AMR Test Analysis Ver1

Document version 0.1

Template Version 2.1

© Nokia Networks Oy

Company Confidential 1 (29)

AMR E2E Test analysis

Authors: Kai Närvänen

Approved by: SPF SG

Approval date: 10.11.2005

Owner: Kai Närvänen

Storage Place: PI: Projects/ GSM EDGE BSS RäD / System

Feature / AMR / E2E Testing

Company confidentialCompany confidentialCompany confidentialCompany confidential

This document may contain confidential information about testing

schedule, resources and organization. In storing the document, ensure

that access to the confidential information is limited only to the

program organization and to relevant stakeholders (if stored in

TestMan, check access control lists). Remove this comment from the

ready document.





ContentsContentsContentsContents

1111 INTRODUCTIONINTRODUCTIONINTRODUCTIONINTRODUCTION .......................................................................................... 4

1.1 Purpose of document ............................................................................ 4

1.2 Terms and abbreviations ....................................................................... 4 1.3 References and bibliography ................................................................. 5 1.4 AMR Feature ........................................................................................... 5

2222 AMR E2E Testing TargetAMR E2E Testing TargetAMR E2E Testing TargetAMR E2E Testing Target ............................................................................... 7

2.1 Test Environment ................................................................................... 8 2.2 Test Views ............................................................................................. 9

3333 Testing in the S12Testing in the S12Testing in the S12Testing in the S12 ..................................................................................... 12

3.1 S12 Testing Process ............................................................................. 12 3.1.1 Functional testing ................................................................................. 13 3.1.2 System testing ..................................................................................... 13 3.1.3 Performance Evaluation Testing .......................................................... 14 3.1.4 System Verification .............................................................................. 14 3.2 Testing status in the S12 ...................................................................... 15 3.2.1 Functional testing ................................................................................. 15 3.2.2 System Testing .................................................................................... 23 3.2.3 Performance evaluation ....................................................................... 23 3.2.4 System Verification .............................................................................. 23

4 Test Case verification against View Requirements ......................... 25 4.1 Test cases against Functional View requirements ............................... 25 4.2 Test cases against User View requirements ......................................... 27 4.3 Test cases against Operator View requirements .................................. 27

4.4 Test cases against Nokia View requirements ....................................... 28

5 Conclusion ......................................................................................... 29 5.1 How we can fill the Gap ....................................................................... 29





Summary of changesSummary of changesSummary of changesSummary of changes

Issue:Issue:Issue:Issue: Author:Author:Author:Author: Date:Date:Date:Date: Summary of changes:Summary of changes:Summary of changes:Summary of changes:

Ver0.0 Kai Närvänen 21.06.2004 First Draft

Ver0.1 Kai Närvänen 24.10.2004 Comments added





1 INTRODUCTION

1.11.11.11.1 Purpose of documentPurpose of documentPurpose of documentPurpose of document

The main purpose of this document is to clarify the AMR E2E

testing Situation inside BSS product development.

In chapter two is described target testing environment and

target mind set and base requirements for test case set for

AMR E2E Testing. In chapter three is described existing test

environment and Test cases. In chapter four is compared

target to current situation and also made some

improvement proposals to AMR E2E Testing

1.21.21.21.2 Terms and abbreviationsTerms and abbreviationsTerms and abbreviationsTerms and abbreviations

AMR Adaptive Multirate

E2E End-to-End i.e. Mobile to

Mobile

HO Handover





1.31.31.31.3 References and References and References and References and bibliographybibliographybibliographybibliography

Document name Date/

Version

Author Location of

document or link

/1/ Nokia Adaptive Multi Rate Codec

Solution Description

12.11.2004

/1.2

Outi

Iltanen

/2/

/3/

/4/

/5/

/6/

/7/

1.41.41.41.4 AMR FeaAMR FeaAMR FeaAMR Featureturetureture

The idea behind the AMR codec concept is that it is capable

of adapting its operation optimally according to the

prevailing channel conditions.

Unlike previous GSM speech codecs (FR, EFR, and HR), which

operate at a fixed rate and constant error protection level,

AMR speech codec adapts its error protection level to the

local radio channel and traffic conditions. AMR codec consists

of a family of codecs. In high-error conditions more bits are

used for error correction to obtain error robust coding, while

in good transmission conditions only low amount of bits is

needed for sufficient error protection and more bits can

therefore be allocated for source coding. This flexibility

provides a number of important benefits:

• Improved speech quality in both half-rate and full-

rate modes by means of codec mode adaptation i.e.

by varying the balance between speech and channel

coding for the same gross bit-rate;

• The ability to trade speech quality and capacity

smoothly and flexibly by a combination of channel

and codec mode adaptation; this can be controlled by

the network operator on a cell by cell basis;

• Improved robustness to channel errors under

marginal radio signal conditions in full-rate mode.

