5 Functional description

23.2143GPPArchitecture enhancements for control and user plane separation of EPC nodesRelease 17TS

5.1 General

This clause contains detailed functional descriptions for some of the functions provided by the UP function of SGW, PGW and TDF (whether a function has to be supported by a functional entity is defined in clause 4.3.2). It is documented how the respective CP function instructs it’s corresponding UP function and which control parameters are used.

5.2 Traffic detection

5.2.1 General

This clause describes the detection process at the UP function that identifies the packets belonging to a bearer, service data flow or IP-CAN/TDF session.

The CP function is responsible for instructing the UP function about how to detect user data traffic belonging to a Packet Detection Rule (PDR). The other parameters provided within a PDR describe how the UP function shall treat a packet that matches the detection information.

5.2.2 Traffic detection information

The CP function controls the traffic detection at the UP function by providing detection information for every PDR. Detection information is a combination of:

– UE IP address;

– F-TEIDu;

– SDF filters as defined in TS 23.203 [3];

– Application ID (referring to an application detection filter) as defined in TS 23.203 [3].

The following Table 5.2.2-1 lists the possible combinations of the traffic detection information for the different UP functions and usage scenarios.

Table 5.2.2-1: Detection information for the different UP functions and usage scenarios

Usage scenario	UP function	Detection information for UL	Detection information for DL	Description
1	SGW-U	Local F-TEIDu (access side)	Local F-TEIDu (core side)	Detection of traffic belonging to a bearer
2	PGW-U	Local F-TEIDu (access side) + uplink SDF filter(s)/application ID (NOTE 2)	UE IP address as destination + downlink SDF filter(s)/application ID	Detection of traffic belonging to a service data flow + UL bearer binding verification (based on F-TEIDu in UL filter)
3	PGW-U	Local F-TEID (access side) + UE IP address as source + uplink SDF filter(s)/application ID (NOTE 2)	UE IP address as destination + downlink SDF filter(s)/application ID	Usage scenario 2 + Packet screening (based on UE IP as source in UL filter)
4	PGW-U	Local F-TEID (access side) (NOTE 1)	–	Detection of remaining traffic, e.g. with wrong UE IP address or on wrong bearer, for measurement and discarding.
5	PGW-U	–	UE IP address as destination (NOTE 1)	Detection of remaining traffic, e.g. not matching any other detection information, for discarding.
6	PGW-U	–	Downlink SDF filter(s)/application ID (NOTE 2)	Detection of RADIUS, Diameter and DHCP signalling traffic on SGi.
7	TDF-U	UE IP address as source + uplink SDF filter(s)/application ID	UE IP address as destination + downlink SDF filter(s)/application ID	Detection of traffic belonging to a service data flow
8	TDF-U	UE IP address as source (NOTE 1)	UE IP address as destination (NOTE 1)	Detecting of remaining traffic (i.e. not matching any other PDR) belonging to a TDF session
NOTE 1: A PDR with such detection information should have the lowest precedence amongst all the PDRs installed for this Sx session. NOTE 2: The detection of traffic related to UE IP address allocation as well as RADIUS, Diameter and DHCP signalling traffic on SGi can be accomplished using SDF filter(s) or an application ID (referring to an application detection filter).

5.3 Charging and usage monitoring handling

5.3.1 General

If functional split of SGW into SGW-C and SGW-U is supported, the overall functionality of offline charging support as defined by TS 23.401 [2] and TS 32.251 [8] shall be preserved.

If functional split of PGW into PGW-C and PGW-U is supported, the overall functionality of online and offline charging as defined by TS 32.251 [8], and of usage monitoring control as defined by TS 23.401 [2], TS 23.203 [3] shall be preserved.

If functional split of TDF into TDF-C and TDF-U is supported, the overall functionality of online and offline charging as defined by TS 32.251 [8], and of usage monitoring control as defined by TS 23.203 [3] shall be preserved.

The following principles shall apply in case of a functional split:

– The Gx, Sd, Gy, Gyn, Gz, Gzn interfaces as well as the interface between SGW and OFCS shall be terminated in the CP function (SGW-C/PGW-C/TDF-C). This implies that the CP function shall support those interfaces towards OCS/OFCS and PCRF, based on information received at the corresponding CP function as well as gathered user-plane related information received from the UP function as further described below.

– There is no impact on PCRF, OCS and OFCS compared to non-split architecture.

– All bearer/traffic flow level, session level and subscriber related information remains at the CP function, and only usage information is requested from UP function.

5.3.2 Activation of usage reporting in UP function

Triggered by the PCC/ADC rules received from the PCRF or preconfigured information available at PGW-C/TDF-C/SGW-C, as well as from the OCS for online charging via Credit-Control session mechanisms, the CP function (PGW-C/TDF-C/SGW-C) shall provide Usage Reporting Rules to the UP function (PGW-U/TDF-U/SGW-U) for controlling how usage reporting is performed.

The CP function shall request the report of the relevant usage information for Usage Monitoring, based on Monitoring Keys and triggers which are specified in TS 23.203 [3] and TS 29.212 [11]. Each Usage Reporting Rule requested for usage monitoring control is associated with the PDR(s) whose traffic is to be accounted under this rule. The CP function shall generate the Usage Reporting Rule for each Monitoring-key within the active PCC/ADC rule(s), either preconfigured or received from the PCRF, and also shall keep the mapping between them. Multiple Usage Reporting Rules may be associated with the same PDR.

