China Shenzhen Olax Technology CO.,Ltd Company News

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.

3GPP defines three modes for UE Mobility and Service Continuity Management (SSC) in 5G (NR) systems, each with the following characteristics:   I. SSC Mode 1: For PDU sessions in this mode, the UPF used as the PDU session anchor at session establishment remains valid, regardless of the access technology (e.g., access type and cell) subsequently used by the UE to access the network. Specifically:   For PDU sessions of IPv4, IPv6, or IPv4v6 type, IP continuity is supported regardless of changes in UE mobility. In Release 18, when IPv6 multihoming or UL CL is applied to a PDU session in SSC Mode 1, and the network (based on local policies) allocates additional session anchors for that PDU session, these additional PDU session anchors may be released or allocated, and the UE does not expect to retain additional IPv6 prefixes for the lifetime of the PDU session. SSC Mode 1 can be applied to any PDU session type and any access type. UEs supporting PDU connectivity should support SSC Mode 1.   II. SSC Mode 2 If a PDU session in this mode has only one session anchor, the network can trigger the release of that PDU session and instruct the UE to immediately establish a new PDU session with the same data network. The triggering condition depends on operator policies, such as application function requests, load status, etc. When establishing a new PDU session, a new UPF can be selected as the PDU session anchor. Otherwise, if the SSC Mode 2 PDU session has multiple PDU session anchors (e.g., multi-homed PDU sessions or UL CL applied to SSC Mode 2 PDU sessions), additional PD session anchors can be released or allocated; furthermore:   SSC2 mode can be applied to any PDU session type and any access type. SSC Mode 2 is optional in the UE.   ---UEs relying on SSC Mode 2 functionality will not function if SSC Mode 2 is not supported.   ---In UL CL mode, the UE does not participate in the reallocation of PDU session anchors, therefore the UE is unaware of the existence of multiple PDU session anchors.   III. SSC Mode 3 For PDU sessions in this mode, the network allows the UE to establish a connection to the same data network through a new PDU session anchor point before the connection between the UE and the previous PDU session anchor point is released.   When the triggering conditions are met, the network decides whether to select a PDU session anchor point UPF suitable for the UE's new conditions (e.g., network access point). In Release 18, SSC Mode 3 applies only to IP PDU session types and any access type. For IPv4, IPv6, or IPv4v6 type PDU sessions, the following rules apply during PDU session anchor point changes:   a. For IPv6 type PDU sessions, a new IP prefix anchored to the new PDU session anchor point can be assigned within the same PDU session (subject to IPv6 multihoming as specified in TS23.501 5.6.4.3), or​ b. A new IP address and/or IP prefix can be assigned within the new PDU session established when the UE is triggered. After a new IP address/prefix is ​​assigned, the old IP address/prefix will be retained for a period of time, during which the UE will be informed via NAS signaling (as described in section 4.3.5.2 of TS 23.502[3]) or router announcement (as described in section 4.3.5.3 of TS 23.502[3]), after which it will be released.   If the SSC mode 3 PDU session has multiple PDU session anchors (e.g., multihomed PDU sessions or UL CL applied to SSC mode 3 PDU sessions), additional PDU session anchors can be released or assigned. Whether the UE supports SSC mode 3 is optional.   ----If the UE does not support SSC mode 3, functions that rely on SSC mode 3 will not work;

