Document Part Number: P_EXCL_CAMEL_UG_2.5

COPYRIGHT Copyright © 2003 IntelliNet Technologies, Inc. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or any means electronic or mechanical, including photocopying and recording for any purpose other than the reader’s personal use without the written permission of IntelliNet Technologies, Inc.

Information in this document is subject to change without notice.

IntelliNet Technologies 1990 W. New Haven Ave., Suite 307 Melbourne, FL 32904 U.S.A.

Phone: +1 321 726 0686 Fax: +1 321 726 0683 Web site: www.intellinet-tech.com

TRADEMARKS IntelliNet Technologies and the IntelliNet Technologies logo are trademarks of IntelliNet Technologies, Inc. Other brands and their products are registered trademarks or trademarks of their respective owners.

2

CAMEL User’s Guide Revision History

Revision Date Notes Rev. 1.0 7-9-2003 Begin document modification for Lucent Excel (P. Arteaga) Rev. 2.0 7-30-2003 Contents of the document reorganized per Gururaj and Santanu (Shobha). Rev. 2.1 9-10-2003 Added details of every message (Invoke and Response) along with the associated parameters and the header files in Chapter 3 (Shobha). Rev. 2.2 9-11-2003 Updated Chapter 5 (Shobha). Rev. 2.3 9-15-2003 Added licensing section (Shobha). Rev. 2.4 11-07-2003 Added section Building and Running CAMEL Application on HP-UX (Shobha). Rev. 2.5 11-10-2003 Added section Building and Running CAMEL Application on Linux (Shobha).

3

CAMEL User’s Guide Contents

Revision History ...... 3

About This Guide...... 7

Document Organization...... 7

Audience...... 7

References...... 7

1 Introduction to CAMEL...... 9 1.1 CAMEL Overview ...... 9 1.1.1 CAMEL Version Information ...... 10 1.2 CAMEL Network Architecture...... 11 1.2.1 Functional Entities Used for CAMEL...... 12 1.3 Detection Points (DPs) ...... 13 1.3.1 Definition and Description...... 13 1.3.2 DP Processing Rules...... 14 1.4 IntelliNet’s CAMEL API Key Features...... 14 2 CAMEL and TCAP Interaction...... 15 2.1 TCAP Overview...... 15 2.1.1 Transaction Portion...... 16 2.1.2 Dialogue Portion...... 19 2.1.3 Component Portion...... 23 2.2 Services Assumed from TCAP...... 30 2.2.1 Common Procedures...... 31 3 CAMEL Messages ...... 40 3.1 Circuit Switched Call Control...... 40 3.1.1 ApplyCharging...... 40 3.1.2 ApplyChargingReport...... 41 3.1.3 AssistRequestInstructions...... 42 3.1.4 CallGap ...... 43 3.1.5 CallInformationReport...... 44 3.1.6 CallInformationRequest...... 45 3.1.7 Cancel...... 46 3.1.8 Connect...... 47 3.1.9 ConnectToResource ...... 48 3.1.10 ContinueWithArgument...... 49 3.1.11 DisconnectForwardConnectionWithArgument...... 50 3.1.12 DisconnectLeg ...... 51 3.1.13 EntityReleased...... 52 3.1.14 EstablishTemporaryConnection ...... 53 3.1.15 EventNotificationCharging...... 54 3.1.16 EventReportBCSM...... 55

4

CAMEL User’s Guide

3.1.17 FurnishChargingInformation...... 56 3.1.18 InitialDP...... 57 3.1.19 InitiateCallAttempt...... 59 3.1.20 MoveLeg...... 60 3.1.21 PlayAnnouncement...... 61 3.1.22 PlayTone...... 62 3.1.23 PromptAndCollectUserInformation...... 63 3.1.24 ReceivedInformation...... 64 3.1.25 ReleaseCall...... 65 3.1.26 RequestNotificationChargingEvent ...... 66 3.1.27 RequestReportBCSMEvent ...... 67 3.1.28 ResetTimer...... 68 3.1.29 SendChargingInformation...... 69 3.1.30 SpecializedResourceReport...... 70 3.1.31 SplitLeg...... 71 3.2 SMS Control...... 72 3.2.1 ConnectSMS...... 72 3.2.2 EventReportSMS...... 73 3.2.3 FurnishChargingInformationSMS ...... 74 3.2.4 InitialDPSMS...... 75 3.2.5 ReleaseSMS...... 76 3.2.6 RequestReportSMSEvent...... 77 3.2.7 ResetTimerSMS...... 78 3.3 GPRS Control ...... 79 3.3.1 ApplyChargingGPRS...... 79 3.3.2 ApplyChargingReportGPRS...... 80 3.3.3 CancelGPRS...... 81 3.3.4 ConnectGPRS ...... 82 3.3.5 ContinueGPRS...... 83 3.3.6 EntityReleasedGPRS...... 84 3.3.7 EventReportGPRS...... 85 3.3.8 FurnishChargingInformationGPRS...... 86 3.3.9 InitialDPGPRS...... 87 3.3.10 ReleaseGPRS...... 88 3.3.11 RequestReportGPRSEvent...... 89 3.3.12 ResetTimerGPRS...... 90 3.3.13 SendChargingInformationGPRS...... 91 4 Designing an Encoder – Decoder Application ...... 92 4.1 Encoding CAMEL Operation...... 92 4.1.1 Step 1 -- Setting Parameters in the Message...... 93 4.1.2 Step 2 – Converting to ASN BER Format...... 94 4.1.3 Step 3 -- Memory Allocation/Deallocation During Encoding...... 95 4.1.4 Exception Handling while Encoding...... 95 4.1.5 Pretty Printing Raw Bytes and Encoded Message...... 95 4.2 Decoding CAMEL Operation...... 97 4.2.1 Parameter Retrieval from Decoded Message...... 98 4.2.2 Memory Allocation/Deallocation During Decoding ...... 99 4.2.3 Exception Handling while Decoding ...... 100 4.2.4 Pretty Printing the Decoded Message ...... 100 5 Integrating Encoder – Decoder with SKTAL and SKIM...... 101 5.1 SKIM Sample Application...... 101

5

CAMEL User’s Guide

5.1.1 Creating a Connection with LLC Using Switch Kit APIs...... 101 5.1.2 Creating an Instance of SKIM API Class...... 101 5.1.3 Sending a TCAP Transaction...... 102 5.1.4 Receiving a TCAP Transaction...... 103 5.1.5 Receiving Notifications ...... 105 5.1.6 Terminating SKIM API Object and Disconnect...... 106 5.2 SKTAL Sample Application...... 107 5.2.1 Creating a Connection with LLC Using Switch Kit APIs...... 107 5.2.2 Initializing SKTAL and Registering SSN ...... 107 5.2.3 Sending a TCAP Dialogue and Component ...... 108 5.2.4 Receiving a TCAP Transaction...... 109 5.2.5 Terminating SKTAL and Disconnecting...... 110 6 Building and Running CAMEL Application...... 111 6.1 Building and Running CAMEL Application on Solaris...... 111 6.1.1 Prerequisites for Building CAMEL Application ...... 111 6.1.2 Compiling CAMEL Application...... 111 6.1.3 Linking CAMEL Application...... 112 6.1.4 Running CAMEL Application ...... 112 6.2 Building and Running CAMEL Application on HP-UX...... 113 6.2.1 Prerequisites for Building CAMEL Application ...... 113 6.2.2 Compiling CAMEL Application...... 113 6.2.3 Linking CAMEL Application...... 113 6.2.4 Running CAMEL Application ...... 114 6.3 Building and Running CAMEL Application on Linux...... 115 6.3.1 Prerequisites for Building CAMEL Application ...... 115 6.3.2 Compiling CAMEL Application...... 115 6.3.3 Linking CAMEL Application...... 115 6.3.4 Running CAMEL Application ...... 116 6.4 Licensing For CAMEL API ...... 117 6.4.1 License Information...... 117 A1 CAMEL Error Codes...... 119

A2 CAMEL Operations...... 120

A3 Index...... 123

6

CAMEL User’s Guide

About This Guide

This manual is meant as a resource to understand the IntelliNet's CAMEL APIs. This guide also describes the integration of CAMEL API with SK_TAL (Switch Kit TCAP Abstraction Layer) and SK_IM (Switch Kit Interface Module) on Excel platform for application development.

Document Organization

CAMEL User's Guide contains the following information: No Title Description 1 Introduction to CAMEL Overview of CAMEL protocols. 2 CAMEL and TCAP Interaction TCAP specific details for carrying CAMEL payload. 3 CAMEL Messages Describes CAMEL message formats and associated header files. 4 Designing an Encoder – Decoder Describes how to design an Encoder – Decoder Application application. 5 Integrating Encoder – Decoder with Provides information on integrating an Encoder – Decoder SKTAL and SKIM application with SKTAL and SKIM. 6 Building and Running CAMEL Provides information on building and running a CAMEL Application application.

Audience

CAMEL User's Guide is written for network operators, administrators, and application developers, who are using the IntelliNet's CAMEL APIs. The following knowledge is highly recommended for individuals using this guide:  Telecommunications application development as specified by the ANSI/CCITT standards  SS7 protocols, including MTP level up through Application Programming Interfaces (APIs)  SS7 and IP network hardware and operations

References

 ETSI TS 129 078 V5.5.0 (2002-06), 3G TS 29.078 version 5.5.0 Release 2002 Digital cellular telecommunications system (Phase 2+) (GSM) Universal Mobile Telecommunications System (UMTS), Customized Applications for Mobile network Enhanced Logic (CAMEL) CAMEL Application Part (CAP) specification  ITU-T Q.771 (06/97) - SERIES Q: SWITCHING AND SIGNALLING Specifications of Signaling System No. 7 - Transaction capabilities application part - Functional description of transaction capabilities

7

CAMEL User’s Guide

 ITU-T Q.772 (06/97) - SERIES Q: SWITCHING AND SIGNALLING Specifications of Signaling System No. 7 - Transaction capabilities application part - Transaction capabilities information element definitions  ITU-T Q.773 (06/97) - SERIES Q: SWITCHING AND SIGNALLING Specifications of Signaling System No. 7 - Transaction capabilities application part - Transaction capabilities formats and encoding  ITU-T Q.774 (06/97) - SERIES Q: SWITCHING AND SIGNALLING Specifications of Signaling System No. 7 - Transaction capabilities application part - Transaction capabilities procedures

8 CChhaapptteerr 11 CAMEL User’s Guide

1 Introduction to CAMEL

This chapter provides following information:  CAMEL overview  CAMEL Network Architecture  Detection Points (DPs)  IntelliNet's CAMEL API Key Features

1.1 CAMEL Overview CAMEL (Customized Application for Mobile Network Enhanced Logic), a platform created by the European Telecommunication Standardization Institute (ETSI), introduces the concept of Intelligent Networks (IN) in the GSM mobile radio system. Taking the increasing competition of GSM networks into account, a standard was created to enable competition between operators based on the services offered.

CAMEL provides the GSM operator with the ability to offer operator specific services based on IN service logic to a GSM subscriber even when roaming outside the home PLMN. CAMEL is a network feature and not a supplementary service. It is a tool for the network operator to provide the subscribers with the operator specific services even when roaming in another network.

The CAMEL enables the network operator, or Home Location Register (HLR) to provide support not normally covered by the GSM even when roaming outside the Home Public Land Mobile Network (HPLMN). The CAMEL protocol supports:  Mobile originated and forwarded calls  Mobile terminating calls  Anytime interrogation  Suppression of announcements  Announcements and in-band user interaction  Charging features  Supplementary service invocation notifications  USSD interaction with the gsmSCF  North American carrier selection CAMEL is divided into several phases. The first phase of the standard was approved in 1997. The standardization of the second phase was finalized in 1998.

CAMEL makes use of IN SSP-SCP interface. CAMEL application protocol (CAP) Phase 1 and 2 are based on ETSI Core INAP CS-1R. CAMEL uncouples the service control from the control of the trunking scheme and then transmits it from the switching center computers to separate computers. Accordingly, it is no longer necessary to load the corresponding software in all Mobile Switching Centers (MSCs) to accommodate new services.

9 11 I nt roduct ion t o CAMEL

CAMEL Phase 4 Application Programming Interface (API), allows a host of new capabilities and features including interactions with Optimal Routing, CAMEL control over MT SMS (Mobile Terminated-Short Message Service), and the provision of location information of the called subscriber. CAMEL is a TCAP based protocol. The CAMEL protocol requires connection-less SCCP and TCAP to run. The SS7 stack with the CAMEL protocol is depicted in the following figure.

1.1.1 CAMEL Version I nformation This section provides information on supported CAMEL versions.

CAMEL Phase 2 Specification identification: ETSI TS 101 046 V7.0.0 Digital cellular telecommunications system (Phase 2+); Customized Applications for Mobile network Enhanced Logic (CAMEL) Stage 2.

CAMEL Phase 3 Specification identification: ETSI TS 129 078 V3.3.0 (2000-03) Digital cellular telecommunications system (Phase 2+) (GSM) Universal Mobile Telecommunications System (UMTS); Customized Applications for Mobile network Enhanced Logic (CAMEL) CAMEL Application Part (CAP) specification (3G TS 29.078 version 3.3.0 Release 1999).

CAMEL Phase 4 Specification identification: ETSI TS 129 078 V5.5.0 (2002-06) Digital cellular telecommunications system (Phase 2+) (GSM) Universal Mobile Telecommunications System (UMTS); Customized Applications for Mobile network Enhanced Logic (CAMEL) CAMEL Application Part (CAP) specification (3G TS 29.078 version 5.5.0 Release 2002).

10 11 I nt roduct ion t o CAMEL

1.2 CAMEL Network Architecture This section describes the functional architecture needed to support CAMEL. Also, describes the additions needed to the basic GSM functionality. The following Figure shows the functional entities involved in calls requiring CAMEL support. The architecture is applicable to the first phase of CAMEL

11 11 I nt roduct ion t o CAMEL

1.2.1 Functional Entities Used for CAMEL This section describes the CAMEL functional entities.

HLR The HLR stores the O/T-CSI for subscribers requiring CAMEL support. The O-CSI is sent to the VLR in case of Location Update or if the O-CSI is updated. The O/T-CSI is sent to the GMSC when the HLR responds to a request for routing information. The HLR may provide an interface towards the gsmSCF for the Any Time Interrogation procedure.

GMSC When processing the calls for subscribers requiring CAMEL support the GMSC receives a O/T-CSI from the HLR, indicating the GMSC to request instruction from the gsmSSF. The GMSC monitors on request the call states (events) and informs the gsmSSF of these states during processing enabling the gsmSSF to control the execution of the call in the GMSC.

MSC When processing the calls for subscribers requiring CAMEL support the MSC receives a O-CSI from the VLR indicating the MSC to request instruction from the gsmSSF. The MSC monitors on request the call states (events) and informs the gsmSSF of these states during processing enabling the gsmSSF to control the execution of the call in the MSC.

VLR The VLR stores the O-CSI as part of the subscriber data for subscribers roaming in the VLR area.

GSM Service Control Function (gsmSCF) A functional entity that contains the CAMEL service logic is to implement OSS. It interfaces with the gsmSSF and the HLR. This contains the service logic providing the logical control to be applied to a call involving an Intelligent Network service. This handles service-related processing activities such as analysis of dialed digits & screening of numbers. It interacts with other entities such as the MSC to obtain information to process a call.

GSM Service Switching Function (gsmSSF) gsmSSF is a functional entity that interfaces the MSC/GMSC to the gsmSCF. The concept of the gsmSSF is derived from the IN SSF, but uses different triggering mechanisms because of the nature of the mobile network.. This provides the means to recognize calls requiring IN service processing and to interact with call processing and the service logic on behalf of those calls.

12 11 I nt roduct ion t o CAMEL

1.3 Detection Points (DPs) This section provides information on DP definition, DP description, and DP processing rules.

1.3.1 Definition and Description Certain basic call events may be visible to the GSM Service Control Function (gsmSCF). The DPs are the points in call at which these events are detected. A DP can be armed in order to notify the gsmSCF that the DP was encountered, and potentially to allow the gsmSCF to influence subsequent handling of the call. If the DP is not armed, the processing entity continues the processing without gmSCF involvement. Three different types of DPs are identified:  Trigger Detection Point - Request (TDP-R) - This detection point is statically armed and initiates a CAMEL control relationship when encountered. Processing is suspended when the DP is encountered.  Event Detection Point - Request (EDP-R) - This detection point is dynamically armed within the context of a CAMEL control relationship. Processing is suspended awaiting instructions from the gsmSCF when encountering the DP.  Event Detection Point - Notification (EDP-N) - This detection point is dynamically armed within the context of a CAMEL control relationship. Processing is not suspended when encountering the DP.