The CP function shall request the report of the relevant usage information for offline and online charging, based on Charging keys and additional triggers which are specified in TS 32.251 [8]. Each Usage Reporting Rule requested for offline or online charging is associated with the PDR(s) whose traffic is to be accounted under this rule. The CP function shall generate the Usage Reporting Rule for each Charging key or Sponsor Identity (if applicable) within the active PCC/ADC rule(s), either preconfigured or received from the PCRF, and also shall keep the mapping between them. Multiple Usage Reporting Rules may be associated with the same PDR.

The CP function shall also provide reporting trigger events to the UP function for when to report usage information. The reporting trigger events (e.g. triggers, threshold information etc.) shall be supported for the session (IP-CAN/TDF) level reporting as well as on Rule level basis as determined by the CP function. The triggers may be provided as a volume, time or event to cater for the different charging/usage monitoring models supported by the TS 23.203 [3] for usage monitoring and by TS 32.251 [8] for offline and online charging. The CP function shall decide on the thresholds value(s) based on allowance received from PCRF, OCS or based on local configuration.

In some cases, the same Usage Reporting Rule can be used for different purposes (for both usage monitoring and charging), e.g. in case the same set of PDR(s), measurement method, trigger event, threshold, etc. apply. Similarly a reported measurement can be used for different purposes by the CP function.

5.3.3 Reporting of usage information towards CP function

The UP function shall support reporting of usage information to the CP function. The UP function shall be capable to support reporting based on different triggers, including:

– Periodic reporting with period defined by the CP function.

– Usage thresholds provided by the CP function.

– Report on demand received from the CP function.

The CP function shall make sure that the multiple granularity levels required by the reporting keys in the Usage Reporting rules satisfy the following aggregation levels without requiring a knowledge of the granularity levels by the UP function:

– Session level reporting (IP-CAN/TDF session);

– Bearer (for charging)/traffic flow (for both charging and usage monitoring) level reporting as defined by the reporting keys in the Usage Reporting Rule (see the description above).

Based on the mapping between Monitoring-key and PCC/ADC rule stored at the CP function, the CP function shall combine the reported information with session and subscriber related information which is available at the CP function, for Usage Monitoring reporting over the corresponding Gx, Sd interfaces.

Based on the mapping between Rating Group or Sponsor Identity and PCC/ADC rule stored at the CP function, the CP function shall combine the reported information with session and subscriber related information which is available at the CP function, for offline and online charging reporting over the corresponding Gy, Gyn, Gz, Gzn interfaces.

This functionality is specified in TS 32.240 [9].

The usage information shall be collected in the UP function and reported to the CP function as defined in 5.3.3, based on Monitoring Keys and triggers which are specified in TS 23.203 [3] and TS 29.212 [11].

5.3.4 PGW Pause of Charging

When the UE moves to ECM-IDLE state and the SGW-C decides to activate buffering in SGW-U for the session, it shall also instruct the SGW-U to measure the number of packets/bytes that are buffered or discarded in SGW-U and the criteria for reporting within the Usage Reporting Rule.

Once the trigger of reporting is met, the SGW-U shall inform the SGW-C by reporting usage information.

The SGW-C can then inform the PGW-C as described in TS 23.401 [2].

When the PGW-C determines to stop the charging and usage monitoring actions for the PDN connection, it shall indicate the PGW-U to stop collecting the usage information.

PGW-C sends an Sx session modification request message to the PGW-U and modifies all the Usage Reporting Rules within the PDN connection to indicate the usage collection shall be stopped. When PGW-C determines to continue the charging action for the PDN connection, it sends an Sx session modification request message to the PGW-U and modifies all the Usage Reporting Rules within the PDN connection to indicate the usage collection shall be resumed.

NOTE: The support for PGW pause of charging is optional as described in TS 23.401 [2], and used only if both the SGW-C and the PGW-C support this feature.

5.4 GTP-U IP address and TEIDu allocation

5.4.1 General

Allocation and release of F-TEIDu is performed by SGW and PGW when a bearer needs to be established or released. If functional split into SGW-C/PGW-C and SGW-U/PGW-U is supported, F-TEIDu allocation and release is done in the UP function, as described in clause 5.4.3 below.

The support of F-TEIDu allocation by the UP function is mandatory.

5.4.2 Void

5.4.3 F-TEIDu allocation / release in the UP function

The SGW-U, the SGW-U shall manage the SGW F-TEIDu space, including ensuring that the allocated F-TEIDu(s) are unique as described in TS 29.060 [6]. In case of bearer activation, the SGW-C shall request SGW-U to allocate F-TEIDu(s) for the applicable SGW-U reference points and provide them to the SGW-C. The SGW-C shall provide the F-TEIDu(s) to other network entities as described in TS 23.401 [2] in order to complete the bearer establishment. In case of bearer deactivation, the SGW-C shall request SGW-U to release F-TEIDu(s) for the bearer.

The PGW-U shall manage the PGW F-TEIDu space, including ensuring that the allocated F-TEIDu(s) are unique as described in TS 29.060 [6]. In case of bearer activation, the PGW-C shall request PGW-U to allocate F-TEIDu(s) for the applicable PGW-U reference points and provide them to the PGW-C. The PGW-C shall provide the F-TEIDu(s) to other network entities as described in TS 23.401 [2] and TS 23.402 [4] in order to complete the bearer establishment. In case of bearer deactivation, the PGW-C shall request PGW-U to release F-TEIDu(s) for the bearer.