In the 5G (NR) system, QoS is the finest granularity unit for differentiating QoS (Quality of Service) in a terminal (UE)'s PDU session. Each QoS flow is identified by a unique identifier called QFI (QoS Flow ID), which is also unique within the PDU session. QoS typically includes the following parameters:   1. GFBR (Guaranteed Flow Bit Rate) Application: Applicable only to GBR and delay-critical GBR QoS flows. Function: Defines the minimum bit rate that the QoS flow can achieve when measured over an averaging window. Uplink and Downlink: Specifies the GFBR for the uplink and downlink separately.   2. MFBR (Maximum Flow Bit Rate) Application: Applicable only to GBR and delay-critical GBR QoS flows. Function: Defines the maximum bit rate that the QoS flow can achieve when measured over an averaging window. Uplink and Downlink: Specifies the MFBR for the uplink and downlink separately.   3. Session Maximum Allowed Bit Rate (Session-AMBR) Function: Defines the sum of the maximum allowed bit rates of all Non-GBR QoS flows in a specific PDU session. Execution: Managed by the User Plane Function (UPF) of the relevant PDU session.   4. Terminal (UE) Maximum Allowed Bit Rate (UE-AMBR) Function: Defines the sum of the maximum allowed bit rates of all non-GBR QoS flows of a specific UE. Execution: Managed by the serving base station.   5. Maximum Packet Loss Rate Application: Applicable only to GBR and delay-critical GBR QoS flows, and only for voice media in 3GPP specification Release 15. Function: Defines the maximum tolerable packet loss rate in the uplink and downlink.   6. Notification Control Function: Indicates whether the base station should notify the SMF if the QoS flow fails to meet its GFBR. Behavior: If the GFBR is not met, the base station will continue to try while notifying the SMF, which may reconfigure or release the QoS flow.   7. Reflective QoS Attribute (RQA) Function: Indicates whether packets in the QoS flow require the UE application to use reflective QoS, which involves learning uplink rules from the downlink pattern. Scope of application: Used for PDU sessions of IP or Ethernet data packets (not applicable to unstructured data packets).

  To ensure that the terminal's (UE) PDU session remains unchanged during mobility or network changes (handover), guaranteeing a seamless user experience, 3GPP has defined SSC (Session and Service Continuity) for 5G (NR)! Through SSC management, sessions can achieve smooth handover without service interruption, which is crucial for various applications such as VoIP, gaming, and the Internet of Things.   I. PDU SSC: The 5G (NR) system architecture defined by 3GPP supports PDU session and service continuity, meeting the various continuity requirements of different applications/services for the terminal (UE). The 5G system supports different SSC (Session and Service Continuity) modes. The SSC mode associated with a PDU session remains unchanged throughout its lifecycle.   II. SSC Modes: Currently (R18 version), there are three modes defined for SSC (Session and Service Continuity): In SSC Mode 1, the network maintains the connection service provided to the UE. For IPv4, IPv6, or IPv4v6 PDU sessions, the IP address will be retained. In SSC Mode 2, the network can release the connection service provided to the UE and release the corresponding PDU session. For IPv4, IPv6, or IPv4v6 types, the release of the PDU session will result in the release of the IP address assigned to the UE. In SSC Mode 3, changes in the user plane are visible to the UE, while the network ensures that the UE's connection is not interrupted. Before terminating the previous connection, a connection is established through a new PDU session anchor to ensure better service continuity. For IPv4, IPv6, or IPv4v6 types, in this mode, the IP address is not retained when the PDU session anchor changes. In the R18 specification version, the process of adding/removing additional PDU session anchors in PDU sessions used for local access DN is independent of the PDU session's SSC mode.   III. Mode Selection: In 5G, the SSC mode adopted by the terminal is determined by the SMF based on the SSC modes allowed in the user subscription (including the default SSC mode) and the PDU session type, and also considers the SSC mode requested by the UE if present. The operator can provide the UE with an SSC mode selection policy (SSCMSP) as part of the URSP rules (see Section 6.6.2 of TS 23.503 [45]). The UE should use the SSCMSP to determine the session type and service continuity mode associated with the UE's application or group of applications, as described in Section 6.6.2.3 of TS 23.503 [45].   If the UE does not have an SSCMSP, the SSC mode can be selected based on the UE's local configuration, as described in TS 23.503 [45] (if applicable). If the UE cannot select an SSC mode, the UE requests a PDU session without providing an SSC mode.

