Comparing to GSM and WCDMA, LTE has much more complicated message structure as shown below (If you are the one who have to implement ASN decoder/encoder in your protocol stack. This would give you a lot of headache). This is not the only structure, this is a most complicated structure and there are many cases where the message is in more simple structure.

The reason is that one LTE message is often several messages from different protocols, packed one inside another. An RRC message carries a NAS message as an opaque octet string, and that NAS message can carry a second NAS message of another protocol. A decoder has to switch between two encoding rules on the way down: ASN.1 PER for RRC, and the fixed octet formats of 24.301 for NAS.

Followings are the topics to be covered in this page.

• Layers of the Message Structure
• Example - Attach Request in RRC Connection Setup Complete
• Reference

Layers of the Message Structure

Which parts of the message belong to which protocol, and how does a decoder find where each part starts? The diagram below answers this for the most nested case: an RRC message that carries an EMM message, which in turn carries an ESM message.

The nesting of an uplink RRC message. The RRC message carries DedicatedInfoNAS, which holds a security protected EMM message. The EMM message holds an ESM message in its own container.

The outer layer is RRC. For an uplink message on the DCCH, the first field is the message type. In 36.331 v19.3.0, UL-DCCH-MessageType is a CHOICE between c1 and messageClassExtension, and c1 has 16 alternatives. PER therefore spends 1 bit on the outer choice and 4 bits on c1, which is the 4-bit C1 field in the diagram. The IEs of the message follow, and one of them is dedicatedInfoNAS.

DedicatedInfoNAS is defined as a plain OCTET STRING. So RRC does not decode the NAS part at all. It only writes a length and then the octets, and the UE or the MME passes them up to the NAS layer. This is the length field at the start of the DedicatedInfoNAS block in the diagram.

The NAS part starts with the security header of 24.301 clause 9.1. The first octet holds the 4-bit security header type and the 4-bit protocol discriminator. When the message is security protected, 4 octets of message authentication code and 1 octet of sequence number follow. That is 4 + 32 + 8 = 44 bits, as the diagram labels them. The plain EMM message comes next, with its own header octet and an 8-bit message type. An ESM message inside it starts with its own header and has its own 8-bit message type. The Security Header and NAS Integrity pages cover these header fields in detail.

• RRC is encoded with ASN.1 PER : the message type is a 1 bit plus 4 bit choice.
• DedicatedInfoNAS is an OCTET STRING : RRC carries NAS without decoding it.
• Security protected NAS adds 6 octets : security header type, PD, MAC and SN.
• ESM travels inside EMM : in the ESM message container IE.

Example - Attach Request in RRC Connection Setup Complete

The diagram above is abstract. The capture below shows the same layers in a real message: the first uplink RRC message of an initial attach, with its NAS content decoded layer by layer.

Following is an example following the message structure illustrated above.

Capture, upper half. RRCConnectionSetupComplete carries dedicatedInfoNAS, and the decoder opens it as a security protected NAS message with an integrity protected Attach request inside.

Capture, lower half. The Attach request carries a PDN connectivity request in its ESM message container of 33 octets.

The upper image starts at the RRC layer. The UE sends rrcConnectionSetupComplete with rrc-TransactionIdentifier 0 and selectedPLMN-Identity 1, the first PLMN listed in SIB1. It also sends registeredMME with mmegi and mmec, because it already holds a GUTI. The value 10 next to rrcConnectionSetupComplete-r8 matches the PER presence bits of its two optional fields, with registeredMME present and nonCriticalExtension absent.

The hex string of dedicatedInfoNAS can be read octet by octet against 24.301 v20.0.0. The table below follows the first octets of the capture. The decoder output in the images gives the same values.

Two details in the capture show the layering clearly. The MME group ID 8001 in the EPS mobile identity is the same value that RRC sends in mmegi, 1000000000000001 in binary. So the same identity appears once for the eNB, which uses it to pick the MME, and once for the MME itself. The ESM message is also complete in itself: it has its own protocol discriminator 2 and its own procedure transaction identity 9. The MME hands it to the session management side unchanged.

Only the outer NAS header is security protected here. The security header type is 1, integrity protected without ciphering. 24.301 clause 4.4.2.3 requires this for an initial NAS message such as the Attach request: the UE protects it with its current EPS security context but does not cipher it. The MME uses the KSI, here 6, to find that context and verify the MAC. The inner Attach request header is plain, with security header type 0, because it sits inside the protected envelope.

• RRC IEs first : selectedPLMN-Identity, registeredMME and dedicatedInfoNAS.
• 17 872D4439 05 : integrity protected NAS envelope with MAC and SN.
• 07 41 : plain header and message type of the Attach request.
• 02 09 D0 : PDN connectivity request inside the ESM message container.

Reference

[1] 3GPP TS 36.331 v19.3.0 - UL-DCCH-Message, RRCConnectionSetupComplete, DedicatedInfoNAS

[2] 3GPP TS 24.301 v20.0.0 - clauses 4.4.2.3 and 9.1, Table 9.3.1 security header type, Tables 9.8.1 and 9.8.2 message types, clause 8.2.4 Attach request