IP allocation in NR process is very similar to LTE IP Allocation process at high level. It is done by a pair of NAS signaling (PDU Session Establishment Request and PDU Session Establishment Accept) as it is done by a pair of NAS message (PDN Connectivity Request and Activate Default/Dedicated EPS Bearer Context Request) in LTE.

• Executive Summary
• High Level Protocol Sequence
• PDU Session Establishment Request
• PDU Session Establishment Accept
• What does the UE actually ask for ?
• Where does the address actually come from ?
• What else does the Accept configure ?
• What does SSC mode decide about the address ?
• How does this compare with LTE ?
• Reference

Executive Summary

High Level Protocol Sequence

The table in this section reads as two messages between the UE and the SMF. I took that literally for a long time. The UE and the SMF never exchange anything directly, and four elements sit between them.

Following is overall signaling procedure for IP allocation in 5G. For the details of these messages refer to 5GSM page.

Start with what the UE actually sends. The 5GSM message never travels on its own. It sits as a payload container inside a 5GMM message, which travels inside RRC, which the gNB repacks into NGAP. The Message column of the table is that stack written on one line.

One detail in the nesting decides the whole procedure. The PDU session ID, the Request type and the DNN sit in the outer 5GMM message, and not inside the container. The AMF needs all three, because it has to choose which SMF will handle the session. It cannot read the container itself, so anything it needs has to sit outside.

Figure 1 unpacks the request from the trace in PDU Session Establishment Request, one layer at a time.

Figure 1. The Message column of the table is this stack written on one line. Only the innermost layer says anything about an IP address.

The gap between the two rows of the table is where most of the work happens. The AMF selects an SMF from the DNN and the S-NSSAI. It then passes the container to that SMF with Nsmf_PDUSession_CreateSMContext. The SMF selects a UPF and establishes an N4 session with it. The address is allocated somewhere in there, by whichever source the SMF is configured to use.

The answer travels back the same way in reverse. The SMF hands the accept to the AMF in Namf_Communication_N1N2MessageTransfer. The AMF sends it down toward the UE, and the radio resources are set up alongside it by an N2 PDU Session Resource Setup. The UE sees none of this. It sees one request and one answer.

Figure 2 puts every element on one time line, so the two rows of the table can be located inside the wider procedure.

Figure 2. The address is allocated at step 4, four elements away from the UE. Everything the UE observes is the delay between its request and the answer.

T3580 is the guard the UE keeps on the whole exchange. The UE starts it when it sends the request, and stops it when the accept or the reject arrives. If the timer expires the UE retransmits, and it abandons the attempt after four retransmissions. Everything between the two rows has to complete inside that window, including the SMF selection, the N4 setup and the address allocation.

• The two rows hide five elements : The UE and the SMF never talk directly. The gNB, the AMF and the UPF all take part in between.
• The 5GSM message is a passenger : It rides inside 5GMM, inside RRC, and then inside NGAP. Only the innermost layer is about IP.
• The AMF cannot read the container : PDU session ID, Request type and DNN sit outside it precisely so the AMF can select an SMF without opening it.
• The address is allocated at the SMF : It happens around the N4 session setup, four elements away from the UE.
• T3580 bounds the whole procedure : SMF selection, N4 setup and address allocation all have to finish before the UE gives up.

PDU Session Establishment Request

The first step for the IP allocation is for UE to make a request to the network to allocate an IP. In case of LTE, network allocate at least one IP to the UE through default EPS bearer setup process, but in NR there is no default IP allocation. So UE should request IP allocation. The signaling message used to request IP allocation is PDU session establishment request (it is equivalent to PDN Connectivity Request in LTE)

This is a sample message from the log provided by Amarisoft.

The way UE indicates the request for IP allocation is similar to the case of LTE. As shown in the example, UE specifies the type of IP (IPv4, IPv6 etc) via the IE PDU sesssion type and specifies the protocols for the IP via PCO(Protocol Configuration Options).

Four groups of information elements matter in this message, and the colours in the trace separate them. The first group names the message, so that the point where the 5GSM message begins inside the 5GMM one is visible. The second is the addressing request, which is a single field. The third is the extended PCO, where everything except the address is asked for. The fourth is the set of parameters that the AMF reads without opening the container. The table after the trace takes each highlighted element in turn.

Highlighting in the trace :  message identity  |  addressing  |  protocol configuration options  |  routing and session parameters

Message: UL NAS transport

Data:


Protocol discriminator = 0x7e (5GS Mobility Management)
Security header = 0x2 (Integrity protected and ciphered)
Auth code = 0xff096300
Sequence number = 0x02
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 = 5
  Procedure transaction identity = 9
  Message type = 0xc1 (PDU session establishment request)
  Integrity protection maximum data data:
    Maximum data rate per UE for user-plane integrity protection 
                                     for uplink = 0xff (Full data rate)
    Maximum data rate per UE for user-plane integrity protection 
                                     for downlink = 0xff (Full data rate)
  PDU session type = 0x3 (IPv4v6)
  SSC mode = 0x1 (1)
  Extended protocol configuration options:
    Ext = 1
    Configuration protocol = 0
    Protocol ID = 0x000a (IP address allocation via NAS signalling)
    Data =
    Protocol ID = 0x0002 (IM CN Subsystem Signaling Flag)
    Data =
    Protocol ID = 0x0001 (P-CSCF IPv6 Address Request)
    Data =
    Protocol ID = 0x000c (P-CSCF IPv4 Address Request)
    Data =
    Protocol ID = 0x0003 (DNS Server IPv6 Address Request)
    Data =
    Protocol ID = 0x000d (DNS Server IPv4 Address Request)
    Data =
