3GPP TS 23.236 V13.0.

0 (2015-06)
Technical Specification

3rd Generation Partnership Project;

Technical Specification Group Services and System Aspects;
Intra-domain connection of Radio Access Network (RAN)
nodes to multiple Core Network (CN) nodes
(Release 13)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
 Keywords
LTE, GSM, UMTS, network, interworking

3GPP

Postal address

3GPP support office address

650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet
http://www.3gpp.org

Copyright Notification

No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.

© 2015, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association
Release 132T 3 3GPP TS 23.236 V13.0.0 (2015-06)

Contents
Foreword............................................................................................................................................................. 5
Introduction ........................................................................................................................................................ 5
1 Scope ........................................................................................................................................................ 6
2 References ................................................................................................................................................ 6
3 Definitions, symbols and abbreviations ................................................................................................... 7
3.1 Definitions ......................................................................................................................................................... 7
3.2 Symbols ............................................................................................................................................................. 7
3.3 Abbreviations ..................................................................................................................................................... 7
4 General Description.................................................................................................................................. 8
4.1 Iu Flex Technical Requirements ........................................................................................................................ 8
4.2 Overview ........................................................................................................................................................... 8
4.3 Pool-Area and Network Resource Identification ............................................................................................. 10
4.4 NAS Node Selection Function ......................................................................................................................... 10
4.5 Load Balancing ................................................................................................................................................ 11
4.5a Load Re-Distribution ....................................................................................................................................... 12
4.5a.1 General ....................................................................................................................................................... 12
4.5a.2 Network Mode of Operation = 1 ................................................................................................................ 13
4.6 Mobility Management...................................................................................................................................... 13
4.7 Default CN node and Backwards Compatibility .............................................................................................. 14
4.8 Support of combined mobility management procedures.................................................................................. 14
4.8.1 Attach ......................................................................................................................................................... 14
4.8.2 Routing area update.................................................................................................................................... 14
4.9 VGCS/VBS Compatibility Issues .................................................................................................................... 15
4.10 Interactions with E-UTRAN ............................................................................................................................ 15
5 Functional Description ........................................................................................................................... 15
5.1 MS Functions ................................................................................................................................................... 15
5.2 RNC Functions ................................................................................................................................................ 16
5.2.1 Load Re-Distribution function in RNC ...................................................................................................... 16
5.3 BSC Functions ................................................................................................................................................. 16
5.3.1 A interface mode ........................................................................................................................................ 16
5.3.2 Gb mode ..................................................................................................................................................... 17
5.3.3 Iu mode ...................................................................................................................................................... 18
5.3.4 Load Re-Distribution function in BSC ....................................................................................................... 18
5.4 MSC Functions ................................................................................................................................................ 18
5.4.1 TMSI Allocation ........................................................................................................................................ 18
5.4.2 Mobility Management and Handover/Relocation ...................................................................................... 18
5.4.3 Backward Compatibility and Default MSC ............................................................................................... 18
5.4.4 Support of Combined Procedures............................................................................................................... 18
5.4.5 Load Re-Distribution function in MSC ...................................................................................................... 18
5.5 SGSN Functions .............................................................................................................................................. 19
5.5.1 P-TMSI Allocation ..................................................................................................................................... 19
5.5.2 Mobility Management and Handover/Relocation ...................................................................................... 19
5.5.3 Backward Compatibility and Default SGSN .............................................................................................. 19
5.5.4 Support of Combined Procedures............................................................................................................... 19
5.5.5 CS Paging ................................................................................................................................................... 20
5.5.6 Load Re-Distribution function in SGSN .................................................................................................... 20
6 Application Examples ............................................................................................................................ 20
6.1 Network configuration example 1 ................................................................................................................... 20
6.2 Network configuration example 2 ................................................................................................................... 20
7 Specific Examples .................................................................................................................................. 21
7.1 Building blocks for signalling flows ................................................................................................................ 21
7.1.1 RAN node selecting CN node in A interface mode.................................................................................... 21

3GPP
Release 132T 4 3GPP TS 23.236 V13.0.0 (2015-06)

7.1.2 RAN node selecting CN node in Gb interface mode.................................................................................. 21

7.1.3 RAN node selecting CN node in Iu interface mode ................................................................................... 21
7.1.4 New CN node selecting old CN node ........................................................................................................ 21
7.1.5 Old CN node selecting new CN node ........................................................................................................ 22
7.1.6 SGSN selecting MSC ................................................................................................................................. 22
7.2 Signalling flow for Attach (Iu interface mode) ................................................................................................ 22
7.3 Signalling flows for Service Request (Iu interface mode) ............................................................................... 24
7.3.1 Service Request initiated by MS ................................................................................................................ 24
7.3.2 Service Request initiated by network ......................................................................................................... 25
7.4 Signalling flow for Routing Area Update (Iu interface mode) ........................................................................ 27
7.5 IMSI attach procedure / Location area update with IMSI ................................................................................ 30

Annex A (informative): Network configuration examples.................................................................. 33

A.1 One city centre surrounded by residential areas ..................................................................................... 33
A.1.1 Assumptions .................................................................................................................................................... 33
A.1.2. TMSI calculation ............................................................................................................................................. 34
A.2 3 Neighbouring large city centres .......................................................................................................... 34
A.3 Support of Dedicated Core Networks .................................................................................................... 39
Annex B (informative): Change history ............................................................................................... 41

3GPP
Release 132T 5 3GPP TS 23.236 V13.0.0 (2015-06)

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates,
etc.

z the third digit is incremented when editorial only changes have been incorporated in the document.

Introduction
UMTS will build on the success of GSM and is likely to become even more widespread, increasing the importance of a
flexible network structure to permit the different operational configurations in which these networks will be deployed.
The requirements to have a RNC or BSC controlled by a single MSC server or SGSN lead to certain limitations.
Allowing the BSCs and RNCs to connect to a number of MSC servers or SGSNs increases the networks performance in
terms of scalability, distributing the network load amongst the serving entities, and reducing the required signalling as
the user roams.

3GPP
Release 132T 6 3GPP TS 23.236 V13.0.0 (2015-06)

1 Scope
This document covers the details for the Intra Domain Connection of RAN Nodes to Multiple CN Nodes for GERAN
and UTRAN based systems. In particular, it details the impacts to GSM and UMTS systems and the stage 2 procedures
for the support of connecting a RNC or BSC to multiple MSC servers or SGSNs. The overall solution is described, and
the detailed impacts on the existing specifications are identified. The description of a broadly similar concept for E-
UTRAN based systems is not described in the document: instead, it is described in TS 23.401 [22].

NOTE: The specified solution impacts RAN nodes. In case an upgrade of radio networks is not performed, the
solutions for deploying NNSF functionality above RAN nodes described in TR 23.924 [23] may be used
as a guideline for connecting RAN nodes to multiple MSC servers.

The reference model to which these procedures apply can be found within TS 23.002 [1]. Detailed architectural
requirements within the subsystems are contained within the remainder of the 23 series of specifications e.g. the
requirements for the Packet Switched (PS) domain are contained within TS 23.060 [2] and the requirements for the
Bearer Independent CS Core Network are contained in TS 23.205 [14].

2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.

• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.

• For a specific reference, subsequent revisions do not apply.

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.

[1] 3GPP TS 23.002: "Network Architecture".

[2] 3GPP TS 23.060: "General Packet Radio Service (GPRS) Service description; Stage 2".

[3] 3GPP TS 23.012: "Location management procedures".

[5] 3GPP TS 25.331: "Radio Resource Control (RRC) Protocol Specification".

[6] 3GPP TS 25.301: "Radio interface protocol architecture".

[7] 3GPP TS 25.303: "UE functions and inter-layer procedures in connected mode".

[8] 3GPP TR 21.905: "3G Vocabulary".

[9] 3GPP TS 25.413: "UTRAN Iu interface RANAP signalling".

[10] 3GPP TS 25.410: "UTRAN Iu Interface: General Aspects and Principles".

[11] 3GPP TS 23.228: "IP Multimedia Subsystem – Stage 2".

