atcomsystems.ca/forum Forums Wiring - Telecom Carriers - Trunks & Services T1's, CSU's and DSU's pri and clipping

With receiving the RAIs every 3 to 5 days, I would check all connections at each possible point of failure. In agreeing with Bill, there's no 5E occurance that I can think of either that would cause RAIs.

"the circuit is delivered over an atm circuit. Can there be another clock in this configuration that might be causing these slips??"

This quote concerns me. How is this PRI delivered over an ATM circuit or did I miss something?

Regardless, the RAI signals you are seeing are T1 alarms. Is this a multi tennant building? Perhaps there's a bad MUX in the basement where the DMARC is and more than one person in the building is experiencing problems?

Just some more ideas.

2 T1s delivered and installed with the same errors/alarms? Hrmmm.....

The second circuit was connected to the system last night. It hab been brought into the building and was looped back to the CO until last night. So far there are no alarms from second circuit. The provider has told me that they are using an atm circuit to transport the PRI to the customer premise. The LEC is Qwest and is supplying the loop that is carrying the circuit. We have tried two certified cable runs from the smart jack to the csu. I am hoping that this new loop will cure the problems.
This is a single tenant building, but the network interface has many other circuits appearing but not connected at this location. ??bridge taps??

Last I checked you can't do a pri over ATM. Qwest is really telling you that? I know you can do Voice over ATM but then it has to come into a mux of some type that can take the ATM cell encapsulation and convert it. Lightstream perhaps? I'm fairly certain this is not your setup though. I've only seen lightstreams in DS3 and OCx applications.

"the circuit is delivered over an atm circuit. Can there be another clock in this configuration that might be causing these slips??"

This quote concerns me. How is this PRI delivered over an ATM circuit or did I miss something?

Regardless, the RAI signals you are seeing are T1 alarms. Is this a multi tennant building? Perhaps there's a bad MUX in the basement where the DMARC is and more than one person in the building is experiencing problems?

Just some more ideas."

You are not kidding Majestic, I have a similar problem, but how can you prove that it's a MUX going bad. I'm sure that the Telco can tel you, but thats like pulling teeth.

THX.....ARK...

I saw that there is already a resolution to this problem, but I'm posting some detailed testing suggestions, in case anyone else needs them.


Here's the thing, in order to troubleshoot, you need to take in to account the way the circuit is designed from the 5ESS to the demark. When you talk about RAI, that alarm is not coming from the 5E, its coming from one of the pieces of transport gear beyond the 5E. More than likely the circuit is built as follows:

5E--> oc carrier or ds3 --> Optical Mux (Probably a Turin T2000)--> DACS -> ds3-> mux (or HDSL Shelf)--> copper 2 wire (HDSL) or 4 wire (traditional T1) --> CO line card (Adtran HTUR, maybe an ADC card) --> f1/f2 cable pairs --> H2TUR NIU - or ADC NIU (Demark T1 shelf card) -> Demark Extension cable --> CSU --> KSU

The T1 shelf cards will generate alarms only if the CO equipment is disconnected from the shelf, so the RAI is coming from the MUX feeding the T1 Shelf, not the span itself. This indicates that your problem is somewhere from the copper mux port to the KSU. If the circuit is using ADC line cards, ask the carrier to replace them, ADC cards have a lot of problems maintaining D channel stability. Ask the carrier to check for bridge taps on the F1 and F2 pairs. At 800 feet out, this shouldn't be an issue, but if bridge taps are present, the circuit is not going to stay stable. I've seen 10 foot bridge taps knock T-1s out. Make sure the carrier is providing HDSL for transport, it's much better than traditional T1 transport.

The next step is to BERT test the circut from the CO line card to the NIU RJ48 jack. Normally, carriers will use BERT testing capabilities that are built in to the transport gear they are using in the CO, these "built in testers" have limited pattern generation capabilites, and a BERT set end to end is the only way to really test the span.

If everything passes at the NIU, move the test set to the cable entering the CSU. If something fails at the extended demark, replace the cable.

Here are the BERT's that need to be run, in this order:

1: QRSS (pronounced Qwazi) - 15 minutes

2: All zeros - 10 minutes

3: All Ones - 10 minutes

4: 1:7 or 1:8 - 10 minutes


Your carrier will be able to explain in detail what each of these tests does. Typically when a ciruit is delivered, only QRSS is run (which is a good all-around test,) but in a case of intermediate trouble, all of the listed test patterns need to be completed.

Many of the T1 cards for KSU's have built in CSUs that don't work very well. If you have one, disable and use an Adtran CSU, something like a 600R with DSX.

....Hope this helps.

Guys, I hate to break it to you-- but this means the problem is carrier related. Anybody who doesn't immediately know this by the type of alarm needs to review how signaling works.

Unless a card fails and just starts spewing out AIS, blue alarms are ALWAYS generated from upstream to downstream. They ALWAYS do this. They are generated by equipment that has a problem or isn't receiving signal. This is to notify downstream equipment that there is a problem "In the Network".

Yellow alarms (sync/clock/time) are ALWAYS generated by downstream equipment towards upstream equipment in response to receiving an AIS to signify they aren't getting time/clock- can't frame.

---

Easiest way to prove that to a carrier, other than educating them in what they should already know, is to put a hardloop on their circuit (back toward them) without telling them, and then asking them if they are still getting the AIS. If so, you've isolated the problem to their network, they can't argue with that.

See how easy this can be if you know what you are doing?

Just an update. The alarms have continued and the system backplane fried in January. This baffled Panasonic?? The system still operated 7600 series telephones, but would not run a single 7400 series set.
Power supply and all cards were OK!! Customer has not called about service interruptions or voice quality.
Read another thread about PRI coming from softswitches and having issues with this. I am receiving from an alternative provider out of a 5E switch. Panasonic stated from the beginning that they had problems with their system on 'emulated'
PRI's. Provider told us that delivery was VIA an ATM circuit, but I suspect HDSL. It is two wire at the cable entrance and four wire out of the smart jack.
Can the customer demand a four wire PRI from the provider??

No not really on the “demanding” part… Delivery of the last mile is left to the discretion of the LEC.

You could work with the Telco’s Tier 2 support (at a cost if the issue turns up to be on the end-user side) and you could have them TRY to make the T1 pipe, full 4-wire. … but I’ve honestly have to tell you, at that short of a distance there would be absolutely no reason to do make the circuit 4-wire transport other than to trouble-shoot via “parts swapping.” HDSL2 technology is field proven and very reliable.

It is still a requirement. The belief that it's only needed for drop and insert applications somehow persists.