Tasks
Before regulatory DPI requirements were introduced, the operator used in-house traffic management tools based on FreeBSD and standard Unix utilities. These solutions covered basic needs at an early stage of network development, when large-scale Wi-Fi user identification and centralized subscriber management were not yet required.
The situation changed with the introduction of DPI and traffic filtering requirements. The operator required a scalable, carrier-grade solution. After evaluating the market, the Stingray platform from VAS Experts was selected.
The cooperation began in 2014 and marked the transition to centralized network management.
Initial Stingray Deployment
At the initial stage, Stingray was used as a DPI platform to meet regulatory requirements. The system also provided traffic classification, analytics, and basic protection capabilities, including DDoS protection.
Initially, traffic was processed on a dedicated DPI node, but over time the operator gradually began using additional platform capabilities.
Migration to software BNG and integration with Hydra Billing
Subscriber authentication was originally implemented using hardware Cisco BNG solutions with PPTP and L2TP tunneling protocols.
As the subscriber base grew, this architecture became a limiting factor: a single device supported approximately 1,500 sessions, had limited throughput, and did not scale well. As a result, the infrastructure could no longer handle the increasing number of connections or traffic growth.
After BNG functionality was introduced in Stingray, the operator gradually migrated subscriber authentication to the new architecture, starting with individual network segments and later expanding it across the entire network.
Integration with the Hydra Billing system was required for full deployment and took approximately three years. API-based logic was implemented for authentication, subscriber accounting, and tariff management. Most of the development work was performed on the operator side, after which the system was deployed into production.
As a result, Stingray became deeply integrated with the billing system and is now used in key scenarios: IPoE authentication, tariff management, CG-NAT, and Wi-Fi identification.
CG-NAT usage
CG-NAT is also implemented within Stingray and is used for subscriber traffic processing. In the early stages of operation, performance limitations under high load occasionally required service restarts.
With the release of version 13, CG-NAT stability was significantly improved, and no operational issues have been observed since. The system is currently operating in stable production mode.
Traffic prioritization and management
Within Stingray operations, the operator used traffic prioritization mechanisms. For example, ICMP traffic was assigned to a separate service class, which reduced support requests from enterprise customers. Traffic shaping policies were also applied to torrent traffic on uplink channels.
As total traffic volumes grew to approximately 70 Gbit/s, prioritization on backbone links was disabled due to increased CPU load. However, subscriber-level prioritization is still in use.
Scaling and performance
Since deployment, the operator has progressively scaled the Stingray platform, moving from a base configuration to a BNG 240-level solution. The architecture is centralized: all subscriber traffic passes through a single DPI node. Scaling is performed vertically by increasing server compute resources.
The system is deployed on an AMD server with 128 cores, of which up to 120 are utilized after optimization. Traffic growth was driven both by organic subscriber expansion and by the acquisition of additional providers. Significant traffic increases were observed during periods of higher demand for fixed broadband services.
Regulatory infrastructure constraints also remained a limiting factor; some bottlenecks were resolved after equipment modernization.In newer Stingray releases (14.x line), traffic processing efficiency was improved, reducing the impact of peak loads. In the future, the operator expects the introduction of a load balancer to enable horizontal scaling.
Deployment of Wi-Fi Hotspot from VAS Experts
Wi-Fi identification systems began development in 2014. Initially, SMS-based authentication was used, but it proved economically inefficient due to high messaging costs.
The operator then switched to authentication via outgoing user calls. The solution was implemented using a combination of billing systems, a web server, and Cisco network equipment, and was used for several years. After migration to Hydra, the Wi-Fi identification system required modernization. Cloud-based solutions were excluded due to dependency on external services and potential instability under regulatory traffic filtering conditions.
As a result, a local deployment based on Stingray Wi-Fi Hotspot was selected. During implementation, the authentication logic had to be modified: instead of a standard code-based model, a user-initiated outgoing call scheme was used.
Additional complexity arose from Android and iOS captive portal behavior, including handling the transition to a phone call and returning the user to the browser after authentication.
At the start of deployment, several iterations were required to adapt the module to the new workflow. Additional tasks included UI customization (branding, logos, advertising elements). Most issues were resolved iteratively in collaboration with the development team. Although configuration is performed via a GUI, the interface was new to the operator’s team, which required adaptation of internal processes.
In the current configuration, Wi-Fi Hotspot operates stably and is used in parallel with the previous system.
Current service metrics
- Approximately 3,000 new authentications are recorded per day
- More than 5,000 Wi-Fi connections are recorded daily, of which approximately 3,000 are processed through Stingray
- Authentication is stored on the device for up to 2 weeks; therefore, re-authentication is not always required
- After authentication, users can connect from any location within the coverage area without repeating the login procedure
The operator considers Wi-Fi identification a competitive advantage and provides it free of charge as part of its service offering.
Development plans
The operator plans further infrastructure and functional development based on Stingray. Key priorities include vertical scaling of the platform to support continued subscriber growth and expansion of IPoE authentication capabilities with deeper integration into the billing system.
Special attention is given to the development of the local Wi-Fi Hotspot. It is important not only to ensure stable service operation but also to simplify its management. In particular, more flexible captive portal customization is required, with the ability to quickly change design, add logos and advertising elements, and edit HTML pages without developer involvement.
Another direction is analytics expansion. The operator requires reports on connections at different access points, such as cafes, restaurants, and hotels, in order to understand how many subscribers connect at each location and how the Wi-Fi infrastructure is used.
In addition, plans include completing the migration of all Wi-Fi clients to the new platform and continuing the development of traffic management tools, including prioritization and control of new traffic types. In the future, the operator is also considering NetFlow and QoE modules for enterprise customers.
Migration to the Stingray platform allowed us to scale the network without bottlenecks, deploy a stable Wi-Fi Hotspot for subscribers, and improve traffic management. The solution fully meets our requirements and helps us develop new customer services.
