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.
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 2 (29)
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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 3 (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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 4 (29)
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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 5 (29)
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;
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 6 (29)
• 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/
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 7 (29)
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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 8 (29)
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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 9 (29)
• 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
•
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 10 (29)
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ä
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 11 (29)
• 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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 12 (29)
3 Testing in the S12
3.13.13.13.1 S12 S12 S12 S12 Testing ProcessTesting ProcessTesting ProcessTesting Process
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 13 (29)
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.
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 14 (29)
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.
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 15 (29)
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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 16 (29)
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)
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 17 (29)
• 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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 18 (29)
• 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.
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 19 (29)
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.
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 20 (29)
• 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).
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 21 (29)
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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 22 (29)
• 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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 23 (29)
• 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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 24 (29)
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.
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 25 (29)
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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 26 (29)
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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 27 (29)
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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 28 (29)
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
Document version 0.1
Template Version 2.1
© Nokia Networks Oy
Company Confidential 29 (29)
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.
Recommended