Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Configuring the CST for a Standalone Server


For a standalone server, the CST is in local memory, and is configured with the dbclusterlocal.gen file when you run the configuration script. The dbclusterlocal.gen file is a small file consisting of a [Bootstrap] section that includes LibraryName = dbclusterlocal and Enable=1.

In addition, the setting of the PersistSessions parameter in the radius.ini file determines whether sessions are restored or not restored when SBR Carrier is restarted. The default and recommended settings for a standalone server are:

This configuration enables the CST in local memory and saves session information in a local file on SBRC so that the information is available after the server restarts.

You cannot configure field names in the local CST (dbclusterlocal.gen). However, there are three predefined fields and seven generic fields you can configure using the sessionTable.ini file. The three predefined fields are:

  • WimaxSessionId

  • AcctMultiSessionId

  • FunkOuterUserName

The seven generic fields are:

  • Generic1

  • Generic2

  • Generic3

  • Generic4

  • Generic5

  • Generic6

  • Generic7

In order to use any of the ten predefined fields, they must be mapped to attributes by editing the sessionTable.ini file.

Configuring the sessionTable.ini file

Configuring the sessionTable.ini file

The sessionTable.ini file allows you to take any attribute in a request and store it in the CST. To configure the seven generic fields in the standalone CST, you use RadAttr fields. RadAttr fields are designed to capture data from RADIUS packet attributes. You must be knowledgeable about RADIUS attributes, how they are used in the network, and which attributes to incorporate into the CST.

Valid Radius-Attribute-Names occur in Steel-Belted Radius Carrier dictionary files, as embodied in the SBR Carrier internal master dictionary (which includes attributes defined in files having .dct, .dcm, .dci, and .dcx extensions in the SBR Carrier installation root directory). For information about SBR Carrier dictionaries, refer to the readme.dct and dictiona.dcm files.


RadAttr Fields and the sessionTable.ini File

RadAttr Fields and the sessionTable.ini File

RADIUS attributes can be generated by Steel-Belted Radius Carrier at four capture points, events that apply only to RadAttr fields:

  • [AuthRequest]

  • [AuthResponse]

  • [AcctRequest]

  • [AcctResponse]

Each RadAttr CST field requires at least one capture point to identify when RADIUS attributes are loaded in the field. Specify one or more capture-points by placing the field entry in one or more of the four capture point sections of the sessionTable.ini file.

One Radius-Attribute-Name can be captured multiple times, at different capture-points, by using multiple (different) RadAttrFieldNames, all of which are mapped to the same Radius-Attribute-Name.

If a RADIUS attribute is not present when a session’s RADIUS packet is scanned at a capture point event, the corresponding CST field is not updated. If the specified attribute does not occur in a packet at any capture point, the session displays a null value in the CST field.

If a session experiences multiple occurrences of packets at the same capture-point carrying the same Radius-Attribute-Name, the values of subsequent occurrences overwrite the values of preceding occurrences in the RadAttrFieldName field. For example, if a session receives multiple Accounting-Start packets, then the AcctRequest and AcctResponse capture-points are exercised more than once for that session, with the result that the captured Radius-Attribute-Name/ RadAddrFieldnames are updated multiple times. Thus, the CST always reflects the most recent values from each capture-point.

Creating RadAttr Field-to-Attribute Mappings

The sessionTable.ini file maps RadAttrFieldName RadAttr CST fields to Radius-Attribute-Name RADIUS attributes:

RadAttrFieldName = Radius-Attribute-Name

Defining RadAttr Fields

To define a RadAttr field, edit the sessionTable.ini file.

Add the RadAttrFieldName = Radius-Attribute-Name field-to-attribute mapping line to the sessionTable.ini file in the appropriate capture point section or in several sections.

For example:

Multi-Valued Attributes

Multi-Valued Attributes

The sessionTable.ini file supports a special syntax to support multi-valued attributes. The RADIUS protocol permits certain attributes to be multi-valued, meaning that two or more instances of the attribute can occur in a single RADIUS packet. System fields in the CST always involve single-valued attributes. RadAttr fields in the CST can be single-valued or multi-valued.

For RadAttr fields in the CST, we support multi-valued attributes with the six MVA facilities defined in the list that follows. Any field-to-attribute mapping (in sessionTable.ini) can have its Radius-Attribute-Name optionally appended with one (but no more than one) multi-valued attribute @ extension.


The MVA-Count extension stores the count (0, 1, or more) of attributes of the specified Radius-Attribute-Name (occurring in the RADIUS packet being scanned at the specified capture-point).



The MVA-Index extension stores the value of the Nth attribute (where N is equal to or greater than 1) of the Radius-Attribute-Name occurring in the RADIUS packet being scanned at the specified capture-point. For example, @1 means to store the first value of the specified Radius-Attribute-Name. If the packet carries fewer than N attributes of the designated type, a value of null is stored.

In this case, N is a 1-based, not 0-based, integer. Thus, N denotes a positive number in the range 1–2038, expressed in standard base-10 notation. Specifying a value for N outside this range is an error.



The MVA-First extension stores the first value of the Radius-Attribute-Name attribute occurring in the RADIUS packet being scanned at the specified capture-point. MVA-First extension is synonymous with the Radius-Attribute-Name@1 extension.



The MVA-Last extension stores the last value of the Radius-Attribute-Name attribute occurring in the RADIUS packet being scanned at the specified capture-point.



The MVA-CharString-Concat extension treats the potentially multiple values of Radius-Attribute-Name as text strings. It concatenates them using the specified string “…”, as a field delimiter between successive values.

The value of the delimiter string cannot contain the 2-character sequence @” (at-sign/double-quote) or internal NULL characters. The delimiter string can consist of any arbitrary (single-byte) characters, such as comma, colon, space, tab, and new line characters. This facility supports C/C++-language backslash-escaping (meta character) conventions. For example, to include a backslash character in a delimiter string or in a character data-value, enter it as: \\.



The MVA-ByteString-Concat extension treats the potentially multiple values of Radius-Attribute-Name as byte strings. It concatenates them using a length and value representation: every value is represented by a one-byte length header that identifies the length of the data value in the range 1–253 and is followed by the data value. The concatenation terminates with a one-byte 0-value trailer that indicates a data of length 0, such as the end of the concatenated byte-string.


Using MVA Facilities

Using MVA Facilities

The syntax of the MVA facilities supports single-valued attributes and multi-valued attributes. For single-valued attributes, @1, @^, @$, and no-@-extension returns the value of the attribute. The @"…" and @* extensions return one item in the concatenation; no delimiter appears for @"…", while the 0-byte terminator immediately follows the first item in the list for @*.

Any field-to-attribute mapping in sessionTable.ini (whether its Radius-Attribute-Name is single-valued or multi-valued) that does not contain an MVA @ extension is considered to be equivalent to the same field-to-attribute mapping with an @^ extension appended to it.

In both the @"…" and the @* cases, the individual values in the MVA are listed in the order they occur in the RADIUS packet. According to the RADIUS protocol, attribute sequence is significant.