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 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:
Alarm. See "Managing SNMP Events".
Transfer. See "Configuring Transfer".
Telemetry. See "Managing Telemetry".
Tracing. See "Managing Tracing".
Conference. See "Managing the Conference Feature".
Charging. See "Enabling Charging in the Runtime Domains".
Statistics. See "OCECAS Statistics and System Administration".
Configuring transfer consists of configuration options related to transfers between circuit-switched and packet-switched networks. The transfer configuration options are divided into groups and described in the following topics:
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 acts as a Service Centralization and Continuity Application Server (SCC AS) and communicates with a Home Subscriber Server (HSS) using Diameter Sh, and with Call State Call Function (I-CSCF) and Serving Call Session Control Function (S-CSCF) using SIP. For more information, see "About OCECAS Services" in Oracle Communications Evolved Communications Application Server Concepts.
OCECAS determines whether SRVCC-specific processing is allowed for a domain based on whether SRVCC is enabled or disabled for that domain. You can enable or disable support for SRVCC for each domain through the Enable SRVCC configuration setting.
It is possible to enable SRVCC in some domains and not enable it in others. For example, you may have disabled SRVCC in all of your domains and subsequently decide to enable it on a test system. In this 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 or processed by OCECAS. If a user end point 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
The address that the ATCF should use when sending an access transfer request to OCECAS. OCECAS provides the ATU STI URI to the ATCF upon processing a successful user equipment (UE) registration.
Transfer Timeout
The transfer timeout milliseconds when OCECAS (acting as the SCC-AS) processes an SRVCC Access Transfer Request.
CS Routing Method
Select CSRN, MSRN, or Prefix from the drop-down menu. Choosing Prefix requires you to enter a CS Routing Prefix.
The CS routing method determines how OCECAS forms the number that is used to terminate a call in the circuit-switched domain. If you select CSRN, OCECAS uses the CS Routing Number retrieved from the subscriber profile in the HSS. If you select MSRN, OCECAS makes a Send Routing Info (SRI) request to HLR using OCCAS-SC. If neither of these options are available, you should select Prefix.
CS Routing Prefix
The routing prefix number to use when Prefix has been selected as the CS Routing Method. The prefix is added to the destination number when T-ADS terminates to a circuit-switched network. The prefix enables the network to route the termination accordingly. You must specify the digit sequence to use for the prefix.
Deployment Mode
Specifies whether the deployment is for VoLTE, VoWiFi, or both (VoLTE+VoWiFi). This affects the way T-ADS selects the terminating domain for a UE that is registered in the IMS with no active call.
If a UE can be registered in the IMS only by way of LTE, Oracle recommends that you set the deployment mode to VoLTE to optimise T-ADS. If a UE can be registered in the IMS only by way of WiFi, Oracle recommends that you set the deployment mode to VoWiFi to optimise T-ADS. Otherwise, Oracle recommends that you set the deployment mode to VoLTE+VoWiFi.
In VoLTE mode, T-ADS queries the HSS for the Voice_over_PS-Supported_Indication, which is stored in the /UserData/HSS/TADS-Information/IMS-Voice-Over-PS-Session-Support external concept. If HSS returns "not supported", then the call is terminated to the circuit-switched domain. In VoWiFi mode, the call will always be terminated as if in IMS, as there is no packet-switched domain. In VoLTE+VoWiFi mode, T-ADS checks the P-Access-Network-Info header, which is stored in the /CacheData/RegisteredAccessNetworkInfo external concept that is associated with the registration. If it indicates WiFi access, the HSS query for Voice_over_PS-Supported_Indication is omitted, and the call is terminated as if in IMS. In addition, if a termination of WiFi-access returns 408, T-ADS attempts to terminate the call to circuit-switched domain.
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 Transfer.
Provide the configuration settings. See "SRVCC Configuration Settings".
Click Save.
Inter-UE transfer refers to transferring a call from one registered device to another when a subscriber has registered multiple devices. OCECAS allows Inter-UE transfer to be enabled or disabled in configuration and requires the provisioning of a URI to be used in Inter-UE transfer requests.
The configuration settings for Inter-UE transfer are:
Enable Inter-UE Transfer
Specifies whether inter-UE transfers are enabled on the platform.
Inter-UE Transfer SCC AS URI
The SIP URI, which is a public service identity hosted by OCECAS, that is used in inter-UE transfer procedures. This is a public service identity that is hosted by OCECAS.
To configure inter-UE transfer 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 Transfer.
Provide the configuration settings for the Inter-UE Transfer section. See "Inter-UE Transfer Configuration Settings".
Click Save.
Configuring OCECAS for an MSC that is not enhanced for IMS Centralized Services (ICS) requires an understanding of important aspects of circuit switched user endpoint origination and termination.
For an overview of OCECAS service centralization, see "About Service Centralization" in Oracle Communications Evolved Communications Application Server Concepts.
The GSMA IR.64 specification describes how the CAMEL protocol is used in origination to allow the Service Control Point (SCP) to redirect a call from the MSC into the IMS by way of the Media Gateway Control Function (MGCF) using an IMS Routing Number (IMRN). On receipt of the originating call, the MGCF initiates a SIP INVITE message to the IM CN subsystem, which sends the request to OCECAS as the SCC-AS.
Because OCECAS cannot rely on the SIP INVITE containing the original called and calling party numbers, the SCP must make those numbers available to OCECAS upon receiving an INVITE based on an IMRN.
OCECAS does not support CAMEL, so you must configure OCCAS - Service Controller (OCCAS-SC) to orchestrate between CAMEL and SIP so that it sends a SIP INVITE to the IMS when it receives an InitialDP message from the MSC.
OCECAS determines that the SIP INVITE resulted from originating triggers in the MSC, generates an IMRN and returns it in a SIP 302 Moved Temporarily response to OCCAS-SC. OCECAS then stores the call for later retrieval using the IMRN.
OCCAS-SC sends a CAP Connect message to the MSC containing the IMRN. If the operator has configured the network in OCECAS to direct calls addressed to the IMRN range into the IMS, this will force all subsequent call signalling to be sent to the IMS.
The MSC performs ISUP signalling to the MGCF using the IMRN instead of the original called-party number. The MGCF sends a SIP INVITE to the IMS containing the IMRN and SDP for media anchored at MGW. When OCECAS receives the request, it uses the IMRN to retrieve the original call information and construct a SIP INVITE. At this point, OCECAS begins to act as a back-to-back user agent (B2BUA).
Terminating calls received by the gateway MSC must be handled in a similar way to anchor the call in the IMS:
On receipt of ISUP IAM, the G-MSC sends MAP-SRI to the HLR for the called party.
The HLR returns the address of OCCAS-SC and the service key for the terminating service.
G-MSC sends InitialDP to the returned SCP address (OCCAS-SC).
OCCAS-SC sends a SIP INVITE message to OCECAS.
OCECAS matches the service key from the SIP Header to the configured terminating service-key.
OCECAS generates an IMRN and adds it as a secondary key to the current SIP Application Session.
OCECAS returns SIP 302 to OCCAS-SC containing the IMRN in Contact SIP header.
OCCAS-SC sends CAP Connect to G-MSC with a destination Routing Address containing the IMRN.
MSC sends ISUP IAM (IMRN) to MGCF.
MGCF sends a SIP INVITE (IMRN) to I-CSCF.
I-CSCF sends a SIP INVITE (IMRN) to OCECAS.
OCECAS uses the IMRN as a key to retrieve the original SIP Application Session containing the called and calling party numbers.
OCECAS sends a SIP INVITE (CdPn) to S-CSCF.
S-CSCF sends SIP INVITE (CdPn) to OCECAS.
OCECAS performs Terminating Supplementary Services and then Terminating Access Domain Selection (T-ADS).
To ensure that OCCAS-SC is triggered for call attempts, you must provision a subscriber's originating and terminating CAMEL Subscription Information (O-CSI and T-CSI respectively) with a unique service key, and the address of OCCAS-SC as gsmSCF. O-CSI and T-CSI require unique service-keys to allow OCECAS to differentiate originating and terminating triggers. You configure the provisioned service-keys in the Administration Console. For more information, see "Anchor Mode" and "Configuration Settings for MSC Not Enhanced for ICS".
OCECAS generates a unique IMRN upon receiving a SIP INVITE due to an IMRN Request from OCCAS-SC. OCECAS uses the IMRN as a key to store the call details for later retrieval when it receives a SIP INVITE due to IMRN Request from MGCF.
An individual IMRN must not be re-allocated for at least the maximum period of time that may elapse between receiving the IMRN request SIP INVITE and the subsequent INVITE addressed to the IMRN. Otherwise OCECAS will not be able to retrieve the original call details.
OCECAS creates an IMRN in the following manner:
Carrier Code + Node ID + Call ID
These elements have the following characteristics:
Carrier code is 1-3 digits in length.
Node ID is 1-4 digits in length. You must allocate a range of Node IDS for OCECAS to use for IMRNs. OCECAS allocates a Node ID to each engine. If you are using Network Function Virtualization, the range must allow for additional engines that could be allocated through that mechanism.
Call ID is a minimum of 2 digits and a maximum of 8 digits.
OCECAS logs an alarm if it cannot allocate a Node ID to an engine. In this case, the engine returns an error response to any SIP INVITE that is due to an IMRN request.
Anchoring a call in the IMS when the call originates in a circuit-switched network and the called party is also in a circuit-switched network is inefficient. Preventing such calls from anchoring in the IMS can reduce the load on the IMS and services for such calls should be provisioned in the circuit-switched network.
OCECAS provides the Anchor Mode configuration setting in the Administration Console to allow you to choose whether calls should be routed to the IMS or handled in the circuit-switched network. Anchor Mode provides the following choices:
Anchor all calls in the IMS
Option A: Do not route MO (originating) calls from PSTN/CS
Option A+B: Do not route MO or MT (originating or terminating) calls from PSTN/CS to the IMS.
Option A requires that the HLR is configured to trigger OCECAS, through OCCAS-SC, upon the originating call attempt. Option A+B requires that the HLR is configured to trigger OCECAS, through OCCAS-SC, upon the terminating call attempt. Note that these are also requirements for supporting IMRN generation.
In the case of either Option A or Option A+B, OCECAS will not generate an IMRN upon receipt of either an originating or terminating SIP INVITE message from OCCAS-SC. Instead, it returns a SIP 302 status and leaves the called party's number unmodified.
The configuration settings for an MSC Not Enhanced for ICS are:
IMRN Carrier Code
The carrier code used in all generated IMRNs. The carrier code is 1-3 digits long. For additional information, see "IMRN Generation".
IMRN Node ID Range
Specifies the range of Node IDs that OCECAS can use in generated IMRNs, for example 0700-0790. A Node ID is 1-4 digits long. Default is 1000-2000. For additional information, see "IMRN Generation".
IMRN Call ID Range
Specifies the range of Call IDs allowed in IMRNs generated by OCECAS. A call ID is 1 to 8 digits in length, so the valid range is 1 - 99999999. For additional information, see "IMRN Generation".
IMRN Validity Period
Specifies the length of time in milliseconds that an OCECAS-generated IP Multimedia Routing Number (IMRN) will remain valid. If a call for the IMRN is received after the period expires, the original call information might not be available and OCECAS will drop the call because it will be unable to direct the call to the original called party. For additional information, see "IMRN Generation".
IMRN MO Service Key
An integer that specifies the MO service key that is expected to be configured in the Originating CAMEL Subscription Information (O-CSI) for a subscriber. OCECAS treats an initial SIP INVITE as a request for an IMRN if the request contains the SIP header X-WCS-Service-Key. Single digit value. Default is 1.
IMRN MT Service Key
An integer that specifies the MT service key that is expected to be configured in the Terminating CAMEL Subscription Information (T-CSI) for a subscriber. OCECAS treats an initial SIP INVITE as a request for an IMRN if the request contains the SIP header X-WCS-Service-Key. Single digit value. Default is 2.
Anchor Mode
Indicates the deployment mode for T-ADS. Allows control of the service domain selection for calls using circuit-switched access. Select Anchor all calls in IMS to route all calls to IMS. Select Option A to not route originating calls to the IMS from a caller camping in a circuit-switched network. Select Option A+B to not route originating or terminating calls to the IMS from a caller camping in a circuit-switched network. For additional information, see "Anchor Mode".
To configure an MSC that is not enhanced for ICS:
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 Transfer.
Provide the configuration settings for the MSC Not Enhanced for ICS section. See "Configuration Settings for MSC Not Enhanced for ICS".
Click Save.
Table 4-3 lists the external concepts are made available for MSC Not Enhanced for ICS:
Table 4-3 External Concepts for MSC Not Enhanced for ICS
| ContextKey | Description |
|---|---|
|
/Chassis/IMRN-Node-ID |
The unique IMRN Node ID allocated to the OCECAS engine. |
|
/Chassis/IMRN |
Unique IMRN allocated to the call. |
|
/Config/Transfer/ImrnValidityPeriod |
Contains the validity period retrieved from configuration |
|
/Config/Transfer/ImrnCarrierCode |
Contains the carrier code retrieved from configuration. |
|
/Config/Transfer/ImrnMoServiceKey |
Contains the IMRN MO service key retrieved from configuration. |
|
/Config/Transfer/ImrnMtServiceKey |
Contains the IMRN MT service key retrieved from configuration |
|
/Config/Transfer/ImrnNodeIdRangeLowerBound |
Contains the lower boundary IMRN Node ID of the IMRN Node ID range retrieved from configuration. |
|
/Config/Transfer/ImrnNodeIdRangeUpperBound |
Contains the upper boundary IMRN Node ID of the IMRN Node ID range retrieved from configuration. |
|
/Config/Transfer/ImrnCallIdRangeLowerBound |
Contains the lower boundary IMRN Call ID of the IMRN Call ID range retrieved from configuration. |
|
/Config/Transfer/ImrnCallIdRangeUpperBound |
Contains the upper boundary IMRN Call ID of the IMRN Call ID range retrieved from configuration. |
Table 4-4 lists external concepts that refer to information that is retrieved from the SIP INVITE that triggered creation of the IMRN. These concepts are valid in the session that triggers the creation of an IMRN for the duration of the IMRN Validity Period. You can are also access them using the Remote Copy activity from the follow-on originating SIP INVITE from MGCF.
External concepts beginning with x-wcs are documented in the OCCAS-SC documentation. For more information, see "Developing a SIP Call Control Application" in Oracle Communications Service Broker SIP Developer's Guide for GSM.
Table 4-4 External Concepts for Information from the SIP INVITE that Triggered IMRN
| Context Key |
|---|
|
/ServiceLoader/IMRN-Request/Header/Diversion |
|
/ServiceLoader/IMRN-Request/Header/P-Access-Network-Info |
|
/ServiceLoader/IMRN-Request/Header/P-Asserted-Identity/Key |
|
/ServiceLoader/IMRN-Request/Header/P-Asserted-Identity/Uri |
|
/ServiceLoader/IMRN-Request/Header/P-Asserted-Identity/User |
|
/ServiceLoader/IMRN-Request/Header/P-Asserted-Identity/Domain |
|
/ServiceLoader/IMRN-Request/Header/Privacy |
|
/ServiceLoader/IMRN-Request/Header/Request-URI/Domain |
|
/ServiceLoader/IMRN-Request/Header/Request-URI/Uri |
|
/ServiceLoader/IMRN-Request/Header/Request-URI/User |
|
/ServiceLoader/IMRN-Request/Header/Request-URI/Key |
|
/ServiceLoader/IMRN-Request/Header/x-wcs-mobile-number |
|
/ServiceLoader/IMRN-Request/Header/x-wcs-msc-address |
|
/ServiceLoader/IMRN-Request/Header/x-wcs-network-name |
|
/ServiceLoader/IMRN-Request/Header/x-wcs-service-key |
|
/ServiceLoader/IMRN-Request/Header/x-wcs-session-case |
Supplementary services can be provided by MSC or IMS, depending on the access method and configuration. For example, the Anchor Mode setting can prevent calls from being anchored in the IMS and force their supplementary services to be provided in the circuit-switched network. Consequently, service data held in the HLR and HSS must be synchronized to ensure a consistent user experience, regardless of access method.
Synchronization of service data between the HLR and HSS is accomplished as follows:
An update to supplementary service data in the HLR triggers a MAP-NOTE-SUBSCRIBER-DATA-MODIFIED message to notify OCCAS-SC of the change. OCCAS-SC forwards the information to OCECAS in a SIP SUBSCRIBE message and OCECAS updates the supplementary service data held in HSS transparent data. OCECAS then returns a SIP NOTIFY message to OCCAS-SC.
Note:
You must provision the HLR to ensure that changes to Supplementary Service data are sent in MAP-NOTE-SUBSCRIBER-DATA-MODIFIED messages to OCCAS-SC.An update to supplementary service data in the HSS is performed through the OCECAS XCAP interface. On receipt of a change, OCECAS sends a MAP-ANYTIME-MODIFICATION in a SIP SUBSCRIBE message to OCCAS-SC, which forwards the request to the HLR. OCCAS-SC returns a SIP NOTIFY message.
OCCAS-SC is configured with the IMPSX plugin to support these cases.
The configuration settings for IMS Centralized Services are:
Enable HSS-HLR Synchronization
Specifies that HSS-HLR synchronization is enabled in the deployment of OCCAS-SC and OCECAS and that synchronization should occur as required.
Subscriber Data Update AS URI
If the deployment of OCCAS-SC and OCECAS supports HSS-HLR synchronization, you must configure OCECAS with a URI to which OCCAS-SC will forward subscriber updates received from the HLR. OCECAS treats updates addressed to this URI as subscriber data updates.
S-CSCF URI
Specifies the URI to use when forwarding a request received from an I-CSCF to a S-CSCF.
OCCAS-SC URI
You must assign a URI to OCCAS-SC and configure it in OCECAS. If HSS-HLR synchronization is enabled, OCECAS pushes this URI into the Route header when it sends to OCCAS-SC a SIP SUBSCRIBE message that contains subscriber data updates for the HLR.
OCCAS-SC-TCAP URI
The OCCAS-SC-TCAP URI item must be configured with the URI that OCCAS-SC associates with the instance of the IM-PSX plugin that will handle XER-encoded TCAP/MAP requests from OCECAS. If HSS-HLR synchronization is enabled, OCECAS uses this as the Request-URI when it sends to OCCAS-SC a SIP SUBSCRIBE message that contains subscriber data updates for the HLR.
GSM SCF Address
You must specify the GSM Service Control Function (SCF) address that is included in outbound XER-encoded Map requests to OCCAS-SC. If HSS-HLR synchronization is enabled, OCECAS sends an XER-encoded MAP Any Time Modification request to OCCAS-SC to forward to the HLR upon receipt of an XCAP profile update. The GSM SCF Address is included in the MAP ATM message.
To configure IMS Centralized Services 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 Transfer.
Provide the configuration settings for the IMS Centralized Services section. See "IMS Centralized Services Configuration Settings".
Click Save.
The Web Service MAP_ATM templates shown in Table 4-5 are used when OCECAS updates the HLR through OCCAS-SC with supplementary service data changes. They contain XER-encoded MAP AnyTimeModification requests that are tailored to the update required.The MAP_SDMN template is used to generate a MAP NoteSubscriberDataModified response to return to OCCAS-SC when OCECAS receives a notification that data has changed in the HLR.
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-6 lists the configuration settings to configure tracing in the Administration Console for the specific runtime domains.
Table 4-6 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-6.
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.
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.
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 Operator's Guide.
SIP chaining is a standards-based mechanism that enables OCECAS to co-exist and interact with other SIP application servers and applications, including applications residing on different nodes. For OCECAS to co-exist with other application servers, you must specify Initial Filter Criteria (IFC) for Oracle Core Session Manager (CSM), which is the S-CSCF in the OCECAS environment, to properly route SIP traffic between application servers. For OCECAS to co-exist with other applications on OCECAS engine nodes, you must provide an OCCAS Default Application Router (DAR) configuration that invokes OCECAS and any other applications, or a custom application router.
For an understanding of SIP chaining and its implementation in OCECAS, see ”About SIP Chaining” inOracle Communications Evolved Communications Application Server Concepts.
To specify Initial Filter Criteria for Oracle Core Session Manager, refer to Oracle Communications Core Session Manager Essentials Guide. For information on Initial Filter Criteria and determining whether an application server can be invoked, refer to the 3GPP technical specification 23.218, release 12.
Note:
For OCECAS to function correctly as the SCC-AS with regard to other application servers, GSMA document IR.64 requires that OCECAS be the first application server to evaluate a UE-originating request and the last application server to evaluate a UE-terminating request.OCECAS is implemented as a SIP servlet that is deployed on Oracle Communications Converged Application Server (OCCAS), a SIP container. The SIP chaining capability provided by the OCCAS Default Application Router enables OCECAS to be chained to any other SIP servlet application. For information on how to configure the Default Application Router using the DAR JSON configuration file, as well as information on how to configure a custom application router, see "Composing SIP Applications" in the Oracle Communications Converged Application Server Developer's Guide. You can also refer to the SIP Servlet 2.0 specification (JSR-000359) for information on the application selection process, which DAR implements.
Note:
For OCECAS to function correctly as the SCC-AS with regard to other applications, GSMA document IR.64 requires that the application router configuration ensures that the OCECAS Session Control Framework SIP servlet is the first application to evaluate a UE-originating request and the last application to evaluate a UE-terminating request.The following INVITE message is a simple illustration of chaining between OCECAS, whose SIP servlet application name is oracle.occas.csp.app.scf, and a simple proxy called my.simple.proxy.
INVITE: ("oracle.occas.csp.app.scf", "DAR:From", "ORIGINATING", "", "NO_ROUTE", "0"), ("my.simple.proxy", "DAR:To", "TERMINATING", "", "NO_ROUTE", "1")
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.