[12] 3GPP TS 43.051: "GSM/EDGE Radio Access Network (GERAN) overall description (Stage 2)".

[13] 3GPP TS 23.153: "Out of Band Transcoder Control - Stage 2".

[14] 3GPP TS 23.205: "Bearer Independent CS Core Network – Stage 2".

[15] 3GPP TR 25.931: "UTRAN Functions, examples on signalling procedures".

[16] GSM 08.18: "General Packet Radio Service (GPRS);Base Station System (BSS) -Serving GPRS
Support Node (SGSN); BSS GPRS Protocol (BSSGP)".

3GPP
Release 132T 7 3GPP TS 23.236 V13.0.0 (2015-06)

[17] 3GPP TS 48.008: "Mobile-services Switching Centre - Base Station System (MSC - BSS)
interface; Layer 3 specification".

[18] 3GPP TS 23.003: "Numbering, addressing and identification".

[19] 3GPP TS 43.068: "Voice Group Call Service (VGCS); Stage 2".

[20] 3GPP TS 43.069: "Voice Broadcast Service (VBS); Stage 2".

[21] 3GPP TS 23.251: "Network Sharing; Architecture and functional description".

[22] 3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access".

[23] 3GPP TS 924: "Feasibility Study on NAS Node Selection Function above BSC/RNC".

3 Definitions, symbols and abbreviations

3.1 Definitions
For the purposes of the present document, the terms defined in TR 21.905 [8] apply:

CN node: for the purpose of this specification, and unless otherwise stated, a CN node is either an MSC or an SGSN.

NAS node selection Function: The function used to assign specific network resources (i.e. MSC or SGSN) to serve a
mobile station and subsequently route the traffic to the assigned network resource.

Network Resource Identifier: A specific parameter used to identify the CN node assigned to serve a mobile station.

Non-broadcast LAI/RAI: Each CN node in a pool have to be assigned one unique non-broadcast LAI/RAI that it use
in case it want to be offloaded. Each CN node in the pool has to be aware of the non-broadcast LAI/RAI assigned to the
other CN nodes in the pool, because in case of re-distribution the 'target CN node' will retrieve data (e.g. IMSI, security
context, MM & PDP contexts) from the 'offloaded CN node' based on non-broadcast LAI/RAI.

Null-NRI: A 'null-NRI' indicates to a radio node (BSC/RNC) that the NAS Node Selection Function shall be used for
selecting a CN node to receive a message. There is one unique 'null-NRI' in a PLMN supporting pool functionality. In
MOCN shared networks (see TS 23.251 [21]) with multiple CN Operators, there is one unique 'null-NRI' per CN
operator. That is, in MOCN networks the RAN Operator handles multiple 'null-NRIs'.

Pool-area: A pool area is an area within which a MS may roam without need to change the serving CN node. A pool
area is served by one or more CN nodes in parallel. All the cells controlled by a RNC or BSC belong to the same one
(or more) pool area(s).

RAN node: for the purpose of this specification, and unless otherwise stated, a RAN node is either an RNC or a BSC.

RAN node service area: This area contains all the cells controlled by the RNC or BSC.

3.2 Symbols
For the purposes of the present document, the following symbols apply:

3.3 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [8] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [8].

AS Access Stratum
BSC Base Station Controller
BVCI BSSGP Virtual Connection Identifier

3GPP
Release 132T 8 3GPP TS 23.236 V13.0.0 (2015-06)

CN Core Network
CS Circuit Switched
CS-MGW Circuit Switched Media Gateway
DCN Dedicated Core Network
DNS Directory Name Server
IDNNS Intra Domain NAS Node Selector
LA Location Area
LAI Location Area Identity
MOCN Multi-Operator Core Network
MS Mobile Station
MSC Mobile Switching Centre
NAS Non Access Stratum
NRI Network Resource Identifier
O&M Operation and Maintenance
PS Packet Switched
RA Routing Area
RAI Routing Area Identity
RAN Radio Access Network
RNC Radio Network Controller
SRNS Serving Radio Network Subsystem
TMSI Temporary Mobile Station Identity
TLLI Temporary Logical Link Identifier
UE User Equipment

4 General Description

4.1 Iu Flex Technical Requirements

This provides a (non-exhaustive) set of technical requirements:

1. Iu Flex capable RAN nodes such as the RNC/BSC shall be able to select any CN node such as the SGSN/MSC-
Server within a pool area

2. Iu Flex capable RAN nodes and CN nodes shall be able to co-exist with pre Release 5 RAN nodes and
pre Release 5 CN nodes.

3. The network shall provide the CN node routing information to the UE and the UE shall store it.

4. The UE shall provide the routing information received from the serving CN node to the RAN node. In some
cases, this serving CN node may be an Evolved Packet Core MME.

5. The solution shall enable the reduction of signalling within the core network (e.g. reduction of the HLR
signalling traffic).

6. The solution shall enable an improved scaling between radio access nodes and the core network nodes.

4.2 Overview
Editor's Note: Clarification is required in order to remove RAN nodes and CN node terminology and to capture that
this is referring to the control signalling aspects.

The Intra Domain Connection of RAN Nodes to Multiple CN Nodes overcomes the strict hierarchy, which restricts the
connection of a RAN node to just one CN node. This restriction results from routing mechanisms in the RAN nodes
which differentiate only between information to be sent to the PS or to the CS domain CN nodes and which do not
differentiate between multiple CN nodes in each domain. The Intra Domain Connection of RAN Nodes to Multiple CN
Nodes introduces a routing mechanism (and other related functionality), which enables the RAN nodes to route
information to different CN nodes within the CS or PS domain, respectively.

3GPP
Release 132T 9 3GPP TS 23.236 V13.0.0 (2015-06)

The Intra Domain Connection of RAN Nodes to Multiple CN Nodes introduces further the concept of “pool-areas”
which is enabled by the routing mechanism in the RAN nodes. A pool-area is comparable to an MSC or SGSN service
area as a collection of one or more RAN node service areas. In difference to an MSC or SGSN service area a pool-area
is served by multiple CN nodes (MSCs or SGSNs) in parallel which share the traffic of this area between each other.
Furthermore, pool-areas may overlap which is not possible for MSC or SGSN service areas. From a RAN perspective a
pool-area comprises all LA(s)/RA(s) of one or more RNC/BSC that are served by a certain group of CN nodes in
parallel. One or more of the CN nodes in this group may in addition serve LAs/RAs outside this pool-area or may also
serve other pool-areas. This group of CN nodes is also referred to as MSC pool or SGSN pool respectively.

The Intra Domain Connection of RAN Nodes to Multiple CN Nodes enables a few different application scenarios with
certain characteristics. The service provision by multiple CN nodes within a pool-area enlarges the served area
compared to the service area of one CN node. This results in reduced inter CN node updates, handovers and relocations
and it reduces the HLR update traffic. The configuration of overlapping pool-areas allows to separate the overall traffic
into different MS moving pattern, e.g. pool-areas where each covers a separate residential area and all the same city
centre. Other advantages of multiple CN nodes in a pool-area are the possibility of capacity upgrades by additional CN
nodes in the pool-area or the increased service availability as other CN nodes may provide services in case one CN node
in the pool-area fails.

An MS is served by one dedicated CN node of a pool-area as long as it is in radio coverage of the pool-area. Figure 1
shows most of the possible pool-area configurations. It contains CS pool-area 1 (RAN area 1, 2, 5, 6 served by MSCs 1,
2, 3), CS pool-areas 2 (RAN area 2, 3, 6, 7 served by MSCs 4, 5, 6), PS pool-area 1 (RAN area 1, 5 served by SGSNs 1,
2) and PS pool-area 2 (RAN area 2, 3, 6, 7 served by SGSNs 3, 4, 5). In addition the RAN areas 4 and 8 are served by
MSC 7 and SGSN 6 without any usage of the Intra Domain Connection of RAN Nodes to Multiple CN Nodes. The
possibility to configure overlapping pool-areas is shown by the CS pool-areas 1 and 2. The PS pool-areas 1 and 2 are
configured non-overlapping. The pool-areas of the CS and the PS domain may be configured identical as CS pool-area
2 and PS pool-area 2 or they may be configured differently as shown by CS pool-area 1 and PS pool-area 1. The
number or capacity of CN nodes is configured independently for each pool-area. The usage of the Intra Domain
Connection of RAN Nodes to Multiple CN Nodes may be configured in parts of the network only. It co-exists with
other areas not using this feature as shown in the figure with RAN areas 4 and 8 which are served by MSC 7 and
SGSN 6.

