Cp Backup-bsc

8/12/2019 Cp Backup-bsc

1/17

BHARAT SANCHAR NIGAM LIMITEDOFFICE OF THE CHIEF GENERAL MANAGER, T&D CIRCLE, SANCHAR VIKAS

BHAVAN, JABALPUR-482001 (MP)

ENGINEERING INSTRUCTIONS

ACCEPTANCE TESTING OF BSC IN GSM (ERICSSON MAKE)[EI No.: - ELECTORNIC SWITCHING/GSM / AT 003]

1.0 SCOPE

This engineering instruction describes in detail the procedure of acceptancetesting of BSC in GSM of Ericsson make.

2.0 GENERAL

The GSM system is divided in two major sub-systems:

a. Switching sub-system (SS), andb. Base station sub-system (BSS).

BSC is the major functional unit of Base Station Sub-system (BSS). Otherfunctional units of BSS are:

a. Base Transceiver System (BTS).b. Transcoder controller (TRC).

The BSC controls and supervises a number of BTSs connected to it and radioconnections in the system. It handles the administration of cell data, thelocating algorithm and orders handovers. The BSC has interface with theBTSs over Abislinks and interface with MSC over A links. This links are built-up over E1 PCMs.

Ericsson BSC is implemented in an AXE-10 hardware platform. The TRCcontrols and supervises the transcoder resources used by the BSC. Thefrequency band allocated to GSM 900 System is 890-915 MHz (up-link) and935-960MHz (down link). The acceptance testing procedure is described

below.

3.0 PROCEDURE

3.1 Location, Alignment and Rigidity

The LAR of the BSC hardware can be checked with the approved layoutdiagram.

3.2 Hardware Conformity Check


2/17

TECHNICAL & DEVELOPMENT CIRCLE

ENGINEERING INSTRUCTION

ACCEPTANCE TESTING OF BSC IN GSM (ERICSSON MAKE)

[EI No.: - ELECTORNIC SWITCHING/GSM / AT 003]

Page 2 of 17

BSC Switch hardware is built up as per site specific installation engineeringdocument named C Module. The hardware installed can be verified as per theC module.

3.3 Cable laying and termination

Cabling is done as per site specific installation engineering document i.e. Cmodule. Cabling can be verified as per the C module.

3.4 Software Conformity Check

The software details implemented on the BSC can be obtained throughfollowing commands. This may be verified through approved software list.

3.4.1 Patch Administ ration

List of software patches can be obtained for an individual block or for allblocks by following commands :

PCORP : BLOCK=ALL;

PCECP : SUID = ALL;

3.4.2 Print all CP blocks

LASIP :BLOCK =ALL;

3.4.3 Print all RP blocks

LAEIP : BLOCK=ALL;

3.4.4 Print the checksum of the blocks

LAFBP: BCM =ALL;

3.4.5 Print modules loaded in IOG 20C

LASSP :SPG=0,VNODE=vnode, SYSTEM= system, SIZE=ALL;

3.5 EXCHANGE DATA VERIFICATION

Exchange Data is prepared as per exchange requirement document.Conformity to exchange requirements can be checked by various printcommands available in the switch.

1. No. of Cells can be obtained by the command.

RLCRP : CELL = ALL;


3/17





Page 3 of 17

2. No. of PCMs towards MSC.

NTCOP :SNT =ALL ; (No.of RALT can be found).

3. No. of PCM towards BTS.

NTCOP :SNT =ALL ; (No. of RBLT can be found).

4. No. of TRX available in the BSC.

RXMSP: MOTY = RXOTRX ;

5. To obtain CGI data of a Cell.

RLDEP :CELL =cell ;

3.6 SYSTEM DIAGNOSTICS AND REDUNDANCY CHECKS

Following procedures can be followed to do the Diagnostics tests on the BSChardware. Diagnostic test shall be conducted on the total hardware installed.

3.6.1 CP Diagnostics

REPCI;

Now end the diagnosis by the command REPCE.

3.6.2 CP repair check

RECCI ;

3.6.3 RP Diagnostics

REPRI;

3.6.4 RP Repair check

RECRI;

3.6.5 Switching Network Tests

NTTEI:SNT= snt;

