Transaction Capabilities Application Part (TCAP) of SS7 protocol stack application.

Transaction Capabilities

Transaction Capabilities (TC) provides support for interactive applications in a distributed environment through a generic remote procedure call service. TC provides the framework for invoking remote procedures and returning the results of these procedures.

Figure 1-1 shows the structure of TC using SS7 network services. TC is composed of two sublayers; the Component Sublayer (CSL) and the Transaction Sublayer (TSL). The CSL deals with components which are the Application Protocol Data Units (APDU) that convey remote operations and their responses. The CSL optionally may utilize the dialogue portion protocol for conveying information related to application context or user information. The TSL deals with the exchange of messages containing components and optionally, a dialogue portion, between TC-Users.

Figure 1-1: TC in SS7

Open Systems Interconnection (OSI)

TC is based on the Remote Operations concept defined in Recommendation X.880 (ROS). TC allows communication between TC-Users across an SS7 network. This communication can be modeled with the OSI seven layer stack as shown in Figure-2.1. SS7 does not define an Intermediate Services Part (ISP) so the Presentation, Session and Transport layers are formally missing however some aspects of the these are present in TC. CSL lies entirely within the application layer.

Figure 2-1: TC in OSI

Figure-2.2 shows the structure of the OSI Application Layer. An Application Process (AP) consists of application code within and outside the OSI framework. The part of an application which resides in the OSI framework is called an Application Entity (AE). The AE may contain a number of cooperating components, each with it's own protocol elements. These components are called Application Service Elements (ASE). An ASE is a separately defined (standardized) part of an Application Entity. ASEs provide a service to higher level ASEs not a higher level layer. The distinction being that unlike layer services an ASE service may consider only part of the communication between Application Entities.

Figure 2-2: OSI Application Process

The Component sublayer is in partial alignment with the capabilities of the Remote Operation Service Element (ROSE) X.219 and X.229. The X.229 protocol is contained within the TC component protocol. CSL includes some extensions to ROSE. The dialogue control facilities are in partial alignment with the capabilities of the Association Control Service Element (ACSE) X.217 and X.227. The abstract syntax for the dialogue control APDUs are a subset of the OSI ACSE abstract syntax.

Figure-2.3 shows an Application Process with an Application Entity which includes the Transaction Capabilities ASE and the Mobile Application Part ASE.

Figure 2-3: SS7 Application Process

An Application Entity (AE) is the part of your Application Process (AP) which uses the services of a combined set of ASEs. An AE-Type defines a set of functions used for communications. For example one AE-Type may combine a TC ASE with a MAP ASE while another combines a TC ASE with an INAP ASE. An AE Invocation (AEI) is an instance of an AE and it's ASEs.

An AEI may perform a subset of the communication functions defined by the AE-Type. The actual procedures that may need to be performed for an instance of communication are determined by the Application Context (AC). The Application Context states which functions are needed. Based on this information the AEI is instantiated from the AE-Type which fits these criteria.

Using the tcap application you will implement your Application Process (AP) and Application Entity (AE) in Erlang. The set of processes which make up an instance of the Component Sublayer (CSL) form the TC ASE. For each new dialogue an AEI including a TC ASE and a TC-User ASE (e.g. MAP) is created. The AE uses the ASEs together to provide higher level functions to the AP.

Figure 3-1: AE Invocations

For example you may have an AE which uses TCAP and MAP ASEs implemented in a gen_statem callback module named ae_map_v3. An AEI for a location update could be created as:

1> gen_statem:start_link(ae_map_v3, ['networkLocUpContext-v3', TSL], [])

Where 'networkLocUpContext-v3' is the application context name and TSL is a reference to the transaction sublayer used for this operation. The callback module would start TC and MAP and coordinate them to provide the location update service to the Application Program.

-module(ae_map_v3).
-export([init/1]).
-behaviour(gen_statem).
-record(state, {ac, tsl, csl, map}).

