[Seminar5]_AsigOverIP

B11 MR1 Ed1

Seminar of GSM Network Engineering

A Signalling over IP

João Frade

March 2010

Agenda

1.Theoretical overview

2.Feature activation & compatibility with previous HW

3.Telecom parameters, counters & Indicators

4.Feature Impact on Tools

5.Test strategy

6.Reference documentation

7.Annex

3 | B11 A Signaling over IP | March 2010 © Alcatel-Lucent 20103 | B10 mCCCH | September 2008

1Theoretical Overview

4 | B11 A Signaling over IP | March 2010 © Alcatel-Lucent 2010

Introduction

As operators began their migration to an Internet Protocol (IP) backbone, the need to transport the ISDN User Part (ISUP) and the Transaction Capabilities Application Part (TCAP) using the Transmission Control Protocol/Internet Protocol (TCP/IP) became mandatory.

The Internet Engineering Task Force (IETF) has defined a new set of TCP/IP-based protocols (SIGTRAN) specifically for use in transporting SS7 (level 4 protocols) over TCP/IP networks.

The main difference between the Message Transfer Part (MTP) and SIGTRAN (which is an acronym for Signaling Transport) lies in the procedures and connection management.

In addition, the SIGTRAN protocols provide an additional level of security not found in existing IP transport.

B11 - A SIGNALING OVER IPTheoretical Overview


The purpose of this feature is to transfer the SS7 signaling over the IP network between the BSC and NGN core network.

A Signalling Over IP supports BSC to be connected to multi MSCs.

The benefits of this feature include:

Improvement of the signaling transfer reliability and lower transfer delay.

Higher signalling transfer bandwidth.

Simple network configuration and flexible network structure.

It supports multi remote SS7 end points to be connected to BSC.



The basic idea is to separate the control plane and user plane in the core network. The legacy MSC is replaced by MSC server (control plane) and MGW (user plane).

A signaling over IP is implemented for MSC server in the NGN network. A signaling is not working on TDM and IP in the same time.


M3UA M3UASCCPBSC

Eth.

Aitf

TDM MSC Server

.

IP backbone

User Plane

A Signalling over IP(Control Plane)

M3UASCCP M3UA SCCP

MGWTC

Eth.Eth.

TDM


SS7 protocol stack for TDM and IP mode M3UA stands for MTP3 - User Adaptation Layer

SCTP is Stream Control Transmission Protocol

TC

BSC

BSSAP

SCCP

MTP3

MTP2

MTP1

MSC

BSSAP

SCCP

MTP3

MTP2

MTP1

N7 Links

TDM Mode

BSSAP

SCCP

M3UA

SCTP

IP

Ethernet

BSSAP

SCCP

M3UA

SCTP

IP

Ethernet

IPIP

BSC MSC Server

IP ModeSS7 Protocol Stack



In IP mode, as recommended by 3GPP TS 29.202, the M3UA protocol based on SCTP protocol is used to transfer SCCP signalling instead of the MTP. A Signalling transfer with M3UA is a 3GPP release 7 feature.

Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a potentially unreliable connectionless packet service such as IP.

Validation and acknowledgment mechanisms

Detection of data corruption, loss of data and duplication of data is achieved by using checksums and sequence numbers.

A selective retransmission mechanism is applied to correct loss or corruption of data.

It is according to RFC 2960 with the CRC correction in RFC.



A signalling over IP is the requirement to provide more flexibility of BSS to access NGN network. IPSP means IP Server Process

M3UAM3UA

SCTPSCTP

IPIP

IPSPIPSPBSCBSC M3UAM3UA

SCTPSCTP

IPIP

IPSP1IPSP1

M3UAM3UA

SCTPSCTP

IPIP

IPSP2IPSP2

MSC ServerMSC Server

IPIP



There is one IPSP in BSC side per MSC, and the IPSP is located in the OMCP working in active standby mode.

Based on the RFC 4666, related to M3UA usage in BSC, there are the corresponding objects: AS IPSP (ASP) Association

AS

IPSP1 IPSPn

Association 1

Association k

…………

…………

Hierarchy of Objects for M3UA

AS = Application serverASP = Application server process IPSP = IP Server Process



The Telecom function is essentially implemented in the BSC by M3UA/SCTP.

The M3UA in BSC and MSC works in the peer-to-peer mode, the mapping of BSC objects and M3UA corresponding concepts is like below:

The AS (Application server) is a logical entity and one AS can have one or several IPSPs. It is used to indicate one SS7 signaling point.

– One BSC is one AS. – For the BSC, each MSC is a separate remote AS.

The ASP (Application Server Process) is a process instance of an Application Server.

The IPSP (IP server process) is one process that handles the M3UA/SCTP. – IPSP is the physical entity managing the SCTP associations.

– An IPSP is essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion.

The connection between two SCTP end points is referred to as association. Each association has a set of streams in which the message is transferred in sequence.



Definitions SCTP protocol is used for the M3UA message transfer. The features of the

SCTP include:– Support multi-homing.

– Support multi streams in one association. One SCTP association is established between two SCTP endpoints (IPSPs), and in one association there can be more than one stream. The stream is used to guarantee the sequencing message transfer.

SCTP Association: The association is established between two IPSPs belong to different AS. For two ASs with n and k IPSPs respectively, there are at max n*k associations can be established between them.

