Session Border Control in IMS

An analysis of the requirements for Session Border Control in IMS networks

Jonathan Cumming, jonathan.cumming@metaswitch.com

First issued March 2007

100 Church Street, Enfield, England, EN2 8BQ | www.metaswitch.com

Executive Summary
There is a lot of controversy and press coverage over both the role of Session Border Controllers (SBCs) and the design of the IP-Multimedia Subsystem (IMS). In this environment it is difficult to determine what are the real issues for each technology, let alone how they need to work together. This white paper is aimed at equipment manufacturers looking at building SBC functionality into their product range to target the IMS market, and carriers and consultants looking to understand how an SBC fits into an IMS network. It explains why IMS networks need session border control and what alternatives are available. It also looks at how these requirements are likely to evolve as services and access methods change, and discusses the function that products targeting this market require. SBCs are described both as a cure-all for next generation telecommunications networks and as an unnecessary attempt by carriers to stop their business becoming a simple bit-carrying commodity. This paper seeks to explain how these different views arise and the varied roles that SBCs play in IMS. About the Author Jonathan Cumming is Director of VoIP Product Management at Metaswitch. During his 7 years at Metaswitch, he has held a range of development, marketing and product management roles. Jonathan has over 17 years' experience in the communications software industry. He holds an MBA from INSEAD and an Engineering degree from Cambridge University.

100 Church Street, Enfield, England, EN2 6BQ | www.metaswitch.com

Table of contents
1. Introduction ............................................................................................................................1 1.1 1.2 2. Overview of Session Border Control................................................................................... 2 Overview of IMS................................................................................................................ 5

IMS Requirements for SBC .....................................................................................................12 2.1 2.2 2.3 2.4 2.5 2.6 Security........................................................................................................................... 13 Call Admission Control.....................................................................................................14 Monitoring....................................................................................................................... 15 Privacy ............................................................................................................................ 15 VoIP Protocol Problems ....................................................................................................16 Summary......................................................................................................................... 17

3.

IMS architecture for SBC ........................................................................................................18 3.1 3.2 3.3 UNI..................................................................................................................................19 NNI................................................................................................................................. 20 Reference Points..............................................................................................................21

4.

IMS SBC Products................................................................................................................. 24 4.1 4.2 4.3 Scope of function............................................................................................................ 24 Management and Control................................................................................................ 29 Product Evolution............................................................................................................ 29

5.

The Future ............................................................................................................................. 31 5.1 5.2 The Future of IMS ............................................................................................................. 31 SBC Function Evolution ................................................................................................... 32

6. 7.

Conclusion ............................................................................................................................35 Further Information............................................................................................................... 36 7.1 7.2 7.3 Sources .......................................................................................................................... 36 Reference material.......................................................................................................... 36 Glossary of Acronyms ......................................................................................................37

8.

About Metaswitch................................................................................................................. 39

Copyright Metaswitch Networks. Confidential | Page i

1. Introduction
The IP-Multimedia Subsystem (IMS) defines the functional architecture for a managed IP-based network. It aims to provide a means for carriers to create an open, standards-based network that delivers integrated multimedia services to increase revenue, while also reducing network CapEx and OpEx. IMS was originally designed for third-generation mobile phones, but it has already been extended to handle access from WiFi networks, and is continuing to be extended into an access-independent platform for service delivery, including broadband fixed-line access. It promises to provide seamless roaming between mobile, public WiFi and private networks for a wide range of services and devices. This move, from a centrally managed network with control over the core and access networks to an open network with soft clients, represents a sea change in the applicability and deployment of IMS. Previously, it was aimed at centrally-managed networks with significant control over the core and access networks and the clients. Now it is moving to a much more open network model, where previous assumptions about the sorts of connecting networks and clients break down. This introduces the need for session border control at the network boundary to provide security, interoperability and monitoring. This white paper examines these evolving requirements for IMS and where session border control fits in the IMS functional architecture. It also assesses the market for equipment targeting this space; both the evolution of existing equipment to handle these new requirements and the likely future evolution as the market and technology mature. This chapter provides an overview of session border control and IMS. Chapters 2 and 3 cover the requirements for session border control in IMS and how this function fits into the IMS architecture Chapters 4, 5 and 6 discuss what products need to address these requirements, how this market is likely to change in the future, and what conclusions can be drawn from this. Chapter 7 provides a list of references to additional information and a glossary of the acronyms used throughout this document. Chapter 8 contains information on Metaswitch and its products.

Copyright Metaswitch Networks. Confidential | Page 1

1.1 Overview of Session Border Control

Session border control is not a standardized set of functions. Instead, Session Border Controllers (SBCs) have evolved to address the wide range of issues that arise when voice and multimedia services are overlaid on IP infrastructure. These include enforcing call admission control policies at the network border security and prevention of service abuse to ensure Quality of Service (QoS) monitoring for regulatory and billing purposes maintaining privacy of carrier and user information resolution of VoIP protocol problems arising from the widespread use of firewalls and network address translation (NAT), and the vast array of differing protocols and dialects used in VoIP networks. These issues are relevant for access to both carrier and enterprise networks, and on both UserNetwork Interfaces (UNI) to end users and access networks, and Network-Network Interfaces (NNI) to peer networks. The following diagram shows where SBC function is typically required.

Signaling Media Services

SBC Protecting Enterprise

UE

SBC Protecting Core

Enterprise Network

Core Network

SBC Protecting Core

SBC Protecting Core Peer Network

UNI

NNI

The diagram depicts a single device at the edge of each network (a traditional SBC), but there is actually great flexibility in how this function is distributed. For example, a device in the access network might perform initial user authentication an edge device might enforce access policy to limit Denial of Service (DoS) attacks and prevent bandwidth theft core devices might limit the total usage for a particular group of users and detect distributed DoS attacks. The location of each function will depend on the overall system design, including the availability of processing resources and the level of trust between the different devices.

Copyright Metaswitch Networks. Confidential | Page 2

The following sections describe each of the SBC functions. For a more detailed description of Session Border Controllers, see our white paper: Session Border Controllers: Enabling the VoIP revolution.

1.1.1 Call admission control

Call admission control (CAC) policies serve two main purposes. They prevent key network resources from being over-utilized. This is crucial to prevent new calls from being set up in an unchecked manner and degrading the services being provided to existing calls. They enforce service level agreements. At the UNI, this might be an agreement between the owner of the access or enterprise network and the provider network. At the NNI, CAC policies represent the set of reciprocal agreements between provider networks. Session border controllers are the logical point in the network to enforce CAC policies. This is because they are VoIP session aware devices which can enforce policy at the network edge before core network bandwidth is consumed or sensitive core network devices are affected by unwanted traffic. Session border controllers may incorporate an on-board policy database that can be configured to enforce various limits on VoIP traffic. Alternatively, in more complex network models, SBCs may contact a separate policy server when users make service requests. The policy server makes an admission control decision on the SBCs behalf, and may in some cases also reserve media plane resources for those services at the edge of the provider network and in the access network.