Figure 1: Pool-area configuration example

3GPP
Release 132T 10 3GPP TS 23.236 V13.0.0 (2015-06)

4.3 Pool-Area and Network Resource Identification

A pool-area is an area within which an MS may roam without a need to change the serving CN node. A pool-area is
served by one or more CN nodes in parallel. The complete service area of a RAN node (RNC or BSC) belongs to the
same one or more pool-area(s). A RAN node service area may belong to multiple pool-areas, which is the case when
multiple overlapping pool-areas include this RAN node service area. The pool-areas of the CS and of the PS domain are
configured independently with the granularity of RAN node service areas. Therefore, all uniqueness statements below
apply to each of the domains (CS/PS) separately. If LAs or RAs span over multiple RAN node service areas then all
these RAN node service areas have to belong to the same pool-area.

The Network Resource Identifier (NRI) identifies uniquely an individual CN node out of all CN nodes, which serve in
parallel a pool-area. The length of the NRI shall be the same in all nodes of a domain in one pool-area. In areas where
pool-areas overlap the NRI identifies uniquely a CN node out of all CN nodes, which serve all these overlapping pool-
areas, i.e. an NRI identifies uniquely a CN node within a RAN node. In case of overlapping pool-areas the NRI length
shall be configured to be the same in all the nodes of a specific domain serving these pool-areas. Note again, that the
NRIs of the CS and the PS domain are independent of each other as the PS and the CS domain CN nodes are addressed
independently. More than one NRI may be assigned to a CN node.

The NRI is part of the temporary identity TMSI (CS domain) or P-TMSI (PS domain), which is assigned by the serving
CN node to the MS. Each CN node which supports the "Intra Domain Connection of RAN Nodes to Multiple CN
Nodes" is configured with its specific one or more NRI(s). The (P-)TMSI allocation mechanism in the CN node
generates (P-)TMSIs which contain a configured NRI in the relevant bit positions. The NRI has a flexible length
between 10 and 0 bits (0 bits means the NRI is not used and the feature is not applied).

In Iu mode the MS provides an Intra Domain NAS Node Selector (IDNNS) TS 25.331 [5] in the AS part of the RRC-
Initial-direct-transfer message to the RAN node (RNC or BSC). The IDNNS contains a routing parameter with a fixed
length of 10 bits. This routing parameter transports the NRI value. In addition the IDNNS contains an indication from
which identity (TMSI, IMSI, IMEI, ...) the routing parameter is derived. The RAN node masks the significant bits out
of the routing parameter part of the IDNNS to determine the NRI which is relevant to identify the CN node. The most
significant bit of the NRI shall correspond with the most significant bit of the routing parameter in the IDNNS. When
the IDNNS is derived from the IMSI, the IDNNS has a value (V) from the range 0 to 999 as defined in TS 25.331 [5].
The RAN node shall be configured to use the value (V) to select a CN node. Each value (V) corresponds a single CN
node. Typically many values of (V) may point to the same CN node. In A/Gb mode.

In A/Gb-mode for the A interface the RAN node derives the NRI from any initial NAS signalling message. The RAN
node masks the significant bits out of the TMSI to determine the NRI, which identifies the CN node. In A/Gb-mode for
the Gb interface the RAN node derives the NRI from the TLLI. The RAN node masks the significant bits out of the
TLLI to determine the NRI, which identifies the CN node.

For all three cases, Iu, A interface and Gb mode, it is configured in the RAN node which bits out of the information
elements provided by the MS are significant for the NRI The NRI is coded in bits 23 to 14 of TMSI or P-TMSI.
Regardless of the NRI length the most significant bit of the NRI is always in bit 23 of TMSI or P-TMSI(examples of
NRI position are given in annex A.2), see also TS 23.003 [18].

The whole network may be configured as one pool-area, a network may configure multiple pool-areas and the
configuration of pool-areas may be combined with MSC or SGSN service areas which are not belonging to pool-areas.
The change of a pool-area is not visible to the MS. In general there is no need to detect a pool-area change. It may be
advantageous for load balancing purposes to detect pool-area changes in the network to distribute MSs entering a pool-
area to CN nodes with an appropriate load status. MSs changing a pool-area may be detected by configuration of
different NRI values for adjacent pool-areas. The pool-area change information potentially provided in the IDNNS by
an MS in Iu mode is ignored by the network.

4.4 NAS Node Selection Function

This function is used in RAN nodes and potentially in CN nodes. In the RAN node the function selects the specific CN
node (i.e. MSC or SGSN) to which initial NAS signalling messages or LLC frames are routed. The NRI identifies the
specific CN node. If the NAS Node Selection Function has a CN node address configured for the NRI derived from the
initial NAS signalling message or from the LLC frame then this message or frame is routed to this address. If no CN
node address is configured for the derived NRI or if no NRI can be derived (e.g. the MS indicated an identity which
contains no NRI) then the NAS Node Selection Function selects an available CN node (e.g. according to load
balancing) and routes the message or LLC frame to the selected CN node.

3GPP
Release 132T 11 3GPP TS 23.236 V13.0.0 (2015-06)

The pool-area has no influence on the decisions of the NAS Node Selection Function as pool-areas may overlap. The
NAS Node Selection Function in the RAN node derives the NRI from the IDNNS when the MS is supported in Iu mode.
When the MS is supported in Gb mode the NRI is derived from the TLLI and for A interface mode the NRI is derived
from the TMSI.

NOTE: A routing-area update after SRNS relocation is not an initial NAS signalling message, thus it is routed
along the existing Iu-connection to the SGSN.

In A/Gb mode in case a MSC/VLR sends a paging-request/paging with IMSI (i.e. the paging message does not contain
a TMSI), the NAS node selection function in the BSC shall upon reception temporarily store the Global-CN- ID of the
node that issued the paging-request/paging message. If the NAS node selection function in A/Gb mode receives a
paging-response with an IMSI then it should check the temporarily stored Global-CN-ID on entries matching this IMSI
and forward the paging-response to the node identified by this Global-CN-ID.

In Iu mode in case a MSC/VLR sends a paging-request/paging with IMSI (i.e. the paging message does not contain a
TMSI), the NAS node selection function in the BSC/RNC may upon reception temporarily store the Global-CN-ID of
the node that issued the paging-request/paging message. If the NAS node selection function in Iu mode receives an
Initial Direct Transfer message with an IDNNS derived from IMSI as a result of IMSI paging:

- and if BSC/RNC has temporarily stored the Global-CN-ID then it should check the temporarily stored Global-
CN-ID on entries matching this IDNNS and forward the paging-response to the node identified by this Global-
CN-ID or

- the BSC/RNC shall use the IDNNS derived from IMSI to select a CN node. In this case the IDNNS has a value
(V) from the range 0 to 999 as defined in TS 25.331 [5]. The RAN node shall be configured to use the value (V)
to select a CN node. Each value (V) corresponds a single CN node. Typically many values of (V) may point to
the same CN node.

In UMTS, an MS answering a paging with IMSI includes in its response an IDNNS derived from its TMSI, if the MS
has a valid TMSI. Temporarily storing the IMSI in the RNC increases the success rate to reach the MS that have both
lost their TMSI and are paged with IMSI. In GSM, an MS paged with IMSI always answers with IMSI.

If the MSC/VLR initiates the paging procedure via Gs-interface the SGSN has to add the MSC/VLR-identity to the
paging-request/paging message.

An MS will return an Attach Request containing the IMSI parameter as a response to a PS IMSI paging. Also, a PS
IMSI paging is not time supervised from the SGSN sending the message. Therefore the RAN node receiving such a
paging request does not have to buffer the associated SGSN identity. This again means that the NAS Node Selection
Function in the RAN node selects an available SGSN (e.g. according to load balancing) when it receives an Attach
Request containing the IMSI parameter.

