atcomsystems.ca/forum Forums Wiring - Telecom Carriers - Trunks & Services T1's, CSU's and DSU's cpe t1 alarm conditions?

hello again. i'm back with more t1 questions as our pbx is at it again. we have an asterisk based pbx that uses a digium t1 card. we've been experiencing a large number of alarms all summer long during rain/thunder/lightening storms. our provider is at&t and they finally escalated our issues to their chronic group who seem to be helping but now they believe that there is an incompatibility between our equipment and theirs.
they say that our equipment does not comply with the below t1 alarm conditions.

from what digium is telling me, heir card generates an alarm after 176 continuous zeros while at&t is saying that our equipment should wait 2.5 seconds after the LOS before generating an alarm. i'm not sure what to think as i don't really understand this stuff well enough.

at&t is able to run a test where they change something on their switch which supposedly produces an errored second. this test causes our pbx to generate an alarm which at&t says should not happen as the error was only 1 second and not 2.5 sec. the digium tech that we've been working with tried increasing the number of zeros to 2500 as an engineer told him that 2500 zeros is equivalent to 2.5 sec but we still had the alarm.

hopefully this stuff makes more sense to some of you than it does to me how do other pbx's generate alarms?

below is an excerpt from ACCUNET® T1.5 SERVICE DESCRIPTION AND INTERFACE SPECIFICATION that at&t provided me with.


7.7 Conditions Causing The Initiation Of Carrier Failure Alarms

On detection of an LOS or OOF not caused by an "all ones" or AIS, a rise slope type integration process starts that declares a CFA after 2.5 seconds of continuous LOS or OOF. If the LOS or OOF is intermittent, the integration process shall decay at a slope of from 1/4 to 1/15 of the rise slope during the period when the signal is normal (i.e., for a 1/5 rise slope, 100 msec. OOF would require a 500 msec. of normal signal for an integration counter to reset to zero). The CFA is cleared when no LOS or OOF conditions occur during a variable minimum-clearing time-period which can vary from one second up to fifteen contiguous seconds, depending upon the application.

A CFA state shall cause a "yellow" signal to be transmitted upstream to the far end, via the outgoing bit stream. The "Yellow" CFA signal must be transmitted continuously until the "Red" CFA condition no longer exists. The "Yellow" CFA signal is generated by forcing the second bit to zero in all channels of a DS-1 using the Superframe format. For the Extended Superframe format, a repetitive 16-bit pattern consisting of 8 "ones" followed by 8 'zeros" (1111111100000000) is transmitted continuously for a minimum of one second, over the ESF data link.

A "Yellow" CFA state is activated at a receiving terminal after the "Yellow" signal has been detected and timed. The Yellow CFA signal must be detected in one second or less, even in the presence of a 1 x 10-3 BER. The minimum detection time is 335 msec. for the SF format and 28 msec. for the ESF format. The recommended detection/clear algorithm for the ESF format is, "a Yellow CFA shall be declared if the Yellow CFA signal pattern occurs in at least seven out of ten contiguous 16-bit pattern intervals. A Yellow CFA is cleared if the Yellow CFA signal pattern does not occur in ten contiguous 16-bit signal pattern intervals."

An AIS signal is detected by monitoring for both OOF and "all-ones" conditions. The "all-ones" condition must be detectable in the presence of a 1 x 10-3 BER. An "AIS CFA" condition is declared when both OOF and "all-ones" conditions are present at the same time. The AIS condition clears when either the OOF, or all-ones, or both conditions clear.

Since the AIS does not contain framing information, an AIS will initially activate a "Red" CFA state. If the incoming AIS signal persists after the 'Red" CFA state is activated, an "AIS CFA" state should be declared. An "AIS CFA" state is cleared when the condition which triggered the "Red" CFA state is cleared.

Are you using B8ZS or AMI for this T1? I don't see a lot of MI these days, and I don't see why an all 0's pattern from AT&T would cause your card to determine LOF as you'd have the B8ZS BPVs. I would wonder under what normal circumstance if you're running B8ZS you're going to see an absence of a pulse for (which it appears that your card is identifying as a LOF, and rightfully so) a period less than 2.5 seconds. The 1's density rule states that you must have a 1 bit for every 15 zeros, and is one of the reasons why B8ZS was created in the first place.

Also, a pulse (bit) on a T1 is a few microseconds in duration. Think of it from this perspective. The speed on a T1 is 1.544 Mbps. Megabits per second. That means for every second there is roughly 1,544,000 bits that are transmitted. That's well over 2,500.

Regardless of what the card is doing, I'd ask AT&T what planet they live on where even 1 second of dead-space all 0's is acceptable, let alone 2.5 seconds. The piece they sent you said it should wait for 2.5 seconds before putting out a CFA as a result of seeing a loss of frame or out of frame condition from something other than all 1's, but that doesn't mean that 2.5 seconds of no signal coming in is acceptable. Even if the card generates an alarm at 176 consecutive 0's, there is no reason it should ever see 176 consecutive 0's (unless it's with B8ZS and then it would see intentional bipolar violations that would come through as 1's).

