Visitor Location Register: LAC and Cell_ID data - is the history of their changes stored and where?

Question

mobile connection

Good day to all.
1) Interested in whether mobile operators (MTS - Beeline - Megafon - Tele2) have the technical ability to provide historical data from VLR.
In particular, we are interested in the history of LAC and Cell_ID changes by subscribers for a certain date and a certain time interval within a given set of LACs and Cell_IDs.
2) If the subscriber's mobile station was turned on, but moved between different Cell_IDs within the same LAC without calls and SMS, are marks written for such a mobile station in the history? Or in VLR it will be static, because LAC doesn't change?

Answer 1

1. I would advise you to address this issue to the corporate client departments of the operators themselves. And I would have prepared a bag of money. And I would speak in a whisper so that no one would overhear)
By the way, a separate issue is personal data. I assume that historical information will be given either by numbers recorded directly on you, or with some anonymous subscriber identifiers instead of numbers.
2. Now for the technology.
Firstly, if the subscriber is in Idle (the subscriber radio channel is dismantled to save network capacity and subscriber battery), his location is known up to LAC (GSM, CDMA) or TAC (LTE).
Yes, the Cell-ID of its last activity is known, but there is no guarantee that during this time the subscriber has not fled to another cell within the LAC / TAC.
It turns out that when the subscriber is in Idle, then, as you wrote, his location is specified at the moment:
- Location Update when changing LAC / TAC
- Periodic Location Update
- Explicit Detach
When the subscriber is in the Connected state (the conversation is in progress or has just ended or data transmission), its location is known to within a cell.
By the way, I would pull historical data not from VLR, but from billing: all records in CDR (Call Detail Records) are written with CGI / E-CGI.

Answer 2

I'm not special, but on the first question, do they store the details? The zone and cell are also probably stored, but no one will probably ever give it to you. According to the second, it is about the alarm that you need to read theirs, because if the device did not turn off, then it needs to somehow know which nearest / working BS to knock on.

Answer 3

Regarding the information about the Cell_ID of the subscriber, what I managed to find out on my own from many articles (I ask the experts to correct if something is wrong):
When the device is in standby mode, then report your "location" (in quotes, because the location is meant inside the network, and not on the ground) in a regular way, it can only be done through the Location Update procedure. It is launched by the device in the following cases:
- registration of a subscriber in the network
- change of LAC (namely LAC, not Cell_ID within the same LAC)
- forcibly, in accordance with the value of timer T3212, the value of which is dictated by the network and stored in the subscriber's SIM.
- turning off the device in a regular way, i.e. not by removing the battery, namely through the regular "off"; in this case, the device tells the network "the subscriber is dead in such and such a Location Area"
When the Location Update procedure is performed, the current LAC of the subscriber and the flag that the subscriber is dead are written to the VLR.
Those. VLR, as far as I understand, stores the "location" of the subscriber up to LAC, tk. It does not need Cell_ID due to the fact that paging when calling a subscriber is carried out for all base stations within the Location Area specified in the subscriber's record in the VLR, and not for a specific base station or cell.
Thus, in the standby mode, if the Cell_ID value is transmitted as part of the Location Update, then only as auxiliary information, and can be recorded somewhere in the logs (after all, this procedure was carried out through some base station).
As a result, a picture of the subscriber's movement with an accuracy of up to a cell, if it can be obtained, is only in the case when the Location Update procedure was often twitching.
However, questions about storing Cell_ID and the history of changes in VLR records, as well as storing logs of the Location Update procedure and the presence of Cell_ID in these logs, remain open until a response from experts is received.

Answer 4

Let me add to the heap. Stored or not - it's up to the operator. It was correctly pointed out here that the detailing of calls and other activity (with an indication of the cell ID) is more billing, since subscriber activity is logged directly, rather than tracking. It is clear that the VLR itself does not store history for reporting (this is not its business), and MSC generates various kinds of CDR / XDR for billing (for simplicity, we consider only CS).
But tracking depends on the operator. As a rule, partner companies provide analytics services for which data is collected by passively listening to signal traffic. It's called Probes Services. The essence of the service is to copy the signaling traffic without being introduced into the routing of the call switching process - i.e. the signaling traffic itself is not interrupted, but is passively listened to by a third-party system that keeps the history of the subscriber by extracting useful data from it.
This service is directly related to the concept of the so-called. Big Data, since the availability of such data (trends) allows, firstly, to draw conclusions about the routes of subscribers, concentration, and secondly, to provide such data to third parties (including special services). All this actually exists and works.