6 GTP-C Message Types and Message Formats

29.2743GPP3GPP Evolved Packet System (EPS)Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)Release 18Stage 3TS

6.0 General

A GTP-C message is sent across a GTP control plane tunnel. In a message, the GTP-C header is followed by zero or more information elements. The GTP-C messages are used for the control plane path management, for the control plane tunnel management and for mobility management.

A T-PDU is an original packet, for example an IP datagram, from an UE, or from a network node in an external packet data network.

6.1 Message Format and Type values

6.1.0 Message Type

GTP defines a set of messages between two associated EPC network elements. The messages to be used shall be as defined in Table 6.1-1.

Table 6.1-1: Message types for GTPv2

Message Type value (Decimal)

Message

Reference

Initial

Triggered

0

Reserved

1

Echo Request

X

2

Echo Response

X

3

Version Not Supported Indication

X

4 to 16

Reserved for S101 interface

TS 29.276 [14]

17 to 24

Reserved for S121 interface

TS 29.276 [14]

25 to 31

Reserved for Sv interface

TS 29.280 [15]

SGSN/MME/ TWAN/ePDG to PGW (S4/S11, S5/S8, S2a, S2b)

32

Create Session Request

X

33

Create Session Response

X

36

Delete Session Request

X

37

Delete Session Response

X

SGSN/MME/ePDG to PGW (S4/S11, S5/S8, S2b)

34

Modify Bearer Request

X

35

Modify Bearer Response

X

MME to PGW (S11, S5/S8)

40

Remote UE Report Notification

X

41

Remote UE Report Acknowledge

X

SGSN/MME to PGW (S4/S11, S5/S8)

38

Change Notification Request

X

39

Change Notification Response

X

42 to 63

For future use

164

Resume Notification

X

165

Resume Acknowledge

X

Messages without explicit response

64

Modify Bearer Command

(MME/SGSN/ TWAN/ePDG to PGW – S11/S4, S5/S8, S2a, S2b)

X

65

Modify Bearer Failure Indication

(PGW to MME/SGSN/ TWAN/ePDG – S5/S8, S11/S4, S2a, S2b)

X

66

Delete Bearer Command

(MME/SGSN to PGW – S11/S4, S5/S8)

X

67

Delete Bearer Failure Indication

(PGW to MME/SGSN – S5/S8, S11/S4))

X

68

Bearer Resource Command

(MME/SGSN/TWAN/ePDG to PGW – S11/S4, S5/S8, S2a, S2b)

X

69

Bearer Resource Failure Indication

(PGW to MME/SGSN/TWAN/ePDG – S5/S8, S11/S4, S2a, S2b)

X

70

Downlink Data Notification Failure Indication

(SGSN/MME to SGW – S4/S11)

X

71

Trace Session Activation

(MME/SGSN/ TWAN/ePDG to PGW – S11/S4, S5/S8, S2a, S2b)

X

72

Trace Session Deactivation

(MME/SGSN/ TWAN/ePDG to PGW – S11/S4, S5/S8, S2a, S2b)

X

73

Stop Paging Indication

(SGW to MME/SGSN – S11/S4)

X

74 to 94

For future use

PGW to SGSN/MME/ TWAN/ePDG (S5/S8, S4/S11, S2a, S2b)

95

Create Bearer Request

X

X

96

Create Bearer Response

X

97

Update Bearer Request

X

X

98

Update Bearer Response

X

99

Delete Bearer Request

X

X

100

Delete Bearer Response

X

PGW to MME, MME to PGW, SGW to PGW, SGW to MME, PGW to TWAN/ePDG, TWAN/ePDG to PGW (S5/S8, S11, S2a, S2b)

101

Delete PDN Connection Set Request

X

102

Delete PDN Connection Set Response

X

PGW to SGSN/MME (S5, S4/S11)

103

PGW Downlink Triggering Notification

X

104

PGW Downlink Triggering Acknowledge

X

105 to 127

For future use

MME to MME, SGSN to MME, MME to SGSN, SGSN to SGSN, MME to AMF, AMF to MME (S3/S10/S16/N26)

S3

S10

S16

N26

128

Identification Request

X

X

X

X

X

129

Identification Response

X

X

X

X

X

130

Context Request

X

