6 Procedures

29.2443GPPInterface between the Control Plane and the User Plane nodesRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 Introduction

The following clauses specify the procedures supported over the Sxa, Sxb and Sxc reference points.

6.2 PFCP Node Related Procedures

6.2.1 General

The following clauses specify either node level or PFCP entity level procedures over the Sxa, Sxb, Sxc and N4 reference points. The behaviour of the CP function und UP function when sending and receiving a node related message is described.

6.2.2 Heartbeat Procedure

6.2.2.1 General

PFCP Heartbeat is a PFCP entity level procedure.

Two messages are specified for PFCP heartbeat procedure: Heartbeat Request and Heartbeat Response. The use of these messages is further specified in clause 19A of 3GPP TS 23.007 [24] for EPC, and in clause 4 of 3GPP TS 23.527 [40] for 5GC.

6.2.2.2 Heartbeat Request

An PFCP entity of a CP or UP function may send a Heartbeat Request to a PFCP entity of a peer node to find out if the peer PFCP entity is alive. If multiple PFCP entities pertain to the same CP or UP function, each PFCP entity may send Heartbeat Request messages towards each PFCP entity pertaining to the peer node with which a PFCP control association is established.

NOTE 1: If the UP function supports the MPAS feature and connected to an SMF set, each PFCP entity of the UP function can send heartbeat Requests towards each PFCP entity of every SMF with which a PFCP control association is established.

NOTE 2: If the UP function supports the SSET feature and connected to an SMF set, each PFCP entity of the UP function can send heartbeat Requests towards each PFCP entity pertaining to the same SMF or the SMFs in the SMF set with which a PFCP control association is established.

A CP function or UP function shall be prepared to receive a Heartbeat Request at any time (even from unknown peers) and it shall reply with a Heartbeat Response.

6.2.2.3 Heartbeat Response

The message shall be sent as a response to a received Heartbeat Request.

6.2.3 Load Control Procedure

6.2.3.1 General

Load Control is a node level procedure.

Load Control is an optional feature defined over the Sxa, Sxb, Sxc and N4 reference points.

Load control enables the UP function to send its load information to the CP function to adaptively balance the PFCP session load across the UP functions according to their effective load. The load information reflects the operating status of the resources of the UP function.

Load control allows for better balancing of the PFCP session load, so as to attempt to prevent overload in the first place (preventive action). Load control does not trigger overload mitigation actions even if the UP function reports a high load.

Load control and overload control may be supported and activated independently in the network, based on operator’s policy.

6.2.3.2 Principles

The UP function may signal its Load Control Information to reflect the operating status of its resources, at the node level, allowing the receiving CP function to use this information to augment the UP function selection procedures.

The Load Control Information is piggybacked in PFCP request or response messages such that the exchange of Load Control Information does not trigger extra signalling.

NOTE: The inclusion of Load Control Information in existing messages means that the frequency of transmission of load control information increases as the session load increases, allowing for faster feedback and thus better regulation of the load.

The calculation of the Load Control Information is implementation dependent and its calculation and transfer shall not add significant additional load to the node itself and to its corresponding peer nodes.

6.2.3.3 Load Control Information

6.2.3.3.1 General Description

A PFCP message may contain one instance of the Load Control Information (LCI) IE.

When providing load control information in a message for the first time or subsequently, the UP function shall always include the full set of load control information, i.e. all the node level instance of the Load Control Information, even if only a subset of the load control information has changed. The Load Control Sequence Number shall be incremented whenever the load control information is changed (see clause 6.2.3.3.2.1).

Load Control Information shall be linked to the Node ID (i.e. FQDN or the IP address used during the UP function selection) of the UP function providing the Information.

The receiver shall overwrite any stored load control information of a peer with the newly received load control information from the same peer node if the new load control information is more recent than the old information as indicated by the Load Control Sequence Number, e.g. if the receiver has stored an instance of the load control information for a peer node, it overwrites this instance with the new instance received in a message from the same peer node.

The receiver shall consider all the parameters received in the same instance of the LCI IE in conjunction while using this information for UP function selection.

The parameters are further defined in clause 6.2.3.3.2.

Load control information may be extended with new parameters in future versions of the specification. Any new parameter will have to be categorized as:

– Non-critical optional parameters: the support of these parameters is not critical for the receiver. The receiver can successfully and correctly comprehend the load control information instance, containing one or more of these parameters, by using the other parameters and ignoring the non-critical optional parameter.

– Critical optional parameters: the support of these parameters is critical for the receiver to correctly comprehend the instance of the load control information containing one or more of these parameters.

The sender may include one or more non-critical optional parameters within any instance of the LCI IE without having the knowledge of the receiver’s capability to support the same. However, the sender shall only include one or more critical optional parameter in an instance of the LCI IE towards a receiver if the corresponding receiver is known to support those parameters. The sender may be aware of this either via signalling methods or by configuration (this will have to be defined when introducing any such new parameter in future).

6.2.3.3.2 Parameters

6.2.3.3.2.1 Load Control Sequence Number

The Load Control Sequence number contains a value that indicates the sequence number associated with the LCI IE. This sequence number shall be used to differentiate any two LCI IEs generated at two different instances by the same UP function. The Load Control Sequence Number shall be supported (if load control is supported) and shall always be present in the LCI IE.

The UP function generating this information shall increment the Load Control Sequence Number whenever modifying some information in the Load Control Information IE. The Load Control Sequence Number shall not be incremented otherwise. The UP function may use the time, represented in an unsigned integer format, of the generation of the Load Control Information to populate the Load Control Sequence Number.

This parameter shall be used by the receiver of the Load Control Information IE to properly collate out-of-order load control information, e.g. due to PFCP retransmissions. This parameter shall also be used by the receiver of the LCI IE to determine whether the newly received load control information has changed compared to load control information previously received from the same node earlier.

NOTE: The PFCP sequence number cannot be used for collating out-of-order load control information as e.g. load control information may be sent in both PFCP requests and responses, using independent PFCP sequence numbering.

