MEMORANDUM

Ref.: BSR/MF/2009/12/04 Alcatel Lucent

Date: 04/12/2008

Pages: (cover page included)

From: Marc Freynet 

marc.freynet@Alcatel-lucent.fr


To:

Europe

CONFIDENTIAL

OBJECT: Dimensioning of the new IPC architecture

1 Target

This memo presents a dimensioning of the new IPC architecture. This memo is
based on the BSR traffic model as defined in CPlane_Traffic_Calculator_Ver1.4.xls
as well as the new IPC architecture document

The IPC team provided a CPU consumption measurement for CS originated and
terminated load test based on the current architecture where SSCP, SCTP, SCCP
and ASN1 decoding (RAB assignment) run on the same processor.

We can assume that the weight in term of CPU consumption of the different
telecom scenario in the IPC depend on the number of processed messages. This
is obviously a rough estimation as some messages may be more CPU consuming
in the IPC (RAB assignment for example) than other.

The measured CPU consumption provides a refined measurement per task (i.e.
per protocol layer). We can then extrapolate the CPU consumption in the new
proposed design where SSCP+SCTP and running in 2 boards and SCCP+ASN1
decoding are running a separated set of boards. This is again a rough estimation
as the current inter protocol CPU estimation (between processes) is less CPU
consuming than the targeted inter protocol CPU estimation (between boards).

For the time being we ca assume that the weight of a given scenario is
proportional to the number of UL and DL RANAP and ALCAP messages crossing
the IPC. Based on the number of messages in each scenario and based on the
traffic mix we can estimate the proportion of CS MOC and MOT compared to the
full traffic mix traffic.
As described in the document 78317 – Capacity Specification, the IPC target is 4
clusters. Each cluster has 64000 Fentos.

2 IPC in the Network

This drawing shows the position of the IPC as well as (for example) the number of
RANAP messages for a Home Voice 64000 Fento cluster.

Messages Per Second per Cluster: Home-Voice Busy Hour

RANAP RANAP
1158 1158
IPC MSC
1164 1164
RANAP BSGAP DPAT RANAP BSGAP RANAP RANAP
1953 150 329 1953 150
Cluster Femtos Brick IP Sec BSG
1985 149 345 1985 149 RANAP
RANAP BSGAP DPAT RANAP BSGAP 795
SGSN
821
RANAP

In the new architecture the IPC terminates also the SGSN traffic.

3 Traffic model as defined in CPlane_Traffic_Calculator_Ver1.4.xl

3.1 Number of BHCA

Fentos per Cluster 64000

Erl per user 50mErl

Home_Femto_Mean_number_of_UEs_camping_on_a_BSR 2

Home_Femto_Number_of_mobile_originated_CS_voice_calls_in_the_busy_hour CS 0,9
per user/per busy hour per UE
Home_Femto_Number_of_mobile_terminated_CS_voice_calls_in_the_busy_hour CS 0,9
Procedures per user/per busy hour per UE

The traffic model represents for the IPC:

64000 Fentos * 2 user * (0.9 MOC + 0.9 MOT) = 230400 = 230 K BHCA.

64000 Fentos * 2 user * 50 mErl = 6400 Erl.

The target for the new IPC is to support 4 clusters.

3.2 Telecom Scenario weight

This table is a direct copy of the Procedure Calculations sheet in the traffic model.

Uplink RANAP Downlink RANAP Number Establish Number of

messages per messages per AAL2 per user per Release AAL2 per
user per second user per second second (home user per second
(home Femto) (home Femto) Femto) (home Femto)
CS MOC and MOT Voice Call 0,004415 0,003915 0,000500 0,000500
Other CS scenario 0,004061 0,004603 0,000001 0,000001
CS Totals 0,008476 0,008518 0,000501 0,000501

PS Totals 0,006958 0,007190

HO BSR -> Macro Network 0,000139 0,000139

Sum 0,015573 0,015847 0,000501 0,000501

The traffic model presents two traffic mix:

A) Home Voice where CS counts for 1 and PS counts for 0.85.
B) Home Data where CS counts for 0.85 and PS counts for 1

We based this memo on Home Voice traffic mix has it is puts more stress on the
IPC.

So for Home Voice, the number of PS messages is multiplied by 0.85 .

