This chapter describes the configuration and management tasks specific to Oracle Communications Evolved Communications Application Server (OCECAS).
For general OCECAS administration tasks, see "Managing the Evolved Communications Application Server".
As a system administrator, you configure and manage the OCECAS nodes in the domains created by your installation.
An OCECAS implementation is made up of the management domain, runtime domains, and the optional UDR domains. Together, they comprise a deployment pipeline that you use to develop, stage, and finally deploy multimedia services for your subscribers to use. This chapter assumes that you have a production implementation.
For more information about OCECAS domains, see "About the OCECAS Domains" in Evolved Communications Application Server Installation Guide.
As a system administrator, you configure and manage the following OCECAS nodes:
Evolved Communications
The Evolved Communications node is a WebLogic Server Administration Console extension that provides access to various configuration values such as event data records (EDRs) specific to OCECAS.
Diameter
The Diameter node presents configuration settings and monitoring pages for the Diameter nodes and Diameter protocol applications used in your implementation of OCECAS.
Sip Server
The Sip Server node presents SIP Servlet container properties and other engine tier functionality. This extension also enables you to view (but not modify) SIP engines.
OCECAS provides Session Initialization Protocol (SIP) servlet support using Oracle Communications Converged Application Server (OCCAS) which itself is built upon Oracle WebLogic Server. For more information about SIP Server configuration, see the Oracle Communications Converged Application Server at
Table 4-1 lists the domains in which the OCECAS nodes reside:
As a system administrator, you manage the following elements in OCECAS:
Accounts. See "Setting Up Accounts for OCECAS".
Evolved Communications node in the management domain. See "Evolved Communications in the Management Domain".
Evolved Communications node in the runtime domains. See "Evolved Communications Node in the Runtime Domains".
Diameter Node. See "Managing the Diameter Node".
Session Design Center. See "About Managing the Session Design Center".
Media Servers. See "Managing Media Servers".
Templates. See "Managing the Templates".
OCECAS supports the following types of accounts:
Administrative accounts authorized to access the management, UDR, and each of the runtime domains.
These administrative accounts are created as post-installation tasks using the Administrator Account Screen of the Domain Configuration Wizard provided by the installation process. See the discussion on "Administrator Account Screen" in Evolved Communications Application Server Installation Guide.
Non-administrative accounts authorized to access each of the domains (optional and as required by your installation). See "Creating Non-Administrative Accounts for OCECAS Domains".
A primary account authorized to access the Session Design Center.
This account belongs to the default user group EvolvedCommunicationUsers. It is created as part of the post-installation process. See the discussion on "Creating Users for the SDC GUI" in Evolved Communications Application Server Installation Guide.
Other accounts authorized to access the Session Design Center (optional and as required by your installation)
All accounts authorized to access the Session Design Center must belong to the EvolvedCommunicationUsers group. To set up these accounts, see the discussion on "Creating Users for the SDC GUI" in Evolved Communications Application Server Installation Guide.
In some installations, access to the respective OCECAS domains could be restricted to administrative accounts only. If this is the case, ensure that the access privilege associated with the user names and passwords for the administrative accounts does not allow them to change the schema in the installed databases.
To create a non-administrative account for an OCECAS domain:
Log in to the Administration Console of the OCECAS domain with your administrator user name and password:
http://hostname:port/console
where hostname is the IP address or name of the machine that hosts the domain and port is the Administration Console access port number.
In the Domain Structure pane on the left side, click Security Realms.
The Summary of Security Realms page appears.
In the Realms table, click myRealm.
The Settings for myrealm page appears.
Click the Users and Groups tab. Then, click the Users subtab.
Click New.
The Create a New User page appears.
In the Name field, enter the user name for accessing the SDC GUI.
In the Password and Confirm Password fields, enter the password for the non-administrative user authorized to access the domain.
Click OK.
In the Users table, click the non-administrative user name that you created in step 6.
The Settings for UserName page appears.
Click the Groups tab.
In the Available pane, select the group to which this user belongs.
Click the right arrow button to move the selected group to the Chosen pane.
Click Save.
Access the Evolved Communications node in the Domain Structure of the management domain (scf_management_domain) to configure EDRs.
Important:
All changes to the EDRs should be made using the Administration Console only. Changes to EDR should not be made in csp.xml.Table 4-2 lists the settings to configure EDRs in the Administration Console for the management domain:
| Entry | Description |
|---|---|
|
Node Name |
Name of the node to be prefixed to EDR files. The EDR files use the format, Node Name_-RC.date_-time.edr Where:
An example file name with the default node name is ecas_-_1.20140616_-_0315+1200.edr |
|
EDR Directory Name |
The directory where EDR files are placed before the files are moved to the archive location. |
|
Maximum EDR file size |
The maximum size of EDR file (1 - 2097150 kilobytes). When this limit is reached, a new file is created. The default size of an EDR file is 500 kilobytes. |
|
File Close timeout |
The duration in seconds for which an EDR file is open for writing. After that duration, EDRs are written to new file. The default is 1800 Seconds. |
|
Days to keep in EDR directory |
The Number of days an EDR file is kept in the EDR directory, After that the EDR File is moved to the Archive location. The default value is 10 days. |
|
Archive directory location |
The directory location where EDR files can be archived for longer duration. |
|
Days to keep in Archive directory |
The number of days for which the EDR files are kept in the Archive directory. After this duration, the files are deleted. The default value is 0, indicating that the files are never deleted. |
|
Filter to exclude EDRs based on Data |
An EDR which meets this filtering criteria will not be written to the EDR file. The default value is empty. All EDRs are written to the file. |
|
Configuration Cache duration |
The duration (in milliseconds) for which the EDR configuration will be cached in the system. This entry makes the system efficient for getting the EDR configuration. The default value is 10000ms, indicating that the EDR configuration is cached for 10000 milliseconds. EDR configuration cache duration changes are effective when the settings are refreshed. |
Use the Administration Console to configure EDRs in the management domain, scf_management_domain.
To configure EDRs for the OCECAS management domain:
Log in to the Administration Console of the OCECAS management domain with your administrator user name and password:
http://hostname:port/console
where hostname is the IP address or name of the machine that hosts the domain and port is the Administration Console access port number.
In the Domain Structure pane on the left side, click Evolved Communications.
The Evolved Communications EDR Configuration page appears.
Configure the EDRs. For a description of the fields, see Table 4-2.
Click Save.
Use the Administration Console to configure the Evolved Communications node in each of the OCECAS runtime domains. You need to configure and manage the following:
Alarms. See "Managing Alarms".
Single Radio Voice Call Continuity (SRVCC). See "Managing Single Radio Voice Call Continuity".
Statistics. See "OCECAS Statistics and System Administration".
Telemetry. See "Managing Telemetry".
Tracing. See "Managing Tracing".
Conference. See "Managing the Conference Feature".
Charging. See "Enabling Charging in the Runtime Domains".
Single Radio Voice Call Continuity (SRVCC) is the ability to continue a call when a subscriber moves from the long-term evolution (LTE) network (packet-switched network) to a legacy circuit-switched network. Such a switch occurs because the subscriber moves out of range of the LTE network.
OCECAS provides a Service Centralization and Continuity Application Server (SCC AS) that communicates with a Home Subscriber Server (HSS) using SIP, Interrogating Call State Call Function (I-CSCF), Serving Call Session Control Function (S-CSCF). For more information, see "About SRVCC" in Evolved Communications Concepts.
You can enable or disable support for SRVCC for each domain. OCECAS determines whether SRVCC-specific processing is allowed for a domain based on whether SRVCC is enabled or disabled for that domain.
It is possible to enable SRVCC in some domains, but not enabled in others. For example, you may have disabled SRVCC in all the domains. Subsequently, you may decide to enable it on a test system. In that case SRVCC would be enabled for the testing domain, and disabled for the staging and production domains.
Note:
If SRVCC is disabled in a runtime domain, the extra SIP headers and message flows are not included by or processed by OCECAS. If a user equipment attempts to perform call transfer (through SRVCC), OCECAS will deny the request.The configuration options for SRVCC are:
Enable SRVCC
SRVCC is disabled, by default. Select Enable SRVCC to enable it.
ATU STI UrI
A URI that is submitted to the Access Transfer Control function in a SIP message when OCECAS (acting as the SCC-AS) successfully processes a user equipment (UE) registration.
Transfer Timeout
The transfer timeout milliseconds when OCECAS (acting as the SCC-AS) processes an SRVCC Access Transfer Request.
To configure SRVCC for a runtime domain:
Log in to the Administration Console of the OCECAS runtime domain with your administrator user name and password:
http://hostname:port/console
where hostname is the IP address or name of the machine that hosts the domain and port is the Administration Console access port number.
In the Domain Structure pane on the left side, click Evolved Communications.
The Evolved Communications Configuration page appears.
Click SRVCC.
Provide the configuration settings. See "SRVCC Configuration Settings".
Click Save.
OCECAS supports the gathering of statistics for particular events and enabling session designers to make decisions based on the value of the collected data. Statistics data can be gathered for events that are session-local or system-wide. OCECAS stores session-local event data within a coherence cache and records system-wide events in a database table.
An OCECAS statistic event may be one of the following:
System-defined event
System-defined events are mostly system-wide, stored in a database, and can be used to generate reports in the Session Design Center. Data associated with system-defined events is permanent and cannot be removed.
The statistics associated with system-defined events is used for license-tracking purposes, such as the maximum number of requests allowed during a specific period. Other examples of system-defined events are the number of session failures determined by a particular control flow that has a counter set up, or the number of times a particular action is performed.
User-defined event
User-defined events are related to sessions and session-local events. Such data is stored within a coherence cache. For example, your subscribers want to collect system-wide voting scores on a telemarketing event. Or, your subscribers need to perform a session-related task such as selecting a random competition winner by connecting the N-th caller.
Session designers generate and use session-related event statistics in OCECAS Session Design Center. They configure the Increment Statistic activity in a control flow to increment the session-local statistic. At a later point in the control flow, they use the resulting statistic value to configure the Statistic Branching activity to take decisions on the flow logic.
For more information about how session designers retrieve statistics in OCECAS, see the discussions on "Getting Statistics Definition" and "Getting Statistics" in Evolved Communications Application Server Operator's Guide.
For system administrators, there is no configuration task associated with the gathering of statistics in OCECAS.
Telemetry is the process by which you measure and collect data at various points in the communications flow and use them to monitor and manage the system. OCECAS records both system telemetry and statistics.
System Telemetry consists of recording and reporting on data generated during a session, with specific regard to the performance of particular subsystems, such as an action or an activity. For example, you can collect the time taken to:
Load the Bootstrap control flow logic (maximum and average).
Retrieve a UDR record (maximum and average).
Interact with a specific web service (maximum and average).
Traverse a segment of a control flow. See "Monitoring a Control Flow Segment".
You can collect the time taken to complete a section of the control flow. For example, to see how long it takes to traverse a section of a control flow, mark the start and end of the path segment. To do so, add an extra activity or set a flag on an activity or branch and specify a name for the telemetry data item. This telemetry data item is stored in service data and associated with the control flow.
At runtime, OCECAS records telemetry for the data item for all sessions using the control flow. When a session passes through the Start Recording Message activity, it records a start time. When recording activity stops or the control flow ends, it records the stop time. OCECAS then calculates the time spent traversing the segment. It stores a summary of the results in a database table and displays the summary in the control flow editor.
In OCECAS, the telemetry feature requires actions on the part of system administrators and the users of the Session Design Center. The requirements for telemetry are:
Enabling of Telemetry in each runtime domain.
Telemetry is disabled, by default. System administrators must enable telemetry in each runtime domain.
The telemetry records.
Each telemetry record provides the name (the telemetry record identifier), a value, and a path to the record. System administrators configure these telemetry record identifiers in the Evolved Communications node for the runtime domains.
Important:
Use alphanumeric characters to specify the [name] attribute of an external concept. For example, tmtryrec1, cflow343tmtryrec2 are valid names.You can use -, _, and blank (or space) character special characters in the name of an external concept. No other special character is allowed in the [name] entry.
In production mode, a telemetry record is selected and called into action for an activity within a control flow of a change set.
In order to be able to collect telemetry values for a runtime domain, the following steps must be completed for the domain:
Service designers or operators:
Determine the telemetry records they wish to use. Each telemetry record is identified by a name, for example, tmtryrec1, cflow343tmtryrec2.
Provide these telemetry record identifiers to their OCECAS system administrators. For example, tmtryrec1, cflow343tmtryrec2.
System Administrators:
Configure telemetry in the Administration Console of the runtime domains. See "Configuring Telemetry".
Service designers or operators:
Access Session Design Center.
Provide these telemetry records as additional external concepts for the Telemetry activity. For information about providing external concepts, see the discussion on "Working with External Concepts" in Evolved Communications Application Server Operator's Guide.
At this point, you have the telemetry record identifiers (in our example, tmtryrec1, cflow343tmtryrec2) provided by the service designers or operators of Session Design Center.
To configure telemetry for a runtime domain:
Log in to the Administration Console of the OCECAS runtime domain with your administrator user name and password:
http://hostname:port/console
where hostname is the IP address or name of the machine that hosts the domain and port is the Administration Console access port number.
In the Domain Structure pane on the left side, click Evolved Communications.
The Evolved Communications Configuration page appears.
Click Telemetry.
To specify that the duration time should be added to the telemetry, select the Enable Duration check box.
In the Telemetry Sections field, do one of the following.
To enable Services Gatekeeper to recognize and accept all telemetry records entered by the session designer, enter all.
To restrict Services Gatekeeper to accepting strings pre-configured in the Administration Console, enter the strings provided by the users of Session Design Center.
For example, if you entered tmtryrec1, cflow343tmtryrec2 as the telemetry record identifiers, Services Gatekeeper uses only these two types of telemetry records.
Click Save.
At this point the telemetry records are ready to be used in the runtime domain. Update the telemetry settings for the remaining runtime domains in which the telemetry records may be called in to act on a control flow.
Also, inform the respective service designers that the telemetry records (in our example, tmtryrec1, cflow343tmtryrec2) are available for use in these domains.
Operators can use tracing in OCECAS to set up and manage the tracing rules that enable them to debug sessions. They create SIP-triggered tracing rules and service triggered tracing rules.
Create rules for the tracing using the JSON format and save them. Each rule has a name that is used for verification. And a condition such as the name of the SIP request method. For example:
{
"all_644123456" :
{
"method" : "INVITE",
"P-Served-User" : ".*\\+644123456.*"
},
"og_644123456" :
{
"method" : "INVITE",
"P-Served-User" : ".*\\+644123456.*sescase=orig.*"
},
"ic_644123456" :
{
"method" : "INVITE",
"P-Served-User" : ".*\\+644123456.*sescase=term.*"
},
"644123456_to_644123457" :
{
"method" : "INVITE",
"P-Served-User" : ".*\\+644123456.*sescase=orig.*",
"To" : ".*\\+644123457.*"
}
}
During runtime when the tracing level is not OFF, OCECAS creates a trace file for all sessions that match the tracing rule. The name of the trace file contains the date and time of capture, the WebLogic node, and an ID derived from the session ID to ensure uniqueness.
For example,
/trace/sip/og_644123456/201501211456-engine1-16b8d52353239611
The path name of the file indicates it contains a SIP-triggered capture for an example rule og_644123456 made at 14:56 hours on 12th January 2015 from engine1.
Table 4-3 lists the configuration settings to configure tracing in the Administration Console for the specific runtime domains.
Table 4-3 Tracing Configurations
| Name | Description |
|---|---|
|
Tracing Level |
Specifies the level of log events that are captured in the trace file. Set the Tracing Level parameter to the desired level for the specific runtime domain. For example, if you select ERROR in a domain, the resulting trace file in that domain contains messages for critical errors only. OCECAS supports ALL, DEBUG, ERROR, INFO, OFF, TRACE, and WARN levels. By default, the tracing level is OFF. If there are no configured rules, then the level of tracing is not changed. |
|
Tracing Rule |
Specify the rules on which Tracing is based. If there are no configured rules, then the system records no trace data. |
|
Trace Directory |
The root directory for trace. Each server creates a sub directory to store trace files. |
Use the Administration Console to configure tracing for the specific runtime domains.
To configure tracing for an OCECAS runtime domain:
Log in to the Administration Console of the OCECAS runtime domain with your administrator user name and password:
http://hostname:port/console
where hostname is the IP address or name of the machine that hosts the domain and port is the Administration Console access port number.
In the Domain Structure pane on the left side, click Evolved Communications.
The Evolved Communications Configuration page appears.
Click the Tracing tab.
Configure the tracing for this domain. For a description of the fields, see Table 4-3.
Click Save.
OCECAS manages three-way sessions as defined in Section 5.3.1.3.3 of 3GPP TS 24.147.
The Administration console of each runtime domain displays the Conference Factory URI option in the Conference tab for the Evolved Communications node. You can specify the URI as a regular expression allowing a number of different URIs to be valid as a factory URI.
Use the Administration Console to configure tracing for the specific runtime domains.
To configure the conference feature for an OCECAS runtime domain:
Log in to the Administration Console of the OCECAS runtime domain with your administrator user name and password:
http://hostname:port/console
where hostname is the IP address or name of the machine that hosts the domain and port is the Administration Console access port number.
In the Domain Structure pane on the left side, click Evolved Communications.
The Evolved Communications Configuration page appears.
Click the Conference tab.
In the Conference Factory URI field, enter the URI to match the initial request URI for access to the conference creation service.
Click Save.
Charging is disabled in each of the runtime domains, by default.
To enable charging for an OCECAS runtime domain:
Log in to the Administration Console of the OCECAS runtime domain with your administrator user name and password:
http://hostname:port/console
where hostname is the IP address or name of the machine that hosts the domain and port is the Administration Console access port number.
In the Domain Structure pane on the left side, click Evolved Communications.
The Evolved Communications Configuration page appears.
Click the Charging tab.
Select the Enable Charging check box.
Click Save.
The Diameter node is available in scf_testing_domain, scf_staging_domain, and scf_production_domain, the runtime domains of OCECAS. By default, transport level security (TLS) is enabled on port 3865.
Adjust the Diameter configuration for your specific requirements, such as hosts, domains and ports.
OCECAS blocks the usage of a resource until it receives authorization for the use of that resource by the requesting party. The online charging system (OCS) performs rating and balance management and approves the authorization for the use of resources. OCECAS passes the request information to the OCS through the Diameter interface (Ro) which then reserves the resource and records the usage of the resource.
The following are not supported in this release:
Credit pooling, the ability of the server to grant the client a pool of credit from which all services draw funds several when services reserve funds against the same account
Charging for data usage
By default, the installation process ensures that the Diameter Ro and RF interfaces are appropriately configured.
You can configure, enable, and manage the Ro and Rf Diameter interfaces by configuring the virt-diameter1 node in the domain structure pane of the Administration Console for the domain.
OCECAS uses the Maximum Request Attempts entry as the number of times a request should be sent before treating the request as timed-out without an answer. By default, its value is 3.
For information see the discussion on "Working with Charging Templates" in Evolved Communications Application Server Operator's Guide.
To configure the Maximum Request Attempts for the virt-diameter1 node in an OCECAS runtime domain:
Log in to the Administration Console of the OCECAS runtime domain with your administrator user name and password:
http://hostname:port/console
where hostname is the IP address or name of the machine that hosts the domain and port is the Administration Console access port number.
In the Domain Structure pane on the left side, click Diameter.
The Diameter Configuration Summary appears.
In the Diameter Configurations table, click on virt-diameter1.
The Diameter Configuration Summary for virt-diameter1 appears.
Click the General tab.
In the Maximum Request Attempts: field, enter the number of times to try a request before treating the request as timed-out without an answer.
Click Save.
Session Design Center is deployed in the management domain. It operates as a closed site with a strict requirement that the user is authenticated and authorized. The main entry points for the website are:
login.html: The login.html provides access to the parts of the website that serve to authenticate the user.
index.html: The index.html provides access to the parts of the application to be used by the authenticated account holder.
For more information, see the discussion on "Using the Session Design Center" in Evolved Communications Application Server Services Guide.
OCECAS uses the following templates:
Session Design and Control Installation template
The Session Design and Control Installation template installs the core functionality of the Session Design Center. The installation process completes this step. It does not provide any working service.
VoLTE and voice and messaging over Wi-Fi (VoWiFi) Services template
The VoLTE and VoWiFi Services template contains all the basic elements required to run VoLTE and VoWiFi. By default, no subscriber data is provisioned.
This template contains the following:
All external concepts required by the default VoLTE, VoWiFi, and eSRVCC application. The term eSRVCC stands for enhanced Single Radio Voice Call Continuity.
The default UDR View (CSP/product/app/scf/udrview)
A default service provider. The format of the service data for this provider matches that expected by the default UDR View.
The following schema as JSON files:
chargingTemplateSchema.json
mappingSchema.json
mediaResSchema.json
mediaSvrSchema.json
parametersSchema.json
prefixTreeSchema.json
serviceDataSchema.json
templateSchema.json
udrSchema.json
Prefix Trees: The CountryCodePrefixTree.json file provides a full set of global international prefixes to ISO 3166-1 alpha-3 country codes. This file is used to obtain the country code for the called party
Mapping Files: The CountryCodeMapping.json mapping file provides a mapping between Network ID values and ISO 3166-1 alpha-3 country codes. Network ID values could be the subscribers home network ID or obtained from the P-VISITED-NETWORK-ID header value when roaming.
Media Server Configuration: Some control flows require a media server to play announcements. This template delivers initial service data that configures the various announcements along with a dummy driver template.
Update the driver template to provide the real data URL or IP address for the media server. Ensure that you have fully configured the media server.