Any ideia about this S1 cause: interaction-with-other-procedure?

[Cesar_Nunes]

Hi Experts.
Any ideia about this S1 cause: interaction-with-other-procedure?

[Usman]

What is the scenario/background?

[Vicky]

Yeah, It’s a race condition occurred when Multiple bearer are in progress and its has to be handle by the MME.
If MME doesn’t support multiple erab I’d instance to handle at a time the we usually got this cause code.

Is your network have VoLTE and 5G together?

Also please mention the MME version as well.
Is it Ericsson?

[Saurabh63]

You said multiple bearers, how many default bearers you have seen in your network?

[Cesar_Nunes]

@Vicky

Is your network have VoLTE and 5G together?

Only VoLTE, don’t have 5G yet.

@Vicky

Also please mention the MME version as well.
Is it Ericsson?

MME is NOKIA.

Here is my S1 trace. If someone can help.

S1_Interface_Trace.TXT.zip (8.2 KB)

[ran_core_consultant]

Hi @Cesar_Nunes. There is nothing much in trace.

Think these errors are rare but are inevitable. Huawei has certain features to avoid these but that still doesn’t completely make these zero.

Trace in summary:
[No.] 3297 [Time] 2021-10-24 13:44:40 (511) → this is S1AP Context Req from MME to eNB and only 1 QCI-9 is being requested to be setup
rest of the message is UE Capability
[No.] 3312 [Time] 2021-10-24 13:44:40 (604) → within 93ms S1AP failure from eNB with cause

Did this happen for a specific UE?
Were you taking tracing somewhere else like UE or at eNB UU interface?

[Cesar_Nunes]

No, this trace was in S1, not for an specific UE.

[ran_core_consultant]

Think there are counters to capture these failures and if you compare those with rest, you will find these are very small numbers.
Also relent this failure doesn’t necessarily mean a Service failure (i.e. user impacting) its an internal system error which may not have any adverse consequences.

[Cesar_Nunes]

Ok, thanks. But it’s affecting Accessibility eRAB KPI…its < 98%.

L.E-RAB.FailEst.MME

[Usman]

@Vicky

Yeah, It’s a race condition occurred when Multiple bearer are in progress and its has to be handle by the MME.
If MME doesn’t support multiple erab I’d instance to handle at a time the we usually got this cause code.

From Huawei site:
https://forum.huawei.com/enterprise/en/l-e-rab-failest-mme-s1ap-initial-context-fail-due-to-interaction-with-other-procedure-mtc-call/thread/675357-100305

How Ericsson/Nokia/Samsung are dealing ‘interaction with other procedures’?
Any insights?
Are these reported as normal event in Oss counter?

As interaction with other procedures involves priority of services like in above scenario. That has nothing to do with radio or mme and such releases should be pegged normally.

[Cesar_Nunes]

Sorry, I can´t see the answers in the link you provide.

But I found this in other forum:

"UE is in handover progress, source enb already sent HO preparation require to MME or other enb. During Handover, UE has service request of Csfb mo/mt, and csfb also initiated by mme sent s1ap context setup request. But enb found it conflict with HO procedure, so enb reply with context setup failure due to interaction.
Solution: it has one parameter to prefer csfb during HO. eNodeB will cancel handover, process CSFB.
A cause value “Interaction with other procedure” was introduced and used in the section 8.4.1.2 of the Handover Preparation procedure
Interactions with E-RAB Management procedures:
If, after a HANDOVER REQUIRED message is sent and before the Handover Preparation procedure is terminated, the source eNB receives a MME initiated E-RAB Management procedure on the same UE associated signaling connection, the source eNB shall either:
1.cancel the Handover Preparation procedure by executing the Handover Cancel procedure with an appropriate cause value “Interaction with other procedure”. After successful completion of the Handover Cancel procedure, the source eNB shall continue the MME initiated E-RAB Management procedure.
As per 3GPP, here is the reason of this cause failure.”

[Mustafa_Rawat]

May you please share you DRX Parameter Settings?
Is this issue on all the cells in the Node?
A particular sector?
Or a particular cell?

[Cesar_Nunes]

DRX is OFF.

[mohsinash]

@Cesar_Nunes

But I found this in other forum:

"UE is in handover progress, source enb already sent HO preparation require to MME or other enb. During Handover, UE has service request of Csfb mo/mt, and csfb also initiated by mme sent s1ap context setup request. But enb found it conflict with HO procedure, so enb reply with context setup failure due to interaction.
Solution: it has one parameter to prefer csfb during HO. eNodeB will cancel handover, process CSFB.
A cause value “Interaction with other procedure” was introduced and used in the section 8.4.1.2 of the Handover Preparation procedure
Interactions with E-RAB Management procedures:
If, after a HANDOVER REQUIRED message is sent and before the Handover Preparation procedure is terminated, the source eNB receives a MME initiated E-RAB Management procedure on the same UE associated signaling connection, the source eNB shall either:
1.cancel the Handover Preparation procedure by executing the Handover Cancel procedure with an appropriate cause value “Interaction with other procedure”. After successful completion of the Handover Cancel procedure, the source eNB shall continue the MME initiated E-RAB Management procedure.
As per 3GPP, here is the reason of this cause failure.”

I have already tried this but it didn’t resolve this specific issue.
Is there any way you can find abnormal UEs?
Did you already implement this?

[Cesar_Nunes]

I changed these two parameters…let’s wait and see results.

MOD GLOBALPROCSWITCH:HOPROCCTRLSWITCH=CsfbFlowFirstSwitch-1;
MOD GLOBALPROCSWITCH:HOERABCONFLPROCESSINGSTRAT=ERAB_FLOW_FIRST;

[mohsinash]

@Cesar_Nunes

MOD GLOBALPROCSWITCH:HOERABCONFLPROCESSINGSTRAT=ERAB_FLOW_FIRST;

This 2nd switch will improve your eRAB RNL failures if you have any, but sure do let us know about the results.

[Cesar_Nunes]

I also have problem with RNL. Less than MME.

[mohsinash]

MME failures are high as compared to RNL, yes its same at my side.

[Cesar_Nunes]

Did you change other parameters?

[RFSpecialist]

@mohsinash

MME failures are high as compared to RNL

MME drops can be RF/RNL drops.

Here you have a nice reading:

LTE Call Drop Rate - Our Technology Planet