5GSM Status is an error reporting message for the 5GS Session Management sublayer. Either side can send it when a 5GSM protocol error is detected and there is no more specific procedure response to use. The key diagnostic field is the 5GSM cause.

At first, this looks like a copy of 5GMM Status for the other NAS sublayer. But there is one big difference. A 5GMM STATUS changes nothing on the receiving side. A 5GSM STATUS with certain causes makes the receiver abort a procedure, and it can even release a PDU session.

• Why we need 5GSM Status ?
• Signaling Sequence
• When is 5GSM Status sent ?
• What does the receiver do ?
• Message Structure
  • Message Contents
  • Example : 5GSM Status
• Reference

Why we need 5GSM Status ?

Why does 5GSM need its own status message ? The reason is that 5GSM messages have two identifiers that 5GMM messages do not have: the PDU session ID and the PTI. Each of them can go wrong in its own way. A command can arrive with a PTI that no procedure is using. A message can name a PDU session that the receiver already released. These are not problems of message format. They are problems of session state, and only the 5GSM layer can see them.

The other reason is where the message ends. A 5GSM message is carried in a UL or DL NAS Transport, and the AMF only forwards it. So the real peer of a 5GSM STATUS from the UE is the SMF, not the AMF. A 5GMM STATUS would stop at the AMF and never reach the SMF that sent the bad message.

The extended protocol discriminator of the bad message decides which status message is used. A message with EPD 0x2e gets a 5GSM STATUS, and a message with EPD 0x7e gets a 5GMM STATUS.

• PTI and PDU session ID errors are 5GSM errors : only the 5GSM layer keeps the state that can detect them.
• The peer is the SMF : the AMF passes a 5GSM STATUS through like any other N1 SM information.
• The EPD of the bad message decides : 0x2e leads to 5GSM STATUS, and 0x7e leads to 5GMM STATUS.

Signaling Sequence

5GSM Status is not a multi-step procedure. It is sent as a single error indication after a 5GSM message or state inconsistency is detected. The receiver sends no answer back, so the exchange is always one message long.

Let's put this single row into a real context. The following table shows a common case. The SMF sends a PDU SESSION RELEASE COMMAND with a PTI that the UE is not using, and the UE cannot match it with any of its own procedures.

There is one exception in this case. If the RELEASE COMMAND is a retransmission of a release the UE already accepted, the UE does not send a STATUS. It simply sends RELEASE COMPLETE again. So a #47 means the UE really has no record of that PTI.

• The STATUS travels in UL NAS Transport : in a log it appears as N1 SM information with the PDU session ID of the bad message.
• Row 3 is what makes 5GSM different : the SMF reacts to the STATUS, and the procedure ends there.
• A retransmission is not a mismatch : the UE answers a repeated command it already handled with the normal response.

When is 5GSM Status sent ?

Then when exactly is a 5GSM STATUS sent ? 24.501 clause 7 answers this, in the same error handling clause used for 5GMM. The general rules for message type and mandatory IE errors apply here too. On top of them, clause 7.3 adds rules for the two 5GSM identifiers, and that is where most 5GSM STATUS messages come from.

One thing you would notice is the last row, when no procedure-specific response is defined. 24.501 clause 7.5.3 lists several 5GSM messages where a mandatory IE error gets a normal procedure message instead of a STATUS. A broken ESTABLISHMENT ACCEPT makes the UE send a PDU SESSION RELEASE REQUEST with #96. A broken RELEASE COMMAND gets a RELEASE COMPLETE with #96. On the network side, a broken ESTABLISHMENT, MODIFICATION or RELEASE REQUEST gets the matching reject with #96.

The PDU session ID has a similar exception on the network side. A MODIFICATION or RELEASE REQUEST with an unknown PDU session ID gets a reject with #43, not a STATUS. If the AMF cannot find the PDU session, it returns the whole payload in a DL NAS Transport with 5GMM cause #90 payload was not forwarded.