4.5 Load Balancing

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

3GPP
Release 132T 12 3GPP TS 23.236 V13.0.0 (2015-06)

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. 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. 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

4.5a.1 General
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:

3GPP
Release 132T 13 3GPP TS 23.236 V13.0.0 (2015-06)

- If null-NRI is used to identify the group of SGSNs that belong to a DCN within a PLMN (see TS 23.401 [22],
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 [22], 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 [22] clause 5.19.1) to redirect the UE to another
SGSN within the same dedicated CN.

A CN node should ensure that move operations does not overload the network. BSCs and RNCs shall be able to handle
situations where several CN nodes are off-loaded simultaneously.

4.5a.2 Network Mode of Operation = 1

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

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.

3GPP
Release 132T 14 3GPP TS 23.236 V13.0.0 (2015-06)

4.7 Default CN node and Backwards Compatibility

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

4.8.1 Attach
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

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.

3GPP
Release 132T 15 3GPP TS 23.236 V13.0.0 (2015-06)

4.9 VGCS/VBS Compatibility Issues

Voice Group Call Services, TS 43.068 [19], as well as Voice Broadcast Service, TS 43.069 [20], 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 [19]
and TS 43.069 [20].

4.10 Interactions with E-UTRAN

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 [22], TS 23.060 [2] and TS 23.003 [18] 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.

NOTE: ISR is specified and described in TS 23.401 [22].

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 [18] 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 [18] and TS 25.331 [5] 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 [18] 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.

5 Functional Description

5.1 MS Functions
In Iu mode the MS provides the IDNNS to the RNC in the access stratum part of the RRC_initial_DT message as
described in TS 25.331 [5].

If the MS is E-UTRAN capable, then TS 23.401 [22], TS 23.060 [2] and TS 23.003 [18] 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.
For the PS domain, the E-UTRAN capable MS shall use this P-TMSI parameter to derive the UTRAN IDNNS
parameter. For the CS domain, the E-UTRAN temporary identities shall not be used to derive the IDNNS: instead the
MS shall use its (MSC supplied) TMSI, if that TMSI is valid, to derive the IDNNS.

NOTE: movement of an E-UTRAN capable MS between GERAN/UTRAN and E-UTRAN accesses does not
cause the TMSI to be marked as invalid or deleted.

When the MS in Iu mode replies to IMSI paging, it shall derive IDNNS from (P)TMSI if a valid one is available. If
(P)TMSI is not available, the MS shall derive IDNNS from IMSI.

No further changes are expected in the MS for Gb or A interface mode.

3GPP
Release 132T 16 3GPP TS 23.236 V13.0.0 (2015-06)

5.2 RNC Functions

The RNC provides the NAS Node Selection Function. It masks the significant number of bits out of the IDNNS
provided by the MS together with the initial NAS signalling message. The significant number of bits is configured in
the RNC. The NAS Node Selection Function derives from the NRI the address of the specific CN node for the relevant
domain (CS or PS). The association between NRI values and CN node addresses is configured in the RNC (O&M).

The RNC routes the initial NAS signalling messages according to the NRI and the "domain indicator" (CS or PS) to the
relevant CN node if a CN node address is configured in the RNC for the specific NRI and the requested domain (CS or
PS).

When IDNNS is derived from the IMSI, the IDNNS has a value (V) from the range 0 to 999 as defined in TS 25.331 [5].
The RAN node shall be configured to use the value (V) to select a CN node. Each value (V) corresponds a single CN
node. Typically many values of (V) may point to the same CN node. In some networks, the RAN node may be
configured to select the MSC/VLR or SGSN for "UEs configured for low access priority" with a different load balance
to that used for MSC/VLR or SGSN selection for other UEs. In this case the RAN node maintains a second, separate
mapping table between value (V) and CN node for "UEs configured for low access priority".

If the selected CN node is not available or if no CN node address is configured in the RNC for the requested NRI or if
the provided identity contains no NRI then the RNC routes the initial NAS signalling message to a CN node selected
from the available CN nodes which serve the related domain (CS or PS). The selection mechanism is implementation
dependent and should enable load balancing between the available CN nodes. In some networks, the RNC may be
configured to select the MSC/VLR or SGSN for "UEs configured for low access priority" with a different load balance
to that used for MSC/VLR or SGSN selection for other UEs.

NOTE 1: A routing-area update after SRNS relocation is not an initial NAS signalling message, thus it is routed
along the existing Iu-connection to the SGSN.

NOTE 2: The RAN can determine whether or not the "MS is configured for low access priority" from information
received in the RRC establishment signalling.

In case a MSC sends a paging with IMSI (i.e. the paging message does not contain a TMSI), the RNC may, for
purposes to increase the paging success rate, upon reception temporarily store the Global-CN-ID of the node that issued
the paging message. If the MSC/VLR initiates the paging procedure via Gs-interface the SGSN has to add the Global-
CN-ID to the paging message.

5.2.1 Load Re-Distribution function in RNC

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.

5.3 BSC Functions

5.3.1 A interface mode
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

3GPP
Release 132T 17 3GPP TS 23.236 V13.0.0 (2015-06)

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.

NOTE: The BSC can determine whether or not the "MS is configured for low access priority" from information
contained in the Initial Layer 3 message. Using a different load balance for "MSs configured for low
access priority" might be useful if some MSCs have a particularly large VLR capacity compared to their
relative processing power.

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.

5.3.2 Gb mode
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.

NOTE 1: For the selection mechanism in the BSC it is probably sufficient, that the algorithm is 'slow moving'. If
the selection algorithm changes the SGSN to be assigned for 'random TLLIs' or for 'foreign TLLIs' whose
NRI value is not used in the current SGSN pool area during a MS's Attach procedure or RA update
procedure, then the Attach procedure or RA update procedure is likely to fail, but the MS will reattempt
the procedure at T3310/T3330 expiry (=15 seconds).

NOTE 2: The BSC can determine whether or not the "MS is configured for low access priorityC" from information
contained in the RR Channel Request message.

NOTE 3: When performing special SGSN selection for "MSs configured for low access priority", it is necessary to
ensure that all the Mobility Management signalling for that MS is routed to that special SGSN and not
routed to any other SGSN. Hence the requirement for the BSC to remember the "TLLI to SGSN"
relationship until the new SGSN has reallocated the TLLI.

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.

3GPP
Release 132T 18 3GPP TS 23.236 V13.0.0 (2015-06)

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

5.3.4 Load Re-Distribution function in BSC

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.

5.4 MSC Functions

5.4.1 TMSI Allocation
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.

5.4.2 Mobility Management and Handover/Relocation

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.

5.4.3 Backward Compatibility and Default MSC

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).

NOTE: It might be required to keep information on ongoing MAP dialogues in the default MSC.

5.4.4 Support of Combined Procedures

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.

5.4.5 Load Re-Distribution function in MSC

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.

3GPP
Release 132T 19 3GPP TS 23.236 V13.0.0 (2015-06)

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.

5.5 SGSN Functions

5.5.1 P-TMSI Allocation
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.

5.5.2 Mobility Management and Handover/Relocation

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.

5.5.3 Backward Compatibility and Default SGSN

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.

NOTE: It might be required to keep information on ongoing GTP dialogues in the default SGSN.

5.5.4 Support of Combined Procedures

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.

3GPP
Release 132T 20 3GPP TS 23.236 V13.0.0 (2015-06)

5.5.5 CS Paging
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.

5.5.6 Load Re-Distribution function in SGSN

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.

6 Application Examples
This clause describes some application examples for networks using the intra domain NAS node selection. In these
examples, pool-areas are depicted by boxes or ellipses, while the core network elements which serve the pool-areas are
depicted by the NRIs they have been assigned.

6.1 Network configuration example 1

This example configures 9 pool-areas each with 3 CN nodes serving within a pool-area. When a MS moves from one
(NRI:1,2,3) to another pool-area (NRI:4,5,6). It indicates the old NRI (3) derived from its old TMSI to the RNC in the
new pool-area (NRI:4,5,6). This NRI 3 is not configured in the RNC of the pool-area (NRI:4,5,6). The RNC selects a
CN node out of the available NRIs 4,5,6 and establishes the signalling connection for the MS with the selected CN node.
This new CN nodes allocates a new TMSI to the MS and thereby the new NRI for the new pool-area.

