Chap05 gtp 03_kh

Chapter 5

GTP – the tunnelContents:5.1 GTP interfaces

1. Protocols for Combined Procedures2. GTP interfaces3. Control and User plane 4. Tunnel Endpoint Identifier 5. GTP and UDP

5.2 Message formats1. The GTPv1 frame2. Optional fields in the Header 3. GTP header for the G-PDU Example

5.3 GTP message groups1. Message groups2. Path Management Messages 3. Tunnel Management Messages 4. Location Management Messages5. Mobility Management Messages

5.4 GTP messages

Chapter 5

GTP –the tunnel5.1 GTP interfaces

1. Protocols for Combined Procedures2. GTP interfaces3. Control and User plane 4. Tunnel Endpoint Identifier 5. GTP and UDP

GTP interfaces

SGSNGn

L1

L2 L2

IP IP

UDP /TCP

UDP /TCP

GTP GTP

L1

GGSNGn

SGSN

L1

L2

IP

UDP /TCP

GTP

SGSN

L1

L2

IP

UDP /TCP

GTP

Gp

In the 2nd generation mobile communication network GSM/GPRS, the GPRS Tunnelling Protocol (GTP) is used between the GPRS Support Nodes (GSN) and for 3rd 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).

versions of GTP:

Another PLMN

GTP version 0GSM 09.60

GTP version 13GPP TS 29.060

There are important changes from GTP Release 98 to GTP Release 99. The main reason is that GTP shall also be used in the backbone of UMTS networks(Gn, Gp and Iu interfaces). To meet this requirement some additional messages for SGSN Relocation procedure have been defined.

Furthermore some Information Elements have changed in Release 99. The most significant change in IEs is that a so-called Tunnel Endpoint Identifier (TEID) substitutes the Tunnel ID (TID) and the Flow Labels. Anonymous PDP Contexts in Release 98 are not specified any longer in Release 99

Control and User plane

IPvX

L1

UDP

GTPv1

L2

Gn/GpGSN

IPvX

L1

UDP

GTPv1

L2

GTP-C

GTP-U

GTP-PDU: A GTP Protocol Data Unit is either a control plane (GTP-C) message or a user plane (GTP-U) message.

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 PDP context. The user plane messages are used to carry user data packets and signalling messages for path management and error 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.

UDP/IP is the only path protocol defined to transfer GTP messages in the version 1 of GTP. A User Datagram Protocol (UDP) compliant with RFC 768 shall be used.

GSN

Tunnelling mechanism for transfer of user packet data

• Tunnel control• Management protocol

In Rel 99only UDP

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.

individualPDP Contexts:

PDPPDP

GTP

UDPIP

PDPPDP

TEIDGSN,control

TEIDGSN,user

GTP-C

GTP-U PDP

PDPPDP

GTPUDP

IP

PDPPDP

GTP and UDP

GSN

PDPPDP

individualPDP Contexts:

TEIDGSN,control

TEIDGSN,user

GTP

RequestResponse

Source Port Dest. Port? 2123

UDP

IP

GTP-C

2123 ?

RequestResponse

Source Port Dest. Port? 2152

GTP-U

2152 ?

PDPPDP

PDP

PDPPDP

GTP

UDP

IP

PDPPDP

GSN

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-pointsAn 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.

Chapter 5

GTP –the tunnel5.2 Message formats

1. The GTPv1 frame2. Optional fields in the Header 3. GTP header for the G-PDU Example

The GTPv1 frame I

Message Types defined for Rel 6 can be found in the end of this chapter

8 456 23 1

Message Type

Version PT X E S PN1

2

7

The GTPv1 frame contains the following elements. version (3 bits): The version field indicates the differentiates between different GTP versions. GTP version 1 = binary value ‘001’.

PT (Protocol Type) (1 bit): The protocol type indicates GTP (PT = 1) or GTP' (PT = 0).

X is a spare bit. It shall be sent as '0'

E (Extension Header Flag) (1 bit): This bit indicates whether the octet 12 of the header shall be evaluated (E=1) or not (E=0)

