mip dt infomodel

Ericssonwide Internal

DT FEATURE DESCRIPTION 1 (29)Prepared (also subject responsible if other) No.

ETH/GS Irén Csiszár 4/190 46-FAD 104 50 Approved Checked Date Rev Reference

ETH\GSC ETHBYP 2005-10-17 A

MSC in POOL

Abstract

This document describes FAJ 121 297 R2 - MSC in Pool from a DataTranscript point of view.

Content 1 Revision Information............................................................................3 2 Description ..........................................................................................3 2.1 Abbreviations.......................................................................................3 2.2 Concepts .............................................................................................4 2.3 Concerned Nodes ...............................................................................5 2.4 Prerequisites .......................................................................................5 2.4.1 Network ...............................................................................................5 2.4.2 Feature included..................................................................................8 2.4.3 Software level ......................................................................................8 2.5 General................................................................................................8 2.5.1 Neighbouring MSC Group ...................................................................9 2.5.2 Network Resource Indicator (NRI):......................................................9 2.5.3 MSC Pool Area..................................................................................10 2.5.4 Overlapping Pool Area ......................................................................11 2.5.5 Proxy MSC ........................................................................................12 2.6 Technical Solution .............................................................................13 2.6.1 MSC in Pool function.........................................................................13 2.6.2 Building a pool network: ....................................................................15 3 Traffic Case .......................................................................................22 3.1 Location update in MSC in pool area ................................................22 3.2 Handover / SRNS Relocation............................................................23 3.2.1 Neighboring MSC groups ..................................................................24 3.2.2 Subsequent Handover/SRNS Relocation to Third MSC, Anchor MSC24 3.2.3 Handling of Handover/SRNS Relocation in Non-anchor MSC ..........25 4 Data Transcript Impacts – MSC ........................................................26 4.1 AXE Parametrs..................................................................................26 4.1.1 Subfile 10000 Size Alteration APT ....................................................27 4.1.2 Subfile 77200 MSC Pool ...................................................................28 5 Data Transcript Impacts- HLR...........................................................28





6 Miscellaneous information.................................................................28 7 Class .................................................................................................29





1 Revision Information

Revision Impacts Prepared Date

A Release ethcsir 17-10-05

PA3 Update after review ethcsir 28-09-05

PA2 SIGTRAN added Mixed netw. BSC/RNC added

ethcsir 08-07-05

PA1 New document ethcsir 09-05-05

2 Description

2.1 Abbreviations

BSC Base station Services Switching Centre

CDR Call Data Record

HLR Home Location Register

ISP In Service Performance

LA Location Area

MSC Mobile Services Switching Centre

MS Mobile Subscriber

MSISDN Mobile Station ISDN number

NRI Network Resource Indicator

PLMN Public Land Mobile Network

RNC Radio Network Controller

SMS Short Message Service

TMSI Temporary Mobile Station Identity





UE User Equipment

VLR Visitor Location Register

2.2 Concepts

A MSC Pool is defined as a pool of MSC nodes linked to a number of BSC and/or RNC nodes. Each BSC/RNC is connected to each MSC node of the pool.

Figure 1: Example of a Configuration of an MSC Pool

All MSCs within a pool need to be connected to all BSCs/RNCs, so links need to be set up between the nodes. All MSCs within a pool need to have the same BSC/cell – RNC/SAI related settings. An MSC of the pool has no knowledge about the behaviour of the surrounding MSC nodes, whether they belong to the same MSC pool or not. The MSC pool concept is mainly applicable for the BSC/RNC, as the BSC/RNC can see a pool of MSC nodes.

Each MSC node in a pool shares the same service area with all other MSCs in the pool. If an MSC is removed from the pool the subscribers of the removed MSC will be distributed to the other MSCs of the pool. This feature provides MSC redundancy and improved network service availability.

This feature requires a fully meshed network of A-interfaces / IuCS interfaces between all the BSC / RNC nodes of a pool service area and all the MSC nodes of this pool.





This means that all MSC nodes of a pool can have access to a GSM service area and a WCDMA service area at the same time.

Note: It has to be noted that all MSCs in the pool should provide the same level of functionality (HW&SW&activation of functions), otherwise the end-user can get different level of service depending on which MSC she/he is connected to.

Anchor-MSC Anchor-MSC is the MSC where the transaction is originally established.

2.3 Concerned Nodes

MSC/VLR

MSC/MGW

MSC server

BSC

RNC

2.4 Prerequisites

2.4.1 Network

The network service availability is improved for UEs roaming in the WCDMA service area of the MSC pool. This is due to the fact that if an MSC fails its subscribers will be reallocated to another MSC node of the pool.

The feature eases a change of the network infrastructure and improves horizontal scalability, availability and in-service performance (ISP). Less relocation and location update cases with registration to the HLR reduce the signalling load.

Some assumptions that an operator should take into account for the MSC in pool function are the following:

• The network topology should be a fully meshed network. This means that each MSC shall be logically connected to all BSCs/RNCs in the MSC pool service area.





• TMSI allocation shall always be performed even after a reload.

• All MSCs within a pool need to have the same BSC/cell, RNC, and area cluster related settings. For the MSCs that serve also BSCs/RNCs outside the pool, additional settings are needed.

• When a new MSC (without connected BSCs/RNCs) is installed in the pool, the data of BSCs/RNCs in the pool should be copied to the new MSC.

• When a new MSC (with connected BSCs/RNCs) is installed in the pool the cell/RNC and area cluster (if available and used) data needs to be copied from the MSC to all MSCs in order to have the same radio data definition. This copy procedure has to be done following some order and rules that are described reference [3].

• If an MSC pool is configured for GSM traffic only and some of the MSCs in the pool also serve for WCDMA traffic, then these MSCs should be offloaded from the GSM traffic distributed in the MSC pool. This means that less subscribers will be routed to this MSC from the BSC, by using the MSC selection function. The opposite case (MSC pool configured for WCDMA only with some MSCs in the pool serving GSM traffic) should be considered in the same way.

• The NRI length should not change during normal operation because all the previously stored NRI values in the MSC are physically deleted from the MSC immediately.

• The BSCs/RNCs and the MSCs need to have consistent NRI length.

Physical location MSC pool members can be placed in the same site (centralized configuration) or they can be placed in different physical sites (distributed configuration). When deciding about the physical location of the nodes (centralized/distributed) it is important to take into consideration the security aspects, the network architecture (layered, non-layered), the transmission cost aspects and the operational aspects. For example, an MSC pool where all the MSC pool members and the BSCs are placed in the same site has a low transmission cost, an easier operation but it is vulnerable for a site failure (for example: fire, power cut). If the MSC pool members are distributed in different sites, it is possible to achieve the required network availability even if one of the sites fails completely.

Layered network architecture The layered network architecture enables the distribution of MSC pool members and BSCs in multiple sites with optimal transmission usage (A-interface transmission).





E-interface (MSC<->MSC) There is no inter-MSC handover among the MSC pool members if all the MSC pool members are only serving the BSCs in the same MSC pool area. That is, as long as the subscribers move inside the MSC pool area, there are only intra MSC handovers. In this case, there is no need for E-interface among the MSC pool members.

D-interface (MSC/VLR<->HLR) In a normal pool operation, the signaling capacity in the D-interface is decreased because there is no location-updating request towards the HLR as long as the subscriber roams inside the MSC pool area. However the dimensioning of the D-interface must take into consideration the MSC pool member failure cases where a large number of subscribers are moved from the “failed MSC pool member” to the other MSC pool members. The consequences are a large amount of transactions to the HLR through the D-interface.

Global paging The MSC pool area in a large MSC pool can contain a very large amount of location areas. The global paging distributed to a large number of location areas decreases the BSC nodes capacity in the MSC pool area. Therefore the MSC pool members should be configured to support first and second local paging as the preferred paging option in normal traffic. The MSC parameter PAGREP1LA enables/disables the global paging. Note that an MSC pool member will always generate global paging for the subscribers with unknown LA. For example, the LA information is lost during the restoration procedures (after a large restart) if the function “retaining MSC/VLR data after system large restart” is not available. The LA information is always lost after a reload followed by a system large restart.

MSC pool area coverage The definition of the MSC pool area should take into consideration the geographical traffic patterns and flow in the network in order to optimize the utilization of network resources. For example, there is a “traffic pattern” from the “housing area/suburb” to a “ central business area” (large number of subscribers moves in the morning from the “suburb” into the business area and back to the suburb in the evening). If the MSC pool area covers the “housing area/suburb”, the “central business area” and the “main roads in between”, it minimizes inter MSC handover cases (inter-MSC handover to MSC/VLRs outside the MSC pool or vice-versa). It minimizes also the number of subscribers that perform location updates in/out of the MSC pool area (HLR signaling).





2.4.2 Feature included

This document describes the following features:

• MSC in POOL FAJ 121 297 R2

2.4.3 Software level

The feature MSC in Pool for GSM was introduced in R11, MSC in pool with access to WCDMA service areas is supported in R12.

2.5 General

Each BSC / RNC in the pool is connected via the A interface / IuCS interface to each MSC/VLR's of the pool.

When a subscriber roams into a MSC Pool Service Area, the involved BSC selects one of the MSC's in the pool according to pre-defined traffic distribution algorithm based on the capacity figures of the MSC’s in the Pool. The subscriber registers in the selected MSC and remains registered in the same MSC until he moves out of the MSC Pool Service Area.

When the subscriber moves from one location area to another within the MSC Pool Service Area, the new BSC will be informed by the MS about the identity of the MSC where it is registered. In order to implement this functionality without impacts on the Mobile Stations, the TMSI is modified to carry the NRI.