5G terminals support the simultaneous establishment of multiple PDU sessions; regarding the uplink in these sessions, 3GPP defines the following in TS23.501:   I. Uplink Classifier: For IPv4, IPv6, IPv4v6, or Ethernet type PDU sessions, the SMF can decide to insert an UL CL (Uplink Classifier) in the data path of the PDU session; The UL CL is a function supported by the UPF, designed to locally offload part of the traffic based on traffic filters provided by the SMF. UL CL insertion and removal are decided by the SMF and controlled by the SMF using generic N4 and UPF functions.   II. The SMF can decide to insert a UPF supporting UL CL functionality into the PDU session data path during or after PDU session establishment, and can also decide to remove a UPF supporting UL CL functionality from the PDU session data path after PDU session establishment. The SMF can include multiple UPFs supporting UL CL functionality in the PDU session data path. The UE is unaware of the traffic offloading caused by the UL CL and does not participate in the insertion and removal of the UL CL.   III. UE Handling For IPv4, IPv6, or IPv4v6 type PDU sessions, the UE associates the PDU session with a single IPv4 address, a single IPv6 prefix, or both, assigned by the network. When the UL CL function is inserted into the data path of the PDU session, the PDU session will have multiple PDU session anchors. These PDU session anchors provide different access methods to the same DN. For IPv4, IPv6, or IPv4v6 type PDU sessions, the UE only obtains one IPv4 address and/or IPv6 prefix. The SMF can configure local policies for certain (DNN, S-NSSAI) combinations so that the PDU session is released when the IPv4 address assigned to the UE is associated with a PSA and that PSA has been removed.   IV. UL CL Application: The current version only supports terminals (UEs) using one IPv4 address and/or IPv6 prefix and configuring multiple PDU session anchors, provided that appropriate mechanisms are deployed to correctly forward packets at the N6 reference point when needed. The R18 specification does not cover the mechanism for packet forwarding between the local access PDU session anchor and the DN over the N6 reference point; where: The UL CL provides forwarding of UL traffic to different PDU session anchors and merging of DL traffic to the UE, i.e., merging traffic from different PDU session anchors on the link to the UE. This is based on traffic detection and forwarding rules provided by the SMF. The UL CL applies filtering rules (e.g., checking the destination IP address/prefix of UL IP packets sent by the UE) and determines how the packets are routed. The UPF supporting the UL CL can also be controlled by the SMF to support charging traffic measurement, LI traffic replication, and bitrate enforcement (per PDU session AMBR).

I. PDU Session Anchor: In the 5G (NR) system, each PDU session for a terminal (UE) must first complete the PSA (PDU Session Anchor); this task is performed by the UPF (User Plane Function) through the N6 interface of the PDU session (acting as a gateway connecting to the external DN (Data Network)). The PSA acts as the anchor point for each data session of the terminal (UE), managing data flow and establishing connections to services such as the internet. When the UE performs multiple services, the anchor point for each session in multiple PDU sessions is defined by 3GPP in TS23.501 as follows:   II. Multiple PDU Session Anchors: To support selective traffic routing to the DN or to support   In SSC Mode 3 as defined in TS23.501 Section 5.6.9.2.3, the SMF can control the data path of the PDU session so that the PDU session can correspond to multiple N6 interfaces simultaneously. The UPF terminating each interface is called a PDU session anchor. Each PDU session anchor supporting the PDU session provides access to different DNs.   Furthermore, the PDU session anchor assigned during PDU session establishment is associated with its SSC mode, while other PDU session anchors assigned in the same PDU session (e.g., for selective traffic routing to the DN) are independent of the PDU session's SSC mode. When PCC rules containing traffic steering enforcement control information influenced by the AF as defined in TS 23.503[45] clause 6.3.1 are provided to the SMF, the SMF may decide whether to apply traffic routing based on the DNAI included in the PCC rules (by using the UL classifier function or IPv6 multi-homing).   ----The AF-influenced traffic steering enforcement control information can be determined by the PCF when requested by the AF via the NEF (as described in clause 5.6.7.1), or it can be statically pre-configured in the PCF. ----Selective traffic routing to the DN supports deployments where, for example, certain selected traffic is forwarded via the N6 interface to a DN "closer" to the AN serving the UE. This may correspond to: the UL classifier function for PDU sessions as defined in clause 5.6.4.2; the use of IPv6 multi-homing in PDU sessions as defined in clause 5.6.4.3.

