GTPv2-C | Core Network: Architecture and Signaling Procedures

5.3. GTPv2-C

5.3.1. Technical Overview

GTP version 2 for the control plane (GTPv2-C) is the control-plane signaling protocol of the EPC, and network nodes use it to create, modify, and delete GTP tunnels and EPS bearers, and to exchange mobility management information.

GTPv2-C runs over the User Datagram Protocol (UDP), on port 2123, and because UDP does not guarantee delivery, a GTPv2-C entity retransmits a request message if it does not receive a response before a timer expires.

GTPv2-C messages fall into eight categories: Path Management Messages, Tunnel Management Messages, Mobility Management Messages, CS Fallback and SRVCC related messages, Non-3GPP access related messages, Restoration and Recovery messages, Trace Management Messages, and MBMS Messages. The Message Categories section below lists the messages in each category.

GTPv2-C applies over the S3, S4, S5, S8, S10, S11, S16, Sv, S101, S121, Sm, Sn, S2a, and S2b interfaces.

A GTPv2-C message can carry a second, piggybacked GTPv2-C message inside the same IP/UDP packet, to avoid an extra signaling round trip; the network uses piggybacking for two message pairs, a Create Session Response that carries a piggybacked Create Bearer Request and a Create Bearer Response that carries a piggybacked Modify Bearer Request. The network uses these combinations during the E-UTRAN Initial Attach procedure, a handover from non-3GPP access to E-UTRAN, and the UE-requested PDN connectivity procedure.

5.3.2. Packet Format

Control Plane GTP uses a variable-length header, with a length that is always a multiple of 4 octets, and GTPv2-C defines two header formats.

5.3.2.1. Header Without a Tunnel Endpoint Identifier

The Echo Request, Echo Response, and Version Not Supported Indication messages use the header without a Tunnel Endpoint Identifier (TEID), which is 8 octets long.

Figure 9. GTPv2-C header without a TEID

Version: Bits 8 to 6 of octet 1. This field states the GTP version, and GTPv2-C sets it to decimal 2.
P: Bit 5 of octet 1. This is the Piggybacking flag; a value of 0 means the message carries no piggybacked message.
T: Bit 4 of octet 1. This is the TEID flag; a value of 0 means the header carries no TEID field.
Message Type: Octet 2. This field states the message type, with a unique value for each GTPv2-C message.
Message Length: Octets 3 to 4. This field states the length of the message in octets, excluding the first 4 octets of the header.
Sequence Number: Octets 5 to 7. This field identifies the request or response, and a node uses it to match a response to its request and to detect retransmissions.

5.3.2.2. Header With a Tunnel Endpoint Identifier

Apart from the Echo and Version Not Supported Indication messages, every GTPv2-C message uses the header with a TEID, which is 12 octets long.

Figure 10. GTPv2-C header with a TEID

TEID: Octets 5 to 8. This field identifies a tunnel endpoint in the receiving entity of GTP for the control plane (GTP-C), and the sending entity sets it to the value that the receiving entity provided.
MP: Bit 3 of octet 1. This is the Message Priority flag; a value of 1 means octet 12 carries a valid Message Priority value. The Load and Overload Control section below describes how a node uses this flag.
Message Priority: Bits 8 to 5 of octet 12. This field states the relative priority of the message, as a value from 0 to 15, where 0 is the highest priority and 15 is the lowest, and it is valid only when the MP flag is set to 1.

5.3.3. Message Categories

5.3.3.1. Path Management Messages

Path management messages check that a GTPv2-C peer is alive and reachable.

Message Functionality Interfaces

Message	Functionality	Interfaces
`Echo Request`	Checks that a peer GTP-C node is alive, and carries the sender’s Restart Counter.	All GTPv2-C interfaces.
`Echo Response`	Confirms that the node is alive, and reports its own Restart Counter and the features it supports.	All GTPv2-C interfaces.
`Version Not Supported Indication`	Tells the sender of an unsupported-version message which GTP version the receiving node supports.	All GTPv2-C interfaces.

Echo Request

Checks that a peer GTP-C node is alive, and carries the sender’s Restart Counter.

All GTPv2-C interfaces.

Echo Response

Confirms that the node is alive, and reports its own Restart Counter and the features it supports.

All GTPv2-C interfaces.

Version Not Supported Indication

Tells the sender of an unsupported-version message which GTP version the receiving node supports.

All GTPv2-C interfaces.

5.3.3.2. Tunnel Management Messages

Tunnel management messages create, modify, and delete GTP tunnels and EPS bearers, and carry other session-level signaling between the MME or the Serving GPRS Support Node (SGSN), the SGW-C, and the PGW-C.

Message Functionality Interfaces