In case MS has roamed outside the MSC Pool Area there may be a need to fetch the IMSI and the security related data from the previous MSC. In order to find out the correct co-operating MSC within the pool, the old TMSI (NRI) is analyzed in the new MSC. In case the previous MSC is part of a MSC pool, then TMSI points out to so called proxy MSC of that MSC pool, which has knowledge of all MSC’s in this MSC pool. This proxy MSC relays the signaling between new MSC and the correct previous MSC.

Note: BSC/RNC configurations have to be adapted to the MSC-Pool concepts.





2.5.1 Neighbouring MSC Group

The MSCs in the neighbouring MSC group are grouped together (max.16) for administration purposes to distribute the inter-MSC handover/SRNS relocation (from outside the pool) in order to achieve a better load distribution. With the neighbouring MSC group, it is allowed to distribute the inter-MSC handovers/SRNS relocations between the group members.

Figure 2: Neighbouring MSC Group

2.5.2 Network Resource Indicator (NRI):

The NRI has been introduced to perform the MSC routing discrimination on BSC/RNC. The routing will be performed based on the NRI. The NRI is coded inside the TMSI, it has a configurable length between 0 to 10 bits, located within bits 14 to 23. The NRI length is configured by the operator and indicates the number of bits that shall be used for the NRI field. NRI univocally identifies a MSC within a Pool. The NRI value is inserted into the TMSI, so that it shall be possible to store it into the SIM card. The length 0 bits means that NRI is not in use and therefore MSC in Pool function is not in use. The NRI is given by MML command when taking a new MSC into the Pool. At least one NRI value has to be assigned to an MSC serving in an MSC pool.





There will be major disturbances in the pool traffic when changing the NRI length. Therefore, the planning of the NRI length must be done very carefully, taking into consideration the future expansion of the MSCs in order to avoid changes in the NRI length. The assumption is that the NRI length is stable and changes of NRI length are rare. A deleted NRI in the MSC/VLR shall force a re-allocation of a new TMSI with a new NRI at the next mobile originating procedure (for example, location update, CM service request).

2.5.3 MSC Pool Area

The MSC pool area is a collection of BSC or RNC service areas or both that are served by one or more MSC nodes in parallel that share the traffic from the pool area. This area an MS can roam without a need to change the serving MSC node. A BSC/RNC service area must belong completely to the one or more MSC pool area(s).All the MSC nodes in such a pool area share the responsibility of handling all the MSs, in all the LAs of the pool area. Each MS can be served by any MSC within a pool area.

Figure 3: Pool Area Consisting of Five Location Areas Once the MS has entered a new pool area, in normal operation the MS





is served by the same MSC as long as the MS roams within the pool area

2.5.4 Overlapping Pool Area

Two (or more) MSC pool areas are overlapping if there is at least one BSC/RNC service area that belongs at the same time to two (or more) MSC pool areas.

No special configuration data are needed in case of an overlapping pool area.

Figure 4 below shows one configuration example of two overlapping pool areas, where MSC 1-3 is serving pool area 1 and MSC 4-6 is serving pool area 2. Pool area 1 and pool area 2 overlap so that RAN nodes in LA2 are served by MSC nodes 1 -6.

Figure 4: Configuration Example of Two Overlapping Pool Areas





2.5.5 Proxy MSC

The cooperating VLR functionality is also impacted when a pool is built, as several MSC/VLRs serve the same location area. A mechanism is needed to ensure that the MAP messages requesting the subscriber data reach the right (previous) VLR. The proxy MSC/VLR function has been introduced to provide this mechanism. An MSC/VLR supporting the proxy functionality is named proxy MSC/VLR.

Old MSC/VLR nodes or MSC/VLR nodes that are not configured with any knowledge of NRI values are not aware of that multiple MSC/VLR nodes can serve the same LA (s). They can only derive one co-operating MSC/VLR address for each LA and can therefore only contact one cooperating MSC/VLR for each LA.

In networks that contains both: MSC in pool and old MSCs there is a need to introduce the ‘Proxy functionality’. This must be defined in at least one MSC/VLR node which has common LA in the pool.

The proxy MSC/VLR relays signaling between two different MSC/VLR nodes. The proxy MSC/VLR will have the knowledge of all MSC/VLR addresses serving the same LA and all NRI values assigned to these MSC/VLR nodes.

The proxy MSC has a table containing all NRIs used inside the pool with their associated MSC/VLRs so modifications in the NRI addressing space have to be done also in all the proxies of the pool in order to keep consistent data. When the proxy MSC receives a MAP message asking for the mobile station IMSI and authentication data, it will extract the NRI from the received TMSI and will redirect the message to the right VLR.

Any MSC belonging to the pool can act as a proxy, provided that it has knowledge of the complete set of NRI with its correspondent MSC used in the pool.





