atcomsystems.ca/forum Forums Wiring - Telecom Carriers - Trunks & Services T1's, CSU's and DSU's Difficulty moving circuit to new T1 path

First off, HAPPY HOLIDAYS to everyone out there! :toast: Maybe it's the Christmas Spirit, but my brain is sure locked up hard on this one (and it's probably something real simple)..I'm moving a very old circuit to new T1 path..(moving the circuit is delayed until next Monday, and here I am for some much needed expert guidance!) :bow: :bow:

Long story short/bottom line up front: The new T1 path has been identified and tested (standard ESF/B8ZS path, tested end to end, fireberd to fireberd, with no errors). The CSUs/DSUs at both ends of the new path "lock right up" to each other fine (solid green on the link, TD, and RD of both CSU/DSUs). However, once the old circuit is applied to the new path via the EIA-530 connections on each of the CSU/DSUs, we're receiving an amber alarm on the xmit of one CSU/DSU, and an amber alarm on the receive of the other CSU/DSU. The remaining LEDs (with exception to the "ALM" LED) are still solid green.

Here's where I may be thinking too hard..I'm thinking "possibly rolled" xmit and receive pairs somewhere along the new path. No such animal that I can find..**THEN** (get this..) the customer "implies" that they "think" that this circuit "may" be a 56K DSO circuit that will be riding along this new T1 path. They're currently digging thru their old records to double check the correct configuration. As of now, no changes have been made to the new path to adjust for a 56K DSO circuit.

My question: If this turns out to indeed be a 56K DSO circuit (versus a standard 1.544M/64K DSOs), shouldn't the framing and coding across the entire new path be updated to AMI/SF? My concern is that the link lights remain solid green during the time that the circuit is applied to the B8ZS/ESF configured path. I also can't see this as any type of timing issue.

Here's a snapshot of the new path:
The local/office CSU/DSU XC 4-wire copper (using HDSL HRU and HLU cards), then over a OC3 fiber mux (4-wire DSX positions), then over to the remote CSU/DSU. In addition to testing and conditioning, the CSU/DSUs are also provide media conversion/interface for 4-wire (RJ-48C) connections from the new path to DB-25/EIA-530 connections required at both distant ends beyond the CSUs/DSUs.

Sorry to throw out this brain teaser this close to Christmas. Thank You all in advance for any help with "un-jarring" my aching brain..I think I'm just overlooking something simple..

Season's Greetings to all once again!!

Mike

Mike,

I'm not 100% sure on this as I don't really get into the cpe side of things but, if the customer has a T1 CSU/DSU on each end of the circuit, and the routers they are trying to use are for DDS (56k,64k, etc.) I don't think it will work. They would need T1 routers which would make the circuit a full T. If their plan is to use just 1 channel out of the T for the 56k and the other 23 for something else, then they would need a channel bank of some sort on each end to break out the channels.

Merry Christmas

Thank you for your quick response.

I wish I knew for certain if it is indeed a 56K DSO, to include if they only intend on using DSO #1. Hopefully I'll have more accurate information on Monday.

The CSU/DSUs do allow for local internal software configuration changes which I accessed using hyperterminal (in addition to their external dip switches which can be enabled/disabled within the software). I did notice that I can update the DSO configs from their default 64K over to 56K, which automatically sets all 24 DSOs over to 56K. However, according to the CSU's manual, the 56K configuration can only be accomplished when the CSU's T1 framing is set to "unframed". That's what has me leaning towards the new path having to be built for AMI/SF).

This is my first encounter with a "possible" 56K DSO circuit riding a standard T1 path. I'm just too used to standard 64K DSO T1s. It wouldn't take very long to update both CSU/DSUs, fiber-mux positions, and HDSL cards over to AMI/SF to test with the circuit next Monday.

Thank you again & Merry Christmas!! :thumb:

Mike -

First, Merry Christmas!

Second, we used to see a lot more AMI/SF circuits then you do now. Most of the older PBX that took T-1 Interfaces were configured for AMI. It's very possible that this is your problem. What equipment is the circuit(s) feeding?

If it's not too difficult, reset the circuit to AMI and give it a go.

Sam

Merry Christmas, Sam! :toast:

My only past experience with AMI/SF T1s was with some old "fiberflex" equipment. It doesn't take too long to reconfigure the new path's framing and coding.

As a LAST resort, I may go with using two stand-alone "Campus-RS" pairgain units (using 2 copper pairs end to end)

-Same T1 over 4-wire transport function as the HDSL & fiber mux
-Offers the RS-530 interface, required at each end
-Offers T1 "scalability" (from 56K all the way up to 2048Mbps)
-The end to end copper distance between the two locations is well within the eight mile tolerance (in extended mode)

The old path uses very old UMS2 CCAs (with DB-25/RS(EIA)-530A modules) connected over a very old fiber path.

Good morning Mike, hope Christmas was good for ya and you didn’t overwork your brain on the holiday and this little puzzle…

I’m not sure what you’ve got going on there just yet but here’s some thoughts and answers for ya.
1) You would not have a rolled Tx/Rx pair anywhere along the line or else you would not have been able to test end-to-end with the firebirds on the new path to start with.
2) DS0’s use a different RJ-48 wiring than T1. (T1 RJ-48C or X versus 56/64Kb RJ-48S, They pin-out different) That “could” possibly ‘splain why the new circuit goes yellow when you plug in to it. … but that’s such an odd thing to get mixed up. –scratching head- :scratch:
3) If this DOES turn out to be a 56 Kb circuit like Whynot posted it would have to run through a channel bank to get up on to a T1.
4) A 56 Kb circuit can run all day everyday on a B8ZF/ESF formatted T1 no worries there.… Where the corn-fusion comes in with that is a 64 Kb DS0 circuit can NOT work over AMI/SF. Sometimes people assume the 64Kb’s and B8ZF/ESF have some sort of exclusive relationship or something but that’s not the case. All sub-rate DS0’s 9.6K up to 56Kb will work just fine on B8ZF/ESF.