5.5 UE IP address management (allocation, renewal and release)

The UE IP address management includes allocation and release of the UE IP address as well as renewal of the allocated IP address, where applicable.

The UE IP address management shall be performed by the PGW-C or the PGW-U. As part of this functionality, various UE IP address management mechanisms as defined in clause 5.3.1 of TS 23.401 [2] are supported by the PGW-C. The PGW-C shall process the UE IP address management related messages, maintain the corresponding state information and provide the response messages to the UE.

When Static IP addresses for a PDN Connection are not used, the actual allocation of the UE IP address(es) for a PDN Connection may use any of the following mechanisms:

– The PGW-C allocates the UE IP address from an IP address pool that corresponds to the PGW-U that has been selected.

– The UE IP address is obtained from the PGW-U. In that case the PGW-C shall interact with the PGW-U via Sxb procedures and request the PGW-U to allocate a suitable IP address. The PGW-C provides the PGW-U with the necessary information allowing the PGW-U to derive the proper IP address (e.g. the network instance).

– If the UE IP address is obtained from the external PDN, the PGW-C shall send the allocation, renewal and release related request messages to the external PDN and maintain the corresponding state information. The PGW-U shall support forwarding of the UE IP address management related messages to the PGW-C, when they are received via the user plane signalling from the UE or from the external PDN.

When PGW-C performs IPv4 address allocation via default bearer activation and release via PDN connection release (clause 5.3.1.2.1 of TS 23.401 [2]), no special functionality is required from the PGW-U.

For the other UE IP address management mechanisms, the UE sends the IP address management related request messages via the user plane signalling. Hence the PGW-U is required to forward these request messages to the PGW-C for processing. Once these request messages are processed by the PGW-C, the PGW-C sends response messages to the UE via the user plane signalling. Hence the PGW-C is required to forward these response messages to the PGW-U so that it can be relayed it to the UE. Correspondingly, following functionality is required to be supported by the PGW-C and PGW-U:

– For IPv6 default prefix management via IPv6 stateless address autoconfiguration (clause 5.3.1.2.2 of TS 23.401 [2]): PGW-C shall configure PGW-U to forward Router Solicitation and Neighbor Solicitation messages from the UE to the PGW-C. The PGW-C shall forward Router Advertisement and Neighbor Advertisement messages to the PGW-U for relaying them to the UE.

– For IPv6 parameter configuration via stateless DHCPv6 (clause 5.3.1.2.3 of TS 23.401 [2]): PGW-C shall configure PGW-U to forward all the DHCPv6 messages from the UE to the PGW-C. The PGW-C shall forward the DHCPv6 response messages to the PGW-U for relaying them to the UE.

– For IPv4 address management and parameter configuration DHCPv4 (clause 5.3.1.2.4 of TS 23.401 [2]): PGW-C shall configure PGW-U to forward all the DHCPv4 messages from the UE to the PGW-C. The PGW-C shall forward the DHCPv4 response messages to PGW-U for relaying them to the UE.

– For IPv6 prefix management via IPv6 prefix delegation (clause 5.3.1.2.6 of TS 23.401 [2]): PGW-C shall configure PGW-U to forward all the DHCPv6 messages from the UE to the PGW-C. The PGW-C shall forward the DHCPv6 response messages to PGW-U for relaying them to the UE.

In addition to the above, when the UE IP address is obtained from the external PDN, following functionality is required to be supported by the PGW-C and PGW-U:

– For UE IP address from AAA server in the external PDN: If the AAA server in the external PDN is reachable only via the PGW-U the PGW-C shall configure the PGW-U to forward all the Diameter or RADIUS messages from the AAA server in the external PDN to the PGW-C. And the PGW-C shall forward the Diameter or RADIUS messages to the PGW-U for relaying them to the AAA server in the external PDN.

– For UE IP address from DHCPv4/v6 server in the external PDN: If the DHCPv4/v6 server in the external PDN is reachable only via the PGW-U the PGW-C shall configure the PGW-U to forward all the DHCPv4/v6 messages from the DHCPv4/v6 server in the external PDN to the PGW-C. And the PGW-C shall forward the DHCPv4/v6 messages to the PGW-U for relaying them to the DHCPv4/v6 server in the external PDN.

NOTE: If the AAA server or the DHCPv4/v6 server in the external PDN is reachable directly, then the PGW-C communicates with it directly, without involving the PGW-U.

5.6 Control of user plane forwarding

5.6.1 General

One of the main tasks of the Sx interface is to enable the CP function to instruct the UP function about how to forward user data traffic. There are several different user plane forwarding scenarios supported. Some scenarios are applicable to SGW only or PGW only, while other scenarios are applicable to SGW and PGW or PGW and TDF. A non-exhaustive list of forwarding scenarios is provided in Table 5.6.2-1 below.

The CP function shall be able to provide the UP with instructions for at least the following behaviors: forward, forward with end marker. The CP function shall also be able to request multiple sets of forwarding instructions to be performed in sequence, e.g. forward to the DL side and forward to the CP function for the purpose of duplication.