X

X

X

X

131

Context Response

X

X

X

X

X

132

Context Acknowledge

X

X

X

X

X

133

Forward Relocation Request

X

X

X

X

X

134

Forward Relocation Response

X

X

X

X

X

135

Forward Relocation Complete Notification

X

X

X

X

X

136

Forward Relocation Complete Acknowledge

X

X

X

X

X

137

Forward Access Context Notification

–

X

X

–

X

138

Forward Access Context Acknowledge

–

X

X

–

X

139

Relocation Cancel Request

X

X

X

X

X

140

Relocation Cancel Response

X

X

X

X

X

141

Configuration Transfer Tunnel

–

X

–

X

X

142 to 148

For future use

152

RAN Information Relay

X

–

X

–

X

SGSN to MME, MME to SGSN (S3)

149

Detach Notification

X

150

Detach Acknowledge

X

151

CS Paging Indication

X

153

Alert MME Notification

X

154

Alert MME Acknowledge

X

155

UE Activity Notification

X

156

UE Activity Acknowledge

X

157

ISR Status Indication

X

158

UE Registration Query Request

X

159

UE Registration Query Response

X

SGSN/MME to SGW, SGSN to MME (S4/S11/S3)

SGSN to SGSN (S16), SGW to PGW (S5/S8)

162

Suspend Notification

X

163

Suspend Acknowledge

X

SGSN/MME to SGW (S4/S11)

160

Create Forwarding Tunnel Request

X

161

Create Forwarding Tunnel Response

X

166

Create Indirect Data Forwarding Tunnel Request

X

167

Create Indirect Data Forwarding Tunnel Response

X

168

Delete Indirect Data Forwarding Tunnel Request

X

169

Delete Indirect Data Forwarding Tunnel Response

X

170

Release Access Bearers Request

X

171

Release Access Bearers Response

X

172 to 175

For future use

SGW to SGSN/MME (S4/S11)

176

Downlink Data Notification

X

177

Downlink Data Notification Acknowledge

X

179

PGW Restart Notification

X

180

PGW Restart Notification Acknowledge

X

SGW to SGSN (S4)

178

Reserved. Allocated in earlier version of the specification.

181 to 199

For future use

SGW to PGW, PGW to SGW (S5/S8)

200

Update PDN Connection Set Request

X

201

Update PDN Connection Set Response

X

202 to 210

For future use

MME to SGW (S11)

211

Modify Access Bearers Request

X

212

Modify Access Bearers Response

X

213 to 230

For future use

MBMS GW to MME/SGSN (Sm/Sn)

231

MBMS Session Start Request

X

232

MBMS Session Start Response

X

233

MBMS Session Update Request

X

234

MBMS Session Update Response

X

235

MBMS Session Stop Request

X

236

MBMS Session Stop Response

X

237 to 239

For future use

Other

240 to 247

Reserved for Sv interface (see also types 25 to 31)

TS 29.280 [15]

248 to 255

For future use

6.1.1 Presence requirements of Information Elements

There are four different presence requirements (Mandatory, Conditional, Optional, or Conditional-Optional) for an IE within a given GTP-PDU:

– Mandatory means that the IE shall be included by the sending side, and that the receiver diagnoses a "Mandatory IE missing" error, when detecting that the IE is not present. A response including a "Mandatory IE missing" cause, shall include the type of the missing IE.

– Conditional means:

– that the IE shall be included by sending entity if the conditions specified in the relevant protocol specification are met;

– the receiver shall check the conditions as specified in the corresponding message type description, based on the parameter combination in the message and/or on the state of the receiving node, to infer if a conditional IE shall be expected. Only if a receiver has sufficient information the following applies. A conditional IE, which is absolutely necessary for the receiving entity to complete the procedure, is missing, then the receiver shall abort the procedure.

– Conditional-Optional means:

– that the IE shall be included by the up-to-date sending entity, if the conditions specified in the relevant protocol specification are met. An entity, which is at an earlier version of the protocol and therefore is not up-to-date, obviously cannot send such new IE.

– the receiver need not check the presence of the IE in the message. If the receiver checks the presence of the Conditional-Optional IE, then the IE’s absence shall not trigger any of the error handling procedures. The handling of an absence or erroneous such IEs shall be treated as Optional IEs as specified in clause 7.7 "Error Handling".

