投稿時間：02/09/02(Mon) 11:43
投稿者名：小林博昭
Ｅメール：
ＵＲＬ ：
タイトル：日本風風味のAnnexCのITU-T非準拠について
先般のお約束通り現行のAnnexCのITU-T非準拠の箇所についての情報の開示です。原文は英文であり、メーカー名は特定できないようにX社とY社にしました。チップのバージョン名は「A」と「B」にしました。
ITU-Tの規格に合わせて作ると以下のポイントで互換性を持たないという内容です。規格通り作るとつながらないから最初から話にならないわけです。
これだけ規格品外製品をばら撒いてどう決着つけるかというのが
今後の大きな問題です。昔、ICの足の長さが国際規格で決まっていたがそれとは別の規格外の長さで大量に製造したメーカーの長さに
あわせてしまったということもあるようです。国際規格（ITU−T)を
日本風に変えてしまうということが取りうる方法かも。
そうすると一体、ITU-Tとは何なのか？という疑問。ITU-T準拠を基本としてきたTTCとはなーに？ということか。
何故国際規格準拠と日本風AnnexCが接続できないかご一読ください。
Maker “x” G.lite and G.dmt Annex C modem non-compliances:
Observation on version “A” and “B”.
1. X’ CO deliberately fails at the beginning of handshake messaging (probably when they
enter HSTU-C initial transaction state) and restarts expecting the RT will do the same.
The second link follows more or less the G.994.1 standard (see the item below).
If RT doesn’t restart immediately, then X’ CO fails again at the same place.
2. In handshake messaging X’ modems (CO and RT) send both R-ACK1 and R-ACK2 bits set to
zero (although G.994.1 recommendation requires that at least one of those bits is set to
one). Also, their RT starts immediately with the MR message without prior exchange of CLR
- CL pair.
3. During the first messaging (R-RATES1 to R-CRC2) X’ RT sends REVERB signal during NEXT
symbols (according to spec, it should be quiet during those symbols). Note that this is
not crucial since on the CO we decode the messages only in FEXT frames.
4. The CRC calculation for RATES1 message (C-CRC1 and R-CRC1) includes the 4-byte prefix
as well as the message itself. (fixed in G.DMT)
5. X’ R-SEGUE1 is 16 frames long (although the maximum length specified in G.lite is 14
frames), and their CO expects such length, otherwise it fails.
6. X’ code does not reset the pseudo-random sequence pointer on first MEDLEY frame so
their first MEDLEY symbol is NOT equal to REVERB (i.e., their MEDLEY is shifted by one
frame).
7. In FEXT Bitmap mode, X’ modems do not increment the pseudo-random sequence pointer
during NEXT MEDLEY symbols when nothing is transmitted.
8. Variable length REVERBs are not supported (X’ CO and RT both require the minimum
REVERB lengths (n = 0), otherwise they fail).
9. C-CRC5 is calculated only on the NEXT B&G message (i.e., on the second half of the
C-B&G message).
10. X’ RT begins R-B&G message with FEXT bits and gains for tone 32, and the
complete transmitted R-B&G table is thus shifted by 31 16-bit words. Also, their
modems calculate upstream CRC5 only on 96 FEXT (tones 32-127) and 96 NEXT concatenated
B&G table entries! (fixed in G.DMT)
11. A double train: X’ DMT RT drops the link immediately after reception of C-CRC5, and
then CO has to restart the link immediately, and the second link becomes stable.
X’ G.dmt Annex C DSLAM specific issues:
1. It requires double training to achieve the good data rate. The first training has to be
G.lite and then CPE gets the good data rate from the second G.dmt training. The first link
can be forced to be G.lite by forcing G.lite mode at CPE or by sending X’s Vendor ID
during the G.hs.
Y’s G.dmt Annex C modem non-compliances:
1. Y’s CO doesn’t transmit the PILOT tone during the NEXT frame in FBM mode.
2. Y’s CPE expects C_QUIET5 instead of C_PILOT3 white CPE does echo canceller training,
while it doesn’t send R_ACK1. If CO transmits C_PILOT3, then the downstream data rate
becomes very low.
小林博昭 |
|