When the RNC receives a message with a 'null-NRI' it uses the NAS Node Selection Function for selecting a CN node where to forward the message. CN node(s) with re-distribution in progress should be excluded from the NAS Node Selection algorithm in the RNC. This is done by O&M configuration in the RNC. In network configurations using MOCN network sharing, the RNC is preconfigured with a null-NRI for each CN Operator in the MOCN. The RNC selects a CN node belonging to a CN Operator based on what 'null-NRI' is received.

The BSC provides the NAS Node Selection Function. It is aware whenever a new RR connection is established. In particular, the BSC always examines the content of the Initial Layer 3 message sent by the MS in order to determine the position of the MS Classmark and to extract its contents. The examination of the Initial Layer 3 message content allows the BSC to observe the TMSI+LAI or IMSI or IMEI. The BSC derives from Initial Layer 3 messages the NRI from the TMSI. It is configured in the BSC (O&M) which bits of the TMSI are significant for the NRI. The BSC routes the Initial Layer 3 message according to the NRI to the relevant MSC if an MSC address is configured in the BSC for the specific NRI. The association between NRI values and MSC addresses is configured in the BSC (O&M). If no MSC address is configured in the BSC for the requested NRI, or if no TMSI is sent by the MS (e.g. an IMSI or IMEI), then the BSC routes the initial NAS signalling message to an MSC selected from the available MSCs. In addition, the BSC may route the initial NAS signalling message to an MSC selected from the available MSCs if this message is a Location Update Request messages and the PLMN ID in the LAI is not one of the PLMN IDs served by the BSC (FFS). The selection mechanism is implementation dependent and should enable load balancing between the available MSCs. In some networks, the BSC 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 MSs. In case a MSC sends a paging-request with IMSI, the NAS node selection function in the BSC shall upon reception temporarily store the MSC/VLR-identity of the node that issued the paging-request message.

The BSC provides the NAS Node Selection Function. The MS sends the TLLI to the BSC. The NRI is part of the P-TMSI and therefore also contained in the 'local TLLI' or in the 'foreign TLLI'. The number of bits out of the TLLI which are significant for the NRI is configured in the BSC (O&M). A 'local TLLI' indicates to the BSC that the TLLI is derived from a P-TMSI which was assigned for the current RA, i.e. the 'local TLLI' contains an NRI which is valid for routing to an SGSN. A 'foreign TLLI' indicates to the BSC that the TLLI is derived from a P-TMSI which was assigned for another RA than the current RA. The BSC does not know whether the other RA and therefore the related P-TMSI belongs to the same pool-area or not unless this is configured in the BSC (which is not intended). Consequently, the BSC assumes, that the 'foreign TLLI' contains a NRI which is valid for routing to an SGSN. For 'local TLLIs' and for 'foreign TLLIs' the BSC masks the NRI out of the TLLI. The BSC routes the uplink LLC frame to the relevant SGSN if an SGSN address is configured in the BSC for the specific NRI. The association between NRI values and SGSN addresses is configured in the BSC (O&M). If no SGSN address is configured in the BSC for the requested NRI, which may happen for NRIs masked out of a 'foreign TLLI', or if the BSC received a 'random TLLI' which contains no NRI at all then the RNC routes the uplink LLC frame to an SGSN selected from the available SGSNs. The selection mechanism is implementation dependent and should enable load balancing between the available SGSNs. In some networks, the BSC may be configured to select the SGSN for "MSs configured for low access priority" with a different load balance to that used for SGSN selection for other MSs. In this case, until TLLI re-allocation occurs, the BSC shall remember which TLLIs are from "MSs configured for low access priority" and which are not. As more than one SGSN may send downlink data at the same time for a cell or a BVCI, the BSC has to share the total possible downlink traffic between the SGSNs that can access a cell. The BSC should use the existing flow control procedure on cell level to control each of the SGSNs in a way not to violate the total possible traffic for the cell. How the BSC decides to share the downlink traffic between each of the SGSNs is an implementation specific issue; e.g. the possible downlink traffic can be equally shared between the SGSNs, or the share of each SGSN can be proportional to the capacity of the SGSN. In case a MSC sends a paging-request with IMSI via Gs-interface the SGSN has to add the MSC/VLR-identity to the paging-request message. The NAS node selection function in the BSC/RNC shall upon reception temporarily store the MSC/VLR-identity.

To support MSs in Iu mode the BSC provides the same functionality as described under "RNC Functions".

When the BSC receives a message with a 'null-NRI' it uses the NAS Node Selection Function for selecting a CN node where to forward the message. This is also done for all messages with 'random TLLIs' (Gb-mode). CN node(s) with re-distribution in progress should be excluded from the NAS Node Selection algorithm in the BSC. This is done by O&M configuration in the BSC.

Every MSC is configured with its one or more specific NRI (O&M). One of these specific NRIs is part of every temporary identity (TMSI) which the MSC assigns to an MS. The TMSI allocation mechanism in the MSC generates TMSIs which contain one of the specific NRIs in the relevant bit positions. An NRI has a flexible length between 10 and 0 bits (0 bits means the NRI is not used and the feature is not applied). The use of the bits not used to encode the NRI is implementation dependent (e.g. to extent the TMSI space). An MSC applying "Intra Domain Connection of RAN nodes to multiple CN nodes" shall allocate TMSIs to the served MSs.

