14 Services assumed from lower layers

29.0783GPPCAMEL Application Part (CAP) specificationCustomised Applications for Mobile network Enhanced Logic (CAMEL) Phase XRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

14.1 Services assumed from TC

The SS7 application layer protocol defined in this 3GPP TS, is a protocol to provide communication between a pair of application processes. In the SS7 environment this is represented as communication between a pair of application‑entities (AEs) using the TC. The function of an AE is provided by a set of application‑service‑elements (ASEs). The interaction between AEs is described in terms of their use of the services provided by the ASEs.

If AC are to be used for FE differentiation within a physical node, then the version of TC used must support the dialogue portion of TC (i.e. ETSI ETS 300 287-1 [22]).

This requirement applies to all interfaces, not just those used for internetworking.

Table 14‑1 defines which versions of TC are the minimum versions required to support the defined CAP interfaces:

Table 14‑1: Minimum TC requirements for CAP interfaces

Interface	CAP
gsmSSF – gsmSCF	White Book
gsmSRF – gsmSCF	White Book
assist gsmSSF – gsmSCF	White Book
smsSSF – gsmSCF	White Book
gprsSSF – gsmSCF	White Book

14.1.1 Common procedures

The present subclause defines the procedures and mapping which apply between CAP and TC to be used in the absence of specific procedures and mapping instructions for the specific CAP interfaces as defined in subsequent subclauses.

14.1.1.1 Normal procedures

The present subclause describes the procedures and TC primitives that shall be used for transmitting messages between AEs under normal operation.

The CAP, as TC‑user, uses only the structured dialogue facility provided by TC. The following situations can occur when a message is sent between two PE:

– 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

– In the case the dialogue is established, operations, leading to a termination of the relationship, can be transmitted by the FE with a TC‑END request primitive (basic) in the case the FE is not interested in the reception of any ERROR or REJECT components for these sent operations. Once the FE dialogue resources have been released, any ERROR or REJECT components received for these operations will be discarded by TC as described in ETSI ETS 300 287-1 [22].

– In the case that the dialogue is established and the FE has received an operation, leading to the termination of the relationship, does not wish to continue dialogue and there is no operation to be sent, a TC‑END request primitive (basic) with zero components can be sent from the FE.

– Pre‑arranged End

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

– in general, the use of prearranged end shall be limited to the case for both communicating entities clearly recognizable that peer entity applies prearranged end. In all other cases, basic end shall be used.

14.1.1.2 Abnormal procedures

The present subclause describes the procedures and TC primitives that shall be used for reporting abnormal situations between AEs. The error cases are defined in clause 10.

The following primitives shall be used to report abnormal situations:

– operation errors, as defined in the CAP, are reported with TC‑U‑ERROR request primitive.

– rejection of a TC component by the TC‑user shall be reported with TC‑U‑REJECT request primitive.

– when the FE detecting error or rejecting operation decides the termination of TC dialogue, TC‑END request primitive (basic) with error or reject can be used for the termination of TC dialogue.

– when the gsmSSF or the gsmSRF detecting error or rejecting operation recognizes the possibility to continue dialogue, TC‑CONTINUE request primitive with error or reject can be used for the continuation of TC dialogue.

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

on expiration of application timer Tssf or Tsrf, dialogue shall be terminated by means of by TC‑U‑ABORT primitive with an Abort reason, regardless of TC dialogue is established or not.

For abnormal situations detected by TC the same rules shall apply for reception of TC‑R‑REJECT indication as for transmission of TC‑U‑REJECT request and for transmission of TC‑P‑ABORT indication as for transmission of TC‑U‑ABORT request primitive.

The following rules shall be applied to terminate the TC dialogue under abnormal situations:

– in the case that abort condition is detected and TC dialogue is established, TC dialogue is terminated by TC‑U‑ABORT primitive with an Abort reason.

– in the case that abort condition is detected and TC dialogue is not established, TC dialogue is locally terminated by TC‑U‑ABORT primitive. (in the case such as application time out).

In error situations prearranged end shall not be used to terminate the TC dialogue. In the case any AE encounters an error situation the peer entity shall be explicitly notified of the error, if possible. If from any entity’s point of view the error encountered requires the relationship to be ended, then it shall close the dialogue via a TC‑END request primitive with basic end or via a TC‑U‑ABORT request primitive, depending on whether any pending ERROR or REJECT component is to be sent or not.

In the case an entity receives a TC‑END indication primitive and after all components have been considered, the FSM is not in a state to terminate the relationship, an appropriate internal error should be provided.

In cases when a dialogue needs to be closed by the initiating entity before its establishment has been completed (before the first TC indication primitive to the TC‑BEGIN request primitive has been received from the responding entity), the TC‑user shall issue a TC‑END request primitive with prearranged end or a TC‑U‑ABORT request primitive. The result of these primitives will be only local, any subsequent TC indication received for this dialogue will be handled in accordance with the abnormal procedures as specified in ETSI ETS 300 287-1 [22]).

When the gsmSSF, gprsSSF or smsSSF receives multiple Operation components in a single TC Message and there is an error in the processing of one of these Operations, then the gsmSSF FSM, gprsSSF FSM or smsSSF FSM shall process the error and shall discard all Operation components in that TC Message of which the processing has not yet started.

14.1.1.3 Dialogue handling

14.1.1.3.1 Dialogue establishment

The establishment of a CAP dialogue involves two application processes as described in clause 1, one that is the dialogue‑initiator and one that is the dialogue‑responder.

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

Sending of a TC‑BEGIN request

Before issuing a TC‑BEGIN request primitive, TC‑USER shall store the AC‑name and if present the user‑information parameter.

TC‑USER shall request the invocation of the associated operations using the TC‑INVOKE service. See subclause 14.1.1.4.1 for a description of the invocation procedure.

After processing of the last invocation request, TC‑USER shall issue a TC‑BEGIN request primitive.

The initiator TC‑USER 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".

Receipt of a TC‑BEGIN indication

On receipt of a TC‑BEGIN indication primitive, responder TC‑USER shall:

– Analyse the application‑context‑name included in the primitive. If it is supported, then process any other indication primitives received from TC as described in subclause 14.1.1.4.1.

– If the application‑context‑name included in the primitive is not supported, then issue a TC‑U‑ABORT request primitive.

Receipt of the first TC‑CONTINUE indication

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

Receipt of a TC‑END indication

On receipt of a TC‑END indication primitive in the dialogue initiated state, TC‑USER shall check the value of the application‑context‑name parameter. If this value match the one used in the TC‑BEGIN request primitive, then the TC‑USER shall process the following TC component handling indication primitives as described in subclause 14.1.1.4.1.

Receipt of a TC‑U‑ABORT indication

Receipt of a TC‑U‑ABORT indication primitive is described as part of user abort procedure (see 14.1.1.3.4.).

Receipt of a TC‑P‑ABORT indication

Receipt of a TC‑P‑ABORT indication primitive is described as part of provider abort procedure (see 14.1.1.3.5.).

14.1.1.3.2 Dialogue continuation

Once established the dialogue is said to be in a continuation phase.

Both application processes can request the transfer of CAP APDUs until one of them requests the termination of the dialogue.

Sending entity

TC‑USER shall process any component handling request primitives as described in subclause 14.1.1.4.1.

After processing the last component handling request primitive, TC‑USER shall issue a TC‑CONTINUE request primitive.

Receiving entity

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

14.1.1.3.3 Dialogue termination