S (Sequence Number Flag) (1 bit): This bit indicates whether the octets 9 and 10 shall be evaluated (S=1) or not (S=0).

PN (N-PDU Number Flag) (1 bit): This bit indicates whether the octet 11 shall be evaluated (PN = 1) or not (PN = 0).

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 Echo Request. But most of the messages are used by a single GTP protocol entity. For instance, the Create PDP Context Request is only a GTP-C protocol entity message.

Length

TunnelEndpointIdentifier(TEID)

Sequence Number

N-PDU Number

Next Extension Header Type

4

5

3

6

9

10

7

8

12

11

The GTPv1 frame II

8 456 23 1

Message Type

Version PT X E S PN

Length


Sequence Number

N-PDU Number


1

4

5

2

3

6

9

10

7

8

12

11

7Length (2 octets): These two octets indicate the length of the payload

(without GTP header) in octet. The first 8 octets of the GTP header are mandatory. The length of the payload is counted from the 8th octet onwards.

TEID (Tunnel Endpoint ID) (4 octets): The tunnel endpoint identifier of the destination. TEIDs exist both for GTP-C and GTP-U protocol entities.

Sequence Number (2 octets): The sequence number is an optional field in the G-PDU. If the sequence order for the payload that has to be transmitted in the GTP-U tunnel has be be preserved, then a strictly increasing sequence numbering 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 other words: request and response have the same number).

N-PDU Number (1 octet): The N-PDU number represents a sequence number for network protocol data units (e.g. IP datagrams for external network). The number is used to coordinate data transmission in the acknowledged mode between 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 area update, the SNDCP N-PDU number is transmitted in the N-PDU Number field.

Next Extension Header Type (1 octet): This field is used to indicate which extension header follows after the standard header. Five Next Extension Header field values have been defined so far:

•0000 0000’ indicates, that there is no extension header to follow. •0000 0001’ MBMS (MultiMedia Broadcast/Multicast Service) support indication•1100 0000’ delivers a PDCP PDU number (UMTS use only).•1100 0001’ for a suspend request.•1100 0010’ for a suspend response.

For MS in Dual Transfer Mode (DTM)

optional

optional

optional

Optional fields in the Header

8 7 456 23 1

Extension Header Content

Extension Header Length


Extension headers consist of three components: Extension Header Length (1 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.

It allows future extensions of the GTP header, without the need to use another version number for the GTP.

GTP Optional header fields:

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.

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).

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:

optional

optional

optional

GTP header for the G-PDU

1 1 1 1 1 1 1 1

0 0 1 1 0 0 0 0

Length


– Version shall be set to decimal 1 ('001').– Protocol Type flag (PT) shall be set to '1'.– 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 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'.

– 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).

– Message Type shall be set to the value 255 (11111111) when T-PDUs are transmitted.

– Length: This field indicates the length in octets of the payload, i.e. the rest 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 PDP context.User Data Packet

T-PDU

SGSN GGSN Transfer of User Data:G-PDU

Version PT X E S PN

MT

IPGTPIP UDPL2

Chapter 5

GTP –the tunnel5.3 GTP message groups

1. Message groups2. Path Management Messages 3. Tunnel Management Messages 4. Location Management Messages5. Defined Messages

Message groups

• 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: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.

• 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 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.

• 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)

Path Management Messages

Tunnel Management Messages

Location Management Messages

Mobility Management Messages

MBMS Messagesoptional

optional

Message groups

The Signalling Messages (any GTP-PDU except the G-PDU) of the GTP are divided into five groups:

Path Management Messages:Echo RequestEcho ResponseVersion Not SupportedSupported Extension Headers Notification

Location Management MessagesSend Routeing Information for GPRS RequestSend Routeing Information for GPRS ResponseFailure Report RequestFailure Report ResponseNote MS GPRS Present RequestNote MS GPRS Present Response

Tunnel Management MessagesCreate PDP Context RequestCreate PDP Context ResponseUpdate PDP Context RequestUpdate PDP Context ResponseDelete PDP Context RequestDelete PDP Context ResponseError IndicationPDU Notification RequestPDU Notification ResponsePDU Notification Reject RequestPDU Notification Reject Response

