ts_ MSC pool

7/29/2019 ts_ MSC pool

1/37

ETSI TS 123 236 V6.0.0 (2004-12)Technical Specification

Digital cellular telecommunications system (Phase 2+);Universal Mobile Telecommunications System (UMTS);

Intra-domain connection of Radio Access Network (RAN)nodes to multiple Core Network (CN) nodes

(3GPP TS 23.236 version 6.0.0 Release 6)

GLOBAL SYSTEM FOR

MOBILE COMMUNICATIONS

R


2/37

ETSI

ETSI TS 123 236 V6.0.0 (2004-12)13GPP TS 23.236 version 6.0.0 Release 6

ReferenceRTS/TSGS-0223236v600

Keywords

GSM, UMTS

ETSI

650 Route des LuciolesF-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N348 623 562 00017 - NAF 742 CAssociation but non lucratif enregistre laSous-Prfecture de Grasse (06) N7803/88

Important notice

Individual copies of the present document can be downloaded from:http://www.etsi.org

The present document may be made available in more than one electronic version or in print. In any case of existing orperceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drivewithin ETSI Secretariat.

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

http://portal.etsi.org/tb/status/status.asp

If you find errors in the present document, please send your comment to one of the following services:http://portal.etsi.org/chaircor/ETSI_support.asp

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.

European Telecommunications Standards Institute 2004.All rights reserved.

DECTTM

, PLUGTESTSTM

and UMTSTM

are Trade Marks of ETSI registered for the benefit of its Members.TIPHON

TMand the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.

3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
http://www.etsi.org/http://www.etsi.org/http://portal.etsi.org/tb/status/status.asphttp://portal.etsi.org/tb/status/status.asphttp://portal.etsi.org/chaircor/ETSI_support.asphttp://portal.etsi.org/chaircor/ETSI_support.asphttp://portal.etsi.org/tb/status/status.asphttp://www.etsi.org/


3/37

ETSI


Intellectual Property Rights

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information

pertaining to these essential IPRs, if any, is 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 inrespect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web

