Download SGSNs in Pool

Leliwa Technical Bulletin
Date:
Date:
23.08.2009
Revision:
005/SGP/004
Author:
Jakub Bluszcz
1
Copyright ©2010 Leliwa. All Rights Reserved.
SGSNs in Pool
Leliwa Technical Bulletin
SGSNs in Pool
Table of contents
Topic
Page
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
2
SGSNs in Pool
Leliwa Technical Bulletin
Introduction
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.
SGSN1
BSC1
BSC2
SGSN2
BSC3
SGSN3
BSC4
BSC5
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.
SGSN1
SGSN2
SGSN3
IP network
BSC1
BSC2
BSC3
BSC4
BSC5
BSC6
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
3
Leliwa Technical Bulletin
SGSNs in Pool
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.
SGSN2
SGSN1
SGSN7
SGSN4
SGSN6
SGSN3
SGSN5
BSC3
BSC2
BSC4
BSC5
BSC8
BSC6
BSC1
Pool-area 1
BSC7
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 poolarea 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 nonoverlapping with any other Pool-area. The number or capacity of SGSNs is
configured independently for each pool-area. The usage of SGSNs in Pool
4
SGSNs in Pool
Leliwa Technical Bulletin
may be configured in parts of the network only and can co-exists with other
areas not using this feature.
Network 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 poolareas, 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.
BSC3
SGSN3
SGSN2
BSC1
SGSN1
BSC2
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
5
Leliwa Technical Bulletin
SGSNs in Pool
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.
octet 4
octet 3
octet 2
octet 1
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
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.
6
SGSNs in Pool
Leliwa Technical Bulletin
Node 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.
SGSN1
(NRI=1)
P-TMSI (NRI=2)
BSC1
SGSN2
(NRI=2)
P-TMSI (NRI=2)
BSC2
Node Selection Function (NSF)
P-TMSI/NRI allocation
NRI routing
SGSN3
(NRI=3)
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
7
Leliwa Technical Bulletin
SGSNs in Pool
'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 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 ReRe-Distribution
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.
8
SGSNs in Pool
Leliwa Technical Bulletin
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.
Null-NRI,
Periodic RA Upd. timer = 4s,
Force to Stand-by
SGSN
(NRI=1)
O&M
RA Upd. (periodic)
RA Upd. Accept ( )
BSC
SGSN
(NRI=2)
RA Upd. (periodic)
SGSN
(NRI=3)
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.
Activate PDP Context Request
Detach Request
Attach Request
SGSN
(NRI=2)
Attach Accept ( )
BSC
RA Upd. (periodic)
Null-NRI,
Periodic RA Upd. timer = 4s,
Force to Stand-by
SGSN
(NRI=3)
Figure 8 Load Re-Distribution (phase 2)
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.
9
Leliwa Technical Bulletin
SGSNs in Pool
Detach Request / IMSI paging
SGSN
Attach Request
(NRI=2)
Attach Accept ( )
BSC
RA Upd. (periodic)
SGSN
Null-NRI,
Periodic RA Upd. timer = 4s,
Force to Stand-by
(NRI=3)
Figure 9 Load Re-Distribution (phase 3)
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 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.
old pool
SGSN
(NRI=1)
SGSN
(NRI=2)
RA Update Request
SGSN
Context Request
(P-TMSI, old RAI)
SGSN
NRI & old RAI ► IP @ old SGSN
Figure 10 SGSN change (new SGSN outside old pool)
10
SGSNs in Pool
Leliwa Technical Bulletin
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).
nriCCCC.racDDDD.lacEEEE.mncYYY.mccZZZ.gprs
SGSN
IP @ old SGSN
DNS
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 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 PTMSI. 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.
11
Leliwa Technical Bulletin
SGSNs in Pool
old pool
SGSN
(default)
SGSN
SGSN
Context Request
RA Update Request
(P-TMSI, old RAI)
SGSN
RAI ► IP @ default SGSN
Figure 12 Default SGSN
Combined 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.
BSC1
SGSN1
SGSN2
BSC2
BSC3
SGSN
BSC4
BSC5
BSC6
Gs
MSC1
MSC2
MSC3
MSC4
Figure 13 MSCs pools & SGSNs pool with Gs I/F
Attach
In case of ‘combined GPRS/IMSI attach’ or ‘GPRS attach when already IMSI
attached’, the SGSN sends the Location Update Request message to the
MSC/VLR. The SGSN selects an MSC/VLR from the available MSC/VLRs
12
SGSNs in Pool
Leliwa Technical Bulletin
(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
pool
(0-4999)
MSC
(4999-9999)
Location Upd.
Request
Combined GPRS/IMSI Attach
SGSN
IMSI ► hash value (0-9999)
hash value & RAI ► MSC No.
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 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.
13
Leliwa Technical Bulletin
SGSNs in Pool
IMSI ► hash value (0-9999)
hash value & RAI ► MSC No.
BSC1
BSC2
MSC1
BSC3
MSC2
BSC4
RA/LA Upd.
BSC5
BSC6
MSC3
MSC4
(0-4999)
(4999-9999)
Request
SGSN
SGSN2
Location Upd.
SGSN1
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 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
pool
MSC
Paging Res. (IMSI)
Paging
Req. (IMSI)
BSC
Paging Req. (IMSI)
Paging
(IMSI + MSC/VLRidentity)
Figure 16 CS paging via Gs interface
14
SGSN
SGSNs in Pool
Leliwa Technical Bulletin
MSC Load ReRe-Distribution
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-UpdateRequest (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.
MSC1
MSC2
MSC3
Location Upd.
RA/LA Upd.
Request
SGSN
O&M
(0-3332) ► MSC1
(3333-6665)+(0-1666) ► MSC2
(3333-6665) ► MSC2 (6666-9999)+(1666-3332) ► MSC3
(6666-9999) ► MSC3
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.
15
Leliwa Technical Bulletin
SGSNs in Pool
MSC1
MSC2
MSC3
Location Upd.
Detach Request (IMSI)
Request
SGSN
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.
16
SGSNs in Pool
Leliwa Technical Bulletin
Acronyms and Abbreviations
BSC
BSS
BSSAP
CN
CPICH
CS
CS
EHPLMN
FDD
GMM
GPRS
GSM
GTP
HLR
HPLMN
IMSI
IP
LA
LLC
MM
MS
MSC
NRI
NSF
PDP
PDP
PS
PS
P-TMSI
RA
RAI
RAN
SGSN
TLLI
TMSI
VLR
Base Station Controller
Base Station System
BSS Application Part
Core Network
Common Pilot Channel
Circuit Switching
Convergence Sublayer
Equivalent Home PLMN
Frequency Division Duplex
GPRS Mobility Management
General Packet Radio Service
Global System for Mobile Communications
GPRS Tunelling Protocol
Home Location Register
Home Public Land Mobile Network
International Mobile Subscriber Identity
Internet Protocol
Location Area
Logical Link Control
Mobility Management
Mobile Station
Mobile services Switching Centre
Network Resource Identifier
Node Selection Function
Packet Data Protocol
Policy Decision Point
Packet Switching
Presence Service
Packet TMSI
Routing Area
Routing Area Identification
Radio Access Network
Serving GPRS Support Node
Temporary Logical Link Identifier
Temporary Mobile Subscriber Identity Number
Visited Location Register
17
Leliwa Technical Bulletin
SGSNs in Pool
References
This section contains the locations of various specifications, document
references and useful information where you can learn more about this
subject.
18
[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
SGSNs in Pool
Leliwa Technical Bulletin
Disclaimer
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 Telecom AB
AB
Plebiscytowa 1.122
PL-44-100 Gliwice
Poland
GPS: N50.2981°, E018.6561°
Orrpelsvägen 66
SE-167 66 BROMMA
Sweden
GPS: N59.3260°, E17.9464°
telephone: +48 32 376 63 05
fax: +48 32 376 63 07
Skype: leliwa_poland
email: [email protected]
telephone: +46 8 4459430
email: [email protected]
19