Mobility Management MessagesIdentification RequestIdentification ResponseSGSN Context RequestSGSN Context ResponseSGSN Context AcknowledgeForward Relocation RequestForward Relocation CompleteRelocation Cancel RequestForward Relocation Complete AcknowledgeForward SRNS Context AcknowledgeForward SRNS Context…..

MBMS MessagesMBMS Notification Request ……

OptionalRel 6

optional

3G only


Path Management Messages:Echo RequestEcho ResponseVersion Not SupportedSupported Extension Headers Notification

RestartCounter

GSNGSN

( Recovery: - GTP-C: restart counter- GTP-U: 0 )

Echo Request

UDP/IP path in use alive?

Echo Response Recoveryvalue

changed?

yesall PDP contexts on this path are inactive

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.

GSN


GSN GSN

( header extension: Y )

Version Not Supported

G-PDUmandatory header extensionsX: supportedY: not supportedZ: supported

Supported Extension Headers Notification( Extension Header Type List )

( )


Error indication

Error Indication( TEIDSGSN, GGSN Address )

G-PDU

PDP Context Deactivation( cause: unknown PDP context )

Deactivate PDP Context Accept

Error Indication( TEIDGGSN, SGSN Address )

G-PDU

There is only one GTP-U tunnel management message: Error Indication.

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


PDP context creation

Tunnel Management MessagesGTP-C Tunnel Management MessagesCreate PDP Context RequestCreate PDP Context ResponseUpdate PDP Context RequestUpdate PDP Context ResponseDelete PDP Context RequestDelete PDP Context ResponsePDU Notification RequestPDU Notification ResponsePDU Notification Reject RequestPDU Notification Reject Response

messages are only required, when mobile terminating PDPs are supported

To set up a Mobile Originated PDP Context the SGSN sends a Create PDP Context Request (CPCQ) message. This CPCQ message contains a Flow Label (FL), a Flow Label Data (FLDatat) IE, a Flow Label Signaling (FLSign) IE, the MSISDN and Quality of Service (QoS) as requested by 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 downlink direction. Furthermore the CPCQ message contains the Signaling and User Traffic SGSN Address as mandatory parameter as well as the End User Address and the Access Point Name (APN). The Create PDP Context Response contains a Cause IE that indicates whether the request was accepted or not.

With these messages PDP Contexts are created. All signaling messages and all user data that belong to the same PDP Context have the same Tunnel ID (TID).

Create PDP Context Request( TEIDSGSN data, TEIDSGSN control plane, NSAPI, QoS profile, End user address,

SGSN address for control plane and for user traffic, TFT )

Create PDP Context Response( TEIDGGSN data, TEIDCGSN control plane, NSAPI, QoS profile, End user address,

GGSN address for control plane and for user traffic )

SGSN GGSN

PDP update / deletion

Update PDP Context Request( TEIDSGSN data, TEIDSGSN control plane,

NSAPI, QoS profile, SGSN address for control plane

and for user traffic ) Update PDP Context Response( TEIDGGSN data, TEIDCGSN control plane,

QoS profile,, GGSN address for control plane

and for user traffic )

SGSN GGSN

The GTP-C protocol provides the messages Update PDP Context Request and Update PDP Context Response. These two messages enable the PDP context modification between SGSN and GGSN. A GGSN and SGSN initiated PDP context update is supported. Rel. 99 allows Update PDP Context initiated by GGSN to change QoS.

Delete PDP Context Request( NSAPI, Teardown indicator )

Delete PDP Context Response( cause )

Between SGSN and GGSN the GTP-C protocol allows the deactivation with the messages Delete PDP Context Request and Delete PDP Context Response. It can be initiated by the GGSN and by the SGSN.


Unsuccessful PDP Context Activation by the Network

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.


Unsuccessful PDP Context Activation by the Network

Activate PDP Context Request

SGSNMS

GGSN

PDU Notification Request

( IMSI, SGSN address )

PDU Notification Response