init([AC, TSL]) ->
    case tcap:open(TSL, self(), []) of
        {ok, CSL} ->
            case map:open(CSL, self(), []) of
                {ok, MAP} ->
                    Data = #state{ac = AC, tsl = TSL, csl = CSL, map = MAP},
                    {ok, idle, Data};
                Error ->
                   Error
            end;
         Error ->
            Error
    end.

In ASN.1 an OPERATION-PACKAGE type is used to define an ASE. An APPLICATION-CONTEXT type defines an AC. An application protocol is defined by the set of all possible ACs. The above example uses these definitions from the 3GPP/GSM MAP specification:

networkLocUpContext-v3 APPLICATION-CONTEXT ::= {
    -- Responder is HLR if Initiator is VLR
    INITIATOR CONSUMER OF {locationUpdatingPackage-v3 | dataRestorationPackage-v3}
    RESPONDER CONSUMER OF {subscriberDataMngtPackage-v3 | tracingPackage-v3}
    ID                    {map-ac networkLocUp(1) version3(3)}
}
locationUpdatingPackage-v3 OPERATION-PACKAGE ::= {
    -- Supplier is HLR if Consumer is VLR
    CONSUMER INVOKES      {updateLocation}
    SUPPLIER INVOKES      {forwardCheckSs-Indication}
}
updateLocation OPERATION ::= { --Timer m
    ARGUMENT              UpdateLocationArg
    RESULT                UpdateLocationRes
    ERRORS                {systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber | roamingNotAllowed}
    CODE                  local:2
}

In a complex AE there may be multiple TC-User ASEs. The operation codes (e.g. local:2 for the updateLocation above) of the received components allow the AE to distribute to the appropriate ASE. While the locationUpdatingPackage-v3 definition above appears informally in the current specifications MAP is still viewed as having a single Application Service Element for historical reasons. The Intelligent Network Application Protocol (INAP) however clearly defines many distinct ASEs. Figure 3-2 shows the configuration of an AEI for INAP using the scf-to-ssf-status-reporting-v1 AC.

Figure 3-2: Example INAP AEI

Addressing

When used with SS7 network services the addressing of the Signaling Connection Control Part (SCCP) is used. The SCCP CalledParty and CallingParty address formats are used in the TCAP address parameters; Destination Address and Originating Address. These parameters identify the destination and originating TC-user.

The SCCP Subsystem Number (SSN) is used by SCCP for message distribution to separate instances of the TCAP Transaction Sublayer (TSL).

Figure 4-1: SSN Distribution

Process Communication

A number of processes interact to provide the TCAP service. Figure 5-1 depicts the message paths between processes used with the TCAP application.

The TCAP protocol layer is split into two sublayers; the Transaction Sublayer (TSL) and the Component Sublayer (CSL).

In the transaction sublayer a transaction coordinator (TCO) process performs marshalling of incoming indications from the SCCP service access point (SAP). It spawns a transaction state machine (TSM) for each new transaction.

In the component sublayer a dialogue handler (DHA) process is started for each transaction. It then spawns a component coordinator process (CCO). For a remotely initiated transaction DHA is started by TCO. For a locally initiated transaction DHA is started by the TC-User. An invocation state machine (ISM) is started for each locally invoked operation involved in the transaction.

Figure 5-1: Process Communication

Supervision Hierarchy

The processes which make up an instance of the TCAP service layer are all instantiated within a supervision tree. When the application is started a top level tcap_sup supervisor is created with a tcap_csl_sup child supervisor. The user may call start_tsl/3 to create a new transaction sublayer (TSL) for each SCCP service access point (SAP). A tcap_tsl_sup supervisor is started with one worker TCO and a supervisor for dynamically added TSM workers.

Figure 5-2 shows the structure of the supervision hierarchy.

For every new transaction ID assigned (Begin indication or request) TCO (tcap_tco_server) starts a TSM (tcap_tsm_fsm) by dynamically adding it to the tcap_transaction_sup supervisor. In the case of a Unidirectional primitive no transaction is assigned and no TSM is started.

