Telecommunications Industry Association (TIA)
TR-30.1/01-03-017
St. Petersburg, Florida, 7th March 2001
COMMITTEE CONTRIBUTION
Technical Committee TR30 Meeting
SOURCE:
Telogy Networks, Texas Instruments Company
20250 Century Blvd
Germantown, MD 20874
TITLE:
Plesiochronous data mode entry in V.34 and V.90.
DISTRIBUTION:
Meeting attendees
CONTACT:
Adrian Zakrzewski
Voice: +1 301 515-6636
Fax: +1 301 515-7954
Email: [email protected]
________________________________
Abstract
This contributions addresses issue 5.12 of Issue List for V.moip. It evaluates two methods of
bringing up modem connections plesiochronously.
Copyright Statement
The contributors grant a free, irrevocable license to the Telecommunications Industry
Association (TIA) to incorporate text contained in this contribution and any modifications
thereof in the creation of a TIA standards publication, to copyright in TIA's name any standards
publication even though it may include portions of this contribution, and at TIA's sole discretion
to permit others to reproduce in whole or in part the resulting TIA standards publication.
Telecommunications Industry Association (TIA)
St. Petersburg, Florida, 7th March 2001
Abbreviations
EC
RTD
IP
MoIP
TAS
Error Correction
Round Trip Delay
Internet Protocol
Modem over IP
Telecomm Analysis Systems
Introduction
During previous MoIP meetings it became clear that it would be desirable to bring up the two
modem connections at approximately the same time (e.g. +/- 1s).
This would make end-to-end negotiation of compression parameters possible and would not
require using default parameters proposed in [1] .
One of the possibilities to achieve this goal is by extending phase 4 of the faster connection, so
that it waits for the other side to catch up.
However, both V.34 and V.90 have pretty tight timeouts, which would force the client to request
a retrain if phase 4 was too long. In order for the scheme to work these timeouts have to be
extended.
We evaluated two possible methods of timeout extension:
 using the existing CME mechanism defined in V.34 recommendation
 using RTD tweaking
1 Extending phase 4 timeouts by means of CME bit
According to V.34 recommendation, if the CME bit in the INFO sequence is set, the timeout
period between sending J-prime and receiving E for an originating modem or between sending Sbar and receiving E for an answering modem in phase 4 will be extended from 2.5s + 2*RTD to
30s.
The three most popular client modems were tested with Telogy server. The server set CME bit in
its INFO sequence and extended its timeout to 30s irrespective of the CME bit received from the
client modem.
In two of the three cases the timeout extension worked fine and we were able to extend the
handshake by over 20s. In one case, however, the scheme did not work – the client modem not
only did not extend its timeout as per V.34 recommendation, but it also did not tolerate the
server’s CME bit set. Each time a connection was attempted the client requested a retrain at the
beginning of phase 4 and finally dropped the call even if the server did not extend its phase 4.
2
Telecommunications Industry Association (TIA)
St. Petersburg, Florida, 7th March 2001
Although CME bit exists in V.90 INFO sequences, the recommendation does not mention
extending the timeout. One of the modems, however, extended the timeout like in V.34. The
other modems did not.
advantages:
 simplicity
 already standardized
 long timeout extension (i.e. up to 30s)
disadvantages:
 supported only in V.34 standard, not V.90
 not all clients support this option in V.34
2 Extending phase 4 timeouts by means of tweaking client modem’s RTD
measurement
75  5 ms
client
CM
CJ
10 ms
INFO0c
B
10 160
ms ms
 670 ms
B
B
B L1
L2
INFO1c
40  1 ms
40 ± 1 ms
40ms+Textra10
ms
server
JM
INFO0a
75  5 ms
A
50 ms
A
A L1
10 160
ms ms
L2
A
A
50 ms
A
670 ms
INFO1a
70  5 ms
T1400760-94/d16
Figure 1 V.34 Phase II
According to the V.34/V.90 recommendations, the server has to generate a phase reversal 40ms
after detecting a phase reversal from the client modem during phase 2 (40ms is subtracted when
computing the RTD).
Thus, the RTD can be adjusted by changing the time duration between receiving the phase
reversal from the client and performing the phase reversal from 40ms to 40ms + Textra.
We found that the RTD measurement affects not only the far-echo canceller and the timeout for
the EC layer (T401) of the client modem, but also some timeouts associated with training
algorithms. We were able to increase the three client modems' RTD measurement up to about 1s
by making the following adjustments:
3
Telecommunications Industry Association (TIA)
St. Petersburg, Florida, 7th March 2001
server needs to
delay sending S/
Sbar by T_extra
S/Sb
server
client
TRN
client misses
S/Sbar because
it thinks it is still
receiving TRN
echo
J
TRN
J S/Sb
TRN length + real RTD
TRN length + virtual RTD
Figure 2 Problems with extended RTD
Some client modems extend receiving of their own Phase III TRN sequence after terminating the
transmission of TRN by a time period based on the measured RTD. Therefore, if the actual RTD
is much shorter than the "virtual" RTD, the client modem will not detect S/Sbar transition, since
it is still receiving TRN echo. This in turn will result in a retrain. To solve the problem, the
transmission of S/Sbar after detecting J from the client modem has to be delayed by the same
amount of time as the correction applied to the RTD in phase 2 (Textra). Figure 2 illustrates the
problem.
For the same reason the transmission of the 2nd A/Abar after receiving B in phase 2 has to be
delayed by Textra.
We also tested different client modems on TAS without any adjustments to the server code and
found that there is a limit on how much “real” RTD is tolerated. The maximum RTD allowed for
the three client modems is between 1.1s and 1.4s. If it is higher, the clients retrain.
Assuming the maximum tolerated RTD is 1.1s and the real RTD not greater than 0.1s, we can
extend phase IV timeouts by:
 2 x 1s = 2s in V.34 (according to section 11.4.2.1.2 and 11.4.2.2.2 of V.34 recommendation)
 5 x 1s = 5s in V.90 (according to section 9.4.1 and 9.4.2 of V.90 recommendation)
4
Telecommunications Industry Association (TIA)
St. Petersburg, Florida, 7th March 2001
advantages:
 works for both V.34 and V.90
 relatively simple to implement
disadvantages:
 short timeout extension
 may cause interoperability problems
 only applicable when there’s no far echo
Conclusions
It is our belief that none of the methods offers a good solution to the problem of entering data
mode at the same time. We do not recommend using CME method, because it is not a universal
solution. The RTD method in our opinion, offers very limited handshake timeout extension at a
price of inevitable and difficult to predict interoperability problems.
References
[1] PCM01-006: Modem Transport Over IP Using SPRT, Cisco Systems
5