Surprised nobody has yet written, "If you can't beat 'em, join 'em."
Instead of bitching about the users who are using dozens of GB per day, why not use that volume of data transfer to improve the network? All data transfer leaves traces, logs and metadata, which are designed to track for movement, track usage, and track signal development and availability. Instead of threatening termination, homicide, being drawn-and-quartered, arrested, tarred-and-feathered, or any other malady, all the bigwigs at TMO need to do is to dedicate a rack of servers to eat the metadata, hoping they will spit out a much better picture of their network from the field, from actual usage, randomized to a great extent (at least the extent that TMO does not know specifically which one of the 3000 people they sell new service today will wind up to be a data hog).
In reality, all of that happens already, both with provisioned devices (your smartphone) and mobile base stations and other tracking stations placed just so, geographically speaking. Your phone communicates with one or more towers regularly, even when you are not using it, and even when no data is flowing. Such is the nature of cellular coverage. The network must be able to track the movements of each device so it knows in which cell a device exists should there be data or voice bound for it. Your phone and the network of towers it's authorized to use, communicate back and forth telemetries about the connection, including deciding when, or if, to change frequencies within the same band (say, if one frequency is noisy while others are not), promote to a faster band (say, 3G to LTE), demote to a slower band, etc. Also, because your device is mobile, said back channel communication determines if there is a tower better able to hear the device, or possibly one that can't hear as well but isn't nearly as congested. Depending on the geography and population density, a 12-mile freeway drive at 80 mph could be a drive through as few as one cell, as many as 100. For someone using the device for a data session, there would be no indication whatsoever that there were switch(es) made to new cells along the way. For someone on a voice call, there would usually be no indication, although there can be a frame or two of scrambled bits while the data streams match up between two different towers and four frequencies (or more now, in case of YxY MIMO on LTE).
What I propose is the greater use and abuse of the telemetries and metadata that the volume users generate. All packetized data on all packetized networks have at least a source and a destination, and the latency from src. to dest. or dest. to src. can be measured through the network with extreme precision. A carrier might be most interested in learning how one of its towers becomes congested nightly, so the carrier's NOC might pull the usage details from the tower logs. They could see any number of things on the surface, such as who is using the most data, who is occupying frequencies and time slices most often, and if there is enough backhaul. If they crunch the metadata, which takes considerable processing power to generate the types of statistics we can use, they may find that the two data hogs in the cell live very close to the tower, and so their devices require less power and fewer timeslices to transfer a large volume of data than 100 devices whose owners live in the stix, and whose devices need full power Tx and orders of magnitude more timeslices for the SAME volume of data.
Cue the network engineers. This is where they come in. They can take the metadata, all crunched up and spit out, and superimpose it on their own field-generated data. They would then be able to detect any natural condition (geological, meterological, etc) that existed that might have caused congestion. They can even create a picture in 3D space and time, say from the POV of each of the towers, of every timeslice and every frequency grant, played back in real time.
So, at least in this fictitious setup here, what did the network engineers see? They saw one data hog, sitting next to a tower, sucking down 36 gigs of data in one hour, but he wasn't the cause of any sort of congestion, for he used only the same five frequencies for the whole hour, and there is more backhaul to that tower than can ever be saturated by one 2x2 LTE downlink. What they actually found was that six blocks over, three busloads of chatty Cathys debarked for a 3-hour odyssey including bathroom breaks and a meal.
The beauty of all of that lies in the answers T-Mobile and all the other carriers could learn about the real-world usage of their networks. We see promotions of it all the time, such as when Verizon sets up at the Super Bowl to meet the enormous data and voice demands of the 100k attendees. That's an excellent test of a network's capabilities, but it's only half-randomized. Run that same data gathering mechanism over an entire network, and there will be enough data for NetEng types to pore through until hell freezes over, and since T-mobile has no idea where their customers will take and use their devices, nor how much, nor when, it's the perfect randomized set of data.
Of course, in the coporate world, T-Mobile will spend $100 million and three years thinking about how to accomplish all that, so there must be a better solution than the one that will generate the most value.
Oh, I've got that, too. Except, to implement this suggestion, TMO will have to spend zero dollars and just flip a switch in software. They've pretty much already done that to the extent that if you go over your "unlimited" cap, they throttle your connection to 64-112 kbps. Instead of hard caps, they could just as easily get away with QoS priorities. Assign a QoS priority on the network end, and nothing a user or device could do would be able to change that QoS priority. Start each billing cycle at 100 (highest priority), and then decrement that priority by one for each GB used, with the caveat that the priority shall stay at 100 if users who pay for 21 GB only use their 21 GB. For such a user, using that 22nd GB would drop his device's QoS priority by 22 points, to 78.
So what would the 78 represent? Not 78% of promised transfer speed. Not 78% of the usual number of timeslices. In fact, the 78 by itself represents nothing at all. When compared to a user still at 100, though, the 78 will have 22% fewer airtime grants, which COULD result in 22% less transfer speed, or it could result in no difference at all, depending on how those with higher QoS priorities are using the network. What if the user has used 500 GB that month? His QoS priority would be 1, which means that everyone else using that tower has a higher priority, but again if they are using only 20% of the resources and bandwidth, there's no issue at all in delivering the data hog what he wants.
That's the bottom line. Either use the tools your network gives you to make more informed choices about where to spend network dollars, or set up a Quality of Service system that does not prevent the data hog from being a data hog, rather it prevents him from doing so when others are using the network. Face it T-Mo. You built, bought and stole your network so that you could make it fast and all-encompassing. It seems to me that your data hogs should be your biggest promoters of your service, not your biggest scourge.
Facebook
Twitter
Instagram