Telecommunications Industry Association
(TIA)
TR-30.1/1-02-08-107
August 6-9, 2002, Waltham, MA
COMMITTEE CONTRIBUTION
Technical Committee TR-30 Meetings
SOURCE:
The CommWorks Corp., a 3Com company
TITLE:
Endpoint communications in MoIP modem relay mode
DISTRIBUTION:
Members of TR-30.1
CONTACT:
Jim Renkel
Office: +1.847.262.2539
E-mail: james_renkel@commworks.com
____________________
ABSTRACT
This contribution examines the issues of data formatting and break handling in MoIP modem relay mode.
The company represented by this individual may have patents or published pending patent applications, the use of
which may be essential to the practice of all or part of this contribution incorporated in a TIA Publication and the
company represented by this individual is willing to grant a license to applicants for such intellectual property
contained in this contribution in a manner consistent with 2a) or 2b) of Annex H of the TIA Engineering Manual.
COPYRIGHT STATEMENT:
The contributor grants a free, irrevocable license to the Telecommunications Industry Association (TIA) to
incorporate text or other copyrightable material contained in this contribution and any modifications thereof in the
creation of a TIA Publication; to copyright and sell in TIA's name any TIA Publication even though it may include all
or portions of this contribution; and at TIA's sole discretion to permit others to reproduce in whole or in part such
contributions or the resulting TIA Publication. This contributor will also be willing to grant licenses under such
copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing a TIA
Publication incorporates this contribution.
This document has been prepared by the Source Company(s) to assist the TIA Engineering Committee. It is
proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the Source
Company(s). The Source Company(s) specifically reserves the right to amend or modify the material contained
herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any
intellectual property of the Source Company(s) other than provided in the copyright statement above.
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
Page 2 of 16
Table of Contents
Introduction ............................................................................................................................................ 3
Endpoint configurations in MoIP modem relay mode ............................................................................ 3
Data elasticity between MoIP endpoints in modem relay mode ............................................................ 5
Break handling by MoIP endpoints in modem relay mode .................................................................... 6
Data formats between MoIP endpoints in modem relay mode .............................................................. 9
5.1
Common header ............................................................................................................................. 9
5.2
Compressed data frames format .................................................................................................. 10
5.3
Asynchronous character format.................................................................................................... 11
5.4
V.110 Asynchronous character format ......................................................................................... 12
5.5
Break indication format ................................................................................................................. 13
5.6
HDLC frame format....................................................................................................................... 13
5.7
Unformatted data format ............................................................................................................... 14
5.8
Elastic data format ........................................................................................................................ 15
6 Proposed issues and resolutions ......................................................................................................... 16
1
2
3
4
5
Table of Figures
Figure 1 - MoIP endpoint modem relay mode configurations ....................................................................... 3
Figure 2 - Example of (destructive) break handling procedure ..................................................................... 8
Figure 3 - Format of common data message header ................................................................................... 9
Figure 4 - Format of compressed data frame data message ...................................................................... 10
Figure 5 - Format of asynchronous characters data message ................................................................... 11
Figure 6 - Format of V.110 asynchronous characters data message ......................................................... 12
Figure 7 - Format of break indication message .......................................................................................... 13
Figure 8 - Format of HDLC frame data message ....................................................................................... 13
Figure 9 - Format of unformatted data message ........................................................................................ 14
Figure 10 - Format of elastic data message ............................................................................................... 15
Table of Tables
Table 1 - Data format preferences of one MoIP endpoint by modem relay mode configuration .................. 4
Table 2 - Data format preferences of two MoIP endpoints by modem relay mode configurations ............... 4
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
1
Page 3 of 16
Introduction
This contribution examines the issues of data formatting and break handling between MoIP endpoints in
modem relay mode.
Section 2 enumerates the possible configurations in an MoIP endpoint operating in modem relay mode,
and then looks at combinations of layer structures in two communicating MoIP endpoints. Section 3 looks
at the issue of the elasticity of the data exchanged between MoIP endpoints operating in modem relay
mode. Section 4 looks at break handling between MoIP endpoints operating in modem relay mode.
Section 5 then recommends data formats to be used between MoIP endpoints in modem relay mode.
Section 6 summarizes issues and proposed resolutions.
2
Endpoint configurations in MoIP modem relay mode
The following figure shows the possible configurations of one endpoint in MoIP modem relay mode. If
error correction is not negotiated with the local modem, configuration 0 is used for both transmitting
packets to and receiving packets from the packet network. If error correction is negotiated with the local
modem, then one of configurations t0 through t4 is used to transmit packets to the packet network, and
one of configurations r0 through r4 is used to receive packets from the packet network, each depending
on the endpoint's transcompression capabilities and the outcome of the data compression negotiations.
Note that not all combinations of t0 through t4 with r0 through r4 are valid.
no error correction
0
transmit configuration
error correction
telephony
interface
modulation
no compression
t0
dx
cx
double TCX dx  cx
t1
dx
cx
double TCX no remote compression
t2
dx
cx
double TCX no local compression
t3
dx
cx
no TCX; single TCX;
double TCX - dx = cx
t4
receive configuration
no compression
r0
cx
dx
single / double TCX dx  cx
r1
cx
dx
single / double TCX no remote compression
r2
cx
dx
single / double TCX no local compression
r3
cx
no TCX;
dx
single / double TCX - dx = cx
r4
Figure 1 - MoIP endpoint modem relay mode configurations
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
Page 4 of 16
The following table gives the preferred data formats of each configuration. Within the table, R denotes
raw modulation data format, A denotes asynchronous characters in V.42 Annex B format, and C is
compressed data frames format.
Table 1 - Data format preferences of one MoIP endpoint by modem relay mode configuration
Configuration
0
t0
t1
t2
t3
t4
r0
r1
r2
r3
r4
Preferred data format
R
A
C
A
C
C
A
C
A
C
C
The following table gives the preferred data format(s) of a pair of MoIP endpoints, G1 and G2,
communicating in modem relay mode, for all combinations of receive and transmit configurations. Only
the G1 to G2 direction is given; the G2 to G1 direction is symmetric. Invalid combinations are shown as
an X. If the preferred format of both gateways is the same, it is shown in the table. If the preferred formats
of the gateways are different, both are shown with G1's preference first.
Table 2 - Data format preferences of two MoIP endpoints by modem relay mode configurations
Preferred data
formats
G1 transmit
configuration
0
t0
t1
t2
t3
t4
0
R
A,R
X
A,R
X
X
G2 receive configuration
r0
r1
r2
r3
R,A
X
R,A
X
A
X
A
X
X
C
X
C
A
X
A
X
X
C
X
C
X
C
X
C
r4
X
X
C
X
C
C
Eighteen (18) of the 36 possible combinations are invalid. In 14 of the 18 remaining combinations, the
preferred transmit format is the same as the preferred receive format, and no conversion is necessary as
data is transmitted from G1 to G2. However, in the remaining 4 combinations, the preferred transmit
format is not the same as the preferred receive format.
However, in all 4 such combinations one format is raw modulation data and the other is asynchronous
characters. In these combinations, we recommend that the endpoint preferring raw modulation data
format, i.e., the endpoint that did not successfully negotiate error correction, perform the conversion to
and from asynchronous character format before transmitting to and after receiving from the packet
network, respectively.
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
3
Page 5 of 16
Data elasticity between MoIP endpoints in modem relay mode
"Elastic data" is data that can be stretched or shrunk within a data stream without changing the meaning
of the data stream.
One example of elastic data is the marks (1 bits) that may be between successive asynchronous
characters. Marks can be safely added or deleted between successive asynchronous characters without
changing the "meaning" of the surrounding asynchronous characters. Note that the timing obviously
would change, but the meaning (independent of timing) would not. Note also that the stop bit of an
asynchronous character, although a 1 bit and continuous with the 1 bits in between successive
asynchronous characters, is NOT considered an elastic mark: it cannot be (safely) deleted.
Another example of elastic data is the stream of flags that may be between successive HDLC frames. As
with marks between asynchronous characters, flags may be safely added or deleted without changing the
meaning of the frames. Again, timing may be changed, and the flag(s) that terminates one frame and
initiates the next are NOT considered elastic.
Asynchronous characters sent as a block per V.42 Annex B have had the elastic marks between them
already and implicitly deleted upon reception (along with start and stop bits) and the elastic marks may be
reinserted upon transmission. Similarly, the elastic flags between compression blocks (along with the
opening and closing flags, and perhaps other fields in the frame, e.g., the checksum) have already and
implicitly been deleted upon reception and elastic flags may be reinserted upon transmission.
The value of elastic data is twofold. It may be removed or reinserted or both to:
1. match speeds between MoIP endpoints that are operating at different speeds; and
2. cover jitter (variations in latency) in the packet network connecting MoIP endpoints.
For these reasons elastic data capabilities should be defined for all modem relay transfer formats
between endpoints. Elastic data for asynchronous characters and compression blocks has been
discussed above, and is implicit in the definition of those data formats.
With raw modulation data, however, there is no automatic and implicit recognition and removal of elastic
data. Here the capability must be explicitly defined.
When an MoIP endpoint is operating with error correction (either with or without data compression) either
locally or remotely or both, it knows in advance to use either the asynchronous character format or the
compression block format, as appropriate, for data transmission between the endpoints. Unfortunately,
when an MoIP endpoint is operating in raw data mode, i.e., without error correction in both endpoints, it
has no such advanced knowledge of the appropriate data format (and the nature of the elastic data
accompanying it) to use, and must rely on pattern recognition in the data stream received from its local
modem. Additionally, there are data formats other than asynchronous characters and HDLC frames that
can be used by the connected modems, and other forms of elastic data other than streams of marks or
flags, respectively, that are used by the other data formats.
The definition and use of elastic data with the asynchronous and compression block formats is implicit in
their definitions. Elastic data for other data formats (within the raw data format) should be explicit but its
use should be optional.
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
4
Page 6 of 16
Break handling by MoIP endpoints in modem relay mode
V.42 defines a simple, elegant, and reliable mechanism for handling breaks. In somewhat simplified form
it is:
 On detecting a break signal, a modem:
 sends a break indication to the remote modem;
 optionally, flushes data waiting to be transmitted on the DTE interface and resets its compression
