SGSNs in Pool

1

SGSNsSGSNsSGSNsSGSNs in Pool in Pool in Pool in Pool

DateDateDateDate:::: 23.08.2009

Revision:Revision:Revision:Revision: 005/SGP/004

Author:Author:Author:Author: Jakub Bluszcz

Leliwa Technical Bulletin

Copyright ©2010 Leliw

a. All Rights Reserved.

Leliwa Technical Bulletin SGSNs in Pool

2

Table of contentsTable of contentsTable of contentsTable of contents

TopicTopicTopicTopic PagePagePagePage

Introduction.....................................................................................................3

Network Resource Identification .....................................................................5

Node Selection Function.................................................................................7

Mobility Management....................................................................................10

Combined MM procedures............................................................................12

Acronyms and Abbreviations ........................................................................17

References ...................................................................................................18

Disclaimer.....................................................................................................19

SGSNs in Pool Leliwa Technical Bulletin

3

IntroductionIntroductionIntroductionIntroduction

The SGSN in Pool, as a part of Intra Domain Connection of RAN Nodes to Multiple CN Nodes solution, overcomes the strict hierarchy, which restricts

the connection of a BSC node to just one SGSN. This restriction results from

routing mechanisms in the BSC which differentiate only between information

to be sent to the SGSN (PS domain) or to the MSC (CS domain) and which

do not differentiate between multiple CN nodes in each domain. The SGSN in

Pool solution introduces a routing mechanism and other related functionality,

which enables the BSC to route information to different CN nodes within the

CS or PS domain, respectively.

SGSN2SGSN1

BSC3BSC2BSC1 BSC5BSC4

SGSN3

BSC6

Figure 1 SGSNs in Pool (logical view)

The fact that the BSC can co-operate with the several SGSN does not implies

that the separate physical interfaces are required since the IP network can be

used between BSCs and SGSNs to switch the traffic delivered on the same

physical interfaces to different recipients connected to that network.

SGSN2SGSN1

BSC3BSC2BSC1 BSC5BSC4

SGSN3

BSC6

IP network

Figure 2 SGSNs in Pool (physical view with Gb/IP)

The SGSN in Pool solution introduces further the concept of ‘pool-areas’

which is enabled by the routing mechanism in the BSC. An SGSN pool-area

is comparable to an SGSN service area as a collection of one or more BSC

service areas. In difference to an SGSN service area a pool-area is served by


4

multiple SGSNs in parallel which share the traffic of this area between each

other. Furthermore, pool-areas may overlap which is not possible for the

SGSN service areas. From a BSS perspective a pool-area comprises all RAs

of one or more BSC that are served by a certain group of SGSN nodes in

parallel. One or more of the SGSNs in this group may in addition serve RAs

outside this pool-area or may also serve other pool-areas. This group of

SGSNs is also referred to as SGSN pool.

The SGSN in Pool enables a few different application scenarios with certain

characteristics. The service provision by multiple SGSNs within a pool-area

enlarges the served area compared to the service area of one SGSN. This

results in reduced inter SGSN RA updates 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 SGSNs in a pool-area are the possibility of capacity

upgrades by additional SGSNs in the pool-area or the increased service

availability as other SGSNs may provide services in case one SGSN in the

pool-area fails.

SGSN7

SGSN6

SGSN4SGSN2

SGSN1

BSC3

BSC2

BSC1

BSC5BSC4BSC7

BSC6

BSC8

SGSN3

SGSN5

Pool-area 1 Pool-area 2 Pool-area 3

Figure 3 Pool area configuration example

An MS is served by one dedicated SGSN node of a pool-area as long as it is

in radio coverage of the pool-area. Fig. 13-3 shows most of the possible pool-

area configurations. It contains Pool-area 1 (BSC area 1, 2 and 3 served by

SGSNs 1 and 2), Pool-area 2 (BSC area 4 and 5 served by SGSNs 3 and 4)

and Pool-area 3 (BSC area 5, 6 and 7 served by SGSNs 5, 6 and 7). In

addition the BSC areas 8 is served by SGSN 7 without any usage of the

SGSNs in Pool feature. The possibility to configure overlapping pool-areas is

shown by the Pool-areas 2 and 3. The Pool-areas 1 is configured non-

overlapping with any other Pool-area. The number or capacity of SGSNs is

configured independently for each pool-area. The usage of SGSNs in Pool


5

may be configured in parts of the network only and can co-exists with other

areas not using this feature.

Network Resource IdentificationNetwork Resource IdentificationNetwork Resource IdentificationNetwork Resource Identification

An SGSN pool-area is an area within which an MS roams without a need to

