BW SystemEngineeringGuide

BroadWorks System Engineering Guide
Document Version 37
9737 Washingtonian Boulevard, Suite 350

Gaithersburg, MD 20878
Tel +1 301.977.9440
WWW.BROADSOFT.COM
BroadSoft Guide
Copyright Notice
Copyright 2015 BroadSoft, Inc.
All rights reserved.
Any technical documentation that is made available by BroadSoft, Inc. is proprietary and
confidential and is considered the copyrighted work of BroadSoft, Inc.
This publication is for distribution under BroadSoft non-disclosure agreement only. No
part of this publication may be duplicated without the express written permission of
BroadSoft, Inc., 9737 Washingtonian Boulevard, Suite 350, Gaithersburg, MD 20878.
BroadSoft reserves the right to make changes without prior notice.
Trademarks
Any product names mentioned in this document may be trademarks or registered
trademarks of BroadSoft or their respective companies and are hereby acknowledged.
This document is printed in the United States of America.
BROADWORKS SYSTEM ENGINEERING GUIDE
2015 BROADSOFT, INC.
01-BD5003-00
PAGE 2 OF 95
Document Revision History

Version
Reason for Change
Date
Author
Updated document for rebranding.
March 2, 2006
Roberta Boyle
Changed name of document from System Guide to

System Engineering Guide for Release 14.
June 2, 2006
Patricia Renaud
Added Release 14 updates.
July 7, 2006
Laura Griffith
Edited document.
August 20, 2006
Patricia Renaud
Added information for fax weightings and

guidelines on the maximum number of DNs.
November 22, 2006
Laura Griffith
Edited document.
December 11, 2006
Patricia Renaud
Made document improvements for System

Monitoring project.
February 1, 2007
Laura Griffith
Edited changes.
March 5, 2007
Patricia Renaud
Made minor changes to call weightings and added

an explanation of business trunking.
March 26, 2007
Laura Griffith
Added section 6.2.1 IPSec Tunnels for EV 46217.
March 29, 2007
Roberta Boyle
Edited changes.
April 3, 2007
Patricia Renaud
Updated system architecture section and added

reference to the Network Server Memory Estimator
tool.
April 30, 2007
Mark Kushnir
Fixed example Network Server capacity

calculation. Added information on assumptions for
real-time accounting configuration. Clarified
10,000 Conferencing Server administrator limit.
April 25, 2007
Laura Griffith
Edited changes.
May 1, 2007
Patricia Renaud
Updated for replication bandwidth.
May 31, 2007
Mark Kushnir
Edited changes and published document.
June 21, 2007
Patricia Renaud
Added information on T2000 hardware.
July 17, 20007
Laura Griffith
July 25, 2007
Andrea Fitzwilliam
Clarified Application Server and Network Server

database sizing rules.
August 30, 2007
Mark Kushnir
Aligned capacity with the BroadWorks

Recommended Hardware Guide, fixed Web Server
example, and updated Application Server
residential cache computations.
October 4, 2007
Laura Griffith
October 12, 2007
Patricia Renaud
Added SNMP get/sec guidelines.
November 6, 2007
Mark Kushnir
Add information on BEA integration. Added

content on high performance IBM systems.
Removed section on base system capacities.
November 15, 2007
Laura Griffith
Added information on unified message storage

engineering rules.
December 5, 2007
Mark Kushnir
December 7, 2007
Andrea Fitzwilliam
Mark Kushnir
01-BD5003-00
PAGE 3 OF 95
Version
Reason for Change
Date
Author
10
Removed restriction on number of enterprises for

Release 14.sp4. Added additional service
weightings to table in Appendix B: Call Weighting.
February 14, 2008
Laura Griffith
10
February 18, 2008
Andrea Fitzwilliam
11
Revised document for EV 58416.
February 25, 2008
Laura Griffith
Added statement indicating that information applies

to earlier releases unless otherwise noted.
Updated enterprise database size per user to 40
KB to match Capacity Planner.
Added Xtended Services Platform.
Updated call weightings for voice mail deposit.
11
April 14, 2008
Andrea Fitzwilliam
12
Updated Application Server Growth Estimate

procedure to used licensing number of users
instead of the SNMP number.
April 23, 2008
Mark Kushnir
12
Changed maximum number of Conferencing

Servers in a cluster.
April 29, 2008
Francois Brassard
12
April 30, 2008
Andrea Fitzwilliam
13
Added Device Management/Profile Server impacts.

Added performance guidelines for new Sun and
IBM systems to section 9 Server Performance
Guidelines.
June 9, 2008
Laura Griffith
13
June 18, 2008
Andrea Fitzwilliam
14
Removed BroadWorks release references.
July 8, 2008
Laura Griffith
Added numbers for large Media Servers.

14
July 21, 2008
Andrea Fitzwilliam
15
Deleted BEA section and added Sun x64 series.
October 20, 2008
Mark Kushnir
15
October 20, 2008
Andrea Fitzwilliam
16
Fixed error in trunk group user estimate.
November 1, 2008
Mark Kushnir
16
Changed Network Server DB PERM sizing to

maximum 48% of available memory.
December 1, 2008
Mark Kushnir
16
Updated description of overload controls.
December 8, 2008
Mark Kushnir
16
Described Capacity Planner changes to support

input of multiple packaged configurations.
March 24, 2009
Laura Griffith
Removed references to the Network Server

Memory Estimator since this has been
incorporated into the Capacity Planner.
Updated Java heap utilization examples.
16
Added Media Server jitter indicators.
April 10, 2009
Steve Liao
16
April 21, 2009
Andrea Fitzwilliam
17
Updated section 7.1.3 Generic Port Calculation

Rules for EV 89418.
May 15, 2009
Goska Auerbach
17
Cleaned up database temp size calculation and

removed Thread Activity as a platform KPI.
June 1, 2009
Mark Kushnir
01-BD5003-00
PAGE 4 OF 95
Version
Reason for Change
Date
Author
17
June 3, 2009
Andrea Fitzwilliam
18
Updated replication bandwidth requirements

according to EV 90986.
June 22, 2009
Mark Kushnir
18
June 25, 2009
Andrea Fitzwilliam
19
Added section to explain how to use the System

Capacity Planner to input live data.
August 21, 2009
Laura Griffith
Updated growth estimate to clarify that busy CPU

should only include system and user activity.
Added UC-Connect specifications.
19
August 28, 2009
Andrea Fitzwilliam
20
Described enhancements to System Capacity

Planner Live Data Input mode.
October 20, 2009
Laura Griffith
Described impact of SOAP transactions on the

Web Server, according to EV 98133.
Added provisioning guidance for Communication
Barring Fixed feature.
20
Reworked Hardware Capacities section to be CPU

Unit-driven and increased Network Server memory
maximum to 48 GB and Application Server
memory maximum to 64 GB.
December 2, 2009
Mark Kushnir
20
December 8, 2009
Andrea Fitzwilliam
21
Made small correction, changing CPUs to CPU

Units and published document.
December 18, 2009
Andrea Fitzwilliam
22
Updated section 4.1.3 Scaling Characteristics for

EV 106924.
February 17, 2010
Goska Auerbach
22
Updated section 8 Server Provisioning Guidelines.
February 18, 2010
Laura Griffith
22
Updated Media Server engineering rules in section

7.1 Media Server Engineering Rules.
February 24, 2010
Mark Kushnir
22
March 17, 2010
Patricia Renaud
23
Synchronized document with System Capacity

Planner version 3.3. Added formulas for Videoenabled Media Server. Renamed Web Server.
March 29, 2010
Laura Griffith
24
April 19, 2010
Andrea Fitzwilliam
25
Removed reference to 5,000-user limit in the

Application Server scaling constraints section and
cleaned up OCP/ODP provisioning guidelines.
May 19, 2010
Mark Kushnir
25
Updated call weightings for call center calls.
May 19, 2010
Laura Griffith
25
May 28, 2010
Andrea Fitzwilliam
26
Fixed errors in growth estimate for EV 114031.
June 29, 2010
Mark Kushnir
26
July 26, 2010
Andrea Fitzwilliam
27
Renamed Number of Simultaneous Ringing

Personal entries to Number of Simultaneous
Ringing Personal criteria entries in section 8.1
Application Server Provisioning Guidelines for
EV 108732.
November 10, 2010
Goska Auerbach
01-BD5003-00
PAGE 5 OF 95
Version
Reason for Change
Date
Author
27
Updated company address and references to

Xchange.
February 9, 2011
Goska Auerbach
27
Added DBS dimensioning information.
April 19, 2011
Mark Kushnir
27
May 3, 2011
Andrea Fitzwilliam
28
Updated provisioning guidelines for EV 140694.

Fixed simultaneous call calculation.
May 6, 2011
Laura Griffith
28
Added CTI-Connect Xtended Services Platform

(Xsp) deployment model.
May 23, 2011
Mark Kushnir
28
Fixed GC heap collection example error in section

10.1.1.1 Execution Server Post Full Collection
Heap Size for EV 143495.
June 9, 2011
Mark Kushnir
28
June 22, 2011
Andrea Fitzwilliam
29
Updated Media Server port weightings. Added

OCI over SOAP rating.
December 12, 2011
Laura Griffith
29
January 3, 2012
Andrea Fitzwilliam
30
Changed Growth Estimate procedure to identify

number of users on an Application Server.
April 30, 2012
Mark Kushnir
30
Corrected Access Mediation Server (AMS)

example calculation.
July 28, 2012
Laura Griffith
Added section to document restriction on

compressed codec usage for conferencing on
UltraSPARC Media Server for EV 154886.
Removed Conferencing Server.
Added Service Control Function (SCF) server.
30
August 10, 2012
Andrea Fitzwilliam
31
Corrected formula for number of simultaneous

connections per Xtended Services Platform in
section 4.6 Xtended Services Platform.
October 1, 2012
Laura Griffith
Added guidance on number of agents per route

point in section 8.1 Application Server Provisioning
Guidelines.
Updated section 7.4.1 Message Storage
Requirements for mailbox size calculations for
EV 140398.
31
October 12, 2012
Patricia Renaud
32
Added section 7.5 Service Control Function

Network Requirements.
December 10, 2012
Mark Kushnir
32
December 11, 2012
Patricia Renaud
01-BD5003-00
PAGE 6 OF 95
Version
33
Reason for Change
Date
Author
Added information on the Virtualized System

Capacity Planner worksheet.
December 10, 2013
Laura Griffith
Added Business Communicator Xsp information.

Added details on Device Management system
engineering.
Removed CDS information.
Added information on provisioning guidelines for
Communication Baring (Hierarchical) feature.
Increased supported group size.
Added information on Session Access Control.
Added EVRC-A codec and described maximum
generic and maximum RTP port requirements.
Added video conferencing.
Updated performance guidelines to support
additional CPU configurations.
33
January 6, 2014
Joan Renaud
34
Added Messaging Server (UMS), Sharing Server

(USS), and WebRTC Server (WRS).
April 11, 2014
Laura Griffith
Updated Media Server calculations to match

capacity planner.
Added AMR-WB.
Added guidelines for disposition/unavailable codes
for EV 191987.
Updated voice mail storage requirements for
EV 213785.
34
Edited changes and republished document.
April 14, 2014
Andrea Fitzwilliam
35
Added clarification to description of Media Server

port weightings.
June 6, 2014
Laura Griffith
Added information for XS mode.

35
Edited changes and republished document.
June 27, 2014
Andrea Fitzwilliam
36
Added Network Function Manager (NFM).
December 17, 2014
Laura Griffith
Removed references to the Solaris operating

system and UltraSPARC hardware.
Updated Network Server database size constraints
for EV 235455.
Added EVRC-NW codec weightings.
36
December 18, 2014
Patricia Renaud
37
Added rebranded server icons.
March 30, 2015
Joan Renaud
37
Added Video Server. Removed references to

hardware vendors.
April 3, 2015
Laura Griffith
37
April 10, 2015
Joan Renaud
01-BD5003-00
PAGE 7 OF 95
Table of Contents
1
Introduction ................................................................................................................................. 13
Definitions .................................................................................................................................... 14
2.1
Average Call Hold Time ............................................................................................................ 14
2.2
Erlang ......................................................................................................................................... 14
2.3
Busy Hour Call Attempts/Calls per Second ............................................................................. 14
2.4
Simultaneous Calls .................................................................................................................... 14
2.5
Call Model .................................................................................................................................. 15
2.6
Call Weighting ............................................................................................................................ 15
Server Capacity Disclaimer ...................................................................................................... 16
System Architecture and Scalability ....................................................................................... 17
4.1
4.2
Network Server .......................................................................................................................... 17

4.1.1
Centralized Location Repository ...................................................................................... 18
4.1.2
Centralized Routing Engine ............................................................................................. 19
4.1.3
Scaling Characteristics ..................................................................................................... 19
4.1.4
Scaling Constraints ........................................................................................................... 20
Application Server...................................................................................................................... 22
4.2.1
Scaling Characteristics ..................................................................................................... 22
4.2.2
Scaling Constraints ........................................................................................................... 23
4.3
Execution Server (XS Mode) .................................................................................................... 24
4.4
Media Server.............................................................................................................................. 24
4.5
Element Management System ................................................................................................. 25
4.6
Xtended Services Platform ....................................................................................................... 25
4.7
4.6.1
Xtended Services Platform Web Container Dimensioning ............................................ 25
4.6.2
Xtended Services Platform Transaction Ratings ............................................................ 26
4.6.3
Xtended Services Platform Deployment Configurations ................................................ 26
BroadWorks Device Management Profile Server .................................................................... 29

4.7.1
4.8
4.9
Profile Server Deployment Configurations ...................................................................... 29
Database Server........................................................................................................................ 30
4.8.1
Database Server Dimensioning ....................................................................................... 31
4.8.2
Database Server Disk Requirement................................................................................ 31
Access Mediation Server .......................................................................................................... 32
4.10 Service Control Function ........................................................................................................... 32

4.11 Messaging Server...................................................................................................................... 32
4.12 Sharing Server ........................................................................................................................... 32
4.13 WebRTC Server ........................................................................................................................ 32
4.14 Network Function Manager....................................................................................................... 33
4.15 Video Server .............................................................................................................................. 33
5
Hardware Capacities .................................................................................................................. 34
01-BD5003-00
PAGE 8 OF 95
6
6.1
6.2
System Capacity Planning ........................................................................................................ 35

Using System Capacity Planner ............................................................................................... 35
6.1.1
Use Single-Packaged Configuration ............................................................................... 35
6.1.2
Use Multiple-Packaged Configurations ........................................................................... 36
6.1.3
Use Manual Configuration ............................................................................................... 37
6.1.4
Bare Metal/Virtualized Configurations ............................................................................. 37
6.1.5
Use Live Data Input .......................................................................................................... 38
Capacity Planning Details by Node .......................................................................................... 39

6.2.1
IPSec Tunnels .................................................................................................................. 39
6.2.2
Application Server............................................................................................................. 39
6.2.3
Network Server ................................................................................................................. 41
6.2.4
Media Server..................................................................................................................... 42
6.2.5
Xtended Services Platform General User Service and Call Control........................... 45
6.2.6
Xtended Services Platform Device Management........................................................ 46
6.2.7
Element Management System ........................................................................................ 46
6.2.8
Profile Server Device Management.............................................................................. 46
6.2.9
UC-Connect ...................................................................................................................... 47
6.2.10 Access Mediation Server ................................................................................................. 48

6.2.11 Service Control Function .................................................................................................. 48
7
7.1
System Engineering Rules ....................................................................................................... 49

Media Server Engineering Rules .............................................................................................. 49
7.1.1
Media Server Resources.................................................................................................. 49
7.1.2
Media Server Processor Allocation Rules ....................................................................... 49
7.1.3
Generic Port Calculation Rules ........................................................................................ 50
7.1.4
Audio Port Calculation Rules ........................................................................................... 51
7.1.5
Video Calculation Rules ................................................................................................... 52
7.1.6
Viewing Media Server Port Assignments ........................................................................ 53
7.1.7
Playout and Recording Memory Usage Rules................................................................ 53
7.2
Video Server Engineering Rules .............................................................................................. 54
7.3
Replication Bandwidth Requirements ...................................................................................... 55
7.4
7.5
8
7.3.1
Application Server Replication Bandwidth Requirements .............................................. 55
7.3.2
Network Server Replication Bandwidth Requirements .................................................. 56
BroadWorks Unified Messaging Storage Server Requirements ............................................ 57

7.4.1
Message Storage Requirements ..................................................................................... 57
7.4.2
Busy Hour Messaging Throughput .................................................................................. 58
Service Control Function Network Requirements.................................................................... 59

Server Provisioning Guidelines ............................................................................................... 61
8.1
Application Server Provisioning Guidelines ............................................................................. 61
8.2
Network Server Provisioning Guidelines .................................................................................. 63
9
9.1
Server Performance Guidelines ............................................................................................... 64

Key Resource Indicator Guidelines .......................................................................................... 64
01-BD5003-00
PAGE 9 OF 95
9.2
9.3
9.4
9.1.1
CPU Usage ....................................................................................................................... 64
9.1.2
Paging ............................................................................................................................... 65
9.1.3
Disk Activity ....................................................................................................................... 66
Application Server Key Performance Indicator Guidelines ..................................................... 67

9.2.1
Execution Server Heap Usage ........................................................................................ 67
9.2.2
Database Usage ............................................................................................................... 67
9.2.3
SIP/MGCP Messages per Second .................................................................................. 68
9.2.4
OCI Provisioning Transactions per Second .................................................................... 68
9.2.5
Call Processing Delays .................................................................................................... 69
Network Server Key Performance Indicator Guidelines .......................................................... 70

9.3.1
Execution Server Heap Usage ........................................................................................ 70
9.3.2
Database Usage ............................................................................................................... 71
9.3.3
SIP Messages per Second .............................................................................................. 71
9.3.4
Internal Queue Statistics .................................................................................................. 72
Media Server Key Performance Indicator Guidelines ............................................................. 72

9.4.1
9.5
Jitter ................................................................................................................................... 72
SNMP Agent Guidelines ........................................................................................................... 73
10 Application Server Growth Estimation Procedure ............................................................... 74

10.1 Growth Estimation Procedure ................................................................................................... 74
10.1.1 Collect Information ............................................................................................................ 75
10.1.2 Calculate Maximum Users per Resource Indicator ........................................................ 77
10.1.3 Analyze Data..................................................................................................................... 78
10.1.4 Revisit Growth Estimate ................................................................................................... 78
11 Device Management Growth Estimation Procedure ............................................................ 79
11.1 Collect Information from Xtended Services Platform and Profile Servers .............................. 79
11.1.1 Tomcat Full Collection Heap Size ................................................................................... 79
11.1.2 Worst Case Busy Hour CPU............................................................................................ 79
11.1.3 Number of Devices ........................................................................................................... 80
11.1.4 Number of Web Container Threads ................................................................................ 80
11.1.5 Apache Statistics .............................................................................................................. 80
11.1.6 IOPS (Profile Server only) ................................................................................................ 80
11.2 Calculate Maximum Devices per Resource Indicator (Xtended Services Platform) ............. 81
11.3 Analyze Data (Xtended Services Platform).............................................................................. 82
11.4 Calculate Maximum Devices per Resource Indicator (Profile Server) ................................... 82
11.5 Analyze Data (Profile Server) ................................................................................................... 82
12 Database Server Disk Estimation Tool ................................................................................... 83
13 XS Mode System Engineering.................................................................................................. 84
13.1 Subscriber Profile Sizing ........................................................................................................... 84
13.2 Execution Server Traffic Model................................................................................................. 84
13.2.1 Patterns ............................................................................................................................. 84
13.2.2 Example ............................................................................................................................ 85
01-BD5003-00
PAGE 10 OF 95
13.3 Profile Server Traffic Model....................................................................................................... 86

13.3.1 Patterns ............................................................................................................................. 86
13.3.2 Example ............................................................................................................................ 87
14 Appendix A: Server Overload Controls ................................................................................. 88
14.1 Application Server...................................................................................................................... 88
14.2 Network Server .......................................................................................................................... 89
14.2.1 Network Server Licensing ................................................................................................ 90
14.3 Media Server.............................................................................................................................. 90
14.4 Xtended Services Platform ....................................................................................................... 90
14.5 UC-Connect ............................................................................................................................... 90
15 Appendix B: Call Weighting..................................................................................................... 91
16 Appendix C: Call Model for Packaged Configurations ....................................................... 94
References .......................................................................................................................................... 95
01-BD5003-00
PAGE 11 OF 95
Table of Figures
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Typical System Architecture ...................................................................................................... 17

Network Server SIP Redirection ............................................................................................... 18
Network Server User Location Lookup..................................................................................... 19
Execution Server Sh Transaction Rate Example, Full Business User ................................... 85
Execution Server Sh Data Volume Example, Full Business User .......................................... 86
01-BD5003-00
PAGE 12 OF 95
Introduction
This document is intended as a guide to engineer a BroadWorks system. The scalability
aspects of the architecture are described along with details on how to plan for expected
system capacity. This information is intended to be used during system planning. This
document applies to all supported BroadWorks releases. Any release-specific information
is noted where applicable.
Information on monitoring system performance is also presented in this document. This is
a crucial part of the ongoing system planning. Current system performance is the most
accurate way to predict future system scalability.
01-BD5003-00
PAGE 13 OF 95
2
2.1
Definitions
Average Call Hold Time
Average call hold time (ACH) defines how long a call is connected (call duration), on
average.
2.2
Erlang
Call load is measured in Erlang units. Erlang units represent traffic intensity or load as
traffic volume per time unit. An Erlang can be defined as one telephone line carrying traffic
continuously for one hour.
For example, if a system receives 100 calls per hour with each call requiring three minutes
(0.05 hour) of service, then the traffic volume in an eight hour period is 100 * 0.05 * 8 = 40
Call Hours (Ch). One Erlang equals one Ch/hour, so the traffic load is 40/8 = 5E.
Peak or busy hour is the busiest one-hour (60 minutes) period of the day. This is typically
the load for which resources are calculated, since it represents the worst case scenario.
Average call hold time (ACH) defines how long a call is connected (call duration), on
average.
Following are metrics typically used in the industry:
2.3
Residential: 0.1 Erlang with three-minute average call hold times
Enterprise: 0.2 Erlang with three-minute average call hold times
Busy Hour Call Attempts/Calls per Second