It sounds like your error thresholds are too low. If you can change the threshold for that alarm to 2.5 seconds then when your systems sees this alarm for less than that it will ignore it. Like stated above 2500 zero's do not equate to 2.5 seconds. This is a qualification timer that your system recognizes a specific conditioning as an alarm, in time not bits.

matt, we're using b8zs on the t1. i'm not sure that i fully understand all the comments in your post. what are bipolar violations?

sst, unfortunately our system does not allow me to change any thresholds. i have to work with digium's support who makes changes for me. but in this case i'm not really sure that they fully understand their system well enough to make the required changes.

In regards to bipolar violations, it comes from the bipoler nature of AMI. The first 1 would be positive, the 2nd negative, the 3rd positive, etc. If two consecutive values are of the same polarity, this constitutes a bipolar violation.

With B8ZS, it transmits in the same way as AMI...John is correct in his description. The first 1 would be positive, and the next 1 in the bit stream would be put on to the line as a negative.

For example, if you were to have an oscilloscope to look at the voltage of a T1, you'd see the first 1 bit expressed as +3V, then it would drop back to 0V. If the next bit was a 0, it'd stay at 0V. When the next 1 bit came along, it would go to -3V. This is a method of transmission that eliminates what's known as DC bias.

A bipolar violation occurs when you have two bits of the same polarity in a row. So in the above example, you'd see +3V for the first 1 bit, then 0V for the 0 bit, and then +3V for the 2nd 1 bit. That would constitute a bipolar violation.

B8ZS was created to eliminate the problem of 1's density, which states that in your transmission you have to have at least one 1 bit for every 15 bits. The reason for this goes into clock recovery of the signal. The way that B8ZS works is like this. Say you have the following being transmitted:

1100000000000000000101

There is 17 consecutive 0's in that string. If it were AMI encoding, you'd see +3V, -3V, 0V 17 times in a row, then +3V, 0V, -3V. The 17 zero's is against 1's density and could potentially cause errors. B8ZS would take the same data string, take each group of 8 consecutive 0's and intentionally place bipolar violations on the 4th and 7th bit into the line that the receiver would recognize as being code for a string of zeros and not actual errors, thus not putting that many 0's on the line.

1100000000000000000101 would be transmitted as:

+3V, -3V, 0V, 0V, 0V, -3V, +3V, 0V, +3V, -3V, 0V, 0V, 0V, -3V, +3V, 0V, +3V, -3V, 0V, +3V, 0V, -3V

There are two groups of 8 consecutive 0's in the 17 0 bit string above, and a bipolar violation was intentionally placed on the 4th and 7th bit of each group so that it is expressed as 000VB0VB where V is a violation and B is a 1 bit that is not a violation.

May be easier to read like this (+ is positive, - is negative, 0 is no pulse, B is a 1 bit, V is a violation)

<font color='blue'>BB000VB0VB000VB0VB0B0B</font>
<font color='red'>+-000-+0+-000-+0+-0+0-</font>
1100000000000000000101

You will never see 2500 or even 176 consecutive physical 0's on a B8ZS encoded line (unless of course it's broken) because B8ZS will place a 1 bit on every 4th and 7th 0 in a string of 8 consecutive 0's. A 0 bit is an absence of a pulse. That setting on that card basically states that if it sees an absence of a pulse for 176 or 2500 (or whatever they set it for), then declare LOF because the line is dead. 2500 consecutive 0's with B8ZS if they were actually 0's being sent would still have the BPV pulses on the 4th and 7th frame, and the card would not put out LOF because they are framed 0's.


So lets take this from the assumption that your card is accurately reporting what it's seeing. I know that's all likely quite confusing, but in short I'd understand where AT&T is coming from in saying to wait 2.5 seconds before putting out a LOF alarm to them, however I would ask them why 2500 consecutive unframed 0's or even 176 consecutive unframed 0's are occurring to give your card cause to put a LOF alarm out. To me it'd be an issue with either the smartjack or the cabling beyond the smartjack because if the smartjack were to receive unframed 0's like that it'd declare LOF and put all 1's towards your equipment. The only way I could see that problem coming up would be if something was going open on the backside of the smartjack on the transmit pair from the smartjack towards your card. AT&T likely is putting up resistance because I'm sure they've tested to the smartjack cleanly, but that doesn't through the smartjack so if a contact or something was flakey in there it could cause problems and go open from time to time, just as a bad cable from there to your equipment could.

I'm assuming you've tried a different card from Digium and the same problem is occurring. Their card could be faulty too. If the cards have been changed out already, I'd change the cable between the smartjack and the Digium card, and have AT&T replace the smartjack as well.

What doesn't make sense is that it's during rain and thunderstorms, because normally those kinds of issues point to an outside facility issue. I can't really see that if the problem is manifesting as unframed 0's coming into your card unless it's just coincidental timing or you have cabling exposed to the elements.

It's really hard to say without being able to actually take a look and perform all the testing I'd want to.

I don't understand where the 176 consecutive zero's actually can represent a lose of framing condition. It's definitely a ones density violation, but I don't think you can know whether it is framed or not without seeing at least 579 bits.

Without the proper test equipment, it's hard to say where the fault is. I do hope that this card is set to derive it's clock from the network.