change the serving SGSN. A pool-area is served by one or more SGSNs

nodes in parallel. The complete service area of a BSC belongs to the same

one or more pool-area(s). An BSC service area may belong to multiple pool-

areas, which is the case when multiple overlapping pool-areas include this

BSC service area. If RAs span over multiple BSC service areas then all these

BSC service areas have to belong to the same pool-area.

SGSN1

SGSN2

SGSN3

BSC3

BSC2

BSC1

An SGSN pool-area is an area within which an MS roams without a need to change the serving SGSN.

Figure 4 Pool-area definition


6

The Network Resource Identifier (NRI) identifies uniquely an individual SGSN

out of all SGSNs, which serve in parallel a pool-area. The length of the NRI is

the same in all SGSNs in one pool-area. In areas where pool-areas overlap

the NRI identifies uniquely an SGSN out of all SGSNs, which serve all these

overlapping pool-areas, i.e. an NRI identifies uniquely an SGSN within a

BSC. In case of overlapping pool-areas the NRI length is configured to be the

same in all the nodes serving these pool-areas. More than one NRI may be

assigned to an SGSN.

The NRI is part of the P-TMSI, which is assigned by the serving SGSN to the

MS. The P-TMSI allocation mechanism in the SGSN 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).

The NRI is coded in bits 23 to 14 of P-TMSI. Regardless of the NRI length the

most significant bit of the NRI is always in bit 23 of P-TMSI.

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 0octet 1octet 2octet 3octet 4

NRI

NRI - Network Resource Identification

Figure 5 Structure of P-TMSI

The BSC node derives the NRI from the TLLI. The BSC masks the significant

bits out of the TLLI to determine the NRI, which identifies the SGSN. It is

configured in the BSC which bits out of TLLI provided by the MS are

significant for the NRI.

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 SGSNs with an appropriate load status. MSs

changing a pool-area may be detected by configuration of different NRI

values for adjacent pool-areas.


7

Node Selection FunctionNode Selection FunctionNode Selection FunctionNode Selection Function

This function is used in BSC and potentially in SGSNs. In the BSC the

function selects the specific SGSN to which LLC frames are routed. The NRI

identifies the specific SGSN. If the Node Selection Function has an SGSN

address configured for the NRI derived from the LLC frame then this frame is

routed to this address. If no SGSN 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 Node Selection Function selects an available SGSN (e.g.

according to load balancing) and routes the LLC frame to that SGSN.

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

A ‘local TLLI’ indicates to the BSC that the TLLI is derived from a P-TMSI

which was assigned for the current RA, i.e. the ‘local TLLI’ contains an NRI

which is valid for routing to an SGSN. A ‘foreign TLLI’ indicates to the BSC

that the TLLI is derived from a P-TMSI which was assigned for another RA

than the current RA. The BSC does not know whether the other RA and

therefore the related P-TMSI belongs to the same pool-area or not unless this

is configured in the BSC (which is not intended). Consequently, the BSC

assumes, that the ‘foreign TLLI’ contains a NRI which is valid for routing to an

SGSN.

SGSN2

SGSN1

SGSN3

BSC1

BSC2

�

P-TMSI (NRI=2)

(NRI=2)

(NRI=1)

(NRI=3)

�

P-TMSI (NRI=2)

�

� Node Selection Function (NSF) � P-TMSI/NRI allocation � NRI routing

Figure 6 Use of NRI

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


8

'random TLLI' which contains no NRI at all then the BSC routes the uplink

LLC frame to an SGSN selected from the available SGSNs. The selection

mechanism is implementation dependent.

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.

Load balancingLoad balancingLoad balancingLoad balancing

The Node Selection Function in the BSC balances the load between the

available SGSNs. This is performed by an appropriate selection of the SGSN

for an MS:

• which was not yet assigned to a SGSN, i.e. when there is no SGSN

configured for the NRI indicated by the MS,

• when a 'random TLLI' is received,

• when no NRI can be derived,

• in exceptional cases, e.g. when the SGSN corresponding to an NRI

cannot be reached.

The load-balancing algorithm is implementation specific.

Load ReLoad ReLoad ReLoad Re----DistributionDistributionDistributionDistribution

There are situations where a network operator wishes to remove load from

one SGSN in an orderly manner (e.g. to perform scheduled maintenance, or,

to perform load re-distribution to avoid overload) with minimal impact to end

users and/or additional load on other entities. The re-distribution procedure

does not require any new functionality in the terminal, that is, all terminals can

be moved.

Re-distribution of MSs is initiated via an O&M command in the SGSN node,

which needs to be off-loaded.

