1 About Oracle Communications Evolved Communications Application Server

This chapter provides an overview of the Oracle Communications Evolved Communications Application Server (OCECAS) product.

See "Glossary" if you are unfamiliar with the telecommunications terms or acronyms used in this document.

About OCECAS

You use OCECAS to provide SIP multimedia services to your IMS subscribers. It contains a Voice over Long Term Evolution (VoLTE) and WiFi-based VOIP (VoWiFi) application that you can modify and expand to define the services that you offer to your subscribers.

The integrated suite of features, includes:

  • Voice call continuity. This feature ensures that a multimedia phone call can continue when a subscriber moves between LTE and 3G/2G coverage. OCECAS offers single radio voice call continuity (SRVCC) functionality.

  • Service centralization and continuity. This feature ensures that a multimedia phone call transitions smoothly from packet-switched equipment to circuit-switched equipment. OCECAS acts as a service centralization and continuity server (SCC-AS) that facilitates single radio voice call continuity (SRVCC).

  • Supplementary services. These features provide out-of-the-box, standards-compliant, integrated, multimedia application services for subscribers to use in multimedia calls. They include capabilities such as Communication Forwarding, Barring, Hold, Identification, and Ad-hoc Conferencing.

  • An easy-to-use GUI interface named Session Design Center. You use Session Design Center to modify SIP call behavior and application service (session control) logic. Session Design Center provides you with graphical (drag and drop) control over the workflow from creation through to testing, staging, and ultimately production.

  • Powerful change management. OCECAS uses a powerful, scalable, flexible, and secure architecture pre configured to package multiple service changes into a single unit that is easy to manage. This functionality includes the production pipeline, a fine-grained, flexible architecture that you use to develop, test, and finally deploy multimedia services to your subscribers.

  • A back-to-back user agent (B2BUA) capability. This feature enables OCECAS to control a SIP call from both the originating and terminating ends.

  • Fine-grained authorization of user actions through Oracle Platform Security Services, which provides security to Oracle Fusion Middleware including WebLogic Server.

Figure 1-1 shows an overview of the OCECAS architecture and how it fits into your network. OCECAS includes the VoLTE and VoWiFi Application, the Session Design Center GUI, Supplementary services, and provides enhanced single radio voice call continuity (eSRVCC) functionality. OCECAS connects to your charging system, 3rd party services, your subscriber database, and Oracle Communications Core Session Manager/Session Border Controller. Session Border Controller interfaces with the rest of your IMS core.

Figure 1-1 OCECAS Network Architecture

Description of Figure 1-1 follows
Description of ''Figure 1-1 OCECAS Network Architecture''

For additional information about OCECAS services, see "About OCECAS Services".

About Service Control Continuity and Voice Call Continuity

This feature enables a subscriber call to continue uninterrupted when it moves from a part of your network serviced by VoLTE packet-switched equipment to a part of your network serviced by legacy circuit-switched equipment with no call degradation.

OCECAS functions as an SCC-AS to provide SRVCC capability. The SRVCC capability is a VoLTE/VoWiFi functionality that allows IMS networks to transition a voice call from the VoIP/IMS packet-switched domain to a circuit-switched domain. OCECAS uses the Session Border Controller and Core Session Manager software products to provide the signaling controller (Access Transfer Control Function or ATCF) and media anchor point (Access Transfer Gateway, or ATGW) capabilities required for SRVCC capability.

About the VoLTE and VoWiFi Functionality

OCECAS implements the IR.92 IMS Profile for Voice and SMS specification for multimedia calls. This specification lists the set of 3GPP multimedia features that a wireless device and network must implement. Implementing this specification guarantees that your customers can use an interoperable, high-quality IMS-based telephony service over Long Term Evolution (LTE) radio access. The IR.92 specification defines the required features as supplementary services.

About XCAP and the Supported Supplementary Services

OCECAS includes supplementary services that allow you to provide multimedia capabilities that your subscribers expect. OCECAS includes the supplementary services listed in "About Using VoLTE Supplementary Services".

OCECAS supports configuration of supplementary services from the subscriber's device (or user equipment (UE)), using the XML configuration access protocol (XCAP). The UE generates the configuration query or request, which is sent over HTTP/1.1 to OCECAS, which processes the request. The URI indicates the document or part of the document to be accessed. The HTTP requests trigger control flows to process requests, allowing designers to take alternate actions based on exchanged data. See "About Applications" for a description of the HTTP control flows.

