A-Flex and A-Signalling Over IP in B11

A-Flex and A-signalling over IP in Release B11
Alcatel-Lucent File Reference Date Edition Page

FFUV7OE3.DOC 3DC 21144 0132 TQZZA 23/01/2009 03 1
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization.

Functional Feature Description
A-Flex and A-Signalling over IP
In Release B11


Contents
1. INTRODUCTION .................................................................................................. 3
1.1 Scope ...................................................................................................... 3
1.2 Rationale.................................................................................................. 4
1.3 References................................................................................................ 4
2. GENERAL DESCRIPTION ......................................................................................... 5
2.1 End-to-End architecture................................................................................ 5
2.2 Feature Benefits......................................................................................... 5
3. A-FLEX DETAILED DESCRIPTION ............................................................................... 7
3.1 3GPP Standards .......................................................................................... 7
3.2 A-Flex concepts.......................................................................................... 7
3.2.1 CS pool area.................................................................................... 7
3.2.2 Network Resource Identifier (NRI).......................................................... 8
3.3 Non Access Stratum (NAS) Node Selection Function .............................................. 9
3.3.1 MS Access ....................................................................................... 9
3.3.2 Network sending PAGING..................................................................... 9
3.4 Load Balancing function...............................................................................10
3.5 Load Re-Distribution function........................................................................10
4. A SIGNALLING OVER IP DETAILED DESCRIPTION ...........................................................11
4.1 Overview.................................................................................................11
4.2 Telecom flows and IP Endpoints .....................................................................12
4.3 Network Architecture for A signalling Over IP ....................................................12
4.4 Redundancy management.............................................................................14
5. OPERATION AND MAINTENANCE..............................................................................15
5.1 A-Flex Parameters......................................................................................15
5.2 A-Signalling over IP Configuration...................................................................16
6. HW COVERAGE AND DEPENDENCIES .........................................................................18
7. GLOSSARY........................................................................................................19

1. INTRODUCTION
1.1 Scope
The present functional feature description provides detailed information about the features A-Flex
and A-signalling over IP:
15 13 24 A-Flex
15 13 22 A Signalling over IP
Both features are optionally introduced from the Alcatel-Lucent BSS release B11 onwards.
The description includes:
An overview of the features,
A description of the implementation within the BSC,
A description of end-to-end architecture between the BSS and the CS Core Network.

Preliminary notice
The information contained in this document is subject to change without notice.

Notice of proprietary information
This document contains proprietary technical information belonging to Alcatel-Lucent. By
accepting this material, the recipient agrees that this material will not be reproduced or used in
whole or part except as otherwise agreed between Alcatel-Lucent and the recipient.

1.2 Rationale
On the core network side, Operators are transitioning to NGN architecture with separate
management of control plane (CP) and user plane (UP). The CP (i.e. signalling) is managed by the
MSC Server (MSC-S) while the UP (User traffic) is handled by the Media Gateway (MGW).
MSC Server can reach much higher capacity than legacy MSC, so the failure of an MSC Server can
have very important impacts on the network availability for a very high number of subscribers.
Therefore, the A-Flex feature is interesting for Operators migrating to NGN, as BSC can be
connected to several MSC Servers, which allows limiting capacity losses in case of MSC Server site
disaster.
The backbone of the NGN is based on IP technology mostly. The A-signalling over IP feature
extends the IP based transport on the control plane down to the BSC and supports the general
trend to IP based inter-connection layers. The feature provides a high flexibility for BSS to connect
to NGN and makes the introduction of the A-flex functionality much easier and future proof than
the combination of A-flex with TDM transport. This strategy avoids the introduction of several SS7-
MSC instances (one MTP3 instance per MSC, one MTP2 link set per MSC).
The A-signalling over IP feature is based on SIGTRAN protocol stacks already in use in the NGN
core. Therefore limited interoperability issues are expected between BSC and MSC Server. The A-
signalling over IP feature complements also the Alcatel-Lucent native IP transport in the BSS. Both
functionalities can be introduced independently.

