Deregistration is the 5GMM procedure used to remove the UE registration from the 5G system for one or more access types. It can be initiated by the UE or by the network. A common UE-initiated case is switch-off, where the UE informs the network that it is leaving 3GPP access and the network can release the corresponding UE context.

In a log, this procedure is usually the last NAS message of a session, and it is short. But its single De-registration type IE carries three different pieces of information, and its meaning depends on the direction. So it is worth reading carefully, especially when the network starts it.

• Why we need Deregistration ?
• Signaling Sequence
  • UE-initiated Normal De-registration
  • Network-initiated De-registration
• De-registration Type
• Message Structure
  • Message Types and Contents
  • Example : Deregistration Request
• Reference

Why we need Deregistration ?

Why should a UE bother to tell the network that it is leaving ? If the UE just disappears, the AMF still keeps its context. It thinks the UE is reachable, so it may page the UE for incoming data and wait for an answer that never comes. The SMF also keeps the PDU sessions and their user plane resources. Deregistration lets both sides clean this up at once.

The network has its own reasons to start the procedure. It may need to remove the UE from 5GS services, for example after the subscription changes, after a network slice authorization fails, or because of CAG restrictions. Sometimes the network only wants the UE to start over, and then it asks the UE to register again.

Whichever side starts it, deregistration ends with a local release of the PDU sessions over the indicated access. No PDU SESSION RELEASE messages are needed for this. Both the UE and the SMF release the sessions on their own.

• A silent UE wastes network resources : the AMF would keep paging, and the SMF would keep the PDU sessions.
• Both sides can start it : the UE when it switches off or leaves an access, and the network when the UE must leave or must register again.
• PDU sessions are released locally : deregistration does not need a separate 5GSM release for each session.
• It works per access type : a UE registered over both 3GPP and non-3GPP access can leave one and stay on the other.

Signaling Sequence

The exact sequence depends on whether the UE or the network initiates the procedure and whether the UE is switching off. The following table shows a UE-originated switch-off case.

Why does the switch-off case have no accept ? The UE is about to power down, so it cannot wait for an answer. 24.501 lets the UE try for 5 seconds to send the request, and it may switch off as soon as the request is sent. On the network side, the procedure is complete when the AMF receives the request, and the AMF sends no DEREGISTRATION ACCEPT.

UE-initiated Normal De-registration

When the UE is not switching off, for example when it leaves only one access type, it does wait for an answer. This is the case where a timer appears on the UE side. T3521 is 15 seconds in normal NR access.

If the accept does not come, the UE retransmits the request on each of the first four expiries of T3521. On the fifth expiry it aborts the procedure and enters 5GMM-DEREGISTERED anyway. The UE does not stay registered just because the network did not answer.

Network-initiated De-registration

Now the roles are reversed. The AMF sends the request, starts T3522, and waits for the UE to accept. The interesting part is the last row, because the De-registration type can ask the UE to register again right away.

T3522 is 6 seconds. On each of the first four expiries the AMF retransmits the request, and on the fifth it aborts the procedure and treats the UE as deregistered for that access. So both timers end the same way. After enough retries, the sender considers the UE deregistered without an answer.

The 5GMM cause tells the UE why it was removed. For example, #62 No network slices available is used when network slice-specific authentication fails or is revoked, and #76 is used for CAG restrictions. When the AMF only deregisters the UE locally, it sends nothing at this point. The UE learns about it later, through a reject with cause #10 implicitly de-registered, when it starts its next 5GMM procedure.

• Switch-off has no accept and no timer : the procedure ends when the AMF receives the request.
• T3521 guards the UE request, T3522 the network request : 15 seconds and 6 seconds, each with four retransmissions.
• Re-registration required means start again : the UE accepts the deregistration and then performs a new initial registration.
• A local de-registration is invisible at first : the UE only finds out through cause #10 in a later reject.

De-registration Type

The De-registration type IE is only half an octet, but it carries three things. Then you may ask how four bits are enough. The answer is that one of the bits means something only in the uplink, and another one only in the downlink. So the same bit position has to be read with the direction in mind.

Let's decode the value from the example below, 0x9. In binary it is 1001. Bit 4 is 1, so this is a switch off. Bit 3 is 0, which is the spare bit in the uplink. Bits 2 and 1 are 01, which is 3GPP access. So the UE is switching off and leaving 3GPP access.

• Read bit 4 only in an uplink request : the network never sends switch off.
• Read bit 3 only in a downlink request : only the network can ask for re-registration.
• The access type is in both directions : it says which registration is being removed.

Message Structure

The deregistration request contains the deregistration type, ngKSI and 5GS mobile identity. The deregistration type tells whether the procedure is for normal deregistration or switch-off and whether it applies to 3GPP access, non-3GPP access, or both.

Message Types and Contents

There are four de-registration messages, not two, because 24.501 defines a separate request and accept for each direction. The message type byte tells you which one you are looking at, as the following table shows.

One thing you would notice is the difference between the two requests. The UE request has to identify the UE, so it carries the 5GS mobile identity, normally the 5G-GUTI. The network request does not need that. Instead it carries the reasons and the restrictions the UE should remember, such as the 5GMM cause and the rejected NSSAI. The NAS message container appears in the UE request only when it is sent from 5GMM-IDLE as an initial NAS message with non-cleartext IEs.

Example : Deregistration Request

The following example is based on an Amarisoft MME log showing a UE-originated switch-off deregistration. The whole decoded NAS message is shown below. Check the De-registration type first, because it decides whether an accept should follow.

Decoded NAS message from an Amarisoft log. Field values are from a live capture, not from the specification.

04:10:00.930 [NAS] UL 0065 5GMM: Deregistration request
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x2 (Integrity protected and ciphered)
        Auth code = 0xcb40f253
        Sequence number = 0x07
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x0 (Plain 5GS NAS message, not security protected)
        Message type = 0x45 (Deregistration request)
        Deregistration type = 0x9 (Switch off=1, Access type=3GPP access)
        ngKSI:
          TSC = 0
          NAS key set identifier = 3
        5GS mobile identity:
          5G-GUTI
            MCC = 001
            MNC = 01 
            AMF Region ID = 128
            AMF Set ID = 4
            AMF Pointer = 1
            5G-TMSI = 0x6e8f8c2c

There are a couple of points that I want you to notice here. The message type is 0x45, the UE originating request. The De-registration type 0x9 is a switch off over 3GPP access, as decoded above. So no DEREGISTRATION ACCEPT follows in the log. The UE identifies itself with its 5G-GUTI, and the request is integrity protected and ciphered with the current NAS security context, ngKSI 3.

This log also shows what happened just before. The PDU session release examples come from the same log and the same UE, 0065, and the release completed at 04:10:00.721. So in this capture the UE released its PDU session explicitly about 0.2 seconds before switching off. That release was not strictly needed. The deregistration alone would have released the session locally.

• 0x45 with switch off means no answer : the absence of an accept in the log is correct behavior.
• The 5G-GUTI identifies the UE : a UE without a valid 5G-GUTI would use its SUCI instead.
• The request is fully protected : the UE was still in connected mode with an active security context.

Reference

The procedure, the timers, the De-registration type coding and the message contents on this page were checked against 24.501.

• 24.501 : Non-Access-Stratum (NAS) protocol for 5G System (5GS). The de-registration procedure in clause 5.5.2, the message contents in clauses 8.2.12 to 8.2.15, the De-registration type IE in clause 9.11.3.20, the message types in Table 9.7.1 and the T3521 and T3522 timer tables. The version read was v20.1.0 (Release 20).
• Registration and PDU Session Establishment : the procedures that deregistration reverses.