In this example, the NRIs can be re-used in a pattern where adjacent pool areas do not use the same NRI. Every pool
area change will initiate a new selection of a new CN node.

NRI: NRI: NRI:

19, 20, 21 22, 23, 24 25, 26, 27

NRI: NRI: NRI:

16, 17, 18 1, 2, 3 4, 5, 6

NRI: NRI: NRI:

13, 14, 15 10, 11, 12 7, 8, 9

Figure 2: Network configuration example 1

6.2 Network configuration example 2

This example shows a network covering one city centre surrounded by residential areas. The city centre is covered by
all 4 pool-areas while each of the residential areas is covered by one pool-area only. Once a MS „found" its pool-area, it
will not change the pool-area while commuting between the city centre and its residential area. Each of the pool-areas is
served by 5 MSCs, indicated by the 5 NRI values in the figure below, which share the load within the pool-area. Only

3GPP
Release 132T 21 3GPP TS 23.236 V13.0.0 (2015-06)

distinct NRI values are used for the overlapping pool-areas. Therefore, a MS changing between these pool-areas will
always be allocated to a new MSC by the NAS node selection function. In addition it is shown, that the NRIs can be re-
used in other pool-areas as indicated in the figure by the smaller areas with only one NRI. Also at a change to these
areas the MSs will always be allocated to a new MSC by the NAS node selection function as adjacent areas do not use
the same NRI values.

A calculation for the possible number of subscribers in this scenario is in Annex A.1: One city centre surrounded by
residential areas

Reuse NRI: 11 NRI:

16,17,18,19,20

NRI: 1,2,3,4,5 city NRI: 11,12,13,14,15

centre

NRI: 6,7,8,9,10
Reuse NRI: 1

Figure 3: Network configuration example 3

7 Specific Examples
This chapter describes specific examples of Iu Flex. First, building blocks of Iu Flex are described in 7.1. These
building blocks are then used in signalling flows starting from 7.2.

The changes to the signalling flows are indicated in italic.

7.1 Building blocks for signalling flows

7.1.1 RAN node selecting CN node in A interface mode

7.1.2 RAN node selecting CN node in Gb interface mode

7.1.3 RAN node selecting CN node in Iu interface mode

7.1.4 New CN node selecting old CN node

This building block describes how a new CN node selects the old CN node which was previously serving the MS. The
new CN node has been allocated to serve the MS, and it may have to communicate with the old CN node e.g. in order to
get IMSI of the MS or to get MM and PDP contexts of the MS.

3GPP
Release 132T 22 3GPP TS 23.236 V13.0.0 (2015-06)

7.1.5 Old CN node selecting new CN node

This building block describes how the old CN node selects a new CN node which starts to serve the MS. The old CN
node has to select a new CN node e.g. when performing handover.

7.1.6 SGSN selecting MSC

7.2 Signalling flow for Attach (Iu interface mode)

At attach, the RNC selects an SGSN to serve the MS. The attach procedure is shown in the figure below.

new old
MS UTRAN new SGSN old SGSN GGSN EIR MSC/VLR HLR MSC/VLR
INITIAL_DT RANAP-INITIAL_UE

1. Attach Request
2. Identification Request

2. Identification Response
3. Identity Request

3. Identity Response

4. Authentication

5. IMEI Check

6a. Update Location

6b. Cancel Location

6c. Cancel Location Ack

6d. Insert Subscriber Data

6e. Insert Subscriber Data Ack

6f. Update Location Ack

7a. Location Update Request

7b. Update Location

7c. Cancel Location

7d. Cancel Location Ack

7e. Insert Subscriber Data

7f. Insert Subscriber Data Ack

7g. Update Location Ack

7h. Location Update Accept

C1
8. Attach Accept

9. Attach Complete
10. TMSI Reallocation Complete

Figure 4: Signalling flow for Attach (Iu interface mode)

3GPP
Release 132T 23 3GPP TS 23.236 V13.0.0 (2015-06)

1) The Attach Request (old P-TMSI, old RAI, old P-TMSI Signature) is carried in the Initial Direct Transfer
message (RRC) from the MS to the RNC. The RNC selects an SGSN to serve the MS as described in
clause 7.1.3 and relays the Attach Request to the SGSN in the Initial UE message (RANAP).

2) If the MS identifies itself with P-TMSI and the SGSN has changed since detach, the new SGSN sends an
Identification Request (P-TMSI, old RAI, old P-TMSI Signature) to the old SGSN to request the IMSI. The new
SGSN selects the old SGSN as described in clause 7.1.4. The old SGSN responds with Identification Response
(IMSI, Authentication Triplets (for GPRS) or Authentication Vectors (for UMTS)). If the MS is not known in
the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN also validates the old
P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old
SGSN.

3) If the MS is unknown in both the old and new SGSN, the SGSN sends an Identity Request (Identity Type =
IMSI) to the MS. The MS responds with Identity Response (IMSI).

4) The authentication functions are defined in the clause "Security Function" of TS 23.060 [2]. If no MM context
for the MS exists anywhere in the network, then authentication is mandatory. Ciphering procedures are described
in clause "Security Function" of TS 23.060 [2]. If P-TMSI allocation is going to be done and the network
supports ciphering, the network shall set the ciphering mode.

5) The equipment checking functions are defined in the clause "Identity Check Procedures" of TS 23.060 [2].
Equipment checking is optional.

6) If the SGSN number has changed since the GPRS detach, or if it is the very first attach, then the SGSN informs
the HLR:

a) The SGSN sends an Update Location (SGSN Number, SGSN Address, IMSI) to the HLR.

b) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to
Update Procedure.

c) The old SGSN acknowledges with Cancel Location Ack (IMSI). If there are any ongoing procedures for that
MS, the old SGSN shall wait until these procedures are finished before removing the MM and PDP contexts.

d) The HLR sends Insert Subscriber Data (IMSI, GPRS Subscription Data) to the new SGSN.

e) The new SGSN validates the MS's presence in the (new) RA. If due to regional subscription restrictions the
MS is not allowed to attach in the RA, the SGSN rejects the Attach Request with an appropriate cause, and
may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If subscription
checking fails for other reasons, the SGSN rejects the Attach Request with an appropriate cause and returns
an Insert Subscriber Data Ack (IMSI, Cause) message to the HLR. If all checks are successful then the SGSN
constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR.

f) The HLR acknowledges the Update Location message by sending an Update Location Ack to the SGSN after
the cancelling of old MM context and insertion of new MM context are finished. If the Update Location is
rejected by the HLR, the SGSN rejects the Attach Request from the MS with an appropriate cause.

7) If Attach Type in step 1 indicated GPRS Attach while already IMSI attached, or combined GPRS / IMSI
attached, then the VLR shall be updated if the Gs interface is installed. The VLR number is determined as
described in 7.1.6. The SGSN starts the location update procedure towards the new MSC/VLR upon receipt of
the first Insert Subscriber Data message from the HLR in step 6d). This operation marks the MS as GPRS-
attached in the VLR.

a) The SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type)
message to the VLR. Location Update Type shall indicate IMSI attach if Attach Type indicated combined
GPRS / IMSI attach. Otherwise, Location Update Type shall indicate normal location update. The VLR
creates an association with the SGSN by storing SGSN Number.

b) If the LA update is inter-MSC, the new VLR sends Update Location (IMSI, new VLR) to the HLR.

c) If the LA update is inter-MSC, the HLR sends a Cancel Location (IMSI) to the old VLR.

d) The old VLR acknowledges with Cancel Location Ack (IMSI).

3GPP
Release 132T 24 3GPP TS 23.236 V13.0.0 (2015-06)

e) If the LA update is inter-MSC, the HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the
new VLR.

f) The VLR acknowledges with Insert Subscriber Data Ack (IMSI).

g) After finishing the inter-MSC location update procedures, the HLR responds with Update Location Ack
(IMSI) to the new VLR.

