Location area update reject

[roots]

Dears

Some cells in the network are experiencing intensive location update ( those cells are not LAC border)
and the main cause of this reject is due to the following :

1/reject-cause:location-area-not-allowed (12)
2/reject-cause plmn-not-allowed (11)

Can Anybody tell me what parameters could be wrongly set in the Core side ?

BSS part=Huawei
Core part=Huawei

Thx
roots

[kaizzer545]

I hava been analyzing at the same (Vendor BSS & CORE) instead check location update reject; you should check at fist location update request and try to match events with location update reject. In case of location update equest you can see MNC+IMSI, so if there are so much MNC that are not of your network maybe could be by emergency call or something like that, but anyway these request are consume signaling resources (traffic sources not because these request are reject).

You can check at the same 3GPP to understand some parameters

BR

[scorpion]

Is there is any analysis about what happens after the LU Reject ?
How the MS behaves based on various LU Reject causes ?

Regards

[klystron]

This info might be a little bit related.

I am also investigating this LU rejections. For visiting subscribers, the MS will try to make 4 LU request (all are rejected with NETWORK FAILURE) before making another LU request to another operator. Usually this happens for roaming partners using traffic steering (also called steering of roaming).

[agenov]

Is there is any analysis about what happens after the LU Reject ?
How the MS behaves based on various LU Reject causes ?

Regards

Will search for another PLMN that is not forbidden until perform sucessfull registration.

[luganomu]

Can Anybody tell me what parameters could be wrongly set in the Core side ?

BSS part=Huawei
Core part=Huawei




With regard to above question the parameter are t3212( period of periodic location update) on BSS and implicit detach(MSC check time) on core

[leelio]

as Luganomu explained earlier, i think you need to check imsi attach and detach timer on switch part and t3212 (periodic update ms) on bss side it seems the switch timer is less than bss

[klystron]

Can Anybody tell me what parameters could be wrongly set in the Core side ?

BSS part=Huawei
Core part=Huawei




With regard to above question the parameter are t3212( period of periodic location update) on BSS and implicit detach(MSC check time) on core

I am not a Huawei core engineer but the principle is that there should be an analysis for the IMSI of the subscriber reach their HLR. The IMSI range/series should be defined in the core side. If this is not defined, PLMN not allowed is sent to the BSS side. Hope this helps

[kaizzer545]

Dears: in my case with LU reject, there is visible the IMSI so you can see wich MNC have it and see wich operator does it correspond.

And as I said it before you can check 3GPP to see specific behaivour . I mean in 3GPP at some part it says that if MS don't atach to correct network it have to be storaged in SIM card as NO valid operator .. something like that

-------------------------------


# 11: (PLMN not allowed);
The mobile station shall delete any LAI, TMSI and ciphering key sequence number stored in the SIM/USIM, reset the attempt counter, set the update status to ROAMING NOT ALLOWED (and store it in the SIM/USIM according to subclause 4.1.2.2). The mobile station shall store the PLMN identity in the "forbidden PLMN list".
The MS shall perform a PLMN selection when back to the MM IDLE state according to 3GPP TS 23.122 [14].

[telecom.santosh]

provide some not if u have..