Telecommunications Industry
Association
(TIA)
Arlington, VA
TR-30.3/10-08-019
August 16 - 17, 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. We expect this text to be edited heavily during the August, 2010
meeting.
TR-30.3/10-08-019
Foreword
[From the TIA Style Manual, 1992!]
The foreword shall appear in every standard; it consists of a general part giving information
relating to the organization responsible and to standards in general and a specific part giving as
many of the following as are appropriate:
-- an indication of the committee that prepared the standard;
-- information regarding the approval of the standard;
-- an indication of any other organization that has contributed to the preparation of the standard;
-- a statement that the standard cancels and replaces other documents in whole or in part;
-- a statement of significant technical changes from the previous edition of the standard;
-- the relationship of the standard to other standards or other documents;
-- a statement of which annexes are normative and which are informative. (e.g., There are two
annexes in this Standard. Annex A is normative and is considered part of this Standard;
Annex B is informative and is not considered part of this Standard.)
The following disclaimer shall appear above the text:
(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. This should provide more realism than the earlier version.
TIA-921-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.
Page 2 of 8
TR-30.3/10-08-019
There are [insert number] of Annexes in this Standard. Annex A [and Annex B] are normative
and are considered part of this Standard. Annex [C and Annex D] are informative and are not
considered part of this Standard.
Introduction
[From the TIA Style Manual]
The introduction is an optional preliminary element used, if required, to give specific information
or commentary about the technical content of the standard and about the reasons prompting its
preparation. It shall not contain requirements.
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.
Scope
[From the TIA Style Manual]
This element shall appear at the beginning of every standard to define without ambiguity the
subject of the standard and the aspect(s) covered, thereby indicating the limits of applicability of
the standard or particular parts of it. It shall not contain requirements.
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, Gatekeepers, Application Servers, Routers, etc.)
o IP Video (IPTV, video conferencing, telepresence, etc.)
o IP Phones (including soft phones)
o IAF (Internet Aware Fax)
o core network elements
 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:
Page 3 of 8
TR-30.3/10-08-019


Test an IP stream under simulated network conditions
Test an IP stream in real time using hardware emulation of the network model.
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.
 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.
Description of the 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.”
Disturbance Load
Generator
Second Disturber
Third Disturber
Test Stream Input
to This Stage
Link
Latency
+
Simulated
Packet Queue
with Loss
Test Stream Output
from This Stage
Disturbance
Packets
Figure 1: Model Basic Network Switch Element
The basic network elements are “wired” in series into a specific network topology. One such
possible network is shown in
Page 4 of 8
TR-30.3/10-08-019
[insert line drawing of slide 12]
This is an outline of the simulator processing:
1. A packet generator drives packets into the simulator. The arrival times and sizes of the
test stream packets and the interfering stream packets are read from pcap files.
2. A switch receives packets on its ingress ports, and determines where packets should go
next.
3. A switch schedules each packet for transmission out one of its egress ports.
4. Wires connect the egress port of one switch to the ingress port of another switch.
5. The process repeats for all packets through all switches and wires.
6. Packet arrival and departure times are stored in a file for analysis.
The sections that follow explain the components of the model in more detail:
 Disturbance Load Files
 Network Topology
 Models of Network Elements
 Simulation Inputs [do we need this subsection?]
 Simulation Outputs
 Packet Scheduling Algorithm
Disturbance Load Files
[where they came from]
[how selected]
[bidirectional]
[how processed: strip payload (or not), optionally scaled, optionally smoothed]
[how described by time series, PDV histogram]
[QoS assigned as managed or residual bandwidth (or does that below elsewhere in the
Standard?)]
[impairment severity is a function of pcap statistics, number and rate of streams]
Network Topology
[standard models: LAN-LAN, core-LAN, core only]
[impairment severity is a function of the number of stages]
[how to describe custom models]
Models of Network Elements
Network Element Overview
The various types of networks elements considered in this model are:
 switch
 router
 firewall
 access link and devices
 [cut this list to the bare minimum required]
[Is there really any interesting difference among these elements, or can they all be modeled as
a switch?]
Page 5 of 8
TR-30.3/10-08-019
Switch
Router
Firewall
Access Technologies
Access Technology Overview
The model accounts for the different properties of different access technologies. The
parameters of interest, all of which affect the impairment severity, include:
 link rate
 bit-error rate
 delay
 DCE buffer size
 QoS [insert noun]
Digital Subscriber Line
DSL data rates are between 10 Mbit/s and 33 Mbit/s. [What about upstream?] DSL bit-error
rates are between 10-8 and 10-7. The data buffer size at the DSL modem is assumed to be 64
kBytes.
Cable Modem
Gigabit Passive Optical Network (GPON)
Wireless Access (WiMAX, LTE)
Simulation Inputs
[Do we need this section, or can we include everything within the preceding subsections?]
Simulation Outputs
The simulator output is a file for each direction – upstream and downstream – that lists the
precise arrival time and delay of each packet in the stream under test from model ingress to
egress. Packets that are dropped because of network congestion are noted. [What does Delay
mean when the packet is dropped?] See the example in Table 1.
Page 6 of 8
TR-30.3/10-08-019
Table 1: Example Simulator Output
Source:
Creation Date:
Description:
ContentEncoding :
Delay Unit:
Time
2
2.064531
2.068719
2.083353
2.103442
2.129744
2.136147
2.160704
2.276267
2.306837
2.331988
2.36096
2.443818
TIA-921-B
5/5/2010
Misc Downstream
2
ASCII
ms
Delay
62.540836
62.5377494
62.106312
62.21563497
62.40617898
62.154648
62.401416
63.0072554
62.69638617
63.43353741
62.41461574
62.09868
63.41120351
Drop
0
0
0
0
0
1
0
1
1
1
1
1
0
The simulator may generate a pcap file containing the same information, suitable for processing
by any program that recognizes the pcap file format.
[Should examples of PDV and time series be included here, or in an informative Annex?]
Packet Scheduling Algorithm
[Chip Webb will provide this text.]
IP Network Impairment Level Requirements
[Insert Y.1541 table of test profiles and SLAs.]
[Insert tables of impairment levels.]
Annex (Normative): Description of Discrete Event Simulator
[or is this really the core part of the standard, and as such, should be in the main body, not in an
Annex?]
Annex (Normative): C++ Source Code of Discrete Event Simulator
[electronic attachment]
[Should the source itself be printed in the document?]
Page 7 of 8
TR-30.3/10-08-019
Annex (Normative): Packet Capture Files of Interfering Traffic
[electronic attachments]
Annex (Normative): Simulator Output
[electronic attachments]
Annex (Informative): Rationale for Network Model
Annex (Informative):
____________________
Page 8 of 8