2.6 Technical Solution

2.6.1 MSC in Pool function

MSC Pool feature is controlled by AXE parameter MSCPOOL/GSM1APTF.

Neighbouring MSC group:

The AXE parameter ADMHOMSCPOOL/GSMMMSC determines whether the administration of outer cells, outer RNCs and MSCs grouped in a neighbouring MSC group for 'Handover to MSC Pool' is activated or not.

The AXE parameter MSCREQNUM/GSMMMSC defines the maximum number of trials to select a target MSC from the neighbouring MSC group.

The command MGMGI is used to initiate a neighbouring MSC group and to add MSCs to an already existing neighbouring MSC group. Altogether one neighbouring MSC group can contain up to 16 MSCs.

The command MGMGP is used to print the neighbouring MSC group connection data and MGMGE deletes the whole neighbouring MSCG or deletes one neighbouring MSC from a neighbouring MSCG in the MSC/Visitor Location Register (VLR) Server.

Definition of the NRI length and own NRI values on every MSC that will belong to the pool:

The functionality will be activated when defining an NRI length greater than 0 using the MGNDI command.

The pool function in the BSC can be activated after NRI has been defined, as no other MSCs are available all subscriber operations would be directed to the available MSC. Only the NRI values belonging to this available MSC must be defined at this stage if any.

One ore more NRI values can be deleted by means of MGNDE command. Using the command without parameter (MGNDE;) sets the NRI length to zero: the MSC Pool functionality is de-activated and all the NRI values previously stored in the MSC/VLR server are deleted.

MGNDP lists the Network Resource Identifier (NRI) length and all the NRI values assigned to a MSC/VLR server.





A Proxy Table contains all the Network Resource Identifier (NRI) values assigned to each MSC/VLR Server in the MSC Pool. The proxy table in the MSC(s) that will act as a proxy can be defined by means of command MGPTI.

MGPTE is used for deleting data from the proxy table. This command deletes the following from the Proxy Table: -a VLR address along with all its NRI values, if only the VLR address is given -one or more NRI value(s) for the specified VLR address, if at least one NRI value is given; whenever the given NRI value(s) are exactly all the NRI value(s) assigned to the specified VLR address in the table, the VLR address is deleted as well

Printing the Proxy table data can be done by means of command MGPTP.

Note: The maximum number of NRI values associated to a VLR address is 1024.

Definition in BSC:

Core Network Identity (CNID) value has to be assigned to each MSC in pool defined in the BSC. This can be done by means of command RRMBI.

NRI is used by BSC to route messages to the right MSC. NRIs must be defined and associated with the corresponding MSCs. NRI length can be defined by means of RRNLC command, while NRI value can be associated to MSC by means of RRNRI command.

MSC traffic distribution can be controlled by setting parameters (mode, capacity, percentage of subscribers at reselection) for each MSC by means of command RLTDC . Example: in mode ACTIVE the MSC is in normal operation. The parameter CAP specifies the capacity of the MSC relative to other MSCs in an MSC pool area, and is used at distribution of subscribers at MSC selection.

Definition for RNC:





Command MGRIC will support the change of the property for the MSC interfacing the target RNC, which denotes if the target RNC serves an MSC in Pool, in case the ‘MSC in Pool’ function is active for any Handover/ Relocation towards UTRAN. The IE ‘Global CN-Id’ will be included in the associated RANAP messages if the target RNC serves an MSC in Pool (the RNC supports the reception of the ‘Global CN-Id).

2.6.2 Building a pool network:

2.6.2.1 Definition in MSC

The MSC in pool functionality will be activated when defining an NRI length greater than 0. Also, definition of the NRI length and own NRI values should be done on every MSC that will belong to the pool:

MGNDI:NRIL=6,NRIV=1&2&3; The command sets the NRI length to 6 and defines the NRI values 1 and 2 and 3.

Proxy table should be defined:

MGPTI:VLRADDR=4-35868765,NRIV=1; The VLR address is given in international format. The specified VLR address is added to the Proxy Table along with the given NRI value.

Neighboring MSC groups should be defined:

MGMGI:MSCG=MSCG,MSC=MSC1inpool; !New MSCG is defined with MSC1inpool as the first MSC belonging to MSCG in the MSC/VLR Server. MGMGI:MSCG=MSCG,MSC=MSC2inpool; MSC2inpool is added to the existing MSCG in the MSC/VLR Server. MSCG contains now two MSCs.

2.6.2.2 Definition in BSC

CNID should be defined for MSCs in pool:





RRMBI:MSC=MSC1inpool,SP=0-5-133,CNID=1024; !Core network identity is set to 1024 for MSCpool !!!Definition for each MSC in pool!!!

NRI length should be defined for MSCs in pool:

RRNLC:MSCNRILENGTH=6; !NRI length is set to 6 bits.

NRI values belonging to available MSCs should be defined:

RRNRI:MSC=MSC1inpool,NRI=0&&2; !This example defines the NRIs 0, 1 and 2 and associates them with the MSC designation MSC1inpool. !!!Definition for each MSC in pool!!!

MSC traffic distribution should be set:

RLTDC:MSC=MSC1inpool,MODE=ACTIVE; The mode for MSC1inpool is changed to active. !!!Definition for each MSC in pool!!!

RLTDC:MSC=MSC1inpool,CAP=20; RLTDC:MSC=MSC2inpool,CAP=10; RLTDC:MSC=MSC3inpool,CAP=30; The relative capacity value for MSC1 is changed to 20, for MSC2 the value is changed to 10, and for MSC3 the value is changed to 30. The traffic will then be distributed so that MSC1 gets 33% of the new traffic, MSC2 gets 17% of the traffic, and MSC3 gets 50% of the traffic.

2.6.2.3 Definition BSC/RNC related signaling and traffic data in the MSC/VLR

There are no changes in commands and parameters when defining signaling and traffic data for MSC in pool. The network topology instead is very different. The followings should be considered when building an MSC in pool network:

1. Building a new MSC in pool network:





• All BSC/RNCs have to be defined in all MSCs in the pool. This would comprehend: Hw definition (for signaling and traffic routes), Signaling data, BSC/RNC parameters and routes

• All MSCs shall have the same set of cell data: all the cells inside the pool have to be defined as inner cells in each MSC. cells neighboring the pool have to be defined as outer cells in each MSC.

• If LAI administration is used: all LAs inside the pool have to be defined in each MSC.

• If area cluster administration is available and used: all area clusters shall be defined in each MSC.

• No inter-MSC handover exists between the pool members.

2. Redefining an already existing network into a pool network

• All BSC/RNCs have to be redefined in all MSCs in the pool. This would comprehend: Hw definition (for signaling and traffic routes), Signaling data, BSC/RNC parameters and routes

The MSC level pool radio network configuration data needs to be distributed to all MSCs within the pool:

• The existing LAs in the MSC shall be extended with the LAs (excluding the ones containing neighboring cells) from the other MSCs. This step shall be executed only if the LAI administration function is used.

• The existing RNCs in the MSC shall be extended with the RNCs (excluding outer RNCs) from the other MSCs. The RNCs defined as outer in the MSC are still required for handover/SRNS relocation, as the pool is not operative yet.

• The existing area clusters in the MSC shall be extended with the area clusters from the other MSCs (excluding the ones containing elements which are neighbouring to the other MSCs that will constitute the pool).This step shall be executed only if area cluster administration is available and used. For the case and for the MSC(s) where either no area cluster administration is available or area cluster administration is available but not used, the equivalent configuration data at RNC(s) or LA(s) or both shall be set.





• The existing inner cells in an MSC shall be extended with the inner cells from the other MSCs with exception of cells from LAIs where outer cells (that will become inner cells later on) are defined. The outer cells are still needed for handover as the pool is not operative yet. Note: The inner cells belonging to BSCs outside of the pool must not be defined as inner cells in the MSCs, which are not connected with these BSCs.

• The existing outer cells/RNCs in an MSC shall be extended with the outer cells/RNCs from the other MSCs (with exception of the outer cells/RNCs that become inner cells/RNCs when the pool is built). Note: In case of some BSCs/RNCs outside the pool, then the outer cells or RNCs or both defined as outer that are related to these BSCs/RNCs should still be administered within the MSCs in the pool.

• Definition of the external to the pool cooperating VLRs associated to the recently defined external to the pool outer cells (LAIs):

• Definition of the remaining cell /RNCs and location area data in the MSCs:

Rearrange cell data in MSC is needed (inter-MSC handover between the MSCs to add to the pool will not work), all MSCs shall have the same set of cell data, so for every MSC has to be done:

• Remove the outer cells that shall be transformed into inner cells, Note: Outer cells belonging to BSCs or outer RNCs outside of the pool should not be removed.

• Define the former outer cells as inner cells. The former inter-MSC handover will become intra-MSC handover. The handover availability will increase as long as the former outer cells are defined as inner cells. Subsequent handovers will not work in this phase. Note: In case of an MSC serves also BSC outside the pool, inter-MSC handover may still be needed in case a subscriber moves from one MSC to the MC that exclusively controls the BSC outside the pool.

• Insert the remaining inner cells.

Rearrange RNC data in MSC (inter-MSC handover/SRNS relocation between the MSCs to add to the pool will not work). All MSCs shall have the same set of RNC data, so for every MSC do

• remove the outer RNCs that shall be transformed into own RNCs,





• define the former outer RNCs as own RNCs. The former inter-MSC handover/SRNS relocation will become intra-MSC handover/SRNS relocation. The handover/SRNS relocation availability will increase as long as the former outer RNCs are defined as own RNCs. Subsequent handovers/SRNS relocations will not work in this phase.

