Hd 3g voice activation

tips for implementation

General description
› HD Voice is a network functionality where E2E support is needed , i.e. across the whole
communication path: UE, RAN and Core elements
› Transport elements need to be compatible also
› Lighthouse and CPI ELEX documentation stablish basic requirements, but information can be
confuse given that this functionality has evolved from his first implementations and elements across
the whole network are involved
› The base or mandatory feature activation on RAN is ‘FAJ 121 1059 AMR WB Speech’. However,
there are some additional features to help to keep the Speech call with AMRWB together with other
RABS, which are described on following slides
› Additional features are needed for operations with 2G HD Voice

We will focus here only on the 3G RAN

part, but the general principles can be
adapted easily to a global 2G/3G
implementation

AMR WB Lessons Learned | 2017-12-05 | Page 2

BASIC core FEATURE FRAME
(lighthouse reference)
MSC

MGW FAJ 121 866 and FAJ 121 939 (Tandem

Free Operation - TFO), are as well
needed in pure 3G scenarios to allow
end-to-end wideband speech after inter-
MSC/inter-MGWSRNS relocation.
FAJ 121 551 (Compressed Speech on
Nb) will be needed for inter MGW AMR
WB communications

AMR WB Lessons Learned | 2017-12-05 | Page 3

Basic Core pre-conditions for HD 3G
VOICE

The above table summarizes the bare minimum needed typically on 3G only scenarios

Note: for 2G, additional features are needed

AMR WB Lessons Learned | 2017-12-05 | Page 4

BASIC RAN FEATURE FRAME
(lighthouse reference)
Quick Tip #1:
Not all features are
needed for AMR HD
Voice Operation (but the
ones included will be
enough for UMTS
implementation)

Quick Tip #2:

To better understand
and adapt the HD
implementation to an
specific scenario, is
better to divide the
features on categories
associated with the
involved network
element

Quick Tip #3:

In order to work
concurrently with AMR-
NB, Features FAJ 121
1084 & FAJ 121 1378 in
the RAN are needed

AMR WB Lessons Learned | 2017-12-05 | Page 5

Features map
Node Type Feature Name Feature Number Remarks
AMR-WB Speech FAJ 121 727 Mandatory
Transcoder Free Operation
FAJ 121 528 Pre-requisites
MSC-S (TrFO)
Enhanced User Equipment
FAJ 121 0850 Optional
Capability Analysis for AMR
AMR-WB Speech FAJ 121 0163 Mandatory
MGW
Compressed Speech on Nb FAJ 121 551 Pre-requisites
AMR WB Speech FAJ 121 1059 Mandatory
AMR WB speech and PS
FAJ 121 1060 Optional (needed for Voice + Basic PS Multibearer operation)
Interactive RAB combination
AMR WB speech and HSDPA
FAJ 121 1061 Optional (Needed for Voice + PS HS Multibearer operation)
Interactive RAB combination
AMR WB speech and two times
PS interactive RAB FAJ 121 1062 Optional (needed for this specific RAB Combination)
combination
AMR WB speech and HSPA PS
FAJ121 1337 Optional (needed for EUL operation with HD Voice)
RNC Interactive RAB Combination
128 kbps and PS Interactive 8
kbps RAB combination AMR- FAJ 121 1066 Optional (needed for this specific RAB Combination)
WB Speech, PS Streaming
TrFO Support for AMR multi-
FAJ 121 1378 Pre-requisites
mode
TrFO support for Speech 12.2 FAJ 121 1084 Pre-requisites
AMR multi mode low rate FAJ 121 1381 Optional
Conversational RAB for multi-
FAJ 121 985 Optional
mode AMR Speech

Table above is an example for an specific market – Mandatory features are the bare minimum for the feature to work,
together with the pre-requisites. Some features (like FAJ 121 1066) can be needed depending of the specific bearers
the customer has implemented over the network
Refer to feature description for additional details

AMR WB Lessons Learned | 2017-12-05 | Page 6

AMR-WB RAB combination map
Quick Tip:
FAJ 121 1137 is required for
EUL + AMR WB support

The Basic UMTS RAN AMR WB feature is FAJ 121 1059. However, this one only support voice, so
in all cases on which there is data RAB ongoing, the communication will not be supported. So, even
on trials, it is recommended to add at least some basic Speech+PS interactive support.
The activated RNC customer RAB combinations can serve as reference