1.1.2 Security
An insecure network cannot charge for its use or provide a guaranteed QoS service, because unauthorized users cannot be prevented from overusing limited network resources. SBCs can provide security and protection against unauthorized access into the trusted network invalid or malicious calls, including Denial of Service (DoS) attacks bandwidth theft by authorized users unusual network conditions, for example a major emergency.

Typical resources that require protection are bandwidth on access links and processing capacity on network servers. In general, core network links can be cheaply over-provisioned to help prevent them becoming bottlenecks.

Copyright Metaswitch Networks. Confidential | Page 3

To provide this security, the SBC identifies and authenticates each user and determines the priority of each call limits call rates and resource usage to prevent overloads authorizes each media flow and classifies and routes the data to ensure suitable QoS prevents unauthorized access for both signaling and media traffic.

QoS across the core of the network is normally handled by an aggregated classification mechanism, for example DiffServ, as this removes the overhead of reserving bandwidth for each individual flow. The SBC may also be used to enforce QoS in the access network by signaling to the access routers or instructing the endpoint to reserve necessary resources across the access network. Alternatively, an intelligent access network may independently determine appropriate QoS for the media streams by analyzing the call signaling messages.

1.1.3 Monitoring
Network usage may need to be monitored for regulatory reasons (such as wiretapping and QoS monitoring), as well as commercial reasons (such as billing and theft-detection). The monitoring devices need sufficient intelligence to understand the signaling and media protocols. They must also be located at a point through which all media and signaling flows. SBCs fulfill both these requirements as all traffic passes through an SBC to enter the network. They provide a scalable, distributed solution to this processing-intensive function.

1.1.4 Maintaining Privacy

The following two types of information need to be protected. Information about the core network, which might provide commercially sensitive information to a competitor or details that could aid an attack. Information about a user that the user does not wish to be made public.

An SBC can be used to remove confidential information from messages before they leave the core network, including details of internal network topology and routing of signaling through the core network. It can also hide the real address of the user by acting as a relay for both the media and the signaling.

Copyright Metaswitch Networks. Confidential | Page 4

1.1.5 Resolution of VoIP Protocol Problems

SBCs can also act as gateways to heterogeneous networks; hiding any differences between in the protocols used in the core and access networks. This can include the following. Hiding access network topology, including the complexity of routing through NATs and firewall and to overlapping address spaces of VPNs or private IP address spaces. Interworking between devices and networks of different capabilities (such as conversion between SIP and H.323 signaling, or between IPv4 and IPv6, or even different versions of H.323). Transcoding media flows between incompatible codecs.

Putting this function in the SBC, which is close to the access device, simplifies the core network devices by limiting the range of protocol variations that they must support.

1.2 Overview of IMS

IMS is the control plane of the 3rd Generation Partnership Project (3GPP) architecture for its nextgeneration telecommunications network. This architecture has been designed to enable operators to provide a wide range of real-time, packet-based services and to track their use in a way that allows both traditional time-based charging as well as packet and service-based charging. IMS provides a framework for the deployment of both basic calling services and enhanced services, including multimedia messaging web integration presence-based services push-to-talk.

At the same time, it draws on the traditional telecommunications experience of guaranteed QoS flexible charging mechanisms (time-based, call-collect, premium rates) lawful intercept legislation compliance.

Copyright Metaswitch Networks. Confidential | Page 5

Network operators also hope that IMS will cut their CapEx and OpEx through the use of a converged IP backbone and the open IMS architecture. The IMS architecture defines many common components (for example, call control and configuration storage) so less development work is required to create a new service as this existing infrastructure can be reused. The use of standardized interfaces should increase competition between suppliers; preventing operators from being locked into a single suppliers proprietary interfaces. As a result, IMS should enable new services to be rolled out more quickly and cheaply, compared with the traditional monolithic design of telephony services.

1.2.1 History and evolution

IMS was initially developed as a call control framework for packet-based services over 3G mobile networks as part of 3GPP Release 5 (2003). It was then extended to include WiFi roaming and additional services such as presence and instant messaging in Release 6 (2004/5). Although originally designed for mobile networks, both ETSI TISPAN and the Multi-Service Switching Forum (MSF) have now also adopted the IMS architecture for their visions of fixed telecommunications networks. Discussions within these groups are driving the IMS extensions to cover fixed networks in 3GPP Release 7 (work-in-progress) and many of the session border control requirements that fixed network access introduces. At this point, it should also be noted that the design of 3GPP Release 7 is not yet complete and there is still some uncertainty over the scope and location of specific functions. However, although the names and details of the specification are likely to change, the principles and issues described in this document are unlikely to be significantly affected.

1.2.2 Drivers
Although originally developed for mobile operators, the main interest in IMS is from fixed line operators, as the existing fixed-line network is older and is due for replacement, whereas much of the mobile infrastructure has only recently been deployed. In particular, the current generation of fixed telephone networks is limited to narrowband voice services and is at great risk of being displaced by mobile and Internet telephony services. An IMSbased network would enable fixed line operators to offer a much wider range of services, to help protect their market. Despite the widespread industry support for IMS, many uncertainties remain over its value. The cost of a providing such a QoS-enabled managed network is high compared with the Internets stateless model. Also, as the success of Vonage and Skype and many other VoIP providers testifies, telephony services are easily provided over the public Internet and the quality is sufficient for many situations.

Copyright Metaswitch Networks. Confidential | Page 6

In order to justify the investment in IMS, the resulting service must be significantly better than that available over the Internet and people must be prepared to pay for it. Whether IMS is a commercial success will be determined over the coming years, but competition from Internet-based providers will make this a competitive market.

1.2.3 Architecture
IMS decomposes the networking infrastructure into separate functions with standardized interfaces between them. Each interface is specified as a reference point, which defines both the protocol over the interface and the functions between which it operates. The standards do not mandate which functions should be co-located, as this depends on the scale of the application, and a single device may contain several functions. The 3GPP architecture is split into three main planes or layers, each of which is described by a number of equivalent names: Service or Application Plane, Control or Signaling Plane, and User or Transport Plane.

Copyright Metaswitch Networks. Confidential | Page 7

1.2.3.1 Application plane

The application plane provides an infrastructure for the provision and management of services, and defines standard interfaces to common functionality including configuration storage, identity management, user status (such as presence and location), which is held by the Home Subscriber Server (HSS) billing services, provided by a Charging Gateway Function (CGF) (not shown) control of voice and video calls and messaging, provided by the control plane.

1.2.3.2 Control plane

