Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.236  Word version:  16.0.0

Top   Top   Up   Prev   None
0…   4…   5…   6…   A…

 

A  Network configuration examplesWord‑p. 33

A.1  One city centre surrounded by residential areas

A.1.1  Assumptions

This example shows a network covering one city centre surrounded by residential areas. The city centre is covered by all 4 pool-areas while the residential areas are covered by one pool-area only. Once a subscriber "found" its pool-area, he will not change the pool-area while commuting between the city centre and his residential area.
Each of the pool-areas is served by 5 MSCs, indicated by the 5 NRI values in the Figure below.
The example in the Figure configures 4 overlapping pool-areas:
  • City centre with 12 Mio subscribers (with context in VLR, attached or detached);
  • One switch office/building with 5 MSCs (5 NRIs) per pool-area;
  • Capacity of one MSC/VLR up to 1 Mio subscribers in VLR;
  • 4 bits are assumed for the VLR-restart counter;
  • Only distinct NRI values are used, so a UE changing between pool-areas will always be allocated to a new MSC by the NAS node selection function.
(not reproduced yet)
Figure 9: One city centre surrounded by residential areas
Up

A.1.2  TMSI calculationWord‑p. 34

For addressing in the CS domain 30 bits for can be used (Bit 30&31 are reserved):
  • The assumption is that 4 bits are used for the restart counter;
  • To differentiate the 20 MSC in the city area 5 bits are needed for the NRI (12 NRI values remain unused; these 12 NRIs are left for additional MSCs in the whole area, NRIs can also be re-used as indicated in the Figure);
  • This leaves 30-4-5 = 21 bits for every MSC to address the subscriber data records in the VLR. (This give address space for 2 Mio TMSIs unique over all LAs of the MSC);
  • The 4 pool-areas sum up to 20 Mio subscriber, allowing for some unbalanced load distribution.
Up

A.2  3 Neighbouring large city centres

This documents 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.
(not reproduced yet)
Figure 10: Example of a TMSI structure with 5 bit 'VLR-restart counter' and 5 bits NRI-length
Up
'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!
(not reproduced yet)
Figure 11: Modified TMSI structure 7 bits NRI-length; VLR-restart field must be reduced to 3 bit
Up
  • 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
(not reproduced yet)
Figure 12: Modified TMSI structure 7 bits NRI-length; VLR-restart field must remain 3 bit.
Up
'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
(not reproduced yet)
Figure 13: NRI-length can be reduced by 1 bit; VLR-restart field can increase to 4 bit.
Up
'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
(not reproduced yet)
Figure 14: NRI-length can be reduced by 1 bit; VLR-restart field can increase to 4 bit.
Up
'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).
(not reproduced yet)
Figure 15: TMSI example for TMSI allocation per VLR; 32M TMSI/pool;
Up
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.
Up

A.3  Support of Dedicated Core Networks |R13|Word‑p. 39

An overview of dedicated core network (DCN) feature is provided in TS 23.401. This annex provides an example of NRI configuration for supporting DCNs.
The following example shows a split of NRI values between operators A (0..99) and B (100..199). Each operator has a separate core network. Furthermore, each operator has two DCNs (A1, A2) and (B1, B2).
Two pool/deployment areas are shown below.
(not reproduced yet)
Figure A.3-1: Example NNSF configuration to support DCN
Up
The figure above shows how the NNSF of pool 1 is configured to select the same operator and same DCN when a UE moves in from neighbour pool area 2. This configuration avoids redirection procedure for UEs that move in idle mode between the pool areas.
With the NNSF configured above, there are NRIs available that may be re-used for redistribution of UEs within the pool without requiring reservation of extra NRIs for redistribution i.e. the NRI allocated to a neighbouring pool area and not allocated in this pool area may be used as a Null-NRI for the pool area. This also avoids the need for additional configuration in NNSF.
In the example above, all A1 nodes of pool 1 may use NRI 4 as Null-NRI for redistributing UEs between A1 nodes of pool 1. The NNSFs of pool 1 are configured to select a new node from nodes belonging to A1, when a UE indicates an IDNNS with NRI 4 or NRI 4 is provided as the Null-NRI in the NAS message redirection procedure by an SGSN (see TS 23.401).
Up

$  Change historyWord‑p. 41


Up   Top