29274-A20 - 3GPP Evolved Packet System (EPS) Evolved General Packet Radio Service (GPRS) Tunnelling Protocol For Control Plane (GTPv2-C) Stage 3

3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;

3GPP Evolved Packet System (EPS);
Evolved General Packet Radio Service
(GPRS)
V10.2.0
(2011-03)
Tunnelling Protocol for Control plane (GTPv2-C);
Technical Specification
Stage 3
(Release 10)
3GPP TS 29.274
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP..
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this
Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
Keywords
GSM, UMTS, packet mode, GPRS, LTE
3GPP
Postal address
3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
2011, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
All rights reserved.
UMTS is a Trade Mark of ETSI registered for the benefit of its members
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP
Organizational Partners
GSM and the GSM logo are registered and owned by the GSM Association
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
Contents
Foreword..........................................................................................................................................................
1
Scope......................................................................................................................................................
References..............................................................................................................................................
Definitions, symbols and abbreviations................................................................................................
3.1
3.2
3.3
4
4.1
4.2
4.2.0
4.2.1
4.2.1.0
4.2.1.1
4.2.1.2
4.2.1.3
4.2.2
4.2.2.1
4.2.2.2
4.2.2.3
4.2.3
4.2.4
4.2.5
4.3
5
5.1
5.2
5.3
5.4
5.5
5.5.1
5.5.2
5.6
Definitions.........................................................................................................................................................
Symbols.............................................................................................................................................................
Abbreviations.....................................................................................................................................................
General.................................................................................................................................................
GTP Tunnel........................................................................................................................................................
Protocol stack....................................................................................................................................................
General.........................................................................................................................................................
UDP header and port numbers.....................................................................................................................
General...................................................................................................................................................
Initial Messages......................................................................................................................................
Triggered Messages................................................................................................................................
Piggybacked Messages...........................................................................................................................
IP header and IP addresses...........................................................................................................................
Initial Messages......................................................................................................................................
Triggered Messages................................................................................................................................
Piggybacked Messages...........................................................................................................................
Layer 2.........................................................................................................................................................
Layer 1.........................................................................................................................................................
Messages with GTPv2 defined replies: Classification of Initial and Triggered Messages..........................
Transmission Order and Bit Definitions............................................................................................................
GTP Header for Control Plane..............................................................................................................

General format...................................................................................................................................................
Control Plane GTP Extension Header...............................................................................................................
GTP-C header for Echo and Version Not Supported messages.........................................................................
EPC specific GTP-C header..............................................................................................................................
Usage of the GTPv2-C Header..........................................................................................................................
General...............................................................................................................................................................
Conditions for sending TEID=0 in GTPv2-C header..................................................................................
Format of the GTPv2-C Message......................................................................................................................
GTP-C Message Types and Message Formats......................................................................................
6.0
General.................................................................................................................................................
6.1
6.1.0
6.1.1
6.1.2
6.1.3
6.2
7
7.1
7.1.0
7.1.1
7.1.2
7.1.3
7.2
7.2.0
7.2.1
7.2.2
7.2.3
7.2.4
Message Format and Type values......................................................................................................................

Message Type...............................................................................................................................................
Presence requirements of Information Elements.........................................................................................
Grouped Information Elements....................................................................................................................
Information Element instance......................................................................................................................
Message Granularity..........................................................................................................................................
GTP-C messages................................................................................................................................................
Path Management Messages..............................................................................................................................
General.........................................................................................................................................................
Echo Request................................................................................................................................................
Echo Response.............................................................................................................................................
Version Not Supported Indication................................................................................................................
Tunnel Management Messages..........................................................................................................................
General.........................................................................................................................................................
Create Session Request................................................................................................................................
Create Session Response..............................................................................................................................
Create Bearer Request..................................................................................................................................
Create Bearer Response...............................................................................................................................
3GPP
Release 10
7.2.5
7.2.6
7.2.7
7.2.8
7.2.9
7.2.9.1
7.2.9.2
7.2.10
7.2.10.1
7.2.10.2
7.2.11
7.2.11.1
7.2.11.2
7.2.11.3
7.2.12
7.2.13
7.2.14
7.2.14.1
7.2.14.2
7.2.15
7.2.16
7.2.17
7.2.17.1
7.2.17.2
7.2.18
7.2.19
7.2.20
7.2.21
7.2.22
7.2.23
7.2.24
7.2.25
7.3
7.3.1
7.3.2
7.3.3
7.3.4
7.3.5
7.3.6
7.3.7
7.3.8
7.3.9
7.3.10
7.3.11
7.3.12
7.3.13
7.3.14
7.3.15
7.3.16
7.3.17
7.3.18
7.3.19
7.4
7.4.1
7.4.2
7.4.3
7.4.4
7.4.5
7.4.6
7.4.7
7.4.8
7.4.9
3GPP TS 29.274 V10.2.0 (2011-03)
Bearer Resource Command.........................................................................................................................

Bearer Resource Failure Indication..............................................................................................................
Modify Bearer Request................................................................................................................................
Modify Bearer Response..............................................................................................................................
Delete Session Request and Delete Bearer Request....................................................................................
Delete Session Request..........................................................................................................................
Delete Bearer Request............................................................................................................................
Delete Session Response and Delete Bearer Response...............................................................................
Delete Session Response........................................................................................................................
Delete Bearer Response.........................................................................................................................
Downlink Data Notification messages.........................................................................................................
Downlink Data Notification...................................................................................................................
Downlink Data Notification Acknowledge............................................................................................
Downlink Data Notification Failure Indication......................................................................................
Delete Indirect Data Forwarding Tunnel Request........................................................................................
Delete Indirect Data Forwarding Tunnel Response.....................................................................................
Modify Bearer Command and Failure Indication........................................................................................
Modify Bearer Command......................................................................................................................
Modify Bearer Failure Indication...........................................................................................................
Update Bearer Request.................................................................................................................................
Update Bearer Response..............................................................................................................................
Delete Bearer Command and Failure Indication..........................................................................................
Delete Bearer Command........................................................................................................................
Delete Bearer Failure Indication............................................................................................................
Create Indirect Data Forwarding Tunnel Request........................................................................................
Create Indirect Data Forwarding Tunnel Response.....................................................................................
Void..............................................................................................................................................................
Release Access Bearers Request..................................................................................................................
Release Access Bearers Response................................................................................................................
Stop Paging Indication.................................................................................................................................
Modify Access Bearers Request..................................................................................................................
Modify Access Bearers Response................................................................................................................
Mobility Management Messages.......................................................................................................................
Forward Relocation Request........................................................................................................................
Forward Relocation Response.....................................................................................................................
Forward Relocation Complete Notification.................................................................................................
Forward Relocation Complete Acknowledge..............................................................................................
Context Request...........................................................................................................................................
Context Response.........................................................................................................................................
Context Acknowledge..................................................................................................................................
Identification Request..................................................................................................................................
Identification Response................................................................................................................................
Forward Access Context Notification..........................................................................................................
Forward Access Context Acknowledge.......................................................................................................
Detach Notification......................................................................................................................................
Detach Acknowledge...................................................................................................................................
Change Notification Request......................................................................................................................
Change Notification Response...................................................................................................................
Relocation Cancel Request........................................................................................................................
Relocation Cancel Response......................................................................................................................
Configuration Transfer Tunnel...................................................................................................................
RAN Information Relay.............................................................................................................................
CS Fallback and SRVCC related messages.....................................................................................................
Suspend Notification..................................................................................................................................
Suspend Acknowledge...............................................................................................................................
Resume Notification..................................................................................................................................
Resume Acknowledge................................................................................................................................
CS Paging Indication.................................................................................................................................
Alert MME Notification.............................................................................................................................
Alert MME Acknowledge..........................................................................................................................
UE Activity Notification............................................................................................................................
UE Activity Acknowledge.........................................................................................................................
3GPP
Release 10
7.5
7.5.1
7.5.2
7.6
7.7
7.7.0
7.7.1
7.7.2
7.7.3
7.7.4
7.7.5
7.7.6
7.7.7
7.7.8
7.7.9
7.7.10
7.7.11
7.8
7.9
7.9.0
7.9.1
7.9.2
7.9.3
7.9.4
7.9.5
7.9.6
7.10
7.11
7.12
7.12.1
7.12.2
7.13
7.13.1
7.13.2
7.13.3
7.13.4
7.13.5
7.13.6
8
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
8.12
8.13
8.14
8.15
8.16
8.17
8.18
8.19
8.20
8.21
8.21.1
3GPP TS 29.274 V10.2.0 (2011-03)
Non-3GPP access related messages.................................................................................................................

Create Forwarding Tunnel Request...........................................................................................................
Create Forwarding Tunnel Response.........................................................................................................
Reliable Delivery of Signalling Messages.......................................................................................................
Error Handling.................................................................................................................................................
Handling Piggybacked Messages..............................................................................................................
Protocol Errors...........................................................................................................................................
Different GTP Versions..............................................................................................................................
GTP Message of Invalid Length................................................................................................................
Unknown GTP Message............................................................................................................................
Unexpected GTP Message.........................................................................................................................
Missing Information Elements...................................................................................................................
Invalid Length Information Element..........................................................................................................
Semantically incorrect Information Element.............................................................................................
Unknown or unexpected Information Element..........................................................................................
Repeated Information Elements.................................................................................................................
TFT Error Handling....................................................................................................................................
Path Failure......................................................................................................................................................
Restoration and Recovery................................................................................................................................
General.......................................................................................................................................................
Delete PDN Connection Set Request.........................................................................................................
Delete PDN Connection Set Response......................................................................................................
Update PDN Connection Set Request........................................................................................................
Update PDN Connection Set Response.....................................................................................................
PGW Restart Notification..........................................................................................................................
PGW Restart Notification Acknowledge...................................................................................................
Fallback to GTPv1 mechanism........................................................................................................................
Fallback to GTPv0...........................................................................................................................................
Trace Management Messages..........................................................................................................................
Trace Session Activation............................................................................................................................
Trace Session Deactivation........................................................................................................................
MBMS Messages.............................................................................................................................................
MBMS Session Start Request....................................................................................................................
MBMS Session Start Response..................................................................................................................
MBMS Session Update Request................................................................................................................
MBMS Session Update Response..............................................................................................................
MBMS Session Stop Request....................................................................................................................
MBMS Session Stop Response..................................................................................................................
GTP-C Information Elements.............................................................................................................

Information Element Types..............................................................................................................................
Information Element Format...........................................................................................................................
International Mobile Subscriber Identity (IMSI).............................................................................................
Cause...............................................................................................................................................................
Recovery (Restart Counter).............................................................................................................................
Access Point Name (APN)..............................................................................................................................
Aggregate Maximum Bit Rate (AMBR).........................................................................................................
EPS Bearer ID (EBI).......................................................................................................................................
IP Address........................................................................................................................................................
Mobile Equipment Identity (MEI)...................................................................................................................
MSISDN..........................................................................................................................................................
Indication.........................................................................................................................................................
Protocol Configuration Options (PCO)...........................................................................................................
PDN Address Allocation (PAA)......................................................................................................................
Bearer Quality of Service (Bearer QoS)..........................................................................................................
Flow Quality of Service (Flow QoS)...............................................................................................................
RAT Type.........................................................................................................................................................
Serving Network..............................................................................................................................................
EPS Bearer Level Traffic Flow Template (Bearer TFT).................................................................................
Traffic Aggregate Description (TAD)..............................................................................................................
User Location Information (ULI)....................................................................................................................
CGI field....................................................................................................................................................
3GPP
Release 10
8.21.2
8.21.3
8.21.4
8.21.5
8.21.6
8.22
8.23
8.24
8.25
8.26
8.27
8.28
8.29
8.30
8.31
8.32
8.33
8.34
8.35
8.36
8.37
8.38
8.39
8.40
8.41
8.42
8.43
8.44
8.45
8.46
8.47
8.48
8.49
8.50
8.51
8.52
8.53
8.54
8.55
8.56
8.57
8.58
8.59
8.60
8.61
8.62
8.63
8.64
8.65
8.66
8.67
8.68
8.69
8.70
8.71
8.72
8.73
8.74
8.75
8.76
8.77
8.78
3GPP TS 29.274 V10.2.0 (2011-03)
SAI field.....................................................................................................................................................
RAI field....................................................................................................................................................
TAI field.....................................................................................................................................................
ECGI field..................................................................................................................................................
LAI field.....................................................................................................................................................
Fully Qualified TEID (F-TEID)......................................................................................................................
TMSI................................................................................................................................................................
Global CN-Id...................................................................................................................................................
S103 PDN Data Forwarding Info (S103PDF).................................................................................................
S1-U Data Forwarding (S1UDF).....................................................................................................................
Delay Value......................................................................................................................................................
Bearer Context.................................................................................................................................................
Charging ID.....................................................................................................................................................
Charging Characteristics..................................................................................................................................
Trace Information............................................................................................................................................
Bearer Flags.....................................................................................................................................................
Void..................................................................................................................................................................
PDN Type........................................................................................................................................................
Procedure Transaction ID (PTI)......................................................................................................................
DRX Parameter................................................................................................................................................
Void..................................................................................................................................................................
MM Context....................................................................................................................................................
PDN Connection..............................................................................................................................................
PDU Numbers..................................................................................................................................................
Packet TMSI (P-TMSI)...................................................................................................................................
P-TMSI Signature............................................................................................................................................
Hop Counter....................................................................................................................................................
UE Time Zone.................................................................................................................................................
Trace Reference...............................................................................................................................................
Complete Request Message.............................................................................................................................
GUTI................................................................................................................................................................
Fully Qualified Container (F-Container).........................................................................................................
Fully Qualified Cause (F-Cause).....................................................................................................................
Selected PLMN ID..........................................................................................................................................
Target Identification.........................................................................................................................................
Void..................................................................................................................................................................
Packet Flow ID................................................................................................................................................
RAB Context...................................................................................................................................................
Source RNC PDCP context info......................................................................................................................
UDP Source Port Number................................................................................................................................
APN Restriction...............................................................................................................................................
Selection Mode................................................................................................................................................
Source Identification........................................................................................................................................
Void..................................................................................................................................................................
Change Reporting Action................................................................................................................................
Fully qualified PDN Connection Set Identifier (FQ-CSID)............................................................................
Channel needed................................................................................................................................................
eMLPP Priority................................................................................................................................................
Node Type........................................................................................................................................................
Fully Qualified Domain Name (FQDN)..........................................................................................................
Private Extension.............................................................................................................................................
Transaction Identifier (TI)...............................................................................................................................
MBMS Session Duration.................................................................................................................................
MBMS Service Area........................................................................................................................................
MBMS Session Identifier................................................................................................................................
MBMS Flow Identifier....................................................................................................................................
MBMS IP Multicast Distribution....................................................................................................................
MBMS Distribution Acknowledge..................................................................................................................
User CSG Information (UCI)..........................................................................................................................
CSG Information Reporting Action.................................................................................................................
RFSP Index......................................................................................................................................................
CSG ID............................................................................................................................................................
3GPP
Release 10
8.79
8.80
8.81
8.82
8.83
8.84
8.85
8.86
8.87
8.88
8.89
3GPP TS 29.274 V10.2.0 (2011-03)
CSG Membership Indication (CMI)................................................................................................................

Service indicator..............................................................................................................................................
Detach Type.....................................................................................................................................................
Local Distinguished Name (LDN)..................................................................................................................
Node Features..................................................................................................................................................
MBMS Time to Data Transfer.........................................................................................................................
Throttling.........................................................................................................................................................
Allocation/Retention Priority (ARP)...............................................................................................................
EPC Timer.......................................................................................................................................................
Signalling Priority Indication..........................................................................................................................
Temporary Mobile Group Identity (TMGI).....................................................................................................
Security...............................................................................................................................................
10
IP - The Networking Technology used by GTP..................................................................................
10.1
10.2
11
11.1
11.1.1
11.1.2
11.2
11.2.1
11.2.2
IP Version.........................................................................................................................................................
IP Fragmentation..............................................................................................................................................
Notification of supported features between peer GTP-C entities........................................................

General.............................................................................................................................................................
Introduction................................................................................................................................................
Defining a feature.......................................................................................................................................
Dynamic discovery of supported features.......................................................................................................
General.......................................................................................................................................................
Features supported by direct peer GTP-C entities.....................................................................................
Annex A (Informative):
Backward Compatibility Guidelines for Information Elements.............
Annex B (informative):
Change History...........................................................................................
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
Scope
The present document specifies the stage 3 of the control plane of the GPRS Tunnelling Protocol, Version 2 for Evolved
Packet System interfaces (GTPv2-C).
In this document, unless otherwise specified, the S2b, S5 and S8 interfaces refer always to the GTP-based S2b, S5 and
S8 interfaces respectively .
GTPv2-C shall be used across the following EPC signalling interfaces: S3, S4, S5, S8, S10, S11 and S16.
GTPv2-C shall be used across the Sm and Sn interfaces for MBMS in EPS.
GTPv2-C based protocols shall also be used across Sv (3GPP TS 29.280 [15]) and S101 (3GPP TS 29.276 [14])
interfaces.
The procedures supported between the ePDG and the PGW on the S2b interface are specified in 3GPP TS 23.402 [45].
References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1]
3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
3GPP TS 23.003: "Numbering, addressing and identification".
[3]
3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access".
[4]
3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP)
across the Gn and Gp interface".
[5]
3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3".
[6]
IETF RFC 791 (STD 0005): "Internet Protocol", J. Postel.
[7]
IETF RFC 768 (STD 0006): "User Datagram Protocol", J. Postel.
[8]
3GPP TS 32.251: "Telecommunication Management; Charging Management; Packet Switched

(PS) domain charging.
[9]
3GPP TS 32.298: "Telecommunication Management; Charging Management; Charging Data

Record (CDR) parameter classification.
[10]
3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1

Application Protocol (S1AP)".
[11]
3GPP TS 33.102: "3G security; Security architecture".
[12]
3GPP TS 33.401: "3GPP System Architecture Evolution (SAE); Security architecture".
[13]
3GPP TS 29.281: "GPRS Tunnelling Protocol User Plane (GTPv1-U)".
3GPP
Release 10
10
3GPP TS 29.274 V10.2.0 (2011-03)
[14]
3GPP TS 29.276: "Optimized Handover Procedures and Protocols between E-UTRAN Access and
cdma2000 HRPD Access Stage 3".
[15]
3GPP TS 29.280: "3GPP EPS Sv interface (MME to MSC) for SRVCC".
[16]
IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification".
[17]
3GPP TS 23.007: "Restoration procedures".
[18]
3GPP TS 32.422: "Telecommunication management; Subscriber and equipment trace; Trace

control and configuration management ".
[19]
3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".
[20]
3GPP TS 36.414: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 data
transport".
[21]
3GPP TS 23.272: "Circuit switched fallback in Evolved Packet System; Stage 2".
[22]
3GPP TS 29.118: "Mobility Management Entity (MME) - Visitor Location Register (VLR) SGs
interface specification".
[23]
3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet".
[24]
void
[25]
ITU-T Recommendation E.164: "The international public telecommunication numbering plan".
[26]
3GPP TS 29.275: "Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunnelling protocols; Stage
3".
[27]
3GPP TS 44.018: "Mobile radio interface layer 3 specification; Radio Resource Control Protocol".
[28]
3GPP TS 48.008: "Mobile-services Switching Centre - Base Station System (MSC-BSS) interface;
Layer 3 specification".
[29]
3GPP TS 29.212: "Policy and charging control over Gx reference point".
[30]
3GPP TS 24.007: "Mobile radio interface signalling layer 3; General aspects".
[31]
IETF RFC 1035:"Domain Names - Implementation and Specification".
[32]
3GPP TS 29.303: "Domain Name System Procedures; Stage 3".
[33]
3GPP TS 25.413: "UTRAN Iu Interface RANAP Signalling".
[34]
3GPP TS 48.018: "General Packet Radio Service (GPRS); Base Station System (BSS) - Serving
GPRS Support Node (SGSN); BSS GPRS Protocol (BSSGP)".
[35]
3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".
[36]
3GPP TS 32.295: "Charging management; Charging Data Record (CDR) transfer".
[37]
3GPP TS 23.246: "Multimedia Broadcast Multicast Service (MBMS); Architecture and functional
description".
[38]
3GPP TS 29.061: "Interworking beween the Public Land Mobile Network (PLMN) supporting
Packet Based Services and Packet Data Networks (PDN) ".
[39]
IETF RFC 3588: "Diameter Base Protocol ".
[40]
IETF RFC 4607: "Source-Specific Multicast for IP".
[41]
3GPP TS 29.002: "Mobile Application Part (MAP) specification".
3GPP
Release 10
11
3GPP TS 29.274 V10.2.0 (2011-03)
[42]
3GPP TS 29.010: "Information element mapping between Mobile Station - Base Station System
and BSS - Mobile-services Switching Centre (MS - BSS - MSC) Signalling procedures and the
Mobile Application Part (MAP)".
[43]
3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2".
[44]
3GPP TS 32.423: " Telecommunication management; Subscriber and equipment trace: Trace data
definition and management".
[45]
3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses.
[46]
3GPP TR 25.999: " HSPA Evolution (FDD)".
Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].
GTP-PDU: GTP Protocol Data Unit is either a GTP-C Message or a GTP-U Message. GTP-U Message may be either a
signalling message across the user plane tunnel, or a G-PDU (see clause 6).
Signalling Message: any GTP-PDU (GTP-C or GTP-U) except the G-PDU.
G-PDU: GTP user plane message, which carries the original packet (payload). G-PDU consists of GTP-U
header and a T-PDU.
T-PDU: original packet, for example an IP datagram, from an UE or a network node in an external packet data
network. A T-PDU is the payload that is tunnelled in the GTP-U tunnel.
GTP-C Message: GTP control plane message type of a GTP-PDU. GTP-C message consists of GTP-C header,
which is followed by zero or more information elements.
GTP-U Message: GTP user plane message. The user plane messages are used to carry user data packets, and
also signalling messages e.g. for path management and error indication. Therefore, GTP-U message consists of
GTP-U header, which is followed by either a T-PDU, or zero or more information elements.
GTP Tunnel: A GTP tunnel is a communication tunnel between two GTP nodes (see subclause 4.1 "GTP Tunnel").
Tunnel Endpoint: A tunnel endpoint is identified with a TEID, an IP address and a UDP port number (see subclause
4.1 "GTP Tunnel").
Tunnel Endpoint Identifier (TEID): unambiguously identifies a tunnel endpoint in scope of a path (see subclause 4.1
"GTP Tunnel").
3.2 Symbols
For the purposes of the present document, the following symbols apply:
S1-U
X2
Interface between SGW and eNodeB

Interface between eNodeBs
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].
AMBR
Aggregate Maximum Bit Rate
3GPP
Release 10
APN
APN-NI
APN-OI
EBI
eNodeB
EPC
ePDG
EPS
F-TEID
G-PDU
GPRS
GTP
GTP-PDU
GTPv2-C
GTPv2-U
IMSI
IP
LBI
L1
L2
LGW
LIPA
MBMS
MEI
MSISDN
PAA
PCO
PDU
PDN
PGW
PTI
QoS
RAT
RIM
SGW
TEID
TEID-C
TEID-U
TFT
TLIV
UDP
ULI
12
Access Point Name

Access Point Name Network Identifier
Access Point Name Operator Identifier
EPS Bearer ID
Evolved Node B
Evolved Packet Core
Evolved Packet Data Gateway
Evolved Packet System
Fully Qualified Tunnel Endpoint Identifier
GTP-U non-signalling PDU
General Packet Radio Service
GPRS Tunnelling Protocol
GTP-C PDU or GTP-U PDU
GTP version 2, control plane
GTP version 2, user plane
International Mobile Subscriber Identity
Internet Protocol
Linked Bearer identity
Layer 1
Layer 2
Local Gateway
Local IP Access
Multimedia Broadcast/Multicast Service
Mobile Equipment Identity
Mobile Subscriber ISDN Number
PDN Address Allocation
Protocol Configuration Options
Protocol Data Unit
Packet Data Network or Public Data Network
PDN Gateway
Procedure Transaction Id
Quality of Service
Radio Access Type
RAN Information Management
Serving Gateway
Tunnel Endpoint Identifier
Tunnel Endpoint Identifier, control plane
Tunnel Endpoint Identifier, user plane
Traffic Flow Template
Type Length Instance Value
User Datagram Protocol
User Location Information
3GPP
3GPP TS 29.274 V10.2.0 (2011-03)
Release 10
13
3GPP TS 29.274 V10.2.0 (2011-03)
4 General
4.1 GTP Tunnel
GTP tunnels are used between two nodes communicating over a GTP based interface, to separate traffic into different
communication flows.
A GTP tunnel is identified in each node with a TEID, an IP address and a UDP port number. The receiving end side of a
GTP tunnel locally assigns the TEID value the transmitting side has to use. The TEID values are exchanged between
tunnel endpoints using GTP-C or S1-MME messages.
The criteria defining when the same or different GTP tunnels shall be used between the two nodes differs between the
control and the user plane, and also between interfaces.
For the control plane, for each end-point of a GTP-C tunnel:
-
The TEID-C shall be unique per PDN-Connection on GTP based S2b, S5 and S8 interfaces. The same tunnel
shall be shared for the control messages related to all bearers associated to the PDN-Connection. A TEID-C on
the S2b/S5/S8 interface shall be released after all its associated EPS bearers are deleted.
There shall be only one pair of TEID-Cs per UE on each of the S3, S10 and the S16 interfaces. The same tunnel
shall be shared for the control messages related to the same UE operation. A TEID-C on the S3/S10/S16
interface shall be released after its associated UE context is removed or the UE is detached.
There shall be only one pair of TEID-C per UE over the S11 and the S4 interfaces. The same tunnel shall be
shared for the control messages related to the same UE operation. A TEID-C on the S11/S4 interface shall be
released after all its associated EPS bearers are deleted.
There shall be only one pair of TEID-C per MBMS Bearer Service (i.e. per TMGI and, if provided, MBMS Flow
Identifier) over the Sm and Sn interfaces respectively. The same tunnel shall be shared for the control messages
related to the same MBMS Bearer Service. A TEID-C on the Sm/Sn interface shall be released after the MBMS
Bearer Session is stopped.
For GTP-U, a TEID-U is used according to 3GPP TS 29.281 [13].

NOTE:
GTP-U is based on GTP version 1 (GTPv1).
4.2 Protocol stack

4.2.0 General
The protocol stack for GTPv2 shall be as depicted in Figure 4.2.0-1.
3GPP
Release 10
14
3GPP TS 29.274 V10.2.0 (2011-03)
GTP
GTP
UDP
UDP
IP
IP
L2
L2
L1
L1
GTPv2 entity
GTPv2 entity
GTPv2 based
interface
Figure 4.2.0-1: GTPv2 stack

The GTPv2 headers are specified in the respective clauses of this specification.
The source and destination IP addresses and UDP ports used for each GTP-C message depend on the role that the
message plays in a message exchange. A message can be an Initial message, or a Triggered message, or a Triggered
Reply message to Triggered message. An Initial message is sent to a peer GTP entity with a sequence number chosen by
the sending entity (see subclause 7.6). A Triggered message is sent in response to an Initial message. Triggered Reply
message may be sent in response to a Triggered message. See subclause 7.6 for the sequence number usage.
Typically, a Request message is an Initial message, but a Request message may be a Triggered messages in certain
procedures where they are triggered by an Initial Command message. See subclause 4.2.5 for classification of the Initial
messages and their possible Triggered messages, as well as cases where there are Triggered Reply messages to the
Triggered messages.
Piggybacking is an optional feature. If the feature is supported, then the piggybacking of the initial messages on
triggered response messages for EUTRAN Initial Attach and UE-requested PDN Connectivity procedures shall be
implemented as per Annex F of 3GPP TS 23.401 [3].When piggybacking is used, a common IP header and a common
UDP header shall be used for the triggered response message and the piggybacked initial message as depicted in Figure
4.2.0-2. Immediately following the triggered response message is the piggybacked initial message, following which no
additional information shall be present. The subclause 5.5 specifies the usage of piggybacking-specific fields in the
GTP-C header.
IP header
UDP header
Triggered response message (P=1)
Piggybacked initial message (P=0)
Figure 4.2.0-2: Packet Format for the Piggybacking of messages
4.2.1 UDP header and port numbers

4.2.1.0
General
A User Datagram Protocol (UDP) compliant with IETF RFC 768 [7] shall be used.
4.2.1.1
Initial Messages
The UDP Destination Port number for GTPv2 Initial messages shall be 2123. It is the registered port number for GTPC.
3GPP
Release 10
15
3GPP TS 29.274 V10.2.0 (2011-03)
The UDP Source Port for a GTPv2 Initial message is a locally allocated port number at the sending GTP entity.
If GTPv2 and GTP' v2 modules are using the same IP address for sending messages, the implementation shall ensure
that while some source port number is used by GTPv2 messages, the same source port number shall not be used by
GTP' v2 messages. Otherwise, the IP interface may have difficulty to delivering a response message to the right
protocol entity.
4.2.1.2
Triggered Messages
The UDP Destination Port value of a GTPv2 Triggered message and for a Triggered Reply message shall be the value of
the UDP Source Port of the corresponding message to which this GTPv2 entity is replying, except in the case of the
SGSN pool scenario.
The UDP Source Port of a GTPv2 Triggered message and for a Triggered Reply message shall be the value from the
UDP Destination Port of the corresponding message to which this GTPv2 entity is replying, except in the case of the
SGSN pool scenario.
In the SGSN pool scenario, if the Identification Request or the Context Request messages have been forwarded by
another SGSN in the pool, the UDP Destination Port for the Identification Response or the Context Response message
shall be determined in the following way. The value from the information element "UDP Source Port Number", which
was sent in the corresponding forwarded request, shall be copied into the UDP Destination Port field. The UDP Source
Port for the Identification Response or the Context Response message may be a locally allocated port number at the
sending GTP entity.
4.2.1.3
Piggybacked Messages
A piggybacked initial message is carried as a concatenation after a triggered response message and they share a
common UDP header (see Figure 4.2.0-2).
The UDP Destination port for the IP packet containing both the triggered response message and the piggybacked initial
message shall be the same as the port number used for the triggered response message.
The UDP Source port for the IP packet containing both the triggered response message and the piggybacked initial
message shall be the same as the port number used for the triggered response message.
4.2.2 IP header and IP addresses

4.2.2.1
Initial Messages
The IP Destination Address of a GTPv2 Initial message shall be an IP address of the destination GTPv2 entity.
During the network triggered service restoration procedure (see 3GPP TS 23.007 [17]), if an MME/S4-SGSN sends
Downlink Data Notification Failure Indication message to the SGW, then the destination address for this message shall
be the source IP address of the Downlink Data Notification message received earlier.
The IP Source Address of a GTPv2 Initial message shall be an IP address of the source GTPv2 entity from which the
Initial message is originating.
4.2.2.2
Triggered Messages
The IP Destination Address of a GTPv2 Triggered message and for a Triggered Reply message shall be copied from the
IP Source Address of the message to which this GTPv2 entity is replying, except in the case of the SGSN pool scenario.
The IP Source Address of a GTPv2 Triggered message and for a Triggered Reply message shall be copied from the IP
destination address of the message to which this GTPv2 entity is replying, except in the case of SGSN pool scenario.
In the SGSN pool scenario, if the Identification Request or the Context Request messages have been forwarded by
another SGSN in the pool, the IP Source address for the Identification Response or the Context Response messages
shall be locally allocated by the sending GTP entity. The IP Destination Address for the Identification Response or
Context Response messages shall be determined in the following way. The value from the information element
"Address for Control Plane", which was sent in the corresponding Identification Request message; or the value from the
3GPP
Release 10
16
3GPP TS 29.274 V10.2.0 (2011-03)
information element "S3/S16/S10 Address and TEID for Control Plane", which was sent in the corresponding Context
Request message, shall be copied into the IP Destination Address field.
4.2.2.3
Piggybacked Messages
A piggybacked initial message is carried as a concatenation after a triggered response message and they share a
common IP header (see Figure 4.2.0-2).
The IP Source Address for the IP packet containing both the triggered response message and the piggybacked initial
message shall be the same as the IP Address used for the triggered response message.
The IP Destination Address for the IP packet containing both the triggered response message and the piggybacked initial
message shall be the same as the IP Address used for the triggered response message.
4.2.3 Layer 2
Typically Ethernet should be used as a Layer 2 protocol, but operators may use any other technology.
4.2.4 Layer 1
Operators may use any appropriate Layer 1 technology.
4.2.5 Messages with GTPv2 defined replies: Classification of Initial and

Triggered Messages
NOTE1: Other clauses of this specification and Stage 2 documents define in detail when a reply message is
expected in an end-to-end procedure. Reply messages are triggered messages.
The expected reply to a Request message is a Triggered message and the reply has the same message name as the
Request but with "Response" replacing "Request". If a Request message is a reply to a Command message, then the
Request message is a Triggered message; otherwise the Request message is an Initial message. Responses do not have
replies except when a "Context Acknowledge" is required as a reply to "Context Response" message as specified in
relevant Stage 2 procedures. Context Acknowledge is always triggered message and does not have a reply.
NOTE2: The "Context Acknowledge" message is sent only if the "Context Response" message is received with the
acceptance cause.
A message whose name ends in "Command" is always an initial message. If a "Command" message fails, the name of
the reply message is constructed by replacing "Command" with "Failure Indication". Apart from "Downlink Data
Notification Failure Indication" message, a "Failure Indication" is a Triggered message. The "Failure Indication"
message does not have a reply. If a "Command" message is successful, its reply will be a Request as specified in
relevant Stage 2 procedures.
A message whose name ends in "Notification" is always an Initial message, The expected Triggered message in reply
has the same message name but with "Acknowledge" replacing "Notification", except for the case of the message
"Downlink Data Notification" which has the reply "Downlink Data Notification Acknowledge" and "PGW Resart
Notification" which has the reply "PGW Restart Notification Acknowledge". An "Acknowledge" message does not have
a reply.
CS Paging Indication, Stop Paging Indication, RAN Information Relay, Configuration Transfer Tunnel, Trace Session
Activation, Trace Session Deactivation, and Downlink Data Notification Failure Indication messages are Initial
messages that do not have a reply.
A Version Not Supported Indication message is a Triggered message.
4.3 Transmission Order and Bit Definitions

The messages in this document shall be transmitted in network octet order starting with octet 1 with the Most
Significant Bit sent first.
3GPP
Release 10
17
3GPP TS 29.274 V10.2.0 (2011-03)
The most significant bit of an octet in a GTP message is bit 8. If a value in a GTP message spans several octets and
nothing else is stated, the most significant bit is bit 8 of the octet with the lowest number.
GTP Header for Control Plane
5.1 General format

Control Plane GTP uses a variable length header. Control Plane GTP header length shall be a multiple of 4 octets.
Figure 5.1-1 illustrates the format of the GTPv2-C Header.
Octets
1
2
3
4
m to
k(m+3)
n to (n+2)
(n+3)
Bits
5
4
3
2
1
P
T
Spare Spare Spare
Message Type
Message Length (1st Octet)
Message Length (2nd Octet)
If T flag is set to 1, then TEID shall be placed into octets 58. Otherwise, TEID field is not present at all.
Sequence Number
Spare
8
7
Version
Figure 5.1-1: General format of GTPv2 Header for Control Plane

Where:
-
if T = 0, TEID field is not present, k = 0, m = 0 and n = 5;
if T = 1, TEID field is present, k = 1, m = 5 and n = 9.
The usage of GTPv2-C header across the EPC specific interfaces is defined in the subclause 5.5 "Usage of the GTPv2-C
Header". Octet 1 bits shall be coded as follows:
-
Bits 6-8 represent the Version field.
Bit 5 represents the Piggybacking flag (P).
Bit 4 represents the TEID flag (T).
Bits 3-1 are spare, the sender shall set them to "0" and the receiving entity shall ignore them.
5.2 Control Plane GTP Extension Header

The legacy Extension Header mechanism is not used for the GTP version 2 control plane (GTPv2-C). Future extensions
will be implemented by adding Information Elements in the message body if new parameters are needed.
5.3 GTP-C header for Echo and Version Not Supported messages
The GTPv2-C message header for the Echo Request, Echo Response and Version Not Supported Indication messages
shall not contain the TEID field, but shall contain the Sequence Number fields, followed by one spare octet as depicted
in figure 5.3-1. The spare bits shall be set to zero by the sender and ignored by the receiver. For the Version Not
Supported Indication message header, the Sequence Number may be set to any number and shall be ignored by the
receiver.
3GPP
Release 10
18
Octets
1
2
3
4
5
6
7
8
7
Version
3GPP TS 29.274 V10.2.0 (2011-03)
Bits
5
4
3
2
1
P
T=0 Spare Spare Spare
Message Type
Sequence Number (1st Octet)
Sequence Number (2nd Octet)
Sequence Number (3rd Octet)
Spare
6
Figure 5.3-1: The format of Echo and Version Not Supported messages Header
5.4 EPC specific GTP-C header

Apart from the Echo Request, Echo Response and Version Not Supported Indication messages, the GTP-C message
header shall contain the TEID and Sequence Number fields followed by one spare octet. A typical GTP-C header is
depicted in figure 5.4-1. The spare bits shall be set to zero by the sender and ignored by the receiver.
Octets
1
2
3
4
5
6
7
8
9
10
11
12
Bits
5
4
3
2
1
P
T=1 Spare Spare Spare
Message Type
Tunnel Endpoint Identifier (1st Octet)
Tunnel Endpoint Identifier (2nd Octet)
Tunnel Endpoint Identifier (3rd Octet)
Tunnel Endpoint Identifier (4th Octet)
Sequence Number (1st Octet)
Sequence Number (2nd Octet)
Sequence Number (3rd Octet)
Spare
7
Version
Figure 5.4-1: The format of EPC specific GTPv2 Control Plane message Header
5.5 Usage of the GTPv2-C Header

5.5.1 General
The format of the GTPv2-C header is specified in subclause 5.1 "General format". The usage of the GTP-C header
across e.g. S101 (3GPP TS 29.276 [14]) and Sv (3GPP TS 29.280 [15]) interfaces are defined in their respective
specifications.
The usage of the GTPv2-C header for EPC specific interfaces shall be as defined below.
The first octet of the header shall be used is the following way:
-
Bits 8 to 6, which represent the GTP-C version, shall be set to decimal 2 ("010").
Bit 5 represents a "P" flag. If the "P" flag is set to "0", no piggybacked message shall be present. If the "P" flag
is set to "1", then another GTPv2-C message with its own header and body shall be present at the end of the
current message.
When present, a piggybacked message shall have its "P" flag set to "0" in its own header. If a Create Session
Response message (as part of EUTRAN initial attach or UE-requested PDN connectivity procedure) has the "P"
flag set to "1", then a Create Bearer Request message shall be present as the piggybacked message. As a response
to the Create Bearer Request message, if the Create Bearer Response has the "P" flag set to "1", then a Modify
Bearer Request (as part of EUTRAN initial attach or UE-requested PDN connectivity procedure) shall be present
as the piggybacked message. A Create Bearer Response with "P" flag set to "1" shall not be sent unless a Create
3GPP
Release 10
19
3GPP TS 29.274 V10.2.0 (2011-03)
Session Response with "P" flag set to "1" has been received for the same procedure. Apart from Create Session
Response and Create Bearer Response messages, all the EPC specific messages shall have the "P" flag set to "0".
-
Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be
set to "1".
Bit 3 is a spare bit. The sending entity shall set it to "0" and the receiving entity shall ignore it.
The usage of the fields in octets 2 - n of the header shall be as specified below.
-
Octet 2 represents the Message type field, which shall be set to the unique value for each type of control plane
message. Message type values are specified in Table 6.1-1 "Message types for GTPv2".
Octets 3 to 4 represent the Length field. This field shall indicate the length of the message in octets excluding the
mandatory part of the GTP-C header (the first 4 octets). The TEID (if present) and the Sequence Number shall be
included in the length count. The format of the Length field is specified in subclause 8.2 "Information Element
Format".
A piggybacked initial message and the preceding triggered response message present in the common IP/UDP
packet shall have their own length and sequence number in their respective GTP-C headers. The overall length
of the IP/UDP packet shall indicate the total length of the two GTP-C messages.
For EPC specific interfaces, T=1, and therefore octets 5 to 8 represent the Tunnel Endpoint Identifier (TEID)
field. This field shall unambiguously identify a tunnel endpoint in the receiving GTP-C entity. The Tunnel
Endpoint Identifier is set by the sending entity to the value provided by the corresponding receiving entity. If a
peer's TEID is not available the TEID field shall be present in a GTPv2-C header, but its value shall be set to "0",
as specified in subclause 5.5.2 "Conditions for sending TEID=0 in GTPv2-C header").
Downlink Data Notification, Downlink Data Notification Acknowledge and Downlink Data Notification Failure
Indication messages sent on S11/S4 as part of the Network Triggered Service Restoration procedure (see 3GPP
TS 23.007 [17]).
Octets 9 to 11 represent GTP Sequence Number field.
5.5.2 Conditions for sending TEID=0 in GTPv2-C header

If a peer's TEID is not available, the TEID field still shall be present in the header and its value shall be set to "0" in the
following messages:
-
Create Session Request message on S2b/S5/S8
Create Session Request message on S4/S11, if for a given UE, the SGSN/MME has not yet obtained the Control
TEID of the SGW.
Create Indirect Data Forwarding Tunnel Request message on S4/S11, if the SGW selected by the MME/S4SGSN for indirect data forwarding is different from the SGW used as anchor.
Identification Request/Response messages.
Forward Relocation Request message.
Context Request message.
Relocation Cancel Request message except for the case where the old SGSN/MME has already been assigned
the Tunnel Endpoint Identifier Control Plane of the new SGSN/MME.
Delete PDN Connection Set Request/Response messages.
3GPP
Release 10
20
3GPP TS 29.274 V10.2.0 (2011-03)
Configuration Transfer Tunnel message.
RAN Information Relay message.
If a node receives a message for which it has no context, it shall respond with "Context not found" Cause in the
corresponding response message to the sender. The TEID used in the GTPv2-C header in the response message
shall be set to zero.
MBMS Session Start Request message.
PGW Restart Notification / PGW Restart Notification Acknowledge messages.
NOTE:
The Change Notification Request/Response messages are also sent on the TEID zero. These messages are
not listed in the procedures above because the peers node TEID is available.
5.6 Format of the GTPv2-C Message

The GTP-C header may be followed by subsequent information elements dependent on the type of control plane
message.
Octets
1 to m
m+1 to n
Bits
5
4
3
2
GTP-C header
Zero or more Information Element(s)
Figure 5.6-1: GTP-C Header followed by subsequent Information Elements
3GPP
Release 10
21
3GPP TS 29.274 V10.2.0 (2011-03)
GTP-C Message Types and Message Formats
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.
3GPP
Release 10
22
Table 6.1-1: Message types for GTPv2
3GPP
3GPP TS 29.274 V10.2.0 (2011-03)
Release 10
Message Type
value (Decimal)
0
1
2
3
4 to 24
25 to 31
32
33
36
37
34
35
38
39
40 to 63
164
165
64
65
66
67
68
69
70
71
72
73
74 to 94
95
96
97
98
99
100
101
102
103 to 127
128
129
130
131
132
133
134
135
136
23
Message
3GPP TS 29.274 V10.2.0 (2011-03)

Reference
Reserved
Echo Request
Echo Response
Version Not Supported Indication
Reserved for S101 interface
Reserved for Sv interface
SGSN/MME/ePDG to PGW (S4/S11, S5/S8, S2b)
Create Session Request
Create Session Response
Delete Session Request
Delete Session Response
SGSN/MME to PGW (S4/S11, S5/S8)
Modify Bearer Request
Modify Bearer Response
Change Notification Request
Change Notification Response
For future use
Resume Notification
Resume Acknowledge
Messages without explicit response
Modify Bearer Command
(MME/SGSN/ePDG to PGW S11/S4, S5/S8, S2b)
Modify Bearer Failure Indication
(PGW to MME/SGSN/ePDG S5/S8, S11/S4, S2b)
Delete Bearer Command
(MME/SGSN to PGW S11/S4, S5/S8)
Delete Bearer Failure Indication
(PGW to MME/SGSN S5/S8, S11/S4))
Bearer Resource Command
(MME/SGSN to PGW S11/S4, S5/S8)
Bearer Resource Failure Indication
(PGW to MME/SGSN S5/S8, S11/S4)
Downlink Data Notification Failure Indication
(SGSN/MME to SGW S4/S11)
Trace Session Activation
Trace Session Deactivation
Stop Paging Indication
(SGW to MME/SGSN S11/S4)
For future use
PGW to SGSN/MME/ePDG (S5/S8, S4/S11, S2b)
Create Bearer Request
Create Bearer Response
Update Bearer Request
Update Bearer Response
Delete Bearer Request
Delete Bearer Response
PGW to MME, MME to PGW, SGW to PGW, SGW to MME,
PGW to ePDG, ePDG to PGW (S5/S8, S11, S2b)
Delete PDN Connection Set Request
Delete PDN Connection Set Response
For future use
MME to MME, SGSN to MME, MME to SGSN, SGSN to
SGSN (S3/S10/S16)
Identification Request
Identification Response
Context Request
Context Response
Context Acknowledge
Forward Relocation Request
Forward Relocation Response
Forward Relocation Complete Notification
Forward Relocation Complete Acknowledge
3GPP
Initial
Triggered
X
X
X
TS 29.276 [14]
TS 29.280 [15]
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Release 10
Message Type
value (Decimal)
137
138
139
140
141
142 to 148
152
149
150
151
153
154
155
156
157 to 159
162
163
160
161
166
167
168
169
170
171
172 to 175
176
177
179
180
178
181 to 199
200
201
202 to 210
211
212
213 to 230
231
232
233
234
235
236
237 to 239
240 to 255
3GPP TS 29.274 V10.2.0 (2011-03)
24
Message
Reference
Forward Access Context Notification

Forward Access Context Acknowledge
Relocation Cancel Request
Relocation Cancel Response
Configuration Transfer Tunnel
For future use
RAN Information Relay
SGSN to MME, MME to SGSN (S3)
Detach Notification
Detach Acknowledge
CS Paging Indication
Alert MME Notification
Alert MME Acknowledge
UE Activity Notification
UE Activity Acknowledge
For future use
SGSN/MME to SGW, SGSN to MME (S4/S11/S3)
SGSN to SGSN (S16), SGW to PGW (S5/S8)
Suspend Notification
Suspend Acknowledge
SGSN/MME to SGW (S4/S11)
Create Forwarding Tunnel Request
Create Forwarding Tunnel Response
Create Indirect Data Forwarding Tunnel Request
Create Indirect Data Forwarding Tunnel Response
Delete Indirect Data Forwarding Tunnel Request
Delete Indirect Data Forwarding Tunnel Response
Release Access Bearers Request
Release Access Bearers Response
For future use
SGW to SGSN/MME (S4/S11)
Downlink Data Notification
Downlink Data Notification Acknowledge
PGW Restart Notification
PGW Restart Notification Acknowledge
SGW to SGSN (S4)
Reserved. Allocated in earlier version of the specification.
For future use
SGW to PGW, PGW to SGW (S5/S8)
Update PDN Connection Set Request
Update PDN Connection Set Response
For future use
MME to SGW (S11)
Modify Access Bearers Request
Modify Access Bearers Response
For future use
MBMS GW to MME/SGSN (Sm/Sn)
MBMS Session Start Request
MBMS Session Start Response
MBMS Session Update Request
MBMS Session Update Response
MBMS Session Stop Request
MBMS Session Stop Response
For future use
Other
For future use
Initial
Triggered
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
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:
3GPP
Release 10
25
3GPP TS 29.274 V10.2.0 (2011-03)
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 upto-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 subclause 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 subclause 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 subclause 7.7 shall be applied for protocol errors of
the embedded IEs.
Only the Cause information element shall be included in the response if the Cause contains a value that indicates that
the request is not accepted.
The following are exceptions:
-
Optionally, the Protocol Configuration Options, Recovery and Local Distinguished Name (LDN) information
elements may be included.
3GPP
Release 10
26
3GPP TS 29.274 V10.2.0 (2011-03)
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.
A Downlink Data Notification Acknowledge (with or) without an indication of success may also include a DL
low priority traffic Throttling IE. The PGW Back-Off Time IE may also be returned when rejecting a Create
Session Request with the cause "APN Congestion".
Failure Indication type messages do not have "Accept" types of cause values i.e. all used values indicate the
rejection, therefore the preceding rules do not apply. For Failure Indication type of triggered messages, some of
the Mandatory information elements, other than the Cause IE, may not be included if they are not available.
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 subclause 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 subclause 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 subclauses 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 subclauses 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 subclauses 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.
3GPP
Release 10
27
3GPP TS 29.274 V10.2.0 (2011-03)
6.2 Message Granularity

The GTPv2-C messages shall be sent per UE on the S3, S10 and S16 interfaces.
The GTPv2-C messages shall be sent per PDN-Connection on the 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 during TAU/RAU/Handover/SRNS Relocation Cancel Using S4/Inter RAT handover
Cancel procedure with SGW change/S1 based handover cancel procedure with SGW change;
Delete Bearer Request during a TAU/RAU/Handover procedure if ISR is being deactivated.
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.
GTP-C messages
7.1 Path Management Messages

7.1.0 General
Three path management messages are specified for GTP-C: Echo Request, Echo Response and Version Not Supported
Indication.
The usage of Echo Request / Response procedure is specified in 3GPP TS 23.007 [17].
7.1.1 Echo Request

Table 7.1.1-1 specifies the information elements included in the Echo Request message.
The Recovery information element contains the local Restart Counter, which is specified in 3GPP TS 23.007 [17])
The optional Private Extension contains vendor or operator specific information.
3GPP
Release 10
28
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.1.1-1: Information Elements in Echo Request

Information
elements
Recovery
Sending Node
Features
Private Extension
Condition / Comment
M
CO This IE shall be sent towards a peer node on any GTPv2
interface if the sending node supports at least one feature
on this interface or if the sending node supports at least
one feature and does not know the interface type towards
the peer node. This IE may be present otherwise.
O
IE Type
Ins.
Recovery
Node Features
0
0
Private Extension
VS
7.1.2 Echo Response

Table 7.1.2-1 specifies the information elements included in the Echo Response message.
The Recovery information element contains the local Restart Counter, which is specified in 3GPP TS 23.007 [17])
The optional Private Extension contains vendor or operator specific information.
Table 7.1.2-1: Information Elements in Echo Response
Information
elements
Recovery
Sending Node
Features
Private Extension
Condition / Comment
M
CO This IE shall be sent towards a peer node on any GTPv2
interface if the sending node supports at least one feature
on this interface or if the sending node supports at least
one feature and does not know the interface type towards
the peer node. This IE may be present otherwise.
O
IE Type
Ins.
Recovery
Node Features
0
0
Private Extension
VS
7.1.3 Version Not Supported Indication

This message contains only the GTPv2 header and indicates the latest GTP version that the sending entity supports.
7.2 Tunnel Management Messages

7.2.0 General
A node shall include the Recovery information element if it is in contact with the peer for the first time or the node has
restarted recently and the new Restart Counter value has not yet been indicated to the peer. The peer receiving the
Recovery information element shall handle it as when an Echo Response message is received but shall consider the rest
of the message in accordance with the message semantics and parameters.
7.2.1 Create Session Request

The direction of this message shall be from MME/S4-SGSN to SGW and from SGW to PGW, and from ePDG to the
PGW (see Table 6.1-1).
The Create Session Request message shall be sent on the S11 interface by the MME to the SGW, and on the S5/S8
interface by the SGW to the PGW as part of the procedures:
-
E-UTRAN Initial Attach
UE requested PDN connectivity
The message shall also be sent on S4 interface by the SGSN to the SGW, and on the S5/S8 interface by the SGW to the
PGW as part of the procedures:
3GPP
Release 10
29
3GPP TS 29.274 V10.2.0 (2011-03)
PDP Context Activation
The message shall also be sent on the S11 interface by the MME to the SGW as part of the procedures:
-
Tracking Area Update procedure with Serving GW change
S1/X2-based handover with SGW change
UTRAN Iu mode to E-UTRAN Inter RAT handover with SGW change
GERAN A/Gb mode to E-UTRAN Inter RAT handover with SGW change
3G Gn/Gp SGSN to MME combined hard handover and SRNS relocation procedure
Gn/Gp SGSN to MME Tracking Area Update procedure
and on the S4 interface by the SGSN to the SGW as part of the procedures:
-
Routing Area Update with MME interaction and with SGW change
Gn/Gp SGSN to S4 SGSN Routing Area Update
Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update using S4 with SGW
change
Iu mode RA Update Procedure using S4 with SGW change
E-UTRAN to UTRAN Iu mode Inter RAT handover with SGW change
E-UTRAN to GERAN A/Gb mode Inter RAT handover with SGW change
Serving RNS relocation using S4 with SGW change
Combined hard handover and SRNS relocation using S4 with SGW change
Combined Cell / URA update and SRNS relocation using S4 with SGW change
Enhanced serving RNS relocation with SGW relocation
and on the S2b interface by the ePDG to the PGW as part of the procedures:
-
Initial Attach with GTP on S2b
UE initiated Connectivity to Additional PDN with GTP on S2b
Handover to Untrusted Non-3GPP IP Access with GTP on S2b
If the new Create Session Request message is received by the SGW with TEID 0 in the header for an existing active
PDN connection context (the existing PDN connection context is identified with the tuple [IMSI, EPS Bearer ID],
whereas IMSI shall be replaced by ME Identity for emergency attached UE without UICC or authenticated IMSI), this
Create Session Request message shall be treated as a request for a new session. The existing PDN connection context
should be deleted locally, before a new session is created.
If the new Create Session Request message is received by the PGW with TEID 0 in the header for an existing PDN
connection context (the existing PDN connection context is identified with the triplet [IMSI, EPS Bearer ID, Interface
type], whereas applicable Interface type here is S2b ePDG GTP-C interface or S5/S8 SGW GTP-C interface and IMSI
shall be replaced by ME Identity for emergency attached UE without UICC or authenticated IMSI), this Create Session
Request message shall be treated as a request for a new session. The existing PDN connection context should be deleted
locally, before a new session is created.
NOTE:
With GTP based S2b, the EPS Bearer IDs assigned for specific UE over S2b between an ePDG and PGW
are independent of the EPS Bearer IDs assigned for the same UE over S5/S8 and may overlap in value
(see 3GPP TS 23.402 [45] subcaluse 4.6.2).
3GPP
Release 10
30
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.1-1: Information Elements in a Create Session Request
3GPP
Release 10
Information
elements
IMSI
31
P
3GPP TS 29.274 V10.2.0 (2011-03)
Condition / Comment
C The IMSI shall be included in the message on the S4/S11

interface, and on S5/S8 interface if provided by the
MME/SGSN, except for the case:
- If the UE is emergency attached and the UE is
UICCless.
IE Type
Ins.
IMSI
MSISDN
MEI
The IMSI shall be included in the message on the S4/S11

interface, and on S5/S8 interface if provided by the
MME/SGSN, but not used as an identifier
if UE is emergency attached but IMSI is not
authenticated.
The IMSI shall be included in the message on the S2b
interface.
MSISDN
ME Identity (MEI)
C For an E-UTRAN Initial Attach the IE shall be included

when used on the S11 interface, if provided in the
subscription data from the HSS.
For a PDP Context Activation procedure the IE shall be
included when used on the S4 interface, if provided in the
subscription data from the HSS.
The IE shall be included for the case of a UE Requested
PDN Connectivity, if the MME has it stored for that UE.
It shall be included when used on the S5/S8 interfaces if
provided by the MME/SGSN.
The ePDG shall include this IE on the S2b interface during
an Attach with GTP on S2b and a UE initiated Connectivity
to Additional PDN with GTP on S2b, if provided by the
HSS/AAA.
C The MME/SGSN shall include the ME Identity (MEI) IE on
the S11/S4 interface:
- If the UE is emergency attached and the UE is
UICCless
-
CO
C
User Location
Information (ULI)
CO
C
Serving Network
RAT Type
If the UE is emergency attached and the IMSI is not

authenticated
For all other cases the MME/SGSN shall include the ME

Identity (MEI) IE on the S11/S4 interface if it is available.
If the SGW receives this IE, it shall forward it to the PGW
on the S5/S8 interface.
This IE shall be included on the S11 interface for E-UTRAN
Initial Attach and UE-requested PDN Connectivity
procedures. It shall include ECGI&TAI. The MME/SGSN
shall also include it on the S11/S4 interface for
TAU/RAU/X2-Handover/Enhanced SRNS Relocation
procedure if the PGW has requested location information
ULI
change reporting and MME/SGSN support location
information change reporting. The SGW shall include this
IE on S5/S8 if it receives the ULI from MME/SGSN.
This IE shall also be included on the S4 and S5/S8
interfaces for PDP Context Activation procedure. It shall
include either the CGI or SAI or RAI.
This IE shall be included on the S4/S11, S5/S8 and S2b
interfaces for an E-UTRAN initial attach, a PDP Context
Activation, a UE requested PDN connectivity, an Attach
with GTP on S2b, a UE initiated Connectivity to Additional
PDN with GTP on S2b and a Handover to Untrusted Non- Serving Network
3GPP IP Access with GTP on S2b.
CO This IE shall be included on S4/S11 for

RAU/TAU/Handover with SGW relocation procedures.
M This IE shall be set to the 3GPP access type or to the
value matching the characteristics of the non-3GPP access
the UE is using to attach to the EPS.
The ePDG may use the access technology type of the
untrusted non-3GPP access network if it is able to acquire
3GPP
RAT Type
Release 10
32
it; otherwise it shall indicate Virtual as the RAT Type.
See NOTE 3, NOTE 4.
3GPP
3GPP TS 29.274 V10.2.0 (2011-03)
Release 10
Indication Flags
Sender F-TEID for

Control Plane
PGW S5/S8 Address
for Control Plane or
PMIP
Access Point Name
(APN)
Selection Mode
33
3GPP TS 29.274 V10.2.0 (2011-03)
C This IE shall be included if any one of the applicable flags

is set to 1.
Applicable flags are:
S5/S8 Protocol Type: This flag shall be used on
the S11/S4 interfaces and set according to the
protocol chosen to be used on the S5/S8
interfaces.
Indication
F-TEID
C This IE shall be sent on the S11 / S4 interfaces. The TEID

or GRE Key is set to "0" in the E-UTRAN initial attach, the
PDP Context Activation and the UE requested PDN
connectivity procedures.
M
F-TEID
APN
Selection Mode
Dual Address Bearer Flag: This flag shall be used

on the S2b, S11/S4 and S5/S8 interfaces and shall
be set to 1 when the PDN Type, determined based
on UE request and subscription record, is set to
IPv4v6 and all SGSNs which the UE may be
handed over to support dual addressing. This shall
be determined based on node pre-configuration by
the operator.
Handover Indication: This flag shall be set to 1 on

the S11/S4 and S5/S8 interface during an EUTRAN Initial Attach or a UE Requested PDN
Connectivity or aPDP Context Activation procedure
if the PDN connection/PDP Context is handed-over
from non-3GPP access.
This flag shall be set to 1 on the S2b interface
during a Handover to Untrusted Non-3GPP IP
Access with GTP on S2b and IP address
preservation is requested by the UE.
Operation Indication: This flag shall be set to 1 on

the S4/S11 interface for a TAU/RAU procedure
with SGW relocation, Enhanced SRNS Relocation
with SGW relocation and X2-based handovers with
SGW relocation.
Direct Tunnel Flag: This flag shall be used on the

S4 interface and set to 1 if Direct Tunnel is used.
Piggybacking Supported: This flag shall be set to 1

only if the MME/ SGW supports the piggybacking
feature as described in Annex F of 3GPP TS
23.401 [3]. This flag shall be set to 1 on S5/S8 only
when both the MME and the SGW support
piggybacking.
Change Reporting support Indication: shall be

used on S4/S11, S5/S8 and set if the SGSN/MME
supports location Info Change Reporting. See
NOTE2.
CSG Change Reporting Support Indication: shall

be used on S4/S11, S5/S8 and set if the
SGSN/MME supports CSG Information Change
Reporting. See NOTE 2.
Unauthenticated IMSI: This flag shall be set to 1 on

the S4/S11 and S5/S8 interfaces if the IMSI
present in the message is not authenticated and is
for an emergency attached UE.
C This IE shall be included on the S4/S11 and S5/S8

3GPP
Release 10
34
3GPP TS 29.274 V10.2.0 (2011-03)
Activation and a UE requested PDN connectivity.

This IE shall be included on the S2b interface for an Initial
Attach with GTP on S2b and a UE initiated Connectivity to
Additional PDN with GTP on S2b.
It shall indicate whether a subscribed APN or a non
subscribed APN chosen by the MME/SGSN/ePDG was
selected.
3GPP
Release 10
PDN Type
PDN Address
Allocation (PAA)
Maximum APN
Restriction
Aggregate Maximum
Bit Rate (APN-AMBR)
Linked EPS Bearer ID
Protocol
Configuration Options
(PCO)
35
3GPP TS 29.274 V10.2.0 (2011-03)
CO When available, this IE shall be sent by the MME/SGSN on

the S11/S4 interface during TAU/RAU/HO with SGW
relocation.
PDN Type
Activation and a UE requested PDN connectivity.
This IE shall be set to IPv4, IPv6 or IPv4v6. This is based
on the UE request and the subscription record retrieved
from the HSS (for MME see 3GPP TS 23.401 [3], clause
5.3.1.1, and for SGSN see 3GPP TS 23.060 [35], clause
9.2.1). See NOTE 1.
C This IE shall be included the S4/S11, S5/S8 and S2b
Activation, a UE requested PDN connectivity, an Attach
PDN with GTP on S2b and a Handover to Untrusted Non3GPP IP Access with GTP on S2b. For PMIP-based
S5/S8, this IE shall also be included on the S4/S11
interfaces for TAU/RAU/Handover cases involving SGW
relocation.
The PDN type field in the PAA shall be set to IPv4, or IPv6
or IPv4v6 by MME, based on the UE request and the
subscription record retrieved from the HSS.
For static IP address assignment (for MME see 3GPP TS
23.401 [3], clause 5.3.1.1, for SGSN see 3GPP TS 23.060
[35], clause 9.2.1, and for ePDG see 3GPP TS 23.402 [45]
subclause 4.7.3), the MME/SGSN/ePDG shall set the IPv4
PAA
address and/or IPv6 prefix length and IPv6 prefix and
Interface Identifier based on the subscribed values
received from HSS, if available. The value of PDN Type
field shall be consistent with the value of the PDN Type IE,
if present in this message.
For a Handover to Untrusted Non-3GPP IP Access with
GTP on S2b, the ePDG shall set the IPv4 address and/or
IPv6 prefix length and IPv6 prefix and Interface Identifier
based on the IP address(es) received from the UE.
If static IP address assignment is not used, and for
scenarios other than a Handover to Untrusted Non-3GPP
IP Access with GTP on S2b, the IPv4 address shall be set
to 0.0.0.0, and/or the IPv6 Prefix Length and IPv6 prefix
and Interface Identifier shall all be set to zero.
CO This IE shall be sent by the MME/SGSN on S11/S4
interface during TAU/RAU/HO with SGW relocation.
APN Restriction
interfaces in the E-UTRAN initial attach, PDP Context
Activation and UE Requested PDN connectivity
procedures.
This IE denotes the most stringent restriction as required
by any already active bearer context. If there are no
already active bearer contexts, this value is set to the least
restrictive type.
C This IE represents the APN-AMBR. It shall be included on
AMBR
the S4/S11, S5/S8 and S2b interfaces for an E-UTRAN
initial attach, UE requested PDN connectivity, the PDP
Context Activation procedure using S4, the PS mobility
from the Gn/Gp SGSN to the S4 SGSN/MME procedures,
Attach with GTP on S2b and a UE initiated Connectivity to
Additional PDN with GTP on S2b.
C This IE shall be included on S4/S11 in RAU/TAU/HO
EBI
except in the Gn/Gp SGSN to MME/S4-SGSN
RAU/TAU/HO procedures with SGW change to identify the
default bearer of the PDN Connection
C This IE is not applicable to TAU/RAU/Handover. If
PCO
MME/SGSN receives PCO from UE (during the attach
procedures), the MME/SGSN shall forward the PCO IE to
SGW. The SGW shall also forward it to PGW.
3GPP
Release 10
36
3GPP TS 29.274 V10.2.0 (2011-03)
Bearer Contexts to be M Several IEs with the same type and instance value shall be Bearer Context
created
included on the S4/S11 and S5/S8 interfaces as necessary
to represent a list of Bearers. One single IE shall be
included on the S2b interface.
One bearer shall be included for an E-UTRAN Initial
Attach, a PDP Context Activation, a UE requested PDN
Connectivity, an Attach with GTP on S2b, a UE initiated
Connectivity to Additional PDN with GTP on S2b and a
Handover to Untrusted Non-3GPP IP Access with GTP on
S2b.
One or more bearers shall be included for a
Handover/TAU/RAU with an SGW change.
Bearer Contexts to be C This IE shall be included on the S4/S11 interfaces for the
Bearer Context
removed
TAU/RAU/Handover cases where any of the bearers
existing before the TAU/RAU/Handover procedure will be
deactivated as consequence of the TAU/RAU/Handover
procedure.
For each of those bearers, an IE with the same type and
instance value shall be included.
Trace Information
C This IE shall be included on the S4/S11 interface if an
Trace Information
SGW trace is activated, and/or on the S5/S8 and S2b
interfaces if a PGW trace is activated. See 3GPP TS
32.422 [18].
Recovery
C This IE shall be included on the S4/S11, S5/S8 and S2b
Recovery
interfaces if contacting the peer node for the first time.
MME-FQ-CSID
C This IE shall be included by the MME on the S11 interface
FQ-CSID
and shall be forwarded by an SGW on the S5/S8 interfaces
according to the requirements in 3GPP TS 23.007 [17].
SGW-FQ-CSID
C This IE shall included by the SGW on the S5/S8 interfaces
FQ-CSID
ePDG-FQ-CSID
C This IE shall be included by the ePDG on the S2b interface
FQ-CSID
UE Time Zone
CO This IE shall be included by the MME over S11 during
UE Time Zone
Initial Attach, UE Requested PDN Connectivity procedure.
0
0
1
2
0
This IE shall be included by the SGSN over S4 during PDP

Context Activation procedure.
This IE shall be included by the MME/SGSN over S11/S4
TAU/RAU/Handover with SGW relocation.
C If SGW receives this IE, SGW shall forward it to PGW
across S5/S8 interface.
User CSG
CO This IE shall be included on the S4/S11 interface for EUCI
Information (UCI)
UTRAN Initial Attach, UE-requested PDN Connectivity and
PDP Context Activation using S4 procedures if the UE is
accessed via CSG cell or hybrid cell. The MME/SGSN
shall also include it for TAU/RAU/Handover procedures if
the PGW has requested CSG info reporting and
MME/SGSN support CSG info reporting. The SGW shall
include this IE on S5/S8 if it receives the User CSG
information from MME/SGSN.
Charging
Charging
Characteristics
interfaces according to 3GPP TS 32.251 [8]
Characteristics
MME/S4-SGSN LDN O This IE is optionally sent by the MME to the SGW on the
Local
S11 interface and by the S4-SGSN to the SGW on the S4
Distinguished
interface (see 3GPP TS 32.423 [44]), when communicating
Name (LDN)
the LDN to the peer node for the first time.
SGW LDN
O This IE is optionally sent by the SGW to the PGW on the
Local
S5/S8 interfaces (see 3GPP TS 32.423 [44]), when
Distinguished
communicating the LDN to the peer node for the first time.
Name (LDN)
ePDG LDN
O This IE is optionally sent by the ePDG to the PGW on the
Local
S2b interfaces (see 3GPP TS 32.423 [44]), when
Distinguished
contacting the peer node for the first time.
Name (LDN)
Signalling Priority
CO The SGSN/MME shall include this IE on the S4/S11
Signalling Priority
Indication
interface if the UE indicates low access priority when
Indication
requesting to establish the PDN connection.
The SGW shall forward this IE in the Create Session
3GPP
0
0
1
2
0
Release 10
37
3GPP TS 29.274 V10.2.0 (2011-03)
Request message on the S5/S8 interfaces if received from

the MME/SGSN.
Private Extension
O This IE may be sent on the S5/S8, S4/S11 and S2b
Private Extension VS
interfaces.
NOTE 1: The conditional PDN Type IE is redundant on the S4/S11 and S5/S8 interfaces (as the PAA IE
contains exactly the same field). The receiver may ignore it. This IE is never sent on the S2b
interface.
NOTE 2: 3GPP TS 23.401 [3] (e.g. subclause 5.3.2.1) and 3GPP TS 23.060 [35] (e.g. subclause 9.2.2.1)
defines the MME/SGSN shall send the MS Info Change Reporting Support Indication to the PGW. In
such case MME/SGSN shall use the Change Reporting Support Indication and/or CSG Change
Reporting Support Indication (whichever is applicable), even if stage 2 refers to MS Info Change
Reporting Support Indication.
NOTE3: The methods that the ePDG may use to acquire the RAT type of the untrusted non-3GPP IP access
network are not specified in this release.
NOTE4: The PDN-GW can be informed about the type of access network used by the UE over several
reference points, see 3GPP TS 29.212 [30] for the mapping between the code values for the
different access network types.
Table 7.2.1-2: Bearer Context to be created within Create Session Request

Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
TFT
Bearer Context IE Type = 93 (decimal)

Length = n
Spare and Instance fields
Condition / Comment
M
O This IE may be included on the S4/S11 and S5/S8
interfaces.
S1-U eNodeB F-TEID C This IE shall be included on the S11 interface for X2-based
handover with SGW relocation.
S4-U SGSN F-TEID
C This IE shall be included on the S4 interface if the S4-U
interface is used.
S5/S8-U SGW FC This IE shall be included on the S5/S8 interface for an
TEID
"eUTRAN Initial Attach", a "PDP Context Activation" or a
"UE Requested PDN Connectivity".
S5/S8-U PGW FC This IE shall be included on the S4 and S11 interfaces for
TEID
the TAU/RAU/Handover cases when the GTP-based S5/S8
is used.
S12 RNC F-TEID
CO This IE shall be included on the S4 interface if the S12
interface is used in the Enhanced serving RNS relocation
with SGW relocation procedure.
S2b-U ePDG F-TEID C This IE shall be included on the S2b interface for an Attach
PDN with GTP on S2b and a Handover to Untrusted Non3GPP IP Access with GTP on S2b.
Bearer Level QoS
M
IE Type
Ins.
EBI
Bearer TFT
0
0
F-TEID
F-TEID
F-TEID
F-TEID
F-TEID
F-TEID
Bearer QoS
Table 7.2.1-3: Bearer Context to be removed within Create Session Request

Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
S4-U SGSN F-TEID

Length = n
Condition / Comment
M
C This IE shall be sent on the S4 interface if the S4-U
interface is used. See NOTE 1.
NOTE 1: The conditional S4-U SGSN F-TEID IE is redundant.
IE Type
Ins.
EBI
F-TEID
0
0
7.2.2 Create Session Response

The Create Session Response message shall be sent on the S11 interface by the SGW to the MME, and on the S5/S8
interface by the PGW to the SGW as part of the procedures:
3GPP
Release 10
38
3GPP TS 29.274 V10.2.0 (2011-03)
The message shall also be sent on S4 interface by the SGW to the SGSN, and on the S5/S8 interface by the PGW to the
SGW as part of the procedures:
-
The message shall also be sent on the S11 interface by the SGW to the MME as part of the procedures:
-
Tracking Area Update procedure with SGW change
S1/X2-based handover with SGW change
3G Gn/Gp SGSN to MME combined hard handover and SRNS relocation procedure
Gn/Gp SGSN to MME Tracking Area Update procedure
and on the S4 interface by the SGW to the SGSN as part of the procedures:
-
Routing Area Update with MME interaction and with SGW change
change
Serving RNS relocation using S4 with SGW change
Combined hard handover and SRNS relocation using S4 with SGW change
Combined Cell / URA update and SRNS relocation using S4 with SGW change
Enhanced serving RNS relocation with SGW relocation
and on the S2b interface by the PGW to the ePDG as part of the procedures:
-
Initial Attach with GTP on S2b
UE initiated Connectivity to Additional PDN with GTP on S2b
Handover to Untrusted Non-3GPP IP Access with GTP on S2b
If handling of default bearer fails, then cause at the message level shall be a failure cause.
Possible Cause values are specified in Table 8.4-1. Message specific cause values are:
-
"Request accepted".
"Request accepted partially".
"New PDN type due to network preference".
"New PDN type due to single address bearer only".
"Missing or unknown APN".
"GRE key not found".
3GPP
Release 10
39
3GPP TS 29.274 V10.2.0 (2011-03)
"Preferred PDN type not supported".
"All dynamic addresses are occupied".
"UE context without TFT already activated".
"Remote peer not responding".
"Semantic error in the TFT operation".
"Syntactic error in the TFT operation".
"Semantic errors in packet filter(s)".
"Syntactic errors in packet filter(s)".
"User authentication failed".
"APN access denied no subscription".
"APN Restriction type incompatibility with currently active PDN Connection".
"Version not supported by next peer".
"Denied in RAT".
"Protocol type not supported".
"APN congestion".
3GPP
Release 10
40
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.2-1: Information Elements in a Create Session Response
3GPP
Release 10
Information
elements
Cause
Change Reporting
Action
41
P
Condition / Comment
3GPP TS 29.274 V10.2.0 (2011-03)

IE Type
M See NOTE2.
Cause
Change Reporting
interfaces with the appropriate Action field if the location
Action
Change Reporting mechanism is to be started or stopped
for this subscriber in the SGSN/MME.
CSG Information
CO This IE shall be included on the S5/S8 and S4/S11
CSG Information
Reporting Action
interfaces with the appropriate Action field if the CSG Info
Reporting Action
reporting mechanism is to be started or stopped for this
subscriber in the SGSN/MME.
Sender F-TEID for
C This IE shall be sent on the S11/S4 interfaces. For the
F-TEID
Control Plane
S5/S8/S2b interfaces it is not needed because its content
would be identical to the IE PGW S5/S8/S2b F-TEID for
PMIP based interface or for GTP based Control Plane
interface.
PGW S5/S8/S2b FC PGW shall include this IE on the S5/S8 interfaces during
F-TEID
TEID for PMIP based
the Initial Attach, UE requested PDN connectivity and PDP
interface or for GTP
Context Activation procedures.
based Control Plane
If SGW receives this IE it shall forward the IE to MME/S4interface
SGSN on S11/S4 interaface.
This IE shall include the TEID in the GTP based S5/S8
case and the GRE key in the PMIP based S5/S8 case.
In PMIP based S5/S8 case, same IP address is used for
both control plane and the user plane communication.
PDN Address
Allocation (PAA)
APN Restriction
Aggregate Maximum C
Bit Rate (APN-AMBR)
Linked EPS Bearer ID C
Protocol
C
(PCO)
Bearer Contexts
created
PGW shall include this IE on the S2b interface during the

Attach with GTP on S2b, UE initiated Connectivity to
Additional PDN with GTP on S2b and Handover to
Untrusted Non-3GPP IP Access with GTP on S2b
procedures.
This IE shall be included on the S5/S8, S4/S11 and S2b
PAA
interfaces for the E-UTRAN initial attach, PDP Context
Activation, UE requested PDN connectivity, Attach with
GTP on S2b, UE initiated Connectivity to Additional PDN
with GTP on S2b and Handover to Untrusted Non-3GPP IP
Access with GTP on S2b procedures.
The PDN type field in the PAA shall be set to IPv4, or IPv6
or IPv4v6 by the PGW.
For the interfaces other than S2b, if the DHCPv4 is used
for IPv4 address allocation, the IPv4 address field shall be
set to 0.0.0.0.
This IE shall be included on the S5/S8 and S4/S11
APN Restriction
interfaces in the E-UTRAN initial attach, PDP Context
Activation and UE Requested PDN connectivity
procedures.
This IE shall also be included on S4/S11 during the Gn/Gp
SGSN to S4 SGSN/MME RAU/TAU procedures.
This IE denotes the restriction on the combination of types
of APN for the APN associated with this EPS bearer
Context.
This IE represents the APN-AMBR. It shall be included on
AMBR
the S5/S8, S4/S11 and S2b interfaces if the received APNAMBR has been modified by the PCRF.
This IE shall be sent on the S4/S11 interfaces during
EBI
Gn/Gp SGSN to S4-SGSN/MME RAU/TAU procedure to
identify the default bearer the PGW selects for the PDN
Connection.
This IE is not applicable for TAU/RAU/Handover. If PGW
PCO
decides to return PCO to the UE, PGW shall send PCO to
SGW. If SGW receives the PCO IE, SGW shall forward it
to MME/SGSN.
EPS bearers corresponding to Bearer Contexts sent in
Bearer Context
request message. Several IEs with the same type and
instance value may be included on the S5/S8 and S4/S11
as necessary to represent a list of Bearers. One single IE
shall be included on the S2b interface.
One bearer shall be included for E-UTRAN Initial Attach,
3GPP
Ins.
0
0
0
0
Release 10
42
3GPP TS 29.274 V10.2.0 (2011-03)
PDP Context Activation or UE Requested PDN

Connectivity , Attach with GTP on S2b, UE initiated
Connectivity to Additional PDN with GTP on S2b, and
S2b.
One or more created bearers shall be included for a
Handover/TAU/RAU with an SGW change. See NOTE 2.
Bearer Contexts
C EPS bearers corresponding to Bearer Contexts to be
Bearer Context
1
marked for removal
removed that were sent in the Create Session Request
message.
For each of those bearers an IE with the same type and
instance value shall be included on the S4/S11 interfaces.
Recovery
Recovery
0
interfaces if contacting the peer for the first time
Charging Gateway
C When Charging Gateway Function (CGF) Address is
FQDN
0
Name
configured, the PGW shall include this IE on the S5
interface.
See NOTE 1.
Charging Gateway
IP Address
0
Address
interface. See NOTE 1.
PGW-FQ-CSID
C This IE shall be included by the PGW on the S5/S8 and
FQ-CSID
0
S2b interfaces and, when received from S5/S8 be
forwarded by the SGW on the S11 interface according to
the requirements in 3GPP TS 23.007 [17].
SGW-FQ-CSID
C This IE shall be included by the SGW on the S11 interface
FQ-CSID
1
SGW LDN
O This IE is optionally sent by the SGW to the MME/SGSN
Local
0
on the S11/S4 interfaces (see 3GPP TS 32.423 [44]), when Distinguished
Name (LDN)
PGW LDN
O This IE is optionally included by the PGW on the S5/S8
Local
1
and S2b interfaces (see 3GPP TS 32.423 [44]), when
Distinguished
Name (LDN)
SGW LDN
Local
0
on the S11/S4 interfaces (see 3GPP TS 32.423 [44]), when Distinguished
Name (LDN)
PGW LDN
O This IE is optionally included by the PGW on the S5/S8
Local
1
interfaces (see 3GPP TS 32.423 [44]), when
Distinguished
Name (LDN)
PGW Back-Off Time
O This IE may be included on the S5/S8 and S4/S11
EPC Timer
0
interfaces when the PDN GW rejects the Create Session
Request with the cause "APN congestion". It indicates the
time during which the MME or S4-SGSN should refrain
from sending subsequent PDN connection establishment
requests to the PGW for the congested APN for services
other than Service Users/emergency services.
See NOTE 3.
Private Extension
interfaces.
NOTE1: Both Charging Gateway Name and Charging Gateway Address shall not be included at the same
time. When both are available, the operator configures a preferred value.
NOTE2: If the SGW cannot accept any of the "Bearer Context Created" IEs within Create Session Request
message, the SGW shall send the Create Session Response with appropriate reject Cause value.
NOTE 3: The last received value of the PGW Back-Off Time IE shall supersede any previous values received
from that PGW and for this APN in the MME/SGSN.
3GPP
Release 10
43
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.2-2: Bearer Context Created within Create Session Response

Octets 1
Octets 2 and 3
Octets 4
Information
elements
EPS Bearer ID
Cause
TFT
S1-U SGW F-TEID
S4-U SGW F-TEID
S5/S8-U PGW FTEID
S12 SGW F-TEID
S2b-U PGW F-TEID
Bearer Level QoS
Charging Id
Bearer Flags
NOTE1:
NOTE2:

Length = n
Condition / Comment
M
M This IE shall indicate if the bearer handling was successful,
and if not, it gives information on the reason. (NOTE1,
NOTE2)
O This IE may be included on the S4/S11, S5/S8 and S2b
interfaces.
interface is used.
interface is used.
C For GTP-based S5/S8, this User Plane IE shall be included
on S4/S11 and S5/S8 interfaces during the "eUTRAN Initial
Attach", a "PDP Context Activation" or a "UE Requested
PDN Connectivity".
C This IE shall be included on the S4 interface if the S12
interface is used.
C This IE (for user plane) shall be included on the S2b
interface during the Attach with GTP on S2b, UE initiated
Connectivity to Additional PDN with GTP on S2b, and
S2b.
interfaces if the received QoS parameters have been
modified.
C This IE shall be included on the S5/S8 interface for an EUTRAN initial attach, a PDP Context Activation and a UE
requested PDN connectivity.
O If the S5/S8 interface is GTP, this IE may be included on
the S4 interface, in order to support CAMEL charging at
the SGSN, for a PDP Context Activation, inter S4-SGSN
RAU with SGW change and Gn/Gp to S4-SGSN RAU.
O Applicable flags are:
PPC (Prohibit Payload Compression) : this flag
may be set on the S5/S8 and S4/S11 interfaces.
IE Type
Ins.
EBI
Cause
0
0
Bearer TFT
F-TEID
F-TEID
F-TEID
F-TEID
F-TEID
Bearer QoS
Charging Id
Bearer Flags
According to 3GPP TS 23.401 [3] e.g. subclause 5.5.1.2.2 "S1-based handover, normal" and 3GPP
TS 23.060 [35], during the handover procedure with an SGW change, except in the case of X2handover (NOTE2 addresses X2 based HO with SGW change case), the target MME/S4-SGSN
initiates the Create Session Request/Response and Modify Bearer Request/Response procedures
one after the other. After receiving the "Bearer Context Created" IEs within Create Session Request
message, the SGW may not accept some of these bearers. The SGW however shall return all
bearers with the "Bearer Context Created" IEs within Create Session Response message (this table),
but with different Cause values. Bearers that were not accepted by the SGW shall have an
appropriate rejection value in the Cause IE. The target MME/S4-SGSN shall send these nonaccepted bearers to the target SGW within the "Bearer Context to be removed" IE in a subsequent
Modify Bearer Request message. Therefore, the SGW shall allocate the DL S5/S8 SGW F-TEIDs
also for the non-accepted bearers. MME/S4-SGSN should remove all of the non-accepted bearers by
separate procedures (e.g. an MME/S4-SGSN initiated Dedicated Bearer Deactivation procedure).
According to 3GPP TS 23.401 [3] subclause 5.5.1.1.3, "X2-based handover with Serving GW
relocation", during the X2-handover procedure with an SGW change, the target MME/S4-SGSN shall
initiate only the Create Session Request/Response procedure. The SGW shall return all bearers
(including those not accepted by the SGW) with a "Bearer Context Created" IE within Create Session
Response message (this table), but with different Cause values. Bearers that were not accepted by
the SGW shall have an appropriate rejection value in the Cause IE, The MME/S4-SGSN should
remove these non-accepted bearers by separate procedures as well.
3GPP
Release 10
44
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.2-3: Bearer Context marked for removal within a Create Session Response
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Cause

Length = n
Condition / Comment
M
and if not, gives the information on the reason.
IE Type
Ins.
EBI
Cause
0
0
7.2.3 Create Bearer Request

The direction of this message shall be from PGW to SGW and from SGW to MME/S4-SGSN, and from PGW to ePDG
(see Table 6.1-1).
The Create Bearer Request message shall be sent on the S5/S8 interface by the PGW to the SGW and on the S11
interface by the SGW to the MME as part of the Dedicated Bearer Activation procedure.
The message shall also be sent on the S5/S8 interface by the PGW to the SGW and on the S4 interface by the SGW to
the SGSN as part of the Secondary PDP Context Activation procedure or the Network Requested Secondary PDP
Context Activation procedure.
The message shall also be sent on the S2b interface by the PGW to the ePDG as part of the Dedicated S2b bearer
activation with GTP on S2b.
Table 7.2.3-1: Information Elements in a Create Bearer Request
Information
elements
Procedure
Transaction Id (PTI)
Condition / Comment
IE Type
Ins.
C This IE shall be sent on the S5/S8 and S4/S11 interfaces

PTI
0
when the procedure was initiated by a UE Requested
Bearer Resource Modification Procedure or Secondary
PDP Context Activation Procedure.
The PTI shall be the same as the one used in the
corresponding Bearer Resource Command.
Linked Bearer Identity M This IE shall be included to indicate the default bearer
EBI
0
(LBI)
associated with the PDN connection.
Protocol
O This IE may be sent on the S5/S8 and S4/S11 interfaces.
PCO
0
(PCO)
Bearer Contexts
M Several IEs with this type and instance values shall be
Bearer Context
0
included as necessary to represent a list of Bearers.
PGW-FQ-CSID
FQ-CSID
0
S2b interfaces and, when received from S5/S8 be
SGW-FQ-CSID
FQ-CSID
1
Change Reporting
Change Reporting 0
Action
interfaces with the appropriate Action field If the location
Action
CSG Information
CSG Information
0
Reporting Action
Reporting Action
Private Extension
interfaces.
NOTE:
In the case that the procedure was initiated by a UE Requested Bearer Resource Modification Procedure
or Secondary PDP Context Activation Procedure, then there will be only one instance of the Bearer
Contexts IE in the Create Bearer Request.
3GPP
Release 10
45
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.3-2: Bearer Context within Create Bearer Request

Octets 1
Octets 2 and 3
Octets 4
Information
elements
EPS Bearer ID
TFT
S1-U SGW F-TEID
S5/8-U PGW F-TEID
S12 SGW F-TEID
S4-U SGW F-TEID
S2b-U PGW F-TEID
Bearer Level QoS
Charging Id
Bearer Flags

Length = n
Condition / Comment
M This IE shall be set to 0.

M This IE can contain both uplink and downlink packet filters
to be sent to the UE or the ePDG. Downlink packet filters
are also used by SGW for PMIP based S5/8 interfaces.
interface is used.
C This IE shall be sent on the S4, S5/S8 and S11 interfaces
for GTP-based S5/S8 interface. The MME/SGSN shall
ignore the IE on S11/S4 for PMIP-based S5/S8 interface.
C This IE shall be sent on the S4 interface if the S12
interface is used.
interface is used.
C This IE (for user plane) shall be sent on the S2b interface.
M
C This IE shall be sent on the S5/S8 interface.
O If the S5/S8 interface is GTP, this IE may be sent on the S4
interface, in order to support CAMEL charging at the
SGSN.
O Applicable flags are:
PPC (Prohibit Payload Compression) : this flag
may be set on the S5/S8 and S4/S11 interfaces
Protocol
O This IE may be sent on the S5/S8 and S4/S11 interfaces.
This bearer level IE takes precedence over the PCO IE in
(PCO)
the message body if they both exist.
IE Type
Ins.
EBI
Bearer TFT
0
0
F-TEID
F-TEID
F-TEID
F-TEID
F-TEID
Bearer QoS
4
0
Charging Id
Bearer Flags
PCO
7.2.4 Create Bearer Response

The Create Bearer Response message shall be sent on the S5/S8 interface by the SGW to the PGW, and on the S11
interface by the MME to the SGW as part of the Dedicated Bearer Activation procedure.
The message shall also be sent on the S5/S8 interface by the SGW to the PGW and on the S4 interface by the SGSN to
the SGW as part of Secondary PDP Context Activation procedure or the Network Requested Secondary PDP Context
Activation procedure.
The message shall also be sent on the S2b interface by the ePDG to the PGW as part of the Dedicated S2b bearer
activation with GTP on S2b.
-
"Request accepted".
"Context not found".
"Service not supported".
"Unable to page UE".
3GPP
Release 10
46
"UE not responding".
"Unable to page UE due to Suspension".
"UE refuses".
"Denied in RAT".
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.4-1: Information Elements in a Create Bearer Response

Information
elements
Cause
Bearer Contexts
Condition / Comment
IE Type
M
Cause
M Several IEs with this type and instance value shall be
Bearer Context
included on the S4/S11, S5/S8 and S2b interfaces as
necessary to represent a list of Bearers.
Recovery
Recovery
MME-FQ-CSID
C This IE shall be included by the MME on the S11
FQ-CSID
interfaceand shall be forwarded by the SGW on the S5/S8
interfaces according to the requirements in 3GPP TS
23.007 [17].
SGW-FQ-CSID
C This IE shall be included by the MME on the S11
FQ-CSID
interfaceand shall be forwarded by the SGW on the S5/S8
interfaces according to the requirements in 3GPP TS
23.007 [17].
ePDG-FQ-CSID
FQ-CSID
Protocol
C If the UE includes the PCO IE, then the MME/SGSN shall
PCO
copy the content of this IE transparently from the PCO IE
(PCO)
included by the UE. If the SGW receives PCO from
MME/SGSN, SGW shall forward it to the PGW.
O This IE is optionally included by the MME on the S11
interface or by the SGSN on the S4 interface.
UE Time Zone
CO The SGW shall forward this IE on the S5/S8 interface if the UE Time Zone
SGW supports this IE and it receives it from the
MME/SGSN.
User Location
ULI
CO The SGW shall forward this IE on the S5/S8 interface if the
Information (ULI)
MME/SGSN.
Private Extension
Private Extension
interfaces.
3GPP
Ins.
0
0
0
0
2
0
0
VS
Release 10
47
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.4-2: Bearer Context within Create Bearer Response

Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Cause
S1-U eNodeB F-TEID
S1-U SGW F-TEID
S5/8-U SGW F-TEID
S5/8-U PGW F-TEID
S12 RNC F-TEID
S12 SGW F-TEID
S4-U SGSN F-TEID
S4-U SGW F-TEID
S2b-U ePDG F-TEID
S2b-U PGW F-TEID
Protocol
(PCO)

Length = n
Condition / Comment
M
and if not, it gives information on the reason.
interface is used.
C This IE shall be sent on the S11 interface. It shall be used
to correlate the bearers with those in the Create Bearer
Request.
C This IE shall be sent on the S5/S8 interfaces.
C This IE shall be sent on the S5/S8 interfaces. It shall be
used to correlate the bearers with those in the Create
Bearer Request.
C This IE shall be sent on the S4 interface if the S12
interface is used.
C This IE shall be sent on the S4 interface. It shall be used to
correlate the bearers with those in the Create Bearer
Request.
interface is used.
C This IE shall be sent on the S4 interface. It shall be used to
correlate the bearers with those in the Create Bearer
Request.
C This IE shall be sent on the S2b interface.
C This IE shall be sent on the S2b interface. It shall be used
to correlate the bearers with those in the Create Bearer
Request.
CO If the UE includes the PCO IE in the corresponding
Activate dedicated EPS bearer context accept message,
then the MME/SGSN shall copy the content of this IE
transparently from the PCO IE included by the UE. If the
SGW receives PCO from MME/SGSN, SGW shall forward
it to the PGW. This bearer level IE takes precedence over
the PCO IE in the message body if they both exist.
IE Type
Ins.
EBI
Cause
0
0
F-TEID
F-TEID
F-TEID
F-TEID
2
3
F-TEID
F-TEID
F-TEID
F-TEID
F-TEID
F-TEID
8
9
PCO
7.2.5 Bearer Resource Command

A Bearer Resource Command message shall be sent from a MME to a SGW and forwarded to PGW as a part of the UE
requested bearer resource allocation procedure or UE requested bearer resource modification procedure (which is used
also for a dedicated bearer deactivation).
The message shall also be sent on the S4 interface by a SGSN to a SGW and on the S5/S8 interface by a SGW to a
PGW as part of the MS initiated PDP Context modification procedure, or secondary PDP context activation procedure.
Table 7.2.5-1 specifies the presence of the IEs in the message.
3GPP
Release 10
48
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.5-1: Information Elements in a Bearer Resource Command

Information
elements
(LBI)
Procedure
Flow Quality of
Service (Flow QoS)
Traffic Aggregate
Description (TAD)
RAT Type
Serving Network
User Location
Information (ULI)
EPS Bearer ID
Indication Flags
Condition / Comment
IE Type
Ins.
EBI
PTI
C This IE shall be included on the S4/S11 interface if the

Flow QoS
"Requested New QoS"/"Required QoS" is included in the
corresponding NAS message (see section 9.5.10 and
section 9.5.15a in 3GPP TS 24.008 [5]) or the "Required
traffic flow QoS" is included in the corresponding NAS
message (see section 8.3.8 and section 8.3.10 in 3GPP
TS 24.301 [23]).
If SGW receives this IE, SGW shall forward it to PGW
M The TAD consists of the description of the packet filter(s)
TAD
for a traffic flow aggregate.
C This IE shall be included for MS initiated PDP Context
RAT Type
modification procedure and Secondary PDP context
activation procedure.
O This IE may be included in the MS initiated PDP Context
Serving Network
modification procedure.
O This IE may be included in the MS initiated PDP Context
ULI
C This IE indicates the EPS Bearer that needs to be
EBI
modified. It shall be included for MS initiated PDP Context
modification procedure. For EUTRAN this IE shall be
present if it is triggered by the NAS Bearer Resource
Modification Request message and its value shall be set to
the value of the "EPS bearer identity for packet filter" IE
received in that NAS message.
O This IE shall be included if any one of the applicable flags
Indication
is set to 1.
Applicable flags:
Change Reporting Support Indication: this flag
may be included in the MS initiated PDP Context
-
S4-U SGSN F-TEID

S12 RNC F-TEID
0
0
0
0
1
Direct Tunnel Flag: this flag may be included in the

MS initiated PDP Context Modification procedure.
C This IE shall be included on the S4 interface when direct

tunnel is not established in the MS initiated PDP Context
modification procedure
tunnel flag is set to 1 in the MS initiated PDP Context
O
Protocol
(PCO)
Private Extension
O
NOTE:
F-TEID
F-TEID
PCO
Private Extension
VS
Depending on the protocol type on the S5/S8 interface, the SGW or the PGW will determine if the UE is
requesting an Allocation/Modification operation of bearer resources for a traffic flow aggregate based on
the TFT operation code and the packet filter ID value in the Traffic Aggregate (TAD) IE and/or the
presence of the EPS Bearer ID IE.
7.2.6 Bearer Resource Failure Indication

A Bearer Resource Failure Indication shall be sent by the PGW to an SGW and forwarded to the MME to indicate
failure of the UE requested bearer resource allocation procedure or UE requested bearer resource modification
procedure.
3GPP
Release 10
49
3GPP TS 29.274 V10.2.0 (2011-03)
The message shall also be sent by a PGW to an SGW and forwarded to an SGSN as part of the failure of an MS
initiated PDP Context modification procedure or secondary PDP context activation procedure.
-
"Semantic error in the TAD operation".
"Syntactic error in the TAD operation".
"Collision with network initiated request".
"Service denied".
"Bearer handling not supported".

Table 7.2.6-1: Information Elements in a Bearer Resource Failure Indication
Information
P
Condition / Comment
elements
Cause
M
Linked EPS Bearer ID M See subclause 6.1.1 "Presence requirements of
Information Elements".
Procedure
M See subclause 6.1.1 "Presence requirements of
Transaction ID (PTI)
Recovery
O
Private Extension
O
IE Type
Ins.
Cause
EBI
0
0
PTI
Recovery
Private Extension
0
VS
7.2.7 Modify Bearer Request

The direction of this message shall be from MME/S4-SGSN to SGW and/or from SGW to PGW (see Table 6.1-1).
The Modify Bearer Request message shall only be sent on the S11 interface by the MME to the SGW and on the S5/S8
interfaces by the SGW to the PGW as part of the procedures:
-
E-UTRAN Tracking Area Update without SGW Change
UE triggered Service Request
S1-based Handover
UTRAN Iu mode to E-UTRAN Inter RAT handover
GERAN A/Gb mode to E-UTRAN Inter RAT handover
3G SGSN to MME combined hard handover and SRNS relocation procedure
X2-based handover without SGW relocation
It shall also only be sent on the S4 interface by the SGSN to the SGW and on the S5/S8 interfaces by the SGW to the
PGW as part of the procedures:
-
Routeing Area Update with MME interaction and without SGW change
E-UTRAN to UTRAN Iu mode Inter RAT handover
3GPP
Release 10
50
3GPP TS 29.274 V10.2.0 (2011-03)
E-UTRAN to GERAN A/Gb mode Inter RAT handover
Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update to S4 SGSNs without
SGW change
Iu mode RA Update Procedure without SGW change
Serving RNS Relocation Procedure
Combined Hard Handover and SRNS Relocation Procedure
Combined Cell / URA Update and SRNS Relocation Procedure
Enhanced Serving RNS Relocation without SGW relocation
UE Initiated Service Request Procedure
Iu mode to A/Gb mode Intra SGSN Change
A/Gb mode to Iu mode Intra SGSN Change
Iu mode to A/Gb mode Inter-SGSN Change
A/Gb mode to Iu mode Inter-SGSN Change
Paging Response with no established user plane on S4
PDP Context Activation Procedure
only on the S4 interface by the SGSN to the SGW as part of the procedures:
-
RAB Assignment Procedure
SRVCC from E-UTRAN to UTRAN or GERAN with DTM HO support procedures and SRVCC from UTRAN
(HSPA) to UTRAN or GERAN with DTM HO support.
and only on the S5/S8 interfaces by the SGW to the PGW as part of the procedures:
-
X2 based handover with SGW relocation
Gn/Gp SGSN to MME Tracking Area Update
Enhanced Serving RNS Relocation with SGW relocation
Routeing Area Update with MME interaction and with SGW change
change
This message can be used as an implicit resume of the suspended bearers in the SGW and in the PGW (see 3GPP TS
23.216 [43] sections 6.2.2.1 and 6.3.2.1, 3GPP TS 23.272 [21] sections 6.3, 6.5 and 7.4).
3GPP
Release 10
51
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.7-1: Information Elements in a Modify Bearer Request
3GPP
Release 10
Information
elements
ME Identity (MEI)
User Location
Information (ULI)
Serving Network
RAT Type
Indication Flags
52
P
3GPP TS 29.274 V10.2.0 (2011-03)
Condition / Comment
IE Type
C This IE shall be sent on the S5/S8 interfaces for the Gn/Gp

MEI
SGSN to MME TAU.
C The MME/SGSN shall include this IE for
ULI
TAU/RAU/Handover procedures if the PGW has requested
location information change reporting and MME/SGSN
support location information change reporting.
An MME/SGSN which supports location information
change shall include this IE for UE-initiated Service
Request procedure if the PGW has requested location
information change reporting and the UEs location info
has changed.
The SGW shall include this IE on S5/S8 if it receives the
ULI from MME/SGSN.
CO This IE shall also be included on the S4/S11 interface for a
TAU/RAU/Handover with MME/SGSN change without
SGW change procedure, if the level of support (User
Location Change Reporting and/or CSG Information
Change Reporting) changes the MME shall include the
ECGI/TAI in the ULI, the SGSN shall include the CGI/SAI
in the ULI.
ULI from MME/SGSN.
CO This IE shall be included on S11/S4 interface for a
TAU/RAU/handover if Serving Network is changed.
This IE shall be included on S11/S4 interface for a
TAU/RAU when UE was ISR activated which is indicated
by ISRAU flag.
Serving Network
This IE shall be included on S11/S4 interface for UE
triggered Service Request when UE is ISR activated.
CO This IE shall be included on S5/S8 if receives this IE from
MME/SGSN.
C This IE shall be sent on the S11 interface for a TAU with
RAT Type
anSGSN interaction, UE triggered Service Request or an IRAT Handover.
This IE shall be sent on the S4 interface for a RAU with
MME interaction, a RAU with an SGSN change, a UE
Initiated Service Request or an I-RAT Handover.
This IE shall be sent on the S5/S8 interface if the RAT type
changes.
CO If SGW receives this IE from MME/SGSN during a
TAU/RAU/Handover with SGW change procedure, the
SGW shall forward it across S5/S8 interface to PGW.
CO The IE shall be sent on the S11/S4 interface for an inter
MM TAU or inter SGSN RAU when UE was ISR activated
which is indicated by ISRAU flag.
If ISR is active, this IE shall also be included on the S11
interface in the S1-U GTP-U tunnel setup procedure during
an intra-MME intra-SGW TAU procedure.
Indication
is set to 1.
ISRAI: This flag shall be used on S4/S11 interface
and set to 1 if the ISR is established between the
MME and the S4 SGSN.
-
Handover Indication: This flag shall be set to 1 on

the S4/S11 and S5/S8 interfaces during an EUTRAN Initial Attach or for a UE Requested PDN
Connectivity or a PDP Context Activation
procedure, if the PDN connection/PDP context is
handed-over from non-3GPP access.
Direct Tunnel Flag: This flag shall be used on the

S4 interface and set to 1 if Direct Tunnel is used.
Change Reporting support Indication: shall be
3GPP
Ins.
0
0
Release 10
53
3GPP TS 29.274 V10.2.0 (2011-03)
used on S4/S11, S5/S8 and set if the SGSN/MME

supports location Info Change Reporting. This flag
should be ignored by SGW if no message is sent
on S5/S8. See NOTE 4.
-
CSG Change Reporting Support Indication: shall

be used on S4/S11, S5/S8 and set if the
SGSN/MME supports CSG Information Change
Reporting. This flag shall be ignored by SGW if no
message is sent on S5/S8. See NOTE 4.
Change F-TEID support Indication: This flag shall

be used on S4/S11 for an IDLE state UE initiated
TAU/RAU procedure and set to 1 to allow the SGW
changing the GTP-U F-TEID.
3GPP
Release 10
54
Sender F-TEID for

Control Plane
3GPP TS 29.274 V10.2.0 (2011-03)
C This IE shall be sent on the S11 and S4 interfaces for a

F-TEID
0
TAU/RAU/ Handover with MME/SGSN change and without
any SGW change.
This IE shall be sent on the S5 and S8 interfaces for a
TAU/RAU/Handover with a SGW change.
Aggregate Maximum C The APN-AMBR shall be sent for the PS mobility from the
AMBR
0
Bit Rate (APN-AMBR)
Gn/Gp SGSN to the S4 SGSN/MME procedures..
Delay Downlink
C This IE shall be sent on the S11 interface for a UE
Delay Value
0
Packet Notification
triggered Service Request.
Request
CO This IE shall be sent on the S4 interface for a UE triggered
Service Request.
Bearer Contexts to be C This IE shall be sent on the S4/S11 interface and S5/S8
Bearer Context
0
modified
interface except on the S5/S8 interface for a UE triggered
Service Request.
When Handover Indication flag is set to 1 (i.e., for
EUTRAN Initial Attach or UE Requested PDN Connectivity
when the UE comes from non-3GPP access), the PGW
shall ignore this IE. See NOTE 1.
Several IEs with the same type and instance value may be
included as necessary to represent a list of Bearers to be
modified.
During a TAU/RAU/Handover procedure with an SGW
change, the SGW includes all bearers it received from the
MME/SGSN (Bearer Contexts to be created, or Bearer
Contexts to be modified and also Bearer Contexts to be
removed) into the list of 'Bearer Contexts to be modified'
IEs, which are then sent on the S5/S8 interface to the
PGW (see NOTE 2).
Bearer Contexts to be C This IE shall be included on the S4 and S11 interfaces for
Bearer Context
1
removed
the TAU/RAU/Handover and Service Request procedures
where any of the bearers existing before the
TAU/RAU/Handover procedure and Service Request
procedures will be deactivated as consequence of the
TAU/RAU/Handover procedure and Service Request
procedures. (NOTE 3)
instance value, shall be included.
Recovery
C This IE shall be included if contacting the peer for the first
Recovery
0
time
UE Time Zone
CO This IE shall be included by the MME/SGSN on the S11/S4 UE Time Zone
0
interfaces if the UE Time Zone has changed in the case of
TAU/RAU/Handover.
C If SGW receives this IE, SGW shall forward it to PGW
MME-FQ-CSID
C This IE shall be included by MME on S11 and shall be
FQ-CSID
0
forwarded by SGW on S5/S8 according to the
requirements in 3GPP TS 23.007 [17].
SGW-FQ-CSID
C This IE shall be included by SGW on S5/S8 according to
FQ-CSID
1
User CSG
CO The MME/SGSN shall include this IE for
UCI
0
Information (UCI)
TAU/RAU/Handover procedures and UE-initiated Service
Request procedure if the PGW has requested CSG Info
reporting and the MME/SGSN support the CSG
information reporting. The SGW shall include this IE on
S5/S8 if it receives the User CSG Information from
MME/SGSN.
MME/S4-SGSN LDN O This IE is optionally sent by the MME to the SGW on the
Local
0
S11 interface and by the SGSN to the SGW on the S4
Distinguished
interface (see 3GPP TS 32.423 [44]), when communicating
Name (LDN)
the LDN to the peer node for the first time.
SGW LDN
O This IE is optionally sent by the SGW to the PGW on the
Local
1
S5/S8 interfaces (see 3GPP TS 32.423 [44]), for interDistinguished
SGW mobity, when communicating the LDN to the peer
Name (LDN)
node for the first time.
Private Extension
O
NOTE1: This requirement is introduced for backwards compatibility reasons. If Bearer Contexts to be modified
IE(s) is received in the Modify Bearer Request message, the PGW shall include corresponding
Bearer Contexts modified IE(s) in the Modify Bearer Response message.
3GPP
Release 10
55
3GPP TS 29.274 V10.2.0 (2011-03)
NOTE2:
According to the description in 3GPP TS 23.401 [3] e.g. subclause 5.3.3.1 "Tracking Area Update
procedure with Serving GW change" and 3GPP TS 23.060 [35], during a TAU/RAU/Handover
procedure with an SGW change, if the SGW receives 'Bearer Context to be removed' IEs, the SGW
shall allocate the S5/8-U SGW F-TEID for those bearers and include also these bearers in the
'Bearer contexts to be modified' IE, which is then sent within this message on the S5/S8 interface to
the PGW.
NOTE3: The 'Bearer Contexts to be removed' IE signals to the SGW that these bearers will be removed by
the MME/SGSN later on by separate procedures (e.g. MME/S4-SGSN initiated Dedicated Bearer
Deactivation procedure). Therefore, the SGW will not delete these bearers during the ongoing
TAU/RAU/Handover procedure (without an SGW change), a Handover procedure (with an SGW
change except for an X2-Handover) and a Service Request procedure.
Table 7.2.7-2: Bearer Context to be modified within Modify Bearer Request

Octets 1
Octets 2 and 3
Octets 4
Information
elements
EPS Bearer ID
S1 eNodeB F-TEID
S5/8-U SGW F-TEID

S12 RNC F-TEID
S4-U SGSN F-TEID

Length = n
Condition / Comment
M
C This IE shall be sent on the S11 interface if the S1-U is
being used:
for an eUTRAN initial attach
-
a UE triggered Service Request
in all S1-U GTP-U tunnel setup procedure during a

TAU procedure (see 3GPP TS 24.301 [23])
/handover cases.
If an MME is aware that the eNodeB supports both IP

address types, the MME shall send both IP addresses
within an F-TEID IE. If only one IP address is included,
then the SGW shall assume that the eNodeB does not
support the other IP address type.
C This IE shall be sent on the S5/S8 interfaces for a
Handover or a TAU/RAU with a SGW change.
C If available, this IE shall be included if the message is sent
on the S4 interface if S12 interface is being used. If an S4SGSN is aware that the RNC supports both IP address
types, the S4-SGSN shall send both IP addresses within
an F-TEID IE. If only one IP address is included, then the
SGW shall assume that the RNC does not support the
other IP address type.
C If available, this IE shall be included if the message is sent
on the S4 interface, if S4-U is being used. If an S4-SGSN
supports both IP address types, the S4-SGSN shall send
both IP addresses within an F-TEID IE. If only one IP
address is included, then the SGW shall assume that the
S4-SGSN does not support the other IP address type.
IE Type
Ins.
EBI
F-TEID
0
0
F-TEID
F-TEID
F-TEID
Table 7.2.7-3: Bearer Context to be removed within Modify Bearer Request

Octets 1
Octets 2 and 3
Octets 4
Information
elements
EPS Bearer ID

Length = n
Condition / Comment
3GPP
IE Type
Ins.
EBI
Release 10
56
3GPP TS 29.274 V10.2.0 (2011-03)
7.2.8 Modify Bearer Response

The Modify Bearer Response message shall be sent on the S11 interface by the SGW to the MME and on the S5/S8
interfaces by the PGW to the SGW as part of the procedures:
-
E-UTRAN Tracking Area Update without SGW Change
UE triggered Service Request
S1-based Handover
It shall also be sent on the S4 interface by the SGW to the SGSN and on the S5/S8 interfaces by the PGW to the SGW
as part of the procedures:
-
Routeing Area Update with MME interaction and without SGW change
Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update to S4 SGSNs without
SGW change
Iu mode RA Update Procedure without SGW change
Serving RNS Relocation Procedure
Combined Hard Handover and SRNS Relocation Procedure
Combined Cell / URA Update and SRNS Relocation Procedure
Enhanced Serving RNS Relocation without SGW relocation
UE Initiated Service Request Procedure
Iu mode to A/Gb mode Intra SGSN Change
A/Gb mode to Iu mode Intra SGSN Change
Iu mode to A/Gb mode Inter-SGSN Change
A/Gb mode to Iu mode Inter-SGSN Change
Paging Response with no established user plane on S4
PDP Context Activation Procedure
on the S4 interface by the SGSN to the SGW as part of:

-
RAB Assignment Procedure
and on the S5/S8 interfaces by the PGW to the SGW as part of:
-
3GPP
Release 10
57
3GPP TS 29.274 V10.2.0 (2011-03)
X2 based handover with SGW relocation
Gn/Gp SGSN to MME Tracking Area Update
Enhanced Serving RNS Relocation with SGW relocation
Routeing Area Update with MME interaction and with SGW change
change
If handling of default bearer fails, then Cause at the message level shall be a failure cause.
-
"Request accepted".
3GPP
Release 10
58
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.8-1: Information Elements in a Modify Bearer Response
3GPP
Release 10
Information
elements
Cause
MSISDN
Aggregate Maximum
Bit Rate (APN-AMBR)
APN Restriction
Protocol
(PCO)
Bearer Contexts
modified
Bearer Contexts
marked for removal
Change Reporting
Action
CSG Information
Reporting Action
Charging Gateway
Name
Charging Gateway
Address
PGW-FQ-CSID
SGW-FQ-CSID
Recovery
SGW LDN
PGW LDN
59
P
3GPP TS 29.274 V10.2.0 (2011-03)
Condition / Comment
M
C This IE shall be included on S5/S8 interfaces by the PGW
if it is stored in its UE context and if this message is
triggered due to TAU/RAU/HO with SGW relocation.
C This IE shall be sent on S5/S8 when the UE moves from a
Gn/Gp SGSN to the S4 SGSN or MME to identify the
default bearer the PGW selects for the PDN Connection.
This IE shall also be sent by SGW on S11, S4 during
Gn/Gp SGSN to S4-SGSN/MME HO procedures to identify
the default bearer the PGW selects for the PDN
Connection.
C This IE shall be included in the PS mobility from Gn/Gp
SGSN to the S4 SGSN/MME procedures if the received
APN-AMBR has been modified by the PCRF.
C This IE denotes the restriction on the combination of types
Context. This IE shall be included over S5/S8 interfaces,
and shall be forwarded over S11/S4 interfaces during
Gn/Gp SGSN to MME/S4-SGSN handover procedures.
This IE shall also be included on S5/S8 interfaces during
the Gn/Gp SGSN to S4 SGSN/MME RAU/TAU
procedures.
The target MME or SGSN determines the Maximum APN
Restriction using the APN Restriction.
C If SGW receives this IE from PGW on GTP or PMIP based
S5/S8, the SGW shall forward PCO to MME/S4-SGSN
during Inter RAT handover from the UTRAN or from the
GERAN to the E-UTRAN. See NOTE 2.
modified that were sent in Modify Bearer Request
message. Several IEs with the same type and instance
value may be included as necessary to represent a list of
the Bearers which are modified.
removed sent in the Modify Bearer Request message.
Shall be included if request message contained Bearer
Contexts to be removed.
C This IE shall be included with the appropriate Action field If
the location Change Reporting mechanism is to be started
or stopped for this subscriber in the SGSN/MME.
CO This IE shall be included with the appropriate Action field if
the location CSG Info change reporting mechanism is to be
started or stopped for this subscriber in the SGSN/MME.
interface during SGW relocation and when the UE moves
from Gn/Gp SGSN to S4-SGSN/MME. See NOTE 1.
interface during SGW relocation and when the UE moves
from Gn/Gp SGSN to S4-SGSN/MME. See NOTE 1.
C This IE shall be included by PGW on S5/S8and shall be
forwarded by SGW on S11 according to the requirements
in 3GPP TS 23.007 [17].
C This IE shall be included by SGW on S11 according to the
time.
on the S11/S4 interfaces (see 3GPP TS 32.423 [44]), when
O This IE is optionally sent by the PGW to the SGW on the
S5/S8 interfaces (see 3GPP TS 32.423 [44]), when
3GPP
IE Type
Ins.
Cause
MSISDN
0
0
EBI
AMBR
APN Restriction
PCO
Bearer Context
Bearer Context
Change Reporting
Action
CSG Information
Reporting Action
FQDN
IP Address
FQ-CSID
FQ-CSID
Recovery
Local
Distinguished
Name (LDN)
Local
Distinguished
Name
0
1
Release 10
60
3GPP TS 29.274 V10.2.0 (2011-03)
(LDN)Name
Private Extension
O
NOTE 1: Both Charging Gateway Name and Charging Gateway Address shall not be included at the same
time. When both are available, the operator configures a preferred value.
NOTE 2: If MME receives the IE, but no NAS message is sent, MME discards the IE.
Table 7.2.8-2: Bearer Context modified within Modify Bearer Response

Octets 1
Octets 2 and 3
Octets 4
Information
elements
EPS Bearer ID
Cause
S1 SGW F-TEID
S12 SGW F-TEID
S4-U SGW F-TEID

Length = n
Condition / Comment
M
and if not, gives information on the reason.
C This IE shall be used on the S11 interface, if the S1
interface is used. See NOTE 1
C This IE shall be included on the S4 interface if the S12
interface is being used. See NOTE 1
C This IE shall be present if used on the S4 interface if the
S4-U interface is being used. See NOTE 1
C This IE shall be present on the S5/S8 interface if this
message is triggered due to one of the following
procedures:
TAU/RAU/HO with SGW relocation
-
IE Type
Ins.
EBI
Cause
0
0
F-TEID
F-TEID
F-TEID
TAU/RAU/HO from Gn/Gp SGSN to MME/S4SGSN
Charging ID
Charging ID
0
O If S5/S8 interface is GTP, this IE may be sent on the S4
interface, in order to support CAMEL charging at the
SGSN, for the following procedures:
inter-SGSN RAU/Handover/SRNS Relocation
without SGW change.
inter-SGSN Handover/SRNS Relocation with SGW
change.
Bearer Flags
CO Applicable flags are:
Bearer Flags
0
PPC (Prohibit Payload Compression): This flag
shall be sent on the S5/S8 and the S4 interfaces at
S4-SGSN relocation.
NOTE 1: The SGW shall not change its F-TEID for a given interface during the Handover, Service Request, EUTRAN Initial Attach, UE Requested PDN connectivity and PDP Context Activation procedures. The
SGW F-TEID shall be same for S1-U, S4-U and S12.
During Handover and Service Request the target eNodeB/RNC/SGSN may use a different IP type
than the one used by the source eNodeB/RNC/SGSN. In order to support such a scenario, the SGW
F-TEID should contain both an IPv4 address and an IPv6 address (see also subclause 8.22 "FTEID").
Table 7.2.8-3: Bearer Context marked for removal within Modify Bearer Response
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Cause

Length = n
Condition / Comment
M
3GPP
IE Type
Ins.
EBI
Cause
0
0
Release 10
61
3GPP TS 29.274 V10.2.0 (2011-03)
7.2.9 Delete Session Request and Delete Bearer Request

7.2.9.1
The direction of this message shall be from MME/S4-SGSN to SGW, from SGW to PGW and from ePDG to PGW (see
Table 6.1-1).
A Delete Session Request message shall be sent on the S11 interface by the MME to the SGW and on the S5/S8
interface by the SGW to the PGW as part of the procedures:
-
EUTRAN Initial Attach
UE, HSS or MME Initiated Detach
UE or MME Requested PDN Disconnection
It shall also be sent on the S4 interface by the SGSN to the SGW, and on the S5/S8 interface by the SGW to the PGW as
part of
-
MS, HLR or SGSN initiated detach procedure
Combined GPRS/IMSI Attach
MS and SGSN Initiated PDN connection Deactivation Procedure using S4
On the S11 interface by the MME to the SGW as part of the procedures:
-
Tracking Area Update with SGW Change
S1 Based Handover with SGW Change
X2 Based Handover with SGW Relocation
Inter RAT handover cancel with SGW change
MME to 3G Gn/Gp SGSN combined hard handover and SRNS relocation procedure
MME to SGSN Routing Area Update
E-UTRAN to Gn/Gp SGSN Inter RAT handover
S1 Based handover cancel with SGW change
Optimised Active Handover: E-UTRAN Access to CDMA2000 HRPD Access
And on the S4 interface by the SGSN to the SGW as part of

-
Enhanced Serving RNS Relocation with SGW relocation using S4
Routing Area Update with SGW change
SGSN to MME Tracking Area Update with SGW change
SRNS Relocation Cancel Procedure Using S4
Inter RAT with SGW change handover cancel
Serving RNS relocation with SGW change
3GPP
Release 10
62
S4 SGSN to Gn/Gp SGSN Routeing Area Update
S4 SGSN to Gn/Gp SGSN Serving RNS Relocation Procedures
S4 SGSN to Gn/Gp SGSN PS handover Procedures
3GPP TS 29.274 V10.2.0 (2011-03)
The message shall also be sent on the S2b interface by the ePDG to the PGW as part of procedures:
-
UE/ePDG Initiated Detach with GTP on S2b
UE Requested PDN Disconnection with GTP on S2b
HSS/AAA Initiated Detach with GTP on S2b
This message may also be sent on S5/S8 interface by the SGW to the PGW:
-
If Downlink Data Notification Acknowledge message with Context not found cause value is received.
If there are any procedure collisions, the Delete Session Request shall have precedence over any other Tunnel
Management message.
During the handover procedure the Delete Session Request message shall not release the indirect data forwarding
tunnels.
Possible Cause values are:
-
"ISR deactivation ".
Table 7.2.9.1-1 specifies the presence of the IEs in the message.
3GPP
Release 10
63
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.9.1-1: Information Elements in a Delete Session Request
3GPP
Release 10
Information
elements
Cause
64
P
3GPP TS 29.274 V10.2.0 (2011-03)
Condition / Comment
C If ISR is being de-activated, the Cause IE shall be included

on the S4/S11 interface and its value shall indicate that the
SGW shall delete the bearer resources by sending Delete
Bearer Request to the MME/SGSN on which ISR was
activated with Cause value "ISR deactivation".
Linked EPS Bearer ID C This IE shall be included on the S4/S11, S5/S8 and S2b
(LBI)
interfaces to indicate the default bearer associated with the
PDN being disconnected unless in the handover/TAU/RAU
with SGW relocation procedures.
User Location
Information (ULI)
Indication Flags
C The MME/SGSN shall include this IE on the S4/S11

interface for the Detach procedure if the PGW has
requested location information change reporting and
MME/SGSN support location information change reporting.
ULI from MME/SGSN.
CO The MME shall include this IE on the S4/S11 interface for
the UE or MME Requested PDN Disconnection procedure
if the PGW has requested location information change
reporting and the MME support location information
change reporting.
ULI from the MME.
is set to 1.
Applicable flags:
Operation Indication: This flag shall be set over
S4/S11 interface if the SGW needs to forward the
Delete Session Request message to the PGW.
This flag shall not be set if the ISR associated GTP
entity sends this message to the SGW in the
Detach procedure. This flag shall also not be set to
1 in the SRNS Relocation Cancel Using S4
(6.9.2.2.4a in 3GPP TS 23.060 [4]), Inter RAT
handover Cancel procedure with SGW change
TAU with Serving GW change, Gn/Gb based RAU
(see 5.5.2.5, 5.3.3.1, D.3.5 in 3GPP TS 23.401 [3],
respectively), S1 Based handover Cancel
procedure with SGW change.
-
IE Type
Ins.
Cause
EBI
ULI
Indication
PCO
Node Type
Scope Indication: if request corresponds to

TAU/RAU/Handover/SRNS Relocation Cancel
Using S4, Inter RAT handover Cancel procedure
with SGW change, S1 Based handover Cancel
procedure with SGW change, then this bit shall be
set on the S4/S11 interface.
See NOTE 1.
Protocol
C If the UE includes the PCO IE, then the MME/SGSN shall
copy the content of this IE transparently from the PCO IE
(PCO)
included by the UE.
If SGW receives the PCO IE, SGW shall forward it to
PGW.
Originating Node
C This IE shall be included on the S4/S11 interface if the ISR
associated GTP entities send this message to the SGW in
Detach procedure to denote the type of the node
originating the message. If this IE is included in the Delete
Session Request message, the SGW in ISR activated
state deactivates ISR after receiving the first Delete
Session Request message from the MME/SGSN, releases
the Originating Node related EPS Bearer contexts
information in the PDN Connection identified by the LBI.
The SGW shall forward the Delete Session Request
message to the PGW after receiving both of the messages
sent from the MME and the SGSN for the same PDN
Connection.
3GPP
Release 10
65
3GPP TS 29.274 V10.2.0 (2011-03)
CO This IE shall be included on the S4/S11 interface if the ISR

associated GTP entity sends this message to the SGW in
TAU/RAU/HO with SGW change procedure to denote the
type of the node originating the message.
Sender F-TEID for
O This IE may be included on the S4/S11 interfaces.
F-TEID
0
Control Plane
If the Sender F-TEID for Control Plane is received by the
SGW, the SGW shall only accept the Delete Session
Request message when the Sender F-TEID for Control
Plane in this message is the same as the Sender F-TEID
for Control Plane that was last received in either the Create
Session Request message or the Modify Bearer Request
message on the given interface.
If the ISR is activated, two F-TEIDs exist: one for the MME
and the other for the SGSN. See NOTE 2.
UE Time Zone
CO This IE shall be included by the MME on the S11 interface
UE Time Zone
0
or by the SGSN on the S4 interface, if the UE Time Zone
has changed.
MME/SGSN, and if the Operation Indication bit received
from the MME/SGSN is set to 1.
Private Extension
interfaces.
NOTE 1: For the Indication Flags, the combination (Operation Indication, Scope Indication) = 1,1 shall be
considered an error if received.
NOTE 2: Following an inter RAT TAU/RAU failure, the target MME/SGSN may mistakenly initiate the implicit
detach procedure while the UE is managed by the other MME/SGSN. In this case, the SGW will
reject the Delete Session Request message with the cause "Invalid peer".
7.2.9.2
The direction of this message shall be from PGW to SGW, from SGW to MME/S4-SGSN and from PGW to ePDG (see
Table 6.1-1).
A Delete Bearer Request message shall be sent on the S5/S8 and S4/S11 interfaces as part of the following procedures:
-
PGW or MME initiated bearer deactivation procedures,
UE requested Bearer Resource Modification,
MS and SGSN Initiated Bearer Deactivation procedure using S4 or
PGW initiated bearer deactivation procedure using S4.
In the above cases, this Request is sent by the PGW to the SGW and shall be forwarded to the MME or S4-SGSN.
The message shall also be sent on the S4/S11 interface by the SGW to the SGSN/MME to delete the bearer resources on
the other ISR associated CN node if the ISRAI flag is not set in the Modify Bearer Request message.
The message shall also be sent on the S4/S11 interface by the SGW to the SGSN/MME to delete the bearer resources on
the other ISR associated CN node in the TAU/RAU/Handover procedures if the ISR related Cause IE is included in the
Delete Session Request message.
The message shall also be sent on the S2b interface by the PGW to the ePDG as part of PGW Initiated Bearer Resource
Allocation Deactivation procedure with GTP on S2b.
The message may also be sent on the S11/S4 interface by the SGW to the MME/S4 SGSN when the SGW receives the
Error Indication from PGW for the default bearer as specified in 3GPP TS 23.007 [17].
-
"RAT changed from 3GPP to Non-3GPP",
"ISR deactivation",
3GPP
Release 10
"Access changed from Non-3GPP to 3GPP",
"Reactivation requested",
"PDN reconnection to this APN disallowed".
66
Table 7.2.9.2-1 specifies the presence of IEs in this message.
3GPP
3GPP TS 29.274 V10.2.0 (2011-03)
Release 10
67
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.9.2-1: Information Elements in a Delete Bearer Request

Information
P
Condition / Comment
IE Type
Ins.
elements
Linked EPS Bearer ID C If the request corresponds to the bearer deactivation
EBI
0
(LBI)
procedure in case all bearers belonging to a PDN
connection shall be released, then this IE shall be included
on the S5/S8, S4/S11 and S2b interfaces to indicate the
default bearer associated with the PDN being
disconnected.
This IE shall be included only when the EPS Bearer ID is
not present in the message.
CO During a TAU/RAU/HO, if the Cause value is set to "ISR
deactivation", an SGW shall send all LBIs for a given UE
with the message on S4/S11 interface. All LBI IEs shall
have the same type and instance value to represent a list
of IEs (see NOTE 1).
EPS Bearer IDs
C This IE shall be used on S5/S8, S4/S11 and S2b interfaces
EBI
1
for bearers different from the default one, i.e., for dedicated
bearers. In this case at least one dedicated bearer shall be
included.
Several IEs with this type and instance values shall be
Failed Bearer
O This IE may be included on the S5/S8 and S11 interfaces if Bearer Context
0
Contexts
the request corresponds to MME initiated bearer
deactivation procedure. This IE shall contain the list of
failed bearers if partial Bearer Contexts included in the
Delete Bearer Command message could not be deleted.
Procedure
C If the request corresponds to UE requested bearer
PTI
0
resource modification procedure for an E-UTRAN, this IE
shall be included on the S5/S8 and S11 interfaces.
Protocol
C PGW shall include Protocol Configuration Options (PCO)
PCO
0
IE on the S5/S8 interface, if available.
(PCO)
If SGW receives this IE, SGW shall forward it to
SGSN/MME on the S4/S11 interface.
PGW-FQ-CSID
FQ-CSID
0
S2b interfaces, and when received from S5/S8 be
SGW-FQ-CSID
FQ-CSID
1
Cause
C This IE shall be sent on S11/S4 and S5/S8 interfaces if the
Cause
0
message is caused by a handover without optimization
occuring from 3GPP to non-3GPP. In this case the Cause
value shall be set to "RAT changed from 3GPP to Non3GPP".
This IE shall also be sent on S11/S4 interfaces when the
SGW requests to delete all bearer contexts for the given
UE in an MME or S4-SGSN due to ISR deactivation, and
the Cause value shall be set to "ISR deactivation".".
This IE shall be sent on the S2b interface if the message is
caused by handover from non-3GPP to 3GPP. In this case
the Cause value shall be set to "Access changed from
Non-3GPP to 3GPP".
O This IE may be sent by a PGW on S5/S8 during PGW
initiated PDN connection deactivation procedures with
values of "Reactivation requested" or " PDN reconnection
to this APN disallowed " (see section 8.4 for details).
CO The IE shall be relayed by the SGW to the MME/S4-SGSN
if received from the PGW.
Private Extension
interfaces.
NOTE 1: If the SGW has sent multiple LBIs to MME/SGSN, but have received only one LBI within the Delete
Bearer Response message, this indicates that the MME/SGSN is pre Rel-10. In such case, the SGW
shall send separate individual Delete Bearer Request message(s) for each of remaining LBIs.
3GPP
Release 10
NOTE:
68
3GPP TS 29.274 V10.2.0 (2011-03)
for an E-UTRAN, then there will be only one instance of the EPS Bearer IDs IE in the Delete Bearer
Request.
Table 7.2.9.2-2: Bearer Context within Delete Bearer Request
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Cause

Length = n
Condition / Comment
IE Type
Ins.
EBI
Cause
0
0
PCO
M
M This IE shall indicate the reason of the unsuccessful
handling of the bearer.
Protocol
CO PGW shall include Protocol Configuration Options (PCO)
IE on the S5/S8 interface, if available. This bearer level IE
(PCO)
takes precedence over the PCO IE in the message body if
they both exist.
7.2.10 Delete Session Response and Delete Bearer Response

7.2.10.1
Delete Session Response
A Delete Session Response message shall be sent on the S11 interface by the SGW to the MME and on the S5/S8
interface by the PGW to the SGW as part of the following procedures:
-
EUTRAN Initial Attach
UE, HSS or MME Initiated Detach
UE or MME Requested PDN Disconnection
It shall also be sent on the S4 interface by the SGW to the SGSN and on the S5/S8 interface by the PGW to the SGW as
part of the procedures:
-
MS, HLR or SGSN initiated detach procedure
Combined GPRS/IMSI Attach
MS and SGSN Initiated Default Bearer Deactivation Procedure using S4
On the S11 interface by the SGW to the MME as part of the procedures:
-
Tracking Area Update with SGW Change
S1 Based Handover with SGW Change
X2 Based Handover with SGW Relocation
Inter RAT handover cancel with SGW change
MME to 3G Gn/Gp SGSN combined hard handover and SRNS relocation procedure
MME to SGSN Routing Area Update
E-UTRAN to Gn/Gp SGSN Inter RAT handover
S1 Based handover cancel with SGW change
3GPP
Release 10
69
3GPP TS 29.274 V10.2.0 (2011-03)
And on the S4 interface by the SGW to the SGSN as part of the procedures:
-
Enhanced Serving RNS Relocation with SGW relocation using S4
Routing Area Update with SGW change
SGSN to MME Tracking Area Update with SGW change
Serving RNS relocation with SGW change
S4 SGSN to Gn/Gp SGSN Routeing Area Update
S4 SGSN to Gn/Gp SGSN Serving RNS Relocation Procedures
S4 SGSN to Gn/Gp SGSN PS handover Procedures
The message shall also be sent on the S2b interface by the PGW to the ePDG as part of procedures:
-
UE/ePDG Initiated Detach with GTP on S2b
UE Requested PDN Disconnection with GTP on S2b
HSS/AAA Initiated Detach with GTP on S2b
This message may also be sent on S5/S8 interface by the SGW to the PGW:
-
If Downlink Data Notification Acknowledge message with Context not found cause value is received.
The sending entity shall include Cause IE in the Delete Session Response message. The IE indicates if the peer has
deleted the bearer, or not.
-
"Invalid peer".

Table 7.2.10.1-1: Information Elements in a Delete Session Response
Information
elements
Cause
Recovery
Condition / Comment
M
Protocol
(PCO)
Private Extension
interfaces.
7.2.10.2
The Delete Bearer Response shall be sent as a response of Delete Bearer Request.
-
"Request accepted".
3GPP
IE Type
Ins.
Cause
Recovery
0
0
PCO
Private Extension
VS
Release 10
70
3GPP TS 29.274 V10.2.0 (2011-03)

Table 7.2.10.2-1: Information Elements in Delete Bearer Response
Information
P
Condition / Comment
elements
Cause
M
Linked EPS Bearer ID C If the response corresponds to the bearer deactivation
(LBI)
procedure in case all the bearers associated with the
default bearer of a PDN connection shall be released, this
IE shall be included on the S4/S11, S5/S8 and S2b
interfaces to indicate the default bearer associated with the
PDN being disconnected.
CO During a TAU/RAU/HO, if an MME/SGSN has received a
Delete Bearer Request message with Cause value "ISR
deactivation" and multiple LBIs, the MME/SGSN shall
include all these LBIs in the response message on S4/S11
interface. All LBI IEs shall have the same type and
instance value to represent a list of IEs.
Bearer Contexts
C It shall be used on the S4/S11, S5/S8 and S2b interfaces
for bearers different from default one. In this case at least
one bearer shall be included.
Used for dedicated bearers. When used, at least one
dedicated bearer shall be present.
Recovery
MME-FQ-CSID
C This IE shall be included by MME the on S11 interface and
shall be forwarded by the SGW on S5/S8 interface
SGW-FQ-CSID
C This IE shall be included by the SGW on the S5/S8
interface according to the requirements in 3GPP TS
23.007 [17].
ePDG-FQ-CSID
Protocol
CO An MME/SGSN shall include the PCO IE if such
information was received from the UE.
(PCO)
If the SGW receives this IE, the SGW shall forward it to
PGW on the S5/S8 interface.
UE Time Zone
User Location
Information (ULI)
Private Extension
IE Type
Ins.
Cause
EBI
0
0
Bearer Context
Recovery
FQ-CSID
FQ-CSID
FQ-CSID
PCO

MME/SGSN.
ULI
MME/SGSN.
Private Extension
interfaces.
3GPP
0
VS
Release 10
71
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.10.2-2: Bearer Context within Delete Bearer Response

Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Cause

Length = n
Condition / Comment
M
Protocol
information was received from the UE. This bearer level IE
(PCO)
they both exist.
IE Type
Ins.
EBI
Cause
0
0
PCO
7.2.11 Downlink Data Notification messages

7.2.11.1
A Downlink Data Notification message shall be sent:

-
on the S11 interface by the SGW to the MME as a part of the network triggered service request procedure;
on the S4 interface by the SGW to the SGSN as part of Paging with no established user plane on S4, SGW
triggered paging with S4;
on S11/S4 interface by SGW to MME/S4-SGSN if the SGW has received an Error Indication (see 3GPP TS
29.281 [13]) from eNodeB/RNC across S1-U/S12 interface. Respective SGW and MME/S4-SGSN functionality
is specified in 3GPP TS 23.007 [17].
on the S11/S4 interface by SGW to the MME/S4-SGSN as part of the network triggered service restoration
procedure if both the SGW and the MME/S4-SGSN support this optional feature (see 3GPP TS 23.007 [17]).
3GPP
Release 10
72
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.11.1-1: Information Elements in a Downlink Data Notification

Information
elements
Cause
EPS Bearer ID
Condition / Comment
O If SGW receives an Error Indication from eNodeB/RNC,

the SGW may send the Cause IE with value "Error
Indication received from RNC/eNodeB" to MME/S4-SGSN
as specified in 3GPP TS 23.007 [17].
CO This IE shall be included on the S11 and S4 interfaces and
shall be set as follows:
If the Downlink Data Notification is triggered by
the arrival of downlink data packets at the SGW,
the SGW shall include the EPS Bearer ID stored
in the EPS bearer context of the bearer on which
the downlink data packet was received;
the receipt of an Error Indication from the eNodeB
or RNC, the SGW shall include the EPS Bearer
ID stored in the EPS bearer context of the bearer
for which the Error Indication was received;
the arrival of control plane signalling, the SGW
shall include the EPS Bearer ID present in the
control plane signalling.
(See 3GPP TS 23.401[3], section 5.3.4.3).
IE Type
Ins.
Cause
EBI
More than one IE with this type and instance values may
be included to represent multiple bearers having received
downlink data packets or being signalled in the received
control plane message.
See NOTE 1.
Allocation/Retention CO This IE shall be included on the S11 and S4 interfaces and
ARP
Priority
shall be set as follows:
the arrival of downlink data packets at the SGW,
the SGW shall include the ARP stored in the EPS
bearer context of the bearer on which the
downlink data packet was received;
the receipt of an Error Indication from the eNodeB
or RNC, the SGW shall include the ARP stored in
the EPS bearer context of the bearer for which
the Error Indication was received.
the arrival of control plane signalling, the SGW
shall include the ARP if present in the control
plane signalling. If the ARP is not present in the
control plane signalling, the SGW shall include
the ARP in the stored EPS bearer context.
(See 3GPP TS 23.401[3], section 5.3.4.3).
If multiple EPS Bearers IDs are reported in the message,
the SGW shall include the ARP associated with the bearer
with the highest priority (i.e. the lowest ARP value).
See NOTE 1.
IMSI
CO This IE shall be included on the S11/S4 interface as part of
IMSI
the network triggered service restoration procedure if both
the SGW and the MME/S4-SGSN support this optional
feature (see 3GPP TS 23.007 [17]).
Private Extension
O
Private Extension
NOTE 1: The usage of this parameter at the S4-SGSN is not specified in this release.
7.2.11.2
VS
Downlink Data Notification Acknowledge
A Downlink Data Notification Acknowledge shall be sent from a MME/SGSN to a SGW in response to Downlink Data
Notification with an indication of success, or failure when MME/SGSN has reachability or abnormal conditions.
3GPP
Release 10
73
3GPP TS 29.274 V10.2.0 (2011-03)
-
"UE already re-attached".

Table 7.2.11.2-1: Information Elements in a Downlink Data Notification Acknowledge
Information
elements
Cause
Data Notification
Delay
Recovery
DL low priority traffic
Throttling
Condition / Comment
M
C The MME/SGSN shall include an adaptive delay indication
to the SGW to delay the number of Data Notification
indications, if the rate of Downlink Data Notification event
occurrence in the MME/SGSN becomes significant (as
configured by the operator) and the MME/SGSN's load
exceeds an operator configured value.
time
O The MME/SGSN may send this IE to the SGW to request
the SGW to reduce the number of Downlink Data
Notification requests it sends for downlink low priority traffic
received for UEs in idle mode served by that MME/SGSN
in proportion to the Throttling Factor and during the
Throttling Delay.
IE Type
Ins.
Cause
Delay Value
0
0
Recovery
Throttling
See NOTE 1, NOTE 2, NOTE 3.

CO 3GPP TS 23.007 [17] specifies conditions for sending this
IMSI
0
IE on the S11/S4 interface as part of the network triggered
service restoration procedure, if both the SGW and the
MME/S4-SGSN support this optional feature.
Private Extension
O
NOTE 1: The last received value of the Throttling Factor and Throttling Delay shall supersede any previous
values received from that MME/SGSN. The reception of a Throttling Delay shall restart the SGW
timer associated with that MME/SGSN. The SGW shall determine whether a bearer is for low priority
traffic or not on the basis of the bearer's ARP priority level and operator policy (i.e. operator's
configuration in the SGW of the ARP priority levels to be considered as prioritary or non-prioritary
traffic).
NOTE 2: For instance, if the DL low priority traffic Throttling IE indicates a Throttling Factor of 40% and a
Throttling Delay of 180 seconds, the SGW drops by 40% the number of Downlink Data Notification
requests it sends for downlink low priority traffic received for UEs in idle mode served by that
MME/SGSN, during a period of 180 seconds.
NOTE 3: The DL low priority traffic Throttling IE may be present whatever the value of the Cause IE.
IMSI
7.2.11.3
Downlink Data Notification Failure Indication
A Downlink Data Notification Failure indication shall be sent from an MME/SGSN to a SGW indicating that the UE
did not respond to paging. It shall also be sent in the case that the UE responded to the page with a Service Request but
that the MME has rejected the request by sending a Service Reject to the UE. It may happen, for example, because the
requested service is not supported or there is a bearer context mismatch.
This message should not be used after an MME/SGSN successfully receives the Service Request message from the UE
in the Network Triggered Service Request procedure as defined in the 3GPP TS 23.401 [3].
NOTE:
Either the Modify Bearer Request message or the Delete Bearer Command message is used by the
MME/SGSN to indicate a possible failure case after an MME/SGSN successfully receives the Service
Request message from the UE.
3GPP
Release 10
74
"Service denied".
"UE already re-attached".
3GPP TS 29.274 V10.2.0 (2011-03)

Table 7.2.11.3-1: Information Elements in a Downlink Data Notification Failure Indication
Information
elements
Cause
Originating Node
IMSI
Private Extension
Condition / Comment
IE Type
Ins.
M
Cause
CO This IE shall be included on the S4/S11 interface if the ISR
Node Type
associated GTP entities i.e. MME, S4-SGSN, send this
message to the SGW during the Network Triggered
Service Request procedure to denote the type of the node
originating the message.
CO 3GPP TS 23.007 [17] specifies conditions for sending this
IMSI
IE on the S11/S4 interface as part of the network triggered
service restoration procedure, if both the SGW and the
MME/S4-SGSN support this optional feature.
O
Private Extension
0
0
VS
7.2.12 Delete Indirect Data Forwarding Tunnel Request

The Delete Indirect Data Forwarding Tunnel Request message is sent on the S4/S11 interface by the SGSN/MME to the
SGW to delete the Indirect Forwarding Tunnels in the Source SGW/Target SGW as part of the following procedures:
-
S1-based handover
MME to 3G SGSN combined hard handover and SRNS relocation procedure
Inter RAT handover Cancel
S1-based handover Cancel

Table 7.2.12-1: Information Element in Delete Indirect Data Forwarding Tunnel Request
Information
elements
Private Extension
Condition / Comment
O Vendor or operator specific information
IE Type
Ins.
Private Extension
VS
7.2.13 Delete Indirect Data Forwarding Tunnel Response

The Delete Indirect Data Forwarding Tunnel Response message is sent on the S4/S11 interface by the SGW to the
SGSN/MME as part of the following procedures:
-
S1-based handover
3GPP
Release 10
75
3GPP TS 29.274 V10.2.0 (2011-03)
MME to 3G SGSN combined hard handover and SRNS relocation procedure
Inter RAT handover Cancel
S1-based handover Cancel
-
"Request accepted".
"Request accepted partially"

Table 7.2.13-1: Information Element in Delete Indirect Data Forwarding Tunnel Response
Information
elements
Cause
Recovery
Private Extension
Condition / Comment
M This IE shall indicate if the deletion of indirect tunnel is

successful, and if not, gives information on the reason.
time.
O
IE Type
Ins.
Cause
Recovery
Private Extension
VS
7.2.14 Modify Bearer Command and Failure Indication

7.2.14.1
Modify Bearer Command
The Modify Bearer Command shall be sent on the S11 interface by the MME to the SGW and on the S5/S8 interface by
the SGW to the PGW as part of the HSS Initiated Subscribed QoS Modification procedure or SQCI flag is set to 1 in the
Context Response message.
It shall also be sent on the S4 interface by the SGSN to the SGW and on the S5/S8 interface by the SGW to the PGW as
part of the HSS Initiated subscribed QoS modification procedure or SQCI flag is set to 1 in the Context Response
message.
It shall also be sent on the S2b interface by the ePDG to the PGW as part of the HSS Initiated Subscribed QoS
Modification procedure.
Table 7.2.14.1-1: Information Elements in a Modify Bearer Command
Information
elements
APN-Aggregate
Maximum Bit Rate
(APN-AMBR)
Bearer Context
Private Extension
Condition / Comment
M This IE shall contain the APN-AMBR value received by the

MME/SGSN/ePDG from the HSS.
M Only one IE with this type and instance value shall be
included and this shall represent the Default Bearer.
interfaces.
3GPP
IE Type
Ins.
AMBR
Bearer Context
Private Extension
VS
Release 10
76
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.14.1-2: Bearer Context within Modify Bearer Command

Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Bearer Level QoS
7.2.14.2

Length = n
Condition / Comment
M This IE shall contain the default bearer ID.

C Mandatory if other parameters than the APN-AMBR have
been changed
CO This IE shall also be included when QCI and ARP have not
been changed and if the SQCI flag is set to 1 in the
Context Response message.
IE Type
Ins.
EBI
Bearer QoS
0
0
Modify Bearer Failure Indication
The Modify Bearer Failure Indication shall be sent on the S5/S8 interface by the PGW to the SGW and on the S11
interface by the SGW to the MME as part of failure of HSS Initiated Subscribed QoS Modification procedure.
It shall also be sent on the S5/S8 interface by the PGW to the SGW and on the S4 interface by the SGW to the SGSN as
part of failure of HSS Initiated subscribed QoS modification.
It shall also be sent on the S2b interface by the PGW to the ePDG as part of failure of HSS Initiated Subscribed QoS
Modification procedure.
Cause IE indicates that an EPS bearer has not been updated in the PGW.
-
"Context not found"
"Service denied".
Table 7.2.14.2-1: Information Elements in a Modify Bearer Failure Indication
Information
elements
Cause
Recovery
Private Extension
Condition / Comment
M
interfaces.
IE Type
Ins.
Cause
Recovery
0
0
Private Extension
VS
7.2.15 Update Bearer Request

The direction of this message shall be from PGW to SGW and/or from SGW to MME/S4-SGSN, and/or from PGW to
ePDG (see Table 6.1-1).
For GTP based S5/S8, the Update Bearer Request shall be sent by the PGW to the SGW and forwarded to the MME as
part of the following procedures:
-
PGW Initiated Bearer Modification with Bearer QoS Update
HSS Initiated Subscribed QoS Modification
PGW Initiated Bearer Modification without Bearer QoS Update
UE Request Bearer Resource Modification procedure
the SGSN as part of the following procedures:
-
PGW Initiated EPS Bearer Modification
3GPP
Release 10
77
Execution part of MS-Initiated EPS Bearer Modification
SGSN-Initiated EPS Bearer Modification Procedure using S4
3GPP TS 29.274 V10.2.0 (2011-03)
and on the S2b interface by the PGW to the ePDG as part of the following procedures:
-
PGW Initiated Bearer Modification
HSS Initiated Subscribed QoS Modification
For PMIP based S5/S8, the Update Bearer Request shall be sent on the S11 interface by the SGW to the MME and on
the S4 interface by the SGW to the SGSN.
Table 7.2.15-1 specifies the presence requirements and the conditions of the IEs in the message.
Table 7.2.15-1: Information Elements in an Update Bearer Request
Information
elements
Bearer Contexts
Condition / Comment
M This IE shall contain contexts related to bearers that need

QoS/TFT modification. Several IEs with this type and
instance values shall be included as necessary to
represent a list of Bearers.
If there is no QoS/TFT modification, only one IE with this
type and instance value shall be included.
Procedure
C If the request corresponds to UE requested bearer
resource modification procedure for an E-UTRAN or MS
initiated EPS bearer modification procedure, this IE shall
be included.
PTI shall be the same as the one used in the
corresponding Bearer Resource Command
Protocol
(PCO)
Aggregate Maximum M APN-AMBR
Bit Rate (APN-AMBR)
Change Reporting
Action
interfaces with the appropriate Action field If the location
CSG Information
Reporting Action
PGW-FQ-CSID
C This IE shall be included by PGW on the S5/S8 and S2b
interfaces, and when received from S5/S8 be forwarded
by SGW on S11 according to the requirements in 3GPP TS
23.007 [17].
SGW-FQ-CSID
Private Extension
interfaces.
NOTE:
IE Type
Ins.
Bearer Context
PTI
PCO
AMBR
Change Reporting
Action
CSG Information
Reporting Action
FQ-CSID
FQ-CSID
Private Extension
VS
for an E-UTRAN or MS initiated EPS bearer modification procedure, then there will be only one instance
of the Bearer Contexts IE in the Update Bearer Request.
3GPP
Release 10
78
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.15-2: Bearer Context within Update Bearer Request

Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
TFT

Length = n
Condition / Comment
M
interfaces if message relates to Bearer Modification and
TFT change.
Bearer Level QoS
interfaces if QoS modification is requested
Bearer Flags
O Applicable flags:
PPC (Prohibit Payload Compression): this flag may be set
on the S5/S8 and S4/S11 interfaces.
Protocol
CO PGW shall include Protocol Configuration Options (PCO)
IE on the S5/S8 interface, if available. This bearer level IE
(PCO)
they both exist. If SGW receives this IE, SGW shall forward
it to SGSN/MME on the S4/S11 interface.
IE Type
Ins.
EBI
Bearer TFT
0
0
Bearer QoS
Bearer Flags
PCO
7.2.16 Update Bearer Response

An Update Bearer Response shall be sent from a MME/SGSN to a SGW and forwarded to the PGW as a response to an
Update Bearer Request message.
Cause IE indicates if an EPS bearer has been modified in the MME/SGSN or not. The EPS Bearer has not been
modified in the MME if the Cause IE value differs from "Request accepted" or "Request accepted partially". Possible
Cause values are specified in Table 8.4-1. Message specific cause values are:
-
"Request accepted".
"Request accepted partially"
"Context not found"
"Denied in RAT".
"UE refuses".
3GPP
Release 10
79
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.16-1: Information Elements in an Update Bearer Response

Information
elements
Cause
Bearer Contexts
Condition / Comment
M
M This IE shall contain contexts related to bearers for which
QoS/TFT modification was requested. Several IEs with this
type and instance values shall be included as necessary to
represent a list of Bearers
Protocol
information was received from the UE.
(PCO)
If the SGW receives this IE, the SGW shall forward it to
PGW on the S5/S8 interface.
Recovery
MME-FQ-CSID
SGW-FQ-CSID
ePDG-FQ-CSID
Indication Flags
UE Time Zone
User Location
Information (ULI)
Private Extension
IE Type
Ins.
Cause
Bearer Context
0
0
PCO

Recovery
C This IE shall be included by MME on S11and shall be
FQ-CSID
forwarded by SGW on S5/S8 according to the
FQ-CSID
FQ-CSID
Indication
is set to 1.
Applicable flags:
Direct Tunnel Flag: this flag may be included on the S4
interface if the Direct Tunnel is used.
MME/SGSN.
ULI
MME/SGSN.
Private Extension
interfaces.
0
0
1
2
0
0
VS
Table 7.2.16-2: Bearer Context within Update Bearer Response

Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Cause

Length = n
Condition / Comment
M
M This IE Indicates if the bearer handling was successful,
S4-U SGSN F-TEID
tunnel is not established.
S12 RNC F-TEID
tunnel flag is set to 1.
Protocol
information was received from the UE. This bearer level IE
(PCO)
they both exist.
3GPP
IE Type
Ins.
EBI
Cause
0
0
F-TEID
F-TEID
PCO
Release 10
80
3GPP TS 29.274 V10.2.0 (2011-03)
7.2.17 Delete Bearer Command and Failure Indication

7.2.17.1
Delete Bearer Command
A Delete Bearer Command message shall be sent on the S11 interface by the MME to the SGW and on the S5/S8
interface by the SGW to the PGW as a part of the eNodeB requested bearer release or MME-Initiated Dedicated Bearer
Deactivation procedure.
The message shall also be sent on the S4 interface by the SGSN to the SGW and on the S5/S8 interface by the SGW to
the PGW as part of the MS and SGSN Initiated Bearer Deactivation procedure using S4.
Table 7.2.17.1-1: Information Elements in Delete Bearer Command
Information
elements
Bearer Contexts
Private Extension
Condition / Comment
M This IE shall be used to indicate dedicated bearers. When

used, at least one dedicated bearer shall be present.
included as necessary to represent a list of Bearers
O
IE Type
Ins.
Bearer Context
Private Extension
VS
Table 7.2.17.1-2: Bearer Context within Delete Bearer Command

Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Bearer Flags
7.2.17.2

Length = n
Condition / Comment
M
CO Applicable flags are:
VB (Voice Bearer) indicator shall be set to
indicate a voice bearer for PS-to-CS SRVCC
handover.
IE Type
Ins.
EBI
Bearer Flags
0
0
A Delete Bearer Failure Indication shall be sent on the S5/S8 interface by the PGW to the SGW and on the S11
interface by the SGW to the MME as part of failure of eNodeB requested bearer release or MME Initiated Dedicated
Bearer Deactivation procedure.
the SGSN as part of failure of MS and SGSN Initiated Bearer Deactivation procedure using S4.
This message shall be sent back if all the bearers included in the Delete Bearer Command message could not be deleted.
Cause IE indicates that an EPS bearer has not been deleted in the PGW.
-
"Context not found"

Table 7.2.17.2-1: Information Elements in a Delete Bearer Failure Indication
Information
elements
Cause
Bearer Context
Recovery
Private Extension
Condition / Comment
M
M This IE shall contain the list of failed bearers. See
subclause 6.1.1 "Presence requirements of Information
Elements".
C This IE shall be included If contacting the peer for the first
time.
O
3GPP
IE Type
Ins.
Cause
Bearer Context
0
0
Recovery
Private Extension
VS
Release 10
81
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.17.2-2: Bearer Context within Delete Bearer Failure Indication

Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Cause

Length = n
Condition / Comment
M See subclause 6.1.1 "Presence requirements of

M This IE shall indicate the reason of the unsuccessful
handling of the bearer.
IE Type
Ins.
EBI
Cause
7.2.18 Create Indirect Data Forwarding Tunnel Request

The Create Indirect Data Forwarding Tunnel Request message shall be sent on the S11/S4 interface by the MME/SGSN
to the SGW as part of the Handover procedures.
Table 7.2.18-1: Information Elements in a Create Indirect Data Forwarding Tunnel Request
Information
elements
Condition / Comment
IMSI
IE Type
Ins.
C This IE shall be included by the MME/SGSN if the SGW

IMSI
0
that the MME/SGSN selects for indirect data forwarding is
different from the SGW already in use for the UE as the
anchor point.
See NOTE1.
Sender F-TEID for
C This IE shall be included by the MME/SGSN if the SGW
F-TEID
0
Control Plane
that the MME/SGSN selects for indirect data forwarding is
different from the SGW already in use for the UE as the
anchor point.
See NOTE1.
Bearer Contexts
M Several IEs with this type and instance value may be
Bearer Context
0
Recovery
CO This IE shall be included if contacting the peer for the first
Recovery
0
time.
Private Extension
O
NOTE 1: The SGW which is hosting the UE's bearer(s) is considered as the (local) anchor point. Unlike the
PGW, the SGW may change due to mobility between eNodeBs, or E-UTRAN and GERAN/UTRAN
supported with S4 based architecture. In these cases the new SGW where the UE's bearer(s) are
moved, becomes the new local anchor point. A source MME/SGSN may select an SGW for indirect
data forwarding which is different than the source (anchor) SGW. Similarly, a target MME/SGSN may
select an SGW for indirect data forwarding which is different than the target (anchor) SGW.
3GPP
Release 10
82
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.18-2: Bearer Context within Create Indirect Data Forwarding Tunnel Request
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
eNodeB F-TEID for
DL data forwarding

Length = n
Condition / Comment
M
C Target eNodeB F-TEID.
This IE shall be present in the message sent from the
target MME to the target SGW, or shall be included in the
message sent from the source SGSN/MME to the source
SGW if the eNodeB F-TEID for DL data forwarding is
included in the Forward Relocation Response message.
SGW F-TEID for DL
C Target SGW F-TEID
data forwarding
source MME/SGSN to the source SGW if SGW F-TEID for
DL data forwarding is included in the Forward Relocation
Response message. This F-TEID is assigned by the SGW
that the target MME/SGSN selects for indirect data
forwarding.
SGSN F-TEID for DL C Target SGSN F-TEID
data forwarding
target SGSN to the target SGW in E-UTRAN to
GERAN/UTRAN inter RAT handover with SGW relocation
procedure, or shall be included in the message sent from
the source MME to the source SGW if the SGSN F-TEID
for DL data forwarding is included in the Forwarding
Relocation Response message.
CO This IE shall also be present in the message sent from the
source MME to the source SGW if the SGSN Address for
User Traffic and the Tunnel Endpoint Identifier Data II are
included in the GTPv1 Forward Relocation Response
message as specified in D.3.7 of 3GPP TS 23.401 [3].
RNC F-TEID for DL
C Target RNC F-TEID
data forwarding
target SGSN to the target SGW in E-UTRAN to UTRAN
inter RAT handover with SGW relocation procedure, or
shall be included in the message sent from the source
MME to the source SGW if the RNC F-TEID for DL data
forwarding is included in the Forwarding Relocation
Response message.
CO This IE shall also be present in the message sent from the
source MME to the source SGW if the RNC IP address
and TEID are included in the RAB Setup Information
and/or the Additional RAB Setup Information in the GTPv1
Forwarding Relocation Response message as specified in
D.3.3 of 3GPP TS 23.401 [3].
eNodeB F-TEID for
O Target eNodeB F-TEID.
UL data forwarding
If available this IE may be present in the message, which is
sent during the intra-EUTRAN HO from the target MME to
the target SGW, or may be included in the message sent
from the source MME to the source SGW if the eNodeB FTEID for data UL forwarding is included in the Forward
SGW F-TEID for UL
O Target SGW F-TEID
data forwarding
If available this IE may be present in the message, which is
sent during the intra-EUTRAN HO from the source MME to
the source SGW if SGW F-TEID for UL data forwarding is
included in the Forward Relocation Response message.
This F-TEID is assigned by the SGW that the target MME
selects for indirect data forwarding.
3GPP
IE Type
Ins.
EBI
F-TEID
0
0
F-TEID
F-TEID
F-TEID
F-TEID
F-TEID
Release 10
83
3GPP TS 29.274 V10.2.0 (2011-03)
7.2.19 Create Indirect Data Forwarding Tunnel Response

A Create Indirect Data Forwarding Tunnel Response message shall be sent by the SGW to the MME/SGSN as a
response to a Create Indirect Data Forwarding Tunnel Request message.
The Cause value indicates if the Indirect Data Forwarding Tunnels has been created in the SGW or not. No Indirect
Data Forwarding Tunnels have been created in the SGW if the Cause differs from "Request accepted" or "Request
accepted partially". Possible Cause values are specified in Table 8.4-1. Message specific cause values are:
-
"Request accepted".
"Data forwarding not supported".

Table 7.2.19-1: Information Elements in a Create Indirect Data Forwarding Tunnel Response
Information
elements
Cause
Sender F-TEID for
Control Plane
Bearer Contexts
Recovery
Private Extension
Condition / Comment
IE Type
M
Cause
C This IE shall be included by an SGW if the SGW receives a
F-TEID
Sender F-TEID for Control Plane IE from an MME/SGSN in
a Create Indirect Data Forwarding Tunnel Request
message.
See also NOTE 1 in Table 7.2.18-1.
M Several IEs with this type and instance value may be
Bearer Context
CO This IE shall be included if contacting the peer for the first
Recovery
time
O
Private Extension
3GPP
Ins.
0
0
0
0
VS
Release 10
84
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.19-2: Bearer Context within Create Indirect Data Forwarding Tunnel Response
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Cause
S1-U SGW F-TEID
for DL data
forwarding
S12 SGW F-TEID for
DL data forwarding

Length = n
Condition / Comment
M
M This IE shall indicate if the tunnel setup was successful,
C This IE shall be included in the response sent from the
source SGW to the source MME.
IE Type
Ins.
EBI
Cause
0
0
F-TEID
C S12 usage only.

F-TEID
1
This IE shall be included in the response sent from the
source SGW to the source SGSN.
S4-U SGW F-TEID
C S4-U usage only.
F-TEID
2
for DL data
This IE shall be included in the response sent from the
forwarding
source SGW to the source SGSN.
SGW F-TEID for DL
C This IE shall be included in the response message sent
F-TEID
3
data forwarding
from the target SGW to the target MME/SGSN.
S1-U SGW F-TEID
O If available this IE may be included in the response sent
F-TEID
4
for UL data
during the intra-EUTRAN HO from the source SGW to the
forwarding
source MME.
SGW F-TEID for UL
O If available this IE may be included in the response
F-TEID
5
data forwarding
message sent during the intra-EUTRAN HO from the target
SGW to the target MME.
NOTE 1: For DL data forwarding if the SGW does not have enough information to decide which of the F-TEID
instance from S1-U, S12, S4-U and SGW to include in the message, it may include all of them.
NOTE 2: For UL data forwarding if the SGW does not have enough information to decide which of the F-TEID
instance from S1-U and SGW to include in the message, it may include both of them.
7.2.20 Void
7.2.21 Release Access Bearers Request
The Release Access Bearers Request message shall sent on the S11 interface by the MME to the SGW as part of the S1
release procedure.
The message shall also be sent on the S4 interface by the SGSN to the SGW as part of the procedures:
-
RAB release using S4
Iu Release using S4
READY to STANDBY transition within the network

Table 7.2.21-1: Information Element in Release Access Bearers Request
Information
elements
List of RABs
Private Extension
Condition / Comment
C Shall be present on S4 interface when this message is

used to release a subset of all active RABs according to
the RAB release procedure.
included as necessary to represent a list of RABs to be
released.
O
3GPP
IE Type
Ins.
EBI
Private Extension
VS
Release 10
85
3GPP TS 29.274 V10.2.0 (2011-03)
7.2.22 Release Access Bearers Response

The Release Access Bearers Response message is sent on the S11 interface by the SGW to the MME as part of the S1
release procedure.
The message shall also be sent on the S4 interface by the SGW to the SGSN as part of the procedures:
-
RAB release using S4
Iu Release using S4
READY to STANDBY transition within the network
-
"Request accepted".

Table 7.2.22-1: Information Element in Release Access Bearers Response
Information
elements
Cause
Recovery
Private Extension
Condition / Comment
M
O This IE shall be included if contacting the peer for the first
time
O
IE Type
Ins.
Cause
Recovery
0
0
Private Extension
VS
7.2.23 Stop Paging Indication

A Stop Paging Indication message shall be sent on the S11/S4 interface by the SGW to the MME/SGSN as a part of the
network triggered service request procedure.
Table 7.2.23-1: Information Elements in a Stop Paging Indication
Information
elements
Private Extension
Condition / Comment
IE Type
Ins.
Private Extension
VS
7.2.24 Modify Access Bearers Request

The direction of this message shall be from MME to SGW (see Table 6.1-1).
If both the SGW and the MME support the MABR feature (see subclause 8.83), an MME may send a Modify Access
Bearer Request message on the S11 interface to an SGW as part of the following procedures:
-
UE triggered Service Request if there is no suspended bearer for that UE,
S1-based Handover without SGW relocation,
X2-based handover without SGW relocation,
Inter-MME E-UTRAN Tracking Area Update without SGW Change;
if all the following conditions are fulfilled:

-
the RAT type has not changed;
3GPP
Release 10
86
3GPP TS 29.274 V10.2.0 (2011-03)
the MME does not need to send UE's location and/or User CSG information or/and UE Time Zone to the PDN
GW;
the MME does not need to send an MME-FQ-CSID as per the requirements specified in 3GPP TS 23.007 [17];
ISR is not activated, if the Modify Access Bearers Request is sent as part of a UE triggered Service Request;
ISR was not activated in the old MME which is indicated by the ISRAU flag in the Context Response, if the
Modify Access Bearers Request is sent as part of an Inter-MME E-UTRAN Tracking Area Update without
SGW change.
The Modify Access Bearers Request message may modify S1-U bearers of all the PDN connections of the UE.
Support of this message is optional for the MME and SGW.
Table 7.2.24-1: Information Elements in a Modify Access Bearers Request
Information
elements
Indication Flags
Condition / Comment

is set to 1.
ISRAI: This flag shall be set to 1 if ISR is
established between the MME and the S4 SGSN
for an S1-based Handover without SGW relocation
and for an X2-based Handover without SGW
relocation.
-
IE Type
Ins.
Indication
Change F-TEID support Indication: This flag shall

be set to 1 for an IDLE state UE initiated TAU
procedure to allow the SGW changing the GTP-U
F-TEID.
Sender F-TEID for

C This IE shall be sent for a TAU/Handover with MME
F-TEID
Control Plane
change and without any SGW change.
Delay Downlink
C This IE shall be sent for a UE triggered Service Request.
Delay Value
Packet Notification
Request
Bearer Contexts to be C Several IEs with the same type and instance value may be Bearer Context
modified
included as necessary to represent a list of Bearers to be
modified.
Bearer Contexts to be C This IE shall be included for the TAU/Handover and
Bearer Context
removed
Service Request procedures where any of the bearers
existing before the TAU/Handover procedure and Service
Request procedures will be deactivated as consequence of
the TAU/Handover procedure and Service Request
procedures.
instance value, shall be included.
Recovery
Recovery
time.
Private Extension
O
Private Extension
3GPP
0
0
0
1
0
VS
Release 10
87
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.2.24-2: Bearer Context to be modified within Modify Access Bearers Request
Octets 1
Octets 2 and 3
Length = n
Octets 4
Information
P
Condition / Comment
elements
EPS Bearer ID
M
S1-U eNodeB F-TEID C This IE shall be sent for
a UE triggered Service Request
-
S1-based Handover without SGW relocation
in S1-U GTP-U tunnel setup procedure during an

Inter-MME E-UTRAN Tracking Area Update
without SGW Change procedure (see 3GPP TS
24.301 [23]).
IE Type
Ins.
EBI
F-TEID
0
0
If an MME is aware that the eNodeB supports both IP

address types, the MME shall send both IP addresses
within an F-TEID IE. If only one IP address is included,
then the SGW shall assume that the eNodeB does not
support the other IP address type.
Table 7.2.24-3: Bearer Context to be removed within Modify Access Bearers Request
Octets 1
Octets 2 and 3
Octets 4
Information
elements
EPS Bearer ID

Length = n
Condition / Comment
IE Type
Ins.
EBI
7.2.25 Modify Access Bearers Response

If an SGW supports the MABR feature (see subclause 8.83), the SGW shall send a Modify Access Bearers Response
message on the S11 interface to an MME as a response to a Modify Access Bearers Request message.
If handling of all default bearers to be modified fails, then Cause at the message level shall be a failure cause.
-
"Request accepted".
"Unexpected repeated IE".
"Modifications not limited to S1-U bearers"
The SGW shall send the cause value "Modifications not limited to S1-U bearers" if
-
it can not serve the MME Request without corresponding S5/S8 signalling, or without corresponding Gxc
signalling when PMIP is used over the S5/S8 interface, or
if there are suspended non-GBR bearers for that UE in the SGW (NOTE 3).
Upon receipt of that cause value, the MME shall repeat its request using Modify Bearer Request message per PDN
connection.
3GPP
Release 10
88
3GPP TS 29.274 V10.2.0 (2011-03)
NOTE 1: This cause value is introduced for forward compatibility between an MME implementing this version of
the specification and an SGW implementing a more recent version requiring the SGW to send S5/S8
signalling.
NOTE 2: During an Inter-MME Intra-SGW handover/TAU, if the SGW, PGW and the old MME support the partial
failure handling feature but the new MME doesn't, the SGW needs to inform the PGW about the change
of FQ-CSID (see subclause 16.2.5 of 3GPP TS 23.007 [17]). If the SGW receives a Modify Access
Bearers Request from the new MME, it can force the MME to send individual Modify Bearer Request
message per PDN connection by returning the cause value "Modifications not limited to S1-U bearers".
NOTE 3: There may be some suspended non-GBR bearers in the SGW during an Inter-MME Intra-SGW Tracking
Area Update without SGW Change when the UE is coming back to E-UTRAN via a different MME than
the MME serving the UE before the CSFB or SRVCC call.
Table 7.2.25-1: Information Elements in a Modify Access Bearers Response
Information
elements
Cause
Bearer Contexts
modified
Bearer Contexts
marked for removal
Recovery
Private Extension
Condition / Comment
IE Type
M
Cause
Bearer Context
modified that were sent in Modify Access Bearers Request
message. Several IEs with the same type and instance
value may be included as necessary to represent a list of
the Bearers which are modified.
Bearer Context
removed that were sent in the Modify Access Bearers
Request message. Shall be included if request message
contained Bearer Contexts to be removed.
Recovery
time.
O
Private Extension
Ins.
0
0
0
VS
Table 7.2.25-2: Bearer Context modified within Modify Access Bearers Response
Octets 1
Octets 2 and 3
Octets 4
Information
elements
EPS Bearer ID
Cause

Length = n
Condition / Comment
IE Type
Ins.
M
EBI
0
Cause
0
S1 SGW F-TEID
M The SGW may change the GTP-U F-TEID value if the
F-TEID
0
'Change F-TEID support Indication' flag was set to 1 in the
Modify Access Bearers Request. Otherwise, the SGW shall
return the currently allocated GTP-U F-TEID value.
See NOTE 1.
NOTE 1: The SGW shall not change its F-TEID for a given interface during the Handover, Service Request.
During Handover and Service Request the target eNodeB may use a different IP type than the one
used by the source eNodeB. In order to support such a scenario, the SGW F-TEID should contain
both an IPv4 address and an IPv6 address (see also subclause 8.22 "F-TEID").
Table 7.2.25-3: Bearer Context marked for removal within Modify Access Bearers Response
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Cause

Length = n
Condition / Comment
M
3GPP
IE Type
Ins.
EBI
Cause
0
0
Release 10
89
3GPP TS 29.274 V10.2.0 (2011-03)
7.3 Mobility Management Messages

7.3.1 Forward Relocation Request
A Forward Relocation Request message shall be sent from the source MME to the target MME over S10 interface as
part of S1-based handover relocation procedure from the source MME to the target SGSN, or from the source SGSN to
the target MME over S3 interface as part of Inter RAT handover and combined hard handover and SRNS relocation
procedures, or from source SGSN to the target SGSN over S16 interface as part of SRNS Relocation and PS handover
procedures.
A Forward Relocation Request message shall also be sent from the source MME to the target SGSN over S3 interface
as part of SRVCC from E-UTRAN to UTRAN or GERAN with DTM HO support procedures and from source SGSN to
the target SGSN over S16 interface as part of SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO
support.
Forward Relocation procedure across S10 interface (when KASME is taken into use) shall be performed according to the
Rules on Concurrent Running of Security Procedures, which are specified in 3GPP TS 33.401 [12].
Table 7.3.1-1 specifies the presence requirements and conditions of the IEs in the message.
3GPP
Release 10
90
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.1-1: Information Elements in a Forward Relocation Request
3GPP
Release 10
Information
elements
IMSI
91
P
3GPP TS 29.274 V10.2.0 (2011-03)
Condition / Comment
C The IMSI shall be included in the message except for the

case:
If the UE is emergency attached and the UE is
UICCless.
IE Type
Ins.
IMSI
The IMSI shall be included in the message but not used as

an identifier
authenticated.
Sender's F-TEID for
Control Plane
MME/SGSN UE EPS
PDN Connections
M This IE specifies the address and the TEID for control

F-TEID
plane message which is chosen by the source
MME/SGSN.
This information shall be used by the target MME/SGSN to
the source MME/SGSN when sending Forward Relocation
Response message, Forward Access Context
Acknowledge message and Forward Relocation Complete
Notification message.
M Several IEs with this type and instance values shall be
PDN Connection
included as necessary to represent a list of PDN
Connections
M
F-TEID
SGW S11/S4 IP
Address and TEID for
Control Plane
SGW node name
C This IE shall be included if the source MME or SGSN has
the source SGW FQDN.
MME/SGSN UE MM M
Context
Indication Flags
C This IE shall be included if any of the flags are set to 1.
Direct Forwarding Indication: This flag shall be set
to 1 if direct forwarding is supported in the S1
based handover procedure. This flag shall not be
set to 1 if the message is used for other handover
procedures.
E-UTRAN
Transparent
Container
UTRAN Transparent
Container
Target Identification
Idle mode Signalling Reduction Supported

Indication flag: This flag shall be set to 1 if the
source MME/SGSN and associated SGW are
capable to establish ISR for the UE.
Unauthenticated IMSI: This flag shall be set to 1 if

the IMSI present in the message is not
authenticated and is for an emergency attached
UE.
Change Reporting support indication flag: This

flag shall be set to 1 if the Source S4-SGSN/MME
supports Location Change Reporting mechanism.
See NOTE1.
CSG Change Reporting Support Indication flag:

This flag shall be set to 1 if the Source S4SGSN/MME supports CSG Information Change
Reporting mechanism. See NOTE1.
C This IE shall be included if the message is used for

UTRAN/GERAN to E-UTRAN inter RAT handover
procedure, intra RAT handover procedure and 3G SGSN
to MME combined hard handover and SRNS relocation
procedure.
C This IE shall be included if the message is used for PS
handover to UTRAN Iu mode procedures, SRNS relocation
procedure and E-TURAN to UTRAN inter RAT handover
procedure.
C This IE shall be included if the message is used for SRNS
relocation procedure and handover to UTRAN/E-UTRAN
3GPP
0
1
FQDN
MM Context
Indication
F-Container
F-Container
Target
Identification
Release 10
92
3GPP TS 29.274 V10.2.0 (2011-03)
procedures.
C This IE shall be included only if the HRPD pre registration
IP-Address
0
was performed at the source MME
C This IE shall be included only if the 1xRTT CS fallback pre
IP-Address
1
registration was performed at the source MME
C This IE is the information from the source eNodeB, the
F-Cause
0
source MME shall include this IE in the message. Refer to
the 3GPP TS 29.010 [42] for the mapping of cause values
between S1AP, RANAP and BSSGP.
RANAP Cause
C This IE is the information from the source RNC, the source
F-Cause
1
SGSN shall include this IE in the message. Refer to the
3GPP TS 29.010 [42] for the mapping of cause values
BSS Container
F-Container
2
handover to GERAN A/Gb mode and E-UTRAN to GERAN
A/Gb mode inter RAT handover procedure.
Source Identification
C This IE shall be included on the S16 interface if the
Source
0
message is used for PS handover from GERAN/UTRAN to
Identification
GERAN A/Gb mode.
BSSGP Cause
C This IE is the information from source BSS, the source
F-Cause
2
SGSN shall include this IE in the message. Refer to the
3GPP TS 29.010 [42] for the mapping of cause values
Selected PLMN ID
C The old MME/SGSN shall include this IE if the selected
Selected PLMN
0
PLMN identity is available. The Selected PLMN ID IE
ID
indicates the core network operator selected for the UE in
a shared network.
Recovery
C If contacting the peer for the first time
Recovery
0
Trace Information
C This IE shall be included when session trace is active for
Trace Information 0
this IMSI/IMEI.
Subscribed RFSP
CO This IE shall be included during inter-MME/SGSN mobility
RFSP Index
0
Index
procedures, if the source MME/SGSN receives it from an
HSS.
RFSP Index in Use
CO This IE shall be included only during inter-MME/SGSN
RFSP Index
1
mobility procedures, if the source MME/SGSN supports the
feature.
CSG ID
CO This IE shall be included if the source MME/SGSN
CSG ID
0
receives it from the source eNodeB/RNC
CSG Membership
CO This IE shall be included if the source MME/SGSN when
CMI
0
Indication
the CSG access mode received from the source
eNodeB/RNC indicates the target cell is a hybrid cell
UE Time Zone
CO When available, this IE shall be included by the source
UE Time Zone
0
MME/S4-SGSN.
Serving Network
CO This IE shall be included to indicate the current Serving
Serving Network
0
Network.
MME/S4-SGSN LDN O This IE is optionally sent by the MME/S4-SGSN to the peer
Local
0
MME/S4-SGSN on the S3/S10/S16 interfaces (see 3GPP
Distinguished
TS 32.423 [44]), when communicating the LDN to the peer
Name (LDN)
Private Extension
O
HRPD access node
S101 IP address
1xIWS S102 IP
address
RAN Cause
The PDN Connection grouped IE shall be coded as depicted in Table 7.3.1-2.
3GPP
Release 10
93
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.1-2: MME/SGSN UE EPS PDN Connections within Forward Relocation Request
Octet 1
Octets 2 and 3
Octet 4
Information
elements
APN
APN Restriction
PDN Connection IE Type = 109 (decimal)

Length = n
Condition / Comment
IE Type
Ins.
M
APN
0
C This IE denotes the restriction on the combination of types APN Restriction
0
Context. The target MME or SGSN determines the
Maximum APN Restriction using the APN Restriction.
If available, the source MME/S4SGSN shall include this IE.
Selection Mode
Selection Mode
0
MME/S4-SGSN
IPv4 Address
C This IE shall not be included if no IPv4 Address is
IP Address
0
assigned. See NOTE 1.
IPv6 Address
IP Address
1
assigned.
Linked EPS Bearer ID M This IE identifies the default bearer of the PDN
EBI
0
Connection.
PGW S5/S8 IP
M This IE shall include the TEID in the GTP based S5/S8
F-TEID
0
Address for Control
Plane or PMIP
PGW node name
FQDN
0
the PGW FQDN.
Bearer Contexts
C Several IEs with this type and instance values may be
Bearer Context
0
Aggregate Maximum M
AMBR
0
Bit Rate (APN-AMBR)
Charging
C This IE shall be present if charging characteristics was
Charging
0
characteristics
supplied by the HSS to the MME/SGSN as a part of
characteristics
subscription information.
Change Reporting
C This IE shall be included whenever available at the source Change Reporting 0
Action
MME/SGSN.
Action
CSG Information
CO This IE shall be included whenever available at the source CSG Information
0
Reporting Action
MME/SGSN.
Reporting Action
Signalling Priority
CO The source SGSN/MME shall include this IE if the UE
Signalling Priority
0
Indication
indicated low access priority when establishing the PDN
Indication
connection.
NOTE 1: For deferred IPv4 address allocation, if the MME/S4-SGSN receives the PDN address "0.0.0.0" from
PGW during "eUTRAN Initial Attach", "PDP Context Activation", "UE requested PDN Connectivity",
then the MME/S4-SGSN shall include this IPv4 address "0.0.0.0".
The Bearer Context grouped IE shall be coded as depicted in Table 7.3.1-3.
3GPP
Release 10
94
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.1-3: Bearer Context within MME/SGSN UE EPS PDN Connections within Forward Relocation
Request
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
TFT
SGW S1/S4/S12 IP
user plane
PGW S5/S8 IP
user plane
Bearer Level QoS
BSS Container

Length = n
Condition / Comment
M
C This IE shall be present if a TFT is defined for this bearer.
M
C This IE shall be present for GTP based S5/S8
M
CO The MME/S4 SGSN shall include the Packet Flow ID,
Radio Priority, SAPI, PS Handover XID parameters in the
TAU/RAU/Handover procedure, if available.
Transaction Identifier C This IE shall be sent over S3/S10/S16 if the UE supports
A/Gb and/or Iu mode.
IE Type
Ins.
EBI
Bearer TFT
F-TEID
0
0
0
F-TEID
Bearer Level QoS

F-Container
0
0
TI
7.3.2 Forward Relocation Response

A Forward Relocation Response message shall be sent as a response to Forward Relocation Request during S1-based
handover procedure, Inter RAT handover procedures, SRNS Relocation procedure and PS handover procedures.
Cause IE indicates if the relocation has been accepted, or not. The relocation has not been accepted by the target
MME/SGSN if the Cause IE value differs from "Request accepted". Possible Cause values are specified in Table 8.4-1.
Message specific cause values are:
-
"Relocation failure".
3GPP
Release 10
95
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.2-1: Information Elements in a Forward Relocation Response
3GPP
Release 10
Information
elements
Cause
Sender's F-TEID for
Control Plane
Indication Flags
96
P
3GPP TS 29.274 V10.2.0 (2011-03)
Condition / Comment
M
C If the Cause IE contains the value "Request accepted", the
target MME/SGSN shall include this IE in Forward
This information shall be used by the source MME/SGSN
to the target MME/SGSN when sending Forward
Relocation Complete Acknowledge message and Forward
Access Context Notification message.
SGW Change Indication:
This flag shall be set to 1 if the target MME/SGSN
has selected a new SGW.
List of Set-up Bearers C The list of set-up Bearers IE contains the EPS bearer
Identifiers of the Bearers that were successfully allocated
in the target system during a handover procedure. This IE
shall be included if the source and target access type is
EUTRAN and the Cause IE contains the value "Request
accepted".
See NOTE 1.
List of Set-up RABs
C The list of set-up RABs IE contains the RAB Identifiers of
the RABs that were successfully allocated in the target
system. This IE shall be included if the Cause IE contains
the value "Request accepted" and
If the source access type is UTRAN and the
target access type is E-UTRAN/UTRAN
If the source access type is E-UTRAN and the
target access type is UTRAN
See NOTE 1.
List of Set-up PFCs
O The list of set-up PFCs IE contains the Packet Flow
Identifies of the PFCs that were successfully allocated in
the target system during a PS handover to/from GERAN or
inter RAT handover to/from GERAN. If the Cause IE
contains the value "Request accepted", this IE may be
included.
See NOTE 1.
eNodeB Cause
C This IE is included if cause value is contained in S1-AP
message. Refer to the 3GPP TS 29.010 [42] for the
mapping of cause values between S1AP, RANAP and
BSSGP.
RANAP Cause
C This IE is included if cause value is contained in RANAP
message. Refer to the 3GPP TS 29.010 [42] for the
BSSGP.
E-UTRAN
C This IE is conditionally included only during a handover to
Transparent
E-UTRAN and contains the radio-related and core network
Container
information. If the Cause IE contains the value "Request
accepted", this IE shall be included.
UTRAN Transparent
Container
UTRAN and contains the radio-related and core network
BSS Container
GERAN and contains the radio-related and core network
BSSGP Cause
C For handover to GERAN, if a cause value is received from
the Target BSC, the BSSGP Cause IE shall be included
and shall be sent to the cause value received from the
target BSC. Refer to the 3GPP TS 29.010 [42] for the
3GPP
IE Type
Ins.
Cause
F-TEID
0
0
Indication
Bearer Context
Bearer Context
Bearer Context
F-Cause
F-Cause
F-Container
F-Container
F-Container
F-Cause
Release 10
97
3GPP TS 29.274 V10.2.0 (2011-03)

BSSGP.
Local
0
Distinguished
Name (LDN)
Private Extension
O
NOTE 1: In the Forward Relocation Request message, the inclusion of "RAN Cause" indicates that the source
access type is E-UTRAN. In the Forward Relocation Request message, the inclusion of "RANAP
Cause" indicates that the source access type is UTRAN. In the Forward Relocation Request
message, the inclusion of "BSSGP Cause" indicates that the source access type is GERAN.
Bearer Context IE in this message is specified in Table 7.3.2-2, the source system shall use this IE for data forwarding
in handover.
Table 7.3.2-2: Bearer Context
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
Packet Flow ID
eNodeB F-TEID for
DL data forwarding
eNodeB F-TEID for

UL data forwarding
SGW F-TEID for DL

data forwarding
RNC F-TEID for DL
data forwarding
SGSN F-TEID for DL
data forwarding
SGW F-TEID for UL
data forwarding

Length = n
Condition / Comment
C This IE shall be included if the message is used for S1Based handover procedure.
This IE shall be included if the message is used for SRNS
relocation procedure and Inter RAT handover to/from Iu
mode procedures.
handover and Inter RAT handover to/from A/Gb mode
procedures.
C This IE shall be included for the message sent from the
target MME, if the DL Transport Layer Address and DL
GTP TEID are included in the "SAE Bearers Admitted List"
of the S1AP: HANDOVER REQUEST ACKNOWLEDGE
and direct forwarding or indirect forwarding without SGW
change is applied.
O This IE may be included for the message sent from the
target MME during the intra-EUTRAN HO, if the UL
Transport Layer Address and UL GTP TEID are included in
the "SAE Bearers Admitted List" of the S1AP: HANDOVER
REQUEST ACKNOWLEDGE and direct forwarding or
indirect forwarding without SGW change is applied.
C This SGW F-TEID shall be included for indirect data
forwarding.
C This RNC F-TEID shall be included in the message sent
from SGSN, if the target system decides using RNC FTEID for data forwarding.
C This SGSN F-TEID shall be included in the message sent
from SGSN, if the target system decides using SGSN FTEID for data forwarding.
O If available this SGW F-TEID may be included for indirect
data forwarding during the intra-EUTRAN HO.
IE Type
Ins.
EBI
Packet Flow ID
F-TEID
F-TEID
F-TEID
F-TEID
F-TEID
F-TEID
7.3.3 Forward Relocation Complete Notification

A Forward Relocation Complete Notification message shall be sent to the source MME/SGSN to indicate the handover
has been successfully finished.
3GPP
Release 10
98
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.3-1: Information Elements in a Forward Relocation Complete Notification

Information
elements
Indication Flags
Condition / Comment
IE Type
Ins.
This IE shall be included if any of the flags are set to 1.

Idle mode Signalling Reduction Activation Indication: This
flag shall be set to 1 if the message is used for inter RAT
handover and the UE has ISR capability. This flag is set to
indicate to the source MME/SGSN whether it shall
maintain the UE's context and whether it shall activate ISR.
Indication
Private Extension
Private Extension
VS
7.3.4 Forward Relocation Complete Acknowledge

A Forward Relocation Complete Acknowledge message shall be sent as a response to Forward Relocation Complete
Notification during inter eNodeB handover with MME relocation procedure, SRNS Relocation with SGSN change
procedures using S4 or Inter RAT Handover with MME/S4 SGSN interaction procedures.
Possible Cause values are specified in Table 8.4-1.
Table 7.3.4-1: Information Elements in a Forward Relocation Complete Acknowledge
Information
elements
Cause
Recovery
Private Extension
Condition / Comment
M
O
O
IE Type
Ins.
Cause
Recovery
Private Extension
0
0
VS
7.3.5 Context Request

The new MME/SGSN shall send the Context Request message to the old MME/SGSN on S3/S16/S10 interface as a
part of TAU/RAU procedure to get the MM and EPS bearer Contexts for the UE.
If the sending/new node is a MME, it shall include in the Context Request message:
-
the GUTI IE and Complete TAU Request Message IE if the GUTI received from UE indicates the old node is a
MME.
the RAI IE and the P-TMSI IE, which are derived from the GUTI received from UE, and the P-TMSI Signature
that was received intact from the UE, if the GUTI indicates the old node is an SGSN.
If the sending/new node is an SGSN, it shall include RAI IE, P-TMSI IE and P-TMSI Signature IE in the Context
Request message. If the receiving/old node is an MME, it shall construct GUTI according to the RAI IE, P-TMSI IE
and P-TMSI Signature IE (see the mapping relationship between RAI, P-TMSI, P-TMSI signature and GUTI defined in
3GPP TS23.003[2]), and find UE context via this GUTI.
The new MME differentiates the type of the old node as specified in subclause 2.8.2.2.2 of 3GPP TS 23.003 [2]. If the
old node is an SGSN, the GUTI shall be mapped to RAI and P-TMSI by the new MME; if the old node is a MME, the
new MME include GUTI IE and Complete TAU Request Message IE in the Context Request message. The Mapping
between temporary and area identities is defined in 3GPP TS 23.003 [2].
The Target PLMN ID IE shall be used in old SGSN/MME in order to decide whether un-used authentication vectors to
be distributed to new SGSN/MME or not. Distribution and use of authentication vectors between different serving
network domains are specified in 3GPP TS 33.401 [12].
3GPP
Release 10
99
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.5-1: Information Elements in a Context Request

Information
elements
Condition / Comment
IE Type
IMSI
Ins.
C IMSI shall be included if the UE has been successfully

IMSI
authenticated.
GUTI
C The New MME shall include this IE over S10 interface.
GUTI
Routeing Area
C This IE shall be included over S3/S16 interface, if the GUTI
ULI for RAI
Identity(RAI)
indicates the old node is an SGSN, the new MME maps
this IE from GUTI.
Packet TMSI(P-TMSI) C This IE shall be included over S3/S16 interface. For the S3
P-TMSI
interface, if sent by the MME, this IE is derived by the MME
from the GUTI received from the UE.
P-TMSI Signature
C This IE shall be included over S3/S16 interface if it is
P-TMSI Signature
received from the.
Complete TAU
C The new MME shall include this IE, and the old MME may
Complete
request message
use this IE for integrity check.
Request Message
S3/S16/S10 Address C This IE specifies the address and the TEID for control
F-TEID
and TEID for Control
plane message which is chosen by the new MME/SGSN.
Plane
In case of SGSN pool, the IPv4 or the IPv6 address field
shall be set to the same value of the Source IP address of
the IP packet carrying this message, and the relaying
SGSN shall not change the content of this IE when
sending it to the old SGSN.
UDP Source Port
C If an SGSN within the same SGSN pool as the old SGSN
Port Number
Number
receives this message, the SGSN shall include the UDP
Source Port number of the received message in this
parameter if this IE is not present and relay the message to
the old SGSN. The old SGSN shall use this UDP port as
the UDP destination port of the Context Response
message.
RAT Type
C The RAT Type indicates the Radio Access Technology
RAT Type
which is used in the new system.
Indication
Indication
is set to 1.
Applicable Flags are:
- The MS Validated indicates that the new system
has successfully authenticated the UE, or the new
system has validated the integrity protection of the
TAU request message.
Hop Counter
O If an SGSN within the same SGSN pool with the old SGSN
Hop Counter
receives this message, the SGSN shall decrement the Hop
Counter if this IE is present in the received message;
otherwise, the SGSN may include a Hop Counter with a
value of max-1, and may relay the message to the old
SGSN.
Target PLMN ID
CO If available, this IE shall be included in order to allow old
Serving Network
MME/SGSN to make a judgment whether un-used
authentication vectors to be distributed or not.
Local
Distinguished
Name (LDN)
Private Extension
O
Private Extension
0
0
0
0
0
0
0
0
0
0
VS
7.3.6 Context Response

A Context Response message shall be sent as a response to a previous Context Request message during TAU/RAU
procedure.
-
"IMSI not known"
"P-TMSI Signature mismatch"
3GPP
Release 10
100
3GPP TS 29.274 V10.2.0 (2011-03)
"User authentication failed"
3GPP
Release 10
101
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.6-1: Information Elements in a Context Response
3GPP
Release 10
Information
elements
Cause
IMSI
102
P
3GPP TS 29.274 V10.2.0 (2011-03)
Condition / Comment
M
C The IMSI shall be included in the message except for the
case:
If the UE is emergency attached and the UE is
UICCless.
IE Type
Ins.
Cause
IMSI
0
0
The IMSI shall be included in the message but not used as

an identifier
authenticated.
MME/SGSN UE MM
Context
MME/SGSN UE EPS
PDN Connections
C This IE shall be included if the Cause IE has the value "

MM Context
Request Accepted ".
C This IE shall be included if there is at least a PDN
PDN Connection
connection for this UE on the sending MME/SGSN.
included as necessary to represent a list of PDN
Connections.
Sender F-TEID for
C This IE specifies the address and the TEID for control
F-TEID
Control Plane
plane message which is chosen by the old MME/SGSN.
SGW S11/S4 IP
C This IE shall be included if a SGW is being used by the old
F-TEID
MME/SGSN.
Control Plane
SGW node name
FQDN
the source SGW FQDN. This IE identifies the SGW that
was used by the old MME/SGSN.
Indication Flags
Indication
0
0
0
1
0
0
Idle mode Signalling Reduction Supported Indication:

This flag shall be set to 1 if the Cause IE value
indicates "Request accepted" and the old system
(including old MME/SGSN and the associated
SGW) has the ISR capability.
Unauthenticated IMSI:
This flag shall be set to 1 if the IMSI present in the
message is not authenticated and is for an
emergency attached UE.
Change Reporting support indication flag:
This flag shall be set to 1 if the Source S4SGSN/MME supports Location Change Reporting
mechanism. See NOTE1.
CSG Change Reporting support indication flag:
This flag shall be set to 1 if the Source S4SGSN/MME supports CSG Information Change
Reporting mechanism. See NOTE1.
ISRAU:
- This flag shall be set to 1 on S10/S16 interface if the
ISR is activated for the UE before the UE moving to
the new SGSN/MME.
Trace Information
HRPD access node
S101 IP address
1xIWS S102 IP
address
Subscribed RFSP
Index
RFSP Index in Use
C This IE shall be included when session trace is active for

Trace Information
this IMSI/IMEI.
C This IE shall be included only if the HRPD pre registration
IP-Address
was performed at the old MME
C This IE shall be included only if the 1xRTT CS fallback pre
IP-Address
registration was performed at the old MME
RFSP Index
mobility procedures, if the source MME/SGSN receives it
from an HSS.
RFSP Index
mobility procedures, if the source MME/SGSN supports the
feature.
3GPP
0
0
1
0
1
Release 10
103
3GPP TS 29.274 V10.2.0 (2011-03)
UE Time Zone

UE Time Zone
0
MME/S4-SGSN.
Local
0
Distinguished
Name (LDN)
Private Extension
O
NOTE1: 3GPP TS 23.401 [3] (e.g. subclause 5.3.2.1) and 3GPP TS 23.060 [35] (e.g. subclause 9.2.2.1)
Table 7.3.6-2: MME/SGSN UE EPS PDN Connections within Context Response

Octet 1
Octets 2 and 3
Octet 4
Information
elements
APN
APN Restriction

Length = n
Condition / Comment
IE Type
M
APN
C This IE denotes the restriction on the combination of types APN Restriction
Context. The target MME or SGSN determines the
Maximum APN Restriction using the APN Restriction.
If available, the source MME/S4 SGSN shall include this
IE.
Selection Mode
Selection Mode
MME/S4-SGSN
IPv4 Address
IP Address
assigned. See NOTE 1.
IPv6 Address
IP Address
assigned.
Linked EPS Bearer ID M This IE identifies the default bearer of the PDN
EBI
Connection.
PGW S5/S8 IP
M This IE shall include the TEID in the GTP based S5/S8
F-TEID
Address for Control
Plane or PMIP
PGW node name
FQDN
the PGW FQDN.
Bearer Contexts
M Several IEs with this type and instance values may be
Bearer Context
Aggregate Maximum M
AMBR
Bit Rate (APN-AMBR)
Charging
C This IE shall be present if charging characteristics was
Charging
characteristics
supplied by the HSS to the MME/SGSN as a part of
characteristics
subscription information.
Change Reporting
C This IE shall be included whenever available at the source Change Reporting
Action
MME/SGSN.
Action
CSG Information
CO This IE shall be included whenever available at the source CSG Information
Reporting Action
MME/SGSN.
Reporting Action
Indication flags
CO This IE shall be included if any one of the applicable flags
Indication
is set to 1.
Applicable flags:
Subscribed QoS Change Indication: This flag shall
be set to 1 if the subscribed QoS profile of the
related PDN connection has changed in the old
MME/SGSN when the UE is in ECM-IDLE state
and ISR is activated.
Signalling Priority
Indication
Ins.
0
0
0
0
1
0
0
0
0
0
0
0
0
0
CO The source SGSN/MME shall include this IE if the UE

Signalling Priority
0
indicated low access priority when establishing the PDN
Indication
connection.
NOTE 1: For deferred IPv4 address allocation, if the MME/S4-SGSN receives the PDN address "0.0.0.0" from
PGW during "eUTRAN Initial Attach", "PDP Context Activation", "UE requested PDN Connectivity",
then the MME/S4-SGSN shall include this IPv4 address "0.0.0.0".
3GPP
Release 10
104
3GPP TS 29.274 V10.2.0 (2011-03)
The Bearer Context shall be coded as depicted in Table 7.3.6-3.

Table 7.3.6-3: Bearer Context within MME/SGSN UE EPS PDN Connections within Context Response
Octet 1
Octets 2 and 3
Octet 4
Information
elements
EPS Bearer ID
TFT
SGW S1/S4/S12 IP
user plane
PGW S5/S8 IP
user plane
Bearer Level QoS
BSS Container
Bearer Context IE Type = 93

Length = n
Sparae and Instance fields
Condition / Comment
M
C This IE shall be present if a TFT is defined for this bearer.
M
C This IE shall only be included for GTP based S5/S8.
M
CO The MME/S4 SGSN shall include the Packet Flow ID,
Radio Priority, SAPI, PS Handover XID parameters in the
TAU/RAU/Handover procedure, if available.
Transaction Identifier C This IE shall be sent over S3/S10/S16 if the UE supports
A/Gb and/or Iu mode.
IE Type
Ins.
EBI
Bearer TFT
F-TEID
0
0
0
F-TEID
Bearer Level QoS

F-Container
0
0
TI
7.3.7 Context Acknowledge

A Context Acknowledge message shall be sent as a response to a previous Context Response message, only if the
previous Context Response message is received with the acceptance cause.
Possible cause values are specified in Table 8.4-1. Message specific cause values are:
-
Table 7.3.7-1: Information Elements in a Context Acknowledge
Information
elements
Cause
Indication flags
Condition / Comment
M
is set to 1.
Applicable Flags are:
SGWCI:
SGW change indication indicates a new SGW has
been selected. The old MME/old SGSN marks in
its context that the information in the GWs and the
HSS are invalid.
IE Type
Ins.
Cause
Indication
0
0
ISRAI:
This flag indicates to the old system that it shall
maintain the UE's contexts. This flag shall be set to
1 if the Cause IE value indicates "Request
accepted" and ISR is activated as specified in
3GPP TS 23.401 [3].
See NOTE1.
Private Extension
O
Private Extension
NOTE1: For the Indication Flags, the combination (SGWCI, ISRAI) = 1,1 shall be considered an error if
received.
3GPP
VS
Release 10
105
3GPP TS 29.274 V10.2.0 (2011-03)
7.3.8 Identification Request

If the UE identifies itself with temporary identity and it has changed SGSN/MME since detach in Attach procedure, the
new MME/SGSN shall send an Identification Request message to the old SGSN/MME over S3, S16 or S10 interface to
request IMSI.
If the sending node is a MME, it shall include in the Identification Request message:
-
the GUTI IE and Complete Attach Request Message IE if the GUTI received from UE indicates the old node is a
MME.
the RAI P-TMSI, which was derived from the GUTI received from UE, and the P-TMSI Signature that was
received intact from the UE, if the GUTI indicates the old node is an SGSN.
If the sending/new node is an SGSN, it shall include RAI IE, P-TMSI IE and P-TMSI Signature IE in the Identification
Request message. If the receiving node is an MME, it shall construct GUTI according to the RAI IE, P-TMSI IE and PTMSI Signature IE (see the mapping relationship between RAI, P-TMSI, P-TMSI signature and GUTI defined in 3GPP
TS23.003[2]), and find UE context via this GUTI.
The new MME differentiates the type of the old node as specified in subclause 2.8.2.2.2 of 3GPP TS 23.003 [2]. If the
old node is an SGSN, the GUTI shall be mapped to RAI and P-TMSI by the new MME; if the old node is a MME, the
new MME include GUTI IE and Complete Attach Request Message IE in the Identification Request message. The
Mapping between temporary and area identities is defined in 3GPP TS 23.003 [2].
The GUTI IE shall not coexist with any of the RAI IE, P-TMSI IE and P-TMSI Signature IE in an Identification
Request message. If this occurs, the receiving node shall return a corresponding cause value in the response message.
The Target PLMN ID IE shall be used in old SGSN/MME in order to decide whether un-used authentication vectors to
be distributed to new SGSN/MME or not. Distribution and use of authentication vectors between different serving
network domains are specified in 3GPP TS 33.401 [12].
3GPP
Release 10
106
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.8-1: Information Elements in an Identification Request

Information
elements
GUTI
Routeing Area
Identity(RAI)
Condition / Comment
C The new MME shall include this IE over S10 interface.

C This IE shall be included over S3/S16 interface, if the GUTI
received from the UE indicates the old node is an SGSN,
the new MME maps this IE from GUTI.
Packet TMSI(P-TMSI) C This IE shall be included over S3/S16 interface. For the S3
interface, if sent by the MME, this IE is derived by the MME
from the GUTI received from the UE.
P-TMSI Signature
C This IE shall be included over S3/S16 interface, if it is
received from the UE.
Complete Attach
C The new MME shall include this IE over S10 interface, and
Request Message
the old MME may use this IE for integrity check.
Address for Control
Plane
receives this message, the SGSN shall include the old IP
address of the received message in this optional
the old SGSN.
UDP Source Port
C If an SGSN within the same SGSN pool as the old SGSN
Number
receives this message, the SGSN shall include the UDP
Source Port number of the received message in this
the old SGSN. The old SGSN shall use this UDP port as
the UDP destination port of the Identification Response
message.
Hop Counter
receives this message, the SGSN shall decrement the Hop
Counter if this IE is present in the received message;
otherwise, the SGSN may include a Hop Counter with a
value of max-1, and may relay the message to the old
SGSN.
Target PLMN ID
CO If available, this IE shall be included in order to allow old
MME/SGSN to make a judgment whether un-used
authentication vectors to be distributed or not.
Private Extension
O None
IE Type
Ins.
GUTI
ULI for RAI
0
0
P-TMSI
P-TMSI Signature
Complete
Request Message
IP Address
Port Number
Hop Counter
Serving Network
Private Extension
VS
7.3.9 Identification Response

The old SGSN/MME shall send an Identification Response message to the new MME/SGSN as a response to a previous
Identification Request message over S3/S10/S16 interface.
For Intra Domain Connection of RAN Nodes to Multiple CN Nodes, if an old SGSN within an SGSN pool receives an
Identification Request message that contains the optional parameter Address for Control Plane, the old SGSN shall use
this address as destination IP address of the Identification Response message.
-
"P-TMSI Signature mismatch"
"User authentication failed"
Only the Cause information element shall be included in the response if the Cause contains another value than "Request
accepted".
3GPP
Release 10
107
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.9-1: Information Elements in an Identification Response

Information
elements
Cause
IMSI
MME/SGSN UE MM
Context
Trace Information
Private Extension
Condition / Comment
M
C This IE shall be included if the Cause contains the value
"Request accepted".
C This IE shall be included if Attach Request is integrity
protected
CO This IE shall be included when session trace is active for
this IMSI/IMEI.
O
IE Type
Ins.
Cause
IMSI
0
0
MM Context
Trace Information
Private Extension
VS
7.3.10 Forward Access Context Notification

A Forward Access Context Notification message shall be sent from the Old SGSN to the New SGSN over the S16
interface to forward the RNC contexts to the target system, or sent from the Old MME to the New MME over the S10
interface to forward the RNC/eNodeB contexts to the target system.
When the old SGSN receives the RANAP message Forward SRNS Context, the old SGSN shall send a Forward Access
Context Notification message to the new SGSN. The new SGSN shall forward the message to the target RNC using the
corresponding RANAP message.
When the old SGSN receives a BSSGP message PS handover Required and the acknowledged peer-to-peer LLC
operation is used for the Bearer Context or when "delivery order" is set in the Bearer Context QoS profile, the old
SGSN shall send a Forward Access Context Notification message with the PDU Number IE to the new SGSN. The new
SGSN shall forward the message to the target RNC/ target BSS using the corresponding RANAP message only for PS
handover to Iu mode.
When the old SGSN receives a BSSGP message PS handover Required from source BSS/RNC for PS handover to A/Gb
mode, the value part of RAB Context IE shall be empty according to its defined minimum length.
Table 7.3.10-1 specifics the presence requirements and conditions of the IEs in the message.
Table 7.3.10-1: Information Elements in a Forward Access Context Notification
Information
elements
RAB Contexts
Source RNC PDCP

context Info
PDU Numbers
E-UTRAN
Transparent
Container
Private Extension
Condition / Comment
C This IE shall be included for S16 only. Several IEs with this
type and instance values shall be included as necessary to
represent a list of Bearers.
For each RAB context in the received RANAP message,
the old SGSN shall include this IE in the message.
C If available, the old SGSN shall include an Source RNC
PDCP context info in the message.
C This IE only applies to S16. The old SGSN shall include
this IE in the message if the acknowledged peer-to-peer
LLC operation is used for the Bearer Context or when
"delivery order" is set in the Bearer Context QoS profile in
A/Gb mode to Iu/A/Gb mode PS handover.
C This IE shall be included over S10 to contain the eNodeB
Status Transfer Transparent Container IE specified in S1AP.
O
IE Type
Ins.
RAB Context
Source RNC
PDCP context
Info
PDU Numbers
F-Container
Private Extension
VS
7.3.11 Forward Access Context Acknowledge

A Forward Access Context Acknowledge message shall be sent to the old MME/SGSN as a response to Forward Access
Context Notification.
3GPP
Release 10
108
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.11-1 specifics the presence requirements and conditions of the IEs in the message.
Table 7.3.11-1: Information Elements in a Forward Access Context Acknowledge
Information
elements
Cause
Private Extension
Condition / Comment
M
O
IE Type
Ins.
Cause
Private Extension
0
VS
7.3.12 Detach Notification

A Detach Notification message shall be sent from an MME to the associated SGSN, or from an SGSN to the associated
MME as a part of Detach procedure if the ISR is activated between the MME and SGSN for the UE.
-
"Local Detach".
"Complete Detach".
A Detach Notification message shall also be sent from an SGSN to the associated MME as a part of Detach procedure if
the ISR is activated between the MME and SGSN for the UE.
-
"IMSI Detach only".
"Local Detach" indicates that this detach is local to the MME/SGSN and so the associated SGSN/MME registration
where the ISR is activated shall not be detached. The MME/SGSN that receives this message including this Cause value
of "Local Detach" only deactivates the ISR. This Cause value shall be included in the procedures:
-
MME/SGSN-initiated Detach Procedure in case of implicit detach.
"Complete Detach" indicates both the MME registration and the SGSN registration that the ISR is activated for, shall be
detached. This "Complete Detach" Cause value shall be included in the procedures:
-
UE-initiated Detach Procedure.
MME/SGSN-initiated Detach Procedure in case of explicit detach.
For the purpose of SGs handling, the SGSN shall include Detach Type in the Detach Notification message for
"Complete Detach" when the UE is combined IMSI/EPS attached and the ISR is activated.
Possible Detach Type values are:
-
"PS Detach".
"Combined PS/CS Detach".
"PS Detach" indicates that the MME shall perform explicit IMSI detach from EPS service as specified in section 5.4,
3GPP TS 29.118 [22]. "Combined PS/CS detach" indicates that the MME shall perform explicit IMSI detach from nonEPS service as specified in section 5.5, 3GPP TS 29.118 [22].
"IMSI Detach only" indicates that combined IMSI/EPS attached UE initiates IMSI only GPRS detach from non-GPRS
service as specified in section 4.7.4.1, 3GPP TS 24.008 [5], and both the SGSN/MME registration shall be remained.
The MME shall perform explicit IMSI detach from non-EPS service for the SGs handling purpose, which is specified in
section 5.5, 3GPP TS 29.118 [22]. This "IMSI Detach only" Cause value shall be included in the procedures:
-
UE-initiated Detach Procedure for GERAN/UTRAN for "IMSI Detach only".
Table 7.3.12-1 specifics the presence of the IEs in the message.
3GPP
Release 10
109
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.12-1: Information Elements in a Detach Notification

Information
elements
Cause
Detach Type
Condition / Comment
M
CO This IE shall be included by SGSN when the Cause
indicates "Complete Detach" for the combined IMSI/EPS
attached UE.
O
Private Extension
IE Type
Ins.
Cause
Detach Type
0
0
Private Extension
VS
7.3.13 Detach Acknowledge

A Detach Acknowledge message shall be sent as a response to a Detach Notification message during Detach procedure.
Table 7.3.13-1: Information Elements in a Detach Acknowledge
Information
elements
Cause
Recovery
Private Extension
7.3.14
Condition / Comment
M
O
O
IE Type
Ins.
Cause
Recovery
Private Extension
0
0
VS
Change Notification Request
3GPP TS 23.401 [3] and 3GPP TS 23.060 [4] specify that if PGW has requested ECGI/TAI/CGI/SAI/RAI Change
Reporting and if MME/S4-SGSN supports the feature, then MME/S4-SGSN shall send the Change Notification Request
message on the S11/S4 interface to the SGW. If SGW supports the feature, the SGW forwards the message on the GTP
based S5/S8 interface to the PGW as part of location dependent charging related procedures.
The TEID value used in this message shall be zero.
Table 7.3.14-1: Information Element in Change Notification
Information
elements
IMSI
RAT Type
User Location
Information (ULI)
User CSG
Information (UCI)
PGW S5/S8 GTP-C
IP Address
LBI
Private Extension
Condition / Comment
IE Type
M
IMSI
M
RAT Type
C The SGSN shall include the User Location Information IE if
ULI
the MS is located in a RAT Type of GERAN, UTRAN or
GAN and shall include the CGI, SAI and/or RAI.
CO The MME shall include the User Location Information IE if
the UE is located in a RAT Type of E-UTRAN and shall
include the ECGI and/or TAI.
CO The SGSN/MME shall include the User CSG Information
UCI
IE if the MS is located in the CSG cell or the hybrid cell and
the P-GW decides to receive the CSG Information.
C This IE shall be sent on S4.
IP Address
CO This IE shall be sent on S11.
CO This IE, identifying the PDN connection, shall be sent by
EBI
the MME/SGSN on S11/S4.
If the SGW receives this IE, it shall forward it to the PGW
on S5/S8.
O Vendor or operator specific information
Private Extension
3GPP
Ins.
0
0
0
0
0
0
VS
Release 10
110
3GPP TS 29.274 V10.2.0 (2011-03)
7.3.15 Change Notification Response

The Change Notification Response message may be sent on the S11/S4 interface by the SGW to the MME/SGSN and is
sent on the S5/S8 interface by the PGW to the SGW as part of location dependent charging related procedures to
acknowledge the receipt of a Change Notification Request.
If SGW does not support the feature (see subclause 7.3.14 "Change Notification Request"), SGW may silently discard
Change Notification Request message from MME/SGSN. If the MME/ SGSN does not receive Change Notification
Response, the MME/SGSN may either send Change Notification Request to the same SGW next time UE location
changes, or not (marking SGW as not supporting the feature).
The Cause value indicates whether or not the Change Notification Request was received correctly. Possible Cause
values are specified in Table 8.4-1. Message specific cause values are:
-
"Request accepted".
"IMSI not known".
The TEID value used in this message shall be zero.

If the IMSI is unknown for the receiving GTP-C entity, then the message shall be silently discarded and no further
processing of the IEs shall continue.
If the MME/SGSN receives Change Notification Response containing a Cause value of "IMSI not known" and CS bit
set to 1, this indicates that the associated PDN connection does not exist within the PGW. The Change Reporting
mechanism shall be stopped in the receiving SGSN/MME for all Bearers of the associated PDN connection. The
SGSN/MME shall then initiate PDN disconnection for all of these PDN Connection .
If the PDN Connection associated of the Change Notification Request message received by the SGW does not exist
within the SGW, the SGW shall return Change Notification Response with the CS bit set to 0 to the MME/SGSN. The
Change Reporting mechanism shall be stopped in the receiving SGSN/MME for all Bearers of the associated PDN
connection, and the MME/SGSN shall then locally delete the PDN connection and release all associated resources.
If the location Change Reporting mechanism is to be stopped or modified for this subscriber in the SGSN/MME, then
the PGW shall include the Change Reporting Action IE in the message and shall set the value of the Action field
appropriately.
Table 7.3.15-1: Information Element in Change Notification Response
Information
elements
IMSI
Cause
Change Reporting
Action
CSG Information
Reporting Action
Private Extension
Condition / Comment
M
M
C This IE shall be included with the appropriate Action field If
the location Change Reporting mechanism is to be started
CO This IE shall be included with the appropriate Action field if
the location CSG Info reporting mechanism is to be started
O
IE Type
Ins.
IMSI
Cause
Change Reporting
Action
0
0
0
CSG Information
Reporting Action
Private Extension
VS
7.3.16 Relocation Cancel Request

A Relocation Cancel Request message shall be sent from the source MME/SGSN to the target MME/SGSN on
S3/S10/S16 interface as part of the Inter RAT handover Cancel procedure/S1 Based handover Cancel procedure and on
the S16 interface as part of the SRNS Relocation Cancel Procedure.Table 7.3.16-1 specifics the presence of the IEs in
the message.
3GPP
Release 10
111
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.16-1: Information Elements in Relocation Cancel Request

Information
elements
IMSI
RANAP Cause
Private Extension
Condition / Comment
IE Type
M
IMSI
C This IE shall be present in the case of SRNS relocation
F-Cause
cancel procedure. It shall contain the cause value received
from the source RNC in the Relocation Cancel message
received over the Iu interface.
O
Private Extension
Ins.
0
0
VS
7.3.17 Relocation Cancel Response

A Relocation Cancel Response message shall be sent as a response to a previous Relocation Cancel Request message
during the Inter RAT handover Cancel procedure/S1 Based handover Cancel procedure/SRNS Relocation Cancel
Procedure.
-
"IMSI not known".

Table 7.3.17-1: Information Elements in Relocation Cancel Response
Information
elements
Cause
Private Extension
Condition / Comment
M
O
IE Type
Ins.
Cause
Private Extension
0
VS
7.3.18 Configuration Transfer Tunnel

A Configuration Transfer Tunnel message shall be used to tunnel eNodeB Configuration Transfer messages from a
source MME to a target MME over the S10 interface. The purpose of the eNodeB Direct Configuration Transfer is to
transfer information from an eNodeB to another eNodeB in unacknowledged mode (see 3GPP TS 36.413 [10]).
Table 7.3.18-1: Information Elements in a Configuration Transfer Tunnel Message
Information
elements
E-UTRAN
Transparent
Container
Target eNodeB ID
Condition / Comment
IE Type
Ins.
M This IE shall contain the SON transfer IE.
F-Container
M This IE shall contain the ID of the target eNodeB
Target
Identification
7.3.19 RAN Information Relay

The RAN Information Relay message shall be sent on S3 interface between SGSN and MME to transfer the RAN
information received by an SGSN from BSS or RNS (or GERAN Iu mode) or by an MME from eNodeB. The
procedures are specified in 3GPP TS 23.401 [3].
This message shall also be sent on S16 interface to transfer the RAN information between GERAN or GERAN Iu mode
or UTRAN.
For handling of protocol errors the RAN Information Relay message is treated as a Response message.
3GPP
Release 10
112
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.3.19-1: Information Elements in a RAN Information Relay

Information
elements
BSS Container
RIM Routing Address
Private Extension
Condition / Comment
M All information elements from the RIM messages, starting

from and including the BSSGP "PDU type", shall be
contained within the BSS Container and forwarded to the
destination MME/SGSN in the RAN Information Relay
message.
C This IE shall be included if the RIM Routing Address
information is included in the message sent from the
source RAN node.
This IE identifies the destination RAN node where the RAN
Information needs to be relayed to. It contains:
the destination RNC Identity when the target is
GERAN Iu mode or UTRAN; or
-
the destination Cell Identity when the target is

GERAN; or
the Target eNodeB ID when the target is EUTRAN.
O None
IE Type
Ins.
F-Container
Target
Identification
Private Extension
VS
7.4 CS Fallback and SRVCC related messages

7.4.1 Suspend Notification
The Suspend Notification message shall be sent on the S11 interface by the MME to the SGW and on the S5/S8
interface by the SGW to the PGW as part of the 1xRTT CS fallback procedures in 3GPP TS 23.272 [21].
The Suspend Notification message shall be sent on the S3 interface by the SGSN to the MME, on the S11 interface by
the MME to the SGW, and on the S5/S8 interface by the SGW to the PGW as part of the SRVCC procedures in 3GPP
TS 23.216 [43] or the CS fallback from E-UTRAN access to UTRAN/GERAN CS domain access related procedures in
3GPP TS 23.272 [21].
The Suspend Notification message shall be sent on the S16 interface as per the inter-SGSN suspend procedures in 3GPP
TS 23.060 [35].
The Suspend Notification message shall be sent on the S16, the S4 and the S5/S8 interfaces as part of the SRVCC from
UTRAN (HSPA) to GERAN without DTM support procedure in 3GPP TS 23.216 [43].
The Suspend Notification message shall be sent on the S4 and the S5/S8 interfaces as part of the CS fallback from EUTRAN to GERAN CS domain related procedures in 3GPP TS 23.272 [21].
After receiving a Suspend Notification message, the SGW/PGW marks all the non-GBR bearers as suspended status.
The PGW should discard packets it receives for the suspended UE.
3GPP
Release 10
113
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.4.1-1: Information Element in Suspend Notification

Information
elements
Condition / Comment
IE Type
Ins.
IMSI
Routeing Area
Identity(RAI)
C This IE shall be included only on the S11 interface.

IMSI
0
C This IE shall be included only on the S3 interface.
ULI for RAI
0
See NOTE 1.
CO This IE shall be included on the S16 interface.
Linked Bearer Identity CO This IE shall be included on the S11/S4 interface to
EBI
0
(LBI)
indicate the default bearer associated with the PDN
connection.
Packet TMSI(P-TMSI) C This IE shall be included only on the S3 interface.
P-TMSI
0
See NOTE 1.
CO This IE shall be included on the S16 interface.
Private Extension
O
NOTE 1: The MME can not suspend the bearers after receving the Suspend Notification message from the
SGSN, the GUTI can not be derived from the P-TMSI and RAI pair as the P-TMSI Signature is not
included in the message. The MME shall still reply the Suspend Acknowledge to the SGSN. Suspend
procedure on MME, SGW and PGW are triggered by the S1 UE Context Release message sent from
the eNodeB to the MME. Refer to section 6.3 and section 7.4 in 3GPP TS 23.272 [21] for detail.
7.4.2 Suspend Acknowledge

The Suspend Acknowledge message shall be sent on the S11 interface by the SGW to the MME and on the S5/S8
interface by the PGW to the SGW as part of the 1xRTT CS fallback procedures in 3GPP TS 23.272 [21].
The Suspend Acknowledge message shall be sent on the S3 interface by the MME to the SGSN, on the S11 interface by
the SGW to the MME and on the S5/S8 interface by the PGW to SGW as part of the SRVCC procedures in 3GPP TS
23.216 [43] or the CS fallback from E-UTRAN access to UTRAN/GERAN CS domain access related procedures in
3GPP TS 23.272 [21].
The Suspend Acknowledge message shall be sent on the S16 interface as per the inter-SGSN suspend procedures in
3GPP TS 23.060 [35].
The Suspend Acknowledge message shall be sent on the S16, the S4 and the S5/S8 interfaces as part of the SRVCC
from UTRAN (HSPA) to GERAN without DTM support procedure in 3GPP TS 23.216 [43].
The Suspend Acknowledge message shall be sent on the S4 and the S5/S8 interfaces as part of the CS fallback from EUTRAN to GERAN CS domain related procedures in 3GPP TS 23.272 [21].
For backward compatibility, if the IMSI IE is missing in the Suspend Notification message that is received on the S11
interface, the cause value "Mandatory IE missing" shall be used.
Table 7.4.2-1: Information Element in Suspend Acknowledge
Information
elements
Cause
Private Extension
Condition / Comment
M
O
IE Type
Ins.
Cause
Private Extension
0
VS
7.4.3 Resume Notification

The Resume Notification message should be sent on the S11 interface by the MME to the SGW and forwarded on the
S5/S8 by the SGW to the PGW as part of the resume procedure returning back to E-UTRAN in the case of CS fallback
or SRVCC.
3GPP
Release 10
114
3GPP TS 29.274 V10.2.0 (2011-03)
The Resume Notification message should also be sent on the S4 interface by the SGSN to the SGW and forwarded on
the S5/S8 interface by the SGW to the PGW as part of the resume procedure returning from SRVCC to HSPA if there is
no Modify Bearer Request message sent to the SGW and PGW as specified in 3GPP TS 23.216 [43].
After receiving a Resume Notification message, the SGW/PGW clears suspended status for all the non-GBR bearers.
The PGW shall forward packets it receives for the UE.
Table 7.4.3-1: Information Element in Resume Notification
Information
elements
Condition / Comment
IMSI
M
Linked Bearer Identity CO This IE shall be included on the S11/S4 interface to
(LBI)
indicate the default bearer associated with the PDN
connection.
Private Extension
O
IE Type
Ins.
IMSI
EBI
0
0
Private Extension
VS
7.4.4 Resume Acknowledge

The Resume Acknowledge message should be sent on the S11 interface by the SGW to the MME and on the S5/S8 by
the PGW to the SGW as part of the resume procedure returning back to E-UTRAN in the case of CS fallback or
SRVCC.
The Resume Acknowledge message should also be sent on the S4 interface by the SGW to the SGSN and on the S5/S8
interface by the PGW to the SGW as part of the resume procedure returning from SRVCC to HSPA if there is no
Modify Bearer Request message sent to the SGW and PGW as specified in 3GPP TS 23.216 [43].
Table 7.4.4-1: Information Element in Resume Acknowledge
Information
elements
Cause
Private Extension
Condition / Comment
M
O
IE Type
Ins.
Cause
Private Extension
0
VS
7.4.5 CS Paging Indication

The CS Paging Indication shall be sent on the S3 interface by the MME to the associated SGSN when ISR is activated
as part of mobile terminated CS services. The MME gets the related information from SGsAP-PAGING-REQUEST
message as specified in 3GPP TS29.118 [21].Table 7.4.5-1 specifies the presence requirements and the conditions of the
IEs in the message.
Table 7.4.5-1: Information Element in CS Paging Indication
Information
elements
IMSI
VLR Name
TMSI
Location area
identifier
Global CN-Id
Channel needed
eMLPP Priority
Service Indicator
M
M
O
O
Private Extension
Condition / Comment
O
O
O
CO This IE shall be sent if the service type for the paging is
available.
O
3GPP
IE Type
Ins.
IMSI
FQDN
TMSI
ULI
0
0
0
0
Global CN-Id
Channel needed
eMLPP Priority
Service Indicator
0
0
0
0
Private Extension
VS
Release 10
115
3GPP TS 29.274 V10.2.0 (2011-03)
7.4.6 Alert MME Notification

An Alert MME Notification message shall be sent on the S3 interface by the MME to the associated SGSN as part of an
SGs Non-EPS alert procedure (see 3GPP TS 29.118 [22]) when ISR is activated, except under the conditions specified
in 3GPP TS 23.272 [21], to request to receive a notification when any activity from the UE is detected.
Table 7.4.6-1: Information Element in Alert MME Notification
Information
elements
Private Extension
Condition / Comment
IE Type
Ins.
Private Extension
VS
7.4.7 Alert MME Acknowledge

An Alert MME Acknowledge message shall be sent as a response to an Alert MME Notification message.
NOTE:
An SGSN implemented according to an earlier version of the specification will silently discard the Alert
MME Notification message. An MME which does not receive an Alert MME Acknowledge message may
not send further Alert MME Notification message to this SGSN.
Table 7.4.7-1: Information Elements in Alert MME Acknowledge
Information
elements
Cause
Private Extension
Condition / Comment
M
O
IE Type
Ins.
Cause
Private Extension
0
VS
7.4.8 UE Activity Notification

A UE Activity Notification message shall be sent on the S3 interface by the SGSN to the associated MME as part of an
SGs Non-EPS alert procedure (see 3GPP TS 29.118 [22]) when ISR is activated, except under the conditions specified
in 3GPP TS 23.272 [21], to indicate that activity from a UE has been detected. Table 7.4.8-1 specifies the presence
requirements and the conditions of the IEs in the message.
Table 7.4.8-1: Information Element in UE Activity Notification
Information
elements
Private Extension
Condition / Comment
IE Type
Ins.
Private Extension
VS
7.4.9 UE Activity Acknowledge

A UE Activity Acknowledge message shall be sent as a response to a UE Activity Notification message.
Table 7.4.9-1 specifics the presence requirements and the conditions of the IEs in the message.
3GPP
Release 10
116
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.4.z-1: Information Elements in UE Activity Acknowledge

Information
elements
Cause
Private Extension
Condition / Comment
M
O
IE Type
Ins.
Cause
Private Extension
0
VS
7.5 Non-3GPP access related messages

7.5.1 Create Forwarding Tunnel Request
A Create Forwarding Tunnel Request message shall be sent by a MME to a Serving GW as a part of the MME
configures resources for indirect data forwarding during active handover procedure from E-UTRAN to CDMA 2000
HRPD access.
Table 7.5.1-1: Information Elements in a Create Forwarding Tunnel Request
Information
elements
S103 PDN Data
Forwarding Info
Private Extension
Condition / Comment
IE Type
M The MME shall include the forwarding Infomation for all

S103PDF
PDN connections of the UE requesting data forwarding
towards the HSGW in the message as S103 PDN Data
Forwarding Info information elements. For each of those
PDN Connections, an IE with the same type and instance
value shall be included.
The Serving GW shall forward downlink data to the HSGW
via the GRE tunnel identified by the HSGW Address and
HSGW GRE Key included in this information element when
it receives downlink data forwarded from the eNodeB
belonging to the corresponding EPS bearers of the PDN
connection.
O
Private Extension
Ins.
0
VS
7.5.2 Create Forwarding Tunnel Response

A Create Forwarding Tunnel Response message shall be sent by a Serving GW to a MME as a response to a Create
Forwarding Tunnel Request message.
The Cause value indicates if Data Forwarding Resources has been created in the Serving GW or not. Data Forwarding
Resources have not been created in the Serving GW if the Cause differs from "Request accepted". Possible Cause
values are specified in Table 8.4-1.
Only the Cause IE shall be included in the response if the Cause IE contains another value than "Request accepted".
3GPP
Release 10
117
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.5.2-1: Information Elements in a Create Forwarding Tunnel Response

Information
elements
Cause
S1-U Data
Forwarding Info
Private Extension
Condition / Comment
IE Type
M
Cause
C S1-U Data Forwarding Info shall be included in the
S1UDF
message if the Cause contains the value "Request
accepted". For each EPS bearer requesting data
forwarding which is included in the S103 PDN Data
Forwarding Info fields of corresponding Create Forwarding
Tunnel Request message, the Serving GW shall assign a
Serving GW S1-U Address and Serving GW S1-U TEID
pair and included it in the response message as S1-U Data
Forwarding Info information element. For each of those
EPS bearers, an IE with the same type and instance value
shall be included.
The eNodeB shall forward downlink data of the EPS bearer
to the Serving GW via the GTP-U tunnel identified by the
Serving GW S1-U Address and Serving GW S1-U TEID.
O
Private Extension
Ins.
0
0
VS
7.6 Reliable Delivery of Signalling Messages

Retransmission requirements in the current subclause do not apply to the Initial messages that do not have Triggered
messages.
Reliable delivery in GTPv2 messages is accomplished by retransmission of these messages. A message shall be
retransmitted if and only if a reply is expected for that message and the reply has not yet been received. There may be
limits placed on the total number of retransmissions to avoid network overload.
Initial messages and their Triggered messages, as well as Triggered messages and their Triggered Reply messages are
matched based on the Sequence Number and the IP address and port rules in subclause 4.2 "Protocol stack". Therefore,
an Initial message and its Triggered message, as well as a Triggered message and its Triggered Reply message shall
have the same sequence Number. A retransmitted GTPv2 message (an Initial or a Triggered) has the exact same GTPv2
message content, including the GTP header, UDP ports, source and destination IP addresses as the originally transmitted
GTPv2 message.
For each triplet of local IP address, local UDP port and remote peer's IP address a GTP entity maintains a sending queue
with signalling messages to be sent to that peer. The message at the front of the queue shall be sent with a Sequence
Number, and if the message has an expected reply, it shall be held in a list until a reply is received or until the GTP
entity has ceased retransmission of that message. The Sequence Number shall be unique for each outstanding Initial
message sourced from the same IP/UDP endpoint. A node running GTP may have several outstanding messages waiting
for replies. Not counting retransmissions, a single GTP message with an expected reply shall be answered with a single
GTP reply, regardless whether it is per UE, per APN, or per bearer
A piggybacked initial message (such as a Create Bearer Request message or Modify Bearer Request message) shall
contain a Sequence Number that is assigned by sending GTP entity and the message shall be held in a list until a
response is received. The response message to a piggybacked initial message may arrive without piggybacking (e.g.,
Create Bearer Response at PGW).
The Sequence Number in the GTP header of the triggered response message shall be copied from the respective request
message.
If a request message (e.g., Create Session Request) triggers piggybacking (i.e., Create Bearer Request piggybacked on
Create Session Response), re-transmission of the request message shall also trigger piggybacking. A Sequence Number
used for a Command message and its Triggered messages, as well as respective Triggered Reply message shall be the
same as in the Command message and shall have the most significant bit set to 1. This setting of the most significant bit
of the Sequence Number is done to avoid potential clashes between the Sequence Number selected for a Command
message, and the Sequence Number selected by a GTPv2 peer for a Request message, which was not triggered by a
Command message.
A Sequence Number used for a Request message, which was not triggered by a Command message shall have the most
significant bit set to 0.
3GPP
Release 10
118
3GPP TS 29.274 V10.2.0 (2011-03)
A timer, denoted T3-RESPONSE, shall be started when a signalling message (for which a reply is expected) is sent. A
signalling message or the triggered message has probably been lost if a reply has not been received before the T3RESPONSE timer expires.
Once the T3-RESPONSE timer expires, the message corresponding to the T3-RESPONSE timer is then retransmitted if
the total number of retry attempts is less than N3-REQUESTS times. The expiry of the timer for piggybacked request
messages shall result in re-transmission of the original IP/UDP packet containing both the triggered response message
and the piggybacked initial message. T3-RESPONSE timer and N3-REQUESTS counter setting is implementation
dependent. That is, the timers and counters may be configurable per procedure. Multileg communications (e.g. Create
Session Requests and Responses) however require longer timer values and possibly a higher number of retransmission
attempts compared to single leg communication.
All received GTPv2 messages with an expected reply shall be replied to and all reply messages associated with a certain
message shall always include the same information. Duplicated reply messages shall be discarded by the receiver unless
the reply needs a reply. A received reply message without a matching outstanding message that is waiting for a reply
should be discarded.
If a GTPv2 node is not successful with the transfer of a non-Echo signalling message, e.g. a Create Bearer Request
message, it shall inform the upper layer of the unsuccessful transfer so that the controlling upper entity may take the
necessary measures.
7.7 Error Handling

7.7.0 Handling Piggybacked Messages
For piggybacked initial messages, the following general rule shall apply: the triggered response message carrying the
piggybacked message shall be processed first, according to the following sections. Subsequently, the piggybacked initial
message shall be processed independently. If the processing of dedicated bearer activation message results in an error,
this shall not affect the default bearer establishment. If the default bearer establishment fails, the dedicated bearer
activation related message shall be discarded.
7.7.1 Protocol Errors

A protocol error is defined as a message or an Information Element received from a peer entity with unknown type, or if
it is unexpected, or if it has an erroneous content.
The term silently discarded is used in the following subclauses to mean that the receiving GTP entity's implementation
shall discard such a message without further processing, or that the receiving GTP entity discards such an IE and
continues processing the message. The conditions for the receiving GTP entity to silently discard an IE are specified in
the subsequent subclauses.
The handling of unknown, unexpected or erroneous GTP messages and IEs shall provide for the forward compatibility
of GTP. Therefore, the sending GTP entity shall be able to safely include in a message a new conditional-optional or an
optional IE. Such an IE may also have a new type value. Any legacy receiving GTP entity shall, however, silently
discard such an IE and continue processing the message.
If a protocol error is detected by the receiving GTP entity, it should log the event including the erroneous message and
may include the error in a statistical counter.
An information element with "Mandatory" in the "Presence requirement" column of a message definition shall always
be present in that message.
An information element with "Conditional" in the "Presence requirement" column of a message definition shall be sent
when the conditions detailed in the "Presence requirement" are met.
The Version Not Supported Indication message shall be considered as a Triggered message as specified in subclause
4.2.5 "Messages with GTPv2 defined replies: Classification of Initial and Triggered Messages".
The receiving GTP entity shall apply the error handling specified in the subsequent subclauses in decreasing priority.
If the received erroneous message is a reply to an outstanding GTP message, the GTP transaction layer shall stop
retransmissions and notify the GTP application layer of the error even if the reply is silently discarded.
3GPP
Release 10
119
3GPP TS 29.274 V10.2.0 (2011-03)
7.7.2 Different GTP Versions

If a GTP entity receives a message of an unsupported GTP version, it shall return a Version Not Supported Indication
message and discard the received message.
7.7.3 GTP Message of Invalid Length

If a GTP entity receives a message, which is too short to contain the respective GTPv2 header, the GTP-PDU shall be
silently discarded.
Apart from a piggybacked GTP message, if a GTP entity receives a Request message within an IP/UDP packet of a
length that is inconsistent with the value specified in the Length field of the GTP header, then the receiving GTP entity
should log the error and shall send the Response message with Cause IE value set to "Invalid Length".
Apart from a piggybacked GTP message, if a GTP entity receives a Response message within an IP/UDP packet of a
length that is inconsistent with the value specified in the Length field of the GTP header, then the receiving GTP entity
should log the error and shall silently discard the message.
If a GTP entity receives two GTP messages (triggered response message and a piggybacked initial message) within an
IP/UDP packet of a length that is inconsistent with the total length of the two concatenated messages as indicated by
Length fields of the GTP headers, then the receiving GTP entity should log the error and return an appropriate Response
message with Cause IE value set to "Invalid overall length of the triggered response message and a piggybacked initial
message". That is:
-
for a Create Session Response message together with a piggybacked Create Bearer Request message, a Create
Bearer Response message should be returned with the above Cause value.
for a Create Bearer Response message together with a piggybacked Modify Bearer Request message, a Modify
Bearer Response message should be returned with the above Cause value.
7.7.4 Unknown GTP Message

If a GTP entity receives a message with an unknown Message Type value, it shall silently discard the message.
7.7.5 Unexpected GTP Message

If a GTP entity receives an unexpected initial message (see subclause 4.2 "Protocol stack"), it shall be silently discard
the message and shall log an error.
If a GTP entity receives an unexpected triggered message (see subclause 4.2 "Protocol stack"), it shall discard the
message and may log an error.
7.7.6 Missing Information Elements

A GTP entity shall check if all mandatory IEs are present in the received Request message. If one or more mandatory
information elements are missing, the GTP entity should log the error and shall send a Response message with Cause IE
value set to "Mandatory IE missing" together with the type and instance of the missing mandatory IE.
If a GTP entity receives a Response message with Cause IE value set to "Mandatory IE missing", it shall notify its
upper layer.
A GTP entity shall check if all mandatory IEs are present in the received Response message. If one or more mandatory
information elements are missing, the GTP entity shall notify the upper layer and should log the error.
A GTP entity shall check if conditional information elements are present in the received message, if possible (i.e. if the
receiving entity has sufficient information available to check if the respective conditions were met).
When possible, a GTP entity shall check if all conditional IEs are present in the received Request message. If one or
more conditional information elements are missing, GTP entity should log the error and shall send a Response message
with Cause IE value set to "Conditional IE missing" together with the type and instance of the missing conditional IE.
3GPP
Release 10
120
3GPP TS 29.274 V10.2.0 (2011-03)
When possible, a GTP entity shall check if all conditional IEs are present in the received Response message. If one or
more conditional information elements are missing, GTP entity shall notify the upper layer and should log the error.
If the Indication IE is applicable for the message as a conditional IE and if it is not present, the GTP entity shall not
reject the message unless there are other reasons to reject the message.
If the Indication IE is applicable for the message as conditional IE and if it is present with the value of all the applicable
flags set to "0", the GTP entity shall not reject the message unless there are other reasons to reject the message.
Absence of an optional information element shall not trigger any of the error handling processes.
7.7.7 Invalid Length Information Element

An information element has invalid length when the actual length of the IE is different from the value of the Length
field in the IE header.
If a GTP message contains more than one information elements and one or more of them have invalid length, the
receiving GTP entity can detect which of the IEs have invalid length only in the following cases:
-
If the Length value in the IE header is greater than the overall length of the message;
If the invalid length IE is the last one in the message.
If a receiving GTP entity detects information element with invalid length in a Request message, it shall send an
appropriate error response with Cause IE value set to "Invalid length" together with the type and instance of the
offending IE.
Other Length field handling cases are specified below:
-
If the received value of the Length field and the actual length of the fixed length IE are consistent, but the length
is greater than that expected by the fixed number of octets, then the extra octets shall be discarded.
If the received value of the Length field and the actual length of the fixed length IE are consistent, but the length
is less than that expected by the fixed number of octets, this shall be considered an error, IE shall be discarded
and if the IE was received as a Mandatory IE or a verifiable Conditional IE in a Request message, an appropriate
error response with Cause IE value set to "Invalid length" together with the type and instance of the offending IE
shall be returned to the sender.
If the received value of the Length field and the actual length of the extendable length IE are consistent, but the
length is greater than that expected by the fixed number of octets preceding the extended field(s), then the extra
unknown octets shall be discarded.
If the received value of the Length field and the actual length of the extendable length IE are consistent, but the
length is less than that expected by the fixed number of octets preceding the extended field(s), this shall be
considered an error, IE shall be discarded and if the IE was received as a Mandatory IE or a verifiable
Conditional IE in a Request message, an appropriate error response with Cause IE value set to "Invalid length"
together with the type and instance of the offending IE shall be returned to the sender.
7.7.8 Semantically incorrect Information Element

The receiver of a GTP signalling message Request including a mandatory or a verifiable conditional information
element with a semantically invalid Value shall discard the request, should log the error, and shall send a response with
Cause set to "Mandatory IE incorrect" together with a type and instance of the offending IE.
The receiver of a GTP signalling message Response including a mandatory or a verifiable conditional information
element with a semantically invalid Value shall notify the upper layer that a message with this sequence number has
been received and should log the error.
If a GTP entity receives an information element with a value which is shown as reserved, it shall treat that information
element as invalid and should log the error. If the invalid IE is received in a Request, and it is a mandatory IE or a
verifiable conditional IE, the GTP entity shall send a response with Cause set to "Mandatory IE incorrect " together with
a type and instance of the offending IE.
3GPP
Release 10
121
3GPP TS 29.274 V10.2.0 (2011-03)
The principle is: the use of reserved values invokes error handling; the use of spare values can be silently discarded and
so in the case of IEs with spare values used, processing shall be continued ignoring the spare values.
The receiver of a GTP signalling message including an optional information element with a Value that is not in the
range defined for this information element value shall discard this IE, but shall treat the rest of the message as if this IE
was absent and continue processing. The receiver shall not check the content of an information element field that is
defined as 'spare".
All semantically incorrect optional information elements in a GTP signalling message shall be treated as not present in
the message.
7.7.9 Unknown or unexpected Information Element

The receiver of a GTP message including an unexpected information element with known Type value, but with the
instance value that is not defined for this message shall discard the IE and log an error. The receiver shall process the
message.
An information element with a Type value which is defined in section 8.1 of the present specification but whose
Instance Value is not expected in the received GTP signalling message according to the grammar defined in section 7 of
the present specification shall be silently discarded (skipped) and the rest of the message processed as if this
information element was not present.
NOTE:
An Information Element in an encoded GTPv2 message or grouped IE is identified by the pair of IE Type
and Instance value.
7.7.10 Repeated Information Elements

An Information Element is repeated if there is more than one IE with the same IE Type and Instance in the scope of the
GTP message (scope of the grouped IE). Such an IE is a member in a list.
If an information element is repeated in a GTP signalling message in which repetition of the information element is not
specified, only the contents of the information element appearing first shall be handled and all subsequent repetitions of
the information element shall be ignored. When repetition of information elements is specified, only the contents of
specified repeated information elements shall be handled and all subsequent repetitions of the information element shall
be ignored.
7.7.11 TFT Error Handling

TFT related error handling for EUTRAN is specified in 3GPP TS 24.301 [23] and for UTRAN/GERAN in 3GPP TS
24.008 [5].
7.8 Path Failure

Restoration and Recovery procedures are specified generally in 3GPP TS 23.007 [17] and a path failure may initiate
recovery procedures.
Path failure is detected only by using Echo Request / Response messages in the following way. A peer's IP address
specific counter shall be reset each time an Echo Response message is received from that peer's IP address and
incremented when the T3-RESPONSE timer expires for an Echo Request message sent to that peer's IP address. The
path shall be considered to be down if the counter exceeds N3-REQUESTS. In this case, the GTP entity may notify the
Operation and Maintenance network element. GTP shall also notify the upper layer of the path failure, so that PDN
connections or PDP contexts associated with this peer's IP address may be deleted.
7.9
Restoration and Recovery
7.9.0 General
Restoration and Recovery procedures are specified in 3GPP TS 23.007 [17].
3GPP
Release 10
122
3GPP TS 29.274 V10.2.0 (2011-03)
7.9.1 Delete PDN Connection Set Request

This message may be sent on the S2b, S5, S8, or S11 interfaces as specified in 3GPP TS 23.007 [17].
Table 7.9.1-1: Information Elements in a Delete PDN Connection Set Request
Information
elements
MME-FQ-CSID
SGW-FQ-CSID
PGW-FQ-CSID
ePDG-FQ-CSID
Private Extension
Condition / Comment
IE Type
C This IE shall be included when a MME reports a partial

FQ-CSID
fault according to the requirements in 3GPP TS 23.007
[17]. More than one FQ-CSID may appear.
C This IE shall be included when a SGW reports a partial
FQ-CSID
C Shall be included when a PGW reports a partial fault. More
FQ-CSID
than one FQ-CSID may appear
C This IE shall be included when an ePDG reports a partial
FQ-CSID
O NoneThis IE may be sent on the S2b, S5, S8 and S11
Private Extension
interfaces.
Ins.
0
1
2
3
VS
TEID of 0 shall be used for the Delete PDN Connection Set Request.
Only one type of FQ-CSID shall be included in each Delete PDN Connection Set Request, A mix of different types,
such as SGW-FQ-CSID and PGW-FQ-CSID shall not be used. A combined node, such as a collocated PGW/SGW, shall
send separate Delete PDN Connection Set Request for the PGW role and one for the SGW role if a partial fault impacts
more than one role.
7.9.2 Delete PDN Connection Set Response

This message is sent as a response to the Delete PDN Connection Set Request.
Table 7.9.2: Information Elements in a Delete PDN Connection Set Response
Information
elements
Cause
Private Extension
Condition / Comment
M
O This IE may be sent on the S2b, S5, S8 and S11
interfaces.
IE Type
Ins.
Cause
Private Extension
0
VS
TEID of 0 shall be used for the Delete PDN Connection Set Response.
The following Cause values are defined:
-
"Request Accepted"
"Request rejected"
"System failure".
"Mandatory IE incorrect".
"Conditional IE missing".
"Invalid message format".
"Request Accepted" indicates the receiving node was capable of storing a CSID value for each PDN connection for the
type of node (MME,SGW,PGW or ePDG) in the Delete PDN Connection Set Request and has marked, or will mark
immediately, the PDN connections for deletion as per 3GPP TS 23.007 [17]. "Request Accepted" shall be returned even
if there are no PDN connections that match.
3GPP
Release 10
123
3GPP TS 29.274 V10.2.0 (2011-03)
"Request rejected" shall be used when the receiver of the Delete PDN Connection Set Request is not capable of storing
at least one CSID value per PDN connection for the type of node (MME, SGW, PGW or ePDG) received in the Delete
PDN Connection Set Request.
The SGW shall respond to the Delete PDN Connection Set Request independently, i.e. without waiting for replies.
7.9.3 Update PDN Connection Set Request

The SGW shall send this message to the PGW on S5/S8 according to the requirements in TS 23.007 [17].
Table 7.9.3-1: Information Elements in a Update PDN Connection Set Request
Information
elements
MME-FQ-CSID
SGW-FQ-CSID
Private Extension
Condition / Comment
C This IE shall be included for MME relocation without SGW

relocation per 3GPP TS 23.007 [17].
O
IE Type
Ins.
FQ-CSID
FQ-CSID
Private Extension
VS
7.9.4 Update PDN Connection Set Response

This message is sent by the PGW to the SGW on S5/S8 in response to the Update PDN Connection Set Request
message.
Table 7.9.4-1: Information Elements in a Update PDN Connection Set Response
Information
elements
Cause
PGW-FQ-CSID
Private Extension
Condition / Comment
M
O
IE Type
Ins.
Cause
FQ-CSID
0
0
Private Extension
VS
The following Cause values are defined:

-
"Request accepted"
"Request rejected"
"System failure".
"Mandatory IE missing".
"Invalid message format".
7.9.5 PGW Restart Notification

The direction of this message shall be from SGW to MME/S4-SGSN (see Table 6.1-1).
If both the SGW and the MME/S4-SGSN support the PRN feature (see subclause 8.83), a PGW Restart Notification
shall be sent when the SGW detect the peer PGW has restarted as specified in 3GPP TS 23.007 [17].
Table 7.9.5-1 specifies the presence of IEs in this message.
3GPP
Release 10
124
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.9.5-1: Information Elements in PGW Restart Notification

Information
elements
PGW S5/S8 IP
Address for Control
Plane or PMIP
SGW S11/S4 IP
Address for Control
Plane
Private Extension
Condition / Comment
IE Type
Ins.
IP Address
IP Address
Private Extension
VS
7.9.6 PGW Restart Notification Acknowledge

The PGW Restart Notification Acknowledge shall be sent as a response of PGW Restart Notification to indicate that the
MME/S4-SGSN deletes all the relevant PDN connections as specified in 3GPP TS 23.007 [17] if the Cause IE includes
an acceptance cause.
Table 7.9.6-1: Information Elements in PGW Restart Notification Acknowledge
Information
elements
Cause
Private Extension
Condition / Comment
M
O
IE Type
Ins.
Cause
Private Extension
0
VS
7.10 Fallback to GTPv1 mechanism

An EPC entity shall assume that each GTP processing node that it is about to communicate with is GTPv2 capable.
Before the first GTP tunnel is setup for a given UE/node, the EPC node shall always send a version 2 (GTPv2) message
to a peer node. As an exception, during an inter-SGSN handover, even if the target SGSN is GTPv2 capable, the source
SGSN shall send a GTPv1 message "Forward Relocation Request" to the target SGSN if the PDP Context(s) for this UE
were established to GGSN(s).
A GTPv2 entity shall fallback to GTPv1 only if eithera "Version Not Supported" message in GTPv1 format as specified
in 3GPP TS 29.060 [4] is received from the peer node; This indicates that the peer GTP entity does not support GTPv2,
or if a GTPv2 message is received with Cause value "Fallback to GTPv1".
If a GTPv1 "Version Not Supported" message in received, a GTPv2 entity may fallback to GTPv1. 3GPP TS 23.401 [3]
(see annex D) and 3GPP TS 23.060 [35] specify GTP version usage during the mobility between a UTRAN/GERAN
and an E-UTRAN.
A GTPv2 entity may receive a GTPv2 message with a Cause value "Fallback to GTPv1" in the following cases:
-
an S4 SGSN receives the Cause code "Fallback to GTPv1" in a GTPv2 Context Response message over S16
interface. When an UE has activated a PDP context via S4 SGSN to GGSN and inter-SGSN RAU is underway,
the old S4 SGSN shall include the Cause value "Fallback to GTPv1" in a GTPv2 Context Response message
over S16 interface.In this case, the new S4 SGSN shall abort the ongoing GTPv2 procedure and send a GTPv1
"SGSN Context Request" message to the old S4 SGSN. The fallback to GTPv1 is performed only for this UE in
the current procedure.
An MME receives the Cause code "Fallback to GTPv1" in a GTPv2 Context Response message over the S3 interface.
When an UE has active PDP context(s) via an S4 SGSN and a TAU is underway, the old S4 SGSN may include the
Cause value "Fallback to GTPv1" in a GTPv2 Context Response message over the S3 interface. In this case, the MME
shall abort the ongoing GTPv2 procedure and should send a GTPv1 "SGSN Context Request" message to the old S4
SGSN. The fallback to GTPv1 is performed only for this UE.
Fallback to GTPv1 shall not occur on already established GTP tunnels without change of the peer nodes of the
communication bearer.
3GPP
Release 10
125
3GPP TS 29.274 V10.2.0 (2011-03)
If a GTPv2 entity does not support GTPv1 and receives a GTPv1 message, it shall silently discard the message.
7.11 Fallback to GTPv0

Fallback from GTPv2 to GTPv0 shall not be supported. Therefore, GTPv2 entity should not listen to the well-known
GTPv0 port 3386. If GTPv2 entity listens to the GTPv0 port, the entity shall silently discard any received GTPv0
message.
7.12 Trace Management Messages

7.12.1 Trace Session Activation
The Trace Session Activation message shall be sent on S11/S4 by the MME/SGSN to the SGW, on S2b by the ePDG to
the PGW, and on S5/S8 by the SGW to the PGW when session trace is activated for a particular IMSI or IMEI for a UE
that is attached and active or attached and idle.
Table 7.12.1-1: Information Elements in a Trace Session Activation
Information
elements
IMSI
Trace Information
ME Identity (MEI)
Condition / Comment
M
M
C The MME shall include the ME Identity (MEI) IE, if
available.
IE Type
Ins.
IMSI
Trace Information
MEI
0
0
0
7.12.2 Trace Session Deactivation

The Trace Session Deactivation message shall be sent on S11/S4 by the MME/SGSN to the SGW, on S2b by the ePDG
to the PGW, and on S5/S8 by the SGW to the PGW when session trace is deactivated for a particular IMSI or IMEI for
a UE that is attached and active or attached and idle.
Table 7.12.2-1: Information Elements in a Trace Session Deactivation
Information
elements
Trace Reference
Condition / Comment
IE Type
Ins.
Trace Reference
7.13 MBMS Messages

7.13.1 MBMS Session Start Request
The MBMS Session Start Request message shall be sent on the Sm/Sn interface by the MBMS GW to the MME/SGSN
3GPP
Release 10
126
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.13.1-1: Information Elements in a MBMS Session Start Request

Information
elements
Sender F-TEID for
Control Plane
Temporary Mobile
Group Identity (TMGI)
MBMS Session
Duration
MBMS Service Area
MBMS Session
Identifier
MBMS Flow Identifier
QoS profile
MBMS IP Multicast
Distribution
Condition / Comment
IE Type
Ins.
F-TEID
TMGI
MBMS Session
Duration
MBMS Service
Area
MBMS Session
Identifier
MBMS Flow
Identifier
Bearer QoS
MBMS IP
Multicast
Distribution
Recovery
M
C This IE shall be forwarded to MME/SGSN if it is provided
by the BM-SC.
by the BM-SC.
M See NOTE 1.
M
Recovery
0
0
0
0
0

0
time.
MBMS Time to Data CO This IE shall be forwarded to MME/SGSN if it is received
MBMS Time to
0
Transfer
from the BM-SC.
Data Transfer
Private Extension
O
NOTE 1: The MME shall ignore the ARP in this IE as specified in Section 6.3.2 of 3GPP TS 23.246 [37]. The
uplink GBR and uplink MBR shall be ignored by MME/SGSN as specified in Section 20.5 of 3GPP
TS 29.061 [38].
7.13.2 MBMS Session Start Response

The MBMS Session Start Response message shall be sent as a response to the MBMS Session Start Request message
on the Sm/Sn interface by the MME/SGSN to the MBMS GW.
Table 7.13.2-1: Information Elements in a MBMS Session Start Response
Information
elements
Cause
Sender F-TEID for
Control Plane
MBMS Distribution
Acknowledge
Sn-U SGSN F-TEID
Recovery
Private Extension
Condition / Comment
M
M
C This IE shall be included on the Sn interface.
IE Type
Ins.
Cause
F-TEID
0
0
MBMS
Distribution
Acknowledge
F-TEID
C This IE shall be included on the Sn interface if some RNCs

have not accepted IP multicast distribution.
Recovery
time.
O
Private Extension
7.13.3 MBMS Session Update Request

The MBMS Session Update Request message shall be sent on the Sm/Sn interface by the MBMS GW to the
MME/SGSN as specified in 3GPP TS 23.246 [37].
3GPP
1
0
VS
Release 10
127
3GPP TS 29.274 V10.2.0 (2011-03)
Table 7.13.3-1: Information Elements in a MBMS Session Update Request

Information
elements
MBMS Service Area
Temporary Mobile
Group Identity (TMGI)
Sender F-TEID for
Control Plane
MBMS Session
Duration
QoS profile
MBMS Session
Identifier
Condition / Comment

by the BM-SC.
M
O
IE Type
Ins.
MBMS Service
Area
TMGI
F-TEID
MBMS Session
0
Duration
M See NOTE 1.
Bearer QoS
0
MBMS Session
0
by the BM-SC.
Identifier
MBMS Flow
0
by the BM-SC.
Identifier
MBMS Time to Data CO This IE shall be forwarded to MME/SGSN if it is provided
MBMS Time to
0
Transfer
by the BM-SC.
Data Transfer
Private Extension
O
NOTE 1: The MME shall ignore the ARP in this IE as specified in Section 6.3.2 of 3GPP TS 23.246 [37]. The
uplink GBR and uplink MBR shall be ignored by MME/SGSN as specified in Section 20.5 of 3GPP
TS 29.061 [38].
7.13.4 MBMS Session Update Response

The MBMS Session Update Response message shall be sent as a response to the MBMS Session Update Request
message on the Sm/Sn interface by the MME/SGSN to the MBMS GW.
Table 7.13.4-1: Information Elements in a MBMS Session Update Response
Information
elements
Cause
MBMS Distribution
Acknowledge
Sn-U SGSN F-TEID
Recovery
Private Extension
Condition / Comment
M
C This IE shall be included on the Sn interface if service area
is changed.
C This IE shall be included on the Sn interface if any of the
newly added RNCs have not accepted IP multicast
distribution.
time.
O
IE Type
Ins.
Cause
MBMS
Distribution
Acknowledge
F-TEID
0
0
Recovery
Private Extension
VS
7.13.5 MBMS Session Stop Request

The MBMS Session Stop Request message shall be sent on the Sm/Sn interface by the MBMS GW to the MME/SGSN
Table 7.13.5-1: Information Elements in a MBMS Session Stop Request
Info specified in
Table 8.4-1.rmation
elements
Private Extension
Condition / Comment
IE Type

MBMS Flow
by the BM-SC.
Identifier
O
Private Extension
3GPP
Ins.
0
VS
Release 10
128
3GPP TS 29.274 V10.2.0 (2011-03)
7.13.6 MBMS Session Stop Response

The MBMS Session Stop Response message shall be sent as a response to the MBMS Session Stop Request message on
the Sm/Sn interface by the MME/SGSN to the MBMS GW.
Possible Cause values are are specified in Table 8.4-1.
Table 7.13.6-1: Information Elements in a MBMS Session Stop Response
Information
elements
Cause
Private Extension
Condition / Comment
M
O
IE Type
Ins.
Cause
Private Extension
0
VS
GTP-C Information Elements
8.1 Information Element Types

A GTP control plane (signalling) message may contain several information elements. In order to have forward
compatible type definitions for the GTPv2 information elements, all of them shall be TLIV (Type, Length, Instance,
Value) coded. GTPv2 information element type values are specified in the Table 8.1-1. The last column of this table
indicates whether the information element is:
-
Fixed Length: the IE has a fixed set of fields, and a fixed number of octets.
Variable Length: the IE has a fixed set of fields, and has a variable number of octets.
For example, the last octets may be numbered similar to "5 to (n+4)". In this example, if the value of the length
field, n, is 0, then the last field is not present.
Extendable: the IE has a variable number of fields, and has a variable number of octets.
The last fields are typically specified with the statement: "These octet(s) is/are present only if explicitly
specified". The legacy receiving entity shall ignore the unknown octets.
In order to improve the efficiency of troubleshooting, it is recommended that the information elements should be
arranged in the signalling messages as well as in the grouped IEs, according to the order the information elements are
listed in the message definition table or grouped IE definition table in section 7. However the receiving entity shall be
prepared to handle the messages with information elements in any order.
Within information elements, certain fields may be described as spare. These bits shall be transmitted with the value set
to 0. To allow for future features, the receiver shall not evaluate these bits. GTPv2-C information elements that have
similar semantics in GTPv1-C shall be converted into GTPv1-C format, as specified in TS 29.060 [4], before sending
them to a pre-R8 GSN.
3GPP
Release 10
129
3GPP TS 29.274 V10.2.0 (2011-03)
Table 8.1-1: Information Element types for GTPv2
3GPP
Release 10
IE Type value
(Decimal)
0
1
2
3
4 to 50
51 to 70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
130
Information elements
Reserved
International Mobile Subscriber Identity (IMSI)
Cause
Recovery (Restart Counter)
Reserved for S101 interface
Reserved for Sv interface
Access Point Name (APN)
Aggregate Maximum Bit Rate (AMBR)
EPS Bearer ID (EBI)
IP Address
Mobile Equipment Identity (MEI)
MSISDN
Indication
Protocol Configuration Options (PCO)
PDN Address Allocation (PAA)
Bearer Level Quality of Service (Bearer QoS)
Flow Quality of Service (Flow QoS)
RAT Type
Serving Network
EPS Bearer Level Traffic Flow Template (Bearer TFT)
Traffic Aggregation Description (TAD)
User Location Information (ULI)
Fully Qualified Tunnel Endpoint Identifier (F-TEID)
TMSI
Global CN-Id
S103 PDN Data Forwarding Info (S103PDF)
S1-U Data Forwarding Info (S1UDF)
Delay Value
Bearer Context
Charging ID
Charging Characteristics
Trace Information
Bearer Flags
Reserved
PDN Type
Procedure Transaction ID
DRX Parameter
Reserved
MM Context (GSM Key and Triplets)
MM Context (UMTS Key, Used Cipher and Quintuplets)
MM Context (GSM Key, Used Cipher and Quintuplets)
MM Context (UMTS Key and Quintuplets)
MM Context (EPS Security Context, Quadruplets and Quintuplets)
MM Context (UMTS Key, Quadruplets and Quintuplets)
PDN Connection
PDU Numbers
P-TMSI
P-TMSI Signature
Hop Counter
UE Time Zone
Trace Reference
Complete Request Message
GUTI
F-Container
F-Cause
Selected PLMN ID
Reserved
Packet Flow ID
RAB Context
Source RNC PDCP Context Info
UDP Source Port Number
APN Restriction
Selection Mode
Source Identification
Reserved
Change Reporting Action
Fully Qualified PDN Connection Set Identifier (FQ-CSID)
Channel needed
eMLPP Priority
Node Type
3GPP
3GPP TS 29.274 V10.2.0 (2011-03)

Comment / Reference
Variable Length / 8.3
Extendable / See 3GPP TS 29.276 [14]
Extendable / See 3GPP TS 29.280 [15]
Fixed Length / 8.7
Extendable / 8.8
Extendable / 8.12
Extendable / 8.15
Extendable / 8.16
Extendable / 8.17
Extendable / 8.18
Extendable / 8.22
Variable Length/ 8.26
Extendable / 8.27
Extendable / 8.28
Extendable / 8.29
Extendable / 8.30
Extendable / 8.31
Extendable / 8.32
Extendable / 8.34
Extendable / 8.35
Variable Length/ 8.36
Extendable / 8.38
Extendable / 8.38
Extendable / 8.38
Extendable / 8.38
Extendable / 8.38
Extendable / 8.38
Extendable / 8.39
Extendable / 8.40
Extendable / 8.43
Fixed Length / 8.45
Variable Length / 853
Fixed Length / 8.54
Extendable / 8.56
Extendable / 8.57
Extendable / 8.58
Extendable / 8.63
Extendable / 8.64
Extendable / 8.65
Release 10
IE Type value
(Decimal)
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159 to 254
255
3GPP TS 29.274 V10.2.0 (2011-03)
131
Fully Qualified Domain Name (FQDN)
Transaction Identifier (TI)
MBMS Session Duration
MBMS Service Area
MBMS Session Identifier
MBMS IP Multicast Distribution
MBMS Distribution Acknowledge
RFSP Index
User CSG Information (UCI)
CSG Information Reporting Action
CSG ID
CSG Membership Indication (CMI)
Service indicator
Detach Type
Local Distiguished Name (LDN)
Node Features
MBMS Time to Data Transfer
Throttling
Allocation/Retention Priority (ARP)
EPC Timer
Signalling Priority Indication
Temporary Mobile Group Identity (TMGI)
Spare. For future use.
Private Extension
Comment / Reference
Extendable / 8.69
Extendable / 8.70
Extendable / 8.71
Extendable / 8.72
Extendable / 8.73
Extendable / 8.74
Fixed Length / 8.77
Extendable / 8.75
Extendable / 8.76
Extendable / 8.78
Extendable / 8.79
Fixed Length / 8.80
Fixed Length / 8.81
Variable / 8.82
Extendable / 8.83
Extendable / 8.84
Extendable / 8.85
Extendable / 8.86
Extendable / 8.87
Extendable / 8.88
Extendable / 8.89
FFS
8.2 Information Element Format

Figure 8.2-1 depicts the format of an information element.
Octets
1
2 to3
4
5 to (n+4)
Bits
5
4
3
2
Type = xxx (decimal)
Length = n
Spare
Instance
IE specific data or content of a grouped IE
7
Figure 8.2-1: Information Element Format

An IE has the following mandatory fields:
-
Type field: This field indicates the type of Information Element. The valid values of the IE type are defined in
clause 8.1.
Length: This field contains the length of the information element excluding the first four octets, which are
common for all information elements (Type, Length and the contents of octet 4) and is denoted "n" in Figure 8.21. For all the length fields, bit 8 of the lowest numbered octet is the most significant bit and bit 1 of the highest
numbered octet is the least significant bit.
Instance: This field shall be used to differentiate amongst different parameters in one specific message which use
the same information element type (see also subclause 6.1.3 "Information Element Instance").
An IE is said to be TLIV (Type, Length, Instance, Value) encoded.
8.3 International Mobile Subscriber Identity (IMSI)

International Mobile Subscriber Identity (IMSI) is transferred via GTP tunnels. The sending entity copies the value part
of the IMSI into the Value field of the IMSI IE. IMSI is defined in 3GPP TS 23.003 [2].
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
132
Octets
1
2 to 3
4
5
6
n+4
Bits
5
4
3
2
1
Type = 1 (decimal)
Length = n
Spare
Instance
Number digit 2
Number digit 1
Number digit 4
Number digit 3
Number digit m
Number digit m-1
7
Figure 8.3-1: IMSI

Octets 5 to (n+4) represent the IMSI value in international number format as described in ITU-T Rec E.164 [25],
encoded as TBCD digits, i.e. digits from 0 through 9 are encoded "0000" to "1001". When there is an odd number of
digits, bits 8 to 5 of the last octet are encoded with the filler "1111". The maximum number of digits is 15.
8.4 Cause
Cause IE is coded as depicted in Figure 8.4-1.
.
Octets
1
2 to 3
4
5
6
a(n+1)
a(n+2) to a(n+3)
a(n+4)
Bits
5
4
3
2
Type = 2 (decimal)
Length = n
Spare
Instance
Cause value
Spare
PCE BCE
Type of the offending IE
Length of the offending IE = 0
6
Spare
CS
Instance
1) Figure 8.4-1: Cause

Cause is a variable length IE, which may have either of the following two lengths values:
-
If n = 2, a = 0 and the Cause IE shall be 6 octets long. Therefore, octets "a(n+1) to a(n+4)" will not be present.
If n = 6, a = 1 and the Cause IE will be 10 octets long.
For PMIP based S5/S8, the SGW/MAG shall do the mapping between GTPv2 Cause IE and respective PMIPv6 IE as
specified in 3GPP TS 29.275 [26].
The following bits within Octet 6 indicate:
-
Bits 8 to 4: Spare, for future use and set to zero
Bit 1 CS (Cause Source): If this bit is set to 1, it indicates that the corresponding error cause is originated by
the remote node (i.e., the MME/SGSN to a PGW, or the PGW to an MME/SGSN). This bit is set to 0 to denote
that the corresponding error cause is originated by the node sending the message.
The CS should be set to 1 by the SGW when the SGW relay a response message with cause value from the
MME/SGSN to the PGW or from the PGW to the MME/SGSN. For PMIP based S5/S8, the SGW shall set the
CS bit to 1 when the SGW/MAG relay a response message with the cause value from the PGW/LMA to the
MME/SGSN.
Bit 2 BCE (Bearer Context IE Error): If this bit is set to 1, it indicates that the corresponding rejection cause is
due to the error in the Bearer Context IE. This bit shall be discarded if the cause value is one of Acceptance
cause value as given in table 8.4-1.
Bit 3 PCE (PDN Connection IE Error): If this bit is set to 1, it indicates that the corresponding rejection cause
is due to the error in the PDN Connection IE. This bit shall be discarded if the cause value is one of Acceptance
cause value as given in table 8.4-1.
3GPP
Release 10
133
3GPP TS 29.274 V10.2.0 (2011-03)
The Cause value shall be included in a response message. In a response message, the Cause value indicates the
acceptance or the rejection of the corresponding request message. The Cause value indicates the explicit reason for the
rejection.
If the rejection is due to a mandatory IE or a verifiable conditional IE is faulty or missing, the offending IE shall be
included within an additional field "a(n+1) to a(n+4)". Only Type and Instance fields of the offending IE that caused the
rejection have a meaning. The length in the Octet 8-9 and spare bits in the Octet 10 shall be set to "0". In this case, the
value of "n" shall be "6". Otherwise, the value of "n" is equal to "2".
The Cause may also be included in the request message. In a request message, the Cause value indicates the reason for
the request.
"Request accepted" is returned when the GTPv2 entity has accepted a control plane request.
"Invalid Reply from remote peer" is used by the SGW for the messages spanning through two interfaces. This cause
value is returned by the SGW to the MME/SGSN or PGW in a reply message where the corresponding reply message
on S5/S8 or S11/S4 from the PGW or MME/SGSN is not decoded as valid.
"Temporarily rejected due to handover procedure in progress" is used by the MME for the dedicated bearer related
procedure initiated by the PGW. When the X2 based handover with/without SGW change or S1 based handover
with/without SGW and/or MME change is in progress, the MME may receive Create / Update / Delete Bearer request
message for the dedicated bearer creation, modification or deletion initiated by the PGW. If the handover procedure
results in the SGW and/or MME change, then the dedicated bearer related procedure can not be handled temporarily by
the MME till the handover procedure is completed. In that case the MME shall reject the dedicated bearer related
procedure with this rejection cause.
The usage of "Fallback to GTPv1" is specified in subclause 7.10 "Fallback to GTPv1 mechanism".
In the PGW initiated PDN connection deactivation procedure, the PGW may include the Cause IE in the Delete Bearer
Request with values "RAT changed from 3GPP to Non-3GPP", "Reactivation requested" or "Reactivation disallowed to
APN". For "Reactivation requested", "PDN reconnection to this APN disallowed", the MME/S4-SGSN uses this to map
to a NAS cause code.
-
GTPv2 cause "Reactivation requested" for PDN connection deactivation shall be mapped to the corresponding
NAS cause value with the same name (see 3GPP TS 24.008 [5] and 3GPP TS 24.301 [23]) in the NAS bearer
context deactivation procedure, for the last PDN connection in E-UTRAN, "Reactivation requested" shall be
mapped to "re-attach required" in the NAS detach type IE.
GTPv2 cause "PDN reconnection to this APN disallowed" for PDN connection deactivation should be mapped
to an implementation specific NAS cause value indicating to the UE that the APN is not currently available, for
the last PDN connection in E-UTRAN, NAS detach type IE should be set to "re-attach not required".
"APN Congestion" is used by the PGW and it indicates that the PGW has detected congestion for the requested APN
and performs overload control for that APN which does not allow the PDN connection to be established.
"UE already re-attached" is used by MME/S4-SGSN for the network triggered service restoration procedure as
specified in 3GPP TS 23.007 [17]. The MME/S4-SGSN may send the Downlink Data Notification Acknowledge or
Downlink Data Notification Failure Indication with this cause as part of the network triggered service restoration
procedure.
The listed cause values for rejection response message descriptions in clause 7 are not meant to be exhaustive lists.
Therefore a GTPv2 node shall use the most appropriate matching rejection response cause value that is listed in Table
8.4-1.
If a Bearer Resource Command message is related to an established PDN connection for LIPA, the LGW shall reject the
Bearer Resource Command with the cause value of "Bearer handling not supported". The MME/S4-SGSN uses this to
map to the corresponding NAS cause value with the same name (see 3GPP TS 24.008 [5] and 3GPP TS 24.301 [23]).
3GPP
Release 10
134
Table 8.4-1: Cause values
3GPP
3GPP TS 29.274 V10.2.0 (2011-03)
Release 10
Message Type
Request / Initial
message
Acceptance in a
Response /
triggered
message. See
NOTE 1.
Rejection in a
Response /
triggered
message. See
NOTE 1.
3GPP TS 29.274 V10.2.0 (2011-03)
135
Cause value
(decimal)
0
1
2
3
4
5
6
7
8
9
10
11 to 15
16
17
18
19
20 to -63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
Meaning
Reserved. Shall not be sent and if received the Cause shall be treated as an
invalid IE
Reserved
Local Detach
Complete Detach
RAT changed from 3GPP to Non-3GPP
ISR deactivation
Error Indication received from RNC/eNodeB
IMSI Detach Only
Reactivation Requested
PDN reconnection to this APN disallowed
Access changed from Non-3GPP to 3GPP
Spare. This value range shall be used by Cause values in an initial/request
message. See NOTE 5.
Request accepted
Request accepted partially
New PDN type due to network preference
New PDN type due to single address bearer only
Spare. This value range shall be used by Cause values in an acceptance
response/triggered message
Context Not Found
Invalid Message Format
Version not supported by next peer
Invalid length
Service not supported
Mandatory IE incorrect
Mandatory IE missing
Shall not be used. See NOTE 2 and NOTE 3.
System failure
No resources available
Semantic error in the TFT operation
Syntactic error in the TFT operation
Semantic errors in packet filter(s)
Syntactic errors in packet filter(s)
Missing or unknown APN
GRE key not found
Relocation failure
Denied in RAT
Preferred PDN type not supported
All dynamic addresses are occupied
UE context without TFT already activated. See NOTE 6.
Protocol type not supported
UE not responding. See NOTE 7.
UE refuses
Service denied. See NOTE 7.
Unable to page UE
No memory available
User authentication failed
APN access denied no subscription
Request rejected (reason not specified)
P-TMSI Signature mismatch
IMSI not known
Semantic error in the TAD operation
Syntactic error in the TAD operation
Remote peer not responding
Collision with network initiated request
Unable to page UE due to Suspension
Conditional IE missing
APN Restriction type Incompatible with currently active PDN connection
Invalid overall length of the triggered response message and a piggybacked initial
message
Data forwarding not supported
3GPP
Release 10
136
107
108
109
110
111
112
113
114
115
116 to 239
240 to 255
3GPP TS 29.274 V10.2.0 (2011-03)
Invalid reply from remote peer

Fallback to GTPv1
Invalid peer
Temporarily rejected due to handover procedure in progress
Modifications not limited to S1-U bearers
Request rejected for a PMIPv6 reason (see 3GPP TS 29.275 [26]).
APN Congestion
Bearer handling not supported
UE already re-attached. See NOTE 7.
Spare. For future use in a triggered/response message See NOTE 4.
Spare. For future use in an initial/request message. See NOTE 5.
Request / Initial
message
NOTE 1: The listed cause values for rejection in a response/triggered message can be also used for request
messages if the request message is triggered by a command message.
NOTE 2: Subclause 7.7.8 "Semantically incorrect Information Element" specifies quite strict handling of the reserved
values and therefore this table shall not contain any reserved values.
NOTE 3: This value was used in earlier versions of the spec. If received, it shall be interpreted as unspecified
rejection cause. Unspecified/unrecognized rejection cause shall be treated in the same ways as the cause
value 94 "Request rejected (reason not specified)".
NOTE 4: This value is or may be used in the newer versions of the spec. If the receiver cannot comprehend the
value, it shall be interpreted as unspecified rejection cause. Unspecified/unrecognized rejection cause shall
be treated in the same ways as the cause value 94 "Request rejected (reason not specified)".
NOTE 5: This value is or may be used in the newer versions of the spec. If the receiver cannot comprehend the
value, it shall be interpreted as an unspecified request/initial message cause. Unspecified/unrecognized
cause handling in a request/initial message shall be implementation dependent (e.g. may be ignored).
NOTE 6: This Cause value is only used over the S4 interface.
NOTE 7: This cause value may also be used by a Downlink Data Notification Failure Indication, which is an initial
message.
8.5 Recovery (Restart Counter)

Recovery IE is coded as depicted in Figure 8.5-1.
In the first release of GTPv2 spec n = 1. That is, the overall length of the IE is 5 octets. In future releases of the spec
additional octets may be specified.
.
Octets
1
2 to 3
4
5 to (n+4)
Bits
5
4
3
2
Type = 3 (decimal)
Length = n
Spare
Instance
Recovery (Restart Counter)
6
Figure 8.5-1: Recovery (Restart Counter)
8.6 Access Point Name (APN)

Access Point Name (APN) is transferred via GTP tunnels. The sending entity copies the value part of the APN into the
Value field of the APN IE.
Octets
1
2 to 3
4
5 to (n+4)
Bits
5
4
3
2
Type = 71 (decimal)
Length = n
Spare
Instance
Access Point Name (APN)
6
Figure 8.6-1: Access Point Name (APN)

The encoding the APN field follows 3GPP TS 23.003 [2] subclause 9.1. The content of the APN field shall be the full
APN with both the APN Network Identifier and APN Operator Identifier being present as specified in 3GPP TS 23.003
[2] subclauses 9.1.1 and 9.1.2, 3GPP TS 23.060 [35] Annex A and 3GPP TS 23.401 [3] subclauses 4.3.8.1.
3GPP
Release 10
NOTE:
137
3GPP TS 29.274 V10.2.0 (2011-03)
The APN field is not encoded as a dotted string as commonly used in documentation.
8.7 Aggregate Maximum Bit Rate (AMBR)

Aggregate Maximum Bit Rate (AMBR) is transferred via GTP tunnels. The sending entity copies the value part of the
AMBR into the Value field of the AMBR (APN-AMBR) IE.
AMBR is defined in clause 9.9.4.2 of 3GPP TS 24.301 [23], but shall be formatted as shown in Figure 8.7-1 as
Unsigned32 binary integer values in kbps (1000 bits per second).
Octets
1
2 to 3
4
5 to 8
9 to 12
Bits
5
4
3
2
Type = 72 (decimal)
Length = 8
Spare
Instance
APN-AMBR for uplink
APN-AMBR for downlink
6
Figure 8.7-1: Aggregate Maximum Bit Rate (AMBR)
8.8 EPS Bearer ID (EBI)

EPS Bearer ID (EBI) is coded as depicted in Figure 8.8-1.
The overall length of the IE is 5 octets. In future releases of the spec additional octets may be specified and new
semantic for the spare bits may be defined.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
5
4
3
2
1
Type = 73 (decimal)
Length = n
Spare
Instance
Spare (all bits set to 0)
EPS Bearer ID (EBI)
These octet(s) is/are present only if explicitly specified
8
Figure 8.8-1: EPS Bearer ID (EBI)

The coding of EBI field and its value range is specified in 3GPP TS 24.007 [30], subclause 11.2.3.1.5, bits 5 to 8.
8.9 IP Address
IP Address is coded as depicted in Figure 8.9-1. The Length field may have only two values (4 or 16) that determine if
the Value field contains IPv4 or IPv6 address.
Octets
1
2 to 3
4
5 to (n+4)
Bits
5
4
3
2
Type = 74 (decimal)
Length = n
Spare
Instance
IPv4 or IPv6 Address
6
Figure 8.9-1: IP address
8.10 Mobile Equipment Identity (MEI)

Mobile Equipment Identity (MEI) is coded as depicted in Figure 8.10-1.. MEI is defined in clause 6.2 of 3GPP TS
23.003 [2].
3GPP
Release 10
138
Octets
1
2 to 3
4
5 to (n+4)
Bits
5
4
3
2
Type = 75 (decimal)
Length = n
Spare
Instance
Mobile Equipment (ME) Identity
6
3GPP TS 29.274 V10.2.0 (2011-03)
Figure 8.10-1: Mobile Equipment (ME) Identity (MEI)

The ME Identity field contains either the IMEI or the IMEISV as defined in clause 6.2 of 3GPP TS 23.003 [2]. It is
encoded as specified in clause 7.7.53 of 3GPP TS 29.060 [4], beginning with octet 4 of Figure 7.7.53.1.
The IMEI(SV) digits are encoded using BCD coding where IMEI is 15 BCD digits and IMEISV is 16 BCD digits. For
IMEI, bits 5 to 8 of the last octet shall be filled with an end mark coded as '1111'.
8.11 MSISDN
MSISDN is transferred via GTP tunnels. The sending entity copies the value part of the MSISDN into the Value field of
the MSISDN IE. MSISDN is defined in 3GPP TS 23.003 [2].
Octets
1
2 to 3
4
5
6
n+4
Bits
5
4
3
2
1
Type = 76 (decimal)
Length = n
Spare
Instance
Number digit 2
Number digit 1
Number digit 4
Number digit 3
Number digit m
Number digit m-1
7
Figure 8.11-1: MSISDN

Octets 5 to (n+4) represent the MSISDN value is in international number format as described in ITU-T Rec E.164 [25]
and 3GPP TS 29.002 [41]. MSISDN value contains only the actual MSISDN number (does not contain the "nature of
address indicator" octet, which indicates "international number" as in 3GPP TS 29.002 [41]) and is encoded as TBCD
digits, i.e. digits from 0 through 9 are encoded "0000" to "1001". When there is an odd number of digits, bits 8 to 5 of
the last octet are encoded with the filler "1111".
8.12 Indication
Indication is coded as depicted in Figure 8.12-1.
Octets
1
2 to 3
4
5
6
7
8 to (n+4)
Bits
5
4
3
2
1
Type = 77 (decimal)
Length = n
Spare
Instance
DAF DTF
HI
DFI
OI ISRSI ISRAI SGW
CI
SQCI UIMSI CFSI CRSI
P
PT
SI
MSV
Spare Spare Spare Spare Spare Spare ISRA CCRS
U
I
8
Figure 8.12-1: Indication

For each message the applicable flags of the Indication IE shall be clearly specified in the individual message sub
clause. The remaining flags of the Indication IE not so indicated shall be discarded by the receiver.
The receiver shall consider the value of the applicable flags as "0", if the Indication IE is applicable for the message but
not included in the message by the sender.
3GPP
Release 10
139
3GPP TS 29.274 V10.2.0 (2011-03)
The following bits within Octet 5 shall indicate:

-
Bit 8 DAF (Dual Address Bearer Flag): This bit shall be set when the PDN Type, determined based on UE
request and subscription record, is set to IPv4v6 and all SGSNs which the UE may be handed over to are
Release 8 or above supporting dual addressing, which is determined based on node pre-configuration by the
operator..
Bit 7 DTF (Direct Tunnel Flag): This bit shall be set when the UE is in UTRAN/GERAN network and Direct
Tunnel is selected
Bit 6 HI (Handover Indication): If this bit is set to 1 over S11/S4 and S5/S8 interfaces, it shall indicate that a
UE handover from a non-3GPP access to a 3GPP access system. This bit is applicable during the E-UTRAN
Initial Attach procedure, PDP Context Activation procedure or during the UE requested PDN connectivity
procedure. If this bit is set to 1 over GTP based S2b interface, it shall indicate the UE handover to Untrusted
Non-3GPP Access system and IP address preservation is requested by the UE.
Bit 5 DFI (Direct Forwarding Indication): If this bit is set to 1, it shall indicate that the direct forwarding
between the source eNodeB and the target eNodeB during the S1 based handover procedure is applied.
Bit 4 OI (Operation Indication):

-
If this bit is set to 1, it shall denote that the receiving SGW of a "Create Session Request" shall send a Modify
Bearer Request immediately to the PGW. This allows the SGW to differentiate if the "Create Session
Request" received on S4/S11 interface belongs to a TAU/RAU with an SGW relocation (OI = 1), or X2-based
handover with SGW relocation (OI = 1) or S1-based handover with SGW relocation (OI = 0).
It shall be set to 1 on S4/S11 interface if the SGW needs to forward the Delete Session Request message to
PGW.
Bit 3 ISRSI (Idle mode Signalling Reduction Supported Indication): If this is set to 1, it shall indicate that the
old/source SGSN/MME and the associated SGW are capable to activate ISR.
Bit 2 ISRAI (Idle mode Signalling Reduction Activation Indication): If this bit is set to 1, it shall indicate that
the ISR is established between the MME and the S4 SGSN during a TAU/RAU without an SGW change
procedure or during an Inter RAT handover without an SGW change procedure. The SGW shall retain the
resources for the other CN node that has its bearer resources on the SGW reserved. The old/source SGSN/MME
shall maintain the UE's contexts and activate ISR.
Bit 1 SGWCI (SGW Change Indication): If this bit is set to 1, it shall indicate that the target MME/SGSN has
selected a new SGW during a TAU/RAU or handover with an SGW change procedure.

-
Bit 8 SQCI (Subscribed QoS Change Indication): If this bit is set to 1, it indicates that the subscribed QoS
profile of the related PDN connection has changed in the old MME/SGSN when the UE is in ECM-IDLE state
and ISR is activated. The new MME/SGSN shall trigger the Subscribed QoS Modification procedure. See 3GPP
TS 23.401 [3], clause 5.3.9.2.
Bit 7 UIMSI (Unauthenticated IMSI): If this bit is set to 1, it indicates that the IMSI present in the message is
not authenticated and is for emergency attached UE.
Bit 6 CFSI (Change F-TEID support indication): if this bit is set to 1, it indicates that the SGW can change the
assigned GTP-U F-TEID in the current procedure. The MME/SGSN shall include this flag in the Modify Bearer
Request message sent to the SGW in the Idle state UE initiated TAU/RAU procedure. The SGW shall include the
new F-TEID in the Modify Bearer Response message if the CFSI flag is received in the corresponding Request
message and the SGW needs to modify the GTP-U F-TEID.
Bit 5 CRSI (Change Reporting support indication): if this bit is set to 1, it indicates that the MME/S4 SGSN
supporting Location Change Reporting mechanism.
Bit 4 PS (Piggybacking Supported). This bit denotes whether the MME/SGW support piggybacking feature as
described in Annex F of 3GPP TS 23.401 [3]. If set to 1, it indicates that the node is capable of processing two
different GTP-C messages appearing back to back in a single UDP payload.
3GPP
Release 10
140
3GPP TS 29.274 V10.2.0 (2011-03)
Bit 3 PT (Protocol Type) If this bit set to 1, it shall indicate that the protocol type for the S5/S8 interface is
PMIP; this bit is set to 0 to indicate that the protocol type for the S5/S8 interface is GTP.
Bit 2 SI (Scope Indication): If this bit is set to 1, it indicates that all bearer resources of the UE shall be
released by the SGW. This flag is set in messages during TAU/RAU/Handover/SRNS Relocation Cancel Using
S4/Inter RAT handover Cancel procedure with SGW change/S1 Based handover Cancel procedure with SGW
change.
Bit 1 MSV (MS Validated): If this bit is set to 1, it shall indicate that the new MME/SGSN has successfully
authenticated the UE.
The following bits within Octet 7shall indicate:

-
Bit 8 to 3 Spare, for future use and set to zero.
Bit 1 CCRSI (CSG Change Reporting support indication): if this bit is set to 1, it indicates that the MME/S4
SGSN support CSG Information Change Reporting mechanism.
Bit 2 - ISRAU (ISR is activated for the UE): if this bit is set to 1, it indicates that ISR is activated for the UE
before the UE moving to the new SGSN/MME.
8.13 Protocol Configuration Options (PCO)

Protocol Configuration Options (PCO) is transferred via GTP tunnels. The sending entity copies the value part of the
PCO into the Value field of the PCO IE. The detailed coding of the PCO field from octets 5 to (n+4) shall be specified
as per clause 10.5.6.3 of 3GPP TS 24.008 [5], starting with octet 3.
Octets
1
2 to 3
4
5 to (n+4)
Bits
5
4
3
2
Type = 78 (decimal)
Length = n
Spare
Instance
Protocol Configuration Options (PCO)
Figure 8.13-1: Protocol Configuration Options (PCO)
8.14 PDN Address Allocation (PAA)

The PDN Address Allocation is coded as depicted in Figure 8.14-1.
NOTE:
The Prefix Length within PAA IE has a fixed value of /64.

Octets
1
2 to 3
4
5
6 to (n+4)
Bits
5
4
3
2
1
Type = 79 (decimal)
Length = n
Spare
Instance
Spare
PDN Type
PDN Address and Prefix
6
Figure 8.14-1: PDN Address Allocation (PAA)
3GPP
Release 10
141
3GPP TS 29.274 V10.2.0 (2011-03)
Table 8.14-1: PDN Address Allocation

PDN type value (octet 5)
Bits
3 2 1
0 0 1
IPv4
0 1 0
IPv6
0 1 1
IPv4v6
Bits 8-4 of octet 5 are spare and shall be coded as zero.
PDN Address and Prefix (octet 6 to n+4)
If PDN type value indicates IPv4, an IPv4 address is present in the PDN Address and
Prefix from octet 6 to octet 9. Bit 8 of octet 6 represents the most significant bit of the
IPv4 address and bit 1 of octet 9 the least significant bit.
If PDN type value indicates IPv6, octet 6 contains the IPv6 Prefix Length. Octets 7
through 22 contain an IPv6 Prefix and Interface Identifier. Bit 8 of octet 7 represents the
most significant bit of the IPv6 Prefix and Interface Identifier and bit 1 of octet 22 the
least significant bit.
If PDN type value indicates IPv4v6, octet 6 contains the IPv6 Prefix Length. Octets 7
through 22 contain an IPv6 Prefix and Interface Identifier. Bit 8 of octet 7 represents the
most significant bit of the IPv6 Prefix and Interface Identifier and bit 1 of octet 22 the
least significant bit. Octets 23 through 26 contain an IPv4 address. Bit 8 of octet 23
represents the most significant bit of the IPv4 address and bit 1 of octet 26 the least
significant bit.
8.15 Bearer Quality of Service (Bearer QoS)

Bearer Quality of Service (Bearer QoS) is transferred via GTP tunnels. The sending entity copies the value part of the
Bearer l QoS into the Value field of the Bearer QoS IE.
Bits
Octets
8
7
6
5
4
3
2
1
1
Type = 80 (decimal)
2-3
Length = n
4
Spare
Instance
5
Spare PCI
PL
Spare PVI
6
Label (QCI)
7 to 11
Maximum bit rate for uplink
12 to 16
Maximum bit rate for downlink
17 to 21
Guaranteed bit rate for uplink
22 to 26
Guaranteed bit rate for downlink
27 to (n+4)
Figure 8.15-1: Bearer Level Quality of Service (Bearer QoS)

Octet 5 represents the Allocation/Retention Priority (ARP) parameter. The meaning and value range of the parameters
within the ARP are defined in 3GPP TS 29.212 [29]. The bits within the ARP octet are:
-
Bit 1 PVI (Pre-emption Vulnerability): See 3GPP TS 29.212[29], clause 5.3.47 Pre-emption-Vulnerability AVP.
Bit 2 spare
Bits 3 to 6 PL (Priority Level): See 3GPP TS 29.212[29], clause 5.3.45 ARP-Value AVP. PL encodes each
priority level defined for the ARP-Value AVP as the binary value of the priority level.
Bit 7 PCI (Pre-emption Capability): See 3GPP TS 29.212[29], clause 5.3.46 Pre-emption-Capability AVP.
Bit 8 spare.
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
142
QCI, Maximum bit rate for uplink, Maximum bit rate for downlink, Guaranteed bit rate for uplink and Guaranteed bit
rate for downlink are specified in 3GPP TS 36.413 [10].
The UL/DL MBR and GBR fields are encoded as kilobits per second (1 kbps = 1000 bps) in binary value. For non-GBR
bearers, both the UL/DL MBR and GBR should be set to zero.
NOTE:
The encoding in 3GPP TS 24.301 [23] and 3GPP TS 36.413 [10] is different from the encoding here.
8.16 Flow Quality of Service (Flow QoS)

Flow Quality of Service (Flow QoS) is transferred via GTP tunnels. The sending entity copies the value part of the Flow
QoS into the Value field of the Flow QoS IE.
Octets
1
2 to 3
4
5
6 to 10
11 to 15
16 to 20
21 to 25
26 to (n+4)
Bits
5
4
3
2
1
Type = 81 (decimal)
Length = n
Spare
Instance
Label (QCI)
Maximum bit rate for uplink
Maximum bit rate for downlink
Guaranteed bit rate for uplink
Guaranteed bit rate for downlink
8
Figure 8.16-1: Flow Quality of Service (Flow QoS)

QCI, Maximum bit rate for uplink, Maximum bit rate for downlink, Guaranteed bit rate for uplink and Guaranteed bit
rate for downlink are specified in 3GPP TS 36.413 [10].
The UL/DL MBR and GBR fields are encoded as kilobits per second (1 kbps = 1000 bps) in binary value. For non-GBR
bearers, both the UL/DL MBR and GBR should be set to zero.
NOTE:
The encoding in 3GPP TS 24.301 [23] and 3GPP TS 36.413 [10] is different from the encoding here.
8.17 RAT Type

RAT Type is coded as depicted in Figure 8.17-1.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
5
4
3
2
1
Type = 82 (decimal)
Length = n
Spare
Instance
RAT Type
8
Figure 8.17-1: RAT Type

Table 8.17-1: RAT Type values
RAT Types
<reserved>
UTRAN
GERAN
WLAN
GAN
HSPA Evolution
EUTRAN
Virtual
<spare>
Values (Decimal)
0
1
2
3
4
5
6
7
8-255
3GPP
Release 10
NOTE:
143
3GPP TS 29.274 V10.2.0 (2011-03)
For S4-SGSN, currently it is only possible to detect the difference between GERAN and UTRAN when
GERAN Gb mode is used. If GERAN Iu mode is used, then an S4-SGSN may not be able to detect the
difference between GERAN and UTRAN. Across the Gb interface, the SGSN may also not be able to
detect the difference between GERAN and GAN. If S4-SGSN cannot detect that the HSPA Evolution
3GPP TR 25.999 [46] network is behind the Iu interface, the S4-SGSN will send the "UTRAN" RAT
Type.
8.18 Serving Network

Serving Network is coded as depicted in Figure 8.18-1.
Octets
1
2 to 3
4
5
6
7
8 to (n+4)
Bits
5
4
3
2
1
Type = 83 (decimal)
Length = n
Spare
Instance
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
8
Figure 8.18-1: Serving Network

If an Administration decides to include only two digits in the MNC, then bits 5 to 8 of octet 6 are coded as "1111".
This IE contains the serving network provided by the MME, S4-SGSN or ePDG.
8.19 EPS Bearer Level Traffic Flow Template (Bearer TFT)

EPS Bearer Level Traffic Flow Template (Bearer TFT) is transferred via GTP tunnels. The sending entity copies the
value part of the EPS Bearer Level TFT into the Value field of the EPS Bearer Level TFT IE. The detailed coding of the
EPS Bearer Level TFT IE is specified in 3GPP TS 24.008 [5], clause 10.5.6.12, beginning with octet 3.
Octets
1
2 to 3
4
5 to (n+4)
Bits
5
4
3
2
1
Type = 84 (decimal)
Length = n
Spare
Instance
EPS Bearer Level Traffic Flow Template (TFT)
7
Figure 8.19-1: EPS Bearer Level Traffic Flow Template (Bearer TFT)
8.20 Traffic Aggregate Description (TAD)

The Traffic Aggregate Description IE is coded as depicted in Figure 8.20-1. The detailed coding of Traffic Aggregate
Description is specified in 3GPP TS 24.008 [5] , clause 10.5.6.12, beginning with octet 3..
Octets
1
2 to 3
4
5 to (n+4)
Bits
5
4
3
2
Type = 85 (Decimal)
Length = n
Spare
Instance
Traffic Aggregate Description
6
Figure 8.20-1 Traffic Aggregate Description
8.21 User Location Information (ULI)

User Location Information (ULI) is a variable length IE that is coded as depicted in Figure 8.21-1. The CGI, SAI, RAI,
TAI, ECGI and LAI identity types are defined in 3GPP TS 23.003 [2].
3GPP
Release 10
144
Octets
1
2 to 3
4
5
a to a+6
b to b+6
c to c+6
d to d+4
e to e+6
f to f+4
g to (n+4)
3GPP TS 29.274 V10.2.0 (2011-03)
Bits
5
4
3
2
1
Type = 86 (decimal)
Length = n
Spare
Instance
Spare
LAI ECGI TAI
RAI
SAI
CGI
CGI
SAI
RAI
TAI
ECGI
LAI
8
Figure 8.21-1: User Location Information

The ULI IE shall contain only one identity of the same type (e.g. more than one CGI cannot be included), but ULI IE
may contain more than one identity of a different type (e.g. ECGI and TAI). The flags LAI, ECGI, TAI, RAI, SAI and
CGI in octet 5 indicate if the corresponding type shall be present in a respective field or not. If one of these flags is set
to "0", the corresponding field shall not be present at all. If more than one identity of different type is present, then they
shall be sorted in the following order: CGI, SAI, RAI, TAI, ECGI, LAI.
The following subclauses specify the coding of the fields representing different identities.
For each identity, if an Administration decides to include only two digits in the MNC, then "MNC digit 3" field of
corresponding location shall be coded as "1111".
8.21.1 CGI field

The coding of CGI (Cell Global Identifier) is depicted in Figure 8.21.1-1. Only zero or one CGI field shall be present in
ULI IE.
Octets
a
a+1
a+2
a+3 to a+4
a+5 to a+6
Bits
7
6
5
4
3
2
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
Location Area Code (LAC)
Cell Identity (CI)
Figure 8.21.1-1: CGI field

The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet a+3 is the most significant bit and bit 1 of Octet a+4
the least significant bit. The coding of the location area code is the responsibility of each administration. Coding using
full hexadecimal representation shall be used.
The Cell Identity (CI) consists of 2 octets. Bit 8 of Octet a+5 is the most significant bit and bit 1 of Octet a+6 the least
significant bit. The coding of the cell identity is the responsibility of each administration. Coding using full hexadecimal
representation shall be used.
8.21.2 SAI field

The coding of SAI (Service Area Identifier) is depicted in Figure 8.21.2-1. Only zero or one SAI field shall be present
in ULI IE.
Octets
b
b+1
b+2
b+3 to b+4
b+5 to b+6
Bits
7
6
5
4
3
2
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
Service Area Code (SAC)
Figure 8.21.2-1: SAI field
3GPP
Release 10
145
3GPP TS 29.274 V10.2.0 (2011-03)
The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet b+3 is the most significant bit and bit 1 of Octet b+4
The Service Area Code (SAC) consists of 2 octets. Bit 8 of Octet b+5 is the most significant bit and bit 1 of Octet b+6
the least significant bit. The SAC is defined by the operator. See 3GPP TS 23.003 [2] section 12.5 for more information.
8.21.3 RAI field

The coding of RAI (Routing Area Identity) is depicted in Figure 8.21.3-1. Only zero or one RAI field shall be present in
ULI IE.
Octets
c
c+1
c+2
c+3 to c+4
c+5 to c+6
Bits
7
6
5
4
3
2
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
Routing Area Code (RAC)
Figure 8.21.3-1: RAI field

The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet c+3 is the most significant bit and bit 1 of Octet c+4
The Routing Area Code (RAC) consists of 2 octets. Only Octet c+5 contains the RAC. Octet c+6 is coded as all 1's
(11111111). The RAC is defined by the operator.
8.21.4 TAI field

The coding of TAI (Tracking Area Identity) is depicted in Figure 8.21.4-1. Only zero or one TAI field shall be present in
ULI IE.
Octets
d
d+1
d+2
d+3 to d+4
Bits
7
6
5
4
3
2
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
Tracking Area Code (TAC)
Figure 8.21.4-1: TAI

The Tracking Area Code (TAC) consists of 2 octets. Bit 8 of Octet d+3 is the most significant bit and bit 1 of Octet d+4
the least significant bit. The coding of the tracking area code is the responsibility of each administration. Coding using
8.21.5 ECGI field

The coding of ECGI (E-UTRAN Cell Global Identifier) is depicted in Figure 8.21.5-1. Only zero or one ECGI field
shall be present in ULI IE.
Octets
e
e+1
e+2
e+3
e+4 to e+6
Bits
7
6
5
4
3
2
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
Spare
ECI
ECI (E-UTRAN Cell Identifier)
Figure 8.21.5-1: ECGI field
3GPP
Release 10
146
3GPP TS 29.274 V10.2.0 (2011-03)
The E-UTRAN Cell Identifier (ECI) consists of 28 bits. The ECI field shall start with Bit 4 of octet e+3, which is the
most significant bit. Bit 1 of Octet e+6 is the least significant bit. The coding of the E-UTRAN cell identifier is the
responsibility of each administration. Coding using full hexadecimal representation shall be used.
8.21.6 LAI field

The coding of LAI (Location Area Identifier) is depicted in Figure 8.21.6-1.
Octets
f
f+1
f+2
f+3 to f+4
Bits
7
6
5
4
3
2
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
Figure 8.21.6-1: LAI field

The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet f+3 is the most significant bit and bit 1 of Octet f+4
8.22 Fully Qualified TEID (F-TEID)

Fully Qualified Tunnel Endpoint Identifier (F-TEID) is coded as depicted in Figure 8.22-1.
Octets
1
2to 3
4
5
6 to 9
m to (m+3)
p to (p+15)
k to (n+4)
Bits
5
4
3
2
1
Type = 87 (decimal)
Length = n
Spare
Instance
V4
V6
Interface Type
TEID / GRE Key
IPv4 address
IPv6 address
8
Figure 8.22-1: Fully Qualified Tunnel Endpoint Identifier (F-TEID)
The following flags are coded within Octet 5:

-
Bit 8 V4: If this bit is set to "1", then IPv4 address field exists in the F-TEID, otherwise the IPv4 address field
is not present at all.
Bit 7 V6: If this bit is set to "1", then IPv6 address field exists in the F-TEID, otherwise the IPv6 address field
is not present at all.
At least one of V4 and V6 shall be set to "1", and both may be set to "1".
-
Bit 6 to Bit 1 Interface Type: This 6 bit wide integer can take the following values representing interface type
and endpoint:
0: S1-U eNodeB GTP-U interface
1: S1-U SGW GTP-U interface
2: S12 RNC GTP-U interface
3: S12 SGW GTP-U interface
4: S5/S8 SGW GTP-U interface
5: S5/S8 PGW GTP-U interface
3GPP
Release 10
147
3GPP TS 29.274 V10.2.0 (2011-03)
6: S5/S8 SGW GTP-C interface

7: S5/S8 PGW GTP-C interface
8: S5/S8 SGW PMIPv6 interface (the 32 bit GRE key is encoded in 32 bit TEID field and since alternate CoA is
not used the control plane and user plane addresses are the same for PMIPv6)
9: S5/S8 PGW PMIPv6 interface (the 32 bit GRE key is encoded in 32 bit TEID field and the control plane and
user plane addresses are the same for PMIPv6)
10: S11 MME GTP-C interface
11: S11/S4 SGW GTP-C interface
14: S3 SGSN GTP-C interface
15: S4 SGSN GTP-U interface
16: S4 SGW GTP-U interface
19: eNodeB GTP-U interface for DL data forwarding
20: eNodeB GTP-U interface for UL data forwarding
21: RNC GTP-U interface for data forwarding
22: SGSN GTP-U interface for data forwarding
23: SGW GTP-U interface for DL data forwarding
24: Sm MBMS GW GTP-C interface
25: Sn MBMS GW GTP-C interface
26: Sm MME GTP-C interface
27: Sn SGSN GTP-C interface
28: SGW GTP-U interface for UL data forwarding
29: Sn SGSN GTP-U interface
30: S2b ePDG GTP-C interface
31: S2b-U ePDG GTP-U interface
32: S2b PGW GTP-C interface
33: S2b-U PGW GTP-U interface
Other values of "Interface Type" are spare and reserved for future use.
"Interface type" values with bit "6" set to 1 shall only be used between Rel-10 onwards GTPv2-C nodes.
NOTE:
"Interface type" IE is defined with 5 bits only in the earlier releases of this specification, thus pre-Rel-10
GTPv2-C nodes can ignore bit "6" which is marked as "Spare" in earlier releases, allowing backward
compatibility.
3GPP
Release 10
148
3GPP TS 29.274 V10.2.0 (2011-03)
Octet 6 to 9 (TEID/GRE field) represent either a TEID or a GRE key. If both IPv4 and IPv6 addresses are present in FTEID IE, then the TEID value shall be shared by both addresses.
Octets "m to (m+3)" and/or "p to (p+15)" (IPv4 address / IPv6 address fields), if present, contain respective address
values.
8.23 TMSI
The TMSI, unambiguously associated with a given UE and Location area, is given by:
Octets
1
2 to 3
4
5 to (n+4)
Bits
5
4
3
2
Type = 88 (decimal)
Length = n
Spare
Instance
TMSI
The TMSI is defined in 3GPP TS 23.003 [2].
7
Figure 8.23-1: TMSI
8.24 Global CN-Id

The Global CN-Id is coded as depicted in Figure 8.24-1.
Octets
1
2 to 3
4
5
6
7
8 to (n+4)
Bits
5
4
3
2
Type = 89 (decimal)
Length = n
Spare
Instance
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
CN-Id
The CN-Id is defined in 3GPP TS 23.003 [2].
7
Figure 8.24-1: Global CN-Id

8.25 S103 PDN Data Forwarding Info (S103PDF)

The HSGW Address and GRE Key identify a GRE Tunnel towards a HSGW over S103 interface for a specific PDN
connection of the UE. The EPS Bearer IDs specify the EPS Bearers which require data forwarding that belonging to this
PDN connection. The number of EPS bearer Ids included is specified by the value of EPS Bearer ID Number.
The spare bits indicate unused bits, which shall be set to 0 by the sending side and which shall not be evaluated by the
receiving side.
Octets
1
2 to 3
4
5
6 to (m+5)
(m+6)- to
(m+9)
(m+10)
(m+11) to
(m+10+k)
Bits
5
4
3
2
Type = 90 (decimal)
Length = n
Spare
Instance
HSGW Address for forwarding Length = m
HSGW Address for forwarding [4..16]
GRE Key
7
EPS Bearer ID Number = k

Spare
EPS Bearer ID
Figure 8.25-1: S103 PDN Data Forwarding Info
3GPP
Release 10
149
3GPP TS 29.274 V10.2.0 (2011-03)
8.26 S1-U Data Forwarding (S1UDF)

The Serving GW Address and Serving GW S1-U TEID consist the S1-U Tunnel information allocated by the Serving
GW for an EPS Bearer identified by the EPS Bearer ID which requires data forwarding during active handover from EUTRAN Access to cdma2000 HRPD Access.
receiving side.
Octets
1
2 to 3
4
5
6
7 to (m+6)
(m+7) to
(m+10)
Bits
5
4
3
2
Type = 91 (decimal)
Length = n
Spare
Instance
Spare
EPS Bearer ID
Serving GW Address Length = m
Serving GW Address [4..16]
Serving GW S1-U TEID
6
Figure 8.26-1: S1-U Data Forwarding Info
8.27 Delay Value

Delay Value is coded as depicted in Figure 8.27-1.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
5
4
3
2
1
Type = 92 (decimal)
Length = n
Spare
Instance
Delay Value in integer multiples of 50 millisecs, or zero
8
Figure 8.27-1: Delay Value

Delay Value is set to zero in order to clear a previously set delay condition.
8.28 Bearer Context

Bearer Context is a grouped IE containing a number of other IEs. Which of those IEs are mandatory, optional or
conditional and the conditions that apply are GTP message specific, and described in the corresponding subclause under
clause 7.
Bearer Context may be repeated within a message with exactly the same Type and Instance values to represent a list of
Bearer Contexts.
Bearer Context is coded as depicted in Table 8.28-1.
Table 8.28-1: Bearer Context Grouped Type
Octet 1
Octets 2 and 3
Octet 4
NOTE:

Length = n
Condition / Comment
IE Type
Ins.
This table uses a 5-column format in order to match the format used in subclauses of clause 7, where
the usage of this IE is further detailed for each specific GTP message including it.
3GPP
Release 10
150
3GPP TS 29.274 V10.2.0 (2011-03)
8.29 Charging ID
The Charging ID is coded as depicted in Figure 8.29-1. It is defined in 3GPP TS 32.251[8].
Octets
1
2 to 3
4
5-8
9-(n+4)
Bits
5
4
3
2
1
Type = 94 (decimal)
Length = n
Spare
Instance
Charging ID value
8
Figure 8.29-1: Charging ID
8.30 Charging Characteristics

The charging characteristics information element is defined in 3GPP TS 32.251 [8] and is a way of informing both the
SGW and PGW of the rules for producing charging information based on operator configured triggers. For the encoding
of this information element see 3GPP TS 32.298 [9].
Octets
1
2 to 3
4
5 to 6
7 to (n+4)
Bits
5
4
3
2
1
Type = 95 (decimal)
Length = n
Spare
Instance
Charging Characteristics value
8
Figure 8.30-1: Charging Characteristics
8.31
Trace Information
Trace Information is coded as depicted in Figure 8.31-1. See 3GPP TS 32.422 [18] for details on trace related
information.
Octets
1
2 to 3
4
5
6
7
8 to10
11 to 19
20 to 21
22
23 to 34
35 to (n+4)
Bits
5
4
3
2
Type = 96(decimal)
Length = n
Spare
Instance
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
Trace ID
Triggering Events
List of NE Types
Session Trace Depth
List of Interfaces
IP Address of Trace Collection Entity
7
Figure 8.31-1: Trace Information

Octets 5 to 10 represent the Trace Reference parameter as defined in 3GPP TS 32.422 [18], clause 5.6.
Triggering Events, List of NE Types, Session Trace Depth and List of Interfaces are specified in 3GPP TS 32.422 [18]
See 3GPP TS 24.008 [5], clause 10.5.1.4, Mobile Identity, for the coding of MCC and MNC, whose values are obtained
from the serving PLMN that the EM/NM is managing. If MNC is 2 digits long, bits 5 to 8 of octet 6 are coded as
"1111".
3GPP
Release 10
151
3GPP TS 29.274 V10.2.0 (2011-03)
8.32 Bearer Flags

Bearer Flags is coded as depicted in Figure 8.32-1.
Octets
1
2 to 3
4
5
6-(n+4)
Bits
5
4
3
2
1
Type = 97 (decimal)
Length = n
Spare
Instance
Spare
VB
PPC
8
Figure 8.32-1: Bearer Flags

The following bits within Octet 5 indicate:
-
Bit 1 PPC (Prohibit Payload Compression): This flag is used to determine whether an SGSN should attempt to
compress the payload of user data when the users asks for it to be compressed (PPC = 0), or not (PPC = 1).
Bit 2 VB (Voice Bearer): This flag is used to indicate a voice bearer when doing PS-to-CS SRVCC handover.
8.33 Void
8.34 PDN Type
The PDN Type is coded as depicted in Figure 8.34-1.
Octets
1
2 to 3
4
5
6 to n+4)
Bits
5
4
3
2
1
Type = 99 (decimal)
Length = n
Spare
Instance
Spare
PDN Type
8
Figure 8.34-1: PDN Type

Table 8.34-1: PDN Type
PDN type value (octet 5)
Bits
3 2 1
0 0 1
IPv4
0 1 0
IPv6
0 1 1
IPv4v6
Bits 8-4 of octet 5 are spare and shall be coded as zero.
8.35
Procedure Transaction ID (PTI)
Procedure Transaction Id is coded as depicted in Figure 8.35-1. It is defined in 3GPP TS 24.301 [23], clause 9.4 and is
coded as specified in 3GPP TS 24.007 [30], clause 11.2.3.1a Procedure transaction identity.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
1
Type = 100 (decimal)
Length = n
Spare
Instance
Procedure Transaction ID
8
3GPP
Release 10
152
3GPP TS 29.274 V10.2.0 (2011-03)
Figure 8.35-1: Procedure Transaction ID
8.36 DRX Parameter

DRX Parameter indicates whether the UE use DRX mode or not, this parameter is coded as depicted in Figure 839-1.
Octets
1
2 to 3
4
5 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
DRX Parameter
Figure 8.36-1: DRX Parameter
8.37 Void
8.38 MM Context
The MM Context information element contains the Mobility Management, UE security parameters that are necessary to
transfer over S3/S16/S10 interface.
All Spare bits are set to zeros by the sender and ignored by the receiver. Spare bits in MM Context IE shall be set to 1's
before sending MM Context IE to pre-R8 SGSN.
Security Mode indicates the type of security keys (GSM/UMTS/EPS) and Authentication Vectors
(quadruplets /quintuplets/triplets) that are passed to the new MME/SGSN.
The DRX parameter coding is specified in clause 10.5.5.6 of 3GPP TS 24.008 [5]. If DRXI (DRX Indicator), bit 4 of
octet 5, is set to "1", then the DRX parameter field is present, otherwise its octets are not present.
Uplink/downlink Subscribed UE AMBR (Aggregate Maximum Bit Rate) is coded as Unsigned32 integer values in kbps
(1000 bps) for all non-GBR bearers according to the subscription of the user. If SAMBRI (Subscribed UE AMBR
Indicator), bit 1 of octet 6, is set to "1", then the Uplink/downlink Subscribed UE AMBR parameter field is present,
otherwise these parameters are not present. If no Subscribed UE AMBR is received from the HSS, the SAMBRI shall
be set to "0".Uplink/downlink Used UE AMBR (Aggregate Maximum Bit Rate) is coded as Unsigned32 integer values
in kbps (1000 bps) for all non-GBR bearers currently being used by the UE. If UAMBRI (Used UE AMBR Indicator),
bit 2 of octet 6, is set to "1", then the Uplink/downlink Used UE AMBR parameter field is present, otherwise these
parameters are not present.
The encoding of Mobile Equipment Identity (MEI) field shall be same as specified in clause 8.10 of this specification. If
Length of Mobile Equipment Identity is zero, then the Mobile Equipment Identity parameter shall not be present. If the
UE is emergency attached and the UE is UICCless or the IMSI is unauthenticated, Mobile Equipment Identity (MEI)
shall be used as the UE identity.
The UE Network Capability coding is specified in clause 9.9.3.34 of 3GPP TS 24.301 [23]. If Length of UE Network
Capability is zero, then the UE Network Capability parameter shall not be present.
The MS Network Capability coding is specified in clause 10.5.5.12 of 3GPP TS 24.008 [5]. If Length of MS Network
Caapability is zero, then the MS Network Capability parameter shall not be present.
The Voice Domain Preference and UE's Usage Setting coding is specified in clause 10.5.5.28 of 3GPP TS 24.008 [5]. If
Length of Voice Domain Preference and UE's Usage Setting is zero, then the Voice Domain Preference and UE's Usage
Setting parameter shall not be present.
Used Cipher indicates the GSM ciphering algorithm that is in use.
Used NAS Cipher indicates the EPS ciphering algorithm that is in use.
3GPP
Release 10
153
3GPP TS 29.274 V10.2.0 (2011-03)
The Access restriction data is composed of UNA(UTRAN Not Allowed), GENA(GERAN Not Allowed), GANA(GAN
Not Allowed), INA(I-HSPA-Evolution Not Allowed), ENA(E-UTRAN Not Allowed) and HNNA(HO-To-Non-3GPPAccess Not Allowed).
As depicted in Figure 8.38-1, the GSM Key, Used Cipher and Authentication Triplets that are unused in the old SGSN
shall be transmitted to the new SGSN for the GSM subscribers.
The Authentication Triplet coding is specified in Figure 8.38-7.
Octets
1
2 to 3
4
5
6
7
8 to 15
16 to h
(h+1) to
(h+2)
j to (j+3)
(j+4) to (j+7)
i to (i+3)
(i+4) to (i+7)
q
(q+1) to k
k+1
(k+2) to m
m+1
(m+2) to r
r+1
r+2
(r+3) to s
(s+1) to
(n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Security Mode
Spare DRXI
CKSN
Number of Triplet
Spare
UAMB SAMB
RI
RI
Spare
Used Cipher
Kc
Authentication Triplet [0..4]
DRX parameter
8
Uplink Subscribed UE AMBR

Downlink Subscribed UE AMBR
Uplink Used UE AMBR
Downlink Used UE AMBR
Length of UE Network Capability
UE Network Capability
Length of MS Network Capability
MS Network Capability
Length of Mobile Equipment Identity (MEI)
Spare
HNNA ENA INA GANA GENA UNA
Length of Voice Domain Preference and UE's Usage
Setting
Voice Domain Preference and UE's Usage Setting
Figure 8.38-1: GSM Key and Triplets

As depicted in Figure 8.38-2, the UMTS Key, Used Cipher and Authentication Quintuplets that are unused in the old
SGSN shall be transmitted to the new SGSN when the UMTS subscriber is attached to a GSM BSS in the old system, in
case the user has a ME capable of UMTS AKA.
The Authentication Quintuplet coding is specified in Figure 8.38-8.
3GPP
Release 10
154
Octets
1
2 to 3
4
5
6
7
8 to 23
24 to 39
40 to h
(h+1) to
(h+2)
j to (j+3)
(j+4) to (j+7)
i to (i+3)
(j+12) to
(i+4)
q
(q+1) to k
k+1
(k+2) to m
m+1
(m+2) to r
r+1
r+2
(r+3) to s
(s+1) to
(n+4)
3GPP TS 29.274 V10.2.0 (2011-03)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Security Mode
Spare DRXI
CKSN/KSI
Number of
Spare
UAMB SAMB
Quintuplets
RI
RI
Spare
Used Cipher
CK
IK
Authentication Quintuplet [0..4]
DRX parameter

Uplink Used UE AMBR
Spare
Setting
Figure 8.38-2: UMTS Key, Used Cipher and Quintuplets

As depicted in Figure 8.38-3, the GSM Key, Used Cipher and Authentication Quintuplets that are unused in the old
SGSN shall be transmitted to the new SGSN when the UMTS subscriber is attached to a GSM BSS in the old system, in
case the user has a ME no capable of UMTS AKA.
3GPP
Release 10
155
Octets
1
2 to 3
4
5
6
7
8 to 15
16 to h
(h+1) to
(h+2)
j to (j+3)
(j+4) to (j+7)
i to (i+3)
(i+4) to (i+7)
q
(q+1) to k
k+1
(k+2) to m
m+1
(m+2) to r
r+1
r+2
(r+3) to s
(s+1) to
(n+4)
3GPP TS 29.274 V10.2.0 (2011-03)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Security Mode
Spare DRXI
CKSN/KSI
Number of
Spare
UAMB SAMB
Quintuplets
RI
RI
Spare
Used Cipher
Kc
Authentication Quintuplets [0..4]
DRX parameter

Uplink Used UE AMBR
Spare
Setting
Figure 8.38-3: GSM Key, Used Cipher and Quintuplets

As depicted in Figure 8.38-4, the UMTS Key, KSI and unused Authentication Quintuplets in the old SGSN may be
transmitted to the new SGSN/MME when the UMTS subscriber is attached to UTRAN/GERAN in the old system, but
it is not allowed to send quintuplets to an MME in a different serving network domain (see 3GPP TS 33.401 [12] clause
6.1.6). The MME may forward the UMTS Key, KSI and unused Authentication Quintuplets which were previously
stored back to the same SGSN, for further details, refer to 3GPP TS 33.401 [12].
3GPP
Release 10
156
Octets
1
2 to 3
4
5
6
7
8 to 23
24 to 39
40 to h
(h+1) to
(h+2)
j to (j+3)
(j+4) to (j+7)
i to (i+3)
(i+4) to (i+7)
q
(q+1) to k
k+1
(k+2) to m
m+1
(m+2) to r
r+1
r+2
(r+3) to s
(s+1) to
(n+4)
3GPP TS 29.274 V10.2.0 (2011-03)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Security Mode
Spare DRXI
KSI
Number of
Spare
UAMB SAMB
Quintuplets
RI
RI
Spare
CK
IK
DRX parameter

Uplink Used UE AMBR
Spare
Setting
Figure 8.38-4: UMTS Key and Quintuplets

As depicted in Figure 8.38-5, the current EPS Security Context, a non-current EPS Security Context (if available), and
unused Authentication Quadruplets in the old MME may be transmitted to the new MME. If the new MME is not in the
same serving network domain then only the current EPS Security Context may be transmitted. Authentication
Quintuplets shall not be transmitted to the new MME even if the old MME has the Authentication Quintuplets for this
UE. The value in Number of Quintuplets field shall be set to '0'. The reasons for not sending Quintuplets are specified
in3GPP TS 33.401 [12] clause 6.1.6.
The Authentication Quintuplet and Authentication Quadruplet codings are specified in Figure 8.38-8 and Figure 8.38-9
respectively.
The value of the NAS Downlink Count shall be set to the value that shall be used to send the next NAS message.
The value of the NAS Uplink Count shall be set to the largest NAS Uplink Count that was in a successfully integrity
verified NAS message.
In Figure 8.38-5, the fields for the Old EPS Security Context (i.e. octets from s to s+64) may be present only in S10
Forward Relocation Request message according to the Rules on Concurrent Running of Security Procedures, which are
specified in 3GPP TS 33.401 [12]. The octets for Old EPS Security Context shall be present if the OSCI (Old Security
Context Indicator), bit 1 of octet 6) is set to "1"; otherwise they shall not be present.
If NHI_old (Next Hop Indicator for old EPS Security Context), bit 1 of octet s, is set to "1", then the parameters old NH
(Next Hop) and old NCC (Next Hop Chaining Count) shall be present; otherwise the octets for old NH parameter shall
not be present and the value of old NCC parameter shall be ignored by the receiver.
3GPP
Release 10
157
Octets
1
2 to 3
4
5
6
7
3GPP TS 29.274 V10.2.0 (2011-03)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Security Mode
NHI DRXI
KSIASME
Number of
Number of
UAMB OSCI
Quintuplets
Quadruplet
RI
SAMB Used NAS integrity
Used NAS Cipher
RI
protection algorithm
NAS Downlink Count
NAS Uplink Count
KASME
Authentication Quadruplet [0..4]
DRX parameter
8
8 to 10
11 to 13
14 to 45
46 to g
(g+1) to h
(h+1) to
(h+2)
p to (p+31)
NH
p+32
Spare
NCC
j to (j+3)
(j+4) to (j+7)
i to (i+3)
Uplink Used UE AMBR
(i+4) to (i+7)
q
(q+1) to k
k+1
(k+2) to m
m+1
(m+2) to r
r+1
Spare
s
NHI_o Spare
old KSIASME
old NCC
ld
(s+1) to
old KASME
(s+32)
(s+33) to
old NH
(s+64)
s+65
Setting
(s+66) to t
t to (n+4)
Figure 8.38-5: EPS Security Context and Quadruplets

If NHI (Next Hop Indicator), bit 5 of octet 5, is set to "1", then the optional parameters NH (Next Hop) and NCC (Next
Hop Chaining Count) are both present, otherwise their octets are not present.
As depicted in Figure 8.38-6, the old MME will derive CK' and IK' from KASME and transmit the CK' and IK' to the new
SGSN. Authentication Quintuplets, if available, shall be transmitted to the SGSN if, and only if the MME received them
from this SGSN earlier, according to 3GPP TS 33.401 [12] clause 6.1.5.
The value in Number of Quadruplets field shall be set to '0', if Authentication Quadruplets are not present. A key KASME
shall never be transmitted to an SGSN according to 3GPP TS 33.401 [12] clause 6.4.
The Authentication Quintuplet and Authentication Quadruplet codings are specified in Figure 8.38-8 and Figure 8.38-9
respectively.
The old SGSN/MME may deliver both Authentication Quadruplets and Authentication Quintuplets it holds to the peer
combo node to optimize the procedure.
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
158
Octets
1
2 to 3
4
5
6
7
8 to 23
24 to 39
40 to g
(g+1) to h
(h+1) to
(h+2)
j to (j+3)
(j+4) to (j+7)
i to (i+3)
(i+4) to (i+7)
q
(q+1) to k
k+1
(k+2) to m
m+1
(m+2) to r
r+1
r+2
(r+3) to s
(s+1) to
(n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Security Mode
Spare DRXI
KSIASME
Number of
Number of
UAMB SAMB
Quintuplets
Quadruplet
RI
RI
Spare
CK
IK
Authentication Quadruplet [0..4]
DRX parameter

Uplink Used UE AMBR
Spare
Setting
Figure 8.38-6: UMTS Key, Quadruplets and Quintuplets

Octets
1 to 16
17 to 20
21 to 28
Bits
5
4
RAND
SRES
Kc
Figure 8.38-7: Authentication Triplet

Octets
1 to 16
17
18 to m
(m+1) to
(m+16)
(m+17) to
(m+32)
m+33
(m+34) to n
Bits
5
4
RAND
XRES Length
XRES
CK
IK
AUTN Length
AUTN
Figure 8.38-8: Authentication Quintuplet

Octets
1 to 16
17
18 to k
k+1
(k+2) to m
(m+1) to
(m+32)
Bits
5
4
RAND
XRES Length
XRES
AUTN Length
AUTN
KASME
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
159
Figure 8.38-9: Authentication Quadruplet

Table 8.38-1: Security Mode Values
Security Type
GSM Key and Triplets
UMTS Key, Used Cipher and Quintuplets
GSM Key, Used Cipher and Quintuplets
UMTS Key and Quintuplets
EPS Security Context and Quadruplets
UMTS Key, Quadruplets and Quintuplets
Value (Decimal)
0
1
2
3
4
5
Table 8.38-2: Used NAS Cipher Values

Cipher Algorithm
No ciphering
128-EEA1
128-EEA2
EEA3
EEA4
EEA5
EEA6
EEA7
Value (Decimal)
0
1
2
3
4
5
6
7
Table 8.38-3: Used Cipher Values

Cipher Algorithm
No ciphering
GEA/1
GEA/2
GEA/3
GEA/4
GEA/5
GEA/6
GEA/7
Value (Decimal)
0
1
2
3
4
5
6
7
Table 8.38-4: Used NAS integrity protection algorithm Values

Integrity protection
Algorithm
No integrity protection
128-EIA1
128-EIA2
EIA3
EIA4
EIA5
EIA6
EIA7
Value (Decimal)
0
1
2
3
4
5
6
7
8.39 PDN Connection

The PDN connection is a grouped IE containing a number of other IEs and shall be coded as depicted in Table 8.39-1.
The PDN Connection IE may be repeated within a message when more than one PDN Connection is required to be sent.
If so, the repeated IEs shall have exactly the same Instance values to represent a list of grouped IEs.
3GPP
Release 10
160
3GPP TS 29.274 V10.2.0 (2011-03)
Table 8.39-1: PDN Connection Grouped Type

Octet 1
Octets 2 and 3
Octet 4
Information
elements
NOTE:

Length = n
Condition / Comment
IE Type
Ins.
This table uses a 5-column format in order to match the format used in subclauses of clause 7, where
the usage of this IE is further detailed for each specific GTP message including it.
8.40 PDU Numbers

The PDU Numbers information element contains the sequence number status corresponding to a Bearer context in the
old SGSN. This information element shall be sent only when acknowledged peer-to-peer LLC operation is used for the
Bearer context or when the "delivery order" QoS attribute is set in the Bearer context QoS profile.
NSAPI identifies the Bearer context for which the PDU Number IE is intended.
DL GTP-U Sequence Number is the number for the next downlink GTP-U T-PDU to be sent to the UE when "delivery
order" is set.
UL GTP-U Sequence Number is the number for the next uplink GTP-U T-PDU to be tunnelled to the S-GW when
"delivery order" is set.
The Send N-PDU Number is used only when acknowledged peer-to-peer LLC operation is used for the Bearer context.
Send N-PDU Number is the N-PDU number to be assigned by SNDCP to the next down link N-PDU received from the
S-GW.
The Receive N-PDU Number is used only when acknowledged peer-to-peer LLC operation is used for the Bearer
context. The Receive N-PDU Number is the N-PDU number expected by SNDCP from the next up link N-PDU to be
received from the UE.
The PDU Number IE will be repeated for each Bearer Context for which this IE is required.
PDU Numbers IE is coded as depicted in Figure 8.40-1.
Octets
1
2 to 3
4
5
6-7
8-9
10-11
12-13
14 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Spare(0 0 0 0)
NSAPI
DL GTP-U Sequence Number
UL GTP-U Sequence Number
Send N-PDU Number
Receive N-PDU Number
8
Figure 8.40-1: PDU Numbers
8.41 Packet TMSI (P-TMSI)

The P-TMSI, unambiguously associated with a given UE and routeing area, is given by:
Octets
1
2 to 3
4
5 to (n+4)
Bits
5
4
3
2
1
Length = n
Spare
Instance
Packet TMSI (P-TMSI)
The P-TMSI is defined in 3GPP TS 23.003 [2].
7
3GPP
d)
h)
n)
p)
r)
Release 10
161
3GPP TS 29.274 V10.2.0 (2011-03)
Figure 8.41-1: Packet TMSI (P-TMSI)
8.42 P-TMSI Signature

The content and the coding of the P-TMSI Signature information element are defined in 3GPP TS 24.008 [5].
Octets
1
2 to 3
4
5 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
P-TMSI Signature
Figure 8.42-1: P-TMSI Signature
8.43 Hop Counter

Where Intra Domain Connection of RAN Nodes to Multiple CN Node is applied, the Hop Counter may be used to
prevent endless loops when relaying Identification Request messages and Context Request messages. The maximum
value is operator specific and shall not be lower than 1.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Hop Counter
8
Figure 8.43-1: Hop Counter
8.44 UE Time Zone

UE Time Zone is used to indicate the offset between universal time and local time in steps of 15 minutes of where the
UE currently resides. The "Time Zone" field uses the same format as the "Time Zone" IE in 3GPP TS 24.008 [5].
UE Time Zone is coded as this is depicted in Figure 8.44-1. The value of the Time Zone field represents the time zone
adjusted for daylight saving time. The value of the Daylight Saving Time field specifies the adjustment that has been
made.
receiving side.
Octets
1
2 to 3
4
5
6
7 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Time Zone
Spare
Daylight
Saving Time
8
Figure 8.44-1: UE Time Zone
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
162
Table 8.44-2 Possible values for the "Daylight Saving Time" field and their meanings.
Daylight Saving Time
No adjustment for Daylight Saving Time
+1 hour adjustment for Daylight Saving Time
+2 hours adjustment for Daylight Saving Time
Spare
Value (binary)
Bit 2
Bit 1
0
0
0
1
1
0
1
1
8.45 Trace Reference

Trace Reference shall be coded as depicted in Figure 8.45-1. See 3GPP TS 32.422 [18], clause 5.6, for the definition of
Trace Reference.
See 3GPP TS 24.008 [5], clause 10.5.1.4, Mobile Identity, for the coding of MCC and MNC, whose values are obtained
from the serving PLMN that the EM/NM is managing. If MNC is 2 digits long, bits 5 to 8 of octet 6 are coded as
"1111".
Octets
1
2 to 3
4
5
6
7
8 to10
Bits
6
5
4
3
2
Length = 6
Spare
Instance
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
Trace ID
7
Figure 8.45-1: Trace Reference
8.46 Complete Request Message

The Complete Request Message is coded as depicted in Figure 8.46-1.
Octets
1
2 to 3
4
5
6- to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
Complete Request Message Type
Complete Request Message
Figure 8.46-1: Complete Request Message

Complete Request Message type values are specified in Table 8.46-1.
Table 8.46-1: Complete Request Message type values and their meanings
Location Types
Complete Attach Request Message
Complete TAU Request Message
<spare>
8.47 GUTI
The GUTI is coded as depicted in Figure 8.47-1.
3GPP
Values (Decimal)
0
1
2-255
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
163
Octets
1
2 to 3
4
5
6
7
8 to 9
10
11 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
MME Group ID
MME Code
M-TMSI
7
Figure 8.47-1: GUTI

8.48 Fully Qualified Container (F-Container)

Fully Qualified Container (F-TEID) is coded as depicted in Figure 8.48-1.
All Spare bits are set to zeros by the sender and ignored by the receiver. If the F-Container field is constructed from the
received container in the message on the Iu-PS or S1-AP interface, the F-Container field shall be encoded as the content
part (excluding IE-ID, criticality, pad and length part) of corresponding parameter.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
Spare
Container Type
F-Container field
Figure 8.48-1: Full Qualified Container (F-Container)

The Container Type is coded as below:
-
If this field is set to 1, then the F-Container field present the UTRAN transparent container.
If this field is set to 2, then the F-Container field present the BSS container.
If this field is set to 3, then the F-Container field present the E-UTRAN transparent container.
The BSS Container IE in the Bearer Context IE in Forward Relocation Request and Context Response messages is
coded as depicted in Figure 8.48-2.
Bits
Octets
6
a
b
c
d to n
4
3
2
1
PHX SAPI RP
PFI
Packet Flow ID
SAPI
Spare
Radio Priority
XiD parameters length
XiD parameters
Spare
Figure 8.48-2: BSS Container

The flags PFI, RP, SAPI and PHX in octet 6 indicate the corresponding type of paratemer (Packet FlowID, Radio
Priority, SAPI and PS handover XID parameters) shall be present in a respective field or not. If one of these flags is set
to "0", the corresponding field shall not be present at all. The Spare bit shall be set to zero by the sender and ignored by
the receiver.
If PFI flag is set, Packet Flow ID shall be present in Octet a.
If RP flag is set, Radio Priority shall be present in Octet b.
If SAPI flag is set, SAPI shall be present in Octet b.
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
164
If PHX flag is set:

-
XiD parameters length is present in Octet c.
XiD parameters are present in Octet d to n.
8.49 Fully Qualified Cause (F-Cause)

Fully Qualified Cause (F- Cause) is coded as depicted in Figure 8.49-1.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
Spare
Cause Type
F-Cause field
Figure 8.49-1: Full Qualified Cause (F-Cause)

The value of Instance field of the F-Cause IE in a GTPv2 message shall indicate whether the F-Cause field contains
RANAP Cause, BSSGP Cause or RAN Cause. If the F-Cause field contains RAN Cause, the Cause Type field shall
contain the RAN cause subcategory as specified in 3GPP TS 36.413 [10] and it shall be encoded as in Table 8.49-1. If
the F-Cause field contains BSSGP Cause or RANAP Cause, the Cause Type field shall be ignored by the receiver.
All spare bits shall be set to zeros by the sender and ignored by the receiver.
F-Cause field is coded as follows:
-
For RANAP Cause, the F-Cause field contains the cause as defined in clause 9.2.1.4 in 3GPP TS 25.413 [33].
The value of F-Cause field (which has a range of 1..512) is transferred over the Iu interface and encoded into two
octet as binary integer.
For BSSGP Cause, the F-Cause field contains the cause as defined in clause 11.3.8 in 3GPP TS 48.018 [34]. The
value of F-Cause field (which has a range of 0..255) is transferred over the Gb interface and encoded into one
octet as binary integer.
For RAN Cause, the F-Cause field contains the cause as defined in clause 9.2.1.3 in 3GPP TS 36.413 [10]. The
value of F-Cause field (and the associated RAN cause subcategory) is transferred over the S1-AP interface and
encoded into one octet as binary integer.
Table 8.49-1: Cause Type values and their meanings
Cause Type
Radio Network Layer
Transport Layer
NAS
Protocol
Miscellaneous
Values (Decimal)
0
1
2
3
4
<spare>
5 to15
8.50 Selected PLMN ID

The Selected PLMN ID IE contains the core network operator selected for tne UE in a shared network. Octets 5-7 shall
be encoded as the content part of the "Selected PLMN Identity" parameter in 3GPP TS 36.413 [10].
Octets
1
2 to 3
4
5 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
Selected PLMN ID
3GPP
Release 10
165
3GPP TS 29.274 V10.2.0 (2011-03)
Figure 8.50-1: Selected PLMN ID
8.51 Target Identification

The Target Identification information element is coded as depicted in Figure 8.51-1.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
Target Type
Target ID
Figure 8.51-1: Target Identification

Target Type values are specified in Table 8.51-1.
The Target Type is RNC ID for SRNS relocation procedure, handover to UTRAN and RAN Information Relay towards
UTRAN or GERAN operating in GERAN Iu mode. In this case the Target ID field shall be encoded as the Target RNCID part of the "Target ID" parameter in 3GPP TS 25.413 [33]. Therefore, the "Choice Target ID" that indicates "Target
RNC-ID" (numerical value of e.g. 0x20) shall not be included (value in octet 5 specifies the target type).
The Target Type is Macro eNodeB ID for handover to E-UTRAN Macro eNodeB and RAN Information Relay towards
E-UTRAN. In this case the coding of the Target ID field shall be coded as depicted in Figure 8.51-2.
Octets
6
7
8
9
10 to 11
12 to 13
Bits
7
6
5
4
3
2
1
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
Spare
Macro eNodeB ID
Macro eNodeB ID
Figure 8.51-2: Target ID for Type Macro eNodeB

The Macro eNodeB ID consists of 20 bits. Bit 4 of Octet 9 is the most significant bit and bit 1 of Octet 11 is the least
significant bit. The coding of the Macro eNodeB ID is the responsibility of each administration. Coding using full
hexadecimal representation shall be used.
The Target Type is Home eNodeB ID for handover to E-UTRAN Home eNodeB. In this case the coding of the Target
ID field shall be coded as depicted in Figure 8.51-3.
Octets
6
7
8
9
10 to 12
13 to 14
Bits
7
6
5
4
3
2
1
MCC digit 2
MCC digit 1
MNC digit 3
MCC digit 3
MNC digit 2
MNC digit 1
Spare
Home eNodeB ID
Home eNodeB ID
Figure 8.51-3: Target ID for Type Home eNodeB

The Home eNodeB ID consists of 28 bits. See 3GPP TS 36.413 [10]. Bit 4 of Octet 9 is the most significant bit and bit 1
of Octet 12 is the least significant bit. The coding of the Home eNodeB ID is the responsibility of each administration.
Coding using full hexadecimal representation shall be used.
The Target Type is Cell Identifier for handover to GERAN and RAN Information Relay towards GERAN. In this case
the coding of the Target ID field shall be same as the Octets 3 to 10 of the Cell Identifier IEI in 3GPP TS 48.018 [34].
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
166
Table 8.51-1: Target Type values and their meanings

Target Types
RNC ID
Macro eNodeB ID
Cell Identifier
Home eNodeB ID
<spare>
Values (Decimal)
0
1
2
3
4 to 255
8.52 Void
8.53 Packet Flow ID
The Packet Flow Id information element contains the packet flow identifier assigned to an EPS Bearer context as
identified by EPS Bearer ID.
The spare bits 8 to 5 in octet 5 indicate unused bits, which shall be set to 0 by the sending side and which shall not be
evaluated by the receiving side.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
Spare
EBI
Packet Flow ID
Figure 8.53-1: Packet Flow ID
8.54 RAB Context

The RAB Context shall be coded as is depicted in Figure 8.54-1.
Octets
1
2 to 3
4
5
6 to 7
8 to 9
10 to 11
12 to 13
Bits
6
5
4
3
2
Length = 9
Spare
Instance
Spare
NSAPI
DL GTP-U Sequence Number
UL GTP-U Sequence Number
DL PDCP Sequence Number
UL PDCP Sequence Number
Figure 8.54-1: RAB Context

The RAB Context IE may be repeated within a message with exactly the same Type and Instance to represent a list.
The RAB context information element contains sequence number status for one RAB in RNC, which corresponds to
one PDP context. The RAB contexts are transferred between the RNCs via the SGSNs at inter SGSN hard handover.
NSAPI identifies the PDP context and the associated RAB for which the RAB context IE is intended.
DL GTP-U Sequence Number is the number for the next downlink GTP-U T-PDU to be sent to the UE.
UL GTP-U Sequence Number is the number for the next uplink GTP-U T-PDU to be tunnelled to the SGW.
DL PDCP Sequence Number is the number for the next downlink PDCP-PDU to be sent to the UE.
UL PDCP Sequence Number is the number for the next uplink PDCP-PDU to be received from the UE.
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
167
8.55 Source RNC PDCP context info

The purpose of the Source RNC PDCP context info IE is to transfer RNC PDCP context information from a source
RNC to a target RNC during an SRNS relocation.
Octets
1
2 to 3
4
5 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
RRC Container
Figure 8.55-1: Source RNC PDCP context info
8.56 UDP Source Port Number

UDP Source Port Number is coded as depicted in Figure 8.56-1.
Octets
1
2 to 3
4
5 to 6
7 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
8
Figure 8.56-1: UDP Source Port Number
8.57 APN Restriction

The APN Restriction information element contains an unsigned integer value indicating the level of restriction imposed
on EPS Bearer Contexts created to the associated APN.
The APN Restriction IE is coded as depicted in Figure 8.57-1:
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Restriction Type value
8
Figure 8.57-1: APN Restriction Type Information Element

An APN Restriction value may be configured for each APN in the PGW. It is used to determine, on a per UE basis,
whether it is allowed to establish EPS bearers to other APNs.
Table 8.57-1: Valid Combinations of APN Restriction
Maximum
APN
Restriction
Value
0
Type of APN
Application Example
No Existing Contexts or Restriction
1
2
3
Public-1
Public-2
Private-1
Private-2
APN Restriction Value allowed to be

established
All
MMS
Internet
Corporate (e.g. who use
MMS)
Corporate (e.g. who do not
use MMS)
3GPP
1, 2, 3
1, 2
1
None
Release 10
168
3GPP TS 29.274 V10.2.0 (2011-03)
8.58 Selection Mode

The Selection mode information element indicates the origin of the APN in the message.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Spare
Selec. Mode
8
Figure 8.58-1: Selection Mode Information Element

Table 8.58-1: Selection Mode Values
Selection mode value
Value (Decimal)
MS or network provided APN, subscribed verified

MS provided APN, subscription not verified
Network provided APN, subscription not verified
For future use. Shall not be sent. If received, shall be interpreted as the value "2".
0
1
2
3
8.59 Source Identification

The Source Identification information element is coded as depicted in Figure 8.59-1.
Octets
1
2 to 3
4
5 to 12
13
14 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
Target Cell ID
Source Type
Source ID
Figure 8.59-1: Source Identification

The Target Cell ID shall be same as the Octets 3 to 10 of the Cell Identifier IEI in 3GPP TS 48.018 [34].
Source Type values are specified in Table 8.59-1.
The Source Type is Cell ID for PS handover from GERAN A/Gb mode. In this case the coding of the Source ID field
shall be same as the Octets 3 to 10 of the Cell Identifier IEI in 3GPP TS 48.018 [34].
The Source Type is RNC ID for PS handover from GERAN Iu mode or for inter-RAT handover from UTRAN. In this
case the Source ID field shall be encoded as as the Source RNC-ID part of the "Source ID" parameter in 3GPP TS
25.413 [33].
Table 8.59-1: Source Type values and their meanings
Source Types
Values (Decimal)
Cell ID
0
RNC ID
1
reserved (NOTE)
2
<spare>
3-255
NOTE:
This value was allocated in an earlier version of the protocol and
shall not be used.
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
169
8.60 Void
8.61 Change Reporting Action
Change Reporting Action IE is coded as depicted in Figure 8.61-1.
Octets
1
2 to 3
4
5 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
Action
Figure 8.61-1: Change Reporting Action

Table 8.61-1: Action values
Action
Stop Reporting
Start Reporting CGI/SAI
Start Reporting RAI
Start Reporting TAI
Start Reporting ECGI
Start Reporting CGI/SAI and RAI
Start Reporting TAI and ECGI
<spare>
Value (Decimal)
0
1
2
3
4
5
6
7-255
Stop Reporting stops all reporting action types.
8.62 Fully qualified PDN Connection Set Identifier (FQ-CSID)

A fully qualified PDN Connection Set Identifier (FQ-CSID) identifies a set of PDN connections belonging to an
arbitrary number of UEs on a MME, SGW, ePDG or PGW. The FQ-CSID is used on S5, S8, S2b and S11 interfaces.
The size of CSID is two octets. The FQ-CSID is coded as follows:
Octets
1
2 to -3
4
5
6 to p
(p+1) to
(p+2)
(p+3) to
(p+4)
...
q to q+1
(q+2) to
(n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Node-ID Type
Number of CSIDs= m
Node-ID
First PDN Connection Set Identifier (CSID)
7
Second PDN Connection Set Identifier (CSID)

...
m-th PDN Connection Set Identifier (CSID)
Figure 8.62-1: FQ-CSID

Where Node-ID Type values are:
0 indicates that Node-ID is a global unicast IPv4 address and p = 9.
1 indicates that Node-ID is a global unicast IPv6 address and p = 21.
2 indicates that Node-ID is a 4 octets long field with a 32 bit value stored in network order, and p= 9. The coding
of the field is specified below:
3GPP
Release 10
170
3GPP TS 29.274 V10.2.0 (2011-03)
Most significant 20 bits are the binary encoded value of (MCC * 1000 + MNC).
Least significant 12 bits is a 12 bit integer assigned by an operator to an MME, SGW, ePDG or PGW. Other
values of Node-ID Type are reserved.
Values of Number of CSID other than 1 are only employed in the Delete PDN Connection Set Request and Response.
The node that creates the FQ-CSID, (i.e. MME for MME FQ-CSID, SGW for SGW FQ-CSID, ePDG for ePDG FQCSID and PGW for PGW FQ-CSID), is responsible for making sure the Node-ID is globally unique and the CSID value
is unique within that node.
When a FQ-CSID is stored by a receiving node, it is stored on a PDN basis even for messages impacting only one
bearer (i.e. Create Bearer Request). See 3GPP TS 23.007 [17] for further details on the CSID and what specific
requirements are placed on the PGW, ePDG, SGW and MME.
8.63 Channel needed

The Channel needed shall be coded as depicted in Figure 8.63-1. Channel needed is coded as the IEI part and the value
part of the Channel Needed IE defined in 3GPP TS 44.018[28]
Octets
1
2 to 3
4
5 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
Channel Needed
Figure 8.63-1: Channel needed
8.64 eMLPP Priority

The eMLPP-Priority shall be coded as depicted in Figure 8.64-1. The eMLPP Priority is coded as the value part of the
eMLPP-Priority IE defined in 3GPP TS 48.008 [29] (not including 3GPP TS 48.008 IEI and 3GPP TS 48.008 [29]
length indicator).
Octets
1
2 to 3
4
5 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
eMLPP-Priority
Figure 8.64-1: eMLPP Priority
8.65 Node Type

Node Type is coded as this is depicted in Figure 8.65-1.
Octets
1
2-3
4
5
6-(n+4)
Bits
6
5
4
3
2
1
Length = n (decimal)
Spare
Instance
Node Type
8
Figure 8.65-1: Node Type

Node type values are specified in Table 8.65-1.
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
171
Table 8. 65-1: Node Type values

Node Types
MME
SGSN
<spare>
Values (Decimal)
0
1
2-255
8.66 Fully Qualified Domain Name (FQDN)

Fully Qualified Domain Name (FQDN) is coded as depicted in Figure 8.66-1.
Octets
1
2 to 3
4
5 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
FQDN
Figure 8.66-1: Fully Qualified Domain Name (FQDN)

The FQDN field encoding shall be identical to the encoding of a FQDN within a DNS message of section 3.1 of IETF
RFC 1035 [31] but excluding the trailing zero byte.
NOTE 1: The FQDN field in the IE is not encoded as a dotted string as commonly used in DNS master zone files.
A "PGW node name" IE in S3/S10/S16 GTP messages shall be a PGW host name as per subclause 4.3.2 of 3GPP TS
29.303 [32] when the PGW FQDN IE is populated from 3GPP TS 29.303 [32] procedures. Specifically, the first DNS
label is either "topon" or "topoff", and the canonical node name of the PGW starts at the third label. The same rules
apply to "SGW node name" IE on S3/S10/S16.
NOTE 2: The constraint of subclause 4.3.2 of 3GPP TS 29.303 format is on populating the IE by 3GPP nodes for
3GPP nodes, the receiver shall not reject an IE that is otherwise correctly formatted since the IE might be
populated for a non-3GPP node.
8.67 Private Extension

Private Extension is coded as depicted in Figure 8.Figure 8.67-1.
Enterprise ID can be found at IANA web site (http://www.iana.org/assignments/enterprise-numbers).
Octets
1
2 to 3
4
5 to 6
7 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
Enterprise ID
Proprietary value
Figure 8.67-1. Private Extension
8.68
Transaction Identifier (TI)
Transaction Identifier is coded as depicted in Figure 8.68-1. It is defined in 3GPP TS 24.301 [23], clause 9.9.4.17 and is
coded as specified in 3GPP TS 24.007 [30], clause 11.2.3.1.3 Transaction identifier.
Octets
1
2 to 3
4
5 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
Transaction Identifier
3GPP
Release 10
172
3GPP TS 29.274 V10.2.0 (2011-03)
Figure 8.68-1: Transaction Identifier
8.69 MBMS Session Duration

The MBMS Session Duration is defined in 3GPP TS 23.246 [37]. The MBMS Session Duration information element
indicates the estimated session duration of the MBMS service data transmission if available. The payload shall be
encoded as per the MBMS-Session-Duration AVP defined in 3GPP TS 29.061 [38], excluding the AVP Header fields (as
defined in IETF RFC 3588 [39], section 4.1).
Octets
1
2 to 3
4
5 to 7
8 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
MBMS Session Duration
8
Figure 8.69-1: MBMS Session Duration
8.70 MBMS Service Area

The MBMS Service Area is defined in 3GPP TS 23.246 [37]. The MBMS Service Area information element indicates
the area over which the Multimedia Broadcast Multicast Service is to be distributed. The payload shall be encoded as
per the MBMS-Service-Area AVP defined in 3GPP TS 29.061 [38], excluding the AVP Header fields (as defined in
IETF RFC 3588 [39], section 4.1).
Octets
1
2 to 3
4
5 to (n+4)
Bits
6
5
4
3
2
Length = n
Spare
Instance
MBMS Service Area
Figure 8.70-1: MBMS Service Area
8.71 MBMS Session Identifier

The MBMS Session Identifier information element contains a Session Identifier allocated by the BM-SC. The MBMS
Session Identifier value part consists of 1 octet. The content and the coding are defined in 3GPP TS 29.061 [38].
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
MBMS Session Identifier
8
Figure 8.71-1: MBMS Session Identifier
8.72 MBMS Flow Identifier

The MBMS Flow Identifier is defined in 3GPP TS 23.246 [37]. In broadcast mode, the MBMS Flow Identifier
information element is included in MBMS Session Management messages to differentiate the different sub-sessions of
an MBMS user service (identified by the TMGI) providing location-dependent content. The payload shall be encoded as
per the MBMS-Flow-Identifier AVP defined in 3GPP TS 29.061 [38], excluding the AVP Header fields (as defined in
IETF RFC 3588 [39], section 4.1).
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
173
Octets
1
2 to 3
4
5 to 6
7 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
MBMS Flow Identifer
8
Figure 8.72-1: MBMS Flow Identifier
8.73 MBMS IP Multicast Distribution

The MBMS IP Multicast Distribution IE is sent by the MBMS GW to the MME/SGSN in the MBMS Session Start
Request. Source Specific Multicasting is used according to IETF RFC 4607 [40].
The IP Multicast Distribution Address and the IP Multicast Source Address fields contain the IPv4 or IPv6 address as
defined in 3GPP TS 23.003 [2]. The Address Type and Address Length fields from 3GPP TS 23.003 [2] shall be
included in each field.
MBMS HC Indicator represents an indication if header compression should be used for MBMS user plane data. The
values are defined in 3GPP TS 25.413 [33].
Octets
1
2 to 3
4
5 to 8
9 to k
(k+1) to
(m+3)
m+4
(m+5) to
(n+4)
Bits
6
5
4
3
2
1
Length=n
Spare
Instance
Common Tunnel Endpoint Identifier Data
IP Multicast Distribution Address (IPv4 or IPv6)
IP Multicast Source Address (IPv4 or IPv6)
7
MBMS HC Indicator
Figure 8.73-1: MBMS IP Multicast Distribution
8.74 MBMS Distribution Acknowledge

The MBMS Distribution Acknowledge IE is sent by the SGSN to the MBMS GW in the MBMS Session Start Response
and MBMS Session Update Response. It is used by the MBMS GW to decide if an IP Multicast Distribution user plane
shall be established, or a normal point-to-point user plane, or both.
Octets
1
2 to 3
4
5
6 to n+4
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Spare
Distr Ind
8
Figure 8.74-1: MBMS Distribution Acknowledge
Table 8.74-1: Distribution Indication values

Distribution Indication
No RNCs have accepted IP multicast distribution
All RNCs have accepted IP multicast distribution
Some RNCs have accepted IP multicast distribution
Spare. For future use.
3GPP
Value (Decimal)
0
1
2
3
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
174
8.75 User CSG Information (UCI)

User CSG Information (UCI) is coded as depicted in Figure 8.75-1. The CSG ID is defined in 3GPP TS 23.003 [2].
Bits
Octets
8
7
6
5
4
3
2
1
1
Type = 145
2 to 3
Length = n
4
Spare
Instance
5
MCC digit 2
MCC digit 1
6
MNC digit 3
MCC digit 3
7
MNC digit 2
MNC digit 1
8
spare
CSG ID
9 to11
CSG ID
12
Access mode
spare
LCSG CMI
13 to (n+4)
Figure 8.75-1: User CSG Information

For two digits in the MNC, bits 5 to 8 of octet 6 are coded as "1111".
The CSG ID consists of 4 octets. Bit 3 of Octet 8 is the most significant bit and bit 1 of Octet 11 is the least significant
bit. The coding of the CSG ID is the responsibility of the operator that allocates the CSG ID by administrative means.
Access mode values are specified in Table 8.75-1.
Table 8.75-1: Access mode values and their meanings
Access Mode
Closed Mode
Hybrid Mode
Reserved
Values (Decimal)
0
1
2-3
Leave CSG flag (LCSG) shall be set to "1" if UE leaves CSG cell/Hybrid cell, and in this case, the receiving node shall
ignore the rest information in the IE.
CSG Membership Indication (CMI) values are specified in Table 8.75-2. CMI shall be included in the User CSG
Information if the Access mode is Hybrid Mode. For the other values of Access Mode, the CMI shall be set to 0 by the
sender and ignored by the receiver.
Table 8.75-2: CSG Membership indication (CMI)
CMI
Non CSG membership
CSG membership
Values (Decimal)
0
1
8.76 CSG Information Reporting Action

CSG Information Reporting Action is coded as depicted in Figure 8.76-1.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
5
4
Type = 146
Length = n
Spare
Spare
Instance
UCIU UCIS UCIC
HC
HC
SG
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
175
Figure 8.76-1: CSG Reporting Action

Bit 1 UCICSG: When set to "1", shall indicate to start reporting User CSG Info when the UE
enters/leaves/access through the CSG Cell.
Bit 2 UCISHC: When set to "1", shall indicate to start reporting User CSG Info when the UE
enters/leaves/access through Subscribed Hybrid Cell.
Bit 3 UCIUHC: When set to "1", shall indicate to start Reporting User CSG Info when the UE
enters/leaves/access through Unsubscribed Hybrid Cell.
All the bits 1 to 3 shall be set to 0 to stop reporting User CSG Info.
8.77
RFSP Index
Index to RAT/Frequency Selection Priority (RFSP Index) is coded as depicted in Figure 8.77-1. It is defined in 3GPP
TS 36.413 [10] as Subscriber Profile ID for RAT/Frequency priority (SPIRFP). The SPIRFP is an integer between 1 and
256, which requires two octets.
Octets
1
2 to 3
4
5 to 6
Bits
6
5
4
3
2
Length = 2
Spare
Instance
RFSP Index
Figure 8.77-1. RFSP Index
8.78 CSG ID
CSG ID is coded as depicted in Figure 8.78-1. The CSG ID is defined in 3GPP TS 23.003 [2].
Octets
1
2 to 3
4
5
6 to 8
9 to (n+4)
Bits
5
4
Type = 147
Length = n
Spare
Spare
Instance
CSG ID
CSG ID
Figure 8.78-1: CSG ID

The CSG ID consists of 4 octets. Bit 3 of Octet 4 is the most significant bit and bit 1 of Octet 7 is the least significant
bit. The coding of the CSG ID is the responsibility of the operator that allocates the CSG ID by administrative means.
8.79 CSG Membership Indication (CMI)

CSG Membership Indication is coded as depicted in Figure 8.79-1.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
5
4
Type = 148
Length = n
Spare
Instance
Spare
CMI
Figure 8.79-1: CSG Membership Indication
3GPP
Release 10
3GPP TS 29.274 V10.2.0 (2011-03)
176
Table 8.79-1: void

CSG Membership Indication (CMI) values are specified in Table 8.79-2.
Table 8.79-2: CSG Membership indication (CMI)
CMI
CSG membership
Non CSG membership
8.80
Values (Decimal)
0
1
Service indicator
Service indicator is coded as depicted in Figure 8.80-1.

Octets
1
2 to 3
4
5
Bits
6
5
4
3
2
Length = 1
Spare
Instance
Service indicator
Figure 8.80-1. Service indicator

Service indicator values are specified in Table 8.80-1.
Table 8.80-1: Service indicator values
Service indicator
<spare>
CS call indicator
SMS indicator
<spare>
Values (Decimal)
0
1
2
3-255
8.81 Detach Type

Detach Type is coded as depicted in Figure 8.81-1.
Octets
1
2 to 3
4
5
Bits
6
5
4
3
2
Length = 1
Spare
Instance
Detach Type
Figure 8.81-1: Detach Type

Table 8.81-1: Detach Type values
Detach Types
<reserved>
PS Detach
Combined PS/CS Detach
<spare>
Values (Decimal)
0
1
2
3-255
8.82 Local Distinguished Name (LDN)

Represents the Local Distinguished Name (LDN) of the network element (see 3GPP TS 32.423 [44]).
3GPP
Release 10
177
Octets
1
2 to 3
4
5 to (n+4)
3GPP TS 29.274 V10.2.0 (2011-03)
Bits
6
5
4
3
2
Length = n
Spare
Instance
LDN
Figure 8.82-1: Local Distinguished Name (LDN)

The LDN field consists of 1 up to a maximum of 400 ASCII characters, i.e., from 1 up to a maximum of 400 octets.
8.83 Node Features

Node Features IE is coded as depicted in Figure 8. 83-1.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Supported-Features
8
Figure 8.83-1: Node Features IE

The Node Features IE takes the form of a bitmask where each bit set indicates that the corresponding feature is
supported. Spare bits shall be ignored by the receiver. The same bitmask is defined for all GTPv2 interfaces.
The following table specifies the features defined on GTPv2 interfaces and the interfaces on which they apply.
Table 8.83-1: Node Features on GTPv2 interfaces
Feature Octet / Bit
5/1
Feature
PRN
Interface
Description
PGW Restart Notification.
If both the SGW and the MME/S4-SGSN support
this feature, SGW shall send PGW Restart
Notification message to MME/S4-SGSN when the
SGW detects that the peer PGW has restarted, as
specified in subclause 7.9.5.
5/2
MABR
S11
Modify Access Bearers Request.
If both the SGW and the MME support this feature,
the MME may modify the S1-U bearers of all the
PDN connections of the UE by sending a Modify
Access Bearers Request message as specified in
subclause 7.2.24.
5/3
NTSR
S11/S4
Network Triggered Service Restoration procedure.
If both the SGW and the MME/S4-SGSN support
this feature (see 3GPP TS 23.007 [17]), the SGW
shall send a Downlink Data Notification message
including the IMSI to the MME/S4-SGSN on the
TEID 0 as part of a network triggered service
restoration procedure.
Feature Octet / Bit: The octet and bit number within the Supported-Features IE, e.g. "5 / 1".
Feature: A short name that can be used to refer to the octet / bit and to the feature.
Interface: A list of applicable interfaces to the feature.
Description: A clear textual description of the feature.
S11, S4
No features have been defined on the following GTPv2 interfaces in this version of the specification: S2b, S5, S8, S10,
S3, S16, Sv, S101, Sm, Sn.
3GPP
Release 10
178
3GPP TS 29.274 V10.2.0 (2011-03)
8.84 MBMS Time to Data Transfer

The MBMS Time to Data Transfer indicates the minimum time occurring between the transmission of the MBMS
SESSION START REQUEST message and the actual start of the data transfer. It is coded as shown in figure 8.84-1.
Octet 5 is coded as the value part of the Time to MBMS Data Transfer IE defined in 3GPP TS 48.018 [34] (not
including the IEI and length indicator octets specified in 3GPP TS 48.018 [34]).
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
MBMS Time to Data Transfer value part
8
Figure 8.84-1: MBMS Time to Data Transfer
8.85 Throttling
Throttling is coded as depicted in Figure 8.85-1.
Octets
1
2 to 3
4
5
6
7 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Throttling Delay Unit
Throttling Delay Value
Throttling Factor
8
Figure 8.85-1: Throttling

Table 8.85.1: Throttling information element
Throttling Delay (octet 5)
Bits 5 to 1 represent the binary coded timer value.
Bits 6 to 8 defines the timer unit for the timer as follows:
Bits
876
0 0 0 value is incremented in multiples of 2 seconds
0 0 1 value is incremented in multiples of 1 minute
0 1 0 value is incremented in multiples of 10 minutes
0 1 1 value is incremented in multiples of 1 hour
1 0 0 value is incremented in multiples of 10 hours
1 1 1 value indicates that the timer is deactivated.
Other values shall be interpreted as multiples of 1 minute.
Throttling Factor (octet 6)
The Throttling Factor indicates a percentage and may take binary coded integer
values from and including 0 up to and including 100. Other values shall be
considered as 0.
8.86 Allocation/Retention Priority (ARP)

Allocation/Retention Priority (ARP) is coded as depicted in Figure 8.86-1.
3GPP
Release 10
179
Octets
1
2 to 3
4
5
6 to (n+4)
3GPP TS 29.274 V10.2.0 (2011-03)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Spare PCI
PL
Spare PVI
8
Figure 8.86-1: Allocation/Retention Priority (ARP)

The meaning and value range of the parameters within the ARP are defined in 3GPP TS 29.212 [29]. The bits within the
octet 5 are:
-
Bit 1 PVI (Pre-emption Vulnerability): See 3GPP TS 29.212[29], clause 5.3.47 Pre-emption-Vulnerability AVP.
Bit 2 spare
Bits 3 to 6 PL (Priority Level): See 3GPP TS 29.212[29], clause 5.3.45 ARP-Value AVP. PL encodes each
priority level defined for the ARP-Value AVP as the binary value of the priority level.
Bit 7 PCI (Pre-emption Capability): See 3GPP TS 29.212[29], clause 5.3.46 Pre-emption-Capability AVP.
Bit 8 spare.
8.87 EPC Timer

The purpose of the EPC Timer information element is to specify EPC specific timer values.
The EPC Timer information element is coded as shown in figure 8.87-1 and table 8.87.1
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Timer unit
Timer value
8
Figure 8.87-1: EPC Timer

Table 8.87.1: EPC Timer information element
Timer value
Bits 5 to 1 represent the binary coded timer value.
Timer unit
Bits 6 to 8 defines the timer value unit for the EPC timer as follows:
Bits
876
0 0 0 value is incremented in multiples of 2 seconds
0 0 1 value is incremented in multiples of 1 minute
0 1 0 value is incremented in multiples of 10 minutes
0 1 1 value is incremented in multiples of 1 hour
1 0 0 value is incremented in multiples of 10 hours
1 1 1 value indicates that the timer is infinite
Other values shall be interpreted as multiples of 1 minute in this version of the
protocol.
Timer unit and Timer value both set to all "zeros" shall be interpreted as an
indication that the timer is stopped.
3GPP
Release 10
180
3GPP TS 29.274 V10.2.0 (2011-03)
8.88 Signalling Priority Indication

The Signalling Priority Indication information element contains signalling priority indications received from the UE for
a specific PDN connection.
The Signalling Priority Indication information element is coded as shown in figure 8.88-1.
Octets
1
2 to 3
4
5
6 to (n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
Spare
LAPI
8
Figure 8.88-1: Signalling Priority Indication

-
Bit 8 to 2 Spare, for future use and set to zero.
Bit 1 LAPI (Low Access Priority Indication): This bit defines if the UE indicated low access priority when
establishing the PDN connection. It shall be encoded as the Low Priority parameter of the Device Properties IE
in 3GPP TS 24.008 [5]. The receiver shall assume the value "0" if the Signalling Priority Indication IE is
applicable for a message but not included in that message by the sender. The low access priority indication may
be included in charging records.
8.89 Temporary Mobile Group Identity (TMGI)

The TMGI contains the Temporary Mobile Group Identity allocated to the MBMS Bearer Service. The BM-SC always
includes the MCC and MNC when allocating the TMGI, see 3GPP TS 29.061 [38].
It is coded as specified in Figure 8.89-1.
Octets
1
2 to 3
4
5-10
11-(n+4)
Bits
6
5
4
3
2
1
Length = n
Spare
Instance
TMGI
8
Figure 8.89-1: TMGI

Octets 5 to 10 shall be encoded as octets 3 to octet 8 in the figure 10.5.154 of 3GPP TS 24.008 [5].
Security
GTPv2-C communications shall be protected according to security mechanisms defined in 3GPP TS 33.401 [12].
10
IP - The Networking Technology used by GTP
10.1 IP Version
GTPv2 entities shall support both versions of the Internet Protocol, version 4 (IPv4) as defined by IETF RFC 791 [6],
and version 6 (IPv6) as defined by IETF RFC 2460 [16].
3GPP
Release 10
181
3GPP TS 29.274 V10.2.0 (2011-03)
10.2 IP Fragmentation
It is specified here how the fragmentation mechanism shall work with GTP-C.
Fragmentation should be avoided if possible. Examples of fragmentation drawbacks are:
-
Fragmentation is inefficient, since the complete IP header is duplicated in each fragment.
If one fragment is lost, the complete packet has to be discarded. The reason is that no selective retransmission of
fragments is possible.
Path MTU discovery should be used, especially if GTPv2-C message is encapsulated with IPv6 header. The application
should find out the path MTU, and thereby utilise more efficient fragmentation mechanisms.
11
Notification of supported features between peer

GTP-C entities
11.1 General
11.1.1 Introduction
New functionality, i.e. functionality beyond the Rel-9 standard, which can not be specified without backward
incompatible changes (e.g. requiring support of a new message or a specific receiver node's behaviour) should be
introduced as a feature, see subclause 11.1.2.
A GTP-C entity should verify that a backward incompatible feature is supported by its peer GTP entities before starting
to use it.
NOTE:
GTPv2 does not support a Comprehension Required mechanism allowing a sender to force the receiver to
support comprehension of some specific IEs as a precondition to process a backward incompatible
message.
Features may be generic node capabilities supported homogeneously for all GTP tunnels, UEs and PDN connections.
Such features are referred in this specification as "Node Features". They are signalled with the granularity of a node on
all GTPv2 interfaces (i.e. S11, S4, S5, S8, S10, S3, S16, Sv, S101, Sm, Sn, S2b). A GTP-C entity may discover the
features supported by a peer GTP-C entity with which it is in direct contact as specified in subclause 11.2.1.
11.1.2 Defining a feature

A feature is a function extending the base GTPv2 functionality that has a significant meaning to the operation of
GTPv2, i.e. a single new parameter without a substantial meaning to the functionality of the GTPv2 endpoints should
not be defined to be a new feature.
A functionality requiring the definition of a new GTPv2 message or extending the use of an existing message over a
new interface should be defined as a feature.
NOTE:
Features are ultimately defined on a case-by-case basis on the merits of defining an extension as a feature.
Features should be defined so that they are independent from each other. A GTP-C entity may support the same feature
over different interfaces, e.g. an SGW may support a feature over both S11 and S4 interface, however support of a
feature on a given interface shall not depend on the support of the same or another feature on another interface.
3GPP
Release 10
182
3GPP TS 29.274 V10.2.0 (2011-03)
11.2 Dynamic discovery of supported features

11.2.1 General
A node supporting at least one feature defined in the Node Features IE shall support dynamic discovery of supported
features as specified in the following subclauses.
11.2.2 Features supported by direct peer GTP-C entities

A node shall signal to a direct peer node the list of features it supports by sending the Sending Node Features IE in the
Echo Request and Echo Response messages.
An exception to this is where the sending node does not support or use any features towards the peer node and is not
prepared to accept a message which is constructed by making use of any features.
The peer receiving the Sending Node Features IE shall store the list of features supported by the sending node per IP
address and only update this list based on the Sending Node Features IE in the Echo Request and Echo Response
messages, and it shall only use common supported features to initiate subsequent GTPv2 messages towards this IP
address.
3GPP
Release 10
183
3GPP TS 29.274 V10.2.0 (2011-03)
Annex A (Informative):
Backward Compatibility Guidelines for Information Elements
In order to preserve backward compatibility, the following rules should apply when adding or modifying information
elements for existing messages.
-
No new mandatory (M) information elements should be added.
No new conditional (C) information elements should be added.
Any new IEs should be either:

optional (O), having no conditions on their presence, or
conditional-optional (CO), having conditions that should apply only to the sender and not to the receiver.
Such conditions should be worded generally as follows: "This IE shall be sent over the xxx interface
<condition>. The receiving entity need not check the IE's presence."
If any new conditions are added to a previously specified conditional (C) information element, these new
conditions should apply only to the sender and not to the receiver.
Such additional conditions should be worded generally as follows: "This IE shall be sent over the xxx interface
<condition>. For this optional condition, the receiving entity need not check the IE's presence."
Existing conditions for such conditional (C) IEs should be treated as before, and the presence of the IEs should
remain conditional (C).
3GPP
Release 10
184
Annex B (informative):
Change History
3GPP
3GPP TS 29.274 V10.2.0 (2011-03)
Release 10
Date
185
TSG # TSG Doc
CT4 Doc
CR
Rev Cat
2008-12
CT#42
CP-080717
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
C4-090922
C4-090520
C4-090834
C4-090878
C4-090879
C4-090902
0001
0003
0004
0005
0006
0008
2
1
2
4
2
2
C
C
C
F
C
C
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
C4-090880
C4-090526
C4-090901
C4-090991
C4-090570
C4-090939
C4-090970
C4-090941
C4-090574
C4-090942
C4-090952
C4-090874
C4-090577
C4-090875
C4-090578
C4-090157
C4-090580
C4-090581
0017
0018
0019
0020
0021
0022
0023
0024
0025
0026
0027
0028
0030
0032
0034
0035
0040
0041
2
1
2
2
1
3
3
2
1
2
2
2
1
2
1
1
1
B
C
C
C
C
C
C
C
F
F
C
C
F
F
F
F
F
F
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CP-090214
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
C4-090583
C4-090798
C4-090945
C4-090588
C4-090590
C4-090591
C4-090592
C4-090593
0043
0043
0044
0045
0048
0050
0051
0052
0053
4
1
2
2
1
1
1
1
1
F
F
F
F
F
F
F
F
F
2009-03
CT#43
CP-090050 C4-090946 0054
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
2009-03
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CT#43
CP-090050
CP-090050
CP-090050
CP-090256
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
0055
0059
0060
0061
0063
0064
0066
0067
0068
0075
0077
0080
0082
3
1
1
3
4
1
4
2
1
3
2
1
3
F
B
C
B
C
F
B
F
F
C
F
F
F
2009-03
2009-03
2009-03
CT#43
CT#43
CT#43
CP-090050 C4-090814 0083

CP-090050 C4-090817 0085
CP-090050 C4-090936 0089
1
1
2
F
F
F
2009-03
2009-03
2009-03
2009-03
2009-03
CT#43
CT#43
CT#43
CT#43
CT#43
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
C4-090826
C4-090871
C4-090822
C4-090823
C4-090829
0093
0094
0095
0096
0097
3
3
1
1
1
B
C
F
F
C
2009-03
2009-03
2009-03
2009-03
2009-03
CT#43
CT#43
CT#43
CT#43
CT#43
CP-090050
CP-090050
CP-090050
CP-090050
CP-090050
C4-090549
C4-090550
C4-090551
C4-090980
C4-090831
0098
0099
0100
0101
0102
3
1
F
F
F
F
C
2009-03
CT#43
CP-090050 C4-090915 0104
C4-090947
C4-090691
C4-090692
C4-090935
C4-090933
C4-090598
C4-090977
C4-090975
C4-090694
C4-090932
C4-090976
C4-090811
C4-090938
3GPP TS 29.274 V10.2.0 (2011-03)

Subject/Comment
Old
New
V2.0.0 approved in CT#42

Delete Indirect Data Forwarding Tunnel
Request/Response
Relocation Cancel Req/Res
Path Failure
Sections 1 through 6 Editorial Clean-up
Delete Session and Delete Bearer messages
Update User Plane messages
Cleanup in path management and bearer
command messages
Create Session/Bearer Messages
Modify Bearer messages
IEs in CSFB related messages
Command Messages
Data Forwarding Info
Delete Bearer messages
Delete Session messages
Update Bearer messages
Secondary PDP Activation
Stop Paging
EPS Bearer Contexts Prioritization
AMBR IE encoding
Authentication Failure Cause Code
Forward SRNS Context Notification
F-TEID IE clarification
SGW Selection during TAU and corrections to
Grouped IEs
Identification Response algorithm information
IE Type ordering
Indication IE corrections
MM Context enhancements
Removal of Bearer ID List IE
Remove unused IP Address IEs
Selection Mode bits
Corrections to Trace Information IE
Trace Information IE to be included in S11 and
S5/S8 messages
Trace Session Activation/Deactivation when
UE is attached
New UE Time Zone IE Type
Release Access Bearers Request/Response
Piggybacking of Dedicated Bearer Messages
Finalizing GTPv2 Error Handling clause
GTPv2 clause 9 and 10 cleanup
RAN Information Relay message
Bearer QoS encoding
Modify Bearer Response
Location Change Reporting
Cleanup on Cause Values
Non-3GPP Requests in GTPv2
Support of IP address retrieval for ANRF
Support for error response for conflicting
resource request
Clarification of Target ID vs Cell ID
TEID Value of the GTP header
Header for the Format of the GTPv2-C
message
Finalization of Partial fault handling in GTPv2
MSISDN encoding
IMSI encoding
PMIP error code reservation
Removal of Comprehension Required from
messages 7.3.1 to 7.3.13
Cause value for PGW not responding
Traffic Aggregate Description IE encoding
Protocol Stack
Reliable delivery for EPC
Removal of reservation for message types of
GTP-U
2.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.0.0
8.1.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.0.0
8.0.0
8.0.0
8.1.0
8.1.0
8.1.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.0.0
8.0.0
8.0.0
8.0.0
8.0.0
8.1.0
8.1.0
8.1.0
8.1.0
8.1.0
8.0.0
8.1.0
3GPP
Release 10
Date
186
TSG # TSG Doc
2009-03
2009-03
2009-06
CT#43
CT#44
2009-06
CT#44
2009-06
2009-06
2009-06
2009-06
CT#44
CT#44
CT#44
CT#44
2009-06
CT#44
CP-090239
-
CT4 Doc
CR
0105
0107
CP-090288 C4-091020
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
2009-06
2009-06
2009-06
2009-06
CT#44
CT#44
CT#44
CT#44
2009-06
2009-06
2009-06
CT#44
CT#44
CT#44
2009-06
CT#44
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
2009-06
2009-06
2009-06
CT#44
CT#44
CT#44
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
1
-
F
-
0108
CP-090288
CP-090288
CP-090288
CP-090288
C4-091459
C4-091460 0109
C4-091461 0110
C4-091463 0111
0112
C4-091465
0114
C4-091471
C4-091537 0115
C4-091473 0117
C4-091474 0118
C4-091103 0119
C4-091475 0120
C4-091476 0122
C4-091586 0125
C4-091478 0127
C4-091480 0128
C4-091115 0129
0131
C4-091481
C4-091120 0134
C4-091587 0136
C4-091510 0137
0142
C4-091512
C4-091513 0143
C4-091515 0147
0149
C4-091516
0150
1
1
1
1
F
F
F
F
1
2
1
1
1
1
2
1
1
-
F
F
F
F
F
F
F
F
F
F
F
2
2
2
F
F
F
F
1
1
1
F
F
F
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
C4-091538
C4-091540
C4-091162
C4-091537
C4-091541
C4-091542
C4-091167
2
1
2
1
1
-
F
F
F
F
F
F
F
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
C4-091168
C4-091467
C4-091543
C4-091548
C4-091549
C4-091550
C4-091202
1
1
2
1
2
-
F
F
F
F
F
F
F
1
-
F
F
F
1
1
1
1
1
1
1
1
3
1
1
1
F
F
F
F
F
F
F
F
F
F
F
F
F
F
CP-090288
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
Rev Cat
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
0151
0153
0154
0156
0157
0158
0159
0160
0161
0164
0168
0169
0175
0176
CP-090288 C4-091203
CP-090288 C4-091544 0177
CP-090288 C4-091205 0178
0180
CP-090288 C4-091546
CP-090288 C4-091551 0181
CP-090288 C4-091234 0183
CP-090288 C4-091462 0184
CP-090288 C4-091561 0185
CP-090288 C4-091552 0186
CP-090288 C4-091553 0187
CP-090288 C4-091557 0189
CP-090288 C4-091241 0190
CP-090288 C4-091539 0192
CP-090500
0193
CP-090288 C4-091547 0195
CP-090288 C4-091556 0196
CP-090288 C4-091545 0198
3GPP TS 29.274 V10.2.0 (2011-03)

Subject/Comment
Old
New
Essential correction to grouped IE type coding

Some of the table formats corrected
Suspend and Resume are also used for
1xRTT CS Fallback
Support for new cause code of "Unable to
page UE due to CSFB" in Downlink Data
Notification Acknowledgement.
Corrections on GTPv2 for 1x IWS IP address
Clarification of Operation Indication (OI)
Usage of User Location Information (ULI) IE
PGW S5/S8 IP Address in Context Response
message
Response
Error_Handling. Withdrawn
PCO Extensions added to messages
Clarifications to message directions
Removal of specification drafting hints
ISR related alignments
Clarifications to grouped IE usage
Clarification to Recovery IE type
Missing conditions
Clarification of ARP encoding
Units for APN-AMBR
Clarification of Mobile Equipment Identity IE
encoding
EPS Bearer Level TFT encoding
UE-initiated procedures with one bearer only
Combine UL and DL TFT IEs
PGW S5/S8 IP Address and TEID for user
plane
Transaction Identifier information element
Modify Bearer Request for TAU without MME
or SGW change
Use of APN, PAA in Create Session Request,
and S5/S8-U PGW F-TEID in Create Session
Response
Message table corrections
Presence requirement for IEs in response
Offending IE in the Cause IE
Minor corrections
FQ-CSID corrections
APN and FQDN encoding clarifications
Removal of Trace Information IE from Update
Bearer Request
Corrections in PDN Connection group IE
Missing IEs in "Update Bearer Response"
PDN Type
IE corrections in Modify Bearer signalling
Create Session Request Clarification
TEID in Detach Notification/ACK
Condition of bearer context in Modify Bearer
messages
Delete Session Request granularity
Deletion of IMSI in the Update Bearer Request
Delete Session Request/Response and Delete
Bearer Request
Detach Notification
SGSN Info for Data Forwarding
APN AMBR clarification
Delete Bearer Request when ISR activated
Clarify the usage of the MS validated IE
UDP Source port and IP Source Address
Recovery IE
APN Information
Cause value
Cleanup indication
Cleanup the usage of some messages
8.0.0
8.1.0
8.1.1
8.1.0
8.1.1
8.2.0
8.1.1
8.2.0
8.1.1
8.1.1
8.1.1
8.1.1
8.2.0
8.2.0
8.2.0
8.2.0
8.1.1
8.2.0
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.1.1
8.1.1
8.1.1
8.1.1
8.2.0
8.2.0
8.2.0
8.2.0
8.1.1
8.1.1
8.1.1
8.2.0
8.2.0
8.2.0
8.1.1
8.2.0
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.1.1
8.1.1
8.1.1
8.2.0
8.2.0
8.2.0
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
3GPP
Release 10
Date
187
TSG # TSG Doc
CT4 Doc
CR
2009-06
2009-06
2009-06
2009-06
2009-06
2009-06
CT#44
CT#44
CT#44
CT#44
CT#44
CT#44
CP-090288
CP-090288
CP-090288
CP-090288
CP-090288
C4-091514
C4-091558
C4-091464
C4-091559
C4-091560
0199
0200
0201
0202
0206
1
1
1
2
1
F
F
F
F
F
2009-06
2009-06
2009-06
2009-06
CT#44
CT#44
CT#44
CT#44
CP-090321
CP-090493
CP-090355
CP-090485
0209
0210
0212
0213
1
1
F
F
F
F
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CP-090472
CP-090533
CP-090533
CP-090533
CP-090533
CP-090533
CP-090533
CP-090533
CP-090533
CP-090533
C4-091625
C4-092004
C4-092005
C4-092008
C4-091630
C4-092012
C4-091633
C4-091635
C4-092013
0214
0215
0216
0217
0218
0220
0222
0223
0225
0226
1
1
1
1
1
1
F
F
F
F
F
F
F
F
F
F
2009-09
2009-09
2009-09
CT#45
CT#45
CT#45
CP-090533 C4-092134 0228

CP-090533 C4-092017 0229
CP-090533 C4-092014 0232
3
1
2
F
F
F
2009-09
2009-09
CT#45
CT#45
CP-090533 C4-092018 0236

CP-090533 C4-092019 0237
1
2
F
F
CP-090533 C4-092020 0239
2009-09
CT#45
CP-090533 C4-092002 0241
CP-090533 C4-092103 0243
CP-090533 C4-092074 0244

CP-090533 C4-092076 0245
1
1
F
F
CP-090533 C4-091722 0246
CP-090533 C4-092656 0247
CP-090533 C4-092078 0249

CP-090533 C4-092711 0250
1
4
F
F
CP-090533 C4-092081 0256

CP-090534 C4-092009 0258
CP-090534 C4-092082 0259
1
1
1
F
F
F
CP-090534
CP-090534
CP-090534
CP-090534
CP-090534
CP-090534
CP-090534
CP-090534
0260
0261
0262
0263
0264
0266
0267
0268
3
2
1
2
2
3
F
F
F
F
F
F
F
F
CP-090534 C4-092105 0269
CP-090534 C4-092106 0270
CP-090534 C4-092710 0271

CP-090534 C4-092043 0276
2
1
F
F
CP-090535 C4-092751 0278

CP-090534 C4-092112 0279
5
3
F
F
CP-090534 C4-092108 0281
CP-090534 C4-092686 0282
2009-09
2009-09
CT#45
CT#45
2009-09
2009-09
CT#45
CT#45
2009-09
CT#45
2009-09
CT#45
2009-09
2009-09
CT#45
CT#45
2009-09
2009-09
2009-09
CT#45
CT#45
CT#45
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
2009-09
CT#45
2009-09
Rev Cat
C4-091784
C4-092651
C4-092104
C4-092083
C4-092085
C4-091790
C4-092086
C4-092636
CT#45
2009-09
2009-09
CT#45
CT#45
2009-09
2009-09
CT#45
CT#45
2009-09
CT#45
3GPP TS 29.274 V10.2.0 (2011-03)

Subject/Comment
Old
New
PCO parameter
User Location Info
F-Cause IE correction
Message granularity
Bearer Context in the Modify Bearer
Command
Sequence Number Extension
Bearer Resource Command clarification
Piggybacked message clarifications
Corrections on handling Charging ID IE and
Charging Characteristics IE
Usage of GTPv2-C Header
Create Session Request and Response
Cleanup Editors Note
Message format and Type values
S16 Influence
MM Context
F-Container
Procedure names
Changes to Create-Session-Request and
Create-Session-Response messages
Changes to Modify-Bearer-Response
Piggybacking Clarifications
Delete Bearer Request Cause value for ISR
deactivation
Modify Bearer Request Bearer Level QoS
Possible reject response Cause values in
GTPv2 message descriptions
SGW F-TEID for S1-U, S12 and S4 for User
Plane
Clarification on the usage of Version Not
Supported Indication
Clarifications on Sender-F-TEID for CP and
S3/S10/S16 CP IP Addr and TEID IEs
Cause Value in Echo Response
Corrections in ULI IE and PDN Connection IE
definitions
GTPv2 Initial and Triggered Message
definition and Sequence Number handling
Missing Cause values in some message
descriptions
Add TAC to Target Identification IE
IMSI and Sender F-TEID in Create Indirect
Data Forwarding Tunnel Messages
Indication in Forward Relocation messages
Paging cause
Correlate the bearers in the Create Bearer
Response
Cleanup cause values
Cleanup Modify Bearer Request
IEs in Response
CS Paging Indication
Serving Network
Service Handover support
Fix incorrect interface name, incorrect
reference and other misreading texts
Clarification on cause value for Downlink Data
Notification Failure Indication
Clarification on the Authentication Vector
handling
Clarification on Authentication Vector encoding
Clarification on Error indication for EPC and
DT
Aligning MBR units to kbps
Clarification to the PGW's UP address in
Modify Bearer procedure for X2 and S1 based
handovers
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.1.1
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.1.1
8.1.1
8.1.1
8.1.1
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.2.0
8.2.0
8.2.0
8.3.0
8.3.0
8.3.0
8.2.0
8.2.0
8.3.0
8.3.0
8.2.0
8.3.0
8.2.0
8.3.0
8.2.0
8.3.0
8.2.0
8.2.0
8.3.0
8.3.0
8.2.0
8.3.0
8.2.0
8.3.0
8.2.0
8.2.0
8.3.0
8.3.0
8.2.0
8.2.0
8.2.0
8.3.0
8.3.0
8.3.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.2.0
8.3.0
8.2.0
8.3.0
8.2.0
8.2.0
8.3.0
8.3.0
8.2.0
8.2.0
8.3.0
8.3.0
8.2.0
8.3.0
3GPP
Release 10
Date
2009-09
2009-09
188
TSG # TSG Doc
CT4 Doc
CR
Rev Cat
CT#45
CP-090534 C4-092109 0290
CP-090534
CP-090534
CP-090534
CP-090534
CP-090534
C4-092000
C4-092642
C4-092644
C4-092646
C4-092189
0292
0295
0296
0297
0301
2
1
1
-
F
F
F
F
F
CP-090534
CP-090535
CP-090535
CP-090535
CP-090535
C4-092647
C4-092648
C4-092649
C4-092652
C4-092653
0302
0303
0304
0307
0308
1
1
1
3
1
F
F
F
F
F
CP-090535
CP-090535
CP-090535
CP-090535
CP-090535
C4-092654
C4-092655
C4-092635
C4-092657
C4-092659
0309
0310
0311
0315
0316
1
1
2
1
1
F
F
F
F
F
CP-090535
CP-090535
CP-090535
CP-090535
CP-090535
CP-090535
CP-090535
CP-090535
CP-090535
C4-092677
C4-092678
C4-092650
C4-092679
C4-092368
C4-092369
C4-092680
C4-092681
C4-092372
0317
0318
0320
0321
0322
0323
0324
0325
0326
1
1
1
1
1
1
-
F
F
F
F
F
F
F
F
F
CP-090535 C4-092709 0330

CP-090535 C4-092388 0332
CP-090535 C4-092397 0334
1
-
F
F
F
CP-090535
CP-090535
CP-090535
CP-090535
CP-090729
0335
0338
0339
0340
0341
4
1
1
1
1
F
F
F
F
F
CP-090729 C4-092738 0342

CP-090535 C4-092634 0346
2
1
F
F
CT#45
2009-09
2009-09
2009-09
2009-09
2009-09
CT#45
CT#45
CT#45
CT#45
CT#45
2009-09
2009-09
2009-09
2009-09
2009-09
CT#45
CT#45
CT#45
CT#45
CT#45
2009-09
2009-09
2009-09
2009-09
2009-09
CT#45
CT#45
CT#45
CT#45
CT#45
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
2009-09
2009-09
2009-09
CT#45
CT#45
CT#45
2009-09
2009-09
2009-09
2009-09
2009-09
CT#45
CT#45
CT#45
CT#45
CT#45
2009-09
2009-09
CT#45
CT#45
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
2009-09
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CT#45
CP-090535
CP-090535
CP-090559
CP-090559
CP-090562
CP-090745
CP-090562
CP-090562
C4-092715
C4-092478
C4-092061
C4-092603
C4-091934
C4-092500
C4-092501
0349
0350
0253
0254
0285
0286
0343
0344
1
2
4
1
4
1
1
F
F
B
B
C
B
B
B
2009-10
2009-12
2009-12
2009-12
2009-12
2009-12
CT#46
CT#46
CT#46
CT#46
CT#46
CT#46
CP-090769
CP-090798
CP-090770
CP-090769
CP-090770
C4-093160
C4-093288
C4-092830
C4-093705
C4-092834
0356
0357
0359
0361
0363
1
2
1
-
A
B
A
A
A
2009-12
CT#46
CP-090770 C4-092857 0365
2009-12
2009-12
CT#46
CT#46
CP-090770 C4-092861 0369

CP-090770 C4-093329 0371
A
A
2009-12
2009-12
2009-12
2009-12
2009-12
CT#46
CT#46
CT#46
CT#46
CT#46
CP-090770
CP-090970
CP-090770
CP-090770
CP-090770
1
2
1
1
1
C4-092740
C4-092712
C4-092713
C4-092714
C4-092626
C4-093331
C4-093335
C4-093337
C4-093339
0373
0375
0377
0380
0382
A
A
A
3GPP TS 29.274 V10.2.0 (2011-03)

Subject/Comment
Old
New
Add necessary cause value to the Update

Bearer Response
Update on Concurrent Running of Security
Procedures
APN Restriction IE
Change Reporting IE
ULI Clarification
Charging ID
Request/Response
SGW F-TEID
BCM
Charging Gateway Address
LBI Clarifications for Gn/Gp Handovers
Trace management messages and IE related
clarifications
Indirect Data Forwarding Tunnel clarifications
Concurrent Running of Security Procedures
Cause value corrections
Identification Response
NSAPI and EBI in Forward Relocation
Response
Cause in the CSFB related messages
Update Bearer Complete
PCO IE
Cleanup Trace Management messages
Cleanup section 5.3 and 8.12
APN AMBR in the Create Bearer Request
Presence Requirments for grouped IE
Making PCO conditional for the Attach
procedure
Echo usage alignment with stage 2
Trace Depth per session
Backward compatibility requirements for
presence
ECGI encoding correction
Consistant PDN type setting
GTP Cause value usage
Partial failure handling alignment with stage 2
Partial failure handling for MME relocation w/o
SGW relocation
Security Specification for GTPV2-C
Avoiding Source Port Overlap between
GTPv2-C and GTPv2-C'
Delete Bearer Command PCO removal
Scope of GTP-C protocol
MBMS session management messages
IMEI based GTP Changes
Unauthenticated IMSI for emergency in GTP
IMEI based Id in GTP messages
Unauthenticated IMSI in GTP messages
Editorial correction. Wrong style was used in
Paragraph character 7.1.3.
Selection Mode IE
PTP bearer fallback
Bearer QoS in Modify Bearer Request
Release Access Bearer Request
Bearer context in Create Session messages
ISRAI flag in the Forward Relocation Complete
Notification
Mapping between RAI, P-TMSI, P-TMSI
signature and GUTI
APN IE encoding
Correction on the condition for resource
release of other CN node
APN Restriction
Cause value "Invalid reply from remote peer"
Indication Flags in Delete Session Request
Suspend
8.2.0
8.3.0
8.2.0
8.3.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.2.0
8.2.0
8.2.0
8.3.0
8.3.0
8.3.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.3.0
8.3.0
8.3.0
8.3.0
8.3.0
8.2.0
8.2.0
8.3.0
8.3.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
8.2.0
9.0.0
8.3.0
9.0.0
9.0.0
9.0.0
9.0.0
9.0.0
9.0.0
9.0.1
9.0.1
9.0.1
9.0.1
9.0.1
9.0.1
9.0.1
9.1.0
9.1.0
9.1.0
9.1.0
9.1.0
9.1.0
9.0.1
9.1.0
9.0.1
9.0.1
9.1.0
9.1.0
9.0.1
9.0.1
9.0.1
9.0.1
9.1.0
9.1.0
9.1.0
9.1.0
3GPP
Release 10
Date
189
TSG # TSG Doc
CT4 Doc
CR
Rev Cat
2009-12
2009-12
CT#46
CT#46
CP-090770 C4-092893 0386

CP-090770 C4-092893 0388
A
A
2009-12
CT#46
CP-090770 C4-092899 0390
2009-12
CT#46
CP-090770 C4-093345 0392
2009-12
2009-12
2009-12
2009-12
CT#46
CT#46
CT#46
CT#46
CP-090770
CP-090804
CP-090770
CP-090769
0393
0395
0397
0399
3
4
3
2
A
B
A
A
2009-12
2009-12
2009-12
CT#46
CT#46
CT#46
CP-090770 C4-093004 0403

CP-090770 C4-093006 0405
CP-090770 C4-093270 0407
A
A
A
2009-12
CT#46
CT#46
CP-090770 C4-093262 0409
CP-090770 C4-093351 0411

CP-090770 C4-093034 0417
2
-
A
A
CP-090769 C4-094038 0419

CP-090769 C4-094040 0423
2
2
A
A
CP-090769 C4-094036 0425
CP-090769 C4-094042 0434
CP-090769 C4-094044 0438
CP-090769 C4-094184 0442
CP-090777 C4-094094 0448

CP-090975
0450
1
2
A
A
CP-090769 C4-094049 0452
CP-090786
CP-090769
CP-090769
CP-090769
CP-090769
CP-090769
0453
0455
0457
0459
0461
0471
1
1
F
A
A
A
A
A
CP-090769 C4-094059 0475
CP-090770 C4-094074 0484
CP-100021 C4-100767 0493

CP-100022 C4-100972 0495
1
5
A
A
CP-100021 C4-100142 0497

CP-100021 C4-100276 0504
CP-100021 C4-100788 0506
A
A
A
CP-100049
CP-100035
CP-100019
CP-100021
0508
0510
0512
0514
1
2
1
B
F
A
A
CP-100021 C4-100800 0516

CP-100022 C4-100856 0518
CP-100022 C4-100960 0520
2
1
2
A
A
A
CP-100035 C4-100756 0521
1
1
2
A
B
A
A
2009-12
2009-12
2009-12
2009-12
CT#46
CT#46
CT#46
CT#46
2009-12
C4-093397
C4-094229
C4-093278
C4-094051
CT#46
2009-12
CT#46
2009-12
CT#46
2009-12
CT#46
2009-12
2009-12
CT#46
CT#46
2009-12
CT#46
2009-12
2009-12
2009-12
2009-12
2009-12
2009-12
CT#46
CT#46
CT#46
CT#46
CT#46
CT#46
2009-12
C4-094071
C4-093647
C4-093649
C4-093651
C4-093668
C4-094059
3GPP TS 29.274 V10.2.0 (2011-03)

Subject/Comment
Old
New
Removal of forwarding Charging Gateway

Address/Name to S4-SGSN
Charging ID in S4-SGSN
Correction of Message Direction for Create
Session Response
PPC (Prohibit Payload Compression)
alignment with Stage-2
UE TimeZone and ULI included in Bearer
Response messages
Support for CSG based charging
User Location Information
PDN type
Removal of ULI from Release Access Bearer
Req
Removal of NSAPI IE
Indication IE clarification
Addition of uplink, downlink F-TEIDs in Create
Indirect Data Forwarding Tunnel Request and
Response messages
Clarifications on use of the Sender-F-TEID for
CP in HO procedure
Clarifications to MSISDN coding
Enhanced handling of RFSP index at the
SGSN/MME
TFT related error handling
Essential correction to the Indirect Data
Forwarding procedure
Correcting misaligned IE presence type
statements
Correcting PCO conditions in Modify Bearer
Response
messages
SRVCC - voice bearer handling in PS HO /
DTM scenarios
NAS Count value
Charging Characteristics value for active PDN
connections
eNodeB Cause and RANAP Cause
corrections
Change the NSAPI to EBI in the PFI IE
Enhanced SRNS Relocation Procedure
Forward Access Context Acknowledge
Correct the message Modify Bearer Request
Cleanup Suspend Notification message
Forward Relocation Request: Selected PLMN
ID
9.0.1
9.1.0
9.0.1
9.0.1
9.1.0
9.1.0
9.0.1
9.1.0
9.0.1
9.1.0
9.0.1
9.0.1
9.0.1
9.0.1
9.1.0
9.1.0
9.1.0
9.1.0
9.0.1
9.0.1
9.0.1
9.1.0
9.1.0
9.1.0
9.0.1
9.1.0
9.0.1
9.0.1
9.1.0
9.1.0
9.0.1
9.0.1
9.1.0
9.1.0
9.0.1
9.1.0
9.0.1
9.1.0
9.0.1
9.1.0
9.0.1
9.1.0
9.0.1
9.0.1
9.1.0
9.1.0
9.0.1
9.1.0
9.0.1
9.0.1
9.0.1
9.0.1
9.0.1
9.0.1
9.1.0
9.1.0
9.1.0
9.1.0
9.1.0
9.1.0
9.0.1
9.1.0
9.1.0
9.2.0
9.1.0
9.1.0
9.2.0
9.2.0
9.1.0
9.1.0
9.1.0
9.2.0
9.2.0
9.2.0
9.1.0
9.1.0
9.1.0
9.1.0
9.2.0
9.2.0
9.2.0
9.2.0
9.1.0
9.1.0
9.1.0
9.2.0
9.2.0
9.2.0
9.1.0
9.2.0
9.1.0
9.1.0
9.1.0
9.2.0
9.2.0
9.2.0
CT#46
2009-12
CT#47
2010-03
2010-03
2010-03
CT#47
CT#47
2010-03
2010-03
2010-03
CT#47
CT#47
CT#47
2010-03
2010-03
2010-03
2010-03
CT#47
CT#47
CT#47
CT#47
2010-03
2010-03
2010-03
CT#47
CT#47
CT#47
2010-03
CT#47
2010-03
2010-03
2010-03
CT#47
CT#47
CT#47
CP-100021
CP-100049
CP-100022
CP-100021
C4-100836
C4-100970
C4-100318
C4-100793
C4-100396
C4-100839
C4-100866
C4-100720
0523
0524
0530
0533

Essential clarification to MME executed TAU
procedure
Essential correction to the MM context IE type
Resolving ambiguity for Target Identification IE
coding
PCO
RFSP Index
Include CSG ID and CSG Membership
Indication in S3 and S10
Location change reporting in EPS
The encoding of APN IE
Indirect Data Forwarding
HSS/PGW initiated Bearer QoS Modification
procedure
APN IE description correction
P-TMSI Signature
Corrections to the RAN Information
Management procedures
Source Identification for E-UTRAN to GERAN
handover
Handovers to HeNB cells
Granularity
Change Reporting Support Indicator
3GPP
Release 10
Date
190
TSG # TSG Doc
2010
2010-03
CT#47
CT#47
2010-03
CT#47
CT4 Doc
CR
CP-100027 C4-100992 0537
2010-03
2010-03
CT#47
CT#47
2010-03
CT#47
2010-03
2010
2010-03
CT#47
CT#47
CT#47
2010-03
2010-03
CT#47
CT#47
2010-03
CT#47
2010-03
Rev Cat
CP-100021 C4-100416 0535
A
2
CP-100021 C4-100420 0539

CP-100035 C4-100995 0541
A
F
CP-100022 C4-100876 0548
CP-100022 C4-100878 0550

CP-100035 C4-100883 0554
CP-100022 C4-100974 0556
1
1
2
A
F
A
CP-100022 C4-100976 0558

CP-100022 C4-100979 0565
2
2
A
A
CP-100021 C4-100784 0567
CP-100022 C4-100981 0569
CP-100022 C4-100983 0577

CP-100022 C4-100906 0581
2
1
A
A
CP-100022 C4-100985 0583
CT#47
2010-03
2010-03
CT#47
CT#47
2010-03
CT#47
CP-100021 C4-100601 0585
2010-03
CT#47
2010-03
2010-06
2010-06
2010-06
CT#47
CT#48
CT#48
CT#48
2010-06
2010-06
2010-06
2010-06
2010-06
2010-06
2010-06
CT#48
CT#48
CT#48
CT#48
CT#48
CT#48
CT#48
2010-06
2010-06
CT#48
CT#48
2010-06
2010-06
2010-06
CT#48
CT#48
CT#48
2010-06
2010-06
2010-06
CT#48
CT#48
CT#48
2010-06
CT#48
2010-06
2010-06
2010-06
2010-06
2010-06
2010-06
2010-06
CT#48
CT#48
CT#48
CT#48
CT#48
CT#48
CT#48
2010-06
2010-06
2010-06
CT#48
CT#48
CT#48
2010-06
CT#48
2010-06
CP-100022
CP-100021
CP-100266
CP-100266
C4-100913
C4-100778
C4-101479
C4-101580
0587
0591
0599
0603
1
1
1
3
A
A
A
A
CP-100266
CP-100266
CP-100266
CP-100266
CP-100266
CP-100266
CP-100266
C4-101480
C4-101486
C4-101489
C4-101491
C4-101495
C4-101583
C4-101537
0605
0614
0618
0624
0626
0635
0637
1
1
1
1
1
2
1
F
A
A
A
A
A
F
CP-100266 C4-101504 0642

CP-100266 C4-101599 0647
1
3
A
A
CP-100266 C4-101553 0650

CP-100266 C4-101555 0657
CP-100266 C4-101558 0659
2
1
1
A
A
A
CP-100266 C4-101291 0664

CP-100281 C4-101585 0540
CP-100281 C4-101484 0609
4
1
A
F
F
CP-100281 C4-101597 0616
CP-100281
CP-100281
CP-100281
CP-100281
CP-100281
CP-100281
CP-100281
0633
0638
0673
0639
0670
0667
0669
1
1
1
3
1
2
1
F
F
F
F
F
F
F
CP-100281 C4-101461 0651

CP-100281 C4-101464 0672
CP-100287 C4-101259 0654
1
1
F
F
F
CP-100287 C4-101608 0640
CP-100266 C4-101601 0678
C4-101498
C4-101459
C4-101465
C4-101609
C4-101463
C4-101593
C4-101462
CT#48
CP-100298
0680
3GPP TS 29.274 V10.2.0 (2011-03)

Subject/Comment
Old
New
MM Context IE type correction

Removal of TEIDs for PS voice bearer UP in
Bearer Context for SRVCC
Correction on the presence condition of
Charging ID IE on S4
Suspend
Modify Octets Sequence Number of RAB
Context IE
Revive the cause value "User Authentication
Failed" in the Create Session Response
Fix PCO handling by defining it per bearer
Fix PDN Connection Grouped Type
Correction on the down link notification failure
procedure
Correction of the presence condtion of IEs
Figure number, Information element and
message usage
2G related parameters in the Forward
Relocation Request and Context Response
Essential correction to the Create Bearer
Request message
Essential correction to FTEID IE
Essential correction to Modify Bearer Request
for non-3GPP to 3GPP handover
Removal of unncessary cause "Unexpected
repeated IE"
Removal of indirect uplink data forwarding
from Inter RAT handovers
Trace alignment with TS 32.422
Essential corrections to M-TMSI mapping
Change Notification
Fix missing conditional description for IEs in
the context response message
Change Reporting Support Indication
Handover/Relocation cancel procedure
ULI in the Modify Bearer Request message
MM context IE encoding
MBR in handover from non-3GPP to 3GPP
Suspend over S16
Adding Service indicator to CS Paging
Indication
Fallback to GTPv1
Essential correction to ULI IE condition in
Modify Bearer Request message
TEID in Change Notification
Charging ID
Alert MME Notification / UE Activity Notification
procedure on S3 interface
Leave CSG Cell indication
Use of Rejection Cause values
Flow QoS in the Bearer Resource Command
message
Correction to the reference in Create indirect
DF Tunnel Request
Removal of FFS
Message type table
Implicit resume
Cause IE type
Clarifications to redundant IEs
EBI value range and coding
Cause IE enhacements to distinguish errors in
the message level IE versus errors in the
grouped IE within the message
Bearer Resource Command usage
Sn-U SGSN F-TEID
Allocation and Retention Priority for MBMS ERAB
Handling of Create Session Request message
on TEID 0 for existing PDN connection
Essential correction for the Initial Attach
procedure
9.1.0
9.1.0
9.2.0
9.2.0
9.1.0
9.2.0
9.1.0
9.1.0
9.2.0
9.2.0
9.1.0
9.2.0
9.1.0
9.1.0
9.1.0
9.2.0
9.2.0
9.2.0
9.1.0
9.1.0
9.2.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.1.0
9.2.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.1.0
9.2.0
9.2.0
9.2.0
9.2.0
9.3.0
9.3.0
9.3.0
9.2.0
9.2.0
9.2.0
9.2.0
9.2.0
9.2.0
9.2.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.2.0
9.2.0
9.3.0
9.3.0
9.2.0
9.2.0
9.2.0
9.3.0
9.3.0
9.3.0
9.2.0
9.2.0
9.2.0
9.3.0
9.3.0
9.3.0
9.2.0
9.3.0
9.2.0
9.2.0
9.2.0
9.2.0
9.2.0
9.2.0
9.2.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.2.0
9.2.0
9.2.0
9.3.0
9.3.0
9.3.0
9.2.0
9.3.0
9.2.0
9.3.0
3GPP
Release 10
Date
2010-06
191
TSG # TSG Doc
CT4 Doc
CR
Rev Cat
CT#48
CP-100276 C4-101157 0612
2010-06
CT#48
CP-100408
2010-09
CT#49
CT#49
CT#49
CT#49
CT#49
2010-09
2010-09
2010-09
CT#49
CT#49
CT#49
2010-09
2010-09
2010-09
2010-09
2010-09
CT#49
CT#49
CT#49
CT#49
CT#49
2010-09
2010-09
2010-09
2010-09
2010-09
2010-09
2010-09
2010-09
CT#49
CT#49
CT#49
CT#49
CT#49
CT#49
CT#49
CT#49
2010-09
2010-09
CT#49
CT#49
2010-09
CT#49
CT#49
CT#49
CT#49
CT#49
CT#49
CT#49
CT#49
CT#49
2010-09
2010-09
CT#49
CT#49
2010-09
2010-09
CT#49
CT#49
2010-09
2010-09
CT#49
CT#49
2010-09
2010-12
CT#49
CT#50
2010-12
2010-12
2010-12
CT#50
CT#50
CT#50
2010-12
CT#50
2010-12
2010-12
2010-12
0607
0630
0681
0685
0687
5
4
2
1
F
A
F
A
A
CP-100444 C4-101878 0689

CP-100580 C4-102309 0690
CP-100452 C4-101922 0693
1
4
2
A
F
F
CP-100452
CP-100445
CP-100451
CP-100444
CP-100444
C4-101932
C4-101921
C4-101926
C4-101678
C4-101876
CP-100452
CP-100452
CP-100452
CP-100452
CP-100452
C4-101713
C4-101927
C4-101715
C4-101716
C4-101930
0694
0695
0696
0697
0701
F
F
F
F
F
CP-100452
CP-100452
CP-100445
CP-100445
CP-100445
CP-100452
CP-100452
CP-100445
C4-101747
C4-101748
C4-101884
C4-101886
C4-101904
C4-101923
C4-101905
C4-101891
0702
0703
0705
0707
0709
0711
0716
0718
1
1
1
2
1
1
F
F
A
A
A
F
F
A
CP-100451 C4-102319 0723

CP-100451 C4-102305 0724
1
1
F
F
CP-100451 C4-102306 0726
CP-100636
0727
CP-100451
CP-100451
CP-100444
CP-100444
CP-100444
CP-100453
CP-100451
CP-100451
C4-102310
C4-102320
C4-102324
C4-102318
C4-102326
C4-102384
C4-102353
C4-102354
0729
0732
0736
0738
0740
0744
0745
0746
2
1
1
1
1
2
1
1
F
F
A
A
A
F
F
F
CP-100444 C4-102329 0748

CP-100444 C4-102331 0750
1
1
A
A
CT#49
2010-09
2010-09
2010-09
2010-09
2010-09
2010-09
2010-09
2010-09
2010-12
0544
CT#49
2010-09
2010-09
2010-09
2010-09
2010-09
2010-09
CP-100451 C4-102208 0751

CP-100451 C4-102229 0754
F
F
CP-100451 C4-102357 0755

CP-100469 C4-102302 0662
1
4
F
B
CP-100469 C4-102382 0698

CP-100469 C4-102300 0734
6
1
B
B
CP-100695 C4-102766 0758

CP-100695 C4-102836 0762
CP-100695 C4-103277 0787
1
3
4
F
B
B
CP-100695 C4-102912 0798
CP-100695 C4-102771 0799
CP-100695 C4-103274 0812
CP-100695 C4-103362 0817

CP-100695 C4-103276 0818
CP-100695 C4-103343 0823
2
1
2
B
F
F
CT#50
CT#50
CT#50
CT#50
3GPP TS 29.274 V10.2.0 (2011-03)

Subject/Comment
Old
New
Transferring of UE's usage setting and voice

capability between CN nodes
Clarifying the bearers to be deactivated on the
S5/S8 interface
Fix Sudden disconnection after the inter RAT
MM attempt
IP Address IE clarification
Serving Network semantics
Originating Node
Condition of ISRAI Flag
PDN Connection for Subscription Data
Change
Clarification for Create Session Response
An exception to use GTPv2
IEs to be included in rejection response
messages
Ambiguity for encoding MBR/GBR
Wrong reference to DRX parameter
Selection Mode
Stop CSG Information Reporting
Create Session Request/Response and
Modify Bearer Request/Response for RAU
procedure
Suspend message on S3 interface
Cause value in Detach Notification
S1 based handover cancel
Used NAS integrity protection algorithm values
TAU with Active Flag
Trace Report File LDNs
Change Notification Response
Presence rules and error handling for
embedded IEs
Dual Address Bearer Flag
Rejecting the dedicated bearer related
procedure from MME to SGW and PGW
Correction to condition of sending Context
Acknowledge message
Clarification to the OI flag usage in Delete
Session Request
Correcting non-existent Cause value
Resume messages
LAI field
P-TMSI Signature
Change Reporting Support Indication
Error handling
Flow QoS IE
PDN Connection for Subscription Data
Change
E-UTRAN to HRPD handover
Correcting type value of the MBMS Session
Start Response message
GTP protocol errors
Essential Clarification in Forward Relocation
Response message
New Modify Access Bearers procedure
Notification of supported features between
peer GTP-C entities
Length of IPv6 Prefix
OI flag in Delete Session Request alignment
with stage
ISR in Delete Bearer Request
PGW Restart Notification
Feature definition for the Modify Access
Bearers procedure
Modify Access Bearers procedure during InterMME Intra-SGW TAU
Clarifications to Failure Indication type of
messages
EPS Bearer ID in Downlink Data Notification
message
Clarifying possible cause value sets
SGSN Failure handling
9.2.0
9.3.0
9.2.0
9.3.0
9.3.0
9.4.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.4.0
9.4.0
9.4.0
9.4.0
9.4.0
9.3.0
9.3.0
9.3.0
9.4.0
9.4.0
9.4.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.4.0
9.4.0
9.4.0
9.4.0
9.4.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.4.0
9.4.0
9.4.0
9.4.0
9.4.0
9.4.0
9.4.0
9.4.0
9.3.0
9.3.0
9.4.0
9.4.0
9.3.0
9.4.0
9.3.0
9.4.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.3.0
9.4.0
9.4.0
9.4.0
9.4.0
9.4.0
9.4.0
9.4.0
9.4.0
9.3.0
9.3.0
9.4.0
9.4.0
9.3.0
9.3.0
9.4.0
9.4.0
3GPP
9.4.0 10.0.0
9.4.0 10.0.0
9.4.0 10.0.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
Release 10
Date
TSG # TSG Doc
2010-12
2010-12
2010-12
CT#50
CT#50
CT#50
2010-12
2010-12
2010-12
CT#50
CT#50
CT#50
2010-12
2010-12
2010-12
CT#50
CT#50
CT#50
2010-12
2010-12
2010-12
2010-12
2010-12
2010-12
2010-12
2010-12
CT#50
CT#50
CT#50
CT#50
CT#50
CT#50
CT#50
CT#50
2010-12
CT#50
2010-12
CT#50
CT#50
CT#50
2010-12
2010-12
CT#50
CT#50
2010-12
CT#50
2010-12
CT4 Doc
CR
Rev Cat
CP-100695 C4-103283 0835

CP-100695 C4-103288 0842
1
1
F
F
CP-100688 C4-103315 0848

CP-100675 C4-102779 0773
CP-100675 C4-102781 0775
2
1
1
B
A
A
CP-100675 C4-102783 0777

CP-100675 C4-102514 0781
CP-100675 C4-102787 0783
1
1
A
A
A
CP-100675
CP-100675
CP-100675
CP-100675
CP-100675
CP-100675
CP-100675
CP-100675
0789
0794
0801
0821
0825
0830
0838
0846
1
1
1
2
1
2
A
A
A
A
A
A
A
A
CP-100672 C4-103294 0851
CP-100674 C4-102775 0765
CP-100686 C4-102796 0767

CP-100686 C4-102539 0786
CP-100686 C4-102560 0796
1
-
B
B
B
CP-100686 C4-103135 0797

CP-100686 C4-102599 0802
3
-
B
B
CP-100686 C4-102629 0804
CP-100686 C4-102650 0807
CP-100686 C4-103300 0839
CP-100687
CP-100667
CP-100669
CP-110064
CP-110064
0769
0828
0816
0921
0916
2
2
1
-
B
A
F
B
F
CP-110064 C4-110831 0911

CP-110064 C4-110828 0897
CP-110064 C4-110479 0896
1
1
-
F
F
F
CP-110064 C4-110955 0895

CP-110064 C4-110826 0894
2
1
F
D
CP-110064 C4-110825 0893

CP-110064 C4-110830 0875
1
2
F
F
C4-102789
C4-102556
C4-102794
C4-103238
C4-102938
C4-103322
C4-103249
C4-103331
CT#50
2010-12
2010-12
2010-12
2010-12
192
CT#50
CT#50
2010-12
2010-12
2011-03
2011-03
2011-03
CT#50
CT#50
CT#51
CT#51
CT#51
2011-03
2011-03
2011-03
CT#51
CT#51
CT#51
2011-03
2011-03
CT#51
CT#51
2011-03
2011-03
CT#51
CT#51
2011-03
2011-03
2011-03
2011-03
2011-03
CT#51
CT#51
CT#51
CT#51
CT#51
2011-03
2011-03
2011-03
2011-03
2011-03
2011-03
CT#51
CT#51
CT#51
CT#51
CT#51
CT#51
2011-03
CT#51
2011-03
C4-102928
C4-102970
C4-103340
C4-110875
C4-110585
CP-110064
CP-110064
CP-110064
CP-110064
CP-110064
C4-110331
C4-110369
C4-110257
C4-110392
C4-110112
0874
0872
0871
0870
0869
1
1
1
2
-
F
F
D
F
F
CP-110064
CP-110064
CP-110064
CP-110061
CP-110061
CP-110060
C4-110062
C4-110322
C4-110882
C4-110548
C4-110310
C4-110348
0860
0855
0844
0856
0858
0859
1
6
2
1
1
F
F
F
B
B
B
CP-110049
C4-110994 0918
CP-110049
CT#51 CP-110049
C4-110889 0901
C4-10971 0889
1
3
A
A
3GPP TS 29.274 V10.2.0 (2011-03)

Subject/Comment
Handover Indication
Cause values for Delete Bearer Request
MME/SGSN overload control by throttling of
DL low priority traffic
Suspend and Resume procedure
Range for BSSGP Cause
RAT Type in the Modify Bearer Request
message
ISR for SGW
ISR in the Detach procedure
Missing Cause Code mapping for IRAT
Handover between GERAN and EUTRAN
Voice bearer flag
MBMS corrections
CSG Reporting
Reporting UE Time Zone changes
Essential correction for UE Timezone reporting
ISR activated flag
Determination of type of source node during
TAU/RAU
Essential correction to Create Indirect Data
Forwarding Tunnel Response
GTP-C Information Elements for GTP based
S2b interface
Delete PDN Connection Set
Addition of GTP over S2b to clauses 1 to 6
Create Session Request/Response & Create
Bearer Request/Response
Delete Session and Bearer messages
Modify Bearer Command/Failure Indication
and Update Bearer Req/Rsp
Trace Session Activation/Deactivation for
GTP-S2b
Handling of Create Session Request message
on header TEID = 0
Downlink data notification information for MPS
services
UE Time Zone adjustments
Essential alignment with PMIP spec
Data Delay Notification
Clean up with GTP-C Information Elements
Inclusion of Node Type in DDN Failure
Indication when the ISR is active
UE Network Capability IE
Adding "Initial", "Triggered" and "Initial or
triggered by a Command" attributes to the
messages in table 6.1
Adding a separate subclause for TEID=0
Removing optional Cause IE from Echo
Response
RAT type clarification for S4-SGSN
Essential correction to the table NOTE for the
Create Session Response message
Error Indication for SGW
Cleanup for GTPv2
RAT Type in Modify Access Bearers Request
Bearer context in Modify Bearer Request
S1-U eNodeB F-TEID IE in the Modify Access
Bearers Request
Correction for VNSI
Serving Network IE
APN based congestion control
Low access priority indicator
EBI and ARP IEs in Downlink Data Notification
Protocol Configuration Options (PCO) in
UE Time Zone condition Delete Session
Request
Subscribed UE-AMBR in mobility procedure
3GPP
Old
New
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0
10.0.0
10.0.0
10.0.0
10.0.0
10.0.0
10.0.0
10.0.0
10.1.0
10.1.0
10.1.0
10.1.0
10.1.0
10.1.0
10.1.0
10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0 10.1.0
10.0.0
10.0.0
10.1.0
10.1.0
10.1.0
10.1.0
10.1.0
10.2.0
10.2.0
10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0
10.1.0
10.1.0
10.1.0
10.1.0
10.2.0
10.2.0
10.2.0
10.2.0
10.2.0
10.1.0
10.1.0
10.1.0
10.1.0
10.1.0
10.1.0
10.2.0
10.2.0
10.2.0
10.2.0
10.2.0
10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
Release 10
Date
TSG # TSG Doc
2011-03
CT#51
2011-03
CT#51
2011-03
2011-03
2011-03
2011-03
2011-03
2011-03
2011-03
2011-03
2011-03
2011-03
2011-03
193
CT4 Doc
CR
Rev Cat
CP-110049
C4-110990 0884
CP-110049
C4-110333 0881
CP-110049
CT#51 CP-110049
CT#51 CP-110049
CT#51
CP-110049
CT#51
CP-110042
CT#51 CP-110056
CT#51 CP-110083
CT#51 CP-110053
CT#51
CP-110266
CT#51
CP-110059
CT#51 CP-110072
C4-110170 0879
C4-110330 0866
C4-110074 0862
1
-
A
A
A
C4-110186 0886
C4-110979
C4-111009
C4-110952
C4-110824
0914
0887
0892
0899
1
5
3
1
A
B
B
A
0903
C4-110583 0915
C4-110887 0923
B
B
CT#51
3GPP TS 29.274 V10.2.0 (2011-03)

Subject/Comment
Essential correction to the fallback to GTPv1

feature
RAT Type in the Modify bearer request
message
Missed procedures for the Delete Session
Request and Response messages
Correction to passing of LDN
S103 resource release
Essential correction to the to GTPv2 cause
table
Correcting IE Type for Bearer QoS IE from
Variable to Extendable
Unsupported Bearer Handling for LIPA
Adding IMSI to DDN
Temporary Mobile Group Identity
UE Time Zone condition in Modify Bearer
Request
Serving network in the Create Session
Request message
CS BIT to be available for initial message
3GPP
Old
New
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0 10.2.0
10.1.0
10.1.0
10.1.0
10.1.0
10.2.0
10.2.0
10.2.0
10.2.0
10.1.0 10.2.0
10.1.0 10.2.0

29274-A20 - 3GPP Evolved Packet System (EPS) Evolved General Packet Radio Service (GPRS) Tunnelling Protocol For Control Plane (GTPv2-C) Stage 3

Uploaded by

Copyright:

Available Formats

29274-A20 - 3GPP Evolved Packet System (EPS) Evolved General Packet Radio Service (GPRS) Tunnelling Protocol For Control Plane (GTPv2-C) Stage 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

29274-A20 - 3GPP Evolved Packet System (EPS) Evolved General Packet Radio Service (GPRS) Tunnelling Protocol For Control Plane (GTPv2-C) Stage 3

Uploaded by

Copyright:

Available Formats

3rd Generation Partnership Project;

Technical Specification Group Core Network and Terminals;

3GPP TS 29.274 V10.2.0 (2011-03)

3GPP TS 29.274 V10.2.0 (2011-03)

Definitions, symbols and abbreviations................................................................................................

GTP Header for Control Plane..............................................................................................................

GTP-C Message Types and Message Formats......................................................................................

Message Format and Type values......................................................................................................................

3GPP TS 29.274 V10.2.0 (2011-03)

Bearer Resource Command.........................................................................................................................

3GPP TS 29.274 V10.2.0 (2011-03)

Non-3GPP access related messages.................................................................................................................

GTP-C Information Elements.............................................................................................................

3GPP TS 29.274 V10.2.0 (2011-03)

3GPP TS 29.274 V10.2.0 (2011-03)

CSG Membership Indication (CMI)................................................................................................................

IP - The Networking Technology used by GTP..................................................................................

Notification of supported features between peer GTP-C entities........................................................

Backward Compatibility Guidelines for Information Elements.............

3GPP TS 29.274 V10.2.0 (2011-03)

3GPP TS 29.274 V10.2.0 (2011-03)

3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

3GPP TS 23.003: "Numbering, addressing and identification".

IETF RFC 791 (STD 0005): "Internet Protocol", J. Postel.

IETF RFC 768 (STD 0006): "User Datagram Protocol", J. Postel.

3GPP TS 32.251: "Telecommunication Management; Charging Management; Packet Switched

3GPP TS 32.298: "Telecommunication Management; Charging Management; Charging Data

3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1

3GPP TS 33.102: "3G security; Security architecture".

3GPP TS 33.401: "3GPP System Architecture Evolution (SAE); Security architecture".

3GPP TS 29.281: "GPRS Tunnelling Protocol User Plane (GTPv1-U)".

3GPP TS 29.274 V10.2.0 (2011-03)

3GPP TS 29.280: "3GPP EPS Sv interface (MME to MSC) for SRVCC".

IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification".

3GPP TS 23.007: "Restoration procedures".

3GPP TS 32.422: "Telecommunication management; Subscriber and equipment trace; Trace

3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet".

ITU-T Recommendation E.164: "The international public telecommunication numbering plan".

3GPP TS 29.212: "Policy and charging control over Gx reference point".

3GPP TS 24.007: "Mobile radio interface signalling layer 3; General aspects".

IETF RFC 1035:"Domain Names - Implementation and Specification".

3GPP TS 29.303: "Domain Name System Procedures; Stage 3".

3GPP TS 25.413: "UTRAN Iu Interface RANAP Signalling".

3GPP TS 32.295: "Charging management; Charging Data Record (CDR) transfer".

IETF RFC 3588: "Diameter Base Protocol ".

IETF RFC 4607: "Source-Specific Multicast for IP".

3GPP TS 29.002: "Mobile Application Part (MAP) specification".

3GPP TS 29.274 V10.2.0 (2011-03)

3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses.

3GPP TR 25.999: " HSPA Evolution (FDD)".

Definitions, symbols and abbreviations

Signalling Message: any GTP-PDU (GTP-C or GTP-U) except the G-PDU.

Interface between SGW and eNodeB

Aggregate Maximum Bit Rate

Access Point Name

3GPP TS 29.274 V10.2.0 (2011-03)

3GPP TS 29.274 V10.2.0 (2011-03)

For GTP-U, a TEID-U is used according to 3GPP TS 29.281 [13].

GTP-U is based on GTP version 1 (GTPv1).