AAL2 Congestion

[icebreaker05]

Hi Experts,

I'm still learning the transport part of UMTS. I'm still a newbie that is why I'm asking for expert advices.
I have encountered this KPI on the PMR of the moshell. And I have found this values which has congestion.



56) RNC Q.Aal2 Setup Performance (Aal2Ap)


Object
Aal2Congestion
Aal2SetupFail
NoAal2SetupAttempts


b252
1.84
2.88
2604






Could someone make an expert judgement and analysis on how to solve the congestion. What are the related parameters I need to look at.

BR,
ice

[senjamir]

Hi,

I dont know it this is already posted here in the forum but you may check this site http://www.scribd.com/doc/57893609/18/Congestion-on-Iub-per-AAL2-Path

You will see some explanations and counter description. :)

Hope this can help

Br,
Sen

[icebreaker05]

Hi,

I dont know it this is already posted here in the forum but you may check this site http://www.scribd.com/doc/57893609/18/Congestion-on-Iub-per-AAL2-Path

You will see some explanations and counter description. :)

Hope this can help

Br,
Sen


Thanks.. what do you think we can increase to remove the congestion. The document doesn't provide any suggestions.

[kaizzer545]

Have you try to verify if there are some errors/second over your Tx ?

[icebreaker05]

I have tried it but the cells having Es/Ses are not the one's having the congestion. For the AAL2 failures, yes they where the one's having TX Es. I'm having congestion on ClassA-CS12 only not in Class C. Is there any parameter related to this?

[dadoba]

Hello,

Check in Node B the counters in the MO Aal2Ap
pmUnSuccInConnsLocalQosClassA
pmUnSuccInConnsLocalQosClassB
pmUnSuccInConnsLocalQosClassC
pmUnSuccInConnsLocalQosClassD

Check in RNC the counters in the MO Aal2Ap
pmUnSuccOutConnsLocalQosClassA
pmUnSuccOutConnsLocalQosClassB
pmUnSuccOutConnsLocalQosClassC
pmUnSuccOutConnsLocalQosClassD

A - CS + Signaling
B - PS R99
C - HS and EUL
D - Normally Not Used

All common channels and CS Speech, CS Data and CS Streaming services are recommended to be configured with AAL2QoS class A.
Best Effort packet services on DCH for Interactive and Background are recommended to be configured with AAL2QoS class B.
The high speed data services, EUL and HSDPA, are best effort services and are recommended to be configured with AAL2QoS class C.

If you have some of them different than 0 you have a problem.

Note that each service consume CIDs from each Class but all B and C services consume CIDs from Class A, because all of them uses Class A for signaling, that explain you only see Class A congestion.

Normally this type of congestion will reduce you RAB CS and HSDPA accessibility or just one of them and after adm fails.

1) Check if your problem is not related to the Iub bandwidth. Node -> pmr -> IubDataStreams -> Check IubHsLimitingRatio, if you have 0 ok if not you can have not sufficient bandwidth or a TX bottleneck problem.

If not...

2) If you are having this problem just in Class A try to reduce some Eul Users and check by pmxh if the counters are reducing.

3) If you are having problems in Class A and C you will have to duplicate VCs, when you duplicate VCs you gain more CIDs with the same bandwidth and can solve this problem, after that if the problem continues a suggest you to change this Iub for IP.


Normally you will just duplicate VCs for Class A and C, for B you can but is not usual unless you have a high PS R99 traffic in your network.

When you have Iub ATM problems you can:

1) Temporally reduce Eul Users to reduce just Class A congestion or in some cases block this service until VC expansion.
(This action will just take effect in Class A congestion and is just temporally)
2) Resquest 2nd VC expansion for Class A and C, B just if you have congestion or high PS R99 traffic.
3) If the action above not bring effects you must change your Iub for IP with the necessary bandwidth.
4) Check if your Iub bandwidth is enough.

I hope it can help you, give REP if useful...

[mout94]

Hi Icebreaker05,

I have doc about congestion, maybe you will find what you are looking for on it. file attached.

Don(t forget reputation plz2960929608

[icebreaker05]

Hello,

Check in Node B the counters in the MO Aal2Ap
pmUnSuccInConnsLocalQosClassA
pmUnSuccInConnsLocalQosClassB
pmUnSuccInConnsLocalQosClassC
pmUnSuccInConnsLocalQosClassD

Check in RNC the counters in the MO Aal2Ap
pmUnSuccOutConnsLocalQosClassA
pmUnSuccOutConnsLocalQosClassB
pmUnSuccOutConnsLocalQosClassC
pmUnSuccOutConnsLocalQosClassD

A - CS + Signaling
B - PS R99
C - HS and EUL
D - Normally Not Used

All common channels and CS Speech, CS Data and CS Streaming services are recommended to be configured with AAL2QoS class A.
Best Effort packet services on DCH for Interactive and Background are recommended to be configured with AAL2QoS class B.
The high speed data services, EUL and HSDPA, are best effort services and are recommended to be configured with AAL2QoS class C.

If you have some of them different than 0 you have a problem.

Note that each service consume CIDs from each Class but all B and C services consume CIDs from Class A, because all of them uses Class A for signaling, that explain you only see Class A congestion.

Normally this type of congestion will reduce you RAB CS and HSDPA accessibility or just one of them and after adm fails.

1) Check if your problem is not related to the Iub bandwidth. Node -> pmr -> IubDataStreams -> Check IubHsLimitingRatio, if you have 0 ok if not you can have not sufficient bandwidth or a TX bottleneck problem.

If not...

2) If you are having this problem just in Class A try to reduce some Eul Users and check by pmxh if the counters are reducing.

3) If you are having problems in Class A and C you will have to duplicate VCs, when you duplicate VCs you gain more CIDs with the same bandwidth and can solve this problem, after that if the problem continues a suggest you to change this Iub for IP.


Normally you will just duplicate VCs for Class A and C, for B you can but is not usual unless you have a high PS R99 traffic in your network.

When you have Iub ATM problems you can:

1) Temporally reduce Eul Users to reduce just Class A congestion or in some cases block this service until VC expansion.
(This action will just take effect in Class A congestion and is just temporally)
2) Resquest 2nd VC expansion for Class A and C, B just if you have congestion or high PS R99 traffic.
3) If the action above not bring effects you must change your Iub for IP with the necessary bandwidth.
4) Check if your Iub bandwidth is enough.

I hope it can help you, give REP if useful...



On your suggestion #1. How the number of EUL users configured can reduce Class A congestion. I have 4 E1's on site, numEULusers is 8 per cell. How can I get the EUL utilization in this case.

Thanks and hope for your reply.

[gprastomo]

Im not familiar to e///, but try to check the CID (connection id), the atm has maximum number of connection per VC, then if you have this rejection, try to add VC for User plane or control plane

[dadoba]

4 E1's is not a problem, it doesn't matter. Your 4 E1's give you 8 Mbps bandwidth and the question here is not bandwidth, but you can check it using another counters. The question here is CID Utilization as our friend said. Eul uses 2 Class A CIDs + 1 Class C CID, then you probably having problems in Class A and it is affecting signaling which affects all you Node-B and/or RNC counters and performance. The remedy for it is reduce some Eul Users or disable Eul after that create a second VC por Class A and second VC por Class C, this way you double the CID capacity with the same bandwidth. If you are having values different from 0 in pmr -> IubDataStreams -> Check IubHsLimitingRatio (Normally in Spi03) consider IUB change for IP or add more E1's, but is necessary create second VCs if you choose add more E1's to avoid problems with CID usage.

[icebreaker05]

4 E1's is not a problem, it doesn't matter. Your 4 E1's give you 8 Mbps bandwidth and the question here is not bandwidth, but you can check it using another counters. The question here is CID Utilization as our friend said. Eul uses 2 Class A CIDs + 1 Class C CID, then you probably having problems in Class A and it is affecting signaling which affects all you Node-B and/or RNC counters and performance. The remedy for it is reduce some Eul Users or disable Eul after that create a second VC por Class A and second VC por Class C, this way you double the CID capacity with the same bandwidth. If you are having values different from 0 in pmr -> IubDataStreams -> Check IubHsLimitingRatio (Normally in Spi03) consider IUB change for IP or add more E1's, but is necessary create second VCs if you choose add more E1's to avoid problems with CID usage.

Hi dadoba,

Thanks for the input. But two points,
1. I have a node converted already to IP and maxhsrate set to 319, but still pmcapIubHslimitingratioSPI03 is pegging some values other than 0. The data traffic on the node is not high but still having congestion.
2. Could you share with me E/// counters that gives me CID utilization, this will give me a proof of creating a second VC for classA and Class C CID.

Thanks for your response..

BR,
ice

[consultant]

The best way to check AAl2 utilization is an moshell script located into moshell\commonjars\scripts\
just run from moshell, all details about AAl2 usage will see
run moshell\commonjars\scripts\aal2_path_usage.mos

regards

[jskhalid]

Hi , Are the same counter applicable for Node B with IP backhaul?

BR

[Armena]

AAL2 resources availability in RNC (M800) RNC_602a
AAL2 resource reservation success rate [%] :

The transport resource request success ratio [%] KPI describes the average success rate of the transport resource reservation attempts for all AAL2 type connections

AAL2_SUCCEEDED - AAL2 signaling requests which have been successfully executed in A2SP

AAL2_REJECTED - AAL2 signaling requests which have failed for any reason. E.g. signaling failed or uplink CAC reject
RES_EXT_CAP - Transport resources requests which are rejected by downlink CAC since there is not enough capacity in the external AAL2 path.

RES_INT_CAP - Resource reservations which are rejected by downlink CAC since there are no RNC-internal AAL2 processing resources available

RES_OTHER - Resource reservations which have failed for any other reason than CAC or signaling (for example route analysis, parameter or DSP resource allocation problem)

[striker]

AAL2 resources availability in RNC (M800) RNC_602a
AAL2 resource reservation success rate [%] :

The transport resource request success ratio [%] KPI describes the average success rate of the transport resource reservation attempts for all AAL2 type connections

AAL2_SUCCEEDED - AAL2 signaling requests which have been successfully executed in A2SP

AAL2_REJECTED - AAL2 signaling requests which have failed for any reason. E.g. signaling failed or uplink CAC reject
RES_EXT_CAP - Transport resources requests which are rejected by downlink CAC since there is not enough capacity in the external AAL2 path.

RES_INT_CAP - Resource reservations which are rejected by downlink CAC since there are no RNC-internal AAL2 processing resources available

RES_OTHER - Resource reservations which have failed for any other reason than CAC or signaling (for example route analysis, parameter or DSP resource allocation problem)



Hi all,

how can we solve pmEdchIubLimitingRatio ? is there a setting for these to solve this issue?