IT Infrastructure Requirements Needed To Run SAP BCM Software

INFRASTRUCTURE OVERVIEW
SAP BUSINESS
COMMUNICATIONS
MANAGEMENT SOFTWARE
(SAP BCM)
Software version 7.0

th
7 of November 2011
© SAP AG
©SAP AG 2007
© Copyright 2012 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express
permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of
other software vendors.
 Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of
Adobe Systems Incorporated in the United States and/or other countries.
 Innovaphone, IP3000 and IP6000 are registered trademarks of innovaphone AG.
 Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or
registered trademarks of Citrix Systems, Inc.
 Hewlett-Packard is a registered trademark of Hewlett-Packard Company. (Hewlett-Packard®)
 HP is a registered trademark of Hewlett-Packard Company. (HP®)
 HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web
Consortium, Massachusetts Institute of Technology
 IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,
OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli,
Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of
IBM Corporation.
 Audiocodes and Mediant are trademarks or registered trademarks of Audiocodes Limited.
 Java is a registered trademark of Sun Microsystems, Inc.
 JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented
and implemented by Netscape.
 MaxDB is a trademark of MySQL AB, Sweden.
 Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
 Oracle is a registered trademark of Oracle Corporation.
 SNMPc, is a trademark of Castle Rock Computing.
 UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services
mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in
Germany and in several other countries all over the world. All other product and service names mentioned are
the trademarks of their respective companies. Data contained in this document serves informational purposes
only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its
affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any
kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only
warranties for SAP Group products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
CONTENTS
1 Introduction to SAP BCM infrastructure 5

1.1 Introduction to site landscapes and connectivity 5
1.2 Introduction to environmental and facility recommendations 7
1.3 Introduction to server hardware, operating systems and software 7
1.4 Introduction to gateways 8
1.5 Introduction to data center LAN 8
1.6 Introduction to customer LAN 9
1.7 Introduction to storage systems 12
1.8 Introduction to telephony and data connections 12
1.9 Introduction to user terminals 13
1.10 Introduction to security 13
1.11 Introduction to availability and manageability 14
1.12 Introduction to deployment, software distribution and configuration 15
1.13 Introduction to sizing 16
2 Site landscapes and connectivity. 18

2.1 Modules 18
2.2 Communication Channels 19
2.3 Virtual units 20
3 Environmental and facility recommendations 23

3.1 Physical security 23
3.2 High availability 24
4 Server hardware, operating systems and software 26

4.1 Servers 26
4.2 Operating systems 32
4.3 Software 32
5 Gateways 36
5.1 Distributing gateways 36
5.2 Connecting to a PBX 37
5.3 Miscellaneous settings 38
5.4 Cisco gateways 39
6 Data center LAN 40

6.1 Performance 40
6.2 Availability 42
6.3 Multiple Sites 45
7 Customer LAN 50
7.1 Availability 50
7.2 Ability to carry voice 50
8 Storage systems 52
8.1 RAID arrays 52
8.2 SAN systems 53
9 Telephony and data connections 54

3
9.1 Telephony connections 54
9.2 Data connections 54
10 User terminals 57
10.1 CDT 57
10.2 IP Desk Phones 57
11 Security 59
11.1 Network traffic control 59
11.2 Identification, authentication and authorization 59
11.3 Signed software modules 59
11.4 Encrypted network traffic 59
12 Availability and manageability 60

12.1 SAP BCM HAC 60
12.2 SAP BCM Alarm Server 61
12.3 SNMP 61
12.4 Miscellaneous 62
13 Deployment, software distribution and configuration 63

13.1 Software distribution 63
14 Sizing 64
15 Interoperability with other systems 65
16 Glossary 67
17 Appendix A: Sample SAP BCM Servers 76
4
INTRODUCTION TO SAP BCM INFRASTRUCTURE
1 Introduction to SAP BCM infrastructure

The SAP Business Communications Management (SAP BCM) software provides a multi-channel, all-IP
communications platform for customer care operations and enterprise telephony. With SAP BCM organizations
can deploy IP telephony for everyone who needs it, including telemarketing experts, customer service agents,
switchboard operators, office workers, mobile experts, and their managers. SAP BCM is the telecommunication
technology of today. It is a single integrated system based on open IT standards and enables customers to
 Manage phone calls, emails, short messages and web contacts in a single, software-based solution.
 Utilize a full range of communication devices such as soft phones on PC desktops, IP desk phones and
mobile phones.
 Connect mobile and globally scattered workforce.
 Manage distributed know-how and utilize the right people with the right skills from front-office agents to
back-office specialists.
 Smooth migration, security, reliability and scalability upon deployment.
SAP BCM infrastructure is everything needed to run the SAP BCM software, such as servers, networks,
gateways and terminals. An enterprise can set up a SAP BCM in-house system or a service provider can offer
SAP BCM functionality to end customers. In-house and service provider setups are basically similar and the
main differences are due to service providers striving towards multitenant and/or multi-instance setups to
achieve cost efficiency and simultaneously facing a variety of and sometimes even contradictory end user
requirements. While an in-house system does not logically differ from a hosted service entity providing the
same service, an in-house system may be considered more stable in terms of various software and hardware
updates. This puts harder requirements on operations and manageability for service providers who, on top of
this, have their own requirements on for example scalability, security and total cost of ownership (TCO).
1.1 Introduction to site landscapes and connectivity

A SAP BCM system is comprised of Windows servers running Microsoft SQL, Microsoft Internet Information
Server (IIS) and SAP BCM. Clients are soft phones (PC), IP desk phones and user terminals running on mobile
phones. In addition, there are gateways carrying external calls to and from the SAP BCM system to the public
switched telephone network (PSTN) and IP networks interconnecting the servers, gateways and user terminals.
CMC
PSTN/PLMN subscribers
IP over
GPRS/EDGE/3G
PSTN
Internet
PLMN
PRI
- Electrical and mechanical adaptation
-ISDN Q.931 to/from SIP or H.323
GATEWAY conversion (signalation)
- 64 kbit/s PCM to/from G.711
conversion (audio stream) BCM
Server
(CS)
100/1000Base-T Ethernet
IP v4
Client
BCM & IIS SIP / IP desk
SQL CDT terminals
Server phone
Server
Figure 1. A Basic SAP BCM in-house landscape.
5
Figure 1 shows a basic SAP BCM in-house landscape in which a voice over IP (VoIP-) gateway is connected to
the telephone network over a 2 Mbit/s PRI line. The gateway adapts the protocols and characteristics on the
PSTN side to those used on the local area network (LAN) side. The PRI line is provided by a telco and a
telephone number range is normally included with the subscription. The gateway and the LAN is setup and
maintained by the Enterprise. Communication Mobile Client (CMC), the mobile client of SAP BCM, gains
access over IP over GPRS/EDGE/3G through a SAP BCM Connection Server in a demilitarized zone (DMZ). In
this simplified landscape illustrating the principles, the SAP BCM Server contains any required SAP BCM
modules and integration interfaces whereas the SQL Server contains operational and reporting databases.
Real setups might contain separate SQL Servers for operational and reporting purposes and SAP BCM
components might be distributed over two or more servers depending on performance, administrative, security
etc. conditions.
PSTN/PLMN subscribers CMC

IP over Client
GPRS/EDGE/3G
PSTN
Internet
PLMN
PRI - Electrical & mechanical adaptation

-ISDN Q.931 to/from SIP or H.323
conversion (signalation)
GATEWAY - 64 kbit/s PCM to/from G.711
conversion (audio stream)
BCM
100/1000Base-T Server
Ethernet IP v4 100/1000Base-T Ethernet
IP v4 Access Network (CS)
Inside Network
BCM
Server
SQL (CEM, CD, MsgToMail, BCM & IIS
Server MsgToSMS, MsgCleaner, Server
PDC, HAC, AS, IA, VUA) (CS, MRS,
HBR, SBR, ETC, UIMS,
Integration Interfaces)
Service link
WAN
Access link
SIP / IP/
phone
100/1000Base-T Ethernet
IP v4
Client
CDT terminals
Figure 2. A Basic SAP BCM service provider landscape.
6
Figure 2 shows a basic SAP BCM service provider landscape. The service provider could equally well be an
external commercial service provider or an internal corporate department providing the service to other
departments. It contains the same SAP BCM components as the in-house landscape. Terminals and users
reside in an enterprise network connected to a service provider network over a wide area network (WAN)
connection. Multitenant and/or multi-instance setups are key issues for a service provider to achieve acceptable
TCO. To be able to run several customers securely on a shared infrastructure, the service provider network is
compartmentalized into an inside network and an access network. Direct customer access is restricted to SAP
BCM components in the access network only on an as-needed basis and SAP BCM components in the access
network are granted access to resources in the inside network on an as-needed basis. The multitenant and/or
multi-instance architecture allows for several customers to share common service provider equipment and
resources, such as servers and networks, facilitating service provider efficiency and competitiveness on the
market.
Chapter 2, Site landscapes and connectivity covers this topic in more detail.
1.2 Introduction to environmental and facility recommendations

The nature of SAP BCM services, dealing with phone calls and other communications channels, makes it
business critical. Because the availability of SAP BCM services depends on the underlying infrastructure, these
aspects have to be taken into consideration.
Some environmental and facility requirements are dictated by server and network equipment manufacturers
and are based on requirements from semiconductor and component manufacturers. Required operating
conditions such as temperature and humidity must be matched and power must be supplied for the services to
run. Available options are for example measures for power failures, alternate call routing and supplying power
for emergency calls.
Some requirements may arise from legislation, corporate security policies and risk management. These may
include administrative roles, passage control and site locations. Environmental and facility requirements should
only partly be considered technical IT issues because they are also business strategy issues and dealing with
them is company and service provider individual.
Chapter 3, Environmental and facility recommendations, covers this topic in more detail.
1.3 Introduction to server hardware, operating systems and

software
SAP BCM servers run the SAP BCM software, Microsoft IIS 6.0 and 7.0 and Microsoft SQL Server 2005 or 32
or 64 bit SQL 2008 on industry standard x86 based server hardware. Servers and desktops are engineered for
different usage. Servers are specifically designed to hold, manage, send and process data. The technologies
behind servers make them more reliable and scalable than desktop systems and help them process data faster
and more efficiently than desktop systems. One significant benefit of servers is that their configurations can be
customized to meet very specific needs, such as disk I/O and/or capacity, so servers can be designed to
provide maximum return for the investments.
Deciding the needed server setup requires investigation in and awareness of for example estimated capacity
demands in terms simultaneous phone calls, number of users and customers. Affecting factors may have very
different importance in different setups. Some factors might be relatively static for enterprises providing the
services internally and some might be even unforeseeable for service providers. Especially service providers
should consider their estimated growth speed, scaling strategy and intended service level agreements (SLA).
An in-house system might consist of a couple of entry-level servers whereas a service provider might run
clustered SQL databases, distribute SAP BCM components over several servers, provide failover nodes for
each and benefit from fault-tolerant LAN’s and fault-tolerant high performance storage area networks (SAN).
Supported operating systems are English versions of Windows Server 2003 and Windows Server 2003 R2,
both referred to as Windows 2003 in this context, and 32 and 64 bit Windows Server 2008. Supported editions
are Standard and Enterprise. SAP BCM is a 32-bit software. Microsoft SQL runs on 64-bit systems as well.
Datacenter and Itanium editions are not supported.
7
For supported and recommended hardware, operating systems and software see appendix A, SAP BCM
infrastructure compatibility list (ICL).
Chapter 4, Server hardware, operating systems and software covers this topic in more detail.
1.4 Introduction to gateways

PSTN networks are connected to IP networks through VoIP-gateways. Gateways provide electrical and
mechanical adaptation between the two networks and perform protocol and voice stream translation as figure 3
shows.
10/100 Base-T Ethernet E1, T1 or J1 line

to IP network to PSTN
DHCP, TFTP
TELNET Q.931
HTTP Q.921
VoIP GATEWAY
SIP, H.323 64 kbit/s PCM
G.711, G.729 56 kbit/s PCM
........
Figure 3. Gateways provide electrical and mechanical adaptation between PSTN and IP/Ethernet networks and
perform protocol and voice stream translation.
SAP BCM supported gateways are available with support for E1, T1 and J1 PRI lines to the PSTN. E1 lines are
used in Europe, T1 in America and J1 in Japan.
One E1 line may be channelized into 32 DS0 channels, one of which is used for synchronization, one as the D-
channel (signaling channel) and 30 as bearer channels for voice streams (phone calls). One T1 or J1 line may
be channelized into 24 DS0 channels, one of which is used as the D-channel.
Gateways are connected to IP networks with 10/100 Base-T Ethernet links. Gateways are controlled by SAP
BCM using the protocols SIP or H.323. Gateways typically support at least dynamic host configuration protocol
DHCP for IP address provisioning, trivial file transfer protocol (TFTP) for configuration provisioning and Telnet
for configuration. Most gateways also provide a web interface for administration and configuration.
Gateways may be distributed geographically for example over different telco areas or to different satellite sites
of a service provider or customer. This allows local calls to satellite sites and enables cost optimization by
routing calls over IP to the most profitable gateway. Distribution of gateways may thus influence telephony
costs and may also have positive impact on failure resistance and data line bandwidth demands. Gateways
may also be connected to private branch exchanges (PBX) over PRI enabling calls between legacy telephony
systems and VoIP systems. In fact, interconnecting the two systems is a commonly used method allowing for
flexible migration phases.
Chapter 5, Gateways, covers gateways in more detail.

Chapter 9, Telephony and data connections, covers PSTN lines in more detail.
1.5 Introduction to data center LAN

Data center LAN refers to the LAN, where the SAP BCM Servers reside and where the SAP BCM services are
produced. Although emphasis here is on service provider data center LANs, this information might give
enterprises ideas when designing their in-house landscapes.
High service availability and manageability are crucial for a service provider. Among many other things, service
supply and underlying infrastructure have to be carefully designed to meet market demands. Growth strategies
8
have to be prepared and risk mapping must be done. Various problem scenarios are covered by building fault
tolerance and automatic or manual failover mechanisms. Nevertheless, a service provider providing numerous
customers’ with business critical communications services is encouraged to prepare for the unexpected and
narrow down the impacts of service supply failures. This can be done for example by segmenting the
production environment into more or less self-sufficient production units constricting the impacts of a failure of
one production unit from other production units. To be self-sufficient, a unit would include all layers from the
bottom of the infrastructure all the way to the service interface towards the customer. It is an ongoing task of
growth, risk and business management to decide how many production units to run, how to design them and
when to start new ones. Figure 4 shows one approach of segmenting the data center LAN.
Customer A Customer B Customer C Customer D Customer E
Customer A Customer E
Service Service
realization realization
BCM/IIS BCM/IIS
MGMT BCM
BCM/IIS SERVER SERVER(S) BCM/IIS
AD
SERVER(S)
SQL BCM
CLUSTER SERVER(S)
BCM/IIS BCM/IIS
BCM/IIS BCM/IIS
Access
Medium Network Network Core Network
Figure 4. A sample segmentation model of data center LAN. The middlemost area constitutes a fault-tolerant
core network all services depend on. The next orbit is a medium network for purposes of separating the core
network from the outermost access network, where the services are made available for the customers. The
green and red areas, service realizations, describe the required portion to produce a service for a customer.
The landscape conforms to the basic service provider landscape shown in figure 1, except for the missing CMC
option.
Chapter 6, Data center LAN, covers this topic in more detail.
1.6 Introduction to customer LAN

The customer LAN refers to the LAN where the SAP BCM service is consumed. In an in-house installation,
SAP BCM services are also produced locally in the customer LAN. If SAP BCM services are provided by a
service provider, the customer LAN is connected to the SAP BCM service with an access link and optional
back-up links. Multi-office customers have the options to access SAP BCM services via access links to each
9
office or via WAN/MAN links interconnecting the offices to a common access link or via any combination of
these.
Figure 5 shows a single site customer LAN connected to a

PSTN SAP BCM service provider. All services are provided from
the data center LAN and accessed over a WAN connection
by users in the customer LAN.
E1/T1/J1
spanns External telephony is routed over one or more PRI
GW (E1/T1/J1) connections to/from the PSTN. The subscriber
of the PRI connection is typically the customer but it may
also be the service provider and the same applies to the
Data center access link, which may be any link capable of providing
LAN sufficient bandwidth and performance, such as a point-to-
BCM & IIS point or a multi protocol label switching (MPLS) link.
SQL
The service provider is responsible for keeping the services

up and running by performing various daily maintenance
tasks and production environment reassessment as service
Service link demands increase and thus maintaining acceptable and
agreed service levels.
The telcos and/or ISPs are responsible for the operability

WAN and service levels of data and telephony links. The
subscriber of the links is responsible for the suitability and
sufficiency of the subscribed links.
The most demanding requirement regarding the data link

Access link and the LANs, besides the overall operability, is the ability
to carry real-time streams without introducing unacceptable
delays or delay variations (jitter). The customer is
responsible for maintaining the customer LAN´s capability
of carrying voice traffic with acceptable quality.
Customer
LAN As a rule of thumb, well performing switched 100 Base-T
Client and 1000 Base-T networks are well fitted for IP telephony.
Figure 5. A single site customer LAN

