Monday, 9 November 2015

The case about long CSFB delay due to Core Network

In X network, we verify the CSFB function from LET to UMTS network. According to the standard from X, the test results need to lower than 6S.
  During the test, we found two cases will lead to CSFB delay too long. There are two cases leading to the CSFB problems, the seam phenomenon is CSFB delay too long. One is due to the core network problem, the other one is due to data configuration problem.

    Core network processing problems

The CSFB definition:
We collect key signaling and calculate the time delay between these signaling, the key signaling are “Extended service request Msg”, “WCDMA signaling Messages (first)” and “alerting”, the gap represent the time delay between two signaling.
We define CSFB time delay from the time on “Extended service request Msg” to the “Alerting” time. Shown as following:
    For instance: GAP1 is the time delay from the signaling “Extended service request Msg” to the signaling “WCDMA signaling Messages (first)”, GAP2 is the time delay from the signaling “WCDMA signaling Messages (first)” to the signaling “alerting”, Delay1 is the duration from the signaling “Extended service request Msg” to the signaling “alerting”. The Delay1 is CSFB time delay.
We can see the CSFB time delay is 15.740S from above picture. This duration is intolerable for users, also too much longer than the 6S desired by H.
So we investigate the signaling collected by UE side. We found that before the UE initiates a voice call, the core network is processing a NAS process. See the mark 1 as following.
During this NAS process, UE initiates a voice call, See the mark 2.
But the core network didn’t respond the message, but continue “Modify EPS bearer context request” message. See the mark 3.
The normally signaling procedure should be following signaling. The UE should receive the “RRCConnectionRelease” message from network after service request sanded, but not waiting the “modify EPS bearer context request Msg” from NAS.
On the other hand, UE distinguish the voice call is the highest priority. So both ends (core network and the UE) are waiting for the answer from other side, until the timer expires (T3417ext, default 10s).
The timer expired, and then UE initiates a voice call on 3G side. That’s why the CSFB time delay is so long.
Like such issues, we need communicate with CN (EPS) engineer and confirm the problem-solving mechanism and process, and choose the reasonable procedure for service initial.

Budi Prasetyo

About Budi Prasetyo

All About LTE

Subscribe to this Blog via Email :


Write comments
Rajiv Gupta
25 July 2018 at 05:05 delete

Thanx for that info

Now can you also explain the other issue you told data configuration problem.