AMR WB Lessons Learned | 2017-12-05 | Page 7

Implementation tips - general

In order to make a AMR HD call, three components are needed:

- Feature Support across all involved elements
- UE Support
- Consistency between the activated features and the parameters

In mobile to mobile calls, both handsets report their codec capabilities to the MSC servers involved in the
call as part of the signaling before the bearer path is established. Thus, an AMR-WB codec is
automatically used if supported by both terminals. But the MSC server needs to know also the supported
RNC codecs and that information is taken from an specific RNC table. Therefore, this RNC table has to be
updated with the correct codec support information, otherwise the Core part will take incorrect decisions.
AMR WB Lessons Learned | 2017-12-05 | Page 8
Implementation tips - 1
Typical MOPs procedures involves the following steps:

• Enable the minimum required features on the Core Side. An example of minimum requirements can
be found on slide 4
• Activate RNC related features. This will depend of the defined RAB combinations, as discussed
before.
• At this stage, the AMR WB still is NOT activated

• Before a AMR WB call can be possible, the MSC needs to have available the corresponding HD code
on the supported list. See table below (Set 0 codec parameters needs to be updated by the Core
specialist)

AMR WB Lessons Learned | 2017-12-05 | Page 9

Implementation tips - 2
• The final step involves updating the RNC codec table (RAN side). This is needed because the
MSC uses that table as reference to know the available codecs to configure the call. Without
updating the RNC codec table, the activated RAB AMR WB features will not have any effect

Quick Tip:
Usually it is only needed to
remove the AMR-WB_SET0
from the RNC table in order
to make a roll-back for AMR

• On the Right hand side it is displayed a typical print-out

of an updated RNC table with the UMTS_AMR_WB
codec included. After this step in completed, the MSC
will assume that HD support is available on the RNC,
so it will try to configure AMR WB RABs if possible

• This means that if at this stage the corresponding

RAB combinations are not active on the RNC, we
will experiment call-fails across the whole RNC
-> Be sure that the RAN features and RAB
combinations are active before updating the RNC
Codec Table!!
AMR WB Lessons Learned | 2017-12-05 | Page 10
summary

AMR WB Lessons Learned | 2017-12-05 | Page 11

Related parameters and activation
› On the RAN side, activation of the corresponding features and RAB combinations is needed. This basically
means that RAB combinations from rabcombination040 up to rabcombination048 should be set to feature
state 1

– Internal RAB parameters can be changed to be consistent with actual network configuration (such as
service offsets and BLER settings) but is not mandatory

› For AMR-WB control, only two more parameters are present. Those only control the maximum WB rate to be
used on DL/UL and cannot be used to disable/enable the WB codecs on cell level

AMR WB Lessons Learned | 2017-12-05 | Page 12

ADDITIONAL ISSUES
› User Equipment – Terminal compatibility

– There are terminals (UE) which report AMR-WB, but actually do not support it. Calls are not dropped
if phones are reporting AMR-WB support in the DTAP message. One of the things that can happen is
that the calls get silent and then the subscriber terminates the call.

– This issue can be solved by deploying the RPC Enhanced User Equipment capability analysis for
AMR and AMR-WB MSC-S feature:

– Enhanced User Equipment capability analysis for AMR, FAJ 121 0850/3 [release ≥ MSC-S 13A]

– There are currently several rather old terminals identified having this problem. Quantifying them is
ongoing.

AMR WB Lessons Learned | 2017-12-05 | Page 13

conclusions
› HD Voice is a E2E process: if one stage does not work properly, the whole functionality will
not work.
– Core (MSC) support
– MGW support
– Transport compatibility
– RAN Support
– UE Support
› There are several features involved on the solution, but not all are needed on all scenarios. A
preliminary audit is always recommended in order to customize the solution to the specific
customer condition
› This functionality requires to change/adjust some parameters which, if not properly set, will
have a big impact over the network. It is important to check and double check the solution
and be sure the MOP specifies the correct order of implementation and the requirements for
each involved stage / element

AMR WB Lessons Learned | 2017-12-05 | Page 14

AMR WB Lessons Learned | 2017-12-05 | Page 15