SIST EN 301 347 V7.5.1:2003

• Abstract:

  CRs from CN#8

• Status: Published
• Publication Date: 30-Nov-2003
• ICS: 33.070.50 - Global System for Mobile Communication (GSM)
• Technical Committee: SS EIT - Technical Board for the electrotechnical, information technology and telecommunications fields
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Dec-2003
• Due Date: 01-Dec-2003
• Completion Date: 01-Dec-2003
• Mandate: BC-T-330
• Ref Project: ETSI EN 301 347 V7.5.1 (2000-12) - Digital cellular telecommunications system (Phase 2+) (GSM); General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface (GSM 09.60 version 7.5.1 Release 1998)

SIST EN 301 347 V7.5.1:2003 is the Slovenian adoption of EN 301 347 Version 7.5.1. It specifies the GPRS Tunnelling Protocol (GTP) across the Gn and Gp interfaces in the GSM Phase 2+ network, covering how GPRS Support Nodes (GSNs) exchange signalling and user data. It is written for implementers and testers of SGSN and GGSN equipment, and for anyone verifying GPRS backbone interworking.

What does SIST EN 301 347 V7.5.1:2003 specify?

SIST EN 301 347 V7.5.1:2003 defines the GTP used between GSN nodes in the GPRS backbone network. It covers both signalling and transmission-plane tunnelling, and it also lists the messages and information elements used by the related charging protocol GTP’.

The scope is the Gn interface within a PLMN and the Gp interface between PLMNs. In practice, that means the standard is relevant when designing or checking packet routing, tunnel setup, mobility procedures, and inter-network GPRS communication.

The document is organized into clauses for the scope, references, definitions, general principles, bit and octet order, the GTP header, signalling plane procedures, transmission plane procedures, path protocols, error handling, inter-PLMN communication, IP use, and GTP parameters. It ends with three informative annexes.

Annex	What it covers
Annex A	Naming convention for logical names and DNS-based translation of GSNs and Routing Areas
Annex B	A method for sequence number checking for received T-PDUs
Annex C	Document change history

What are the key requirements of SIST EN 301 347 V7.5.1:2003?

SIST EN 301 347 V7.5.1:2003 defines GTP as a tunnel-based protocol with a fixed header, defined message formats, and explicit procedures for creating, updating, and deleting PDP contexts. In practice, implementers need to build compatible header handling, context management, and packet forwarding behavior on both SGSN and GGSN sides.

Header and encoding rules

Clause 5 sets network octet order and bit numbering, and clause 6 defines a fixed 20-octet GTP header for all GTP messages. The header includes version, protocol type, message type, length, sequence number, flow label, SNDCP N-PDU Number, spare fields, and the tunnel identifier (TID). This matters because every implementation must interpret fields the same way or signalling and tunnelling will fail.

Clause 7.9 requires information elements to use TLV or TV encoding, with types sorted in ascending order in a signalling message. That means message parsers must accept the specified structure and reject malformed ordering or lengths according to the error rules.

Signalling plane behaviour

Clause 7 defines the signalling plane for GPRS Mobility Management functions such as GPRS Attach, Routeing Area Update, and PDP Context activation. The standard defines message families for path management, tunnel management, location management, and mobility management. For implementers, this is the control logic that creates tunnels, manages them, and tears them down when the network or mobile state changes.

Clause 7.3 explains how the GTP header is used for signalling messages, including how sequence numbers identify request-response pairs and how the TID is used in tunnel management and mobility management. This matters for matching replies to requests and for binding messages to the correct subscriber context.

Tunnel management and context procedures

Clause 7.5 covers Create, Update, and Delete PDP Context procedures, plus Create and Delete AA PDP Context procedures, Error Indication, and PDU Notification messages. These procedures establish the tunnel for user traffic and carry key data such as QoS Profile, APN, End User Address, GGSN and SGSN addresses, Charging ID, and Charging Gateway Address. In practice, these are the core messages that network elements exchange when a packet data session starts, changes, or ends.

The clause also shows how the GGSN may assign a dynamic PDP address and how the End User Address takes precedence when there is conflicting address information. For buyers and integrators, this means address handling and APN selection must be implemented exactly as specified to avoid session setup errors.

Reliable delivery and recovery