5.6.2 Control of user plane forwarding

The CP function controls user-plane packet forwarding for traffic detected by a PDR by providing FAR(s) with instructions to the UP function, including:

– Forwarding operation information;

– Forwarding target information.

The details of the forwarding target and operation will depend on the scenario and is described in Table 5.6.2-1 below. The following forwarding functionality is required by the UP function (more than one forwarding scenario can be active for the same traffic):

– Apply GTP-U bearer related handling, i.e. encapsulation, de-capsulation or both. (This covers scenario 1 in the table below).

– Forward the traffic to the CP function (This covers scenario 2, 3, 4 in the table below).

– Apply locally configured policy for traffic steering. (This covers scenario 5 in the table below).

Further details on the forwarding related information are provided in clause 7.5.

Table 5.6.2-1: Forwarding information for different scenarios

	Scenario description	Forwarding target and operation	Applicable to
1	Forwarding of user-plane between UE and PDN, including mapping onto GTP-U tunnels and mapping between GTP-U tunnels	GTP-U encapsulation information (F-TEID)	SGW, PGW
2	Forwarding of user-plane packets from UE and CP function (e.g. RS/RA, DHCPv4/v6, traffic subject to HTTP redirect etc)	Information that the CP function is source/target (CP function IP address)	PGW
3	Forwarding of packets from the external PDN / SGi and the CP function (e.g. for RADIUS, Diameter and DHCP signalling, traffic subject to HTTP redirect etc)	Information that the CP function is source/target (CP function IP address)	PGW
4	Forwarding of packets subject to buffering in CP function	Information that the CP function is source/target (CP function IP address)	SGW
5	Forwarding of packets between the UP function and the SGi-LAN for Flexible Mobile Service Chaining	Reference to a predefined traffic steering configuration (e.g. Traffic-Steering Policy identifier)	PGW, TDF

5.6.3 Format of forwarded user plane data

For forwarding between the CP function and UP function the user plane packet is forwarded via an Sx-u tunnel by encapsulating the user-plane packet using GTP-U protocol that allows the receiving entity to identify which PDN Connection and which bearer the traffic belongs to. In the direction from the CP function to UP function for forwarding towards the UE or PDN, the UP encapsulation protocol also shall contain information that allows the UP function to identify whether the UE or PDN is targeted.

NOTE: The Sx-u tunnel may be established per bearer of a PDN connection, or per PDN or per UP function. The details of Sx-u tunnel are defined in TS 29.244 [12].

5.7 UE’s permanent identifier usage

For the scenarios requiring UE’s permanent identity at the UP function, e.g. UP function performing http header enrichment in a trusted environment, the UE’s permanent identity may be provided from the CP function to the UP function in a container, instead of in an Sx parameter.

NOTE: In an untrusted environment in which the UE’s permanent identity cannot be provided, due to e.g. to fulfil the privacy requirements, the session identifier is used between the CP function and UP function for correlating UE’s session related events.

5.8 Functionality of sending of "end marker"

Sending of "end marker" is a functionality which involve SGW-C and SGW-U, and PGW-C and PGW-U. As part of the functionality, constructing of end marker packets can either be done in the CP function or in the UP function, as described in clauses 5.8.1 and 5.8.2. Whether constructing of end marker packets is performed by CP function or UP function is determined by network configuration.

5.8.1 UP function constructing the "end marker" packets

In case of eNodeB relocation during handover procedure without SGW-U change, SGW-C shall indicate the SGW-U to switch the S1 path(s) by sending an Sx session modification request message with the new F-TEID-u of eNodeB and in addition, provide an indication to the SGW-U to send the end marker packet(s) on the old path.

On receiving this indication, the SGW-U shall construct end marker packet(s) and send it for each S1 GTP-U tunnel towards the source eNodeB after sending the last PDU on the old path.

In case of SGW-U relocation during handover procedure, PGW-C shall indicate the PGW-U to switch the S5/S8 path(s) by sending an Sx session modification request message (bearer ID, new F-TEID of SGW-U) and in addition, provide an indication to the PGW-U to send the end marker packet(s) on the old path.

On receiving this indication, the PGW-U shall construct end marker packet(s) and send it for each S5/S8 GTP-U tunnel towards the source SGW-U after sending the last PDU on the old path.

On receiving the end marker packet(s) on S5/S8 GTP-U tunnel, SGW-U shall forward the end marker packet(s) and send it for each S1 GTP-U tunnel towards the source eNodeB.

5.8.2 CP function constructing the "end marker" packets

In case of eNodeB relocation during handover procedure without SGW-U change, SGW-C shall indicate the SGW-U to switch the S1 path(s) by sending an Sx session modification request message (bearer ID, new F-TEID of eNodeB). After sending the last PDU on the old path, SGW-U shall replace the old F-TEID with the new one and responds with an Sx session modification response message to acknowledge the success of path switch.

When the path switch is finished, SGW-C constructs the end marker packet(s) and sends it to the SGW-U. SGW-U then forwards the packet(s) to the source eNodeB.

In case of SGW-U relocation during handover procedure, PGW-C shall indicate the PGW-U to switch the S5/S8 path(s) by sending an Sx session modification request message (bearer ID, new F-TEID of SGW-U). After sending the last PDU on the old S5/S8 path, PGW-U shall replace the old F-TEID with the new one and responds with an Sx session modification response message to acknowledge the success of path switch.

