3GPP 23.501 v20.2.0 — the document's own text
5.8.5.3 Packet Detection Rule
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 following table describes the Packet Detection Rule (PDR) containing information required to classify a packet arriving at the UPF. Every PDR is used to detect packets in a certain transmission direction, e.g. UL direction or DL direction.
Table 5.8.5.3-1: Attributes within Packet Detection Rule
| Attribute | Description | Comment | |
|---|---|---|---|
| N4 Session ID | Identifies the N4 session associated to this PDR. NOTE 5. | ||
| Rule ID | Unique identifier to identify this rule. | ||
| Precedence | Determines the order, in which the detection information of all rules is applied. | ||
| Packet | Source interface | Contains the values "access side", "core side", "SMF", "N6-LAN", "5G VN internal". | Combination of UE IP address (together with Network instance, if necessary), CN tunnel info, |
| Detection | UE IP address | One IPv4 address and/or one IPv6 prefix with prefix length (NOTE 3). | packet filter set, application identifier, Ethernet PDU Session |
| Information.NOTE 4. | Network instance (NOTE 1) | Identifies the Network instance associated with the incoming packet. | Information and QFI are used for traffic detection.Source interface identifies the |
| CN tunnel info | CN tunnel info on N3, N9 interfaces, i.e. F-TEID. | interface for incoming packets | |
| Packet Filter Set | Details see clause 5.7.6. | where the PDR applies, e.g. from access side (i.e. up-link), | |
| Application identifier | from core side (i.e. down-link), | ||
| QoS Flow ID | Contains the value of 5QI or non-standardized QFI. | from SMF, from N6-LAN (i.e. the | |
| Ethernet PDU Session Information | Refers to all the (DL) Ethernet packets matching an Ethernet PDU session, as further described in clause 5.6.10.2 and in TS 29.244 [65]. | DN), or from "5G VN internal" (i.e. local switch). | |
| Framed Route Information | Refers to Framed Routes defined in clause 5.6.14. | Details like all the combination possibilities on N3, N9 interfaces are left for stage 3 decision. | |
| FQDN Filter for DNS Query | Contains one or more FQDN, FQDN range and/or any FQDN. | The FQDN or FQDN range only used for detection of plain DNS Query message (i.e. not subject to ciphering). The usage is described in TS 23.548 [130]. | |
| Protocol Description | Indicates service protocol used by the flow (NOTE 8), (NOTE 9). | ||
| Expedited Transfer Indication | Contains the value of the "Expedited Transfer Indication" for the downlink traffic. Can be set to TRUE or FALSE (NOTE 10). | ||
| Packet replication and detection carry on information | Packet replication skip information NOTE 7 | Contains UE address indication or N19/N6 indication. If the packet matches the packet replication skip information, i.e. source address of the packet is the UE address or the packet has been received on the interface in the packet replication skip information, the UP function neither creates a copy of the packet nor applies the corresponding processing (i.e. FAR, QER, URR). Otherwise the UPF performs a copy and applies the corresponding processing (i.e. FAR, QER, URR). | |
| NOTE 6 | Carry on indication | Instructs the UP function to continue the packet detection process, i.e. lookup of the other PDRs. | |
| Outer header removal | Instructs the UP function to remove one or more outer header(s) (e.g. IP+UDP+GTP, IP + possibly UDP, VLAN tag), from the incoming packet. | Any extension header shall be stored for this packet. | |
| Forwarding Action Rule ID (NOTE 2) | The Forwarding Action Rule ID identifies a forwarding action that has to be applied. | ||
| Multi-Access Rule ID (NOTE 2) | The Multi-Access Rule ID identifies an action to be applied for handling forwarding for a MA PDU Session. | ||
| List of Usage Reporting Rule ID(s) | Every Usage Reporting Rule ID identifies a measurement action that has to be applied. | ||
| List of QoS Enforcement Rule ID(s) | Every QoS Enforcement Rule ID identifies a QoS enforcement action that has to be applied. | ||
| NOTE 1: Needed e.g. if: - UPF supports multiple DNN with overlapping IP addresses; - UPF is connected to other UPF or AN node in different IP domains. - UPF "local switch", N6-based forwarding and N19 forwarding is used for different 5G LAN groups. - UPF "local switch" may be used for DNN/S-NSSAI dedicated for PIN.NOTE 2: Either a FAR ID or a MAR ID is included, not both.NOTE 3: The SMF may provide an indication asking the UPF to allocate one IPv4 address and/or IPv6 prefix. When asking to provide an IPv6 Prefix the SMF provides also an IPv6 prefix length.NOTE 4: When in the architecture defined in clause 5.34, a PDR is sent over N16a from SMF to I-SMF, the Packet Detection Information may indicate that CN tunnel info is to be locally determined. This is further defined in clause 5.34.6.NOTE 5: In the architecture defined in clause 5.34, the rules exchanged between I-SMF and SMF are not associated with a N4 Session ID but are associated with a N16a association.NOTE 6: Needed in the case of support for broadcast/multicast traffic forwarding using packet replication with SMF-provided PDRs and FARs as described in clause 5.8.2.13.3.2.NOTE 7: Needed in the case of packet replication with SMF-provided PDRs and FARs as described in clause 5.8.2.13.3.2, to prevent UPF from sending the broadcast/multicast packets back to the source UE or source N19/N6.NOTE 8: Not for PDR matching. In the case of unencrypted traffic, it may be provided to assist PDU Set identification when PDU Set Identification and marking applies to the PDR and/or to assist identification of the last packet of the Data burst in downlink when End of Data Burst identification and marking in downlink applies to the PDR. It may assist determination of the Data Burst Size of the data burst when Data Burst Size determination and marking in downlink applies to the PDR. See TS 26.522 [179]. It may assist determination of the Time to Next Burst when time to next data burst determination and marking in downlink applies to the PDR. See TS 26.522 [179].NOTE 9: Not for PDR matching. In the case of end-to-end encrypted traffic, it may be provided to indicate how to retrieve media related information as specified in clause 5.37.9.NOTE 10: For PDR matching but only applicable for a PDR with Source interface "core side". Needed in the case of Expedited Data Transfer with reflective QoS as described in clause 5.37.10.3. |