Clause 7.8 defines reliable delivery of signalling messages using per-path queues, sequence numbers, retransmissions, and timers. Clause 10.2 and clause 10.4 add path-failure handling, MS detach handling, and restart recovery with Restart Counters. In practice, implementations must detect lost signalling, retry requests, clear affected contexts after failures, and resynchronize after restarts.

Clause 13 gives configurable parameters, including the T3-RESPONSE timer, the T3-TUNNEL timer, the N3-REQUESTS counter, and the N3-BUFFER-SIZE. These settings matter operationally because they govern retry timing, buffering, and when a path is treated as down.

Transmission plane and path protocols

Clause 8 defines the transmission plane, where G-PDUs carry encapsulated T-PDUs between GSN pairs. The GTP header identifies the tunnel, while the path protocol carries the packet over the backbone. Clause 9 states that UDP/IP is the path protocol for signalling in this version and the recommended connection-less path for connection-less T-PDUs, while TCP/IP is the recommended reliable connection-oriented path for connection-oriented T-PDUs.

Clause 12 states that IPv4 is the networking technology on which GTP tunnelling is based in this phase. It also covers fragmentation considerations, so implementers need to size links and packet handling to avoid unnecessary fragmentation in the backbone.

Inter-PLMN communication

Clause 11 states that no security is provided by GTP itself for communication between different GPRS networks over the Gp interface. That means operators need to handle protection between Border Gateways by agreement and external security mechanisms if required.

What terms does SIST EN 301 347 V7.5.1:2003 define?

• G-PDU - A G-PDU is a T-PDU combined with a GTP header, so it is the packet format carried across the backbone.
• GTP tunnel - A GTP tunnel is the paired context used to forward packets for one subscriber session between two GSNs.
• GTP flow - A GTP flow is a one-way aggregation of G-PDUs and/or signalling messages linked to one or more tunnels.
• MM Context - An MM Context is the set of mobility-management information held for a GPRS subscriber in the MS and GSNs.
• NSAPI - The Network Service Access Point Identifier identifies a particular PDP Context inside an MM Context ID.
• T-PDU - A T-PDU is the original user packet being carried through the tunnel, such as an IP datagram.
• TID - The Tunnel ID combines the MM Context ID and NSAPI and points to the subscriber session in the header.
• Path Protocol - The Path Protocol is the bearer protocol used between GSNs to carry GTP, such as UDP/IP or TCP/IP.

Who uses SIST EN 301 347 V7.5.1:2003?

SIST EN 301 347 V7.5.1:2003 is used by vendors of SGSN and GGSN equipment, mobile network engineers, protocol testers, and operators responsible for GPRS backbone interoperability. It is also relevant to quality managers and buyers who need to verify that GPRS network elements support the right signalling, tunnelling, and recovery behavior.

Typical tasks include implementing Create and Delete PDP Context procedures, handling inter-SGSN Routeing Area Update traffic, mapping logical names to IP addresses, testing sequence-number handling, and checking charging-related information elements. It is also used when validating GTP-MAP interworking for network-requested PDP context activation.

What changed in SIST EN 301 347 V7.5.1:2003 from the previous edition?

Annex C records V7.5.1 as an update for publication. The change history also shows that this edition sits on top of the earlier Release 1998 work on GTP messages, information elements, timer handling, APN transfer, MSISDN in Create PDP Context, and related clarifications.

Which standards are used with SIST EN 301 347 V7.5.1:2003?

The document references several companion standards and protocols that provide the surrounding GSM and IP functions:

• GSM 01.04 - abbreviations and acronyms.
• GSM 03.03 - numbering, addressing, and identification.
• GSM 03.07 - restoration procedures.
• GSM 03.20 - security-related network functions.
• GSM 03.60 - GPRS service description and the procedures that trigger GTP signalling.
• GSM 03.64 - overall description of the GPRS radio interface.
• GSM 04.08 - mobile radio interface layer 3, including several encodings used by GTP information elements.
• GSM 04.64 - LLC layer specification.
• GSM 09.02 - MAP procedures used in GTP-MAP interworking.
• GSM 12.15 - GTP’ charging protocol.
• STD 0005, STD 0006, STD 0007 - IP, UDP, and TCP.
• RFC 1700 and RFC 2181 - assigned numbers and DNS clarifications.
• ITU-T X.25 and X.121 - packet-mode access and numbering for X.25-based addressing.

What does the SIST EN 301 347 V7.5.1:2003 document contain?