server (http://webapp.etsi.org/IPR/home.asp).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guaranteecan 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.

Foreword

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, UMTS identitiesorGSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under

http://webapp.etsi.org/key/queryform.asp .
http://webapp.etsi.org/IPR/home.asphttp://webapp.etsi.org/IPR/home.asphttp://webapp.etsi.org/key/queryform.asphttp://webapp.etsi.org/key/queryform.asphttp://webapp.etsi.org/IPR/home.asp


4/37

ETSI


Contents

Intellectual Property Rights................................................................................................................................2

Foreword.............................................................................................................................................................2Foreword.............................................................................................................................................................5

Introduction ........................................................................................................................................................5

1 Scope ........................................................................................................................................................6

2 References ................................................................................................................................................6

3 Definitions, symbols and abbreviations ...................................................................................................73.1 Definitions..........................................................................................................................................................73.2 Symbols..............................................................................................................................................................73.3 Abbreviations ................................................................ ........................................................ .............................7

4 General Description..................................................................................................................................74.1 Iu Flex Technical Requirements.................................. .................................................................... ...................74.2 Overview ........................................................... .......................................................... .......................................84.3 Pool-Area and Network Resource Identification........................ ............................................................... .........94.4 NAS Node Selection Function ...................................................................... ...................................................104.5 Load Balancing ............................................................ ........................................................ ............................114.6 Mobility Management ......................................................... ........................................................... ..................114.7 Default CN node and Backwards Compatibility ........................................................................... ...................114.8 Support of combined mobility management procedures .................................................... ..............................124.8.1 Attach..........................................................................................................................................................124.8.2 Routing area update ............................................................ ...................................................... ..................12

5 Functional Description ...........................................................................................................................125.1 MS Functions ......................................................... .............................................................. ............................12

5.2 RNC Functions........................................................... .......................................................... ............................125.3 BSC Functions.................................................. ............................................................ ....................................135.3.1 A interface mode......................................... ........................................................ ........................................135.3.2 Gb mode ................................................. ........................................................ ............................................135.3.3 Iu mode................................................... ........................................................ ............................................145.4 MSC Functions........................... ........................................................... ......................................................... ..145.4.1 TMSI Allocation............................................................ .......................................................... ...................145.4.2 Mobility Management and Handover/Relocation................................................................. ......................145.4.3 Backward Compatibility and Default MSC............................................................. ...................................145.4.4 Support of Combined Procedures ............................................ .................................................. .................155.5 SGSN Functions ............................................................... ............................................................. ...................155.5.1 P-TMSI Allocation ....................................................... ............................................................ ..................15

5.5.2 Mobility Management and Handover/Relocation................................................................. ......................155.5.3 Backward Compatibility and Default SGSN ................................................................................ ..............155.5.4 Support of Combined Procedures ............................................ .................................................. .................155.5.5 CS Paging .................................................... ....................................................... ........................................15

6 Application Examples ............................................................................................................................166.1 Network configuration example 1 ............................................................ ........................................................166.2 Network configuration example 2 ............................................................ ........................................................16

7 Specific Examples ..................................................................................................................................177.1 Building blocks for signalling flows .................................................... ............................................................177.1.1 RAN node selecting CN node in A interface mode ........................................................ ............................177.1.2 RAN node selecting CN node in Gb interface mode ......................................................... .........................177.1.3 RAN node selecting CN node in Iu interface mode........................... .........................................................17

7.1.4 New CN node selecting old CN node ..................................................... ................................................... .177.1.5 Old CN node selecting new CN node ................................................. ....................................................... .177.1.6 SGSN selecting MSC............................................................ ............................................................. .........187.2 Signalling flow for Attach (Iu interface mode) ........................................................... .....................................18


5/37

ETSI


7.3 Signalling flows for Service Request (Iu interface mode)....................................... .........................................207.3.1 Service Request initiated by MS.......... ............................................................................. ..........................207.3.2 Service Request initiated by network.............................................................................. ............................217.4 Signalling flow for Routing Area Update (Iu interface mode).............................................................. ...........227.5 IMSI attach procedure / Location area update with IMSI ..................................................................... ...........25

Annex A (informative): Network configuration examples..................................................................28A.1 One city centre surrounded by residential areas.....................................................................................28A.1.1 Assumptions...................................................... .......................................................... .....................................28A.1.2 TMSI calculation....... ................................................................. ........................................................... ...........29

A.2 3 Neighbouring large city centres ..........................................................................................................29

Annex B (informative): Change history ...............................................................................................35

History ..............................................................................................................................................................36


6/37

ETSI


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 formalTSG 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 which 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 ofscalability, distributing the network load amongst the serving entities, and reducing the required signalling as the user

roams.


7/37

ETSI


1 Scope

This document covers the details for the Intra Domain Connection of RAN Nodes to Multiple CN Nodes for GSM and

UMTS 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 thedetailed impacts on the existing specifications are identified.

The reference model to which these procedures apply can be found within 3GPP TS 23.002 [1]. Detailed architectural

requirements within the subsystems are contained within the remainder of the 23 series of specifications e.g. therequirements for the Packet Switched (PS) domain are contained within 3GPP TS 23.060 [2] and the requirements for

the Bearer Independent CS Core Network are contained in 3GPP 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.) ornon-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 (includinga 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)".

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


8/37

ETSI


3 Definitions, symbols and abbreviations

3.1 Definitions

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

NAS node selection Function: The function used to assign specific network resources (i.e. MSC or SGSN) to serve amobile 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.

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 service area: This area contains all the cells controlled by the RAN node (RNC or BSC).

3.2 SymbolsFor the purposes of the present document, the following symbols apply:

3.3 Abbreviations

For the purposes of the present document, the following abbreviations apply:

AS Access Stratum

BSC Base Station Controller

BVCI BSSGP Virtual Connection Identifier

CN Core Network

CS Circuit SwitchedCS-MGW Circuit Switched Media Gateway

DNS Directory Name Server

IDNNS Intra Domain NAS Node Selector

LA Location Area

LAI Location Area Identity

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 IdentityRAN 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:


9/37

ETSI


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

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

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


10/37

ETSI


Area 1

RAN

node

Area 5

RAN

node

Area 6

RAN

node

Area 7

RAN

node

Area 8

RAN

node

Area 2

RAN

node

Area 3

RAN

node

Area 4

RAN

node

PS pool-area 2PS pool-area 1

CS pool-area 2CS pool-area 1

MSC 3MSC 2

MSC 1

MSC 6MSC 5

MSC 4

SGSN 6

SGSN 2

SGSN 1

SGSN 5SGSN 4

SGSN 3

MSC 7