• Insert the remaining own RNCs

Remove cooperating VLR representing the MSCs in the pool.

In the BSCs/RNCs, define the NRI of the new defined MSCs. Note: Only for the BSCs/RNCs that belong to the pool

When the pool is operative the handover/SRNS relocation can be distributed between the pool members defining the corresponding neighboring MSC groups and modifying accordingly the outer cells/RNCs in the corresponding external MSCs .

Cooperating VLR addresses per NRI sets and LAI can be defined in the external to the pool MSCs at this stage if wanted.

Clean up hardware and data that is not needed anymore (handover numbers, MSC neighboring relations, inter-MSC routes….). This step can be executed any time after the pool is operative, as there are no traffic impacts. Note: In case an MSC also served a BSC/RNC outside the pool, it should be sure that all the required data and HW are in the place in order to be able to perform Handover/SRNS relocation between the MSCs in the pool.





IP transported signaling

SIGTRAN on IP bearer is used to transport the signaling for the MSC pool member controlling the BSC nodes in the MSC pool area.

Figure 6 : End-to-end SCTP associations between MSC pool members and M-MGW(s)





SIGTRAN signaling in each MSC pool member must support end-to-end SCTP associations to all the media gateways providing remote BSC access. The number of SCTP associations is equal to the number of BSC nodes in the MSC pool area times two (assuming two media gateways per BSC). SCTP associations are configured according to existing recommendations regarding SCTP redundancy (for example, support of multi-homing) as usual. An MSC pool member uses SLI boards to support SIGTRAN signaling. One SCTP end point is configured to terminate all the SCTP associations (M3UA) that the SLI board is handling. The number of SLI boards in an MSC pool member depends on the full signaling load in the MSC pool member and the SLI capacity. Each M-MGW providing BSC connection concentrates all the BSSAP signaling links. The SGW is used to convert the HSSL (or TDM) signaling to SIGTRAN and vice-versa. The MTP3 messages originated by the BSC are converted to M3UA messages (SGW) that are delivered to the correct MSC pool member (defined by the corresponding DPC) in the pool using the corresponding SCTP association (end-to-end association MGW<->MSC pool member). The M3UA messages originated by an MSC pool member are carried by the end-to-end SCTP association to the M-MGW (BSC connected) where they are converted to MTP3 messages that are delivered to the corresponding BSC. That is, the M-MGW(s) connected to a BSC must be dimensioned and configured to handle the traffic signaling through SGW for the BSSAP.

MSC pool and consistent M-MGW data configuration

Each BSC in the MSC pool area is physically connected to at least two M-MGWs. In order to support optimized connections between the subscribers in the MSC pool area (shortest connection paths), it is required that each MSC pool member is able to select and to control all the M-MGWs that are providing connections to the BSCs in the MSC pool area. That is, the data related to M-MGW selection (MGG, routes, and so on) must be configured in a consistent way in all MSC pool members.

For example, each MSC pool member must have a media gateway group MGG_BSCX that contains all the M-MGW nodes providing the connection for BSC-X in the MSC pool area (X=1, 2, 3, N). The corresponding BSC routes and restricted media gateway groups (one restricted MGG for each M-MGW providing BSC connection) must also be configured in a consistent way in all MSC pool members.

SIGTRAN definition is described in FAJ 121 294 R3 related document: Signaling Transport over IP (SIGTRAN), 5/190 46-FAD 104 50 Uen.

Charging

Charging will be handled in the Call Data Records (CDR) in the MSC in which the subscriber is registered independent of the current location of the subscriber.





3 Traffic Case

3.1 Location update in MSC in pool area

There are no changes in the external behavior of the node. The network architecture is different but an MSC node will continue to communicate with other nodes in the same way using the same interfaces.

The main idea in the pooled network concept is that a BSC/RNC can be connected to more than one MSC. This means that the originating traffic of the area served via a specific BSC/RNC is distributed via a certain algorithm to several MSCs.

When a UE moves into an MSC pool area (from outside) in idle mode, the UE performs a location update. The UE is registered in a random MSC pool member selected by the MSC selection function in the BSC. The MSC selection function distributes the new subscribers among the available MSC pool members based on their relative capacity. Each available MSC pool member receives a number of subscribers proportional to its relative capacity. In this case the location update implies HLR signaling. A TMSI with the NRI that identifies the MSC pool member is assigned to the UE. Now the UE uses this TMSI/NRI in the mobile originated transactions.

When a UE moves to new location areas within the MSC pool area in idle mode, the location update requests are always directed to the same MSC pool member (by the BSC TMSI based routing) where the UE is registered. The UE stays registered in the same MSC pool member as long as the subscriber is roaming within in the MSC pool area. Therefore, the changes of location areas within the MSC pool area do not require HLR signaling.

In the same way, mobile originated transactions that contain a TMSI with a defined NRI are directed to the correct MSC pool member by the TMSI based routing in the BSC.