The number of ALCAP messages is multiplied by 2 as each AAL2 Establish
message is associated to a Confirm message.

Uplink RANAP Downlink RANAP Number Number of

messages per messages per Establish+Confirm Release+Confirm
user per second user per second AAL2 per user per AAL2 per user per
(home Femto) (home Femto) second (home second (home
Femto) Femto)

CS MOC and MOT Voice Call 0,004415 0,003915 0,001000 0,001000

Other CS scenario 0,004061 0,004603 0,000001 0,000001
CS Totals 0,008476 0,008518 0,001001 0,001001

PS Totals * Voice to Data 0,005915 0,006112

Coefficient
HO BSR -> Macro Network 0,000139 0,000139

Sum 0,014530 0,014769 0,001001 0,001001

We can represent those numbers of messages by a ratio on the total number of

messages.

Uplink RANAP Downlink RANAP Number Number of Sum

messages per messages per Establish+Confirm Release+Confirm
user per second user per second AAL2 per user per AAL2 per user per
(home Femto) (home Femto) second (home second (home
Femto) Femto)

CS MOC and MOT Voice Call 14,105% 12,508% 3,195% 3,195% 33,00%
Other CS scenario 12,975% 14,706% 0,004% 0,004% 27,69%
CS Totals 27,080% 27,214% 54,29%

PS Totals * Voice to Data 18,896% 19,526% 38,42%

Coefficient
HO BSR -> Macro Network 0,444% 0,444% 0,89%

Sum 46,42% 47,18% 3,20% 3,20% 100,00%

To summarize, we can estimate that the CS Mobile originated and Mobile
terminated Voice call telecom scenario represent 33% of the CPU power
consumption in the IPC.

4 Current IPC 2.1 CPU consumption

4.1 Measured data

The IPC team used the simulator (8610) to load the IPC.
The simulator creates simultaneous Voice MOC and MOT connection and release.
The simulator holds the established call for a few second (2sec or 10sec).
The simulator counts the number of call established and from then computes the
BHCA of the test.

In the latest test, 800 Terminal Test is run and each call has a hold time of 2 sec.
The PO generated in IPC is around 51% and the BHCA is 441K.

Validation:

3600 sec
800 Erl *  441K BHCA  X signaling time  4.5 sec
 2 sec X signaling time 

We have 800 UE doing establishment and release. If the call are hold during 2
seconds and the establishment and release of each call takes 4.5 seconds then
we reach the 441K BHCA.

The 4.5 seconds for establishment and release looks big but it suspect that with
only 2 seconds of holding time, the simulator itself may be under CPU load and
may not be able to really hold the established call for only 2 seconds. This is not
an issue as we are only interested by the number of call established in one hour
(BHCA) and the CPU load on the IPC.

The standard hold time with the simulator is normally 10 seconds. The IPC team
down the holding time to 2 seconds to create more stress on the IPC and to get
some better average CPU consumption in the IPC task per task.

4.2 Extrapolation

The one cluster (64000 Fento) target traffic model is 230 K BHCA.

The measured IPC CPU is 51% of CPU load for 441 K BHCA.

The target traffic model for voice MOC and MOT will then consume:
230 K BHCA
51% *  27%
441K BHCA

The Voice MOC and MOT traffic model represents only 33% of the over all telecom
scenario CPU load.

The target traffic model for all traffic scenarios will then consume:
 230 K BHCA 100%
51% * *  81%
441K BHCA 33%

To summarize, 1 cluster (64000 fento) produces 230 K BHCA and 6400 Erl should
consume 81% of CPU in the IPC.

The queuing theory shows that when the load of a CPU reaches 60%, the average
waiting time in 2.1 times the average processing time.
We should dimension our system to have an average maxim load of 60% of CPU.

A 60% of IPC CPU as target represents:

60%
a) 64000 Fento *  47640 Femto
81%
60%
b) 6400 Erl *  4764 Erl
81%
60%
c) 230 K BHCA *  171 KBHCA
81%

Those theatrically values are more or less in line with the real load test performed
in Nuremberg:
Cluster size 50k:
Erlang: 5000 (50 mErlang/subscriber * 2 subscribers per Femto * 50k Femto)
BHCA: 230k ((voice 1,8 + supplementary services 0,5 per subscriber) * 2 * 50k)
For IPC we have proven the BHCA value already (in fact we came up to 248k
BHCA), however as you know we are still working on the Erlang value.