3.6.6 Trunk Module Tests

TCTDI :DEV= dev, BNB= bnb;

Response is received from the system and then give the commands givenbelow


4/17





Page 4 of 17

CON;

END;

3.6.7 Test of Announcement, CSR and CCD devices

Announcements, Code sender receiver, CCD tests, all are carried out throughSNT test only as mentioned above in point number 3.6.5.

3.6.8 SS7 network control system tests

Deactivation of CCS links.

C7LAE : LS= ls, SLC= slc ;

An observation alarm will be issued on the alarm terminal.

Activation of CCS links.

C7LAI;

Alarm ceasing should appear on the alarm terminal.

3.6.9 System Alarm Panel Test

Following command should be given from COMMAT terminal to test the AlarmPanel.ALLTI : ALI=0;

System checks the alarm panel lamp one by one and gives beep also. Whentest is over then end the command with :

ALLTE : ALI=0;

3.6.10 Synchronization clock module Tests

GSTEI : CLM= CLM-X;

3.6.11 Redundancy Checks

The Central Processor, Regional Processors, Group Switch Planes etc. areduplicated. Redundancy can be checked by blocking one of the pair ofequipment and making calls using them. The other pair functioning shouldalso be checked.

3.7 CELL CONFIGURATION


5/17





Page 5 of 17

The configuration function tries to match the available BTS equipment with thecell configuration data in the BSC and configures the BTS equipmentaccordingly. If there is a lack of BTS equipment, the function will try to matchthe available equipment with the cell configuration data in the best possible

way. During operation certain data in the cell configuration may be changedby changing the following parameters.

a. Hopping Sequence Number.b. Adding Frequency.c. Removing Frequency.d. Output power for both BCCH carrier and other carriers.

During operation, the available BTS equipment may change either due to newequipment brought into service or equipment removed from service.

3.7.1 Configuration (BCCH+ 4 SDCCH/4 and 7 +X *8 TCHs)

A combined control channel without CBCH is configured and the correctinformation about the channel is sent in System Information 3 message. Itshould be possible to setup different types of call.

3.7.2 Configuration (BCCH + 3 SDCCH/4 + CBCH and 7 + X*8 TCHs)

The test case should verify the configuration of a combined control channelwith CBCH when channel group is brought into service. Calls of different

types should be made when the cell is active. Frequency hopping data shouldbe checked.

3.7.3 Configuration (BCCH, SDCCH/8 and 6 +X *8 TCHs)

The test case should verify the configuration of a non-combined controlchannel without CBCH when channel group is brought into service. Calls ofdifferent types should be made when the cell is active. Frequency hoppingdata should be checked.

3.7.4 Reconfiguration when adding CBCH to SDCCH/8

The test case should verify the reconfiguration when adding a CBCH to a noncombined control channel. A call should be active on the carrier where theCBCH should be added. The result should be that a CBCH is configuredinstead of one of the SDCCH / 8 subchannels and the correct informationabout the channel is sent in SYSTEM INFORMATION 3 message. The callshould not be affected.

3.7.5 Reconfiguration when adding SDCCH /8

The test case should verify the reconfiguration when adding a second

SDCCH/8 on another frequency in the channel group. A call should be active


6/17





Page 6 of 17

on the carrier where the SDCCH /8 should be configured, but not on the sametime slot. Call setup should be performed on the SDCCH/8 that was added.

3.7.6 Configuration 4SDCCH / 8 on BCCH frequency

The test case should verify the configuration of 4 SDCCH / 8 on the BCCHfrequency, no CBCH, when channel group is brought into service. 4 TRX sare needed in the cell. Different type of calls should be made when the cell isactive. It should be possible to setup different types of call.

3.7.7 Reconf iguration when adding CBCH to 4 SDCCH /8 on BCCH frequency

The test case should verify the reconfiguration when adding a CBCH to 4SDCCH /8 on the BCCH frequency. 4 TRXs are needed in the cell. A callshould be active on the carrier where the CBCHs should be added.

3.7.8 Reconf iguration when changing BSPWRB

The test case should verify the reconfiguration when changing power for theBCCH frequency in the cell. The power should be decreased first and afterreconfiguration, the power should be increased again. A call should be activein the cell on the carrier for BCCH. The result should be that when the outputpower from the BTS is changed, the call should not be affected.