PDU session ID = 5
Request type = 0x1 (initial request)
DNN = "ims"

PDU Session Establishment Accept

Once the core network (SMF) recieves the IP allocation request from UE, the network allocates the necessary resources and configurations with other network components and notifies about the final result (i.e, allocated IP) to the UE via PDU session Establsihment accept.

The accept answers the request element by element, so the two traces are worth reading side by side. Every container identifier that the request sent empty reappears here carrying a value. The address itself arrives in the PDU address element, and everything around it is the session configuration that comes with the address. The same four colours are used in both traces, so the groups can be compared directly.

Highlighting in the trace :  message identity  |  addressing  |  protocol configuration options  |  routing and session parameters

Protocol discriminator = 0x7e (5GS Mobility Management)
Security header = 0x2 (Integrity protected and ciphered)
Auth code = 0x66f143b0
Sequence number = 0x03
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 = 5
  Procedure transaction identity = 9
  Message type = 0xc2 (PDU session establishment accept)
  Selected PDU session type = 0x3 (IPv4v6)
  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
  PDU address:
    PDU session type = 3 (IPv4v6)
    IPv6 = ::2001:468:3000:1
    IPv4 = 192.168.4.2
  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 = 1
      5QI = 5
  Extended protocol configuration options:
    Ext = 1
    Configuration protocol = 0
    Protocol ID = 0x000d (DNS Server IPv4 Address)
    Data = 8.8.8.8
    Protocol ID = 0x0003 (DNS Server IPv6 Address)
    Data = 2001:4860:4860:0:0:0:0:8888
    Protocol ID = 0x000c (P-CSCF IPv4 Address)
    Data = 192.168.4.1
    Protocol ID = 0x0001 (P-CSCF IPv6 Address)
    Data = 2001:468:3000:1:0:0:0:0
    Protocol ID = 0x0002 (IM CN Subsystem Signaling Flag)
    Data =
  DNN = "ims.mnc001.mcc001.gprs"
  PDU session ID = 5

What does the UE actually ask for ?

The request carries more than a wish for an address. Three of its information elements decide what the UE receives. The trace in PDU Session Establishment Request shows all three.

The first is the PDU session type. It names the address family, and it is the field that decides whether an IP address is involved at all. Two of the five values do not produce an address of any kind.

The network is not obliged to grant the type that was asked for. It answers with a Selected PDU session type, which may be narrower than the request. A UE that asks for IPv4v6 in a network offering only IPv4 receives an accept, not a reject. The accept then carries the selected type together with a 5GSM cause. Cause #50 means IPv4 only, and cause #51 means IPv6 only.

The second element is the extended protocol configuration options. This is where the UE asks for everything that is not the address itself. Each request is a container identifier with an empty payload, and the network answers with the same identifier carrying a value. The table below pairs the containers from the two traces on this page.

The third element is the DNN, which is "ims" in this trace. That single value explains most of the rest of the exchange. It is why the UE asks for P-CSCF addresses. It is also why the answering QoS flow uses 5QI 5, which is the standardised value for IMS signalling.

• PDU session type decides the address family : Unstructured and Ethernet sessions receive no IP address at all.
• The network may narrow the type : It answers with a Selected PDU session type and a 5GSM cause, rather than rejecting the request.
• The ePCO containers work in pairs : An empty container in the request is answered by the same container carrying a value in the accept.
• Container 0x000A is different : It selects NAS signalling as the allocation method instead of asking a question, so nothing is echoed back.
• The DNN explains the rest : A DNN of "ims" is why P-CSCF addresses are requested and why 5QI 5 appears in the answer.

Where does the address actually come from ?

The IPv6 value in the accept puzzled me the first time I read a trace like this one. It reads ::2001:468:3000:1. An address starting with two colons means the leading bits are all zero. That is not a strange address. It is half of one.

The two families are handled differently, and the difference is not cosmetic. For IPv4 the PDU address IE carries the complete 32-bit address. The UE can use it the moment the accept arrives, and nothing further is needed.

For IPv6 the same IE carries only a 64-bit interface identifier. The 64-bit prefix is not in the NAS message at all. It reaches the UE afterwards in an ICMPv6 Router Advertisement, on the user plane. Only then can the UE build the address it will actually use. It joins the prefix to the interface identifier it was given.

That is why the decoder shows leading zeros. It is printing an 8-octet interface identifier in the shape of a full IPv6 address. The 64 bits it does not have therefore appear as zeros. The value in the trace is the bottom half of the address and nothing more.