connected to a SAP BCM service
provider.
10
Service link Service link
WAN WAN
Access links
Site 1 Site 2 Site 1 Site 2

LAN LAN LAN LAN
Client Client Client Client
Site 3 Site 3
LAN LAN
Client Client
Enterprise Enterprise
Network Network
Figure 6. A multi-site customer LAN with one Figure 7. A multi-site customer LAN with one
access link per site. common access link.
Figure 6 shows a landscape of a customer with three sites, each connected directly to the SAP BCM service
provider. External telephony is routed over the access links. Internal telephony may be routed over the access
links or links interconnecting the sites. Back-up connectivity may be provided over the links interconnecting the
sites.
Figure 7 shows a landscape of a customer with three sites sharing a common access link to the SAP BCM
service provider. Links interconnecting the sites must be dimensioned for carrying the telephony traffic and
back-up routes and/or access links should be considered.
Sorting out the most suitable approach for each case involves investigating the current enterprise network
topology and its fault tolerance, finding out user concentrations and estimating the bandwidth demand on
different parts of the network. Also, existing traffic profiles and regular and casual peak loads should be
considered especially on interconnecting links, which often are slower than the site LANs. Quality of service
(QoS) controls may be applied to the interconnecting links and sometimes to the site LANs as well.
In general, there are three factors deteriorating voice quality in a network point of view. They are too long one-
way delay, packet loss and jitter. One way delay problems suggest network design problems and that
fundamental incompatibility exist between the current network implementation and the demand of carrying
quality voice over it. For example, it could be a too slow link over a too long distance without even theoretical
ability to achieve demanded performance.
Packet loss or extensive number of retransmissions and cyclic redundancy check (CRC) errors implies
hardware or configuration problems, such as speed or duplex mismatches, poor connectors, damaged or poorly
mounted cabling or exceeded environmental conditions. These two problem types, too long one-way delay and
packet loss, including retransmissions and CRC errors, are remedied by one time actions. Once the root cause
is identified, the problem is solvable permanently. Drops can be monitored in many ways, for example routers
and switches usually have drop counters. Too long one-way delay is immediately recognized by overlapping
speakers. Delays can be estimated from the round trip shown by ping.
Jitter is variation of one-way delay and is compensated to a limited extent by jitter buffers on gateways and
terminals. A constant stream of digitized voice data must be supplied to an AD converter in order to get
constant analog sound. If the digitized voice stream is interrupted or delayed, there will be an outage on the
analog sound deteriorating the voice quality. Jitter problems can be remedied by applying QoS controls and
revising network topologies to minimize congestions.
Chapter 7, Customer LAN, covers this topic in more detail.
11
1.7 Introduction to storage systems

Storage systems refer here to hard disk storage used by SAP BCM and underlying infrastructure for saving
operating systems, applications and data. Storage is necessary for each server, but storage capacity,
performance requirements and availability requirements may vary depending on server roles and utilization.
Storage design may also impact how servers are managed and maintained.
SAP BCM allows for setups with redundant servers. This means there are preconfigured up-to-date failover
servers available in case of server crashes. These, kind of disposable, servers should not contain any user
data, such as recorded files, voicemails or attachments. Neither should they contain any usage data that is not
afforded to be lost in case of a server crash.
All failover events are not invisible to users and securing server storage improves reliability and eases system
maintenance. This can be done using fault-tolerant disk configurations such as
- RAID-1
- RAID-5
- RAID-10
Some data must be made available for all servers sharing a common role, such as SQL servers and file
servers. For example if a SQL Server cluster node fails, a back-up node must be able to mount the storage and
access the database. Clustered server packages with integrated disk arrays constitute one possibility to fulfill
this requirement. Another possibility is to use Storage Area Networks (SANs).
SANs provide centralized storage capacity to distributed servers in such a way that the storage seems to be
locally attached in the operating systems point of view. Servers can be booted from SANs so SANs makes it
possible to use diskless servers, in the sense that no disks are installed physically in the server.
This approach allows servers to be easily replaceable “dummy” electronics boards that are ever less
individualized or designated for any specific task, potentially giving more flexibility in production operations,
upgrades and scaling tasks. SANs provide high performance disk I/O. Servers are connected to the SANs with
Fibre Channel links or Ethernet links. In the former case the server requires a host bus adaptor (HBA).
SANs introduce a potential for regarding different life spans for servers and storage. Although a SAN system is
scalable itself and there are different classes of SANs, a SAN system is one of the biggest single investments in
a SAN-based SAP BCM infrastructure. Whilst being that, a longer life span should be considered for a SAN
than for a server as perfectly intact servers grow old as operating systems and applications evolve.
Chapter 8, Storage systems, covers this topic in more detail.
1.8 Introduction to telephony and data connections

Data links refer to access and service links connecting the customer LAN to the data center LAN and carrying
voice streams, signaling information and UI data to/from SAP BCM servers and gateways from/to SAP BCM
user terminals, such as soft phones and IP desk phones.
Telephony connections refer to E1/T1/J1 PRI links carrying phone calls between gateways and the PSTN. SAP
BCM does not directly require any special technology for data links as long as sufficient IP performance is
provided and the same applies to the telephony links as long as the gateways they are connected to provide
SIP or H.323 over IP on the network side.
SAP BCM supported gateways support ISDN PRI E1/T1/J1 telephony links. Telephony links are provided by a
telco and telephone number ranges are allocated to each link or group of links. Gateways, and thus telephony
12
links, may be concentrated in a data center or distributed to customer premises, branch offices or other points
of presence. For availability purposes, telephony links may also be distributed over two or more telephone
exchanges or sometimes even over two or more telcos.
Access and service links are required in service provider cases only. For a service provider, it is often
reasonable to build a high-density service link to one or more ISPs and have them provide the access links to
the customers. If telephony links are centralized in the data center, all SAP BCM related traffic will pass over
the service and access links. If gateways are distributed to customer locations, a relevant part of the voice
streams may exist only inside the customer LAN and thus access link bandwidth demand may decrease.
Deciding the capacity and the customer side endpoint of the access link involves estimation of the maximum
number of simultaneous calls and call density estimations per locations in order to find the most suitable
endpoint location. Minimizing the network distance between the endpoint and the call density center allows for
maximum average call quality expectations.
Chapter 9, Telephony and data connections, covers this topic in more detail.
1.9 Introduction to user terminals

There are three types of user terminals, soft phones, IP desk phones and mobile terminals.
Communication Desktop (CDT) is the SAP BCM Microsoft IE browser based soft phone including numerous
features such as directories and PRS (presence) profile management. A handset or headset is used with CDT.
The handset/headset connects to a USB port of a PC either directly or via an adaptor performing the analog-to-
digital (A/D) transformation. The BCM Outlook phone is an alternative for CDT with suppressed functionality.
Supported IP desk phones are SIP phones. IP desk phones are voice stream and signaling information
endpoints and they are quite independent units resembling legacy telephone terminals. They do not provide the
advanced features of CDT.
Mobile SAP BCM terminals are Nokia or Ericsson cellular phones running SAP CMC. SAP CMC provides
directory services, PRS management and call control to mobile users. The SIP functionality on some Nokia
phones enables to connect them to SAP BCM as SIP terminals over a wireless LAN.
Chapter 10, User terminals, covers this topic in more detail.
1.10 Introduction to security

SAP BCM provides telephony over IP and is normally used in private networks but not in public networks such
as the Internet. SAP BCM includes security instruments itself, such as identification, authentication and
encryption, but it relies also on security mechanisms in the underlying infrastructure.
In general, security aspects are present in several different levels and viewpoints. The primary concern of a
service provider might be to ensure the availability and integrity of the data center, that is, their business and
the services provided to customers, whereas the concerns of the customer might be availability and
confidentiality. Although the slightly different security viewpoints affect the security issue, overall security must
be considered and both service provider and customer demands must be met.
When the service is provided by a service provider and utilized by an end user, it is obvious that security roles
and responsibilities are divided to both parts. From the network landscape it can be observed that the data
connection between the data center and the service provider poses a potential threat from the service provider
to the customer and vice versa.
Important security mechanisms are access lists, traffic filtering and virtual LAN (VLAN) segmentation. Figure 8
gives an overview of protocols used by SAP BCM. Signed soft phone and mobile terminal components assure
the integrity and the manufacturer of the components. Server side authentication is achieved by certificates
from trusted certificate authorities.
13
SIP SIP Data Center LAN

RTP
SIP Bridge
CDT http(s)
RTP
Customer LAN ODBC

WACP WEB
WACP ODBC
CDT SQL
RTP
RTP
WACP
CEM&CD
RTP
CDT
H.323
H.323 Bridge
SIP H.323 Gateway

RTP PRI
PSTN
Figure 8. An overview of protocols used by SAP BCM.
Chapter 11, Security, covers this topic in more detail.
1.11 Introduction to availability and manageability

High availability in this context refers to high availability of service achieved by introducing fault tolerance and
disaster recovery. The fault tolerance architecture attempts also to provide good manageability. The idea is to
have a fault tolerant architecture performing manual and/or automatic failovers but unlike probably most cases,
not to do fallbacks. Failover may occur due to failures or avoidance of down-times during maintenance tasks
and therefore a more appropriate term than failover is switchover.
Interactions and attitudes of individuals can devastate even the best systems or make the worst possible
systems appear excellent. Therefore, it is important to understand existing fault tolerance and its entities,
mutual impacts between systems and/or their components and to undertake working methods to support
aspired service levels. High availability is not reachable with technical measures alone.
Enabling switchover operations due to maintenance task and/or failures requires that the ability to produce a
service exists in two or more places. The ability to produce a service includes CPU power, storage,
configuration data and network connectivity and so on. Making this ability generally available for all services
requires good management of SAP BCM infrastructure, awareness of available resources, awareness of the
committed service levels, proactive approaches in developing the infrastructure, engagement in undistorted
14
working methods and continuous testing. The idea of using only switchovers and not fallbacks is an important
part of testing. Switchover moves the source of the service in question from one entity to another and thus tests
the entities.
Adapting the switchover mechanism to version updates can result in that live production entities are never
updated. Arranging for a group of at least three similar service entities, one being active and two being standby,
enables to apply an update and to test it with minimal downtime. The update is applied to one of the standby
entities to which cannot be switched over to during the update. The other standby entity is there in case of a
failure of the active entity during the update.
When the update is applied, the entity can be tested, even by the customer, and when it is approved, a
switchover is performed to the updated entity. One of the remaining entities needs to be updated as well to
provide an equal version switchover entity or if it unacceptable to switchover from the updated version to the
previous version, an updated service entity must be arranged for in advance. Eventually, the old entities and
related resources are freed and available for other updates.
The described updating and maintenance practice allows for the actual updates and maintenance tasks being
performed during normal office hours without having to adapt to maintenance windows and strict time frames.
The update experienced by the user is only a rapid switchover.
SAP BCM provides management tools only for the application, such as:
- High Availability Controller (HAC)
- Infrastructure Administrator (IA, former IA + VUA)
- System Configurator
Management tools for the infrastructure are provided by each device manufacturer or some third party provider.
These tools include Telnet and/or browser-based device configuration and server management tools, such as
HP server management tools, simple network management protocol (SNMP) agents by hardware
manufacturers and SNMP management software.
High availability includes also ensuring quality voice in the customer LAN by implementing QoS. This protects
against voice quality impairments due to heavy network bandwidth consumption which may be caused by new
or improperly configured software or increased usage of existing software.
Chapter 12, Availability and manageability, covers this topic in more detail.
1.12 Introduction to deployment, software distribution and

configuration
SAP BCM deployment is a manifold task. It starts by finding out and defining the particular service to be
provided and its various parameters, such as:
- Schedules
- Queues
- Prompts
- Telephone number ranges and call volumes
When call volumes and server and agent locations are recognized, the network topology is decided. This
includes deciding the number of PRI lines, number of gateways and their locations and when this is done, the
15
number of required access links and their capacities can be decided. Also high availability requirements affect
the designing phase in terms of volume, number of access and telephony lines and number of servers used.
One important decision is whether to provide full or partial capacity in a failure situation. Full capacity means
that for some resources, double capacity is at hand when operating normally. These are crucial steps that might
have undesired impact if they are poorly designed and/or implemented.
Deployment also includes decisions on what terminals and accessories to use, such as the type of handsets
and/or headsets to be used with CDT and deciding the type of IP desk phones and to purchase these.
Once the above steps are completed, access lists can be designed. Typically, there is a firewall, router or layer
3 switch providing access control between the users and the servers. The particular access control
configuration depends on the used IP address ranges, the terminal and gateway models and the used
protocols.
The SAP BCM related client software is needed mainly by CDT. These are ActiveX components available as
msi files. The SAP BCM ActiveX components are signed by Wicom Communications Oy to convince the user of
their trustworthiness. These components can be distributed in any way suitable, e.g. using Microsoft systems
management server (SMS) or by installing copying them manually to each workstation. All CDT configurations
are done within CDT or via SAP BCM Management utilities by an administrator. IE, local firewall and so on
configurations are done with the respective software.
IP desk phone configurations are done manually using the keypad or (semi)automatically using DHCP, TFTP,
Telnet and/or browser-based administration tools. The facilities vary slightly between different manufacturers.
So far the soft phone is clearly the dominating terminal and IP desk phone configurations have mostly been
made manually using the keyboard of the phone and/or using a browser.
Chapter 13, Deployment, software distribution and configuration, covers this topic in more detail.
1.13 Introduction to sizing

Sizing involves various capacity requirements of components and devices constituting an operational SAP BCM
system, such as telephone links, access links, customer and data center LANs, gateways and servers.
The resource requirements of different SAP BCM components and the capacity they provide are discussed
here, for example a SIP bridge (SBR) can handle a maximum of 700 simultaneous SIP calls. Sizing does not
take count in capacity requirements for high availability solutions, it tells only what is required and achieved by
a single component or device. Spare and failover capacity has to be considered separately.
Scaling goes closely along with sizing and is covered as well. Especially for a service provider it is crucial to
consider scaling from the very beginning and to design the system accordingly in order to maximize cost
efficiency and prepare for future increases.
Since the current hardware development is rapid it would be easy to believe that hardware investments made in
advance are not profitable. However, over time hardware does not constitute the most expensive portion of the
business and standardizing might increase working efficiency and thus give savings in labor costs.
Designing a SAP BCM infrastructure that has high availability and is scalable should start with recognizing
some goals and margins, such as estimated total volumes in terms of:
- Customers
- End users
- Data lines
- Telephony lines
16
Particularly important is also to estimate the life cycle of the SAP BCM technical infrastructure, for example a
storage system may serve significantly longer than a server that might become outdated in three years.
Sizing rules are not always so simple and unambiguous because the usage pattern may vary a lot from case to
case depending on for example the implemented integrations channels. Especially e-mail channels and
channels that are converted into e-mail channels, such as web channels, may deal with numerous attachments
of various sizes that consume storage and network capacity.
To throw some light on sizing as number of servers, there are implemented systems with one Microsoft SQL
Server (cluster) and two SAP BCM servers perfectly dealing with up to 660 simultaneous calls and there are
systems where additional three servers have been installed as SIP and/or H.323 bridges dealing with 2000
simultaneous calls. Factors such as higher redundancy demands and backup sites may require additional
servers to be installed.
Usually the most expensive servers are high end, SAN attached and clustered Microsoft SQL servers and SAP
BCM application servers are more affordable.
Chapter 13, Sizing, covers this topic in more detail.
17
ENVIRONMANTAL AND FACILITY RECOMMENDATIONS
2 Site landscapes and connectivity.

Basic in-house and service provider landscapes are shown in section 1.1, Introduction to site landscapes
and connectivity. This chapter explains what modules are used and for what purposes, how different channels
are implemented, how virtual units (VU) are used and how systems are interconnected using the federation
bridge (FBR).
The specific behavior and functionality of any SAP BCM system is determined by the set of modules used and
their configurations. Any specific module is responsible for a logical set of functionality, for example if there is a
demand for sending and/or receiving SMS messages, the SMSToMail module is needed.
Channels refer to communications channels used to communicate externally and/or internally such as
telephony, fax and email.
Virtual units are used for administrative grouping of services. In a multitenant environment, where several
customers are served by the same hardware, virtual units are assigned customer specific resources such as IP-
addresses, directories and other settings.
Federation bridges enable two or more organizations to constitute a VoIP society where VoIP calls can traverse
from one to the other without passing through the PSTN.
2.1 Modules
A SAP BCM module is discrete product module run as a process. Modules are run in some virtual units context,
which typically contains its own resources such as IP-addresses, log file directories and configuration data.
2.1.1 Human interface modules

Human interface modules are a set of mostly web browser-based user interfaces that provide the end users to
access phone, directory and call history functionality and administrators to access administrative functions.
These modules are:
 CDT (Communications desktop) is the SAP BCM soft phone and the primary graphical user interface.
 CMC, Communication Mobile Client is a UI for mobile phones running on Symbian platforms.
 Communication Toolbar for MS Outlook (CT Outlook) is a plug-in to Microsoft Outlook providing
basic telephony functionality and one way calendar event feed from Microsoft Outlook to SAP BCM.
 Infrastructure Administrator (IA) is for controlling and monitoring SAP BCM software, for example