A UE performs a location update when it moves outside the MSC pool area to a new MSC/VLR service area. The new MSC/VLR is able to request the security related data about the subscriber in the original MSC pool member (VLR) in two ways. • If the “new MSC/VLR” is pool aware, it is able to contact directly the

original MSC pool member by using the “enhanced co-operating VLR” functionality. In this case, the NRI in the TMSI is used to find the original MSC pool member (VLR).

• If the “new MSC/VLR” is not pool aware, it contacts the MSC pool member that corresponds to the LA (LA->MSC). This MSC pool member has a proxy function. The “proxy MSC/VLR” forwards the request to the original MSC pool member using the TMSI/NRI. The proxy VLR tables must contain all the NRI values for the pool.





The configuration example below, a proxy MSC/VLR which relays signaling from an MSC/VLR node, which only can derive one co-operating MSC/VLR address per LA, to an MSC/VLR serving in an MSC pool in LAI_1. In this example, the proxy MSC/VLR 2 has been configured as co-operating MSC/VLR in LAI_1 in MSC/VLR x. MSC/VLR x sends a MAP message to the proxy MSC/VLR 2, which then derives NRI_3 from the old TMSI provided in the MAP message, and then routes the MAP message to the MSC/VLR with NRI_3, according to the proxy table in the proxy MSC/VLR 2.

Figure 5 : Proxy MSC Defined in an MSC Pool Serving LAI_1

3.2 Handover / SRNS Relocation

In active mode the subscriber can move around the whole MSC pool area and there is no inter-MSC handover between the MSC pool members (only intra MSC handover).

If the subscriber initiates a call outside of the MSC pool area (anchor MSC not a MSC pool member) and the subscriber moves into the MSC pool area in active mode, there is an inter-MSC handover to a neighbour MSC pool member. When the UE becomes idle, the UE performs a location update and it is registered in some random MSC pool member (based on the MSC selection function in BSC).





3.2.1 Neighboring MSC groups

In order to improve the load distribution algorithm during inter-MSC HO into a pool, it is possible to define neighboring MSC Groups (MSCG):

Neighbouring MSCG is a cluster of neighbouring MSCs grouped together for inter-MSC handover/relocation purposes towards an MSC Pool. It is not mandatory for a neighbouring MSCG to contain all the MSCs in an MSC Pool.

The neighbouring MSCG concept gives the possibility to handle the load on MSCs inside the MSC Pool by routing the Mobile Station during the handover to MSC Pool to the desired group of MSCs.

16 MSCs can be defined in a neighbouring MSCG.

Figure 7: Neighbouring MSC groups in the MSC Pool

MGMGI:MSCG=MSCG1,MSC=MSC1; MGMGI:MSCG=MSCG1,MSC=MSC2; MGMGI:MSCG=MSCG1,MSC=MSC3;

MGMGI:MSCG=MSCG2,MSC=MSC3; MGMGI:MSCG=MSCG2,MSC=MSC4; MGMGI:MSCG=MSCG2,MSC=MSC5;

3.2.2 Subsequent Handover/SRNS Relocation to Third MSC, Anchor MSC

In case of a subsequent handover/SRNS relocation to a third MSC that belongs to the same pool area with the anchor MSC then the anchor MSC will handle this subsequent handover/SRNS relocation instead of the third MSC.





Figure 8: Subsequent Handover/SRNS Relocation to Third MSC Belonging to the Same Pool Area with the Anchor MSC

3.2.3 Handling of Handover/SRNS Relocation in Non-anchor MSC

In the subsequent handover/SRNS relocation to third MSC, the nonanchor MSC will check the target cell/RNC and if the target cell/RNC belongs to the anchor MSC, a subsequent handover/SRNS relocation back to anchor is performed.

Figure 9: Subsequent Handover/SRNS Relocation from the Non-anchor MSC to Third MSC Belonging to the Same Group with the Anchor MSC

MSC

MSC

MSC

MSC

Pool area

2nd HO

1st HO

Anchor

Third

Non-anchor

MSC

MSC

MSC

Pool area 1

Anchor

Third

MSC

MSC

MSC

Pool area 2

Non-anchor

1st HO

2nd HO

2nd HOX





4 Data Transcript Impacts – MSC

4.1 AXE Parametrs

!MSC/VLR server in MSC-Pool (0=feature disabled, 1=feature enabled)! DBTRI; DBTSC:TAB=AXEPARS, SETNAME=GSM1APTF, NAME=MSCPOOL, VALUE=1; DBTRE:COM;

!Maximum number of trials to select MSC from the neighbouring MSC group.! !Applicable when target MSC is an MSC Pool (Value Range: 1-16, default ! !value=1)! DBTRI; DBTSC:TAB=AXEPARS, SETNAME=GSMMMSC, NAME=MSCREQNUM, VALUE=1; DBTRE:COM;