The source of the address is a separate question, and the UE cannot see the answer. The SMF may allocate from its own pool, or ask the UPF. It may also use an external DHCP server. A fourth option is the DN-AAA server, during secondary authentication. The NAS signalling looks identical whichever one was used. IPv4 has one further option. DHCPv4 can run on the user plane after the session is established, instead of NAS allocation.

Figure 3 sets the two families side by side, using the values from the trace in PDU Session Establishment Accept.

Figure 3. The leading colons in the IPv6 value are the whole story. Half the address is missing at that point, and it arrives on the user plane rather than in NAS.

• IPv4 arrives complete : The PDU address IE holds the full 32-bit address, and the UE needs nothing further.
• IPv6 arrives as half an address : The IE holds a 64-bit interface identifier, and the prefix is not in NAS at all.
• The prefix comes in a Router Advertisement : It travels on the user plane, so a NAS-only trace never shows the address the UE actually uses.
• Leading colons are the giveaway : A decoder printing an interface identifier as a full address shows the missing top half as zeros.
• The source is invisible to the UE : SMF pool, UPF, external DHCP or DN-AAA all produce identical NAS signalling.

What else does the Accept configure ?

I used to read this message as an address delivery. It is a complete session configuration that happens to contain an address, and most of what it carries has nothing to do with addressing.

The authorized QoS rules come first. The trace in PDU Session Establishment Accept has one rule with DQR set to 1, which marks it as the default QoS rule. Its packet filter is match-all and bidirectional, with precedence 255. That combination is what makes every packet without a more specific rule follow QoS flow 1.

The Session-AMBR sets the aggregate rate for all non-GBR flows in the session, at 3000000 kbps down and 1000000 kbps up in this trace. It is a per-session limit, and it is separate from the per-UE AMBR that the AMF holds.

The authorized QoS flow descriptions then bind the flow to a treatment. QFI 1 is mapped to 5QI 5, and 5QI 5 is the standardised value for IMS signalling. That is consistent with the DNN, and it is a useful check when reading an unfamiliar trace.

Finally the accept confirms what the network actually selected. Selected PDU session type and Selected SSC mode are both echoed, and either one may differ from what the UE asked for. Reading the request without these two fields is how people debug the wrong thing.

• The default QoS rule is identified by DQR : DQR set to 1 with a match-all filter is what catches traffic no other rule matches.
• Session-AMBR is per session : It bounds the non-GBR flows of this session only, and it is not the per-UE AMBR.
• QFI binds to 5QI : The flow description maps QFI 1 to 5QI 5, which is the standardised IMS signalling treatment.
• The selected fields are the authoritative ones : Selected PDU session type and Selected SSC mode may both differ from the request.

What does SSC mode decide about the address ?

SSC stands for Session and Service Continuity, and the trace on this page shows SSC mode 1. The mode decides whether the PDU session anchor survives. The address lasts exactly as long as the anchor does.

SSC mode 1 preserves the anchor for the life of the session. The UE keeps the same address however far it moves. That is the mode an application wants when a changing address would break it.

SSC mode 2 releases the session and asks the UE to establish a new one to the same data network. The new session gets a new anchor and a new address. There is a short interval with no session at all, which is why this mode is described as break before make.

SSC mode 3 establishes the new session before releasing the old one. For a while the UE holds two sessions and two addresses. It can therefore move its traffic across before the old one goes. The address still changes, but nothing is interrupted.

Figure 4 places the three modes on a common time line.

Figure 4. The mode is chosen per session, so the question is not what the network supports but what the application can tolerate.

• The address lives as long as the anchor : SSC mode decides the anchor, so it decides the address.
• Only mode 1 guarantees one address : The anchor is preserved for the life of the session, whatever the UE does.
• Mode 2 costs an interruption : The old session is released first, so there is an interval with no connectivity.
• Mode 3 costs a second session : Two sessions and two addresses exist together, which avoids the interruption at the cost of resources.
• The mode is per session : The network confirms it as Selected SSC mode, and it may differ from the requested one.

How does this compare with LTE ?

The opening of this page says the two procedures are similar at a high level, and they are. Setting the pieces beside each other shows where the similarity stops.

One row matters more than the others. In LTE the network establishes a default bearer during attach, so a UE that completes attach always has an address. In 5G nothing is established until the UE sends a PDU Session Establishment Request. A registered 5G UE with no address is a normal state, and not a fault to be investigated.

• The message pair maps directly : PDN Connectivity Request and Activate Default EPS Bearer Context Request become the request and accept pair.
• Registration grants nothing : There is no 5G equivalent of the default bearer, so the UE has to ask for every session it wants.
• QoS moved inside the session : Bearers became flows, identified by QFI within one PDU session.
• SSC mode has no LTE counterpart : Anchor behaviour was implicit in LTE, and it is an explicit per-session choice in 5G.

Reference

[1] 3GPP SA2 architecture and functions for 5G mobile communication system

[2] 5G beyond radio access: a flatter sliced network

[3] End to End Network Slicing