If looping the CSU fails
Here are the possible meanings of a failure to loop the CSU:
- If you can't loop the CSU, this is a strong indication that there are problems somewhere in your local loop.
- If you are testing to identify the source of a circuit failure issue, and your carrier can't see the CSU to loop it, there's a break in the circuit somewhere in the area being tested.
- If you are troubleshooting for a call quality issue and you can loop the CSU (indicating that you have electrical continuity) but you receive errors, some piece of hardware within the testing area is probably dying a slow death.
Remember These tests don't indicate that your CSU is the problem; they simply indicate that something between your CSU and the CFA point is the problem. The only way to isolate the issue is to proceed to "Step 3: Looping the NIU."
If looping the CSU is successful
If your carrier can loop your CSU without a problem (for circuit failure issues) and can run test patterns to it without taking any errors (for circuit quality issues), the entire section of the circuit you are testing is clean. Looping your CSU generally causes the equipment on the other side of it, usually your multiplexer, to idle up all the channels.
Looping the CSU not only bounces the circuit signal back to your carrier, but also bounces the signal that it's sending back to your multiplexer. If your MUX doesn't idle up to the back of the looped CSU, your next course of action is to have your hardware vendor test your MUX to determine whether it's the point of failure.
Remember Looping a piece of hardware doesn't confirm that everything is wired correctly to the device being tested; it simply confirms that you have electrical continuity. See the following section to make sure your wires aren't crossed.
Making sure your crossover cables aren't straight-through cables
Dedicated circuits have designated wires to transmit and receive signals. Even if these transmit and receive wires are crossed between the NIU and the CSU, you can still loop the CSU; but in that case, the T-1 level of your circuit won't idle up. If this situation occurs, you need to check the configuration of the cable you are using to connect your NIU to your CSU.
There are two main varieties of cables in telecom, straight-through cables, and crossover cables. The wires that make up cables are numbered for easy reference, allowing you to understand why they have their specific label.
If the CSU can be looped and you have checked the cabling, but you still don't have dial tone, you need to confirm the configuration of your circuit. In spite of the fact that you may have confirmed the line coding and framing is set for B8ZS/ESF on both ends of the loop, that still doesn't prove that a piece of hardware isn't programmed incorrectly. Your carrier can validate that the line is B8ZS/ESF by sending all 0s down the circuit. If the zeros come back without errors, you can rest assured that all the hardware it's hitting is configured for B8ZS/ESF. Your carrier can run the same type of test for AMI/SF by sending down all 1s. When you've validated the line coding, you should confirm the outpulse signal and start (E&M Wink or Immediate, loopstart, or groundstart) on both your hardware and the carrier.
Remember If the CSU can be looped, and the configuration has been confirmed, the next variable to examine is the hardware on both ends of the circuit. Just as you have a multiplexer that breaks down your T-1 into 24 individual channels, your carrier has a card in its phone switch that does the same thing.
It's very unlikely that a T-1 level card in your carrier's switch will fail, but it does happen. If you have more than one circuit and only one of the circuits has been acting up, ask your carrier to reassign one of the known bad circuits to the card that is working on the good circuit. If your hardware instantly comes to life when you are on the known good card, the other card is obviously bad (that was the only variable you changed). If you make the change and your circuit is still down, your hardware is probably the source of the trouble. Move on to the following section.
In this tutorial:
- Troubleshooting Your Dedicated Circuits
- Identifying the Level of Your Problem
- Identifying circuit variables in circuits that are DS-3 or larger
- Identifying DS-1-level circuit variables
- Identifying DS-0 or individual channel issues
- Categorizing the Nature of Your Problem
- Understanding dedicated call quality issues
- Understanding circuit failure issues
- Opening a Trouble Ticket for Your Dedicated Circuit
- Letting your channels be your guide
- Remembering the first rule of troubleshooting
- Remote made busy: RMB
- Installation made busy: IMB
- Avoiding permanent IMB status
- Managing Your Dedicated Trouble Ticket
- Getting the Basics of Dedicated Outbound Troubleshooting
- Step 1: Rebooting your hardware
- Understanding your trouble ticket options
- Step 2: Intrusively testing: Looping the CSU
- If looping the CSU fails
- Using a T-1 test set
- Step 3: Looping the NIU
- Getting the scoop on loops
- Step 4: Looping to your T-1 jack
- If you can't loop the T-1 jack
- Step 5: Looping the CFA point
- Following a Dedicated Troubleshooting Shortcut
- Validating the Circuit You Are Testing
- The Basics of Dedicated Toll-Free Troubleshooting
- Step 1: Identifying a provisioning issue
- Step 2: Redialing your dedicated toll-free number
- Step 3: Validating your dedicated RespOrg
- Step 4: Validating the DNIS configuration
- Step 5: Head-to-head dedicated toll-free testing