6.2.1 What is a PDU Session?

The ‘PDU Session’ is the (new) abstraction for 5G user plane services like the concept of a Packet Data Network (PDN) connection in 4G Evolved Packet Core (EPC). A PDU Session provides connectivity between applications on a UE and a DN such as the ‘Internet’ or private corporate networks. A DN is identified by a Data Network Name (DNN) which is the equivalent of an Access Point Name (APN) in 4G EPC.

A PDU Session is associated with a single DNN and with a single slice (S‐NSSAI).

PDU Sessions can provide different types of transport services corresponding to the nature of the PDU(s) carried over the PDU Session:

• Internet Protocol (IP) type PDU Sessions offer a Layer 3 service including IP address assignment and IP flow‐based filtering and QoS. The 5GS provides the first hop router for the UE. An IP type PDU Session is expected to be the most commonly used PDU Session type for regular Internet connectivity and for operator offered services such as Internet Protocol Multimedia Subsystem (IMS) services (including voice).
  1. ∘ An IP type PDU Session may offer either an IPv4 service or an IPv6 service or the combination of an IPv4 service and of an IPv6 service.
• Ethernet (ETH) type PDU Sessions offer a Layer 2 service including layer 2 (e.g. Media Access Control [MAC] address and/or Virtual Local Area Network [VLAN]) based QoS, forwarding and filtering of frames. ETH type PDU Session are expected to be the commonly used PDU Session for industrial applications, enterprise Local Area Network (LAN) services (e.g. when 5GS is used for connectivity within an enterprise).
• Unstructured type PDU Sessions provide a fully transparent data transport service that does not make any assumptions on the payload type and data format; traffic filtering and classification are not supported in this case. Typical use of unstructured type PDU Session would be for IoT (Internet of Things) traffic targeted towards Machine to Machine (M2M) applications.

One PDU Session carries PDU(s) of a single type only: either IP or ETH or Unstructured. 5G user plane delivery must support new use cases for a variety of vertical markets including for example industrial control applications relying on very low latency (Ultra Reliable Low Latency Communication [URLLC] services) and/or demanding non‐IP connectivity services (e.g. ETH). URLLC services are defined in Section 6.3.

Other PDU Session types may be defined in future 3GPP releases.

The 5GS guarantees that applications on the DN and traffic forwarding on the DN are not bothered by UE mobility. For this purpose, the 5GC delivers and receives traffic of a PDU Session to and from the DNs via interfaces called N6 terminated on a User Plane Function (UPF) said to support a PDU Session Anchor (PSA) functionality (Figure 6.1).

The User Plane of PDU Sessions is supported by the Fifth Generation Access Network (5G‐AN, e.g. the Fifth Generation Radio Access Network [5G‐RAN] or the Non‐3GPP Interworking Function (N3IWF) in case of Un‐Trusted Non Third Generation Partnership Project [3GPP] access defined in Section 4.12) and by UPFs in the 5G Core. There can be multiple UPFs supported for a single PDU Session. An UPF that supports a PSA functionality interfaces with the DN via N6. At least one UPF is expected to act as a PSA for a given PDU Session.

3GPP Rel‐15 specifications support service continuity for a PDU Session when the UE moves:

1. – within 3GPP access (within a Next Generation Radio Access Network [NG‐RAN] and between NG‐RAN(s)),
2. – between 3GPP and non‐3GPP access to the 5G Core,
3. – between the 5GC and the 4G EPC.

This implies that seamless service continuity is offered for the PDU Sessions for a given UE (i.e. from an end user perspective, application continues to work without service disruption) when mobility occurs as mentioned above.

Whether a PDU Session may use 3GPP access or non‐3GPP access or both is defined by policies configured by the operator in the UE.

In release 15 version of 3GPP specifications, a PDU Session cannot simultaneously use a 3GPP and a non‐3GPP Access.

A UE may simultaneously establish multiple PDU Sessions (e.g. corresponding to different PDU types or to different devices within the UE). In that case the User Plane and the Control Plane of these PDU Sessions may be totally disjointed in the 5G Core (even though these PDU Sessions target the same DN).

SMF (Session Management Function) is the 5GC Control Plane Function responsible for establishing/maintaining the PDU Sessions (Figure 6.2). 5GC specifications define a generic UPF with capabilities that can be programmed by the SMF allowing flexibility for the deployment of 5G user plane features. UPF(s) may be geographically distributed or centralized.

The SMF (5GC CP) controls the UPF via the N4 interface.

6.2.2 Multiple Concurrent Access to the Same Data Network

End‐to-End (E2E) network latency depends on multiple factors such as the air interface latency, packet switching and transport latency as well as processing of data flows in UPFs of the core. As air interface latencies are reduced to sub‐millisecond level in 5G, propagation delay caused by the speed of light in the backhaul (i.e. optical fibre) is becoming the limiting factor. This leads to the need to distribute UPFs as well as application services to locations that are topologically and physically closer to the end user device.

In 5GS, the UE can obtain services simultaneously from local/central access to the same DN. This allows the UE to obtain fast access to content/applications deployed locally but at the same time have access to any central server for all other content/applications: as opposed to 4G EPC where a PDN connection corresponds to a single interface to the DN, a 5GC PDU Session may support multiple PSAs and have multiple interfaces to the DN. The local access allows the end user enjoying application access with very low latency. The central access allows access to any application without service disruption due to mobility. This is to deal with the fact that due to specific application requirements (e.g. on end to end latency as for Augmented Reality) and due to network optimizations (e.g. for content caching in a content delivery network (CDN) for popular videos), different flows exchanged over a PDU Session may need to reach the DN at different locations (at different PSAs), some close to the UE and some more central.

Enabling seamless service continuity in a distributed network with full mobility required a major redesign of the 5G user plane.