This increased robustness to errors and hence to

interference may be used to increase capacity by

operating a tighter frequency re-use pattern;





• Ability to tailor AMR operation to meet the different

needs of operators;

• Potential for improved handover and power control

resulting from additional signalling transmitted

rapidly in-band. /1/





2 AMR E2E Testing Target

AMR E2E testing should be as close as possible to Real Life. Real Life

can be described from chopper point of view with very simply way:

AMR Mobile Users are calling to each other and also to Non AMR

mobile. Operator is maintaining network and collecting Counter and

measurement information and offering services to Customer as

competitive way as possible. Nokia is offering own equipments to

operator in very competitive market.

This Real life situation sets requirement to Test environment and also

to way to make test. Test Environment should support all functions

that are happening in real life. And when we are making the test we

have to take account not only technical point t of view but also

Operator, End user and Nokia Point of views. In example when we

are testing Link adaptation change, we should also take account how

it will affect to Voice Quality, how counters are updated, is this limit

value to make link adaptation change best one and how operator

can be confirmed about it.

Scope of the AMR E2E testing is to improve AMR competitiveness by

• optimize the AMR performance

• find better values for default parameters

• Supporting our Product Management and Marketing by giving

information about capability improvements





2.1 Test Environment

1 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials

Company Confidential

AMR E2E Test Network

AMR Phone

AMR Phone

AMR Phone

Non AMR

Phone

BSCBSC

AMR BTS

AMR BTS

AMR BTS

NON AMR BTS

NON AMR BTS

MSC

NMS

TCTC

AMR Phone

AMR Phone

Non AMR

Phone

Non AMR

Phone

Non AMR

Phone

Non AMR

Phone

Traffic Simulator Traffic Simulator

Testing environment should support followed functions:

• Calls between two AMR and non AMR terminals. Terminals can

be located under same BTS (AMR and NON AMR), BSC or MSC.

• Link adaptation changes during Call

• Packing / Unpacking during call

• Tandem free operation

• Intra-BSC handovers, with and without Packing / Unpacking

and with and without Link Adaptation changes.

• Intra-BSC handovers between AMR BTS and Non AMR BTS

• Inter-BSC handovers, with and without Packing / Unpacking

and with and without Link Adaptation changes.

• Inter-BSC handovers between AMR BTS and Non AMR BTS

• A- interface pool changes

• Unsuccessful handovers because of Capacity reason or Link

adaptation changes failure or Packing/ unpacking failure

• Unsuccessful Link Adaptation changes and Packing/

Unpacking

• Counters and measurement reports sent to NMS system.

(Needs traffic generators)

• AMR Feature operating via NMS





• Licence Issues (licence delivery, update, pilot licence)

• Bad ACCH channel situations (i.e. Voice is OK, but ACCH

collapse)

• Voice Quality measurement by using human being or

equipment

•

2.2 Test Views

During The E2E test AMR system should be study from four different

perspectives.

2 © 2005 Nokia V1-Filename.ppt / yyyy-mm-dd / Initials

Company Confidential

Four Different Views

AMR

Operator View:

-Operability

-Performance

-Measurement

-Capacity

-Reliability

Functional View:

-Handovers

-Packing/ Unpacking

-Link Adaptation

End-User View:

-Voice Quality

-Accessibility

-Retainability

Nokia View:

-Market Arguments

-Future Improvements

-Parameter optimization

-Customer support

Functional ViewFunctional ViewFunctional ViewFunctional View

Functional view is most common of the Testing Views. This is what

normally has been tested. We implement new functionalities and test

them.

In pervious chapter requirements for test environment is covering list

of functions that should be tested.

• Link adaptation

• Packing /unpacking

• Handovers

• Call establishment

•





EndEndEndEnd----User ViewUser ViewUser ViewUser View

End user is not aware about technical details. He will never know

what codec is used or via which BTS his call is routed. He may be

aware that he is having AMR Mobile. The issues that end user is keen

on is quality of the voice during the call, is call dropped and can he

make a call anytime and anywhere he want to.

When we are making calls from End user point of view we should

consider followed issues:

• How Link adaptation change, Handover or

Packing/Unpacking will affect to voice quality. Is there some

break or irritating noise during itä

• Is Voice Quality good during bad Air Conditions period and is

call up and running

• Can End user make call from bad air condition area and what

is quality of the call in the begin of the call and what are the

limitation to make call

Operator ViewOperator ViewOperator ViewOperator View

Operators main target is make profit by offering Mobile services to

end user. To achieve this goal operator has to keep end user

satisfied. That Operator can do by offering good voice quality and

large coverage with acceptable price. To be able to Offer all this to

end user operator have to invest network. To keep network (money

making machine) in good shape operator needs to collect and

analyse information how it is working. To keep price acceptable the

target of the investment has to be well planned and also the