Message	Functionality	Interfaces
`Create Session Request`	Creates a new PDN connection and its default EPS bearer.	S11, S4, S5, S8, S2a, S2b.
`Create Session Response`	Reports the outcome of a `Create Session Request`, and returns the allocated addresses and bearer parameters.	S11, S4, S5, S8, S2a, S2b.
`Create Bearer Request`	Creates one or more dedicated EPS bearers for an existing PDN connection.	S11, S4, S5, S8, S2a, S2b.
`Create Bearer Response`	Reports the outcome of a `Create Bearer Request`.	S11, S4, S5, S8, S2a, S2b.
`Bearer Resource Command`	Forwards a UE request for a new bearer resource or a change to an existing one, for example a QoS change or an IP flow mobility update.	S11, S4, S5, S8, S2a, S2b.
`Bearer Resource Failure Indication`	Reports that the network could not honor a `Bearer Resource Command`.	S11, S4, S5, S8, S2a, S2b.
`Modify Bearer Request`	Updates the parameters of an existing EPS bearer, for example the eNodeB’s downlink address after a handover or a service request.	S11, S5, S8.
`Modify Bearer Response`	Reports the outcome of a `Modify Bearer Request`.	S11, S4, S5, S8, S2b.
`Delete Session Request`	Deletes a PDN connection and its EPS bearers.	S11, S4, S5, S8, S2a, S2b.
`Delete Bearer Request`	Deletes one or more dedicated EPS bearers, without deleting the whole PDN connection.	S11, S4, S5, S8, S2a, S2b.
`Delete Session Response`	Reports the outcome of a `Delete Session Request`.	S11, S4, S5, S8, S2a, S2b.
`Delete Bearer Response`	Reports the outcome of a `Delete Bearer Request`.	S11, S4, S5, S8, S2a, S2b.
`Downlink Data Notification`	Tells the MME/SGSN that the SGW-C received downlink data, or downlink signaling, for a UE in idle mode, to start paging.	S11, S4.
`Downlink Data Notification Acknowledge`	Confirms that the MME/SGSN accepted a `Downlink Data Notification` and attempts to reach the UE.	S11, S4.
`Downlink Data Notification Failure Indication`	Tells the SGW-C that a paging attempt failed, for example because the UE did not respond.	S11, S4.
`Delete Indirect Data Forwarding Tunnel Request`	Tells the SGW-C to release an indirect data-forwarding tunnel that a handover procedure set up.	S11, S4.
`Delete Indirect Data Forwarding Tunnel Response`	Reports the outcome of a `Delete Indirect Data Forwarding Tunnel Request`.	S11, S4.
`Modify Bearer Command`	Asks the PGW-C to apply a subscribed QoS change that the HSS pushed down for a UE’s default bearer.	S11, S4, S5, S8, S2a, S2b.
`Modify Bearer Failure Indication`	Reports that the PGW-C could not apply the QoS change requested in a `Modify Bearer Command`.	S11, S4, S5, S8, S2a, S2b.
`Update Bearer Request`	Changes the QoS or the TFT of an existing EPS bearer, at the request of the PGW-C or the PCRF.	S11, S4, S5, S8, S2a, S2b.
`Update Bearer Response`	Reports the outcome of an `Update Bearer Request`.	S11, S4, S5, S8, S2a, S2b.
`Delete Bearer Command`	Asks the SGW-C/PGW-C to deactivate one or more dedicated EPS bearers, without deleting the PDN connection.	S11, S4, S5, S8.
`Delete Bearer Failure Indication`	Reports that the PGW-C could not deactivate the bearers requested in a `Delete Bearer Command`.	S11, S4, S5, S8.
`Create Indirect Data Forwarding Tunnel Request`	Sets up an indirect data-forwarding tunnel at the SGW-C, to forward buffered downlink data during a handover.	S11, S4.
`Create Indirect Data Forwarding Tunnel Response`	Reports the outcome of a `Create Indirect Data Forwarding Tunnel Request`.	S11, S4.
`Release Access Bearers Request`	Asks the SGW-C to release the radio and S1-U (or Iu) user-plane bearers for a UE that enters idle mode, while keeping the PDN connection.	S11, S4.
`Release Access Bearers Response`	Reports the outcome of a `Release Access Bearers Request`.	S11, S4.
`Stop Paging Indication`	Tells the MME/SGSN to stop paging a UE, for example because the network already reached it another way.	S11, S4.
`Modify Access Bearers Request`	Updates only the eNodeB’s user-plane addresses at the SGW-C for a UE’s bearers, without involving the PGW-C.	S11.
`Modify Access Bearers Response`	Reports the outcome of a `Modify Access Bearers Request`.	S11.
`Remote UE Report Notification`	Tells the SGW-C/PGW-C that a remote UE, reached through a ProSe UE-to-Network Relay, connected or disconnected.	S11, S5, S8.
`Remote UE Report Acknowledge`	Reports the outcome of a `Remote UE Report Notification`.	S11, S5, S8.

Create Session Request

Creates a new PDN connection and its default EPS bearer.

S11, S4, S5, S8, S2a, S2b.

Create Session Response

Reports the outcome of a Create Session Request, and returns the allocated addresses and bearer parameters.

S11, S4, S5, S8, S2a, S2b.

Create Bearer Request