When the path switch is finished, PGW-C constructs the end marker packet(s) and sends it to PGW-U. PGW-U then forwards the packet(s) to the source SGW-U.

5.9 Idle state packet SGW buffering function

5.9.1 General

Buffering of the UE’s data packets for the UE in idle or power saving mode can be performed in SGW-U or SGW-C.

The support of buffering in the SGW-U is mandatory and the SGW-C shall support buffering by the SGW-U.

The support of buffering in the SGW-C is optional and the SGW-U optionally supports buffering by the SGW-C. An exception is that in a dedicated core network serving UEs which may enter power saving mode or apply eDRX, e.g. NB-IoT UEs, the SGW-C shall support buffering capability.

When buffering is supported in both SGW-C and SGW-U, the SGW-C decides on a per UE session basis (e.g. based on local configuration and other information such as UE capability) to perform buffering in either the SGW-C or the SGW-U.

5.9.2 Buffering in CP function

When the UE moves to ECM-IDLE state, if the SGW-C supports buffering capability and decides to activate buffering, the SGW-C shall inform the SGW-U to stop sending data packets to eNodeB and start forwarding the downlink data packets towards the SGW-C.

When the UE transition to the ECM-CONNECTED state, the SGW-C shall update the SGW-U via Sxa interface with the F-TEIDu of the eNodeB. If there are buffered packets available and their buffering duration has not expired, the SGW-C shall forward those packets to the SGW-U outside of the control plane signalling (see clause 5.6.3 "Format of forwarded user plane data") to relay them to the UE. These packets are then forwarded by the SGW-U to the eNodeB.

5.9.3 Buffering in UP function

5.9.3.1 General

The SGW-C shall be able to provide the SGW-U with instructions for at least the following behaviors: buffer without reporting the arrival of first downlink packet, buffer with reporting the arrival of first downlink packet, drop packets.

When the UE moves to ECM-IDLE state, if the SGW-C does not support buffering capability, or if the SGW-C supports buffering capability and decides to activate buffering in SGW-U for the session, the SGW-C shall inform the SGW-U, via an Sx session modification. The SGW-C decides whether buffering timers are handled by the SGW-U or by the SGW-C. The activation of buffering implicitly stops sending data to the eNodeB/RNC/SGSN.

After starting the buffering, when the first downlink packet arrives on any bearer, SGW-U shall inform the SGW-C. SGW-U sends an Sx reporting message to the SGW-C unless specified otherwise and identifies the S5/S8 bearer on which the downlink packet was received.

On receiving this reporting message, the SGW-C decides whether to send a Downlink Data Notification message to the MME as defined in TS 23.401 [2].

At the UE transition to ECM-CONNECTED state, the SGW-C shall update the SGW-U via Sxa interface with the F-TEIDu of the eNodeB/RNC/SGSN. The buffered data packets, if any, are then forwarded to the eNodeB/RNC/SGSN by the SGW-U.

In case of SGW-U relocation, buffered data packets are transferred from the old SGW-U to the new SGW-U.

5.9.3.2 Delay Downlink Packet Notification

According to clause 5.3.4.2 of TS 23.401 [2], the MME/SGSN may inform the SGW that for all UEs served by the MME/SGSN, the Downlink Packet Data Notification shall be delayed for a period D.

If the parameter D is handled by the SGW-U, the SGW-C shall include the parameter D in the Sx session establishment for new Sx sessions, in the Sx session modification for Sx sessions which are not in buffering state (when transitioning these sessions to the buffering state), and in the next Sx report ack message for Sx sessions already in buffering state. The SGW-U shall then delay the sending of subsequent Sx reporting upon next DL data arrival.

If the parameter D is handled by the SGW-C, there is no special handling compared to clause 5.9.3.1. When the SGW-U reports the arrival of a DL data packet, the SGW-C shall delay the sending of the Downlink Data Notification to the MME by parameter D delay.

5.9.3.3 Extended buffering

According to clauses 5.3.4.3 and 5.7.3 of TS 23.401 [2], the MME/SGSN invoking extended buffering indicates it to the Serving GW in the Downlink Data Notification Ack message, includes a DL Buffering Duration time and optionally a DL Buffering Suggested Packet Count.

If the MME/SGSN included the DL Suggested Packet Count, the SGW-C shall include the DL Suggested Packet Count in the Sx reporting Ack message.

If the DL Data Buffer Expiration Time is handled by the SGW-U, the SGW-C includes it in the Sx reporting Ack message and requests the SGW-U to buffer DL data packets. When the SGW-U receives the DL Data Buffer Expiration Time, the SGW-U buffers the DL data packets without reporting the arrival of the first DL data packet until the DL Data Buffer Expiration Time expires. When the DL Data Buffer Expiration Time expires, the SGW-U shall discard the buffered DL packets and shall restart buffering DL data packets with reporting the arrival of the first DL data packet.

If the DL Data Buffer Expiration Time is handled by the SGW-C, the SGW-C requests the SGW-U to buffer the DL data packets without reporting the arrival of the first DL data packet. When the DL Data Buffer Expiration Time expires, the SGW-C requests the SGW-U to drop the buffered data packets and to start buffering the DL data packets with reporting of the arrival of the first DL data packet, via an Sx Session Modification.