1.3 References

[1] 3DC 21144 0130 TQZZA FFD: Native IP Transport in the BSS
[2] 3GPP TS 29.202 SS7 Signalling Transport in Core Network; Stage 3
[3] 3GPP TS 23.236
Intra-domain connection of Radio Access Network (RAN) nodes to
multiple Core Network (CN) nodes
[4] 3GPP TS 23.003 Numbering, addressing and identification
[5] 3GPP TS 24.008
Mobile radio interface Layer 3 specification;
Core network protocols; Stage 3
[6] RFC 4666
Signalling System 7 (SS7) Message Transfer Part 3 (MTP3) - User
Adaptation Layer (M3UA)
[7] RFC 2960 Stream Control Transmission Protocol (SCTP)

2. GENERAL DESCRIPTION
2.1 End-to-End architecture
The A-Flex feature belongs to the circuit switched domain. It allows the connection of a BSC to
several MSC Servers for the CS signalling. In the Alcatel-Lucent implementation, A-Flex relies on
the feature A-signalling over IP. The end-to-end architecture is shown in the figure below.

IP Backbone
A signalling over IP
+
A-Flex
MSC server2
9130 BSC1
MSC server1
9130 BSC2
Media Gateways
9125 TC
User CS traffic over TDM
User CS traffic over TDM

Figure 1: Alcatel-Lucent A-Flex end-to-end architecture with A Signalling over IP
Note: It is not in the scope of the figure to show the exhaustive NGN connections. Also each BSC can be connected to one or several
MGW, without any impact on the BSS.
2.1.1 Feature Benefits
The A-Flex feature brings the following benefits:
Reduction of the signalling load in the core network: Signalling between the MSC/VLR
and HLR due to Location Update and inter-MSC handover procedure become necessary only
when MS leave the CS pool area (see 3.2.1).
Better MSC resilience: with A-Flex feature a BSC can be connected to several MSC Servers
for the handling of A-signalling. As a consequence if an MSC Server fails the remaining MSC
Servers can take over new service requests and maintain the service availability.
Better signalling load balancing between MSC Servers.

Easier Core network expansion: if the core network capacity needs to be increased,
there is no need any more to reconfigure the radio network. The existing LA/RA
configuration can be kept. It is sufficient to add a new MSC to the CS pool area with the
same radio configuration as the other MSCs of this CS pool area.
The benefits of A-signalling over IP feature are:

Easier configuration of signalling links on A interface using Ethernet connectivity of Alcatel-
Lucent 9130 BSC evolution
Reduced transmission OPEX
Support of multiple SS7 end points facilitating A-Flex configuration.

3. A-FLEX DETAILED DESCRIPTION
3.1 3GPP Standards
A-Flex has been standardized in 3GPP Rel-5 (3GPP TS 23.236 (Ref. [3])).
3.2 A-Flex concepts
3.2.1 CS pool area
A CS pool area is an area within which a MS may roam without need to change the serving MSC
Server. A CS pool area is served by one or more MSC Servers in parallel.

MSC server2
MSC server1
MSC server3
MSC server5
MSC server4
MSC server6
Area 1
9130 BSC1
Area 2
9130 BSC2
Area 3
9130 BSC3
Area 5
9130 BSC5
Area 6
9130 BSC6
Area 7
9130 BSC7
CS pool area 1
CS pool area 2
MSC server2 MSC server2
Area 1
9130 BSC1
Area 1
9130 BSC1 9130 BSC1
Area 2
9130 BSC2
Area 2
9130 BSC2 9130 BSC2
Area 3
9130 BSC3
Area 3
9130 BSC3 9130 BSC3
Area 5
9130 BSC5
Area 5
9130 BSC5 9130 BSC5
Area 6
9130 BSC6
Area 6
9130 BSC6 9130 BSC6
Area 7
9130 BSC7
Area 7
9130 BSC7 9130 BSC7
CS pool area 1
CS pool area 2

