Motorola Buses

9
CBUS device description The CBUS device is a hardware device that carries the GCLK signal on the backplane. A specific CBUS is dedicated to a GCLK. The state of the CBUS does not follow the state of the GCLK as due to hardware redundancy a CBUS can still be used by the system even though its GCLK is OOS. The user transitions are not supported for the CBUS. Control of the CBUS is by the GCLK transitions. CBUS alarms and fault resolution procedures Overview CBUS alarms are generated when the system detects a problem with the clock signal on the CBUS. These alarms typically result from a primary failure elsewhere in the clock generation and distribution function. With the single exception shown below, on-site troubleshooting is not normally required. PBUS alarms and fault resolution procedures Overview PBUS alarms are generated for faults associated with the Processor Bus (PBUS). The PBUS is the software device representing the Motorola Cellular Advanced Processor (MCAP) bus. The MCAP transports data between the GPROCs and the following full size digital boards: MSI/RXCDR. GCLK. GDP. KSW/TSW. DRI/DRIM.

description

Describe Motorola BSC buses

Transcript of Motorola Buses

Page 1: Motorola Buses

CBUS device descriptionThe CBUS device is a hardware device that carries the GCLK signal on the backplane. A specific CBUSis dedicated to a GCLK. The state of the CBUS does not follow the state of the GCLK as due to hardwareredundancy a CBUS can still be used by the system even though its GCLK is OOS.The user transitions are not supported for the CBUS. Control of the CBUS is by the GCLK transitions.

CBUS alarms and fault resolution proceduresOverviewCBUS alarms are generated when the system detects a problem with the clock signal on the CBUS. Thesealarms typically result from a primary failure elsewhere in the clock generation and distribution function.With the single exception shown below, on-site troubleshooting is not normally required.

PBUS alarms and fault resolution proceduresOverviewPBUS alarms are generated for faults associated with the Processor Bus (PBUS). The PBUS is thesoftware device representing the Motorola Cellular Advanced Processor (MCAP) bus. The MCAPtransports data between the GPROCs and the following full size digital boards:• MSI/RXCDR.• GCLK.• GDP.• KSW/TSW.• DRI/DRIM.

PBUS: Device FailureHardwareBSC and InCell.

DescriptionThis alarm is generated if the PBUS device is placed OOS due to a fault translation triggered by backgroundsystem tests on the MCAP bus. Since the MCAP bus transports data from the GPROCs to the full size boardslisted in the preceding Overview, it is likely that the problem is in these participating modules, in the bus

Page 2: Motorola Buses

terminator cards (BTCs), or in the physical MCAP bus itself. This bus runs through the backplane.Depending on the hardware configuration, this alarm can therefore be caused by:• Failed MSI/XCDR.• Failed GCLK.• Failed GDP.• Failed KSW/TSW.• Failed DRI/DRIM.• Failed BTC(s).• Failed backplane or backplane edge connectors.

PBUS alarmsThis chapter describes the alarms and OMC-R troubleshooting procedures associatedwith the Processor Bus (PBUS) device.The PBUS is the software device representing the Motorola Cellular Advanced Processor (MCAP) bus.The MCAP transports data between the GPROCs and the following full-sized digital boards:• Multiple Serial Interface (MSI)/Transcoder (XCDR).• Generic Clock (GCLK).• Kiloport Switch (KSW).• Digital Radio Interface (DRI)/DRI extended Memory (DRIM).PBUS alarms apply only to BSC and InCell equipment.

Page 3: Motorola Buses

Serial Bus Connection Failure alarmHardwareThis alarm applies to BSC, InCell BTS, RXCDR only.

DescriptionThe BCUP Serial Bus Connection Failure alarm is generated if a Power Supply Module (PSM) fails torespond when it is polled from the Generic Processor board (GPROC), by the FMS. This indicates thatthe FMS on the GPROC is unable to communicate with the PSM board via the Serial Bus (SBUS). Thephysical path for the SBUS is through the backplane. This alarm is therefore typically due to:• Faulty PSM board installation.• Faulty PSM board.• Faulty FMS.• Faulty SBUS signal line through the backplane.• Faulty backplane edge connectors.

Before going to the siteThe OMC-R must determine:• The site number.• Cage number.• Device ID.

ProcedureProcedure 5-1 Serial Bus Connection Failure alarmThe two boards that have failed to communicate via the SBUS are the GPROC and PSM boards. Thisprocedure therefore checks that the relevant boards are properly seated. If this fails to clear the alarm,the boards are checked in turn by substitution. If the alarm persists, the backplane edge connectors areexamined and, if necessary, the physical path through the backplane is tested for continuity.

SBUS alarm and fault resolution proceduresOverviewSBUS alarms are generated for fault conditions associated with the Serial Bus (SBUS) device.An SBUS is a logical device that maps the communications path between the GPROCs andLANX cards. The communications path includes the half size cards installed in the cage. Eachcage has two SBUSs, one active and one standby. SBUS alarms apply to BSC and InCellBSU-based systems only, including ExCell and TopCell.The single SBUS alarm does not normally require on site troubleshooting

Page 4: Motorola Buses

SBUS: Device FailureHardwareBSC, InCell, including ExCell and TopCell.

DescriptionThis alarm is generated if the SBUS device fails, causing the site to reset. The SBUS runs from the GPROCto the LANX board, via the half size boards on the shelf. The SBUS is terminated on the backplane bya Bus Termination Card (BT), which keeps signals on the bus at the correct TTL level.This alarm can therefore be caused by:• LANX board not correctly inserted into the backplane.• LANX board failure.• Faulty GPROC board.• Missing BTC causing signals to go out of range.• A half size board is not correctly seated in the backplane.• Faulty half size board.• The SBUS edge connectors on the backplane are faulty.Two BTC modules must be fitted in each BSU or RXU shelf, in slot L0and slot L28, at all times. Before a BTC is removed, a BTC must thereforebe inserted into a KSW slot to maintain this requirement.

Introduction of SBUS alarmsSBUS alarmsThis chapter describes the alarm and OMC-R troubleshooting procedures associatedwith the Serial Bus (SBUS) device.An SBUS is a logical device made up of the communication path between the GPROCs and LANXcards in a cage. The communications path includes the half-sized cards installed in the cage.Each cage has two SBUS devices (one active and one redundant).

SBUS: Device FailureClearing Type: FMICSeverity Level: CriticalCategory: Equipment

DescriptionThe SBUS device failed causing the site to reset.This alarm is generated only for InCell BSU-based hardware (including ExCell and TopCell).

Additional Information fieldThere is no additional information in the output for this alarm.

Possible cause(s)The following are possible causes for this alarm:• The LANX card is not correctly inserted into the backplane.

Page 5: Motorola Buses

• The LANX card failed.• The GPROC board is faulty causing it to be incapable of communication on the SBUS.• A Bus Terminator Card (BTC) is not plugged into the backplane causing signalson the backplane to go out of the expected range.• A half-size card is not correctly plugged into the backplane.• The SBUS connections on the backplane are faulty.

TBUS

KSW device descriptionThe KSW (Kiloport Switch) is a time division digital switch that performs timeslot interchangefor the active TDM highway. It communicates with the controlling GPROC via the MCAPbus and is connected to the TDM highway.The DSW (Double Kiloport Switch) is an enhanced version of the KSW that supports double thenumber of ports and extended sub-rate switching down to 8 kbit/s. For the double rate TDM busthe bandwidth is increased to 128 Mbit/s partitioned into 2048 timeslots.All references to KSW apply equally to the DSW, unless otherwise stated.The following section describes the states and transitions for the KSW device.In the state transition diagram Figure 2-33, and in the description, INS means the purpose of the transition isto bring the device into service. When the device is in an in service state, it is currently being used by thesystem and is referred to as ACTIVE. STANDBY refers to the device that is ready for use but is not busy.OOS refers to out of service. Thus, if the device is in the OOS state, it is not being used by the system.Associated with each CAGE device is a TBUS device. A TBUS is a logical device made upof a cageTDM backplane, the KSW devices managing the CAGE.s TDM highway, and localand remote KSWX devices and DSWX devices (if they exist). Changes in a KSW state canaffect the state of the TBUS devices controlled by that KSW.Associated with each SITE is a TDM device. The active TDM device chosen is based on the statesof all the TBUS devices. Since changes in a KSW device state can affect the state of TBUS devices,changes in a KSW device state can also affect the state of the TDM devices. If TDM 0 is the activeTDM device, the A side KSW devices will be the active KSW devices (KSW devices in slot 27). IfTDM 1 is the active TDM device, the B side KSW devices will be the active KSW devices (KSWdevices in slot 1). The active KSW follows the active TDM device.

BUS device■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■■■

TBUS device descriptionA TBUS is a logical device made up of a KSW, the cage containing the TBUS, local and remote KSWXdevices (if they exist), and the fibre optic cable that interconnects the KSWX devices. Each cage has two(one active and one redundant) TBUS devices associated with it. The state of the TBUS depends upon thestate of its parent KSW, therefore a change in KSW state will also affect the corresponding TBUS.In Figure 2-51 and the state transition description, INS means the purpose of the transition is to bring thedevice into service. When the device is in an in-service state, the device is currently being used by thesystem. STANDBY refers to the device that is ready for use but not busy. OOS refers to out-of-service.Thus, if the device is in the OOS state, it is not being used by the system

TDM device

Page 6: Motorola Buses

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■■■

TDM device descriptionThe TDM (Time Division Multiplexing) bus can be viewed as an extension of the KSW. TDM isa logical device consisting of its associated TBUS devices. The TDM device is based exclusivelyon TBUS devices from one highway (A or B) within a site. A combination of TBUS devices fromboth highways A and B is not allowed, therefore TDM A consists of all TBUS A devices andTDM B consists of all TBUS B devices. Only one TDM can be active at a given time, thereforeonly TBUS A or TBUS B for a cage can be active at a given time.

TBUS alarms and fault resolution proceduresOverviewTBUS alarms are generated for faults associated with the TDM Bus (TBUS). A TBUS is a logicaldevice consisting of a KSW, the cage containing the TBUS, local and remote KSWX/DSWXcards (if used), and the fibre optic cables interconnecting the KSWX/DSWX cards. Each cagehas two TBUS devices, one active and one redundant. A TBUS may reside in the same cageas the controlling KSW or it may reside in an extended cage.When the system detects a TDM Highway fault condition related to a specific cage, a loopback test isinitiated. This loopback test is performed between the GPROCs in that cage and the active KSW. Ifthe loopback test fails, a specific TBUS loopback alarm is generated. TBUS alarms are also generatedwhen a fault occurs within the TBUS fibre optic link between cages.

The TBUS alarm is reported by a KSW, a KSWX, a GPROC, an MSI/XCDR, or aDRI, to the designated GPROC software.

MCAP BUS

The GPROC2 module contains: A Motorola MC68C040 32-bit processor operating at 33 MHz.

The LAN processors, which are the interface between the GPROC2 andthe token ring LAN. The COMM processor which, in conjunction with the TDM interfacecontroller, is the interface between the GPROC2 and the TDM highway

Communication

Page 7: Motorola Buses

The GPROC2 communicates with other full size modules via the MCAP bus,and with half size modules (and modules not on the module shelf) via the BSSserial bus.The LAPD processor and the TDM interface controller communicate via a highspeed private bus. The private bus arbiter is the interface between theMC68LC040 address/data bus and the high speed private bus.The parallel port controls output signals to the front panel LEDs, and receivesinput signals (via the register ports) from the backplane. These contain:S Shelf ID.S Slot ID.S Backplane type.S Backplane revision level.