If the DL Suggested Packet Count was included in the request from the SGW-C, the SGW-U buffers the DL data packets up to the number of packets indicated by the DL Suggested Packet Count.

5.9.3.4 Throttling

According to clause 4.3.7.4.1a of TS 23.401 [2], the MME/SGSN can request the SGWs to selectively reduce the number of Downlink Data Notification requests it sends for downlink non-priority traffic received for UEs in idle mode according to a throttling factor and for a throttling delay specified in the Downlink Data Notification Ack message.

Throttling mechanism by which the MME uses Downlink Data Notification Acknowledgement messages DL low priority traffic Throttling parameters, is handled by the SGW-C as follows:

– On receiving Downlink Data Notification Acknowledgement from the MME/SGSN, the SGW-C determines which bearers are subject to the throttling of Downlink Data Notification requests on the basis of the bearer’s ARP priority level and the operator policy.

– Upon receipt of an Sx report notifying the arrival of DL data packets on those bearers, the SGW-C decides whether or not to send a DDN to MME based on the requested throttling factor. The SGW-C may indicate in the Sx Report Ack whether SGW-U shall discard the buffered packet and may also indicate whether SGW-U shall notify when additional DL packets arrive.

– The throttling delay timer and throttling factor are handled by the SGW-C and not provided to SGW-U.

5.10 Bearer and APN policing

ARP is used for admission control (i.e. retention and pre-emption of the bearer). The value of ARP is not required to be provided to the UP function.

For every bearer, SGW-C/PGW-C shall use the QCI and optionally, the ARP priority level, to determine the transport level packet marking and provide the transport level packet marking to the SGW-U/PGW-U.

PGW-C shall provide the APN-AMBR value together with a QoS Enforcement Rule correlation ID (as described in clause 7.6) to PGW-U so that the PGW-U can enforce the APN-AMBR across all IP‑CAN sessions of the UE to the same APN at the PGW-U.

SGW-C/PGW-C shall provide the GBR and MBR value for each GBR bearer of the PDN connection to the SGW-U/PGW-U. When the Gn/Gp interface is used by the PGW-U, PGW-C shall also provide the MBR value to the PGW-U for each non-GBR bearer of the PDN connection on the Gn/Gp interface.

TDF-C shall provide the TDF session MBR value to TDF-U to be applied to the TDF session of the UE.

5.11 PCC/ADC related functions

5.11.1 Activation/Deactivation of predefined PCC/ADC rules

A predefined PCC/ADC rule is configured in the CP function.

The traffic detection filters required in the UP function can be configured either in the CP function and provided to the UP function, as service data flow filter(s), or be configured in the UP function, as the application detection filter identified by an application identifier. For the latter case, the application identifier has to be configured in the CP function and the UP function.

The traffic steering policy information can be only configured in the UP function, together with traffic steering policy identifier(s), while the CP function has to be configured with the traffic steering policy identifier(s).

Policies for traffic handling in the UP function, which are referred by some identifiers corresponding to the parameters of a PCC/ADC rule, can be configured in the UP function. These traffic handling policies are configured as predefined QER(s), FAR(s) and URR(s).

When a predefined PCC/ADC rule is activated/deactivated by the PCRF, PGW-C/TDF-C shall decide what information has to be provided to the PGW-U/TDF-U to enforce the rule based on where the traffic detection filters (i.e. service data flow filter(s) or application detection filter), traffic steering policy information and the policies used for the traffic handling in the UP function are configured and where they are enforced:

– If the predefined PCC/ADC rule contains an application identifier for which corresponding application detection filters are configured in the UP function, the PGW-C/TDF-C shall provide a corresponding application identifier to the UP function;

– If the predefined PCC/ADC rule contains traffic steering policy identifier(s), the PGW-C/TDF-C shall provide a corresponding traffic steering policy identifier(s) to the UP function;

– If the predefined PCC/ADC rule contains service data flow filter(s), the PGW-C/TDF-C shall provide them to the PGW-U/TDF-U;

– If the predefined PCC/ADC rule contains some parameters for which corresponding policies for traffic handling in the UP function are configured in the UP function, the PGW-C/TDF-C shall activate those traffic handling policies via their rule ID(s).

The CP function shall maintain the mapping between a PCC/ADC rule received over Gx/Sd and the flow level PDR rule(s) used on Sx.

5.11.2 Enforcement of dynamic PCC/ADC rules

The application detection filters required in the UP function can be configured either in the CP function and provided to the UP function as the service data flow filter, or be configured in the UP function identified by an application identifier.

When receiving a dynamic PCC/ADC rule from the PCRF which contains an application identifier and/or parameters for traffic handling in the UP function:

– if the application detection filter is configured in the PGW-C/TDF-C, the PGW-C/TDF-C shall provide it in the service data flow filter to the UP function, as well as parameters for traffic handling in the UP function received from the dynamic PCC/ADC rule;

– otherwise, the application detection filters is configured in UP function, the PGW-C/TDF-C shall provide to PGW-U/TDF-U with the application identifier and the parameters for traffic handling in the UP function as required based on the dynamic PCC/ADC rule.

The CP function shall maintain the mapping between a PCC/ADC rule received over Gx/Sd and the flow level PDR(s) used on Sx.

5.11.3 Redirection