Figure 2: A-Flex network architecture
Figure 2 gives an example of CS pool-area configuration. It contains CS pool-area 1 (area 1, 2, 5, 6
served by MSC Servers 1, 2, 3), CS pool-areas 2 (area 2, 3, 6, 7 served by MSC Servers 4, 5, 6).

All the cells controlled by a BSC belong to the same (one or more) CS pool area(s). For
example, all the cells controlled by BSC 1 belong to the CS pool-area 1. The possibility to
configure overlapping pool-areas is shown by the CS pool-areas 1 and 2: the BSC 2 and 6
belong to CS pool-areas 1 and 2.
The serving MSC Server is allocated by the BSC when the MS enters the CS pool-area (see 3.3 for
details). An MS is served by the same MSC Server of a CS pool-area as long as it remains in the
radio coverage of this CS pool-area.
Notes:
In the Alcatel-Lucent implementation, a BSC can be connected to up to 16 MSC.
If a physical MGW is connected to more than one MSC Server, the MGW is required to
support the feature Virtual MGW.
3.2.2 Network Resource Identifier (NRI)
The Network Resource Identifier (NRI) identifies uniquely an individual MSC out of all MSC which
serve in parallel a CS pool-area. In areas where CS pool-areas overlap the NRI identifies uniquely a
MSC out of all MSC which serve all these overlapping pool-areas, i.e. an NRI identifies uniquely a
MSC within a BSC.
When A-Flex is used, the NRI is included in the TMSI. The TMSI consists of 4 octets as shown below:
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 & TIME
NRI
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 & TIME
NRI
31 31 30 30 29 29 28 28 27 27 26 26 25 25 24 24 23 23 23 22 22 22 21 21 21 20 20 20 19 19 19 18 18 18 17 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 99 88 77 66 55 44 33 22 11 00
CS/PS CS/PS VLR-restart & TIME VLR-restart & TIME
NRI NRI NRI

The standards allow Operators to define the NRI length and the NRI values.
The Operator defines the NRI length according to the number of MSC Servers in an MSC pool: each
MSC Server in the pool must have a unique NRI. The NRI has a configurable length of 0 to 10 bits (a
length of 0 bits indicates that the NRI is not used and A-Flex feature is not activated in the MSC).
The length of the NRI is the same in all MSC of a given CS pool area. In case of overlapping pool-
areas the NRI length is the same in all the MSC of related overlapping pool-areas. The bits of the
TMSI that are significant for the NRI are configured in the OMC-R. Once the NRI length set to n bits
for instance, the number of available NRI values is 2
n
-1 (one value is reserved for NULL_NRI).
It may happen that for a defined NRI length, a given MSC Server reaches TMSI shortage. In that
case, it is possible to define several NRI values for this MSC Server to increase the number of
available TMSI. In Alcatel-Lucent implementation, one MSC Server can handle up to 8 NRI.

One unique NRI called NULL_NRI is reserved per network (i.e. per PLMN). This NRI is not linked to
any MSC Server. It is used by the load re-distribution procedures as explained in 3.5.
3.3 Non Access Stratum (NAS) Node Selection Function
The NAS Node Selection Function is a new routing function implemented in the BSC. Its purpose is
to assign a specific MSC Server to serve an MS and to route its signalling messages to this MSC
Server as long as the MS remains in the same CS pool-area.
The NAS Node Selection Function examines the content of the Layer 3 message (e.g. 24.008 CM
SERVICE REQUEST) coming from MS or MSC Servers.
3.3.1 MS Access
An MS may access the network to send Layer 3 messages such as: PAGING RESPONSE; LOCATION
UPDATING REQUEST; IMSI ATTACH/DETACH INDICATION; CM SERVICE REQUEST; CM Re-
Establishment Request; etc.
When an MS has already been assigned a TMSI by the Core Network, the MS sends Layer 3 messages
with TMSI included. The BSC derives the NRI from the TMSI and routes the Layer 3 messages
according to the NRI to the relevant MSC. The association between NRI values and MSC addresses
(MSC Signalling Point Code) is configured in the BSC.
When the BSC receives a message with a NULL_NRI it uses the load balancing function for re-
routing the received message to one of the MSC servers connected to the BSC.
If the NRI derived from the TMSI is unknown by the BSC, it uses the load balancing function to
select an MSC Server.
The MSC servers being off loaded (see 3.4) are excluded from the load balancing by the BSC.
3.3.2 Network sending PAGING
The network may send PAGING Layer 3 messages to an MS with its IMSI included.
There are two cases:
If PAGING (with only IMSI) is received from the MSC Server via A-interface, then the BSC
saves the MSC address (MSC Signalling Point Code MSC SPC) and IMSI.
If CS PAGING (with only IMSI) is received from the SGSN via Gs-interface, then the BSS
saves MSC address (MSC_CN_ID) and IMSI.

