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