The NTN (Non-Terrestrial Network) introduced by 3GPP in its standardization roadmap aims to achieve full 5G coverage and connectivity through satellites and airborne platforms. Key terminology includes:   1. NTN Definition: This is a wireless network technology approved by 3GPP, where access nodes are deployed on space-based or air-based platforms such as satellites or High Altitude Platform Stations (HAPS), rather than being fixed to ground infrastructure. NTN networks are typically used to extend coverage to areas where ground network deployment is impractical or economically unfeasible. From a 3GPP perspective, NTN is not an independent technology, but rather an extension of 5G (NR). NTN reuses and adapts NR protocols, parameters, and procedures as much as possible to support long propagation delays, high Doppler shifts, large cell sizes, and platform mobility.   2. NTN Platforms: This is the most basic classification of satellite orbits, which directly affects latency, coverage, and mobility; specifically including:   GEO (Geostationary Orbit): GEO satellites are located at an altitude of approximately 35,786 kilometers and are stationary relative to the Earth. GEO (Geosynchronous Orbit) satellites have wide coverage but high round-trip delay, making them unsuitable for latency-sensitive services. MEO (Medium Earth Orbit): MEO satellites operate at altitudes between 2,000 and 20,000 kilometers, achieving a balance between coverage and latency; this is particularly emphasized in the current 3GPP NTN specifications. LEO (Low Earth Orbit): LEO satellites operate at altitudes between 300 and 2,000 kilometers. They offer low latency and high throughput, but move very quickly relative to the Earth, leading to frequent inter-satellite handovers and significant Doppler effects. VLEO (Very Low Earth Orbit): VLEO refers to experimental satellites designed to operate at altitudes below 300 kilometers. They are expected to achieve ultra-low latency but face significant atmospheric challenges. HAPS (High Altitude Platform Station): HAPS typically operate at altitudes between 20 and 50 kilometers. HAPS platforms include: solar-powered drones, balloons, and airships. High Altitude Platform Systems (HAPS) can act as NR base stations, relays, or coverage enhancers, and compared to satellites, they have quasi-static characteristics and significantly lower latency.   3. Wireless Access (Terminology) NTN gNB: This is a 5G (NR) base station specifically modified for non-terrestrial deployment. Depending on the architecture, the NTN gNB can be fully hosted on a satellite or HAPS, partially deployed in space and partially on the ground, or entirely ground-based with the satellite acting as a relay. The functional division between space and ground is a key design choice. Transparent Payload or Bent-Pipe Architecture: In a transparent payload or bent-pipe architecture, the satellite does not perform baseband processing. This architecture aims to simplify satellite design, but its operation is highly dependent on the availability of ground infrastructure and feeder links; the transmission payload performs the following functions: Receiving radio frequency signals from user equipment (UE) Performing frequency shifting and amplification Forwarding them to the ground base station (gNB) via the feeder link Regenerative Payload: Performs part or all of Layer 1 and Layer 2 processing on the satellite. In this model, the satellite itself carries the gNB functionality. This architecture reduces feeder link latency, improves scalability, and enables localized decision-making. However, regenerative payloads increase the complexity and cost of the satellite.   4. NTN Links Service Link: Specifically refers to the wireless connection between the user equipment (UE) and the NTN platform (satellite or high-altitude platform). It uses the NR air interface waveform suitable for large cell radii and extended timing advance. Diagram of 5G NTN service link, inter-satellite link, feeder link, and ground network integration. Feeder Link: This connects the satellite to the gateway ground station, which interfaces with the 5G core network. Feeder links typically operate at higher frequencies and require high-capacity backhaul links. Inter-Satellite Link (ISL): Supports direct communication between satellites, allowing data to be routed in space without direct involvement of ground stations. ISL enhances network resilience and reduces end-to-end latency.   5. Network Architecture Gateway Earth Station: The gateway earth station acts as the interface between the satellite system and the 5G core network. It connects the feeder link and plays a crucial role in mobility and session continuity. 5GC supporting NTN: From a protocol perspective, the 5G core network (5GC) remains largely unchanged. Enhancements primarily focus on: supporting long latency, handling large cells, and optimizing processing procedures for idle and connected modes. D2D NTN (Direct-to-Device): User equipment (UE) communicates directly with satellites/high-altitude platforms (HAPS) without intermediate ground access. Hybrid NTN-TN architecture: NTN complements the terrestrial network, used for fallback, offloading, or extending coverage. Relay-based NTN: Satellites or high-altitude platforms (HAPS) act as relay nodes between user equipment (UE) and the terrestrial network.