Creates one or more dedicated EPS bearers for an existing PDN connection.

S11, S4, S5, S8, S2a, S2b.

Create Bearer Response

Reports the outcome of a Create Bearer Request.

S11, S4, S5, S8, S2a, S2b.

Bearer Resource Command

Forwards a UE request for a new bearer resource or a change to an existing one, for example a QoS change or an IP flow mobility update.

S11, S4, S5, S8, S2a, S2b.

Bearer Resource Failure Indication

Reports that the network could not honor a Bearer Resource Command.

S11, S4, S5, S8, S2a, S2b.

Modify Bearer Request

Updates the parameters of an existing EPS bearer, for example the eNodeB’s downlink address after a handover or a service request.

S11, S5, S8.

Modify Bearer Response

Reports the outcome of a Modify Bearer Request.

S11, S4, S5, S8, S2b.

Delete Session Request

Deletes a PDN connection and its EPS bearers.

S11, S4, S5, S8, S2a, S2b.

Delete Bearer Request

Deletes one or more dedicated EPS bearers, without deleting the whole PDN connection.

S11, S4, S5, S8, S2a, S2b.

Delete Session Response

Reports the outcome of a Delete Session Request.

S11, S4, S5, S8, S2a, S2b.

Delete Bearer Response

Reports the outcome of a Delete Bearer Request.

S11, S4, S5, S8, S2a, S2b.

Downlink Data Notification

Tells the MME/SGSN that the SGW-C received downlink data, or downlink signaling, for a UE in idle mode, to start paging.

S11, S4.

Downlink Data Notification Acknowledge

Confirms that the MME/SGSN accepted a Downlink Data Notification and attempts to reach the UE.

S11, S4.

Downlink Data Notification Failure Indication

Tells the SGW-C that a paging attempt failed, for example because the UE did not respond.

S11, S4.

Delete Indirect Data Forwarding Tunnel Request

Tells the SGW-C to release an indirect data-forwarding tunnel that a handover procedure set up.

S11, S4.

Delete Indirect Data Forwarding Tunnel Response

Reports the outcome of a Delete Indirect Data Forwarding Tunnel Request.

S11, S4.

Modify Bearer Command

Asks the PGW-C to apply a subscribed QoS change that the HSS pushed down for a UE’s default bearer.

S11, S4, S5, S8, S2a, S2b.

Modify Bearer Failure Indication

Reports that the PGW-C could not apply the QoS change requested in a Modify Bearer Command.

S11, S4, S5, S8, S2a, S2b.

Update Bearer Request

Changes the QoS or the TFT of an existing EPS bearer, at the request of the PGW-C or the PCRF.

S11, S4, S5, S8, S2a, S2b.

Update Bearer Response

Reports the outcome of an Update Bearer Request.

S11, S4, S5, S8, S2a, S2b.

Delete Bearer Command

Asks the SGW-C/PGW-C to deactivate one or more dedicated EPS bearers, without deleting the PDN connection.

S11, S4, S5, S8.

Delete Bearer Failure Indication

Reports that the PGW-C could not deactivate the bearers requested in a Delete Bearer Command.

S11, S4, S5, S8.

Create Indirect Data Forwarding Tunnel Request

Sets up an indirect data-forwarding tunnel at the SGW-C, to forward buffered downlink data during a handover.

S11, S4.

Create Indirect Data Forwarding Tunnel Response

Reports the outcome of a Create Indirect Data Forwarding Tunnel Request.

S11, S4.

Release Access Bearers Request

Asks the SGW-C to release the radio and S1-U (or Iu) user-plane bearers for a UE that enters idle mode, while keeping the PDN connection.

S11, S4.

Release Access Bearers Response

Reports the outcome of a Release Access Bearers Request.

S11, S4.

Stop Paging Indication

Tells the MME/SGSN to stop paging a UE, for example because the network already reached it another way.

S11, S4.

Modify Access Bearers Request

Updates only the eNodeB’s user-plane addresses at the SGW-C for a UE’s bearers, without involving the PGW-C.

S11.

Modify Access Bearers Response

Reports the outcome of a Modify Access Bearers Request.

S11.

Remote UE Report Notification

Tells the SGW-C/PGW-C that a remote UE, reached through a ProSe UE-to-Network Relay, connected or disconnected.

S11, S5, S8.

Remote UE Report Acknowledge

Reports the outcome of a Remote UE Report Notification.

S11, S5, S8.

5.3.3.3. Mobility Management Messages

Mobility management messages transfer a UE’s mobility management and bearer context between the old and the new serving node during a handover, a relocation, or a Tracking/Routing Area Update. Some of these messages coordinate Idle mode Signalling Reduction (ISR), a feature that keeps a UE registered on an MME and an SGSN at the same time, so the network can page the UE without knowing which of the two it is camped on. These messages also apply to the EPS to 5G System (5GS) handover and idle-mode mobility procedures, where the peer node is an Access and Mobility Management Function (AMF), over the N26 interface.

Message Functionality Interfaces