In a first phase (a couple of Periodic RA Update periods long), MSs doing RA

Update or Attach are moved to other SGSNs in the pool. When the SGSN

node receives the, RA Update or Attach request, it returns a new P-TMSI with

a null-NRI, a sufficiently low value of periodic routing area update timer

(recommended value 4 seconds) and sets the force to Stand-by indication.


9

The MS shortly after sends a new RA Update that the BSC then routes to a

new SGSN due to the presence of a null-NRI.

SGSN

SGSN

SGSN

�

(NRI=2)

(NRI=1)

(NRI=3)

BSC� RA Upd. Accept ( )

� RA Upd. (periodic)

Null-NRI, Periodic RA Upd. timer = 4s, Force to Stand-by


O&M

Figure 7 Load Re-Distribution (phase 1)

In a second phase, the SGSN requests all MSs trying to set up PDP Contexts

to detach & reattach. When they reattach, the SGSN moves them as in the

first phase described above.

SGSN

SGSN

(NRI=2)

(NRI=3)

� Detach Request

� Activate PDP Context Request

� Attach Request

� Attach Accept ( )BSC




A third phase includes scanning through remaining MSs and initiating a move

of them to other SGSNs by requesting them to detach and reattach, which

causes them to be moved.


10

SGSN

SGSN

(NRI=2)

(NRI=3)

� Detach Request / IMSI paging

� Attach Request

� Attach Accept ( )BSC




The MSs being moved from one SGSN are stopped from registering to the

same SGSN again by an O&M command in BSCs connected to the pool. The

MSs moving into a pool area are also stopped from registering into a SGSN

being off-loaded in the same manner.

Mobility ManagementMobility ManagementMobility ManagementMobility Management

An MS performs RA Updates and Attachments, which may result in a change

of the serving SGSN. In these procedures the new SGSN requests from the

old SGSN MS specific parameters. If multiple SGSNs are configured in the

new SGSN for the old RA indicated by the MS then the new SGSN derives

the NRI from the old P-TMSI indicated by the MS. The new SGSN node uses

the old RA together with the NRI to derive the signalling address of the old

SGSN from its configuration data.

SGSN

SGSN

SGSN

(NRI=2)

(NRI=1)

old pool

�

� RA Update Request (P-TMSI, old RAI)

� NRI & old RAI ► IP @ old SGSN

� SGSN Context Request

Figure 10 SGSN change (new SGSN outside old pool)


11

The SGSN addresses are configured in the SGSN (O&M) or in DNS for each

RAI and NRI combination. If a DNS server is used, it is queried using the

logical name, derived from the old RAI and NRI information (see Fig. 13-11).

SGSN DNSnriCCCC.racDDDD.lacEEEE.mncYYY.mccZZZ.gprs

IP @ old SGSN

Figure 11 DNS query

If the network contains nodes that cannot derive the old SGSN from RAI and

NRI a default SGSN for each RA is used to resolve the ambiguity of the

multiple SGSNs serving the same area.

Default SGSN and backwards compatibilityDefault SGSN and backwards compatibilityDefault SGSN and backwards compatibilityDefault SGSN and backwards compatibility

SGSNs that can only derive one SGSN from the RAI (e.g. because they do

not support the SGSN in Pool feature, or no detailed knowledge of the NRIs

is configured) are not aware, that multiple SGSNs may serve a RA. These

nodes can therefore contact only one SGSN (default SGSN) per RA.

A default SGSN resolves the ambiguity of the multiple SGSNs per RA by

deriving the NRI from the P-TMSI. The default SGSN relays the signalling

between the new SGSN and the old SGSN.

Note that the default SGSN is configured per RA. So different SGSNs in a

network might have configured different default nodes for a RA. With this

approach more than one of the SGSNs that serve a pool-area can be used as

default SGSN, so load concentration on one SGSN and a single point of

failure can be avoided.

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.


12

SGSN

SGSN

SGSN

old pool

�

� RA Update Request (P-TMSI, old RAI)

� RAI ► IP @ default SGSN

� SGSN Context Request

(default) �

Figure 12 Default SGSN

Combined MM proceduresCombined MM proceduresCombined MM proceduresCombined MM procedures

The Intra Domain Connection of RAN Nodes to Multiple CN Nodes allows for

creation of PS and CS pool areas (i.e. SGSNs pools and MSCs pool). If the

operator is using Network Mode of Operation 1 (i.e. Gs interface) than the

combined MM and GMM procedures are affected.

BSC3BSC2BSC1 BSC4

MSC2MSC1 MSC4

BSC5 BSC6

MSC3

