29.244-g30 5.2 Packet Forwarding Model

5.2 Packet Forwarding Model

5.2パケット転送モデル

5.2.1 General

5.2.1一般

The packet forwarding scenarios supported over the Sxa, Sxb and Sxc reference points are specified in 3GPP TS 23.214 [2].

The packet forwarding scenarios supported over the N4 reference point are specified in 3GPP TS 23.501 [28] and 3GPP TS 23.502 [29].

The CP function controls the packet processing in the UP function by establishing, modifying or deleting PFCP Session contexts and by provisioning (i.e. adding, modifying or deleting) PDRs, FARs, QERs, URRs, BAR and/or MAR or by activating/deactivating pre-defined PDRs, FARs, QERs, URRs, per PFCP session context, whereby a PFCP session context may correspond:

Sxa、Sxb、およびSxc参照ポイントでサポートされるパケット転送シナリオは、3GPP TS 23.214 [2]で指定されています。 N4参照ポイントでサポートされるパケット転送シナリオは、3GPP TS 23.501 [28]および3GPP TS 23.502 [29]で指定されています。 CP機能は、PFCPセッションコンテキストを確立、変更、または削除し、PDR、FAR、QER、URR、BAR、MARをプロビジョニング（つまり、追加、変更、または削除）するか、またはpre-definedしたPDR、FAR、QER、URR、PFCPセッションコンテキストごとにアクティブ化/非アクティブ化することにより、UP機能のパケット処理を制御します。これにより、PFCPセッションコンテキストが対応する場合があります。

- for EPC, to an individual PDN connection, a TDF session, or a standalone session not tied to any PDN connection or TDF session used e.g. for forwarding Radius, Diameter or DHCP signalling between the PGW-C and the PDN.

-EPCの場合、個々のPDN接続、TDFセッション、または使用されているPDN接続またはTDFセッションに関連付けられていないスタンドアロンセッションPGW-CとPDN間のRadius、Diameter、またはDHCPシグナリングの転送用。

- for 5GC, to an individual PDU session or a standalone PFCP session not tied to any PDU session.

-5GCの場合、個々のPDUセッション、またはどのPDUセッションにも関連付けられていないスタンドアロンのPFCPセッション。

Each PDR shall contain a PDI, i.e. one or more match fields against which incoming packets are matched, and may be associated to the following rules providing the set of instructions to apply to packets matching the PDI:

　各PDRにはPDIが含まれます。着信パケットが照合される1つ以上の一致フィールド。PDIに一致するパケットに適用する一連の命令を提供する次のルールに関連付けることができます。

- one or more FARs, which contains instructions related to the processing of the packets as follows:

- an Apply Action parameter, which indicates whether the UP function shall forward, duplicate, drop or buffer the packet with or without notifying the CP function about the arrival of a DL packet, or whether the UP function shall accept or deny UE requests to join an IP multicast group;

- forwarding, buffering and/or duplicating parameters, which the UP function shall use if the Apply Action parameter requests the packets to be forwarded, buffered or duplicated respectively. These parameters may remain configured in the FAR regardless of the Apply Action parameter value, to minimize the changes to the FAR during the transitions of the UE between the idle and connected modes. The buffering parameters, when present, shall be provisioned in a BAR created at the PFCP session level and referenced by the FAR.

NOTE 1: Buffering refers here to the buffering of the packet in the UP function. The UP function is instructed to forward DL packets to the CP function when applying buffering in the CP function. See clause 5.3.1.

- zero, one or more QERs, which contains instructions related to the QoS enforcement of the traffic;

- zero, one or more URRs, which contains instructions related to traffic measurement and reporting.

- zero or one MAR, which contains instructions related to Access Traffic Steering, Switching and Splitting (ATSSS) for the downlink traffic of a Multi-Access (MA) PDU session. See clause 5.2.7.

NOTE 2: A downlink PDR can be associated with two FARs for a N4 session established for a MA PDU session as a MAR contains two FARs for 3GPP and non-3GPP respectively.

A FAR, a QER, a URR and a MAR shall only be associated to one or multiple PDRs of the same PFCP session context.

The QoS Enforcement Rule Correlation ID shall be assigned by the CP function to correlate QERs from multiple PFCP session contexts. For instance, the enforcement of APN-AMBR in the PGW-U shall be achieved by setting the same QoS Enforcement Rule Correlation ID to the QERs from different PFCP sessions associated with all the PDRs corresponding to the non-GBR bearers of all the UE's PDN connections to the same APN. The QERs that are associated to the same QoS Enforcement Rule Correlation ID in multiple PFCP sessions shall be provisioned, with the same QER contents, in each of these PFCP sessions. The QoS Enforcement Rule Correlation ID shall be only used to enforce the APN-AMBR when the UE is in EPC, it may be provided by the CP function over N4 to the UP function for a PDU session may move to EPC in a later stage.