Stream: it is used in SCTP to refer to a sequence of user messages that are to be delivered to the upper-layer protocol in order with respect to other messages within the same stream.

SLS: Signalling Link Selector. The logical link used by SCCP, for one SLS the message is transferred in sequence. The range of SLS is from 0 to 15.



Definitions Routing Key: A Routing Key describes a set of SS7 parameters and parameter

values that uniquely define the range of signaling traffic to be handled by a particular Application Server. The Signalling Point Code (SPC) is used as the routing key.

– The routing key is used to identify one IPS– One BSC has one routing key– From BSC view, one MSC has one routing key

– On the current implementation, the routing key used by BSC is the SS7 point code of the MSC server

NA: Network Appearance, it is a M3UA local reference shared by MSC Server and AS (typically an integer) that, together with an Signaling Point Code, uniquely identifies an SS7 node by indicating the specific SS7 network to which it belongs.

– The NA is used together with the routing key by BSC to identify the unique MSC server.

– It is configured by the operator– The NA of the MSC server should be same in BSC side



Connections between the BSC and MSC Servers BSC can be connected to more than one MSC and each MSC can have more

than one IPSPs. In BSC, for each MSC there is one separate IPSP, and all the IPSPs in BSC have same IP address and they are distinguished by different port number.

IPSP1

IPSP2

IPSP3

MSC 1

IPSPn

BSC Side MSC Side

IPSP2

IPSP1

BSC

MSC 2

A single SCTP Association A Set of SCTP Associations



A signaling over IP configuration

At the BSC, the following configuration should be provided for each MSC that will be connected:

Network Appearance: it is configured for each MSC server by the operator.

Routing Key: The routing key of the MSC server, on current BSC implementation it is the SS7 point code of the MSC server.

The number of the IPSP belongs to the MSC server.

The IP address and port number of each remote IPSP.

The redundancy mode of all the remote IPSPs.

As the BSC and MSC is a peer-to-peer mode, then the configuration for them is the same.



Support for Multi-Homing on MSC side The multi-homing is a way to increase the reliability of the Internet

connection for an IP network.

The SCTP is designed to establish robust communication associations between two endpoints, each of which may be reachable by more than one IP addresses.

Potentially different addresses may lead to different data paths between the two endpoints. Then the BSS should be able to accept that the MSC SCTP endpoint has more than one IP address.

For BSC side, it is accessible through different IP networks by one IP address, and two IP addresses are meaningless.



Support for Multi-Homing on MSC side One association may be established with two different paths, and only one

path is used to transfer the message in one time.

SCTP supervises both paths and it changes the path without association broken when the active path has a failure.

Example of multi-homing

IPSP in BSC

SCTP

M3UA

IPSP in MSC

SCTP

M3UA

IP Add1

IP Add2

Router1

Router2

VRRP

IP Network 1IP Network 1




Support for Multi-Homing from BSC For BSC, to support the multi-homing, only one IP address is used in BSC.

BSC is connected to two routers, and the two routers are working with VRRP (Virtual Router Redundancy Protocol).

BSC

Router 1

Router 2

SSW1

SSW2

VRRP

Gateway1

Gateway2 MSC

Server



Gateway1

Gateway2

Example of multi-homing



MxBSC SS7 Architecture In the BSC, the IP endpoints for A signalling over IP are managed by

the OMCP.


OMCP

SSW

CCP

IP Backbone

BSCA signalling over IP

MSC Server


MxBSC SS7 Architecture There are three corresponding modules for three N7 signalling transport

modes respectively. The SCCP module has the same interface with these three N7 modules.

TPOMCP

IP

SCTP

CCP

SCCP

BSSAP

M3UA

M3UA_LM

SCTP

M2UA

SLH_IP

MTP1

MTP2

SLH


A Signalling Over IP

impact: OMCP CPU load

increase, because the

M3UA and M3UA/SCTP

are located on the OMCP.


MxBSC SS7 Architecture Evolution of N7 subsystem:

In B11, all the N7 transport modes are supported, but only one mode is active at the same time.

A SignallingTransfer mode

Protocol Stack

N7 Endpoints

Comments

TDM/LSL MTP3, MTP2, MTP1

BSC and MSC

TS 16 is used for SS7.

TDM/HSL MTP3, MTP2, MTP1

BSC and MSC

One E1 link is dedicated to N7 signalling transfer.

A-ter in IP mode and A in TDM mode

M2UA, SCTP, IP MTP3, MTP2, MTP1

BSC, TC and MSC

The N7 signalling is transferred between BSC and TC over IP by M2UA/SCTP, and the transfer between TC and MSC is in TDM mode. The TC takes a role of signalling gateway. In this mode, the N7 link between TC and MSC can be LSL or HSL.

A Signalling Over IP

M3UA, SCTP, IP

BSC and MSC

The N7 signalling is transferred over IP by M3UA. The BSC is connected to MSC directly. TS16 can be used for traffic.




A Signaling over IP network architecture

Alcatel-Lucent implementation

The following dimensioning limits should be verified:

Parameter Value

Max MSC servers per BSS 16

Max SPC per MSC server for one

BSC 1

Max ASL per MSC server 4

Max ASL per BSC 64

Max IP addresses per SCTP endpoint 2

Max SCTP endpoints per MSC server 4

