
á
PRELIMINARY
DS3 UNI FOR ATM
XRT7245
REV. 1.03
233
2.
The received Flag Sequence octet could be just
one of many Flag Sequence octets that are
transmitted via the DS3 Transport Medium, dur-
ing idle periods between the transmission of
LAPD Messages.
The LAPD Receiver will negate the “Flag Present” bit
as soon as it has received an octet that is something
other than the “Flag Sequence” octet. At this point,
the LAPD Receiver should be receiving either octet #2
of the incoming LAPD Message, or an Abort Sequence
(e.g., a string of seven or more consecutive “1s”). If
this next set of data is an abort sequence, then the
LAPD Receiver will assert the RxAbort bit (Bit 6) of
the Rx DS3 LAPD Status Register. However, if this
next octet is Octet #2 of an incoming LAPD Message,
then the Rx DS3 LAPD Status Register will begin to
present some additional status information on this
incoming message. Each of these indicators are
presented below in sequential order.
Bit 3—RxCR Type—C/R (Command/Response)
Type
This bit-field reflects the contents of the C/R bit-field
within octet #2 of the LAPD Frame Header. When
this bit is “0” it means that this message is originating
from a customer installation. When this bit is “1” it
means that this message is originating from a net-
work terminal.
Bit 4, 5—RxLAPD Type[1, 0]—LAPD Message Type
The combination of these two bit fields indicate the
Message Type and the Message Size of the incoming
LAPD Message frame. The following table relates the
values of Bits 4 and 5 to the Incoming LAPD Message
Type/Size.
Note:
The Message Size pertains to the size of the “Infor-
mation portion” of the LAPD Message Frame (as presented
in Table 49).
Bit 3—Flag Present
The LAPD Receiver should receive another “Flag
Sequence” octet, which marks the End of the Message.
Therefore, this bit field should be asserted once again.
Bit 1—EndOfMessage—End of LAPD Message
Frame
Upon receipt of the closing “Flag Sequence” octet,
this bit-field should be asserted. The assertion of this
bit-field indicates that a LAPD Message Frame has
been completely received. Additionally, if this newly
received LAPD Message is different from the previous
message, then the LAPD Receiver will inform the local
μC/μP of the “EndOfMessage” event by generating
an interrupt.
Bit 2—RxFCSErr—Frame Check Sequence Error
Indicator
The LAPD Receiver will take the incoming LAPD
Message and compute its own version of the Frame
Check Sequence (FCS) word. Afterwards, the LAPD
Receiver will compare its computed value with that it
has received from the “Far-End” Transmitter. If these
two values match, then the LAPD Receiver will
presume that the LAPD Message has been properly
received; and the contents of the Received LAPD
Message (payload portion) will be retained at loca-
tions DEh through 135h in on-chip RAM. The LAPD
Receiver will indicate an “error-free” reception of the
LAPD Message by keeping this bit field negated
(Bit 2 = 0). However, if these two FCS values do not
match, then the received LAPD Message is corrupted;
and the user is advised not to process this erroneous
information. The LAPD Receiver will indicate errored
receipt of this message by setting this bit-field to “1”.
Note:
The Receive DS3 Framer will not generate an inter-
rupt to the local μP due to the detection of an FCS error.
Therefore, the user is advised to “validate” each and every
received LAPD message by checking this bit-field prior to
processing the LAPD message.
Removal of Stuff Bits from the Payload Portion
of the incoming LAPD Message
While the LAPD Receiver is receiving a LAPD Message,
it has the responsibility of removing all of the “0” stuff
bits from the Payload Portion of the incoming LAPD
T
ABLE
50: T
HE
R
ELATIONSHIP
BETWEEN
R
X
LAPDT
YPE
[1:0]
AND
THE
RESULTING
LAPD M
ESSAGE
TYPE
AND
SIZE
.
R
X
LAPD T
YPE
[1, 0]
M
ESSAGE
T
YPE
M
ESSAGE
S
IZE
00
Test Signal Identification
76 bytes
01
Idle Signal Identification
76 bytes
10
CL Path Identification
76 bytes
11
ITU-T Path Identification
82 bytes