Starnet — Stingray Service Gateway Replacing Hardware Solutions

StarNet is an advanced telecommunications company with a subscriber base of over 130 thousand users. The operator is one of the three largest providers of the Moldova Republic, being a pioneer in providing Internet access via fiber-optic cable to individuals, and has been operating on the market since 2003.

The provider needed a solution for:

• Hardware replacement
• Adding IPv6
• Improving performance and reducing recovery time.

Firstly, we considered CISCO ASR, but it had many shortcomings. For example, it was unable to control transmission speed proportionally when dealing with IPv4, IPv6, and Dual-Stack clients at the same time — ASR limits transmission rate disproportionally: when traffic policing was configured to 50 Mbps, in fact, we had 100 — 50 Mbps in case of IPv4 and 50 Mbps in case of IPv6.

— Andrian Wisniewski, the StarNet lead system administrator, shares his thoughts about technical aspects of choosing the proper solution.

StarNet chose Stingray SG as a multifunctional solution that combines DPI, BNG, CG-NAT in one product.

Internet access is provided using GPON, FTTB, and Wi-Fi technologies. Most customers use a wired connection. Prior to using the Stingray Service Gateway its network scheme before optimization could be simplified like this:

 

 

Tasks

Before optimization, the network was built on several Ericsson SE1200s that performed BNG functions and NAT when necessary. About once every six months the equipment refused to work. There were attempts to search for ways to resolve this problem, but no permanent solution was ever found. So the first task was to change equipment.

The second task was adding IPv6 technology. Ericsson SE1200 handles IPv6 for PPPoE sessions only. Transferring 130 thousand users to PPPoE is technically incorrect and takes too much time and effort.

The third task was to reduce the network recovery period after downtime. Owing to its features Ericsson SE600 is capable of processing about 300 per second attempts of creating sessions. As a result, it took a little bit more than 10 minutes to fully reconnect all customers.

In our opinion, the transition to software-based solutions is more profitable for the purposes of the upgrade, scaling, and redundancy. We observed this trend in the equipment market of almost all manufacturers: CISCO, Juniper, Nokia, Huawei, HP — almost all of them have software-based BRAS, and they successfully promote it. Everything is simple — the processor load reaches critical — a new processor is installed in the neighbouring socket and the problem is solved.

The cost of Stingray solution is lower than the new devices from Juniper or CISCO. Line Card and other service cards for well-known telecom equipment manufacturers increase eventual cost even more. Besides, licences are tied to the number of customers and the amount of traffic.

Solution

While searching for the solution StarNet engineers refused to purchase a new Ericsson due to its price and the sad previous experience. As possible options, Juniper MX, CISCO ASR, and Stingray SG were considered.

The criteria were as follows:

• cost
• fault-tolerance
• clarity of documentation
• support and upgradeability
• the ability to reserve equipment
• Dual-stack (simultaneous support for IPv6 and IPv4)
• bandwidth shaping.

StarNet chose Stingray as a multifunctional solution that combines DPI, BNG, CG-NAT, DLP, DDoS protection, and Lawful Interception in one product.

We were surprised by the very fast deployment compared to Ericsson, which we set up on our own for a very long time with the help of various forums since there was no available documentation. And the final adjustment of Ericsson lasted for a year and a half.

The Stingray Service Gateway was implemented in three months. We signed an agreement at the end of October 2018. In November 2018, we received software for the test, and then a full license. We began to configure and startup of equipment. The full project implementation was completed by mid-December 2018.

Result

After implementation of the Stingray SG solution, the provider’s network scheme looks like this:

 

 

Stingray platform was implemented on Huawei hardware platform in three months. As a result:

1. All Ericsson were replaced by routers
2. Stingray SG servers were installed based on the following principle: one unit per 1 public subnet and two units as NAT servers per 1 private one
3. The operator uses the Quality of Experience Module to collect statistics to evaluate the quality of service and conduct marketing campaigns

By opinion of Andrian Wisniewski, comparative analysis Ericsson required 3-4 RADIUS procedures and about 11 attributes. In order to set data transmission rate for the subscriber, the RADIUSDB sent to BRAS 8 RADIUS parameters: inbound and outbound Moldavian traffic transmission rate, the transmission rate of external inbound and outbound traffic along with rate and burst parameters. Apart from that, there were individual authentication procedures, individual authorization procedures, and individual accounting procedures.

The Stingray platform, instead, required 2 procedures in one along with 5 attributes: accept, transmission rate and services need to be activated. We are planning to expand the network next year, whereas the positive results of the Stingray platform implementation leave no doubt that the DPI, BNG, and CG-NAT manufacturer replacement is not needed.