Message	Functionality	Interfaces
`Forward Relocation Request`	Asks the target node to prepare resources for a handover or a relocation, and carries the UE’s mobility management and bearer context.	S10, S3, S16, N26.
`Forward Relocation Response`	Reports whether the target node accepted the relocation, and which bearers it set up.	S10, S3, S16, N26.
`Forward Relocation Complete Notification`	Tells the source node that the handover finished successfully.	S10, S3, S16, N26.
`Forward Relocation Complete Acknowledge`	Reports the outcome of a `Forward Relocation Complete Notification`.	S10, S3, S16, N26.
`Context Request`	Asks the old serving node for a UE’s mobility management and bearer context, during a Tracking/Routing Area Update or an idle-mode inter-system mobility procedure.	S3, S16, S10, N26.
`Context Response`	Returns the requested mobility management and bearer context, or rejects the request.	S3, S16, S10, N26.
`Context Acknowledge`	Confirms that the new node accepted the context that a `Context Response` transferred.	S3, S16, S10, N26.
`Identification Request`	Asks the old serving node to resolve a UE’s temporary identity to its IMSI.	S3, S16, S10, N26.
`Identification Response`	Returns the UE’s IMSI, and its mobility management context if authentication already succeeded.	S3, S16, S10, N26.
`Forward Access Context Notification`	Forwards a UE’s radio access network context, for example a Radio Network Controller (RNC) or an eNodeB context, to the target node during a relocation.	S16, S10.
`Forward Access Context Acknowledge`	Reports the outcome of a `Forward Access Context Notification`.	S16, S10.
`Detach Notification`	Tells an ISR-associated MME or SGSN to also detach the UE, or to only deactivate ISR for it.	S3.
`Detach Acknowledge`	Reports the outcome of a `Detach Notification`.	S3.
`Change Notification Request`	Reports a change in a UE’s location or CSG membership to the SGW-C, for location-dependent charging.	S11, S4, S5, S8.
`Change Notification Response`	Reports the outcome of a `Change Notification Request`.	S11, S4, S5, S8.
`Relocation Cancel Request`	Tells the target node to abandon the resources it prepared for a handover or a relocation that the source node cancelled.	S3, S10, S16, N26.
`Relocation Cancel Response`	Reports the outcome of a `Relocation Cancel Request`.	S3, S10, S16, N26.
`Configuration Transfer Tunnel`	Carries an opaque radio configuration container between a source and a target radio node, relayed transparently through the core network.	S10, N26.
`RAN Information Relay`	Relays radio access network information between core-network nodes, on behalf of their radio access network nodes.	S3, S16.
`ISR Status Indication`	Tells an ISR-associated MME or SGSN to deactivate ISR, to page the UE, or to stop paging it.	S3.
`UE Registration Query Request`	Asks a candidate MME whether a given UE is registered there, to coordinate CS and packet-switched (PS) service in a shared radio access network.	S3.
`UE Registration Query Response`	Reports whether the UE is registered in the queried MME, and with which core network operator.	S3.

Forward Relocation Request

Asks the target node to prepare resources for a handover or a relocation, and carries the UE’s mobility management and bearer context.

S10, S3, S16, N26.

Forward Relocation Response

Reports whether the target node accepted the relocation, and which bearers it set up.

S10, S3, S16, N26.

Forward Relocation Complete Notification

Tells the source node that the handover finished successfully.

S10, S3, S16, N26.

Forward Relocation Complete Acknowledge

Reports the outcome of a Forward Relocation Complete Notification.

S10, S3, S16, N26.

Context Request

Asks the old serving node for a UE’s mobility management and bearer context, during a Tracking/Routing Area Update or an idle-mode inter-system mobility procedure.

S3, S16, S10, N26.

Context Response

Returns the requested mobility management and bearer context, or rejects the request.

S3, S16, S10, N26.

Context Acknowledge

Confirms that the new node accepted the context that a Context Response transferred.

S3, S16, S10, N26.

Identification Request

Asks the old serving node to resolve a UE’s temporary identity to its IMSI.

S3, S16, S10, N26.

Identification Response

Returns the UE’s IMSI, and its mobility management context if authentication already succeeded.

S3, S16, S10, N26.

Forward Access Context Notification

Forwards a UE’s radio access network context, for example a Radio Network Controller (RNC) or an eNodeB context, to the target node during a relocation.

S16, S10.

Forward Access Context Acknowledge

Reports the outcome of a Forward Access Context Notification.

S16, S10.

Detach Notification

Tells an ISR-associated MME or SGSN to also detach the UE, or to only deactivate ISR for it.

S3.

Detach Acknowledge

Reports the outcome of a Detach Notification.

S3.

Change Notification Request

Reports a change in a UE’s location or CSG membership to the SGW-C, for location-dependent charging.

S11, S4, S5, S8.

Change Notification Response

Reports the outcome of a Change Notification Request.

S11, S4, S5, S8.

Relocation Cancel Request

Tells the target node to abandon the resources it prepared for a handover or a relocation that the source node cancelled.