If the receiving entity has already received and stored load control information from the peer UP function, the receiving CP function shall update its load control information only if the Load Control Sequence Number received in the new load control information is higher than the stored value of the Load Control Sequence Number associated with the peer UP function. However due to roll-over of the Load Control Sequence Number or restart of the node, the Load Control Sequence Number may be reset to an appropriate base value by the peer UP function, hence the receiving entity shall be prepared to receive (and process) a Load Control Sequence Number parameter whose value is less than the previous value.

6.2.3.3.2.2 Load Metric

The Load Metric parameter shall indicate the current load level of the originating node. The computation of the Load Metric is left to implementation. The node may consider various aspects, such as the used capacity of the UP function, the load in the node (e.g. memory/CPU usage in relationship to the total memory/CPU available, etc.).

The Load Metric represents the current load level of the sending node as a percentage within the range of 0 to100, where 0 means no or 0% load and 100 means maximum or 100% load reached (i.e. no further load is desirable).

The Load Metric shall be supported (if load control is supported). The Load Metric shall always be included in the Load Control Information.

Considering the processing requirement of the receiver of the Load Control Information (e.g. handling of the new information, tuning the node selection algorithm to take the new information into account), the sender should refrain from advertising every small variation (e.g. with the granularity of 1 or 2), in the Load Metric which does not result in useful improvement in node selection logic at the receiver. During the typical operating condition of the sender, a larger variation in the Load Metric, e.g. 5 or more units, should be considered as reasonable enough for advertising the new Load Control Information and thus justifying the processing requirement (to handle the new information) of the receiver.

NOTE: The range of the Load Metric, i.e. 0 to 100, does not mandate the sender to collect its own load information at every increment/decrement and hence to advertise the change of Load Metric with a granularity of 1%. Based on various implementation specific criteria, such as: the architecture, session and signalling capacity, the current load and so on, the sender is free to define its own logic and periodicity with which its own load information is collected.

6.2.3.3.3 Frequency of Inclusion

How often the sender includes the load control information is implementation specific. The sender shall ensure that new/updated load control information is propagated to the target CP functions within an acceptable delay, such that the purpose of the information (i.e. effective load balancing) is achieved. The sender may include the LCI IE e.g. as follows:

– the sender may include Load Control Information towards a peer only when the new/changed value has not already been provided to that peer;

– the sender may include the Load Control Information in each and every message (extended with LCI IE) towards the peer;

– the sender may include Load Control Information periodically, i.e. include the information during a first period then cease to do so during a second period.

The sender may also implement a combination of one or more of the above approaches. Besides, the sender may also decide to include the Load Control Information only in a subset of the applicable PFCP messages.

The receiver shall be prepared to receive the load control information in any of the PFCP messages extended with an LCI IE and upon such reception, shall be able act upon the received load control information.

6.2.4 Overload Control Procedure

6.2.4.1 General

Overload Control is a node level procedure.

Overload Control is an optional feature defined over the Sxa, Sxb, Sxc and N4 reference points.

Overload control enables a UP function becoming or being overloaded to gracefully reduce its incoming signalling load by instructing its peer CP functions to reduce sending traffic according to its available signalling capacity to successfully process the traffic. A UP function is in overload when it operates over its signalling capacity which results in diminished performance (including impacts to handling of incoming and outgoing traffic).

Overload control aims at shedding the incoming traffic as close to the traffic source as possible generally when an overload has occurred (reactive action), so to avoid spreading the problem inside the network and to avoid using resources of intermediate nodes in the network for signalling that would anyhow be discarded by the overloaded node.

Load control and overload control may be supported and activated independently in the network, based on operator’s policy.

6.2.4.2 Principles

When a UP function determines that the offered incoming signalling traffic is growing (or is about to grow) beyond its nominal capacity, the UP function may signal its overload, at node level granularity, to its peer CP functions by including Overload Control Information in PFCP signalling which provides guidance to the receiving CP functions to decide actions which lead to signalling traffic mitigation towards the sender of the information. This helps in preventing severe overload and hence potential breakdown of the UP function.

The Overload Control Information is piggybacked in PFCP request or response messages such that the exchange of Overload Control Information does not trigger extra signalling.

NOTE: The inclusion of Overload Control Information in existing messages means that the frequency of transmission of overload control information increases as the signalling load increases, thus allowing for faster feedback and better regulation.

The calculation of the Overload Control Information is implementation dependent and its calculation and transfer shall not add significant additional load to the node itself and to its corresponding peer nodes. The calculation of Overload Control Information should not severely impact the resource utilization of the UP function, especially considering the overload situation.

The overload control feature should continue to allow for preferential treatment of priority users (eMPS) and emergency services.

The overload mitigation actions based on the reception of the overload related information received from the UP function will not be standardized.

6.2.4.3 Overload Control Information

6.2.4.3.1 General Description

A PFCP message may contain one instance of the Overload Control Information (OCI) IE.

When providing overload control information in a message for the first time or subsequently, the UP function shall always include the full set of overload control information, i.e. all the node level instance of the Overload Control Information, even if only a subset of the overload control information has changed. The Overload Control Sequence Number shall be incremented whenever the Overload control information is changed (see clause 6.2.4.3.2.1).

The receiver shall overwrite any stored overload control information of a peer with the newly received overload control information from the same peer node if the new overload control information is more recent than the old information as indicated by the Overload Control Sequence Number, e.g. if the receiver has stored an instance of the Overload control information for a peer node, it overwrites this instance with the new instance received in a message from the same peer node.

The receiver shall consider all the parameters received in the same instance of the OCI IE in conjunction while applying the overload mitigation action.

The parameters are further defined in clause 6.2.4.3.2.

Overload control information may be extended with new parameters in future versions of the specification. Any new parameter will have to be categorized as:

– Non-critical optional parameters: the support of these parameters is not critical for the receiver. The receiver can successfully and correctly comprehend the Overload control information instance, containing one or more of these parameters, by using the other parameters and ignoring the non-critical optional parameter.

– Critical optional parameters: the support of these parameters is critical for the receiver to correctly comprehend the instance of the Overload control information containing one or more of these parameters.

The sender may include one or more non-critical optional parameters within any instance of the OCI IE without having the knowledge of the receiver’s capability to support the same. However, the sender shall only include one or more critical optional parameter in an instance of the OCI IE towards a receiver if the corresponding receiver is known to support those parameters. The sender may be aware of this either via signalling methods or by configuration (this will have to be defined when introducing any such new parameter in future).

