Ei Gsm Ericsson) Bsc At

BHARAT SANCHAR NIGAM LIMITED OFFICE 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 acceptance testing 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), and b. Base station sub-system (BSS). BSC is the major functional unit of Base Station Sub-system (BSS). Other functional 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 radio connections in the system. It handles the administration of cell data, the locating algorithm and orders handovers. The BSC has interface with the BTSs over Abis links and interface with MSC over A links. This links are builtup over E1 PCMs. Ericsson BSC is implemented in an AXE-10 hardware platform. The TRC controls and supervises the transcoder resources used by the BSC. The frequency band allocated to GSM 900 System is 890-915 MHz (up-link) and 935-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 layout diagram.

3.2

Hardware Conformity Check

TECHNICAL & DEVELOPMENT CIRCLE ENGINEERING INSTRUCTION

ACCEPTANCE TESTING OF BSC IN GSM (ERICSSON MAKE)

BSC Switch hardware is built up as per site specific installation engineering document named C Module. The hardware installed can be verified as per the C module. 3.3

Cable laying and termination Cabling is done as per site specific installation engineering document i.e. C module. Cabling can be verified as per the C module.

3.4

Software Conformity Check The software details implemented on the BSC can be obtained through following 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 all blocks 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 print commands available in the switch. 1. No. of Cells can be obtained by the command. RLCRP : CELL = ALL;

[EI No.: - ELECTORNIC SWITCHING/ GSM / AT – 003] Page 2 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 BSC hardware. 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 given below [EI No.: - ELECTORNIC SWITCHING/ GSM / AT – 003] Page 3 of 17



CON; END; 3.6.7 Test of Announcement, CSR and CCD devices Announcements, Code sender receiver, CCD tests, all are carried out through SNT 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 Alarm Panel. ALLTI : ALI=0; System checks the alarm panel lamp one by one and gives beep also. When test 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. are duplicated. Redundancy can be checked by blocking one of the pair of equipment and making calls using them. The other pair functioning should also be checked. 3.7

CELL CONFIGURATION




The configuration function tries to match the available BTS equipment with the cell configuration data in the BSC and configures the BTS equipment accordingly. If there is a lack of BTS equipment, the function will try to match the available equipment with the cell configuration data in the best possible way. During operation certain data in the cell configuration may be changed by 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 new equipment 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 correct information about the channel is sent in System Information 3 message. It should 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 channel with CBCH when channel group is brought into service. Calls of different types should be made when the cell is active. Frequency hopping data should be checked. 3.7.3 Configuration (BCCH, SDCCH/8 and 6 +X *8 TCHs) The test case should verify the configuration of a non-combined control channel without CBCH when channel group is brought into service. Calls of different types should be made when the cell is active. Frequency hopping data 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 non combined control channel. A call should be active on the carrier where the CBCH should be added. The result should be that a CBCH is configured instead of one of the SDCCH / 8 subchannels and the correct information about the channel is sent in SYSTEM INFORMATION 3 message. The call should 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




on the carrier where the SDCCH /8 should be configured, but not on the same time 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 BCCH frequency, no CBCH, when channel group is brought into service. 4 TRX s are needed in the cell. Different type of calls should be made when the cell is active. 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 4 SDCCH /8 on the BCCH frequency. 4 TRXs are needed in the cell. A call should 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 the BCCH frequency in the cell. The power should be decreased first and after reconfiguration, the power should be increased again. A call should be active in the cell on the carrier for BCCH. The result should be that when the output power 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 nonBCCH frequencies in the cell. The power should first be increased and after reconfiguration the power should be decreased again. A call should be active in the cell on a carrier not used for BCCH. The result should be that when the output 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 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 the channel group is reconfigured and the radio equipment is put as spare. The active call should not be affected in case of non-hopping or synthesizer hopping configurations. 3.7.11 Reconfiguration when adding frequency The test case should verify the reconfiguration when adding a frequency when there is spare radio equipment available. A call should be active during the test. Frequency hopping data should be checked. It should be possible to make calls on the frequency that was added.




3.8

RBS 2000 TEST FUNCTIONS AND EVENT LOGGING The objective of this test is to demonstrate functions for retrieving fault information 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. The current situation of failure can be checked with a command. A Managed Object (MO) is considered to be faulty if it is blocked from its own supervision and in state NOOPER or FAIL. All fault information will also be recorded and stored in error logs for all manually de-blocked managed objects. There is also a command in the BSC to test of managed objects. Several managed objects can be specified in one command. The BSC will order the BTS to carry out the tests. Only managed objects that are manually blocked and in service can be tested. One command is provided to do a Loop test of time slots of BTS. Only time slots that are manually blocked and in service can be Loop tested.

3.8.1 Fault Information The test case will demonstrate the different ways by which fault information from 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 MO’s and subordinate MOs RXMFP :MO = RXOTG-x, FAULTY, SUBORD; 7. Retrieve fault information based on managed object type. Information about all MO’s of specified MOTY RXMFP :MOTY = RXOTS ; 8. Verify that more than one command can be issued from different terminals simultaneously. [EI No.: - ELECTORNIC SWITCHING/ GSM / AT – 003] Page 7 of 17



3.8.2 Error Log Data Retrieval Test case should demonstrate the error logs capability of storing fault information 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 necessary.

and RXB cables. Block/ Deblock

the TRX if