– Optional means:

– that the IE shall be included as a service option. Therefore, the IE may be included or not in a message. The handling of an absent optional IE, or an erroneous optional IE is specified in clause 7.7 "Error Handling".

For conditional IEs, the clause describing the GTP-PDU explicitly defines the conditions under which the inclusion of each IE becomes mandatory or optional for that particular GTP-PDU. These conditions shall be defined so that the presence of a conditional IE only becomes mandatory if it is critical for the receiving entity. The definition might reference other protocol specifications for final terms used as part of the condition.

For grouped IEs, the presence requirement of the embedded IE shall follow the rules:

– The grouped IE is Mandatory within a given message: the presence requirements of individual embedded IEs are as stated within the Mandatory grouped IE for the given message.

– The grouped IE is Conditional within a given message: if the embedded IE in the grouped IE is Mandatory or Conditional, this embedded IE is viewed as Conditional IE by the receiver. If the embedded IE in the grouped IE is Conditional-Optional, this embedded IE is viewed as Optional IE by the receiver. If the embedded IE in the grouped IE is Optional, this embedded IE is viewed as Optional IE by the receiver.

– The grouped IE is Conditional-Optional within a given message: if the embedded IE in the grouped IE is Mandatory or Conditional, this embedded IE is viewed as Conditional-Optional IE by the receiver. If the embedded IE in the grouped IE is Conditional-Optional, this embedded IE is viewed as Optional IE by the receiver. If the embedded IE in the grouped IE is Optional, this embedded IE is viewed as Optional IE by the receiver.

– The grouped IE is Optional within a given message: all embedded IEs in the grouped IE are viewed as Optional IEs by the receiver.

In all of the above cases, appropriate error handling as described in clause 7.7 shall be applied for protocol errors of the embedded IEs.

Only the Cause information element at message level shall be included in the response if the Cause contains a value that indicates that the request is not accepted regardless of whether there are other mandatory or conditional information elements defined for a given response message.

The following are exceptions:

– Optionally, the Protocol Configuration Options, Recovery, User Location Information (ULI), Load Control Information, Overload Control Information, Bearer Context and Local Distinguished Name (LDN) information elements may be included.

– For the rejection response of a Forward Relocation Request, the Forward Relocation Response message may also include an F-Cause IE as specified in clause 7.3.2.

– For the rejection response of a SRVCC PS to CS Request, the SRVCC PS to CS Response message may also include an SRVCC Cause IE as specified in clause 5.2.3 in 3GPP TS 29.280 [15].

– A Downlink Data Notification Acknowledge (with or) without an indication of success may also include a DL low priority traffic Throttling IE and the IMSI IE.

– The PGW Back-Off Time IE may also be returned when rejecting a Create Session Request with the cause "APN Congestion".

– Change Notification Response message may also include the IMSI and MEI information elements.

– Failure Indication type messages do not have "Accept" types of Cause values, i.e. all used values indicate the rejection, therefore for Failure Indication type of triggered messages, other information elements, other than the Cause IE, shall also be included according to the conditions of presence specified in the respective message, if they are available.

– The Context Response message (sent by an SGSN or MME) should also include the IMSI IE if the Cause IE contains the value "P-TMSI Signature mismatch", except if the UE is emergency or RLOS attached and the UE is UICCless.

– The Create Bearer Response message, the Update Bearer Response message and the Delete Bearer Response message shall include the RAN/NAS Cause IE according to the conditions specified in clauses 7.2.4, 7.2.16 and 7.2.10.2.

– The UE Registration Query Response message shall include IMSI to allow the SGSN to correlate the response message with the corresponding request.

If the Cause information element at Grouped IE level contains a value that indicates that the Grouped IE is not handled correctly, e.g. "Context Not Found" at Bearer Context IE level, the other information elements in this Grouped IE, other than the Cause IE, may not be included.

6.1.2 Grouped Information Elements

Information elements can contain other IEs. This type of IE is called "Grouped IEs".

Grouped IEs have a length value in the TLIV encoding, which includes the added length of all the embedded IEs. Overall coding of a grouped information element with 4 octets long IE header is defined in clause 8.2 "Information Element Format". Each information element within a grouped IE also shall also contain 4 octets long IE header.

