differentiating volte and vowifi at internet · pdf filedifferentiating volte and vowifi at...

DIFFERENTIATING VOLTE AND VOWIFI AT INTERNET SPEED AND COST WITH THE EVOLVED COMMUNICATIONS APPLICATION SERVER

Reliable Design and Delivery of Compelling Services in a Virtualized All-IP Network

O R A C L E W H I T E P A P E R | N O V E M B E R 2 0 1 5

1 | DIFFERENTIATING VOLTE AND VOWIFI AT INTERNET SPEED AND COST WITH THE EVOLVED COMMUNICATIONS APPLICATION SERVER

Contents

Introduction 2

VoLTE and VoWiFi Business Case Overview 2

The Role of the Telecommunications Application Server 2

GSMA IMS Profile for Voice, Video and Service Continuity 3

Key Challenges Facing the Proprietary TAS 4

Differentiating Services without Costly Coding or Vendor Customization 4

Validating and Deploying New Services Quickly but Without High Cost and Risk 4

Leveraging Virtualized Deployment in a Multi-Vendor Network Environment 5

Essential TAS Characteristics to Support VoLTE and VoWiFi 6

Extendable Applications Using Drag and Drop Tools 6

Risk-free New Service Rollout Using an Automated Deployment Pipeline 9

Network Function Virtualization with Automated Orchestration 10

Oracle Communications Evolved Communications Application Server 11

Independent Innovation 11

Service Agility 12

Seamless Reliability 12

Conclusion 13


Introduction

The key business drivers for voice over LTE (VoLTE) and voice over Wi-Fi (VoWiFi) are focused on

cost optimization and customer experience enhancements - the telecommunications application server

(TAS) plays a pivotal role in both. As service providers drive towards a virtualized all-IP network, they

require the means to design and deliver compelling and differentiated VoLTE and VoWiFi services in

order to attract and retain subscribers. However, the business model requires this to be achieved with

the lowest operational cost. This whitepaper examines both the key challenges and essential TAS

characteristics to take into account when launching differentiated VoLTE and VoWiFi services at

internet speed and cost.

VoLTE and VoWiFi Business Case Overview

Many service providers have launched 4G LTE networks to satisfy the increasing data demands of connected

devices and the digital lifestyle, but by doing so have been left with the “two network problem” and the associated

operational expenditure with maintaining voice services on the legacy circuit-switched networks and data on the

packet-switched LTE networks. By launching VoLTE, service providers aim to move voice traffic from 2G/3G to 4G

networks, allowing spectrum re-farming and more data to be sold to high value subscribers. VoLTE promises to

enhance the customer experience with a plethora of enriched voice services - in crystal clear high-definition quality -

and a new era of IP-based video communications. Such evolutions are long overdue as traditional voice and SMS

services play catch-up with so-called “over the top” (OTT) services coming from the I.T world such as Apple’s

FaceTime, Skype or Google Talk. However, service providers are an advantage because they can provide a higher

guarantee of quality of service through prioritized VoLTE data packets unlike OTT services that must rely on “hit and

miss” best-efforts delivery.

The VoLTE business case is intended to provide cost-savings and enhance the customer experience. VoWiFi

extends subscriber reach and can be deployed as a stepping stone to VoLTE by fully leveraging VoLTE investment

Virtually the same network elements that are required for VoLTE are also required for VoWiFi – the same IMS-

based VoLTE services are accessed except that the Wi-Fi network is used to access the evolved packet core (EPC)

by incorporating a mobile security gateway - so the two offerings are very much complimentary. VoWiFi extends

subscriber reach and solves deep customer problems such as poor indoor network coverage or “out of service”

areas such as travel in the sky or underground on the metro. Many service providers are adopting a strategy where

VoWiFi is deployed first as a stepping stone to VoLTE rollout which can be done in a phased and less risky

approach, while at the same time fully leveraging VoLTE network investment.

The Role of the Telecommunications Application Server

The telecommunications application server (TAS) plays a pivotal role in both the cost to deploy and to differentiate

VoLTE and VoWiFi offerings – it is the entity that dictates the end customer experience by controlling value-added

multimedia services in the IP Multimedia Subsystem (IMS). It orchestrates IMS service logic such as by originating

SIP requests; by processing and impacting SIP sessions; and by also being able to send accounting information to