For MAP signalling between two MSCs which both support the Intra Domain Connection of RAN Nodes to Multiple CN Nodes the new MSC derives the address of the old MSC from the old LAI and the NRI contained in the old TMSI. The MSC addresses for each LAI and NRI combination are configured in the MSC (O&M). If the network contains MSCs that cannot derive the old MSC from LAI and NRI the default MSC per LAI as described below shall be used (e.g. to reduce the configuration effort). Some redundancy may be required as the default MSC is a single point of failure. The load balancing between multiple target MSCs at handover/relocation into a pool area is described in "4.5 Load Balancing". The handover/relocation from an MSC that supports the Intra Domain Connection of RAN Nodes to Multiple CN Nodes to an MSC not supporting the feature needs no new functionality, as there is only one MSC that serves the handover/relocation target.

If a default MSC that is serving a pool-area receives MAP signalling (e.g. to fetch the IMSI or to get unused cipher parameters) it has to resolve the ambiguity of the multiple MSCs per LAI by deriving the NRI from the TMSI. The MSC relays the MAP signalling to the old MSC identified by the NRI in the old TMSI unless the default MSC itself is the old MSC. For every NRI value that is used in the pool-area an MSC address is configured in the default MSC (O&M).

If the SGSN does not support the Intra Domain Connection of RAN Nodes to Multiple CN Nodes then only one default out of the MSCs serving the related LA can be used for the combined procedures. A relaying or diverting from the default MSC to another is FFS. Distributing the associations of the combined procedures according to the LAs would result in MSC changes when the MS is still in the old MSC service area.

The MSC needs to ensure that the RR-connection is released immediately after the Location Update response message is returned to the UE, i.e. the follow-on proceed flag shall be cleared. For the special case when an MSC in a pool also serves a BSC or RNC that is not part of the pool (e.g. a BSC or RNC that does not support pool functionality), an MSC should not try to re-distribute UEs connected to that BSC or RNC.

Every SGSN is configured with its specific one or more NRI (O&M). One of these specific NRIs is part of every temporary identity (P-TMSI) which the SGSN assigns to an MS. The P-TMSI allocation mechanism in the SGSN generates P-TMSIs which contain one of the specific NRIs in the relevant bit positions. An NRI has a flexible length between 10 and 0 bits (0 bits means the NRI is not used and the feature is not applied). The use of the bits not used to encode the NRI is implementation dependent (e.g. to extent the TMSI space). An SGSN applying "Intra Domain Connection of RAN nodes to multiple CN nodes" shall allocate P-TMSIs to the served MSs.

For the GTP signalling between two SGSNs supporting the Intra Domain Connection of RAN Nodes to Multiple CN Nodes the new SGSN derives the address of the old SGSN from the old RAI and the NRI contained in the old P-TMSI/TLLI. The SGSN addresses are configured in the SGSN (O&M) or in DNS for each RAI and NRI combination. If the network contains SGSNs that cannot derive the old SGSN from RAI and NRI the default SGSN per RAI as described below shall be used (e.g. to reduce the configuration effort). The load balancing between multiple target SGSNs at handover/relocation into a pool area is described in "4.5: Load Balancing". The handover/relocation from an SGSN that supports the Intra Domain Connection of RAN Nodes to Multiple CN Nodes to an SGSN not supporting the feature needs no new functionality, as there is only one SGSN that serves the handover/relocation target.

If a default SGSN that is serving a pool-area receives GTP signalling (e.g. to fetch the IMSI or to get unused cipher parameters) it has to resolve the ambiguity of the multiple SGSNs per RAI by deriving the NRI from the P-TMSI. The SGSN relays the GTP signalling to the old SGSN identified by the NRI in the old P-TMSI unless the default SGSN itself is the old SGSN. For every NRI value that is used in the pool-area an SGSN address is configured in the relaying SGSN (O&M) or in DNS.

The SGSN has to select an MSC at the Gs interface for the combined procedures if multiple MSCs are configured for the relevant LAI. The MSC out of the available MSCs is selected based on the TMSI based NRI as provided by the UE or on the IMSI, and optionally, whether the "MS is configured for low access priority". Use of the TMSI based NRI as provided by the UE prevents an MSC change for UEs when UEs register first via normal procedures, and later by combined procedures. Use of the TMSI based NRI as provided by the UE or IMSI hash prevents an MSC change for many MSs if an SGSN fails and the re-attaching MSs would get assigned another MSC by the new SGSN. Two HLR updates instead of one would be the result. From the LAI and the TMSI based NRI as provided by the UE, the SGSN can select a VLR from the available VLRs. The NRI length and the selected VLR per NRI value shall be the same as for the CN Node selection for the CS Domain in the RNC and BSC nodes. From the IMSI the SGSN derives a value (V) using algorithm [(IMSI div 10) modulo 1000]. Every value (V) from the range 0 to 999 corresponds to a single MSC node. Typically many values of (V) may point to the same MSC node. The configuration of the MSC node should be the same in the same RNC area. 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 second set of tables of NRI to MSC mappings, and of value (V) to MSC mappings.

If a CS paging is received via the Gs interface from MSC with mobile identity type IMSI then the SGSN should include the MSC/VLR-id in the paging / paging-request message to RNC/BSC.

On the Iu-ps interface the SGSN needs to ensure that the Iu-connection is released immediately after the Routing Area Update response message is returned to the UE, i.e. the follow-on flag shall be cleared. On the Gb interface the SGSN needs to force the UE to standby after the Routing Area Update response message is returned to the UE, i.e. the force to standby indication shall be set. This ensures the Periodic Routing Area Update timer to start as quickly as possible. For the special case when an SGSN in a pool also serves a BSC or RNC that is not part of the pool (e.g. a BSC or RNC that does not support pool functionality), an SGSN should not try to re-distribute UEs connected to that BSC or RNC.