!Administration for Handover to MSC in pool (1=activate)! DBTRI; DBTSC:TAB=AXEPARS, SETNAME=GSMMMSC, NAME= ADMHOMSCPOOL, VALUE=1; DBTRE:COM;

!Define CN-id of the global CN-id of an MSC/VLR (Value range 0-4095)! DBTRI; DBTSC:TAB=AXEPARS, SETNAME=GSMMMSC, NAME=OWNCNID, VALUE=0; DBTRE:COM;

!Mobile Country Code! DBTRI; DBTSC:TAB=AXEPARS, SETNAME=GSM1APTC, NAME= OWNMCCM, VALUE=364; DBTRE:COM;

!Mobile Network Code! DBTRI; DBTSC:TAB=AXEPARS, SETNAME=GSM1APTC, NAME= OWNMNCM, VALUE=12; DBTRE:COM;





!The time supervision value during the handling of the changes in the ! !Network Resoucer Identifier (NRI) list in MSC/VLR server. ! !Value shall be greater or equal than the duration of timer used for periodic ! !location updating. ! !Dependent on: MSCPOOL GSM1APTF ! !Value range 1-255 ! !Default value 255 ! DBTRI; DBTSC:TAB=AXEPARS, SETNAME=GSMMDSC, NAME=TIMNRICHGM, VALUE=255; DBTRE:COM;

The table AXEPARS is protected by password, which is beyond the scope of this document.

4.1.1 Subfile 10000 Size Alteration APT

! MTRAN global events ; SAAII:SAE=132, NI=200; !Number of Cells! SAAII:SAE=255, NI=2; !Nunber of BSCs! SAAII:SAE=274, NI=3; !Nunber of Neighbouring MSCs! SAAII:SAE=448, NI=3; !Nunber of cooperating VLRs! SAAII:BLOCK=MTRAN, SAE=1100, NI=2; !Nunber of RNCs! SAAII:BLOCK=MTRAN, SAE=1137, NI=200; !Nunber of Areas! SAAII:BLOCK=MTRAN, SAE=1141,NI=10; ! Neighbouring MSCGs ! SAAII:BLOCK=MCVLRD,SAE=500,NI=8; !setting for NRIL=3! SAAII:BLOCK=MCVLRD,SAE=602,NI=20; ! number of LAIs=20! SAAII:BLOCK=MCVLRD,SAE=603,NI=200; !NLAIs * 10! SAAII:BLOCK=MCVLRD,SAE=629,NI=100; ! NVLR * NLAI ! SAAII:BLOCK=MCVLRD,SAE=630,NI=300; ! NNRI * NVLR * NLAI ! SAAII:BLOCK=MBSSD,SAE=285,NI=24; ! NLA + NLAO ! SAAII:BLOCK=MBSSD,SAE=611,NI=300; ! NAreaClusterElements ! SAAII:BLOCK=MBSSD,SAE=612,NI=1; ! NPLMN ! SAAII:BLOCK=MBSSD,SAE=687,NI=568; ! DIG*(1+(N-1)*FDIV)! SAAII:BLOCK=MBSSD,SAE=688,NI=277; ! 9*(1+(100-1)*0.3)!





4.1.2 Subfile 77200 MSC Pool

! Definition of Proxy Table !

MGPTI: VLRADDR=46 70 747 0000, NRIV=1&2&3;

! Definition of Cooperating VLRs !

MGCVI:VLR=MSCVLR, VLRADDR=4-46 70 747 0000, MAPV=MAP-3, LAI=262-02-71, NRIV=1&2&3, NRIL=10 ;

! Definition of neighbouring MSC-Groups !

MGMGI: MSCG=MSCG1, MSC= MSC1; MGMGI: MSCG=MSCG1, MSC= MSC2;

! Definition of NRI Data !

MGNDI:NRIL=3, NRIV=1&2&3;

5 Data Transcript Impacts- HLR

6 Miscellaneous information

References

1. MSC in Pool DT description GSM R11 10/190 46-FAD 109 1001 rev.A

2. Optional New and Enhanced Features in MSC R12 221 04-FGC 101 790 Rev C

3. MSC in Pool in MSC User Description





7/1553-APR 101 49/2 Uen Rev A

4. MSC Pool User Description 19/1553-HSD 101 73/2 Uen Rev A

5. Alex MSC R12, WCDMA R5/GSM LSV28 EN/LZN 701 0094 P21A

6. MSC, TSC and STP WCDMA/GSM R12 Network Impact Report 10948-AXE 106 30/2 Uen Rev A

7. MSC in Pool for WCDMA Enhancements, MSC R12 – Implementation Proposal 129/159 41-FCPW 101 97/F Uen Rev A

7 Class

MSC in pool - FAJ 121 297 R2 is a standard, optional feature enhanced in R12.

mip dt infomodel

Documents