h) The VLR responds with Location Update Accept (VLR TMSI) to the SGSN. An Iu Flex aware VLR includes
one of its (CS-)NRIs as part of VLR TMSI. The SGSN creates an association with the VLR by storing VLR
number.

8) The SGSN selects Radio Priority SMS, and sends an Attach Accept (P-TMSI, VLR TMSI, P-TMSI Signature,
Radio Priority SMS) message to the MS. P-TMSI is included if the SGSN allocates a new P-TMSI. An Iu Flex
aware SGSN includes one of its (PS-)NRIs as part of P-TMSI.

9) If P-TMSI or VLR TMSI was changed, the MS acknowledges the received TMSI(s) by returning an Attach
Complete message to the SGSN.

10) If VLR TMSI was changed, the SGSN confirms the VLR TMSI re-allocation by sending a TMSI Reallocation
Complete message to the VLR.

7.3 Signalling flows for Service Request (Iu interface mode)

When performing service request, the signalling connection between the MS and the SGSN is re-established.

7.3.1 Service Request initiated by MS

The service request procedure initiated by the MS is shown in the figure below.

MS RNC SGSN HLR GGSN

1. RRC Connection Request
1. RRC Connection Setup

Initial_DT RANAP-INITIAL_UE
2. Service Request

3. Security Functions

4. Radio Access Bearer Assignment

Request
5. Radio Bearer Setup

6. Radio Bearer Setup

Complete
6. Radio Access Bearer Assignment
Response
7. SGSN-Initiated PDP Context Modification

8. Uplink PDU

Figure 5: Signalling flows for Service Request initiated by MS (Iu interface mode)

1) The MS establishes an RRC connection, if none exists for CS traffic.

2) The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type
specifies the requested service. Service Type shall indicate one of the following: Data or Signalling. The Service
Request is carried in the Initial Direct Transfer message (RRC) from the MS to the RNC. The RNC selects an

3GPP
Release 132T 25 3GPP TS 23.236 V13.0.0 (2015-06)

SGSN to serve the MS as described in 7.1.3 and relays the Service Request to the SGSN in the Initial UE
message (RANAP). At this point, the SGSN may perform the authentication procedure.

- If Service Type indicates Data, a signalling connection is established between the MS and the SGSN, and
resources for active PDP context(s) are allocated, i.e., RAB establishment for the activated PDP context(s).

- If Service Type indicates Signalling, the signalling connection is established between the MS and the SGSN
for sending upper-layer signalling messages, e.g., Activate PDP Context Request. The resources for active
PDP context(s) are not allocated.

3) The SGSN shall perform the security functions if the MS in PMM-IDLE state initiated the service request.

4) If the network is in PMM-CONNECTED state and the Service Type indicates Data, the SGSN shall respond
with a Service Accept message towards the MS, in case the service request can be accepted. In case Service
Type indicates Data, the SGSN sends a Radio Access Bearer Assignment Request (NSAPIRAB ID(s), TEID(s),
QoS Profile(s), SGSN IP Address(es)) message to re-establish radio access bearer for every activated PDP
context.

5) The RNC indicates to the MS the new Radio Bearer Identity established and the corresponding RAB ID with the
RRC radio bearer setup procedure.

6) SRNC responds with the Radio Access Bearer Assignment Response (RAB ID(s), TEID(s), QoS Profile(s), RNC
IP Address(es)) message. The GTP tunnel(s) are established on the Iu interface. If the RNC returns a Radio
Access Bearer Assignment Response message with a cause indicating that the requested QoS profile(s) can not
be provided, e.g., "Requested Maximum Bit Rate not Available", the SGSN may send a new Radio Access
Bearer Assignment Request message with different QoS profile(s). The number of re-attempts, if any, as well as
how the new QoS profile(s) values are determined is implementation dependent.

7) For each RAB re-established with a modified QoS profile, the SGSN initiates a PDP Context Modification
procedure to inform the MS and the GGSN of the new negotiated QoS profile for the corresponding PDP context.

8) The MS sends the uplink packet.

7.3.2 Service Request initiated by network

The service request procedure initiated by the network is shown in the figure below.

3GPP
Release 132T 26 3GPP TS 23.236 V13.0.0 (2015-06)

MS RNC SGSN HLR GGSN

1. Downlink PDU
2. Paging
2. Paging

3. RRC Connection Request

3. RRC Connection Setup

Initial_DT
RANAP-INITIAL_UE
4. Service Request
5. Security Functions

6. Radio Access Bearer Assignment

6. Radio Bearer Setup Request

6. Radio Bearer Setup

Complete 6. Radio Access Bearer Assignment
Response

7. SGSN-Initiated PDP Context Modification Procedure

8. Downlink PDU

Figure 6: Signalling flows for Service Request initiated by network (Iu interface mode)

1) The SGSN receives a downlink PDP PDU for an MS in PMM-IDLE state.

2) The SGSN sends a Paging message to the RNC. The RNC pages the MS by sending a Paging message to the MS.
See clause "PS Paging Initiated by 3G-SGSN without RRC Connection for CS" of TS 23.060 [2] for details.

3) The MS establishes an RRC connection if none exists for CS traffic.

4) The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type
specifies Paging Response. The Service Request is carried over the radio in an RRC Direct Transfer message.
The RNC selects an SGSN to serve the MS as described in 7.1.3 and relays the Service Request to the SGSN in
the Initial UE message (RANAP). At this point, the SGSN may perform the authentication procedure. The SGSN
knows whether the downlink packet requires RAB establishment (e.g., downlink PDU) or not (e.g., Request PDP
Context Activation or MT SMS).

5) The SGSN shall perform the security mode procedure.

6) If resources for the PDP contexts are re-established, the SGSN sends a Radio Access Bearer Assignment Request
(RAB ID(s), TEID(s), QoS Profile(s), SGSN IP Address(es)) message to the RNC. The RNC sends a Radio
Bearer Setup (RAB ID(s)) to the MS. The MS responds by returning a Radio Bearer Setup Complete message to
the RNC. The RNC sends a Radio Access Bearer Assignment Response (RAB ID(s), TEID(s), RNC IP
Address(es)) message to the SGSN in order to indicate that GTP tunnels are established on the Iu interface and
radio access bearers are established between the RNC and the MS. If the RNC returns a Radio Access Bearer
Assignment Response message with a cause indicating that the requested QoS profile(s) can not be provided, e.g.,
"Requested Maximum Bit Rate not Available", the SGSN may send a new Radio Access Bearer Assignment
Request message with different QoS profile(s). The number of re-attempts, if any, as well as how the new QoS
profile(s) values are determined is implementation dependent.

7) For each RAB re-established with a modified QoS profile, the SGSN initiates a PDP Context Modification
procedure to inform the MS and the GGSN of the new negotiated QoS profile for the corresponding PDP context.

8) The SGSN sends the downlink packet.

3GPP
Release 132T 27 3GPP TS 23.236 V13.0.0 (2015-06)

7.4 Signalling flow for Routing Area Update (Iu interface mode)
The routing area update procedure is shown in the figure below.

3GPP
Release 132T 28 3GPP TS 23.236 V13.0.0 (2015-06)

new old new old

MS UTRAN 3G-SGSN 3G-SGSN GGSN MSC/VLR HLR MSC/VLR
INITIAL-DT RANAP-INITIAL_UE

1. Routeing Area Update Request

2. SGSN Context Request

2a. SRNS Context Request C1

2a. SRNS Context Response

2. SGSN Context Response

3. Security Functions

4. SGSN Context Ack

C2

5. Update PDP Context Request

5. Update PDP Context Response

6. Update Location

7. Cancel Location
7a. Iu Release Command

7a. Iu Release Complete

7. Cancel Location Ack

8. Insert Subscriber Data

8. Insert Subscriber Data Ack

9. Update Location Ack

10. Location Update Request

11a. Update Location
11b. Cancel Location

11c. Cancel Location Ack

11d. Insert Subscriber Data

11e. Insert Subscriber Data Ack

11f. Update Location Ack

12. Location Update Accept

C2

13. Routeing Area Update Accept

