A simple software fix could limit location data sharing

Yes, in a perfect world, they would simply choose to not track. We (I'm a co-author on the research) chose to change things such that we don't need to rely on carrier benevolence.

Our fix changes the architecture to nullify an identity that has long been used to track users. The data has simply been available for them to sell as a byproduct of running a network.

You're right: the big carriers don't have much incentive to deploy this -- yet. We think deployment will come through three paths: 1) virtual operators (MVNOs) can differentiate themselves by offering PGPP-based privacy-enhanced service, 2) big carriers (MNOs) will want to (eventually) claim that they are doing the right thing on privacy and jump on board, and 3) new regulations (in various U.S. states and post-GDPR rules that are being drafted) are stipulating that location data is private so it's better to not have it rather than have to prove that it's being handled properly.

Better GDPR enforcement would be an incentive.

The GDPR introduces the principle of data minimisation which means that you must collect the least amount of data possible to deliver a particular service (unless the user consents to sharing more which should be opt-in, you can’t force them or use dark patterns to make them opt-in).

But considering even basic violations that are trivial to rectify such as the Facebook SDK or Google Analytics being everywhere are not punished, there is no chance they’d go after cell carriers.

The regular attach procedure is unchanged. In the simplest version we give every SIM the identical IMSI and key.

However, their use is to only gain IP connectivity - the equivalent of an allow list on the backend db (AUSF) which gives you IP connectivity. At that point you do billing and auth at the PGPP-GW using oblivious auth tokens.

Additional question for my understanding - this needs an app running in the background to send the signed token at every other time interval, correct?

First of all, congratulations, when you get Bruce Schneier to endorse your work, you have probably done something interesting.

But still the article is not very clear on technical details. Of course on initial contacts your phone has to provide information about your service provider (they will somehow have to pay for your communications) and it has also has to have some form of identification about your phone (so that the service provider can decide if they want to pay for it). If I understand it correctly, normally this identification is the IMSI, which is normally constant for your phone. From the article it is not clear if you are proposing to generate multiple IMSI's for a phone or using other types of information in the protocols.

Do you have some links to a more technical explanation of PGPP?

If you're interested in security protocols, I'd recommend Bruce Schneier's book Cryptography Engineering (and Ross Anderson's Security Engineering). If general networking protocols, there are many options -- Kurose, Peterson and Davie, Tanenbaum, etc.