5.2.2.1 / Change "10 different IC combinations, and transfer a short message" to "different RBS patterns, 5 different digital pad levels, and 6 different loops. A short message is transferred to ensure that the modems have correctly established a connection.
5.2.2.1 / Add the paragraph: "Rather than choose all 120 of these combinations of RBS, digital pad, and loop, this test runs a subset of the combinations which are chosen so that 1) connection problems associated with any single value of these parameters can be determined, 2) connection problems associated with any combination of 2 parameters can be detected, 3) all values of each parameter are tested with all values of the other parameters, and 4) the results for each value of each parameter is largely independent of the other parameters. This is accomplished by testing only 48 of the 120 combinations."
5.2.2.3 / I believe it doesn't make sense to use this particular test with the U portion of the network model.
5.2.2.3 / This should be replaced by "This test uses impairments specified by TIA/EIA-793 impairment combination I09D with modification for RBS and digital pad as specified in Table XYY below." The table should indicate the RBS values of (no RBS, a single RBS1, a single RBS2, and a single RBS1 combined with a single RBS2). The table should indicate the digital pad values of (0dB, 3dB, 4.5dB, 6dB, and 9dB).
5.2.2.3 / Should these also include the ISDN equivalents – i.e. I09D & U09D, respectively?
5.2.2.8 / Everything below Figure 1 needs to be replaced, but the text is fairly involved. This is effectively two tests combined into one.
5.2.3 / Should this test be dropped?
5.2.4.2 / I believe this test should focus only on those factors visible to users: throughput over a long time period and maintaining the connection for the entire duration. Measuring retrains, renegotiaitons, etc. are better measured in how they impact the throughput.
5.2.4.3 / Set the network emulator to the single test channel in the network model. (Which one(s)?
5.2.4.7 / It might be better to run the test for 16 hours, since this more closely approximates an overnight test.
5.2.5.2 / Throughput for each file type.
5.2.5.3 / Set the network emulator to the single test channel in the network model. (Which one(s)?
5.2.5.4 / One call per file type.
5.2.5.7 / It would be MUCH easier to drop the connection between each test. The TAS software does not support changing tests during the call.
5.2.5.7 / 4.  Transfer the test file 1.TST repeatedly for three minutes from DTE B to DTE A. Begin the transfer as soon as the previous A–to–B transfer finishes.
Do we really begin the B>A transfer after completion of A>B, instead of simultaneously (full-duplex)?
5.2.5.8 / Why is there a weighting factor? This does not seem to add anything to the results. If this is a means to combine the results for each direction, that would tend to obscure any real problems with the modem by consolidating unrelated information.
5.2.6.1 / Many test labs run the throughput vs network model test with compression turned on and using non-compressable data. We may want to leave that option open as the results are very similar.
5.2.6.2 / Why capture connect speeds?
5.2.6.4 / One call per combination of IC and test loop.
5.2.6.6 / If a highly compressable file is sent (as specified in 5.2.6.1) and data compression is enabled, the results are going to be extremely high.
5.2.6.7 / Why require using FTP for throughput?
5.2.6.7 / 2.  Transfer the test file 1.TST repeatedly for three minutes from DTE A to DTE B using FTP with no delay between establishment of the connection as defined in 4.4 and the be-ginning of data transfer.
Why FTP instead of the standard file transfer used by the TAS test software? How will this requirement be accomodated in the TAS test software? If we are only interested in testing the signal converter behaviour, then why would the file transfer protocol necessarily matter if it is consistent throughout the test?
5.3.4.0 /

Throughput vs. file type

Is the only difference between this test and the Throughput vs. Filetype in section 5.2.5 the use of FTP in this version?
5.3.4.6
TABLE E.2 / The weighting should be based on the relative importance of one–way and two–way file transfers for the particular application. In this example, a weighting of 75 percent for one–way and 25 percent for two–way was selected. These weightings can be adjusted as desired, as long as their sum is 100 percent.
Would like explanation of the weighting idea, and why would necessarily weight one-way throuhput more heavily than two-way…
5.3.7 / This seems to be a functionality test rather than a performance test. Does this fit the scope and role of TR30.3 (I honestly don't know, myself)?
Forward / Remove "when used in asynchronous... synchronous or asynchronous applications" and replace with "in such applications as file downloading and is one important metric for how users will perceive a wide variety of uses such as web browsing."
General / Should we get rid of all references to synchronous mode and testing?
General / Setting the DTE speed to the maximum possible value can often produce bad results. A particular headend modem has been observed to slow down when its DTE speed is set to the maximum of 230400 bps with bidirectional data transfer.
Editorial Notes /
Section / Note
1 / 1st paragraph: remove the phrase "and leased line modems"
1 / 1st paragraph: change "data comunications applications" to "users"
1 / 2nd paragraph: change "defects in" to "characteristics of"
also change "Public Switched Telephone Network (PSTN), and in leased-lines" to "Public Switched Telephone Network (PSTN), and defects in leased-lines"
1 / 3rd paragraph: change "network converge" to "network model" because that's what nearly everyone calls it.
1 / 3rd paragraph: change "a bunch of" to "merely"
3 / is EIE-232-E the latest version (or is it F or G or something else)?
3 / V.35 has been replaced (by V.36 and V.37?)... this reference could probably be removed.
3 / Should this also mention V.25 ter as well as V.25 and V.25 bis?
3 / Need to reference V.44 as well as V.44 and V.42bis
4.10 / Add V.44 (and V.44bis?)
4.13 / Need to reference V.44 bis dictionary
4.14 / Should we get rid of direct mode?
4.16 / Need to reference V.44
4.19 / Need to reference "TIA/EIA-793 (previously known as PN3857)"
4.21 / Either need to reference V.44 or remove the whole definition.
4.24 / Technically, there are also "mark" and "space" parity where the optional check bit is always set to 1 and 0 respectively.
4.30 / Need to reference TIA/EIA-793 (previously known as PN3857)
4.31 / Need to reference TIA/EIA-793 (previously known as PN3857)
4.35 / Is an ADPCM definition really needed?
4.38 / Change to "digital pads: - network carrier level adjustments, effectively reduces digital signal level by 6 db,3 db, or some other amount of attenuation."
4.44 / reference V.92 as well as V.90
5.2.1.1 / Complete the phrase
5.2.1.3 / Section is empty
5.2.2.4 / Complete placeholder for number of calls
5.2.2.5 / Complete sentence fragment
5.2.2.6 / Include reference to V.44?
5.2.3.7 / Fix spelling
5.2.5 / New files for testing compression, now that we have V.44?
5.3.5.7 / Repair page numbering (it starts over here).
All / Why sans-serif font? It’s harder to read than Times Roman. Check TIA Style Guide.
Cover / Update Draft #.
Update date.
Add “(to be published as TIA/EIA-3800)”
Forward / The count of Annexes will need to be updated when the document is complete.
TOC / Odd alignment, probably caused by indented headings. Page numbers should align on right edge.

1  V.92/V.44 Test Procedure

1.1  Procedures specific to V.92

1.1.1  Throughput vs Network Model Coverage (i-model)

Throughput vs Network Model Coverage (u-model)

PCM Upstream

Call Connect Reliability (CCR)

Modem-on-Hold (MoH) – Functionality / Compatibility

Quick Connect

Block Acknowledgement & Character Echo Delay

Procedures specific to V.44

Throughput vs File Type (TFT) - V.44 files

2  Quick Connect

As part of standard Network Model Coverage

Establish specified network simulation parameters

Dial from client-modem to V.92 compliant RAS

Transmit V.44 test file #1 bi-directionally and measure file throughput in cps

Tear down call

Repeat step 2 and record “last digit” to “connect message” time

Repeat steps 2 through 5 for all NMC test points

3  Modem on Hold

3.1  Procedures specific to V.92 Evaluation

Establish specified network simulation parameters

Dial from client-modem to V.92 compliant RAS

Transmit V.44 test file #1 from RAS to client-modem and measure file throughput in cps

Enter modem-on-hold test plan:

Repeat throughput test in step 3 at each plan endpoint

Tear down call

Repeat steps 2 through 6 for all test plan endpoints

4  PCM Upstream

4.1  Procedures specific to V.92: As part of standard Network Model Coverage

Establish specified network simulation parameters

Dial from client-modem to V.92 compliant RAS

Transmit V.44 test file #1 bi-directionally and measure file throughput in cps

Tear down call

Repeat steps 2 through 4 for all NMC test points

5  V.44

5.1  Procedures specific to V.44 Evaluation

Establish specified network simulation parameters

Dial from client-modem to V.44 compliant RAS

Transmit V.44 test file #1 from RAS to client-modem and measure file throughput in cps

Tear down call, then Reestablish call

Transmit V.44 test file #1 from client-modem to RAS and measure file throughput in cps

Tear down call, then Reestablish call

Transmit V.44 test file #1 bi-directionally and measure file throughput in cps

Tear down call

Repeat steps 2 through 9 using files #2 through 6