The control plane sits between the application and transport planes. It routes the call signaling, tells the transport plane what traffic to allow, and generates billing information for the use of the network. At the core of this plane is the Call Session Control Function (CSCF), which comprises the following functions. The Proxy-CSCF (P-CSCF) is the first point of contact for users with the IMS. The P-CSCF is responsible for security of the messages between the network and the user and allocating resources for the media flows. The Interrogating-CSCF (I-CSCF) is the first point of contact from peered networks. The ICSCF is responsible for querying the HSS to determine the S-CSCF for a user and may also hide the operators topology from peer networks (Topology Hiding Inter-network Gateway, or THIG). The Serving-CSCF (S-CSCF) is the central brain. The S-CSCF is responsible for processing registrations to record the location of each user, user authentication, and call processing (including routing of calls to applications). The operation of the S-CSCF is controlled by policy stored in the HSS. This distributed architecture provides an extremely flexible and scalable solution. For example, any of the CSCF functions can generate billing information for each operation. The following diagram shows the routing of a typical call in an IMS environment and the two distinct uses of the NNI. Roaming (the left-hand NNI): This is required to access services provided by your own service provider (home network) when connected to another carriers network (visited network). Interworking (the right-hand NNI): This is required when placing a call to a customer of a different carrier network. The call signaling flows from the caller pass through the P-CSCF in the visited network to his home SCSCF. The signaling then passes onto the called party via his S-CSCF.

Copyright Metaswitch Networks. Confidential | Page 8

Signaling Media S-CSCF

S-CSCF

I-CSCF

S-CSCF

I-CSCF P-CSCF

P-CSCF I-CSCF P-CSCF

Home Network

UE Access Network

UNI Visited Network

NNI

NNI

UNI Called Network Access Network

UE

1.2.3.3 Resource and Admission Control Subsystem

The Control Plane controls User Plane traffic through the Resource and Admission Control Subsystem (RACS). The Service-based Policy Decision Function (SPDF) acts on behalf of the provider network and implements the provider networks admission control policies. Typically these are global policies that prevent the network from being over-utilized. The Access-Resource and Admission Control Function (A-RACF) is a component used only with wireline access networks. It acts on behalf of one or more access networks (which in general may be owned and operated by a separate organization from the provider), and implements the access networks admission control policies. These are usually policies that prevent the networks bandwidth from being over-utilized. When a user requests new services in the signaling plane, the P-CSCF contacts the SPDF and requests an admission control decision. The SPDF checks the provider network policies, and then requests an admission control decision from the particular A-RACF that manages the access network the user is connecting over. This two-stage policy check is necessary because the provider and access networks may be owned by separate organizations, and so in general multiple provider networks may be making demands of the same access network. If both admission control decisions are positive, the SPDF and A-RACF also reserve QoS within the core network edge and access network respectively corresponding to the service that was requested, before informing the P-CSCF that it may proceed in signaling the service request onwards.

Copyright Metaswitch Networks. Confidential | Page 9

1.2.3.4 Network Attachment Subsystem

The Network Attachment Subsystem (NASS) is a subsystem of components used only with wireline access networks. It is responsible for providing network connectivity to users on the access network. It authenticates user equipment, assigns an IP address to it by running a DHCP server, and informs the A-RACF of user equipment properties and QoS profiles to use for particular users.

1.2.3.5 User plane

The User plane provides a core QoS-enabled IPv6 network with access from User Equipment (UE) over mobile, WiFi and broadband networks. This infrastructure is designed to provide a wide range of IP multimedia server-based and P2P services.

IMS Authentication and access control Call Signaling Media Control Media

IMS Core

To IMS Services

3GPP IPv6 core

IP Address Allocation User Authentication (Transport) Routing and Concentration

GGSN

PDG

BAS

SGSN

WAG

DSLAM

UE

P PD GPRS/UMTS Access Release 5

xt te on C

el nn Tu Wireless LAN Access Release 6

UE

UE Broadband Access Release 7

Although IPv6 is defined for this transport plane, many initial deployments are built upon existing IPv4 infrastructure and use private IPv4 addresses. This introduces Network Address Translators (NATs) at the boundary of each address domain and the associated difficulties routing VoIP calls across the boundary. Access into the core network is through Border Gateways (GGSN/PDG/BAS). These enforce policy provided by the IMS core: controlling traffic flows between the access and core networks, as follows. With GPRS/UMTS access, the GGSN authenticates the user equipment (UE) and controls the establishment of media channels using authenticated PDP contexts. This enforces QoS and access control through the access network to the UE. With Wireless LAN (WLAN) access, the Packet Data Gateway (PDG) controls the establishment of tunnels through the access network to the UE. These tunnels provide security of the

Copyright Metaswitch Networks. Confidential | Page 10

3GPP Release 7 adds support for IP connectivity over a range of access technologies including wireline access via DSL and Cable. 3GPP are working with ETSI TISPAN to define R7 standards, where the IMS core is connected to external networks through Border Gateways that are not part of the core IMS specifications.

It is this change from a very controlled network with limited access methods in Releases 5 and 6, to a much wider range of access devices in Release 7, which introduces the need for Session Border Controllers.

Copyright Metaswitch Networks. Confidential | Page 11

2. IMS Requirements for SBC

Some of the functions provided by a Session Border Controller have always been important and inherent in IMS, given its role in providing a QoS-enabled service with detailed usage monitoring to enable charging for its use. Others are only now becoming important as Release 7 expands the range of supported access methods. This chapter looks at the requirements for this functionality and how they are changing. The IMS architecture consists of interconnected core networks belonging to different carriers, with endpoints connected through attached access networks, and gateways to non-IMS networks. Border gateways control access into and out of each core network, monitoring and regulating the data flows on each interface. This architecture is shown on the diagram below.

IMS Core

IMS Core

IMS Core

UNI Border Control

NNI Border Control

NNI Border Control

NNI Border Control

NNI Border Control

Access Control

UNI Border Control

Visited Network

Home Network

Called Network

Access Control

Call Signaling Caller Access Control Media

Callee

The core network needs to be protected against all of the threats described in section 1.1, but each interface imposes a different set of border control requirements due to differences in the attached devices and access networks. The following sections describe the common requirements and the specific issues that each interface introduces.

Copyright Metaswitch Networks. Confidential | Page 12

2.1 Security
Security in IMS Releases 5 and 6 is designed around an open IPv6 core with well protected access. Access to the network core is protected using transport layer security on the UNI in the form of authenticated PDP contexts and tunnels. The NNI is an internal trusted interface within this secure core, so requires very little security. However, 3GPP Release 7 and the reality of early IMS deployments have changed this model, and have expanded the range of security needed on each interface. Nevertheless over some interfaces, a subset of this functionality may be provided by the access network.

2.1.1 User-Network Interface (UNI)

