UL NAS Transport and DL NAS Transport are 5GMM messages used to carry another NAS payload through the 5GMM layer. The most common payload is N1 SM information, for example a 5GSM PDU Session Establishment Request in the uplink and a 5GSM PDU Session Establishment Accept in the downlink. In this case 5GMM does not interpret the 5GSM content as mobility management information; it provides the protected transport envelope between UE and AMF.

If you look at a 5G SA log, these two messages are everywhere. Every PDU session procedure, every SMS over NAS, every LPP positioning message and every UE policy update rides inside one of them. So once you understand this envelope, a big part of the NAS log becomes much easier to read.

• Why we need NAS Transport ?
• Signaling Sequence
• Payload Container Type
• Message Structure
  • UL NAS Transport Contents
  • DL NAS Transport Contents
  • Example : UL NAS Transport
  • Example : DL NAS Transport
• When the AMF cannot forward the payload
• Reference

Why we need NAS Transport ?

Why do we need a special message only for carrying other messages ? The reason comes from how N1 is built. The UE has only one NAS signalling connection, and it ends at the AMF. But the AMF is not the only core network function that wants to talk to the UE. The SMF wants to exchange 5GSM messages, the SMSF wants to exchange SMS, the LMF wants to exchange LPP messages, and the PCF wants to send UE policies.

One option would be a separate NAS connection for each of these functions. 5GS does not do that. Instead, everything goes through the one 5GMM connection to the AMF, and UL/DL NAS Transport is the envelope for it. The AMF opens the envelope only far enough to see where it should go. Then it forwards the content to the right function, or delivers the reply back to the UE.

The following diagram shows this fan-out. The UE and the gNB each see one NAS connection. The fan-out to the different core functions happens only at the AMF, and the Payload container type in the envelope decides the direction.

Figure 1. One NAS connection, many peers. The gNB and the UE see a single 5GMM connection, and only the AMF splits the traffic by Payload container type toward the function that owns the payload.

• N1 SM information goes to the SMF : this is the PDU session traffic, and it is the payload you will see most often in a log.
• SMS goes to the SMSF : this is SMS over NAS, so a UE can send SMS without an IMS registration.
• LPP message container goes to the LMF : positioning measurements and assistance data use the same envelope.
• UE policy container goes to the PCF : the URSP delivery of the Manage UE Policy procedure travels here.
• SOR and UE parameters update containers go to the UDM : the home network uses them to update steering of roaming data and UE parameters.

There is one more benefit of this design. The 5GMM envelope is integrity protected and ciphered with the NAS security context of the registration. So every payload inside it gets the same protection, and none of these protocols needs its own NAS security.

Signaling Sequence

The following sequence shows a typical use case where the UE requests a PDU session and the network returns the corresponding session establishment result. The 5GSM messages are transported inside UL/DL NAS Transport.

This table shows only the two NAS messages, but each of them crosses three interfaces on the way. Then you may ask what the message looks like on each of them. The NAS message itself never changes. Only the container around it changes, and the following table follows the same PDU session establishment through all of them.

One thing you would notice is row 5. In the uplink, the NAS message travels in a plain NGAP UPLINK NAS TRANSPORT. In the downlink for this case, it does not travel in DOWNLINK NAS TRANSPORT. The AMF puts the DL NAS Transport inside the PDU SESSION RESOURCE SETUP REQUEST, together with the N2 information the gNB needs for the user plane. So the gNB receives the NAS accept and the resource setup in one message.

The other point is the SMF side. The SMF never sees the 5GMM envelope. The AMF strips it in row 3 and builds a new one in row 5. So the PDU session ID, S-NSSAI and DNN in the envelope are information for the AMF, not for the SMF.

• The NAS message is the same end to end : only the RRC and NGAP containers around it change.
• The SMF sees only the 5GSM part : the 5GMM envelope ends at the AMF in both directions.
• The downlink NAS can ride in a resource setup message : the accept arrives with the N2 user plane setup instead of in a separate DOWNLINK NAS TRANSPORT.