Peak or busy hour is the busiest one-hour period of the day. This is typically the load for
which resources are calculated, since it represents the worst case scenario. The
number of calls during this hour represents the number of Busy Hour Call Attempts
(BHCA). Calls per second (CPS) are equal to the BHCA converted to seconds.
To calculate BHCA the following formula is used:
BHCA = # of subscribers * ([Erlang per subscriber * 60 minutes] /
call hold time per subscriber in minutes)
To calculate CPS, the following formula is used:
CPS = BHCA / 3600
For example, 1000 residential subscribers with an Erlang of 0.1 would have the BHCA
computed follows: BHCA = 1000 * ([0.1 * 60]/3) = 2000 BHCA.
2.4
Simultaneous Calls
The number of simultaneous calls can be computed from the number of subscribers and
the Erlang per subscriber as follows.
Number of simultaneous calls = Number of subscribers * Erlang per
subscriber
01-BD5003-00
PAGE 14 OF 95
For Business Trunking applications, the number of simultaneous calls is used for licensing
instead of the number of users. The number of simultaneous calls is equivalent to the
overall system trunk group call capacity. However, for capacity planning purposes, the
effective number of users must be estimated to determine the database size and expected
number of web and provisioning transactions. The effective number of users is
determined from the number of simultaneous calls and the Erlang per user.
Effective Number of Users = Number of simultaneous calls / Erlang per
user
2.5
Call Model
The call model defines the calling profile. Elements of the call model include:
2.6
Percentage of internal versus external calls Internal calls are defined as calls
between BroadWorks users within the same group.
Incoming external versus outgoing external calls An incoming external call is

defined as a call originating from another network element and terminating to a
BroadWorks user on the Application Server. An outgoing external call is a call
originating from a BroadWorks user and terminating to another network element.
Call disposition Answered, Not Answered, Busy, or Error.
Service distribution This is the expected penetration of the various BroadWorks

services, each of which has a varying effect on system capacity.
Call Weighting
Each service in the call model is assigned a call weighting to estimate the impacts. The
weighting is an impact relative to a basic call. A basic call is defined as a simple answered
call. The call weighting is based primarily on impacts to messaging throughput. For
example, the Simultaneous Ringing service results in an extra terminating call leg for each
provisioned number. If one number is configured, the effective call weight is 1.5.
Registrations are also weighed as a call. A registration with authentication is assumed to
have a call weighting of one-half an answered call.
Detailed call weightings are shown in Appendix B: Call Weighting.
01-BD5003-00
PAGE 15 OF 95
Server Capacity Disclaimer

The server capacities are shown in this document as an indication only as to the expected
performance of a standard system, using a typical system configuration and feature mix.
Variations in hardware platforms, operating system updates, selected customer feature
sets, and customer mix affect the maximum number of users actually supported by the
system.
BroadSoft makes every effort to provide useful data in the sections that follow, but the
information should be viewed as guidelines rather than absolute performance figures.
01-BD5003-00
PAGE 16 OF 95
System Architecture and Scalability

Figure 1 Typical System Architecture provides a view of a typical BroadWorks System
Architecture. The following sections briefly describe the architecture and associated
scalability aspects of each of the BroadWorks nodes.
Figure 1 Typical System Architecture
Another aspect of system scalability is ensuring that each server has appropriate overload
controls to protect the system. Appendix A: Server Overload Controls describes the
overload controls for each server.
4.1
Network Server
The Network Server cluster is the key element in BroadWorks system scaling. A Network
Server cluster is defined as a number of Network Servers using the same synchronized
data store. In general, a BroadWorks deployment has one Network Server cluster. The
Network Server cluster provides two main functions:
Centralized Location Repository
Centralized Routing Engine
It is possible to segregate the Network Server functionality such that different Application
Servers are homed on different Network Server clusters. In this case, each Network
Server cluster would be considered a different BroadWorks system and the general
scaling rules outlined in this document would apply to each system independently.
01-BD5003-00
PAGE 17 OF 95
4.1.1
Centralized Location Repository

The Network Server cluster knows where all Application Server login user IDs, directory
numbers (DNs), and Session Initiation Protocol (SIP) Uniform Resource Locators (URLs)
are hosted.
The Network Server acts as a SIP-based redirection server for ingress INVITEs returning
a SIP 302 Moved Temporarily response with an Application Server cluster as contact.
The Network Server knows where all device address of record (AOR)/line ports are hosted
(Release 14.sp2) and can act as SIP-based redirection server for ingress REGISTERs
returning a SIP 302 Moved Temporarily response with a serving Application Server cluster
as contact. Figure 2 Network Server SIP Redirection shows the Network Server SIP
redirection function.
Figure 2 Network Server SIP Redirection
The Network Server acts as a Hypertext Transfer Protocol (HTTP)-based user location
server for web and client login returning the users serving primary and secondary
Application Server. This location application programming interface (API) can be used by
a third-party portal. Figure 3 Network Server User Location Lookup shows the Network
Server user location function.
01-BD5003-00
PAGE 18 OF 95
Figure 3 Network Server User Location Lookup
4.1.2
Centralized Routing Engine

The Network Server provides policy-driven originator-based/terminator-based routing
capabilities that can be shared by all Application Server clusters. It provides:
Centralized advanced routing capabilities for all Application Servers clusters, for
example, Equal Access Support, Physical Location Routing, and so on.
SIP-based Media Server Selection for all Application Server clusters.
For more information on Network Server capabilities, see the BroadWorks Network Server
Product Description.
4.1.3
Scaling Characteristics
Network Servers are deployed in clusters. To increase capacity, additional servers are
added to the cluster.
Network Servers are deployed in an N+1 manner, in which the cluster is over-provisioned
with an additional server. This is done to provide redundancy. If a server should fail, there
would be enough capacity to accommodate busy hour traffic.
A maximum of twenty servers can be in a cluster. Nineteen servers are used for capacity
planning, with one additional redundant server.
On systems with a large volume of provisioning transactions, a dedicated Network Server
can be deployed as a provisioning-only server.
01-BD5003-00
PAGE 19 OF 95
The Network Server uses the Oracle TimesTen database, with a memory resident data
store. TimesTen replication is used to keep the data stores across the clusters in
synchronization.
Network Server transactions consist primarily of network-bound SIP redirection traffic,
Media Server Selection requests, and Web/Open Client Server (OCS) User Locator
requests. The Network Server can also be optionally configured to handle access-side
call and registration traffic.
There are a number of ways that network elements such as Application Servers, public
switched telephone network (PSTN) interconnects, and session border controls (SBCs)
can select Network Servers. Some common Network Server selection algorithms are as
follows.
4.1.4
Pre-defined Network Server route list with round-robin algorithm route selection
Segmentation of Network Server based on access originated traffic versus network

originated traffic
Segmentation of Network Server based on per node fixed Network Server list (for
example, Application Server cluster 1 uses Network Server 1/Network Server 2 while
Application Server cluster 2 uses Network Server 2/Network Server 3)
Scaling Constraints
The number of subscribers supported by a given Network Server cluster is constrained by
the following items:
TimesTen Database Size
Transactions per Second (TPS)
Execution Server Heap Size
The above constraints are directly related to platform resource usage, that is, Central
Processing Unit (CPU) and memory. The type of platform, number of servers required
and memory-per-server, is dictated by the system requirements. For example, to support
ten million subscribers, the requirement of the Network Server database might be 6 GB,
which would mean 12 GB minimum RAM for each server. Assuming a typical residential
deployment with two calls per user per hour, the cluster would need to support twenty
million calls per hour or 5,556 TPS. If the selected hardware was rated at 600 TPS, then
ten servers would be required, with the eleventh server available to handle load during a
node failure.
4.1.4.1
Database Size Constraints

The TimesTen database is replicated across all members of the cluster. The database
size is directly related to available system memory/RAM. BroadSoft performance
benchmarking has validated the Network Server with up to 48 GB of physical memory.
This corresponds to a maximum database size of 24 GB. The database allocated
permanent size can be changed at any time and should not be set to greater than 50% of
available physical memory (up to 48 GB for an Intel 5500-based server). Database
temporary size, unless otherwise indicated by BroadSoft, should be set to the script
default value associated with the selected permanent size.
The Network Server database footprint is driven by the following key elements:
Deployment model (enterprise/service provider/group mix)
Residential Model 1 group per user/household model
01-BD5003-00
PAGE 20 OF 95
Business/enterprise model Up to 5,000 users per group
Subscriber attributes
A subscribers Network Server profile is made up of a number of data attributes:
Directory number(s) (DNs)
Web/client login user ID
SIP URL aliases
Extension (if user does not have a DN)
Routing attributes:
Network elements (NEs)
Routing profiles, routing policies, route list entries
NPA-NXX Active Code List (NNACL) files, Local Calling Area (LCA) entries, Local
Number Portability (LNP) entries
The main driver to the database size as a system scales is the subscriber information. In
general, a subscriber has at least two attributes: a directory number and a web/client login
user ID.
4.1.4.2
Transactions per Second (TPS) Constraints

Each Network Server cluster member has a rate TPS guideline that is based on hardware
type. A Network Server transaction can be one of the following equally weighted types:
SIP INVITE redirection
SIP REGISTER redirection
User location lookup
A servers rated TPS is based on CPU resource usage and is derived from performance
validation testing data. TPS per-platform rating ranges from 300 to 4500 TPS. For
specific Network Server TPS ratings per hardware (HW) type, see section 5 Hardware
Capacities.
The total Network Server cluster TPS is the sum of TPSs across each individual cluster
memberone server (for redundancy). The Network Server cluster is currently rated at up
to 19 + 1 elements, which means that the maximum total system TPS is currently rated at
85,500 TPS (19 servers * 4500 TPS for a 24 CPU Unit Intel 5600 Xeon-based server).
The BroadWorks System Capacity Planner [2] identifies how many Network Server
elements of a certain hardware type are required to meet the estimated traffic model.
4.1.4.3
Execution Server Heap Size Constraints

The Execution Server (XS) is the process responsible for call processing. The memory
heap size used by the Execution Server process is directly related to available system
memory/RAM. BroadSoft performance benchmarking has validated the Network Server
with up to 48 GB of physical memory. This corresponds to an Execution Server heap size
of 7.2 GB (15% of available memory). The Network Server Execution Server heap size
footprint is driven by the following key elements.
Data caching
Routing information
01-BD5003-00
PAGE 21 OF 95
Transactions per second
SIP-based redirection and user location lookups
Each active session uses up heap space
Unlike the database size constraint, which is cluster-wide, the Execution Server heap is
server-specific. This means that different servers in the cluster can have heaps at
different sizes if they are not handling the same traffic loads. In general, the Network
Server Execution Server heap size is rarely the bottleneck for growth for the Network
Server cluster.
4.2
Application Server
The Application Server is the service delivery platform that provides the line-side soft
switch capabilities. A subscriber belongs to a specific Application Server cluster and as
such, the subscribers profile resides in the database that is unique to each cluster.
BroadWorks provides two different deployment models for its Telephony Application
Server (TAS) product targeted for IMS deployments: the Application Server (AS) TAS and
the Execution Server (XS) TAS. A system with an Application Server TAS is referred to as
AS mode. A system with an Execution Server TAS is referred to as XS mode.
This section describes AS mode. For information on XS mode, see section 4.3 Execution
Server (XS Mode).
4.2.1
Scaling Characteristics
The BroadWorks Application Server is deployed in a primary/secondary server cluster
scheme. Multiple Application Server clusters are deployed within the same Network
Server cluster to increase capacity. Each Application Server cluster is managed
independently of the other. The number of Application Server clusters per system is
limited by the capacity of the Network Server cluster. Adding additional Application Server
clusters drive additional requirements on other network components such as the Media
Server, Web Server, Network Server, Conferencing Server, and Call Detail Server.
The secondary server operates in a hot-standby mode, with all subscriber data kept
current on both servers of the cluster. Failure of the primary node causes rollover of user
control to the secondary server.
Subscriber data is stored in an Oracle TimesTen database that is memory resident. A
memory database provides for optimum performance and throughput. Replication of
subscriber data is accomplished using TimesTen replication.
Provisioning of service providers, enterprises, groups, users, and services is done via the
Open Client Interface-Provisioning (OCI-P). This provisioning traffic is generated via the
web interface, local command line interface (CLI), and by BroadWorks/third-party clients
(and proxied by the OCS).
The system can be (optionally) configured to allow for preferred provisioning on the
secondary server. This can more evenly distribute processing load during steady state
operation, but is not a mechanism to provide increased capacity, as a single server must
be able to service both call and provisioning load during software upgrades and failure
scenarios.
01-BD5003-00
PAGE 22 OF 95
4.2.2
Scaling Constraints
An Application Servers capacity is constrained by the following:
Processing Power:
Calls per second (CPS)
Open Client Interface (OCI) provisioning transactions per second (PTPS)
And
Memory:
Database size
Execution Server Heap Size
The BroadWorks System Capacity Planner [2] takes the previously listed constraints into
account when providing an estimate subscribers-per-Application Server cluster.
4.2.2.1
Execution Server Heap Size Constraints

The Execution Server (XS) is the process responsible for call processing. The memory
heap size used by the Execution Server process is directly related to available system
memory/RAM. BroadSoft performance benchmarking has validated the Application
Server with up to 64 GB of physical memory. This corresponds to an Execution Server
heap size of 16 GB (25% of available memory). The Application Server Execution Server
heap size footprint is driven by the following key elements.
Data caching
4.2.2.2
Group information and subscriber information
Transactions per second
Call processing and non-call processing traffic
Each active call uses up heap space
Calls per Second and Provisioning TPS Constraints

The Application Server is rated at a maximum number of calls per second (CPS) and
provisioning transaction (PTPS) rate. The quoted CPS rates are for basic answered calls
with a call weighting of one. The quoted PTPS rate assumes 100% get transactions.
A modify transaction is approximately five times more costly that a get, and an add or
delete is ten times more costly.
A servers rated CPS and PTPS are based on CPU resource usage and are derived from
performance validation testing data. For specific Application Server CPS/PTPS ratings
per hardware type, see section 5 Hardware Capacities.
NOTE: Provisioning using the Application Servers deprecated Operations Support System
(OSS) interface is approximately four times more resource-intensive than an OCI transaction.
01-BD5003-00
PAGE 23 OF 95
4.2.2.3
Database Size Constraints

The TimesTen database is replicated across the two Application Server cluster members.
The database size is directly related to available system memory/RAM. BroadSoft
performance benchmarking has validated the Application Server with up to 64 GB of
physical memory. The database allocated permanent size can be changed at any time
and should not be set to greater than 38% of available physical memory. This
corresponds to a maximum database size of 24 GB. Database temporary size, unless
otherwise indicated by BroadSoft, should be set to the script default value associated with
the selected permanent size.
The Application Server database footprint is driven by the following key elements:
Deployment model (enterprise/service provider/group mix)
Residential model One group per user/household model
Business/enterprise model Multiple users per group
Group profile
Subscriber profile
4.3
The number of group services assigned

The number of services assigned to each subscriber
Execution Server (XS Mode)

The Execution Server Telephony Application Server provides a different scalability model
than the Application Server Telephony Application Server. Execution Server Telephony
Application Server nodes are deployed in a farm configuration with N+1 redundancy. The
Execution Server Telephony Application Server provides call processing and service logic.
An individual node is dimensioned similar to the Application Server Telephony Application
Server with the following exceptions:
4.4
The Execution Server Telephony Application Server has no database; therefore, the
database usage is not part of the dimensioning. Subscriber profile information is
retrieved from the Home Subscriber Server (HSS) and/or Database Server (DBS).
The Execution Server Telephony Application Server heap is configured to consume

more of the system RAM. Its size is 66 percent of the system memory, with a
maximum of 32 GB.
Provisioning is handled by the Profile Server Provisioning Application.
Media Server
Media Servers are also deployed in clusters. To increase capacity, additional servers are
added to the cluster. There can be up to 2,000 Media Servers per Network Server cluster.
Each Media Server operates independently.
The Media Server is dimensioned in terms of ports. A port can provide interactive voice
response (IVR) or conferencing functions. Ports for different codecs, fax, and video are
weighted in proportion to the resources used relative to the G.711 codec.
A given systems Media Server port requirements are derived from the call model. The
number of users per Media Server port is estimated based on the average amount of time
each user requires a Media Server resource/port.
01-BD5003-00
PAGE 24 OF 95
A Media Server can be classified as a video transcoding/conferencing-enabled Media

Server. This type of Media Server has increased hardware requirements. Video
transcoding/conferencing-enabled Media Servers can be deployed alongside non-video
enabled Media Servers. Video transcoding/conferencing-enabled Media Servers are
divided into CPUs dedicated for video transcoding/conferencing and CPUs dedicated for
IVR and conferencing.
4.5
Element Management System

The Element Management System is dimensioned in terms of managed objects. A
managed object is defined as one managed BroadWorks or non-BroadWorks node. The
Element Management System is deployed in pairs, with one server acting as the primary
and the other as a hot standby in case of failure.
4.6
Xtended Services Platform

The Xtended Services Platform (Xsp) provides a generic container platform for running a
customer Demilitarized Zone (DMZ) application. The Xtended Services Platform comes
with a number of preinstalled applications that can be deployed and share the same
server resources. There are two types of applications:
Web applications: Hypertext Transfer Protocol/Hypertext Transfer Protocol Secure

Sockets (HTTP/HTTPS)-based applications that run in an Apache/Tomcat Web
Container. All web applications run in the same Web Container and share its
resources.
BroadWorks applications: Java or C++based applications providing some specific

function. Each BroadWorks application is independent and has its own resource and
dimensioning requirements.
Xtended Services Platforms are deployed in a cluster with any Xtended Services Platform
about to handle requests destined for any of the deployed applications. Generically, the
Xtended Services Platform uses the Network Server Location API to determine the
Application Server (AS) cluster that should be the recipient of a request.
There can be up to 1,000 Xtended Services Platform nodes per Network Server cluster.
4.6.1
Xtended Services Platform Web Container Dimensioning

Xtended Services Platform web applications all share the same Apache/Tomcat Web
Container. The general Web Container dimensioning rules are as follows:
Maximum number of simultaneous HTTP(s) connections is a factor of available

memory.
#_Simultaneous_Connections = Available_Memory/12 * 10,000
An Xtended Services Platform with 12 GB of RAM would support 10K simultaneous
connections.
Apache keep-alive time-out is set to 15 seconds with a maximum of 100 requests.
If a socket does not receive anything within 15 seconds, the connection is closed.
The client can only hold socket for 1500 seconds.
Tomcat session time-out is set to 5 minutes.

The client can reuse the same session-id cookie for five minutes even after the
original HTTP session ends.
01-BD5003-00
PAGE 25 OF 95
The BroadWorks Capacity Planner [2] uses the Web Container dimensioning information
previously mentioned when modeling Xtended Services Platform capacity based on a web
applications general footprint. For example, a BroadWorks Receptionist or Call Center
client would generate more requests and receive more updates within a given busy hour
than a general BroadWorks AssistantEnterprise client user. As such, overall, the Web
Container would be able to support more BroadWorks AssistantEnterprise clients than
BroadWorks Receptionist clients.
4.6.2
Xtended Services Platform Transaction Ratings

In general, the Xtended Services Platform takes requests for a variety of different
applications from the outside world and forwards them on to the appropriate BroadWorks
Server within the core. The Xtended Services Platforms workload is rated in unweighted
requests per second (RPS), which is a factor of the available CPU. For example, a 6 CPU
Unit Xtended Services Platform would be rated at 750 unweighted RPS; while a 12 CPU
Unit Xtended Services Platform would be rated at 2000 RPS. Each request processed by
the Xtended Services Platform, regardless of the application or underlying protocol, has an
RPS weighting. For example:
Network Server Location API lookup weight: 1 RPS
OCI CAP or OCI-P request weight: 1 RPS
Xtended Services Interface action or event weight: 1 RPS
OCI over SOAP request weight: 3 RPS
The BroadWorks System Capacity Planner [2] uses a transaction weighting model and an
applications traffic footprint when modeling Xtended Services Platform capacity.
4.6.3
Xtended Services Platform Deployment Configurations

As a generic container platform, in theory, the Xtended Services Platform could support
deployment of all applications on the same Xtended Services Platform. However, in
practice, a combined deployment model can be problematic for a few reasons.
Memory allocation: Each BroadWorks application has its own default memory
allocation footprint, as does the Web Container application (in which the web
applications run). Certain combinations of deployed applications are in excess of the
available memory on the server. Although the Xtended Services Platform
automatically adjusts each applications memory allocation to fit into the available
memory, the Xtended Services Platform server would no longer be running at the
recommended memory level for each application and would not follow the generic
capacity models captured in the BroadWorks System Capacity Planner [2].
Application cross-impacts: Applications have different behavior and traffic

footprints. For example, with the Device Management application, it would be
considered normal for a mass reboot of phones to occur and the Xtended Services
Platform would not be able to handle all the requests simultaneously. It would be
forced to refuse requests when the Xtended Services Platform is at capacity, in which
case the phone would try another Xtended Services Platform or it would try again
later. If that same Xtended Services Platform were supporting Call Center clients,
these clients would not be able to access the Xtended Services Platform during the
mass device reboot, thus denying service to the client, which would be an
unacceptable grade of service for that specific application.
01-BD5003-00
PAGE 26 OF 95
As a best practice, BroadSoft recommends grouping different applications together into

different Xtended Services Platform deployment configurations based on application
functions. There are five generic Xtended Services Platform deployment configurations:
4.6.3.1
General User Service and Call Control
Business Clients
Device Management
UC-Connect
CTI-Connect
Business Communicator (BC)
General User Service and Call Control Deployment Configuration

