Visitor Location Register: данные LAC и Cell_ID — хранится ли история их изменений и где?

1. Я бы посоветовал обратиться с этим вопросом в отделы по работе с корпоративными клиентами самих операторов. И мешок денег приготовил бы. И говорил бы шопотом, чтобы не подслушал никто )
Кстати, отдельный вопрос - персональные данные. Предполагаю, что историческую информацию отдадут либо по номерам, записанным непосредственно на Вас, либо с некими анонимными абонентскими идентификаторами вместо номеров.

2. Теперь по технологии.
Во-первых, если абонент находится в Idle (абонентский радиоканал разобран для экономии ёмкости сети и абонентского аккумулятора), его местонахождение известно с точностью до LAC (GSM, CDMA) или TAC (LTE).
Да, известен Cell-ID его последней активности, но нет никаких гарантий, что за это время абонент не убежал на другую соту в пределах LAC/TAC.
Получается, когда абонент в Idle, то, как Вы и написали, его местонахождение уточняется в момент:
- Location Update при смене LAC/TAC
- Periodic Location Update
- Explicit Detach

Когда же абонент находится в состоянии Connected (идёт или только-только закончился разговор либо передача данных), его местонахождение с точностью до соты известно.
Кстати, я исторические данные вытягивал бы не из VLR, а из биллинга: все записи, что в CDR (Call Detail Records), пишутся с указанием CGI/E-CGI.

Я не спец, но по первому вопросу хранят же они детализацию? Зона и сота тоже наверняка хранятся, но ее вам никто и никогда не даст наверное. По второму, это про сигнализацию надо почитать ихнюю, ведь если аппарат не выключался, то ему надо как-то знать к какой ближайшей/рабочей БС стучаться.

Касательно информации о Cell_ID абонента, что удалось выяснить самостоятельно из множества статей (прошу экспертов поправить, если что не так):

Когда аппарат находится в режиме ожидания, то сообщить о своём "местонахождении" (в кавычках, т.к. имеется в виду местонахождение внутри сети, а не на местности) штатным образом он может только путём процедуры Location Update. Она запускается аппаратом в случаях:
- регистрация абонента в сети
- смена LAC (именно LAC, а не Cell_ID внутри той же LAC)
- принудительно, в соответствии со значением таймера T3212, значение которого диктуется сетью и сохраняется в SIM абонента.
- выключении аппарата штатным образом, т.е. не выниманием батарейки, а именно через штатное "выкл"; в этом случае аппарат говорит сети "абонент потух в такой-то Location Area"
При выполнении процедуры Location Update в VLR записывается текущий LAC абонента и флаг, что абонент потух.

Т.е. VLR, насколько я понял, хранит "местонахождение" абонента с точностью до LAC, т.к. Cell_ID ему не нужна ввиду того, что пэйджинг при вызове абонента осуществляется по всем базовым станциям в рамках Location Area, указанной в записи абонента в VLR, а не по конкретной базовой станции или соте.
Таким образом, в режиме ожидания, значение Cell_ID если и передаётся в рамках Location Update, то только в качестве вспомогательной информации, и может фиксироваться где-то в логах (ведь данная процедура осуществлялась посредством некоторой базовой станции).
В итоге, картину перемещения абонента с точностью до соты если и можно получить, то только лишь в случае, когда часто дёргалась процедура Location Update.

Тем не менее, вопросы по хранению Cell_ID и истории изменения записей VLR, а также по хранению логов процедуры Location Update и по наличию в этих логах Cell_ID, до получения ответа от экспертов остаются открытыми.

Давайте я добавлю к куче. Хранятся или нет - это дело оператора. Здесь правильно указали, что детализация звонков и прочей активности (с указанием ID соты) - это больше биллинг, так как логируется непосредственно активность абонентская, нежели трекинг. Понятно, что сам VLR не хранит историю для отчетности (не его это дело), а MSC генерирует различного рода CDR/XDR для биллинга (для простоты рассматриваем только CS).

Но трекинг зависит от оператора. Как правило, партнерские компании предоставляют услуги аналитики, для которой производится сбор данных путем пассивной прослушки сигнального трафика. Это называется Probes Services. Суть сервиса заключается в копировании сигнального трафика, не внедряясь в маршрутизацию процесса коммутирования вызовов - т.е. сам сигнальный трафик не прерывается, но пассивно прослушивается сторонней системой, которая ведет историю абонента, с помощью экстракции полезных данных из него.

Данный сервис напрямую связан с концепцией т.н. Big Data, так как наличие таких данных (trends) позволяет, во-первых, делать выводы о маршрутах абонентов, концентрации, во-вторых - предоставлять такие данные третьим сторонам (включая спецслужбы). Все это на практике существует и работает.