The Overload Control Information shall be associated by default to the PFCP entity corresponding to the peer node’s IP address of the PFCP session, over which the OCI IE is received, i.e. to the IP address received within the "UP F-SEID" IE.

Alternatively, the UP function may send Overload Control Information which is associated with the Node ID of the UP function (i.e. FQDN or the IP address used during the UP function selection). In that case, the UP function shall provide an explicit indication that the OCI IE included in the message belongs to the Node ID.

6.2.4.3.2 Parameters

6.2.4.3.2.1 Overload Control Sequence Number

The PFCP protocol requires retransmitted messages to have the same contents as the original message. Due to PFCP retransmissions, the overload control information received by a CP function at a given time may be less recent than the overload control information already received from the same UP function. The Overload Control Sequence Number aids in sequencing the overload control information received from an overloaded UP function. The Overload Control Sequence Number contains a value that indicates the sequence number associated with the Overload Control Information IE. This sequence number shall be used to differentiate between two OCI IEs generated at two different instants, by the same UP function.

The Overload Control Sequence Number parameter shall be supported (when supporting the overload control feature) and shall always be present in the Overload Control Information IE.

The UP function generating this information shall increment the Overload Control Sequence Number whenever modifying some information in the OCI IE. The Overload Control Sequence Number shall not be incremented otherwise. The UP function may use the time, represented in an unsigned integer format, of the generation of the overload control information, to populate the Overload Control Sequence Number.

This parameter shall be used by the receiver of the OCI IE to properly collate out-of-order OCI IEs, e.g. due to PFCP retransmissions. This parameter shall also be used by the receiver of the OCI IE to determine whether the newly received overload control information has changed compared to the overload control information previously received from the same UP function. If the newly received overload control information has the same Overload Control Sequence Number as the previously received overload control information from the same UP function, then the receiver may simply discard the newly received overload control information whilst continuing to apply the overload abatement procedures, as per the previous value.

NOTE 1: The timer corresponding to the Period of Validity (see clause 6.2.4.3.2.2) is not restarted if the newly received overload control information has the same Overload Control Sequence Number as the previously received overload control information. If the overload condition persists and the overloaded UP function needs to extend the duration during which the overload information applies, the sender needs to provide a new overload control information with an incremented Overload Control Sequence Number (even if the parameters within the overload control information have not changed).

NOTE 2: The PFCP Sequence Number cannot be used for collating out-of-order overload information as e.g. overload control information may be sent in both PFCP requests and responses, using independent PFCP sequence numbering.

If the receiving CP function already received and stored overload control information, which is still valid, from the overloaded UP function, the receiving entity shall update its overload control information, only if the Overload-Sequence-Number received in the new overload control information is larger than the value of the Overload Control Sequence Number associated with the stored information. However due to roll-over of the Overload Control Sequence Number or restart of the UP function, the Overload Control Sequence Number may be reset to an appropriate base value by the peer UP function, hence the receiving entity shall be prepared to receive (and process) an Overload Control Sequence Number parameter whose value is less than the previous value.

6.2.4.3.2.2 Period of Validity

The Period of Validity indicates the length of time during which the overload condition specified by the OCI IE is to be considered as valid (unless overridden by subsequent new overload control information).

An overload condition shall be considered as valid from the time the OCI IE is received until the period of validity expires or until another OCI IE with a new set of information (identified using the Overload Control Sequence Number) is received from the same UP function (at which point the newly received overload control information shall prevail). The timer corresponding to the period of validity shall be restarted each time an OCI IE with a new set of information (identified using the Overload Control Sequence Number) is received. When this timer expires, the last received overload control information shall be considered outdated and obsolete, i.e. any associated overload condition shall be considered to have ceased.

The Period of Validity parameter shall be supported (when supporting overload control).

The Period of Validity parameter achieves the following:

– it avoids the need for the overloaded UP function to include the Overload Control Information IE in every PFCP messages it signals to its peer CP functions when the overload state does not change; thus it minimizes the processing required at the overloaded UP function and its peer CP functions upon sending/receiving PFCP signalling;

– it allows to reset the overload condition after some time in the peer CP functions having received an overload indication from the overloaded UP function, e.g. if no signalling traffic takes place between these PFCP entities for some time due to overload mitigation actions. This also removes the need for the overloaded UP function to remember the list of CP functions to which it has sent a non-null overload reduction metric and to which it would subsequently need to signal when the overload condition ceases, if the Period of Validity parameter was not defined.

6.2.4.3.2.3 Overload Reduction Metric

The Overload Reduction Metric shall have a value in the range of 0 to 100 (inclusive) which indicates the percentage of traffic reduction the sender of the overload control information requests the receiver to apply. An Overload Reduction Metric of "0" always indicates that the UP function is not in overload (that is, no overload abatement procedures need to be applied) for the indicated scope.

Considering the processing requirement of the receiver of the Overload Control Information, e.g. to perform overload control based on the updated Overload Reduction Metric, the sender should refrain from advertising every small variation, e.g. with the granularity of 1 or 2, in the Overload Reduction Metric which does not result in useful improvement for mitigating the overload situation. During the typical operating condition of the sender, a larger variation in the Overload Reduction Metric, e.g. 5 or more units, should be considered as reasonable enough for advertising a new Overload Reduction Metric Information and thus justifying the processing requirement (to handle the new information) of the receiver.

NOTE: The range of Overload Reduction Metric, i.e. 0 to 100, does not mandate the sender to collect its own overload information at every increment/decrement and hence to advertise the change of Overload Reduction Metric with a granularity of 1%. Based on various implementation specific criteria, such as the architecture, session and signalling capacity, the current load/overload situation and so on, the sender is free to define its own logic and periodicity with which its own overload control information is collected.

The computation of the exact value for this parameter is left as an implementation choice at the sending UP function.

The Overload Reduction Metric shall be supported (when supporting overload control) and shall always be present in the OCI IE.