the online and offline charging functions.


“An application server (AS) is a network element capable of hosting and executing IP multimedia services based on

the Session Initiation Protocol (SIP) signaling. … the next-generation SCP was carried forward to embrace IP

transport and SIP signaling to support other IP-based multimedia services, notably (but not limited to) video”

DAVID SNOW

PRINCIPAL ANALYST FOR SERVICE PROVIDER INFRASTRUCTURE, CURRENT ANALYSIS

GSMA IMS Profile for Voice, Video and Service Continuity

In September 2010, the GSMA froze IR.92 – a profile for voice and SMS services over LTE. This was a major

milestone as it meant there was now a global and stabilized baseline for VoLTE deployment. As part of IR.92, the

TAS provides network control of supplementary services for both originating and terminating legs, depending on

which service is applied (see table 1), and is connected to the IMS call chain via the IMS service control (ISC)

interface. IR.94 has also become stabilized which is the profile for conversational video.

Supplementary Service 3GPP TS Description

Originating Identification

Presentation (OIP) 24.607 Service provides the terminating user with the identity of the originating user

Terminating Identification

Presentation (TIP) 24.608

Service provides the originating user with the possibility of receiving identity information

in order to identify the terminating user

Originating Identification

Restriction (OIR) 24.607

Service enables the originating user to prevent presentation of its identity information to

the terminating user

Terminating Identification

Restriction (TIR) 24.608 Service offered to the connected user which enables the connected user to prevent

presentation of the terminating identity information in order to identify the terminating user

Communication Diversion

Services (CDIV) 24.604 Service allows the user to re-direct (forward) an incoming request that fulfills certain

provisioned or configured conditions to another destination

Communication Waiting (CW) 24.610 Allows a subscribed user with an active call to be informed about an additional incoming

call

Ad-hoc conferring (AHC) 24.605 Service enables a user to participate in and control a simultaneous communication

involving a number of user

Communication Hold (CH) 24.628 Service enables a user to suspend media within a session, and resume that media at a

later moment

