The Rainbow Guest Connect application provide a smartphone client application running on iOS and Android

smartphones and a customizable self-service web portal.

Smartphone application Self-service web portal

For more information on Rainbow Guest Connect, please refer to Rainbow Guest Connect Solution Presentation

2.3.2.10 System and Infrastructure

The following RTUs provide system and infrastructure capability to the OTEC platform:
System and Description RTU id Application
Infrastructure

SIP Trunk channel Allows connecting the Business Telephony to a SIP public 3JE31038AA Business Telephony
Provider

8770 MCS Allows provisioning the OTEC platform, getting 3JE31098AA Management
Management Pack report/statistics/CDR and managing alarm

8770 MCS Allow to ensure 870 high availability 3JE31124AA Management

Management
redundancy

8770 Local Pack Allow to deploy a local 8770 dedicated to a company 3JE31099AA Management

OTEC Selfcare Allows delegating key features to the end user and the 3JE31183AA Selfcare
telecom admin of the end customer

Passive Call server Allows providing local call survivability on a site when the 3JE31000AA Business Telephony
(PCS) cloud link is broken

Call Server Allows providing fault tolerant capability with call server 3JE31001AA Business Telephony
redundancy duplication

Encryption per Capability to encrypt signaling and media of all the devices 3JE31209AA Business Telephony
PCS connected to one media gateway

2.3.2.10.1 SIP Trunking

By default, no SIP trunk channel is delivered to the company. If the service provider sells the OTEC solution with SIP
Trunking connectivity, the enterprise has to configure the amount of SIP Trunk channels to be subscribed thanks to
this option.
If the SIP trunk provider is not yet qualified by ALE, a qualification can be done by the service provider with the help
of ALE during the OTEC lab qualification process.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 31

2.3.2.10.2 ISDN Trunks
ISDN trunks allow to connect the company to the PSTN network using T0 or T2 trunk. Dedicated media gateways per
company are required to connect the ISDN trunk to the OTEC solution. The number of T0/T2 channels per media
gateway is defined when purchasing the media gateways.
There is no RTU associated to ISDN Trunk.

2.3.2.10.3 8770 MCS

The Alcatel-Lucent OmniVista® 8770 Network Management System (NMS) is an all-in-one graphical
management application that offers a unified view of the ALE communication network. It includes the following
applications:
- Unified User Management:
• Quick user provisioning with profiles
• SIP devices deployment and user association
• Mass provisioning
• User configuration
- System configuration:
• OpenTouch Multimedia Services (OTMS)
• Alcatel-Lucent OmniPCX Enterprise Communication Server (OXE)
• Graphical view of Alcatel-Lucent Smart DeskPhone, Premium DeskPhone, DeskPhone, DeskPhone 8
Series, DeskPhone 9 Series
- Topology and alarms monitoring:
• Notifications of urgent situations
• Topology maps
- Accounting:
• Multi-carrier and multi-currency accounting
• Consolidated view of telecommunications expenses
• Delivered with a set of predefined reports
• Possibility to create personalized reports
- Performance monitoring:
• KPI Measurement
• Notification of threshold crossing
• Attendants, trunks, base stations and VoIP communications performances monitoring
- MCS features:
• Automated emailing to lists of customers according to their preferences
• Consolidated alarms monitoring
• Backups, upgrades
• User MAC (Moves, Adds and Changes)
• Performance and accounting
• Asset management
• Management domains:
- Distributed topology: delegate user management to local administrator
- OTEC Service Provider: delegate user management to customer admin
Please refer to TBE026 - OmniVista 8770 NMS Global Presentation for detail.
OmniVista 8770 also provides a simple Web selfcare portal with the following features:
• Configure the programmable keys of his device
• Activate the Do Not Disturb mode
• Configure the call forwarding

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 32

2.3.2.10.4 OTEC Selfcare
The OTEC Selfcare is a web application allowing the OTEC Business Partner to delegate to the end customer some
key features of the OTEC service.

With the OTEC Selfcare, the end user can:

- Configure the programmable keys of his device
- Activate his Do Not Disturb mode
- Configure his call forwarding
- Lock the pad of his device
- Reset his pin code
The local admin can:
- Create / Delete devices
- Associate voicemail to device
- Manage tandem and remote extension
- Manage desktop sharing
- Manage hunting groups and pickup groups
- Manage Automatic Call Distribution (ACD)
- Perform all the end user features defined above
The super admin can:
- Configure OXE and OT MS nodes
- Associate LDAP server for user authentication to the OXE node
- Manage Group, Enterprise, Site
- Create local admin and restrict rights based on site, cost center, entity

2.3.2.10.5 Passive Call Server

The Passive Call Server (PCS) allows the service continuity if a major incident occurs (e.g.: connectivity lost
between the enterprise site and the data center).
In such a case the Passive Call Server allows the devices connected on the site communicating together by voice, and
communicating outside if some ISDN trunks are available on the local Media Gateway.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 33

2.3.2.10.6 Call Server Redundancy
Call server redundancy ensure service continuity. It is based on the deployment of a second call server allowing
hot stand-by high availability. The redundancy can be local to ensure the service continuity in case of a failure on the
main call server.
When the second call server is deployed in a different geographical location, it ensures a service continuity in case of
major disaster in the main data center.

2.3.2.11 OmniPCX Open Gateway

The OmniPCX Open Gateway (O2G) is a standalone application providing Open Web Services on top of OXE
communication platforms.
This gateway simplifies the vertical integration and development of customer centric services from third party partners
or end-customers. It provides a unique set of REST full APIs covering Advanced Telephony, Management and
Analytics domains.

The following RTU options are available:

System and Description RTU id Application

Infrastructure

Management & Provide access to OXE Management and Analytic through 3JE31215AA O2G
Analytics O2G API.

Advanced Provide access to OXE Advanced telephony through O2G API. 3JE31216AA O2G
Telephony

For detailed information please refer to: TBE098 - OmniPCX Open Gateway Presales Presentation

2.3.2.12 Visual Notification Assistant