The inclusion of the OCI IE signals an overload situation is occurring, unless the Overload Reduction Metric is set to "0", which signals that the overload condition has ceased. Conversely, the absence of the OCI IE in a message does not mean that the overload has abated.

6.2.4.3.3 Frequency of Inclusion

How often or when the sender includes the overload control information is implementation specific. The sender shall ensure that new/updated overload control information is propagated to the target receivers with an acceptable delay, such that the purpose of the information, (i.e. the effective overload control protection) is achieved. The following are some of the potential approaches the sender may implement for including the OCI IE:

– the sender may include OCI IE towards a receiver only when the new/changed value has not already been provided to the given receiver;

– the sender may include the OCI IE in a subset of the messages towards the receiver;

– the sender may include the OCI IE periodically, i.e. include the information during a first period then cease to do so during a second period.

The sender may also implement a combination of one or more of the above approaches. Besides, the sender may also include the OCI IE only in a subset of the applicable PFCP messages.

The receiver shall be prepared to receive the overload control information received in any of the PFCP messages extended with an OCI IE and upon such reception, shall be able act upon the received information.

6.2.4.4 Message Throttling

6.2.4.4.1 General

As part of the overload mitigation, a CP function shall reduce the total number of messages, which would have been sent otherwise, towards the overloaded peer based on the information received within the Overload Control Information. This shall be achieved by discarding a fraction of the messages in proportion to the overload level of the target peer. This is called "message throttling".

Message throttling shall only apply to Request messages. Response messages should not be throttled since that would result in the retransmission of the corresponding request message by the sender.

A CP function supporting PFCP overload control shall support and use the "Loss" algorithm as specified in this clause, for message throttling.

6.2.4.4.2 Throttling algorithm – "Loss"

6.2.4.4.2.1 Description

An overloaded UP function shall ask its peers to reduce the number of requests they would ordinarily send by signalling Overload Control Information including the requested traffic reduction, as a percentage, within the "Overload-Reduction-Metric", as specified in clause 6.2.4.3.2.

The recipients of the "Overload-Reduction-Metric" shall reduce the number of requests sent by that percentage, either by redirecting them to an alternate destination if possible (e.g. the PFCP Session Establishment Request message may be redirected to an alternate UP function), or by failing the request and treating it as if it was rejected by the destination UP function.

For example, if a sender requests another peer to reduce the traffic it is sending by 10%, then that peer shall throttle 10% of the traffic that would have otherwise been sent to this UP function.

The overloaded UP function should periodically adjust the requested traffic reduction based e.g. on the traffic reduction factor that is currently in use, the current system utilization (i.e. the overload level) and the desired system utilization (i.e. the target load level), and/or the rate of the current overall received traffic.

Annex A.1 provides an (informative) example of a possible implementation of the "Loss" algorithm, amongst other possible methods.

NOTE 1: This algorithm does not guarantee that the future traffic towards the overloaded UP function will be less than the past traffic but it ensures that the total traffic sent towards the overloaded UP function is less than what would have been sent without any throttling in place. If after requesting a certain reduction in traffic, the overloaded UP function receives more traffic than in the past, whilst still in overload, leading to the worsening rather than an improvement in the overload level, then the overloaded UP function can request for more reduction in traffic. Thus, by periodically adjusting the requested traffic reduction, the overloaded node can ensure that it receives, approximately, the amount of traffic which it can handle.

NOTE 2: Since the reduction is requested as a percentage, and not as an absolute amount, this algorithm achieves a good useful throughput towards the overloaded node when the traffic conditions vary at the source nodes (depending upon the events generated towards these source nodes by other entities in the network), as a potential increase of traffic from some source nodes can possibly be compensated by a potential decrease of traffic from other source nodes.

6.2.4.5 Message Prioritization

6.2.4.5.1 Description

When performing message throttling:

– PFCP requests related to priority traffic (i.e. eMPS as described in 3GPP TS 22.153 [15]) and emergency have the highest priority. Depending on regional/national requirements and network operator policy, these PFCP requests shall be the last to be throttled, when applying traffic reduction, and the priority traffic shall be exempted from throttling due to PFCP overload control up to the point where the requested traffic reduction cannot be achieved without throttling the priority traffic;

– for other types of sessions, messages throttling should consider the relative priority of the messages so that the messages which are considered as low priority are considered for throttling before the other messages. The relative priority of the messages may be derived from the relative priority of the procedure for which the message is being sent or may be derived from the session parameters such as APN, QCI, ARP and/or Low Access Priority Indicator (LAPI).

NOTE: A random throttling mechanism, i.e. discarding the messages without any special consideration, could result in an overall poor congestion mitigation mechanism and bad user experience.

An overloaded node may also apply these message prioritization schemes when handling incoming initial messages during an overloaded condition, as part of a self-protection mechanism.

6.2.4.5.2 Based on the Message Priority Signalled in the PFCP Message

Message prioritization may be performed by an overloaded node, when handling incoming messages during an overloaded condition, based on the relative PFCP message priority signalled in the PFCP header (see clause 7.2.2.3).

A PFCP entity shall determine whether to set and use the message priority in PFCP signalling, based on operator policy. The requirements specified in this clause shall apply if message priority in PFCP signalling is used.

A sending PFCP entity shall determine the relative message priority to signal in the message according to the principles specified in clause 6.2.4.5.1. If the message affects multiple bearers, the relative message priority should be determined considering the highest priority ARP among all the bearers.

A PFCP entity should set the same message priority in a Response message as received in the corresponding Request message.

For incoming PFCP messages that do not have a message priority in the PFCP header, the receiving PFCP entity:

– shall apply a default priority, if the incoming message is a Request message;

– should apply the message priority sent in the Request message, if the incoming message is a Response message.

This feature should be supported homogenously across the CP functions and UP functions in the network, otherwise an overloaded node will process Request messages received from the non-supporting nodes according to the default priority while Request messages received from supporting nodes will be processed according to the message priority signalled in the PFCP message.

6.2.5 PFCP PFD Management Procedure

6.2.5.1 General

PFCP PFD Management is a node level procedure.

The PFCP PFD Management procedure may be used by the CP function and UP function to provision PFDs (e.g. received from the PFDF as specified in clauses 5.11.4 and 6.5.2 of 3GPP TS 23.214 [2]) to the UP function, for one or more Application Identifiers.