C3

14. Routeing Area Update Complete

15. TMSI Reallocation Complete

Figure 7: Signalling flow for Routing Area Update (Iu interface mode)

3GPP
Release 132T 29 3GPP TS 23.236 V13.0.0 (2015-06)

1) The RRC connection is established, if not already done. The Routeing Area Update Request (old P-TMSI, old
RAI, old P-TMSI Signature) is carried in the Initial Direct Transfer message (RRC) from the MS to the RNC.
The RNC selects an SGSN to serve the MS as described in 7.1.3 and relays the Routeing Area Update Request to
the SGSN in the Initial UE message (RANAP).

2) If the RA update is an Inter-SGSN Routeing area update and if the MS was in PMM-IDLE state, the new SGSN
sends an SGSN Context Request message (old P-TMSI, old RAI, old P-TMSI Signature) to the old SGSN to get
the MM and PDP contexts for the MS. The new SGSN selects the old SGSN as described in 7.1.4. The old
SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the
value stored in the old SGSN. This should initiate the security functions in the new SGSN. If the security
functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (IMSI, old RAI,
MS Validated) message to the old SGSN. MS Validated indicates that the new SGSN has authenticated the MS.
If the old P-TMSI Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old
SGSN responds with SGSN Context Response (Cause, IMSI, MM Context, PDP contexts). If the MS is not
known in the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN starts a timer.
The new SGSN shall ignore the MS Network Capability contained in MM Context of SGSN Context Response
only when it has previously received an MS Network Capability in the Routeing Area Request.

a) If the MS is PMM-CONNECTED in the old 3G-SGSN, the old SGSN shall send an SRNS Context Request
(IMSI) message to the old SRNS to retrieve the sequence numbers for the PDP context for inclusion in the
SGSN Context Response message from the SRNS. Upon reception of this message, the SRNS buffers and
stops sending downlink PDUs to the MS and returns an SRNS Context Response (IMSI, GTP-SNDs,
GTP-SNUs, PDCP-SNUs) message. The SRNS shall include for each PDP context the next in-sequence GTP
sequence number to be sent to the MS and the GTP sequence number of the next uplink PDU to be tunnelled
to the GGSN. For each active PDP context using acknowledged mode, the SRNS also includes the uplink
PDCP sequence number (PDCP-SNU). PDCP-SNU shall be the next in-sequence PDCP sequence number
expected from the MS (per each active radio bearer).

3) Security functions may be executed. These procedures are defined in clause "Security Function" of
TS 23.060 [2]. If the security functions do not authenticate the MS correctly, the routeing area update shall be
rejected, and the new SGSN shall send a reject indication to the old SGSN. The old SGSN shall continue as if
the SGSN Context Request was never received.

4) If the RA update is an Inter-SGSN Routeing area update, the new SGSN sends an SGSN Context Acknowledge
message to the old SGSN. The old SGSN marks in its context that the MSC/VLR association and the
information in the GGSNs and the HLR are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be
updated if the MS initiates a routeing area update procedure back to the old SGSN before completing the
ongoing routeing area update procedure.

5) If the RA update is an Inter-SGSN RA Update and if the MS was in PMM-IDLE state, the new SGSN sends
Update PDP Context Request (new SGSN Address, QoS Negotiated, Tunnel Endpoint Identifier) to the GGSNs
concerned. The GGSNs update their PDP context fields and return an Update PDP Context Response (Tunnel
Endpoint Identifier). Note: If the RA update is an Inter-SGSN routeing area update initiated by an MS in
PMM-CONNECTED state, the Update PDP Context Request message is sent as described in clause "Serving
RNS Relocation Procedures" of TS 23.060 [2].

6) If the RA update is an Inter-SGSN RA Update, the new SGSN informs the HLR of the change of SGSN by
sending Update Location (SGSN Number, SGSN Address, IMSI) to the HLR.

7) If the RA update is an inter-SGSN RA Update, the HLR sends Cancel Location (IMSI, Cancellation Type) to the
old SGSN with Cancellation Type set to Update Procedure. If the timer described in step 2 is not running, the old
SGSN removes the MM context. Otherwise, the contexts are removed only when the timer expires. It also
ensures that the MM context is kept in the old SGSN in case the MS initiates another inter SGSN routeing area
update before completing the ongoing routeing area update to the new SGSN. The old SGSN acknowledges with
Cancel Location Ack (IMSI).

a) If the MS is PMM-CONNECTED in the old 3G-SGSN, the old 3G-SGSN sends an Iu Release Command
message to the old SRNC. The SRNC responds with an Iu Release Complete message.

8) If the RA update is an inter-SGSN RA Update, the HLR sends Insert Subscriber Data (IMSI, subscription data)
to the new SGSN. The new SGSN validates the MS's presence in the (new) RA. If due to regional subscription
restrictions the MS is not allowed to be attached in the RA, the SGSN rejects the Routeing Area Update Request
with an appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message

3GPP
Release 132T 30 3GPP TS 23.236 V13.0.0 (2015-06)

to the HLR. If all checks are successful, the SGSN constructs an MM context for the MS and returns an Insert
Subscriber Data Ack (IMSI) message to the HLR.

9) If the RA update is an Inter-SGSN RA Update, the HLR acknowledges the Update Location by sending Update
Location Ack (IMSI) to the new SGSN.

10) If Update Type indicates combined RA / LA update with IMSI attach requested, or if the LA changed with the
routeing area update, the association has to be established. The VLR number is determined as described in 7.1.6.
The new SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) to the
VLR. Location Update Type shall indicate IMSI attach if Update Type in step 1 indicated combined RA / LA
update with ISI attach requested. Otherwise, Location Update Type shall indicate normal location update. The
SGSN starts the location update procedure towards the new MSC/VLR upon receipt of the first Insert Subscriber
Data message from the HLR in step 8). The VLR creates or updates the association with the SGSN by storing
SGSN Number.

11) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The
HLR cancels the old VLR and inserts subscriber data in the new VLR (this signalling is not modified from
existing GSM signalling and is included here for illustrative purposes):

a) The new VLR sends an Update Location (new VLR) to the HLR.

b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR.

c) The old VLR acknowledges with Cancel Location Ack (IMSI).

d) The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR.

e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI).

f) The HLR responds with Update Location Ack (IMSI) to the new VLR.

12) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the SGSN.
VLR TMSI is optional if the VLR has not changed. An Iu Flex aware VLR includes one of its (CS-)NRIs as part
of VLR TMSI. The SGSN creates an association with the VLR by storing VLR number.

13) The new SGSN validates the MS's presence in the new RA. If due to roaming restrictions the MS is not allowed
to be attached in the SGSN, or if subscription checking fails, the SGSN rejects the routeing area update with an
appropriate cause. If all checks are successful, the new SGSN establishes MM context for the MS. The new
SGSN responds to the MS with Routeing Area Update Accept (P-TMSI, VLR TMSI, P-TMSI Signature). An Iu
Flex aware SGSN includes one of its (PS-)NRIs as part of P-TMSI.

14) The MS confirms the reallocation of the TMSIs by returning a Routeing Area Update Complete message to the
SGSN.

15) The new SGSN sends a TMSI Reallocation Complete message to the new VLR if the MS confirms the VLR
TMSI.

7.5 IMSI attach procedure / Location area update with IMSI

This signalling flow shows the basic IMSI attach or location update procedure when a UMTS UE registers to a pool-
area by mobile identity type IMSI.

3GPP
Release 132T 31 3GPP TS 23.236 V13.0.0 (2015-06)

UE RNC New MSC old MSC HLR

1. Initial_DT( IDNNS = “routing parameter derived from IMSI”)

2. Inital_UE

3. Security Functions

4a. Update Location

4b. Cancel Location

4c. Cancel Location Ack

4d. Insert Subscriber Data

4e. Insert Subscriber Data Ack

4f. Update Location Ack

5. Direct_Transfer(NAS_PDU(TMSI(NRI)))

6. Downlink_DT (NAS_PDU(TMSI(NRI)))

7. Uplink_DT(NAS_PDU)

8. Direct_Transfer(NAS_PDU)