Notes: ASL = A Signalling Link, SPC - Signalling Point Code


2Feature activation & Compatibility with

previous HW


A SIGNALING OVER IP Feature Activation

The feature “A Signalling Over IP” is a commercially optional feature, and the A-signalling over TDM is still supported.

The cost is controlled by counting all the TRX from the BSCs where the feature will be activated.

TDM mode and IP mode are exclusive - A signaling will not working on TDM and IP in the same time.



The feature is activated at BSC level (per BSC), by setting the parameter EN_ASIG_OVER_IP equal to 1 (ENABLE).

The A signalling migration from TDM to IP or from IP to TDM may be encountered in two cases:

The BSC is already connected to a MSC server and the operator wants to change the BSS A signalling link transport.

The BSC is moved from a legacy MSC to a MSC server.



Migration

A signaling migration from TDM to IP

Requirements:

It is not required to keep calls during the operation

Rollback procedure must be available in case of problem detected

The configuration of the A signaling over IP is possible without impacting TDM traffic to reduce the outage duration at maximum. Only common parameters could not be changed in advance.

If LSL is used in the TDM mode, after changing it to IP mode, the TS16 used for SS7 in TDM mode should be used for traffic after changing the mode.



Returning to TDM mode, A signaling migration from IP to TDM.

The method is similar to the migration from TDM to IP.

For the N7 link mode (LSL/HSL) after changing the mode:

In case of roll-back, recover the previous N7 configuration LSL or HSL

In case of BSC installed from scratch in Asig over IP, go in N7 LSL



Activation prerequisites

The BSC and MSC server are in peer-to-peer mode. The MSC server will terminate the SS7 signaling instead of forwarding it to other SS7 signalling point. There is no other SS7 signalling point between BSC and MSC server.

One MSC server has only one signalling point code.

The A Signalling over IP is not working with the other A signalling transfer modes at the same time.

The A Signalling over IP can be used towards several MSC servers.

The IP address of both MSC and BSC is IPV4.

The MSC is added to BSC.

At least one ASL is added to MSC.



Activation process

Before activation

Declare a new MSC by giving the needed information regarding the MSC related parameters like: TRAFFIC_MODE, MSC_SPC, MSC_CN_ID, …

Create new ASL by giving the requested information regarding the ASL related address parameters like: LOCAL_ASIG_SCTP_ENDPOINT_IP_Address_1,

LOCAL_ASIG_SCTP_ENDPOINT_PORT, …

When activating A signalling over IP

It is necessary to set or change if already done the following parameters: START_TELECOM_IP_ADDRESS_BSC,

TELECOM_IP_SUBNET_MASK_BSC, and for the static route to declare: Dest-IP-Address, IP-Subnet-Mask, and Gateway-IP-Address.



Compatibility with previous HW generation

This feature is only supported on the BSC Evolution.

Restrictions & Limitations

The BTS G1 and G2, the MFS with AS800 are not supported in B11 and must be removed prior to the migration to B11.


3 Telecom Parameters, Counters, Indicators


Parameter

name

Definition Sub-

syste

m

Instan

ce

Category/

OMC-R

access

Type Range

/Default

value

EN_ASIG_

OVER_IP

Enables/disables the

support of "A

signalling over IP"

BSC BSC CAE/

changeabl

e

Flag 0: disable1: enable

LOCAL_ASI

G_SCTP_EN

DPOINT_IP_

Address_1

Local primary IP

adress of a SCTP

endpoint (used by

M3UA protocol) on

the BSC side.

BSC SCTP

EndPoin

t

CAE/

displayed

IP

addres

s

0-

4294967295

/ none

LOCAL_ASI

G_SCTP_EN

DPOINT_PO

RT

Local TCP port of a

SCTP endpoint (used

by M3UA protocol)

on the BSC side.

BSC SCTP

EndPoin

t

CAE/

displayed

Numbe

r

61953-

61999/none

These are new Parameters introduced by A Signaling over IP feature.

B11 - A SIGNALING OVER IPTelecom Parameters


Paramete

r name

Definition Sub-

syste

m

Instan

ce

Category/

OMC-R

access

Type Range

/Default

value

ASIG_SCT

P_ENDPOI

NT_LIST

List of the SCTP

endpoints (used by

M3UA protocol) on the

MSC side. Up to 4

endpoints can be

defined in that list.

BSC MSC CAE/ Set

Create &

Changeabl

e

List of

numbe

rs

0-

4294967295

/ none

MAX_NB_

ASIG_SCT

P_ENDPOI

NT

Maximum number of

SCTP endpoints

defined in the MSC

server that handle the

traffic with the BSS.

BSC MSC System/

DLS

numbe

r

4-4/4




Paramete

r name

Definition Sub-

syste

m

Instan

ce

Category/

OMC-R

access

Type Range

/Default

value

ASIG_SCT

P_ENDPOI

NT_IP_Add

ress_1

Primary IP adress of a

SCTP endpoint (used

by M3UA protocol) on

the MSC side.

BSC SCTP

EndPoin

t

CAE/

changeabl

e

IP

addres

s

0-4294967295/none

ASIG_SCT

P_ENDPOI

NT_IP_Add

ress_2

Secondary IP adress of aSCTP endpoint (used byM3UA protocol) on theMSC side. It is an optional addressused in case of SCTPmultihoming in MSC side.