Figure 6.3 shows a PDU Session example that illustrates key enhancements of 5G user plane capabilities. In this example, a 5G UE is concurrently served from different network locations (‘Data Centers’) hosting core network UPFs and cloud applications:

1. A local serving location selected to be near to the 5G UE, hosting low latency applications (like video caching and Augmented Reality) and a UPF acting as a temporary mobility anchor towards the access network. The local serving location may change when the UE is leaving the serving area of the ‘local Data Center’, and the challenge is to maintain service continuity during that change.
2. A central serving location providing a stable PDU Session termination for applications that do not tolerate changes of IP addresses, e.g. services like IMS voice. A central IP anchor is optional and would not be established in all cases.
3. A previous local serving location. Service continuity may require an application instance in the previous local serving location to be reachable on a temporary basis, until application‐specific state and context information have been transferred to the new local serving location or until the application usage is over (in case the application does not support mobility). This allows the decoupling of application‐level mobility from changes in primary serving locations (see Section 4.8 on Multi‐Access Edge Computing [MEC]).

The example shows that a PDU Session may be configured to comprise multiple UPF typically arranged in a hub‐and‐spoke topology. The local serving location is hosting the hub UPF which acts as a branching point forwarding traffic flows to local applications or to other UPFs (acting as the spoke), e.g. connected to central applications. 3GPP has defined two User Plane solution architectures for controlling packet forwarding behaviour in the hub UPF:

1. (1) Uplink Classifier (UL CL) model (Figure 6.4) – With this model, an UPF supporting UL CL functionality can be inserted into the data stream to divert UL traffic matching destination‐based filter rules. The UE is unaware of the existence of the UL CL and has a single network layer source address (e.g. IPv4 or IPv6 address). UL Forwarding rules (in the UL CL) that are based on the destination‐based filter rules ensure that UL traffic is sent via the correct PSA. When an UL CL is used, DL traffic from the DN (e.g. the Internet) is expected to be received via a PSA connected to the DN in the central serving location. Techniques like IP address translation (NAT) or local forced forwarding (tunnelling) may be used to ensure that DL traffic from local applications is sent via the PSA connected to the DN in the local serving location.

   DL traffic received from all serving locations is sent by the UL CL towards the Access Network serving the PDU Session.

2. (2) Multi‐homing – IPv6 multi‐homing (Figure 6.5) is an alternative concept for IPv6 PDU Sessions with multiple IP anchors. It is based on multi‐homing as defined in Request for Comments (RFC) 7157 [1]. The UE is assigned separate IPv6 prefixes for each PSA and needs to select one of those source prefixes based on address selection policies provided by the network as described in RFC 4191 [2]. A PDU Session with multi‐homing capability requires an UPF that acts as a Branching Point UPF. The Branching Point UPF has UL forwarding rules associating each source IP prefix with a PSA. This solution depends on UE support for IPv6 multi‐homing.

   DL traffic received from all serving locations is sent by the Branching Point towards the Access Network serving the PDU Session.

IPv6 multi‐homing can be employed in two scenarios:

1. 1) Multi‐homing as a permanent condition: a single PDU Session provides access to a local and to a centralized DN.
2. 2) Multi‐homing as a transient condition: this leverages IPv6 multi‐homing for changing of PSA due to UE mobility while ensuring there is no service delivery gap: IPv6 Multi‐homing allows a UE to send and receive data traffic via two PSAs simultaneously. This supports Session and Service Continuity (SSC) mode 3 defined in Section 6.2.3.

6.2.3 Support of SSC (Session and Service Continuity) Modes

When the UE moves it may be needed to change the PSA (i.e. interface to the DN) of a PDU Session. This change of PSA may be due to one of the following reasons:

1. – To ensure an end to end data transfer delay compatible with QoS requirements on the PDU Session.
2. – To optimize the backhaul resources of the network.

Changing the PSA may induce a change of IP address to be used by the UE on the PDU Session. Some applications like voice may not tolerate a change of IP address on the PDU Session while others may recover from a change of IP address or even recover from a small gap of IP connectivity.

Thus, 3GPP has defined different SSC modes to tackle this diversity of requirements about the loss of the UE IP address and the loss of IP connectivity.

5GS specifications support a wide range of SSC modes for PDU Sessions:

1. – For a PDU Session of SSC mode 1, the UPF acting as PSA at the establishment of the PDU Session is maintained regardless of the access technology (e.g. Access Type and cells) a UE is using to access the network. In case of a PDU Session of IP type, IP address continuity is supported regardless of UE mobility events. SSC mode 1 is well suited for applications like voice that are sensitive to the loss of IP address.
2. – For a PSA of SSC mode 2, the network may release the PSA when the UE mobility induces that a more optimum PSA should be allocated to the UE. In case of a PDU Session of IP type, the IP address/prefix corresponding to the released PSA is released. If the released PSA was the last remaining PSA for the given PDU Session, the PDU Session is released and the UE is ‘invited’ to request a new PDU Session (‘break before make’ mobility). SSC mode 2 is well suited for applications that can cope with the temporary loss of IP connectivity (e.g. mail programs or browsers).
3. – For PDU Session of SSC mode 3, the network allows the establishment of UE connectivity via a new PSA to the same DN before connectivity between the UE and the previous PSA is released (‘make before break’ mobility). This enables support for seamless service continuity when the UE mobility induces that a more optimum PSA should be allocated to the PDU Session. SSC mode 3 is well suited for applications that can cope with a change of IP address/Prefix while they cannot cope with a temporary loss of IP connectivity: for example, a video player may finish to get the current video chunk via the previous PSA while it will use the new PSA to get the next video chunks.

The support of SSC modes is documented in 3GPP TS 23.501 [3] section 5.6.9 and in 3GPP TS 23.502 [4] section 4.3.5.

6.2.4 Support of PDU Sessions Available/Authorized Only in Some Location (LADN)