S3, S10, S16, N26.

Relocation Cancel Response

Reports the outcome of a Relocation Cancel Request.

S3, S10, S16, N26.

Configuration Transfer Tunnel

Carries an opaque radio configuration container between a source and a target radio node, relayed transparently through the core network.

S10, N26.

RAN Information Relay

Relays radio access network information between core-network nodes, on behalf of their radio access network nodes.

S3, S16.

ISR Status Indication

Tells an ISR-associated MME or SGSN to deactivate ISR, to page the UE, or to stop paging it.

S3.

UE Registration Query Request

Asks a candidate MME whether a given UE is registered there, to coordinate CS and packet-switched (PS) service in a shared radio access network.

S3.

UE Registration Query Response

Reports whether the UE is registered in the queried MME, and with which core network operator.

S3.

5.3.3.4. CS Fallback and SRVCC Related Messages

These messages support CS Fallback and SRVCC: they suspend and resume a UE’s non-Guaranteed Bit Rate (non-GBR) bearers around a move to the CS domain, and coordinate paging and activity reporting between an MME and an ISR-associated SGSN.

Message Functionality Interfaces

Message	Functionality	Interfaces
`Suspend Notification`	Tells the SGW-C/PGW-C to suspend a UE’s non-GBR bearers, because the UE moved to the CS domain.	S3, S4, S5, S8, S11, S16.
`Suspend Acknowledge`	Reports the outcome of a `Suspend Notification`.	S3, S4, S5, S8, S11, S16.
`Resume Notification`	Tells the SGW-C/PGW-C to resume a UE’s suspended bearers, because the UE returned to the PS domain.	S11, S4, S5, S8.
`Resume Acknowledge`	Reports the outcome of a `Resume Notification`.	S11, S4, S5, S8.
`CS Paging Indication`	Relays a CS domain paging request from the MME to an ISR-associated SGSN.	S3.
`Alert MME Notification`	Asks an ISR-associated SGSN to notify the MME the next time it detects activity from the UE.	S3.
`Alert MME Acknowledge`	Reports the outcome of an `Alert MME Notification`.	S3.
`UE Activity Notification`	Tells the MME that an ISR-associated SGSN detected activity from the UE.	S3.
`UE Activity Acknowledge`	Reports the outcome of a `UE Activity Notification`.	S3.

Suspend Notification

Tells the SGW-C/PGW-C to suspend a UE’s non-GBR bearers, because the UE moved to the CS domain.

S3, S4, S5, S8, S11, S16.

Suspend Acknowledge

Reports the outcome of a Suspend Notification.

S3, S4, S5, S8, S11, S16.

Resume Notification

Tells the SGW-C/PGW-C to resume a UE’s suspended bearers, because the UE returned to the PS domain.

S11, S4, S5, S8.

Resume Acknowledge

Reports the outcome of a Resume Notification.

S11, S4, S5, S8.

CS Paging Indication

Relays a CS domain paging request from the MME to an ISR-associated SGSN.

S3.

Alert MME Notification

Asks an ISR-associated SGSN to notify the MME the next time it detects activity from the UE.

S3.

Alert MME Acknowledge

Reports the outcome of an Alert MME Notification.

S3.

UE Activity Notification

Tells the MME that an ISR-associated SGSN detected activity from the UE.

S3.

UE Activity Acknowledge

Reports the outcome of a UE Activity Notification.

S3.

5.3.3.5. Non-3GPP Access Related Messages

These messages set up an indirect data-forwarding tunnel at the SGW-C for a handover between E-UTRAN and CDMA2000 High Rate Packet Data (HRPD) access.

Message Functionality Interfaces

Message	Functionality	Interfaces
`Create Forwarding Tunnel Request`	Asks the SGW-C to set up an indirect data-forwarding tunnel for a handover from E-UTRAN to CDMA2000 HRPD access.	S11.
`Create Forwarding Tunnel Response`	Reports the outcome of a `Create Forwarding Tunnel Request`.	S11.

Create Forwarding Tunnel Request

Asks the SGW-C to set up an indirect data-forwarding tunnel for a handover from E-UTRAN to CDMA2000 HRPD access.

S11.

Create Forwarding Tunnel Response

Reports the outcome of a Create Forwarding Tunnel Request.

S11.

5.3.3.6. Restoration and Recovery Messages

These messages let GTP-C nodes recover gracefully from a peer’s partial fault or restart, by deleting or re-associating the affected PDN connections. TS 23.007 defines the restoration and recovery procedures that use these messages.

Message Functionality Interfaces