Communications Barring (CB) 24.611 Service allows user to selectively block session attempts such as incoming calls (when

roaming, outgoing international calls or anonymous communication restriction (ACR)

Message Waiting Indicator

(MWI) 24.606 Service enables the application server to indicate to the user that there is at least one

message waiting

Table 1. Overview of 3GPP specifications for IMS VoLTE supplementary services

In addition to IR.92 and IR.64, the GSMA IMS profile for IR.64 delivers a process called enhanced single radio voice

call continuity (eSRVCC) which transfers ongoing voice calls from the LTE to the circuit-switched domain when LTE

coverage becomes too weak. This complex transfer process requires the execution of multiple exchanges between

many network entities such as the call session control function (CSCF), home subscriber storage (HSS) and also

the service control and continuity application server (SCC-AS). The SCC-AS can be deployed as a separate entity to

the TAS, however it is often more efficient for a single AS to perform the roles of both the TAS and SCC-AS.


Key Challenges Facing the Proprietary TAS

Traditional TAS are responsible for a significant proportion of the costs required to deliver compelling VoLTE and

VoWiFi services. This section examines three key challenges that must be overcome in order to lower this cost:

» Differentiating services without costly coding or vendor customization

» Validating and deploying new services quickly but without high cost and risk

» Leveraging virtualized deployment in a multi-vendor network environment

Differentiating Services without Costly Coding or Vendor Customization

It would take many man years of time and effort for service providers to code IR.92, IR.94 and IR.64 profiles from

scratch. Consequently, a common approach from most vendors is to provide “out of the box applications” to support

these with services being hard-coded and built in accordance to the 3GPP standards. Such an approach is great to

jumpstart “vanilla” VoLTE and VoWiFi services; however the reality is that marketing will always want to offer their

customers more than a “vanilla” service in order to differentiate and add value to their service - resulting in a need

for customization. The following example using the anonymous caller restriction (ACR) service illustrates how value

can be added the standard IR.92 “barring” service:

Most people do not like to receive anonymous calls, especially when the caller is an automated computer trying to

sell a service. By subscribing to the standard IR.92 ACR service, all anonymous calls would be blocked -

unfortunately, this would also apply to legitimate people trying to call you e.g. banks, your wife from work,

businesses or even the pizza company trying to call to ask for directions. This service could be enhanced by

screening anonymous calls and rejecting automated nuisance callers through additional logic that would prompt an

anonymous caller to identify themselves via a recording, before being put on hold until the called party answers,

hears the message and then decides whether to accept the call or not.

Making the above service extensions to IR.92 to support enhanced call screening adds value and differentiates

offerings. However, the implementation is traditionally very expensive and implemented using two approaches:

1. Employ a team of highly skilled engineers to make code changes to a vendor-specific application. This

approach is complex, time consuming and prone to error.

2. The vendor is requested to make several customizations to the out of the box application. Typically

vendors make a large percentage of their revenue through such customizations and due to other customer

commitments cannot always fulfil such projects within a short timeframe.

Either approach is expensive and time consuming and can severely limit the ability to react to emerging market

opportunities.

Validating and Deploying New Services Quickly but Without High Cost and Risk

The aforementioned “service creation” challenges are only the beginning – manual and error-prone processes for

rolling out new services are the next problem. Historically, service providers have deployed multiple instances of a

TAS for testing, staging and production purposes.

» The testing TAS is where the value-added service (VAS) engineer codes up a new service and functionally

validates that it works as desired

» The staging TAS is where the service is manually deployed and where the operations team would assume

responsibility to begin their final run acceptance testing of the service


» The production TAS is where the service would be manually deployed for commercial rollout

However the real problem lies with the reliable transfer and deployment of the service between each TAS. After

taking time to code a service in testing, it is always a manual process to transfer and deploy it into the staging TAS –

this is achieved by developing a unique deployment script which is highly prone to error, takes a long time to code

and above all, is an expensive process. Likewise, when the service provider is ready to commercially launch the

service, it needs to be deployed from the staging to the production TAS and the process needs to be started all over

again. However, this step is also extremely risky, since different TAS configurations on testing, staging and

production allows the potential for errors to be found in production that did not exist in staging or testing: any outage

or negative effect on customer experience can severely jeopardize brand value and lead to churn.

Figure 1. Service providers have deployed separated TAS for testing, staging and production purposes, with manual, costly and

error-prone processes to rollout new services between each environment

Primary research conducted by Oracle with service providers indicates that this whole deployment process from

design to commercial rollout across testing, staging and production TAS can take anywhere from 3-6 months.

The consequence of this outdated deployment process is that service providers are forced to make only two or three

major launches every year. Therefore, it is generally preferred to pack more functionality into each release which

further lengthens time to market and causes an opportunity cost of having to wait six months or more to release a

new service. In order to compete with more nimble IT players, the key challenge is to be able to respond to

emerging market opportunities in a shorter time frame more closely aligned to a few weeks or days.

Leveraging Virtualized Deployment in a Multi-Vendor Network Environment

Building NFV into legacy networks or pre-existing physical networks is not an easy task. Products supporting very

low-latency, high-performance data transcoding and transport will probably remain appliance-based for several

years. The more likely candidates for NFV in the early phases of deployment will be the signalling intensive

functions, such as session core control plane activity and enhanced routing applications, signalling proxies, network

policy elements and the TAS. This makes VoLTE and VoWiFi a prime candidate for NFV.

“Many mobile operators are planning to use vIMS core for VoLTE deployment, and most of these operators will also

deploy mobile core/vEPC, which 59% of NFV respondents plan to deploy by 2016 or later.”

SDN AND NFV STRATEGIES: GLOBAL SERVICE PROVIDER SURVEY, MARCH 27, 2014

INFONETICS RESEARCH (PART OF IHS INC)


While there are many existing VoLTE TAS products that were launched around 2010 when IR.92 was stabilized, it

was not till 2012 when we started to see the introduction of NFV as a new technology. Consequently, we have been

bombarded by vendor claims of VNFs, such as the TAS, being NFV-ready. But what does it really mean to be “NFV-

ready?” NFV management and network orchestration (MANO) is what really makes NFV work, and while many

vendors have launched virtualized TAS that are supported by their own virtual network function managers (VNFMs),

what happens if a service provider has already selected a VNFM from an alternative vendor that is required to be

their single solution for orchestration across their virtualized network? What happens if a service provider has a

certain preference or limitation based on the hypervisor technology being used and therefore requires support for

OVM, whereas the “virtualized TAS” may only support KVM? The key to being “NFV-ready” is the ability to offer

flexibility and interoperability so that the diverse needs of service providers can be met without feeling pressured into

a vendor lock-in situation.

Essential TAS Characteristics to Support VoLTE and VoWiFi

The VoLTE business case is focused on cost savings and a modernized customer experience to compete with web-

based OTT offerings – speed, reliability and cost are critical factors to consider. This section examines three

essential TAS characteristics that will enable carrier-grade delivery of differentiated VoLTE and VoWiFi offerings

with internet speed and cost:

» Extendable applications using drag and drop tools

» Risk-free new service rollout using an automated deployment pipeline

» Network function virtualization with automated orchestration

Extendable Applications Using Drag and Drop Tools

Reliance on coding or vendor customization when implementing service extensions to pre-configured VoLTE

applications from vendors for IR.92, IR.94 and IR.64 is expensive and time consuming. A better approach would be

to provide the service provider with a configurable VoLTE and VoWiFi application complete with tools allowing the

logic to be configured, modified or extended without writing any code and especially without reliance on vendor

customization. In order for this to become a reality, the application would need to be built in such a way that

abstracts complexity using business-focused service logic building blocks from an extensive portfolio that would

allow a broad range of additional service logic to be created. To illustrate the use of building blocks to create service

logic, the earlier example of extending the IR.92 anonymous caller restriction (ACR) service may be built to screen

anonymous calls and reject automated nuisance callers as detailed in the key challenge section. In Figure 2, the

screenshot shows an example of how the logic for the ACR service can be extended using service building blocks.

The graphical and “business-view” of the logic, similar to a flow-chart, has been configured to prompt an

anonymous caller to identify themselves via a recording, before being put on hold till the called party answers.


Figure 2. Example of how service logic building blocks can be used to “prompt an anonymous caller to identify themselves”

In order to complete this service, figure 3 shows how additional session termination logic would be configured after

the calling party answers, that would then play back the recorded message of the anonymous caller and give the

called party the option to speak to the caller or not.


Figure 2. Example logic allows a called party to accept an anonymous call based upon hearing a recorded identification message


In fact, extending the ACR service with the additional logic shown in figures 2 and 3 is fairly complex - it involves

sophisticated usage of the back-to-back user agent, programmatic event and state processing and various

integrations with the media server (play announcement, record, collect digits etc). However, a graphical system with

an advanced drag and drop approach to service building allows engineers to “configure” and functionally validate

such logic up to four times faster than writing and maintaining code or waiting for vendor customization.

Risk-free New Service Rollout Using an Automated Deployment Pipeline

In traditional PSTN, the whole service deployment process from design to commercial rollout across separated

testing, staging and production TAS can take anything from 3-6 months. To solve this, a service engine could be

deployed as a virtual network function (VNF) that contains a single management component with runtime

environments for testing, staging and production that are interlinked but also isolated. The service engine could then

provide a single deployment view of each runtime environment and allow new projects or services to be deployed

between each using a risk free and automated process as per Figure 3.

Figure 3. A TAS with a single service engine for testing, staging and production and a single view of the runtime environments

providing new service rollout using an automated deployment process

In the example where the “anonymous caller enrichment” service was designed using drag and drop service

assembly, an “automated deployment pipeline” would allow the service to be:

» Deployed into testing with a “couple of clicks”, where functional testing would begin. Such an approach would

ensure that the testing environment configuration exactly mirrors production in order to greatly reduce the risk of

finding errors later down the line in final testing or even in production.

» Once functionally validated, deployment to staging should be as simple as a “couple of clicks”, where the

operations team would begin their final run acceptance testing.

» Then once operations are happy that the service is ready for production deployment, again it should be as simple

as a “couple of clicks” and it would be deployed into production.

Using such an automated approach efficiently shortens the validation and deployment process because a high level

of quality is built into each service right from the very beginning, where services are designed in environments that

almost identically replicate the production environment and therefore greatly reduce the likelihood of finding errors

later in the deployment process such as in final-run testing and commercial rollout. Likewise, if things were to go

wrong during commercial launch, such as changes elsewhere in the network affecting how the service behaves,


custom rollback procedures are also incredibly risky and prone to human-error – whereas the ability to instantly

“retract” a version-controlled project from production would allow the swift diagnosis and correction of any erroneous

configuration allowing the marketing launch schedule to be maintained while at the same time safeguarding the

customer experience. Furthermore, this automated process would also allow a more streamlined network operations

centre (NOC) – less people could do more in a shorter amount of time – enabling reduced time and operational cost

when rolling out new services.

Network Function Virtualization with Automated Orchestration

NFV management and network orchestration (MANO) within a multi-vendor environment is considered to be the

Holy Grail for turning the promise of NFV into reality. This means that for any VNF to be “NFV-ready” there are the

requirement to seamlessly integrate within the ETSI NFV framework and provide the following capabilities:

» Virtualized software running on any suitable hardware

» Support for multiple VMs such as OVM and KVM

» Able to be integrated with a 3rd party VNF manager or orchestrator

The above capabilities will allow service providers to realize the very purpose of NFV in moving beyond the

limitations of proprietary hardware and platform capabilities with a virtualized, multi-vendor approach that is fully

orchestrated to truly improve service agility, speed to market, and lower operational costs. For example, the

anonymous caller enrichment service which allows screening of anonymous calls by hearing an identification

message, is a great example of where orchestrated NFV would be of great value since introduction of the service

would have an instant impact on performance since the call hold time and number of interactions with the media

server will increase for every anonymous call. Correspondingly, the NFV Orchestrator (NFVO) must be able to

aggregate performance measurements from each VNF instance to monitor its utilization, and when capacity

thresholds are crossed that are assigned to Key Performance Indicators (KPIs), make automated control decisions

such as whether to elastically scale out the applicable VM instances (such as the TAS and MRF). This service agility

will allow service providers to move away from rigid network architectures designed for a few fixed services to a

flexible platform that can be programmed to address either dynamically or statically any number of current and

future services.


Oracle Communications Evolved Communications Application Server

Service providers are driving their networks toward an all-IP and virtualized state and require the means to design

and deliver compelling high definition voice, video and multimedia offers via VoLTE and VoWiFi. Oracle

Communications Evolved Communications Application Server (OCECAS) brings a sophisticated, yet easy-to-use

network service design and delivery product to satisfy that need: it works out of the box; it is NFV-enabled and

standards compliant; and it provides network-grade speed and reliability with the cost profile of an IT product.

Figure 4. Oracle Communications Evolved Communications Application Server

Independent Innovation

OCECAS enables service providers to jumpstart VoWiFi and VoLTE offerings with access to an out of the box and

standards compliant application built in accordance with IR.92, IR.64 and IR.94. However, the unique value of

OCECAS is evident with the addition of the Session Design Center, an advanced tool that can be used by service

providers to extend the out of the box application without coding or vendor customization, enabling offerings to be

differentiated from “vanilla offerings” with the lowest operational cost and fastest time to market. With the business

view of service logic, the Session Design Center allows easy extensions to the complex models of VoWiFi, VoLTE

and eSRVCC by simply dragging, dropping and connecting service logic building blocks. Service logic building

blocks, as categorized by table 3, are used to make decisions, perform and respond to actions, and to interact with

data stores and external systems via open APIs. Traditional methods of coding or relying on vendor to make such

customizations are expensive and time consuming whereas the session design center allows such logic to be

configured without coding and without error.


Building Block Category Functionality

Make new decisions Make new decisions based on date / time, prefix / geographical location, data stores, SIP

messages (headers, SDP media), session context / call state

Perform new actions

Manipulation of session state (end/forward session or participant, hold/add participant), early

media and pre-call / in-call / post call announcements, call hunting / forwarding / barring, location

services, cross session context look-up, charging trigger function, custom operations and alarms

New responses to actions Manage failure, wait for and act on event, store information for use later

Interact with new data stores Local UDR subscriber data, federated subscriber data, local service data, 3rd party systems

exposed via SOAP or JSON

Interact with other systems Media server (JSR 309), charging systems (Diameter Ro/Gy), WebRTC g/w (via SIP), messaging

g/w (via SOAP / JSON), enterprise and middleware (via SOAP, JSON, JMX, SNMP traps)

Table 3. Functions of service logic building block categories provided by the Session Design Center tool of OCECAS

Service Agility

OCECAS automates and alleviates risk when rolling out new services. The VoWiFi, VoLTE and eSRVCC

application is supplied as a single change set that can be configured, extended and deployed using version-

controlled projects into interlinked testing, staging and production environments. Furthermore, each environment

configuration is almost identical meaning that far fewer “production” errors are built into projects in testing but also

that errors and extremely unlikely to be found in production that did not exist during final run acceptance testing in

staging. A single view of these environments is provided that enables new services to be deployed [or retracted] to

each testing, staging and production environment with a few clicks using an automated and risk-free process.

The rapid growth of 4G LTE in mobile networks is exposing a real need for delivery of IMS-driven services. Oracle

Communications Evolved Communications Application Server is a good fit for VoLTE and VoWiFi, and because of

its design, it aligns nicely with the CSP’s goal of increased service agility.”

DIANE MYERS, RESEARCH DIRECTOR

INFONETICS RESEARCH, PART OF IHS INC (NYSE: IHS)

OCECAS is built from the ground-up to support virtualized deployment using productized software, deployable on

x86-based hardware, with support for OVM and KVM, as well as providing KPIs to be interrogated by any VNF

manager such as the Oracle Communications Application Orchestrator. The combination of NFV-ready capabilities

with a unique approach to new service rollout provides service providers with the full set of keys to unlock the cost

curves and speed of innovation promised by NFV while ensuring carrier-grade reliability of new service rollout.

Seamless Reliability

OCECAS provides flexible data federation designed for the stringent demands of IMS environments and is powered

by the IMS-compliant and proven Oracle Communications Converged Application Server (OCCAS). OCCAS is

deployed with the majority of IMS/SIP networks and provides unrivalled performance based on SIP Servlet, IMS,

Java EE, Diameter, Media Server Control and Web Service. OCECAS leverages all of these benefits to provide a

highly available N+M architecture with failover and overload support. It uses an Oracle Coherence Cluster to

guarantee high availability and can be deployed in a geographically redundant configuration with optional Disaster

Recovery capability. OCECAS implements Java Specification Request (JSR) 309 for standard and open media

support and has interoperability testing certification with Radisys and Dialogic. It supports open IMS core

interoperability with every major 3rd party vendor and also out of the box integration with Oracle’s IMS core, fulfilled


by the Oracle Communications Core Session Manager and the Oracle Communications Session Border Controller.

This industry-leading session delivery infrastructure reduces both the complexity and cost of deploying VoWiFi,

VoLTE and eSRVCC while ensuring seamless reliability.

Conclusion

The TAS plays a pivotal role in successfully delivering the key business and marketing drivers of cost optimization and customer

experience enhancements when launching VoLTE and VoWiFi. However, limitations of proprietary TAS are hindering the ability of

service providers to design and deliver compelling and differentiated evolved communications offers with internet speed and cost while

moving towards a virtualized all-IP network. These key challenges are caused by service creation requiring coding or vendor

customizations; validation and rollout of new services being slow and error-prone; and lack of support for virtualized deployment within a

multi-vendor environment. In order to better compete with more nimble, web-based “OTT” players, service providers require the means

to design and deliver compelling and differentiated offers via VoLTE and VoWiFi in order to attract and retain subscribers through

investment in a TAS that supports:

» Out of the box applications (IR.92, IR.64 and IR.94) that are built with extensible service logic building blocks

» Service creation and extension using drag and drop tools (no coding or reliance on vendor customization)

» Risk-free new service rollout using an automated deployment pipeline

» NFV with intelligent orchestration in a multi-vendor environment

The Oracle Communications Evolved Communications Application Server (OCECAS) has been built to exactly satisfy those needs to

enable the carrier-grade delivery of differentiated VoLTE and VoWiFi offerings with internet speed and cost. OCECAS lays the

foundation for a successful IP communications strategy that is built to support NFV, independent innovation, service agility and

seamless reliability.


Oracle Corporation, World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065, USA

Worldwide Inquiries

Phone: +1.650.506.7000

Fax: +1.650.506.7200

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0615 Differentiating VoLTE and VoWiFi with the Evolved Communications Application Server June 2015

C O N N E C T W I T H U S

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

differentiating volte and vowifi at internet · pdf filedifferentiating volte and vowifi at...

Documents