ETSI TS 123 236 V17.0.0 (2022-04)

Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes (3GPP TS 23.236 version 17.0.0 Release 17)

RTS/TSGS-0223236vh00

General Information

• Status: Not Published
• Technical Committee: 3GPP SA 2 - Architecture
• Current Stage: 12 - Completion
• Completion Date: 05-Apr-2022

Standards Content (Sample)

TECHNICAL SPECIFICATION
Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS);
LTE;
Intra-domain connection of Radio Access Network (RAN)
nodes to multiple Core Network (CN) nodes
(3GPP TS 23.236 version 17.0.0 Release 17)

3GPP TS 23.236 version 17.0.0 Release 17 1 ETSI TS 123 236 V17.0.0 (2022-04)

Reference
RTS/TSGS-0223236vh00
Keywords
GSM,LTE,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.
ETSI
3GPP TS 23.236 version 17.0.0 Release 17 2 ETSI TS 123 236 V17.0.0 (2022-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TS 23.236 version 17.0.0 Release 17 3 ETSI TS 123 236 V17.0.0 (2022-04)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
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
ETSI
3GPP TS 23.236 version 17.0.0 Release 17 4 ETSI TS 123 236 V17.0.0 (2022-04)
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
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 . 33
A.2 3 Neighbouring large city centres . 35
A.3 Support of Dedicated Core Networks. 42
Annex B (informative): Change history . 44
History . 45

ETSI
3GPP TS 23.236 version 17.0.0 Release 17 5 ETSI TS 123 236 V17.0.0 (2022-04)
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.
ETSI
3GPP TS 23.236 version 17.0.0 Release 17 6 ETSI TS 123 236 V17.0.0 (2022-04)
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)".
ETSI
3GPP TS 23.236 version 17.0.0 Release 17 7 ETSI TS 123 236 V17.0.0 (2022-04)
[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
ETSI
3GPP TS 23.236 version 17.0.0 Release 17 8 ETSI TS 123 236 V17.0.0 (2022-04)
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.
ETSI
3GPP TS 23.236 version 17.0.0 Release 17 9 ETSI TS 123 236 V17.0.0 (2022-04)
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.
MSC 3 MSC 6
MSC 2 MSC 5
MSC 1 MSC 4 MSC 7
CS pool-
CS pool-
area 2
area 1
RAN RAN RAN RAN
node node node node
Area 1 Area 2 Area 3 Area 4
RAN RAN RAN RAN
node node node node
Area 5 Area 6 Area 7 Area 8
PS pool-area 1 PS pool-area 2
SGSN 1 SGSN 3 SGSN 6
SGSN 2 SGSN 4
SGSN 5
Figure 1: Pool-area configuration example
ETSI
3GPP TS 23.236 version 17.0.0 Release 17 10 ETSI TS 123 236 V17.0.0 (2022-04)
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.
ETSI
3GPP TS 23.236 version 17.0.0 Release 17 11 ETSI TS 123 236 V17.0.0 (2022-04)
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
ETSI
3GPP TS 23.236 version 17.0.0 Release 17 12 ETSI TS 123 236 V17.0.0 (2022-04)
handover/relocation target. The mechanism for distribution of the traffic between the handover/relocation target CN
nodes is implementation specific. This load balancing is complemented by the NAS Node selection Function in the
RAN, which distributes MSs between the CN nodes when these MSs enter the pool-area in idle mode.
As more than one SGSN may send downlink data at the same time for a cell or a BVCI the total possible downlink
traffic has to shared between the SGSNs as described in clause 5.3.2.
When dedicated core networks (DCNs) are used, load balancing by RNC/BSC is only performed between SGSNs that
belong to the same DCN within the same SGSN pool area. Load balancing may also be performed per DCN in the case
of an SGSN serving multiple DCNs when one DCN is supported by multiple SGSNs. The DCN Load Balancing
functionality permits UEs that are entering into a pool area and being re-directed to an appropriate DCN to be
distributed in a manner that achieves load balancing between the core network nodes of the same DCN within the same
SGSN pool area. An example of NRI configuration that can achieve this is when DCNs are used is provided in
clause A.3.
In case of CS domain subsequent handover/relocation, if the controlling MSC supports Intra Domain Connection of
RAN Nodes to Multiple CN Nodes then it should check the target indicated by the serving MSC. If it is in its own pool
area then the handover/relocation is handled as one back to the controlling MSC (the target MSC indicated by the
serving MSC is not taken into account). If the target location is not in its own pool area then the target MSC indicated
by the serving MSC is taken into account as normal (handover/relocation to a third MSC).
If the controlling (anchor) MSC is not in the same pool as target third MSC and if the controlling MSC does not support
Intra Domain Connection of RAN Nodes to Multiple CN nodes, because the serving MSC can select any third MSC in
the target pool area, the operator should configure the addresses of all possible third MSCs within the controlling MSC
...