JAIN(tm) TCAP
Compatibility Test Suit (CTS) Specification
Copyright - 1999 Sun Microsystems, Inc. All rights reserved.
901 San Antonio Road, Palo Alto, California 94043, U.S.A.
This product and related documentation are protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any.
RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the United States Government is subject to the restrictions set forth in DFARS 252.227-7013 (c)(1)(ii) and FAR 52.227-19.
The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applications.
TRADEMARKS
Sun, the Sun logo, Sun Microsystems, Java, Java Compatible, JavaBeans, Solaris,Write Once, Run Anywhere, JDK, Java Development Kit, and JavaStation are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and certain other countries. UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. All other product names mentioned herein are the trademarks of their respective owners.
THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THE PUBLICATION. SUN MICROSYSTEMS, INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS PUBLICATION AT ANY TIME.
The purpose of this document is to detail the test cases, for the Compatibility Test Suite relevant to the JAIN TCAP API Protocol. The Compatibility Test Suite (CTS) tests an implementation of the JAIN interfaces for compliance with the JAIN Specification. The purpose of the JAIN TCAP CTS is to verify that a Java TCAP implementation is compatible with the JAIN TCAP API Specification. [See RQS-JAIN-TCAP-001.] The test cases outlined in this document are based on the JAIN TCAP API Specification requirements that are specific to the remit of the CTS. This document also details the initial architectural set up required for the CTS.2.1 Support SoftwareThe CTS will have also have the ability to run against the JAIN TCAP Reference Implementation (RI) see [See RQS-JAIN-TCAP-001.] The RI will emulate the functions of an SS7 stack (but will not be an SS7 stack) in order to verify the requirements in this specification. The intention of the RI is not to implement an SS7 stack or to replace vendor SS7 stacks. The purpose of the RI is to provide a means to verify that JAIN applications are compatible with their appropriate JAIN specification. The requirements for the RI are outlined in the JAIN TCAP API Reference Implementation Requirements Specification document.
A test program written using JDK1.2 will be used during the tests. It is necessary to apply the following requirements as listed in the JAIN TCAP Requirements Specification.REQ-RR-01-01: In order to execute the JAIN TCAP Compatibility Test Suite, or a JAIN TCAP application, the following shall be required:
1. The JAIN TCAP API specification is implemented over a JAIN compliant protocol stack or over the Reference Implementation.
2. Java Virtual Machine
The CTS interfaces with either the Reference Implementation (RI) or a Vendor Specific Implementation of the JAIN TCAP API, specifically the 'JainTcapStack' interface and the 'JainTcapProvider' interface.
The RI or the Vendor Specific Implementation will be refered to as the vendor throughout the document.After the initial setup, the JAIN CTS Listener should be capable of sending and receiving Events, see Section 4.0. The CTS test cases can then be run.
4.1 Tc_User addresses
Messages are sent from the Listener and addressed to the Destination node. The Destination node's TC_User address is the same as the originating Listener's TC_User address. Therefore any messages sent from the Listener will be expected to be routed through the SS7 stack and back to the same Listener (i.e. the Destination).The messages will be passed from the Listener to the JAIN TCAP Provider Implementation and into the SS7 stack. These messages are considered local to the SS7 stack because the destination node has the same Signaling Point Code (SPC) as the SS7 stack. In effect the Signaling Connection Control Point (SCCP) layer of the SS7 stack will recognise that the messages are local and pass the messages back up the stack to the Provider. The messages are then routed back to the Listener. [See Figure 4.1]
Consequently as messages travel only as far as the SCCP layer before they are routed back up the SS7 stack, only one SS7 stack is required in order to run the CTS test cases.
Figure 4.1 JAIN TCAP API CTS Message routing.
4. 2 Method invocations
As a result of the running the CTS a Test Report is produced. The CTS report includes a success status for each test. In addition a detailed execution trace will be output.If all test cases are passed the JAIN TCAP Implementation will be considered JAIN Compliant.
REQ-CR-01-01: A JAIN TCAP Implementation shall be compatible after passing the CTS.
Many of the Test Cases, which are based on the JAIN TCAP API specification requirements applicable to the scope of the CTS, will be effectively passed if the CTS setup architecture is adhered to and components and dialogues can be routed successfully from Listener to destination. However the test cases outlined will individually test all appropriate aspects of the CTS and a report will be generated.The JAIN TCAP CTS will only test a 1:1 Provider / Listener relationship. A future release of the JAIN TCAP CTS will test a multiple Provider / Listener relationship. Details of test cases to be included in future releases of the JAIN TCAP CTS are outlined in section 6.0.
The test cases in this section consist of a Test Case name, reference number, the JAIN TCAP API requirement being tested, Test purpose and a Test result required for a success.
Test Type | Test Reference |
Set Up Configuration | 6.2, 6.6, 6.10 |
Message Sending | 6.2, 6.3, 6.4, 6.5, 6.7, 6.8, 6.9, 6.11, 6.14, 6.16, 6.17 |
Message Sending (with modifications) | 6.12, 6.13, 6.15 |
Table 6.1 Test Case categories
There is specific test case for each requirement applicable to the CTS based on the JAIN TCAP Requirement Specification. The CTS Test Report [see section 5.0] will individually list results based on each test case.
Test Reference Test Case Requirement being tested : TCAP Requirement Specification Reference 6.1 CTS Set Up The ability to correctly set up the CTS architecture as detailed in section 3.0 6.2 Sending Component and Dialogue primitives from Listener to destination. To ensure that Component and Dialogue primitives are sent from the Listener to destination. 6.3 Indication Event sending verification REQ-ER-03-01: Indication Events shall only be sent from the Provider to the Listener 6.4 Verification of passing Events with same Dialogue ID to the same Listener. REQ-ER-05-01: Events with the same Dialogue Id shall be passed to the same Listener. 6.5 Verification of Event passing to specified User Address. REQ-ER-06-01: Events shall only be passed to the Listener with the corresponding User Address 6.6 Verification of attachment and detachment of Provider to TCAP layer REQ-PR-01-01: One or more Providers shall have the capability to be attached or detached to a TCAP layer at any time. 6.7 Provider message routing. REQ-PR-03-01: A Provider shall be able to route messages to all Listeners registered with it. 6.8 Listener Message Routing REQ-PR-05-01: All Events associated with a Dialogue (identified by the Dialogue ID) shall be passed to that Dialogue's Provider. 6.9 Verification of Event passing of TCAP messages passed through Provider Peer to Listener REQ-PR-06-01: All TCAP messages shall be passed through the Provider peer to the Listener as Events 6.10 Listener registration REQ-LR-01-01: All JAIN TCAP Listeners shall be able to register with all JAIN TCAP Providers 6.11 Verification of passing TCAP messages using the Event Model. REQ-LR-03-01: The TCAP Listener shall receive TCAP messages from a JAIN TCAP Provider by following the JavaBeanä Event model. [See Section 3.3.1.1 of the JAIN TCAP API Requirements Specification] 6.12 Exception throwing REQ-NC-02-01: All access methods shall throw an exception when accessing a parameter that has not previously been set or is not supported by a specific implementation. 6.13 Verification of API ability to map protocol variant information. REQ-CD-01-01: The API shall incorporate a common set of primitives that will map to protocol variant information. [See Reference 2-5 of JAIN TCAP API Requirement Specification] 6.14 Message order verification. REQ-PR-07-01: The Provider peer shall ensure that the order in which associated components encapsulated as Events are received by it, is the same order at, which they are passed to the TCAP layer 6.15 Performance Testing REQ-PF-01-01: Assuming a quiet system and no extraneous processing, the message latency from the top of the protocol stack through the API implementation into the JAIN TCAP Application shall not exceed on average one second. 6.16 Sending Components and Dialogues between Provider and Listener as Events. REQ-ER-01-01: The API implementation should send Component and Dialogue handling primitives between the Provider and the Listener as Events. 6.17 Sending Component and Dialogue primitives separately between Provider and Listener. REQ-ER-02-01: Events representing Component and Dialogue handling primitives shall be sent separately between the Provider and Listener. Table 6.2 Test Case Index
6.1.1 Test purposeThe ability to correctly set up the CTS architecture as detailed in section 3.0.
6.1.1 Test procedure
As detailed in section 3.0, the user executes the TestSuite.java class. This prompts the user for a Stack Class name, Protocol version and Provider class name. The CTS Listener is instantiated, followed by a Factory object, a JAIN TCAP stack object and JAIN TCAP Provider which is attached to the stack. Registration for Event listening then takes place. Many of the procedures required to set up the CTS architecture, for example Event Listener registration, are listed as requirements of the JAIN TCAP API specification. Consequently verification of a correct set up will result in several of the Test Cases in this section including this one being passed.
6.1.3 Test result
The Test Report includes a detailed execution log. In addition the status of all relevant Test Cases effected by the set up are reported in the Test Report. After set up the CTS Listener is able to send and receive Events.
6.2.1 Test purposeTo ensure that Component and Dialogue primitives are sent from the Listener to destination.
6.2.2 Test procedure
The CTS set up procedure should be adhered to. As outlined in section 4.0 the Listener creates dialogues and components, which are routed to the destination. As the CTS v1.0 architecture includes only one Listener the destination is the Listener which sent the original message. If the Listener can successfully send and receive messages using the architecture detailed in section 3.0 the test cases (including this one) in table X.X will be passed.
6.2.3 Test result
The Test Report includes a detailed execution log. The report will list the messages received with a breakdown of their content. In addition the status of all relevant Test Cases effected by the sending and receiving of messages are reported in the Test Report.
REQ-ER-03-01: Indication Events shall only be sent from the Provider to the Listener6.3.1 Test purpose
This test checks if Events of type Indication are sent from the Provider to the Listener.
6.3.2 Test procedure
The process of sending events from Listener to Destination outlined in section 4.0 will be adhered to. The implementation of the JAIN TCAP API Listener restricts the object to receive events of type Indication, it therefore follows that if sections 3.0 and 4.0 are adhered to this test is passed. However in addition a flag will be set if the Listener successfully receives an Indication event from the Provider. A list of received events will be reported. If the Provider attempts to send any other type of Event a method Not Found Exception will be thrown.
6.3.3 Test result
The corresponding flag for this test will be set as passed, if the Listener receives an Indication event.
Figure 6.3 Passing Events between Provider and Listener.
REQ-ER-05-01: Events with the same Dialogue Id shall be passed to the same Listener.6.4.1 Test purpose
Tests that all Events with the same Dialogue ID are successfully passed to the same Listener.
6.4.2 Test procedure
As the CTS V1.0 for JAIN TCAP API is restricted to a 1:1 Provider: Listener relationship this test does not test the multiple cardinality aspect of the original JAIN TCAP API requirement [REQ-ER-05-01]. However the process of sending events from Listener to Destination outlined in section 4.0 will be adhered to. A predetermined number of Events are sent from the Listener. The Listener shall examine the Events received by it to ensure it receives all the Events associated with the same DialogueId.
6.4.3 Test result
This test will be considered passed if the Listener receives all the Events associated with the same DialogueId that it originally sent. The CTS execution log outputs details of primitives received and if all events are received successfully the test case flag is set as passed.
REQ-ER-06-01: Events shall only be passed to the Listener with the corresponding User Address6.5.1 Test purpose
Tests the ability of the Provider to pass Events to a Listener with a specified User Address.
6.5.2 Test procedure
As the CTS for JAIN TCAP API is restricted to a one Provider to Listener relationship this test does not test the multiple cardinality aspect of the original JAIN TCAP API requirement [REQ-ER-06-01]. However the process of sending events from Listener to Destination node outlined in section 4.0 will be adhered to. As User Address is used to route the events the Listener shall examine the Events sent to it to ensure it receives all the Events it sent.
6.5.3 Test result
A report of all Event User Addresses received by the Listener will be output and a comparison with Events sent compiled. Any difference will be highlighted.
REQ-PR-01-01: One or more Providers shall have the capability to be attached or detached to a TCAP layer at any time.6.6.1 Test purpose
This case will ensure that it is possible to attach a Provider to the JAIN TCAP Stack Object. It will also test the ability to detach the Provider.
6.6.2 Test procedure
As the CTS for JAIN TCAP API is restricted to a one Provider to Listener relationship this test does not test the multiple cardinality aspect of the original JAIN TCAP API requirement [REQ-PR-01-01]. If the CTS set up [section 3.0] is adhered to and the sending of Events [section 4] is successfully applied then the Provider attachment part of this test will be considered to have been passed. The CTS will attempt to detach the Provider to satisfy the second part.
6.6.3 Test result
The Provider is shown to successfully attach and then detach.
REQ-PR-03-01: A Provider shall be able to route messages to all Listeners registered with it.6.7.1 Test purpose
As the CTS for JAIN TCAP API is restricted to a one Provider to Listener relationship this test does not test the multiple cardinality aspect of the original JAIN TCAP API requirement [REQ-PR-03-01]. This test case tests the ability of a Provider to route messages to its registered Event Listener.
6.7.2 Test procedure
The process of sending events from Listener to Destination node outlined in section 4.0 will be adhered to. In order to route Dialogue Requests it sends back to itself the Listener sets the Destination address as the Originating Tc_User Address.
6.7.3 Test result
The Listener exams the Destination Address of all Dialogues it receives. If the Destination address is the same as the Tc_User Address of the Listener then this test is considered passed.
REQ-PR-05-01: All Events associated with a Dialogue (identified by the Dialogue ID) shall be passed to that Dialogue's Provider.6.8.1 Test purpose
This test case tests the ability of a Listener to route messages to the appropriate Provider. As the CTS for JAIN TCAP API is restricted to a one Provider to Listener relationship this test does not test the multiple cardinality aspect of the original JAIN TCAP API requirement [REQ-PR-05-01]. This Test Case does not require the Vendor's Provider implementation to notify that that it receives all Events. However as all messages are rerouted back to the Listener through the Provider, if the Events received by the Listener have corresponding settings as those passed by it then this test is considered passed.
6.8.2 Test procedure
The process of sending events from Listener to Destination node outlined in section 4.0 will be adhered to.
6.8.3 Test result
The receipt by the Listener of Component and Dialogue Indications with the same settings as the original Component and Dialogue Requests sent by the Listener will be considered sufficient to pass this test.
REQ-PR-06-01: All TCAP messages shall be passed through the Provider peer to the Listener as Events6.9.1 Test purpose
To ensure that TCAP messages are passed through the Provider peer as Events.
6.9.2 Test procedure
Without imposing restrictions on the Vendor's Provider implementation it is not possible for the CTS to verify at the Provider level if TCAP messages are passed as Events. Therefore the process of sending events from Listener to Destination node outlined in section 4.0 will be adhered to.
6.9.3 Test result
The receipt by the Listener of Indication Components and Dialogues with the corresponding settings as the original Component and Dialogue Requests sent by the Listener will be considered sufficient to pass this test.This ensures that the Provider handles Requests and Indications as Events.
REQ-LR-01-01: All JAIN TCAP Listeners shall be able to register with all JAIN TCAP Providers6.10.1 Test purpose
To ensure that the CTS Listener can register with the Vendor's Provider. As the CTS for JAIN TCAP API is restricted to a one Provider to Listener relationship this test does not test the multiple cardinality aspect of the original JAIN TCAP API requirement
[REQ-LR-01-01].
6.10.2 Test procedure
If the CTS set up [section 3.0] is adhered to and the sending of Events [section 4.0] is successfully applied then the Listener registration will be considered to have been passed. Verification of successful Listener registration will be part of the Test Report.
6.10.3 Test result
Test is passed if the CTS Listener successfully registers as an Event Listener with the Provider.
REQ-LR-03-01: The TCAP Listener shall receive TCAP messages from a JAIN TCAP Provider by following the JavaBeanä Event model. [See Section 3.3.1.1 of the JAIN TCAP API Requirements Specification]6.11.1 Test purpose
To verify that the Java Event Model is used for the passing of messages between the Listener and Provider. The CTS implementation constrains the Listener to receive TCAP messages by using the Java Event Model. The Listener accepts messages from the Provider only via Java Events.
6.11.2 Test procedure
Due to the architectural constraints imposed on the CTS Listener for sending and receiving messages, if the CTS set up [section 3.0] is adhered to and the sending of Events [section 4.0] is successfully applied then this test will be considered to have been passed. Verification of successful Message passing and receiving by the Listener will be part of the Test Report.
6.11.3 Test result
Successful receipt of sent message, see section 4.0.
REQ-NC-02-01: All access methods shall throw an exception when accessing a parameter that has not previously been set or is not supported by a specific implementation.6.12.1 Test purpose
Tests that access methods throw exceptions when accessing a parameter that has not previously been set or is not supported by a specific implementation.
6.12.2 Test procedure
A number of access methods will attempt to access parameters that have not previously been set.
6.12.3 Test Result
The test should confirm that the selected methods that attempt to access non-set parameters throw appropriate exceptions. The exception thrown will be output to the Test Report.
REQ-CD-01-01: The API shall incorporate a common set of primitives that will map to protocol variant information. [See Reference 2-5 of JAIN TCAP API Requirement Specification]6.13.1 Test purpose
Tests the ability of the API to map protocol variants incorporated in a common set of primitives. This relates to ANSI and ITU primitives.
6.13.2 Test procedure
The CTS Listener shall set a selected set of parameters corresponding to both ANSI and ITU variants within a component being sent. Upon receipt of the returned component the Listener will attempt to access all the parameters corresponding to both ANSI and ITU variants. An exception should be thrown when the Listener tries to access the alternative Vendor stack implementation being used.
6.13.3 Test result
Test is passed if the Listener is able to successfully set the selectedprotocol variant parameter and subsequently the appropriate exception thrown when the component is received.
REQ-PR-07-01: The Provider peer shall ensure that the order in which associated components encapsulated as Events are received by it, is the same order at, which they are passed to the TCAP layer.6.14.1 Test purpose
To ensure that the order in which messages are sent are the order in which they are received. To construct a test case, which maps directly to the TCAP API Requirement specification [REQ-PR-07-01] would involve imposing on the Provider the necessity to generate a report on the order it sends a message. Subsequently the TCAP layer would be required to output an analysis of the messages received by it. It is recommended that the CTS does not impose any restrictions on Vendor's implementations apart from those detailed in Sections 3.0 and 4.0. Thereby in order to pass this test a message with known order will be sent from the CTS Listener to a Destination node [see Section 4.0]. The destination node will analyze the order in which the message is received.
6.14.2 Test procedure
A message will be set from CTS Listener to destination node.
6.14.3 Test result
Test will be passed if the order received is the same as the order sent.
![]()
Figure 6.14 Component sending order.
REQ-PF-01-01: Assuming a quiet system and no extraneous processing, the message latency from the top of the protocol stack through the API implementation into the JAIN TCAP Application shall not exceed on average one second.6.15.1 Test purpose
As it is recommended that the CTS does not impose any restrictions on Vendor's implementations apart from those detailed in Sections 3.0 and 4.0, this test does not map precisely to the TCAP API Requirement specification[REQ-PF-01-01]. To do so would necessitate the CTS imposing that a timing device is present at the top of the protocol stack. However it is expected that sending a message from the CTS Listener to a destination node, a process which includes the message travelling from the top of the protocol stack through the API implementation into the JAIN TCAP Applicationwould take less than the specified time in the requirement. Therefore to pass this test case a message should arrive at the Destination node within one second of being sent.
6.15.2 Test procedure
A timer will be started as a message is passed from the CTS Listener. The process outlined in Section 4.0 will be adhered to. When the destination receives the message the timer will be stopped.
6.15.3 Test result
If time taken is less than one second then the test case will be considered passed.
REQ-ER-01-01: The API implementation should send Component and Dialogue handling primitives between the Provider and the Listener as Events.6.16.1 Test purpose
To ensure that Components and Dialogues that are sent between the Provider and Listener are in the form of Events.
6.16.2 Test procedure
After initial set of the CTS see Diagram 3.1, the process of sending events from Listener to Destination node outlined in section 4.0 will be adhered to.
6.16.3 Test result
The CTS Listener is restricted to sending and receiving Components and Dialogues as Events, therefore the receipt by the Listener of Indication Components and Dialogues with the corresponding settings as the original Component and Dialogue Requests sent by the Listener will be considered sufficient to pass this test.
REQ-ER-02-01: Events representing Component and Dialogue handling primitives shall be sent separately between the Provider and Listener.6.17.1 Test purpose
To ensure that the Events that are sent between the Provider and Listener are sent separately.
6.17.2 Test procedure
The process of sending events from Listener to Destination node outlined in section 4.0 will be adhered to. As the Listener receives events they are examined to ensure that they contain separate Components and Dialogues.
6.17.3 Test result
The Listener shall receive Components and Dialogues as separate Events. The received primitives are checked to ensure they have the corresponding settings as those sent.
7.0 Test Cases for future JAIN TCAP API Releases
Due to the restriction of a one Provider to one Listener relationship the following requirements are not tested in CTS 1.0. It is envisaged that they will form individual test cases for future releases of JAIN TCAP APIs.REQ-PR-02-01: The Provider shall have the capability to pass one or more Events to one or more registered Listeners. However, a Provider shall send an Event to only one of the registered Listeners.
REQ-LR-02-01: A Listener shall have the capability to pass one or more Events to one or more Providers.However, a Listener shall send an event to only one Provider.
REQ-PR-04-01: Only one Provider shall be used to handle a particular Dialogue
REQ-LR-04-01: A Listener shall have the capability to register with one or more TCAP Providers using one or more unique User Addresses to receive Events
REQ-LR-07-01: A primary User Address shall uniquely identify one Listener for processing its events.
Abbreviations
ANSI | American National Standards Institute |
API | Application Programming Interface |
CTS | Capability Test Suite |
ITU | International Telecommunications Union |
JAIN | Java APIs for Integrated Network Framework |
SCCP | Signalling Connection Control Point |
TCAP | Transaction Capabilities Application Part |
RI | Reference Implementation |
This document details the Capability Test Suite specification requirements for which an implementation of JAIN interfaces must pass in order to be considered compliant to the JAIN Specification. The purpose of the JAIN CTS is to verify that a Java TCAP protocol implementation is compatible to the JAIN TCAP Specification.
Copyright - 1999 Sun Microsystems
01 September 99