managing services, platforms, virtual units, web sites and viewing technical logs.
 System Configurator GUI is for managing call switching and stream protocols, Queues, Services and
SAP BCM Administrator accounts.
2.1.2 Service modules

Service modules are modules providing some specific functionality used directly by the user or indirectly by
some other module. These modules are:
 Alarm Server (AS), receives XML and/or HTTP alarms from any applications and filters and converts
them to SMS, email and/or SNMP alarms/messages and forwards them to desired targets.
 Call Dispatcher is for call routing, switching and control.
 Chat Portal Server provides a Chat Portal Interface for integrating third party chat servers.
 Chat Server manages chat discussions between participants.
 Connection Server (CS) provides a secure TCP tunnel between clients and servers.
18
 Contact Event Manager (CEM) is the core module of SAP BCM managing for example contact
requests, queues and contacts event auditing.
 Data Collector collects event data from various sources and stores them along with some pre-
calculated aggregates into various databases.
 External Terminal Controller (ETC) poses IP desk phones as CDT phones towards CEM.
 File Replication Service (FRS) performs file replication between local/remote directories.
 H.323 Bridge, (HBR) handles initiating, receiving, and controlling calls to/from H.323 gateways. It also
contains an H.323 registrar. It performs protocol translation from H.323 to SAP BCM protocols and vice
versa.
 High Availability Controller (HAC) is for monitoring and controlling software processes and
performing failover operations.
 Media Routing Server (MRS) is for handling audio and video streams to and from other modules or
components.
 Message to Mail (MsgToMail) sends e-mail messages from SAP BCM using SMTP (simple mail
transfer protocol).
 Monitoring Database stores and provides current statistics information.
 Reporting Database stores and provides reporting information.
 SAP CIC Adapter enables usage of SAP BCM contact center solutions as an integrated part of the
SAP myCRM solution.
 SIP Bridge, (SBR) handles initiating, receiving, and controlling calls to/from SIP gateways and IP desk
phones. It also contains a SIP registrar and performs protocol translation from SIP to SAP BCM
protocols and vice versa.
 SMS Engine sends and receives SMS messages between GSM network’s Short Message Service
Centers and the CEM database.
 SMS to Mail (SMSToMail) converts received SMS messages into email messages.
 WebClient is an IIS extension module providing a scripting language for generating HTML and XML
documents from data in databases and various HTML or XML templates.
2.1.3 Integration interface modules

 Online Interaction Interface Server provides Online Interaction Interface (OII) and Online
Monitoring Interface (OMI).
 SAP phone BCM provides the interface SAP phone statistics.
 WS2 server provides Administration and Configuration Interface (ACI), Directory and Availability
Interface (DAI) and Reporting Data Interface (RDI)
 TMI server provides Task Management Interface (TMI).
2.2 Communication Channels

The communication channels supported by SAP BCM are:
- Voice (telephony)
- E-mail
- Chat
- Web
- SMS
19
- Fax
Communications events from each channel are received and routed by SAP BCM according to predefined
rules, such as timetables, queues and skills.
2.3 Virtual units

Virtual units are administrative groupings of services. A virtual unit is assigned an IP-address and one or more
modules (virtual unit products) are added to it. A virtual unit is also a failover domain. If any service or resource
of a virtual unit fails, the whole virtual unit fails and its services are taken over by a failover virtual unit. Failover
proceedings may be automatically triggered by a monitoring event or they may be manual based on fault
detection or maintenance requirements. Exceptions are VU_HAC and VUA, because they never perform
failover.
The naming convention of virtual units is free, but specially in service provider setups it is worth creating a
naming convention suitable for supporting daily operations and maintenance. Logical and consistent naming
convention eases recognition and thus decreases the risk of human errors.
A grouping of services and processes to virtual units based on their functionality and access requirements is
recommended.
Grouping based on functionality can be as follows:
- VU_CORE for core components, such as CEM, CD and Data Collector

- VU_CONN for connectivity components, such as CS, ETC, SIP (for ETC) and Chat Server
- VU_BRIDGE for HBR, SBR and MRS
- VU_COM for communications components, such as SMS Engine
- VU_CEM_DB and VU_DPM_DB for databases.
Grouping based on access requirements can be as follows:
- VU_IWR for internal web services accessed by the system itself

- VU_WEB_ADMIN for administrative purposes and accessible only from the inside network
- VU_WEB_USER_CUSTOMER1 for end-user service access from customer1’s network
- VU_WEB_USER_CUSTOMER2 for end-user service access from customer2’s network
- VU_INT for integration services and interfaces accessible from the outside network, possibly one-to-one
access.
In a fault tolerant setup, each virtual unit has one or more identical virtual units configured on one or more
failover server(s). The virtual unit constitutes also a failover domain, that is the smallest assembly able to
perform a failover to a spare node.
20
INTERNET
- CMC CUSTOMER NETWORK
- CDT - VU_X
DMZ - Communication Toolbar MRS
- VUA - Outbound Desktop FRS
- VU_DMZ - Communication Task Management SBR
Internet Chat Client - IP Desk Phones HBR
CS_n
MGMT NETWORK ACCESS NETWORK

- VU_HAC - VU_HAC - VUA
HAC - VU_FBR - VU_FRS_n
AS FBR - VU_INT
- VU_WEB_USER Web Server
* or if with AS failover * Web Server Integration Interfaces
Web Clients Chat Portal Server
- VU_HAC Repoting Web Clients - VU_TERMINAL_n
HAC - VU_PSTN_n CS
- VU_AS SBR SBR (for ETC)
AS HBR - VU_WEB_REPORTING
MRS Web Server
- VUA Prompts Standard Reports
- VU_WEB_ADMIN
IA CORE NETWORK
Web Server - VU_HAC - VUA
Web Admin Tools - VU_CORE - VU_FRS_n
- VU_CONN CEM Server - PDC Server
- SNMP Chat Server - VU_COM
- Network Admin Tools ETC Communication
- VoiceEdit - VU_INTERNAL_n SMS Server
Web Server - VU_Prompts
Internal Web Services Prompts
Data_Collector - VU_CEM_DB
- VU_CPM_DB CEM Database
CPM Database CEM_History_DB
- VU_Report_DB CEM_Reporting_DB
Reporting Database
WWU_DB
DSAREA_DB
APO_DB
Figure 9. A SAP BCM virtual unit configuration sample.
Figure 9 shows a sample VU configuration. VU and module names ending with “_n” can typically have more
than one active instance and n is used to number those instances. It is recommendable to name the first
instance as VU_1 or module_1, although future instances seem unlikely, because it makes it simpler to keep
the naming convention later, if more instances are added after all.
The VUs in picture 9 can be further split into smaller VUs as follows:
- VU_X can be split into 4 VUs, one for each module.
- VU_WEB_USER can be split into 2 VUs each containing Web Server and one of the other modules.
- VU_PSTN can be split into 3 VUs, one for each module.
- VU_INT can be split into 2 VUs each containing Web Server and one of the other modules.
- VU_TERMINAL_n can be split into 2 VUs, one for each module.
- VU_CORE can be split into 3 VUs, one for each module.
- VU_INTERNAL_n can be split into 2 VUs each containing Web Server and one of the other modules.
- VU_COM can be split into 2 VUs, one for each module.
VU_X in the customer network is required if:
21
- Local gateways in the customer network are used (SBR and/or HBR).
- Local gateways retrieve prompts from local servers (MRS and/or FRS).
- Recordings, for example voice mail messages are saved locally.
Configuring VU_X also requires to setup a local VUA. Prompts are typically maintained by the service provider
and replicated to the customer site with FRS.
For the above setup the recommended minimum number of servers is five. Failover servers must be added to
this number. Failover servers do not have to be dedicated for a particular system, for example a pool of
production servers can target a single failover server. How many production servers a failover server serves is
based on risk analysis and is a business decision. The recommended five servers are:
- Management server in the management network.
- SAP BCM Core Server in the core network.
- SAP BCM Database server in the core network.
- SAP BCM Access Server in the access network
- SAP BCM DMZ Server in the DMZ network.
In an in-house setup, the network structure may be reduced as much as to one network containing all VUs or to
two networks if CMC and/or Internet Chat Client are used. In the latter case, it is strongly advised that VU_DMZ
reside in a DMZ network.
22
3 Environmental and facility recommendations

Suitable facilities assist in successful service management and operation and provide means for successful
business. Facility recommendations aim to improve physical security and high availability. Facilities may be:
- run and owned by an enterprise or a service provider

- rented
- outsourced
To outsource the hosting of networks and servers not only saves one from the maintenance burden but may
also significantly increase available expertise regarding the outsourced parts and enables the outsourcer to
concentrate the efforts on SAP BCM operations.
3.1 Physical security

The purpose of security is to protect the personnel and assets and keep the business running smoothly.
Physical security risk analysis and business impact assessment taking all possible physical threats into
count is needed to implement security efficiently. All threats should be covered but the security measures
should not be exaggerated. Below are examples of some physical security threats:
- Emergencies
- Fire and smoke contaminants
- Building collapse or explosion
- Utility loss (electrical power, air conditioning, heating, cooling)
- Water damage (pipe breakage)
- Release of toxic material
- Natural disasters
- Earth movement (such as earthquakes and mudslides)
- Storm damage (such as snow, ice and floods)
- Human intervention
- Sabotage
- Vandalism
- War
- Strikes
In general the following should be implemented:
- Walls (from the floor to the ceiling), floors, ceilings and doors have acceptable fire and strength
ratings. Windows are normally not acceptable. Doors must resist forcible entry.
- no nearby water pipes and shutoff valve locations are known and accessible
- passage control with audit trails
- intrusion detection and alarm
- fire detection, fire alarm and fire extinguishing
Emergency procedures should be implemented and practiced, such as:
23
- Emergency system shut down

- Evacuation
- Periodic equipment and system tests
3.2 High availability

In order to offer high availability services, proper facilities providing the demanded supply and connectivity,
protection against incidents and meaningful maintenance are needed.
3.2.1 Power supply

Power supply should always pass through UPS devices. In an online UPS the primary power source is a
UPS battery. Online UPS devices provide galvanic isolation from the supplying electricity network and
prevent undesirable current loops between devices connected to different switchgears.
An online UPS is very similar to the least expensive standby UPS in that it has the same two power sources
and a transfer switch that selects between them. It is the exact opposite from the standby UPS in that there
is no transfer time in the event of a power failure and it efficiently filters off peaks and noise coming from the
wall because those affect only the battery charger and not the inverter supplying the output power.
Power failures in the power distribution network are instantly covered by UPS devices. In a power failure
situation UPS devices are able to supply power for short times only, for a couple of hours, depending on the
UPS capacity and the power consumption. Generators are needed to protect against power failures that last
longer than the UPS is able to supply power. UPS devices cover easily the time it takes for generators to
start.
3.2.2 HVAC
HVAC stands for heating, ventilation and air conditioning. HAVC is needed to keep humidity and
temperature at acceptable levels, which are important parameters for electronic equipment.
Electronic components are designed to operate at some specified temperatures at which specified
tolerances are valid. Increasing temperature usually decreases electrical resistances and specified
tolerances ceases to apply and eventually the functionality becomes undefined.
Anti-static flooring is used to prevent static electricity and high voltage static electricity shocks from breaking
electrical circuits. Increased humidity leads to increased electrical conductivity in the air and prevents static
electricity but too high humidity leads to corrosion of leads of electrical components.
HVAC should be arranged so that it is tolerant to failure of one single HVAC system.
3.2.3 Utilities
Utilities that ease management and maintenance are appropriate equipment shelves and cable routes.
Rack cabinets are excellent for installation of rack servers and network devices. Devices should be easy to
install, recognize and remove. Well-defined cable routes allow for easily adding required cabling and for
removing unnecessary cabling.
3.2.4 Connectivity
Cable routes to the data center premises should be investigated. There should be at least two totally
separate routes entering the building on different walls. The separation of routes should remain inside the
building as close to the data center as possible. Alternate routes protect against failures on one of the
routes. Such failures could be caused for example by fire or by a digger breaking the cable miles away.
24
3.2.5 Sites
Multiple sites provide continuity guaranties in case of major incidents such as fires and total loss of
connectivity despite of alternate routes. In some cases alternate sites are required by law.
The same recommendations are valid for each site. Distances between sites should guarantee adequate
separation and independency of common data and power supply network nodes. This should be verified
with the local power supply operator and telco. In general, the distance should be at least 15 km.
Sites should be connected to each other with dual links backing up each other. These links and cable routes
should be all the way separate from each other. Typically IP and FC (Fibre Channel) connectivity is required
between sites, FC for connecting storage systems and IP for all the remaining traffic.
IP and FC connections can be carried over a single mode fiber pair by multiplexing different wavelengths or
colors to the same fiber pair. A third inter-site connection based on different technology such as SDH
(synchronous digital hierarchy) is recommendable for cluster heartbeat control traffic. Inter-site fiber
connections are typically 1 Gbit/s and for a third heartbeat connection 2 Mbit/s should be sufficient.
Multi-site landscape enables also partial service distribution. For example a customer setup can have PSTN
gateways in more than one site which can provide PSTN connectivity to more than one telephone
exchange.
25
SERVER HARDWARE, OPERATING SYSTEMS AND SOFTWARE
4 Server hardware, operating systems and software

SAP BCM servers refer to the server hardware running the SAP BCM components. Basically any industry
standard x86 32-bit server is capable of running a SAP BCM system. Selecting specific hardware is a result of
several aspects and is decided case-by-case. This chapter aims to give some guidelines for deciding on the
appropriate hardware.
4.1 Servers
Prerequisites for the server configuration are:
- Site and network topology

- Capacity demands in terms of virtual units and/or modules
- Availability demands
- Facility demands
Site and network topology together with capacity demands prescribes the number of servers in the basic set
and their specifications. Capacity refers to the number of virtual units and/or modules required.
Availability demands add failover servers to the number of servers in the basic setup.
Facility demands states the physical shape of the servers, such as tower, rack mounted or blade servers.
4.1.1 Number of servers

The number of servers depends, in most cases on network topology, availability demands and security issues
but as the setups get bigger, also on performance issues. The SAP BCM system is modular and easy to scale
up with increasing load. If performance at some point of time threatens to be a problem, it can be circumvented
by adding respective multi instance virtual units and/or modules on existing servers or on new servers.
It is a good idea to start understanding and/or designing the network layout properly and recognizing the
network location of involved SAP BCM components. For example in an in-house setup or demonstration
system, there might be only one core network, the enterprise LAN, and thus all components would reside there.
In such a case, the minimum number of servers is two, one running the databases and one running the other
components. This setup is suitable only for systems with light load and low availability requirements.
Site and network topology affects the number of servers required. Different network zones, such as DMZ and/or
management network, require separate servers. Site and network topology might also place requirements for
additional network interfaces on multi homed servers. The setup in figure 9, SAP BCM virtual unit configuration
sample, requires a minimum of four servers if no virtual units are located in the customer network.
Capacity demands affect the number of multi instance virtual units and/or modules (those named VU_n or
module_n in section 2.3., Virtual units) required and thus may also affect the number of servers. One server
may run more than one instance of any multi instance virtual unit or module. The restrictions of virtual unit and
module capacity do not necessarily correlate to CPU or I/O power. They can be due to the number of threads a
process may create or some other operating system or software-specific features. Chapter 14, Sizing, covers
this topic in more detail.
Availability demands determine precautions for eventual fault incidences and procedures for maintenance
tasks. Precautions for fault incidences are failover mechanisms. Failover can be configured in the following
ways:
26
- Manual failover
- Automatic failover
- Failover to other active SAP BCM servers
- Failover to inactive dedicated failover servers
Manual and automatic failover is covered in chapter 12, Availability and maintenance. This topic may affect
the number of required servers. With manual failover, an operator can choose the most suitable one of the
available failover destinations. With automatic failover, capacity must be prepared in advance at one or more
specific failover destinations.
If the set of active SAP BCM servers are only moderately utilized and the capacity budget allows it, failover
destinations may be configured within the set without using dedicated standby servers for failover. If utilization
increases over time, the setup can be reconfigured with one or more dedicated standby failover servers.
When maintenance tasks can be performed outside office hours there is no 24/7 demand and there is no
demand for additional failover destinations for maintenance reasons. If it is not possible to perform maintenance
outside office hours because of a 24/7 demand, failover destinations must be available to enable uninterrupted
service during maintenance.
4.1.2 Type of servers

SAP BCM runs on industry standard x86 based server hardware. There are several selection criteria for the
servers and the emphasis may vary from case to case. The most essential criteria are described below.
4.1.2.1 Storage and application servers

From a functional point of view two types of servers are used:
- Storage servers with significant file I/O, storage capacity and backup demands
- Application servers with performance focus on CPU and networking
Storage servers refer to SAP BCM (SQL) database servers and file servers. SAP BCM database servers are
used for storing for example system configuration, user accounts and call detail records (CDR). File servers are
used for storing for example prompts, voice mail messages, recordings and attachments. Storage servers
contain both static data (configuration and user data) and dynamic accounting data (CDR).
The static data is crucial to the operation of SAP BCM and therefore attention must be paid to its availability. It
is recommended that static data is kept on clustered servers and that the data is regularly backed up.
The dynamic data is not crucial to the ongoing operation of SAP BCM, but its value is often essential because
of billing, production control, service control or other business related issues and may thus be vital to the
service provider and/or to the customer. It is recommended that dynamic data is kept on clustered servers and
that the data is regularly backed up.
27
Application servers run different SAP BCM virtual units. They retrieve process and/or store data between users,
other modules and data storages. Application servers are replaceable in the sense that they do not contain any
crucial data and their assignments can therefore be overtaken by other servers.
Performance characteristics have emphasis on file I/0 and storage capacity for storage servers and network I/0
and CPU for application servers.
4.1.2.2 Server chassis and operability