maintenance of the network should not be expensive.

And when we are making test cases from Operator point of view we

should consider followed issues:

• How feature can be operated and maintained. Is it easy to

use with MML or NetActä Is there some Macro to install this

featureä

• Are there counters or Measurements that tell status of

networkä Is Values of the counters and measurements

reliableä

• If some parameter value is changed how it will affect to

Countersä

• What is performance of AMR and how it can be improvedä

What are the correct parameters values for different kind of

environmentä And how can operator be sure that wanted

improvement is really happened. Are there any counters to

follow thisä

• Are counters also supported by NetActä





• Do our documentation describing behaving of counters

Nokia ViewNokia ViewNokia ViewNokia View

Sales and Marketing is a main internal customer for RäD. RäD is

developing SW that SäM sell to the Operators. But RäD can serve SäM

much better way. Added to SW delivery RäD can also deliver sales

argument to SäM. And now I mean measurement data how will new

feature improve Capacity or voice Quality.

Another Important internal customer for RäD is Customer support.

RäD should be able to deliver all operational information concerning

new features to Customer Support. That way Customer support is

better way to repaired to answer question and gives operators

feeling that Nokia is more Professional Vendor that others.

When we are making testing from Nokia point of view, we should

concentrated following issues:

• New ideas of the Capacity and voice quality improvements

• Parameter optimization. There are default values for the

parameters, which are not the best values for the Parameters

• Error information and recovery action delivery to Customer

support.

• Measured information how much new features will increase

Capacity or Voice quality.

• How Operator can verify functionality of the new features by

using counters and measurements





3 Testing in the S12

3.13.13.13.1 S12 S12 S12 S12 Testing ProcessTesting ProcessTesting ProcessTesting Process





3.1.1 Functional testing

Functional Testing is Network Element (NE) level testing. FT is the

main test phase of the NE. The purpose of the FT phase is to ensure

that:

• All SW modules work together and do not cause harm to

each others

• All new functionalities work correctly

• All old functionalities work correctly

Used methods in NE level FT are:

• Black box testing - which means analyzing the product

controller interfaces

• White box testing - which means analyzing the messaging

between the program modules

Testing is divided into project planning; test planning, test design

and test execution and reporting phase. The progress of planning

specifying and executing the functional testing is tightly

synchronized with the time schedule and milestones of the product

programs.

3.1.2 System testing

The purpose of ST is to ensure that the whole product (system) works

as it is meant to work in the circumstances and procedures that

correspond to the intended use of the product, that no functionality

or features are missing and that no unwanted functionality appears.

ST gains confidence in the product that it is ready for delivery to the

customer.

System testing is done from the operators and network element

point of view. System testing verifies user requirements and

procedures. This includes testing of the basic HW and SW

configuration, new and old features, fault situations, restarts, and

maintenance and so on. In other network elements released

software is used, if possible. If something else than released software

is used this has to be agreed between system testing, release

program management and also compatibility testing. System testing

uses real network elements and mobile phones (as well as

compatibility testing).

System testing ends when exit criteria are fulfilled (more about exit

criteria in system test execution and reporting phase).

System testing works in co-operation with the System verification.

System verification verifies part of the end to end features.





3.1.3 Performance Evaluation Testing

In System Test (ST) level, testing is done from the Product (that is

considered as a system) and also customeräs (when necessary) point

of view with real typical complementary environment. Simulators

(e.g. load/traffic generators) are used when necessary.

The purpose of ST is to ensure that the whole product (system) works

as it is meant to work in the circumstances and procedures that

correspond to the intended use of the product. ST gains confidence in

the product that it is ready for delivery to the customer. See more in

IäV terminology and abbreviations.

In System Test level, there are several testing areas each with

different objectives and methods. The testing areas and their phasing

are described under the attached links. The workflow described in

this process applies both to individual testing areas and to several

testing areas grouped depending on IäV project structure defined in

master test

Performance Evaluation Testing is not part of The Product Program.

3.1.4 System Verification

System Verification is not part of The Product Program. The objective

of System verification (SyVe) is to verify end-to-end functionalities of

the entire network system (including applications, terminals and

possible backbones). The verified system could also be a network

sub-system. The main idea in verification is to use real environment

even only sub-system is verified.

SyVe does not mean that everything is verified but the functionality

specified by the ordered work. The functionality to be verified is

typically specified in new requirements for end-to-end system

services/functionalities (in network level) or in new system feature

specifications (in sub-network level). In system release programs, the

verified functionality can also include also existing system end-to-

end functionality (regression testing).

The aim is to verify system solutions or functionality in real network

and to find out faults that do not appear in other testing phases

inside product programs or which are not even possible to find out

without real network environment. So SyVe does not replace any

product programs testing phases. Instead, SyVe can be seen as

äinternal pilotä for new end-to-end functionalities. Via SyVe it is also

