PS EXTENSION

P7 DLDC Territory Upgrade

1. SIV2_015_DLDC_343_102 Objective 102_Territory upgrade, 2 DLDC TRXs, RLC unack mode Description The purpose of this test case is to check DLDC territory upgrade functionality in two DLDC capable TRX configuration. First territory upgrade is requested in TRX 1 to fulfill its allocation. After guard timer expiry territory upgrade is requested also in TRX 2. RLC unack mode is used. This test case will be tested by PCU2E-card. BSS21343-002, -004, -008 Required test environment settings 2 EGPRS TRXs (BCCH in TRX 1) MS 1: DLDC capable multislot class 45 CDEF = 1 TSL HMC feature is set ON RLC unack mode 2. SIV2_015_DLDC_343_104 Objective 104_Territory upgrade, 3 TRXs, unlock TRX Territory upgrade, 3 TRXs, unlock TRX Description The purpose of this test case is to check DLDC territory upgrade functionality when there is three DLDC capable TRXs in the system and some timeslots are locked so that MS is stored in deprived list. In the beginning TRX 3 is locked so that territory upgrade is requested in TRX 1 and TRX 2 and DLDC will be allocated there. Because there is locked timeslots, territory upgrade request some extra channels to upgrade in TRX 2. Then TRX 3 is unlocked but no territory upgrade to TRX 3 is requested. This test case will be tested by PCU2D - and -E-cards. BSS21343-002, -004, -008

Required test environment settings 3 EGPRS DLDC capable TRXs (BCCH in TRX 1) DLDC capable multislot class 32 MS CDEF = 2 TSL Multislot Capability Reduction for Downlink Dual Carrier = 2 HMC feature is set ON CONC_UL_TBF_FAVOR_DIR = 1 (DL is favoured) CONC_DL_TBF_FAVOR_DIR = 1 3. SIV2_015_DLDC_343_111 Objective 111_Territory upgrading, locking timeslots Territory upgrading, locking timeslots Description The purpose of this test case is to test that locking timeslot in PS territory does not cause territory upgrading even MS will be stored in deprived list. This test case will be tested by PCU2D-card. BSS21343-002, -008, -009 Required test environment settings 2 EGPRS TRXs (BCCH in TRX 1) DLDC capable multislot class 38 MS CDEF = 3 TSL HMC feature is set ON 4. SIV2_015_DLDC_343_104 Objective 104_Territory upgrade, 3 TRXs, unlock TRX Territory upgrade, 3 TRXs, unlock TRX Description The purpose of this test case is to check DLDC territory upgrade functionality when there is three DLDC capable TRXs in the system and some timeslots are locked so that MS is stored in deprived list. In the beginning TRX 3 is locked so that territory upgrade is

requested in TRX 1 and TRX 2 and DLDC will be allocated there. Because there is locked timeslots, territory upgrade request some extra channels to upgrade in TRX 2. Then TRX 3 is unlocked but no territory upgrade to TRX 3 is requested. This test case will be tested by PCU2D - and -E-cards. BSS21343-002, -004, -008 Required test environment settings 3 EGPRS DLDC capable TRXs (BCCH in TRX 1) DLDC capable multislot class 32 MS CDEF = 2 TSL Multislot Capability Reduction for Downlink Dual Carrier = 2 HMC feature is set ON CONC_UL_TBF_FAVOR_DIR = 1 (DL is favoured) CONC_DL_TBF_FAVOR_DIR = 1 5. SIV2_015_DLDC_343_109 Objective 109_Territory upgrading, default PS territory is covered by two TRXs Territory upgrading, default PS territory is covered by two TRXs Description The purpose of this test case is to test territory upgrading when default PS territory is covered by two TRXs. Default PS territory size is set to 9 timeslots so territory upgrade is requested in second TRX only. This test case will be tested by PCU2D - and -E-cards. Required test environment settings 2 EGPRS TRXs (BCCH in TRX 1) DLDC capable multislot class 12 MS CDEF = 9 TSL Multislot Capability Reduction for Downlink Dual Carrier = 1 6. SIV2_015_DLDC_343_119 Objective 119_Territory upgrade, concurrent TBFs, UL favoured Territory upgrade, concurrent TBFs, UL favoured

Description The purpose of this test case is to check amount of allocated timeslots when there is concurrent UL TBF during DL territory upgrade procedure and UL direction is favoured. This test case will be tested by PCU2D-card Required test environment settings 2 EGPRS DLDC capable TRXs (BCCH in TRX 1) MS 1: DLDC capable multislot class 34 MS 2: DLDC capable multislot class 12 Multislot Capability Reduction for Downlink Dual Carrier = 1 CDEF = 2 TSL CONC_UL_TBF_FAVOR_DIR = 0 (UL is favoured) CONC_DL_TBF_FAVOR_DIR = 0 HMC feature is set ON

7. SIV2_015_DLDC_343_122 Objective 122_Territory upgrade when limited CMAX value Territory upgrade when limited CMAX value Description The purpose of this test case is to check DLDC territory upgrade functionality in two DLDC capable TRX configuration when CMAX value has limited to 60% of max value. First territory upgrade is requested in TRX 1 to fulfill its allocation. After guard timer expiry territory upgrade is requested also in TRX 2 but not so many timeslots can be allocated that is requested because of limited CMAX. This test case will be tested by PCU2E-card. BSS21343-002, -004, -008 Required test environment settings 2 EGPRS TRXs (BCCH in TRX 1) MS 1: DLDC capable multislot class 43 CDEF = 2 TSL HMC feature is set ON CMAX = 60%

8. SIV2_015_IBNACC_083_403 Objective 403_IB-NACC activation fails, PCU reset Description The purpose is to test the failure scenario when IB-NACC feature enabling message is received during PCU2 reset. Tested with PCU2E or PCU2D. Required test environment Application version (Kk): S15 X.XX-X-> Red Hat Linux: 7.3 -> Emulators: gprs3gemulator-4.6.2 -> Required environment settings PCU2 reset; NACC feature is enabled at PCU2. IB-NACC and IS-NACC features are disabled at PCU2. Guides for execution PCU reset IB-NACC activation Check error code and alarms After PCU is up, check that IB-NACC is active alarm is cancelled. Expected results If sending of the feature state to PCU2 fails, then PUBDAT sets the existing alarm 'FAILURE IN UPDATING BSC SPECIFIC PARAMETERS TO PCU' 3261 (fail_in_pcu_bsc_update_a) with the interrupted task gup_case_t_feat_stat_upd_c (0x22) for the PCU2. DLDC LA 1. Objective Basic_data_transfer,_LA_algorithm_provides_TRX_specific_MCS_values,_RLC_Ack_ mode Description

The purpose of this test case is to verify that the Link Adaptation algorithm provides TRX specific MCS values for DL TBF operating in DLDC configuration (BTS-A, TRXz and TRX-w, z ? w) RLC Ack mode is used. Required test environment Application version (Kk): S15 mcBSC X.XX-X-> Real setup with RIM mobiles, emulators to be used as backup setup (Linux version: According to emulator package requirements) (Emulators: gprs3gemulator-X.X.0 ->) Required environment settings Test configuration 1 is active. Guides for execution Use DLDC capable MS for the following scenario. Start static DL data transfer, the DLDC configuration is allocated for MS on BTS-A. at intervals impair the radio conditions of carriers (by signal generator) (Use data block corrupter on emulator so that there are retransmissions for nacked DL RLC data blocks taking place all the time during DL data transfer). check the BEP values sent by MS. Based on BEP values Link Adaptation will result in o Individual MCS per TRX for initial transmission of RLC data blocks o Individual maximum MCS per TRX for retransmission of RLC data blocks o Let the values change periodically in a way that sometimes TRX-z has better link quality than TRX-w and sometimes other way round. Expected results PCUM uses MCSes according to Link Adaptation algorithm. DL data transfer successful. No irrelevant errors in PCUM logs. 2. Objective Creating_radio_network_(Test_configuration_1) Description The purpose of this test case is to create following radio network. RADIO NETWORK CONFIGURATION IN BSC: EP B F T R C D-CHANNEL BUSY AD OP R ET- BCCH/CBCH/ R E S O&M LINK HR FR LAC CI HOP ST STATE FREQ T PCM ERACH X F U NAME ST /GP ===================== == ====== ==== == ==== =========== = = == ===== == === === BCF-0002 FLEXI EDGE U WO 0 OM002 WO 00007 03003 BTS-0003 U WO 0 0

-/TRX-001 U WO 1 TRX-002 U WO 2 00007 03003 BTS-0004 U WO -/TRX-003 U WO 3 TRX-004 U WO 4

8 0 0 0 0 - MBCCHC 0 8 0 0 P 0 0 0

Required test environment Application version (Kk): S15 mcBSC X.XX-X-> Real setup with RIM mobiles, emulators to be used as backup setup (Linux version: According to emulator package requirements) (Emulators: gprs3gemulator-X.X.0 ->) Required environment settings Following features must be installed and set to active: GPRS and EGPRS DLDC Activated PCUMs Guides for execution Create radio network according to Test configuration information. Expected results Gb- and Abis interfaces (PDCHs) up and running. Packet Abis L1 synchronization successful on all territories. NS and BSSGP layer in unblocked state, initial BVC flow control messages sent according to territory sizes towards SGSN SI13 indicates active state of (E)GPRS in the cell. No errors in BSC or PCUM logs. PCU RESTART 1. Objective Max_duration_of_packet_data_transfer_capability_break_in_PCUM_cold_restart Description of test case: Purpose of the test case is to check that max duration of packet data transfer break in PCUM cold restart is not exceeded. PCUM shall be able to transfer data in case of a successful PCUM cold restart according to appropriate requirements.

Required test environment: Real GPRS network Real GPRS terminal equipments (MS and laptop with FTP transmission) for PS call

Preconditions: Create network configuration that has one BTS with one TRX. Establish a PS call and start packet data transfer with GPRS terminal equipments Initiate PCUM cold restart through MML

Expected results: Packet Data capability is resumed in the cell. Duration of packet data transfer break is according to requirements. 2. Objective Max_duration_of_packet_data_transfer_capability_break_in_PCUM_switchover Description of test case: Purpose of the test case is to check that max duration of packet data transfer break in PCUM switchover is not exceeded. PCUM shall be able to transfer data in case of a successful PCUM switchover according to appropriate requirements. Required test environment: Real GPRS network Real GPRS terminal equipments (MS and laptop with FTP transmission) for PS call

Preconditions: Create network configuration that has one BTS with one TRX. Establish a PS call and start packet data transfer with GPRS terminal equipments Initiate PCUM switchover through MML

Expected results: Packet Data capability is resumed in the cell. Duration of packet data transfer break is according to requirements. 3. Objective PCUM_cold_restart,_basic_case

Description of test case: Purpose of the test case is to check the basic functionality of PCUM cold restart. PCUM has the plain radio network configured but there are no active calls or call attempts during the PCUM cold restart. During the test case it will be verified that PCUM's object state changes as specified. After PCUM cold restart is completed it is verified that PCUM interfaces are up and running. The PS call is made to verify end-user service capability. Required test environment: Real GPRS network

Guides for execution: Create network configuration that has one BTS with one TRX. Restart PCUM via MML Expected results: PCUM reset scenario takes place. Abis and Gb-interfaces will recover. PS calls are successful after PCUM cold restart

4. Objective PCUM_cold_restart,_when_PS_call_ongoing Description of test case: Purpose of the test case is to check that PS data transfer is aborted when PCUM cold restart occurs. After PCUM cold restart it has to be able to make a new PS call: attach, activate PDP context(s) and transfer packet data successfully. Required test environment: Real GPRS network

Guides for execution: Create network configuration that has one BTS with one TRX. Restart PCUM via MML during active PS call Expected results:

PCUM reset scenario takes place. Abis and Gb-interfaces will recover. No hanging resources at PCUM or BSC. SI13 message indicates the loss/return of GPRS capability in the cell properly. PS calls are successful after PCUM cold restart. 5. Objective PCUM_switchover,_basic_case Description of test case: Purpose of the test case is to check the basic functionality of PCUM switchover. PCUM has the plain radio network configured but there are no active calls or call attempts during the PCUM switchover. During the test case it will be verified that PCUM's object state changes as specified. After PCUM switchover is completed it is verified that PCUM interfaces are up and running. The PS call is made to verify end-user service capability. Required test environment: Real GPRS network

Guides for execution: Create network configuration that has one BTS with one TRX. Switchover PCUM via MML Expected results: PCUM switchover scenario takes place. Abis and Gb-interfaces will recover. PS calls are successful after PCUM switchover

6. Objective PCUM_switchover,_when_PS_call_ongoing Description of test case: Purpose of the test case is to check that PS data transfer is aborted when PCUM switchover occurs. After PCUM switchover it has to be able to make a new PS call: attach, activate PDP context(s) and transfer packet data successfully. Required test environment: Real GPRS network

Guides for execution:

Create network configuration that has one BTS with one TRX. Switchover PCUM via MML during active PS call

Expected results: PCUM switchover scenario takes place. Abis and Gb-interfaces will recover. No hanging resources at PCUM or BSC. SI13 message indicates the loss/return of GPRS in capability in the cell properly. PS calls are successful after PCUM switchover.

REGRESSION
1 PCU_Test_case_for_setting_alarm_3211_two

Objective Test case for setting alarm 3211 (two dynamic NS - VC), priority 1 4.0.0

Test case for setting alarm 3211 (two dynamic NS - VLs) Description of test case Purpose of the test case is to check that alarm 3211 is correctly set. NSE has two dynamic NS - VL. Preconditions IP is connected to PCU Default static route (IP) is configured successfully SGSN - emulator and PCU are already configured to use Gb over IP (two dynamic NS-VL) Radio network is configured to emulators and BSC (e.g. Routing area, BVC, BTS, NSEI etc.) PSE is created with ZFWA command BTS is attached to NSEI (GENA=N and BCF,BTS and TRX are locked) Emulators and PCU are already up and running IPv4 configured in use at BSC and emulators Execution Expected Results 1. Modify both endpoint signaling and data weight. Sent SNS-CHANGEWEIGHT from SGSN - emulator using service primitive nsoper_sns_changeweight

1. Modification of both Endpoint signaling and data weight to different value is successful. NS -VCs weights are modified as follows: One NS -VC signaling weight is modified to 0, data is 1 The other NS -VC data weight is modified to 0, signaling is 1

BSC/PCU: 1) SGSN initiated change weight procedure is started: PCU receive SNS-CHANGEWEIGHT from SGSN with new weight values BSSGP/NS/RELAY sends SNS-ACK to SGSN

Emulators: 1) One NS - VL is WO - EX after modification Collected information during case in order to check items mentioned above are: - Alarms in BSC - GBADMI (42D), PDM,PFM,BSSGP,RELAY and NS (MAINLY LOG LEVELS 1:2:3:4:5:6:11) - New service terminal information (for Gb over IP) - Emulators logs - Nethawk - log - MML - outputs (like ZQRS, ZEEI, ZFWI and ZEQO) 2. Delete one of the Endpoints (the one, which data weight is 1). Sent SNS-DELETE from SGSN - emulator using service primitive nsoper_sns_delete 1. Deletion of one Endpoint (the one, which data weight is 1) is successful. BSC/PCU: 1) Delete one Endpoint with help of SNS-DELETE 2) Successful Endpoint deletion in PCU: SGSN sends SNS-DELETE to PCU (for one Endpoint) BSSGP/NS/RELAY sends SNS-ACK to SGSN

3) Alarm 3211 is set, because last remote IP Enndpoint is deleted. Emulators:

1) NSE is not available Collected information during case in order to check items mentioned above are: - Alarms in BSC - GBADMI (42D), PDM,PFM,BSSGP,RELAY and NS (MAINLY LOG LEVELS 1:2:3:4:5:6:11) - New service terminal information (for Gb over IP) - Emulators logs - Nethawk - log - MML - outputs (like ZQRS, ZEEI, ZFWI and ZEQO) 2 PCU2_EGPRS_TBF_est

Objective UL & DL TBF establishment and release (EGPRS) 2.0.0 1. Description Purpose of this test case is to verify that EGPRS UL & DL TBF establishments and releases work as specified. 2. Required test environment Radio network created. 3. Required environment settings EGPRS territory exists and Abis L1 synchronization steady. 4. Guides for execution Perform UL & DL EGPRS TBF establishment (using two phase access) and release with help of Byteslinger (UDP traffic). 5. Expected results EGPRS UL & DL TBF establishments and releases work as specified. 6. Pass/Fail criteria for evaluating results 3 PCU2_GPRS_TBF_estab

Objective UL & DL TBF establishment and release (GPRS) 2.0.0 1. Description Purpose of this test case is to verify that GPRS UL & DL TBF establishments and releases work as specified. 2. Required test environment Radio network created. 3. Required environment settings GPRS territory exists and Abis L1 synchronization steady. 4. Guides for execution

Perform UL & DL TBF establishment and release by Byteslinger (UDP traffic). 5. Expected results GPRS UL & DL TBF establishments and releases work as specified. 6. Pass/Fail criteria for evaluating results 4 EDA_one_phase_nRT_EDA_capab_and no_EDA_c