The document contains message tables, information element tables, header diagrams, protocol stack figures, and encoding figures for the main GTP fields. It shows the formats for GTP signalling messages, G-PDUs, the TID, Cause values, End User Address variants for IPv4, IPv6, X.25, PPP, and OSP:IHOSS, and the MM Context and PDP Context information elements.

It also includes the procedure text for path management, tunnel management, location management, mobility management, reliable delivery, error handling, restoration, and recovery. Annex B gives a worked method for checking received T-PDU sequence numbers, and Annex A gives an optional naming convention for logical GSN and Routing Area names.

SLOVENSKI STANDARD
01-december-2003
'LJLWDOQLFHOLþQLWHOHNRPXQLNDFLMVNLVLVWHPID]D±6SORãQDUDGLMVNDVWRULWHYV
SDNHWLUDQLPLSRGDWNL*356±3URWRNROWXQHOLUDQMDY*356*73SUHNYPHVQLND
*QLQ*S*60UD]OLþLFDL]GDMD
Digital cellular telecommunications system (Phase 2+) (GSM); General Packet Radio
Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface
(GSM 09.60 version 7.5.1 Release 1998)
Ta slovenski standard je istoveten z: EN 301 347 Version 7.5.1
ICS:
33.070.50 Globalni sistem za mobilno Global System for Mobile
telekomunikacijo (GSM) Communication (GSM)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