possible to get competence, which can be taken advantage when

new network functionality is designed.





3.2 Testing status in the S12

3.2.1 Functional testing

In S12 four Test teams are testing AMR Features:

• TT01 (Call establishment)

• TT09 (Licensing)

• TT13 (AMR)

• TT14 (Q3)

• TT15 (Counters)

• TT16 (DFCA)

• TT19 (A /Ater interface)

TT01 Test cases

• IT001R005801 Assignment procedure (successful case)

• IT001R005802 Assignment procedure, AMR disabled

• IT001R005803 Assignment procedure, FR/HR case

• IT001R005805 Assignment procedure, multirate configuration IE not present (abnormal case)

• IT001R005806 FACCH call setup (successful case)

• IT001R005807 FACCH call setup (abnormal case), MS does not support the indicated mode

• IT001R005808 Mode modify (successful case)

• IT001R005809 Mode modify (abnormal case), MS does not support the indicated mode

AMR CR Case

• IT010CR50000 "AMR Radio link timeout parameter (ARLT) value is send in TCH Channel Activation message to MS when AMR call in case"

Pronto cases with ARM

• IT010PRN0012 PR 1-43747312: No queue for AMR calls from non-AMR BTS

• IT010PRN0010 PR 1-23321183: FRF-CSL02278: S10.5 ED E5 CD2.0 HR/FR/DR/AMR: AMR ME call setup failed on RTSL0 of NBCCH Talk-family

TT09 Test cases





Test Team 9 is testing AMR HR License installation, updating and working

TT13 Test cases

Adaptive Multi Rate (AMR) Speech Codec

• IT0131000401 : AMR: Packing/unpacking of FR AMR calls to HR AMR calls - Packing is done due to cell load and unpacking is done due to call quality

• IT0131000402 : AMR: No packing of FR AMR calls when cell load is full

• IT0131000403 : AMR: External HO, source side (successful case)

• IT0131000404 : AMR: External HO, target side - Preferred multirate configuration is currently used

• IT0131000405 : AMR: External HO, target side - Preferred multirate configuration is the multirate configuration of target

BTS

• IT0131000406 : AMR: No intra BSC DADL/B HO - AMR FR call to cell with AMR DADL/B capable adjacent cells and serving cell(AMR capable) has free TCHs

• IT0131000407 : AMR: Intra BSC DADL/B HO - AMR HR call to cell with AMR DADL/B capable adjacent cells and serving

cell(not AMR capable) has free TCHs

• IT0131000408 : AMR: BSC external DR handover (source side) - due to congestion (no TCHs available) with queuing

• IT0131000409 : AMR: External HO, source side (abnormal case), inconsistent Multirate Configuration IE

• IT0131000410 : AMR: Intra-cell handover from a regular TRX to Super-reuse TRX in IUO - due to super reuse good C/I threshold for AMR FR

• IT0131000411 : AMR: Intra-cell HO from super-reuse to regular in IUO - due to super reuse bad C/I threshold for AMR HR

• IT0131000412 : AMR: PC(more/less power) - Rx quality is below lower AMR FR threshold/above upper AMR FR threshold (Slow AMR LA disabled)

• IT0131000413 : AMR: PC(more/less power) - Rx quality is below lower AMR HR threshold/above upper AMR HR threshold (Slow AMR LA disabled)

• IT0131000414 : AMR: PC(more/less power) - Rx quality is below lower AMR FR threshold/above upper AMR FR threshold (Slow AMR LA enabled)





• IT0131000415 : AMR: PC(more/less power) - Rx quality is below lower AMR HR threshold/above upper AMR HR threshold (Slow AMR LA enabled)

• IT0131000416 : AMR: Inter cell HO - AMR codec set downgrades (new parameter Initial AMR channel rate, AMR

codec mode set downgrades and upgrades)

• IT0131000417 : AMR: Inter cell HO - AMR codec set upgrades

• IT0131000418 : AMR: Inter cell HO failure - HANDOVER_COMMAND contain inconsistent Multirate Configuration IE (abnormal case)

• IT0131000419 : AMR: Inter cell HO - AMR codec set of the source BTS differs from target BTS and parameter AMR codec mode set downgrades and upgrades denies upgrades/downgrades

• IT0131000420 : AMR: Inter cell HO - Target cell does not support AMR calls

• IT0131000421 : AMR: Inter cell HO - Target cell does not support AMR calls (AMR disabled)

• IT0131000422 : AMR: Packing/unpacking of FR AMR calls to HR AMR calls - Packing is done due to cell load and unpacking is

done due to call quality in IUO

• IT0131000423 : AMR HO Optimization, Internal intra-cell handover for AMR call

• IT0131000424 : AMR HO Optimization, Internal inter-cell handover for AMR call, Codec sets in source- and target BTS’s