Both the dialogue‑initiator and the dialogue‑responder have the ability to request the termination of a dialogue after it has been established 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 14.1.2.1.1 and 14.1.2.1.2.

The dialogue termination procedure is driven by the following events:

– A TC‑END request primitive

– A TC‑END indication primitive

Sending of TC‑END request

When the dialogue shall no longer be maintained, TC‑USER shall process any component handling request primitives as described in subclause 14.1.1.4.1

After processing the last component handling request primitive (if any), TC‑USER shall issue a TC‑END request primitive with the release method parameter set to "basic end" or "prearranged release", in accordance with the rules as stated in subclauses 14.1.2.1.1 and 14.1.2.1.2.

When no dialogue is to be established, refer to subclauses 14.1.1.3.1.

Receipt of a TC‑END indication

On receipt of a TC‑END indication primitive, the TC‑USER shall accept any component handling indication primitives and process them as described in subclause 14.1.1.4.1.

After processing the last component handling primitive all dialogue related resources are released.

14.1.1.3.4 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

Sending of TC‑U‑ABORT request

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

Receipt of a TC‑U‑ABORT indication

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

14.1.1.3.5 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

Receipt of a TC‑P‑ABORT indication

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

14.1.1.3.6 Mapping to TC dialogue primitives

The TC‑UNI service is not used by CAP.

The mapping of parameters onto the TC Dialogue services is as follows:

The use of parameters of the TC‑BEGIN service is as defined in subclause 14.1.1.3.7 with the following qualifications:

– The Destination Address parameter of the TC‑BEGIN service shall be set to the CAP address of the AE which is to respond to the TC‑BEGIN service.

NOTE 1: The address used in this parameter may be mapped by SCCP address translation to one of a number of alternative AEs.

– The AC Name parameter of the TC‑BEGIN service shall be set according to the specific interface being used between the initiating AE and the responding AE.

– The Originating Address parameter of the TC‑BEGIN service shall be set to the unambiguous CAP address of the AE initiating the TC‑BEGIN service.

The use of parameters of the TC‑CONTINUE service is as defined in subclause 14.1.1.3.7 with the following qualifications:

– The AC Name parameter of the TC‑CONTINUE service shall be set to the value of the AC Name parameter of the TC‑BEGIN service for the same TC Dialogue ID parameter value.

– If present, the Originating Address parameter of the TC‑CONTINUE service shall be set to the unambiguous CAP address of the AE initiating the TC‑CONTINUE service. This parameter is present only in the first TC‑CONTINUE service after a TC‑BEGIN service with the same TC Dialogue ID parameter value.

The use of parameters of the TC‑END service is as defined in subclause 14.1.1.3.7 with the following qualifications:

– The AC Name parameter of the TC‑END service shall be set to the value of the AC Name parameter of the TC‑BEGIN service for the same TC Dialogue ID parameter value. This parameter is present only if the TC‑END service is used immediately after the TC‑BEGIN service.

The use of parameters of the TC‑U‑ABORT service is as defined in subclause 14.1.1.3.7 with the following qualifications:

– The Abort Reason parameter of the TC‑U‑ABORT service shall be used as specified in ETSI ETS 300 287-1 [22].

– The AC Name parameter of the TC‑U‑ABORT service shall be set to the value used in the TC‑BEGIN service.

NOTE 2: This parameter is present only if the TC‑U‑ABORT is the immediate response to a TC‑BEGIN indication.

The use of parameters of the TC‑P‑ABORT service is as defined in subclause 14.1.1.3.7 with the following qualifications:

– The P‑Abort parameter of the TC‑P‑ABORT service is set by TC to indicate the reason why TC aborted the dialogue. It shall take the values as defined in ETSI ETS 300 287-1 [22].

14.1.1.3.7 Default mapping to TC dialogue parameters

Dialogue Id

The value of this parameter is associated with the CAP invocation in an implementation dependent manner. This parameter uniquely identifies a specific TC dialogue to a remote CAP AE for a CAP AE.

Application‑context‑name

The application‑context‑name parameter is set in accordance with the set of Operations which need to be supported by the TC dialogue. The defined AC Names can be found in clauses 6 to 8.

User information

This parameter may be used by both initiating and responding application processes. This parameter shall be used for the CAP-GPRS-ReferenceNumber as defined in 14.1.7. For interfaces other than the gprsSSF‑gsmSCF interface and for SMS related messages (as in subclauses 14.1.3, 14.1.4 and 14.1.5) the receiving side may ignore this parameter if received. The User Information parameter shall be encoded in accordance with the definition provided in ITU-T Recommendation Q.773 [46], subclause 3.2, and the definition of EXTERNAL type provided in ITU-T Recommendation X.690 [57], with the restriction that:

– a size (1..10) constraint of SEQUENCE OF EXTERNAL;

– an Object Identifier shall always be present to identify the user information and the entity which sent it;

– a single-ASN-1-type is used for encoding.

For the use of CAP defined TC-U-Abort reason, see the ASN.1 notation in the subclause 5.7.

For the use of CAP defined CAP-GPRS-ReferenceNumber, see subclause 14.1.7. For the abstract syntax of CAP defined CAP-GPRS-ReferenceNumber, see the ASN.1 notation in the subclause 8.1.

Component present

This parameter is used by TC‑USER as described in ETSI ETS 300 287-1 [22].

Termination

The value of the release method parameter of the TC‑END request primitive is set by TC‑USER according to the rules as stated in subclauses 14.1.2.1.1 and 14.1.2.1.2.

Quality of service

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

– Sequencing requested;

– return option, this parameter is set by TC‑USER in an implementation dependent manner.

14.1.1.4 Component handling

14.1.1.4.1 Procedures for CAP Operations

The present subclause describes the procedures for CAP Operations.

Operation invocation

TC‑USER 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, then this indicates a child operation and implies that the operation is linked to a parent operation.

Operation invocation receipt

On receipt of a TC‑INVOKE indication primitive, TC‑USER shall:

– If the operation code does not correspond to an operation supported by the application‑context, then 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, then 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, then request the transfer of a reject component using the TC‑U‑REJECT request primitive, with the appropriate problem code (linked response unexpected or unexpected linked operation);

If a linked ID is not included, but a Linked ID is needed to correlate the indication primitive with a parent operation invocation, then request the transfer of a reject component using the TC‑U‑REJECT request primitive, with the appropriate problem code (mistyped parameter);

– If the type of the argument is not the one defined for the operation, then 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 CAP related dialogue is about to be released, then request the transfer of a reject component using the TC‑U‑REJECT request primitive with the problem code (Initiating Release);

– If sufficient CAP related resources are not available to perform the requested operation, then 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, then TC‑USER waits for the corresponding response.

Operation Response

For user confirmed operations, TC‑USER shall:

– If no error indication is included in the response to a class 1 or 3 operation, then 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, then construct an error parameter from the parameters received and request its transfer using the TC‑U‑ERROR request primitive.

Receipt of a response

On receipt of a TC‑RESULT‑NL indication, TC‑USER 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, TC‑USER 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, TC‑USER shall:

– If the error code is not defined for the TC‑USER or is not one associated with the operation referred to by the invoke ID, 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, TC‑USER shall:

– accept the TC‑U‑REJECT indication primitive.

On receipt of a TC‑L‑REJECT indicating "return result problem, return error unexpected", TC‑USER shall inform the application process.

On receipt of a TC‑L‑REJECT indicating "return error problem, return error unexpected", TC‑USER shall inform the application process.