dictionaries if any; and
 holds or flushes data received from the DTE interface or the remote modem until a break
acknowledgement is received from the remote modem; and
 On receiving a break indication from a remote modem, a modem:
 depending on the nature of the break, optionally flushes data received from the other modem and
waiting to be transmitted on the DTE interface and data received from the DTE interface and
waiting to be transmitted to the remote modem, and resets its compression dictionaries if any;
and
 transmits a break acknowledgement to the remote modem.
This is fine for two directly connected modems. But when MoIP endpoints in modem relay mode are
present in the connection, the situation is complicated by:
 one modem / endpoint connection may not be error corrected;
 there may be as many as four additional transcompression engines in the connection whose
dictionaries may also need to be reset; and
 it is undesirable to wait for and end-to-end exchange of break indication and acknowledgement
messages.
Therefore, a slightly more complicated mechanism, based on "connection epochs", is needed.
A "connection epoch" is a period of time within a modem connection between two successive
(de)compression dictionary resets. As is usual with definitions of this type, the dictionaries are considered
to be reset upon initiation and termination of the connection.
The epochs may be numbered sequentially for identification and for convenience the epoch sequence
numbers may be taken modulo some small integer, e.g., 8.
Break handling in MoIP endpoints is then performed as follows:
 each endpoint keeps an integer identifying the current epoch; on establishment of the connection,
