Contents of Section 7.4
7.4 Services assumed from TCAP
7.4.1 Normal procedures
7.4.1.1 SSF-to-SCF messages
7.4.1.1.1 SSF FSM related messages
7.4.1.1.2 Assisting/Hand-off SSF FSM related messages
7.4.1.1.3 SSME FSM related messages
7.4.1.2 SCF-to-SSF messages
7.4.1.2.1 SCSM FSM related messages
7.4.1.2.2 SCME FSM related messages
7.4.1.3 SCF-to/from-SRF messages
7.4.2 Abnormal procedures
7.4.2.1 SCF-to-SSF/SRF messages
7.4.2.2 SSF/SRF-to-SCF messages
7.4.3 Dialogue establishment
7.4.3.1 Sending of a TC-BEGIN request primitive
7.4.3.2 Receipt of a TC-BEGIN indication
7.4.3.3 Receipt of the first TC-CONTINUE indication
7.4.3.4 Receipt of a TC-END indication
7.4.3.5 Receipt of a TC-U-ABORT indication
7.4.3.6 Receipt of a TC-P-ABORT indication
7.4.4 Dialogue continuation
7.4.4.1 Sending entity
7.4.4.2 Receiving entity
7.4.5 Dialogue termination
7.4.5.1 Sending of TC-END request
7.4.5.2 Receipt of a TC-END indication
7.4.6 User Abort
7.4.6.1 Sending of TC-U-ABORT request
7.4.6.2 Receipt of a TC-U-ABORT indication
7.4.7 Provider Abort
7.4.7.1 Receipt of a TC-P-ABORT indication
7.4.8 Procedures for INAP operations
7.4.8.1 Operation invocation
7.4.8.2 Operation invocation receipt
7.4.8.3 Operation Response
7.4.8.4 Receipt of a response
7.4.8.4.1 Receipt of TC-RESULT-NL indication
7.4.8.4.2 Receipt of TC-RESULT-L indication
7.4.8.4.3 Receipt of TC-U-ERROR indication
7.4.8.4.4 Receipt of TC-U-REJECT indication
7.4.8.4.5 Receipt of a TC-L-REJECT indication
7.4.8.4.6 Receipt of a TC-L-CANCEL indication
7.4.8.5 Other events
7.4.8.5.1 Receipt of a TC-U-REJECT
7.4.8.5.2 Receipt of a TC-R-REJECT indication
7.4.8.5.3 Receipt of a TC-L-REJECT indication
7.4.8.5.4 Receipt of a TC-NOTICE ndication
7.4.9 Mapping on to TC services
7.4.9.1 Dialogue control
7.4.9.1.1 Destination address
7.4.9.1.2 Originating address
7.4.9.1.3 Dialogue Id
7.4.9.1.4 Application-context-name
7.4.9.1.5 User information
7.4.9.1.6 Component present
7.4.9.1.7 Termination
7.4.9.1.8 Quality of service
7.4.9.2 Operation procedures
7.4.9.2.1 Invoke Id
7.4.9.2.2 Linked Id
7.4.9.2.3 Dialogue Id
7.4.9.2.4 Class
7.4.9.2.5 Operation
7.4.9.2.6 Error
7.4.9.2.7. Parameters
7.4.9.2.8 Time out
7.4.9.2.9 Last component
7.4.9.2.10 Problem code

7.4.1 Normal procedures

This subclause describes the procedures and TCAP primitives that shall be used for transmitting messages between SSF, SCF, SRF, and SDF under normal operation.
The INAP, as TC-user, uses only the structured dialogue facility provided by TCAP. The following situations can occur when a message is sent between two physical entities:

a dialogue shall be established: the TC-user issues a TC-BEGIN request primitive;

a dialogue shall be maintained: the TC-user issues a TC-CONTINUE request primitive;

a dialogue shall no longer be maintained: the TC-user issues a TC-END request primitive with either basic end or with pre-arranged end depending on the following conditions:

Basic End

