Oracle Communications Network Charging and Control
Product:
Component:
OCNCC 4.3
Service Logic Execution Environment
Technical Guide
S’ware version:
Release 3.2.0
Guide version:
06.00
Release date:
December 2010
Status:
Approved
Commercial In Confidence
Copyright
Service Logic Execution Environment Technical Guide, Release 3.2.0
06.00
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement
containing restrictions on use and disclosure and are protected by intellectual
property laws. Except as expressly permitted in your license agreement or allowed
by law, you may not use, copy, reproduce, translate, broadcast, modify, license,
transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by
any means. Reverse engineering, disassembly, or decompilation of this software,
unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not
warranted to be error-free. If you find any errors, please report them to us in
writing.
If this software or related documentation is delivered to the U.S. Government or
anyone licensing it on behalf of the U.S. Government, the following notice is
applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related
documentation and technical data delivered to U.S. Government customers are
"commercial computer software" or "commercial technical data" pursuant to the
applicable Federal Acquisition Regulation and agency-specific supplemental
regulations. As such, the use, duplication, disclosure, modification, and adaptation
shall be subject to the restrictions and license terms set forth in the applicable
Government contract, and, to the extent applicable by the terms of the
Government contract, the additional rights set forth in FAR 52.227-19, Commercial
Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle
Parkway, Redwood City, CA 94065.
This software is developed for general use in a variety of information management
applications. It is not developed or intended for use in any inherently dangerous
applications, including applications which may create a risk of personal injury. If
you use this software in dangerous applications, then you shall be responsible to
take all appropriate fail-safe, backup, redundancy, and other measures to ensure
the safe use of this software. Oracle Corporation and its affiliates disclaim any
liability for any damages caused by use of this software in dangerous applications.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other
names may be trademarks of their respective owners.
This software and documentation may provide access to or information on content,
products, and services from third parties. Oracle Corporation and its affiliates are
not responsible for and expressly disclaim all warranties of any kind with respect to
third-party content, products, and services. Oracle Corporation and its affiliates will
not be responsible for any loss, costs, or damages incurred due to your access to
or use of third-party content, products, or services.
Page ii
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Contents
Copyright ............................................................................................................................. ii About this Document ........................................................................................................... v Document Conventions ...................................................................................................... vi Chapter 1 System Overview Overview .............................................................................................................................. 1 Introduction to the Service Logic Execution Environment ................................................... 2 Main Components of the SLEE ........................................................................................... 4 SLEE Interfaces ................................................................................................................... 7 Application Programming Interface ..................................................................................... 9 Chapter 2 Configuration Overview ............................................................................................................................ 13 Configuration Overview ..................................................................................................... 14 Configuring the SLEE ........................................................................................................ 15 Chapter 3 Tools and Utilities Overview ............................................................................................................................ 29 slee.sh ............................................................................................................................... 30 stop.sh ............................................................................................................................... 31 clean .................................................................................................................................. 32 check ................................................................................................................................. 33 sfVerify ............................................................................................................................... 36 Chapter 4 Background Processes Overview ............................................................................................................................ 37 replicationIF ....................................................................................................................... 38 tcRelayApp ........................................................................................................................ 39 watchdog ........................................................................................................................... 40 Chapter 5 Troubleshooting Overview ............................................................................................................................ 43 Common Troubleshooting Procedures .............................................................................. 44 Possible Problems ............................................................................................................. 46 Chapter 6 Pre-installation Overview ............................................................................................................................ 47 Installation Pre-requisites .................................................................................................. 48 Setting the Time Zone ....................................................................................................... 49 Continued on next page
Service Logic Execution Environment
Technical Guide
Page iii
Commercial In Confidence
Chapter 7 Installation Overview ............................................................................................................................ 51 Installation Procedure Overview ........................................................................................ 52 Loading the Distribution File .............................................................................................. 53 Installing the SLEE package.............................................................................................. 54 Checking the Installation ................................................................................................... 56 Chapter 8 Removal Overview ............................................................................................................................ 57 Removing Packages .......................................................................................................... 58 Appendix Overview ............................................................................................................................ 59 Glossary of Terms ............................................................................................................. 61 Index .................................................................................................................................. 65 Page iv
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
About this Document
Scope
The scope of this document includes all the information required to install,
configure and administer the SLEE application.
Audience
This guide was written primarily for system administrators and persons installing,
configuring and administering the SLEE application. The documentation assumes
that the person using this guide has a good technical knowledge of the system.
Pre-requisites
Although there are no pre-requisites for using this guide, familiarity with the target
platform would be an advantage.
A solid understanding of Unix and a familiarity with IN concepts are an essential
pre-requisite for safely using the information contained in this technical guide.
Attempting to install, remove, configure or otherwise alter the described system
without the appropriate background skills, could cause damage to the system;
including temporary or permanent incorrect operation, loss of service, and may
render your system beyond recovery.
This manual describes system tasks that should only be carried out by suitably
trained operators.
Related
documents
There are no documents related to this document.
Service Logic Execution Environment
Technical Guide
Page v
Commercial In Confidence
Document Conventions
Typographical
conventions
Before you start using this guide, it is important to understand the terms and
typographical conventions used in the documentation.
Specialised terms and acronyms are defined in the Glossary at the end of this
guide.
Formatting convention
Type of information
Special Bold
Items you must select such as menu options,
or names of tabs.
Emphasis within text.
Names of database tables and fields.
Italics
Name of a document, chapter, topic or other
publication.
Button
The name of a button to click or a key to
press.
Example: To close the window, either click
Close or press Esc.
Key+Key
Key combinations for which the user must
press and hold down one key and then press
another.
Example: Ctrl+P, or Alt+F4.
Monospace
Text that you must type and examples of code
or standard output.
variable
Used to indicate variables or text that should
be replaced.
menu option > menu option >
Used to indicate the cascading menu option to
be selected, or the location path of a file.
Example: Operator Functions > Report Functions
Example: /IN/html/SMS/Helptext/
Used to indicate a hypertext link on an HTML
page.
hypertext link
Icons
The following icons are used as visual cues to draw attention to important
information.
Note: Indicates useful and complementary information. Explanation, comment, or
short expansion of the text object that is intended to catch your attention.
Tip: Indicates practical but non-essential information that makes the solution
easier to use or operate (e.g. keyboard shortcut, alternative way to perform a step
in a procedure, etc).
Warning: Indicates a caution. If this information is ignored, it could cause possible
and irreversible damage to the equipment, data or software.
Continued on next page
Page vi
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Terminology
This topic explains any terminology specific to this manual.
Term
Definition
ACS Customer
ACS Customers are set up in the ACS Customer screen.
They configure systems to provide services to subscribers.
Service Provider
CCS Service Providers are the same as ACS Customers
and are set up in the ACS Customer screen. There is
additional Service Provider configuration provided in CCS.
Customer
Customers in CCS refer to the Customers configured on the
Subscriber Management screen.
A Subscriber account is set up for each MSISDN which uses
services provided by the Service Provider.
Subscriber
Service Logic Execution Environment
Technical Guide
Page vii
Commercial In Confidence
Chapter 1
System Overview
Overview
Introduction
This chapter provides a high-level overview of the application. It explains the
basic functionality of the system and lists the main components.
It is not intended to advise on any network or service implications of the product.
In this chapter
This chapter contains the following topics.
Introduction to the Service Logic Execution Environment............................... 2
Main Components of the SLEE .......................................................................4
SLEE Interfaces ..............................................................................................7
Application Programming Interface .................................................................9
Service Logic Execution Environment
Technical Guide
Page 1
Chapter 1
Commercial In Confidence
Introduction to the Service Logic Execution Environment
Introduction
The SLEE provides a common execution environment for existing Oracle
Intelligent Network (IN) products, including:
Advanced Calling Services (ACS)
Call Control Services (CCS)
Universal Billing Engine (UBE)
Messaging Manager (MM)
It provides mechanisms for multiple interfaces to communicate events with the call,
therefore simplifying the service logic interfaces.
Functionality
overview
The SLEE provides the following functionality:
Functionality for
hosted services
The main functions of the SLEE are to provide hosted services with the following
functionality:
SLEE process monitoring/restart, and
simultaneous management of multiple different service logic applications.
event handling/call matching
event scheduling
call thread and context data control
service logic application management, and
interface management.
Service logic
support
The SLEE implements the useful common components of service logic within a
single environment.
It provides the following to simply service logic interfaces:
a well-defined, open interface for the handling of call control threads, call
context data and application management, and
efficient flexible mechanisms for multiple interfaces to communicate events
with the call.
The SLEE maintains integrity and ensures high performance when managing
multiple messages from multiple underlying networks to multiple applications.
Continued on next page
Page 2
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 1
Introduction to the Service Logic Execution Environment,
Continued
Example setup
Here is an example of a common SLEE setup.
Service Logic Execution Environment
Technical Guide
Page 3
Chapter 1
Commercial In Confidence
Main Components of the SLEE
Introduction
The Oracle SLEE uses the following components.
Component
Description
Further Information
SLEE.cfg
This file holds the main
configuration for the SLEE and
startup.
Configuring the SLEE
(on page 15)
SLEE shared
memory
Shared memory used by SLEE
applications and interfaces.
SLEE API
Application Programming Interface
used by SLEE applications and
interfaces.
watchdog
The SLEE watchdog monitors
SLEE applications and interfaces,
restarting them if necessary.
watchdog (on page 20)
Application
An application consists of an
executable program that uses the
SLEE application API to process
events for calls.
Applications (on page
5)
Application
Instance
An application instance is a
running instance of a SLEE
application program.
Application instance (on
page 5)
Service
A service is the functionality
provided by an application.
Service (on page 6)
Service Handle
A service handle is a name given
to the service.
Service handles (on
page 6)
Service Key
A service key maps to a service or Service keys (on page
interface.
6)
Interface
An interface is an executable
program that provides a service to
the applications.
Interfaces (on page 6)
Interface Handle
An interface handle identifies the
associated interface.
The SLEE has a set of common
tools which can be used to
manage the SLEE and the SLEE
applications and interfaces.
Interface handle (on
page 6)
SLEE tools (on page 6)
SLEE tools
For a full description of each component, refer to the topics below.
SLEE shared
memory
The /tmp/slee is the default file used by all SLEE processes at start up to get the
shared memory key of the SLEE shared memory. This file must exist and must be
the same for all processes wishing to access the same shared memory.
If this file is removed, a SLEE process which is starting up will will fail to find
shared memory and will exit. If this file is removed, you must restart the SLEE.
Continued on next page
Page 4
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 1
Main Components of the SLEE, Continued
SLEE shared memory (continued)
For information about overriding the location and filename by setting the
environment variable SLEE_FILE for all SLEE processes, see Optional
environmental variables (on page 15).
Entity
relationship
This diagram shows how entries in the SLEE.cfg file are related.
Applications
An example of an application is a piece of service logic that provides local number
portability processing. An application may support multiple services (for example,
it may provide voice VPN in addition to number portability). The SLEE can support
multiple different applications simultaneously.
An application is a program that provides a specific set of services to the
interfaces. The SLEE allows multiple copies of an application to be started, to
enable performance advantages in SMP environments and in cases where an
application can block (very briefly) during execution of service logic. This may
occur, for example, during an Oracle database read.
Note: Care must be taken to avoid applications from blocking.
Under ideal conditions, an application would never communicate directly with
external entities. However, in some cases, this cannot be avoided.
Applications are provided with a set of classes and objects, which provide an
interface to the SLEE. All the API functionality for an application is based around
call instances. A call instance must be created by an interface (or application
acting like an interface). The application’s call context memory may also be
allocated via the API that is associated with the call instance.
Application
instance
Each executing copy of the application is known as an application instance. The
SLEE can support multiple running instances of each application program. This is
useful in multi-processor environments, where it is possible to be processing
events for more than one call in parallel.
Continued on next page
Service Logic Execution Environment
Technical Guide
Page 5
Chapter 1
Commercial In Confidence
Main Components of the SLEE, Continued
Service
Each application may provide multiple services. In the above example, we have
an application that provides service and local number portability (SNP & LNP).
That application would therefore have two services defined - one for each SNP
and LNP.
Service handles
The service handle is defined in the service entity. When a new call is presented
to the application, the service handle indicates the particular service for which the
call is intended.
Service keys
The service key is the SLEE's mechanism for providing service discrimination.
Each service key maps to a service or interface.
Note: A service key is a generic name for the identifiers for a service or interface.
Service keys may be derived in some cases from the INAP InitialDP service key.
For more information about configuring service keys, see Service keys (see
"SERVICEKEY" on page 23).
Interfaces
Each service may include an interface to a protocol, which is used to talk to an
external entity (SSP, HLR, billing engine, alarm system).
An interface may also generate new calls for the services, applications and
application instances.
Examples: Interfaces include:
TCAP/SS7
Billing Access
Databases
Timers.
Interface handle
Interface handles are used by other elements within the SLEE (other interfaces or
application instances) to identify the associated interface.
SLEE tools
The SLEE package also includes a set of tools for managing the SLEE. This table
describes these tools.
Tool
Description
Further Information
slee.sh
This script starts the SLEE.
Starting the SLEE.
stop.sh
This script shuts down the SLEE and
clears the SLEE shared memory.
Stopping the SLEE.
clean
The clean utility is used to remove
Removing Shared
SLEE shared memory and semaphores Memory.
after a unclean SLEE shutdown has
occurred.
This tool provides reports on SLEE
check (on page 33).
attributes.
check
Page 6
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 1
SLEE Interfaces
Introduction
An interface is a process that converts messages or events from outside the
system from an external format into a common SLEE format. These may then be
passed between elements of the SLEE. It also converts SLEE format messages
to the external format required. The common format is an object representation of
the event called a SLEE Event.
Interfaces are provided with a set of classes and objects, which provide an
interface to the SLEE. Interfaces are the main sources of calls requiring
processing. This is done by call instances and dialogs with those call instances.
A dialog allows messages to be routed between call instances and interfaces. A
dialog also allows identification of the call instance or dialog that a SLEE Event
can support.
In addition to converting to and from SLEE events and external format events, the
interfaces must also respond to SLEE management events. SLEE management
events are a specific type of SLEE event.
Types of interface There are different types of interface. Any interface can be one or more of these
types:
Type
Description
Source
Can generate new call instances and dialogs due to external events.
Server
Can only respond to entities that create dialogs with it and make
requests (that is, it can only respond to existing call instances).
A service that never sends a SLEE event. A special method of
sending events to sinks is provided that does not use a dialog.
Sink
Interface
communication
through dialogs
While it is normal for interfaces to only communicate via dialogs belonging to call
instances, it is also possible for an interface to talk to another interface, via a
dialog. It is also possible for an application to talk to another application, via a
dialog and call objects.
Example
interfaces
This table describes some of the interfaces that may be supplied with the SLEE
package.
Interface
Description
Type
timerIF
The Timer interface interacts with the system’s
real-time clock to provide time-out events to the
service logic on demand.
Server
alarmIF
The Alarm interface interacts with the system
Sink
error logging functionality to report alarms passed
from the service logic application.
statsIF
The Statistics interface maintains and reports
statistics to the management system. Statistics
are effectively peg counts.
statsIF requires a statistics.bin file to run. For
more information about creating a statistics.bin
file, see sfVerify (on page 36).
Sink
Continued on next page
Service Logic Execution Environment
Technical Guide
Page 7
Chapter 1
Commercial In Confidence
SLEE Interfaces, Continued
Example interfaces (continued)
Interface
Description
replicationIF
The Database Replication interface is an update
Server/Sink
requester. It processes updates to the system
which are generated during call processing. For
example, when a client uses call plan functionality
to change their profile data.
The replicationIF sends an update request to the
smsMaster on an SMP. The SMF database is
updated with the new information, and is then
replicated to all other nodes.
For more information about update requests,
update requests and replication, see the SMS
Technical Guide.
The CDR interface writes cdr files containing data Server
received from SLEE CDR events.
cdrIF
Type
Note: Different installations use different SLEE interfaces. If the interface is not
listed in the SLEE.cfg file, it is not being used by your installation.
Page 8
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 1
Application Programming Interface
Introduction
The SLEE provides an Application Programming Interface, through which
applications may interact with the SLEE and elements within the SLEE, such as
applications and interfaces.
All interactions between applications and other SLEE elements are performed via
messages based on objects, which are sub-classes of the SleeEvent class.
The SLEE itself only has one type of SleeEvent, the SleeManagementEvent class.
Each of the interfaces provided with the SLEE have their own sub-classes of
SleeEvent. SleeEvents may be sent as part of a dialog with another SLEE entity,
in which case a SleeDialog object is used to associate SleeEvents of the same
dialog. Alternatively, messages may be sent as one-off events, which do not
require a response or associated message. In this case, there is no SleeDialog
object.
SLEE Dialogs
A SleeDialog provides an association between related messages flowing between
SLEE entities (applications and interfaces).
Dialogs also store the 'addresses' of the two entities involved in the dialog. Each
dialog has an application side and an interface side.
Note: When an application instance opens a dialog with another application, the
first application instance is considered to be the ‘interface’ side of the dialog. Also,
if a SLEE interface opens a dialog with another SLEE interface, the first SLEE
interface is considered to be the ‘application’ side of the dialog.
Application instances can only open dialogs with interfaces and interfaces can only
open dialogs with applications. To enable application to application and interface
to interface dialogs, the first application or interface must pretend to be interface or
application respectively.
SLEE Events
SLEE Events are chunks of shared memory which are used to communicate data
within a dialog. Applications and interfaces monitor dialogs for new events.
Management
Events
A SLEE management event is an implementation of a SLEE Event, which is used
to pass management events from the SLEE to applications and interfaces.
The SLEE reserves a number of events user to send management events. These
events are added to the first list that has a size >= 1024 bytes. This means the
event count in the check program will show more events than configured in the
configuration file.
Continued on next page
Service Logic Execution Environment
Technical Guide
Page 9
Chapter 1
Commercial In Confidence
Application Programming Interface, Continued
Supported
management
events
The following SLEE management events are supported.
Event
Description
WATCHDOG
The watchdog monitors the health of all SLEE
elements by sending a series of checks to each
configured element. If an element fails to respond, the
watchdog will take action to restart the process.
Initially, it will send the element a SIGABRT. If the
process does not die after a period, a SIGKILL will be
sent.
SERVICE_ENABLED
Indicates to an application instance that a service has
been enabled. The service handle is passed in the
event. Can be used to trigger opening of files,
databases, etc.
SERVICE_DISABLED
Indicates to an application instance that a service has
been disabled. The service handle is passed in the
event. Can be used to trigger closing of files,
databases, etc.
APPLICATION_END
Indicates that the application is currently being
quiessed and that no new calls will be received. An
APPLICATION_KILL will be received when all existing
calls complete.
APPLICATION_KILL
Indicates that the application instance should be
shutdown and exited. Failure to perform this task
within a time period will result in a SIGHTERM being
sent to the application instance. If the application
instance is still active after a further period, a SIGKILL
will be sent.
INTERFACE_END
Indicates that the interface is currently being quiessed
and that no new calls will be received or should be
generated. An INTERFACE_KILL will be received
when all existing dialogs are complete.
INTERFACE_KILL
Indicates that the interface process should be
shutdown and exited. Failure to perform this task
within a time period will result in a SIGHTERM being
sent to the interface process. After a further period, if
the interface process is still active, a SIGKILL will be
sent.
DIALOG_CLOSED
Indicates to an interface or application that a dialog has
been closed by the other end, but no message data
has been sent.
REREAD_CONFIG
This message is sent to an application or interface to
request it to re-read its config. This is a usermanagement event which the SLEE will never transmit
on its own.
Not all interfaces support this request.
Continued on next page
Page 10
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 1
Application Programming Interface, Continued
Supported management events (continued)
Event
Description
CALL_INSTANCE_KILL The specified call instance has been killed.
REPORT_REQUEST
This message is sent to an application or interface to
generate a short report to stdout or a pre-defined file.
Not all interfaces support this request.
CALL_INSTANCE_
TIMED_OUT
The specified call instance has timed out.
DIALOG_TIMED_OUT
The specified dialog has timed out.
STATUS_REQUEST
A status request is sent to an application or interface to
generate a short status summary. The receiver should
send back a STATUS_RESPONSE message with the
current status of the process.
Not all interfaces support this request.
Contains the response for the STATUS_REQUEST
message.
STATUS_RESPONSE
Service Logic Execution Environment
Technical Guide
Page 11
Commercial In Confidence
Chapter 2
Configuration
Overview
Introduction
This chapter explains how to configure the application.
In this chapter
This chapter contains the following topics.
Configuration Overview .................................................................................14
Configuring the SLEE ....................................................................................15
Service Logic Execution Environment
Technical Guide
Page 13
Chapter 2
Commercial In Confidence
Configuration Overview
Introduction
This topic provides a high level overview of how the SLEE is configured.
There are configuration options which are added to the configuration files that are
not explained in this chapter. These configuration options are required by the
application and should not be changed.
Configuration
process overview
This table describes the steps involved in configuring the SLEE for the first time.
Step
Action
1
The SLEE.cfg file must be configured. This will include configuring:
the SLEE maximum values
the watchdog
the SLEE interfaces which will be used for this installation (for
example, timerIF, cdrIF and/or alarmsIF.
Any SLEE interface or application which has an additional configuration
file must be configured. For example, the cdrIF is configured using the
cdrIF.cfg file.
Note: Most installations will require other applications and interfaces to
be configured in the SLEE.cfg also. This should be done after the other
applications have been installed. For more information about how to
configure additional interfaces and applications, see the documentation
for the application.
2
Configuration
components
The SLEE is configured by the following components:
Component
Locations
Description
Further Information
SLEE.cfg
all machines
The only file used to configure
the SLEE is SLEE.cfg.
The configuration file is used to
configure the applications,
services and interfaces which
the SLEE manager will initialise.
From this information the SLEE
manager also knows how much
shared memory to allocate.
SLEE.cfg is broken into three
sections:
maximum object instances
application entries, and
interface entries
Configuring the SLEE
(on page 15).
Environmental
variables
all machines
SLEE supports some
environmental variables.
Optional environmental
variables (on page 15)
This file configures the cdrIF.
This file configures the
tcRelayApp.
Configuration (on page
39)
cdrIF.cfg
all machines
tcRelayMapping all machines
s.def
Page 14
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 2
Configuring the SLEE
Introduction
The SLEE must be configured at start-up. The default configuration file is:
/IN/service_packages/SLEE/etc/SLEE.cfg
You can change this by setting the SLEE_FILE environmental variable.
Optional
environmental
variables
SLEE supports the following environmental variables (usually declared in
acs_oper's SLEE_FILE_:
SLEE_FILE
Syntax:
Description:
Optionality:
Default:
Notes:
Modifying
SLEE.cfg
The location of the file which stores the shared memory keys
for the SLEE's shared memory.
Optional.
/tmp/slee
All SLEE processes must use the same SLEE_FILE.
Each section of the SLEE.cfg configuration file is detailed below, with examples of
appropriate settings.
The SLEE must be restarted for any configuration changes to take effect. For
more information on restarting the SLEE, see Tools and Utilities (on page 29).
Maximum values
The first section of SLEE.cfg contains the maximum number of each type of object
which can be held in shared memory. If this value is exceeded, an exception will
be thrown and an entry made in the syslog. In many cases this will cause the
SLEE and all processes to restart.
Format:
MAXAPPLICATIONS=<max>
MAXSERVICES=<max>
MAXSERVICEHANDLES=<max>
MAXSERVICEKEYS=<max>
MAXDIALOGS=<max>
MAXEVENTS=<max> [<size>]
MAXCALLS=<max>
MAXINTERFACES=<max>
MAXEVENTTYPES=<max>
The available parameters are:
MAXAPPLICATIONS
Syntax:
Description:
Type:
Optionality:
Default:
Notes:
Example:
MAXAPPLICATIONS=<max>
The maximum number of application objects which can be
held in shared memory.
Integer
Mandatory
none
This also sets the maximum number of APPLICATION (on
page 24) entries which can be active in the SLEE.cfg file.
MAXAPPLICATIONS=5
Continued on next page
Service Logic Execution Environment
Technical Guide
Page 15
Chapter 2
Commercial In Confidence
Configuring the SLEE, Continued
Maximum values (continued)
MAXSERVICES
Syntax:
Description:
Type:
Optionality:
Default:
Notes:
Example:
MAXSERVICES=<max>
The maximum number of service objects which can be held
in shared memory.
Integer
Mandatory
none
This also sets the maximum number of SERVICE entries (on
page 21) which can be active in the SLEE.cfg file.
MAXSERVICES=5
MAXSERVICEHANDLES
Syntax:
Description:
Type:
Optionality:
Default:
Notes:
Example:
MAXSERVICEHANDLES=<max>
The maximum number of service handles.
Integer
Optional (default used if not set).
10
MAXSERVICEHANDLES has to be greater than or equal to
the number of distinct service handles specified in SERVICE
entries (on page 21) in SLEE.cfg
MAXSERVICEHANDLES=20
MAXSERVICEKEYS
Syntax:
Description:
Type:
Optionality:
Default:
Notes:
Example:
MAXSERVICEKEYS=<max>
The maximum number of service key objects which can be
held in shared memory.
Integer
Optional (default used if not set).
If this parameter is not specified, the count of serviceKey
entries in the configuration files are used.
This also sets the maximum number of SERVICEKEY (on
page 23) entries which can be active in the SLEE.cfg file.
MAXSERVICEKEYS=5
MAXDIALOGS
Syntax:
Description:
Type:
Optionality:
Default:
Example:
MAXDIALOGS=<max>
The maximum number of Dialog objects which can be held in
shared memory.
Integer
Mandatory
none
MAXDIALOGS=5
Continued on next page
Page 16
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 2
Configuring the SLEE, Continued
Maximum values (continued)
MAXDIALOGS
Syntax:
Description:
Type:
Optionality:
Default:
Notes:
Example:
MAXEVENTS=<max> <size>
The maximum number of event objects which can be held in
shared memory.
Integer
Mandatory
none
MAXEVENTS can be specified more than once for multiple
lists of differing sizes and the effects are cumulative.
This list will then have its count modified (when the SLEE
starts up) to handle the management event reservation. This
affects the check tool event count. For more information, see
check (on page 33).
If the MAXEVENTS values are exceeded when the system is
running, no more events or calls will be accepted and alarm
messages will be sent.
To get 500 events of size 2k, and 200 of size 4k, set:
MAXEVENTS=500 2048
MAXEVENTS=200 4096
<size>
Syntax:
Description:
Type:
Optionality:
Default:
Notes:
Example:
<size>
MAXEVENTS (see "MAXDIALOGS" on page 17). supports
the <size> parameter which allows you to set the maximum
data segment size of an event.
Integer
Optional (default used if not set).
1024
There must be al least one list with a size equal to or greater
than 1024 bytes.
For an example of this parameter in context, see
MAXEVENTS (see "MAXDIALOGS" on page 17).
MAXCALLS
Syntax:
Description:
Type:
Optionality:
Default:
Notes:
Example:
MAXCALLS=<max>
The maximum number of call objects which can be held in
shared memory.
Integer
Mandatory
none
If the MAXCALLS values are exceeded when the system is
running, no more events or calls will be accepted and alarm
messages will be sent.
MAXCALLS=500
Continued on next page
Service Logic Execution Environment
Technical Guide
Page 17
Chapter 2
Commercial In Confidence
Configuring the SLEE, Continued
Maximum values (continued)
MAXSERVICEKEYS
Syntax:
Description:
Type:
Optionality:
Notes:
Example:
MAXINTERFACES=<max>
The maximum number of interface objects which can be held
in shared memory.
Integer
Mandatory
This also sets the maximum number of INTERFACE (on
page 18) entries which can be active in the SLEE.cfg file.
MAXINTERFACES=5
MAXEVENTTYPES
Syntax:
Description:
Type:
Optionality:
Example:
Other parameters
MAXEVENTTYPES=<max>
The maximum number of Event Type objects which can be
held in shared memory.
Integer
Mandatory
MAXEVENTTYPES=5
These parameters are set after the Maximum values configuration in SLEE.cfg.
NOWIPESOCKETS
Syntax:
Description:
Type:
Optionality:
Allowed:
Default:
Notes:
INTERFACE
NOWIPESOCKETS=<int>
How to handle pre-existing sockets on startup.
Integer
Optional (default used if not set).
0
Socket files corresponding to SLEE.cfg-specified
interfaces are removed.
anything No socket files will be removed.
else
0
This setting is designed for use in testing environments
where more than one SLEE is running concurrently. It
should not be used in production.
Interface entries configure SLEE interfaces and they should be left intact. The
installation and removal of packages may add or remove interface entries.
Messages can be sent directly to an interface handle, or via a service key.
Usage:
INTERFACE=<ifHandle> <interfaceName> <interfacePath>
<interfaceType> [<inteventCount> <dialogCount>]
The available parameters are:
Continued on next page
Page 18
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 2
Configuring the SLEE, Continued
INTERFACE (continued)
ifHandle
Syntax:
Description:
Type:
Optionality:
Example:
To see this parameter in context, see INTERFACE (on page
18).
The unique name of this SLEE interface which identifies the
interface.
String
Optional (default used if not set).
For an example of this parameter used in context, see
Example (on page 20).
interfaceName
Syntax:
Description:
Type:
Example:
To see this parameter in context, see INTERFACE (on page
18).
The name of the binary which enables this interface.
String
For an example of this parameter used in context, see
Example (on page 20).
interfacePath
Syntax:
Description:
Type:
Example:
To see this parameter in context, see INTERFACE (on page
18).
The full path to the binary.
String
For an example of this parameter used in context, see
Example (on page 20).
interfaceType
Syntax:
Description:
Type:
Allowed:
Example:
To see this parameter in context, see INTERFACE (on page
18).
The type of interface.
String
EVENT
UGD
For an example of this parameter used in context, see
Example (on page 20).
Continued on next page
Service Logic Execution Environment
Technical Guide
Page 19
Chapter 2
Commercial In Confidence
Configuring the SLEE, Continued
INTERFACE (continued)
intEventCount
Syntax:
Description:
Type:
Optionality:
Default:
Notes:
Example:
To see this parameter in context, see INTERFACE (on page
18).
The maximum number of events allowed to be awaiting
processing before call limiting for the interface starts.
Integer
Optional, but required if dialogCount is set.
unlimited
If the number of events exceeds the limit specified in the
configuration file, then any further attempts to create another
dialog to the interface will fail. This failure will then be
handled by the process attempting to create the dialog.
For an example of this parameter used in context, see
Example (on page 20).
dialogCount
Syntax:
Description:
Type:
Optionality:
Default:
Notes:
Example:
To see this parameter in context, see INTERFACE (on page
18).
The maximum number of dialogs that can be open on the
interface.
Integer
Optional (default used if not set).
unlimited
The SLEE tracks the number of dialogs open on the
interface. If the interface has exceeded the limit specified in
the configuration file, any further attempts to create a dialog
on the interface will fail.
For an example of this parameter used in context, see
Example (on page 20).
Example
These lines in SLEE.cfg configure the timer, replication and notification interfaces.
INTERFACE=Timer timerIF /IN/service_packages/SLEE/bin EVENT
INTERFACE=Replication replicationIF.sh
/IN/service_packages/SLEE/bin EVENT
INTERFACE=notificationIF notificationIF
/IN/service_packages/SLEE/bin UDG
watchdog
This section defines the location and cycle time for the watchdog. You should not
need to alter these settings.
WATCHDOG=/IN/service_packages/SLEE/bin/ watchdog
WATCHDOGCYCLETIME=30
For more information, see watchdog (on page 40).
Continued on next page
Page 20
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 2
Configuring the SLEE, Continued
SERVICE entries
The SERVICE entries define each service object to be created in shared memory.
The service name, priority and the name of the application that provides this
service are defined here. Each service must be associated with an application.
Note: You cannot have more SERVICES than the number allowed by
MAXSERVICEHANDLES (on page 16).
Usage:
SERVICE=<serviceName> <priority> <appName> <serviceHandle>
[<callCount >]
The available parameters are:
serviceName
Syntax:
Description:
Type:
Optionality:
Notes:
Example:
To see this parameter in context, see SERVICE entries (on
page 21).
The name of the service provided by an application.
String
Mandatory
This matches the dest (on page 24) parameter in the
SERVICEKEY (on page 23) entry for the service keys which
will use this service.
It must match at least one service key entry.
For an example of this parameter used in context, see
Examples (on page 23).
priority
Syntax:
Description:
Type:
Optionality:
Example:
To see this parameter in context, see SERVICE entries (on
page 21).
The priority the scheduler gives this service.
Integer
Mandatory
For an example of this parameter used in context, see
Examples (on page 23).
Continued on next page
Service Logic Execution Environment
Technical Guide
Page 21
Chapter 2
Commercial In Confidence
Configuring the SLEE, Continued
SERVICE entries (continued)
appName
Syntax:
Description:
Type:
Optionality:
Notes:
Example:
To see this parameter in context, see SERVICE entries (on
page 21).
The name of the application which enables this service.
String
Mandatory
This matches to the appName (on page 24) parameter in the
APPLICATION (on page 24) for the application which will
handle this service.
It must match at least one application entry.
For an example of this parameter used in context, see
Examples (on page 23).
serviceHandle
Syntax:
Description:
Type:
Optionality:
Notes:
Example:
To see this parameter in context, see SERVICE entries (on
page 21).
The service handle which is sent to the application to enable
it to provide more than one service.
String
Mandatory
It must match the service handle defined in the application
entry this service entry links to.
Example: serviceHandles for slee_acs must match
serviceNames in ServiceEntries in acs.conf. For more
information about ACS ServiceEntries, see the ACS
Technical Guide.
There will typically be multiple lines of this type for each
appName as one application will usually handle more than
one service.
For an example of this parameter used in context, see
Examples (on page 23).
Continued on next page
Page 22
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 2
Configuring the SLEE, Continued
SERVICE entries (continued)
callCount
Syntax:
Description:
Type:
Optionality:
Default:
Notes:
Example:
To see this parameter in context, see SERVICE entries (on
page 21).
The maximum number of concurrent calls which can be
processed by this service.
Integer
Optional
unlimited
If the number of calls active on this service exceeds the
specified limit, all attempts to create a call for this service will
fail.
For an example of this parameter used in context, see
Examples (on page 23).
Examples
This text shows some examples of SERVICE entries in a SLEE.cfg file.
SERVICE=PREPAID 1 slee_acs CCS
SERVICE=ACS_Outgoing 1 slee_acs ACS_Outgoing
SERVICEKEY
The service key entries define each service key. They also include information on
which service or interface will handle this service key. Each service key must be
associated with either a service or an interface instance.
Service keys have the following configuration options:
SERVICEKEY=<keyType> <serviceKey> <dest>
The available parameters are:
keyType
Syntax:
Description:
Type:
Example:
To see this parameter in context, see SERVICEKEY (on
page 23).
The type of service key.
Integer
For an example of this parameter used in context, see
Examples (on page 24).
serviceKey
Syntax:
Description:
Allowed:
Example:
To see this parameter in context, see SERVICEKEY (on
page 23).
The service key from interface.
Format depends on interface.
For an example of this parameter used in context, see
Examples (on page 24).
Continued on next page
Service Logic Execution Environment
Technical Guide
Page 23
Chapter 2
Commercial In Confidence
Configuring the SLEE, Continued
SERVICEKEY (continued)
dest
Syntax:
Description:
Notes:
Example:
To see this parameter in context, see SERVICEKEY (on
page 23).
Service name or interface name.
Must match a serviceName (on page 21) or ifHandle (on
page 18).
For an example of this parameter used in context, see
Examples (on page 24).
Examples
This text shows examples of SERVICEKEY entries.
SERVICEKEY=INTEGER 101 PREPAID
SERVICEKEY=INTEGER 1 0800
The serviceKey depicts the service key that this application will handle. There will
typically be multiple lines of this type for each appName as one application will
usually handle more than one service key.
APPLICATION
The application entry enables the SLEE to execute the binary files.
Usage:
APPLICATION=<appName> <execName> <execDir> <startInstances>
<maxinstances> [<appEventCount>]
The available parameters are:
appName
Syntax:
Description:
Type:
Optionality:
Default:
Notes:
Example:
To see this parameter in context, see APPLICATION (on
page 24).
The name of the application.
String
Mandatory
none
This is used to refer to the application in other parts of the
configuration file, including SERVICE entries (on page 21),
where it must be matched by appName (on page 22).
For an example of this parameter used in context, see
Example (on page 26).
Continued on next page
Page 24
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 2
Configuring the SLEE, Continued
APPLICATION (continued)
execName
Syntax:
Description:
Type:
Optionality:
Default:
Example:
To see this parameter in context, see APPLICATION (on
page 24).
The name of the binary file to be run.
String
Mandatory
none
For an example of this parameter used in context, see
Example (on page 26).
execDir
Syntax:
Description:
Type:
Optionality:
Allowed:
Default:
Example:
To see this parameter in context, see APPLICATION (on
page 24).
Full path to the directory where the executable binary is
stored.
String
Optional (default used if not set).
Any directory path.
/IN/service_packages/SLEE/bin
For an example of this parameter used in context, see
Example (on page 26).
startInstances
Syntax:
Description:
Type:
Optionality:
Default:
Example:
To see this parameter in context, see APPLICATION (on
page 24).
The number of instances of the application the SLEE should
initially start.
Integer
Optional (default used if not set).
1
For an example of this parameter used in context, see
Example (on page 26).
Continued on next page
Service Logic Execution Environment
Technical Guide
Page 25
Chapter 2
Commercial In Confidence
Configuring the SLEE, Continued
APPLICATION (continued)
maxInstances
Syntax:
Description:
Type:
Optionality:
Default:
Example:
To see this parameter in context, see APPLICATION (on
page 24).
The maximum number of instances of the application that the
SLEE will support.
Integer
Optional (default used if not set).
1
For an example of this parameter used in context, see
Example (on page 26).
appEventCount
Syntax:
Description:
Type:
Optionality:
Notes:
Example:
To see this parameter in context, see APPLICATION (on
page 24).
The maximum number of events allowed to be awaiting
processing before call limiting for the application starts.
Integer
Optional
app event count applies to the application as a
whole, that is, all the application instances combined. If
app event count is set to 1000 and start num
instance and max num instance are both set to 2,
then two application instance processes will run and
each one can have up to 500 events queued.
If the number of events exceeds the limit specified in the
configuration file, then any further attempts to create
another call instance will fail.
For an example of this parameter used in context, see
Example (on page 26).
Example
This text shows an example of an APPLICATION entry.
APPLICATION=appExample appExample ../appExample 1 1
Example
SLEE.cfg file
This is an example of the configuration part of a SLEE.cfg file.
MAXAPPLICATIONS=10
MAXSERVICES=10
MAXSERVICEHANDLES=10
MAXSERVICEKEYS=20
MAXDIALOGS=70000
MAXEVENTS=50000
MAXCALLS=25000
MAXINTERFACES=20
MAXEVENTTYPES=30
MAXCORRELATIONIDS=10000
INTERFACE=Timer timerIF /IN/service_packages/SLEE/bin
EVENT
Continued on next page
Page 26
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 2
Configuring the SLEE, Continued
Example SLEE.cfg file (continued)
INTERFACE=acsStatsLocalSLEE acsStatsLocalSLEE
/IN/service_packages/ACS/bin EVENT
INTERFACE=Replication replicationIF.sh
/IN/service_packages/SLEE/bin EVENT
INTERFACE=hssScIf hssScIf.sh /IN/service_packages/SLEE/bin EVENT
WATCHDOG=/IN/service_packages/SLEE/bin/ watchdog
WATCHDOGCYCLETIME=30
# SLEE Process Manager (statistics collection)
#INTERFACE=sleeProcMan sleeProcMan /IN/service_packages/SLEE/bin
UDG
# APPLICATION
APPLICATION=mngApp mngApp /IN/service_packages/SLEE/bin 1 1
# SERVICE
SERVICE=ACS 1 slee_acs ACS
SERVICE=ACS_Outgoing 1 slee_acs ACS_Outgoing
# SERVICEKEY
SERVICEKEY=INTEGER 111 ACS
SERVICEKEY=INTEGER 110 ACS_Outgoing
Service Logic Execution Environment
Technical Guide
Page 27
Commercial In Confidence
Chapter 3
Tools and Utilities
Overview
Introduction
This chapter explains how to use the utilities provided with the SLEE. To
start the SLEE, see stop.sh (on page 31).
shut down the SLEE, see stop.sh (on page 31).
remove Shared Memory and semaphores, see clean (on page 32).
display what SLEE resources are in use, see check (on page 33).
create a statistics.bin file for statsIF, see sfVerify (on page 36).
Warning: All these scripts must be run from /IN/service_packages/SLEE/bin.
Unpredictable results will occur if run from elsewhere.
In this chapter
This chapter contains the following topics.
slee.sh ...........................................................................................................30
stop.sh ...........................................................................................................31
clean ..............................................................................................................32
check .............................................................................................................33
sfVerify...........................................................................................................36
Service Logic Execution Environment
Technical Guide
Page 29
Chapter 3
Commercial In Confidence
slee.sh
Purpose
slee.sh provides a standardised way of starting the SLEE.
Warning: Running this script while the SLEE is already running will result in the
SLEE becoming unstable.
Configuration
The slee.sh does not support any configuration options.
Failure
If slee.sh fails, the SLEE will not start properly. To ensure you start the SLEE in a
stable environment, complete the following before you run slee.sh again:
run stop.sh
run clean, and
ensure all SLEE processes are killed.
Output
Page 30
slee.sh writes error messages to the system messages file.
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 3
stop.sh
Purpose
The stop.sh script shuts down the SLEE in a controlled manner. This ensures the
SLEE shared memory and semaphores are cleared.
Configuration
stop.sh does not support any configuration options.
Failure
If the stop.sh script has failed, the SLEE may not have been shut down properly.
Attempt to run the stop.sh script again, and run clean to ensure all SLEE shared
memory has been properly removed and all processes have been removed.
Output
stop.sh writes error messages to the system messages file.
Service Logic Execution Environment
Technical Guide
Page 31
Chapter 3
Commercial In Confidence
clean
Purpose
The clean tool uses the Unix clean tool to remove an current SLEE shared
memory and semaphores. This must be completed if the SLEE has exited without
being shut down properly, for example if there was a network outage.
Startup
clean is started by acs_oper from the command line using the following command:
/IN/service_packages/SLEE/bin/clean
Configuration
clean does not support any configuration options.
Failure
If clean fails, SLEE Shared Memory may still exist. Attempt to rerun the script.
Output
clean writes error messages to the system messages file.
Page 32
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 3
check
Purpose
check provides a method of monitoring the SLEE. It can produce either periodic
reports or general reports.
Events
The number of events (total) reported by the check tool will not match the total
event number specified in the configuration file. This is because SLEE reserves a
set of events for exclusive use by the watchdog process. These events are used
to clean up the SLEE if a runaway process allocates all the available SLEE
resources and needs to be cleaned up. The additional number of events is
calculated as:
Extra Event = Max Dialogs * 2 + Max Application Instances * 2 + Max
Interfaces * 2
These events are added into the list with a size greater (or equal) to the default of
1024.
Configuration
check supports the following command-line options:
Usage:
check [-v] [-c|-C|-d|-D|-e|-E|-f] [-b] <delay> [<count>]
The available parameters are:
Parameter
Default
Description
-v
Includes data in event dumps.
-c
Include floating calls in the report.
-C
Display all calls in the report.
-d
Display active dialogs in the report.
-D
Display all dialogs in the report.
-e
Display floating events in the report.
-E
Display all events in the report.
-f
Display free object counts in the report.
-b
Batch mode. Only print the report header once.
<delay>
The number of seconds before the specified report
is repeated.
The number of times the report should be
repeated.
<count>
1
Note: To access the check script's reports menu (and gain access to the general
reports), run the script without the seconds variable.
Main Menu
options
To gain access to the check script's report menu, run the command line invocation
without any options.
Example: /IN/service_packages/SLEE/bin/check
Main menu options: Once you have started the check script, you will see a menu
with 10 options as shown below.
Check which type of object?
Continued on next page
Service Logic Execution Environment
Technical Guide
Page 33
Chapter 3
Commercial In Confidence
check, Continued
Main Menu options (continued)
1: Dialogs
2: Events
3: Calls
4: Services
5: Applications
6: Application Instances
7: Interface Instances
8: General Status
9: Free Objects
q: Quit
Select:
The options are executed by typing the character before the colon. This table
describes the main menu options:
Option
Description
1: Dialogs
Reports the number of open SLEE dialogs.
2: Events
Reports the number of current SLEE events.
3: Calls
Reports the number of current calls.
4: Services
Reports the number of SLEE services which are
running.
5: Applications
Reports the number of SLEE applications which are
currently running.
6: Application Instances
Reports the number of instances of SLEE applications
which are currently running.
7: Interface Instances
Reports the number of SLEE interface instances
which are currently running.
8:General Status
Reports general information and statistics about the
SLEE.
9: Free Objects
Reports the number of free objects still available in the
SLEE shared memory.
Exits from check.
q: Quit
Output
check writes reports to stdout. The different reports have different formats.
Reports will be the same whether run from the command line or the main menu
options.
Note: The number of events (total) reported by the check tool will not match the
total event number specified in the configuration file. This is because SLEE
reserves a set of events for exclusive use by the watchdog process.
check writes error messages to the system messages file.
General reports
If you choose option 8 from the menu, the check script will provide you with a
summary report of the information available from the other reports, and return you
to the menu.
Example: This is an example of a general report.
Select:
8
Continued on next page
Page 34
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 3
check, Continued
General reports (continued)
SLEE Status Report
Service:
ACS
Using application:
0xc0013d28
Service:
ACS_Outgoing
Using application:
0xc0013d28
Application:
slee_acs at 0xc0013d28
Contains the following Instances....
Instance at :
0xc0014b88
Process ID:
5493
Status: 3
Call Count:
0
Free
Free
Free
Free
Free
Free
Exiting check
Dialogs:
70000
Applications:
9
Application Instances:
Services: 8
Events:
49998
Calls:
25000
90
To exit from the check report running in periodic report mode, press Ctrl+C.
To exit from the menu choose option q.
Service Logic Execution Environment
Technical Guide
Page 35
Chapter 3
Commercial In Confidence
sfVerify
Purpose
sfVerify creates the statistics.bin file which is needed to run statsIF.
Configuration
sfVerify supports the following command-line options:
Usage:
sfVerify [-v--verbose-c--commit-f--force] [-d <path> --dir <path>]
[-o <filename> --output <filename>] [-s <KB> --size <KB>]
The available parameters are:
Parameter
Default
Description
-v
--verbose
false
Controls the amount of information output from the
program.
-c
--commit
false
Commits the changes to the stats interface. This
will only work if the SLEE is running and the stats
interface is configured. This parameter writes the
output file and then signals the stats interface to
reread the configuration file statistics.bin.
-f
--force
false
Force the commit without asking the user.
-d
--dir
stats_defn
The directory to import the statistics definitions
from.
-o
--output
-s
--size
output.defn The name of the output file.
128
The maximum size in Kb for the stats interface
output files.
Note: Any of the parameters (except the period) can either be a single word, or
specified as a quote-delimited string.
Import files
The import files for the statistics interface take the following form:
applicationName statisticName description period comment
Output
The output file used by the statistics interface is:
/IN/service_packages/SLEE/etc/statistics.bin
sfVerify writes error messages to the system messages file.
Page 36
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 4
Background Processes
Overview
Introduction
This chapter explains the processes which run automatically as part of the
application. These processes are started automatically by one of the following:
inittab
crontab, or
SLEE.
Note: This chapter also includes some plugins to background processes which do
not run independently.
In this chapter
This chapter contains the following topics.
replicationIF ...................................................................................................38
tcRelayApp ....................................................................................................39
watchdog .......................................................................................................40
Service Logic Execution Environment
Technical Guide
Page 37
Chapter 4
Commercial In Confidence
replicationIF
Purpose
replicationIF responds to slee replication events by sending data to another
machine (usually the USMS).
Startup
replicationIF is started by the following line in SLEE.cfg:
INTERFACE=replicationIF replicationIF.sh
/IN/service_packages/SLEE/bin EVENT
Configuration
replicationIF supports the following command line parameters:
replicationIF -r <node> -d <microsecs>
-r <node>
Syntax:
Description:
Type:
Optionality:
Allowed:
Default:
Example:
-r <node>
The node number of the requester node (that is, the node
number of the replicationIF itself).
Integer
Mandatory (disallowed default of 0 used if not set).
A number between 512 and 1023.
0
-r 601
-d <microsecs>
Syntax:
Description:
Type:
Optionality:
Default:
Page 38
-d <microsecs>
The number of microseconds between processing large slee
events.
Integer
Optional (default used if not set).
1000
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 4
tcRelayApp
Purpose
tcRelayApp is a SLEE application which relays TCAP primitives. This enables
SLEE interfaces to send TCAP primitives to other SLEE interfaces (particularly
TCAP IF).
You can use tcRelayApp to add destination number and originating number
information to the TCAP primitive.
Startup
tcRelayApp is started by the following line in SLEE.cfg:
APPLICATION=tcRelayApp tcRelayApp.sh /IN/service_packages/SLEE/bin
1 1
Configuration
tcRelayApp supports the following parameters in each line of
tcRelayMappings.def:
<serviceHandle> <IF name> <dest ssn> <dest pc> <dest GT> <orig ssn>
<orig pc>
The available parameters are:
Parameters
Default
Description
serviceHandle
Incoming service handler. The SLEE service
handle this message has been sent to.
(Required.)
IF name
Outgoing interface name. The SLEE
interface name the message should be
forwarded to. (Required.)
dest ssn
Destination SSN. The Destination SSN
value which the TCAP primitive should have.
(Required.)
dest pc
Destination PC. The Destination Point Code
value which the TCAP primitive should have.
(Required.)
dest gt
Destination GT. The Destination Global Title
value which the TCAP primitive should have.
(Optional, use "-" to not specify.)
orig ssn
Originating SSN. The Originating SSN value
which the TCAP primitive should have.
(Optional.)
Originating PC. The Originating PC value
which the TCAP primitive should have.
(Optional.)
orig pc
Failure
If tcRelayApp fails, TCAP primitives which must be relayed through the SLEE will
fail. If the process is not running, the SLEE watchdog will attempt to restart the
service.
Output
tcRelayApp writes error messages to the system messages file, and also writes
additional output to:
/IN/service_packages/SLEE/tmp/tcRelayApp.log
Service Logic Execution Environment
Technical Guide
Page 39
Chapter 4
Commercial In Confidence
watchdog
Purpose
The watchdog is responsible for the maintenance of the processes and ensuring
the current time of day is correct in the shared memory segment.
If it detects that either some application (or interface) has stopped processing
events it shuts it down and cleans up any dialogs associated with it.
Once everything is clean, it then restarts the failed process.
The watchdog has three timers, which run concurrently:
1
Every 10 milliseconds the current time of day is written to the shared memory
segment. If this is unsuccessful, the error code is inserted in the shared
memory so that the other SLEE processes are able to determine an error has
occurred and respond appropriately.
2 Every 100 milliseconds the watchdog scans all the SLEE processes looking at
their total event count. If this number has changed, due to the process
handling events, the process is considered VALID and no other action is taken.
If the process has not handled any events it is marked as SUSPECT and a
WATCHDOG management event is sent to the process.
3 Any SUSPECT processes are checked every WATCHDOG_CYCLE_TIME
(defaults to 30 seconds) to see if they have processed any events since the
watchdog last checked. If they have, the process is added back on to the
VALID list and handled normally. Otherwise the process is aborted and
restarted.
Another responsibility for the watchdog is keeping track of SLEE resource usage.
If the resource drops below 80% of the start value, a warning is raised alerting the
user to the error. A notice is posted when the value rises back up to 70% of the
start value. The watchdog keeps track of the resource usage for the dialog, call
instance and event lists.
When the watchdog begins a check loop, it starts a timer running to ensure that it
will not remain deadlocked on a semaphore forever. If the timer expires the
watchdog will restart the SLEE.
Startup
watchdog is started by the following line in SLEE.cfg:
APPLICATION=tcRelayApp tcRelayApp.sh /IN/service_packages/SLEE/bin
1 1
Configuration
watchdog accepts the following configuration options from the SLEE.cfg file.
These are set at installation and should not need changing.
This section defines the location and cycle time for the watchdog. You should not
need to alter these settings.
WATCHDOG=/IN/service_packages/SLEE/bin/ watchdog
WATCHDOGCYCLETIME=30
The available parameters are:
Parameters
Default
Description
30
The path and binary filename for the
watchdog executable.
The number of seconds between checks
on SUSPECT processes. For more
information about SUSPECT processes,
see Purpose (on page 40).
WATCHDOG
WATCHDOGCYCLETIME
Continued on next page
Page 40
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 4
watchdog, Continued
Failure
If the watchdog fails, SLEE processes will not be monitored. This will mean SLEE
processes are not restarted if they fail. You must restart the SLEE. For more
information about restarting the SLEE, see Tools and Utilities (on page 29).
Output
watchdog writes error messages to the system messages file.
Service Logic Execution Environment
Technical Guide
Page 41
Commercial In Confidence
Chapter 5
Troubleshooting
Overview
Introduction
This chapter explains the important processes on each of the server components
in the OCNCC, and a number of example troubleshooting methods which will help
aid the troubleshooting process before raising a Support Ticket.
In this chapter
This chapter contains the following topics.
Common Troubleshooting Procedures ......................................................... 44
Possible Problems.........................................................................................46
Service Logic Execution Environment
Technical Guide
Page 43
Chapter 5
Commercial In Confidence
Common Troubleshooting Procedures
Introduction
Refer to the NCC System Administrator's Guide for troubleshooting procedures
common to all OCNCC components.
Checking current
processes
You can check which processes are running using the standard UNIX command:
ps. To find processes being run by Oracle software, you can grep for the string
'oper', which will display all processes being run by the application operator
accounts (for example, acs_oper, ccs_oper and smf_oper).
Note: Some processes which are required for proper functioning may be run by
other users, including root or the user which runs the webserver.
Example command: ps -ef | grep oper
For more information about the ps command, see the system documentation for
the ps command.
You can also check how much of the processor a process is using by running the
standard UNIX tool: top. If you have some baseline measurements, you will be
able to compare it with the current load.
Example command: top
Tip: Some processes should only have one instance. If there are two or more
instances, this may indicate a problem. For example, there will usually only be
one timerIF running on each UAS.
For more information about which processes should be running on each node,
check the Process List for each node in Installation.
Checking
installed
packages
To check the details of an installed package, use the pkginfo command.
Example command: pkginfo -l smsSms
Example output: This is an example of the output of the example command above.
PKGINST:
NAME:
CATEGORY:
ARCH:
VERSION:
VENDOR:
PSTAMP:
INSTDATE:
EMAIL:
STATUS:
FILES:
smsSms
Oracle smsSms
application
sun4u
3.1.0
Oracle
smsNode20041020104925
Oct 20 2004 13:15
support@oracle.com
completely installed
348 installed pathnames
39 directories
89 executables
152448 blocks used (approx)
For more information about the pkginfo utility, see the system documentation.
Checking network Network connectivity will affect any process which requires communication
connectivity
between two different network addresses.
Network connectivity should support ssh sessions between the two machines
experiencing the problem.
Continued on next page
Page 44
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 5
Common Troubleshooting Procedures, Continued
Checking network connectivity (continued)
If you can open an ssh session between the two machines, check the following
before contacting Level 1 support with details:
If the address of either of the machines specified in the Node Management
screens is a hostname, check that the hostnames used in the ssh sessions
are the hostnames specified in the Node Management screen.
If you cannot ssh, check the following before contacting Level 1 support with
details:
Check that the hostname is resolving correctly in the DNS.
Check that the physical network connection is working correctly.
Check that the inetd and sshd are running.
Check that sshd is listening on the expected port.
Check that the smf_oper and acs_oper accounts are not locked, and that the
username and password combinations being used are correct.
Checking
configuration
files
One of the significant areas where faults can occur and be remedied is in the
configuration of processes. Configuration files can be edited by any standard text
editor. A backup of the existing configuration file should always be taken before
editing a configuration file.
For more information about the configuration files used in this application, see
Configuration.
For more information about the configuration file for a specific program or tool, see
the section named after the binary in question.
Service Logic Execution Environment
Technical Guide
Page 45
Chapter 5
Commercial In Confidence
Possible Problems
Introduction
This topic lists common problems and actions which can be taken to investigate or
solve them. This list enables you to check for alarms based on the overall
behavior you are experiencing.
SLEE failing on
startup
This table describes possible reasons why the SLEE may be failing to startup:
Page 46
Reason
Remedy
Alarms
sleeStartup could not parse
the SLEE.cfg file.
Check that the SLEE.cfg file exists
in the expected location and that it
can be read.
Check that the syntax of the file is
correct.
For more information about the
SLEE.cfg file, see Configuration
(on page 13).
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 6
Pre-installation
Overview
Introduction
This chapter explains the pre-installation configuration requirements of the
application.
In this chapter
This chapter contains the following topics.
Installation Pre-requisites ..............................................................................48
Setting the Time Zone ...................................................................................49
Service Logic Execution Environment
Technical Guide
Page 47
Chapter 6
Commercial In Confidence
Installation Pre-requisites
Introduction
This topic provides a list of the pre-requisites for the installation of the SLEE.
For details on the installation of the required system software, refer to the
installation and set-up documentation supplied with the software.
Warning: It is highly recommended that you understand the replication process and
have sketched a possible replication set-up before installing any software.
Checking
partition space
Ensure that there is enough space in the / directory for the installation to proceed.
All machines
This table describes the third party or layered software which should have been
installed on the machine as part of installing SMS. It is also required for SLEE.
By default, IN is created in this partition.
Note: While either version 9 or 10 of Solaris and Oracle can be used, a Solaris 9
installation must have version 9 of Oracle. Similarly, an installation with Solaris 10,
can only have version 10 Oracle.
Software
Version
Description
Solaris
9 or later
10 or later
SUN operating system
Oracle
9.2.0 or later
10 or later
9.2.0.4
Oracle DBMS
Patch
Solaris Enterprise Edition
You must have version 3.0.0 or later of the Service Management System package
installed on this machine before SLEE will work. For details about which version
of the software is required, see the rlease notes for the SLEE package you are
installing.
Checking
software on
Solaris
Check that your Solaris version is correct. The version required is listed under the
machine names in this topic.
Example commands: You can check your Solaris version by using the commands:
uname -r, and
pkginfo
For more information about finding out your Solaris version, see your Solaris
documentation.
Checking Oracle
application
versions - cmn
Use the pkginfo utility to check the versions of Oracle application packages on
each node.
For more information about:
which versions are required, see the list under the machine name in this topic.
using pkginfo, see Checking installed packages (on page 44).
Page 48
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 6
Setting the Time Zone
Setting timezones All SLEE machines and users must run in the GMT timezone. Unless a time-zone
to GMT
is specified in the user's .profile, it will use the default timezone which is specified
in the following file:
/etc/TIMEZONE
For all accounts to default to the GMT timezone, this file must contain the line
TZ=GMT. If you change this file, it is recommended that you restart the machine
to ensure that all accounts are in the correct timezone.
We suggest running time synchronisation software such as NTP daemons and
servers.
Checking the time Follow these steps to verify that a UNIX system has time zones configured
zone
correctly for the operation of screens and Discounts.
Step
Action
1
2
Log onto the machine you want to check the time zone of.
Type env | grep TZ
Result: This command should return:
TZ = GMT
This indicates that the time zone directory is set to GMT.
Service Logic Execution Environment
Technical Guide
Page 49
Commercial In Confidence
Chapter 7
Installation
Overview
Introduction
This chapter explains how to install the application.
In this chapter
This chapter contains the following topics.
Installation Procedure Overview ...................................................................52
Loading the Distribution File ..........................................................................53
Installing the SLEE package .........................................................................54
Checking the Installation ...............................................................................56
Service Logic Execution Environment
Technical Guide
Page 51
Chapter 7
Commercial In Confidence
Installation Procedure Overview
Introduction
On the Sun platform, the SLEE is installed in in a single package on each machine
other than SMPs.
Packages are installed using the pkgadd utility.
SLEE installation
process overview
This table describes the steps involved in installing SLEE packages for both
clustered and unclustered platforms.
Step
Action
1
The SLEE distribution file must be loaded onto the SCP. For more
information, see Loading the Distribution File (on page 53).
The SLEE package must be installed on the SCP. This is done using
the pkgadd utility.
2
Page 52
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 7
Loading the Distribution File
Introduction
Before you can install the application packages, you must load them in an
installation directory on the correct machines. This procedure copies and registers
packages from the distribution file on to the system.
You must repeat this procedure on every machine. If your application packages
have already been loaded, you do not have to complete this procedure.
Installation
directory
This procedure copies the distribution file into the /tmp directory. The installation
procedure assumes that the /tmp directory has been used.
Procedure
Follow these steps to load the distribution file.
Step
Action
1
Ensure you are logged onto the machine as root.
2
Copy the distribution file into the /tmp directory.
The application's distribution file will be distributed on either CD or from
an FTP location. If you do not either have a CD or know the correct FTP
location, please contact your Oracle contact.
The packages are often distributed in one large compressed file (for
example, sms.tar.gz).
3
Check whether the distribution file is compressed (zipped).
You can usually determine this by the file extension: .gz or .tgz will mean
the file is compressed. Occasionally, the file extension will be incorrect,
or the file will fail to uncompress or untar. If it is available, you can use
the file command to attempt to determine the type of file by checking its
contents.
If the distribution file is:
not compressed, go to Step 4.
compressed, uncompress the file.
Example commands:
gunzip <filename>, or
4
gzip –d <filename>
Where:
<filename> is the distribution file
Result: This uncompresses the distribution file.
If the distribution file is:
.pkg file, no further actions are required to load the distribution file.
a tar ball, untar the distribution.
Example command: tar –xvf <filename>
Where:
<filename> is the uncompressed distribution file.
Result: Untarring unzips the packages into the /tmp directory and will
create an install sub-directory.
Service Logic Execution Environment
Technical Guide
Page 53
Chapter 7
Commercial In Confidence
Installing the SLEE package
Introduction
Use this procedure to install the SLEE package on any non-USMS machine in a
clustered or unclustered installation.
This process uses the pkgadd utility to install the package. When the install is
complete, the utility automatically runs the post-install script.
Sample SLEE
script
The table below provides a sample of the text displayed during a SLEE package
install.
Script Output
Action
# pkgadd -d `pwd` SLEE
Type this command to start the
installation.
Processing package instance <SLEE> from </tmp>
Indicates the package you are
installing and the location you
are installing it from.
SLEE Installation
(sun4u) 3.2.0.7
Oracle
Indicates the version of the
software you are installing.
## Processing package information.
Notices provided for
informational purposes.
## Processing system information.
## Verifying disk space requirements.
## Checking for conflicts with packages already
installed.
## Checking for setuid/setgid programs.
The utility will check if there are
any conflicts between existing
files and the files which the utility
will install. If there are any
conflicts, they will be listed.
The following files are being installed with setuid
and/or setgid permissions:
/IN/service_packages/SLEE/bin/su_remove.sh <setuid
root setgid other>
Do you want to install these as setuid/setgid files
[y,n,?,q]
This package contains scripts which will be executed
with super-user permission during the process of
installing this package.
Do you want to continue with the installation of
<SLEE> [y,n,?]
Type y to continue the
installation. If you type anything
else the script will abort.
Type y to start the installation. If
you type anything else the script
will abort.
Continued on next page
Page 54
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 7
Installing the SLEE package, Continued
Sample SLEE script (continued)
Script Output
Action
Installing SLEE Installation as <SLEE>
## Executing preinstall script.
## Installing part 1 of 1.
/IN/service_packages/SLEE/bin/alarmIF
/IN/service_packages/SLEE/bin/cdrIF
This output indicates that the
installation process is starting. It
will display a list of all files which
are being installed in the bin, etc
and and lib directories.
Note that full list is not shown
here, to save space.
/IN/service_packages/SLEE/bin/check
...
/IN/service_packages/SLEE/lib/libStatusEvent.so
/usr/lib/secure/libSLEE.so <symbolic link>
[ verifying class <none> ]
## Executing postinstall script.
Installation of <SLEE> was successful.
Installing
additional
packages
Notices provided for
informational purposes.
Installation completed. No
action is required.
No other packages are required on this machine to complete the installation of the
SLEE.
Service Logic Execution Environment
Technical Guide
Page 55
Chapter 7
Commercial In Confidence
Checking the Installation
Introduction
Refer to these checklists to ensure that SLEE has installed correctly.
Checklist
Follow these steps in this checklist to ensure the SLEE has been installed on the
UAS machine correctly.
Step
Action
1
Log onto the machine as root.
2
Check the following directory structure exists with subdirectories:
/IN/service_packages/SLEE
Check both directories contain subdirectories and that all are owned by:
root user (group other)
3
Page 56
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Chapter 8
Removal
Overview
Introduction
This chapter explains how to remove the application.
In this chapter
This chapter contains the following topics.
Removing Packages .....................................................................................58
Service Logic Execution Environment
Technical Guide
Page 57
Chapter 8
Commercial In Confidence
Removing Packages
Introduction
Use the pkgrm utility to remove the SLEE from an SCP.
Before you begin
The pkgrm utility will delete the entire package directory. Please check the
/IN/service_packages/SLEE directory for any files you wish to keep.
Important: If you are storing any critical files there, please move them before
starting these procedures.
Removing the
SLEE package
Page 58
Follow these steps to remove the SLEE package from an SCP.
Step
Action
1
2
Ensure you are logged into the SCP as root.
Use the pkgrm utility to remove the SLEE package.
Example command: pkgrm SLEE
Result: This removes this package and the configuration entries.
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
Appendix
Overview
In this appendix
This appendix contains the following topics.
Glossary of Terms ......................................................................................... 61 Index .............................................................................................................. 65
Service Logic Execution Environment
Technical Guide
Page 59
Commercial In Confidence
Glossary of Terms
ACS
Advanced Control Services configuration platform.
API
Application Programming Interface
C7
See SS7.
CC
Country Code. Prefix identifying the country for a numeric international address.
CCS
1) Charging Control Services (or Prepaid Charging) component.
2) Common Channel Signalling. A signalling system used in telephone networks
that separates signalling information from user data.
CDR
Call Detail Record
Note: The industry standard for CDR is EDR (Event Detail Record). Over time
EDR will replace CDR in the Oracle documentation.
Connection
Transport level ink between two peers, providing for multiple sessions.
cron
Unix utility for scheduling tasks.
crontab
File used by cron.
FTP
File Transfer Protocol - protocol for electronic transfer of files
GPRS
General Packet Radio Service - employed to connect mobile cellular users to PDN
(Public Data Network- for example the Internet).
GT
Global Title.
The GT may be defined in any of the following formats:
Type 1: String in the form "1,<noa>,<BCD address digits>"
Type 2: String in the form "2,<trans type><BCD address digits>"
Type 3: String in the form "3,<trans type>,<num plan>,<BCD address digits>"
Type 4: String in the form "4,<trans type>,<num plan>,<noa>,<BCD address
digits>"
The contents of the Global Title are defined in the Q713 specification, please refer
to section 3.4.2.3 for further details on defining Global Title.
HLR
The Home Location Register is a database within the HPLMN (Home Public Land
Mobile Network). It provides routing information for MT calls and SMS. It is also
responsible for the maintenance of user subscription information. This is
distributed to the relevant VLR, or SGSN (Serving GPRS Support Node) through
the attach process and mobility management procedures such as Location Area
and Routing Area updates.
HPLMN
Home PLMN
Service Logic Execution Environment
Technical Guide
Page 61
Commercial In Confidence
HTML
HyperText Markup Language, a small application of SGML used on the World
Wide Web.
It defines a very simple class of report-style documents, with section headings,
paragraphs, lists, tables, and illustrations, with a few informational and
presentational items, and some hypertext and multimedia.
IN
Intelligent Network
INAP
Intelligent Network Application Part - a protocol offering real time communication
between IN elements.
ISDN
Integrated Services Digital Network - set of protocols for connecting ISDN stations.
ISUP
ISDN User Part - part of the SS7 protocol layer and used in the setting up,
management, and release of trunks that carry voice and data between calling and
called parties.
LNP
Local Number Portability
MM
Messaging Manager.
MSISDN
Mobile Station ISDN number. Uniquely defines the mobile station as an ISDN
terminal. It consists of three parts; the country code (CC), the national destination
code (NDC) and the subscriber number (SN).
MT
Mobile Terminated
MTP
Message Transfer Part (part of the SS7 protocol stack).
Oracle
Oracle Corporation
PC
Point Code. The Point Code is the address of a switching point.
PLMN
Public Land Mobile Network
SCCP
Signalling Connection Control Part (part of the SS7 protocol stack).
SCP
Service Control Point. Also known as UAS.
Service Provider
See Telco.
SGML
Standard Generalized Markup Language. The international standard for defining
descriptions of the structure of different types of electronic document.
SGSN
Serving GPRS Support Node
SLEE
Service Logic Execution Environment
SMP
Service Management Platform (also referred to as USMS).
SMS
Short Message Service.
SN
Service Number
Page 62
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
SS7
A Common Channel Signalling system used in many modern telecoms networks
that provides a suite of protocols which enables circuit and non circuit related
information to be routed about and between networks. The main protocols include
MTP, SCCP and ISUP.
SSN
Subsystem Number. An integer identifying applications on the SCCP layer.
SSP
Service Switching Point
Switching Point
Anything that can send and receive C7 messages.
System
Administrator
The person(s) responsible for the overall set-up and maintenance of the IN.
TCAP
Transaction Capabilities Application Part – layer in protocol stack, message
protocol.
Telco
Telecommunications Provider. This is the company that provides the telephone
service to customers.
Telecommunicati
ons Provider
See Telco.
UAS
Universal Application Server - hardware on which applications run.
UBE
Universal Billing Engine for Oracle Communications Network Control and
CharginOracle Communications Network Control and Oracle Communications
Network Control and Charging.
USMS
Universal Service Management System hardware platform.
VLR
Visitor Location Register - contains all subscriber data required for call handling
and mobility management for mobile subscribers currently located in the area
controlled by the VLR.
VPN
The Virtual Private Network product is an enhanced services capability enabling
private network facilities across a public telephony network.
Service Logic Execution Environment
Technical Guide
Page 63
Commercial In Confidence
Index
A C,(continued)
About this Document
Audience • v
Pre-requisites • v
Related documents • v
Scope • v
ACS • vii
alarmIF • 7
All machines
Installation Pre-requisites • 48
API • 4
appEventCount • 26
Application • 4
APPLICATION • 15, 22, 24, 25, 26
Configuring the SLEE • 24
Application instance • 4
Main Components of the SLEE • 5
Application Instance • 4
Application Programming Interface
Introduction • 9
Management Events • 9
SLEE Dialogs • 9
SLEE Events • 9
Supported management events • 10
APPLICATION_END • 10
APPLICATION_KILL • 10
Applications • 4
Main Components of the SLEE • 5
appName • 22, 24
Audience
About this Document • v
check • 6, 17, 29
Configuration • 33
Events • 33
Exiting check • 35
General reports • 34
Main Menu options • 33
Output • 34
Purpose • 33
Checking configuration files
Common Troubleshooting Procedures • 45
Checking current processes
Common Troubleshooting Procedures • 44
Checking installed packages • 48
Common Troubleshooting Procedures • 44
Checking network connectivity
Common Troubleshooting Procedures • 44
Checking Oracle application versions - cmn
Installation Pre-requisites • 48
Checking partition space
Installation Pre-requisites • 48
Checking software on Solaris
Installation Pre-requisites • 48
Checking the Installation
Checklist • 56
Introduction • 56
Checking the time zone
Setting the Time Zone • 49
Checklist
Checking the Installation • 56
clean • 6, 29
Configuration • 32
Failure • 32
Output • 32
Purpose • 32
Startup • 32
Common Troubleshooting Procedures
Checking configuration files • 45
Checking current processes • 44
Checking installed packages • 44
Checking network connectivity • 44
Introduction • 44
Component
Application • 4
Application Instance • 4
cdrIF.cfg • 14
Environmental variables • 14
Interface • 4
Interface Handle • 4
Service • 4
Service Handle • 4
Service Key • 4
SLEE API • 4
B -b • 33
Before you begin
Removing Packages • 58
C -c • 33
-C • 33
-c --commit • 36
C7 • 63
CALL_INSTANCE_ TIMED_OUT • 11
CALL_INSTANCE_KILL • 11
callCount • 23
CC • 62
CCS • vii
CDR • 8
cdrIF • 8
cdrIF.cfg • 14
Service Logic Execution Environment
Technical Guide
Page 65
Commercial In Confidence
C,(continued)
E SLEE shared memory • 4
SLEE tools • 4
SLEE.cfg • 4, 14
tcRelayMappings.def • 14
watchdog • 4
Configuration • 14, 46
check • 33
clean • 32
replicationIF • 38
sfVerify • 36
slee.sh • 30
stop.sh • 31
tcRelayApp • 39
watchdog • 40
Configuration components
Configuration Overview • 14
Configuration Overview
Configuration components • 14
Configuration process overview • 14
Introduction • 14
Configuration process overview
Configuration Overview • 14
Configuring the SLEE • 4, 14
APPLICATION • 24
Example SLEE.cfg file • 26
INTERFACE • 18
Introduction • 15
Maximum values • 15
Modifying SLEE.cfg • 15
Optional environmental variables • 15
Other parameters • 18
SERVICE entries • 21
SERVICEKEY • 23
watchdog • 20
Connection • 62
cron • 61
crontab • 37
-e • 33
-E • 33
EDR • 61
Entity relationship
Main Components of the SLEE • 5
Environmental variables • 14
Event
APPLICATION_END • 10
APPLICATION_KILL • 10
CALL_INSTANCE_ TIMED_OUT • 11
CALL_INSTANCE_KILL • 11
DIALOG_CLOSED • 10
DIALOG_TIMED_OUT • 11
INTERFACE_END • 10
INTERFACE_KILL • 10
REPORT_REQUEST • 11
REREAD_CONFIG • 10
SERVICE_DISABLED • 10
SERVICE_ENABLED • 10
STATUS_REQUEST • 11
STATUS_RESPONSE • 11
WATCHDOG • 10
Events
check • 33
Example • 19, 20, 24, 25, 26
Example interfaces
SLEE Interfaces • 7
Example setup
Introduction to the Service Logic Execution
Environment • 3
Example SLEE.cfg file
Configuring the SLEE • 26
Examples • 21, 22, 23, 24
execDir • 25
execName • 25
Exiting check
check • 35
D F -d • 33
<microsecs> • 38
-D • 33
-d --dir • 36
dest • 21, 24
DIALOG_CLOSED • 10
DIALOG_TIMED_OUT • 11
dialogCount • 20
Document Conventions
Icons • vi
Terminology • vii
Typographical conventions • vi
-f • 33
-f --force • 36
Failure
clean • 32
slee.sh • 30
stop.sh • 31
tcRelayApp • 39
watchdog • 41
FTP • 53
Functionality for hosted services
Introduction to the Service Logic Execution
Environment • 2
Functionality overview
Introduction to the Service Logic Execution
Environment • 2
Page 66
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
G I,(continued)
General reports
check • 34
GPRS • 61
GT • 39
Interfaces • 4
Main Components of the SLEE • 6
interfaceType • 19
intEventCount • 20
Introduction
Application Programming Interface • 9
Checking the Installation • 56
Common Troubleshooting Procedures • 44
Configuration Overview • 14
Configuring the SLEE • 15
Installation Pre-requisites • 48
Installation Procedure Overview • 52
Installing the SLEE package • 54
Introduction to the Service Logic Execution
Environment • 2
Loading the Distribution File • 53
Main Components of the SLEE • 4
Possible Problems • 46
Removing Packages • 58
SLEE Interfaces • 7
Introduction to the Service Logic Execution
Environment
Example setup • 3
Functionality for hosted services • 2
Functionality overview • 2
Introduction • 2
Service logic support • 2
ISDN • 62
ISUP • 63
H HLR • 6
HPLMN • 61
HTML • vi
I Icons
Document Conventions • vi
ifHandle • 19, 24
Import files
sfVerify • 36
IN • v
INAP • 6
Installation directory
Loading the Distribution File • 53
Installation Pre-requisites
All machines • 48
Checking Oracle application versions - cmn
• 48
Checking partition space • 48
Checking software on Solaris • 48
Introduction • 48
Installation Procedure Overview
Introduction • 52
SLEE installation process overview • 52
Installing additional packages
Installing the SLEE package • 55
Installing the SLEE package
Installing additional packages • 55
Introduction • 54
Sample SLEE script • 54
Interface • 4
alarmIF • 7
cdrIF • 8
replicationIF • 8
statsIF • 7
timerIF • 7
INTERFACE • 18, 19, 20
Configuring the SLEE • 18
Interface communication through dialogs
SLEE Interfaces • 7
Interface handle • 4
Main Components of the SLEE • 6
Interface Handle • 4
INTERFACE_END • 10
INTERFACE_KILL • 10
interfaceName • 19
interfacePath • 19
Service Logic Execution Environment
Technical Guide
K keyType • 23
L LNP • 6
Loading the Distribution File • 52
Installation directory • 53
Introduction • 53
Procedure • 53
M Main Components of the SLEE
Application instance • 5
Applications • 5
Entity relationship • 5
Interface handle • 6
Interfaces • 6
Introduction • 4
Service • 6
Service handles • 6
Service keys • 6
SLEE shared memory • 4
SLEE tools • 6
Page 67
Commercial In Confidence
M,(continued)
P,(continued)
Main Menu options
check • 33
Management Events
Application Programming Interface • 9
MAXAPPLICATIONS • 15
MAXCALLS • 17
MAXDIALOGS • 16, 17
MAXEVENTTYPES • 18
Maximum values
Configuring the SLEE • 15
maxInstances • 26
MAXSERVICEHANDLES • 16, 21
MAXSERVICEKEYS • 16, 18
MAXSERVICES • 16
MM • 2
Modifying SLEE.cfg
Configuring the SLEE • 15
MSISDN • vii
MT • 61
MTP • 63
-o --output • 36
-s --size • 36
-v • 33
-v --verbose • 36
Parameters
<size> • 17
appEventCount • 26
appName • 22, 24
callCount • 23
-d <microsecs> • 38
dest • 24
dialogCount • 20
execDir • 25
execName • 25
ifHandle • 19
interfaceName • 19
interfacePath • 19
interfaceType • 19
intEventCount • 20
keyType • 23
MAXAPPLICATIONS • 15
MAXCALLS • 17
MAXDIALOGS • 16, 17
MAXEVENTTYPES • 18
maxInstances • 26
MAXSERVICEHANDLES • 16
MAXSERVICEKEYS • 16, 18
MAXSERVICES • 16
NOWIPESOCKETS • 18
priority • 21
-r <node> • 38
serviceHandle • 22
serviceKey • 23
serviceName • 21
SLEE_FILE • 15
startInstances • 25
PC • 39
PLMN • 61
Possible Problems
Introduction • 46
SLEE failing on startup • 46
Pre-requisites
About this Document • v
priority • 21
Procedure
Loading the Distribution File • 53
Purpose • 40
check • 33
clean • 32
replicationIF • 38
sfVerify • 36
slee.sh • 30
stop.sh • 31
tcRelayApp • 39
watchdog • 40
N NOWIPESOCKETS • 18
O -o --output • 36
Optional environmental variables • 5, 14
Configuring the SLEE • 15
Oracle • ii
Other parameters
Configuring the SLEE • 18
Output
check • 34
clean • 32
sfVerify • 36
slee.sh • 30
stop.sh • 31
tcRelayApp • 39
watchdog • 41
P Parameter
<count> • 33
<delay> • 33
-b • 33
-c • 33
-C • 33
-c --commit • 36
-d • 33
-D • 33
-d --dir • 36
-e • 33
-E • 33
-f • 33
-f --force • 36
Page 68
Service Logic Execution Environment
Technical Guide
Commercial In Confidence
R S,(continued)
-r
sfVerify • 7, 29
Configuration • 36
Import files • 36
Output • 36
Purpose • 36
SGML • 62
SGSN • 61
Sink • 7
SLEE • v
SLEE API • 4
SLEE Dialogs
Application Programming Interface • 9
SLEE Events
Application Programming Interface • 9
SLEE failing on startup
Possible Problems • 46
SLEE installation process overview
Installation Procedure Overview • 52
SLEE Interfaces
Example interfaces • 7
Interface communication through dialogs •
7
Introduction • 7
Types of interface • 7
SLEE shared memory • 4
Main Components of the SLEE • 4
SLEE tools • 4
Main Components of the SLEE • 6
SLEE.cfg • 4, 14
slee.sh • 6
Configuration • 30
Failure • 30
Output • 30
Purpose • 30
SLEE_FILE • 15
SMP • 5
SMS • vi
SN • 62
Source • 7
SS7 • 6
SSN • 39
SSP • 6
startInstances • 25
Startup
clean • 32
replicationIF • 38
tcRelayApp • 39
watchdog • 40
statsIF • 7
STATUS_REQUEST • 11
STATUS_RESPONSE • 11
<node> • 38
Related documents
About this Document • v
Removing Packages
Before you begin • 58
Introduction • 58
Removing the SLEE package • 58
Removing the SLEE package
Removing Packages • 58
replicationIF • 8
Configuration • 38
Purpose • 38
Startup • 38
REPORT_REQUEST • 11
REREAD_CONFIG • 10
S -s --size • 36
Sample SLEE script
Installing the SLEE package • 54
SCCP • 63
Scope
About this Document • v
SCP • 52
Server • 7
Service • 4
Main Components of the SLEE • 6
SERVICE entries • 16, 21, 22, 23, 24
Configuring the SLEE • 21
Service Handle • 4
Service handles • 4
Main Components of the SLEE • 6
Service Key • 4
Service keys • 4
Main Components of the SLEE • 6
Service logic support
Introduction to the Service Logic Execution
Environment • 2
Service Provider • vii
SERVICE_DISABLED • 10
SERVICE_ENABLED • 10
serviceHandle • 22
serviceKey • 23
SERVICEKEY • 6, 16, 21, 23, 24
Configuring the SLEE • 23
serviceName • 21, 24
Setting the Time Zone
Checking the time zone • 49
Setting timezones to GMT • 49
Setting timezones to GMT
Setting the Time Zone • 49
Service Logic Execution Environment
Technical Guide
Page 69
Commercial In Confidence
S,(continued)
W stop.sh • 6, 29
Configuration • 31
Failure • 31
Output • 31
Purpose • 31
Supported management events
Application Programming Interface • 10
Switching Point • 63
Symbolic names
<microsecs> • 38
<node> • 38
<size> • 17
System Administrator • 44
watchdog • 4, 20
Configuration • 40
Configuring the SLEE • 20
Failure • 41
Output • 41
Purpose • 40
Startup • 40
WATCHDOG • 10
T TCAP • 6
tcRelayApp
Configuration • 39
Failure • 39
Output • 39
Purpose • 39
Startup • 39
tcRelayMappings.def • 14
Telco • 62
Telecommunications Provider • 63
Terminology
Document Conventions • vii
timerIF • 7
Tool
check • 6
clean • 6
slee.sh • 6
stop.sh • 6
Tools and Utilities • 15, 41
Type
Server • 7
Sink • 7
Source • 7
Types of interface
SLEE Interfaces • 7
Typographical conventions
Document Conventions • vi
U UAS • 44
UBE • 2
USMS • 38
V -v • 33
-v --verbose • 36
VLR • 61
VPN • 5
Page 70
Service Logic Execution Environment
Technical Guide