are identical

• IT0131000425 : AMR HO Optimization, Internal inter-cell handover fails for AMR call, Codec sets in source- and target BTS’s are identical

• IT0131000426 : AMR: AMR HR call. Quality based inter-cell HO with all codecs

• IT0131000427 : Pronto 6148ES11P : AMR HR usage checked correctly

• IT0131000428 : Pronto 1-36063202 : AMR packing is stopped when resources are not any longer available, case1

• IT0131000429 : Pronto 1-36063202 : AMR packing is stopped when resources are not any longer available, case2

• IT0131000430 : Pronto 1-37706263 : AMR packing state is checked after TCH channel is released

• IT0131000431 : Pronto 1-37706263 : AMR packing state is checked after TSL or TRX is de-blocked

• IT0131000432 : Pronto 7703ES11P AMR, HO/PC thresholds used correctly





• IT0131000433 : Pronto 7703ES11P : AMR, HO/PC thresholds used correctly.

• IT0131000434 : Pronto 1-39462846 : AMR, directed retry to non-AMR BTS.

• IT0131000435 : Pronto 1-42114181: AMR, Cingular MaxCap - RxQuality handover enables unpacking when handover is not happen

• IT0131000436 : Pronto 1-42114186: AMR, Cingular MaxCap - RRM is packing FR calls to HR during intra-cell interference handover

• IT0131000437 : Pronto 1-42617277 : Initial channel rate for AMR calls, IAC = 2.

• IT0131000438 : BSS20209 AMR, Remove or relax codec dependency for AMR HR packing correction

• IT0131000439 : Pronto 1-47131161 : AMR, UTPFIL-file patch for MIDR and MADR in case of AMR DADL/B handovers.

• IT0131000440 : Pronto 1-53312961: Penalty timer after unsuccessful AMR packing/unpacking.

• IT0131000441 : Pronto 1-55245695: Pool switching - AMR disabled in BTS.

• IT013PRN0006 : Prontos 351146, 350146 and 598053: Packing and unpacking of FR AMR and HR AMR calls, unpacking is done regardless of the used codec mode. AMR half rate mode sets updates correctly

• IT013PRN0012 : Pronto 400146 : AMR counters in RXQ report

• IT013PRN0014 : Pronto 36372: Initial AMR channel rate is set to AMR FR, AMR FR channel is allocated

• IT013PRN0015 : Pronto 648146: DADL/B HO from PGSM900 to GSM1800 cell, AMR active in BSC; successful case

• IT013PRN0016 : Pronto 660146: Intra BSC DADL/B HO - AMR DADL/B capable adjacent cells, AMR disabled in serving cell

• IT013PRN0020 : Pronto 827146: AMR counters when BTS Measure Averaging is used

• IT013PRN0023 : Pronto 2041ES04P : AMR FACCH call when

Slow AMR LA is used

• IT013PRN0032 : Pronto 3117ES09P, Initiation of AMR DADL/B

• IT013PRN0034 : Pronto 1-23321114, AMR-interworking with queuing and Circuit Pool switching

• IT013PRN0039 : Pronto 1-37858051, TCH allocated using right codec in certain circumstances in cases of internal intercell

handover

• IT013PRN0042 : Pronto 1-37549351 : AMR, external HO is working

same way than internal HO in certain circumstances.





BSS Licensing

• IT0131116401 : AMR Half Rate TRX count ON/OFF – effects to AMR packing

• IT0131116402 : AMR Half Rate TRX count ON/OFF – effects to HR3 codec in speech codec list

• IT0131000411 : AMR: Intra-cell HO from super-reuse to regular in IUO - due to super reuse bad C/I threshold for AMR HR

• IT0131000413 : AMR: PC(more/less power) - Rx quality is below lower AMR HR threshold/above upper AMR HR threshold

(Slow AMR LA disabled)

TT14 Test Cases

Test team 14 is testing AMR Parameter handling over Q3 with OSITEST/NM Program.

TT15 Test Cases

Test Team 15 is testing some AMR related counters

TT16 Test Cases

Dynamic Frequency Channel Allocation (DFCA)

• IT016DCA0201 DFCA. C/N Check for cell access control. Call setup and intra-cell handover. Single band network.

• IT016DCA0202 DFCA. C/N Check for cell access control. Common BCCH network.

• IT016DCA0204 DFCA. Soft blocking in 1-way DL check. Single band network. Intra-cell adjacent channel interference.

• IT016DCA0206 DFCA. Soft blocking in 2-way DL check. Common BCCH network. Inter-BSC inter-segment adjacent and co-channel interference.

• IT016DCA0211 DFCA. Soft blocking in 2-way UL check. Inter-BSC inter-cell co-channel interference.

• IT016DCA0212 DFCA. C/I target in 1-way DL check. GSM900 single band network. Intra-BSC inter-cell adjacent channel interference.