Objective UL TBF one phase access nRT, 1 GPRS and 1 EDA capable GPRS MS in 1 TRX 3.0.0 Description The purpose of this test case is to check that when there is one EDA capable GPRS MS and one GPRS MS without EDA capability in one TRX system, EDA allocation is working as specified in case that there is enough free timeslots to get allocation possible. EDA capability is optional. Extended Dynamic Allocation&High Multislot Classes FDD 2.0 chap.5.3.1.1. Extended Dynamic Allocation&High Multislot Classes RS 1.4.0 BSS20089-007. Required test environment Application version (Kk): S12 X.XX-X-> Red Hat Linux: 7.3 -> Emulators: gprs3gemulator-2.4.0 -> Required environment settings 1 BTS with CCCH TRX. EDA licence is installed in the system. EDA feature is set on. CONC_UL_TBF_FAVOR_DIR parameter value 0D. In the beginning there is empty territory. Guides for execution 1. Check that MS1 MS class is e.g.11 (EDA capability is optional). Check also that there is enough free timeslots (at least 3 for both MS's). 2. 3. Start data transferring by MS1. Start data transferring by MS2.

4. Check from Packet Uplink Assignment messages that MS1 MAC mode has changed to EDA.

Expected results 1.&2.&3. Data transferring succeeds and timeslots are allocated correctly. There are three timeslots allocated to MS1 and one or two timeslots allocated to MS2. 4. MAC mode in MS1 has changed to EDA.

PS TEST CASES
1. IT2814228033 Objective Cell reselections (including RA&LA changes) with several DLDC MSs 1.0.0 Description The purpose of this test case is to verify that data transfer works using DLDC when DLDC capable MS is in DLDC enabled cell and also cell reselections work to and from DLDC enabled cell when several DLDC capable MSs are used Test Environment DLDC license is active In radio network there is one BTS with at least 2 TRXs, DCENA and PUTD parameters are ?Y' for this BTS. BB hopping is in use in this BTS. Also in radio network there is another cell which does not have DLDC enabled.( DCENA=N and PUTD=Y) DLDC capable MSs Test execution Start FTP download using DLDC capable MS in DLDC enabled BTS. Perform cell reselection to non-DLDC BTS. Verify that throughput is acceptable in both BTSs. Repeat cell change several times. Move one of the BTSs to different routing area. Perform cell reselection to non-DLDC BTS. Verify that throughput is acceptable in both BTSs. Repeat cell change several times. Move one of the BTSs to different location area and set NMO to 2. Perform cell reselection to non-DLDC BTS. Verify that throughput is acceptable in both BTSs. Repeat cell change several times. 2. IT2814228031 Objective DLDC with BB hopping 1.0.0 Description

The purpose of this test case is to verify that data transfer works using DLDC when BB hopping is used. Test Environment DLDC license is active In radio network there is one BTS with at least 2 TRXs, DCENA and PUTD parameters are ?Y' for this BTS. BB hopping is in use in this BTS. DLDC capable MS Test execution Start FTP download using DLDC capable MS in DLDC enabled BTS. Verify that throughput is in acceptable level. Factors affecting throughput multislot class of MS DSP capacity of PCU if PCU2-D/U card is in use MCS in use if link adaptation is not used Gb interface speed (if it is inadequiate) EDAP size 3. IT2814228026 Objective Several MSs in DLDC connections + several non-DLDC MSs transferring data - 3 TRXs in BTS 1.0.0 Description The purpose of this test case is to verify that data transfer works when there are DLDC MSs and non-DLDC MSs using the same BTS. Test Environment DLDC license is active In radio network there is one BTS with 3 TRXs, DCENA and PUTD parameters are ? Y' for this BTS. DLDC capable MSs + non-DLDC capable MSs Test execution Start FTP download using DLDC capable MS in DLDC enabled BTS. Verify that throughput of all MSs is as expected. Verify that timeslot allocation is as expected. 4. IT0281155061 Objective TBF reallocation, GPRS-CS1-CS2 - GPRS-CS1-CS4 1.0.0

Required test environment: Real GPRS network with EGPRS capable UltraSite BTS GPRS-class 10 MS Prerequisite: Dynamic Abis and CS3&CS4 features activated Create network as described below: Create segment which is as described below SEG1 o BTS1 1800 (Ultra Site) TRX1 (BCCH) o BTS2 900 (Ultra Site) TRX2 GPRS-CS1-CS2 GPRS-CS1-CS4

Define maximum amount of Dedicated GPRS channels to TRXs (ZEQV:BTS=<bts_id>:CDEF=100,CDED=100;) Enable GPRS in segment (ZEQV:SEG=<seg_id>:GENA=Y;) Unlock both BTS&apos;s (ZEQS:BTS=<bts_id>:U;) Start GPRS data transfer on BTS1 Test execution: Adjust power control parameters so that TBF reallocation to BTS2 is possible (ZEUG:SEG=<seg_id>:PMAX1=<X dB>,PMAX2=<Y db>;) After reallocation check that TBF is using CS3/CS4 Adjust power control parameters so that TBF reallocation to BTS1 is possible (ZEUG:SEG=<seg_id>:PMAX1=<Y dB>,PMAX2=<X db>;) Expected results: Reallocation to BTS 2 is successful. Data transfer successful with correct CS. Reallocation to BTS 1 doesn&apos;t happen. Data transfer continues on BTS2. 5. IT0281321018 Objective DL TBF cell reselection (super area[CS3&4] -- normal area[egprs]) 1.0.0

Requirement reference: Purpose: To verify that cell reselections are possible in following inter-DSP configuration. Required test environment: Real GPRS network with EGPRS capable Flexi EDGE BTS Nethawk analyzer SOFI 06 simulator Prerequisite: Create following network configuration. SEG1 o BTS1 900 (Flexi EDGE) GPRS-CS1-CS4 N-TRX1 (BCCH) DAP1 E-TRX2 (ERACH + SDCCH + 3 EGTCH) S-TRX3 (ERACH + SDCCH + 3 EGTCH) SEG2 o BTS2 900 (Flexi EDGE) EGPRS-CS1-CS2 N-TRX4 (BCCH) DAP2 E-TRX5 (ERACH + SDCCH + 3 EGTCH) S-TRX6 (ERACH + SDCCH + 3 EGTCH) Create simulation where the mobiles are statically in the super area. (SOFI 06 attached to BTS1) Define BTS 2 to be neighbor cell to BTS 1 (ZEAC:BTS=<bts_id>:ABTS=<bts_id>;) Define BTS 1 to be neighbor cell to BTS 2 (ZEAC:BTS=<bts_id>:ABTS=<bts_id>;) Define BTS2 PMAX2 parameter to its highest (ZEUG:BTS=<bts_id>:PMAX2=30;) Define BTS1 PMAX2 parameter to its lowest (ZEUG:BTS=<bts_id>:PMAX2=0;) Start EGPRS a long downlink data transfer on BTS1 Test execution: Adjust power control parameters in both BTSs so that cell reselection to BTS2 is possible (ZEUG:BTS=<bts_id>:PMAX=<X dB>;) After a while adjust power control parameters in both BTSs so that cell reselection to BTS1 is possible (ZEUG:BTS=<bts_id>:PMAX=<X dB>;) Expected results:

Cell reselection to BTS 2 is successful. Data transfer is successful and defined MCS is used. Cell reselection to BTS 1 is successful. Data transfer is successful and defined CS is used. Inter-DSP allocations are done successfully. 6. IT0281321016 Objective DL TBF reallocation between all service areas (egprs) 1.0.0 Requirement reference: BSS21270-802 Reallocations between the service areas are triggered on the basis of TA evolution, BSS21270-904 TBF reallocation from the super extended service area to the extended service area UC Purpose: To verify that EGPRS downlink data transfer is working correctly, when mobile is performing reallocations between all three service areas. Required test environment: Real GPRS network with EGPRS capable Flexi EDGE BTS Nethawk analyzer SOFI 06 simulator Prerequisite: Create following network configuration. SEG1 o BTS1 900 (Flexi EDGE) EGPRS-CS1-CS2 N-TRX1 (BCCH) E-TRX2 (ERACH + SDCCH + 3 EGTCH) S-TRX3 (ERACH + SDCCH + 3 EGTCH) Create a simulation, where the mobile is traveling in a loop starting from outer part of normal area and ending at inner part of super area. Test execution: Start a long downlink data transfer. Start the simulation.

Check counter 72231 TBF service area reallocations and failed TBF service area reallocations values for all areas. Expected results: Long downlink data transfer is successful. Counters values are updated as defined in requirement specification. 7. IT0281321028 Objective MCMU switchover during data transfer in super area 1.0.0 Requirement reference: Purpose: To verify that after MCMU switchover data transfer is possible in super area. Required test environment: Real GPRS network with EGPRS capable Flexi EDGE BTS Nethawk analyzer SOFI 06 simulator Prerequisite: Test execution: Create following network configuration. SEG1 o BTS1 900 (Flexi EDGE) EGPRS-CS1-CS2 N-TRX1 (BCCH) E-TRX2 (ERACH + SDCCH + 4 EGTCH) S-TRX3 (ERACH + SDCCH + 4 EGTCH) Enable GPRS and EGPRS (ZEQV:BTS=<bts_id>:GENA=Y,EGENA=Y;) Start downlink data transfer with two mobiles in super area. During data transfer initiate a MCMU switchover. Restart data transfers when RNW is back up . Expected results:

Territory creation is successful Data transfers are executed successfully. After MCMU switchover it is possible to start data transfers again. 8. IT0281157202 Objective Coverage based ISNCCR from GSM cell to WCDMA cell 1.0.0 Test Purpose: To verify that Intersystem NCCR to WCDMA FDD cell when GSM coverage is not adequate. Required test environment: Two cells are created in the BSC "cell1" with GPRS enabled and PBCCH and "cell2" with WCDMA FDD. The MS should be Release 4+ (GPRS and WCDMA FDD capable). Prerequisite: The "Cell1" is the serving cell for MS and "Cell2" is the neighbouring cell. Parameter WCDMA FDD NCCR enabled is set on. Parameter WCDMA FDD NCCR preferred is set to value off. Parameter NCCR Control mode = 4 Test execution: 1. Establish a DL TBF so that SGSN can send the data to MS. 2. Increase the power of "Cell2" and decrease the power of "Cell1", such that the coverage of the "cell1" is not adequate. 3. Trigger DL-UNIDATA from SGSN with optional Service UTRAN CCO IE (Network initiated cell change order procedure to UTRAN should not be performed). 4. Use the service terminal (command DSEGTBF in PCU2) to verify that TBF is established in the new cell. Expected results: 1. DL TBF is established and MS receives DL data from SGSN. 2. PACKET MEASUREMENT REPORT is received at PCU 3. PCU sends PACKET CELL CHANGE ORDER to MS. MS sends Cell Update to SGSN. SGSN sends Flush-LL to PCU. Intersystem NCCR is done to an appropriate WCDMA FDD neighbour cell. 4. Data call is established in Cell2. There is no TBF in Cell1

9. IT0281156118 Objective NACC handling with several MSs in CCCH-configuration. 1.0.0 Test Purpose: To verify simultaneous NACC handling for several MS in CCCH-configuration. Required test environment: Two cells are created in the BSC1, cell1 and cell2 (with EGPRS enabled) and one cell3 created in BCS2 6 EGPRS MS 4 Prerequisite: NACC enabled Network control mode is set to NC0 Test execution: 1. Attach and execute PDP ctx activations for all MS to cell1 2. Establish EGPRS PSW-call and start FTP downlink data transfer in cell1 3. Increase the power of "Cell2" and decrease the power of "Cell1", such that the power of this "Cell2" is highest 4. Increase the power of "Cell3" and decrease the power of ?Cell2?, such that the power of this "Cell3" is highest Expected results: 1. PDP ctx activation succeed 2. EGPRS PSW-calls successfully established and FTP data transfers started in cell1 3. MS sends Packet Cell Change Notification to PCU for "Cell2" (MS keep sending DL data blocks ) ? PCU sends Packet Neighbour Cell Data messages to MS&apos;s ? PCU sends Packet Cell Change Continue messages to MS&apos;s ? MS&apos;s sends Cell Update to SGSN. SGSN sends Flush LLC procedure ? Cell reselection is done for all MS&apos;s to cell2 (Verify from service terminal that no TBF in cell1) ? Follow up the speed of cell-reselection (cell-reselection is quicker with NACCenabled) 4. Autonomous cell change is done for all MS&apos;s to cell3 ? MS&apos;s sends Cell Update to SGSN. SGSN sends Flush LLC procedure ? Cell reselection is done for all MS to cell3 (Verify from service terminal that no TBF in cell2)

10. SIV3_S15_ICNACC_001 Objective IB-NACC operations Objective To verify that IS-NACC O&M operations related to feature state changes can be performed successfully. Requirement ID BSS21045-002, BSS21045-032, BSS21045-033 Test Configuration 1 BSC with S15 SW active. PCU2 card in use. 2. SGSN with SG6 or newer connected to BSC using FR or GboIP, "RIM Procedure Support" license active in SGSN Pre-Condition 1. One BTS with at least 1 TRX created in BSC. 2. GPRS successfully enabled in BTS mentioned in pre-condition 1 3. NACC license enabled and NACC feature activated in BSC 4. IB-NACC license active Test case Execution Step # Action Expected result 1 Enable IS-NACC license in BSC In PCU IS-NACC feature is enabled, to be verified from PCUSIG monitoring 2 3 4 Disable GPRS in BTS Reset NSE BTS is deleted in PCU

RIM message support information is received from SGSN

Disable IS-NACC license in BSC In PCU IS-NACC feature is disabled, to be verified from PCUSIG monitoring

11. SIV3_S15_ICNACC_019 Objective IB-NACC Cell change duration Objective

To verify that inter-BSC NACC cell changes takes as short time as intra-BSC NACC cell change. Cell change outage is measured as defined for intra-BSC NACC cell reselection. Requirement ID BSS20083-009, BSS20083-014, BSS20083-020, BSS20083-023 Test Configuration 1. 2 BSCs (referred below as BSC1 and BSC2) with S15 SW active. PCU2 card in use in both BSCs. 2. 1 SGSN with SG6 or newer connected to BSCs using FR or GboIP, "RIM Procedure Support" license active in SGSN. Pre-Condition 1. One BTS with at least 1 TRX created in both BSCs. 2. GPRS successfully enabled in BTSs mentioned in pre-condition 1 3. NACC license enabled and NACC feature activated in BSCs 4. IB-NACC license enabled in both BSCs 5. Adjacencies just created between BTS in BSC1 and BTS in BSC2 (i.e. NACC target cell sys infos are not yet stored in PCUs

Test case Execution Step # Action Expected result 1 Start data transfer using 1 MS in BTS of BSC1 Data transfer started successfully

2 Perform cell reselection to BTS of BSC2 using PMAX parameter modification or attenuator MS sends PCCN when cell reselection criteria are met in MS. PCU in BSC1 requests for sys infos of target cell in BSC2 and sends PCCC to MS 3 Perform cell reselection to BTS of BSC1 using PMAX parameter modification or attenuator MS sends PCCN when cell reselection criteria are met in MS. PCU in BSC2 requests for sys infos of target cell in BSC1 and sends PCCC to MS 4 Perform cell reselection to BTS of BSC2 using PMAX parameter modification or attenuator MS performs inter-BSC cell reselection using NACC 5 Perform cell reselection to BTS of BSC1 using PMAX parameter modification or attenuator MS performs inter-BSC cell reselection using NACC 7 Stop data transfer & collect and analyze logs. Check also NACC related BSC counters Data transfer stopped successfully. No protocol errors nor computer error logs are visible. Counter values are correct. Measure cell change outage as defined in BSC

performance requirements. IB-NACC cell change performance should meet criteria set to intra-BSC NACC cell reselection. 12. IT02813086022 Objective PSE reset with multipoint Gb, LRAS and PCP 1.0.0 Purpose: To verify that PSE reset works with multipoint Gb, LRAS and PCU pool Requirement reference: BSS20086-035 PSE Restart UC Required test environment: Licence file with Multipoint Gb feature and PCP few PCU2s two SGSNs two NSEs in PSE: PAPU group(LRAS) and one other PAPU LRAS with several NS-VLs two BTSs under different BCSUs 2 MSs Nethawk Activate ?DL forwarding? and ?F/R TLLI UL FORWARDING? in SGSN(PAPU group parameter) Assistance configuration: One BTS with own PCU and PAPU. Units and BTS are not in multipoint configuration. Prerequisite: Working multipoint Gb with LRAS and PCP Normal Round Robin in use Multipoint Gb configuration: Assistance configuration: Test execution: Attach and detach MS1 under other BTS-X(assistance configuration). BTS is under different PAPU and PCU.=> MS1 gets TLLI with PAPU&apos;s NRI Attach MS1 with foreign TLLI which is not in NRI list(BTS1). Check that it uses LRAS NSEI. Reset PSE(ZFXR) After reset transfer data with MS1 Execute few times:

o Attach and detach MS2 under other BTS-X(assistance configuration). BTS is under different PAPU and PCU. => MS2 gets TLLI with PAPU&apos;s NRI o Attach MS2 with foreign TLLI which is not in NRI list(BTS1). Expected results: Reset succeeds, all NSEs in PSE reseted After reset NS-VL and BVCI states are WO-EX Verify NSE selection from Nethawk trace. After reset MS1 uses local TLLI with known NRI=> BSC select same LRAS NSE than earlier BSC selects NSE for foreign TLLI which NRI is not in NRI list based on Normal Round Robin Analyse that TLLI contain PAPU&apos;s NRI(SG5.1&SG6: NRI is part of the TLLI and it is located to bits 14 to 23 of TLLI. Most significant bit is 23 ) and local/foreign information is correct(bits 31&30 in TLLI)

bit 31 bit 30 type of TLLI 1 1 Local TLLI 1 0 Foreign TLLI 13. IT02813086024 Objective BCSU switchover with multipoint Gb, LRAS and PCP 1.0.0 Purpose: To verify that BCSU switchover works with multipoint Gb, LRAS and PCU pool Requirement reference: BSS20086-027 BCSU Switchover Required test environment: Licence file with Multipoint Gb feature and PCP few PCU2s Two SGSNs two NSEs in PSE: PAPU group(LRAS) and one other PAPU

two BTSs under different BCSUs 2 MSs Nethawk Activate ?DL forwarding? and ?F/R TLLI UL FORWARDING? in SGSN(PAPU group parameter) Assistance configuration: One BTS with own PCU and PAPU. Units and BTS are not in multipoint configuration. Prerequisite: Working multipoint Gb with LRAS and PCP Normal round robin in use Multipoint Gb configuration: Assistance configuration: Test execution: Attach and detach MS1 under other BTS-X(assistance configuration). BTS is under different PAPU and PCU. => MS1 gets TLLI with PAPU&apos;s NRI BTS1: Attach MS1 with foreign TLLI which is not in NRI list. Use LRAS NSEI. Activate PDP context and start data transfer Attach and detach MS2 under other BTS-X(assistance configuration). BTS is under different PAPU and PCU. => MS2 gets TLLI with PAPU&apos;s NRI BTS2: Attach MS2 with foreign TLLI which is not in NRI list. Check that it uses LRAS NSE. Activate PDP context and start data transfer Execute BCSU switchover(ZUSC) for BCSU which MS1 has been used. MS1&MS2: Stop data transfer Execute several times: o Attach and detach MS2 under other BTS-X(assistance configuration). BTS is under different PAPU and PCU. => MS2 gets TLLI with PAPU&apos;s NRI o Attach MS2 with foreign TLLI which is not in NRI list(BTS1). o Detach MS2 Expected results: Switchover succeeds After switchover NS-VL and BVCI state is WO-EX Verify NSE selection from Nethawk trace. After reset MS1 uses local TLLI with known NRI=> BSC select same NSE than earlier(LRAS) BCSU switchover doesn&apos;t affect for MS2, data transfer succeeds BSC selects NSE for foreign TLLI which NRI is not in NRI list based on Normal Round Robin

14. IT02813086027 Objective Cell change with multipoint Gb, PCP and LRAS 1.1.0 Purpose: To verify that data transfer is possible after cell change with multipoint Gb, PCU pooling and LRAS Requirement reference: BSS20086-006 SGSN selection UC BSS20086-007 Load Sharing UC Required test environment: Licence file with Multipoint Gb feature and PCP three PCU2s, all PCUs in PCP one PAPU group(LRAS) and two other PAPUs three BTSs under different PCU 2 MSs Nethawk Activate ?DL forwarding? and ?F/R TLLI UL FORWARDING? in SGSN(PAPU group parameter) Assistance configuration: One BTS with own PCU and PAPU. Units and BTS are not in multipoint configuration. Prerequisite: Working multipoint Gb with LRAS and PCP Normal round robin in use Multipoint Gb configuration:

Assistance configuration: Test execution: MS1: Test several times o Attach and detach MS1 under other BTS-X(assistance configuration). BTS is under different PAPU and PCU => MS1 gets TLLI with PAPU&apos;s NRI o Attach and activate PDP context => mobile attach with foreign TLLI which is in NRI list o Start data transfer o Change cell few times o detach MS1

 o o o

MS2: execute few times Attach and activate PDP context. Start data transfer. Change cell detach MS1

Expected results: Verify NSE selection from Nethawk trace. MS1: Foreign TLLI&apos;s NRI is not in NRI list and BSC selects new NSEI(based on Normal Round Robin). MS1: After cell change system selects same PAPU than in old sell. MS2: SGSN uses load balansing and based on NRR it selects NSVL. BSC sends (from "correct" PCU) empty LLC frame (RDF Resource Distribution Function) to SGSN when SGSN sends reply to ?wrong PCU?=> BSC sends IP address of PCU which handle subscriber. Cell changes succeeds.

15. ITA281151001 Objective 1]BCSU reset, all TRXs and Gb on reset BCSU TA 1.0.0

Prerequisite: 1 (E) GPRS capable BTS, 4 TRX, all ch unlocked CDED=CDEF=1, CMAX=100 GENA=Y, EGENA=Y 3 msc10 MS connected to MCG MSs on correct frequency BCSU 0 WO-EX BCSU 1 WO-EX BCSU 2 SP-EX BCSU 1 controlling bearer channel BCCH TRX 1 are created to BCSU 1 TCH TRX 1&2 are controlled by BCSU 1 TCH TRX 3&4 are controlled by BCSU 0 TRX 1&2&3&4 unlock Parameters: [ITA281151001] # ALL TRX+GB BCSU first_trx_lock=3 second_trx_lock=4

SubSection COMMON Test execution: Preparation Set MCS & CS Set EGENA state Execution Start CS call MS1 -> MS2, duration (param) Start DL data MS3, file (param) Wait CS call end Wait DL data call end MS3 Set TRX ID lock Set BCCH D-channel state Reset BCSU ID Wait reset when completed Start CS call MS1 -> MS2, duration (param) Start DL data MS3, file (param) Wait CS call end Wait DL data call end MS3 Restore EGENA=Y Set MCS & CS default Set BCSU 0 WO-EX Set BCSU 1 WO-EX Set BCSU 2 SP-EX TRX 1&2&3&4 unlock Analyse Check that all transfers were completed Check that all CS were succesfull No log writings in PCU log Alarms are set and canceled correctly

16. ITA281151002 Objective BCSU reset, all TRXs on reset BCSU, Gb on different BCSU TA 1.0.0 Prerequisite: 1 (E) GPRS capable BTS, 4 TRX, all ch unlocked CDED=CDEF=1, CMAX=100

GENA=Y, EGENA=Y 3 msc10 MS connected to MCG MSs on correct frequency BCSU 0 WO-EX BCSU 1 WO-EX BCSU 2 SP-EX BCSU 1 controlling bearer channel BCCH TRX 1 are created to BCSU 1 TCH TRX 1&2 are controlled by BCSU 1 TCH TRX 3&4 are controlled by BCSU 0 TRX 1&2&3&4 unlock

Parameters: [ITA281151002] # ALL TRX BCSU first_trx_lock=1 second_trx_lock=2 pref_trx=3 SubSection COMMON Test execution: Preparation Set MCS & CS Set EGENA state Execution Start CS call MS1 -> MS2, duration (param) Start DL data MS3, file (param) Wait CS call end Wait DL data call end MS3 Set TRX ID lock Set BCCH D-channel state Reset BCSU ID Wait reset when completed Start CS call MS1 -> MS2, duration (param) Start DL data MS3, file (param) Wait CS call end Wait DL data call end MS3 Restore EGENA=Y Set MCS & CS default Set BCSU 0 WO-EX Set BCSU 1 WO-EX Set BCSU 2 SP-EX

 TRX 1&2&3&4 unlock Analyse Check that all transfers were completed Check that all CS were succesfull No log writings in PCU log Alarms are set and canceled correctly 17. ITA281151003 Objective BCSU reset, Gb on reset BCSU, TRXs on different BCSU TA 1.0.0 Prerequisite: 1 (E) GPRS capable BTS, 4 TRX, all ch unlocked CDED=CDEF=1, CMAX=100 GENA=Y, EGENA=Y 3 msc10 MS connected to MCG MSs on correct frequency BCSU 0 WO-EX BCSU 1 WO-EX BCSU 2 SP-EX BCSU 1 controlling bearer channel BCCH TRX 1 are created to BCSU 1 TCH TRX 1&2 are controlled by BCSU 1 TCH TRX 3&4 are controlled by BCSU 0 TRX 1&2&3&4 unlock Parameters: [ITA281151003] # GB BCSU first_trx_lock=1 second_trx_lock=2 pref_trx=3 unit_id = 1#unit index for WO-EX unit to be switchover SubSection COMMON Test execution: Preparation Set MCS & CS Set EGENA state Execution

 Start CS call MS1 -> MS2, duration (param) Start DL data MS3, file (param) Wait CS call end Wait DL data call end MS3 Set TRX ID lock Set BCCH D-channel state Reset BCSU ID Wait reset when completed Start CS call MS1 -> MS2, duration (param) Start DL data MS3, file (param) Wait CS call end Wait DL data call end MS3 Restore EGENA=Y Set MCS & CS default Set BCSU 0 WO-EX Set BCSU 1 WO-EX Set BCSU 2 SP-EX TRX 1&2&3&4 unlock Analyse Check that all transfers were completed Check that all CS were succesfull No log writings in PCU log Alarms are set and canceled correctly 18. IT0281151005 Objective BCSU switchover, Gb on switched over BCSU, TRXs on different BCSU 1.1.0 Required test environment: one MS BTS Prerequisite: Basestations all TRX links and Gb-interface are at different BCSU. Test execution: Destination PCU2: Set log levels (sll pq2 6:11) and enable system dump (esd). Start data transfer. Make switchover for BCSU which handle Gb-interface(ZUSC). Check following logs:

Destination Chorus PCU:clog -sa Destination PCU2: check log writings and disable system dump(dsd) computer logs(ZGD). Expected results: Switchover succeeded and data transfer continues. 19. IT0281056530 Objective EGPRS call inter BSCs cell change. Counters 72058, 72059 1.0.0 The test case consist of PCU measurement case IT02812000105 (counters 72058 and 72059). Required test environment: Real GPRS network BSC with EGPRS capable UltraSite BTS BSC with GPRS capable TalkFamily BTS EGPRS MS Prerequisite: Create network as described below: BSC1 BTS1 (UltraSite) TRX1 (BCCH, EGPRS TRX) BSC2 BTS2 (Talk Family) TRX1 (BCCH, GPRS TRX) Define BTS 1 to be neighbour cell to BTS 2 (ZEAC:BTS=<bts_id>:LAC=<lac>,CI=<ci>:NCC=<ncc>,BCC=<bcc>,FREQ=<bcch_fr eq>;) Define BTS 2 to be neighbour cell to BTS 1 (ZEAC:BTS=<bts_id>:LAC=<lac>,CI=<ci>:NCC=<ncc>,BCC=<bcc>,FREQ=<bcch_fr eq>;) Define BTS1 PMAX paremeter to its highest (ZEUG:BTS=<bts_id>:PMAX=30;) Define BTS2 PMAX paremeter to its lowest (ZEUG:BTS=<bts_id>:PMAX=0;) Define maximum amount of Dedicated GPRS channels to BTSs (ZEQV:BTS=<bts_id>:CDEF=100,CDED=100;) Enable GPRS in both BTSs (ZEQV:BTS=<bts_id>:GENA=Y;)

Enable EGPRS in BTS1 (ZEQV:BTS=<bts_id>:EGENA=Y;) Unlock both BTSs (ZEQS:BTS=<bts_id>:U;) Start GPRS data transfer on BTS2 Test execution: Adjust power control parametrs in both BTSs so that handover to BTS2 is possible (ZEUG:BTS=<bts_id>:PMAX=<X dB>;) Continue data transfer and adjust power control parametrs in both BTSs so that handover to BTS1 is possible. Expected results: Handover to the both BSC&apos;s are successful. Data transfer successful. 20. IT2812089029 Objective EDA and HMC allocation according to transfer direction 1.0.0 Purpose: Verify that EDA and HMC are allocated according to transfer direction. Required test environment: Flexi BTS BSC (with S12 software) EDA/HMC capable mobile (MSC 32). Prerequisite: EDA and HMC are activated Test execution: Make sequential DL and UL FTP transfers Expected results: DL direction MS gets 5+1 allocation, and UL MS gets 3+3 allocation

21. IT2812084007 Objective Multislot class support 11-45 1.1.0 Purpose: To verify mobile TSL allocation is according to multislot class. Required test environment: Ultrasite BTSs (with CX4.2 -> software), 1 TRX BSC (with S12 software) Mobiles from each multislot class (11-45) 11 and 32 Prerequisite: - HMC is active - EDA is off - Favour DL on ( ZWOI:46,100&101;) (If 1 and 1 => Favour DL; 0 and 0 => Favour UL if [1 and 0] or [0 and 1] => Shared) Test execution: Make DL and UL data transfer with each multislot class mobile Check multislot allocation with PCU ST dsegtbf (initial and during data transfer) Turn Favour UL on. Make DL and UL data transfer with each multislot class mobile Check multislot allocation with PCU ST dsegtbf (initial and during data transfer) Turn SHARE on. Make DL and UL data transfer with each multislot class mobile Check multislot allocation with PCU ST dsegtbf (initial and during data transfer) Turn EDA on Turn Favour DL on. Make DL and UL data transfer with each multislot class mobile Check multislot allocation with PCU ST dsegtbf (initial and during data transfer) Turn Favour UL on. Make DL and UL data transfer with each multislot class mobile Check multislot allocation with PCU ST dsegtbf (initial and during data transfer) Turn SHARE on. Make DL and UL data transfer with each multislot class mobile Check multislot allocation with PCU ST dsegtbf (initial and during data transfer)

Expected results: Initial allocation is according to favour UL/DL parameter Mobiles are getting TSL allocation according to their multislot class. Reference: BSS20084-001

22. IT2812089011 Objective Timeslot configuration for mobiles supporting EDA 1.0.0 Purpose: To verify that PCU is supporting timeslot configurations for mobiles from different MS class and EDA capability. Required test environment: Ultrasite BTSs (with CX4.2 -> software) BSC (with S12 software) EDA capable mobiles MSC 11-45. Prerequisite: EDA is active CMAX=100% Favour DL is on Test execution: Make UL and DL data transfers with EDA capable mobile from MS class 11-45. Check timeslot allocation with PCU2 STE dsegtbf. Adjust CMAX value so it will force also smaller allocations than max Repeat transfers with favour UL on and share on. Expected results: Mobiles get timeslot configuration as in specification. MS Class 1

1+1 2 1+1, 2+1 3 1+1, 1+2, 2+1 4 1+1, 2+1, 3+1 5 1+1,1+2, 2+1, 2+2 6 1+1, 1+2, 2+1, 2+2, 3+1 7 1+1, 1+2, 1+3, 2+1, 2+2, 3+1 8 4+1 9 1+1, 1+2, 2+1, 2+2, 3+1, 3+2 10 1+1, 1+2, 2+1, 2+2, 3+1, 3+2, 4+1 11 1+1, 1+2, 1+3, 2+1, 2+2, 2+3, 3+1, 3+2, 4+1 12 1+1, 1+2, 1+3, 1+4, 2+1, 2+2, 2+3, 3+1, 3+2, 4+1 19 1+1, 1+2, 2+1, 2+2, 3+1, 3+2, 4+1 20 1+1, 1+2, 1+3, 2+1, 2+2, 2+3, 3+1, 3+2, 4+1 21 1+1, 1+2, 1+3, 2+1, 2+2, 2+3, 3+1, 3+2, 4+1 22 1+1, 1+2, 1+3, 1+4, 2+1, 2+2, 2+3, 3+1, 3+2, 4+1 23 1+1, 1+2, 1+3, 1+4, 2+1, 2+2, 2+3, 3+1, 3+2, 4+1 24 1+1, 1+2, 2+1, 2+2, 3+1, 3+2, 4+1 25 1+1, 1+2, 1+3, 2+1, 2+2, 2+3, 3+1, 3+2, 4+1 26 1+1, 1+2, 1+3, 2+1, 2+2, 2+3, 3+1, 3+2, 4+1 27 1+1, 1+2, 1+3, 1+4, 2+1, 2+2, 2+3, 3+1, 3+2, 4+1 28 1+1, 1+2, 1+3, 1+4, 2+1, 2+2, 2+3, 3+1, 3+2, 4+1 29 1+1, 1+2, 1+3, 1+4, 2+1, 2+2, 2+3, 3+1, 3+2, 4+1 30

1+1, 2+1, 3+1, 4+1, 5+1 31 1+1, 2+1, 3+1, 4+1, 5+1, 1+2, 2+2, 3+2, 4+2 32 1+1, 2+1, 3+1, 4+1, 5+1, 1+2, 2+2, 3+2, 4+2, 1+3, 2+3, 3+3 33 1+1, 2+1, 3+1, 4+1, 5+1, 1+2, 2+2, 3+2, 4+2, 1+3, 2+3, 3+3, 1+4, 2+4 34 1+1, 2+1, 3+1, 4+1, 5+1, 1+2, 2+2, 3+2, 4+2, 1+3, 2+3, 3+3, 1+4, 2+4 35 1+1, 2+1, 3+1, 4+1 36 1+1, 2+1, 3+1, 4+1, 1+2, 2+2, 3+2 37 1+1, 2+1, 3+1, 4+1, 1+2, 2+2, 3+2, 1+3, 2+3 38 1+1, 2+1, 3+1, 4+1, 1+2, 2+2, 3+2, 1+3, 2+3 39 1+1, 2+1, 3+1, 4+1, 1+2, 2+2, 3+2, 1+3, 2+3 40 1+1, 2+1, 3+1, 4+1, 5+1 41 1+1, 2+1, 3+1, 4+1, 5+1, 1+2, 2+2, 3+2, 4+2 42 1+1, 2+1, 3+1, 4+1, 5+1, 1+2, 2+2, 3+2, 4+2, 1+3, 2+3, 3+3 43 1+1, 2+1, 3+1, 4+1, 5+1, 1+2, 2+2, 3+2, 4+2, 1+3, 2+3, 3+3, 1+4, 2+4 44 1+1, 2+1, 3+1, 4+1, 5+1, 1+2, 2+2, 3+2, 4+2, 1+3, 2+3, 3+3, 1+4, 2+4 45 1+1, 2+1, 3+1, 4+1, 5+1, 1+2, 2+2, 3+2, 4+2, 1+3, 2+3, 3+3, 1+4, 2+4

23. IT2812084008 Objective HMC Multislot class mapping when no HMC licence 1.0.0 Purpose: To verify that HMC MSs are mapped to correct multislot class when there&apos;s no valid HMC licence. Required test environment:

Ultrasite BTSs (with CX4.2 -> software), 1TRX BSC (with S12 software) HMC multislot class 30-45 MSs Prerequisite: HMC feature off EDA off Favor DL on Test execution: Start data DL transfer with HMC capable EGPRS mobiles from classes 30-45 one at a time Check mobile&apos;s TSL allocation. Turn Favour UL on Reapeat the transfers Turn Favour DL on Reapeat the transfers Turn Favour SHARE on Reapeat the transfers Reapeat all the above when EDA is on with UL data transfer Expected results: Initial allocation follows favour UL/DL/SHARE Durin data transfer HMC mobiles are mapped MSC 11. Reference: BSS20084-002

24. IT2812089019 Objective nRT EDA to DA and DA to EDA allocation reconfiguration, EDA traffic 1.0.0 Purpose: Verify that when available resources are changing, reconfiguration from EDA to DA and DA to EDA is happening Required test environment: Ultrasite BTSs (with CX4.2 -> software). 1 TRX BSC (with S12 software)

4 EDA capable mobiles Prerequisite: EDA is active Favour UL parameter is on. Large EDAP. Test execution: Start nRT UL data transfer with 4 mobiles one at a time. Check MS allocation between each started transfer with PCU STE dsegtbf. Stop transfers one at a time Check MS allocation between each stopped transfer with PCU STE dsegtbf Expected results: When enough resources are not available EDA allocation is changed to DA. When enough resources are available DA allocation is changed to EDA. Counter 72211 DA FOR EDA NRT Counter 72213 DA REALLOC TO EDA FOR NRT Counter 72215 EDA REALLOC TO DA FOR NRT Reference:

25. IT2812088103 Objective DTM-mobile inter-PCU HO from DTM to a non-DTM cell. 1.0.0 DTM capable mobile makes a CS call in a DTM and GPRS enabled segment. Verify that DTM coordination information is properly exchanged between DX and PCU2. There is a HO for the MS to a nonDTM-capable cell in different PCU. Setup: 1. Setup with 2 PCU2s in one BCSU cartridge. 2. S12 SW is installed with DTM license and DTM feature state is set to ON. 3. All the hardware and software is up and running on all the units in the setup. 4. 2 segments (and BVC with one NS VC) with one BTS and one TRX in the BTS created. GPRS is enabled in the segments. One CCCH, one SDCCH, two PDCH configured in the TRX. 5. DTM has been enabled in the 1st segment by setting DENA = YES.

6.

There is a good nonDTM-capable neighbour in a different PCU.

Test Execution: 1. 2. 2. Take a DTM capable MS and start a MO CS call for this MS Adjust the transmission power to trigger a HO. Stop the CS-call

Expected results: 1. 2. a. DX should send the dtm_imsi_entry_ind_s message to PCU2. b. PCU2 should create an IMSI context for this MS. a. DX sends HO_COMMAND to MS b. DX sends dtm_imsi_exit_ind_s to the old PCU c. PCU should respond with dtm_imsi_exit_ind_resp_s. d. PCU should delete the IMSI context for this MS. e. From the new cell MS reponds with HO_COMPLETE

26. IT2812088102 Objective DTM-mobile intra-PCU HO from a nonDTM to DTM cell. 1.0.0 DTM capable mobile makes a CS call in a GPRS enabled segment. There is a HO for the MS to a DTM-capable cell in the same PCU. Verify that DTM coordination information is properly exchanged between DX and PCU2. Setup: 1. Setup with one PCU2 in one BCSU cartridge. 2. S12 SW is installed with DTM license and DTM feature state is set to ON. 3. All the hardware and software is up and running on all the units in the setup. 4. 2 segments (and BVC with one NS VC) with one BTS and one TRX in each BTS created. GPRS is enabled in the segments. One CCCH, one SDCCH, two PDCH configured in the TRX. 5. DTM has been disabled in the 1st segment by setting DENA = NO. 6. There is a good DTM-capable neighbour in the same PCU.

Test Execution: 1. 2. 3. Take a DTM capable MS and start a MO CS call for this MS Adjust the transmission power to trigger a HO. Stop the CS-call

Expected results: 1. 2. a. CS call is established a. DX sends HO_COMMAND to MS b. From the new cell MS reponds with HO_COMPLETE c. DX should send the dtm_imsi_entry_ind_s message to PCU2. d. PCU2 should create an IMSI context for this MS. a. DX should send the dtm_imsi_exit_ind_s message to PCU2. b. PCU2 should respond with dtm_imsi_exit_ind_resp_s. c. PCU2 should delete the IMSI context for this MS.

3.

27. IT2812088028 Objective MO DTM-call BTS selection. Segment with cs,psDTM resources. CDED=0, CDEF=1, CMAX=1 in BCCH-band PS-territory, CDED=0, CDEF=1, CMAX=100 in non-BCCH band. 1.0.0 DTM capable mobile makes a CS call followed by MO-PS call (ping) , in a DTM and GPRS enabled segment with EQoS disabled. Segment has BTSs with CSonly and GPRS/DTM territories. BTS indexesand bands are: 1 BCCH, 2 cs non-bcch, 3 ps nonbcch Verify that DTM call is successfully made, CS and PS traffic continues and finally PS calls are properly released. 1. BTS indexes and bands are: 1 BCCH, 2 cs non-bcch, 3 ps non-bcch CMAX=100 2. BTS indexes and bands are: 1 non-bcch CMAX=100, 2 cs non-bcch, 3 BCCH 3. BTS indexes and bands are: 1 BCCH, 2 non-bcch CMAX=100, 3 cs 4. BTS indexes and bands are: 1 cs, 2 non-bcch, 3 BCCH CMAX=100 Setup:

1. setup with one PCU2 in one BCSU cartridge. 2. S12 SW is installed with DTM license and DTM feature state is set to ON. 3. All the hardware and software is up and running on all the units in the setup. 4. One segment (and BVC with one NS VC) with 3 BTSs and one TRX in each BTS created. CS-territory is in different band from BCCH territory. GPRS is disabled in one BTS (GTRX=N), One CCCH, one SDCCH configured. 5. DTM has been enabled in the segment by setting DENA = YES. 6. Take a DTM capable MS (DTM GPRS multislot class 9) and connect it to a Laptop. De-configure all the unnecessary applications from Laptop so that no undesirable UL or DL data transfer happens from Laptop for this MS. Test execution: 1. 2. 3. 4. Take a DTM capable MS and start a MO CS call for this MS Make attach and PDP-activation Initiate PING application from this MS with def settings. Stop the CS call for this MS

Expected results: 1. a. DX should send the dtm_imsi_entry_ind_s message to PCU2. b. PCU2 should create an IMSI context for this MS. c. CS call is allocated in the non-PS BTS.

2. a. MS sends GPRS_attach and PDP_activation to DX in GPRS_INFORMATION thru GTTP b. DX sends gttp_msg_s to PCU2. c. PCU sends BSSGP message to SGSN 3. a. MS sends a DTM Request over the FACCH channel to initiate the sending of Ping request PDUs. b. DX sends dtm_alloc_req_s to PCU2. c. PCU2 allocates 1 CS and 1 PS TSL to the MS, locally releases the CS TSL

from PS territory through internal territory downgrade procedure and sends the allocation (in dtm_alloc_resp_s message) back to DX. d. DX sends DTM assignment command to MS.

e. MS switches to newly assigned CS and PS TSLs (different BTS and band) and sends the DTM Assignment Complete message on new channel. f. DX sends dtm_alloc_conf_s message to PCU2. g. PCU2 starts scheduling for the UL TBF. h. During the TBF active duration, verify (at Nethawk, MS) that PSI14 message is scheduled every 15 second on PACCH. i. In all TBF assignment messages, verify (at Nethawk, MS) that the timing advance value is not provided. j. Once all Ping request PDU have been transferred, UL TBF should be released at PCU2. PCU2 sends a dtm_ps_release_req_s message to DX. k. DX allocates a CS slot for CS territory and initiates intra cell handover procedure for the MS. Once it is completed, then DX sends dtm_cs_release_req_s message to PCU2. l. PCU responds with dtm_cs_release_resp_s. m. PCU2 makes territory upgrade for the released CS-tsl. n. Over the whole duration of Ping procedure, CS call of the MS continues in normal way. 4. a. DX should send the dtm_imsi_exit_ind_s message to PCU2. b. PCU2 should respond with dtm_imsi_exit_ind_resp_s. c. PCU2 should delete the IMSI context for this MS.

28. Alarm 3415 is cancelled when fixed PS lo Objective Alarm 3415 is cancelled when fixed PS load in all PCUs is lower than alarms cancellation load limit (S13, PCP, CR212) 1.0.0 The purpose is to test that alarm 3415 (GPRS/EDGE LOAD IS VERY HIGH IN PCU OF PSE) is cancelled and it&apos;s cancelled only in case that fixed PS load of all PCUs in PSE is lower than the alarm&apos;s cancellation load limit. There is only one alarm for the PSE even if fixed PS load of several PCUs would be higher than the alarm&apos;s load limit. Segments&apos; PS load information is not initialised when alarm 3415 is cancelled. Preconditions:

- There are two PCUs in the PCP (PCU1 and PCU2) - POAT = 50 - Alarm 3415 is not active for the PSE PCU1 and PCU2: - There are quite many segments with their DAPs in PCU1 and PCU2 - Fixed PS load of both PCUs is lower than the alarm&apos;s load limit - Fixed PS load of both PCUs is anyway so high that alarm 3415 can be triggered by increasing PS load of segments. - PS load of all segments is 0. Execution: 1. Increase PS load of segments in PCU1 (e.g. with cell_load_info_s messages) so that fixed PS load of PCU1 is getting higher than alarm&apos;s 3415 load limit. - Alarm 3415 is set for PSE/PCU1 2. Increase PS load of segments in PCU2 (e.g. with cell_load_info_s messages) so that fixed PS load of PCU2 is also getting higher than alarm&apos;s 3415 load limit. - The same alarm 3415 is still active for PSE/PCU1 3. Decrease PS load of segments in PCU1 so much that fixed PS load of PCU1 is getting below alarm&apos;s cancellation load limit. (e.g. send cell_load_info_s messages 27 times per segment) - Fixed PS load of PCU1 is getting lower than alarm&apos;s 3415 cancellation load limit - The same alarm 3415 is still active for PSE/PCU1 because load in PCU2 is still higher than the alarm&apos;s cancellation load limit 4. Decrease PS load of segments in PCU2 so much that fixed PS load of PCU2 is getting lower than the alarm&apos;s cancellation load limit. (e.g. send cell_load_info_s messages 27 times per segment) - Fixed PS load of PCU2 is getting lower than alarm&apos;s 3415 cancellation load limit - Alarm 3415 is cancelled for PSE/PCU1 5. Check that segments&apos; PS load values were not initialised. - All segments have still correct PS load values. Same values which they had before cancellation of the alarm. - PS load value of any segment is not initialised to value FF. 29. Alarm 3415 is not cancelled after reallo Objective Alarm 3415 is not cancelled after reallocation if fixed PS load in some PCUs is still higher than alarms cancellation load limit (S13, PCP, CR212) 1.0.0

The purpose is to test that alarm 3415 (GPRS/EDGE LOAD IS VERY HIGH IN PCU OF PSE) is not cancelled in case that fixed PS load of some PCU is still higher than the alarm&apos;s cancellation load limit after reallocation. Preconditions: - There are two PCUs in the PCP (PCU1 and PCU2) - POAT = 50 - PSAT = 50 - Alarm 3415 is active for the PSE/PCU1 PCU1: - There are quite many segments with their DAPs in PCU1 - Fixed PS load of PCU1 is higher than the alarm&apos;s load limit - Fixed PS load of PCU1 is higher than reallocation limit PCU2: - There are quite many segments with their DAPs in PCU2 - Fixed PS load of PCU2 is lower than the alarm&apos;s load limit - Fixed PS load of PCU2 is lower than reallocation limit - Fixed PS load of PCU2 is anyway so high that it&apos;s not possible to move enough segments and DAPs from PCU1 to PCU2 in order to cancel the alarm 3415. Execution: 1. Start reallocation by MML ZFXF:P:PSEI=X; - Reallocation is started and at least one segment with DAPs is moved from PCU1 to PCU2. - Alarm 3415 is not cancelled because load of PCU1 is still higher than the alarm&apos;s cancellation load limit. 30. Alarm 3415 is set after PCU removal if f Alarm 3415 is set after PCU removal if fixed PS load in some PCU is higher than alarms load limit (S13, PCP, CR212) 1.0.0 The purpose is to test that alarm 3415 (GPRS/EDGE LOAD IS VERY HIGH IN PCU OF PSE) is set in case that fixed PS load of some PCU is higher than the alarm&apos;s load limit after removing PCU from PCP.

Preconditions: - There are three PCUs in the PCP (PCU1, PCU2 and PCU3) - POAT = 50 - PSAT = 95 - Alarm 3415 is not active for the PSE PCU1: - There are quite many segments with their DAPs in PCU1 - Fixed PS load of PCU1 is quite high, but lower than the alarm&apos;s load limit - Fixed PS load of PCU1 is lower than reallocation limit PCU2: - There are quite many segments with their DAPs in PCU2 - Fixed PS load of PCU2 is quite high, but lower than the alarm&apos;s load limit - Fixed PS load of PCU2 is lower than reallocation limit PCU3: - There are some segments with their DAPs in PCU3 - Fixed PS load of PCU3 is so high, that fixed PS load of PCU1 or PCU2 will be higher than the alarm&apos;s load limit, when PCU3 is removed from PCP. Execution: 1. Remove PCU3 from PSE/PCP ZFXF:R:BCSU=X,PCU=X; - PCU3 is successfully removed from the PSE/PCP - Alarm 3415 is set because fixed PS load of PCU1 or PCU2 is getting higher than the alarm&apos;s load limit. 31. Alarm 3415 is set if fixed PS load in so Objective Alarm 3415 is set if fixed PS load in some PCU is higher than alarms load limit after enabling GPRS (S13, PCP, CR204) 1.1.0 The purpose is to test that alarm 3415 (GPRS/EDGE LOAD IS VERY HIGH IN PCU OF PSE) is set in case that fixed PS load of some PCU is getting higher than the alarm&apos;s load limit after enabling GPRS. Preconditions: - There are two PCUs in the PSE/PCP (PCU1 and PCU2)

- POAT = 50 - Alarm 3415 is not active for the PSE1 - There is no PS load/traffic in any segment. It could cause unpredictable results during this test case. PCU1: - There are quite many segments with their DAPs in PCU1 - There are e.g. 7 (or more) default channels in every segment (CDEF=100). - Fixed PS load of PCU1 is just a bit lower than the alarm&apos;s load limit. - GPRS of some segments is disabled. It&apos;s possible to trigger alarm 3415 by enabling GPRS of these segments. - PS load of all segments = 0 PCU2: - There are some segments with their DAPs in PCU2 - Fixed PS load of PCU2 is clearly lower than alarm&apos;s 3415 load limit. Execution: 1. Enable GPRS from some segments of PCU1. Enabling is done from so many segments that fixed PS load of PCU1 is getting higher than alarm&apos;s 3415 load limit. ZEQV:... - Alarm 3415 is set because fixed PS load of PCU1 is higher than the alarm&apos;s load limit. 32. IT02813106004 Objective PCP Create dynamic NSE to PCP 1.0.0 Description: Dynamic NS configuration can be used with PCP. Pre-requirements: * PSE with at least 3 PCU2s. Test execution: * Trace Gb. * Create dynamic NSE to the PSE and SGSN. ZFXK:... * Create RNW to the PSE and start data transfer. Expected results: * Check Gb trace:

- One PCU performs Size and Configuration procefures and signalling BVC reset. - Other PCUs perform Add procedure. * Data transfer is successful.

33. IT02813106006 Objective PCP Create static NSE with multiple NS-VLs to PCP 1.0.0\ Description: Static NSE configuration can be used with PCP. Pre-requirements: * PSE with at least 3 PCU2s. * SGSN has PAPU group with at least 3 PAPU units. Test execution: * Create static NSE with all BSC endpoints (PCUs) to SGSN. * Create static NSE with 1st SGSN endpoint (PAPU) to BSC. ZFXK:... * Add additional SGSN endpoints to NSE in BSC. ZFXK:... * Create RNW and start data transfer. Expected results: Data transfer is successful.

34. IT02813106022 Objective PCP Delete and recreate NSE in SGSN 1.0.0 Description: Verify that NSE deletion and recreation in SGSN works with PCP. Pre-requirements: * PSE with at least 3 PCU2s. * Dynamic NSE created. * Working RNW. Test execution: * Trace Gb. * Delete NSE from SGSN.

* Output NSE info from all PCUs in the PSE. ZFXI:BCSU=<bcsu>,PCU=<pcu>; * Recreate the NSE back to SGSN. * Output NSE info from all PCUs in the PSE. ZFXI:BCSU=<bcsu>,PCU=<pcu>; * Start data transfer. Expected results: * Check Gb trace: - SGSN sends SNS-DELETE to a PCU, which replies with SNS-ACK (without cause field). - One PCU starts sending SNS-SIZE to SGSN, which doesn&apos;t answer. NSE output shows that no PCU in PSE has any SGSN endpoints. - SGSN answers with SNS-SIZE-ACK, and Configuration procedure is performed. - One PCU performs signalling BVC reset. - Other PCUs perform Add procedure. - All PCUs perform PTP BVC reset for their cells. NSE output shows that all PCUs in PSE have same SGSN endpoints. * Data transfer is successful.

35. IT02813106020 Objective PCP Change weights of SGSN endpoints 1.0.0 Description: Verify that SGSN initiated Changeweight procedure (SGSN changes weights of its endpoints) works with PCP. Pre-requirements: * PSE with at least 3 PCU2s. * Dynamic NSE created. Test execution: * Trace Gb. * Change weights of NSE&apos;s endpoint in SGSN. ZFWO:NSEI=<nse_id>:NEWLDW=<new_weight>,NEWLSW=<new_weight>,NE WMODE=1; * Output NSE info from all PCUs in the PSE. ZFXI:BCSU=<bcsu>,PCU=<pcu>; Expected results: * Check Gb trace:

- SGSN sends SNS-CHANGEWEIGHT to a PCU, which replies with SNS-ACK (without cause field). NSE output shows that all PCUs in the PSE have same SGSN endpoint weights.

36. IT02813106025 Objective PCP Change PCU IP address 1.0.0 Description: Verify that changing PCU&apos;s IP address is successful with PCP. Pre-requirements: * PSE with at least 3 PCU2s. * Dynamic NSE created. * Working RNW. Test execution: * Trace Gb. * Remove PCU IP address. ZQRG:BCSU,<bcsu>:PCU2D,<pcu>:IFETH0; ZQRG:BCSU,<bcsu>:PCU2D,<pcu>:IFETH1; ZQKA::BCSU,<bcsu>:PCU2D,<pcu>; * Watch alarms. * Create new IP address to the PCU. ZQRN:BCSU,<bcsu>:PCU2D,<pcu>:IFETH0:<new IP address>,L:<netmask length>; ZQRN:BCSU,<bcsu>:PCU2D,<pcu>:IFETH1:<new IP address>,L:<netmask length>; ZQKC:BCSU,<bcsu>:PCU2D,<pcu>::<new default gateway address>; * Start data transfer. Expected results: * Check Gb trace: - PCU sends SNS-DELETE to remove the old endpoint. - PCU sends SNS-ADD to create the new endpoint. * Data transfer is successful

37. IT02813106003 Objective

PCP Delete PSE with multiple PCUs 1.0.0 Description: PCP is deleted from BSC. Pre-requirements: * PSE with 3 or more PCU2s. * Working RNW in the PSE. Test execution: * Disable GPRS from all cells in the PSE. * Delete NSE. ZFXH:... * Delete PSE. ZFXE:PSEI=<psei>; * Create PSE with first PCU. ZFXA:PSEI=<psei>,BCSU=<bcsu>,PCU=<pcu>,:; * Create NSE. ZFXK:... * Enable GPRS to all cells in the PSE. * Start data transfer. * Add all other PCUs to the PSE. ZFXF:A:PSEI=<psei>,BCSU=<psei>,PCU=<pcu>:RAE=Y:; Expected results: * NSE and PSE deleted and new ones created successfully. * Data transfer is successful. 38. IT02813106005 Objective PCP Delete dynamic NSE from PCP 1.0.0 Description: Dynamic NSE can be deleted from PCP. Pre-requirements: * PSE with at least 3 PCU2s and dynamic NSE. Test execution: * Trace Gb. * Delete dynamic NSE from the PSE and SGSN. Expected results: * Check Gb trace:

- All PCUs perform Delete procedure.

39. IT02813106010 Objective PCP PSE reset with dynamic NSE in PCP 1.0.0 Description: PSE/NSE reset works with dynamic NSE configuration in PCP. Pre-requirements: * PSE with at least 3 PCU2s. * Dynamic NSE created. * Working RNW. Test execution: * Start data transfer. * Trace Gb. * Reset PSE/NSE. ZFXR:PSEI=<psei>; ZFXR:NSEI=<nsei>; Expected results: * Check Gb trace: - One PCU performs Size and Configuration procedures and Signalling BVC reset. - Other PCUs perform Add procedure. - All PCUs perform PTP BVC resets for their cells. * Data transfer continues undisturbed. 40. IT02813106011 Objective PCP PSE reset with static NSE in PCP 1.0.0 Description: PSE/NSE reset works with static NSE configuration in PCP. Pre-requirements: * PSE with at least 3 PCU2s. * Static NSE created. * Working RNW.

Test execution: * Start data transfer. * Trace Gb. * Reset PSE/NSE. ZFXR:PSEI=<psei>; ZFXR:NSEI=<nsei>; Expected results: * Check Gb trace: - One PCU performs Signalling BVC reset. - All PCUs perform PTP BVC resets for their cells. * Data transfer continues undisturbed. 41. IT02813106002 Objective PCP Remove PCU with RNW from PSE 1.0.0 Description: PCU with working RNW is removed from PSE. RNW is reallocated to remaining PCUs in the PSE. Pre-requirements: * PSE with 3 PCU2s. * RNW on at least 1 of the PCUs. Test execution: * Start data transfer in RNW on the PCU which is to be removed from PSE. * Remove a PCU with RNW from the PSE. ZFXF:R:BCSU=<bcsu>,PCU=<pcu>; * Remove another PCU with RNW from the PSE. ZFXF:R:BCSU=<bcsu>,PCU=<pcu>; Expected results: * Data transfer is successful in all cells.

42. IT02813106031 Objective PCP Routing PCU (outside the PCP) 1.0.0

Description: Verify that DL data sent by SGSN to PCU different than the one where the MS&apos;s RNW is forwarded to the PCU with the RNW, when routing PCU not in the PSE is used. Pre-requirements: * PSE with 2 PCU2s, both in the same PCU2-D plug-in unit. * Other PCU2 not in the PSE, set as the routing PCU for both the PCUs in the PSE. * Working NSE and RNW. Test execution: * Refer to test case "PCP: SGSN sends data to wrong PCU". Expected results: * Refer to test case "PCP: SGSN sends data to wrong PCU". 43. IT02813106057 Objective Description: The operator can move GPRS segment from PSE to another by disabling and enabling GPRS in Segment. Pre-requirements: * 2 PCP with 2 PCUs. * 2 GPRS segments. Test execution: * Move segment from PCP to another. ZEQV:BTS=x:GENA=N; ZEQV:BTS=x:GENA=Y,:PSEI=x; Expected results: * Modification is succesful and data transfer is possible.

44. IT02813106058 Objective PCP PCUs cell configuration in PCU 1.0.0 Description: PCU has to know cell configurations of all other PCUs in PCP. Pre-requirements:

* 1 PCP with 2 PCUs. * 2 EGPRS segments each in different PCU. Test execution: * Check cell configuration of both PCUs. - Check PCU ID to BCSU & PCU index mapping: ZFXL:PSEI=<psei>; - Check cell configuration from PCU service terminal: gpcp Expected results: * PCUs knows the cell configuration of all PCUs.

45. IT02813106030 Objective PCP Inter-PCU cell change 1.0.0 Description: Verify that inter-PCU cell change works with PCP. Pre-requirements: * PSE with at least 2 PCU2s. * Working NSE and RNW. Test execution: * Trace Gb. * Start data transfer. * Do cell change from source PCU to target PCU. Expected results: * Check Gb trace: - SGSN sends FLUSH-LL to some PCU (which forwards it to source PCU thru inter-PCU interface). - Source PCU sends FLUSH-LL-ACK to SGSN. * Data transfer continues undisturbed.

46. IT02813106050 Objective PCP Neighbours in PCU selection algorithm 1.0.0

Description: PCU selection algorithm shall be able to take account also neighbour cells in PCU selection. Pre-requirements: * 1 PCP with 2 PCUs. * 3 segments. 2 segments are adjacent. Test execution: * Trigger reallocation ZFXF:P:PSEI=x; Expected results: * Neighbour cells should be located into the same PCU because the Intra-PCU cell reselection gives better performance than the inter-PCU cell reselection.

47. SIV3_S15_PAbis_004 Objective Active e2e RTT with Packet abis Requirement reference: ETP-1213 PS u-plane RTT caused by ETPE/T Purpose: To Measure active RTT when packet abis is in use Required test environment: Real GPRS network with EGPRS capable Flexi BTS Wire shark analyzer EGPRS mobile Prerequisite: Following network configuration: SEG1 BTS1 1800 (Ultra Site) EGPRS-CS1-CS2 TRX1 (BCCH) Define full dedicated GPRS channels to TRX Lock TSLs 1&&3 EUTM feature activated. Test execution:

Make a excel sheet of the different situations. The test shall be performed using the ping application with packet sizes (32, 256 and 1460 bytes) by sending 51 consecutive ping packets to a known address. Expected results: Ping times are reasonable. No exceptions can be noticed. Post processing: The first ping result is excluded from the material and following figures (in milliseconds) are calculated: Average active RTT Minimum and maximum values for active RTT 48. SIV3_S15_PAbis_005 Objective Idle e2e RTT with Packet abis Purpose: To Measure idle RTT when packet abis is in use Required test environment: Real GPRS network with EGPRS capable Flexi BTS Wire shark analyzer EGPRS mobile Prerequisite: Following network configuration: SEG1 BTS1 1800 (Ultra Site) EGPRS-CS1-CS2 TRX1 (BCCH) Define full dedicated GPRS channels to TRX Lock TSLs 1&&3 EUTM feature activated. Test execution: Make a excel sheet of the different situations.

The test shall be performed using the ping application with packet sizes (32, 256 and 1460 bytes) by sending 50 ping packets to a known address with 4 seconds interval between packets. Expected results: Ping times are reasonable. No exceptions can be noticed. Post processing: The following figures (in milliseconds) are calculated from the results: Average active RTT Minimum and maximum values for active RTT

49. SIV3_S15_PAbis_006 Objective PCU2 Abis RTT with packet abis Purpose: To Measure abis RTT when packet abis is in use Required test environment: Real GPRS network with EGPRS capable Flexi BTS Wire shark analyzer EGPRS mobile Signal generator Prerequisite: Following network configuration: SEG1 BTS1 1800 (Ultra Site) EGPRS-CS1-CS2 TRX1 (BCCH) Define full dedicated GPRS channels to TRX Lock TSLs 1&&6 EUTM feature activated. Test execution: Start downlink data transfer.

Cause such radio conditions that some RLC blocks are lost. Then measure from NH-logs the time difference between face 1 and 3 in a following situation. BSS setting the polling bit, RLC/MAC encodes the packet and sends it to mobile. MS processes the polling and replies with an ack/nack indicating certain blocks missing. BSS retransmits the missing RLC blocks. Expected results: The RLC RTT is according to requirements. (Less than 200ms). 50. SIV3_S15_PAbis_321 Objective ETP-TETP-E restart UC Test purpose To verify that BSC shall be able to transmit CS and PS traffic after ETP-T/ETP-E unit restart. Required test environment BSC3i 1000/2000 or Flexi BSC with S15 SW. Packet Abis supported BTS Test execution Restart ETP-T unit Check ETP-T and RNW objects states Make CS and PS calls after RNW recovered Restart ETP-E unit Check ETP-T and RNW objects states Make CS and PS calls after RNW recovered Expected results Unit restarted successfully and it will be recovered The states of RNW objects following the ETPx unit state CS and PS calls were succeed after unit has been recovered Note! Due to ETPx unit restart user can check the state of RNW objects. RNW state table found from (Packet Abis OM IS [chapter 5.2.7.1] ) and restart procedure (Packet Abis OM IS [chapter 5.2.7.2]) Linked requirements BSS21231-401 New operative state for TRX, BTS and BCF objects BSS21231-403 ETP restart & File Based Plan provisioning

51. SIV3_S15_PAbis_322 Objective BCSU reset and switchovers, BCF state does not change Test purpose To verify that during ETPx restart, BCSU restart and - switchover succeeds, but the state of the BCF does not change. Required test environment BSC3i 1000/2000 or Flexi BSC with S15 SW. Packet Abis supported BTS Test execution Restart ETPx Restart BCSU and check the state of BCF Wait for that the BCSU recovered Make a BCSU switchover (ETPx still restart phase) and check the state of the BCF Expected results BCSU restart succeeds and the state of the BCF stays BL-ETP. BCSU switchover succeed and the state of the BCF stays BL-ETP. Note!. If BCSU restart or BCSU switchover occurs during ETP restart, then DX O&M shall skip the BCSU reset/switchover (blocking / de-blocking) task related to the BCF, which is in blocked operative state due to the ETP restart. Linked requirements BSS21231-402 ETP-T/ETP-E restart UC. 52. SIV3_S15_PAbis_341 Objective Controlled Switchover between two ETPTs and between two ETPEs. Test purpose To verify that controlled switchover between two ETPTs and between two ETPEs succeeded. Ongoing calls shall continued during switchover. Required test environment BSC3i 1000/2000 or Flexi BSC with S15 SW. Packet Abis supported BTS Test execution

1. Make CS and PS calls Execute controlled switchover to ETPT. Make sure that a call does not drop. Make a new CS and PS calls. 2. Make CS and PS calls Execute controlled switchover to ETPE. Make sure that a call does not drop. Make a new CS and PS calls. Expected results Switchover is performed successfully. Ongoing calls are continued in the new active unit. The new active unit is able to serve new calls. 53. SIV3_S15_PAbis_342 Objective Forced switchover of ETPT and ETPE due to HW alarm Test purpose To verify that Forced switchover of ETPT and ETPE due to HW alarm succeeded. Required test environment BSC3i 1000/2000 or Flexi BSC with S15 SW. Packet Abis supported BTS Test execution 1. Make CS and PS calls Execute forced switchover to ETPT by causing one of the next alarm. hw block failure in PIU (2794) hotlink failure (1340) Ethernet interface failure (3053) Make a new CS and PS calls in the new active unit. Verify that traffic between BTS and ETPT succeed. 2. Make CS and PS calls Execute forced switchover to ETPE by causing one of the next alarm. hw block failure in PIU (2794) hotlink failure (1340) Ethernet interface failure (3053) Make a new CS and PS calls in the new active unit. Verify that traffic between BTS and ETPE succeed. Expected results Switchover is performed successfully The new active unit is able to serve new calls

Note! DX recovery system sets the state of failed unit into TE and starts diagnostics. Linked requirements

54. SIV3_S15_PAbis_343 Objective Forced switchover of ETPT and ETPE due to total HW failure Test purpose To verify that forced switchover of ETPT and ETPE due to total HW failure succeeded. Required test environment BSC3i 1000/2000 or Flexi BSC with S15 SW. Packet Abis supported BTS Test execution 1. Make CS and PS calls Execute forced switchover to ETPT by causing one of the next alarm. hw block failure in PIU (2794) Make a new CS and PS calls in the new active unit. Verify that traffic between BTS and ETPT succeed. 2. Make CS and PS calls Execute forced switchover to ETPE by causing one of the next alarm. hw block failure in PIU (2794) Make a new CS and PS calls in the new active unit. Verify that traffic between BTS and ETPE succeed. Expected results Switchover is performed successfully The new active unit is able to serve new calls Note! Active ETPx fails totally and cannot send an alarm. The pair unit sets an alarm where the object is the failed pair. Linked requirements 55. SIV3_S15_PAbis_344

Forced switchover of ETPT and ETPE due to forced state change Test purpose To verify that forced switchover of ETPT and ETPE due to forced state change succeeded. Required test environment BSC3i 1000/2000 or Flexi BSC with S15 SW. Packet Abis supported BTS Test execution 1. Make CS and PS calls Execute uncontrolled (forced) switchover to ETPT. From WO-EX to BL using forced state change. Make a new CS and PS calls in the new active unit. Verify that traffic between BTS and ETPT succeed. 2. Make CS and PS calls Execute uncontrolled (forced) switchover to ETPE. From WO-EX to BL using forced state change. Make a new CS and PS calls in the new active unit. Verify that traffic between BTS and ETPT succeed. Expected results Switchover is performed successfully The new active unit is able to serve new calls Linked requirements 56. SIV3_S15_PAbis_345 Objective Forced switchover of ETPT and ETPE due to restart Test purpose To verify that forced switchover of ETPT and ETPE due to restart succeeded. Required test environment BSC3i 1000/2000 or Flexi BSC with S15 SW. Packet Abis supported BTS Test execution 1. Make CS and PS calls Restart active unit by MML command (USU) or by the Recovery system (e.g.due to unit supervision failure)

Recovery system ordered uncontrolled (forced) switchover to ETPT. After recovery make a new CS and PS calls in the new active unit. Verify that traffic between BTS and ETPT succeed. 2. Make CS and PS calls Restart active unit by MML command (USU) or by the Recovery system (e.g.due to unit supervision failure) Recovery system ordered uncontrolled (forced) switchover to ETPE. After recovery make a new CS and PS calls in the new active unit. Verify that traffic between BTS and ETPE succeed. Expected results Switchover is performed successfully The new active unit is able to serve new calls Note! In this case the unit main working state will not change, i.e. it is still WO, although switchover shall take place. Linked requirements

57. SIV3_S15_PAbis_347 Objective Failure of Active ETPT and ETPE when the pair unit is BL Test purpose To verify that ongoing calls shall cleared during the switchover procedure if the redundant unit is in BL state. Required test environment BSC3i 1000/2000 or Flexi BSC with S15 SW. Packet Abis supported BTS Test execution 1. Change the state of the redundant ETPT to BL. Make CS and PS calls through active ETPT. 1.1 Active ETPT detects a HW failure and sends an alarm. DX recovery system execute switchover. DX recovery system sets the state of failed unit into TE and starts diagnostics 1.2 Active ETPT fails totally and cannot send an alarm. The pair (redundant) unit sets an alarm where the object is the failed pair. DX recovery system execute switchover. DX recovery system sets the state of failed unit into TE and starts diagnostics

Change the state of the new active ETPT unit state to WO-EX. Make a new CS and PS calls in the new active unit. After the fault is cleared, change the previous active unit to WO-EX. Execute switchover with the these two ETPTs Make a new CS and PS calls. 2. Change the state of the redundant ETPE to BL. Make CS and PS calls through active ETPE. 2.1 Active ETPE detects a HW failure and sends an alarm. DX recovery system execute switchover. DX recovery system sets the state of failed unit into TE and starts diagnostics 2.2 Active ETPE fails totally and cannot send an alarm. The pair (redundant) unit sets an alarm where the object is the failed pair. DX recovery system execute switchover. DX recovery system sets the state of failed unit into TE and starts diagnostics Change the state of the new active ETPE unit state to WO-EX. Make a new CS and PS calls in the new active unit. After the fault is cleared, change the previous active unit to WO-EX. Execute switchover with the these two ETPEs Make a new CS and PS calls. Expected results Switchover is performed successfully, but ongoing calls shall clear. The new active unit is able to serve new calls after the state change to WO-EX. Note! ETP-219 Failure of Active ETPT and ETPE when the pair unit is BL.

58. SIV3_S15_PAbis_302 Objective REMOVE PCU - ETP CONNECTION Test purpose To verify that Removing PCU - ETP connection succeeds. Required test environment BSC3i 1000/2000 or Flexi BSC with S15 SW. Packet Abis supported BTS Test execution Delete Packet Abis connection over TDM Delete Packet Abis connection over Ethernet Remove PCU - ETP connection

Expected results Deletion of Packet Abis connection over TDM succeed. Deletion of Packet Abis connection over Ethernet succeed. Deletion of connection between PCU and ETP succeed. Linked requirements BSS21231-115 ETP handling MML. BSS21231-116 Outputting the ETP and HDLC link information. BSS21231-301 ETP-PCU connection configuration. BSS21231-302 Enabling GPRS/EGPRS

PCP FUNCTIONAL TESTING

Alarm 3415 is cancelled when fixed PS load in all PCUs is lower than alarms cancellation load limit The purpose is to test that in mixed PSE configuration (PSE with PCUM and PCU2-D/E cards) alarm 3415 (GPRS/EDGE LOAD IS VERY HIGH IN PCU OF PSE) is cancelled and its cancelled only in case that fixed PS load of all PCUs in PSE is lower than the alarms cancellation load limit. There is only one alarm for the PSE even if fixed PS load of several PCUs would be higher than the alarm load limit. Segment's PS load information is not initialised when alarm 3415 is cancelled. Preconditions: - 2 PS-ext boxes in use - One PSE with 2*PCUM, 1*PCU2-D and 1*PCU2-E - POAT = 50 - Alarm 3415 is not active for the PSE - There are enough segments in all PCU's - Fixed PS load of all PCUs is lower than the alarm's load limit - Fixed PS load of all PCUs is anyway so high that alarm 3415 can be triggered by increasing PS load of segments. - PS load of all segments is 0. Execution: 1. Increase PS load of segments in first PCUM (e.g. with cell_load_info_s messages) so that fixed PS load of PCUM is getting higher than alarm's 3415 load limit. - Alarm 3415 is set for PSE/PCUM 2. Increase PS load of segments in second PCUM (e.g. with cell_load_info_s messages) so that fixed PS load of second PCU2M is also getting higher than alarm's 3415 load limit. - The same alarm 3415 is still active for PSE/first PCUM 3. Repeat the same also to PCU2-D and PCU2-E 4. Decrease PS load of segments in first PCUM so much that fixed PS load of PCUM is getting below alarm's cancellation load limit. (e.g. send cell_load_info_s messages 27 times per segment) - Fixed PS load of first PCUM is getting lower than alarm's 3415 cancellation load limit - The same alarm 3415 is still active for PSE/first PCUM because load in second PCUM and PCU2D/E are still higher than the alarm's cancellation load limit

5. Decrease PS load of segments in second PCUM so much that fixed PS load of PCUM is getting lower than the alarm's cancellation load limit. (e.g. send cell_load_info_s messages 27 times per segment) - Fixed PS load of second PCUM is getting lower than alarm's 3415 cancellation load limit - The same alarm 3415 is still active for PSE/second PCUM because load PCU2-D/E are still higher than the alarm's cancellation load limit 6. Decrease PS load of segments in PCU2-D so much that fixed PS load of PCU2-D is getting lower than the alarm's cancellation load limit. (e.g. send cell_load_info_s messages 27 times per segment) - Fixed PS load of PCU2-D is getting lower than alarm's 3415 cancellation load limit - The same alarm 3415 is still active for PSE/PCUM's and PCU2-D because load PCU2E is still higher than the alarm's cancellation load limit. 7. Decrease PS load of segments in PCU2-E so much that fixed PS load of PCU2-E is getting lower than the alarm's cancellation load limit. (e.g. send cell_load_info_s messages 27 times per segment) - Fixed PS load of PCU2-E is getting lower than alarm's 3415 cancellation load limit - Alarm 3415 is cancelled for PSE/PCUM's and PCU2-D 8. Check that segment's; PS load values were not initialised. - All segments have still correct PS load values. Same values which they had before cancellation of the alarm. - PS load value of any segment is not initialised to value FF. Alarm 3415 is set if fixed PS load in some PCU is higher than alarms load limit after enabling GPRS The purpose is to test that in mixed PSE configuration (PSE with PCUM and PCU2-D/E cards) alarm 3415 (GPRS/EDGE LOAD IS VERY HIGH IN PCU OF PSE) is set in case that fixed PS load of some PCU is getting higher than the alarm's load limit after enabling GPRS. Preconditions: - 2 PS-ext boxes -2*PCUM, 1*PCU2-D, 1*PCU2-E - POAT = 50 - Alarm 3415 is not active for the PSE - There is no PS load/traffic in any segment. It could cause unpredictable results during this test case. First PCUM and PCU2-D/E

- There are enough segments in PCUM and PCU2-D/E - There are enough default channels in every segment (CDEF=100). - Fixed PS load of First PCUM and PCU2-D/E are just a bit lower than the alarm's load limit. - GPRS of some segments is disabled. It's possible to trigger alarm 3415 by enabling GPRS of these segments. - PS load of all segments = 0 Second PCUM - There are some segments in second PCUM - Fixed PS load of second PCUM is clearly lower than alarm's 3415 load limit. Execution: 1. Enable GPRS from some segments of first PCUM and PCU2-D/E. Enabling is done from so many segments that fixed PS load of first PCUM and PCU2-D/E is getting higher than alarms 3415 load limit. - Alarm 3415 is set because fixed PS load of fist PCUM and PCU2-D/E is higher than the alarm's load limit.

Alarm 3415 is not cancelled after reallocation if fixed PS load in some PCUs is still higher than alarms cancellation load The purpose is to test that in mixed PSE configuration (PSE with PCUM and PCU2-D/E cards) alarm 3415 (GPRS/EDGE LOAD IS VERY HIGH IN PCU OF PSE) is not cancelled in case that fixed PS load of some PCU is still higher than the alarm's cancellation load limit after reallocation. Preconditions: - 2 PS-ext boxes - 2*PCUM, 1*PCU2-D, 1*PCU2-E - POAT = 50 - PSAT = 50 - Alarm 3415 is active for the PSE/first PCUM and PCU2-D/E First PCUM and PCU2-D/E - There are enough segments in first PCUM/PCU2-D/E - Fixed PS load of first PCUM/PCU2-D/E is higher than the alarm's load limit - Fixed PS load of first PCUM/PCU2-D/E is higher than reallocation limit Second PCUM - There are enough segments in second PCUM - Fixed PS load of second PCUM is lower than the alarm's load limit - Fixed PS load of second PCUM is lower than reallocation limit

- Fixed PS load of second PCUM is anyway so high that it's not possible to move enough segments from first PCUM and PCU2-D/E to second PCUM in order to cancel the alarm 3415.

Execution: 1. Start reallocation by MML ZFXF:P:PSEI=X; - Reallocation is started and at least one segment is moved from first PCUM/PCU2-D/E to second PCUM. - Alarm 3415 is not cancelled because load of first PCUM/PCU2-D/E is still higher than the alarm's cancellation load limit.

PCP reallocation after ETPE restart Description: To verify that PCP reallocation works fine after ETPE restart Pre-requirements: - 2 PS-ext boxes - PSE with 4 PCU2s (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) - Dynamic NSE created. - enough segments Test execution: - Restart ETPE. - After the restart is over trigger PCP reallocation Expected results: - ETPE is up and running after the restart - PCP reallocation is executed and all segments are working after it.

PCP Change weights of SGSN endpoints Description: Verify that SGSN initiated Changeweight procedure (SGSN changes weights of its endpoints) works with PCP Pre-requirements:

* 2 PS-ext boxes * PSE with 4 PCU2s (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) * Dynamic NSE created. Test execution: * Trace Gb. * Change weights of NSE endpoint in SGSN. ZFWO:NSEI=<nse_id>:NEWLDW=<new_weight>,NEWLSW=<new_weight>,NE WMODE=1; * Output NSE info from all PCUs in the PSE. ZFXI:BCSU=<bcsu>,PCU=<pcu>; Expected results: * Check Gb trace: - SGSN sends SNS-CHANGEWEIGHT to a PCU, which replies with SNS-ACK (without cause field). NSE output shows that all PCUs in the PSE have same SGSN endpoint weights.

PCP Change PCU IP address Description: Verify that changing PCU IP address is successful with PCP. Pre-requirements: * 2 PS-ext boxes * PSE with 4 PCUs (1 PCUM from both PS-boxes and one PCU2-D & PCU2-E from the BSC) * Dynamic NSE created. * Working RNW. Test execution: * Remove PCU IP address. ZQRG:BCSU,<bcsu>:PCUM/PCU2D/E,<pcu>:IFETH0; ZQRG:BCSU,<bcsu>: PCUM/PCU2D/E,<pcu>:IFETH1; ZQKA::BCSU,<bcsu>: PCUM/PCU2D/E,<pcu>; * Watch alarms. * Create new IP address to the PCU. ZQRN:BCSU,<bcsu>: PCUM/PCU2D/E,<pcu>:IFETH0:<new IP address>,L:<netmask length>; ZQRN:BCSU,<bcsu>: PCUM/PCU2D/E,<pcu>:IFETH1:<new IP address>,L:<netmask length>; ZQKC:BCSU,<bcsu>: PCUM/PCU2D/E,<pcu>::<new default gateway address>;

* Start data transfer. Expected results: * Check Gb trace: - PCU sends SNS-DELETE to remove the old endpoint. - PCU sends SNS-ADD to create the new endpoint. Data transfer is successful.

PCP BSC restart Description: Verify that PCP comes up and works after BSC restart. Pre-requirements: * 2 PS-ext boxes * PSE with 4 PCUs. (1 PCUM from both PS-boxes and one PCU2-D & PCU2-E from the BSC) * Working RNW. Test execution: * Restart BSC system. * After system is up, output NSE info from all PCUs in the PSE. * Start data transfer. Expected results: * NSE output shows that all PCUs in the PSE have same SGSN endpoints. Data transfer is successful. PCP BCSU switchover Description: Verify that PCP works after BCSU switchover (both host and gateway BCSU). Pre-requirements: * PSE with PCUM cards from both PS-ext boxes Dynamic NSE. * Working RNW. Test execution: * Start data transfer on the PCU which will be switched over. * Trace Gb. * Do BCSU switchover. * After system is up, output NSE info from all PCUs in the PSE.

Expected results: * Check Gb trace: - After new PCU comes up, it starts sending NS-ALIVE to all SGSN endpoints. SNS-ADD is not sent. - The PCU performs PTP BVC reset for its cells. * NSE output shows that all PCUs in the PSE have same SGSN endpoints. Data transfer continues. PCP BCSU restart Description: Verify that PCP works after BCSU restart (both host and gateway BCSU). Pre-requirements: * PSE with 4 PCUs in different BCSUs. (1 PCUM from both PS-boxes and one PCU2-D & PCU2-E from the BSC) * Dynamic NSE. * Working RNW. Test execution: * Start data transfer. * Trace Gb. * Restart BCSU which has PCU in PSE. * After system is up, output NSE info from all PCUs in the PSE. Expected results: * Check Gb trace: - From SGSN, NS-STATUS messages for all NS-VCs on the restarted PCU. - After restarted PCU comes up, it starts sending NS-ALIVE to all SGSN endpoints. SNS-ADD is not sent. - Restarted PCU performs PTP BVC reset for its cells. * NSE output shows that all PCUs in the PSE have same SGSN endpoints. Data transfer is successful.

PSE reset with static NSE in PCP Description: PSE/NSE reset works with static NSE configuration in PCP. Pre-requirements: * PSE with 4 PCUs in different BCSUs. (1 PCUM from both PS-boxes and one PCU2-D & PCU2-E from the BSC)

* Static NSE created. * Working RNW. Test execution: * Start data transfer. * Trace Gb. * Reset PSE/NSE. ZFXR:PSEI=<psei>; ZFXR:NSEI=<nsei>; Expected results: * Check Gb trace: - One PCU performs Signalling BVC reset. - All PCUs perform PTP BVC resets for their cells. Data transfer continues undisturbed. PCP PSE reset with dynamic NSE in PCP Description: PSE/NSE reset works with dynamic NSE configuration in PCP. Pre-requirements: * PSE with 4 PCUs in different BCSUs. (1 PCUM from both PS-boxes and one PCU2-D & PCU2-E from the BSC) * Dynamic NSE created. * Working RNW. Test execution: * Start data transfer. * Trace Gb. * Reset PSE/NSE. ZFXR:PSEI=<psei>; ZFXR:NSEI=<nsei>; Expected results: * Check Gb trace: - One PCU performs Size and Configuration procedures and Signalling BVC reset. - Other PCUs perform Add procedure. - All PCUs perform PTP BVC resets for their cells. Data transfer continues undisturbed.

PCP O&M operations during BCSU restart

Description: Verify that PCP O&M operations are handled sanely during BCSU restart. Pre-requirements: PSE with 4 PCUs (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) Test execution: 1) NSE creation during BCSU restart * Trace Gb. Restart BCSU which has PCU in PSE. * While the BCSU is restarting, create NSE to the PSE. * After system is up, output NSE info from all PCUs in the PSE. * Output NSE info from SGSN. 2) NSE deletion during BCSU restart Create NSE to PSE. Trace Gb. * Restart BCSU which has PCU in PSE. * While the BCSU is restarting, delete NSE from the PSE. * After system is up, output NSE info from all PCUs in the PSE. * Output NSE info from SGSN. 3) Adding PCU to PCP during BCSU restart Create NSE to PSE. Restart BCSU which has PCU in PSE. * While the BCSU is restarting, add another PCU to the PSE. * After system is up, output NSE info from all PCUs in the PSE. * Output NSE info from SGSN. 4) Removing PCU from PCP during BCSU restart Create NSE to PSE. Restart BCSU which has PCU in PSE. * While the BCSU is restarting, remove one PCU from the PSE. * After system is up, output NSE info from all PCUs in the PSE. * Output NSE info from SGSN. * Reset NSE. * Output NSE info from BSC and SGSN. 5) PCP reallocation during BCSU restart * Create NSE to PSE. Create RNW to PSE. * Trace Gb. * Restart BCSU which has PCU in PSE. * While the BCSU is restarting, perform PSE reallocation. * After system is up, output NSE info from all PCUs in the PSE. * Output NSE info from SGSN.