Visual Notification Assistant is an all in one solution, embedding several mass notifications features. It provides a
simple tool for configuring multi-channel notification, multi-party conferencing, mass notification and integration with
Rainbow.
VNA enables companies and institutions to respond to safety issues such as in the fields of transportation and
education.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 34

 System and Description RTU id Application
Infrastructure

VNA System option VNA System option allows notifying users using email chat or 3JE31213AA VNA
SMS.

VNA Broadcast user VNA Broadcast user options allows to send mass voice 3JE31214AA VNA
option notifications to users.

2.3.2.13 API
The following RTU allows opening the OTEC platform to external applications:
System and Description RTU id Application
Infrastructure

INFOCENTER LINK Allows connecting OTEC platform to a third-party vendor 3JE31069AA API
infocenter application

MANAGEMENT API Allows connecting OTEC platform to a third-party vendor 3JE31070AA API
management application

CSTA/TSAPI/TAPI Allows connecting OTEC platform to a third-party vendor call 3JE31096AA API
MONITOR control application

RECORDING API Allows connecting OTEC platform to a third-party vendor 3JE31097AA API
recording application

RSI Call center Allows a third-party contact center application to select an 3JE31112AA API
Agent RSI call center agent as target of a routing strategy. RSI call
center agent have advanced call center capabilities.

RSI Business agent Allows a third-party application to select an RSI Business 3JE31113AA API
agent as target of a routing strategy. RSI Business agent
have no advanced call center capabilities.

2.3.2.13.1 Infocenter link

The Infocenter is a computer system used to store data relative to the users of a PABX (Directory, messages
dropped and received by the users during their absence, etc.).

This information is displayed on the terminal associated with the attendant in order to simplify the attendant's work.
Each time a Connection user leaves his office, he can send an absence message to the Infocenter system to indicate
the reason for this absence and the time and date of his expected return. The Infocenter system activates
automatically the immediate forwarding or "Do Not Disturb”.
When the attendant dials a number, receives a local call or receives a call initially destined to the Connection user
having sent an absence message, the Infocenter system displays, on the terminal associated with the attendant, the
data corresponding to the absence message.

2.3.2.13.2 Management API

Move and Change APIs allows the Business Partner to connect any provisioning application collocated in the
datacenter to the OmniPCX Enterprise and OpenTouch Multimedia Services components.
These APIs allows creating/modifying/deleting:
- Users
- Devices

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 35

2.3.2.13.3 CSTA/TSAPI/TAPI Monitoring
The TAPI OTEC option allows Microsoft TAPI compatible applications to access OmniPCX Entreprise telephony
services. This item includes a specific gateway called TAPI Premium Server, to be deployed per company.

The TSAPI OTEC option allows Novell and AT&T TSAPI compatible application to access OmniPCX Entreprise
telephony services. This item includes a specific gateway called TSAPI Premium Server, to be deployed per company.
OTCS application, Nice, Verint and ASC recorder use TSAPI API.
All the applications using the TAPI API, or the TSAPI API must be deployed in the company private cloud, either in the
customer premise or in the datacenter premise.

2.3.2.13.4 RSI (Routing Service Interface)

The Routing Service Intelligence is an OmniPCX Enterprise interface for voice call processing which improves
integration of a third-party Contact Center CTI application in the OmniPCX Enterprise environment. The third-party
CTI application monitor incoming calls through RSI points and define the best target (a RSI Call Center agent, or a
RSI Business agent) to route the call on, depending on a specific routing strategies.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 36

2.3.3 Mapping of high-level design architectures with offer content
The following table shows in which architecture / HLD chapter are described the different OTEC offer options.

Offer Item HLD Architecture

Business Telephony for SIP, Analog, Digital, WLAN or Architecture 1: Reference Architecture
Cellular Devices
Business Telephony for DECT Devices Architecture 11: IP-Dect
Desk sharing Architecture 1: Reference Architecture
IP Desktop client Architecture 1: Reference Architecture
Encryption per user Architecture 17: Encryption of ALE devices
Messaging Architecture 1: Reference Architecture
External SIP Messaging Architecture 5: IT Integration
Fax User Architecture 6: Fax Server integration
Universal Desktop / Mobile Architecture 2: External mobility
Multimedia Conf initiator Architecture 1: Reference Architecture
Agent Base User, CC Agent, WFM, CRI, SoftPanel, Supervisor Architecture 13: Contact Center
ALE Connect Architecture 13: Contact Center with ALE Connect
Visual Automated Attendant, Visual Notification Assistant Architecture 1: Reference Architecture
IP Attendant W/ BLF Architecture 1: Reference Architecture
Recording Architecture 12: Call recording
Hotel mode (Guest or Room) Error! Not a valid result for table.
Rainbow Guest Connect Error! Not a valid result for table.
SIP Trunk channel Architecture 1: Reference Architecture
ISDN Trunks Architecture 7: ISDN Trunks
8770 MCS Management Pack Architecture 1: Reference Architecture
OTEC Selfcare Architecture 1: Reference Architecture
Passive Call Server (PCS) Architecture 8: Survivability
Call Server Redundancy Architecture 8: Survivability
Encryption per PCS Architecture 17: Encryption of ALE devices
Infocenter link Error! Not a valid result for table.
Management API Architecture 1: Reference Architecture
CSTA/TAPI / TSAPI APIS / OO2G Architecture 15: TAPI/TSAPI/RSI applications
Recording API Architecture 12: Call recording

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 37

3 Deploying OTEC Services
A service provider can build a commercial offer based on OTEC solution either to capture new customers (acquisition
market) or to increase its revenues on his existing installed base of customers (retention market).
In term of deployment, the commercial strategy chosen by the service provider is translated into the following use
cases:
- The company subscribing to the OTEC solution is ready to rip and replace its existing communication
infrastructure
- The company subscribing to the OTEC solution wants to benefit from the OTEC experience and keeps its
existing communication infrastructure (Alcatel-Lucent or non-Alcatel-Lucent infrastructure)
The end to end network architecture proposed in this HLD supports these two use cases.
The OTEC architecture follows the National society of standards and technology (NIST) definition of cloud
computing. It is an hybrid cloud deployment model. The service is deployed for the specific use of the subscribing
enterprise. Access to the service is restricted to the enterprise only.

The service can be provided off customer premise, or both off and in customer premises.

3.1 High level architecture

In this chapter we present a high level diagram for the architecture of its complete solution.

The OTEC framework concept is to dedicated resources to an enterprise customer. Resources are:
- OTEC virtual applications (or Company instance virtual application)
- Security services (e.g. firewall, Session Border controller, Reverse proxy)
- Network services
- Customer LAN data and Voice infrastructure
Following figure presents the OTEC framework component from an end to end perspective.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 38

3.2 OTEC solution description
To deliver applications from the cloud data center to the end customer LAN, the service provider must divide the
required tasks into optimized functional areas. Effective choices within each functional area can help designers meet
application goals with respect to latency, availability, security and scale.

With the OTEC solution, components are installed on service provider datacenters as well as on customer premises.
This induces multiple technical challenges to extend the customer LAN to the distributed datacenters in a secured
manner. For example privacy from the datacenter computing area to the end customer, end to end quality of service
provisioning, datacenter LAN switching design, customer LAN infrastructure, etc..

Below figure shows typical high level cloud architecture. It includes the following areas and where OTEC architecture
is involved:
- A data center with Switching Fabric, Security, Servers, virtualization and Storage running the OTEC application
suite
- An operation center configuring and supervising the OTEC service from an end to end perspective.
- A provisioning center provisioning remotely the user subscription
- A billing center processing, rating the charging ticket to build the invoice toward the subscriber
- A public network connecting the enterprise to the fixed and mobile network. The public network can be IP
Multimedia Subsystem (IMS) or Legacy (PSTN)
- The virtual private network service connecting the enterprise sites to the datacenter through a private IP
network. Various technologies can be used to build this private network (e.g.:L2 VPN, L3 VPN, IPSec, etc.)
- The customer premises equipment with managed access router, managed switches, multi-media devices.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 39

3.2.1 OTEC solution components
The solution is made of different components provided by ALE and technology partners. These components can be
logically split according to their role. OTEC topology is flexible, most of the component are optional and their
deployment depends on the chosen options.

3.2.1.1 Applications

Component Deployment

OmniPCX Enterprise (OXE) Mandatory

OpenTouch Multimedia Service (OTMS) Optional

OpenTouch Message Center (OTMC) Optional

Media Gateway Optional

OXE Media Server (OMS) Optional

OpenTouch Contact Center Standard Edition (OTCCSe) Optional

OmniVista 8770 Optional

OmniPCX Record Optional

Document Conversion Server (DCS) Optional

TAPI Gateway Optional

TSAPI Gateway Optional

Rainbow WebRTC Gateway Optional

Visual Automated Attendant Optional

Visual Notification Assistant Optional

O2G Optional

3.2.1.2 Management
Component Deployment

OpenTouch Deployment tool (ALED) Optional

OmniVista 8770 Servers MCS Mandatory

OmniVista™ 2500 Network Management System Optional

VMware vSphere Mandatory

VMware vCenter™ Operations Management Suite Optional

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 40

3.2.1.3 IT Servers
Component Deployment

Domain Name Server Mandatory

LDAP Directory server Optional

Radius Server (AAA Server) Optional

Network time Protocol Server Optional

3.2.1.4 Infrastructure
Component Deployment

VMWare vCenter Mandatory

Compute equipment Mandatory

Storage equipment Mandatory

3.2.1.5 Network and security

Component Deployment

Switching fabric Mandatory

Firewall Mandatory

OpenTouch Session Border Controller Optional

Reverse proxy Optional

3.2.1.6 Customer premise equipment

Component Deployment

Devices Mandatory

Media Gateway Optional

Local Area Network Omniswitch Optional

Wireless Local Area Network OmniAccess Optional

Wide Area Network Enterprise Service Router Optional

3.2.2 Data Center

3.2.2.1 Overview
OTEC can be delivered in any virtualized datacenter relying on x86 processor architecture. The customer can use his
own compute and storage resources.
The goal of the compute infrastructure in the OTEC is to supply a reliable, scalable, flexible, and economical compute
platform. The platform shall possess the following attributes:
• Reliability features: The computing platform must be constructed with high availability features. The
system must have redundant power supplies, capable of being serviced without downtime or interruption. The
system must be able to run off of multiple power sources, with the ability to survive the loss of a power bus
without incident. Multiple data paths are required for network and storage connections.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 41

 • Strong supplier: The hardware supplier must be financially stable and have a history of good business
practice. The supplier should be a preferred supplier for Alcatel-Lucent. The supplier must be responsive to all
requests for information in technical, commercial, compliance and legal matters.

• Flexible configuration: the compute platform must have the capability to be assembled or configured in a
variety of ways, without wasting or stranding resources. The configuration tasks must be accessible by a
programmatic method, with a well-documented interface, fully supported by the vendor. Support offerings
must include training, consulting, online resources and call in support.
• Remote management features: The compute platform must have the capability to be managed remotely.
The remote management feature must include the ability to power cycle the machine; soft reboot: force an
orderly shutdown of the operating system; display a remote console for monitoring boot sequences; include
power and other environmental monitoring; and support remote virtual media: virtual DVD, virtual floppy disk,
and virtual USB memory keys.

• Environmental monitoring: The compute platform must contain integral temperature and humidity sensor
capabilities. These sensors must be able to signal operators and automated alert systems when exceptional
conditions and warning thresholds are reached.
• Small energy and space footprint: In adhering to Alcatel-Lucent’s company goals of minimizing
environmental impact and achieving lowered energy and carbon footprints, the compute platform must
consume minimal energy in both primary consumption and cooling load generation.
• Hardware and software support options: The support offerings must have mission critical attributes of
all hours’ service, with rapid response to incidents. The support plan must have the option for assigned
resources and rapid escalation for critical problems.

• Scalability: The solution needs to have features and construction that permits scaling, in several dimensions.
The scaling should be as seamless as possible, requiring a minimum of disruption. The selected solution must
have a product line longevity sufficient to span the current business cycle and not require changes due to
obsolesce or product line discontinuance.

3.2.2.2 Virtualization
When talking about virtualization, there are three main elements to consider:

Appli 1 Appli n Appli n+1

Virtual
Machines O.S. 1 •• O.S. n O.S. n+1

VM #1 VM #n VM #n+1

Hypervisor Hypervisor

Host

- Virtual Machine: This is an emulation of a given computer system, therefore containing an operating
system and one or more applications. It is also sometimes referred to by ‘guest machine’.
- Hypervisor: This is a piece of computer software, firmware or hardware that creates and runs Virtual
Machine(s). It presents the guest O.S. with an abstraction layer of the underlying hardware resources.
Multiple Virtual Machines, with possibly different of O.S., isolated from each other, may share the virtualized
hardware resources. It is also sometimes referred to by Virtual Machine Monitor (VMM).
- Host: This is the physical platform on which is deployed a hypervisor running one or more Virtual Machine.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 42

3.2.2.3 Virtual machine characteristics
To size a Virtual Machine, different structuring parameters have to be considered:

- Virtual CPU (number of vCPU) – a VM has at least 1 vCPU,

- The required CPU usage, expressed in MHz
- Virtual RAM (vRAM, expressed in GB),
- Virtual Hard disk (vHard disk) characteristics, comprising
o the disk space, expressed in GB
o Average disk IOPS (Input / Output Operations Per Second)
o Average disk read/write bandwidth, expressed in KB/s
- Virtual NIC (number of vNIC – virtual Network Interface Controller) - unless otherwise explicitly stated, one
vNIC is being considered.
If NAS or SAN (except SAN with fiber channel technology) is used, network bandwidth has also to be considered.

Note that RAID and the choice of its level have an impact regarding disk space and write operations (write operations
penalty: 2 for RAID1/10, 4 for RAID5 and 6 for RAID6) but not regarding read operations.

3.2.2.4 Processing resources, core and vCPU

Nowadays, hardware platform uses multi-core processors (ie processors with multiple CPU). Each CPU is called a
physical core. Some servers are even using several multi-core processors.

The VM computing resources are characterized by two parameters: the CPU usage in MHz, representing the peak
CPU usage a system may require during the busy hour, and the number of vCPUs.

A Virtual CPU (vCPU) is seen as a single core by the Virtual Machine’s operating system. It uses the same CPU clock
speed as the cores of the physical host.
If the Virtual Machine CPU usage in MHz is less than a core power, this Virtual Machine is configured with a single
vCPU.

However, if the Virtual Machine CPU usage in MHz is more than a core power, this Virtual Machine must be configured
with several vCPUs, based on the formula:

VM CPU usage in MHz

Round up to the
next integer Host’s core speed

The following rules have to be kept in mind:

- A Virtual Machine requires at least one vCPU

- A Virtual Machine cannot have more vCPUs than the number of physical cores of the host.
Note: Some types of Virtual Machines, such as OTMS and OV8770, require a minimum of 2 vCPUs to ensure a smooth
scheduling, even when the needed VM power consumption only requires the power of one core or less.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 43

Some examples, assuming a CPU clock speed of 2.4 GHz on the host:

Example 1: Example 2: Example 3:

VM CPU usage = 0.35 GHz VM CPU usage = 2.4 GHz VM CPU usage = 5.8 GHz

2 2 2

1 1 1

This VM will need This VM will need This VM will need

1 vCPU 1 vCPU 3 vCPUs

VMware scheduler dynamically allocates the various Virtual Machines into the host cores.
The CPU usage in MHz of a Virtual Machine has to comply with the following rules:

- The CPU usage required by a Virtual Machine must be available at all times.
- The GHz requirement for the Virtual Machine must include a margin of 20% to handle busy hour peaks or
maintenance operations, as well as avoid the system to experience issues that may happen on a too loaded
Virtual Machine.
- To benefit from the power of a number of CPU cores, a Virtual Machine needs as many vCPUs. No need to
assign more vCPUs.

3.2.2.5 CPU over-provisioning

As seen in 3.2.2.4, a Virtual Machine is characterized at processing level by a number of vCPUs and a CPU usage,
expressed in MHz, that includes a margin to handle busy hour peaks or maintenance operations. The former being
computed from the later by a rounding-up operation, some extra MHz are then present:

Extra power available

to other VMs

3
vCPUs required by the VM =
GHz required 2
GHz required / CPU clock speed
by the VM
rounded up to the nearest integer
e.g. 5.5 GHz 1

CPU clock speed

e.g. 2.4 GHz

If the CPU usage (measured in MHz) required by a Virtual Machine must be available at all times, the extra MHz
permitted by the rounding-up of the computed vCPUs may be allocated to additional Virtual Machines, within the
limits of the total physical CPU power provided by the server host.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 44

As a result, the overall number of vCPUs can exceed the number of physical CPU cores, to the extent permitted by the
rules mentioned above in 3.2.2.4. In such case, we talk about CPU overprovisioning, which can be characterized by
the following ratio:
Sum of vCPUs provisioned for all hosted VMs
CPU overprovisioning ratio =
Number of physical CPU cores of the server host

Remember that the only overprovisioning allowed on a given server host corresponds to this extra MHz, as illustrated
in the above figure.
CPU overprovisioning allows then deploying more Virtual Machines on the physical host. On the other side, it has to
be used in a reasonable manner to prevent latency and jitter generation, which has to be avoided for real-time
communication. Alcatel-lucent Enterprise has established maximum authorized values for the CPU
overprovisioning, which can also be seen as the maximum number of instances of a given VM that can be deployed
on a single physical core:
• OXE, A4645, EEGW: 8
• OXE-MS: 4
• OTMS, OTMC: 2
No specific maximum for other virtualized packages. Keep in mind that these maximum values may be approached
only by stacking very small Virtual Machines (for instance up to eight OXE virtual machine at 200 MHz may be
deployed on a single core).

When several virtual machines with different maximum ratio are deployed on a physical host, the smallest maximum
ratio has to be considered.

3.2.2.6 Margin and overhead

The sizing of a Virtual Machine in MHz must take into account a 20% margin to preserve some resource for
maintenance operations or user activity spikes and avoid issues due to a too loaded Virtual Machine.

