The document describes the GPRS Tunnelling Protocol (GTP) used in 2G and 3G mobile networks. It discusses GTP interfaces and tunnels, message formats including the GTP header, and message groups. The key points are:
1. GTP is used between GPRS Support Nodes (GSNs) and between SGSN and RNC to tunnel user data packets and control signaling messages.
2. The GTP header contains fields for version, message type, length, TEID, and optional fields for sequence number and N-PDU number.
3. GTP messages are grouped into path management messages for path verification, tunnel management messages for context creation/deletion, and location/mobility management messages
1. Chapter 5
GTP – the tunnel
Contents:
5.1 GTP interfaces
1. Protocols for Combined Procedures
2. GTP interfaces
3. Control and User plane
4. Tunnel Endpoint Identifier
5. GTP and UDP
5.2 Message formats
1. The GTPv1 frame
2. Optional fields in the Header
3. GTP header for the G-PDU Example
5.3 GTP message groups
1. Message groups
2. Path Management Messages
3. Tunnel Management Messages
4. Location Management Messages
5. Mobility Management Messages
5.4 GTP messages
2. Chapter 5
GTP –the tunnel
5.1 GTP interfaces
1. Protocols for Combined Procedures
2. GTP interfaces
3. Control and User plane
4. Tunnel Endpoint Identifier
5. GTP and UDP
3. GTP interfaces
In the 2nd generation mobile communication network GSM/GPRS, the GPRS Tunnelling Protocol (GTP) is used
between the GPRS Support Nodes (GSN) and for 3 rd generation networks as well between SGSN and RNC (not
covered here):
•Gn-interface: The Gn interface is in use between SGSN and GGSN within one operator‘s network infrastructure
and between SGSNs. The Gn-interface between SGSNs is required to support service continuation in case of
inter-SGSN cell reselection.
•Gp-interface: The SGSN is located in the visited network, where a roaming subscriber is currently registered, but
the GGSN is located in a foreign network (normally, in the subscriber‘s home network).
•(Ga-interface: This interface is used between the GSNs and the Charging Gateway Function (CGF). A derivate
of the GTP is used, denoted GTP‘. Both CGF and GTP‘ are optional. The CGF may located in a stand-alone
device, often called Charging Gateway. Alternatively, it may be implemented in the GSN units. The GTP‘ was
designed to carry charging related information. GSM 12.15).
GTP version 0 GTP version 1
versions of GTP: GSM 09.60 3GPP TS 29.060
GTP GTP GTP GTP
There are important changes from GTP Release 98 to GTP Release
UDP / UDP / UDP / UDP / 99. The main reason is that GTP shall also be used in the backbone of
TCP TCP TCP TCP UMTS networks(Gn, Gp and Iu interfaces). To meet this requirement
IP IP IP IP some additional messages for SGSN Relocation procedure have been
defined.
L2 L2 L2 L2
Furthermore some Information Elements have changed in Release 99.
L1 L1 L1 L1 The most significant change in IEs is that a so-called Tunnel Endpoint
Gn Gn Gp Identifier (TEID) substitutes the Tunnel ID (TID) and the Flow Labels.
SGSN SGSN GGSN SGSN Anonymous PDP Contexts in Release 98 are not specified any longer
in Release 99
Another PLMN
4. Control and User plane
GTP-PDU: A GTP Protocol Data Unit is either a control plane (GTP-C)
• Tunnel control message or a user plane (GTP-U) message.
• Management protocol The control plane messages (GTP-C) are used to transfer GSN
capability information between GSN pairs, to create, update and delete
GTP tunnels and for path management.
The tunnels for GTP-U protocol entities make a transport service for one
Tunnelling mechanism PDP context. The user plane messages are used to carry user data
for transfer of user packets and signalling messages for path management and error
packet data indication. G-PDU: A G-PDU carries a user data message. It consists of a
T-PDU (Original user packet data, for example an IP datagram) plus a
GTP header.
Note: All GSNs supporting GTPv1 must support a fallback to GTPv0.
GSN
UDP/IP is the only path protocol
defined to transfer GTP messages in the
GTP-C GTPv1 1 of GTP. A User
version Datagram
GTPv1
GTP-U Protocol (UDP) compliant with RFC 768
shall be used.
UDP UDP
IPvX In Rel 99
IPvX only
L2 L2 UDP
L1 L1 GSN
Gn/Gp
5. Tunnel Endpoint Identifier
A GTP tunnel in the GTP-U plane is defined for each PDP Context or each MBMS (MultiMedia
Broadcast/Multicast Service) in the GSNs. It is necessary to forward packets between an external packet data
network and an MS user.
A GTP tunnel in the GTP-C plane is defined for all PDP Contexts with the same PDP address and APN (for
Tunnel Management messages) or for each MS (for messages not related to Tunnel Management).
A GTP tunnel is identified in each node with a TEID, an IP address and a UDP port number.
The Tunnel Endpoint Identifier (TEID) unambiguously identifies a tunnel endpoint in the receiving GTP-U or
GTP-C protocol entity. 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 RANAP, over the
Iu) messages. If the TEID ≠ 0, then one PDP Context is addressed. TEID = 0 holds messages not associated
with one PDP context.
PDP GTP-C PDP
PDP TEIDGSN,control
PDP
PDP PDP
PDP PDP
GTP TEIDGSN,user GTP individual
UDP PDP Contexts:
UDP
GTP-U PDP
IP IP
6. GTP and UDP
User data and GTP signalling and control information have to be exchanged between GSNs. The path between two
network nodes is described by an IP address and the UDP port number. For GTP-C request messages, the UDP
destination port number is always 2123, while the UDP source port number can be allocated locally. For GTP-U
request messages, the UDP destination port number is always 2152, and the UDP source port number is allocated
locally. In the response message, the destination port number is the source GSN‘s source port number, while the
source port number is the source GSN‘s UDP destination port number. User data packets (so-called T-PDU) are
transmitted in the same way as GTP-U request messages. The combination of UDP port number and IP address is
often called UDP/IP path.
UDP/IP Path: connection-less unidirectional or bidirectional path defined by two end-points
An IP address and a UDP port number define an end-point. A UDP/IP path carries GTP messages between GSN
nodes, and between GSN and RNC nodes related to one or more GTP tunnels. There is one GTP-entity for each
used IP address.
GSN
GTP-C GSN
TEIDGSN,control Source Port Dest. Port
PDP
Request ? 2123 PDP
PDP
PDP
PDP Response 2123 ?
PDP
PDP TEIDGSN,user PDP
GTP
GTP
GTP-U Source Port Dest. Port individual
UDP Request ? 2152 PDP Contexts:
UDP
IP Response 2152 ? PDP
IP
7. Chapter 5
GTP –the tunnel
5.2 Message formats
1. The GTPv1 frame
2. Optional fields in the Header
3. GTP header for the G-PDU Example
8. The GTPv1 frame I
8 7 6 5 4 3 2 1
The GTPv1 frame contains the following elements. version (3 bits): The version field
1 Version PT X E S PN
indicates the differentiates between different GTP versions. GTP version 1 = binary
value ‘001’.
2 Message Type
PT (Protocol Type) (1 bit): The protocol type indicates GTP (PT = 1) or GTP' (PT =
3 0).
Length X is a spare bit. It shall be sent as '0'
4
E (Extension Header Flag) (1 bit): This bit indicates whether the octet 12 of the
5 header shall be evaluated (E=1) or not (E=0)
Tunnel S (Sequence Number Flag) (1 bit): This bit indicates whether the octets 9 and 10
6 shall be evaluated (S=1) or not (S=0).
Endpoint
Identifier PN (N-PDU Number Flag) (1 bit): This bit indicates whether the octet 11 shall be
7
(TEID) evaluated (PN = 1) or not (PN = 0).
8 Message Type (1 octet): The message type identifies a GTP message: Some
messages exist for GTP-U, GTP-C, and GTP’ protocol entities, such as the message
9 Echo Request. But most of the messages are used by a single GTP protocol entity.
Sequence Number For instance, the Create PDP Context Request is only a GTP-C protocol entity
10 message.
Message Types defined for Rel 6 can be found in the end of this chapter
11 N-PDU Number
12 Next Extension Header Type
9. The GTPv1 frame II
Length (2 octets): These two octets indicate the length of the payload
8 7 6 5 4 3 2 1 (without GTP header) in octet. The first 8 octets of the GTP header are mandatory.
The length of the payload is counted from the 8 th octet onwards.
1 Version PT X E S PN
TEID (Tunnel Endpoint ID) (4 octets): The tunnel endpoint identifier of
2 Message Type the destination. TEIDs exist both for GTP-C and GTP-U protocol entities.
optional Sequence Number (2 octets): The sequence number is an optional field
3 in the G-PDU. If the sequence order for the payload that has to be transmitted in the
Length GTP-U tunnel has be be preserved, then a strictly increasing sequence numbering
4 has to be added in the header field Sequence Number For control message frames
(both GTP-C and GTP-U) the sequence number is used as a transaction identifier (in
5 other words: request and response have the same number).
Tunnel optional N-PDU Number (1 octet): The N-PDU number represents a sequence
6
Endpoint number for network protocol data units (e.g. IP datagrams for external network). The
Identifier number is used to coordinate data transmission in the acknowledged mode between
7
(TEID) the MS and the SGSN. It is used during inter-SGSN routing area updates and inter-
system handovers to support loss-less data transmission. In an inter-SGSN routing
8
area update, the SNDCP N-PDU number is transmitted in the N-PDU Number field.
9 optional Next Extension Header Type (1 octet): This field is used to indicate
Sequence Number which extension header follows after the standard header. Five Next Extension
10 Header field values have been defined so far:
•0000 0000’ indicates, that there is no extension header to follow.
11 N-PDU Number •0000 0001’ MBMS (MultiMedia Broadcast/Multicast Service) support indication
•1100 0000’ delivers a PDCP PDU number (UMTS use only).
12 Next Extension Header Type •1100 0001’ for a suspend request. For MS in Dual Transfer Mode (DTM)
•1100 0010’ for a suspend response.
10. Optional fields in the Header
GTP Optional header fields:
optional Sequence Number: This field is an optional field in G -PDUs. In the user plane, an increasing sequence
number for T-PDUs is transmitted via GTP-U tunnels, when transmission order must be preserved. For
signalling messages it is used as a transaction identity having a response message defined for a request
message, that is the Sequence Number value is copied from the request to the response message
header.
optional
N-PDU Number: This field is used at the Inter SGSN Routeing Area Update procedure and some inter-
system handover procedures (e.g. between 2G and 3G radio access networks). This field is used to co-
ordinate the data transmission for acknowledged mode of communication between the MS and the SGSN.
The exact meaning of this field depends upon the scenario. (For example, for GSM/GPRS to GSM/GPRS,
the SNDCP N-PDU number is present in this field).
optional
Next Extension Header Type: This field defines the type of Extension Header that follows this field in the
GTP‑PDU. If present the extension header has the following format:
8 7 6 5 4 3 2 1
Extension headers consist of three components: Extension Header Length (1
Extension Header Length octet), Extension Header Content (N*8-2 octets) and an Next Extension
Header Type field (1 octet).
Currently it is mainly used for 3G networks.
Extension Header Content
It allows future extensions of the GTP header, without the need to use
another version number for the GTP.
Next Extension Header Type
11. GTP header for the G-PDU
Version PT X E S PN – Version shall be set to decimal 1 ('001').
– Protocol Type flag (PT) shall be set to '1'.
0 0 1 1 0 0 0 0 – If the Sequence Number flag (S) is set to '1' the sequence number field is
present and meaningful, otherwise it is set to '0‘ (needed for in sequence
1 1 1 1 1 1 1 1 MT delivery of G-PDU). For GTP-U messages Echo Request, Echo Response,
Error Indication and Supported Extension Headers Notification, the S flag
shall be set to '1'.
Length
– The payload number (PN) may be set to 1. It is used during an Inter-SGSN
routing area update. The old SGSN informs the new SGSN about the N-
PDU number allocated to a T-PDU. Please note, that PN = 0 if
unacknowledged mode of operation is used in the LLC).
Tunnel – Message Type shall be set to the value 255 (11111111) when T-PDUs are
Endpoint transmitted.
Identifier – Length: This field indicates the length in octets of the payload, i.e. the rest
(TEID) of the packet following the mandatory part of the GTP header (that is the
first 8 octets). The Sequence Number, the N-PDU Number or any
Extension headers shall be considered to be part of the payload, i.e.
included in the length count.
– TEID: Contains the Tunnel Endpoint Identifier for the tunnel to which this
T-PDU belongs. The TEID shall be used by the receiving entity to find the
User Data Packet PDP context.
T-PDU
SGSN L2 IP UDP GTP IP Transfer of User Data:G-PDU GGSN
12. Chapter 5
GTP –the tunnel
5.3 GTP message groups
1. Message groups
2. Path Management Messages
3. Tunnel Management Messages
4. Location Management Messages
5. Defined Messages
13. Message groups
Path Management Messages
• Path Management messages:
are the Echo Request / Response messages and the message Version Not Supported. They are used to verify,
whether a path between GSN peer entities is still alive.
Tunnel Management Messages
• Tunnel Management messages:
are all messages, which are necessary to create and delete PDP Contexts and Network Initiated Contexts as well
as PDU notification to allow the transmission of an individual PDU.
optional
Location Management Messages
• Location Management messages:
The location management is optional and required only, when network requested PDP context activation is
supported and the GGSN supports no SS7 interface. Then GTP is used to transfer location management
messages to a GTP-MAP protocol converter. (not further discussed)
Mobility Management
• Mobility Management messages: Messages
Mobility Management messages are GTP-C messages, which are exchanged between SGSNs to perform an
Inter-SGSN routing area update and GPRS attach (with a new SGSN). In both cases, the new SGSN retrieves
information from the old SGSN, such as the IMSI. The old SGSN is identified via the old RAI, which is delivered
with the MS‘s request. Also the Identification Request / Response messages belong to this group.
MBMS Messages optional
• The MBMS (MultiMedia Broadcast/Multicast Service) messages
are control plane messages that are used in accordance with 3GPP TS 23.246. These are further categorised
into control plane messages related to UE specific MBMS signalling, and control plane messages related to
MBMS service specific signalling. (not further discussed)
14. Message groups
The Signalling Messages (any GTP-PDU except the G-PDU) of the GTP are divided into five groups:
Tunnel Management Messages Mobility Management Messages
Create PDP Context Request Identification Request
Create PDP Context Response Identification Response
Update PDP Context Request SGSN Context Request
Update PDP Context Response SGSN Context Response
Delete PDP Context Request SGSN Context Acknowledge
Delete PDP Context Response Forward Relocation Request
Error Indication Forward Relocation Complete
PDU Notification Request Relocation Cancel Request
3G only
PDU Notification Response Forward Relocation Complete Acknowledge
PDU Notification Reject Request Forward SRNS Context Acknowledge
PDU Notification Reject Response Forward SRNS Context
…..
Location Management Messages
Send Routeing Information for GPRS Request
Path Management Messages:
Send Routeing Information for GPRS Response
Echo Request
Failure Report Request
Echo Response
Failure Report Response
Version Not Supported
Note MS GPRS Present Request optional Supported Extension Headers Notification
Note MS GPRS Present Response
MBMS Messages Optional
MBMS Notification Request Rel 6
……
15. Path Management Messages
GSN Path Management Messages:
UDP/IP path
GSN Restart
GSN Echo Request
in use alive? Counter
Echo Response
Version Not Supported
Echo Request
Supported Extension Headers Notification
Echo Response all PDP contexts yes Recovery
( Recovery: on this path value
- GTP-C: restart counter changed?
are inactive
- GTP-U: 0 )
An Echo Request (ECHQ) message is send by any GSN to find out if the peer GSN is alive. It shall not be
send more often than 60 seconds on each path.
The answer to this ECHQ is the Echo Response (ECHR) message. The Echo Response contains a Recovery
number as mandatory IE. This Recovery number is used in case of a system restart to synchronize the
connected GSNs.
The Message Version Not Supported (VNS) is send if the entities use different GTP versions – as indicated in
the header of the messages. Two GTP versions currently exist. It may happen, that one network node supports
GTPv0 only, while its peer-entity supports GTPv1. A GTPv1 network elements is always backwards compatible,
i.e. it supports also GTPv0.
If a GSN wants to figure out, which version number is supported by a peer-GSN, it sends the message Version
Not Supported, which indicates the latest GTP version would be support by the other side on the used UDP/IP
path. This message is only used for GTP-C and GTP‘. It consists of the GTP header fields only.
Extension headers are allowed in GTP. If a GSN is internally marked as one which does not support all
extensions, and when it is required to interpret a mandatory header extension which it does not support, then it
must send to its peer GSN the list of extensions, it is capable to support. This is done with the message
Supported Extension Headers Notifications. This message is used for GTP-C and GTP-U.
16. Path Management Messages
Path Management Messages
GSN GSN
Version Not Supported
( )
mandatory
G-PDU
header extensions
( header extension: Y )
X: supported
Y: not supported
Z: supported
Supported Extension Headers Notification
( Extension Header Type List )
17. Error indication
There is only one GTP-U tunnel management message: Error Indication. Tunnel Management Messages
A GSN receives a G-PDU, for which no active PDP context exists. It retrieves the TEID from the retrieved G-
PDU. Then it creates the Error Indication message, adds the TEID and its GSN address, and sends the
message to its peer-GSN entity. The G-PDU is deleted.
If a GSN receives an Error Indication message, it deletes the PDP context. Especially, when an SGSN
receives an error indication from the GGSN, it also has to indicate this event to the MS. It sends the session
management message Deactivate PDP Context, including the cause „unknown PDP context“.
MS BSS SGSN GGSN
G-PDU
Error Indication
PDP Context Deactivation ( TEIDSGSN, GGSN Address )
( cause: unknown PDP context )
Deactivate PDP Context Accept
G-PDU
Error Indication
( TEIDGGSN, SGSN Address )
18. PDP context creation
GTP-C Tunnel Management Messages
Tunnel Management Messages
Create PDP Context Request
Create PDP Context Response
Update PDP Context Request With these messages PDP
Update PDP Context Response Contexts are created. All
Delete PDP Context Request signaling messages and all
Delete PDP Context Response user data that belong to the
PDU Notification Request same PDP Context have the
messages are only required,
PDU Notification Response same Tunnel ID (TID).
when mobile terminating
PDU Notification Reject Request
PDPs are supported
PDU Notification Reject Response
SGSN GGSN
Create PDP Context Request
To set up a Mobile Originated PDP Context the SGSN sends
( TEIDSGSN data, TEIDSGSN control plane,
a Create PDP Context Request (CPCQ) message.
This CPCQ message contains a Flow Label (FL), a Flow NSAPI, QoS profile, End user address,
Label Data (FLDatat) IE, a Flow Label Signaling (FLSign) IE, SGSN address for control plane
the MSISDN and Quality of Service (QoS) as requested by and for user traffic, TFT )
the MS.
After the PDP Context is created the FLData and FLSign of
the CPCQ are used to indicate all data or signaling traffic in Create PDP Context Response
downlink direction. ( TEIDGGSN data, TEIDCGSN control plane,
Furthermore the CPCQ message contains the Signaling and NSAPI, QoS profile, End user address,
User Traffic SGSN Address as mandatory parameter as well GGSN address for control plane
as the End User Address and the Access Point Name (APN). and for user traffic )
The Create PDP Context Response contains a Cause IE
that indicates whether the request was accepted or not.
19. PDP update / deletion
Tunnel Management Messages
SGSN GGSN
Update PDP Context Request
( TEIDSGSN data, TEIDSGSN control plane,
The GTP-C protocol provides the messages NSAPI, QoS profile,
Update PDP Context Request and Update SGSN address for control plane
PDP Context Response. These two and for user traffic )
messages enable the PDP context Update PDP Context Response
modification between SGSN and GGSN. A ( TEIDGGSN data, TEIDCGSN control plane,
GGSN and SGSN initiated PDP context
QoS profile,,
update is supported. Rel. 99 allows Update
GGSN address for control plane
PDP Context initiated by GGSN to change
and for user traffic )
QoS.
Between SGSN and GGSN the GTP-C Delete PDP Context Request
protocol allows the deactivation with the ( NSAPI, Teardown indicator )
messages Delete PDP Context Request
and Delete PDP Context Response. It can
be initiated by the GGSN and by the SGSN. Delete PDP Context Response
( cause )
20. Unsuccessful PDP Context Activation by the Network
Location Management Messages
Mobile terminated GPRS session establishment signalling is is covered by the GTP-C tunnelling protocol. MTC
may fail for many reasons. In the figure on the right hand side, we assume, that the GGSN is able to perform a
HLR interrogation. It receives the GSN address of the SGSN, which is currently serving the MS. The GGSN
sends a PDU Notification Request to the SGSN. A network originated PDP context activation is rejected, when
the MS is unknown, when it is GPRS detached, when no resources are available, etc. The response is
transmitted in the message PDU Notification Response.
If the network orientated PDP context activation is accepted by the SGSN:
1. The SGSN sends a PDU Notification Response message to the GGSN. The message includes the cause
„Request Accepted“. When a GGSN receives this message, it can already start to forward G-PDUs because it
has received the right IP address of the Serving SGSN.
2. The SGSN sends a PDP Context Activation request message to the MS. The MS is not responding to a GPRS
paging request, thus no response is returned to the SGSN. The MS may explicitly reject a network requested
PDP context activation. Then the message PDP Context Activation Reject is returned.
In both cases, the SGSN generates the message PDU Notification Reject Request. The cause for the reject
request is added, which is either „MS Not GPRS Responding“ or „MS Refuse“.
3. The GGSN notifies the reject request by returning the PDU Notification Reject Response message.
21. Unsuccessful PDP Context Activation by the Network
MS Location Management Messages
ISP
SGSN HLR GGSN
PDP PDU
Send Routing Info for GPRS
( IMSI)
Send Routing Info for GPRS Ack
( IMSI, SGSN address )
PDU Notification Request
( IMSI, TEIDGGSN control plane,
End user address, APN,
GGSN address for control plane)
PDU Notification Response
Activate PDP ( cause: Request Accepted )
Context Request
Activate PDP
Context Reject PDU Notification Reject Request
( cause: MS Refuse ) ( cause: MS Refuse or MS Not GPRS Responding)
PDU Notification Reject Response
22. Inter SGSN Routing Area update procedure
Before the RA change Mobility Management
After the RA change Messages
HLR HLR
GGSN GGSN
old MSC/VLR old SGSN new SGSN new MSC/VLR old MSC/VLR old SGSN new SGSN new MSC/VLR
Old new Old new
BSC BSC BSC BSC
LA1, RA1 LA2, RA2 LA1, RA1 LA2, RA2
MS MS
Path of the packets
MS initiates the procedure with a GMM Routeing Area Update Request sent to the new SGSN. Update
Type shall indicate RA update or periodic RA update.
The new SGSN sends SGSN Context Request to the old SGSN to get the MM and PDP contexts for
.
the MS. The new SGSN derives the old SGSN from the old RAI. If the old P ‑TMSI Signature was valid
or if the new SGSN indicates that it has authenticated the MS, the old SGSN stops assigning SNDCP
N‑PDU numbers to downlink N‑PDUs received, and responds with SGSN Context Response (MM
Context, PDP Contexts). The old SGSN stores New SGSN Address, to allow the old SGSN to forward
data packets to the new SGSN. The old SGSN starts a timer and stops the transmission of N-PDUs to
the MS
23. Inter SGSN Routing Area update procedure
MS BSS new SGSN old SGSN GGSN HLR
Routeing Area Update Request Mobility Management
1. SGSN Context Request Messages
2. SGSN Context Response
Security Functions may be performed Security Functions may be performed
3. SGSN Context Acknowledge
Mobility Management Messages:
SGSN Context Request 4. Forward Packets
SGSN Context SGSN Context Response 5. Update PDP Context Request
SGSN Context Acknowledge 6. Update PDP Context Response
Update PDP Context Request
Update Location
Update PDP Context Response
Cancel Location
Cancel Location Ack
Insert Subscriber Data
Insert Subscriber Data Ack
Update Location Ack
Routeing Area Update Accept
Routeing Area Update Complete
24. 5.4 Defined messages for GTP (Rel 6)
Message Message GTP-C GTP-U GTP'
Type value
0 For future use. Shall not be sent.
1 Echo Request X X x
2 Echo Response X X x
3 Version Not Supported X x
4 Node Alive Request X
5 Node Alive Response X
6 Redirection Request X
7 Redirection Response X
8-15 For future use. Shall not be sent.
16 Create PDP Context Request X
17 Create PDP Context Response X
18 Update PDP Context Request X
19 Update PDP Context Response X
20 Delete PDP Context Request X
21 Delete PDP Context Response X
22-25 For future use. Shall not be sent.
26 Error Indication X
27 PDU Notification Request X
28 PDU Notification Response X
25. Defined messages for GTP II
29 PDU Notification Reject Request X
30 PDU Notification Reject Response X
31 Supported Extension Headers Notification X X
32 Send Routeing Information for GPRS Request X
33 Send Routeing Information for GPRS Response X
34 Failure Report Request X
35 Failure Report Response X
36 Note MS GPRS Present Request X
37 Note MS GPRS Present Response X
38-47 For future use. Shall not be sent.
48 Identification Request X
49 Identification Response X
50 SGSN Context Request X
51 SGSN Context Response X
52 SGSN Context Acknowledge X
53 Forward Relocation Request X
54 Forward Relocation Response X
55 Forward Relocation Complete X
56 Relocation Cancel Request X
57 Relocation Cancel Response X
58 Forward SRNS Context X
59 Forward Relocation Complete Acknowledge X
60 Forward SRNS Context Acknowledge X
61-69 For future use. Shall not be sent.
70 RAN Information Relay X
26. Defined messages for GTP III
71-95 For future use. Shall not be sent.
96 MBMS Notification Request X
97 MBMS Notification Response X
98 MBMS Notification Reject Request X
99 MBMS Notification Reject Response X
100 Create MBMS Context Request X
101 Create MBMS Context Response X
102 Update MBMS Context Request X
103 Update MBMS Context Response X
104 Delete MBMS Context Request X
105 Delete MBMS Context Response X
106 - 111 For future use. Shall not be sent.
112 MBMS Registration Request X
113 MBMS Registration Response X
114 MBMS De-Registration Request X
115 MBMS De-Registration Response X
116 MBMS Session Start Request X
117 MBMS Session Start Response X
118 MBMS Session Stop Request X
119 MBMS Session Stop Response X
120 -239 For future use. Shall not be sent.
240 Data Record Transfer Request X
241 Data Record Transfer Response X
242-254 For future use. Shall not be sent.
255 G-PDU X
Editor's Notes
TS 23.060 chap. 9.2.2.2.2 Es gibt noch weitere fälle, die im falle einer failure eine Signallisierung zum HLR bedeuten.
The procedure begins when the MS detects a new RAI that is different to the one stored on the SIM. It sends a Routing Area Update Request to the new SGSN. 1. The new SGSN has to get the IMSI for this MS. Therefore the new SGSN translates the old RAI from the MS into the old SGSN IP address using a DNS. Then the new SGSN sends the GTP message SGSN Context Request to the old SGSN. This SGSN Context Request message contains the old RAI, TLLI, and new SGSN address. Important IEs: - Flow Label for downlink data and signalling - QoS as negotiated between MS and SGSN - SGSN address of the new(!) SGSN 2. The old SGSN transfers all GMM context and all data about active PDP contexts back to the new SGSN using the GTP message SGSN Context Response . 3. The new SGSN now gets the IMSI and authentication data from the GMM context and all information about all PDP contexts. Hence the new SGSN can perform authentication. When authentication is successful the new SGSN will send the GTP message SGSN Context Acknowledge to the old SGSN which triggers the old SGSN to forward buffered user packet data to the new SGSN. Concurrently with the last step the new SGSN contacts the GGSN for the active PDP context. It sends the GTP message Update PDP Context Request to the GGSN. This message holds the SGSN IP address and TEID. Additionally the new SGSN can set a new quality of service for the PDP context. The new QoS can be lower or higher than the QoS before the update. But the QoS will never exceed the QoS requested by the user. The GGSN acknowledges the GTP message with the Update PDP Context Response . Rel. 99 allows Update PDP Context initiated by GGSN to change QoS ! Following values may be updated: QoS negotiated, packet flow identifier, radio priority, PDP-address (when initiated by the GGSN), and TFT (when initiated by the MS).