logo
Invia messaggio
Shenzhen Olax Technology CO.,Ltd
prodotti
Notizie
Casa. > Notizie >
Notizie dell'azienda 5G (NR) Terminal Supported PDU Session Types
eventi
Contatti
Contatti: Ms. Anna
Contatta ora
Spedicaci

5G (NR) Terminal Supported PDU Session Types

2026-01-23
Latest company news about 5G (NR) Terminal Supported PDU Session Types

In 5G (NR), a PDU session is a logical connection between the terminal (UE) and the data network (such as the Internet or enterprise network), responsible for data traffic transmission and supporting services such as browsing or voice (VoNR). The UE's PDU session is managed by the SMF (Session Management Function Unit) and carries traffic mapped to specific Quality of Service (QoS) streams, thereby achieving differentiated service levels. The types of PDU sessions supported by 5G (NR) terminals are defined by 3GPP in TS23.501 as follows:

 

I. UE and SMF Relationship

 

1.1 During the PDU session lifecycle, the terminal (UE) can obtain configuration information from the SMF, including:

  • The address of the P-CSCF;
  • The address of the DNS server.
  • If the UE indicates to the network that it supports (D)TLS-based DNS, and the network wishes to enforce the use of (D)TLS-based DNS, the configuration information sent by the SMF through the PCO may also include the corresponding DNS server security information specified in TS 24.501[47] and TS 33.501[29].
  • UE's GPSI.

The terminal device (UE) may obtain the MTU that the UE should consider from the SMF when the PDU session is established, as detailed in Clause 5.6.10.4.

 

1.2 During the lifecycle of the PDU session, the information that the UE may provide to the SMF includes:

  • Indicating whether P-CSCF reselection is supported, based on the procedures specified in TS 24.229[62] (Clause B.2.2.1C and L.2.2.1C).
  • UE's PS data off status.

 

----The operator may deploy NAT functionality in the network; support for NAT is not specified in Release 18.

 

II. Ethernet and PDU Sessions

 

2.1 For PDU sessions established using the Ethernet type, the SMF and the UPF acting as the PDU session anchor (PSA) can support specific behaviors related to the Ethernet frames carried by the PDU session. Depending on the operator's DNN configuration, the handling of Ethernet traffic on N6 may differ, for example:

 

  • A one-to-one configuration between the PDU session and the N6 interface may correspond to a dedicated tunnel established on N6. In this case, the UPF acting as the PSA transparently forwards Ethernet frames between the PDU session and its corresponding N6 interface, and can route downlink traffic without knowing the MAC address used by the UE.
  • Multiple PDU sessions (e.g., multiple UEs) pointing to the same DNN may correspond to the same N6 interface. In this case, the UPF acting as the PSA needs to know the MAC address used by the UE in the PDU session in order to map downlink Ethernet frames received through N6 to the corresponding PDU session. The forwarding behavior of the UPF acting as the PSA is managed by the SMF, as detailed in Clause 5.8.2.5.

----The MAC address used by the UE refers to any MAC address used by the UE or any device locally connected to the UE and communicating with the DN using a PDU session.

 

III. SMF and PSA: Depending on the operator configuration, the SMF can request the UPF, which acts as the anchor point for the PDU session, to respond to an ARP/IPv6 neighbor cell information request based on local cached information (i.e., the mapping between the UE's MAC address and IP address, and the DN to which the PDU session is connected), or redirect ARP traffic from the UPF to the SMF. ARP/IPv6 ND responses based on local cached information apply to ARP/IPv6 NDs received in both uplink and downlink (UL and DL) directions.

 

---The prerequisite for responding to ARP/NDs from the local cache is that the UE or devices behind the UE obtain their IP address through an in-band mechanism detectable by the SMF/UPF and associate the IP address with the MAC address through this mechanism.

---This mechanism aims to avoid broadcasting or multicasting ARP/IPv6 NDs to every UE.