This document provides some calculations for 'poolidentification alternative B' in case that 3 huge city centres are covered by poolareas with direct contacts.
Assumptions:
The calculations are based on the following assumptions:

3 neighbouring pools with capacity of 32 M nonpurged subscribers each.

Maximum capacity of a paging channel is 1 M pagings/hour per LA.

0.25 pagings / hour are assumed per subscriber → 2M TMSI/LA can be realized.

For the 'VLRrestart' counters a number of bits need to be reserved. Working assumption is that 5 bit should be sufficient for any implementation, in the examples these 5 bits are reserved on the upper part of the TMSI. (This is of course implementation specific and not part of Iu Flex).

The calculations are based on a node capacity of up to 1M (2^20) nonpurged subscribers this results in:

Minimum 32 nodes are needed per poolarea (5bit NRI).

Minimum is 16 LA's per poolarea.
Basic configuration needed for 1 pool:

To address the 32M TMSI per pool the total number of 25 bits are needed in the TMSI.

For a node capacity of 1M nonpurged TMSIs 20 Bits have to be reserved for TMSI per NRI and 5 bit for the NRI value.

The NRI is located bit 1423 (configurable). It is assumed that the bits 1923 are used for the NRI.
'3 pool configuration'  full sharing of NRIs between the pools:

The last variant of these configurations is a full sharing is all NRI values between all neighbouring pools. In this case no detection of pool area changes is possible. Consequently no distribution of load can be achieved. This results necessarily in the need to have a 'forced redistribution' mechanism to resolve heavy unbalance of load.

The NRI and TMSI ranges will then be the same as in the 'single pool' example in the beginning.
Result:
The examples above show that it is basically not possible to configure the example configuration (32M nonpurged subscribers; 1M per MSC) with a VLRrestart field as put in the assumptions, except that the full range of NRI is shared between the pools.
Taking it literally it could be possible with 3 pools when sharing the remaining quarter of the NRI (the part that would be unused otherwise), but latest if 4 poolareas with this capacity have to be supported this reaches the limit.
An alternative to overcome this could be to apply the TMSI's on a per LA basis as it is already foreseen on the A/Iu interface specifications.
TMSI per LA:
Taking the example configuration mentioned above but changing the TMSI allocation per LA would result in an increase of the addressing space. Then the same TMSI value can be used multiple times in the same VLR. A specific subscriber data record can then only be addressed by LA&TMSI.
For the 32 MSCs this means that that each of them supports an equal share of TMSI of a LA. So each MSC handles 2M/32 = 32k TMSI of a specific LA.
The required TMSI addressing space id thereby reduced to 15 bit per MSC.
If, like before, 96 NRI values are needed to address all nodes in the 3 pools then 7 bit are needed for this. This leaves 5 bit for the VLRrestart counters (plus 3 unused bits).
Without sharing NRI values the pool size can even be increased (Factor 8  since 3 bit spare).
A number of aspects however remain to be looked at with this TMSI per LA approach:

It requires an equal distribution of UE's of a certain LA over all nodes in the pool. This contradicts the wish for a flexible routing where e.g. a new attach should be routed to the closest node in order to save transmission resources.

Attach requests in a LA may be rejected by one node because this node has already a fully booked TMSI table for this LA. At the same time the node may have in total still capacity left to serve subscribers.

The total load of TMSI reallocations may increase since every change of LA must result in a TMSI reallocation.

MAP on VLRVLR I/F must be updated, otherwise subscriber confidentially decreases because for every change to other MSCs the IMSI has to be fetched via the air I/F. (At the same time node changes should only occur when changing the poolarea  so maybe never?).

Can it happen that if NRI are shared there are several subscribers with the same TMSI in a certain LA? FFS
If yes then a pagingrequest there will trigger several pageresponse messages per LA.