Figure 8: IMSI attach procedure / Location area update with IMSI

1) UE requests the setup of the RRC connection and sends the Initial_DT including the Intra Domain NAS Node
Selector (IDNNS). The IDNNS indicates that the routing parameter is derived from IMSI.

2) The RNC selects the MSC as described in 7.1.3. The Initial-UE message is generated on RANAP and sent via
Iu-CS to the selected MSC/VLR.

3) The optional security functions can be executed.

4) Since the UE wasn't registered in the MSC before the Map Update-location procedure to HLR is invoked by the
MSC:

a) The update-location is sent to HLR;

b) In case the UE was registered in another VLR the HLR sends cancel location procedure to old VLR;

c) The old VLR acknowledges with Cancel location Ack;

d) The HLR sends insert-subscriber data to the new VLR;

e) The new VLR acknowledges with insert-subscriber data Ack;

f) After finishing the location update procedure the HLR responds with Update-location to the new VLR.

5) The MSC/VLR assigns a new TMSI to the UE and sends this TMSI value in the location-update accept to the
UE. The TMSI contains the NRI of the VLR. The location update accept is carried in the NAS-PDU of the
RANAP direct-transfer over Iu interface.

3GPP
Release 132T 32 3GPP TS 23.236 V13.0.0 (2015-06)

6) The RNC transparently forwards the NAS-PDU to the UE in the RRC downlink-DT message.

7) In the UE the new TMSI (including the NRI) and the LA are stored on SIM and the TMSI-reallocation complete
is generated. This NAS message is returned to CN in the Uplink-DT via RRC. The mobile shall use this new
TMSI next time it performs a mobile originating procedure.

8) The RNC forwards the NAS-PDU transparently to the MSC/VLR in the NAS-PDU of a Direct-transfer on Iu
interface. If the TMSI-reallocation complete is received in the MSC/VLR the TMSI is considered as valid for the
UE. From then on the UE will be addressed using this TMSI value.

3GPP
Release 132T 33 3GPP TS 23.236 V13.0.0 (2015-06)

Annex A (informative):
Network configuration examples
Editor's note: This annex contains the examples for network configurations that have been discussed during the
drafting meetings.

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.

Reuse NRI: 11 NRI:

16,17,18,19,20

NRI: 1,2,3,4,5
NRI: 11,12,13,14,15

NRI: 6,7,8,9,10
Reuse NRI: 1

Figure 9: One city centre surrounded by residential areas

3GPP
 Release 132T 34 3GPP TS 23.236 V13.0.0 (2015-06)

A.1.2. TMSI calculation

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.

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.

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

CS/
PS 'VLR-restart' used NRI range

Figure 10: Example of a TMSI structure with 5 bit 'VLR-restart counter' and 5 bits NRI-length

'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.

3GPP
Release 132T 35 3GPP TS 23.236 V13.0.0 (2015-06)

- 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!

Pool 2
NRI: 32..63
TMSI: x0100000xx
-
Pool 1 x0111111xx

NRI: 0..31
TMSI: x0000000xx Pool 3
-
x0011111xx NRI: 64..95
TMSI: x1000000xx
-
x1011111xx

NRI: 96..127
TMSI: x1100000xx - x1111111xx
are unused

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

CS/
PS 'VLR- used NRI range
restart'

Figure 11: Modified TMSI structure 7 bits NRI-length; VLR-restart field must be reduced to 3 bit

- 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

3GPP
Release 132T 36 3GPP TS 23.236 V13.0.0 (2015-06)

Pool 2
NRI: 0..7 & 32..55
TMSI: x0000000xx -
x0000111xx &
x0100000xx
Pool 1 -
x0110111xx
NRI: 0..31
TMSI: x0000000xx
- Pool 3
x0011111xx
NRI: 0..7 & 56..79
TMSI: x0000000xx -
x0000111xx &
x0111000xx
-
x1001111xx

NRI: 80..127
TMSI: x1010000xx - x1111111xx
are unused

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

CS/
PS 'VLR- used NRI range
restart'

Figure 12: Modified TMSI structure 7 bits NRI-length; VLR-restart field must remain 3 bit.

'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

3GPP
 Release 132T 37 3GPP TS 23.236 V13.0.0 (2015-06)

Pool 2
NRI: 0..15 & 32..47
TMSI: x000000xx -
x001111xx &
x010000xx
Pool 1 -
x101111xx
NRI: 0..31
TMSI: x000000xx
- Pool 3
x011111xx
NRI: 0..15 & 48..63
TMSI: x000000xx -
x001111xx &
x110000xx
-
x111111xx

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

CS/
PS 'VLR-restart' used NRI range

Figure 13: NRI-length can be reduced by 1 bit; VLR-restart field can increase to 4 bit.

'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

3GPP
 Release 132T 38 3GPP TS 23.236 V13.0.0 (2015-06)

Pool 2
NRI: 0..23 & 32..39
TMSI: x000000xx -
x010111xx &
x100000xx
Pool 1 -
x101001xx
NRI: 0..31
TMSI: x000000xx
- Pool 3
x011111xx
NRI: 0..23 & 40..47
TMSI: x000000xx -
x010111xx &
x101010xx
-
x101111xx

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

CS/
PS 'VLR-restart' used NRI range

Figure 14: NRI-length can be reduced by 1 bit; VLR-restart field can increase to 4 bit.

'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).

3GPP
Release 132T 39 3GPP TS 23.236 V13.0.0 (2015-06)

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

CS/
PS 'VLR-restart' used NRI range

Figure 15: TMSI example for TMSI allocation per VLR; 32M TMSI/pool;

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.

A.3 Support of Dedicated Core Networks

An overview of dedicated core network (DCN) feature is provided in TS 23.401 [22]. 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.

3GPP
Release 132T 40 3GPP TS 23.236 V13.0.0 (2015-06)

pool area 1 pool area 2

CNs with NRIs: CNs with NRIs:

A1: 1, 2, 3 A1: 4, 5, 6
A2: 10, 11 A2: 12, 13
B1: 100, 101 B1: 102, 103
B2: 110, 111 B2: 112, 113

NNSF (selects a new node) U

Input NRI -> select from CN
4, 5, 6 -> A1 {1, 2, 3} UE with NRI 4 changes to
12, 13 -> A2 {10, 11} pool area 1
102, 103 -> B1 {100, 101} NNSF of pool area 1 knows:
112, 113 -> B2 {110, 111} NRI 4 belongs to CN A1
and selects a new CN node
from A1 {1, 2, 3}

Figure A.3-1: Example NNSF configuration to support DCN

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 [22]).

3GPP
Release 132T 41 3GPP TS 23.236 V13.0.0 (2015-06)

Annex B (informative):
Change history
Change history
Date TSG # TSG Doc. CR Rev Cat Subject/Comment Old New
2010-03 SA#47 SP-100162 0039 1 F Inclusion of informative reference to FS_IDC study work 9.0.0 10.0.0
2010-09 SA#49 SP-100553 0041 1 B M2M related updates 10.0.0 10.1.0
2010-12 SA#50 SP-100688 0042 1 F Extra text on NNSF for MTC 10.1.0 10.2.0
2010-12 SA#50 SP-100691 0046 2 F Iu/A Flex - Subsequent Inter-MSC Handover Interactions 10.1.0 10.2.0
2011-01 - - - - - Update of LTE logo to LTE-Advanced logo 10.2.0 10.2.1
2012-03 SA#55 SP-120074 0048 2 F Corrected MTC terminology 10.2.1 10.3.0
2012-06 SA#57 SP-120486 0049 3 F Gs Support for MSC in Pool to avoid dual VLR registration. 10.3.0 11.0.0
2013-06 SA#60 SP-130232 0050 3 C Use of Low Access Priority Indication (LAPI) to select 11.0.0 12.0.0
SGSN for PS domain
2015-06 SA#68 SP-150234 0051 3 B Update of MME load balancing for Dedicated Core 12.0.0 13.0.0
Networks
2015-06 SA#68 SP-150234 0053 2 B Load re-balancing for SGSNs with Dedicated Core 12.0.0 13.0.0
Networks

3GPP