The DPs are characterized by the following attributes:  Arming/disarming mechanism - The mechanism by which the DP is armed. A DP may be statically armed or dynamically armed. The following arming rules apply: o Provisioning the O/T-CSI in the HLR statically arms a DP. A statically armed DP remains armed until the O/T-CSI is withdrawn. o A DP is dynamically armed by the gsmSCF within the context of a CAMEL control relationship (between the gsmSSF and the gsmSCF). The following disarming rules apply: o A statically armed DP is disarmed when a O/T-CSI is withdrawn in the HLR. Only TDP-Rs can be disarmed using this mechanism. o If an armed EDP is met, then it is disarmed. o If an EDP is met that causes the release of the related leg, then all EDPs related to that leg are disarmed. o If a call is released, then all EDPs related to that call are disarmed.  Relationship - given that an armed DP was encountered, the gsmSSF provides an information flow via a relationship. A relationship between the gsmSSF and the gsmSCF for the purpose of operator specific service processing is considered to be a CAMEL relationship. There are two types of CAMEL relationships: o A CAMEL control relationship if the gsmSCF is able to influence the call processing via the relationship. o A CAMEL monitor relationship if the gsmSCF is not able to influence the call processing via the relationship.

13 11 I nt roduct ion t o CAMEL

1.3.2 DP Processing Rules Since a DP may be armed as an EDP-N or an EDP-R for the same call, the gsmSSF should apply the following set of rules during DP processing to ensure single point of control:  A control relationship persists as long as there is ˜ 1 EDP-R armed for this portion of the call. A control relationship terminates if there are no more EDP-Rs armed or the call clears. During a control relationship, EDPs are disarmed by the gsmSSF as they are encountered and reported to the SCF, or when the call clears.  A control relationship changes to a monitor relationship if there are no more EDP-Rs armed and ˜ 1 EDP-N armed. A monitor relationship terminates if there are no more EDP-Ns armed or the call clears. During a monitor relationship, EDP-Ns are disarmed by the gsmSSF as they are encountered and reported to the SCF, or when the call clears. When the armed TDP-R is encountered triggering is unconditional.

1.4 IntelliNet’s CAMEL API Key Features The following are the features:  Compliant with current GSM standard  Easy to use API in C++  Platform-independent and object-oriented implementation  Available on a number of platforms  Thread safe allowing development of multi-threaded applications

14 CChhaapptteerr 22 CAMEL User’s Guide

2 CAMEL and TCAP Interaction

This chapter provides information about TCAP specific details for carrying CAMEL payload.

2.1 TCAP Overview The TCAP message format consists of three parts, namely the transaction portion, the dialogue portion and the component portion. Information in the component portion concerns individual operations and their replies. The transaction portion contains protocol control information for the transaction sub layer. The dialogue portion is concerned with the application context and, as an option, user information (that is, the data, which are not components). The message units within TCAP are partitioned into three portions:  Transaction Portion  Dialog Portion  Component Portion The following figure shows the detailed TCAP message structure.

15 22 CAMEL and TCAP I nt er act ion

2.1.1 Transaction Portion The transaction portion provides the information necessary for the signaling point to route the component information to its destination. Included in the transaction portion is the transaction ID, which is used as a reference for tracking all TCAP messages. Significant is the length of the TCAP message in its entirety. The transaction portion provides the necessary data for the receiver to be able to determine the nature of the message and its relation to any existing transactions in progress The transaction portion of a TC message may contain the following information elements, namely:

Message Type Five types of messages are defined for the transaction portion as follows:  Unidirectional: This message is used when there is no need to establish a transaction with another peer TR-User.  Begin: This message is used to initiate a transaction with another peer TR-User.  End: This message is used to terminate a transaction with another peer TR-User.  Continue: This message is used to complete the establishment of a transaction and to continue an established transaction.  Abort: This message is used to terminate a transaction following an abnormal situation detected by the transaction sub layer (the service provider), or to abort a transaction by the TR-User (the service user).

Transaction I Ds Transaction IDs are independently assigned by each of the two nodes communicating via a transaction, enabling each node to uniquely identify the transaction and associate the entire contents of the message with that particular transaction. There are two types of Transaction IDs, namely:  Originating transaction ID: The Originating Transaction ID is assigned by the node sending a message, and is used to identify the transaction at that end.  Destination transaction ID: The Destination Transaction ID identifies the transaction at the receiving end.

P-abort Cause This is used when the transaction sub layer aborts a transaction. P-Abort cause definitions are as follows:  Unrecognized message type: The message type is not one of those defined in the above sections.  Unrecognized transaction ID: A transaction ID has been received for which a transaction does not exist at the receiving node.  Badly formatted transaction portion: The transaction portion of the received message does not conform to the X.209 encoding rules as outlined in 4.1/Q.773.  Incorrect transaction portion: The elemental structure within the transaction portion of the received message does not conform to the rules for the transaction portion defined in 3.1/Q.773.  Resource limitation: Sufficient resources are not available to start a transaction.

16 22 CAMEL and TCAP I nt er act ion

The message type field consists of one octet and is mandatory for all TCAP messages. Message type tags are coded as shown in the following table. Message Type H G F E D C B A Unidirectional 0 1 1 0 0 0 0 1 Begin 0 1 1 0 0 0 1 0 (Reserved) 0 1 1 0 0 0 1 1 End 0 1 1 0 0 1 0 0 Continue 0 1 1 0 0 1 0 1 (Reserved) 0 1 1 0 0 1 1 0 Abort 0 1 1 0 0 1 1 1

The Transaction Portion fields for various message types are shown in the following tables.

Note Details for encoding each sub field in a table please refer to ITU-T Q.773 (06/97) - SERIES Q: SWITCHING AND SIGNALLING.

Refer the following table for Transaction Portion Fields Unidirectional message type. Element Form Fields of Transaction Portion Mandatory Indication Constructor Message Type Tag Mandatory Total message Lengtha) Constructor Dialogue Portion Optional Constructor Component Portion Tag Mandatory Component Portion Length Constructor One or more Components Mandatory (Not a part of Transaction Portion) (Described in 4.2.2)

Refer the following table for Transaction Portion Fields Begin message type. Element Form Fields of Transaction Portion Mandatory Indication Constructor Message Type Tag Mandatory Total message Lengtha) Primitive Originating Transaction ID Tag Mandatory Transaction ID Length Transaction ID Constructor Dialogue Portion Optional Constructor Component Portion Tag Optionalb) Component Portion Length Constructor One or more Components Optional (Not a part of Transaction Portion) (Described in 4.2.2)

17 22 CAMEL and TCAP I nt er act ion

Refer the following table for Transaction Portion Fields End message type. Element form Fields of Transaction Portion Mandatory Indication Constructor Message Type Tag Mandatory Total message Lengtha) Primitive Destination Transaction ID Tag Mandatory Transaction ID Length Transaction ID Constructor Dialogue Portion Optional Constructor Component Portion Tag Optionalb) Component Portion Length Constructor One or more Components Optional (Not a part of Transaction Portion) (Described in 4.2.2)

Refer the following table for Transaction Portion Fields Continue message type. Element Form Fields of Transaction Portion Mandatory Indication Constructor Message Type Tag Mandatory Total message Lengtha) Primitive Originating Transaction ID Tag Mandatory Transaction ID Length Transaction ID Primitive Destination Transaction ID Tag Mandatory Transaction ID Length Transaction ID Constructor Dialogue Portion Optional Constructor Component Portion Tag Optionalb) Component Portion Length Constructor One or more Components Optional (Not a part of Transaction Portion) (Described in 4.2.2)

Refer the following table for the Transaction Portion Fields Abort message type. Element Form Fields of Transaction Portion Mandatory Indication Constructor Message Type Tag Mandatory Total message Lengtha) Primitive Destination Transaction ID Tag Mandatory Transaction ID Length Transaction ID Primitive P-Abort Cause Tag Optionalb) P-Abort Cause Length P-Abort Cause Constructor Dialogue Portion Optionalc)

18 22 CAMEL and TCAP I nt er act ion

2.1.2 Dialogue Portion The dialogue portion contains a dialogue control Application Protocol Data Unit (APDU) or user information.

Dialogue Control APDUs  Dialogue Request (AARQ) APDU: The Dialogue Request (AARQ) APDU is used by the initiating TC-User at the start of a transaction to convey the Application Context Name and, as an option, user information (that is, data, which are not components) to the peer TC-User.  Dialogue Response (AARE) APDU: The Dialogue Response (AARE) APDU is used by the responding TC- User in the first backward message to inform the originating TC-User on whether or not the dialogue is accepted.  Dialogue Abort (ABRT) APDU: the component sub layer to inform its peer of the receipt of an abnormal (syntactically invalid or inopportune) dialogue portion APDU uses The Dialogue Abort (ABRT) APDU. It is also used by the TC-Users to terminate a dialogue due to an abnormal situation.  Dialogue Uni (AUDT) APDU: The Dialogue Uni (AUDT) APDU is used to convey the Application Context Name and, as an option, user information (that is, the data, which are not components) for the situation where there is no need to establish a dialogue between two TC-Users.

Dialogue Portion I nformation Elements  Application context name: This parameter, of the form OBJECT IDENTIFIER, is a reference to an explicitly defined set of the TC-User Application Service Elements (ASEs), related options and any other necessary information for the inter working of two TC-Users during an instance of communication.  Protocol version: The protocol version information element indicates the versions of the Dialogue Portion that can be supported. It is a bit string, where each bit that is set to one indicates the version of the dialogue portion that is supported. Bit 0 represents version 1, bit 1 represents version 2, and so on. The last bit set to one in the bit string is the highest selected version. When the Protocol version parameter is absent, it implies "version 1" which is the version corresponding to this Recommendation.  User information: User information corresponds to any information exchanged between two TC-Users. Depending on the Application Context Name that accompanies it or is in place during its use. For example, this parameter may be used to carry information that further refines the application context by providing the "versions" of the ASEs that are referenced, "initialization" information on the ASEs, etc. Its meaning and use are therefore outside the scope of these Recommendations.  Result: This parameter is set by the component sub layer to provide the initiating TC-User with the result of the request to establish a dialogue. Its value is set based on the dialogue handling primitive (and its accompanying parameters) used by the responding TC-User in response to the request for a dialogue. It takes the values "accepted" or "rejected (permanent)". The use of the value "rejected (transient)" is for further study.  Result source diagnostic: This parameter identifies the creating source of the Result parameter and qualifies the result with some diagnostic information. The value of this parameter is set by the component sub layer and takes the symbolic values "dialogue service user" or "dialogue service provider". If the Result parameter takes the value "accepted", this parameter’s value is set to "dialogue service user".  The "dialogue service user" can further qualify the result with a diagnostic with values of "null" or "no reason given" (for the case where no diagnostic is offered) or "application-context-name-not-supported" for the case when the dialogue is refused because the application context is not supported. The "dialogue service provider" can further qualify the result with a diagnostic with values of "null" or "no reason given" (for the case where no

19 22 CAMEL and TCAP I nt er act ion

diagnostic is offered) or "no common-dialogue-portion" (for the case, supporting the future evolution of these Recommendations, when the dialogue portions of the peer TC are different).  Abort source: This parameter identifies whether the abnormal release of the dialogue is due to a request by the TC-User or the initiated by the dialogue portion for which it takes the values, respectively, of "dialogue service user" or "dialogue service provider". The Dialogue Portion when present consists of one dialogue control protocol data unit or user information. The dialogue portion is type of EXTERNAL. The direct-reference element of the EXTERNAL type shall indicate the following abstract syntax name: { ccitt recommendation q 773 as (1) dialogue-as (1) version1 (1) } If structured dialogue is used and: { ccitt recommendation q 773 as (1) unidialogue-as (2) version1 (1) } If unstructured dialogue is used, the data value shall be one of the defined dialogue control protocol data units.

User information when a user shall identify present defined abstract syntax name.

Dialogue Control PDUs The dialogue portion when present consists of one of the following dialogue control protocol data units. Refer the following tables.

Note For details of encoding each info element refer to ITU-T Q.773 (06/97) - SERIES Q: SWITCHING AND SIGNALLING.

Refer the following table for Dialogue Portion. Element Form Dialogue Portion Mandatory Indication Constructor Dialogue Portion Tag Mandatory Dialogue Portion Length Constructor External Tag Mandatory External Length Constructor Structured or unstructured dialogue Mandatory

Refer the following table for Dialogue Portion Tag.

H G F E D C B A Dialogue Portion Taga) 0 1 1 0 1 0 1 1 a) [APPLICATION 11]

Refer the following table for External Tag. H G F E D C B A External Taga) 0 0 1 0 1 0 0 0 a) [UNIVERSAL 8]

20 22 CAMEL and TCAP I nt er act ion

Dialogues can be Structured or Unstructured. Refer the following table for Structured Dialogue. Element form Structured Dialogue Mandatory Indication Primitive Object Identifier Tag Mandatory Object Identifier Length Dialogue-as-ID value Constructor Single-ASN.1-type Taga) b) Mandatory Single-ASN.1-type Length Constructor Dialogue PDU Mandatory

Refer the following table for Unstructured Dialogue. Element form Unstructured Dialogue Mandatory Indication Primitive Object Identifier Tag Mandatory Object Identifier Length Unidialogue-as-ID value Constructor Single-ASN.1-type Taga) b) Mandatory Single-ASN.1-type Length Constructor Unidirectional Dialogue PDU Mandatory

Refer the following table for Dialogue Request (AARQ-apdu). Element Form Dialogue Request (AARQ-apdu) Mandatory Indication Constructor Dialogue Request Tag Mandatory Dialogue Request Length Primitive Protocol Version Tag Optionalb) Protocol Version Length Protocol Version Constructor Application Context Name Tag Mandatory Application Context Name Length Primitive Object Identifier Tag Mandatory Object Identifier Length Application Context Name a) Constructor User Information Tag Optional User Information Length User Information

Refer the following table for Dialogue Response (AARE-apdu). Element Form Dialogue Response (AARE-apdu) Mandatory Indication Constructor Dialogue Response Tag Mandatory Dialogue Response Length Primitive Protocol Version Tag Optionalb) Protocol Version Length Protocol Version Constructor Application Context Name Tag Mandatory Application Context Name Length

21 22 CAMEL and TCAP I nt er act ion

Primitive Object Identifier Tag Mandatory Object Identifier Length Application Context Namea) Constructor Result Tag Mandatory Result Length INTEGER Tag INTEGER Length Result Constructor Result Source Diagnostic Tag Mandatory Result Source Diagnostic Length Result Source Diagnostic Constructor User Information Tag Optional User Information Length User information

Refer the following table for Dialogue Abort (ABRT-apdu). Element Form Dialogue Abort (ABRT-apdu) Mandatory Indication Constructor Dialogue Abort Tag Mandatory Dialogue Abort Length Primitive Abort Source Tag Mandatory Abort Source Length Abort Source Constructor User Information Tag Optional User Information Length User Information

Refer the following table for Unidirectional Dialogue (AUDT-apdu). Element form Unidirectional Dialogue (AUDT-apdu) Mandatory Indication Constructor Unidirectional Dialogue Tag Mandatory Unidirectional Dialogue Length b) Primitive Protocol Version Tag Optional Protocol Version Length Protocol Version Constructor Application Context Name Tag Mandatory Application Context Name Length Primitive Object Identifier Tag Mandatory Object Identifier Length a ) Application Context Name Constructor User Information Tag Optional User Information Length User Information

22 22 CAMEL and TCAP I nt er act ion

Refer the following table for Unidirectional Dialogue Tag. H G F E D C B A Unidirectional Dialogue Tag 0 1 1 0 0 0 0 0

2.1.3 Component Portion The Component Portion contains the following types of information elements. Components within a message are delivered to the user at the receiving end in the same order in which they were received from the user at the originating end.

Component Type There are five types of components that may be present in the Component Portion of a TC message. The four Protocol Data Units (PDUs) defined in Recommendation X.229 are used, namely:  Invoke: The invoke component requests that an operation be performed. It may be linked to another operation invocation previously sent by the other end. In this case it is known as a "Linked Invoke".  Return result (not last): When TC uses a connectionless Network Service, it may be necessary for the TC-User to segment the result of an operation if the two peer TC-users use a network service that does not provide segmenting/reassembling of user data. In this case the Return Result (Not Last) component is used to convey each segment of the result except the last, which is conveyed in a Return Result (Last) component.  The Return Result (Not Last) facility is allowed ONLY if the result is too large to fit into a single Return Result (Last) component. Note that the use of the Return Result (Not Last) facility implies that the operation has completed successfully.  Return result (last): The Return Result (Last) component reports successful completion of an operation. It may contain the last segment of a result. Or in the case of an un-segmented result, it contains the entire result.  Return error: The Return Error component reports that an operation has not been successfully completed.  Reject: The Reject component reports the receipt and rejection of an incorrect component, other than a Reject component. The possible causes for rejecting a component are defined by the Problem Code element.

I nvoke I D An Invoke ID is used as a reference number to identify uniquely an operation invocation. It is present in the Invoke component and in any reply to the Invoke (Return Result, Return Error or Reject), enabling the reply to be correlated with invoke.

Linked I D A Linked ID is included in an invoke component by a node when it responds to an operation invocation with a linked operation invocation. The node receiving the Linked ID uses it for correlation purposes, in the same way that it uses the invoke ID in Return Result, Return Error and Reject components.

23 22 CAMEL and TCAP I nt er act ion

Operation Code The Operation Code element indicates the precise operation to be invoked, and is present in an Invoke component type. It is also present in the Return Result (Last/Not Last) components if the results contain parameters. The operation code may be given a local value (that is, integer), which then identifies the operation within a limited domain; or it may be a global value (that is, object identifier), which makes the operation uniquely identifiable across all applications. The actual operation codes, the definition of the operations and their associated parameters, are defined in relevant ASE specifications. The component sub layer does not set or examine the operation code value, nor parameters, which are present, nor the parameter values.

Parameter The Parameter element contains one or several user information elements accompanying a component. The information elements themselves are defined in relevant ASE specifications.

Error Code The Error Code element contains the reason why an operation cannot be completed successfully. It is present only in a Return Error component. As with operations, errors may be local or global. These errors and associated parameters are defined in relevant ASE specifications.

Problem Code The Problem code element contains the reason for the rejection of a component, and one such element is present in a Reject component. Four problem code elements are defined, namely:  General problem - This element contains one of the problem codes which apply to the component sub layer in general, and which do not relate to any specific component type. The component sub layer generates all of these. They are: o Unrecognized component: The component type is not recognized. o Mistyped component: The elemental structure of a component does not conform to the structure of that component as defined in 3.1/Q.773. o Badly structured component: The contents of the component do not conform to the encoding rules defined in 4.1/Q.773. o Invoke problem: This element contains one of the problem codes that relate only to the invoke component type. They are: o Duplicate invoke ID: The invoke ID is that of a previously invoked operation which has not been completed. The TC-User generates this code. o Unrecognized operation: The operation code is not one of those agreed by the two TC-User. o Mistyped parameter: Signifies that the type of parameter in an invoke component is not that agreed by the two TC-Users.

24 22 CAMEL and TCAP I nt er act ion

o Resource limitation: Sufficient resources are not available to perform the requested operation. The TC-User generates this code. o Initiating release: The requested operation cannot be invoked because the dialogue is about to be released. This code is generated only by the TC-User. o Unrecognized linked ID: The linked ID does not correspond to an active invoke operation. Only the component sub layer generates this code. o Linked response unexpected: The operation referred to by the linked ID is not an operation for which linked invokes are allowed. Only the TC-User generates this code. o Unexpected linked operation: The operation referred to by the linked ID does not allow this linked operation. This code is generated only by the TC-User  Return result problem: This element contains one of the problem codes, which relate only to the return result component type. They are: o Unrecognized invoke ID: no operations with the specified invoke ID is in progress. This code is generated by the component sub layer o Return result unexpected: The invoked operation does not report success. This code is generated by the component sub layer o Mistyped parameter: Signifies that the type of parameter in the return result component is not that agreed by the two TC-Users  Return error problem: This element contains one of the problem codes that relate only to the return error component type. They are: o Unrecognized invoke ID: no operations with the specified invoke ID is in progress. This code is generated by the component sub layer o Return error unexpected: The invoked operation does not report failure. This code is generated by the component sub layer o Unrecognized error: The error code is not one of those agreed by the two TC-User o Unexpected error: The received error is not one of those that the invoked operation may report. This code is generated by the TC-User o Mistyped parameter: Signifies that the type parameter in a Return Error component is not that agreed by the two TC-Users

Component Type Tag Each Component is a sequence of information elements. The Component types, as defined for TCAP, have the structure indicated in the following tables.

The Component Portion Tag is coded as shown in the following table. H G F E D C B A Component Portion Tag 0 1 1 0 1 1 0 0

25 22 CAMEL and TCAP I nt er act ion

Refer the following table for Component Type Tag. Component Type Tag H G F E D C B A Invoke 1 0 1 0 0 0 0 1 Return Result (Last) 1 0 1 0 0 0 1 0 Return Error 1 0 1 0 0 0 1 1 Reject 1 0 1 0 0 1 0 0 (Reserved) 1 0 1 0 0 1 0 1 (Reserved) 1 0 1 0 0 1 1 0 Return Result (Not Last) 1 0 1 0 0 1 1 1 Refer the following tables for component types.

Note Details of encoding info elements please refer to ITU-T Q.773 (06/97) - SERIES Q: SWITCHING AND SIGNALLING.

Refer the following table for Invoke component. Element Form Invoke component Mandatory Indication Constructor Component Type Tag M Component Length Primitive Invoke ID Tag M Invoke ID Length Invoke ID Primitive Linked ID Tag O Linked ID Length Linked ID Primitive Operation Code Tag M Operation Code Length Operation Code Primitive/ Parameter Tag O constructor Parameter Length Parameters

26 22 CAMEL and TCAP I nt er act ion

Refer the following table for Return Result (Last) and Return Result (Not Last) components. Element Form Return Result (Last) and Return Result (Not Last) Mandatory Indication components Constructor Component Type Taga) M Component Length Primitive Invoke ID Tag M Invoke ID Length Invoke ID Constructor Sequence Tag Ob) Sequence Length Primitive Operation Code Tag Ob) Operation Code Length Operation Code Primitive/ Parameter Tag Ob) constructor Parameter Length Parameters

Refer the following table for Return Error Component. Element Form Return Error Component Mandatory Indication Constructor Component Type Tag M Component Length Primitive Invoke ID Tag M Invoke ID Length Invoke ID Primitive Error Code Tag M Error Code Length Error Code Primitive/ Parameter Tag O constructor Parameter Length Parameters

Refer the following table for Reject component. Element Form Reject component Mandatory Indication Constructor Component Type Tag M Component Length Primitive Invoke ID Taga) M Invoke ID Length Invoke ID Primitive Problem Code Tag M Problem Code Length Problem Code Note  The Component Type Tag is coded context-specific, constructor as indicated in the following table.  The format of a Return Result (Not Last) is identical to that of a Return Result (Last).

27 22 CAMEL and TCAP I nt er act ion

Component I D tag The term Component ID refers to the Invoke ID or the Linked ID. The Component ID tag is coded as shown in the following table. H G F E D C B A Invoke ID 0 0 0 0 0 0 1 0 Linked ID a) 1 0 0 0 0 0 0 0 The length of a Component ID is 1 octet. An Invoke Component has one or two Component IDs: an Invoke ID, and if it is desired to associate the Invoke with a previous Invoke, then the Linked ID is provided in addition to the Invoke ID.

Return Result and Return Error Components have one Component ID, called an Invoke ID, which is the reflection of the Invoke ID of the Invoke Component to which they are responding.

The Reject Component uses as its Invoke ID, the Invoke ID in the Component being rejected. If this ID is unavailable (for example, due to mutilation, of the message undetected by lower layers), then the Invoke ID tag is replaced with a universal NULL tag (which always has length = 0) as shown in the following table.

If an Invoke containing both Invoke and Linked IDs is being rejected, only the Invoke ID is used in the Reject Component. H G F E D C B A NULL tag 0 0 0 0 0 1 0 1

Operation Code Tag Each operation is assigned a value to identify it. Operations can be classified as local or global operations. A local operation code follows an Operation Code Tag and Operation Code length. The Operation Code Tag is coded as shown in the following table.

The Global Operation Code is coded as described in Recommendation X.208.

H G F E D C B A Local Operation Code Tag 0 0 0 0 0 0 1 0 Global Operation Code Tag 0 0 0 0 0 1 1 0

Parameter Tag The Parameter tag shall be any valid ASN.1 tag, depending on the type of the parameter supplied. It can indicate either a primitive or a constructor element and refer to any of the defined tag classes.

When the parameter element is a collection of several information elements, the associated data type shall be derived from the Sequence, SequenceOf, Set or SetOF types (refer the following table).

H G F E D C B A Sequence Tag 0 0 1 1 0 0 0 0 Set Tag 0 0 1 1 0 0 0 1

28 22 CAMEL and TCAP I nt er act ion

Error Code Tag Each error is assigned a value to identify it. Errors can be classified as local or global errors. A local error code follows the Error Code Tag and Error Code Length. The Error Code Tag is coded as shown in the following table. The Global Error Code is coded as an Object Identifier, which is described in Recommendation X.208. H G F E D C B A Local Error Code Tag 0 0 0 0 0 0 1 0 Global Error Code Tag 0 0 0 0 0 1 1 0

Problem Code The Problem Code consists of one of the four elements General Problem, Invoke Problem, Return Result Problem or Return Error Problem.

Refer the following table for Coding of Problem Type Tags. Problem Type H G F E D C B A General Problem 1 0 0 0 0 0 0 0 Invoke 1 0 0 0 0 0 0 1 Return Result 1 0 0 0 0 0 1 0 Return Error 1 0 0 0 0 0 1 1

Refer the following table for Coding of General Problem. H G F E D C B A Unrecognized Component a) 0 0 0 0 0 0 0 0 Mistyped Component a) 0 0 0 0 0 0 0 1 Badly Structured Component a) 0 0 0 0 0 0 1 0

Refer the following table for Coding of Invoke Problem. H G F E D C B A Duplicate Invoke ID 0 0 0 0 0 0 0 0 Unrecognized Operation 0 0 0 0 0 0 0 1 Mistyped Parameter a) 0 0 0 0 0 0 1 0 Resource Limitation 0 0 0 0 0 0 1 1 Initiating Releaseb) 0 0 0 0 0 1 0 0 Unrecognized Linked ID 0 0 0 0 0 1 0 1 Linked Response Unexpected 0 0 0 0 0 1 1 0 Unexpected Linked Operationc) 0 0 0 0 0 1 1 1

29 22 CAMEL and TCAP I nt er act ion

Refer the following table for Coding of Return Result Problem. H G F E D C B A Unrecognized Invoke ID 0 0 0 0 0 0 0 0 Return Result Unexpected 0 0 0 0 0 0 0 1 Mistyped Parameter a) 0 0 0 0 0 0 1 0

Refer the following table for Coding of Return Error Problem. H G F E D C B A Unrecognised Invoke ID 0 0 0 0 0 0 0 0 Return Error Unexpected 0 0 0 0 0 0 0 1 Unrecognised Error 0 0 0 0 0 0 1 0 Unexpected Error 0 0 0 0 0 0 1 1 Mistyped Parameter 0 0 0 0 0 1 0 0

2.2 Services Assumed from TCAP The SS7 application layer protocol 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 ACs is to be used for FE differentiation within a physical node then the version of TC used must support the dialogue portion of TC (that is, ETS 300 287-1 [6]). This requirement applies to all interfaces, not just those used for internetworking. The following table defines which versions of TC are the minimum versions required to support the defined CAP interfaces. Interface IN CS2 gsmSSF - gsmSCF Blue Book (note) gsmSCF - gsmSRF Blue Book (note) Note: If the AC name needs to be indicated, then ETS 300 287- 1 [6] is the minimum version required.

30 22 CAMEL and TCAP I nt er act ion

2.2.1 Common Procedures This section 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 the following sections.

Normal Procedures This section describes the procedures and TCAP 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 TCAP. 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: o 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 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 are discarded by TC as described in ETS 300 287-1 [6].

½ In case 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.

o 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 (that is, the relationship is terminated).

o In general, the use of prearranged end is 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.

Abnormal Procedures This section describes the procedures and TCAP primitives that shall be used for reporting abnormal situations between AEs. 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 TCAP 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.

31 22 CAMEL and TCAP I nt er act ion

 The TC-user with a TC-U-ABORT request primitive shall abort a dialogue.

 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 TCAP dialogue is established or not. For abnormal situations detected by TCAP the same rules applies 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 TCAP dialogue under abnormal situations:  In the case that abort condition is detected and TCAP dialogue is established, TCAP dialogue is terminated by TC-U-ABORT primitive with an Abort reason.  In the case that abort condition is detected and TCAP dialogue is not established, TCAP 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 TCAP dialogue. In 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, 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 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 according to the abnormal procedures as specified in ETS 300 287- 1 [6]).

Dialogue Handling This section provides information on dialogue handling. Dialogue Establishment The establishment of a CAP dialogue involves two application processes, one that is the dialogue-initiator and one that is the dialogue-responder. AC negotiation may not be supported in all PE 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: o A TC-END indication primitive occurring at the initiating side o A TC-U-ABORT indication primitive occurring at the initiating side o A TC-P-ABORT indication primitive occurring at the initiating side

32 22 CAMEL and TCAP I nt er act ion

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 requests the invocation of the associated operations using the TC-INVOKE service. 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 not issues 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 has to:  Analyze the application-context-name if included in the primitive. If it is supported, process any other indication primitives received from TC.  If the application-context-name included in the primitive is not supported, 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, TC-USER shall process the following TC component handling indication primitives, 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.

Receipt of a TC-U-ABORT Indication Receipt of a TC-U-ABORT indication primitive is described as part of user abort procedure.

Receipt of a TC-P-ABORT Indication Receipt of a TC-P-ABORT indication primitive is described as part of provider abort procedure. 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. 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 has to accept zero, one or several TC component handling indication primitives and process them.

33 22 CAMEL and TCAP I nt er act ion

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. 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 is no longer be maintained, TC-USER process any component handling request primitives. After processing the last component handling request primitive (if any), TC-USER has to issue a TC-END request primitive with the release method parameter set to "basic end" or "prearranged release", according to the rules.

Receipt of a TC-END Indication On receipt of a TC-END indication primitive, the TC-USER has to accept any component handling indication primitives and process them. After processing the last component handling primitive all dialogue related resources are released. 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. 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. Mapping to TC Dialogue Primitives CAP does not use the TC-UNI service. The mapping of parameters onto the TC Dialogue services is as follows:  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.

34 22 CAMEL and TCAP I nt er act ion

 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 is set to the unambiguous CAP address of the AE initiating the TC-BEGIN service. The use of parameters of the TC-CONTINUE service is with the following qualifications:  The AC Name parameter of the TC-CONTINUE service is set to the value of the AC Name parameter of the TC-BEGIN service for the same Dialogue ID parameter value.  If present, the Originating Address parameter of the TC-CONTINUE service is set to the unambiguous CAP address of the AE initiating the TC-CONTINUE service. This parameter is only present in the first TC-CONTINUE service after a TC-BEGIN service with the same Dialogue ID parameter value. The use of parameters of the TC-END service is with the following qualifications:  The AC Name parameter of the TC-END service has to be set to the value of the AC Name parameter of the TC-BEGIN service for the same Dialogue ID parameter value. This parameter is only present if the TC-END service is used immediately after the TC-BEGIN service. The use of parameters of the TC-U-ABORT service is with the following qualifications:  The Abort Reason parameter of the TC-U-ABORT service has to be used as specified in ETS 300 287-1 [6].  The AC Name parameter of the TC-U-ABORT service has to be set to the value used in the TC-BEGIN service. NOTE 2 - This parameter is only present 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 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 takes the values as defined in ETS 300 287-1 [6]. 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 according to the set of operations, which need to be supported by the TC dialogue.

User Information Both initiating and responding application processes can use this parameter. The receiving side may ignore this parameter if received. The User Information parameter shall be encoded in accordance with the definition provided in Q.773 (sub clause 3.2) [48] and the definition of EXTERNAL type provided in X.690 [34], with the restriction that:  A size (1..10) Constraint of SEQUENCE OF EXTERNAL  An Object Identifier is always present to identify the user information and the entity which sent it  A single-ASN-1-type is used for encoding

