The purpose of the ESM cause information element is to indicate the reason why a session management request (e.g, PDN Connectivity Request) is rejected (e.g, PDN Connectivity Reject) or restricted (e.g, Activate default EPS bearer context request).

Three questions follow from that. Which messages carry the cause, what each of the three values actually restricts, and what the exchange looks like on a trace. The page answers them in that order, and 24.301 has moved in two places since the sections below were first written.

• NAS Messages Carrying ESM Cause
• Meaning of the Cause defined in 3GPP
• Example 1
• Reference :

NAS Messages Carrying ESM Cause

There are roughly two type of NAS message that carry ESM Cause. One is Activate default EPS Bearer Request which is used to accept the IP that UE requested and another message is PDN Connectivity Reject which is used to reject the PDN that UE requested.

• The tree is an Activate default EPS bearer context request, opened down to its ESM cause. Every line above it is another information element of the same message, from EPS bearer identity down to APN-AMBR.
• ESM cause splits into Octet1 and Octet2. Octet1 holds the ESM cause IEI, shown as 58, and Octet2 holds the cause value.
• The highlighted cause value reads #8:Operator Determined Barring. That is not one of the three values this page is about. The picture shows the container rather than an example of #50 to #52.
• Protocol configuration options follows the cause, which is the order 24.301 lists these elements in.

The IEI is not decoration. 24.301 defines the ESM cause as a type 3 information element two octets long, and its table for this message lists the element as optional, format TV, with IEI 58. Optional is the word that matters. An accept message carries a cause only when the network has something to report about the request it is accepting.

Roughly two is the right hedge in that paragraph, because 24.301 carries the ESM cause in eleven messages rather than two. Nine of them are rejections or a deactivation. Two of them are requests.

The split changes the encoding, which matters more than the count. In nine of the eleven the element is mandatory and its format is V, a single octet holding the value alone. In the other two it is optional and its format is TV, two octets, the first of which is the IEI.

That is why the two trees above do not match. The Activate default EPS bearer context request opens its cause into Octet1 and Octet2, because the element is optional there and carries IEI 58. The PDN connectivity reject shows a bare cause value, because the element is mandatory there and an IEI would repeat what the message type already said.

The direction runs both ways, which the paragraph above does not say. Most of the eleven do have the network answering the UE. Three do not. In 24.301 the UE sends the Activate default EPS bearer context reject and the Activate dedicated EPS bearer context reject, and either side may send the Modify EPS bearer context reject.

• The tree is a PDN connectivity reject, and it is short enough that every field shows its value.
• EPS bearer identity value reads No EPS bearer identity assigned. A rejected request never reached the point of having a bearer.
• Protocol discriminator is 2, which is EPS session management, and Message type is D1. Table 9.8.2 of 24.301 gives 1101 0001 for PDN connectivity reject, and that byte is D1.
• The highlighted cause value reads #51:PDN type IPv6 only allowed, which is one of the three.
• T3396 value sits at the bottom of the tree. That is the back-off timer, and the section below explains why it changes nothing for this cause.

The two pictures together make the point the paragraph above makes in words. One information element appears in an accept and in a reject, and only the message around it says which of the two happened.

• The cause is an element rather than a message : 24.301 defines it once, in clause 9.9.4.4, and eleven different messages carry it.
• Mandatory costs one octet and optional costs two : format V carries the value alone, while format TV puts IEI 58 in front of it, and that is the difference between the two trees above.
• An accept can still carry a cause : that is what the opening paragraph means by restricted, and it is why the element is optional in the accept message at all.
• The UE sends ESM causes too : the UE sends the activate default and activate dedicated bearer context rejects, so a cause is not only the network's answer.

Meaning of the Cause defined in 3GPP

Three cause values sit next to each other in 24.301 and are easy to confuse. Two of them limit which IP version the UE may have on an APN. The third limits how many versions may share one bearer, which is a different question with a different answer.

The details of ESM Cause is described in 24.301 B.1 Causes related to Nature of Request

#50, #51, #52 are as follows :

If you expend this table into more detailed cases, we can describe the cases as follows.

• Read the ESM Cause column against the NAS Message column and the pattern appears. Where the network refuses, the cause arrives in a PDN Connectivity Reject. Where the network accepts with a restriction, the same cause arrives in an Activate Default EPS Bearer Context Request.
• The network accepts every row where the UE asks for IPv4v6. It narrows the PDN type instead of refusing the request.
• #52 appears on two rows only, and both of them have the UE asking for IPv4v6 with Single Bearer switched ON.
• N/A in the ESM Cause column marks the rows where the UE got what it asked for, so the network had nothing to report.

Note (*) : "Single Bearer" indicate Network allows 'single address bearer only'.

Also, 24.301 6.2.2 IP address allocation via NAS signalling describes in detail as follows :

