The Signalware TCAP stack implementation for CGIN consists of two parts:
-
a Java "frontend" library, deployed on each Rhino node as part of the CGIN RA; and
-
a C++ "backend" executable, run within the Signalware platform environment, that is linked against the Signalware TCAP library.
Frontend - backend processes
It works like this:
-
Each frontend establishes TCP/IP connections to all configured backends.
-
The Signalware platform receives incoming TCAP traffic from the network,
... and directs that traffic to the appropriate backend process. -
The backend performs basic TCAP processing, using the Signalware TCAP library,
... and passes the results to a frontend deployed in a Rhino node. -
The frontend library then passes this data to the CGIN Unified RA.
-
The CGIN Unified RA performs protocol-specific decoding to produce SLEE events,
... and fires those events to Rhino. -
In Rhino, SLEE services process those events,
... and send outgoing TCAP traffic to the CGIN Unified RA. -
The CGIN Unified RA performs protocol-specific encoding,
... and passes TCAP data to the frontend. -
The frontend passes that data to the appropriate backend process for the dialog.
-
The backend passes the TCAP data to the Signalware TCAP library.
-
The Signalware TCAP library then passes the resulting encoded data to the Signalware platform.
-
And the Signalware platform sends that data to the network.
|
Frontends and backends for each resource adaptor entity
For a single resource adaptor entity configured in Rhino, there will be one or more frontends (one per Rhino node), and one or more backends (as configured in the Signalware deployment). All the backends associated with a particular resource adaptor entity have an identical configuration — multiple backends in this case are only needed for performance and redundancy reasons; they are otherwise equivalent. |