TCO also starts a tcap_dialogue_sup supervisor, by dynamically adding it to the tcap_csl_sup supervisor, when a Begin or Unidirectional primitive is received.

When a tcap_dialogue_sup supervisor is started it creates a DHA (tcap_dha_fsm) worker and a (tcap_components_sup) supervisor with one CCO (tcap_cco_server) worker and a tcap_invocation_sup supervisor.

An ISM (tcap_ism_fsm) worker is dynamically added to the tcap_invocation_sup supervisor for each locally invoked operation.

Figure 5-2: Process Supervision

Distribution

In order to facilitate scalable systems the TC service layer may be decomposed with the TSL and CSL sublayers distributed across nodes. Figure 6-1 shows an example of an AP having AEIs distributed across several remote Erlang nodes to accomplish load distribution. The AE includes an ASE for CAMEL Application Part (CAP) and an ASE for TCAP implemented with the CSL.

Figure 6-1: Process Distribution

When the TSL is created with start_tsl/3 the tcap_tco_server behaviour callback module exports a start_aei/2 callback function used to start an Application Entity Instance (AEI) which includes a CSL instance. The AEI may be created at a remote node by dynamically adding a child of a tcap_csl_sup supervisor in the tcap application running on that node.

Primitives (ITU)

The communication between layers is defined in ITU-T recommendations using "primitives". The information content is specified but not a specific encoding. ITU-T Q.771 provides the primitives for TCAP. In the tcap application tuples of the form provided below are sent as messages between processes. The Parameters are represented using primitive specific records.

TC-User → Component Sublayer

Dialogue Handling

{'TC', 'UNI', request, Parameters}
{'TC', 'BEGIN', request, Parameters}
{'TC', 'CONTINUE', request, Parameters}
{'TC', 'END', request, Parameters}
{'TC', 'U-ABORT', request, Parameters}

Component Handling

{'TC', 'INVOKE', request, Parameters}
{'TC', 'RESULT-L', request, Parameters}
{'TC', 'RESULT-NL', request, Parameters}
{'TC', 'U-ERROR', request, Parameters}
{'TC', 'U-CANCEL', request, Parameters}
{'TC', 'U-REJECT', request, Parameters}

Component Sublayer → TC-User

Dialogue Handling

{'TC', 'UNI', indication, Parameters}
{'TC', 'BEGIN', indication, Parameters}
{'TC', 'END', indication, Parameters}
{'TC', 'U-ABORT', indication, Parameters}
{'TC', 'P-ABORT', indication, Parameters}
{'TC', 'NOTICE', indication, Parameters}

Component Handling

{'TC', 'INVOKE', indication, Parameters}
{'TC', 'RESULT-L', indication, Parameters}
{'TC', 'RESULT-NL', indication, Parameters}
{'TC', 'U-ERROR', indication, Parameters}
{'TC', 'L-CANCEL', indication, Parameters}
{'TC', 'L-REJECT', indication, Parameters}
{'TC', 'R-REJECT', indication, Parameters}
{'TC', 'U-REJECT', indication, Parameters}
{'TC', 'TIMER-RESET', indication, Parameters}

Component Sublayer → Transaction Sublayer

{'TR', 'UNI', request, Parameters}
{'TR', 'BEGIN', request, Parameters}
{'TR', 'CONTINUE', request, Parameters}
{'TR', 'END', request, Parameters}
{'TR', 'U-ABORT', request, Parameters}

Transaction Sublayer → Component Sublayer

{'TR', 'UNI', indication, Parameters}
{'TR', 'BEGIN', indication, Parameters}
{'TR', 'CONTINUE', indication, Parameters}
{'TR', 'END', indication, Parameters}
{'TR', 'U-ABORT', indication, Parameters}
{'TR', 'P-ABORT', indication, Parameters}
{'TR', 'NOTICE', indication, Parameters}

Transaction Sublayer → SCCP

{'N', 'UNITDATA', request, Parameters}

SCCP → Transaction Sublayer

{'N', 'UNITDATA', indication, Parameters}
{'N', 'NOTICE', indication, Parameters}