Furthermore, we have to account for the hypervisor, installed on the physical platform hosting the various Virtual
Machines, which adds an extra CPU consumption at the host level. To estimate the hypervisor overhead an extra 10%
margin of the cumulated CPU usage in MHz of the various Virtual Machines, deployed on the platform, has to be
provisioned.

20% margin for VM #2

VM #2 required CPU usage in MHz 1
Appli #2 needed CPU usage in MHz

2 20% margin for VM #1

VM #1 required CPU usage in MHz Appli #1 needed CPU usage in MHz

1

10% margin for hypervisor overhead

No margin has to be considered for the cumulated vRAM requirement of the different Virtual Machines deployed on a
physical host.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 45

3.2.2.7 Resources reservation
The required amount of vRAM (in GB) by any OTEC virtualized application must be reserved. In other words, the
physical host must provide as many physical RAM as the specified amount of vRAM.
The number and speed of physical CPU cores must be planned so as to accommodate the cumulated number of GHz
required by all VMs on the physical host. In other words, the CPU usage in MHz required by all the VMs has to be
guaranteed by budgeting (ie the cumulated CPU usage of all the VMs cannot exceed the overall power of the host) …
without the need to reserve it.

3.2.2.8 Pre-requisites at physical host level

OTEC is compatible with any servers relying on x86 architecture using AMD or Intel Processing Units.

3.2.2.8.1 Servers
The servers used for an OTEC factory fit into two different main size types:
• Server-rack (also known as appliance servers): In a standard server-rack configuration, 1U (one rack
unit, 19" [48 cm] wide and 1.75" [4.45 cm] tall) is the minimum size. The most common computer rack form-
factor is 42U high, which limits the number of discrete standard server-rack directly mountable in a rack to 42
components. Each server has its own redundant power supply module, external interfaces such as network
interface cards, etc.
• Blade servers: A blade server is a stripped-down server computer with a modular design optimized to
minimize the use of physical space and energy. Whereas a standard rack-mount server can function with (at
least) a power cord and network cable, blade servers have many components removed to save space,
minimize power consumption and other considerations, while still having all the functional components to be
considered a computer. A blade enclosure, which can hold multiple blade servers, provides services such as
power, cooling, networking, various interconnects and management. Together, blades and the blade
enclosure form a blade system
The choice between both server solutions depends on the Service Provider evaluation of application growth which is
directly linked to the sales forecast. Both server solutions provide different ROI figures.

While rack-mount servers are easy to start with due to the relatively low level of investments to run the first
application; server space, power consumption savings, ease of scalability, cable reduction, hot-swapping, reliability,
and redundancy are becoming more important factors when creating larger scale environment.
Multiple solutions are available on the market and the customer can use his own infrastructure as long as it complies
with the performance requirements of the OTEC Solution, as described in the next chapter.
If needed, Alcatel-Lucent can help the business partner defining the right computing server, based on the targeted
market (company sizes and volumes).

3.2.2.8.2 Processors
Intel and AMD are supported.
- Intel processor: CPU generation is minimum XEON 35xx, 55xx, 65xx, 75xx or newer. 1 Core is considered as 1
logical CPU.
- AMD processor: CPU generation is minimum OPTERON (6000 series) or newer. 1 Core is considered as 1
logical CPU

3.2.2.9 Storage equipment’s

A storage area network (SAN) is a dedicated network and shared among the virtualization environment that provides
access to consolidated, block level data storage.
It simplifies storage administration and adds flexibility since cables and storage devices do not have to be physically
moved to shift storage from one server to another.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 46

Multiple solutions are available on the market and the customer can use his own infrastructure as long as it complies
with the performance requirements of the OTEC Solution:
- The storage must cover the needs of OTEC virtual application instances related to storage capacity (in GB,
including at least one VMware snapshot) but also in performance (Input Output per second (IOPS)).
- It is recommended to use the Thin provisioning capabilities of VMWare
If needed, Alcatel-Lucent can help the business partner defining the right storage solution, based on the targeted
market (company sizes and volumes).

3.2.2.10 VMWare environment

This section describes VMWare environment and the VMware features supported by OTEC.

3.2.2.10.1 VMware vCenter

The vSphere family of products includes:
- vCenter Server and vCenter Server Database: It is the central point for configuring, provisioning, and
managing virtualized IT environments. It provides essential datacenter services such as access control,
performance monitoring, and alarm management
- ESXi hosts, clustered by vCenter Server: the virtualization layer run on physical servers that abstracts
processor, memory, storage, and resources into multiple virtual machines
- OTEC R100 supports VMWare 6.0, 6.5 or 6.7 release.
For detail please refer to https://www.vmware.com/products/vcenter-server.html

3.2.2.10.2 VMware vCenter™ Operations Management Suite

vCenter Operations Manager is an application used to monitor and manage the health, capacity, and performance of
the virtual environment. For detail please refer to https://www.vmware.com/support/pubs/vmware-vcops-suite-
pubs.html.

VMware provides several features that can be leveraged to increase the availability of a virtualized environment. This
section presents these features as they apply to availability of the applications, the infrastructure, and the
management platform. It will give roadmap how they are planned to be applied into an OpenTouch environment.

3.2.2.10.3 VMware vMotion

vMotion allows moving a running virtual machine from one physical host to another one without stopping it. It is
typically used during software and hardware maintenance operation to avoid restarting a running VM.
OTEC support vMotion in maintenance mode only (not in traffic).
For detail please refer to https://www.vmware.com/fr/products/vsphere/vmotion.html.

3.2.2.10.4 VMware DRS (Distributed Resource Scheduler)

VMware DRS works with vMotion to provide automated resource optimization and virtual machine placement and
migration, to help align available resources with pre-defined business priorities while maximizing hardware utilization.
The use of DRS (Distributed Resource Scheduler) is supported in maintenance mode only. As a reminder:

- Automatic mode: it moves VMs continuously searching for an optimal resource usage.
- Partially automatic mode: it provides an automatic initial VMs placement and asks for recommendation
only for load balancing (under administrator decision).
- Manual mode: it provides recommendation for both initial VMs placement and load balancing (under
administrator decision).
For detail please refer to https://www.vmware.com/fr/products/vsphere/drs-dpm.html

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 47

