LTE attach request with GUTI x IMSI

Hi Experts, how are you all?

I have faced an issue I’d need your help. About LTE attach request with GUTI x IMSI.

An industrial device is trying to attach our 4G network with GUTI, and Core rejects.

IMSI never shows up in the logs.

Two things I don’t understand:

  1. Why does the device choose GUTI instead of IMSI, even in the first access (after a device reset)?

  2. When CORE gets the request, it just rejects. Doesn’t it have to ask for IMSI once the GUTI is unknown?

I guess our CORE doesn’t use GUTI.

SimCard is correct and working on phones or CPEs.

Hi dear
What is the exact reject message and code?
The industrial device is 3gpp or non 3gpp?

Typically, after the initial attach procedure, the network assigns a GUTI to the device.

The device will use this GUTI for subsequent attach requests to avoid frequently transmitting the IMSI.

(The GUTI assigned to the device might have expired or there might be a synchronization issue between the device’s stored GUTI and the core network’s record, causing the core to not recognize the GUTI).

But you are saying that your MME does not support GUTI based attach.

What is the rejection cause code?

Other options:

  • Use other devices or different types of SIM cards to see if the issue is specific to a particular device or SIM card.
  • Verify Core Network Configuration:
    • Check the configuration and policies in the core network (MME) related to handling GUTI and IMSI.
    • Ensure that the core network is set to request IMSI if the GUTI is not recognized.
1 Like

Thank you dears.

I agree with you about typical procedure.

What I got from CORE guys is that MME shows Rejection Cause Code 17 - Network Failure.

I agree that if GUTI is unknown, it should challenge the simCard asking for IMSI, but it seems our CORE hasn’t done it.

Network failure seems issue with NAS signalling mostly MME is unable to handle because of GUTI to MME mapping is not there?

Meanwhile if you have any other UE and different SIM it would confirm the issue.

One other thing we observed:

When logging S1AP msgs at BTS we can see the Attach request using GUTI, but TMSI fild comes all whith zeros (000000000).

Great, this seems the root cause.

It seems UE might detected that its GUTI is no longer valid (e.g., due to timeout or moving to a new tracking area where the GUTI is not recognized).

Consequently, it sends an all-zeros M-TMSI as a placeholder.

If device detects its GUTI is no longer valid, why not go with IMSI?

Good question.

But it’s bit tricky to confirm its MME issue or UE…

As per my understanding ,Rejection Cause Codes: Ensure that MME sends a specific rejection cause code (e.g., “GUTI not valid”) that prompts the UE to fallback to IMSI.