Hi Experts.
One query related to VoLTE Huawei.
How will UE shift its codec from EVS to AMR and AMR to EVS?
Any parameter setting, condition or anything else?
VoLTE rate control feature helps in controlling the codecs between AMR only or EVS only?
Need to know the controlling factors of EVS to AMR and AMR to EVS codec shifting.
The controlling factors should be the radio conditions.
When this feature is activated, the eNodeB monitors radio network conditions, and periodically sends optimal uplink physical bit rate to the UEs which support RAN-assisted codec adaptation specified in 3GPP Release 14.
In poor radio conditions, a lower bit rate is recommended, and if it is accepted by the UE, the lower codec rate results in fewer dropped packets through the call.
In good radio conditions higher codec rate is proposed, and the UE adapts to the recommendation, if this is supported.
Using higher bit rates improves speech quality.
Yes. That’s already understood that radio conditions are changing the codec, but asking the specific parameter or algorithm from which its happening in Huawei.
EVS to AMR and AMR to EVS.
Is it changing during the call or at the beginning only during codec negotiation?
There is a codec change in UL only in Huawei vendor.
Basically handsets connected on EVS codecs and they are not following the rate negotiation during call.
If any codec negotiated at the start of the call, UE will remain on same codec.
Even tough, EVS rate control complete feature implemented along with license, its not working.
But for AMR NB and WB its working fine.
Yes, how it will communicate to come down from EVS to AMR?
Main issue is that rate negotiation is not happening for EVS during the call and Call is not shifting from EVS to AMR codec.
Just wanted to know how can we check controlling parameter.
In my opinions codec is not possible to change during the call.
It is always negotiated at the start of the call.
Only rate recommendation is done through feature from RAN side and can be changed during the call but within the same codec.
Its changes and UE measurement for codec changes at VoLTE as well and device also to support to up / down.
It allows to have HD VoLTE speech codec, and classified into EVS narrowband, EVS wideband, EVS superwideband, and EVS fullband. Either 5.9 or 13.2 or 16.4 kbps [Amr does 12.2 to 5.9]
Based on Radio condition, eNB transparent to signalling.
After all, it is EVS with just the rate changing? Is’n’t it?
Yes, correct.
Conclusion is there is a codec change with in EVS rate and there may not be a codec change b/w EVS and AMR.Am I right?.
Within EVS Rate change happens in NR in 5GC take control. LTE has AMR to EVS or codec change also
there is other question if the UE(A) has EVS , and UE(B) doesn’t support the EVS or doesn’t agree for EVS negociation , what will be the situation?
Yes. Thinking of codec change from EVS to AMR is illogical as EVS is more robust compared to AMR under same radio conditions.
E2E volte calls are either on EVS or AMR. The type of codec is negotiated only once during call setup. This is done in two steps. In the first step the caller includes information about supported codecs in the SIP INVITE message. At the end of this message all supported codecs are enlisted. The callee selects one of the codecs and informs the caller about the chosen codec in a 183 SESSION PROGRESS message. So codec type is selected at this phase ensuring both UEs support the same codec.
So pls share how to know that UE support EVS or not ? Can we see in UE capabilities ?
CodecchangesbetweenEVSandAMRareillogicalbecauseEVS is more robustthanAMR underthesame radio conditions.
ok .This is how it is happening.Modern day VoNR capable handsets sends EVS 16k as the first codec in SDP offer.In other words prefered codec.Slightly older devices volte only devices sends prefered Codec as AMRWB.I respective of which code UE sends it is completely up to IMS to decide which codec network is going to impliment between A and B parties.Lets take an example VoNR capable handset making a call to a Volte handset.PCSCF receives the initial invite with SDP offer as EVS 16 k at this stage PCSCF dont know what is the B party so what usually does happen is PCSCF select the GBR dedicated bearer qos which allows that codec to traverse and will setup the dedicated bearer for A party as soon as invite receives without waiting for the sdp offer answer.lets say it sets bit rate as 50kbps .And also PCSCF sets pre condision off telling the receiving party that oroginating leg is no waiting for his preference to setup the bearer.when B party receives invite its prefered codec is amrwb so it sets the bit rate lets say 30kbps for that codec and sends the 183 or 200 ok with SDP offer answer once it receives by A Party PCSCF it have two choices since 30 kbps is smaller than 50kbps .Originating party BGF can decide not to do any change but to do the transcoding .What it means is B party messages coming with AMRWB transcoded to A party EVS 16k vice versa.but this is very MGW resource intensive.Ifnot BGF can decide to run a transcorder free operation(TRFO) in that case it will send a another bearer modification towards PCRF via Rx lowering the bit rate from 50k to 30 literaly forcing handset to drop EVS and take up next best which is AMRWB.SIP signalling related to this can vary some implimentations use update message some use only prack 200 ok with sdp parmaters etc. but the mechanism is the one I mentioned above.This is called Media gating function of SBG.SBG is controlling when the media stream will start by controlling the qos profile.in parallel sip signalling will select the codecs which matches that QOS profile by SBG .