When the BSC receives a PAGING RESPONSE (with only IMSI) from the MS, the BSC checks its
internal mapping table (IMSI/SPC; or IMSI/MSC_CN_ID) to find the MSC address corresponding to
the IMSI. If no such MSC is found, the BSC uses the load balancing function to assign an MSC Server
to the MS.
If there is neither TMSI nor IMSI included, the BSC selects an MSC Server using the load balancing
function.
3.4 Load Balancing function
When the BSC does not know to which MSC Server an MS is assigned, it chooses an MSC Server with
the target to keep a fair load balancing among all its connected MSC Server.
In the Alcatel-Lucent implementation, each MSC Server is assigned a weight, configurable from
OMC-R (MSC_WEIGHT parameter). The different MSC Servers connected to the BSC are selected
proportionally to their weight. For instance, an MSC Server with a weight 10 is selected twice
more often than an MSC Server with a weight 5.
A MSC Server is not selected in the following cases:
The MSC Server is not operational; or
The MSC Server is off loaded (i.e. a parameter configurable from the OMC-R
(MSC_OFFLOAD_STATE) allows the Operator to set an MSC-S to off loaded or on loaded.
This is used for load re-distribution function as explain in 3.5); or
The MSC Server is on loaded & operational & overloaded, and there is at least one MSC
Server connected to the BSC who is on loaded & operational & normal load.
3.5 Load Re-Distribution function
This function allows the Operator to remove load from one MSC Server (this means preventing this
MSC Server to handle new calls), in order to remove definitively an MSC Server from an MSC pool
for instance. The Operator triggers the Load Re-Distribution function by O&M actions both on BSC
and MSC.
From a BSS perspective, the Operator sets the MSC_OFFLOAD_STATE parameter of the MSC Server
to off loaded from the OMC-R.
During the Load Re-distribution, the MSC Server being off-loaded sends messages with new TMSI
with NULL_NRI embedded. Upon reception of its new TMSI, the MS sends message with NULL_NRI
to the BSC. The BSC then uses the load balancing function to assign a new MSC Server to the MS.
When the MSC Server is free of traffic (i.e. all MS have been reallocated to other MSC Servers in
the MSC pool), the Operator can safely remove it.

4. A SIGNALLING OVER IP DETAILED DESCRIPTION
4.1 Overview
The purpose of A-signalling over IP is to replace the legacy SS7 network by an IP network for the
transport of signalling on A interface, between the BSC and the MSC Server. Figure 3 illustrates the
usage of A-signalling over IP (with the example of a TDM based BSS and A user plan over TDM).
The A-signalling over IP feature also applies to BSS network where IP transport in BSS is activated.
M3UA
M3UA
SCCP BSC
Eth.
Eth.
A itf
TDM MSC Server
Eth.
TDM
IP backbone
User Plane
A-Signalling over IP
M3UA SCCP M3UA SCCP
MGW TC

Figure 3 TDM BSS with A-signalling over IP
The protocol stack to transfer BSSAP messages over IP is shown in Figure 4.
BSSAP
SCCP
M3UA
SCTP
BSSAP
SCCP
M3UA
SCTP
IP
BSS
MSC

Figure 4: Protocol Stack for A Signalling Over IP
A signalling over IP uses the Alcatel-Lucent 9130 BSC Ethernet connections.

