4 Interface specification for telecommunication services

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

4.1 General

4.1.1 Definition methodology

The definition of the protocol can be split into three sections:

– the definition of the Single Association Control Function (SACF)/Multiple Association Control Function (MACF) rules for the protocol;

– the definition of the operations transferred between entities;

– the definition of the actions taken at each entity.

The SACF/MACF rules are defined in prose. The operation definitions are in Abstract Syntax Notation One (ASN.1). For details on ASN.1 refer to ITU-T Recommendation X.680 [53] and ITU‑T Recommendation X.681 [54]. The actions are defined in terms of state transition diagrams. Further guidance on the actions to be performed on receipt of an operation can be gained from the description of the relevant information flow in ITU‑T Recommendation Q.1224 [50].

The CAMEL Application Part (CAP) is a ROS Element (ROSE) user protocol. Refer to ITU-T Recommendation X.880 [58], ITU-T Recommendation X.881 [59] and ITU-T Recommendation X.882 [60] for Remote Operations. The ROSE protocol is contained within the component sublayer of Transaction Capabilities Application Part (TCAP) (see ETS 300 287‑1 [22]) and Digital Subscriber Signalling System No One (DSS1) (see ITU‑T Recommendation Q.932 [48]). At present, the ROSE Application Protocol Data Units (APDUs) are conveyed in transaction sublayer messages in Signalling System no. 7 (SS7) and in the EN 300 403‑1 [25] REGISTER, FACILITY and call control messages in DSS1. Other supporting protocols may be added at a later date.

The CAP (as a ROSE user) and the ROSE protocol are specified in ASN.1, as defined in ITU‑T Recommendation X.680 [53], ITU‑T Recommendation X.681 [54], ITU‑T Recommendation X.682 [55] and ITU‑T Recommendation X.683 [56]. The encoding of the resulting Protocol Data Units (PDUs) shall be done in accordance with the Basic Encoding Rules as defined in ITU‑T Recommendation X.690 [57].

4.1.2 Example physical scenarios

The reader is referred to Intelligent Network Capability Set 1 (CS1) Core INAP [24] for details of the example physical scenarios.

Scenario 1, Direct Path to IP (Ref. CS1 cases b) & d)).

Figure 4-1/1: Scenarios

Figure 4-1/2: Scenarios

Scenario 2a, Connection to IP via an assisting gsmSSF with relay function; IP co-located with assisting gsmSSF (Ref. CS1 case c)).

Figure 4-1/3: Scenarios

Figure 4-1/4: Scenarios

Scenario 2b; Connection to IP via an assisting gsmSSF with relay function; IP not co-located with sssisting gsmSSF (Ref CS1 case c)).

Figure 4-1/5: Scenarios

Figure 4-1/6: Scenarios

Scenario 3, Connection to IP with relay function; IP co-located with gsmSSF (Ref CS1 case a)).

Figure 4-/7: Scenarios

Figure 4-1/8: Scenarios

Scenario 4, Connection to IP with relay function; IP not co-located with gsmSSF (Ref CS1 case a)).

Figure 4-1/9: Scenarios

Figure 4-1/10: Scenarios

Scenario 5, GPRS interworking. No connection to IP.

Figure 4-1/11: Scenarios

The following table summarises the scenarios and corresponding interface connections that shall be supported by the CAP protocol. The following terms used in the table are defined as follows:

Basic: Fully defined in CAP and may be used between any two network operators supporting CAP.

Bilateral: Additional clarifications of CAP capabilities between network operators and/or equipment vendors are necessary in order for CAP to be used between any two network operators supporting CAP.

Direct: This refers to the case where CAP Operations are exchanged between the gsmSRF and the gsmSCF via a transaction-level relationship established directly between the gsmSRF and the gsmSCF.

Relay: This refers to the case where CAP Operations are exchanged between the gsmSRF and the gsmSCF via two transaction-layer relationships. These relationships are:

– gsmSCF to/from gsmSSF;

– gsmSSF to/from gsmSRF.

The gsmSSF sends operations it receives from the gsmSCF to the gsmSRF, and operations it receives from the gsmSRF to the gsmSCF. This is done without unpacking (and thus processing) of the relayed operations.

The gsmSSF function referred to in the table is always located in an MSC or GMSC.

The gprsSSF function referred to in the table is always located in an SGSN.

Table 4-1

Scenario	Interface Support
	GsmSSF to/from gsmSCF	gsmSSF to/from gsmSRF	gsmSSF to/from assisting gsmSSF	gsmSRF to/from gsmSCF	assisting gsmSSF to/from gsmSCF