For a description of the XCAP communication flow, see Figure 6-1 in "About the OCECAS Environment" and "Understanding How OCECAS Communicates".

About the Session Design Center UI

OCECAS includes the VoLTE and VoWiFi multimedia application that you modify to provide services for your subscribers. This application uses the session initiation protocol (SIP) signaling protocol to determine multimedia call behavior.

You use the Session Design Center UI to create the SIP session logic for calls, and to add functionality in the form of subscriber services. This UI is designed so that service designers no longer need the complex coding knowledge to create and change SIP applications. Staff familiar with your IMS network can rapidly and easily create new call flows with decision forks based on subscriber profiles. You set up the session logic based on subscriber information and input. For example, you could set up a different session logic (call experience) based on:

  • The current account state.

  • UDR information, such as the account location.

  • SIP Session information, such as information from a SIP message header.

  • External factors, such as time-of-day or date.

  • A response from an external system (such as the results of a web service query).

Session Design Center is a service assembly environment (SAE). The sessions take the form of a flowchart of decisions and activities.

The Session Design Center offers these features:

  • The Control Flow Editor, an intuitive and powerful GUI-oriented drag-and-drop environment for controlling sessions. You can build flows to manage your sessions from start to finish. You use this tool to identify key resources, create triggering criteria to use in session logic, and create hierarchical component services.

  • Powerful change management features that allow you to deploy new services and features to your production pipeline. You can deploy changes to the testing, staging, and production environments with a simple drag-and-drop action. If the changes are no longer required, you remove them just as easily.

  • Resource management. You can reference announcements, create white and black lists of resources, and create templates for notifications and web services.

  • A Deployment view that you use to manage changes across a pipeline of multiple environments, such as Testing, Staging, and Production.

Figure 1-2 shows how Session Design Center works with your subscriber database to apply supplementary services to a multimedia call. You first use the Session Design Center to create session logic. Then when a call requires a supplementary service, it automatically selects the session logic based on the subscriber characteristics you specify. The session logic then specifies the supplementary service to use.

Figure 1-2 OCECAS Session Logic and Multimedia Features

Description of Figure 1-2 follows
Description of ''Figure 1-2 OCECAS Session Logic and Multimedia Features''

About Change Management and the Production Pipeline

OCECAS provides you with a low-risk, solid, predictable service and change deployment structure to control changes to your implementation. The production pipeline itself uses these stages:

  • A testing environment that you use to develop and test services.

  • A pre-release (staging) environment that you use to validate services.

  • A production environment that your subscribers use to access your services.

The change management platform enables you to combine features into a single entity called a change set. Change sets can include changes to control flows, announcements, number sets, configuration data, and so on. Change sets do not contain any data external to OCECAS, and do not contain any subscriber data.

After you create a change set, you deploy, roll back, or delete all of the changes it contains with a single action. A change set could define a subscriber service, configuration changes, or other modifications that you manage as a single unit. Using this system, you can:

  • Design new services (or modify existing services) as a collection of related changes to different entities.

  • Test a group of changes as a single entity.

  • Quickly and easily migrate the service, configuration changes, or other changes from your development system to your staging system, and then to your production system.

  • Roll back the set of related changes with a single action.

  • See a complete history of a set of related changes. The history is often useful for auditing.

Figure 1-3 shows an overview of the OCECAS production pipeline that you use for change management. The OCECAS Management System at the top contains a system with a special Oracle Fusion Middleware WebLogic domain. This is a special domain that you use to manage the other OCECAS domains. You push configuration changes from the Management System to the systems in your production pipeline.

The lower part of the diagram shows the production pipeline with its series of three OCECAS systems. Each of the systems runs on its own WebLogic machine. The machines could be real or virtual. The system on the left is a testing system for creating new services. The middle system is for staging (verification) services. And finally, the system on the right is the production system where your subscribers can access your services. The arrows show change sets moving from the testing system to the staging system, and finally to the production system. The arrows represent new session behavior or products that you test, then stage, and then finally offer to your subscribers.

All three systems include WebLogic domains, coherence clusters, OCECAS session information, and internal user data repository (UDR) databases. The UDRs in this diagram are internal databases required for OCECAS data. You can locate this domain inside runtime domains (as shown in Testing and Staging), or use a dedicated UDR domain to store it (as shown in Production). This internal UDR is different from the home subscriber server (HSS) that you use to store subscriber information. However, connections to the internal UDR and to your external HSS are defined in the same file. The connection to your HSS is not shown in this diagram.