SGSNSGSN2SGSN1

Gs

Figure 13 MSCs pools & SGSNs pool with Gs I/F

AttachAttachAttachAttach

In case of ‘combined GPRS/IMSI attach’ or ‘GPRS attach when already IMSI

attached’, the SGSN sends the Location Update Request message to the

MSC/VLR. The SGSN selects an MSC/VLR from the available MSC/VLRs


13

(MSC/VLRs in Pool) which serve the current LA of the MS. The selection

bases on a hash value derived from the IMSI. It is configured in the SGSN

which range of the hash values relates to which MSC/VLR.

MSC

MSC

SGSN

pool

� Combined GPRS/IMSI Attach

� IMSI ► hash value (0-9999) hash value & RAI ► MSC No.

� Location Upd. Request

(0-4999)

(4999-9999)

Figure 14 Combined GPRS/IMSI Attach

This selection mechanism avoids a random change of the MSC/VLR for MSs

using combined procedures when an SGSN fails. The new SGSN will select

the same MSC/VLR.

Routing area updateRouting area updateRouting area updateRouting area update

The CN node changes in the following considerations result from pool-area

changes (when pool-areas are configured) or from CN node service area

changes (when no pool-areas are configured). For each domain (PS or CS) it

is configured independently whether pool-areas are used or not.

When neither the MSC nor the SGSN are changed, the association for an MS

between both CN nodes will also not change.

When the MSC changes but the SGSN does not change, the SGSN selects a

new MSC because the new LA is not served by the old MSC/VLR. The

selection mechanism is as described for the attach above.

When the SGSN changes but the MSC does not change, the new SGSN

selects the old MSC to establish a Gs association because the new SGSN

uses the same selection mechanism as described above for the attach with

the same parameters as configured in the old SGSN.


14

BSC3BSC2BSC1 BSC4

MSC2MSC1

BSC5 BSC6

MSC3

SGSNSGSN2SGSN1

MSC4

� RA/LA Upd.�

� IMSI ► hash value (0-9999) hash value & RAI ► MSC No.

�Lo

catio

n U

pd.

Req

uest

(0-4999) (4999-9999)

Figure 15 SGSN change with no MSC change

When both the MSC and the SGSN change, the new SGSN selects a new

MSC to establish a Gs association. The selection mechanism is as described

for the attach above.

CS paging via Gs interfaceCS paging via Gs interfaceCS paging via Gs interfaceCS paging via Gs interface

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 message. The selection

function in the BSC temporarily stores MSC/VLR-identity in order to send the

Paging Response to the MSC that has issued the Paging Request.

MSC

MSC

SGSN

pool

� Paging Req. (IMSI)

BSC� Paging

(IMSI + MSC/VLR-identity)

� Paging Req. (IMSI)

� Paging Res. (IMSI)

Figure 16 CS paging via Gs interface


15

MSC Load ReMSC Load ReMSC Load ReMSC Load Re----DistributionDistributionDistributionDistribution

Redistribution of MSs is initiated by O&M command in the SGSN providing

the Gs interface to the MSC to be off-loaded. The corresponding IMSI Hash

table is reconfigured to reflect the redistribution. If the SGSNs are also

configured in a pool, this is repeated for any SGSN connected to that MSC.

The IMSI Hash table have a consistent configuration in all SGSNs in the pool.

The redistribution is done in two phases. During the first phase, the MSs that

are performing combined RA/LA updates are moved to a new MSC. When

the SGSN receives a Routing Area Update Request (combined RA/LA

updating), it checks if the particular MS shall be moved (i.e. it has a Gs

association with the MSC being off-loaded). If the MS shall be moved, the

SGSN invokes the MSC selection function (IMSI Hash) to decide where the

MS should be distributed. SGSN sends the (BSSAP+) Location-Update-

Request (IMSI attach) to the new selected MSC where the MS is registered.

Stationary MSs (i.e. MSs not performing RA/LA updates) are not moved

during this first phase.

MSC2MSC1

SGSN

MSC3

� O&M

(0-3332) ► MSC1

(3333-6665) ► MSC2

(6666-9999) ► MSC3

(3333-6665)+(0-1666) ► MSC2

(6666-9999)+(1666-3332) ► MSC3�

� RA/LA Upd.


Figure 17 MSC Load Re-Distribution (phase 1)

During the second phase, the SGSN scans its Gs associations to find out

which MSs shall be moved. For each MS with an association to the MSC

being off-loaded, the SGSN sends a Detach Request (indicating IMSI

detach). The MS is forced to re-attach to non-GPRS service (note that there

is no impact on PDP contexts in this case). The MS sends a RA Update