3.7.9 Reconfiguration when changing BSPWRT

The test case should verify the reconfiguration when changing power for non-BCCH frequencies in the cell. The power should first be increased and afterreconfiguration the power should be decreased again. A call should be activein the cell on a carrier not used for BCCH. The result should be that when theoutput power from the BTS is changed, the call should not be affected.

3.7.10 Reconf iguration when removing frequency

The test case should verify the reconfiguration when removing a frequency,thus making the radio equipment spare. A call should be active during the test

on a carrier that is not removed. Calls on the carrier removed will be dropped.Frequency hopping data should be checked. The result should be that thechannel group is reconfigured and the radio equipment is put as spare. Theactive call should not be affected in case of non-hopping or synthesizerhopping configurations.

3.7.11 Reconf iguration when adding frequency

The test case should verify the reconfiguration when adding a frequency whenthere is spare radio equipment available. A call should be active during thetest. Frequency hopping data should be checked. It should be possible to

make calls on the frequency that was added.


7/17





Page 7 of 17

3.8 RBS 2000 TEST FUNCTIONS AND EVENT LOGGING

The objective of this test is to demonstrate functions for retrieving faultinformation from BTSs and to test managed objects (MO) in the BTS. When a

failure occurs in the BTS information about the failure is sent to the BSC. Thecurrent situation of failure can be checked with a command. A ManagedObject (MO) is considered to be faulty if it is blocked from its own supervisionand in state NOOPER or FAIL. All fault information will also be recorded andstored in error logs for all manually de-blocked managed objects. There isalso a command in the BSC to test of managed objects. Several managedobjects can be specified in one command. The BSC will order the BTS tocarry out the tests. Only managed objects that are manually blocked and inservice can be tested. One command is provided to do a Loop test of timeslots of BTS. Only time slots that are manually blocked and in service can beLoop tested.

3.8.1 Fault Information

The test case will demonstrate the different ways by which fault informationfrom BTSs can be obtained.

1. Reset the radio trans-receiver administration error log.

RXELR : MO =RXOTG-x;

2. Print alarm coordination data for the TG

RXALP : MO =RXOTG- x ;

3. Disconnect the RXA and RXB cables on the TRU.

A class 2 alarm on the MO RXOTRX is expected.

4. Retrieve fault information based on managed object.

Information about all MOs specified (MO classes TG, CF, IS, DP, TRX,TF, TX, RX OR TS) eg,

RXMFP:MO = RXOTS x-y-z ;

5. Information about faulty MOs only.

RXMFP : MO = RXOTS-x-y-z, FAULTY;

6. Information about faulty MOs and subordinate MOs

RXMFP :MO = RXOTG-x, FAULTY, SUBORD;

7. Retrieve fault information based on managed object type.

Information about all MOs of specified MOTYRXMFP :MOTY = RXOTS ;

8. Verify that more than one command can be issued from different terminalssimultaneously.


8/17





Page 8 of 17

3.8.2 Error Log Data Retrieval

Test case should demonstrate the error logs capability of storing faultinformation and how this information can be retrieved.

1. Retrieve error log data.( Fault information for one MO).

RXELP: MO = RXOTRX-x-y;

2. Retrieve error log data (Fault information for all MOs).

RXELP: MOTY = RXOTG;

3. Retrieve error log data (Fault information for MOs of specified type).

RXELP: MOTY = RXOTRX;

4. Reconnect the RXA and RXB cables. Block/ Deblock the TRX ifnecessary.

The TRX and RXs alarm should cease.

5. Retrieve error log data and fault information for the TRU.

RXELP :MO =RXOTRX-x-y;

RXMF : MO = RXOTRX x-y;

There should not be any alarms.

6. Generate a fault on the TRU by pushing the remote / local button on theTRU. The TRU will switch to local mode. An alarm will be generatedLOCAL MODE /OML FAULT.

7. Retrieve error log data and fault information for the TRU.

RXELP : MO= RXOTRX-x-y;

RXMFP : MO= RXOTRX-x-y;

3.8.3 Error Log Data Erasure