BSC SCTP

EndPoin

t

CAE/

changeabl

e

IP

addres

s

0-4294967295/none




Paramete

r name

Definition Sub-

syste

m

Instan

ce

Category/

OMC-R

access

Type Range /

Default

value

ASIG_SCT

P_ENDPOI

NT_PORT

Port of a SCTP

endpoint (used by

M3UA protocol) on the

MSC side.

BSC SCTP

EndPoin

t

CAE/ Set

Create &

Changeabl

e

Number 0-65535/none

MIN_NB_

ACTIVE_

IPSP(MSC

)

The minimum number

of active IP server

process (IPSP) in the

MSC server required

to handle the traffic

with that MSC.

BSC MSC CAE/

changeabl

e

Number 1-4/1




Paramete

r name

Definition Sub-

syste

m

Instanc

e

Category/

OMC-R

access

Type Range

/Default

value

MSC_SPC Signalling Point Code of

a given MSC,

connected to the BSC.

BSC MSC CAE/ Set

Create &

Changeabl

e

Numbe

r

0- 16383/

none

TRAFFIC_

MODE

Traffic mode of the MSC server: 0 (override), 1 (broadcast), or 2 (load sharing).

BSC MSC CAE/

changeabl

e

Numbe

r

0-2/0

MSC_NAM

E*

Friendly Name of MSC

server. A MSC Name

identifies uniquely a

MSC within a BSC.

OMC CNE CAE/

changeabl

e

String 0 to 15

characters



* This Parameter is not present in BTP.


These are new Counters introduced by A Signaling over IP feature.

Referenc

e

Long name Definition Type Measured

object

MC1101 NB_ASPUP_TX Number of the message ASPUP

sent out from BSC to MSC

110 MSC_BSC

MC1102 NB_ASPUP_RX Number of the message ASPUP

received from the MSC to BSC

110 MSC_BSC

MC1103 NB_ASPDOWN_TX Number of the message ASPDOWN

sent from BSC to MSC

110 MSC_BSC

MC1104 NB_ASPDOWN_RX Number of the message ASPDOWN

received from the MSC to BSC

110 MSC_BSC

MC1105 NB_ASPACTIVE_T

X

Number of the message

ASPACTIVE sent from BSC to MSC

110 MSC_BSC

MC1106 NB_ASPACTIVE_R

X


ASPACTIVE received from MSC to

BSC

110 MSC_BSC

MC1107 NB_ASPIACTIVE_

TX


ASPINACTIVE sent from BSC to

MSC

110 MSC_BSC

B11 - A SIGNALING OVER IPTelecom Counters



Referenc

e

Long name Definition Type Measur

ed

object

MC1108 NB_ASPIACTIVE_

RX


ASPINACTIVE received from MSC to

BSC

110 MSC_BS

C

MC1109 NB_BSC_SENT_SS7

_

IP_BYTES_ASIG_IP

Counts the number of bytes of the

SS7 flow sent by a BSC to the MSC

(MSC-CS) when A signaling over IP is

used.

110 MSC_BS

C


_

IP_PACKETS_ASIG_

IP

Counts the number of SCTP packets

sent by a BSC to a given MSC for the

SS7 flow when A signaling over IP is

used. It corresponds to is the number

of SCTP segments sent, counted by

the SCTP stack.

110 MSC_BS

C




Referenc

e


ed

object

MC1111 NB_BSC_RESENT_S

S7_IP_PACKETS_ASI

G_IP

Counts the number of SCTP packets resent by a BSC to a given MSC for the SS7 flow, when A signaling over IP is used.

110 MSC_BS

C


_IP_BYTES_MAX_M

N_ASIG_IP

Counts the max number of bytes of the SS7 flow sent by a BSC to a given MSC in one minute during the granularity period of monitoring, when A signaling over IP is used.

110 MSC_BS

C

MC1113a NB_N7_CON_EST_F

AIL_DUE_NSS_ASIG

_IP

Number of BSS originating SCCP connection failures due to the NSS, when A signaling over IP is used.

110 MSC_BS

C

MC1113b NB_N7_CON_EST_F

AIL_DUE_BSS_Asig_

IP

Number of BSS originating SCCP connection failures due to the BSS, when A signaling over IP is used.

110 MSC_BS

C




Referenc

e


ed

object

MC1114 NB_N7_UNIT_DA

TA_SENT_ASIG_IP

Number of connectionless Unit Data

messages class 0 sent to the MSC,

when A signaling over IP is used.

110 MSC_BS

C

MC1115 NB_N7_UNIT_DA

TA_REC_ASIG_IP

Number of connectionless Unit Data

messages class 0 received from the

MSC, when A signaling over IP is used.

110 MSC_BS

C

MC1116 NB_N7_CON_REQ

_ SENT_ASIG_IP

Number of CONNECTION REQUEST

sent to the MSC by the BSC, when A

signaling over IP is used.

110 MSC_BS

C

MC1117 NB_N7_CON_REQ

_REC_ASIG_IP

Number of CONNECTION REQUEST

received from the MSC by the BSC,


110 MSC_BS

C




Referenc

e


ed

object

MC1118 NB_N7_CON_CO

NF_SENT_ASIG_I

P

Number of CONNECTION CONFIRM



110 MSC_BS

C

MC1119 NB_N7_CON_CO