Support of this procedure is optional for the CP function and the UP function. The UP function shall set the PFDM feature flag in the UP Function Features IE if it supports the PFD Management procedure (see clause 8.2.25).

The UP function shall store the PFDs provisioned per Application Identifier. These PFDs shall apply to all the PFCP session established in the UP function, for all the controlling CP functions, i.e. the scope of a PFD is not limited to the PFCP sessions established by the CP function which provisioned the PFD.

NOTE: Application identifiers preconfigured in the UP function, if any, need to be distinct from application identifiers provisioned via PFD management procedure.

6.2.5.2 CP Function Behaviour

The CP function initiates the PFCP PFD Management procedure to provision PFDs in the UP function, for one or more Application Identifier(s).

The CP function:

– shall send the PFCP PFD Management Request message, including the full set of PFD IDs and PFD contents to be provisioned in the UP function per Application Identifier.

When the CP function receives a PFCP PFD Management Response with cause success, the CP function shall consider that the PFDs have been provisioned as requested.

6.2.5.3 UP Function Behaviour

When the UP function receives a PFCP PFD Management Request message, it shall:

– if no Application ID’s PFDs IE is present in the request (i.e. empty message):

– delete all the PFDs received and stored earlier for all Application Identifier(s) provisioned via the PFD Management Procedure;

– if at least one Application ID’s PFDs IE is present in the request:

– delete all the PFDs received and stored earlier for the indicated Application Identifier(s);

– store all the PFDs received in the request for the indicated Application Identifier(s);

– send a PFCP PFD Management Response with the cause "success", if the above operations were performed successfully;

– if a PFD is removed/modified and this PFD was used to detect application traffic related to an application identifier in a PDR created/activated for a PFCP session and the UP function has reported the application start to the CP function for the application or the application instance corresponding to this PFD as defined in clause 5.4.11 ((Un)solicited Application Reporting), the UP function shall report the application stop to the CP function for the corresponding application or the corresponding application instance identifier as defined in clause 5.4.11 if the removed/modified PFD in UP results in the stop of the application or the application instance is not being able to be detected. See clause 5.11.4 of 3GPP TS 23.214 [2].

NOTE: Multiple PFDs can be associated with the application identifier. When the removed/modified PFD is the last one which is used to detect traffic identified by application id, the UPF reports application stop.

6.2.6 PFCP Association Setup Procedure

6.2.6.1 General

PFCP Association Setup is a node level procedure.

The PFCP Association Setup procedure shall be used to setup a PFCP association between a CP function and a UP function, to enable the CP function to use the resources of the UP function subsequently, i.e. establish PFCP Sessions.

The setup of a PFCP association may be initiated by the CP function (see clause 6.2.6.2) or the UP function (see clause 6.2.6.3).

The CP function and the UP function shall support the PFCP Association Setup initiated by the CP function. The CP function and the UP function may additionally support the PFCP Association Setup initiated by the UP function.

6.2.6.2 PFCP Association Setup Initiated by the CP Function

6.2.6.2.1 CP Function Behaviour

The CP function shall initiate the PFCP Association Setup procedure to request to setup a PFCP association towards a UP function prior to establishing a first PFCP session on this UP function.

The CP function shall retrieve an IP address of the UP function to send the PFCP Association Setup Request, as specified in clause 5.8.1, and shall send a PFCP Association Setup Request to the UP function with:

– the Node ID of the CP function;

– the list of optional features the CP function supports which may affect the UP function behaviour, if any;

– optionally, the PFCP Session Retention Information IE (see figure 7.4.4.1-2) to request the UP function to retain all or part of the existing PFCP sessions if a PFCP association already exists in the UP function for the same Node ID.

The CP function shall only initiate PFCP Session related signalling procedures toward a UP function after it receives the PFCP Association Setup Response with a successful cause from this UP function.

The CP function shall determine whether the UP function supports Sxa, Sxb, Sxc and/or combined Sxa/Sxb by local configuration or optionally via DNS if deployed.

6.2.6.2.2 UP Function behaviour

When receiving a PFCP Association Setup Request, the UP function:

– if the request is accepted:

– shall store the Node ID of the CP function as the identifier of the PFCP association;

– shall send a PFCP Association Setup Response including:

– a successful cause;

– its Node ID;

– information of all supported optional features in the UP function;

– optionally one or more UE IP address Pool Information IE which contains a list of UE IP Address Pool Identities per Network Instance, S-NSSAI and IP version;

– optionally the NF Instance ID of the UPF if available.

– shall send a PFCP Version Not Supported Response if the PFCP header of the request indicates a PFCP protocol version that is not supported by the UP function;

– otherwise, shall send a PFCP Association Setup Response with an appropriate error cause if the request is rejected.

If the PFCP Association Setup Request contains a Node ID for which a PFCP association was already established, the UP function shall:

– proceed with establishing the new PFCP association (regardless of the Recovery Timestamp received in the request), overwriting the existing association;

– retain the PFCP sessions that were established with the existing PFCP association and that are requested to be retained, if the PFCP Session Retention Information IE was received in the request; otherwise, delete the PFCP sessions that were established with the existing PFCP association;

– set the PSREI (PFCP Session Retained Indication) flag to "1" in the PFCP Association Setup Response, if the PFCP Session Retention Information IE was received in the Request and the requested PFCP sessions have been retained.

If the UPF is configured to be used for IPUPS, the UPF shall set the UUPSI (UPF configured for IPUPS Indication) flag to "1" in the PFCP Association Setup Response message.

6.2.6.3 PFCP Association Setup Initiated by the UP Function

6.2.6.3.1 UP Function Behaviour

The UP function initiates the PFCP Association Setup procedure to request to setup a PFCP association towards a CP function. The UP function is configured with a set of CP functions to which it shall establish a PFCP association.

The UP function:

– shall retrieve an IP address of the CP function, e.g. based on local configuration in the UP function;

– shall send the PFCP Association Setup Request including:

– the Node ID of the UP function;

– information of all supported optional features in the UP function;

– optionally one or more UE IP address Pool Information IE which contains a list of UE IP Address Pool Identities per a given Network Instance, S-NSSAI and IP version;

