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

I have a Panasonic kxtda 200 with pri running about a block from the 5E CO. We have been receiving RAI alarms about every 2 to 3 days and from time to time see a sync error. This is my first install with a PRI circuit and the provider says that the problem is customer side. (We have replaced the entire system and CSU) They are now complaining about voice clipping on the inbound conversation (ok on the outbound side). And were seeing disconnects until the provider rebuilt the circuit last week.
We had this problem on start up but they changed a voice detection setting to correct it. Now they tell me that all parameters have been checked on their side and to change the pri card again. Am I missing something

2 bad PRI cards? That sounds fishy. Sounds more like a physical T1 problem than a PRI issue. Have they tested the T1 circuit to see if it's good? Have you mage sure you are slaved to them on clocking? RAI comes on when you don't have d-channel negotiaition (24th channel).

I am told that the circuit is fine. Support tell me that slips will cause this issue. I am slaved to the provider for clocking and the circuit is delivered over an atm circuit. Can there be another
clock in this configuration that might be causing these slips??

Well, I have a hard time believing you have 2 bad systems. Remember, on a PRI all it takes is channel 24 to have a problem to cause the whole thing to crap out. You wouldn't have a TBERD would you? I have to say 99.9% of every PRI issue I have ever had was ALWAYS a telco issue of some kind. Check your cables real good and the LBO on the CSU to make sure it's correct.

the csu is an adtran ace and LBO is set ot >133ft.
the smart jack patch cable to the csu patchcable length is 93 feet and certified to 5E standards. We installed a second 5E link, with a different route, and certified it at 89 feet.
I know that a bank across the street has a t1/pri that passes through the dmarc at this customers site. From there we are less than 800 feet to the Central Office where both originate. It is most likely that that cable enters the CO with the same count that it has at this location. Is there any way for another clock on another circuit to show up on our circuit.
We were told that the provider saw timing errors and our equipment is definitly not providing any clock.

I meant less than 133 feet (<) sorry

If the CO can see slips on your side, place a loopback at the demarc (smartjack,etc.) and see if they still see slips. If they do, it's on their side. If no slips, it's on your end.

Very quick hits on the T1 circuit could cause the CPE to briefly lose sync with the C.O.

Can you tell me what "RAI" stands for? (I'm not familiar with Panasonic's business telephone systems).

Remote Alarm Indicator..Means you're receiving a yellow alarm from the far end. I understand by the post that the alarms and errors quit and now have clipping. I've been waiting to see if there are still errors or alarms before I chime in on the clipping.

Just wanted to add. You say you've never installed a PRI. It's still just a T1 as far as testing the facility goes.

I'm curious about the error/alarm situation too.

I just re-read this post and withdrew my comment.
You will need a t-berd or similar to prove your case to the telco.

Good luck!

That made my post make no sense, not that any of them do.

May I ask why the Ace is in line? Why not plug the PRI right into the phone system?

According to Panasonic the Ace is an FCC requirement.

The Provider just let me know that the excel program template for programming this circuit had a voice activity detection circuit set to very sensetive parameters. When they rebuilt the circuit they were supposed to disable this feature but they now tell me that they must not have pressed !save! when they made the change. Customer now says that the voice quality is back to normal.
Is the CSU a Federal requirement or Not- that is the question.

Hrmmm strange. I'm a big fan of not adding anything into the mix that doesn't need to be there. An FCC requirement eh? Perhaps I should do a little homework. :p

Glad to hear your problem is resolved.

Fred

The CSU/DSU is a requirement. This gives the telco the capability to look both ways on the circuit when testing. Some systems have this capability built-in to the card, but if it doesn't, you have to use one.

They also help condition the circuit. I have encountered video conferencing installations without CSUs installed and the video would freeze up every 19 seconds. The conference would have to be restarted. Once we added CSU's, everything was great.

I'm only referring to not needing a CSU when it's for a voice only circuit. PRI or TDM/E&M.

I just received a call from the PRI provider and they have a new circuit to the customers location. They say that is has been running and tested for about a month and would like to switch the customer to this new circuit. We are still seeing evening RAI alarms about every 3 to 5 days, but the customer has not complained about clipping or disconnects. Does anyone know of an occurance in a 5E switch that would cause these alarms and if this solves the problem, where do I send the bill??

The 5E would not send out a yellow (RAI) to your equipment, unless it lost signal and saw a AIS (red) incoming.

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.