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?