This deployment configuration represents the replacement of the legacy Web Server. The
function of the configuration is to support Xtended Services Platform applications that
provide general users with access to service control and call control applications such as
the web portal, BroadWorks clients, and/or third-party clients. This deployment
configuration would generally support the following applications:
CommPilot Web Portal (Web Server legacy replacement)
Open Client Server (Web Server legacy replacement)
Flash Policy (Web Server legacy replacement; required for BroadWorks Call
Manager)
Xsi Actions (Optional application to support newer clients)
Xsi Events (Optional application to support newer clients)
The General User Service and Call Control Xtended Services Platforms would also be the
home for all low penetration applications (for example, specialty applications such as
BWOCTabs, Business client applications in low volume deployments, and Device
Management applications in low volume deployments).
4.6.3.2
Xtended Services Platform: Business Client Services

This deployment configuration provides for the segregation of BroadWorks Receptionist
and Call Center clients to dedicated Xtended Services Platforms to support a high grade
of service for those applications over and above the general user applications. A
deployment planning to scale to greater than 2,000 business clients should consider this
deployment model. This deployment configuration would generally support the following
applications:
BroadWorks Call Center
BroadWorks Call Center Reporting
BroadWorks Receptionist
Xsi Actions
Xsi Events
01-BD5003-00
PAGE 27 OF 95
4.6.3.3
Xtended Services Platform: Device Management

This deployment configuration provides for the segregation of BroadWorks Device
Management applications to dedicated Xtended Services Platforms to protect other
Xtended Services Platform applications. A deployment planning to scale to greater than
10,000 phones should consider this deployment model. This deployment configuration
would generally support the following applications:
4.6.3.4
BroadWorks Device Management
BroadWorks Device Management TFTP (optional)
Xtended Services Platform: UC-Connect

The UC-Connect BroadWorks application interconnects the BroadWorks Application
Server to the Microsoft Office Communications Server (MOC) and provides Remote Call
Control (RCC). The BroadWorks UC-Connect maps the BroadWorks Client Application
Protocol (CAP) to the Computer Supported Telecommunications Applications (CSTA)
interface.
For non-lab usage, the UC-Connect application should be deployed on a dedicated
Xtended Services Platform. By default, the UC-Connect application is dimensioned at 80
percent of available server memory and as such should be the only application running on
this Xtended Services Platform.
NOTE: By default, all Xtended Services Platforms deploy the Web Container. For UC-Connect
Xtended Services Platforms, the Web Container application should be undeployed as it is not
required and a deployed Web Container consumes server memory.
The UC-Connect Xtended Services Platform is deployed in a cluster with a minimum of
two UC-Connect Xtended Services Platforms for redundancy. To increase capacity,
additional UC-Connect Xtended Services Platforms can be added.
The UC-Connect Xtended Services Platform server is dimensioned in terms of
transactions per second (TPS). A transaction is initiated by the MOC when a user logs in
or out or initiates a call. A transaction can also be initiated from the Application Server in
the form of CAP updates when the user initiates a call from their phone.
4.6.3.5
Xtended Services Platform: CTI-Connect

The CTI-Connect deployment configuration interconnects the BroadWorks Application
Server to a Genesys platform to support route point functionality. This deployment
configuration would generally support the following applications:
Xsi Actions
Xsi Events
01-BD5003-00
PAGE 28 OF 95
4.6.3.6
Xtended Services Platform: Business Communicator

This deployment configuration provides for the segregation of Business Communicator
(BC) applications to dedicated Xtended Services Platforms to protect other Xtended
Services Platform applications. The scaling of this configuration depends on the
requirement for enhanced call control. Enhanced call control is required when a user
places a call from their desk or other phone and needs to control the call from the
Business Communicator client. This deployment configuration generally supports the
following applications:
4.7
Business Communicator (required prior to Business Communicator Release 10)
Xsi Actions
Xsi Events (optional if Enhanced Call Control disabled)
BroadWorks Device Management Profile Server

The Profile Server provides a generic container platform for running network core
applications. The Profile Server comes with a number of preinstalled applications that can
be deployed and share the same server resources. There are two types of applications:
Web applications: HTTP/HTTPS-based applications that run in an Apache/Tomcat

Web Container. All web applications run in the same Web Container and share its
resources.
BroadWorks applications: Java or C++ based applications providing some specific

functions. Each BroadWorks application is independent and has its own resource
and dimensioning requirements.
Profile Servers are deployed in a cluster. RSYNC file replication is used between Profile
Servers to keep files synchronized within the cluster. To increase capacity, additional
nodes are added to the cluster. There can be up to ten Profile Server nodes per Profile
Server cluster.
4.7.1
Profile Server Deployment Configurations

As a generic container platform, in theory, the Profile Server could support the deployment
of all applications on the same Profile Server. However, in practice, a combined
deployment model can be problematic for a few reasons:
Memory allocation: Each BroadWorks application has its own default memory
allocation footprint, as does the Web Container application (in which the web
applications run). Certain combinations of deployed applications are in excess of the
available memory on the server. Although the Profile Server automatically adjusts
each applications memory allocation to fit into the available memory, that Profile
server would no longer be running at the recommended memory level for each
application and would not follow the generic capacity models captured in the
BroadWorks System Capacity Planner [2].
Application cross-impacts: Applications have different behavior and traffic

footprints and as such, can impact each other.
As a best practice, BroadSoft recommends grouping different applications together into

different Profile Server deployment configurations based on application functions. There
are two generic Profile Server deployment configurations:
Device Management File Repository
Enhanced Call Center Reporting
01-BD5003-00
PAGE 29 OF 95
4.7.1.1
Provisioning Application (XS mode)
Profile Server: Device Management Repository

This deployment configuration provides for the segregation of BroadWorks Device
Management on to dedicated Profile Servers. This deployment configuration provides a
central repository for the storage of device files. It offers an HTTP and Web-based
Distributed Authoring and Versioning (WebDAV) interface for file operations, and it
supports authentication and file replication to other Profile Servers. A deployment
planning to scale to greater than 10,000 phones should consider this deployment model.
This deployment configuration would generally support the BroadWorks File Repository
application.
4.7.1.2
Profile Server: Enhanced Call Center Reporting

This deployment configuration provides for the segregation of Enhanced Call Center
Reporting applications to dedicated Profile Servers. A deployment planning to scale to
greater than 2,000 Call Center clients should consider this deployment model. This
deployment configuration would generally support the following applications:
BroadWorks Call Center Reporting
BroadWorks Call Center Reporting Repository
BroadWorks Call Center Reporting Database Management
The Profile Server workload, when running the BroadWorks Enhanced Call Center
Reporting applications, is rated in simultaneous requests-per-second reports, which is a
factor of the available CPU. For example, a 12 CPU Unit Profile Server with 12 GB of
RAM would be rated at 750 RPS. The BroadWorks System Capacity Planner [2] uses
this simultaneous requests-per-second reports rating and average report generation
numbers when modeling Profile Server capacity.
4.7.1.3
Profile Server: Provisioning Application (XS Mode)

This deployment configuration supports the provisioning application in XS mode. The
Provisioning Server in this mode connects to the Database Server. For guaranteed
performance, this node cannot be combined with other Profile Server applications. The
BroadWorks System Capacity Planner [2] uses the expected provisioning transactions per
second (administrative and user) to model the Profile Server capacity.
4.8
Database Server
The Database Server provides a generic Oracle 11g2 database platform that can be used
to support one or more schemas. A Database Server configuration consists of one or
more server platforms that run the Oracle instance and storage, and internal disks or
external SAN, to support the database files.
The number of Database Server instances required for a given solution can vary from one
to four platforms depending on the deployment model. A Database Server can be
deployed in one of four deployment models:
Single Instance Non-redundancy single DBS with internal or external storage
Cluster Redundancy Oracle Real Application Cluster (RAC) providing two DBSs
working in a load balanced cluster using a shared storage SAN
Standby Redundancy Oracle Data Guard providing two independent synchronized

DBSs, each with their own storage. One DBS is active, while other is on standby.
01-BD5003-00
PAGE 30 OF 95
4.8.1
Cluster and Standby Redundancy This includes both the Oracle Real Application
Cluster (RAC) and the Oracle Data Guard.
Database Server Dimensioning

Database Server dimensioning and capacity is different for each schema/application. In
general, a database model is required for proper dimensioning regardless of the
application. This model requires the following:
Database Write Model: Number of input/output operations per second (IOPS) and
throughput requirements to support busy hour traffic load under different input
parameters
Database Read Model: Number of IOPS and throughput requirements to support

busy hour database reads under different input parameters
Database Storage Model: Database sizing requirements driven by the number of

tables/rows and data retention time frames
Once the database model is defined and validated, the hardware footprint (CPU, memory)
can be derived for the Database Server and storage requirements (IOPS and throughput)
for the given application.
4.8.2
Database Server Disk Requirement

The Database Server can use either internal or external storage for the database. The
BroadWorks System Capacity Planner [2] provides a view of the required IOPS, the data
throughput, and the storage space that the storage system needs to support based on the
expected scaling of the solution. The storage system needs to be engineered to meet
those requirements. As a general rule of thumb, a 10K RPM disk can support 150 IOPS,
while a 15K RPM disk can support 180 IOPS. The DBS provides a tool to estimate disk
capabilities post-schema deployment. For more information, see section 11 Device
Management Growth Estimation Procedure.
4.8.2.1
External Array Minimum Requirements

BroadSoft has validated the Database Server with external SAN storage. The minimum
SAN requirements are:
Interface: 4 Gigabits per second (Gbps) Fiber Channel/SAS
Controller caching: 1 GB
01-BD5003-00
PAGE 31 OF 95
4.9
Access Mediation Server

The Access Mediation Server enables support for the Skinny Call Control Protocol
(SCCP) on BroadWorks. The Access Mediation Server provides conversion between
SCCP and SIP, thereby allowing the BroadWorks Application Server to control and route
calls to and from SCCP devices connected to the Access Mediation Server.
The Access Mediation Server is deployed in an ACTIVE-ACTIVE configuration. This is
the standard deployment in which two Access Mediation Servers are collocated and are
installed on the same subnet (site redundancy). This allows for seamless Real-Time
Transport Protocol (RTP) failover. The Access Mediation Server also supports a
geographic redundant configuration without site redundancy/RTP failover. Both
mechanisms can be used together; however, this requires twice the number of servers.
The Access Mediation Server is dimensioned in terms of media ports as well as resources
for the expected load of phone registrations and calls.
4.10 Service Control Function

The Service Control Function (SCF) provides inter-networking capabilities, allowing the
BroadWorks Application Server to deliver mobile calls to the Voice over Internet Protocol
(VoIP) domain. The SCF communicates with the mobile operators network over standard
protocols, such as CAMEL, GSM MAP, ANSI-41, and WIN. It resides in the mobile
operators network or in a hosting center.
The Service Control Function server is deployed in an ACTIVE-STANDBY configuration
and is dimensioned in terms of overall transactions per second.
4.11 Messaging Server

The Messaging Server (UMS) is an Extensible Messaging and Presence Protocol (XMPP)
server that can be deployed in the BroadWorks environment. It provides one-on-one
messaging, group chat, vCard Support, shared contacts, roster list presense, and
federation with other XMPP servers.
The Messaging Server is deployed in an active-active pair configuration. An Application
Server cluster can use a single Messaging Server pair; however, a Messaging Server pair
can be shared by more than one Application Server cluster.
The Messaging Server is dimensioned by the number of simultaneously connected
Business Communicator clients. It is primarily limited by memory.
4.12 Sharing Server

The Sharing Server (USS) provides desktop sharing capability to the UC-One client
Release 20.0. It is deployed in a farm configuration with N+1 redundancy. A single farm
can be used by the entire system.
The Sharing Server is dimensioned in terms of the number of desktop share sessions.
The Sharing Server is primarily limited by memory.
4.13 WebRTC Server

The WebRTC Server (WRS) is a dual-homed server that terminates signaling and media
from WebRTC-enabled browsers on the public side and provides interworking of calls
originated by WebRTC-enabled browsers to trusted SIP elements on the private side. It is
deployed in a farm configuration with N+1 redundancy. A single farm can be used by the
entire system.
01-BD5003-00
PAGE 32 OF 95
A given WebRTC node supports a fixed number of audio and video transcoding sessions.
4.14 Network Function Manager

The Network Function Manager (NFM) provides centralized licensing starting in Release
21. It is deployed in a farm configuration, with a minimum of three servers required for
high availability support.
4.15 Video Server

The Video Server (UVS) provides My Room collaboration capability to the UC-One client.
It is deployed in a farm configuration with N+1 redundancy. A single farm can be used by
the entire system.
The Video Server is dimensioned in terms of the number of required video and audio
streams.
01-BD5003-00
PAGE 33 OF 95
Hardware Capacities
The BroadWorks Platform Dimensioning Guide [1] describes the supported hardware
configurations for each BroadSoft server.
The following tables show base server capacity based on CPU for the various supported
CPU Unit footprints, where a CPU Unit is equivalent to a CPU core or thread. For
example, a quad core E5405 CPU would be equivalent to 4 CPU Units, while a quad core
L5520 CPU with hyper-threading per core would be equivalent to 8 CPU Units.
These CPU-based numbers can be used for manual capacity planning as described in
section 6 System Capacity Planning. Numbers vary based on service usage and call
model. For more information, see the BroadWorks System Capacity Planner [2].
Intel Xeib-based Server CPU-based Capacities
BroadSoft Server Type
Application
Network
Media
Xtended
Services
Platform
Element
Management/
Network
Function
Manager
18 CPS per CPU
188 TPS per

CPU
See section 7.1.3

Generic Port
Calculation
Rules.
150 RPS per

CPU
250 managed
objects/nodes
18 PTPS per CPU
UC-Connect
Access Mediation Server
Service Control Function
62 TPS per CPU
325 ports per CPU
100 TPS per CPU
Messaging
Server
Sharing Server
Video Server
WebRTC
100,000 users
2,000 active participants
See section 7.2 Video

Server Engineering Rules.
500 audio
20 video
NOTE: When a hyper-threading capable CPU is used with hyper-hyper threading disabled, the
capacity can be multiplied by a factor of 1.5.
01-BD5003-00
PAGE 34 OF 95
System Capacity Planning

This section describes how to estimate system capacity and determine the required
number of nodes of each type required to handle the expected configuration.
Section 6.1 Using System Capacity Planner describes the usage of the BroadWorks
System Capacity Planner [2]. The formulas described in section 6.2 Capacity Planning
Details by Node describe how system capacity is computed. A system can also be
manually engineered using these formulas.
NOTE: Capacity planning provides an estimate of the required number of nodes and their
capacity during system planning. It is not intended as a substitute for continuous live system
monitoring based on defined system indicators as described in section 9 Server Performance
Guidelines. In addition, future growth expectations should periodically be re-evaluated based on
current system information, as described in section 10.1 Growth Estimation Procedure.
6.1
Using System Capacity Planner

A systems capacity can be estimated using the BroadWorks System Capacity Planner
[2]. The first worksheet of the capacity planner describes the call model.
The call model can be input to the BroadWorks System Capacity Planner using manual
inputs or using one or more packaged configurations.
The BroadWorks System Capacity Planner can be used for bare metal hardware or a
virtualized system (as described in section 6.1.4 Bare Metal/Virtualized Configurations).
The BroadWorks System Capacity Planner can also be used to input key performance
indicators from a live system and perform additional capacity planning. This is described
in section 6.1.5 Use Live Data Input.
6.1.1
Use Single-Packaged Configuration

The BroadWorks System Capacity Planner [2] supports the following packaged
configurations:
Standard Residential/SOHO User Package with Unified Messaging
Premium Residential/SOHO User Package with Unified Messaging
Business Line
Business Trunk
Standard Enterprise User Package with Unified Messaging
Premium Enterprise User Package with Unified Messaging
The configuration can be selected from the drop-down menu. After the configuration is
selected, the number of users, user Erlangs, and hold time can be entered. For the
Business Trunk package, the number of simultaneous calls is entered instead of the
number of users. The Apply packaged configuration(s) button is used to apply the
selected call model for the configuration.
For information on the call model for the packaged configurations, see Appendix C: Call
Model for Packaged Configurations.
01-BD5003-00
PAGE 35 OF 95
6.1.1.1
Example 1: Standard Residential System

1)
Select the Standard Residential/SOHO User Package with Unified Messaging

package from the drop-down menu for Packaged Configuration Selection 1.
2)
Enter the number of users and adjust the User Erlang/Call Hold time as necessary.
3)
Click the Apply Packaged Configuration(s) button.
4)
Select the hardware server types for each of the BroadWorks nodes (that is, the
Application Server, Network Server, and so on).
The Capacity Planner computes the server requirements

6.1.1.2
Example 2: Business Trunking System

1)
Select the Business Trunking from the drop-down menu for Packaged Configuration
Selection 1.
2)
Enter the number of simultaneous calls and adjust the User Erlang/Call Hold time as
necessary. The number of simultaneous calls is equivalent to the number of trunking
lines.
3)
Click the Apply Packaged Configuration(s) button.
4)
Select the hardware server types for each of the BroadWorks nodes (that is,
The Capacity Planner computes the server requirements.

6.1.1.3
Example 3: Standard Residential System with additional Simultaneous Ringing

Service Usage
1)
Repeat steps in section 6.1.1.1 Example 1: Standard Residential System.
2)
Display the manual configuration settings by clicking on the Toggle View button in the
Manual Configuration area.
3)
Update the penetration percentage for the Simultaneous Ringing service.

NOTE: If the Apply Packaged Configurations button is selected again, it overwrites the manual
settings from the previous step.
6.1.2
Use Multiple-Packaged Configurations

Multiple-packaged configurations can be displayed and configured using the More
Configurations button. A mix of up to five configurations is supported. The Capacity
Planner automatically weighs the profiles to determine the overall processing and memory
requirements. Note that it is assumed that the users with the various profiles are evenly
distributed across the Application Server clusters.
6.1.2.1
Example 1: System with Mix Standard Residential and Business Trunking

1)
Select the Standard Residential/SOHO User Package with Unified Messaging

package from the drop-down menu for Packaged Configuration Selection 1.
2)
Enter the number of residential users.
01-BD5003-00
PAGE 36 OF 95
3)
Click the More Configurations button.
4)
Select the Business Trunking package from the drop-down menu for Packaged
Configuration Selection 2.
5)
Enter the number of simultaneous trunking calls.
6)
Click the Apply Packaged Configurations button.
7)

6.1.2.2
Example 2: System with Mixed Standard Residential and Business Trunking but with
Additional Simultaneous Ringing Service Usage
1)
Repeat the steps from the previous example.
2)
Display the manual configuration settings by clicking the Toggle View button in the
Manual Configuration area.
3)
Update the penetration percentage for the Simultaneous Ringing service. Note that
you must manually compute the weighting for this service. This weighting is for the
whole system and overrides the weighting computed for the mix of the packaged
configurations.
4)

NOTE: If the Apply Packaged Configurations button is selected again, it overwrites the manual
settings from the previous step.
6.1.3
Use Manual Configuration

Alternate call models can be also manually input to the BroadWorks System Capacity
Planner [2]. The call model can initially be derived from a packaged configuration and
then altered by toggling the view of the Manual Configuration area. Note that the manual
configuration applies to the entire system and not to a particular profile.
6.1.4
Bare Metal/Virtualized Configurations

Once the call model is entered, the next worksheets are used to select the hardware
configuration. The planner will then output the number of servers required to support the
load.
The Capacity Planner worksheet is used for bare metal hardware. On this worksheet,
the hardware type and configuration (CPU units and memory) are selected from dropdown lists, which correspond to the resources defined in the BroadWorks Platform
Dimensioning Guide [1].
01-BD5003-00
PAGE 37 OF 95
The Virtualized Planner worksheet is used for a virtualized system. On this worksheet,
the hardware is selected automatically and can be overridden by user inputs. In automatic
mode, the hardware is selected as a minimum configuration if it can support the load.
Larger or smaller servers can be selected using drop-downs for CPU Units and Memory.
The Virtualized Planner also computes the total disk space requirements (storage,
throughput, and IOPS) as well as the required network bandwidth for each node. Finally,
on the bottom line, the Virtualized Planner reports the total resource requirements for the
system. For the minimum and maximum specifications for each virtualized BroadWorks
node, see the BroadWorks Platform Dimensioning Guide [1]. For virtualization
configuration and supported virtual machines, see the BroadWorks Virtualization
Configuration Guide [3].
6.1.5
Use Live Data Input

The BroadWorks System Capacity Planner [2] can be used to take key performance
indicators from a live deployed system and perform additional capacity planning such as
selecting new hardware or changing the call model.
The capacity planning of changes to the call model from live data depends on accurately
capturing the current call model.
The following data should be collected and used as input to the planner:
Current Application Server hardware.
Current Packaged Configuration or Manual Call Model Input. This is optional and only
used if the call model is to be altered for additional capacity planning. Selecting
Manual for the packaged configuration uses the input from the manual configuration
area.
Execution Server heap size: Collected as described in section 10.1.1.1 Execution

Server Post Full Collection Heap Size.
Database permanent size: Collected as described in section 10.1.1.2 Database

Permanent Size.
Busy CPU percentage: Collected during the busy hour as described in section
10.1.1.3 Worst Case Busy Hour CPU.
Number of users: Collected as described in section 10.1.1.4 Provisioned Users.
Number of simultaneous calls: Collected during the busy hour from the SNMP gauge
executionServer/callpModule/callpStats/bwCallpActiveCalls. This data is optional and
only required for computing the actual user Erlang.
Calls per second: Collected during the busy hour from the SNMP gauge
executionServer/callpModule/callpStats/bwCallpCallsPerSecond. This data is also
optional and only required for computing the actual user Erlang.
The Input to Model button applies the data to the model. The Clear button removes all live
data inputs and changes the planner to its original state.
Note that changes to the memory profile such as the number of users per group or
number of groups per service provider are not able be changed for additional capacity
planning. The initial memory and database profile is always used.
01-BD5003-00
PAGE 38 OF 95
6.1.5.1
6.1.5.2
6.2
Example 1: Selecting New Hardware