35 22 CAMEL and TCAP I nt er act ion

Component Present This parameter is used by TC-USER as described in ETS 300 287-1 [6].

Termination

The value of the release method parameter of the TC-END request primitive is set by TC-USER according to the rules.

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

Component Handling Procedures for CAP Operations This section 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 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, 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 CAP related dialogue is about to be released, requests the transfer of the 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, 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, 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, construct a result information element from the parameters received and request its transfer using the TC-RESULT-L service.

36 22 CAMEL and TCAP I nt er act ion

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

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 informs the application process.

On receipt of a TC-L-REJECT indicating" return error problem, return error unexpected", TC-USER informs 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. 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

37 22 CAMEL and TCAP I nt er act ion

 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 section describes the behavior 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 (that is, 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. This is also applicable for invoke problems related to a class 4 linked operation. On receipt of a TC-R-REJECT indication (that is, 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. On receipt of a TC-L-REJECT indication primitive (that is, 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 only occur if the Return Option has been set. 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 with the following qualifications:  The Operation parameter of the TC-INVOKE service contains the operation.&operationCode value of the CAP operation to be invoked. The operation must be one of the valid operations supported by the negotiated 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 with the following qualifications:  The Invoke Id parameter of the TC-RESULT-L service is 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 is 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 with the following qualifications:

38 22 CAMEL and TCAP I nt er act ion

 Invoke Id parameter of the TC-U-ERROR service is 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 is 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 is 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 with the following qualifications:  The Invoke Id parameter of the TC-U-REJECT service is set to the Invoke Id Parameter of the TC component service from the remote AE, which is being rejected. Default Mapping to TC Component Parameters Invoke Id The sending application process sets this parameter. It represents the unique identity of an instance of an operation, which is invoked by a AE within a specific TC dialogue. The TC dialogue is identified by the Dialogue Id parameter.

Linked Id The sending application process sets this parameter. 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 only present 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 carries 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.

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 ETS 300 287-1 [6].

Abort Reason This parameter is used by TC-USER, and network operator specifies attributes and coding.

39 CChhaapptteerr 33 CAMEL User’s Guide

3 CAMEL Messages

This chapter describes the messages for CAMEL defined for the following operations:  Circuit switched call control  SMS control  GPRS control

Note In the Parameters tables, in the following sections:  M - refers mandatory parameter  O - refers optional parameter

3.1 Circuit Switched Call Control This section describes operation procedures for circuit switched call control.

3.1.1 ApplyCharging The gsmSCF uses this operation for interacting with the gsmSSF function CSE control of call duration. The ApplyChargingReport operation provides the feedback from the gsmSSF to the gsmSCF.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_apply_charging_arg.h None Control

Refer the following table for the parameter details. ApplyChargingArg Parameter Sequence Associated Header File AChBillingChargingCharacteristics M cap_v4_a_ch_billing_charging_characteristics.h SendingSideID M cap_v4_sending_side_id.h ExtensionField O cap_v4_extension_field.h AChChargingAddress M cap_v4_a_ch_charging_address.h

40 33 CAMEL Messages

3.1.2 ApplyChargingReport The gsmSSF uses this operation to report charging related information to the gsmSCF as requested by the gsmSCF using the ApplyCharging operation. If Answer is detected by the gsmSSF, then timing of duration is started as requested by the ApplyCharging operation. It is started independently for a connection to a Called Party, a Temporary Connection, and a gsmSRF connection. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_apply_charging_report_arg.h None Control

Refer the following table for the parameter details. ApplyChargingReportArg Parameter Sequence Associated Header File CAMEL-CallResult M cap_v4_camel_call_result.h

41 33 CAMEL Messages

3.1.3 AssistRequestI nstructions This operation can be used by an assist gsmSSF or by a gsmSRF. The operation is sent to the gsmSCF when the assisting gsmSSF or gsmSRF receives an indication from an initiating gsmSSF indicating an assist procedure. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_assist_request_instructions_arg.h None Control

Refer the following table for the parameter details. AssistRequestInstructionsArg Parameter Sequence Associated Header File CorrelationID M cap_v4_correlation_id.h IPSSPCapabilities M cap_v4_ipssp_capabilities.h ExtensionField O cap_v4_extension_field.h

42 33 CAMEL Messages

3.1.4 CallGap The gsmSCF uses this operation to request the gsmSSF to reduce the rate at which specific service requests are sent to the gsmSCF. This operation can be sent only within a dialogue that has been opened by the gsmSSF by an InitialDP operation.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_call_gap_arg.h None Control

Refer the following table for the parameter details. CallGapArg Parameter Sequence Associated Header File GapCriteria M cap_v4_gap_criteria.h GapIndicators M cap_v4_gap_indicators.h ControlType O cap_v4_control_type.h GapTreatment O cap_v4_gap_treatment.h ExtensionField O cap_v4_extension_field.h

43 33 CAMEL Messages

3.1.5 CallI nformationReport The gsmSSF uses this operation to send specific call information for a single call party to the gsmSCF as requested by the gsmSCF in previous CallInformationRequest operation. The report is sent at the end of a call party connection.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_call_information_report_arg.h None Control

Refer the following table for the parameter details. CallInformationReportArg Parameter Sequence Associated Header File RequestedInformationList M cap_v4_requested_information_list.h ExtensionField O cap_v4_extension_field.h LegID O cap_v4_leg_id.h

44 33 CAMEL Messages

3.1.6 CallI nformationRequest The gsmSCF uses this operation to request the gsmSSF to record specific information about a single call party and report it to the gsmSCF using the CallInformationReport operation. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_call_information_request_arg.h None Control

Refer the following table for the parameter details. CallInformationRequestArg Parameter Sequence Associated Header File RequestedInformationTypeList M cap_v4_requested_information_type_list.h ExtensionField O cap_v4_extension_field.h LegID O cap_v4_leg_id.h

45 33 CAMEL Messages

3.1.7 Cancel The gsmSCF uses this operation to request the gsmSRF or gsmSSF to cancel a correlated previous operation.

The Cancel operation can be used for the following purposes:  Cancel can be sent to the gsmSRF to cancel the PlayAnnouncement or the PromptAndCollectUserInformation operation. The cancellation of the operation is indicated via a respective error indication, Canceled to the invoking entity of the cancelled PlayAnnouncement or PromptAndCollectUserInformation operation.  Cancel can be sent to the gsmSSF to disarm all armed EDPs and cancel all pending reports. This enables the gsmSSF FSM to transit to the state Idle. If Cancel is used for this purpose, then the Cancel operation does not specify any specific operation to be cancelled. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_cancel_arg.h None Control

Refer the following table for the parameter details. CancelArg Parameter Sequence Associated Header File InvokeID M cap_v4_invoke_id.h CallSegmentToCancel M cap_v4_call_segment_to_cancel.h

46 33 CAMEL Messages

3.1.8 Connect The gsmSCF uses this operation to request the gsmSSF to perform the call processing actions to route a call to a specific destination. In general all parameters, which are provided in a Connect operation to the gsmSSF, replaces the corresponding signaling parameter in the CCF in O-BCSM, in accordance with ETSI ES 201 296 [21] and is used for subsequent call processing. The CCF of the T-BCSM sends corresponding signaling parameters to new call leg without using them in subsequent call processing. Parameters, which are not provided by the Connect operation, retain their value (if already assigned) in the CCF for subsequent call processing.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_connect_arg.h None Control

Refer the following table for the parameter details. ConnectArg Parameter Sequence Associated Header File DestinationRoutingAddress M cap_v4_destination_routing_address.h AlertingPattern O cap_v4_alerting_pattern.h OriginalCalledPartyID O cap_v4_original_called_party_id.h ExtensionField O cap_v4_extension_field.h Carrier O cap_v4_carrier.h CallingPartysCategory O cap_v4_calling_partys_category.h RedirectingPartyID O cap_v4_redirecting_party_id.h RedirectionInformation O cap_v4_redirection_information.h GenericNumbers O cap_v4_generic_numbers.h ChargeNumber O cap_v4_charge_number.h LigID O cap_v4_leg_id.h Cug-Interlock O cap_v4_cug_interlock.h Cug-OutgoingAccess O NULL SuppressionOfAnnouncement O cap_v4_suppression_of_announcement.h OCSIApplicable O cap_v4_ocsi_applicable.h NaOliInfo O cap_v4_na_oli_info.h Bor-InterrogationRequested O NULL

47 33 CAMEL Messages

3.1.9 ConnectToResource The gsmSCF uses this operation to connect a call segment from the gsmSSF to a specialized resource. After successful connection to the gsmSRF, the interaction with the parties in the call segment can take place. The gsmSSF relays all operations for the gsmSRF and all responses from the gsmSRF.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_connect_to_resource_arg.h None Control

Refer the following table for the parameter details. ConnectToResourceArg Parameter Sequence Associated Header File IpRoutingAddress M cap_v4_ip_routing_address.h ExtensionField O cap_v4_extension_field.h ServiceInteractionIndicatorsTwo O cap_v4_service_interaction_indicators_two.h CallSegmentID O cap_v4_call_segment_id.h

48 33 CAMEL Messages

3.1.10 ContinueWithArgument The gsmSCF uses this operation to request the gsmSSF to proceed with call processing at the DP at which it previously suspended call processing to await gsmSCF instructions. It is also used to provide additional service related information to a user (Called Party or Calling Party) whilst the call processing proceeds.

In general all parameters, which are provided in a ContinueWithArgument operation to the gsmSSF, replaces the corresponding signaling parameter in the CCF, in accordance with ETSI ES 201 296 [21]; is used for subsequent call processing. Parameters, which are not provided by the ContinueWithArgument operation, retain their value (if already assigned) in the CCF for subsequent call processing.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_continue_with_argument_arg.h None Control

Refer the following table for the parameter details. ContinueWithArgumentArg Parameter Sequence Associated Header File LegID O cap_v4_leg_id.h AlertingPattern O cap_v4_alerting_pattern.h ExtensionField O cap_v4_extension_field.h ServiceInteractionIndicatorsTwo O cap_v4_service_interaction_indicators_two.h CallingPartysCategory O cap_v4_calling_partys_category.h GenericNumbers O cap_v4_generic_numbers.h Cug-Interlock O cap_v4_cug_interlock.h Cug-OutgoingAccess O NULL ChargeNumber O cap_v4_charge_number.h Carrier O cap_v4_carrier.h SuppressionOfAnnouncement O cap_v4_suppression_of_announcement.h NaOliInfo O cap_v4_na_oli_info.h Bor-InterrogationRequested O NULL Suppress-O-CSI O NULL ContinueWithArgumentArgExtension O Cap_v4_continue_with_argument_arg_extension.h

49 33 CAMEL Messages

3.1.11 DisconnectForwardConnectionWithArgument The gsmSCF uses this operation to disconnect a connection to a resource (gsmSRF) established previously with a ConnectToResource or an EstablishTemporaryConnection operation. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched cap_v4_disconnect_forward_connection_with_argument_arg.h None Call Control

Refer the following table for the parameter details. DisconnectForwardConnectionWithArgumentArg Parameter Sequence Associated Header File CallSegmentID O cap_v4_call_segment_id.h ExtensionField O cap_v4_extension_field.h

50 33 CAMEL Messages

3.1.12 DisconnectLeg The gsmSCF uses this operation to request the gsmSSF to release a specific leg associated with the call. Any other leg(s) not specified in the Disconnect Leg operation are retained. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_disconnect_leg_arg.h None Control

Refer the following table for the parameter details. DisconnectLegArg Parameter Sequence Associated Header File LegID M cap_v4_leg_id.h Cause O cap_v4_cause.h ExtensionField O cap_v4_extension_field.h

51 33 CAMEL Messages

3.1.13 EntityReleased The CSA uses this operation to inform the gsmSCF about the release of a logical entity (Call Segment or BCSM) caused by exception or errors. The CSA uses this operation if this information cannot be conveyed in a TC_ABORT or TC_END TC message because the TC dialogue has to be maintained for other logical entities (Call Segment or BCSM) in this CSA, which are not affected, by this error or exception. The CSA not uses this operation if the last Call Segment in the CSA was released. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_entity_released_arg.h None Control

Refer the following table for the parameter details. EntityReleasedArg Parameter Sequence Associated Header File CallSegmentFailure M cap_v4_call_segment_failure.h BCSM-Failure M cap_v4_bcsm_failure.h

52 33 CAMEL Messages

3.1.14 EstablishTemporaryConnection The gsmSCF uses this operation to create a connection between an initiating gsmSSF and an assisting gsmSSF as part of a service assist procedure. It can also be used to create a connection between a gsmSSF and a gsmSRF, for the case where the gsmSRF exists in a separately addressable PE.

The assistingSSPIPRoutingAddress contains routing digits, a correlationID and an scfID when a temporary connection is established between PLMNs and no bilateral agreement exists between the involved network operators to transfer correlationID and SCFiD as separate parameters.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_establish_temporary_connection_arg.h None Control

Refer the following table for the parameter details. EstablishTemporaryConnectionArg Parameter Sequence Associated Header File AssistingSSPIPRoutingAddress M cap_v4_assisting_sspip_routing_address.h CorrelationID O cap_v4_correlation_id.h ScfID O cap_v4_scf_id.h ExtensionField O cap_v4_extension_field.h Carrier O cap_v4_carrier.h ServiceInteractionIndicatorsTwo O cap_v4_service_interaction_indicators_two.h CallSegmentID O cap_v4_call_segment_id.h NaOliInfo O cap_v4_na_oli_info.h ChargeNumber O cap_v4_charge_number.h

53 33 CAMEL Messages

3.1.15 EventNotificationCharging The gsmSSF uses this operation to report to the gsmSCF the occurrence of a specific charging event type as requested by the gsmSCF using the RequestNotificationChargingEvent operation. As several charging events may occur during a connection configuration, the possibility exists for the EventNotificationCharging operation to be invoked on multiple occasions. For each connection configuration, the EventNotificationCharging operation can be used several times. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_event_notification_charging_arg.h None Control

Refer the following table for the parameter details. EventNotificationChargingArg Parameter Sequence Associated Header File EventSpecificChargingInformation M cap_v4_event_specific_charging_information.h LegID O cap_v4_leg_id.h ExtensionField O cap_v4_extension_field.h

54 33 CAMEL Messages

3.1.16 EventReportBCSM The gsmSSF uses this operation to notify the gsmSCF of a call related event previously requested by the gsmSCF in a RequestReportBCSMEvent operation. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_event_report_bcsm_arg.h None Control

Refer the following table for the parameter details. EventReportBCSMArg Parameter Sequence Associated Header File EventTypeBCSM M cap_v4_event_type_bcsm.h EventSpecificInformationBCSM O cap_v4_event_specific_information_bcsm.h LegID O cap_v4_leg_id.h MiscCallInfo M cap_v4_misc_call_info.h ExtensionField O cap_v4_extension_field.h

55 33 CAMEL Messages

3.1.17 FurnishChargingI nformation The gsmSCF uses this operation to send charging related information to a logical call record. This logical call record is CAMEL specific. The first FurnishChargingInformation operation of a call leg leads to the generation of a logical call record. The handling of subsequent FurnishChargingInformation operations for a call leg depends on the presence and value of the append free format data parameter in the FurnishChargingInformation operation. If a FurnishChargingInformation operation is received for the called party when the gsmSSF FSM is in the state Monitoring, or is suspended in one of the following DPs, then the charging information is included in the logical call record for the leg that has been or is to be established:  Collected_Info  Analysed_Information  O_Answer  Terminating_Attempt_Authorised  T_Answer If a FurnishChargingInformation operation is received for the called party when the gsmSSF is suspended in any other DP, then the charging information is included in the logical call record created for the last failed or disconnected called party.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_furnish_charging_information_arg.h None Control

Refer the following table for the parameter details. FurnishChargingInformationArg Parameter Sequence Associated Header File FCIBillingChargingCharacteristics M cap_v4_fci_billing_charging_characteristics.h

56 33 CAMEL Messages

3.1.18 I nitialDP The gsmSSF uses this operation after detection of a TDP-R in the BCSM, to request the gsmSCF for instructions to complete the call. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_initial_dp_arg.h None Control

Refer the following table for the parameter details. InitialDPArg Parameter Sequence Associated Header File ServiceKey M cap_v4_service_key.h CalledPartyNumber O cap_v4_called_party_number.h CallingPartyNumber O cap_v4_calling_party_number.h CallingPartysCategory O cap_v4_calling_partys_category.h CGEncountered O cap_v4_cg_encountered.h IPSSPCapabilities O cap_v4_ipssp_capabilities.h LocationNumber O cap_v4_location_number.h OriginalCalledPartyID O cap_v4_original_called_party_id.h ExtensionField O cap_v4_extension_field.h HighLayerCompatibility O cap_v4_high_layer_compatibility.h AdditionalCallingPartyNumber O cap_v4_additional_calling_party_number.h BearerCapability O cap_v4_bearer_capability.h EventTypeBCSM O cap_v4_event_type_bcsm.h RedirectingPartyID O cap_v4_redirecting_party_id.h RedirectionInformation O cap_v4_redirection_information.h Cause O cap_v4_cause.h ServiceInteractionIndicatorsTwo O cap_v4_service_interaction_indicators_two.h Carrier O cap_v4_carrier.h cug-Index O cap_v4_cug_index.h Cug-Interlock O cap_v4_cug_interlock.h Cug-OutgoingAccess O NULL IMSI O cap_v4_imsi.h SubscriberState O cap_v4_subscriber_state.h LocationInformation O cap_v4_location_information.h Ext-basicServiceCode O cap_v4_ext_basic_service_code.h CallReferenceNumber O cap_v4_call_reference_number.h ISDN-Address String O cap_v4_isdn_address_string.h CallForwardingSS-Pending O NULL

57 33 CAMEL Messages

CalledPartyBCDNumber O cap_v4_called_party_bcd_number.h TimeAndTimezone O cap_v4_time_and_timezone.h InitialDPArgExtension O cap_v4_initial_dp_arg_extension.h

58 33 CAMEL Messages

3.1.19 I nitiateCallAttempt The gsmSCF uses this operation to request the gsmSSF to create a new call leg to one call party using the address information provided by the gsmSCF (that is wake-up call). The gsmSCF subsequently arms O_Answer as an EDP-R and the call failure events (Route_Select_Failure, O_Busy, and O_No_Answer) as EDP-Rs and/or EDP-Ns, in order to enable the gsmSCF to treat this call appropriately when any of these events is encountered. InitiateCallAttempt can also be used to create an additional call party in a new Call Segment within an existing Call Segment Association.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_initiate_call_attempt_arg.h None Control cap_v4_initiate_call_attempt_res.h

Refer the following table for the parameter details. InitiateCallAttemptArg Parameter Sequence Associated Header File DestinationRoutingAddress M cap_v4_destination_routing_address.h ExtensionField O cap_v4_extension_field.h LegID O cap_v4_leg_id.h CallSegmentID O cap_v4_call_segment_id.h CallingPartyNumber O cap_v4_calling_party_number.h CallReferenceNumber O cap_v4_call_reference_number.h ISDN-AddressString O cap_v4_isdn_address_string.h Suppress-T-CSI O NULL InitiateCallAttemptRes SupportedCamelPhases O cap_v4_supported_camel_phases.h SupportedCamel4Subsets O cap_v4_supported_camel4_subsets.h ExtensionField O cap_v4_extension_field.h

59 33 CAMEL Messages

3.1.20 MoveLeg The gsmSCF uses this operation to request the gsmSSF to move the leg from its current Call Segment to the intial Call Segment (CS ID = 1). Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_move_leg_arg.h None Control

Refer the following table for the parameter details. MoveLegArg Parameter Sequence Associated Header File LegID M cap_v4_leg_id.h ExtensionField O cap_v4_extension_field.h

60 33 CAMEL Messages

3.1.21 PlayAnnouncement The gsmSCF uses this operation for in band interaction with a CS user.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_play_announcement_arg.h None Control

Refer the following table for the parameter details. PlayAnnouncementArg Parameter Sequence Associated Header File InformationToSend M cap_v4_information_to_send.h ExtensionField O cap_v4_extension_field.h CallSegmentID O cap_v4_call_segment_id.h

61 33 CAMEL Messages

3.1.22 PlayTone The gsmSCF uses this operation to instruct the gsmSSF to play tones to a leg or a Call Segment using the MSC’s tone generator. If a Call Segment is indicated, then the tones are played to all active legs in that Call Segment. If a leg is indicated, then the tones are played to that leg only.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_play_tone_arg.h None Control

Refer the following table for the parameter details. PlayToneArg Parameter Sequence Associated Header File LegOrCallSegment M cap_v4_leg_or_call_segment.h Bursts M cap_v4_burst.h ExtensionField O cap_v4_extension_field.h

62 33 CAMEL Messages

3.1.23 PromptAndCollectUserI nformation The gsmSCF uses this operation to interact with a call party in order to collect information.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched cap_v4_prompt_and_collect_user_information_arg.h None Call Control

Refer the following table for the parameter details. PromptAndCollectUserInformationArg Parameter Sequence Associated Header File CollectedInfo M cap_v4_collected_info.h InformationToSend O cap_v4_information_to_send.h ExtensionField O cap_v4_extension_field.h CallSegmentID O cap_v4_call_segment_id.h

63 33 CAMEL Messages

3.1.24 ReceivedI nformation Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_received_information_arg.h None Control

Refer the following table for the parameter details. ReceivedInformationArg Parameter Sequence Associated Header File Digits M cap_v4_digits.h

64 33 CAMEL Messages

3.1.25 ReleaseCall The gsmSCF uses this operation to tear down a call at any phase. This operation may not be sent to an assisting gsmSSF. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_release_call_arg.h None Control

Refer the following table for the parameter details. ReleaseCallArg Parameter Sequence Associated Header File Cause M cap_v4_cause.h

65 33 CAMEL Messages

3.1.26 RequestNotificationChargingEvent The gsmSCF uses this operation to instruct the gsmSSF how to manage the charging events, which are received from other Functional Entities (FEs) not under the control of the ServiceLogic (SL) instance. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched cap_v4_request_notification_charging_event_arg.h None Call Control

Refer the following table for the parameter details. RequestNotificationChargingEventArg Parameter Sequence Associated Header File EventTypeChargingPLMN M cap_v4_event_type_charging_plmn.h MonitorMode M cap_v4_monitor_mode.h LegID O cap_v4_leg_id.h ExtensionField O cap_v4_extension_field.h

66 33 CAMEL Messages

3.1.27 RequestReportBCSMEvent The gsmSCF uses this operation to request the gsmSSF to monitor for a call-related event (example, BCSM events such as O_Busy or O_No_Answer) and to send a notification to the gsmSCF when the event is detected. The monitoring of more than one event may be requested with a single RequestReportBCSMEvent operation, but each of these requested events are reported in a separate EventReportBCSM operation.

Note If the RequestReportBCSMEvent requests arming of the current DP from which the call processing was suspended, then the next occurrence of the DP encountered during BCSM processing is detected (that is not the current one from which the call was suspended).

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_request_report_bcsm_event_arg.h None Control

Refer the following table for the parameter details. RequestReportBCSMEventArg Parameter Sequence Associated Header File BcsmEvents M cap_v4_bcsm_event.h ExtensionField O cap_v4_extension_field.h

67 33 CAMEL Messages

3.1.28 ResetTimer

The gsmSCF uses this operation to refresh the Tssf application timer, in order to avoid the Tssf time-out at the gsmSSF. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_reset_timer_arg.h None Control

Refer the following table for the parameter details. ResetTimerArg Parameter Sequence Associated Header File TimerID M cap_v4_timer_id.h Timervalue M cap_v4_timer_value.h ExtensionField O cap_v4_extension_field.h CallSegmentID O cap_v4_call_segment_id.h

68 33 CAMEL Messages

3.1.29 SendChargingI nformation The gsmSCF uses this operation to instruct the gsmSSF on the Advice of Charge information to be sent by the gsmSSF. The SendChargingInformation operation can be invoked on multiple occasions. The SendChargingInformation operation may be used for MO and MT calls in the VMSC. In the case of an MT call, the CSE provided Mobile Station does not use e-parameters if a call forwarding or follow-on call occurs.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_send_charging_information_arg.h None Control

Refer the following table for the parameter details. SendChargingInformationArg Parameter Sequence Associated Header File SCIBillingChargingCharacteristics M cap_v4_sci_billing_charging_characteristics.h SendingSideID M cap_v4_sending_side_id.h ExtensionField O cap_v4_extension_field.h

69 33 CAMEL Messages

3.1.30 SpecializedResourceReport The gsmSRF uses this operation as a response to a PlayAnnouncement operation or a PromptAndCollectUserInformation operation. This operation is used only when the requestAnnouncementCompleteNotification parameter is TRUE or the requestAnnouncementStartedNotification parameter is TRUE in the PlayAnnouncement operation or the PromptAndCollectUserInformation.

Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_specialized_resource_report_arg.h None Control

Refer the following table for the parameter details. SpecializedResourceReportArg Parameter Sequence Associated Header File AllAnnouncementsComplete M NULL FirstAnnouncementStarted M NULL

70 33 CAMEL Messages

3.1.31 SplitLeg The gsmSCF uses this operation to request the gsmSSF to separate one party from the source Call Segment and place it in a new target Call Segment. Refer the following table for the message details. Classification Associated Header File Errors Circuit Switched Call cap_v4_split_leg_arg.h None Control

Refer the following table for the parameter details. SplitLegArg Parameter Sequence Associated Header File LegID M cap_v4_leg_id.h CallSegmentID O cap_v4_call_segment_id.h ExtensionField O cap_v4_extension_field.h

71 33 CAMEL Messages

3.2 SMS Control This section describes operation procedures for SMS control.

3.2.1 ConnectSMS The gsmSCF uses this operation to request the smsSSF to continue Short Message processing such as routing a short message to a specific destination or delivering a short message to the served subscriber with modified information.

Refer the following table for the message details. Classification Associated Header File Errors SMS Control cap_v4_connect_sms_arg.h MissingParameter ParameterOutOfRange SystemFailure TaskRefused UnexpectedComponentSequence UnexpectedDataValue UnexpectedParameter

Refer the following table for the parameter details. ConnectSMSArg Parameter Sequence Associated Header File ISDN-AddressString O cap_v4_isdn_address_string.h CalledPartyBCDNumber O cap_v4_called_party_bcd_number.h ExtensionField O cap_v4_extension_field.h

72 33 CAMEL Messages

3.2.2 EventReportSMS The smsSSF uses this operation to notify the gsmSCF of a short message related event previously requested by the gsmSCF in a RequestReporSMSEvent operation. Refer the following table for the message details. Classification Associated Header File Errors SMS Control cap_v4_event_report_sms_arg.h None

Refer the following table for the parameter details. EventReportSMSArg Parameter Sequence Associated Header File EventTypeSMS M cap_v4_event_type_sms.h EventSpecificInformationSMS O cap_v4_event_specific_information_sms.h MiscCallInfo M cap_v4_misc_call_info.h ExtensionField O cap_v4_extension_field.h

73 33 CAMEL Messages

3.2.3 FurnishChargingI nformationSMS The gsmSCF uses this operation to send charging related information to a Logical SMS record. This Logical SMS record is CAMEL specific. The first FurnishChargingInformationSMS operation leads to the generation of a Logical SMS record. Receipt of subsequent FurnishChargingInformationSMS operations overwrites or appends the contents of the Logical SMS record.

Refer the following table for the message details. Classification Associated Header File Errors SMS Control cap_v4_furnish_charging_information_sms_arg.h None

Refer the following table for the parameter details. FurnishChargingInformationSMSArg Parameter Sequence Associated Header File FCISMSBillingChargingCharacteristics M cap_v4_fcisms_billing_charging_characteristics.h

74 33 CAMEL Messages

3.2.4 I nitialDPSMS The smsSSF uses this operation after detection of a TDP-R in the smsSF FSM, to request the gsmSCF for instructions to complete the Short Message submission to the SMSC or the Short Message delivery to the served subscriber.

Refer the following table for the message details. Classification Associated Header File Errors SMS Control cap_v4_initial_dpsms_arg.h None

Refer the following table for the parameter details. InitialDPSMSArg Parameter Sequence Associated Header File ServiceKey M cap_v4_service_key.h CalledPartyBCDNumber O cap_v4_called_party_bcd_number.h CallingPartyNumber O cap_v4_calling_party_number.h EventTypeSMS O cap_v4_event_type_sms.h IMSI O cap_v4_imsi.h LocationInformation O cap_v4_location_information.h LocationInformationGPRS O cap_v4_location_information_gprs.h ISDN-AddressString O cap_v4_isdn_address_string.h TimeAndTimezone O cap_v4_time_and_timezone.h TPShortMessageSpecificInfo O cap_v4_tp_short_message_specific_info.h TPProtocolIdentifier O cap_v4_tp_protocol_identifier.h TPDataCodingScheme O cap_v4_tp_data_coding_scheme.h TPValidityPeriod O cap_v4_tp_validity_period.h ExtensionField O cap_v4_extension_field.h CallReferenceNumber O cap_v4_call_reference_number.h ISDN-AddressString O cap_v4_isdn_address_string.h ms-Classmark2 O cap_v4_ms_classmark2.h GPRSMSClass O cap_v4_gprsms_class.h IMEI O cap_v4_imei.h CalledPartyNumber O cap_v4_called_party_number.h

75 33 CAMEL Messages

3.2.5 ReleaseSMS The gsmSCF uses this operation to tear down a Short Message submission attempt or Short Message delivery attempt. The operation can be sent within a control relationship only. It is not allowed in a monitor relationship. Refer the following table for the message details. Classification Associated Header File Errors SMS Control cap_v4_release_sms_arg.h None

Refer the following table for the parameter details. ReleaseSMSArg Parameter Sequence Associated Header File RPCause M cap_v4_rp_cause.h

76 33 CAMEL Messages

3.2.6 RequestReportSMSEvent The gsmSCF uses this operation to request the smsSSF to monitor for a Short Message related event (FSM events such as failure, delivery, or submission) and to send a notification to the gsmSCF when the event is detected.

The monitoring of more than one event may be requested with a single RequestReportSMSEvent operation, but each of these requested events are reported in a separate EventReportSMS operation. Refer the following table for the message details. Classification Associated Header File Errors SMS Control cap_v4_request_report_sms_event_arg.h None

Refer the following table for the parameter details. RequestReportSMSEventArg Parameter Sequence Associated Header File SMSEvents M cap_v4_sms_event.h ExtensionField O cap_v4_extension_field.h

77 33 CAMEL Messages

3.2.7 ResetTimerSMS

The gsmSCF uses this operation to refresh the Tssf application timer, to prevent Tssf expiry at the smsSSF. Refer the following table for the message details. Classification Associated Header File Errors SMS Control cap_v4_reset_timer_sms_arg.h None

Refer the following table for the parameter details. ResetTimerSMSArg Parameter Sequence Associated Header File TimerID cap_v4_timer_id.h Timervalue cap_v4_timer_value.h ExtensionField cap_v4_extension_field.h

78 33 CAMEL Messages

3.3 GPRS Control This section describes operation procedures for GPRS control.

3.3.1 ApplyChargingGPRS The gsmSCF uses this operation for interacting with the gprsSSF function CSE control of GPRS session or PDP Context duration and volume. The ApplyChargingGPRSReport operation provides the feedback from the gprsSSF to the gsmSCF.

If this procedure is used within a PDP Context dialogue, then the charging instruction pertains to the PDP Context only. Data volume threshold and duration threshold may be defined separately.

If this procedure is used within a GPRS Session dialogue, then the charging instruction may pertain to the GPRS Session or to a single PDP Context. Charging for a PDP Context may be on duration and/or volume. Charging for a GPRS Session may be on duration only.

Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_apply_charging_gprs_arg.h None

Refer the following table for the parameter details. ApplyChargingGPRSArg Parameter Sequence Associated Header File ChargingCharacteristics M cap_v4_charging_characteristics.h TariffSwitchInterval O cap_v4_tariff_switch_interval.h PDPID O cap_v4_pdpid.h

79 33 CAMEL Messages

3.3.2 ApplyChargingReportGPRS The gprsSSF uses this operation to report charging related information to the gsmSCF as requested by the gsmSCF using the ApplyChargingGPRS operation. Timing of duration and measuring of transferred data (if applicable) is started when an Attach, PDP Context Establishment Acknowledgement, or an Inter SGSN Routeing Area Update acceptance is detected by the gprsSSF. A report is made when a PDP Context Disconnect, a Detach or a Change in QoS is detected by the gprsSSF or when the gprsSSF detects that the transferred volume or elapsed time duration indicated in the parameter transferredVolume or elapsedTime (received in ApplyChargingGPRS operation) has been reached. ApplyChargingReportGPRS is sent only on chargeable QoS changes.

Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_apply_charging_report_gprs_arg.h None

Refer the following table for the parameter details. ApplyChargingReportGPRSArg Parameter Sequence Associated Header File ChargingResult M cap_v4_charging_result.h QualityOfService O cap_v4_quality_of_service.h PDPID O cap_v4_pdpid.h ChargingRollOver O cap_v4_charging_roll_over.h

80 33 CAMEL Messages

3.3.3 CancelGPRS The gsmSCF uses this operation to request the gprsSSF to disarm all pending EDPs and to cancel all pending reports for a GPRS Session or for a specific PDP Context. This enables the gprsSSF FSM to transit to the state Idle. This procedure cannot be used to cancel a previous operation.

Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_cancel_gprs_arg.h None

Refer the following table for the parameter details. CancelGPRSArg Parameter Sequence Associated Header File PDPID O cap_v4_pdpid.h

81 33 CAMEL Messages

3.3.4 ConnectGPRS The gsmSCF uses this operation to provide an APN to the gprsSSF, to be used for establishing a PDP Context.

Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_connect_gprs_arg.h None

Refer the following table for the parameter details. ConnectGPRSArg Parameter Sequence Associated Header File AccessPointName M cap_v4_access_point_name.h PDPID O cap_v4_pdpid.h

82 33 CAMEL Messages

3.3.5 ContinueGPRS The gsmSCF uses this operation to request the gprsSSF to proceed with GPRS Session or PDP Context processing at the DP at which it previously suspended processing to await gsmSCF instructions. The gprsSSF continues processing without substituting new data from the gsmSCF.

Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_continue_gprs_arg.h None

Refer the following table for the parameter details. ContinueGPRSArg Parameter Sequence Associated Header File PDPID O cap_v4_pdpid.h

83 33 CAMEL Messages

3.3.6 EntityReleasedGPRS The gprsSSF uses this operation to inform the gsmSCF that the GPRS Session is detached or a PDP Context is disconnected. It is used only when the associated event detection point (that is, for GPRS Session Detach: DP Detach and for PDP Context Disconnect: DP PDP Context Disconnection) is at that moment not armed for reporting.

This operation is used irrespectively of the functional entity that initiated the Detach or PDP Context Disconnect and irrespectively of the cause for the Detach or PDP Context Disconnect.

When a PDP Context is terminated, then the gprsSSF sends all pending reports of that PDP Context to the gsmSCF. When a GPRS Session is terminated, then the gprsSSF sends all outstanding reports of the GPRS Session to the gsmSCF.

Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_entity_released_gprs_arg.h None

Refer the following table for the parameter details. EntityReleasedGPRSArg Parameter Sequence Associated Header File GPRSCause M cap_v4_gprs_cause.h PDPID O cap_v4_pdpid.h

84 33 CAMEL Messages

3.3.7 EventReportGPRS The gprsSSF uses this operation to notify the gsmSCF of a GPRS Session or PDP Context event previously requested by the gsmSCF in a RequestReportGPRSEvent operation. Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_event_report_gprs_arg.h None

Refer the following table for the parameter details. EventReportGPRSArg Parameter Sequence Associated Header File GPRSEventType M cap_v4_gprs_event_type.h MiscCallInfo M cap_v4_misc_call_info.h GPRSEventSpecificInformation O cap_v4_gprs_event_specific_information.h PDPID O cap_v4_pdpid.h

85 33 CAMEL Messages

3.3.8 FurnishChargingI nformationGPRS The gsmSCF uses this operation to send charging related information to a Logical GPRS record. This Logical GPRS record is CAMEL specific. The first FurnishChargingInformationGPRS operation results in the generation of a Logical GPRS record. Receipt of subsequent FurnishChargingInformationGPRS operations overwrites or appends the contents of the Logical GPRS record.

Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_furnish_charging_information_gprs_arg.h None

Refer the following table for the parameter details. FurnishChargingInformationGPRSArg Parameter Sequence Associated Header File FCIGPRSBillingChargingCharacteristics M cap_v4_fcigprs_billing_charging_characteristics.h

86 33 CAMEL Messages

3.3.9 I nitialDPGPRS The gprsSSF uses this operation after detection of a TDP-R in the GPRS Session or PDP Context state machine, to request the gsmSCF for instructions to complete the GPRS Session or PDP Context. For a GPRS Session, the Attach and Change of Position Session TDPs may result in the InitialDPGPRS Procedure.

For a PDP Context, the PDP Context Establishment, the PDP Context Establishment Acknowledgement and the Change of Position Context TDPs may result in the InitialDPGPRS Procedure.

If a PDP Context related TDP is met and there is at that moment a GPRS dialogue for the GPRS Session, then the gprsSSF not initiates the InitialDPGPRS Procedure for that PDP Context. If the PDP Context Establishment Acknowledgement event occurs and this event is armed as a TDP, and there is at that moment a GPRS dialogue for the PDP Context, then the gprsSSF not initiates a new InitialDPGPRS Procedure for that PDP Context. Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_initial_dpgprs_arg.h None

Refer the following table for the parameter details. InitialDPGPRSArg Parameter Sequence Associated Header File ServiceKey M cap_v4_service_key.h GPRSEventType M cap_v4_gprs_event_type.h ISDN-AddressString M cap_v4_isdn_address_string.h IMSI M cap_v4_imsi.h TimeAndTimeZone M cap_v4_time_and_timezone.h GPRSMSClass O cap_v4_gprsms_class.h EndUserAddress O cap_v4_end_user_address.h QualityOfService O cap_v4_quality_of_service.h AccessPointName O cap_v4_access_point_name.h RAIdentity O cap_v4_ra_identity.h GPRSChargingID O cap_v4_gprs_charging_id.h SGSNCapabilities O cap_v4_sgsn_capabilities.h LocationInformationGPRS O cap_v4_location_information_gprs.h PDPInitiationType O cap_v4_pdp_initiation_type.h ExtensionField O cap_v4_extension_field.h GSN-Address O cap_v4_gsn_address.h SecondaryPDP-context O NULL IMEI O cap_v4_imei.h

87 33 CAMEL Messages

3.3.10 ReleaseGPRS The gsmSCF uses this operation to tear down by the gsmSCF an existing GPRS Session or PDP Context at any phase. Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_release_gprs_arg.h None

Refer the following table for the parameter details. ReleaseGPRSArg Parameter Sequence Associated Header File GprsCause M cap_v4_gprs_cause.h PDPID O cap_v4_pdpid.h

88 33 CAMEL Messages

3.3.11 RequestReportGPRSEvent The gsmSCF uses this operation to request the gprsSSF to monitor for a GPRS Session or PDP Context related event (example, events such as PDP Context establishment or detach) and to send a notification to the gsmSCF when the event is detected.

The monitoring of more than one event may be requested with a single RequestReportGPRSEvent operation, but each of these requested events are reported in a separate EventReportGPRS operation. Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_request_report_gprs_event_arg.h None

Refer the following table for the parameter details. RequestReportGPRSEventArg Parameter Sequence Associated Header File GPRSEvents M cap_v4_gprs_event.h PDPID O cap_v4_pdpid.h

89 33 CAMEL Messages

3.3.12 ResetTimerGPRS

The gsmSCF uses this operation to refresh the Tssf application timer, in order to avoid the Tssf time-out at the gprsSSF. Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_reset_timer_gprs_arg.h None

Refer the following table for the parameter details. ResetTimerGPRSArg Parameter Sequence Associated Header File TimerID M cap_v4_timer_id.h Timervalue M cap_v4_timer_value.h

90 33 CAMEL Messages

3.3.13 SendChargingI nformationGPRS The gsmSCF uses this operation to instruct the gprsSSF on the Advice of Charge information to be sent to the MS, provided that the SGSN supports Advice of Charge. The operation can be invoked on multiple occasions. Refer the following table for the message details. Classification Associated Header File Errors GPRS Control cap_v4_send_charging_information_gprs_arg.h None

Refer the following table for the parameter details. SendChargingInformationGPRSArg Parameter Sequence Associated Header File SCIGPRSBillingChargingCharacteristics M cap_v4_scigprs_billing_charging_characteristics.h

91 CChhaapptteerr 44 CAMEL User’s Guide

4 Designing an Encoder – Decoder Application

This chapter provides information about how to design an Encoder ± Decoder application and describes the following:  Encoding CAMEL operation  Decoding CAMEL operation

4.1 Encoding CAMEL Operation The following three steps need to be performed sequentially to encode any CAMEL message. The following sample illustrates how to encode the EncodeInitialDP message:

1. Instantiate the message object and populate the relevant message parameters. 2. Call ASN Encode () method for converting the full message payload into BER format.

3. Release memory allocated in the above two procedures.

EncodeInitialDP() { AsnObject* msgArg = NULL; Octets* encOctets = NULL;

msgArg = BuildInitialDP();

EncodeMsg(msgArg, &encOctets);

if (msgArg) { delete msgArg; delete encOctets; msgArg = NULL; encOctets = NULL; }

}

92 44 Designing an Encoder - Decoder Applicat ion

Detailed explanation of each step along with the relevant code snippet follows.

4.1.1 Step 1 -- Setting Parameters in the Message To set parameters in the message: 1. Create an EncodeInitialDP object. User needs to allocate memory for this object.

2. Populate the object with its parameters. The relevant methods to set the parameters can be found in the header file cap_v4_initial_dp_arg.h

AsnObject* BuildInitialDP() { InitialDPArg *idp = (InitialDPArg*)obj;

/* Set the Service Key */ int skey = 1000; ServiceKey* serviceKey = new ServiceKey(skey); idp->SetServiceKey(serviceKey);

/* Set the Called Party No*/ byte calledPartyArray[5] = { 0x11, 0x22, 0x33, 0x44, 0x55 }; CalledPartyNumber* cdp = new CalledPartyNumber(FixedByteArrayToVector(calledPartyArray)); idp->SetCalledPartyNumber(cdp);

/* Set the Calling Party No*/ byte callingPartyArray[5] = { 0x11, 0x22, 0x33, 0x44, 0x55 }; CallingPartyNumber* clp = new CallingPartyNumber(FixedByteArrayToVector(callingPartyArray)); idp->SetCallingPartyNumber(clp);

/* Set the Calling Party’s Catagory */ byte callingPartysCategory[1] = { 0x21 }; CallingPartysCategory* cat = new CallingPartysCategory(FixedByteArrayToVector(callingPartysCategory)); idp->SetCallingPartysCategory(cat);

/* Set the LocationNumber */ byte locationNumberArray[4] = { 0x91, 0x92, 0x93, 0x94 }; LocationNumber* loc = new LocationNumber(FixedByteArrayToVector(locationNumberArray)); idp->SetLocationNumber(loc);

return ((AsnObject*)idp); }

93 44 Designing an Encoder - Decoder Applicat ion

In the above application, for Array type elements, a byte array has been converted to a vector of bytes by a simple conversion macro. Vector is an STL type. The Set-methods for all parameters of the type Octet String accept vector bytes. // Utilities

// // Macro to get the size (count of items) of a fixed array // #define FixedArraySize(array) \ (sizeof(array) / sizeof(array[0]))

// // Macro to convert fixed arrays (of bytes) to vectors // #define FixedByteArrayToVector(array) \ (vector(array, array + FixedArraySize(array)))

// // Macro to convert fixed arrays (of booleans) to vectors // #define FixedBooleanArrayToVector(array) \ (vector(array, array + FixedArraySize(array)))

4.1.2 Step 2 – Converting to ASN BER Format Following are the steps for converting to ASN BER Format:

1. Create a pointer to a temporary object of type Octets. This object is used for storing the encoded bytes. The memory for this object is allocated inside the ASN Encode method. This object needs to be deleted by the user to free the memory resources. Note that the ASN runtime library does the allocation, but the deletion has to be done by the User when the Octets objects are of no further use. 2. Encode the EncodeInitialDP object to produce the ASN BER format. void EncodeMsg(AsnObject* p, Octets** octets) { // Print ASN.1 value before encoding

printf("[CAMEL Test]: %s: line %d\n", __FILE__, __LINE__);

cout << endl; cout << "------" << endl; cout << "Printing ASN.1 value before encoding..." << endl; cout << endl << *p << endl;

// Encode using ASN.1 BER. Octets* tmpOctets;

try { tmpOctets = p->Encode(); } catch (AsnEncodeError& exc) { cout << endl; cout << "------" << endl; cout << "Exception during encoding phase..." << endl; cout << exc.GetDescription() << endl; cout << "Exit test..." << endl; }

cout << endl;

94 44 Designing an Encoder - Decoder Applicat ion

cout << "------" << endl; cout << "Printing ASN.1 encoded value..." << endl; cout << endl << *tmpOctets << endl;

*octets = tmpOctets; }

4.1.3 Step 3 -- Memory Allocation/ Deallocation During Encoding The EncodeInitialDP message object was allocated on the heap and is to be deleted by the User to prevent any memory loss. It is to be noted that memory allocated for individual parameters within the message gets automatically freed up when the memory for the container message object is deleted.

4.1.4 Exception Handling while Encoding AsnEncodeError is the exception that can occur during encoding. User needs to catch this exception in the catch block after the call to the Encode () method. GetDescription () method is called on AsnEncodeError to get the file name, line number and the description of the exception. Actions deemed relevant for the application in case of encoding exception has to be called inside the Catch Block. try { tmpOctets = p->Encode(); } catch (AsnEncodeError& exc) { cout << endl; cout << "------" << endl; cout << "Exception during encoding phase..." << endl; cout << exc.GetDescription() << endl; cout << "Exit test..." << endl; }

4.1.5 Pretty Printing Raw Bytes and Encoded Message The printing of the message can be done in two ways:  Print the raw bytes of the encoded message  Pretty-print the bytes in the encoded message. The Pretty-print prints the bytes in a easily readable format Print Raw Bytes cout << endl; cout << "------" << endl; cout << "Printing ASN.1 value before encoding..." << endl; cout << endl << *p << endl;

Following is the sample output of the payload bytes encoded by the EncodeInitialDP ()

Printing ASN.1 encoded value...

[ 30 1B 80 02 03 E8 82 05 11 22 33 44 55 83 05 11 22 33 44 55 85 01 21 8A 04 91 92 93 94 ]

95 44 Designing an Encoder - Decoder Applicat ion

Print Encode Message Format

cout << endl; cout << "------" << endl; cout << "Printing ASN.1 encoded value..." << endl; cout << endl << *tmpOctets << endl;

Following is the encoded message format.

Printing ASN.1 value before encoding...

InitialDPArg (SEQUENCE) { ServiceKey (INTEGER) [ 1000 ]

CalledPartyNumber (OCTET STRING) [ 11 22 33 44 55 ]

CallingPartyNumber (OCTET STRING) [ 11 22 33 44 55 ]

CallingPartysCategory (OCTET STRING) [ 21 ]

LocationNumber (OCTET STRING) [ 91 92 93 94 ] }

96 44 Designing an Encoder - Decoder Applicat ion

4.2 Decoding CAMEL Operation The following steps need to be performed sequentially to decode any CAMEL message. The following sample illustrates how to decode the EncodeInitialDP message:

1. Instantiate the message object by allocating memory on the heap 2. Call ASN Decode () method on the BER format encoded message. This populates the parameters inside the instantiated message object.

3. Retrieve the parameters contained inside the decoded EncodeInitialDP message. 4. Perform memory cleanups.

DecodeInitialDP (Octets* encOctets) { AsnObject* msgArg = NULL;

msgArg = new InitialDPArg();

DecodeMsg (msgArg, encOctets); GetParameters (msgArg);

if (msgArg) { delete msgArg; msgArg = NULL; } }

Detailed explanation of each step along with the code snippet follows. The following function is a generic Decode function, which accepts the instantiated message class, and the encoded octets. Individual ASN message classes inherit from the base class AsnObject. Hence the Decode function can be generic.

void DecodeMsg(AsnObject* p, Octets* octets) { // Decoding using ASN.1 BER

try { if (p) { p->Decode(*octets); } } catch (AsnDecodeError& exc) {

printf("[CAMEL Test]: %s: line %d\n", __FILE__, __LINE__);

cout << endl; cout << "------" << endl; cout << "Exception during decoding phase..." << endl; cout << exc.GetDescription() << endl; cout << "Exit test..." << endl; }

// Print ASN.1 value after decoding

97 44 Designing an Encoder - Decoder Applicat ion

printf("[CAMEL Test]: %s: line %d\n", __FILE__, __LINE__);

cout << endl; cout << "------" << endl; cout << "Printing ASN.1 value after decoding..." << endl;

if (p) { cout << endl << *p << endl << endl; }

return p; }

4.2.1 Parameter Retrieval from Decoded Message After decoding, the instantiated message object contains all the parameters set during encoding. This is to be passed as an argument to the following snippet to retrieve the individual parameters by calling the corresponding Get () methods. void GetParameters (AsnObject* msgArg) { InitialDPArg* initialDpArg = (InitialDPArg*)msgArg;

cout <

/* Get Called Party No*/ ServiceKey serviceKey; serviceKey = initialDpArg->GetServiceKey(); cout <

/* Get Called Party No */ if (initialDpArg->OptionCalledPartyNumber()) { CalledPartyNumber calledPartyNumber; calledPartyNumber = initialDpArg->GetCalledPartyNumber(); cout <

/* Get Calling Party Number */ if (initialDpArg->OptionCallingPartyNumber()) { CallingPartyNumber callingPartyNumber; callingPartyNumber = initialDpArg->GetCallingPartyNumber(); cout <

/* Get CallingPartysCategory */ if (initialDpArg->OptionCallingPartysCategory()) { CallingPartysCategory callingPartysCategory; callingPartysCategory = initialDpArg->GetCallingPartysCategory(); cout <

/* Get LocationNumber*/ if (initialDpArg->OptionLocationNumber()) { LocationNumber locationNumber;

98 44 Designing an Encoder - Decoder Applicat ion

locationNumber = initialDpArg->GetLocationNumber(); cout <

Following is the output for each parameter retrieved.

Printing ASN.1 value after decoding...

Retrieving Parameters from InitialDpArg Message.

Retrieving ServiceKey:: Parameter : OPTIONAL ServiceKey (INTEGER) [ 1000 ]

Retrieving CalledPartyNumber :: Parameter : OPTIONAL CalledPartyNumber (OCTET STRING) [ 11 22 33 44 55 ]

Retrieving Paramter CallingPartyNumber :: Parameter : OPTIONAL CallingPartyNumber (OCTET STRING) [ 11 22 33 44 55 ]

Retrieving Paramter CallingPartysCategory :: Parameter : OPTIONAL CallingPartysCategory (OCTET STRING) [ 21 ]

Retrieving Paramter LocationNumber :: Parameter : OPTIONAL LocationNumber (OCTET STRING) [ 91 92 93 94 ] }

4.2.2 Memory Allocation/ Deallocation During Decoding The instantiated message object needs to be deleted after retrieving relevant parameters by using Get methods on the object.

99 44 Designing an Encoder - Decoder Applicat ion

4.2.3 Exception Handling while Decoding AsnDecodeError is the exception that can occur during Decoding. User needs to catch this exception in the catch block after the call to the Decode () method. GetDescription () method is called on AsnDcodeError to get the file name, line number and the description of the exception. try { if (p) { p->Decode(*octets); } } catch (AsnDecodeError& exc) { printf("[CAMEL Test]: %s: line %d\n", __FILE__, __LINE__);

cout << endl; cout << "------" << endl; cout << "Exception during decoding phase..." << endl; cout << exc.GetDescription() << endl; cout << "Exit test..." << endl; }

4.2.4 Pretty Printing the Decoded Message The printing of the message can be done in two ways:  Print the raw bytes of the decoded message  Pretty-print the bytes in the decoded message. The Pretty-print prints the bytes in a easily readable format

Print Decode Message Format

cout << endl; cout << "------" << endl; cout << "Printing ASN.1 value after decoding..." << endl;

if (p) { cout << endl << *p << endl << endl; }

Following is the decoded message format.

InitialDPArg (SEQUENCE) { ServiceKey (INTEGER) [ 1000 ]

CalledPartyNumber (OCTET STRING) [ 11 22 33 44 55 ]

CallingPartyNumber (OCTET STRING) [ 11 22 33 44 55 ]

CallingPartysCategory (OCTET STRING) [ 21 ]

LocationNumber (OCTET STRING) [ 91 92 93 94 ] }

100 CChhaapptteerr 55 CAMEL User’s Guide

5 Integrating Encoder – Decoder with SKTAL and SKIM

This chapter describes sample applications using SKIM API interface and SKTAL API interface.

5.1 SKIM Sample Application This section describes a sample application using SKIM API interface. The following steps are involved:

1. Create a connection with LLC using Switch Kit APIs 2. Create an instance of SKIM API Class

3. Send a TCAP transaction

4. Receive a TCAP transaction 5. Receive notifications

6. Terminate SKIM API object and disconnect

5.1.1 Creating a Connection with LLC Using Switch Kit API s connect() { int ret;

/* Create the connection */ ret = skts_createConnection(CONN_ID, CONN_LABEL, CONN_NAME, SKIM_FALSE, PRI_IP, PRI_PORT, BACK_IP, BACK_PORT); if (ret == 0) { fprintf(stderr, "Error connecting to switch\n"); return (SKIM_EINVALIDARGS); }

return (SKIM_SUCCESS); }

5.1.2 Creating an I nstance of SKI M API Class SKIM_Api api_classptr;

// LOCAL_NODE - value created during configuration // STACK_ID - Stack Id for the stack instance created during configuration // CONN_ID - Same as created in step one // LOCAL_PC - Local Point Code for stack instance // LOCAL_SSN - local subsystem number for stack instance // APP_TransHandler - Default Handler for handling incoming // TCAP Transaction messages // APP_NotifyHandler - Default Handler for handling incoming // SKIM notifications // tag - Tag to be returned with handler functions. res = api_classptr.Initialize(LOCAL_NODE, STACK_ID, CONN_ID, LOCAL_PC, LOCAL_SSN, APP_TransHandler, APP_NotifyHandler, NULL); if (res != SKIM_SUCCESS) {

101 55 I nt egrat ing Encoder- Decoder wit h SKTAL and SKI M

printf("\n Initialization FAILED !!!!!!!!!"); api_classptr.Terminate(); exit(0); } else { printf("\n SUCCESS FROM INITIALIZATION API !!\n"); }

5.1.3 Sending a TCAP Transaction // Create SKIM_Trans object of type SKIM_TC_BEGIN SKIM_Trans trans (SKIM_TC_BEGIN);

// Create objects for calling party and called party address. SKIM_CallingPartyAddr origAddr; SKIM_CalledPartyAddr destAddr;

// Populate OPC and DPC trans.SetOPC(LOCAL_PC); trans.SetOPC(REMOTE_PC);

// Populate calling party address origAddr.SetSSN(LOCAL_SSN); origAddr.SetPointCode(LOCAL_PC); origAddr.SetRouteByPCSSN(true);

#if defined(CCITT) origAddr.SetInternationalRouting(true); #elif defined (ANSI) origAddr.SetInternationalRouting(false); #endif

// Set calling party address for beginning transaction. trans.SetSourceAddress(origAddr);

//Set Called Party Address destAddr.SetSSN(REMOTE_SSN); destAddr.SetPointCode(REMOTE_PC); destAddr.SetRouteByPCSSN(true); #if defined(CCITT) destAddr.SetInternationalRouting(true); #elif defined (ANSI) destAddr.SetInternationalRouting(false); #endif // Set called party address for begin transaction. trans.SetDestAddress(destAddr);

// Set quality of service for the transaction message SKIM_OCTET slsKey, priority; slsKey = 0; priority = 0; trans.SetQualityOfService(QOSI_RET_OPT|SKIM_QOSI_RET_OPT, slsKey, priority);

// Adding a operation to transaction object.

// Create operation of type SKIM_TC_INVOKE SKIM_Operation op(SKIM_TC_INVOKE);

// Set Invoke Id. op.SetInvokeId(1 + i);

// Set Operation Code #if defined(CCITT) op.SetOpCode(100);

// Set Operation Class for Invoke operation. op.SetClass(1); // Set Invoke operation timeout

102 55 I nt egrat ing Encoder- Decoder wit h SKTAL and SKI M

op.SetInvokeTimeout(10); #else defined(ANSI) op.SetOpCode(true, 1, 1); #endif

// Set ASN.1 encoded TCAP User parameters op.SetParameter(SKIM_Encode());

// Add operation to the transaction object. trans.AddOperation(op);

// Send transaction to EXS ret = api_classptr.Send(trans); if (ret != SKIM_SUCCESS) { printf("Send transaction failed ret = %d", ret); return ret; }

// Get the call reference id allocated for this transaction. SKIM_UINT callrefid = trans.GetCallReferenceId();

5.1.4 Receiving a TCAP Transaction Transactions are received via transaction handler and registered during initialization. Sample implementation for transaction handler is shown in the following code snippet. int APP_TransHandler( SKIM_Trans &trans, void *tag) { SKIM_OCTET type;

printf("APP_TransHandler Called\n");

SKIM_UINT id = trans.GetCallReferenceId();

trans.GetTransType(type); switch(type) { case SKIM_TC_UNI: rcvd_callrefid = id; printf ("Received TCAP UNI call reference id is %x\n", id); AppReceiveOperation(trans);

break;

case SKIM_TC_BEGIN : rcvd_callrefid = id; printf ("Received TCAP Begin call reference id is %x\n", id); AppReceiveOperation(trans);

break;

case SKIM_TC_CONTINUE : rcvd_callrefid = id; printf ("Received TCAP Continue call reference id is %x\n", id); AppReceiveOperation (trans);

break;

case SKIM_TC_END : rcvd_callrefid = id; printf ("Received TCAP End call reference id is %x\n", id); AppReceiveOperation (trans);

break;

#if defined(ANSI) case SKIM_TC_ABORT :

103 55 I nt egrat ing Encoder- Decoder wit h SKTAL and SKI M

rcvd_callrefid = id; printf ("Received TCAP Abort call reference id is %x\n", id);

break; #endif #if defined(CCITT) case SKIM_TC_U_ABORT : rcvd_callrefid = id; printf ("Received TCAP Abort call reference id is %x\n", id);

break;

case SKIM_TC_P_ABORT : rcvd_callrefid = id; printf ("Received TCAP Abort call reference id is %x\n", id);

break;

case SKIM_TC_P_ABORT : rcvd_callrefid = id; printf ("Received TCAP Abort call reference id is %x\n", id);

break; #endif

default : printf("Unknown transaction received\n"); break; };

return SKIM_SUCCESS; }

AppReceiveOperation(SKIM_Trans &trans) { SKIM_Operation op;

while (trans.RemoveOperation(op) == SKIM_SUCCESS) { if (op.GetType() == SKIM_TC_INVOKE) { rcvd_invoke_id = op.GetInvokeId(); printf("Received Invoke with Invoke id = %d\n", op.GetInvokeId()); vector paramData; op.GetParameter(paramData);

SKIM_Decode(paramData); } else if (op.GetType() == SKIM_TC_RESULT_L) { printf("Received Return Result Last with Invoke id = %d\n", op.GetInvokeId()); vector paramData; op.GetParameter(paramData);

SKIM_DecodeResponse(paramData); } #if defined(ANSI) else if (op.GetType() == SKIM_TC_ERROR) { printf("Received Return Error with Invoke id = %d\n", op.GetInvokeId()); } #endif #if defined(CCITT) else if (op.GetType() == SKIM_TC_U_ERROR) { printf("Received Return Error Last with Invoke id = %d\n", op.GetInvokeId());

104 55 I nt egrat ing Encoder- Decoder wit h SKTAL and SKI M

} #endif #if defined(ANSI) else if (op.GetType() == SKIM_TC_REJECT) { printf("Received Return Reject with Invoke id = %d\n", op.GetInvokeId()); } #endif #if defined(CCITT) else if (op.GetType() == SKIM_TC_U_REJECT || op.GetType() == SKIM_TC_L_REJECT || op.GetType() == SKIM_TC_R_REJECT) { printf("Received Return Error Last with Invoke id = %d\n", op.GetInvokeId()); } #endif else { printf("Unknown operation type received\n"); }

} }

5.1.5 Receiving Notifications Notifications are received via notification handler, registered during initialization. Sample implementation for notification handler is shown in the following code snippet. int APP_NotifyHandler( SKIM_Notify ¬ify, void *tag) { printf("APP_NotifyHandler Invoked\n"); int type = notify.GetType();

switch(type) { case SKIM_NOTIFY_OP_TIMEOUT :

printf ("Operation Timeout Notification Message Received\n");

break;

case SKIM_NOTIFY_SCCP_MGMT_IND :

printf ("SCCP Management Notification Message Received\n");

break;

case SKIM_NOTIFY_MTP3_MGMT_IND :

printf ("MTP3 Management Notification Message Received\n");

break;

case SKIM_NOTIFY_INTERNAL_ERROR :

printf ("SKIM Internal Error Notification Message Received\n");

break;

default :

printf("Unknown Notification Received \n");

break;

105 55 I nt egrat ing Encoder- Decoder wit h SKTAL and SKI M

}; return SKIM_SUCCESS; }

5.1.6 Terminating SKI M API Object and Disconnect

api_classptr.Terminate();

if (CONN_ID) { skts_destroyConnection(connection); connection = NULL; }

106 55 I nt egrat ing Encoder- Decoder wit h SKTAL and SKI M

5.2 SKTAL Sample Application This section describes a sample application using SKTAL API interface. The following steps are involved:

1. Create a connection with LLC using Switch Kit APIs

2. Initialize SK-TAL and register SSN 3. Send a TCAP Dialogue and Component

4. Receive a TCAP Transaction

5. Terminate SK-TAL and Disconnect

5.2.1 Creating a Connection with LLC Using Switch Kit API s connect() { int ret; /* Create the connection */ connection = skts_createConnectionWithID(CONN_ID, CONN_LABEL, CONN_NAME, SKTAL_FALSE, PRI_IP, PRI_PORT, BACK_IP, BACK_PORT); if (ret == 0) { fprintf(stderr, "Error connecting to switch\n"); return (SKTAL_EINVALIDARGS); } return (SKTAL_SUCCESS); }

5.2.2 I nitializing SKTAL and Registering SSN // Initialize TAL layer // TAL initialization is done once at application startup. ret = sktal_initializeTCAP() if (ret != SK_OK) { fprintf(stderr, "Error initializing TCAP: %s\n", sk_errorText(ret)); skts_destroyConnection(CONN_ID); return (SKTAL_EINVALIDARGS); } // Register SSN with TCAP // LOCAL_NODE - value created during configuration // STACK_ID - Stack Id for the stack instance created during configuration // CONN_ID - Same as created in step one. // LOCAL_PC - Local Point Code for stack instance // LOCAL_SSN - local subsystem number for stack instance // newDialogue - Default Handler for handling new // TCAP Transaction messages // instance - instance value returned after registration is successful. // This instance value is used while sending and receiving TCAP // dialogues and components. ret = sktal_registerTCAPSSNHandler (LOCAL_NODE, STACK_ID, LOCAL_PC, LOCAL_SSN, newDialogue, &instance, CONN_ID); if (ret != SK_OK) { fprintf(stderr, "Error registering handler: %s\n", sk_errorText(ret)); skts_destroyConnection(CONN_ID); }

107 55 I nt egrat ing Encoder- Decoder wit h SKTAL and SKI M

5.2.3 Sending a TCAP Dialogue and Component // Allocate dialogue id. Instance value is returned during registration. ret = sk_allocateTCAPDialogueID(instance, &did); if (ret != SK_OK) { printf("Failed to allocate dialog id: %d\n", ret); }

// Create TCAP Begin dialogue object sktal::TCAP_Begin begin;

// Populate orignating and destination point codes. begin.SetOPC(LOCAL_PC); begin.SetDPC(REMOTE_PC);

// Populate orignating SCCP address begin.SetOrigAddr(true, LOCAL_PC, LOCAL_SSN);

// Populate destination SCCP address begin.SetOrigAddr(true, LOCAL_PC, LOCAL_SSN);

// Populate destination SCCP address begin.SetDestAddr(true, REMOTE_PC, REMOTE_SSN);

// Set dialogue id allocated. begin.SetDialogueID(did);

// Create TCAP invoke component instance. sktal::TCAP_Invoke invoke;

invoke.SetOperation(true, 1, 1);

// Set invoke id. invoke.SetInvokeID(1);

// Set invoke timeout. invoke.SetTimeOut(20);

// Set encoded parameters of TCAP User part // API’s like ANSI-41, MAP, CAMEL etc. invoke.SetParameter(encodedParam);

// Send TCAP Component ret = sktal::TCAP_Component::Send(sktal_getTCAPHandle(instance), &begin, &invoke); if (ret != SKTAL_SUCCESS) { printf("Failed to send component: %d\n", ret); } else { // Send TCAP dialogue ret = sktal::TCAP_Dialogue::Send(sktal_getTCAPHandle(instance), &begin);

if (ret != SKTAL_SUCCESS) { printf("Failed to send dialogue: %d\n", ret); } }

108 55 I nt egrat ing Encoder- Decoder wit h SKTAL and SKI M

5.2.4 Receiving a TCAP Transaction Transactions are received via dialogue handler and registered with SKTAL. Sample implementation for dialogue handler is shown in the following code snippet. i/* * new dialogue handler */ extern "C" int newDialogue(int instance, unsigned newDID) { printf("NEW DIALOGUE: %08x\n", newDID);

// register a message handler for new dialogue. return sktal_setTCAPDialogHandler(instance, newDID, onMessage, NULL); }

/* * Message handler. */ extern "C" int onMessage(int instance, SKTAL_EVENT *ev, void *tag) { static sktal::TCAP_Dialogue *dlg = NULL; TCAP_CPT cpt; sktal::Event event; unsigned did;

printf("ON MESSAGE\n"); if (TCAP_MSG_TYPE(ev) == SKTAL_TCAP_DLG) { event = ev; sktal::TCAP_Dialogue::Receive(sktal_getTCAPHandle(instance), event, &dlg);

if (dlg) { dlg->Print(std::cout); } } else if (TCAP_MSG_TYPE(ev) == SKTAL_TCAP_CPT) { printf("Got component\n"); sktal::TCAP_Component *result;

event = ev; sktal::TCAP_Component::Receive(sktal_getTCAPHandle(instance), event, dlg, &result);

result->Print(std::cout);

delete result; delete dlg; dlg = NULL; } else { fprintf(stderr, "Unknown message type: %d\n", TCAP_MSG_TYPE(ev)); }

printf("RETURN FROM USER HANDLER\n");

return (SK_OK); } }

109 55 I nt egrat ing Encoder- Decoder wit h SKTAL and SKI M

5.2.5 Terminating SKTAL and Disconnecting // Unregister SSN instance. if (instance >= 0) { sktal_unregisterTCAPSSNHandler (instance); instance = -1; }

// Terminate SKTAL stalk_terminateTCAP();

// disconnect if (connection) { skts_destroyConnection(CONN_ID); connection = NULL; }

110 CChhaapptteerr 66 CAMEL User’s Guide

6 Building and Running CAMEL Application

This chapter describes building and running a CAMEL application on:  Solaris  HP-UX  Linux

6.1 Building and Running CAMEL Application on Solaris This section describes building and running a CAMEL application on Solaris.

6.1.1 Prerequisites for Building CAMEL Application Following are the prerequisites:

1. Any one of the following compiler is required to build the application:

a. gnu: gcc3.2.1 b. Sun Forte: CC Forte6 Update2

2. Set the following environment variable:

ITS_ROOT = base directory where SK-IM/TAL package is downloaded. (Assuming that the package has been installed under /opt/SK-IM-TAL)

6.1.2 Compiling CAMEL Application Include Directories Add the following paths in the Make file:  -I $(ITS_ROOT)/itsinc  -I $(ITS_ROOT)/itsinc/asn-cpp  -I $(ITS_ROOT)/itsinc/CAMEL/itu Perform the following steps:

1. Do a 'make clean' to remove any previously existing libraries and executables 2. Do a 'make' to compile the application

111 66 Building and Running CAMEL Applicat ion

6.1.3 Linking CAMEL Application The following IntelliNet libraries are required to build the sample application: Library Name Functionality Provided CAP-V4++. a CAP codec APIs library ASN++.a ASN C++ Run time library SKIM-TAL-CCITT. a SKIM SK-TAL API libraries Set the following paths for including the above libraries from IntelliNet:  $(ITS_ROOT)/itslib Include the following lines in the Make file to link the application with the IntelleNet libraries:  L $(ITS_ROOT)/itslib \  -l CAP-V4++ \  -l ASN++ \  -l SKIM-TAL-CCITT \ The above library names are for Release versions of the libraries. For DEBUG versions, the names have to be suffixed with D. For example, CAP-V4++D.a, ASN++D.a Doing a 'make' takes care of both compiling and linking of the sample application.

6.1.4 Running CAMEL Application To run the application, execute the following command:

. / Where is the name of the executable that is created once the compiling and linking are done.

112 66 Building and Running CAMEL Applicat ion

6.2 Building and Running CAMEL Application on HP-UX This section describes building and running a CAMEL application on HP-UX.

6.2.1 Prerequisites for Building CAMEL Application Following are the prerequisites: 1. The following compiler is required to build the application:

aCC: HP ANSI C++ B3910B A.03.371

2. Set the following environment variable: ITS_ROOT = base directory where SK-IM/TAL package is downloaded.

(Assuming that the package has been installed under /opt/SK-IM-TAL)

6.2.2 Compiling CAMEL Application Include Directories Add the following paths in the Make file:  -I $(ITS_ROOT)/itsinc  -I $(ITS_ROOT)/itsinc/asn-cpp  -I $(ITS_ROOT)/itsinc/CAMEL/itu The following steps needs to be performed: 1. Do a 'make clean' to remove any previously existing libraries and executables

2. Do a 'make' to compile the application

6.2.3 Linking CAMEL Application The following IntelliNet libraries are required to build the sample application: Library Name Functionality Provided CAP-V4++. a CAP codec APIs library ASN++.a ASN C++ Run time library SKIM-TAL-CCITT. a SKIM SK-TAL API libraries

Set the following paths for including the above libraries from IntelliNet:  $(ITS_ROOT)/itslib

113 66 Building and Running CAMEL Applicat ion

Include the following lines in the Make file to link the application with the IntelliNet libraries:  L $(ITS_ROOT)/itslib \  -l CAP-V4++ \  -l ASN++ \  -l SKIM-TAL-CCITT \ The above library names are for Release versions of the libraries. For DEBUG versions, the names have to be suffixed with D. For example, CAP-V4++D.a, ASN++D.a

Doing a 'make' takes care of both compiling and linking of the sample application.

6.2.4 Running CAMEL Application To run the application, execute the following command:

. / Where is the name of the executable that is created once the compiling and linking are done.

114 66 Building and Running CAMEL Applicat ion

6.3 Building and Running CAMEL Application on Linux This section describes building and running a CAMEL application on Linux

6.3.1 Prerequisites for Building CAMEL Application Following are the prerequisites: 1. The following compiler is required to build the application:

gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

2. Set the following environment variable: ITS_ROOT = base directory where SK-IM/TAL package is downloaded.

(Assuming that the package has been installed under /opt/SK-IM-TAL)

6.3.2 Compiling CAMEL Application Include Directories Add the following paths in the Make file:  -I $(ITS_ROOT)/itsinc  -I $(ITS_ROOT)/itsinc/asn-cpp  -I $(ITS_ROOT)/itsinc/CAMEL/itu The following steps needs to be performed: 1. Do a 'make clean' to remove any previously existing libraries and executables

2. Do a 'make' to compile the application

6.3.3 Linking CAMEL Application The following IntelliNet libraries are required to build the sample application: Library Name Functionality Provided CAP-V4++. a CAP codec APIs library ASN++.a ASN C++ Run time library SKIM-TAL-CCITT. a SKIM SK-TAL API libraries

Set the following paths for including the above libraries from IntelliNet:  $(ITS_ROOT)/itslib

115 66 Building and Running CAMEL Applicat ion

Include the following lines in the Make file to link the application with the IntelliNet libraries:  L $(ITS_ROOT)/itslib \  -l CAP-V4++ \  -l ASN++ \  -l SKIM-TAL-CCITT \ The above library names are for Release versions of the libraries. For DEBUG versions, the names have to be suffixed with D. For example, CAP-V4++D.a, ASN++D.a

Doing a 'make' takes care of both compiling and linking of the sample application.

6.3.4 Running CAMEL Application To run the application, execute the following command:

. / Where is the name of the executable that is created once the compiling and linking are done.

116 66 Building and Running CAMEL Applicat ion

6.4 Licensing For CAMEL API Intellinet CAMEL API is licensed based on host identifier for a given host platform. Host identifier for a SUN Solaris, Linux, and HP-UX platforms can be obtained by running hostid command. For example:  $ hostid 831664bf This host identifier for a given host platform must be provided for generating a license file.

License files must be placed under directory pointed by environment variable ISS7_CONFIG_DIR. If ISS7_CONFIG_DIR environment variable is not set, the license file should be placed under current execution directory. For example:  $echo $ISS7_CONFIG_DIR /opt/accelero/config/  $ls $ISS7_CONFIG_DIR its.lic

Note ISS7_CONFIG_DIR environment variable should always end in '/'.

6.4.1 License I nformation API package contains executable prlicense for printing license file contents and vrlicense for verifying license file contents. Before executing the following commands, please go to the directory - /opt/Intellinet/CAMEL/bin containing the two executables.

Printing License I nformation prlicense executable can be used on any host to print the contents of license file. For example:  $./prlicense Following is the license info. cookie : 0xdeadbeef expiry : 0xffffffff duration : 0xffffffff max_voice_ports: 0xffffffff max_links : 0xffff revision : 7.0 serial_number : 0x831664bf ------Licenses enabled for: camel ------

The output in the above table shows license is enabled for host id 0x831664bf for the following API:  CAMEL

117 66 Building and Running CAMEL Applicat ion

Verifying License I nformation vrlicense executable verifies that the license is valid for the host. If the host is valid, contents of the license file are printed. For example:  $./vrlicense Following is the license info. cookie : 0xdeadbeef expiry : 0xffffffff duration : 0xffffffff max_voice_ports: 0xffffffff max_links : 0xffff revision : 7.0 serial_number : 0x831664bf ------Licenses enabled for: camel ------

Note At runtime, the program exits in the case of license error. The following is the license error message displayed when API does not find the license file at runtime: License violation: Error opening license file. Please contact Excel for additional licensing privileges. The following error message is displayed when license is not enabled for CAMEL: License violation: You are not licensed for capability: CAMEL Please contact Excel for additional licensing privileges.

118 AAppppeennddiixx 11 CAMEL User’s Guide

A1 CAMEL Error Codes

Refer the following table for the CAMEL error codes, which are available in cap_cpp.h. CAMEL Message Name ERROR Code ERROR Code (In Decimal) (In HEX) canceled 0 0 cancelFailed 1 1 eTCFailed 3 3 improperCallerResponse 4 4 missingCustomerRecord 6 6 missingParameter 7 7 parameterOutOfRange 8 8 requestedInfoError 10 A systemFailure 11 B taskRefused 12 C unavailableResource 13 D unexpectedComponentSequence 14 E unexpectedDataValue 15 F unexpectedParameter 16 10 unknownLegID 17 11 unknownPDPID 50 32 unknownCSID 51 33

119 AAppppeennddiixx 22 CAMEL User’s Guide

A2 CAMEL Operations

The following table summarizes the CAMEL operation codes, which are available in cap_cpp.h. CAMEL Message Name Operation Code Operation Code (In Decimal) (In HEX) gsmSCF activation Package initialDP 0 0 gsmSCF/gsmSRF activation of assist Package assistRequestInstructions 16 10 Assist connection establishment Package EstablishTemporaryConnection 17 11 Generic disconnect resource Package DisconnectForwardConnection 18 12 DFCWithArgument 86 56 Non-assisted connection establishment Package connectToResource 19 13 Connect Package (elementary gsmSSF function) connect 20 14 Call handling Package (elementary gsmSSF function) releaseCall 22 16 BCSM Event handling Package requestReportBCSMEvent 23 17 eventReportBCSM 24 18 Charging Event handling Package requestNotificationChargingEvent 25 19 eventNotificationCharging 26 1A gsmSSF call processing Package Continue 31 1F ContinueWithArgument 56 38 gsmSCF call initiation Package initiateCallAttempt 32 20 Timer Package resetTimer 33 21 Billing Package FurnishChargingInformation 34 22 Charging Package ApplyCharging 35 23 applyChargingReport 36 24 PlayTone 97 61 Traffic management Package

120 AA22 CAMEL Operat ions

CallGap 41 29 Call report Package CallInformationReport 44 2C callInformationRequest 45 2D Signaling control Package sendChargingInformation 46 2E Specialized resource control Package PlayAnnouncement 47 2F promptAndCollectUserInformation 48 30 SpecializedResourceReport 49 31 Cancel Package cancel 53 35 Activity Test Package activityTest 55 37 CPH Response Package continueWithArgument 88 58 disconnectLeg 90 5A moveLeg 93 5D splitLeg 95 5F Exception Inform Package entityReleased 96 60 Sms Activation Package initialDPSMS 60 3C Sms Billing Package furnishChargingInformationSMS 61 3D Sms Connect Package connectSMS 62 3E Sms Event Handling Package requestReportSMSEvent 63 3F eventReportSMS 64 40 Sms Processing Package continueSMS 65 41 Sms Release Package releaseSMS 66 42 Sms Timer Package resetTimerSMS 67 43 Gprs Activity Test Package activityTestGPRS 70 46 Gprs Charging Package

121 AA22 CAMEL Operat ions

applyChargingGPRS 71 47 applyChargingReportGPRS 72 48 Gprs Cancel Package cancelGPRS 73 49 Gprs Connect Package connectGPRS 74 4A Gprs Processing Package continueGPRS 75 4B Gprs Exception Information Package entityReleasedGPRS 76 4C Gprs Billing Package furnishChargingInformationGPRS 77 4D Gprs Scf Activation Package initialDPGPRS 78 4E Gprs Release Package releaseGPRS 79 4F Gprs Event Handling Package eventReportGPRS 80 50 requestReportGPRSEvent 81 51 Gprs Timer Package resetTimerGPRS 82 52 Gprs Charge Advice Package SendChargingInformationGPRS 83 53

122 AAppppeennddiixx 33 CAMEL User’s Guide

A3 Index

ANSI/CCITT standards...... 6 Home Public Land Mobile Network CAMEL API Key Features...... 4, 8, 12 (HPLMN) ...... 8 CAMEL Error Codes...... 5, 111 Initializing SKTAL and Registering SSN CAMEL features...... 12 ...... 105 CAMEL Messages...... 4, 6, 38 Linking CAMEL Application...... 5, 109 CAMEL Network Architecture...... 4, 8, 9 Memory Allocation/Deallocation...4, 92, 96 CAMEL Operations...... 5, 112 Mobile Application Part ...... 9 CAMEL Overview...... 4, 8 Operation Code tag...... 26 Circuit Switched Call Control ...... 38 Parameter Retrieval ...... 4, 95 Common Procedures...... 4, 29 Parameter tag...... 26 Compiling CAMEL Application...... 5, 109 Prerequisites for Building CAMEL Component ID tag...... 26 Application...... 5, 109 Component Portion....4, 13, 15, 16, 21, 23 Pretty Printing...... 4, 92, 97 Component type tag...... 24 Problem Code ...... 27 Converting to ASN BER Format...... 4, 91 Receiving a TCAP Transaction5, 101, 107 Creating a Connection with LLC Using Running CAMEL Application5, 6, 109, 110 Switch Kit APIs...... 99, 105 Sending a TCAP Dialogue and Creating an Instance of SKIM API Class 5, Component...... 5, 106 99 Services Assumed from TCAP ...... 4, 28 Decoding CAMEL Operation ...... 4, 94 Setting Parameters ...... 4, 90 Detection Points...... 4, 8, 11 SKIM Sample Application ...... 99 Dialogue Control PDUs...... 18 SKTAL Sample Application...... 105 Dialogue Portion...... 4, 15, 16, 17, 18 SMS Control...... 69 Encoding CAMEL Operation ...... 4, 89 TCAP Overview...... 4, 13 Error Code tag...... 27 Terminating SKIM API Object...... 5, 104 Exception Handling...... 4, 92, 97 Terminating SKTAL and Disconnecting Functional Entities Used for CAMEL..... 10 ...... 108 GPRS Control ...... 76 Transaction Portion ...... 4, 13, 14, 15, 16 Home Location Register (HLR) ...... 8

123