SBC 7000 Deployment Scenarios

Overview 

The 

 platform includes the same functional capabilities as other members of the , but in a much bigger scale suitable for large service providers, carriers and enterprises. The  offers a higher I/O-bandwidth-to-compute-power ratio than the  making it  more attractive product for video-heavy applications.

• Service Provider Access – High subscriber and simultaneous call scale coupled with high availability and redundancy
• Service Provider Peering – High simultaneous call scale coupled with high availability and redundancy
• Enterprise and Service Provider Video – Supports large WAN interface bandwidth
• Wireless – Supports a large number of subscribers and calls where high availability is essential

Consumer Access

This scenario includes residential VoBB, VoLTE and such. Many subscribers access the

through a shared IP network and require CPU-intensive Hosted NAT Traversal (HNT). Simultaneous calls per subscriber is low, so must support many subs to “fill” the . Large numbers of subscribers are typically served through a common Zone and common IPTG.

The

 typically requires the following:

• One Address Context (AC) and one or a few IP interfaces (LIFs)
• One or a few Zones and IPTGs
• High fanout for registrations, TLS

SIP - Trunking

In this scenario, the

connects to PBXs at many enterprise sites which does not require registration. Typically, it requires a Zone per enterprise and an IPTG per site (with one or more sites per enterprise).  There are two important sub-cases corresponding to the type of IP layer connectivity

SIP Trunking with Private IP Access per Enterprise

In this case the

must connect to each enterprise’s PBX within the enterprise’s own private IP address space.  For example, when a carrier provides a layer 3 VPN service such as RFC 2547-style BGP-MPLS VPNs and deploys the SBC with simultaneous IP connectivity into each VPN.  The uses distinct Address Contexts and IP Interfaces (VLANs) to connect to each enterprise’s IP VPN.  Another case would be where each enterprise is connected separately to the using a layer 2 service such as metro-area Ethernet.

SIP Trunking with Common IP Access

In this case,many enterprises are connected to the

over a common IP internetwork and can be an actual shared IP access network.  It can also be an IP subnet that is advertised into each enterprise’s carrier-provided IP VPN and that contains common services provided by the carrier such as the . The SBC uses a single Address Context and one or a few IP Interfaces in total to connect to all the enterprises in this scenario.

Enterprise – IP Centrex

In this scenario the

is fronting a carrier-based system that registers the phones and provides call services. The must process registrations but typically need not do HNT.  It may not need detailed billing stats support since the Centrex service covers that and this consideration may allow allocating an IPTG per enterprise rather than one per site. This scenario has the same two subcases as SIP trunking, based on the type of IP layer connectivity:

IP Centrex with Private IP Access per Enterprise

This is very similar to the “SIP Trunking with Private IP Access per Enterprise” case except that it is individual UAs rather than a PBX that are interacting with the

within each enterprise IP space.

IP Centrex with Common IP Access

This is very similar to the “SIP Trunking with Common IP Access” case except that it is individual UAs rather than a PBX that are interacting with the

from each enterprise.

Carrier Peering

This scenario covers carrier interconnect with other carriers. It typically happens using public IP addresses and hence does not use many ACs. The number of peers is presumed to be in the single thousands, so the number of Zones and IPTGs required is moderate. Separate IP Interfaces may be used to connect with each peer, or a small number of IP interfaces to a common IP interconnect network may be used.