7 What a NAS message looks like on the wire

7.1 Why the coding gets its own clauses

Two vendors who agree on every procedure in the document will still fail to interoperate if one of them puts a field in a different octet. So the document separates two questions and answers them in different places: what a message means, and what it looks like.

Clause 8 defines every message as a list of fields with a presence rule and a format. Clause 9 defines how each of those fields is written into octets. A question about behaviour goes to clauses 5 and 6; a question about bytes goes to 8 and 9.

7.2 The fixed part of every message

Every NAS message is a standard layer-3 message, and a plain one always begins the same way §9.1.1:

• Extended protocol discriminator, one octet, first §9.2. It says which of the two protocols this message belongs to.

• Security header type with a spare half octet, or, for a session management message, the PDU session identity §9.3 §9.4 §9.5. The two share the second octet because a message is never both.

• Procedure transaction identity — only in session management messages, and only there does the extra octet exist at all §9.1.1 §9.6.

• Message type, one octet, a number out of a table §9.7.

• Other information elements as required.

The document is precise about which octet each of those occupies, and about the one that sometimes is not there: the procedure transaction identity octet is included only in messages whose protocol discriminator says session management §9.1.1.

7.3 Protection: a message inside a message

A protected NAS message is not a plain message with extra fields bolted on. It is a different message, whose last field is the whole plain message §8.2.28:

Field	Presence	Length in octets
Extended protocol discriminator	M	1
Security header type	M	1/2
Spare half octet	M	1/2
Message authentication code	M	4
Sequence number	M	1
Plain 5GS NAS message	M	3-n

Six octets of wrapper, then the real message. The code protecting it is four octets §9.8, and the sequence number is one octet carrying the eight least significant bits of the NAS COUNT §9.10 — the full counter is longer, and both sides keep the rest.

One detail catches people reading a capture: the protocol discriminator in the header of a security protected message is always encoded as "5GS mobility management messages", whatever is inside §9.2.

A protected session management message looks like a mobility management message until you unwrap it.

The security header type is four bits and takes five defined values §9.3:

Value	Meaning
0000	Plain message, not security protected
0001	Integrity protected
0010	Integrity protected and ciphered
0011	Integrity protected with new security context
0100	Integrity protected and ciphered with new security context

The last two exist for one moment each: 0011 may be used only for a security mode command, and 0100 only for a security mode complete §9.3. All other values are reserved.

And the rule that keeps a receiver honest:

The field inside the plain message that holds it is defined so as to forbid the obvious recursion: a security protected message is not a plain message and shall not be put inside one §9.9.

7.4 How a message definition is written

Each message in clause 8 comes with a table of the fields it may carry, in the order they appear §8.1. Six things are given per field:

• The identifier in hexadecimal, if the field carries one.

• The name, which usually hints at the meaning.

• The type, which points at the clause 9 subclause that codes it.

• The presence requirement — M for mandatory, C for conditional, O for optional.

• The format — T, V, TV, LV, TLV, LV-E or TLV-E.

• The length, in octets, or a range.

The order is not arbitrary. Fields in the formats V, LV and LV-E make up the imperative part of a message and always come before the fields in T, TV, TLV and TLV-E, which make up the non-imperative part §8.1.

That is what lets a receiver parse the mandatory part positionally and then walk the rest by identifier.

There is one blanket rule about repetition, and it is easy to overlook because it sits at the end of the message-format clause rather than with the message definitions:

7.5 Bit order, spelled out

Field mapping gets its own subclause because the mistake it prevents is expensive §9.1.2. Inside a single octet, the lowest numbered bit is the least significant.

Across several octets, significance decreases as the octet number rises: the most significant bit of a field is the highest numbered bit of its lowest numbered octet.

That convention is stated once and then assumed everywhere, including in the tables of clause 9 that draw fields spanning octet boundaries.

7.6 When a message cannot be understood

Clause 7 is what stops one side's mistake from becoming both sides' deadlock, and it is applied in a fixed order §7.1. A few of its answers are worth knowing without lookup.

A message type that does not exist, or is not implemented. The device returns a status message — 5GMM STATUS or 5GSM STATUS depending on the protocol discriminator — with cause #97, "message type non-existent or not implemented" §7.4.

A message that exists but does not fit the current state. The device returns a status message with cause #98, "message type not compatible with protocol state" §7.4.

A message whose contents are semantically wrong. The device does whatever the procedure clauses say; where they say nothing, it ignores the message and returns a status with cause #95, "semantically incorrect message" §7.8.

The network's side of all three is looser on purpose. Where the device "shall" return a status, the network's actions are implementation dependent in some cases, and where it does answer, the clause says it "should" §7.4 §7.8.

The document is explicit that detailed error handling in the network is implementation dependent and may vary from one operator to another §7.1.

Errors in the non-imperative part are their own category, and there are exactly two kinds: syntactically incorrect optional fields, and conditional field errors §7.7.

7.7 The cause values

A rejection is never bare. It carries a numbered cause, and the two annexes list them all with a paragraph each — Annex A for mobility management, Annex B for session management.

Reading a few makes the style clear. Cause #3, "Illegal UE", is sent when an identity is not acceptable to the network or the device failed the authentication check §A.1.

Cause #10, "Implicitly de-registered", is sent when the network has already dropped the device, for example after a timer expired or after an AMF restart §A.1.

The protocol-error causes run in a block of five §B.2:

Cause	Meaning
#95	Semantically incorrect message
#96	Invalid mandatory information
#97	Message type non-existent or not implemented
#98	Message type not compatible with protocol state
#99	Information element non-existent or not implemented

7.8 Where this meets the rest of the course

The procedures these messages serve are Getting on the network, and getting a connection through it, and the document's layout, including where clause 8 and clause 9 sit in the reading path, is Finding your way around TS 24.501. Every one of these tables got its current contents through the process in From a document number to a published version.