European Standard (Telecommunications series)
Digital cellular telecommunications system (Phase 2+);
General Packet Radio Service (GPRS);
GPRS Tunnelling Protocol (GTP)
across the Gn and Gp Interface
(GSM 09.60 version 7.5.1 Release 1998)
R
GLOBAL SYSTEM FOR
MOBILE COMMUNICATIONS
2 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
Reference
REN/TSGN-040960Q7R3
Keywords
Digital cellular telecommunications system,
Global System for Mobile communications (GSM)
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: [phone] Fax: [phone]
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at http://www.etsi.org/tb/status/
If you find errors in the present document, send your comment to:
[e-mail]
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.
© European Telecommunications Standards Institute 2000.
All rights reserved.
ETSI
3 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
Contents
Intellectual Property Rights .6
Foreword.6
1 Scope.7
2 References.7
3 Definitions and abbreviations.8
3.1 Definitions . 8
3.2 Abbreviations. 9
4 General.9
5 Transmission order and bit definitions.10
6 GTP header.10
7 Signalling Plane.12
7.1 Signalling protocol . 12
7.2 Signalling Message Formats . 13
7.3 Usage of the GTP Header . 14
7.4 Path Management messages. 14
7.4.1 Echo Request. 14
7.4.2 Echo Response. 15
7.4.3 Version Not Supported. 15
7.5 Tunnel Management messages. 15
7.5.1 Create PDP Context Request . 15
7.5.2 Create PDP Context Response. 17
7.5.3 Update PDP Context Request. 19
7.5.4 Update PDP Context Response. 20
7.5.5 Delete PDP Context Request . 21
7.5.6 Delete PDP Context Response. 21
7.5.7 Create AA PDP Context Request. 22
7.5.8 Create AA PDP Context Response . 23
7.5.9 Delete AA PDP Context Request. 24
7.5.10 Delete AA PDP Context Response . 25
7.5.11 Error Indication. 25
7.5.12 PDU Notification Request. 25
7.5.13 PDU Notification Response. 26
7.5.14 PDU Notification Reject Request . 27
7.5.15 PDU Notification Reject Response. 27
7.6 Location Management messages. 28
7.6.1 Send Routeing Information for GPRS Request.28
7.6.2 Send Routeing Information for GPRS Response . 28
7.6.3 Failure Report Request. 29
7.6.4 Failure Report Response . 29
7.6.5 Note MS GPRS Present Request . 30
7.6.6 Note MS GPRS Present Response . 30
7.7 Mobility Management messages. 31
7.7.1 Identification Request . 31
7.7.2 Identification Response. 31
7.7.3 SGSN Context Request . 32
7.7.4 SGSN Context Response. 33
7.7.5 SGSN Context Acknowledge . 34
7.8 Reliable delivery of signalling messages . 34
7.9 Information elements. 35
7.9.1 Cause. 35
7.9.2 International Mobile Subscriber Identity (IMSI) . 38
7.9.3 Routeing Area Identity (RAI) . 38
ETSI
4 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
7.9.4 Temporary Logical Link Identity (TLLI) . 39
7.9.5 Packet TMSI (P-TMSI). 39
7.9.6 Quality of Service (QoS) Profile. 39
7.9.7 Reordering Required. 40
7.9.8 Authentication Triplet . 40
7.9.9 MAP Cause . 41
7.9.10 P-TMSI Signature. 41
7.9.11 MS Validated. 41
7.9.12 Recovery . 42
7.9.13 Selection mode . 42
7.9.14 Flow Label Data I . 42
7.9.15 Flow Label Signalling. 43
7.9.16 Flow Label Data II. 43
7.9.17 Charging ID. 43
7.9.18 End User Address . 44
7.9.19 MM Context . 46
7.9.20 PDP Context. 47
7.9.21 Access Point Name . 50
7.9.22 Protocol Configuration Options. 50
7.9.23 GSN Address. 50
7.9.24 MS International PSTN/ISDN Number (MSISDN). 51
7.9.25 Charging Gateway Address. 51
7.9.26 Private Extension . 51
8 Transmission Plane.52
8.1 Protocol Stack. 52
8.1.1 Usage of the GTP Header. 52
8.1.1.1 Usage of the Sequence Number. 53
8.2 Tunnelling between SGSNs. 53
8.3 Tunnelling between GGSNs . 53
9 Path Protocols.53
9.1 UDP/IP . 53
9.1.1 UDP Header . 54
9.1.1.1 Signalling request messages. 54
9.1.1.2 Signalling response messages. 54
9.1.1.3 Encapsulated T-PDUs. 54
9.1.2 IP Header. 54
9.1.2.1 Signalling request messages and Encapsulated T-PDUs. 54
9.1.2.2 Signalling response messages. 54
9.2 TCP/IP. 54
9.2.1 TCP Header . 54
9.2.2 IP Header. 54
10 Error handling .55
10.1 Protocol errors. 55
10.1.1 Different GTP versions . 55
10.1.2 GTP Message too short . 55
10.1.3 Unknown GTP signalling message . 55
10.1.4 Unexpected GTP signalling message. 55
10.1.5 Missing mandatorily present information element. 55
10.1.6 Invalid Length. 56
10.1.7 Invalid mandatory information element . 56
10.1.8 Invalid optional information element. 56
10.1.9 Unknown information element . 56
10.1.10 Out of sequence information elements. 56
10.1.11 Unexpected information element. 56
10.1.12 Repeated information elements. 57
10.1.13 Incorrect optional information elements. 57
10.2 Path failure. 57
10.3 MS detach. 57
10.4 Restoration and Recovery. 57
ETSI
5 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
11 Inter-PLMN GTP communication over the Gp interface.57
12 IP, the networking technology used by GTP.57
12.1 IP version. 57
12.2 IP fragmentation. 58
12.2.1 MO direction . 58
12.2.2 MT direction. 58
12.2.3 Tunnelling from old to new SGSN . 58
13 GTP parameters.58
13.1 Timers. 59
13.2 Others . 59
Annex A (informative): Naming convention .64
A.1 Routing Area Identities .64
A.2 GPRS Support Nodes.64
Annex B (informative): A method for sequence number checking .65
Annex C (informative): Document change history .66
History .67
ETSI
6 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://www.etsi.org/ipr).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This European Standard (Telecommunications series) has been produced by ETSI Technical Committee Special Mobile
Group (SMG).
The present document defines the Gn and Gp interfaces for the General Packet Radio Service (GPRS) within the digital
cellular telecommunications system (Phase 2+).
The contents of the present document are subject to continuing work within SMG and may change following formal
SMG approval. Should SMG modify the contents of the present document, it will then be re-submitted for OAP by
ETSI with an identifying change of release date and an increase in version number as follows:
Version 7.x.y
where:
7 indicates Release 1998 of GSM Phase 2+.
x the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
y the third digit is incremented when editorial only changes have been incorporated in the specification.
National transposition dates
Date of adoption of this EN: 1 December 2000
Date of latest announcement of this EN (doa): 31 March 2001
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 30 September 2001
Date of withdrawal of any conflicting National Standard (dow): 30 September 2001
ETSI
7 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
1 Scope
The present document defines the Gn and Gp interfaces for the General Packet Radio Service (GPRS).
2 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.
• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same
number.
• For this Release 1998 document, references to GSM documents are for Release 1998 versions (version 7.x.y).
[1] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and
acronyms".
[2] GSM 03.03: "Digital cellular telecommunications system (Phase 2+); Numbering, addressing and
identification".
[3] GSM 03.07: "Digital cellular telecommunications system (Phase 2+); Restoration Procedures".
[4] GSM 03.20: "Digital cellular telecommunications system (Phase 2+); Security related network
functions".
[5] GSM 03.60: "Digital cellular telecommunications system (Phase 2+); General Packet Radio
Service (GPRS); Service Description; Stage 2".
[6] GSM 03.64: "Digital cellular telecommunications system (Phase 2+); General Packet Radio
Service (GPRS); Overall description of the GPRS Radio Interface; Stage 2".
[7] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface
layer 3 - specification".
[8] GSM 04.64: "Digital cellular telecommunications system (Phase 2+); Mobile Station - Serving
GPRS Support Node (MS-SGSN) Logical Link Control (LLC) Layer Specification".
[9] GSM 09.02: "Digital cellular telecommunications system (Phase 2+); Mobile Application Part
(MAP) specification".
[10] STD 0005: "Internet Protocol", J. Postel.
[11] STD 0006: "User Datagram Protocol", J. Postel.
[12] STD 0007: "Transmission Control Protocol", J. Postel.
[13] RFC 1700: "Assigned Numbers", J. Reynolds and J. Postel.
[14] RFC 2181: "Clarifications to the DNS Specification", R. Elz and R. Bush.
[15] ITU-T Recommendation X.25: "Interface between data terminal equipment (DTE) and data
circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to
public data networks by dedicated circuit".
[16] ITU-T Recommendation X.121: "International Numbering Plan for Public Data Networks".
ETSI
8 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Conditional: when the presence requirement for the information element is conditional, the receiving protocol level can
check the presence or absence of an IE based on the received information
G-PDU: T-PDUplus a GTPheader. AG-PDUis sentin a path
GTP-Flow: GTP flow is defined by the unidirectional virtual aggregation of G-PDUs and/or signalling messages
related to one or more GTP tunnels. A GTP flow is identified by a Flow Label included in the GTP header. The
meaning of the Flow Label is transparent for the transmitter side, only the receiver may evaluate the Flow Label
GTP tunnel: GTP tunnel is defined by two associated PDP Contexts in different GSN nodes and is identified with a
Tunnel ID. A GTP tunnel is necessary to forward packets between an external packet data network and a MS user
MM Context: information sets held in MS and GSNs for a GPRS subscriber related to mobility management (MM)
(please refer to the MM Context Information Element)
MM Context ID:IMSI or equivalent for use in conjunction with Anonymous Access (please refer to section GTP
Header)
NSAPI: Network Service Access Point Identifier. An integer value in the range [0; 15], identifying a certain PDP
Context. It identifies a PDP context belonging to a specific MM Context ID
Path: UDP/IP path and TCP/IP path are examples of paths that may be used to multiplex GTP tunnels
Path Protocol: Path Protocol is the protocol(s) used as a bearer of GTP between GSNs
PDP: Packet Data Protocol (PDP) is a network protocol used by an external packet data network interfacing to GPRS
PDP Context: information sets held in MS and GSNs for a PDP address (please refer to the PDP Context Information
Element)
Quality of Service: Quality of Service may be applicable for the GPRS backbone if the path media supports it.
Separate paths with different priorities may be defined between a GSN pair. However, the possible use of QoS in the
GGSN is outside the scope of the GTP specification
Signalling message: GTP signalling messages are exchanged between GSN pairs in a path. The signalling messages are
used to transfer GSN capability information between GSN pairs and to create, update and delete GTP tunnels
TCP/IP path: TCP/IP path is a reliable connection-oriented path defined by two end-points and an end-point is defined
by an IP address and a TCP port number. TCP/IP paths should be used when the T-PDUs are based on connection-
oriented protocols, such as the X.25 packet layer protocol
T-PDU: original packet, for example an IP datagram, from a MS or a network node in an external packet data network.
A T-PDU is the payload that is tunnelled in the GTP tunnel
TID: Tunnel ID (TID) consists of a MM Context ID and a NSAPI
UDP/IP path: UDP/IP path is a connection-less path defined by two end-points and an end-point is defined by an IP
address and a UDP port number. A UDP/IP path carries G-PDUs between GSN nodes related to one or more GTP
tunnels. A UDP/IP path should be used when the T-PDUs are based on connection-less protocols, such as IP
ETSI
9 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
3.2 Abbreviations
Abbreviations used in the present document are listed in GSM 01.04.
For the purposes of the present document, the following additional abbreviations apply:
BB Backbone Bearer
DF Don’t Fragment
FFS For Further Study
Gn interface Interface between GPRS Support Nodes (GSNs) within a PLMN
Gp interface Interface between GPRS Support Nodes (GSNs) in different PLMNs
GTP GPRS Tunneling Protocol
IANA Internet Assigned Number Authority
ICMP Internet Control Message Protocol
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
MTU Maximum Transmission Unit
QoS Quality of Service
TCP Transmission Control Protocol
TID Tunnel IDentifier
UDP User Datagram Protocol
4 General
The present document defines the GPRS Tunnelling Protocol (GTP), i.e. the protocol between GSN nodes in the GPRS
backbone network. It includes both the GTP signalling and data transfer procedures. It also lists the messages and
information elements used by the GTP based charging protocol GTP’, which is described in GSM 12.15.
GTP is defined both for the Gn interface, i.e. the interface between GSNs within a PLMN, and the Gp interface between
GSNs in different PLMNs. GTP’ is defined for the interface between CDR generating functional network elements and
Charging Gateway(s) within a PLMN. Charging Gateway(s) and GTP’ protocol are optional, as the Charging Gateway
Functionalities may either be located in separate network elements (Charging Gateways), or alternatively be embedded
into the CDR generating network elements (GSNs) when the GSN-CGF interface is not necessarily visible outside the
network element. These interfaces relevant to GTP are between the grey boxes shown in figure 1.
ETSI
10 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
Gr or Gc
GTP-MAP
HLR
protocol
converting
GSN
Gn
SGSN Gc
Gn
Gi
R Um Gb
PDN TE
TE MT BSS SGSN GGSN
Gn
Gp
R Um Gb
TE MT BSS SGSN
Other PLMN
Signalling Interface
Signalling and Data Transfer Interface
Figure 1: GPRS Logical Architecture with interface name denotations
GTP allows multiprotocol packets to be tunnelled through the GPRS Backbone between GPRS Support Nodes (GSNs).
In the signalling plane, GTP specifies a tunnel control and management protocol which allows the SGSN to provide
GPRS network access for a MS. Signalling is used to create, modify and delete tunnels.
In the transmission plane, GTP uses a tunnelling mechanism to provide a service for carrying user data packets. The
choice of path is dependent on whether the user data to be tunnelled requires a reliable link or not.
The GTP protocol is implemented only by SGSNs and GGSNs. No other systems need to be aware of GTP. GPRS MSs
are connected to a SGSN without being aware of GTP.
It is assumed that there will be a many-to-many relationship between SGSNs and GGSNs. A SGSN may provide
service to many GGSNs. A single GGSN may associate with many SGSNs to deliver traffic to a large number of
geographically diverse mobile stations.
5 Transmission order and bit definitions
The messages in this document shall be transmitted in network octet order starting with octet 1. Where information
elements are repeated within a message the order shall be determined by the order of appearance in the table defining
the information elements in the message.
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.
6 GTP header
The GTP header shall be a fixed format 20-octet header used for all GTP messages.
- Version bits: If the PT bit is ‘1’ (indicating a GTP message), the Version shall be set to 0 to indicate this, the first
version of GTP. For the treatment of other versions, see section 10.1.1, "Different GTP versions".
ETSI
11 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
- PT (Protocol Type) bit indicates whether the message is a GTP message (when PT is ‘1’) or a GTP’ message
(when PT is ‘0’). GTP is described in this document and the GTP’ protocol in GSM 12.15. Note that the
interpretation of the header fields may be different in GTP’ than in GTP.
- Spare ‘1’: These unused bits shall be set to ‘1’ by the sending side and shall not be evaluated by the receiving
side.
- SNN is a flag indicating if SNDCP N-PDU Number is included or not.
- Message Type indicates the type of GTP message.
- Length indicates the length in octets of the GTP message (G-PDU), excluding the GTP header. Bit 8 of octet 3 is
the most significant bit and bit 1 of octet 4 is the least significant bit of the length field.
- Sequence Number is a transaction identity for signalling messages and an increasing sequence number for
tunnelled T-PDUs.
- SNDCP N-PDU Number is used at the Inter SGSN Routeing Area Update procedure to co-ordinate the data
transmission between the MS and SGSN.
- TID is the tunnel identifier that points out MM and PDP contexts (see Figure 3: Tunnel ID (TID) format).
- The flow label identifies unambiguously a GTP flow.
All fields in the GTP header shall always be present but the content of the fields differs depending on if the header is
used for signalling messages (see the sub-section Usage of the GTP Header in the section Signalling Plane) or T-PDUs
(see the sub-section Usage of the GTP Header in the section Transmission Plane).
Bits
Octets 8765 4321
1 Version PT Spare‘111‘ SNN
2 Message Type
3-4 Length
5-6 Sequence Number
7-8 Flow Label
9 SNDCP N-PDULLC Number
10 Spare‘11111111‘
11 Spare‘11111111‘
12 Spare‘11111111‘
13-20 TID
1) LLC frame number (continued)
Figure 2: Outline of GTP header
ETSI
12 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
Bits
Octets 8 7 6 5 4 3 2 1
IMSI digit 2 IMSI digit 1
IMSI digit 4 IMSI digit 3
IMSI digit 6 IMSI digit 5
IMSI digit 8 IMSI digit 7
IMSIdigit10 IMSIdigit9
IMSIdigit12 IMSIdigit11
IMSIdigit14 IMSIdigit13
NSAPI IMSI digit 15
The IMSI is defined in GSM 03.03 (and includes MCC, MNC and MSIN). IMSI digits that are not used
shall be coded as binary '1 1 1 1'.
NOTE: For Anonymous Access, the MSIN part of the IMSI shall be replaced by a number assigned by the
particular PLMN. The assigned number shall not collide with any MSIN used in the PLMN and shall be
unique within the PLMN.
Figure 3: Tunnel ID (TID) format
7 Signalling Plane
The signalling plane in this case relates to GPRS Mobility Management functions like for example GPRS Attach, GPRS
Routeing Area Update and Activation of PDP Contexts. The signalling between GSN nodes shall be performed by the
GPRS Tunnelling Protocol (GTP).
GTP GTP
Path Protocol Path Protocol
GSN Gn, Gp GSN
Figure 4: Signalling Plane - Protocol stack
7.1 Signalling protocol
The GTP signalling flow shall be logically associated with, but separate from, the GTP tunnels. For each GSN-GSN
pair one or more paths exist. One or more tunnels may use each path. GTP shall be the means by which tunnels are
established, used, managed and released. A path may be maintained by keep-alive echo messages. This ensures that a
connectivity failure between GSNs can be detected in a timely manner.
ETSI
13 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
7.2 Signalling Message Formats
GTP defines a set of signalling messages between two associated GSNs. The signalling messages to be used are defined
in the table below.
Table 1: Signalling messages
Message Type value Signalling message Reference
(Decimal)
0 For future use. Shall not be sent. If received, shall
be treated as an Unknown message.
1 Echo Request 7.4.1
2 Echo Response 7.4.2
3 Version Not Supported 7.4.3
4 Node Alive Request GSM 12.15
5 Node Alive Response GSM 12.15
6 Redirection Request GSM 12.15
7 Redirection Response GSM 12.15
8-15 For future use. Shall not be sent. If received, shall
be treated as an Unknown message.
16 Create PDP Context Request 7.5.1
17 Create PDP Context Response 7.5.2
18 Update PDP Context Request 7.5.3
19 Update PDP Context Response 7.5.4
20 Delete PDP Context Request 7.5.5
21 Delete PDP Context Response 7.5.6
22 Create AA PDP Context Request 7.5.7
23 Create AA PDP Context Response 7.5.8
24 Delete AA PDP Context Request 7.5.9
25 Delete AA PDP Context Response 7.5.10
26 Error Indication 7.5.11
27 PDU Notification Request 7.5.12
28 PDU Notification Response 7.5.13
29 PDU Notification Reject Request 7.5.14
30 PDU Notification Reject Response 7.5.15
31 For future use. Shall not be sent. If received, shall
be treated as an Unknown message.
32 Send Routeing Information for GPRS Request 7.6.1
33 Send Routeing Information for GPRS Response 7.6.2
34 Failure Report Request 7.6.3
35 Failure Report Response 7.6.4
36 Note MS GPRS Present Request 7.6.5
37 Note MS GPRS Present Response 7.6.6
38-47 For future use. Shall not be sent. If received, shall
be treated as an Unknown message.
48 Identification Request 7.7.1
49 Identification Response 7.7.2
50 SGSN Context Request 7.7.3
51 SGSN Context Response 7.7.4
52 SGSN Context Acknowledge 7.7.5
53-239 For future use. Shall not be sent. If received, shall
be treated as an Unknown message.
240 Data Record Transfer Request GSM 12.15
241 Data Record Transfer Response GSM 12.15
242-254 For future use. Shall not be sent. If received, shall
be treated as an Unknown message.
255 T-PDU 8.1.1
ETSI
14 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
7.3 Usage of the GTP Header
For signalling messages the GTP header shall be used as follows:
-SNNshallbesetto0.
- Message Type shall be set to the unique value that is used for each type of signalling message.
- Length shall be the length, in octets, of the signalling message excluding the GTP header.
- SNDCP N-PDU Number: this field is not yet used in signalling messages. It shall be set to 255 by the sender and
shall be ignored by the receiver.
- Sequence Number shall be a message number valid for a path or a tunnel. Within a given set of contiguous
Sequence Numbers from 0 to 65535, a given Sequence Number shall, if used, unambiguously define a GTP
signalling request message sent on the path or tunnel (see section Reliable delivery of signalling messages). The
Sequence Number in a signalling response message shall be copied from the signalling request message that the
GSN is replying to.
- TID (see figure 3: Tunnel ID (TID) format) shall be set to 0 in all Path Management messages (see section Path
Management messages), Location Management messages (see section Location Management messages) and
Mobility Management messages (see section Mobility Management messages). In the Tunnel Management
messages (see section Tunnel Management messages), TID shall be used to point out the MM and PDP Contexts
in the destination GSN.
- In all Path Management messages (see section Path Management messages) and Location Management
messages (see section Location Management messages) the Flow Label is not used and shall be set to 0 . In case
of Tunnel Management message and Mobility Management messages the Flow Label is set to the requested
value and points out the GTP flow except for the Create PDP Context Request message as well as Identification
Request/Response and SGSN Context Request message (see section Mobility Management messages).
The GTP header may be followed by subsequent information elements dependent on the type of signalling message.
Only one information element of each type is allowed in a single signalling message, except for the Authentication
Triplet, the PDP Context and the Flow Label Data II information element where several occurrences of each type are
allowed.
Bits
Octets 8 7 6 5 4 3 2 1
1 - 20 GTP header
21 - n Information Element(s)
Figure 5: GTP header followed by subsequent Information Elements
7.4 Path Management messages
The Path Management messages may be sent between any type of GSN pair.
7.4.1 Echo Request
An Echo Request may be sent on a path to another GSN to find out if the peer GSN is alive (see section Path Failure).
Echo Request messages may be sent for each path in use. A path is considered to be in use if at least one PDP context
uses the path to the other GSN. When and how often an Echo Request message may be sent is implementation specific
but an Echo Request shall not be sent more often than every 60 seconds on each path.
A GSN shall be prepared to receive an Echo Request at any time and it shall reply with an Echo Response. A GSN may
optionally send Echo Request messages.
ETSI
15 ETSI EN 301 347 V7.5.1 (2000-12)
(GSM 09.60 version 7.5.1 Release 1998)
The optional Private Extension contains vendor or operator specific information.
Table 2: Information elements in an Echo Request
Information element Presence requirement Reference
Private Extension Optional 7.9.26
7.4.2 Echo Response
The message shall be sent as a response of a received Echo Request.
The Recovery information element contains the local Restart Counter (see section Restoration and Recovery) value for
the GSN that sends the Echo Response message.
The GSN that receives an Echo Response from a peer GSN shall compare the Restart Counter value received with the
previous Restart Counter value stored for that peer GSN. If no previous value was stored, the Restart Counter value
received in the Echo Response shall be stored for the peer GSN.
If the value of a Restart Counter previously stored for a peer GSN differs from the Restart Counter value received in the
Echo Response from that peer GSN, the GSN that sent the Echo Response shall be considered as restarted by the GSN
that received the Echo Response
...