The uplink application’s traffic redirection may be enforced either in the PGW-C/TDF-C (as specified in 5.4.2 Control of user plane forwarding) or directly in the UP function. The redirect destination may be provided in the dynamic PCC/ADC rule or be preconfigured, either in the CP function or in the UP function.

When receiving redirect information (redirection enabled/disabled and redirect destination) within a dynamic PCC/ADC rule or being activated/deactivated by the PCRF for the predefined redirection policies, PGW-C/TDF-C shall decide whether to provide and what information to be provided to the UP function based on where the redirection is enforced and where the redirect destination is acquired/preconfigured. When redirection is enforced in the UP function and the redirect destination is acquired from the dynamic PCC/ACD rule or is configured in the CP function, CP function shall provide the redirect destination to the UP function. When redirection is enforced in the CP function, CP function shall instruct the UP function to forward applicable user plane traffic to the CP function.

5.11.4 Support of SDCI

PFDF shall provide PFD(s) to the PGW-C/TDF-C on the request of PGW-C/TDF-C (pull mode) or on the request of PFD management from SCEF (push mode), as described in TS 23.203 [3]. The PGW-C/TDF-C shall provide the PFD(s) to the PGW-U/TDF-U, on which the Application ID corresponding to the PFD(s) is active.

The PGW-C/TDF-C supports the procedures for Gw/Gwn as specified in TS 23.203 [3], for management of PFDs. PFD(s) is cached in the PGW-C/TDF-C, and the PGW-C/TDF-C maintains a caching timer associated to the PFD(s). When the caching timer expires and there’s no active PCC/ADC rule that refers to the corresponding application identifier, the PGW-C/TDF-C informs the PGW-U/TDF-U to remove the PFD(s) identified by the application identifier using the PFD management message.

When a PDR is provided for an Application ID corresponding to the PFD(s) that are not already provided to the PGW-U/TDF-U, the PGW-C/TDF-C shall provide the PFD(s) to the PGW-U/TDF-U (if there are no PFD(s) cached, the PGW-C/TDF-C retrieves them from the PFDF as specified in TS 23.203 [3]). When any update of the PFD(s) is received from PFDF by PGW-C/TDF-C (using "push" or "pull" mode), and there are still active PDRs in PGW-U/TDF-U for the Application ID, the PGW-C/TDF-C shall provision the updated PFD set corresponding to the Application ID to the PGW-U/TDF-U using the PFD management message.

NOTE 1: PGW-C/TDF-C should assure not to overload Sx signalling while managing PFD(s) to the UP function, e.g. forwarding the PFD(s) to the right UP function where the PFD(s) is enforced.

When the PGW-U/TDF-U receives the updated PFD(s) from either the same or different PGW-C/TDF-C for the same application identifier, the latest received PFD(s) shall overwrite any existing PFD(s) stored in the UP function.

NOTE 2: For the case a single UP function is controlled by multiple CP functions, the conflict of PFD(s) corresponding to the same application identifier provided by different CP functions should be avoided by operator enforcing a well-planned PFDF and CP/UP function 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 Sx session and the PGW-U/TDF-U has reported the application start as described in clause 6.4.2 to the PGW-C/TDF-C for the application instance corresponding to this PFD, the PGW-U/TDF-U shall report the application stop to the PGW-C/TDF-C for the corresponding application instance identifier if the removed/modified PFD in PGW-U/TDF-U 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 PFDF override any PFDs pre-configured in the PGW-C/TDF-C. When all the PFDs retrieved from the PFDF for an application identifier are removed, the pre-configured PFDs are used. The PGW-C/TDF-C shall provide either the PFDs retrieved from PFDF or the pre-configured PFDs for an application identifier to the PGW-U/TDF-U as specified in clause 6.5.2.

5.12 User Plane function selection

5.12.1 General

The selection of the UP function (SGW-U, PGW-U, TDF-U, combined SGW/PGW-U) is performed by its respective CP function (SGW-C, PGW-C, TDF-C, combined SGW/PGW-C).

The UP function’s capabilities shall be signalled during the initial connection establishment between the CP function and the UP function.

The CP function shall be made dynamically aware on the UP function load and relative static capacity for which it has an established Sx session as specified in the clauses below.

The exact set of parameters used for the selection mechanism is deployment specific and controlled by the operator configuration, e.g. UE capabilities such as the UE support for dual connectivity with NR, and, the UE’s location information may be used for selecting UP function in some deployments while may not be used in other deployments.

5.12.2 Selection of PGW-U

For PGW-U selection, the PGW-C shall be able to consider the following parameters:

– the PGW-U’s dynamic load, at the node level (the PGW-C may then derive the load at the APN level);

– the PGW-U’s relative static capacity (among PGW-Us supporting the same APN);

– the PGW-U location configured in the PGW-C and the UE location information provided by the MME/SGSN in order to select the appropriate PGW-U, e.g. for SIPTO above RAN service;

– the capability of the UP function and the functionality required for the particular UE session: An appropriate UP function can be selected by matching the functionality and features required for an UE (which can be derived from the information received over S11/S4/S5/S8 (e.g. APN, mapped UE Usage Type, UE location information, UE capabilities (e.g. UE support for dual connectivity with NR)) or from the PCRF (e.g. need to perform DPI)) with the capabilities of the UP function so as to fulfil the service for the UE, e.g. if L7 based traffic detection is needed then an UP function supporting corresponding functionality needs to be selected.