Figure 1: Pool-area configuration example

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 thesame 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) [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 10bits. 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


11/37

ETSI


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: "Radio Resource

Control (RRC) Protocol Specification" [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 RANnode 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 3GPP 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 CNnode 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.

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 Iumode. 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 (ie the paging message does not contain a

TMSI), the NAS node selection function in the BSC shall upon reception temporarily store the Global-CN- IDof 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 IMSIand 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 (ie 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: "Radio Resource Control (RRC) Protocol Specification"

[5]. The RAN node shall be configured to use the value (V) to select a CN node. Each value (V) corresponds asingle CN node. Typically many values of (V) may point to the same CN node.


12/37

ETSI


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

In case of handover/relocation into a pool-area a load balancing between all the target CN nodes serving this pool-area

is gained by configuration. Source CN nodes which support Intra Domain Connection of RAN Nodes to Multiple CN

Nodes may be configured with all possible target CN nodes for each handover/relocation target. Source CN nodes

which do not support the Intra Domain Connection of RAN Nodes to Multiple CN Nodes can configure only one target

CN node per handover/relocation target. In this case each of source CN nodes which handover/relocate to the same

pool-area may be configured with another target CN node out of all target CN nodes serving the same

handover/relocation target. The mechanism for distribution of the traffic between the handover/relocation target CN

nodes is implementation specific. This load balancing is complemented by the NAS Node selection Function in the

RAN, which distributes MSs between the CN nodes when these MSs enter the pool-area in idle mode.

As more than one SGSN may send downlink data at the same time for a cell or a BVCI the total possible downlink

traffic has to shared between the SGSNs as described in clause "5.3.2 Gb mode".

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 theseprocedures 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 toresolve the ambiguity of the multiple CN nodes serving the same area.

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


13/37


14/37

ETSI


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:

"Radio Resource Control (RRC) Protocol Specification" [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.

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

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 case a MSC sends a paging with IMSI (ie the paging message does not contain a TMSI), the RNC may, for purposesto increase the paging success rate, upon reception temporarily store the Global-CN-IDof 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-

IDto the paging message.

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

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 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 TLLIwhich 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 validfor 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


15/37

ETSI


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.

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

5.3.3 Iu mode

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

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 MultipleCN 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 thatserves 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, that it might be required to keep information on ongoing MAP dialogues in the default MSC.


16/37

ETSI


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 defaultout 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.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 DomainConnection 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, that 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 IMSI. This 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 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.

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.


17/37

ETSI


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

1, 2, 3

NRI:

7, 8, 9

NRI:

4, 5, 6

NRI:

10, 11, 12

NRI:

25, 26, 27

NRI:

22, 23, 24

NRI:

19, 20, 21

NRI:

16, 17, 18

NRI:

13, 14, 15

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 isserved by 5 MSCs, indicated by the 5 NRI values in the figure below, which share the load within the pool-area. Only

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 theseareas the MSs will always be allocated to a new MSC by the NAS node selection function as adjacent areas do not usethe 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


18/37


19/37

ETSI


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.

7d. Cancel Location Ack

7c. Cancel Location

7b. Update Location

7g. Update Location Ack

7e. Insert Subscriber Data

7f. Insert Subscriber Data Ack

6d. Insert Subscriber Data

6c. Cancel Location Ack

6b. Cancel Location

3. Identity Response

2. Identification Response

2. Identification Request1. Attach Request

5. IMEI Check

3. Identity Request

4. Authentication

6a. Update Location

7a. Location Update Request

7h. Location Update Accept

6f. Update Location Ack

6e. Insert Subscriber Data Ack

MS UTRAN new SGSN old SGSN GGSN HLREIR

old

MSC/VLR

new

MSC/VLR

9. Attach Complete

8. Attach Accept

10. TMSI Reallocation Complete

C1

RANAP-INITIAL_UEINITIAL_DT

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

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 7.1.3 andrelays the Attach Request to the SGSN in the Initial UE message (RANAP).


20/37


21/37

ETSI


h) The VLR responds with Location Update Accept (VLR TMSI) to the SGSN. An IuFlex 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 IuFlex

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 MSThe service request procedure initiated by the MS is shown in the figure below.

SGSNMS

2. Service Request

3. Security Functions

RNC1. RRC Connection Request

8. Uplink PDU

1. RRC Connection Setup

4. Radio Access Bearer AssignmentRequest

6. Radio Access Bearer AssignmentResponse

5. Radio Bearer Setup

6. Radio Bearer SetupComplete

HLR GGSN

7. SGSN-Initiated PDP Context Modification

Initial_DT RANAP-INITIAL_UE

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


22/37

ETSI


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

7. SGSN-Initiated PDP Context Modification Procedure

8. Downlink PDU

SGSNMS


RNC

3. RRC Connection Request

1. Downlink PDU

3. RRC Connection Setup

6. Radio Access Bearer Assignment

Request

6. Radio Access Bearer AssignmentResponse

6. Radio Bearer Setup

6. Radio Bearer SetupComplete

2. Paging2. Paging

4. Service Request

HLR GGSN

Initial_DTRANAP-INITIAL_UE

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.


23/37

ETSI


2) The SGSN sends a Paging message to the RNC. The RNC pages the MS by sending a Paging message to the

MS. See subclause "PS Paging Initiated by 3G-SGSN without RRC Connection for CS" of 23.060 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 inthe 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.

7.4 Signalling flow for Routing Area Update (Iu interface mode)

The routing area update procedure is shown in the figure below.


24/37

ETSI


2. SGSN Context Response3. Security Functions

2. SGSN Context Request1. Routeing Area Update Request

MS UTRAN GGSNold

3G-SGSN

new

3G-SGSN HLR

new

MSC/VLR

old

MSC/VLR

4. SGSN Context Ack

C2

7. Cancel Location

7. Cancel Location Ack

5. Update PDP Context Response

5. Update PDP Context Request

6. Update Location

11b. Cancel Location



15. TMSI Reallocation Complete


12. Location Update Accept

14. Routeing Area Update Complete

13. Routeing Area Update Accept

9. Update Location Ack

11a. Update Location

10. Location Update Request

8. Insert Subscriber Data

8. Insert Subscriber Data Ack


C3

C2

2a. SRNS Context Request

2a. SRNS Context Response

7a. Iu Release Command

7a. Iu Release Complete

C1

RANAP-INITIAL_UEINITIAL-DT

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


25/37

ETSI


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 getthe 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 subclause "Security Function" of 23.060. 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 Acknowledgemessage 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 subclause "Serving

RNS Relocation Procedures" of 23.060.

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

7) If the RA update is an nter-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 subscriptionrestrictions 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


