School of Specs 23.501v20.2.0

3GPP 23.501 v20.2.0 — the document's own text

5.8.2.8.4 Support of PFD Management

Taught in 13. Where the packets actually go (The 5G system architecture, in depth), 5. The connection, and what is promised on it (The 5G system architecture, overview).

The NEF (PFDF) shall provide PFD(s) to the SMF on the request of SMF (pull mode) or on the request of PFD management from NEF (push mode), as described in TS 23.503 [45]. In addition, the NEF (PFDF) may subscribe to NWDAF to be notified or request to get PFD "Determination analytics" for known applications (as specified in TS 23.288 [86]) and may decide whether to create, update, or delete PFD(s) based on the NWDAF analytics as specified in TS 23.503 [45]. The SMF shall provide the PFD(s) to the UPF, which have active PDR(s) with the application identifier corresponding to the PFD(s).

The SMF supports the procedures in clause 4.4.3.5 of TS 23.502 [3], for management of PFDs. PFD(s) is cached in the SMF and the SMF maintains a caching timer associated to the PFD(s). When the caching timer expires and there's no active PCC rule that refers to the corresponding application identifier, the SMF informs the UPF to remove the PFD(s) identified by the application identifier using the PFD management message.

When a PDR is provided for an application identifier corresponding to the PFD(s) that are not already provided to the UPF, the SMF shall provide the PFD(s) to the UPF (if there are no PFD(s) cached, the SMF retrieves them from the NEF (PFDF) as specified in TS 23.503 [45]). When any update of the PFD(s) is received from NEF (PFDF) by SMF (using "push" or "pull" mode) and there are still active PDRs in UPF for the application identifier, the SMF shall provision the updated PFD set corresponding to the application identifier to the UPF using the PFD management message.

NOTE 1: SMF can assure not to overload N4 signalling while managing PFD(s) to the UPF, e.g. forwarding the PFD(s) to the right UPF where the PFD(s) is enforced.

When the UPF receives the updated PFD(s) from either the same or different SMF for the same application identifier, the latest received PFD(s) shall overwrite any existing PFD(s) stored in the UPF.

NOTE 2: For the case a single UPF is controlled by multiple SMFs, the conflict of PFD(s) corresponding to the same application identifier provided by different SMF can be avoided by operator enforcing a well-planned NEF (PFDF) and SMF/UPF deployment.

When a PFD is removed/modified and this PFD was used to detect application traffic related to an application identifier in a PDR of an N4 session and the UPF has reported the application start to the SMF as defined in clause 4.4.2.2 of TS 23.502 [3] for the application instance corresponding to this PFD, the UPF shall report the application stop to the SMF for the corresponding application instance identifier if the removed/modified PFD in UPF results in that the stop of the application instance is not being able to be detected.

If the PFDs are managed by local O&M procedures, PFD retrieval is not used; otherwise, the PFDs retrieved from NEF (PFDF) override any PFDs pre-configured in the SMF. When all the PFDs retrieved from the NEF (PFDF) for an application identifier are removed, the pre-configured PFDs are used. The SMF shall provide either the PFDs retrieved from NEF (PFDF) or the pre-configured PFDs for an application identifier to the UPF.