This event occurs when the local TC detects a protocol error in an incoming component which affects an operation.

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 TC‑USER in such a case is described in the subclause headed "other events".

On receipt of a TC‑L‑CANCEL indication, the TC‑USER 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;

Other events

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

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 14.1.2.1.2. This is also applicable for invoke problems related to a class 4 linked operation.

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 14.1.2.1.2.

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.

On receipt of a TC‑NOTICE indication primitive, which informs the TC‑USER that a message cannot be delivered by the Network Layer, it is for the application process to decide whether to terminate the dialogue or retry.

This primitive can occur only if the Return Option has been set (see subclause 14.1.1.3.6).

14.1.1.4.2 Mapping to TC component primitives

The mapping of parameters onto the TC Component services is as follows:

The TC‑U‑CANCEL service is not used.

The TC‑RESULT‑NL service is not used.

The use of parameters of the TC‑INVOKE service is as defined in subclause 14.1.1.4.3 with the following qualifications:

– The Operation parameter of the TC‑INVOKE service shall contain the operation.&operationCode value of the CAP Operation to be invoked. The operation must be one of the valid operations supported by the AC for the TC dialogue and must be invokable by the local AE.

– The Parameters parameter of the TC‑INVOKE service shall contain a value of the operation.&ArgumentType value for the operation being invoked, as specified by the Operation parameter.

The use of parameters of the TC‑RESULT‑L service is as defined in subclause 14.1.1.4.3 with the following qualifications:

– The Invoke Id parameter of the TC‑RESULT‑L service shall be set to the value of the Invoke Id parameter of the TC‑INVOKE service from the remote AE to which a result is being sent.

– The Operation parameter of the TC‑RESULT‑L service be set to the value of the Operation parameter of the TC‑INVOKE service from the remote AE which contains the same Invoke Id Parameter value.

– The Parameters parameter of the TC‑RESULT‑L service shall contain the operation.&ResultType value for the operation result, as specified by the Operation parameter.

The use of parameters of the TC‑U‑ERROR service is as defined in subclause 14.1.1.4.3 with the following qualifications:

– The Invoke Id parameter of the TC‑U‑ERROR service shall be set to the value of the Invoke Id parameter of the TC‑INVOKE service from the remote AE to which an error is being sent.

– The Error parameter of the TC‑U‑ERROR service shall be set to the value of the error.&errorCode of the error to be sent. It must be one of the errors which is expected for the invoked operation as defined in the operation.&Errors specification.

– The Parameters parameter of the TC‑U‑ERROR service shall be set to the value of the error.&ParameterType of the error to be sent, as identified by the Error parameter.

The use of parameters of the TC‑U‑REJECT service is as defined in subclause 14.1.1.4.3 with the following qualifications:

– The Invoke Id parameter of the TC‑U‑REJECT service shall be set to the Invoke Id Parameter of the TC component service from the remote AE which is being rejected.

The use of parameters of the TC‑L‑CANCEL service is as defined in subclause 14.1.1.4.3.

14.1.1.4.3 Default mapping to TC component parameters

Invoke Id

This parameter is set by the sending application process. It represents the unique identity of an instance of an operation which is invoked by an AE within a specific TC dialogue. The TC dialogue is identified by the Dialogue Id parameter.

Linked Id

This parameter is set by the sending application process. It represents the Invoke Id of an operation which was received from the remote AE for a specific TC dialogue to which the operation being invoked by the local AE is to be linked. This parameter is present only if the original operation invoked by the remote AE is defined as having linked operations. The type of local operation invoked must be the same type as one of the operations defined as being linked.

Dialogue Id

The value of this parameter is associated with the CAP invocation in an implementation dependent manner. It represents the identity of the established TC dialogue which will carry the component services between the local AE and the remote AE.

Class

The value of this parameter is set according to the type of the operation to be invoked according to the operation definitions in clauses 6 through 8.

Time out

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

Last component

This parameter is used as described in ETSI ETS 300 287-1 [22].

Problem code

This parameter is used as described in subclause 14.1.1.4.1.

Abort reason

This parameter is used by TC‑USER, and attributes and coding are specified by network operator.

14.1.2 gsmSSF‑gsmSCF interfaces

14.1.2.1 Normal procedures

14.1.2.1.1 gsmSSF‑to‑gsmSCF messages

The present subclause defines the normal procedures for TC messages from the gsmSSF to the gsmSCF.

gsmSSF FSM related messages

A dialogue shall be established when the gsmSSF FSM transits from the state "Idle" to the state "Waiting_for_Instructions".

The CAP Operation InitialDP shall be sent with a TC‑BEGIN request primitive.

When the dialogue was opened with InitialDP or InitiateCallAttempt operation then the gsmSSF shall maintain the dialogue when sending the SpecializedResourceReport operation indicating the announcement complete for PlayAnnouncement regardless of the fact whether the disconnectFromIPForbidden parameter was set to true or false.

For all other operations sent from the gsmSSF FSM, the dialogue shall be maintained except for the following cases.

When the gsmSSF FSM executes a non‑error case state transition to the state "Idle" and there is one or more pending operation and TC dialogue is established, TC dialogue can be terminated by TC‑END primitive with component(s). When the gsmSSF sends the last EventReportBCSM, ApplyChargingReport or CallInformationReport the dialogue may be ended from the gsmSSF by a TC‑END request primitive with basic end.

In the case that there is no pending operation and TC dialogue is established, TC dialogue can be terminated by TC‑END primitive with zero component or prearranged end. When the gsmSSF FSM makes a non‑error case state transition to the state "Idle" and there is no operation to be sent, the dialogue is ended by means of a TC‑END request primitive (basic) with zero components, or the dialogue is locally ended by means of a TC‑END request primitive with prearranged end.

In the case where a call release is initiated by any other entity than a gsmSCF, the gsmSSF can end a dialogue with a TC‑END request primitive with zero component or prearranged end if a TC dialogue is established and the gsmSSF has no pending call information requests (or pending requests which should be treated in the same way, see subclause 14.1.1.1) nor any armed EDP.

When the gsmSSF has sent the last EventReportBCSM, ApplyChargingReport or CallInformationReport the dialogue may be ended from the gsmSCF by a TC‑END request primitive with basic end.

Assisting gsmSSF FSM related messages

A dialogue shall be established when the assisting gsmSSF FSM transits 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 gsmSSF FSM, the dialogue shall be maintained except for the following cases.

When the assisting gsmSSF FSM makes a non‑error case state transition to the state "Idle" and there is one or more pending operation and TC dialogue is established, TC dialogue can be terminated by TC‑END primitive with component(s).

In the assisting gsmSSF case the same rules apply as for the gsmSRF as specified for the SpecializedResourceReport operation in subclause 14.1.3.1.1.

In the case that there is no pending operation and TC dialogue is established, TC dialogue can be terminated by TC‑END primitive with zero component or prearranged end. When the assisting gsmSSF FSM makes a non‑error case state transition to the state "Idle" and there is no operation to be sent, the dialogue is ended by means of a TC‑END request primitive (basic) with zero components, or the dialogue is locally ended by means of a TC‑END request primitive with prearranged end.

gsmSSME FSM related messages

The following procedures shall be followed:

– The dialogue shall be maintained when the ActivityTest Return Result is sent.

14.1.2.1.2 gsmSCF‑to‑gsmSSF messages

The present subclause defines the normal procedures for TC messages from the gsmSCF to the gsmSSF.

SCSM‑FSM related messages

A dialogue shall be established when the SCSM‑FSM receives an InitialDP operation for TDP‑R or an AssistRequestInstructions operation, or sends an InitiateCallAttempt operation.

For subsequent operations sent from the SCSM‑FSM, the dialogue shall be maintained except for the following cases;

The dialogue shall no longer be maintained when the prearranged end condition is met in the gsmSCF. When the gsmSCF 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 relationship, by means of a TC‑END request primitive (basic end) is possible.

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.

– For sending one or more CallGap operations, the SCME FSM shall use an existing SCSM FSM associated dialogue which was initiated by a gsmSSF FSM (i.e. established for the transmission of the InitialDP operation). The dialogue shall be maintained.

14.1.2.1.3 smsSSF -to-gsmSCF SMS related messages

A dialogue shall be established when the smsSSF has finalised trigger processing and transits to the state "Waiting_for_Instructions". The relevant CAP Operation, which can be the InitialDPSMS operation only, shall be transmitted in the same message.

For all other operations sent from the smsSSF, the dialogue shall be maintained.

The dialogue shall no longer be maintained when the prearranged end condition is met in the smsSSF. When the smsSSF 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 smsSSF FSM transits to the state "Idle", but no event was reported to the gsmSCF, then the smsSSF shall send TC-END with zero components to the gsmSCF.

When the smsSSF has sent the last EventReportSMS operation the dialogue may be ended from the gsmSCF by a TC‑END request primitive with basic end. If the smsSSF decides to apply basic end, then it shall send TC-END with zero components.

14.1.2.1.4 gsmSCF-to-smsSSF SMS related messages

All operations are sent after a dialogue was established from the smsSSF (the gsmSCF has previously received a TC‑BEGIN indication primitive with an InitialSMSEvent operation).

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.

14.1.2.1.5 Use of dialogue handling services

Dialogue handling services are used to trigger the sending of the APDUs associated with the operations involved in the CAP packages.

Component grouping is performed under the control of the application‑process through an appropriate usage of the TC‑BEGIN, TC‑CONTINUE and TC-END service.

14.1.2.2 Abnormal procedures

The following procedures also apply to the gsmSCF‑gsmSRF interfaces.

14.1.2.2.1 gsmSCF‑to‑gsmSSF/gsmSRF messages

Considering that gsmSSF and gsmSRF do not have the logic to recover from error cases detected on the gsmSCF‑gsmSSF/gsmSRF interface, the following shall apply:

– Operation errors and rejection of TC components shall be transmitted to the gsmSSF and, respectively, the gsmSRF with a TC‑END request primitive, basic end.

If, in violation of the above procedure, an ERROR or REJECT component is received with a TC‑CONTINUE indication primitive, then the gsmSSF and, respectively, the gsmSRF shall abort the dialogue with a TC‑U‑ABORT request primitive.

14.1.2.2.2 gsmSSF/gsmSRF/ ‑to‑gsmSCF messages

Operation errors and rejection of TC components shall be transmitted to the gsmSCF 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 gsmSCF decides on further processing. It may either continue, explicitly end or abort the dialogue.

– When the gsmSSF has received and processed InitiateCallAttempt and has acknowledged InitiateCallAttempt with InitiateCallAttempt-RESULT, then a User Error resulting from an erroneous component that is contained in the same TC_Begin message as InitiateCallAttempt, shall be transmitted with a TC‑CONTINUE indication primitive.

– 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.

– on expiration of application timer Tssf or Tsrf, dialogue shall be terminated by means of by TC‑U‑ABORT primitive with an Abort reason, regardless of TC dialogue is established or not.

If the error processing in the gsmSSF or gsmSRF leads to the case where the gsmSSF or gsmSRF is not able to process further gsmSCF operations while the dialogue is to be maintained, then the gsmSSF or gsmSRF aborts the dialogue with a TC‑END request primitive with basic end or a TC‑U‑ABORT request primitive, depending on whether any pending ERROR or REJECT component is to be sent or not.

The gsmSSF can end a dialogue with a TC‑U‑ABORT request primitive in the case that call release is initiated by any other entity then the gsmSCF and the gsmSSF has no pending call information requests (or pending requests which should be treated in the same way, i.e., ApplyCharging nor any armed EDP to notify the gsmSCF of the call release (for alternative way, see subclause 14.1.2.1.1).

14.1.2.2.3 gsmSCF-to-smsSSF SMS related messages

Considering that the smsSSF does not have the logic to recover from error cases detected on the gsmSCF-smsSSF interface, the following shall apply:

– operation errors and rejection of TC components shall be transmitted to the smsSSF with a TC‑END request primitive, basic end.

If, in violation of the above procedure, an ERROR or REJECT component is received with a TC‑CONTINUE indication primitive, then the smsSSF shall abort the dialogue with a TC‑U‑ABORT request primitive.

14.1.2.2.4 smsSSF-to-gsmSCF SMS related messages

Operation errors and rejection of TC components shall be transmitted to the gsmSCF 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 gsmSCF decides on further processing. It may either continue, explicitly end or abort the dialogue;

If the error processing in the smsSSF leads to the case where the smsSSF is not able to process further gsmSCF operations while the dialogue is to be maintained, then the smsSSF aborts the dialogue with a TC‑U‑ABORT request primitive.

The smsSSF aborts a dialogue with a TC‑U‑ABORT request primitive if release is initiated by any other entity than the gsmSCF and the smsSSF has no armed EDPs to notify the gsmSCF.

14.1.2.2.5 Use of dialogue handling services

On receipt of a TC‑U‑REJECT.ind in the FE, this primitive should be ignored. 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 14.1.1.2. This is also applicable for invoke problems related to a class 4 linked operation.

A TC‑U‑REJECT.req should be sent followed by a TC‑CONTINUE.req.

On receipt of a TC‑R‑REJECT.ind in the FE, this primitive should be ignored. 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 14.1.1.2. This is also applicable for invoke problems related to a class 4 linked operation.

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.

On receipt of a TC‑NOTICE indication the TC‑USER is informed that a message cannot be delivered by the Network Layer. It occurs if the Return Option has been set (see subclause 14.1.1.3.7). It is for the application process to decide whether to terminate the dialogue or retry.

The application‑process is the sole user of the TC‑P‑ABORT service and TC‑NOTICE service.

The receipt of a TC‑U‑ABORT‑Ind or TC‑P‑ABORT‑Ind on a dialogue terminates all request processing.

14.1.2.3 Dialogue handling

14.1.2.3.1 Dialogue establishment

14.1.2.3.2 Dialogue continuation

14.1.2.3.3 Dialogue termination

14.1.2.3.4 User abort

14.1.2.3.5 Provider abort

14.1.2.3.6 Mapping to TC dialogue primitives

The gsmSSF‑gsmSCF IN services can be mapped onto TC services. The present subclause defines the mapping of the gsmSSF‑gsmSCF IN services onto the services of the TC dialogue handling services defined in ETSI ETS 300 287-1 [22].

a) The TC‑BEGIN service is used to invoke the operations of the gsmSCF‑gsmSSF connection packages as defined in clause 6.

b) The TC‑CONTINUE service is used to report the success of the operations invoked in a TC‑BEGIN service and to invoke or respond to any other operations.

c) The TC‑U‑ABORT service is used to report the failure of operations of the connection packages as defined in clause 6.

The mapping of the parameters onto the TC‑BEGIN primitive is defined in subclause 14.1.1.3.6 with the following qualifications:

– The AC Name parameter shall take the value of the application‑context‑name field of the cap3-sms-AC object if the initiating AE is a gsmSSF.

The mapping of the parameters onto the TC‑CONTINUE primitive is defined in subclause 14.1.1.3.6.

The mapping of the parameters onto the TC‑U‑ABORT primitive is defined in subclause 14.1.1.3.6 with the following qualifications:

– The Application‑Context‑Name parameter shall be used as specified in ETSI ETS 300 287-1 [22]. When the responding AE refuses a dialogue because the application‑context‑name it receives is not supported, this parameter shall have the value of the application‑context‑name field of the cap3-sms-AC object if the responding AE is a gsmSCF.

The use of the parameters of the TC‑END service is defined in subclause 14.1.1.3.6.

14.1.2.4 Component Handling

14.1.2.4.1 Procedures for CAP Operations

The CAP ASEs are users of the TC component handling services except for the TC‑L‑REJECT and TC‑L‑CANCEL services which are used by the application‑process. Receipt of a TC‑L‑REJECT‑Ind leads the application‑process to abandon the dialogue (i.e. it issues a TC‑U‑ABORT‑Request primitive).

The TC‑U‑CANCEL service is never used.

14.1.2.4.2 Mapping to TC component parameters

The gsmSSF‑gsmSCF IN ASE services are mapped onto the TC component handling services. The mapping of operations and errors onto TC services is defined in subclause 14.1.1.4.2 with the following qualifications:

The timeout parameter of the TC‑INVOKE‑Req primitives is set according to clause 6.

14.1.3 gsmSCF‑gsmSRF interface

14.1.3.1 Normal procedures

14.1.3.1.1 gsmSCF‑to/from‑gsmSRF messages

A dialogue is established when the gsmSRF sends an AssistRequestInstructions operation to the gsmSCF. For all other operations sent to/from the gsmSRF, the dialogue shall be maintained.

In the case that there is no pending operation and TC dialogue is established, TC dialogue can be terminated by TC‑END primitive with zero component. When the SCSM makes a non‑error case state transition to end-user interaction and there is no operation to be sent, the dialogue is ended by means of a TC‑END request primitive (basic) with zero components.

When the dialogue is opened with the AssistRequestInstructions operation then the gsmSRF shall no longer maintain the dialogue when sending the SpecializedResourceReport operation indicating announcement complete for PlayAnnouncement with disconnectFromIPForbidden parameter was set to false or Return Result of the PromptAndCollectUserInformation with disconnectFromIPForbidden parameter was set to false. The dialogue is ended by means of a TC‑END request primitive with basic end, and the SpecializedResourceReport operation is transmitted with the same request.

Regardless of whether pending operation exists or not, when the SRSM‑FSM is informed of the disconnection of bearer connection (in the case of gsmSCF initiated disconnection or call abandon from call party) and dialogue is established, the dialogue is ended by means of a TC‑END request primitive (basic) with zero components or TC‑END request primitive (prearranged end).

The dialogue shall no longer be maintained when the prearranged end condition is met in the gsmSRF. When the SRSM‑FSM is informed the disconnection of bearer connection and TC dialogue is not established, TC dialogue is locally terminated by TC‑END primitive with prearranged end.

When the gsmSCF 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 relationship, by means of a TC‑END request primitive (basic end) is possible.

In the relay case, the gsmSRF‑gsmSCF relationship uses the gsmSSF‑gsmSCF TC dialogue. This is possible, because begin and end of the gsmSRF‑gsmSCF relationship are embedded in the gsmSSF‑gsmSCF relationship. gsmSRF‑gsmSCF information shall be exchanged with TC‑CONTINUE request primitives.

14.1.3.1.2 Abnormal procedures

14.1.3.1.3 Dialogue handling

14.1.3.1.3.1 Dialogue establishment

14.1.3.1.3.2 Dialogue continuation

14.1.3.1.3.3 Dialogue termination

14.1.3.1.3.4 User abort

14.1.3.1.3.5 Provider abort

14.1.3.1.3.6 Mapping to TC dialogue primitives

The gsmSCF‑gsmSRF IN services can be mapped onto TC services. The present subclause defines the mapping of the gsmSCF‑gsmSRF IN services onto the services of the TC dialogue handling services defined in ETSI ETS 300 287-1 [22].

a) The TC‑BEGIN service is used to invoke the operations of the gsmSRF‑gsmSCF connection packages as defined in clause 6.

b) The TC‑CONTINUE service is used to report the success of the operations invoked in a TC‑BEGIN service and to invoke or respond to any other operations.

c) The TC‑U‑ABORT service is used to report the failure of operation of the gsmSCF‑gsmSRF operations packages as defined in clause 6.

The mapping of parameters onto the TC Dialogue services is as defined in subclause 14.1.1.3.6 with the following qualifications:

The mapping of the parameters onto the TC‑BEGIN primitive is defined in subclause 14.1.1.3.6 with the following qualifications:

– The AC Name parameter shall take the value of the application‑context‑name field of the gsmSRF‑gsmSCF‑ac object.

14.1.3.2 Component handling

14.1.3.2.1 Procedures for CAP Operations

14.1.3.2.2 Mapping to TC component parameters

The mapping of parameters for the TC component services is defined in subclause 14.1.1.4.2 with the following qualifications.

The Timeout Parameter of the TC‑INVOKE service is set according to clauses 6.

14.1.4 gprsSSF‑gsmSCF interface

14.1.4.1 Normal procedures

14.1.4.1.1 TC-dialogues and relationships

The GPRS dialogue can consist of multiple consecutive TC-dialogues. A GPRS dialogue is identified by a GPRS-ReferenceNumber consisting of the originationReference and the destinationReference. One GPRS-Reference is assigned by the SGSN and shall be unique within this SGSN. The other GPRS-Reference is assigned by the gsmSCF and shall be unique within this gsmSCF.

The TC-dialogues are closed and (re)opened whenever necessary.

14.1.4.1.2 Use of the GPRS Reference

For the use of CAP defined GPRS-ReferenceNumber, see also the ASN.1 notation in the subclause 8.1.

When the gprsSSF sends the first operation for a new GPRS dialogue (InitialDPGPRS), the gprsSSF shall include a GPRS Reference Number in the TC message. This GPRS Reference Number shall consist of the SGSN Process Id as originationReference, which is internally allocated by the gprsSSF. This number is used by the gprsSSF to associate an incoming TC message with an internal GPRS Process.

When the gsmSCF has received the InitialDPGPRS operation, it shall store the SGSN Process ID and allocate an SCF Process Id which is used by the gsmSCF to associate an incoming TC message with an internal gsmSCF Process.

The gsmSCF shall include the GPRS Reference Number in the first TC-CONTINUE message, SGSN Process Id in destinationReference and SCF Process Id in originationReference, returned to the gprsSSF.

When the gprsSSF receives the first TC message from the gsmSCF for this GPRS dialogue, the gprsSSF shall store the gsmSCF Process Id together with the SGSN Process Id.

From here onwards all the TC messages that open a new TC dialogue shall include the GPRS Reference Number consisting of the originationReference and the destinationReference to associate the internal process in the origination entity and the destination entity, respectively, until the end of the relationship between these processes.

For any TC-CONTINUE in the existing TC dialogue, transporting the GPRS Reference Number is not needed except for the first response after the InitialDPGPRS operation.

14.1.4.1.3 gprsSSF‑to‑gsmSCF messages

The present subclause defines the normal procedures for TC messages from the gprsSSF to the gsmSCF.

gprsSSF FSM related messages

A GPRS dialogue and a TC dialogue shall be established when the gprsSSF FSM transits from the state "Idle" to the state "Waiting_for_Instructions". The InitialDPGPRS operation shall be transmitted in the same TC message, i.e. TC-BEGIN. It shall contain the GPRS-Reference as assigned by the SGSN in the originationReference. The gprsSSF may intiate the subsequent TC dialogues for this GPRS dialogue with the following operations:

– ApplyChargingReportGPRS

– EntityReleasedGPRS

– EventReportGPRS

For the establishment of a new TC dialogue within the context of the current GPRS dialogue, the gprsSSF may apply one of the following mechanisms:

the gprsSSF shall memorise the gsmSCF address used in the first response message to the InitialDPGPRS and use it to open the new TC dialogue;
the gprsSSF shall use the gsmSCF address from GPRS-CSI to open the new TC dialogue.

The gsmSCF shall memorise the gprsSSF address received along with the InitialDPGPRS and use it for the opening of new TC dialogues within the context of the current GPRS dialogue.

The gsmSCF may open subsequent TC dialogues with the following CAP Operations:

– ActivityTestGPRS;

– ApplyChargingGPRS;

– CancelGPRS;

– FurnishChargingInformationGPRS;

– ReleaseGPRS;

– RequestReportGPRSEvent;

– SendChargingInformationGPRS.

The CAP Operation that opens a TC dialogue shall be sent with a TC‑BEGIN request primitive. This message shall contain the GPRS-ReferenceNumber assigned by the sender of this message in the originationReference. If the operation opens a subsequent TC dialogue, then this message shall contain also the previously received destinationReference. If an operation opens a GPRS dialogue, then the TC message reply shall contain the originationReference as assigned by the sender, i.e. the gsmSCF.

The TC dialogue shall be closed for the idle periods, i.e. when the gprsSSF FSM transits from the state "Waiting_for_Instructions" to the state "Idle", if the gprsSSF FSM is in the state "Monitoring" and has received all replies or time‑outs for the operations sent, after standalone operations of the gsmSCF in Monitoring state if gprsSSF FSM does not transit to the state "Idle" (ActivityTestGPRS, ApplyChargingGPRS, CancelGPRS, FurnishChargingInformationGPRS, RequestReportGPRSEvent, SendChargingInformationGPRS), or at the end of a GPRS dialogue.
Each TC dialogue shall be terminated by the gprsSSF using TC-END (basic end). The following operations can cause the end of the GPRS dialogue:

– ContinueGPRS;

– ConnectGPRS;

– ApplyChargingReportGPRS result;

– EntityReleasedGPRS rersult;

– EventReportGPRS (EDP-N) result;

– CancelGPRS;

– ReleaseGPRS;

– RequestReportGPRSEvent (disarming of DPs).

When the gprsSSF FSM makes a non‑error case state transition to the state "Idle" and there is one or more pending operation and TC dialogue is established, TC dialogue may be terminated by TC‑END primitive with zero component(s) after all pending operations have been sent. When the gprsSSF sends the last EventReportGPRS, EntityreleasedGPRS or ApplyChargingReportGPRS, then aftrer reception of the result or error, the GPRS dialogue may be ended from the gprsSSF by a TC‑END request primitive with basic end.

In the case that there is no pending operation, result nor error, and TC dialogue is established, TC dialogue shall be terminated by a TC‑END primitive with zero component.

In the case where a PDP Context release or detach is initiated by any other entity than a gsmSCF, the gprsSSF shall end a GPRS dialogue with the EntityReleasedGPRS operation if the gprsSSF has no armed DP to report nor pending ApplyChargingReportGPRS which should reported.

In the case of overlapping dialogues for the same GPRS dialogue the gsmSCF opened TC dialogue is aborted by the gprsSSF with the abort reason overlapping-dialogue as specified in subclause 5.7. This abort reason is used to indicate to the gsmSCF that a specific instance already has a TC dialogue open. It is typically obtained when both the gsmSCF and gprsSSF open a new dialogue at the same time. While the gprsSSF waits for a response to an operation sent in TC-BEGIN it may receive an operation from the gsmSCF in TC-BEGIN. In such cases the dialogue opened by the gprsSSF is maintained and the dialogue opened by the gsmSCF is aborted with this abort reason.

gprsSSME FSM related messages

The following procedures shall be followed:

– The TC dialogue shall be terminated by a TC-END primitive with zero components after the ActivityTestGPRS Return Result is sent.

14.1.4.1.4 gsmSCF‑to‑gprsSSF messages

The present subclause defines the normal procedures for TC messages from the gsmSCF to the gprsSSF.

In the case of overlapping dialogues for the same relationship the gsmSCF opened dialogue is closed by the gprsSSF as specified in subclause 5.7. The gsmSCF shall first respond normally to the operations sent by the gprsSSF, and then decide on the further actions.

SCME‑FSM related messages

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

– A new subsequent TC dialogue is established when the ActivityTestGPRS operation is sent.

14.1.4.2 Abnormal procedures

14.1.4.2.1 gsmSCF‑to‑gprsSSF messages

The present subclause defines the abnormal procedures for TC messages from the gsmSCF to the gprsSSF.

Considering that the gprsSSF does not have the logic to recover from error cases detected on the gsmSCF‑gprsSSF interface, the following shall apply:

– Operation errors and rejection of TC components shall be transmitted to the gprsSSF with a TC‑END request primitive, basic end.

– The GPRS dialogue shall be closed.

– The gprsSSF shall apply Default GPRS Handling from the valid CSI to the PDP Context or GPRS Session.

If, in violation of the above procedure, an ERROR or REJECT component is received with a TC‑CONTINUE indication primitive, then the gprsSSF shall abort the dialogue with a TC‑U‑ABORT request primitive and shall apply Default GPRS Handling from the valid CSI to the PDP Context or GPRS Session.

14.1.4.2.2 gprsSSF‑to‑gsmSCF messages

The present subclause defines the abnormal procedures for TC messages from the gprsSSF to the gsmSCF.

Operation errors and rejection of TC components shall be transmitted to the gsmSCF according to the following rules:

– The TC 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.
On receipt of an ERROR or REJECT component the gsmSCF decides on further processing. It may either continue, explicitly end or abort the TC dialogue. If the TC dialogue is closed due to such error, then the GPRS dialogue shall also be closed.

– on expiration of application timer Tssf, the TC dialogue shall be terminated by means of by TC‑U‑ABORT primitive with an Abort reason. The GPRS dialogue shall be closed.

If the error processing in the gprsSSF leads to the case where the gprsSSF is not able to process further gsmSCF operations while the TC dialogue is to be maintained, then the gprsSSF aborts the TC dialogue with a TC‑END request primitive with basic end or a TC‑U‑ABORT request primitive, depending on whether any pending ERROR or REJECT component is to be sent or not.

The gprsSSF can end a TC dialogue with a TC-U-ABORT request primitive in the following case:

– Any entity other than the gsmSCF initiates closure of the GPRS dialogue, and

– The gprsSSF has no pending reports, and

– The gprsSSF has no armed EDP to notify the gsmSCF that the GPRS dialogue has been closed.

For an alternative method, see subclause 14.1.7.1.1.

14.1.4.2.3 Default GPRS Handling

If a TC dialogue is closed due to unrecoverable TC/protocol error (does not apply to the overlapping TC dialogues), or aborted by the gsmSCF, or at the Tssf expiry, then the gprsSSF shall check the applicable Default GPRS Handling parameter of the GPRS-CSI. In this context the applicable Default GPRS Handling is the one that corresponds the TDP that opened the GPRS dialogue. The same default handling shall apply to all state models that are controlled by the particular GPRS dialogue.

14.2 Services assumed from SCCP

The present subclause describes the services required from the SCCP that may be used by the CAMEL applications for the CAMEL Application Part (CAP) used between the gsmSSF, assisting gsmSSF, gsmSRF, gprsSSF, and gsmSCF.

The following SCCP revisions are supported by CAP:

– Signalling Connection Control Part, Signalling System no. 7 CCITT ("Blue Book SCCP")

– Signalling Connection Control Part, Signalling System no. 7 ITU-T Recommendation Q.711 to Q.716 ("White Book SCCP")

NOTE: Support of White Book SCCP at the receiving side shall be mandated from 00:01hrs, 1st July 2002(UTC).

– ANSI T1.112-1996 [91]: "American National Standards for Telecommunications– Signalling System Number 7 (SS7) – Signalling Connection Control Part (SCCP)".

When CAP uses White Book SCCP to send a message, and SCCP segments the message into one or more XUDT messages, then the transmission of this message may fail.

Failure will occur when the destination SCCP, or any intermediate SCCP, does not support White Book SCCP.

Support of ANSI T1.112-1996 [91] SCCP applies to PLMNs in North America only. Interworking between a PLMN in North America and a PLMN outside North America will involve a STP to translate between ANSI SCCP and ITU-T/CCITT SCCP.

14.2.1 Normal procedures

The SCCP forms the link between the TC and the MTP and provides (in conjunction with the MTP) the network services for the CAMEL applications. The network services provided allow the signalling messages sent by the application to the lower layers to be successfully delivered to the peer application.

14.2.2 Service functions from SCCP

14.2.2.1 SCCP connectionless services

The services described are those given in the SCCP ITU-T recommendations Q.711 to Q.716 should be consulted to identify possible interworking and compatibility issues between the different SCCP versions.

The following Connection‑less services are expected from the SCCP:

a) Network Addressing to enable signalling connections between SCCP users;

b) Sequence Control to enable the SCCP users to invoke "sequence guaranteed" or "sequence not guaranteed" options for a given stream of messages to the same destination;

c) Segmentation/reassembly of large user messages (for "White Book SCCP" only);

d) Return Option to enable the SCCP users to invoke "discard message on error" or "return message on error" for a given message not able to be delivered by the SCCP to the destination SCCP user, due to routeing or segmentation/re‑assembly failure;

e) Congestion control.

The primitives used for the above services are given below.

The N‑UNITDATA request and N‑UNITDATA indication primitives are used to send and receive data. The parameters of these primitives include the Called and Calling Addresses, Sequence Control, Return Option and User Data with the addressing parameters always mandatory.

The N‑NOTICE indication primitive is used to return undelivered data if return option is set and a routeing/segmentation error occurs.

14.2.2.1.1 Sub-System Number (SSN)

The use of SSN is a network operator option and values for intra-PLMN usage are network specific. A CAP SSN has been reserved for inter-PLMN use, as defined in 3GPP TS 23.003 [5].

14.2.2.1.2 Addressing

The addressing elements consist of information contained within the Calling and the Called Party Addresses which are sent by the application to the lower layers.

The application expects the SCCP to route messages by either (a) the use of the Destination Point Code (DPC) plus the Subsystem Number (SSN), or (b) the use of the GT plus optionally the SSN. The application also specifies to the lower layer whether to route the message on the DPC or the GT.

Method (a) above may be used when the application is aware of the destination point code and the destination SSN located at that point code to which the message is to be delivered. Within a national network different SSNs, according to ITU-T Recommendation Q.713 [42], may be allocated for the different network specific applications, e.g. a SSN may be allocated for a gsmSCF functionality.

Method (b) above may be used when a message is to be delivered to a SCCP‑user which can be identified by the combination of the elements within the GT. An example of the use of this method is when messages have to be delivered between different networks. This method may be used since the originating network is unaware of the point code and SSN’s allocations within the destination network. The network that determines the end‑node to which the message is to be delivered has to perform a GT Translation to derive the destination Point Code and the SSN. If optionally the original address contained the SSN, then this may be used as the destination SSN, or the translation may, if required, provide an appropriate new SSN.

When GT is used for addressing, the CAMEL application expects that the SCCP supports the following elements as defined in ITU-T Recommendation Q.713 [42]:

Address Indicator:

The application will set this indicator to indicate one or any combination of the elements "signalling point code, GT, subsystem number" in the address information octets.

GT Indicator:

This indicator specifies the method employed for the formatting of the address information. There are four values (1 to 4), for example, the value 4 indicates that the format includes the numbering plan, the nature of the address indicator and the translation type. The format with the indicator value 4 is always used for internetwork connections.

Translation Type:

The Translation Types are defined within ITU-T Recommendation Q.713 [42].

Numbering Plan:

1) The proposed "generic numbering plan" is described within the ITU-T Recommendation Q.713 [42]. This numbering plan identifies the SCCP nodes or SCCP subsystems unambiguously such that messages may be efficiently routed within one or more networks, and is particularly useful when used in the Calling Address for the sending of a response message back to the originating node. This is achieved by having an international and a national part in the generic numbering plan. For response messages the responding node analyses the international part of the generic numbering plan to determine the gateway node to which the response is to be routed. Having routed to the gateway node, the national part (which was populated within the originating network) is analysed to determine the originating node within the originating network.

2) A numbering plan which would define particular nodes based specifically on services is outside the scope of CAMEL.

3) The SCCP caters for a number of other numbering plans (e.g. ISDN, Mobile etc. numbering plans). The whole range catered for is shown in [?]. These may be used by CAMEL applications if deemed suitable.

Encoding Scheme:

This identifies the encoding scheme employed by the application and is generally BCD encoded with odd or even number of digits.

GT Address Information:

These are the actual address digits supplied by the application and may be BCD digits or encoded as indicated by the encoding scheme.

The network provider must ensure that any change of GT value during translation preserves any CAP specific information contained in the initial GT value.

This requirement applies to all interfaces, not just those used for internetworking.

If route on SSN is to be supported from the originating node, then an ITU-T non‑zero internationally standardised SSN is required for international internetworking.

In the absence of a ITU-T standardised non‑zero SSN for CAP services, the use of route on GT is mandatory from the origin node to the network containing the destination node.

When the SCCP of CCITT Signalling System No. 7 is used, the format and coding of address parameters carried by the SCCP for that purpose shall comply with ITU-T Recommendation Q.713 [42] with the following restrictions:

1) Intra-PLMN addressing

For communication between entities within the same PLMN, the use of SCCP addressing is network specific, and method (a) and (b) are both applicable.

2) Inter-PLMN addressing

method (b) with the mandatory SSN is applicable only with the following format:

i) Called Party Address

– SSN indicator = a standardised SSN shall be used. The SSN used shall be that specified for CAP in 3GPP TS 23.003 [5];

– Point Code indicator = 0;

– Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and nature of address indicator);

– Translation type = 0 (Not used);

– Routing indicator = 0 (Routeing on global title);

The format is also described in the table 14-2 below (for NP=1, NAI=4):

Table 14-2: Called Party Address format

