During my time working at mobile operators I’ve often been asked if it’s possible to differentiate regular on-device web browsing from tethered data traffic.
Tethering refers to the practice of sharing your mobile phone’s cellular data connection with external devices connected by Bluetooth or a serial cable. For example, you might activate tethering on an iPhone and use your mobile data on a connected laptop.
Smartphones generally do a very good job of providing transparent tethered data to connected devices (and hiding these from the network!), so it’s not usually possible for the mobile operator to easily identify tethered traffic.
You could perhaps use deep-packet inspection to search out user-agent headers, but this method is not reliable and not scaleable.
When I first started looking into this problem, I came up with the idea of getting the mobile device to make a clear distinction between on-device and tethered data consumption. The ideal identifier to use for this task is the Network Service Access Point Identifier – or NSAPI.
When an application requests a data bearer, the mobile device sends a PDP context activation request to the radio network.
Contained within the PDP context activation request is the NSAPI value. The NSAPI identifies a PDP context within the mobile device and the SGSN. This is necessary because a device may have multiple PDP contexts and application endpoints.
The mobile device usually allocates NSAPI 5 to the first PDP context. The reason for this is that according to the design specs (3GPP TS 24.008), the first five NSAPI values are reserved.
My proposal is to use the previously reserved NSAPI values (0-4) to identify an endpoint that is terminated on an external tethered device.
By using these reserved values the SGSN can distinguish between on-device data and tethered connections. This could be used to apply different network quality of service parameters or even differential billing.
I first proposed this solution in 2002, but it’s going to take widespread industry adoption to make it happen, particularly from the mobile device vendors. But with LTE just around the corner, perhaps this solution is too late?
WebDiary.com 
What i understand from above process is to block the tethered user, which is not my case. We want to modify the charging and throttle limits for user using PCRF. The time GGSN start dpi packets is already in standard TCP/IP stack rather than GTP which make this process useless as NSAPI is not included in TCP/IP stack.
Not exactly. The method (if adopted globally) would allow operators to identify tethered connections and tag those IP packets accordingly, so you would be able to adopt differential pricing or make other policy based decisions.
Why you thought, secondary PDP needed for tethering support? Simply TTL calculation do this job well. If MS or MSOS vendors make possible TTL modification(to prevent tethering detecting by this method), why they should implement secondary PDP activation for tethering itself?
In any way, tethering differentiation a worst case in telco service model.