Session State Register Database Tables
The database cluster uses a relational SQL design to store data. The database contains multiple tables that store Steel-Belted Radius Carrier state information such as IP address pool information and current sessions.
IP Address Pools
Session State Register stores information about all IP address pools centrally in a dedicated table in the SSR database. Network Access Servers can send RADIUS requests to any stateless SBR Carrier server, and the SBR Carrier server allocates IP addresses from the shared central pool in response, after authentication.
Operators can query from any SSR management node to verify what addresses are in use and how many addresses remain available for an IP address pool or set of pools.
Subscriber Session Data Controls
Session State Register stores session data centrally in the Current Sessions Table in the SSR database.
The table's format is controlled by a configuration file on the cluster's management nodes; one file is copied to all nodes in a node group, so all nodes operate with the same information. The standard Session State Register database schema addresses the needs of most carriers, but you can modify the CST to address unique needs and situations. The CurrentSessions.sql file determines the schema used by the CST table maintained by the data nodes. When the database is created, the table is set up using the schema outlined in the CurrentSessions.sql file.
Session control features include:
- User concurrency control — you can enforce concurrency across your entire network by controlling the number of active connections on a per-user, per-cluster basis using the user name. You can set a limit on the maximum number of concurrent connections that a user can have and you may use any configured attribute to track instead of just the user name.
Subsequently, when the user requests a new connection, the Steel-Belted Radius Carrier servers in the cluster compare the current number of connections to the maximum limit. If a new connection exceeds the limit, the additional connection can be disallowed, or allowed and logged.
- Optional attribute-based concurrency control — If you have a license for the SSR Optional Concurrency and Wholesale Module, you can enforce concurrency across the network by tracking any attribute of a user account, not just the user name.
- Change of Authorization (CoA)/Disconnect Message (DM) processing — you can change the state of authenticated sessions dynamically. In accordance with the Dynamic Authentication RFC 3576, you can:
- Deploy prepaid scenarios in WLAN integration for GSM/UMTS networks.
- Place users in legal intercept.
- Enable online service and billing profile changes.
- Disconnect or quarantine users for abusing the network.
Related Topics
- Chapter 36, "Introduction to Managing and Controlling Sessions in SBR Carrier" on page 573
- Chapter 39, "Using the Command Line Utility to Manage and Control Sessions" on page 599
Application Support
Because the CST is centrally located and can be easily modified, it is often used as the entry point for third party applications that need current session data. This enables Steel-Belted Radius Carrier Session State Register to be the logical source for other applications to query for correlative and verification purposes.
A calling application can make its request through an API as SBR Carrier does, or with a SQL query as shown in Figure 195. The SQL query usually takes more processing resources and cycles to complete than an API call, so we recommend against allowing multiple or repeated queries because they can slow down the cluster's primary tasks.
Rows in each table are evenly distributed among a node group's data nodes. A client application can locate a particular record by accessing the unique primary key of any table, which only involves a single node in the cluster. Scans of tables for records meeting broader criteria (such as a search for sessions more than two hours old) involves all the data nodes in the primary node group, and would take more processing cycles to complete. We recommend that queries from outside applications be as precise as possible to avoid slowing all operations down.
Figure 195 shows the general deployment scenario with usage examples. Communications initiated by applications or systems in the operational support system (OSS) can be formatted as standard SQL queries, shell scripts, or stored procedures, depending on usage requirements.
For example, a video gateway might use its own internal identifier (such as an MSISDN, IMSI, or username) for a subscriber, but might not have the subscriber's current IP address. The video gateway could query the Current Sessions Table in real time to retrieve information about an active session.
