Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.214  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   4.3…   5…   5.6…   5.10…   6…   6.3…   6.3.1.2   6.3.1.3…   6.3.1.6…   6.3.2…   6.3.3…   6.3.3.4…   6.3.3.7…   6.3.4…   6.3.4.2…   6.3.4.2.2   6.3.4.3   6.4…   7…

 

5.6  Control of user plane forwardingp. 27

5.6.1  Generalp. 27

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.
Up

5.6.2  Control of user plane forwardingp. 27

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.
Scenario description Forwarding target and operation Applicable to
1Forwarding of user-plane between UE and PDN, including mapping onto GTP-U tunnels and mapping between GTP-U tunnelsGTP-U encapsulation information (F-TEID)SGW, PGW
2Forwarding 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
3Forwarding 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
4Forwarding of packets subject to buffering in CP functionInformation that the CP function is source/target (CP function IP address)SGW
5Forwarding of packets between the UP function and the SGi-LAN for Flexible Mobile Service ChainingReference to a predefined traffic steering configuration (e.g. Traffic-Steering Policy identifier)PGW, TDF
Up

5.6.3  Format of forwarded user plane datap. 27

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.
Up

5.7  UE's permanent identifier usagep. 28

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.
Up

5.8  Functionality of sending of "end marker"p. 28

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.
Up

5.8.1  UP function constructing the "end marker" packetsp. 28

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.
Up

5.8.2  CP function constructing the "end marker" packetsp. 28

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.
Up

5.9  Idle state packet SGW buffering functionp. 29

5.9.1  Generalp. 29

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.
Up

5.9.2  Buffering in CP functionp. 29

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.
Up

5.9.3  Buffering in UP functionp. 29

5.9.3.1  Generalp. 29

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.
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.
Up

5.9.3.2  Delay Downlink Packet Notificationp. 29

According to clause 5.3.4.2 of TS 23.401, 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.
Up

5.9.3.3  Extended bufferingp. 30

According to clauses 5.3.4.3 and 5.7.3 of TS 23.401, 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.
Up

5.9.3.4  Throttlingp. 30

According to clause 4.3.7.4.1a of TS 23.401, 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.
Up

Up   Top   ToC