– optionally the NF Instance ID of the UPF if available.

– the UUPSI (UPF configured for IPUPS Indication) flag set to "1" if the UPF is configured to be used for IPUPS.

6.2.6.3.2 CP Function Behaviour

When receiving a PFCP Association Setup Request, the CP function:

– if the request is accepted:

– shall store the Node ID of the UP function as the identifier of the PFCP association;

– shall send a PFCP Association Setup Response with a successful cause, its Node ID, and information of the list of optional features the CP function supports which may affect the UP function behaviour, if any;

– shall send a PFCP Version Not Supported Response if the PFCP header of the request indicates a PFCP protocol version that is not supported by the CP function;

– otherwise, shall send a PFCP Association Setup Response with an appropriate error cause if the request is rejected.

The CP function shall only initiate PFCP Session related signalling procedures toward a UP function after it has sent the PFCP Association Setup Response with a successful cause to the UP function.

The CP function shall determine the UP function supports Sxa, Sxb, Sxc and/or combined Sxa/Sxb by local configuration or optionally via DNS if deployed.

6.2.7 PFCP Association Update Procedure

6.2.7.1 General

PFCP Association Update is a node level procedure.

The PFCP Association Update procedure shall be used to modify an existing PFCP association between the CP function and the UP function. It may be initiated by the UP function or by the CP function to update the supported features or available resources of the UP function.

6.2.7.2 PFCP Association Update Procedure Initiated by the CP Function

6.2.7.2.1 CP Function Behaviour

The CP function initiates the PFCP Association Update procedure to report changes to the PFCP association to the UP function, e.g. to update the supported features.

When both the CP function and UP function support the EPFAR feature, the CP function may send a PFCP Association Update Request with the "PFCP Association Release Preparation Start" flag set to "1" when the CP function decides to release the PFCP association and request the UP function to report all non-zero usage reports for the PFCP session affected by the release of the PFCP association, as specified in clause 5.18.

6.2.7.2.2 UP Function Behaviour

When receiving a PFCP Association Update Request, the UP function:

– shall update the list of optional features of the CP function, when received;

– shall send a PFCP Association Update Response with an appropriate error cause if the Node ID is not known by the UP Function;

– shall return a PFCP Association Update Response with a successful cause value, if the PFCP Association Update Request is handled successfully.

When both the CP function and UP function support the EPFAR feature, and the CP function has set the "PFCP Association Release Preparation" set to "1" in the PFCP Association Update Request message, the UP function shall send the PFCP Association Update Response to CP function with successful cause value and then send PFCP Session Report Request messages to report non-zero usage reports (at least one message per PFCP Session) for the PFCP Sessions affected by the release of the PFCP association, as specified in clause 5.18.

6.2.7.3 PFCP Association Update Procedure Initiated by UP Function

6.2.7.3.1 UP Function Behaviour

The UP function initiates the PFCP Association Update procedure to report changes to the PFCP association to the CP function, e.g. change of optional features, an indication to request to release the PFCP association, change of the UE IP Address Pool Identifies configured in the UP function.

The UP function may send a PFCP Association Update Request to request the CP function to perform the release of the PFCP association, optionally providing a Graceful Release Period.

When the Enhanced PFCP Association Release feature (EPFAR) (see clause 5.18) is supported by both the CP function and UP function, the UP function:

– may send a PFCP Association Update Request with the flag "PFCP Association Release Preparation" set to "1" when the UP function decides to release the PFCP association and thus inform the CP function that all non-zero usage reports for those PFCP session affected by the release of the PFCP association will be reported;

– shall then send a PFCP Association Update Request, with the URSS flag set to "1" once all non-zero usage reports for all the PFCP Sessions affected by the release of PFCP Association have been sent to the CP function.

After reception of the PFCP Association Update Response, the UP function shall consider that the PFCP association is still setup until receiving a PFCP Association Release Request. When the UP function requests to release the PFCP Association and sends a PFCP Association Update Request message with a Graceful Release Period or with the URSS flag set, if no PFCP Association Release Request is received before the Graceful Release Period or a configurable timer (when the URSS flag is set) expires, the UP function may locally release the association, behaving as if the PFCP Association Release Request had been received.

6.2.7.3.2 CP Function Behaviour

When receiving a PFCP Association Update Request, the CP function:

– shall update the list of optional features of the UP function, when received;

– shall send a PFCP Association Update Response with an appropriate error cause if the Node ID is not known by the CP Function;

– shall return a PFCP Association Update Response with a successful cause value if the PFCP Association Update Request is handled successfully.

If the UP function has requested to release the PFCP association in the PFCP Association Update Request, the CP function should initiate a PFCP Association Release Request to release the PFCP association, as soon as possible if no Graceful Release Period was included in the request or before the expiry of the Graceful Release Period. The CP function should stop creating new PFCP sessions in the UP function during the Graceful Release Period. When the final usage report(s) for a PFCP Session (upon being deleted) is required, e.g. based on operator policies, the CP function should initiate a PFCP Session Deletion Procedure to collect the usage reports per PFCP Session affected by the release of PFCP Association before the Graceful Release Period is expired.

When both the CP function and UP function support the EPFAR feature, and if the UP function has set the URSS flag to "1" in the PFCP Association Update Request message, the CP function shall send the PFCP Association Update Response with successful cause value to indicate the PFCP Association Update Request is handled successfully and then immediately initiate the PFCP Association Release Procedure, as specified in clause 5.18.

If the UP function has included UE IP address Pool Identity IE in the PFCP Association Update Request message, the CP function shall use it to overwrite the UE IP address Pool Identity previously received from the UP function.

6.2.8 PFCP Association Release Procedure

6.2.8.1 General

PFCP Association Release is a node level procedure.

The PFCP Association Release procedure shall be used to terminate the PFCP association between the CP Function and the UP Function due to e.g. OAM reasons. The PFCP Association Release Request may be initiated by the CP function.

When the final usage report(s) for a PFCP Session is required, e.g. based on the operator policies, the CP function should retrieve the final usage reports for the PFCP Sessions affected by the release of PFCP Association, i.e. by initiating a PFCP Session Deletion Procedure towards the UP function for every PFCP session, before it initiates PFCP Association Release Request.