Payload Container Type

The Payload container type is the field that makes the envelope work. It is only four bits, but it decides how the AMF routes the container and how the UE parses it. 24.501 Table 9.11.3.40.1 defines the values below, and every value other than these is reserved.

The first value is the one you will see in almost every log. Most of the others belong to features that came later, and a commercial UE may never use them. Multiple payloads needs special care, because it changes the structure of the container itself. The container then starts with a number of entries, and each entry has its own type, length and routing information.

• The type is a half octet : it is a type 1 IE and shares its octet with a spare half octet in both messages.
• The type tells the UE how to parse the container : with N1 SM information the container starts with the 5GSM extended protocol discriminator 0x2e.
• Multiple payloads is the only nested form : every other value means exactly one payload in the container.

Message Structure

The key field is the Payload container type. When this value indicates N1 SM information, the payload container starts with a 5GSM message such as PDU Session Establishment Request, PDU Session Establishment Accept, PDU Session Modification Command, or PDU Session Release Command.

The two messages are not symmetric. The uplink message carries many optional IEs, because the UE has to give the AMF enough routing information to select an SMF. The downlink message has almost nothing besides the container, because the routing is already done when the AMF sends it.

UL NAS Transport Contents

Following is 24.501 Table 8.2.10.1.1, without the header IEs. For now, just pay attention to the PDU session ID, Request type, S-NSSAI and DNN rows. Those are the IEs the AMF uses to pick an SMF for a new PDU session.

Then what happens when the UE does not include S-NSSAI or DNN ? The AMF fills the gap itself. For example, if the allowed NSSAI has only one S-NSSAI, the AMF simply uses that one. If there are several and only one of them is a default S-NSSAI in the subscription, the AMF uses that default. A missing DNN is handled in a similar way, with the default DNN of the subscription. The example below gives a DNN but no S-NSSAI.

DL NAS Transport Contents

Following is 24.501 Table 8.2.11.1.1, again without the header IEs. Look at the last three rows. They appear only when something went wrong, so a normal DL NAS Transport carries none of them.

So if you see a 5GMM cause in a DL NAS Transport, do not read the container as a normal downlink message. It is your own uplink message coming back. The section When the AMF cannot forward the payload explains this case.

Example : UL NAS Transport

The following example is based on an Amarisoft MME log where the UE sends N1 SM information for PDU session establishment. The whole decoded NAS message is shown below.

Decoded NAS message from an Amarisoft log. Field values are from a live capture, not from the specification.

04:09:34.950 [NAS] UL 0064 5GMM: UL NAS transport
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x2 (Integrity protected and ciphered)
        Auth code = 0x44bc599f
        Sequence number = 0x03
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x0 (Plain 5GS NAS message, not security protected)
        Message type = 0x67 (UL NAS transport)
        Payload container type = 1 (N1 SM information)
        Payload container:
          Protocol discriminator = 0x2e (5GS Session Management)
          PDU session identity = 1
          Procedure transaction identity = 49
          Message type = 0xc1 (PDU session establishment request)
          Integrity protection maximum data data:
            Maximum data rate per UE for user-plane integrity protection for uplink = 0x00 (64 kbps)
            Maximum data rate per UE for user-plane integrity protection for downlink = 0x00 (64 kbps)
          PDU session type = 0x3 (IPv4v6)
          5GSM capability:
            0x00 (TPMIC=0, ATSSS-ST=0, EPT-S1=0, MH6-PDU=0, RqoS=0)
          Extended protocol configuration options:
            Ext = 1
            Configuration protocol = 0
            Protocol ID = 0xc223 (CHAP)
            Data = 01 00 00 16 10 e3 f4 30 30 e3 f4 30 30 e3 f4 30 30 e3 f4 30 30 2a
            Protocol ID = 0xc223 (CHAP)
            Data = 02 00 00 16 10 96 a3 52 cd 73 78 3b 3d 22 d1 d5 50 a6 e9 17 17 2a
            Protocol ID = 0x8021 (IPCP)
            Data = 01 00 00 10 81 06 00 00 00 00 83 06 00 00 00 00
            Protocol ID = 0x000d (DNS Server IPv4 Address Request)
            Data =
            Protocol ID = 0x0003 (DNS Server IPv6 Address Request)
            Data =
            Protocol ID = 0x000a (IP address allocation via NAS signalling)
            Data =
            Protocol ID = 0x0005 (MS Support of Network Requested Bearer Control indicator)
            Data =
            Protocol ID = 0x0010 (IPv4 Link MTU Request)
            Data =
            Protocol ID = 0x0011 (MS support of Local address in TFT indicator)
            Data =
            Protocol ID = 0x0023 (QoS rules with the length of two octets support indicator)
            Data =
            Protocol ID = 0x0024 (QoS flow descriptions with the length of two octets support indicator)
            Data =
        PDU session ID = 1
        Request type = 0x1 (initial request)
        DNN = "internet"