The TRX and RX’s 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 the TRU. The TRU will switch to local mode. An alarm will be generated LOCAL 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. [EI No.: - ELECTORNIC SWITCHING/ GSM / AT – 003] Page 8 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 are performed. 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 in the 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.




RLCRP : CELL= cell; 3.9

ALARM HANDLING AND RECOVERY The objective of this test is to demonstrate the BSC’s ability to recover after different 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. SNT’s goes ABL. Alarm: Group Switch fault. 6. Check the group switch status. TSM-A-x and TSM-B-x are ABL. 7. Print the SNT’s 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. [EI No.: - ELECTORNIC SWITCHING/ GSM / AT – 003] Page 10 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 by pulling 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 on affected 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 DIP state. 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 good speech 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.




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 all established 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 list response 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 network synchronization. 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 speech quality. 7. Disconnect the call, put back the DIP cable and repair the fault by blocking and deblocking the Network Synchronisation. DIP recovers automatically and the network Synchronization becomes working again. 8. Deblock the devices that were blocked earlier. [EI No.: - ELECTORNIC SWITCHING/ GSM / AT – 003] Page 12 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 good speech quality. 3.9.7 Large Manual Restart This test case will demonstrate the BSC’s 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 have been cleared by the Large Restart. Verify that new calls of different types can be made after completion of Large Restart. The time taken for Large Restart is approx. seven to eight minutes. 3.9.8 Manual Reload This test case will demonstrate the BSC’s ability to recover after a reload. 1. Make a system backup dump. SYBUP: FILE =file This 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 [EI No.: - ELECTORNIC SWITCHING/ GSM / AT – 003] Page 13 of 17



DPWSP ; 5. Make a system reload. SYREI:RANK = RELOAD ; 6. Check speech connection of established call. The call should have been cleared 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 the system backup on to the hard Disk of the SPG and then copy this generation on 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 the command 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 using following 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 OUTPUT EXECUTED END

3.10.2 Regeneration of System from the OD [EI No.: - ELECTORNIC SWITCHING/ GSM / AT – 003] Page 14 of 17



To test this function, first copy the software on to the hard disk. Create a file as 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= FILE2=RELFSW3,FILE=RELFSW0;

node,

IO2=OD-1,

It will take about 15 to 20 minutes to copy from OD to HDD of IOG 20C. Now start the APZ with this file. Please make sure that latest file contents are available 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 the recovery test from this file. 3.10.3 Recovery from the Backup Before proceeding further please ensure that RELFSW0 is having latest information because following command always reloads the CP from the file RELFSW0 only. SYREI :RANK = RELOAD ; The system will take between 6 to10 minutes to reload it from the HDD of IOG20C. Please check the system recovered successfully. The IO contact is restored back and all the exchange functions are normal. Check the status of CP by command DPWSP ; status of all RP by command EXRPP:RP=ALL; all RP 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 of Group 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, OSS Administration, OSS Documentation etc. GUI will be available. There will be sub menus available to each of these applications based on the features of OSS. Therefore to work in OSS Platform the following steps are to be executed. 1. Log in OSS with a valid userid/password. [EI No.: - ELECTORNIC SWITCHING/ GSM / AT – 003] Page 15 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. 2. 3. 4. 5. 6. 7. 8. 9.

Choose Alarm List Viewer from the workspace menu. Select an alarm that is not acknowledged. Alarm details are displayed in the separate ALV Expand window. The Alarm can be acknowledged (authority is required to acknowledge a Alarm) Undoing of Acknowledgement of Alarms can be done. Select one or several alarms to add comments into. Select an alarm with the severity Critical, Major or Minor. Clear the Alarm manually. (Authority is required to clear an alarm) 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 are used 1. 2. 3. 4. 5. 6. 7. 8.

Select an MSC. Select a BSC. Locate a site. A new Transceiver Group is defined. A new internal Cell may be created using an Internal Cell Profile Object. Define Frequencies for Channel Group 0. Copy the BTS software files in a directory in the local OMC file store BTS Uploading can be done using Cellular Network Activity Manager. See the downloading process by frequently updating /refreshing. If the transfer is OK it shows completed else the reason of failure can be seen in the bottom part of the CNA

3.11.3 Check of Traffic Report. [EI No.: - ELECTORNIC SWITCHING/ GSM / AT – 003] Page 16 of 17



The OMC is able to collect statistical information. With this test we shall be able 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. 3. 4. 5. 4.0

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

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 both type of BSC. Also verify that the infrastructure and the PCM media provided to the BSC are acceptance tested. Any discrepancies observed should be brought into the notice of the Installer for rectification and re-offer. Abbreviations SS BSS BTS TRC SNT CSR BCCH TCH SDCCH CBCH CP OD RBS OSS OMC

– – – – –

Switching subsystem Base Station Subsystem Base Transceiver system Transcoder Controller Switching Network Terminal Code Sender & Receiver Broadcast Control Channel Traffic Channels Stand alone Dedicated Control Channel Cell Broadcast Channel Central Processor Optical Disk Radio Base Station Operation and Support System Operation & Maintenance Centre. END

Chief General Manager Technical & Development Circle Jabalpur- 482001 [EI No.: - ELECTORNIC SWITCHING/ GSM / AT – 003] Page 17 of 17

Ei Gsm Ericsson) Bsc At

Recommend Documents