No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


Not all tariff-level were applyed for subscriber because RADIUS low perfomance

Publication Date:  2012-07-27 Views:  132 Downloads:  0

Issue Description

Sustomer meet following problem:
Sometimes for subscribers don’t apply VAS policy, sometimes subscriber applies policy but tariff-levels apply only 3 instead of 5.

Alarm Information


Handling Process

As described by the customer, five tariff-levels are configured, but only three tariff-levels are used for most users after they go online. Suppose a DAA user is configured with five tariff-levels. The user sends six accounting requests, one is the general request (master session) and the other five correspond to the each of the five tariff-levels. If the configuration is as follows:
[me60-2]disp accounting-scheme yosh

Accounting-scheme-name : yosh
Accounting-method : radius
Realtime-accounting-switch : enabled
Realtime-accounting-interval(sec) : 1800
Start-accounting-fail-policy : offline //the user is logged out because the accounting fails.
Realtime-accounting-fail-policy : online
Realtime-accounting-send-update : no
Realtime-accounting-failure-retries : 3

Then, when the first accounting request arrives at the radius server, the radius server does not respond in time because of the limited capability. Therefore, start-accounting fails and the user cannot go online. If the radius server does not recover before the accounting request corresponding to a certain tariff-level arrives, this tariff-level will not be generated. So, if RADIUS server is not respond to master-session accounting packets, user can't go online. If RADIUS server can respond on master-session accounting packets, but can't respong for any sub-session accounting request, corresponding tariff-level will not activated. The reason why only three of the configured tariff-levels are found is that the radius server fails to respond to the accounting requests corresponding to the other two tariff-levels, and thus the two tariff-levels are not generated.

The log generated at that time is as follows:
disp logbuffer
Logging buffer configuration and contents:enabled
Allowed max buffer size : 1024
Actual buffer size : 512
Channel number : 4 , channel name : logbuffer
Dropped messages : 0
Overwritten messages : 2653234
Current messages : 512

Apr 18 2008 05:25:50 me60-2 %%01vsm/4/rd_normalacct_stafail(l): normal accounting for me60-201200dsg090720c0e92005527 failed to be started, please check radius accounting server.

The accounting session id's followed by dsg are the id's of the accounting requests corresponding to tariff-levels defined for the value-added service. If the radius fails to respond to an accounting request, the corresponding tariff-level does not take effect for the user.


Root Cause

I have check information for some test subscriber's. Log info is in attachment.

Both users apply same VAS:
value-added-service policy jet daa
accounting-scheme yosh
tariff-level 1 qos-profile car8m
tariff-level 2 qos-profile car8m
tariff-level 3 qos-profile car8m
tariff-level 5 qos-profile car8m
tariff-level 6 qos-profile car8m


Improve the capability of the radius server.
Modify the configuration to make the me60 keep users online when start-accounting fails so that the value-added service can take effect.
The modification to the configuration does not affect the operation of the customer because the me60 still sends accounting packets to the radius server in real time. The modification to the configuration of the me60 is important because radius servers in many sites have insufficient capabilities, which causes inconsistency between configured tariff-levels and actual tariff-levels.