• Most 5GSM STATUS messages are about the PTI : #47 and #81 cover the cases where the PTI does not fit the message.
• #43 from the UE means the session is gone in the UE : the UE already sees that PDU session as inactive.
• A procedure-specific answer wins over a STATUS : when a request, accept or release command is broken, the normal procedure message carries the cause instead.

What does the receiver do ?

This is the part where 5GSM STATUS really differs from 5GMM STATUS. A 5GMM STATUS changes no state on the receiving side. A 5GSM STATUS does, for a few cause values. 24.501 clauses 6.5.2 and 6.5.3 list them, and the following table puts the UE and the SMF side by side.

Now we can see why the PDU session ID and PTI fields matter so much in this message. The receiver uses them to find which procedure to abort, or which session to release. A 5GSM STATUS with the wrong PDU session ID could release the wrong session. This is why the UE copies the received PDU session ID into the UL NAS Transport when it sends #43.

The #47 case on the SMF side is worth remembering for log analysis. If the UE answers an ESTABLISHMENT ACCEPT with #47, the SMF releases that PDU session locally. So the session can disappear in the network with no RELEASE COMMAND in the log.

• #43 releases the session on both sides : the UE and the SMF both perform a local release.
• #47 and #81 abort a procedure, not a session : except when the SMF gets #47 for an ESTABLISHMENT ACCEPT.
• #96 is handled differently by each side : the SMF aborts the procedure, while the UE changes no state.
• A silent release can follow a STATUS : a local release produces no RELEASE messages, so the STATUS is the only trace in the log.

Message Structure

The 5GSM Status message contains the 5GSM header and a 5GSM cause IE. In trace analysis, the message before the status indication is usually the message that should be inspected first.

Message Contents

Following is 24.501 Table 8.3.16.1.1. Compare it with the 5GMM STATUS. The 5GSM header carries the PDU session ID and the PTI, and those two fields tell the receiver which session and which procedure the error is about.

The message has dual significance, while the 5GMM STATUS has local significance. In other words, a 5GSM STATUS is meant for the SMF at the far end, and the AMF only forwards it. Like 5GMM STATUS, it has no optional IEs.

Example : 5GSM Status

The checked Amarisoft MME logs did not contain a decoded 5GSM Status instance, so the following is a constructed full-message example. It shows only the 5GSM part. In a real log it sits inside a UL NAS Transport with payload container type N1 SM information.

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

[NAS] UL 5GSM: 5GSM status
        Protocol discriminator = 0x2e (5GS Session Management)
        PDU session identity = 1
        Procedure transaction identity = 52
        Message type = 0xd6 (5GSM status)
        5GSM cause = 0x60 (Invalid mandatory information)

The cause 0x60 is #96 invalid mandatory information, and the message is uplink. So the UE found a mandatory IE error in a downlink 5GSM message with PTI 52 for PDU session 1. Which message could that be ? It cannot be an ESTABLISHMENT ACCEPT or a RELEASE COMMAND, because those get a procedure-specific answer under clause 7.5.3. A PDU SESSION MODIFICATION COMMAND is a good candidate, since clause 7.5.3 has no special rule for it.

On receipt, the SMF aborts the procedure for PTI 52 or PDU session 1 and stops its timer. If that was a modification, T3591 stops here, and the SMF does not retransmit the command.

• PTI 52 points at the procedure : the SMF uses it to find the modification it should abort.
• #96 from the UE stops the SMF procedure : this is one of the causes listed in clause 6.5.3.
• The 5GMM envelope is not shown : a real capture adds the UL NAS Transport header and the outer PDU session ID.

Reference

The procedure, the error handling rules, the receiver actions, 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 5GSM status procedure in clause 6.5, the error handling in clause 7, the message contents in Table 8.3.16.1.1, the message type in Table 9.7.2 and the cause descriptions in Annex B. The version read was v20.1.0 (Release 20).
• 5GMM Status : the matching status message for 5GMM errors.
• PDU Session Procedures : the PTI rules and the procedures a 5GSM STATUS can abort.