* Output RNW configuration. * Start data transfer. Expected results: 1) NSE creation during BCSU restart * MML rejects the operation with error code incorrect_unit_state_ec. -- or -* Check Gb trace: - After coming up, PCU in restarted BCSU sends SNS-ADD (dynamic) or NSALIVE to all SGSN endpoints (static). * BSC NSE output shows that all PCUs in the PSE have same SGSN endpoints. * SGSN NSE output shows that all PCUs are added to the NSE (dynamic). 2) NSE deletion during BCSU restart * Check Gb trace: - Resetting PCUs (BSC endpoints) are not deleted from SGSN with SNS-DELETE (dynamic). * BSC NSE output shows that NSE is deleted from all PCUs in the PSE. * SGSN NSE output shows that resetting PCUs are not deleted from NSE (dynamic). 3) Adding PCU to PCP during BCSU restart * MML rejects the operation with error code incorrect_unit_state_ec (dynamic). MML rejects the operation with error code no_nse_configuration_ec (static). 4) Removing PCU from PCP during BCSU restart BSC NSE output shows that all remaining PCUs in the PSE have same SGSN endpoints. SGSN NSE output shows first that removed PCUs is not deleted from NSE (dynamic). * After NSE reset, the removed PCU is deleted from SGSN NSE (dynamic). 5) PCP reallocation during BCSU restart * MML rejects the operation with error code incorrect_unit_state_ec. -- or -* Check Gb trace: - After coming up, PCU in restarted BCSU sends SNS-ADD (dynamic) or NSALIVE to all SGSN endpoints (static). - After coming up, PCU in restarted BCSU does PTP BVC reset to all its BVCs. * BSC NSE output shows that all PCUs in the PSE have same SGSN endpoints. * SGSN NSE output shows that all PCUs exist in the NSE (dynamic). * RNW reallocation is performed without problems. Data transfer is successful.