5GS specifications support the concept of PDU Sessions available/authorized only in a set of locations called LADN (Local Area Data Network) service area. LADN may be used for applications that are only valid in some areas, for example a dedicated Augmented Reality application that is only available in a sport stadium.

LADN may be used e.g. to limit the access to some DNN(s) in the corresponding ‘LADN service area’:

1. – Tracking Areas serving the corporate premises for a corporate DNN; and
2. – Tracking Areas serving a ‘stadium’ for a DNN associated with applications dedicated to people participating to an event in the ‘stadium’.

A LADN service area is defined as a set of Tracking Areas. In 3GPP Rel‐15, LADNs apply only to 3GPP accesses.

For DNN subject to LADN restrictions, the LADN service area is configured in the Access and Mobility Management Function (AMF) on a per DNN basis, i.e. for different UEs accessing the same LADN, the configured LADN service area is the same. The AMF provides the UE with information on the LADN service area.

When the UE is out of the LADN service area of a DNN subject to LADN restrictions, the UE:

1. – shall not establish/modify a PDU Session for this DNN; and
2. – shall not request activation of the User Plane connection of a PDU Session for this DNN.

The support of LADN is documented in 3GPP TS 23.501 [3] section 5.6.5.

6.2.5 Data Network Authentication and Authorization of PDU Sessions

At the establishment of a PDU Session to a DNN subject to DN authentication/authorization, the DN‐specific identity of a UE may be authenticated/authorized by a Data Network Authentication, Authorization and Accounting DN‐AAA server (which is generally not operated by the Public Land Mobile Network [PLMN]). The DN‐AAA server may belong to the 5G operator or to the DN owner (e.g. to an external provider).

This allows the DN owner (especially when it is an external provider) to control who enters the DN as well as to provide policies (for example, on the allowed throughput or on the allowed MAC addresses) restricting the access to the DN. This feature may be used for a PDU Session allowing access to a corporate network enabling the manager of the corporate network to control access to this network. This may be a requirement when the corporate network supports control of industrial processes (automated factories).

DN authentication/authorization of PDU Sessions works as follows:

1. – At the establishment of a PDU Session, if the SMF determines that authentication/authorization of the PDU Session establishment is required, the SMF triggers the authentication/authorization of the UE from the configured DN‐AAA server. This is controlled by SMF policies associated with the DNN.
2. – The DN‐AAA server may authenticate the PDU Session establishment. The SMF supports this UE authentication by relaying Extensible Authentication Protocol (EAP) exchanges between UE (via NAS SM signalling exchanged with the UE) and DN‐AAA Server (via AAA signalling exchanged with the DN-AAA server).
3. – When DN‐AAA server authorizes the PDU Session establishment, it may send to the SMF DN authorization data for the established PDU Session. The DN authorization data for the established PDU Session may include one or more of the following:
   1. • a reference to locally configured authorization data in the SMF;
   2. • a DN profile index to retrieve the SM or QoS policy from the Policy Control Function (PCF);
   3. • a list of allowed MAC addresses for the PDU Session; this may apply only for PDU Sessions of ETH PDU Session type; and
   4. • the PDU Session Aggregate Maximum Bit Rate (Session AMBR) (as defined in Section 6.4.4).
4. The DN‐AAA server may request receipt of information associating the UE identifier (Generic Public Subscription Identifier – GPSI) with the IP address(es) of the UE and/or with actual N6 traffic routing information to be used to reach the UE on the PDU Session; this information may be used by applications in the DN to communicate with the UE.

DN authentication/authorization of PDU Sessions is documented in 3GPP TS 23.501 [3] section 5.6.6 and in 3GPP TS 23.502 [4] section 4.3.2.3.

6.2.6 Allocation of IPv4 Address and IPv6 Prefix to PDU Sessions

A UE may correspond to a smartphone where the 3GPP layer (‘the modem’), the ‘Transmission Control Protocol (TCP)/Internet Protocol (IP) stack’ and the applications are in a single piece of equipment.

A UE may also be made up of different entities such as:

1. – A smartphone containing the 3GPP layer (‘the modem’); and
2. – Other devices like PC(s) containing the ‘TCP/IP stack’ and the applications but not supporting 3GPP technology.

In this latter case the UE needs to receive its IP addressing information via non 3GPP methods like Dynamic Host Configuration Protocol (DHCP), see [5].

For PDU Sessions associated with IPv4 (IPv4 or IPv4v6 PDU Session type), the 5GS may deliver the (unique) IPv4 address associated with the PDU Session using:

1. – NAS (N1) SM signalling. The IPv4 address associated with the PDU Session is provided to the UE within the dedicated 3GPP signalling indicating that the network accepts the establishment of the PDU Session,
2. – DHCPv4. When the UE indicates its willingness to have ‘deferred IPv4 address allocation’, no IPv4 address is provided to the UE within the dedicated 3GPP signalling indicating that the network accepts the establishment of the PDU Session. Once the PDU Session establishment is accepted, the UE (for example a PC behind a smartphone) is sending DHCPv4 [5] signalling in the User Plane to get the IPv4 address associated with the PDU Session.

For PDU Sessions associated with IPv6 (IPv6 or IPv4v6 PDU Session type), the 5GS may deliver the (possibly not unique) IPv6 Prefix associated with the PDU Session using SLAAC (IPv6 Stateless Address Autoconfiguration as defined in [6]):

1. – No IPv6 Prefix is provided to the UE within the dedicated 3GPP signalling indicating that the network accepts the establishment of the PDU Session. Once the PDU Session establishment is accepted, the network sends a Router Advertisement in the User Plane providing an IPv6 Prefix associated with the PDU Session
2. – When a new Prefix is allocated to a PDU Session supporting IPv6 multi‐homing (as defined in Section 6.2.2), the network sends a Router Advertisement in the User Plane providing the new IPv6 Prefix associated with the PDU Session.

