Browse Prior Art Database

Method to Support Multiple Telco Protocols Testing in a Toolkit Test Container

IP.com Disclosure Number: IPCOM000173728D
Original Publication Date: 2008-Aug-22
Included in the Prior Art Database: 2008-Aug-22
Document File: 3 page(s) / 160K

Publishing Venue

IBM

Abstract

Telco protocols are complex in nature. They expect a large number of parameters to be set in the request objects. The returned response objects contain a large amount of data. Developing a test client so that a tester or a system integrator could send these requests and handle responses is a significantly tedious effort. Stress testing a network using these test clients is another complicated task. The clients should be able to inject significantly high traffic volume, some times synchronously or asynchronously to test various network scenarios. The current solutions include developing an end-to-end test application. The major drawback with such solution is that, when a new protocol need to be supported, the developer has to code the application from end-to-end from scratch, and the user has to learn the user interface for each protocol solution with no commonality thereby increasing the education cost.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Method to Support Multiple Telco Protocols Testing in a Toolkit Test Container

Method to Support Multiple Telco Protocols Testing in a Toolkit Test ContainerMethod to Support Multiple Telco Protocols Testing in a Toolkit Test Container

Disclosed here is a unique method, which provides a core Controller and Model state machine, and further publishes a set of interfaces for a developer to extend and provide their own protocol implementation. The core controller handles majority of the functionality and delegates protocol unique tasks to the contributed classes. The design is a result of past experience, which we have seen in the fields and this we think will fill that gap by significantly easing the burden on the developer community writing such tools.

The core Controller provides an easy to use interface that is common for each protocol implementation, so that the protocol tester does not need to learn an new application interface for each protocol being tested.

Figure 1 below shows a screenshot of the Tool upon contribution. The picture shows developer contributing different protocols, e.g. XCap and SIP. The contributed request shows up as an Eclipse View. The container manages the execution order, introducing timers, pausing, executing in parallel or in sequential and various other operations. Upon executing a request, the results are sent to the IIMSLogger which in this case writes it to a User Interface. Another implementation might write it out to a database or to a socket.

Figure 1.

1

[This page contains 1 picture or other non-text object]

Page 2 of 3

Figure 2 below shows the interfaces and their details.

IIMSRequest

IIMSJobRunner

IIMSLogger

Figure 2.

As shown in Figure 2, for each protocol, a developer has to implement these three interfaces.
• IIMSRequest
• IIMSJobRunner
• IIMSLogger

Use Case and Flow Chart:


Provide XCap protocol extension the existing IMS Telecom Test Container:
A developer desires to add XCap protocol test capability to the Test Container. He has to review...