• IT016DCA0213 DFCA. C/I target in 1-way DL check. GSM900/GSM1800 common BCCH network. Inter-BSC inter-

segment co-channel interference.





• IT016DCA0214 DFCA. C/I target in 2-way DL check. GSM1800/GSM900 common BCCH network. Intra-BSC inter-segment co-channel interference.

• IT016DCA0215 DFCA. C/I target in 2-way DL check. GSM1800 single band network. Inter-BSC inter-cell adjacent channel

interference.

• IT016DCA0231 DFCA and queuing. DFCA connection released. Multiple requests in queue.

• IT016DCA0232 DFCA. Informing the neighbouring BSCs about channel assignment and release. Call setup and release case

• IT016DCA0240 DFCA - PR 11187ES09P: DFCA 1582 CONNECTION OR RELEASE ERROR

• IT016DCA0248 DFCA: Inter-Cell HO with AMR Packing.

• IT016DCA1101 DFCA – Forced HR/AMR HR mode. Entering and exiting forced mode.

• IT016DCA1102 DFCA – Forced HR/AMR HR mode. Forced mode handling during Measurement Relation Initiation and

Measurement Relation Termination.

• IT016DCA1103 DFCA – Forced HR/AMR HR mode. Band specific forced operation.

• IT016DCA1104 DFCA – Forced HR/AMR HR mode. Common BCCH & Dual Band operation.

• IT016DCA1201 DFCA - Changing preference between DFCA and non-DFCA resources.

Enhanced TRX Priorisation on TCH Allocation

• IT016ETP0001 TCH channel is allocated primary from BCCH

TRX for the non AMR calls and for AMR calls primary beyond

BCCH TRX

RxLev Min Access (S11.5 CR14)

• T016RMA0002 RXLEV MIN ACCESS. C/N Check for cell access control. Call setup.

• IT016RMA0003 RXLEV MIN ACCESS. C/N Check for cell access control. Call setup, intra BSC inter-cell and external handovers.

• IT016RMA0006 RXLEV MIN ACCESS. Pool switching - Call setup. (PR 14050ES09P).

• IT016RMA0007 RXLEV MIN ACCESS. Pool switching - Internal inter-cell handover. (PR 14050ES09P).

• IT016RMA0008 RXLEV MIN ACCESS. Pool switching – Call setup. Counter 1194 TCH_ACC_REJ_DUE_LOW_RX. (PR

14050ES09P).





Pronto Cases

• IT016PRN0019 Problem report 1-49965451: TRHO does not work when AMR Handset makes MO call on NON AMR BTS

• IT016PRN0020 Problem report 8249ES10P: CS TCH allocation calculation (CTC) parameter is not observed in AMR packing

Single Antenna Interference Cancellation (SAIC)

• IT016SAIC0001 SAIC - DFCA TCH allocation in call setup

• IT016SAIC0002 SAIC - DFCA TCH allocation. External handover to regular layer, followed by intra-cell handover to DFCA layer

Dual Transfer Mode (DTM)

• IT016DTM0101 DTM - MO DTM call establishment: Basic MO DTM call. CS connection originally in CS territory

• IT016DTM0127 DTM - MO DTM call establishment: Speech codec usability evaluation. AMR case

• IT016DTM0132 DTM - MO DTM call establishment: AMR allocation from another BTS. Mode modify procedure triggered.

• IT016DTM0201 DTM - MT DTM call establishment: Basic MT DTM call. CS connection originally in CS territory

• IT016DTM0224 DTM - MT DTM call establishment: Speech codec usability evaluation. AMR case

• IT016DTM0230 DTM - MT DTM call establishment: AMR allocation from another BTS. Mode modify procedure triggered

TT19 Test cases

Test cases for AMR pool testing in the A/ Ater- interface.

• IT0195003008 Modification of AMR type TC_PCM to EFR&FR type TC_PCM

• IT0195001009 Modification of AMR type TC_PCM to EFR&FR&HR&D144 type TC_PCM

• IT0195001015 Modification of AMR type TC_PCM to FR type TC_PCM when only existing FR type TC_PCM is NS

• IT0195001012 Modification of EFR&FR&HR&D144 type TC_PCM to AMR type TC_PCM

• IT0195001013 Modification of FR type TC_PCM the old type transcoder to AMR type TC_PCM

• IT0195001014 Modification of HR type TC_PCM to AMR type TC_PCM





• IT0195002006 Modification of FR type TC_PCM to AMR type TC_PCM

• IT0195002007 Try to modify AMR type TC_PCM to EFR&FR type TC_PCM when TCSM2 state is wrong

Test cases for New TCSM-pools

• IT0195004001 TCSM3i - Creating TC_PCM in ETSI environment

• IT0195004002 TCSM3i - Modifying TC_PCM in ETSI environment