Test cases demonstrate how fault information in the error log can be erased.

1. Manual erasure of error log data for one TG.

RXELR : MO= RXOTG-x ;

2. Check that the erasure was successful.


9/17





Page 9 of 17

RXELP : MO= RXOTG-x;

3. Manual erasure of error log for all TGs.

RXELR:MOTY = RXOTG ;

3.8.4 Test of Managed objects

This test case demonstrates how manual tests of Managed objects areperformed.

1. Block the Managed object CF.

RXBLI: MO= RXOCF-x , FORCE;

2. Test the Managed object CF.

RXTEI: MO= RXOCF-x;

3. Deblock the managed object CF.

RXBLE: MO =RXOCF-x;

4. The other managed objects (IS, TF, TRX, TX, RX, TS) should be tested inthe similar manner.

3.8.5 Loop test of Timeslots

This test case demonstrates how loop test of time slots can be performed.The loop test should be initiated for 16 time slots at the same time.

1. Check blocking state of time slots

RXMSP :MO =RXOTS-x-y-0&&-7 & RXOTS x-z-0&&-7;

2. Check fault information about the time slots.

RXMFP :MO =RXOTS x-y-0&&-7 & RXOTS-x-z-0&&-7;

3. Block the MOs to be tested.

RXBLI :MO =RXOTS x-y-0&&-7 & RXOTS x-z-0&&-7,FORCE;

4. Perform the loop test of the time slots.

RXLTI :MO =RXOTS x-y-0&&-7 & RXOTS x-z-0&&-7;

5. Deblock the timeslots.

RXBLE :MO =RXOTS x-y-0&&-7 & RXOTS x-z-0&&-7;

6. Make sure that the cell fully configures.


10/17





Page 10 of 17

RLCRP : CELL= cell;

3.9 ALARM HANDLING AND RECOVERY

The objective of this test is to demonstrate the BSCs ability to recover afterdifferent failures and how it handles alarms of essential system parts.

3.9.1 DL3 Link failure

1. Print the SNT status.

NTSTP:SNT= snt ;

2. Pull out the first DL3 cable (B side).

TSM-B-x goes ABL & Alarm : Group Switch Fault

3. Print the SNT status( It should be working).

4. Check the Group Switch status.

GSSTP;

5. Pull out the second DL3 cable (A side).

TSM-A-x goes ABL. SNTs goes ABL. Alarm: Group Switch fault.

6. Check the group switch status.

TSM-A-x and TSM-B-x are ABL.

7. Print the SNTs status. It should be ABL.

8. Put back the DL3 cables.

9. Block the TSMs.

GSBLI :TSM= TSM-x -x;

10. Test the TSMs.

GSTEI:TSM= TSM-x-x ;

11. Deblock the TSMs.

GSBLE:TSM= TSM-x-x ;

12. Check the group switch status.

All TSMs should be working.


11/17





Page 11 of 17

13. Print the status of the SNT.

NTSTP:SNT= snt ;

SNT should be working.

3.9.2 DIP failure

This test case will demonstrate BSC alarm list response. Fault is simulated bypulling a DIP cable, alarm list is checked.

1. Pull the DIP cable in one ETC magazine.

DIP goes down, alarm Digital path fault supervision generated and calls onaffected SNT goes down.

2. Print the status of the DIP.

DTSTP: DIP = dip; DIP state should be ABL.

3. Put back the DIP cable. The DIP should recover automatically. Print DIPstate.

DTSTP:DIP=dip ; DIP should be working.

3.9.3 CLM failure

1. Make a call from an MS.

2. Pull out one of the looped phase transfer bus in the CLM Magazine(slave).

CLM goes down. Alarm GROUP SWITCH FAULT.

3. Check the group switch state.

GSSTP ; All TSMs , SPMs are working, one CLM is ABL.

4. Check the speech connection for the call. Call should continue with goodspeech quality.

5. Reconnect the phase transfer bus cable in the CLM magazine.

6. Block and test the CLM.

GSTEI: CLM =clm ;

7. Deblock the CLM.


12/17





Page 12 of 17

GSBLE:CLM= clm ;

8. Check the state of the group switch. All units should be working.

3.9.4 SPM failure