Operations, leading to a termination of the control relationship, can be transmitted by the SCF with a TC-END request primitive (basic) in case the SCF is not interested in the reception of any ERROR or REJECT components for these sent operations.
Once the SCF dialogue resources have been released any ERROR or REJECT components received for these sent operations will be discarded by TC as described in ETS 300 287 [11] (ITU-T Recommendation Q.774).

In case the SCF entity has received an operation, leading to the termination of the control relationship, a TC-END request primitive (basic) with zero components can be sent from the SCF.

Pre-arranged End
In case, an entity is interested in possible ERROR or REJECT messages on response to sent operations leading to a termination of the control relationship, the dialogue is ended with a TC-END request primitive (pre-arranged end) after the last associated operation timer expires. The receiving entity shall end the dialogue with a TC-END request primitive (basic or pre-arranged end) after successful processing of these operations (i.e. the control relationship is terminated).

a dialogue shall not be established: for class 2 or 4 operations only the sending TC-user issues a TC-BEGIN request primitive and ends the dialogue locally after operation timeout by means of a prearranged end. Upon reception of the TC-BEGIN indication primitive the receiving TC-user shall end the dialogue locally.

7.4.1.1.1 SSF FSM related messages

A dialogue shall be established when the SSF FSM moves from the state Trigger Processing to the state Waiting for Instructions. The relevant INAP operation, which can only be the InitialDP operation, shall be transmitted in the same message.
For all other operations sent from the SSF FSM, the dialogue shall be maintained.
The dialogue shall no longer be maintained when the prearranged end condition is met in the SSF. When the SSF FSM makes a state transition to the state Idle, the dialogue is locally ended by means of a TC-END request primitive with prearranged end.
When the SSF has sent the last EventReportBCSM, ApplyChargingReport or CallInformationReport the dialogue may be ended from the SCF by a TC-END request primitive with basic end.

7.4.1.1.2 Assisting/Hand-off SSF FSM related messages

A dialogue shall be established when the Assisting/Hand-off SSF FSM moves from the state Idle to the state Waiting for Instructions. The AssistRequestInstructions operation shall be transmitted with a TC-BEGIN request primitive.
For all other operations sent from the Assisting/Hand-off SSF FSM, the dialogue shall be maintained.
The dialogue shall no longer be maintained when the prearranged end condition is met in the SSF. When the SSF FSM makes a state transition to the state Idle, the dialogue is locally ended by means of a TC-END request primitive with prearranged end.

7.4.1.1.3 SSME FSM related messages

The following procedures shall be followed:

the dialogue shall be maintained when the ActivityTest Return Result is sent;

no dialogue shall be established when the ServiceFilteringResponse operation is sent. The operation is sent with a TC-BEGIN request primitive and the dialogue is ended by means of a TC-END request primitive with prearranged end;

a dialogue shall no longer be maintained when the Return Result of the ActivateServiceFiltering operation is sent. The dialogue is ended by means of a TC-END request primitive with basic end, the Return Result is transmitted with the same request;

the dialogue is locally terminated by means of a TC-END request primitive with prearranged end, upon reception of a TC-BEGIN indication primitive with a CallGap operation.

7.4.1.2.1 SCSM FSM related messages

A dialogue shall be established when the SCSM FSM moves from state Idle to state Preparing SSF Instructions and an InitiateCallAttempt operation is sent to the SSF.
For subsequent operations sent from the SCSM FSM, the dialogue shall be maintained, i.e. all other operations are sent after a dialogue was established from the SSF (the SCF has previously received a TC-BEGIN indication primitive with either an InitialDP or an AssistRequestInstructions operation).
The dialogue shall no longer be maintained when the prearranged end condition is met in the SCF. When the SCF does not expect any messages other than possibly REJECT or ERROR messages for the operations sent and when the last associated operation timer expires, the dialogue is locally ended by means of a TC-END request primitive with prearranged end.
Alternatively, the sending of operations, leading to the termination of the control relationship, by means of a TC-END request primitive (basic end) is possible.

7.4.1.2.2 SCME FSM related messages

The operations sent from the SCME FSM shall be issued according to the following procedures:

the dialogue shall be maintained when the ActivityTest operation is sent;

a dialogue shall not be established when a CallGap operation is sent without using a SCSM associated dialogue. The operation is sent using a TC-BEGIN request primitive and the dialogue is terminated with a prearranged end;

for sending one or more CallGap operations, the SCME FSM may use an existing SCSM FSM associated dialogue which was initiated by a SSF FSM (i.e. established for the transmission of the InitialDP operation). The dialogue shall be maintained and the CallGap operation(s) shall be sent with the first response of the SCSM FSM to the InitialDP operation;

a dialogue shall be established when an ActivateServiceFiltering operation is sent. The operation shall be transmitted with a TC-BEGIN request primitive;

the dialogue is locally terminated upon reception of a ServiceFilteringResponse operation using a TC-END request primitive with prearranged end.

A dialogue is established when the SRF sends an AssistRequestInstructions operation to the SCF. For all other operations sent from the SRF, the dialogue shall be maintained.
The dialogue shall no longer be maintained when the prearranged end condition is met in both the SRF and SCF. When the SRSM FSM makes a state transition to the state Idle, the dialogue is locally ended by means of a TC-END request primitive with prearranged end.
When the SCF does not expect any messages other than possibly REJECT or ERROR messages for the operations sent and when the last associated operation timer expires, the dialogue is locally ended by means of a TC-END request primitive with prearranged end.
Alternatively, the SCF can send the last operation to the SRF with a TC-END request primitive (basic end) when the SCF does not expect any further messages and is no longer interested in any possible error and reject messages.
In the relay case, the SRF-SCF relationship uses the SSF-SCF TCAP dialogue. This is possible, because begin and end of the SRF-SCF relationship are embedded in the SSF-SCF relationship. SRF-SCF information shall be exchanged with TC-CONTINUE request primitives.

7.4.2 Abnormal procedures

This subclause describes the procedures and TCAP primitives that shall be used for reporting abnormal situations between SSF, SCF, SRF, and SDF. The error cases are defined in subclause 7.2.
The following primitives shall be used to report abnormal situations:

operation errors, as defined in the Core INAP, are reported with TC-U-ERROR request primitive;

rejection of a TCAP component by the TC-user shall be reported with TC-U-REJECT request primitive;

a dialogue shall be aborted by the TC-user with a TC-U-ABORT request primitive.

Considering that both SSF and SRF do not have the logic to recover from error cases detected on the SCF-SSF/SRF interface, the following shall apply:

operation errors and rejection of TCAP components shall be transmitted to the SSF respectively SRF with a TC-END request primitive, basic end.

Operation errors and rejection of TCAP components shall be transmitted to the SCF according to the following rules:

the dialogue shall be maintained when the preceding message, which contained the erroneous component, indicated that the dialogue shall be maintained. I.e. the error or reject shall be transmitted with a TC-CONTINUE request primitive if the erroneous component was received with a TC-CONTINUE indication primitive;

on receipt of an ERROR or REJECT component the SCF decides on further processing. It may either continue, explicitly end or abort the dialogue;

in all other situations the dialogue shall no longer be maintained. I.e. the error or reject shall be transmitted with a TC-END request primitive, basic end, if the erroneous component was received with a TC-BEGIN indication primitive.

The establishment of an INAP dialogue involves two application processes as described in subclause 4.3, one that is the dialogue-initiator and one that is the dialogue-responder.
AC negotiation may not be supported in all physical entities and/or all networks.
This procedure is driven by the following signals:

a TC-BEGIN request primitive from the dialogue-initiator;

a TC-BEGIN indication primitive occurring at the responding side;

the first TC-CONTINUE indication primitive occurring at the initiating side or under specific conditions:

a TC-END indication primitive occurring at the initiating side;

a TC-U-ABORT indication primitive occurring at the initiating side;

a TC-P-ABORT indication primitive occurring at the initiating side.

Before issuing a TC-BEGIN request primitive, SACF shall store the AC-name and if present the user-information parameter.
SACF shall request the invocation of the associated operations using the TC-INVOKE service. See subclause 7.4.8 for a description of the invocation procedure.
After processing of the last invocation request, SACF shall issue a TC-BEGIN request primitive.
The requesting side SACF then waits for a TC indication primitive and will not issue any other requests, except a TC-U-ABORT request or a TC-END request with the release method parameter set to "pre-arranged release".
If no TC indication primitive is expected because no dialogue is to be established according to the rules as stated in subclauses 7.4.1 and 7.4.2, SACF will wait for the last associated TCAP operation timer to expire and issue a TC-END request with the release method parameter set to "pre-arranged release".