each endpoint's current epoch number is initialized to the value 0;
 on receipt of data from the telephony interface:
 the data is decompressed or (re)compressed or both as appropriate;
 marked with the endpoint's current epoch number; and
 queued for transmission over the packet network;
 as the rate control function enables transmission over the packet network, the data is transmitted;
 on receipt of data messages from the packet network:
 if the epoch number in the data message is not equal to the endpoint's current epoch number, the
data message is discarded; note that break indications are never discarded;
 else the data message:
 is decompressed or (re)compressed or both as appropriate and queued for transmission over
the telephony interface;
 as the telephony interface is available for the transmission of data, the first queued data
message, if any, is transmitted;
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA


Page 7 of 16
on receipt of a break indication message from its local modem on an error corrected modem link or
on detection of a break signal from its local modem on a non-error corrected modem link, an
endpoint:
 if the break indication is received over an error corrected link, the expedited and destructive
attributes are copied to the break indication message to the other endpoint, and a break
acknowledgement is immediately returned;
 if the break indication is detected on a non-error corrected link, the expedited and destructive
attributes are set to endpoint configured values; the values for these attribute defaults should be
expedited and destructive;
 if the break indication to be sent to the other endpoint has the destructive attribute set:
 the epoch sequence number is incremented by one modulo the maximum value; and
 all data waiting to be transmitted over the telephony interface and the packet network