There are a couple of points that I want you to notice here. First, look at the two security headers. The outer one says integrity protected and ciphered, and the inner one says plain. The inner header belongs to the same UL NAS transport after the security is removed, and the 5GSM message has no security header of its own.

Second, look at the indentation. Everything indented under Payload container is the 5GSM message for the SMF. The last three lines, PDU session ID, Request type and DNN, are back at the outer level. Those are the 5GMM routing IEs for the AMF. Also notice that there is no S-NSSAI at the outer level, so the AMF has to choose the slice for this session.

• Two security headers is normal : the first is the protected NAS message, and the second is the plain 5GMM message inside it.
• The PDU session ID appears twice : once inside the 5GSM header and once as the outer 5GMM IE, and both are 1 here.
• The UE asked for IPv4v6 : keep this in mind when you read the accept in the next example.

Example : DL NAS Transport

The following example is based on the matching downlink response in the same Amarisoft MME log. The whole decoded NAS message is shown below. Keep the uplink example in view while you read it, because most fields here answer a field there.

Decoded NAS message from an Amarisoft log. Field values are from a live capture, not from the specification.

04:09:34.950 [NAS] DL 0064 5GMM: DL NAS transport
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x2 (Integrity protected and ciphered)
        Auth code = 0xa999e875
        Sequence number = 0x04
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x0 (Plain 5GS NAS message, not security protected)
        Message type = 0x68 (DL NAS transport)
        Payload container type = 1 (N1 SM information)
        Payload container:
          Protocol discriminator = 0x2e (5GS Session Management)
          PDU session identity = 1
          Procedure transaction identity = 49
          Message type = 0xc2 (PDU session establishment accept)
          Selected PDU session type = 0x1 (IPv4)
          Selected SSC mode = 0x1 (1)
          Authorized QoS rules:
            QoS rule 1:
              QoS rule identifier = 1
              Rule operation code = 1 (create new QoS rule)
              DQR = 1 (the QoS rule is the default QoS rule)
              Number of packet filters = 1
              Packet filter identifier = 15
                Packet filter direction = 3 (bidirectional)
                Match-all
              QoS rule precedence = 255
              QFI = 1
          Session AMBR:
            Session-AMBR for downlink = 3000000 kbps
            Session-AMBR for uplink = 1000000 kbps
          5GSM cause = 0x32 (PDU session type IPv4 only allowed)
          PDU address:
            SI6LLA = 0
            PDU session type = 1 (IPv4)
            IPv4 = 192.168.3.2
          S-NSSAI:
            Length of S-NSSAI contents = 1 (SST)
            SST = 0x01
          Mapped EPS bearer contexts:
            Mapped EPS bearer context 1:
              EPS bearer identity = 5
              Operation code = 1 (create new EPS bearer)
              E = 1 (parameters list is included)
              Number of EPS parameters = 2
              Mapped EPS QoS parameters:
                QCI = 9
              APN-AMBR:
                APN-AMBR for downlink = 2816000000 bits
                APN-AMBR for uplink = 768000000 bits
          Authorized QoS flow descriptions:
            QoS flow description 1:
              QFI = 1
              Operation code = 1 (create new QoS flow description)
              E = 1 (parameters list is included)
              Number of parameters = 2
              5QI = 9
              EPS bearer identity = 5
          Extended protocol configuration options:
            Ext = 1
            Configuration protocol = 0
            Protocol ID = 0x8021 (IPCP)
            Data = 03 00 00 0a 81 06 08 08 08 08
            Protocol ID = 0x000d (DNS Server IPv4 Address)
            Data = 8.8.8.8
          DNN = "internet.mnc001.mcc001.gprs"
        PDU session ID = 1