Other IP addressing allocation mechanisms will be defined in 3GPP Release 16 to support the specific requirements of Wireline access.

6.2.7 Support of PDU Sessions When Roaming

When the UE is roaming, its access is served by a Visited Public Land Mobile Network (VPLMN) that is different from its Home Public Land Mobile Network (HPLMN) (or different from a PLMN equivalent to its HPLMN).

In the case of roaming, the HPLMN may control whether for a PDU Session the access to the DN (the PSA) is located:

1. – In the VPLMN: this is called a LBO (Local Breakout) roaming mode.
2. – In the HPLMN: this is called a HR (Home Routed) roaming mode.

In HR mode (Figure 6.6) the HPLMN keeps control on the PSA, i.e. on the (N6) connectivity service of the PDU Session and on the corresponding Policy control; the VPLMN does not need to be aware of the specific data services provided on the PDU Session and the VPLMN responsibility is restricted to ensuring proper QoS, supporting the handovers, and handling the transitions between UP active and UP non‐active state for the PDU Session.

The HR mode is well suited to cases where the HPLMN is providing specific data services to the users of a DN (for example, corporate Virtual Private Network [VPN]).

In LBO mode (Figure 6.7) the VPLMN has full control over the PDU Session including the PSA (on the N6 connectivity service of the PDU Session) and on the corresponding Policy control.

Different PDU Sessions of the same UE may be established in different modes (LBO or HR). Subscription data tell the VPLMN on a per DNN and slice (S‐NSSAI) basis whether the corresponding PDU Session may be established in LBO mode or in HR mode. The HPLMN may allow LBO usage for some (‘friendly’, e.g. belonging to the same operator group) VPLMN(s) while it only allows HR for other VPLMN(s).

6.2.8 Summary of the UPF Topology Options

As seen throughout this chapter, the user plane framework in 5GS offers a wide range of topology options. Figure 6.8 illustrates this fact:

• Centralized UPF. For long term stable IP address assignment;
• Cascaded UPF. For Multiple concurrent (e.g. local/central) access to the same DN (Section 6.2.2) or for HR roaming (Section 6.2.7); and
• Parallel UPF. Transient usage of two PSA within a PDU Session at UE mobility (when the UE supports IPv6 multi‐homing).

6.4.1 What is a QoS Flow?

The 5G QoS model is based on QoS Flows. The QoS Flow is the finest granularity of QoS differentiation in a PDU Session. All PDU(s) within a QoS flow are given the same treatment as far as QoS is concerned (e.g. scheduling, admission control, PDU discard, etc.). Different PDU(s) within a QoS flow may nevertheless be charged differently due to different tariff plans or to an external entity subsidizing some flows, e.g. related with advertisements.

A QoS flow associates a QoS profile with a set of PDU(s) identified by traffic filters.

The 5G QoS model supports both QoS Flows which require Guaranteed Flow Bit Rate (GFBR) (‘GFBR’ QoS Flows) and also QoS Flows which do not require GFBR (‘non‐GBR’ QoS Flows). A Guaranteed Bitrate (GBR) QoS Flow may be further qualified as delay critical GBR when end to end latency requirements are very tight (a PDU delayed more than the PDU Delay Budget is counted as lost if the transmitted data burst is less than the Maximum Data Burst Volume allowed within the period of PDU Delay Budget). GBR QoS Flows are typically used to support IMS voice service. Delay critical GBR may also be used to support industrial control applications that need support for low latency and ultra‐high reliability.

The 5G QoS model also supports reflective QoS where the UE is required to reflect (i.e. mirror) the QoS for UL traffic based on the QoS applied for the DL traffic (see Section 6.4.3).

A QoS Flow Identifier (QFI) is used to identify a QoS Flow in the 5GS. The QFI is a scalar and is carried in an encapsulation header between the UPF and the 5G‐AN (and between UPF(s)), i.e. without any changes to the e2e PDU header. QFI are used for all PDU Session Types. The QFI is unique within a PDU Session.

5GS QoS mechanism is documented in 3GPP TS 23.501 [3] section 5.7. Policy control related with QoS enforcement is documented in 3GPP TS 23.503 [7] section 4.3.

Figure 6.9 illustrates the 5G QoS framework:

6.4.2 QoS Parameters Handled in 5G System

A QoS Flow is characterized by:

1. – A QoS profile that defines the QoS parameters applied to the QoS flow;
2. – One or more QoS rule(s) which correspond to traffic filters associating PDU(s) to a QoS Flow.

The QoS profile of a QoS Flow contains following QoS parameters:

1. – A 5G QoS Identifier (5QI):
   1. • A 5QI is a scalar that is used as a reference to 5G QoS characteristics, i.e. access node‐specific parameters that control QoS forwarding treatment for the QoS Flow (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.).
   2. • Standardized 5QI values have one‐to‐one mapping to a standardized combination of 5G QoS characteristics as specified in 23.501 [3] Table 5.7.4‐1.
   3. • The 5G QoS characteristics for pre‐configured 5QI values are pre‐configured in the 5G‐AN. The 5G QoS characteristics for dynamically assigned 5QI values are signalled as part of the QoS profile.
   4. • Standardized or pre‐configured 5G QoS characteristics, are indicated through the 5QI value, and the default values are not signalled on any interface. 5GS provides means to override some QoS characteristics.
2. – An Allocation and Retention Priority (ARP):
   1. • The ARP contains information about the priority level, the pre‐emption capability and the pre‐emption vulnerability of the QoS Flow and is used to decide whether a new QoS Flow may be accepted or needs to be rejected in case of resource limitations (typically used for admission control of GBR traffic).