• If the UE requests for PDN type IPv4v6, but Network allows IPv4 only or IPv6 only for the requested APN for various reason, the network shall override the PDN type requested by the UE to be limited to a single address PDN type (IPv4 or IPv6). In the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message sent to the UE, the network shall set the PDN type value to either "IPv4" or "IPv6" and the ESM cause value to #50 "PDN type IPv4 only allowed", or #51 "PDN type IPv6 only allowed", respectively. The UE shall not subsequently initiate another UE requested PDN connectivity procedure to the same APN to obtain a PDN type different from the one allowed by the network.

• A UE, which is IPv6 and IPv4 capable and
• has not been allocated an IP address for this APN, shall set the PDN type IE to IPv4v6.
• has been allocated an IPv4 address for this APN and received the ESM cause #52 "single address bearers only allowed", and is requesting an IPv6 address, shall set the PDN type IE to IPv6
• has been allocated an IPv6 address for this APN and received the ESM cause #52 "single address bearersonly allowed", and is requesting an IPv4 address, shall set the PDN type IE to IPv4.

24.301 has moved since that quotation was written, and clause 6.2.2 now separates three cases where the page above has one.

The first two both produce #50 or #51, and they differ only in where the limit comes from. In one the subscription is limited to a single IP version for that APN. In the other the PDN GW configuration dictates it. The message the UE receives is identical either way.

The third produces #52, and it restricts something else. The operator uses single addressing per bearer, which 24.301 attributes to interworking with nodes of earlier releases. Nothing about the APN is limited to one IP version here. The limit is that one bearer carries one version.

That difference decides what the UE does next, and the quotation above stops just before it. Figure 1 puts the two outcomes side by side. Both begin from the same accept message with an overridden PDN type, and the cause value is the only thing that differs.

Figure 1. What follows each cause, from 24.301 clause 6.2.2. After #50 or #51 the UE must stop asking for the other IP version on that APN. After #52 it should ask again on a second PDN connection, and it then holds one connection for each version.

• The prohibition after #50 and #51 is not permanent. 24.301 lists what ends it: the UE registers to a new PLMN, the UE is switched off, or the USIM is removed.
• After #52 the UE should request the other version rather than must. 24.301 adds a note that a UE whose MT and TE are separated may not be able to act on the cause at all.
• Neither path uses a retry timer. 24.301 states that for #50 and #51 the UE shall ignore the Back-off timer value IE if the network sent one, which is why the T3396 value in the reject tree above changes nothing.
• 24.301 has since added three more values to the same group. It names #57 PDN type IPv4v6 only allowed, #58 PDN type non IP only allowed and #61 PDN type Ethernet only allowed beside #50 and #51 in the same rules.

• #50 and #51 answer which version, and #52 answers how many per bearer : the first two limit the APN to one IP version, and the third limits one bearer to one version.
• The cause decides what the UE does next : #50 and #51 forbid another request for a different PDN type, while #52 asks for one.
• The prohibition ends on three events : a new PLMN, a power off, or removal of the USIM.
• A back-off timer beside these causes does nothing : 24.301 tells the UE to ignore the Back-off timer value IE for #50 and #51.

Example 1

The trace below is the refusal case rather than the restriction case. The UE asks for IPv4, the network offers IPv6 only, and the request never becomes a bearer. The two decodes at the end are that request and that refusal, as an analyser unpacked them.

i) UE Request IPv4 to Network that support IPv6 only

ii) Network send PDN Connectivity Reject with ESM Cause 51

• Steps 1 and 2 are the RRC connection, and steps 4 to 6 are authentication and the two security mode procedures. None of them knows anything about the PDN type.
• Step 3 carries three things at once, and the comment column gives the one that matters: PDN Type value = IPv4.
• Step 7 answers in the same stacked form, and its comment column gives ESM Cause = #51 PDN type IPv6 only allowed.
• Step 8 is an RRC Connection Release. A refused attach leaves nothing for the connection to carry.

Step 3 : RRC Connection Setup Complete + Attach Request + PDN Connectivity Request

Capture : Step 3, RRC Connection Setup Complete carrying the Attach Request and the PDN Connectivity Request. The values come from one live exchange and not from the specification, and the analyser collapsed several elements to dots.

UL-DCCH-Message
    message: c1 (0)
        c1: rrcConnectionSetupComplete (4)
            rrcConnectionSetupComplete
                rrc-TransactionIdentifier: 0
                criticalExtensions: c1 (0)
                    c1: rrcConnectionSetupComplete-r8 (0)
                        rrcConnectionSetupComplete-r8
                            selectedPLMN-Identity: 1
                            registeredMME
                                mmegi: 8001 [bit length 16, 1000 0000  0000 0001 decimal value 32769]
                                mmec: 00 [bit length 8, 0000 0000 decimal value 0]
                            dedicatedInfoNAS: 17824a8d76050741220bf61300148001000000000105e060...
                                Non-Access-Stratum (NAS)PDU
                                    .....
                                    EPS mobile identity
                                        .....
                                    UE network capability
                                        .....
                                    ESM message container
                                        Length: 33
                                        ESM message container contents:
                                                   0202d011d1271a8080211001000010810600000000830600...
                                            0000 .... = EPS bearer identity: No EPS bearer identity assigned (0)
                                            .... 0010 = Protocol discriminator:
                                                        EPS session management messages (0x02)
                                            Procedure transaction identity: 2
                                            NAS EPS session management messages: PDN connectivity request (0xd0)
                                            0001 .... = PDN type: IPv4 (1)
                                            .... 0001 = Request type: initial request (1)
                                            ESM information transfer flag
                                                ....
                                            Protocol Configuration Options
                                               .....
                                    Tracking area identity - Last visited registered TAI
                                        .....
                                    DRX Parameter
                                        .....
                                    MS Network Capability
                                        .....

