Content for  TS 23.236  Word version:  18.0.0

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

• 3 neighbouring pools with capacity of 32 M non-purged 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 'VLR-restart' 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) non-purged subscribers this results in:
  • Minimum 32 nodes are needed per pool-area (5-bit NRI).
  • Minimum is 16 LA's per pool-area.

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 non-purged TMSIs 20 Bits have to be reserved for TMSI per NRI and 5 bit for the NRI value.
• The NRI is located bit 14-23 (configurable). It is assumed that the bits 19-23 are used for the NRI.

'3 pool configuration' - no sharing of NRI values:

• This example assumes that the 3 pool-areas have independent NRI values, so the available TMSI range has to be shared between the pools. All TMSI's from other pool-areas can be detected - best load distribution in the pools.
• So 3*32 = 96 NRI values are needed for all 3 pools. The NRI-length has to be increased to 7 bit. (not an optimum configuration since 32 NRI values are unused). In the example the NRI now uses bits 23-17.
• Since still for each NRI value 20 bits are needed to address 1M TMSIs there is a conflict with the assumed VLR-restart field length of 5 bit. The VLR-restart field has to be reduced to a 3 bit field in order to free sufficient addressing space in the TMSI structure!

• In this example configuration 32M TMSI values are wasted! So it would be more efficient to assign these TMSI ranges to the 3 pools rather than leave them unused. Alternatively these values could be used for sharing with nodes in the 'outside world'.
• The major drawback of this solution is the reduction of the VLR-restart field to 3 bits only!

  '3 pool configuration' - 25% of NRI values shared between the pools:

• Now the pool configurations are changed in a way that 25% of the NRI values are the same in all the 3 pools. This means that for ¼ of subscribers pool-changes cannot be detected. The traffic generated by these subscribers will not be distributed, but is routed by the NAS node selection function to the specific node with this NRI value in the new pool.
• The total range of needed NRI values is reduced by this to:
  8 (the shared NRI's) + 3 * 24 = 80
• To code this NRI's still 7 bit are needed. So there is no gain in terms of addressing space in this example.
• In the example the NRI values 0..7 are shared and so are the TMSI ranges x0000000xx .. x0000111x

'3 pool configuration' - 50% of NRI values shared between the pools:

• The percentage of the shared NRIs is now increased to 50%. So ½ of the NRI values are the same in all the 3 pools. This means that for ½ of subscribers pool-changes cannot be detected. The traffic generated by these subscribers will not be distributed, but is routed by the NAS node selection function to the specific node with this NRI value in the new pool.
• The total range of needed NRI values is reduced by this to:
  16 (the shared NRI's) + 3 * 16 = 64.
• This reduction of NRI saves 1 bit in NRI length. So the VLR-restart can be slightly increased to 4 bit (still 1 bit less than in the original assumption).
• In the example the NRI values 0..15 are shared and so are the TMSI ranges x000000xx .. x001111x.

'3 pool configuration' - 75% of NRI values shared between the pools:

• Next step is to even increase the shared part of the NRI to ¾. This means that only 25% of the incoming traffic in a pool-area is distributed.
• The total range of needed NRI values is reduced by this to:
  24 (the shared NRI's) + 3 * 8 = 48.
• Like the first step this doesn't free any addressing space in the TMSI. But some NRI values are now available in case it is wanted to share them with other nodes outside the '3 pool area'.
• In the example the NRI values 0..23 are shared and so are the TMSI ranges x000000xx .. x010111x.

'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 non-purged subscribers; 1M per MSC) with a VLR-restart 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 pool-areas 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 VLR-restart 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 re-allocations may increase since every change of LA must result in a TMSI reallocation.
• MAP on VLR-VLR 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 pool-area - 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 paging-request there will trigger several page-response messages per LA.