1)
Display the live data input area by clicking on the Toggle View button.
2)
Enter the current Application Server hardware, packaged configuration, number of

users, number of simultaneous calls, calls per second, database permanent size,
Execution Server heap size, and busy CPU percentage.
3)
Click on the Input to Model button. An initial growth estimate is displayed to the right
of the live data input area.
4)
Select the new hardware server type for the Application Server node. The new
number of users is computed and displayed.
Example 2: Adding Additional Simultaneous Ringing Service Usage

1)
Repeat steps 1 through 4 from the previous example.
2)
Display the manual configuration area by clicking on the Toggle View button.
3)
Enter a new value for the Simultaneous Ringing service penetration. This new value
can be a delta value if previous usage is unknown. For example, if no packaged
configuration is used when the Input to Model button is selected, then the usage can
be set to 10% to estimate an additional 10% increase in usage.
4)
The new number of users and server requirements is computed and displayed.
Capacity Planning Details by Node

The following sections describe the formulas used by the BroadWorks System Capacity
Planner [2] to estimate the capacity of each node.
6.2.1
IPSec Tunnels
The overall impact of IPSec with ESP encryption ON (the worst-case scenario) is of 4% on
the system (Kernel) processes. With ESP-Null, the overall degradation of the system
is ~1%.
6.2.2
Application Server
The capacity of a given Application Server node is determined by the processing and
memory requirements as defined by the call model.
Using the global call weighting (derived from the call model) an effective CPS can be
determined. The provisioning load is taken into account by determining the amount of
provisioning transactions expected and applying a weighting factor.
Provisioning traffic is generated by the web interface, command line interface (CLI), and
clients (BroadWorks and third party) proxied by the Open Client Server (OCS). An
Application Server web page generates approximately 2.7 OCI transactions per web page
hit. A high concentration of add, delete, and modify transactions have more impact on the
server.
These are the assumptions for the following example:
Hardware supports Base CPS of 33 and Base Provisioning TPS of 33
Erlang = .2
Average call hold time = 3 minutes
Global call weighting = 1.2
01-BD5003-00
PAGE 39 OF 95
Provisioning transactions per user per hour = 5

Value
Formula
Example
Base CPS
See section 5 Hardware Capacities.
33 CPS
Base Provisioning
Transactions per
Second
33 TPS
Weighted CPS
Base CPS/Global call weighting
33 / 1.2 = 27.5
Calls per User per

Hour
Erlang * 60/Hold time
.2 * 60 / 3 = 4
Call Processing Users
Weighted CPS * 3600/Calls per user

per hour
27.5 * 3600 / 4 = 24750
Number of
Provisioning
Transactions per
Second
Number of users * Provisioning

transactions per user per hour/3600
24,750 * 5 / 3600 = 34.375
Provisioning
Weighting Factor
.5 + .5 * Provisioning TPS/Base
provisioning TPS
.5 + .5 * 34.375 / 33 =
1.021
Number of Users
Call processing users/Provisioning

weighting factor
24750 / 1.021 = 24240
CPS
Weighted CPS/Provisioning
weighting factor
27.5 / 1.021 = 26.9
A given servers memory requirements are determined from the memory required for the
database, active calls, and additional cached data per subscriber. The following
assumptions are used for memory requirements:
Active call footprint = 90 KB
Database usage per enterprise users = 40 KB
Database usage per residential user (one user per group) = 52 KB
Additional cached data per enterprise subscriber = 9 KB
Additional cached data per residential subscriber = 19 KB
SIP call hold time extension (SIP T2 * 10) = 40 seconds
Total database size up to 512 MB on system with 2 GB of RAM
Total database size up to 3/8 of RAM on system with > 2 GB RAM
Execution Server (Call Processing Server) heap size = 25% of RAM; at most 60% in
use during busy hour.
The maximum number of users based on memory requirements is computed as shown in

the following table. For the example, we assume a server with 8 GB of RAM and an
enterprise-type deployment.
Value
Formula
Example
Maximum Database
Size
RAM * 3/8
8 * 3/8 = 3 GB
Maximum Number of
Users based on DB
Size
0.9 * maximum database size * 1024

* 1024 / database usage per
subscriber
0.9 * 3 * 1024 * 1024 / 26

= 108890
01-BD5003-00
PAGE 40 OF 95
Value
Formula
Example
Maximum Number of
Users based on Call
Footprint
RAM * 1024 * 1024 * 0.25 * 0.6 /

(cached data per subscriber + 90 *
calls per user per hour * (hold time +
40)/3600)
8 * 1024* 1024 * 0.25 *

0.6 / (9 + 90 * 4 * (180 +
40) / 3600) = 40591
Maximum Number of
Users based on
Memory
Requirements
Smaller of previous two calculations
40591
The total number of users supported on a given hardware box is the smallest of the
number of users above. In the example, the maximum number of users based on
processing requirements is 24,240 and based on memory requirements is 40,591.
Therefore, the maximum number of users is 24,240.
The total number of Application Server clusters can then be determined from the required
number of users. From the example above, if this system needs to support 60,000 users,
then three Application Server clusters would be required.
6.2.3
Network Server
Each Network Server node can process a maximum number of transactions per second
(TPS). To estimate the number of Network Server nodes required for a given deployment,
the total transactions required must be calculated.
The total TPS required for a system is estimated as the sum of the following:
Call Redirection Traffic The total number of calls that use the Network Server for
redirection processing. This is usually the total number of external incoming/outgoing
calls but in some deployments (for example, IMS) it may include intra-group calls.
Media Server Selection Requests The total number of Application Server initiated
requests to locate a Media Server resource.
Access-side Registration and Call Traffic The total number of registrations and
calls initiated and routed to the Network Server (when configured). This is a system
configuration option.
User Locator Requests: The total number of user logins/location requests from the
web portal, OCS, or Xtended Services Platform.
50% incoming network calls
50% outgoing network calls
Erlang = .2
Average call hold time = Three minutes
1.5 user locator request per user per hour
Percent of calls utilizing Media Server = 20%
Access-side routing not enabled
01-BD5003-00
PAGE 41 OF 95
Value
Formula
Example
Base TPS
150 TPS
Calls per User per

Hour
Erlang * 60 / Hold time
0.2 * 60 / 3 = 4
Call Redirection
Transactions per Hour
Calls per user per hour * (Percent

incoming network calls + Percent
outgoing network calls)
4 * (0.5 + 0.5) = 4
Access-side
Transactions per Hour
If configured:
User Locator
Requests per Hour
Web logins per user per hour + Thirdparty client logins per user per hour
1.5
Media Server
Selection Requests
per Hour
Calls per user per hour * Percent of

calls utilizing the Media Server
0.2 * 4 = 0.8
Total Transactions per

User per Hour
Sum of previous four rows
4 + 1.5 + 0.8 = 6.3
Total Number of
Users per Network
Server Node
Base TPS * 3600 / Total transactions

per user per hour
150 * 3600 / 6.3 = 87,142
(Registration interval * 2) + (Calls per

user per hour + percent outgoing
calls)
The total number of Network Server nodes can then be determined from the required
number of users. From the example above, if this system needs to support 120,000
users, then two Network Server nodes would be required, plus one for redundancy.
Therefore, there would be a total of three nodes.
6.2.4
Media Server
A Media Servers capacity is divided among audio IVR/conferencing, video transcoding,
and video conferencing. The number of CPUs and resources for each are controlled via
settings in the command line interface (CLI) described in section 7.1 Media Server
Engineering Rules.
To estimate the total number of Media Servers required for a given deployment, a
calculation is made of the number of users that can be supported for audio IVR, audio
conferencing, video transcoding, and video conferencing.
To determine the Media Server requirements for audio IVR/conferencing, the number of
users per port is calculated. To do this calculation, first the call model must be used to
estimate the percent of calls that require a Media Server audio resource. The average
duration of these calls must also be determined from the call model.
Percentage of calls using Media Server IVR resource = 18%
Percentage of calls using Media Server audio conferencing resource = 2%
Average IVR duration = 30 seconds
Average conference duration = 195 seconds
Percent G.729 codec = 100%
IVR resource ratio = 75
Erlang = .2
01-BD5003-00
PAGE 42 OF 95
Average call hold time = Three minutes

Value
Formula
Example
Base G.711 Ports
See section 7.1.Media Server

Engineering Rules.
600 ports
Calls per User per

Hour
Erlang * 60 / Hold time
0.2 * 60 / 3 = 4
Average Erlang of
Media Server IVR
Resources in Busy
Hour
Percentage of calls using Media

Server IVR * Calls per user per hour *
Average IVR call duration / 3600
0.18 * 4 * 30 / 3600 =
0.006
Average Erlang of
Media Server Audio
Conferencing
Resources in Busy
Hour
Percentage of calls using Media

Server audio conferencing * Calls per
user per hour * Average call duration
/ 3600
0.02 * 4 * 195 / 3600 =

0.0043
Users per Media

Server IVR Port
1/ average Erlang of Media Server

resources in busy hour
1/ 0.006 = 166 users
IVR Port Weighting
1 * G711 + 1.25 * G726 + 1.7 * G729

+ 2 * Video
1 * 0 + 1.25 * 0 + 1.7 *
1 + 2 * 0 = 1.7
Users per Media

Server Conferencing
Port
1/ average Erlang of Media Server

1/ 0.0043 = 230 users
Conference Port
Weighting
1 * G711 + 2 * G726 + 5 * G729
1 * 0 + 2 * 0 + 5 * 1 = 5
Number of Weighted
IVR Ports
Base ports * IVR resource ratio / IVR

port weighting
600 * 0.75 / 1.7 = 264
Number of Weighted
Conferencing Ports
Base ports * (1 IVR resource ratio) /

Conference port weighting
600 * 0.25 / 5 = 30
Number of Users
based on IVR
Weighted ports * Users per Media

Server IVR port
264 * 166 = 44000
Number of Users
based on
Conferencing

Server conferencing port
30* 230 = 6900
Total Number of
Users per Media
Server Node Based
on IVR/Conferencing
requirements
Minimum of users based on IVR or

conferencing
6900
To determine the number of users supported for video transcoding, the call model is again
used to determine the duration, frequency, and type of transcoding required. Video codec
determines the amount of time a video transcoding thread is used.
Average duration of video transcoding = 30 seconds
Percentage of Time User Requires Media Server Transcoding Resource = 10%
Percentage H.264 CIF codec = 100%

Value
Formula
Example
Number of Video
Transcoding
Processes

Engineering Rules.
01-BD5003-00
PAGE 43 OF 95
Value
Formula
Example
Transcoding Duration

Engineering Rules. For H.264 CIF,
the value is 1/4.
30 * 1/14 = 2.14
Average Erlang of
Media Server
Resources in Busy
Hour
Percent of calls using video

transcoding * Calls per user per hour
* Transcoding duration / 3600
0.1 * 4 * 2.14 / 3600 =

0.000238
Users per Video

Transcoding Process
Average Erlang of Media Server

1/ 0.000238 = 4205 users
Total Number of
Users per Media
Server Node based on
Video Transcoding
Requirements
Weighted ports * Users per video

transcoding process
3 * 4205 = 12616
To determine the number of users supported for video conferencing, the call model is
again used to determine the duration and frequency of video conferencing usage. Video
codec determines the weighting.
Average duration of video conference = 600 seconds
Percentage of calls using video conferencing = 0.5%
Average number of participants per conference = 3
Percentage CIF codec = 100%

Value
Formula
Example
Number of Video
Conferencing Ports

Engineering Rules.
6000
Average Erlang of
Media Server
Resources in Busy
Hour
Percent of calls using video

conferencing * Calls per user per
hour * Average number of
participants * Conference duration /
3600
0.005 * 4 * 3 * 600 /
3600 = 0.01
Users per Media

Server Port
1/ Average Erlang of Media Server

1/ 0.01 = 100 users
Port Weighting

Engineering Rules.
70
Weighted ports
Base ports / Port weighting
6000 / 70 = 85
Total Number of
Users per Media
Server Node Based
on Video
Conferencing
Requirements

Server port
85 * 100 = 8500
The number of users per Media Server is the lower of the above three calculations (users
based on audio resources, users based on video transcoding, and users based on video
conferencing). For the previous example, this would be 6814.
The total number of Media Server nodes can then be determined from the required
number of users. From the example above, if this system needs to support 60,000 users,
then nine Media Server nodes would be required, plus one for redundancy. Therefore,
there would be a total of ten nodes.
01-BD5003-00
PAGE 44 OF 95
6.2.5
Xtended Services Platform General User Service and Call Control

Each Xtended Services Platform node can process a maximum number of transactions
per second (TPS). To estimate the number of Xtended Services Platform nodes required
for a given deployment, the total transactions required must be calculated.
Xtended Services Platform transactions in a General User Service/Call Control
deployment configuration consist of the following:
Web page hits
Third-party client transactions processed by the Open Client Server (OCS)
Web penetration = 20%
Web pages per user per hour = 10
BroadWorks AssistantEnterprise penetration = 10%

Logins per hour = 1
Operations per hour = 2
Third-party client usage = 0%
CommPilot Call Manager penetration = 5%
CCC2 penetration = 0%
Value
Formula
Example
Base TPS
500 TPS
Web Transactions per

User per Hour
Web penetration * Pages per user

per hour
0.2 * 10 = 2
BroadWorks
AssistantEnterprise
Transactions per User
per Hour
Penetration * (logins per user per

hour * 18 + operations per user per
hour * 3)
0.1 * ( 1 * 18 + 2 * 3) =
2.4
OCS (OCI-P)
per Hour
BroadWorks client transactions per

user per hour + Third-party client
transactions per user per hour
2.4 + 0 = 2.4
OCS (OCI-C)
per Hour
Calls per user per hour *(Call

Manager penetration + CCC2
penetration) * 4
4 * (0.05 + 0) * 4= 0.8
Total Transactions per

User per Hour
Web transactions per user per hour +

OCS (OCI-P) transactions per user
per hour + OCS (OCI-C) transactions
per user per hour
2 + 2.4 + 0.8 = 5.2
Total Number of
Users

per user per hour
500 * 3600 / 5.2 = 346K
Another aspect of Xtended Services Platform capacity planning is ensuring there is

enough memory on the server to support the required number of simultaneous
connections. The total number of simultaneous connections is the sum of the active
HTTP and OCS logins. An Xtended Services Platform can support approximately 5,000
simultaneous connections per 6 GB of server memory. For example, a box with 6 GB of
RAM can support at most 5,000 simultaneous connections.
01-BD5003-00
PAGE 45 OF 95
The total number of Xtended Services Platform nodes can then be determined from the
required number of users. From the previous example, if this system needs to support
300,000 users, then one Xtended Services Platform node would be required, plus one for
redundancy, for a total of two nodes.
6.2.6
Xtended Services Platform Device Management

Each Xtended Services Platform Device Management node is dimensioned according to
the following primary constraints:
Network bandwidth
Web container thread usage
Heap usage
CPU
Supported traffic levels are modeled as a function of the following:
Number of devices
Device type complexity which determines the amount of incoming traffic on a phone
reboot/reset:
Number of GET requests
Number of PUT requests
Average response time
Average response size
Amount of controlled rebuild traffic (for example, rebuilding all devices at a group level
due to a template change).
Amount of controlled phone resets (for example, due to a rollout of new firmware).
Background traffic:
6.2.7
Automatic rebuilds traffic due to configuration changes
Automatic resets due to configuration changes
Background PUT traffic (for example, phone logs)
Element Management System

The number of Element Management System nodes is a simple computation based on
the total number of BroadWorks and non-BroadWorks nodes to be managed.
For example, if the Element Management System hardware supports 100 managed
objects, then for a deployment with 75 nodes, two Element Management System boxes
would be required for a redundant configuration.
6.2.8
Profile Server Device Management

Profile Server dimensioning for Device Management is similar to dimensioning for the
Xtended Services Platform Device Management node. One difference; however, is that
the amount of requests that require usage of the Profile Server is affected by the caching
rate. In Release 18.0 and later, the Xtended Services Platform has an option to cache
static files for a configurable period of time. The cache is refreshed based on time or
when the file changes.
01-BD5003-00
PAGE 46 OF 95
The Profile Server is also constrained by disk throughput.

6.2.9
UC-Connect
Each UC-Connect node can process a maximum number of transactions per second
(TPS). To estimate the number of nodes required for a given deployment, the total
transactions required must be calculated.
UC-Connect transactions consist of the following:
Login/logout
Call creation and call state changes sent from the Application Server
Click To Dial transactions from the Office Communicator client
The assumptions for the following example are:
UC-Connect penetration = 100%
Login/logout transactions per user per hour = 0.1
Click To Dial penetration = 5%
Calls per user per hour = 4

Value
Formula
Example
Base TPS
250 TPS
Outgoing call
transactions per user
per hour
Penetration * Calls per user per hour
1.0 * 4 = 4.0
Click To Dial
transactions per user
per hour
Penetration * Calls per user per hour

* Click To Dial penetration
1.0 * 4 * 0.05 = 0.2
Total transactions per

user per hour
Login/logout transactions per user

per hour + Outgoing call transactions
per user per hour + Click To Dial
transactions per user per hour
0.1 + 4.0 + 0.2 = 4.3
Total number of users

per user per hour
250 * 3600 / 4.3 = 209302
Another aspect of UC-Connect capacity planning is ensuring there is enough memory on

the server to support the required number of simultaneous sessions. The total number of
sessions is the total number of users. One UC-Connect node can support approximately
13,750 sessions per GB of server memory. For example, a box with 16 GB of RAM can
support at most 220,000 sessions.
The total number of UC-Connect nodes can then be determined from the required number
of users. From the example above, if this system must support 200,000 users, then two
UC-Connect nodes would be required, plus one for redundancy, for a total of three nodes.
01-BD5003-00
PAGE 47 OF 95
6.2.10 Access Mediation Server

Each Access Mediation Server node can maintain a maximum number of RTP sessions
for calls. To estimate the number of nodes required for a given deployment, the total
number of ports required must be calculated.
User Erlang = 0.1
Value
Formula
Example
Base ports
1300 ports
Total number users
Base Ports / (SCCP Penetration *

User Erlang)
13,000
Another aspect of AMS capacity planning is to ensure enough memory is available for
registrations and calls. The following assumptions are used for memory requirements:
Memory per registration/binding = 29 KB
Active call footprint = 11 KB
Signaling server heap size = 50% of RAM; at most 60% in use during busy hour.
The maximum number of users based on memory requirements is computed as shown in

the following table. For this example, a server with 8 GB of RAM and an enterprise-type
deployment are assumed.
Value
Formula
Example
Memory per user
Memory Per Binding + Memory Per

Call * User Erlang
29 + 11 * 0.1 = 30.1
Maximum number of
users based on
memory footprint
RAM * 1024 * 1024 * 0.5 * 0.6 /

Memory Per User
6 * 1024* 1024 * 0.5 *

0.6 / 30.1 = 62705
The total number of users supported on a given hardware box is the smallest of the
number of users above.
The total number of Access Mediation Server clusters can then be determined from the
required number of users. A minimum of two nodes are required for each cluster. Four
are required for geographic redundancy.
The System Capacity Planner [2] assumes there is no geographic redundancy. If this is
required, then the number of servers should be doubled.
6.2.11 Service Control Function
Each Service Control Function (SCF) node can process a maximum number of
transactions per second. To estimate the number of nodes required for a given
deployment, the total number of transactions required must be calculated. Transactions
for the SCF come from IN trigger-based originations and terminations as well as message
waiting indicator (MWI) notifications.
01-BD5003-00
PAGE 48 OF 95
System Engineering Rules

This section outlines system engineering rules for BroadWorks servers.
7.1
7.1.1
Media Server Engineering Rules

Media Server Resources
The following Media Server resources control capacity and scaling:
Processor allocation This is the number of available processes for each service.
This is based on the number of CPU cores and can be configured via the CLI.
RTP ports This represents the maximum number of simultaneous RTP streams that
the Media Server can support. This value has a maximum of 4000 and can be
lowered via CLI configuration. The maximum is 1000 for virtualized configurations.
Audio ports This is a dynamically calculated value that is based on platform

capabilities that define the upper boundary of generic audio ports that a Media Server
can support. It represents the CPU limit based on profiling. The maximum is 9500
for Release 20.0 and later. The maximum is 4000 prior to Release 20.0.
Video ports This is a dynamically calculated value based on platform capabilities. It

defines the upper boundary of generic video ports that a Media Server can support.
Media Server resources define the limits that apply to the following services: Interactive
Voice Response (Audio/Video), Conferencing (Audio/Video), Fax Messaging, Stream
Mixer (used for call recording), and Repeaters (used for Lawful Intercept and In-Call
Service Activation). Resource allocations can be tuned to favor one service over another.
For example, a Media Server can be tuned to be IVR-centric or conferencing-centric by
optimizing the capacity numbers for that service.
The main controls that affect resource allocation are as follows:
7.1.2
Number of audio processes
Number of video processes (default = 1 if more than 8 CPUs; otherwise, 0)
IVR resource ratio (default = 75)
Video transcoding resource ratio (default = 100)
Media Server Processor Allocation Rules

The Media Server allocates CPUs to specific processes. The number of processes is a
major factor in port allocation. CPUs are reserved for the Operating System, Repeater,
Stream Mixer, and Control Channel Framework (CFW) processes. By default, this
reserves 4 CPUs. The remaining CPUs are divided between Audio and Video processes.
The number of video processes versus audio processes on a given Media Server is
configured via the numVideoProcesses and numAudioProcesses parameters on the
Media Server CLI. By default, both numVideoProcesses and numAudioProcesses
parameters are set to automatic, which means that only one video process is enabled at
start-up. Setting either of the two process parameters results in a change in the other
based on the remaining available CPUs (even though the CLI still references that
parameter as automatic). In general, only one should be set and the other should be
automatically calculated.
01-BD5003-00
PAGE 49 OF 95
If numAudioProcesses is set to a value greater than 3, then numVideoProcesses =

