UE Context Release Causes Missing AMF Context and Paging Errors

[thomas-hoger]

Description:

After triggering a UE Context Release from the gNB (NG-RAN initiated), we observe that the UE context is removed as expected. However, when the UE attempts to re-establish its connection—either via a service request or through paging—the system fails to re-select a valid AMF. This results in errors such as:

• "AMF selection for UE[1] failed. Could not find a suitable AMF."
• "AMF context not found with id: 0"

It appears that the AMF context is deleted during the release procedure, but subsequent paging messages do not trigger a proper re-creation of the UE context with a valid AMF ID.

Steps to Reproduce:

1. Start UERANSIM and free5gc
2. The UE registers successfully and establishes RRC connection and PDU sessions.
3. Initiate a UE Context Release from the gNB side (NG-RAN node initiated).
4. The gNB sends a UE Context Release Request.
5. The AMF responds with a UE Context Release Command.
6. The RRC connection is released.
7. Shortly after, the UE attempts to re-establish its connection (via RRC Setup and service request).
8. Errors appear indicating that the AMF selection has failed and the AMF context is missing (AMF context id: 0).

gNB/UERANSIM Logs:

UERANSIM v3.2.7
[2025-03-06 11:08:31.957] [sctp] [info] Trying to establish SCTP connection... (10.100.200.16:38412)
[2025-03-06 11:08:31.960] [sctp] [info] SCTP connection established (10.100.200.16:38412)
[2025-03-06 11:08:31.960] [sctp] [debug] SCTP association setup ascId[29]
[2025-03-06 11:08:31.960] [ngap] [debug] Sending NG Setup Request
[2025-03-06 11:08:31.962] [ngap] [debug] NG Setup Response received
[2025-03-06 11:08:31.962] [ngap] [info] NG Setup procedure is successful
[2025-03-06 11:09:09.346] [rrc] [debug] UE[1] new signal detected
[2025-03-06 11:09:09.347] [rrc] [info] RRC Setup for UE[1]
[2025-03-06 11:09:09.347] [ngap] [debug] Initial NAS message received from UE[1]
[2025-03-06 11:09:09.484] [ngap] [debug] Initial Context Setup Request received
[2025-03-06 11:09:09.795] [ngap] [info] PDU session resource(s) setup for UE[1] count[1]
[2025-03-06 11:09:09.849] [ngap] [info] PDU session resource(s) setup for UE[1] count[1]
[2025-03-06 11:09:13.591] [ngap] [debug] Sending UE Context release request (NG-RAN node initiated)
[2025-03-06 11:09:13.623] [ngap] [debug] UE Context Release Command received
[2025-03-06 11:09:13.623] [rrc] [info] Releasing RRC connection for UE[1]
[2025-03-06 11:09:31.363] [rrc] [info] RRC Setup for UE[1]
[2025-03-06 11:09:31.363] [ngap] [debug] Initial NAS message received from UE[1]
[2025-03-06 11:09:31.363] [ngap] [error] AMF selection for UE[1] failed. Could not find a suitable AMF.
[2025-03-06 11:09:31.363] [ngap] [error] AMF context not found with id: 0
[2025-03-06 11:09:32.407] [ngap] [debug] Paging received
[2025-03-06 11:09:38.408] [ngap] [debug] Paging received
[2025-03-06 11:09:44.413] [ngap] [debug] Paging received
[2025-03-06 11:09:50.409] [ngap] [debug] Paging received
[2025-03-06 11:09:50.409] [ngap] [error] AMF context not found with id: 0
[2025-03-06 11:09:56.413] [ngap] [debug] Paging received
[2025-03-06 11:10:06.971] [rrc] [debug] UE[2] new signal detected
[2025-03-06 11:10:08.773] [rls] [debug] UE[1] signal lost`

UE Logs:

UERANSIM v3.2.7
UERANSIM v3.2.7
[2025-03-06 11:09:09.346] [nas] [info] UE switches to state [MM-DEREGISTERED/PLMN-SEARCH]
[2025-03-06 11:09:09.346] [rrc] [debug] New signal detected for cell[1], total [1] cells in coverage
[2025-03-06 11:09:09.347] [nas] [info] Selected plmn[208/93]
[2025-03-06 11:09:09.347] [rrc] [info] Selected cell plmn[208/93] tac[1] category[SUITABLE]
[2025-03-06 11:09:09.347] [nas] [info] UE switches to state [MM-DEREGISTERED/PS]
[2025-03-06 11:09:09.347] [nas] [info] UE switches to state [MM-DEREGISTERED/NORMAL-SERVICE]
[2025-03-06 11:09:09.347] [nas] [debug] Initial registration required due to [MM-DEREG-NORMAL-SERVICE]
[2025-03-06 11:09:09.347] [nas] [debug] UAC access attempt is allowed for identity[0], category[MO_sig]
[2025-03-06 11:09:09.347] [nas] [debug] Sending Initial Registration
[2025-03-06 11:09:09.347] [nas] [info] UE switches to state [MM-REGISTER-INITIATED]
[2025-03-06 11:09:09.347] [rrc] [debug] Sending RRC Setup Request
[2025-03-06 11:09:09.347] [rrc] [info] RRC connection established
[2025-03-06 11:09:09.347] [rrc] [info] UE switches to state [RRC-CONNECTED]
[2025-03-06 11:09:09.347] [nas] [info] UE switches to state [CM-CONNECTED]
[2025-03-06 11:09:09.378] [nas] [debug] Authentication Request received
[2025-03-06 11:09:09.378] [nas] [debug] Received SQN [000000000045]
[2025-03-06 11:09:09.378] [nas] [debug] SQN-MS [000000000000]
[2025-03-06 11:09:09.391] [nas] [debug] Security Mode Command received
[2025-03-06 11:09:09.391] [nas] [debug] Selected integrity[2] ciphering[0]
[2025-03-06 11:09:09.484] [nas] [debug] Registration accept received
[2025-03-06 11:09:09.484] [nas] [info] UE switches to state [MM-REGISTERED/NORMAL-SERVICE]
[2025-03-06 11:09:09.484] [nas] [debug] Sending Registration Complete
[2025-03-06 11:09:09.484] [nas] [info] Initial Registration is successful
[2025-03-06 11:09:09.484] [nas] [debug] Sending PDU Session Establishment Request
[2025-03-06 11:09:09.484] [nas] [debug] UAC access attempt is allowed for identity[0], category[MO_sig]
[2025-03-06 11:09:09.484] [nas] [debug] Sending PDU Session Establishment Request
[2025-03-06 11:09:09.484] [nas] [debug] UAC access attempt is allowed for identity[0], category[MO_sig]
[2025-03-06 11:09:09.686] [nas] [debug] Configuration Update Command received
[2025-03-06 11:09:09.795] [nas] [debug] PDU Session Establishment Accept received
[2025-03-06 11:09:09.795] [nas] [info] PDU Session establishment is successful PSI[1]
[2025-03-06 11:09:09.803] [app] [info] Connection setup for PDU session[1] is successful, TUN interface[uesimtun0, 10.60.0.1] is up.
[2025-03-06 11:09:09.849] [nas] [debug] PDU Session Establishment Accept received
[2025-03-06 11:09:09.849] [nas] [info] PDU Session establishment is successful PSI[2]
[2025-03-06 11:09:09.855] [app] [info] Connection setup for PDU session[2] is successful, TUN interface[uesimtun1, 10.61.0.1] is up.
[2025-03-06 11:09:13.623] [rrc] [debug] RRC Release received
[2025-03-06 11:09:13.623] [nas] [info] UE switches to state [CM-IDLE]
[2025-03-06 11:09:31.363] [nas] [debug] Uplink data status changed PSI[1] pending[true]
[2025-03-06 11:09:31.363] [nas] [debug] Service request required due to [IDLE-UPLINK-DATA-PENDING]
[2025-03-06 11:09:31.363] [nas] [debug] UAC access attempt is allowed for identity[0], category[MO_data]
[2025-03-06 11:09:31.363] [nas] [debug] Sending Service Request due to [IDLE-UPLINK-DATA-PENDING]
[2025-03-06 11:09:31.363] [nas] [info] UE switches to state [MM-SERVICE-REQUEST-INITIATED]
[2025-03-06 11:09:31.363] [rrc] [debug] Sending RRC Setup Request
[2025-03-06 11:09:31.363] [rrc] [info] RRC connection established
[2025-03-06 11:09:31.363] [rrc] [info] UE switches to state [RRC-CONNECTED]
[2025-03-06 11:09:31.363] [nas] [info] UE switches to state [CM-CONNECTED]
[2025-03-06 11:09:32.394] [nas] [debug] Uplink data status changed PSI[1] pending[false]
[2025-03-06 11:09:32.407] [nas] [debug] Ignoring received Paging, another procedure already initiated
[2025-03-06 11:09:38.408] [nas] [debug] Ignoring received Paging, another procedure already initiated
[2025-03-06 11:09:44.413] [nas] [debug] Ignoring received Paging, another procedure already initiated
[2025-03-06 11:09:46.383] [nas] [debug] NAS timer[3517] expired [1]
[2025-03-06 11:09:46.383] [nas] [info] UE switches to state [MM-REGISTERED/PS]
[2025-03-06 11:09:46.383] [nas] [info] UE switches to state [MM-REGISTERED/NORMAL-SERVICE]
[2025-03-06 11:09:50.409] [nas] [debug] Responding to received Paging
[2025-03-06 11:09:50.409] [nas] [debug] Mobility registration updating required due to [PAGING-OR-NOTIFICATION]
[2025-03-06 11:09:50.409] [nas] [debug] Sending Mobility Registration with update cause [PAGING-OR-NOTIFICATION]
[2025-03-06 11:09:50.409] [nas] [info] UE switches to state [MM-REGISTER-INITIATED]
[2025-03-06 11:09:56.413] [nas] [debug] Ignoring received Paging, another procedure already initiated
[2025-03-06 11:10:06.403] [nas] [debug] NAS timer[3510] expired [1]
[2025-03-06 11:10:06.403] [nas] [info] Performing local release of NAS connection
[2025-03-06 11:10:06.403] [nas] [info] UE switches to state [MM-REGISTERED/NORMAL-SERVICE]
[2025-03-06 11:10:06.403] [rrc] [info] UE switches to state [RRC-IDLE]
[2025-03-06 11:10:06.403] [nas] [info] UE switches to state [CM-IDLE]

Expected Behavior:

After a proper UE Context Release, both the gNB and AMF should clear the UE context. When the UE re-establishes its connection (via service request or paging), a new context must be created with a valid AMF selection. The AMF context should be available, allowing the re-establishment of the connection without errors.

Request:

Please investigate the handling of the UE context release and re-establishment procedures. It seems that after a context release, the AMF context is not being recreated or re-selected correctly, resulting in paging errors and failed service requests.

Any assistance or pointers toward a fix would be greatly appreciated.

[thomas-hoger]

I’ve dug into the issue and found the root cause. After a context-release, the function extractSliceInfoAndModifyPdu returns -1. This value is then used as the requestedSliceType when calling selectAmf during the creation of a new UE context. Since there’s no slice defined with type -1, the gNB cannot find an AMF and fails to recreate the session.

For my use case (where I only need a single slice), I implemented a temporary fix by hardcoding requestedSliceType to 1 in the function handleInitialNasTransport:

void NgapTask::handleInitialNasTransport(int ueId, OctetString &nasPdu, int64_t rrcEstablishmentCause,
                                         const std::optional<GutiMobileIdentity> &sTmsi)
{
    // int32_t requestedSliceType = extractSliceInfoAndModifyPdu(nasPdu);
    int32_t requestedSliceType = 1;
    // ... rest of the function
}

This workaround forces the use of slice type 1, which is acceptable for my scenario. However, the proper fix would be to modify the extractSliceInfoAndModifyPdu function so that it returns a valid default slice type (e.g., 1) instead of -1 after a context-release.

[kiemtcb]

Hello,

Sorry, this is a bit off-topic, but could I ask you about the time it takes when you release a PDU session on the UE using nr-cli? Specifically, how long does it take from the moment the command is received until the PDU session is re-established?

In my case, it takes 20 seconds to complete.

My environment:

UERANSIM v3.2.7
Free5GC v4.0.0

[yaoyao-zhang666]

I’ve dug into the issue and found the root cause. After a context-release, the function extractSliceInfoAndModifyPdu returns -1. This value is then used as the requestedSliceType when calling selectAmf during the creation of a new UE context. Since there’s no slice defined with type -1, the gNB cannot find an AMF and fails to recreate the session.

For my use case (where I only need a single slice), I implemented a temporary fix by hardcoding requestedSliceType to 1 in the function handleInitialNasTransport:

void NgapTask::handleInitialNasTransport(int ueId, OctetString &nasPdu, int64_t rrcEstablishmentCause,
                                         const std::optional<GutiMobileIdentity> &sTmsi)
{
    // int32_t requestedSliceType = extractSliceInfoAndModifyPdu(nasPdu);
    int32_t requestedSliceType = 1;
    // ... rest of the function
}

This workaround forces the use of slice type 1, which is acceptable for my scenario. However, the proper fix would be to modify the extractSliceInfoAndModifyPdu function so that it returns a valid default slice type (e.g., 1) instead of -1 after a context-release.

hello,I met the same question,I understand your solution ,but I want to know how you activate paging from core network,and do you know how to stop UE from initiating data requests autonomously when in idle state? Only when the core network initiates paging is an RRC connect request initiated.
I would be very grateful if you could provide some help with what you know！

[thomas-hoger]

I want to know how you activate paging from core network

To trigger paging I send a ping from the UPF to the UE IP address through the upfgtp interface in free5GC.
I verified and it doesn't produce the same outcome as pinging the data network through the UE.

Logs from UERANSIM when the UPF pings the UE

[2025-06-16 09:21:01.539] [nas] [debug] Service request required due to [IDLE-PAGING]
[2025-06-16 09:21:01.539] [nas] [debug] UAC access attempt is allowed for identity[0], category[MT_acc]
[2025-06-16 09:21:01.539] [nas] [debug] Sending Service Request due to [IDLE-PAGING]
[2025-06-16 09:21:01.539] [nas] [info] UE switches to state [MM-SERVICE-REQUEST-INITIATED]
[2025-06-16 09:21:01.539] [rrc] [debug] Sending RRC Setup Request
[2025-06-16 09:21:01.539] [rrc] [info] RRC connection established
[2025-06-16 09:21:01.539] [rrc] [info] UE switches to state [RRC-CONNECTED]
[2025-06-16 09:21:01.539] [nas] [info] UE switches to state [CM-CONNECTED]
[2025-06-16 09:21:01.541] [nas] [info] Service Accept received
[2025-06-16 09:21:01.541] [nas] [info] UE switches to state [MM-REGISTERED/PS]
[2025-06-16 09:21:01.541] [nas] [info] UE switches to state [MM-REGISTERED/NORMAL-SERVICE]

Logs from UERANSIM when the UE pings the DN

[2025-06-16 09:23:34.176] [nas] [debug] Uplink data status changed PSI[1] pending[true]
[2025-06-16 09:23:34.176] [nas] [debug] Service request required due to [IDLE-UPLINK-DATA-PENDING]
[2025-06-16 09:23:34.176] [nas] [debug] UAC access attempt is allowed for identity[0], category[MO_data]
[2025-06-16 09:23:34.176] [nas] [debug] Sending Service Request due to [IDLE-UPLINK-DATA-PENDING]
[2025-06-16 09:23:34.176] [nas] [info] UE switches to state [MM-SERVICE-REQUEST-INITIATED]
[2025-06-16 09:23:34.176] [rrc] [debug] Sending RRC Setup Request
[2025-06-16 09:23:34.176] [rrc] [info] RRC connection established
[2025-06-16 09:23:34.176] [rrc] [info] UE switches to state [RRC-CONNECTED]
[2025-06-16 09:23:34.176] [nas] [info] UE switches to state [CM-CONNECTED]
[2025-06-16 09:23:34.184] [nas] [info] Service Accept received
[2025-06-16 09:23:34.184] [nas] [info] UE switches to state [MM-REGISTERED/PS]
[2025-06-16 09:23:34.184] [nas] [info] UE switches to state [MM-REGISTERED/NORMAL-SERVICE]
[2025-06-16 09:23:35.182] [nas] [debug] Uplink data status changed PSI[1] pending[false]

---

how to stop UE from initiating data requests autonomously when in idle state

I encountered the same issue. By default, UERANSIM enables IPv6, which causes the UE to send Neighbor Solicitation and Neighbor Advertisement messages. These are part of the IPv6 Neighbor Discovery Protocol which, as I understand it, resemble DHCP. The UE sends those packets automatically to discover its neighbors and because it sends data it also tries to wake up.

In my setup I use free5gc-compose which allow to run both free5gc and ueransim as dockers.
To fix the auto waking issue I forked free5gc-compose and disabled ipv6 in the docker-compose config :

sysctls:
      - net.ipv6.conf.all.disable_ipv6=1

You can find the exact docker-compose I use here https://github.com/thomas-hoger/free5gc-compose/blob/87609bd25bd6ec570a126742e40284988d224af7/docker-compose.yaml#L344

[yaoyao-zhang666]

谢谢，已收到