Bryan -

I agree with you that a rolled pair would have failed the T-Bird test but an AMI circuit running on B8ZF?

I don't know. We always formatted circuits either or. I know that our PBXs that had T-1 feeds directly in needed AMI, I don't think they would have worked on a B8ZF.

I'll go along with a 56K DS0 working on a B8ZF, but who would order (and Pay!) for a T-1 when a modem on a loop start DT line would work?

I'm as confused as Mike.

Sam

Sam, at the T1 level the error detection AMI versus B8ZS DOES have to mach from end-to-end of the circuit. … AND the coding would have to match the requirements of the CPE ports/modules…

I understood one of Mike’s questions to be more or less, “can a 56Kb circuit run over B8ZS? That’s a yes. The “DS0 payload” does not care how the T1 is checking for error detection at the DS1 level.

And yeah, that would be pretty silly to PAY for T1 but only use one 56 Kb. I’ve seen it done out of necessity several times, where a full T1 is ordered but only a fractional T1 is used but only 56K… :scratch:

Mike.

Please correct me, but from what I read in your initial log, the two T1 CSU/DSU's have achieved frame synch over the new T1 link. However what I don't understand is how the ciruit is being used based on the following quote;

"The CSUs/DSUs at both ends of the new path "lock right up" to each other fine (solid green on the link, TD, and RD of both CSU/DSUs). However, once the old circuit is applied to the new path via the EIA-530 connections on each of the CSU/DSUs, we're receiving an amber alarm on the xmit of one CSU/DSU, and an amber alarm on the receive of the other CSU/DSU. The remaining LEDs (with exception to the "ALM" LED) are still solid green."

Is the reference to the "OLD CIRCUIT" actually the terminal (CPE) equipment that is being thrown onto the new T1 circuit path at each customer location?

Are the CSU/DSU's CPE interfaces strictly DB-25 EIA-520 interfaces used for data?

What type of alarm is being reported by the CSU/DSU's? Is there a designation label to the alarm LED's mentioned?

How is the circuit being used on an end to end basis?

As for a DDS interface, as we know; DDS uses the same physical eight pin modular jack/plug as a T1 interface. However the wiring and pin outs differ substantially.

DDS uses a RJ-48S interface with the CSR transmit on pins 1&2 to Telco, CSR receive on pins 7&8.

A T1 will use a RJ-48C (Or X) interface with CSR transmit to Telco on pins 4&5, and CSR receive on pins 1&2.

If there was a screw up with DDS, the pins will not line up, plus the CSU/DSU's will never synch and report a LOS RED alarm (Loss of signal).

But as a sanity check, the mounting hardware that is used at the custmer location to house either T1 Smartjacks, HDSL HTU-R (Remote's), or 2Wire IDSL-DDS OCU-R NCTE field housing units have a selectable switch to choose either a RJ-48C/S interface. Depending on the type of circuit delivered, and remote unit installed. Most, if not all Verizon stand alone NCTE field housing units have this feature. Other Telco companies may also use the same NCTe housing supplier these days, typically Westell, or one of the companies that it merged with.

If the Telco tech, assuming it's Vz, that instaled your circuit set the NCTE mounting to the DDS option, RJ-48S, your circuit would not work.

A T1 optioned for B8ZS will pass any type of DS0 channel (56 or 64Kbs), since the B8ZS option to AMI T1 lines is designed to allow unrestricted zeros to pass over a T1.

Regarding SF/ESF. If the circuit is a dedicated link between to points, and the Telco does not perform any DS0 multiplexing, such as a channel bank or T1 MUX, then the T1 frame format can be changed, as long as each end is optioned with the same T1 frame format. As for AMI/B8ZS, changing the line code of the CPE requires the Telco to change the line code setting on their MUX/HDSL equipment to match the CPE.

Since the CSU/DSU can be accessed by a Hyperterm, VT-100 session, take a look at the alarm menu screen to try and determine what type of alarm(s) is being reported.

Regards & a belated Merry Christmas.


Bill

My strongest apologies for my delayed response in this thread.

Ops, CnG, Sam, and whynot,
Thank you all for your very valuable responses.

This was one of those situations where we were not initially provided correct information from the distant end. We were finally able to confirm the circuits as 1344Mbps (using all twenty-four 56K DSOs), and the far end connections were actually RS-530A instead of standard RS-530.

I learned quite a bit thru this ordeal; both from your responses as well as personal experience. We attempted applying RS-530 tail-circuit cables, which did allow the circuits to come in service, but still unable to pass data. Needless to say that the model of CSUs/DSUs which were provided for this effort were NOT what I would have personally recommended. I prefer working with Larscom Access-T (& Split-Ts) and TXPORT Prism 3111s. We finally decided on pulling and terminating some zip-cord, and using some existing fiber modem shelves to move the T1s from off the VC-1000 which sat in the middle of the old path. This solution also enabled us to continue using the existing RS-530A T1 connections at each end of the path.

Thank you all again for your valuable responses and assistance. :bow: :bow: