Session border controllers (SBCs) play an important role delivering the necessary features for serving the enterprise with IMS and TISPAN networks, says Seamus Hourihan
Tier one service providers and network equipment vendors around the world have generally embraced IMS as the architecture for building next-generation wireless, wireline and converged service networks. Yet, that general embrace doesn’t necessarily equate to capital invested and massive deployments today. In fact, in a recent Heavy Reading report Session Management, IMS, and the Future of Session Border Controllers, of the service providers surveyed, 41 per cent of respondents did not know when they’d implement IMS. Encouragingly, 37 per cent of respondents had deployments underway or would by the end of 2007. This gap between enthusiasm and deployment is due, in part, to the work that remains with the architectural frameworks.
Immersed in the dogma and excitement of IMS is a hidden danger: the enterprise is missing. By blindly implementing this next generation architecture according to current specs, service providers could leave behind their most profitable customer segment: the enterprise. IMS, the architecture defined by 3GPP for the delivery of real-time voice, video and multimedia services using SIP over packet networks, is exclusively focused on mobile wireless networks. This architecture is being extended by ETSI TISPAN to more completely satisfy the service delivery requirements in fixed wireline networks. However, even the TIPSAN architecture has yet to satisfy all the requirements associated with delivering services to enterprises. Bridging this gap, session border controllers (SBCs) play an important role delivering the necessary features for serving the enterprise with IMS and TISPAN networks.
SBCs in IMS/TISPAN architectures
IMS, as defined by 3GPP and extended by ETSI TISPAN for wireline networks, is an architecture defined in terms of functional elements, not products. While there is not an element specifically called ‘session border controller’, the defined functions exactly point to the features on SBC platforms. Within the extended IMS architecture there are two different types of SBCs: the access SBC and the interconnect SBC.
The access SBC satisfies the requirements at the border where subscribers access the IMS core. It incorporates two functional elements from the IMS and TISPAN architectures: the Proxy-Call Session Control Function (P-CSCF) and the Access Border Gateway Function (ABGF).
• P-CSCF – is the SIP signaling contact point, the outbound/inbound ‘proxy’ for subscribers within IMS and TISPAN networks. The P-CSCF is responsible for forwarding SIP registration messages from the subscriber’s endpoint, the User Element (UE), in a visited network to the Interrogating-CSCF (I-CSCF) and subsequent call set-up requests and responses to the Serving-CSCF (S-CSCF). The P-CSCF maintains the mapping between logical subscriber SIP URI address and physical UE IP address and a security association, for both authentication and confidentiality. It supports emergency call (E911) local routing within the visited network, accounting, session timers and admission control. Admission control is implemented with an interface to an external IMS Policy Decision Function (PDF) or ESTI TISPAN Resource and Admission Control Subsystem (RACS). The P-CSCF interacts with A-BGF for control of the boundary at the transport layers including pinhole firewall, Network Address and Port Translations (NAPT) and numerous other features.
• A-BGF – controls the transport boundary at layers 3 and 4 between subscribers and the service provider’s network. It performs all of the functions and features of the I-BGF. In addition, in wireline networks, it provides network-based NAT traversal for the media flows.
The interconnect SBC addresses the requirements at the boundary where different service provider networks interconnect or ‘peer.’ It incorporates three functional elements from the IMS and TISPAN architectures: the Interconnect Border Control Function (I-BCF), Inter-working Function (IWF) and Interconnect Border Gateway Function (I-BGF).
• I-BCF – provides overall control of the boundary between different service provider networks. It provides security for the IMS core in terms of signaling information by implementing a Topology-Hiding Inter-network Gateway (THIG) sub-function. This sub-function performs signaling-based topology hiding, IPv4-IPv6 inter-working and session screening based upon source and destination signaling addresses. The I-BCF also invokes the Inter-Working Function when connecting non-SIP or non-IPv6 networks, and performs admission control and bandwidth allocation using local policies or via interface to ETSI TISPAN Resource and Admission Control Subsystem (RACS). Lastly, the I-BCF interacts with I-BGF for control of the boundary at the transport layers including pinhole firewall, NAPT and numerous other features.
• IWF – provides signaling protocol inter-working between the SIP-based IMS network and other service provider networks using H.323 or non-IMS SIP implementations.
• I-BGF – controls the transport boundary at layers 3 and 4 between service provider networks. This function acts as a pinhole firewall and NAT device protecting the service provider’s IMS core. It controls access by packet filtering on IP address/port and opening/closing gates (pinholes) into the network. It uses NAPT to hide the IP addresses/ports of the service elements in the IMS core. QoS packet marking, bandwidth & signaling rate policing, usage metering and QoS measurements for the media flows are additional features supported by the I-BGF.
Serving the enterprise with IMS cores
Seven enterprise-specific requirements are currently lacking from today’s next generation architecture definitions. These functions are best implemented at the border of the IMS core, in session border controllers, to maximize service reach, assure SLAs and protect the IMS service infrastructure. The specific features defined below enable service providers to use their IMS and TISPAN cores to connect to and service their business customers with next generation services.
Surrogate registration of IP PBX & IAD phones – IMS assumes that each SIP endpoint (e.g., wireline phone, wireless phone, softclient) is capable of registering itself with its Serving Call Session Control Function (S-CSCF). However, many enterprise phones connect to SIP IADs or SIP/H.323 IP PBXs and can not register with the IMS core. The phones register with the aggregation © device (IAD or IP PBX) and that aggregation device will not forward the endpoint registrations to the IMS core. SIP registration on behalf of each individual phone located behind an aggregation device is a mandatory requirement for serving those endpoints with IMS services.
H.323 IP PBX - SIP IMS interworking – The vast majority of installed enterprise IP PBXs from vendors such as Avaya, Cisco, Siemens use H.323 as the trunking signaling protocol to connect with the outside world. Even as vendors add SIP support to their IP PBXs, deployed IP PBXs likely will remain H.323. The enterprise H.323 IP PBXs cannot be served by the SIP-based IMS core. H.323-SIP IMS interworking enables service providers to interwork these IP PBXs with their IMS network. This must include support for H.323 supplementary services, number normalization and translation to support overlapping private dial plans (i.e., 3- or 4-digit dialing).
VPN bridging – Many large enterprises use private IP address spaces that often overlap with other enterprises or use service provider supplied MPLS VPNs defined by IETF RFC 2547 to securely interconnect many office locations. The ability to bridge multiple security and IP address domains is required, enabling SIP and H.323 devices to connect to an IMS core for hosted IP Centrex services or IP PBX trunking while maintaining tight enterprise security.
Adaptive NAT/firewall traversal – IMS assumes NAT/firewall devices are not present between subscriber mobile phones and the IMS core. Enterprises, however, use NAT/firewalls to secure their networks, thus blocking all incoming calls. In order to allow the IMS core to deliver calls to enterprises, a NAT traversal function is required to enable trusted sessions to traverse enterprise-based NAT/firewalls. For the enterprise, the access SBC, represented by a single well-known IP address in a trusted service provider’s network, is more secure than alternative methods such as multiple STUN and TURN servers.
DoS/DDoS protection for IMS edge and IMS core elements – Denial-of-service (DoS) and distributed DoS (DDoS) protection from both malicious attacks and non-malicious overloads is a functional requirement absent from both 3GPP and ETSI TISPAN architectures. Without this protection, even a flood of registration messages after a city-block power failure could aversely disrupt all services. A border element that can protect itself and the IMS core elements from signaling and media attacks is critical to reliable service delivery.
Overload protection for IMS core elements – Mechanisms for preventing overloads on S- and I-CSCF functions are also missing from IMS. Service providers will require a border element to perform call rate limiting or code gaping for each CSCF based upon the number of sessions or session establishment rate. Selective admission control based upon destination or source telephone numbers to ensure valuable enterprise calls are always accommodated even in the presence of high volume, low value consumer televoting is also crucial.
Transcoding – The G.711 and G.729 codecs defined by the ITU are the de-facto-standards used by IP phones and PCs in enterprises today. The SBC needs to support transcoding to enable these enterprise endpoints to communicate with wireless and wireline endpoints that use different codecs such as AMR, EVRC, SMV and QCELP in mobile networks and other wireline codecs such as iLBC, G.723.1, G.726 and G.728.
Enterprises generate the most profits for service providers today, yet IMS and derivative next generation architectures are functionally deficient in delivering services to their most valuable customers. Session border controllers fulfill functional requirements as defined by 3GPP and ETSI and go beyond those requirements to allow service providers to wisely invest in IMS and sell services based on their IMS core to their business customers.
• Seamus Hourihan is Vice President of Marketing and Product Management, Acme Packet and can be contacted via e-mail: email@example.com