Message	Functionality	Interfaces
`Delete PDN Connection Set Request`	Tells a peer node that reports a partial fault to delete the PDN connections associated with the affected control-plane identifier.	S2a, S2b, S5, S8, S11.
`Delete PDN Connection Set Response`	Reports the outcome of a `Delete PDN Connection Set Request`.	S2a, S2b, S5, S8, S11.
`Update PDN Connection Set Request`	Tells the PGW-C which control-plane node now serves a PDN connection’s SGW-C or MME, after an MME change that did not change the SGW-C.	S5, S8.
`Update PDN Connection Set Response`	Reports the outcome of an `Update PDN Connection Set Request`.	S5, S8.
`PGW Restart Notification`	Tells the MME/SGSN that the PGW-C serving a UE’s PDN connections has restarted or failed.	S11, S4.
`PGW Restart Notification Acknowledge`	Confirms that the MME/SGSN deleted the PDN connections that a `PGW Restart Notification` reported.	S11, S4.
`PGW Downlink Triggering Notification`	Asks the SGW-C to restore the user-plane path for a UE, after the SGW-C lost its bearer context but the PGW-C still has downlink data or signaling to deliver.	S5, S8, S11, S4.
`PGW Downlink Triggering Acknowledge`	Reports the outcome of a `PGW Downlink Triggering Notification`.	S5, S8, S11, S4.

Delete PDN Connection Set Request

Tells a peer node that reports a partial fault to delete the PDN connections associated with the affected control-plane identifier.

S2a, S2b, S5, S8, S11.

Delete PDN Connection Set Response

Reports the outcome of a Delete PDN Connection Set Request.

S2a, S2b, S5, S8, S11.

Update PDN Connection Set Request

Tells the PGW-C which control-plane node now serves a PDN connection’s SGW-C or MME, after an MME change that did not change the SGW-C.

S5, S8.

Update PDN Connection Set Response

Reports the outcome of an Update PDN Connection Set Request.

S5, S8.

PGW Restart Notification

Tells the MME/SGSN that the PGW-C serving a UE’s PDN connections has restarted or failed.

S11, S4.

PGW Restart Notification Acknowledge

Confirms that the MME/SGSN deleted the PDN connections that a PGW Restart Notification reported.

S11, S4.

PGW Downlink Triggering Notification

Asks the SGW-C to restore the user-plane path for a UE, after the SGW-C lost its bearer context but the PGW-C still has downlink data or signaling to deliver.

S5, S8, S11, S4.

PGW Downlink Triggering Acknowledge

Reports the outcome of a PGW Downlink Triggering Notification.

S5, S8, S11, S4.

5.3.3.7. Trace Management Messages

These messages start and stop a protocol-level signaling trace for a subscriber, across the control-plane nodes that serve the subscriber’s session.

Message Functionality Interfaces

Message	Functionality	Interfaces
`Trace Session Activation`	Activates signaling trace recording for a subscriber’s session.	S11, S4, S5, S8, S2a, S2b.
`Trace Session Deactivation`	Deactivates a previously activated signaling trace.	S11, S4, S5, S8, S2a, S2b.

Trace Session Activation

Activates signaling trace recording for a subscriber’s session.

S11, S4, S5, S8, S2a, S2b.

Trace Session Deactivation

Deactivates a previously activated signaling trace.

S11, S4, S5, S8, S2a, S2b.

5.3.3.8. MBMS Messages

These messages let the Multimedia Broadcast Multicast Service (MBMS) Gateway control a broadcast or multicast session at the MME/SGSN.

Message Functionality Interfaces

Message	Functionality	Interfaces
`MBMS Session Start Request`	Asks the MME/SGSN to start an MBMS session, and carries its QoS, service area, and multicast distribution parameters.	Sm, Sn.
`MBMS Session Start Response`	Reports the outcome of an `MBMS Session Start Request`.	Sm, Sn.
`MBMS Session Update Request`	Updates the parameters of an ongoing MBMS session, for example its service area.	Sm, Sn.
`MBMS Session Update Response`	Reports the outcome of an `MBMS Session Update Request`.	Sm, Sn.
`MBMS Session Stop Request`	Ends an MBMS session.	Sm, Sn.
`MBMS Session Stop Response`	Reports the outcome of an `MBMS Session Stop Request`.	Sm, Sn.

MBMS Session Start Request

Asks the MME/SGSN to start an MBMS session, and carries its QoS, service area, and multicast distribution parameters.

Sm, Sn.

MBMS Session Start Response

Reports the outcome of an MBMS Session Start Request.

Sm, Sn.

MBMS Session Update Request

Updates the parameters of an ongoing MBMS session, for example its service area.

Sm, Sn.

MBMS Session Update Response

Reports the outcome of an MBMS Session Update Request.

Sm, Sn.

MBMS Session Stop Request

Ends an MBMS session.

Sm, Sn.

MBMS Session Stop Response

Reports the outcome of an MBMS Session Stop Request.

Sm, Sn.

5.3.4. References

Specification Clauses and coverage

Specification	Clauses and coverage
TS 29.274	Clause 4.2 — GTPv2-C protocol stack and interfaces Clause 4.3 — Transmission order and bit definitions Clause 5.1 — General header format Clause 5.3 — Header for the Echo and Version Not Supported Indication messages Clause 5.4 — EPC specific GTP-C header Clause 5.5 — Usage of the GTPv2-C header, including the `MP` flag and the `Message Priority` field Clause 6 — GTP-C message types and message formats Clause 7 — GTP-C messages, covering: 7.1 Path Management Messages 7.2 Tunnel Management Messages 7.3 Mobility Management Messages 7.4 CS Fallback and SRVCC related messages 7.5 Non-3GPP access related messages 7.9 Restoration and Recovery 7.12 Trace Management Messages 7.13 MBMS Messages