Grouped IEs are not marked by any flag or limited to a specific range of IE type values. The clause describing an IE in this specification shall explicitly state if it is grouped.

NOTE 1: Each entry into each Grouped IE creates a new scope level. Exit from the grouped IE closes the scope level. The GTPv2 message level is the top most scope. This is analogous to the local scope of a subroutine/function.

If more than one grouped information elements of the same type, but for a different purpose are sent with a message, these IEs shall have different Instance values.

If more than one grouped information elements of the same type and for the same purpose are sent with a message, these IEs shall have exactly the same Instance value to represent a list.

NOTE 2: For instance, all "Bearer Contexts Modified" IEs of the type "Bearer Context" in a "Modify Bearer Response" message shall have the Instance value of 0, while all "Bearer Contexts Marked for Removal" IEs of the type "Bearer Context" in the same message shall have the Instance value of 1.

6.1.3 Information Element instance

Every GTPv2 message and grouped IE within a message in this specification has a column documenting the instance value of each IE.

When a GTPv2 message is encoded for use the instance value of each included IE is encoded in the Instance field of the IE for the message scope. See clause 7 and clause 8.2 for details of that encoding.

An Information Element in an encoded GTPv2 message or encoded grouped IE is identified by the pair of IE Type and Instance values and described by a specific row in the corresponding tables in clauses of 7 in the present document.

If several Information Elements with the same Type and Instance values are included in an encoded GTPv2 message, they represent a list for the corresponding IE name and row identified in the message grammar in clauses of clause 7.

If several Information Elements with the same Type and Instance values are included in an encoded grouped IE, they represent a list for the corresponding IE name and row identified in the grouped IE grammar in clauses of clause 7.

In tables in this document the instance value for "Private Extension" is marked as VS (Vendor Specific). While an instance value must be encoded by the sender the value can be Vendor and even Private Extension specific.

The same IE name might be used in different messages (on the top level or within grouped IEs) in this specification. The instance value and name of an IE is only meaningful within the scope of the message definition . The combination of Type value and Instance value uniquely identifies a specific row in a message description table.

6.2 Message Granularity

The GTPv2-C messages shall be sent per UE on the S3, S10, S16 and N26 interfaces.

The GTPv2-C messages shall be sent per PDN-Connection on the S2a, S2b, S4, S11, S5 and S8 interfaces apart from the following exclusion.

The following GTPv2-C messages are sent per UE on the S4 and S11 interfaces:

– Downlink Data Notification / Acknowledge / Failure Indication;

– Stop Paging Indication;

– Delete Indirect Data Forwarding Tunnel Request/Response;

– Delete Session Request/Response with Scope Indication set to 1 during following procedures with SGW change:

– Tracking Area Update procedure;

– Routing Area Update procedure;

– Handover procedure;

– SRNS Relocation Cancel Using S4;

– Inter RAT handover Cancel procedure;

– S1 based handover cancel procedure;

– Delete Bearer Request/Response during a TAU/RAU/Handover procedure if the Cause value "ISR deactivation" is included in the Delete Session Request message, or when it is sent to delete the bearer resources on the other ISR associated CN node if the ISRAI flag is not set in the Modify Bearer Request/Modify Access Bearers Request message.

– Release Access Bearers Request/Response;

– Create Indirect Data Forwarding Tunnel Request/Response;

– Trace Session Activation;

– Trace Session Deactivation;

– Create Forwarding Tunnel Request/Response.

The following GTPv2-C messages are sent per UE on the S11 interface:

– Modify Access Bearers Request/Response.

The following GTPv2-C messages are sent per GTP-C entity on the S2a, S2b, S5, S8, and S11 interfaces:

– Delete PDN Connection Set Request/Response.

The following GTPv2-C messages are sent per GTP-C entity on the S5 and S8 interfaces:

– Update PDN Connection Set Request/Response.

The following GTPv2-C messages are sent per GTP-C entity on the S4 and S11 interfaces:

– PGW Restart Notification/Acknowledge.

The following GTPv2-C path management messages are sent per GTP-C entity on all GTPv2-C interfaces:

– Echo Request/Response;

– Version Not Supported Indication.