• IT0195004003 TCSM3i - Unsuccessful TC_PCM modification in ETSI environment

• IT0195004004 TCSM3i - Delete TC_PCMs in ETSI environment

• IT0195004005 TCSM3i - Miscellaneous configuration handling in ETSI environment

• IT0195005001 TCSM3i - Creating TC_PCM in ANSI environment

• IT0195005002 TCSM3i - Modifying TC_PCM in ANSI environment

• IT0195005003 TCSM3i - Unsuccessful TC_PCM modification in ANSI environment

• IT0195005004 TCSM3i - Delete TC_PCMs in ANSI environment

• IT0195005005 TCSM3i - Miscellaneous configuration handling in ANSI environment

TCSM2/TCSM3i SW DL cases. AMR is involved because TCSM2 has own TD-software for ARM. AMR call is done after every test case.

• IT0195901007 TCSM2E, SW downloading and unit restart

• IT0195901003 TCSM2E, SW downloading with C=OPT and TCSM WO-EX

• IT0195901002 TCSM2E, SW downloading with C=TOT and TCSM TE-EX

• IT0195901004 TCSM2E, SW downloading with C=TOT and TCSM WO-EX

• IT0195902001 TCSM2A and TCSM2A-C, SW downloading (parallel pre-processor loading)

Location test cases. AMR call is done after every test case.

• IT0071110012 U-TDOA method, AMR support for U-TDOA

• IT0071110013 U-TDOA method, Intra BSC HO with AMR support





• IT0071110015 Commercial U-TDOA and AMR support for U-TDOA

• IT0071110016 U-TDOA method, AMR parameter sending to S/A SMLC

• IT0071110018 U-TDOA method, AMR support for U-TDOA during FACCH call setup

• IT0071110019 U-TDOA method, AMR support for U-TDOA in HO target BSC

3.2.2 System Testing

In system Testing followed test cases are tested:

• STS1001O0001 Activating Adaptive Multirate Codec (AMR) Feature

• STS1001O0003 AMR call, Intra cell hand over

• STS1001O0004 AMR call, Inter cell hand over

• STS1001O0005 AMR call, Inter cell hand over between AMR and normal cell

• STS1001O0007 Spontaneous packing and unpacking of AMR calls

• STS1001O0008 Deactivating Adaptive Multirate Codec (AMR) Feature

• STS1103O0011 Common BCCH and Dual Band with DFCA

• STS1103O0009 Soft blocking in Common BCCH network

• STS11052O001 C/I based FR/HR rate selection (forced HR mode)

• STS0903B0001 Tandem free operation

3.2.3 Performance evaluation

In Performance evaluation there is not any call traffic, so AMR

features is not tested

3.2.4 System Verification

Listed test cases are S11.5 test cases, because scope of S12 SyVe is not

planned yet

• SVS10CAO201AMR spontaneous packing and unpacking of

AMR calls





o The purpose of this case is to verify that AMR

spontaneous packing and unpacking feature allocates

calls from fullrate channels to halfrate channels until

the amount of available fullrate resources is above

specified limit. Halfrate calls are upgraded to fullrate

channels as the rx quality of the calls decreases below

specified limits.

AMR Call is done during followed testcases:

• SVS115CAO312 DFCA, C/I based FR/HR rate selection (forced HR

mode)

o The purpose of the test is to verify that cell enters and

exists forced HR rate mode due to overall load (C/I)

situation. AMR codecs are used. Counter are checked

with NetAct (OSS4).

• SVS115CAO312 DFCA, C/I based FR/HR rate selection (forced HR

mode)

o The purpose of the test is to verify that cell enters and

exists forced HR rate mode due to overall load (C/I)

situation. AMR codecs are used. Counter are checked

with NetAct (OSS4).

• SVS115VAO501 AMR Support For U-TDOA (This case may be

dropped)

o The purpose of this test case is to verify AMR support

for U-TDOA positioning in emergency service case

when S/A SMLC is in use.





4 Test Case verification against View Requirements

4.14.14.14.1 Test cases against Functional View requirementsTest cases against Functional View requirementsTest cases against Functional View requirementsTest cases against Functional View requirements

FT/ Test

Team 01

FT/ Test Team

13

FT/ test

Team 14

FT/ test

Team 15

FT/ Test Team

16

FT/ Test

Team 19

FT/ Test Team

09 SyTe SyVe

Calls between two AMR and non AMR

terminals. Terminals can be located

under same BTS (AMR and NON AMR),

BSC or MSC. X X

X X X X

Link adaptation changes during Call X

Packing / Unpacking during call X X X

Tandem Free Operation X

intra-BSC handovers, with Packing /

Unpacking X

intra-BSC handovers with Link

Adaptation Changes X

Intra-BSC handovers, without Packing /

Unpacking and without Link Adaptation

changes. X