number of CPUs reserved CPUs numAudioProcesses.
If numAudioProcesses is set to a value less than or equal to 3, then

numVideoProcesses = number of CPUs reserved CPUs 2.
If numVideoProcesses is set, then numAudioProcesses number of CPUs 1

numVideoProcesses.
Video processes are further divided into processors dedicated to either transcoding or
conferencing. The CLI parameter, videoTranscodingResourcesRatio, sets the percentage
of video processors dedicated to transcoding (the remaining parameters are dedicated to
video conferencing). By default, the videoTranscodingResourcesRatio defaults to 100.
For a video conferencing-only Media Server, the videoTranscodingResourcesRatio should
be set to 0.
7.1.3
Generic Port Calculation Rules

Media Servers are limited to a number of generic ports that are derived using the following
algorithm:
If the Media Server hardware platform is listed in the hardware_cap.csv file located in
/usr/local/broadworks/bw_base/conf, the number of Media Server ports for this server
is equal to the lesser of the hardware_cap.csv file value or the numPorts= value listed
in the license.txt file read at server start-up.
If the Media Server hardware platform is not listed in the hardware_cap.csv file
located in /usr/local/broadworks/bw_base/conf, the number of Media Server ports for
this server is equal to the lesser the numPorts= value listed in the license.txt file or the
port number calculated from the following CPU and memory based formulas:
The CPU-derived port number is based on the following formula:
CpuMaxPorts = #_of_CPU X CPU_Frequency/3
where the #_of_CPU and CPU_Frequency are those provided by cat
/proc/cpuinfo. CPU_Frequency is expressed in MHz (for example, 2 GHz would be
2000 MHz).
A final memory-based port calculation is done to ensure that the server can support
the number of ports calculated based on CPU. The memory-based calculation uses
the lesser of the total physical memory on the server (AvailMem) or shared memory
(ShmMem) (both expressed in MB) and takes into account IVRResourcesRatio that
can be configured under the CLI MS_CLI/System level.
If AvailMem < ShmMem, MemMaxPorts = (AvailMem 1500)/(2 *

IVRResourcesRatio)
If AvailMem > ShmMem, MemMaxPorts = (ShmMem * .75)/(2 *

IVRResourcesRatio)
where ShmMem can be obtained using the df k command and looking at the
/dev/shm partition size. By default, this is set to 50% of the RAM on a box with 6 GB
or less and 66% on a box with more than 6 GB.
The final maximum generic port number (maxGenericPorts) is the lesser of licensed
ports, CpuMaxPorts, and MemMaxPorts.
01-BD5003-00
PAGE 50 OF 95
7.1.4
Audio Port Calculation Rules

The number of audio ports on a server is determined by multiplying the number of generic
ports by the ratio of audio processes to the total number of CPU.
For example, if the maximum number of generic ports is 9000, and there are three audio
processes and 12 CPUs, then the server will be allowed 2250 audio ports. The ports are
split across IVR and conferencing as governed by the ivrResourceRatio.
The maximum generic audio port number is also bound by a maximum port value of
4000 prior to Release 20.0 and 9500 in Release 20.0 and later. Generic audio ports
are divided between IVR and conferencing as governed by the ivrResourceRatio.
7.1.4.1
Media Server Audio Port Weightings

Media Server port usage is weighted. A port can provide interactive voice response (IVR)
or conferencing functions. Ports for different codecs, fax, and video are weighted in
proportion to the resources used relative to the G.711 codec. The following table outlines
the various ports weighting for different codecs.
Codec
Weighting
G.711 IVR
G.711 Conferencing
G.722 IVR
G.722 Conferencing
G.726 IVR
G.726 Conferencing
G.729 IVR
G.729 Conferencing
1.5
6
1.25
2
1.7
8
AMR-NB IVR
2.5
AMR-NB Conferencing
11
AMR-WB IVR
AMR-NB Conferencing
23
Video IVR
FAX
EVRC-A IVR
EVRC-A Conferencing
14
EVRC-NW IVR
12
EVRC-NW Conferencing
56
The number of RTP sessions is limited to 4000 on a bare metal system and 1000 on a
virtualized system.
A 4000 port Media Server could support 4000 G.711 ports or 3200 (4000/1.25)
G.726 ports.
01-BD5003-00
PAGE 51 OF 95
7.1.5
Video Calculation Rules

Video resources are split between video transcoding and video conferencing.
In Release 20.0 and later, the number of processes available for video transcoding is
affected by the parameter videoTranscodingResourcesRatio. This is the percentage of
video processes that are available for transcoding. For example, if numVideoProcesses is
12 and videoTranscodingResourcesRatio is 25, then three processes are available for
video transcoding. The remaining processes are available for video conferencing.
Prior to Release 20.0, all video processes are available for video transcoding.
7.1.5.1
Video Transcoding Rules

The Media Server implements video transcoding in a set of processes separate from the
media streaming processes that are used for audio/video IVR and Conferencing. When a
media streaming process needs a video file transcoded, it hands that file off to a
transcoding process that transcodes the file, which is then played back by the media
streaming process.
The number of simultaneous transcodings is equal to the number of transcoding
processes configured on the server. Prior to Release 20.0, this is equal to the number of
video processes that are computed as described above. In Release 20.0 and later, this is
a function of the videoTranscodingResourcesRatio parameter.
For example, if numVideoProcesses is 12 and videoTranscodingResourcesRatio is 25,
then three processes are available for video transcoding. The remaining processes are
available for video conferencing.
Although the number of simultaneous transcodings is limited to the number of video
processes, the actual transcoding time is a fraction of the actual file size. For example, a
30-second H.264 CIF file is transcoded in approximately two seconds. The transcoding
time to playback time ratio for different target codec values is provided in the following
table.
Environment
Transcode Time to Playback Time Ratio
H.264 CIF
1/14
H.264 QCIF
1/23
H.263 CIF
1/41
H.263 QCIF
1/55
Given that transcoding is a fraction of playback time, a given transcoding process is only
involved in a fraction of the actual call hold time and can thus successively deal with many
calls within an average hold time. For example, if the average call hold time for a Media
Server call requiring transcoding is 30 seconds with a 20-second playback file requiring
H264 CIF transcoding, the transcoding time for the 30-second call would be (20/14) 1.4
seconds. Therefore, in that 30-second call hold time window, this transcoding process
could theoretically handle 21 other transcodings given an even distribution of calls.
In addition, the Media Server caches transcoded files. Therefore, a file that was
previously transcoded does not require re-transcoding. This reduces the number of actual
transcodings required on the system as greetings and prompts caching hits a steady state
over a period of time.
01-BD5003-00
PAGE 52 OF 95
The BroadWorks System Capacity Planner [2] can be used to help calculate the number
of Media Servers and video processes per Media Server that would be required based on,
a) target transcoding environment, b) overall video penetration, c) video-enabled service
penetration rate, and d) average file size.
7.1.5.2
Video IVR Rules

Video IVR consumes two audio IVR ports.
7.1.5.3
Video Conferencing Rules

The number of video conferencing ports is calculated from the resources remaining on the
server after allocating resources for audio IVR/conferencing and video transcoding.
The number of processes available for video conferencing is affected by the
videoTranscodingResourcesRatio parameter. For example, if numVideoProcesses is 12
and videoTranscodingResourcesRatio is 25, then nine processes are available for video
conferencing.
The number of video conferencing ports is calculated from the overall port number
calculated above and is equal to the number of ports multiplied by the ratio of video
conferencing processes to the total number of processes. For example, if 9 out of 16
CPUs are used for video conferencing and there are 9000 generic ports, then 5062 video
conferencing ports are available.
7.1.5.4
Media Server Video Conferencing Port Weightings

The following table outlines the various port weighting for different video codecs.
Video conferencing port weights are measured separately for conferencing services and
monitoring services at the following steps in resolution.
7.1.6
Resolution
Conferencing Services
Monitoring Services
CIF
70
195
4 CIF
185
430
720p HD
330
850
Viewing Media Server Port Assignments

The number of ports assigned at Media Server start-up can be viewed in the start-up
created msfeXX.log file located in /var/broadworks/logs/mediaserver0.
7.1.7
Playout and Recording Memory Usage Rules

The Media Server requires memory for media playing and recording. The IVR memory
maximum is statically defined under MS_CLI/Service/IVR> parameter memorySize.
When memorySize is set to automatic, the Media Server attempts to calculate IVR
memory based on the available shared memory on the server. Memory usage depends
on the codec sampling rate used in the call.
G.711 sampling rate 8 KBps
01-BD5003-00
PAGE 53 OF 95
AMR sampling rate 1.5 KBps
Video sampling rate 80 KBps
The following describes how the Media Server memory behaves for audio and video
playout, as well as voice messaging recording:
Playout Memory Requirements: IVR memory usage for IVR playout actions such as
announcements or treatments, Music On Hold, or IVR prompts is as follows:
Memory_Usage = length_of_file_in_sec x (Codec_Sampling_Rate)
This works out to approximately 500 KB per minute for G.711 audio and 5 MB per minute
for video. IVR memory is released as soon as the file playout ends.
Voice Mail Recording: IVR memory usage for voice mail recording is as follows:
memory_usage = (length_of_greeting_in_sec x Codec_Sampling_Rate) +
(min_duration_of_recording_in_sec x (2*Codec_Sampling_Rate))
where min_duration_of_ recording_in_sec is 60 seconds
The Media Server reallocates 60 seconds worth of memory for each recording. Once
used up, the Media Server allocates memory in 30-second increments until the recording
ends or maximum recording length (configured on the Application Server) is reached. In
general, 60 seconds is a good value to use in calculations for general recording memory
usage.
On greeting playout, memory is released when the greeting playout ends. For memory
used by recording, memory is released when the recording sessions end (around send
mail time).
A good rule of thumb for a G.711 voice mail recording is 1 MB per recording.
7.2
Video Server Engineering Rules

Video Servers are limited to a number of generic ports that are derived using the following
algorithm:
MaxPorts = #_of_CPU X CPU_Frequency/3
where the #_of_CPU and CPU_Frequency are those provided by cat
/proc/cpuinfo. CPU_Frequency is expressed in MHz (for example, 3 GHz would be
3000 MHz).
The Video Server uses port weightings similar to the Media Server to determine the
number of supported RTP streams.
Resolution
Weight
CIF or smaller
120
4CIF or smaller
345
720p HD or smaller
520
Audio codecs vary by computational complexity and are thus weighted differently. There
is a separate set of weights for audio mixing versus IVR. The Capacity Planner is not
currently taking into account the IVR usage because it is assumed to be minimal
compared to the mixing usage.
Codec
Mixing Weight
IVR Weight
u-law, A-law
01-BD5003-00
PAGE 54 OF 95
7.3
Codec
Mixing Weight
IVR Weight
G.722
9.3
1.8
G.729
1.7
Replication Bandwidth Requirements

Both the Application Server and Network Server use database and file replication across
potentially geographically distributed servers. The replication bandwidth requirements are
detailed in this section.
7.3.1
Application Server Replication Bandwidth Requirements

The Application Server replicates the following dynamic data: Basic call logs,
registrations, and media files. In addition, provisioned subscriber data (for example, users,
groups, user service configuration) is also replicated.
A general guideline for replication bandwidth is approximately 1500 Kbps per Application
Server cluster.
For a detailed calculation specific to a given deployment, the amount of bandwidth can be
computed based on traffic volume.
Approximately 1400 bytes of bandwidth is required to replicate a single call log or
registration. The bandwidth to replicate media files depends on the frequency at which
these files are uploaded and their size.
These are the busy hour assumptions for the following example:
33 calls per second (CPS)
50% external incoming calls
50% external outgoing calls
50% of users with Basic Call Log feature assigned
15 registrations per second (RPS)
Media files:
Number of files uploaded in busy hour = 1000
Average media file size = 160 KB (20 seconds u-Law)
File synchronized interval = 30 seconds
Provisioning
Number of provisioning modification transactions per second = 6.6
Number of bytes per transaction = 1,000
Value
Formula
Example
Steady State
Replication Bandwidth
1 KB per second
1 KB per second
Call Replication
Bandwidth
(Percent incoming network calls +

percent outgoing network calls + 2 *
Percent internal calls) * CPS * Basic
call log feature penetration * 1400
= (0.5 + 0.5 + (2 * 0)) *

(33 * 0.5 * 1400) = 23.1
KB per second
Registration
RPS * 1400
= 15 * 1400 = 21 KB per
second
01-BD5003-00
PAGE 55 OF 95
Value
Formula
Example
File Replication
Bandwidth
File synchronized interval * Number

of files uploaded in busy hour/3600 *
Average file size
= (1000 / 3600) * 160 =

44 KB per second
Provisioning
Provisioning modification TPS * 1k
= 6.6 * 1K = 6.6 KB per

second
Total Replication
Bandwidth
Sum of above values
= 1 + 23.1 + 21 + 44 +
6.6 = 89 KB per second
In the above example, the Application Server busy hour peer-to-peer bandwidth
requirements would be 89 KBps or (89 KBps * 8 bits) = 712 Kbps.
7.3.2
Network Server Replication Bandwidth Requirements

The Network Server has less demanding bandwidth requirements. The data that is
replicated is user hosting information (that is, whether the user is hosted on the primary or
secondary server). This hosting information only changes when a user migrates from one
Application Server peer to the other Application Server peer (for example, when there is a
primary Application Server failure). In addition, this migration replication data is bursty in
nature. When a primary Application Server fails, each users device migrates to the
secondary server on their next call, therefore, the Network Server receives migration
reports from the secondary server at the same call rate as the user calls migrate to the
secondary and replicates them at that same rate. (Note that the Network Server does
have throttling that limits user migration replication events to 100 per seconds.) This
migration update ends when all users have migrated to the secondary server. For
example, if a primary Application Server with 50 K users fails at busy hour with 33 CPS, it
would take ~(50K/33) or ~1,500 seconds until all users are migrated to the secondary
server. The Network Server replication traffic would increase during those 1,500 seconds
and return to normal afterwards. Replication of this information is approximately 560 bytes
per migration.
The following example calculates the bandwidth requirements when a single primary
Application Server fails at busy hour. The assumptions for the following example are:
An Application Server with 100 K users experiences a primary server failure at busy
hour when traffic rates are at 55 CPS.
There are four Network Server nodes in the Network Server cluster.
Value
Formula
Example
Steady State
1 KB per second
1 KB per second
User Hosting
Migrations per second per cluster (up

to a maximum of 100) * Number of
simultaneous failed Application
Server clusters * 560
= 55 * 1 * 560 = 31 KB
per second
between the source
Network Server and
any one peer
Sum of above
TOTAL Replication
Bandwidth required
from the source
Network Server to
ALL peers
(Number of Network Server nodes

1)* User hosting replication
bandwidth.
= 31K + 1K = 32 KB
= 32K * 3 = 96 KB
01-BD5003-00
PAGE 56 OF 95
In this example, the steady state busy hour replication bandwidth between a Network
Server and its peer is ~1 KBps or 8 KBps. In the event of a single Application Server
cluster resulting in a mass migration of users at busy hour, the replication bandwidth
requirement between peers would increase to 32 KBps or 256 KBps, but only for the time
required to migrate all users (for example, ~100K/55 CPS = 1,800 seconds).
7.4
BroadWorks Unified Messaging Storage Server Requirements

The BroadWorks Unified Messaging service allows for voice, video, and/or fax messages
to be deposited in a users account. A user can then retrieve these messages via the
BroadWorks voice portal and/or have them delivered as e-mail attachments. The Unified
Messaging service uses standard Simple Mail Transfer Protocol (SMTP) to deposit the
message to the store and either POP3 or IMAP for mail retrieval. As such, BroadWorks
supports any standard mail server for the storage repository, for user messages.
This section outlines the engineering requirements for the Unified Messaging storage
server. It explains how to calculate the total storage and overall bandwidth required for the
entire BroadWorks system. The output from the rules can then be used to derive the perstorage server requirements, which would depend on the Unified Messaging storage
architecture (that is, a single centralized clustered mail server or distributed N Application
Server to M mail servers mapping).
7.4.1
Message Storage Requirements

BroadWorks messages have the following per-message footprint.
Voice messages (Voice_Size) 330 KB/minute for G729/G711,

2,600 KB/minute for G722
Video messages (Video_Size) 2.2 MB/minute
Fax messages (Fax_Size) 100 KB/minute
To simplify the following calculations, we assume that fax messaging (if present) is folded
into standard voice messaging.
7.4.1.1
User Account Size Quota

A users mail server account size quota setting must be set to support the Application
Server defined Full Mail Limit, which defines the maximum number of storage minutes
per user. This parameter can be set at a system level via parameter
AS_CLI/Service/VoiceMsg> maxMailboxLength, and can be overwritten at the enterprise,
group, and user levels.
A users account quota can be derived from the per-message footprint and the
maxMailboxLength setting. It is best practice to add one minute to the maxMailboxLength
to ensure that no message is unexpectedly lost due to a quota limit being hit. The peruser account quota setting can be calculated as follows (10-minute maxMailboxLength
and ulaw are used in the example):
Voice messaging-enabled user:
voice_quota = (maxMailboxLength +1) * Voice_Size = (10 +1) * 330 KB/min = 3.6 MB
Video messaging enabled user:
video_quota = (maxMailboxLength +1) * Video_Size = (10+1) * 2.2 MB/min = 24 MB
01-BD5003-00
PAGE 57 OF 95
7.4.1.2
Total Storage Requirements

