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)

REN/TSGN-040960Q7R3

Digitalni celični telekomunikacijski sistem (faza 2+) – Splošna radijska storitev s paketiranimi podatki (GPRS) – Protokol tuneliranja v GPRS (GTP) prek vmesnika Gn in Gp (GSM 09.60, različica 7.5.1, izdaja 1998)

General Information

Status
Published
Publication Date
03-Jan-2001
Technical Committee
Current Stage
12 - Completion
Due Date
08-Dec-2000
Completion Date
04-Jan-2001
Mandate
Standard
EN 301 347 V7.5.1:2003
English language
67 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)


SLOVENSKI STANDARD
01-december-2003
'LJLWDOQLFHOLþQLWHOHNRPXQLNDFLMVNLVLVWHP ID]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.: +33492 94 4200 Fax: +33493 65 4716
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:
editor@etsi.fr
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
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...