NN43041-220 05.12 Communication Server 1000E Planning Engineering

Communication Server 1000E Planning
and Engineering
Avaya Communication Server 1000
7.5
NN43041-220, 05.12
May 2012
© 2012 Avaya Inc. Copyright
All Rights Reserved. Except where expressly stated otherwise, no use should be made of
materials on this site, the Documentation, Software, or Hardware
Notice provided by Avaya. All content on this site, the documentation and the
Product provided by Avaya including the selection, arrangement and
While reasonable efforts have been made to ensure that the design of the content is owned either by Avaya or its licensors and is
information in this document is complete and accurate at the time of protected by copyright and other intellectual property laws including the
printing, Avaya assumes no liability for any errors. Avaya reserves the sui generis rights relating to the protection of databases. You may not
right to make changes and corrections to the information in this modify, copy, reproduce, republish, upload, post, transmit or distribute
document without the obligation to notify any person or organization of in any way any content, in whole or in part, including any code and
such changes. software unless expressly authorized by Avaya. Unauthorized
reproduction, transmission, dissemination, storage, and or use without
Documentation disclaimer the express written consent of Avaya can be a criminal, as well as a
“Documentation” means information published by Avaya in varying civil offense under the applicable law.
mediums which may include product information, operating instructions
Third-party components
and performance specifications that Avaya generally makes available
to users of its products. Documentation does not include marketing Certain software programs or portions thereof included in the Product
materials. Avaya shall not be responsible for any modifications, may contain software distributed under third party agreements (“Third
additions, or deletions to the original published version of Party Components”), which may contain terms that expand or limit
documentation unless such modifications, additions, or deletions were rights to use certain portions of the Product (“Third Party Terms”).
performed by Avaya. End User agrees to indemnify and hold harmless Information regarding distributed Linux OS source code (for those
Avaya, Avaya's agents, servants and employees against all claims, Products that have distributed the Linux OS source code), and
lawsuits, demands and judgments arising out of, or in connection with, identifying the copyright holders of the Third Party Components and the
subsequent modifications, additions or deletions to this documentation, Third Party Terms that apply to them is available on the Avaya Support
to the extent made by End User. Web site: http://support.avaya.com/Copyright.
Link disclaimer Preventing Toll Fraud
Avaya is not responsible for the contents or reliability of any linked Web “Toll fraud” is the unauthorized use of your telecommunications system
sites referenced within this site or documentation provided by Avaya. by an unauthorized party (for example, a person who is not a corporate
Avaya is not responsible for the accuracy of any information, statement employee, agent, subcontractor, or is not working on your company's
or content provided on these sites and does not necessarily endorse behalf). Be aware that there can be a risk of Toll Fraud associated with
the products, services, or information described or offered within them. your system and that, if Toll Fraud occurs, it can result in substantial
Avaya does not guarantee that these links will work all the time and has additional charges for your telecommunications services.
no control over the availability of the linked pages.
Avaya Toll Fraud Intervention
Warranty
If you suspect that you are being victimized by Toll Fraud and you need
Avaya provides a limited warranty on its Hardware and Software technical assistance or support, call Technical Service Center Toll
(“Product(s)”). Refer to your sales agreement to establish the terms of Fraud Intervention Hotline at +1-800-643-2353 for the United States
the limited warranty. In addition, Avaya’s standard warranty language, and Canada. For additional support telephone numbers, see the Avaya
as well as information regarding support for this Product while under Support Web site: http://support.avaya.com. Suspected security
warranty is available to Avaya customers and other parties through the vulnerabilities with Avaya products should be reported to Avaya by
Avaya Support Web site: http://support.avaya.com. Please note that if sending mail to: securityalerts@avaya.com.
you acquired the Product(s) from an authorized Avaya reseller outside
of the United States and Canada, the warranty is provided to you by Trademarks
said Avaya reseller and not by Avaya.
The trademarks, logos and service marks (“Marks”) displayed in this
Licenses site, the Documentation and Product(s) provided by Avaya are the
registered or unregistered Marks of Avaya, its affiliates, or other third
THE SOFTWARE LICENSE TERMS AVAILABLE ON THE AVAYA parties. Users are not permitted to use such Marks without prior written
WEBSITE, HTTP://SUPPORT.AVAYA.COM/LICENSEINFO/ ARE consent from Avaya or such third party which may own the Mark.
APPLICABLE TO ANYONE WHO DOWNLOADS, USES AND/OR Nothing contained in this site, the Documentation and Product(s)
INSTALLS AVAYA SOFTWARE, PURCHASED FROM AVAYA INC., should be construed as granting, by implication, estoppel, or otherwise,
ANY AVAYA AFFILIATE, OR AN AUTHORIZED AVAYA RESELLER any license or right in and to the Marks without the express written
(AS APPLICABLE) UNDER A COMMERCIAL AGREEMENT WITH permission of Avaya or the applicable third party.
AVAYA OR AN AUTHORIZED AVAYA RESELLER. UNLESS
OTHERWISE AGREED TO BY AVAYA IN WRITING, AVAYA DOES Avaya is a registered trademark of Avaya Inc.
NOT EXTEND THIS LICENSE IF THE SOFTWARE WAS OBTAINED
FROM ANYONE OTHER THAN AVAYA, AN AVAYA AFFILIATE OR AN All non-Avaya trademarks are the property of their respective owners,
AVAYA AUTHORIZED RESELLER; AVAYA RESERVES THE RIGHT and “Linux” is a registered trademark of Linus Torvalds.
TO TAKE LEGAL ACTION AGAINST YOU AND ANYONE ELSE
USING OR SELLING THE SOFTWARE WITHOUT A LICENSE. BY Downloading Documentation
INSTALLING, DOWNLOADING OR USING THE SOFTWARE, OR
AUTHORIZING OTHERS TO DO SO, YOU, ON BEHALF OF For the most current versions of Documentation, see the Avaya
YOURSELF AND THE ENTITY FOR WHOM YOU ARE INSTALLING, Support Web site: http://support.avaya.com.
DOWNLOADING OR USING THE SOFTWARE (HEREINAFTER
Contact Avaya Support
REFERRED TO INTERCHANGEABLY AS “YOU” AND “END USER”),
AGREE TO THESE TERMS AND CONDITIONS AND CREATE A Avaya provides a telephone number for you to use to report problems
BINDING CONTRACT BETWEEN YOU AND AVAYA INC. OR THE or to ask questions about your Product. The support telephone number
APPLICABLE AVAYA AFFILIATE ( “AVAYA”). is 1-800-242-2121 in the United States. For additional support
telephone numbers, see the Avaya Web site: http://support.avaya.com.
2 Communication Server 1000E Planning and Engineering May 2012

Comments? infodev@avaya.com
Contents
Chapter 1: New in this release........................................................................................... 15

Features.................................................................................................................................................... 15
Other changes........................................................................................................................................... 15
Revision history................................................................................................................................ 15
Chapter 2: Customer service............................................................................................. 19
Navigation................................................................................................................................................. 19
Getting technical documentation............................................................................................................... 19
Getting product training............................................................................................................................. 19
Getting help from a distributor or reseller.................................................................................................. 19
Getting technical support from the Avaya Web site.................................................................................. 20
Chapter 3: Overview of the engineering process............................................................ 21
Contents.................................................................................................................................................... 21
Introduction............................................................................................................................................... 21
About this document................................................................................................................................. 22
Subject...................................................................................................................................................... 22
Applicable systems................................................................................................................................... 23
Intended audience.................................................................................................................................... 23
Conventions.............................................................................................................................................. 23
Related information................................................................................................................................... 25
Engineering a new system........................................................................................................................ 26
Engineering a system upgrade................................................................................................................. 26
Communication Server 1000 task flow...................................................................................................... 28
Enterprise Configurator............................................................................................................................. 30
Chapter 4: Regulatory information.................................................................................... 33
Contents.................................................................................................................................................... 33
System approval....................................................................................................................................... 33
Electromagnetic compatibility.................................................................................................................... 34
Notice for United States installations........................................................................................................ 35
Hearing aid compatibility........................................................................................................................... 36
FCC compliance: Registered equipment for Direct Inward Dial calls....................................................... 36
Radio and TV interference........................................................................................................................ 37
Notice for Canadian installations.............................................................................................................. 37
Radio and TV interference........................................................................................................................ 38
Canadian and US network connections.................................................................................................... 38
Notice for International installations.......................................................................................................... 39
European compliance information............................................................................................................ 40
Supported interfaces................................................................................................................................. 40
Safety specifications................................................................................................................................. 40
Notice for Germany................................................................................................................................... 40
Empfangen und Auspacken des Communication Server 1000E..................................................... 40
Richtlinien zum Aufstellen des Systems........................................................................................... 41
Kühlen des Gehäuses...................................................................................................................... 41
ESE und Sicherheit.......................................................................................................................... 42
Sicherheits- und Betriebsnormen..................................................................................................... 42
Communication Server 1000E Planning and Engineering May 2012 3

Vorsichtshinweise zur Lithium-Batterie............................................................................................. 43
Installation in ein 19-Zoll-Rack......................................................................................................... 43
Chapter 5: Data network planning for VoIP...................................................................... 45
Contents.................................................................................................................................................... 45
Introduction............................................................................................................................................... 45
Data network planning for VoIP................................................................................................................ 46
Evaluating the existing data infrastructure................................................................................................ 46
Planning deployment of a CS 1000E system on a data network.............................................................. 47
QoS planning............................................................................................................................................ 48
Core network planning.............................................................................................................................. 48
100BaseTx IP connectivity........................................................................................................................ 48
Campus network system requirements..................................................................................................... 49
Media conversion devices......................................................................................................................... 49
Chapter 6: System architecture......................................................................................... 51
Contents.................................................................................................................................................... 51
Main components and architecture........................................................................................................... 51
Communication Server 1000E Call Server............................................................................................... 56
Functional description...................................................................................................................... 57
Operating parameters...................................................................................................................... 57
Physical description of a CP PIV Call Server................................................................................... 57
CP PIV Call Server hardware components...................................................................................... 58
Physical description of a CP PM Call Server............................................................................................ 60
CP PM Call Server hardware components............................................................................................... 62
CP PM chassis.......................................................................................................................................... 63
CP PM card............................................................................................................................................... 63
CP PM System Utility functionality................................................................................................... 65
Co-resident Call Server and Signaling Server hardware components...................................................... 65
Media Gateway......................................................................................................................................... 66
Media Gateway hardware................................................................................................................ 66
Circuit cards..................................................................................................................................... 67
Security device................................................................................................................................. 67
Media Gateway Controller (MGC) card............................................................................................ 68
Common Processor Media Gateway (CP MG) card........................................................................ 71
Media Gateway Extended Peripheral Equipment Controller (MG XPEC) card................................ 72
Network connections........................................................................................................................ 73
Avaya CS 1000 Media Gateway 1000E........................................................................................... 74
Physical description.......................................................................................................................... 75
Media Gateway Expander................................................................................................................ 77
Media Gateway 1010....................................................................................................................... 78
Voice Gateway Media Card.............................................................................................................. 81
Signaling Server........................................................................................................................................ 84
Main role........................................................................................................................................... 84
CP PM Signaling Server physical description.................................................................................. 85
CP PM Signaling Server hardware components.............................................................................. 86
CP DC Signaling Server physical description.................................................................................. 86

CP DC Signaling Server hardware components.............................................................................. 87
COTS Signaling Server physical description.................................................................................... 87
COTS Signaling Server hardware components............................................................................... 88
Software applications....................................................................................................................... 88
Terminal Server......................................................................................................................................... 90
Hardware components..................................................................................................................... 90
Layer 2 switch........................................................................................................................................... 91
Power over LAN (optional)........................................................................................................................ 92
Telephones................................................................................................................................................ 93
Component dimensions............................................................................................................................ 94
Chapter 7: Configuration options...................................................................................... 95
Contents.................................................................................................................................................... 95
Introduction............................................................................................................................................... 95
Fax/Modem pass through......................................................................................................................... 96
Modem traffic............................................................................................................................................ 97
Recommendations for Fax configuration in the CS 1000 system............................................................. 98
Typical scenarios.............................................................................................................................. 99
Recommendations for faxing in a data network............................................................................... 100
Configuration for analog line cards connected to faxes................................................................... 101
Option 1: Campus-distributed Media Gateways....................................................................................... 101
Option 2: Campus Redundancy................................................................................................................ 102
Option 3: Branch Office............................................................................................................................. 103
Option 4: Geographic Redundancy Survivable Media Gateway............................................................... 104
Media Gateway and Voice Gateway Media Card Triple Registration....................................................... 105
Chapter 8: Planning reliability strategies......................................................................... 107
Contents.................................................................................................................................................... 107
Introduction............................................................................................................................................... 107
Response to different points of failure....................................................................................................... 108
Call Server failure............................................................................................................................. 108
Network failure................................................................................................................................. 109
Signaling Server failure.................................................................................................................... 110
NRS failure....................................................................................................................................... 111
CS 1000E resiliency scenarios................................................................................................................. 113
Call Server failure............................................................................................................................. 114
Signaling Server failure.................................................................................................................... 116
NRS failure....................................................................................................................................... 117
Branch Office scenarios................................................................................................................... 119
Alternate Call Servers and survivability..................................................................................................... 125
IP telephony node configuration....................................................................................................... 125
Alternate Call Server considerations................................................................................................ 126
Campus survivable Media Gateway considerations......................................................................... 127

Multiple D-channels.......................................................................................................................... 127
Configuring for survivability.............................................................................................................. 128
Chapter 9: Telephony planning.......................................................................................... 129
Contents.................................................................................................................................................... 129
Installation planning.................................................................................................................................. 129
Milestone chart.......................................................................................................................................... 130
Evaluating existing telephony infrastructure............................................................................................. 130
Telephony planning issues........................................................................................................................ 131
Applications............................................................................................................................................... 132
Access....................................................................................................................................................... 132
Numbering plans....................................................................................................................................... 132
DTI/PRI clocking....................................................................................................................................... 133
Synchronization methods.......................................................................................................................... 134
Pleisiochoronous operation....................................................................................................................... 135
Mesochronous operation.......................................................................................................................... 135
North American hierarchical synchronization............................................................................................ 135
Timing reference....................................................................................................................................... 135
Node categories/Stratum.......................................................................................................................... 136
Frame slip................................................................................................................................................. 137
Guidelines................................................................................................................................................. 137
Clock controller function and description.................................................................................................. 138
Clocking modes......................................................................................................................................... 138
Tracking mode.......................................................................................................................................... 138
Monitoring references............................................................................................................................... 139
Reference switchover................................................................................................................................ 139
Automatic recovery and chatter................................................................................................................ 139
Holdover and free-run............................................................................................................................... 140
Free-run (nontracking).............................................................................................................................. 140
Faceplate LEDs......................................................................................................................................... 140
Clocking operation.................................................................................................................................... 141
Free-running clocks................................................................................................................................... 141
Connecting to a CO................................................................................................................................... 142
Allocating primary and secondary references........................................................................................... 144
Installation and configuration.................................................................................................................... 145
Examples.................................................................................................................................................. 147
Chapter 10: Preparing a system installation plan............................................................ 149
Contents.................................................................................................................................................... 149
Introduction............................................................................................................................................... 149
Creating an installation plan...................................................................................................................... 150
Installation outline..................................................................................................................................... 150
Milestone chart.......................................................................................................................................... 151
Fire, security, and safety requirements..................................................................................................... 152
Fire protection and prevention.................................................................................................................. 152
Fire extinguishing systems........................................................................................................................ 153
Security precautions.................................................................................................................................. 153
Safety procedures and training................................................................................................................. 154
Occupational noise exposure.................................................................................................................... 154

Equipment room requirements.................................................................................................................. 154
Environmental requirements..................................................................................................................... 155
Space requirements.................................................................................................................................. 155
Primary storage......................................................................................................................................... 156
Secondary storage.................................................................................................................................... 156
Maintenance and technician space........................................................................................................... 156
Temperature and humidity control............................................................................................................. 157
Air conditioning guidelines........................................................................................................................ 158
Other environmental factors...................................................................................................................... 159
Static electricity......................................................................................................................................... 159
Vibration.................................................................................................................................................... 160
Electromagnetic and radio frequency interference................................................................................... 160
Dust........................................................................................................................................................... 160
Lighting...................................................................................................................................................... 161
Earthquake bracing................................................................................................................................... 161
Structural features..................................................................................................................................... 161
Grounding and power requirements......................................................................................................... 161
Reserve power equipment room............................................................................................................... 161
Cable requirements................................................................................................................................... 162
Cable types............................................................................................................................................... 162
Cable access............................................................................................................................................. 163
LAN design................................................................................................................................................ 163
Preparing a floor plan................................................................................................................................ 166
Creating a building cable plan................................................................................................................... 166
Wire routing............................................................................................................................................... 167
Termination points..................................................................................................................................... 168
Preparing for delivery................................................................................................................................ 171
Conducting pre-installation inspections.................................................................................................... 171
Preparing for installation........................................................................................................................... 172
Reviewing the installation plan.................................................................................................................. 172
Reviewing the work orders........................................................................................................................ 173
Reviewing the documentation................................................................................................................... 173
Chapter 11: Power and grounding..................................................................................... 175
Contents.................................................................................................................................................... 175
Introduction............................................................................................................................................... 175
Grounding requirements........................................................................................................................... 175
Single Point Ground.................................................................................................................................. 177
Grounding methods................................................................................................................................... 180
Ground bar (NTBK80)............................................................................................................................... 181
Ground bar (NTDU6201)........................................................................................................................... 181
CP PIV Call Server (NTDU62).................................................................................................................. 181
COTS servers........................................................................................................................................... 182
Media Gateway......................................................................................................................................... 182
Media Gateway Expander......................................................................................................................... 182
Multiple components in a rack................................................................................................................... 183
Conduit requirements................................................................................................................................ 183
Commercial power requirements.............................................................................................................. 183

Media Gateway 1000E and Media Gateway Expander............................................................................ 184
Rack power bars....................................................................................................................................... 184
Powering redundant equipment................................................................................................................ 184
Powering auxiliary equipment................................................................................................................... 184
Alternative AC-powered installation.......................................................................................................... 185
Installing an isolation transformer ground................................................................................................. 185
AC input requirements.............................................................................................................................. 186
Power consumption................................................................................................................................... 187
Power consumption worksheets............................................................................................................... 190
Heat dissipation......................................................................................................................................... 195
Uninterruptible Power Supply.................................................................................................................... 195
UPS sizing................................................................................................................................................. 195
UPS installation......................................................................................................................................... 196
Power requirements for IP Phones........................................................................................................... 197
Chapter 12: Design parameters......................................................................................... 199
Contents.................................................................................................................................................... 199
Introduction............................................................................................................................................... 199
Note on terminology.................................................................................................................................. 199
System parameters................................................................................................................................... 200
Customer parameters............................................................................................................................... 200
Console and telephone parameters.......................................................................................................... 201
Trunk and route parameters...................................................................................................................... 202
ACD feature parameters........................................................................................................................... 202
Special feature parameters....................................................................................................................... 203
Hardware and capacity parameters.......................................................................................................... 205
Communication Server 1000E Co-resident Call Server and Signaling Server design parameters.......... 205
Media Cards.............................................................................................................................................. 205
Call Server memory related parameters................................................................................................... 206
Buffer limits............................................................................................................................................... 207
Access Restrictions packet logging memory limits................................................................................... 208
Chapter 13: System capacities.......................................................................................... 209
Contents.................................................................................................................................................... 209
Introduction............................................................................................................................................... 209
Memory size.............................................................................................................................................. 210
Memory engineering................................................................................................................................. 211
Call register usage.................................................................................................................................... 211
Mass storage............................................................................................................................................. 212
Software installation.................................................................................................................................. 212
Database backup...................................................................................................................................... 213
Physical capacity....................................................................................................................................... 213
CS 1000E SA and HA physical capacity ................................................................................................... 213
CS 1000E Co-resident Call Server and Signaling Server physical capacity............................................. 214
CS 1000E TDM physical capacity............................................................................................................. 214
Signaling and data links............................................................................................................................ 215
Physical links............................................................................................................................................. 215
Serial Data Interface (SDI)........................................................................................................................ 215
Local Area Network (LAN)........................................................................................................................ 215

Functional links......................................................................................................................................... 216
Application Module Link (AML)................................................................................................................. 216
OAM.......................................................................................................................................................... 216
ISDN Signaling (ISL)................................................................................................................................. 216
D-Channel................................................................................................................................................. 216
Property Management System Interface (PMSI)...................................................................................... 217
CS 1000E network traffic.......................................................................................................................... 217
Terminology............................................................................................................................................... 218
Loops and superloops............................................................................................................................... 218
Loop counting............................................................................................................................................ 219
Superloop capacity.................................................................................................................................... 220
Lines and trunks........................................................................................................................................ 220
Voice over IP traffic................................................................................................................................... 220
Service loops and circuits......................................................................................................................... 222
TDS........................................................................................................................................................... 222
Conference................................................................................................................................................ 222
Broadcast circuits...................................................................................................................................... 223
DTR........................................................................................................................................................... 224
IP Media Services..................................................................................................................................... 225
IP Recorded Announcer............................................................................................................................ 226
IP Attendant Console................................................................................................................................ 226
IP Media Services sessions...................................................................................................................... 226
Media Cards.............................................................................................................................................. 227
Traffic capacity engineering algorithms..................................................................................................... 227
Grade-of-Service....................................................................................................................................... 227
Traffic models............................................................................................................................................ 228
Real time capacity..................................................................................................................................... 229
Equivalent Basic Calls............................................................................................................................... 229
Feature impact.......................................................................................................................................... 230
Call Server real time calculations.............................................................................................................. 231
Auxiliary processors.................................................................................................................................. 231
real time algorithm..................................................................................................................................... 231
Busy hour calls.......................................................................................................................................... 231
Telephones................................................................................................................................................ 232
Trunks....................................................................................................................................................... 232
Data........................................................................................................................................................... 233
RAN........................................................................................................................................................... 233
Music......................................................................................................................................................... 234
Signaling Server........................................................................................................................................ 234
Signaling Server capacity limits................................................................................................................ 238
Maximum number of SIP and H.323 Virtual Trunks.................................................................................. 245
Impact of H.245 tunneling......................................................................................................................... 246
Application server for Personal Directory, Callers List, Redial List, and Unicode Name Directory........... 246
Software configuration capacities............................................................................................................. 247
IP Telephony node maximums.................................................................................................................. 247
CS 1000E capacities................................................................................................................................. 247
Zone/IP Telephony Node Engineering...................................................................................................... 248

Chapter 14: Resource calculations................................................................................... 249
Contents.................................................................................................................................................... 249
Introduction............................................................................................................................................... 249
Resource calculation parameters.............................................................................................................. 250
Resource calculation equations................................................................................................................ 251
Total system traffic.................................................................................................................................... 253
System calls.............................................................................................................................................. 253
Traffic equations and penetration factors.................................................................................................. 254
Resource use equations........................................................................................................................... 257
Real time calculations............................................................................................................................... 257
System EBC without applications............................................................................................................. 260
Feature and applications EBCs................................................................................................................ 260
Call Server utilization................................................................................................................................ 262
CPU real time conversion for upgrades.................................................................................................... 262
DSP/Media Card calculations................................................................................................................... 264
DSP ports for Conference......................................................................................................................... 265
DSP ports for digital trunks....................................................................................................................... 266
DSP ports for general traffic...................................................................................................................... 266
DSP ports for major applications............................................................................................................... 266
Special treatment for nonblocking access to DSP ports........................................................................... 267
Total Media Gateway DSP requirements.................................................................................................. 267
Simplified Media Gateway DSP calculations............................................................................................ 268
Virtual Trunk calculations.......................................................................................................................... 269
Reducing Virtual Trunk imbalances.......................................................................................................... 270
Bandwidth requirement for access ports................................................................................................... 271
Signaling Server algorithm........................................................................................................................ 271
Signaling Server calculations.................................................................................................................... 284
Maximum number of Failsafe Network Routing Services......................................................................... 304
Reducing imbalances (second round of algorithm calculations)............................................................... 305
Virtual Trunks............................................................................................................................................ 306
Line and trunk traffic.................................................................................................................................. 307
Illustrative engineering example............................................................................................................... 308
Assumptions.............................................................................................................................................. 308
Given configuration................................................................................................................................... 309
Calculations............................................................................................................................................... 310
Real time calculation with major applications........................................................................................... 313
New system real-tme usage...................................................................................................................... 314
CPU real time conversion for upgrades.................................................................................................... 315
DSP calculation for conference ports........................................................................................................ 315
DSP calculation for features and applications.......................................................................................... 315
DSP and Media Card calculations............................................................................................................ 316
Virtual trunk calculation............................................................................................................................. 316
Signaling Server calculation...................................................................................................................... 317
LAN/WAN bandwidth calculation algorithm............................................................................................... 322
Chapter 15: Application engineering................................................................................ 323
Contents.................................................................................................................................................... 323
Introduction............................................................................................................................................... 323

Access Restrictions................................................................................................................................... 324
Converged Desktop.................................................................................................................................. 325
Maximum number of Converged Desktop users.............................................................................. 325
SIP access port requirement............................................................................................................ 325
Personal Call Assistant requirement................................................................................................ 325
Calculating SIP access port and PCA requirements........................................................................ 325
Exchange 2007 Unified Messaging SIP trunk provisioning...................................................................... 332
Microsoft Office Communications Server users........................................................................................ 333
Trunking............................................................................................................................................ 333
Mobile Extension engineering................................................................................................................... 338
Mobile Extension.............................................................................................................................. 339
MOBX Digital Signal Processor engineering.................................................................................... 339
MOBX Digitone Receiver engineering.............................................................................................. 339
D-channel.................................................................................................................................................. 340
Engineering considerations.............................................................................................................. 340
Multiple D-channels.......................................................................................................................... 341
D-channel handling architecture....................................................................................................... 341
D-channel......................................................................................................................................... 342
ISDN Signaling Link network............................................................................................................ 344
Virtual Network Services network..................................................................................................... 344
NACD network.................................................................................................................................. 345
Trunk requirements under Longest Idle Agent routing..................................................................... 347
Parameter settings........................................................................................................................... 348
Serial Data Interface (SDI)........................................................................................................................ 349
Call Detail Recording records........................................................................................................... 350
D-channel handler engineering procedure................................................................................................ 351
DCH applications.............................................................................................................................. 352
SDI applications............................................................................................................................... 353
Examples.......................................................................................................................................... 354
Avaya CallPilot engineering...................................................................................................................... 356
Call Center................................................................................................................................................ 357
ACD.................................................................................................................................................. 357
NACD............................................................................................................................................... 359
RAN and Music................................................................................................................................ 359
Symposium Call Center............................................................................................................................ 359
Symposium Call Center with IP phones and Virtual Trunks............................................................. 360
ELAN engineering..................................................................................................................................... 360
Survivable and Distributed Media Gateway ELAN traffic estimation................................................ 360
HSP LAN Engineering............................................................................................................................... 365
Switching Equipment........................................................................................................................ 367
HSP IP address configuration.......................................................................................................... 368
CLASS network engineering rules............................................................................................................ 368
Feature operation............................................................................................................................. 368
Guidelines for nonCall Center applications...................................................................................... 370
Guidelines for Call Center applications............................................................................................ 370
Configuration parameters.......................................................................................................................... 370
Media Application Server (MAS)............................................................................................................... 371

Chapter 16: Assigning loops and card slots in the Communication Server 1000E...... 375
Contents.................................................................................................................................................... 375
Introduction............................................................................................................................................... 375
Note on terminology......................................................................................................................... 376
Loops and superloops............................................................................................................................... 376
Virtual superloops............................................................................................................................. 376
MGTDS and MGCONF loops........................................................................................................... 376
PRI/PRI2/DTI/DTI2 loops................................................................................................................. 377
Card slot usage and requirements............................................................................................................ 377
Assigning loops and cards in the CS 1000E............................................................................................. 380
Rules and guidelines........................................................................................................................ 380
Conference....................................................................................................................................... 381
TDS.................................................................................................................................................. 382
PRI/PRI2/DTI/DTI2........................................................................................................................... 383
Controlled broadcast........................................................................................................................ 383
Broadcast circuits............................................................................................................................. 383
Other service circuits........................................................................................................................ 385
TDM telephones and TDM agents................................................................................................... 385
Consoles.......................................................................................................................................... 386
IP Attendant Consoles...................................................................................................................... 386
Standard telephones........................................................................................................................ 387
Non-blocking access for ACD.......................................................................................................... 389
Preparing the final card slot assignment plan........................................................................................... 389
Chapter 17: Provisioning.................................................................................................... 391
Contents.................................................................................................................................................... 391
Introduction............................................................................................................................................... 391
Step 1: Define and forecast growth........................................................................................................... 392
Example........................................................................................................................................... 392
Step 2: Estimate CCS per terminal........................................................................................................... 393
Comparative method........................................................................................................................ 393
Manual calculation............................................................................................................................ 393
Default method................................................................................................................................. 394
Step 3: Calculate number of trunks required............................................................................................ 394
Example........................................................................................................................................... 394
Step 4: Calculate line, trunk, and console load......................................................................................... 395
Avaya Communication Server 1000E............................................................................................... 395
Step 5: Calculate Digitone receiver requirements..................................................................................... 396
Model 1............................................................................................................................................. 396
Model 2............................................................................................................................................. 396
Model 3............................................................................................................................................. 397
Model 4............................................................................................................................................. 397
Step 6: Calculate total system load........................................................................................................... 397
Step 7: Calculate the number of IPE cards required................................................................................. 397
Step 8: Calculate the number of Media Cards required............................................................................ 397
Step 9: Calculate the number of Signaling Servers required.................................................................... 398
Step 10: Provision conference/TDS loops................................................................................................ 398
Step 11: Calculate the number of Media Gateways required.................................................................... 398

Step 12: Assign equipment and prepare equipment summary................................................................. 398
Resource calculation worksheets.............................................................................................................. 399
Real time calculation worksheets.............................................................................................................. 404
Appendix A: Reference tables........................................................................................... 409
List of tables.............................................................................................................................................. 409
Trunk traffic Erlang B with P.01 Grade-of-Service..................................................................................... 409
Trunk traffic Poisson 1 percent blocking................................................................................................... 411
Trunk traffic Poisson 2 percent blocking................................................................................................... 412
Digitone receiver requirements Model 1................................................................................................... 414
Digitone receiver load capacity 6 to 15 second holding time.................................................................... 418
Digitone receiver load capacity 16 to 25 second holding time.................................................................. 419
Digitione receiver requirement Poisson 0.1 percent blocking................................................................... 421
Conference and TDS loop requirements.................................................................................................. 422
Digitone receiver provisioning................................................................................................................... 423
Index..................................................................................................................................... 425

Chapter 1: New in this release
The following section details what is new in this document for Avaya Communication Server 1000 (Avaya
CS 1000) Release 7.5.
Navigation
• Features on page 15
• Other changes on page 15
Features
The Extend Local Calls (ELC) feature is introduced. The engineering calculations are updated
to support the ELC feature.
®
The Avaya Aura Session Manager (SM) is supported. The SM can replace the Network
Routing Service (NRS) for most CS 1000E deployments. The Signaling Server algorithm
calculations are updated to include SM content.
Other changes
This section contains the following topic:
• Revision history on page 15
Revision history
May 2012 Standard 05.12. This document is up-issued to include additional

information on the Media Application Server (MAS) in the Resource
calculations and Application Engineering sections.
April 2012 Standard 05.11. This document is up-issued to include information about
the surge-suppression cable for certain trunk cards.
March 2012 Standard 05.10. This document is up-issued to include updates to CSQI/
CSQO limits.

New in this release
March 2012 Standard 05.09. This document is up-issued to include information about
supported codecs and the MAS session connection call rate.
February 2012 Standard 05.08. This document is up-issued for changes in technical
content. The section Signaling Server capacity limits on page 238 is
updated.
November Standard 05.07. This document is up-issued to include an update to the
2011 number of IP Attendant Consoles available for IP Media Services
sessions.
July 2011 Standard 05.06. This document is up-issued to update the Security Server
capacities table with MAS cph details.
June 2011 Standard 05.05. This document is up-issued to include the Avaya
Common Server (HP DL360 G7).
March 2011 Standard 05.04. This document is up-issued to include recommended fax
configurations in the Communication Server 1000 Release 7.5.
February 2011 Standard 05.03. This document is up-issued to remove legacy feature and
hardware content that is no longer applicable to or supported by
Communication Server 1000 systems.
November Standard 05.02. This document is issued to support Avaya
2010 Communication Server 1000 Release 7.5.
November Standard 05.01. This document is issued to support Avaya
March 2012 Standard 04.05. This document is up-issued to include updates to CSQI/
CSQO limits.
March 2012 Standard 04.04. This document is up-issued to include information about
supported codecs and the MAS session connection call rate.
October 2010 Standard 04.03. This document is up-issued to update the dedicated
Signaling Server capacity limits to support Avaya Communication Server
1000 Release 7.0.
August 2010 Standard 04.02. This document is up-issued to update planning and
engineering capacities, and the Signaling Server algorithm to support
Avaya Communication Server 1000 Release 7.0.
June 2010 Standard 04.01. This document is issued to support Avaya
Communication Server 1000 Release 7.0.
February 2010 Standard 03.08. This document is up-issued to replace Baystack with
Ethernet Routing Switch.
October 2009 Standard 03.07. This document is up-issued to include Media Gateway
Extended Peripheral Equipment Controller (MG XPEC) content.
September Standard 03.06. This document is up-issued to include Media Gateway
2009 1010 content.
August 2009 Standard 03.05. This document is up-issued to update Memory-Related
parameters.

Other changes
June 2009 Standard 03.04. This document is up-issued to include an introduction to

the CP PM Co-resident Call Server and Signaling server feature in the
New in this release chapter, and to add SIP in the Data network planning
for VoIP chapter.
June 2009 Standard 03.03. This document is up-issued to include updates for
Signaling Server algorithm constants.
May 2009 Standard 03.02. This document is up-issued to include a task flow graphic
for Communication Server 1000 Release 6.0.
May 2009 Standard 03.01. This document is issued to support Nortel
Communication Server 1000 Release 6.0.
October 2008 Standard 02.07. This document is up-issued to include information about
Call Servers memory capacity.
October 2008 Standard 02.06. This document is up-issued to include the limit of 128 ITG
cards or 4096 DSPs as a system limit. The table System Parameters
includes the updated technical content.
May 2008 Standard 02.05. This document is up-issued to reflect changes in
technical content for mobile extensions.
May 2008 Standard 02.04. This document is up-issued to include information about
the maximum call rate supported in the Signaling Server software
element.
February 2008 Standard 02.03. This document is up-issued to include additional Modem
Pass Through Allowed information, corrections to software degradation
release factors, and COTS servers running NRS on Linux cannot run
signaling server applications.
January 2008 Standard 02.02. This document is up-issued to include Modem Pass
Through Allowed information, updates for supported IP Phones, and
Enterprise Configurator.
December Standard 02.01. This document is issued to support Nortel
December Standard 01.05. This document is up-issued with corrections to the
2007 memory requirements and number of IP users in PD/CL/RL applications.
This document also contains corrections to CP PM supported slots in an
Option 11C cabinet.
November Standard 01.04. This document is up-issued to include Survivable and
2007 Distributed Media Gateway ELAN traffic estimations.
July 2007 Standard 01.03. This document is up-issued with corrections to ISP 1100
Signaling Server Network Routing Service limits for calls per hour, end
points, and routing entries.
June 2007 Standard 01.02. This document is up-issued with corrections to real time
factors and software release degradation factors. This document also
contains revised maximum number of IP users in PD/CL/RL
applications.

New in this release
May 2007 Standard 01.01. This document is issued to support Nortel

Communication Server 1000 Release 5.0. This document is renamed
Communication Server 1000E Planning and Engineering (NN43041-220)
and contains information previously contained in the following legacy
document, now retired: Communications Server 1000E: Planning and
Engineering (553-3041-120).

Chapter 2: Customer service
Visit the Avaya Web site to access the complete range of services and support that Avaya provides. Go
to www.avaya.com or go to one of the pages listed in the following sections.
Navigation
• Getting technical documentation on page 19
• Getting product training on page 19
• Getting help from a distributor or reseller on page 19
• Getting technical support from the Avaya Web site on page 20
Getting technical documentation

To download and print selected technical publications and release notes directly from the
Internet, go to www.avaya.com/support.
Getting product training

Ongoing product training is available. For more information or to register, go to
www.avaya.com/support. From this Web site, locate the Training link on the left-hand
navigation pane.
Getting help from a distributor or reseller

If you purchased a service contract for your Avaya product from a distributor or authorized
reseller, contact the technical support staff for that distributor or reseller for assistance.

Customer service
Getting technical support from the Avaya Web site

The easiest and most effective way to get technical support for Avaya products is from the
Avaya Technical Support Web site at www.avaya.com/support.

Chapter 3: Overview of the engineering
process
Contents
This chapter contains the following topics:
Introduction on page 21
Engineering a new system on page 26
Engineering a system upgrade on page 26
Communication Server 1000 task flow on page 28
Enterprise Configurator on page 30
Introduction
Warning:
Before an Avaya Communication Server 1000E (Avaya CS 1000E) system can be installed,
a network assessment must be performed and the network must be VoIP-ready.
If the minimum VoIP network requirements are not met, the system will not operate
properly.
For information about the minimum VoIP network requirements and converging a data
network with VoIP, see Avaya Converging the Data Network with VoIP Fundamentals,
NN43001-260.
A switch must be engineered upon initial installation, during upgrades, and when traffic loads
change significantly or increase beyond the bounds anticipated when the switch was last
engineered. A properly engineered switch is one that all components work within their capacity
limits during the busy hour.
This document is not intended to provide a theoretical background for engineering principles,
except to the extent required to make sense of the information. Furthermore, in order to control
complexity, technical details and data are sometimes omitted when the impact is sufficiently
small.

Overview of the engineering process
This document does not address the engineering or functionality of major features, such as
Automatic Call Distribution (ACD) or Network Automatic Call Distribution (NACD), and of
auxiliary processors and their applications, such as Symposium and Avaya CallPilot.
Guidelines for feature and auxiliary platform engineering are given in documents relating to
the specific applications involved. This document provides sufficient information to determine
and account for the impact of such features and applications upon the capacities of the system
itself.
About this document

This document is a global document. Contact your system supplier or your Avaya
representative to verify that the hardware and software described are supported in your
area.
Subject
Warning:
Before an Avaya CS 1000E system can be installed, a network assessment must be
performed and the network must be VoIP-ready.
properly.
NN43001-260.
This document provides the information necessary to properly engineer a Communication
Server 1000E (CS 1000E) system. There are two major purposes for using this document: to
engineer an entirely new system, and to evaluate a system upgrade.
The Enterprise Configurator provides an alternative to the manual processes given in this
document. It is beyond the scope of this document to describe the Enterprise Configurator
process.
Note on legacy products and releases
This document contains information about systems, components, and features that are
compatible with CS 1000 software. For more information about legacy products and releases,
click the Technical Documentation link under Support & Training on the Avaya home page:
http://www.avaya.com

Applicable systems
Applicable systems
This document applies to the CS 1000E system.
When upgrading software, memory upgrades can be required on the Signaling Server, the Call
Server, or both.
Intended audience
This document is intended for system engineers responsible for engineering the switch and
the Avaya Technical Assistance Support personnel who support them. Engineers can be
employees of the end user, third-party consultants, or distributors.
The engineer responsible for system implementation should have several years of experience
with Avaya PBX systems.
Others who are interested in this information, or find it useful, are Sales and Marketing, Service
Managers, Account Managers, and Field Support.
Conventions
In this document, CS 1000E is referred to generically as system.
In this document, the following Chassis or Cabinets are referred to generically as Media
Gateway:
• Option 11C Mini Chassis (NTDK91) and Chassis Expander (NTDK92)
• Option 11C Cabinet (NTAK11)
• Avaya MG 1000E Chassis (NTDU14) and Expansion Chassis (NTDU15)
• Media Gateway 1010 (MG 1010) (NTC310)
• IPE module (NT8D37) with MG XPEC card (NTDW20)
In this document, the following cards are referred to generically as Gateway Controller:
• Media Gateway Controller (MGC) card (NTDW60 and NTDW98)
• Common Processor Media Gateway (CP MG) card (NTDW56 and NTDW59)
• Media Gateway Extended Peripheral Equipment Controller (MG XPEC) card (NTDW20)

In this document, the following hardware platforms are referred to generically as Server:
• Call Processor Pentium IV (CP PIV)
• Common Processor Pentium Mobile (CP PM)
• Common Processor Media Gateway (CP MG)
• Common Processor Dual Core (CP DC)
• Commercial off-the-shelf (COTS) servers
- IBM x306m server (COTS1)
- HP DL320 G4 server (COTS1)
- IBM x3350 server (COTS2)
- Dell R300 server (COTS2)
- HP DL360 G7 (Avaya Common Server)
In this document, the generic term COTS refers to all COTS servers. The term COTS1, COTS2,
or Common Server refers to the specific servers in the preceding list.
Co-res CS and SS is not supported on COTS1 servers (IBM x306m, HP DL320-G4)
The following table shows CS 1000 supported roles for various hardware platforms.
Table 1: Hardware platform supported roles
Hardware VxWorks Linux Server Co-res CS and Gateway

platform Server SS Controller
CP PIV yes no no no
CP PM yes yes yes no
CP DC no yes yes no
CP MG no no yes (see note) yes (see note)
MGC no no no yes
MG XPEC no no no yes
COTS1 no yes no no
COTS2 no yes yes no
Common Server no yes yes no
Note:
The CP MG card functions as the Co-res CS and SS, and the Gateway Controller while
occupying slot 0 in a Media Gateway.

Related information
Related information
This section lists information sources that relate to this document.
Documents
The following documents are referenced in this document:
• Avaya Feature Listing Reference, NN43001-111
• Avaya Signaling Server IP Line Applications Fundamentals, NN43001-125
• Avaya Network Routing Service Fundamentals, NN43001-130
• Avaya Converging the Data Network with VoIP Fundamentals, NN43001-260
• Avaya Electronic Switched Network Signaling and Transmission Guidelines,
NN43001-280
• Avaya Transmission Parameters, NN43001-282
• Avaya Dialing Plans Reference, NN43001-283
• Avaya Circuit Card Reference, NN43001-311
• Avaya IP Peer Networking Installation and Commissioning, NN43001-313
• Avaya Branch Office Installation and Commissioning, NN43001-314
• Avaya Linux Platform Base and Applications Installation and Commissioning,
NN43001-315
• Avaya SIP Line Fundamentals, NN43001-508
• Avaya Co-resident Call Server and Signaling Server Fundamentals, NN43001-509
• Avaya Automatic Call Distribution Fundamentals, NN43001-551
• Avaya System Management Reference, NN43001-600
• Avaya Access Control Management Reference, NN43001-602
• Avaya Software Input Output Administration, NN43001-611
• Avaya Security Management, NN43001-604
• Avaya Element Manager System Reference - Administration, NN43001-632
• Avaya Telephones and Consoles Fundamentals, NN43001-567
• Avaya IP Phones Fundamentals (NN43001-368), NN43001-368
• Avaya ISDN Primary Rate Interface Fundamentals, NN43001-569
• Avaya Basic Network Feature Fundamentals, NN43001-579
• Avaya ISDN Basic Rate Interface Feature Fundamentals, NN43001-580
• Avaya Traffic Measurement Formats and Outputs Reference, NN43001-750
• Avaya Software Input Output Reference Maintenance, NN43001-711

• Avaya Communication Server 1000M and Meridian 1 Large System Planning and
Engineering, NN43021-220
• Avaya Communication Server 1000E Installation and Commissioning, NN43041-310
• Avaya Communication Server 1000E Software Upgrades, NN43041-458
• Avaya CallPilot Planning and Engineering, 555-7101-101
Online
To access Avaya documentation online, click the Technical Documentation link under
Support & Training on the Avaya home page:
http://www.avaya.com
Engineering a new system

Figure 1: Engineering a new system on page 27 illustrates a typical process for installing a
new system. The agent expected to perform each step of the process is listed to the right of
the block. The highlighted block is the subject of this document.
Engineering a system upgrade

In cases of major upgrades or if current resource usage levels are not known, Avaya
recommends following the complete engineering process, as described for engineering a new
system.
If minor changes are being made, calculate the incremental capacity impacts and add them to
the current resource usage levels. Then compare the resulting values with the system
capacities to determine whether the corresponding capacity has been exceeded.

Engineering a system upgrade
Figure 1: Engineering a new system

Communication Server 1000 task flow

This section provides high-level task flow diagrams for CS 1000 network and CS 1000 SA/HA
system installations or upgrades. The task flow indicates the recommended sequence of
events to follow when configuring a system and provides the document number that contains
the detailed procedures required for the task. For more information refer to the following
publications, which are referenced in the task flow diagram:
• Avaya Linux Platform Base and Applications Installation and Commissioning,
NN43001-315
• Avaya Communication Server 1000E Installation and Commissioning, NN43041-310
• Avaya Communication Server 1000E Software Upgrades, NN43041-458

Communication Server 1000 task flow
Figure 2: Communication Server 1000E network task flow

Figure 3: Communication Server 1000E deployment task flow
Enterprise Configurator
The Enterprise Configurator (EC) is a global engineering and quotation tool to assist the site
engineer, sales person, or customer in engineering the switch. It is available in both stand-
alone and web-based versions. For users in North America and the Caribbean and Latin
America (CALA), it replaces Meridian Configurator and 1-Up. For users in Europe, Middle East,
and Africa (EMEA) countries, it replaces NetPrice.
The EC provides a simple "needs-based" provisioning model that allows for easy configuring
and quoting. The EC supports CS 1000E new system sales and upgrades by analyzing input

Enterprise Configurator
specifications for a digital PBX to produce a full range of pricing, engineering reports, and
graphics. These reports include equipment lists, cabling reports, software matrix, engineering
capacities, and pricing for currently available CS 1000E configurations. Graphics depict the
engineered platform, card slot allocations as well as loop assignments.
The EC runs on the user's Windows-based or MacOS personal computer. It uses standard
browser and Microsoft Office applications. For details on computer system requirements and
for user instructions, refer to the Avaya web site. Enterprise Configurator implements the
algorithms specified in this document for real time, memory, and physical capacities. It is the
official tool for determining whether a proposed configuration will meet the customer's capacity
requirements.
Where applicable, in this document, references are made to the EC inputs that correspond to
parameters being described.


Chapter 4: Regulatory information
Contents
System approval on page 33
Electromagnetic compatibility on page 34
Notice for United States installations on page 35
Notice for Canadian installations on page 37
Canadian and US network connections on page 38
Notice for International installations on page 39
Notice for Germany on page 40
System approval
The Avaya Communication Server 1000E (Avaya CS 1000E) system has approvals to be sold
in many global markets. Regulatory labels on the back of system equipment contain national
and international regulatory information.
Some physical components in systems have been marketed under different names in the past.
Previous naming conventions utilizing the terms Succession 1000 and CSE 1000 have been
harmonized to use the term Avaya CS 1000. Similarly, previous naming conventions utilizing
the terms Meridian and Option have been harmonized to use the term Meridian 1 PBX. Product
names based on earlier naming conventions can still appear in some system documentation
and on the system regulatory labels. From the point of view of regulatory standards compliance,
the physical equipment is unchanged. As such, all the instructions and warnings in the
regulatory sections of this document apply to the CS 1000M, CS 1000S, and CS 1000E
systems, as well as the Meridian, Succession 1000, and CSE 1000 systems.

Regulatory information
Electromagnetic compatibility
Caution:
In a domestic environment, the system can cause radio interference. In this case, the user
can be required to take adequate measures.
Table 2: EMC specifications for Class A devices on page 34 lists the EMC specifications for
the system.
Table 2: EMC specifications for Class A devices
Jurisdiction Standard Description

United States FCC CFR 47 FCC Rules for Radio Frequency Devices (see Note
Part 15 1a)
Canada ICES-003 Interference-Causing Equipment Standard: Digital
Apparatus
Europe EN 55022/ Information technology equipment — Radio
CISPR 22 disturbance characteristics — Limits and methods of
measurement (see Note 2)
EN 55024 Information technology equipment — Immunity
characteristics — Limits and methods of
measurement
EN 61000-3-2 Limits for harmonic current emissions (equipment
input current <= 16 A per phase)
EN 61000-3-3 Limitation of voltage fluctuations and flicker in low-
voltage supply systems for equipment with rated
current <= 16 A
Australia CISPR 22/ AS/ Limits and methods of measurement of radio
NZS 3548 disturbance characteristics of information technology
equipment (see Note 2)
Korea KN22 Information technology equipment — Radio
disturbance characteristics — Limits and methods of
measurement
KN24 Information technology equipment — Immunity
characteristics — Limits and methods of
measurement
Taiwan CNS 13438 Limits and methods of measurement of radio
disturbance characteristics of information technology
equipment

Notice for United States installations
Jurisdiction Standard Description

Note 1a: FCC CFR 47 Part 15.21 statement: "Note: This equipment has been tested and
found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC
Rules. These limits are designed to provide reasonable protection against harmful
interference when the equipment is operated in a commercial environment. This equipment
generates, uses, and can radiate radio frequency energy and, if not installed and used in
accordance with the instruction manual, can cause harmful interference to radio
communications. Operation of this equipment in a residential area is likely to cause harmful
interference, in which case the user is required to correct the interference at his own
expense."
Note 1b: The user should not make changes or modifications not expressly approved by
Avaya. Any such changes can void the user's authority to operate the equipment.
Note 2: EN 55022/CISPR 22 statement: "WARNING This is a class A product. In a domestic
environment this product can cause radio interference, in which case the user can be
required to take adequate measures."
Notice for United States installations

The system complies with Part 68 of the United States Federal Communications Commission
(FCC) rules. A label containing the FCC registration number and Ringer Equivalence Number
(REN) for the equipment is on the back of each Media Gateway and Media Gateway Expander.
If requested, you must provide this information to the telephone company.
Regulatory labels include:
• FCC registration: AB6CAN-61117-MF-E
• FCC registration: AB6CAN-61116-PF-E
• FCC registration: AB6CAN-18924-KF-E
• Service code: 9.0F, 6.0P
• Ringer equivalence (REN): 2.7A
The FCC regulation label includes the REN. This number represents the electrical load applied
to your telephone line after you plug the system into the wall jack. The telephone line for your
premises does not operate correctly if the total ringer load exceeds the capabilities of the
telephone company's Central Office (CO) equipment. If too many ringers connect to the line,
there may not be enough energy to ring your system. If the ringer load exceeds the system's
capabilities, you can have problems dialing telephone numbers.
For more information about the total REN permitted for your telephone line, contact your local
telephone company. However, as a guideline, a total REN of five should support normal
operation of your equipment.
If your system equipment causes harm to the telephone network, the telephone company can
temporarily discontinue your service. The telephone company can ask you to disconnect the
equipment from the network until the problem is corrected and you are sure the equipment is

working correctly. If possible, the telephone company notifies you before they disconnect the
equipment. You are notified of your right to file a complaint with the FCC.
Your telephone company can make changes in its facilities, equipment, operations, or
procedures that can affect the correct operation of your equipment. If the telephone company
does make changes, they give you advance notice. With advance notice, it is possible for you
to make arrangements to maintain uninterrupted service.
If you experience trouble with your system equipment, contact your authorized distributor or
service center.
You cannot use the equipment on public coin service provided by the telephone company.
Connection to party line service is subject to state tariffs. Contact the state public utility
commission, public service commission, or corporation commission for information.
The equipment can provide access to interstate providers of operator services through the use
of Equal Access codes. Failure to provide Equal Access capabilities is a violation of the
Telephone Operator Consumer Services Improvement Act of 1990 and Part 68 of the FCC
Rules.
Hearing aid compatibility

All proprietary telephones used with the system meet with the requirements of FCC Part 68
Rule 68.316 for hearing aid compatibility.
FCC compliance: Registered equipment for Direct Inward

Dial calls
Equipment registered for Direct Inward Dial (DID) calls must provide proper answer
supervision. Failure to meet this requirement is a violation of part 68 of the FCC's rules.
The definition of correct answer supervision is as follows:
• DID equipment returns answer supervision to the Central Office when DID calls are:
- answered by the called telephone
- answered by the attendant
- routed to a recorded announcement that can be administered by the user
- routed to a dial prompt
• DID equipment returns answer supervision on all DID calls forwarded to the Central
Office. Exceptions are permitted if a call is not answered, a busy tone is received, or a
reorder tone is received.

Radio and TV interference

The system complies with Part 15 of the FCC rules in the United States of America. Operation
is subject to the following two conditions:
1. The system must not cause harmful interference.
2. The system must accept any interference received, including interference that can
cause undesirable operation.
You can determine the presence of interference by placing a telephone call while monitoring.
If the system causes interference to radio or television reception, try to correct the interference
by moving the receiving TV or radio antenna if this can be done safely. Then move the TV or
radio in relation to the telephone equipment.
If necessary, ask a qualified radio or television technician or supplier for additional information.
You can refer to the document "How to Identify and Resolve Radio-TV Interference", prepared
by the Federal Communications Commission. This document is available from:
U.S. Government Printing Office Washington DC 20402
Notice for Canadian installations

Industry Canada uses a label to identify certified equipment. Certification indicates that the
equipment meets certain operations, safety, and protection requirements for
telecommunications networks. Industry Canada does not guarantee that the equipment will
operate to the user's satisfaction.
The Load Number (LN) assigned to each terminal device is the percentage of the total load
that can be connected to a telephone loop using the device. This number prevents overload.
The termination on a loop can have any combination of devices, provided that the total of the
Load Numbers does not exceed 100. An alphabetical suffix is also defined in the Load Number
for the appropriate ringing type (A or B), if necessary. For example, LN = 20 A indicates a Load
Number of 20 and an "A" type ringer.
Before you install any equipment, make sure that it can connect to the facilities of the local
telecommunications company. Install the equipment using acceptable methods of connection.
In some cases, a certified connector assembly (telephone extension cord) can extend the
company's inside wiring associated with a single line individual service. Understand that
compliance with the above conditions does not always prevent degradation of service.
Repairs to certified equipment must be made by an authorized Canadian maintenance facility
designated by the supplier. If you make repairs or modifications to this equipment, or if the
equipment malfunctions, the telephone company can ask you to disconnect the equipment.

Make sure that the electrical ground connections of the power utility, telephone lines, and
internal metallic water pipe system, if present, connect together. This precaution is for the
users' protection, and is very important in rural areas.
Voltage:
DANGER OF ELECTRIC SHOCK
The system frame ground of each unit must be tied to a reliable building ground
reference.
Voltage:
Do not attempt to make electrical ground connections yourself. Contact your local electrical
inspection authority or electrician to make electrical ground connections.

The system does not exceed Class A limits for radio noise emissions from digital apparatus,
as set out in the radio interference regulations of Industry Canada (ICES-003).
Canadian and US network connections

Table 3: Network connection specifications on page 38 contains information that must be
given to the local telephone company when ordering standard network interface jacks for the
system.
Table 3: Network connection specifications on page 38 includes columns for system port
identification, Facility Interface Code (FIC), Service Order Code (SOC), Uniform Service Order
Code (USOC) jack identification, and associated Avaya equipment part numbers.
Table 3: Network connection specifications
Ports Facility Service REN Network Manufacturer

Interface Order jacks network interface
Code Code port designation
MTS/WATS
2-Wire, LSA, L-S 02LS2 9.0F 2.7A RJ21X NT8D14
(2-Wire, Local CA21X*
Switched Access,
Loop-Start)
2-Wire, LSA, G-S 02GS2 9.0F 2.7A RJ21X NT8D14

Notice for International installations
Ports Facility Service REN Network Manufacturer

Interface Order jacks network interface
Code Code port designation
Switched Access,
Ground-Start)
2-Wire, LSA, R-B 02RV2-T 9.0F 0.0B RJ21X NT8D14
Switched Access,
Reverse-Battery)
1.544 Mbps OSI, SF 04DU9-BN 6.0P N/A RJ48 NTRB21
CA48*
1.544 Mbps OSI, SF 04DU9-KN 6.0P N/A RJ48 NTRB21
CA48*
Analog PL facilities
8-port OPX line OL13C 9.0F N/A RJ21X NT1R20
E&M TIE Trunk TL11M 9.0F N/A RJ2EX NT8D15
(TIE line, lossless, 2- CA2EX*
wire type 1 E&M)
E&M 4-Wire DRTT TL31M 9.0F N/A RJ2GX NT8D15
(TIE line, lossless, CA2GX*
dial repeating, 4-wire
type 1 E&M)
E&M 4-Wire DRTT TL32M 9.0F N/A RJ2HX NT8D15
(TIE line, lossless, CA2HX*
dial repeating, 4-wire
type 2 E&M)
Digital
1.544 Mbps 04DU9-BN 6.0P N/A N/A NT5D12
superframe
1.544 Mbps 04DU9-KN 6.0P N/A N/A NT5D12
extended
superframe
* RJ with CA for Canada
Notice for International installations

If there is not enough planning or technical information available for your country of operation,
contact your regional distributor or authority.

European compliance information

The system meets the following European technical regulations: CTR 1, CTR 2, CTR 3, CTR
4, CTR 6, CTR 10, CTR 12, CTR 13, CTR 15, CTR 17, CTR 22, CTR 24, and the I-ETS 300
131.
Supported interfaces
Analog interfaces are approved based on national or European specifications. Digital
interfaces are approved based on European specifications.
Safety specifications
The system meets the following European safety specifications: EN 60825, EN 60950, and
EN 41003.
Notice for Germany
Empfangen und Auspacken des Communication Server 1000E

Dem Gerät sollte eine Teileliste beiliegen, die alle im Lieferumfang des Systems enthaltenen
Teile auflistet. Vergleichen Sie diese Teileliste mit den erhaltenen Teilen. Sollte die Teileliste
mit den erhaltenen Teilen nicht übereinstimmen, benachrichtigen Sie unverzüglich den
Lieferungsagenten und Avaya. Alle mit dem System bestellten Optionen sind werkseitig
installiert und nicht separat auf der Teileliste aufgelistet. Bewahren Sie die Versandkartons auf,
um sie ggf. wiederverwenden zu können.
Hinweis: Falls die Versandkartons bei Empfang beschädigt sind, sollten Sie den
Lieferungsagenten bitten, bei dem Auspacken und der Inspektion des Geräts anwesend zu
sein.

Notice for Germany
1. Stellen Sie sicher, daß sich der Verpackungskarton in aufrechter Position

befindet.
2. Schneiden Sie das Verpackungsklebeband vorsichtig mit einem Schneidemesser
auf, und öffnen Sie dann den Karton.
3. Entfernen Sie die Kartonverpackung, das Schaumstoff- verpackungsmaterial und
die schützende Plastikverpackung.
4. Heben Sie das Chassis vorsichtig aus dem Karton, und plazieren Sie es an dem
gewünschten Aufstellungsort.
Richtlinien zum Aufstellen des Systems

Bei der Wahl des Systemstandorts empfiehlt es sich, folgende Punkte in Betracht zu ziehen:
1. Stabilität. Stellen Sie das System in einem Bereich auf, der vor übermäßigen
Bewegungen und Erschütterungen geschützt ist.
2. Sicherheit. Installieren Sie das System im Hinblick auf Sicherheit. Sorgen Sie dafür,
daß Kabel und Drähte den Zugang nicht behindern.
3. Zugang. Stellen Sie das System so auf, daß es problemlos gewartet werden kann.
Bei Wartungsarbeiten ist Zugang zur Vorder- und Rückseite des Systems
erforderlich.
4. Betriebsumgebung. Stellen Sie das System in einem Bereich auf, an dem es Hitze,
Staub, Rauch und elektrostatischer Entladung (ESE) nicht ausgesetzt ist.
5. Kühlung. Lassen Sie Platz für eine ausreichende Luftzirkulation zur Kühlung.
Stellen Sie sicher, daß vor und hinter dem System mindestens 10 cm Freiraum
gelassen wird. (Zusätzliche Richtlinien zur Kühlung des Gerätes finden Sie im
nächsten Abschnitt.)
Kühlen des Gehäuses

Es ist äußerst wichtig, daß alle Geräte eines Systems sachgemäß gekühlt werden. Die
Eingangslufttemperatur der Systemkomponenten muß im allgemeinen unter 45° C (113° F)
liegen. Interne, durch Gleichstrom betriebene Ventilatoren kühlen die Laufwerke und Module
des Systems ab. Die Übergangsmodule an der Rückseite des Chassis werden durch natürliche
Konvektion gekühlt. Um eine ausreichende Kühlung zu gewährleisten, sollten Sie:
• Vor und hinter dem System mindestens 10 cm Freiraum lassen.
• Sicherstellen, daß die Verkleidungen aufgesetzt, alle vorderen und rückwärtigen Schlitze
gefüllt und alle Öffnung abgedeckt sind.
• Alle nicht verwendeten Modulschlitze abdecken.
Bei der Installation des Systems in einer bestimmten Betriebsumgebung sollten die
technischen Daten zur Betriebsumgebung der Systemkomponenten beachtet werden. Zum

Beispiel: Bei Umgebungstemperaturen über 45° C (113° F) wird der Betrieb von Disketten-
und Festplattenlaufwerken nicht mehr zuverlässig. Im Falle eines Gerätes, das in einem
Gehäuse installiert ist, sollten Sie beachten, daß die interne Umgebungstemperatur unter
Umständen über die maximal mögliche, externe Umgebungstemperatur ansteigen kann.
ESE und Sicherheit
ESE-ANTISTATIKBAND VERWENDEN
Avaya empfiehlt, bei allen Installations- oder Aufrüstarbeiten am System
ein Antistatikband und eine ableitende Schaumstoffunterlage zu
verwenden. Elektronische Komponenten, wie z.B. Plattenlaufwerke,
Platinen und Speichermodule, können gegen ESE äußerst empfindlich
sein. Nach dem Entfernen des Bauteils aus dem System oder aus der
Schutzhülle wird das Bauteil flach auf eine geerdete und statikfreie
Oberfläche gelegt, und im Falle einer Platine mit der Komponentenseite
nach oben. Das Bauteil nicht auf der Oberfläche hin und her bewegen.
Ist kein ESE-Arbeitsplatz verfügbar, so können ESE-Gefahren durch das
Tragen eines Antistatikbands (in Elektronik- Fachgeschäften erhältlich)
vermieden werden. Dabei ist ein Ende des Bandes um das Handgelenk
zu legen. Das Erdungsende (normalerweise ein Stück Kupferfolie oder
eine Krokodilklemme) an einer elektrischen Masseverbindung
anschließen. Hierbei kann es sich um ein Stück Metall handeln, das direkt
zur Erde führt (z.B. ein unbeschichtetes Metallrohr) oder ein Metallteil
eines geerdeten, elektrischen Gerätes. Ein elektrisches Gerät ist geerdet,
wenn es einen dreistiftigen Schukostecker besitzt, der in eine Schuko-
Steckdose gesteckt wird. Das System selbst kann nicht als
Masseverbindung verwendet werden, weil es bei allen Arbeiten vom Netz
getrennt wird.
Voltage:
WARNUNG
Vor dem Ausführen dieser Verfahren ist die Stromzufuhr des Systems auszuschalten und
das System vom Stromnetz zu trennen. Wenn der Strom vor dem Öffnen des Systems nicht
ausgeschaltet wird, besteht die Gefahr von Körperverletzungen und Beschädigungen des
Gerätes. Im Gerät sind gefährliche Spannungen, Strom und Hochenergie vorhanden. An
den Anschlußpunkten der Betriebsschalter können gefährliche Spannungen anliegen, auch
wenn sich der Schalter in der ausgeschalteten Position befindet. Das System darf nicht bei
abgenommener Gehäuseabdeckung betrieben werden. Vor dem Einschalten des Systems
ist die Gehäuseabdeckung stets anzubringen.
Sicherheits- und Betriebsnormen

Diese Systeme entsprechen den Sicherheits- und Betriebsnormen, die für einzelne Geräteteile
gelten. Es ist jedoch möglich, dieses Produkt mit anderen Einzelteilen zusammen zu
verwenden, die ein System ergeben, welches nicht den Systemrichtlinien entspricht. Da Avaya

Notice for Germany
nicht voraussehen kann, welche Geräte mit diesem Gehäuse verwendet werden oder wie
dieses Gehäuse verwendet wird, sind der Systemintegrator und der Installateur völlig dafür
verantwortlich, daß das gesamte fertiggestellte System den Sicherheitsanforderungen von UL/
CSA/VDE sowie den EMI/HFI-Emissionsgrenzen entspricht.
Vorsichtshinweise zur Lithium-Batterie

Dieses System enthält Lithium-Batterien.
Caution:
VORSICHT
Bei einem inkorrekten Auswechseln der Lithium-Batterien besteht Explosionsgefahr.
Wechseln Sie die Batterien nur mit dem gleichen oder einem gleichwertigen Batterietyp, der
von dem Hersteller empfohlen ist, aus. Entsorgen Sie gebrauchte Batterien gemäß den
Herstelleranweisungen.
Caution:
VORSICHT
Bitte nehmen Sie vor Ort keine Wartung bzw. Austausch der Lithium-Batterien selber vor.
Um die Batterien sachgemäß warten oder auswechseln zu lassen, setzen Sie sich mit Ihrem
Avaya Servicevertreter in Verbindung.
Installation in ein 19-Zoll-Rack

Um das Gerät in ein Rack einzubauen, gehen Sie folgendermaßen vor:
Caution:
VORSICHT
Befestigen Sie das Chassis nicht oben am Rack. Ein kopflastiges Rack kann Umkippen und
Geräte beschädigen sowie Personal verletzen.
Um Verletzungen von Personen oder Beschädigungen der Geräte zu vermeiden sollten
folgende Schritte von zwei Personen ausgeführt werden.
1. Schieben Sie das Chassis vorne in das Rack.
2. Befestigen Sie das Chassis mit Schrauben. (Um Genaueres über die hierzu
empfohlenen Schraubenarten zu erfahren, wenden Sie sich bitte an den Hersteller
des Racks.)
3. Stellen Sie sicher daß der Netzschalter (ON/OFF oder EIN/AUS) am Chassis auf
OFF (O) gestellt ist. Ist Ihr System mit einem Spannungswahlschalter versehen, so
stellen Sie den Schalter auf die Ihrem Standort gemäße Betriebsspannung.

4. Stecken Sie das Sockelende des Chassisnetzkabels in die Netzsteckbuchse an der

Rückseite des Chassis.
5. Installieren Sie alle Kommunikationskabel.
6. Stecken Sie alle Netzkabel in eine geerdete, gegen Spannungsspitzen geschützte
Schuko-Steckdose.
7. Um den Netzstrom einzuschalten, stellen Sie den Netzschalter (ON/OFF) an der
Rückseite des Chassis auf ON (1). Die normale Startroutine des Systems erfolgt,
und das System ist dann einsatzbereit.
Voltage:
WARNUNG
Vor Wartungsarbeiten am Chassis ist das Netzkabel vom Stromnetz zu trennen, um die
Gefahr eines elektrischen Schlages oder andere mögliche Gefahren zu reduzieren.

Chapter 5: Data network planning for VoIP
Contents
Data network planning for VoIP on page 46
100BaseTx IP connectivity on page 48
Introduction
Warning:
properly.
NN43001-260.
The data network's infrastructure, engineering, and configuration are critical to achieve
satisfactory IP Telephony voice quality. A technical understanding of data networking and Voice
over IP (VoIP) is essential for optimal performance of the Avaya CS 1000E system.
See Avaya Converging the Data Network with VoIP Fundamentals, NN43001-260 for detailed
information about network requirements. These requirements are critical to the system Quality
of Service (QoS).

Data network planning for VoIP

Consider the following when planning the network:
• system network requirements (for ELAN and TLAN subnets)
• basic data network requirements for Call Server to Media Gateway connections, including
the following:
- jitter
- delay
- bandwidth
- LAN recommendations
• basic data network requirements for IP Phones
- bandwidth
• power requirements for IP Phones
Evaluating the existing data infrastructure

Evaluate the existing data infrastructures (LAN and WAN) to confirm their suitability for VoIP
deployment. In some cases, VoIP deployment requires additional bandwidth, improved
performance and QoS, and greater availability.
To evaluate voice performance requirements, review such items as device inventory, network
design, and baseline information about network performance. Links and devices must have
sufficient capacity to support additional voice traffic. You may need to upgrade links that have
high peak or busy hour utilization.
When assessing the environment, target devices with the following characteristics:
• high CPU utilization
• high backplane utilization
• high memory utilization
• queuing drops
• buffer misses for additional inspection
• potential upgrade
Peak utilization characteristics in the baseline are valuable in determining potential voice
quality issues.

Planning deployment of a CS 1000E system on a data network
To evaluate requirements for the VoIP network, review network topology, feature capabilities,
and protocol implementations. Measure redundancy capabilities of the network against
availability goals with the network design recommended for VoIP.
Evaluate the overall network capacity to ensure that the network meets overall capacity
requirements. Overall capacity requirements must not impact existing network and application
requirements. Evaluate the network baseline in terms of the impact on VoIP requirements.
To ensure that both VoIP and existing network requirements are met, it can be necessary to
add one or more of the following:
• memory
• bandwidth
• features
Planning deployment of a CS 1000E system on a data

network
To deploy the CS 1000E system on a data network, consider the following data networking
details and see Avaya Converging the Data Network with VoIP Fundamentals, NN43001-260:
• VoIP technology
- H.323 protocols
- Session Initiation Protocol (SIP)
- VoIP concepts and protocols
- Real-time Transport Protocol (RTP)
- Codecs including G.711 and G.729
• data network architecture
- TCP/IP
- IP subnetting
- routing protocols including EIGRP, OSPF, RIP, and BGP
• data services and peripherals
- DNS
- DHCP
- TFTP
- Web server
- QoS

QoS planning
An IP network must be engineered and provisioned to achieve high voice quality performance.
It is necessary to implement QoS policies network-wide to ensure that voice packets receive
consistent and proper treatment as they travel across the network.
IP networks that treat all packets identically are called "best-effort networks". In a best-effort
network, traffic can experience varying amounts of delay, jitter, and loss at any time. This can
produce speech breakup, speech clipping, pops and clicks, and echo. A best-effort network
does not guarantee that bandwidth is available at any given time. Use QoS mechanisms to
ensure bandwidth is available at all times, and to maintain consistent, acceptable levels of loss,
delay, and jitter.
For planning details for QoS, see Avaya Converging the Data Network with VoIP
Fundamentals, NN43001-260.
Core network planning

CS 1000E IP Telephony network design consists of two networks:
1. ELAN (Embedded LAN) subnet
2. TLAN (Voice LAN) subnet
The ELAN (Embedded LAN) subnet, isolates critical telephony signaling between the Call
Server and the other components. The TLAN (Telephony LAN) subnet, carries telephony,
voice, and signaling traffic, and connects to the customer network and the rest of the world.
100BaseTx IP connectivity
Between the Call Server and Media Gateway, the CS 1000E supports 100BaseTx IP
connectivity or campus data network connectivity. Campus data network connectivity is
provided through ELAN and Layer 2 switches.
To satisfy voice quality requirements, adhere to applicable engineering guidelines. See Avaya
Converging the Data Network with VoIP Fundamentals, NN43001-260 for details. Contact the
local Data Administrator to obtain specific IP information.

Campus network system requirements
Campus network system requirements

The following campus network system requirements are necessary:
• The ELAN subnet and the TLAN subnet must be separate.
• ELAN subnet applications must be on the same subnet. This includes the Voice Gateway
Media Cards, which must be on the same ELAN subnet.
• Voice Gateway Media Cards in the same node must be on the same TLAN subnet.
• Use of the VLAN concept is a practical way to maintain the same subnet for remote
locations.
See Avaya Converging the Data Network with VoIP Fundamentals, NN43001-260 for
information about basic data network and LAN requirements for Call Server to Media Gateway
connections, including the following:
• Packet Delay Variation (PDV) jitter buffer
• bandwidth planning
• LAN recommendations for Excellent Voice Quality
• monitoring IP link voice quality of service
• basic data network requirements for IP Phones
- bandwidth requirements
- bandwidth planning
Media conversion devices

Third-party media conversion devices can extend the range of the 100BaseTx and convert it
to fiber. Use caution when extending the length of cable used with a media converter. Do not
exceed the specified round-trip delay parameters.


Chapter 6: System architecture
Contents
Main components and architecture on page 51
Communication Server 1000E Call Server on page 56
Media Gateway on page 66
Signaling Server on page 84
Terminal Server on page 90
Layer 2 switch on page 91
Power over LAN (optional) on page 92
Telephones on page 93
Component dimensions on page 94
Main components and architecture

A typical Avaya Communication Server 1000E (Avaya CS 1000E) solution is composed of a
Call Server, Media Gateway, and Signaling Server. You can also add components such as
Layer 2 switches and optional Terminal Servers.
• The Call Server provides call processing capability. You can deploy an Avaya CS 1000E
Standard Availability, High Availability, or Co-resident Call Server and Signaling Server.
(see Communication Server 1000E Call Server on page 56)
• The Media Gateway cabinet or chassis platform provides the CS 1000E system with IPE
card slots for connection of telephones and trunks. The Media Gateway houses the
Gateway Controller and can house Server cards. Call Servers can support up to 50 Media
Gateways and optional Avaya CS 1000 Media Gateway 1000E (Avaya MG 1000E)
expander chassis. (see Media Gateway on page 66 ).

System architecture
• The Signaling Server provides the CS 1000E system with SIP/H.323 signaling between
components. Signaling Servers (total number required depends on capacity and
survivability levels). (see Signaling Server on page 234)
• The Layer 2 switch provides the CS 1000E system with additional ports to transmit data
packets to devices interconnected by Ethernet to the ELAN or TLAN subnets (see Layer
2 switch on page 91).
• The Terminal Server is an option that provides the CS 1000E system with additional serial
ports for applications and maintenance. For more information about the MRV Terminal
Server , see Terminal Server on page 90.
CS 1000E systems can be configured for either Standard Availability, High Availability (system
redundancy), or Co-resident Call Server and Signaling Server (Co-res CS and SS).
Figure 4: CP PM Standard Availability on page 53 shows the typical main components of a
Standard Availability CP PM Communication Server 1000E solution.
Figure 5: Co-resident Call Server and Signaling Server on page 54 shows the typical main
components of a Co-resident Call Server and Signaling Server CS 1000E solution.
Figure 6: CP PM High Availability on page 55shows the typical main components of a High
Availability CP PM equipped CS 1000E solution.
Figure 7: CP PIV High Availability on page 56 shows the typical main components of a High
Availability CP PIV equipped CS 1000E solution.
Important:
CP PIV equipped CS 1000E cannot be configured for Standard Availability. CS 1000E
systems equipped with a stand-alone CP PM processor can be configured for Standard
Availability or upgraded to High Availability with an additional CP PM processor and software
package 410 HIGH_AVAIL HIGH AVAILABILITY. CS 1000E systems with Co-resident Call
Server and Signaling Server cannot be configured for High Availability. The remainder of
this chapter discusses each component in further detail.
The Communication Server 1000E system supports various types of hardware platforms. You
must ensure that your hardware platform can support your target CS 1000E configuration. For
more information about supported roles for each hardware platform, see Table 1: Hardware
platform supported roles on page 24

Figure 4: CP PM Standard Availability

System architecture
Figure 5: Co-resident Call Server and Signaling Server

Figure 6: CP PM High Availability

System architecture
Figure 7: CP PIV High Availability
Communication Server 1000E Call Server

The CS 1000E Call Server serves as the call processor for the CS 1000E system. You can
deploy a Call Server in a stand-alone Standard Availability (SA), stand-alone High Availability
(HA) or in a Co-resident Call Server and Signaling Server (Co-res CS and SS) configuration.
You can add another CP PM to a stand-alone SA system to create a CP PM equipped HA
system (redundant system).
The CS 1000E SA and HA system software is VxWorks based. The CS 1000E Co-res CS and
SS software is Linux based.

Functional description
The Call Servers provide the following functionality:
• provide main source of call processing
• process all voice and data connections
• control telephony services
• control circuit cards installed in Media Gateways
• provide resources for system administration and user database maintenance
Operating parameters
The CS 1000E can be equipped as SA (single Call Server) or High Availability (dual Call Server)
(Core 0 and Core 1) to provide a fully redundant system. The CP PIV supports High Availability
only. The Co-resident Call Server and Signaling Server does not support High Availability.
Core 0 and Core 1 can operate in redundant mode over the High Speed Pipe (HSP) with
software package 410 HIGH_AVAIL HIGH AVAILABILITY: one runs the system while the other
runs in a warm standby mode, ready to take over system control if the active Call Server
fails.
The system configuration and user database are synchronized between the active and inactive
Call Servers. This lets the inactive Call Server assume call processing in the event of failure
of the active Call Server.
The Call Server uses a proprietary protocol to control the Media Gateways. This proprietary
protocol is similar to industry-standard Media Gateway Control Protocol (MGCP) or H.248
Gateways.
CS 1000E Call Servers can control up to 50 Media Gateways.
The Call Servers provide connectivity to telephony devices using IP signaling through Media
Gateways rather than by direct physical connections.
The CS 1000E system supports lineside T1 (NT5D14) and lineside E1 (NT5D34) cards. For
further information about T1/E1 lineside cards, see Avaya Circuit Card Reference,
NN43001-311
Physical description of a CP PIV Call Server

Figure 8: CS 1000E CP PIV Call Server (front and rear) on page 58 shows the front (without
cover) and rear of one Call Server.

System architecture
Figure 8: CS 1000E CP PIV Call Server (front and rear)
CP PIV Call Server hardware components
Similar to the set of core circuit cards used in CS 1000M Large System, each CP PIV Call
Server contains the following:
• CP PIV Call Processor card
• System Utility card
In addition, each Call Server is equipped with the following modules:
• Power supply module
• Alarm/fan module
CP PIV Call Processor card
The CP PIV Call Processor card (NT4N39AA) is the main processor for the Call Server,
controlling all call processing and telephony services. It also provides the system memory
required to store operating software and customer data.
The CP PIV Call Processor card provides the following connectors:
• The Com 1 port is an RS232 serial port you directly connect to a system terminal for
system access. You can optionally connect the Com 1 port to an IP-based Terminal

Server, which provides standard serial ports for system maintenance and third-party
applications (for more information, see Terminal Server on page 90).
• The Com 2 port is an additional RS-232 port (for system maintenance only).
• The LAN 1 Ethernet port connects the Call Server to the Embedded LAN (ELAN) subnet
through an ELAN Layer 2 switch to provide IP connections between the Call Server,
Signaling Servers, and Media Gateways. The port is a 10/100/1000MB autonegotiate
port.
• The LAN 2 Ethernet port connects Call Server 0 to Call Server 1 over a 1 Gbps auto
negotiating high speed pipe to provide communication and database synchronization.
• The USB port is not supported by the CS 1000E system and cannot be used.
System Utility card
The System Utility card (NT4N48) provides auxiliary functions for the Call Server.
The minimum vintage for the System Utility card with CS 1000E is NT4N48BA.
System Utility card functions include:
• LCD display for system diagnostics
• interface to the Call Server alarm monitor functions
• Core-selection DIP switches to specify Call Server 0 or Call Server 1
• software security device holder
The software security device enables the activation of features assigned to the CS 1000E
system. The security device for a CS 1000E Call Server is similar to the one used on a CS
1000M Large System
Filler Blank
The filler blank covers over the disk carrier slot used in the older CP PII-based system. The
blank supports the blue LEDs that illuminate the Logo.
Power supply module
The AC power supply module (NTDU65) is the main power source for the Call Server and is
field-replaceable.
Alarm/fan module

System architecture
The alarm/fan module (NTDU64) provides fans for cooling the Call Server and provides status
LEDs indicating the status of Call Server components. The alarm/fan module is field-
replaceable.
Physical description of a CP PM Call Server

Figure 9: CS 1000E Media Gateway with CP PM Call Server (front) on page 61 shows the
front (without cover) of a NTDU14 Media Gateway 1000E chassis. For a CP PM Call Server
configuration, the Media Gateway contains a Media Gateway Controller (MGC) card and Call
Processor Pentium Mobile (CP PM) card.
Figure 10: Option 11C cabinet upgraded to CS 1000E CP PM Call Server on page 62 shows
the front (without cover) of an Option 11C cabinet upgraded with MGC and CP PM cards.

Physical description of a CP PM Call Server
Figure 9: CS 1000E Media Gateway with CP PM Call Server (front)

System architecture
Figure 10: Option 11C cabinet upgraded to CS 1000E CP PM Call Server
CP PM Call Server hardware components

Each CP PM Call Server requires the following hardware:
• CP PM supported chassis:
- Option 11C cabinet (except for slot 0)

CP PM chassis
- Option 11C Mini chassis (except for slot 0 and slot 4)

- Option 11C Mini expander chassis
- Avaya Media Gateway 1000E main chassis (except for slot 0)
- Avaya Media Gateway 1000E expander chassis
- Media Gateway 1010 (except for slot 0)
- IPE module with MG XPEC card (except for controller slot)
• CP PM card
• MGC card with DSP daughterboards in each Media Gateway chassis or cabinet
• MG XPEC card in each IPE module
CP PM chassis
The CP PM is a circuit card that you insert in a Media Gateway. For more information, see
Media Gateway on page 66 . For information about upgrading Option 11C equipment to
support the CP PM card, see Avaya Communication Server 1000E Upgrades,
NN43041-458.
For information about upgrading CS 1000M IPE modules to support CS 1000E Server cards,
see Avaya Communication Server 1000M and Meridian 1 Large System Planning and
Engineering, NN43021-220 and Avaya Communication Server 1000E Installation and
Commissioning, NN43041-310.
CP PM card
The Common Processor Pentium Mobile (CP PM) card can be configured as a Call Server.
The CP PM offers similar features to that of the CP PIV processor, but uses an IPE slot form
factor, allowing for a CS 1000E product with only a single Media Gateway chassis. The CP PM
card can also be configured as a stand-alone Signaling Server, or a Co-resident Call Server
and Signaling Server.
Figure 11: CP PM card NTDW61 on page 64 shows the CP PM faceplate and CP PM circuit
card. The NTDW61 CP PM card is designed for use in Media Gateway IPE slots.
The NTDW99 CP PM card contains a metal faceplate that provides enhanced EMC
containment. The NTDW99 CP PM card is designed for use in Media Gateway 1010 chassis
slots 22 and 23.

System architecture
Figure 11: CP PM card NTDW61
CP PM hardware includes the following components and features:

• Intel Pentium M processor
• Integrated Intel 855MGE GMCH/Intel ICH-4 controller chipset

Co-resident Call Server and Signaling Server hardware components
• Two Compact Flash sockets: 1 GB fixed media disk (FMD) on the card and a hot swap
removable media disk (RMD) accessible on the faceplate
• 1 GB DDR RAM (expandable up to 2 GB)
• Three Ethernet ports (TLAN, ELAN, HSP):
• One USB 2.0 port, for future use
• Security device, housed on board
CP PM System Utility functionality

The CP PM Call Server solution does not require an external System Utility (SUTL) card. The
CP PM provides similar SUTL functionality without requiring any external hardware. Instead
of setting a switch to indicate the CPU side information, side settings are configured from the
overlays or from the installation program. SUTL functionality provides a redundancy LED (CPU
display), and security device.
Co-resident Call Server and Signaling Server hardware

components
You can deploy a Co-resident Call Server and Signaling Server (Co-res CS and SS) with
various hardware platforms. The Co-res CS and SS hardware platforms run the Linux Base
Operating System. The following Servers support the Co-res CS and SS configuration:
• Common Processor Pentium Mobile (CP PM)
• Common Processor Dual Core (CP DC)
• Common Processor Media Gateway (CP MG)
• Commercial off-the-shelf (COTS) servers
- IBM x3350 server (COTS2)
- Dell R300 server (COTS2)
- HP DL360 G7 server (Avaya Common Server)
For a description of each Server hardware platform, see Avaya Circuit Card Reference,
NN43001-311.
During hardware installation, the Server circuit cards (CP PM, CP DC, CP MG) are inserted
into a Media Gateway cabinet or chassis. COTS2 and Common Servers are inserted into
standard 19" racks. Each Co-res CS and SS requires a Gateway Controller in a Media
Gateway. The Gateway Controller can be a Media Gateway Controller (MGC) card, or a
Common Processor Media Gateway (CP MG) card. The CP MG card functions as a Co-res
CS and SS, and a Gateway Controller while occupying slot 0 in a Media Gateway.

System architecture
For more information about Co-res CS and SS, see Avaya Co-resident Call Server and
Signaling Server fundamentals, NN43001-509. For information about installing or configuring
Co-res CS and SS applications, see Avaya Linux Base and Applications Installation and
Commissioning, NN43001-315
Media Gateway
Media Gateways provide basic telephony media services, including tone detection, generation,
and conference to CS 1000E telephones. The Media Gateway houses IPE circuit cards and
connectors for access to the Main Distribution Frame. The Media Gateway with Media Gateway
Controller (MGC) supports digital trunk and PRI access to the PSTN and to other PBX systems.
The Media Gateway also supports Avaya Integrated Applications, including Integrated
Recorded Announcer. It can also provide connectivity for digital and analog (500/2500-type)
telephones as well as analog trunks for telephone and fax.
Media Gateway hardware

The term Media Gateway refers to the following Media Gateway hardware types:
• MG 1000E chassis (NTDU14) and Media Gateway Expander chassis (NTDU15)
• Option 11C Mini chassis (NTDK91) and Option 11C Mini Expander chassis (NTDK92)
• Option 11C cabinet (NTAK11)
• MG 1010 chassis (NTC310)
• IPE module (NT8D37) with MG XPEC card (NTDW20)
For a physical description of the Media Gateway hardware, see Avaya Communication Server
1000E Overview, NN43041-110
The Branch Office uses the same Media Gateway hardware. For more information about
Branch Office, see Avaya Branch Office Installation and Commissioning, NN43001-314 .
The Media Gateway provides the following functionality:
• tones, conference, and digital media services (for example, Music and Recorded
Announcement) to all phones
• support for CallPilot and Avaya Integrated Applications
• direct physical connections for analog (500/2500-type) phones, digital phones, and fax
machines

Media Gateway
• direct physical connections for analog trunks

• provides digital trunks to the PSTN and trunking to other PBX systems using E1, T1, and
ISDN BRI circuit cards
• supports analog trunks
• supports Voice Gateway Media Cards for transcoding between IP and TDM
• supports the DECT application
Circuit cards
The following circuit cards are supported in Media Gateways:
• One Gateway Controller card is required in each Media Gateway chassis or cabinet. See
Media Gateway Controller (MGC) card on page 68 or Common Processor Media
Gateway (CP MG) card on page 71 for Gateway Controller card details.
• An MG XPEC card in each IPE module. SeeMedia Gateway Extended Peripheral
Equipment Controller (MG XPEC) card on page 72 for card details.
• Server cards (CP PM, CP DC, CP MG).
• Voice Gateway Media Cards. See Voice Gateway Media Card on page 81 for card
details.
• Intelligent Peripheral Equipment (IPE) cards. See Operating parameters on page 67 for
specific cards supported on Media Gateways.
For more information about circuit cards, see Avaya Circuit Card Reference, NN43001-311.
Security device
The security device on the Media Gateway is a generic security device that allows Media
Gateways to register with the CS 1000E Call Servers.
Control for the activation of features assigned to the CS 1000E system, including Media
Gateways, is provided by the security device on the System Utility card in CP PIV systems,
and the security dongle on all other supported hardware platforms.
For more information about security devices, see Avaya Security Management,
NN43001-604.
The Media Gateway operates under the direct control of the Call Server. Up to 50 Media
Gateways can be configured on the Call Server.
To allow IP Phones to access digital media services, you must configure Media Gateways with
Digital Signal Processor (DSP) ports. The MGC with DSP daughterboards can provide up to

System architecture
128 DSP ports, or 256 DSP ports when configured as a PRI Gateway. The CP MG card is
available with 32 or 128 DSP ports. You can install Voice Gateway Media Cards into a Media
Gateway to provide additional DSP ports beyond the DSP port limit of the Gateway Controller
card.
The Media Gateways support the following circuit cards and applications:
• Voice Gateway Media Cards: transcode between the IP network and digital circuit cards
• Service cards: provide services such as Music or Recorded Announcements (RAN)
• Analog interfaces to lines and trunks: support analog (500/2500-type) phones and fax,
analog PSTN trunks, and external Music or RAN sources
• Analog trunk cards
• Digital line cards: support digital terminals, such as attendant consoles, M2000 and Avaya
3900 Series Digital Deskphones, and external systems that use digital line emulation,
such as Avaya CallPilot Mini
• Digital PSTN Interface Cards, including E1, T1, and ISDN Basic Rate interfaces: provide
access to PSTN
• CLASS Modem card (XCMC)
• DECT Mobility cards
• Avaya Integrated Applications, including:
- Integrated Conference Bridge
- Integrated Call Assistant
- Integrated Call Director
- Integrated Recorded Announcer
- Hospitality Integrated Voice Services
- MGate cards for CallPilot
- CallPilot IPE
Digital Trunks, PRI and BRI, and DECT Mobility Cards are only supported in Media Gateways
with MGC.
Media Gateway Controller (MGC) card
The MGC card occupies the system controller slot 0 in a Media Gateway chassis.
The MGC card provides a gateway controller for IP Media Gateways in a CS 1000E system.
The MGC only functions as a gateway controller under control of a CS 1000E Call Server.
The MGC card supports up to 128 DSP ports with the two expansion sites to accommodate
digital signal processor daughterboards. 128-port DSP daughterboard NTDW78, 96-port DSP
daugherboard NTDW64 and 32-port DSP daughterboard NTDW62 can be installed on the

Media Gateway
MGC. The DSP daughterboards support VoIP voice gateway resources on the MGC, reducing
the amount of separate Voice Gateway Media Cards.
The MGC DSP daughterboard security feature provides an infrastructure to allow endpoints
capable of SRTP/SRTCP to engage in secure media exchanges. The media security feature
can be configured by the administrator or, optionally, by the end user. This feature provides for
the exchange of cryptographic material needed by the SRTP-capable endpoints to secure
media streams originating from those endpoints.
For more information about Media Security or SRTP, see Avaya Security Management,
NN43001-604.
DSP daugherboards include voice gateway (VGW) application; they do not include the
Terminal Proxy Server (TPS) application. DSP daughterboards cannot be used for load sharing
of IP Phones from Signaling Servers, or as backup TPS in case of failures.
Figure 12: Media Gateway Controller card (NTDW60) on page 70 shows the MGC faceplate
and MGC circuit card (with two DSP daughterboards installed).
The MGC card (NTDW98) contains a metal faceplate for enhanced EMC containment. The
NTDW98 MGC card is designed for use in a Media Gateway 1010 chassis.

System architecture
Figure 12: Media Gateway Controller card (NTDW60)
The MGC card (without expansion daughterboards) includes the following components and
features:
• Arm processor
• 128 MB RAM
• 4 MB boot flash
• Internal Compact Flash (CF) card mounted on the card. It appears to the software as a
standard ATA hard drive
• Embedded Ethernet switch
• Six 100 BaseT Ethernet ports for connection to external networking equipment
• Four character LED display on the faceplate
• Two PCI Telephony Mezzanine Card form factor sites for system expansion

Media Gateway
• Real time clock (RTC)

• Backplane interface
• Three serial data interface (SDI) ports
Figure 13: NTDW63 MGC adapter for Option 11C
When installing an MGC in an Option11C cabinet, a NTDW63 adapter is required to provide

ports for Ethernet and clock reference.
Important:
The MGC is a gateway controller that replaces the SSC in a Media Gateway. It also reduces
the need for separate Voice Gateway Media Cards with the use of onboard DSP
daughterboards. The MGC-based Media Gateway supports PRI/PRI2/DTI/DTI2 trunks, BRI
trunks, D-channels, and clock controllers. The MGC remote SDI feature reduces the need
for separate Terminal Servers.
For more information about the MGC card, see Avaya Circuit Card Reference,
NN43001-311.
Common Processor Media Gateway (CP MG) card
The hardware for the Common Processor Media Gateway (CP MG) card consists of integrating
a Common Processor, a Gateway Controller, and non-removable Digital Signal Processor
(DSP) resources into a single card for use in a Communication Server 1000E system. The CP
MG card design is based on the CP PM card and MGC card with DSP daughterboards. The
CP MG card is available in two versions:
• NTDW56BAE6 - CP MG card with 32 DSP ports
• NTDW59BAE6 - CP MG card with 128 DSP ports
The CP MG card provides improvements in port density and cost reductions by functioning as
a Co-resident Call Server and Signaling Server (Co-res CS and SS) and a Gateway Controller
with DSP ports while only occupying one slot in a Media Gateway cabinet or chassis. The CP
MG card occupies the system controller slot 0 in a Media Gateway.
The CP MG card includes the following components and features:
• Intel EP80579 integrated processor, 1200 Mhz (Common Processor)
• 2 GB DDR2 RAM (expandable to 4 GB)

System architecture
• 160 GB SATA hard drive

• USB to 1-wire bridge chip from Intel processor to security device
• One faceplate USB 2.0 port for software installations and upgrades
• Two faceplate Common Processor TTY serial ports
• Mindspeed Chagall-2 processor M82515 to run Avaya proprietary software (MGC, tone
and conference)
• SPI flash for BIOS storage
• Compact Flash card (ATA) for Chagall-2 file system
• Onboard flash boot-ROM
• Three backplane TTY ports, two from Chagall-2, one from Intel Common Processor
• Mindspeed Picasso M82710 or Matisse M82910 for VoIP or DSP resources
• Ten port embedded fast Ethernet switch
• One faceplate 100 BaseT T-LAN port
• One faceplate 100 BaseT E-LAN port
• One backplane 100 BaseT T-LAN port
• One backplane 100 BaseT E-LAN port
• Faceplate status LED and card reset buttons
• In-rush power controller to support hot-plug
The Gateway Controller component of the CP MG card is based on the same architecture as
the MGC card. For more information about the Gateway Controller architecture, see Media
Gateway Controller (MGC) card on page 68. The Gateway Controller component of the CP
MG card registers with the Call Server with an Internet Protocol Media Gateway (IPMG) type
of MGS. The Communication Server 1000E system uses a common Gateway Controller
loadware for the MGC, MG XPEC, and MGS.
For more information about the CP MG card, see Avaya Circuit Card Reference,
NN43001-311.
Media Gateway Extended Peripheral Equipment Controller (MG

XPEC) card
You can convert NT8D37 Communication Server 1000M and Meridian 1 large system IPE
modules into Communication Server 1000E Media Gateways with the Media Gateway
Extended Peripheral Equipment Controller (MG XPEC) card. The MG XPEC card provides a
solution to migrate IPE modules from a Meridian 1 TDM system, or CS 1000M system to a CS
1000E system. The MG XPEC card converts one IPE module into two Media Gateway shelves
(type MGX) for use in a CS 1000E system.
The NTDW20 MG XPEC card replaces the NT8D01 controller card in the controller slot of a
NT8D37 IPE module. The MG XPEC card is a dual card assembly that contains a motherboard

Media Gateway
and a daughterboard. Each board of the dual assembly contains 192 non-removable Digital
Signal Processor (DSP) ports. The MG XPEC card is essentially equivalent to two Media
Gateway Controller (MGC) cards. The MG XPEC motherboard controls slots 0 to 7 on the left
half of the IPE module, and the MG XPEC daughterboard controls slots 0 to 7 on the right half
of the IPE module.
For information about converting an IPE module into Media Gateways with the MG XPEC card,
see Avaya Communication Server 1000M and Meridian 1 Large System Planning and
Engineering, NN43021-220.
Network connections
The ELAN of the Media Gateway can reside in a separate layer 3 subnet from that of the Call
Server ELAN. When connecting the Media Gateway to the ELAN through a Layer 3 switch the
connection from the Call Server to the Media Gateway must have a round trip delay of less
than 80 msec and have a packet loss of less than 0.5 % (0% recommended).
Figure 14: Redundant network connections with MGC Dual Homing on page 74 is a
schematic representation of redundant network connections for Media Gateways with MGC.
The call servers, signaling servers, switches, and chassis can be any of the supported
types.

System architecture
Figure 14: Redundant network connections with MGC Dual Homing
The separate LAN subnets that connect the Media Gateway and the Call Server to the
customer IP network are as follows:
• ELAN The ELAN subnet (100BaseT, full-duplex) is used to manage signaling traffic
between the Call Server, Signaling Server, and Media Gateways. The ELAN subnet
isolates critical telephony signaling between the Call Servers and the other
components.
• TLAN The TLAN subnet (100BaseT, full-duplex) is used to manage voice and signaling
traffic. It connects the Signaling Server and Voice Gateway Media Cards to the Customer
LAN. It also isolates the IP Telephony node interface from broadcast traffic.
The HSP (high speed pipe) is a 1000BaseT connection used to provide standby call server
redundancy. The HSP provides connectivity for High Availability if two CP PM or CP PIV call
servers are connected through the HSP, and the Campus Redundancy software package 410
HIGH_AVAIL HIGH AVAILABILITY has been purchased. The HSP is not supported on Co-res
CS and SS configurations.
Avaya CS 1000 Media Gateway 1000E

The CS 1000E Call Server can connect to and control a maximum of 50 Avaya CS 1000 Media
Gateway 1000Es (Avaya MG 1000E) with optional Media Gateway Expanders. Each Avaya
MG 1000E houses a Gateway Controller and contains four slots for IPE cards. Each MG 1000E

Media Gateway
supports an optional Media Gateway Expander through copper connections for a total of eight
slots.
Physical description
The following sections describe the front and rear components of the MG 1000E (NTDU14).
Front components
Figure 15: Front components in the MG 1000E (NTDU14) on page 75 shows the Media
Gateway with the front cover removed. Note the following:
• The DIP switches configure telephone ringing voltages, ringing frequencies, and message
waiting voltages.
• The 100BaseT bulkhead ports 1 and 2 provide MGC daughterboard ports with
connections to rear bulkhead ports.
Figure 15: Front components in the MG 1000E (NTDU14)

System architecture
Rear components
Figure 16: Rear components in the MG 1000E on page 76 shows the rear components on
the Media Gateway. Note the following:
• The AC power cord connector provides AC connection to the Media Gateway.
• AUX extends Power Failure Transfer Unit (PFTU) signals to the Main Distribution Frame
(MDF).
• GND is used for ground cable termination.
• 100BaseT bulkhead ports 1 and 2 provide connections from IP daughterboard ports on
the MGC card to other system components.
• The Attachment Unit Interface (AUI) is used with cards that require a Media Access Unit
(MAU).
• The AUI is used with MGC cards as a clock reference. When the AUI connection is used
with an MGC, Ethernet link and speed LEDs cannot function.
• The serial port connects to maintenance terminals.
• DS-30X and CE-MUX interconnect the Media Gateway to the Media Gateway
Expander.
• 25-pair connectors extend the IPE card data to the MDF.
Figure 16: Rear components in the MG 1000E

Media Gateway
Media Gateway Expander

The Media Gateway Expander supports up to four circuit cards. The Media Gateway Expander
can directly support the Server cards. A Gateway Controller card in the corresponding MG
1000E controls each card in an Expander. Digital trunk interface packs are not supported in
the Media Gateway Expander.
Figure 17: Media Gateway Expander (NTDU15) on page 77 shows the Media Gateway
Expander (NTDU15).
Figure 17: Media Gateway Expander (NTDU15)
Rear components
Figure 18: Rear components in the Media Gateway Expander on page 78 shows the rear
components in the Expander. Note the following:
• The AC power cord connector provides an AC connection to the Expander.
• GND is used for ground cable termination.
• DS-30X and CE-MUX are used to interconnect the Media Gateway and the Expander.
• 25-pair connectors are used to extend IPE card data to the MDF.

System architecture
Figure 18: Rear components in the Media Gateway Expander
Media Gateway 1010

The Media Gateway 1010 (MG 1010) is a rack mount Media Gateway chassis that provides a
larger amount of card slots than a MG 1000E with Media Gateway Expander. The CS 1000E
Call Server can connect to and control a maximum of 50 MG 1010s. Each MG 1010 provides
a dedicated Gateway Controller slot, two dedicated Server card slots, and ten slots for IPE
cards. The MG 1010 is a single chassis that can provide more processing power and card
capacity than a MG 1000E with the optional Media Gateway Expander.
The Media Gateway 1010 chassis (NTC310AAE6) consists of:
• MG 1010 rack mount kit (NTC316AAE6)
• backplane assembly (NTC31002)
• Media Gateway Utility (MGU) card (NTC314AAE6)
• power supply, maximum of two with load sharing (NTC312AAE6)
• blower fans, N+1 arrangement for redundant cooling (NTC320AAE6)
• air filter (NTC315AAE6)
• front cover with EMC containment and a window to view status LEDs
• MG 1010 serial cable kit (NTC325AAE6)

Media Gateway
Metal faceplate Server cards and Gateway Controller cards are required for enhanced EMI
containment. Avaya recommends you to use metal CP PM card (NTDW99) and metal MGC
card (NTDW98) in a MG 1010. All CP MG and CP DC cards contain metal faceplates.
The following sections describe the front and rear components of the MG 1010 (NTC310).
Front components
Figure 19: Front components in the MG 1010 on page 79 shows the Media Gateway 1010
without the front cover. Note the following:
• Ten IPE card slots
• Two Server card slots
• One Gateway Controller card slot
• One Media Gateway Utility (MGU) card provides LED status, ringing, message waiting
voltage, dual homing Ethernet cable ports, and serial cable ports
• One metal divider in chassis to separate MGU, Server cards, and Gateway Controller
card from the IPE cards.
Figure 19: Front components in the MG 1010
Figure 20: MG 1010 front cover on page 80 shows the MG 1010 with the front cover. Note
the following:
• Window to view LED status of all cards
• Decorative cover provides additional EMC shielding
• Two locking latches in top corners of front cover.

System architecture
Figure 20: MG 1010 front cover
Rear components
Figure 21: Rear components of the MG 1010 on page 81 shows the rear components of the
MG 1010. Note the following:
• Hot swappable redundant power supplies
• Hot swappable fans in a redundant N + 1 configuration for chassis cooling
• One DECT connector
• One AUX connector
• Ten MDF connectors

Media Gateway
Figure 21: Rear components of the MG 1010
Voice Gateway Media Card

The Gateway Controller cards can provide a limited number of DSP ports. Voice Gateway
Media Cards provide additional DSP ports for Media Gateways to translate between IP and
TDM. Voice Gateway Media Cards provide interfaces that connect to the Telephony Local Area
Network (TLAN) and Embedded Local Area Network (ELAN) subnets. The Voice Gateway
Media Card is also known as a Media Card (MC).
Figure 22: Media Card on page 82 shows faceplate connectors and indicators on the 32-port
line Media Card.
Figure 23: Media Card 32S on page 83 (MC32S) shows the faceplate connectors and circuit
card of the 32-port secure Media Card.

System architecture
Figure 22: Media Card

Media Gateway
Figure 23: Media Card 32S
The MC32S provides 32 channels of IP-TDM connectivity between an IP device and a TDM
device in the CS 1000 network. The MC32S is an IPE form factor card and can interwork with
other voice gateway application cards, such as the MGC card.
The MC32S Media Security feature provides an infrastructure to allow endpoints capable of
SRTP/SRTCP to engage in secure media exchanges. The media security feature can be
configured by the administrator or, optionally, by the end user. This feature provides for the
exchange of cryptographic material needed by the SRTP-capable endpoints to secure media
streams originating from those endpoints.
For more information about Media Security or SRTP, see Avaya Security Management,
NN43001-604.
For more information about Media Card features or the IP Line application, see Avaya Signaling
Server IP Line Applications Fundamentals, NN43001-125.

System architecture
Signaling Server
Main role
The Signaling Server provides SIP and H.323 signaling between components in a CS 1000E
system.
The hardware platforms supported as stand-alone Signaling Servers are CP PM, CP DC, and
Commercial off-the-shelf (COTS) Servers. Available COTS servers are IBM x306m, IBM
x3350, HP DL320 G4, HP DL360 G7, and Dell R300 servers.
The Communication Server 1000E Linux Platform Base includes many operational,
performance, and security hardening updates. The User Access Control (UAC) introduces
eight Linux groups to define user privileges. Central Authentication provides user
authentication across the security domain with single password. The Emergency Account
allows you to log on through the Command Line Interface (CLI) if both the Primary and
Secondary UCM are offline. Secure File Transfer Protocol (SFTP) is the default file transfer
protocol. You must explicitly identify FTP users, all users can use SFTP.
The Linux Platform Base operating system installs on the Signaling Server and can run multiple
applications, including:
• SIP and H.323 Signaling Gateways
• Terminal Proxy Server (TPS)
• Network Routing Service (NRS)
• SIP Line Gateway (SLG)
• Element Manager
• Application Server for Personal Directory (PD), Callers List (CL), Redial List (RL), and
Unicode Name Directory (UND) for UNIStim IP Phones
SIP Line Gateway includes:
• SIP Line (SIPL)
• SIP Management Service, an Element Manager (EM) system management interface you
use to configure and manage the SIP Line Service.
NRS includes:
• H.323 Gatekeeper
• SIP Proxy Server

Signaling Server
• SIP Redirect Server

• NCS
The Signaling Server has both an ELAN and TLAN network interface. The Signaling Server
communicates with the Call Server through the ELAN network interface.
CP PM Signaling Server physical description

Figure 24: CP PM Signaling Server card and faceplate on page 86 shows the CP PM
Signaling Server. Two versions of the CP PM Signaling Server are available, each designed
for use in the CS 1000M or CS 1000E chassis, however they are functionally identical.
NTDW61 single slot CP PM card for Media Gateway chassis, or Option 11C cabinets. NTDW66
double wide faceplate CP PM card for CS 1000M Large System IPE cubes.
The NTDW99 CP PM card is an update to the NTDW61 CP PM card. It is functionally identical,
however it contains a metal faceplate for enhanced EMC containment. The NTDW99 CP PM
card is designed for use in a Media Gateway 1010 chassis.

System architecture
Figure 24: CP PM Signaling Server card and faceplate
CP PM Signaling Server hardware components

The CP PM Signaling Server hardware is based on the same board design as the CP PM Call
Server. The CP PM Signaling Server uses a fixed media device (hard drive), as opposed to
the Compact Flash drive on the CP PM Call Server. The CP PM Signaling Server is populated
with 2 GB of SDRAM. CP PM card on page 63 provides further details the CP PM hardware
components.
CP DC Signaling Server physical description

The Common Processor Dual Core (CP DC) card is a Server card for use in Communication
Server 1000E and Communication Server 1000M systems. The CP DC card is designed to

Signaling Server
replace the Common Processor Pentium Mobile (CP PM) card. The CP DC card contains a
dual core AMD processor and upgraded components which can provide improvements in
processing power and speed over the CP PM card. The CP DC card requires the Linux Base
Operating System, and supports Co-resident Call Server and Signaling Server, or stand-alone
Signaling Server configurations.
The CP DC card is available in two versions:
• NTDW53AAE6 - single slot metal faceplate CP DC card (CS 1000E).
• NTDW54AAE6 - double slot metal faceplate CP DC card (CS 1000M).
The CP DC card provides performance improvements in MIPS, maximum memory capacity,
and network transfer rate, and occupies one IPE slot in a Media Gateway.
CP DC Signaling Server hardware components

The CP DC card includes the following components and features:
• AMD Athlon 64 X2 1.8 Ghz dual core processor
• 2 GB DDR2 RAM
• 160 GB SATA hard drive
• Three faceplate USB 2.0 ports for software installations, upgrades, patching, and USB
keyboard and mouse support
• One faceplate VGA port for monitor support
• Two faceplate Gigabit Ethernet ports
• Faceplate status LED and card reset buttons
You can use a USB 2.0 storage device to install or upgrade the Linux Base Operating System.
The CP DC card does not support Compact Flash (CF) cards.
An NTDW5309E6 2 GB memory upgrade kit is available for Media Application Server (MAS)
deployments. This upgrades a CP DC card to a total of 4 GB DDR2 RAM.
COTS Signaling Server physical description

Commercial off-the-shelf Signaling Servers are multivendor servers based on 1U rack-
mounted server chassis design.

System architecture
COTS Signaling Server hardware components

IBM x306m and HP DL320 G4 (COTS1) Signaling Servers provide the following features:
• Intel Pentium 4 processor at 3.6 GHz
• One 80 GB SATA simple swap hard drive (2 front bays, 1 used)
• 2 GB PC2-4200 ECC DDR2 SDRAM (4 DIMM slots, 2 used)
• Two 10/100/1000BaseT Ethernet ports
• Four USB 2.0 ports (2 front, 2 back)
• One slim line CD-RW/DVD ROM drive
• One serial port
IBM x3350 and Dell R300 (COTS2) and HP DL360 G7 (Common Server) Signaling Servers
provide the following features:
• Intel Xeon quad-core processor (minimum of 2.4 GHz)
• Two simple swap Serial-attached SCSI (SAS) or SATA hard drives (minimum of one 75
GB hard drive)
• 4 GB of RAM PC2-5300 DDR II with error correcting code (ECC)
• Two 10/100/1000BaseT Ethernet ports
• Four USB 2.0 ports
• One slim line CD-RW/DVD ROM drive
• One serial port
COTS servers do not have an INI button. COTS servers have a reset button on the front panel
to perform cold starts. Software warm starts can be invoked through the command line interface
(CLI) on the servers (reboot).
Software applications
The following software components operate on the Signaling Server:
• SIP Gateway (Virtual Trunk)
- SIP Line
- SIP Management Service
• H.323 Gateway (Virtual Trunk)

Signaling Server
- SIP Redirect Server
- SIP Proxy Server
- SIP Registrar
- NRS Manager
• CS 1000 Element Manager
• Application Server for the Personal Directory, Callers List, Redial List, and Unicode Name
Directory features
Signaling Server software elements can coexist on one Signaling Server or reside individually
on separate Signaling Servers, depending on traffic and redundancy requirements for each
element.
For descriptions of the function and engineering requirements of each element, see Table 43:
Elements in Signaling Server on page 234. For detailed Signaling Server engineering rules
and guidelines, see Signaling Server algorithm on page 271. For more information about
H.323, SIP Trunking NRS and SIP Proxies see Avaya IP Peer Networking Installation and
Commissioning, NN43001-313 and Avaya Network Routing Service Fundamentals,
NN43001-130.
For more information about SIP Line and IP Line, see Avaya SIP Line Fundamentals,
NN43001-508 and Avaya Signaling Server IP Line Applications Fundamentals,
NN43001-125.
The Signaling Server provides the following functionality:
• provides IP signaling between system components on the LAN
• enables the Call Server to communicate with IP Phones and Media Gateways
• supports key software components (see Software applications on page 88)
The Signaling Server provides signaling interfaces to the IP network using software
components that run on the Linux Base operating system. For more information about the
Signaling Server Linux Base, see Avaya Linux Platform Base and Applications Installation and
Commissioning, NN43001-315.
The Signaling Server can be installed in a load-sharing, survivable configuration.

System architecture
The total number of Signaling Servers that you require depends on the capacity and
redundancy level that you require (see Signaling Server calculations on page 284).
Terminal Server
The MRV IR-8020M IP-based Terminal Server provides the Call Server with standard serial
ports for applications and maintenance.
Important:
A CS 1000E configured with a Gateway Controller does not require a separate Terminal
Server. The Gateway Controller provides serial ports for connectivity.
Figure 25: Terminal Server on page 90 shows the Terminal Server.
Figure 25: Terminal Server
Hardware components
The MRV Terminal Server provides 20 console ports for modular RJ-45 connectors. It is also
equipped with one RJ-45 10BaseT connection for network interface to the ELAN subnet and
an internal modem to provide remote access.
A CS 1000E configured with a Gateway Controller does not require a separate Terminal Server.
The Gateway Controller provides serial ports for connectivity.

Layer 2 switch
Traditionally, serial ports are used to connect terminals and modems to a system for system
maintenance. As well, many third-party applications require serial port interfaces to connect to
a PBX. Because the Call Server provides only two local serial ports for maintenance purposes,
an IP-based Terminal Server is required to provide the necessary serial ports.
The Terminal Server provides standard serial ports for applications. These applications include
billing systems that analyze Call Detail Recording (CDR) records, Site Event Buffers (SEB)
that track fault conditions, and various legacy applications such as Property Management
System (PMS) Interface and Intercept Computer applications. In addition, serial ports are used
to connect system terminals for maintenance, modems for support staff, and printers for system
output.
The Terminal Server is configured to automatically log in to the active Call Server at start-up.
For this reason, each Call Server pair requires only one Terminal Server. Customers can
configure up to 16 TTY ports for each Call Server pair.
The Terminal Server can be located anywhere on the ELAN subnet. However, if the Terminal
Server is used to provide local connections to a Com port on the Call Server, it must be
collocated with the system.
The Terminal Server can also be used as a central point to access and manage several devices
through their serial ports.
Important:
Currently, the CS 1000E only supports the MRV IR-8020M commercial Terminal Server.
Layer 2 switch
The Layer 2 switch transmits data packets to devices interconnected by Ethernet to the ELAN
or TLAN subnets. The switch only directs data to the target device, rather than to all attached
devices.
ELAN Layer 2 switch

Figure 26: ELAN Layer 2 switch (Ethernet Routing Switch 2550T) on page 92 shows an
example of an ELAN Layer 2 switch.

System architecture
Figure 26: ELAN Layer 2 switch (Ethernet Routing Switch 2550T)
TLAN Layer 2 switch

To provide Layer 2 connections on the TLAN subnet, Avaya recommends the Ethernet Routing
Switch 2526T, which has embedded Power-over-LAN capabilities for powering IP Phones.
Optionally, other Power-over-LAN units can also be used to provide power to IP Phones.
Figure 27: TLAN Layer 2 switch (Ethernet Routing Switch 2526T) on page 92 shows the
Ethernet Routing Switch 2526T.
Figure 27: TLAN Layer 2 switch (Ethernet Routing Switch 2526T)
These components must be supplied by the customer. For more information, see Avaya
Converging the Data Network with VoIP Fundamentals, NN43001-260.
Power over LAN (optional)

An optional Power over LAN unit adds power and data communication over standard Category
5 LAN drops for powering IP Phones. The Power over LAN unit eliminates the need to connect
each telephone to an AC power outlet. This saves in desktop wiring and enables the use of a
centralized Uninterruptable Power Supply (UPS) for power backups. Using a Power over LAN
unit eliminates the need to use a separate power transformer for each IP Phone.

Telephones
For more information, see Avaya Converging the Data Network with VoIP Fundamentals,
NN43001-260.
Telephones
The CS 1000E system supports the following:
• IP Phones
- IP Phone 2001
- IP Phone 2002
- IP Phone 2004
- Avaya 2007 IP Deskphone
- Avaya 1120E IP Deskphone
- Avaya 2050 Mobile Voice Client (MVC)
- Avaya 2050 IP Softphone
- Avaya 2033 IP Conference Phone
- WLAN Handset 2210, 2211 and 2212
- IP Phone Key Expansion Module (KEM)
• analog (500/2500-type) telephones
• digital deskphones
• attendant consoles
• DECT handsets
• 802.11 Wireless LAN terminals

System architecture
Component dimensions
All rack mount components fit in 19-inch racks. Table 4: Height dimension of CS 1000E
components on page 94 lists the height of each rack mount component. COTS Servers
require the use of 4 post racks.
Option 11C cabinet is a supported CS 1000E enclosure. Option 11C cabinets are 25" high x
22" wide. They can be wall or floor mounted. Option 11C cabinets are not rack mountable.
Table 4: Height dimension of CS 1000E components
Component Height
NTDU62 CP PIV Call Server 3U
Signaling Server (COTS) 1U
NTDU14 Media Gateway <5U
NTDU15 Media Gateway Expander <5U
NTC310 Media Gateway 1010 9U
MRV Terminal Server 1U
Ethernet Routing Switch 2526T 1U
Ethernet Routing Switch 2550T 1U
1 U = 4.4 cm (1-3/4 in.)
The clearance in front of rack-mounted equipment is the same for all major components. For
the Call Servers, Media Gateways, and Media Gateway Expanders, the distance from the
mounting rails of the rack to the front of the bezel/door is 7.6 cm (3 in.).

Chapter 7: Configuration options
Contents
Fax/Modem pass through on page 96
Recommendations for Fax configuration in the CS 1000 system on page 98
Option 1: Campus-distributed Media Gateways on page 101
Option 2: Campus Redundancy on page 102
Option 3: Branch Office on page 103
Option 4: Geographic Redundancy Survivable Media Gateway on page 104
Introduction
The IP-distributed architecture of the Avaya Communication Server 1000E (Avaya CS 1000E)
enables flexibility when it comes to component location. Given this flexibility, the Avaya CS
1000E offers many configuration options to support increased system redundancy.
The CS 1000E can be deployed in LAN and WAN environments. Most fall into one of the
following categories:
• Multiple buildings in a campus
- Campus-distributed Media Gateways
- Campus Redundancy
• Multiple sites
- Central Call Server with Branch Office
- Geographic Redundancy
- Geographic Redundancy Survivable Media Gateway

Configuration options
These configurations provide CS 1000E systems with many options for redundancy and
reliability. Careful planning is required to determine the configuration that is appropriate for
your needs.
The following sections describe each of these configuration options.
Fax/Modem pass through

The Fax/Modem pass through feature provides a modem pass through allowed (MPTA) class
of service (CLS) for an analog phone TN. MPTA CLS dedicates an analog phone TN to a
modem or a Fax machine terminal. A connection that initiates from the dedicated TN, and/or
calls that terminate at the dedicated TN through a Digital Signal Processor (DSP), use a G711
NO VAD codec on the Call Server.
Modem Pass through is a specific configuration of a G.711 VoIP channel that improves modem
performance compared to standard VoIP configuration. Automatic switch to Voice Band Data
(VBD) is a feature of the DSP; the DSP monitors the data stream to distinguish between voice
and data calls. The DSP reconfigures to modem pass through mode when it determines the
call is a modem call.
For modem calls between CS 1000 systems connected by analog and digital trunks, you must
configure MPTA CLS on the Call Server of each CS 1000 system for analog units connected
to modems. MPTA CLS configuration is necessary because the call setup negotiation is not
done end to end as it is for virtual trunks. If the analog unit on one Call Server uses MPTA CLS
and the analog unit on the other Call Server uses modem pass through denied (MPTD) CLS,
the modem call fails.
MPT CLS is supported by the G.711 codec only; MPT CLS includes no other codecs. The
packet interval for G.711 codec is set to 20 msecs in MPT.
The maximum speed supported for modem and fax is 33.6 Kbps. This limit is imposed by the
analog line card.
MPT allows CS 1000 to support the following:
• modem pass through
• Super G3 (SG3) fax at V.34 (33.6 Kbps)
• V.34 rate (33.6 Kbps) modems
• Fax machines that support V.17, V.27, V.29, and V.34 protocols
For interface commands, responses, and definitions for MPT see Table 5: Interface commands
and responses on page 96.
Table 5: Interface commands and responses
Command prompt User response Description

CLS MPTA Turn on the MPT feature.
CLS MPTD Turn off the MPT feature.

Modem traffic
Note:
CLS MPTA and MPTD is included in LD10 for analog line card units.
For information about feature packaging requirements see Table 6: Feature packaging
requirements on page 97.
Table 6: Feature packaging requirements
Package Package Package description Package type Applic

mnemonic number (new, existing, or able
dependency) market
Softswitch 402 Identifies a softswitch system. Existing All
Media 403 Identifies a system that is Existing All
Gateway equipped with Media Gateways.
Modem traffic
The CS 1000E supports modem traffic in a campus-distributed network with the following
characteristics:
• Media Card configuration:
- G.711 codec
- 20 msec packet size
• one-way delay less than 5 msec
• low packet loss
• V.34 rate (33.6 Kbps)
Performance degrades significantly with packet loss.
Modem and fax traffic performance is improved with Modem/Fax Pass Through Allowed
(MPTA) class of service in an analog phone TN. The call server selects a G.711 codec with no
Voice Activity Detection (VAD) to setup the call. Call Server disconnection or slow modem and
fax data rates caused by closing the voice connection and reconnecting with T.38 codec have
been eliminated with MPTA.
The CS 1000E supports Modem Pass Through and Super G3 (SG3) fax at V.34 (33.6 Kbps).
You can configure MPTA for a TN, and the codec used by the DSP for that TN will be G.711
NO VAD only.
Performance degrades significantly with packet loss. Packet loss and latency in modem pass
through mode can degrade connectivity rate, throughput rate and drop calls.
If you plan to route modem calls through analog trunks, you must configure the line cards for
the modems and the analog trunks to route in the same Media Gateway. Delay issues can also

be addressed by using a baud rate of 2400 baud or lower on the modem, provided the customer
needs can be met at the low baud rate.
Avaya recommends you use digital trunks and only hardware modems in large systems which
require modems and a large number of trunks. Do not deploy software modems across different
Media Gateways regardless of the trunk type. Replace software modems with hardware
modems or other IP interfaces.
The following hardware modems have been tested with the Communication Server 1000E
using digital trunks:
• U.S. Robotics 5637
• U.S. Robotics 5685E
• U.S. Robotics 5699B
The guidelines listed above must be considered for upgrades to a CS 1000E system from a
Option 11C or CS 1000M. Some configuration changes may be necessary.
Important:
Avaya has conducted extensive but not exhaustive tests of modem-to-modem calls, data
transfers, and file transfers between a CS 1000E and Media Gateway, using Virtual Trunks
and PRI tandem trunks. While all tests have been successful, Avaya cannot guarantee that
all modem brands will operate properly over all G.711 Voice over IP (VoIP) networks. Before
deploying modems, test the modem brand within the network to verify reliable operation.
Contact your system supplier or your Avaya representative for more information.
Recommendations for Fax configuration in the CS 1000

system
Fax settings and performance over Voice over IP (VoIP) solutions vary depending on the
network configuration. In order to achieve a successful faxing environment, the VoIP solution
must be engineered properly. This section describes the configuration and network design
aspects that need to be taken into consideration when implementing faxing in VoIP
solutions.
CODECs:
T.38:
• Older fax machines use V.21
• For lower speeds such as V.21, T.38 protocol should be used in the VoIP segments of the
call

Recommendations for Fax configuration in the CS 1000 system
Modem pass-through (G.711):

• Newer fax machines use modem protocols to achieve higher speeds (V.34)
• The Modem pass-through feature is intended for modems and high speed faxes
employing V.34, using clear channel G.711 over the VoIP segments of the call.
• The Modem pass-through feature detects the phase reversal tone negotiation used for
higher speeds and instructs the Digital Signal Processors (DSPs) involved in the call to
disable echo cancellation and all other non-linear components.
• The Modem Pass-Through Denied (MPTD) class of service (CoS) for analog fax lines
allows the DSPs to switch between T.38 protocol for lower speeds and G.711 protocol for
higher speeds.
• The MPTD CoS must be used on analog line card (ALC) units connected to fax machines
when there are trunk cards present in the IP Media Gateway (IPMG) and other IPMGs
that connect to the TN. The MPTD class of service is required in order to support T.38
and V.34 faxes that could originate or terminate from/to the TN.
• In order for MPTD CoS to work, a system bandwidth strategy of BQ (Best Quality) must
be used.
• The Modem Pass-Through Allowed (MPTA) CoS should be used only for modems, as it
will force all calls to use G.711 protocol.
• When going to the TN, there is no control over the far-end; however, if the far-end supports
T.38 and Modem pass-through, speeds of 33.6 Kbps should be achievable.
Important:
Fax performance at higher speeds (33.6 Kbps) requires that all network elements are
properly engineered to support it. When high speed faxes cannot be achieved with a
consistent success rate, Avaya recommends that the fax units be set at a lower speed (14.4
Kbps).
Typical scenarios
Typical scenarios for faxing in a CS 1000E solution are:
• two faxes connected to analog lines in the same Media Gateway Controller (MGC)
• two faxes connected to analog lines in different MGCs of the same CS 1000E system
• one fax connected to an analog line in an MGC, to an IP trunk, to a remote system with
a fax
• one fax connected to an analog line in an MGC, to an analog trunk in the same MGC,
and then to a TN (Local or Long Distance (LD)) fax

• one fax connected to an analog line in an MGC, to a digital trunk in the same MGC, and
then to a TN (Local or LD) fax
• one fax connected to an analog line in an MGC, to a digital trunk in a different MGC of
the same CS 1000E system, to a TN (Local or LD) fax
Note:
The following scenario is not supported for faxing: one fax connected to an analog line in an
MGC, to an analog trunk in a different MGC of the same CS 1000E system, to a TN (Local or
LD) fax.
Recommendations for faxing in a data network

Depending on the fax scenario used, fax calls can traverse the IP network, either internally
(e.g., MGC to MGC) or externally (e.g., IP trunks). It is important to engineer the data network
to support the following:
• Media card configuration:
- G.711/T.38 codecs
- 20 ms packet size
• Round trip delay must be less than 50 ms
• Packet loss must be less than 0.5%
• V.34 rate (33.6 Kbps) can be used as long as the far end supports the Modem pass-
through feature
• Mean jitter is less than 5 ms
Important:
Performance degrades significantly with packet loss (must be less than 0.5%) and when the
delay (round trip) is greater than 50 ms and the mean jitter is greater than 5 ms.
Important:
Avaya conducted extensive but not exhaustive test of fax calls in different scenarios. While
all tests succeeded, Avaya cannot guarantee that all fax brands can operate properly over
all G.711 Voice over IP (VoIP) networks. Before you deploy faxes, test the fax within the
network to verify reliable operation. Contact your system supplier or your Avaya
representative for more information.

Option 1: Campus-distributed Media Gateways
Configuration for analog line cards connected to faxes

The typical configuration recommended for analog line cards connected to faxes is as follows:
• MGCs:
- Enable Modem pass-through mode in the Element Manager
- Enable V.21 FAX tone detection in the Element Manager
- Set Voice Gateway (VGW) trunks to the zone with Best Quality (BQ)
• Analog lines:
- Use Class of Service FAXA to set the proper trunk capability for fax calls
- Use Class of Service Modem Pass-Through Denied (MPTD). This setting allows lower
speed faxes (up to 14.4 Kbps) to use T.38, and higher speed faxes to use G.711 clear
channel (no echo cancellation, no non-linear DSP features)
Option 1: Campus-distributed Media Gateways

With multiple buildings in a campus, you can distribute Media Gateways across a campus IP
network. Figure 28: Campus-distributed Media Gateways on page 102 shows Media
Gateways distributed across multiple buildings in a campus setting.

Figure 28: Campus-distributed Media Gateways
In this configuration, a CS 1000E system is installed at the main site, and additional Media
Gateways and an optional Signaling Server are installed at a second campus site. All IP
Phones are configured and managed centrally from the main site.
For details on the specific operating and network parameters for the Media Gateway, see
Media Gateway on page 66.
Option 2: Campus Redundancy

With Campus Redundancy, customers can separate the Call Server pair across a campus IP
network by extending the HSP over a network. As determined by software, the individual call
processors are referred to as Call Server Core 0 and Call Server Core 1. The distance depends
upon network parameter limitations specified in Avaya System Redundancy Fundamentals,
NN43001-507. This provides additional system redundancy within a local configuration. The
Call Servers function normally and the inactive Call Server assumes control of call processing
if the active Call Server fails.

Option 3: Branch Office
To do this, the ELAN subnet and the subnet of the High Speed Pipe (HSP) are extended
between the two Call Servers using a dedicated Layer 2 Virtual LAN configured to meet
specified network parameters. Figure 29: Campus Redundancy configuration on page 103
shows a CS 1000E system in a Campus Redundancy configuration. For more information, see
Avaya System Redundancy Fundamentals, NN43001-507.
Figure 29: Campus Redundancy configuration
Option 3: Branch Office

The CS 1000E system supports the Branch Office feature, which provides central
administration of Media Gateways at remote sites. Figure 30: Branch Office configuration on
page 104 shows a CS 1000E system with an Media Gateway installed at a remote branch
office.

Figure 30: Branch Office configuration
In this configuration, the Branch Office Media Gateway is survivable. This ensures that
telephone service remains available if the main office fails. For more information about Branch
Office, see Avaya Branch Office Installation and Commissioning, NN43001-314. For more
information about Survivable Media Gateway, see Avaya System Redundancy Fundamentals,
NN43001-507.
Option 4: Geographic Redundancy Survivable Media

Gateway
Geographic Redundancy Survivable Media Gateway is an enhancement over Geographic
Redundancy. A Geographic Redundancy Survivable Media Gateway configuration consists of
1 primary Call Server and up to 50 secondary Call Servers that can be configured as alternate
Call Server 1 or alternate Call Server 2.
Geographic Redundancy Survivable Media Gateway provides primary Call Server
redundancy, WAN failure redundancy, and both IP and TDM resources redundancy. If the
primary Call Server or WAN fails, each configured alternate Call Server provides service to the
peripheral equipment and resources that it has been assigned.
The Geographic Redundancy Survivable Media Gateway replication system has a single
database, administered on the primary Call Server and replicated to all secondary Call Servers.

Media Gateway and Voice Gateway Media Card Triple Registration
Figure 31: Geographic Redundancy Survivable Media Gateway configuration on

page 105shows the different paths of registration and replication.
TDM resources redundancy is achieved by Media Gateway and Voice Gateway Media Card
Triple Registration on page 105.
Figure 31: Geographic Redundancy Survivable Media Gateway configuration
For more information about Geographic Redundancy Survivable Media Gateway, see Avaya
System Redundancy Fundamentals, NN43001-507.
Media Gateway and Voice Gateway Media Card Triple

Registration
Media Gateways equipped with MGC enhance redundancy by providing survivability over
Layer 3 connections for network-dispersed Media Gateways. Redundancy is performed by
allowing the Media Gateway to register to either primary Call Server, alternate Call Server 1,
or alternate Call Server 2.
In normal mode, all Media Gateways in a CS 1000E are registered on the primary Call Server,
and the primary Call Server provides service to all resources in the system. During a primary
Call Server failure, the Media Gateway first attempts to connect to the primary Call Server
without a service interruption using the Dual-Homing feature of the MGC. If a connection to

the primary Call Server cannot be established, the Media Gateway reboots and registers to its
configured alternate Call Server 1.
During a WAN failure, the Media Gateway reboots and registers to its configured alternate Call
Server 2. Once the alternate Call Server connection is established, the Media Gateway can
provide service to the resources in its own area.
When the Media Gateway is registered to any of the alternate Call Servers, it continues to poll
configured Call Servers. When the primary Call Server is detected, the Media Gateway can
automatically switch back to register with the primary Call Server if the registration switching
policy is defined as automatic. Switching policy can also be set to manual and the Media
Gateway remains registered to an alternate Call Server until a command is entered.
With Voice Gateway Media Card Triple Registration, the Voice Gateway Media Card can
register with the primary Call Server, alternate Call Server 1, or alternate Call Server 2. The
Voice Gateway Media Card is configured with three IP addresses: primary, alternate 1, and
alternate 2. The IP addresses of the three Call Servers must be defined on the Media Card
level. To avoid the Media Gateway and Voice Gateway Media Card registering on different
alternate Call Servers during a primary Call Server failure, the Media Gateway sends a
message to Voice Gateway Media Card in each Media Gateway to register with the same
alternate Call Server that the Media Gateway is registered with.

Chapter 8: Planning reliability strategies
Contents

Response to different points of failure on page 108
Call Server failure on page 108
Network failure on page 109
Signaling Server failure on page 110
NRS failure on page 111
NRS failure fail-safe on page 112
CS 1000E resiliency scenarios on page 113
Call Server failure on page 114
Signaling Server failure on page 116
NRS failure on page 117
Branch Office scenarios on page 119
Alternate Call Servers and survivability on page 125
IP telephony node configuration on page 125
Alternate Call Server considerations on page 126
Campus survivable Media Gateway considerations on page 127
Configuring for survivability on page 128
Introduction
Reliability in the Avaya Communication Server 1000E (Avaya CS 1000E) system is based on:

Planning reliability strategies
1. The reliability/mean time between failures (MTBF) of components

2. Data Network robustness
3. End-point survivability
4. MGC dual-homing
Communications reliability is critical to the operation of any business. A number of capabilities
are available in Avaya CS 1000E system to ensure that telephony is available when:
• a hardware component fails
• a software component fails
• the IP network suffers an outage
The CS 1000E system provides several levels of redundancy to ensure that the telephony
services can withstand single hardware and network failures. The following component
redundancy is provided:
• Call Server with automatic database distribution by the way of configured alternate Call
Servers
• Signaling Server software, including Session Initiation Protocol (SIP) Gateway, H.323
Gateway, and IP Phone software
• Network Routing Service (NRS), including H.323 Gatekeeper
• Campus-distributed Media Gateways in Survival Mode
Response to different points of failure

The following topics describe possible failure points and suggested remedies.
• Call Server failure on page 108. See Call Server failure on page 108.
• Network failure on page 109. See Network failure on page 109.
• Signaling Server failure on page 110. See Signaling Server failure on page 110.
• NRS failure on page 111. See NRS failure on page 111.
• NRS failure fail-safe on page 112. See NRS failure fail-safe on page 112.
Call Server failure

Figure 32: Call Server failure on page 109 shows a network-wide view of Call Server failure.

Figure 32: Call Server failure
Alternate Call Server

This situation applies when the CS 1000E equipment is collocated and not widely
distributed.
When planning reliability strategies, provision one Media Gateway as an alternate Call Server
1 within the IP Telephony node. To support an alternate Call Server 1, the installer must
configure the alternate Call Server IP address in Element Manager.
If the primary Call Server fails, as shown in Figure 32: Call Server failure on page 109, the
Media Gateway assigned as an alternate Call Server 1 assumes the role of the Call Server.
The Signaling Servers register to alternate Call Server 1 and system operation resumes.
Operation resumes with single Media Gateway cards, such as analog and PRI cards.
Network failure
Figure 33: Network failure with Survivable Media Gateway on page 110 illustrates a network
failure with Survivable Media Gateway.

Figure 33: Network failure with Survivable Media Gateway
Campus-distributed Media Gateway in Survival Mode

Media Gateways equipped with CP PM can be configured as survivable when distributed
throughout a campus environment. Therefore, basic telephony services can be provided in the
event of a network outage. When planning for survivable Media Gateway, consider the location
of critical telephones and trunks.
Signaling Server failure

Figure 34: Signaling Server failure on page 111 illustrates the failure of a Signaling Server.

Figure 34: Signaling Server failure
Signaling Server redundancy

Signaling Server redundancy provides a load-sharing basis for the IP Phone Terminal Proxy
Server (TPS) and an alternate route for the NRS and SIP and H.323 Gateway software.
When planning Signaling Server survivability strategies, a second or redundant Signaling
Server should be installed. As shown in Figure 34: Signaling Server failure on page 111, two
Signaling Servers can load-share when the Media Gateway contain multiple Media Cards.
Also, one Signaling Server is a lead Signaling Server that acts as the primary, master TPS.
The other Signaling Server is a follower Signaling Server that acts as a secondary, redundant
TPS, Virtual Trunk, and NRS.
If the lead Signaling Server fails, an election process takes place and the follower Signaling
Server becomes the master TPS. The IP Phones reregister to the follower Signaling Server
and the system operation resumes. If the follower Signaling Server fails, the IP Phones that
were registered to the follower Signaling Server reregister to the lead Signaling Server.
NRS failure
Figure 35: NRS failure on page 112 illustrates an NRS failure.

Figure 35: NRS failure
NRS redundancy
Figure 35: NRS failure on page 112 depicts a distributed environment where the TPS and NRS
software reside with Call Server A and Call Server B on their own Signaling Server.
The NRS, TPS, and Gateway software can all reside on a single Signaling Server. Furthermore,
primary software, the TPS, and the SIP and H.323 Gateways can all reside on Call Server A,
while the second instance of NRS software can reside on a separate Signaling Server with the
TPS.
CS 1000E networks are equipped with at least one NRS to provide management of the network
numbering plan for private and public numbers. An optional redundant NRS can be installed
in the network. This alternate NRS automatically synchronizes its database with the primary
NRS periodically.
When planning NRS survivability strategies, install a second or redundant NRS. If the primary
NRS fails, the alternate NRS assumes control. The Gateways time out and register to the
alternate NRS. Network calls resume.
NRS failure fail-safe

Figure 36: NRS failure fail-safe on page 113 illustrates NRS fail-safe.

CS 1000E resiliency scenarios
Figure 36: NRS failure fail-safe
In addition to NRS redundancy, SIP and H.323 Gateway interfaces can withstand
communication loss to both NRS by reverting to a locally cached copy of the Gateway
addressing information. Since this cache is static until one NRS becomes accessible, it is only
intended for a brief network outage.
The NRS can be configured as primary, alternate, or Fail-safe. If both NRS fail or a network
outage to an NRS occurs, the Gateways route calls using cached data until communication to
the NRS resumes.

This section describes the following resiliency scenarios:
• Call Server failure on page 114 (see Call Server failure on page 114)
• Signaling Server failure on page 116 (see Signaling Server failure on page 116)
• NRS failure on page 117 (see NRS failure on page 117)
• Branch Office scenarios on page 119 (see Branch Office scenarios on page 119)
Refer toFigure 37: CS 1000E on page 114 when reviewing these scenarios.

Figure 37: CS 1000E
Call Server failure
Resiliency Scenario 1
IP Phone 2004 A1 and A2 are talking over the LAN and Call Server A fails.
What happens to the call in progress?
The call stays up until the Media Gateway is finished rebooting, and then the call is dropped.
Describe what happens:
Media Gateway A reboots and, if it is configured as an alternate Call Server, it begins taking
over all call processing. The Signaling Server reregisters to the alternate Call Server so service
can be restored for all IP Phones.
Minutes before the call described in the situation can be initiated:
1.5 minutes for the Media Gateway reboot plus switchover timer. (Default for switchover timer
is 2 minutes.)

IP Phone 2004 A1 and IP Phone 2004 B2 are talking and Call Server A fails.
Same as Scenario 1.
The call stays up until the Media Gateway is finished rebooting, and then it is dropped.
Same as Scenario 1.
Media Gateway A reboots and if it is configured as an alternate Call Server, it begins taking
Same as Scenario 1.
1.5 minutes for reboot plus switchover timer. (Default for switchover timer is 2 minutes.)
IP Phone 2004 A1 is talking to someone locally or off-net over a PSTN trunk in Media Gateway
A, and Call Server A fails.
Same as Scenario 1.
The call stays up until the Media Gateway is finished rebooting, and then it is dropped.
Same as Scenario 1.
Media Gateway A reboots and if it is configured as an alternate Call Server, it begins taking
Same as Scenario 1.
1.5 minutes for reboot plus switchover timer. (Default for switchover timer is 2 minutes.)

Signaling Server failure
IP Phone 2004 A1 and IP Phone 2004 B2 are talking and Signaling Server A fails. A redundant
Signaling Server is configured on Site A.
• 50% of calls on Site A stay up for 2.5 minutes, and then are dropped.
• The other 50% of telephones registered to the redundant Signaling Server on Site A do
not drop the call.
• IP Phone A1 (that is, 50% of calls) reboots and then reregisters with the redundant
Signaling Server.
• The other 50% have no impact on the calls in progress and the telephones stay registered
to the redundant Signaling Server.
• 2 to 5 minutes depending on number of telephones (2 minutes for all telephones to realize
the first Signaling Server is not responding, and then all telephones from the first Signaling
Server reboot and start registering with the redundant Signaling Server). At this stage,
100% of telephones from Site A are registered to the redundant Signaling Server.
• Not applicable for other 50% of telephones.
IP Phone 2004 A1 and IP Phone 2004 A2 are talking and Signaling Server A fails. A redundant
Signaling Server is configured on Site A.
Same as Scenario 4.
• 50% of the calls stay up for 2.5 minutes, and then are dropped.
• Other 50% of telephones registered to the redundant Signaling Server do not drop the
call.

Same as Scenario 4.
• 50% of telephones on Site A1 reboot and then reregister with the redundant Signaling
Server.
• Other 50% are unaffected and have no impact on the calls in progress. Telephones stay
registered to the redundant Signaling Server. At this stage, 100% of the telephones from
Site A are registered to the redundant Signaling Server.
Same as Scenario 4.
• 2 to 5 minutes depending on number of telephones (2 minutes for all telephones to realize
the first Signaling Server is not responding, and then all the telephones reboot and start
registering with redundant Signaling Server).
• Not applicable for other 50% of the telephones.
NRS failure
IP Phone 2004 A1 and IP Phone 2004 B2 are talking and the primary NRS fails. An alternate
NRS is configured on Site B. Assume the primary NRS is a stand-alone box (without a TPS).
The calls in progress are unaffected.
The alternate NRS takes over as Active NRS after the 30-second polling timer expires.
There is also the Time to Live timer for the H.323 endpoints to the Gatekeeper. This timer is
usually configured shorter. This timer is also user configurable.
New calls are established following:
• the 30-second polling timer expires
• the alternate NRS switches over to the Active NRS
• the Time to Live timer expires
IP Phone 2004 A1 and IP Phone 2004 B2 are talking and the primary NRS (Signaling Server)
fails. Assume the primary NRS is Co-resident with the Signaling Server TPS on Site A. An

alternate NRS is configured on Site B. Assume the alternate NRS is Co-resident with Signaling
Server TPS on Site B. A redundant Signaling Server is configured on Site A.
Similar to Scenario 4.
• 50% of the calls on Site A stay up for 2.5 minutes, and then are dropped.
• Other 50% of the telephones registered to the redundant Signaling Server on Site A do
not drop the call.
• Calls in progress are unaffected by the NRS switchover. If transient calls (for example,
calls in ringing stage) exist, they are dropped due to the Signaling Server switchover.
• 50% of telephones on Site A (that is, 50% of the calls) reboot and then reregister with the
redundant Signaling Server.
• Other 50% have no impact on the calls in progress and telephones stay registered to the
redundant Signaling Server.
• The alternate NRS takes over as Active NRS after the 30-second polling timer expires.
• There is also the Time to Live timer for the H.323 endpoints to the Gatekeeper. This Time
to Live timer is usually configured shorter than the 30-second polling timer. This timer is
also user configurable. The Virtual Trunks from the first Signaling Server register to the
redundant Signaling Server like the telephones.
Minutes before the call described in the situation can be reinitiated:
2 to 5 minutes depending on the number of telephones (2 minutes for all telephones to realize
the first Signaling Server is not responding, and then all telephones from the first Signaling
Server reboot and start registering with redundant Signaling Server). At this stage, 100% of
the telephones from Site A are registered to the redundant Signaling Server.
For the other 50% of the telephones already registered to the redundant Signaling Server, new
calls are established following:
IP Phone 2004 A1 and IP Phone 2004 B2 are talking and both the primary and alternate NRS
fail (both are stand-alone NRS).
Same as scenario 6.

The calls in progress remain unaffected.

The primary Signaling Server uses its Fail-safe NRS after it fails to register to the other NRS.
At this point, the Fail-safe NRS cannot accept registrations from new endpoints.
Both primary and alternate NRS timers expire. New calls are established following:
Branch Office scenarios
IP Phone 2004 C1 and C2 are talking over the LAN and Call Server A fails.
The call stays up until Media Gateway A is finished rebooting, and then it is dropped.
Media Gateway A reboots at the Main Office site and acts as an alternate Call Server at Site
A. The Branch Office telephones on Signaling Server A register with the alternate Call
Server.
1.5 minutes for reboot plus switchover timer. (Default for timer is 2 minutes.)
IP Phone 2004 C1 and A2 are talking and Call Server A fails.
Same as Scenario 9.
Same as Scenario 9.

Server.
Same as Scenario 9.
IP Phone 2004 C1 and C2 are talking over the LAN and Signaling Server A fails.
The call stays up for 2.5 minutes, and then it is dropped.
C1 and C2 reboot and register with the branch office Signaling Server. The telephones are
redirected back to the Main Office to register with the redundant Signaling Server.
2 to 6 minutes; 2 to 5 minutes to reboot C1 and C2, plus the extra minute for redirection.
IP Phone 2004 C1 and A2 are talking over LAN and Signaling Server A fails.
A2 reboots and registers with the redundant Signaling Server at the Main Office. C1 reboots,
registers with the branch office Signaling Server, and then is redirected to register with the
redundant Signaling Server at the Main Office. This assumes telephones are registered to the
failing Signaling Server in this scenario. If 50% of telephones were registered to the surviving
Signaling Server, telephones and calls would proceed as per normal healthy operation.
For telephone A2, 2 to 5 minutes depending on the number of telephones (2 minutes for all
telephones to realize the first Signaling Server is not responding, and then all telephones from
the first Signaling Server reboot and start registering with the redundant Signaling Server). At
this stage, 100% of telephones from Site A are registered to the redundant Signaling Server.

For telephone C1, 2 to 6 minutes. The extra minute is needed to register to the branch office
Signaling Server and then be redirected back to the Main Office.
Not applicable for the other 50% of telephones if registered to the redundant Signaling
Server.
IP Phone 2004 C1 and C2 at the branch office are talking and the WAN data network
connection to the Main Office goes down.
Telephones C1 and C2 reboot and then reregister with the Signaling Server at the branch
office.
Minimum of 1 minute after the call is dropped. The time depends on the number of Branch
Office telephones. It is approximately 6 minutes for 400 telephones.
IP Phone 2004 C1 and A2 are talking and the WAN data network connection to the Main Office
goes down.
The speech path is lost as soon as the network connection is down.
A2 stays registered with Signaling Server A. C1 reboots and registers with Signaling Server at
the branch office.
Calls between Site A and Site C over IP only start after the WAN connection is fixed. Calls
routed over PSTN Trunks can be completed as soon as the IP Phones reboot.
IP Phone 2004 C1 is talking to someone off-net over a PSTN trunk in Branch Office C and Call
Server A fails.


Server.
IP Phone 2004 C1 is talking to IP Phone 2004 C2 and the branch office Signaling Server
fails.
No impact on the call in progress.
No impact on existing or future Branch Office IP to IP calls in progress.
Not applicable.
IP Phone 2004 C1 is talking to someone off-net over a PSTN trunk in Branch Office C and the
Signaling Server C (branch office) fails. (The behavior is the same as IP Phone 2004 A1 talking
to someone off-net over a PSTN trunk in Media Gateway B and Signaling Server B fails.)
Telephone C1 is registered to the TPS at the Main Office site. A Virtual Trunk (SIP or H.323)
session is initiated between the Signaling Server at the Main Office site and the Signaling
Server at the branch office. With the loss of the Signaling Server at the branch office, the SIP
or H.323 session fails. All idle Virtual Trunks become idle unregistered. Virtual Trunks that are
busy on established calls also become unregistered, but they remain busy until the calls are
released.

If there is no redundant Signaling Server in the branch office, calls of this type cannot be
initiated until the Signaling Server is reestablished. The call would, in this instance, be routed
out over an alternative PSTN route.
A digital telephone in the branch office is talking to someone off-net over a PSTN trunk in
Branch Office C and the Signaling Server C (branch office) fails.
The call from the digital telephone proceeds as normal. The Signaling Server does not
participate in this call.
Not applicable.
A digital telephone in the Main Office is talking to someone off net over a PSTN trunk in Branch
Office C and Signaling Server A (Main Office) fails. A redundant Signaling Server is installed
at Site A. (This is the same as a digital telephone in Media Gateway A talking to someone off-
net over a PSTN trunk in Media Gateway B and Signaling Server A fails.)
The call from the digital telephone proceeds as normal. The Signaling Server at Site A fails,
the Virtual Trunk (SIP or H.323 session) required to continue the call continues. All idle Virtual
Trunks become idle unregistered and then register with the redundant Signaling Server
installed at Site A. Virtual Trunks that are busy on established calls also become unregistered,
but they remain busy. There is no impact on the media path between the DSP connected to
digital telephone in the Main Office and that connected to the PSTN trunk. When the call is
released by the user, the Virtual Trunk in the Main Office becomes idle, and then registers with
the redundant Signaling Server installed at Site A.
The call from the digital telephone proceeds as normal with no delay. The redundant Signaling
Server at Site A initiates the Virtual Trunk (SIP or H.323 session) required to complete the
call.

A digital telephone in the Main Office Site A is talking to someone off-net over a PSTN trunk
in Branch Office C and Signaling Server A (Main Office) fails. No redundant Signaling Server
is installed at Site A. PSTN is configured as an alternate route. (This is the same as a digital
telephone in Media Gateway A talking to someone off-net over a PSTN trunk in Media Gateway
B and Signaling Server A fails.)
No impact to the call in progress.
All idle Virtual Trunks become idle unregistered. Virtual Trunks that are busy on established
calls also become unregistered, but they remain busy until the calls are released. There is no
impact on the media path between the DSP connected to the digital telephone and that
connected to the PSTN trunk.
The call from the digital telephone proceeds as normal. The PSTN from the Main Office site is
used as an alternative route to complete the call.
A digital telephone in the Main Office Site A is talking to a digital telephone in Branch Office C
and Signaling Server A (Main Office) fails. No redundant Signaling Server is installed at Site
A. PSTN is configured as an alternate route. (This is the same as digital telephone in Media
Gateway A talking to digital telephone in Media Gateway B and Signaling Server A fails.)
No impact to the call in progress.
All idle Virtual Trunks become idle unregistered. Virtual Trunks that are busy on established
calls also become unregistered, but they remain busy until the calls are released. There is no
impact on the media path between the DSP connected to digital telephone in Main Office Site
A and that connected to digital telephone in Branch Office C.
The call from the digital telephone proceeds as normal with no delay. The PSTN is used as an
alternative route to complete the call.

Alternate Call Servers and survivability
A digital telephone in the Main Office Site A is talking to IP Phone C1 in Branch Office C and
Signaling Server A (Main Office) fails. There is no redundant Signaling Server installed at Site
A.
The call stays up for 2.5 minutes on average and then it is dropped. Time varies due to
watchdog timer on the IP Phone.
IP Phones reboot and attempt to register to Signaling Server A.
IP calls between Site A and Site C are offline and can start once the Signaling Server is
fixed.

The CS 1000E system can be provisioned with 50 secondary Call Servers providing alternate
Call Server connections if the primary Call Server becomes unavailable. A Media Gateway has
two modes of operation:
• Normal Mode: the local resources of the Media Gateway are controlled by the primary
Call Server call processing
• Survival Mode: the Media Gateway configured as an alternate Call Server performs call
processing for its local resources
Configure IP telephony nodes and survivable Media Gateway for optimal operational efficiency
and reliability.
IP telephony node configuration

An IP telephony node is a grouping of Signaling Servers and Media Cards, regardless of the
location of theMedia Cards in Media Gateway. Therefore, several Media Gateways can belong
to the same node. Alternately, each Media Gateway can have its own node.
Each IP telephony node can be configured with the IP address of an alternate Call Server,
which it registers to if the Call Server is unavailable. Alternate Call Servers are Media Gateways
with MGC that are configured as survivable.
The survivable Media Gateway (alternate Call Server) IP address must be on the same ELAN
subnet as the Call Server. If the Media Gateway is on a physically different subnet, such as in

a different building, then you can use VLANs to keep IP addresses on the same logical subnet.
For further implementation details, see Avaya Converging the Data Network with VoIP
If there are different nodes in different Media Gateway, then the nodes can be configured to
register to different alternate Call Servers. This concept is desirable for optimizing system
reliability to best deal with possible system outages. Associate each IP telephony node with
an appropriate (for example, collocated) alternate Call Server.
If the node IDs are configured using the guidelines for the 'Enhanced Redundancy for IP Line
Nodes' feature, then the IP Phones can register (if needed) to an alternate node on a Media
Gateway Expander. This further improves the survivability of the IP Phones by allowing them
to register to a different node should a system outage occur on their primary node's Media
Gateway.
For a description of the enhanced redundancy for IP Line nodes, see Avaya Signaling Server
IP Line Applications Fundamentals, NN43001-125 .
Alternate Call Server considerations

The following are alternate Call Server considerations:
• Media Gateway are collocated.
• Configure one IP telephony node for the system (that is, all Media Gateway).
• Only one IP Phone Connect Server on a Signaling Server is required for the node.
• Trunks in any Media Gateway can be used by all users.
• DSP resources on Media Cards in any Media Gateway can be used by all users.
• Configure one survivable Media Gateway as the alternate Call Server for the node.
• In Normal Mode, IP Phones register with the primary Call Server.
• In Normal mode, calls can be made between all Media Gateways.
• In Survival Mode, IP Phones register with an alternate Call Server and can only use its
resources.
• In Survival mode, calls cannot be made between Media Gateways, but all their local
telephones and trunks are functional.
• Less administration is required since there is only one node to manage.

Campus survivable Media Gateway considerations

The following are campus survivable Media Gateway considerations:
• Media Gateways are in different locations.
• Configure a separate IP telephony node for each Media Gateway.
• Each Media Gateway requires an IP Phone Connect Server on the Signaling Server.
• At each Media Gateway, provision trunks to distribute traffic and for survivability.
• At each Media Gateway, provision DSP resources on the Media Cards.
• Configure each survivable Media Gateway as an alternate Call Server for its node.
• In Normal Mode, IP Phones register with the primary Call Server.
• In Normal Mode, calls can be made between all Media Gateway.
• In Survival Mode, IP Phones register with an alternate Call Server and can only use its
resources.
• In Survival Mode, calls cannot be made between Media Gateways, but all their local
telephones and trunks are functional.
• More administration is required since there is more than one node to manage.
Multiple D-channels
Avaya does not recommend you to split the Primary and Backup D-channels of the same ISDN
Trunk Group across multiple GR/CR CS 1000E Media or PRI Gateways. While this
configuration insures D-channel redundancy during some Primary D-Channel failure
situations, states could exist where both D-channels register to different Call Servers and
simultaneously activate creating a conflict in the Central Office. This conflict can affect service
and can lead to a complete ISDN Trunk Group outage in most service provider Central
Offices.
If your service provider supports ISDN Trunk Group hunting, Avaya recommends you to
maintain multiple ISDN Trunk Groups with each ISDN service provider. Configure each Trunk
Group with its own Primary and Backup D-channels on PRI circuits in each Media Gateway.
This solution offers resilient configuration in larger systems distributed geographically and
operates well even if your service provider is unable to support a D-channel for each ISDN PRI
circuit.
Avaya can provide VoIP Session Border Controllers as an alternative to large scale ISDN
Trunking facilities. This solution offers improved flexibility in deployment and resiliency
performance. For more information, see www.avaya.com/support.

Configuring for survivability

For more information about configuring survivability. see Avaya System Redundancy

Chapter 9: Telephony planning
Contents
Installation planning on page 129
Milestone chart on page 130
Evaluating existing telephony infrastructure on page 130
Telephony planning issues on page 131
Numbering plans on page 132
DTI/PRI clocking on page 133
Clocking operation on page 141
Installation and configuration on page 145
Installation planning
Use Table 7: installation planning on page 129 as a guide to prepare a detailed plan for every
installation.
Table 7: installation planning
Procedure Requirements
Research Determine requirements for fire protection and safety,
the equipment room, grounding and power, and
cables.
Site planning Select a site with suitable qualifications. Develop the site
to meet requirements. Prepare the building cabling
plan.
Delivery and installation Perform pre-installation inspections. Examine the
preparation delivery route. Review equipment handling precautions.
Gather all delivery items.

Telephony planning
Milestone chart
Site preparation activities are easier to plan and monitor when a milestone chart is used. A
milestone chart is a general schedule that shows all required activities in order, with a start and
end date for each. Individual operations and an overall installation schedule should both be
represented. Table 8: Milestone chart on page 130 lists typical activities in a milestone chart.
For a complex site, a more detailed chart can be required.
Table 8: Milestone chart
Step Action
1 Select the site and complete planning activities.
• Plan fire prevention and safety features.
• Plan the equipment room layout.
• Plan grounding and power.
• Plan cable routes and terminations.
• Plan and start any renovations to the equipment room.
2 Continue site construction and renovation tasks.

• Install grounding, power, air conditioning, and heating.
• Install special rigging, such as overhead cable racks and distribution frame
equipment, as required.
• Test site wiring to ensure that minimum requirements are met.
3 Complete construction and ensure that grounding and power are in place.
• Test air conditioning and heating systems.
• Make equipment delivery arrangements.
• Complete equipment room inspection, identifying and resolving any delivery
constraints.
Evaluating existing telephony infrastructure

To determine the best way to deploy an Avaya Communication Server 1000E (Avaya CS
1000E) system, you must evaluate the existing Telecom infrastructure. This evaluation helps
decide whether to replace existing network components or add new Avaya CS 1000E system
components.

Telephony planning issues
The Telecom infrastructure analysis examines the products, services, and features used in the
existing environment, including:
• PBX systems and locations
• system and network level features
• existing dial Plan
• supported applications
• key systems
• PBX inter-connectivity
• telephone users and features
• PSTN trunking
Telephony planning issues

To deploy the CS 1000E system, you must address the following planning issues.
• Desktop features. For details about desktop features, see the following:
- Avaya Telephones and Consoles Fundamentals, NN43001-567
- Avaya IP Phones Fundamentals, NN43001-368
• System features. For information about feature operation, see Avaya Feature Listing
Reference , NN43001-111. For information about feature configuration, see Avaya
Software Input Output Administration , NN43001-611.
• System interworking and networking. For information about Numbering and Dial Plan
Configuration, see the following:
- Avaya Electronic Switched Network Signaling and Transmission Guidelines,
NN43001-280
- Avaya Dialing Plans Reference, NN43001-283
- Avaya Basic Network Feature Fundamentals, NN43001-579
• PRI/DTI clocking. For information about PRI/DTI clocking, see the following:
- DTI/PRI clocking on page 133
- Avaya ISDN Primary Rate Interface Fundamentals, NN43001-569
- Avaya ISDN Basic Rate Interface Feature Fundamentals, NN43001-580

Telephony planning
Applications
For information about Avaya CallPilot, Symposium, and other applications, see the following:
• Avaya Automatic Call Distribution Fundamentals, NN43001-551
• CallPilot 555-7101- xxx series publications
• Symposium 297-2183-xxx series publications
• Remote Office 555-8421-xxx series publications
• MDECT 553-3601-xxx series publications
• other applications publications
Access
For information about signaling (ISDN-PRI, EIR2, CCS and CAS), see the following:
• Avaya ISDN Primary Rate Interface Fundamentals, NN43001-569
• Avaya ISDN Basic Rate Interface Feature Fundamentals, NN43001-580
For information about FXS, FXO, or ground/loop start COT trunks, see Avaya Circuit Card
Reference, NN43001-311.
Numbering plans
A CS 1000E network can use many numbering plans, depending upon dialing preferences and
configuration management requirements. Primary options include:
• Uniform Dialing Plan (UDP)
• Coordinated Dialing Plan (CDP)
• Zone Based Dialing (ZBD)
• Transferable Directory Numbers (TNDN)
See Avaya Network Routing Service Fundamentals, NN43001-130 for information about the
following:
• the Network Routing Service (NRS) and how it performs address translation
• numbering plans

DTI/PRI clocking
• call routing
• zoning plans
• collaborative servers
For more information about dialing plans, see Avaya Dialing Plans Reference,
NN43001-283.
DTI/PRI clocking
When digital signals transport over a digital communication link, the receiving end must operate
at the same frequency as the originating end to prevent data loss, this is called link
synchronization. If one end of a communication link is not synchronized, data bit slips occur
and data loss results. To ensure reliable data transfer, accurate timing is important and
synchronized timing is critical.
When only two PBX systems interconnect in an isolated private network, the two systems can
operate in master-slave mode to achieve synchronization. In master-slave mode, one system
derives its timing from the other. Slips can be lessened by forcing all systems to use a common
reference clock through a network clocking hierarchy, shown in Figure 38: Hierarchical
synchronization on page 134.

Telephony planning
Figure 38: Hierarchical synchronization
Synchronization methods
There are two common methods of maintaining timing synchronization between switching
systems:
• Pleisiochoronous operation
• Mesochronous operation

Pleisiochoronous operation
Pleisiochoronous operation
In pleisiochoronous mode, nodal clocks run independently (free-run) at the same nominal
frequency. Frequency differences between clocks result in frame slips. The magnitude of frame
slips is directly proportional to the difference in frequency. Slips, though inevitable, can be
minimized by using stable clocks and elastic stores or buffers. The buffers absorb data bits to
compensate for slight variances in clock frequencies.
Mesochronous operation
In mesochronous mode, nodal clocks are commonly and automatically locked to an external
reference clock, yielding virtually slip-free operation. With this method, frame slips are
eliminated if elastic stores are large enough to compensate for transmission variances.
If the CS 1000E system is not used as a master in a private network, Avaya recommends that
systems be configured in mesochronous mode. To do this, users can configure the clock
controller circuit cards to lock onto an external reference source.
If the CS 1000E system is used as a master in a private network, end-users can configure the
system in pleisiochoronous mode. Since a private network has no digital links to a higher node
category, a CS 1000E clock controller in an isolated private network can operate in free run
mode and act as a master clock. Other PBX systems in the private network can then track the
master clock.
North American hierarchical synchronization

Figure 38: Hierarchical synchronization on page 134 provides a general view of clock
synchronization in a digital network, including the four Stratum levels, where Stratum 1 offers
the highest accuracy and Stratum 4, the lowest. Also shown in Figure 38: Hierarchical
synchronization on page 134 are ways to provide a secondary clock source to prevent timing
loops that can cause instability in digital network synchronization.
Timing reference
In the North American network, the Primary Timing Reference is derived from a cesium beam
atomic clock.

Telephony planning
In Canada, the digital network is divided in two regions that interact plesiochronously, each
with its own cesium atomic clock. Their common boundary lies between the Manitoba
Telephone System and Bell Canada. The Eastern Region clock is located in Ottawa, the
Western region clock in Calgary. Any DS-1 signal leaving these switches is synchronized to
cesium oscillators. Every digital node in Canada (whether Central Office (CO), Digital PBX with
CO connectivity, or digital Multiplexer) can trace their clock back to the cesium oscillator in
Ottawa or Calgary. That is, unless the Digital System is operating in Pleisiochoronous
operation.
In the United States, a similar arrangement exists. The U.S. digital network is supported by
two primary clocks, one in St.Louis, Missouri, and a second in Boulder, Colorado.
Node categories/Stratum
In the North America digital network, nodes are synchronized using a priority master/slave
method. Digital networks are ranked in Node Categories A to E in Canada, as shown in Table
10: Node categories on page 137, and in Stratum levels 1 to 5 in USA. Each node is
synchronized to the highest ranking clock where the node has a direct link.
Table 9: Stratum data
Stratum 2 Stratum 3 Stratum 4

Accuracy +/- 1.6 * 10^-8 Hz +/- 4.6 * 10^-6 Hz +/- 3.2 * 10-5 Hz
Holdover 1 * 10^-10 per day <=255 frame slips in Not Required
1st 24 hours
Hardware Duplication Required Required Not Required
Non-duplicated
hardware that meets
all other Stratum 3
requirements is
referred to as
Stratum 3ND.
Maximum Time MTIE <= 1 usec MTIE <= 1 usec Not Required
Interval Error (MTIE) Phase Change Phase Change Stratum 4 clock
During Slope: <= 81 ns in Slope: <= 81 ns in hardware that meets
Rearrangement any 1.326 msec any 1.326 msec MTIE requirements
during
rearrangements is
referred to as 4E.
Pull-in Range 3.2 * 10^-8 Hz 9.2 * 10^-8 Hz 6.4 * 10^-5 Hz
Dedicated Timing Required Required Not Required
Required

Frame slip
Table 10: Node categories
AT&T Stratum Canadian Node Operating Equipment

Category
1 (Located in St. Louis A (Located in Calgary and Regional master with an associated
and Boulder) Ottawa) cesium atomic clock.
2 B, C International Gateway switch
3 D Central Office/End Office, or digital
PBX
4 E Digital PBX or Multiplexers
Frame slip
Digital signals must have accurate clock synchronization for data to be interleaved into or
extracted from the appropriate timeslot during multiplexing and de-multiplexing operations. A
frame slip is defined as the repetition or deletion of the 193 bits of a DS-1 frame due to a
sufficiently large discrepancy in the read and write rates at the buffer. Frame slips occur when
clocks do not operate at the same exact speed.
When data bits are written into a buffer at a higher rate than the bits are read, the buffer
overflows, known as a slip-frame deletion. When data bits are written into a buffer at a lower
rate than the bits are read, the buffer runs dry or under-flows, known as a slip-frame repetition.
Both occurrences are called a slip or a controlled slip. Frame slippage has a negative impact
on data transfer, but can be controlled or avoided with proper clock synchronization.
Guidelines
Design guidelines for CS 1000E Network Synchronization are as follows:
• Where possible, the master Clock Source should always be from a Node Category/
Stratum with a higher clock accuracy. When the PBX is connected to the CO, the CO is
always the master and the PBX is the slave. For example, the PBX clock controller prompt
PREF is set to the slot number of the DTI/PRI connected to the CO.
• Clock controllers within the system should not be in free-run unless they operate in a fully
independent network where the source clock controller acts as a master. Only one clock
controller in the system can operate in free-run mode.
• When connecting two PBXs together with no CO connections, the most reliable PBX
should be the master clock source.

Telephony planning
• Avoid timing loops. A timing loop occurs when a clock uses as its reference frequency, a
signal that is traceable to the output of the same clock. This produces a closed loop that
leads to frequency instability.
• All Central Offices/PBX links that serve as clock references must offer a traceable path
back to the same Stratum 1 clock source.
• If a Media Gateway has at least one DTI, PRI, or BRI trunk card, it must also have one
clock controller installed. The clock controller tracks to the same traceable reference as
the other Media Gateway.
• All slave clock controllers must set their primary reference (PREF) to the slot that they
are installed. For example, a clock controller installed in slot 9 must have its PREF set to
slot 9.
• The Media Gateway Expander does not support clock controllers.
Clock controller function and description

The NTAK20 A-series clock controller meets Stratum 3 level requirements and the NTAK20 B-
series clock controller meets Stratum 4 requirements. The embedded clock controllers on the
NTAK10 2MB DTI card, and the NTAK79 2MB PRI card meet Stratum level 4 requirements.
Clocking modes
The CS 1000E system supports up to one clock controller in each Media Gateway. Each clock
controller can operate in one of two modes: tracking or nontracking (free-run).
Tracking mode
In tracking mode, the DTI/PRI card supplies a clock reference to a clock controller
daughterboard. Also, one DTI/PRI with clock controller is defined as the primary reference
source for clock synchronization. The other (within the same Media Gateway) is defined as the
secondary reference source (PREF and SREF in LD 73).
There are two stages to clock controller tracking:
1. tracking a reference
2. locked onto a reference
When tracking a reference, the clock controller uses an algorithm to match its frequency to the
frequency of the incoming clock. When the frequencies are nearly matched, the clock controller
locks on to the reference. The clock controller makes small adjustments to its own frequency

Monitoring references
until incoming frequencies and system frequencies correspond. If the incoming clock reference
is stable, the internal clock controller tracks it, locks on to it, and matches frequencies exactly.
Occasionally, environmental circumstances cause the external or internal clocks to drift. When
this occurs, the internal clock controller briefly enters the tracking stage. The green LED flashes
momentarily until the clock controller once again locks on to the reference.
If the incoming reference is unstable, the internal clock controller is continually in the tracking
stage, with green LED flashing continually. This condition does not present a problem, rather,
it shows that the clock controller is continually attempting to lock on to the signal. If slips occur,
a problem exists with the clock controller or the incoming line.
Monitoring references
Primary and secondary synchronization references are continuously monitored to provide
autorecovery.
Reference switchover
Switchover can occur with reference degradation or signal loss. When reference performance
degrades to a point where the system clock is not able to follow the timing signal, the reference
is out of specification. If the primary reference is out of specification but the secondary
reference is within specification, an automatic switchover is initiated without software
intervention. If both references are out of specification, the clock controller provides
holdover.
Automatic recovery and chatter

If the command "track to primary" is given, the clock controller tracks to the primary reference
and continuously monitors the quality of both primary and secondary references. If the primary
goes out of specification, the clock controller automatically tracks to secondary if the secondary
is within specification.
If both references are out of specification, the clock controller enters the Holdover mode and
continuously monitors both references. An automatic switchover is initiated to the reference
that recovers first. If primary recovers first, the clock controller tracks to the primary. If
secondary recovers first, the clock controller tracks to secondary, and switches to primary if
and when primary recovers. To prevent chatter due to repeated automatic switching between
primary and secondary reference sources, a time-out mechanism of at least 10 seconds is
implemented.

Telephony planning
If the command "track to secondary" is given, the clock controller tracks to the secondary
reference and continuously monitors the quality of both primary and secondary references. If
secondary goes out of specification, the clock controller automatically tracks to primary,
provided that primary is within specification.
Holdover and free-run

In the temporary absence of a synchronization reference signal, or when sudden changes
occur on the incoming reference due to error bursts, the clock controller provides a stable
holdover. The free-run mode is initiated when the clock controller has no record of the quality
of the incoming reference clock If the command "free run" is given, the clock controller enters
the free-run mode and remains there until a new command is received. Free-run mode
automatically initiates after the clock controller has been enabled.
Free-run (nontracking)
In free-run mode, the clock controller does not synchronize on any source. Instead, the clock
controller provides its own internal clock to the system. Free-run mode can be used when the
CS 1000E system acts as a master clock source for other systems in the network. If the CS
1000E system is a slave, free-run mode is not desirable. Free-run mode can take effect when
primary and secondary clock sources are lost due to hardware faults. Administrators can
invoke free-run mode by using software commands.
Faceplate LEDs
Table 11: NTAK20 LED indications on page 140 provides a description of the NTAK20
LEDs.
Table 11: NTAK20 LED indications
LED state LED color Definition

On Red NTAK20 is equipped and disabled.
On Green NTAK20 is equipped, enabled, and (a) locked on to a reference
or (b) operating in free-run mode.
Flashing Green NTAK20 is equipped and attempting to lock (tracking mode) to
a reference. If the LED flashes continuously over an extended
period of time, check the clock controller stats in LD60. If the
clock controller is tracking, this can be an acceptable state.

Clocking operation
LED state LED color Definition

Check for slips and related clock controller error conditions. If
none exist, then this state is acceptable, and the flashing is
identifying jitter on the reference.
Off NTAK20 is not equipped.
Clocking operation
The CS 1000E system can support up to 50 active clock controllers, one for each Media
Gateway with a PRI. However, a Media Gateway can support only one clock controller, and a
Media Gateway Expander cannot support a clock controller.
The following are clock controller acronyms:
• CC - Clock Controller
• FRUN - Free Running mode
• PREF - Primary Reference
• SREF - Secondary Reference
Free-running clocks
Free-running clocks are allowed only if the CS 1000E system does not connect to a CO.
Figure 39: Acceptable connection to an isolated private network with primary reference on
page 141 to Figure 41: Acceptable connection with a combined CO and private network on
page 142 show acceptable connections.
Figure 39: Acceptable connection to an isolated private network with primary reference

Telephony planning
Figure 40: Acceptable connection to an isolated private system with primary and secondary
reference
Figure 41: Acceptable connection with a combined CO and private network
Connecting to a CO
Any Media Gateway that supplies a reference to a remote PBX must have a trunk tracking to
a CO. There is no clock relationship between gateways. Each media gateway operates in a
separate clock domain.

Connecting to a CO
Figure 42: Acceptable connection: Media Gateway 1 and Media Gateway 2 receive clock
reference directly from CO
Figure 43: Acceptable connection: Media Gateway 1 receives clock reference directly from CO/
Remote, Media Gateway 2 receives clock reference indirectly from CO

Telephony planning
Figure 44: Unacceptable connection: Media Gateway 1 references remote PBX; clock loop, no
master clock reference
Allocating primary and secondary references

The secondary reference (SREF) clock must reside in the Media Gateway with the primary
(PREF) reference.
Figure 45: Acceptable connection: Media Gateway 1 references remote PBX; Media Gateway 2
provides master reference to remote PBX

Installation and configuration
Installation and configuration

This section describes CS 1000E system installation principles and NTAK20 clock controller
daughterboard use. This section also describes installation principles and the use of 2Mb DTI/
PRI embedded clock controllers.
The NTAK20 clock controller is installed on the following circuit cards:
• NTRB21 – 1.5Mb DTI/PRI
• NTBK22 – BRI
• NTBK50 – 2Mb PRI
Embedded clock controllers are found on the following cards:
• NTAK10 – 2Mb DTI
• NTAK79 – 2Mb PRI
Figure 46: NTAK20 Daughterboard installation on page 145 shows the installation of the
NTAK20 on the NTRB21 TMDI card.
Figure 46: NTAK20 Daughterboard installation
Clock controllers are configured in LD 73. For 1.5 Mb and 2 Mb DTI/PRI, the following
commands are used.

Telephony planning
Table 12: LD 73 - Configure clock controllers
Prompt Response Description

REQ aaa Request (aaa = CHG, END, NEW, OUT, or PRT)
TYPE aaaa Type (aaaa = DTI2, PRI2, or JDMI)
FEAT SYTI Feature = SYTI (System Timers) Valid response when
TYPE = DTI2, PRI2 or JDMI
...
DBNC (10)-32 Debounce timer
MGCLK sl s c Superloop, shelf, card number of Clock Controller
PREF card Card of the primary reference. For MISP loop use the
SILC card number. For non MISP loops use the card
number entered for the MGCLK prompt.
SREF card Card of secondary reference. Do not use the card
number entered for MGCLK or PREF prompt.
Table 13: Clock Controller commands (LD 60)
Command Description
DIS CC l s Disable system clock controller on specified superloop and shelf.
DSCK loop Disables the clock for loop. This is not applicable for 1.5Mb DTI/PRI.
DSYL loop Disable yellow alarm processing for loop.
ENCK loop Enable the clock for loop. This is not applicable for 1.5Mb DTI/PRI.
ENL CC l s Enable system clock controller on specified superloop and shelf.
ENYL loop Enable yellow alarm processing for loop.
SSCK l s Get status of system clock on specified superloop and shelf.
TRCK aaa l s Configure clock controller on Media Gateway specified by the superloop,
loop and shelf tracking to primary, secondary or free-run. Where aaa is:
• PCK = track primary clock
• SCLK = track secondary clock
• FRUN = free-run mode
Track primary clock (PCK) or secondary clock (SCLK) as the reference
clock or go to free-run (FRUN) mode.
An installed clock controller can be accessed by the following commands:

Examples
Command Description
SSCK l s Get status of system clock on specified superloop and shelf.
Examples
Status of the CC when it is tracking to Primary.
.ssck 4 0
ENBL
CLOCK ACTIVE
CLOCK CONTROLLER - LOCKED TO SLOT 1
PREF - 1
SREF -
AUTO SWREF CLK - ENBL
Status of the CC when it is in Free Run.
.ssck 12 0
ENBL
CLOCK ACTIVE
CLOCK CONTROLLER - FREE RUN
PREF -
SREF -
Status of the CC when it is tracking to Secondary.
.ssck 40 0
ENBL
CLOCK ACTIVE
CLOCK CONTROLLER - LOCKED TO SLOT 2
PREF - 1
SREF - 2
The tracking mode on an installed clock controller can be changed by the following
commands.
Command Description
TRCK PCK l s Configure clock controller tracking to primary on specified superloop and
shelf.

Telephony planning
Command Description
PCK = track primary clock
Instructs the installed clock controller to track to a primary reference clock
source also referred to as "SLAVE" mode.
TRCK FRUN l s Configure clock controller tracking to free-run on specified superloop and
shelf.
FRUN = free-run mode
Instructs the installed clock controller to free-run. In this mode, the system
provides a reference or "MASTER" clock to all other systems connected
through DTI/PRI links. This mode can be used only if there are no other
clock controllers in SLAVE mode anywhere within the system.
The Call Server can be locked to any Media Gateway with the following command.
Command Description
TRCK PLL l s Overrides the default search order and locks to specified superloop and
shelf.
Track primary clock (PCK) or secondary clock (SCLK) as the reference
clock or go to free-run (FRUN) mode.

Chapter 10: Preparing a system installation
plan
Contents
Creating an installation plan on page 150
Fire, security, and safety requirements on page 152
Equipment room requirements on page 154
Grounding and power requirements on page 161
Cable requirements on page 162
LAN design on page 163
Preparing a floor plan on page 166
Creating a building cable plan on page 166
Creating a building cable plan on page 166
Enterprise Configurator on page 30
Preparing for installation on page 172
Introduction
Warning:
properly.

Preparing a system installation plan
NN43001-260.
Planning for system installation affects the installation cost, as well as operation and
maintenance, and can have an overall effect on system performance. Consider the following
requirements (in addition to local and national building and electrical codes) when you plan a
system installation.
Select and evaluate sites according to the requirements in this document and the following
criteria:
• Space:
- The site must provide adequate space for unpacking, installation, operation, potential
expansion, service, and storage. The site must provide space for sufficient cooling. You
can need additional space for a maintenance and technician area.
• Location:
- The location should be convenient for equipment delivery and close to related work
areas. Consider the location of related equipment, such as the distribution frame and
batteries for Uninterruptable Power Supply (UPS) units. Also consider cable
limitations.
• Grounding and power:
- Proper grounding and sufficient power facilities must be available.
• Structural integrity:
- The floor must be strong enough to support anticipated loads and, if applicable, the
ceiling must be able to support overhead cable racks.
Creating an installation plan

To assist with the development of the installation plan, create an Installation Outline and a
Milestone Chart.
Installation outline
Use Table 17: Installation plan outline on page 151 as a guide for preparing a detailed
installation plan.

Milestone chart
Table 17: Installation plan outline
Procedure Requirements
Researching site requirements • Determine fire, security, and safety requirements
• Determine equipment room requirements
• Determine grounding and power requirements
• Determine cable requirements
Planning the site • Prepare a floor plan

• Estimate floor loading
• Prepare the building cabling plan
Preparing for delivery and • Prepare for delivery

installation
• Prepare for installation
Milestone chart
Planning and monitoring site preparation activities is easier when you use a milestone chart.
A milestone chart is a general site planning schedule showing the sequence of activities
necessary to complete a job.
Table 18: Milestone chart on page 151 lists typical activities included in a milestone chart. For
a complex site, you must create a more detailed chart.
Table 18: Milestone chart
Task Action
1 Select the site.
2 Plan fire prevention and safety features.
3 Plan the equipment room layout.
4 Plan grounding and power.
5 Plan cable routes and terminations.
6 Plan and start any renovations to the equipment room.
7 Continue site construction and renovation tasks.
8 Install grounding, power, air conditioning, and heating.
9 Install special rigging, such as overhead cable racks and distribution
frame equipment, as required.

Task Action
10 Test site wiring to ensure that minimum requirements are met.
11 Complete construction and ensure that grounding and power are in
place.
12 Test air conditioning and heating systems.
13 Make equipment delivery arrangements.
14 Complete equipment room inspection, identifying and resolving any
delivery constraints.
When you prepare a milestone chart, consider not only individual operations, but the overall
installation schedule. The milestone chart should show the necessary operations in order and
can assign a start and end date for each activity.
Fire, security, and safety requirements

Building, fire, and safety codes establish the degree of protection required for an installation.
Additional information is available from the National Fire Protection Association (NFPA) in
"Standard for the Protection of Electronic Computer/Data Processing Equipment" (NFPA 75)
and "National Electrical Code (NEC)" (NFPA 70).
Fire protection and prevention

Expertise is required to properly locate and install:
• Sprinkler heads
• Fire and smoke sensing devices
• Other fire extinguishing equipment
During the planning stage, consult local codes, experts, insurance underwriters, and local
building authorities.
You can implement some fire precautions when an equipment area is constructed. For
example, extend walls from floor to ceiling, and construct walls, floor, and dropped ceiling of
noncombustible material.
If the structural floor is made from combustible materials, cover it with a noncombustible
covering and remove all debris between the raised and permanent floors before the system is
installed. If there are power connections beneath a raised floor, use waterproof electrical
receptacles and connectors.
You can install shatterproof windows and sprinklers outside and above the windows to keep
fire from spreading from an adjacent room or building. The roof or floor above the equipment
area must be watertight. Design ducts and plumbing for air-conditioning systems to keep fire,

Fire extinguishing systems
heat, and smoke from spreading from one part of a building to another. Install smoke detectors
in all appropriate places.
Regularly check services such as steam, water, and power, and inspect pipes for excess
condensation, leaks, or corrosion.
Fire extinguishing systems

In most cases, carbon dioxide or water sprinkler systems are the recommended fire
extinguishing systems.
Dry-pipe water sprinklers are strongly recommended. This type of system interrupts power to
the room and opens a master valve that fills the overhead sprinklers.
Carbon dioxide systems are also effective in containing a fire, but they quickly exhaust the
oxygen supply. If you use a carbon dioxide system, you must install an alarm to warn site
personnel when carbon dioxide is released. For health and safety reasons, employees must
be evacuated within 30 seconds of the release.
Danger:
Avaya does not recommend using Halon or any other fire extinguishing system that is not
described above.
Security precautions
You may need to extend and improve existing building security to provide adequate protection
for the equipment. For example, you can install safeguards such as tamper proof keylock door
controls and electrically taped glass doors and windows that can tie into an alarm system. You
can also install a monitoring unit using closed-circuit television.
Important:
Electric locks, such as push button access code or card reader locks, are not recommended
unless you provide a battery backup or a key override.
Protect critical data, such as business records, by storing backups well away from the
equipment room. A regular updating program is highly recommended.

Safety procedures and training

Company personnel should be taught how to respond to emergencies; some companies
designate trained individuals as security members. Training can include when and how to
evacuate personnel and records, notify the fire department, shut off all electrical power, and
handle fire extinguishers properly.
In addition, install temperature and humidity monitoring devices (both visual and audible alarm
signals) in equipment and storage rooms so people can respond quickly to an emergency.
Occupational noise exposure

If employees are subjected to noise levels exceeding local standards, or the levels listed in
1910.5 of the Occupational Safety and Health Administration (OSHA) Standards, initiate
administrative and engineering controls. If these controls do not reduce sound levels
effectively, provide protective equipment.
Important:
The acoustic noise generated by a system ranges from 45 dBA to 60 dBA (decibels "A"-
weighted).
Equipment room requirements

The environment for the system (and for storing spare parts) can influence system performance
and reliability. Temperature, humidity, and other environmental factors, such as static
electricity, must be controlled to meet system operating requirements.

Environmental requirements
Environmental requirements
The environment that the Avaya CS 1000E system operates in must meet the following general
conditions:
• The room must be clean, relatively dust-free, and well ventilated. On equipment,
ventilating openings must be free of obstructions.
• The room must meet the requirements for temperature and humidity. For more information
about temperature and humidity requirements, see Temperature and humidity control on
page 157 and Air conditioning guidelines on page 158.
• The room cooling system must meet the requirements for the installed equipment. For
estimating cooling requirements based on thermal generation from system components,
see Power consumption on page 187.
• Select a location for equipment installation that is not subject to constant vibration.
• Locate equipment at least 12 ft (3660 mm) away from sources of electrostatic,
electromagnetic, or radio frequency interference. These sources can include:
- power tools
- appliances (such as vacuum cleaners)
- office business machines (such as copying machines)
- elevators
- air conditioners and large fans
- radio and TV transmitters
- high-frequency security devices
- all electric motors
- electrical transformers
Space requirements
Space and equipment layout requirements differ with each installation. When you plan the site,
consider the following requirements:
• Primary storage
• Secondary storage
• Maintenance and technician space

Primary storage
The floor area required for a system depends on the number of racks, the length-to-width ratio
of the area, and the location of walls, partitions, windows, and doors. To determine the exact
layout required, prepare a detailed floor plan after regarding all of the requirements in this
chapter.
Wall jacks and outlets must be provided for all devices located in the equipment room.
Secondary storage
Provide space in the equipment area for storing disks, printer paper, printouts, and daily
reports. A secure storage room for spare parts is recommended.
Whenever possible, maintain the same environmental conditions in the equipment room and
storage areas. If it is not possible to maintain the environment of the storage area exactly the
same as the environment of the operating equipment, give stored materials time to adjust to
the equipment room environment before using them.
Maintenance and technician space

You can use the maintenance and technician area as an online work center and a place to
store tools, test equipment, system documents, and spare parts. The area should have good
lighting and convenient access to the system.
Typical items in a maintenance and technician area include:
• Shelves for instruction books
• Spare parts storage room
• Paper storage area
• Locking cabinet or storage area for backup disks
• Table or desk
• Terminal, printer, or equivalent device
During regular system operation, a terminal, or a modem, or both must be connected
permanently to the system to provide a constant I/O interface. You can use more than one
terminal or modem. Plan for surface apace, power outlets, and the availability of the terminals/
modems before installation.

Temperature and humidity control
Temperature and humidity control

Frequent and extended system operation above recommended temperature limits can
degrade system reliability. Low humidity can increase static electricity build-up, while high
humidity can affect the performance of disks and printers.
Take temperature readings 76 cm (30 in.) from the front of the system. Table 19: Operating
environment on page 157 shows system operating requirements.
Danger:
Damage to Equipment
Do not expose equipment to absolute temperature limits for more than 72 hours. Do not
place heat sources (such as floor heaters) near the equipment.
Table 19: Operating environment
Equipment Temperature and humidity considerations

CS 1000E Recommended:
• 15° to 30°C (59° to 86°F)
• RH 20% to 55%, noncondensing
Absolute:
• 10° to 45° C (50° to 113°F)
• temperature change less than 10°C (18°F) per hour
COTS Servers (IBM, Dell, HP) Recommended:

• 10°C to 35°C (50° to 95°F)
Telephones Absolute:
• 5°C to 40°C (41° to 104°F)
Other terminal devices (such as Refer to the specific documentation or manufacturer's

personal computers, data sets, and guidelines
printers)
If you operate the system within recommended temperature limits, there are no thermal
restrictions on any equipment.
Follow the specifications listed in Table 20: Storage environment on page 158 to store or
transport equipment.

Table 20: Storage environment
Equipment Temperature/humidity considerations

CS 1000E system • –40° to 70°C (–40° to 158°F)
COTS servers (IBM, Dell, • –40° to 60°C (–40° to 140°F)

HP)
Telephones • –40° to 70°C (–40° to 158°F)

Media Gateways • –40° to 70°C (–40° to 158°F)

Other terminal devices Refer to the specific Avaya publication or the manufacturer's
guidelines
Important:
Temperature changes must be less than 30° C (54° F) per hour for storage and during
transportation.
Air conditioning guidelines

Use the following guidelines to estimate air conditioning requirements. Exact requirements
must be determined by a qualified air conditioning engineer.
• The air conditioning system in equipment areas must handle:
- the heat produced by the equipment, room personnel, and lighting; and,
- the heat that comes through walls, windows, floors, and ceilings.
• A stable ambient operating temperature of approximately 22° C (72° F) is recommended.
The temperature differential in the equipment room must not exceed ±3.0° C (±5° F).
For systems with reserve power equipment, consult the manufacturer's specifications for
recommended operating temperatures.
• Heat dissipation from a system is estimated in Btu per hour (Btu/hr). You can estimate
the amount of air conditioning required at a rate of one ton of refrigeration for every 12
000 Btu/hr of heat generated in the equipment area plus one ton for each 500 sq ft of floor
space.
Each person in the equipment room generates 600 Btu/hr.

Other environmental factors
Caution:
Damage to Equipment
Because digital systems require constant power (even if the system is idle), they
generate heat continuously. Air conditioning requirements must be met at all times.
• Table 23: Current, power, and cooling requirements for CS 1000E components on
page 187 and Table 24: Power and cooling requirements for Media Gateway packs on
page 189 show the thermal dissipation for system components.
Other environmental factors

In addition to temperature and humidity, many environmental factors must be controlled in
equipment areas. The environmental factors that must be controlled include:
• Static electricity
• Vibration
• Electromagnetic and radio frequency interference (EMI/RFI)
• Dust
• Lighting
• Earthquake bracing
• Structural features
Static electricity
Electronic circuits are extremely sensitive to static discharge. Static discharge can damage
circuitry permanently, interrupt system operation, and cause lost data.
Static electricity can be caused by physical vibration, friction, and the separation of materials.
Other common causes of static electricity build-up are low humidity, certain types of carpeting,
the wax on equipment room floors, and plastic-soled shoes. The human body is the most
common collector of static electricity. A combination of plastic-soled shoes, certain flooring
materials, and low humidity can cause body charges in excess of 15 kV.
Important:
IEEE Standard 142-1982 recommends that flooring resistance be more than 25 000 ohms
and less than 1 million megohms, measured by two electrodes 0.91 m (3 ft) apart on the
floor. Each electrode must weigh 2.2 kg (5 lb) and have a dry flat contact area of 6.35 cm
(2.5 in.) in diameter.
Antistatic wrist straps, sprays, and mats are available. Avaya recommends at least using an
antistatic wrist strap whenever you work on equipment.

Vibration
Vibration can cause the slow deterioration of mechanical parts and, if severe, can cause
serious disk errors. Avoid structure-borne vibration and consequent noise transferred to the
equipment room. Raised floors must have extra support jacks at strategic places to prevent
the transmission of vibration.
Limit vibration in an office environment to a frequency range of 0.5–200 Hz and a G-force
magnitude of 0.1 G (in accordance with the Bellcore "Network Equipment Building Systems
Generic Equipment Requirements" specification TR-EOP-000063).
Electromagnetic and radio frequency interference

Sources of electromagnetic and EMI/RFI located close to equipment can cause problems with
system operation. Common EMI/RFI sources known to disturb system operation include:
• Thunderstorms, static electricity, and high-voltage power lines
• Radar, broadcast stations, and mobile communications
• Power tools, appliances (such as vacuum cleaners), and office business machines (such
as copiers)
• Industrial machines and ultrasonic cleaners
• Vehicle ignition, arc welders, and dielectric heaters
• Dimmer switches
Dust
Accumulated dust and dirt can degrade system reliability and performance. Dust and dirt can:
• Scratch the contacts on circuit cards causing intermittent failures
• Have conductive contents that increase static electricity in the environment
• Cause components to operate at higher temperatures
Average dust density for an office environment must be 0.00014 g/m3 or better. False ceilings
and tiled floors help maintain dust density requirements.

Lighting
Lighting
Lighting illumination of 50 to 75 footcandles measured 76 cm (30 in.) above the equipment
room floor is recommended. Avoid direct sunlight in the equipment room to prevent
malfunctions by devices with light sensors (such as disk units).
Lighting must not be powered from the equipment room service panel. For large system
installations, consider provisions for emergency lighting in the equipment room.
Earthquake bracing
Earthquake (seismic) bracing is required or should be considered in some locations.
Structural features
Use sealed concrete, vinyl, or mastic tile for flooring and ensure that it meets the floor loading
requirements described later in this document. Avoid using sprayed ceilings or walls.
Grounding and power requirements

For more information, see Power and grounding on page 175 .
Reserve power equipment room

If the reserve power equipment is located in a separate room then that room must meet the
following conditions.
1. Well-ventilated and operating at optimum temperature; specific gravity readings are
based on 25 degrees C (77 degrees F)
2. Located within the recommended proximity to the system
3. Equipped with protective equipment (such as goggles, face shields, acid-resistant
gloves, protective aprons, water for rinsing eyes/skin, and bicarbonate of soda)

4. Well-secured
5. Accessible (the doorway must not be blocked)
6. Meet all floor loading requirements and the noise levels required by OSHA
standards 1910.5 (or local standards)
For detailed instructions on battery usage, see ANSI/IEEE Standard 450-1987: "Maintenance,
Testing and Replacement of Large Storage Batteries."
Cable requirements
This section describes the types of cable used in the system. It also provides some cabling
guidelines.
Cable types
The system uses the following major types of wiring:
• 25-pair main distribution frame (MDF) cables: These cables carry voice and data
information between gateways and the distribution frame. One end of the cable must be
equipped with a 25-pair female connector that terminates on the module input/output (I/
O) panel. The other end of the cable terminates on the MDF block.
• Interface cables: Interface, or I/O, cables are typically 25-conductor interfaced through
RS-232-C connectors. These cables are used to connect data units to printers, host
computers, and modems.
• Three port cables: This cable is used as an interconnect between terminal equipment and
the terminal port on the Media Gateway 1000E. The cable also functions as a remote TTY
if it has been configured with an MGC. On the Avaya MG 1000E, it is required only for
initial configuration of IP addresses.
• Cat 5 cables: These are standard cables used to connect LAN equipment and are
terminated with RJ45 connectors. These are specified as either being standard or straight
through or as cross over. Not recommended for speeds greater than 100 Mbps.
• Cat 5E (Cat 5 Enhanced) cables: The Cat 5E are the same as Cat 5 cables, but made to
more stringent requirements. They are also designed for speeds up to 1 Gbps.
• Cat 6 cables: The same as Cat 5E, but made to more stringent standards. Designed for
speeds up to 1 Gbps.
• Terminal server cables: Terminal server cables are a proprietary cable that can be used
to interface between the MRV Terminal Server and various system components in order
to allow terminal access.

Cable access
• Twisted-pair telephone cables: These cables carry analog voice and digitized voice and
data information between distribution frames and terminal devices throughout the
building. They connect to 8-pin modular jacks located within 2.4 m (8 ft) of each device.
• Surge-suppression cables: These cables prevent transient voltages from damaging
certain Central Office Trunk (COT) and Direct-Dial Inward (DDI) cards. The cable has a
male connector on one end and a female connector on the other so that you can connect
it serially with the existing cable. For a list of cards that require surge-supression cables
and installation instructions, see Circuit Card Reference, NN43001–311.
Consider cable length requirements and limitations for both initial installation and later growth
when you plan a system.
Cable access
The customer is responsible for supplying all access for station, feeder, and riser cabling. This
includes (where necessary):
• Conduit
• Floor boring
• Wall boring
• Access into hung ceilings
LAN design
Network requirements are critical to the CS 1000E quality of service. Ensure the network meets
the following requirements:
• Provision 100BaseTx IP connectivity between the Call Server and the Media Gateway.
The 100BaseTx IP connectivity can be either a point-to-point network or a distributed
campus data network. IP daugherboards in the Call Server and the Media Gateway
provide connectivity.
• Ensure that the 100BaseTx Layer 2 (or Layer 3) switch supports full-duplex connection.
Routers are not supported in Call Server to Media Gateway connections. The ports on
Layer 2 (or Layer3) switching equipment must be configured to autonegotiate
ENABLED.
• Provision the ELAN subnet and the TLAN subnet on separate subnets.

• Provision all applications on the ELAN subnet on the same subnet. This includes Voice
Gateway Media Cards that must be on the same ELAN subnet.
• Ensure that Voice Gateway Media Cards are in the same node on the same TLAN
subnet.
For information about the requirements for creating a robust, redundant network, see Avaya
Converging the Data Network with VoIP Fundamentals, NN43001-260.
Keep a record of the IP addresses assigned to system components. See Figure 47: Sample
IP address record sheet on page 165 for a sample.

LAN design
Figure 47: Sample IP address record sheet

Preparing a floor plan

Prepare a detailed floor plan for each site. The floor plan must indicate the size and location
of:
• the racks, including planned expansion areas
• the service panel
• system terminal, printer, or other terminal devices (such as modems)
• PTFUs (if equipped)
• space for additional equipment, such as reserve power equipment or auxiliary processors
Important:
According to the National Fire Code, equipment must be at least 30.5 cm (12 in.) from a
sprinkler head.
Ensure that the site configuration meets all requirements of the third-party suppliers of the 19-
inch racks.
Creating a building cable plan

To create a building cable plan, complete the following tasks.
1. Show the routing of all wiring, the location and wiring requirements of each terminal
device connected to the system, and any other relevant information about the
device.
2. Show the location of distribution frames, conduits and access points, and power
outlets.
3. Identify the ownership of existing building wire if it is to be used.
4. Perform a random sampling of in-place wiring to ensure that it meets specifications
for high-speed lines. All wiring carrying high-speed data must pass a verification
test as part of the installation procedures.
5. Identify the location of conduits and floor ducts. If telephone cable is run in conduit
then that conduit cannot be used for any other wiring.
6. Provide three pairs of telephone wire from a distribution frame to a nearby telephone
jack for each terminal device. Modular jacks must be within 2.0 m (8 ft) of the
device.
7. Provide Power over LAN cables to all desktops.
8. Divide the building cable plan into zones. Zones are typically the termination point
of conduits throughout the office. Identify each zone on the building cable plan with

Wire routing
a letter or number, and assign a block of numbers to each zone. Figure 48: Building
cable zones on page 169 illustrates zoning.
Be sure to leave room for expansion.
Wire routing
Refer to the appropriate electrical code for your region for standards you are required to meet.
For the US, refer to the National Electrical Code (NEC).
To plan wire routing, establish the start and end point of each cable relative to the location of
the terminal devices in the building, and then examine the construction of the office to
determine the best wiring routes. Consider the following guidelines when performing this
task.
• Floors:
- In the open, wires can run along baseboard, ceiling moldings, or door and window
casings. For the safety of employees, never run wire across the top of the floor.
- When concealed, wires can run inside floor conduits that travel between distribution
frames and jacks. (Under-carpet cable is not recommended.)
• Ceilings:
National and local building codes specify the types of telephone wire that you can run in
each type of ceiling. Local building codes take precedence.
• Walls:
Cables that run vertically should, when possible, run inside a wall, pole, or similar facility
for vertical wire drops. Cables that run horizontally cannot be blind-fed through walls.
• Between floors:
Locate distribution frames as closely to one another as possible. Local coding laws specify
whether or not a licensed contractor is required if conduit is installed.
• EMI:
Data degradation can occur if wires travel near strong EMI sources. See Electromagnetic
and radio frequency interference on page 160 for a description of common interference
sources.

Termination points
After you determine the wire routing, establish termination points. Cables can terminate at:
• the MDF (typically in the equipment room)
• intermediate distribution frames, typically on each floor in telephone utility closets
• wall jacks to terminal boxes, typically located near the terminal device
At the distribution frame (also called the cross-connect terminal), house cables terminate on
the vertical side of the two-sided frame and cross connect to equipment that is typically located
on the horizontal. If you use a color field scheme, house cables typically terminate in the blue
field and the equipment terminates on the purple (US) or white (Canada) field.
In all cases, clearly designate the block where the cables terminate with the cable location
information and the cable pair assignments. Keep a log book (cable record) of termination
information. See Figure 49: Sample cable record on page 170 for an example.

Termination points
Figure 48: Building cable zones

Figure 49: Sample cable record

Preparing for delivery
Preparing for delivery

When preparing for equipment delivery, answer the following questions:
• Has a request been made for equipment delivery?
• Are transportation arrangements to the premises completed?
• Is a list of all ordered equipment available on site?
• Is help needed and available for preparing the equipment room?
• Are unloading and unpacking facilities and tools available?
• Is help needed and available for delivery?
Plan to unload equipment as close to the final installation area as possible for an easier, and
perhaps safer, installation.
Conducting pre-installation inspections

Obtain any appropriate sign-off before the site is ready for equipment delivery and installation.
Sign-off can include regulatory items such as electrical inspections, air conditioning
inspections, and cable plan approval. In addition, an overall equipment room inspection and a
building cable inspection should be performed before installation.
• Inspect the room to verify that:
- All physical and environmental requirements are met.
- System grounding and power equipment is installed and tested.
- The equipment layout is marked on the floor.
• Inspect building cable to verify that:
- Sufficient distribution frames are provided.
- Conduits or floor ducts to terminal locations are installed.
- Terminal jacks are installed.
- Sufficient wiring is available.
Inspect the equipment room to verify that all physical and environmental requirements are met,
system grounding and power equipment is installed and tested, and the equipment layout is
marked on the floor.
Inspect the building cable to verify that sufficient distribution frames are provided, conduits or
floor ducts to terminal locations are installed, terminal jacks are installed, and sufficient wiring
is on hand.

Preparing for installation

The installation plan, work orders, and appropriate documentation should be on hand at the
time of installation.
Reviewing the installation plan

The installation plan can consist of the equipment room floor plan, the building cable plan, and
an installation and test sequence chart.
The equipment room floor plan should show:
• Racks, including planned expansion areas
• Main distribution frame
• Service panel
• System terminal, printer, or other terminal devices
• External power equipment (such as UPS)
• Cable racks
• PFTUs (if equipped)
The building cable plan should show:
• Cable routing and designation information
• Location of each terminal device
• Type of cable or wiring required for each terminal device
• Location of all distribution frames and system and terminal cross-connect assignments
• Location of conduits and floor ducts, including access points
• Location of power outlets for terminal devices
An installation and test sequence (ITS) chart shows typical installation tasks, the sequence of
the tasks, and task start and duration information.

Reviewing the work orders
Reviewing the work orders

The work order can include:
• Detailed listing of the equipment ordered
• Terminal Number (TN) assignments
• Directory Number (DN) assignments for each terminal device
• IP assignments for all equipment
• Office Data Administration System (ODAS) designators for each terminal device (if the
software package is equipped)
• Features available to each telephone and data set
• Administration database entries for telephone and data set features
Reviewing the documentation

Instructions for unloading and unpacking system equipment, as well as a full set of standard
publications, are delivered with each system.


Chapter 11: Power and grounding
Contents
Grounding requirements on page 175
Grounding methods on page 180
Commercial power requirements on page 183
Alternative AC-powered installation on page 185
AC input requirements on page 186
Power consumption on page 187
Heat dissipation on page 195
Uninterruptible Power Supply on page 195
Power requirements for IP Phones on page 197
Introduction
Avaya Communication Server 1000E (Avaya CS 1000E) system components are AC-
powered. This section outlines the system's grounding and electrical requirements.
Grounding requirements
For system grounding in new installations, Avaya recommends following ANSI/TIA/EIA-607
(Commercial Building and Bonding Requirements for Telecommunications Equipment).
In building installations where the ANSI/TIA/EIA-607 method is not used, connect the
equipment ground to the AC ground at the respective service panel.

Power and grounding
If you are having difficulty interpreting the grounding methods in this document, Avaya
recommends obtaining the services of a certified power contractor or auditor prior to system
installation or cutover
Warning:
Failure to follow grounding recommendations can result in a system installation that is:
• unsafe for personnel handling or using the equipment
• not properly protected from lightning or power transients
• subject to service interruptions
Before installing the equipment and applying AC power, measure the impedance of the building
ground reference. An ECOS 1023 POW-R-MATE or similar meter is acceptable for this
purpose. Ensure that the ground path connected to the system has an impedance of 4 ohms
or less. Make any improvements to the grounding system before attempting installation.
Voltage:
Never connect the single point ground conductor from the system to structural steel
members or electrical conduit. Never tie this conductor to a ground source or grounded
electrode that is not hard-wired to the building reference conductor.
System grounding must adhere to the following requirements:
• The ground path must have an impedance of 4 ohms or less.
• Ground conductors must be at least #6 AWG (16 mm 2) at any point (see Table 21: Area-
specific ground wire requirements on page 176 for a list of grounding wire requirements
specific to some areas).
• Ground conductors must not carry current under normal operating conditions.
• Spliced conductors must not be used. Continuous conductors have lower impedance and
are more reliable.
• All conductors must terminate in a permanent way. Make sure all terminations are easily
visible and available for maintenance purposes.
• Tag ground connections with a clear message such as "CRITICAL CONNECTION: DO
NOT REMOVE OR DISCONNECT."
Table 21: Area-specific ground wire requirements
Area Ground wire requirements

Germany #8 AWG (10 mm 2) green/yellow wire
Other areas in Europe Not smaller than #6 AWG (16 mm 2) at any point
UK Two green/yellow wires no thinner than 10 mm2
For more information about standards and guidelines for grounding telecommunications
equipment, refer to ANSI/TIA/EIA-607 (Commercial Building and Bonding Requirements for
Telecommunications Equipment).

Single Point Ground
Voltage:
For an installed Call Server, Media Gateway, Media Gateway Expander, or Signaling Server,
link impedance between the ground post of any equipment and the single point ground that
it connects to must be less than 0.25 ohms.
Caution:
Damage to Equipment
Transients in supply conductors and ground systems can damage integrated circuits. This
damage can result in unreliable system operation. Damage caused by transients is not
always immediately apparent. Degradation can occur over a period of time.
Single Point Ground

Correct grounding of communications systems is necessary to protect equipment from the
hazards of surge and noise interference. The Single Point Ground (SPG) method of protecting
communications equipment is the Avaya standard. Table 22: Grounding design
considerations on page 177 describes grounding design considerations.
Table 22: Grounding design considerations
Safety • Dissipate unwanted surge energies such as

lightning striking on the outside plant
• Fuses or breakers open to disrupt the excessive
current flow caused by a power fault
Equipment protection • Grounding for outside plant cable shields and

protectors
• Grounds for framework and logic references
Electromagnetic compatibility • Conform with electromagnetic compatibility (EMC)

(EMC) grounding requirements
Installation and maintenance • Cost-effective to install and maintain when part of

the initial electrical installation
• Correcting violations of national codes after the
initial installation is difficult and costly
Powering • If the equipment is backed up with an

Uninterruptable Power Supply (UPS), consider the
grounding of all equipment that is part of the
telecommunications system as a single system

Power and grounding
Advances in technology • Provides important protection to ensure the effective

operation of circuit cards and avoid costly downtime
and replacement
Voltage:
Do not perform work inside electrical panels unless you are a qualified electrician. Do not
try to remove bonding conductors without approval from qualified personnel.
In an ANSI/TIA/EIA-607 installation, the Telecommunications Main Grounding Busbar (TMGB)/
Telecommunications Grounding Busbar (TGB) links the telecommunications equipment to the
ground. Other grounding terminology is:
• building principal ground, normally in a building with one floor
• floor ground bar, normally in buildings with more than one floor
Configure telecommunications subsystems, such as groups of frames or equipment, as
separate single-point ground entities connected to the equipment's dedicated service panel
via a single-point ground bar. The service panel ground connects to the building principal
ground via the main service panel or, in an ANSI/TIA/EIA-607 installation, via the TGB. Refer
to Figure 51: Typical wiring plan on page 180.

Single Point Ground
Figure 50: ANSI/TIA/EIA-607 grounding schematic

Power and grounding
Figure 51: Typical wiring plan
Grounding methods
This section describes the grounding methods for:
• Ground bar (NTBK80) on page 181
• Ground bar (NTDU6201) on page 181
• CP PIV Call Server (NTDU62) on page 181
• COTS servers on page 182
• Media Gateway on page 182

Ground bar (NTBK80)
• Media Gateway Expander on page 182

• Multiple components in a rack on page 183
Voltage:
To prevent ground loops, power all CS 1000E system equipment from the same dedicated
power panel.
Ground bar (NTBK80)

The NTBK80 ground bar is capable of grounding up to six Media Gateways (either with or
without companion Media Gateway Expanders) back to the SPG. See Table 21: Area-specific
ground wire requirements on page 176 for area-specific ground wire requirements.
Ground bar (NTDU6201)

If there are more than six Media Gateways (either with or without companion Media Gateway
Expanders), use the NTDU6201 ground bar. The NTDU6201 can be adjusted for various
mounting configurations. It accepts 35 #6 AWG (16 mm 2) wire connections. The ground bar
must terminate at the service panel ground. See Figure 51: Typical wiring plan on page 180.
CP PIV Call Server (NTDU62)

The CP PIV Call Server does not connect to a ground bar. It is properly grounded when:
• The CP PIV Call Server power cord is plugged into the rack's AC outlet. The rack's AC
outlet must be grounded to its dedicated electrical panel.
• The CP PIV Call Server power cord is plugged into a wall AC outlet. The CP PIV Call
Server is grounded outside of the rack via the safety grounding conductor in the power
cord. This method only ensures proper grounding of the CP PIV Call Server. It does not
provide grounding protection for other rack-mounted pieces of equipment in a CS 1000E
system. Therefore, ensure that other devices in the rack are properly grounded as
required.
The CP PM Call Server is grounded from the Media Gateway

Power and grounding
COTS servers
The Commercial off-the-shelf (COTS) server does not connect to a ground bar. It is properly
grounded when:
• The COTS server power cord is plugged into the rack's AC outlet. The rack's AC outlet
must be grounded to its dedicated electrical panel.
• The COTS server power cord is plugged into a wall AC outlet. The Server is grounded
outside of the rack via the safety grounding conductor in the power cord. This method
only ensures proper grounding of the Signaling Server itself. It does not provide grounding
protection for other rack-mounted pieces of equipment. Therefore, ensure that other
devices in the rack are properly grounded as required.
Media Gateway
The grounding method used for the Media Gateway depends on the number of units used and
whether the units are powered by the same service panel.
All equipment located in a series of equipment racks that are physically bonded together must
be grounded to and powered by the same service panel. If additional service panels are
required, collocate them beside the original service panel.
If racks are not bonded together, then the equipment located in the racks can be grounded and
powered by separate service panels.
Connect a #6 AWG (16 mm 2) ground wire from the rear panel grounding lug of each Media
Gateway to the ground bar. See Table 21: Area-specific ground wire requirements on page 176
for area-specific ground wire requirements. Connect the ground bar to a ground source in the
dedicated service panel.
In the UK, connect the ground wire from the equipment to a ground bar or through a Krone
Test Jack Frame.

The Media Gateway and Media Gateway Expander are considered as the same ground. To
ground the Media Gateway Expander, jumper the ground wire from it to the grounded Media
Gateway.

Multiple components in a rack
Important:
Power each Media Gateway and Media Gateway Expander pair from the same service
panel.
Multiple components in a rack

To ground multiple pieces of equipment installed in a rack, run a separate connection from the
grounding lug on each piece of equipment to the ground bar.
If a piece of equipment in a rack does not have a grounding lug, ground the rack to the ground
bar. Grounding the rack in this manner grounds the equipment by the SPG method.
Conduit requirements
Conductive conduit linking panels and equipment is legal for use as a grounding network in
most countries. For all CS 1000E system ground paths, route the correct size of insulated
copper conductors inside conduit. A ground link that depends on a conduit can defeat the
improvements achieved with the installation of dedicated electrical panels and transformers.
A grounding failure can result from the following:
• Personnel who service different equipment can separate conduit links. If such a
separation occurs between the system and the building ground reference, the conduit
cannot provide a ground path. This situation is hazardous.
• Corrosion of metal conduits increases resistance. Threaded connections are prone to
corrosion. This problem becomes worse when there are multiple links. Applying paint over
the conduit increases the corrosion process.
• Conduit cannot be fastened to secure surfaces. Often, the conduit bolts on to structural
steel members, which can function as ground conductors to noisy equipment (for
example, compressors and motors). Adding noisy equipment into the grounding system
can damage the system's performance. The resulting intermittent malfunctions can be
difficult to trace.
Commercial power requirements

The CS 1000E system is AC-powered. Optimally, a dedicated electrical panel that is connected
to the facility's electrical system powers the system. The dedicated electrical panel provides
power only to the CS 1000E system components and its related telecommunications hardware

Power and grounding
such as TTYs and printers. There is no expectation that system components that are located
off-site will be powered by this dedicated electrical panel.
Media Gateway 1000E and Media Gateway Expander

Each Media Gateway 1000E Expander pair must share the same electrical breaker and outlet.
For more information, see AC input requirements on page 186.
If the system is equipped with Avaya CallPilot, the CallPilot server must connect to the same
dedicated service panel that feeds the Media Gateway that the MGate card resides.
Rack power bars

Power each power bar or rack-mounted power rail on a separate circuit fed from the service
panel.
The rating for power bars must be 120 or 240 V, 15 or 20 A, 50-60 Hz, grounded. Power bars
are nonisolated ground type.
Powering redundant equipment

Provide power to redundant equipment from dedicated power bars fed from their own
dedicated circuits.
For redundant power in the Media Gateway 1010, each of the two MG 1010 power supplies
must be on separate circuits.
Powering auxiliary equipment

Terminals, printers, modems, and other data units used with the CS 1000E or Media Gateway
have special wiring requirements. All equipment must be:
• powered from the same electrical panel or transformer as the system
• grounded to the same electrical panel or transformer as the system
• labeled at the electrical panel to prevent a nonauthorized power interruption

Alternative AC-powered installation
Alternative AC-powered installation

Use an approved isolation transformer when the power to all system components at a location
cannot be supplied by a dedicated electrical panel or the dedicated electrical panel cannot
provide optimal conditions. To determine the system power consumption, see Table 23:
Current, power, and cooling requirements for CS 1000E components on page 187 and Table
24: Power and cooling requirements for Media Gateway packs on page 189.
The isolation transformer must have the following characteristics:
• 120/240 V AC input, over-current protected at primary.
• 120/240 V AC available at secondary outputs, each protected by circuit breaker.
• Primary and secondary windings completely isolated from one another.
• Approved for use locally as a stand-alone user product (CSA, UL, or other locally
recognized clear markings).
• Capable of providing power to all components operating at the same time at full load.
• Equipment unrelated to the system must not be powered from a transformer that provides
service to the system.
Installing an isolation transformer ground

The transformer ground must have separate grounds for primary and secondary windings
rather than a common ground. Ground conductors inside the transformer must be correctly
sized.
Voltage:
Avaya does not recommend connecting any CS 1000E system telecommunications ground
bus to untested horizontal structural steel or water pipes, or other unreliable ground paths.
Use a ground point known to be "clean" and permanent. Place a "DO NOT DISCONNECT"
tag on it.
Installing an isolation transformer without pluggable power cords on page 185 describes the
method to install an isolation transformer without pluggable power cords.
Installing an isolation transformer without pluggable power cords
1. If the transformer does not have a pluggable cord, hardwire the transformer to an
electrical panel. Route all wires (including grounds) through a single conduit.

Power and grounding
Some electrical codes permit the use of conduit as the only ground conductor
between pieces of equipment.
2. Run a separate insulated ground conductor through the conduit to hold unit grounds
together. Such a conductor maintains the safety ground connection in the event that
the conduit becomes corroded or disconnected.
3. Run all ground lines through the same conduit as the phase conductors that serve
the equipment. Figure 52: Typical hardwired isolation transformer wiring plan on
page 186 shows the isolation transformer connections.
Figure 52: Typical hardwired isolation transformer wiring plan
AC input requirements
For the AC input current requirements of Communication Server 1000E components, see Table
23: Current, power, and cooling requirements for CS 1000E components on page 187 .
North America: Voltage range 90 to 132V AC, 60Hz.
Europe and UK: Voltage range 180 to 250V AC, 50Hz Note: Regulations in Germany allow a
maximum supply panel fuse or breaker of 16A.

Power consumption
If other data communications equipment is in the same rack as the CS 1000E system, power
each piece of equipment from the same electrical panel. Install additional outlets, if
necessary.
Because local power specifications vary, consult a qualified local electrician when planning
power requirements.
Power consumption
System power consumption depends on the number of components installed.
Table 23: Current, power, and cooling requirements for CS 1000E components on page 187
summarizes the current, power, and cooling requirements for CS 1000E components. Table
23: Current, power, and cooling requirements for CS 1000E components on page 187 shows
absolute maximum ratings as well as typical ratings for configured systems. The typical values
are provided as a guide to avoid over-engineering, particularly for Uninterruptable Power
Supply (UPS) requirements.
Table 23: Current, power, and cooling requirements for CS 1000E components
Component Current @ 120/240 V Required UPS power Thermal dissipation

AC (A) (W) (Btu)
Maximum Typical Maximum Typical Maximum Typical
NTDU62 Call 2.50/1.25 1.00/0.5 300.00 120.00 1023.90 409.56
Server 0
NTDU97 (HP 6.00/3.0 4.0/2.0 580.00 400.00 1990.00 1370.00
DL320 G4)
NTDU99 (IBM 5.50/2.8 3.00/1.5 550.00 350.00 1024.00 682.00
x306m)
NTDW40 (IBM 4.00/2.0 2.00/1.0 400.00 250.00 1365.00 853.00
x3350)
NTDW41 (Dell 4.00/2.0 2.00/1.0 400.00 250.00 1365.00 853.00
R300)
700501181 (HP 4.00/2.0 2.00/1.0 400.00 250.00 1365.00 853.00
DL360 G7)
NTDU14 Media 1.40/0.70 1.17/0.5 300.00 190.00 1023.60 648.30
Gateway 8
NTDU15 Media 1.15/0.58 1.17/0.5 300.00 145.00 1023.60 494.70
Gateway 8
Expander
MRV Terminal 1.60/0.80 0.40/0.2 192.00 48.00 655.30 163.83
Server 0

Power and grounding
Component Current @ 120/240 V Required UPS power Thermal dissipation

AC (A) (W) (Btu)
Maximum Typical Maximum Typical Maximum Typical
Ethernet Routing 0.8 - 96.00 76.00 327.00 -
Switch 2526T
Switch 2550T
Switch 2526T-
PWR
Switch 2550T-
PWR
Maximum values for the Media Gateway and Expander assume worst case conditions. It is
difficult to specify a typical configuration. The typical values in the table are intended as a
rough guide for quick estimations. Avaya recommends that qualified personnel take current
measurements for a more accurate assessment of UPS and thermal requirements.
Maximum AC input for the Ethernet Routing Switch 2550T-PWR and the Ethernet Routing
Switch 2526T-PWR includes maximum power of the Power over LAN. The typical rating has
been adjusted to reflect configuring for IP Phones (60 mA at 48 V DC).
Maximum voltage limits: North America – 90 and 132 V, single phase. Europe and UK – 180
and 250 V, single phase. Frequency: North America – 60 Hz. Europe and UK – 50 Hz. Fuse:
Germany – 16 A.
Table 24: Power and cooling requirements for Media Gateway packs on page 189 provides
the power consumption and thermal dissipation of Media Gateway packs (circuit cards and
daughterboards) commonly installed in CS 1000E and Media Gateway Media Gateways and
Expanders. Use the data in the following table in conjunction with the system and Media
Gateway power consumption worksheets. See Power consumption worksheets on
page 190.
Electrical load for analog line cards varies with traffic load. The figures in the following table
assume that 50% of analog lines are active.
For digital and analog (500/2500-type) telephones, most thermal dissipation will be external
to the switch room. This is accounted for In Table 24: Power and cooling requirements for Media
Gateway packs on page 189, and the Power consumption worksheets on page 190. This
thermal dissipation is also accounted for in the typical values shown in Table 23: Current,
power, and cooling requirements for CS 1000E components on page 187.

Power consumption
Table 24: Power and cooling requirements for Media Gateway packs
Component Active off-hook Power Thermal

(%) consumption dissipation
(W) outside system
(W)
NTAK11 Option 11C Cabinet N/A 8.5
(NTDK70 power supply)
NTAK14/15 MG 1000E Chassis N/A 24
NTC310 MG 1010 Chassis (2 N/A 100
power supplies, 3 blower fans, 1
MGU card)
NTDW53/NTDW54 Common N/A 30
Processor Dual Core
NTDW56/NTDW59 Common N/A 35
Processor Media Gateway
NTDW60/98 Media Gateway N/A 7
Controller card
NTDW61/66/99 Common N/A 30
Processor Pentium Mobile
NTDW62 MGC DSP N/A 4
daughterboard (32 port)
NT5K02 Flexible Analog Line card 50 26 19.4
NT8D02 Digital Line card 100 26 13
NT8D03 Analog Line card 50 26 19.4
NT8D09 Analog Message Waiting 50 26 19.4
Line card
NT8D14 Universal Trunk card (DID N/A 28
enabled)
NT8D15 E&M Trunk card N/A 29
NTAK09 1.5 MB DTI/PRI card N/A 10
NTAK10 2.0 MB DTI card N/A 12
NTAK79 2.0 MB PRI card N/A 12
NTBK50 2.0 MB PRI card N/A 12

Power and grounding
Component Active off-hook Power Thermal

(%) consumption dissipation
(W) outside system
(W)
NTRB21 TMDI (1.5 MB DTI/PRI) N/A 12
card
NTVQ01 Media Card (32 port) N/A 18
NTDW65 MC32S Media Card (32 N/A 9
port)
NTDW79 UDT N/A 12
Important:
To determine the required UPS rating for Media Gateways you must allow for the efficiency
factor of the Media Gateway power supply plus peak inrush. For NTAK11, NTDU14, and
NTDU15, multiply the total power consumption of the components by 1.5. For NTC310,
multiply the total power consumption of the components by 1.3. See the Media Gateway
power consumption worksheets for this calculation.
Power consumption worksheets

Use the provided worksheets to determine power consumption for the CS 1000E system.
• Table 25: CS 1000E system power consumption worksheet on page 190
• Table 26: NTAK11 Media Gateway Option 11C power consumption worksheet on
page 192
• Table 27: NTDU14 and NTDU15 Media Gateway power consumption worksheet on
page 193
• Table 28: NTC310 Media Gateway 1010 power consumption worksheet on page 194
Prepare one worksheet for the system as a whole (Table 25: CS 1000E system power
consumption worksheet on page 190).
Table 25: CS 1000E system power consumption worksheet
Component Required UPS Thermal dissipation

power
Number of Per comp. Total Per comp. Total
comp. (1) (W) (2) (W) (1) (Btu) (3) (Btu) (1)
x (2) x (3)
Call Server
Signaling Server

Component Required UPS Thermal dissipation

power
Number of Per comp. Total Per comp. Total
comp. (1) (W) (2) (W) (1) (Btu) (3) (Btu) (1)
x (2) x (3)
Terminal Server
Ethernet Routing Switch
2526T
2550T
2526T-PWR
2550T-PWR
NTDW77 HD PRI Gateway
NTAK11 Media Gateway
Option 11C*
NTDU14/15 Media Gateway
1000E*
NTC310 Media Gateway
1010*
TOTAL
*Enter the sum of the totals from all Media Gateway worksheets.
Prepare one worksheet for each Media Gateway. Use the appropriate worksheet for the Media
Gateway type from the following list.
• Table 26: NTAK11 Media Gateway Option 11C power consumption worksheet on
page 192
• Table 27: NTDU14 and NTDU15 Media Gateway power consumption worksheet on
page 193
• Table 28: NTC310 Media Gateway 1010 power consumption worksheet on page 194
For the power and thermal dissipation requirements for the individual components, see Table
24: Power and cooling requirements for Media Gateway packs on page 189 .

Power and grounding
Table 26: NTAK11 Media Gateway Option 11C power consumption worksheet
Media Gateway number ________________

Power Thermal
consumption dissipation
(W) outside system
Slot Media Gateway Pack (W)
NTAK11 Option 11C cabinet 8.5
0 Gateway Controller
0 DSP daughterboard
0 DSP daughterboard
1
2
3
4
5
6
7
8
9
10
TOTAL
multiply total power consumption by 1.5 x 1.5
Required UPS Power (W or VA)
subtract total thermal dissipation outside
system (W)
System thermal dissipation (W)
multiply by 3.412 to convert to BTU x 3.412
System thermal dissipation (BTU)

Table 27: NTDU14 and NTDU15 Media Gateway power consumption worksheet

Power Thermal
(W) outside system
NTDU14 MG 1000E chassis 24
0 DSP daughterboard
0 DSP daughterboard
1
2
3
4
NTDU15 Media Gateway Expander chassis 24

7
8
9
10
TOTAL
system (W)
Syste
m
therma
l
dissipa
tion
(W)

Power and grounding
Table 28: NTC310 Media Gateway 1010 power consumption worksheet

Power Thermal
(W) outside system
23 Server card
22 Server card
MG 1010 chassis 100
0 DSP daughterboard
0 DSP daughterboard
1
2
3
4
5
6
7
8
9
10
TOTAL
system (W)
System thermal dissipation (W)

Heat dissipation
Heat dissipation
The CS 1000E is equipped with a cooling system and does not have heat dissipation problems
under normal applications. Mounting in the rack is not restricted.
Use the Power consumption worksheets on page 190 to determine the thermal load generated
by system components and Media Gateway packs.
For air conditioning purposes, 1 ton = 12 000 Btu.
Uninterruptible Power Supply

An Uninterruptible Power Supply (UPS) generally consists of a combination battery charger
(AC/DC converter) and inverter (DC/AC converter), along with associated batteries. The
batteries can be internal or external to the UPS. A UPS is not a standby power source, but an
online unit with no output interruption when the AC power is interrupted.
There are a number of UPS vendors and systems available. Factors to consider when choosing
a UPS include:
• input voltage and frequency range
• output voltage and current capacity
• number and type of output receptacles
• regulatory and safety agency approvals
• efficiency and performance considerations
• alarm and status indications
• battery recharge time
• the maximum time backup power is required
• existing batteries or other power equipment available at the site
• future system growth
UPS sizing
To determine UPS sizing, sum the values given in Table 23: Current, power, and cooling
requirements for CS 1000E components on page 187 and Table 24: Power and cooling
requirements for Media Gateway packs on page 189 for UPS requirements for the applicable
components and Media Gateway packs. The value in watts (W) is equivalent to a volt-ampere
(VA) rating. Size the UPS in terms of its rating in VA (or kVA). For AC-powered systems,

Power and grounding
Enterprise Configurator calculates the system power consumption in both watts and volt-
amperes.
To determine the sizing and provisioning of UPS batteries, follow the instructions provided by
the UPS manufacturer. A general approach is to take the total system power in watts, divide
by the UPS inverter efficiency, and convert to battery current drain by dividing by the nominal
discharge voltage of the battery string. Then determine the battery requirements in ampere-
hours (A-hrs) by multiplying the battery current drain by the required reserve power operating
time.
UPS installation
When installing a UPS, follow the vendor's instructions carefully.
Avaya recommends installing a bypass switch during the initial UPS wiring (if the switch
function is not inherently a part of the UPS itself). The UPS bypass switch lets the system run
directly from the commercial power source while the UPS is taken off-line during installation,
service, or battery maintenance.
Caution:
Damage to Equipment
Take care when connecting battery cables to the UPS. Connecting battery cables backward
can result in severe damage to the UPS.
Figure 53: Typical UPS wiring plan on page 197 shows a typical UPS wiring plan.

Power requirements for IP Phones
Figure 53: Typical UPS wiring plan
Power requirements for IP Phones

The IP Phones and IP Softphone require 16 V AC, 500 mA that is supplied by a local
transformer. The appropriate transformer depends on the line voltage, which is different for
each country.
IP Phones also accommodate 48 V DC power. IP Phones can be powered over the LAN by a
Layer 2 switch such as a Ethernet Routing Switch 2526T-PWR (see Layer 2 switch on
page 91). For more information about Power over LAN, see Avaya Converging the Data
Network with VoIP Fundamentals, NN43001-260.

Power and grounding

Chapter 12: Design parameters
Contents
System parameters on page 200
Customer parameters on page 200
Console and telephone parameters on page 201
Trunk and route parameters on page 202
ACD feature parameters on page 202
Special feature parameters on page 203
Hardware and capacity parameters on page 205
Call Server memory related parameters on page 206
Introduction
This section describes sets of design parameters that set an upper boundary on certain system
capacities. Changes to these parameters generally require a revision to the software and are
constrained by other basic capacities such as memory and traffic or system load. The design
parameters are set to provide the best possible balance between limits.
Note on terminology
The term Media Gateway refers to the Avaya CS 1000 Media Gateway 1000E (Avaya MG
1000E), and Media Gateway 1010, (MG 1010). The MG 1010 provides ten IPE slots. The
Avaya MG 1000E provides four IPE slots.

Design parameters
Each MG 1000E can be connected to an optional Media Gateway Expander in order to

increase capacity to eight IPE slots. In this chapter, the term MG 1000E includes the optional
Media Gateway Expander, if equipped.
System parameters
Table 29: System parameters on page 200 lists system parameters and provides their
maximum values.
Table 29: System parameters
System parameters Maximum value Comments

Customers 100
Display messages for background 255
terminal
Input/output ports (for example, 16 Two physical (Com 1 and Com 2)
TTYs and printers) and fourteen PTYs to Terminal
Server (history file counts as one
device)
AML/CSL links 16 IP links
TNs Software design limit. Actual
– Avaya Communication Server number of TNs will be constrained
1000E (Avaya CS 1000E) by physical capacity, real time,
65 534 memory, and License limits.
Media Cards Limit of Media Cards, which
includes banks of 32 DSPs on DSP
256 daughter cards.
DSPs 8192 DSP limit on a system (256 * 32)
Customer parameters
Table 30: Customer parameters on page 200 lists customer parameters and their maximum
values.
Table 30: Customer parameters
Customer parameters Maximum value Comments

Tenants 512

Console and telephone parameters
Customer parameters Maximum value Comments

Dial Intercom Groups 2046
Members per Dial Intercom Group 100
Ringing Number Pickup groups 4095 Call Pickup Group 0 = no
pickup group
Listed Directory Numbers (direct inward 6
dialing only)
DISA DNs 240
Console and telephone parameters

Table 31: Console and telephone related parameters on page 201 lists console and telephone-
related parameters and their maximum values.
Table 31: Console and telephone related parameters
Console/telephone parameters Maximum value Comments

Consoles per customer 63
Lamp field arrays per customer 1 May be repeated once on
another console.
Lamps per array (all numbers must be 150
consecutive)
Feature keys per attendant console: –
Avaya 2250 Attendant Console 20
Incoming call indicators per console 20
Trunk group busy indicators per
console: – Avaya 2250 Attendant
Console 20
Additional key/lamp strips:
– console – telephones 26
Add on modules: 2
– Avaya 3904 Key Expansion Module 1 one-page
(KEM) KEM
– IP Phone 2002 KEM 2 one-page
– IP Phone 2004 KEM KEM
or
1 two-page KEM
Protect bcs block length 512

Design parameters
Trunk and route parameters

Table 32: Trunk and network-related parameters on page 202 lists trunk and network-related
parameters and their maximum values.
Table 32: Trunk and network-related parameters
Trunk/network parameters Maximum value Comments

Trunk routes per customer 512
Members per trunk route 510
RAN trunks per RAN route 10
Trunk access restriction groups 32
Locations in an ESN network 1000 or 16 000 1000 without ESN Location
Code Expansion (LOCX)
package 400; 16 000 with the
LOCX package 400
Basic authorization codes 4096
Length of basic authcode 14 digits
Network authorization codes 20 000 ESN networks
Length of network authcode 7 digits Fixed length defined per
customer
NCOS: – CDP – BARS/NFCR – NARS/
NSIG/AUTOVON 3 7 15
Route lists: – CDP – BARS – NARS 32 128 256
Route list entries 64
NFCR trees 255 New Flexible Code Restriction
IDC trees 255 Incoming DID Digit
Conversion
Virtual Trunk D-channels 64
ACD feature parameters

Table 33: ACD feature parameters on page 203 lists ACD feature parameters and their
maximum values.

Special feature parameters
Table 33: ACD feature parameters
ACD parameters Maximum value Comments

ACD DNs and CDNs per customer 2000 (CP PIV, 2000 with ACD-F package
CP PM) (411), 1000 with ACD-E
package
Agent positions per DN 1200 real time and physical capacity
constraints can limit this
further.
Agent priorities 48
Agent IDs per customer 9999
Agents logged in at one time per system 9999 real time constraints can limit
this further.
AST DNs per telephone 4 4 with ACD-F package (411),
otherwise the limit is 2
Number of ACD-ADS customers 5
Terminals and printers on CCR 8
Links per VASID 1
Special feature parameters

Table 34: Non-ACD feature parameters on page 203 lists nonACD feature parameters and
their maximum values.
Table 34: Non-ACD feature parameters
Feature parameters Maximum value Comments

Speed call lists per system 8191 The number of speed call
lists and the number of
DNs per speed call list can
be limited by the amount
of available memory on
the system (protected and
unprotected data store).
Number of DNs in speed call list 1000
Multiple appearances of the same 30* Limited by watchdog
directory number (MADN) timer.
*See Steps in a hunting
group.

Design parameters
Feature parameters Maximum value Comments

Steps in a hunting group 30* Marketing objective,
limited by watchdog
timer.
*In combination with
MADN, each hunt step
with more than 16
appearances is counted
as two, so the maximum
combination of MADN
and hunt steps is 30
MADN and 15 hunt
steps.
Number of Call Party Name Display Variable Limited by the number of
names defined DNs defined and
available space in the
protected data store.
CPND length: – SL-1 protocol – ISDN 27 24 Software design limit.
protocol Display IE limitation (DMS
switches have a display IE
limit of 15).
AWU calls in 5 minutes 500 Marketing objective,
constrained by ring
generator.
Group Call Feature: –Groups per
customer –Stations per group 64 10
BRI application: –Protocol parameter 16 Software design limit;

telephone groups per system –Terminal 32 000 actual number is
service profiles (per DSL) DSLs 640 000 constrained by the
–LTIDs number of TNs in the
system. Each DSL
occupies 2 TNs. Software
design limit; each DSL
can have a maximum of
20 LTIDs. The maximum
number of LTIDs is limited
by the number of DSLs, by
memory, and by real
time.
Mobile Extensions per customer 4000 Software design limit. Can
be further constrained by
PRI requirements.

Hardware and capacity parameters
Hardware and capacity parameters

The software design limits are not typically the binding constraints. The number of items of a
particular type is usually determined by a combination of loop and slot constraints (if the item
requires loops) or by slot constraints alone.
Table 35: Physical capacity/hardware-related parameters on page 205 lists hardware and
capacity parameters and their maximum values for TDM conference.
Table 35: Physical capacity/hardware-related parameters
Physical capacity/hardware Maximum value Comments

parameters (loops)
MGCONF 2 Provide Conf, and MFS
functionality for the cards in
that Media Gateway. 30 units
for each loop.
MGTDS 2 Provide TDS functionality for
the cards in that Media
Gateway. 30 units for each
loop.
Total service and terminal loops 256 Each superloop requires 4
loops.
Communication Server 1000E Co-resident Call Server and

Signaling Server design parameters
An Avaya CS 1000E Co-resident Call Server and Signaling Server (Co-res CS and SS) system
uses the same architecture and design parameters as the Communication Server 1000E
Standard Availability or High Availability system. The co-resident heavy CPU load constrains
the number of supported phones and trunks because both the Call Server and Signaling Server
applications run on one CPU. For more information about the Co-res CS and SS physical
capacity limitations, see Physical capacity on page 213.
Media Cards
A Media Card is a card that provides additional DSP resources for a Media Gateway beyond
the DSP resources provided by the Gateway Controller. Media Card is a term for the Media

Design parameters
Card 32-port secure line card, Media Card 32-port line card, and the Media Card 8-port line
card.
In the CS 1000E, Media Cards are used primarily for DSP connections between the TDM
devices in a Media Gateway and IP circuits.
Media Cards can be assigned to any nonblocking slot other than slot 0. You must provision
each Media Gateway with enough DSP ports to support the TDM devices in that Media
Gateway.
Call Server memory related parameters

Table 36: Memory related parameters on page 206 lists Call Server memory related
parameters and their maximum values.
Table 36: Memory related parameters
Values
Parameter CS 1000E
Low-priority input buffers 95 – 5000
(3500)
• (recommended default)
High-priority input buffers 16 – 5000

(3500)
Input buffer size (words) 4

500-telephone, trunk and digital telephone 16 –2048
output buffer (2000)
Message length (words) 4

D-channel input buffer size (bytes) 261
D-channel output buffer size (bytes) 266
TTY input buffer size (characters) 512
TTY output buffer size (characters) 2048
Number of call registers 26 – 65 000
(35 000)
• (recommended)
Call registers assigned to AUX 26–255

Number of AML msg call registers 25 – the minimum of 25% of total call
registers or 255
(default 25)

Buffer limits
Values
Parameter CS 1000E
Call registers for AML input queues (CSQI) Up to 25% of total call registers (NCR),
minimum 20
Call registers for AML output queues Up to 25% of total call registers (NCR),
(CSQO) minimum 20
Auxiliary input queue 20 – the minimum of 25% of total call
registers or 255
(default 20)
Auxiliary output queue 20 – the minimum of 25% of total call
registers or 255
(default 20)
History file buffer length (characters) 0 – 65 535
In a system with Avaya CallPilot, AML, and Symposium, add the number of CSQI and CSQO
to the Call Register (CR) requirement obtained from feature impact calculations.
The buffer estimates were based on relatively conservative scenarios, which should cover
most practical applications in the field. However, most models deal with "average traffic".
When traffic spikes occur, buffers can overflow. In these cases, raise the buffer size,
depending on the availability of CRs. The maximum number of buffers allowed for CSQI
and CSQO is up to 25% of total call registers (NCR).
Buffer limits
The buffer limit is the maximum number of Call Registers (CR) that can be used for that
particular function out of the total CR pool. If the designated limit is larger than needed and
there are still spare CRs, the unused CRs will not be tied up by this specific function. Therefore,
there is little penalty for overstating the buffer size limit, as long as the limit is within the number
of CRs available to the system.
The values provided in Table 36: Memory related parameters on page 206 indicate the relative
requirements for various buffers. They are the minimum buffer size needed to cover most
applications under the constraint of tight memory availability. When increasing buffer sizes,
make the increases proportional to the values in Table 36: Memory related parameters on
page 206. This guideline applies in all cases except CSQI/CSQO, which is relatively
independent of other buffers and can be increased without affecting others.
For example, with a CS 1000E Call Center (maximum 25 000 CRs) using many applications
(such as CallPilot), it would be advisable to set the CSQI/CSQO to a high value (even up to
the limit of 25% of NCR). Note that the value of NCR should be increased to account for the
requirements of CSQI and CSQO.

Design parameters
Access Restrictions packet logging memory limits

The Access Restrictions feature, also known as the port blocking facility enables a VxWorks
firewall to prevent port-based attacks on the CP PIV, MGC, and MC32S. Enabling the port
blocking rule list starts performance statistics and logging that requires 384 kB of memory. 64
kB for the rule list, 64 kB of memory to allow for logging, and 256 kB for performance statistics.
Memory logging is limited to use a maximum 55 MB of memory.
You can log the packets to the tty or to a first in first out (FIFO) wrap around memory buffer.
The logging data can be written to a file. Port blocking logs are independent from the system
logs, and store in a portacc.log file on the removable CF card of the CP PIV, and /e partition
of the MGC and MC32S.

Chapter 13: System capacities
Contents
Memory size on page 210
Mass storage on page 212
Physical capacity on page 213
CS 1000E network traffic on page 217
Real time capacity on page 229
Signaling Server on page 234
Software configuration capacities on page 247
CS 1000E capacities on page 247
Zone/IP Telephony Node Engineering on page 248
Introduction
This chapter describes the system's primary capacity categories. For each category, this
chapter:
• identifies the units that the capacity is measured
• details the primary physical and functional elements affecting the capacity
• describes actions that can be used to engineer the capacity
Resource calculations on page 249 provides the algorithms for engineering the system within
the capacity limits. In some cases, applications such as Call Center require detailed
engineering. These applications are discussed in Application engineering on page 323

System capacities
Memory size
Table 37: Avaya CS 1000 memory requirements on page 210 shows the minimum amount of
memory required for Avaya Communication Server 1000 (Avaya CS 1000) software.
Table 37: Avaya CS 1000 memory requirements
System FMD Flash Drive required DRAM memory

required
CS 1000E SA or HA (CP PIV) 1 GB 512 MB
CS 1000E SA or HA (CP PM) 1 GB 1 GB
CS 1000E CP PM Co-res CS and N/A 2 GB
SS
CS 1000E CP MG Co-res CS N/A 2 GB
and SS
CS 1000E CP DC Co-res CS and N/A 2 GB
SS
CS 1000E COTS2 Co-res CS N/A 4 GB
and SS
CS 1000E Common Server Co- N/A 4 GB
res CS and SS
CS 1000E CP PM TDM N/A 2 GB
CP PIV and CP PM VxWorks based SA and HA Call Servers can be upgraded to a maximum
of 1 GB DRAM memory.
CP DC cards can be upgraded to a maximum of 4 GB DRAM memory.
Table 38: Recommended call register counts on page 210 shows the call register count
recommended for Communication Server 1000 software, so that the system's memory
requirements do not exceed the processor's memory capacity.
Table 38: Recommended call register counts
System Recommended Memory Memory

call register required (SL-1 required (MB)
count words)
CS 1000E HS (CP PM large 60 000 13 680 000 52.185
deployment, see note)
CS 1000E (CP PIV and CP PM) 35 000 7 980 000 30.441
CS 1000E Co-res CS and SS 20 000 4 560 000 17.395
Call registers are 228 SL-1 words long. One SL-1 word is 4 bytes.

Memory engineering
System Recommended Memory Memory

call register required (SL-1 required (MB)
count words)
Note:
A large deployment is greater than 11 500 SIP Line users or greater than 22 500 UNIStim
users.
Memory engineering
Current call processors for the CS 1000E are shipped with sufficient memory for the supported
line sizes of the individual CPU types. Memory engineering is not required for most items.
Customer data is split between unprotected data store (UDS) and protected data store (PDS).
Using LD 10 or LD 11 and looking at the memory usage, you can determine the amount of
memory left on a system.
>ld 11 SL1000 MEM AVAIL: (U/P): 8064848 USED U P: 8925713 4998811 TOT: 21989372
The preceding example shows that there is 8,064,848 SL1 words (32,259,392 bytes) of
memory left that can be used for either UDS or PDS. When the amount of available memory
drops to be very low this will be shown as amount of UPS available and PDS available.
The preceding example also shows that currently 8,925,713 SL1 words (35,702,852 bytes) of
UDS in use and 4,998,811 SL1 words (19,995,244 bytes) of PDS in use.
The major consumer of unprotected data store (UDS) is call register definitions. Therefore
before increasing the number of call registers on a system, check that there is sufficient UDS
available.
The major consumer of protected data store (PDS) is speed call lists. The overlay used to
create speed call lists does the memory calculations (based on the number of lists, size of lists
and DN sizes).
For definitions of large numbers of sets, it is recommended that you look that the available
memory, create a single set and see how much memory was consumed. Then determine if
there is sufficient memory left to create all of the desired sets.
Call register usage

Call register requirements on a system vary with usage and call patterns. In general you want
at least 20% more call registers than sets, but this can vary with trunk usage or other features
(ACD).

System capacities
Assumptions:
• Call Register Traffic Factor (CRF) = 1.865
• The formula for calculating the recommended number of call registers depends on traffic
load for the system.
• 28 centi-call seconds (CCS) for each ACD trunk
• Snacd = (Number of calls overflowed to all target ACD DNs × 2.25) – (Number of calls
overflowed to local target ACD DNs × 1.8) (= 0 if the system is not a source node)
• Tnacd = 0.2 × Number of expected calls overflowed from source (= 0 if the system is not
a target node)
• ISDN CCS = PRI CCS + BRI CCS
• ISDN penetration factor: p = ISDN CCS ÷ Total Voice Traffic
• ISDN factor: (1 – p)^2 + [4 × (1 – p)] × p + (3 × p^2)
If Total Voice Traffic > 3000 CCS, then:

Recommended number of call registers = (CRF * 0.071 × Total Voice Traffic) +
(0.33 × Number of ACD incoming trunks) + [(Snacd + Tnacd) × 0.03 × ISDN factor]
If Total Voice Traffic < 3000 CCS, then:
Recommended number of call registers = [(Number of system equipped ports –
Number of ACD incoming trunks – Number of ACD agent telephones) × 0.94] +
{(Number of ACD incoming trunks * 1.21) + [(Snacd + Tnacd) × 0.03]}
A general call register equation would be:
Recommended number of call registers = total ports + (total ports x trunking
factor)
trunking factor = (1 – p)^2 + [4 × (1 – p)] × p + (3 × p^2)
p (penetration factor) = trunking CCS ÷ Total Voice Traffic
Mass storage
The system processor program and data are loaded from a Fixed Media Disk (FMD).
Depending on the hardware platform, the FMD can be a hard disk drive (HDD) or Compact
Flash (CF) card.
Software installation
Software, customer databases, and PEPS are delivered to the system using a Removable
Media Disk (RMD), either CF card or USB, inserted into the Server. An installation process

Database backup
copies the software to the on-board FMD. The software subsequently operates on the Server
FMD.
Database backup
The RMD can also be used for customer database backups.
Physical capacity
The following physical capacities are discussed in this section:
• CS 1000E SA and HA physical capacity on page 213
• CS 1000E Co-resident Call Server and Signaling Server physical capacity on
page 214
• CS 1000E TDM physical capacity on page 214
CS 1000E SA and HA physical capacity

The CS 1000E SA or HA system (CP PIV or CP PM) supports a maximum of
• 22 500 IP Phones (UNIStim + 2 × SIP Line), where SIP Line = (SipN telephones + Sip3
telephones) and the total number of SIP Line telephones must be <= 11 500
• 50 Media Gateways
• 8000 TDM telephones
• 100 PRI spans
A CS 1000E SA or HA system configured for IP only can support 40 000 IP Phones (UNIStim
+ 2 × SIP Line), where SIP Line = (SipN telephones + Sip3 telephones) and the total number
of SIP Line telephones must be <= 20 000.
A fully expanded CS 1000E system, with 50 MG 1000Es each equipped with an Media
Gateway Expander, provides 400 card slots (50 × 8) to support TDM devices and their required
DSP resources.
A fully expanded CS 1000E system, with 50 MG 1010s, provides 500 card slots (50 × 10) to
support TDM devices and their required DSP resources.
A maximum of 256 loops are available to be used for gateway definitions, MGCONF and
MGTDS definitions, and phantom or virtual loops for telephones and trunks. For more

System capacities
information about phantom and virtual loops, see the Global Software Licenses chapter in
Avaya Features and Services Fundamentals, NN43001-106.
For information about loop and card slot usage and requirements for the Media Gateways in
the CS 1000E, see Assigning loops and card slots in the Communication Server 1000E on
page 375 .
CS 1000E Co-resident Call Server and Signaling Server

physical capacity
The CS 1000E Co-res CS and SS supports a maximum of
• 1000 IP Phones (UNIStim + SIP Line), where SIP Line = (SipN telephones + Sip3
telephones) and the total number of SIP Line telephones must be <= 1000
• 16 PRI spans
• 400 virtual trunks
• 200 ACD agents
• 5 NRS endpoints with up to 20 routing entries
• 5 Branch Offices
The Communication Server 1000E Co-res CS and SS is supported on various hardware
platforms with varying physical capacities. For platform specific CS 1000E Co-res CS and SS
capacity information, see Avaya Co-resident Call Server and Signaling Server Fundamentals,
NN43001-509.
CS 1000E TDM physical capacity

The CS 1000E TDM supports a maximum of
• 16 PRI spans
• 200 ACD agents
The CS 1000E TDM is supported on the CP PM, CP DC, and CP MG 128 hardware
platforms.

Signaling and data links
The CS 1000E TDM system does not support any IP Phones (UNIStim, SIP Line, or SIP
DECT), virtual trunks, or an NRS. For more information about CS 1000E TDM, see Avaya Co-
resident Call Server and Signaling Server Fundamentals, NN43001-509.
Signaling and data links

The following signaling and data links are discussed in this section:
• Physical links on page 215
• Functional links on page 216
Physical links
There are two types of physical links to consider:
• Serial Data Interface (SDI) on page 215
• Local Area Network (LAN) on page 215
Serial Data Interface (SDI)

The SDI is an asynchronous port, providing input access to the system from an OAM terminal
and printing out maintenance messages to a TTY. Server cards typically have two SDI ports,
COM 1 and COM 2. COM 1 (TTY1) must be used for system installation and upgrades.
Local Area Network (LAN)

The system can communicate over the LAN with Ethernet connections through a Network
Interface Card (NIC). The CS 1000E LAN contains subnets for the Embedded Local Area
Network (ELAN) and the Telephony Local Area Network (TLAN). AML messages are
embedded in the communication protocols, and they continue to interface with the system
through CSQI and CSQO queues.
The data rate at the NIC port autonegotiates up to 1000 MB full duplex.

System capacities
Functional links
For each of the following functions, the type of link and resulting capacity are given.
Application Module Link (AML)

AML is an Ethernet signaling link between the system and an Application Module (AM)
connected to the ELAN subnet.
OAM
The system uses a SDI port to connect to a terminal/computer (TTY) to receive maintenance
commands or to print traffic reports, maintenance messages, or CDR records.
ISDN Signaling (ISL)

An ISL provides common channel signaling for an ISDN application without PRI trunks. An
analog trunk with modems at the originating switch and the terminating switch can be used as
an ISL to transmit ISDN messages between these two remote systems. The interface for an
ISL is an ESDI port. The maximum data rate for the link is 19.2 kbps.
D-Channel
A PRI interface consists of 23 B-channels (30 in Europe based on E1) and 1 D-channel. The
D-channel at 64 kbps rate is used for signaling. A D-channel communicates with the system
through a DCHI card or a DCHI port on the D-channel handler. A D-channel on a BRI set is a
16 kbps link that is multiplexed to make a 54 kbps channel.

Property Management System Interface (PMSI)
Property Management System Interface (PMSI)

The PMSI lets the system interface directly to a customer-provided PMS through an SDI port
in a Terminal Server. It is primarily used in Hotel/Motel environments to allow updates of the
room status database either from the check-in counter or a guest room. The enhanced PMSI
allows retransmission of output messages from the system to a PMS. The maximum baud rate
for this asynchronous port is 9600.
Table 39: I/O interface for applications on page 217 summarizes the above functional links
and interfaces and provides information required to calculate the number of I/O cards needed
as an input to the card slot calculations.
Table 39: I/O interface for applications
Application Type of link/ Type of port Sync or async

interface
AML (associated telephone) AML ESDI Sync
Symposium ELAN Ethernet Sync
CallPilot ELAN Ethernet Sync
CDR RS232 C PTY Async
Host Enhanced Routing AML ESDI Sync
Host Enhanced Voice Processing CSL & AML ESDI Sync
ISL Modem ESDI Sync
Interactive Voice Response CSL ESDI Sync
Meridian 911 AML ESDI Sync
Property Management System PMSI Link PTY Async
Interface (PMSI)
NACD (PRI) 64 kB D-channel DCHI Sync
TTY (OAM) RS232 C PTY Async
An ESDI card has two ports; an SDI card has two ports; a DCHI card has one DCHI port
and one SDI port.
CS 1000E network traffic

Traffic is a measure of the time a circuit is occupied. On the system, the circuit normally consists
of a path from the telephone or trunk to the terminating telephone or trunk.

System capacities
This section discusses the following traffic considerations:

• Loops and superloops on page 218
• Lines and trunks on page 220
• Service loops and circuits on page 222
• Media Cards on page 227
• Traffic capacity engineering algorithms on page 227
Terminology
Basic traffic terms used in this section are:
• ATTEMPT – any effort on the part of a traffic source to seize a circuit/channel/timeslot
• CALL – any actual engagement or seizure of a circuit or channel by two parties
• CALLING RATE – the number of calls per line per busy hour (Calls/Line)
• BUSY HOUR – the continuous 60-minute period of day having the highest traffic usage,
usually beginning on the hour or half-hour
• HOLDING TIME – the length of time that a call engages a traffic path or channel
• TRAFFIC – the total occupied time of circuits or channels, generally expressed in Centi-
Call Seconds (CCS) or Erlangs (CCS = a circuit occupied 100 seconds; Erlang = a circuit
occupied one hour)
• BLOCKING – attempts not accepted by the system due to unavailability of the resource
• OFFERED traffic = CARRIED traffic + BLOCKED traffic
• Traffic load in CCS = Number of calls × AHT ÷ 100 (where AHT = average holding time)
• Network CCS = Total CCS handled by the switching network or CCS offered to the network
by stations, trunks, attendants, Digitone Receivers, conference circuits, and special
features
Communication Server 1000E engineering is typically based on measurements you perform
in an hour (typical busy hour). This applies to traffic load in CCS and Network CCS.
Loops and superloops

The number of loops and superloops on a CS 1000E is calculated form the number of lines,
trunks, cards, and Media Gateways configured. The CS 1000E does not use the traffic
requirements to determine loop usage.

Loop counting
Loop counting
• 1 Virtual Superloop has 1024 TNs (IP Phones, Vrtks, IP Media Services)
• 2 Media Gateways per Superloop (Media Gateway PRI Gateway counts as 1 Media
Gateway)
• Gateway Controller card
- 1 loop per TDS definition (30 units per loop).
- 1 loop per Conference definition (30 units per loop).
- Can define up to 2 Conference loops and 2 TDS loops.
• IP Media Services are IP tone, IP conference, IP attendant consoles, IP recorded
announcer, and IP music.
- IP tone - 30 units for each tone loop
- IP conference - 30 units for each conference loop
• 1 Phantom loop has 512 units. Used for M39xx Virtual Office.
• 1 Phantom loop has 1024 DECT users.
• 1024 i200x Virtual Office sets per Superloop.
• Every PRI definition requires 1 loop (23 channels TI, 30 channels E1).
• 1024 PCAs per Superloop.
• Limit of 64 Superloops (256 loops).
• Superloops = ROUNDUP(IP Phones + Vrtks) / 1024 + ROUNDUP (MGs / 2) +
ROUNDUP(M39XX_vo / 512) + ROUNDUP(i200x_vo / 1024) + ROUNDUP(PCA / 1024)
+ ROUNDUP(DECT users / 1024) + ROUNDUP ( (2×(SIPN + SIP3 users) ) / 1024)
• Loops = ROUNDUP(Conference Ports / 30) + TDS loops (minimum 1 for each MGC) +
PRI or DTI cards + (1000E PRI Gateways × 4)
• Total Loops = Loops + IP tone loops + Superloops × 4
• Total Loops > 256 is an error, too many loops being used.
• Total Superloops = ROUNDUP(Total Loops / 4)
Note:
Conference ports can be TDM or IP.

System capacities
Superloop capacity
On a TDM based system (CS 1000M) each superloop is constrained by the number of talkslots
and the number of CCS that the superloop can carry.
The CS 1000E is an IP based system and does not have the same constraints. All Virtual
superloops use "virtual talkslots" and are nonblocking (one virtual talkslot per virtual TN). This
also removes the CCS per superloop constraint.
The Media Gateway has a nonblock TDM backplane (1 talksot per TDM unit). Call blocking
can only occur here for other required resources (DTR, TDS, DSP, etc) which must all exist
within the same Media Gateway as the phone requiring the resource.
Loop capacity and Media Gateway TDM resources are subject to the Grade-of-Service (GoS)
described under Grade-of-Service on page 227.
Lines and trunks

The relationship between lines and trunks is relevant for calculating loop requirements.
Voice over IP traffic

In the context of Voice over IP (VoIP) application, the lines include IP Phones and the trunks
include IP Peer H.323 Virtual Trunks and SIP Virtual Trunks. The ratio of IP calls to the total
line calls, and the ratio of H.323 and SIP Virtual Trunks calls to the total trunk calls, are required
parameters. The split of TDM traffic to IP/Virtual Trunks (VT) becomes important, since
resources such as Digital Signal Processor (DSP) in Media Cards and H.323 or SIP Virtual
Trunks are affected by traffic distribution.
Figure 54: CS 1000E system call types on page 221 is a representation of the traffic flow for
different types of calls. Each connection is denoted by a line. Only lines crossing the DSP line
require a DSP port. For example, IP to IP connections in a CS 1000E system require no DSP
and neither do IP to VT, but TDM to TDM do require DSP.

Voice over IP traffic
Figure 54: CS 1000E system call types
Table 40: Connection type resources required on page 221 lists the resources required for
each type of connection.
Table 40: Connection type resources required
Connection Type Resources

TDM to UNIStim IP, UNIStim IP to TDM DSP
TDM to VT, VT to TDM DSP and VT
UNIStim IP to UNIStim IP no DSP, no VT
UNIStim IP to VT or VT to UNIStim IP VT
TDM to TDM telephone or trunk calls no DSP*, no VT
TDM to SIP Line or SIP Line to TDM DSP, VT
SIP Line to SIP Line VT
SIP Line to VT or VT to SIP Line VT
SIP Line to UNIStim IP or UNIStim IP to SIP Line VT
* You require DSPs in each Media Gateway for TDM calls between Media Gateway
chassis.
See Resource calculations on page 249 for the algorithms to calculate the required
resources.

System capacities
Service loops and circuits

Service circuits are required in call processing to provide specific functions to satisfy the
requirements of a given application. Service circuits consume system resources, such as
physical space, real time, memory, and so on.
In the CS 1000E, virtual tone and conference circuits (MGTDS and MGCONF) must be defined
for use by each Media Gateway.
This section describes the traffic characteristics, calculation algorithms, and impact on other
system resources of the following types of service circuits:
• TDS on page 222
• Conference on page 222
• Broadcast circuits on page 223
• DTR on page 224
• IP Media Services on page 225
TDS
The Tone and Digit Switch (TDS) loop provides dial tone, busy tone, overflow tone, ringing
tone, audible ringback tone, DP or dual tone multifrequency (DTMF) outpulsing, and
miscellaneous tones. All these tones are provided through the maximum 30 timeslots in the
TDS loop.
A minimum of one TDS loop is required in each Media Gateway. The TDS circuits are provided
by the MGC card. If additional TDS circuits are required in any Media Gateway, a second TDS
loop can be configured in it. TDS circuits in a Media Gateway provide tones for TDM telephones
or trunks in that Media Gateway only.
Conference
The MGC has a maximum of 2 conference loops, with 30 conference circuits for each
conference loop, for a total of 60 conference circuits for each MGC-based Media Gateway.
The maximum number of parties involved in a single conference on a Media Gateway with
Gateway Controller is 30. Conference circuits in the CS 1000E are a system resource.
Conference loops can be TDM or IP.

Broadcast circuits
Broadcast circuits
The Avaya Integrated Recorded Announcer (Recorded Announcer) card provides either 8 or
16 ports to support Music, Recorded Announcement (RAN), and Automatic Wake Up. There
is a maximum of 60 simultaneous connections to an individual card for broadcast within a
Media Gateway. The use of controlled broadcast with Symposium and MGate cards has the
same simultaneous connection limit as broadcast circuits. With special provisioning, the limit
can be increased to 120 connections (see Broadcast circuits on page 383).
Music
Music Broadcast requires any Music trunk and an external music source or a Recorded
Announcer card. The Recorded Announcer has the capability to provide audio input for external
music. A CON loop is not required for Music Broadcast.
Network Music
With the Network Music feature, a networked Central Audio Server is attached to the CS 1000E
system to be used as the music source on demand to all parties on hold. With Network Music,
the CS 1000E systems supports MOH features without a locally equipped music source for
each node. Network Music feature provides music to every node in the system
The Central Audio Server is accessed over the network through H.323/SIP virtual trunks or
TDM trunks. Virtual trunks or TDM trunks are connected to a network music trunk through an
analog TIE trunk, the Network Music TIE trunk. Network Music is implemented with an XUT
pack (NT8D14) and a network music agent. Broadcast music or conference music is set up so
that multiple held parties can share the same music trunk.
To maximize the resource efficiency, the music is broadcast so that multiple parties can share
the same music trunk. One music trunk can support a maximum of 64 listeners with broadcast
music.
RAN
RAN trunks are located on eight-port trunk cards on PE shelves just like regular trunk circuits.
They provide voice messages to waiting calls. RAN trunks are also needed to provide music
to conference loops for music on hold.
Each RAN trunk is connected to one ACD call at a time, for the duration of the RAN message.
Different RAN sources require different RAN trunk routes. If the first RAN is different from the
second RAN, they need different RAN trunk routes. However, if the same message is to be
used, the first RAN and second RAN can use the same route.
Use the following formula to calculate RAN traffic:
RAN CCS = Number of ACD calls using RAN × RAN HT ÷100
A RAN message typically runs from 20 seconds to 40 seconds. If the average for a specific
application is not known, use a default of 30 seconds. After RAN CCS is obtained, estimate
RAN trunk requirements from a Poisson P.01 table or a delay table (such as DTR table)
matching the holding time of a RAN message.

System capacities
DTR
A Digitone Receiver (DTR) serves features involving 2500 telephones or Digitone trunks. In
CS 1000E systems, DTRs are not system-wide resources. They support only the telephones
and trunks in the Media Gateway that they reside.
The MGC card provides 16 DTRs, or 8 DTRs and 4 Multifrequency Receivers (MFR). Additional
DTRs can be provided by XDTR cards.
There are a number of features that require DTRs. General assumptions for DTR traffic
calculations are:
• DTR traffic is inflated by 30% to cover unsuccessful dialing attempts.
• Call holding time used in intraoffice and outgoing call calculations is 135 seconds if actual
values are unknown.
• DTR holding times are 6.2 and 14.1 seconds for intraoffice and outgoing calls,
respectively.
• The number of incoming calls and outgoing calls are assumed to be equal if actual values
are not specified.
The major DTR traffic sources and their calculation procedures are as follows:
1. Calculate intraoffice DTR traffic:
Intraoffice = 100 × DTR station traffic (CCS) ÷ AHT × (R ÷ 2) (Recall that R is the
intraoffice ratio.)
2. Calculate outgoing DTR traffic:
Outgoing = 100 × DTR station traffic (CCS) ÷ AHT × (1 - R ÷ 2)
3. Calculate direct inward dial (DID) DTR traffic:
DID calls = DID DTR trunk traffic (CCS) × 100 ÷ AHT
4. Calculate total DTR traffic: Total = [(1.3 × 6.2 × intra) + (1.3 × 14.1 × outgoing calls)
+ (2.5 × DID calls)] ÷ 100
5. See Digitone receiver load capacity 6 to 15 second holding time on page 418 to
determine the number of DTRs required. Note that a weighted average for holding
times should be used.

IP Media Services
IP Media Services
IP Media Services is a term used for a group of services. The services supported are:
• IP Tone generation for IP Phones
• IP Conference
• IP Music
• IP Recorded Announcer
• IP Attendant Console
IP Tone
IP Tone is required for IP Phone blind transfers (ring back tone required). Approximately 3
percent of IP Phones are involved in a blind transfer on a system at any given time. Therefore,
IP Tone uses a low amount of media sessions on a system.
Perform the following steps to determine the number of media sessions required to support IP
Tone.
1. Determine the number of calls per hour for IP Phones (UNIStim and SIP).
• Calls involving at least one UNIStim Phone and TPS: CIPtone = C2IP + C1IP +
CSTIV + CSTID + CTSVI + CTSDI + C2SIPUIP
• Calls involving at least one SIP Line Phone using SLG: CSIPtone = C2SIP + C1SIP
+ C2SIPUIP + CSTSV + CSTSD + CTSVS + CTSDS
Total_IP_calls = CIPtone + CSIPtone
2. Determine the number of IP based calls that require an IP Tone.
IP_Tone_calls = Total_IP_calls × 0.03
3. Determine the traffic load (CCS) for IP Tone. Assume the tone is required for 20
seconds.
IPT_CCS = (IP_Tone_calls × 20) ÷ 100
4. Determine the number of IP Tone sessions required.
Use a Poisson 1% blocking (P.01 GOS) formula or table to determine the number
of IP Tone sessions you require.
Note:
IP Tone loops are the same density as TDM loops. Loop counting for determining the number
of loops consumed for IP Tone is the same as TDM.
IP Conference
IP Conference provides IP based conference. The conference port calculations and loop
counting remain the same as the TDM based Conference calculations. DSP resources are not
required for IP Conference.

System capacities
The IP Media Sessions required to support IP Conference is equal to the number of required
conference ports.
Conference ports for each system = (Number of total telephones) × rcon × 0.4
IP Conference Sessions = Conference ports for each system
IP Music
You require one IP media session for every IP Music ISM ordered. You enter the number of IP
Music ISM on the IP Media Services input page.
IP Recorded Announcer
You require one IP media session for every IP Recorded Announcer (IP RAN) ISM ordered.
You enter the number of IP RAN ISM on the IP Media Services input page.
IP Attendant Console
You require one IP Attendant ISM for every IP Attendant console ordered. You order IP
Attendant Consoles on the Consoles and terminals input page. The number of IP Attendant
ISM is displayed on the IP Media Services input page.
IP Media Services sessions

The total number of IP Media Services sessions required on a system is:
MSC_Sessions = IP Conference sessions + IP Tone sessions + (3 × IP Attendant Consoles)
+ IP Music ISM + IP RAN ISM
Each IP Media Services maximum sessions can vary based on the hardware platform and
deployment type. For example, a dedicated CP DC with 2GB of RAM can support 1000
sessions each for IP RAN, IP TONE, and IP MUSIC. A dedicated COTS2, Common Server,
or CP DC with 4GB of RAM can support 4000 sessions each for IP RAN, IP TONE, and IP
MUSIC.

Media Cards
Media Cards
Media Cards (MC32 or MC32S) do not run the Terminal Proxy Server (TPS) application. Media
Cards provide DSP resources. The TPS application only runs on a Signaling Server.
All the Media Cards in a specific Media Gateway must be in the same zone, so that bandwidth
management and codec selection can be performed properly.
Traffic capacity engineering algorithms

Traffic capacities of subsystems in the system are estimated based on statistical models that
approximate the way a call is handled in that subsystem.
When inputs to the algorithm are lines, trunks, average holding time (AHT), and traffic load
(CCS), the algorithms can be used to determine system size.
Alternatively, when the traffic capacity is known for a given configuration, the algorithms can
be used to determine the traffic level allowed at the line and trunk level while meeting GoS
requirements.
Grade-of-Service
In a broad sense, the Grade-of-Service (GoS) encompasses everything a telephone user
perceives as the quality of services rendered. This includes:
• frequency of connection on first attempt
• speed of connection
• accuracy of connection
• average speed of answer by an operator
• quality of transmission
In the context of the system capacity engineering, the primary GoS measures are blocking
probability and average delay.

System capacities
Based on the EIA Subcommittee TR-41.1 Traffic Considerations for PBX Systems, the
following GoS requirements must be met:
• Dial tone delay is not greater than 3 seconds for more than 1.5% of call originations.
• The probability of network blocking is 0.01 or less on line-to-line, line-to-trunk, or trunk-
to-line connections.
• Blocking for ringing circuits is 0.001 or less.
• Post-dialing delay is less than 1.5 seconds on all calls.
Traffic models
Table 41: Traffic models on page 228 summarizes the traffic models that are used in various
subsystem engineering procedures.
Table 41: Traffic models
Model Assumptions Service criteria Applicability

Erlang B Infinite sources (ratio Blocked calls cleared Loop, ringing circuit blocking
of traffic sources to (no queueing)
circuits > 5:1)
Erlang C Infinite sources Blocked calls Dial tone delay, I/O buffers,
delayed Digitone, RAN trunks
Infinite queue
Poisson Infinite sources Blocked calls held for Incoming/outgoing trunks,
a fixed length Digitone, Call Registers, RAN
trunks
Typically, the GoS for line-side traffic is based on Erlang B (or Erlang Loss formula) at P.01
GoS. When there is no resource available to process a call entering the system, the call is
blocked out of the system. Therefore, the correct model to calculate the call's blocking
probability is a "blocked call cleared" model, which is the basis of Erlang B.
When a call is already in the system and seeking a resource (trunk) to go out, the usual model
to estimate trunk requirements is based on the Poisson formula. The reasons are:
• The Poisson model is more conservative than Erlang B (in that it projects a higher number
of circuits to meet the same GoS). This reflects trunking requirements more accurately,
since alternative routing (or routing tables) for outgoing trunk processing tends to increase
loading on the trunk group.
• General telephony practice is to provide a better GoS for calls already using system
resources (such as tones, digit dialing, and timeslots). Incomplete calls inefficiently waste
partial resources. With more trunk circuits equipped, the probability of incomplete calls is
lower.

Real time capacity
Real time capacity

Real time capacity (load) refers to the ability of the Call Server to process instructions resulting
from calls in accordance with service criteria.
Existing systems can use methods based on traffic data in order to determine Rated Call
Capacity and current utilization levels. See Avaya Traffic Measurement Formats and Outputs
Reference, NN43001-750 for a description of the TFS004 call capacity report and for
information about interpreting TFS004 output.
If a new switch is being configured, equivalent basic calls must be calculated in order to
estimate the processor loading of a proposed configuration.
Equivalent Basic Calls

A basic call is defined as a simple, unfeatured call between two telephones. The terminating
telephone is allowed to ring once, then is answered, waits approximately two seconds, and
hangs up. The originating telephone then hangs up as well.
The basic call is always the call type that consumes the least CPU on the call server. For
Communication Server 1000E SA / HA systems, the basic call is an i2004 to i2004 local call.
For the Communication Server 1000E Co-resident Call Server and Signaling Server (Co-res
CS and SS) system, and the CS 1000E TDM system, the basic call is an analog telephone to
analog telephone call between two Media Gateway chassis. This call requires less CPU than
a UNIStim call because the TPS application in a Co-res CS and SS system runs on the same
CPU as the Call Server.
When the capacity of a switch is stated in Equivalent Basic Call (EBC), it is independent of
such variables as configuration, feature mix, and usage patterns. It still varies from release to
release, and between processors. However, since it is independent of other factors, it is a good
way to compare the relative call processing capability of different machines running the same
software release.
Table 42: Real time capacity (EBC) by system on page 229 gives the rated capacities of the
Call Server processors in systems operating CS 1000 Release 7.5.
Table 42: Real time capacity (EBC) by system
System Capacity cph

CS 1000E (CP PIV) 740 000
CS 1000E (CP PM) 955 000
CS 1000E (CP PM Co-res CS and SS) 132 000 (see note)
CS 1000E (CP MG Co-res CS and SS) 82 000 (see note)

System capacities
System Capacity cph

CS 1000E (CP DC Co-res CS and SS) 330 000 (see note)
CS 1000E (COTS2 Co-res CS and SS) 780 000 (see note)
CS 1000E (Common Server Co-res CS and SS) 780 000 (see note)
Note:
Co-res CS and SS effective throughput is significantly reduced because of high RTM factors
with all calls and UCM load. The effective call throughput is the following
• CP PM - 10 000 cph
• CP DC - 15 000 cph
• CP MG - 8000 cph
• COTS2 - 20 000 cph
• Common Server - 20 000 cph
Feature impact
Every feature that is applied to a call increases the CP real time consumed by that call. These
impacts can be measured and added incrementally to the cost of a basic call to determine the
cost of a featured call. This is the basis of the algorithm used by Enterprise Configurator to
determine the rated capacity of a proposed switch configuration.
The incremental impact of a feature, expressed in EBC, is called the real time factor for that
feature. real time factors are computed by measuring the incremental real time for the feature
in milliseconds, and dividing by the call service time of a basic call.
Each call is modeled as a basic call plus feature increments. For example, an incoming call
from a DID trunk terminating on a digital telephone with incoming CDR is modeled as a basic
call plus a real time increment for incoming DID plus an increment for digital telephones plus
an increment for incoming CDR.
A second factor is required to determine the overall impact of a feature on a switch. This is the
penetration factor. The penetration factor is simply the proportion of calls in the system that
invoke the feature.
The real time impact, in EBC, of a feature on the system is computed as follows:
(Calls) × (penetration factor) × (real time factor)
The sum of the impacts of all features, plus the number of calls, is the real time load on the
system, in EBC.
For penetration and real time factors and for the detailed EBC calculations, see System
calls on page 253 and Table 52: Real time factors on page 258.

Call Server real time calculations
Call Server real time calculations

The system EBC divided by the processor's rated capacity (see Table 42: Real time capacity
(EBC) by system on page 229) yields the fraction for processor utilization. This determines
whether the proposed system can handle the load. If the projected real time load is larger than
the system capacity, a processor upgrade is needed.
Traffic peaking of 30% has been incorporated in the derivation of rated capacity. In other words,
at 100% rated capacity, the absolute loading of the processor is 70%. Users should not adjust
the rated capacity, but the loading percentage can reach 100% and the system can still function
well. However, to preserve spare capacity for growth and extra traffic peaking, initial
engineering of any site at full 100% loading is not recommended. A more typical initial load is
about 85%.
If the configuration is an upgrade to an existing switch, in addition to calculating the new load
as described above, users must also factor in CPU utilization data from a current traffic report
TFS004. Users apply a formula to convert the existing processor usage to the equivalent
loading on the new (and presumably faster) CPU.
Auxiliary processors
Interactions with auxiliary processors also have real time impacts on the system CP depending
on the number and length of messages exchanged. Several applications are described in
Application engineering on page 323.
real time algorithm

As described above, calculating the real time usage of a configuration requires information
about the number of busy hour call attempts and the penetration factors of each feature.
Busy hour calls

If the switch is already running, the number of busy hour calls or call load can be determined
from the traffic printout TFS004. The second field of this report (after the header) contains a
peg count of CP Attempts. Examine a period of several days (a full week, if possible) to
determine the maximum number of CP attempts experienced. This number varies with season,

System capacities
as well. The relevant number is the average of the highest ten values from the busiest four-
week period of the year. An estimate is sufficient, based on current observations, if this data
is not available.
If the switch is not accessible and call load is not known or estimated from external knowledge,
call load can be computed. For this purpose, assumptions about the usage characteristics of
telephones and trunks must be made. For a description of the parameters that are required
and default values, see Resource calculation parameters on page 250.
Telephones
As the primary traffic source to the system, telephones have a unique real time impact on the
system. For the major types listed below, the number of telephones of each type must be given,
and the CCS and AHT must be estimated. In some cases it can be necessary to separate a
single type into low-usage and high-usage categories. For example, a typical office
environment with analog (500/2500-type) telephones can have a small call center with agents
on analog (500/2500-type) telephones. A typical low-usage default value is 6 CCS. A typical
high-usage default value is 28 CCS.
The principal types of telephones include:
• Analog: 500/2500-type, message waiting 500, message waiting 2500, and CLASS
telephones
• Digital: M2000 series Meridian Modular Telephone, voice and/or data ports
• Consoles
• IP Phones 200x and 11xxE
• IP Softphone 2050
Trunks
Depending on the type of trunk and application involved, trunks can either be traffic sources,
which generate calls to the system, or resources that satisfy traffic demands. Default trunk
CCS in an office environment is 26 CCS. Call Center applications can require the default to
be as high as 28 to 33 CCS.
Voice
Analog:
• CO
• DID
• WATS

Data
• FX
• CCSA
• TIE E&M
• TIE Loop Start
Digital:
• DTI: number given in terms of links, each provides 24 trunks under the North American
standard
• PRI: number given in terms of links, each provides 23B+D under the North American
standard
• European varieties of PRI, each provides 30B+D: VNS, DASS, DPNSS, QSIG, ETSI PRI
DID
H.323 Virtual Trunk
An IP Peer H.323 Virtual Trunk identified with a trunk route that is not associated with a physical
hardware card.
SIP Virtual Trunk
A Session Initiation Protocol (SIP) Virtual Trunk identified with a trunk route that is not
associated with a physical hardware card.
Data
• Sync/Async CP
• Async Modem Pool
• Sync/Async Modem Pool
• Sync/Async Data
• Async Data Lines
RAN
The default value for AHT RAN is 30 seconds.

System capacities
Music
The default value for AHT MUSIC is 60 seconds.
Signaling Server
The following software components operate on the Signaling Server:
• H.323 Gateway (Virtual Trunk)
• SIP Gateway (Virtual Trunk)
• Network Connection Service (NCS)
• CS 1000 Element Manager Web Server
• Application Server
• Avaya Unified Communication Manager (Avaya UCM)
Signaling Server software elements can coexist on one Signaling Server or reside individually
on separate Signaling Servers, depending on traffic and redundancy requirements for each
element. For any Co-resident Signaling Server software element combination the maximum
call rate supported is 10K cph.
A Signaling Server can also function as an application server for the Personal Directory, Callers
List, Redial List, and Unicode Name Directory applications and Password administration. See
Application server for Personal Directory, Callers List, Redial List, and Unicode Name
Directory on page 246.
Table 43: Elements in Signaling Server on page 234 describes the function and engineering
requirements of each element.
Table 43: Elements in Signaling Server
Element Function and engineering requirements

Terminal Proxy • The TPS handles initial signaling exchanges between an IP Phone
Server (TPS) and the Signaling Server.
• The TPS supports a maximum of 5000 IP Phones on each Signaling
Server.

Signaling Server
• The TPS manages the firmware for the IP Phones that are registered
to it. Accordingly, the TPS also manages the updating of the firmware
for those IP Phones.
• The redundancy of TPS is N+1. Therefore, you can provide one extra
Signaling Server to cover TPS functions from N other servers.
H.323 Gateway • The IP Peer H.323 Gateway trunk, or H.323 Virtual Trunk, provides
(Virtual Trunk) the function of a trunk route without a physical presence in the
hardware. The H.323 Gateway supports direct, end-to-end voice
paths using Virtual Trunks.
• The H.323 Signaling software (Virtual Trunk) provides the industry-
standard H.323 signaling interface to H.323 Gateways. It supports
both en bloc and overlap signaling. This software uses an H.323
Gatekeeper to resolve addressing for systems at different sites.
• The H.323 Gateway supports up to 1200 H.323 Virtual Trunks per
Signaling Server, assuming a combination of incoming and outgoing
H.323 calls (see Maximum number of SIP and H.323 Virtual
Trunks on page 245). Beyond that, a second Signaling Server is
required.
• The redundancy mode of the H.323 Gateway is 2 × N. Two H.323
Gateways handling the same route can provide redundancy for each
other, but not for other routes.
SIP Gateway • The SIP Gateway trunk, or SIP Virtual Trunk, provides a direct media
(Virtual Trunk) path between users in the CS 1000E domain and users in the SIP
domain.
• The SIP trunking software functions as: – a SIP User Agent – a
signaling gateway for all IP Phones
• The SIP Gateway supports a maximum of 3700 SIP Virtual Trunks
on CP DC and COTS2, and a maximum of 1800 SIP Virtual Trunks
on CP PM and COTS1 (see Maximum number of SIP and H.323
Virtual Trunks on page 245).
• The redundancy mode of the SIP Gateway is 2 × N. Two SIP
Gateways handling the same route can provide redundancy for each
other, but not for other routes.
SIP Line Gateway • The SLG fully integrates Session Initiation Protocol (SIP) endpoints
(SLG) in the Communication Server 1000 system and extends the
Communication Server 1000 features to SIP clients.
• The Call Server requires Package 417 (SIPL)
• The maximum SIPL users for each SLG is 3700 on CP DC, COTS2,
and Common Server. The maximum SIPL users for each SLG is 1800
on CP PM and COTS1. The maximum SIPL users for a
Communication Server 1000E Call Server is 11 250. In a pure IP
system, the maximum SIPL users is 20 000.

System capacities
• You configure SIPL users as SIPL UEXT (SIPN and SIP3). SIPL
users require two TNs from the Call Server, one for line TN (SIP
UEXT), and one for the SIPL VTRK. There must be a 1 to 1 ratio
between SIPL UEXT and SIPL VTRK TN.
• SIPL redundancy can be a leader and follower configuration for a
SLG node. Both Signaling Servers share the same node IP, however
SIPL clients only register on the SLG node leader. The two Signaling
Servers do not load share.
Network Routing • The NRS has three components: – H.323 Gatekeeper – SIP Redirect
Service (NRS) Server – SIP Proxy Server – Network Connection Service (NCS)
• The NRS must reside on the Leader Signaling Server
• For NRS redundancy, there are two modes:
- Active-Active mode for SIP Redirect and SIP Proxy provides load
balancing across two NRS servers. You must appropriately
engineer Active-Active mode to carry the redundant load in the case
of an NRS server failure.
- Primary-Secondary mode uses the Primary NRS server to handle
the total call rate from all the registered endpoints. If the Primary
NRS fails, the endpoints register to the Secondary NRS server to
handle the calls.
• The Primary and Secondary NRS Servers must be matched pairs.
Unmatched vendor NRS Servers are not supported. You must use
matched software configurations and engineering on each server for
optimal performance.
• For NRS failsafe, you must identify a Gateway Server as the NRS
failsafe.
• You can configure a Server as either Primary, Secondary, or Failsafe.
You cannot combine multiple roles on one Server.
• The NRS software limit for the total number of endpoints is 5000. An
exception is SIP Proxy mode with SIP TCP transport, where the
endpoints limit is 1000.
• The total number of routing entries is 50 000.
• The redundancy of the NRS is in a mode of 2 × N.
• H.323 • All systems in the network register to the H.323 Gatekeeper, which
Gatekeeper provides telephone number to IP address resolution.
• The capacity of the H.323 Gatekeeper is limited by the endpoints it
serves and the number of entries at each endpoint.

Signaling Server
• Potential hardware limits are the Signaling Server processing power

and memory limits.
• Since the Gatekeeper is a network resource, its capacity is a function
of the network configuration and network traffic (IP calls). Some basic
network information is required to engineer a Gatekeeper.
• SIP Redirect • The SIP Redirect Server provides telephone number to IP address
Server resolution. It uses a Gateway Location Service to match a fully
qualified telephone number with a range of Directory Numbers (DN)
and uses a SIP gateway to access that range of DNs.
• The SIP Redirect Server logically routes (directly or indirectly) SIP
requests to the proper destination.
• The SIP Redirect Server receives requests, but does not pass the
requests to another server. The SIP Redirect Server sends a
response back to the SIP endpoint, indicating the IP address of the
called user. The caller can directly contact the called party because
the response included the address of the called user.
• SIP Proxy • The SIP Proxy acts as both a server and a client. The SIP Proxy
Server (SPS) receives requests, determines where to send the requests, and acts
as a client for the SIP endpoints to pass requests to another server.
• Network • The NCS provides an interface to the TPS, enabling the TPS to query
Connection the NRS using the UNIStim protocol. The NCS is required to support
Service (NCS) the Avaya MG 1000B, Virtual Office, and Geographic Redundancy
features.
CS 1000 Element • Has a negligible impact on capacity and can reside with any other
Manager Web element.
Server
Application Server • The Application Server for the Personal Directory, Callers List, Redial
List, and Unicode Name Directory feature runs on the Signaling
Server.
• Only one database can exist in the network, and redundancy is not
supported.
• The database can coexist with the other software applications on a
Signaling Server. However, if the number of IP users exceeds the
following PD and UND limits, the database must be stored on a
dedicated Signaling Server.
- CP PM: PD limit of 2000 IP users, UND limit of 2000 IP users
- COTS1 (HP DL320-G4 or IBM x306m): PD limit of 3000 IP users,
UND limit of 3000 IP users.
- COTS2 (Dell R300 or IBM x3350): PD limit of 5000 IP users, UND
limit of 5000 IP users.

System capacities
- Common Server (HP DL360-G7): PD limit of 5000 IP users, UND

limit of 5000 IP users.
• The maximum number of Unicode names a dedicated server can
service is 50 000.
• The Application Server cannot be run on a Signaling Server at a
branch office.
• For more information about Personal Directory, Callers List, Redial
List, and Unicode Name Directory, see Avaya Signaling Server IP
Line Applications Fundamentals, NN43001-130.
The feasibility of combining the TPS, H.323 Gateway, SIP Gateway, and NRS on a Signaling
Server is determined by traffic associated with each element and the required redundancy
of each function.
Signaling Server capacity limits

The following tables contain information about Signaling Server capacity. In these tables, the
term dedicated Signaling Server means there is one Signaling Server application on a server.
The term non-dedicated Signaling Server means there is more than one Signaling Server
application on a server.
Table 44: Dedicated Signaling Server limits (one SS application per server)
CP PM COTS1 COTS2 Common CP DC

(HP (Dell Server
DL320- R300, (HP
G4, IBM IBM DL360-
x306m) x3350) G7)
UNIStim Phones per TPS 5000 5000 5000 5000 5000
Calls per hour (cph) per TPS 40 000 60 000 80 000 80 000 80 000
UNIStim Phone registration 5000 5000 5000 5000 5000
timing per TPS (5 min)
Personal Directory users 15 000 22 500 40 000 40 000 25 000
Personal Directory cph 60 000 90 000 180 000 180 000 90 000
H323 trunks per GW 1200 1200 1200 1200 1200
H323 cph per GW 40 000 60 000 80 000 80 000 60 000
SIP trunks per SIP Signaling GW 1800 1800 3700 3700 3700
(includes ELC users)
SIP cph per SIP Signaling GW 40 000 60 000 120 000 120 000 120 000


(HP (Dell Server
DL320- R300, (HP
G4, IBM IBM DL360-
x306m) x3350) G7)
GW endpoints per NRS (UDP) - 5000 5000 6000 6000 5000
redirect or proxy
GW endpoints per NRS (TCP, 1000 1000 1000 1000 1000
TCP/TLS )- redirect or proxy
NRE per NRS (UDP, TCP, TCP/ 50 000 50 000 300 000 300 000 50 000
TLS)
H323 cph per NRS (UDP, TCP) 200 000 300 000 500 000 500 000 300 000
SIP Redirect cph per NRS (UDP) 100 000 200 000 500 000 500 000 200 000
SIP Redirect cph per NRS (TCP, 100 000 200 000 300 000 300 000 200 000
TCP/TLS)
SIP Proxy cph per NRS (UDP, 50 000 100 000 200 000 200 000 100 000
TCP, TCP/TLS)
OCS Clients/TR87 5000 5000 5000 5000 5000
SIPLine/SIP DECT per SLG 1800 1800 3700 3700 3700
SIPLine/SIP DECT cph per SLG 15 000 25 000 60 000 60 000 60 000
CS 1000 SIP Trunk Bridge cph N/A N/A 15 000 15 000 8000
with Media Anchoring
(simultaneous conversations)
SIP Trunk signaling capacity with N/A N/A 1000 1000 1000
Media Anchoring
CS 1000 SIP Trunk Bridge cph N/A N/A 75 000 75 000 40 000
without Media Anchoring
SIP Trunk signaling capacity N/A N/A 5000 5000 5000
without Media Anchoring
MAS sessions G711 N/A N/A 800 IBM 800 240
700 DELL
MAS sessions G722 N/A N/A 445 IBM 445 133
390 DELL
MAS Sessions G729 N/A N/A 411 IBM 411 123
360 Dell
MAS Sessions G711 + SRTP N/A N/A 688 IBM 688 206
602 Dell
360 Dell

System capacities

(HP (Dell Server
DL320- R300, (HP
G4, IBM IBM DL360-
x306m) x3350) G7)
334 Dell
MAS Session Call Rate (cph) N/A N/A 18,000 18,000 6,000
UCM number of elements 1000 1000 5000 5000 1000
Media Server Controller (MSC) 40 000 60 000 120 000 120 000 80 000
cph
MSC total sessions * 1800 1800 4000 4000 4000
MSC IPConf sessions 1920 1920 1920 1920 1920
MSC IPMusic sessions 1000 1000 4000 4000 1000 if 2
GB
4000 if 4
GB
MSC IPRan sessions 1000 1000 4000 4000 1000 if 2
GB
4000 if 4
GB
MSC IPTone sessions 1000 1000 4000 4000 1000 if 2
GB
4000 if 4
GB
MSC IPAttn sessions 256 256 256 256 256
* Note: MSC = MSC = MSC = MSC = MSC =
(IPConf + (IPConf (IPConf + (IPConf + (IPConf +
IPRan + + IPRan IPRan + IPRan + IPRan +
IPTone + + IPTone IPTone + IPTone + IPTone +
IPMusic + + IPMusic + IPMusic + IPMusic
IPAttn) <= IPMusic IPAttn) <= IPAttn) <= + IPAttn)
1800 + IPAttn) 4000 4000 <= 4000
<= 1800
Table 45: Non-dedicated Signaling Server limits (multiple SS applications per server)

(HP (Dell Server
DL320- R300, (HP
G4, IBM IBM DL360-
x306m) x3350) G7)
* UNIStim Phones 1500 2000 3000 3000 2000


(HP (Dell Server
DL320- R300, (HP
G4, IBM IBM DL360-
x306m) x3350) G7)
Personal Directory users 1500 2000 3000 3000 2000
* SIP Line Phones 800 1000 1200 1200 1000
* Virtual Trunks (H323 ) 800 1000 1200 1200 1000
* Virtual Trunks (SIP ) 800 1000 1200 1200 1000
UCM number of elements 100 1000 2000 2000 1000
Service endpoints per NRS 100 100 100 100 100
Network Routing Entries (NRE) 1000 1000 1000 1000 1000
Media Server Controller (MSC) 800 1000 1000 1000 1000
IPConf sessions
MSC IPMusic sessions 800 1000 1000 1000 1000
MSC IPRan sessions 800 1000 1000 1000 1000
MSC IPTone sessions 800 1000 1000 1000 1000
MSC total sessions ** 800 1000 1200 1200 1000
Calls per hour (Sum of all 15 000 20 000 30 000 30 000 20 000
applications) sum of sum of sum of sum of sum of
TPS, TPS, TPS, TPS, TPS,
SipLine, SipLine, SipLine, SipLine, SipLine,
Vtrk, NRS Vtrk, Vtrk, NRS Vtrk, NRS Vtrk, NRS
+ MSC NRS + + MSC + MSC + MSC
MSC
MAS N/A N/A N/A N/A N/A
*Note: 1500 IP 2000 IP 3000 IP 3000 IP 3000 IP
users users users users users
where where where where where
(UNIStim (UNISti (UNIStim (UNIStim (UNIStim
+ SipLine m+ + SipLine + SipLine + SipLine
<= 1500) SipLine <= 3000) <= 3000) <= 3000)
and <= 2000) and and and
(SipLine and (SipLine (SipLine (SipLine
+ Vtrk + (SipLine + Vtrk + + Vtrk + + Vtrk +
ELC <= + Vtrk + ELC <= ELC <= ELC <=
800) and ELC <= 2000) 2000) 1000)
(Vtrk + 1000) and (Vtrk and (Vtrk and (Vtrk
MSC <= and + MSC <= + MSC <= + MSC <=
800) (Vtrk + 2000) 2000) 1000)

System capacities

(HP (Dell Server
DL320- R300, (HP
G4, IBM IBM DL360-
x306m) x3350) G7)
MSC <=
1000)
** Note: MSC = MSC = MSC = MSC = MSC =
(IPConf + (IPConf (IPConf + (IPConf + (IPConf +
IPRan + + IPRan IPRan + IPRan + IPRan +
IPTone + + IPTone IPTone + IPTone + IPTone +
IPMusic + + IPMusic + IPMusic + IPMusic +
IPAttn) <= IPMusic IPAttn) <= IPAttn) <= IPAttn) <=
800 + IPAttn) 1200 1200 1000
<= 1000
Table 46: CS 1000E Co-resident Call Server and Signaling Server limits
CP MG CP PM COTS2 Common CP DC
128 (Dell Server
R300, (HP
IBM DL360
x3350) G7)
ACD Agents (IP agents, IP 200 200 200 200 200
trunks)
* UNIStim Phones 700 1000 1000 1000 1000
Personal Directory users 700 1000 1000 1000 1000
* SIP Line Phones 400 400 1000 1000 400
* Virtual Trunks (H323 and/or 400 400 400 400 400
SIP)
TDM 800 128 128 128 128
Branch Branch Branch Branch
Office Office Office Office
800 stand 800 stand 800 stand 800 stand
alone alone alone alone
PRI Spans 16 16 16 16 16
UCM Elements 100 100 100 100 100
Media Gateways (IPMG) 5 5 5 5 5
Service/GW endpoints on NRS 5 5 5 5 5
NRE on NRS 20 20 20 20 20
OCS TR87 700 1000 1000 1000 1000

CP MG CP PM COTS2 Common CP DC
128 (Dell Server
R300, (HP
IBM DL360
x3350) G7)
Media Server Controller (MSC) 400 400 400 400 400
IPConf sessions
MSC IPMusic sessions 400 400 400 400 400
MSC IPRan sessions 400 400 400 400 400
MSC IPTone sessions 400 400 400 400 400
MSC total sessions ** 400 400 400 400 400
Calls per hour 8 000 10 000 20 000 20 000 15 000
sum of sum of sum of sum of sum of
CS + CS + CS + CS + CS +
NRS + NRS + NRS + NRS + NRS +
MSC MSC MSC MSC MSC
* Note: (UNISti (UNIStim (UNIStim (UNIStim (UNIStim
m + SipN + SipN + + SipN + + SipN + + SipN +
+ Sip3 Sip3 <= Sip3 <= Sip3 <= Sip3 <=
<= 700 1000 sets 1000 sets 1000 sets 1000 sets
sets and AND AND AND AND
TDM <= TDM <= TDM <= TDM <= TDM <=
800 and 800 and 800 and 800 and 800 and
(MSC + (MSC + (MSC + (MSC + (MSC +
VTRK + VTRK + VTRK + VTRK + VTRK +
ELC ELC ELC ELC ELC
<=400) <=400) <=400) <=400) <=400)
** Note: MSC = MSC = MSC = MSC = MSC =
(IPConf (IPConf + (IPConf + (IPConf + (IPConf +
+ IPRan IPRan + IPRan + IPRan + IPRan +
+ IPTone IPTone + IPTone + IPTone + IPTone +
+ IPMusic + IPMusic + IPMusic + IPMusic +
IPMusic IPAttn) <= IPAttn) <= IPAttn) <= IPAttn) <=
+ IPAttn) 400 400 400 400
<= 400
Table 47: MG 1000B Co-resident Call Server and Signaling Server limits
CP MG 32 CP MG 128 CP PM CP DC
CoRes CoRes
ACD Agents (IP agents, IP trunks) 20 200 200 200
UniStim sets * 100 400 400 400

System capacities
CoRes CoRes
PD users 100 400 400 400
Sip Line sets * 0 0 0 0
vtrks (H323 and/or SIP) * 400 400 400 400
TDM 32 128 128 128
PRI Spans 1 16 16 16
UCM Elements N/A N/A N/A N/A
Media Gateways (IPMG) ** 1 5 5 5
HD PRI GW 0 2 2 2
NRS N/A N/A N/A N/A
Media Server Controller IPConf 10 20 20 20
sessions
MSC IPMusic sessions 30 120 120 120
MSC IPRan sessions 30 120 120 120
MSC IPTone sessions 10 20 20 20
MSC IPAttn sessions 16 64 64 64
MSC total sessions *** 100 350 350 350
Calls per hour 8,000 sum 8,000 sum 10,000 sum 15,000 sum
of CS + of CS + of CS + of CS +
MSC MSC MSC MSC
* Note: (UniStim + (UniStim + (UniStim + (UniStim +
SipLine SipLine <= SipLine <= SipLine <=
<= 100 400 sets 400 sets 400 sets
sets and and TDM and TDM and TDM
TDM <= <= 128 and <= 128 and <= 128 and
32 and (MSC + (MSC + (MSC +
(MSC + VTRK + VTRK + VTRK +
VTRK + ELC ELC ELC
ELC <=400) <=400) <=400)
<=400)
** Note: single 4 Media Media Media
slot Gateway + Gateway + Gateway +
chassis HD GW <= HD GW <= HD GW <=
5 5 5
*** Note: MSC = MSC = MSC = MSC =
(IPConf + (IPConf + (IPConf + (IPConf +
IPRan + IPRan + IPRan + IPRan +
IPTone + IPTone + IPTone + IPTone +

Maximum number of SIP and H.323 Virtual Trunks
CoRes CoRes
IPMusic + IPMusic + IPMusic + IPMusic +
IPAttn) <= IPAttn) <= IPAttn) <= IPAttn) <=
100 350 350 350
Maximum number of SIP and H.323 Virtual Trunks

The maximum number of SIP and H.323 channels available on each Signaling Server depends
on the number of available File Descriptors (FD) for Virtual Trunks. The maximum number of
File Descriptors for Virtual Trunks is 1800 for CP PM or COTS1, and 3700 for CP DC, COTS2,
or Common Server.
• Each SIP call uses one FD.
• Each incoming H.323 call uses two FD.
• Each outgoing H.323 call uses one FD.
When no more File Descriptors are available (available FD = 0), new channels added on the
Call Server cannot register on the Signaling Server.
Each CP PM or COTS1 Signaling Server can support up to 1800 Virtual Trunks. Each CP DC,
COTS2, or Common Server Signaling Server can support up to 3700 Virtual Trunks. The
maximum number of SIP and H.323 trunks depends on traffic patterns, both the split between
SIP and H.323 calls and the split between incoming and outgoing H.323 calls. Table 48:
Maximum number of Virtual Trunks, per Signaling Server on page 245 gives examples of the
maximum number of Virtual Trunks supported.
Table 48: Maximum number of Virtual Trunks, per Signaling Server
H.323* Total Virtual

SIP Incoming Outgoing Total H.323 Trunks
3700 0 0 0 3700
0 600 600 1200 1200
0 900 0 900 900
600 0 1200 1200 1800
600 300 600 900 1500
*Assumes H.245 tunneling is enabled.
The formula to calculate the maximum number of Virtual Trunks is:

(Num_of_SIP × 1 FD) + (Num_of_Incoming_H323 × 2 FD) + (Num_of_Outgoing_H323 × 1
FD) <= Max_Num_of_FDs

System capacities
where Max_Num_of_FDs = 3700
Impact of H.245 tunneling

By default, H.245 tunneling is enabled. Unless there is a specific reason to disable tunneling,
such as for maintenance, it should always be enabled. When tunneling is off, the handling
capacity of the Signaling Server is reduced to a maximum of 900 H.323 Virtual Trunks.
Application server for Personal Directory, Callers List,

Redial List, and Unicode Name Directory
There is one Application server for the Personal Directory, Callers List, Redial List, and Unicode
Name Directory features within a Communication Server 1000 system. These applications
cannot be divided to run on separate Application servers.
• Personal Directory: Stores up to 100 entries per user of user names and DNs.
• Callers List: Stores up to 100 entries per user of caller ID information and most recent call
time.
• Redial List: Stores up to 20 entries per user of dialed DNs and received Call Party Name
Display with time and date.
The Unicode Name Directory feature is available on the Application server. The Personal
Directory, Callers List, and Redial List can operate without the Unicode Name Directory.
However, to operate the Unicode Name Directory you must configure Personal Directory,
Callers List, and Redial List. A dedicated PD/UND server can support 50 000 UND users.
If the system size is relatively small, in terms of number of users as well as calling rates, one
Signaling Server can serve both database and normal Signaling Server functions. The
Personal Directory, Callers List, and Redial List database can co-reside with other applications
(TPS, H.323/SIP Gateways, Element Manager). For more information about Co-resident limits,
see Table 58: Signaling Server algorithm constants on page 272. For larger systems, one
additional Signaling Server, on top of the normal requirement for handling signaling traffic, is
required for the Personal Directory, Callers List, and Redial List features.
There is no redundancy for the Signaling Server dedicated to the Personal Directory, Callers
List, Redial List, and Unicode Name Directory. If that Application Signaling Server fails, the
system loses those applications.

Software configuration capacities
Software configuration capacities

The tables inDesign parameters on page 199 provide maximum configuration capacities for
applicable system and feature parameters. A system may not be able to simultaneously
accommodate all of the maximum values listed because of system limitations on the real time,
memory, or traffic capacity.
IP Telephony node maximums

The maximum number of Voice Gateway Media Cards per node is 30. When more than 30
Voice Gateway Media Cards are needed on a single CS 1000E system, use multiple nodes.
The maximum number of Signaling Servers and Voice Gateway Media Cards combined within
a node is 35.
CS 1000E capacities
Since IP telephony consumes less processing than TDM, the total number of telephones that
a particular platform can support depends on the type of traffic as well as the physical capacity
and applications of a specific configuration.
Table 49: CS 1000E capacities summary on page 247 summarizes the capacities of CS 1000E
systems. Values in each cell indicate the total number of telephones that can be supported in
a particular configuration. These values are calculated from the point of view of call server
processing capacity, not from the point of view of physical card slot capacity.
Values in each cell are exclusive, not additive.
Table 49: CS 1000E capacities summary
Total number of telephones

Pure TDM (no Pure IP Pure IP (SIPLine) Mixed IP and
System trunking) (UNIStim) Access to PSTN TDM Access to
Access to PSTN
PSTN
CS 1000E (CP 8000 22 500 2x(SipN+Sip3) <= 8000* TDM
PIV) SA/HA 22 500 (UNIStim +
2x(SipN+Sip3)
<= 22 500)*

System capacities
Total number of telephones

Pure TDM (no Pure IP Pure IP (SIPLine) Mixed IP and
System trunking) (UNIStim) Access to PSTN TDM Access to
Access to PSTN
PSTN
CS 1000E (CP 8000 22 500 2x(SipN+Sip3) <= 8000* TDM
PM) SA/HA 22 500 (UNIStim +
2x(SipN+Sip3)
<= 22 500)*
CS 1000E (CP N/A 40 000 (PSTN 2x(SipN+Sip3) <= N/A
PM) SA/HA (IP through Vtrk) 40 000
only)
CS 1000E TDM 800 N/A N/A N/A
(CP PM, CP
MG 128)
CS 1000E (Co- 800 1000 (SipN+Sip3) <= 800* TDM
res CS and SS) 1000 (UNIStim + (SipN
(CP PM, +Sip3 <= 1000)**
COTS2,
Common
Server, CP DC)
CS 1000E (Co- 800 700 (SipN+Sip3) <= 800* TDM
res CS and SS) 700 (UNIStim + (SipN
(CP MG 128) +Sip3 <= 700)**
Values in each column reflect the total telephones for a configuration. These are absolute
limits for pure TDM and pure IP. For mixed TDM and IP, values are for typical configurations.
Applications and calling patterns impact call server capacity. Enterprise Configurator and
publications are used to calculate practical values preconfiguration. Values beyond these
limits must be engineered.
TPS requires Signaling Servers.
Mixed configuration assumes 8-15% digital trunking to PSTN and no applications.
* Number of IP and TDM phones with PSTN access is dependant on the number of PRI/
DTI/PRI2/DTI2 spans. This ties into loop consumption and must be calculated.
** The CS 1000E Co-res CS and SS system (SipN+Sip3) must always be <=1000. For
example, a Co-res CS and SS system can have 600 UNIStim telephones and 400 SIP Line
telephones.
Zone/IP Telephony Node Engineering

For information about Zone/IP Telephony Node Engineering, see Avaya Communication
Server 1000M and Meridian 1 Large System Planning and Engineering, NN43021-220.

Chapter 14: Resource calculations
Contents
Resource calculation parameters on page 250
Resource calculation equations on page 251
Total system traffic on page 253
System calls on page 253
Real time calculations on page 257
DSP/Media Card calculations on page 264
Virtual Trunk calculations on page 269
Signaling Server algorithm on page 271
Reducing imbalances (second round of algorithm calculations) on page 305
Illustrative engineering example on page 308
Introduction
This chapter describes the algorithms implemented by the Enterprise Configurator tool in order
to calculate the resources required by the system.
In many cases, the calculations require user inputs that are the result of pre-engineering
performed in accordance with the capacities and guidelines described in System capacities on
page 209 and Application engineering on page 323.
When a proposed new system is equipped with more ports than the initial configuration actually
uses, treat the two sets of input data like two separate configurations. Run each set of data
through the algorithm and then compare results. For a viable solution, both sets of calculation
results must be within the capacities of the proposed system.

Resource calculations
Resource calculation parameters

Table 50: Resource calculation parameters on page 250 describes the parameters you use
in resource calculations.
Table 50: Resource calculation parameters
Parameter Description Default value

TelephoneCCS Centi-Call Seconds (CCS) for each standard 5 CCS
telephone
NBTelephoneC CCS for each nonblocking telephone 18 CCS
CS
ACDCCS CCS for each Automatic Call Distribution (ACD) 33 CCS

telephone
TRKCCS CCS for each Time-Division Multiplexing (TDM) 28 CCS
trunk
VTRKCCS CCS for each Virtual trunk 28 CCS
CP1CSS CCS for each local CallPilot port 26 CCS
CP2CCS CCS for each network CallPilot port 26 CCS
APPLCCS CCS for each application port 26 CCS
Intraoffice ratio The portion of telephone to telephone calls, from 0.30
(RI) the total number of calls.
Tandem ratio The portion of trunk to trunk calls, from the total 0.05
(RT) number of calls.
Incoming ratio The portion of trunk to telephone calls, from the 0.40
(I) total number of calls.
Outgoing ratio The portion of telephone to trunk calls, from the 0.25 calculated on the
(O) total number of calls O = 1 - RI - RT - I The sum values for RI, RT, and I
of all four traffic ratios (RI, RT, I, O) must equal
1
AHTSS Average holding time (AHT) for telephone-to-
60 seconds
telephone calls
AHTTS AHT for trunk to telephone calls 150 seconds
AHTST AHT for telephone to trunk calls 150 seconds
AHTTT AHT for trunk to trunk calls 180 seconds
AHTAGT AHT for ACD agent calls 180 seconds
AHTCP AHT for CallPilot calls 40 seconds

Resource calculation equations
Parameter Description Default value

AHTMICB AHT for Integrated Conference Bridge calls 1800 seconds
AHTMIRAN AHT for Integrated Recorded Announcement
90 seconds
calls
AHTMIPCD AHT for Integrated Call Director calls 60 seconds
AHTMICA AHT for Integrated Call Announcement calls 180 seconds
AHTMIVS AHT for Integrated Voice Services calls 90 seconds
rcon Conference loop ratio (number of conference 0.07
loops / total number of loops)
Resource calculation equations

Table 51: Resource calculation equations on page 251 describes the equations you use in
resource calculations. Evaluate the equations in the order shown, as other calculations require
the results of the previous calculations.
Table 51: Resource calculation equations
Name Description Equation

LTDM Total TDM telephone CCS, LTDM = ((number of digital telephones
including analog, digital and line- + number of analog telephones +
side T1/E1 ports number of line-side T1/E1 ports) ×
TelephoneCCS) + (number of
nonblocking telephones ×
NBTelephoneCCS)
LIP Total UNIStim IP Phone CCS, LIP = (number of UNTIStim IP Phones
including wireless IP telephones - number of IP ACD agents) ×
TelephoneCCS
LACD Total TDM ACD agent CCS LACD = (number of TDM ACD agents)
× ACD CCS
LACDIP Total IP ACD agent CCS LACDIP = (number of UNIStim ACD
agents) × ACD CCS
LDECT Total Digital Enhanced Cordless LDECT = (number of DECT telephones)
Telecommunications (DECT) × TelephoneCCS
telephone CCS, excluding SIP-
DECT
LIPW Total IP Wireless 802.11 LIPW = (number of Wireless 802.11
telephone CCS telephones) × TelephoneCCS


LSIPL Total SIP Line telephone CCS, LSIPL = (number of SIPN telephones +
including SIP-DECT number of SIP3 telephones) ×
TelephoneCCS
ACDadj ACD CCS adjustment for TDM ACDadj = (number of TDM ACD agents
agents (see paragraph below × NBTelephoneCCS)
table)
LCCS Total line CCS. The sum of all LCCS = (LTDM + LIP + LACD + LACDIP +
telephone CCS LDECT + LIPW + LSIPL) - ACD adj
TTDM Total TDM trunk CCS, including TTDM = (number of analog trunks +
analog and digital trunks number of digital trunks) × TRKCCS
HVTCCS Total H323 trunk CCS HVTCCS = (number of H323 trunks) ×
TRKCCS
SVTCCS Total SIP trunk CCS SVTCCS = (number of SIP trunks) ×
TRKCCS
VTCCS Total Virtual Trunk CCS VTCCS = HVTCCS + SVTCCS
TTCCS Total trunk CCS TTCCS = TTDM + VTCCS
VH Percentage of H323 trunk CCS VH = HVTCCS ÷ VTCCS
from the total Virtual Trunk CCS
VS Percentage of SIP trunk CCS VS = SVTCCS ÷ VTCCS
from the total Virtual Trunk CCS
V Percentage of Virtual Trunk CCS V = VTCCS ÷ TTCCS
from the total trunk CCS
PU Ratio of UNIStim telephone CCS PU = (LIP + LACDIP) ÷ LCCS
to total telephone CCS
PS Ratio of SIP Line telephone CCS PS = LSIPL ÷ LCCS
to total telephone CCS
PIP Ratio of IP telephone CCS to total PIP = (LIP + LACDIP + LSIPL) ÷ LCCS = PU
telephone CCS + PS
WAHT Weighted average holding time WAHT = (RI × AHTSS) + (RT × AHTTT)
(WAHT) in seconds + (I × AHT TS) + (O × AHT ST)
Total_telephon Total number of telephones on Total_telephones = number of TDM
es the system telephones + number of UNIStim
telephones + number of SIPN
telephones + number of SIP3
telephones + number of MDECT
telelphones + number of SIP-DECT
telephones + number of BRI
telephones + number of MobileX
users + number of MC3100 users

Total system traffic

rDTP Ratio of converged desktop rDTP = number of telephones with
telephones to total number of converged desktop ÷
telephones Total_telephones
VDCCS Converged desktop CCS VDCCS = LCCS × rDTP
MOP Percentage of Microsoft MOP = number of telephones with
Converged Office users Microsoft Converged Office ÷
Total_telephones
IPSECP IP security usage If any IP security features are enabled
IPSECP = 1, otherwise IPSECP = 0
CP1 Local CallPilot CCS CP1 = number of local CallPilot ports
× CP1CCS
CP2 Network CallPilot CCS CP2 = number of network CallPilot
ports × CP2CCS
MC3100_P Percentage of MC3100 users MC3100_P = MC3100_users ÷
Total_telephones
MobileX_P Percentage of MobileX users MobileX_P = MobileX_users ÷
Total_telephones
The ACD traffic for TDM terminations is integral in L TDM for all systems. Large systems can
contain both standard and nonblocking telephones. You must enter ACD agents in the
nonblocking telephone count (for line card provisioning), therefore adjust the CSS using the
nonblocking CCS rate.
LIP is correct for IP ACD agents. L IP does not require a CSS adjustment because all IP Phones
are nonblocking.
Total system traffic

System traffic is the sum of traffic from the sources. The total system CCS is the sum of
telephone and trunk CCS.
TCCS = LCCS + TTCCS
System calls
The total number of calls the system must be engineered to handle is given by:
TCALL = 0.5 × TCCS × 100 ÷ WAHT

Traffic equations and penetration factors

Total system calls comprise four different types of traffic:
1. Telephone-to-telephone (Intraoffice calls (CSS) on page 254)
2. Trunk-to-trunk (Tandem calls (CTT) on page 255)
3. Telephone-to-trunk (Originating/outgoing calls (CST) on page 255)
4. Trunk-to-telephone (Terminating/incoming calls (CTS) on page 256)
1. Intraoffice calls (CSS)
CSS = Total calls (TCALL) × Intraoffice ratio (RI)
This parcel can be further broken down to six types:
a. Intraoffice UNIStim IP to UNIStim IP calls (UIPtoUIP)
C2IP = CSS × PU × PU (require no DSP, no VT)
P_UIPtoUIP = C2IP ÷ TCALL P_UIPtoUIP is the penetration factor for the
intraoffice UNIStim IP to UNIStim IP calls
b. Intraoffice UNIStim IP to TDM telephone calls (UIPtoL)
C1IP= CSS × 2 × PU × (1 – PIP) (require DSP, no VT)
P_UIPtoL = C 1IP ÷ TCALL P_UIPtoL is the penetration factor for the
intraoffice UNIStim IP to TDM telephone calls
c. Intraoffice TDM telephone to TDM telephone calls (LtoL)
CNoIP = CSS × (1 – PIP)2 (require no DSP, no VT)
P_LtoL = C NoIP ÷ TCALL P_LtoL is the penetration factor for the intraoffice
TDM to TDM calls
d. Intraoffice SIP Line to SIP Line calls (SIPtoSIP)
C2sip = CSS × PS2 (require no DSP, no VT)
P_SIPtoSIP = C2sip ÷ TCALL P_SIPtoSIP is the penetration factor for the
intraoffice SIP Line to SIP Line calls
e. Intraoffice SIP Line to UNIStim IP calls (SIPtoUIP)
C2sipuip = CSS × 2 × PS × PU (require no DSP, no VT)
P_SIPtoUIP = C2sipuip ÷ TCALL P_SIPtoUIP is the penetration factor for
the intraoffice SIP Line to UNIStim IP calls
f. Intraoffice SIP Line to TDM calls (SIPtoL)
C1sip = CSS × 2 × PS × (1 - PIP) (require DSP, no VT)

Traffic equations and penetration factors
P_SIPtoL = C 1sip ÷ TCALL P_SIPtoL is the penetration factor for the

intraoffice SIP Line to TDM calls
2. Tandem calls (CTT)
CTT = Total calls × Tandem ratio = T CALL × RT
The tandem calls can be further broken down into:
a. Tandem VT to TDM trunk calls (VTtoTr)
CT1VT = 2 × CTT × V × (1 – V) (require DSP and VT)
P_VTtoTr = CT1VT ÷ TCALL P_VTtoTr is the penetration factor for the
tandem VT to TDM trunk calls
b. Tandem TDM trunk to TDM trunk calls (TrtoTr)
CT2NoVT = CTT × (1 – V)2 (require no DSP, no VT)
P_TrtoTr = CT2NoVT ÷ TCALL P_TrtoTr is the penetration factor for the
tandem TDM trunk to TDM trunk calls
c. Tandem VT (H.323) to VT (SIP) calls (VhtoVs)
CT2HS= CTT × V2 × VH × VS × 2 × 2 (require VT)
where VH is the fraction of H.323 trunks to total VTs, and VS is the fraction
of SIP trunks to total VTs.
If there is only one type of VT (either VH or VS = 0), the connection is
handled at the Network Routing Service and no calls are offered to the
Call Server. In this case, P_VhtoVs = 0.
P_VhtoVs = CT2HS ÷ TCALL P_VhtoVs is the penetration factor for the
tandem VT (H.323) to VT (SIP) calls
3. Originating/outgoing calls (CST)
CST = Total calls × Outgoing ratio = T CALL × O
Originating/outgoing calls can be further broken down into:
a. UNIStim IP to VT calls (UIPtoVT)
CSTIV = CST × PU × V (require no DSP, no VT)
P_UIPtoVT = CSTIV ÷ TCALL P_UIPtoVT is the penetration factor for the
outgoing UNIStim IP to VT calls
b. UNIStim IP to TDM trunk calls (UIPtoTr)
CSTID = CST × PU × (1 – V) (require DSP, no VT)
P_UIPtoTr = CSTID ÷ TCALL P_UIPtoTr is the penetration factor for the
outgoing UNIStim IP to TDM trunk calls
c. TDM telephone to VT calls (LtoVT)
CSTDV = CST × (1 – PIP) × V (require DSP, VT)

P_LtoVT = CSTDV÷ TCALL P_LtoVT is the penetration factor for the

outgoing TDM telephone to VT calls
d. TDM telephone to TDM trunk calls (LtoTr) CSTDD = CST × (1 – PIP) × (1
– V) (require no DSP, no VT)
P_LtoTr = CSTDD ÷ TCALL P_LtoTr is the penetration factor for the
outgoing TDM telephone to TDM trunk calls
e. SIP Line to VT calls (SIPtoVT) C STSV = CST × PS × V (require no DSP,
VT)
P_SIPtoVT = CSTSV ÷ TCALL P_SIPtoVT is the penetration factor for the
outgoing SIP Line to VT calls
f. SIP Line to TDM trunk calls (SIPtoTr) C STSD = CST × PS × (1 - V) (require
DSP, no VT)
P_SIPtoTr = CSTSD ÷ TCALL P_SIPtoTr is the penetration factor for the
outgoing SIP Line to TDM trunk calls
4. Terminating/incoming calls (CTS)
CTS = Total calls × Incoming ratio = T CALL × I
Terminating/incoming calls can be further broken down into:
a. VT to TDM telephone calls (VTtoL)
CTSVD = CTS × V × (1 – PIP) (require DSP, VT)
P_VTtoL = C TSVD ÷ TCALL P_VTtoL is the penetration factor for the
incoming VT to TDM telephone calls
b. VT to UNIStim IP telephone calls (VTtoUIP)
CTSVI = CTS × V × (PU) (require no DSP, VT)
P_VTtoUIP = CTSVI ÷ TCALL P_VTtoUIP is the penetration factor for the
incoming VT to UNIStim IP telephone calls
c. TDM trunk to UNIStim IP telephone calls (TrtoUIP)
CTSDI = CTS × (1 – V) × (PU) (require DSP, no VT)
P_TrtoUIP = CTSDI ÷ TCALL P_TrtoUIP is the penetration factor for the
incoming TDM trunk to UNIStim IP telephone calls
d. TDM trunk to TDM telephone calls (TrtoL)
CTSDD = CTS × (1 – V) × (1 – PIP) (require no DSP, no VT)
P_TrtoL = C TSDD ÷ TCALL P_TrtoL is the penetration factor for the
incoming TDM trunk to TDM telephone calls
e. VT to SIP Line calls (VTtoSIP)
CTSVS = CTS × V × PS (require DSP, no VT)

Resource use equations
P_VTtoSIP = CTSVS ÷ TCALL P_VTtoSIP is the penetration factor for the

incoming VT to SIP Line calls
f. TDM trunk to SIP Line calls (TrtoSIP)
CTSDS = CTS × (1 - V) × PS (require no DSP, no VT)
P_TrtoSIP = CTSDS ÷ TCALL P_TrtoSIP is the penetration factor for the
incoming TDM trunk to SIP Line calls
Resource use equations

The following equations, summing different types of traffic, are used to calculate the required
TPS and SLG resources.
• Calls involving at least one UNIStim IP Phone and therefore using TPS:
CIP = (2 × C2IP) + C1IP + CSTIV + CSTID + CTSVI + CTSDI + C2SIPUIP
• Calls that require at least one SIP Line Phone and therefor using SLG:
CSIP = (2 × C2SIP) + C1SIP + C2SIPUIP + CSTSV + CSTSD + CTSVS + CTSDS
Real time calculations

This section describes the following real time calculations:
• System EBC without applications on page 260
• Feature and applications EBCs on page 260
• Call Server utilization on page 262
• CPU real time conversion for upgrades on page 262
The real time required to process a basic telephone to basic telephone call is an Equivalent
Basic Call (EBC), which is the unit used to measure other, more complicated feature calls. The
basic call type varies for each system, and is based on the call requiring the least amount of
Call Server CPU. Every feature call can be converted to EBCs by using its real time factor
(RTF).
RTF = (Real time of a feature call in ms ÷ Real time of a basic call) - 1
There are a total of 21 major combinations of telephone and trunk types of calls in the system.
The real time factor of each call type is denoted by fi (i = 1 to 21). In addition, there are standard
real time factors for applications and features. Table 52: Real time factors on page 258
provides the real time factors.

Table 52: Real time factors
Type of call Real time Avaya CS Avaya CS

factor 1000E SA/HA 1000E Co-res
+ SLG
Intraoffice calls:
UNIStim IP telephone to UNIStim IP (f1) 0.0 4.90
telephone
UNIStim IP telephone to TDM (f2) 1.41 1.86
telephone
TDM telephone to TDM telephone (f3) 0.81 0.03
Tandem calls:
Virtual Trunk to TDM trunk (f4) 1.14 3.65
TDM trunk to TDM trunk (f5) 1.20 2.85
H.323 Virtual Trunk to SIP Virtual Trunk (f6) 1.09 4.45
Originating/outgoing calls:
UNIStim IP telephone to Virtual Trunk (f7) 1.20 5.18
UNIStim IP telephone to TDM trunk (f8) 1.16 4.96
TDM telephone to Virtual Trunk (f9) 2.44 3.95
TDM telephone to TDM trunk (f10) 1.25 4.36
Terminating/incoming calls:
Virtual Trunk to TDM telephone (f11) 1.72 2.86
Virtual Trunk to IP telephone (f12) 0.97 3.72
TDM trunk to UNIStim IP telephone (f13) 1.25 0.74
TDM trunk to TDM telephone (f14) 1.34 0.06
SIPL to SIP telephone (f15) 2.72 4.80
SIPL to UNIStim IP telephone (f16) 1.36 2.04
SIPL to TDM telephone (f17) 1.78 2.50
SIPL to Virtual Trunk (f18) 1.97 5.60
SIPL to TDM Trunk (f19) 2.25 2.14
Virtual Trunk to SIP telephone (f20) 2.17 5.97
TDM Trunk to SIPL (f21) 3.57 4.97
Application/feature calls:
ACD agent without Symposium (fACD) 0.13 0.13

Real time calculations
Type of call Real time Avaya CS Avaya CS

factor 1000E SA/HA 1000E Co-res
+ SLG
Symposium (fSYM) 5.70 5.70
CallPilot (fCP) 1.70 1.70
Avaya Integrated Conference Bridge (fMICB) 1.59 1.59
Avaya Integrated Recorded Announcer (fMIRAN) 0.63 0.63
Avaya Integrated Call Assistant (fMICA) 0.57 0.57
Avaya Hospitality Integrated Voice (fMIVS) 0.57 0.57
Service
Avaya Integrated Call Director (fMIPCD) 0.63 0.63
IP Recorded Announcer on Media (fIPRAN_MS) 1.2 1.2
Server
Media Services based tones (fIPTDS) 0.8 0.8
BRI ports (fBRI) 0.12 0.12
MDECT telephone (fDECT) 4.25 4.25
Intraoffice CDR (fICDR) 0.44 0.44
Incoming CDR (fCCDR) 0.32 0.32
Outgoing CDR (fOCDR) 0.32 0.32
Tandem CDR (fTAN) 0.44 0.44
CPND factor (fCPND) 0.20 0.20
Converged Desktop factor (fDTP) 2.33 2.33
Error term – minor feature overhead (fOVRH) 0.25 0.25
Microsoft Converged Office factor (fMO) 2.33 2.33
IP Security factor (fIPSEC) 0.33 0.33
MC3100 factor (fMC3100) 4.78 4.78
MobileX factor (fmobileX) 0.67 0.67
Extend Local Calls factor (fELC) 4.36 4.36
The real time factor adjusts for the fact that a feature call generally requires more real time to
process than a basic call. The impact on the system is a function of the frequency with which
the feature call appears during the busy hour. The penetration factor of a feature is the ratio
of that type of feature call to the overall system calls. See Traffic equations and penetration
factors on page 254 for the equations to calculate penetration factors for the 21 major call
types.

The real time factors and penetration factors are used to generate the real time multiplier
(RTM), which in turn is used to calculate the overall system EBC.
The real time multiplier is given by:
RTM = 1 + Error_term + (P_UIPtoUIP × f1) + (P_UIPtoL × f 2) + (P_LtoL × f 3) + (P_VTtoTr × f4)
+ (P_TrtoTr × f5) + (P_VhtoVs × f6) + (P_UIPtoVT × f7) + (P_UIPtoTr × f8) + (P_LtoVT × f9) +
(P_LtoTr × f10) + (P_VTtoL × f 11) + (P_VTtoUIP × f12) + (P_TrtoUIP × f13) + (P_TrtoL × f 14) +
(P_SIPtoSIP × f15) + (P_SIPtoUIP × f16) + (P_SIPtoL × f 17) + (P_SIPtoVT × f18) + (P_SIPtoTr
× f19) + (P_VTtoSIP × f20) + (P_TrtoSIP × f21)
The Error_term accounts for features such as call transfer, three-way conference, call-forward-
no-answer, and others that are hard to single out to calculate real time impact. The Error_term
is usually assigned the value 0.25.
System EBC without applications

System EBC = (Total system calls × real time Multiplier) SEBC = (TCALL × RTM)
Feature and applications EBCs

Table 53: Feature and applications EBC on page 260 lists the equations to calculate the EBC
impacts of individual applications and features. The total application and feature EBC impact,
which is included in the system real time EBC calculation, is the sum of these application and
feature EBCs.
Table 53: Feature and applications EBC
EBC feature or Calculation

application
ACD ACD agents without Symposium + ACD agents with
Symposium
where ACD agents without Symposium = (1 – % Symposium)
× fACD × (Number of IP ACD agents + number of TDM agents)
× ACD CCS × 100 ÷ AHT AGT
and ACD agents with Symposium is user input. (If unknown,
assume all ACD agent calls are with Symposium.)
Symposium % Symposium × fSYM × (Number of IP ACD agents + number
of TDM agents) × ACD CCS × 100 ÷ AHT AGT
CallPilot (CP1 + CP2) × 100 ÷ AHT CP × fCP
Internal CDR CSS × fICDR
Incoming CDR CTS × fCCDR

Feature and applications EBCs
EBC feature or Calculation

application
Outgoing CDR CST × fOCDR
Tandem CDR CTT × fTCDR
Integrated Conference Number of Integrated Conference Bridge ports × CCS × 100 ÷
Bridge AHTMICB × fMICB
Integrated Recorded Number of Integrated Recorded Announcer ports × CCS × 100
Announcer ÷ AHT MIRAN × fMIRAN
Integrated Call Director Number of Integrated Call Director ports × CCS × 100 ÷
AHTMIPCD × fMIPCD
Integrated Call Number of Integrated Call Announcer ports × CCS × 100 ÷
Announcer AHTMICA × fMICA
Hospitality Integrated Number of Hospitality Integrated Voice Services ports × CCS ×
Voice Services 100 ÷ AHT MIVS × fMIVS
IP_RAN (((IP RAN ports + IP MUS ports) × 26) × 100) ÷ 90) × f IPRAN
IP_TDS IP Tone Calls × f MSTDS
BRI # BRI ports × CCS × 100 ÷ AHT BRI × fBRI
MDECT LDECT × 100 ÷ WAHT × fDECT
CPND (C1IP + CNoIP + CTSVD + CTSDD) × fCPND
Converged Desktop (CD) (CSS × 0.1 + CTT + CST + CTS) × rDTP × fDTP
Microsoft Converged (CSS × 0.1 + CTT + CST + CTS) × mop × fMO
Office (MO)
IP Security (IPSEC) (Css + CTT + CTS) × P × ipsecp × fIPSEC
MC3100 (Css + CTT + CST + CTS) × MC3100_P × fMC3100 where
MC3100_P = MC3100_users / (MC3100_users + total number
of set and extensions)
MobileX (Css + CTT + CST + CTS) × MobileX_P × fMobileX where
MobileX_P = MobileX_users / (total number of set and
extensions)
Extend Local Calls (ELC) (Css × ELC_P × fELC where ELC_P = ELC_users / (total number
of telephones and extensions)
Feature and application EBC defines as: FAEBC = ACD_EBC + Symposium_EBC +

CallPilot_EBC + InternalCDR_EBC + IncomingCDR_EBC + OutgoingCDR_EBC +
TandemCDR_EBC + MICB_EBC + MIRAN_EBC + MIPCD_EBC + MICA_EBC + MIVS_EBC
+ BRI_EBC + MDECT_EBC + CPND_EBC + CD_EBC + MO_EBC + IPSEC_EBC +
MC3100_EBC + MobileX_EBC + IP_RAN_EBC + IP_TDS_EBC + ELC_EBC

Call Server utilization

Real Time Usage (RTU) is expressed as a percentage of the rated EBC capacity of the CPU.
RTU = (SEBC + FAEBC) ÷ Rated_EBC × 100 Where Rated_EBC value is from Table 42: Real
time capacity (EBC) by system on page 229.
CPU real time conversion for upgrades

When upgrading an existing switch, CPU engineering must provide a certain level of spare
capacity in order to ensure that the upgrade will be able to handle both the existing site and
the new additions. real time calculations must include the existing load as well as the new
load.
The CPU utilization data from a current traffic report TFS004 provides the existing load. The
existing load is then converted to the equivalent loading on the new (and presumably faster)
CPU. The final loading on the new processor is the sum of the usual real time calculations for
the new load and the converted existing load. It must be less than or equal to 100% of the
rated capacity for the new processor.
Use the following formula to convert the existing processor usage to the new processor
equivalent:
CRTU = (RTU/100) × [1 + (SWRC ÷ 100)] × CPTU
• CRTU = CPU loading from the existing switch converted to an equivalent load on the new
processor, in percent.
• RTU = Current CPU usage, in percent (from the TFS004 report of the existing switch).
• SWRC = Software release degradation factor, in percent. Since every new release is
enhanced with new features and capabilities, the processing power of the existing CPU
is degraded to some extent (typically 10-20%) by the newer release.
• CPTU = Capacity ratio of the existing CPU to the new CPU. The ratio is always less than
1 (unless the same CPU is used, in which case it is equal to 1).
If CRTU > CPTU, set CRTU = CPTU.
Since the capacity ratio is the maximum load the old CPU can offer to the new one, the
converted CPU load from the existing processor cannot be greater than the capacity ratio.
Table 54: Software release degradation factors (SWRC) on page 263 lists the software release
degradation factors for supported software upgrades.

Table 54: Software release degradation factors (SWRC)
From Degradation factor (%)

to CS 1000E Release 7.5
Release 18 310
Release 19 291
Release 20B 220
Release 21B 190
Release 22 149
Release 23 130
Release 23C 125
Release 24B 81
Release 25B 69
Succession Release 2 66
Succession Release 3 62
CS 1000 Release 4 55
CS 1000 Release 4.5 42
CS 1000 Release 5 23
Table 55: Ratio of existing processor capacity to new processor capacity (CPTU) on page 263
gives capacity ratio values for supported processor upgrades.
Table 55: Ratio of existing processor capacity to new processor capacity (CPTU)
From CPU type EBC Ratio

To CP PII To CP PIV To CP PM
CP PII 1.00 0.32 0.30
CP PIV – 1.00 0.667
CP PM – – 1.00

DSP/Media Card calculations

DSP resources are provided by Media Cards and MGC DSP daughterboards. The total DSP
requirement is the sum of DSP requirements for various functions, which are calculated
separately for each Media Gateway.
• DSP ports for Conference on page 265
• DSP ports for general traffic on page 266
• DSP ports for major applications on page 266
• Special treatment for nonblocking access to DSP ports on page 267
• Total Media Gateway DSP requirements on page 267
• Simplified Media Gateway DSP calculations on page 268
For reasons explained in the Traffic models on page 228section, the Erlang B model is used
to calculate DSP port requirements.
The DSP port requirement must be calculated in increments of 32. The Gateway Controller,
MC32, and MC32S provide DSPs in groups of 32. DSP calculations that refer to a Media Card
equal a bank of 32 DSP ports. The 32 DSP ports can be provided by a MC32, MC32S, or DSP
resources from a Gateway Controller. For example, an MGC card with 128 DSP ports is the
equivalent of 4 Media Cards.
Table 56: Erlang B and Poisson values, in 32-port increments on page 264 provides Erlang B
and Poisson values for P.01 Grade-of-Service (GoS) in 32-port increments. The DSP resource
required to handle the offered traffic is the number of ports corresponding to the first Erlang B
CCS capacity greater than the calculated traffic value. The Poisson values are used to
calculate Virtual Trunk requirements (see Virtual Trunk calculations on page 269).
Table 56: Erlang B and Poisson values, in 32-port increments
Erlang B with P.01 GoS Poisson with P.01 GoS

Number of Virtual Trunk access
Number of DSP ports CCS ports CCS
32 794 32 732
64 1822 64 1687
96 2891 96 2689
128 3982 128 3713
160 5083 160 4754
192 6192 192 5804

DSP ports for Conference
Because DSPs cannot be shared between Media Gateways, the efficiency of the DSP ports
on a Media Card is not as high as in a system-wide group. To calculate port and Media Card
requirements, use the following (and round up to the next integer if the result is a fraction):
• 794 CCS per Media Card (32 ports)
• 1822 CCS per two Media Cards (64 ports)
• 2891 CCS per three Media Cards (96 ports)
For example, 2000 CCS requires 96 DSP ports to provide a P.01 GoS (2000 >1822) as
calculated from Table 56: Erlang B and Poisson values, in 32-port increments on page 264. In
this example, you must provide 3 Media Cards, or a 96 DSP ports.
For information about allocating Media Cards to Media Gateways, see Assigning loops and
card slots in the Communication Server 1000E on page 375.
DSP ports for Conference

A DSP channel is required for each telephone joining a conference call. The more telephones
in the system, the higher the demand for DSP channels to access the conference feature.
Applications are another source of demand for the conference feature. Conference usage for
Integrated Conference Bridge is treated separately, as part of the calculations for application
ports. For other applications, the default is two conference loops, with a total of 60 channels,
per network group. If a particular application requires a different number of conference ports,
use the specific number.
The equation to calculate the number of DSP ports the system requires for Conference is:
Number of conference ports = [(Total number of telephones) × rCon × 0.4]
where rCon is the ratio of conference loops to traffic loops. The default value of rCon is 0.07
because, for each network group, there are assumed to be 2 conference loops and 28 traffic
loops (rCon = 2÷ 28 = 0.07). The default value of rCon can be changed if circumstances
warrant.
Number of conference loops = ROUNDUP [Number of Conference ports ÷ 30]
Number of DSP ports for Conference = Number of Conference loops × 32 (You require 1 Media
Card or 32 DSP ports for each defined conference loop).
Note:
For IP Media Services, no dedicated DSP resources are required to support IP
conference.

DSP ports for digital trunks

Digital trunks typically carry heavy traffic (28 to 36 CCS) per port, therefore each digital trunk
(PRI/PRI2/DTI/DTI2) requires a dedicated DSP port.
The minimum number of DSP ports required on the system equals the number of digital trunk
ports on the system.
When digital trunk cards are installed in a Media Gateway, the DSPs required to support that
digital trunk card must be placed into the same Media Gateway.
Number of DSP ports for digital trunks = Number of digital trunk ports
DSP ports for general traffic

There are two steps to calculate the number of DSP ports required for general traffic in each
Media Gateway:
1. Calculate the number of CCS for all standard cards in the Media Gateway.
Media Gateway standard CCS = (Number of standard telephones × CCS for each
telephone) + (Number of standard analog trunks × CCS for each trunk) + (Number
of standard consoles × 100 CCS).
A standard console requires 4 DSP ports that accounts for approximately 100 CCS
of usage.
2. Using the Erlang B table for P.01 GoS (see Table 56: Erlang B and Poisson values,
in 32-port increments on page 264), find the corresponding number of DSP ports
required.
Number of DSP ports for general traffic = Required number of ports for DSP CCS
from Erlang B table
DSP ports for major applications

For most applications, provide one DSP port for each application port.
Table 57: DSP port requirements for applications on page 267 provides the equations to
calculate the number of DSP ports required for each application. You must provide enough
DSP ports in each Media Gateway that contain application cards.

Special treatment for nonblocking access to DSP ports
Table 57: DSP port requirements for applications
Application or port type Calculation

Integrated Recorded Announcer Number of Integrated Recorded Announcer ports
Integrated Conference Bridge Number of Integrated Conference Bridge ports
Integrated Call Director Number of Integrated Call Director ports
Integrated Call Assistant Number of Integrated Call Assistant ports
Hospitality Integrated Voice Number of Hospitality Integrated Voice Service ports
Service
BRI Number of SILC ports = Number of BRI users × 2
CallPilot ports (Number of local CallPilot ports) + (Number of network
CallPilot ports) (see Note)
Agent Greeting ports Number of Agent Greeting ports
Avaya CallPilot calls served by another node are treated as trunk traffic and are not included
in DSP calculations for this node.
Number of DSP ports for applications = DSP for Integrated Recorded Announcer + DSP for
Integrated Conference Bridge + ... + DSP for Agent Greeting ports
Special treatment for nonblocking access to DSP ports

Since both Erlang B and Poisson models assume a high ratio of traffic sources to circuits, using
the standard estimate of 36 CCS per agent to calculate DSP requirements for a specified GoS
tends to result in over-provisioning. For this reason, rather use the fixed rule of one DSP port
for each nonblocking TDM telephone requiring a DSP resource, in order to provide nonblocking
access between the telephone and DSP.
The nonblocking telephones must be located in the same Media Gateway as the Media Cards
providing the DSP resources for the telephones.
Number of DSP ports for nonblocking traffic = Number of nonblocking TDM telephones +
number of nonblocking analog trunks + (number of nonblocking consoles × 12)
Total Media Gateway DSP requirements

Number of DSP ports for each Media Gateway = Number of DSP ports for conference
equation on page 265 + Number of DSP ports for digital trunks equation on page 266 + Number

of DSP ports for general traffic equation on page 266 + Number of DSP ports for applications
equation on page 267 + Number of DSP ports for nonblocking traffic equation on page 267
Simplified Media Gateway DSP calculations

You must allocate DSP ports for each Media Gateway in a Communication Server 1000E
system. The general DSP calculations on system wide traffic only provide an estimate of the
total number of DSP ports required on a Communication Server 1000E. You can use the
following rules to avoid complex DSP calculations for each Media Gateway.
Provision each Media Gateway with 128 DSP ports. This configuration allows a mix of blocking
and nonblocking cards in a standard Media Gateway with certain limits. You can configure a
maximum of 60 nonblocking ports in a standard Media Gateway. For example, you can
configure any two of either PRI, DTI, ICB, Mgate cards, and so on. RAN/MUSIC connections
also count as nonblocking ports. You can add a maximum of 30 conference ports in addition
to the previously selected items.
Note:
For IP Media Services, no dedicated DSP resources are required.
Each Communication Server 1000E system can have two types of Media Gateway DSP
configurations:
• maximum of 2 nonblocking resource units
• any number of blocking cards (limited by the available card slots in the Media Gateway)
• maximum of 2 standard consoles
A nonblocking resource unit can be any of the following
• 1 x PRI or digital trunk card (for example, 24-channel TMDI/T1 or 30-channel PRI/E1)
• 1 x CallPilot card
• 1 x DECT card (for example, DMC / DMC8 or DMC-E / DMC8-E)
• 1 x Agent Greeting, SECC VSC, CRQM and RAO cards
• 2 x nonblocking digital or analog line cards (includes analog card for CLASS and Reach
line card)
• 2 x nonblocking analog trunk cards
• 2 x nonblocking consoles
• 1 x nonblocking line side interface card
• 30 x broadcast circuits (RAN, MUSIC)
- Accounts for MIRAN cards. If you assign more than 60 broadcast circuits to a single
MIRAN or trunk card, you must install it in a dedicated nonblocking Media Gateway. If

Virtual Trunk calculations
less than 1 MIRAN or trunk card is available or assigned, you can have a maximum of
30 RAN or MUSIC for each card and install each in a standard Media Gateway.
A blocking card can be any of the following:
• CP PM and XCMC (CLASS clock)
• Standard digital or analog lines
• Standard Reach line cards
• Standard trunk cards
If there are high CCS rates for each card, you must configure the cards as nonblocking.
A nonblocking Media Gateway can also be referred to as a Dedicated Media Gateway. A
nonblocking Media Gateway has one DSP port for each resource in the Media Gateway. 12
DSP ports are required for each nonblocking console.
Virtual Trunk calculations

For reasons explained in the "System capacities on page 209" chapter (see Traffic capacity
engineering algorithms on page 227), the Poisson model is used to calculate trunk
requirements.
Table 56: Erlang B and Poisson values, in 32-port increments on page 264 provides Poisson
values for P.01 GoS in 32-port increments. The Virtual Trunk resource required to handle the
offered traffic is the number of access ports corresponding to the first Poisson CCS capacity
greater than the calculated traffic value.
To obtain the exact number of access ports required, use the following formula. Round up to
the next integer if the result is a fraction.
Number of access ports = (Calculated CCS) ÷ (CCS from Table 56: Erlang B and Poisson
values, in 32-port increments on page 264) × (Number of access ports for table CCS)
Perform the following steps to calculate the number of access ports required:
1. Estimate the Virtual Trunk requirement by adding together all the calls that require
the service of access ports.
Virtual Trunk calls (CVT) = Tandem VT-TDM trunk calls (CT1VT) + UIP-VT calls
(CSTIV) + TDM telephone-VT calls (C STDV) + VT-TDM telephone calls (CTSVD) + VT-
UIP telephone calls (CTSVI) + H.323-SIP VT calls (C T2HS) + SIP Line-VT calls
(CSTSV) + VT-SIP Line calls (CTSVS)
CVT = CT1VT + CSTIV + CSTDV + CTSVD + CTSVI + CT2HS + CSTSV + CTSVS
Calls that require H.323 Virtual Trunks: HCVT = CVT × VH
Calls that require SIP Virtual Trunks: SC VT = CVT × VS

For sites where the proportion of ACD agent telephones is less than 15% of the total
telephones in the system, CVT includes all general traffic seeking an access port.
Sites where the proportion of ACD agent telephones exceeds 15% of the total
telephones in the system are considered to be call centers. For call centers, CVT is
a reduced total that excludes ACD CCS. See Special treatment for nonblocking
access to DSP ports on page 267.
2. Convert Virtual Trunk calls to CCS.
Virtual Trunk CCS (VTCCS) = CVT × WAHT ÷ 100
3. For call centers, since the calculated Virtual Trunk calls exclude ACD traffic, restore
ACD traffic so that the final number of Virtual Trunks will be sufficient to handle both
general and ACD traffic.
Final Virtual Trunk CCS = (Calculated VTCCS without ACD) + [(Number of IP ACD
agent telephones) + (Number of TDM ACD agent telephones)] × V × ACD CCS ÷
TRKCCS
The expanded Virtual Trunk CCS is inflated by the ratio of 33/28 to reflect the fact
that more Virtual Trunks are needed to carry each agent CCS. This is because the
traffic levels engineered for ACD agents and Virtual Trunks are different.
4. Use the SIP and H.323 ratios to determine how the Virtual Trunk access ports will
be allocated to the two groups.
SIP Virtual Trunk CCS (SVTCCS) = VTCCS × vS H.323 Virtual Trunk CCS (HVTCCS)
= VTCCS × vH
5. Using the Poisson table for P.01 GoS (seeTable 56: Erlang B and Poisson values,
in 32-port increments on page 264 or Trunk traffic Erlang B with P.01 Grade-of-
Service on page 409), find the corresponding number of SIP and H.323 access
ports required.
Although a Virtual Trunk does not need the physical presence of a superloop, it does
utilize a logical superloop. A superloop of 128 timeslots can support 1024 Virtual
Trunk channels.
Reducing Virtual Trunk imbalances

The final value for calculated Virtual Trunks and its split into SIP and H.323 can be different
from initial user input. If the gap between user input and the calculated result is less than 20%,
use either number (although the larger number is preferred). If the gap is bigger, the
configuration is not balanced. It can be necessary to re-enter input data, including other input
parameters, and fine tune the configuration in order to narrow the gap. See Reducing
imbalances (second round of algorithm calculations) on page 305.
A discrepancy between calculated and input Virtual Trunks is significant because system
resources such as DSP ports and Virtual Trunk licenses depend on the accuracy of the traffic

Bandwidth requirement for access ports
split. Imbalanced Virtual Trunk traffic renders the resulting equipment recommendation
unreliable.
For example, if the calculated number of Virtual Trunks is 80 but the original input value was
60, and the user decides to use the original input value of 60 to calculate bandwidth and
Signaling Server requirements, the resulting system will likely provide service inferior to the
normal expected P.01 GoS. On the other hand, if the user input was 80 and the calculated
result is 60, it is up to the user to choose the number to use for further calculations for necessary
resources, such as the LAN/WAN bandwidth requirement. Unless the configuration is
constrained in some way, the larger of the two values (input number or calculated number) is
always preferred.
Bandwidth requirement for access ports

The LAN/WAN bandwidth requirement is based directly on traffic. Therefore, it does not depend
on the traffic model used nor on the number of Virtual Trunks (either input or calculated) used
for other calculations.
Convert Virtual Trunk calls to erlangs:
VT erlangs = VTCCS ÷ 36
Look up the VT erlangs number in a bandwidth table to find the corresponding bandwidth
required to carry the Virtual Trunk traffic to other H.323 endpoints. For information about the
bandwidth table and calculating LAN/WAN bandwidth requirements, see Avaya Converging
the Data Network with VoIP Fundamentals , NN43001-260.
Signaling Server algorithm

The Signaling Server algorithm in the EC tool determines the number of Signaling Servers
required for a given configuration. The algorithm allows a change in constants for Signaling
Server platform or Signaling Server application software releases.
The software components that operate on the Signaling Server are the Network Routing
Service (NRS), Terminal Proxy Server (TPS), IP Peer Gateways (H.323 and SIP), and Element
Manager. Traffic and user requirements determine whether the software components share a
Signaling Server or are served by stand-alone Signaling Servers.
For the applications, there are performance factors and software limit factors. The performance
factors are determined through capacity analysis. The software limit factors are defined by the
application. Element Manager can collocate with any of the other applications with negligible
impact.
In order to calculate the number of Signaling Servers required to support a particular
configuration, the algorithm first calculates the amount of Signaling Server resources required

by each application, taking redundancy requirements into consideration. The calculation for
each application is performed separately. Once the individual requirements are determined,
the algorithm proceeds to evaluate sharing options. Then the results are summed to determine
the total Signaling Server requirement.
In most cases, the individual calculations divide the configuration's requirement for an
applicable parameter (endpoint, call, telephone, trunk) into the system limit for that parameter.
The particular application's Signaling Server requirement is determined by the parameter with
the largest proportional resource requirement, adjusted for redundancy.
The Signaling Server hardware platform can be CP PM, CP DC, IBM x306m, HP DL320-G4,
HP DL360-G7, IBM x3350, or Dell R300 servers. For the calculations, each variable is indexed
by Signaling Server type. type index = CP PM or CP DC or COTS1 (HP DL320-G4, IBM
x306m), COTS2 (IBM x3350, Dell R300), or Common Server (HP DL360-G7).
Table 58: Signaling Server algorithm constants on page 272 defines the constants you use in
the Signaling Server algorithm.
Table 58: Signaling Server algorithm constants
Algorithm Constant Description Limit Notes

NRCHL[type_index] NRS calls per hour CP PM = 200 000 Hardware limit
CP DC = 300 000 for Signaling
COTS1 = 300 000 Server.
COTS2= 500 000 The SIP loading
Common Server= factor
500 000 determines SIP
Redirect and SIP
Proxy call rates,
see Table 63:
SIP mode
factors on
page 289.
NRCSL[type_index] NRS calls per hour CP PM = 20 000 Shared limit for
CP DC= 30 000 Signaling
COTS1 = 30 000 Server.
COTS2 = 50 000
Common Server =
50 000
NRD1[type_index] NRS CDP + UDP 50 000 Software limit.
entries limit COTS2 = 300 000
Common Server =
300 000
NRDHL[type_index] NRS product of 50 000 Hardware limit.
endpoint and CDP/ COTS2 = 300 000
UDP entries Common Server =
300 000
NRE1[type_index] NRS endpoints limit 5000 Software limit.
COTS2 = 6000


Common Server =
6000
SIP_Proxy_Limit[type_ind SIP Proxy NRS 1000 Software limit.
ex] endpoints limit for
TCP only
NRPSL[type_index] NRS product of 50 000 Software limit.
endpoint and CDP/ COTS2 = 300 000
UDP entries Common Server =
300 000
IPLSL[type_index] Internet phone limit 5000 Software limit.
IPCHL[type_index] Internet phone calls CP PM = 40 000 Hardware limit.
per hour limit CP DC = 80 000
COTS1 = 60 000
COTS2 = 80 000
Common Server =
80 000
PDmax[type_index] Maximum number of CP PM = 15 000 Hardware limit.
PD users CP DC = 25 000
COTS1 = 22 500
COTS2 = 40 000
Common Server =
40 000
HVTCHL[type_index] H.323 Gateway calls CP PM = 40 000 Hardware limit.
per hour limit CP DC= 60 000
COTS1 = 60 000
COTS2 = 80 000
Common Server =
80 000
HVTSL[type_index] H.323 Gateway 1200 CPU limit.
access ports for each
Signaling Server
SVTCHL[type_index] SIP Gateway calls per CP PM = 40 000 Hardware limit.
hour limit CP DC = 120 000
COTS1 = 60 000
COTS2 = 120 000
Common Server =
120 000
SVTSL[type_index] SIP Gateway access CP PM = 1800 CPU limit.
ports per Signaling CP DC = 3700
Server COTS1 = 1800
COTS2 = 3700
Common Server =
3700


TR87CL[type_index] SIP CTI/TR87 clients 5000 CPU limit.
SIPLCHL[type_index] SIP Phone call per CP PM = 15 000 Hardware limit.
hour limit CP DC =60 000
COTS1 = 25 000
COTS2 = 60 000
Common Server =
60 000
SIPLSL[type_index] SIP Phone limit CP PM = 1800 Software limit,
CP DC = 3700 includes SIP
COTS1 = 1800 DECT
COTS2 = 3700
Common Server =
3700
SIPL_VtrkSL[type_index] Combined SIPL and CP PM = 1200 Software limit.
Vtrk limit CP DC = 1600
COTS1 = 1600
COTS2 = 2000
Common Server =
2000
IPLDB[type_index] IP Phone limit with CP PM = 1500 Reduced due to
PD/CL/RL database CP DC = 2000 PD/RL/CL
and/or SIP Line COTS1 = 2000 database and
COTS2 = 3000 other
Common Server = applications.
3000
VTSL[type_index] Virtual Trunk share CP PM = 800 VT share limit.
limit CP DC = 1000 H.323 + SIP.
COTS1 = 1000
COTS2 = 1200
Common Server =
1200
TR87SL[type_index] SIP CTI/TR87 share 1000 Shared limit.
limit
NRESL[type_index] NRS endpoint share 100 Shared limit.
limit
NRDSL[type_index] NRS routing entry 1000 Shared limit.
share limit
STBCHL[type_index] SIP Trunk Bridge calls CP PM = 0 Hardware limit.
per hour CP DC = 40 000 CP PM, COTS1
COTS1 = 0 not supported.
COTS2 = 75 000
Common Server =
75 000


STBC_MAHL[type_index] SIP Trunk Bridge calls CP PM = 0 Hardware limit.
per hour with Media CP DC = 8000 CP PM, COTS1
Anchoring COTS1 = 0 not supported.
COTS2 = 15 000
Common Server =
15 000
STBSL[type_index] SIP Trunk Bridge CP PM = 0 Software limit.
session limit CP DC = 5000 CP PM, COTS1
COTS1 = 0 not supported.
COTS2 = 5000
Common Server =
5000
STB_MASL[type_index] SIP Trunk Bridge CP PM = 0 Software limit.
Media Anchoring CP DC = 1000 CP PM, COTS1
session limit COTS1 = 0 not supported.
COTS2 = 1000
Common Server =
1000
MSCSSL[type_index] MSC session limit CP PM = 1800 Software limit.
CP DC = 4000 Sum of IPCONF
COTS1 = 1800 + IPMUSIC +
COTS2 = 4000 IPTONE +
Common Server = IPRAN + IPATTN
4000 dedicated
platform
MSCSSLIPCONF[type_ind MSC IP Conf session 1920 Software limit
ex] limit dedicated
platform
MSCSSLIPRAN[type_inde MSC IP Ran session CP PM = 1000 Software limit
x] limit CP DC = 1000 / dedicated
4000 platform
COTS1 = 1000 CP DC variance
COTS2 = 4000 is 2GB / 4GB
Common Server =
4000
MSCSSLIPTONE[type_ind MSC IP Tone session CP PM = 1000 Software limit
ex] limit CP DC = 1000 / dedicated
4000 platform
Common Server =
4000
MSCSSLIPMUSIC[type_in MSC IP Music CP PM = 1000 Software limit
dex] session limit CP DC = 1000 / dedicated
4000 platform


Common Server =
4000
MSCSSLIPATTN[type_ind MSC IP Attn session 256 Software limit
ex] limit dedicated
platform
MSCCHL[type_index] MSC session call rate CP PM = 40 000 Hardware limit,
limit CP DC = 80 000 calls per hour.
COTS1 = 60 000
COTS2 = 120 000
Common Server =
120 000
MSC_VtrkSL[type_index] Shared MSC CP PM = 800 Software limit.
sessions and Vtrk limit CP DC = 1000 Sum of IPCONF
COTS1 = 1000 + IPMUSIC +
COTS2 = 2000 IPTONE +
Common Server = IPRAN + IPATTN
2000 non-dedicated
platforrm
MSC_VtrkSLIPCONF[type MSC IP Conf session CP PM = 800 Software limit
_index] limit CP DC = 1000 non-dedicated
COTS1 = 1000 platform
COTS2 = 1000
Common Server =
1000
MSC_VtrkSLIPRAN[type_i MSC IP Ran session CP PM = 800 Software limit
ndex] limit CP DC = 1000 non-dedicated
COTS2 = 1000
Common Server =
1000
MSC_VtrkSLIPTONE[type MSC IP Tone session CP PM = 800 Software limit
_index] limit CP DC = 1000 non-dedicated
COTS2 = 1000
Common Server =
1000
MSC_VtrkSLIPMUSIC[typ MSC IP Music CP PM = 800 Software limit
e_index] session limt CP DC = 1000 non-dedicated
COTS2 = 1000
Common Server =
1000


MSC_VtrkSLIPATTN[type_ MSC IP Attn session 256 Software limit
index] limit non-dedicated
platform
MASSSL[type_index] MAS session limit CP DC = 240 Software limit
IBM x3350 = 800 CP PM and
DELL R300 = 700 COTS1 not
HP DL360-G7 = supported
800
MASCSL[type_index] MAS session call rate CP DC = 6000 Hardware limit
limit IBM x3350 = 18000 for cph
Dell R300 = 18000 CP PM and
HP DL360-G7 = COTS1 not-
18000 supported
Co-resCR[type_index] Co-resident call rate CP PM = 15 000 Call rate limit for
limit CP DC = 30 000 Co-resident SS
COTS1 = 30 000 applications.
COTS2 = 50 000
Common Server =
50 000
type_index = CP PM or CP DC or COTS1 (HP DL320-G4, IBM x306m), COTS2 (IBM x3350,
Dell R300), or Common Server (HP DL360-G7)
If a limit does not specify a type_index, then the limit applies to all the Signaling Server
hardware platforms. CP MG is not supported as a stand-alone Signaling Server platform.
Table 59: Signaling Server algorithm user inputs on page 277 describes the user inputs you
use in the Signaling Server algorithm.
Table 59: Signaling Server algorithm user inputs
Algorithm user input Description Value Notes

NRS[type_index] Network Routing enter Yes or No
Service (NRS)
required
NRA[type_index] Network Routing enter Yes or No.
Service (NRS)
alternate required
NRC[type_index] NRS calls per hour enter Two
components:
NRC = NRC0 +
NRCNET one
local, one
network
NRD[type_index] NRS CDP + UDP enter
entries


NRE[type_index] NRS endpoints enter (= 0 if NRS,
which is a
network-wide
resource, is not
provisioned in
this node)
SSDB[type_index] PD/RL/CL required enter / derived = a if not
required = b if
shared = c if
standalone
IPL[type_index] IP Phones enter
HVT[type_index] Number of H.323 enter
virtual trunks required
SVT[type_index] Number of SIP virtual enter
trunks required
TR87[type_index] Aggregate number of enter
SIP CTI/TR87
required based upon
the MCS and OCS
calculated
TR87A[type_index] SIP CTI/TR87 enter Yes or No
redundancy required
SIPL[type_index] SIP Phones enter SIPN + SIP3
TPSA[type_index] TPS N+1 redundancy enter Yes or No
required
CUIP IP Phones calls per enter / derived Busy hour calls
hour from all IP
Phones
CUIP SIP Phones calls per enter / derived Busy hour calls
hour from all SIP
Phones
GWA[type_index] H.323 Gateway enter Yes or No
alternate required
GSA[type_index] SIP Gateway enter Yes or No
alternate required
SLGA[type_index] SLG 1+1 redundancy enter Yes or No
required
STB[type_index] SIP Trunk Bridge enter Requested SIP
sessions Trunk Bridge
sessions


STB_MA[type_index] SIP Trunk Bridge enter Yes or No
Media Anchoring
required
STBA[type_index] STB 1+1 redundancy enter Yes or No
required
MSCA[type_index] MSC 1+1 redundancy enter Yes or No
required
MASA[type_index] MAS N+1 redundancy enter Yes or No
required
XMSC_sessions External MSC enter 0 if no external
sessions from other sessions
systems expected
HS_NRSA[type_index] HS NRS 1+1 enter Yes or No
redundancy required
HS_ManA[type_index] HS Manager 1+1 enter Yes or No
redundancy required
HS_Primary HS Primary location enter Yes or No, set for
HS Primary
system only
Table 60: Signaling Server algorithm variables on page 279 describes the variables you use
in the Signaling Server algorithm.
Table 60: Signaling Server algorithm variables
Algorithm variable Description Value Notes

NRP NRS product of - Interim
endpoing and CDP/ calculation.
UDP entries
CUIP UNIStim IP Phones calc Busy hour calls
calls per hour from all UNIStim
IP Phones.
HCVT H.323 call rate calc
SCVT SIP call rate calc
ELCCVT ELC call rate calc
CSIP SIP Phones calls per calc Busy hour calls
hour from all SIP
Phones.
SSNR NRS Signaling Server calc Real number
calculation requirement
(example, 1.5)

Algorithm variable Description Value Notes

(= 0 if NRS is not
provisioned in
this node)
SSGW NRS Signaling Server calc Whole number
requirements requirement
including
alternate.
SSHR H.323 Gateway calc Real number
Signaling Server requirement
calculation (example, 1.5).
SSHW H.323 Gateway calc Whole number
requirements including
alternate.
SSTR TPS Signaling Server calc Real number
calculation requirement
(example,1.5).
SSTW TPS Signaling Server calc Whole number
requirements requirement
including
alternate.
SSTR87W SIP CTI/TR87 calc Whole number
Signaling Server required
alternate.
SSTR87 SIP CTI/TR87 calc Real number
calculation requirement.
SSSR SIP Gateway calc Real number
calculation (example,1.5).
SSSW SIP Gateway calc Whole number
alternate.
SSSLGR SIP Line Gateway calc Real number
calculation (example,1.5).
SSSLGW SIP Line Gateway calc Whole number
alternate.

Table 61: Constant and variable definitions for Co-resident Call Server and Signaling
Server on page 281describes the constant and variable definitions for each Co-resident Call
Server and Signaling Server hardware type.
Table 61: Constant and variable definitions for Co-resident Call Server and Signaling
Server
Algorithm constant Description Value [type_index] Comments

CS_SS_NRS_EP Gateway endpoints 5
on NRS
CS_SS_NRS_RE Routing entries on 20
NRS
CS_SS_CallRate CS and NRS call rate CP PM = 10 000
limit CP DC = 20 000
CP MG 128 = 8000
COTS2 = 30 000
Common Server =
30 000
CS_SS_IP_limit UNIStim Phone limit CP PM = 1000
CP DC = 1000
CP MG 128 = 700
COTS2 = 1000
Common Server =
1000
CS_SS_SIPL_limit SIPL Phone limit CP PM = 400 Includes SIP
CP DC = 400 DECT
CP MG 128 = 400
COTS2 = 1000
Common Server =
1000
CS_SS_IP_SIPL_limit UNIStim limit wien CP PM = 1000 SIPL includes
SIPL > 0 CP DC = 1000 SIP DECT
CP MG 128 = 700
COTS2 = 1000
Common Server =
1000
CS_SS_Vtrk_limit Vtrk limit CP PM = 400 SIP Gateway +
CP DC = 400 H323 Gateway
CP MG 128 = 400
COTS2 = 400
Common Server =
400
CS_SS_SIPL_Vtrk_limit Combined limit of CP PM = 800 sum of
SIPL and Vtrk CP DC = 800 CS_SS_SIPL_li
CP MG 128 = 800 mit +
COTS2 = 1400


Common Server = CS_SS_Vtrk_li
1400 mit
CS_SS_UCM_Elements UCM Element limit CP PM = 10
CP DC = 10
CP MG 128 = 10
COTS2 = 10
Common Server =
10
CS_SS_MSC_Sessions Maximum MSC CP PM = 400
sessions CP DC = 400
CP MG 128 = 400
COTS2 = 400
Common Server =
400
CS_SS_MSC_Ses_Vtrk Maximum combined CP PM = 400 MSC sessions +
Vtrk and MSC CP DC = 400 Vtrks <= this
sessions CP MG 128 = 400 limit
COTS2 = 400
Common Server =
400
CS_SS_MSC_IPCONF_S Maximum MSC IP CP PM = 400
essions Conf sessions CP DC = 400
CP MG 128 = 400
COTS2 = 400
Common Server =
400
CS_SS_MSC_IPTONE_S Maximum MSC IP CP PM = 400
essions Tone sessions CP DC = 400
CP MG 128 = 400
COTS2 = 400
Common Server =
400
CS_SS_MSC_IPRAN_Se Maximum MSC IP CP PM = 400
ssions Ran sessions CP DC = 400
CP MG 128 = 400
COTS2 = 400
Common Server =
400
CS_SS_MSC_IPMUSIC_ Maximum MSC IP CP PM = 400
Sessions Music sessions CP DC = 400
CP MG 128 = 400
COTS2 = 400
Common Server =
400


CS_SS_MSC_IPATTN_S Maximum MSC IP CP PM = 256
essions Attn sessions CP DC = 256
CP MG 128 = 256
COTS2 = 256
Common Server =
256
CS_SS_chasislimit Chassis limit as a CP PM = 5 not used in CPU
main CP DC = 5 calculation
CP MG 128 = 5
COTS2 = 5
Common Server =
5
CS_SS_ACD_agents Maximum ACD CP PM = 200 not used in CPU
agents as a main CP DC = 200 calculation
CP MG 128 = 200
COTS2 = 200
Common Server =
200
CS_SS_PRI Maximum PRI spans CP PM = 16 not used in CPU
CP DC = 16 calculation
CP MG 128 = 16
COTS2 = 16
Common Server =
16
CS_SS_TDM Maximum TDM CP PM = 720 not used in CPU
Phones CP DC = 720 calculation
CP MG 128 = 720
COTS2 = 720
Common Server =
720
CS_SS_branchs Maximum Branch CP PM = 5 not used in CPU
Offices CP DC = 5 calculation
CP MG 128 = 5
COTS2 = 5
Common Server =
5
For Co-res CS and SS, type_index = CP PM, CP DC, CP MG 128, COTS2 and Common
Server
A type_index is required for each algorithm constant. If only one value is provided, it applies
to all types
COTS1 is not a supported hardware type for Co-res CS and SS.
CP MG 32 is not supported as a stand-alone Co-res CS and SS. CP MG 32 is only supported
as SIP Media Gateway.

Signaling Server calculations

Signaling Server software components can run on shared or on standalone Signaling Servers.
System traffic and user requirements (for alternate, redundant, or dedicated Signaling Servers)
determine how many Signaling Servers are required.
SIP Dect telephones are provisioned on the SIP Line Gateway (SLG). The SIP Line count
includes SIP Dect telephones (SipN + Sip3), where SipN includes both SIP Line and SIP
Dect.
SIP Trunk Bridge requires a dedicated stand-alone multi-core Signaling Server (CP DC,
COTS2, or Common Server),
SIP Vtrk use for the HMS400 application is not calculated here. The HMS400 server SIP Vtrk
cannot be shared with a typical vtrk deployment on the NRS.
The Signaling Server algorithm takes account of all the requirements by performing the
following calculations in sequence:
1. Avaya Aura Session Manager Servers on page 285
2. High Scalability system Signaling Servers on page 286
3. Signaling Server for Co-resident Call Server and Signaling Server on page 287
4. Signaling Server for Personal Directory/Callers List/Redial List database (SSDB) on
page 288
5. Network Routing Service calculation (SSNR) on page 289
6. Terminal Proxy Server calculation (SSTR) on page 291
7. H.323 Gateway calculation (SSHR) on page 292
8. SIP Gateway calculation (SSSR) on page 292
9. SIP CTI/TR87 Calculation on page 293
10. SIP Line Gateway (SLG) calculation on page 294
11. Media Session Controller (MSC) calculation on page 295
12. Signaling Server Co-resident calculations on page 296
13. SIP DECT Server calculation on page 300
14. UCM calculation on page 300
15. SIP Trunk Bridge (STB) calculation on page 300
16. MAS calculation on page 301
17. Total Signaling Servers (SST) on page 304
Various hardware platforms are available for a Signaling Server. For the calculations, each
variable is indexed by the Signaling Server type_index. The type_index = CP PM or CP DC or

COTS1 (HP DL320-G4, IBM x306m), COTS2 (IBM x3350, Dell R300), or Common Server (HP
DL360-G7).
Note:
® ®
The Aura Session Manager does not run on any of these severs and requires its own Aura
hardware.
®
1. Avaya Aura Session Manager Servers
A Session Manager (SM) can replace the NRS except for when IPv6, H.323
Gateway, or a High Scalability system is required.
®
The Aura Session Manager does not run on any of the CS 1000 supported
®
signaling servers. It runs on its own Aura supported platform. The calculation
®
provided here is to help determine the number of Aura Session Manager servers
required. These are separate from the CS 1000 Signaling Server calculations and
are not part of the total Signaling Server calculation.
®
Once you determine if an Aura Session Manager is required, the following table
provides the information required for the Session Manager calculations.
Table 62: Session Manager constants and variables
Algorithm Description Value Notes

constant
SME_EP_limit SM maximum 11 200 hardware limit for
number of SIP SM
endpoints
SMC SM calls per hours enter SMC =SMC0 +
SMCNET, one
local, one network
equivalent to
BHCC
SMCHL SM calls per hour 300 000 hardware limit for
SM
SME SM number of SIP enter Value from index
endpoints 1h from user
SMNW Number of SM calc
SME is the sum of the value entered for index 1h and index 1d-1. The value entered
for SME cannot exceed 100 000. The value calculated for SMC or BHCC cannot
exceed 3 000 000, as the total number of SM is 10.
SMC is the calculated value of the BHCC for the SM.
SMC0 = VTSIP × CCS × 100 ÷ WAHT
SMCNET = VTSMNET × CCS × 100 ÷ WAHT ÷ 2

Perform the following calculation to determine the number of Session Manager

servers excluding N+1 redundancy or extra server requirements.
SMNR = larger of:

{
a) SME / SME_EP_limit endpoints software limit
b) SMC(BHCC) / SMCHL calls per hour limit
c) 0 if SM not provisioned
}
If SMNR >= 1
Th
en {
SMNW = ROUNDUP (SSMR) if true; else 1
}
All Signaling Server calculations are required. Calculate the following algorithm
in sequence
2. High Scalability system Signaling Servers

Determine if you require a High Scalability (HS) system. The HS system is a
collection of High Availability (HA) Call Servers and Signaling Servers. Each HS
system requires:
• a minimum of one dedicated COTS2 or Common Server NRS configured for
SIP Proxy mode to handle PSTN and interoperability connections.
• a minimum of one dedicated COTS2 or Common Server for the High Scalability
management server
Avaya recommends you deploy another inter-node NRS for management, and
recommends you dedicate a UCM server at the primary location. Use the following
calculation to determine the unique HS Signaling Servers required
If (HS_Primary = true)
Then {
HS_SS[type_index] = 2; (one NRS, one HS manager)
If (HS_NRSA = yes) then %alternate NRS required
HS_SS[type_index] = HS_SS[type_index] + 1
If (HS_ManA = yes) then %alternate HS manager required
HS_SS[type_index] = HS_SS[type_index] +1
}

Else
HS_SS[type_index] = 0;
in sequence
3. Signaling Server for Co-resident Call Server and Signaling Server

Determine if you require a Co-resident Call Server and Signaling Server system. If
yes, determine if the limits meet your Co-resident Call Server and Signaling Server
limits. Provision a system only if the limit criteria is met.
If system_type = Co-res CS and SS % Various hardware platforms

Then
{
% Check for boundaries
Total_IP_Phones = UNIStim + SIP Line (including SIP Dect)
If (Total_IP_Phones > CS_SS_SIPL_limit[Co-res_CS_type])
OR (SIPL_users > CS_SS_SIPL_limit[Co-res_CS_type])
OR ((HVT + SVT + ELC VT) > CS_SS_Vtrk_limit[Co-res_CS_type])
OR ((HVT + SVT + MSC) > CS_SS_MSC_Ses_Vtrk[Co-res_CS_type])
OR (MSC > CS_SS_MSC_sessions[Co-res_CS_type]) then
{
error (('CS-SS Co-res limit(s) exceeded.')
Exit this section and select new system type;
}
Else % Set & Trunk limits OK, check NRS
If NRE > 0 and NRE <= CS_SSNRS_EP[Co-res_CS_type] then
If NRD <= CS_SS_RNS_RE[Co-res_CS_type] then
{
calculate NRC as shown in NRS calculations;
% Note that TCALL is calculated in Call Server system calls section
if TCALL + NRC > CS_SS_CallRate[Co-res_CS_type] then
{
error ("The call rate calculated exceeds the limit this server can
handle.");
Exit this section and select new system type;

}
Else
one Co-res_CS_type server provision is correct
}
Else
If (NRE > CS_SS_NRS_EP[Co-res_CS_type])
OR (NRD > CS_SS_NRS_RE[Co-res_CS_type]) then
{
If TCALL > CS_SS_CallRate[Co-res_CS_type] then
{
error ("The call rate calculated exceeds the limit this server can
handle.");
Exit this section and select a new system type;
}
Else % stand-alone NRS required, one of the Co-res NRS limits
exceeded
SST[type_index] = SST[type_index] + NRA (=2 if true, else 1);
} % End of Co-res NRS bounds checking
% Provision additional SS for SIP Line if required
If SIP Line users > 0 and SIP Line dedicated= YES then
if SIPLineRedundant = true then
SST[type_index] = SST[type_index] + 2
Else
SST[type_index] = SST[type_index] + 1
} % End of Co-res CS + SS checks
Else
in sequence
4. Signaling Server for Personal Directory/Callers List/Redial List database

(SSDB)
SSDB[type_inde = a if no PD/CL/RL feature

x]
= b if yes on feature, and sharing functions on SS (UNIStim
Phones <= IPLDB[type_index] and (HVT+SVT) <=

VTSL[type_index]); PD_Co-res = True; NumOfCo-res =

NumOfCo-res + 1;
= c if yes on feature, and dedicated PD/CL/RL or (UNIStim
Phones > IPLDB[type_index] and (HVT+SVT) >
VTSL[type_index])
if SSDB = c PD on dedicated Signaling Server
SST[type_index] = SST[type_index] +1
5. Network Routing Service calculation (SSNR)
Choose NRS hardware type if dedicated NRS, otherwise nrs_type_index =

type_index
If dedicated NRS required, then
{ obtain the NRS platform type: nrs_type_index
where nrs_type_index = CP PM or CP DC or COTS1 (IBM x306m, HP
DL320-G4), COTS2 (IBM x3350, Dell R300), or Common Server (HP
DL360-G7)
initialize SST[nrs_index_type] = 0
}
If there are SIP endpoints that require NRS, query and obtain the SIP mode,
If SIP_mode = none, Proxy or Redirect.
If SIP_mode = Proxy, then the maximum number of GW endpoints = 1000
(SIP_Proxy_limit).
Query and obtain SIP transport required: SIP_transport = UDP or TCP/TLS

If SIP_mode = Proxy and SIP_transport = TCP/TLS, then
NRS_EP_limit = SIP_Proxy_limit[nrs_type_index]
Else
NRS_EP_limit = NRE[nrs_type_index]
Since the capacity for handling H323 calls is different than SIP calls, you must
determine the SIP call loading factor on NRS. There are two SIP modes, SIP_Proxy
and SIP_Redirect. To calculate the SIP loading factor, see Table 63: SIP mode
factors on page 289.
Table 63: SIP mode factors
type_index SIP_Redirect_Factor SIP_Proxy_Factor

CP PM 2 4
CP DC 1.5 3
COTS1 1.5 3

type_index SIP_Redirect_Factor SIP_Proxy_Factor

COTS2 1.67 2.5
Common Server 1.67 2.5
SSNR[nrs_type_index] = larger of:

{
a NRE[nrs_type_index] ÷ NRS_EP_limit (endpoints software limit)
b NRD[nrs_type_index] ÷ NRDl[nrs_type_index] (dial plan entries software
limit)
c NRC[nrs_type_index] ÷ NRCHL[nrs_type_index] (calls per hour
hardware limit)
d 0 if NRS is not provisioned and there is no branch office
e If (NRE > NRESL[nrs_type_index] or NRD > NRDSL[nrs_type_index] or
NRC > NRCSL[nrs_type_index]), then 1, else 0 (Co-res limit)
}
If you require a dedicated NRS Signaling Server, round up SSNR for the following
calculations.
If SSNR[nrs_type_index] >= 1 or dedicated NRS required

Then {
SSNW = ROUNDUP(SSNR) × NRA(=2, if true; else 1)
SST[nrs_type_index] = SST[nrs_type_index] + SSNW
}
Else { SS_Co_Res = SS_Co_Res + SSNR[nrs_type_index];
If SSNR[type_index] > 0
Then { NRS_Co-res = True; NumOfCo-res = NumOfCo-res + 1
}
}
NRC could be a hardware or CPU or memory limit; it includes NRC0 (calls result
from main switch calculation) and network VTNET for the Network Routing Service:
NRC = NRC0 + NRCNET
Both VT323 and VTSIP must convert to H.323 and SIP calls from your input:
H323 calls = VT323 × CCS per VT × 100 ÷ WAHT

SIP calls = VTSIP × CCS per VT × 100 ÷ WAHT + (ELC VT × CSS per telephone ×
100 ÷ WAHT)
Determine the SIP loading factor on the NRS:
Factor = If SIP mode = Proxy,

Then SIP_Proxy_Factor[nrs_type_index]
Else If SIP mode = Redirect,
Then SIP_Redirect_Factor[nrs_type_index]
Else 0
NRC0 = (H323 calls + Factor × SIP calls) NRCNET = VTNET × CSS for each VT ×
100 ÷ WAHT ÷ 2
NRC = NRC0 + NRCNET
Formula (c) in SSNR equation = NRC ÷ NRCHL[nrs_type_index]
The previous equation represents the load on the Signaling Server to handle NRS
calls. Compare it with (a) and (b) to determine the highest of all potential uses.
6. Terminal Proxy Server calculation (SSTR)
Calculate the TPS call rate: CUIP= C2IP× 2 + C1IP + C2SIPUIP + CSTIV + CSTID + CSTVI
The Call Server CPU calculations define the variables.
SSTR[type_index] = larger of:

{
a IPL ÷ IPL SL[type_index] IP Phones software
limit
b CUIP[type_index] ÷ IPCHL[type_index] call limit - calls per hour
limit
c If IPL > IPL DB[type_index] then 1 else 0 Co-res limit
}
If the user wants Terminal Proxy Server(s) in a dedicated Signaling Server, round
up SSTR before proceeding with further calculations:
if SSTR[type_index] >= 1 or dedicated TPS required

Then {
SSTW[type_index] = ROUNDUP(SSTR[type_index]) +
TPSA[type_index] (=1, if true; else 0)
TPSA = if N+1 redundant TPS needed

SST[type_index] = SST[type_index] + SSTW;

}
Else { Co-res
If SSTR[type_index] = 0
Then { TPS_Co-res = true; NumOfCo-res = NumOfCo-res + 1
}
}
7. H.323 Gateway calculation (SSHR)

HCVT = (HVTCCS × 100) ÷ WAHT
SSHR[type_index] = larger of:

{
a HVT[type_index] ÷ number of trunks (software limit)
HVTSL[type_index]
b HCVT[type_index] ÷ calls per hour (hardware limit)
HVTCHL[type_index]
c If HVT[type_index] > non-dedicated limit
VTSL[type_index] then 1 else 0
}
If the user wants H.323 Gateway(s) in a dedicated Signaling Server, round up

SSHR[type_index] before proceeding with further calculations:
if SSHR[type_index] >= 1 or dedicated H323 Gateway is required

Then {
SSHW[type_index] = ROUNDUP(SSHR[type_index]) ×
GWA[type_index] (true = 2; else=1)
GWA = If Alternate H323 Gateway needed
SST[type_index] = SST[type_index] + SSSW
}
Else { If SSHR[type_index] > 0
Then { H323_Co-res = True; NumOfCo-res = NumOfCo-res + 1
}
}
8. SIP Gateway calculation (SSSR)

The number of SIP virtual trunk calls is calculated from the SVTCSS:
SCVT = (SVTCCS × 100) ÷ WAHT
The number of virtual trunks required for the Extend Local Calls (ELC) feature:
ELCVT = ELC ISM value (the requested number of ELC users)
The number of ELC calls that impact SIP virtual trunks:
ELCCVT = CSS × ELC_P
SSSR[type_index] = larger of:

{
a (SVT[type_index] + ELCVT) ÷ number of trunks (software limit)
SVTSL[type_index]
b (SCVT[type_index] + ELCCVT calls per hour (hardware limit)
c (SVT[type_index]+ ELCVT) > non-dedicated limit
VTSL[type_index] then 1 else 0
}
If the user wants SIP Gateway(s) in a dedicated Signaling Server, round up

SSSR[type_index] before proceeding with further calculations:
if SSSR[type_index] >= 1 or dedicated SIP Gateway is required

Then {
SSSW[type_index] = ROUNDUP(SSSR[type_index]) +
GSA[type_index] (= 2 if true, else 1)
GSA = If Alternate SIP Gateway needed
SST[type_index] = SST[type_index] + SSSW
}
Else { If SSSR[type_index] > 0
Then { SIP_Co-res = true; NumOfCo-res = NumOfCo-res + 1
}
}
9. SIP CTI/TR87 Calculation

If SIP CTI TR87 feature is present, Total SIP CTI TR87 is > 0
SSTR87[type_index] = larger of:

{

a TR87[type_index] ÷ TR87CL[type_index] number of clients

(software limit)
b If TR87 > TR87 SL[type_index] then 1 else 0 Co-res limit
}
If the user wants SIP CTI/TR87 in a dedicated signalling server, then round up
SSTR87[type_index] before proceeding with further calculations.
if SSTR87[type_index] >= 1 or dedicated SIP CTI is required

Then {
SSTR87W[type_index] = ROUNDUP(SSTR87[type_index]) ×
TR87A[type_index] (= 2 if true, else 1)
TR87A = if Alternate SIP CTI/TR87 needed
SST[type_index] = SST[type_index] + SSTR87W
}
Else { If SSTR87[type_index] > 0
Then { TR87_Co-res = true; NumOfCo-res = NumOfCo-res + 1
}
}
10. SIP Line Gateway (SLG) calculation

SLG supports SIP DECT as SIP Line users.
The number of SIP Line users on a Call Server is defined as: SIPL = SIPN + SIP3
Where SIPN = ISM value including SIP Line and SIP DECT telephones
If SIPL = 0 do not provision hardware for SIPL.
Calculate the total number of SIP Line calls

CSIP = (2 × C2SIP) + C1SIP + C2SIPUIP + CSTSV + CSTSD + CTSVS + CTSDS
The Call Server CPU calculations define the
variables
SSSLGR7[type_index] = larger of:
{
a SIPL ÷ SIPL SL[type_index] number of phones
(software limit)
b CSIP ÷ SIPLCHL[type_index] calls per hour (software
limit)

c SIPL + IPL > IPL_db or SIPL + SVT + HVT > non-dedicated limit
SIPL_VtrkSL[type_index] then 1 else 0
}
Round up SSSLGR before performing further calculations
If (SSLGR[type_index] >= 1) or dedicated SIP Line Gateway then
{
SSSLGW[type_index] = ROUNDUP
(SSSLG[type_index] × SIPLA[type_index]
(=2, if true; else 1) SIPLA = if 1 + 1 redundant
SIPL is required
SST[type_index] = SST[type_index] +
SSSLGW;
}
Else Co-res
If SSSLGR[type_index] > 0 then
{
SLG_Co-res = true;
NumOfCo-res = NumOfCo-res + 1;
}
11. Media Session Controller (MSC) calculation

The MSC application is required if you selected IP Media Services and calculated
the required media sessions. To calculate MSC_sessions, see IP Media
Services on page 225.
MSCC = (MSC_sessions × TRKCCS × 100) ÷ WAHT
Media anchoring lowers the supported number of sessions and the call rate of SIP
Trunk Bridge.
SSMSCR[type_index] = larger of:

{
a MSC_sessions ÷ MSCSSL[type_index] number of sessions
(software limit)
b MSCC ÷ MSCCSL[type_index] calls per hour
(hardware limit)
c MSC_sessions + SVT + HVT > 1 = dedicated MSC
MSC_VtrkSL[type_index] then 1, else 0 required
0 = non-dedicated limit
OK

}
SSMSCR[type_index] = ROUNDUP (SSMSCR[type_index]);
If (SSMSCR[type_index] >= 1) or dedicated MSC then
{
If MSCA[type_index] = true then redundant MSC
requested
SSMSCW[type_index] =
SSMSCR[type_index] + 1
SSMSCW[type_index];
}
Else Co-res
If SSMSCR[type_index] > 0 then
{
MSC_Co-res = true;
}
12. Signaling Server Co-resident calculations

Determine if any Signaling Server applications can co-reside on one Signaling
Server.
Case of NumOfCo-res;
Null; No SS applications Co-
res
{
SST[type_index] = SST[type_index] + 1; One SS application -
assign one SS
If redundant needed, add one SS and reset Co-res flag
If (NRS_Co-res = true and NRA = true) or (TPS_Co-res = true and TPSA = true)
or (H323_Co-res = true and GWA = true) or (SIP_Co-res = true and GSA = true)
or (TR87_Co-res = true and TR87A = true) or MSC_Co-res = true and MSCA =
true)
Then { SST[type_index] = SST[type_index] + 1;

If NRS_Co-res = true then NRS_Co-res = false;
Else

If TPS_Co-res = true then TPS_Co-res = false;

Else
If H323_Co-res = true then H323_Co-res = false;
Else
If SIP_Co-res = true then SIP_Co-res = false;
Else
If TR87_Co-res = true then TR87_Co-res = false;
Else
If SIPL_Co-res = true then SIPL_Co-res =
false;
Else
If MSC_Co-res = true then MSC_Co-res =
false;
NumOfCo-res = 0;
} End case of one SS
application Co-res
}
Determine if the Co-res VTRK limit is More than one SS
exceeded application Co-res
{
If H323_Co-res = true and SIP_Co-res = true and (HVT + SVT + ELC VT >
VTSL[type_index])
Then { SST[type_index] = SST[type_index] + 1;
H323_Co-res = false;
If GWA = true then SST[type_index] = SST[type_index] + 1;
}
If NumOfCo-res = 0, then exit
Else If NumOfCo-res = 1, then DO One SS application - assign one SS
Else
{ CallRate = 0;
If NRS_Co-res = true then CallRate = CallRate + NRC;
If TPS_Co-res = true then CallRate - CallRate + CUIP;
If H323_Co-res = true then CallRate = CallRate + HCVT;

If SIP_Co-res = true then CallRate = CallRate + SCVT+ ELCCVT;

If SIPL_Co-res = true then CallRate =
CallRate + CSIP;
If MSC_Co-res = true then CallRate =
CallRate + MSCC;
If CallRate <= Co-resCR[type_index]
Then {
SST[type_index] = SST[type_index] + 1;
If (NRS_Co-res = true and NRA = true) or (TPS_Co-res = true and
TPSA = true) or (H323_Co-res = true and GWA = true) or (TR87_Co-
res = true and TR87A = true) or (SIPL_Co-res = true and SIPLA = true)
or (MSC_Co-res = true and MSCA = true)
Then
SST[type_index] = SST[type_index] + 1;
}
Else { Call rate exceeds the Co-
res limit
TNRC = NRC;
TCUIP = CUIP;
THCVT = HCVT;
TSCVT = SCVT + ELCCVT;
TCSIP = CSIP;
TMSCC = MSCC
DO
{
large = largest of (TNRC, TCUIP, THCVT, TSCVT, Dedicate a SS to the
TSIP, TMSCC); largest contributor
If large = TNRC
Then {
NRS_Co-res = false;
CallRate = CallRate - NRC;
NumOfCo-res = NumOfCo-res - 1;
TNRS = 0;
SST[type_index] = SST[type_index] + NRA (= 2 if true, else 1);
}

Else If large = TCUIP

Then { TPS_Co-res = false;
CallRate = CallRate = CUIP;
TCUIP = 0;
SST[type_index] = SST[type_index] + TPSA (= 2 if true, else 1);
}
Else If large = THCVT
Then { H323_Co-res = false;
CallRate = CallRate - HCVT;
THCVT = 0;
SST[type_index] = SST[type_index] + GWA (= 2 if true, else 1);
}
Else If large = TSCVT
Then { SIP_Co-res = false;
CallRate = CallRate - SCVT - ELCCVT;
TSCVT = 0;
SST[type_index] = SST[type_index] + GSA (= 2 if true, else 1);
}
Else If large = TCSIP
Then { SIPL_Co-res = false;
CallRate = CallRate - SCSIP;
TSCSIP = 0
SIPLA (=2 if true, else 1);
}
Else If large = TMSCC
Then { MSC_Co-res = false;
CallRate = CallRate - MSCC;

TMSCC = 0
MSCA (=2 if true, else 1);
}
Repeat DO until CallRate <= Co-
resCR[type_index]
If NumOfCo-res = 0, then exit
Else If NumOfCo-res = 1, then do One SS application -
Assign one SS
Else { SST[type_index] = SST[type_index] + 1;
If (NRS_Co-res = true and NRA = true) or (TPS_Co-res = true and
TPSA = true) or (H323_Co-res = true and GWA = true) or (SIP_Co-res
= true and GSA = true) or (TR87_Co-res = true and TR87A = true) or
(SIPL_Co-res = true and SIPLA = true) or MSC_Co-res = true and
MSCA = true)
Then SST[type_index] = SST[type_index] + 1;
}
}
}
}
13. SIP DECT Server calculation

The SIP Line Gateway (SLG) calculation includes SIP DECT. No independent SIP
DECT servers required.
SS_DECT = 0
14. UCM calculation
If ucm_pss_required = true
Then {
SST[ucm_pss_type] =
SST[ucm_pss_type] + 1;
If ucm_backup_required = true then
SST[ucm_pss_type] = SST[ucm}pss_type] + 1;
}
15. SIP Trunk Bridge (STB) calculation

The SIP Trunk Bridge application must be deployed as a stand-alone dedicated
server.

Determine the number of calls per hour for SIP Trunk Bridge. STBC[type_index] =
(STB[type_index] × TRKCCS × 100) ÷ WAHT The number of servers required
increases with media anchoring usage. Media anchoring lowers the supported call
rate and number of sessions for SIP Trunk Bridge.
If STB_MA[type_index] = yes then

{ Media anchoring
required
SSSBTR[type_index] = larger of:
{
a STB[type_index] ÷ STB_MASL[type_index] number of trunks
(software limit)
b STBC[type_index] ÷ STBC_MAHL[type_index] calls per hour
(hardware limit)
}
Else No media anchoring
{
SSSBTR[type_index] = larger of:
{
a STB[type_index] ÷ STBSL[type_index] number of trunks
(software limit)
b STBC[type_index] ÷ STBCHL[type_index] calls per hour
(hardware limit)
}
SIP Trunk Bridge requires a dedicated Signaling Server
If STBA[type_index] = no then No redundancy
required
{
SSSTBW[type_index] = ROUNDUP
(SSSR[type_index])
Else
SSSTBW[type_index] = ROUNDUP
(SSSR[type_index]) + 1
}
SST[type_index] = SST[type_index] + SSSTBW[type_index];
16. MAS calculation

The MAS application requires additional dedicated Signaling Servers. The MAS
application is supported on CPDC and COTS2 Server Signaling Servers only.
MAS servers are deployed in clusters, with a maximum cluster size of 7 servers.
The MAS license server does not know the capacity limitations of the MAS servers
in the cluster. Therefore, all MAS servers within the cluster MUST be of the same
type, or at a minimum, have the same capacity rating.
To ensure the MAS servers can handle the load of a cluster when one of the servers
fails, a redundant server may be selected. Selecting redundancy for MAS puts an
additional server in each cluster (N+1 servers per cluster).
Since the cluster has a limit of 7 servers, adding a redundant server lowers the
cluster size by 1 server, which could potentially increase the number of MAS clusters
required. An example is shown in the following table:
No Redundancy Redundancy
Servers in Cluster Servers in Redundant Total Server is
Cluster Server Cluster
1–7 1–6 1 2–7
Additional MAS servers requested by the customer must also be considered in the
cluster calculations.
The Systems Options page contains an input field for Additional MAS Servers,
referred to as MAS_Additional.
The codec used on the MAS server has a large impact on the number of conference
sessions that can be supported. Therefore, the MAS codec selection must be taken
into consideration when determining the number of sessions that can be supported
on a MAS server.
The following table shows the MAS Codec Ratios (MASCRatio) used for each MAS
server type:
Type index G711 G722 G729

CPDC 1 1.8 1.944
Dell R300 1 1.8 1.944
IBM x3350 1 1.8 1.944
HP GL360 G7 1 1.8 1.944
The following table shows the MAS SRTP impact (MASSRTP):

Type index G711 G722 G729

CPDC 0.860 0.922 0.928
Dell R300 0.860 0.922 0.928
IBM x3350 0.860 0.922 0.928
HP GL360 G7 0.860 0.922 0.928
The calculations used to determine the number of Signaling Servers required for
MAS depends on the MAS codec selection, the use of Media Security on the MAS
server and two MSC variables; MSC Sessions (MSC_sessions) and MSC call rate
(MSCC).
If (MAS_MSEC=off) then
MASSRTP_factor = 1;
Else
MASSRTP_factor = MASSRTP[codec];
SSMASR[type_index] = larger of:
{
a (MSC_sessions + XMSC_sessions) ÷ number of sessions
((MASSSL[type_index] * MASSRTP_factor )/ (software limit)
MASCRatio[MAScodec] )
b MSCC ÷ MASCHL[type_index] calls per hour
(hardware limit)
}
SSMASR[type_index] = ROUNDUP(SSMASR[type_index]) + MAS_Additional
If (SSMASR [MAS_type_index] >= 1)

Then
{
If MASA[MASA_type_index] = true then Redundant MAS
Server(s) required
{
SSMASRed[MAS_type_index] = Calculate number of
SSMASR[MAS_type_index] / redundant servers
(MAS_Cluster_size -1)
SSMASRed[MAS_type_index] = ROUNDUP Roundup to whole
(SSMASR[MAS_type_index]) number

SSMASW[MAS_type_index] = Total MAS servers = N

SSMASR[MAS_type_index] + server + redundant
SSMASRed[MAS_type_index] server
}
Else SSMASW[MAS_type_index] = No redundancy. N is
SSMASR[MAS_type_index] total MAS Servers
required
}
SST[MAS_type_index] = SST[MAS_type_index] + Add total MAS servers
SSMASW[MAS_type_index] to current SS total
17. Total Signaling Servers (SST)
The total number of Signaling Servers provisioned:

SST[type_index] = SST[type_index] + SST[nrs_type_index] +
SST[ucm_pss_type] + SST[sipl_type_index]:
If you are calculating for the primary location of a High Scalability (HS)
deployment, then deploy the HS servers at this location:
SST[type_index] = SST[type_index] + HS_SS[type_index]
See Signaling Server calculation on page 317 for a for a numerical example illustrating the
algorithm.
Maximum number of Failsafe Network Routing Services

This algorithm defines the maximum number of Failsafe Network Routing Services (RSF) that
can be configured. The maximum RSF is limited by the Primary Network Routing Service (RSP)
configuration.
RSF is less than or equal to RSPE RSF = (RDEL ÷ RSPE) × [FR – (RFRS or RFRC)] × (DDR
÷ 24) × (RSPC)
Simplified formulas:
RSF = (16 000 ÷ RSPE) for stand-alone Network Routing Service RSF = (10 000 ÷ RSPE) for
collocated Network Routing Service
Table 64: RSF algorithm constant and variable definitions on page 305 defines the terms used
in the calculations.

Reducing imbalances (second round of algorithm calculations)
Table 64: RSF algorithm constant and variable definitions
Algorithm term Description Value Notes

DDR Dynamic Data 24 (Constant that In one day, the
Resynch updates with platform minimum number of
changes) synchronizations of
dynamic data from
Active RD to a RSF.
FR FTP Resource 10 (Constant that Software limit.
updates with system
software releases)
RDEL NRS endpoints limit 5000 (Constant that Software limit.
updates with system
software releases)
RSF Maximum Failsafe calc (Calculated
NRS allowed result)
RSPC RSP CPU 1.0 (Constant that PIII 700 MHz; 512
performance updates with platform MByte; 20 GByte
changes)
RSPE RSP endpoints enter (Variable to be
entered into the
formula)
RFRC Reserved FTP 5 (Constant that Software limit. RSP
Resource Collocated updates with system shares Signaling
software releases) Server with other
applications, such as
TPS. Reserve 3 for
other applications.
RFRS Reserved FTP 2 (Constant that Software limit. RSP is
Resource Standalone updates with system only application on
software releases) Signaling Server.
Reserve 1 for Static
updates and 1 spare.
Reducing imbalances (second round of algorithm

calculations)
Input data may not be consistent. For example, there can be a high intraoffice ratio in a call
center, or few trunks but a high interoffice ratio. In these cases, the resulting calculations in the
Enterprise Configurator tool generate a warning message indicating traffic imbalance. The user
may want to change the input data and rerun the calculation.

There are two types of imbalances that can occur

• Virtual Trunks on page 306
• Line and trunk traffic on page 307
Virtual Trunks
When the VT number input by the user differs significantly from the calculated VT number
(more than 20% difference), the Enterprise Configurator tool uses the calculated number and
rerun the algorithm to obtain a newer VT number. If the resulting VT number is not stable (in
other words, after each rerun, a new calculated VT number is obtained), the program repeats
the calculation cycle up to six times. This recalculation looping is built into the Enterprise
Configurator and occurs automatically, with no user action required. At the end of the
recalculation cycle, the user has the choice of using the original input VT number or the final
calculated VT number in the configuration.
The user inputs about the number of H.323 Virtual Trunks and SIP Virtual Trunks are a function
of other parameters in the system. For example, the number of Virtual Trunks required are
affected by the total number of trunks in the system and by intraoffice/incoming ratios: Virtual
Trunks and TDM trunks cannot carry a high volume of trunk traffic if the system is characterized
as carrying mostly intraoffice calls. If pre-engineering has not provided consistent ratios and
CCS, the VT input numbers tend to diverge from the calculated results based on input trunking
ratios.
Use the following formula to calculate the VT CCS to compare against user input, in order to
determine the size of the deviation. Note that for this consistency check, H.323 VT CCS and
SIP VT CCS are separated out from the VT total by using the user input ratio of H.323 to
SIP.
HVT = CVT × vH × WAHT ÷ 100
SVT = CVT × vS × WAHT ÷ 100
The respective difference between HVT and HVTCCS, and between SVT and SVT CCS, is the
deviation between input data and calculated value.
After the automatic Enterprise Configurator recalculations, if the discrepancy between the input
VT number and the final calculated number is still significant (more than 20%), follow the
recommendations for reducing line and trunk traffic imbalance (see Line and trunk traffic on
page 307). Adjusting the number of Virtual Trunks and trunk CCS alone, without changing the
intraoffice ratio or its derivatives, may never get to a balanced configuration.

Line and trunk traffic
Line and trunk traffic

At the end of the algorithm calculation, if the line and trunk CCS are significantly imbalanced
(more than 20% difference), the Enterprise Configurator tool generates a warning message.
The user can choose whether to change input data and rerun the calculation to have a better
balanced system. The recalculation loop starts from the point of entering configuration inputs
at the GUI.
Use the following formula to obtain the calculated line CCS to compare against user input, in
order to determine the size of the deviation.
Calculated line CCS (LCCCS) = (CSS + CST + CTS) × WAHT ÷ 100
The difference between LCCS and LCCCS is the imbalanced line CCS.
Similarly, use the following formula to obtain the calculated trunk CCS to compare against user
input, in order to determine the size of the deviation.
Calculated total trunk CCS (TCCCS) = (CTT + CST + CTS) × WAHT ÷ 100
The difference between TTCCS and TCCCS is the imbalanced trunk CCS.
Because the calculated CCS factor in traffic ratios, line and trunk CCS can be significantly
imbalanced if these ratios are inconsistent. For example, if the intraoffice, incoming, and
outgoing ratios are based on contradictory assumptions, the calculated line CCS can be much
higher than the number of trunks can absorb.
Table 65: Tips to reduce traffic imbalances on page 307 provides tips for users to modify input
data so as to steer the algorithm in the right direction. The desired configuration for the input
data is when the input numbers for Virtual Trunks, line CCS, and trunk CCS are close to their
calculated values (less than 20% difference).
Table 65: Tips to reduce traffic imbalances
When this happens... Try this...

Line traffic too high • Reduce CCS per telephone or number of
telephones.
• Increase the intraoffice ratio.
Trunk traffic too high • Reduce CCS per trunk or number of trunks.
• Reduce the intraoffice ratio.
• Increase the tandem ratio (if justified; changing the
incoming/outgoing ratio has no impact on line/trunk
traffic imbalance).

When this happens... Try this...

Need to change input VT number • If changing the input VT number is not an option,
because other input data has keep it and change only the number of TDM
changed trunks.
• If the input VT number is not a committed value, use
the VT number from the previous run.
• When input traffic data is changed, expect the
resulting VT number to change accordingly. Modify
line data or trunk data one at a time to see the trend
of convergence. Otherwise, it is hard to know what
variable is most responsible for converging to the
desired result.
Illustrative engineering example

The following numerical example is for a general business/office model.
Assumptions
The example uses the following values for key parameters.
These parameter values are typical for systems in operation, but the values for the ratios are
not the defaults.
• Intraoffice ratio (RI): 0.25
• Tandem ratio (RT): 0.03
• Incoming ratio (I): 0.60
• Outgoing ratio (O): 0.12
In fraction of calls, the above ratios add up to 1.
• AHTSS = 60 [average hold time (AHT) for telephone to telephone (SS)]
• AHTTS = 150 [AHT for trunk to telephone (TS)]
• AHTST = 150 [AHT for telephone to trunk (ST)]
• AHTTT = 180 [AHT for trunk to trunk (TT)]

Given configuration
Given configuration
A Communication Server 1000E CP PIV system with the following configuration data:
• 1200 digital and analog telephones at 5 CCS/telephone
- including 170 ACD agents with digital telephones at 33 CCS/agent
• 1600 IP telephones at 5 CCS/IP telephone
- including 50 IP ACD agent telephones at 33 CCS/IP agent telephone
• 200 MDECT mobile phones at 5 CCS/telephone
• 1200 SIP Line telephones
• 820 trunks
- 450 Virtual Trunks (300 H.323 and 150 SIP) at 28 CCS/trunk (The numbers for H.323
and SIP Virtual Trunks are input from user response to a GUI request in the EC.)
- 370 TDM (PRI) trunks at 28 CCS/trunk
• Network Virtual Trunks served by this Gatekeeper: 800 (This is another input from the
user interface.)
• CallPilot ports at 26 CCS/CP port
- 36 local CallPilot ports
- 24 network CallPilot ports (input from user interface)
• Other traffic-insensitive, preselected application ports that require DSP channels and real
time feature overhead. The DSP required for IP Phones to access these special
applications is proportional to the percentage of IP calls in the system.
- Agent greeting ports: 4
- Integrated Conference Bridge ports: 16 (HT = 1800)
- Integrated Recorded Announcer ports: 12 (HT = 90)
- Integrated Call Assistant ports: 8 (HT = 180)
- Hospitality Integrated Voice Service ports: 8 (HT = 90)
- Integrated Call Director ports: 12 (HT = 60)
- BRI users: 8 (HT = 180)
- MDECT mobile telephones: 200 (HT = WAHT)
• Features with processing overhead but no hardware ports:
- CPND percentage: CPND calculation assumes all calls involving a telephone use
CPND

- Converged Desktop percentage: 5% of the following calls: (intraoffice calls × 0.1) +

incoming calls + outgoing calls + tandem calls
- Intraoffice CDR: No (could be yes, but not typical)
- Incoming CDR: Yes
- Outgoing CDR: Yes
- Tandem CDR: Yes
- Symposium-processed ACD calls: 90%
- ACD calls without Symposium: 10%
Real time factors are based on Table 52: Real time factors on page 258.
Calculations
The calculations in this example were performed by spreadsheet. Some rounding off may have
occurred.
• The percentage of ACD agent to total telephones = (50 + 170) ÷ (1200 + 1600 + 1200 +
200) × 100 = 5.238 % This ratio is less than the 15% threshold, so the site is not considered
a call center. All ACD traffic will be included in call distribution calculations. For more
information, see DSP ports for general traffic on page 266. The following calculations use
the default nonblocking telephone CCS rate of 18 CCS.
• LTDM TDM telephones CCS = [(1200 – 170) × 5] + (170 × 18) = 8210 CCS
• LIP IP telephones CCS = (1600 – 50) × 5 = 7750 CCS
- LACD TDM ACD agent CCS = 170 × 33 = 5610 CCS
- LACDIP IP ACD agent CCS = 50 × 33 = 1650 CCS
- LDECT DECT telephones CCS = 200 × 5 = 1000 CCS
- LSIPL SIP Line telephones CCS = 1200 × 5 = 6000 CCS
- ACDadj ACD CCS adjustment for TDM agents = 170 × 18 = 3060 CCS
- LCCS Total line CCS = 8210 + 7750 + 5610 + 1650 + 1000 + 6000 + 3060 = 27160
CCS
• TTDM TDM trunk CCS = 370 × 28 = 10360 CCS
- HVTCCS H.323 trunk CCS = 300 × 28 = 8400 CCS
- SVTCCS SIP trunk CCS = 150 × 28 = 4200 CCS
- VTCCS Total Virtual Trunk CCS = 8400 + 4200 = 12600 CCS
- TTCCS Total Trunk CCS = 12600 + 10360 = 22960 CCS
• Fraction of H.323 CCS of total Virtual Trunk CCS (VH) = 8400 ÷ 12600 = 0.67
• Fraction of SIP CCS of total Virtual Trunk CCS (V S) = 4200 ÷ 12600 = 0.33

Calculations
• Fraction of Virtual Trunk CCS of total trunk CCS (V) = 12600 ÷ 22960 = 0.549
• Fraction of UNIStim IP CCS (PU) = (7750 + 1650) ÷ 27160 = 0.346
• Fraction of SIP CCS (PS) = 6000 ÷ 27160 = 0.221
• Fraction of IP CCS (PIP) = 0.346 + 0.221 = 0.561
• Weighted average holding time (WAHT) = (60 × 0.25) + (150 × 0.60) + (150 × 0.12) +
(150 × 0.12) + (180 × 0.03) = 128 seconds
• CP1 local CallPilot CCS = 36 × 36 = 936
• CP2 network CallPilot CCS = 24 × 26 = 624
• Total CCS (TCCS) = LCCS + TTCCS = 27160 + 22960 = 50120 CCS
• Total calls (TCALL) = 0.5 × TCCS × 100 ÷ WAHT = 0.5 × 50120 × 100 ÷ 128 = 19578
• The system calls are comprised of four different types of traffic: Intraoffice calls
(telephone-to-telephone) (CSS); Tandem calls (trunk-to-trunk) (CTT); Originating/Outgoing
calls (telephone-to-trunk) (CST); Terminating/Incoming calls (trunk-to-telephone) (CTS).
a. Intraoffice calls (CSS) = TCALL × RI = 19578 × 0.25 = 4895 calls
i. Intraoffice UNIStim IP to UNIStim IP calls (C 2IP) = CSS × PU × PU =
4895 × 0.346 × 0.346 = 586 (require no DSP, no VT) P_UIPtoUIP
= 586 ÷ 19578 = 0.03
ii. Intraoffice UNIStim IP to TDM calls (C 1IP) = CSS × 2 × PU × (1 – PU)
= 4895 × 2 × 0.346 × (1 – 0.346) = 1467 (require DSP) P_UIPtoL =
1467 ÷ 19578 = 0.07
iii. Intraoffice TDM to TDM calls (C NoIP) = CSS × (1 – PIP)2 = 4895 × (1
– 0.567) × (1 – 0.567) = 918 (require no DSP, no VT) P_LtoL = 918
÷ 19578 = 0.05
iv. Intraoffice SIP Line to SIP Line calls (C 2sip) = CSS × PS2 = 4895 ×
0.221 × 0.221 = 239 (require no DSP, no VT) P_SIPtoSIP = 239 ÷
19578 = 0.01
v. Intraoffice SIP Line to UNIStim IP calls (C 2sipuip) = CSS × PS × PU =
4895 × 0.221 × 0.346 = 748 (require no DSP, no VT) P_SIPtoUIP
= 748 ÷ 19578 = 0.04
vi. Intraoffice SIP Line to TDM calls (C 1sip) = CSS × 2 × PS × (1 - PIP)
= 4895 × 2 × 0.221 × (1 - 0.567) = 936 (require DSP, no VT)
P_SIPtoL = 918 ÷ 19578 = 0.05
b. Tandem calls (CTT) = TCALL × RT = 19578 × 0.03 = 587 calls
i. Tandem VT to TDM calls (C T1VT) = 2 × CTT × V × (1 – V) = 2 × 587
× 0.549 × (1 – 0.549) = 291 (require DSP and VT) P_VTtoTr = 291
÷ 19578 = 0.0015
ii. Tandem TDM to TDM calls (C T2NoVT) = CTT × (1 – V) × (1 – V) = 587
× (1 – 0.549) × (1 – 0.549) = 120 (require no DSP, no VT) P_TrtoTr
= 120 ÷ 19578 = 0.006

iii. Tandem VT (H.323) to VT (SIP) calls (C T2HS) = CTT × V2 × VH × VS

× 2 × 2 = 587 × 0.549 × 0.549 × 0.67 × 0.33 × 4 = 157 (require no
DSP, VT) P_VhtoVs = 157 ÷ 19578 = 0.008
c. Originating/outgoing calls (CST) = TCALL × O = 19578 × 0.12 = 2349 calls
i. UNIStim IP to VT calls (C STIV) = CST × PU × V = 2349 × 0.346 ×
0.549 = 446 (require VT) P_UIPtoVT = 446 ÷ 19578 = 0.02
ii. UNIStim IP to TDM trunk calls (C STID) = CST × PU × (1 – V) = 2349
× 0.346 × (1 – 0.549) = 367 (require DSP) P_UIPtoTr = 367 ÷ 19578
= 0.02
iii. TDM telephone to VT calls (CSTDV ) = CST × (1 – PIP) × (V) = 2349
× (1 – 0.567) × 0.549 = 558 (require DSP, VT) P_LtoVT = 558 ÷
19578 = 0.03
iv. TDM to TDM calls (CSTDD) = CST × (1 – PIP) × (1 – V) = 2349 × (1
– 0.567) × (1 – 0.549) = 459 (require no DSP, no VT) P_LtoTr = 459
÷ 19578 = 0.02
v. SIP Line to VT calls (C STSV) = CST × PS) × V = 2349 × 0.221 × 0.549
= 285 (require no DSP, VT) P_SIPtoVT = 285 ÷ 19578 = 0.01
vi. SIP Line to TDM trunk calls (C STSD) = CST × PS) × (1 - V) = 2349 ×
0.221 × (1 - 0.549) = 234 (require DSP, no VT) P_SIPtoTr = 234 ÷
19578 = 0.01
d. Terminating/incoming calls (CTS) = TCALL × I = 19578 × 0.60 = 11747 calls
i. VT to TDM telephone calls (C TSVD) = CTS × V × (1 – PIP) = 11747
× 0.549 × (1 – 0.567) = 2791 (require DSP, VT) P_VTtoL = 2791 ÷
11747 = 0.14
ii. VT to UNIStim IP calls (C TSVI) = CTS × V × PU = 11747 × 0.549 ×
0.346 = 2231 (require VT) P_VTtoUIP = 2231 ÷ 11747 = 0.11
iii. TDM to UNIStim IP calls (CTSDI) = CTS × (1 – V) × PU = 11747 × (1
– 0.549) × 0.346 = 1834 (require DSP) P_TrtoUIP= 1834 ÷ 11747
= 0.09
iv. TDM to TDM telephone calls (CTSDD ) = CTS × (1 – V) × (1 – PIP) =
11747 × (1 – 0.549) × (1 – 0.567) = 2295 (require no DSP, no VT)
P_LtoL = 2295 ÷ 11747 = 0.12
v. VT to SIP Line calls (C TSVS ) = CTS × V × PS = 11747 × 0.549 ×
0.221 = 1424 (require no DSP, VT) P_VTtoSIP = 2424 ÷ 11747 =
0.07
vi. TDM trunk to SIP Line calls (CTSDS ) = CTS × (1 - V) × PS = 11747
× (1 - 0.549) × 0.221 = 1171 (require no DSP, no VT) P_TrtoSIP =
2287 ÷ 11747 = 0.06
• From the above data, the weighted average penetration factor (PF) is:
PF = (P_UIPtoUIP × f1) + (P_UIPtoL × f 2) + (P_LtoL × f 3) + (P_VTtoTr × f4) + (P_TrtoTr ×
f5) + (P_VhtoVs × f6) + (P_UIPtoVT × f7) + (P_UIPtoTr × f8) + (P_LtoVT × f9) + (P_LtoTr
× f10) + (P_VTtoL × f 11) + (P_VTtoUIP × f12) + (P_TrtoUIP × f13) + (P_TrtoL × f 14) +
(P_SIPtoSIP × f15) + (P_SIPtoUIP × f16) + (P_SIPtoL × f 17) + (P_SIPtoVT × f18) +
(P_SIPtoTr × f19) + (P_VTtoSIP × f20) + (P_TrtoSIP × f21) = (0.03 × 0) + (0.07 × 1.41) +

Real time calculation with major applications
(0.05 × 0.81) + (0.015 × 1.14) + (0.006 × 1.20) + (0.008 × 1.09) + (0.02 × 1.20) + (0.02 ×
1.16) + (0.03 × 2.44) + (0.01 × 1.25) + (0.14 × 1.72) + (0.11 × 0.97) + (0.09 × 1.25) + (0.12
× 1.34) + (0.01 × 2.72) + (0.04 × 1.36) + (0.05 × 1.78) + (0.01 × 1.97) + (0.01 × 2.25) +
(0.07 × 2.17) + (0.06 × 3.57) = 1.552
• Calculate the System EBC SEBC = (TCALL × (1 + PF + Error_term)) = 19578 × (1 + 1.552
+ 0.25) = 54854
Real time calculation with major applications

• ACD agent calls without Symposium CACD = [(LACD + LIPACD) × 100 ÷ AHT AGT] = (5610
× 1650) × 100 ÷ 180 = 4033
• Calculate the impact of other major features and applications.
You can use Table 66: Feature and application EBC calculation on page 313 to calculate
the EBC for your features and applications.
Table 66: Feature and application EBC calculation
Feature or application EBC calculation forumula EBC

ACD ACDEBC = CACD × (1 - = 4033 × 0.1 × 0.13 =
%Symposium) × fACD 52
Symposium SymposiumEBC = %Symposium = 4033 × 0.9 × 5.74 =
× CACD × fSYM 20836
CallPilot CallPilotEBC = (CP1 + CP2) × 100 = (936 + 624) × 100 ÷
÷ AHT CP × fCP 40 × 1.66 = 6474
Incoming CDR IncomingCDR_EBC = CTS × fCCDR = 11747 × 0.32 = 3759
Outgoing CDR OutgoingCDR_EBC = CST × fOCDR = 2349 × 0.32 = 752
Tandem CDR TandemCDR_EBC = CTT × fTAN = 587 × 0.44 = 258
Integrated Conference MICB_EBC = number of = 16 × 26 × 100 ÷
Bridge Integrated Conference Bridge 1800 × 1.56 = 37
ports × Appl CCS × 100 ÷ AHT MICB
× fMICB
Integrated Recorded MIRAN_EBC = number of = 12 × 26 × 100 ÷ 90
Announcer Integrated Recorded Announcer × 0.63 = 218
ports × Appl CCS × 100 ÷ AHT MIRAN
× fMIRAN
Integrated Call Director MIPCD_EBC = number of = 12 × 26 × 100 ÷ 60
Integrated Call Director ports × × 0.63 = 328
ApplCCS × 100 ÷ AHT MIPCD ×
fMIPCD

Feature or application EBC calculation forumula EBC

Integrated Call MIPA_EBC = number of = 8 × 26 × 100 ÷ 180
Announcer Integrated Call Announcer ports × × 0.57 = 66
ApplCCS × 100 ÷ AHT MICA × fMICA
Hospitality Integrated MIVS_EBC = number of = 8 × 26 × 100 ÷ 90 ×
Voice Service Hospitality Integrated Voice 0.57 = 132
Service ports × Appl CCS × 100 ÷
AHTMIVS × fMIVS
BRI BRI_EBC = number of BRI users = 8 × 5 × 100 ÷ 180 ×
× TelephoneCCS × 100 ÷ AHT BRI × 0.12 = 3
fBRI
MDECT MDECT_EBC = LDECT × 100 ÷ = 1000 × 100 ÷ 128 ×
WAHT × fDECT 4.25 = 3320
CPND CPND_EBC = (CSS + CTS) × fCPND = (4895 + 11747) ×
0.2 = 3328
Converged Desktop CD_EBC = (CSS × 0.1 + CTT + CST = (4895 × 0.1 + 587 +
+ CTS) × rDTP× fDTP 2349 + 11747) × 0.05
× 2.33 = 1768
Features and Applications FAEBC = ACD_EBC + = 41332
EBC Symposium_EBC +
CallPilot_EBC +
InternalCDR_EBC +
IncomingCDR_EBC +
OutgoingCDR_EBC +
TandemCDR_EBC + MICB_EBC
+ MIRAN_EBC + MIPCD_EBC +
MICA_EBC + MIVS_EBC +
BRI_EBC + MDECT_EBC +
CPND_EBC + CD_EBC +
MO_EBC + IPSEC_EBC +
MC3100_EBC + MobileX_EBC +
ELC_EBC
New system real-tme usage

Compare the total system EBC with the CPU rated capacity to determine the processor
utilization.
RTU = (SEBC + FAEBC) ÷ BHCC × 100 = (54854 + 41332) ÷ 840 000 × 100 = 12.8 %
In this example, CPU utilization, including application and feature impact, is 12.8 %. This
loading indicates that the CPU can handle this configuration with ease and has plenty of spare
capacity.


If you upgrade a system, in addition to the new load from the above calculation, the CPU
utilization data from a current traffic report TFS004 is also required.
Assume you upgrade a system from Communication Server 1000 Release 4 with CP PII to
Communication Server 1000 Release 7.5 with CP PIV, when the TFS004 reading is 60%.
From Table 54: Software release degradation factors (SWRC) on page 263 and Table 55: Ratio
of existing processor capacity to new processor capacity (CPTU) on page 263:
SWRC = 55 CPTU = 0.32
The calculation to convert the loading is:
CRTU = (60 ÷ 100) × [1 + (55 ÷ 100)] × 0.32 = 0.298
29.8% of the new system CPU (CP PIV) must be reserved to handle calls of the existing site.
The expected total CPU utilization is (26.7 + 12.8) = 41.6% .
DSP calculation for conference ports

The formula to calculate the DSP requirement for conference ports is based on the number of
telephones in the system:
Number of conference ports = Total_telephones × rCon × 0.4 = 4208 × 0.07 × 0.4 = 207
Number of conference loops = ROUNDUP (conference ports ÷ 30) = 207 ÷ 30 = 7
Number of DSP ports for conference = conference loops × 32) = 7 × 32 = 224
DSP calculation for features and applications

Table 67: DSP ports for features and applications
Feature or application Number of ports DSP

Integrated Conference Bridge 16 16
Integrated Recorded 12 (only 12 listeners) 12
Announcements
Integrated Call Director 12 12

Feature or application Number of ports DSP

Integrated Call Assistant 8 8
Hospitality Integrated Voice 8 8
Service
BRI 8 16
Agent greeting 4 4
CallPilot 60 60
Total 136
The general formula for
calculating CS 1000E DSP for
features and applications is: DSP
= number of application ports
DSP for BRI = 2× the number of
BRI ports
DSP and Media Card calculations

Total DSP ports = DSP for calls + Conference + Applications/features = 384 + 67 + 73 = 524
Number of 32-port Media Cards required = 524 ÷ 32 = 17
For an 8-port Media Card, number of Media Cards required = 524 ÷ 8 = 66
It is recommended to round up the Media Card calculation to an integer.
See Simplified Media Gateway DSP calculations on page 268 and Table 97: Worksheet B:
Detailed DSP and Media Card calculation for Media Gateway on page 402 to determine the
card placement and DSP port requirements for each Media Gateway chassis.
Virtual trunk calculation

VT calls (CVT) = CT1VT + CSTIV + CSTDV + CTSVD + CTSVI + CT2HS + CSTSV + CTSVS= 8184
H.323 VT calls (HCVT) = CVT × VH = 8184 × 0.67 = 5484
SIP VT calls (SC VT) = CVT × VS = 8184 × 0.33 = 2701
VTCCS = CVT × WAHT ÷ 100 = 8184 × 128 ÷ 100 = 10476 CCS
Refer to a Poisson table (with P.01 GoS) to find the corresponding number of trunks, or use
the following formula:

Signaling Server calculation
Number of Virtual Trunks = VTCCS ÷ 5804 × 192 = 347

Number of H.323 Virtual Trunks = 347 × 0.67 = 233
Number of SIP Virtual Trunks = 347 × 0.33 = 115
User input for number of Virtual Trunks is 450. Since this is greater than 347, 450 is the number
you use for further resource calculation.

The following information was obtained from previous calculations or input data:
Signaling Server [type_index = CP PM]

Number of IP Phones in the system (IPL) = 1600 Number of SIP Line Phones in the
system (SIPL) = 1200 Number of Virtual Trunks = 450 (H.323 = 300; SIP = 150) HVT
= 300 SVT = 150 Calls involving at least one IP Phone (C UIP) = 8267 Calls involving at
least one SIP Line Phone (CSIP) = 5277 Calls involving Virtual Trunks (CVT) = GKC0
= 8184
The following is additional user input to the EC tool:
Endpoints served by this NRS: 100 NRS entries (CDP + UDP + É): 1000 Virtual Trunks
from other endpoints served by this NRS: 800 NRS alternate (NRA): Yes TPSA (TPS
N+1 redundancy required): Yes H.323 Gateway alternate (GWA): Yes SIP Gateway
alternate (GSA): Yes PD/CL/RL feature available to IP Phones: Yes Sharing Database
with other traffic: Yes SIP Proxy or SIP Redirect: Proxy SIP Proxy TCP: Yes SIP Line
Alternate (SIPLA) :Yes
1. Signaling Server CP PM Co-resident Call Server and Signaling Server

Determine if you require a CP PM Co-resident Call Server and Signaling Server.
The system_type is not CP PM Co-res CS and SS. Follow the Signaling Server
algorithm to determine the number of Signaling Servers required.
2. Signaling Server for Personal Directory/Callers List/Redial List
SSDB = b
The database share limit for type_index = CP PM is 2000 IP Phones.
3. Network Routing Service calculations
Dedicated NRS not required, nrs_type_index = type_index = CP PM

SIP Proxy with TCP protocol is required

NRS_EP_limit = SIP_Proxy_limit = 1000

SSNR[nrs_type_index] = larger of:
{
a NRE[nrs_type_index] ÷ NRE_EP_limit = 800 ÷ 1000 = 0.8 endpoints
b NRD[nrs_type_index] ÷ NRD[nrs_type_index] = 1000 ÷ 50 000 = 0.02
dial plan entries
c NRC[nrs_type_index] ÷ NRCHL[nrs_type_index] = 23486 ÷ 200 000 =
0.15 calls per hour
d 0 if NRS is not provisioned and there is no branch office = 0
e If (NRE > NRESL[nrs_type_index] or NRD > NRDSL[nrs_type_index] or
NRC > NRCSL[nrs_type_index]) then 1 else 0 If (800 > 100 or 1000 >
5000 or 28436 > 200 000) evaluates true = 1
}
SSNR[CP PM] = 1
If SSNR[nrs_type_index] >= 1 or dedicated NRS required
1 >= 1 evaluates true
Then { SSNW = ROUNDUP(SSNR) × NRA (= 2 if true, else 1) = 1 × 2 = 2
SST[nrs_type_index] = SST[nrs_type_index] + SSNW;
SST[CP PM] = 0 + 2 = 2
}
NRC could be hardware or CPU or memory limit, it includes local NRC0 (calls from
main switch calculation) and network VTNET for the NRS:. NRC = NRC0 + NRCNET
Both VT323 and VTSIP from user input must convert to H.323 and SIP calls.
H.323 calls = VT323 × CCS × 100 ÷ WAHT = 300 × 28 × 100 ÷ 128 = 6562
SIP calls = VTSIP × CCS × 100 ÷ WAHT = 150 × 28 × 100 ÷ 128 = 3281
Determine the SIP loading factor on the NRS:
Factor = if SIP_mode = Proxy, then 4
NRC0 = (H323 calls × Factor × SIP calls) = 6562 + 4 × 3281 = 19686
NRCNET = (VTNET × CCS for each VT × 100 ÷ WAHT ÷ 2) = 800 × 28 × 100 ÷ 128
÷ 2 = 8750
NRC = NRC0 + NRCNET = 19686 + 8750 = 28436
Formula (c) in SSNR equation = NRC ÷ NRCHL[nrs_type_index] = 28436 ÷ 200 000
= 0.15

4. Terminal Proxy Server calculations
Calculate TPS call rate:

CUIP = C2UIP × 2 + C1UIP + C2SIPUIP + CSTIV + CSTID + CSTVI + CSTDI
CUIP = 8267
SSTR[type_index] = larger of:
{
a IPL ÷ IPL SL[type_index] = 1600 ÷ 5000 = 0.32
b CUIP ÷ IPCHL[type_index] = 8267 ÷ 40 000 = 0.2
c If IPL > IPL DB then 1 else 0 1600 > 2000 evaluates false = 0
}
SSTR[CP PM] = 0.32
If SSTR[type_index] >= 1 or dedicated TPS required
0.32 >= 1 evaluates false and dedicated not required
Else { If SSTR[type_index] > 0
0.32 > 0 evaluates true
Then { TPS_Co-res = true; NumOfCo-res = NumOfCo-res + 1
= NumOfCo-res = 0 + 1 = 1
}
}
5. H.323 Gateway calculations
HCVT = (HVTCCS × 100) ÷ WAHT

= (8400 × 100) ÷ 128
= 6562
SSHR[type_index] = larger of:
{
a HVT[type_index] ÷ HVTSL[type_index] = 300 ÷ 1200 = 0.25
b HCVT[type_index] ÷ HVTCHL[type_index] = 6562 ÷ 18 000 = 0.36
c If HVT > VTRKSL[type_index] then 1 else 0 300 > 800 evaluates false
=0
}
SSHR[CP PM] = 0.36
If SSHR[type_index] >= 1 or dedicated H323 GW required


Else { If SSHR[type_index] > 0
0.36 > 0 evaluates true
Then { H323_Co-res = true; NumOfCo-res = NumOfCo-res + 1
= NumOfCo-res = 1+ 1 = 2
}
}
6. SIP Gateway calculations
SCVT = (SVTCCS × 100) ÷ WAHT

= (4200 × 100) ÷ 128
= 3500
SSSR[type_index] = larger of:
{
a SVT[type_index] ÷ SVTSL[type_index] = 150 ÷ 1800 = 0.08
b SCVT[type_index] ÷ SVTCHL[type_index] = 3500 ÷ 27 000 = 0.13
c SVT > VRTKSL[type_index] then 1 else 0 150 > 800 evaluates false =
0
}
SSSR[CP PM] = 0.13
If SSSR[type_index] >= 1 or dedicated SIP GW required
Else { If SSSR[type_index] > 0
Then { SIP_Co-res = true; NumOfCo-res = NumOfCo-res + 1
= NumOfCo-res = 2+ 1 = 3
}
}
7. SIP CTI/TR87 calculations

No SIP CTI/TR87 specified.
8. Signaling Server Co-resident calculations
Determine if any Signaling Server applications can co-reside on one Signaling

Server
Case of NumOfCo-res:

NumOfCo-res = 3, evaluate the portion if more than one Signaling

Server application is Co-resident
Determine if Co-resident VRTK exceeds limit
If H323_Co-res = true and SIP_Co-res = true and (HVT + SVT >
VTSL[type_index]) H323_Co-res = true and SIP_Co-res = true and (300
+ 150) > 800) This evaluates false;
If NumOfCo-res = 0, then exit NumOfCo-res = 3, evaluates false
Else If NumOfCo-res = 1, then do, one Signaling Server application - assign
one Signaling Server NumOfCo-res = 3, evaluates false
Else { CallRate = 0;
If NRS_Co-res = true, then CallRate = CallRate + NRC; NRS_Co-res
evaluates false
If TPS_Co-res = true, then CallRate = CallRate + CUIP; TPS_Co-res
evaluates true, CallRate = 8267;
If H323_Co-res = true, then CallRate = CallRate + HCVT; H323_Co-res
evaluates true, CallRate = 8267 + 6562 = 14829;
If SIP_Co-res = true, then CallRate = CallRate + SCVT; SIP_Co-res
evaluates true, CallRate = 14829 + 3500 = 18329;
If CallRate <= Co-resCR[type_index] 18329 <= 20000 Co-res CallRate
limit met
Then { SST[type_index] = SST[type_index] +1; SST[CP PM] = 1 + 1 = 2;
Since one of the following evaluates true; SST[CP PM] = 2 + 1 = 3
If (NRS_Co-res = true and NRA = true) or (TPS_Co-res = true and TPSA
= true) or (H323_Co-res = true and GWA = true) or (SIP_Co-res = true
and GSA = true) or (TR87_Co-res = true and TR87A = true)
Then SST[type_index] = SST[type_index] + 1;
}
}
}
9. SIP Line Gateway calculations
SIPL = SIPN + SIP3, where SIPL = total number of SIP Phones SIPL = 1200
Calculate total number of SIP Line calls
CSIP = (2 × C2SIP) + C1SIP + C2SIPUIP + CSTSV + CSTSD + CSTVS + CSTDS
CSIP = 5277
SSSLGR[type_index] = larger of:
{

a SIPL ÷ SIPL SL[type_index] = 1200 ÷ 1000 = 1.2

b CSIP ÷ SIPLCHL[type_index] = 5277 ÷ 10000 = 0.53
}
SSSLGR[CP PM] = 1.2
Round up SSLGR before you proceed with the calculations
SSSLGW[type_index] = ROUNDUP(SSSLGR[type_index] ×
SIPLA[type_index] (= 2 if true, else 1)
SIPLA = if redundant SIPL is needed
SSSLGW[CP PM] = 2 × 2 = 4
SST[type_index] = SST[type_index] + SSSLGW; SST[CP PM] = 3 + 4 =
7
10. SIP DECT calculations

No SIP DECT Phones required.
11. Total Signaling Server requirement
The total number of Signaling Servers provisioned:
SST[type_index] = 6, and If nrs_type_index and type_index are not the same, then
SST[nrs_type_index], else 0 nrs_type_index [CP PM] = type_index [CP PM]
evaluates 0, and Signaling Servers for SIP DECT = SS_DECT = 0
LAN/WAN bandwidth calculation algorithm

The calculation for LAN/WAN bandwidth requirement is based on traffic directly. It does not
depend on the traffic model used.
VT traffic in erlangs = [(240 + 120) × 28] ÷ 36 = 280 erlangs

Chapter 15: Application engineering
Contents
Access Restrictions on page 324
Converged Desktop on page 325
Exchange 2007 Unified Messaging SIP trunk provisioning on page 332
Microsoft Office Communications Server users on page 333
Mobile Extension engineering on page 338
D-channel on page 340
D-channel handler engineering procedure on page 351
Avaya CallPilot engineering on page 356
Call Center on page 357
Symposium Call Center on page 359
ELAN engineering on page 360
HSP LAN Engineering on page 365
CLASS network engineering rules on page 368
Configuration parameters on page 370
Media Application Server (MAS) on page 371
Introduction
Certain applications have significant capacity impact and require engineering in order to
operate properly from a capacity perspective. This section provides suggestions for
engineering these applications.

Application engineering
For descriptions of the features and their functionality, refer to feature documentation in the
Avaya publications.
For more information about voice networks, see Avaya Converging the Data Network with VoIP
Access Restrictions
The Access Restrictions feature, also known as the port blocking facility is a VxWorks-based
firewall designed to prevent port-based attacks on the CP PIV, MGC, and MC32S running
VxWorks software. Access Restrictions use port blocking rules for accepting or rejecting
packets to open ports. The port blocking rules are preconfigured during installation and
distribute from the Call Server to the MGC and MC32S. You can customize the port blocking
rules post installation with Overlay 117 or EM.
Adding port blocking rules increases CPU utilization. Avaya recommends you to maintain
minimal port blocking rules to minimize the CPU performance impact. Access Restrictions
provide a minimum but essential firewall to secure the VxWorks platforms. If you require a full
firewall, Avaya recommends the use of a dedicated third-party hardware firewall.
CPU utilization depends on the type and amount of rules configured. Table 68: CP PIV packet
throughput drop at 10 percent CPU utilization on page 324 provides an example of the CP
PIV performance drop with increasing rule depth.
Table 68: CP PIV packet throughput drop at 10 percent CPU utilization
Rule Depth 60 byte packet, 60 byte packet, 60 byte packet, 60 byte packet,
reject at end. accept at rule. accept at rule. accept at rule.
(packets/ (packets/ CPU utilization CPU utilization
second) second) drop against no drop against
firewall. accept all
default rule.
No firewall 66 500 66 500 0 n/a
0 64 000 57 000 14.3% 0
1 57 000 51 000 23.3% 10.5%
4 52 000 48 000 27.8% 15.8%
8 43 000 41 000 38.3% 28.1%
16 35 000 33 000 50.4% 42.1%
32 24 750 25 000 62.4% 56.1%
64 13 250 13 500 79.7% 76.3%
128 7 500 7 500 88.7% 86.8%

Converged Desktop
Converged Desktop
The Converged Desktop is a TDM or IP Phone configured to access Avaya Multimedia
Communication Server 5100 (Avaya MCS 5100) multimedia applications through a Session
Initiation Protocol (SIP) Virtual Trunk.
Maximum number of Converged Desktop users

In a pure IP system, the Avaya Communication Server 1000E (Avaya CS 1000E) can support
up to 10 000 Converged Desktop users. However, for a new installation, Avaya recommends
configuring no more than 7000 IP users with the Converged Desktop application. This reserves
a reasonable amount of real time capacity for future growth.
SIP access port requirement

Every Converged Desktop call uses a SIP trunk for signaling during the ringing period. In
addition, a certain percentage of calls use the SIP trunk for voice traffic for the entire duration
of the call. Therefore, the required number of SIP access ports depends on the number of
Converged Desktop users and the percentage of voice calls using SIP trunks for
conversation.
Personal Call Assistant requirement

The following types of calls to a Converged Desktop use the Personal Call Assistant (PCA)
feature for the duration of ringing time:
• calls originating from an internal phone
• calls originating from any nonSIP trunk
• calls originating from a SIP trunk but not from an MCS 5100
The PCA requirement depends only on the number of Converged Desktop users. It is
independent of the percentage of voice calls using SIP trunks for conversation.
Calculating SIP access port and PCA requirements

Table 69: SIP port and PCA requirements for Converged Desktop (with P.01 GoS) on page 327
shows the required number of SIP access ports and PCAs for different levels of Converged
Desktop usage, with P.01 Grade-of-Service (GoS).

The columns under "% voice traffic carried by SIP trunk" indicate the fraction of calls that use
a SIP trunk for conversation. A percentage of zero means that the SIP port is used only for
signaling during the ringing period and is dropped from the connection once the call is
answered.
To use the table, users must know (1) the number of Converged Desktop users and (2) the
percentage of Converged Desktop users using SIP trunks to carry voice traffic. The readings
below the percentage column are the number of SIP trunks and PCA ports required for a given
number of Converged Desktop users.
The number of users shown in Table 69: SIP port and PCA requirements for Converged
Desktop (with P.01 GoS) on page 327 increments by increasingly large amounts as the
number of users increases. If you are calculating requirements for a number of users not shown
in the table, use the following formula:
Inputs
• Total number of Converged Desktop users required (MCS_CD_Users)
• Percentage of calls that are answered on a soft client configured as a Converged Desktop
(P_CD_SIP)
• Total Number of nonconverged desktop users required (MCS_Non_CD_Users)
• Number of Meet-Me Audio Conference ports configured on the MCS (MeetMe_Ports)
Calculations
• Traffic for CD = (MCS_CD_Users) x (CCS per user) x 10%
• Traffic for SIP ports = (MCS_Non_CD_Users) x (CCS per user) + (MCS_CD_Users x
P_CD_SIP) x (CCS per user)
• Total SIP Traffic = (Traffic for CD) x (1 - P_CD_SIP) + (Traffic for SIP ports)
• Number of SIP ports = Poisson (Total SIP Traffic) at P.01 + MeetMe_Ports
• Number of MCS PC As ports = Poisson (Traffic for CD) at P.01
• Number of ACD agents = Number of MCS PCAs ports
If detailed information about the network is not available, use the following formula to estimate
the percentage of Converged Desktop users using SIP trunks to carry voice traffic, rounding
up the result:
(Number of SIP trunks) ÷ [(Number of SIP trunks) + (Number of H.323 trunks)]
Assumptions
1. The ringing period is 10% of the conversation time. (One ring is a 6-second cycle;
the ringing period is usually 2–3 rings; average conversation time is 120–180
seconds.)
2. PCA holding time is equal to the length of the ringing period for each call. This is a
conservative assumption, because it implies that every call needs a PCA.

Converged Desktop
Example
Two hundred Converged Desktop users with 0% SIP trunk conversation require 8 SIP access
ports and 8 PCAs. If 20% use SIP for conversation, the requirements are 16 SIP access ports
and 8 PCAs.
Table 69: SIP port and PCA requirements for Converged Desktop (with P.01 GoS)
# CD % voice traffic carried by SIP trunk

Users 0 5 10 15 20 25 30 35 40 45 50 100
25 SIP 12 18 23 29 35.0 40.6 46.2 51.9 57.5 63.1 68.8 125
CC .5 .1 .8 .4 .0
S
SIP 3 4 4 4 5 5 5 6 6 6 7 9
port
PC 3 3 3 3 3 3 3 3 3 3 3 3
A
50 SIP 25 36 47 58 70.0 81.2 92.5 103 115 126 137 250
CC .0 .2 .5 .8 .8 .0 .2 .5 .0
S
SIP 4 5 6 6 7 7 8 8 9 9 10 15
port
PC 4 4 4 4 4 4 4 4 4 4 4 4
A
75 SIP 37 54 71 88 105 121 138 155 172 189 206 375
CC .5 .4 .2 .1 .0 .9 .8 .6 .5 .4 .2 .0
S
SIP 5 6 7 8 8 9 10 11 11 12 13 19
port
PC 5 5 5 5 5 5 5 5 5 5 5 5
A
100 SIP 50 72 95 117 140 162 185 207 230 252 275 500
CC .0 .5 .0 .5 .0 .5 .0 .5 .0 .5 .0 .0
S
SIP 6 7 8 9 10 11 12 13 14 15 16 24
port
PC 6 6 6 6 6 6 6 6 6 6 6 6
A
125 SIP 62 90 118 146 175 203 231 259 287 315 343 625
CC .5 .6 .8 .9 .0 .1 .2 .4 .5 .6 .8 .0
S


Users 0 5 10 15 20 25 30 35 40 45 50 100
SIP 6 8 9 10 12 13 14 15 16 17 18 29
port
PC 6 6 6 6 6 6 6 6 6 6 6 6
A
150 SIP 75 108 142 176 210 243 277 311 345 378 412 750
CC .0 .8 .5 .2 .0 .8 .5 .2 .0 .8 .5 .0
S
SIP 7 9 10 12 13 14 16 17 18 20 21 33
port
PC 7 7 7 7 7 7 7 7 7 7 7 7
A
175 SIP 87 126 166 205 245 284 323 363 402 441 481 875
CC .5 .9 .2 .6 .0 .4 .8 .1 .5 .9 .2 .0
S
SIP 8 9 11 13 14 16 18 19 20 22 23 37
port
PC 8 8 8 8 8 8 8 8 8 8 8 8
A
200 SIP 100 145 190 235 280 325 370 415 460 505 550 1000
CC .0 .0 .0 .0 .0 .0 .0 .0 .0 .0 .0 .0
S
SIP 8 10 12 14 16 18 19 21 23 24 26 42
port
PC 8 8 8 8 8 8 8 8 8 8 8 8
A
225 SIP 112 163 213 264 315 365 416 466 517 568 618 1125
CC .5 .1 .8 .4 .0 .6 .2 .9 .5 .1 .8 .0
S
SIP 9 11 13 15 17 19 21 23 25 27 28 46
port
PC 9 9 9 9 9 9 9 9 9 9 9 9
A
250 SIP 125 181 237 293 350 406 462 518 575 631 687 1250
CC .0 .2 .5 .8 .0 .2 .5 .8 .0 .2 .5 .0
S
SIP 9 12 14 16 19 21 23 25 27 29 31 50
port
PC 9 9 9 9 9 9 9 9 9 9 9 9
A

Converged Desktop

Users 0 5 10 15 20 25 30 35 40 45 50 100
300 SIP 150 217 285 352 420 487 555 622 690 757 825 1500
CC .0 .5 .0 .5 .0 .5 .0 .5 .0 .5 .0 .0
S
SIP 10 13 16 19 21 24 26 28 31 33 36 58
port
PC 10 10 10 10 10 10 10 10 10 10 10 10
A
400 SIP 200 290 380 470 560 650 740 830 920 101 110 2000
CC .0 .0 .0 .0 .0 .0 .0 .0 .0 0.0 0.0 .0
S
SIP 13 16 20 23 26 29 33 36 39 42 45 74
port
PC 13 13 13 13 13 13 13 13 13 13 13 13
A
500 SIP 250 362 475 587 700 812 925 103 115 126 137 2500
CC .0 .5 .0 .5 .0 .5 .0 7.5 0.0 2.5 5.0 .0
S
SIP 15 19 23 27 31 35 39 43 47 50 54 90
port
PC 15 15 15 15 15 15 15 15 15 15 15 15
A
750 SIP 375 543 712 881 105 121 138 155 172 189 206 3750
CC .0 .8 .5 .2 0.0 8.8 7.5 6.2 5.0 3.8 2.5 .0
S
SIP 19 26 32 37 43 49 54 60 65 71 76 129
port
PC 19 19 19 19 19 19 19 19 19 19 19 19
A
1000 SIP 500 725 950 117 140 162 185 207 230 252 275 5000
CC .0 .0 .0 5.0 0.0 5.0 0.0 5.0 0.0 5.0 0.0 .0
S
SIP 24 32 40 47 55 62 69 77 84 91 98 168
port
PC 24 24 24 24 24 24 24 24 24 24 24 24
A
1250 SIP 625 906 118 146 175 203 231 259 287 315 343 6250
CC .0 .2 7.5 8.8 0.0 1.2 2.5 3.8 5.0 6.2 7.5 .0
S


Users 0 5 10 15 20 25 30 35 40 45 50 100
SIP 29 38 48 57 66 75 84 93 102 111 120 205
port
PC 29 29 29 29 29 29 29 29 29 29 29 29
A
1500 SIP 750 108 142 176 210 243 277 311 345 378 412 7500
CC .0 7.5 5.0 2.5 0.0 7.5 5.0 2.5 0.0 7.5 5.0 .0
S
SIP 33 44 56 67 78 88 99 109 120 130 141 243
port
PC 33 33 33 33 33 33 33 33 33 33 33 33
A
1750 SIP 875 126 166 205 245 284 323 363 402 441 481 8750
CC .0 8.8 2.5 6.2 0.0 3.8 7.5 1.2 5.0 8.8 2.5 .0
S
SIP 37 51 63 76 89 101 113 126 138 150 162 280
port
PC 37 37 37 37 37 37 37 37 37 37 37 37
A
2000 SIP 100 145 190 235 280 325 370 415 460 505 550 10
CC 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 000
S .0
SIP 42 56 71 85 100 114 128 142 155 169 183 318
port
PC 42 42 42 42 42 42 42 42 42 42 42 42
A
2500 SIP 125 181 237 293 350 406 462 518 575 631 687 12
CC 0.0 2.5 5.0 7.5 0.0 2.5 5.0 7.5 0.0 2.5 5.0 500
S .0
SIP 50 68 86 104 121 139 156 173 190 207 224 392
port
PC 50 50 50 50 50 50 50 50 50 50 50 50
A
3000 SIP 150 217 285 352 420 487 555 622 690 757 825 15
CC 0.0 5.0 0.0 5.0 0.0 5.0 0.0 5.0 0.0 5.0 0.0 000
S .0
SIP 58 80 101 122 143 164 184 205 225 245 266 465
port
PC 58 58 58 58 58 58 58 58 58 58 58 58
A

Converged Desktop

Users 0 5 10 15 20 25 30 35 40 45 50 100
3500 SIP 175 253 332 411 490 568 647 726 805 883 962 17
CC 0.0 7.5 5.0 2.5 0.0 7.5 5.0 2.5 0.0 7.5 5.0 500
S .0
SIP 66 91 116 140 165 188 212 236 260 283 307 538
port
PC 66 66 66 66 66 66 66 66 66 66 66 66
A
4000 SIP 200 290 380 470 560 650 740 830 920 10 11 20
CC 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 100 000 000
S .0 .0 .0
SIP 74 103 131 158 186 213 240 267 294 321 347 611
port
PC 74 74 74 74 74 74 74 74 74 74 74 74
A
4500 SIP 225 326 427 528 630 731 832 933 10 11 12 22
CC 0.0 2.5 5.0 7.5 0.0 2.5 5.0 7.5 350 362 375 500
S .5 .0 .0
SIP 82 114 145 176 207 237 268 298 328 358 388 684
port
PC 82 82 82 82 82 82 82 82 82 82 82 82
A
5000 SIP 250 362 475 587 700 812 925 10 11 12 13 25
CC 0 5 0 5 0 5 0 375 500 625 750 000
S
SIP 90 125 160 194 228 262 295 329 362 395 428 757
port
PC 90 90 90 90 90 90 90 90 90 90 90 90
A
6000 SIP 300 435 570 705 840 975 11 12 13 15 16 30
CC 0 0 0 0 0 0 100 450 800 150 500 000
S
SIP 106 148 189 230 270 310 350 390 430 470 509 908
port
PC 106 106 106 106 106 106 106 106 106 106 106 106
A
7000 SIP 350 507 665 822 980 11 12 14 16 17 19 35
CC 0 5 0 5 0 375 950 525 100 675 250 000
S


Users 0 5 10 15 20 25 30 35 40 45 50 100
SIP 121 170 218 265 312 358 405 451 497 543 589 1057
port
PC 121 121 121 121 121 121 121 121 121 121 121 121
A
8000 SIP 400 580 760 940 11 13 14 16 18 20 22 40
CC 0 0 0 0 200 000 800 600 400 200 000 000
S
SIP 137 192 246 300 353 406 459 512 565 617 669 1205
port
PC 137 137 137 137 137 137 137 137 137 137 137 137
A
9000 SIP 450 652 855 10 12 14 16 18 20 22 24 45
CC 0 5 0 575 600 625 650 675 700 725 750 000
S
SIP 152 214 274 335 395 454 513 573 632 690 749 1354
port
PC 152 152 152 152 152 152 152 152 152 152 152 152
A
10 000 SIP 500 725 950 11 14 16 18 20 23 25 27 50
CC 0 0 0 750 000 250 500 750 000 250 500 000
S
SIP 168 236 303 369 436 502 568 633 698 767 834 1502
port
PC 168 168 168 168 168 168 168 168 168 168 168 168
A
Voice users in CCS = 5 CCS per user. Ratio of ringing time to holding time = 0.1.
Exchange 2007 Unified Messaging SIP trunk provisioning

For information about Exchange 2007 Unified Messaging SIP trunk provisioning, see Avaya
Communications Server 1000 with Microsoft Exchange Server 2007 Unified Messaging
Fundamentals, NN43001-122. Refer to the SIP provisioning guidelines section.

Microsoft Office Communications Server users

The Avaya Converged Office feature combines the business-grade telephony of the Avaya CS
1000 with the real time multimedia communication and the remote call control provided by
Microsoft® Office Communications Server (OCS) 2007. Avaya Converged Office comprises
the following components:
• Remote Call Control (RCC) with Session Initiation Protocol (SIP) Computer Telephone
Integration (CTI) TR/87 provides full Microsoft® Office telephony integration to control
business-grade telephones from within Microsoft® Office applications, as well as support
for a standards-based CTI interface defined by the TR/87 protocol.
• Telephony Gateway and Services provides a basic SIP Telephony Gateway for
connectivity between private and public telephony networks and Office Communicator
(OC) 2007 clients.
Trunking
To handle the traffic between the Communication Server 1000 and the Office Communications
Server 2007, you must configure sufficient SIP trunks and Universal Extensions (UEXT). The
number of additional SIP trunks needed is determined by:
The number of Office Communicator users using the SIP Gateway feature.
multiplied by:
The percentage of users expected to be on the phone at any given time.
For example, 100 Office Communicator SIP Gateway users × 10% on the phone at any given
time = 10 additional SIP trunks.
The percentage of users on a phone is decided by standard practice and the environment
involved (Call Center, Normal Office, and so on).
Telephony services (TLSV) has replaced Personal Call Assistant (PCA). TLSV extends the call
over a SIP trunk to the OCS client from the Communication Server 1000 system.
Calculating SIP access port and TLSV requirements

the following table defines the inputs used to calculate SIP access ports and TLSV
requirements.
Table 70: Inputs
Input Description

TN_MO_Users Total number of Office Communicator users

that utilize the SIP Access Ports for voice
services.
UEXT_MO_Users Number of Office Communicator users that
use Universal Extension (UEXT) with
Telephony Services (TLSV) subtype. The
UEXTs you require are additional to the
number of UEXTs indicated in the Enterprise
Configurator (EC) tool software.
P_UEXT_SIP Percentage of UEXT calls that use the soft
client to answer a call.
Calculations
Use the following formulas to calculate traffic requirements:
Traffic for UEXTs = (UEXT_MO_Users) × (CCS per user) × (1 - P_UEXT_SIP) × 10%
Traffic for SIP ports = (TN_MO_Users - UEXT_MO_Users) × (CCS per user) +
(UEXT_MO_Users × P_UEXT_SIP) × (CCS per user)
Total SIP Traffic = (Traffic for UEXTs) + (Traffic for SIP ports)
Number of MO SIP ports = Poisson (Total SIP Traffic) at P.01 Grade of Service
MO = Microsoft® Office Communicator
Table 71: Traffic figures on page 334 shows traffic in CCS and number of ports calculated
based on Poisson formula at P.01 Grade of Service.
Table 71: Traffic figures
Traffic (CCS) Traffic (Erlang) #Ports

5 0.14 2
10 0.28 3
15 0.42 3
20 0.56 4
25 0.69 4
30 0.83 4
35 0.97 5
40 1.11 5
45 1.25 5
50 1.39 6
55 1.53 6

60 1.67 6
65 1.81 6
70 1.94 7
75 2.08 7
80 2.22 7
85 2.36 7
90 2.5 8
95 2.64 8
100 2.78 8
125 3.47 9
150 4.14 10
175 4.86 12
200 5.56 13
225 6.25 14
250 6.94 15
275 7.64 16
300 8.33 17
325 9.03 18
350 9.72 19
375 10.42 19
400 11.11 20
425 11.81 21
450 12.5 22
475 13.19 23
500 13.89 24
550 15.28 26
600 16.67 28
650 18.06 29
700 19.44 31
750 20.83 33
800 22.22 35
850 23.61 36

900 25 38
950 26.39 40
1000 27.78 42
1500 41.67 58
2000 55.56 74
2500 69.44 90
3000 83.33 106
3500 97.22 121
4000 111.11 137
4500 125 152
5000 138.89 168
6000 166.67 198
7000 194.44 228
8000 222.22 258
9000 250 288
10000 277.78 318
20000 555.56 611
30000 833.33 908
40000 1111.11 1205
50000 1388.89 1502
60000 1666.67 1799
70000 1944.44 2096
Basic Client Configuration

The Basic Client Configuration (BCC) can program the new TLSV subtype for UEXT TNs. All
UEXTs associated with OCS 2007 require the TLSV subtype.
LD 11 supports the administration of telephones. BCC uses REQ commands, such as NEW,
CHG, and OUT. In LD 20, BCC uses the PRT command to retrieve phones from the Call
Server.

Port use
The Communication Server 1000 uses the following ports for TCP and TLS:
• 5060: TCP
• 5061: TLS
The dynamic port range Office Communicator uses for SIP and RTP is 1024 - 65535. You can
restrict the port range with group policy settings. Port ranges must not overlap. For more
information, see the help and support page on the Microsoft Web site at http://
www.microsoft.com.
SIP CTI/TR87
When planning for capacity with SIP CTI services, observe the following fundamental
restriction:
For a single call server that supports multiple nodes, each with SIP CTI services enabled,
multiple SIP CTI/TR87 sessions can be established for a given DN through the same node,
but not through different nodes.
To illustrated this restriction, consider the following high-level example:
Client A sends a TR/87 SIP INVITE to Node 1 to monitor DN 1000. The TR/87 association is
established. Client B then sends a TR/87 SIP INVITE to Node 1 (the same node) to monitor
DN 1000. Both sessions are established successfully. As a result of this sequence, two TR/87
sessions exist for DN 1000 through Node 1.
However, if Client B attempts to send a TR/87 SIP INVITE to Node 2 (that has an AML link to
the same call server as Node 1), the attempt to establish the TR87 sessions fails because the
DN is already in use by client A's session through Node 1.
To solve this issue when planning for capacity, SIP routing must ensure that all TR/87 session
for a given DN always terminate on the same node when a single Call Server has multiple
nodes. (See Figure 55: Capacity example on page 338.

Figure 55: Capacity example
This situation can arise in cases where there is an expectation that a single user has multiple
clients logged on simultaneously, such as a client at home, a client in the office, and a mobile
client all with TR/87 capability.
Impact on Signaling Server
The maximum number of SIP CTI/TR87 users on a single Signaling Server is 5000. One
Signaling Server can support up to 1800 SIP trunks, therefore you require two Mediation
servers for each Signaling Server to correctly deploy OCS 2007. To increase the system
capacity, associate a pool of Mediation servers with each Call Server. The Multimedia
Convergence Manager (MCM) routes inbound calls from the Signaling Server to the
appropriate Mediation server within the Mediation server pool. The CP PIV and CP PM Call
Server can support up to 13 000 users.
For more information about Converged Office features and engineering, see Avaya Converged
Office Fundamentals - Microsoft Office Communications Server 2007, NN43001-121.
Mobile Extension engineering

The following sections detail the engineering related to your use of Mobile Extensions, Primary
Rate Interface, Digital Signal Processor, and Digitone Receiver resources for Mobile
Extension.

Mobile Extension engineering
Mobile Extension
You can configure a mobile user with a Mobile Extension (MOBX), providing a logical
connection to the users mobile phone. Each mobile user requires a configured MOBX.
There is a limit of 4000 Mobile Extensions per customer.
MOBX Digital Signal Processor engineering

You require a Digital Signal Processor (DSP) for each Primary Rate Interface (PRI) trunk
allocated for MOBX. The DSP resources are used for dual tone multi frequency (DTMF)
detection. DSP resources are chassis and cabinet specific on a CS 1000E system. You must
have a one to one relationship with PRI trunks in each chassis or cabinet. See MOBX Primary
Rate Interface engineering on page 340 to calculate the DSPs required.
MOBX Digitone Receiver engineering

You require additional Digitone Receivers (DTR) for the MOBX beyond the required DTRs for
telephones or Digitone trunks. Invoking the Mobile Feature Activation Code (MFAC) disables
the DSP DTMF detector and regular DTR resources are required for the Flexible Feature Code
handling. The MOBX DSP resource is released when the call is released. You can calculate
the number of DTRs required using the following two formulas.
MOBX DTR engineering example
NC = (100 x T) / CHT
Where NC = number of calls
T = traffic in CCS
CHT = 150 (average call hold time in seconds)
DTR CCS = (HT x NC) / 100
Where HT = 6 (DTR average hold time in seconds)
Use your DTR CCS calculated call value and see Table 109: Digitone receiver load capacity
6 to 15 second holding time on page 418 to find the number of DTRs required under the 6
second column. DTR resources are chassis and cabinet specific on a CS 1000E system. Avaya
recommends you configure all 16 DTRs for each chassis or cabinet with MOBX.

MOBX Primary Rate Interface engineering

You can calculate the number of PRI trunks required for MOBX by using the call rate of MOBX
users. (See Table 103: Trunk traffic Poisson 1 percent blocking on page 411).
MOBX PRI engineering example
1000 MOBX users
5 CCS busy hour call attempts (BHCA)
Therefore, 1000 x 5 = 5000 CCS
The table indicates 5000 CCS requires 168 trunks and 168 DSPs, a one to one relationship
between DSP and DTR trunks.
D-channel
D-channel handling interfaces are based on the Multi-purpose Serial Data Link (MSDL) used
in Large Systems.
CS 1000E usage of D-channels for digital trunking is the same as the CS 1000M, therefore
this section applies to the engineering of D-channels for digital trunking on the CS 1000E.
Engineering considerations
The engineering guidelines assume normal traffic consisting of valid call processing and
administrative messages. Engineering rules cannot prevent a piece of equipment on the
network from malfunctioning and generating spurious messages, which overload the links. At
this point the recovery mechanism becomes essential. The mechanism is graceful, not
requiring manual intervention, and can provide as much diagnostic information as possible, to
help isolate the root cause of the problem.
Outgoing messages originate from the system Core Processor (CP), are passed to the D-
channel handler, and travel across the appropriate link to the destination. In equilibrium, or
over a relatively long period of time (on the order of several minutes), the system cannot
generate messages faster than the D-channel handler can process them, than the link can
transmit them, or than the destination can process them. Otherwise, messages build up at the
bottleneck and are eventually lost. The entity with the lowest capacity is the system bottleneck.
For very short periods of time, however, one or more entities can be able to send messages
at a higher rate than the system bottleneck, since buffers are available to queue the excess
messages. These periods are referred to as bursts. The length of the burst and the size of the
burst that can be supported depend on the sizes of the buffers.

D-channel
Thus, to properly engineer a system, two areas must be considered:

• Equilibrium or steady-state performance, which requires an analysis of the CP processing
capacity of the various components of the system, along with link bandwidth. The
equilibrium analysis assumes 30% peakedness, which is consistent with models for the
system CP.
• Burst performance, which requires an analysis of the buffer utilization of the system.
Multiple D-channels
Avaya does not recommend you to split the Primary and Backup D-channels of the same ISDN
Trunk Group across multiple GR/CR CS 1000E Media or PRI Gateways. While this
configuration insures D-channel redundancy during some Primary D-Channel failure
situations, states could exist where both D-channels register to different Call Servers and
simultaneously activate creating a conflict in the Central Office. This conflict can affect service
and can lead to a complete ISDN Trunk Group outage in most service provider Central
Offices.
If your service provider supports ISDN Trunk Group hunting, Avaya recommends you to
maintain multiple ISDN Trunk Groups with each ISDN service provider. Configure each Trunk
Group with its own Primary and Backup D-channels on PRI circuits in each Media Gateway.
This solution offers resilient configuration in larger systems distributed geographically and
operates well even if your service provider is unable to support a D-channel for each ISDN PRI
circuit.
Avaya can provide VoIP Session Border Controllers as an alternative to large scale ISDN
Trunking facilities. This solution offers improved flexibility in deployment and resiliency
performance. For more information, see www.avaya.com/support.
D-channel handling architecture

The D-channel handler and system exchange messages using an SRAM and interrupt
scheme. To prevent any one application from tying up buffer resources, a flow control
mechanism is defined at the system and D-channel handling interface level. The flow control
mechanism is based on the common window mechanism, in which the number of messages
outstanding in the transmit or receive direction per socket, or port, cannot exceed T(K) or R(K),
respectively. In the transmit direction, for example, a message is considered outstanding from
the time the SL-1 software writes it into the transmit ring until all processing of the message
by the D-channel handler is completed. Currently T(K) and R(K) are both set at 30. Each
application must queue messages if the flow control threshold is exceeded. Typically, the
system task also has a buffer for messages.
An overload control threshold is also implemented in the incoming direction to protect the
system Core Processor (CP) from excess messages. If the incoming messages on a single
port exceed 200 messages in 2 seconds, the port is locked out, and a port overload message

is printed. Manual intervention is required to clear the overloaded port. This feature prevents
a single port from locking up the whole link.
Several software tasks exist on the D-channel handler. Layer 1 message processing operates
at the highest priority. If the link is noisy, Layer 1 processing can starve the Layer 2 and Layer
3 processing tasks, resulting in buffer overflows. If such a problem is suspected, the Protocol
Log (PLOG) can be examined. PLOG reporting is requested in LD 96, as described in Avaya
Software Input Output Administration, NN43001-611.
D-channel
For interfaces including NI-2, Q-SIG, and Euro-ISDN, Layer 3 processing is also performed on
the D-channel handler, thus reducing its capacity. These interfaces are referred to as R20+
interfaces. The steady state message rate allowable for D-channel messages is 29 msg/sec
for R20+ interfaces.
The SL-1 software output queue for DCH messages is the Output Buffer (OTBF), which is user
configurable for between 1 and 127 buffers in LD 17. This is a single system resource shared
by all D-channels.
It is possible to define overload thresholds per D-channel for R20+ interfaces. The
ISDN_MCNT (ISDN message count), defined in LD 17, specifies the number of ISDN Layer 3
call control messages allowed per 5-second interval. Overload control thresholds can be set
per D-channel, ranging from 60 to 350 messages in a 5-second window, with a default of 300
messages. If the overload control threshold is exceeded, DCH421 is output. When the
message rate exceeds the threshold for two consecutive 5-second periods, overload control
is invoked and new incoming call requests are rejected by the Layer 3 protocol control in the
third 5-second time interval. Layer 3 resumes accepting new calls at the end of the third time
interval. This flexibility lets the user to regulate the processing required by a specific R20+ DCH
port.
The default value implies no overload control, since 300 messages/5 seconds exceeds the
rated capacity of 29 messages/second.
Primary Rate Interface network

Equilibrium analysis
A D-channel can be configured to support up to 383 B-channels (or 382 with a backup D-
channel) on a T1 or 480 B-channels on an E1. The bandwidth available for messages is 64
kbps. Assumptions for a typical application are: 8 messages/call, 29 bytes/message, including
18 bytes of Layer 3 data and 11 bytes of Layer 2 overhead, 28 hundred call seconds (CCS)/
trunk, and 180 second Average Hold Time (AHT)/call. The system capacity is derived from its
call-carrying capacity for 100% incoming Primary Rate Interface (PRI) calls.
Under the traffic assumptions described above, the D-channel handler is able to support basic
call processing messages for 4 D-channels under normal (steady-state) operation.

D-channel
Peak analysis
When there is a link restart, STATUS messages are sent to all trunks with established calls.
Since the SL-1 software task does not implement flow control on this mechanism, a burst of
up to several hundred messages can be sent to the D-channel handler, exceeding flow control
thresholds. When this happens, messages back up on the OTBF buffer, possibly resulting in
buffer overflow, as indicated by DCH1030 messages. OTBF overflow is also possible after an
initialization, since a burst of messages is sent to each D-channel in the system, and the OTBF
is a shared system resource.
The system capacity is significantly higher in this scenario than in the steady state one because
it is sending out D-channel messages that do not involve call processing. D-channel handling
and Link capacities are also higher because, for equilibrium analysis, some capacity is
reserved for peaking.
In the worst case scenario for a single D-channel, if the system sends messages at its peak
rate, OTBF buffer overflow is possible. Also, once the messages are sent, a burst of responses
can be expected in the incoming direction, resulting in additional congestion at the D-channel
handler.
This situation also occurs when a backup D-channel becomes active, since STATUS messages
are exchanged to resynchronize the link.
To reduce the possibility of this problem occurring, limit the number of B-channels supported
by a D-channel, separate D-channels onto several cards so that message bursts are not being
sent to ports on the same D-channel handling card after initialization, and increase the size of
OTBF to the maximum value of 127.
The Status Enquiry Message Throttle is implemented. This feature applies only to system-to-
system interface networks. It lets the user to configure the number of Status Enquiry messages
sent within 128 msec on a per-D-channel basis. The SEMT parameter is set in LD 17 with a
range between 1 and 5. The default value is 1. Since this feature provides a flow control
mechanism for Status Enquiry messages, the likelihood of buffer overload is reduced.
B-channel overload
In an Automatic Call Distribution (ACD) environment, in which the number of ACD agents plus
the maximum ACD queue length is considerably less than the number of B-channels available
for incoming calls, a burst of incoming messages can impact the performance of the D-channel
handler as well as the system via the following mechanism: Calls from the CO terminate on a
specified ACD queue. When the destination is busy (the destination telephone is busy or the
ACD queue has reached its maximum limit of calls), the system immediately releases the call.
The CO immediately presents another call to the same destination, which is released
immediately by the PBX, and so on.
The B-channel Overload Control feature addresses this problem by delaying the release of an
ISDN PRI call by a user-configurable time when the call encounters a busy condition. The
delay in releasing the seized B-channel prevents a new call from being presented on the same
B-channel, decreasing the incoming call rate. The timer BCOT is set in LD 16 with a range
between 0 and 4000 msec.

ISDN Signaling Link network

In an ISDN Signaling Link (ISL) application, a modem is used to transmit ISDN signaling
messages. Baud rates are user configurable at the standard RS232/RS422 rates: 300, 1200,
2400, 4800, 9600, and 19 200 bps (see Table 72: ISL link capacities on page 344). In this
case, the modem baud rate constraint can be the limiting constraint. The messages/second
that can be supported by the baud rates are given below, where the values allow for 30%
peakedness.
The B-channels that can be supported assume the messaging required for a typical application
as described in Equilibrium analysis on page 342.
Table 72: ISL link capacities
Modem baud rate Link capacity (msgs/sec) B-channels that can be

supported
300 1 input 1 output 46
4800 15 input 15 output 382(T1)/480(E1)
9600 29 input 29 output 382(T1)/480(E1)
19 200 58 input 58 output 382(T1)/480(E1)
For the baud rates listed in Table 72: ISL link capacities on page 344, the link is the limiting
constraint. The potential peak traffic problems described in Peak analysis on page 343 apply
here as well, to an even greater extent because of the larger rate mismatch between the system
and the system bottleneck. To minimize the risk, set the baud rate as high as possible.
Virtual Network Services network

Concepts applicable to ISL networks also apply to Virtual Network Services (VNS) networks.
Up to 4000 VNS DNs (VDN) are supported.
D-channel bit rate
The following guidelines provide the basis for engineering the Network ACD (NACD)/VNS D-
channel speed.
The bit rate load on the D-channel equals:
the amount of messages × the octets per message × the number of messages per second
For example, if Facility Message burst is opened with 25 calls in the queue, then the Call
Request queue size is greater than or equal to 25. The outgoing facility call request is 25

D-channel
messages in one second. The incoming facility call request acknowledges 25 messages in the
same second. The outgoing and incoming call requests total 50 messages.
In this example, the bit rate load on the D-channel equals:
50 messages × 70 octets × 8 bits/octet = 28 800 bits/second
Total bandwidth of a 9600 baud modem is approximately:
9600 baud × 2 = 19 200 bits/second
With a total bandwidth of 19 200 bits/second and a bit rate load of 28 800 bits/second, the D-
channel cannot handle the messaging. D-channel messaging is backlogged.
If the customer is having problems networking calls during high traffic, then the D-channel can
be the cause (especially if the bandwidth is less than 2800 baud). If the D-channel messaging
is delayed to the point where VNS call processing gets delayed, the calls fail to network and
many PRI/VNS/DCH messages are output at both the source and target nodes.
NACD network
A Network ACD (NACD) network is difficult to engineer, since performance depends on specific
network configuration details including connectivity, routing tables, the number of nodes, the
number of queues at each node, and calling patterns.
Diverting calls in NACD is controlled by Routing Tables with timers. Calls diverted by NACD
can be answered by the Source ACD DN or any one of up to 20 Target ACD DNs. Each Target
can have an individual timer defined, from 0 to 1800 seconds. By using ISDN D-channel
messaging to queue Call Requests at remote Target ACD DNs, voice calls are not physically
diverted until an idle agent is reserved for that call at the remote Target node.
Avaya recommends that the Routing Table be designed so that Call Requests cascade to the
network with the timers staggered. The node that is most likely to have available agents should
have the smallest timer value. Otherwise Call Requests flood the network, resulting in
inefficient use of network and real time resources.
An Active Target is available to accept NACD calls, while a Closed Target is closed to incoming
calls. When calls in the Call Request queue exceed the Call Request Queue Size (CRQS)
threshold, the status changes to Closed. A Status Exchange message is sent from the Target
node to the Source ACD DNs indicating the new status. The Target ACD DN remains Closed
to further network call requests until the number of calls in the queue is reduced by the Flow
Control Threshold (FCTH).
At the source node, for each call queued to the network but not answered, 4 messages are
exchanged. For each call queued to the network and answered, 11 messages are exchanged.
Likewise, at the target node, a network call that is queued but not answered requires 4
messages, while a call that is queued and answered requires 11 messages. Messages average
31 bytes.

From a single D-channel perspective, the most difficult network topology is a star network that
each agent node is connected to a tandem node. All messages to the other nodes are sent
across the D-channel connected to the tandem node.
As an example, consider a site with 2000 calls arriving locally during the busy hour. The timers
in the Routing Table are staggered so that 1000 are answered locally without being queued to
the network, 500 are answered locally after being queued to an average of two network target
queues, and 500 are answered in the network after being queued to an average of four network
target queues. Meanwhile, 200 Logical Call Requests arrive from the network, of which 100
calls are answered.
For this same network, assume now that the timers in the Routing Table are not staggered;
instead, Logical Call Requests are broadcast to the 4 target nodes in the network as soon as
calls arrive at the local node. Also assume that a total of 4000 calls arrive elsewhere in the
network and are queued at local ACD DNs. Even if the calls are answered exactly where they
were before, the number of messages exchanged increases significantly:
• 1500 calls queued on 4 ACD DNs and not answered × 4 msgs/call/DN = 24 000 msgs
• 500 calls answered × 11 msgs/call = 5500 msgs
• 500 calls queued on 3 ACD DNs and not answered × 4 msgs/call/DN = 6000 msgs
• 3900 network calls queued on local DN and not answered × 4 msgs/call = 15 600 msgs
• 100 network calls answered × 11 msgs/call = 1100 msgs
• Total 52 200 msgs/hr
• (52 200 msgs/hr) ÷ (3600 secs/hr) = 14.5 msgs/sec
Peak analysis
When the CRQS threshold is reached, the target queue broadcasts messages to the source
ACD DNs informing them that it no longer accept calls. The size of this outgoing burst of
messages depends on the number of source ACD DNs in the network.
Once the FCTH threshold is reached, another Status Exchange message is sent. At that point,
Logical Call Request messages are sent by the Source ACD DNs. While the target queue has
been closed, many calls can have queued at source ACD DNs, resulting in a burst of Logical
Call Request messages once the DN becomes available.
If CRQS values are set high, many messages are exchanged, with the network emulating a
single virtual queue. If the CRQS values are lowered, fewer Call Requests are sent across the
network. However, average source delays can be increased. If FCTH levels are set too low,
target nodes can bounce between Active and Closed states, resulting in network congestion
and excessive real time utilization. However, if FCTH levels are set too high, a target node can
be inundated with Logical Call Request messages once it becomes available. CRQS is
configurable for the range 0 to 255, while FCTH is configurable for the range 10 to 100.
Since the impact of these parameters depends on the configuration, it is not possible to make
general recommendations on how to configure them. They can be determined as part of the
custom network design process. Contact your local Avaya representative for network
engineering services.
Impact of proper engineering of B-channels
In the NACD environment, another problem arises when insufficient B-channels are configured
across the network. When an agent becomes available, an Agent Free Notification message

D-channel
is sent to the source node. An ISDN Call Setup message is sent from the source node to the
target node. Since no B-channel is available, the agent reservation timer expires, an ISDN
Cancellation Message is sent from the target node to the source node, and an ISDN
Cancellation Acknowledge message is sent from the source node to the target node. At this
point, the agent is still free, so the process repeats until a trunk becomes available or the target
closes. This scenario results in a significant amount of message passing.
Trunk requirements under Longest Idle Agent routing

Trunk requirements are usually calculated using the NACD engineering guidelines, whereby
call loading for each queue at each site is estimated and used to calculate the required number
of trunks between each pair of sites. However, when Longest Idle Agent (LIA) is used as the
routing criterion, load estimation becomes difficult. Assuming that any agent can take any call
and that agents have equal holding time characteristics, the following procedure provides a
method to estimate the number of trunks required between pairs of sites.
Assumptions
1. All agents reside in one common pool and process calls at an equal rate (in other
words, they have a common average call service time).
2. An agent having the longest idle time occurs with equal probability among all of the
agents during normal operation.
3. Agents appear as one large pool to incoming calls.
With these assumptions, under LIA, calls are routed proportional to the number of active agents
at each site.
Calculation steps
1. Note the number of active agents at each site (ni) and the total number of active
agents over all sites (N).
2. Calculate the proportion of active agents at each site: pi = ni/N
3. For each incoming local call arrival stream to site i (Ai, expressed in CPH), calculate
the calls routed from site i to site j: Cij = Ai x pj
4. Calculate the total calls routed (T, expressed in CPH) between each pair of sites:
Tij = Tji = Cij + Cji
5. Apply Erlang B to each Tij, i < j, to get the number of required trunks between sites
i and j (Lij).
Erlang B requires the following parameters:
a. Grade-of-Service (GoS) — probability of a blocked call (in other words,
no trunk available) — taken to be 0.01
b. Mean Call Service Time (usually in seconds)
c. number of calls per hour (CPH)
For Erlang B values, see Trunk traffic Erlang B with P.01 Grade-of-Service on page 409.

Parameter settings
The following are parameters that can be configured in LD 17 for CS 1000 D-channels. Items
are listed with their input ranges, with default values shown in brackets.
1. OTBF 1 - (32) - 127: Size of output buffer for DCH
This parameter configures how many output buffers are allocated for DCH
messages outgoing from the system CP to the D-channel handling card. The more
that are created, the deeper the buffering. For systems with extensive D-channel
messaging, such as call centers using NACD, the parameter can be set at 127. For
other systems with moderate levels of D-channel messaging, OTBF can be set at
the smaller of the following two quantities: Total B-channels – (30 × MSDL cards
with D-channels) or 127.
For example, if a system in a standard office environment is configured with 7 T1
spans, 2 D-channels located on two different NTBK51 daughterboards, and 2 back-
up D-channels, the total number of B-channels is (7 × 24) – 4 = 164. OTBF can be
configured to be the smaller of 164 – (30 × 2) = 104 and 127 which is 104.
2. T200 2 - (3) - 40: Maximum time for acknowledgment of frame (units of 0.5 secs)
This timer defines how long the D-channel handler's Layer 2 LAPD waits before it
retransmits a frame. It if does not receive an acknowledgment from the far end for
a given frame before this timer expires, it retransmits a frame. Setting this value too
low can cause unnecessary retransmissions. The default of 1.5 seconds is long
enough for most land connections. Special connections, over radio, for instance,
can require higher values.
3. T203 2 - (10) - 40: Link Idle Timer (units of seconds)
This timer defines how long the Layer 2 LAPD waits without receiving any frames
from the far end. If no frames are received for a period of T203 seconds, the Layer
2 sends a frame to the other side to check that the far end is still alive. The expiration
of this timer causes the periodic "RR" or Receiver Ready to be sent across an idle
link. Setting this value too low causes unnecessary traffic on an idle link. However,
setting the value too high delays the system from detecting that the far end has
dropped the link and initiating the recovery process. The value can be higher than
T200. It can also be coordinated with the far end so that one end does not use a
small value while the other end uses a large value.
4. N200 1 - (3) - 8: Maximum Number of Retransmissions
This value defines how many times the Layer 2 resends a frame if it does not receive
an acknowledgment from the far end. Every time a frame is sent by Layer 2, it
expects to receive an acknowledgment. If it does not receive the acknowledgment,
it retransmits the frame N200 times before attempting link recovery action. The
default (3) is a standard number of retransmissions and is enough for a good link

to accommodate occasional noise on the link. If the link is bad, increasing N200 can
keep the D-channel up longer, but in general this is not recommended.
5. N201 4 - (260): Maximum Number of Octets (bytes) in the Information Field
This value defines the maximum I-frame (Info frame) size. There is no reason to
reduce the number from the default value unless the system is connected to a
system that does not support the 260-byte I-frame.
6. K 1 - (7): Maximum number of outstanding frames
This value defines the window size used by the Layer 2 state machine. The default
value of 7 means that the Layer 2 state machine sends up to 7 frames out to the
link before it stops and requires an acknowledgment for at least one of the frames.
A larger window allows for more efficient transmission. Ideally, the Layer 2 receives
an acknowledgment for a message before reaching the K value so that it can send
a constant stream of messages. The disadvantage of a large K value is that more
frames must be retransmitted if an acknowledgment is not received. The default
value of 7 should be sufficient for all applications. The K value must be the same
for both sides of the link.
7. ISDN_MCNT (ISDN Message Count) 60 - (300) - 350: Layer 3 call control messages
per 5-second interval
It is possible to define overload thresholds for interfaces on a per-D-channel basis.
This flexibility lets the user to regulate the D-channel handler processing required
by a specific R20+ DCH port. The default value of 300 messages/5 seconds is
equivalent to allowing a single port to utilize the full real time capacity of the D-
channel handler. To limit the real time utilization of a single R20+ DCH port to (1 ÷
n) of the real time capacity of the D-channel handler, for n > 1, set ISDN_MCNT to
(300 ÷ n) × 1.2, where the 1.2 factor accounts for the fact that peak periods on
different ports are unlikely to occur simultaneously. For example, to limit a single
port to one-third of the processing capacity of the D-channel handler, ISDN_MCNT
is set to (300 ÷ 3) × 1.2 = 120.
If the ISDN_MCNT threshold is exceeded for one 5-second period, error message DCH421 is
printed. If the threshold is exceeded for two consecutive periods, incoming call requests
arriving in the third 5-second interval are rejected by the D-channel handler Layer 3 software.
At the end of the third 5-second interval, Layer 3 resumes accepting incoming call requests.

The SDI ports on the Media Gateway Controller (MGC) cards in the Media Gateways and on
the Terminal Server provide an asynchronous serial data interface to TTYs, printers, modems,
CRTs, ACD-C package displays and reports, and CDR TTYs.
Normally, in the output direction, the SDI Application passes any character received from the
system to the Layer 1 Driver to be sent out over the interface. If XON/XOFF Handling is enabled
for printing, the SDI Application buffers up to 500 characters once an XOFF is received. The

system is not aware that an XOFF has been received. After the buffer is full, if further output
is received, the oldest data is discarded. Output resumes when an XON is received or 1 minute
has passed since the output was halted by an XOFF. At this point, the contents in the buffer is
emptied first, followed by output from the system. If any data has been discarded, an error
message is sent.
In the input direction, every character received by the Layer 1 Driver is passed to the SDI
Application. The SDI Application echos any input character unless it is told not to by the system.
In Line Editing Mode, the SDI Application buffers a line of up to 80 characters that can be edited
before being sent to the system.
Under certain conditions, control characters can cause messages to bounce between a
modem or printer and the system. To avoid these situations, configure modems in dumb mode
and disable printer flow control.
The system input buffer is the TTY input buffer, which can store 512 characters. The system
output buffer is the TTY output buffer, which can store 2048 characters.
Call Detail Recording records

Call Detail Recording (CDR) records are available in two formats: FCDR=old and FCDR=new.
A typical record for the old format is 100 bytes long while a typical record for the new format
is 213 bytes long (see Table 73: Link capacities for CDR application (outgoing) on page 350).
Due to the nature of the SDI interface, characters are output one at a time, resulting in 100
messages and 213 messages generated for FCDR=old and FCDR=new, respectively. Each
message requires 10 bits. Based on real time measurements, the MSDL rated capacity for
processing CDR messages is 16 631 messages/second.
Table 73: Link capacities for CDR application (outgoing)
Modem baud rate Link capacity (msg/ Calls/Hour for Call/Hour for
sec) (peak) FCDR=old FCDR=new
300 30 831 390
1200 120 3323 1560
2400 240 6646 3120
4800 480 13 292 6241
9600 960 26 585 12 481
19 200 1920 53 169 24 962
38 400 3840 106 338 49 924
The system capacity for messages per second is conservatively based on the assumption of
100% outgoing calls with FCDR=new. Typically, CDR records are not generated for 100% of
the calls.

D-channel handler engineering procedure
Peak analysis
Since each character is sent as a separate message, every time a CDR record is sent, a traffic
peak is generated.
To prevent system buffers from building up, set the baud rate at 38 400. If a lower baud rate
is chosen, assume that the CDR application frequently is in a state of flow control. Note that
this is true even if the steady state message rate is low, due to the nature of the SDI
interface.
The burst sizes are even greater if CDR is configured with queue records for incoming ACD
calls.

It is important to engineer the D-channel handler in the context of engineering the entire
system. For more information about real time engineering of the system, see Avaya Traffic
Measurement Formats and Outputs Reference, NN43001-750 . In all cases with a user
configurable link rate, it is essential that the link be configured so that the rate is high enough
to support steady-state requirements and some peakedness. Otherwise, the application
messages occupy system buffers, increasing the chance of buffer overflow.
Table 74: D-channel handler engineering worksheet on page 351 is a high-level worksheet
for analysis of D-channel handling capacity. See Table 80: Real time requirements for D-
channel applications on page 356 through Table 78: Peak buffer requirements for SDI
applications on page 354 for the values to use in the worksheet.
Table 74: D-channel handler engineering worksheet
Real Time Peak Buffer usage Peak Buffer usage
Port Application required outgoing incoming
0 ____________ ________ ________ ________
1 ____________ ________ ________ ________
2 ____________ ________ ________ ________
3 ____________ ________ ________ ________
Total ________ ________ ________
Assuming 30% peakedness for the applications, the total real time required should be less
than 2 770 000 msec. The projected real time utilization of the D-channel handler is given by:
Real time usage = Total Real Time Required ÷ 2 770 000
Avaya recommends that peak buffer usage be less than 60 in each direction. As the peak buffer
usage increases over 60, the likelihood of an intermittent buffer-full problem increases.
The following sections provide procedures, including worksheet tables, for calculating the real
time required on the D-channel handler for various applications.
In Table 74: D-channel handler engineering worksheet on page 351 through Table 78: Peak
buffer requirements for SDI applications on page 354, if the calls/hour value is known, insert

that value into Column A. Otherwise, follow the guidelines provided. Values in parentheses are
default values. For example, the default number of calls/hr/trunk is 15.6. The value in Column
E can be inserted in the Real Time Required column of Table 74: D-channel handler
engineering worksheet on page 351, and the appropriate Peak Buffer Usage values should be
inserted in the corresponding Peak Buffer Usage columns of Table 74: D-channel handler
engineering worksheet on page 351.
DCH applications
If several applications share a D-channel, add the final real time requirements for the
applications and then enter the total in the appropriate entry in Table 80: Real time
requirements for D-channel applications on page 356.
Table 75: Real time requirements for D-channel applications
DCH Calls/hr A Msgs/call B Msgs/hr C Msec/msg D Msec E =

=A×B C×D
ISDN trunks/DCH × calls/ pre-R20: 8.8
Network hr/trunk (15.6) = 8 _____ R20+: 26.5 _____
_____
NACD NACD agents × calls/
hr/agent (18.3) = 30 _____ pre-R20: 8.8 _____
_____
NMS NMS ports × calls/hr/ pre_R20: 8.8
10 _____ _____
port (65) = _____
For clarification of the terms "pre-R20" and "R20+," see D-channel on page 342
The calculations described for NACD provide a simplified approximation of a "typical" NACD
network. If call flows can be predicted or estimated, they can be used to develop a more
accurate model using the number of messages. When this is done, the msgs/hr is computed
directly, so columns A and B are not used. See Examples on page 354 for a detailed example
of how this can be done.
If a live system is being modeled, add the "number of all incoming messages received on the
D-channel" and the "number of all outgoing messages sent on the D-channel" field from a busy
hour TFS009 report to derive the entry for Column C. See Avaya Traffic Measurement Formats
and Outputs Reference, NN43001-750 for details.
Table 76: Peak buffer requirements for D-channel applications
DCH Outgoing Incoming

ISDN Network SEMT (1) × 8 SEMT (1) × 8
NACD Source ACD DNs + 5 = ____ Network congestion level:

DCH Outgoing Incoming
• Low: 10
• Medium: 20
• High: 30
NMS 10 10
In the case of an ISL D-channel, ensure that the baud rate of the connection is greater than
(C msgs/hr × 29 bytes/msg × 8 bits/byte) ÷ 3600 sec/hr
where C comes from column C in Table 80: Real time requirements for D-channel
applications on page 356.
If the baud rate is too low to meet requirements, performance of the entire D-channel handler
can be jeopardized, since 30 of the output buffers are occupied with ISL D-channel messages
and the real time spent processing these messages increases due to additional flow control
and queueing logic.
SDI applications
In the HSL analysis, include live agents, automated agents, and Avaya CallPilot agents in the
agent total. This compensates for the assumption of simple calls.
Table 77: Real time requirements for SDI applications
SDI calls/hr A msgs/call B msgs/hr msec/msg msec

C=A×B D E=C×D
CDR calls/hr with reports FCDR = old:100
= _____ FCDR = new: 213 _____ 0.05 _____
HSL agents × calls/ 5
agent/hr (18.3) = _____ 8.8 _____
_____
TTY NA NA 15 000 0.05 _____
There are no traffic reports that provide information about the number of SDI messages directly.
For CDR records, determine whether CDR is enabled for incoming, outgoing, and/or internal
calls. The number of incoming, outgoing, internal, and tandem calls is available from TFC001.
Tandem calls are considered both incoming and outgoing. Alternatively, the number of CDR
records can be counted directly.

Table 78: Peak buffer requirements for SDI applications
SDI Outgoing Incoming Minimum baud rate

CDR • 30 if baud rate is less than 1 (msgs/hr × 10 bits/msg) ÷
recommended in Table 73: (3600 sec/hr) = ____
Link capacities for CDR
application (outgoing) on
page 350
HSL • Messages per call (msgs/hr × 20 bytes/msg × 9

bits/byte) ÷ (3600 sec/hr) =
- simple: 5 ____
1
- medium: 10
- complex: 15
TTY 10 10
Examples
NACD network with CDR reports

Consider an NACD network with the topology given in Figure 56: NACD network on
page 355. The call flow is provided, where arrows indicate where calls enter the network and
where they are answered.
Each node has a single ACD DN and calls are queued to the network target DNs as soon as
they arrive.
For this network, we wish to determine whether a single D-channel handler on Node B can
support DCH1, DCH2, and an SDI port for CDR records on Port 0.
Since we have detailed call flow information, we can develop a messaging model for DCH1
and DCH2 (see Table 79: NACD Message Model on page 355).

Figure 56: NACD network
Table 79: NACD Message Model
Originating Node Total Queued Queued but Total DCH1 DCH2

Queued and not messages
answered answered
Node A to Node B 3000 500 2500 15 500 x x
Node A to Node C 3000 500 2500 15 500 x x
Node B to Node A 2600 100 2500 11 100 x
Node B to Node C 2600 500 2100 13 900 x
Node C to Node A 1650 50 1600 6950 x x
Node C to Node B 1650 100 1550 7300 x x
The DCH1 and DCH2 columns indicate whether the messages can be included in the DCH1
and DCH2 message count, respectively. For each row, multiply the entry in the "Queued and
answered" column by 11 messages and multiply the entry in the "Queued but not answered"
column by 4 messages. The sum of these two values is provided in the "Total messages"
column. By summing the rows that can be included for DCH1 and DCH2, we derive the total
messages for DCH1: 56 350 msg/hr and DCH2: 59 150 msg/hr. Note that these messages do
not include the impact of CRQS and FCTH, which are beyond the scope of this analysis (see
Table 80: Real time requirements for D-channel applications on page 356).

Table 80: Real time requirements for D-channel applications
DCH calls/hr A msgs/call B msgs/hr msec/msg D msec E=C×D

C=A×B
NACD NA NA 56 350 pre-R20: 8.8 495 880
DCH1
NACD NA NA 59 150 pre-R20: 8.8 520 520
DCH2
Assuming that no nonNACD calls are carried, Node B carries 3750 calls/hour.
Table 81: Real time requirements for SDI applications
SDI calls/hr A msgs/call B msgs/hr msec/ msg msec

C=A×B D E=C×D
CDR calls/hr with FCDR=old: 100 FCDR=new: 798 750 0.05 39 938
reports=37 213 (FCDR=ne
50 w)
The total D-channel handler requirements can then be computed:

Table 82: Engineering worksheet
Port Application Real Time Peak Buffer usage Peak Buffer usage
required outgoing incoming
0 CDR 39 938 10 1
1 DCH-NACD 495 880 7 10
2 DCH-NACD 520 520 7 10
3
Total 1 056 338 24 21
The projected D-channel handler utilization is 1 056 338 ÷ 2 770 000 = 38%. Assuming low
network congestion, incoming and outgoing peak buffer usage are below 60, so a single D-
channel handler is able to support this configuration. However, due to the potentially high
messaging impact of NACD, this can be re-engineered periodically to determine whether the
call volumes or call flow patterns have changed.
Avaya CallPilot engineering

For information about Avaya CallPilot engineering, see CallPilot Planning and Engineering,
555-7171-101. The abbreviated procedure in this chapter is for system engineering where a
rough estimate of CallPilot ports (or channels) is required.

Call Center
In addition to voice channels, a CallPilot allows fax and speech-recognition media. As a

measure of Digital Signal Processing (DSP) power, different media types require different
Multimedia Processing Unit (MPU) quantities:
• One voice channel requires one MPU.
• One fax channel requires two MPUs.
• One speech-recognition channel requires four MPUs.
A Multimedia Processing Card (MPC-8) is a credit-card sized PC card that resides in the
CallPilot Server. Each MPC-8 has eight MPUs. The maximum number of MPUs in a CallPilot
is 96. Any use of nonvoice application reduces the number of channels available for voice
traffic.
For an IP source to access Avaya CallPilot, the codec must be set for G.711. Since a
nonstandard proprietary codec is used in CallPilot, a multi-rate transcoding renders the
resulting voice samples with very poor quality.
The default holding time for a voice channel user is 40 seconds in the CallPilot port engineering.
Another resource to be estimated in CallPilot is storage size. This requires a complicated
calculation and is not be covered here. For more information, see CallPilot Planning and
Engineering, 555-7101-101 .
Once the CCS for each type of media is calculated, sum up the total and refer to capacity tables
in the publication for the MPU requirement based on the offered CCS traffic.
For nonblocking access, provide one DSP port for each CallPilot port equipped.
Call Center
The Call Center is an ACD switch whose calls are mostly incoming, with extensive applications
features such as Avaya Hospitality Integrated Voice Services. A port in the Call Center
environment, either as an agent telephone or trunk, tends to be more heavily loaded than other
types of applications.
System capacity requirements depend on customer application requirements, such as calls
processed in a busy hour, and feature suites such as Recorded Announcement (RAN), Music,
and Interactive Voice Response (IVR).
ACD
Automatic Call Distribution (ACD) is an optional feature available with the system. It is used
by organizations where the calls received are for a service rather than a specific person.
For basic ACD, incoming calls are handled on a first-come, first-served basis and are
distributed among the available agents. The agent that has been idle the longest is presented
with the first call. This ensures an equitable distribution of incoming calls among agents.

The system is managed or supervised by supervisors who have access to the ACD information
through a video display terminal. These supervisors deal with agent-customer transactions
and the distribution of incoming calls among agents.
Many sophisticated control mechanisms have been built on the basic ACD features. Various
packages of ACD features have real time impact on the system CP capacity.
ACD-C1 and C2 packages

ACD Management Reporting provides the ACD customer with timely and accurate statistics
relevant to the ACD operation. These statistics form periodic printed reports and ongoing status
displays so the customer can monitor changing ACD traffic loads and levels of service and
implement corrective action where required.
The ACD-C1 package primarily provides status reporting of the system through a TTY terminal.
To control and alter the configuration of the system, the ACD-C2 package is required; it
provides the load management commands. The following is a partial list of functions of a
supervisor position in the C2 package:
• Assign autoterminating ACD trunk routes.
• Assign priority status to ACD trunks.
• Reassign ACD agent positions to other ACD DNs.
• telephone the timers and routes for first and second RAN.
• Define the overflow thresholds.
• Specify a night RAN route.
ACD-D package
The ACD-D system is designed to serve customers whose ACD operation requires
sophisticated management reporting and load management capabilities. It has an enhanced
management display, as the system is supplemented by an auxiliary data system. The system
and the auxiliary processor are connected by data links through SDI ports for communications.
Call processing and service management functions are split between the system and the
auxiliary processor.
ACD-MAX
ACD-MAX offers a customer managerial control over the ACD operation by providing past
performance reporting and current performance displays. It is connected through an SDI port
to communicate with the system CP. The ACD-MAX feature makes the necessary calculations
of data received from the system to produce ACD report data for current and past performance
reports. Every 30 seconds, ACD-MAX takes the last 10 minutes of performance data and uses

Symposium Call Center
it to generate statistics for the current performance displays. The accumulated past
performance report data is stored on disk every 30 minutes.
ACD-MAX calls impact capacity engineering in the real time area only.
NACD
The majority of tasks in the engineering of Network ACD (NACD) involve the design of an
NACD routing table and the engineering of overflow traffic. The process is too complex to be
included here. The engineering procedure in this document is for single-node capacity
engineering, which accounts for the real time impact of NACD calls on a switch either as a
source node or remote target node. Therefore, the overall design of a network is not in the
scope of this document.
RAN and Music

The RAN trunk can be treated just like a normal trunk. The only potential capacity impact is for
systems that include RAN trunks in blocking or nonblocking calculations. The calculations
determine the total number of loops or card slots required.
Music Broadcast requires any Music trunk and an external music source or an Avaya Integrated
Recorded Announcer card. The Integrated Recorded Announcer has the capability to provide
audio input for external music. A Conference loop is not required for Music Broadcast.
For more information, see Service loops and circuits on page 222.
Symposium Call Center

Symposium is a Host Server that interfaces through an Ethernet to enable the system to
provide advanced Call Center features to users. Although Internet Protocol (IP) is used for
communications, the underlying message to the system input queue is an Application Module
Link (AML) message.
The customer can create simple-to-write scripts in Symposium to control processing of an
arriving call that is eventually delivered to an agent queue after following various call processing
rules, such as skill set of agent, call priority, and length of waiting time.
The complexity of call handling on the system call processor determines the impact of
Symposium Call Center on the system. Depending on the script used, the call processing can
include giving RAN, Music, and IVR, all of which require a voice-processing system such as
Avaya CallPilot.

Symposium Call Center with IP phones and Virtual Trunks

When IP Phones are used as ACD agent telephones, there are certain special engineering
rules. The following two additional resources must be engineered:
• Digital Signal Processor (DSP) channels (therefore, Media Cards)
• Virtual Trunks
For nonblocking access, provide one DSP port for each ACD agent configured.
For the detailed calculations, see Resource calculations on page 249.
ELAN engineering
The Embedded Local Area Network (ELAN) subnet is designed to handle messaging traffic
between the system and its applications, such as Symposium and Avaya CallPilot. It is not
meant to handle functions of the customer's LAN, which carries customer application traffic.
A 64 kbps link can handle messaging traffic of over 80 000 calls. The ELAN subnet, being an
Ethernet with data rate of 10/100/1000MG autonegotiate, is not a bottleneck in a Symposium/
CallPilot configuration. However, observe the following engineering guidelines to avoid
performance problems. For more information, see Avaya Converging the Data Network with
VoIP Fundamentals, NN43001-260.
• Ensure that settings on the physical interface of the system to the Ethernet are correct.
• Although no traffic engineering is required on the ELAN subnet, if the loading on the link
is extremely high (for example, above 10% on the 10T-10 Mbps), collision on the Ethernet
can happen. Use a sniffer to detect any performance problems. Decrease the loading on
the link if it is overloaded.
• Set a consistent data rate with the application.
Certain remote maintenance applications can utilize the ELAN subnet to access the system
from a remote location. Ensure that no other customer LAN traffic is introduced.
Survivable and Distributed Media Gateway ELAN traffic estimation

When using a Survivable or Distributed Media Gateway in environments with bandwidths less
than 20Mbit/s, Avaya recommends to estimate the ELAN traffic bandwidth for each Media
Gateway. This information is required to properly plan and engineer the data network needs
of the gateway.
Failure to estimate and engineer the data network for the ELAN traffic for Survivable or
Distributed Media Gateways may result in unpredictable behavior of the Media Gateway under
load conditions. Avaya also recommends routinely monitoring the ELAN traffic to determine
the actual bandwidth needs for the Media Gateways. Any configuration change to Media

ELAN engineering
Gateways requires a recalculation of the ELAN traffic estimation to ensure proper data
networking.
You can estimate the ELAN traffic by estimating the load on each card in the Media Gateway
in an estimation table. Table 83: Media Gateway ELAN traffic estimation example on page 361
includes the traffic load on each card in the CCS. Record each card load as normal or maximum
in the table, then copy the appropriate traffic bandwidth number and idle traffic bandwidth for
each card from Table 84: Estimated traffic for cards on page 362. Total and sum the ELAN
traffic bandwidth needed for each Media Gateway. If a card is not found in Table 84: Estimated
traffic for cards on page 362 use the Unknown IPE Card (UIC). Table 83: Media Gateway
ELAN traffic estimation example on page 361 shows an example ELAN traffic estimation table.
Table 84: Estimated traffic for cards on page 362 shows estimated ELAN traffic per card
required for the calculation.
Table 83: Media Gateway ELAN traffic estimation example
Slot PEC Short Name Estimated Idle Traffic Traffic Load

Load (Normal (Bits/sec) (Bits/sec)
or Maximum) (Normal or
Maximum)
0 NTDW60 MGC (96 DSP - DB) Normal Load 6000 0
1 NTBK50 E1 - 2.0Mb PRI Normal Load 14400 57500
2 NT8D09BB Flax Analogue Line Normal Load 0 24000
Card MW
3 NTDW61 CP PM - Call Server None 0 0
4 NTSF6800 TMDI Pkg (1.5Mb Maximum 14400 100000
DTI/PRI) Load
5 0 0
6 0 0
7 NT8D02 Digital Line Card 16 Maximum 0 36400
Port (ACD Agents) Load
8 NT8D02 Digital Line Card 16 Normal Load 0 20800
Port
9 Wired for DLC Wired for DLC Normal Load 0 20800
10 Wired for DLC Wired for DLC Normal Load 0 20800
Totals 34800 280300
ELAN traffic estimation sum example

34800 + 280300 = 315100 Bits/sec
The Media Gateway is estimated to require 315100 Bits/sec of ELAN traffic.

With IPSec, there is an estimated 30% increase in traffic overhead. ELAN traffic estimation
with IPSec is 409630 Bits/sec.
Table 84: Estimated traffic for cards
PEC Short Idle Traffic Normal Normal Maximum Maximum

Description (Bits/sec) Traffic Load Traffic Load
(Bits/sec) (CCS) (Bits/sec) (CCS)
NTDU60BA MGC 6000 0 0 0 0
E5 (Includes
DSP Cards)
NT1R20 XOPS 0 24000 80 42000 528
NT5D14 LINE T1 14400 46000 115 100000 759
NT5D15 XUT Trunk 0 12000 40 24000 264
NT5D26 UTC 0 20800 80 36400 528
NT5D29 XFCOT 0 24000 80 42000 528
NT5D31 UTC 0 20800 80 36400 528
NT5D34 LE1 14400 57500 144 125000 949
NT5D39 DXUT 0 20800 80 36400 528
NT5D51 MICB 3 0 20800 80 36400 528
NT5D51AA MICB 0 20800 80 36400 528
NT5D51BC ICB 4 0 20800 80 36400 528
NT5D60 XCMC 0 20800 80 36400 528
NT5D80 XCMC 0 20800 80 36400 528
NT5G01 ICA 0 20800 80 36400 528
NT5G15 MIVS 0 20800 80 36400 528
NT5G71 ICD 0 20800 80 36400 528
NT5K02 MWALC 0 24000 80 42000 528
NT5K07 UTC 0 24000 80 42000 528
NT5K17 DID 0 12000 40 24000 264
NT5K18 FCOT 0 12000 40 24000 264
NT5K19 EM Trunk 0 12000 40 24000 264
NT5K21 XMFC/MFE 0 20800 80 36400 528
NT5K36 UTC 0 12000 40 24000 264
NT5K50 EM Trunk 0 12000 40 24000 264

ELAN engineering
NT5K60 Inc. 3 wire 0 12000 40 24000 264

Trk
NT5K61 Out. 3 wire 0 12000 40 24000 264
Trk
NT5K70 UTC 0 12000 40 24000 264
NT5K72 EM Trunk 0 12000 40 24000 264
NT5K82 UTC 0 12000 40 24000 264
NT5K83 EM Trunk 0 12000 40 24000 264
NT5K84 UTC 0 12000 40 24000 264
NT5K90 UTC 0 12000 40 24000 264
NT5K93 UTC 0 12000 40 24000 264
NT5K96 Non-MW 0 24000 80 42000 528
ALC
NT5K99 FCOT 0 12000 40 24000 264
NT6D70 SILC 14400 15333 38 33333 253
NT6D71 UILC 14400 15333 38 33333 253
NT8D02 DLC 0 20800 80 36400 528
NT8D03 ALC 0 24000 80 42000 528
NT8D09 Mess Wait 0 24000 80 42000 528
NT8D14 UTC 0 12000 40 24000 264
NT8D15 EM Trunk 0 12000 40 24000 264
NT8K93 EM Trunk 0 12000 40 24000 264
NTAG03 UTC 0 12000 40 24000 264
NTAG04 XDDI 0 12000 40 24000 264
NTAG36 XMFR 0 12000 40 24000 264
NTAG46 UTC 0 12000 40 24000 264
NTAG86 MIRAN III 0 20800 80 36400 528
NTAG88 MIRAN II 0 20800 80 36400 528
NTAK02 SDI/DCH 0 20800 80 36400 528
NTAK03 TDS/DTR 0 20800 80 36400 528
NTAK09 PRI/DTI 14400 46000 115 100000 759
NTAK10 2.0Mb DTI 14400 57500 144 125000 949
NTAK79 2.0Mb PRI 14400 57500 144 125000 949

NTBK22 MISP 11C 14400 46000 115 100000 759

NTBK50 2.0Mb PRI 14400 57500 144 125000 949
NTCG02 2.0Mb DTI 14400 57500 144 125000 949
NTCK16 UTC 0 12000 40 24000 264
NTCK18 XFCOT 0 12000 40 24000 264
NTCK22 DID/DDI 0 12000 40 24000 264
NTCK24 FCOT 0 12000 40 24000 264
NTCW00 DMC4 0 20800 80 36400 528
NTCW00B DMC8 0 20800 80 36400 528
NTCW01 DMC4E 0 20800 80 36400 528
NTCW01B DMC8E 0 20800 80 36400 528
NTDK16 48port DLC 0 62400 240 109200 1584
NTDR68 RLC 0 1500 5 2625 33
NTDR71 RLC III 0 48000 160 84000 1056
NTSF6800 TMDI Pkg 14400 46000 115 100000 759
(1.5Mb DTI/
PRI)
NTHF78BA VSC 8 Port 0 20800 80 36400 528
NTHF82BA VSC 16 Port 0 20800 80 36400 528
NTHF83BA VSC 24 Port 0 20800 80 36400 528
NTRA03 EM Trunk 0 12000 40 24000 264
NTRA04 Mess Wait 0 24000 80 42000 528
NTRA06 OPX 0 24000 80 42000 528
NTRA08 Non Msg 0 24000 80 42000 528
Wait
NTRA10 UTC 0 12000 40 24000 264
NTRA12 UTC 0 12000 40 24000 264
NTRB18 CP Mgate 0 20800 80 36400 528
NTRB21 TMDI 14400 46000 115 100000 759
NTRB37 UTC 0 12000 40 24000 264
NTUB01 CallPltlPE 0 20800 80 36400 528
NTVQ01 SMC 0 20800 80 36400 528

HSP LAN Engineering
NTVQ01BA Remote Agt 0 20800 80 36400 528

Obsv
NTVQ09AB Agent Greet 0 20800 80 36400 528
NTVQ55 ITG 0 20800 80 36400 528
NTZC13 ITG 0 20800 80 36400 528
UIC Unknown 0 20800 80 36400 528
IPE Card
• ELAN Traffic is additional traffic from the ELAN ports on the MGC that must be included
in the overall data network bandwidth estimation. This traffic is specifically between the
MGC and the controlling Communication Server. The MGC may re-home to three
Communication Servers.
• Idle Traffic (Bits/sec) is the minimum ELAN traffic that occurs under no load conditions.
This traffic is always present and must be added to the total ELAN traffic estimation.
• Normal Traffic (Bits/sec) is the normal ELAN traffic during 20% card load or 5 CCS per
port.
• Maximum Traffic (Bits/sec) is the maximum ELAN traffic during 100% card load or 33 CCS
per port.
• Normal Load CCS is the normal card load measured in CCS. For example the NT8D09
Digital Line Card under normal CCS is 80 CCS (16x5CCS = 80 CCS).
• Maximum Load CCS is the maximum card load measured in CCS. For example the
NT8D09 Digital Line Card under maximum CCS is 80 CCS (16x33CCS = 528 CCS).
Table 84: Estimated traffic for cards on page 362 is only to be used for estimating the Media
Gateway ELAN traffic. Do not use these table values for other calculations. Additional network
parameters such as TLAN traffic, packet loss and round trip delay are also required for proper
data network planning and engineering. See Avaya Converging the Data Network with VoIP
Fundamentals, NN43001-260 for additional details on Distributed Media Gateways.
HSP LAN Engineering

The High Speed Pipe (HSP) is used to connect two Call Server CPUs in a Campus Redundant
environment. The HSP is used to shadow disk and memory information from one CPU to
another and to provide heartbeat information (including health information) from one CPU to
the other.
Due to the mission critical role that the HSP provides between the active and redundant Call
Server, the HSP must be carefully engineered. This section describes the rules governing the
engineering of the HSP. For a more information about how the Campus Redundancy feature
works, see Avaya System Redundancy Fundamentals, NN43001-507.

The HSP can be connected using a cable directly between the two CPUs, or using networking
equipment. CP PIV requires the use of a crossover cable for HSP. When using networking
equipment to connect, the HSP ports are assigned unique IP addresses.
The following are recommendations and rules for configuring the HSP network and network
interfaces of two Call Server CPUs using network equipment:
• The HSP must be connected through an Ethernet cable (cross-over on CP PIV) or by a
dedicated VLAN through switches.
• The HSP must be in its own IP subnet. It cannot be combined with the ELAN subnet.
• The minimum throughput of the HSP must be 100 Mbps. Therefore, the HSP port must
be 100 Mbps and full duplex. This must be confirmed using the STAT HSP command in
LD 137 after the equipment is operational. This must also be verified on the network
equipment that the HSP is attached.
• The network switches must be capable of port mapping to 802.1p/Q.
• When running the HSP across network equipment, the HSP must be isolated in its own
VLAN. Do not include other traffic in this VLAN. This VLAN must be given higher VLAN
priority than any other traffic on the network, except for network control traffic (network
control traffic is the traffic necessary to keep the network operational). The VLAN must
be 802.1p/Q-capable and must be set to a very high setting so as not to starve the HSP.
Avaya strongly recommends 802.1p Level 7 (Network Control and OAM).
• When using third-party vendor network equipment that has not been validated by Avaya,
a pre-test of the network must be performed. This test includes mixed traffic going across
the networks in different VLANs. The network specifications can meet the round trip delay
and packet loss requirements.
• The round trip delay of the HSP VLAN must be less than 30 msec and the packet loss of
the HSP VLAN must be below .1 % packet loss.
• The HSP port on the CP PIV is set to autonegotiate the link speed and duplex. Therefore,
the network equipment that the CP PIV is attached must also use autonegotiate. Verify
that both the CP PIV and the network equipment speed and duplex are a match.
• Avaya recommends that MLT (Multi Link Trunking) be used across the enterprise IP
network for the Campus Redundancy configuration.
• Cabling for the HSP port on the CP PIV must be at least Cat 5e when running the link
speed at 1 Gbps.
Caution:
Duplex mismatches occur in the LAN environment when one side is set to autonegotiate
and the other is hard configured.
The autonegotiate side adapts only to the speed setting of the fixed side. For duplex
operations, the autonegotiate side sets itself to half-duplex mode. If the forced side is full-
duplex, a duplex mismatch occurs.

HSP LAN Engineering
Switching Equipment
Layer 2 switching equipment

The following equipment supports MLT (Multi Link Trunking), port based VLANs, and 802.1P
priority configuration and is recommended for the HSP application.
• 325-24T - Layer 2 VLANs, MLT, 802.3ad
• 325-24G - Layer 2 VLANs, MLT, 802.3ad
• 425-24T - Layer 2 VLANs, MLT, DMLT, 802.3ad
• 460-24T-PWR - Layer 2 VLANs, MLT, DMLT, , 802.3ad, 802.3af PoE
• 5510-24T - Layer 2 VLANs, MLT, DMLT, L3 interVLAN routing
• 5510-48T - Layer 2 VLANs, MLT, DMLT, L3 interVLAN routing
• 5520-24T - Layer 2 VLANs, MLT, DMLT, L3 interVLAN routing, 802.3af PoE
• 5520-48T - Layer 2 VLANs, MLT, DMLT, L3 interVLAN routing, 802.3af PoE
• 8300 - Layer 2 VLANs, MLT, DMLT, L3 interVLAN routing
• 8600 - Layer 2 VLANs, MLT, DMLT, SMLT, 802.3ad, L3 interVLAN routing
Third-party vendor switching equipment

The HSP supports all vendor switching equipment. The following third-party equipment has
been tested:
• CISCO WS-3750G 24T-E GE ENH MULTILAYER CAYALYST (Layer 2 VLAN mode)
• 3C17203-3COM US/ 3COM 24-PORT 10/100TX SWITCH W/2
• 3COM 3C17304-US 3COM SS3 SWITCH 4228G 28PORTS EN
• 13240 EXTREME SUMMIT 200-24 SWITCH - 24 PORTS
Important:
The HSP cannot be routed, and as a result, it cannot be extended through a Layer 3 router
unless that device supports a method of providing Layer 2 end-to-end connectivity
(Example: Layer 2 tunneling). Therefore, when passing through routing equipment, the HSP
must remain in the same subnet from one Call Server to the other (Example: tunneling the
HSP over the network).

HSP IP address configuration

The configuration of HSP IP addressing can be performed after the installation process if the
default IP addresses are not appropriate for the customer network. Avaya strongly
recommends allocation of a network IP address within a customer address space if the network
is not dark fiber driven by Ethernet Routing Switch 2550T.
CLASS network engineering rules

In a single-group network system, the network internal blocking is determined by the
concentration ratio of equipped ports on Intelligent Peripheral Equipment and the number of
interfaced loops or superloops. Depending on traffic engineering, a nonblocking network is
achievable.
Feature operation
A call originated from Telephone A (or Trunk A) seeks to terminate on a CLASS Telephone B.
When Telephone B starts to ring, Telephone A hears ringback. A unit in CLASS Modem
(CMOD) is assigned to collect the originator's CND information and waits for the CND delivery
interval. After the first ring at Telephone B, a silence period (deliver interval) ensues, and the
CMOD unit begins to deliver CND information to the CLASS telephone.
The CND information of a traffic source (Telephone A) is a system information, which is
obtained by the system when a call is originated. During the two-second ringing period of the
CLASS Telephone B, Telephone A's CND is delivered to CMOD by SSD messages (using
signaling channel only). When the CND information is sent from CMOD to CLASS Telephone
B, it is delivered through a voice path during the four-second silence cycle of Telephone B. The
CMOD unit is held for a duration of six seconds.
The system delivers SSD messages containing CND information to CMOD and then sends it
to Telephone B during the delivery interval through a voice path.
Table 85: CMOD Unit Capacity on page 368 is the CMOD capacity table. It provides the
number of CMOD units required to serve a given number of CLASS telephones with the desired
GoS (P.001). The required number of CMOD units can have a capacity range whose upper
limit is greater than the number of CLASS telephones equipped in a given configuration.
Table 85: CMOD Unit Capacity
CMOD Unit CLASS Telephone CMOD Unit CLASS Telephone

1 1-2 33 2339-2436

CLASS network engineering rules
CMOD Unit CLASS Telephone CMOD Unit CLASS Telephone

2 3-7 34 2437-2535
3 8-27 35 2536-2635
4 28-59 36 2637-2735
5 60-100 37 2736-2835
6 101-150 38 2836-2936
7 151-206 39 2937-3037
8 207-267 40 3038-3139
9 268-332 41 3140-3241
10 333-401 42 3242-3344
11 402-473 43 3345-3447
12 474-548 44 3448-3550
13 549-625 45 3551-3653
14 626-704 46 3654-3757
15 705-785 47 3768-3861
16 786-868 48 3862-3966
17 869-953 49 3967-4070
18 954-1039 50 4071-4175
19 1040-1126 51 4176-4281
20 1127-1214 52 4282-4386
21 1215-1298 53 4387-4492
22 1299-1388 54 4493-4598
23 1389-1480 55 4599-4704
24 1481-1572 56 4705-4811
25 1573-1665 57 4812-4918
26 1666-1759 58 4919-5025
27 1760-1854 59 5026-5132
28 1855-1949 60 5133-5239
29 1950-2046 61 5240-5347
30 2047-2142 62 5348-5455
31 2143-2240 63 5456-5563
32 2241-2338 64 5564-5671

Guidelines for nonCall Center applications

In a noncall center application, there is no significant number of agent telephones. Therefore,
no conversion of agent telephones to regular telephones is needed.
Engineering rule (no reconfiguration required)

The following engineering rule can be followed to avoid the need to reconfigure a switch to
accommodate the CLASS feature: Provide the number of CMOD units serving all CLASS
telephones in the system based on the capacity table (see Table 85: CMOD Unit Capacity on
page 368).
Guidelines for Call Center applications
Engineering rules (no reconfiguration required)

Follow these engineering rules to avoid the need to reconfigure a switch to accommodate the
CLASS feature for a call center environment:
1. Convert agent telephones to regular telephones:
1 agent CLASS telephone = 4 telephones (called equivalent telephones)
2. Sum up the total number of regular CLASS telephones and equivalent CLASS
telephones and find the number of CMOD units required based on the capacity table
(see Table 85: CMOD Unit Capacity on page 368).
Configuration parameters
Design parameters are constraints on the system established by design decisions and
enforced by software checks. Defaults are provided in the factory-installed database. However,
some parameter values must be set manually, through the OA&M interface, to reflect the actual
needs of the customer's application.
For guidelines on how to determine appropriate parameter values for call registers, I/O buffers,
and so on, see Design parameters on page 199 and Memory engineering on page 211.

Media Application Server (MAS)

MAS servers are deployed in clusters, with a maximum cluster size of 7 servers.
Within a cluster, one server is designated at the Primary MAS server, which handles the
licensing and load sharing for all of the servers within that cluster. Optionally, a Secondary MAS
server can be designated, which will take over the licensing and load sharing function if the
Primary server fails. Both of these servers participate in handling the load (conference, tone,
RAN, Music).
Note:
If both the Primary and Secondary servers in a cluster fail, the remaining servers in the
cluster no longer function, as they cannot obtain a license.
MAS license keys are not shared between MAS clusters.
The MAS license server does not know the capacity limitations of the MAS servers in the
cluster. Therefore, all MAS servers within the cluster MUST be of the same type, or at a
minimum, have the same capacity rating.
When a redundant MAS server is required, an additional MAS server is added to each cluster.
This is done to ensure the MAS servers can handle the load of a cluster in the event that one
of the servers fails or goes offline. The load capacity of this redundant server is not factored
into the calculation of load capacity of the cluster as a whole.
There is a calculation used to determine the number of MAS servers required:MAS
Calculation on page 301. A number of the variable definitions and calculated values from the
MAS calculation are required to determine how to divide the Total_MAS_Session_Licenses
between the different MAS clusters.
It should be noted that the MAS Codec selected and the use of Media Security impact the load
capacity of a MAS server. The MAS server engineering assumes the same codec is used for
all sessions on all MAS servers.
The number of clusters and the size of the license key for each cluster must be calculated.
MAS License/Keycode Calculation:
The total number of MAS sessions equates to the total session licenses required in all MAS
keycodes.
Total_MAS_Session_Licenses = MSC_sessions+XMSC_sessions
Each cluster of MAS servers must have its own keycode. Therefore the total number of MAS
keycodes is equal to the number of MAS clusters.

First, calculate the number of MAS clusters required for the number of servers that will be
deployed (MAS_Clusters).
If (MASA[MASA_type_index] = true then
MAS_Clusters = round_up(SSMASR / (MAS_Cluster_size -1))
Else
MAS_Clusters = roundup(SSMASR / MAS_Cluster_size)
The MAS licenses need to be divided up between the clusters and the number of servers
in each cluster must be taken into consideration.
Second, calculate the number of servers in each Cluster:
Where Servers_in_cluster_one_and_full is defined as the
number of servers in the first cluster and the number of
servers in each full cluster. Therefore when there is only
one cluster this number can be less than the cluster
size.
Servers_in_cluster_N is defined as the number of
servers in the last cluster. When there is only one cluster
this value will be zero. This value will often be smaller than
the cluster size.
If (MASA[MASA_type_index] = true then % have redundancy
{
Servers_in_cluster_one_and_full = MAS_Cluster_size -1
If MAS_Clusters > 1 then
Servers_in_cluster_N = roundup(SSMASR-
((MAS_Clusters-1)*MAS_cluster_size-1))
Else % only one cluster
Servers_in_cluster_N =0
}
Else % no redundancy
{
Servers_in_cluster_one_and_full = MAS_Cluster_size
If MAS_Clusters > 1
then
Servers_in_cluster_N = roundup(SSMASR-
((MAS_Clusters-1)*MAS_cluster_size))
Else % only one cluster
Servers_in_cluster_N = 0
}

Now that the number clusters is known and the number of servers per cluster is known, the
size of the keycode per cluster can be calculated.
Note that the cluster N-1 may not be a full cluster and therefore will have a different number
of licenses than a full cluster.
If MAS_Clusters > 1 then
{
Numb_Cluster_one_keycodes = MAS_Clusters – 1
Numb_ClusterN_keycodes = 1
If MASA = true % have redundancy
{
Cluster_one_keycode_Sessions =
ROUNDUP(Total_MAS_Sessions_Licens
es/SSMASR*(MAS_cluster_size-1)
}
Else % no redundancy MAS servers
{
Cluster_one_keycode_Sessions =
ROUNDUP(Total_MAS_Sessions_Licens
es/SSMASR*(MAS_cluster_size)
} % end redundancy check
% there is more than one cluster, so determine keycode sessions for clusterN
ClusterN_keycode_Sessions = Total_MAS_Session_Licenses –
(Cluster_one_keycode_Sessions * (MAS_Clusters-1))
} % end > 1 MAS cluster
Else % only one MAS cluster
{
Cluster_one_Keycode_Sessions = Total_MAS_Sessions_Licenses
ClusterN_keycode_Sessions = 0
Numb_Cluster_one_keycodes = 1
Numb_ClusterN_keycodes = 0
}
The customer now needs Numb_Cluster_one_keycodes of size
Cluster_one_keycode_Sessions. If the number of MAS clusters (MAS_Clusters) is greater
than one, an additional keycode of size ClusterN_keycode_Sessions will be required.
To verify the number of keycodes that must be generated:
Numb_Cluster_one_keycodes + Numb_ClusterN_keycodes = MAS_Clusters

To verify the size of the keycodes:

(Numb_Cluster_one_keycodes * Cluster_one_Keycode_Sessions) +
(Numb_ClusterN_keycodes * ClusterN_keycode_Sessions)
= Total_MAS_Sessions_Licenses

Chapter 16: Assigning loops and card slots
in the Communication Server
1000E
Contents
Loops and superloops on page 376
Card slot usage and requirements on page 377
Assigning loops and cards in the CS 1000E on page 380
Preparing the final card slot assignment plan on page 389
Introduction
Calculating the number and assignment of cards and, relatedly, Media Gateways is an iterative
procedure, because of specific capacity and usage requirements.
In an Avaya Communication Server 1000E (Avaya CS 1000E) system, Digital Signal Processor
(DSP), Digitone receiver (DTR), Tone and Digit Switch (TDS), and other services are provided
by circuit cards such as Media Cards, and the Media Gateway Controller (MGC). These
resources are available only to the Media Gateway (with optional Expander) that the circuit
cards reside. Other services, such as Conference, are available as system resources but
require Media Gateway-specific DSP resources in order to access them.
System capacities on page 209 and Resource calculations on page 249 describe the
theoretical, traffic-based calculations used by Enterprise Configurator to estimate the required
number of Media Cards and Media Gateways. This chapter describes the steps to allocate the
cards to specific Media Gateways. The process can result in an increase in the required
number of Media Cards and Media Gateways.

Assigning loops and card slots in the Communication Server 1000E
Note on terminology
The term Media Gateway refers to the Media Gateway 1010 (MG 1010) and Avaya CS 1000
Media Gateway 1000E (Avaya MG 1000E). The MG 1010 provides ten IPE slots. The Avaya
MG 1000E provides four IPE slots.
Each MG 1000E can be connected to an optional Media Gateway Expander in order to
increase capacity to eight IPE slots. In this chapter, the term MG 1000E includes the optional
Media Gateway Expander, if equipped.
Loops and superloops

A fully expanded Avaya CS 1000E system provides a maximum of 256 loops or 64 superloops.
Each superloop must be defined on a loop number that is a multiple of 4.
A superloop can be configured to include two Media Gateways. In such a case, the first Media
Gateway is referred to as shelf 0 and the second as shelf 1.
A maximum of 1024 TNs (= 2 × 16 × 32) from two Media Gateways can be associated with a
superloop.
Virtual superloops
There are no physical timeslots on Media Gateways. Timeslots are defined within virtual
superloops that benefit from the nonblocking timeslot architecture used by IP Phones and
Virtual Trunks.
The superloop is layered into 16 banks of virtual superloops interfacing the 16 card slots in the
two Media Gateways. This expands the superloop's 120 timeslots to 1920 timeslots (= 16 ×
120) to service a maximum of 1024 TNs in the address space. Media Gateways are therefore
nonblocking with respect to timeslots.
Internally, a card number separates the banks of software timeslots. Since a superloop is
associated with 16 cards, each card is associated with one virtual superloop.
The network-level circuits, such as Conference and Tones, use additional loops outside of this
address space. They also use DSPs from within the nonblocking superloops.
MGTDS and MGCONF loops

Media Gateway Tone and Conference configuration is configured in LD 17.

Card slot usage and requirements
With MGTDS, you can configure two Media Gateway TDS loops. MGC-based Media Gateway
lets 30 parties on each loop.
MGC-based Media Gateway capacity is 2 MGCONF loops with 30 parties on each loop.
PRI/PRI2/DTI/DTI2 loops
An MGC is required in slot 0 of any Media Gateway that will contain a PRI/PRI2/DTI/DTI2
card.
Each T1/E1 span consumes a loop, as well as a card slot.
The CP PIV and CP PM processors can support up to 100 PRI/PRI2/DTI/DTI2 spans. However,
this many TI/E1 spans would consume most of the loops on the system.

Table 86: Card slots in the MG 1000E chassis on page 377 summarizes the physical and
logical card slots available in the MG 1000E chassis.
Table 87: Card slots in the MG 1010 chassis on page 378 summarizes the physical and logical
card slots available in the MG 1010 chassis.
Table 88: Card slots in the MG 1000E cabinet on page 379 summarizes the physical and
logical card slots available in the MG 1000E cabinet.
Table 86: Card slots in the MG 1000E chassis
Slot number Used for Comment

Physical Logical
MG 1000E chassis
0 0 MGC Dedicated card slot
1–4 1–4 • Media Cards
• Digital line cards
• Digital trunk cards
• Analog line cards
• Application cards
• CP PM cards
n/a 5–6 n/a Not supported


Physical Logical
• CP PM cards
Virtual
n/a 0 32-port MGC DSP 32-port DSP daugherboards
daughterboard use virtual slot 0. 32-port
daugherboards are supported
in MGC daugherboard location
1 and location 2.
n/a 11 96-port MGC DSP 96-port DSP daughterboard
daughterboard uses virtual slots 11, 12, and
n/a 12 13. 96-port daugherboard is
n/a 13 supported in MGC
daughterboard location 1.
n/a 14 DTRs (maximum: 8) Required if any analog
terminals or trunks are
n/a 15 DTRs (maximum: 8) equipped in the MG 1000E.
n/a 15 MF tone detectors (maximum: Must be provided on each MG
4) 1000E that requires tone-
based signaling.
If DTRs are configured in any other card slot, a receiver hardware pack must be equipped
in the slot.
Table 87: Card slots in the MG 1010 chassis

Physical Logical
MG 1010 chassis
0 0 MGC (NTDW98) Dedicated card slot
1–10 1–10 • Media Cards You can use NTDW61 CP PM
cards in IPE slots 1-10. CP PM
• Digital line cards cards in slots 1-10 require the
• Digital trunk cards NTAK19 cable kit for serial
connections.


Physical Logical

• CP PM cards
n/a 21 MGU Dedicated card slot

n/a 22 CP PM cards (NTDW99) Dedicated card slot
n/a 23 CP PM cards (NTDW99) Dedicated card slot
Virtual
1 and location 2.
n/a 14 DTRs Required if any analog
n/a 15 DTRs equipped in the MG 1010.
n/a 15 MF tone detectors Must be provided on each MG
1010 that requires tone-based
signaling.
in the slot.
Table 88: Card slots in the MG 1000E cabinet

Physical Logical
MG 1000E cabinet
0 0 MGC Dedicated card slot
• Digital trunk cards


Physical Logical

10 10 n/a Not supported

Virtual
1 and location 2.
n/a 14 DTRs (maximum: 8) Required if any analog
n/a 15 DTRs (maximum: 8) equipped in the MG 1000E.
n/a 15 MF tone detectors (maximum: Must be provided on each MG
4) 1000E that requires tone-
based signaling.
in the slot.
Assigning loops and cards in the CS 1000E

Media Gateways are nonblocking with respect to timeslots (see Virtual superloops on
page 376). Blocking can occur only if a Media Gateway is configured with fewer DSP ports
than the line or trunk ports require.
The following rules and guidelines describe methods to balance constraints and usage
requirements. Use these guidelines to develop a detailed card slot and loop assignment
plan.
Rules and guidelines

1. Place the MGC card in slot 0 of each Media Gateway.
2. There must be at least 32 DSP ports in each Media Gateway.

Important:
DSP resources cannot be shared between Media Gateways. Therefore, each
Media Gateway must contain sufficient DSP resources required by the equipment
configured in that Media Gateway.
3. There must be at least one TDS loop in each Media Gateway.
4. Allocate the users and Media Cards for dedicated DSPs first, then fill remaining
empty slots in Media Gateways with other IPE cards.
Important:
There is no way to reserve DSP resources for dedicated usage (such as
Conference). If a system has higher than expected call rates for standard
telephones, these standard telephones can effectively hijack DSP resources
required for dedicated functions. Therefore, in a system with high call rates for
standard telephones, place dedicated and standard resources in different Media
Gateways.
Provision resources in the following order:
a. Conference on page 381
b. TDS on page 382
c. Broadcast circuits on page 383
d. Other service circuits on page 385
e. TDM telephones and TDM agents on page 385
f. Consoles on page 386
g. Standard telephones on page 387
Conference
Each Media Gateway provides up to 60 conference circuits (ports), which can be used to form
conferences of up to 30 parties each. The MGC card has 60 conference circuits (2 loops).
Users can configure 2 conference loops on each MGC-based Media Gateway, with each loop
providing 30 conference circuits.
The conference circuits are available to all Media Gateways in the system. Calls are assigned
to conference circuits on a "round robin" basis. Each conference circuit is accessed through a
DSP port in the Media Gateway that the conference loop is defined. In addition, the device
using the service can require another DSP in order to reach the conference port (see DSP
ports for Conference on page 265).
For nonblocking access, provide an equal number of DSP ports and conference ports. In other
words, provide one 32-port Media Card for every defined conference loop.

Media Gateway and DSP calculations for Conference
1. Calculate the number of Media Gateways required for Conference based on the
number of conference circuits needed, in multiples of 60:
Number of Media Gateways = ROUNDUP(Number of conference circuits ÷ 60)
2. Calculate the number of DSPs required for Conference based on the number of
conference circuits needed, in multiples of 32:
Provide 32 ports of DSP for every defined conference loop.
Examples
1. 30 conference circuits are needed:

• One Media Gateway has Conference configured. All other Media Gateways
do not have conference circuits provisioned.
• The Media Gateway with Conference requires 32 DSP ports to support the
service.
• One Media Gateway has Conference configured. All other Media Gateways
• The Media Gateway with Conference requires 64 DSP ports to support the
service.
• Two Media Gateways have Conference configured. All other Media Gateways
• Each Media Gateway with Conference requires 64 DSP ports to support the
service.
TDS
A minimum of one TDS loop is required in each Media Gateway. The TDS circuits are provided
by the MGC card. If additional TDS circuits are required in any Media Gateway, a second TDS
loop can be configured in it.

PRI/PRI2/DTI/DTI2
Each digital trunk in a CS 1000E system requires a dedicated DSP resource. Each T1 span
requires 24 ports of DSP and each E1 span requires 30 ports of DSP.
PRI/PRI2/DTI/DTI2 cards require the use of CEMUX are supported in slots 1-9 of a Media
Gateway.
The definition of each PRI/PRI2/DTI/DTI2 span consumes 1 loop and can be configured in LD
17.
Controlled broadcast
If an MGate card is used for controlled broadcast, the rules for card placement of the MGate
card and timeslot usage is the same as for a MiRan card. The MGate card will require 1 DSP
for every listener.
Table 89: Example of timeslot sharing in a superloop on page 383, if timeslot sharing is used
for MiRan, the same that would be used for MGate, when used for controlled broadcast.
Broadcast circuits
Music and Recorded Announcement (RAN) are broadcast circuits. One channel can support
many listeners. Each listener needs one DSP port. A broadcast music trunk is required for
every 60 broadcast users.
In order to maximize the number of simultaneous connections to an Avaya Integrated
Recorded Announcer card in one Media Gateway shelf of a superloop, use all the timeslots
for the superloop for that card. The software "steals" the timeslots from the other shelf of the
superloop, provided the equivalent card slot in the second Media Gateway is not used. Table
89: Example of timeslot sharing in a superloop on page 383 illustrates the strategy.
Table 89: Example of timeslot sharing in a superloop
Media Gateway 0 Media Gateway 1

l s c Card l s c Card
0 0 1 Media Card for Conference 0 1 1 [Available for use.]
0 0 2 Media Card for Conference 0 1 2 [Available for use.]
0 0 3 Integrated Recorded 0 1 3 [Must be left empty to avoid
Announcer card conflict with Integrated
Recorded Announcer card.]
0 0 4 Media Card for RAN/Music 0 1 4 [Available for use.]

Media Gateway 0 Media Gateway 1

l s c Card l s c Card
0 0 10 [Leave empty — all DSPs in 0 1 10 [Available for use.]
this Media Gateway are
allocated to the conference
and broadcast circuits, so
there is no room for TDM
devices.]
Legend: l = loop (superloop), s = shelf, c = card
An alternative strategy is to use just one Media Gateway on a superloop when broadcast
circuits are required.
Integrated Recorded Announcer card calculations

Since many listeners can be connected to a single source channel, it is possible that one or
two sources on a broadcast source (Recorded Announcer) card can use all of the 120 timeslots
available. No other sources can be used on that card.
Two Licenses are relevant for broadcast services:
• RAN CON = the maximum number of simultaneous RAN listeners in a system
• MUS CON = the maximum number of simultaneous music listeners in a system
When (RAN CON + MUS CON) > 120, more than one card is required for the music and RAN
source. The following calculation provides the minimum number of cards required:
Number of cards = ROUNDUP[(RAN CON + MUS CON) ÷ 120]
For Recorded Announcer cards, the number of ports being ordered is known. Assuming that
port usage and connection load is spread evenly across the Recorded Announcer cards, the
calculation can be recast to perform the following check:
If [(RAN CON + MUS CON) ÷ Number of ports] <= 120, then there are sufficient Recorded
Announcer cards to support the broadcast functions in the system.

Media Gateway DSP calculations for controlled broadcast

Since there are no ISMs to indicate when controlled broadcast is used, usage of this feature
requires special attention.
• Symposium scripts must not assign more than 120 broadcasts to an MGate card.
• There must be enough DSPs in the Media Gateway to support all of the functions within
that chassis or cabinet. If 128 ports of CallPilot are provided, 128 DSPs are required for
CallPilot usage. If controlled broadcast is used with 120 connections, then only 8 DSPs
would be left for access to all remaining CallPilot ports.
When too few DSPs are present and controlled broadcast is given, the end user would get a
busy signal instead of the broadcast message.
Media Gateway and DSP calculations for broadcast circuits

Since each Recorded Announcer card can broadcast to up to 120 listeners, each card requires
a maximum of 120 DSP ports for all music or RAN source channels for that card. Each Media
Gateway can support a single fully used music/RAN source card (1 broadcast source card +
4 Media Cards to support it).
• If (RAN CON + MUS CON) <= 32, allocate 1 Media Card and all Recorded Announcer
cards to the same Media Gateway.
• If 32 < (RAN CON + MUS CON) <= 120, allocate 4 Media Cards + 1 Recorded Announcer
card to the same Media Gateway.
Other service circuits

The list of other service circuits is extensive. It includes, amongst others, cards such as Avaya
Integrated applications, Avaya CallPilot, digital trunks, and analog trunks.
Provide one DSP port for each channel of the service circuits.
TDM telephones and TDM agents

Provide one DSP port for each TDM telephone or TDM agent. Each XDLC card supports up
to 16 TNs. (See also Non-blocking access for ACD on page 389.)

Consoles
Each Avaya 2250 Attendant Console and PC Console requires two TNs (originating and
terminating) on an XDLC card and one Aux TN (for supervisor function). Avaya also
recommends two power TNs per console.
DSPs are used when a call is active on an Attendant loop key. Each side (originating and
terminating) requires one DSP, for a total of two DSPs per active/held call on the console.
Queued calls (ICI key indicators) do not consume DSP resources until the Attendant answers
the call on a loop key.
DSP calculations
For standard access, provide 4 DSPs per console.
For dedicated DSPs, provide 12 DSPs per console (2 × 6 loop keys).
IP Attendant Consoles
Each IP Attendant 3260 in the system requires four SIP ports. You must ensure that there are
enough SIP ports to support the intended number of consoles.
Traffic estimation
You only need to perform traffic estimation calculations if the overall bandwidth between the
IP Attendant Consoles and the registered Media Services server is less than 20 Mbps. This
applies to all deployments.
The traffic estimation calculations shown in the table below are only applicable to the traffic
between the IP Attendant Console and the Media Services server.
Table 90: Traffic estimation calculations for IP Attendant Console
Attendants Estimated Traffic Load Load Requirements

(Mbps)
1 0.07 0.1
2 0.14 0.15
3 0.21 0.25
4 0.28 0.3
5 0.35 0.4
10 0.7 0.75

Attendants Estimated Traffic Load Load Requirements

(Mbps)
15 1.05 1.1
20 1.4 1.4
30 2.1 2.1
40 2.8 2.8
50 3.5 3.5
60 4.2 4.2
63 4.41 4.4
Standard telephones
Standard telephones are the average line users configured with a standard configuration.
1. Using a rule of thumb of five telephones per unallocated DSP, distribute line cards
to the Media Gateways with empty slots and unused DSPs.
The rule of thumb is derived as follows:
• A Media Card with 32 DSPs supports 794 CCS. This approximates to 24.8
CCS per DSP (794 ÷ 32).
• The default value for average user traffic is 5 CCS. At 5 CCS per standard
user, 24.8 CCS per DSP translates to 5 telephones per DSP.
2. Using a rule of thumb of one Media Card per seven line cards, fill empty Media
Gateways with the remaining line cards and their required Media Cards.
The rule of thumb assumes average traffic of less than 7 CCS per telephone. This
is derived as follows:
• There are a total of 8 card slots available in each MG 1000E.
• If 1 card slot is used by a Media Card, a maximum of 7 line cards, or 112
telephones (7 × 16 ports), can be added to the MG 1000E.
• There are a total of 10 card slots available in each MG 1010.
• If 1 card slot is used by a Media Card, a maximum of 9 line cards, or 144
telephones (9 × 16 ports), can be added to the MG 1010.
• A Media Card with 32 DSPs supports 794 CCS. This is the traffic capacity of
this particular Media Gateway.
• A capacity limit of 794 CCS means each MG 1000E based telephone must
generate less than 7 CCS, on average (794 ÷ 112).
• A capacity limit of 794 CCS means each MG 1010 based telephone must
generate less than 5.5 CCS, on average (794 ÷ 144).
For average traffic of more than 7 CCS per telephone, use Table 91: Maximum
number of Media Cards, line cards, and telephones in a Media Gateway on

page 388 to determine the number of Media Cards and telephones that can be
assigned to an MG 1000E.
Table 91: Maximum number of Media Cards, line cards, and telephones in a
Media Gateway
CCS per Media Cards Line cards Telephones*

telephone
<=5.5 1 9 144
<= 7.0 1 7 112
<= 8.0 1 6 96
<= 10.0 1 5 80
<= 18.9 2 6 96
<= 22.8 2 5 80
<= 28.5 2 4 64
<= 36.0 3 5 80
*Number of telephones = Number of line cards × 16 ports
3. Use a similar rule to add trunk cards (XUT) and their required Media Cards. See
Table 92: Maximum number of Media Cards, trunk cards, and trunks in a Media
Gateway on page 388.
Table 92: Maximum number of Media Cards, trunk cards, and trunks in a Media
Gateway
CCS per Media Cards Trunk cards Trunks*

telephone
<= 11.0 1 9 72
<= 14.2 1 7 56
<= 36.0 2 6 48
*Number of trunks = Number of trunk cards × 8 ports
4. To mix line and trunk cards in a Media Gateway, calculate the total CCS for the
number of lines and trunks. Then use Table 93: Traffic capacity of Media Cards
(Erlang B at P.01) on page 388 to identify the number of Media Cards required to
support that CCS rate.
Table 93: Traffic capacity of Media Cards (Erlang B at P.01)
Total CCS Number of Media Cards Number of DSPs

794 1 32
1822 2 64
2891 3 96

Preparing the final card slot assignment plan
CLASS cards
CLASS cards can be placed in any Media Gateway. Therefore, each CLASS cards requires
32 ports of DSP.
The telephones that use the CLASS cards do require extra DSP resources. The rules for
allocating standard telephones apply.
Non-blocking access for ACD

Table 94: Number of Media Cards, line cards, and ACD agents per superloop on page 389
describes two alternative recommended configurations to provide nonblocking ACD access to
DSP ports. Typically, 33 CCS per agent telephone is engineered. However, in a nonblocking
configuration, up to 36 CCS per agent is allowed.
Table 94: Number of Media Cards, line cards, and ACD agents per superloop
Total number Media Gateway (shelf 0) Media Gateway (shelf 1)

of agents* Media Line Agents* Media Line Agents*
Cards cards Cards cards
128 2 4 64 2 4 64
160 3 5 80 3 5 80
*Number of agents = Number of digital line cards × 16 ports; CCS per agent: 33–36
Preparing the final card slot assignment plan

Prepare a final card slot assignment plan as follows:
1. Count the inventory of cards and Media Gateways developed in accordance with
this chapter.
2. Go back to the Enterprise Configurator theoretical calculations and increment the
order requirements to match the modified configuration.
3. Produce the final Enterprise Configurator configuration report. Enterprise
Configurator output includes the following:
• card locations
• DSP allocations (where Media Card utilization is less than 100%)
• Media Gateways that must have conference circuits provisioned

• Media Gateways that must not have conference circuits provisioned

Chapter 17: Provisioning
Contents
Step 1: Define and forecast growth on page 392
Step 2: Estimate CCS per terminal on page 393
Step 3: Calculate number of trunks required on page 394
Step 4: Calculate line, trunk, and console load on page 395
Step 5: Calculate Digitone receiver requirements on page 396
Step 6: Calculate total system load on page 397
Step 7: Calculate the number of IPE cards required on page 397
Step 8: Calculate the number of Media Cards required on page 397
Step 9: Calculate the number of Signaling Servers required on page 398
Step 10: Provision conference/TDS loops on page 398
Step 11: Calculate the number of Media Gateways required on page 398
Step 12: Assign equipment and prepare equipment summary on page 398
Resource calculation worksheets on page 399
Introduction
This section provides a high-level overview of the steps required to determine general
equipment requirements. Consult your Avaya representative and use a configuration tool, such
as Enterprise Configurator, to fully engineer a system.

Provisioning
Important:
The values used in the examples in this chapter are for illustrative purposes only, and should
not be interpreted as limits of the system capacity. The values must be adjusted to suit the
application of a particular system.
Step 1: Define and forecast growth

Forecast the number of telephones required at two-year and five-year intervals.
The customer determines the number of telephones required when the system is placed in
service (cutover). If the customer is unable to provide a two-year and five-year growth forecast,
then use an estimate of annual personnel growth in percent to estimate the number of
telephones required at the two-year and five-year intervals.
Example
A customer has 500 employees and needs 275 telephones to meet the system cutover. The
customer projects an annual increase of 5% of employees based on future business
expansion. The employee growth forecast is:
• 500 employees × 0.05 (percent growth) = 25 additional employees at 1 year
• 525 employees × 0.05 = 27 additional employees at 2 years
The ratio of telephones to employees is 275 ÷ 500 = 0.55.
To determine the number of telephones required from cutover through a five-year interval,
multiply the number of employees required at each of the time periods by the ratio of telephones
to employees (0.55).
• 500 employees × 0.55 = 275 telephones required at cutover
• 525 employees × 0.55 = 289 telephones required at 1 year
• 552 employees × 0.55 = 304 telephones required at 2 years

Step 2: Estimate CCS per terminal
This customer requires 275 telephones at cutover, 304 telephones at two years, and 352
telephones at five years.
Each DN assigned to a telephone requires a TN. Determine the number of TNs required for
each customer. Perform this calculation for cutover, two-year, and five-year intervals.
Step 2: Estimate CCS per terminal

Estimate the station and trunk centi-call seconds (CCS) per terminal (CCS/T) using any one
of the following methods:
1. Comparative method
2. Manual calculation
3. Default method
Comparative method
Select three existing systems that have an historical record of traffic study data. The criteria
for choosing comparative systems are:
1. Similar line size (+25%)
2. Similar business (such as bank, hospital, insurance, manufacturing)
3. Similar locality (urban or rural)
Calculate the average station, trunk, and intra-system CCS/T for the selected systems. Apply
these averages to calculate trunk requirements for the system being provisioned.
Manual calculation
Normally, the customer can estimate the number of trunks required at cutover and specify the
Grade-of-Service (GoS) to be maintained at two-year and five-year periods (see Table 95:
Example of manual calculation of CCS/T on page 394).
Use an appropriate trunking table (see Reference tables on page 409) to obtain estimated
trunk group usage for the number of trunks. Divide the number of lines that are accessing the
group at cutover into the estimated usage. The result is the CCS/T, which can be used to
estimate trunk requirements.
Table 95: Example of manual calculation of CCS/T on page 394 provides an example of the
manual calculation.

Provisioning
Table 95: Example of manual calculation of CCS/T
Traffic source Cutover (CCS) Two years (CCS) Five years (CCS)
Line 275 × 6.2 = 1705 304 × 6.2 = 1885 352 × 6.2 = 2183
Trunk 275 × 4.1 = 1128 304 × 4.1 = 1247 352 × 4.1 = 1444
Subtotal 2833 3132 3627
Console 30 30 30
Total system load 2863 3162 3657
Line CCS/T = 6.2; Trunk CCS/T = 4.1; two consoles = 30 CCS.
Repeat this method for each trunk group in the system, with the exception of small special
services trunk groups (such as TIE, WATS, and FX trunks). Normally, customers tolerate a
lesser GoS on these trunk groups.
Default method
Studies conducted estimate that the average line CCS/T is never greater than 5.5 in 90% of
all businesses. If attempts to calculate the CCS/T using the comparative method or the manual
calculation are not successful, the default of 5.5 line CCS/T can be used.
Determine the network line usage by multiplying the number of lines by 5.5 CCS/T. Then
multiply the total by 2 to incorporate the trunk CCS/T. However, this method double-counts the
intra-CCS/T, resulting in over-provisioning if the intra-CCS/T is high. Also, this method is not
able to forecast individual trunk groups. The trunk and intra-CCS/T are forecast as a group
total.
Step 3: Calculate number of trunks required

Once the trunk CCS/T is known and a GoS has been specified by the customer, determine the
number of trunks required per trunk group to meet cutover, two-year, and five-year
requirements. The following example demonstrates the method.
Example
The customer requires a Poisson 1% blocking GoS (see Trunk traffic Poisson 1 percent
blocking on page 411). The estimated trunk CCS/T is 1.14 for a DID trunk group. Determine
the total trunk CCS by multiplying the number of lines by the trunk CCS/T for cutover, two-year,
and five-year intervals:

Step 4: Calculate line, trunk, and console load
Cutover 275 (lines) × 1.14 (trunk CCS/T) = 313.5 CCS

Two-year 304 (lines) × 1.14 (trunk CCS/T) = 346.56 CCS
Five-year 352 (lines) × 1.14 (trunk CCS/T) = 401.28 CCS
Use Trunk traffic Poisson 1 percent blocking on page 411 to determine the quantity of trunks
required to meet the trunk CCS at cutover, two-year, and five-year intervals. In this case:
• 17 DID trunks are required at cutover
• 18 DID trunks are required in two years
• 21 DID trunk are required in five years
For trunk traffic greater than 4427 CCS, allow 29.5 CCS/T.
Step 4: Calculate line, trunk, and console load
Avaya Communication Server 1000E
Line load
Calculate line load by multiplying the total number of TNs by the line CCS/T. The number of
TNs is determined as follows:
• one TN for every DN assigned to one or more single-line telephones
• one TN for every multi-line telephone without data option
• two TNs for every multi-line telephone with data option
Trunk load
The number of Virtual Trunks to provision is calculated by the ordering and configuration tool
as part of the Media Card provisioning calculation. See Resource calculation worksheets on
page 399 for the manual calculation.
Console load
Calculate console load by multiplying the number of consoles by 30 CCS per console.

Provisioning
Step 5: Calculate Digitone receiver requirements

Once station and trunk requirements have been determined for the complete system, calculate
the Digitone receiver (DTR) requirements.
For information about the DTR resources provided by the MGC card and optional, additional
XDTR cards, see DTR on page 224 .
In the Avaya Communication Server 1000E (Avaya CS 1000E), DTRs are not system-wide
resources. They support only the telephones and trunks in the Media Gateway that they reside
in. See DTR on page 224 for the calculations to determine overall DTR traffic and refer to
reference tables Digitone receiver requirements Model 1 on page 414 through Digitone
receiver requirements Model 4 on page 417 to estimate overall system requirements.
The actual provisioning of additional DTR resources depends on the number of Media
Gateways in the system, and the distribution of line and trunk cards within them.
The models in reference tables Digitone receiver requirements Model 1 on page 414 through
Digitone receiver requirements Model 4 on page 417 are based on some common PBX traffic
measurements.
Model 1
Digitone receiver requirements Model 1 on page 414 is based on the following factors:
• 33% intraoffice calls, 33% incoming calls, and 33% outgoing calls
• 1.5% dial tone delay GoS
• no Digitone DID trunks or incoming Digitone TIE trunks
Model 2
• the same traffic pattern as Model 1
• Digitone DID trunks or incoming Digitone TIE trunks
• Poisson 0.1% blockage GoS

Step 6: Calculate total system load
Model 3
• 15% intraoffice calls, 28% incoming calls, and 56% outgoing calls
• 1.5% dial tone delay GoS
• no Digitone DID trunks or incoming Digitone TIE trunks
Model 4
• the same traffic pattern as Model 3
• Digitone DID trunks or incoming Digitone TIE trunks
• Poisson 0.1% blockage GoS
Step 6: Calculate total system load

Total the line, trunk, console, and DTR load for each customer to get the total load figure for
cutover, two-year, and five-year intervals.
Step 7: Calculate the number of IPE cards required

Using the results of previous calculations for growth forecast and the number of DTRs,
calculate the number of IPE cards required. Divide the number of digital telephone TNs, analog
(500/2500-type) TNs, and trunk TNs by the number of TN assignments for each card. Round
up each calculation to the next integer, then total the number of cards required.
Perform the calculations separately for cutover, two-year, and five-year intervals.
Step 8: Calculate the number of Media Cards required

Resource calculation worksheets on page 399 provides a theoretical, traffic-based calculation
for the number of Media Cards required in the system. This is the method followed by the
ordering and configuration tool. The results provide a starting point for provisioning. For
additional rules and tips to distribute the Media Cards amongst the Media Gateways in order

Provisioning
to determine final Media Card requirements, see Assigning loops and card slots in the
Communication Server 1000E on page 375 .
Step 9: Calculate the number of Signaling Servers

required
The ordering and configuration tool calculates the number of Signaling Servers required. For
a description of the calculation method, see Signaling Server algorithm on page 271 .
Step 10: Provision conference/TDS loops

The MGC card provides conference/TDS functions. For information about provisioning these
functions within each Media Gateway, see Conference on page 381 and TDS on page 382 .
Step 11: Calculate the number of Media Gateways required

Calculating the required number of Media Gateways is an iterative procedure, because certain
resources must be provisioned within each Media Gateway. See Assigning loops and card
slots in the Communication Server 1000E on page 375.
Step 12: Assign equipment and prepare equipment

summary
The ordering and configuration tool produces a summary of the equipment requirements for
the complete system at cutover. Assign the equipment. Adjust the equipment summary if
necessary as a result of assignment procedures. Use the finalized equipment summary to
order the equipment for the system.
Important:
Another step you want to consider at this point is system security. For more information, see
Avaya Access Control Management Reference, NN43001-602.

Resource calculation worksheets

The following lists information you require to determine card placement, DSP usage, and
Signaling Server requirements.
Input parameters Input configuration data

TelephoneCCS – CCS for each standard Number of TDM telephones (analog and
telephone digital), both blocking and nonblocking
TRKCCS – CCS for each trunk Number of UNIStim IP Phones
NBtelephoneCCS – CCS for each Number of SIP IP Phones
nonblocking telephone
ACDCCS – CCS for each ACD agent Number of DECT telephones, including SIP-
DECT
RI – intraoffice calls ratio Number of TDM ACD agents
RT – tandem calls ratio Number of UNIStim IP ACD agents
I – incoming calls to total calls ratio Number of TDM trunks
O – outgoing calls to total calls ratio Number of SIP Virtual Trunks (estimated)
rCON – Conference loop to traffic loop ratio Number of H.323 Virtual Trunks (estimated)
Hold time in seconds (AHTXX)for telephone
to telephone, trunk to trunk, telephone to
trunk, trunk to telephone
Use the calculations in Table 96: Worksheet A: Resource calculation procedure on page 399
for input into the Table 98: Worksheet C: Virtual Trunk calculation on page 403, and for input
into the Real time calculation worksheets on page 404. Worksheet A is not required for input
into the DSP calculations for a Communication Server 1000E system.
Table 96: Worksheet A: Resource calculation procedure
Item Calculation formula

(1) TDM telephone CCS (LTDM) = ((number of analog telephones + number of digital
telephones + number of line-side T1/E1 ports) × _____
TelephoneCCS) + (number of nonblocking telephones
× _____ NBtelephoneCCS)
(2) UNIStim IP telephone CCS (LIP) = (number of UNIStim IP telephones - number of IP
ACD agents) × ______ TelephoneCCS
(3) TDM ACD agent CCS (L ACD) = (number of TDM ACD agents) × ______ ACD CCS

Provisioning

(4) UNIStim IP ACD agent CCS = (number of UNIStim IP ACD agents) × ______
(LACDIP) ACDCCS
(5) DECT telephone CCS (LDECT) = (number of DECT telephones + number of SIP-
DECT telephones) × ______ Telephone CCS
(6) IP 802.11 Wireless telephone = (number of 802.11 Wireless telephones) × ______
CCS (LIPW) TelephoneCCS
(7) SIP Line IP telephone CCS = (number of SIP Line IP telephones) × ______
(LSIPL) TelephoneCCS
(8) ACD CCS adjustment for TDM = number of TDM ACD agents × ______
agents (ACDadj) NBtelephoneCCS
(9) Total line CCS (LCCS) = LTDM + LIP + LACD + LACDIP + LDECT + LIPW + LSIPL -
ACDadj
= (1) + (2) + (3) + (4) + (5) + (6) + (7) - (8)
(10) TDM trunk CCS (TTDM) = Number of TDM trunks × ____ TRK CCS
(11) SIP Virtual Trunk CCS = Number of SIP Virtual Trunks × ____ TRK CCS
(SVTCCS)
(12) H.323 Virtual Trunk CCS = Number of H.323 Virtual Trunks × ____ TRK CCS
(HVTCCS)
(13) Total Virtual Trunk CCS = SVTCCS + HVTCCS
(VTCCS) = (11) + (12)
(14) Total trunk CCS (TTCCS) = TTDM + VTCCS
= (10) + (13)
(15) Total system CCS (TCCS) = LCCS + TTCCS
= (9) + (14)
(16) Percentage H.323 trunk CCS = HVTCCS ÷ VTCCS
of total Virtual Trunk CCS (VH) = (12) ÷ (13)
(17) Percentage SIP trunk CSS of = SVTCCS ÷ VTCCS
total Virtual Trunk CCS (VS) = (11) ÷ (13)
(18) Percentage Virtual Trunk CSS = VTCCS ÷ TTCCS
of total trunk CCS (V) = (13) ÷ (14)
(19) UNIStim IP CSS to total = (LIP + LACDIP) ÷ LCCS
telephone CCS ratio (PU) = ( (2) + (4) ) ÷ (9)
(20) SIP Line IP CSS to total = LSIPL ÷ LCCS
telephone CCS ratio (PS) = (7) ÷ (9)
(21) IP CSS to total telephone CCS = PU + PS
ratio (PIP) = (19) + (20)
(22) Weighted average holding = (RI × AHT SS) + (RT × AHT TT) + (I × AHT TS) + (O ×
time (WAHT) AHTST)


(23) Total calls (TCALL) = 0.5 × TCCS × 100 ÷ WAHT
= 0.5 × (15) × 100 ÷ (22)
(24) Intraoffice calls (CSS) = TCALL × RI
• (a) Intraoffice UNIStim IP to = CSS × PU × PU

UNIStim IP calls (C2IP)
• (b) Intraoffice UNIStim IP to TDM = CSS × 2 × PU × (1 - PIP)

telephone calls (C1IP)
• (c) Intraoffice TDM telephone to = CSS × (1 – PIP)2

TDM telephone calls (CNoIP)
• (d) Intraoffice SIP Line to SIP Line = CSS × PS × PS

calls (C2sip)
• (e) Intraoffice SIP Line to UNIStim = CSS × PS × PU

IP calls (C2sipuip)
• (f) Intraoffice SIP Line to TDM = CSS × 2 × PS × (1 - PIP)

calls (C1sip)
(25) Tandem calls (CTT) = TCALL × RT
• (a) Tandem VT to TDM trunk calls = CTT × 2 × V × (1 - V)

(CT1VT)
• (b) Tandem TDM trunk to TDM = CTT × (1 - V)2

trunk calls (CT2NoVT)
2
• (c) Tandem VT (H323) to VT (SIP) = CTT × V × VH× VS × 2 × 2
calls (CT2HS)
(26) Originating / Outgoing calls = TCALL × O (outgoing ratio)

(CST)
• (a) UNIStim IP to VT calls (C STIV) = CST × PU × V
• (b) UNIStim IP to TDM calls = CST × PU × (1 - V)

(CSTID)
• (c) TDM telephone to VT calls = CST × (1 - PIP) × V

(CSTDV)
• (d) TDM telephone to TDM trunk = CST × (1 - PIP) × (1 - V)

calls (CSTDD)
• (e) SIP Line to VT calls (C STSV) = CST × PS × V

Provisioning
• (f) SIP Line to TDM trunk calls = CST × PS × (1 - V)

(CSTSD)
(27) Terminating / Incoming calls = CTS × I (incoming ratio)

(CTS)
• (a) VT to TDM telephone calls = CTS × V × (1 - PIP)

(CTSVD)
• (b) VT to UNIStim IP telephone = CTS × V × PU

calls (CTSVI)
• (c) TDM trunk to UNIStim IP = CTS × (1 - V) × PU

telephone calls (CTSDI)
• (d) TDM trunk to TDM telephone = CTS × (1 - V) × (1 - PIP)

calls (CTSDD)
• (e) VT to SIP Line telephone calls = CTS × V × PS

(CTSVS)
• (f) TDM trunk to SIP Line = CTS × (1 - V) × PS

telephone calls (CTSDS)
Table 97: Worksheet B: Detailed DSP and Media Card calculation for Media Gateway

Calculate for each Media Gateway Media Gateway location
_______________________________
(1) DSP ports for nonblocking ports = Number of trunk ports + number of
(telephones, ACD agents, consoles, digital telephones + [4 × number of standard
trunks, and analog trunks) consoles] + [12 × number of nonblocking
consoles]
(2) Media Gateway CCS for general traffic = Number of standard ports × telephoneCCS
(CCSDSP)
(3) DSP ports for general traffic = lookup the CCSDSP value (2) in Table 56:
Erlang B and Poisson values, in 32-port
increments on page 264 for the number of
DSP ports
(4) DSP ports for conference = Total_telephones × PIP × rCON × 0.4
= Number of configured conference loops ×
32
(maximum of 2 conference loops for each
Media Gateway)
(5) DSP ports for applications = (a) + (b) + (c) + (d) + (e) + (f) + (g) + (h)

• (a) CallPilot = Number of CallPilot ports
• (b) MIRAN = Number of MIRAN listeners (maximum of

120 listeners for each Media Gateway)
• (c) Integrated Conference Bridge = Number of ICB ports
• (d) Integrated Conference Director = Number of IPCB ports
• (e) Integrated Call Assistant = Number of ICA ports
• (f) Hospitality Integrated Voice Service = Number of IVS ports
• (g) BRI = Number of BRI ports × 2
• (h) Agent greeting ports = Number of Agent greeting ports
(6) Total DSP ports = (1) + (3) + (4) + (5)

(7) Extra Media Cards required * = Roundup [[(6) - 128] ÷ 32]
* Number for extra Media Cards assumes
each Media Gateway contains 128 DSP
ports on the MGC card. If extra Media Cards
are required, then you may need to move
other cards out of the Media Gateway to
provide enough available slots to hold more
Media Cards.
Table 98: Worksheet C: Virtual Trunk calculation
Call type Calculation formula

(1) Virtual Trunk calls (CVT) = CT1VT + CSTIV + CSTDV + CTSVD + CTSVI +
CT2HS + CSTSV + CTSVS
(2) SIP Virtual Trunk calls CVT × VS
(3) H.323 Virtual Trunk calls CVT × VH
(4) Virtual Trunk CCS (CCSVT) CVT × WAHT ÷ 100
(5) Number of Virtual Trunks Roundup (CCSVT ÷ 5084 × 192)
(6) Virtual Trunk traffic in erlangs Roundup (CCSVT ÷ 36) use this for LAN/
WAN bandwidth calculation
If the calculated number of Virtual Trunks differs significantly from the original estimated
number of Virtual Trunks (> 20%), Avaya recommends using the calculated Virtual Trunk
number and repeating the calculation procedure to yield a more accurate number for
required Media Cards and Virtual Trunks.

Provisioning
Real time calculation worksheets

The variable values in many of the following tables are calculated in Table 96: Worksheet A:
Resource calculation procedure on page 399.
Table 99: Worksheet D-1: Basic call EBC calculation

(1) Intraoffice UNIStim IP to UNIStim IP call P_UIPtoUIP = C2IP ÷ TCALL
penetration factor
(2) Intraoffice UNIStim IP to TDM telephone P_UIPtoL = C 1IP ÷ TCALL
calls penetration factor
(3) Intraoffice TDM telephone to TDM P_LtoL = C NoIP ÷ TCALL
telephone calls penetration factor
(4) Intraoffice SIP Line to SIP Line calls P_SIPtoSIP = C2sip ÷ TCALL
penetration factor
(5) Intraoffice SIP Line to UNIStim IP calls P_SIPtoUIP = C2sipuip ÷ TCALL
penetration factor
(6) Intraoffice SIP Line to TDM telephone P_SIPtoL = C 1sip ÷ TCALL
calls penetration factor
(7) Tandem Virtual Trunk to TDM trunk calls P_VTtoTr = CT1VT ÷ TCALL
penetration factor
(8) Tandem TDM trunk to TDM trunk calls P_TrtoTr = CT2NoVT ÷ TCALL
penetration factor
(9) Tandem VT (H323) to VT (SIP) calls P_VhtoVs = CT2HS ÷ TCALL
penetration factor
(10) UNIStim IP to VT calls penetration factor P_UIPtoVT = CSTIV ÷ TCALL
(11) UNIStim IP to TDM trunk calls P_UIPtoTr = CSTID ÷ TCALL
penetration factor
(12) TDM telephone to VT calls penetration P_LtoVT = CSTDV ÷ TCALL
factor
(13) TDM telephone to TDM trunk calls P_LtoTr = CSTDD ÷ TCALL
penetration factor
(14) SIP Line to VT calls penetration factor P_SIPtoVT = CSTSV ÷ TCALL
(15) SIP Line to TDM trunk calls penetration P_SIPtoTr = CSTSD ÷ TCALL
factor
(16) VT to TDM telephone calls penetration P_VTtoL = C TSVD ÷ TCALL
factor


(17) VT to UNIStim IP telephone calls P_VTtoUIP = CTSVI ÷ TCALL
penetration factor
(18) TDM trunk to UNIStim IP telephone P_TrtoUIP = CTSDI ÷ TCALL
penetration factor
(19) TDM trunk to TDM telephone P_TrtoL = C TSDD ÷ TCALL
penetration factor
(20) VT to SIP Line telephone calls P_VTtoSIP = CTSVS ÷ TCALL
penetration factor
(21) TDM trunk to SIP Line telephone P_TrtoSIP = CTSDS ÷ TCALL
penetration factor
(22) Weighted average penetration factor PF = (P_UIPtoUIP × f1) + (P_UIPtoL × f 2) +
(P_LtoL × f 3) + (P_VTtoTr × f4) + (P_TrtoTr ×
f5) + (P_VhtoVs × f6) + (P_UIPtoVT × f7) +
(P_UIPtoTr × f8) + (P_LtoVT × f9) + (P_LtoTr
× f10) + (P_VTtoL × f 11) + (P_VTtoUIP × f12)
+ (P_TrtoUIP × f13) + (P_TrtoL × f 14) +
(P_SIPtoSIP × f15) + (P_SIPtoUIP × f16) +
(P_SIPtoL × f 17) + (P_SIPtoVT × f18) +
(P_SIPtoTr × f19) + (P_VTtoSIP × f20) +
(P_TrtoSIP × f21)
(23) Error_term (basic features: forward/ Error_term = 0.25
transfer/conference/waiting)
(24) System EBC SEBC = (TCALL × (1 + PF + Error_term))
Table 100: Worksheet D-2: Feature and application EBC calculation

ACD calls CACD = (LACD + LIPACD) × 100 ÷ AHT AGT
ACD ACDEBC = CACD × (1 - %Symposium) × fACD
Symposium SymposiumEBC = %Symposium × CACD × fSYM
CallPilot CallPilotEBC = (CP1 + CP2) × 100 ÷ AHT CP ×
fCP
Internal CDR InternalCDR_EBC = CSS × fICDR
Incoming CDR IncomingCDR_EBC = CTS × fCCDR
Outgoing CDR OutgoingCDR_EBC = CST × fOCDR
Tandem CDR TandemCDR_EBC = CTT × fTAN
Integrated Conference Bridge MICB_EBC = number of Integrated Conference
Bridge ports × Appl CCS × 100 ÷ AHT MICB × fMICB

Provisioning

Integrated Recorded Announcer MIRAN_EBC = number of Integrated Recorded
Announcer ports × Appl CCS × 100 ÷ AHT MIRAN ×
fMIRAN
Integrated Call Director MIPCD_EBC = number of Integrated Call
Director ports × Appl CCS × 100 ÷ AHT MIPCD ×
fMIPCD
Integrated Call Announcer MICA_EBC = number of Integrated Call
Announcer ports × Appl CCS × 100 ÷ AHT MICA ×
fMICA
Hospitality Integrated Voice Services MIVS_EBC = number of Hospitality Integrated
Voice Services ports × Appl CCS × 100 ÷ AHT MIVS
× fMIVS
BRI BRI_EBC = number of BRI users × TelephoneCCS
× 100 ÷ AHT BRI × fBRI
MDECT MDECT_EBC = LDECT × 100 ÷ WAHT × f DECT
CPND CPND_EBC = (CSS + CTS) × fCPND
Converged Desktop CD_EBC = (CSS × 0.1 + CTT + CST + CTS) × rDTP
× fDTP
Microsoft Converged Office MO_EBC = (CSS × 0.1 + CTT + CST + CTS) × mop
× fMO
IP Security IPSEC_EBC = (CSS + CTT + CST + CTS) × PIP ×
IPSEC_P × fipsec
MC3100 MC3100_EBC = (CSS + CTT + CST + CTS) ×
MC3100_P × fmc3100
MobileX MobileX_EBC = (CSS + CTT + CST + CTS) ×
MobileX_P × fmobileX
ELC ELC_EBC = (CSS × ELC_P × fELC
Features and Applications EBC FAEBC = ACD_EBC + Symposium_EBC +
CallPilot_EBC + InternalCDR_EBC +
IncomingCDR_EBC + OutgoingCDR_EBC +
TandemCDR_EBC + MICB_EBC + MIRAN_EBC
+ MIPCD_EBC + MICA_EBC + MIVS_EBC +
BRI_EBC + MDECT_EBC + CPND_EBC +
CD_EBC + MO_EBC + IPSEC_EBC +
MC3100_EBC + MobileX_EBC + ELC_EBC
Table 101: Worksheet D-3: Real Time Usage calculation

Real Time Usage RTU = (SEBC + FAEBC) ÷ Rated_EBC × 100


where Rated_EBC is the rated capacity of the
CPU from Table 42: Real time capacity (EBC) by
system on page 229

Provisioning

Appendix A: Reference tables
List of tables
Trunk traffic Erlang B with P.01 Grade-of-Service on page 409
Table 103: Trunk traffic Poisson 1 percent blocking on page 411
Table 104: Trunk traffic Poisson 2 percent blocking on page 412
Digitone receiver requirements Model 1 on page 414
Digitone receiver load capacity 6 to 15 second holding time on page 418
Digitone receiver load capacity 16 to 25 second holding time on page 419
Digitione receiver requirement Poisson 0.1 percent blocking on page 421
Conference and TDS loop requirements on page 422
Digitone receiver provisioning on page 423
Trunk traffic Erlang B with P.01 Grade-of-Service

Table 102: Trunk traffic Erlang B (P.01)
Trunks CCS Trunks CCS Trunks CCS Trunks CCS Trunks CCS
1 0.4 21 462 41 1076 61 1724 81 2387
2 5.4 22 491 42 1108 62 1757 82 2419
3 16.6 23 521 43 1140 63 1789 83 2455
4 31.3 24 550 44 1171 64 1822 84 2488
5 49.0 25 580 45 1203 65 1854 85 2520

Reference tables
6 68.8 26 611 46 1236 66 1886 86 2552
7 90.0 27 641 47 1268 67 1922 87 2588
8 113 28 671 48 1300 68 1955 88 2621
9 136 29 702 49 1332 69 1987 89 2653
10 161 30 732 50 1364 70 2020 90 2689
11 186 31 763 51 1397 71 2052 91 2722
12 212 32 794 52 1429 72 2088 92 2758
13 238 33 825 53 1462 73 2120 93 2790
14 265 34 856 54 1494 74 2153 94 2822
15 292 35 887 55 1526 75 2185 95 2858
16 319 36 918 56 1559 76 2221 96 2891
17 347 37 950 57 1591 77 2254 97 2923
18 376 38 981 58 1624 78 2286 98 2959
19 404 39 1013 59 1656 79 2318 99 2992
20 433 40 1044 60 1688 80 2354 100 3028
101 3060 121 3740 141 4424 161 5119 181 5810
102 3092 122 3776 142 4460 162 5155 182 5843
103 3128 123 3809 143 4493 163 5188 183 5879
104 3161 124 3845 144 4529 164 5224 184 5915
105 3197 125 3877 145 4561 165 5260 185 5974
106 3229 126 3913 146 4597 166 5292 186 5983
107 3265 127 3946 147 4630 167 5328 187 6019
108 3298 128 3982 148 4666 168 5360 188 6052
109 3330 129 4014 149 4702 169 5396 189 6088
110 3366 130 4050 150 4738 170 5429 190 6124
111 3398 131 4082 151 4770 171 5465 191 6156
112 3434 132 4118 152 4806 172 5501 192 6192
113 3467 133 4151 153 4842 173 5533 193 6228
114 3503 134 4187 154 4874 174 5569 194 6260
115 3535 135 4219 155 4910 175 5602 195 6296
116 3571 136 4255 156 4946 176 5638 196 6332

Trunk traffic Poisson 1 percent blocking
117 3604 137 4288 157 4979 177 5670 197 6365
118 3640 138 4324 158 5015 178 5706 198 6401
119 3672 139 4356 159 5051 179 5738 199 6433
120 3708 140 4392 160 5083 180 5774 200 6469
For trunk traffic greater than 6469 CCS, allow 32.35 CCS per trunk.

Table 103: Trunk traffic Poisson 1 percent blocking
1 0.4 41 993 81 2215 121 3488 161 4786
2 5.4 42 1023 82 2247 122 3520 162 4819
3 15.7 43 1052 83 2278 123 3552 163 4851
4 29.6 44 1082 84 2310 124 3594 164 4884
5 46.1 45 1112 85 2341 125 3616 165 4917
6 64 46 1142 86 2373 126 3648 166 4549
7 84 47 1171 87 2404 127 3681 167 4982
8 105 48 1201 88 2436 128 3713 168 5015
9 126 49 1231 89 2467 129 3746 169 5048
10 149 50 1261 90 2499 130 3778 170 5081
11 172 51 1291 91 2530 131 3810 171 5114
12 195 52 1322 92 2563 132 3843 172 5146
13 220 53 1352 93 2594 133 3875 173 5179
14 244 54 1382 94 2625 134 3907 174 5212
15 269 55 1412 95 2657 135 3939 175 5245
16 294 56 1443 96 2689 136 3972 176 5277
17 320 57 1473 97 2721 137 4004 177 5310
18 346 58 1504 98 2752 138 4037 178 5343
19 373 59 1534 99 2784 139 4070 179 5376
20 399 60 1565 100 2816 140 4102 180 5409

Reference tables
21 426 61 1595 101 2847 141 4134 181 5442
22 453 62 1626 102 2879 142 4167 182 5475
23 480 63 1657 103 2910 143 4199 183 5508
24 507 64 1687 104 2942 144 4231 184 5541
25 535 65 1718 105 2974 145 4264 185 5574
26 562 66 1749 106 3006 146 4297 186 5606
27 590 67 1780 107 3038 147 4329 187 5639
28 618 68 1811 108 3070 148 4362 188 5672
29 647 69 1842 109 3102 149 4395 189 5705
30 675 70 1873 110 3135 150 4427 190 5738
31 703 71 1904 111 3166 151 4460 191 5771
32 732 72 1935 112 3198 152 4492 192 5804
33 760 73 1966 113 3230 153 4525 193 5837
34 789 74 1997 114 3262 154 4557 194 5871
35 818 75 2028 115 3294 155 4590 195 5904
36 847 76 2059 116 3326 156 4622 196 5937
37 876 77 2091 117 3359 157 4655 197 5969
38 905 78 2122 118 3391 158 4686 198 6002
39 935 79 2153 119 3424 159 4721 199 6035
40 964 80 2184 120 3456 160 4754 200 6068

Table 104: Trunk traffic Poisson 2 percent blocking
1 0.4 31 744 61 1659 91 2611 121 3581
2 7.9 32 773 62 1690 92 2643 122 3614
3 20.9 33 803 63 1722 93 2674 123 3647
4 36.7 34 832 64 1752 94 2706 124 3679

5 55.8 35 862 65 1784 95 2739 125 3712
6 76.0 36 892 66 1816 96 2771 126 3745
7 96.8 37 922 67 1847 97 2803 127 3777
8 119 38 952 68 1878 98 2838 128 3810
9 142 39 982 69 1910 99 2868 129 3843
10 166 40 1012 70 1941 100 2900 130 3875
11 191 41 1042 71 1973 101 2931 131 3910
12 216 42 1072 72 2004 102 2964 132 3941
13 241 43 1103 73 2036 103 2996 133 3974
14 267 44 1133 74 2067 104 3029 134 4007
15 293 45 1164 75 2099 105 3051 135 4039
16 320 46 1194 76 2130 106 3094 136 4072
17 347 47 1225 77 2162 107 3126 137 4105
18 374 48 1255 78 2194 108 3158 138 4138
19 401 49 1286 79 2226 109 3190 139 4171
20 429 50 1317 80 2258 110 3223 140 4204
21 458 51 1348 81 2290 111 3255 141 4237
22 486 52 1374 82 2322 112 3288 142 4269
23 514 53 1352 83 2354 113 3321 143 4302
24 542 54 1441 84 2386 114 3353 144 4335
25 571 55 1472 85 2418 115 3386 145 4368
26 562 56 1503 86 2450 116 3418 146 4401
27 627 57 1534 87 2482 117 3451 147 4434
28 656 58 1565 88 2514 118 3483 148 4467
29 685 59 1596 89 2546 119 3516 149 4500
30 715 60 1627 90 2578 120 3548 150 4533

Reference tables
Digitone receiver requirements Model 1

Table 105: Digitone receiver requirements Model 1
Number of Max. DTR load Number of Max. DTR load

DTRs number of (CCS) DTRs number of (CCS)
Digitone Digitone
lines lines
2 7 2 17 1181 319
3 33 9 18 1244 336
4 69 19 19 1348 364
5 120 33 20 1455 393
6 179 49 21 1555 420
7 249 68 22 1662 449
8 332 88 23 1774 479
9 399 109 24 1885 509
10 479 131 25 1988 537
11 564 154 26 2100 567
12 659 178 27 2211 597
13 751 203 28 2325 628
14 848 229 29 2440 659
15 944 255 30 2555 690
16 1044 282
See Step 5: Calculate Digitone receiver requirements for Model 1 assumptions.



Digitone Digitone
lines lines
2 2 2 17 843 253
3 21 7 18 920 276
4 52 15 19 996 299
5 90 27 20 1076 323
6 134 40 21 1153 346
7 183 55 22 1233 370
8 235 71 23 1316 395
9 293 88 24 1396 419
10 353 107 25 1480 444
11 416 126 26 1563 469
12 483 145 27 1650 495
13 553 166 28 1733 520
14 623 187 29 1816 545
15 693 208 30 1903 571
16 770 231
See Step 5: Calculate Digitone receiver requirements" for Model 2 assumptions.

Reference tables


Digitone Digitone
lines lines
2 5 2 17 862 319
3 22 9 18 908 336
4 50 19 19 983 364
5 87 33 20 1062 393
6 132 49 21 1135 420
7 180 68 22 1213 449
8 234 88 23 1294 479
9 291 109 24 1375 509
10 353 131 25 1451 537
11 415 154 26 1532 567
12 481 178 27 1613 597
13 548 203 28 1697 628
14 618 229 29 1781 659
15 689 255 30 1864 690
16 762 282



Digitone Digitone
lines lines
2 4 2 17 683 253
3 18 7 18 745 276
4 41 15 19 808 299
5 72 27 20 872 323
6 109 40 21 935 346
7 148 55 22 1000 370
8 193 71 23 1067 395
9 240 88 24 1132 419
10 291 107 25 1200 444
11 340 126 26 1267 469
12 391 145 27 1337 495
13 448 166 28 1405 520
14 505 187 29 1472 545
15 562 208 30 1543 571
16 624 231

Reference tables
Digitone receiver load capacity 6 to 15 second holding

time
Table 109: Digitone receiver load capacity 6 to 15 second holding time
Numbe Average holding time in seconds

r of 6 7 8 9 10 11 12 13 14 15
DTRs
1 0 0 0 0 0 0 0 0 0 0
2 3 2 2 2 2 2 2 2 2 2
3 11 10 10 9 9 9 9 8 8 8
4 24 23 22 21 20 19 19 19 18 18
5 41 39 37 36 35 34 33 33 32 32
6 61 57 55 53 52 50 49 49 48 47
7 83 78 75 73 71 69 68 67 66 65
8 106 101 97 94 91 89 88 86 85 84
9 131 125 120 116 113 111 109 107 106 104
10 157 150 144 140 136 133 131 129 127 126
11 185 176 170 165 161 157 154 152 150 148
12 212 203 196 190 185 182 178 176 173 171
13 241 231 223 216 211 207 203 200 198 196
14 270 259 250 243 237 233 229 225 223 220
15 300 288 278 271 264 259 255 251 248 245
16 339 317 307 298 292 286 282 278 274 271
17 361 346 335 327 320 313 310 306 302 298
18 391 377 365 356 348 342 336 331 327 324
19 422 409 396 386 378 371 364 359 355 351
20 454 438 425 414 405 398 393 388 383 379
21 487 469 455 444 435 427 420 415 410 406
22 517 501 487 475 466 456 449 443 438 434
23 550 531 516 504 494 487 479 472 467 462
24 583 563 547 535 524 515 509 502 497 491

Digitone receiver load capacity 16 to 25 second holding time

r of 6 7 8 9 10 11 12 13 14 15
DTRs
25 615 595 579 566 555 545 537 532 526 521
26 647 628 612 598 586 576 567 560 554 548
27 680 659 642 628 618 607 597 589 583 577
28 714 691 674 659 647 638 628 620 613 607
29 746 724 706 690 678 667 659 651 644 637
30 779 758 738 723 709 698 690 682 674 668
31 813 792 771 755 742 729 719 710 703 696
32 847 822 805 788 774 761 750 741 733 726
33 882 855 835 818 804 793 781 772 763 756
34 913 889 868 850 836 825 812 803 795 787
35 947 923 900 883 867 855 844 835 826 818
36 981 957 934 916 900 886 876 866 857 850
37 1016 989 967 949 933 919 909 898 889 881
38 1051 1022 1001 982 966 951 938 928 918 912
39 1083 1055 1035 1015 999 984 970 959 949 941
40 1117 1089 1066 1046 1029 1017 1002 990 981 972
Load capacity is measured in CCS.
Digitone receiver load capacity 16 to 25 second holding

time
Table 110: Digitone receiver load capacity 16 to 25 second holding time

r of 16 17 18 19 20 21 22 23 24 25
DTRs
1 0 0 0 0 0 0 0 0 0 0
2 2 2 2 2 2 2 2 2 2 2
3 8 8 8 8 8 8 8 8 8 8
4 18 18 18 18 18 17 17 17 17 17

Reference tables

r of 16 17 18 19 20 21 22 23 24 25
DTRs
5 31 31 31 30 30 30 30 30 30 29
6 47 46 46 45 45 45 45 44 44 44
7 64 63 63 62 62 62 61 61 61 60
8 83 82 82 81 80 80 79 79 79 78
9 103 102 101 100 100 99 99 98 98 97
10 125 123 122 121 121 120 119 119 118 118
11 147 145 144 143 142 141 140 140 139 138
12 170 168 167 166 165 164 163 162 161 160
13 193 192 190 189 188 186 185 184 184 183
14 218 216 214 213 211 210 209 208 207 206
15 243 241 239 237 236 234 233 232 231 230
16 268 266 264 262 260 259 257 256 255 254
17 294 292 290 288 286 284 283 281 280 279
18 322 319 317 314 312 311 309 308 306 305
19 347 344 342 339 337 335 334 332 331 329
20 374 371 368 366 364 361 360 358 356 355
21 402 399 396 393 391 388 386 385 383 381
22 431 427 424 421 419 416 414 412 410 409
23 458 454 451 448 445 442 440 438 436 434
24 486 482 478 475 472 470 467 465 463 461
25 514 510 506 503 500 497 495 492 490 488
26 544 539 535 532 529 526 523 521 518 516
27 573 569 565 561 558 555 552 549 547 545
28 603 598 594 590 587 584 581 578 576 573
29 631 626 622 618 614 611 608 605 602 600
30 660 655 651 646 643 639 636 633 631 628
31 690 685 680 676 672 668 665 662 659 656
32 720 715 710 705 701 698 694 691 688 686
33 751 745 740 735 731 727 724 721 718 715
34 782 776 771 766 761 757 754 750 747 744

Digitione receiver requirement Poisson 0.1 percent blocking

r of 16 17 18 19 20 21 22 23 24 25
DTRs
35 813 807 801 796 792 788 784 780 777 774
36 841 835 829 824 820 818 814 810 807 804
37 872 865 859 854 849 845 841 837 834 831
38 902 896 890 884 879 875 871 867 863 860
39 934 927 921 914 909 905 901 897 893 890
40 965 958 952 945 940 936 931 927 923 920
Load capacity is measured in CCS.
Digitione receiver requirement Poisson 0.1 percent

blocking
Table 111: Digitone receiver requirements Poisson 0.1 percent blocking
Number of DTRs DTR load (CCS) Number of DTRs DTR load (CCS)
1 0 26 469
2 2 27 495
3 7 28 520
4 15 29 545
5 27 30 571
6 40 31 597
7 55 32 624
8 71 33 650
9 88 34 676
10 107 35 703
11 126 36 729
12 145 37 756
13 166 38 783
14 187 39 810
15 208 40 837

Reference tables
Number of DTRs DTR load (CCS) Number of DTRs DTR load (CCS)
16 231 41 865
17 253 42 892
18 276 43 919
19 299 44 947
20 323 45 975
21 346 46 1003
22 370 47 1030
23 395 48 1058
24 419 49 1086
25 444 50 1115
Conference and TDS loop requirements

Table 112: Conference and TDS loop requirements
Network loops required TDS loops required Conference loops required

at 2 years
1–12 1 1
13–24 2 2
25–36 3 3
37–48 4 4
49–60 5 5
61–72 6 6
73–84 7 7
85–96 8 8
97–108 9 9
109–120 10 10

Digitone receiver provisioning
Digitone receiver provisioning

Table 113: Digitone receiver provisioning
DTR CCS DTR ports DTR CCS DTR ports

1–2 2 488–515 24
3–9 3 516–545 25
10–19 4 546–576 26
20–34 5 577–607 27
35–50 6 608–638 28
51–69 7 639–667 29
70–89 8 668–698 30
90–111 9 699–729 31
112–133 10 730–761 32
134–157 11 762–793 33
158–182 12 794–825 34
183–207 13 826–856 35
208–233 14 857–887 36
234–259 15 888–919 37
260–286 16 920–951 38
287–313 17 952–984 39
314–342 18 985–1017 40
343–371 19 1018–1050 41
372–398 20 1051–1084 42
399–427 21 1085–1118 43
428–456 22 1119–1153 44
457–487 23 1154–1188 45
1189–1223 46 1961–1995 68
1224–1258 47 1996–2030 69
1259–1293 48 2031–2065 70
1294–1329 49 2066–2100 71

Reference tables
DTR CCS DTR ports DTR CCS DTR ports

1330–1365 50 2101–2135 72
1366–1400 51 2136–2170 73
1401–1435 52 2171–2205 74
1436–1470 53 2206–2240 75
1471–1505 54 2241–2275 76
1506–1540 55 2276–2310 77
1541–1575 56 2311–2345 78
1576–1610 57 2346–2380 79
1611–1645 58 2381–2415 80
1646–1680 59 2416–2450 81
1681–1715 60 2451–2485 82
1716–1750 61 2486–2520 83
1751–1785 62 2521–2555 84
1786–1802 63 2556–2590 85
1821–1855 64 2591–2625 86
1856–1890 65 2626–2660 87
1891–1926 66 2661–2695 88
1926–1960 67 2696–2730 89
2731–2765 90 2941–2975 96
2766–2800 91 2976–3010 97
2801–2835 92 3011–3045 98
2836–2870 93 3046–3080 99
2871–2905 94 3081–3115 100
2906–2940 95 3116–3465 101
Provisioning assumes an 11-second holding time.

Index
A
M
ACD (Automatic Call Distribution) ............................202
design parameters .............................................202
memory .....................................................................206
attendant consoles ...................................................201
C N
customer parameters ................................................200 networks, design parameters ...................................202
E S
engineering Meridian 1 systems .......................200–202
schedules (milestone chart) ......................................130
console/telephone parameters ...........................201
system parameters ...................................................200
customer parameters .........................................200
system parameters .............................................200
trunk and network parameters ...........................202 T
H telephones ................................................................201
hardware ...................................................................205 trunks ........................................................................202
design parameters .............................................205 design parameters .............................................202

NN43041-220 05.12 Communication Server 1000E Planning Engineering

Uploaded by

Copyright:

Available Formats

NN43041-220 05.12 Communication Server 1000E Planning Engineering

Uploaded by

Document Information

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

NN43041-220 05.12 Communication Server 1000E Planning Engineering

Uploaded by

Copyright:

Available Formats

Communication Server 1000E Planning

2 Communication Server 1000E Planning and Engineering May 2012

Chapter 1: New in this release........................................................................................... 15

Communication Server 1000E Planning and Engineering May 2012 3

4 Communication Server 1000E Planning and Engineering May 2012

Communication Server 1000E Planning and Engineering May 2012 5

6 Communication Server 1000E Planning and Engineering May 2012

Communication Server 1000E Planning and Engineering May 2012 7

8 Communication Server 1000E Planning and Engineering May 2012

Communication Server 1000E Planning and Engineering May 2012 9

10 Communication Server 1000E Planning and Engineering May 2012

Communication Server 1000E Planning and Engineering May 2012 11

12 Communication Server 1000E Planning and Engineering May 2012

Communication Server 1000E Planning and Engineering May 2012 13

May 2012 Standard 05.12. This document is up-issued to include additional

Communication Server 1000E Planning and Engineering May 2012 15

16 Communication Server 1000E Planning and Engineering May 2012

June 2009 Standard 03.04. This document is up-issued to include an introduction to

Communication Server 1000E Planning and Engineering May 2012 17

May 2007 Standard 01.01. This document is issued to support Nortel

18 Communication Server 1000E Planning and Engineering May 2012

Getting technical documentation

Getting product training

Getting help from a distributor or reseller

Communication Server 1000E Planning and Engineering May 2012 19

Getting technical support from the Avaya Web site

20 Communication Server 1000E Planning and Engineering May 2012

Communication Server 1000E Planning and Engineering May 2012 21

About this document

22 Communication Server 1000E Planning and Engineering May 2012

Communication Server 1000E Planning and Engineering May 2012 23

Hardware VxWorks Linux Server Co-res CS and Gateway

24 Communication Server 1000E Planning and Engineering May 2012

Communication Server 1000E Planning and Engineering May 2012 25

Engineering a new system

Engineering a system upgrade

26 Communication Server 1000E Planning and Engineering May 2012

Figure 1: Engineering a new system

Communication Server 1000E Planning and Engineering May 2012 27

Communication Server 1000 task flow

28 Communication Server 1000E Planning and Engineering May 2012

Figure 2: Communication Server 1000E network task flow

Communication Server 1000E Planning and Engineering May 2012 29

Figure 3: Communication Server 1000E deployment task flow

30 Communication Server 1000E Planning and Engineering May 2012

Communication Server 1000E Planning and Engineering May 2012 31

32 Communication Server 1000E Planning and Engineering May 2012

Communication Server 1000E Planning and Engineering May 2012 33

Jurisdiction Standard Description

34 Communication Server 1000E Planning and Engineering May 2012

Jurisdiction Standard Description

Notice for United States installations

Communication Server 1000E Planning and Engineering May 2012 35

Hearing aid compatibility

FCC compliance: Registered equipment for Direct Inward

36 Communication Server 1000E Planning and Engineering May 2012

Radio and TV interference

Notice for Canadian installations

Communication Server 1000E Planning and Engineering May 2012 37

Radio and TV interference