BSCS iX for du
CCRM - Call Cleaner and Recovery Manager
Product Documentation
Copyright
© Ericsson Telekommunikation GmbH & Co. KG. All rights reserved. No part of
this document may be reproduced in any form without the written permission of
the copyright owner.
Disclaimer
The contents of this document are subject to revision without notice due to con-
tinued progress in methodology, design and manufacturing. Ericsson shall have
no liability for any error or damage of any kind resulting from the use of this
document.
2012-02-11
BSCS iX for du > Area: Online Charging > CCRM - Call Cleaner and Recovery Manager
Change History
Change History
Type Number Date Description
defect 357637 22.11.2010 CCRM: Added information about replication to standby (on page 6)
defect 317513 24.11.2008 CCRM: Added information about value of -u parameter (on page 9)
defect 294533 21.09.2007 CCRM: Timeout for call cleaning must be configured in DXL_PRO-
CESS.TRANACTION_TIME_LIMIT (on page 6, 11)
2012-02-11 3
Icons used in the Documentation
Tip: Provides alternative ways of achieving the same goal or of facilitating your
work.
Important: Provides information that is crucial to the completion of a task.
Caution: Warns you that a certain action (or lack thereof) can result in the loss
of data or in damage to the system.
2012-02-11
BSCS iX for du > Area: Online Charging > CCRM - Call Cleaner and Recovery Manager
Table of Contents
Table of Contents
1 CCRM Overview 6
1.1 Description 6
1.2 Architecture 6
1.3 Processing Logic 6
2 CCRM Operations Guide 9
2.1 Starting and Stopping 9
2.2 Files and Directories 10
2.2.1 Log Files 10
3 CCRM Configuration Options 11
3.1 Configuration Tables 11
3.2 Environment Variables 11
4 Index 12
2012-02-11 5
BSCS iX for du > Area: Online Charging > CCRM - Call Cleaner and Recovery Manager
CCRM Overview
1 CCRM Overview
1.1 Description
The Call Cleaner and Recovery Manager process (CCRM) has two major tasks:
completing hanging calls and replicating open calls to the standby node.
• CCRM periodically checks RSHD's shared memory for hanging calls, i.e.
calls which, due to an error in the SCP or the rating engine, are unfinished
because a completion message such as a CALL_DROP_REQ(telephony)
or CONF_REQUEST(content) message has not been processed.
• Whenever a standby is started, the CCRM on the master is triggered by
Supervisor to replicate all open calls in memory to the standby.
On standby node CCRM does not perform a call cleaning. Therefore, CCRM
sleeps until the standby node switches to master.
CCRM connects to all shared memory segments of RSHD. Therefore, it is not
possible to run more than one CCRM in parallel.
1.2 Architecture
Call Cleaner and Recovery Manager
1.3 Processing Logic
Call Cleaning For its call cleaning activities, CCRM proceeds as follows:
1. Looks into RHSD's shared memory in regular intervals as configured for
CCRM in DXL_PROCESS.TRANSACTION_TIME_LIMIT.
This value must be an integer greater than 0.
2. For each transaction found in the shared memory, reads the time-out con-
figured for the event type (refer to the table below).
3. Compares the value of the EVENT_STATUS_INFO.LAST_CHANGE_TIME
UDR attribute with the time-out for the event type.
4. Clears from RSHD's shared memory all events for which the UDR value is
greater than the time-out.
2012-02-11 6
BSCS iX for du > Area: Online Charging > CCRM - Call Cleaner and Recovery Manager
CCRM Overview
The source of the time-out depends on the event type:
Event Type Location of Time-Out
Telephony -u command-line option
Data streaming RSHD_CONFIGURATION.STREAMINGRESERVATION-
TIMEOUT
SMS RSHD_CONFIGURATION.RESERVATIONTIMEOUT
Content RSHD_CONFIGURATION.RESERVATIONTIMEOUT
The way that CCRM proceeds when clearing the memory, however, depends
on the message flow protocol.
• For messages from SCPs using the HP MBI or Diameter protocol, CCRM
sends a cancellation request to RSHD. Thereafter:
- RSHD forwards the cancellation request to CCH.
- CCH cancels the reservation and informs RSHD.
- RSHD moves the event from its working shared memory into its shared
memory segment for duplicate records.
The prepaid balances are not changed, that is, the events are not billed. If
the SCP then sends the reservation request again, RSHD detects that it is
a duplicate request and rejects it.
• For messages from SCPs using the LHS protocol, CCRM creates an artificial
call drop message (CALL_DROP_TRIGGER) and sends it to RSHD. It
depends on the type of service (SMS, content, telephony, or data streaming)
whether the call is billed or the reservation is canceled:
- Telephony, SMS, and data streaming services are billed and the balances
are updated accordingly.
- Content services are not billed; the reservation is canceled and the bal-
ances remain unchanged.
Call Replication The replication process is started when the standby node is started. In this case,
the standby Supervisor sends its counterpart on the master node a startup noti-
fication. The master Supervisor then sends a control UDR to CCRM with EVENT_
STATUS_INFO.MESSAGE_ID set to 203..
CCRM uses the timestamp of the control UDR as the replication start time and
processes all messages in all RSHD shared memory segments.
For each message with a last modification date (EVENT_STATUS_INFO.LAST_
CHANGE_DATE) less than the replication start time, CCRM triggers RSHD to
replicate the messages to the RSHD on the on the standby node refer to
RSHD'sReplication to Standby for more information.
The replication to standby is indicated in the CCRM log file as follows:
CCRM starts replication to standby (<timestamp>)
CCRM ends replication to standby (timestamp)
<n> records out of <n> were replicated
<n> records were not replicated (records created after replication starts)
2012-02-11 7
BSCS iX for du > Area: Online Charging > CCRM - Call Cleaner and Recovery Manager
CCRM Overview
After sending the last replication trigger, CCRM sends an alarm message SYN-
CHRONIZATION_COMPLETED to Supervisor.
2012-02-11 8
BSCS iX for du > Area: Online Charging > CCRM - Call Cleaner and Recovery Manager
CCRM Operations Guide
2 CCRM Operations Guide
2.1 Starting and Stopping
The following command-line options can also be configured in application.
ini.
Option Description Mandatory
-u <value> The time-out (in seconds) after Yes
which CCRM takes the pro-
tocol-specific action for clean-
ing RSHD's shared memory of
hanging calls. This time-out is
used as a fallback if the UDR
attribute EVENT_STATUS_
INFO-RESERVATION_
TIMEOUT is not filled (refer to
Call Cleaning in the Pro-
cessing Logic section for more
information).
Example: -u 180 cancels all
call reservations older than 3
minutes
The value entered
should be larger than
the value configured in DEF-
DURATIONCHUNK of the
RSHD_CONFIGURATION
table for RSHD. Otherwise
CCRM will clean the ongoing
call and it will not be billed.
-i Print out compiler information No
like compiler switches, libraries
or environment settings, ver-
sion of the binary.
Starting via CCRM can be started automatically by Supervisor if configured in Supervisor's
Supervisor application.ini.
Stopping When CCRM runs under Supervisor control, Supervisor stops the CCRM process
by sending a shutdown command with the DXL_TERMINATE messageor DXL_
TERMINATE_IMMEDIATELY sent via DXL/DaTA. When CCRM receives this
shutdown message, it completes the activities in progress and exits.
2012-02-11 9
BSCS iX for du > Area: Online Charging > CCRM - Call Cleaner and Recovery Manager
CCRM Operations Guide
2.2 Files and Directories
2.2.1 Log Files
CCRM creates a log file for each PID every day at 12:00 midnight, local time.
Directory The directory of the log file is defined by the LOG_PATH environment variable.
File Name CCRM_EVENT_LOG_FILE_<PID>_<YYMMDD>.log
Example: The CCRM log file for process ID 25830 on April 15, 2005 is
namedCCRM_EVENT_LOG_FILE_25830_050415.log.
2012-02-11 10
BSCS iX for du > Area: Online Charging > CCRM - Call Cleaner and Recovery Manager
CCRM Configuration Options
3 CCRM Configuration Options
3.1 Configuration Tables
CCRM reads configuration data from the RSHD_CONFIGURATION table.
CCRM reads the value of DXL_PROCESS.TRANSACTION_TIME_LIMIT to find
out the interval in which it should perform its call cleaning activities.
This value must be an integer greater than 0, otherwise CCRM will cause
a high CPU usage. A value of 600 (seconds) is recommended.
3.2 Environment Variables
CCRM processes evaluate two types of environment variables:
• Global Environment Variables: BSCSDB, BSCS_PASSWD and LOG_PATH
• High Availability related environment variables: SV_ALARM_CONNECT.
• CCRM-specific environment variables, as described in the table below:
Variable Name Description
CCRM_TRACE_LEVEL Trace level [0..3] with 3 as the most detailed level.
CCRM_USERID CCRM user name. If this variable is not set, "CCRM" will be
used instead
2012-02-11 11
BSCS iX for du > Area: Online Charging > CCRM - Call Cleaner and Recovery Manager
Index
Index
C
CCRM
architecture, graphic 6
configuration tables 11
description 6
environment variables, description 11
log files 10
processing logic 6
starting and stopping 9
2012-02-11 12
© Ericsson Telekommunikation GmbH & Co. KG 2012.
Ericsson Telekommunikation GmbH & Co. KG All rights reserved. No part of this document may be reproduced
Herriotstr. 1 in any form without the written permission of the copyright owner.
60528 Frankfurt am Main
Germany The contents of this document are subject to revision without
Phone + 49 69 2383 3000 notice due to continued progress in methodology, design and
Fax + 49 69 2383 5188 manufacturing. Ericsson shall have no liability for any error or
www.ericsson.com damage of any kind resulting from the use of this document.