PCP Move Segment from PCP to another

Description: The operator can move GPRS segment from PSE to another by disabling and enabling GPRS in Segment. Pre-requirements: * 2 PCP with 2 PCUMs (2 PS-ext boxes in use). 2 segments in use Test execution: * Move segment from PCP to another. ZEQV:SEG=x:GENA=N; ZEQV:SEG=x:GENA=Y,:PSEI=x; Expected results: Modification is successful and data transfer is possible.

PCP MCMU switchover Description: Verify that PCP works after MCMU switchover. Pre-requirements: * PSE with 4 PCUs (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) Working RNW. Test execution: * Do MCMU switchover. * After system is up, output NSE info from all PCUs in the PSE. * Start data transfer. * Repeat test case with forced switchover. Expected results: * NSE output shows that all PCUs in the PSE have same SGSN endpoints. Data transfer is successful.

PCP MCMU hot restart Description: Verify that PCP comes up and works after MCMU hot restart.

Pre-requirements: * PSE with 4 PCUs (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) Working RNW. Test execution: * Hot restart WO-EX MCMU. * After system is up, output NSE info from all PCUs in the PSE. * Start data transfer. Expected results: * NSE output shows that all PCUs in the PSE have same SGSN endpoints. Data transfer is successful

PCP LAN disconnect, static NSE Description: Verify that BSC can recover from Gb break when PCP is used. Pre-requirements: * PSE with 4 PCUs (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) * Static NSE created. Working RNW. Test execution: 1) * Trace Gb. * Disconnect all outgoing PCU LAN cables from BSC. * Wait until alarm 3019 set. * Output NSE info from all PCUs in the PSE. ZFXI:BCSU=<bcsu>,PCU=<pcu>; * Reconnect LAN cables. * Output NSE info from all PCUs in the PSE. ZFXI:BCSU=<bcsu>,PCU=<pcu>; * Start data transfer. 2) * Trace Gb. * Disconnect LAN cables from one PCU. * Wait until alarm 3019 set. * Output NSE info from all PCUs in the PSE.