( IMSI, TEIDGGSN control plane, End user address, APN,

GGSN address for control plane)

ISPHLR

PDP PDUSend Routing Info for GPRS

Send Routing Info for GPRS Ack( IMSI)

( cause: Request Accepted )

Activate PDP Context Reject( cause: MS Refuse )

PDU Notification Reject Request( cause: MS Refuse or MS Not GPRS Responding)

PDU Notification Reject Response


Inter SGSN Routing Area update procedure

LA1, RA1

old SGSN

LA2, RA2

Old BSC

old MSC/VLR

MS

new BSC

HLR

GGSN

new SGSN new MSC/VLR

LA1, RA1

old SGSN

LA2, RA2

Old BSC

old MSC/VLR

MS

new BSC

HLR

GGSN

new SGSN new MSC/VLRnew SGSN

Before the RA change After the RA change

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


Inter SGSN Routing Area update procedureMS BSS new SGSN HLRGGSNold SGSN

2. SGSN Context ResponseSecurity Functions may be performed

Routeing Area Update Request 1. SGSN Context Request

5. Update PDP Context Request 6. Update PDP Context Response Update Location

Update Location Ack

Routeing Area Update Accept

Cancel Location Cancel Location Ack

Insert Subscriber Data Ack Insert Subscriber Data

Routeing Area Update Complete

4. Forward Packets

3. SGSN Context Acknowledge

Mobility Management Messages:SGSN Context RequestSGSN Context SGSN Context ResponseSGSN Context AcknowledgeUpdate PDP Context RequestUpdate PDP Context Response

Security Functions may be performed


5.4 Defined messages for GTP (Rel 6)

Message Type value

0

1

2

3

4

5

6

7

8-15

16

17

18

19

20

21

22-25

26

27

28

Message

For future use. Shall not be sent.

Echo Request

Echo Response

Version Not Supported

Node Alive Request

Node Alive Response

Redirection Request

Redirection Response


Create PDP Context Request

Create PDP Context Response

Update PDP Context Request

Update PDP Context Response

Delete PDP Context Request

Delete PDP Context Response


Error Indication

PDU Notification Request

PDU Notification Response

GTP-C GTP-U GTP'

X X x

X X x

X x

X

X

X

X

X

X

X

X

X

X

X

X

X

Defined messages for GTP II

293031323334353637

38-47

48495051525354555657585960

61-69

70

PDU Notification Reject RequestPDU Notification Reject ResponseSupported Extension Headers NotificationSend Routeing Information for GPRS RequestSend Routeing Information for GPRS ResponseFailure Report RequestFailure Report ResponseNote MS GPRS Present RequestNote MS GPRS Present ResponseFor future use. Shall not be sent.

Identification RequestIdentification ResponseSGSN Context RequestSGSN Context ResponseSGSN Context AcknowledgeForward Relocation RequestForward Relocation ResponseForward Relocation CompleteRelocation Cancel RequestRelocation Cancel ResponseForward SRNS ContextForward Relocation Complete AcknowledgeForward SRNS Context AcknowledgeFor future use. Shall not be sent.

RAN Information Relay

X X X X X X X X X X

X X X X X X X X X X X X X

X

Defined messages for GTP III

71-95

96979899100101102103104105

106 - 111

112113114115116117118119

120 -239

240

241

242-254

255


MBMS Notification RequestMBMS Notification ResponseMBMS Notification Reject RequestMBMS Notification Reject ResponseCreate MBMS Context RequestCreate MBMS Context ResponseUpdate MBMS Context RequestUpdate MBMS Context ResponseDelete MBMS Context RequestDelete MBMS Context ResponseFor future use. Shall not be sent.

MBMS Registration RequestMBMS Registration ResponseMBMS De-Registration RequestMBMS De-Registration ResponseMBMS Session Start RequestMBMS Session Start ResponseMBMS Session Stop RequestMBMS Session Stop ResponseFor future use. Shall not be sent.

Data Record Transfer Request

Data Record Transfer Response


G-PDU

X X X X X X X X X X

X X X X X X X X

X

X

X

Chap05 gtp 03_kh

Documents