Scenario 1 gsmSRF in IP connected to gsmSSF in MSC or GMSC via ISUP and accessed by gsmSCF through direct Signalling System No.7 Connection	See Note 1	See Note 2	–	See Notes 3 and 6. For gsmSRF in VPLMN see Note 4; For gsmSRF in HPLMN see note 5	–
Scenario 2a assisting gsmSSF in MSC or GMSC connected to gsmSSF in MSC or GMSC via ISUP. Assisting gsmSSF is accessed by gsmSCF through direct Signalling System No.7 Connection. gsmSRF is co-located with assisting gsmSSF and accessed (by gsmSCF) by relay via assisting gsmSSF over an internal nodal interface	See Note 1 For gsmSRF in VPLMN see Notes 4 and 6; For gsmSRF in HPLMN see note 5 and 6	–	See Note 2	–	See Note 3
Scenario 2b assisting gsmSSF in MSC or GMSC connected to gsmSSF in MSC or GMSC via ISUP. Assisting gsmSSF is accessed by gsmSCF through direct Signalling System No.7 Connection gsmSRF is in IP connected to assisting gsmSSF and accessed (by gsmSCF) by relay through ISUP or DSS1 via assisting gsmSSF	See Note 1 See Notes 4 and 6	See Notes 4 and 6	See Note 2	–	See Note 3
Scenario 3 gsmSRF is co-located with a gsmSSF in an MSC or GMSC and accessed by relay via gsmSSF over an internal nodal interface	For gsmSRF in VPLMN see Notes 4; For gsmSRF in HPLMN see notes 5 and 6	–	–	–	–
Scenario 4 gsmSRF in IP connected to gsmSSF and accessed by gsmSCF by relay through ISUP or DSS1 via gsmSSF	See Notes 4 and 6	See Notes 4 and 6	–	–	–

NOTE 1: Basic for establishment of interface when CorrelationID and SCFiD are transferred in the AssistingSSPIPRoutingAddress. Bilateral when CorrelationID and SCFiD are transferred by other means than in the AssistingSSPIPRoutingAddress.

NOTE 2: Basic for establishment of interface when CorrelationID and SCFiD are transferred in the Called Party Number. Bilateral when CorrelationID and SCFiD are transferred by other means than in the Called Party Number.

NOTE 3: Basic when the full Called Party Number received in VPLMN or HPLMN is transferred on its own in the AssistRequestInstructions operation CorrelationID parameter to a gsmSCF in HPLMN.

Bilateral when CorrelationID is extracted from Called Party Number in HPLMN or VPLMN and transferred on its own in AssistRequestInstructions CorrelationID field to a gsmSCF in HPLMN.

NOTE 4: Bilateral for the playing of announcements via elementaryMessageIDs and variableMessages, playing of tones and the collection of DTMF digits.

NOTE 5: Basic for the playing of announcements via elementaryMessageIDs and variableMessages, playing of tones and the collection of DTMF digits.

NOTE 6: Bilateral for the playing of announcements via text to speech translation, translation of DTMF digits via speech to caller and the translation of voice to digits.

4.1.3 CAP protocol architecture

Many of the terms used in the present subclause are based on the OSI application layer structure as defined in ISO 9545 (1989) [81].

The CAP protocol architecture is illustrated in figure 4‑2.

A Physical Entity (PE) has either single interactions (case a) or multiple co‑ordinated interactions (case b) with another PE.

In case (a), SACF provides a co‑ordination function in using Application Service Elements (ASEs), which includes the ordering of operations supported by ASE(s), in the order of received primitives. The Single Association Object (SAO) represents the SACF plus a set of ASEs to be used over a single interaction between a pair of PEs.

In case (b), MACF provides a co‑ordinating function among several SAO’s, each of which interacts with an SAO in a remote PE.

Each ASE supports one or more operations. Description of each operation is tied with the action of corresponding Functional Entity (FE) modelling. For FE modelling, refer to ITU‑T Recommendation Q.1224 [50] and clause 11 of the present document. Each operation is specified using the OPERATION macro described in figure 4‑3.

NOTE: CAP is the collection of all specifications in ASEs.

Figure 4‑2: CAP protocol architecture

Figure 4-3: Operation description

4.1.4 Compatibility mechanisms used for CAP

4.1.4.1 Introduction

The present subclause specifies the compatibility mechanisms that shall be used for CAP.

Two major categories of compatibility are handled by these mechanisms:

– compatibility with the ITU‑T Recommendation Q.1228 [51] version of CS2 INAP and the specification EN 301 140-1 version of CS2 INAP [26];

– compatibility with future versions of CAP.

The second category has three subcategories of compatibility dealt with within the present subclause:

– Minor changes to CAP in future versions of CAP:
A minor change can be defined as a change of a functionality which is not essential for the requested IN service. Where it is a modification of an existing function, it is acceptable that the addressed function is executed in either the older or the modified variant. If the change is purely additional, then it is acceptable that it is not executed at all and that the peer Application Entity (AE) need not know about the effects of the change. For minor changes, a new Application Context is not required.