Intra-BSC handovers between AMR BTS

and Non AMR BTS X

Inter-BSC handovers with Packing /

Unpacking X

X

Inter-BSC handovers with Link

Adaptation changes. X

Inter-BSC handovers without Packing /

Unpacking and without Link Adaptation

changes. X

Inter-BSC handovers between AMR BTS

and Non AMR BTS X

X

A- interface pool changes X X





Unsuccessful handovers (because of

Link adaptation changes failure or

Packing/ unpacking failure) X

Packing/ unpacking failure X

Unsuccessful Link Adaptation changes X

Power Control during AMR Call X

Interworking with DFCA X

AMR Related Counters X

X note

4

Counters and measurement reports sent

to NMS system.

x

note 1

AMR Feature operating via NMS

x note

3

License Issues (license delivery, update,

pilot license) X

X note

5

Bad ACCH channel situations (i.e. Voice is

OK, but ACCH collapse)

x note

2

Voice Quality measurement by using

human being or equipment

Note 1: Only Couple calls are made. I.e. it is verified that counter values will

change

Note 2: Scope of testing is in the DCFA feature

Note 3: Q3 changes is tested with OSITEST/NM program

Note 4: Some counters are tested

Note 5: TT09 is testing AMR HR license Installation, updating and working.

License is delivered via FTP





4.24.24.24.2 Test cases against Test cases against Test cases against Test cases against UserUserUserUser View reqView reqView reqView requirementsuirementsuirementsuirements

Note 1: Scope of the testing is testing functionality not the affect to the Voice

Quality

4.34.34.34.3 Test cases against Test cases against Test cases against Test cases against OperatorOperatorOperatorOperator View requirementsView requirementsView requirementsView requirements

Note 1: Only one / couple calls are made. In example DRC verification

between different BSC releases can not be done.

Note 2: Q3 changes is tested with OSITEST/NM program

Note 3: TT09 is testing AMR HR license Installation, updating and working

FT/ Test Team

01

FT/ Test

Team 13 SyTe SyVe

Link adaptation changes during Call x

note 1

Packing / Unpacking during call x

note 1 x

note 1 x

note 1

Voice Quality measurement by using

human being or equipment

Retainability

Accessibility

Bad ACCH channel situations (i.e. Voice is OK,

but ACCH collapse)

FT/ Test

Team 09

FT/ Test

Team 14 SyVe

Counters and measurement reports sent to

NetAct system. (Needs traffic generators)

x

note 1

AMR Feature operating via NetAct

x note 2

License Issues (license delivery, update,

pilot license) x note 3

Performance

Capacity

Reliability





4.44.44.44.4 Test cases against Test cases against Test cases against Test cases against NokiaNokiaNokiaNokia View requirementsView requirementsView requirementsView requirements

FT/ Test

Teams PET SyTe SyVe

New ideas of the Capacity and voice quality

improvements

Parameter optimization

Error information and recovery action

delivery to Customer support

Measured information how much new

features will increase Capacity or Voice

quality

Guidelines how Operator can verify

functionality of the new features by using

counters and measurements





5 Conclusion

The testing of the AMR Functionality is covered very well. It’s not surprising,

because this is the Nokia Traditions; we are implementing and verifying all

technical tricks. Also our Development Process supports this finding, because

it is description that our main testing phase is FT. FT is focused to test that all

SW modules work together and don’t cause harm to each others, all new

functionalities work correctly and all old functionalities work correctly.

Unfortunately rest of the views are not so well tested. I can claim that there is

not any test case that measures voice quality at all or Counters with heavy

load. Also we are not repaired for testing AMR affect of new Improvements

like Progressive Power Control against existing functionality. To Support our

Marketing and sales we should be able to argument that new feature can

improve capacity 7% against older SW version.

5.15.15.15.1 How we can fill the GapHow we can fill the GapHow we can fill the GapHow we can fill the Gap

To add missed test cases to FT teams is almost impossible. Scope of the

Functional testing is and according to process description FT can be done

against simulators. Also scope of the FT Testing is not matching to scope of

the E2E testing. In E2E testing the whole GSM system can be handled as

Black box.

If I have to select the best home for new test cases from existing test phases,

my selection will be SyVe. SyVe should have test team that is focused to the

AMR E2E testing. This test Team should be charge of

• Voice quality measurement

o They should be able to prove Voice quality improvements by

using MOS reports

• Capacity or Performance Improvement

o They should be able prove capacity and Performance

improvements by using NetAct Counters and Measurements

• Retainability and accessibility during bad air conditions

o They should be able prove capacity and Performance

improvements by using NetAct Counters and Measurements

• Verify recommended Measurements and counters

New laboratory we don’t need to establish. Dallas Load laboratory has already

required equipments.

AMR Test Analysis Ver1

Documents

Transcript of AMR Test Analysis Ver1