In competitive random access, after a terminal (UE) receives a RAR message and sends a request for RRC connection establishment, whether it receives permission to establish the connection is crucial for determining the success of the competition. In the NTN scenario, the duration of the contention resolution timer presents another challenge for the terminal (UE).   I. Timer Challenges: During the RACH process, after the terminal (UE) sends the RRC connection request MSG3, it waits for the contention resolution message MSG4 to determine whether its random access attempt was successful. The duration for which the UE listens for MSG4 is controlled by the ra-ContentionResolutionTimer – this timer starts immediately after MSG3 is sent. In NTN systems, the distance between the UE and the satellite base station is much greater, resulting in significantly higher round-trip delays compared to terrestrial systems. While the maximum configurable value of the ra-ContentionResolutionTimer can theoretically cover these longer delays, this approach is inefficient and may unnecessarily consume power at the UE. NTN typically requires energy-efficient operation, especially in remote or battery-constrained applications. Therefore, the default settings of the ra-ContentionResolutionTimer must be adjusted to better accommodate NTN propagation delays while conserving UE power.   II. Potential Solution: One solution is to introduce an offset for the start of the ra-ContentionResolutionTimer in the NTN scenario. The timer would not start immediately after MSG3 transmission, but only after an offset period that accounts for the expected round-trip delay in NTN. This adjustment ensures that the timer is only active during the time period when MSG4 is expected to be received; by aligning the timer with the NTN-specific delay, the UE can avoid unnecessary monitoring during periods when MSG4 is unlikely to arrive. This saves power consumption and ensures compatibility with the longer latency of NTN. The advantages of offset-based timer adjustment include:   Power Efficiency: The UE only monitors when a message is actually likely to arrive, thus reducing unnecessary power consumption. Adaptability to Different Orbits: The offset can be configured according to the type of NTN (GEO or LEO), as the propagation delay differs significantly between these systems. Scalability: This method can adapt to NTNs of different scales and propagation delay characteristics without requiring significant modifications to the standard conflict resolution process. Robustness: Aligning the timer with the actual delay prevents the conflict resolution timer from timing out prematurely, which could otherwise lead to unnecessary retransmissions or failures in NTN communication.

  In the 5G system, the AMF is responsible not only for terminal (UE) access and mobility management, but also for processing and notifying other units about terminal (UE) service requests and data transmission. The key points of the interaction with related networks during this process are as follows:   I. The AMF is responsible for SMF selection according to the procedures described in clause 6.3.2; for this purpose, it obtains subscription data from the UDM as defined in that clause. In addition, it obtains the subscribed UE-AMBR from the UDM and, based on the operator's local policy, obtains the dynamic service network UE-AMBR (optional) from the PCF; then it sends it to the (R)AN as defined in clause 5.7.2; AMF-SMF interaction supporting LADN is defined in clause 5.6.5.   To support billing and meet regulatory requirements (NPLI (Network Provided Location Information) as defined in TS 23.228 [15]) related to IMS voice call establishment, modification and release or SMS transfer, the following provisions apply:   If the AMF possesses the UE's PEI during PDU session establishment, the AMF will provide the PEI to the SMF. When the AMF forwards UL NAS or N2 signaling to a peer NF (such as SMF or SMSF) or during PDU session UP connection activation, it will provide any user location information received from the 5G-AN, as well as the AN access type (3GPP-non 3GPP) of the received UL NAS or N2 signaling. The AMF will also provide the corresponding UE time zone. In addition, to meet regulatory requirements (i.e., providing Network Provided Location Information (NPLI) as defined in TS 23.228 [15]); when the access method is non-3GPP, if the UE is still connected to the same AMF for 3GPP access (i.e., user location information is valid), the AMF can also provide the last known 3GPP access user location information and its validity period.   II.The SMF may further provide user location information, access type, and UE time zone to the PCF. The PCF can obtain this information from the SMF to provide NPLI to applications that have requested NPLI (such as IMS). User location information may include:   For 3GPP access: Cell ID, even if the AMF receives the primary cell ID from the auxiliary RAN node in NG-RAN, the AMF only includes the primary cell ID. For untrusted non-3GPP access: The local IP address used by the UE to connect to the N3IWF, and (if NAT is detected) the UDP source port number (optional).   III.Trusted non-3GPP   For trusted non-3GPP access: TNAP/TWAP identifier, the local IP address used by the UE/N5CW device to connect to the TNGF/TWIF, and (if NAT is detected) the UDP source port number (optional). When the UE connects to the TNGF using WLAN based on IEEE 802.11 technology, the TNAP identifier should include the SSID of the access point to which the UE is connected. The TNAP identifier should include at least one of the following elements, unless otherwise specified by the TWAN operator's policy: BSSID (see IEEE Std 802.11-2012 [106]); Address information of the TNAP to which the UE is connected.   IV. The TWAP identifier should include the SSID of the access point to which the NC5W is connected; unless otherwise specified by the TWAN operator's policy, the TWAP identifier should also include at least one of the following: BSSID (see IEEE Std 802.11-2012 [106]); Address information of the TWAP to which the UE is connected.   In addition: Multiple TNAPs/TWAPs may use the same SSID, and the SSID alone may not provide location information, but may be sufficient for billing purposes. It is assumed that the BSSID associated with the TNAP/TWAP is static.   V. User location information for W-5GAN access is defined in TS 23.316 [84]. When the SMF receives a request to provide access network information report, and there are no operations required to be performed on the 5G-AN or UE (e.g., no QoS flows need to be created/updated/modified), the SMF may request user location information from the AMF. The interaction between the AMF and SMF for the insertion, relocation, or removal of the I-SMF in a PDU session is described in Section 5.34.

  In the 5G (NR) system, AMF and SMF are two independent core network functional units. They are directly connected via the N11 interface; the 5G terminal (UE) connects to them directly or indirectly through N1, N2, N3, N4, and N11 interfaces, and the information exchanged is as follows:   I. Messages exchanged with SMF via the N1 interface include: A single N1 termination point is located in the AMF; the AMF forwards SM-related NAS information to the SMF based on the PDU session ID in the NAS message. Subsequent SM NAS exchanges (e.g., SM NAS message responses) received by the AMF via access (e.g., 3GPP or non-3GPP access) are transmitted through the same access. The serving PLMN ensures that subsequent SM NAS exchanges (e.g., SM NAS message responses) received by the AMF via access (e.g., 3GPP or non-3GPP access) are transmitted through the same access. The SMF handles the session management part of the NAS signaling exchanged with the UE. The UE can only initiate PDU session establishment in the RM-REGISTERED state. When an SMF is selected to serve a specific PDU session, the AMF must ensure that all NAS signaling related to that PDU session is handled by the same SMF instance. After successful PDU session establishment, the AMF and SMF store the access type associated with that PDU session.   II. Messages exchanged with SMF via the N11 interface include: The AMF reports the UE's reachability to the SMF based on the SMF's subscription, including: location information of the UE relative to the area of interest indicated by the SMF. The SMF indicates to the AMF when the PDU session is released. After successful PDU session establishment, the AMF stores the identifier of the SMF serving the UE, and the SMF stores the identifier of the AMF serving the UE, including the AMF set. When attempting to connect to the AMF serving the UE, the SMF may need to apply the behavior described in Section 5.21 for "other CP NFs".   III​. Messages exchanged with SMF via the N2 interface include: Certain N2 signaling (e.g., handover-related signaling) may require the joint action of the AMF and SMF. In this case, the AMF is responsible for ensuring coordination between the AMF and SMF. The AMF can forward SM N2 signaling to the corresponding SMF based on the PDU session ID in the N2 signaling. The SMF should provide the PDU session type and PDU session ID to the NG-RAN so that the NG-RAN can apply the appropriate header compression mechanism to packets of different PDU types. See TS 38.413 [34] for details.   IV. N3 interface interaction messages with the SMF include: Selective activation and deactivation of existing PDU session UP connections are defined in clause 5.6.8 of TS 23.501.   V. N4 interface interaction messages with the SMF include: When the UPF learns that a UE has received downlink data but there is no downlink N3 tunnel information, the SMF will interact with the AMF to initiate a network-triggered service request procedure. In this case, if the SMF learns that the UE is unreachable, or that the UE is only reachable for regulatory priority services, and the PDU session is not for regulatory priority services, the SMF should not send a downlink data notification to the AMF;