– Major changes to CAP in future versions of CAP:
A major change can be defined as a change of a functionality which is essential for the requested IN service. Where it is a modification of an existing function, both application entities shall have a shared knowledge about the addressed functional variant. If the change is purely additional and one of the application entities does not support the additional functionality, then the requested IN service will not be provided. For major changes, a new Application Context is required.

– Network-specific changes to CAP:
These additions may be of either the major or minor type for a service. No new Application Context is expected to be defined for this type of change. At the time of definition of these network-specific changes to CAP, the additions would not be expected to be included in identical form in future versions of CAP.

4.1.4.2 Definition of CAP compatibility mechanisms

4.1.4.2.1 Compatibility mechanism for interworking of CAP with ETSI CS2 Core INAP and ITU‑T Q.1228 INAP

On receipt of an operation according to ITU‑T Recommendation Q.1228 [51] or an operation according to ETSI EN 301 140-1 [26], which is not part of the CAP or is part of the CAP but which contains parameters which are not part of the CAP:

– the gsmSSF, gsmSCF, assisting gsmSSF and gsmSRF shall apply the normal error handling for unknown operations or parameters, i.e. the normal error handling procedures as specified in clause 10 shall be followed.

Tagging of CAP additions to ITU‑T Recommendation Q.1228 [51] and ETSI EN 301 140-1 [26] are specified from 50 to 59.

4.1.4.2.2 Procedures for major additions to CAP

In order to support the introduction of major functional changes, the protocol allows a synchronisation between the two applications with regard to which functionality is to be performed. This synchronisation takes place before the new function is invoked in either application entity, in order to avoid complicated fall-back procedures.

4.1.4.2.3 Procedures for minor additions to CAP

The extension mechanism marker shall be used for future standardised minor additions to CAP. This mechanism implements extensions by including an "extensions marker" in the type definition. The extensions are expressed by optional fields that are placed after the marker. When an entity receives unrecognised parameters that occur after the extension marker, they are ignored. Refer to ITU-T Recommendation X.680 [53] for further details on the extension mechanism.

4.1.4.2.4 Procedures for inclusion of network specific additions to CAP

This mechanism is based on the ability to explicitly declare fields of any type via the Macro facility in ASN.1 at the outermost level of a type definition. It works by defining an "ExtensionField" that is placed within the type definition. This extension field is defined as a set of extensions, where an extension can contain any type. Each extension is associated with an identification that unambiguously identifies the extension. Refer to ITU‑T Recommendation Q.1400 [52] for a definition of this mechanism.

4.1.5 Definition and usage of LegID

4.1.5.1 Definition of LegID

In CAP V4, two types of LegID may be exchanged between the gsmSCF and the gsmSSF. These are:

– Sending Side LegID; and

– Receiving Side LegID.

Sending Side LegID is always used in operations sent from the gsmSCF to the gsmSSF, and Receiving Side LegID is always used in operations sent from the gsmSSF to the gsmSCF.

4.1.5.2 Allocation of LegID

For all operations containing a LegID:

– LegID = 1 shall always refer to the Calling Party, more specifically that party in the call present when InitialDP is sent to the gsmSCF;

– LegID = 2 shall always refer to a Called Party, more specifically a party in the call created as a result of the InitialDP operation, followed by the Connect, Continue or ContinueWithArgument operation.

– LegID > 2 shall always refer to a Called Party, more specifically a party in the call created as a result of the InitiateCallAttempt operation, followed by the ContinueWithArgument operation.

4.2 SACF/MACF rules

4.2.1 Reflection of TC AC

TC AC negotiation rules require that the proposed AC, if acceptable, is reflected in the first backwards message.

NOTE: If the gsmSSF, gprsSSF or smsSSF provides an AC which is not acceptable to the gsmSCF, then an alternate AC shall not be returned. If the AC presented to the gsmSCF is not acceptable, then this is most probably due to an error in subscriber data provisioning or an error at the gsmSSF, gprsSSF or smsSSF.

4.2.2 Sequential/parallel execution of operations

In some cases it may be necessary to distinguish whether operations should be performed sequentially or in parallel (synchronised). Operations which may be synchronised are:

– charging operations; may be synchronised with any other operation(s).

The method of indicating to the receiving entity that operations should be synchronised is to transmit these operations in a single TC message. If one of the operations identified above shall not be executed until the execution of another operation has progressed to a certain extent or has finished, then the sending PE shall control this by sending the operations in two separate TC messages.

This method does not imply that all operations sent in a single TC message shall be executed simultaneously, but that where it could make sense to do so (in the situations identified above) the operations should be synchronised.

In the case of inconsistency between the above-mentioned generic rules and the FE-specific rules, as specified in clause 9, the FE-specific rules take precedence over the generic rules.