7.4.3.2 Receipt of a TC-BEGIN indication

On receipt of a TC-BEGIN indication primitive, SACF shall:

analyse the application-context-name included in the primitive and if it is supported, process any other indication primitives received from TC as described in subclause 7.4.8.

On receipt of the first TC-CONTINUE indication primitive for a dialogue, SACF shall check the value of the application-context-name parameter. If this value matches the one used in the TC-BEGIN request primitive, SACF shall process the following TC component handling indication primitives as described in subclause 7.4.8, otherwise it shall issue a TC-U-ABORT request primitive.

7.4.3.4 Receipt of a TC-END indication

On receipt of a TC-END indication primitive in the dialogue initiated state, SACF shall check the value of the application-context-name parameter. If this value matches the one used in the TC-BEGIN request primitive then the SACF shall process the following TC component handling indication primitives as described in subclause 7.4.8, otherwise it shall not be processed.

7.4.3.5 Receipt of a TC-U-ABORT indication

Receipt of a TC-U-ABORT indication primitive is described as part of user abort procedure (see subclause 7.4.6.2).
If the abort reason is application-context-name not supported, the responding side may propose an alternative application-context-name in the TC-U-ABORT indication. If an alternative application context is proposed the receiving entity shall check this name and if it can be supported a new dialogue may be established.

7.4.3.6 Receipt of a TC-P-ABORT indication

Receipt of a TC-P-ABORT indication primitive is described as part of provider abort procedure (see subclause 7.4.7.1).

7.4.4 Dialogue continuation

Once established the dialogue is said to be in a continuation phase.
Both application processes can request the transfer of INAP APDUs until one of them requests the termination of the dialogue.

7.4.4.1 Sending entity

SACF shall process any component handling request primitives as described in subclause 7.4.8.
After processing the last component handling request primitive, SACF shall issue a TC-CONTINUE request primitive.

7.4.4.2 Receiving entity

On receipt of a TC-CONTINUE indication primitive SACF shall accept zero, one or several TC component handling indication primitives and process them as described in subclause 7.4.8.

7.4.5 Dialogue termination

Both the dialogue-initiator and the dialogue-responder have the ability to request the termination of a dialogue when no dialogue is to be established or when a dialogue is no longer to be maintained according to the rules as stated in subclauses 7.4.1 and 7.4.2.
The dialogue termination procedure is driven by the following events:

a TC-END request primitive;

a TC-END indication primitive.

When the dialogue shall no longer be maintained, SACF shall process any component handling request primitives as described in subclause 7.4.8
After processing the last component handling request primitive (if any), SACF shall issue a TC-END request primitive with the release method parameter set to "basic end" or "prearranged release", according to the rules as stated in subclauses 7.4.1 and 7.4.2.
When no dialogue is to be established, refer to subclauses 7.4.3.1 and 7.4.3.2.

7.4.5.2 Receipt of a TC-END indication

On receipt of a TC-END indication primitive, the SACF shall accept any component handling indication primitives and process them as described in subclause 7.4.8.
After processing the last component handling primitive all dialogue related resources are released.

7.4.6 User Abort

Both the dialogue-initiator and the dialogue-responder have the ability to abort a dialogue at any time.
The user abort procedure is driven by one of the following events:

a TC-U-ABORT request primitive;

a TC-U-ABORT indication primitive.

After issuing a TC-U-ABORT request primitive, all dialogue related resources are released.

7.4.6.2 Receipt of a TC-U-ABORT indication

On receipt of a TC-U-ABORT indication all dialogue related resources are released.

7.4.7 Provider Abort

TC has the ability to abort a dialogue at both the dialogue-initiator side and the dialogue-responder side.
The provider abort procedure is driven by the following event:

a TC-P-ABORT indication primitive.

On receipt of a TC-P-ABORT indication, all dialogue related resources are released.

7.4.8 Procedures for INAP operations

This subclause describes the procedures for INAP operations.

7.4.8.1 Operation invocation

SACF shall build an operation argument from the parameters received and request the invocation of the associated operation using the TC-INVOKE procedure. If a linked ID parameter is inserted in the primitive this indicates a child operation and implies that the operation is linked to a parent operation.

7.4.8.2 Operation invocation receipt

On receipt of a TC-INVOKE indication primitive, SACF shall:

if the invoke ID is already in use by an active operation, request the transfer of a reject component using the TC-U-REJECT request primitive with the appropriate problem code (duplicated invokeID);

if the operation code does not correspond to an operation supported by the application-context, request the transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate problem code (unrecognized operation);

if a linked ID is included, perform the following checks: If the operation referred to by the linked ID does not allow linked operations or if the operation code does not correspond to a permitted linked operation, or if the parent operation invocation is not active, issue a TC-U-REJECT request primitive with the appropriate problem code (linked response unexpected or unexpected linked operation);

if the type of the argument is not the one defined for the operation, request the transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped parameter);

if the operation cannot be invoked because the dialogue is about to be released, requests the transfer of a reject component using the TC-U-REJECT request primitive with the problem code (Initiating Release);

if sufficient INAP related resources are not available to perform the requested operation, request the transfer of a reject component using the TC-U-REJECT request primitive with the problem code (Resource Limitation);

otherwise, accept the TC-INVOKE indication primitive. If the operation is to be user confirmed, SACF waits for the corresponding response.

For user confirmed operations, SACF shall:

if no error indication is included in the response to a class 1 or 3 operation, construct a result information element from the parameters received and request its transfer using the TC-RESULT-L service;

if an error indication is included in the response to a class 1 or 2 operation, construct an error parameter from the parameters received and request its transfer using the TC-U-ERROR request primitive.

7.4.8.4.1 Receipt of TC-RESULT-NL indication

On receipt of a TC-RESULT-NL indication, SACF shall:

request the transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped parameter).

On receipt of a TC-RESULT-L indication, SACF shall:

if the type of the result parameter is not the one defined for the result of this operation, request the transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped parameter);

otherwise, accept the TC-RESULT-L indication primitive.

On receipt of a TC-U-ERROR indication, SACF shall:

if the error code is not defined for the SACF or is not one associated with the operation referred to by the invoke identifier, request the transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate problem code (unrecognized error or unexpected error);

if the type of the error parameter is not the one defined for this error, request the transfer of a reject component using the TC-U-REJECT request primitive, with the appropriate problem code (mistyped parameter);

otherwise, accept the TC-U-ERROR indication primitive.

On receipt of a TC-U-REJECT indication primitive which affects a pending operation, SACF shall accept the TC-U-REJECT indication primitive.

7.4.8.4.5 Receipt of a TC-L-REJECT indication

This event occurs when the local TC detects a protocol error in an incoming component which affects an operation.
On receipt of a TC-L-REJECT indicating "return result problem, return result unexpected", SACF shall inform the application process.
On receipt of a TC-L-REJECT indicating "return error problem, return error unexpected", SACF shall inform the application process.
Note that when the problem code indicates a general problem, it is considered that the event cannot be related to an active operation even if the invoke Id is provided by TC. This is because it is unclear whether the invoke Id refers to a local or remote invocation. The behaviour of SACF in such a case is described in subclause 7.4.8.5.3.

7.4.8.4.6 Receipt of a TC-L-CANCEL indication

On receipt of a TC-L-CANCEL indication, the SACF shall:

if the associated operation is a class 1 operation, inform the application process;

if the associated operation is a class 2 operation and no linked operations are defined for this operation, ignore the primitive;

if the associated operation is a class 2 operation and has linked operations but none of them has been invoked, inform the application process;

if the associated operation is a class 2 operation and a linked operation invocation has already been received in response to this operation, ignore the primitive
;

if the associated operation is a class 3 operation, inform the application process;

if the associated operation is a class 4 operation, ignore the primitive.