TS 29.274

Clause 4.2 — GTPv2-C protocol stack and interfaces
Clause 4.3 — Transmission order and bit definitions
Clause 5.1 — General header format
Clause 5.3 — Header for the Echo and Version Not Supported Indication messages
Clause 5.4 — EPC specific GTP-C header
Clause 5.5 — Usage of the GTPv2-C header, including the MP flag and the Message Priority field
Clause 6 — GTP-C message types and message formats
Clause 7 — GTP-C messages, covering:
- 7.1 Path Management Messages
- 7.2 Tunnel Management Messages
- 7.3 Mobility Management Messages
- 7.4 CS Fallback and SRVCC related messages
- 7.5 Non-3GPP access related messages
- 7.9 Restoration and Recovery
- 7.12 Trace Management Messages
- 7.13 MBMS Messages

5.3.5. Load and Overload Control

5.3.5.1. Technical Overview

GTPv2-C load control and GTPv2-C overload control are optional, complementary features that manage signaling traffic between EPC control-plane nodes and help keep the network stable.

Load control is a preventive mechanism: a node uses it to balance the distribution of new sessions across its peers before an overload condition occurs.

Overload control is a reactive mechanism: a node uses it to reduce incoming signaling traffic after the node already operates over its capacity.

An operator can support load control and overload control independently of each other, based on operator policy. Each node piggybacks its Load Control Information (LCI) or Overload Control Information (OCI) onto existing GTP-C request and response messages, a method that avoids extra signaling traffic and keeps the computation and transfer of this control information from adding significant load to the sending node or to its peers.

Overload control still lets the network give preferential treatment to emergency services traffic and to enhanced Multimedia Priority Service (eMPS) traffic.

Load control and overload control apply over the S11, S4, S5, S8, S2a, and S2b interfaces.

5.3.5.2. Load Control Procedure

Load control lets a node, typically the SGW-C or the PGW-C, advertise its operating status to a peer, for example the MME, the SGSN, the Trusted WLAN Access Network (TWAN), or the ePDG. The peer uses this status to balance the distribution of new sessions.

The node includes an LCI IE in its GTP-C messages. The LCI IE carries the following parameters:

Load Control Sequence Number: This number sequences the LCI updates, letting the receiving node identify the most recent load information.
Load Metric: This parameter states the current load level, as a percentage from 0 to 100, where 100 means the node operates at maximum load.
List of APN and Relative Capacity (PGW-C only): This list states the load status for a specific APN, and the PGW-C includes it when it does not distribute its resources evenly across its APNs.

Load control operates at two levels:

Node Level: This level advertises the load of the entire node, helping distribute sessions evenly across a cluster of gateways.
APN Level: This level advertises the load for a specific APN and applies when a PGW-C allocates a separate resource pool to each APN, stopping the network from selecting a node for a new session on an APN whose resources are exhausted, even when the node has spare capacity overall.

5.3.5.3. Overload Control Procedure

Overload control activates when a node operates over its nominal capacity and its performance degrades, and the overloaded node instructs its peers to reduce the rate of Request messages that they send to it.

The node includes an OCI IE in its GTP-C messages. The OCI IE carries the following parameters:

Overload Control Sequence Number: This number differentiates between OCI instances, letting the receiving node collate reports that arrive out of order.
Overload Reduction Metric: This parameter states the traffic reduction that the sender requests from the receiver, as a percentage from 0 to 100, where a value of 0 means the overload condition ended.
Period of Validity: This parameter states how long the overload condition stays valid, and when this timer expires without a new OCI, the receiving node considers the overload condition ended.
List of APNs (PGW-C only): This list states the APNs that are in overload, for example because of a shortage in the IP address pool.

A node reduces traffic toward an overloaded peer through the following mechanisms:

Message Throttling: The reacting node reduces the number of initial messages that it sends to the overloaded peer, in proportion to the Overload Reduction Metric, but does not throttle a triggered request or a response message, because doing so would cause the sender to retransmit the corresponding request message.
"Loss" Throttling Algorithm: This is the mandatory default throttling algorithm for overload control, under which the node discards a fraction of the initial messages, in proportion to the requested traffic reduction. A typical implementation generates a random number for each candidate message and discards the message when the number falls within the requested reduction percentage.
Self-Protection: As a fallback when peer throttling does not reduce the load enough, an overloaded node can still reject incoming requests, with a cause value such as GTP-C Entity Congestion or APN congestion.

5.3.5.4. Message Prioritization during Overload

Emergency services traffic and eMPS traffic keep the highest priority, and, depending on regional and national requirements and on operator policy, the network exempts this traffic from throttling for as long as it can achieve the requested traffic reduction without throttling it.