3. – For each Non‐GBR QoS Flow, the QoS profile may also include a Reflective QoS Attribute (RQA) which indicates that certain traffic (not necessarily all) carried on this QoS Flow may be subject to Reflective QoS.
4. – For each GBR QoS Flow, the QoS profile also includes:
   1. • GFBR – UL and DL;
   2. • Maximum Flow Bit Rate (MFBR) – UL and DL;
5. – In case of a GBR QoS Flow only, the QoS parameters may also include:
   1. • Notification control that indicates whether notifications are requested from the 5G‐AN when the GFBR can no longer (or can again) be fulfilled for a QoS Flow.
   2. • Maximum Packet Loss Rate – UL and DL.

Each QoS profile has one corresponding QoS Flow identifier (QFI), which is not included in the QoS profile itself.

Standardized 5QI values and their corresponding QoS characteristics as specified in 23.501 [3] Table 5.7.4‐1 support a wide range of different traffic types/services:

1. – Very stringent combinations of delay (sub 10 ms end to end delay) and PDU loss rate (e.g. 10⁻⁵) for services like Intelligent Transport Systems, Remote Control of industrial processes, etc.
2. – Low delay (50–150 ms) but higher acceptable PDU loss rate for conversational Voice/Video (Live Streaming); Different scheduling priorities and delays are defined for Mission Critical (firemen, etc.) and for regular voice services.
3. – Higher delay (300 ms) for web based, e.g. TCP‐based applications like www, e‐mail, chat, ftp, p2p file sharing, progressive video, etc. Different scheduling priorities are defined to support user/traffic differentiation.

6.4.3 Reflective QoS

As the name implies, Reflective QoS is to enable UEs to ‘reflect’ (i.e. mirror) the QoS for the UL traffic based on the QoS applied for the DL traffic. It allows support for symmetric QoS in the UL and DL.

Reflective QoS activated by the UPF enables the UE to map UL User Plane traffic, IP flows, to appropriate QoS Flows using implicitly derived (also referred to as UE derived) QoS rules (without using SMF signalled QoS rules via N1 signalling). Reflective QoS activated by the RAN enables the UE to map UL QoS Flows to appropriate DRBs.

This saves N1 signalling especially in case of very dynamic usage of IP flows by some applications requiring a specific QoS (e.g. in case of Internet browsing, TFTs (Traffic Flow Templates) may change so rapidly that it is impossible to perform signalling for every new TFT). This is achieved by the UE creating derived QoS rules (also referred to as implicitly derived QoS rules) based on the received DL traffic when reflective QoS is indicated by the 5GS for this DL traffic. When Reflective QoS is activated by the UPF, the UE shall use the derived QoS rules to determine mapping of UL traffic to QoS Flows. When the Reflective QoS is activated by the RAN, the UE shall use the derived QoS rules to determine mapping of UL QoS Flows to appropriate DRBs.

Reflective QoS is controlled by the 5GC (Figure 6.10) on per‐packet basis by using the Reflective QoS Indication (RQI). The RQI is provided by the UPF in DL traffic together with the QFI in the (GTP‐u) encapsulation header on N3 and then propagated by the 5G‐AN on the interface with the UE.

Reflective QoS applies only for IP PDU Sessions and ETH PDU Sessions. It is possible to apply reflective QoS and non‐reflective QoS concurrently within the same PDU Session.

The UE shall indicate whether it supports reflective QoS to the network (i.e. SMF) during the PDU Session establishment.

6.4.4 QoS Enforcement and Rate Limitation

The amount of traffic flowing through the 5GS for an UE is limited by

1. – Subscription for non‐GBR traffic; this corresponds to AMBRs: Session‐AMBR and User Equipment Aggregate Maximum Bit Rate (UE‐AMBR);
2. – The GFBR – UL and DL – negotiated at the establishment of a GBR QoS flow;
3. – Service Level Agreements (SLA) between the HPLMN and the VPLMN in case of roaming.

Each PDU Session is associated with a per Session‐AMBR. The Session‐AMBR limits the aggregate bit rate that can be expected to be provided across all Non‐GBR QoS Flows for a specific PDU Session.

The subscribed Session‐AMBR is a subscription parameter which is retrieved by the SMF from the Unified Data Management (UDM).

The SMF may use the subscribed Session‐AMBR or modify it based on local policies or use the authorized Session‐AMBR received from PCF to determine the Session‐AMBR to be applied to the PDU Session. The Session‐AMBR to be applied to the PDU Session is signalled to the appropriate UPF(s), to the UE and to the 5G‐AN (to enable the calculation of the UE‐AMBR).

The Session‐AMBR is measured over an AMBR averaging window which is a standardized value. In downlink direction, the Session‐AMBR is enforced by the UPF. In uplink, the Session‐AMBR is enforced by both the UE and the UPF.

Each UE is associated with a per UE‐AMBR.

The UE‐AMBR limits the aggregate bit rate that can be expected to be provided across all Non‐GBR QoS Flows of all PDU Sessions of a UE. Each 5G‐AN shall set the UE‐AMBR policed value to the sum of the Session‐AMBR values of all PDU Sessions with active user plane to this AN up to the value of the subscribed UE‐AMBR. The subscribed UE‐AMBR is a subscription parameter which is retrieved from UDM and provided to the 5G‐AN by the AMF. The UE‐AMBR is measured over an AMBR averaging window which is a standardized value. The UE‐AMBR is not applicable to GBR QoS Flows. The 5G‐AN enforces the UE‐AMBR in both downlink and uplink.

6.4.5 QoS Control within 5GS

Within the 5GS, QoS Flows are controlled by the SMF, possibly enforcing policies received from the PCF and subscription information received from the UDM.

QoS profiles

1. – may either correspond to preconfigured QoS characteristics values in the 5G‐AN; in this case, there is no need of any signalling with the 5G‐AN to establish or release the corresponding QoS flows. This provides great flexibility to use many different QoS flows within a PDU Session. or
2. – may be dynamically established by the SMF in the 5G‐AN (via the AMF) over the N2 reference point. The SMF may fine tune the 5G‐AN delay requirements (referred to as 5G‐AN part of the PDB – Packet Delay Budget) based on the transport delays between the DN and the 5G‐AN; when transport delay requirements are low, bigger buffering time is available for the RAN thus enabling the RAN to optimize its resources.

