BHARAT SANCHAR NIGAM LIMITED OFFICE OF THE CHIEF GENERAL MANAGER, T&D CIRCLE, SANCHAR VIKASBHAVAN, 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 A bis links 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 describedbelow. 3.0 PROCEDURE3.1 Location, Alignment and Rigidity The LAR of the BSC hardware can be checked with the approved layoutdiagram. 3.2 Hardware Conformity Check

2013-09-22

Page1, Total17

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 Administration 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;

2013-09-22

Page2, Total17

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

2013-09-22

Page3, Total17

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

2013-09-22

Page4, Total17

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 possibleway. 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 differenttypes 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 secondSDCCH/8 on another frequency in the channel group. A call should be active

2013-09-22

Page5, Total17

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 Reconfiguration 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 Reconfiguration 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 Reconfiguration 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 teston 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 Reconfiguration 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 tomake calls on the frequency that was added.

2013-09-22

Page6, Total17

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 afailure 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 TGRXALP : 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 MOsRXMFP :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.

2013-09-22

Page7, Total17

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.

2013-09-22

Page8, Total17

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 slotsRXMSP :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.

2013-09-22

Page9, Total17

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 Fault3. 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.

2013-09-22

Page10, Total17

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.

2013-09-22

Page11, Total17

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 executiveNSSTP ;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.

2013-09-22

Page12, Total17

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 stateDPWSP ;3. Make large restartSYREI: 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 RELFSW0SYTUC ;3. Make a call from a MS.4. Check that the CP is working in parallel state

2013-09-22

Page13, Total17

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 thehard disk before Backup command is issued. To create the file use thecommandINMCT: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. Afterthe 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 resultsBACKUP INFORMATION OUTPUTEXECUTEDEND 3.10.2 Regeneration of System from the OD

2013-09-22

Page14, Total17

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 bythese 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.

2013-09-22

Page15, Total17

2. Open the OSS workspace menu from the background window.3. All possible OSS applications will be viewed in the workspace menu base onthe system configuration.4. Select one of the applications by clicking on the workspace menu. Allpossible submenus will appear automatically on the right side of theselected 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 beup 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 aAlarm)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 areused1. 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. Seethe 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.

2013-09-22

Page16, Total17

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 thosereports.1. Run Business objectsStart->Programs-> Business Objects 5.0->Business Objects2. 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 subsystem BSS - Base Station Subsystem BTS - Base Transceiver system TRC - Transcoder Controller SNT - Switching Network Terminal CSR - Code Sender & Receiver BCCH - Broadcast Control Channel TCH - Traffic Channels SDCCH Stand alone Dedicated Control Channel CBCH Cell Broadcast Channel CP Central Processor OD - Optical Disk RBS - Radio Base Station OSS - Operation and Support System OMC Operation & Maintenance Centre. END

2013-09-22

Page17, Total17