Each The production system is shown using two clustered machines to take advantage of the OCECAS high availability features.

Figure 1-3 Evolved Communications Application Server Change Management Architecture

Description of Figure 1-3 follows
Description of ''Figure 1-3 Evolved Communications Application Server Change Management Architecture''

Note:

A user with access to the Session Design Center UI also has permission to make pipeline changes. So only give the Session Design Center credentials to trusted personnel.

About SIP Call Control (Back-to-Back User Agent)

The OCECAS server includes a SIP back-to-back user agent (B2BUA), which means it sets up and controls a SIP call from both the originating and terminating ends. OCECAS controls the entire call in two different portions, and allows you to add value-added services to one or both of the call portions. For example, you can:

  • Add new legs to a conference call

  • Redirect the call to a different endpoint

  • Charge for the call, using on-going session authorization (time-based) or by individual service (service-based)

  • Add any interaction involving media servers, such as announcements

  • Perform call hunting

  • Perform or change call failure handling

  • Perform basic location and mobile state session control

See "About Back-to-Back User Agent" for details about the default back-to-back user agent capabilities.

About SIP Chaining

SIP chaining is a standards-based mechanism that enables OCECAS to co-exist with other SIP servlets, application servers, and applications, including applications that reside on different nodes.These other application servers and applications can often perform specialized tasks.

About SIP Chaining with Other Application Servers

When OCECAS is deployed with other application servers, the Serving Call Session Control Function (S-CSCF) is responsible for routing traffic between them. In the OCECAS environment, Oracle's Control Session Manager (CSM) is the S-CSCF.

IMS application servers receive SIP traffic by way of the S-CSCF based on Initial Filter Criteria (IFC) that is defined in the Application Server Subscription Information for the user being served. When the S-CSCF receives a SIP message, it requests the relevant IFCs from the HSS, examines them and, when a match is found, forwards the message to the specified application server. Application servers such as OCECAS, therefore, can be chained together through IFCs under the control of the S-CSCF. For information on the criteria that determines whether an application server can be invoked, refer to the 3GPP technical specification 23.218, version 12.3.0 specification, available from the ”3GPP Specification detail” web site.

You must define IFCs to ensure that OCECAS receives SIP signalling from user endpoints (UEs) and third-party REGISTER requests for registration, re-registration, and de-registration. OCECAS must be informed of all such requests to maintain the registration expiry timestamp information that is held in the subscriber data store.

For information on specifying Initial Filter Criteria for OCECAS to co-exist with other application servers, see ”About Configuring SIP Chaining” in Oracle Communications Evolved Communications Application Server System Administrator's Guide.

About SIP Chaining with Other Applications

When other applications are deployed on the OCECAS engine nodes, the OCCAS Default Application Router is responsible for routing the SIP traffic between them.

When OCCAS receives an initial SIP request from an external entity, it invokes the application selection process as specified by the SIP Servlet 2.0 specification (JSR-000359) to select the first application to service the request. If the first application proxies the request or acts as a B2BUA and sends a new initial request, OCCAS again invokes the application selection process to invoke the next application. As applications proxy or send requests, they create a chain of applications that ends when an application acts as a user agent server (UAS) or when the request is sent to an external SIP entity.

OCCAS provides a Default Application Router (DAR) that acts as the SIP Application Router to implement the application selection process. The DAR is not configured in the default OCECAS installation. Instead, the OCECAS Session Control Framework SIP servlet is specified as the default SIP servlet to cause all traffic to be directed to OCECAS. To enable OCECAS to interface with other applications, you must modify the OCCAS SIP server configuration, after installation, to provide a DAR configuration that invokes OCECAS and any other applications, or a custom application router.

For information on specifying DAR configuration for OCECAS to co-exist with other applications, see ”About Configuring SIP Chaining” in Oracle Communications Evolved Communications Application Server System Administrator's Guide.

About Oracle Platform Security Services

OCECAS supports fine-grained authorization of user actions through the assignment of roles, which have associated permissions. OCECAS uses the underlying Oracle Platform Security Services (OPSS) framework to implement the authorization of user actions. OPSS provides security to Oracle Fusion Middleware, including WebLogic Server.

You initialize the OPSS repository during installation of OCECAS. For information on OCECAS application roles, see "Implementing Authorization and Permissions" in Oracle Communications Evolved Communications Application Server Security Guide.