QoS rule(s) may be provided by the SMF to the UE (via the AMF) using SM related signalling (PDU Session creation/modification) over the N1 reference point and/or may be derived by the UE by applying reflective QoS.

Rules provided by the SMF to the UPF over N4 may associate traffic filters with:

1. – A QFI setting, associating the PDU matching a traffic filter to a QoS Flow.
2. – A RQI when Reflective QoS is applied to this traffic.
3. – Transport (DiffServ Code Point [DSCP]) QoS setting determined based on the 5QI and ARP of the traffic.
4. – Usage monitoring (e.g. for charging) requests.
5. – Traffic gating.

This is further defined in Section 6.8.

6.4.6 Delay Critical GBR QoS Flows and Their Characteristics

To support applications with requirements for ultra‐high reliable and low latency communications, GBR QoS flows of resource type ‘delay critical GBR’ were introduced. When there is a need to transmit packets with a latency in the order of 1–10 ms and to support reliability in the order of 10⁻⁵, it was essential also to define the largest amount of data that the 5G‐AN is required to transmit within a period of the 5G‐AN PDB (i.e. the 5G‐AN part of the Packet Delay Budget (PDB)). This is referred to as Maximum Data Burst Volume. Each Delay Critical GBR QoS flow is associated with a Maximum Data Burst Volume. The Maximum Data Burst Volume may be signalled with 5QIs to the (R)AN, and if it is not signalled, default values apply for standardized 5QIs QoS characteristics.

For delay critical GBR QoS flows, a packet delayed more than the PDB is counted as lost if the transmitted data burst is less than Maximum Data Burst Volume within the period of PDB and the data rate for the QoS flow is not exceeding the GFBR. The PER (Packet Error Rate) also defines a target for reliability for the latency target set by the PDB.

Table 6.1 shows the delay critical 5QI values and the QoS characteristics:

6.4.7 Packet Filter Set

The Packet Filter Set is used in the QoS rules to identify one or more packet (IP or ETH) flow(s).

The Packet Filter Set may contain one or more Packet Filter(s). Every packet filter can be made applicable for the DL direction only, the UL direction only or both directions.

Packet Filter Sets can be of two types: IP Packet Filter Set and ETH Packet Filter Set, corresponding to those PDU Session Types.

For IP PDU Session type, the Packet Filter Set allows packet filtering based on a combination of the following aspects:

1. – Source/destination IP address or IPv6 prefix
2. – Source/destination port number
3. – Protocol ID of the protocol above IP/Next header type
4. – Type of Service (TOS) (IPv4)/Traffic class (IPv6) and Mask
5. – Flow Label (IPv6)
6. – Security Parameter Index (SPI)
7. – Packet Filter direction.

For ETH PDU Session type, the Packet Filter Set allows packet filtering based on a combination of the following aspects:

1. – Source/destination MAC address
2. – Ethertype as defined in IEEE 802.3
3. – Customer‐VLAN tag (C‐TAG) and/or Service‐VLAN tag (S‐TAG) VLAN Identifier (VID) fields as defined in IEEE 802.1Q
4. – C‐TAG and/or S‐TAG Priority Code Point (PCP)/Drop Eligible Indicator (DEI) fields as defined in IEEE 802.1Q
5. – IP Packet Filter Set, in the case that Ethertype indicates IPv4/IPv6 payload
6. – Packet Filter direction.

6.6.1 Overview

The PCF can send dynamically derived policies to the SMF; these policies may target:

1. – Either the PDU Session or
2. – a Service Data flow (SDF). An SDF refers to a set of PDU(s) (within a PDU Session) identified by traffic filters that are to be handled the same way in any dimension (QoS, charging, forwarding, gating, etc.).

Conversely the PCF may receive information from the SMF about the status of the PDU Session, e.g. information on the Access Type and the RAT Type, the roaming situation, the IP address/IPv6 prefix(es) allocated to the PDU Session, etc. This information can influence dynamic policies derived by the PCF.

The PCF is an optional function of the 5GC. Whether PCF control is applied to a PDU Session is defined by SMF policies based on the DNN and slice. When PCF control does not apply, locally configured SMF policies apply to the PDU Session (local policy rule‐based control of the PDU Session).

PDU Sessions supporting IMS voice and emergency services are meant to support PCF control, allowing the IMS to request GBR QoS Flows via the PCF.

Policy control related with PDU Sessions and QoS enforcement is documented in 3GPP TS 23.503 [7] section 4.3.

6.6.2 Application Impact on UP Traffic Routing

Supporting necessary enablers for MEC is a key driver for 5GS (see Section 4.8 on MEC). How SMF and UPF enable support for MEC is defined in this section.

One of the key features of 5GS is to facilitate the deployment of UPF that provides the most optimum UP path between the UE (or the 5G‐AN currently serving the UE) and ‘critical’ applications deployed at the edge of the network. There are different cases leading to an application being identified as ‘critical’, e.g.:

1. – The application has strict UP latency requirements (industrial control and Virtual Reality are typical examples).
2. – The application requires a big DL throughput while content caching at the edge may dramatically reduce the transmission cost for the operator and greatly improve end user experience (content caching for popular videos is an example).
3. – The application is used by a crowd of people located at the same place (stadium).
4. – Placing the application at the edge dramatically reduces the amount of data sent UL within the network (e.g. the application at the edge reports to a central server only when it has detected some configured pattern in a video: video surveillance).

Locating an UPF geographically ‘close’ to where the 5G‐AN (radio site) of the UE is located and ‘close’ to where such applications have been deployed is thus a requirement in 5GS. UPF selection is further defined in Section 6.7.3.