The total message storage required to support the entire system depends on the
acceptable oversubscription factor. Even though each user has an account quota set (for
example, 3.5 MB), it would be unlikely that all users would fill the quota. Therefore,
dimensioning the server to support maximum quota for all users would result in unused
storage. In general, one would oversubscribe the storage to reduce unused storage. The
oversubscription factor would depend on the carriers requirement, but an oversubscription
factor of 50% would be conservative for a voice messaging environment.
The total storage required would be calculated as follows:
no_users Number of users on the system
um_voice_penetration Percentage of users with Unified Messaging voice
um_video_penetration Percentage of users with Unified Messaging video
oversub_factor Oversubscription percentage (for example, assuming that each user

would only use half his or her quota, the over_sub_factor would be 50%.
total_storage = (no_users * oversub_factor) * [(um_voice_penetration * voice_quota) +

(um_video_penetration * video_quota)]
For example, a 50 K residential system with 100% voice messaging penetration, per user
voice quota of 3.6 MB and an acceptable oversubscription factor of 50% would require the
following storage:
total_storage = (50 K * 0.5) * [(1 *3.6 MB) + (0 *2.2 MB)] = 90 GB
7.4.2
Busy Hour Messaging Throughput

The overall bandwidth throughput requirements to/from message storage depend on a
number of variables:
AS_CPS Estimated busy hour call per second
total_AS_ Total number of Application Server clusters in the system
%_incoming _calls Percentage of incoming calls (default of 50%)
%_Unanswered_incoming_calls Percentage of incoming calls that are unanswered

(default of 45%)
%_Busy_incoming_calls Percentage of incoming calls that are busy (default of 5%)
%_Diverted_call_deposited Percentage of unanswered/busy incoming calls that

actually result in a message deposit (default 30%)
%_retrieval_to_deposit_ratio Ratio of how many message retrievals there are permessage deposit (default 50%)
Avg_msg_length Average length of the deposited message (default 30 seconds)
With the above variables, the number of overall messages in/out can be calculated as
follows:
msg_in/sec = (AS_CPS * total_AS) *(%_incoming _calls *
(%_Unanswered_incoming_calls + %_Busy_incoming_calls)) *
%_Diverted_VM_call_deposited
msg_out/sec = (AS_CPS * total_AS) *(%_incoming _calls *
(%_Unanswered_incoming_calls + %_Busy_incoming_calls)) *
(%_Diverted_call_deposited * %_retrieval_to_deposit_ratio)
01-BD5003-00
PAGE 58 OF 95
For example, with the following variables:
AS_CPS 72
total_AS_ 5
%_incoming _calls 50%
%_Unanswered_incoming_calls 45%
%_Busy_incoming_calls 5%
%_Diverted_call_deposited 30%
%_retrieval_to_deposit_ratio 50%
Avg_msg_length 30 seconds (.5 min)
The busy hour messages rates would be:
msg_in/sec = (72 *5) *(0.5 *(0.45 +0.05)) *(0.3) = 27 messages in/sec
msg_out/sec = (72 *5) *(0.5 *(0.45 +0.05)) *(0.3 *0.5) = 14 messages in/sec
The overall traffic throughput can be calculated per-message footprint as follows:
bytes_in/sec = msg_in/sec * [(um_voice_penetration *(330 KB * Avg_msg_length)) +

(um_voice_penetration *(2.2 MB * Avg_msg_length))]
bytes_out/sec = msg_out/sec * [(um_voice_penetration *(330 KB * Avg_msg_length))

+ (um_voice_penetration *(2.2 MB * Avg_msg_length))]
For the above examples, the overall traffic throughput attributable to message storage
would be:
bytes_in/sec = 27 * [(1 *(330 KB * 0.5)) + (0 *(2.2 MB * 0.5))]= 4.4 MBps
bytes_out/sec = 14 * [(1 *(330 KB *0.5)) + (0 *(2.2 MB * 0.5))]= 2.2 MBps
It is important to note that the bytes_in/sec flows between the storage and all Media
Servers, while the bytes_out/sec flows between the storage and all Application Servers.
7.5
Service Control Function Network Requirements

The Service Control Function (SCF) redundancy deployment model requires that Service
Control Function Servers be deployed in pairs. The Service Control Function Server
peers can be deployed in a geo-redundant fashion and require a round-trip delay latency
of <150 msec and packet loss of <1% between peers.
BroadSoft supports three Service Control Function hardware footprints that support a
maximum of 750, 1500, and 3000 Mobile Application Part (MAP)/CAMEL Application Part
(CAP) transactions per second (TPS) respectively. In general, Service Control Function
Server pairs are deployed in a load-balanced manner. In failover, each Service Control
Function Server pair member needs to be able to handle the total system-rated traffic. As
such, a Service Control Function Server pair is rated to a maximum of 3,000 transactions
per second.
Service Control Function bandwidth requirements vary based on traffic. The following
table represents the bandwidth requirements for the three rated server traffic levels. The
inter-SCF peer bandwidth requirements listed represent steady state.
01-BD5003-00
PAGE 59 OF 95
SCF Rated Traffic (TPS)
Total Bandwidth
Inter-SCF Peer Bandwidth
750
Tx: 7 MBps
Tx: 1.25 MBps
Rx: 5 MBps
Rx: 1 MBps
Tx: 15 MBps
Tx: 2.5 MBps
Rx: 10 MBps
Rx: 2 MBps
Tx: 30 MBps
Tx: 5 MBps
Rx: 20 MBps
Rx: 4 MBps
1500
3000
01-BD5003-00
PAGE 60 OF 95
Server Provisioning Guidelines

This section outlines Application Server and Network Server provisioning guidelines.
8.1
Application Server Provisioning Guidelines

To ensure proper scaling of an Application Server, the following provisioning guidelines
should be taken into consideration.
Items
Recommended Guideline
System Level Items
Total number of DNs
Number of service providers/enterprises
Up to three times the maximum number of

subscribers
Up to the maximum number of subscribers
(Note that prior to Release 14.sp4, the
maximum number of enterprises was rated
at <1000.)
Number of communication barring (fixed)

profiles/network class of service
Number of communication barring criteria
Number of system domains
Number of system-level OCP digit maps
Number of criteria per communication baring profile
<1000
<100
Service Provider/Enterprise Items
Number of groups
Number of devices
Number of administrators
Number of departments
Number of service packs
Enterprise trunks
Session Admission Control groups
Number of communication baring (hierarchical)

profiles
Device profiles per Session Admission Control group
Number of disposition/unavailable codes
Up to the maximum number of subscribers

<1000
Group Level Items
Number of users
<30000
01-BD5003-00
PAGE 61 OF 95
Items
Number of group administrators
Number of departments
<1000
Number of holiday and time schedules
Auto Attendants
Call Pickup groups
Hunt groups
Conference Bridges
Call Capacity groups
Call Centers
Instant Group Call groups
Series Completion groups
Trunk groups
Session Admission Control groups
Authorization codes
Users per service group (Call Pickup, Hunt Group,

Call Center, Series Completion)
Users per Account Authorization Code

restricted/non-restricted list
Device profiles per Session Admission Control group
Number of disposition/unavailable codes
Receptionist/Attendant Console Number of

monitored users
<500
Digit strings for outgoing calling plan (ODP)
<100
Number of emergency zones
Group Paging targets
User Level Items
Number of available phone numbers for assignment
Number of departments to select from
Number of available devices
Number of time schedules
Number of conferences
Number of recordings
Number of call centers for which a user is an

agent/supervisor
Number of agents per route point
Number of Call Notify entries
Number of Call Forwarding Selective entries
Number of Selective Acceptance entries
Number of Selective Rejection entries
Number of Custom Ringback user entries
Number of Priority Alert entries
Number of monitored users in Phone Status

Monitoring
Number of aliases for messaging
Number of Simultaneous Ringing Personal criteria
<1000
<100
01-BD5003-00
PAGE 62 OF 95
Items
entries
8.2
Number of phone numbers in a distribution list
Number of personal phone list entries
Network Server Provisioning Guidelines

To ensure proper scaling of a Network Server, the following provisioning guidelines should
be taken into consideration.
Items
System Level Items
Total number of DN/URLs/Login aliases
<30 million
Total number of enterprises
<10 million
Total number of groups
<10 million
Total number of network elements (NEs)
Policy Related Items
Number of VoiceVPN dial plan entries per instance
Number of policy route list entries per instance
<32 K
<32 K
01-BD5003-00
PAGE 63 OF 95
Server Performance Guidelines

Although there is no one indicator of a servers overall general health, there are a number
of key resource and performance indicators that can be used to gauge a servers health
and performance. The following sections outline the guidelines for key resource and
performance indicators. Detailed information on how to collect these key resource and
performance indicators is located in section 18 of System Monitoring, in the BroadWorks
Maintenance Guide. There is a version of this document for each BroadWorks major
release.
This section is divided into the following subsections:
Key Resource Indicator Guidelines
Application Server Key Performance Indicator Guidelines
Network Server Key Performance Indicator Guidelines

NOTE: A reading outside the documented guidelines that follow is not necessarily an indication
that a server is performing poorly. However, it should trigger an investigation as to the root
cause of the issue.
9.1
Key Resource Indicator Guidelines

The following resource guidelines are true for all BroadWorks servers.
9.1.1
CPU Usage
A quick and easy indicator of any servers health is averaged CPU usage. Averaged
CPU usage can be obtained using SAR or vmstat. A five-minute averaging window is
recommended. Averaged Busy CPU time is calculated by adding %usr (User time) +
%sys (System time).
NOTE: A one-time reading that moves a server into another range for one five-minute interval
can usually be ignored as an anomaly, unless the high reading occurs regularly. For example,
the majority of averaged busy CPU readings are <60%, but periodically throughout the day, the
reading increases to 75% busy. This 75% high water value spike should be used to identify the
servers operating range since at that given time interval, the server is susceptible to the issues
associated with that operating range.
Operating Range
Acceptable
Averaged Busy CPU

60%
Comment
No resource bottleneck.
Server has sufficient CPU resources to handle

growth.
There should be no issue upgrading this server.
Server growth should be capped near the higher

end of the range.
01-BD5003-00
PAGE 64 OF 95
Operating Range
Marginal
Poor
Critical
Averaged Busy CPU

> 60% AND < 70%
70% AND < 85%
85%
Comment
Possibility of bottleneck at higher ends of the range.
BroadWorks normal operation is generally not

impacted.
Server growth needs to be capped.
Low probability at higher ends of the range of a

system outage event occurring due to sporadic
resource exhaustion.
Possibility of recouping CPU through server

tuning.
Upgrading this server depends on an analysis of

all server performance indicators.
Significant bottleneck.
BroadWorks normal operation is probably

impacted.
Moderate probability of a system outage event

occurring due to sporadic resource exhaustion.
Server growth needs to be halted.
Possibility of recouping CPU through server

tuning.
CPU relief may require either hardware upgrade or

user migration.
This server should not be upgraded.
Critical bottleneck.
BroadWorks normal operation is definitely

impacted.
High probability of a system outage event

occurring due to sporadic resource exhaustion.
CPU relief required through either hardware

upgrade or user migration.
This server should not be upgraded.
NOTE: Application Server clusters using provisioning to secondary capability need to ensure
that the combined CPU Busy usage for both the primary and secondary servers do not surpass
the guidelines listed above.
Network Server clusters need to ensure that in the event of the failure of one of the Network
Servers, the other Network Servers in the cluster can handle the CPU usage of the down server.
For example, in a two Network Server cluster, each Network Server should be able to handle the
combined CPU usage of both Network Servers.
9.1.2
Paging
Excessive paging on a server can impact resource usage and in turn impact BroadWorks.
Memory usage can be impacted by non-application specific events (for example, opening
a CLI session, using a VI editor to edit a large file, compressing/zipping files). In ideal
circumstances, a BroadWorks server does not undergo paging.
01-BD5003-00
PAGE 65 OF 95
The SAR utility can be used to obtain five-minute averaged paging rates (pswpin/s).
Constant non-zero values on any server should be an indication that more memory is
required. The impact of periodic spikes depends on the value. In these cases, the high
value spike should be used. For example, every day there are a few non-zero readings
with the high being 55. The 55 reading should be used to identify the operating range.
NOTE: A one-time reading can usually be ignored as an anomaly. For example, pgscan/s and
pswpin/s is always 0.00 except for one five-minute period on one day.
Operating Range
Ideal
Acceptable
pswin/s
0.00
Periodic 1
Comment
The server is not paging and does not need more
memory.
The server generally has enough memory.
The few paging spikes that do occur, do not impact
performance.
Poor
Periodic >1 AND 2

AND/OR constant
paging
This server may require more memory if the situation

is not addressed.
Scan rates in this range should in general, not impact
performance, but should be addressed.
For periodic spiking, an investigation should identify
the root cause of the paging.
Critical
Periodic 2
AND/OR constant
paging
This server requires more memory if the situation is

not addressed.
Scan rates in this range may affect performance and
they should be addressed.
For periodic spiking, an investigation should identify
the root cause of the paging.
9.1.3
Disk Activity
Although BroadWorks applications tend not to be I/O blocking, excessive disk activity can
be an indication of too much I/O traffic such as when writing to disk. Excessive writing to
disk can be caused by a number of activities that can be corrected, such as logging levels
set too high for a server. It is important to monitor disk activity to ensure that disks are not
bottlenecked.
Disk activity can be monitored using the iostat utility by collecting five-minute averaged
readings on average disk service time and average disk busy. The svctm (average
service time of the disk) and %util (percentage of time the disk is busy) parameter
provides an indication of disk activity.
01-BD5003-00
PAGE 66 OF 95
Operating Range
Ideal
Disk Busy and Service Time

% disk busy 20% AND ServiceTime 20
ms
Marginal
Poor
9.2
% disk busy > 20% AND (20 ms <

ServiceTime 30 ms)
% disk busy > 20% AND ServiceTime > 30
ms
Comment
The server I/O function is
operating normally.
The I/O functions may be
bottlenecked, but the application
should not be impacted.
The I/O functions are
bottlenecked; need to check
thread blocking to see if
application is impacted.
Application Server Key Performance Indicator Guidelines

This section outlines Application Server specific performance indicators.
9.2.1
Execution Server Heap Usage

The Application Server Execution Server (XS) process is assigned a fixed amount of heap
memory at start-up. The heap usage grows over time until Java cleans up the heap with a
full garbage collection. The Application Server Execution Server (XS) heap is cleaned up
whenever the heap reaches 68% of maximum allocated heap.
The heap size after the full collection represents the actual heap required to support the
users and active calls at the time. It is important that the post cleanup heap does not grow
to 68% of the maximum allocated heap or the heap ends up in a full collection loop, which
severely impacts server performance.
The post Java garbage collection heap size needs to be monitored daily and should
always be 60% of the allocated heap. As the heap increases towards 60%, it may be
possible to increase the maximum allocated heap by adding more memory to the server.
Allocated heap size can be increased to a maximum of 8 GB with 32 GB of physical
memory present.
Post-Collection Heap Size Guidelines
60% of allocated heap size
Comment
Execution Server post-collection heap size should
not surpass 60% of allocated permanent size.
Maximum allocated heap size = 8 GB (32 GB RAM)
9.2.2
Database Usage
The Application Server TimesTen database is assigned a fixed permanent size allocation
at installation. The database grows as the system scales. It is important that the
database permanent size in use does not grow beyond 90% of the maximum allocated
permanent size.
The database allocated permanent size is set at installation and should not be set to
greater than 38% of available physical memory.
Database Permanent Size in Use Guidelines
90% of allocated permanent size
Comment
Database size should not surpass 90% of allocated
permanent size.
Maximum allocated permanent size =
12 GB (32 GB RAM)
01-BD5003-00
PAGE 67 OF 95
9.2.3
SIP/MGCP Messages per Second

Excessive SIP and Media Gateway Control Protocol (MGCP) messaging can impact
server performance. The more messages that are processed, the more system resources
are required. The amount of traffic a server can handle is dependent on hardware
platform.
For SIP, there is a distinction between call processing related messages and ancillary
messaging (for example, REGISTER, OPTIONS, SUBSCRIBE, NOTIFY). In general,
ancillary SIP traffic should be kept to a minimum. Ideally, the only ancillary SIP traffic
would be REGISTERs and we would expect no more than two REGISTERs an hour per
user.
The ideal Application Server messages per second (MPS) for a SIP user base can be
calculated as follows:
Expected MPS= (CPS * 16) + (NoSipRegisteringUsers *4)/3600
where CPS can be obtained from the busy hour bwCallpCallsPerSecond reading.
For example, an Application Server cluster with 30,000 SIP registering users and a
measured CPS of 12 would ideally have the following message rate:
(12 * 16) + (30000 * 4)/3600 = 225 MPS
Of course the number may be high due to higher than normal registration rate or other
ancillary SIP traffic (for example, OPTIONS, SUBSCRIBE/NOTIFY). If it is substantially
higher, it impacts the growth of the server up to the point that the server no longer
operates in an acceptable MPS range.
MPS is calculated by summing up all SIP UDP and TCP ins/outs and MGCP
command/response in/out messages and dividing by the collection period in seconds
(Total_MPS = SIP_MPS + MGCP_MPS). As a guideline, the acceptable Application
Server total MPS rate is as follows:
Platform
Intel Xeon 4 CPU Units
Maximum Calls Per Second
Acceptable MPS Range
18.75 per CPU Unit
675 per CPU Unit
Although not a hard resource limit such as CPU usage, operating the server above
Acceptable Total MPS Range reduces server capacity. Operating a server substantially
higher (for example, > 50% over) can push the server CPU usage into the Poor or Critical
range.
9.2.4
OCI Provisioning Transactions per Second

Excessive provisioning traffic impacts server performance. Provisioning traffic can be the
result of the following:
Administrative provisioning via external provisioning system, web, or CLI
User web traffic
User client traffic
All provisioning traffic, regardless of the source, uses the OCI-P interface. OCI
transactions per second can be derived by dividing the OCI-P total transactions collected
by the collection period in seconds.
01-BD5003-00
PAGE 68 OF 95
As a rough guideline, the acceptable Application Server OCI PTPS rate for the general
categories of server platforms are as follows:
Platform
Maximum OCI PTPS
Acceptable OCI PTPS Range
Intel Xeon
18.75 per CPU Unit
18.75 per CPU Unit
Although not a hard resource limit like CPU usage, operating the server above the
Acceptable OCI TPS Range reduces server capacity. Operating a server substantially
higher can push the server CPU usage into the Poor or Critical range.
9.2.5
Call Processing Delays

Delays in any of the Application Server primary internal queues impact the end-user
experience. If the delays become too large, the result may be a traffic flood that drives up
the servers resource usage, potentially forcing the server into a CPU operating range of
Poor or Critical.
A good method of obtaining a sense of primary queue delay health is to monitor average
and maximum high water mark SIP and MGCP call setup and call answer times. These
Simple Network Management Protocol (SNMP)-enabled gauges provide a view of the
end-to-end delay though all internal queues and are as follows.
bwSipStatsSetupSignalDelay This gauge measurement is intended to reflect the

average elapsed delay between receipt of the call setup signal from the caller and
transmission of the call setup signal to the called party. Delays incurred by a query to
an external element (for example, dip to the Network Server, CNAME query) are part
of the measurement commonly referred to as Cross Office Delay.
bwSipStatsAnswerSignalDelay This gauge measures the average time (in

milliseconds, based on a rolling average of up to100 samples) between the receipt of
a 200 OK message indicating answer or an NTFY off-hook indicating answer and the
transmission of a 200 OK indicating answer to the originator. This measurement is
intended to reflect internal queuing, scheduling, and processing delays.
bwMGCPStatsDialToneDelay This gauge measures the average time (in

milliseconds) between receipt of NTFY indicating off-hook and transmission of
notification request (RQNT) indicating dial tone and request for digits.
bwMGCPStatsSetupSignalDelay This gauge is applicable to MGCP-originated

calls. It measures the average time (in milliseconds) it takes between the receipt of a
NTFY message with digits dialed for the origination of a new call and the transmission
of one of the following:
an INVITE (SIP terminator),
an RQNT (MGCP terminator with in-band ringback), or
a Create Connection (CRCX) (MGCP terminator without in-band ringback)
to the primary device of the original called party (for an intra-group call) or to the
network element of the original called party (for a call to the PSTN). Delays incurred
by a dip to the Network Server are removed from the measurement. This
measurement is intended to reflect internal queuing, scheduling, and processing
delays.
01-BD5003-00
PAGE 69 OF 95
bwMGCPStatsAnswerSignalDelay This gauge measures the average time (in

milliseconds) between the receipt of a 200 OK message indicating answer or an
NTFY off-hook indicating answer and the transmission of an Modify Connection
(MDCX) indicating answer to the originator. This measurement is intended to reflect
internal queuing, scheduling, and processing delays.
Each of the above average delays should be polled and reset every 15 minutes. A
one-time high reading can be discarded. Average delay times should be within the
following guidelines.
Gauge
Queue Averages (msec)
bwSipStatsSetupSignalDelay
50
bwSipStatsAnswerSignalDelay
20
bwMGCPStatsDialToneDelay
20
bwMGCPStatsSetupSignalDelay
50
bwMGCPStatsAnswerSignalDelay
20
For maximum high water mark delays readings, the rolling daily distribution of all
maximum high water mark delays should be polled and reset every 15 minutes and
compared to the following acceptable ranges.
Distribution Percentage of Readings
Acceptable Range
80%
500 msec
95%
1.5 sec
100%
2.5 sec
0%
> 2.5 sec
A server performing above the acceptable range could be an indication that the server is
over capacity. In general, other indicators such as CPU usage provide the same result. A
server that is not nearing capacity, but reporting high maximum delay queue statistics may
be experiencing other non-performance related issues. (BroadSoft should be contacted to
help identify the root cause).
9.3
Network Server Key Performance Indicator Guidelines

This section outlines Network Server specific performance indicators.
9.3.1
Execution Server Heap Usage

The Network Server Execution Server (XS) process is assigned a fixed amount of heap
memory at start-up. The heap usage grows over time until Java cleans up the heap with a
full garbage collection. The Network Server Execution Server heap is cleaned up
whenever the heap reaches 68% of maximum allocated heap.
The heap size after the full collection represents the actual heap required to support the
users and active calls at the time. It is important that the post cleanup heap does not grow
to 68% of the maximum allocated heap or the heap ends up in a full collection loop, which
severely impacts server performance.
01-BD5003-00
PAGE 70 OF 95
The post Java garbage collection heap size needs to be monitored daily and should
always be 60% of the allocated heap. As the heap increases towards 60%, it may be
possible to increase the maximum allocated heap by adding more memory to the server.
Allocated heap size can be increased to a maximum of 8 GB with 32 GB of physical
memory present.
Post-Collection Heap Size Guidelines
Comment
60% of allocated heap size
Execution Server post-collection heap size should

not surpass 60% of allocated permanent size.
Maximum allocated heap size =
8 GB (32 GB RAM).
9.3.2
Database Usage
The Network Server TimesTen database is assigned a fixed permanent size allocation at
installation. The database grows as the system scales. It is important that the database
permanent size in use does not grow beyond 90% of the maximum allocated permanent
size.
The database allocated permanent size is set at installation and should not be set to
greater than 48% of available physical memory. By default, database temporary size
should be sized to 1/6 of permanent size.
Database Permanent Size in Use Guidelines
90% of allocated permanent size
Comment
Database size should not surpass 90% of
allocated permanent size.
Maximum allocated permanent size =
24 GB (48 GB RAM).
9.3.3
SIP Messages per Second

Excessive SIP messaging impacts server performance. The more messages that are
processed, the more system resources are required. The amount of traffic a server can
handle is dependent on hardware platform.
As a SIP redirection server from the Network Server perspective, there is little distinction
between call processing-related messages such as INVITEs and ancillary messaging
such as REGISTER redirections.
SIP_MPS is calculated by summing up all SIP UDP/TCP ins/outs and dividing by the
collection period in seconds. As a guideline, the acceptable Network Server total MPS
rate is as follows.
Platform
Maximum Calls Per Second
Acceptable MPS Range
Intel Xeon
188 per CPU unit
675 per CPU unit
Although not a hard resource limit such as CPU usage, operating the server above the
Acceptable Total MPS range reduces server capacity. Operating a server substantially
higher (for example, > 50% over) can push the server CPU usage into the Poor or Critical
range.
01-BD5003-00
PAGE 71 OF 95
9.3.4
Internal Queue Statistics

Delays in any of the Network Server primary internal queues can lead to call routing
delays. If the delays become too large, the result may be a traffic flood that drives up the
servers resource usage, potentially forcing the server CPU usage into the Poor or Critical
operating range.
A good method to use to get a sense of primary queue delay health is to trend both the
average queue time (bwSystemInternalQueueTimeAvg) and the maximum high water
marks (bwSystemInternalQueueTimeMax) over time. For example, each primary queue
average delay and maximum delay could be polled and reset every 15 minutes.
For average queue time delays, the high water average delay value of any of the primary
queues should be used to determine the operating range. A one-time high reading can be
discarded. Primary (queue) average queue times should follow the following guidelines.
Operating Range
Queue Averages (msec)
Comment
Acceptable
25
There is no issue with the average primary queue

delays.
Poor
> 25
The average queue delays are high and need to

be addressed.
This may be the result of a general server
performance or traffic issue.
BroadSoft Support needs to be contacted to
identify the root cause.
For primary queue maximum high water mark delays, the rolling daily distribution of all
maximum high water mark delays should be collected and compared to the following
acceptable ranges.
Distribution Percentage of Readings
Acceptable Range
80%
500 msec
95%
1.5 sec
100%
2.5 sec
0%
> 2.5 sec
A server performing above the acceptable range could be an indication that the server is
over capacity. In general, other indicators such as CPU usage provide the same result. A
server that is not nearing capacity, but reporting high maximum delay queue statistics may
be experiencing other non-performance related issues. (BroadSoft should be contacted to
help identify the root cause).
9.4
Media Server Key Performance Indicator Guidelines

This section outlines Media Server-specific performance indicators.
9.4.1
Jitter
Excessive jitter in the absence of packet loss is often a sign of some network condition (for
example, congestion, queuing delays in network equipment, and so on) preventing RealTime Transport Protocol (RTP) packets from being delivered in a timely manner.
Excessive jitter can lead to voice quality issues.
01-BD5003-00
PAGE 72 OF 95
The Media Server maintains two measurements for jitter, msRtpReceivedPacketJitter, and
msRtpTransmitJitter. Both measurements are in units of microseconds. The
msRtpReceivedPacketJitter measurement is a cumulative measurement tracking the jitter
of incoming RTP voice packets experienced by each RTP session. The
msRtpTransmitJitter measurement is a cumulative measurement tracking the jitter
reported by remote RTP endpoints.
Since these measurements are cumulative, it is important to observe how these
measurements trend over time as more RTP sessions are handled. For a given time
period, the average receive-packet jitter per RTP session and average transmit-packet
jitter per RTP session are calculated as follows.
Average Jitter
Formula
Average receive-packet jitter per

RTP session
(change in msRtpReceivedPacketJitter during time period)/
Average transmit-packet jitter per

RTP session
(change in msRtpTransmitJitter during time period)/
(change in msRtpSessionsCount during time period)

(change in msRtpSessionsCount during time period)
Note that selecting a longer time period may mask large intermittent jitter increases.
Average received packet jitter per RTP session of 40 milliseconds (that is, 40000
microseconds) or less is considered acceptable.
9.5
SNMP Agent Guidelines

All BroadWorks servers contain an SNMP agent that generates traps and can be used for
polling performance measurements. This section outlines SNMP agent-specific
guidelines.
For SNMP trap generation, each BroadWorks server should have alarm throttling enabled
under CLI level CLI/Monitoring/Alarm/Threshold/Default set to 5 traps per second.
For SNMP polling, the recommended maximum gets per second depends on the server
platform.
Platform
Maximum SNMP GETS Per Second
Intel Xeon
15 per CPU unit
01-BD5003-00
PAGE 73 OF 95
10 Application Server Growth Estimation Procedure

The BroadWorks System Capacity Planners [2] packaged and/or manual configuration
inputs provide an excellent mechanism for initial system planning when no existing
BroadWorks infrastructure exists. Once a production Application Server cluster is
deployed and is in-service, this cluster can be used to more accurately estimate the
maximum number of users that this Application Server cluster and any future cluster with
the same hardware footprint and deployment model (service/traffic mix)) will be able to
support.
This section outlines the Application Server growth estimation procedure. This procedure
is based on two key assumptions:
Group/user service footprint remains constant Assigning a new service may

