GTP message Types.

Here I am going deeper inside the 3GPP TS 29.060

GTP Message Types:

Tunnel management messages:
















-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
-PDU Notification Reject Request
-PDU Notification Reject Response
-Initiate PDP Context Activation Request
-Initiate PDP Context Activation Response



Path Management Messages:








-Echo Request
-Echo Response
-Version Not Supported
-Supported Extension Headers Notification



Location Management Messages:




 



-Send Routeing Information for GPRS Request
-Send Routeing Information for GPRS Response
-Failure Report Request
-Failure Report Response
-Note MS GPRS Present Request
-Note MS GPRS Present Response


Mobility Management Messages:

-Identification Request
-Identification Response
-SGSN Context Request
-SGSN Context Response
-SGSN Context Acknowledge
-Forward Relocation Request
-Forward Relocation Response
-Forward Relocation Complete
-Relocation Cancel Request
-Relocation Cancel Response
-Forward Relocation Complete Acknowledge
-Forward SRNS Context
-Forward SRNS Context Acknowledge
-RAN Information Management Messages
-RAN Information Relay


Multimedia Broadcast Multicast Service (MBMS) messages:

1. UE Specific MBMS Messages:

-MBMS Notification Request 
-MBMS Notification Response 
-MBMS Notification Reject Request
-MBMS Notification Reject Response
-Create MBMS Context Request
-Create MBMS Context Response
-Update MBMS Context Request
-Update MBMS Context Response
-Delete MBMS Context Request
-Delete MBMS Context Response

2. Service Specific MBMS Messages:

-MBMS Registration Request

-MBMS Registration Response
-MBMS De-registration Request
-MBMS De-Registration Response
-MBMS Session Start Request
-MBMS Session Start Response
-MBMS Session Stop Request
-MBMS Session Stop Response
-MBMS Session Update Request
-MBMS Session Update Response

Explanation for each of the messages started from next post!

Direct Tunneling Vs Gateway offloading

The Next Generation Mobile Equipment will be very Bandwidth intensive and always hungry due to high demand of Video/voice and triple play services on the move. According to one report a single smart-phone traffic uses requirement is apporx 25-30 times higher than the simple GSM phones!

Due to this increased traffic demands, the Mobile networks and Gateways are being flooded and customers are getting unsatisfactory services.
So whats the solution there,

1. Keep increasing the Gateway hardwares to build up the network infrastructure to the next level.
2. Using the optimization methods, such as Direct tunneling and Gateway offloading.

Purchasing the huge number of network hardwares (GWs) to reach the hardware level infrastructure is really not the solution at all, It will eat up millions of dollars for Network service providers and even not complete, on increasing the number of subscriber it will need the same amount of maintains cost continiously!

So whats next!

Direct Tunneling and Offloading.

Direct Tunneling: The direct tunnel feature enables an SGSN to establish a direct user plane tunnel between the radio network controller (RNC) and a GGSN.
The SGSN functions as the gateway between the RNC and the core network. It handles both
signaling traffic (to keep track of the location of mobile devices), and the actual data packets being
exchanged between a mobile device and the Internet.

Snapshot from 3GPP TR 23.919 version 7

So what actually we are doing with the Direct tunnel, we are bypassing the SGSN to reduce the latency and freeing the SGSN from heavy traffic loads.

Now again here is one question? Does this really solve our problem?, I think a bit but not completely, because when the packtes are reaching directly to the GGSN from lots of RNC simultaneously, its again creating the chaos on the GGSN interfaces.

Then network optimization reached to another level where the SGSN and GGSN are thought to be only for the GTP signaling and PCRF and no data traffic will come up from the GGSN.

This New advancement is the SGSN and GGSN offloading.
In this technique a Offload gateway is been placed in the middle of the RNC and SGSN.
Once the PDP context is activated fromt he GGSN, all the Data traffic will follow from the Offload Gateway!

 So both the RNC and Offload Gateway will talk using the Iu-PS interface and SGSN and GGSN will never be loaded due to data traffic.

I really dont have idea about the security vulnerability in this condition and I suspect its really a security issue in this case because we are just allowing the IP packets without the GTP header to the Internet Core from the radio interface.


Waiting for your comments and suggestions!