Content for TS 23.236 Word version: 18.0.0
4.5 Load Balancing
4.5a Load Re-Distribution
4.6 Mobility Management
4.7 Default CN node and Backwards Compatibility
4.8 Support of combined mobility management procedures
4.9 VGCS/VBS Compatibility Issues
4.10 Interactions with E-UTRAN
...
...
4.5 Load Balancing p. 11
Preferably, the NAS Node Selection Function in the RAN node balances the load between the available CN nodes. This is performed by an appropriate selection of the CN node for an MS which was not yet assigned to a CN node, i.e. when there is no CN node configured for the NRI indicated by the MS, when a 'random TLLI' is received (Gb-mode BSC), when no NRI can be derived or in exceptional cases, e.g. when the CN node corresponding to an NRI cannot be reached.
The load-balancing algorithm is implementation specific.
When the NAS Node Selection Function in the RAN (or, if using Network Mode of Operation I, the SGSN) receives an indication that the MS is configured for low access priority (e.g. because it is used for Machine Type Communication), the NAS Node Selection Function may take this indication into account when selecting the CN node (e.g. to select an MSC that has a particularly large VLR capacity or an SGSN that is optimized to handle UEs configured for low access priority).
In case of handover/relocation into a pool-area a load balancing between all the target CN nodes serving this pool-area is gained by configuration. Source CN nodes which support Intra Domain Connection of RAN Nodes to Multiple CN Nodes may be configured with all possible target CN nodes for each handover/relocation target. Source CN nodes which do not support the Intra Domain Connection of RAN Nodes to Multiple CN Nodes can configure only one target CN node per handover/relocation target. In this case each of source CN nodes which handover/relocate to the same pool-area may be configured with another target CN node out of all target CN nodes serving the same handover/relocation target. The mechanism for distribution of the traffic between the handover/relocation target CN nodes is implementation specific. This load balancing is complemented by the NAS Node selection Function in the RAN, which distributes MSs between the CN nodes when these MSs enter the pool-area in idle mode.
As more than one SGSN may send downlink data at the same time for a cell or a BVCI the total possible downlink traffic has to shared between the SGSNs as described in clause 5.3.2.
When dedicated core networks (DCNs) are used, load balancing by RNC/BSC is only performed between SGSNs that belong to the same DCN within the same SGSN pool area. Load balancing may also be performed per DCN in the case of an SGSN serving multiple DCNs when one DCN is supported by multiple SGSNs. The DCN Load Balancing functionality permits UEs that are entering into a pool area and being re-directed to an appropriate DCN to be distributed in a manner that achieves load balancing between the core network nodes of the same DCN within the same SGSN pool area. An example of NRI configuration that can achieve this is when DCNs are used is provided in clause A.3.
In case of CS domain subsequent handover/relocation, if the controlling MSC supports Intra Domain Connection of RAN Nodes to Multiple CN Nodes then it should check the target indicated by the serving MSC. If it is in its own pool area then the handover/relocation is handled as one back to the controlling MSC (the target MSC indicated by the serving MSC is not taken into account). If the target location is not in its own pool area then the target MSC indicated by the serving MSC is taken into account as normal (handover/relocation to a third MSC).
If the controlling (anchor) MSC is not in the same pool as target third MSC and if the controlling MSC does not support Intra Domain Connection of RAN Nodes to Multiple CN nodes, because the serving MSC can select any third MSC in the target pool area, the operator should configure the addresses of all possible third MSCs within the controlling MSC.
4.5a Load Re-Distribution |R6| p. 12
4.5a.1 General p. 12
There are situations where a network operator will wish to remove load from one CN node in an orderly manner (e.g. to perform scheduled maintenance, or, to perform load re-distribution to avoid overload) with minimal impact to end users and/or additional load on other entities. The re-distribution procedure does not require any new functionality in the terminal, that is, all terminals can be moved.
Re-distribution of UEs is initiated via an O&M command in the CN node, which needs to be off-loaded. In a first phase (a couple of Periodic LU/RAU periods long), UEs doing LU/RAU or Attach are moved to other CN nodes in the pool. When the CN node receives the Location Update, Routing Area Update or Attach request, it returns a new TMSI/P-TMSI with a null-NRI, and a non-broadcast LAI/RAI in the accept message.
In CS domain the non-broadcast LAI will cause the terminal to immediately send a new Location Update, which the RAN node then will route to a new MSC due to the null-NRI. In the PS domain, a new Routing Area Update is triggered by setting the periodic routing area update timer to a sufficiently low value (recommended value is 4 seconds) in the accept message. The UE will shortly after send a new Routing Area Update that the RAN node then will route to a new SGSN due to the presence of a null-NRI.
In a second phase (PS domain specific), the SGSN requests all UEs trying to set up PDP Contexts to detach & reattach. When they reattach, the SGSN moves them as in the first phase described above.
A third phase includes scanning through remaining UEs and initiating a move of them to other CN nodes. In the PS domain UEs are requested to detach and reattach, which will cause them to be moved. In case of CS domain a new TMSI is allocated to these UEs using the TMSI re-allocation procedure (with null-NRI and non-broadcast LAI) so that a Location Update is triggered when the ongoing CM transaction ends, which will cause them to be moved.
UEs being moved from one CN node are stopped from registering to the same CN node again by an O&M command in BSCs and RNCs connected to the pool. UEs moving into a pool area may also be stopped from registering into a CN node being off-loaded in the same manner.
In network configurations using MOCN network sharing, re-distribution is always done between CN nodes within the same CN Operator. This is ensured by each CN Operator using his own unique null-NRI. The RAN node is preconfigured with the null-NRIs for the different CN Operators, and it uses the null-NRI to select a CN node within the same CN Operator.
When dedicated core networks (DCNs) are used, re-distribution of UEs is always done to core network nodes of the same DCN as the node being off-loaded. The details are as follows:
- If null-NRI is used to identify the group of SGSNs that belong to a DCN within a PLMN (see TS 23.401, clause 4.3.25), then the procedure stated in the clause above may be used. The null-NRI corresponds to the DCN of the node being off-loaded.
- If either "SGSN group ID" or null-NRI is used to identify the group of SGSNs that belong to a DCN within a PLMN, then the following procedure may instead be used:
- To off-load UEs in PMM-IDLE/STANDBY state that perform RAU Updates or Attaches, the SGSN uses the NAS Message Redirection Procedure (see TS 23.401, clause 5.19.1) to redirect the UE to another SGSN within the same DCN. To off-load UEs in PMM-IDLE/STANDBY state without waiting for the UE to perform a RAU procedure, the SGSN first pages the UE to bring it to PMM-CONNECTED/READY state and then proceeds as below.
- To off-load UEs in PMM-CONNECTED/READY state, the SGSN first performs P-TMSI reallocation procedure, includes the UEs unchanged P-TMSI and a non-broadcast RAI, and sets the periodic routing area update timer to a sufficiently low value (recommended value is 4 seconds) and forces the UE to change state to PMM-IDLE/STANDBY state. The UE shortly performs a RAU procedure, during which the SGSN uses the NAS Message Redirection Procedure (see TS 23.401, clause 5.19.1) to redirect the UE to another SGSN within the same dedicated CN.
4.5a.2 Network Mode of Operation = 1 p. 13
If an operator is using Network Mode of Operation = 1 (i.e. using combined MM and GMM procedures and the Gs interface), then redistribution of MSC load needs to be handled in a special way.
Redistribution of UEs is initiated by O&M command in the SGSN providing the Gs interface to the MSC to be off-loaded. The corresponding NRI distribution or IMSI Hash table is reconfigured to reflect the redistribution. If the SGSNs are also configured in a pool, this is repeated for any SGSN connected to that MSC. The NRI distribution or IMSI Hash table shall have a consistent configuration in all SGSNs in the pool (to ensure that a redistribution of SGSN load doesn't affect the MSC registration of UEs).
The redistribution is done in two phases. During the first phase, the UEs that are performing combined RA/LA updates are moved to a new MSC. When the SGSN receives a Routing Area Update Request (combined RA/LA updating), it checks if the particular UE shall be moved (i.e. it has a Gs association with the MSC being off-loaded). If the UE shall be moved, the SGSN invokes the MSC selection function (NRI distribution or IMSI Hash) to decide where the UE should be distributed. SGSN sends the (BSSAP+) Location-Update-Request (IMSI attach) to the new selected MSC where the UE is registered. Stationary UEs (i.e. UEs not performing RA/LA updates) are not moved during this first phase.
During the second phase, the SGSN scans its Gs associations to find out which UEs shall be moved. For each UE with an association to the MSC being off-loaded, the SGSN sends a Detach Request (indicating IMSI detach). The UE is forced to re-attach to non-GPRS service (note that there is no impact on PDP contexts in this case). The UE sends a RAU request (combined RA/LA updating with IMSI Attach). SGSN checks if the UE shall be moved. If the UE shall be moved, the SGSN invokes the MSC selection function (NRI distribution or IMSI Hash) to select another MSC. SGSN sends the (BSSAP+) Location-Update-Request (IMSI attach) to the new MSC where the UE is registered.
During the redistribution, incoming IMSI Detach messages are (as during normal operation) routed to respective existing associated MSC. That is, the reconfigured NRI distribution or IMSI Hash doesn't affect the routing of IMSI Detach messages.
4.6 Mobility Management p. 13
An MS performs LA or RA Updates and Attachments, which may result in a change of the serving CN node. In these procedures the new CN node requests from the old CN node MS specific parameters. If multiple CN nodes are configured in the new CN node for the old RA or LA indicated by the MS then the new CN node derives the NRI from the old (P-)TMSI indicated by the MS. The new CN node uses the old RA or LA together with the NRI to derive the signalling address of the old CN node from its configuration data. If the network contains nodes that cannot derive the old CN node from LAI/RAI and NRI a default CN node for each RA or LA (as described below) shall be used to resolve the ambiguity of the multiple CN nodes serving the same area.
4.7 Default CN node and Backwards Compatibility p. 14
CN nodes that can only derive one CN node from the LAI or RAI (e.g. because they do not support the Intra Domain Connection of RAN Nodes to Multiple CN Nodes, or no detailed knowledge of the NRIs is configured) are not aware, that multiple CN nodes may serve a LA or RA. These nodes can therefore contact only one CN node per LA or RA, respectively. This node will further on be referred to as default node.
A default node resolves the ambiguity of the multiple CN nodes per LA or RA by deriving the NRI from the TMSI and P-TMSI. The default node relays the signalling between the new CN node and the old CN node.
Note that the default node is configured per LA or RA. So different CN nodes in a network might have configured different default nodes for a LA or RA. With this approach more than one of the CN nodes that serve a pool-area can be used as default-node, so load concentration on one node and a single point of failure can be avoided.
Note further, that it may be required to keep information on ongoing MAP/GTP dialogues in the default nodes.
The handover/relocation from CN nodes which do support the Intra Domain Connection of RAN Nodes to Multiple CN Nodes to CN nodes not supporting this features does not need a NAS Node Selection Function in the originating CN node as there is only one target CN node. The originating CN node discovers from its configuration data, that there is only one target CN node for the requested handover/relocation target ID. See clause 4.5 for handling of subsequent handover/relocation in the controlling CN node.
4.8 Support of combined mobility management procedures p. 14
4.8.1 Attach p. 14
In case of 'combined GPRS/IMSI attach' or 'GPRS attach when already IMSI attached', the SGSN sends the Location Update Request message to the MSC/VLR. The SGSN selects an MSC/VLR from the available MSC/VLRs which serve the current LA of the MS. The selection is based on the TMSI based NRI as provided by the UE or a hash value derived from the IMSI. It is configured in the SGSN which NRI values and range of the hash values relates to which MSC/VLR. This selection mechanism avoids a random change of the MSC/VLR for MSs using combined procedures when an SGSN fails. The new SGSN will select the same MSC/VLR.
In some networks, the SGSN may be configured to select the MSC/VLR for "MSs configured for low access priority" with a different load balance to that used for MSC/VLR selection for other UEs. In this case the SGSN maintains a separate NRI and hash value function for "MSs configured for low access priority".
4.8.2 Routing area update p. 14
The CN node changes in the following considerations result from pool-area changes (when pool-areas are configured) or from CN node service area changes (when no pool-areas are configured). For each domain (PS or CS) it is configured independently whether pool-areas are used or not.
When neither the MSC nor the SGSN are changed, the association for an MS between both CN nodes will also not change.
When the MSC changes but the SGSN does not change, the SGSN selects a new MSC because the new LA is not served by the old MSC/VLR. The selection mechanism is as described for the attach above.
When the SGSN changes but the MSC does not change, the new SGSN selects the old MSC to establish a Gs association because the new SGSN uses the same selection mechanism as described above for the attach with the same parameters as configured in the old SGSN.
When both the MSC and the SGSN change, the new SGSN selects a new MSC to establish a Gs association. The selection mechanism is as described for the attach above.
4.9 VGCS/VBS Compatibility Issues p. 15
Voice Group Call Services, TS 43.068, as well as Voice Broadcast Service, TS 43.069, are specified for A-interface only. Architectural enhancements and procedures needed to support these services in an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is applied on the A-interface are specified in TS 43.068 and TS 43.069.
4.10 Interactions with E-UTRAN |R8| p. 15
The MS has separate core network temporary identities for GERAN/UTRAN (the RAI plus P-TMSI in the packet domain) and E-UTRAN (the GUTI).
Following movement between GERAN/UTRAN and E-UTRAN the MS will have both a P-TMSI and a GUTI. Independent of whether the Idle mode Signalling Reduction (ISR) feature is active, one or both of the P-TMSI and GUTI may be valid. If the MS is E-UTRAN capable, then TS 23.401, TS 23.060 and TS 23.003 define rules as to how the MS shall select and encode the identity to place in the P-TMSI/TLLI parameters used in the Routing Area Update procedure.
In some network deployments the MME and SGSN may be combined in the same physical platform (while in other deployments they may be separated).
TS 23.003 specifies a mapping from the E-UTRAN core network temporary identity (the GUTI) to the TLLI that facilitates the BSC to route an RA update caused by movement from E-UTRAN to GERAN to an SGSN that is on the same physical platform as the MME.
TS 23.003 and TS 25.331 specify a mapping from the E-UTRAN core network temporary identity (the GUTI) to the IDNNS that facilitates the RNC to route an RA update caused by movement from E-UTRAN to UTRAN to an SGSN that is on the same physical platform as the MME.
TS 23.003 also specifies a mapping from the RAI and P-TMSI to the GUTI that facilitates the E-UTRAN to route to an MME that is on the same physical platform as the SGSN. For this mapping function to work correctly when using combined MME/SGSNs, the effective maximum length of the NRI is reduced from 10 bits to 8 bits.