interface is discarded;
 if the break indication to be sent to the other endpoint has the expedited attribute set, the
message is sent over the expedited reliable SPRT channel, otherwise the normal reliable channel
is used;
on receipt of a break indication message from the other endpoint, an endpoint:
 if the break indication received from the other endpoint has the destructive attribute set:
 the epoch sequence number is incremented by one modulo the maximum value; and
 all data waiting to be transmitted over the telephony interface and the packet network
interface is discarded;
 if the break indication received from the other endpoint has the expedited attribute set, the
message is queued ahead of any other data waiting to be transmitted over the telephony
interface, otherwise it is queued behind any other data waiting to be transmitted over the
telephony interface;
 if the endpoint has an error corrected link with its local modem, when the break indication is to be
transmitted to the local modem:
 the expedited and destructive attributes are copied to the break indication message to the
local modem;
 data transmission to the local modem is suspended until a break acknowledgement is
received from the local modem; and
 if the break indication sent to the local modem has the destructive attribute, data received
from the local modem is discarded until a break acknowledgement is received;
 if the endpoint has an non-error corrected link with its local modem, when the break indication is
to be transmitted to the local modem, a break condition is generated on the telephony interface;
further data transmission to the local modem is not suspended, nor is any data received from the
local modem discarded.
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
Page 8 of 16
The following figure gives an example of the above procedure:
M1
G1
G2
0
M2
0
0
1
2
3
4
5
6
0,0
0
0,1
brk
1
brk
brk ack
1
0,2
brk
1
1,7
brk ack
7
8
7
1,8
8
Figure 2 - Example of (destructive) break handling procedure
In this figure, data messages are shown as light dashed lines. Data messages between modems and
gateways are labeled with their sequence number, retaining the original sequence numbers from M2.
Data messages between gateways are labeled with their epoch and sequence numbers, again retaining
the original sequence numbers from M2. In practice, sequence numbers appropriate to the link would
actually be used.
The figure assumes that the M2 to G2 link is operating at twice the speed of the M1 to G1 link, and that
G2 is pacing data messages to G1 to match this slower speed.
Control messages (break indication (brk) and break acknowledgement (brk ack)) are shown as dark
solid lines.
The gateways G1 and G2 are labeled with the value of their current epoch number variables.
Data message 2 is discarded upon reception by G1 because its epoch number does not match G1's
current epoch number. Data messages 3 through 5 inclusive are discarded by G2 upon reception of the
(destructive) break indication from G1. Data message 6 is discarded by G2 because it is received after a
break indication has been sent to M2 but before the corresponding break acknowledgement has been
received from it.
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
5
Data formats between MoIP endpoints in modem relay mode
5.1
Common header
Page 9 of 16
The following figure defines the format of the header that is common to all data formats:
Octet:
Bit:
0
1
2
3
76543210 7 654 3 2 1 0 7 6 543210 7 6543210
+--------+-+---+-+-+-+-+-+-+------+-+-------+
|
| .
. . . . | . .
| .
|
| type |X. E .L.D.S.F|R.A.DLCI0 |r. DLCI1 |
|
| .
. . . . | . .
| .
|
+--------+-+---+-+-+-+-+-+-+------+-+-------+
Figure 3 - Format of common data message header
Where:
type
X
E
L
D
S
F
R
is a unique value among all SPRT message IDs, identifying this message as
a modem relay data message and indicating its format, as follows:
0 DATA_ELAS
none, elastic data only (the L bit of the message
must be set to 1)
1 DATA_COMP
compressed data frame
2 DATA_ASYN
asynchronous characters
3 DATA_V110
ITU-T Recommendation V.110 formatted data
4 DATA_BRK
break indication
5 DATA_HDLC
HDLC frame
6 DATA_UNF
unformatted data
7
reserved
is a bit which if 1 indicates the presence of format specific extension fields in
the message (only used with DATA_ELAS, DATA_ASYN, DATA_V110,
DATA_BRK, DATA_HDLC, and DATA_UNF formats)
is a 3 bit value which gives the epoch number during which this data was
received from its local modem by a gateway
is a bit which if 1 indicates the presence of elastic data following the nonelastic data in this message; elastic data may be appended to the message
only if the F bit, in formats in which it is used, is set; formats which do not use
the F bit (DATA_ASYN, DATA_V110, and DATA_BRK) may always have
elastic data appended; if no elastic data is appended to the last message of a
block in a format that uses the F bit, then the next block must transmitted
immediately after this block; if no elastic data is appended to formats that do
not use the F bit, it is assumed that the elastic data is continuous mark bits
(1s).
is a bit which if 1 indicates that a data link connection identifier (DLCI) is
included in the frame (only used with DATA_COMP, DATA_ASYN, and
DATA_BRK formats)
is a bit which if 1 indicates that this message contains the start of a block of
data that spans multiple messages; no elastic data may be inserted between
data in different messages within the block (only used with DATA_COMP,
DATA_HDLC, and DATA_UNF formats)
is a bit which if 1 indicates that this message contains the finish of a block of
data that spans multiple messages (only used with DATA_COMP,
DATA_HDLC, and DATA_UNF formats)
is a bit which when set indicates that the data was extracted from the first 7
of every 8 bits, e.g., the data came from a 56k BPS DS0. when reset it
indicates that the data was extracted using all bits
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
A
DLCI0
r
DLCI1
5.2
Page 10 of 16
is a bit which when set indicates that the DLCI1 field is present, i.e., the
DLCI, if present, is 13 bits long; when reset it indicates that the DLCI1 field is
not present, i.e., that the DLCI, if present, is 6 bits long.
is the first six bits of the DLCI; present only if D bit is 1
reserved; set to 0 by sender; ignored by receiver
is the next seven bits of the DLCI, present only if A bit is 1
Compressed data frames format
The following figure defines the format of a compressed data frame data message:
Octet:
Bit:
0
h
h+1
h+2
h+3
h+4
76543210 76543210 76543210 76543210 76543210 76543210
+--------+--------+--------+--------+--------+-------|
|
|
|
|
|
| header | count | frame data ...
|
|
|
|
|
|
+--------+--------+--------+--------+--------+--------
Figure 4 - Format of compressed data frame data message
Where:
header
count
frame data
is the common h byte header (h = 2, 3, or 4) as defined above, with:
type set to DATA_COMP
X
set to 0
is the number of compressed data frame octets in this message
are the octets of the information field of the compressed frame, up to the
number given by count
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
5.3
Page 11 of 16
Asynchronous character format
The following figure defines the format of an asynchronous characters data message:
Octet:
Bit:
0
h
h+1
h+2
h+3
h+4
76543210 76 543 21 0 7654321076543210 76543210 76543210
+--------+--+---+--+-+----------------+--------+--------+-------|
| .
. . |
|
|
|
| header |D . P .S .R|
rate
|count
| characters ...
|
| .
. . |
|
|
|
+--------+--+---+--+-+----------------+--------+--------+--------
Figure 5 - Format of asynchronous characters data message
Where:
header
D
P
S
R
rate
count
characters
is the common h byte header (h = 2, 3, or 4) as defined above, with:
type set to DATA_ASYN
X
set to 1 if octet h is present, else 0
is a 2 bit value which gives the number of data bits in each asynchronous
character, as follows:
0
5 data bits
1
6 data bits
2
7 data bits
3
8 data bits
is a 3 bit value which gives the type of parity bit to be added to each
asynchronous character, as follows:
0
no parity bits
1
even parity bits
2
odd parity bits
3
0 parity bits
4
1 parity bits
5-7
reserved
is a 2 bit value which gives the number of stop bits in each asynchronous
character, as follows:
0
1 stop bit
1
1.5 stop bits
2
2 stop bits
3
reserved
is a 1 bit field, which if 1 indicates the presence of the rate field
is a 16 bit field that gives the bit rate at which the asynchronous characters
were decoded, in units of 0.5 bits per second; if 0 or not present, the
asynchronous characters were decoded at the synchronous rate of the
modulation in use
is the number of asynchronous characters in this message
are the asynchronous characters, up to the number given by count, each
right aligned in its octet as defined in ITU-T Recommendation V.42, Annex B.
Octet h, containing the D, P, S, and R fields, is optional and is present only if the X bit is set to 1. If the X
bit is set to 0, the values of the D, P, and S fields are unknown, and the value of the R field is assumed to
be 0, i.e., the rate field is not present.
Octets h+1 and h+2, containing the rate field, is optional and is present only if the R bit is present and
set to 1. If not present or 0, the asynchronous characters were decoded at the synchronous rate of the
modulation in use
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
5.4
Page 12 of 16
V.110 Asynchronous character format
The following figure defines the format of a V.110 asynchronous characters data message:
Octet:
Bit:
0
h
h+1
h+2
h+3
h+4
h+5
76543210 76 543 21 0 7654321076543210 7 6 5 43210 76543210 76543210
+--------+--+---+--+-+----------------+-+-+-+-----+--------+--------+-------|
| .
. . |
| . . .
|
|
|
| header |D . P .S .R|
rate
|A.B.X.resv |count
| characters ...
|
| .
. . |
| . . .
|
|
|
+--------+--+---+--+-+----------------+-+-+-+-----+--------+--------+--------
Figure 6 - Format of V.110 asynchronous characters data message
Where:
header
D
P
S
R
rate
A
B
X
count
characters
is the common h byte header (h = 2, 3, or 4) as defined above, with:
type set to DATA_V110
X
set to 1 if octet h is present, else 0
is a 2 bit value which gives the number of data bits in each asynchronous
character, as follows:
0
5 data bits
1
6 data bits
2
7 data bits
3
8 data bits
is a 3 bit value which gives the type of parity bit to be added to each
asynchronous character, as follows:
0
no parity bits
1
even parity bits
2
odd parity bits
3
0 parity bits
4
1 parity bits
5-7
reserved
is a 2 bit value which gives the number of stop bits in each asynchronous
character, as follows:
0
1 stop bit
1
1.5 stop bits
2
2 stop bits
3
reserved
is a 1 bit field, which if 1 indicates the presence of the rate field
is a 16 bit field that gives the bit rate at which the asynchronous characters
were decoded, in units of 0.5 bits per second; if 0 or not present, the
asynchronous characters were decoded at the synchronous rate of the
modulation in use
is a bit which encodes V.110 S1, S3, S6, S8 or V.24 108 (107)
is a bit whcih encodes V.110 S4, S9, or V.24 105 (109)
is a bit which encodes V.110 X or V.24 106
is the number of asynchronous characters in this message
are the asynchronous characters, up to the number given by count, each
right aligned in its octet as defined in ITU-T Recommendation V.42, Annex B.
Octet h, containing the D, P, S, and R fields, is optional and is present only if the X bit is set to 1. If the X
bit is set to 0, the values of the D, P, and S fields are unknown, and the value of the R field is assumed to
be 0, i.e., the rate field is not present.
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
Page 13 of 16
Octets h+1 and h+2, containing the rate field, is optional and is present only if the R bit is present and
set to 1. If not present or 0, the asynchronous characters were decoded at the synchronous rate of the
modulation in use
5.5
Break indication format
The following figure defines the format of a break indication data message:
Octet:
Bit:
0
h
h+1
76543210 7 6 5 43210 76543210
+--------+-+-+-+-----+--------+
|
| . . .
|
|
| header |D.S.B.resv |brk_len |
|
| . . .
|
|
+--------+-+-+-+-----+--------+
Figure 7 - Format of break indication message
Where:
header
D
S
B
resv
brk_len
is the common h byte header (h = 2, 3, or 4) as defined above, with:
type set to DATA_BRK
X
set to 1 if octet h is present, else 0
is a bit which if 1 indicates that previously received data should be discarded,
i.e., the break signal is destructive
is a bit which if 1 indicates the break indication should move ahead of
previously received but not yet transmitted data, i.e., the break signal is
expedited
is a bit which if 1 indicates the break length field is present
is reserved; set to 0 by sender; ignored by receiver
is the length of the break signal in units of 10 milliseconds; the value 255
indicates a break signal longer in duration than 2.54 seconds
Octet h, containing the D, S, B, and resv fields, is optional and is present only if the X bit is set to 1. If
the X bit is set to 0, the D and S fields are both assumed to have the value 1, i.e., this break indication is
expedited and destructive.
Octet h+1 containing the brk_len field, is optional and is present only if the B bit is present and set to 1.
If not present or set to 0, the value of the brk_len field is undefined and the break signal should be
generated with a default duration.
5.6
HDLC frame format
The following figure defines the format of an HDLC frame data message:
Octet:
Bit:
0
h
h+1
h+2
h+3
h+4
76543210 7 6543 210 76543210 76543210
+--------+-+----+---+--------+--------+-------|
| .
.
|
|
|
| header |T. r .PAD| count | bytes ...
|
| .
.
|
|
|
+--------+-+----+---+--------+--------+--------
Figure 8 - Format of HDLC frame data message
Where:
header
is the common h byte header (h = 2, 3, or 4) as defined above, with:
type set to DATA_HDLC
X
set to 1 if octet h is present, else 0
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
T
r
PAD
count
bytes
Page 14 of 16
is a bit which if present and set indicates that the frame is terminated with an
abort sequence rather than a flag; if not present or not set, the frame is
terminated with a flag
reserved; set to 0 by sender; ignored by receiver
is a 3 bit value which gives the number of bits in the last byte of the message
that are NOT included in the frame, i.e., the frame's data has been padded to
a full byte with this many bits
is the number of bytes, less the indicated number of pad bits, in the HDLC
frame
are the data of the HDLC frame, from immediately after the opening flag until
immediately before the closing flag or abort sequence, with zero bits that
were inserted to prevent flag simulation deleted.
Octet h, containing the T and PAD fields, is optional and is present only if the X bit is set to 1. If the X bit
is set to 0, the value of the T field is assumed to be 0 (The frame is terminated with a flag.), and the value
of the PAD field is assumed to be 0, i.e., the length of the data in the frame is an exact multiple of 8 bits.
5.7
Unformatted data format
The following figure defines the format of an unformatted data message:
Octet:
Bit:
0
h
h+1
h+2
h+3
76543210 76543 210 76543210 76543210
+--------+-----+---+--------+--------+-------|
|
.
|
|
|
| header | r .PAD| count | bytes ...
|
|
.
|
|
|
+--------+-----+---+--------+--------+--------
h+4
Figure 9 - Format of unformatted data message
Where:
header
r
PAD
count
bytes
is the common h byte header (h = 2, 3, or 4) as defined above, with:
type set to DATA_UNF
X
set to 1 if octet h is present, else 0
reserved; set to 0 by sender; ignored by receiver
is a 3 bit value which gives the number of bits in the last byte of the message
that are NOT included in the unformatted data, i.e., the unformatted data has
been padded to a full byte with this many bits
is the number of bytes, less the indicated number of pad bits, in this
unformatted data
are the unformatted data
Octet h, containing the PAD field, is optional and is present only if the X bit is set to 1. If the X bit is set to
0, the value of the PAD field is assumed to be 0, i.e., the length of the unformatted data is an exact
multiple of 8 bits.
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
5.8
Page 15 of 16
Elastic data format
The following figure defines the format of an elastic data message. Elastic data (without its header) may
also appear at the end of all other format data messages if the L bit of that message's header is set; in
that case, optional octet h is always present.
Octet:
Bit:
0
h
h+1
h+2
h+3
h+4
76543210 7 6543 210 76543210 76543210
+--------+-+----+---+--------+--------+-------|
| .
.
|
|
|
| header |C. r .PAD| count | bytes ...
|
| .
.
|
|
|
+--------+-+----+---+--------+--------+--------
Figure 10 - Format of elastic data message
Where:
header
C
r
PAD
count
bytes
is the common h byte header (h = 2, 3, or 4) as defined above, with:
type set to DATA_UNF
X
set to 1 if octet h is present, else 0
is a bit which if present and set indicates that the carrier is turned off, in
which case count is 0.
reserved; set to 0 by sender; ignored by receiver
is a 3 bit value which gives the number of bits in the last byte of the message
that are NOT included in the frame, i.e., the frame's data has been padded to
a full byte with this many bits
is the number of bytes, less the indicated number of pad bits, in the elastic
data
is the elastic data
Octet h, containing the C and PAD fields, is optional and is present only if the X bit is set to 1. If the X bit
is set to 0, the value of the C field is assumed to be 0 (The carrier is turned on.), and the value of the PAD
field is assumed to be 0, i.e., the length of the data in the frame is an exact multiple of 8 bits.
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
Telecommunications Industry Association (TIA)
August 6-9, 2002, Waltham, MA
6
Page 16 of 16
Proposed issues and resolutions
x.y0
Open
(08/02)
x.y1
Open
(08/02)
Should the procedures defined in section 4 of TR-30.1/1-02-08-107 be
used as the modem relay mode data transmission and reception
procedures of V.moip?
Should the formats defined in section 5 of TR-30.1/1-02-08-107 be
used as the modem relay mode data formats of V.moip?
3Com / CommWorks
Endpoint communications in MoIP modem relay mode
TR-30.1/1-02-08-107
TR-30.1/
1-02-08-107
TR-30.1/
1-02-08-107