change the resource footprint of the server (for example, adding BroadWorks
AssistantEnterprise client support to all users).
User traffic pattern does not change Per-user Erlang contribution remains at the
same level as the system grows.
A change in either of these two items would require a recalculation of growth estimate.
As described in section 6.1.5 Use Live Data Input, the BroadWorks System Capacity
Planner [2] live input area can be also be used to automate the growth estimate
procedure.
10.1 Growth Estimation Procedure

This simple procedure is because a servers key resource usage increases generally in a
linear fashion as the number of users increase (as long as the per-user service footprint
and traffic pattern remains relatively constant). The key resource indicators that tend to be
growth bottlenecks are:
Execution Server (XS) heap usage
CPU usage
DB permanent size
A server can continue to scale as long as these indicators are within acceptable range.
For performance guidelines, see section 8 Server Provisioning Guidelines. To estimate a
servers growth potential, we first collect information on the above key resource indicators
and the number of current users. Then we can calculate the per-user contribution to these
key indicators and plot out the linear growth of each indicator versus users to see when
each one hits a bottleneck condition (for example, reaching the acceptable limit for that
resource). Since heap size and database size are a function of server physical memory,
these bottlenecks can sometimes be addressed easily by adding more physical memory
to the server (up to the supported 32 GB). CPU resource is a function of the server
platform and tends to be a hard bottleneck.
To use this procedure, you need a certain level of growth to have already occurred on the
cluster so that the key resource indicators can start tracking. In general, on a small
configuration system you could start using this procedure after at least 500 users have
been provisioned, while on a medium to large configuration, these indicators generally
start tracking in a linear fashion after 4,000 to 5,000 users have been provisioned.
01-BD5003-00
PAGE 74 OF 95
10.1.1 Collect Information

The following information should be collected from the primary Application Server since it
should be handling all traffic.
10.1.1.1 Execution Server Post Full Collection Heap Size
From the /var/broadworks/logs/appserver/XSOutputXX.log files, the garbage collection
(GC) line AFTER the lines containing CMS-concurrent-reset: indicates the heap size
after a full garbage collection. Example:
483642.181: [CMS-concurrent-reset: 0.242/0.242 secs]
483644.184: [GC 483644.184: [ParNew: 49024K->0K(49088K), 0.1162924 secs]
842711K->804212K(4194240K), 0.1168831 secs]
804212K is the heap size after a full garbage collection and 4194240K is the maximum
heap size. After this full collection, 804212 /4194240 or 19.1% of the 4 GB heap is in use.
To obtain the post-collection heap size for the purposes of this procedure, a number of
busy-day (days that have the highest traffic)
/var/broadworks/logs/appserver/XSOutputXX.log files should be analyzed. The high value
full post-collection heap sizes can be obtained using a simple awk statement such as:
cat /var/broadworks/logs/appserver/XSOutput24.log |awk '$2=="[CMS-concurrentreset:"{getline;print}' >> post-collection_heap.out
You can now obtain the maximum post-collection heap size from the postcollection_heap.out file. For example, if post-collection_heap.out contains the following:
231662.434: [GC 231662.434:
811655K->791912K(1572800K),
231773.201: [GC 231773.201:
809310K->789781K(1572800K),
231883.193: [GC 231883.194:
821889K->803170K(1572800K),
231993.503: [GC 231993.503:
812462K->793207K(1572800K),
232104.661: [GC 232104.661:
800871K->781200K(1572800K),
232221.538: [GC 232221.538:
806474K->786846K(1572800K),
232335.614: [GC 232335.614:
803134K->783621K(1572800K),
232458.578: [GC 232458.579:
794432K->774487K(1572800K),
232579.809: [GC 232579.809:
789489K->769703K(1572800K),
[ParNew: 24448K->0K(24512K),
0.0858999 secs]
[ParNew: 24448K->0K(24512K),
0.0798135 secs]
[ParNew: 24448K->0K(24512K),
0.0923137 secs]
[ParNew: 24448K->0K(24512K),
0.0686410 secs]
[ParNew: 24448K->0K(24512K),
0.0774966 secs]
[ParNew: 24448K->0K(24512K),
0.0715919 secs]
[ParNew: 24448K->0K(24512K),
0.0856315 secs]
[ParNew: 24448K->0K(24512K),
0.0924747 secs]
[ParNew: 24448K->0K(24512K),
0.0707344 secs]
0.0856301 secs]
0.0795525 secs]
0.0920691 secs]
0.0683859 secs]
0.0772532 secs]
0.0713419 secs]
0.0853518 secs]
0.0922371 secs]
0.0705055 secs]
then 803170 is the maximum post-collection heap size and 1572800 is the configured
maximum heap size.
10.1.1.2 Database Permanent Size
Database permanent size in use can be obtained using the following command sequence.
bwadmin@as1$ ttIsql
Command> dssize;
PERM_ALLOCATED_SIZE:
PERM_IN_USE_SIZE:
1310720
929406
01-BD5003-00
PAGE 75 OF 95
PERM_IN_USE_HIGH_WATER:
TEMP_ALLOCATED_SIZE:
TEMP_IN_USE_SIZE:
TEMP_IN_USE_HIGH_WATER:
936963
348160
4597
71409
The PERM_IN_USE_SIZE parameter shown above indicates that 929 MB is in use out of
1.31 GB (PERM_ALLOCATED_SIZE) available or 71% (929/1310) of the available
database.
10.1.1.3 Worst Case Busy Hour CPU
Worst Case Busy Hour CPU is obtained by analyzing SAR output for a number of busydays. One needs to look for the highest sum that is obtained by adding the following
numbers together: user CPU usage, system CPU usage, and, if this information is
available, nice CPU usage.
Note that any anomaly (for example, a one-time, one-day low reading) should be
discarded. Wait for IO (wio) CPU should not be included. This high reading should occur
during high traffic hours. If the low reading corresponds to a time in which an item such as
a system backup is running, it should be disregarded. If the following represents the CPU
usage peak that in general reoccurs over multiple days:
06:30:00
06:35:00
06:40:00
06:45:00
06:50:00
06:55:00
18
21
19
18
18
20
6
7
6
5
5
6
7
3
3
3
7
3
69
69
73
74
70
71
then the Worst Case Busy Hour CPU is 28%.

10.1.1.4 Provisioned Users
The number of provisioned users is available via the following SNMP gauge.
executionServer/systemModule/systemStats/bwNumberOfUsers
64345
This number represents the total number of all types of users on the Application Server
(for example, real users and virtual users such as Voice Portals, Hunt Groups, Call
Centers) and as such, this is not the best indicator of users for the purpose of this
procedure.
For this procedure, the number of real trunking and non-trunking users should be used in
all calculations. This can be obtained from the following SNMP gauge.
executionServer/systemModule/systemStats/bwNumberOfNonVirtualUsers 35092
01-BD5003-00
PAGE 76 OF 95
10.1.2 Calculate Maximum Users per Resource Indicator

Once the data has been collected, we can estimate the maximum number of users that
can be supported by each of the key resource indicators, and then we can choose the
lower of the values. This is done by calculating the per-user contribution to each of the
measured resource indicators, and then extrapolating the number of users that can be
supported until that indicator reaches the acceptable limit, where the acceptable limit for
each indicator is as follows:
Worst Case Busy Hour CPU idle 40%
Database Permanent Size 90% of MAX_ALLOWED_ALLOC_PERM
Post Full Collection Heap Size 60% of MAX_ALLOWED_HEAP
where:
MAX_ALLOWED_ALLOC_PERM = 38% of MAX_SERVER_MEM
MAX_ALLOWED_HEAP = 25% of MAX_SERVER_MEM
The following example demonstrates the growth estimation procedure:
Given the following data:
Number of Users
35092
Worst Case Busy Hour CPU = 28% busy
Database Perm Size = 929406
(out of a allocated size of 1310720)
Post Full Collection Heap Size = 803170 (out of a allocated size of
1572800)
1)
First, calculate the per-user resource contribution (rounding down the users to
35,000).
Busy_CPU_Per_User = 28/35000 = 0.0008% per user

Post_Collection_Heap_Per_User = 803170 /35000 = 22.9K per user
DB_Perm__Per_User = 929406/35000 = 26.5K per user
2)
Then extrapolate the maximum number of users for each resource indicator:
CPU
Acceptable CPU is < 60% busy.
max_num_users_based_on_cpu = 60/Busy_CPU_Per_User= 60/0.0008 = 75000
users
Heap
The current configured allocated heap is 1572800. 60% of this allocated heap value
would be 1572800 X 0.6 = 934680.
max_num_users_based_on_current_heap =
934680K/Post_Collection_Heap_Per_User = 934680K/22.9K =
40815 users
This server currently has 6 GB of memory. This server platform can support a memory
upgrade to 16 GB, so the maximum allocated heap could be increased to 4 GB
(4194240). Sixty percent (60%) of the allocated heap would then be 4194240 x 0.6 =
2516544, which would result in the following.
max_num_users_based_on_max_heap = 2516544K/Post_Collection_Heap_Per_User
= 2516544K/22.9 = 109892 users
01-BD5003-00
PAGE 77 OF 95
Database
The current configured allocated PERM_ALLOCATED_SIZE is 1310720K. Ninety
percent (90%) of this is 1310720 X 0.9 = 1179648.
max_num_users_based_on_current_db = 1179648/DB_Perm__Per_User =
1179648K/26.5K = 44515 users
This server currently has 6 GB of memory. If the server platform can support a memory
upgrade to 16 GB then the maximum PERM_ALLOCATED_SIZE could be increased to
6G (6291360). Ninety percent (90%) of the PERM_ALLOCATED_SIZE would then be
6291360 X 0.9 = 5662224, which would result in the following.
max_num_users_based_on_max_db = 5662224/DB_Perm__Per_User =
5662224K/26.5K = 212668 users
10.1.3 Analyze Data

The existing platform has the following per-resource indicator maximum user estimates.
max_num_users_based_on_cpu = 75000 users
max_num_users_based_on_current_heap = 40815 users
max_num_users_based_on_current_db = 44515 users
The bottleneck is a heap size since it is the lower of the user values and restricts the
server growth to an estimate of 40,000 users. Since this server can be expanded in terms
of memory, increasing the server to 16 GB changes the bottleneck and the maximum
estimated number of users.
max_num_users_based_on_cpu = 75000 users
max_num_users_based_on_max_heap = 109892 users
max_num_users_based_on_max_db = 212668 users
With 16 GB, the bottleneck is now CPU and restricts the growth to an estimate of 75,000
users.
10.1.4 Revisit Growth Estimate
Once a maximum growth estimate is obtained, this procedure should be rerun periodically
as the server continues to scale (approximately every addition of 5,000 users) to ensure
that user versus key resource indicator is tracking in a linear fashion. Initially, one would
expect a linear tracking with a margin of error no worse than +/-10%. As the server growth
reaches the higher end of the range (for example, > 50% of the original expected users),
the tracking margin of error should decrease to be within +/-5%. Any larger margin
between the original growth estimate and recalculation may be the result of a footprint
change in per-user traffic or service assignment. Key performance indicators (for
example, call attempts, calls per second, SIP messages per second, and OCI messages
per second) as defined in the BroadWorks Maintenance Guide should be collected prior to
the calculation of any growth estimate to ensure that the per-user footprint has not
changed.
10.1.4.1 Server Health
It is critical that as your server grows, you continually monitor the health of the server to
ensure that all key resource indicators and performance indicators are within acceptable
ranges. For a view on what key indicators need to be monitored, see section 18 in the
BroadWorks Maintenance Guide [4].
01-BD5003-00
PAGE 78 OF 95
11 Device Management Growth Estimation Procedure

This procedure can be used to predict growth for the Xtended Services Platform and
Profile Server nodes that are used solely for device management.
11.1 Collect Information from Xtended Services Platform and Profile Servers
The information in the following sections should be collected from the Xtended Services
Platform and Profile Servers.
11.1.1 Tomcat Full Collection Heap Size
The Tomcat garbage collection information can be obtained from the
/var/broadworks/logs/tomcat/TomcatOutputXX.log files. The line to look at is after a line
with the text Full GC and can be collected using a simple awk statement such as:
cat /var/broadworks/logs/tomcat/TomcatOutput17.log |awk '/Full GC/
{getline;print}' >> post-collection_heap.out
You can now obtain the maximum post-collection heap size from the postcollection_heap.out file. For example, if post-collection_heap.out contains the following:
10368662.254: [GC [PSYoungGen: 35648K->656K(53952K)] 212910K>177918K(242368K), 0.0181865 secs] [Times: user=0.01 sys=0.00,
.02 secs]
.02 secs]
.02 secs]
.02 secs]
.02 secs]
0.02 secs]
real=0
real=0
real=0
real=0
real=0
real=
then 212910 is the maximum post-collection heap size.

Since the Tomcat heap may not be statically sized the maximum size can be obtained in
the CLI.
XSP_CLI/System/Resources/Memory/Containers> get
Container
Min
Max
Amount Percentage
Actual
===========================================================
platform
512 M
512 M
512 M
8.35 %
512 M
tomcat
256 M
6134 M
4294 M
70 %
4294 M
The maximum heap size is 4294 M.

11.1.2 Worst Case Busy Hour CPU
This is identical to the procedure for the Application Server described in section 10.1.1.3
Worst Case Busy Hour CPU.
01-BD5003-00
PAGE 79 OF 95
11.1.3 Number of Devices

The number of devices on each Application Server can be obtained using the
Performance Measurement table bwDeviceTypeSystemTable. This number needs to be
obtained on each Application Server cluster that a given Xtended Services Platform
services.
executionServer/systemModule/systemStats/bwDeviceTypeSystemTable
This table shows the number of provisioned devices by type at a system level. The
number of devices using Device Management can be calculated from the sum of the total
devices, eliminating device types that are not using Device Management.
The number of devices utilizing a particular Xtended Services Platform / Profile Server can
be determined by dividing the total number of devices in the system by the number of
Xtended Services Platform/ Profile Servers that are actively serving traffic.
NOTE: It is assumed that traffic is disturbed in a round robin fashion. If this is not the case, a
different weighting must be used.
11.1.4 Number of Web Container Threads

The number of web container threads can be obtained from the CLI on the Xtended
Services Platform or Profile server. The number of usable threads is the lesser of the
following values (the example is for Release 19.0).
XSP_CLI/Applications/WebContainer/Apache/GeneralSettings> get
usableWorkerThreads = 10000
XSP_CLI/Applications/WebContainer/Tomcat/Executors/AJP/ThreadPool> get
max = 10000
11.1.5 Apache Statistics

The average response time, average incoming requests per second, and average
response size can be obtained from the apache access logs in the directory
/var/broadworks/logs/apache.
The webTrafficParser script can be used to profile the traffic for a given hour. A busy hour
can be selected by profiling the traffic for the day and obtaining the following:
Average Response Time (in seconds)
Requests per second
Average request size
11.1.6 IOPS (Profile Server only)

Worst Case Busy Hour IOPS is obtained by analyzing SAR output for the disk or disks
that are hosting the file repository. Note that any anomaly (for example, a one-time, oneday low reading) should be discarded. The IOPS is obtained from the output of sar d
in the tps field.
01-BD5003-00
PAGE 80 OF 95
11.2 Calculate Maximum Devices per Resource Indicator (Xtended Services

Platform)
Once the data has been collected, you can estimate the maximum number of devices that
can be supported by each of the key resource indicators, and then choose the lower of
these values. This is done by calculating the per device contribution to each of the
measured resource indicators, and then extrapolating the number of devices that can be
supported until that indicator reaches the acceptable limit, where the acceptable limit for
each indicator is as follows:
Worst Case Busy Hour CPU idle 40%
Web container threads < Maximum
Bandwidth < Usable Bandwidth
Post Full Collection Heap Size 60% of MAX_ALLOWED_HEAP
The following example demonstrates the growth estimation procedure:

Number of Devices
Worst Case Busy Hour CPU
Post Full Collection Heap Size
5872025)
Web Container Threads
Usable Bandwidth
Requests per Second
Average Request Size
Average Response Time
5000
2% busy
100170 (out of a allocated size of
5000
300 Mbps
11.2
189 KB
0.575 seconds
First, calculate the per device resource.

Busy_CPU_Per_Device = 2/5000 = 0.0004% per device
Post_Collection_Heap_Per_Device = 200170 /5000 = 20 KB per device
Bandwidth per Device = 11.2 * 189 * 8 / 1024 / 5000= 0.0033 Mbps per
device
Web container thread per Device = 11.2 * 0.575 / 5000 = 0.0013 Threads
per device
Then extrapolate the maximum number of devices for each resource indicator.
CPU
Acceptable CPU is < 60% busy.
max_num_devices_based_on_cpu = 60/Busy_CPU_Per_Device = 60/0.04 = 150000
devices
Heap
The current configured allocated heap is 5872025. 60% of this allocated heap value
would be 5872025X 0.6 = 3523215.
max_num_devices_based_on_current_heap = 3523215/Post_Collection_Heap_Per_
Device = 3523215K/20K = 176160 devices
01-BD5003-00
PAGE 81 OF 95
Bandwidth
The usable bandwidth on this server is 600 Mbps.
max_num_devices_based_on_bandwidth = 300/Bandwidth per device =
600/0.0033 = 90909 devices
Web Container Threads

The number of web container threads on this server is 5000.
max_num_devices_based_on_web container threads = 500/ Web container
thread per Device = 5000/0.0013 = 3846153 devices
11.3 Analyze Data (Xtended Services Platform)

The existing platform has the following per-resource indicator maximum device estimates.
max_num_devices_based_on_cpu = 150000 devices
max_num_devies_based_on_current_heap = 176160 devices
max_num_devices_based_on_bandwidth = 90909 devices
max num devices based on web container threads = 3846153 devices
The constraining factor is the bandwidth; therefore, each Xtended Services Platform can
support approximately 90K users.
11.4 Calculate Maximum Devices per Resource Indicator (Profile Server)

The procedure for the Profile Server is identical to the procedure for the Xtended Services
Platform described in section 11.2 Calculate Maximum Devices per Resource Indicator
(Xtended Services Platform), except that an additional scaling constraint is the disk
throughput.
Number of Devices
Rated Disk IOPS
Measured IOPS
5000
450
100
First, calculate the per-device resource contribution.

IOPS per device = 100/5000= 0.02
Then extrapolate the maximum number of devices for each resource indicator.
IOPS
max_num_devices_based_on_IOPS = 450/IOPS per_Device = 450 / 0.02 = 22500
devices
11.5 Analyze Data (Profile Server)

The maximum number of devices based on IOPS can be factored in with the other
constraints as described for the Xtended Services Platform.
01-BD5003-00
PAGE 82 OF 95
12 Database Server Disk Estimation Tool

The Database Server provides an estimator tool to provide a view of disk array characteristics
such as total IOPS and data throughput. The tool is wrapped in the dbsctl script and should be
run after installation and schema deployment. The tool requests two inputs:
Total number of physical disks in the DATA ASM disk group.

This should be equal to half of the total number of disks.
Acceptable latency (10 milliseconds [msec] is a good number to use).
Usage: dbsctl [-vxfha] <command> [OPTIONS]

Supported commands:
disk
calibrate
Calibrate the disk subsystem.
[latency]
Specify maximum latency (in ms)
[disks]
Specify number of physical disks in DATA disk
group.
bwadmin@lin180-3550M3$ dbsctl disk calibrate 10 8
!WARNING! Are you sure you want to run I/O calibration on DATA disk
group?
Do you want to continue (y/n) [n]?y
Running calibration process... [DONE]
Number of physical disks
: 8
Maximum IOPS
: 1047
Maximum MBPS
: 120
Maximum MBPS (large request): 36
Target latency
: 10
The input/output (I/O) calibrated results are only for the DATA ASM disk group. The FRA
ASM disk group should be sized the same as DATA ASM disk group, so that the total
disk capability is twice the disk-calibrated numbers provided.
01-BD5003-00
PAGE 83 OF 95
13 XS Mode System Engineering

This section provides information about planned Sh traffic, and it can be used for capacity
planning purposes.
DISCLAIMER: This section only provides estimations. The real-life behavior highly depends on
numerous configuration parameters, enterprise/service provider organization, and service
penetration.
13.1 Subscriber Profile Sizing

The subscriber profile size has a direct impact on the Sh traffic. The BW-BaseUserInfo
document has a fairly fixed size, while the BW-FullUserInfo can vary slightly depending on
some collections (identities, shared schedules, and so on). The BW-Services and MMTelServices data varies based on the service model (number of assigned services). Some
services have a variable length configuration (for example, Speed Dial 100) that affects
the size of subscriber profile.
The following table provides an estimated size for some service models, illustrating lower
bound and upper bound for service penetration.
Service Model
BWBaseUserInfo
size (bytes)
BWFullUserInfo
(bytes)
BW-Services
(bytes)
MMTelServices
(bytes)
Total
Basic User
500
4000
500
4000
9000
Full Business
User
500
10000
20000
4000
34500
13.2 Execution Server Traffic Model

13.2.1 Patterns
Cold Start Upon Execution Server start-up, the profile cache is empty, but the Network
Server is typically not proxying any SIP traffic (for example, the Network Server would
have migrated the subscribers to other Execution Servers in the cluster), and thus would
not generate Sh traffic.
Subscriber Migration When the Network Server is performing enterprise or service
provider migration, this results in SIP traffic on the Execution Server for users whose
profile is not cached. This can result in a burst of profile fetch operations that gradually
fade as the cache fills up. The HSS also starts to send profile modification notifications for
the profiles just cached. Subscriber migration can take place on an already operating
Execution Server (which can be in steady state) or on a freshly started Execution Server.
The System Engineering traffic model usually sets the SIP REGISTER interval to 60
minutes, which means that a Sh traffic burst caused by subscriber migration should last for
one hour (that is, it is remotely influenced by the time at which the subscriber migration
has been performed, such as if it was at busy hour or during the night). Subscriber
migration is typically caused by an Execution Server node that has failed or through a
manual subscriber-host calculation performed by the Network Server.
01-BD5003-00
PAGE 84 OF 95
Steady State The Execution Server cache is full and the Network Server is not
performing any subscriber migration. The Sh traffic is characterized by notifications from
the HSS due to provisioning activities and by notification subscription (and optionally
profile) refreshes from the Execution Server, which take place on a configurable interval. It
is expected that provisioning activities are higher during the day and notification
subscription/profile refreshes to converge are uniform throughout the day.
13.2.2 Example
The following figures illustrate the Sh traffic on a given Execution Server that is initially in
steady state. The Execution Server is hosting 300K full business users and is performing
notification subscriptions and profile refreshes as well as processing profile modification
notifications from the HSS, with higher traffic during daytime.
On Day 2, at 10:00 A.M., 200K subscribers are migrated by the Network Server after a
failure of an Execution Server in the farm. This causes a peak of profile fetches due to
cache misses for newly migrated subscribers. The following smaller peaks are profile
refreshes for the newly hosted subscribers, which occur within 70 percent and 90 percent
of the subscriptions expiration, to converge eventually to a constant rate. Note that when
the Execution Server performs profile fetches triggered from SIP traffic (and cache miss),
there are two Subscribe-Notification-Requests (SNRs) sent. The first fetches the users
main identity and the second downloads the remainder of the profile. When performing a
profile refresh, the Subscriber Agent already knows the main identity; thus, only one SNR
is sent per profile refresh.
140
120
100
80
SNR txns/sec
60
PNR txns/sec
40
20
0
Day
1
Day
2
Day
3
Day
4
Figure 4 Execution Server Sh Transaction Rate Example, Full Business User
In this example, the 200K subscriber migration causes a peak of ~120 SNRs/sec in the
hour following the migration due to registrations and call setup.
01-BD5003-00
PAGE 85 OF 95
3000
2500
2000
1500
Outgoing traffic volume (kbytes/s)

Incoming traffic volume (kbytes/s)
1000
500
Day 4
Day 3
Day 2
Day 1
Figure 5 Execution Server Sh Data Volume Example, Full Business User
The subscriber migration results in a peak of ~2500 KBps generated by the HSS toward
the Execution Server.
The above-mentioned numbers are based on the following key configuration parameters:
reloadDataOnExpiration set to true
expiryTimeDelay set to 24 hours
dynamicNotifEffSupportDiscovery set to true; HSS supports Notif-Eff
supportsSendDataIndication set to true
Registration interval: 60 minutes
13.3 Profile Server Traffic Model

13.3.1 Patterns
Initial build-out This is the initial subscriber profile load for newly installed systems.
This is typically performed by the OSS, which logs in with administrator accounts.
Steady State This is a mix of administrator traffic (user create/delete) and customer
service and self-care traffic (mostly service configuration modification). Provisioning
clients usually create logical sessions, and all traffic for a given session goes through the
same Profile Servers. The next session created by a given user is likely on another Profile
Server in the farm, thus generating a cache miss on about every session login. Moreover,
it is intended to set the profile cache size to prevent subscriber profile fetches for
provisioning commands that occur within small (few minutes) interval. Therefore, a profile
fetch can even take place within a session, which for self-care usage, is typically set to
30 minutes. With this pattern, the cache miss is high (compared to an Execution Server
in steady state), but is not impacted much by Profile Server failure.
System engineering guides usually allow for 80 percent reads (which may or may not
trigger profile fetch on the HSS) and 20 percent writes (which trigger profile updates on the
HSS for one or more transparent data and resulting notifications). Reads usually involve a
full profile fetch, while a writes cause a Profile-Update-Request of single Repository-Data
(most likely BW-Services or MM-Tel Services). Even if the Profile Server is registering for
modification notifications on the HSS, the rate of Push-Notification-Requests (PNRs) is
expected to be negligible as the Profile Server is usually the initiator of profile modifications
(the HSS is not notifying the entity having done the profile update).
01-BD5003-00
PAGE 86 OF 95
13.3.2 Example
This example is for a Profile Server in steady state during business activity. It assumes
that the cache hit is on average 66 percent on reads. Note that careful tuning of the profile
cache may yield better results. For a system of 5 million users, the intention is that a
single Profile Server should be able to handle the entire load of 750 PTPS. This
represents 600 reads and 150 writes per second and it translates to 200 profile fetches
per second (66 percent cache hit) and 150 profile updates per second.
Thus, for a full business user, this represents 200 SNRs/sec and 150 Profile Update
Requests per second (PURs/sec). The corresponding outgoing traffic volume is ~3000
KBps on the outgoing side (from the Profile Server to the HSS, assuming an update to the
BW-Services document) and ~7500 KBps on the incoming side.
01-BD5003-00
PAGE 87 OF 95
14 Appendix A: Server Overload Controls

This section describes the overload protections for each BroadWorks node type.
14.1 Application Server

The Application Server must be able to manage an overload condition without affecting
calls in progress. An additional objective is to provide greater than 90% call completion
rate at 150 percent of rated system capacity. To meet this requirement, the Application
Server samples input queue delay. If the queue delay becomes too long, overload
conditions are triggered. For SIP messaging, separate queues are used for call traffic (for
example, INVITE) versus non-call traffic (for example, REGISTER and OPTIONS). For
the each of the following traffic types the Application Server maintains two overloaded
zones (yellow and red):
SIP call traffic
SIP non-call traffic
MGCP traffic
Each zone has a separate configurable queue-delay threshold that causes the Application
Server to transition to the next zone when exceeded.
In the yellow zone, the Application Server continues to process existing calls in progress.
If new call originations are detected, half of them are processed. The other half of call
originations are denied. In the red zone, the Application Server continues to process
existing calls in progress. If new call originations are detected, they are all denied. The
Application Server remains in the corresponding overload zone until the queue delay
returns to an acceptable threshold value.
An alarm is generated on entry into each zone. If the overload condition subsides, then
the alarm is cleared upon exiting the overload zone.
The Application Server uses an algorithm to prevent hysteresis loops. This is done to
prevent rapid fluctuations between zones. The system remains in a particular zone for a
pre-defined amount of time before transitioning to another zone. This keeps the system
from experiencing a ping-pong effect at the border of two zones.
When the Application Server denies new call originations, it can be configured to send an
error response (503 for SIP with or without a Retry-After header; 409 for MGCP), drop
the request, or redirect the request. In all cases, the end goal is to cause the endpoint to
roll over to the secondary Application Server and complete. The recommended setting is
to send an error response.
It is important to note that in an overload zone (yellow or red), the Application Server can
be configured to treat most new emergency calls as if they were existing calls in
progress.
The Application Server also implements extreme overload control protections. These
protections limit queue length, time in queue, as well as force the server into overloads
during low memory conditions. Different maximum time in queue (also referred to as the
maximum packet age) values is used during overload and non-overload conditions.
01-BD5003-00
PAGE 88 OF 95
The maximum queue time and memory values are configured via the CLI. The default
maximum queue length is computed based on the server memory but can be overridden
by a start-up parameter. By default, the maximum queue length value is set to 2500
messages per 256 MB of heap. Typically, the heap size is calculated to be a quarter of
the total amount of memory on the system. For example, a box with 2 GB of RAM would
have a heap size of 512 MB and the default value for the number of messages in the
queues would be 5000.
14.2 Network Server

As with the Application Server, the Network Server supports input queue delay-driven
overload controls. If the queue delay becomes too long, overload conditions are triggered.
For SIP messaging, separate queues are used for call traffic (for example, INVITE) versus
non-call traffic (for example, REGISTER and SUBSCRIBE redirection). For each of the
following traffic types, the Network Server maintains two overloaded zones (yellow and
red):
SIP call traffic
SIP non-call traffic
Each zone has a separate configurable queue-delay threshold that causes the Network
Server to transition to the next zone when exceeded.
In the yellow zone, the Network Server denies 50% of incoming traffic. In the red zone,
the Network Server denies 100% of incoming traffic. The Network Server remains in the
corresponding overload zone until the queue delay returns to an acceptable threshold
value.
An alarm is generated on entry into each zone. If the overload condition subsides, then
the alarm is cleared upon exiting the overload zone.
The Network Server uses an algorithm to prevent hysteresis loops. This is done to
prevent rapid fluctuations between zones. The system remains in a particular zone for a
predefined amount of time before transitioning to another zone. This keeps the system
from experiencing a ping-pong effect at the border of two zones.
When the Network Server denies new call originations, it can be configured to send an
error response (503 for SIP with or without a Retry-After header) or drop the request.
The recommended setting is to send an error response.
It is important to note that in an overload zone (yellow or red), the Network Server can be
configured to accept all emergency calls.
The Network Server also implements extreme overload control protections. These
protections limit queue length and time in queue. They also force the server into
overloads during low memory conditions. Different maximum time in queue (also referred
to as the maximum packet age) values are used during overload and non-overload
conditions.
The maximum queue time and memory values are configured via the CLI. The default
maximum queue length is computed based on the server memory; however, it can be
overridden by a start-up parameter. By default, the maximum queue length value is set to
2500 messages per 256 MB of heap. Typically, the heap size is calculated to be a
quarter of the total amount of memory on the system. For example, a box with 2 GB of
RAM would have a heap size of 512 MB and the default value for the number of
messages in the queues would be 5000.
01-BD5003-00
PAGE 89 OF 95
14.2.1 Network Server Licensing

Along with delay-driven overload controls, each Network Server is licensed for a fixed
amount of busy hour call attempts (BHCA). The Network Server monitors current BHCA.
Once the licensed BHCA capacity is met, the Network Server rejects or ignores new
transactions until it stabilizes to its peak licensed BHCA capacity.
Requests should be distributed evenly across the individual Network Servers in the
cluster. By denying new transactions, incoming INVITEs from Application Servers,
softswitches, and proxies are redirected to the next Network Server in the cluster.
Network Servers are stateless, so any Network Server generates the same response for a
given request. This overload control mechanism allows the load to be distributed
throughout the cluster until the overload condition subsides.
A Network Server generates an alarm once the peak BHCA capacity has been exceeded.
The alarm is cleared once the BHCA returns to normal.
14.3 Media Server

A Media Server is guaranteed to provide an acceptable quality of service while operating
under the rated load. If a request is received while a Media Server is at capacity, the
request is denied. By rejecting traffic when at the rated capacity, a Media Server
maintains an acceptable quality of service by ensuring a predictable processor load.
14.4 Xtended Services Platform

The performance characteristics of the Xtended Services Platform are based on the
incoming requests supported. The Xtended Services Platform supports a configurable
number of maximum requests, with separate settings for the total number of requests and
the maximum number of requests per user.
14.5 UC-Connect
As with the Application Server, UC-Connect supports input queue delay-driven overload
controls. If the queue delay becomes too long, overload conditions are triggered.
01-BD5003-00
PAGE 90 OF 95
15 Appendix B: Call Weighting

The following table shows the various call weightings.
Calls
Weighting
Internal Calls
User Calls
Answered Calls
1.00
Busy Calls
1.08
Unanswered Calls
0.69
Failure Calls
1.12
Busy to Voice Mail
1.85
No Answer to Voice Mail
3.0
Busy Forwarded to Voice Mail
3.0
No Answer Forwarded to Voice Mail
3.0
Service Calls
Auto Attendant
2.31
Call Center
2.23 + (0.08 * time between comfort messages/

average comfort message duration)
Simultaneous Ringing
1 + 0.5 * average number of entries per user
Shared Call Appearance
1 + 0.5 * average number of appearances per

user
Three-Way Conferencing
4.27
N-Way Conferencing (Media Server)
4.27 * average number of participants/3
Voice Portal
1.92
Custom Ringback
2.21 + 2 * percent of ringback files hosted on the

Application Server
Instant Group Call
1 + 0.5 * average number of instant group call

members
Voice Portal Outcalling
4.74
Push To Talk
6.14
Two-Stage Dialing
2.71
BroadWorks Anywhere Incoming
1 + 0.5 * average number of locations per user
BroadWorks Anywhere Outgoing
2.86
In-Call Service Activation
2.29
External Calls
Outgoing Calls
Answered Calls
1.00
Unanswered Calls
0.93
01-BD5003-00
PAGE 91 OF 95
Calls
Weighting
Busy Calls
1.07
Failure Calls
0.89
Incoming Calls
Basic Calls
Answered Calls
1.00
Busy/Failure Calls
1.11
Unanswered Calls
0.68
Busy to Voice Mail
2.05
No Answer to Voice Mail
1.95
Busy Forwarded to Voice Mail
1.15
No Answer Forwarded to Voice Mail
1.30
Service Calls
Auto Attendant
2.32
Call Center
2.1 + number of internal announcements * 0.5 +

number of external announcements * 0.36
Simultaneous Ringing
1 + 0.5 * average number of entries per user
Shared Call Appearance
2.50
Three-Way Conferencing
4.26
N-Way Conferencing
4.27 * average number of participants/3
Voice Portal
1.95
Custom Ringback
2.21
Push To Talk
6.14
Voice Portal Outcalling
4.74
Push To Talk
6.14
Two-Stage Dialing
2.71
BroadWorks Anywhere Incoming
1 + 0.5 * average number of locations per user
BroadWorks Anywhere Outgoing
2.86
In-Call Service Activation
2.29
Enhanced Functions
Shared Call Appearance - Call Info/Line Seize
0.57 + 0.71 * m average number of appearances

per user
Invite Authentication
0.21
CAP/OCI-C Usage
0.33 * (CommPilot Call Manager penetration +

CCC2 Penetration + Xsi Call Control penetration
+ UC-Connect penetration)
Attendant Console Usage
0.07 * average number of monitored users
01-BD5003-00
PAGE 92 OF 95
Calls
Weighting
SIP Phone Registrations (with authentication)
0.5 * ([60 registration interval in

minutes]/[registration interval in minutes * calls
per user per hour])
CPE Monitoring
2 * 60/(monitoring interval in minutes * ports per

device * calls per user per hour)
Lawful Intercept Event Monitoring
0.19
Lawful Intercept Media Monitoring
Real-time Accounting using Radius

(default configuration)
0.21
Rf Interface
0.02
Ro Interface
0.04 * penetration of pre-paid service
Busy Lamp Field
0.43 * number of monitored users
Music On Hold
2.71
Device Management
Number of device-initiated resets per user per

hour * 0.25 + number of device configuration
rebuilds per user per hour * 2
SIP Subscriptions (with authentication)
6/14 * Subscriptions per user per hour/calls per

user per hour
Route Point
(Route point events per call * # route point

channel sets) * route point CPS + (route point
subscriptions per hour/3600 ) * number of
agents/number of users * 3600/calls per user per
hour/14
01-BD5003-00
PAGE 93 OF 95
16 Appendix C: Call Model for Packaged Configurations

LEGEND:
SR = Standard Residential/SOHO User Package with Unified Messaging
PR = Premium Residential/SOHO User Package with Unified Messaging
BL = Business Line
BT = Business Trunk
SE = Standard Enterprise User Package with Unified Messaging
PE = Premium Enterprise User Package with Unified Messaging
SR
PR
BL
BT
SE
PE
Erlang
0.1
0.1
0.2
0.2
0.2
0.2
Erlang per Trunk
N/A
N/A
0.8
0.8
N/A
N/A
Attendant Console
0.00%
0.00%
0.00%
0.00%
3.00%
3.00%
Auto Attendant
0.00%
0.00%
0.00%
0.00%
3.00%
3.00%
Busy Lamp Field
0.00%
0.00%
0.00%
0.00%
1.50%
1.50%
Call Center
0.00%
0.00%
0.00%
0.00%
0.00%
5.00%
Call Manager
0.00%
2.50%
0.00%
0.00%
0.00%
5.00%
Client Applications
0.00%
10.00%
0.00%
0.00%
0.00%
10.00%
Enhanced Call Logs
0.00%
100.00%
0.00%
0.00%
0.00%
100.00%
Fax
0.00%
0.50%
0.00%
0.00%
0.00%
0.50%
N-Way Conferencing
using Conferencing
Server
0.00%
0.00%
0.00%
0.00%
0.00%
1.00%
N-Way Conferencing
using Media Server
0.00%
0.50%
0.00%
0.00%
0.00%
0.50%
Push To Talk
0.00%
0.00%
0.00%
0.00%
0.00%
0.50%
Shared Call
Appearance
0.00%
0.00%
0.00%
0.00%
5.00%
5.00%
Simultaneous
Ringing
0.00%
20.00%
0.00%
0.00%
0.00%
20.00%
Three-Way Calling
0.50%
0.50%
0.50%
0.00%
0.50%
0.50%
Voice Portal
2.50%
2.50%
0.00%
0.00%
3.00%
3.00%
Voice Messaging
No Answer
45.00%
45.00%
0.00%
0.00%
40.00%
40.00%
Voice Messaging
Busy
5.00%
5.00%
0.00%
0.00%
40.00%
40.00%
Web Portal
Penetration
10.00%
10.00%
20.00%
20.00%
20.00%
20.00%
Web Portal Usage

(Pages per User per
Hour)
10
10
10
10
Real-time Accounting
Enabled
01-BD5003-00
PAGE 94 OF 95
References
[1] BroadSoft, Inc. 2015. BroadWorks Platform Dimensioning Guide. Available
from the BroadSoft Xchange at xchange.broadsoft.com.
[2] BroadSoft, Inc. 2015. BroadWorks System Capacity Planner. Available from the
BroadSoft Xchange at xchange.broadsoft.com.
[3] BroadSoft, Inc. 2015. BroadWorks Virtualization Configuration Guide. Available
from the BroadSoft Xchange at xchange.broadsoft.com.
[4] BroadSoft, Inc. 2015. BroadWorks Maintenance Guide. Available from the
BroadSoft Xchange at xchange.broadsoft.com.
01-BD5003-00
PAGE 95 OF 95

BW SystemEngineeringGuide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BW SystemEngineeringGuide

Uploaded by

Copyright:

Available Formats

BroadWorks System Engineering Guide

9737 Washingtonian Boulevard, Suite 350

BROADWORKS SYSTEM ENGINEERING GUIDE

2015 BROADSOFT, INC.

Document Revision History

Reason for Change

Updated document for rebranding.

Changed name of document from System Guide to

Added Release 14 updates.

August 20, 2006

Added information for fax weightings and

November 22, 2006

December 11, 2006

Made document improvements for System

Made minor changes to call weightings and added

March 26, 2007

Added section 6.2.1 IPSec Tunnels for EV 46217.

March 29, 2007

Updated system architecture section and added

April 30, 2007

Fixed example Network Server capacity

April 25, 2007

Updated for replication bandwidth.

May 31, 2007

Edited changes and published document.

June 21, 2007

Added information on T2000 hardware.

July 17, 20007

Edited changes and published document.

July 25, 2007

Clarified Application Server and Network Server

August 30, 2007

Aligned capacity with the BroadWorks

Edited changes and published document.

October 12, 2007

Added SNMP get/sec guidelines.

Add information on BEA integration. Added

November 15, 2007

Added information on unified message storage

Edited changes and published document.

BROADWORKS SYSTEM ENGINEERING GUIDE

2015 BROADSOFT, INC.

Reason for Change

Removed restriction on number of enterprises for

February 14, 2008

Edited changes and published document.

February 18, 2008

Revised document for EV 58416.

February 25, 2008

Added statement indicating that information applies

Edited changes and published document.

April 14, 2008

Updated Application Server Growth Estimate

April 23, 2008

Changed maximum number of Conferencing

April 29, 2008

Edited changes and published document.

April 30, 2008

Added Device Management/Profile Server impacts.

Edited changes and published document.

June 18, 2008

Removed BroadWorks release references.

Added numbers for large Media Servers.