NF_REC_ASIG_IP

Number of CONNECTION CONFIRM

sent from the MSC by the BSC, when A


110 MSC_BS

C

MC1120 NB_N7_CON_REF

_ SENT_ASIG_IP

Number of CONNECTION REFUSED



110 MSC_BS

C

MC1121 NB_N7_CON_REF

_ REC_ASIG_IP

Number of CONNECTION REFUSED

received from the MSC by the BSC,


110 MSC_BS

C



New Counters explained


BSC

MC110

1

Nb ASPUPMessages sent

MSC

MC110

2

Nb ASPUPMessages received

MC110

3

Nb ASPDOWNMessages sent

MC110

4

Nb ASPDOWNMessages received

MC110

5

Nb ASPACTIVEMessages sent

MC110

6

Nb ASPACTIVEMessages received

MC110

7

Nb ASPINACTIVEMessages sent

MC110

8

Nb ASPINACTIVEMessages received

State CommentsASP-DOWN It is a state when the SCTP

association has not been established or the remote peer IPSP is not available.

ASP-INACTIVE

The SCTP association and the remote peer IPSP(ASP) are available, but the IPSP(ASP) is not ready to transfer the payload data message.

ASP-ACTIVE The payload data message can be transferred by the IPSP(ASP).




BSC

MC110

9

Nb SS7 bytessent

MSC

MC111

0

Nb SS7 packetssent

MC111

1

Nb SS7 packetsresent

MC111

2

Max Nb SS7 bytessent per minute

MC111

4

Nb N7 UnitData sent

MC111

5

Nb N7 UnitData received




BSC

MC111

6

Nb N7 ConnectionRequest sent

MSC

MC111

7

Nb N7 ConnectionRequest received

MC111

8

Nb N7 ConnectionConfirm sent

MC111

9

Nb N7 ConnectionConfirm received

MC112

0

Nb N7 ConnectionRefused sent

MC112

1

Nb N7 ConnectionRefused received

MC1113

a

Nb N7 Connection EstablishFail due to NSS

MC1113

b

Nb N7 Connection EstablishFail due to BSS


These are new N7 Alarms introduced by A Signaling over IP feature.

Refname

Event TypeProbable Cause

Description

[35, 4] ASL-REP

Communication

Communication Subsystem Failure

This alarm is reported whenever one SCTP

association is broken or established.

[35, 5] RMH-REP

Communication


This alarm is for the feature Multi-Homing

and it is only reported for the ASL that has

the remote endpoint with 2 IP addresses. It

is reported whenever one of the IP

addresses status is changed while the SCTP

association status keep in traffic.

[35, 6] MSC-REP

Communication


This alarm is reported when there is no IT

ASL or less than n IT ASL for load-sharing

mode.

B11 - A SIGNALING OVER IPTelecom Alarms


This N7 Alarm has been changed due to A Signaling over IP feature.

Refname

Event TypeProbable Cause

Description

[35, 3] INC-REP

Communication

Response Time Excessive

An incident report is generated whenever

the BSC receives a message with either a

DPC, OPC or an SSF label part different

from the expected one. It is also generated

when on changeover/changeback, too

many MSUs are received from other DTCs.

Excessive incident report generation is

avoided by limiting the number of reports

per unit time. Infrequent software error.

Note: This alarm can be produced at a

maximum of once an hour.

B11 - A SIGNALING OVER IPTelecom Alarms

In A Signaling Over IP, this alarm is used to indicate when one MSU is received

with unexpected DPC or OPC.


These are new NPO Indicators introduced by A Signaling over IP feature.

B11 - A SIGNALING OVER IPTelecom Indicators

Refname Long Name Description Formula

GIPABSSASUPN

IP_A_BSC_Sent _ASPUP

Number of ASPUP messages sent by the BSC to any MSC MC1101

GIPABSRASUPN

IP_A_BSC_Received_ ASPUP

Number of ASPUP messages received by the BSC from a given MSC MC1102

GIPABSSASDWN

IP_A_BSC_Sent_ ASPDOWN

Number of ASPDOWN messages sent by the BSC to any MSC MC1103

GIPABSRASDWN

IP_A_BSC_Received_ ASPDOWN

Number of ASPDOWN messages received by the BSC from a given MSC MC1104

GIPABSSASACN

IP_A_BSC_Sent_ ASPACTIVE

Number of ASPACTIVE messages sent by the BSC to any MSC MC1105

GIPABSRASACN

IP_A_BSC_Received_ ASPACTIVE

Number of ASPACTIVE messages received by the BSC from a given MSC MC1106





GIPABSSASIACNIP_A_BSC_Sent_ASPINACTIVE

Number of ASPINACTIVE messages sent by the BSC to any MSC MC1107

GIPABSRASIACN

IP_A_BSC_ Received_ ASPINACTIVE

Number of ASPINACTIVE messages received by the BSC from a given MSC MC1108

GIPABSMCSSBYN

IP_A_BSC_MSC_SS7_Bytes

Number of bytes of the SS7 flow sent by a BSC to the MSC (MSC-CS) when A signaling over IP is used. MC1109

GIPABSMCSSPKN

IP_A_BSC_MSC_SS7_Packets

Number of SCTP packets sent by a BSC to a given MSC for the SS7 flow when A signaling over IP is used. It corresponds to is the number of SCTP segments sent, counted by the SCTP stack. MC1110





