Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

Understanding SBRC Call Models

A call model, also known as a session call model, is a logical description of the flow of information on the control plane of a carrier system, each part of which is termed a “leg” of the flow. It includes items such as authentication and authorization, service activation and provisioning, call and device control, and termination.

When you plan the sizing and expected performance of an SBRC as a system of systems, a key aspect to determine beforehand is the impact of the call models on the expected SBRC operation, that is, the scope and shape of the normal level of SBRC traffic.

Carriers often use the widely established call models, such as the reference models from networking working groups (such as 3G, WiMAX, and LTE) and modify them for their customer base to model their specific range of services. A subscriber base is often broken down into several key call models with subscribers (current and future), who either have or are expected to have certain classes of service, and statistically operate within identifiable patterns of system utilization. These call models and patterns of system utilization are further decomposed into the work that SBRC front-end applications and back ends (external DB, downstream proxies, and SSR) must do. This is usually done with the help of technical experts armed with existing data and statistics from the carrier or operator in consultation with the Juniper Network’s sales engineering force or value-added reseller. These often consult with Juniper Networks’ product engineering team for the latest information and to seek possible ways to optimize a specific use case.

An actionable set of call models and statistical information can include information like the following:

  • 6 million total subscribers
  • 2 million xDSL device address authentications, always on with an interim period of 4 hours and reauthentication period of 24 hours (+/- 1 hour), randomly occurring throughout the day
  • 1.3 million fixed always-on WiMAX Device TLS with an interim period of 1 hour
  • 30 percent of 500,000 subscribers, simultaneously using roaming WiMAX TTLS, each with:
    • An expected CPS of 3 per day with an interim period of 10 minutes
    • An expected regular peak of 200 CSPS for 20 minutes (at 9:00 a.m., 12:00 p.m., and 5:30 p.m.)
    • A tolerable absolute peak of 2000 CSPS during certain external events (for example, earthquakes or the Superbowl)
  • Each GGSN supports 250,000 subscribers, which will reauthenticate at a limited rate of 2500 CSPS on restart; as well as attempt to support 2 GGSN simultaneous restarts, load balanced across both NOCs in normal operation, on a best-effort basis
  • 100,000 heavy use commercial roaming WiMAX users with:
    • An expected CSPS of 1 per hour owing to cell movement
    • An interim period of 10 minutes
    • A peak of 800 CSPS (between 7:00 a.m. and 7:30 a.m.)
    • 35 percent simultaneous dormant subscribers
  • 1000 foreign agent SPSs from recognized Wi-Fi relationships
  • IP not assigned from the SSR and no concurrency checking

From the above, breaking the information into the respective use cases, you can measure the limits of CPS or CSPS that the system might simultaneously be called to do. You can derive the requirements for a system in terms of SSR hits, required SSR sharding (or splitting up the subscriber base over multiple SSRs), the amount of CPU power in GHz required, and SBRC front-end applications required to support the system that would need to be in each of the two NOCs, either of which might be required to handle the entire load in a failure condition.

After a thumbnail analysis of the above, you can see that scaling for authentication proves to be strongly related to the peak WiMAX rates (CPU intensive) on the front-end applications, and further closely related to the number of interims flowing through the system, up to the limits of SSR hits-per-second that one SSR can support.

There are multiple ways to optimize the system based on the performance results for specific hardware (see Hardware Used for more information). In addition to optimizing the behavior of SBRC, you need to consider such possibilities as decreasing the interim and fixed reauthentication periods to significantly reduce the background load on the SSR to permit a wider bandwidth to support GGSN resets, or limiting spikiness through the use of flood queues and lengthening retry semantics. To maintain the expected security level, you can use a non-default cipher suite, smaller prime number generation for temporary Diffie-Hellman Ephemeral (DHE) Encryption keys, or a smaller TLS server certificate with more frequent certificate updates.

Modified: 2017-03-07