ZFXI:BCSU=<bcsu>,PCU=<pcu>; * Reconnect LAN cables. * Output NSE info from all PCUs in the PSE. ZFXI:BCSU=<bcsu>,PCU=<pcu>; * Start data transfer. Expected results: 1) * Check Gb trace: - NS-STATUS messages for all NS-VCs. - All PCUs keep on sending NS-ALIVE to all SGSN endpoints. - When LAN connection is restored, SGSN replies with NS-ALIVE-ACK. - One PCU performs signalling BVC reset. - All PCUs perform PTP BVC reset for their cells. * NSE output shows that all PCUs in the PSE have same SGSN endpoints. * Any set alarms are canceled. * Data transfer is successful. 2) * Check Gb trace: - NS-STATUS messages for all NS-VCs in disconnected PCU. - Disconnected PCU keeps on sending NS-ALIVE to all SGSN endpoints. - When LAN connection is restored, SGSN replies with NS-ALIVE-ACK. - Disconnected PCU performs PTP BVC reset for its cells. * NSE output shows that all PCUs in the PSE have same SGSN endpoints. * Any set alarms are cancelled. Data transfer is successful

PCP Inter-PCU cell change Description: Verify that inter-PCU cell change works with PCP. Pre-requirements: * PSE with 4 PCUs (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) * Working NSE and RNW. Test execution: * Trace Gb. * Start data transfer. * Do cell change: PS-box <-> PS-box and PS-box <-> PCU2-D/E

Expected results: * Check Gb trace: - SGSN sends FLUSH-LL to some PCU (which forwards it to source PCU thru inter-PCU interface). - Source PCU sends FLUSH-LL-ACK to SGSN. Data transfer continues undisturbed.

PCP Forced BCSU switchover Description: Verify that PCP works after forced BCSU switchover (both host and gateway BCSU's). Pre-requirements: * PSE with 4 PCUs (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) * Dynamic NSE. * Working RNW. Test execution: * Start data transfer on the PCU which will be switched over. * Trace Gb. * Do forced BCSU switchover. ZUSC:BCSU,<bcsu>:SP:FCD; * After system is up, output NSE info from all PCUs in the PSE. ZFXI:BCSU=<bcsu>,PCU=<pcu>; Expected results: * Check Gb trace: - After new PCU comes up, it starts sending NS-ALIVE to all SGSN endpoints. SNS-ADD is not sent. - The PCU performs PTP BVC reset for its cells. * NSE output shows that all PCUs in the PSE have same SGSN endpoints. Data transfer continues.

PCP Delete static NSE with multiple NS-VLs from PCP Description: Static NSE configuration can be deleted from PCP. Pre-requirements:

* PSE with 4 PCUs (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) * SGSN has PAPU group with at least 4 PAPU units. Static NSE configuration. Test execution: * Delete each SGSN endpoint from NSE in BSC, one at a time. ZFXH:... Expected results: All SGSN endpoints and NSE removed successfully from BSC.

PCP Delete some SGSN endpoints Description: Verify that SGSN initiated Delete procedure (SGSN deletes some of its endpoints) works with PCP. Pre-requirements: * PSE with 4 PCUs (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) * SGSN with PAPU group with at least 4 PAPU units. Dynamic NSE created. * Working RNW. Test execution: * Start data transfer. * Trace Gb. * Delete at least two endpoints (with one command) from the NSE in SGSN. At least one endpoint shall remain. - Set weights for all PAPUs: ZFWM:DYN:NSEI=<nsei>:NEWLSW=1,NEWLDW=1:PAPU=<papu>; - Set NSE to operator mode: ZFWM:DYN:NSEI=<nsei>:NEWMODE=1; - Set the remaining PAPUs (other PAPUs are deleted): FWM:DYN:NSEI=3501:PAPUS=<remaining PAPUs>; * Output NSE info from all PCUs in the PSE. ZFXI:BCSU=<bcsu>,PCU=<pcu>; Expected results: * Check Gb trace:

- SGSN sends single SNS-DELETE with multiple endpoints to a PCU, which replies with SNS-ACK (without cause field). * NSE output shows that all PCUs in the PSE have same SGSN endpoints. Data transfer continues undisturbed.

PCP Delete and recreate NSE in SGSN Description: Verify that NSE deletion and recreation in SGSN works with PCP. Pre-requirements: * PSE with 4 PCUs (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) * Dynamic NSE created. * Working RNW. Test execution: * Trace Gb. * Delete NSE from SGSN. * Output NSE info from all PCUs in the PSE. * Recreate the NSE back to SGSN. * Output NSE info from all PCUs in the PSE. * Start data transfer. Expected results: * Check Gb trace: - SGSN sends SNS-DELETE to a PCU, which replies with SNS-ACK (without cause field). - One PCU starts sending SNS-SIZE to SGSN, which doesn't answer. NSE output shows that no PCU in PSE has any SGSN endpoints. - SGSN answers with SNS-SIZE-ACK, and Configuration procedure is performed. - One PCU performs signalling BVC reset. - Other PCUs perform Add procedure. - All PCUs perform PTP BVC reset for their cells. NSE output shows that all PCUs in PSE have same SGSN endpoints. Data transfer is successful

PCP Create static NSE with multiple NS-VLs to PCP

Description: Static NSE configuration can be used with PCP. Pre-requirements: * PSE with 4 PCUs (one PCUM-card from both PS-boxes and one PCU2-D & PCU2-E from the BCS) * SGSN has PAPU group with at least 3 PAPU units. Test execution: * Create static NSE with all BSC endpoints (PCUs) to SGSN. * Create static NSE with 1st SGSN endpoint (PAPU) to BSC. * Add additional SGSN endpoints to NSE in BSC. * Create RNW and start data transfer. Expected results: Data transfer is successful

PCP UNIT INTEGRATION TESTING

Automatic PCU selection according to PCUM capacity during GPRS enabling The purpose is to test that PCU with most amount of available DSP capacity is correctly selected for segment during GPRS enabling. Combined mcBSC (PCU capacity extension) is used and there are three types of PCUs (PCU2D, PCU2E and PCUM) in same PCU pool. Preconditions: - There are three types of PCUs in PSE-1: PCU2D-4, PCU2E-6, PCUM-10. - There are a lot of enabled (GENA=Y) segments in every PCU - There are also some not enabled segments (GENA=N) which can be enabled to PSE-1 during testing. - Channels NS-VLs and BVCs are up and working in every PCU - It's possible to transfer data in some segment of every PCU. a) - There is enough DSP capacity for every segment in every PCU - The amount of available DSP capacity is close to each other in every PCU b) - There is just enough DSP capacity available for some segments in every PCU - Limit for available DSP capacity will be exceeded in every PCU when some new segments are enabled to them. c) - Limit for available DSP capacity has been exceeded in every PCU already. - Deficit for DSP capacity is same in every PCU Execution: 1.) Enable several new EGPRS segments to PSE-1 ZEQV:BTS=1:GENA=Y,:PSEI=1: - GPRS of every segment is successfully enabled - PCU is correctly selected for every segment - PCU with most amount of available DSP capacity or smallest deficit for DSP capacity is selected. Note! PCUs which have BTSs with same BCF have to be taken into account

mcPCU switchover does not reset NSE when mcBSC belongs to PCU pool The purpose is to test that mcPCU switchover does not reset NSE when mcPCU belongs to PCU pool. Preconditions: - There are three types of PCUs in PSE-1: PCU2D, PCU2E and PCUM. (e.g. PCU2D-4, PCU2D-5, PCU2E-6, PCU2E-8, PCUM-10 and PCUM-12) - Channels, NS-VLs and BVCs are up and working in every PCU - It's possible to transfer data in some segment of every PCU. - Gb interface and DX messages of GBADMI are monitored Execution: 1.) Initiate PCUM switchover by MML ZUSW:... - PCUM switchover is performed - There is no NSE reset. - GBA indicates correct NSE procedure for PCUMs concerning switchover. - NSE in other PCUs stay up and running all the time. 2.) Check that all channels, NS-VLs and BVCs are up and working after reallocation - All channels, NS-VLs and BVCs are up and working after reallocation. 3.) Start data transfer in some segment of every PCU - Data is successfully transferred

PCU adding to PCU pool with reallocation The purpose is to test that different PCU types (PCU2D, PCU2E and PCUM) can be successfully added to PCU pool so that reallocation is allowed during adding. All channels are successfully up and working after reallocation. Preconditions: - There are two types of PCUs in PSE-1 already. - There are some segments in all PCUs. - Fixed PS load of one PCU (source) is higher than reallocation load limit. Several segments haves to be moved from source PCU during reallocation. - Fixed PS load of other PCU's (target) is lower than reallocation load limit. - Channels, NS-VLs and BVCs are up and working. Execution

1.) Add new PCU into PSE-1. Type on new PCU is different than those which are included in PSE-1 already. Allow reallocation. a) PCU2D type PCU is added to PSE-1 b) PCU2E type PCU is added to PSE-1 c) PCUM type PCU is added to PSE-1 ZFXF:A:BCSU=0,PCU=6,PSEI=1:RAE=Y; - New PCU is added to PSE-1 - Several segments are moved from source PCU 2.) Check that channels, NS-VLs and BVCs are successfully up and working after reallocation. - Channels, NS-VLs and BVCs are successfully up and working after reallocation 3.) Start data transfer in some segment of every PCU - Data is successfully transferred

PCU adding to PCU pool with reallocation is rejected in case that some PCU in PCU pool is not in working state The purpose is to test that PCU adding to PCU pool with reallocation is rejected in case that one PCU in PCU pool is not in working state. a) One PCU is in configuring state because of PCU's hot restart b) One PCU is in restarting state because of PCU's cold restart Preconditions: a) and b) - There are three types of PCUs in PSE-1: PCU2D, PCU2E and PCUM - PCUs are in working state - There are some segments in all PCUs. - Fixed PS load of one PCU (source) is higher than reallocation load limit. Some segments have to be moved from source PCU during reallocation. - Fixed PS load of other PCU's (target) is lower than reallocation load limit. - Channels, NS-VLs and BVCs are up and working. a) Execution: 1.) Initiate hot restart for one PCU2D or PCU2E by MML - The PCU is restarted - The PCU's state is changed to configuring 2.) Try to add new PCU to PSE-1 several times while the other PCU is restarting. Allow reallocation. a) Try to add PCU2D type PCU to PSE-1 b) Try to add PCU2E type PCU to PSE-1 c) Try to add PCUM type PCU to PSE-1 ZFXF:A:BCSU=0,PCU=6,PSEI=1:RAE=Y;

- PCU's adding is every time rejected with error 17559 (PCU CONFIGURATION IS IN PROGRESS) 3.) Wait until restarted PCU is in working state 4.) Add new PCU into PSE-1. Allow reallocation. a) Add PCU2D type PCU to PSE-1 b) Add PCU2E type PCU to PSE-1 c) Add PCUM type PCU to PSE-1 ZFXF:A:BCSU=0,PCU=6,PSEI=1:RAE=Y; - New PCU is successfully added to PSE/PCU pool - Some segments are moved from source PCU - Channels, NS-VLs and BVCs are successfully up and working after reallocation b) 1.) Initiate cold restart for one PCU2D or PCU2E by MML - The PCU is restarted - The PCU's state is changed to restarting 2.) Try to add new PCU into PSE-1 while the other PCU is restarting. Allow reallocation. a) Try to add PCU2D type PCU to PSE-1 b) Try to add PCU2E type PCU to PSE-1 c) Try to add PCUM type PCU to PSE-1 ZFXF:A:BCSU=0,PCU=6,PSEI=1:RAE=Y; - PCU's adding is every time rejected with error 17561 (PCU IS RESTARTING) 3.) Wait until restarted PCU is in working state 4.) Add new PCU into PSE. Allow reallocation. a) Add PCU2D type PCU to PSE-1 b) Add PCU2E type PCU to PSE-1 c) Add PCUM type PCU to PSE-1 ZFXF:A:BCSU=0,PCU=6,PSEI=1:RAE=Y; - New PCU is successfully added to PSE/PCU pool - Some segments are moved from source PCU - Channels , NS-VLs and BVCs are successfully up and working after reallocation

PCU adding to PCU pool without reallocation The purpose is to test that different PCU types (PCU2D, PCU2E and PCUM) can be successfully added to PCU pool. Reallocation is not allowed during adding. Preconditions: - There are two types of PCUs in PSE-1 already. - There are some segments in all PCUs. - Fixed PS load of one PCU (source) is higher than reallocation load limit. Several segments have to be moved from source PCU during reallocation.

- Fixed PS load of other PCU's (target) is lower than reallocation load limit. - Channels, NS-VLs and BVCs are up and working. Execution 1.) Add new PCU into PSE-1. Type on new PCU is different than those which are included in PSE-1 already. Do not allow reallocation. a) PCU2D type PCU is added to PSE-1 b) PCU2E type PCU is added to PSE-1 c) PCUM type PCU is added to PSE-1 ZFXF:A:BCSU=0,PCU=6,PSEI=1:RAE=Y; - New PCU is added to PSE-1 - Several segments are moved from source PCU 2.) Check that channels, NS-VLs and BVCs are successfully up and working after reallocation. - Channels, NS-VLs and BVCs are successfully up and working after reallocation 3.) Start data transfer in some segment of every PCU - Data is successfully transferred PCU adding to PCU pool without reallocation is rejected in case that some PCU in PCU pool is not in working state The purpose is to test that PCU adding to PCU pool without reallocation is rejected in case that some PCU in PCU pool is not in working state. a) One PCU is in configuring state because of PCU's hot restart b) One PCU is in restarting state because of PCU's cold restart Preconditions: a) and b) - There are three types of PCUs in PSE-1: PCU2D, PCU2E and PCUM - PCUs are in working state - There are some segments in all PCUs. - Fixed PS load of one PCU (source) is higher than reallocation load limit. Some segments have to be moved from source PCU during reallocation. - Fixed PS load of other PCU's (target) is lower than reallocation load limit. - Channels, NS-VLs and BVCs are up and working. a) Execution: 1.) Initiate hot restart for one PCU2D or PCU2E by MML - The PCU is restarted - The PCU's state is changed to configuring 2.) Try to add new PCU to into PSE-1 several times while the other PCU is restarting. Do not allow reallocation. a) Try to add PCU2D type PCU to PSE-1 b) Try to add PCU2E type PCU to PSE-1

