Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


How Attribute-Based Concurrency Works


To support attribute-based concurrency on all SBR Carrier servers in a cluster, the Sbr_UserConcurrency table in the cluster’s SSR database contains fields for specified attributes in addition to the default user ID and the current count of sessions for each specified attribute. The Sbr_UserConcurrency table is created automatically when you run the script on each management node to create the database.


Concurrency limits (quotas) are enforced during authentication. If the SBR Carrier server is being used as an accounting-only node, user concurrency limits are not enforced.

When an Access-Request is received, the user is authenticated and an ID consisting of an authentication method prefix, a hyphen, and a username or attribute is created in the table. Each specified attribute is tracked in other columns.

The ID and attribute(s) are used to look up the count of open sessions in the table. If this number exceeds the number of sessions allowed, as determined either by native user configuration, LDAP/SQL lookup, or Funk VSA in the Access-Request, the request is rejected. Otherwise, the count is incremented and an Access-Accept is sent.

When an Accounting-Stop is received, the count is decremented. The Class attribute sent in the Access-Accept must be returned in the Accounting-Request so that the user can be matched with the ID in the table for user session counts.

The administrative script decrements the Count fields as required. For more details about the script, see