GIPABSMCSSPKRN

IP_A_BSC_MSC_SS7_Packets_Resent

Number of SCTP packets resent by a BSC to a given MSC for the SS7 flow, when A signaling over IP is used. MC1111

GIPABSMCSSBYMN

IP_A_BSC_MSC_SS7_Bytes_Max

Maximum number of bytes of the SS7 flow sent by a BSC to a given MSC in one minute during the granularity period of monitoring, when A signaling over IP is used. MC1112

GIPABSNSFLNIP_A_BSC_NSS_Fail

Number of BSS originating SCCP connection failures due to the NSS, when A signaling over IP is used.

MC1113a

GIPABSBSFLNIP_A_BSC_BSS_Fail

Number of BSS originating SCCP connection failures due to the BSS, when A signaling over IP is used.

MC1113b





GIPABSSUDM0NIP_A_BSC_Sent_Unit_data_Message_Class_0

Number of connectionless Unit Data messages class 0 sent to the MSC, when A signaling over IP is used. MC1114

GIPABSRUDM0N

IP_A_BSC_Received_ Unit_data_Message_Class_0

Number of connectionless Unit Data messages class 0 received from the MSC, when A signaling over IP is used. MC1115

GIPABSSCNRQNIP_A_BSC_Sent_Connection_Request

Number of CONNECTION REQUEST sent to the MSC by the BSC, when A signaling over IP is used. MC1116

GIPABSRCNRQNIP_A_BSC_Received_Connection_Request

Number of CONNECTION REQUEST received from the MSC by the BSC, when A signaling over IP is used. MC1117





GIPABSSCNCNFN

IP_A_BSC_Sent_ Connection_ Confirm

Number of CONNECTION CONFIRM sent to the MSC by the BSC, when A signaling over IP is used. MC1118

GIPABSRCNCNFN

IP_A_BSC_ Received_ Connection_ Confirm

Number of CONNECTION CONFIRM received from the MSC by the BSC, when A signaling over IP is used. MC1119

GIPABSSCNRFN

IP_A_BSC_Sent_ Connection_ Refused

Number of CONNECTION REFUSED sent to the MSC by the BSC, when A signaling over IP is used. MC1120

GIPABSRCNRFN

IP_A_BSC_ Received_ Connection_ Refused

Number of CONNECTION REFUSED received from the MSC by the BSC, when A signaling over IP is used. MC1121


This are new NPO Indicators introduced by A Signaling over IP feature.



GIPABSMCSSBYP

KN

IP_A_BSC_MSC_ SS7_Bytes_per_ Packet_avg

Average number of bytes per packet of the SS7 flow sent by a BSC to the MSC (MSC-CS) when A signalling over IP is used.

MC1109 / MC1110

GIPABSBSFLOIP_A_BSC_BSS_Fail_Ratio

Ratio of BSS originating SCCP connection failures due to the BSS, when A signaling over IP is used.

MC1113b / (MC1113a + MC1113b)

GIPABSSECNFN

IP_A_BSC_Estab_Connection_Failure

Number of BSC connection requests failures.

MC1116 - (MC1119 + MC1121)

GIPABSNSBSFLNIP_A_BSC_NSS_BSS_Fail

Number of BSS originating SCCP connection failures due to the NSS and BSS, when A signaling over IP is used.

MC1113a + MC1113b





GIPABSNSBSFL

R

IP_A_BSC_NSS_BSS_Fail_Rate

Rate of BSS originating SCCP connection failures due to the BSS and NSS, when A signaling over IP is used.

(MC1113a + MC1113b) / (MC1118 + MC1119)

GIPABSNSBSSC

R

IP_A_BSC_NSS_BSS_Success_Rate

Rate of BSS originating SCCP connection successes due to the BSS and NSS, when A signaling over IP is used.

1 - (MC1113a + MC1113b) / (MC1118 + MC1119)

GIPABSNSFLOIP_A_BSC_NSS_Fail_Ratio

Ratio of BSS originating SCCP connection failures due to the NSS, when A signaling over IP is used.

MC1113a / (MC1113a + MC1113b)

GIPABSTCNCNF

N

IP_A_BSC_Total_Connection_Confirm

Number of CONNECTION CONFIRM sent to the MSC by the BSC and received from the MSC by the BSC, when A signaling over IP is used.

MC1118 + MC1119





GIPABSTCNRFN

IP_A_BSC_Total_Connection_Refused

Number of CONNECTION REFUSED sent to the MSC by the BSC and received from the MSC by the BSC, when A signaling over IP is used.

MC1120 + MC1121

GIPABSTCNRQN

IP_A_BSC_Total_Connection_Request

Number of CONNECTION REQUEST sent to the MSC by the BSC and received from the MSC by the BSC, when A signaling over IP is used.

MC1116 + MC1117

GIPAECNFN

IP_A_Estab_Connection_Failure

Total of connection requests failures.

MC1116 - (MC1119 + MC1121) + MC1117 - (MC1118 + MC1120)

GIPABSRECNFN

IP_A_MSC_Estab_Connection_Failure

Number of MSC connection requests failures.

MC1117 - (MC1118 + MC1120)


These are new NPO LASER Indicators introduced by A Signaling over IP feature.



ASL_REP_Alarm_ Count