3.2.2.10.5 VMware High Availability
VMware HA leverages multiple ESXi hosts configured as a cluster to provide rapid recovery from outages and cost-
effective high availability for applications running in virtual machines. VMware HA protects application availability in
the following ways:
- It protects against a server failure by restarting the virtual machines on other hosts within the cluster.
- It protects against application failure by continuously monitoring a virtual machine and resetting it if a failure
is detected.
For detail please refer to https://www.vmware.com/fr/products/vsphere/high-availability.html

Support of VMware HA depends on deployed applications. OTMS and OTMC supports VMWare HA. OmniPCX
Enterprise doesn’t support VMWare HA.

3.2.2.10.6 Hyper-threading
Till VMware ESXi/vSphere 6.0, Hyper-Threading had to be de-activated at Virtual Machine level by ensuring that
“Hyper-threading sharing core” parameter was configured as “none” in the Virtual Machine settings for OmniPCX
Enterprise, OTMS and OXE Media Server (OMS).

In the recent releases, improvements have been done regarding handling of hardware resources, including Hyper-
Threading, with the consequence that Hyper-threading can therefore be considered at Virtual Machine level.

3.2.2.11 KVM
From OTEC 2.3.2, KVM is also supported on a subset of application:
- OXE
- OMS
- 8770 MCS
- NGINX Reverse Proxy
- OT SBC
- OTEC Selfcare
KVM is a cost-effective hypervisor compared to VMWare. Nevertheless, VMware has some features that KVM doesn’t
provide:

WMware KVM

CPU reservation is very easy to configure. VM placement and CPU over-commitment must be
carefully managed with KVM through cgroups

VMware HA offers application independent cold No HA

redundancy VMware HA

KVM has many flavors (SUSE, RedHat, OpenStack…) and can run on several Linux distributions, whereas VMware is a
unique product.
Most of powerful virtualization management tools are included in vSphere for VMware. The VMWare management
tools are available as graphical tools for current needs (administration, supervision, management) as well as CLI and
API for automation.
KVM is mainly managed and supervised by virsh, a command line interface that is powerful but sometimes difficult to
use. Graphical tools for KVM are available but not standard and not always free.

3.2.3 Virtual applications

A virtual application is software component delivered an open virtualization format (ovf) file. A virtual application is
dedicated to a unique company.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 48

There are 2 groups of virtual applications:
- The secured virtual application: it is deployed in a customer secure datacenter subnet accessible only
from the customer premises.
Note that in case the Call Server redundancy option is selected, a second OmniPCX Enterprise (OXE stand-by)
must be deployed.

Virtual machine

OmniPCX Enterprise (OXE main)

OXE Media Server (OMS)

OpenTouch Multimedia Service (OTMS)

OpenTouch Messaging Center (OTMC)

Visual Automated Attendant

Visual Notification Assistant

O2G

OpenTouch Contact Center Standard Edition

OmniPCX Record

OmniVista 8770 (local delegated management)

TAPI Premium Server (TAPI Gateway)

TSAPI Premium Server (TSAPI Gateway)

Rainbow WebRTC GW

OTEC Selfcare

- The public virtual application: It is deployed in a customer public datacenter subnet accessible only from
the public network (internet, public voice network, …)

Virtual machine

OpenTouch Session Border Controller (OTSBC)

Reverse Proxy (NGINX)

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 49

 Component VMWare KVM

OXE Yes Yes

OXE MS Yes Yes

OTMS Yes No

OTMC Yes No

3.2.4 IT Servers
3.2.4.1 Domain Name Servers (DNS)
DNS service is used by the phones to locate the company virtual instance. The DNS is required to resolve the
company virtual instance private IP addresses located in the datacenter as well as public IP addresses of the security
elements located in the datacenter DMZ.

Two DNS servers are required, a primary and a secondary with database replication.
Alcatel-Lucent Enterprise recommends using BIND for DNS service. But the service provider can also use his
recommended DNS servers.

The DNS servers are deployed within two shared virtual machines in the public DMZ.

3.2.4.2 LDAP Directory Server

LDAP directory server allows finding contact information (telephone numbers, e-mail address, etc.) for a given
company. There is one LDAP directory server per company. It can be located either in the datacenter or in the
company premise, or in both locations with an automated synchronization from the company premise toward the
datacenter premise.
OTEC is compatible with standard LDAP server such as Microsoft™ Active Directory and OpenLDAP.
The LDAP directory server can also be used for admin and user authentication for a dedicated company.

The LDAP servers are deployed within a virtual machine close to the company virtual instance in the customer secure
zone.

3.2.4.3 RADIUS authentication server

RADIUS server is used for authentications during the login phase. OTEC is compatible with standard Radius server
such as FreeRadius.

3.2.4.4 Time Synchronization with NTP server

The NTP server is used to synchronize time between all the virtual machines. The OTEC reference architecture
recommends positioning two NTP servers in the global DMZ zone. These NTP servers are themselves synchronized
with external official NTP servers, through internet.

Time synchronization is very important to have a consistency of:

- The system logs
- The call logs
- The call detail records
- The voice mail
- The feature using time such as time-based routing, time-based screening, etc.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 50

3.2.5 Network and Security equipment
OTEC can be delivered in any datacenter class network and security elements relying on IP architecture.
Multiple solutions are available on the market and the customer can use his own infrastructure as long as it complies
with the network and security requirements of the OTEC solution.
In this reference architecture we use the Alcatel-Lucent Datacenter Switch Fabric with POD and MESH Architecture as
well as our partners (Fortinet, ACME, Blue Coat) to deliver highly scalable and secure network infrastructure.

3.2.5.1 Datacenter switching fabric

The datacenter equipment’s require being connected each other with IP network that is highly scalable, low latency,
secure and highly available.
Alcatel-Lucent’s POD and MESH architecture is based upon a resilient architecture with the network dynamically
adapting to the applications, users and devices in order to provide a high-quality user experience, as well as reducing
operation costs and management complexity.
A mesh network is a flat network that employs one of two connection arrangements, full mesh topology or partial
mesh topology.
In the full mesh topology, each node is connected directly to every other node.
A node example can be a full rack filled with HP c7000 enclosure.

A mesh network scores high on reliability, if one node can no longer operate, all the rest can still communicate with
each other, directly or through one or more intermediate nodes.
The POD and MESH can also be used in conjunction of the Virtual Machine Management from the Omnivista 2500
NMS:

The Network Understands each VM:

Provisioning requirements, Security profile, Expected QoS levels, Priority of the application
for the corporation, Specific latency and jitter requirements
Network Automatically Manages VMs:
Automatic discovery of VM location at creation time, Network configuration follows VM
moves, Dynamic tuning of QoS parameters, Requested VM moves to minimize latency

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 51

The network switching must be fault tolerant and provides at least 1Gbps redundant port per host for
application flow (front end traffic), 10 Gbps redundant port per host for storage and 10 Gbps redundant
port per host for management

3.2.5.2 Firewalls
A firewall is introduced to secure the OTEC server and to insure the public network termination.
Multiple solutions are available on the market and the customer can use his own infrastructure as long as it complies
with the firewall requirements of the OTEC solution:
The firewall must support one virtual firewall (e.g. VDOM for Fortinet products) per company. Two
virtual firewalls are also needed for management area and public area.

3.2.5.3 Session Border Controllers

A session border controller is used to:
- Secure the SIP Trunking interface between OpenTouch and the public SIP Trunks used by the company
- Allow OpenTouch users connecting to the OpenTouch service from a public IP network (3G/4G, Wi-Fi hotspot,
ADSL at Home).
The SBC can be mono tenant, in this case one SBC must be dedicated per company. If the SBC is multi-
tenant, a tenant must be dedicated per company.

OTEC Solution is natively integrated with OpenTouch Session Border Controller. It is strongly recommended to use OT
SBC to interconnect remote users and SIP Trunks.

For SIP Trunks, if the business partner has already deployed another vendor SBC, OTEC Solution may be
integrated with this other vendor SBC, but it is under the responsibility of the OTEC Business Partner:
Alcatel-Lucent Enterprise cannot guarantee the inter-working with third party SBC.

In such a case an interworking test session will have to be passed in project mode before Alcatel-Lucent supports the
deployed OTEC solution. The test procedure is part of the reference test plan.
The features requirement for the OTEC solution that have to be supported by the 3rd party SBC supplied must be at
least:
- For mono-tenant SBC
o Security Access Control Lists (ACL)
o Optionally transcode (SIP, G711 A/U to G729)
o Media Control
o Video CODEC Relay
o SIP Message Manipulation
- For multi-tenant SBC
o All Mono-tenant SBC requirements
o Logical SBCs
o Access to logical SBC via dedicated tenant VLAN
For multi-tenant SBC: The SBC is deployed within shared virtual machines across OpenTouch instance with logical SBC
connected in the global DMZ.
For mono-tenant SBC: The SBC is deployed within a dedicated virtual machine per OpenTouch instance in the
customer DMZ.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 52

OT SBC is currently available for mono-tenant deployment and multi-tenant. Deployment. The following table
compares the two deployment modes:

Criteria Mono tenant Multi-tenant

Resources Dedicated for a given company Shared amongst several companies

Economics More expensive. The company has Less expensive. Cost of the SBC usage per
to support the full cost of the OT company decreases as soon as new company is
SBC deployed on the same instance

Network Architecture Deployed in the secure zone of Deployed in the Global DMZ of the OTEC factory
each company (in the same zone than the Reverse Proxy)

IP Address Translation No translation required between Source NAT required between SBC and
SBC and Company LAN Company LAN

OT SBC Configuration Simple configuration More complex configuration

complexity

For more information on multi-tenant OT SBC Architecture please refer to chapter: 4.18 Architecture 16: Multi-tenant
SBC.

3.2.5.3.1 Reverse proxies

OTEC solution needs a reverse proxy to secure the data center network and to offer public URLs, which are reachable
from any IP public network (e.g.: 3G, Wi-Fi Hotspot). In OTEC, the reverse proxy is used by remote users.
Multiple solutions are available on the market and the customer can use his own infrastructure as long as it complies
with the reverse proxy requirements of the OTEC solution.

The requirements list is available on the Business Partner Web Site – Official statement for reverse proxies – FAQ.
If the Service Provider has no preferred Reverse Proxy vendor, Alcatel-Lucent recommends the NGINX reverse proxy.

The reverse proxy can be mono tenant, in this case one revers proxy must be dedicated per company. If
the reverse proxy is multi-tenant, a tenant must be dedicated per company.
The reverse proxy is deployed:
- For multi-tenant reverse proxy: within shared virtual machines or shared physical appliance across
OpenTouch instance with routing toward OpenTouch instance based on Public FQDN.
- For mono-tenant reverse proxy: within a dedicated virtual machine per OpenTouch instance in the customer
demilitarized zone.

3.2.6 Media Gateways

3.2.6.1 Overview
IP media gateways are controlled by the OmniPCX Enterprise Call Server through an IP connection. They are required
in 2 cases:
- Provide access to legacy terminals (TDM and analogic), PSTN and third-party systems (QSIG, H323, …).
- Provide DSP resources to the OmniPCX Enterprise call server. This DSP resources are used to play tones,
detect DTMF, …
IP media gateways are available as proprietary hardware or as a pure software component (OXE Media Server). The
OXE Media Server doesn’t provide access to legacy terminal (TDM or analogic) and legacy PSTN.
Hardware media gateways can be installed at customer premises or in the datacenter if the public access needs to be
centralized. Media gateways are dedicated per company instance. Software media gateway (OXE Media
Services) is installed in the datacenter.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 53

The OXE-MS supports Com Server duplication in the same subnetwork, as well as duplication with the two Com
Servers on two different subnetworks (spatial redundancy).

The Alcatel-Lucent Media Gateway is available with two different hardware:

Common hardware
For the common hardware, the Media Gateway consists
in Rack Modules (Rack 1 or Rack 3 modules) and
corresponds to the small and medium chassis (1.5U and
3.5U). It can be installed on a standard 19’’ rack.