HEX : 20 20 80 01 00 65 17 82 4A 8D 76 05 07 41 22 0B F6 13 00 14 80 01 00 00 00 00 01 05 E0 60 C0 40 01 00 21 02 02 D0 11 D1 27 1A 80 80 21 10 01 00 00 10 81 06 00 00 00 00 83 06 00 00 00 00 00 0D 00 00 0A 00 52 13 00 14 00 01 5C 0A 00 31 03 E5 E0 3E 13 13 00 14 00 01 11 03 57 58 A6 40 08 04 02 60 00 00 02 1F 00 5D 01 02 E0

• The RRC layers at the top are a wrapper. The NAS message travels as dedicatedInfoNAS, printed once as raw hex and then unpacked below it, which is why one decode shows three protocol layers.
• ESM message container holds the PDN Connectivity Request, and its contents begin 0202d011. The 02 pairs are the bearer identity with the protocol discriminator and the procedure transaction identity, d0 is the message type for PDN connectivity request, and 11 packs the next two lines.
• Those two lines are the request itself. PDN type: IPv4 (1) and Request type: initial request (1) are the two halves of that single byte.
• EPS bearer identity: No bearer identity assigned appears here too. A request carries no bearer, for the same reason the reject does not.
• The runs of dots are the analyser's own collapsing, not a truncation introduced here. The capture is left exactly as it was recorded.

Step 7 : dlInformationTransfer+Attach Reject+PDN Connectivity Reject

Capture : Step 7, dlInformationTransfer carrying the Attach Reject and the PDN Connectivity Reject. Same exchange as the capture above, and the same message as the PDN connectivity reject tree higher up this page.

DL-DCCH-Message
    message: c1 (0)
        c1: dlInformationTransfer (1)
            dlInformationTransfer
                rrc-TransactionIdentifier: 0
                criticalExtensions: c1 (0)
                    c1: dlInformationTransfer-r8 (0)
                        dlInformationTransfer-r8
                            dedicatedInfoType: dedicatedInfoNAS (0)
                                dedicatedInfoNAS: 27cf676073020744137800040202d133
                                    Non-Access-Stratum (NAS)PDU
                                        ....
                                        NAS EPS Mobility Management Message Type: Attach reject
                                        EMM cause
                                            Cause: ESM failure (19)
                                        ESM message container
                                            Element ID: 0x78
                                            Length: 4
                                            ESM message container contents: 0202d133
                                                ....
                                                Procedure transaction identity: 2
                                                NAS EPS session management messages:
                                                    PDN connectivity reject (0xd1)
                                                ESM cause
                                                    Cause: PDN type IPv6 only allowed (51)

HEX : 08 00 81 3E 7B 3B 03 98 10 3A 20 9B C0 00 20 10 16 89 98

• Procedure transaction identity: 2 matches the request. It ties the answer to the question, and the PDN connectivity reject tree higher up this page carries the same value.
• There are two causes here, not one. EMM cause, Cause: ESM failure (19) sits at the Attach Reject level, and the real reason is one layer further in.
• ESM message container is four bytes long, 0202d133. The 02 pairs are as before, d1 is the message type for PDN connectivity reject, and 33 is the cause value, which is 51 in decimal.
• Cause: PDN type IPv6 only allowed (51) is the last line of the decode, and the whole refusal fits in those four bytes.

The nesting is worth remembering when reading a log. A UE can fail to attach for this reason and show only ESM failure at the top, and ESM failure says nothing about IP versions. The answer is inside the ESM message container, and a trace that stops at the EMM cause never reaches it.

• The refusal is four bytes : bearer identity and discriminator, procedure transaction identity, message type d1, and the cause byte 33.
• EMM cause and ESM cause are different fields : the Attach Reject reports ESM failure, and only the container inside it names the PDN type.
• The procedure transaction identity links the pair : value 2 appears in the request and in the reject, which is how a log links an answer to its request.
• A refusal and a restriction are easy to tell apart on a trace : this exchange ends in an RRC Connection Release, while #50, #51 or #52 in an accept would have produced a bearer.

Reference :

[1] 24.301 : 3GPP - Non-Access-Stratum protocol for Evolved Packet System; Stage 3, v20.0.0. Clause 6.2.2 gives the three cases that produce #50, #51 and #52, and what the UE does after each. Clause 6.5.1 covers the PDN connectivity reject and the back-off timer, clause 8.3.6.1 lists the ESM cause element in the accept message, and clause 9.9.4.4 defines that element. Table 9.8.2 gives the message types.