The expanding range of access devices and reduced control over the access network has increased the responsibility on the border controller at the edge of the core network. In 3GPP Release 5, only GPRS/UMTS access networks are supported. In this environment, the P-CSCF uses the GGSN to control access and bandwidth use through the entire access network all the way to the handset. Additional DoS controls on the signaling can be applied by the P-CSCF, but due to the controlled design and certification of handsets, there is limited scope for such attacks. The addition of WLAN access in 3GPP Release 6 does not greatly expand the range of protection required at the network border, as traffic into the core is controlled through tunnels managed by the PDG. In addition, Release 6 is primarily aimed at data roaming between 3G and WLAN, not the handling of voice calls over WLAN access, so there is limited function to protect. Release 7 expands both the range of supported access methods and the function, and as a result greatly expands the scope of attack. In addition, the core network now exerts little control over the access network, so the border gateway becomes its first line of defense. As 3GPP has progressed from Release 5 to Release 7, the additional supported access methods have significantly increased the scope for Denial of Service (DoS) attacks to be launched against the network. Therefore, in IMS the SBC plays a key role in detecting and eliminating such attacks before they impact the core network or the service experienced by legitimate users. Cutting-edge SBCs will identify the source of a DoS attack by analyzing suspicious traffic, and will intelligently blacklist that source whilst allowing service for other users to continue.

Copyright Metaswitch Networks. Confidential | Page 13

2.1.2 Network-Network Interface (NNI)

Early IMS deployments have identified that security on the NNI is also required to protect the core network from malicious or unexpected behavior by a peer, and to prevent a problem in one network core affecting other.

2.2 Call Admission Control

CAC is a set of policies designed to control utilization of network resources and police SLAs between networks. Session border controllers are the best network device on which to enforce CAC policies. In IMS however, CAC policies may actually be provisioned and accessed on standalone network devices. In 3GPP R5 and R6, the PDF stored all CAC policy and processed admission control requests over the Ro interface from the P-CSCF. In 3GPP R7, the situation is more complex. The SPDF takes CAC policy decisions for the core network, and the A-RACF takes CAC policy decisions for the access network. Both the SPDF and A-RACF are involved in making an admission control decision for each service request. The reason for this increased complexity lies in the new access methods supported by 3GPP R7. Prior to R7, all access networks were cellular. This commonality of access network type meant that a single device the PDF could encompass all the intelligence needed to take admission control decisions and reserve media plane resources. From R7, the IMS core is being altered to be more independent of access network type, so that new access methods can be added easily in the future. For this reason, in R7 the PDF is split into a component dependent only on the service being requested (the SPDF) and a component that implements access-network-specific procedures (the ARACF). This allows a new service model where a core IMS network provider owns (or leases the services of) an SPDF and allows access from any partner access network capable of delivering IP. Meanwhile, an access network provider owns an access-method-specific A-RACF device, which communicates with the SPDF of their partner core network over a well-defined interface (the Rq reference point). The R7 architecture provides scope for a number of potential models for session border controllers. Some SBCs may implement no CAC policies themselves, and offload all policy decisions to separate SPDF and A-RACF devices. These will be lower-cost IP-only devices. More complex SBC devices may choose to incorporate an SPDF, implementing core network policies and reserving core network resources themselves. These will be higher-end IP-only devices offering more inbuilt function and eliminating the need for another vendors SPDF.

Copyright Metaswitch Networks. Confidential | Page 14

There is also scope for specialist SBC devices that act as gateways between specific types of access network and an IP core. These SBCs will be aimed at providers who require tighter integration with the access network (for example, providers who own the access network) and will incorporate both SPDF and A-RACF functionality.

These models are discussed in more detail later in this document.

2.3 Monitoring
Government regulations and commercial reasons both require monitoring of network use. 3GPP Release 5 did not include monitoring on the NNI. However, reconciliation of inter-carrier charges, monitoring of service level agreements (SLAs), and lawful intercept of calls traversing the network, have all increased the need for monitoring on this interface.

2.4 Privacy
Privacy of both network topology and user information is required on all interfaces. Again, network topology hiding was not considered in the design of 3GPP Release 5, but is considered a requirement for real deployments to protect this commercially-sensitive information from peers. The requirements of Telco networks impose two aspects to privacy of user information. A caller may request for his identity to be hidden from the callee. The callerss identity must be available for emergency calls and lawful intercept regulations.

These requirements mean that user policy may modify the visible identification of the user to the callee, but that the signaling within the trusted core must continue to contain the true identity of the caller at the border of the trusted network, the true identity of the caller must be removed.

The border of the trusted network may be the edge of one carriers core, or contain the core networks of several different carriers, depending on the regulations under which each operates.

Copyright Metaswitch Networks. Confidential | Page 15

2.5 VoIP Protocol Problems

VoIP protocol problems were not seen as an issue in 3GPP Releases 5 and 6. However the importance of this area has been raised by two factors: the use of IPv4 and other interoperability issues in early IMS trials the inclusion of NATs and a wider range of devices and network topologies in Release 7.

The scope of VoIP protocol problems seen depends on the interface and access method, as each has very different characteristics.

2.5.1 User-Network Interface (UNI)

The UNI border typically has to handle a large number of separate connections from individual users and a wide range of equipment, so it has to deal with a wide variety of protocol variants and network topologies. It is not decided whether responsibility for NAT and firewall traversal issues is part of the IMS architecture, but functionality is required to enable interworking across such devices.

2.5.2 Network-Network Interface (NNI)

The NNI handles the signaling and media traffic between IMS carriers and through gateways to nonIMS carriers. A single interface typically handles a small number of high-volume connections with peer carriers. The original IMS architecture envisaged a pure IPv6 IMS network core with minimal protection at the NNI boundaries. However, this model has changed due to the need to interoperate with non-IMS and pre-standard networks, such as IPv4 networks, and the requirement from carriers to protect their network core. The effect of this on the IMS architecture is to add an SBC on the NNI. The NNI border controller may therefore provide the following. Interworking between signaling protocols, protocol variants and media codecs Network Address and Port Translation (NAPT) function.

Firewall and NAT traversal mechanisms are not required, as the peer carrier is expected to manage its own NAT/Firewall.

Copyright Metaswitch Networks. Confidential | Page 16

2.5.2.1 IPX Proxy

The GSM Association (GSMA) has identified the need for centralized interconnection of multiple carriers through an inter-carrier carrier that provides both IP connectivity and a clearinghouse for inter-carrier charges. This mimics the existing inter-GSM carrier (GRX) networks and removes the need for bi-lateral agreements between all interconnected carriers. This inter-carrier IP network is known as an IPX network. In addition to simple connectivity, the IPX network provider can also provide a wide range of session border control functionality to its customers by providing an SBC within the IPX network. This SBC is known as an IPX proxy.

2.6 Summary
The following table summarizes the original SBC function defined in 3GPP Releases 5 and 6, and the new function introduced with Release 7 and early IMS deployments. Releases 5 and 6 Security Access network enforces access controls Peer networks are trusted CAC Single policy interface for requesting admission of services. Privacy Topology hiding not considered User privacy is handled by the P-CSCF Topology hiding required. Media relayed to hide end-user location User privacy may be required at gateways to non-IMS networks Monitoring VoIP Protocol problems Monitoring of UNI for billing and lawful intercept Monitoring of NNI to enforce intercarrier agreements NAT to support IPv4 core with private addresses. NAT / firewall traversal on UNI Interoperability with devices with limited function Multiple policy interfaces for requesting admission of services. Additional requirements in Release 7 and Early IMS Border gateway enforces policy at all network boundaries

Copyright Metaswitch Networks. Confidential | Page 17

3. IMS architecture for SBC

As discussed earlier, session border control is inherent in the design of IMS. However, unlike architectures defined by other standards bodies, for example the Multi-service Switching Forum (MSF), the IMS architecture does not include a device labeled SBC. This chapter describes how SBC function fits onto the IMS-defined functional architecture, and how this architecture is evolving to handle the increasing requirements. The IMS architecture defines separate sets of functions for each access type. However many of these functions perform similar roles in the network and each role provides the same subset of session border control function.

The following sections describe the differences between the function required on the UNI and NNI and the set of IMS functions that may be combined into an IMS-targeted SBC.

Copyright Metaswitch Networks. Confidential | Page 18

3.1 UNI
The following diagram shows how the IMS functions could be combined at the UNI to build an SBC for 3GPP Release 6 and Release 7 network access.

SBC
P-CSCF Gq' RACS A-RACS SPDF Ia A-BGF P-CSCF

Internal Signaling

Internal Media

SBC
P-CSCF Gq

SIP Signaling Diameter H.248 COPS PDF Go Media Unspecified

R7 Access Network

PDG R6 Access Network

In both R6 and R7 access scenarios, the RACS / PDF components could either be a part of the SBC itself, or else could be separate devices with which the SBC communicates over the network. These options are discussed in more detail in section 4. In terms of the 3GPP architecture, the SBC function is split between the following logical functions. R6 - GPRS/UMTS/WiFi P-CSCF Controls security over the access network Tells the PDF what resources are required for the call PDF / SPDF Implements media resource allocation policy Authorizes media resource requests from BGF Programs the A-BGF to accept media flows Additional SBC features in R7 SIP Application Level Gateway (ALG) for IPv4 address translation and NAT firewall traversal

Copyright Metaswitch Networks. Confidential | Page 19

R6 - GPRS/UMTS/WiFi A-RACF Function incorporated into GGSN/PDG

Additional SBC features in R7 Controls resources within the access network In 3GPP Release 7, the management of the access network is split out of the expanded PDF into the A-RACF. The combination of the A-RACF and SPDF is known as the Resource and Admission Control Subsystem (RACS).

A-BGF

Provides media relay for hiding endpoint address with managed pinholes to prevent bandwidth theft

Implements NAPT and NAT/Firewall traversal for media flows

The I-CSCF could also be part of an SBC in some situations.

3.2 NNI
The SBC-related functions within the NNI have a similar architecture to the UNI. This is shown in the following diagram. Again, the I-CSCF could also be part of the SBC in some situations.

Internal Signaling

SBC I-CSCF IBCF

SIP Signaling H.248 Media

Internal Media I-BGF

The IBCF and I-BGF are new functions in IMS Release 7. SBC features provided IBCF Interconnect Border Control Function I-BGF Interconnect Border Gateway Function Transport-level security Tells the RACS what resources are required for the call NAPT function and control of NAPT in BGF Media relay for hiding endpoint address Pinholes to prevent bandwidth theft NAPT and NAT/Firewall traversal for media flows

Copyright Metaswitch Networks. Confidential | Page 20

There is ongoing discussion whether the IBCF and I-BGF function should be standardized within the IMS architecture. The ETSI TISPAN recommendation is that they remain outside the core specifications, providing a flexible gateway to other networks. There is also discussion over the inclusion of a standardized RACS function between the IBCF and IBGF, as on the UNI, to mediate requests for media resources and manage local policy.

3.3 Reference Points

A reference point is a standardized interface between two IMS functions. It defines both the functions that it links and the protocol across the interface. Each reference point is denoted by the combination of one upper and one lower case letter, e.g. Gq. The following diagram illustrates the reference points used at the UNI.
SIP RTP DIAMETER H.248 DHCP Unspec.
NASS DHCP e4 RACS Rq Gm IMS Core Mw

P-CSCF
e2 Gq'

User
DSL Access Network

CLF
Re

A-RACF

SPDF

Ia RTP IP Access Network RTP

RTP

RCEF

BGF

The following diagram shows the reference points used at the NNI.

Copyright Metaswitch Networks. Confidential | Page 21

Legacy Network

Mw / Mk / Mm IMS Core

Iw

P-CSCF / I-CSCF / S-CSCF SIP RTP DIAMETER H.248 H.323 etc.

IBCF
Gq' RACS

Ic

Other Network

SPDF

Ia IP Core Network RTP RTP Other Network

BGF

I-BGF

The main reference points involved in session border control from these two diagrams are described in the following subsections.

3.3.1 Call Signaling (Gm, Mw, Mk, Mm, Ic)

All call signaling in IMS uses the Session Initiation Protocol (SIP). For a comprehensive introduction to SIP, see our white paper: SIP Market Overview.

3.3.2 P-CSCF to PDF / SPDF (Gq / Gq)

This reference point controls requests for network bandwidth from the IMS core. The original Gq interface in Release 6 enabled access control policy to be centralized in a separate Policy Decision Function (PDF). The Gq reference point is based on the Diameter protocol and enables the P-CSCF to request an authorization token from the PDF for access for a specified bandwidth. This reference point is being expanded in Release 7, to include the direct control of access. The Gq reference point enables the P-CSCF to program the BGF to perform specific NAPT and NAT traversal function, as well as control the access network. This revised interface also uses Diameter as its transport.

Copyright Metaswitch Networks. Confidential | Page 22

3.3.3 CLF to P-CSCF (e2)

This reference point communicates information to the P-CSCF concerning the identity and properties of the access network to which a subscriber is connected, their geographical location, and the SPDF address to whom the P-CSCF should address Gq requests for that subscriber. For each service requested by a subscriber, the P-CSCF sends a query for the relevant information over the e2 reference point. This is a new reference point introduced in release 7. It uses Diameter as its transport.

3.3.4 SPDF to A-RACF (Rq)

This is a new reference point introduced in release 7. It is very similar to Gq, and is used by the SPDF to request access network resources to carry a particular service requested by the subscriber. It differs from Gq chiefly in that no NAT or NAPT function is provided; the access network is not expected to translate IP addresses. As with Gq, this reference point uses Diameter as its transport.

3.3.5 PDF/BGF (Ia)

Release 7 expands the role of the Go reference point to enable direct control of the BGF to program NAPT and NAT traversal function and open pinholes in the gateway. The new Ia reference point is being defined for this purpose, and is based on H.248.

Copyright Metaswitch Networks. Confidential | Page 23

4. IMS SBC Products

The earlier chapters describe how session border control fits onto the functions defined by IMS. This chapter considers how this function is likely to be packaged into products and how these products will evolve from existing devices. There are three different types of interface requiring control: UNI, NNI to peer IMS carriers and NNI to non-IMS carriers. Although a single device could be used for all applications, it is likely that separate products will be developed to target the functionality and scale of each application.

4.1 Scope of function

Most current SBC products are implemented as a single stand-alone device that is placed in front of existing equipment in the path of all the signaling and media traffic on an interface. This one box includes the media (BGF/I-BGF) and signaling processing (IBCF/P-CSCF) as well as the media resource control (SPDF/RACS).
SIP Signaling Media Other

P-CSCF

RACS / PDF External Signaling External Media BGF / PDG / GGSN / BAS Internal Signaling Internal Media

Access Network

SBC

Core Network

Althou

gh in some small-scale applications, it makes sense to include all these functions in a single device, this solution does not scale well to the requirements of service providers. For these applications, the media, signaling and CAC processing will often be split into separate devices, with the signaling processing clustered into regional server farms, the CAC processing centralized (and possibly supplied wholesale by a third party supplier) and the media processing distributed closer to the user. This provides economies of scale on the signaling processing and increases network manageability, whilst maintaining direct media routing to minimize network transit delays. The following sections discuss options for multi-device SBC solutions in IMS.

Copyright Metaswitch Networks. Confidential | Page 24

4.1.1 Access Network Specialized UNI Device

This type of device has specialized hardware and software allowing one or more types of access network to be connected directly to the IP core network through the UNI SBC. They encapsulate both the SPDF and A-RACF policy processing. They are implemented either as monolithic devices, or as distributed devices, one of which handles signalling (SBC-SIG) and the other media (SBC-MEDIA). Both models are illustrated in the diagram below.

SBC
P-CSCF Gq' RACS A-RACF Re RCEF SPDF Ia A-BGF

I-CSCF / S-CSCF

Internal Signaling

Internal Media

SBC-SIG
P-CSCF Gq' RACS A-RACF SPDF

SIP Signaling Diameter H.248 Media Unspecified

Re / Ia

SBC-MEDIA
RCEF A-BGF

Copyright Metaswitch Networks. Confidential | Page 25

4.1.2 Access Network Independent UNI Device Incorporating SPDF

This type of device is independent of particular access methods, and so is suitable for scenarios where connectivity may be over a variety of access networks. For example, this is applicable where a provider owns an all-IP core, and has agreements with regional network owners to provide access to subscribers over cable, DSL, Wi-Fi, and so on. This device implements its own CAC policies and so does not require the services of an external SPDF. However, because it interoperates with separate access networks, it requires the services of one or more A-RACFs to provide CAC decisions and reserve resources in those networks. Therefore, it exports the Rq policy interface. As in section 4.1.1, this SBC may be implemented either as a monolithic device, or as a distributed device, one of which handles signalling and the other media. This is illustrated in the following diagram.

SBC
P-CSCF Gq' RACS A-RACF Rq SPDF Ia A-BGF

I-CSCF/ S-CSCF

Internal Signaling

Internal Media

SIP Signaling Diameter H.248 Media

SBC-SIG
P-CSCF Gq' RACS A-RACF Rq SPDF

Ia

SBC-MEDIA
A-BGF

Copyright Metaswitch Networks. Confidential | Page 26

4.1.3 Access Network Independent UNI Device Excluding Policy

As in section 4.1.2 above, this type of device is independent of particular access methods, and fits the same types of access scenarios as described there. However, in addition this device exports all CAC policy decisions to an off-board SPDF. This type of device may be more suited to very small or very large provider networks. This device is likely to be a simpler version of that presented in section 4.1.2, hence a small network may find it more cost efficient to buy one of these devices and lease services from an SPDF in a separate network. A large provider network will benefit from reduced management costs if CAC policy configuration is centralized on a separate SPDF device. In general, such networks will have a small number of SPDFs and a larger number of SBCs. Since this device requires the services of a third-party SPDF, it exports the Gq interface. As in section 4.1.1, this SBC may be implemented either as a monolithic device, or as a distributed device, one of which handles signalling and the other media. This is illustrated in the following diagram.

SBC-SIG
P-CSCF

I-CSCF / S-CSCF

Internal Signaling

Internal Media

Gq'

RACS A-RACF Rq SPDF

SIP Signaling Diameter H.248 Media

Ia

SBC-MEDIA
A-BGF

Unspecified

SBC
P-CSCF Gq' RACS A-RACF Rq SPDF Ia A-BGF

Copyright Metaswitch Networks. Confidential | Page 27

4.1.4 NNI Device Incorporating SPDF

This device could either be specialized to be deployed in an NNI scenario, or equivalent to the device described in section 4.1.2. This would be a general-purpose SBC capable of being deployed on the UNI or NNI. In some network scenarios, such a device could play both roles.

Internal Signaling

SBC
IBCF Gq' RACS SPDF Ia SIP Signaling Diameter H.248 Media Peer

Internal Media I-BGF

SBC-SIG
Internal Signaling IBCF Gq' RACS SPDF

Ia

SBC-MEDIA
Internal Media I-BGF

Copyright Metaswitch Networks. Confidential | Page 28

4.1.5 NNI Device Excluding Policy

This device is equivalent to that described in section 4.1.4, with the exception that it uses the services of an off-board SPDF to perform admission control functions. It therefore is required to support the Gq reference point, where the device in section 4.1.4 is not.

Internal Signaling

SBC
IBCF Gq' Peer

RACS SPDF Ia SIP Signaling Internal Media I-BGF Diameter H.248 Media

SBC-SIG
Internal Signaling IBCF Gq' RACS SPDF Ia

SBC-MEDIA
Internal Media I-BGF

4.2 Management and Control

One of the most challenging aspects of the number of different functions defined by the IMS architecture is managing the resulting proliferation of devices. User configuration is centralized in the HSS, but operator policy is implemented across many separate devices (P-CSCF, I-CSCF, S-CSCF, SPDF, and others). There is currently no standardized way to control these devices, but an SNMPbased solution is likely to be the most effective way to centrally configure and monitor the system.

4.3 Product Evolution

The requirements of 3GPP Release 7 are bringing together three sets of products, each currently lacking the complete set of function: Products targeted at earlier IMS releases. These generally lack NAPT and NAT/firewall traversal function, and do not have sufficient call access control to prevent the wide range of DoS attacks that broadband devices can generate.

Copyright Metaswitch Networks. Confidential | Page 29

SBCs targeted at the broadband access market. These may not be designed to fit the IMS architecture and generally do not support the IMS reference points and 3GPP-specific protocol extensions.

IP and multi-service routers that have traditionally targeted the IP carrier interconnect and carrier edge markets. These products excel at high-performance routing, but need to add both the SBC function and IMS interfaces.

The short-term effect is that very different products are being promoted as fulfilling this same requirement, and the still-evolving standards are being pushed by each manufacturer to conform as closely as possible to its existing product range. At the same time, there is huge pressure on the manufacturers to enhance their products to address the rapidly growing IMS SBC market. Depending on their situation, most are taking one of the following routes. Developing the function themselves, often incorporating much of the technology from independent suppliers such as Metaswitch to reduce cost and improve time to market. Partnering with complimentary suppliers. Purchasing companies with the relevant expertise and then trying to merge the product lines, (for example, Juniper/Kagoor, Tekelec/IPtel, NetCentrex/NeoTIP). Whichever method they choose, a rapidly expanding range of IMS-targeted devices incorporating SBC functionality will evolve to create an extremely competitive market. However, given the amount of investment by operators in their next generation networks, this will be extremely lucrative for those vendors that get it right.

Copyright Metaswitch Networks. Confidential | Page 30

5. The Future
Looking forward, there are two areas that we need to consider to predict the evolution and interaction of IMS and SBC products. Firstly, the future of IMS and its requirements for session border control. Secondly, the evolution of session border control function itself as VoIP technology matures.

The following sections look at each of these areas in more detail.

5.1 The Future of IMS

There is huge pressure on fixed-line operators to deploy a new architecture, and IMS offers the most attractive model available. However IMS has not yet been deployed outside trials, and the IMS standards continue to evolve to overcome flaws in the original design, as well as extensions to provide new functionality. As a result, it is likely that IMS in some form will be deployed, but that it will not be in the form currently envisaged in any of the defined releases. Instead, future networks will combine elements from each of the releases with new functionality to address new market opportunities. The following factors will have a significant influence on the direction of IMS, and will change nature and location of session border control within the IMS network and its derivatives.

5.1.1 Legislation
Government action to apply lawful intercept (wire tapping) and mandatory quality levels to telephony services may force all telephony service providers (including pure VoIP services) to deploy managed networks with border controls. However, unless governments make it illegal to communicate over P2P VoIP services (as they have in China), the effect of this sort of legislation will be to increase the cost of providing a traditional telephony service and increase the use of less regulated P2P solutions.

5.1.2 Consumer pressure

Consumers will judge the value of IMS on whether the service that it provides surpasses that of alternatives. If it does, then the operator will be able to charge a premium for IMS services and reap the benefit from its investment in the IMS infrastructure. However, IMS-based operators will be at a cost disadvantage compared with operators that offer a pure IP connection without the expense and complexity of an IMS infrastructure, so they will not be able to compete on price on basic services.

Copyright Metaswitch Networks. Confidential | Page 31

Many factors influence consumers choices, but important areas include reliability trust, including solutions to SPAM Telephony (SPIT) and SPAM Messaging (SPIM) convenience and simplicity cost.

The IMS architecture as it is currently designed is focused on an operator knows best model. The success IMS and its evolution will depend on whether consumers agree with operators choices or require a different set of features and restrictions.

5.1.3 Competitive pressure

The competitive landscape will be the primary driver for the introduction and success of IMS. If all the major carriers pursue the IMS model to prevent their service becoming a commodity, then there will be limited competition and pressure to encourage them to try more radical business model. However, this scenario is unlikely for number of reasons. One or more carriers will choose to offer an open IP network link at low cost. There are already examples of unlimited IP price plans from both fixed and mobile operators. If an uncompetitive market develops, anti-trust legislation will force operators to open up their networks to competitive carriers, who can provide a pure-IP service at marginal cost. The spread of alternative network providers (such as WiFi hotspots and urban WiFi networks) is increasing competition in the access network. Internet telephony is being promoted by well-known companies with deep pockets, including Ebay/Skype, Google and Microsoft.

5.2 SBC Function Evolution

The power of the Internet is the transparency of the network and the ability for services to evolve without the need to upgrade the network core. Many session border control functions break this transparency by requiring the SBC in the core to understand the media signaling. This both increases the cost of running the network and reduces the speed at which services can evolve, but provides additional security for the users. Hopefully, some of the more intrusive SBC roles will diminish over time with the spread of IPv6 and VoIP friendly NATs, but others will remain to control and monitor access to the operators network. The following sections discuss the likely evolution of each area.

Copyright Metaswitch Networks. Confidential | Page 32

5.2.1 Security
SBCs cannot support end-to-end security, as they need to be able to understand and modify the signaling messages. If users require higher security then they will use an encrypted P2P service across an open IP network instead. The primary driver for such end-to-end security is likely to be illegal avoiding surveillance by the intelligence services but it may also be used to prevent unauthorized surveillance, for example by an intermediate carrier or competitor. The security model provided by IMS will not change it will remain point-to-point. Users who require end-to-end security will use an alternative service, or encrypt the media to provide sufficient security for their requirements.

5.2.2 NAT and firewall traversal

Within the SOHO environment, the use of symmetric NATs 1 is likely to decrease, so the support of STUN and other NAT traversal techniques by endpoints will enable the NAT traversal technology in SBCs to be retired for many users. The use of STUN enables SIP to be used through all types of NAT except symmetric NATs. However, in enterprise environments, SBCs will increasingly be installed at the edge of the corporate network to protect it from attack. Corporate rules will enable NAT and firewall traversal according to corporate policy this may limit the roll-out and availability of IMS services from within a corporate LAN. This is identical to the situation today with access to other Internet services, e.g. email and web browsing, from within a corporate LAN, and should not be subverted by the carriers.

5.2.3 IPv4 and NATs

The IMS network, particularly when IPv4 and VPN issues are included, is not an open transparent network, so SBC function is required to enable multimedia services to work. End-point NAT traversal technologies such as STUN remove the need for traversal devices at the UNI, but do not provide an end-to-end solution for media traffic that needs to traverse multiple private address spaces. The use of IPv6 or a single global IPv4 address space throughout the network core would enable media to be routed directly between endpoints without the need for SBC function on the NNI. In addition to reducing the processing required, this would also ensure that the media takes the most direct route to its destination. However, the current generation of core networks is based on IPv4 and many early IMS deployment will run over these networks. It will be a number of years before NATs on the NNI can be removed.
1

Symmetric NATs set up separate mappings between the private IP address and port, and the public IP address and port, for each remote address. As a result, an endpoint cannot use STUN to determine a public address that a third-party can use to route media to it through a symmetric NAT. Instead, a media relay must be used.

Copyright Metaswitch Networks. Confidential | Page 33

5.2.4 QoS
QoS across core networks is already extremely good, and the Internet has been shown to be capable of handling serious disruptions to its infrastructure without significant effect on its performance. However, QoS in access networks remains a challenge. Bandwidth availability within access networks will continue to increase, but new services will evolve to use any extra capacity, so QoS mechanisms within access networks will continue to be required. The design of these mechanisms will depend on the specific access medium: in some cases an SBC will be required to enforce the rules at the network boundary, but in others it will be possible to negotiate access end-to-end. It is certain is that differential handling of different classes of traffic over the access network will increase, however it is not clear that this will require session border control at the core network end of the link to enforce policy. A more flexible solution would be to allow the endpoint to determine the class of service to be applied to each stream using an out-of-band mechanism.

Copyright Metaswitch Networks. Confidential | Page 34

6. Conclusion
Session border control is fundamental to the IMS proposition to both operators and consumers. The exact function required will evolve as the underlying infrastructure and customers demands change, but SBCs will always be part of any IMS solution. There is short-term pressure for manufacturers to enhance their existing SBC and IMS products to enable them to be used as part of a 3GPP Release 7 solution. This will be a competitive area with products being developed by many manufacturers, but is also an area that requires an unusually wide breadth of expertise, so will challenge the expertise of many contenders. Longer term, the evolution of session border control in IMS networks will depend on the ability of IMS-based networks to compete with lower-cost solutions available over the Internet, and of operators to charge enough for the QoS and security that they offer. With or without IMS, SBCs will continue to provide protection at the boundaries between managed networks. The evolution of the next generation of Telco networks will just determine where and how transparent those boundaries are.

Copyright Metaswitch Networks. Confidential | Page 35

7. Further Information
7.1 Sources
GSM Association IETF SIP Forum 3rd Generation Partnership Project SIP Working Group SIPPING Working Group ETSI TISPAN 3GPP2 http://www.gsmworld.com http://www.ietf.org http://www.sipforum.org http://www.3gpp.org http://www.softarmor.com/sipwg http://www.softarmor.com/sipping http://portal.etsi.org/tispan http://www.3gpp2.org

7.2 Reference material

7.2.1.1 IP Multimedia Subsystem (IMS)
3rd Generation Partnership Project GSM Association TS 23.228 v7.0.0 IR.65 Technical Specification Group Services and System Aspects: IP Multimedia Subsystem (IMS); Stage 2 (Release 7) IMS Roaming and Interworking Guidelines

7.2.1.2 SBC
Metaswitch white paper Session Border Controllers: Enabling the VoIP Revolution

7.2.1.3 SIP
Metaswitch white paper IETF RFC Session Initiation Protocol (SIP) SIP Market Overview

Copyright Metaswitch Networks. Confidential | Page 36

3261 IETF RFC 3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)

7.3 Glossary of Acronyms

3GPP ALG A-RACF BAS BCF BGCF BGF CSCF COPS DoS GGSN IBCF I-BGF I-CSCF IMS NAPT NASS NAT NNI P-CSCF P2P PDF PDG PLMN PoC QoS RACS RAN Third Generation Partnership Program Application Level Gateway Access Resource and Admission Control Function Broadband Access Server Border Control Function Breakout Gateway Control Function Border Gateway Function Call Session Control Function Common Open Policy Service Denial of Service Gateway GPRS Support Node Interconnect Border Control Function Interconnect Border Gateway Function Interrogating CSCF IP Multimedia Subsystem Network Address and Port Translation Network Attach Subsystem Network Address Translation Network-Network Interface Proxy CSCF Peer-to-Peer Policy Decision Function Packet Data Gateway Public Land Mobile Network Push-to-Talk over Cellular Quality of Service Resource and Access Control Subsystem Radio Access Network

Copyright Metaswitch Networks. Confidential | Page 37

S-CSCF SBC SGSN SIP SLA SOHO SPDF STUN THIG TrGW UE UNI VLAN VPN WAG WLAN

Serving CSCF Session Border Controller Serving GPRS Support Node Session Initiation Protocol Service Level Agreement Small Office Home Office Service-based Policy Decision Function Simple Traversal of UDP through NATs Topology Hiding Inter-network Gateway Transition Gateway User Equipment User-Network Interface Virtual Local Area Network Virtual Private Network Wireless Access Gateway Wireless Local Area Network

Copyright Metaswitch Networks. Confidential | Page 38

8. About Metaswitch
Metaswitch is a privately owned technology company based in London, UK. We have US offices in Alameda, CA, Reston, VA, and Boxborough, MA. Our Network Protocols Division is the leading developer and supplier of (G)MPLS, OSPF(-TE), ISIS(-TE), BGP, VPN, RIP, PIM, IGMP, MLD, ATM, MGCP, Megaco, SCTP, SIP, VoIP Conferencing, Messaging, Directory and SNA portable products. Customers include Alcatel, Cisco, Fujitsu, HewlettPackard, Hitachi, IBM Corp., Microsoft, Nortel and Sun. Our company culture focuses on building software of consistently high quality, developed and supported by engineers who are with Metaswitch for the long term. Founded in 1981, we have over 450 employees, of whom 280 are engineers. The average length of service of engineers at Metaswitch is 8 years, and the annual attrition rate is 3%. Throughout this period, Metaswitch has been consistently profitable with profits exceeding 15% of revenue. 2007-2008 revenues were $118m with $22m profit. Over 90% of revenue is generated from exports and 80% is from customers in the US (so we are very used to working with American companies). The company is privately held by top-tier investment firms Francisco Partners and Sequoia Capital, as well as the Employee Benefit Trust (EBT). As part of this ownership structure, Metaswitch distributes a share of profit to all employees, equitably rewarding them for their contribution and encouraging long-term commitment. As a private company with an emphasis on long-term stability, we are not driven by the short-term requirements of quarterly profit statements. This means that we can concentrate on providing software as we would like that is, developing high quality implementations of complex technologies. Drawing from technology and experience from multiple divisions of Metaswitch the Network Protocols division has developed a fully portable Session Border Controller (DC-SBC) software solution designed specifically for system vendors. Metaswitchs extensive VoIP and IP routing heritage provides OEMs with a field-hardened SBC solution that is deployable immediately, delivering dramatic cost and time to market savings. Along with traditional session border controller functionality, DC-SBC also supports many of the vital functions required in IMS networks including P-CSCF, IBCF, SPDF, and BGF/I-BGF roles. Furthermore, Metaswitch offers a full range of VoIP and IMS protocols stacks (DC-SIP, DC-Megaco/H.248 and

Copyright Metaswitch Networks. Confidential | Page 39

DC-Diameter) that support the required interfaces and enhancements to fully operate in standardsbased IMS environments. All of the Metaswitch protocol implementations are built with scalability, distribution across multiple processors and fault tolerance architected in from the beginning. We have developed extremely consistent development processes that result in on-time delivery of highly robust and efficient software. This is backed up by an exceptionally responsive and expert support service, staffed by engineers with direct experience in developing the protocol solutions. Metaswitch and the Metaswitch logo are trademarks of Metaswitch Networks. All other trademarks and registered trademarks are the property of their respective owners. Copyright 2007 - 2009 by Metaswitch Networks. Metaswitch Networks 100 Church Street Enfield EN2 6BQ England +44 20 8366 1177 http://www.metaswitch.com

Copyright Metaswitch Networks. Confidential | Page 40