But applications located at the edge will not handle all traffic as the biggest number of applications will remain reachable via central access to the DN (e.g. Internet). So, it should be possible to configure the local UPF so that it knows (i) which traffic is to be routed to local applications and (ii) which traffic is to be sent centrally (possibly to a central UPF as defined in Section 6.2.2). Furthermore, the UPF needs to be configured how (e.g. on which tunnel) traffic is to be routed to a given local application instance.

Some applications may support application mobility while other applications may not support application mobility. Support for application mobility implies that another instance of the application can be selected to serve the UE once the UE has moved beyond the serving area of the current application instance.

For applications that support mobility between application instances, the SMF needs to notify the application environment when a new local application instance is to be used. For applications known not supporting mobility, the SMF needs to ensure that despite of the mobility of a UE, the traffic can be exchanged with the same application instance if the application is running on the UE.

All points listed up to now show that the SMF needs some configuration to properly support local applications and MEC (see Section 4.6). Thus, the application controller (MEC system management), which is called an Application Function (AF) in 3GPP terminology, can issue requests to the 5GC that may contain:

1. (1) Information to identify traffic to be forwarded to a local application instance. The traffic can be identified in the AF request by:
   1. – Either a DNN and possibly slicing information (S‐NSSAI) or an AF‐Service‐Identifier
      1. • When the AF provides an AF‐Service‐Identifier, i.e. an identifier of the service on behalf of which the AF is issuing the request, the 5G Core maps this identifier to a target DNN and slicing information (S‐NSSAI).
   2. – An application identifier or traffic filtering information (e.g. 5‐Tuple). The application identifier refers to an application handling UP traffic and is used by the UPF to detect the traffic of the application.
2. (2) Information on how to route locally traffic identified in bullet (1) above.
3. (3) Potential locations of applications towards which the traffic routing should apply. The potential location of applications is expressed as a list of Data Network Access Identifier(s) DNAI(s). This should be used as a guideline for SMF selection of a local UPF. This information is determined by the AF based on its knowledge of where (which Data Centers) application instances have been deployed (one of the roles of the MEC Controller is to manage instantiation of local instances of applications).
4. (4) Information on the target UE(s). This may correspond to:
   1. – Individual UEs identified using a GPSI which is a public identifier (like a Mobile Subscriber Integrated Services Digital Network [MSISDN]), or an IP address/Prefix;
   2. – Groups of UEs identified by a Group Identifier;
   3. – Any UE: the request applies to any UE accessing the combination of DNN, and slice (S‐NSSAI).
5. (5) Indication that for the traffic related with an application, no DNAI change shall take place once selected for this application (the application does not support mobility);
6. (6) Temporal validity condition.

The AF sends its request to the PCF directly or via the NEF. When the AF request targets any UE or a group of UE(s), the AF request shall be sent via the NEF. In that case the AF request is likely to influence multiple PDU Sessions served by multiple SMFs and PCFs.

If the AF request is sent via NEF, the NEF may

1. – Validate the AF request
2. – Provides mapping between information from the AF and internal 5GS information (DNN, S‐NSSAI, etc.)
3. – Determine the relevant PCF when the request targets an individual UE
4. – Store the requests in the UDR when the request targets multiple UEs and thus potentially multiple PCF(s):

   PCF(s) that need to receive AF requests targeting a DNN (and slice), and/or a group of UEs subscribe to receive UDR notifications about change on such AF request information. When PCF(s) receive a notification about such AF request, they take the received AF request information into account when making policy decisions for existing and future relevant PDU Sessions. In the case of existing PDU Sessions, the PCF's policy decision may trigger a PCC rule change from the PCF to the SMF.

When a PCC rule is received from the PCF, the SMF may take appropriate actions to reconfigure the User Plane of the PDU Session such as:

1. – Adding, relocating or removing a UPF in the data path to, e.g. insert an UL CL or a Branching Point UPF as described in Section 6.2.2.
2. – Allocate a new IPv6 Prefix to the UE (when IPv6 multi‐homing applies).
3. – Update the UPF with new traffic steering rules (e.g. to forward relevant traffic to local application instances).
4. – Subscribe to notifications from the AMF to determine when it should insert a local UPF.

6.6.3 PCF Policies Targeting a PDU Session

The PCF can control following parameters of a PDU Session:

1. – The information to assist in determining the IP Address allocation method (e.g. from which IP pool to assign the address) when a PDU Session requires an IP address/Prefix – as defined in TS 23.501 [3] section 5.8.1.
2. – The default charging method for the PDU Session.
3. – The address of the corresponding charging entity.
4. – The conditions upon which the SMF shall fetch new policies for the PDU Session (called Policy Control Request Triggers).
5. – The Authorized Session‐AMBR.
6. – The default 5QI and ARP of the QoS Flow associated with the default QoS rule.
7. – Applicability of Reflective QoS for QoS Flows within a PDU Session.
8. – Usage Monitoring Control related information.

Multiple Authorized Session‐AMBR and default 5QI and ARP may be provided by the PCF with conditions where they are to apply (e.g. time condition).

6.6.4 PCF Policies Targeting a Service Data Flow

The PCF can instruct the SMF to ensure actions on PDU(s) identified by SDF filtering information (also called SDF templates). PCC rules associate SDF filtering information with actions to apply on the corresponding traffic.

Such policies don't apply for PDU Sessions with unstructured PDU Session Type.

A PCC rule may be predefined (locally configured on the SMF) or dynamically provisioned during the lifetime of a PDU Session. The latter is referred to as a dynamic PCC rule.

It is possible to take a PCC rule into service, and out of service, when a specific condition is met, e.g. at a specific time of day without any PCF‐SMF interaction at that point in time.

Actions defined on traffic identified by an SDF template may provide instructions to the SMF in order to:

1. – Apply QoS as defined in Section 6.4
   1. • All traffic associated with the same QoS parameters build a QoS Flow. A QoS flow may thus correspond to multiple SDF template (when these SDF templates are associated with the same QoS requirements but could correspond to different requirements in terms of traffic steering/charging/gating, etc.)
2. – Perform Gating Control, i.e. discard selected traffic upon PCF control
   1. • This may be used to prevent Voice traffic before IMS Voice charging has been started
3. – Discard traffic that don't match the SDF template of any active PCC rule
   1. • wild‐carded SDF filters allow exchange of traffic that does not match any SDF template of any other active PCC rules.
4. – Monitor the amount of traffic for charging or for other purpose such as service traffic limitation (per day, month, etc.)
5. – Steer traffic: this may be used to control forwarding of traffic towards different N6 interfaces of the same DN identified by a DNAI; DNAI(s) are global (valid for any DNN) and may be used to identify different local/central Data Centres. This may also be used to steer traffic towards Service Functions deployed at N6 on the DN.
6. – Apply relevant User Plane security (integrity protection) (this is enforced by the RAN).

These actions are executed locally by the SMF or result in N4 commands towards UPF, see Section 6.8.

An SDF template may identify:

1. – A PDU direction (UL, DL, both)
2. – A Precedence (to disambiguate different SDF templates that would identify the same traffic).

An SDF may be identified by the IP or ETH Packet filters (see Section 6.4.7) depending on the type of PDU Session.

The SMF is responsible of any network signalling towards UPF and 5G‐AN that are required to adapt a PCC rule (see also Section 6.7).

6.7.1 Overview

The SMF is responsible for any network (5GC) signalling required to control a PDU Session and to set the User Plane handling within this PDU Session. Following are some of the functionalities performed by the SMF:

1. – Selection of the UPF(s) supporting the PDU Session (see Section 6.7.3).
2. – N4 Signalling to control User Plane handling in the UPF (see Section 6.8).
3. – Exchange N2 session management (SM) Signalling via AMF to set QoS parameters in the 5G‐AN, e.g. to reserve resources for GBR traffic. This may take place when receiving a new or a modified PCC rule from the PCF, when applying a local policy at PDU Session establishment but also when the User Plane of a PDU Session becomes active (e.g. when the CM state of the UE becomes CM‐CONNECTED, see Section 5.2).
4. – Exchange N1 SM signalling (via AMF) with the UE, e.g. to:
   1. • establish, modify and release the PDU Session
   2. • provide the UE with QoS rule(s), i.e. a mapping between traffic filter(s) and the QoS that has to be apllied to the corresponding traffic.
5. – Interactions with the AMF to
   1. • exchange N1 SM signalling with the UE via the AMF,
   2. • exchange N2 SM signalling with the 5G‐AN serving the UE via the AMF,
   3. • receive from the AMF requests to activate the User Plane of a PDU Session,
   4. • get event notifications from the AMF when the UE has moved out of an area identified in the event subscription from the SMF; this may be used to handle LADN (see Section 6.2.4).
6. – When PCF control is to apply, selection of the PCF and then support of any signalling exchange with the selected PCF (see Section 6.6).

6.7.2 PDU Session Establishment

Only UE(s) initiate the PDU Session Establishment procedure. This procedure may be started in following cases:

1. – to establish a new PDU Session:
   1. • the PDU Session may be established if the UE is registered with the 5GS (e.g. ‘always‐on’ PDU Session for IMS Voice),
   2. • the PDU Session Establishment may be, due to an internal event in the UE (e.g. the user opens a new application that triggers the request for a new PDU Session) or in response to a device trigger (Short Message Service [SMS]), received by the UE from a network application.
2. – to establish a new PDU Session for IMS Emergency services,
3. – to support a UE initiated PDU Session handover between 3GPP and non‐3GPP access,
4. – to support a UE initiated PDU Session handover from EPS to 5GS.

Upon reception of a UE request for a new PDU Session (received via the AMF), the SMF may (see Figure 6.12):

1. – Contact the UDM to retrieve subscription data and register itself in the UDM for this PDU Session.
2. – Check whether the UE request is compliant with the user subscription.
3. – Check whether PCF control is to apply to this PDU Session. If it applies, the SMF determines whether to use the same PCF as the AMF or whether local policies (e.g. related with slicing) require a dedicated PCF.
4. – Contact the PCF to retrieve policies (for the PDU Session and for SDFs within this PDU Session as described in Section 6.6).
5. – Select UPF(s) to serve this PDU Session (see Section 6.7.3).
6. – In case of IP PDU Session Type allocate or request the allocation of an IP address/IPv6 prefix.
7. – Interact with the charging entity for this PDU Session.
8. – Configure the UPF(s) over N4 (see Section 6.8).
9. – Configure (via the AMF) the 5G‐AN with QoS flows for this PDU Session.
10. – Answer (via the AMF and the 5G‐AN) to the UE providing QoS Rules (and an IP address/IPv6 prefix) for this PDU Session.

6.7.3 UPF Selection

The selection and reselection of the UPF are performed by the SMF considering, e.g.

• UPF deployment scenarios such as centrally located UPF and distributed UPF located close to or at the Access Network site (Section 6.2.4),
• the parameters of the PDU Session (DNN, slice).

For home routed roaming case, the UPF in HPLMN is selected by the SMF in H‐PLMN, and the UPF(s) in VPLMN are selected by the SMF in V‐PLMN.

The UPF selection involves two steps:

1. – Step 1. Discovery of available UPF(s). This step may take place while there is no PDU Session to establish and may be followed by N4 Node Level procedures where the UPF and the SMF may exchange information such as the support of optional functionalities and capabilities.
2. – Step 2. Selection of an UPF for a particular PDU Session; this is followed by N4 session management procedures.