4.2 Telecom flows and IP Endpoints
In the BSC, the IP endpoints for A signalling over IP are managed by the OMCP.
IP Backbone
BSC
OMCP
SSW
A signalling over IP
MSC Server MSC Server

Figure 5: Telecom flow and IP endpoints for A signaling over IP
Note: In the case of A-signalling over IP, the O&M flow between the BSC and the OMC-R cannot be
conveyed on timeslots of Ater interface. Like for the A-signalling flow, the Ethernet connectivity of the
BSC is used.
4.3 Network Architecture for A signalling Over IP
A-signalling over IP introduces the following new layers below the SCCP layer:
Message Transfer Part 3 User Adaptation (M3UA) [6]. Implemented at the same level as
MTP3, M3UA defines a protocol for supporting the transport of any SS7 MTP3 user signalling
(e.g. ISUP or SCCP messages) and provides the equivalent set of primitives as used by MTP3
to its local MTP3 users at an SS7 signalling endpoint.
The Stream Control Transport Protocol (SCTP) [7] is an IP transport protocol
implemented at the same level than TCP or UDP. The basic service offered by SCTP is a
reliable transfer of user messages between peer SCTP users (i.e. signalling messages
between BSC and MSC Server). SCTP is connection oriented. It establishes first a
connection (called SCTP association) between two endpoints before transmitting data.
M3UA elements definition:
An Application Server (AS) can be a BSC or an MSC Server.

The IP Server Process (IPSP) is the physical entity managing the SCTP associations. One AS can
have one or several IPSP.
The SCTP Association is an association established between two IPSP belonging to different AS
(i.e. BSC and MSC Server).
There is one IPSP in the BSC side per MSC. A BSC can be connected to more than one MSC Server.
Each MSC Server can have more than one IPSP to handle a given BSC. On BSC side, all the IPSP have
the same IP address. Different port numbers distinguishes the IPSP. Figure 6 illustrates the
connections between the BSC and the MSC Server.

Figure 6: Connections between BSC and MSC Server

The way the signalling is transferred on the IPSP depends on the transport mode of the AS. The
possible transport modes used by one AS are defined by TRAFFIC_MODE parameter and can
be:
o Broadcast mode: the IPSP receives the same messages as any other currently
active IPSPs.

o Override mode: only one of the IPSPs takes the traffic whatever the number of
IPSPs.
o Load-Sharing mode: the IPSP shares the traffic with any other currently active
IPSPs. The parameter MIN_NB_ACTIVE_IPSP defines the minimum number of active
IPSPs in the MSC Server required to handle the traffic with that MSC in load-sharing
mode.
4.4 Redundancy management
The BSC can be connected to two routers connected with VRRP (Virtual Router Redundancy
Protocol). The BSC has two switch boards, each of which is connected to one router. There is only
one external IP address for the BSC. In case of router failure, there is a take over by the other
router. The IPSP also benefits from the internal redundant BSC architecture, so that the IPSP is
always on the active OMCP board (if an OMCP fails, the IPSP is moved to the stand-by OMCP). Please
refer to [1] for more details.
When the MSC SCTP endpoint has more than one IP address, multi-homing can be applied on MSC
side. Alcatel-Lucent BSC can make use of MSC Server multi homing capability to establish a SCTP
association using two different IP addresses at MSC Server side. Only one path (i.e. one IP address) is
active at a time. SCTP supervises both paths. When the active path fails, SCTP switches path
without breaking the SCTP association.

5. OPERATION AND MAINTENANCE
5.1 A-Flex Parameters

Parameter name Definition Instance Range
EN_A_FLEX
Enables or disables the A-Flex
feature.
BSC 0: disabled
1: enabled
MSC_CN_ID
Core Network identifier:
PLMN-Id + CN-Id.
MSC 0 to 4095
MSC_SPC
MSC Signalling Point Code. MSC 0 to 16383
MSC_WEIGHT Weight assigned to the MSC for load
balancing function.
MSC 1 to 255
NRI_LIST List of NRI. MSC 0 to 1024
NULL_NRI
Please refer to 3.2.2 BSC 0 to 1023
NRI_LENGTH Length of NRI inside TMSI. BSC 1 to 10
MSC_OFFLOAD_STATE State assigned to a given MSC,
connected to the BSC, for the load
redistribution function.
MSC
0: off loaded
1: on loaded

