5GMM Status is a simple error reporting message. Either the UE or the AMF can send it when a 5GMM protocol error is detected and a specific procedure-specific reject message is not the right response. The important field is the 5GMM cause, which tells the peer why the status message was sent.

You will not see this message often in a healthy log. But when you see it, it is one of the most useful messages to look at, because it points directly at the NAS message the other side could not handle.

• Why we need 5GMM Status ?
• Signaling Sequence
• When is 5GMM Status sent ?
• Message Structure
  • Message Contents
  • Example : 5GMM Status
• Reference

Why we need 5GMM Status ?

Most 5GMM procedures already have their own way to say no. Registration has REGISTRATION REJECT, service request has SERVICE REJECT, and so on. Then you may ask why another error message is needed. The reason is that some errors do not belong to any procedure. A message may have an unknown message type, a broken mandatory IE, or it may arrive in a state where it is not expected. In that case the receiver cannot even tell which procedure should reject it.

5GMM STATUS fills this gap. It is a generic report that says only one thing: I received something from you that I could not handle, and here is the reason. 24.501 clause 5.4.6 describes it as a procedure for reporting error conditions at any time, from the AMF or from the UE.

The important point is what the receiver does with it. 24.501 says that on receipt of 5GMM STATUS, no state transition and no specific action shall be taken as seen from the radio interface. Local actions are allowed, but they are implementation dependent. So 5GMM STATUS is a diagnostic message. It does not abort, restart or complete any procedure by itself.

• It reports errors no procedure can reject : unknown message types, broken mandatory IEs and messages in the wrong state.
• Both sides can send it : the UE and the AMF use the same message in both directions.
• The receiver changes no state : any reaction is a local, implementation dependent action, invisible on the radio interface.
• It covers 5GMM only : an error in a 5GSM message is reported with 5GSM Status instead, and the EPD of the bad message decides which one.

Signaling Sequence

There is no multi-step procedure in the normal sense. The status message is sent as an error indication after one side detects a problem in a received 5GMM message.

This one-row table looks too simple, so let's put it in context. A 5GMM STATUS is always an answer to an earlier message from the other side. In a log, the interesting message is usually the one right before it, in the opposite direction. The following table shows a typical case where the UE cannot decode a downlink 5GMM message.

Then what happens to the procedure that message 1 belonged to ? 24.501 does not tie the STATUS to that procedure. My understanding is that the sender of message 1 usually finds out through its own procedure timer. The STATUS tells a human reading the log why the timer expired, but it does not stop the timer.

• Read the message before the STATUS : the STATUS points at the previous message from the other side, not at itself.
• The bad message is usually ignored : for most protocol errors the receiver discards the message and sends only the STATUS.
• Recovery comes from the original procedure : timers and retransmissions of that procedure do the recovery, not the STATUS.

When is 5GMM Status sent ?

So when exactly does a UE or an AMF send this message ? The answer is in 24.501 clause 7, the error handling clause. It lists the checks a receiver applies to every NAS message, in order of precedence. Each check that fails has a fixed reaction, and several of those reactions are a status message with a specific cause.

The following table summarizes the cases that end in a 5GMM STATUS. Pay attention to the UE and Network columns. The UE side usually says shall, but the network side usually says should or leaves it to the implementation.

One thing you would notice is that not every error ends in a STATUS. A message too short to hold a complete message type is simply ignored. A syntactically incorrect optional IE is treated as if it were not present. An unknown IE that is not marked comprehension required is also skipped. In these cases the message is still processed, or silently dropped, and no STATUS appears in the log.

These causes belong to the class of protocol errors in 24.501 Annex A.4. The class has three more causes. They are #99 information element non-existent or not implemented, #101 message not compatible with protocol state and #111 protocol error, unspecified. #111 is the catch-all, used only when no other cause in the class applies.

• The UE must report, the network may : most clause 7 rules make the UE STATUS mandatory and the network STATUS optional.
• A UE-sent STATUS is the more common one in a log : this follows directly from the shall and should difference.
• The cause tells you which check failed : #96 is a mandatory IE, #97 a message type, #98 the state, #100 a conditional IE and #95 the semantics.
• Optional IE errors are silent : the receiver drops the bad optional IE and continues, so no STATUS is sent.

Message Structure

The 5GMM Status message contains the standard 5GMM header and the 5GMM cause IE. The cause value is the key diagnostic information. In trace analysis, this message usually means that the previous NAS message or the current NAS state should be checked carefully.

Message Contents

Following is 24.501 Table 8.2.29.1.1. It is one of the shortest NAS messages, and the only IE that carries information is the 5GMM cause. There are no optional IEs at all, so every 5GMM STATUS has exactly the same shape.

The message has local significance and can go in either direction. Local means that the AMF does not pass it on to any other network function. It ends at the AMF, unlike the payload of a UL NAS Transport.

Example : 5GMM Status

The Amarisoft MME logs checked for this update did not contain a decoded 5GMM Status instance, so the following is a constructed decoding example for a malformed message case. The whole message is shown below.

Constructed NAS message, not a capture. The codings follow 24.501, and the field values are only illustrative.

[NAS] UL 5GMM: 5GMM status
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x2 (Integrity protected and ciphered)
        Auth code = 0x5a1c03e7
        Sequence number = 0x07
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x0 (Plain 5GS NAS message, not security protected)
        Message type = 0x64 (5GMM status)
        5GMM cause = 0x60 (Invalid mandatory information)

This is an uplink message, so the UE is the one complaining. The cause 0x60 is #96 invalid mandatory information. So the next step in a real log would be to find the last downlink 5GMM message before this one, and check its mandatory IEs one by one.

Also notice the security header. The STATUS is protected with the current NAS security context, like any other 5GMM message after security mode control. So the error is in the content of the previous message, not in its integrity protection. A failed integrity check is handled by different rules, and it does not lead to this message.

• The direction tells you who found the error : UL means the UE could not handle a downlink message.
• The cause tells you which check failed : 0x60 points at a mandatory IE of the previous message.
• A protected STATUS means security is fine : the problem is in the message content, not in the NAS security context.

Reference

The procedure, the error handling rules, the message contents and the cause values on this page were checked against 24.501.

• 24.501 : Non-Access-Stratum (NAS) protocol for 5G System (5GS). The 5GMM status procedure in clause 5.4.6, the error handling in clause 7, the message contents in Table 8.2.29.1.1, the message type in Table 9.7.1 and the cause descriptions in Annex A.4. The version read was v20.1.0 (Release 20).
• 5GSM Status : the matching status message for 5GSM errors.