I have a T1 plugged directly into a dialogic card configured for ami/d4 and telco states their seeing b8zs signals. They've taken the ckt down and tested clean to csu. The telco indicates that the equipment is configured for b8zs/esf but it isn't. I've reconfigured the equipment again for ami/d4. What could be causing this? (the csu was disconnected from ckt to exclude this as a possibility)
Thanks in advance.

Was the T1 itself ordered as B8ZS/ESF? If it was order and built that way, they’re seeing B8ZS ‘cause that’s what it is…

You’ll have to check the way the T1 order was placed to make sure it’s AMI/D4. That’s pretty rare now days.

Also, fair warning… I moderator will be along shortly to ask you to update your profile. They always do.

Thank you for your response.
I can confirm that the circuit was ordered as AMI/D4. There are 8 other AMI/D4 ckts working properly, terminated to the same piece of equipment but using separate dialogic cards for each T1.
This specific dialogic card defaults to using AMI/D4 and I haven't configured it for anything else. Not sure why the telco is seeing b8zs framing errors.
Telco did an intrusive test to the csu last night and it came up clean. Any ideas?
Thanks.

You might want to put a hardwire loopback for them to test to. If they see b8zs, the local card is probably misconfigured.

What problem is it causing? b8zs will pass your ami signal, but it won't work the other way around. If they are seeing a flashing b8zs on a tberd or a similar test set, that is not a b8zs signal. On a b8zs signal the b8zs light will be lit all the time. But the bottom line is what's the problem? It won't be just the lec sees b8zs.

The CO circuit is config'd B8Zs up to the NIU. CSU probably doesn't care. I have had to upgrade many sites as AMI/D4 is not supported through many of the new Muxs at satellite COs. Don't know of any carriers in my area installing/supporting AMI/D4 format any longer on the span.

If you've had them terminate to a smart jack, then you can tell by the LED's what it's seeing coming from Dialogic.

What Dialogic card are you setting up and what version of the Dialogic driver? The new DMV cards don't handle AMI by default, it takes a bit of a hack.

I'm curious as to what the solution is to this problem once they get it fixed. (If they really tell you) This just gets more complicated all the time with new technologies. My guess would be that there are several hops between the point to point and a tributary on a DCS, GR303 or fiber mux is not provisioned correctly in the process of delivery. These problems can test good to a loop from the field and still not be correct in a colo somewhere. On the other hand Rob may also be correct since I do not know the Dialogic, I'm just offering another possibility.

As a C.O. technician I deal with mis-options on an almost daily basis.

Have the telco try to run an "All 0's" test pattern to a loopback plug inserted into the smartjack from all test points in the circuit's path.

All 0's will not pass through any device optioned as AMI.

If they get a good signal back, then the circuit is optioned as ESF/B8ZS. If they cannot see the pattern come back, then some part of the circuit is optioned D4/AMI.

As far as if B8ZS can pass through an AMI mis-option and vice versa, in my 16 years as a C.O. tech, I have never seen a signal pass cleanly through a piece of mis-optioned equipment.

A B8ZS mis-option on an AMI circuit will result in Bipolar Violations to the equipment on the side facing the mis-optioned equipment.

An AMI mis-option on a B8ZS circuit will result in CRC errors being registered by the equipment AND the equipment on the opposite end will be reporting "Far End CRC Errors".

Dexman, AMI will pass through B8ZS optioned equipment, B8ZS will not pass through an AMI optioned circuit. That doesn't mean you can put AMI into a switch optioned B8ZS. It will pass through the circuit fine until it reaches the equipment at each end. His question was the lec was seeing B8ZS from his AMI optioned equipment, which if his equipment were optioned AMI they would not. They may get an intermittent B8ZS light if the zero's density is exceeded, but that is not the same as receiving B8ZS. Running all zeros to a loop back wouldn't prove anything if the lec is saying they are seeing this from his equipment. In my experience the lec was always passive, they would just pass whatever was given, the problem came when they would test, as they would test the circuit as ordered. Once you got it through their heads that they didn't care what went through them as they had nothing on the circuit to do the AMI/B8ZS optioning then you could get down to what the real trouble was. That's why I asked, what is the trouble? Because I'm seeing B8ZS is not a trouble. Now this is all from my experience when this went from an AT&T piece of equipment through to an end user. I'm not talking a lec switch to an end user. Sorry this is so long. Bottom line is we still don't know what the trouble is he was/is having.

Hey Bill,

I agree that mis-optioning will not block a signal, but the signal will not be clean in any way, shape or form. The end devices will always give plenty of indication that something is amiss.

Coding does not usually come into play for cross-connects on high-speed cards (In a Titan 5500 for example, CST to CST cross-connects require you to specify only framing).

LECs are not always passive. Run a circuit through a Fuji or a DDM-1000 and you add devices that must have some sort of coding specified.

The surest way I can think of to prove the CPE is to swap the suspect circuit and a known working circuit, and see how the problem moves.

If the problem follows the card, replace it. If the problem follows the circuit, have the LEC fix their problem.

Paul

Paul you and I could go at this for awhile. I think were both saying the same thing, but from different perspectives. Now again I'm talking AT&T to LEC, not switch to end user. All our T-3's were B8ZS..for all the issues you've stated. Very seldom would be find a DDM in the LEC misoptioned, it did happen but not often. It could easily be found with the test you mentioned, all zeros was our main one cause we were suppose to get B8ZS..you could send all 1's to verify AMI. I'd still like to know what trouble the end user was actually experiencing here to try to help on the trouble.

