[NSN] NodeB reporting AAL TYPE 2 RESET FAILED

[pUbLIS]

Hi all

Does anyone knows why a NSN nodeB reports the alarm "AAL TYPE 2 RESET FAILED"?
I've been connected to the site for a while now, and I've seen that for some reason, every now and then the cells go inactive, the site re-integrates the RAN, the TRS (FTEB) get it's comissioning, and all the cells get active again.... all of this without me loosing the conectivity to the site.
The DCR is thru the roof (of course) and when I query for an alarm history, among some other alarms, the one I see the most is the "AAL TYPE 2 RESET FAILED".

Cheers

[pUbLIS]

Anyone? Nothing?... :confused:

[safoot]

Hi Dear,
Actually in our network this alarm always appears on sites having a problem in the transmission links (PDH and SDH) also for transmission fluctuations, sometimes this alarm appears as well when the transmission timers are not synchronized with the radio timers causing the UE to send the REQ more to make an RRC Connection before recieving an ACK, in my case this needs tuning of a transmission parameter called the CDVT.

[cococrunch]

Hi Dear,
Actually in our network this alarm always appears on sites having a problem in the transmission links (PDH and SDH) also for transmission fluctuations, sometimes this alarm appears as well when the transmission timers are not synchronized with the radio timers causing the UE to send the REQ more to make an RRC Connection before recieving an ACK, in my case this needs tuning of a transmission parameter called the CDVT.

I would really appreciate if you could enlighten us more about this.. Thanks.. :)

[pUbLIS]

CDVT: Cell Delay Variation Tolerance

Cell Delay Variation Tolerance (CDVT) is a QoS parameter in ATM network for managing traffic that is specified when a connection is set up. In CBR transmissions, CDVT determines the level of jitter that is tolerable for the data samples taken by the PCR.

None the less... the CDVT are all the same for every node on the network, and the config stays the same but for some other reason, the node stops reporting that alarm.
It should be something else... rather then config parameters

[Kirill Kucherov]

Hi All!

Restore the topic.
I'm facing the same alarm. However, have more detailed diagnostics and some ideas.

Case:
An alarm became appearing regularly after ATM Iub of NodeB has been modified to the following configuraion:
VC_1, CBR, DCH+Str, PCR = N cps,
VC_2, CBR, DCH+Str.bi level, PCR = M cps,
VC_3, UBR, HSPA, Str.+Str.bi level + Tolerant, PCR = N+M
Dynamic Scheduling for NRT DCH (and for HSDPA) with Path Selection are activated (as consequence, AF for NRT DCH became 0,7)
Sometimes, this alarm coexists with RRC connection setup failure due to transmission, sometimes does not.

Assume, that ToAW (Time of arrival window) might be set larger in order to prevent transport channel synchronization procedure and thus RLC retransmission.
Is CDVT and ToAW have similar purpose? Can it be helpful to increase CDVT to solve the problem?

Has anybody faced the same problem and what sollution is possible? If increasing ToAW, by which value?

Thanks in advance!