Crystal hardware
For the crystal hardware, the Media Gateway consists in
crystal shelf is based on the Alcatel-Lucent Crystal
Technology (ACT) whose main characteristic is a
meshed backplane offering full connectivity between
slots. Crystal shelves can be hosted in:
- M2 cabinet: one 28-slot or two 14-slot Crystals
- M3 cabinet: two 28-slot or four 14-slot Crystals
Mi Standard 19’’ racks

Media Gateway deployment depends on the type of public accesses (PSTN, SIP), on the location of the public
accesses, on customer site or centralized, and on the level of expected survivability.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 54

3.2.6.2 Centralized SIP Trunk public access
A SIP Trunk public access requires a OXE Media Service deployed in the data center. In case of WAN outage between
the data center and the customer premises, the customer site can be secure with an OXE Passive Call Server and an
OXE media Gateway on customer site providing access to a local ISDN public access.

Central OXE Media Service, no Customer OXE

Media Gateway
In case of WAN outage, the customer site is isolated
from the OTEC service provider datacenter.
Communication from customer site to public network
are not possible.
Customer site local communication are not possible.
Communication from public network to customer site
are redirected to voice mail.

Central OXE Media Services, Customer OXE

Media Gateway with Local Survivability (PCS)
and ISDN Fallback
In case of WAN outage, customer site is secured by
the PCS.
Communication from customer site to public network
are done through the local PSTN access.
Customer site local communication are possible thank
to the PCS.
Communication from public network to customer site
(incoming external communications coming from the
central SIP trunk), are possible with the public to
private overflow mechanism of OXE.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 55

3.2.6.3 Centralized PSTN access
A centralized PSTN access requires a OXE Media Gateway deployed in the data center. In case of WAN outage
between the data center and the customer premises, the customer site can be secure with an OXE Passive Call Server
and an OXE Media Gateway on customer site providing access to a local ISDN public access.

Central OXE Media Gateway, no Customer OXE

Media Gateway
In case of WAN outage, the customer site is isolated
from the OTEC service provider datacenter.
Communication from customer site to public network
are not possible.
Customer site local communication are not possible.
Communication from public network to customer site
are redirected to voice mail.

Central OXE Media Gateway, Customer OXE

Media Gateway with Local Survivability (PCS)
and ISDN Fallback
In case of WAN outage, customer site is secured by the
PCS.
Communication from customer site to public network
are done through the local PSTN access.
Customer site local communication are possible thank
to the PCS.
Communication from public network to customer site
(incoming external communications coming from the
central ISDN), are possible with the public to private
overflow mechanism of OXE.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 56

3.2.6.4 Customer PSTN access
With this topology, the PSTN access are provider directly at the customer site. An OXE Media Gateway deployed in the
customer site. In case of WAN outage between the data center and the customer premises, the customer site can be
secure with an OXE Passive Call Server.

No Central OXE Media Gateway/Service,

Customer OXE Media Gateway WITHOUT Local
Survivability
In case of WAN outage, the customer site is isolated
from the OTEC service provider datacenter.
External incoming or outgoing communications are not
possible.
Customer site local communication are not possible.

No Central OXE Media Gateway/Service,

Customer OXE Media Gateway with Local
Survivability (PCS) and ISDN Fallback
In case of WAN outage, customer site is secured by the
PCS.
External incoming or outgoing communications are not
possible.
Customer site local communication are possible thank to
the PCS.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 57

3.2.7 Enterprise Service Router
The OmniAccess 5710 and Omni Access 5720 Enterprise Service Routers (ESR) allows connecting a small office, a
branch office or a home office to the OTEC through a standard internet connection: ADSL2+/VDSL2 or Metro
Ethernet for 5710, Metro Ethernet for 5720. In case of FTTH (Fiber To The Home), 5710 and 5720 can be connected
directly to the GPON ONT (Optical Network Terminator).
The following table provides an overview of the main features of the OA 5710 and OA 5720:

Omni Access 5710 – Enterprise Service Router Omni Access 5720 – Enterprise Service Router

OmniAccess 5710 and Omni Access 5720 Enterprise service routers are validated in the OTEC reference architecture
and provide the following use cases:

- Connect small offices to OTEC cloud through an Internet connection and IP Sec tunnel
- Connect local SIP Trunk
- Provide local survivability with or without local SIP Trunk
- Deliver fallback on 3G or 4G connectivity when fixed WAN is unavailable
- Provide fault tolerant capability thanks to redundant CPE
Please refer to 6.4 WAN Access Resiliency use cases.

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 58

3.3 Multitenancy deployment and Security
The service provider is responsible for the end to end architecture and hence is responsible securing each tenant from
the other.
The tenant is referenced as a customer instance from an end to end point of view (UC servers, network services,
Customer Premise devices).
Each tenant must be securely separated from other tenants because they share a common network pool of resources
(Firewall, Switch, Core).
Each tenant communicates with other tenants through peer public networks:

- IMS or PSTN network for telephony network

- Internet for IP network
The figure below shows the resources that are shared/dedicated to each customer instance:

The dedicated resources per company are:

- Company virtual instance machines with reserved infrastructure resources (CPU, RAM, Disk Space)
- OT SBC for remote worker usage
- Virtual Private network with dedicated Carrier Ethernet/IP-VPN/IP-Sec VPN services per customer
The shared resources are:
- The compute and storage resources
- Firewall with Virtual Domain to allow IP address overlapping
- Data Center Core switching with dedicated VLAN/VRF per customer to avoid inter instance routing and to
allow IP address overlapping
- NAS storage with dedicated storage mounting point
- Reverse Proxy (in the shared DMZ area)
- IT Servers such as DNS/NTP

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 59

3.3.1 Zoning and isolation
Securing the OTEC infrastructure means:
1. Isolate the customer data networks
2. Isolate the management network
3. Secure the customer access to cloud-based resources
4. Secure external access to prevent denial of service (DoS) attacks
From a service provider point of view the recommended reference security architecture is as follow:

3BL75230AAAAUAZZA Copyright © 2022 ALE International. All rights reserved. Page 60