6.2.8.2 CP Function Behaviour

If the CP function initiates the PFCP Association Release procedure to release an existing PFCP association, the CP function:

– shall delete locally all the PFCP sessions related to that PFCP association when receiving the PFCP Association Release Response with the cause value success.

6.2.8.3 UP Function behaviour

When the UP function receives a PFCP Association Release Request, the UP function:

– shall delete all the PFCP sessions related to that PFCP association locally;

– shall delete the PFCP association and any related information (e.g. Node ID of the CP function);

– shall send a PFCP Association Release Response with a successful cause.

NOTE: The UP function always accepts a PFCP Association Release Request.

6.2.9 PFCP Node Report Procedure

6.2.9.1 General

PFCP Node Report Procedure is a node level procedure.

The PFCP Node Report procedure shall be used by the UP function to report information to the CP function which is not related to a specific PFCP session, e.g. to report a user plane path failure affecting all the PFCP sessions towards a remote GTP-U peer.

6.2.9.2 UP Function Behaviour

The UP function shall initiate the PFCP Node Report procedure to report information to the CP function. The UP function:

– shall send the PFCP Node Report Request message, including the information to be reported.

When the UP function receives a PFCP Node Report Response with the cause success, the UP function shall consider the information successfully delivered to the CP function.

6.2.9.3 CP Function behaviour

When the CP function receives a PFCP Node Report Request message, it shall:

– process the information being reported as appropriate and send a PFCP Node Report Response with the cause "success";

– otherwise return an appropriate error cause value.

6.3 PFCP Session Related Procedures

6.3.1 General

The following clauses describe the session related procedures over the Sxa, Sxb, Sxc and N4 reference points. The behaviour of the CP function and UP function when sending and receiving session related messages is described.

6.3.2 PFCP Session Establishment Procedure

6.3.2.1 General

The PFCP Session Establishment procedure shall be used to setup a PFCP session between CP function and UP function and configure Rules in the UP function so that the UP function can handle incoming packets.

6.3.2.2 CP Function Behaviour

The CP function initiates the PFCP Session Establishment procedure to create a PFCP session for a PDN connection or a PDU session, or IP-CAN session or TDF session or for applying a certain IP packets treatment which is not associated with any PDN connection or TDF session.

The CP function:

– shall send the PFCP Session Establishment Request message with a new PFCP F-SEID together with Rules to be created;

– may include its current Recovery Time Stamp as specified in clause 19A of TS 3GPP TS 23.007 [24].

When the CP function receives a PFCP Session Establishment Response with the cause "Request accepted (success)", the CP function shall continue with the procedure which triggered the PFCP Session Establishment procedure. If the CP function indicated support of the PSUCC feature (see clause 8.2.58) during the PFCP association setup or update procedure, and if the cause in the response indicates "Request partially accepted", the CP function shall behave as specified in clause 5.2.9.

6.3.2.3 UP Function Behaviour

When the UP function receives a PFCP Session Establishment Request message:

– the UP function shall store and apply the rules received in the request and send a PFCP Session Establishment Response with cause "success", if all rules in the PFCP Session Establishment Request are stored and applied;

– Otherwise, if at least one rule failed to be stored or applied:

– the UP function shall return an appropriate error cause value with the Rule ID of the Rule causing the first error, discard all the received rules and not create any PFCP session context, if the CP function or the UP function does not support the PSUCC feature (see clause 5.2.9); or

– alternatively, if the CP function indicated support of the PSUCC feature (see clause 8.2.58) during the PFCP association setup or update procedure, and if this feature is also supported by the UP function, the UP function should accept the request partially, if possible, and return a response indicating a partial acceptance of the request as specified in clause 5.2.9.

6.3.3 PFCP Session Modification Procedure

6.3.3.1 General

The PFCP Session Modification procedure shall be used to modify an existing PFCP session, e.g. to configure a new rule, to modify an existing rule, to delete an existing rule.

6.3.3.2 CP Function behaviour

The CP function initiates the PFCP Session Modification procedure to modify an existing PFCP session, e.g. triggered by a modification of PDN connection, PDU session, IP CAN session or TDF session.

The CP function shall:

– include a complete PDI if the PDI in the existing PDR is to be updated;

– remove locally the reference to a rule in the PDRs when the related Rule is deleted;

– provide all the new, updated or deleted Rules. The Updated Rules shall contain only the information which are changed, added and/or deleted.

The CP function shall not include multiple updates in a PFCP Modification Request message, e.g. Create PDR, Update PDR and Remove PDR, for the same rule identified by the Rule ID.

When the CP function receives a PFCP Session Modification Response with the cause "Request accepted (success)", it shall continue with the procedure which has initiated the PFCP Session Modification procedure. If the CP function indicated support of the PSUCC feature (see clause 8.2.58) during the PFCP association setup or update procedure, and if the cause in the response indicates "Request partially accepted", the CP function shall behave as specified in clause 5.2.9.

6.3.3.3 UP Function Behaviour

When the UP function receives a PFCP Session Modification Request it shall:

– send the PFCP Session Modification Response message with a rejection cause value set to "Session context not found" if the F-SEID included in the PFCP Session Modification Request message is unknown;

– reject a modification request which would relate to a rule not existing in the UP function;

– discard any updates on the PFCP session context included in the PFCP Session Modification Request message if the request is rejected and send a PFCP Session Modification Response with an appropriate error cause together with additional information e.g. indicating the first Rule ID of the Rule causing the error. In this case, the UP function shall continue with the existing PFCP session context for the PFCP session as if the PFCP Session Modification Request had not been received;

– remove all rules identified by a Rule ID to be removed and remove the Rule ID from the PDR(s) from where they are referenced;

– send the PFCP Session Modification Response with the cause "Request accepted (success)", if all the requested modifications are accepted and performed successfully;

– send the PFCP Session Modification Response with the cause "Request partially accepted", if the CP function indicated support of the PSUCC feature (see clause 8.2.58) during the PFCP association setup or update procedure, if this feature is also supported by the UP function, and if the UP function could accept the request partially as specified in clause 5.2.9.