It might seem that there is no, or very little, importance in what type of server chassis is selected. As noticed
earlier, this also may vary from case to case and it may have considerable importance in some cases. Server
chassis alternatives are:
- Tower
- Rack
- Blade
Tower servers are recommended for in-house setups, where the existing facilities do not require any other type
of servers to be selected. Tower servers often have the space for sufficient RAID (redundant array of
inexpensive disks) disks, integrated sophisticated RAID controllers and enough slots for possible additional
RAID controllers and network interface cards. The drawbacks of tower servers compared to the others are:
- Big space requirements.

- Lack of built-in KVM (keyboard, video, mouse) switches/multiplexers.
- Discrete power and network cabling.
Rack servers are designed to be mounted in a server cabinet. The advantages of using rack servers are:
- More effective space usage

- Better order and control of servers and cables
- Possibility to arrange and adjust power and cooling on a per cabinet basis.
- Some rack servers contain built-in KVM switches enabling a group of servers to be operated
from one console.
Rack servers come in different sizes or heights. The height of rack servers is measured in units (U) where one
U is the minimum height of a device that can be installed in a cabinet. A cabinet may contain for example 40 or
42 U. One U servers are usually suitable for application servers whereas, storage servers require more space
for disks and possible additional network and/or RAID boards. Rack mount kits are available for some tower
servers.
Attention should be paid to the cooling of rack mounted servers. Cooled air should flow through the cabinet, for
example from the bottom to the top.
Rack-mounted servers are a good choice for enterprises and service providers running several servers.
28
Blade servers are electronics boards that are installed to a blade chassis. The blade chassis is installed in a
similar cabinet as rack servers. The blade chassis provides power and required interfaces to the blade. Benefits
of blade servers are:
- The most effective space usage
- Integrated cabling, power, network and storage
- In some cases, integrated LAN switches
- Integrated KVM switches
- Improved reliability due to the integrations
- Possibility to configure hot standby blades
Regardless of the selected chassis type, the following features are recommended:
- Dual power supplies for increased availability
- Dual fans for increased availability
- Management, such as HP ILO and/or SNMP for retrieving notifications of possible failures or
arising problems.
- Separate physical network interfaces for each network (core, access, management) the server
connects to.
29
4.1.2.3 Server specifications

These server specifications are indicative. The recommended specifications are based on experiences from
existing installations in service provider and in-house setups. Below are the minimum and recommended server
specifications.
Server, File
Application
Application
SAP BCM
SAP BCM
SAP BCM
SAP BCM
Storage
Storage
Server,
Server
server
server
Feature
SQL
light
MIN REC MIN REC MIN REC MIN REC
>2 >= 2
CPU speed 1 GHz > 1 GHz 1 GHz >= 2 GHz 2 GHz 1 GHz
GHz GHz
Number of CPUs and

1 1 1 1-2 1 1-4 1 1
cores together
4 – 32
RAM 1 GB 1 GB 1 GB 2 - 4 GB 4 GB 1 GB >= 2 GB
GB
100 or 1000
100 100 100 100 100 1000
Network interface 1000 Base-
Base-T Base-T Base-T Base-T Base-T Base-T
Base-T T
Number of network
1 1 1 1-2 1 1-3 1 1-3
interfaces
Operating system on
Yes Yes Yes - Yes Yes Yes Yes
local disks
Data on local disks Yes Yes Yes - Yes No Yes No
Operating system on
- - - Yes - No - No
SAN
Data on SAN - - - Yes - Yes - Yes
A SAP BCM light application server is running only few SAP BCM components. For example, a SAP BCM CS
(connection server) located in a DMZ serving connections from SAP BCM CMC clients could be considered a
light server.
The design aspects of the entirety may lead to standardizing application server configurations and to thus make
the hardware interchangeable, so that any SAP BCM light application server can be assigned the tasks of any
other SAP BCM light application server without any need to upgrade the hardware. An arrangement including
some minor additional investments in hardware, such as RAM, are required but is facilitates in maintenance
efforts.
It is possible to assign processor resources in a multi-core environment running multiple SQL Server instances
so that, for example, each SQL Server instance uses its own CPU core.
SQL Servers benefit from all available RAM. In a multi-instance installation, the amount of RAM available for
each instance can be configured. Especially in reporting and analysis, but not limited to these, the performance
30
is improved by increasing available RAM.
The number of network interfaces depends on several things:
- Network topology: Dual-hosted servers require at least two network interfaces. A server can
be connected for example to an access network and to a management network or to an access
network and to a core network.
- High availability: Network teaming (a dual connection providing fault tolerance) requires at
least two network interfaces.
- Clustering: It is recommended that at least three network connections are made available for
cluster control and heartbeat traffic and that at least one them is dedicated for this purpose.
The best location, which would be local or SAN disks, of the operating system and the data is affected by the
intended maintenance procedures:
- Using servers, especially blade servers, retrieving the operating system from SAN and storing
data to SAN and not having any local disks, makes the servers “dummy” electronics boards
with no identity. This enables fast and easy reassignments of servers to different tasks and can
be useful for example during version updates and when applying patches.
- All servers should have at least a mirrored (RAID-1) disk configuration. In some cases, for
example with DMZ servers, it might be more reasonable to use local disks.
- Cluster servers should always have local disks for the operating system and SAN disks for
data to ensure proper cluster control and data availability at all times.
The hyphen “-“ in the table indicates a neutral attitude. The decision is usually made based on existing
possibilities and on design aspects of the entirety.
See appendix B for sample SAP BCM Servers.
31
4.2 Operating systems

Supported operating Systems for servers are English versions of Windows Server 2003, Windows Server 2008,
Windows Server2008 R2, 32-bit or 64-bit with the latest service packs.. Supported editions are Standard and
Enterprise. SAP BCM is a 32-bit software. Microsoft SQL Server runs on 64-bit systems as well. Datacenter
and Itanium editions are not supported. Below are the most significant features of the editions and the
differences between them in relation to SAP BCM.
Windows 2008 32-bit
Windows 2008 32-bit
Windows 2008 64-bit
Windows 2008 64-bit

Enterprise edition
Enterprise edition
Enterprise edition
Standard edition
Standard edition
Standard edition
Windows 2003
Windows 2003
Feature
Max memory 4 GB 32 GB 4 GB 64 GB 32 GB 1 TB
Cluster service No Yes No Yes No Yes
Standard editions are recommended for SAP BCM application servers. Enterprise edition is recommended for
SAP BCM storage servers because of the larger amount of maximum memory and the clustering capability. If
clustering is not required for file servers, standard edition can be used. It is recommended to always apply the
latest services packs provided by Microsoft.
4.3 Software
Software refers to third party software required to run SAP BCM or supporting it in some way, such as SQL
Server. Essential software and/or operating system services for SAP BCM are:
- Windows Server 2003 or later Active Directory
- Microsoft Internet Information Server 6.0
- Microsoft SQL Server 2005 or SQL Server 2008
- Microsoft Certificate Services (optional)
- Windows 2003 DCHP Server or later (optional)
- A TFTP Server (optional)
- A syslog server (optional)
SAP BCM servers are usually added to a Windows domain. Some exceptions exist, for example a SAP BCM
CS Server installed in a DMZ zone does not typically belong to any domain. Windows Server Active Directory is
used for maintaining Windows user and computer accounts in that domain. Windows user accounts are created
for SAP BCM administrators, operators and services.
32
Microsoft Internet Information Server 6.0 is used for running SAP BCM web services, such as the CDT and
Administrator interfaces.
Microsoft SQL Server 2005 or SQL Server 2008 is the database system used by SAP BCM. See section 4.3.1,
Microsoft SQL Server, for more information about Microsoft SQL Server.
Microsoft Certificate Services (CA) can be used to create self-granted server certificates for encrypted SSL
connections. Parties (such as hosts and services) connecting to services using self-granted certificates must
recognize the issuing CA as a trusted root.
Windows 2003 or later DHCP Server can be used to provide gateways, IP desk phones and other equipment
residing in the server network with IP-addresses and additional information, such as boot files, configuration
files and configuration information.
A TFTP server (any available) can be configured in the DHCP information as a destination where additional
configuration information is available. Configuration information can also be stored from a device to a TFTP
server for example as a backup.
A syslog server can be used to log messages from devices such as IP Desk Phones and gateways. Most
devices provide alternative log levels to avoid storing uninteresting information. A syslog server with the ability
to filter syslog events and forward selected ones via e-mail and/or notifying of essential events via SNMP
(simple network management protocol) is recommended.
33
4.3.1 Microsoft SQL Server

Microsoft SQL Server 2005 and SQL Server 2008 R2 come in different editions of which Standard and
Enterprise editions are supported, mainly because of the high availability features. Both editions have support
for 64-bit systems but can also be run in 32-bit systems.
There are three licensing models for SQL Server of which Per Processor Licenses are recommended. One Per
Processor License is required for each processor running a SQL Server instance. This licensing mode does not
require any CALs (client access licenses). One Per Processor License allows for running a multi-core
processor. Below are the most important features of the editions and differences between them in relation to
SAP BCM.
Enterprise edition
Enterprise edition
SQL Server 2005
SQL Server 2005
SQL Server 2008
SQL Server 2008

Standard edition
Standard edition
Feature
Max number of CPUs 4 Unlimited 4 8
Operating Operating 64 GB 2 TB
Max RAM system system
maximum maximum
Database size Unlimited Unlimited - -
Yes(safety Yes (full)

Database mirroring Yes Yes
full only)
Yes (2 Yes
Failover clustering Yes Yes nodes) (op.sys
max)
One Per Processor License allows for more than one instances of SQL Server to be run on the same host.
Each instance can be configured with a maximum amount of memory and with one or more cores.
SQL Servers running the reporting databases should have the SQL Server options Analysis Services and
Reporting Services installed.
4.3.2 Microsoft Internet Information Server 6.0

Microsoft Internet Information Server (IIS) 6.0 is used by SAP BCM to provide user interfaces to CDT and to
administrative tools. IIS is included with Windows Server 2003 but not installed by default and is an option that
needs to be selected manually.
If e-mail notifications are needed, for example, from voice mails and SMS messages, SMTP (simple mail
transfer protocol) needs to be installed. SMTP is included with IIS, but not installed by default and is an option
that needs to be selected manually.
One IIS server can contain several web sites, one per each installed virtual unit, for example, VU_WEB_USER.
Each web site and thus virtual unit can and preferably should be assigned a unique IP address. Backup
instances of each web site should share that same unique IP address.
34
4.3.3 Certificates
SAP BCM uses SSL server certificates to authenticate SAP BCM servers and to encrypt traffic between servers
and clients. Servers refer to SAP BCM components listening to connection attempts. Clients refer to SAP BCM
components initiating connections. Both servers and clients can be SAP BCM service components.
Authentication succeeds when all of the following are true:
- The URL connected to matches the name the certificate is issued to.
- The certificate date is valid.
- The issuer of the certificate is trusted by the client.
Certificates can be obtained from any certification authority (CA) trusted by the client. Windows Server 2003
contains by default several trusted certification authority certificates. Trusted CAs can be added by adding their
certificates among the trusted certification authorities.
For internal usage, for example, for authentication and encryption inside the core or access network, the
certification authority services included with Windows Server 2003 can be used. They are not installed by
default and need to be selected manually. For self-granted certificates, the certificate of the issuer needs to be
distributed to the clients, usually manually.
For public usage or usage over the Internet from numerous clients, for example CMC, certificates issued by
public certificate authorities are required to avoid massive distribution of CA certificates to numerous clients.
Public certificate authorities are for example VeriSign and Thawte.
35
GATEWAYS
5 Gateways
Gateways connect PSTN networks to IP networks and enable calls to pass from one to the other. In in-house
cases gateways are installed in the customer LAN. In service provider cases, they are typically installed in the
service provider network but they can also be distributed over the customer LAN or over the service provider
network and customer LAN.
SAP BCM uses traditionally H.323 as the control protocol for gateways. SIP is also supported and it is slowly
becoming more esteemed than H.323. The SAP BCM control component in front of the gateways is either a
H.323 bridge or a SIP bridge.
Finding suitable locations for gateways is an important step in designing each SAP BCM landscape. Affecting
factors are:
- Cost of PSTN links and gateways

- Cost of sufficient bandwidth from gateways to other voice endpoints (LAN & WAN)
- Preferred telephone numbering, regional or nationwide
Because of the real-time requirement of voice streams, the networks ability to carry them is considered in
landscape design. To be able to optimize the networks ability to carry voice, it is essential to understand the
possible voice stream paths and to recognize the possible endpoints. Gateways are voice stream endpoints in
the LAN. The other voice stream endpoint is either an immediate endpoint such as:
- IP desk phone
- CDT
- IVR
- Voice Mail
- In some special cases, another gateway
Or, it can be an intermediate endpoint, such as the SAP BCM MRS (media routing server) component, which
forwards the voice stream to a next endpoint.
MRS may also be an immediate voice stream endpoint depending on its function. MRS is used to:
- Play prompts (immediate)

- Record voice streams (immediate)
- Relay voice streams (intermediate)
- NAT Bypass (intermediate)
- Encryption endpoint (immediate or intermediate)
5.1 Distributing gateways

Distributing the gateways over headquarters and branch offices may provide local telephone numbering and
may also significantly reduce the required WAN bandwidth between the sites and the service provider network.
Distributing gateways may at the same time increase the required gateway capacity as they come in multiples
of E1/T1/J1 ports.
For example a company has two offices and a one E1 line in the service center network. Less
demand for a maximum of 30 simultaneous than a 2 Mbit/s data link is required but smaller
calls. If nationwide telephone numbering is used, data links with sufficient capacity are often not
the company can manage with one gateway and available.
36
GATEWAYS
If regional telephone numbering is used at both

PSTN offices, two gateways and two E1 lines are required.
The narrower data links are sufficient for Control
E1
Protocols and UI traffic (CDT). If prompts are played
often 1 Mbit/s links should be used instead, or MRS at
Service each site should be available to provide prompts
Provider
2 Mbit/s 2 Mbit/s locally.
Site 1 Site 2 PSTN

LAN LAN
Client Enterprise Client
Network
Figure 11. Gateway located in service provider E1 Service E1

network Provider
512 kbit/s 512 kbit/s
.
Site 1 Site 2
LAN LAN
Client Client
Enterprise
Network
Figure 12. Gateways distributed to each customer

office.
Back-up capacity is often wanted, which also comes in multiples of E1/T1/J1 lines and gateways. Combining
the nationwide telephone numbering with gateways distributed to both offices provides this back-up capacity if
sufficient IP bandwidth is available for carrying voice between the offices.
The back-up capacity can also be arranged by locating both gateways in the service provider network and by
ordering the E1/T1/J1 lines to different telephone exchanges in the PSTN. This presumes that the PSTN
cabling routes are sufficiently separated all the way to the gateways in order to eliminate single points of failure.
This also usually presumes that nationwide numbering or the same regional numbering is used.
5.2 Connecting to a PBX

Gateways can also be used to interconnect SAP BCM systems with existing private branch exchanges (PBX)
or PBX networks to enable calls to pass from one to the other. This is preferred when the SAP BCM
implementation is divided into phases and a migration plan is used. Technical connections must be done,
telephone number ranges must be matched and routing rules configured on both sides.
For example the company A has a telephone number range of 250 1300 – 250 1799. The SAP BCM migration
is not yet completed and 300 subscriptions are created in SAP BCM while 200 still exist on the traditional PBX.
SAP BCM subscriptions are assigned the numbers 250 1300 – 250 1599 and the numbers 250 1600 – 250
1799 are still in the PBX.
To enable calls between all employees, a gateway is installed to connect the SAP BCM system to the PBX. The
E1/T1/J1 port of the gateway is used to connect to the PBX and as normally, the Ethernet port is used to
connect to the SAP BCM system.
The PBX is configured to route all, except the numbers 250 1600 – 250 1799, to the port where the gateway is
connected.
The gateway is configured to route the numbers 250 1600 – 250 1799 to the port where the PBX is connected.
37
GATEWAYS
PSTN
All but
250 1600 All but 250 1300
- -
250 1799 250 1300 250 1799
PBX -
250 1799
250 1600
-
250 1799
SAP BCM System
Figure 13. Connecting a gateway to a PBX.
Another way to do the interconnection is showed in figure 14, where the gateway is connected between the
PSTN and the PBX. This setup requires a gateway that has at least two E1/T1/J1 ports and the capability to
route configured number ranges as showed in figure 14. For example innovaphone IP3000 DD and
innovaphone IP6000 can be used in the setup below. Usually this setup is reasonable when only one E1/T1/J1
connection is needed to connect to the PSTN.
PSTN
All but 250 1300

-
250 1599
250 1300
-
250 1799 SAP BCM System
250 1600
-
All but 250 1799
250 1600
- PBX
250 1799
Figure 14. Connecting a gateway between the PSTN and a PBX.
5.3 Miscellaneous settings

Gateways are usually configured by default to retrieve the synchronization clock signal from the PSTN network.
Gateways are typically configured as slaves and the telephone exchange, to which the gateway is connected, is
configured as a master. Connecting to a PBX involves explicitly setting either the PBX or the gateway as a
master and the other as a slave. Master is also referred to as NT (network terminal) and slave as TE (terminal
equipment).
38
GATEWAYS
ISDN is sometimes referred to as DSS1 (digital signaling system 1). The protocol used on the PSTN side
should be ISDN S2. R2 is not supported.
Voice codecs supported by SAP BCM are G.711 and G.729.
ISDN protocols refers to N-ISDN including Q.931 and Q.921.
5.4 Cisco gateways

SAP BCM supports Cisco multiservice Modular Access routers configured to VoIP gateways using High Density
Voice Network Modules. These gateways differ essentially from the other supported gateways in the way they
are built and in that they simultaneously serve as routers. Other supported gateways include also modular
models but they are less complex.
Such a Cisco gateway is comprised by:
- A multiservice Modular Access Router

- One or more High Density Voice (HDV) Network Modules (NM)
- One or more Voice/WAN Interface Cards (VWIC)
- One or more Packet Voice DSP Modules (PDVM)
Cisco 2600, 2600XM, 2811, 2821, 2851, 2691 3600, 3700 series and 3800 series multiservice Modular Access
routers are supported. Up to 4 HDV Network Modules can be installed on a single router depending on the
router model. See appendix A, ICL, for more information.
Each HDV Network module has one VWIC slot. The VWIC provides the interface to the PSTN, E1, T1 or J1.
VWICs are available with one or two T1/E1/J1 ports.
Up to 5 PDVMs can be installed on each HDV Network Module. The amount of required PDVMs depends on
the amount of simultaneous calls and codec being used.
For more information, see www.cisco.com.
39
DATA CENTER LAN
6 Data center LAN

Data center LAN refers to the LAN, where the SAP BCM Servers reside and where the SAP BCM services are
produced by service provider or by an in house operator. The LAN consists basically of Ethernet Switches
connecting servers and network devices together over LAN cables, such as CAT5/6, and IP routers connecting
the LAN to the outside world over WAN links. Recommended networks are 100 Base-T and 1000 Base-T
switched networks.
SAP BCM service availability is extremely important to the customers and to the users. It appears far more
critical than traditional IT systems like e-mail and World Wide Web. The most important features of the data
center LAN are:
- Performance
- Availability
The data center LAN is crucial to the SAP BCM service availability as the SAP BCM service availability cannot
exceed the data center LAN availability. The performance of the data center LAN is vital to the SAP BCM
service availability because only minor and occasional voice distortions are sustained.
6.1 Performance
Different traffic shapes apply to different network boundaries. Between a management network and a core
network, there is management traffic, such as SNMP traffic and traffic related to configuration tasks. Between a
core network and an access network there are mainly database queries and SAP BCM Control Traffic. Unlike
voice streams, these do not have real time demands.
Voice streams are typically carried from voice endpoints in the access networks over service and access links
to voice endpoints in the customer LAN. Voice endpoints are any immediate or intermediate devices or services
transmitting or receiving voice, such as CDTs, IP desk phones, VoIP gateways, routers, CSs and MRSs.
It is recommended to keep the network layout as straight-forward as possible by minimizing the network
distance between endpoints. Doing this provides more robustness against voice distortions due to increasing
delay caused by increasing overall utilization. This also minimizes the number of devices a particular service
depends on and minimizes the points of failure. Increased overall utilization can be caused for example by new
end users and customers, but also by poor configuration allowing or generating unnecessary traffic.
The above can be applied the other way around too. In a data center access network serving several
customers, minimizing the network distance between service endpoints may decrease the number of services
that depend on any particular device and can therefore be considered as a kind of segmentation into smaller
failure domains.
6.1.1 Minimizing network distances

In a network based on hubs directing all traffic to every port and thus all over the LAN, the maximum nominal
capacity equals the maximum peak performance, for example in a 100 Base-T network the aggregate
momentary throughput cannot exceed 100 Mbit/s.
However switched networks allow for traffic isolation between parties and traffic is not unnecessarily
propagated all over the network. Therefore in a switched network with the nominal capacity of 100 Mbit/s, two
or more simultaneous fully utilized 100 Mbit/s connections may exist.
Switched networks are strongly recommended for SAP BCM data center networks as well as customer LANs.
Small SOHO (small office home office) sites with only a few hosts and modestly utilized networks are an
exception.
40
DATA CENTER LAN
The maximum aggregate performance of a switched network depends on the network topology and on the
performance of the network devices themselves. The absolute maximum capacity of any link and switch port is
its nominal speed. Two switches connected together over a 100 Mbit/s link cannot carry more than 100 Mbit/s
data to each other although the total demand from other ports would exceed this as depicted below.
Switch 1 Switch 2
A B C D E F G H A B C D E F G H
40 Mbit/s
40 Mbit/s
40 Mbit/s
40 Mbit/s
40 Mbit/s
40 Mbit/s
100 Mbit/s
b it/s
0M N
d 12 TIO
n S
ma GE
De CON
Figure 15. Network congestion/overload on interconnecting link between switches.
Devices contributing to one and the same service should be located close by in the network to minimize the
network distances and thus to optimize the network performance as figure 16 shows..
Switch 1 Switch 2
A B C D E F G H A B C D E F G H
40 Mbit/s
40 Mbit/s
40 Mbit/s
40 Mbit/s
40 Mbit/s
40 Mbit/s
100 Mbit/s
/s
bit N
8 0 M TIO
nd ES
ma NG
De CO
NO
Figure 16. Network distance between related services is minimized to optimize performance. The host or
segment connected to switch 1, port F, has been moved to switch 2, port H.
One solution is to use 1000 Base-T links between switches, but it is still recommended to minimize the network
distance between related devices and services. Every additional hop introduces a potential delay and a
potential point of failure.
Based on this, it seems that in a switched network the aggregate capacity is a multiplier n times the nominal
network capacity, where the multiplier n depends on the network topology and the capability and speed of the
switches to queue and forward traffic. However, queuing traffic introduces delivery delays eventually distorting
the voice quality.
Service segmentation provides some certainty of service availability and service infrastructure should be
divided into self-sufficient parts independent on incidents in other parts. Therefore it is recommended to have
another access network in advance before the previous is utilized to its reasonable extents.
41
DATA CENTER LAN
6.1.2 LAN capacity

For data center LANs 1000 Base-T (1 Gbit/s) is recommended for core networks. A core network can serve
more than one access network, either physical or logical. The capacity demands of the access networks relates
to the aggregated capacity of the service links or access links. (See chapter 1, Introduction for a description of
core networks, access networks, service links and access links).
Assuming that, in a pure SAP BCM environment:
an average Ethernet network utilization of 40% is a reasonable maximum limit

80% of the traffic would be destined over access links and 20% to and from the core network
It would occur that a 100 Base-T access network would be capable of serving approximately
100 Mbit/s x 0,4 x 0,8 = 32 Mbit/s access and service links.
In switched, well-structured network this might apply to one switch in the network. The network utilization varies
over time as the number of simultaneous calls and directory queries varies. Unlike traditional IT systems like e-
mail, where it is possible to wait some seconds in a congestion situation, a SAP BCM system must be designed
to carry-real time voice at any moment as dimensioned. Average loads do not count and dimensioning must
apply to peak loads.
6.1.3 VLAN
Virtual LANs (VLANs) provide broadcast filtering, security, address summarization and traffic flow management.
VLANs can be used to provide the segmentation services traditionally provided by routers in LAN
configurations, for example to split a large access network into segments and by doing this, increasing
manageability and security. By definition, switches may not bridge IP traffic between VLANs because it would
violate the integrity of the VLAN broadcast domain.
VLANs have the same attributes as physical LANs but they allow for end stations to be grouped together even
if they are not on the same LAN segment. In a legacy network, end stations are assigned to networks based on
geography. Using VLANs, networks can be logically grouped without physical LAN topology restrictions.
Two kinds of VLANs exist. One is based on the protocol IEEE 802.1Q, where Ethernet frames are tagged with
VLAN information allowing for VLAN multiplexing over trunk lines. These VLANs are suitable for reaching
logical core, management and access networks over multiple sites. Each VLAN appears as one and the same
network regardless of its physical location.
The other kind of VLANs are port-based VLANs. With port-based VLANs two or more switch ports are assigned
a VLAN identifier which groups the ports together to a port-based VLAN. Traffic cannot flow between ports
belonging to different VLANs without passing through a VLAN router. Multi-VLAN ports may be configured to
provide services, for example management or database, to multiple VLANs.
6.2 Availability
The data center LAN availability focuses on keeping the network serve its purpose by avoiding unnecessary or
unwarranted traffic and by preparing for failures. Together with diligent network management, operation and
monitoring, access control and fault tolerance are central elements of high availability. Prioritizing may also be
considered a protection mechanism with similarities to access control.
6.2.1 Access control

Access control is an enforcement method allowing only relevant traffic. Unwarranted traffic is rejected at outer
network boundaries by firewalls but there might be unnecessary traffic inside generated by servers and network
devices. Switches with ACL (access list) capabilities can be used to constrain the inside distribution of
unnecessary traffic in the network.
42
DATA CENTER LAN
See chapter 11, Security, for access control at outer network boundaries as protection against external threats.
In this context, access control is considered as an enabler for network robustness which is done with access
lists on switches. Access control can be based on, for example, any of the following:
- Source IP address or address range

- Destination IP address or address range
- Source port number or port number range
- Destination port number or port number range
- Protocol
- Connection direction for TCP protocols
The data center LAN may be segmented into different networks to obtain more granular control over it and the
network traffic in it. Such segments may be, for example core, access and management networks where
boundary controls are implemented and/or virtual LANs (VLAN) assigned to a customer or a group of
customers.
Access controls inside a segment, or even inside a data center LAN, can be implemented with switches but on
the outside boundary towards a customer or another organization, more sophisticated firewalls are
recommended.
Access control contributes to availability and high quality of service. It may constrain the distribution of
unnecessary or even malicious traffic caused by:
- Accidental improper configuration

- Improper functionality caused by for example software bugs
- DoS (denial of service) attacks, malicious and other
- Faulty devices
Access control should be carefully planned and clear benefits and objectives should be recognized, such as
allowing specified traffic shapes or protecting organization limits. Good options are allowing only voice streams
and control protocols to voice endpoints or allowing only traffic to and from a specific organization. Access
control should be kept as simple as possible and well documented.
6.2.2 Prioritizing
Prioritizing involves categorizing traffic into different traffic classes and to assign priorities to those classes.
Categorization of traffic can mainly be based on the same factors as access control and it can also be based on
a type of service identifier (ToS or ToS bit). Traffic with higher priority is passed through network devices, such
as switches and routers, before traffic with lower priority. ToS bits are usually set by endpoint but it is also
possible in some cases to set ToS bits on network devices on the transmission path.
In opposite to access control, which strictly allows or rejects traffic, prioritizing does not initially reject traffic but
instead allows higher prioritized traffic pass before lower prioritized traffic. With increased utilization and
congestion, prioritizing will eventually cause low priority traffic to be dropped and thus allow higher priority traffic
to be carried over the network.
Prioritizing is a mechanism providing control over bandwidth usage. It does not provide means to counteract
low bandwidth. Prioritizing may provide higher availability in the same cases as access control and it could also
be seen as a performance factor.
43
DATA CENTER LAN
6.2.3 Fault tolerance

Fault tolerance protects the service production against physical device and network failures by routing the traffic
over an alternative path in case of failure of a link or network device. The fault tolerance degree of the network
may vary. It may include the whole data center LAN, only the most critical parts of it or something in between.
The fault tolerance of the data center LAN is a part of the overall SAP BCM service fault tolerance and it relates
to fault tolerance implemented by network topology designs, network hardware and network protocols.
6.2.3.1 Deciding on the fault tolerance degree

The fault tolerance degree is a business decision based on risk analyses and liabilities of service availability.
Moreover, it is also associated with the reputation the of service provider wanting to provide outstanding
services.
The following questions can be used when deciding on the degree of the fault tolerance:
- Are total (all services/customers) service downtimes allowable?
If not, then the following can be used:
-
- Independent service pools are required to constrain the service breaks.
- Partially independent service pools sharing common clustered service pools are required
- The service pools must contain comprehensive failover mechanisms.
- Is a couple of minutes of downtime allowed during a failover?
If not, then the failover probability must be minimized by adding robustness to each component
Each step costs additionally and each incidence has its price, probability and estimated recurrence. However,
the reasoning described below is difficult and laborious to use when drilling into a variety of details and
equipment. Another is that the cost of an incidence is easily underestimated.
An incidence may involve:
- Interrupting ongoing tasks and thus delaying new business

- Working overtime
- Requiring third party services outside business hours
- Penalties to customers
- Reputation damage
To keep the reasoning simple, think if a particular incidence is allowed even once. If not, then counteract it.
Otherwise follow-up the recurrence and reconsider the situation if needed.
In general, it is recommended that all simple fault tolerance measures are implemented, such as:
- Dual power supplies

- Dual cooling fans
The final outcome of the reasoning should be a fault tolerance plan or a risk chart showing the critical spots and
outlining the steps of precaution.
44
DATA CENTER LAN
6.2.3.2 Teaming
Teaming is a technique using two or more network cards to connect a server to the network. The team or the
group of network cards appears as one logical network card in the operating system. The remaining network
cards assume the traffic of the failed card, if one network card in the group fails. The virtual network card has
one MAC address and one or more IP addresses just as real network cards do. Teamed network cards also
share the network load increasing the available network bandwidth and providing load balancing.
Teaming is recommended to be used at least with clustered switches capable of continuing the server
connectivity in case a part of the switch cluster goes down. Teaming is also supported by some gateways.
6.3 Multiple Sites

SAP BCM services may be available as real-time failover from more than one site. This is typically the case
when the business grows to and it becomes too risky to rely on only one site, or when there are legislative
demands of guaranteeing service availability from more than one site. Arranging with two sites provides for
disaster tolerance and disaster recovery.
Basically, providing the SAP BCM services from two or more alternative sites requires:
- Alternative premises with far enough distance between them. The distance depends on the
disaster prepared for. For protection against fire emergencies, collapsed buildings, power
outages and data link outages, a suitable distance could be about 20 km or more. Power and
data network structures should be discussed with respective providers before deciding
alternative locations.
Partially or fully duplicated production equipment, such as servers and gateways. It is possible
to run only selected services with standby failover on remote sites.
- Connections to the PSTN from each site.
- Service links to each site.
- Duplicated connections between the sites.
- Common data storage, preferably a real-time mirrored SAN between the sites.
Obviously providing real time failover services from alternative sites is costly. However, the actual case might
be that only a fragment of the customers demand this high availability and disaster tolerance. Establishing
alternative production sites provides also more production capacity and preparing for alternative sites might be
a good growth strategy from the very beginning. This reduces the risk of having too much of the service
provider business on one site and reduces the initial costs by keeping premises and facilities a little bit smaller
at the beginning.
The majority of multi-site concerns are exactly the same as with single sites because multi-sites are run with,
for example identical servers and data links. The points to focus on are:
- Common broadcast domain in all failover sites.
- Connecting sites together
- Data connectivity and routing
- Distributed real-time mirrored SAN
- Incoming call routing
- Arranging for cluster and HAC nodes in each site

45
DATA CENTER LAN
6.3.1 Common broadcast domain

The Ethernet broadcast domain is the area or group of devices receiving Ethernet broadcast messages. The
Ethernet addressing is based on MAC addresses, also known as hardware addresses. The address is a
hexadecimal number unique to each network interface card.
Since MAC addresses are not divided into network and host portions, a host cannot determine from the MAC
address of another host if that is on the same network or not.
To be able to address hosts on other networks, IP addresses are used. IP addresses contain a host portion and
a network portion. When addressing another host, it is in the same network if the senders and receivers
network portion of the IP address is the same. Otherwise, it is on a different network and will be addressed to
via a router.
Hosts and services are configured with IP addresses. For example, an IP desk phone is configured to find its
registrar at the IP address 10.10.0.5.
The IP desk phone uses ARP (address resolution protocol) to determine the MAC address of the registrar by
sending an ARP request containing the IP address 10.10.0.5 and the MAC address of the sender. ARP
requests are sent with Ethernet broadcast addresses and received by every other host in that network. The
host configured with the IP address 10.10.0.5 replies with an ARP reply containing its MAC address. This way,
MAC addresses are changed between hosts and the rest of the communication continues using these MAC
addresses. MAC addresses are stored by the hosts in ARP tables until they expire and requested for again.
The SAP BCM high availability concept includes virtual IP addresses assigned to SAP BCM services. The
virtual IP address hides the actual server or site from the user.
The SAP BCM high availability concept is based on virtual units having more than one instance sharing the
same IP address and of which only one instance is active at a time. However, each instance has its own
network interfaces and its own MAC addresses that must be resolvable by the router connecting to the
customer.
Therefore, sites must be in the same broadcast domain and there must not be a routed connection between
them.
6.3.2 Connecting sites together

IP and Fibre Channel links are needed to connect two sites together. Fibre Channel is a gigabit-speed network
technology primarily used for storage networking. Here it is used to connect the SANs of the two sites together.
IP is used for all the remaining traffic.
Single mode (SM) optical fibers are recommended as the physical link media between sites, because of their
excellent ability to carry information over long distances without any repetition or other electronic intermediate
devices constituting points of failure. One fiber link consists of two fiber strains or a fiber pair. For fault
tolerance, two separately routed fiber pairs are used.
CWDM (coarse wavelength division multiplexing) is used to deploy different services such as IP and FC over a
single fiber pair. CWDM is an optical technology for transmitting several channels, each in a separate
wavelength or color, over the same fiber strand. Unlike DWDM (dense wavelength division multiplexing) which
can transmit 32 or more channels on the same fiber, CWDM uses a more loose spacing between channels and
is less expensive than DWDM. The International Telecommunication Union (ITU) has standardized a 20 nm
channel spacing grid for use with CWDM with the wavelengths between 1310 nm and 1610 nm.
46
DATA CENTER LAN
Site 1 Site 2
Gray Gray
Violet Violet
Blue Blue
Green Green
Yellow Yellow
Orange SM Fiber pair Orange
Red Red
Brown
(receiving & Brown
transmitting)
Figure 17. Multiplexing several channels over a optical fiber pair (CWDM).
Figure 17 shows two eight channel CWDM multiplexers connected over a SM fiber pair. Each channel can be
used to interconnect a 1000 Base-T Ethernet network, VLAN or Fibre Channel network between the sites.
Figure 18 shows an Ethernet network or a VLAN connection between two sites. The four edge switches are
connected together in a ring. The spanning tree protocol is used to determine active path between the sites.
Site 1 Site 2
Spanning Tree
Figure 18. Two fiber links routed physically apart are used to interconnect the sites.
47
DATA CENTER LAN
6.3.3 Data connectivity and routing

For customers to be able to benefit from the services from a failover site, data connectivity must be arranged to
the failover site as well. The same dimensioning is valid as for the primary site, but there must be a way to
automatically reroute the traffic.
With SAP BCM, the service is

reached at the failover site (site 2)
Service
with the same IP address as it was Provider
at the primary site (site 1). Network
Site 1 Site 2
A virtual router cluster running Common
HSRP (hot standby router protocol), Broadcast
in close association with a rapid- Domain
converging routing protocol such as Ethernet Ethernet
OSPF (open shortest path first), is
used to do the rerouting. HSRP
Group
Two or more routers running HSRP Virtually one router
in, for example, the service provider
network appears as one virtual Serial Serial
router. HSRP is used between the
routers in the HSRP group to WAN OSPF
decide the active router.
Another similar pair is used in the Serial Serial

customer LAN.
HSRP
Group
The routers of the HSRP group in Virtually one router
the service provider network are
connected over data links to routers
Ethernet Ethernet
in the HSRP group in the customer
LAN.
Each group has only one active Customer

router at a time. Network
The active router becomes inactive,

if the Ethernet port of that router
goes down or if the serial port
connected to the WAN goes down.
In this case, another router in that Figure 17. HSRP and a rapid converging routing protocol is used to
HSRP group becomes active and connect failover sites to the customer.
continues routing the traffic.
HSRP does not inform the other HSRP group of an event where the active router changes. If the Ethernet port
of an active router goes down and the active router in that group is changed, traffic from the other group is still
destined over the WAN to the previously active router. Therefore, a routing protocol is needed to cover the
return path.
48
DATA CENTER LAN
6.3.4 Distributed real-time mirrored SAN

For data to be available at the failover site, a distributed real-time mirrored SAN (storage area network) system
is recommended. SAN systems have the ability to hide physical disk structures from hosts and maintain
mirrored and distributed copies over several disks even in separate locations.
Such disks appear to the hosts as single logical disks and are mounted, for example, by SQL clusters at
failover.
6.3.5 Incoming call routing

In multi-site landscapes, gateways are usually also distributed over the sites. The telephone network considers
the E1/T1/J1 line alive practically as long as the gateway is powered on and the line is connected and intact
regardless of the data connectivity between the service provider network and the customer network or between
the service provider sites.
For occasions when gateways on either site are not able to respond reasonably to incoming calls, for example,
no answer is sent from the gateway to the PSTN, an alternative destination is required the incoming calls. The
primary alternative destination would be respective gateways on the other site, but overflows could be defined
to any PSTN destination.
6.3.6 Arranging cluster and HAC nodes in each site

Running multi-site services requires configuring SAP BCM virtual unit instances to each site for failover
purposes. The configuration of a SAP BCM virtual unit is aware of only the IP addresses, not the locations and
thus, multi-site setups are equal to single-site setups in regard to the configuration of the SAP BCM software.
Running multi-site services requires also for databases and file sharing services to be available at both sites.
This is achieved using Microsoft cluster services, SQL clusters and distributed real-time mirrored SANs.
49
CUSTOMER LAN
7 Customer LAN
The customer LAN refers to the LAN where the SAP BCM service is used. Different site topologies are already
covered in the section 1.6, Introduction to customer LAN. 100 Base-T and/or 1000 Base T switched networks
are recommended. There are two concerns related to the customer LAN:
- Availability
- Ability to carry quality voice
7.1 Availability
For the customer LAN availability, valid techniques are explained in:
- Minimizing network distances is a network hygiene matter and is explained in

the section 6.1.1, Minimizing network distances
- Ring topologies can be used to interconnect departments, floors and sites as explained in
the section 6.3.2, Connecting sites together
- For sites in different subnets, HSRP in combination with a rapid-converging routing protocol
can be used as explained in
the section 6.3.3, Data connectivity and routing
7.2 Ability to carry voice

The ability of a 100 Base-T or 1000 Base-T switched LAN to carry quality voice depends on the path the voice
has to traverse on the LAN and the utilization and health of the LAN along that path. Utilization can be
measured using network analyzers and reviewing switch statistics.
If there is heavy utilization and especially if there are heavy load peaks, it is advisable to find out the cause of
the heavy utilization and/or the heavy peaks to verify that they are permissible and rational. When it is
confirmed and possibly counter-measured that there is no dispensable traffic, a utilization baseline has been
found. This baseline is used to recognize the available capacity for voice.
It should be observed that average utilization is not the whole truth about the ability to carry voice. A LAN with
very modest average utilization but frequent high load peaks may show totally unworthy of carrying voice. The
high load peaks may cause significant distortion to voice. A LAN carrying most of the calls perfectly well but at
the same time disrupting the voice a few times a day is not acceptable.
Prioritizing traffic is an efficient method to attach heavy load peaks in a LAN where the average utilization is
moderate.
7.2.1 Prioritizing traffic

Voice can be prioritized over other traffic in many ways. Common to all of these is that:
- There are some means to identify and categorize traffic
- Prioritization is done on queuing devices, such as switches
Voice traffic can be identified by the ToS bit set by SAP BCM or by constructing access lists on routers or
switches filtering traffic into categories based on, for example, sender and/or receiver IP address or protocol.
For configuration details see the documentation of the network device.
50
CUSTOMER LAN
Categorization
High Priority
Port 1 High priority
input buffer queues are
Eth emtied first
Port x
Medium Priority output buffer
Port 2
Eth
input buffer
Low Priority
Port n
input buffer
Figure 18. Frame queuing.
Figure 18 shows the principal of queuing and prioritizing traffic. A received Ethernet frame is buffered in the
input buffer. The frame is analyzed to determine the category of it and moved to the buffer with respective
priority. Frames in higher priority buffers are transmitted before frames (depending on the prioritization
algorithm) in lower priority buffers. Frames in each buffer have no mutual priority, they are sent on a first-in first-
out basis.
7.2.2 Verifying the LAN health

Switch statistics can be easily, and often very efficiently, used to verify the LAN health. Switch statistics usually
show:
- Information about the utilization:

The number of bits and packets received and sent per each port.
- Buffer overflows:
May indicate too heavy utilization, bad network topology or malfunctioning hardware.
- Suspected speed and/or duplex mismatches:
Indicates configuration problems. Auto settings might not work properly or manual settings do
not match.
- The number of collisions and late collisions:
May indicate too heavy utilization, malfunctioning hardware or bad network topology.
For details, see the documentation of the switch.
51
STORAGE SYSTEMS
8 Storage systems
Storage systems refer to the disks, disk arrays and SAN systems used for storing data. SAN systems use disk
arrays internally. Disk arrays provide better availability and sometimes also faster performance than single
disks. Faster performance is achieved especially in reading operations by reading several disks in parallel. SAN
systems are mostly based on high speed optical fiber connections providing better throughput than traditional
connections.
8.1 RAID arrays

RAID stands for redundant array of inexpensive disks and is a technology that employs simultaneous use of
two or more hard disk drives that appear as one logical drive in the operating system. There are various RAID
designs that all involve increased data availability or faster performance. Key RAID concepts are:
- Mirroring
Mirroring involves copying data to more than one disk.
- Striping
Striping involves splitting of data across more than one disk.
- Error correction.
Error correction involves storing redundant data such as parity to enable problem detection
and possibly problem fixing.
The most interesting RAID designs or levels are:
- RAID 1
All data is written to two identical disks, which allows for loss of one disk without data-loss.
- RAID 5
Striped set with distributed parity allowing for loss of one disk without data-loss.
- RAID 1+0 (or RAID 10).
Two or more mirrored sets are striped to provide a bigger disk allowing for loss of several disks
as long as no mirror set loses its both disks.
RAID 5
Logical
RAID 1 disks
A,B&C
Logical disk A1 A2 A3 Ap
B1 B2 Bp B3
C1 Cp C2 C3
Disk 1 Disk 2
Disk 1 Disk 2 Disk 3 Disk 4
Figure 19. RAID 1 Figure 20. RAID 5 with 3 logical disks.
RAID 1 arrays are recommended to be used in SAP BCM application servers with local disks and for the
operating system in SQL clusters. RAID 5 arrays or RAID 1+0 arrays are recommended to be used as
database storage.
52
STORAGE SYSTEMS
8.2 SAN systems

Storage area network (SAN) is an architecture for attaching remote computer storage devices such as disk
arrays and tape libraries to servers in a way that they appear as local disks to the operating system. SAN usage
usually simplifies storage administration and adds flexibility since storage devices do not have to be physically
moved to move storage from one server to another. SAN also allows for booting from the storage devices.
It is recommended that SAP BCM application servers boot from SAN but that cluster servers, such as Microsoft
SQL clusters, have local disks for the operating system and that the databases are on the SAN.
SANs usually utilize a Fibre Channel fabric topology made up of Fibre Channel switches, where devices are
connected to each other through one or more Fibre Channel switches. Host bus adapters (HBA) are used
connect servers to Fiber Channel switches. Each server and storage is connected to two switches for fault
tolerance.
SAN
attached
servers
Fiber Channel
Switches
Storage 1 Storage 2
Figure 21. Fibre Channel switched fabric topology
Figure 21 shows storages 1 and 2 that reside at different sites. The figure contains cascaded switches for
illustration purposes. The shown topology could be run with two Fibre Channel switches.
Using manufacturer-specific SAN options, logical disks can be mirrored to different storages making data
available in real-time at different locations.
Snapshots can be used to preserve a copy of the data at the given moment. Benefits of snapshots are, for
example, separated partitions that can be analyzed without influencing the production environment and
establishing truly identical test environments.
53
TELEPHONY AND DATA CONNECTIONS
9 Telephony and data connections

Data and telephony connections are used to connect the service center to the outside world. Data connections
are connected to the customers and telephony connections are connected to the PSTN. Both are covered
earlier in this document:
- Telephony connections are covered as follows:

1.4 Introduction to gateways
1.8 Introduction to telephony and data connections
5 Gateways
- Overall topology and service and access links are covered as follows:
1.1 Introduction to site landscapes and connectivity
1.6 Introduction to customer LAN
6.6.3 Data connectivity and routing
9.1 Telephony connections

Public network and PBX interfaces, ITU-T G.703 RJ48 (120 ohm), are provided by the gateways. These
interfaces are connected to E1/T1/J1 lines or spans provided by an operator. These lines are Time Division
Multiplexed (TDM), for example an E1 line is divided into 32 channels of which channels 1 – 15 and 17 – 31 are
used for voice and 0 and 16 are used for synchronization and signaling. The signaling used is S ISDN.
Every 3.91 microseconds 8 bits from one channel is sent down the line followed by 8 bits from the next channel
during the next 3.91 microseconds, and so on, in a round-robin fashion throughout all the channels and thus, 32
channels are used once every 125 microseconds.
Service providers may consider preparing for coming demands by obtaining, for example, E3 or bigger trunks to
their sites in advance and having the telco splitting them into E1 lines at the site. One E3 trunk contains 16 E1
lines. The suggested arrangement helps maintaining the technical sanity and might speed up new deployments
as only configuration remains to be done when taking more lines in use.
Lines are taken in use by subscribing them. It is recommended that subscriptions are made by the customers
and that they are invoiced for the telephone traffic by the telco directly.
Subscriptions include a telephone number range. In most cases only numbers from this number range can be
shown as A numbers or calling party numbers.
1 1 1 1 1 1
2 2 2 2 2 2
3 3 3 3 3 3
15 15 15 0 1 2 3 15 16 17 31 0 1 2 3 15 16 17 31 15 15 15
17 17 17 17 17 17
31 31 31 31 31 31
Figure 22. E1 Time Division Multiplexing. Each timeslot is 3,91 microseconds.
9.2 Data connections

Data connections refer to service and access links. Service links are high bandwidth connections from a telco’s
network to the site(s) of a service provider. Service links provide similar preparedness on the data network side
54
as using E3 trunks does on the telephone network side. Similarly, service links provide better technical sanity,
cost efficiency and expedited deployment times because the access links only need to be physically installed.
Dimensioning of service links is straight-forward as the required bandwidth is the sum of the bandwidth of the
access links. Dimensioning of access links relies on:
- Maximum number of simultaneous calls

- The codec G.711 or G.729
- The packet periods, 10, 20, 30, 40 ms, and so on.
- Estimated usage profile
The maximum number of simultaneous calls equals the number of (assuming all gateways are at the service
provider):
- E1 lines x 30 or
- T1 or J1 lines x 23
The codec G.711 creates a 64 kbit/s stream for a signal sampled at 8 kHz and G.729 creates an 8 kbit/s stream
correspondingly. This stream is the payload to be carried over the IP network. The stream is sliced into packets
of, for example, 20 ms of the stream. To be able deliver these packets, they are wrapped into RTP, UDP and IP
headers and finally, also in transport medium dependent headers. The choice of packet length is a trade-off
between latency and packet overhead.
20 ms of a G.711 stream is 64000 kbit/s x 0.02 s = 1280 bits -> 1280 bits / 8 = 160 octets.
20 ms of a G.729 stream is 8000 kbit/s x 0.02 s = 160 bits -> 160 bits / 8 = 20 octets.
It should be noticed that some gateways and/or IP desk phones accept only multiplies of 20 ms and therefore,
20 ms is a good default value.
As figure 23 shows, carrying RTP voice over Ethernet involves 78 octets overhead, Ethernet 38 octets and
IP/UDP/RTP 40 octets. The 38 octets are transmission-media dependent and apply to Ethernet only. HDLC
(High-Level Data link Control) and PPP (point-to-point protocol) are typically used, for example, on 2 Mbit/s
access links based on the SDH network. HDLCs overhead is 6 to 7 octets and PPPs overhead is 7 to 9 octets.
Ethernet Preample (8) Ethernet Inter-Frame Gap (12)
Ethernet Header (14) Ethernet CRC (4)
20 ms G.711 Payload (160)
IP, UDP & RTP Header (40)
Figure 23. Ethernet frame carrying G.711 over IP
The IP/UDP/RTP header can generally be thought of as a fixed overhead of 40 octets per packet, though on
point-to-point links RTP header compression can reduce this to 2 to 4 octets (RFC 2508).
Sending 20 ms voice in each Ethernet frame means that 50 frames are send each second. This gives total
bandwidth demand of:
- 50 times per second x (78 octets + 160 octets) x 8 = 95.2 kbit/s for G.711 over Ethernet
- 50 times per second x (78 octets + 20 octets) x 8 = 39.2 kbit/s for G.729 over Ethernet
- 50 times per second x (7 octets + 160 octets) x 8 = 66.8 kbit/s for G.711 over HDLC
55
- 50 times per second x (7 octets + 20 octets) x 8 = 10.8 kbit/s for G.729 over HDLC
- 50 times per second x (9 octets + 160 octets) x 8 = 67.6 kbit/s for G.711 over PPP
- 50 times per second x (9 octets + 20 octets) x 8 = 11.6 kbit/s for G.729 over PPP
Certain codecs support silence suppression. Voice Activity Detection (VAD) suppresses the transmission of
data during silence periods. As only one person normally speaks at a time, this can reduce the demand for
bandwidth by as much as 50 percent. The receiving codec will normally generate comfort noise during the
silence periods.
The bandwidth requirement is full duplex.
As a conclusion, based on earlier experiences a good rule of thumb is that G.711 requires 80 kbit/s and G.729
requires 40 kbit/s per simultaneous call on a HDL or PPP link. This includes the voice stream, signaling
information and CDT user interface. This rule may not be applicable in inbound and outbound call center cases,
where calls are interleaved very little or not at all.
Capacity demands for other channels, such as e-mail, are estimated based on information received from the
customer, for example, average sizes and e-mail frequencies. This capacity is added on top of the capacity
calculated for telephony.
56
USER TERMINALS
10 User terminals
The SAP BCM user terminals are CDT (SAP BCM soft phone), IP desk phones and mobile terminals. CDT
provides the broadest scale of functionality and is the primary user interface. IP desk phones are usually used
in negotiation rooms and other places where PCs are not available. SAP BCM CMC is a mobile client offering
some CDT functionality to mobile users. It runs on Nokia and Sony Ericsson Symbian phones.
10.1 CDT
CDT is a browser based telephone user interface including sophisticated functionality for enterprise telehony,
switchboard and call center users. It runs on Windows XP, Windows Vista and Windows 7 and IE 7, 8 and 9.
For required IE settings, refer to the user documentation of SAP BCM.
USB handsets and headsets are used with CDT. Headsets are also available as wireless. Handsets may
include keypads for dialing, such as Cyberphone W and VX-200. Headsets may include volume control, mute,
on-hook and off-hook functions. Headsets are either monaural or binaural, they come with one earpiece or with
two earpieces.
USB devices are powered either via the USB bus or they have external power supplies. In cases where many
USB devices are used and/or high power USB devices are used, consider using external USB HUBs with
external power supplies. The current supplied by the USB bus is limited to maximum of 500 mA.
For information about supported handsets and headsets, see appendix A SAP BCM infrastructure
compatibility list.
10.2 IP Desk Phones

SAP BCM IP desk phones are stand-alone phone devices connected to a SAP BCM system over the Ethernet
LAN. These phones run SIP and are configured to register to the SAP BCM SIP Bridge.
The IP desk phone settings may be done manually using the keypad. The phones usually contain a web server
for administration and additional configurations can be done using a browser once mandatory IP settings are
effective. Theses settings are:
- IP address
- Subnet mask
- Default router (in some cases)
Other important settings for IP desk phones are:
- SIP registrar and proxy IP addresses

- Subscription number
- NTP (network time server) IP address
IP desk phones include usually configurable speed dial functions and downloadable telephone number
directories.
IP desk phones can also be configured automatically using DHCP (Dynamic Host Configuration Protocol) and
TFP (Trivial File Transfer Protocol).
DHCP servers are servers that are assigned a pool of IP addresses that they lease to hosts upon their DHCP
requests. The DHCP reply typically contains at least the following information:
- IP address
57
USER TERMINALS
- Subnet mask
- Default router
- DNS (Domain Name System) IP address
The DHCP may be configured to provide, for example, the following additional information as well:
- NTP server IP address

- TFTP server IP address
Most IP desk phones are capable of retrieving and storing detailed configuration information from and to TFTP
servers. If configured to do so, an IP desk phone does the following when it boots:
- Sends DHCP request (layer 2 broadcast)

- Receives a DHCP reply
- Activates the received mandatory IP settings
- Requests for its configuration file (recognized by the MAC address) from the TFTP server
- Configures itself according to the received settings
The behavior is manufacturer dependent in case the DHCP and/or TFTP requests fail. In some cases it is to
use to the previously active settings.
TFTP servers are also useful for making configuration backups even if the initial configuration is done in some
other way.
IP desk phones can be, in most cases, powered by external power supplies or by PoE (Power over Ethernet).
PoE requires the connected switch to support it or to arrange a separate PoE adapter between the switch and
the IP desk phone. PoE utilizes otherwise unused wires in CAT 5/6 LAN cables.
To power
supply
PoE
Adapter
Unpowered Powered
LAN cable LAN cable
Figure 24. Powering IP desk phones over Ethernet.
For supported IP Desk and Mobile Phones, refer to appendix A, SAP BCM infrastructure compatibility list.
58
SECURITY
11 Security
SAP BCM security relies on infrastructure security described earlier as follows:
- 1.5 Introduction to data center LAN introduces a layered network structure
- 1.10 Introduction to security introduces some security viewpoints
- 3.1 Physical security covers aspects of physical security
- 4.3.3 Certificates covers certificates
- 6.2.1 Access control covers the benefits of access control
11.1 Network traffic control

Network traffic control plays a crucial role in SAP BCM security. The layered network structure of a data center
forms three security zones and if CMC is used, the fourth zone, the DMZ. The layered structure is designed to
allow only necessary traffic at each level and to facilitate connections from higher security levels to lower
security levels only between known endpoints.
In the access network layer, where the customer is considered as a known endpoint, more granular
segmentation is advised by constructing VLANs for different customers. Routing between customers is not
recommended. If there is a demand to pass VoIP calls from a customer to another, it should be done via MRS.
Network traffic control is implemented with firewalls and access-lists on switches and routers and using VLANs.
For information needed to configure access lists, see the documentation of the SAP BCM ports and protocols.
11.2 Identification, authentication and authorization

SAP BCM administrators and CDT and CMC users are identified and authenticated with user IDs and
passwords.
Connection servers are identified and authenticated with server certificates.
Partially authorized SAP BCM administrators are authorized by fully authorized SAP BCM administrators.
CDT and CMC users are authorized by SAP BCM administrators
11.3 Signed software modules

The essential SAP BCM software modules are signed with publisher ID certificates to indicate the origin and the
integrity of the modules.
11.4 Encrypted network traffic

The network connections that are most vulnerable for attackers can be encrypted.
59
AVAILABILITY AND MANAGEABILITY
12 Availability and manageability

The primary availability concept is implementing overall fault tolerance. Fault tolerance is achieved as follows:
- Spanning tree, introduced in 6.3.2 Connecting sites together. This is applicable for in LANs
in general
- NIC teaming, introduced in 6.2.3.2 Teaming
- HSRP, introduced in 6.3.3 Data connectivity and routing
- Multiple sites, introduced in 6.3 Multiple sites
- Facility recommendations, introduced in 3 Environmental and facility recommendations
- SQL and File server clusters, introduced in 4.3.1 Microsoft SQL Server 2005
- Server and hardware fault tolerance, introduced in 4.1.2.2 Server chassis and operability
- SAP BCM HAC (high availability controller), explained below
12.1 SAP BCM HAC

HAC stands for high availability controller. It is a SAP BCM component installed on every SAP BCM server, and
also referred to as a HAC node. HAC monitors the health of local services, typically each virtual unit, and
communicates with other HAC nodes over the network with a kind of a heart-beat protocol.
SAP BCM components for a particular service are installed on two or more HAC nodes and configured with
identical settings. One of these is active at any given time and referred to as the active node or the active
instance. The standby nodes remain inactive as long as they receive OK status information from the active
node. Failover nodes are prioritized primarily by the name of the instance element and secondarily by the ID of
the instance element. The failover entity is one or more virtual units.
HAC Node 1 HAC Node 2 HAC Node 3
VU_HAC VU_HAC VU_HAC
VU_CORE VU_CORE VU_CORE

atus
ns
notificatio
Regular st
s
tatu
u l ar s ons
Reg tificati
no
Figure 25. HAC nodes. The node 1 is active and the nodes 2 and 3 are prepared failover destinations.
HAC failover can also be initiated manually, for example, for the duration of maintenance tasks. HAC can also
be configured to notify the SAP BCM Alarm Server about its statuses.
60
12.2 SAP BCM Alarm Server

The Alarm Server retrieves status information from HAC nodes. The Alarm Server can be configured to forward
these alarms to configured destinations as:
- E-mail messages
- SMS messages
- SNMP (simple network management protocol) traps
12.3 SNMP
SNMP (simple network management protocol) is part of the Internet Protocol Suite as defined by Internet
Engineering Task Force (IETF). SNMP is used in network management systems to monitor network attached
devices for conditions that warrant administrative attention.
Several SNMP management systems exist on the market and there is no particular preference for any of them.
Basically SNMP defines the following message types:
- SNMP GET REQUEST
- SNMP SET REQUEST
- SNMP TRAP
SAP BCM sends only SNMP traps. SNMP GET and SET messages can be used for managing other SAP BCM
infrastructure devices supporting SNMP.
SNMP management systems typically include sophisticated functions, such as ability to:
- Filter the most relevant messages
- Send e-mail and SMS alerts initiated by events in the monitored system.
- Log events for further investigation.
- Export event data to files, sheets or syslog servers for reporting purposes.
61
Figure 26. SNMP network view.
Figure 27. SNMP SAP BCM servers view.
12.4 Miscellaneous
SAP BCM operators should consider stopping unnecessary Windows services to minimize server and network
utilization and vulnerability. Furthermore SAP BCM operators should consider stopping the optimization of SQL
Server performance. For more information see the documentation of Windows Server and SQL Server.
SAP BCM Infrastructure Administrator (IA) and Virtual Unit Administrator (VUA) are used to install and
configure SAP BCM components. For more information see the documentation of SAP BCM.
62
DEPLOYMENT, SOFTWARE DISTRIBUTION AND CONFIGURATION
13 Deployment, software distribution and configuration

Deployment issues were introduced in 1.12 Deployment, software distribution and configuration but they
were also discussed thoroughly through this document. Deployment may be seen as a twofold project. On the
one hand, it deals with SAP BCM functionality and parameter definitions, such as queues, prompts and
telephone numbering, but on the other hand, deals with technical infrastructure definitions and preparations.
Service providers may consider running different SAP BCM infrastructures with different service level
characteristics, such as 24/7 and 24/5. The implementation of each service agreement would be possible in a
SAP BCM infrastructure where the service level characteristics match or exceed the requirements in the
corresponding service level agreement.
This arrangement may clarify the urgency of administrative and operative alternation in case of incidents. This
arrangement also adds flexibility for maintenance windows during which routine maintenance tasks are
performed without explicit notifications.
13.1 Software distribution

Software components required by CDT are available as Windows Installer files and distributed and installed to
the client workstations either manually or by means of Microsoft SMS or Microsoft AD group policies. The first
time installation requires authorization for installing software and is typically done with administrative user
rights. Subsequent updates are performed by SAP BCM ActiveX Proxy and do not require administrative
intervention.
Figure 28. Windows Installer view of SAP BCM Terminal Setup.
The terminal.msi file contains all client-side software components but they are also available as separate
installation files. For example added and/or updated support for headsets and handsets are provided as, for
example, terminal_HS_device.msi files, where device is the name of the device or its manufacturer.
63
SIZING
14 Sizing
Sizing is covered in this document as follows:
- 1.13 Introduction to sizing
- 2.3 Virtual units
- 4.1.1 The number of servers
- 4.1.2.3 Server specifications
- 4.2 Operating systems
- 4.3.1 Microsoft SQL Server
- 5 Gateways (the sizing information is available in appendix A)
- 6 Data center LAN
- 6.1.2 LAN capacity
- 6.3 Multiple sites
- 7 Customer LAN
- 9 Telephony and data connections
- Appendix B Sample SAP BCM servers
The basic principle is that SAP BCM is a modular system that scales up by adding components to achieve
increased capacity. Components with high utilization can be multiplied. The following are exceptions:
- There can be only one CEM server per each customer instance.
- There can be only one CEM database per each customer instance.
- There can be only one CPM database per each customer instance.
The remaining components are not critical capacity-wise or can be multiplied to increase capacity. Database
server performance is increased by scaling up the hardware, such as disks, memory and CPU. One CEM
server is capable of handling at least 100000 calls per hour.
For components that can be multiplied, the following maximum limits are recommended:
- HBR 1000 simultaneous calls
- SBR 2000 simultaneous calls
- MRS 800 simultaneous prompts or recordings or 1000 simultaneous NAT calls or SRTP calls
- CS 500 simultaneous connections
64
INTEROPERABILITY WITH OTHER SYSTEMS
15 Interoperability with other systems

Interoperability with other systems, such as Cisco Call Manager (CM) or Microsoft Office Communications
Server (OCS), is achieved at basic call level by sharing the gateway(s) between the systems and configuring
respective call routing on the gateway(s) similar to the configuration in chapter “Connecting to a PBX”.
LAN
Extensions Extensions
100 - 199 200 - 299
SAP BCM Outgoing Microsoft

calls OCS
xxx100 – xxx200 -
xxx199 xxx299
xxx100 – xxx200 -
xxx199 xxx299
PSTN
Figure 29. SAP BCM and Microsoft OCS are sharing common
gateway capacity.
Incoming calls are routed based on the dialed number to either SAP BCM or Microsoft OCS. A dial peer is
configured on the gateway (Cisco in this sample) for both SAP BCM and Microsoft OCS. Both dial peers define
a session target (the SAP BCM and Microsoft OCS SIP counterparts) with which the control protocol is
negotiated and a destination pattern that matches the dialed telephone numbers with either of the systems.
Outbound calls are routed on both systems to the gateway and by the gateway to the PSTN.
65
INTEROPERABILITY WITH OTHER SYSTEMS
LAN
100 - 199 200 - 299
SAP BCM 200 - 299 Microsoft

OCS
100 - 199 100 - 199
Figure 30. Calls between SAP BCM and Microsoft OCS

routed via common gateway capacity.
Calls between SAP BCM and Microsoft OCS can be routed via the gateway. The drawback of this configuration
is that internal calls consume gateway capacity.
LAN
100 - 199 200 - 299
100 - 199
200 - 299
SAP BCM Outgoing Microsoft
calls OCS
xxx100 – xxx200 -
xxx199 xxx299
xxx100 – xxx200 -
xxx199 xxx299
PSTN
Figure 31. Optimizing call paths.
An alternative way to route calls between SAP BCM and Microsoft OCS is to configure a SIP trunk between
them. According to the standards, this is possible, but it has not been fully tested yet. The same is true for
Cisco Call Manager.
66
GLOSSARY
16 Glossary
ABBREVIATION (TERM) DESCRIPTION OR SYNONYM
10Base-T Standards for Ethernet over twisted pair or copper-
100Base-TX based computer networking physical connectivity
1000Base-T methods. The currently most widely used of these are
10BASE-T, 100BASE-TX, and 1000BASE-T running
at 10 Mbit/s, 100 Mbit/s and 1000 Mbit/s (1 Gbit/s)
respectively.
3G (third generation) The level of development related to wireless
technologies. The preceding levels were 1G (included
analog standards such as FDMA and NMT), 2G
(included digital standards such as CDMA and GSM),
and 2.5G (included the packet-based GPRS
standard). The 3G standards include UMTS (based on
GSM) and WCDMA (based on CDMA).
A number The number where the call or message comes from
(i.e. the caller’s number or the source number).
Absence A user is away or not available and cannot be
reached.
ACD (automatic call distributor) A module which manages inbound calls by using the
destination number.
A/D, A/D conversion Analog to digital conversion and vice versa
ActiveX ActiveX is a component object model (COM)
developed by Microsoft for Windows platforms.
Software based on ActiveX technology is prevalent in
the form of Internet Explorer plugins and, more
commonly, in ActiveX controls, ActiveX based
applications launched from web pages
Agent A user who handles queue calls and interacts with
customers. Usually related to contact centers.
AS (alarm server) A server receiving alarms from a HAC node and
distributing those alarms according to its rule sets.
ASP (application service provider) An enterprise that provides other enterprises or
individuals remote access to application programs and
services over the Internet.
ATL, ATLTERMINAL The core module required for the phone functions in
the Communication Desktop (CDT) application. This
ActiveX component is installed on a client workstation.
Attended transfer An active call is not transferred to another number
until you see whether it is answered or not. The call is
put on hold automatically, and you can release and
continue it if the other party does not answer.
Compare to the blind transfer method.
Auto-allocation mode The call queue mode where you get automatically the
next inbound call from the queues you are currently
logged into (i.e. serving as an agent). Each call is
offered separately to the agents who are logged into
the queue. Compare to hunt group mode.
Availability information Indicates whether a user is absent or present. Related
to PRS profiles in the Communication Desktop (CDT)
application.
67
GLOSSARY

B number The target of the call or message (i.e. the destination
number).
Blind transfer An active call is transferred to another number without
knowing whether the call is answered or not. Compare
to the attended transfer method.
Bridge (H.323 or SIP) A core module for connecting the registered terminal
devices and the gateways to the CD core module.
C number The target of the call which is forwarded from the B
number.
Campaign Defines the contents of the outbound call set (such as
the customers, scripts and special rules) in the
Outbound (OB) application.
CD (Call Dispatcher) The core module for low-level call handling.
CDT (Communication Desktop) An end user application related to enterprise
telephony systems and contact center operations.
CEM (Communication Event Manager) The core module for top-level call handling.
CEM database The system database for call handling.
CD (call dispatcher) The core module for low-level call handling.
Chat, chatting Real-time communication between users by using
computing devices.
ClientCom The communication interface between the client-level
applications.
Codec (coder/decoder) A module which combines analog-to-digital and digital-
to-analog conversion.
Company An external customer or an internal employer in the
CPM database. Contacts are always linked to one or
more companies.
Contact An external customer or an internal employee in the
CPM database. When internal user accounts are
transferred from the CEM database to the CPM
database, they are interpreted as contacts. Contacts
are always linked to one or more companies.
Contractor The party that uses the services of an outbound call
center to run its outbound campaigns. Used in the
Outbound (OB) application.
CPM Administrator An administration application related to the CPM
database and predefined outbound call campaigns.
CPM database (Contact Process Manager)The system database for
managing customer information and activities (such as
tasks).
CS (connection server) A SAP BCM module connecting terminals to other
SAP BCM components.
CTI (computer-telephony integration) The use of computers for managing and making
telephone calls.
Customer An external company or contact in the CPM database.
Customizer, customizing file A text file in the CEM server which contains dedicated
customer-specific values.
DB, db (database) A collection of information which is organized by using
predefined rules.
DHCP (dynamic host configuration protocol) Dynamic Host Configuration Protocol (DHCP) is a
protocol used by networked devices (clients) to obtain
68
GLOSSARY

