You are using a T1 PRI. So a frame is 193 bits (1 octet for each one
of 24 channels, plus one framing bit). The CRC (CRC-6 on T1) is computed
on the 4632 bits contained in a superframe, which is the concatenation
of 24 frames. The CRC for a superframe is sent using 6 of the 24 occurences
of the framing bit in the next superframe. Upon reception, the received
CRC is compared with a locally computed version. End of theory.
So, each time you see a CRC error, it means that at least one bit of the
preceding superframe was garbled. The consequences depend on the nature
of the bit that has been affected:
- if it was a framing bit, synchronization will likely be maintained,
nothing else is affected ;
- if it was one of the bits of the octet in each frame carrying the D
channel, then an error is introduced in the D channel communication.
Recovery will be performed by the signaling entities when they detect
that a LAPD frame has a bad CRC (we are talking about quite *another*
CRC here) and retransmit it.
- if it was one of the bits of the octets carrying a B channel, this
channel has got a bit error. The consequences now depend on what this
channel was used for, but any recovery is the problem of the user of
that particular channel (*).
In no case does the multiplexing equipment (chip) do anything to (help)
correct the error. Actually, while it knows that an error has occured
somewhere, it does not know where...
(*) We can continue our break down ad nauseum:
- if the B channel carries an analog modem communication, a bit error
translate to analog noise. Depending on which bit is affected, the
noise is more or less severe, and can have consequences ranging from
nil to a bit error in the digital data transported by the modem, which
will probably be corrected by the V.42 (or MNP) protocol in the modem
itself - worst case with a very bad modem could be a disconnect, but
you need a really bad modem.
- if the B channel carries a sync PPP stream, the PPP frame is garbled,
but PPP itself does not pay attention, and thus the IP packet will be
delivered as-is (maybe undamaged, if the error fell in the PPP framing
itself...). Error recovery will then continue as usual in IP/TCP/UDP.
/AF
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>