Request (combined RA/LA updating with IMSI Attach). SGSN checks if the

MS shall be moved. If the MS shall be moved, the SGSN invokes the MSC

selection function (IMSI Hash) to select another MSC. SGSN sends the

(BSSAP+) Location Update-Request (IMSI attach) to the new MSC where the

MS is registered.


16

MSC2MSC1

SGSN

MSC3


� Detach Request (IMSI)

� RA/LA Upd (IMSI Attach)

Figure 18 MSC Load Re-Distribution (phase 2)

During the redistribution, incoming IMSI Detach messages are (as during

normal operation) routed to respective existing associated MSC. That is, the

reconfigured IMSI Hash doesn't affect the routing of IMSI Detach messages.


17

Acronyms and AbbreviationsAcronyms and AbbreviationsAcronyms and AbbreviationsAcronyms and Abbreviations

BSCBSCBSCBSC Base Station Controller BSSBSSBSSBSS Base Station System BSSAPBSSAPBSSAPBSSAP BSS Application Part CNCNCNCN Core Network CPICHCPICHCPICHCPICH Common Pilot Channel CSCSCSCS Circuit Switching CSCSCSCS Convergence Sublayer EHPLMNEHPLMNEHPLMNEHPLMN Equivalent Home PLMN FDDFDDFDDFDD Frequency Division Duplex GMMGMMGMMGMM GPRS Mobility Management GPRSGPRSGPRSGPRS General Packet Radio Service GSMGSMGSMGSM Global System for Mobile Communications GTPGTPGTPGTP GPRS Tunelling Protocol HLRHLRHLRHLR Home Location Register HPLMNHPLMNHPLMNHPLMN Home Public Land Mobile Network IMSIIMSIIMSIIMSI International Mobile Subscriber Identity IPIPIPIP Internet Protocol LALALALA Location Area LLCLLCLLCLLC Logical Link Control MMMMMMMM Mobility Management MSMSMSMS Mobile Station MSCMSCMSCMSC Mobile services Switching Centre NRINRINRINRI Network Resource Identifier NSFNSFNSFNSF Node Selection Function PDPPDPPDPPDP Packet Data Protocol PDPPDPPDPPDP Policy Decision Point PSPSPSPS Packet Switching PSPSPSPS Presence Service PPPP----TMSITMSITMSITMSI Packet TMSI RARARARA Routing Area RAIRAIRAIRAI Routing Area Identification RANRANRANRAN Radio Access Network SGSNSGSNSGSNSGSN Serving GPRS Support Node TLLITLLITLLITLLI Temporary Logical Link Identifier TMSITMSITMSITMSI Temporary Mobile Subscriber Identity Number VLRVLRVLRVLR Visited Location Register


18

ReferencesReferencesReferencesReferences

This section contains the locations of various specifications, document

references and useful information where you can learn more about this

subject.

[1] 23.236 Intra-domain connection of Radio Access Network (RAN)

nodes to multiple Core Network (CN) nodes

[2] 23.002 Network architecture

[3] 23.060 General Packet Radio Service (GPRS); Service description;

Stage 2

[4] 48.008 Mobile Switching Centre - Base Station system (MSC-BSS)

interface; Layer 3 specification

[5] 23.003 Numbering, addressing and identification


19

DisclaimerDisclaimerDisclaimerDisclaimer

This document is based on Leliwa training materials.

Information in this document is subject to change without notice. Leliwa

assumes no responsibility for any errors that may appear in this document.

This document may be freely redistributed. You can store it on any servers

and make it available for public download. In such case it must be clearly

indicated that it comes from Leliwa website www.leliwa.com

If you received only this file, you can download more Leliwa Technical

Bulletins from the following address:

http://www.leliwa.com/downloads

If you want to be informed when the new bulletins are uploaded, please send

a blank e-mail with Subject="Update_request" to [email protected] or

click this link: mailto:[email protected]?subject=Update_request

Leliwa Sp. z o.o.Leliwa Sp. z o.o.Leliwa Sp. z o.o.Leliwa Sp. z o.o. Plebiscytowa 1.122 PL-44-100 Gliwice Poland GPS: N50.2981°, E018.6561° telephone: +48 32 376 63 05 fax: +48 32 376 63 07 Skype: leliwa_poland email: [email protected]

Leliwa Telecom ALeliwa Telecom ALeliwa Telecom ALeliwa Telecom ABBBB Orrpelsvägen 66 SE-167 66 BROMMA Sweden GPS: N59.3260°, E17.9464° telephone: +46 8 4459430 email: [email protected]

Documents

SGSNs in Pool