various parameters necessary for the clients to
operate in an Internet Protocol (IP) network.
Dialer A module (such as the third-party Sytel Softdial dialer)
which controls the outbound call sequence, timing and
agent assignment in the Outbound (OB) application.
Directory Either a CEM directory defined in the System
Administrator application, or a segment which is
displayed as a directory in the Communication
Desktop (CDT) application.
DMZ (demilitarized area) In computer security, a demilitarized zone, a
demarcation zone or perimeter network, is a physical
or logical subnetwork that contains and exposes an
organization's external services to a larger, untrusted
network, usually the Internet. The purpose of a DMZ is
to add an additional layer of security to an
organization's Local Area Network (LAN); an external
attacker only has access to equipment in the DMZ,
rather than the whole of the network.
DTMF (dual tone multi-frequency) The signals you generate by pressing the keypad of a
traditional phone.
DU (Data Universe) The data warehouse and reporting software.
E1, E1 line A single physical wire in telecommunications that can
be used to carry many simultaneous voice
conversations. It is widely used in almost all countries
outside USA, Canada and Japan. The line data rate
for E1 is 2.048 Mbit/s (full duplex) which is split into 32
time slots and can carry 30 simultaneous voice
conversions.
EDGE (Enhanced Data rates for Global Evolution) Also known as EGPRS. A packet switched radio
network for data transmission by mobile devices. A
successor of GPRS. Also considered a 2 or 2.5 G
(second generation) network.
E-mail channel The queue type which is used for receiving and
handling e-mail messages in the Task Manager (TM)
application.
ETC (external terminal controller) ETC converts IP desk phone functionality by imitating
BCM soft phones and thus standardizes IP desk
phone features towards CEM.
External agent A user who is logged into the software from an
external number (mobile or fixed). External agents
serve in queues remotely.
FBR (Federation Bridge) The core module for interconnecting several SAP
BCM systems.
G.711 G.711 is an ITU-T standard for audio companding. It is
primarily used in telephony.
G.729 G.729 is an audio data compression algorithm for voice
that compresses voice audio in chunks of 10
milliseconds. G.729 is mostly used in Voice over IP
(VoIP) applications for its low bandwidth requirement.
Standard G.729 operates at 8 kbit/s.
GK (gatekeeper) (H.323 or SIP) A core module for registering the terminal devices to
the CD core module. A SIP gatekeeper is also called
registrar.
69
GLOSSARY

GMT/UTC (Greenwich Mean Time/Coordinated The standard time system used in the software. Times
Universal Time) in different time zones are calculated in relation to the
GMT time.
GPRS (General Packet Radio Service) A packet switched radio network used for data
transmission by mobile devices. GPRS is a 2G
(second generation) network.
GUI (graphical user interface) The graphical interface for human-computer
interaction (HCI). GUIs make it easier to use the
software applications, especially when compared to
command-based interfaces.
GW (gateway) (H.323 or SIP) An external module for connecting the system to an
external network (usually to the PSTN network).
H.323, H323 A standard protocol for audio, video, data, internet
phone, and VoIP transmissions.
HA (high availability) A system or module which is operational for a required
time without uncontrolled interruptions.
HAC (High-Availability Controller) An administration application related to the system
infrastructure.
HBA (host bus adapter) Used in San systems to connect servers to storages.
HBR (H.323 bridge) A SAP BCM component acting as H.323 registrar
towards H.323 devices and performing protocol
translation from H.323 to proprietary protocols towards
other SAP BCM components and vice versa.
Hunt group mode The call queue mode where you can select any
inbound call from the queues you are currently logged
into (i.e. serving as an agent). Each call is offered
simultaneously to all agents who are logged into the
queue. Compare to auto-allocation mode.
IA (Infrastructure Administrator) An administration application related to the system
infrastructure.
ICL (infrastructure compatibility list) List of SAP BCM compatible devices
IE ( internet explorer) Windows Internet Explorer (formerly Microsoft Internet
Explorer abbreviated MSIE), commonly abbreviated to
IE, is a series of graphical web browsers developed by
Microsoft and included as part of the Microsoft
Windows line of operating systems starting in 1995.
IIS (Internet Information Server) A Microsoft server product which is used for various
web-related tasks, such as managing services and
sharing information.
iLO (integrated lights-out) Integrated Lights-Out (iLO) Standard combines basic
management functions and diagnostics with essential
Lights-Out functionality as standard components of the
server. Used by HP.
IM (instant message) Short messages sent and delivered by using the
Communication Desktop (CDT) application.
Inbound Incoming (communication events).
IP (Internet Protocol) The method and technology for sending data between
computers on the Internet.
IP phone A telephone based on IP technology.
IP v4 Internet Protocol version 4 (IPv4) is the fourth iteration
of the Internet Protocol (IP) and it is the first version of
70
GLOSSARY

the protocol to be widely deployed.
ISDN Q.921 ITU-T Recommendation Q.921, is the second layer
protocol on the ISDN protocol stack in the D channel.
ISDN Q.931 ITU-T Recommendation Q.931 is ISDN's connection
control protocol. Q.931 is a layer 3 protocol, mainly
used for the ISDN call establishment, maintenance,
and release of network connections.
ISP An Internet service provider is a company or business
that provides access to the Internet and related
services.
IVR (Interactive Voice Response) A system which supports interaction between the
caller and the system. For example, the caller may
hear a prerecorded prompt which instructs to enter
data with the phone keypad.
J1, J1 line A single physical wire in telecommunications that can
conversations. It is used in Japan. A J1 line can carry
23 simultaneous voice conversions.
LAN (local area network) A group of computing devices which are used over a
shared data line within a limited geographical area.
MAGENT The core module required for the messaging functions
in the Communication Desktop (CDT) application. This
MCB (Mobile Connection Bridge) The core module for connecting the SPS terminal
devices and the server modules securely.
MCTABUFF The core module required for ClientCom integrations
and the task management integration. This ActiveX
component is installed on a client workstation.
MMS (multimedia messaging service) A method for delivering multimedia data to mobile
phones and other devices.
Mobile phone A cellular telephone, cell phone, or portable hand
phone.
MPLS (multi protocol label switching) In computer networking and telecommunications, Multi
Protocol Label Switching (MPLS) is a data-carrying
mechanism that belongs to the family of packet-
switched networks.
MRS (Media Routing Server) The core module for playing prompt files. It also
converts the RTP stream into a WAV file when a caller
leaves a voicemail message.
MsgCleaner The module cleaning old messages.
MsgToMail The module converting messages to e-mails.
MsgToSMS The module converting messages to SMS messages.
MSI The file format for Microsoft Windows Installer
packages. Usually data in installation packages is
compressed to decrease the size. The packages
make it easier to install software applications and
modules and to configure some initial settings during
the installation.
MTD (Multi-terminal Desktop) Functions for defining multiple terminal devices for
receiving inbound calls, and for selecting which one of
the devices is used when making outbound calls.
Used in the Communication Desktop (CDT)
71
GLOSSARY

application.
NAT (Network Address Translation) An IP address used in one network (the inside
network) is translated to a different IP address known
in another network (the outside network). Often
involves address mapping and firewall configuration to
improve security.
OB (Outbound) An end user application related to predefined
outbound call campaigns.
Operator A user who acts as a switchboard operator.
Outbound Outgoing (communication events).
PBX (private branch exchange) A traditional corporate telephone system which usually
includes switchboard hardware.
PCM, 64 kbit/s PCM (pulse-code modulation) Pulse-code modulation (PCM) is a digital
representation of an analog signal where the
magnitude of the signal is sampled regularly at
uniform intervals, then quantized to a series of
symbols in a digital (usually binary) code. PCM has
been used in digital telephone systems and is also the
standard form for digital audio in computers.
PDA (personal digital assistant) A hand-held device for mobile computing.
PDC (Predictive Dialing Controller) A CEM module which runs the outbound campaigns in
the technical sense. Used in the Outbound (OB)
application.
Person An external individual in the CPM database. Persons
are not connected to companies and are usually
private persons.
Phone for MS Office Outlook An extension application which makes it possible to
use some phone and availability functions in the MS
Office Outlook application.
PLMN (public land mobile net) In telecommunication, a public land mobile network
(PLMN) is a network providing land mobile
telecommunications services to the public.
Access to PLMN services is achieved by means of an
air interface involving radio communications between
mobile phones or other wireless enabled user equipment
and land based radio transmitters or radio base stations
POP (point-of-presence) An internet access point which has a unique IP
address and provides an access to the rest of the
Internet.
Presence A user is free and can be reached.
Prompt An audio message file in the WAV format.
PRI (Primary rate interface) The primary rate interface (PRI) is a
telecommunications standard for carrying multiple
DS0 voice and data transmissions between two
physical locations.
PRS (Personal Reachability Services) Functions related to profiles and availability
information. Used in the Communication Desktop
(CDT) application and Smartphone Suite (SPS)
application.
PRS profile An absence, presence or conference profile which
defines how inbound calls are handled depending on
your availability.
72
GLOSSARY

PSTN (public switched telephone network) The collection of interconnected public telephone
networks and systems.
QoS (quality of service) In the field of computer networking and other packet-
switched telecommunication networks, the traffic
engineering term quality of service (QoS) refers to
resource reservation control mechanisms.
Queue routing The rules for offering calls to the agents who are
serving in the queues in the auto-allocation mode.
R number The term used for the original external source number
(the A number) in the following special case: the
system is configured to display the original number
even when the call has been forwarded within the
system before it is finally forwarded to another
external number. Normally the system displays the
personal extension number or the queue number as
the source number.
RTP (Real-time Transport Protocol) A standard protocol for audio, video, data, internet
SAM (Service Availability Monitor) A core module which monitors the state and
responsiveness of systems by simulating phone calls
and HTTP requests.
SAN (storage area network) A Storage Area Network is an architecture to attach
remote computer storage devices such as disc arrays
to servers in such a way that, to the operating system,
the devices appear as locally attached.
SBR (SIP Bridge) A SAP BCM component acting as SIP registrar
towards SIP devices and performing protocol
translation from SIP to proprietary protocols towards
other SAP BCM components and vice versa.
SBR (skill-based routing) A queue routing method in the software. The software
offers calls to the agents who are most suitable to take
the call.
Segment A target group which is created in the CPM database
and displayed as a directory in the Communication
Desktop (CDT) application. It contains persons,
contacts, and companies. Segments may be
company-wide (created in the CPM Administrator
application) or personal (created in the Task Manager
(TM) application).
SIP (Session Initiation Protocol) A standard protocol for audio, video, data, internet
SMS (systems management server) Microsoft Systems Management Server is a software
product for managing Windows computer systems
providing remote control, patch management, software
distribution, and hardware and software inventory.
SMS (short message service) A method for delivering short messages to mobile
phones.
SNMP (simple network management protocol) SNMP protocol forms part of the internet protocol suite
as defined by the Internet Engineering Task Force
(IETF) and is used in network management systems
to monitor network-attached devices for conditions
73
GLOSSARY

that warrant administrative attention.
SOAP (Simple Object Access Protocol) The method which allows to exchange data between
applications running on different platforms.
SPS (Smartphone Suite) An end user application related to mobile usage.
SQL (Structured Query Language) A programming language used for database queries
and updates. May also refer to a database server or
program.
Superior-assistant Roles related to special queue functions (previously
called boss-secretary).
Switchboard Traditionally hardware (a telephone routing table) for
routing calls and connecting calls to other users.
System Administrator An administration application related to the system
data and configuration.
T1, T1 line A single physical wire in telecommunications that can
conversations. It is widely used in USA and Canada.
The line data rate for T1 is 1.544 Mbit/s which is split
into time slots so a T1 line can carry 23 simultaneous
voice conversions.
TAPI (Telephony Application Programming Interface) A programming interface which allows to make
telephone and video calls by using computers.
Task Manager Extension for MS Office Outlook An extension application which makes it possible to
create tasks manually from e-mail messages.
TCP/IP (Transmission Control Protocol/Internet A method and language for sending data between
Protocol) computers on the Internet.
Telco Telco is a generic term for telephone companies
TFTP (trivial file transfer protocol) Trivial File Transfer Protocol (TFTP) is a very simple
file transfer protocol, with the functionality of a very
basic form of FTP
TM (Task Manager) An end user application related to task management.
It is also used for creating and maintaining customer
data and your personal segments.
User Administrator An administration application related to the user
accounts.
VLAN (virtual LAN) Virtual LAN, commonly known as a VLAN, is a group
of hosts with a common set of requirements that
communicate as if they were attached to the same
wire, regardless of their physical location.
Voicemail Traditionally a telephone answering service where
callers can leave messages into a voicemail box. Also
an application and functions in the Communication
Desktop (CDT) application.
VoIP (Voice over IP) A method and technology for transferring voice by
using an IP-based data network.
VPN (virtual private network) A method for offering remote users secure access to a
network.
VU (virtual unit) A group of technical services that are managed as a
single unit. Related to the system infrastructure.
VUA (virtual unit administrator) Tool for installing, upgrading and removing BCM
software.
VUMU (Virtual Unit Management Utility) An administration application related to the system
74
GLOSSARY

infrastructure.
WC (WebClient) A software object acting as an interface between an
user interface and a database.
WLAN (wireless local area network) A group of computing devices which are used over a
wireless link within a limited geographical area.
WVP The core module required for the video call function in
the Communication Desktop (CDT) application. This
75
APPENDIX A: SAMPLE SAP BCM SERVERS
17 Appendix A: Sample SAP BCM Servers

For sample BCM servers, refer to the current ICL list available on BCM support pages.
76

IT Infrastructure Requirements Needed To Run SAP BCM Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IT Infrastructure Requirements Needed To Run SAP BCM Software

Uploaded by

Copyright:

Available Formats

INFRASTRUCTURE OVERVIEW

Software version 7.0

1 Introduction to SAP BCM infrastructure 5

2 Site landscapes and connectivity. 18

3 Environmental and facility recommendations 23

4 Server hardware, operating systems and software 26

6 Data center LAN 40

9 Telephony and data connections 54

12 Availability and manageability 60

13 Deployment, software distribution and configuration 63

15 Interoperability with other systems 65

17 Appendix A: Sample SAP BCM Servers 76

1 Introduction to SAP BCM infrastructure

1.1 Introduction to site landscapes and connectivity

Figure 1. A Basic SAP BCM in-house landscape.

PSTN/PLMN subscribers CMC

PRI - Electrical & mechanical adaptation

Figure 2. A Basic SAP BCM service provider landscape.

1.2 Introduction to environmental and facility recommendations

1.3 Introduction to server hardware, operating systems and

1.4 Introduction to gateways

10/100 Base-T Ethernet E1, T1 or J1 line

Chapter 5, Gateways, covers gateways in more detail.

1.5 Introduction to data center LAN

Customer A Customer B Customer C Customer D Customer E

Chapter 6, Data center LAN, covers this topic in more detail.

1.6 Introduction to customer LAN

Figure 5 shows a single site customer LAN connected to a

The service provider is responsible for keeping the services

The telcos and/or ISPs are responsible for the operability

The most demanding requirement regarding the data link

Figure 5. A single site customer LAN

Service link Service link

Site 1 Site 2 Site 1 Site 2

Chapter 7, Customer LAN, covers this topic in more detail.

1.7 Introduction to storage systems

Chapter 8, Storage systems, covers this topic in more detail.

1.8 Introduction to telephony and data connections

1.9 Introduction to user terminals

Chapter 10, User terminals, covers this topic in more detail.

1.10 Introduction to security

SIP SIP Data Center LAN

Customer LAN ODBC

SIP H.323 Gateway

Figure 8. An overview of protocols used by SAP BCM.

Chapter 11, Security, covers this topic in more detail.

1.11 Introduction to availability and manageability

- High Availability Controller (HAC)

- Infrastructure Administrator (IA, former IA + VUA)

1.12 Introduction to deployment, software distribution and

- Telephone number ranges and call volumes

1.13 Introduction to sizing

Chapter 13, Sizing, covers this topic in more detail.

2 Site landscapes and connectivity.

2.1.1 Human interface modules

2.1.2 Service modules

2.1.3 Integration interface modules

2.2 Communication Channels

2.3 Virtual units

Grouping based on functionality can be as follows:

- VU_CORE for core components, such as CEM, CD and Data Collector

Grouping based on access requirements can be as follows:

- VU_IWR for internal web services accessed by the system itself