1. Block SPM A plane by command GSBLI.

2. The group switch stays working. All established calls remain unaffected.

3. Deblock the SPM A plane, now block SPM B plane and see that allestablished calls remain unaffected.

4. Repeat the same tests for TSM A plane and TSM B plane.

3.9.5 Network Synchronization failure

This test case will demonstrate the stability of the GSD, the BSC alarm listresponse and the redundancy of the synchronization inlets.

1. Check which DIP connection is executive.

NSSTP ;

2. Block all devices connected to this DIP.

BLODI :DEV = dev ;

3. Make a call from MS .

4. Pull the DIP cable in the ETC magazine which carries the networksynchronization.

DIP goes down. Alarm NETWORK SYNCHRONIZATION FAULT.

5. Check which DIP connection is executive

NSSTP ;

6. Check the speech connection for the call. Call continues with good speechquality.

7. Disconnect the call, put back the DIP cable and repair the fault by blockingand deblocking the Network Synchronisation.

DIP recovers automatically and the network Synchronization becomesworking again.

8. Deblock the devices that were blocked earlier.


13/17





Page 13 of 17

BLODE:DEV = dev ;

3.9.6 Small Manual Restart

1. Make a call from a MS and put the call on hold.

2. Execute the small restart.

SYREI:RANK = SMALL ;

3. The held call should not be dropped and call should continue with goodspeech quality.

3.9.7 Large Manual Restart

This test case will demonstrate the BSCs ability to recover after large restart.

1. A call is set up.

2. Check that the CP is working in parallel state

DPWSP ;

3. Make large restart

SYREI: RANK = LARGE ;

4. Check speech connection for the established call. The call should havebeen cleared by the Large Restart. Verify that new calls of different typescan be made after completion of Large Restart. The time taken for LargeRestart is approx. seven to eight minutes.

3.9.8 Manual Reload

This test case will demonstrate the BSCs ability to recover after a reload.

1. Make a system backup dump.

SYBUP: FILE =fileThis may take about an hour time.

2. Put the dump in RELFSW0

SYTUC ;

3. Make a call from a MS.

4. Check that the CP is working in parallel state


14/17





Page 14 of 17

DPWSP ;

5. Make a system reload.

SYREI:RANK = RELOAD ;

6. Check speech connection of established call. The call should have beencleared by the restart.

7. Verify that the system has recovered to parallel state.

DPWSP ;

3.10 SYSTEM BACKUP AND RESTORATION

System Backup is taken on the Optical Disk(OD). First we have to take thesystem backup on to the hard Disk of the SPG and then copy this generationon the OD.

3.10.1 Backup of the CP software

SYBUP: FILE =RELFSW2 ;

The file RELFSWx where X is a generation number must be created on the

hard disk before Backup command is issued. To create the file use thecommand

INMCT:SPG =0;

INFII : FILE= RELFSW2, RLENGTH=2048, SIZE=16, EXP=64,TYPE=SEQ, FCLASS=CMP,VOL=RELVOLUMSW;

END;

The backup should take around 60 minutes to give the result printout. After

the result printout is received, the file should be copied to OD by usingfollowing command. The copying on the OD takes about 15 to 20 minutes.

SYMTP:SPG=0,DIR=OUT, NODE=node, IO2= OD-1, FILE2=RELFSW2;

Expected results

BACKUP INFORMATION OUTPUTEXECUTEDEND

3.10.2 Regeneration of System from the OD


15/17





Page 15 of 17

To test this function, first copy the software on to the hard disk. Create a fileas given in step 3.10.1. This file will be treated as destination e.g. RELFSW3.

1. Copying from OD to HD.

SYMTP: SPG=0, DIR=IN, NODE= node, IO2=OD-1,FILE2=RELFSW3,FILE=RELFSW0;

It will take about 15 to 20 minutes to copy from OD to HDD of IOG 20C. Nowstart the APZ with this file. Please make sure that latest file contents areavailable in file RELFSW0. So we can rename this file as given below.

2. Renaming the file.

INMCT :SPG=0 ;

INFIC:FILE1 =RELFSW3, FILE2 = RELFSW0;

END ;

Now file RELFSW3 will be renamed as RELFSW0 . Proceed further for therecovery test from this file.