8	7	6	5	4	3	2	1
0	RI = 0	GTI = 4 (0100)				SSNI = 1	PCI = 0	Octet 1
SSN = a value for CAP as specified in 3GPP TS 23.003 [5]								Octet 2
Translation type = 0								Octet 3
Numbering plan = 1 (E.164)				Encoding scheme = 1 or 2				Octet 4
0	Nature of address indicator = 4 (International)							Octet 5
Country code digit 2 (if present)				Country code digit 1				Octet 6
National Destination Code (NDC) Digit 1				Country code digit 3 (if present)				Octet 7
NDC digit 3 (if present)				NDC digit 2 (if present)				Octet 8
NDC digit 5 (if present)				NDC digit 4 (if present)				Octet 9
Equipment idntification digit 2				Equipment idntification digit 1				Octet 10
…				…				…
filler = 0 (if needed)				Equipment idntification digit m				Octet n

Note Country code, National Destination Code, and SN(equipment id) are provided as example, so each digit may differ for each Inter-PLMN addressing case. (e.g., there is a case where only CC digit 1 shall be used). See ITU-T Recommendation Q.713 [42] for translation rules.

ii) Calling Party Address

SSN indicator = a standardised SSN shall be used. The SSN used shall be that specified for CAP in 3GPP TS 23.003 [5];
Point code indicator = 0;
Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and nature of address indicator);
Translation type = 0 (Not used);
Routing indicator = 0 (Routeing on Global Title).

The format is also described in the table 14-3 below (for NP=1, NAI=4):

Table 14-3: Calling Party Address format

8	7	6	5	4	3	2	1
0	RI = 0	GTI = 4				SSNI = 1	PCI = 0	Octet 1
SSN = a value for CAP as specified in 3GPP TS 23.003 [5]								Octet 2
Translation type = 0								Octet 3
Numbering plan = 1 (E.164)				Encoding scheme = 1 or 2				Octet 4
0	Nature of address indicator = 4 (International)							Octet 5
Country code digit 2 (if present)				Country code digit 1				Octet 6
National Destination Code (NDC) Digit 1				Country code digit 3 (if present)				Octet 7
NDC digit 3 (if present)				NDC digit 2 (if present)				Octet 8
NDC digit 5 (if present)				NDC digit 4 (if present)				Octet 9
Equipment idntification digit 2				Equipment idntification digit 1				Octet 10
…				…				…
Filler = 0 (if needed)				Equipment idntification digit m				Octet n

When the SCCP of ANSI Signalling System No. 7 is used, the format and coding of address parameters carried by the SCCP for the purpose of signalling transfer shall comply with ANSI Recommendation T1.112-1996 [91] with the following restrictions:

1) Intra-PLMN addressing

For communication between entities within the same PLMN, the use of SCCP addressing is network specific.

2) Inter-PLMN addressing

a) Called Party Address

SSN indicator = a standardised SSN shall be used. The SSN used shall be that specified for CAP in 3GPP TS 23.003 [5];
Point Code indicator = 0;
Global title indicator = 0010 (Global title includes translation type);
the Translation Type (TT) field shall be coded according to the content of the address information as follows:

TT = 9 (decimal), if IMSI is included; or

TT = 14 (decimal), if MSISDN is included; or

TT = 10 (decimal), if a Network Element address is included. (If TT=10, then Number Portability is not applicable, if TT=14, then Number Portability is applicable)

Routing indicator = 0 (Routeing on global title);

b) Calling Party Address

SSN indicator = a standardised SSN shall be used. The SSN used shall be that specified for CAP in 3GPP TS 23.003 [5];
Point code indicator = 0;
Global title indicator = 0010 (Global title includes translation type);
the Translation Type (TT) field shall be coded according to the content of the address information as follows:

TT = 9 (decimal), if IMSI is included; or

TT = 14 (decimal), if MSISDN is included; or

TT = 10 (decimal), if a Network Element address is included. (If TT=10, then Number Portability is not applicable, if TT=14, then Number Portability is applicable)

Routing indicator = 0 (Routeing on Global Title).

14.2.2.1.3 Sequence control

The application will specify whether SCCP protocol class 0 or 1 is required. Class 0 provides a basic connection‑less service where the sequence of message delivery is not guaranteed. Class 1 connection‑less service provides a guaranteed sequence delivery of messages (with the same called address) for a given stream of messages. Class 1 shall be requested by any application that can send more than 1 TC message to its peer (consecutive TR-CONTINUE) before receiving a response from its peer (TR-CONTINUE or TR-END).

On receipt of a TC-RESULT-NL indication, the TC-USER shall request the transfer of a reject component using TC-U-REJECT request primitive, with the appropriate problem code (mistyped parameter).

The return option may be used if requested by the application (Network Operator to determine).

14.2.2.1.4 Return on error

Return on Error mechanism may be required by the CAMEL applications such that the application is aware of messages that have not been delivered to the destination by the SCCP. The return option allows the return of the message that was not delivered due to routeing or segmentation/re‑assembly failure back to the issuing user. This return option may be required in all segments of a long message or only in the first segment by the CAMEL applications.

If the return option is invoked by the application and the message is not delivered, then the SCCP specifies the "return reason" as specified in ITU-T Recommendation Q.713 [42]. The N‑NOTICE primitive is used to return the undelivered message to the originating user.

14.2.2.1.5 Segmentation / reassembly

The application expects that since the SCCP can send up to 260 octets of user data (including the address information and TC‑message) in a UDT message (248 octets in a XUDT message performing segmentation and congestion control), segmentation is available for long user messages.

Also the SCCP is expected to perform the reassembly function on received segmented messages and deliver the reassembled message to the user.

However, it should be noted that even though the theoretical maximum size of SCCP‑user data and addresses that can be segmented by the SCCP is 3 968 octets, the SCCP‑user would limit the length to about 2 560 octets to allow for the largest known addresses. Note that the application must also allow for the octets used for the TC‑message in the 2 560 octets.

The CAMEL application does not expect the SCCP to segment the long message into more than 16 segments.

14.2.2.1.6 Congestion control

To help control of possible congestion that might occur in the lower layers the application may assign a value to indicate the importance of the message. The use of this parameter requires the use of SCCP (1997) ITU‑T Recommendations.

Also there exist other congestion control mechanisms as indicated below in SCCP Management.

These congestion control methods are network operator option in the case of intra-PLMN network signalling, and shall not be used in the case of inter-PLMN network signalling.

14.2.2.2 SCCP connection oriented services

The use by CAMEL applications for the Connection‑oriented services is outside the scope of CAMEL.

14.2.2.3 SCCP management

The subsystems used within the CAMEL application expect the SCCP to provide management procedures to maintain network performance by re‑routeing in the event of failure of a subsystem, and in the case of network congestion by use of the congestion handling procedure. These procedures have appropriate interactions with the SCCP user as described in ITU-T Recommendations Q.713 [42] and ITU-T Recommendation Q.714 [43].

To achieve the above the SCCP is expected to perform the following procedures:

– Signalling point status management (which include the signalling point prohibited, signalling point allowed, signalling point congested, and local MTP availability sub procedures).

– Subsystem status management (which include the subsystem prohibited, subsystem allowed, and subsystem status test sub procedures).

– Co‑ordinated state change (a procedure which allows a duplicated subsystem to be withdrawn from service without affecting the performance of the network).

These SCCP management procedures are network operator option in the case of intra-PLMN network signalling, and shall not be used in the case of inter-PLMN network signalling.

Annex A (normative):
Mapping between CAP and ISUP