ASL_REP_Alarm_Count

Count of ASL REP active alarms

NZ(ALARM_COUNT_REC('SPECIFICPROBLEM LIKE '%_[35]%_[4]%''))

INC_REP_Alarm_ Count INC_REP_Alarm_Count

Count of INC REP active alarms


MSC_REP_Alarm_ Count

MSC_REP_Alarm_Count

Count of MSC REP active alarms


RMH_REP_Alarm_ Count

RMH_REP_Alarm_Count

Count of RMH REP active alarms




This is a new NPO Report introduced for A Signaling over IP feature: Alc_Mono_A_sig_o_IP

Report Properties


4 Feature Impact on Tools


The following tools will be impacted by A Signaling over IP feature:

• NPO (New 110 Counters, Parameters, Indicators, Reports and LASER)

• Smart MCT (New Parameters)

• AMT.NET (New Network Configuration)

• AnaQoS (New Indicators)

• SQM (New Indicators)

B11 - A SIGNALING OVER IPImpact on Tools


B11 - A SIGNALING OVER IP Impact on Tools


5 Test Strategy


B11 - A SIGNALING OVER IPTest Strategy

Overview

The test strategy is intended to follow A signalling over IP feature impact on CS services.

Test scenarios

Case 1: Asig over IP without A-flex activation:

Single CS pool area case

It is possible to be tested only in 1 BSC + 1 MSC server configuration.

Note: If the BSC is connected to more then 1 MSC server, the Aflex must be also activated (see case 2).



Test scenarios

Case 2: Asig over IP with A-flex activation:

2.1. The minimal configuration for Asig over IP testing with A-flex activation:

Single CS pool area case

1 BSC + 2 MSC servers configuration

Area 1

BSC 1

CS pool-area

MSC 2

MSC 1

Configuration with single CS pool area



Test scenarios


2.2. Configuration for Asig over IP testing with CS two pool areas:

2 adjacent CS pool areas case

2 BSC needed: 1 BSC inside each pool area, so at least 4 MSC servers

Area 1

BSC 1

CS pool-area 1

MSC 2

MSC 1

Area 2

BSC 2

CS pool-area 2

MSC 4

MSC 3

•Configuration with two adjacent CS pool areas



Test scenarios


2.2. Configuration for Asig over IP testing with CS two pool areas:

2 overlapping CS pool areas case

3 BSC needed: 1 BSC inside each pool area and 1 BSC common for both pool areas, so at least 4 MSC servers.

MSC 2

MSC 1

Area 1 Area 2 Area 3

BSC 3

BSC 2

BSC 1

CS pool-area 2

CS pool-area 1

MSC 4

MSC 3

•Configuration with two overlapping CS pool areas



Test plan

The test plan is organized around the following aspects:

Parameters settings

Functional unitary testsThe aim is to check the basic procedures related to CS services. These tests have to be performed using dedicated mobile stations and dedicated tools in static and mobility conditions.

Location Update procedure

MO call & MT call

HO, intra BSC and inter BSC

Call release procedure

Assign failure procedure

Ciphering procedure

Voice quality tests



Statistical testsThe aim is to check that there is no QoS degradation due to the change of SS7 signaling transport mode from TDM to IP.

In depth QoS analysis with focus on:– General QoS follow-up for non regression– Ater-Mux CS QoS follow-up– SS7 stability and availability follow-up– Ater-Mux CS stability and availability follow-up

BSC Stability

Note: Statistical tests for A signaling over IP feature can be performed to assess simultaneously A-flex feature, since the last one can work only together with A signaling over IP.


The test plan should verify that the activation of the feature allows to have: A lower signalling transfer delay

Higher signalling transfer bandwidth

Test the Network performance with all the 3 traffic mode types

The GSM KPIs keep stable

The Network’s stability keeps stable

The test plan is based on the following NPO Reports:

• Alc_Mono_A_sig_over_IP

• Alc_Mono_Call

• OPERATIONAL (LASER Report)

• STABILITY (LASER Report)




The test list

Test Reference Test Name Aim of the tests

Test 1

(B11_ASIGOVERIP_1)

Functional unitary

testsAllow to check the basic procedures

related to CS services

Test 2

(B11_ASIGOVERIP_2)

CS Signaling follow-up

Allow to check availability of N7

signaling

Test 3

(B11_ASIGOVERIP_3)BSC stability Allow to verify the BSC stability

Test 4

(B11_ASIGOVERIP_4)

Non regression of

global QoS

Allow to check global QoS non-

regression



Type of tests: Unitary (static and mobility) and Statistical (NPO).

Type of analysis: QoS and stability.

Required tools: NPO, OMC-R, AMT.NET and Smart MCT

Estimated duration of the tests: 2 Weeks (1 Reference + 1 Observation)

+1 Week for Post-processing and generate the report


6Reference documentation


─ SFD: A Signaling Over IP (3BK 10204 0101 DTZZA)

─ DN: A Signaling Over IP (3BK 11206 0895 DSZZA)

─ Modify N7 Transport Mode for BSC Evolution (3BK 17438 1024 RJZZA)

B11 - A SIGNALING OVER IPReference documentation


7Annex


B11 - A SIGNALING OVER IPAnnex

MxBSCAS (IPS)

MSC 1AS (IPS)

IPSPSCTP

endpoint

IPSPSCTP