To conclude the current IPC CPU control capacity is around (may be a bit less)
50000 Fento and 5000 Erl.

5 Target for IPC 2.3 CPU consumption

5.1 IPC CPU per task in 2.1

The following table shows per task the CPU consumption

NAME PRI Total Ticks IPC 2.1
tShell0 2 0% 1
uAssertTask 11 0% 63
uPlaneTask 25 Outgoing: NONE. Incoming: GRE and SCTP Adaptors 0% 0 0%
tNetTask 30 0% 53 0%
uEtherTask 33 0% 13
uPlatMEvc 50 Outgoing: NONE. Incoming: STC.1/ALCAP-PE/ALCAP NF 2% 603 2%

tTelnetOut_a 55 0% 65
uCiccTask 60 0% 7
tSpyTask 81 8% 2121
bcmCNTR.0 150 0% 6
tCGDriverTas 150 Outgoing: ControlGateway/ALCAP-NF/ALCAP-PE/STC.1. 9% 2512 9%
Incoming: ControlGateway
VWSS_TMRTSK 150 0% 1
tSccp 150 Outgoing: SCCP. Incoming: SCCP 14% 3580 14%
tQsaal 150 Outgoing: SSCOP/A5/GRE. Incoming: SSCOP 7% 2027 7%
tIpTrans 150 Outgoing: M3UA/SCTP/SCTP-Adaptor. Incoming: SCTP/M3UA 14% 3603 14%
tAtmTrans 150 Outgoing: MTP3/Q.2140. Incoming: MTP3/Q.2140 6% 1607 6%
cpTask 160 0% 7
uGreNPSanity 200 0% 84
u_stdout_rea 207 0% 24
u_plat_log 210 0% 17
t_load_low 255 Tpu_load_m ? 32% 8328
KERNEL 0 3% 847
TOTAL 0 95% 25569 52%

The gray column (IPC 2.1) lists the tasks that depend on the traffic. The sum is
52%. This is (I guess) where the 51% of CPU usage given by the IPC team comes
from.

Question: What is this t_load_low.

5.2 IPC CPU per task in 2.3

The following tables show the probable CPU usage in 2.3 for the SS7 Link
processor and the SIGTRAN Link processor.

NAME PRI IPC 2.3 SS7 IPC 2.3 SIGTRAN

Link Proc Link Proc
tShell0 2
uAssertTask 11
uPlaneTask 25 Outgoing: NONE. Incoming: GRE and SCTP Adaptors 0%
tNetTask 30 0% 0%
uEtherTask 33 0% 0%
uPlatMEvc 50 Outgoing: NONE. Incoming: STC.1/ALCAP-PE/ALCAP NF 2%

tTelnetOut_a 55
uCiccTask 60
tSpyTask 81
bcmCNTR.0 150
tCGDriverTas 150 Outgoing: ControlGateway/ALCAP-NF/ALCAP-PE/STC.1. 9%
Incoming: ControlGateway
VWSS_TMRTSK 150
tSccp 150 Outgoing: SCCP. Incoming: SCCP 14%
tQsaal 150 Outgoing: SSCOP/A5/GRE. Incoming: SSCOP 7%
tIpTrans 150 Outgoing: M3UA/SCTP/SCTP-Adaptor. Incoming: SCTP/M3UA 14%
tAtmTrans 150 Outgoing: MTP3/Q.2140. Incoming: MTP3/Q.2140 6%
cpTask 160
uGreNPSanity 200
u_stdout_rea 207
u_plat_log 210
t_load_low 255 Tpu_load_m ? ? ?
KERNEL 0
TOTAL 0 27% 25%

Those numbers show that half (27%) is used by the link side and the other half
(25%) by UE context side.

In 2.1 with 1 board be can process around 50000 Femto.

So it is seems difficult to handle 4 Clusters with only 2 SS7 Line board.

6 Conclusion

The current IPC 2.1 is probably able to support a bit less than 50000 Fento.
It looks difficult in the new IPC 2.3 proposal to support 4 clusters with only 2 SS7
Line board.