This subclause describes the behaviour of SACF on receipt of a component handling indication primitive which cannot be related to any operation or which does not affect a pending one.

7.4.8.5.1 Receipt of a TC-U-REJECT

On receipt of a TC-U-REJECT indication primitive which does not affect an active operation (i.e. indicating a return result or return error problem), it is up to the application process to abort, continue or terminate the dialogue, if not already terminated by the sending application process according to the rules as stated in subclause 7.4.2. This is also applicable for invoke problems related to a class 4 linked operation.

7.4.8.5.2 Receipt of a TC-R-REJECT indication

On receipt of a TC-R-REJECT indication (i.e. when a protocol error has been detected by the peer TC entity) which does not affect an active operation, it is up to the application process to abort, continue or terminate the dialogue, if not already terminated by the sending application process according to the rules as stated in subclause 7.4.2.

7.4.8.5.3 Receipt of a TC-L-REJECT indication

On receipt of a TC-L-REJECT indication primitive (i.e. when a protocol error has been detected by the local TC entity) which cannot be related to an active operation, it is up to the application process to continue, or to terminate the dialogue and implicitly trigger the transmission of the reject component or to abort the dialogue.

7.4.8.5.4 Receipt of a TC-NOTICE ndication

This informs the SACF that a message cannot be delivered by the Network Layer, this can only occur if the Return Option has been set (see clause 7.4.9.1.8), It is for the application process to decide whether to terminate the dialogue or retry.

7.4.9 Mapping on to TC services

7.4.9.1 Dialogue control

The TC-UNI service is not used by INAP.

7.4.9.1.1 Destination address

This parameter is set by the dialogue initiating application process, and may optionally be modified by the responding dialogue in the first backward TC-CONTINUE.

7.4.9.1.2 Originating address

This parameter is set by the dialogue initiating application process.

7.4.9.1.3 Dialogue Id

The value of this parameter is associated with the INAP invocation in an implementation dependent manner.

7.4.9.1.4 Application-context-name

The application-context-name parameter is set by SACF as defined in subclause 6.4.

7.4.9.1.5 User information

This parameter may be used by both initiating and responding application processes.

7.4.9.1.6 Component present

This parameter is used by SACF as described in ETS 300 287 [11] (ITU-T Recommendation Q.771).

7.4.9.1.7 Termination

The value of the release method parameter of the TC-END request primitive is set by SACF according to the rules as stated in subclauses 7.4.1 and 7.4.2.

7.4.9.1.8 Quality of service

The quality of service of TC request primitives is set by the SACF to the following value:

sequencing requested;

return option, this parameter is set by SACF in an implementation dependent manner.

7.4.9.2.1 Invoke Id

This parameter is set by the sending application process.

7.4.9.2.2 Linked Id

This parameter is set by the sending application process.

7.4.9.2.3 Dialogue Id

The value of this parameter is associated with the INAP invocation in an implementation dependent manner.

7.4.9.2.4 Class

The value of this parameter is set by SACF according to the type of the operation to be invoked according to subclause 6.1.

7.4.9.2.5 Operation

The operation code of a TC-INVOKE request primitive is set by the sending application process as defined in subclause 6.4.
SACF shall set the operation code of the TC-RESULT-L primitive (if required) to the same value as the one received at invocation time.

7.4.9.2.6 Error

The error parameter of the TC-U-ERROR request primitive is set by the sending application process as defined in subclause 6.4.

7.4.9.2.7. Parameters

The argument parameter of TC-INVOKE primitives is set by the sending application process as defined in subclauses 6.1 and 6.3.
The result parameter of TC-RESULT-L primitives is set by the sending application process as defined in subclauses 6.1 and 6.3.
The parameter of TC-U-ERROR primitives are set by the sending application process as defined in subclauses 6.2 and 6.3.

7.4.9.2.8 Time out

The value of this parameter is set by SACF according to the type of operation invoked.

7.4.9.2.9 Last component

This parameter is used by SACF as described in ETS 300 287 [11] (ITU-T Recommendation Q.771).

7.4.9.2.10 Problem code

This parameter is used by SACF as described in subclause 7.4.8.

INAP Contents Page