Session border controllers (SBCs) play a critical role in enabling and protecting the new generation of multimedia services, which are driving the deployment of voice-over-Internet protocol (VoIP) and IP multimedia subsystem (IMS) networks. By deploying properly engineered SBCs at the edge of their networks, network service providers (NSPs) can be confident that their networks are secured and that quality of service (QoS) is guaranteed. However, before deploying SBCs, NSPs should ask the following ten questions.
a) Denial of service (DoS)
Unprotected VoIP and IMS networks are exposed to the risk of DoS attacks, which are explicit attempts to prevent legitimate users from using the network by flooding the network with a large amount of traffic. With the network overwhelmed, calls originating from legitimate subscribers cannot be served, resulting in service outages.
b) Unclosed pinhole
Upon the ending of a call, the SBC should terminate the connection (pinhole) used for that particular traffic flow. Unclosed pinholes are security loopholes that hackers can exploit to attack the network with rogue media. To ensure that networks are protected, the SBC must be tested vigilantly against these illicit security threats.
Theft of services occurs when subscribers gain access to services illegally without paying for them. For example, a subscriber paying only for audio services might send video instead of audio. Since video consumes more bandwidth than audio, calls from other subscribers may be negatively affected when bandwidth is taken away from them. If this illegal traffic is not penalized, the overall QoS may be degraded. The SBC has the ability to prevent theft of services by allowing only media traffic type negotiated during the call setup to flow through. To guarantee QoS of the network can be maintained, the SBC must be tested against theft of services.
SBC vendors typically advertise the best performance figures, which are measured under a specific condition not easily achievable under real-world network conditions. To find out the SBC’s actual performance figures, its performance must be measured under real-world network traffic, which should consist of a mix of traffic in various proportions such as basic calls (60%), transferred calls (30%) or three-way calls (10%). NSPs will only be able to understand how the SBC will perform when deployed in the live network if the SBC is tested with the network load that represents the right mix of traffic in the network.
Unlike time-division multiplexing (TDM) networks, in which the bandwidths and codecs used are fixed for all calls based on the physical characteristics of the connection line, VoIP networks allow a mix of codecs, each consuming a different amount of bandwidth per call. Calls originating from different types of user-equipment, such as cell phones or VoIP fixed-line phones, could select different codecs for their calls. For example, calls originating from cell phones would likely use a highly compressed codec, such as AMR, while calls from VoIP, fixed-line phones would use a lower compressed codec such as G.711. Traffic traversing the network boundaries may also need to be transcoded so as to adapt to the different network requirements; e.g. from a bandwidth-conscious cellular network to a bandwidth-rich, fixed-line network. Because of the wide variety of codecs that can co-exist in calls traversing the same networks, the SBC must be tested with traffic consisting of the desired mix of codecs to ensure proper support of calls from different network environments.
Extreme network traffic load is triggered when a large number of subscribers are attempting to gain access to the NSP network at the same time. For example, a registration flood can be triggered by the recovery of a large-scale power outage. Upon restoration of power, all subscriber equipment affected by the outage will try to register to the network at the same time, resulting in extraordinary traffic load in the NSP network. The heavy network traffic load could overwhelm all the network resources, preventing any calls from being processed. The SBC’s ability to limit the amount of network traffic entering the NSP network is crucial to avoid service outages caused by such extreme network traffic loads. Network engineering analysis must be performed to determine the threshold of the amount of traffic that should be allowed into the SBC; such thresholds must be tested to verify the SBC’s ability to protect the NSP network against extreme network traffic loads.
In a typical residential deployment, subscribers originate calls to the NSP’s network from a firewall-protected home network that shares a single public IP address. This type of firewall-protected network relies on a gateway device (router) to provide network address translation (NAT) and map traffic from the home network to the external public network. Calls originating from a firewall-protected network will fail if the SBC cannot perform NAT traversal properly. Since NSPs have little control over how subscriber home networks are set up, their SBC must be able to traverse the subscribers’ NAT device to ensure that services are available. Therefore, it is extremely important for NSPs to validate their SBC ability to support NAT and firewall traversal.
Quality of experience (QoE) is the perception that a user has regarding the service offered by an NSP. It is determined by factors such as call setup time, packet delay, jitter and dropped packets. In VoIP and IMS networks, a call traverses a series of network elements, each of which might have a negative effect on the users’ QoE. Located at the edge of the network, an SBC processes all calls and could affect the quality of calls traversing across it. For example, under high traffic loads, significant delay may be introduced to the traffic by the SBC. Therefore, it is very important for NSPs to characterize their SBC to know the impact it will have on the subscribers’ QoE. By subjecting the SBC to QoS testing under various traffic conditions, NSPs could determine if the SBC will negatively affect the quality of the services.
The open-standards approach adopted by the VoIP and IMS architectures allows NSPs to create best-of-breed networks by selecting network equipment from different vendors. Though protocols used in VoIP and IMS networks are formalized by industry standard bodies, equipment vendors might implement proprietary extensions or draft standards that may not be fully supported by all network equipment. Should an SBC be unable to interoperate with other network elements, subscribers will not be able to make end-to-end calls. Therefore, an SBC must be tested against traffic from a wide range of network elements to ensure broad coverage of vendor equipment.
In today’s competitive environment, SBC deployment must be done cost-effectively. NSPs need to make sure that the initial investment made in network equipment (including the SBC) is not overly costly and that the SBC is sufficient to meet the short-term capacity requirements. As capacity demand increases, the selected SBC must be expandable at a reasonable cost. NSPs need to understand whether the maximum capacity of the SBC will meet their projected long-term subscriber growth so as to make an intelligent investment decision.
IMS is quickly becoming the architecture of choice for most NSPs offering next-generation converged services. SBCs deployed in VoIP networks must be able to process IMS network traffic to preserve the NSP’s investment when migrating to an IMS network architecture. To guarantee smooth migration, SBCs deployed today must be tested against IMS traffic to validate its IMS compliance.
Undoubtedly, SBCs play a critical role in enabling NSPs to offer good-quality and reliable services to their subscribers. With proper understanding of SBC characteristics, NSPs can better plan and engineer their networks if their SBCs are tested in the following critical areas:
SBCs will remain an important network component for delivering interactive, secure, interoperable and scalable communications across regional and worldwide IP networks. The work begins in the carriers’ laboratory and requires carriers to invest sufficient effort and testing to ensure that the SBC delivers its promise in their own network architecture.