endpointIPSPSCTP

endpoint

ASL

ASL

IPSPSCTP

endpoint

MSC 2AS (IPS)

IPSPSCTP

endpointIPSPSCTP

endpoint

ASL

ASL

MSC_SPCMSC_SPC

LOCAL_ASIG_SCTP_ENDPOINT_IP_Address_1 LOCAL_ASIG_SCTP_ENDPOINT_IP_Address_1

LOCAL_ASIG_SCTP_ENDPOINT_PORT LOCAL_ASIG_SCTP_ENDPOINT_PORT

ASIG_SCTP_ENDPOINT_LIST ASIG_SCTP_ENDPOINT_LIST

ASIG_SCTP_ENDPOINT_IP_Address_2 ASIG_SCTP_ENDPOINT_IP_Address_2


ASIG_SCTP_ENDPOINT_PORT ASIG_SCTP_ENDPOINT_PORT

MIN_NB_ACTIVE_IPSP MIN_NB_ACTIVE_IPSP

TRAFFIC_MODE TRAFFIC_MODE

MAX_NB_ASIG_SCTP_ENDPOINT* MAX_NB_ASIG_SCTP_ENDPOINT* Not

changeable(= 4)

Up to 4 SCTP endpoints per MSC

Up to 4 ASLs per MSC

Up to 64 ASLs per BSC

Up to 16 MSC servers per BSC

Two IPSP have same IP address

but different port numbers

Asig over IP functionality

Parameter Settings Only 1 SPC per MSC



MxBSCAS (IPS)

MSC 1AS (IPS)

IPSPSCTP

endpoint

IPSPSCTP

endpointIPSPSCTP

endpoint

ASL

ASL

IPSPSCTP

endpoint

MSC 2AS (IPS)

IPSPSCTP

endpointIPSPSCTP

endpoint

ASL

ASL

MSC_SPCMSC_SPC

LOCAL_ASIG_SCTP_ENDPOINT_IP_Address_1 LOCAL_ASIG_SCTP_ENDPOINT_IP_Address_1

LOCAL_ASIG_SCTP_ENDPOINT_PORT LOCAL_ASIG_SCTP_ENDPOINT_PORT







MSC_SPCMSC_SPC







EN_ASIG_OVER_IPEN_ASIG_OVER_IP

Optional address used in

case of multihoming

Two IPSP have same address but different port numbers


Activation

MAX_NB_ASIG_SCTP_ENDPOINT* MAX_NB_ASIG_SCTP_ENDPOINT*

MAX_NB_ASIG_SCTP_ENDPOINT* MAX_NB_ASIG_SCTP_ENDPOINT*

Up to 4 SCTP endpoints

per list (MSC)




Configurations The ASP/IPSP active procedure depends on the network configuration.

From the BSS point view, for each MSC, there is one separated IPSP in one BSS.

For the MSC side, there are two possible cases:

• Only one IPSP in one MSC• More than one IPSP in one MSC

MxBSCAS (IPS)

MSC 1AS (IPS)

IPSPSCTP

endpoint

IPSPSCTP

endpointIPSPSCTP

endpoint

IPSPSCTP

endpoint

MSC 2AS (IPS)

IPSPSCTP

endpoint




Configurations The Traffic mode at MSC side can be:

– override mode (ie only one of the IPSPs handle the traffic) – broadcast mode (ie all the active IPSPs receive the same messages)– load sharing mode (ie the traffic is distributed over all the active IPSPs)

MxBSCAS (IPS)

MSC 1AS (IPS)

IPSPSCTP

endpoint

IPSPSCTP

endpointIPSPSCTP

endpoint

IPSPSCTP

endpoint

MSC 2AS (IPS)

IPSPSCTP

endpoint

The different MSCs may have different traffic mode and redundancy scheme.



MxBSCAS (IPS)

MSC 1AS (IPS)

IPSPSCTP

endpoint

IPSPSCTP

endpoint

IPSPSCTP

endpoint

MSC with only one IPSP

In this case there is no difference for the three traffic modes. It is better to use the Override mode.


Configurations, Traffic mode and Redundancy



MxBSCAS (IPS)

MSC 1AS (IPS)

IPSPSCTP

endpoint

IPSPSCTP

endpoint

IPSPSCTP

endpoint

MSC with more than one IPSP

Config. 1+1: there are two IPSPs for the AS in the active/standby mode. In this case, the traffic mode Override should be applied.

Config. n+k: there are more than 1 IPSP for the AS, where ‘n’ is the minimum IPSPs required to handle the traffic, and the ‘k’ IPSPs can be either active or inactive. The traffic mode Load-Sharing is used for this case.


Configurations, Traffic mode and Redundancy

IPSPSCTP

endpoint


Abbreviations

SCCP = Signalling Connection Control Part M3UA = MTP3 User Adaptation Layer (RFC4666) SCTP = Stream Control Transmission Protocol (RFC 2960) SIGTRAN = SIGnalling TRANsport SG = Signalling gateway AS = Application server (RFC4666) ASP = Application server process (RFC4666) IPS = IP Server IPSP = IP Server Process (RFC4666) ASL = A Signalling Link



www.alcatel-lucent.comwww.alcatel-lucent.com

[Seminar5]_AsigOverIP

Documents

Transcript of [Seminar5]_AsigOverIP