The following principles shall apply for the provisioning of PDRs in the UP function:

- The CP function shall not provision more than one PDR with the same match fields in the PDI (i.e. with the same set of match fields and with the same value). The CP function may provision PDRs with the same value for a subset of the match fields of the PDI but not all;

- different PDRs of a same PFCP session may overlap, e.g. the CP function may provision two PDRs which differ by having one match field set to a specific value in one PDR and the same match field not included in the other PDR (thus matching any possible value);

- different PDRs of different PFCP sessions, not including the Packet Replication and Detection Carry-On Information IE, shall not overlap, i.e. there shall be at least one PDR in each PFCP session which differs by at least one different (and not wildcarded) match field in their PDI, such that any incoming user plane packet may only match PDRs of a single PFCP session;

NOTE 3: It is allowed for instance to provision in a PGW-U a same uplink PDR, matching any uplink traffic towards a particular application server's IP address, in two different PFCP sessions of two different UEs, as long as each PFCP session is also provisioned with another uplink PDR set with the respective UE IP address and/or uplink F-TEIDu, which allows the PGW-U to identify the PFCP session to which the packet corresponds.

- As an exception to the previous principle, the CP function may provision a PDR with all match fields wildcarded (i.e. all match fields omitted in the PDI) in a separate PFCP session, to control how the UP function shall process packets unmatched by any PDRs of any other PFCP session. The CP function may provision the UP function to send these packets to the CP function or to drop them. The UP function shall grant the lowest precedence to this PDR.

- different PDRs of different PFCP sessions, including the Packet Replication and Detection Carry-On Information IE, may overlap. The Detection Carry-On Indication indicates that the UP function shall proceed with the look-up of other PDRs of other PFCP sessions matching the packet. This is used for broadcast traffic forwarding in 5G VN Group Communication.

- different downlink PDRs of different PFCP sessions, with a PDI including the IP multicast IP address IE, may overlap. The UP function shall proceed with the look-up of other PDRs of other PFCP sessions matching the packet. This is used for downlink IP multicast traffic for IPTV service (see clause 5.25).

On receipt of a user plane packet, the UP function shall perform a lookup of the provisioned PDRs and:

- identify first the PFCP session to which the packet corresponds; and

- find the first PDR matching the incoming packet, among all the PDRs provisioned for this PFCP session, starting with the PDRs with the highest precedence and continuing then with PDRs in decreasing order of precedence. Only the highest precedence PDR matching the packet shall be selected, i.e. the UP function shall stop the PDRs lookup once a matching PDR is found.

A packet matches a PDR if all the match fields which are identified with different IE type in the PDI of the PDR are matching the corresponding packet header fields unless specified otherwise. If a match field is not included in the PDI, it shall be considered as matching all possible values in the header field of the packet. If the match field is present and does not include a mask, the match field shall be considered as matching the corresponding header field of the packet if it has the same value. If the match field is present and includes a mask (e.g. IP address with a prefix mask), the match field shall be considered as matching the corresponding header field of the packet if it has the same value for the bits which are set in the mask. If a match field has multiple instances, i.e. there are several IEs with the same IE type, a packet matches this match field if any instance is matching the corresponding packet header field.

The match fields of the PDI shall correspond to outer and/or inner packet header fields, e.g. uplink bearer binding verification in the PGW-U may be achieved by configuring a PDR with the PDI containing the local GTP-U F-TEID (for outer IP packet matching) and the SDF filters of the data flows mapped to the bearer (for inner IP packet matching).

NOTE 4: A DL PDR can be provisioned with a UE IP address together with a Framed-Route or a Framed-IPv6-Rotue either in the PDI IE or in the Create Traffic Endpoint IE; in such case, the PDR is matched if the packet matches either the UE IP address or the Framed-Route (Framed-IPv6-Route).

When one or more pre-defined PDR(s) are activated for a given PDR (see clause 5.19), an incoming packet matches the PDR if it matches one of activated pre-defined PDR(s).

The UP function should drop packets unmatched by any PDRs.

The packet processing flow in the UP function is illustrated in Figure 5.2.1-1.

Figure 5.2.1-1: Packet processing flow in the UP function

At the deletion of a PFCP session, the UP function shall delete the PFCP session context and all the associated non-preconfigured rules.

NOTE 5: Deleting a QER in one PFCP session does not result in deleting another QER in another PFCP session even when these two QERs have the same QER ID and/or are associated with the same QER Correlation ID.

A UP Function controlled by multiple CP functions shall handle Rule IDs from the different CP functions independently from each other.

Rule ID used for PDR, FAR, BAR, QER, URR or MAR is uniquely identifying a rule of the corresponding rule type within a session.