DO NOT SHARE THESE DOCS WITH CUSTOMERS!
This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.
In this section:
The SBC 7000 platform includes the same functional capabilities as other members of the SBC Core, but in a much bigger scale suitable for large service providers, carriers and enterprises. The SBC 7000 offers a higher I/O-bandwidth-to-compute-power ratio than the SBC 5000 series making it more attractive product for video-heavy applications.
This scenario includes residential VoBB, VoLTE and such. Many subscribers access the SBC 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 SBC. Large numbers of subscribers are typically served through a common Zone and common IPTG.
The SBC typically requires the following:
In this scenario, the SBC 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
In this case the SBC 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 SBC 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 SBC using a layer 2 service such as metro-area Ethernet.
In this case,many enterprises are connected to the SBC 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 SBC. 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.
In this scenario the SBC is fronting a carrier-based system that registers the phones and provides call services. The SBC 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:
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 SBC within each enterprise IP space.
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 SBC from each enterprise.
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.