Compare this with the uplink example. The outer level now has only one routing IE, the PDU session ID. There is no 5GMM cause either, so the AMF delivered the request to the SMF normally and this container is a real answer from the SMF. The PTI is 49 in both messages, and that is how the UE pairs this accept with its request.

Now look inside the container. The UE asked for IPv4v6, but the selected PDU session type is IPv4, and the 5GSM cause 0x32 is #50 PDU session type IPv4 only allowed. So the downgrade is reported inside the 5GSM message, not in the 5GMM envelope. The S-NSSAI with SST 1 is the slice the AMF chose, because the uplink did not name one.

• No 5GMM cause means normal delivery : the outer level of a successful DL NAS Transport usually carries only the PDU session ID.
• Session results are in the 5GSM part : the IPv4 only downgrade appears as a 5GSM cause inside the accept, not as a 5GMM cause.
• The DNN changes form : the UE sent internet, and the accept returns the full form internet.mnc001.mcc001.gprs with the operator identifier.

When the AMF cannot forward the payload

So far the AMF always forwarded the container. But what happens if it cannot ? The AMF may fail to select an SMF, the slice or DNN may be congested, or the UE may already have the maximum number of PDU sessions. In these cases the AMF does not discard the message silently. It sends the uplink 5GSM message back to the UE in a DL NAS Transport, together with a 5GMM cause.

This is the reason the 5GMM cause and Back-off timer value IEs exist in the downlink message. The following table lists the common 5GMM causes for a returned 5GSM message and what each one means for the UE.

On the UE side, the 5GMM layer does not handle the failure by itself. It passes the returned 5GSM message up to the 5GSM sublayer, together with the reason and the back-off timer value. So the 5GSM procedure that sent the message ends there. For PDU session establishment, 24.501 lists a DL NAS Transport with #22, #28, #65, #67, #69, #90, #91 or #92 as one of the events that stop T3580.

This is the case where reading a log quickly can mislead you. The returned container still decodes as a PDU SESSION ESTABLISHMENT REQUEST, which is a UE-to-network message, inside a downlink message. That is not a decoder error. It is the AMF returning your own request.

• A 5GMM cause in DL NAS Transport is a delivery failure : the SMF never saw the request, so there is no 5GSM reject from the SMF.
• The container is the UE's own uplink message : an uplink 5GSM message type inside a downlink envelope is the marker of this case.
• The back-off timer is the main thing to respect : with #22, #67 and #69 the UE has to wait before it can try the same DNN or slice again.
• A 5GSM reject is a different case : when the SMF refuses the session, the reject arrives as a normal DL NAS Transport with no 5GMM cause and a 5GSM cause inside.

Reference

The message contents, the payload container types and the cause handling on this page were checked against 24.501. The PDU session context around the examples is on the PDU session page of this site.

• 24.501 : Non-Access-Stratum (NAS) protocol for 5G System (5GS). The NAS transport procedures in clause 5.4.5, the UL and DL NAS TRANSPORT message contents in clauses 8.2.10 and 8.2.11, the payload container type in Table 9.11.3.40.1 and the T3580 timer table. The version read was v20.1.0 (Release 20).
• PDU Session Establishment : the 5GSM messages carried inside these envelopes, including modification and release.
• NGAP : the NGAP messages that carry the NAS message between gNB and AMF.