Analysis of ss7 high-speed link (hsl) quad interoperability test plan




Дата канвертавання21.04.2016
Памер24.26 Kb.

ANALYSIS OF SS7 HIGH-SPEED LINK (HSL)

QUAD INTEROPERABILITY TEST PLAN




Nabeel Cocker, Rimma Iontel, Wichean Preedalumpabut, Malathi Veeraraghavan




Abstract




1 Introduction





The purpose of this document is to analyze Telcordia’s HSL test plan with special attention to how well the tests cover requirements specified in various Generic Requirements (GR) documents. The Tests tests had to extensively cover both the requirements for nodes supporting HSL [2] and specific requirements for referring to STP functionality of STP [3].

GR documents provided by Bell Labs and Bell Atlantic had a number of different requirements (R) covering a range of issues. Handling of messages going through the network, procedures dealing with operations and maintenance of links, as well as the functions and procedures inside a single STP had been standardized. Since some of the features were left to be implementation dependant, documents also contain conditional requirements (CR), objectives (O), and conditional objectives (CO). During our analysis of tests in conjunction with the requirements we concentrated on Rs and also CRs, where appropriate. For later releases Os and COs may become relevant.

The Test tests had to take into the account that the main goal was to make sure that STPs produced by different vendors could interoperate with each other. The Two two products tested in [1] were Tekelec EAGLE STP Release 23.0 and Nortel DMS STP Release 04. Besides meeting the standards, products should maintain seamless interaction interworking where implementation dependant issues are involved.

The Introduction introduction of HSL into the network forced the biggest change to be made to Level 2 of SS7 protocol stack. The functionality of this level therefore is of a vital importance and one of the concentration points in all of the tests.

While the network undergoes a change from 56 kbps links to HSL, some of the low speed links will stay in place and new STPs should still be able to handle the traffic along those links. Meeting the requirements for handling the situation of mixed mode traffic is also one of the targets in the test that had to be verified.

The rest of this paper is organized as follows. Section 2 provides the methodology used to analyze the scope and validity of the tests. Section 3 focuses on requirements specific to [2]HSLs. Section 4 focuses on requirements presented in [3]. Section 5 gives our opinion on possibly redundant tests. Section 6 presents the conclusion.




2Methodology used for analysis





We took the following steps when analyzing the test plan. For each requirement and conditional requirement in [2] and [3] we checked for a corresponding test case. Where the requirement was concerned with protocol layer specifications we worked out expected test sequences (messages/primitives). We also listed all peer-to-peer messages that would be generated by different layers during various procedures and transfers and then checked if there was at least one test case which would cause the message to be used. We used a similar procedure to test the generation of primitives and signals going through between the layers of the STP.

After concluding the analysis of how thoroughly the test covers each requirement we assessed the test from a different point of view, we looked for the tests that were testing requirements already covered by previous tests and thus were redundant. Table ## shows the structure we used to make the determination.

Finally, we tried to look at the requirements and existing tests and determine if any of the missing tests were feasible to do given the time and additional resources.




3Test coverage of GR-2878 requirements





    1. Functional requirements




ThisFunctional requirements section covers all of the protocol-related issues. It lists all of the functions each layer should be equipped to handle. Also it covers the interaction between the layers and primitives and messages that would be generated to accomplish the interaction. Procedures and specific conditions that would activate those procedures are a part of this section, as well. Another aspect covered in the functional requirements is the default values of various timers and number of PDUs generated.

Table 3.1 lists the requirements provided in functional requirements section of [2]






    1. Performance requirements

Performance requirementsThis section deals with the numbers allowed for reliability, various delays, and capacity. Table 3.2 addresses these requirements and the tests that cover them.

Reliability is one of the requirements that cannot be tested easily since it calls for a year’s observation of the functioning of the STP to verify if its downtime exceeds allowable 10 minutes/year.

There are two main delays are specified: link output delay, and cross-STP transport time delay.



cross-STP transport time = STP node processing time + link output delay

Processing time is the interval between the instant the STP receives the last bit of an incoming message and the time the message is placed into the output buffer.



link output delay = queuing delay + emission time

Queuing delay is the time between placing a message into the output buffer and time when the first bit is transmitted.

While cross-STP transport time delay can be easily checked using MGTS, link output delay is much harder to test. The existing test cases do not cover this particular requirement list well.

Capacity is another requirement that was not tested but since [2] does not provide specific numbers we made our own approximation for this value.





Using link speed of 1.5 Mbps, minimum message size of 15 octets, and 4 links we get a capacity = of 50000 messages/sec.




Requirements

Test

Signaling Link Activation

5.1.1

Signaling Link Restoration

5.1.3

Signaling Link Deactivation

5.2.2

Extended Changover/Changeback

5.1.3, 5.2.2, 5.2.3

Forced/Controlled Rerouting

5.2.3

MTP Restart

No test

Management Inhibiting

5.2.1, 5.2.7

Signaling Traffic Flow Control

5.2.6

Time Controlled Diversion

No test

Time Controlled Changeover

5.2.7

Transfer Prohibited/Allowed/Controlled

5.2.3

Signaling Route-Set Test

5.2.3

Transfer Controlled

5.1.4

Signaling Route-set-congestion Test

5.1.4

Message Handling

5.1.2

SSCF Functions (no peer-to-peer)

5.1.1, 5.1.2, 5.1.3
















































База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка