6.BSC Operation

Version 0 Revision 1 JTO PH II (3G) Ericsson

BSC Operations

Objectives:

Operate and supervise the BSC using pre-defined routines

and supervision command and tools analysis of the OSS

Handle practical fault-finding on BSC hardware using On-line

documentation

Issued by BRBRAITT, JABALPUR in the month of SEPT-09 6-1


SYSTEM SUPERVISION

This list of procedures is an example of what a system technician may perform as daily, weekly, monthly, quarterly and periodic supervision processes.

DAILY SUPERVISION

Run Daily BSC commands

Store each of the following printouts.

• The alarm list, ALLIP;

• CP working state, DPWSP;

• CP load data, PLLDP;

• Group switch status, GSSTP; (for MSC 810 have GDSTP).

• IOG node status, IMMCT:SPG=spg;

IMCSP;

END;

• System clock, CACLP;

• List of all blocked devices, STBSP:DETY=ALL;

• SP link data, EXSLP:SPG=spg;

• State of all SS7 link sets, C7LTP:LS=ALL;

• System error intensity, SYELP;

• Verify backup times, SYBTP;

• List of unused and continuously used devices, RASAP;

• List of unused and continuously used channels, RLVAP;

• Cell status, RLSTP:CELL=ALL;

• Cell resource data, RLCRP:CELL=ALL;

• Error log data, RXELP:MOTY=moty;



• Managed object fault information, RXMFP:MOTY=moty;

• Managed object status, RXMSP:MOTY=moty;

This can be run as a daily command file every morning, and it can be automatically run using the command :

IOCML:FILE=file, DATE=date, TIME=time, PROC=proc,DAILY, IO2=io2;

Analyze the printouts, determine any possible fault situation. Review spontaneous alarm printouts from the previous working day.

Verify the Accuracy of the System Clock

Obtain the official time from the PSTN. • Print

system date and time, CACLP;

Verify the accuracy of the system clock. To change the time, refer to the OPI System Clock, Inspect and Adjust.

Complete Daily Checklist

• Run daily BSC commands.

• Check the alarm printer AT-0 for proper operation.

• Check the alarm list several times during the day, ALLIP;

• Print system error intensity, SYELP;

• Print error log data, RXELP:MOTY=moty;

• Print managed object fault information, RXMFP:MOTY=moty;

• Print managed object status, RXMSP:MOTY=moty;

Record all events in the Exchange Journal and the applicable log. To update the Journal, refer to the OPI Keeping a Journal.


Version 0 Revision 1 JTO PH II (3G) Ericsson WEEKLY SUPERVISION

Run Weekly BSC Commands


• Check quality supervision parameters, DTQSP:DIP=ALL;

• Check fault supervision parameters, DTFSP:DIP=ALL;

• Print transaction logging conditions, IMLCT:SPG=spg;

MCTLP;

END;

• Network synchronization supervision data, NSDAP;

• Signaling terminal fault data, S7FLP:ST=ALL;

• Measurement program schedules, TRTSP:MP=0&&255;

• CLM control values, GSCVP;

• Digital paths, DTSTP:DIP=ALL;

• SP fault detection log, DISFP:SPG=spg, NODE=node;

• A-bis path status, RXAPP:MOTY=RXOTG;

• Cell supervision of logical channels, RLSLP:CELL=ALL;

• Seizure supervision of logical channels, RLVLP;

• Exchange supervision functions, RABLP:DETY=ALL;

Analyze the printouts, determine any possible fault situation.

Backup Commands in the Transaction Log

To print all the commands in the transaction log use the OPI MCS Search in the Transaction Log. Store the commands on a log file and copy to a 3.5” disk. Store for one year. (This may be done in the Network Management Center (NMC), where the file will be stored in the OSS). Update the Exchange Journal.



Perform System Backup

Evaluate whether there is enough time to perform a manual dump before the scheduled automatic dump. (If there is not enough time, deactivate the automatic dumping function, refer to the commandSYBUE ).

Use the OPI Handling of New Plant Generation.

Update the Exchange Journal.

Administer Group Switch Disturbances

• Open a log file.

• Print group switch disturbances, GSDSP;

Counters will be reset after the printout.

• Analyze the printout and compare the disturbance counters to the

previous printouts.

If high values are noted, wait at least ten minutes and repeat the procedure to determine if it is a permanent fault. If so, use the OPIConnection Performance Test of Group Switch Disturbances.

Record the trends in the Exchange Journal.

Complete Weekly Checklist

• Run the weekly BSC commands.

• Perform a system backup.

• Backup the commands in the Transaction Log.

• Determine if the Transaction Log is active, IMLCT:SPG=spg;

MCTLP;

END;

• Print supervision parameters for DIPs, DTQSP/DTFSP:DIP=ALL;



• Print the SP fault detection log, DISFP:SPG=spg, NODE=node;



• Print the state of the Digital paths, DTSTP:DIP=ALL;

• Print network synchronization supervision data, NSDAP;

• Print the CLM control values, GSCVP;

• Print the group switch disturbances, GSDSP;

• Print the A-bis path status, RXAPP:MOTY=RXOTG;

• Print the cell supervision of logical channels, RLSLP:CELL=ALL;

Record all events in the Exchange Journal and the applicable log.

MONTHLY SUPERVISION

Run Monthly BSC Commands


• Print the external alarm data, AEXLP; and ALRDP;

• Print the audit functions threshold data, AFTSP:TEST=101...

• Print the CP error record, DIRCP; (for APZ 212 20)

• Print the RP event record, DIRRP:RP=ALL;

• Print the scheduled processor load measurement program, PLSMP:MP=ALL;

• Print the size alteration store utilization, SASTP;

• Print the digital path transmission functions quality data, DTQUP:DIP=ALL;

• Verify the backup times, SYBTP;

• Print the software recovery log, SYRIP:LOG; (Note: This can

be extremely long).

• Print the seizure supervision of devices, RASSP:DETY=dety;

• Print the dynamic BTS/MS power control, RLBCP/RLPCP:CELL=ALL;



• Print the differential channel allocation, RLDCP;

Analyze the printouts, determine any possible fault situation.

Test Alarm Panels

• Locate the Alphanumeric Terminal (AT)

configured as COMMATT, IOIOP:IO1=ALL;

• If necessary, set attendance for the exchange, IODAC:ATT;

To test the alarm panel use the OPI Inspection and Repair ofScanning Interface.

• If necessary, indicate unattendance, IODAC;

Complete Monthly Checklist

• Run the monthly BSC commands.

• Perform a system backup.

• Print the software recovery log, SYRIP:LOG; (or Survey)

• Test the alarm panel, ALLTI:ALI=ali;

• Print the external alarms, AXELP; and ALRDP;

• Print the digital path transmission functions quality data, DTQUP:DIP=ALL;

• Print the CP error record, DIRCP;

• Print the RP event record, DIRRP:RP=ALL;

Record all events in the Exchange Journal and the applicable log.

QUARTERLY SUPERVISION

A quarterly supervision comprises such as Lifeline test (testing the most important CP functions, initial starts, restarts, etc.), the backup of IOG software and the backup of IOG exchange data and RP load files.



BLOCKING SUPERVISION

Blocking supervision informs operators that the number of blocked RALT devices is too high. Different alarm classes can be specified, depending on the number of blocked devices. The number of blocked devices and alarm classes are set using the commandRABLC.

RABLC: Dety= , lvb= , acl= ;

Where:

Acl Alarm Class

Dety Device Type

Lvb Limit Value Block

If the number of RALT devices is equal to or more than the Blocking Level (parameter LVB) a blocking supervision alarm is initiated. Before an alarm is initiated or prevented, the alarm indication needs to take place twice above or below the defined threshold. Measurements take place at an interval of 100 seconds – see Figure 6-2.

The command RABLP is used to print out the supervision data for the specified device types and RABLE is used to discontinue the supervision. If the parameter PERM is added, the supervision is removed permanently.

Application example of the blocking supervision:

RABLP: DETY=RALT;

This command prints out supervision data for specified device types.

RABLC:DETY=RALT,LVB=30&60&90,ACL=A3;

See the definition of this command in first paragraph

RABLI:DETY=RALT;

The command connects/reconnects a device type to blocking supervision.


Version 0 Revision 1 JTO PH II (3G) Ericsson SEIZURE SUPERVISION OF DEVICES

Seizure supervision of devices is implemented to monitor RALT devices and to identify the equipment which is continuously busy or not used during a specified time interval. Supervision can be ordered per device type and Periodic Length (PL). PL specifies the supervision period length (in hours). The RASSC command is used to set up the supervision for specified devices. Seizure supervision can be started and restarted with the command RASSI.

RASSC: dety= , pl= , acl= ;

Where:

Dety Device Type

Pl Supervision period length in hours.

ACL Alarm Class

RASSI: dety= ;

Where: Dety

Device Type

As illustrated in Figure 6-3, during the PL, RALT-36 is not seized and RALT-40 is continuously busy. Therefore, these devices cause the alarm SEIZURE SUPERVISION IN BSC. However, the alarm does not indicate which of these devices is the cause of the alarm. The RASAP command prints out the SEIZURE SUPERVISION IN BSC ALARM OBJECTS. This report provides information about the devices that have not been seized and the devices continuously seized. Devices are indicated by name and number. To prevent the alarm, the RASAR command must be entered.

Application example of the seizure supervision of devices:

RASSC:DETY=RALT,PL=1,ACL=A1;


RASSI:DETY=RALT;



RASAR:DETY=RALT;

This command is used to order alarm reset of all unapproved devices for specified device

type with seizure supervision active.

RASSE:DETY=RALT,PERM;

This command is used to disconnect seizure supervision of devices per device type.

*** ALARM 183 A1/APT "TIM TESTE"A 031106 1143 SEIZURE SUPERVISION OF DEVICES IN BSC DETYRALT

END

RASAP;

SEIZURE SUPERVISION OF DEVICES IN BSC ALARMED DEVICES CONGESTION IN DEVICE ALARM DATA LISTNEVER USED DEVICES

DEV STATE RALT-1 IDLECONTINUOUSLY BUSY DEVICES

DEV STATENONEEND

Figure Alarm Printout



To deactivate supervision, the command RASSE should be entered. If the parameter PERM is added, supervision is completely removed. If this is the case, the RASSC command with the correct parameters must be entered again. The RASSP command is used to order a printout of data for seizure supervision.

SUPERVISION OF LOGICAL CHANNEL AVAILABILITY

Supervision of logical channel availability informs the operator if traffic availability is too low on logical channels. In a cell, each type of logical channel (TCH, SDCCH, BCCH or CBCH) is checked against its alarm limit value. This limit value can be set by command, or a default value can be used.

The supervision threshold is set using command RLSLC. The parameter SCTYPE indicates the subcell type. This means that different alarm levels in the overlaid and underlaid subcells can be specified. In the overlaid cell, only CHTYPE = TCH or SDCCH is possible.

If the number of available logical channels is less than the defined threshold, the alarm SUPERVISION OF LOGICAL CHANNELS AVAILABILITY will be initiated. Each specified channel type within the cell is checked every 30 seconds. If the number of available channels is less than the preset alarm limit value (LVA) in 2.5 minute intervals, an alarm occurs. If the number of available channels is more than the LVA in a 2.5 minute interval, the alarm ceases. If an alarm continuously occurs for the same cell, the traffic load is too high and the number of channels should be increased. See Figure 6-6 for this.

Supervision is started or restarted with the command RLSLI.

RLSLI: cell= , sctype= ;

Where:

Cell Cell designation

Sctype Channel Type (BCCH, SDCCH, CBCH and TCH)



To maintain this alarm properly, the Cell Supervision of Logical Channels Availability OPI should be used.

The RLSLP command is used to print out supervision data for cells and the command RLSLE removes the alarm. If the parameter PERM is added, supervision is completely removed.

Application example of the cell supervision of logical channels

RLSLP:CELL=BTS021;

This command prints out supervision of logical channels availability data for the subcells of the specified cell(s) or the subcells of all internal cells.

RLSLC:CELL=BTS021,CHTYPE=TCH,SPV=1,LVA=13,ACL= A1;

RLSLI:CELL=BTS021;


*** ALARM 181 A1/APT "TIM TESTE"A 031106 1138 CELL LOGICAL

CHANNEL AVAILABILITY SUPERVISION CELL SCTYPE CHTYPE CHRATE

SPV BTS021 TCH FR 1

TCH FR 2 END



CALL PATH TRACING IN THE BSC

The Call Path Tracing function in the BSC is designed to provide operations staff with a picture of a call connection through the BSC. This function is initiated via the RAPTI command. One command at a time is permitted from one terminal. The function is free to be used again once the printout has started. Tracing can start from a given device or a logical channel with a specified channel type or Circuit Identity Code (CIC) as illustrated in Figure 6-6.

RAPTI: cic= , or dev= ;

Where:

CIC Circuit Identity Code (CIC)

Dev Type of device connected to the group switch

The CALL PATH TRACING IN BSC printout shows a picture of the call connection including the devices linked together, the switching data for established paths in the GS, and the used channel. A printout is also provided for unstable connections, that is, during setup, handover, or disconnection. The printout lists branch links by branch if there are more than one.


Documents

6.BSC Operation