– to enable APN-AMBR enforcement, whether a PDN connection already exists for the same UE and APN, in which case the same PGW-U shall be selected;

The criteria for PGW-U selection may include load balancing between PGW-Us.

The PGW-C may support the Sx Load Control feature.

In order to allow the PGW-C to select a PGW-U according to above parameters:

– the SGW-C shall provide the relevant UE’s capabilities when available (e.g. UE support for dual connectivity with NR) over the S5/S8 interface.

– the SGW-C may provide the mapped UE Usage Type over the S5 interface.

5.12.3 Selection of SGW-U

For SGW-U selection, the SGW-C shall be able to consider the following parameters:

– the SGW-U location (e.g. SGW Service Area) and the UE location information, provided by the MME/SGSN in order to select a UP function close to the UE’s point of attachment;

– the SGW-U’s dynamic load;

– the SGW-U’s relative static capacity (versus other SGW-Us);

– the capability of the UP function and the functionality required for the particular UE session: An appropriate UP function can be selected by matching the functionalities and features required for an UE (which can be derived from the information received over S11/S4 (e.g. individual CIoT capabilities, UE Usage Type, the APN (for selection of combined SGW/PGW), UE capabilities (e.g. UE support for dual connectivity with NR)) with the capabilities of the UP function so as to fulfil the service requirement for the UE then a UP function supporting corresponding functionality needs to be selected.

The criteria for SGW-U selection may include load balancing between SGW-Us.

The SGW-C may support the Sx Load Control feature.

In order to allow the SGW-C to select a SGW-U according to the above parameters:

– the MME/SGSN shall provide the location of the UE (i.e. ECGI, eNB or TAI for E-UTRAN, and RAI or RNC-ID for UTRAN), the APN (for selection of a combined SGW/PGW), relevant UE capabilities when available (e.g. UE support for dual connectivity with NR) and may provide the mapped UE Usage Type in the Create Session Request over the S11/S4 interface;

NOTE: MME sets the UE support for dual connectivity with NR indication when the UE indicates support for NR and there is no Access Restriction for NR for the UE (see clause 4.3.2a of TS 23.401 [2]).

5.12.4 Selection of a combined SGW/PGW-U

A combined SGW/PGW-C selects the SGW-U and PGW-U as defined respectively in clauses 5.12.3 and 5.12.4, with the following addition:

– The SGW-C determines that it is a combined SGW/PGW-C entity the same way as in the non-split case;

– The combined SGW/PGW-C may optimize UP function selection by selecting the best couple of SGW-U and PGW-U for the requested APN, among all candidate couples of (SGW-U, PGW-U), instead of selecting independently the SGW-U first and then the PGW-U (which may result in selecting non-co-located SGW-U and PGW-U).

5.12.5 Selection of TDF-U

5.12.5.1 Solicited application reporting mode

TDF-C shall select TDF-U at PDN connection establishment (TDF session establishment).

The selection may be based on the following parameters:

– the TDF-U’s dynamic load;

– the TDF-U’s relative static capacity;

– the capability of the UP function and the functionalities and the capabilities required for the particular UE session: An appropriate UP function can be selected by matching the functionalities and features required for the UE from the PCRF.

The criteria for TDF-U selection includes load balancing between TDF-Us.

The TDF-C may support the Sx Load Control feature.

5.12.5.2 Unsolicited application reporting mode

The selection of TDF-U for the unsolicited application reporting is performed by TDF-C during the Sx management procedure, using the information configured in TDF-C.

NOTE: TDF-C provides the instructions for application detection and reporting to the TDF-U during the Sx session management procedure. TDF-U shall communicate with the TDF-C (using the same Sx session) when application reporting is necessary, based on instructions provided by TDF-C.

5.13 Support for L2TP tunneling on SGi

If requested by the PGW-C during Sx Session Establishment, the PGW-U may setup L2TP towards an L2TP network server (LNS) in the DN and tunnel the PDN Connection user plane traffic in L2TP. In this case the PGW-U acts as a L2TP access concentrator (LAC). To enable this, the PGW-C may provide L2TP information to the PGW-U, such as LNS IP address and/or LNS host name, as described in TS 29.244 [12]. This L2TP information may be configured on the PGW-C as part of the APN configuration or received from a AAA server, as described in TS 29.061 [14]. Alternatively, the L2TP tunnel parameters may be configured in the PGW-U. The L2TP tunnel parameters include necessary parameters for setting up L2TP tunnel towards the LNS (e.g. LNS address, tunnel password, etc.).

In addition, the PGW-C may provide PAP/CHAP authentication information to the PGW-U, for use in L2TP session establishment, in case it was received from the UE in the PCO of the PDN Connection Establishment Request.

When L2TP is to be used for a PDN Connection, the PGW-C may select a PGW-U based upon support of this feature. The PGW-C determines whether the PGW-U supports this feature via Sx capability negotiation during Sx Association Setup.

If the PGW-C requests the PGW-U to allocate a UE IP address as described in clause 5.5, the PGW-U (LAC) may retrieve this IP address from the LNS. In addition, if the PGW-C requests the PGW-U to provide DNS server address(es), the PGW-U (LAC) may request the LNS to provide DNS server address(es) and report such DNS server address(es) to the PGW-C.