For other traffic, an overloaded node can prioritize messages for throttling in the following ways.

Prioritization Based on Procedures: The node groups GTPv2-C procedures into four categories and gives a lower preference to throttle to the messages of a higher-priority category.
Prioritization Based on Session Parameters: The node can further prioritize messages within a category, based on session parameters such as the APN, the QoS Class Identifier (QCI), the Allocation and Retention Priority (ARP), or the Low Access Priority Indicator (LAPI).
Prioritization Based on the Message Priority: The node can prioritize messages based on the relative Message Priority that the sending node signals in the GTPv2-C header, through the MP flag and the Message Priority field.

The procedure categories, from the highest priority to the lowest, are:

UE session mobility, for example a Create Session Request and a Modify Bearer Request with the handover indication bit set. Throttling these messages can cause the loss of a PDN connection or the interruption of a service.
Release of a PDN connection or bearer resources, for example a Delete Session Request and a Delete Bearer Request. These messages free node resources, so the node gives them a lower preference to throttle.
Other session management procedures, for example a Modify Bearer Request without the handover indication bit set, and a Change Notification.
Requests for a new PDN connection or new bearer resources, for example a Create Session Request for a new PDN connection, and a Create Bearer Request. The node gives the highest preference to throttle these messages, because it denies new services before it drops existing ones.

5.3.5.5. Implementation Requirements and Enforcement

Peer Discovery: A node decides whether to use load control and overload control, based on local configuration and operator policy, and this decision applies separately to internal interfaces and to roaming interfaces.
Homogeneity: Operators need to support these features consistently across all nodes in the network, because partial support can cause unfair load distribution: supporting nodes throttle their traffic, while non-supporting nodes keep overwhelming the target node.
Direct Enforcement: A node enforces load control and overload control for peers that it directly contacts, based on the metrics that those peers report.
Remote Enforcement: A node also enforces control for entities that it does not directly contact, for example an MME that signals to a PGW-C through an SGW-C. In this case, the source node enforces control based on the maximum reduction metric that any node in the signaling path reports, whether that node is the target or an intermediate node.
Interaction with the PGW-C Back-Off Timer: For a given APN, a PGW-C uses either APN-level overload control or the PGW back-off timer mechanism, never both mechanisms at the same time.

5.3.5.6. Messages Carrying Load and Overload Control Information

A node includes the LCI IE and the OCI IE in a wide range of session management messages, including:

Create Session Request and Create Session Response.
Modify Bearer Request and Modify Bearer Response.
Delete Session Request and Delete Session Response.
Create Bearer Request/Response, Update Bearer Request/Response, and Delete Bearer Request/Response.
Downlink Data Notification.
Bearer Resource Command and Bearer Resource Failure Indication.

5.3.5.7. References

Specification Clauses and coverage

Specification	Clauses and coverage
TS 23.401	Clause 4.3.7.1a — GTP-C signalling based Load and Overload Control Clause 4.3.7.1a.1 — Load control Clause 4.3.7.1a.2 — Overload control Clause 4.3.7.5 — APN congestion control and the PGW back-off timer
TS 29.274	Clauses 5.4 and 5.5 — the `MP` flag and the `Message Priority` field Clauses 8.111 to 8.115 — the Overload Control Information, Load Control Information, Metric, Sequence Number, and APN and Relative Capacity Information Elements Clauses 12.1 to 12.3 — the GTP-C load and overload control mechanism, including message throttling in clause 12.3.9 and enforcement in clause 12.3.10 Annex D — the GTP-C interfaces that do not support these features, and example implementations of the "Loss" algorithm and of overload control enforcement between remote GTP-C entities
TS 29.244	Clauses 6.2.3 and 6.2.4 (the parallel load and overload control mechanism over the Packet Forwarding Control Protocol, PFCP).
TS 29.213	Annexes G and K (the equivalent load and overload control mechanism over Diameter).

TS 23.401

Clause 4.3.7.1a — GTP-C signalling based Load and Overload Control
Clause 4.3.7.1a.1 — Load control
Clause 4.3.7.1a.2 — Overload control
Clause 4.3.7.5 — APN congestion control and the PGW back-off timer

TS 29.274

Clauses 5.4 and 5.5 — the MP flag and the Message Priority field
Clauses 8.111 to 8.115 — the Overload Control Information, Load Control Information, Metric, Sequence Number, and APN and Relative Capacity Information Elements
Clauses 12.1 to 12.3 — the GTP-C load and overload control mechanism, including message throttling in clause 12.3.9 and enforcement in clause 12.3.10
Annex D — the GTP-C interfaces that do not support these features, and example implementations of the "Loss" algorithm and of overload control enforcement between remote GTP-C entities

TS 29.244

Clauses 6.2.3 and 6.2.4 (the parallel load and overload control mechanism over the Packet Forwarding Control Protocol, PFCP).

TS 29.213

Annexes G and K (the equivalent load and overload control mechanism over Diameter).