26/37

ETSI


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

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


27/37

ETSI


UE RNC New MSC HLRold MSC



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

4a. Update Location

4b. Cancel Location




2. Inital_UE

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 theMSC

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


28/37

ETSI


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 theUE. From then on the UE will be addressed using this TMSI value.


29/37


30/37


31/37

ETSI


'3 pool configuration' no sharing of NRI values:

This example assumes that the 3 pool-areas have independent NRI values, so the available TMSIrange has to be shared between the pools. All TMSI's from other pool-areas can be detected best

load distribution in the pools.

So 3*32 = 96 NRI values are needed for all 3 pools. The NRI-length has to be increased to 7 bit.(not an optimum configuration since 32 NRI values are unused). In the example the NRI nowuses bits 23-17.

Since still for each NRI value 20 bits are needed to address 1M TMSIs there is a conflict with theassumed 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 1

NRI: 0..31TMSI: x0000000xx

-

x0011111xx

Pool 2

NRI: 32..63

TMSI: x0100000xx

-

x0111111xx

Pool 3

NRI: 64..95TMSI: 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-

restart'

used NRI range

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


32/37

ETSI


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

In the example the NRI values 0..7 are shared and so are the TMSI ranges x0000000xx ..x0000111x

Pool 1

NRI: 0..31

TMSI: x0000000xx

-

x0011111xx

Pool 2

NRI: 0..7 & 32..55

TMSI: x0000000xx -

x0000111xx &

x0100000xx

-

x0110111xx

Pool 3

NRI: 0..7 & 56..79TMSI: 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-restart'

used NRI range

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


The percentage of the shared NRIs is now increased to 50%. So of the NRI values are the samein 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.


This reduction of NRI saves 1 bit in NRI length. So the VLR-restart can be slightly increased to 4bit (still 1 bit less than in the original assumption)



33/37

ETSI


Pool 1

NRI: 0..31

TMSI: x000000xx

-

x011111xx

Pool 2

NRI: 0..15 & 32..47

TMSI: x000000xx -

x001111xx &

x010000xx

-

x101111xx

Pool 3

NRI: 0..15 & 48..63TMSI: 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.


Next step is to even increase the shared part of the NRI to . This means that only 25% of theincoming traffic in a pool-area is distributed.


Like the first step this doesn't free any addressing space in the TMSI. But some NRI values arenow available in case it is wanted to share them with other nodes outside the '3 pool area'.



34/37

ETSI


Pool 1

NRI: 0..31

TMSI: x000000xx

-

x011111xx

Pool 2

NRI: 0..23 & 32..39

TMSI: x000000xx -

x010111xx &

x100000xx

-

x101001xx

Pool 3

NRI: 0..23 & 40..47TMSI: 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/


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


35/37

ETSI


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

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/


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 thewish 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 bookedTMSI 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 TMSIreallocation.

MAP on VLR-VLR I/F must be updated, otherwise subscriber confidentially decreases because forevery 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 certainLA? FFS

If yes then a paging-request there will trigger several page-response messages per LA.


36/37


37/37


History

Document history

V6.0.0 December 2004 Publication

ts_ MSC pool

Documents

Transcript of ts_ MSC pool