6.3.4 PFCP Session Deletion Procedure

6.3.4.1 General

The PFCP Session Deletion procedure shall be used to delete an existing PFCP session between the CP function and the UP function.

6.3.4.2 CP Function Behaviour

The CP function initiates a PFCP Session Deletion procedure towards the UP function to delete an existing PFCP session e.g. when the corresponding PDN connection or PDU session is deleted.

The CP shall:

– send a PFCP Session Deletion Request with the F-SEID identifying the PFCP session.

When the CP function receives PFCP Session Deletion Response with cause success, the CP function shall continue with the procedure which triggers the PFCP Session Deletion procedure.

6.3.4.3 UP Function Behaviour

When the UP function receives a PFCP Session Deletion Request it shall:

– send the PFCP Session Deletion Response message with a rejection cause set to "Session context not found" if the F-SEID include in the PFCP Session Deletion Request message is unknown;

– send the PFCP Session Deletion Response message with an acceptance cause if the PFCP session and associated rules are deleted successfully, and include any pending Usage Report(s) in the message.

6.3.5 PFCP Session Report Procedure

6.3.5.1 General

The PFCP Session Report procedure shall be used by the UP function to report information related to the PFCP session to the CP function.

6.3.5.2 UP Function Behaviour

The UP function shall initiate the PFCP Session Report procedure to report information related to a PFCP session to the CP function. The UP function:

– shall send the PFCP Session Report Request message, identifying the PFCP session for which the report is sent and including the information to be reported.

If the Enhanced PFCP Association Release feature (EPFAR) is supported by both the CP function and UP function, the UP function may send a PFCP Session Report Request message with the flag PSDBU being set to "1" to the CP function to report that the PFCP session is being deleted in the UP function, as specified in clause 5.18, e.g. to report remaining non-zero usage reports for all URRs in the PFCP Session before the PFCP Session is locally deleted in the UP function during an Enhanced PFCP Association Release procedure.

When the UP function receives a PFCP Session Report Response with the cause success, the UP function shall consider the information to be successfully delivered to the CP function.

6.3.5.3 CP Function Behaviour

When the CP function receives a PFCP Session Report Request message, it shall:

– send the PFCP Session Report Response message with a rejection cause set to "Session context not found" if the F-SEID included in the PFCP Session Report Request message is unknown;

– process the information being reported as appropriate and send a PFCP Session Report Response with the cause "success";

– otherwise return an appropriate error cause value.

If the Enhanced PFCP Association Release feature (EPFAR) is supported by both the CP function and UP function, the CP function shall consider that a PFCP Session is locally deleted in the UP function upon receiving a PFCP Session Report Request message from the UP function with the flag PSDBU being set to "1".

6.4 Reliable Delivery of PFCP Messages

Reliable delivery of PFCP messages is accomplished by retransmission of these messages as specified in this clause.

A PFCP entity shall maintain, for each triplet of local IP address, local UDP port and remote peer’s IP address, a sending queue with Request messages to be sent to that peer. Each message shall be sent with a Sequence Number and be held until a corresponding Response is received or until the PFCP entity ceases retransmission of that message. The Sequence Number shall be unique for each outstanding Request message sourced from the same IP/UDP endpoint. A PFCP entity may have several outstanding Requests waiting for replies.

When sending a Request message, the sending PFCP entity shall start a timer T1. The sending entity shall consider that the Request message has been lost if a corresponding Response message has not been received before the T1 timer expires. If so, the sending entity shall retransmit the Request message, if the total number of retry attempts is less than N1 times. The setting of the T1 timer and N1 counter is implementation specific.

A retransmitted PFCP message shall have the same message content, including the same PFCP header, UDP ports, source and destination IP addresses as the originally transmitted message.

A Request and its Response message shall have the same Sequence Number value, i.e. the Sequence Number in the PFCP header of the Response message shall be copied from the respective Request message. A Request and its Response messages are matched based on the Sequence Number and the IP address and UDP port.

Not counting retransmissions, a Request message shall be answered with a single Response message. Duplicated Response messages shall be discarded by the receiver. A received Response message not matching an outstanding Request message waiting for a reply should be discarded.

The PFCP entity should inform the upper layer when detecting an unsuccessful transfer of a Request message to enable the controlling upper entity to take any appropriate measure.

6.5 PFCP messages bundling

PFCP messages bundling is an optional procedure that may be supported by the CP function and the UP function.

PFCP messages bundling may be used if both the CP function and the UP function have indicated support of the corresponding feature (see clauses 8.2.25 and 8.2.58) during the PFCP Association Setup or Update procedure. If so, the following requirements shall apply.

Several PFCP session related requests and/or responses messages, related to the same PFCP session or to different PFCP sessions handled by the same peer PFCP entity (i.e. with the peer’s F-SEID having the same IP address, or with the same peer’s IP address for PFCP Session Establishment Requests), may be bundled together in a single UDP/IP packet as specified in clause 7.2.1A, when being sent to that peer PFCP entity. PFCP messages may be bundled towards a PFCP entity of a UP function or of a CP function, independently.

NOTE 1: If the CP function bundles few PFCP session related requests in one UDP/IP packet it sends to a UP function, the UP function can return responses in separate UDP/IP packets or it can bundle some of the responses together with other PFCP session related messages.

NOTE 2: Bundling PFCP messages in a single UDP/IP packet enable to enhance performance and scalability (reduced CPU and memory cost thanks to reducing the number of packets to be packetized, exchanged and processed over N4).

PFCP session related messages handled by different peer PFCP entities (i.e. with the peer’s F-SEID having different IP addresses) shall not be bundled together. PFCP node related messages shall not be bundled either.

The procedures specified in the rest of this specification shall apply for each PFCP message that is bundled in a UDP/IP packet, as if the PFCP message was sent in its own individual UDP/IP packet, i.e. PFCP messages bundling shall not incur any change to the PFCP protocol other than what is described in this clause.

NOTE 3: Each PFCP message bundled in a single UDP/IP packet has its own sequence number. Besides, if a UDP/IP packet carrying bundled PFCP messages is lost, retransmitted PFCP messages do not need to be bundled in the same manner as when sent originally.