c) Try to add PCUM type PCU to PSE-1 ZFXF:A:BCSU=0,PCU=6,PSEI=1:RAE=Y; - PCU's adding is every time rejected with error 17559 (PCU CONFIGURATION IS IN PROGRESS) 3.) Wait until restarted PCU is in working state 4.) Add new PCU into PSE-1. Do not allow reallocation. a) Add PCU2D type PCU to PSE-1 b) Add PCU2E type PCU to PSE-1 c) Add PCUM type PCU to PSE-1 ZFXF:A:BCSU=0,PCU=6,PSEI=1:RAE=Y; - New PCU is successfully added to PSE/PCU pool - Some segments are moved from source PCU - Channels, NS-VLs and BVCs are successfully up and working after reallocation b) 1.) Initiate cold restart for one PCU2D or PCU2E by MML - The PCU is restarted - The PCU's state is changed to restarting 2.) Try to add new PCU into PSE-1 several times while the other PCU is restarting. Do not allow reallocation. a) Try to add PCU2D type PCU to PSE-1 b) Try to add PCU2E type PCU to PSE-1 c) Try to add PCUM type PCU to PSE-1 ZFXF:A:BCSU=0,PCU=6,PSEI=1:RAE=Y; - PCU's adding is every time rejected with error 17561 (PCU IS RESTARTING) 3.) Wait until restarted PCU is in working state 4.) Add new PCU into PSE-1. Do not allow reallocation. a) Add PCU2D type PCU to PSE-1 b) Add PCU2E type PCU to PSE-1 c) Add PCUM type PCU to PSE-1 ZFXF:A:BCSU=0,PCU=6,PSEI=1:RAE=Y; - New PCU is successfully added to PSE/PCU pool - Some segments are moved from source PCU - Channels, NS-VLs and BVCs are successfully up and working after reallocation

PCU pool reallocation The purpose is to test that PCU pool reallocation works correctly with combined mcBSC (PCU capacity extension) when there are three type of PCUs (PCU2D, PCU2E and PCUM) in same PCU pool.

Preconditions: - There are three types of PCUs in PSE-1: PCU2D-4, PCU2D-5, PCU2E-6, PCU2E-8, PCUM-10 and PCUM-12. - Fixed PS load in source PCU is higher than reallocation load limit, so high that several segments have to be moved during reallocation. - Fixed PS load in other PCUs is lower than reallocation load limit. - Channels NS-VLs and BVCs are up and working in every PCU - It's possible to transfer data in some segment of every PCU. Execution: a) Source PCU is PCU2D b) Source PCU is PCU2E c) Source PCU is PCUM 1.) Start reallocation ZFXF:P:PSEI=1; - Reallocation is started - Correct amount of segments are moved from source PCU - Target PCUs are selected correctly 2.) Check that all channels, NS-VLs and BVCs are up and working after reallocation of all unlocked segments are upgraded successfully - Channels of moved segments are upgraded successfully after reallocation - All channels, NS-VLs and BVCs are Channels of not moved segments are up and working after reallocation. 3.) Start data transfer in some segment of every PCU - Data is successfully transferred

PCU pool reallocation threshold for PCU2E and PCUM type PCUs is adjusted with DOP parameter The purpose is to ensure that reallocation load threshold for PCU2E and PCU2M is correctly adjusted according to DOP parameter. Preconditions: - DLDC is in use and there are PCU2Ds together with PCU2Es and PCUMs in the PSE-1 (e.g. PCU2D-4, PCU2D-5, PCU2E-6, PCU2E-8, PCUM-10, PCUM-12) - There are enough segments in order to create suitable amount of load for PCUs: -- a lot of EGPRS segment (segments without DLCC BTSs) -- a lot of DLDC segments (segments with DLDC BTSs) - DOP parameter value is quite high (e.g. 80). Load limit for PCU2E and PCUM type PCUs is higher than load limit for PCU2D type PCUs.

a) - Load of PCU2E-6 is just below reallocation limit so that reallocation can be triggered by adjusting DOP parameter. b) - Load of PCUM-10 is just below reallocation limit so that reallocation can be triggered by adjusting DOP parameter. Execution: 1.) Try to start reallocation by MML ZFXF:P:PSEI=1; - Reallocation is not started because load of every PCU is lower than reallocation load limit 2.) Adjust the value of DOP parameter lower so that reallocation can be started ZEEQ:DOP=70; - The value of DOP parameter is adjusted a) Now the load of PCU2E-6 is higher than load limit b) Now the load of PCUM-10 is higher than load limit 3.) Start reallocation by MML ZFXF:P:PSEI=1; - Reallocation is started a) - PCU2E-6 is source PCU - Correct amount of segments is moved from PCU2E-6 b) - PCUM-10 is source PCU - Correct amount of segments is moved from PCUM-10

PCU removing from PCU pool The purpose is to test that different PCU types (PCU2D, PCU2E and PCUM) can be successfully removed from PCU pool. Segments are correctly moved to remaining PCUs in PCU pool. Preconditions: - There are three types of PCUs in PSE-1: PCU2D, PCU2E and PCUM. - There are some segments in all PCUs. - There is enough capacity in order to remove any PCU from PCU pool - Channels, NS-VLs and BVCs are up and working.

- It's possible to transfer data in every PCU Execution: 1.) Remove one PCU from PSE-1. a) Remove PCU2D type PCU from PSE-1 b) Remove PCU2E type PCU from PSE-1 c) Remove PCUM type PCU from PSE-1 ZFXF:R:BCSU=0,PCU=6; - PCU is successfully removed from PSE-1 - All segments of removed PCU are correctly moved to other remaining PCUs in PCU pool. 2.) Check that all channels, NS-VLs and BVCs are up and working after PCU removing - All channels, NS-VLs and BVCs are up and working 3.) Start data transfer in some segment which was moved from removed PCU-6 - Data is successfully transferred

PCU removing from PCU pool is rejected because of capacity limit The purpose is to test that PCU removing is rejected right away and nothing is moved in case that there is not enough capacity to remove PCU from PCU pool. PCU Preconditions: - There are three types of PCUs in PSE-1/PCU pool: PCU2D, PCU2E and PCUM - There are some segments in all PCUs. - There is not enough space/capacity in PCUs of PSE-1 in order to remove any PCU from PSE. - Channels, NS-VLs and BVCs are up and working. Execution: 1.) Try to remove one PCU from PSE-1. a) Try to remove PCU2D from PSE-1 b) Try to remove PCU2E from PSE-1 c) Try to remove PCU2M from PSE-1 ZFXF:R:BCSU=0,PCU=6; - PCU is not removed from PSE-1 - Any segments are not moved - All channels, NS-VLs and BVCs stay up and working PCU removing from PCU pool is rejected in case that some PCU in PCU pool is not in working state

The purpose is to test that PCU removing from PSE/PCU pool is rejected in case that some PCU in PCU pool is not in working state. a) One PCU is in configuring state because of PCU's hot restart b) One PCU is in restarting state because of PCU's cold restart Preconditions: a) and b) - There are three types of PCUs in PSE-1: PCU2D, PCU2E and PCUM - All PCUs are in working state - There are some segments in all PCUs. - There is enough capacity/space in PSE-1 in order to remove any PCU from the pool. - Channels, NS-VLs and BVCs are up and working a) Execution: 1.) Initiate hot restart for one PCU2D or PCU2E by MML - The PCU is restarted - The PCU's state is changed to configuring 2.) Try to remove some PCU from PSE-1 several times while the other PCU is restarting a) Try to remove PCU2D from PSE-1 b) Try to remove PCU2E from PSE-1 c) Try to remove PCUM from PSE-1 ZFXF:R:BCSU=0,PCU=6; - PCU removing is rejected every time with error 17559 (PCU CONFIGURATION IS IN PROGRESS) 3.) Wait until restarted PCU is in working state 4.) Remove one PCU from PSE-1. a) Remove PCU2D from PSE-1 b) Remove PCU2E from PSE-1 c) Remove PCUM from PSE-1 ZFXF:R:BCSU=0,PCU=6; - PCU is successfully removed from PSE-1 - Segments are correctly moved to other remaining PCUs in PCU pool. - All channels, NS-VLs and BVCs are up and working after PCU removing. b) Execution: 1.) Initiate cold restart for one PCUD or PCU2E by MML - The PCU is restarted - The PCU's state is changed to configuring 2.) Try to remove some PCU from PSE-1 several times while the other PCU is restarting a) Try to remove PCU2D from PSE-1 b) Try to remove PCU2E from PSE-1 c) Try to remove PCUM from PSE-1 ZFXF:R:BCSU=0,PCU=6; - PCU removing is rejected every time with error 17561 (PCU IS RESTARTING)

3.) Wait until restarted PCU is in working state 4.) Remove one PCU from PSE-1. a) Remove PCU2D from PSE-1 b) Remove PCU2E from PSE-1 c) Remove PCUM from PSE-1 ZFXF:R:BCSU=0,PCU=6; - PCU is successfully removed from PSE-1 - Segments are correctly moved to other remaining PCUs in PCU pool. - All channels, NS-VLs and BVCs are up and working PCU removing

PCU2E and PCUM type PCUs are preferred for DLDC BTSs The purpose is to test that PCU2E and PCUM type PCUs are preferred DLDC segments during reallocation. a) Source PCU is PCU2D - DLDC segments are preferably moved away from PCU2D type PCU - PCU2E and PCUM type PCUs are selected for moved DLDC segments - PCU2D type PCU is selected for moved EGPRS segments b) Source PCU is PCU2E EGPRS segments are preferably moved away from PCU2E type PCU - PCU2D type PCUs are selected for moved EGPRS segments - PCU2E and PCUM type PCUs are selected for moved DLDC segments c) Source PCU is PCUM - EGPRS segments are preferably moved away from PCUM type PCU - PCU2D type PCUs are selected for moved EGPRS segments - PCU2E and PCUM type PCUs are selected for moved DLDC segments Preconditions: - There are three types of PCUs in PSE-1: PCU2D, PCU2E and PCUM. (e.g. PCU2D-4, PCU2D-5, PCU2E-6, PCU2E-8, PCUM-10, PCUM-12) - There are enough segments in order to create suitable amount of load for PCUs: a) - Load of PCU2D-4 is higher than reallocation load limit (source PCU)

(several segments are moved from source PCU during reallocation) - Load of other PCUs is lower than reallocation load limit (target PCUs) - There are a lot of EGPRS segments in PCU2D-4 - There are also some DLDC segments in PCU2D-4 - Loads of EGPRS segments in PCU2D-4 are higher than loads of DLDC segments - DLDC segments have at least one adjacent cells in PCU2D-4 and PCU2D-5 b) - Load of PCU2E-6 is higher than reallocation load limit (source PCU) (several segments are moved from source PCU during reallocation) - Load of other PCUs is lower than reallocation load limit (target PCUs) - There are a lot of DLDC segments in PCU2E-6 - There are also some EGPRS segments in PCU2E-6 - Loads of DLDC segments in PCU2E-6 are higher than loads of EGPRS segments - EGPRS segments have at least one adjacent cell in PCU2E-6, PCU2E-8, PCUM-10 and PCUM-12 c) - Load of PCUM-10 is higher than reallocation load limit (source PCU) (several segments are moved from source PCU during reallocation) - Load of other PCUs is lower than reallocation load limit (target PCUs) - There are a lot of DLDC segments in PCUM-10 - There are also some EGPRS segments in PCUM-10 - Loads of DLDC segments in PCUM-10 are higher than load of EGPRS segments - EGPRS segments have at least one adjacent cell in PCUM-10, PCU2E-6, PCU2E-8 and PCUM-12 Execution: a) 1.) Start reallocation by MML command ZFXF:P:PSEI=1 - Reallocation is started - Segments with DLDC BTSs are moved first from PCU2D-4 - DLDC segments are moved to PCU2E or PCUM type PCUs - Also some EGPRS segments are moved after DLDC segments. - EGPRS segments are moved to PCU2D type PCU b) 1.) Start reallocation by MML command ZFXF:P:PSEI=1 - Reallocation is started - EGPRS segments are moved first from PCU2E-6 - EGPRS segments are moved to PCU2D type PCUs - Also some DLDC segments are moved after EGPRS segments.

- DLDC segments are moved to PCU2E and PCUM type PCUs c) 1.) Start reallocation by MML command ZFXF:P:PSEI=1 - Reallocation is started - EGPRS segments are moved first from PCUM-10 - EGPRS segments are moved to PCU2D type PCUs - Also some DLDC segments are moved after EGPRS segments. - DLDC segments are moved to PCU2E and PCUM type PCUs PCUM switchover is rejected during PCU pool reallocation The purpose is to test that PCUM switchover is rejected in case that PCU pool reallocation is ongoing. Preconditions: - There are three types of PCUs in PSE-1: PCU2D, PCU2E and PCUM - All PCUs are in working state - There are some segments in all PCUs - Fixed PS load of one PCU is higher than reallocation load limit. - Fixed PS load of other PCUs is lower than reallocation load limit. - Channels, NS-VLs and BVCs are up and working in every PCU. - It's possible to transfer data in some segment of every PCU. Execution: 1.) Start reallocation ZFXF:P:PSEI=1; - Reallocation is started 2.) Try to initiate PCUM switchover by MML several times during reallocation ZUSW:... - PCUM switchover is every time rejected with Dx error 3.) Wait until reallocation is ready - Reallocation is ready 4.) Initiate PCUM switchover by MML - PCUM switchover is done 5.) Check that channels, NS-VLs and BVCs are successfully up and working after PCUM switchover - Channels, NS-VLs and BVCs are successfully up and working. 6.) Start data transfer in some segment. - Data is successfully transferred

Reallocation is rejected in case that some PCU in PCU pool is not in working state The purpose is to test that PCU pool reallocation is rejected when some PCU in PCU pool is not in working state. a) PCU2D or PCU2E is in configuring state because of PCU's hot restart b) PCU2D or PCU2ED is in restarting state because of PCU's cold restart c) PCUM switchover takes place just before reallocation attempt Preconditions: a), b) and c) - There are three different type of PCUs in PSE-1: PCU2D, PCU2E and PCU2M - All PCUs are in working state - There are some segments in all PCUs - Fixed PS load of one PCU is higher than reallocation load limit. - Fixed PS load of other PCUs is lower than reallocation load limit. - Channels, NS-VLs and BVCs are up and working in every PCU. - It's possible to transfer data in some segment of every PCU. a) Execution: 1.) Initiate hot restart for one PCU2D or PCU2E by MML - The PCU is restarted - The PCU's state is changed to configuring 2.) Try to start PCP reallocation several times while one PCU is restarting. ZFXF:P:PSEI=1; - PCP reallocation is every time rejected with error 17559 (PCU CONFIGURATION IS IN PROGRESS) 3.) Wait until hot restarted PCU is in working state 4.) Start PCU pool reallocation ZFXF:P:PSEI=1; - PCU pool reallocation is successfully started - Channels, NS-VLs and BVCs are successfully up and working after reallocation b) Execution: 1.) Initiate cold restart for one PCU2D or PCU2E by MML - The PCU is restarted - The PCUs state is changed to configuring 2.) Try to start PCU pool reallocation several times while one PCU is restarting. ZFXF:P:PSEI=1; - PCP reallocation is every time rejected with error 17561 (PCU IS RESTARTING) 3.) Wait until cold restarted PCUis in working state 4.) Start PCU pool reallocation ZFXF:P:PSEI=1;

- PCU pool reallocation is successfully started - Channels, NS-VLs and BVCs are up and working after reallocation c) Execution: 1.) Initiate switchover for PCUM by MML ZUSW - The PCUM switchover takes place 2.) Try to start PCU pool reallocation immediately after PCUM switchover command was given ZFXF:P:PSEI=1; - Reallocation is rejected or not depending on timing - Nothing harmful happens - Channels, NS-VLs and BVCs are anyway up and working afterwards

PS EXTENSION
LT_mcBSC_Rel1_Int Integration for mcBSC Rel1 Load Testing OBJECTIVE: Target is to verify the functionality and stability of mcBSC Rel1 to be ready for actual Main Load Tests of mcBSC Rel1. This test case will be executed in each load test environment which is planned for mcBSC Rel1 Main Load Tests TEST CONFIGURATION: Test configuration for each load test environment is described in the test plan, chapter 6.2 'Test Environment Requirements' TEST CASE EXECUTION: Precondition: - mcBSC hardware and software up and running - BSC up and running (Extension configurations) - Other network element's in load test environment (test plan, chapter 6.2) available for integration

Procedure: Step Action 1 Create all necessary GSM/EDGE network interface's (PAbis, AoIP, GboIP) that will be used in the 1st test case of Main Load Test's. => Interface's UP and working 2 Create radio network that will be used in 1st test case of the Main Load Test's => Radio network UP and working 3 Run some PS, CS or combined PS/CS call scenario in the radio network. It is preferred to allocate calls to each BTS/TRX in the radio network => PS and CS calls are successfull 4 Run the previous call scenario 1-3 days to verify basic stability for Main Load Test's => mcBSC and all mcBSC unit's are stable Pass/Fail Criteria All expected result's (=>) in the procedure are PASSED No critical class A or B fault's

SIV4_PA_MGb_PCP_001PSEXT PCP O&M with PS-extension OBJECTIVE: Target is to verify the functionality and stability of PCU2 pool with Packet Abis enabled BTS's and heavy traffic load. TEST CONFIGURATION: BSC: BSC3i 1000/2000/Flexi-BSC with PS-extension PCU2-D, PCU2-E and PCUM units in a PCU2 pool Two ETPE units BSC S15 sw with PA support BTS -emulators: Required amount of PC's to generate 8000 RTSL RNW: Dynamic Territory

Detailed RNW is defined by Testing Engineer

SGSN/GGSN -emulators Required amount of PC's to handle datarate generated by BTS/MS emulators MS -emulators: One GEMU per BCF making 5 min data transfers, One making attach detach loop and one making pdp activation and deactivations TEST CASE EXECUTION: Precondition: BSC: BSC params CSD=0, CSU=0 BTS params CDED=1, CDEF=1, CMAX=100 Following measurements created and activated: PCU, C_SCHEME, RLC_BLOCKS, GbIP Procedure: Step Action 1 Upgrade the radio network 2 Start data transfer 3 Execute one PCP operation (Delete Segment, Create Segment, Remove PCU, Add PCU, Reallocate, Delete Gb, Create Gb or Move Segment) 4 Wait 5 min 5 Data transfer continue on all segments 6 Repeat steps 3-5 2 weeks Postcondition: No permanent synchronization errors No unexpected alarms. No Process exceptions No unexpected log records. BSC measurements can be found through test. No Octeon, PQII or DSP crashes No hanging TBFs, MS's or (E)GPRS Abis radio channels on PCU2/BSC It's possible to make ATTACH and PDP after test is executed without BSCU switchover or restart Pass/Fail Criteria: all the posticonditions are fullfilled the whole test can be executed without BSC/BCSU/ETP restart or switchover

SIV4_PA_DLDC_002 (DLDC & LA) Long term data transfer with LA and TRX based error modeling, several MSs in each cells, GMM procedures and data transfer (PCU2-E) OBJECTIVE: Target is to verify the functionality and stability of PCU2 (Packet Control Unit), with DLDC (Downlink Dual Carrier), EGPRS and GPRS enabled BTS's and traffic/signaling load, when TRX based error modeling and TRX specific link adaptation for DLDC are used. TRX based error modeling is a S15 GEMU feature and TRX specific link adaptation for DLDC is a S15 BSC/PCU2 feature. TEST CONFIGURATION: BSC: Flexi BSC3i One PCU2-E card BTS -emulators: At least 22 Linux-PC's with GEMU emulator (based on three BTS per PC) GEMU sw at least 4.x.x with 'Packet Abis' feature support Three or more BTS per one Linux-PC Two TRX per one BTS RNW: 24x EGPRS BTS (DLDC enabled) 21x EGPRS BTS (DLDC disabled) 21x GPRS BTS SGSN/GGSN -emulators One Linux-PC with GEMU emulator (at least 4.x.x) MS -emulators: Option-1: one Linux-PC with GEMU emulator (at least 4.x.x) controlling all BTS's. Option-2: the use of MS locally in each PC, controlling BTS's in one PC NOTE! It is recommend to use 'MS Launcher' help tool in the execution. For that purpose, the need is one Linux-PC. TEST CASE EXECUTION: Precondition: BSC:

DLDC and EUTM features has been activated in BSC PCU2-E full connectivity in use Gb-if: Gb over IP BSC params CSD=0, CSU=0 BTS params GENA=Y, EGENA=Y, DCENA=Y for DLDC EGPRS BTS's BTS params GENA=Y, EGENA=Y for EGPRS BTS's BTS params GENA=Y for GPRS BTS'sBTS params MCA=<sw default>, MCU=<sw default>, ELA=2, BFG=0 BTS params CDED=1, CDEF=1, CMAX=100 Following measurements created and activated: PCU, C_SCHEME, RLC_BLOCKS, GbIP (15min meas period in use) BTS: BTS param ext_ul_tbfm=1 TRX based error modeling in use separate values for GMSK_MEAN_BEP, GMSK_CV_BEP, 8PSK_MEAN_BEP and 8PSK_CV_BEP in each GEMU PC (tbd by test engineer) let the values change periodically in a way that sometimes another TRX has better link quality than another and sometimes other way round (tbd by test engineer) MS's: Geran-feature-package-1 supported MSCR=0 Multislot Class-10 mobiles (4+4) for DLDC MS's (in DLDC cells) Multislot Class-5 mobiles (2+2) for GPRS and EGPRS MS's 32 or more MS per BTS (Note that there might be some MS's occasionally without GPRS service) TOOL's: Macro or other test application to collect following measurement's PCU2 PQII and DSP load value's PCU2 MS/TBF amount Procedure: Step Action Expected result

1 Upgrade the radio network RNW is upgraded, no synchronization errors 2 Start measurement macro or application Measurement is successfully started. 3 Attach 2112 or more MS's (32 or more per BTS), make PDP CTX and start EGPRS data transfer Attaches and PDP's are successful and data transfer is started

4 After ~10min data transfer, detach all MS's. Use ~5-10sec. delay between BTS's in detach procedures. Attach, make PDP CTX and start EGPRS data transfer right after detaches in every BTS. Detaches are successful in every BTS. Attaches and PDP's are successful and data transfer is started 5 Repeat the step 3 continuously. Wait at least 12h, overnight execution preferred.

6 Check that data transfer is ongoing in every 24 BTS's Data transfer is ongoing. 7 Stop data transfer and make detaches to MS's. Data transfer is stopped and detaches are successful. Postcondition: No unexpected synchronization errors No unexpected alarms. No unexpected log records. BSC measurements can be found through test. No PQII(I) or DSP crashes No hanging TBFs, MS's or (E)GPRS Abis radio channels on PCU2/BSC It's possible to make ATTACH and PDP after test is executed without BSCU switchover or restart Pass/Fail Criteria: all the postconditions are fulfilled the whole test can be executed without BSC/BCSU restart or switchover REFERENCES: BSS 21228 Downlink Dual Carrier, BSC S14, Requirement Specification v.1.1.10 BSS 21392 TRX Specific Link Adaptation for DLDC, BSC S15, Requirement Specification v.1.0.1 BSS21343 DLDC Territory Procedures, BSC S15, Requirement Specification v.1.0.0 GPRS Emulator (GEMU) BSS S15, Requirement Specification v.0.3.0 Chapter 6.4 Individual Carrier LA for DLDC GEMU BSS S15, Individual Carrier LA for DLDC, Design Note v.0.1.0

STANDALONE
LT_mcBSC_Rel1_Int Integration for mcBSC Rel1 Load Testing OBJECTIVE: Target is to verify the functionality and stability of mcBSC Rel1 to be ready for actual Main Load Tests of mcBSC Rel1. This test case will be executed in each load test environment which is planned for mcBSC Rel1 Main Load Tests TEST CONFIGURATION: Test configuration for each load test environment is described in the test plan, chapter 6.2 'Test Environment Requirements' TEST CASE EXECUTION: Precondition: - mcBSC hardware and software up and running - BSC up and running (Extension configurations) - Other network element's in load test environment (test plan, chapter 6.2) available for integration Procedure: Step Action 1 Create all necessary GSM/EDGE network interface's (PAbis, AoIP, GboIP) that will be used in the 1st test case of Main Load Test's. => Interface's UP and working 2 Create radio network that will be used in 1st test case of the Main Load Test's => Radio network UP and working 3 Run some PS, CS or combined PS/CS call scenario in the radio network. It is preferred to allocate calls to each BTS/TRX in the radio network => PS and CS calls are successfull 4 Run the previous call scenario 1-3 days to verify basic stability for Main Load Test's => mcBSC and all mcBSC unit's are stable

Pass/Fail Criteria All expected result's (=>) in the procedure are PASSED No critical class A or B fault's

SIV4_PA_MGb_PCP_001MC PCP O&M with Standalone MC BSC OBJECTIVE: Target is to verify the functionality and stability of PCU2 pool with Packet Abis enabled BTS's and heavy traffic load. TEST CONFIGURATION: BSC: MC BSC PCUM units in a PCU pool ETME unit BSC S15 sw with PA and MC BSC support BTS -emulators: Required amount of PC's to generate 8000 RTSL RNW: Dynamic Territory Detailed RNW is defined by Testing Engineer SGSN/GGSN -emulators Required amount of PC's to handle datarate generated by BTS/MS emulators MS -emulators: One GEMU per BCF making 5 min data transfers, One making attach detach loop and one making pdp activation and deactivations TEST CASE EXECUTION: Precondition: BSC: BSC params CSD=0, CSU=0 BTS params CDED=1, CDEF=1, CMAX=100 Following measurements created and activated: PCU, C_SCHEME, RLC_BLOCKS, GbIP

Procedure: Step Action 1 Upgrade the radio network 2 Start data transfer 3 Execute one PCP operation (Delete Segment, Create Segment, Remove PCU, Add PCU, Reallocate, Delete Gb, Create Gb or Move Segment) 4 Wait 5 min 5 Data transfer continue on all segments 6 Repeat steps 3-5 2weeks Postcondition: No permanent synchronization errors No unexpected alarms. No Process exceptions No unexpected log records. BSC measurements can be found through test. No Octeon, PQII or DSP crashes No hanging TBFs, MS's or (E)GPRS Abis radio channels on PCU2/BSC It's possible to make ATTACH and PDP after test is executed without BSCU switchover or restart Pass/Fail Criteria: all the posticonditions are fullfilled the whole test can be executed without BSC/BCSU/ETP restart or switchover

LT_mcBSC_Rel1_Int Integration for mcBSC Rel1 Load Testing OBJECTIVE: Target is to verify the functionality and stability of mcBSC Rel1 to be ready for actual Main Load Tests of mcBSC Rel1. This test case will be executed in each load test environment which is planned for mcBSC Rel1 Main Load Tests TEST CONFIGURATION: Test configuration for each load test environment is described in the test plan, chapter 6.2 'Test Environment Requirements' TEST CASE EXECUTION:

Precondition: - mcBSC hardware and software up and running - BSC up and running (Extension configurations) - Other network element's in load test environment (test plan, chapter 6.2) available for integration Procedure: Step Action 1 Create all necessary GSM/EDGE network interface's (PAbis, AoIP, GboIP) that will be used in the 1st test case of Main Load Test's. => Interface's UP and working 2 Create radio network that will be used in 1st test case of the Main Load Test's => Radio network UP and working 3 Run some PS, CS or combined PS/CS call scenario in the radio network. It is preferred to allocate calls to each BTS/TRX in the radio network => PS and CS calls are successfull 4 Run the previous call scenario 1-3 days to verify basic stability for Main Load Test's => mcBSC and all mcBSC unit's are stable Pass/Fail Criteria All expected result's (=>) in the procedure are PASSED No critical class A or B fault's

SIV4_PA_CSPS_001MC mcBSC stability test with mixed (E)GPRS RNW, additional territory downgrades and upgrades,CS and PS calls in the same cell, Packet Abis, Gb over IP and A over IP Test title: mcBSC stability test with mixed (E)GPRS RNW, additional territory downgrades and upgrades, CS and PS calls in the same cell, Packet Abis, Gb over IP and A over IP Test purpose:

This test case is used to verify the territory downgrades and upgrades when circuit switched calls needs resources from packet switched calls. Target is to verify that BCXU/ETME/ETMA/PCUM in mcBSC is stable during long term test. Packet Abis (over Ethernet), Gb over IP and A over IP -interface's are used. Test configuration: Test environment is described in Test Plan: Chapter 6.2 'Test Environment Requirements', Figure 4 Radio network configuration: - 550 TRX per one BCXU - Amount of BCF/BTS optional but based on following requirements: => limitation's of BscPeT tester tool when the HW configuration of BscPeT tester is following: 5x genBCSU's, 5x genPCU's per each genBCSU (total of 25 genPCu's) => half of the BTS's in mcBSC are EGPRS, other half GPRS BTS parameters: GENA=Y for GPRS BTS's GENA=Y and EGENA=Y for EGPRS BTS's CDED=1%, CDEF=1%, CMAX=100% UCSA, DCSA, MCU and MCA: use different values in BTS's, values tbd by test engineer. BSC parameters: CSD=0, CSU=0 Test prerequisite: GboIP feature enabled and interface configured Packet Abis over Ethernet enabled and interface configured A over IP feature enabled and interface configured ETME/ETMA/PCUM(/BCXU) log monitoring enabled, level: mcBSC default Test execution: 1. Upgrade radio network and activate mobile emulators. 2. Start mcBSC log monitoring. 3. Start concurrent uplink and downlink data transfer to each BTS, using large amount of PS (packet switched) mobiles. 4. Start macro for continuous CS (circuit switched) call establishments to each BTS. 5. Wait 2-5 days. 6. Stop the CS call macro. Check the PS data transfer.

7. Stop PS data transfer, detach mobiles. 8. Check that there arent any hanging TBFs (PS calls) from PCUM 9. Check that there arent any hanging CS calls from ETME/ETMA 10. Downgrade radio network (BCF/BTS lock or GENA=N) and check that there arent any hanging (E)GPRS radio channels in PCUM or in DX. 11. Re-execute the steps 1-4 and check that PS and CS calls can be started successfully. Expected results: BCXU/PCUM/ETME/ETMA in mcBSC are stabile. No unit switchovers No abnormal crashes . No abnormal log writings or BSC alarms. No hanging TBFs, CS calls or (E)GPRS radio channels after test. It is possible to start data transfer again after test without problems

LT_mcBSC_Rel1_Int Integration for mcBSC Rel1 Load Testing OBJECTIVE: Target is to verify the functionality and stability of mcBSC Rel1 to be ready for actual Main Load Tests of mcBSC Rel1. This test case will be executed in each load test environment which is planned for mcBSC Rel1 Main Load Tests TEST CONFIGURATION: Test configuration for each load test environment is described in the test plan, chapter 6.2 'Test Environment Requirements' TEST CASE EXECUTION: Precondition: - mcBSC hardware and software up and running - BSC up and running (Extension configurations) - Other network element's in load test environment (test plan, chapter 6.2) available for integration

Procedure: Step Action 1 Create all necessary GSM/EDGE network interface's (PAbis, AoIP, GboIP) that will be used in the 1st test case of Main Load Test's. => Interface's UP and working 2 Create radio network that will be used in 1st test case of the Main Load Test's => Radio network UP and working 3 Run some PS, CS or combined PS/CS call scenario in the radio network. It is preferred to allocate calls to each BTS/TRX in the radio network => PS and CS calls are successfull 4 Run the previous call scenario 1-3 days to verify basic stability for Main Load Test's => mcBSC and all mcBSC unit's are stable Pass/Fail Criteria All expected result's (=>) in the procedure are PASSED No critical class A or B fault's

SIV4_PA_MGB_EDA_HMC_001MC (MGb & EDA-HMC) Mixed MS types in same territory with short data transfers (5-45 min). Mixed network with dynamic territories. 1.1 OBJECTIVE Traffic mix and stability test. 1.2 TEST CONFIGURATION GPRS3GEMULATOR environment with packet abis support. 18 BTS emulators needed. Standalone mcBSC with mcBSC Rel1 SW and Packet Abis capability. 1.3 TEST CASE EXECUTION

1.3.1 Precondition Error modeling is activated in emulators, so that RLC data blocks are randomly corrupted during data transfer.

1.3.1.1 BSC - EGPRS activated in part of the BTSes. - EDA & HMC activated - BFG = 2 - GPRS measurements are active - Radio network must be as large as possible to ensure that channel capacity of PCUM card is in use as widely as possible. 1.3.1.2 BTS - EGPRS activated - Error modelling in use 1.3.1.3 MS Mobiles on each territory / BTS - MCS-5 MSC-32 : 1 - CS-2 MSC-32 : 1 - MCS-5 MSC-5 : 2 - CS-2 MSC-5 : 2 1.3.2 Procedure 1. Start measurements. The the processor load and throughput can be measured 2. Activate data transfer in MS emulators. Let it continue 48 hours. Generate continuous TBF/PFC establishments and releases for each mobile, interval 5-45min per mobile. 3. After 48 hours check processor load, log writings and BCSU alarms. 4. Stop calls. Calls stopped normally. No hanging TBFs 5. A short basic type data transfer is made after case to ensure PCU is functional.

1.3.3 Postcondition All channels are in sync. No unexpected alarms.

No unexpected log records. PCU is up and functional. No overload actions. 1.3.4 Pass/Fail criteria Post condition criteria is met.

SIV4_PA_MGB_EDA_HMC_002MC (MGb & EDA-HMC) Mixed MS types in same territory. Continuous 48h data transfer with error modelling. Mixed network with dynamic territories. 1.1 OBJECTIVE Traffic mix and stability test. 1.2 TEST CONFIGURATION GPRS3GEMULATOR environment with packet abis support. 18 BTS emulators needed. Standalone mcBSC with mcBSC Rel1 SW and Packet Abis capability. 1.3 TEST CASE EXECUTION

1.3.1 Precondition Error modeling is activated in emulators, so that RLC data blocks are randomly corrupted during data transfer. 1.3.1.1 BSC - EGPRS activated in part of the BTSes. - EDA & HMC activated - BFG = 2 - GPRS measurements are active - Radio network must be as large as possible to ensure that channel capacity of PCUM card is in use as widely as possible. 1.3.1.2 BTS - EGPRS activated - Error modelling in use

1.3.1.3 MS Mobiles on each territory / BTS - MCS-5 MSC-32 : 1 - CS-2 MSC-32 : 1 - MCS-5 MSC-5 : 2 - CS-2 MSC-5 : 2 1.3.2 Procedure 1. Start measurements. The the processor load and throughput can be measured 2. Activate data transfer in MS emulators. Let it continue 48 hours. 3. After 48 hours check processor load, log writings and BCSU alarms. 4. Stop calls. Calls stopped normally. No hanging TBFs 5. A short basic type data transfer is made after case to ensure PCU is functional.

1.3.3 Postcondition All channels are in sync. No unexpected alarms. No unexpected log records. PCU is up and functional. No overload actions. 1.3.4 Pass/Fail criteria Post condition criteria is met. LT_mcBSC_Rel1_Int Integration for mcBSC Rel1 Load Testing OBJECTIVE:

Target is to verify the functionality and stability of mcBSC Rel1 to be ready for actual Main Load Tests of mcBSC Rel1. This test case will be executed in each load test environment which is planned for mcBSC Rel1 Main Load Tests TEST CONFIGURATION: Test configuration for each load test environment is described in the test plan, chapter 6.2 'Test Environment Requirements' TEST CASE EXECUTION: Precondition: - mcBSC hardware and software up and running - BSC up and running (Extension configurations) - Other network element's in load test environment (test plan, chapter 6.2) available for integration Procedure: Step Action 1 Create all necessary GSM/EDGE network interface's (PAbis, AoIP, GboIP) that will be used in the 1st test case of Main Load Test's. => Interface's UP and working 2 Create radio network that will be used in 1st test case of the Main Load Test's => Radio network UP and working 3 Run some PS, CS or combined PS/CS call scenario in the radio network. It is preferred to allocate calls to each BTS/TRX in the radio network => PS and CS calls are successfull 4 Run the previous call scenario 1-3 days to verify basic stability for Main Load Test's => mcBSC and all mcBSC unit's are stable Pass/Fail Criteria All expected result's (=>) in the procedure are PASSED No critical class A or B fault's

SIV4_ETPE_PCUE_STAB_003

Full ETPE connectivity with 8 PCU2-Es, large number of PS calls, CLASS 1 MSs, CS-1, concurrent ULDL, long term data transfer SIV4_ETPE_PCUE_STAB_003 Full ETPE connectivity with 8 PCU2-Es, large number of PS calls, CLASS 1 MSs, CS-1, concurrent UL/DL, long term data transfer OBJECTIVE To verify ETP-E functionality and stability with full PCU2-E connectivity and large number of active long term PS calls. Large means as much as poss. and the more the better, and if feasible then max amount. Target is maximum number of PS calls for one ETP. TEST CONFIGURATION Necessary amount of PCs with PAoE GEMU MS/BTS and SGSN SW RNW with large number of BTSs and TRXs so that full ETP-E connectivity is reached 8 PCU2-Es connected to ETP-E TEST CASE EXECUTION Precondition (M)CS-1 is in use and LA is disabled in all BTSs Large number of class 1 MSs configured to each MS/BTS emulator BSC is up and running Procedure Make long term (min 48 h) data transfer with large number of MSs Max duration should be level on six nines availability per year which means 30 sec down time. The term 'high availability' is used when referring to a system that is capable of providing service most of the time. A widely adopted standard for telephone networks has been five nines, service availability 99.999% of the time. It means that the annual downtime is less than about five minutes. Nowadays target availability for critical applications is six nines, equivalent of 30 seconds or less of downtime annually. The prerequisite for the availability of BSC network element is simplicity and speed of the servicing procedures, such as fault repair time. There is the general requirement for built-in redundancy functionalities and efficient supervision functions to minimise the time spent in maintenance. In addition, reliable network elements and automatic fault detection and recovery procedures are needed to reduce required site visits. As a result, the network maintenance can be implemented more economical. Postcondition No unexpected alarms No unexpected log writings ETP-E is up and running

PCU2-Es are up and running Pass/fail criteria Test can be executed without any BSC, BSCU, ETP-E or PCU problems SIV4_ETPE_PCUE_STAB_004 Full ETPE connectivity with 8 PCU2-Es, large number of PS calls, different data profiles in use, long term data transfer SIV4_ETPE_PCUE_STAB_004 Full ETPE connectivity with 8 PCU2-Es, large number of PS calls, different data profiles in use, long term data transfer OBJECTIVE To verify ETP-E functionality and stability with full PCU2-E connectivity and large number of active long term PS calls. Large means as much as poss. and the more the better, and if feasible then max amount. TEST CONFIGURATION Necessary amount of PCs with PAoE GEMU MS/BTS and SGSN SW RNW with large number of BTSs and TRXs so that full ETP-E connectivity is reached 8 PCU2-Es connected to ETP-E TEST CASE EXECUTION Precondition Different MSCs and data profiles in use and LA is disabled in all BTSs Large number of different MS class configured to each MS/BTS emulator BSC is up and running Procedure Make long term (min 48 h) data transfer with large number of MSs Max duration should be level on six nines availability per year which means 30 sec down time. The term 'high availability' is used when referring to a system that is capable of providing service most of the time. A widely adopted standard for telephone networks has been five nines, service availability 99.999% of the time. It means that the annual downtime is less than about five minutes. Nowadays target availability for critical applications is six nines, equivalent of 30 seconds or less of downtime annually. The prerequisite for the availability of BSC network element is simplicity and speed of the servicing procedures, such as fault repair time. There is the general requirement for built-in redundancy functionalities and efficient supervision functions to minimise the

time spent in maintenance. In addition, reliable network elements and automatic fault detection and recovery procedures are needed to reduce required site visits. As a result, the network maintenance can be implemented more economical. Postcondition No unexpected alarms No unexpected log writings ETP-E is up and running PCU2-Es are up and running Pass/fail criteria Test can be executed without any BSC, BSCU, ETP-E or PCU problems

SIV4_ETPE_ETPA_STAB_007 High ETPE connectivity with ETPA, large number of concurrent CS calls, continuous busy hour type situation SIV4_ETPE_ETPA_STAB_007 High ETPE connectivity with ETPA, large number of concurrent CS calls, continuous busy hour type situation. OBJECTIVE To verify ETP-E functionality and stability with full ETPA connectivity and large number of concurrent active long term CS calls. High and large means as much as poss. and the more the better, if feasible then max amount. English: busy hour ; BH busy telephone traffic hour Definition: continuous 60-minute period during which traffic load is greatest TEST CONFIGURATION Necessary amount of PCs with PAoE GEMU MS/BTS, SGSN, MGW and MSC SW RNW with large number of BTSs and TRXs so that full ETP-E connectivity is reached ETPA has equipped. TEST CASE EXECUTION Precondition Channels/Type Subchannel# 0 per RTSL 1xPS PS 1xFR FR 2xHR 1st HR 2xFR OSC (DFR) FR OSC-0

Subchannel# 1 2nd HR -

Subchannel# 2 FR OSC-1

Subchannel# 3 -

4xHR OSC (DHR) OSC-1

1st HR OSC-0

2nd HR OSC-0

1st HR OSC-1

2nd HR

Different CS codecs in use Large number of class 1 MSs configured to each MS/BTS emulator BSC is up and running Procedure Make long term (min 48 h) CS traffic with large number of MSs Max duration should be level on six nines availability per year which means 30 sec down time. The term 'high availability' is used when referring to a system that is capable of providing service most of the time. A widely adopted standard for telephone networks has been five nines, service availability 99.999% of the time. It means that the annual downtime is less than about five minutes. Nowadays target availability for critical applications is six nines, equivalent of 30 seconds or less of downtime annually. The prerequisite for the availability of BSC network element is simplicity and speed of the servicing procedures, such as fault repair time. There is the general requirement for built-in redundancy functionalities and efficient supervision functions to minimise the time spent in maintenance. In addition, reliable network elements and automatic fault detection and recovery procedures are needed to reduce required site visits. As a result, the network maintenance can be implemented more economical. Postcondition No unexpected alarms No unexpected log writings ETP-E and ETP-A is up and running PCU2-Ds are up and running Pass/fail criteria Test can be executed without any BSC, BSCU, ETP or PCU problems SIV4_ETPE_CSPS_STAB_009 High ETPE connectivity with ETPA and 8 PCU2-Es, large number CS and PS calls, different profiles on CS and PS calls, ongoing busy hour situation SIV4_ETPE_CSPS_STAB_009 High ETPE connectivity with ETPA and 8 PCU2-Es, large number CS and PS calls, different profiles on CS and PS calls, ongoing busy hour situation OBJECTIVE

To verify ETP-E functionality and stability with full ETP-A and PCU2-E connectivity and large number of active long term CS and PS calls. High and large means as much as poss. and the more the better, if feasible then max amount. TEST CONFIGURATION Necessary amount of PCs with PAoE GEMU MS/BTS, SGSN, MGW and MSC SW RNW with large number of BTSs and TRXs so that full ETP-E connectivity is reached 8 PCU2-Es connected to ETP-E ETPA has equipped. TEST CASE EXECUTION Precondition Channels/Type Subchannel# 0 Subchannel# 1 Subchannel# 2 Subchannel# 3 per RTSL 1xPS PS 1xFR FR 2xHR 1st HR 2nd HR 2xFR OSC (DFR) FR OSC-0 FR OSC-1 4xHR OSC (DHR) 1st HR OSC-0 2nd HR OSC-0 1st HR OSC-1 2nd HR OSC-1 Different CS codecs, (M)CSs and data profiles in use and LA is disabled in all BTSs Large number of different MS class configured to each MS/BTS emulator BSC is up and running Procedure Make long term (min 48 h) data transfer with large number of MSs Max duration should be level on six nines availability per year which means 30 sec down time. The term 'high availability' is used when referring to a system that is capable of providing service most of the time. A widely adopted standard for telephone networks has been five nines, service availability 99.999% of the time. It means that the annual downtime is less than about five minutes. Nowadays target availability for critical applications is six nines, equivalent of 30 seconds or less of downtime annually. The prerequisite for the availability of BSC network element is simplicity and speed of the servicing procedures, such as fault repair time. There is the general requirement for built-in redundancy functionalities and efficient supervision functions to minimise the time spent in maintenance. In addition, reliable network elements and automatic fault detection and recovery procedures are needed to reduce required site visits. As a result, the network maintenance can be implemented more economical. Postcondition No unexpected alarms No unexpected log writings

ETP-A/E is up and running PCU2-Es are up and running Pass/fail criteria Test can be executed without any BSC, BSCU, ETP or PCU problems

SIV4_ETPE_CSPS_FUNC_001 Controlled ETPE switchover with heavy CSPS load SIV4_ETPE_CSPS_FUNC_001 Controlled ETPE switchover with heavy CS/PS load OBJECTIVE To verify ETP-E controlled switchover functionality with heavy CS and PS traffic. TEST CONFIGURATION Necessary amount of PCs with PAoE GEMU MS/BTS, SGSN MGW and MSC SW RNW with large number of BTSs and TRXs so that full ETP-E connectivity is reached PCU2s connected to ETP-E ETPA/C has equipped. TEST CASE EXECUTION Precondition Channels/Type Subchannel# 0 Subchannel# 1 Subchannel# 2 Subchannel# 3 per RTSL 1xPS PS 1xFR FR 2xHR 1st HR 2nd HR 2xFR OSC (DFR) FR OSC-0 FR OSC-1 4xHR OSC (DHR) 1st HR OSC-0 2nd HR OSC-0 1st HR OSC-1 2nd HR OSC-1 Different CS codecs, (M)CSs and data profiles in use and LA is disabled in all BTSs Large number of different MS class configured to each MS/BTS emulator BSC is up and running Procedure Make controlled ETP-E switchover when heavy load situation Postcondition No unexpected alarms

No unexpected log writings ETP is up and running PCU2s are up and running Pass/fail criteria Test can be executed without any unexpected BSC, BSCU, ETP or PCU problems and traffic continues after controlled switchover. SIV4_ETPE_CSPS_FUNC_002 ETPE DSP recoverys functionality during high CSPS traffic. SIV4_ETPE_CSPS_FUNC_002 ETPE DSP recovery's functionality during high CS/PS traffic. OBJECTIVE To verify ETP-E DSP recovery functionality with CS and PS traffic during different traffic models. After DSP restart HDLC links are created according to the requirements and traffic will be reconstituted without problems. TEST CONFIGURATION Necessary amount of PCs with PAoE GEMU MS/BTS, SGSN MGW and MSC SW RNW with large number of BTSs and TRXs so that full ETP-E connectivity is reached PCU2-Ds connected to ETP-E ETPA/C has equipped. TEST CASE EXECUTION Precondition Channels/Type Subchannel# 0 Subchannel# 1 Subchannel# 2 Subchannel# 3 per RTSL 1xPS PS 1xFR FR 2xHR 1st HR 2nd HR 2xFR OSC (DFR) FR OSC-0 FR OSC-1 4xHR OSC (DHR) 1st HR OSC-0 2nd HR OSC-0 1st HR OSC-1 2nd HR OSC-1 Different CS codecs, (M)CSs and data profiles in use and LA is disabled in all BTSs Large number of different MS class configured to each MS/BTS emulator BSC is up and running Procedure Make ETP-E DSP reset during high load.

Postcondition DSP and Link Failure alarms are canceled No unexpected alarms No unexpected log writings ETP is up and running PCU2-Ds are up and running Pass/fail criteria Test can be executed without any unexpected BSC, BSCU, ETP or PCU problems and after DSP reset traffic is started again without any problems. All expected alarms are canceled.

SIV4_ETPE_CSPS_FUNC_003 Controlled BCSU switchover with heavy CSPS traffic on ETPE SIV4_ETPE_CSPS_FUNC_003 Controlled BCSU switchover with heavy CS/PS traffic on ETPE OBJECTIVE ETP-E stability and functionality verification during controlled BCSU switchover/restart with heavy CS and PS traffic. After BCSU switchover PEP HDLC and Ethernet links are created according to the requirements and traffic continues without any problems. TEST CONFIGURATION Necessary amount of PCs with PAoE GEMU MS/BTS, SGSN MGW and MSC SW RNW with large number of BTSs and TRXs so that full ETP-E connectivity is reached PCU2D/E-s connected to ETP-E ETPA/C has equipped. TEST CASE EXECUTION Precondition Channels/Type Subchannel# 0 Subchannel# 1 Subchannel# 2 Subchannel# 3 per RTSL 1xPS PS 1xFR FR 2xHR 1st HR 2nd HR 2xFR OSC (DFR) FR OSC-0 FR OSC-1 4xHR OSC (DHR) 1st HR OSC-0 2nd HR OSC-0 1st HR OSC-1 2nd HR OSC-1 Different CS codecs, (M)CSs and data profiles in use and LA is disabled in all BTSs Large number of different MS class configured to each MS/BTS emulator

BSC is up and running Procedure Make controlled BCSU switchover during high load. Postcondition No unexpected alarms No unexpected log writings ETPs are up and running PCU2D/Es are up and running Pass/fail criteria Test can be executed without any unexpected BSC, BSCU, ETP or PCU problems and traffic is started again after controlled BCSU switchover/reset.

TRX EXTENSION TEST CASES

SIV2_015_PABIS_454_517 517_Temporary ethernet link failure between ETP and PCU2E 1.1 Temporary Ethernet link failure between ETP and PCU2-E

Description of test case: Purpose of the test case is to check that detection and recovery of short Ethernet link failure between ETP and PCU2-E works correctly. Requirements: BSS21440-341 Ethernet data link monitor Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - IP addresses in PCU2E and ETP are successfully configured - VLAN is successfully configured in PCU2 - PCU2 is connected to ETP - No redundant Ethernet interface configured for PCU2 Execution: Disconnect for the short period of time (under 30s) Ethernet cable between PCU2-E and ETP. Monitor Ethernet link state using ST command "dals". Check that alarm is not raised using MML-command ZAHO. Connect Ethernet cable between PCU2-E and ETP. Monitor Ethernet link state using ST command "dals". Expected Results:

When the cable is disconnected Ethernet link stays up and PCU2-E sends ping messages to ETP after every 3 second but does not receive response from ETP. PCU2-E does not raise PEP_DATA_LINK_FAILURE alarm. When the cable is reconnected PCU2-E starts receiving responses for ping messages from ETP. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_518 518_Permanent ethernet link failure between ETP and PCU2E 1.1 Permanent Ethernet link failure between ETP and PCU2-E

Description of test case: Purpose of the test case is to check that detection and recovery of permanent Ethernet link failure between ETP and PCU2-E works correctly. Requirements: BSS21440-341 Ethernet data link monitor Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - IP addresses in PCU2E and ETP are successfully configured - VLAN is successfully configured in PCU2 - PCU2 is connected to ETP - No redundant Ethernet interface configured for PCU2 Execution:

Disconnect Ethernet cable between PCU2-E and ETP for a period of over 30 seconds. Monitor Ethernet link state using ST command "dals". Check that alarm is raised using MML-command ZAHO. Connect Ethernet cable between PCU2-E and ETP. Monitor Ethernet link state using ST command "dals". Check that alarm is cancelled using MML-command ZAHO. Expected Results: When the cable is disconnected the Ethernet link stays up and PCU2-E sends ping messages to ETP after every 3 second and at least 10 times but does not receive response from ETP. After 30 seconds PCU2-E raises PEP_DATA_LINK_FAILURE alarm and Ethernet link goes down. When the cable is reconnected PCU2-E receives responses for ping messages from ETP and the ETP-PCU2 link goes up. After that PEP_DATA_LINK_FAILURE alarm is cancelled by PCU2-E. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_523 523_Recovery of packet abis after PCU2E restart 1.1 Recovery of Packet Abis after PCU2-E restart Description of test case: Purpose of the test case is to check that Ethernet link between ETP and PCU2-E is reestablished successfully and DSP allocations and territory procedures work correctly after PCU2-E restart. Requirements: BSS21440-223 Ethernet data link establishment for PCU2-E Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements

- Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - IP addresses in PCU2E and ETP are successfully configured - VLAN is successfully configured in PCU2 - PCU2 is connected to ETP - (E)GPRS enabled BTS with one TRX created Execution: Make BCSU restart/PCU2-E hot restart/PCU2-E cold restart using MML command. Start data transfer with 1 MS. Expected Results: When PCU2 is restarted Ethernet link between PCU2 and ETP is disconnected. PCU2 restart is successful. After PCU2 comes up DX sends the Packet Abis IP Address and VLAN information to PCU2 in tcpip_mgmt_rpc_s message. PCU2 responds with tcpip_mgmt_rpc_rsp_s. PCU2 receives conn_eth_datalink_to_etp_s message from DX and responds with conn_eth_datalink_to_etp_ack_s. PCU2 initiates PCU2-ETP Ethernet link monitoring and resolves the ETP MAC Address DX sends segment table information in message pcu_segment_capability_s. PCU2 responds with pcu_segment_capability_ack_s message and makes DSP allocation for the segment. After that (E)GPRS territory is upgraded successfully and data transfer works correctly. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_525 525_Recovery of packet abis in PCU2E after ETP restart 1.1 Recovery of Packet Abis in PCU2-E after ETP restart Description of test case:

Purpose of the test case is to check that Ethernet link between ETP and PCU2-E is reestablished successfully and DSP allocations and territory procedures work correctly after ETP restart. Requirements: BSS21440-223 Ethernet data link establishment for PCU2-E Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - IP addresses in PCU2E and ETP are successfully configured - VLAN is successfully configured in PCU2 - PCU2 is connected to ETP - (E)GPRS enabled BTS with one TRX created Execution: Make ETP restart using MML command. Start data transfer with 1 MS. Expected Results: When ETP is restarted Ethernet link between PCU2 and ETP is disconnected. ETP restart is successful. After ETP comes up PCU2 receives conn_eth_datalink_to_etp_s message from DX and responds with conn_eth_datalink_to_etp_ack_s. PCU2 initiates PCU2-ETP Ethernet link monitoring and resolves the ETP MAC Address. After that (E)GPRS territory is upgraded successfully and data transfer works correctly. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_532 532_SMCH selection for new PSTP 1.1 SMCH selection for new PSTP

Description of test case: Purpose of the test case is to check that SMCH selection works correctly when a new PSTP is created. Requirements: BSS21440-321 PSTP for BTS Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E or PCU2-D card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - PCU2 is connected to ETP - BTS with 2 TRXs created - BTS and TRXs are unlocked - There are both DEDICATED TSLs and DEFAULT TSLs in (E)GPRS territory - (E)GPRS is disabled Execution: Make territory upgrade for all channels of both TRXs by changing GENA=Y using MML command ZEQV. Expected Results: New PSTN is created to PCU2 and new SMCH is selected according to following procedure:

Step 1: If the TRX has DEDICATED TSLs, then the highest numbered DEDICATED TSL is designated as the SMCH for the PSTP. If there is no DEDICATED TSL on the TRX, then SMCH is selected using Step 2 below. Step 2: If the TRX has DEFAULT TSLs, then the highest numbered DEFAULT TSL is designated as the SMCH for the PSTP. If there is no DEFAULT TSL on the TRX, then SMCH is selected using Step 3 below. Step 3: The highest numbered TSL is designated as the SMCH for the PSTP. Use ST command "ddspinfo" to verify that correct TSL has been selected as SMCH. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_533 533_SMCH reselection for PSTP 1.1 SMCH reselection for PSTP

Description of test case: Purpose of the test case is to check that selection of a new SMCH works correctly when the old SMCH is downgraded. Requirements: BSS21440-321 PSTP for BTS Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E or PCU2-D card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - PCU2 is connected to ETP - BTS with 2 TRXs created - BTS and TRXs are unlocked

- There are both DEDICATED TSLs and DEFAULT TSLs in (E)GPRS territory - (E)GPRS is enabled Execution: Lock TSLs one by one using MML command ZERS so that every time the locked TSL is the current SMCH TSL of PSTP. Continue until all TSLs are locked. Expected Results: Every time when the old SMCH is locked a new SMCH is selected according to following procedure: Step 1: PFD scans the candidate TSLs (in order 7 to 0) of all the TRXs of PSTP starting from the TRX farthest from CS-PS territory border to find a DEDICATED TSL. If a DEDICATED TSL is found, it is designated as new SMCH of the PSTP. Otherwise, the new SMCH is selected using Step 2. Step 2: PFD scans the candidate TSLs (in order 7 to 0) of all the TRXs of PSTP starting from the TRX farthest from CS-PS territory border to find a DEFAULT TSL. If a DEFAULT TSL is found, it is designated as new SMCH of the PSTP. Otherwise, the new SMCH is selected using Step 3. Step 3: The first candidate TSL (in order 7 to 0) among all the TRXs of PSTP starting from the TRX farthest from CS-PS territory border is designated as new SMCH of the PSTP. Use ST command "ddspinfo" to verify that new SMCH TSL has been reselected correctly each time when old SMCH TSL is locked. No test case related errors in MCMU, BCSU or PCU2 logs.

Create_PCP_by_adding_new_PCU_unde_ PSE_w Create PCP by adding new PCU under PSE with multipoint Gb and cells (S13) 2.0.0

Description:

The operator creates a new Packet Control Pool into BSC by adding second PCU under the same PSE. PCU to be added is new one without Gb interface or cells. PSE includes two NSEs, DAPs and cells already. Multipoint Gb is in use. PSE and PCU objects are created into the database. PCP is taken into use in BSC and PCUs are taken to PCP usage. Because reallocation is enabled and load in the existing PCU and segment is over change limit, (E)GPRS load is shared between PSE&apos;s both PCUs. DAPs and segments are allocated also to new PCU. New PCU is ready to transmit (E)GPRS traffic. Preconditions: - PCP and Multipoint Gb licences are activated in the BSC. - Local IP address is configured into the new PCU. - PSE has one PCU with DAPs and cells already. - There are two NSEs in the PSE (multipoint Gb is in use) - There are not any DAPs or cells in the new PCU which will be added to the PSE. - Gb interface is not created in the new PCU. - Cell reallocation is allowed. - (E)GPRS load is high enough in order to generate DAP and cell reallocation to the new PCU. Load is over change limit in the PCU and at least in one of the cells. - Cell to be reallocated is using different DAP than cells which stay in the original PCU. a) - Static IP configuration is used b) - Dynamic IP configuration is used Test scenario: a) and b) 1. The operator modifies PSE configuration by adding a new (second) PCU into the PSE. Parameters are: PSEI, BCSU index and PCU index. 2. BSC checks that: - PCP licence is activated, - type of PCU PIU has to be same in every BCSU in same track, - local IP address is configured to new PCU, - PSEI exist in database, - BCSU index and PCU index must exist, - new PCU is not in PSE usage, - maximum number of PCUs in PSE not exceeded. 3. BSC creates a new PCU object under PSE object into the database.