I agree with ya on this one. I think we are saying pretty much the same thing from a different perspective, but mis-optioned DDM-1000s happen more often (especially with Verizon New England) than many people realize.

Background static and slow data transmission can be caused by the problem being discussed.

I'll cease posting on this subject.

No need to cease posting on this. I'm sure something will come up we can both provide some insight to. Thanks for your input.
Bill

Thanks!

Like Bill, I want to hear more about what actual problem is being experienced with the circuit and equipment. Seeing B8ZS on an AMI isn’t really getting to the meat of the matter.

Dexman, Just bill,
I think you two are missing each other one finer point of ya’lls discussion.
I’m gon-na paraphrase so hope I’m not misquoting or misunderstanding either of ya…
Bill’s correct in saying that a B8ZF facility will carry an AMI circuit all day every day.
Paul is correct that a mis-optined piece of equipment can turn a circuit into a piece of steaming poo!

Customer orders a T1 service D4/AMI... There’s a real good chance it will be carried over T3 or STS-1 virtual time slot B8ZS over its entire path end-to-end. BUT equipment and ports along the way… Fiber MUX ports, HDSL etc. will still need to be optioned for AMI at the DS1 level.

If the T1 AMI order is incorrectly engineered and built the entire T1 circuit was provisioned B8ZS. Since that’s what nearly all customer T1’s are now days, it would be easy enough to do. There’s a real good chance the end-users AMI equipment will work just peachy. Also good chance no one will ever realize there’s a problem. 'Til there's a maintenance or repair issue that is.

Now let’s say that same T1 AMI order is engineered correctly and ALMOST built correctly. Let’s say just one piece (again port or HDSL card) is mis-optioned for B8ZS where everything else along that circuit path is optioned AMI as ordered. Ain’t nuthin’ gon-na work right in this scenario.

I could give further examples of B8ZS across a network, but think I'd just further confuse things, heck I'm getting confused. Thanks for the input Bryan. As you said, we are still far from the meat of the issue since we don't know what problems were being experienced.

AMI/D4 .v. B8ZS/ESF -- First off, All digital (AKA ISDN) signaling in carriers is D4. That is the fundamental frame from which all others are derived. So yes, D4 will travel on ESF. All digital signaling is fundamentally AMI. It must be, because voltage must change regularly. B8ZS is merely a method by which voltage is required to alternate more frequently, to ensure there is a voltage change to be detected by the equipment (creating the proper density of voltage changes). Will AMI/D4 run over B8ZS/ESF-- to a degree-. You'll still see errors, but you can also force traffic to a point. Beyond a certain frequency, errors mitigate the gains and performance degrades-- not ideal.

For a carrier to say they are seeing B8ZS- they need to tell you specifically what makes them think that. B8ZS will register on any signal where there is sufficiently frequent AMI occuring yielding _frames_. That is why a test set will register B8ZS on an AMI circuit-- but blinking on the test set, not solid-- because it is only seeing it every once in awhile when the pattern matches satisfactorily over a specific period of time-- but won't show frame.

PMs should be run on the DCS, because it will register errors that test-sets may not see (for example, a Centest650 may miss EXZs where the Titan 5500 will see them).

Problem should be isolated on one side of the demarc or the other, using hardloop and confirming frame. If frame is up- then whatever signal the source is sending to itself is what it should see and frame to.

If CPE sees errors when hardlooped-- I suggest they check their cable lengths, and condition of cabling. Might also try reversing the pair.

Only as a last resort do you assume there is a card problem or problem with the complex. And then of course swapping cards will show you if it's card if the problem follows a card.

Now, with all that said-- if you can run B8ZS/ESF, you want to. AMI/D4 was fine for it's day-- but truthfully that is why this protocol and frame aren't used as much, now. They were _starting points_ for the better signaling and framing algs today (B8ZS/ESF). AMI/D4 is still subject to noise interference based on the data being passed-- whereas, B8ZS/ESF was written to add more error correction inherently, and to enforce a specific AMI density ratio-- all meaning, cleaner signalling in noisier environments.

Now, regarding transporting DS1 signals over STS1 (T3), The STS1 cares not what the DS1 signal is. Its signalling and framing are on a higher order and has no impact by or to signal on a DS1 traveling on it. Neither will any piece of equipment along the path that carries that STS1 to higher-order superspans or back to STS1 even know or care what the STS1 signalling is doing.

Can the Dialogic card not be re-configured as B8ZS/ESF? Must be a fairly older dialogic.

And over a year later we still don't know what the actual trouble was. I would sure assume it's fixed by now.

Honestly, about the only thing that would cause specifically what he suggested: the pair was reversed at the CO.

Yes, I would hope it's been fixed by now. :p I replied mostly because there is too much misunderstanding in this field. I know few people in VoIP, or in the carriers who actually know how it works end-to-end.

I probably know more about transport than most of the techs in the world. I used to be one of those guys carriers would come to in order to resolve transport issues their own people couldn't figure out, from DS0 to OC-192. I am fully trained and comfortable with virtually every piece of switch-gear and endpoint you will find in a large CO, as well as every application behind it, and alarm system. I own my own TestPAD 2209 for DS1 and DS3 testing and qualification. Any field tech, ops person, or telecom analyst who professes to know ATM transport and yet has never worked with a test-set (more than just being familiar with the buttons), isn't worth a hill of beans.


I've come down from the cloud and use this knowledge privately and for much higher-paying employers now.

Hhahaha, I didn't even notice the date... Bad mod, Bad!