3.10.3 Recovery from the Backup

Before proceeding further please ensure that RELFSW0 is having latestinformation because following command always reloads the CP from the fileRELFSW0 only.

SYREI :RANK = RELOAD ;

The system will take between 6 to10 minutes to reload it from the HDD ofIOG20C. Please check the system recovered successfully. The IO contact isrestored back and all the exchange functions are normal. Check the status ofCP by command DPWSP ; status of all RP by command EXRPP:RP=ALL; allRP should be in working state. Also verify the status of EM s controlled by

these RPs by command EXEMP:EM=ALL, RP=ALL ; and finally the status ofGroup Switch as GSSTP ;

3.11 OMC-R RELATED TEST

In a standard OSS, most of the applications like Fault Management,Configuration Management, Performance Management, OSS tools, OSSAdministration, OSS Documentation etc. GUI will be available. There will besub menus available to each of these applications based on the features ofOSS. Therefore to work in OSS Platform the following steps are to beexecuted.

1. Log in OSS with a valid userid/password.


16/17





Page 16 of 17

2. Open the OSS workspace menu from the background window.

3. All possible OSS applications will be viewed in the workspace menu base on

the system configuration.

4. Select one of the applications by clicking on the workspace menu. All

possible submenus will appear automatically on the right side of the

selected application.

5. Select one from the submenus by clicking on it.

6. The requested application GUI window will appear.

7. Close the application by selecting File-> Exit option.

OSS is connected to the GSM network through X.25 and this link should be

up and running . The following tests can be performed in OSS.

3.11.1 Receipt and processing of Alarms.

1. Choose Alarm List Viewer from the workspace menu.2. Select an alarm that is not acknowledged.3. Alarm details are displayed in the separate ALV Expand window.4. The Alarm can be acknowledged (authority is required to acknowledge a

Alarm)5. Undoing of Acknowledgement of Alarms can be done.6. Select one or several alarms to add comments into.

7. Select an alarm with the severity Critical, Major or Minor.8. Clear the Alarm manually. (Authority is required to clear an alarm)9. In case of a new alarm a beep shall be heard.

3.11.2 BTS Uploading

This test means that the operator should be able to do any changes/modifications in the network from the OMC. The following procedures areused

1. Select an MSC.2. Select a BSC.3. Locate a site.4. A new Transceiver Group is defined.5. A new internal Cell may be created using an Internal Cell Profile Object.6. Define Frequencies for Channel Group 0.7. Copy the BTS software files in a directory in the local OMC file store8. BTS Uploading can be done using Cellular Network Activity Manager. See

the downloading process by frequently updating /refreshing. If the transferis OK it shows completed else the reason of failure can be seen in thebottom part of the CNA

3.11.3 Check of Traffic Report.


17/17





Page 17 of 17

The OMC is able to collect statistical information. With this test we shall beable to collect the statistics for grade of service and quality of service.Business Object Software must be installed in the OMC for generating those

reports.

1. Run Business objects

Start->Programs-> Business Objects 5.0->Business Objects

2. Log in as super user.3. Click on File option and go to dir: ericsson4. All traffic statistics reports are available in this link5. Run the reports.

4.0 CONCLUSION

The BSC of Ericsson are of two types.1. Co Located BSC.2. Remote BSC.

The Acceptance Test procedure described above should be followed for bothtype of BSC. Also verify that the infrastructure and the PCM media providedto the BSC are acceptance tested. Any discrepancies observed should bebrought into the notice of the Installer for rectification and re-offer.

Abbreviations

SS Switching subsystemBSS - Base Station SubsystemBTS - Base Transceiver systemTRC - Transcoder ControllerSNT - Switching Network TerminalCSR - Code Sender & ReceiverBCCH - Broadcast Control ChannelTCH - Traffic Channels

SDCCH Stand alone Dedicated Control ChannelCBCH Cell Broadcast ChannelCP Central ProcessorOD - Optical DiskRBS - Radio Base StationOSS - Operation and Support SystemOMC Operation & Maintenance Centre.

END

Chief General Manager

Technical & Development CircleJabalpur- 482001

Cp Backup-bsc

Documents

Transcript of Cp Backup-bsc