4. PCP is taken into use in the PSE. BSC indicates to first PCU to act as PCP&apos;s PCU. 5. BSC indicates to new PCU to act as PCP&apos;s PCU. 6. BSC creates NSE configuration (all NS-VLs of NSE) to new PCU. If Multipoint Gb is activated, BSC creates PSE&apos;s all NSEs and their configuration to new PCU. 7. In case of dynamic IP configuration, new PCU starts the Add procedure to configure additional IP endpoint for NSE [48.016]. In case of static IP configuration new PCU starts the Test procedure. 8. When NS layer is configured successfully, new PCU responds to BSC. 9. BSC informs to other PCUs in PSE about new PCU. 10.1. If the operator has allowed the cell reallocation, BSC shares (E)GPRS load within the PCP by the PCU selection algorithm. Algorithm selects DAPs and cells to new PCU from PSE&apos;s other PCUs where (E)GPRS load has been very high. BSC moves DAPs to new PCU one by one. BSC downgrades (E)GPRS traffic from all cells attached in DAP and deletes needed BVCs from PCU. BSC indicates PCU to delete EDAP from PCU. 10.2. PCU releases (E)GPRS channels from DSPs and deletes EDAP&apos;s from PCU. 10.3. BSC releases EDAP from PCUPCM. BSC changes Abis PCM connection to new PCU&apos;s PCUPCM and sends EDAP info to new PCU. 10.4. New PCU uses a reversed PCUPCM hunting to allocating continuous block for EDAP. 10.5. BSC connects EDAP to PCUPCM and responds to new PCU. 10.6. New PCU connects (E)GPRS channels to DSPs. 10.7. BSC updates Segment&apos;s PCU connection into the database and creates BVCs to new PCU. BSC upgrades (E)GPRS traffic in all moved cells and sends SIs to BTS. 10.8. BSC updates PSE&apos;s cell configuration to all PCUs in PSE. 11. If operation was started locally, BSC sends response to the MMI and an event to the NetAct RAC about PCU creation. If operation was started from NetAct RAC, BSC sends response to the NetAct. Possible exceptions: 1. PCP licence not activated, PSEI does not exist, and new PCU already belong to some other PSE, local IP address not configured to new PCU: BSC interrupts the PCU addition into the PSE and informs to the operator with error message

Creation_of_second_dynamic_NSE_under_PSE Creation of second dynamic NSE under PSE when PCP is in use 2.0.0

Creation of second dynamic NSE under PSE when PCP is in use Description of test case Purpose of the test case is to check that adding of new dynamic NSE under PSE is successful when two PCUs are connected to PSE. Required test environment - Kantokoski + emulated MS, BTS, SGSN and GGSN. - GPRS emulator version 3.3-0 or later. - Red Hat Linux 7.3 or later. - Application version (Kk): S13 XXX. Required environment settings - PCU2 and Gb over IP licences are enabled - Multipoint Gb licence is enabled - IP address and static default route are created for PCUs - PCU2 Pooling licence is enabled - PSE is created - Dynamic NSE1 is created under PSE - PCU1 and PCU2 are connected to PSE - BTS1 is attached to PSE (PCU1 selected by PCU selection algorithm) - BTS2 is attached to PSE (PCU2 selected by PCU selection algorithm) Related documents: PCU2 Pooling, Implementation Specification, Version 2.4-0, Chapter 5.4.3.1 Execution Expected Results 1. Create new dynamic NS-VL under NSE2 using MML command ZFXK. 1. Creation of dynamic NS-VL is successful. New NS-VL and NSE2 are created to both PCUs. Signaling BCV for NSE2 is created to both PCUs. For BTS1 new point-to-point BVC to NSE2 is created to PCU1. For BTS2 new point-to-point BVC to NSE2 is created to PCU2. 2. Make several (E)GPRS calls from MS attached to BTS1. 2. (E)GPRS calls are successful. (E)GPRS calls are connected via PCU1 and shared evenly between NSE1 and NSE2. 3. Make several (E)GPRS calls from MS attached to BTS2. 3. (E)GPRS calls are successful. (E)GPRS calls are connected via PCU2 and shared evenly between NSE1 and NSE2. 4. Collect following information during test case execution:

- GBADMI (42D) - PCU2 logs (MPGB, PDM, PFM, BSSGP, RELAY and NS) - PCU service terminal information - SGSN emulator log 4. Check that no PCU2 error logs has been appeared during test case execution.

SIV2_015_PABIS_454_506 506_Creating Ethernet connection between ETP and PCU2E 1.1 Creating Ethernet connection between ETP and PCU2-E

Description of test case: Purpose of the test case is to check that creation of Ethernet connection between ETP and PCU2-E is successful and ETP related parameters are delivered correctly to PCU. Requirements: BSS21440-223 Ethernet data link establishment for PCU2-E Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - IP addresses in PCU2E and ETP are successfully configured - VLAN is successfully configured in PCU2 Execution: Create connection between ETP and PCU2-E using MML-command ZESK. For example ZESK:ETPGID=1,ETPT=ETP-E,BCSU=0,PCU=4; Verify that connection has been created using MML command ZESL.

Expected Results: Execution of MML command ZESK is successful. DX sends the IP address of the ETP in the conn_eth_datalink_to_etp_s message to PCU2, which responds with conn_eth_datalink_to_etp_ack_s message to DX. Then PCU2 starts sending ping messages to ETP for Abis Link Monitoring. For the ping request messages sent to ETP, the IP stack sends the VLAN tagged ARP request to ETP to resolve the MAC address of ETP. ETP sends the VLAN tagged ARP reply containing the ETP MAC address to PCU2.The IP stack on receiving the ARP reply sends the VLAN tagged ping request to ETP. The IP stack then sends the message 'ETP_MAC_s' to PCU-AGNT in PCU2. PCUAGNT creates a static ARP entry for the ETP IP address on stack, saves the ETP MAC address and marks the Abis Ethernet Interface state as WORKING. ETP sends reply to ping messages. This link monitoring process then continues between PCU2 and ETP. MML command ZESL shows correctly information of created connection. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_507 507_Creating Ethernet connection between ETP and PCU2E, no IP address configured for PCU2 1.1 Creating Ethernet connection between ETP and PCU2-E, no IP address configured for PCU2 Description of test case: Purpose of the test case is to check that creation of Ethernet connection between ETP and PCU2-E fails when PCU2-E has no IP addresses configured. Requirements: BSS21440-223 Ethernet data link establishment for PCU2-E Required test environment:

- Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - PCU2-E has no IP addresses configured - VLAN is successfully configured in PCU2 Execution: Try to create Ethernet connection between ETP and PCU2-E using MML-command ZESK. Verify that connection has not been created using MML command ZESL. Expected Results: DX sends conn_eth_datalink_to_etp_s message to PCU2. PCU2 finds out that there is no IP address configured. Connection creation fails and conn_eth_datalink_to_etp_ack_s is sent to DX with correct error code. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_508 508_Creating Ethernet connection between ETP and PCU2E, IP addresses not in same subnet 1.1 Creating Ethernet connection between ETP and PCU2-E, IP addresses not in same subnet Description of test case: Purpose of the test case is to check that creation of Ethernet connection between ETP and PCU2-E fails when IP addresses of PCU2-E and ETP do not belong to same subnet. Requirements:

BSS21440-260 PCU2-E BSC internal LAN detection Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - PCU2-E has IP address configured for Packet Abis - ETP has IP address configured for PEP interface - VLAN is successfully configured in PCU2 - IP addresses do not belong to same subnet Execution: Try to create Ethernet connection between ETP and PCU2-E using MML-command ZESK. Verify that connection has been created using MML command ZESL. Expected Results: DX sends conn_eth_datalink_to_etp_s message to PCU2. IP addresses defined for PCU2 are compared to received ETP IP address. PCU2 finds out that addresses do not belong to same subnet and sends conn_eth_datalink_to_etp_ack_s is sent to DX with correct error code. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_510 510_Disconnecting of Ethernet connection between ETP and PCU2E 1.1 Disconnecting of Ethernet connection between ETP and PCU2-E

Description of test case: Purpose of the test case is to check that disconnecting of Ethernet connection between ETP and PCU2-E works correctly. Requirements: BSS21440-225 Ethernet data link release for PCU2-E Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - IP addresses in PCU2E and ETP are successfully configured - VLAN is successfully configured in PCU2 - PCU2 is connected to ETP Execution: Release the connection between ETP and PCU2-E using MML-command ZESH. For example ZESH:ETPGID=1,ETPT=ETP-E,BCSU=0,PCU=4; Verify that connection has been removed using MML command ZESL. Expected Results: Execution of MML command ZESH is successful. DX sends the message release_eth_datalink_to_etp_s to PCU2.

PCU2 stops Abis Link Monitoring and stops sending any packets to ETP and marks the Abis Ethernet interface state as FAILED and sends release_eth_datalink_to_etp_ack_s to DX. MML command ZESL shows that connection has been removed. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_528 528_DSP allocation for GPRS segments 1.1 DSP allocation for GPRS segments

Description of test case: Purpose of the test case is to check that DSP allocation algorithm works correctly in case of several GPRS BTSs. Requirements: BSS21440-131 PCU2-D DSP allocation BSS21440-132 PCU2-E DSP allocation Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E or PCU2-D card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - PCU2 is connected to ETP - Several GPRS enabled BTSs with TRXs are created - All TRXs are locked - Segments have different 'GPRS capacity throughput factor' parameter values Execution: PCU update procedure is started using MML command ZFXU.

Unlock TRXs using MML command ZERS. Start data transfer with 1 MS. Expected Results: PCU2 receives pcu_segment_capability_s message from DX with correct GPRS segment information. PCU2 makes DSP allocation for GPRS segments according to specifications and acknowledges the message by sending pcu_segment_capability_ack_s to DX. When TRX is unlocked DX sends psw_territory_upgrade_s messages for upgraded channels to PCU2 which acknowledges messages with psw_territory_upgrade_ack_s. Use ST command "dsegrnw" to verify DSP allocations after territory upgrades. Data transfer is successful. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_529 529_DSP allocation for EGPRS segments 1.1 DSP allocation for EGPRS segments

Description of test case: Purpose of the test case is to check that DSP allocation algorithm works correctly in case of several EGPRS BTSs. Requirements: BSS21440-131 PCU2-D DSP allocation BSS21440-132 PCU2-E DSP allocation Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E or PCU2-D card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements

- Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - PCU2 is connected to ETP - Several EGPRS enabled BTSs with TRXs are created - All TRXs are locked - Segments have different 'GPRS capacity throughput factor' parameter values Execution: PCU update procedure is started using MML command ZFXU. Unlock TRXs using MML command ZERS. Start data transfer with 1 MS. Expected Results: PCU2 receives pcu_segment_capability_s message from DX with correct EGPRS segment information. PCU2 makes DSP allocation for EGPRS segments according to specifications and acknowledges the message by sending pcu_segment_capability_ack_s to DX. When TRX is unlocked DX sends psw_territory_upgrade_s messages for upgraded channels to PCU2 which acknowledges messages with psw_territory_upgrade_ack_s. Use ST command "dsegrnw" to verify DSP allocations after territory upgrades. Data transfer is successful. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_552 552_GPRS data transfer using CS-2 over packet abis 1.1 GPRS data transfer using CS-2 over Packet Abis

Description of test case:

Purpose of the test case is to check that encoding and sending of Packet Abis PCU UL Data Frames and decoding and receiving of Packet Abis PCU DL Data Frames is made correctly by PCU2 when CS-2 GPRS coding scheme is selected as initial coding scheme. Requirements: BSS21440-145 Packet Abis UL scheduling BSS21440-146 Packet Abis DL scheduling Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E or PCU2-D card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - PCU2 is connected to ETP - GPRS enabled BTS with one TRX created - CDED=1, CDEF=1, CMAX=100 Execution: Change CS-2 as an initial CS for uplink and downlink using MML command ZEQV. For example ZEQV:BTS=1:DCSA=1,UCSA=1; Start UL data transfer with 1 MS Stop data transfer Start DL data transfer with 1 MS Stop data transfer Use Wireshark to verify that CS-2 is used during UL and DL data transfer. Expected Results: Data transfer works correctly both UL and DL directions. CS-2 is used in both Packet Abis PCU UL Data Frames and Packet Abis PCU DL Data Frames during data transfer. No test case related errors in MCMU, BCSU or PCU2 logs.

SIV2_015_PABIS_454_563 563_EGPRS data transfer using MCS-9 over packet abis 1.1 EGPRS data transfer using MCS-9 over Packet Abis

Description of test case: Purpose of the test case is to check that encoding and sending of Packet Abis PCU UL Data Frames and decoding and receiving of Packet Abis PCU DL Data Frames is made correctly by PCU2 when MCS-9 EGPRS coding scheme is selected as initial coding scheme. Requirements: BSS21440-145 Packet Abis UL scheduling BSS21440-146 Packet Abis DL scheduling Required test environment: - Kantokoski + emulated MS, BTS, SGSN and GGSN - ETP-E or ETP-T card - PCU2-E or PCU2-D card - GPRS emulator version 4.8.6 or later - Linux version according to emulator package requirements - Application version (Kk): Latest available S15 software Required environment settings: - PCU2 and Packet Abis licenses are enabled - ETP is configured to BSC - PCU2 is connected to ETP - EGPRS enabled BTS with one TRX created - CDED=1, CDEF=1, CMAX=100 Execution: Change MCS-9 as an initial MCS for uplink and downlink using MML command ZEQV. For example ZEQV:BTS=1:MCA=9,MCU=9; Start UL data transfer with 1 MS. Stop data transfer. Start DL data transfer with 1 MS.

Stop data transfer. Use Wireshark to verify that MCS-9 is used during UL and DL data transfer. Expected Results: Data transfer works correctly both UL and DL directions. MCS-9 is used in both Packet Abis PCU UL Data Frames and Packet Abis PCU DL Data Frames during data transfer. No test case related errors in MCMU, BCSU or PCU2 logs.