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 specific Oracle Communications Convergent Charging Controller network or service implications of the product.
Introduction to SLEE TCAP Interfaces
Introduction
The Oracle SIGTRAN TCAP Interface is a SLEE interface that enables the SLEE to inter-work with a TCAP Protocol stack.
The interface converts messages arriving from the TCAP Protocol stack and converts them into SLEE events. The SLEE events are then sent to the application which is configured to handle the call. The SIGTRAN TCAP Interface also converts SLEE events coming from a SLEE application back into a form the TCAP Protocol stack can understand.
For more information about SLEE events and applications, see SLEE Technical Guide.
Service routing and message correlation
The SIGTRAN TCAP Interface also has a role in routing calls to services on the platform.
It routes the message setting one of the following:
- The SLEE service key for the message
- A correlation ID which matches the message to one sent to the SLEE earlier (in this case, the second message will use the same service key as the first)
TCAP Protocol stack
A TCAP Protocol stack is a software implementation of a networking protocol suite. It involves a group of protocols working together to allow Oracle platform software and hardware to communicate with a telecommunications network.
The protocols are:
- TCAP
- underlying protocols such as SCCP/MTP or SUA/SCTP/IP
The hardware is Network Interface Cards on an applicable high-performance server-based platform.
The networks typically support Intelligent Network-type Signaling Control and other associated or similar functions.
TCAP Interface layers
The SIGTRAN TCAP Interface used in a specific installation will depend on the requirements of the network and the type of physical interface and network protocols used.
Generally, the SIGTRAN TCAP Interface which will be installed is built from underlying layers of smaller protocol stacks which sit below the TCAP layer. These layers may be comprised of TCP/IP or SIGTRAN protocols (SUA/SCCP/M3UA). They may be provided and supported by Oracle and/or third party vendors.
SCCP Level TCAP Interfaces
Introduction
The SIGTRAN TCAP Interface stack can be used to translate to a third party SCCP/SUA implementation.
SIGTRAN/SUA interface components
This table describes the main components in the SUA version of the SIGTRAN TCAP Interface.
| Process | Role | Further information |
| sua_if |
Interface between the SLEE and the network. Note: This process includes the SIGTRAN libraries which interface to the network. |
sua_if . |
| SLEE | Real-time interface between the interfaces and applications which have been configured to communicate through the SLEE. | Service Logic Execution Environment Technical Guide. |
| sua_if.sh | Shell Startup script used to set the command line parameters for configuring sua_if. | Configuration Overview . |
| tcapif.def | Optional configuration file for sua_if. Can be used to set some command line parameters. | Configuring tcapif.def . |
| sigtran.config | Main configuration file for sua_if. | Configuring sigtran.config . |
| sccp_YYYYMMDD_hhmm.log | The SCCP-level message log file. | log . |
M3UA Level TCAP Interfaces
Introduction
The SIGTRAN TCAP stack can be used to translate to a third party SCCP/M3UA implementation.
SIGTRAN m3ua interface components
This table describes the main components in the M3UA version of the SIGTRAN TCAP Interface.
| Process | Role | Further information |
| m3ua_if |
Interface between the SLEE and the network. Note: This process includes the SIGTRAN libraries which interface to the network. |
m3ua_if . |
| SLEE | Real-time interface between the interfaces and applications which have been configured to communicate through the SLEE. | Service Logic Execution Environment Technical Guide. |
| m3ua_if.sh | Shell Startup script used to set the command line parameters for configuring m3ua_if. | Configuration Overview . |
| tcapif.def | Optional configuration file for sua_if. Can be used to set some command line parameters. | Configuring tcapif.def . |
| sigtran.config | Main configuration file for m3ua_if. | Configuring sigtran.config . |
| sccp_YYYYMMDD_hhmm.log | The SCCP-level message log file. | log . |
Routing to Services
Introduction
When the SIGTRAN TCAP Interface receives a new TCAP message (TC-BEGIN), it determines what SLEE service key it should use when sending the message on. SLEE service keys are used by the SLEE to determine where to route the message to. For more information about how SLEE routes calls, see SLEE Technical Guide.
Note: If the message is an assistRequestInstructions, sua_if/m3ua_if will send the message to the SLEE with a correlation ID. The SLEE will then route based on only correlation ID. For more information about correlation IDs and how they are processed, see Correlation IDs .
Routing process
This table describes how SIGTRAN TCAP Interface constructs the SLEE service key for an incoming message.
| Stage | Description |
|---|---|
| 1 | TC-BEGIN arrives at sua_if/m3ua_if. |
| 2 |
sua_if/m3ua_if determines which protocol the message is using by matching the SSN the message arrived from to the ssn details in its command line or tcapif.def configuration. For more information about setting which SSNs correspond to which protocols, see tcapif parameters . |
| 3 | If the protocol is INAP, sua_if/m3ua_if will check whether the operation is assistRequestInstructions. If it is, it will set a correlation ID in the message and send it to the SLEE. No further action is taken. |
| 4 | If the protocol is not INAP, or it is INAP but the operation is an InitialDP, sua_if/m3ua_if will construct the SLEE service key. |
| 5 | sua_if/m3ua_if sends the message on to the SLEE, where it will be routed according to the rules defined for service keys in SLEE.cfg. |
SLEE service key construction
The SLEE service key constructed by sua_if/m3ua_if is made up from the following elements:
| Byte | MSB 8 | 7 | 6 | 5 | 4 | 3 | 2 | LSB 1 | ||||||||||||||
| Sourced from | Base service key value defined by sleekey . | Dest SSN (SCCP) |
Depends on the protocol of incoming message:
|
|||||||||||||||||||
| Example 1 |
0x1
|
0xd0
|
00000009
|
|||||||||||||||||||
| Example 2 |
0x123456
|
0x05
|
fffffffe
|
|||||||||||||||||||
Note: The base service key (bytes 6-8) is not padded with leading zeros. Bytes 1 to 4, and byte 5 are padded with leading zeros.
Example SLEE service keys
Example 1:
If sua_if/m3ua_if is using the default base key of 0x1, and the TC-BEGIN has INAP SSN = 13 (that is, 0xd) and service key = 8: the SLEE service key will be 0x10d00000008.
The message can then be routed to INAPService1 on App1 by the following lines in SLEE.cfg:
SERVICEKEY=INTEGER 0x10d00000008
INAPService1SERVICE=INAPService1 1 App1 INAPService1Example 2:
If sua_if/m3ua_if is using a non-default base key of 0x1234, and the TC-BEGIN has INAP SSN = 112 (that is, 0x70) and service key = 10: the SLEE service key will be 0x12347000000010.
The message can then be routed to INAPService2 on App2 by the following lines in SLEE.cfg:
SERVICEKEY=INTEGER 0x12347000000010
INAPService2SERVICE=INAPService2 1 App2 INAPService2Example 3:
If sua_if/m3ua_if is using the default base key of 0x1, and the TC-BEGIN has MAP SSN = 5 and operation ID = 5: the SLEE service key will be 0x10500000005.
The message can then be routed to MAPService on App2 by the following lines in SLEE.cfg:
SERVICEKEY=INTEGER 0x10500000005 MAPServiceSERVICE=MAPService
1 App2 MAPServiceCorrelation IDs
In some circumstances, a message arriving at sua_if/m3ua_if will need to be matched to an earlier message. For example, when a play announcement node has requested an Intelligent Peripheral to play a message to a caller, and the IP is reporting the result of the action.
In this case, the second message received by sua_if/m3ua_if (sent by the IP) will be an INAP AssistRequestInstructions (ARI) operation, and will contain a correlation ID. sua_if/m3ua_if will attempt to initiate a SLEE dialog using the correlation ID instead of a service key. The correlation ID will be a decimal conversion of the digits from the ARI's correlationID parameter.
Matching SLEE correlation IDs
These are the steps involved in matching correlation IDs.
| Stage | Description |
|---|---|
| 1 | On an SLC, an InitialDP is sent across the SLEE. (Usually sent by an interface such as sua_if/m3ua_if to a service application such as slee_acs). The SLEE assigns it a call ID. |
| 2 |
The SLEE service application which received the InitialDP requests the SLEE to assign a correlation ID to the InitialDP. The SLEE allocates a correlation ID and returns it to the SLEE service application. |
| 3 | The SLEE service application sends an INAP ETC operation over the SLEE to an interface. The operation contains the Address of an external network entity and the correlation ID. |
| 4 | The interface sends the operation o the switch which forwards it to the remote entity specified in the Address (usually an Intelligent Peripheral). |
| 5 | The remote entity sends the interface on the SLC an INAP TC-BEGIN containing an AssistRequestInstructions (ARI) and the original correlation ID. |
| 6 |
When sua_if/m3ua_if receives the ARI, it initiates a new SLEE dialog using the correlation ID. The correlation ID is matched to the call ID assigned in Stage 1, and the same service key routing rules are applied (this means the ARI will be delivered to the SLEE service application which sent the ETC). The correlation ID must be read from within the TCAP component which holds the conveyed protocol's first message. |
| 7 | The SLEE service application receives the message with the call ID assigned to the InitialDP and correlates the messages. |
For an example of how correlation IDs are used by ACS when playing announcements, see Advanced Control Services Technical Guide.