5.2 A-Signalling over IP Configuration

Parameter name Definition Instance Range
EN_ASIG_OVER_IP
Enables or disables the A Signalling
Over IP feature.
BSC 0: disabled
1: enabled
TRAFFIC_MODE
MSC traffic mode.
override mode (i.e. only one of the
IPSPs handle the traffic)
broadcast mode (i.e. all the active
IPSPs receive the same messages)
load sharing mode (i.e. the traffic is
distributed over all the active IPSPs)

MSC 0: override mode
1: broadcast
mode
2: loadsharing
mode
MIN_NB_ACTIVE_IPSP
The minimum number of active IP
server process (IPSP) in the MSC
server required to handle the traffic
with that MSC. (Significant when MSC
is in load sharing mode)
MSC 1 to 4
LOCAL_ASIG_SCTP_END
POINT_IP_Address_1
Local primary IP adress of a SCTP
endpoint (used by M3UA protocol) of
the BSC.
BSC 0 to 4294967295
LOCAL_ASIG_SCTP_END
POINT_PORT
Local TCP port of a SCTP endpoint
(used by M3UA protocol) of the BSC.
BSC 61953 to 61999
ASIG_SCTP_ENDPOINT_L
IST

List of the SCTP endpoints (used by
M3UA protocol) of the MSC. Each
entry is an SCTP endpoint, composed
of
ASIG_SCTP_ENDPOINT_IP_Address_1,
ASIG_SCTP_ENDPOINT_PORT and
ASIG_SCTP_ENDPOINT_IP_Address_2
MSC 0 to 4294967295

ASIG_SCTP_ENDPOINT_I
P_Address_1

Primary IP address of a SCTP endpoint
(used by M3UA protocol) of the MSC.

SCTP
EndPoint

0 to 4294967295
ASIG_SCTP_ENDPOINT_I
P_Address_2
Secondary IP address of a SCTP
endpoint (used by M3UA protocol) of
the MSC.
It is an optional address used in case
of SCTP multi Homing in MSC side.
SCTP
EndPoint

0 to 4294967295
ASIG_SCTP_ENDPOINT_
PORT

Port of a SCTP endpoint (used by
M3UA protocol) of the MSC.
SCTP
EndPoint

0 to 65535

6. HW COVERAGE AND DEPENDENCIES
The A-Flex and A-signalling over IP features are supported on 9130 BSC evolution. They are not
supported on 9120 BSC G2. They have impacts on the Core Network.
A-Flex is available with A-signalling over IP. A-Flex over TDM is not supported.

7. GLOSSARY

End of Document
BSS Base Station Subsystem
CIC (A interface) Circuit Identification Code
CN Core Network
CNE Core Network Element (MSC server, SGSN, etc)
GPRS General Packet Radio Service
GSM Global System for Mobile communications
MFS Multi-BSS Fast packet Server
NAS Non Access Stratum
NASNSF Non Access Stratum Node Selection Function
NGN Next Generation Network
NRI Network Resource Identifier
OPC Originating Point Code (ITU-T Q.701 - Q.704)
SCCP Signalling Connection Control Part
SCTP Stream Control Transmission Protocol (RFC 2960)
SGSN Service GPRS Support Node
SIGTRAN SIGnalling TRANsport
SPC Signalling Point Code (ITU-T Q.701 - Q.704)
STP Signalling Transfer Point
TC TransCoder

A-Flex and A-Signalling Over IP in B11

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

A-Flex and A-Signalling Over IP in B11

Caricato da

Copyright:

Formati disponibili

A-Flex and A-signalling over IP in Release B11

Alcatel-Lucent File Reference Date Edition Page

Potrebbero piacerti anche