2.1 CMSDB Initialization Test Cases
The SCP Call Management Services Data Base (CMSDB) Initialization (also known as SCP Initialization) test case should be attempted only after the communications start-up procedures are successful, since many of the steps are dependent on the existence of data transfer across the links.
2.1.1 Test Case # 01A CMSDB Initialization (SCP Turn Up)
Keyword |
Value |
Purpose:
Note: This test case can only be run with a CLLI that has not previously existed in the SMS/800. |
This Turn Up Testing is to bring up a new SCP into the existing SMS/800 – SCP network. First, establish the test environment before any part of turn up can proceed. The CLLI code for the new SCP which is defined in the SMS/800 site should be consistent with that defined in the SCP site.
This Turn Up procedure is composed of three main features: DCM Bring Up, SCP Initial Incremental Load, and Batch Retransmission.
The input and output specifications will be combined as a series of steps in this test case. All events must occur in sequence, and the results of each step must be tested and verified before proceeding to the next step.
After the completion of the Turn Up, the status of this new SCP and SMS/800 should be in the data transfer state. |
Method |
Results |
1. SMS/800 will generate specific SMS/800 and SCP Administration tables as described in SMS/800 SCP Turnup Guide (document number BR780-004-212). |
Tables will be set up in the SMS/800. |
2. When SMS/800 – SCP communications (see test case #2) are established, the SMS/800 sends the tables (with default values) needed for initial load over the SMS/800 – SCP links. |
The following messages are sent to update tables:
UPD-CCO UPD-NMP (run 2X to test parameters setup in the ECC and NRL screens) UPD-ETT UPD-ALP UPD-DTT UPD-MNL
Tables should be received and loaded correctly into the SCP. Responses for each should be sent back to SMS/800. |
3. The SMS/800 will send a RTRV- NCD and a RTRV-MNL request to the SCP. |
The SCP should respond with a REPT-NCD and a REPT-MNL. |
4. SMS/800 will create the Incremental Load data for this SCP. Include NXXs for all records that will be included in this test. This data will be sent to the SCP. |
During load, SMS/800 will automatically set the queue status to Queue for this SCP. Load file should be received by SCP. |
2.1.2 Test Case # 01B CMSDB Initialization (SCP Turn Up)
Keyword |
Value |
1. The load file will be processed by the SCP. If the load process succeeds, the SCP will generate a response file and send it to the SMS/800 for processing. |
The load file should be successfully processed and a response file produced. The response file should be processed by SMS/800. |
2. The SCP will bring up the CMSDB application and send the ISA-INACTIVE message to SMS/ 800. The SCP sends an ISA- ACTIVE message to SMS/800 indicating it is ready to go live on the network. |
Both messages should be processed by SMS/800. The SMS/800 DCM tables should be updated.
Note: The purpose of step 2 is to update SMS/800 DCM tables. |
3. SMS/800 will run Batch Retransmit with an effective date on or before the time of the start of the SCP incremental Load. |
Delete messages for DIAL Numbers that were deleted during the load period will be resent. The delete messages should be received at the SCP. Any new messages should be received at the SCP |
4. SMS/800 will transmit a TELL- CUC message that signifies the end of Customer Record transmission. |
The TELL-CUC should be processed by the SCP.
Note: The purpose of step 4 is to verify that batch retransmit has completed. |
5. SMS/800 will send an AUD-CPR message for each of 12 randomly selected Customer Records that contain the SCP in their area of service. |
The SCP should respond with a RSP-AUD message for each AUD- CPR sent by SMS/800 to verify the records match. |
2.2 UPL –TCP/IP Test Cases
2.2.1 Test Case # 02 Connect/Disconnect Sequence – SCP Sends Good Bye
Keyword |
Value |
Purpose |
Verify the SCP can initiate and terminate a connection gracefully with SMS/800 according to the Connect/Disconnect Dialogue in SR-4959.
This should be the first TCP/IP test case performed because all other test cases depend on this test case being successful.
Note: The two systems may not be able to communicate if this initial interface is not working as required. |
Method |
Results |
1. SCP should send TCP Connect Request to SMS/800. |
The SMS/800 processes on each SMS/800 DCM should listen for socket connection requests and send back a TCP Connect Accept. SCP Node and SCP CMSDB connections should be established on each SMS/800 DCM. |
2. SCP should send Good Day message with zero(0) length desNodeName field. |
The SMS/800 should respond with Good Day message with both srcNodeName and desNodeName fields filled in. Both SCP and SMS/800 should be in data transfer phase. |
3. SMS/800 should send any application message. |
SCP should respond with response to the application message. |
4. SCP should send Good Bye message to SMS/800. |
The SMS/800 should finish sending any message that is in progress and disconnect the session. The SCP should receive the message but not attempt to send a response until a new session is established. The existing session should end. |
2.2.2 Test Case # 01B CMSDB Initialization (SCP Turn Up)
Keyword |
Value |
1. The load file will be processed by the SCP. If the load process succeeds, the SCP will generate a response file and send it to the SMS/800 for processing. |
The load file should be successfully processed and a response file produced. The response file should be processed by SMS/800. |
2. The SCP will bring up the CMSDB application and send the ISA-INACTIVE message to SMS/ 800. The SCP sends an ISA- ACTIVE message to SMS/800 indicating it is ready to go live on the network. |
Both messages should be processed by SMS/800. The SMS/800 DCM tables should be updated.
Note: The purpose of step 2 is to update SMS/800 DCM tables. |
3. SMS/800 will run Batch Retransmit with an effective date on or before the time of the start of the SCP incremental Load. |
Delete messages for DIAL Numbers that were deleted during the load period will be resent. The delete messages should be received at the SCP. Any new messages should be received at the SCP |
4. SMS/800 will transmit a TELL- CUC message that signifies the end of Customer Record transmission. |
The TELL-CUC should be processed by the SCP.
Note: The purpose of step 4 is to verify that batch retransmit has completed. |
5. SMS/800 will send an AUD-CPR message for each of 12 randomly selected Customer Records that contain the SCP in their area of service. |
The SCP should respond with a RSP-AUD message for each AUD- CPR sent by SMS/800 to verify the records match. |
2.2 UPL –TCP/IP Test Cases
2.2.1 Test Case # 02 Connect/Disconnect Sequence – SCP Sends Good Bye
Keyword |
Value |
Purpose |
Verify the SCP can initiate and terminate a connection gracefully with SMS/800 according to the Connect/Disconnect Dialogue in SR-4959.
This should be the first TCP/IP test case performed because all other test cases depend on this test case being successful.
Note: The two systems may not be able to communicate if this initial interface is not working as required. |
Method |
Results |
1. SCP should send TCP Connect Request to SMS/800. |
The SMS/800 processes on each SMS/800 DCM should listen for socket connection requests and send back a TCP Connect Accept. SCP Node and SCP CMSDB connections should be established on each SMS/800 DCM. |
2. SCP should send Good Day message with zero(0) length desNodeName field. |
The SMS/800 should respond with Good Day message with both srcNodeName and desNodeName fields filled in. Both SCP and SMS/800 should be in data transfer phase. |
3. SMS/800 should send any application message. |
SCP should respond with response to the application message. |
4. SCP should send Good Bye message to SMS/800. |
The SMS/800 should finish sending any message that is in progress and disconnect the session. The SCP should receive the message but not attempt to send a response until a new session is established. The existing session should end. |
2.2.2 Test Case # 03 Connect/Disconnect Sequence – SCP Sends Good Night
Keyword |
Value |
Purpose |
Verify the SCP can initiate and terminate a connection immediately with SMS/800 according to the Connect/Disconnect Dialogue in SR-4959.
This should be the first TCP/IP test case performed because all other test cases depend on it being successful. The two systems may not be able to communicate if this initial interface is not working as required. |
Method |
Results |
1. SCP should send TCP Connect Request to SMS/800. |
The SMS/800 processes on each DCM should listen for socket connection requests and send back a TCP Connect Accept. SCP Node and SCP CMSDB connections should be established on each DCM. |
2. SCP should send Good Day message with zero(0) length desNodeName field. |
The SMS/800 should respond with Good Day message with both srcNodeName and desNodeName fields filled in. Both SCP and SMS/800 should be in data transfer phase. |
3. SMS/800 should send any application message. |
SCP should respond with response to the application message. |
4. SCP should send Good Night message to SMS/800. |
The Good Night should be immediately followed with a disconnect of the session. |
2.2.3 Test Case # 04 Connect/Disconnect Sequence – SMS/800 Sends Good Bye
Keyword |
Value |
Purpose |
Verify the SMS/800 can terminate a connection with SCP gracefully according to the Connect/Disconnect Dialogue in SR-4959. |
Method |
Results |
1. SCP should send TCP Connect Request to SMS/800. |
The SMS/800 processes on each DCM should listen for socket connection requests and send back a TCP Connect Accept. SCP Node and SCP CMSDB connections should be established on each DCM. |
2. SCP should send Good Day message with zero (0) length desNodeName field. |
The SMS/800 should respond with Good Day message with both srcNodeName and desNodeName fields filled in. Both SCP and SMS/800 should be in data transfer phase. |
3. SMS/800 should send any application message. |
SCP should respond with response to the application message. |
4. SMS/800 should send Good Bye message to SCP. |
The SCP should finish sending any message that is in progress and disconnect the session. The SMS/800 should receive the message and not attempt to send any response. The session should end. |
2.2.4 Test Case # 05 Connect/Disconnect Sequence – SMS/800 Sends Good Night
Keyword |
Value |
Purpose |
Verify the SMS/800 can terminate a connection immediately with the SCP according to the Connect/Disconnect Dialogue in SR-4959. When SCP tries to initiate a connection, SMS/800 sends a Good Night (GN) message to SCP. |
Method |
Result |
1. SCP should send TCP Connect Request to SMS/800. |
The SMS/800 processes on each DCM should listen for socket connection requests and send back a TCP Connect Accept. SCP Node and SCP CMSDB connections should be established on each DCM. |
2. SCP should send Good Day message with zero (0) length desNodeName field. |
The SMS/800 should respond with Good Day message with both srcNodeName and desNodeName fields filled in. Both SCP and SMS/800 should be in data transfer phase. |
3. SMS/800 should send any application message. |
SCP should respond with response to the application message. |
4. SMS/800 should send Good Night message to SCP. |
The Good Night should be immediately followed with a disconnect of the session. |
2.2.5 Test Case # 06 Connect/Disconnect Sequence – SMS/800 Sends Good Day
Keyword |
Value |
Purpose |
Verify the SMS/800 can send a Good Day message any time the connection is established. |
Method |
Results |
1. SCP should send TCP Connect Request to SMS/800. |
The SMS/800 processes on each DCM should listen for socket connection requests and send back a TCP Connect Accept. SCP Node and SCP CMSDB connections should be established on each DCM. |
2. SCP should send Good Day message with zero (0) length desNodeName field. |
The SMS/800 should respond with Good Day message with both srcNodeName and desNodeName fields filled in. Both SCP and SMS/800 should be in data transfer phase. |
3. SMS/800 should send any application message. |
SCP should respond with response to the application message. |
4. SMS/800 should send Good Day message to SCP with destNodeName null. |
The SCP should respond with a Good Day message with both srcNodeName and desNodeName fields filled in. |
2.2.6 Test Case # 07 DCM Failure
Keyword |
Value |
Purpose |
Verify the SCP can receive messages via one DCM if the other has failed. |
Method |
Results |
1. SCP should send TCP Connect Request to SMS/800. |
The SMS/800 processes on each DCM should listen for socket connection requests and send back a TCP Connect Accept. SCP Node and SCP CMSDB connections should be established on each DCM. |
2. SCP should send Good Day message with zero(0) length desNodeName field. |
The SMS/800 should respond with Good Day message with both srcNodeName and desNodeName fields filled in. Both SCP and SMS/800 should be in data transfer phase. |
3. SMS/800 should send application messages at a steady rate. |
The SCP should respond with responses to the application messages. Messages should be routed via either DCM. |
4. SMS/800 should disable one DCM. Client needs to connect to both SMS/800 servers. |
The SCP should continue to receive messages via the remaining DCM. |
5. SMS/800 should send application messages at a steady rate. |
The SCP should respond with responses to the application messages. Responses should go through the remaining DCM. |
2.2.7 Test Case # 08 Node Session Failure
Keyword |
Value |
Purpose |
Verify SMS/800 and the SCP can send/receive CMSDB messages if the Node TCP/IP sessions are not established.
When SCP NODE connection is down, verify CMSDB still can communicate between SMS/800 and SCP. |
Method |
Results |
1. SCP should send TCP Connect Request to SMS/800. |
The SMS/800 processes on each DCM should listen for socket connection requests and send back a TCP Connect Accept. SCP Node and SCP CMSDB connections should be established on each DCM. |
2. SCP should send Good Day message with zero(0) length desNodeName field. |
The SMS/800 should respond with Good Day message with both srcNodeName and desNodeName fields filled in. Both SCP and SMS/800 should be in data transfer phase. |
3. SMS/800 should send application messages at a steady rate. |
The SCP should respond with responses to the application messages. Messages should be routed via either DCM. |
4. The SCP should drop both of the Node TCP/IP sessions by sending Goodnight messages. |
The sessions established for Node message transfer should be disconnected. |
5. SMS/800 should send application messages at a steady rate. |
The SCP should respond with responses to the application messages. CMSDB application messages should not be affected by the disconnected Node sessions. |
6. SMS/800 should send several RTRV-ISA messages. |
All node messages should be queued until the node sessions are established. |
2.2.8 Test Case # 09 CMSD Session Failure
Keyword |
Value |
Purpose |
Verify SMS/800 and the SCP can send/receive NODE messages if the CMSD TCP/IP sessions are not established. |
Method |
Results |
1. SCP should send TCP Connect Request to SMS/800. |
The SMS/800 processes on each DCM should listen for socket connection requests and send back a TCP Connect Accept. SCP Node and SCP CMSDB connections should be established on each DCM. Verify when SCP CMSDB connection is down, NODE still can communicate between SMS/800 and SCP. |
2. SCP should send Good Day message with length zero (0) desNodeName field. |
The SMS/800 should respond with Good Day message with both srcNodeName and desNodeName fields filled in. Both SCP and SMS/800 should be in data transfer phase. |
3. SMS/800 should send application messages at a steady rate. |
The SCP should respond with responses to the application messages. Messages should be routed via either DCM. |
4. The SCP should drop both of the Cmsd TCP/IP sessions by sending Goodnight messages. |
The sessions established for CMSD message transfer should be disconnected. |
5. SMS/800 should send application messages at a steady rate. |
All CMSD messages should be queued until the CMSD sessions are established. |
6. SMS/800 should send several RTRV-ISA messages. |
The SCP should respond with RSP-ISA messages. All node messages should not be affected by the disconnected CMSD sessions. |
2.2.9 Test Case # 10 Normal SMS/800 Dequeuing to SCP
Keyword |
Value |
Purpose |
This test will verify the ability for the SCP to handle a large volume of message dequeuing from the SMS/800 to SCP. |
Method |
Results |
1. The SCP should send Good Night messages to each SMS/800 DCM for all applications. |
The sessions should be disconnected. |
2. SMS/800 will attempt to send UPD-UCR messages (1000) to the SCP. |
These messages will be queued by the SMS/800 since the sessions are not established. |
3. The SCP should establish a session and send Good Day message to each DCM. |
Two sessions should be established. All of the queued records will be transmitted to SCP. All of the queued records should be transmitted and responded to without error. |
2.3 NODE Messages
2.3.1 Test Case # 11 Retrieve Indicated Status Application (RTRV-ISA, RSP-ISA)
Keyword |
Value |
Purpose |
Upon receipt of a RTRV-ISA from SMS/800, SCP will send a RSP- ISA message with the requested application status and the MII field. The RSP-ISA message reports CMSDB or NODE current status DISABLE, INACTIVE, or ACTIVE.
This test should be repeated for each application status. |
Method |
Results |
1. SMS/800 will send a RTRV-ISA with TYPE = 255 message to SCP. |
SCP returns a RSP-ISA message with the requested NODE application status and the MII field. The TYPE should be 255. |
2. SMS/800 will send a RTRV-ISA with TYPE = 254 message to SCP. |
SCP returns a RSP-ISA message with the requested CMSDB application status and the MII field. The TYPE should be 254. |
2.3.2 Test Case # 12 Report Indicated Status Application (REPT-ISA)
Keyword |
Value |
Purpose |
SCP will send a REPT-ISA message when the status of the application is changed. The REPT-ISA message reports CMSDB or NODE current status DISABLE, INACTIVE, or ACTIVE.
This test case should be repeated for each application status. |
Method |
Results |
1. SCP should send REPT-ISA message with TYPE = 255, that indicates any status change. |
SMS/800 will receive a REPT-ISA message with the current NODE status. |
2. SCP should send REPT-ISA message with TYPE = 254, that indicates any status change. |
SMS/800 will receive a REPT-ISA message with the current CMSDB status. |
2.3.3 Test Case # 13 SCP Status Change
Keyword |
Value |
Purpose |
This test will verify that when the SCP informs SMS/800 that the SCP is disabled, then SMS/800 will queue all messages. When the status goes to active and there is “no overload”, SMS/800 dequeues the messages. |
Method |
Results |
1. SCP should send REPT-ISA message with status equal 00. |
SMS/800 will report SCP status changes to a designated printer and change the status in the DCM tables.
Note: This printout might not be testable unless there is a networked printer connected to SMS/800. |
2. SMS/800 should send 500 UPD- UCR messages. |
All messages will be queued at SMS/800. |
3. SCP should send REPT-ISA message with status equal 01. |
SMS/800 will report SCP status changes to a designated printer and change the status in the DCM tables. |
4. SCP should send REPT-ISA message with status equal 02. |
SMS/800 will report SCP status changes to a designated printer and change the status in the DCM tables. SMS/800 will dequeue 500 messages. |
2.3.4 Test Case # 14 SCP Overload Status Change
Keyword |
Value |
Purpose |
This test will verify that when the SCP informs SMS/800 that the SCP is in high overload, then SMS/800 will throttle all but critical messages. In addition, this test will verify that as the overload status goes to “low overload” and then to “no overload”, SMS/800 dequeues the appropriate messages.
The overload levels of an SCP and throttling of a message are as follows:
|
Method |
Results |
1. SMS/800 should send ENT-MCL. Precondition: The SCP is set to overload level 0. |
This message will be sent to the SCP. |
2. SCP should send REPT-ISA message with overload value equal to 00. |
SMS/800 will change the status in the DCM tables. |
3. SMS/800 should send: ENT-MCL. Precondition: The SCP is set to overload level 1. |
This message will be sent to the SCP. |
4. SCP should send REPT-ISA message with overload value equal to 01. |
SMS/800 will change the status in the DCM tables. |
5. SMS/800 should send: ENT-MCL. Precondition: The SCP is set to overload level 2. |
This message will be sent to the SCP. |
6. SCP should send REPT-ISA message with overload value equal to 02. |
SMS/800 will change the status in the DCM tables. |
7. SMS/800 should send: ENT-MCL |
The ENT-MCL message will be sent to the SCP. |
8. SCP should send REPT-ISA message with overload value greater than 02. |
SMS/800 will change the status in the DCM tables. |
9. SMS/800 should: ENT-MCL |
The ENT-MCL message will be sent to the SCP. |
2.4 CPR Data Maintenance
2.4.1 Test Case # 15 UPD-UCR with NPA Decision Node
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify the NPA decision node. |
Method |
Results |
1. SMS/800 will download to the SCP a UPD-UCR message that contains 3 Area Code decision nodes followed by an NXX node with 2 NXXs. |
The message should contain these FIELDS:
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. The SCP will query each of the 3 branches to verify the terminations number and CIC. |
In the SCP, queries to the number should return the appropriate termination and CIC information. |
2.4.2 Test Case # 16 UPD-UCR with LATA Decision Node
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify the LATA decision node. |
Method |
Results |
1. SMS/800 will create and store a Customer Record, which has 3 decision branches for 3 different LATAs. Each branch lists 1 or more LATAs.
SMS/800 will download UPD-UCR message to the SCP. |
The message should contain these FIELDS:
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. The SCP will query each of the 4 branches to verify the termination number and CIC. |
In the SCP, queries to the DIAL number should return the appropriate termination and CIC information. |
2.4.3 Test Case # 17 UPD-UCR with NXX Decision Node
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify the NXX decision node. The record built for this test case will be based on production type records with numerous NXXs. |
Method |
Results |
1. SMS/800 will download to the SCP a UPD-UCR message that contains 4 Area Code decision nodes followed by an NXX node with 3 NXXs. |
The message should contain these FIELDS:
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. The SCP will query random branches of the CPR. |
In the SCP queries to the number should return the appropriate termination and CIC information. |
2.4.4 Test Case # 18 UPD-UCR with NPA-NXX Decision Node
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify the NPA-NXX decision node. The record built for this test case will be based on production type records which numerous NXXs associated with several NPAs. |
Method |
Results |
1. SMS/800 will download to the SCP a UPD-UCR message that contains LATA nodes followed by NPA-NXX decision nodes. |
The message should contain these FIELDS:
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. The SCP will query random branches of the CPR. |
In the SCP, queries to the number should return the appropriate termination and CIC information. |
2.4.5 Test Case # 19 UPD-UCR with Ten-Digit Decision Node
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify the Ten-Digit decision node. For this record, queries originating from different 10- digit ANIs will route to different terminating numbers. |
Method |
Results |
1. SMS/800 will create and store a Customer Record, which has 10 decision branches for 10 different 10- digit numbers.
SMS/800 will download the record to the SCP with an UPD-UCR message. |
The message should contain these FIELDS:
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. The SCP should query each of the 10-digit decision nodes and the OTHER branch. |
In the SCP, queries to the number should return the appropriate termination and CIC information. |
2.4.6 Test Case # 20 UPD-UCR with TOD Decision Node and NST Time Zone
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify the Time of Day decision node. Newfoundland Standard Time will be used to create the time range values in the different decision nodes. |
Method |
Results |
1. SMS/800 will create and store a Customer Record, which has 4 decision branches for different time ranges. 6:00 A.M. NST to 12:00 P.M. will be one time range. 12:00 P.M. NST to 6:00 P.M. will be a second time range. 6:00 P.M. NST to 8:30 P.M. will be a third time range. An “OTHER” branch will be the fourth time range. SMS/800 will download the record to the SCP with an UPD-UCR message. |
The message should contain these FIELDS:
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. The SCP will then query each of the time of day decision nodes and the OTHER branch. |
In the SCP, queries to the number should return the appropriate termination and CIC information. |
2.4.7 Test Case # 21 UPD-UCR with DOW Decision Node and NDT Time Zone
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify the Day of Week (DOW) decision node. Newfoundland Daylight Time will be used to create the Day of Week transition, e.g. between Tuesday and Wednesday. |
Method |
Results |
1. SMS/800 will create and store a Customer Record, which has 3 decision branches for the seven days of the week: Monday will be a one day range, Tuesday through Thursday will be a range of days, and OTHER will account for Friday, Saturday, and Sunday. SMS/800 will download the record to the SCP with an UPD-UCR message. |
The message should contain these FIELDS:
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. The SCP will query each of the decision nodes and the OTHER branch. |
In the SCP, queries to the DIAL number should return the appropriate termination and CIC information. |
2.4.8 Test Case # 22 UPD-UCR with DOY Decision Node and EDT Time Zone
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify the Day of Year (DOY) decision node. Eastern Daylight Time will be used to create the Day of Year transition, e.g. between July 4th and July 5th. |
Method |
Results |
1. SMS/800 will create and store a Customer Record, which has 5 decision branches for the 366 days of the year: July 4th will be the first date (“186” because July 4th is the 186th day of the year), January 15th thru February 14th will be a second range (“015,045”); December 1st thru December 31st will be a third range; and May 1st, June 3rd, and August 20th will comprise a fourth decision node. OTHER will default for other days of the year.
SMS/800 will download the record to the SCP with an UPD-UCR message. |
The message should contain the following FIELDS:
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. The SCP will query each of the decision nodes and the OTHER branch. |
In the SCP, queries to the DIAL number should return the appropriate termination and CIC information. |
2.4.9 Test Case # 23 UPD-UCR with PCT Decision Node
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify the Percent (PCT) decision node. The percent decision node is used by the SCP to route a percentage of calls to different termination points. |
Method |
Results |
1. SMS/800 will create and store a Customer Record, which has 3 decision branches for with 40% of the calls going to 1 termination number, 40% of the calls going to a 2nd termination number, and 20% going to a 3rd termination number.
SMS/800 will download the record to the SCP with an UPD-UCR message. |
The message should contain the following FIELDS:
The SCP should respond with a successful “COMPLD” RSP-RCU message.
Note: This test case is not specifying how the UPD-UCR message will look, yet rather it is merely specifying what the values for each field should be. |
2. The SCP will query the number at least 10 times. |
In the SCP, queries to the number should return the appropriate termination and CIC information. In the SCP, queries to the number should result in approximately 40% routing to one termination number, 40% routing to a second termination number, and 20% routing to the third termination number. |
2.4.10 Test Case # 24 UPD-UCR with LSO Action Node
Keyword |
Value |
Purpose |
UPD-UCR with LSO Action Node: This UPD-UCR test case will verify the LSO action node. |
Method |
Results |
1. Create record with BA AOS. SMS/800 will create and store a Customer Record, which has 3 decision branches with 40% of the calls going to 1 termination number, 40% of the calls going to a 2nd termination number, and 20% going to a 3rd. termination number. The destination number on the first branch will contain a POTs number which has a Foreign Serving Office (FSO) of 201555 entered on the CAD.
SMS/800 will download the record to the SCP with an UPD-UCR message. |
The message should contain the following FIELDS:
The fields NPA and NXX are the values of the LSO for the TEL Node that is not Turnaround if FSO is filled.
The SCP should respond with a successful “COMPLD” RSP-RCU message.
Note: This test case is not specifying how the UPD-UCR message will look, yet rather it is merely specifying what the values for each field should be. |
2.4.11 Test Case # 25 UPD-UCR with TEL Action Node
Keyword |
Value |
Purpose |
UPD-UCR with TEL Action Node: This UPD-UCR test case will verify the TEL action node. |
Preconditions |
|
Method |
Results |
1. Create record with BA AOS. SMS/800 will build a record using the LATA, CAR and TEL nodes. The value for one of the TEL nodes will be the DIAL# for a turnaround.
SMS/800 will download the record to the SCP with an UPD-UCR message. |
The message should contain the following FIELDS:
The fields NPA NXX and LINE are the values of the POTS number for the TEL Node that is not a Turnaround.
For the branch that uses a turnaround only NET & CAR fields should appear.
There will be no TEL Node.
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2.4.12 Test Case # 26 UPD-UCR with TEMPLATE Action Node
Keyword |
Value |
Purpose |
UPD-UCR with TEMPLATE Action Node: This UPD-UCR test case will verify the TEMPLATE action node. |
Preconditions |
|
Method |
Results |
1. Create record with XC AOS. SMS/800 will build a record using the LATA, CAR and TEL nodes. The value for one of the TEL nodes will be the DIAL# for a turnaround. SMS/800 will download the record to the SCP with an UPD-UCR message. |
The SCP should respond with a successful “COMPLD” RSP-RCU message for each. |
2. Create 50 Pointer Records that point to the Template. |
The message should contain FIELDS:
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2.4.13 Test Case # 27 UPD-UCR with TEMPLATE Action Node
Keyword |
Value |
Purpose |
UPD-UCR with TEMPLATE Action Node: This UPD-UCR test case will verify the TEMPLATE action node. |
Preconditions |
|
Method |
Results |
1. Create 20 Template Records containing various decision nodes and download to SCP. The records should contain the same nodes as the records created for test cases # 15 – 24. |
The SCP should respond to each with a successful “COMPLD” RSP-RCU message. |
2. Send numerous Pointer Records which use each Template created. |
The SCP should respond to each with a successful “COMPLD” RSP-RCU message. |
2.4.14 Test Case # 28 UPD-UCR with TEMPLATE Action Node
Keyword |
Value |
Purpose |
Test UPD-UCR action code D for Template. UPD- UCR with TEMPLATE Action Node. Verify error if Template Node is missing. |
Preconditions |
Previously created Template Record is removed from ISCP database.
Somos should ask the SCP owner/operator to delete a specific existing Active Template ID from the test SCP, however, SMS/800 needs to keep that Template in the SMS/800 database for this test. Then the tester creates a Pointer record to point to this Template in SMS/800 and download it to the SCP. The Pointer’s UPD-UCR should be sent to SCP because the Template is Active in SMS/800 but no longer exists in the SCP, the SCP should return error 08 saying the Template is not found in the SCP. |
Method |
Results |
1. Disconnect an Active Template Record that all Pointer Records were already disconnected. |
The delete CMSDB record (ACD=D) should be sent to SCP. SCP Owner/Operator should verify the Template Record is removed from SCP Database. |
2. Send Pointer Record which points to the Template Record that has been removed from the SCP Database. |
The SCP should respond to with a denied “DENIED, 08” RSP-RCU message. |
2.4.15 Test Case # 29 UPD-UCR with Switch Node in First Position
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify that a record using a ‘Switch’ node in the first node position can be created in SMS/800 and downloaded to the SCP.
This test case has Switch Off. |
Method |
Results |
1. SMS/800 will build a record using the Switch, LATA, State, Carrier, Tel# and Announcement nodes where switch is the first node and OFF is the first position. |
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. In the SCP, queries will be made to traverse each decision branch. |
Appropriate termination and CIC information should be returned.
Note: The tester should keep in mind there is no Switch Node in the UPD-UCR. The switch node in SMS/800 simply determines which rows are sent to the SCPs. |
2.4.16 Test Case # 30 UPD-UCR with Switch Node in First Position
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify that a record using a switch node in the first node position can be created in SMS/800 and downloaded to the SCP.
This test case has Switch On. |
Method |
Results |
1. SMS/800 will build a record using the Switch, LATA, State, Carrier, Tel# and Announcement nodes where switch is the first node and ON is the first position. |
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. In the SCP, queries will be made to traverse each decision branch. |
Appropriate termination and CIC information should be returned. |
2.4.17 Test Case # 31 UPD-UCR with AOS Change
Keyword |
Value |
Purpose |
Verify that an AOS change will send a delete message to the test SCP and that a following resend will not change the delete. |
Method |
Results |
1. Create record with XC AOS. SMS/ 800 will build a record using the LATA, CAR and TEL nodes. The value for one of the TEL nodes will be the DIAL# for a turnaround. SMS/800 will download the record to the test SCP with an UPD-UCR message. |
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. Change the AOS for the record so that the test SCP is no longer part of the AOS. |
A delete message should be sent to the test SCP and the record should be removed from its database. |
3. Do a batch resend to the test SCP that includes the record with the AOS change. Make the resend data file contain the effective date/time of the record before the AOS change. |
No updates should be sent to the test SCP. |
2.4.18 Test Case # 32 UPD-UCR with a Combination of Decision Nodes
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify that a record using a combination of Decision Nodes can be created in SMS/800 and downloaded to the SCP. |
Method |
Results |
1. SMS/800 will build a record using the NPA, LATA, NXX, TOD, DOW, DOY, and PCT decision nodes. |
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. Build a Template Record using the NPA, LATA, NXX, TOD, DOW, DOY, and PCT decision nodes. Send Pointer Records that use the Template. |
The SCP should respond with a successful “COMPLD” RSP-RCU for each message. |
3. In the SCP, queries will be made to traverse each decision branch. |
Appropriate termination and CIC information should be returned. |
2.4.19 Test Case # 33 UPD-UCR with Large CPR
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify that large CPRs can be created in SMS/800 and downloaded to the SCP. |
Method |
Results |
1. SMS/800 will build a record with large CPR (size > 32k bytes) |
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. In the SCP, queries will be made to traverse each decision branch. |
Appropriate termination and CIC information should be returned. |
2.4.20 Test Case # 34 UPD-UCR with Maximum CPR
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify that large CPRs can be created in SMS/800 and downloaded to the SCP. |
Method |
Results |
1. SMS/800 will build a record with a CPR that is between 160K and 170K in size. |
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. In the SCP, queries will be made to traverse each decision branch. |
Appropriate termination and CIC information should be returned. |
2.4.21 Test Case # 35 UPD-UCR with maximum NPA branches
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify that large CPRs can be created in SMS/800 and downloaded to the SCP. |
Method |
Results |
1. SMS/800 will build a record with 1000 NPA Decision nodes (while under maximum size of 170K). |
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. In the SCP, queries will be made to traverse each decision branch. |
Appropriate termination and CIC information should be returned. |
2.4.22 Test Case # 36 UDP-UCR with maximum Branches (other than NPA)
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify that large CPRs can be created in SMS/800 and downloaded to the SCP. |
Method |
Results |
1. SMS/800 will build a record with 255 Decision nodes other than NPA (while under maximum size of 170K). |
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. In the SCP, queries will be made to traverse each decision branch. |
Appropriate termination and CIC information should be returned. |
2.4.23 Test Case # 37 UPD-UCR Messages for Disconnect of Complex CPR
Keyword |
Value |
Purpose |
This UPD-UCR test case will verify that a complex record can be disconnected in SMS/800 and downloaded to the SCP.
The Disconnect record’s Effective Date should be set to “NOW”. This test case is to Disconnect the CR with Effective Date of “NOW” and End Intercept Date of the next day. This test case is to verify the SCP verifies the CR still exists on their side even after they received UPD-UCR for a disconnected CR with date of NOW. SMS/800 sends a delete message on the End Intercept Day which is the next day in this test case. The CR should be deleted by the SCP on their side when they receive the delete message from SMS/800 the next day. |
Method |
Results |
1. SMS/800 will build a record using the NPA, LATA, NXX, TOD, DOW, DOY, and PCT decision nodes. |
The SCP should respond with a successful “COMPLD” RSP-RCU message. |
2. The complex record should be disconnected with the end intercept date set for the next day. |
The message should be accepted. A delete message should be sent on the day of the end intercept and the record should be removed from the NDB. |
2.4.23 Test Case # 38 SCP Incremental Load
Keyword |
Value |
Purpose |
Verify SCP Incremental Load Process |
Method |
Results |
1. Run ZMAP205 for SCP. |
Jobs ZMAP205(0-9) will complete with a condition code of 0.
Verify that all test records are found in the load files. Verify that every record in the load file contains a Sequence Number and More Data Flag. |
2. Run ZMUP995X for SCP. |
Job ZMUP995X should complete with a condition code of 0. Records from every NXX should be written to file(s). Records >32K bytes should be segmented correctly on the file. |
3. Send file to SCP for processing. |
File should be processed correctly by SCP. SCP should send response file to SMS/800. |
4. Run ZMAP206X with response file received from SCP. |
Job ZMAP206 should complete with a condition code of 0. |
2.4.24 Test Case # 39 AUD-CPR Audit match
Keyword |
Value |
Purpose |
This AUD-CPR test case will verify that a Customer Record in SMS/800 and the SCP, which are consistent, will indicate a match when SMS/800 audits the SCP. |
Method |
Results |
1. SMS/800 should audit a regular Customer Record created in a previous test case by sending an AUD-CPR message to the SCP. |
SCP should respond with a successful “COMPLD” RSP-AUD message. |
2. Audit large Customer Record or Template where its AUD-CPR size > 160K bytes. Refer to Test Case 34 for the CR size is > 160K bytes. |
SCP should respond with a successful “COMPLD” RSP-AUD message. (One of the SCP vendor had a bug on large Templates, fixed in Feb 2016) |
3. SMS/800 should audit a Template Record created in a previous test case by sending an AUD-CPR message to the SCP. |
SCP should respond with a successful “COMPLD” RSP-AUD message. |
4. SMS/800 should audit a Pointer Record created in a previous test case by sending an AUD-CPR message to the SCP. |
SCP should respond with a successful “COMPLD” RSP-AUD message. |
2.4.25 Test Case # 40 AUD-CPR Inconsistent CPRs
Keyword |
Value |
Purpose |
This AUD-CPR test case will verify that a Customer Record in SMS/800 and the SCP that have the same effective date but inconsistent CPRs will return an error code of ‘11’ when audited.
This test case uses an existing CR that was created before this test is run. That means the SCP already has this UPD-UCR before this test starts. The SCP tester needs to do a destructive action on their end in step1. The purpose is to test error code 11. |
Method |
Results |
1. SCP should replace the record created through SMS/800 with a slightly different CPR but the same effective date. |
Changes in the CPR should be in the CMSDB. |
2. SMS/800 should audit the record by sending an AUD-CPR message to the SCP. |
SCP should respond with a “DENIED” RSP-AUD message with an error code of 11. |
2.4.26 Test Case # 41 AUD-CPR - Record not found
Keyword |
Value |
Purpose |
This AUD-CPR test case will verify that a Customer Record in SMS/800 that is not found in the SCP will return an error code of “02” when audited. |
Method |
Results |
1. SMS/800 will audit a Customer record that is not in the SCP. |
The SCP should respond with a “DENIED” RSP-AUD message with an error code of “02”. |
2.4.27 Test Case # 42 AUD-CPR - Inconsistent Effective Date
Keyword |
Value |
Purpose |
This AUD-CPR test case will verify that a Customer Record in SMS/800 that has inconsistent effective date with the same record in the SCP will return an error code of “99” when audited. |
Method |
Results |
1. The SCP should replace the record previously audited by one having a different effective date. |
The effective date should be changed in CMSDB. |
2. SMS/800 should audit the record by sending an AUD-CPR message to the SCP. |
The SCP should respond with a “DENIED” RSP-AUD message. The RSP-AUD message should have an error code of “99”
|
2.4.28 Test Case # 43 UPD-ROR message
Keyword |
Value |
Purpose |
SCP must accept UPD-ROR messages. The correct ROR data must be echoed back to SMS/800 in the RSP-ROR message. RESP ORGS will be stored in the CMSDB data base. |
Method |
Results |
Retrieve an existing Customer Record in SMS/800. Copy forward that Customer Record to “Now” and change the RESP ORG to generate a UPD- ROR message. |
Valid RSP-ROR messages should be generated for the UPD-ROR messages. Both UPD-ROR and UPD-UCR are sent for this TFN at the same time (milliseconds apart). SCP should be able to handle this scenario. Make sure there is no racing condition when updating the SCP database. |
2.4.29 Test Case # 44 Reverse Audit with SCP
Keyword |
Value |
Purpose |
The reverse audit file is used to verify that the SCPs CMSDB database matches the SMS/800 database. SMS/800 then resolves discrepancies. |
Method |
Results |
1. SCP should generate a reverse audit file and send the file to SMS/800. |
The Reverse Audit runs should finish to completion. Output should be consistent with the interface specification. SMS/800 should identify the appropriate discrepancies. For records existing in SMS/800 but not in the SCP, or for records with more recent effective dates in SMS/800 that the SCP, updates should automatically be scheduled to the SCP. |
2.4.31 Test Case # 45 Execution Error (REPT-EER)
Keyword |
Value |
Purpose |
The SCP will send an unsolicited message to the SMS/800 when it detects an CPR Execution Error. |
Method |
Results |
1. The SCP sends a REPT-EER message to SMS/800 by creating a Call Processing Record (CPR) execution error. |
SMS/800 will generate and print an Exception Report immediately, illustrating the error. |
2. Create an error condition by sending Pointer Record which points to a missing Template Record. |
SMS/800 will generate and print an Exception Report immediately, illustrating the error. The error should be 08. |
2.4.32 Test Case # 46 Report Misrouted Error (REPT-MER)
Keyword |
Value |
Purpose |
The REPT-MER message is generated by CMSDB if it receives a query for a number which is not 800 or an 800 number not in the range defined by the Master Number List. |
Method |
Results |
1. The SCP should send a REPT- MER message to SMS/800. |
The exception report will be verified to ensure that it agrees with the transmitted message from the SCP. |
2.5 Administrative Data Maintenance
2.5.1 Test Case # 47 Update Master Number List for Multiple NPAs (UPD-MNL)
Keyword |
Value |
Purpose |
The CMSDB requires a master number list of “800 Service” NPA- NXXs to distinguish between queries to vacant codes and misroutes by the CCS network.
This test case will verify that SMS/800 can generate the UPD-MNL message for the 800 or 888 or 877 or any other NPA and that the SCP will respond, store the data and route queries correctly based on the specific NXX values. |
Method |
Results |
1. SMS/800 will generate an UPD- MNL message for the 800 or 888 or 877 NPA with the following changes:
|
The SCP should generate a RSP-MNL with a status of “COMPLD” to the UPD-MNL message and return valid announcement nodes and call routing information to the queries.
|
2.5.2 Test Case # 48 Retrieve Master Number List (RTRV-MNL)
Keyword |
Value |
Purpose |
The RTRV-MNL message is used by SMS/800 to verify consistency between the SMS/800 NXX Screen and the SCP Master Number List. |
Method |
Results |
1. SMS/800 will generate a RTRV- MNL message. |
The SCP should respond with successful RSP-RML message (status = COMPLD) to all RTRV-MNL messages. Reports should be successfully generated by SMS/800. Report should show no discrepancies. |
2. After one successful RTRV- MNL, the SCP will modify the Master Number List. |
The Master Number List in the SCP should not be the same as the one in SMS/800. |
3. SMS/800 will generate a second RTRV-MNL message. |
Reports should be successfully generated by SMS/800. Report should show the discrepancies caused by the modification to the Master Number List. |
2.5.3 Test Case # 49 Carry a Null NPA Master Number List (UPD-MNL)
Keyword |
Value |
Purpose |
The UPD-MNL message can carry a “NULL” NPA Master Number List to a SCP.
The tester can use the SCP NPA-NXX List Audit report to generate the RTRV-MNL message. |
Method |
Results |
1. SMS/800 will generate a “NULL” UPD-MNL message and send it to the SCP. |
The SCP should respond with successful RSP-MNL (status = COMPLD) to the UPD-MNL message. The NXX and TA value are removed from the NXX list.
Result is a null Master Number List. |
2.5.4 Test Case # 50 Retrieve Noncustomer Data (RTRV-NCD)
Keyword |
Value |
Purpose |
SMS/800 sends this command to retrieve the values for various parameters at a particular SCP. Those values will then be compared to the same values as set in SMS/800.
The values to be compared are: Execution Errors Report Limit and Misrouted Queries Report Limit. |
Method |
Results |
1. The request to retrieve non- customer data message (RTRV-NCD) will be transmitted by SMS/800 to the SCP. |
The SCP will respond back to the SMS/800 with the RSP-NCD message which contains the non-customer data which will be used to generate the selected report. The values in the report will be compared to the values generated for each parameter in previous test cases. |
2.5.5 Test Case # 51 Update Application Layers Parameters (UPD-ALP)
Keyword |
Value |
Purpose |
The CMSDB requires an exception report threshold for the misrouted queries and the application/customer sample over- flow threshold. This message is used to update these thresholds. For the threshold value of n, CMSDB only sends the first n exception reports in a 5 minute period. The PRL screen can be accessed to establish MISROUTED ERROR and LOW SAMPLE SPACE exception report limits. |
Method |
Results |
1. SMS/800 should access the PRL screen and enter new values (1 - 100) for MISROUTED ERROR and LOW SAMPLE SPACE for the target SCP. The UPD-ALP message will be sent to the SCP. |
SCP will respond with a RSP-ALP message containing the ‘completed’ condition code. The MISROUTED ERROR exception report limits sent by SMS/800 should agree with the values stored at the SCP. The LOW SAMPLE SPACE exception report limits sent by SMS/800 should agree with the values stored at the SCP. The SCP will verify the updates to CMSDB. |
2.5.6 Test Case # 52 Update Exception Threshold Table (UPD-ETT)
Keyword |
Value |
Purpose |
The CMSDB requires an exception report threshold to control the generation of excessive Report Execution Error (REPT-EER) reports. For the threshold value of n, CMSDB only reports the first n exception events in a 5 minute period. The PRL screen can be accessed to establish EXECUTION ERROR exception report limits. |
Method |
Results |
1. The PRL screen will be accessed and new value (1 - 100) for EXECUTION ERROR will be entered for the target SCP. The UPD- ETT message will be sent to the SCP. |
SCP will respond with a RSP-ETT message containing the ‘completed’ condition code. The EXECUTION Error exception report limits sent by SMS/800 should agree with the values stored at the SCP. The SCP will verify the updates to CMSDB. |
2.6 Special Studies
2.6.1 Test Case # 53 Special Studies (ENT-SSL, DLT-SSL)
Keyword |
Value |
Purpose |
A special study is a temporary call monitor at the SCP that produces exception reports for calls that meet specified trap criteria. A command message is sent to ENTER or DELETE an entry on a special study list at the SCP. SMS/800 sets up Special Studies for each of the 6 trap criteria: 10-digit (POTS#, DIAL#), 6-digit (POTS#, DIAL#), Carrier or SSP by sending ENT-SSL message. This is a request to SCP to collect special study data based on the trap criteria. The following error codes will also be tested: • 02 - list full (add) (max 10 entries) • 03 - entry not found (delete) • 04 - entry already on list (add) |
Method |
Results |
1. SMS/800 will send ENT-SSL message (while delete a special study will send DLT-SSL) to SCP for each of the trap criteria. |
After the SCP verifies the ENT-SSL or DLT-SSL messages, the response RSP-SSL should be transmitted back to SMS/800. The SCP will verify the addition and deletion of special studies. |
2. After receiving the message, SCP sets up and calls will be placed to the DIAL# under study to meet the specified trap criteria. |
The actual special studies data will be transmitted by the SCP in REPT-SSR message to SMS/800. REPT-SSR messages are generated every 15 minutes while a special study is in progress. |
3. SMS/800 will send ENT-SSL messages until the Special Studies List is full. |
The SCP will verify the addition and deletion of special studies. The denied RSP-SSL should be transmitted back to SMS/800 with the error code = 02. |
4. SMS/800 will send DLT-SSL message for a trap criteria that has been deleted by the SCP. |
The denied RSP-SSL should be transmitted back to SMS/800 with the error code = 03. |
5. SMS/800 will send ENT-SSL message with same trap criteria as a previous message. |
The denied RSP-SSL should be transmitted back to SMS/800 with the error code = 04. |
2.6.2 Test Case # 54 Report Special Studies Results (REPT-SSR)
Keyword |
Value |
Purpose |
If there are any Special Studies in effect, the SCP is scheduled to send an SSR message every 15 minutes to report on all trapped calls (for all active special studies) that have not yet been reported in an earlier message.
The SCP also sends an unsolicited SSR message when a special study completes (because either the trap limit or time limit has been reached) to report on all trapped calls for that special study that have not yet been reported in an earlier SSR message.
When a special study completes the report will contain data for the special study that completed as well as all other active special studies.
More than one SSR message is sent if all the data to be reported cannot be contained in one message.
Note: The SCP(s), not SMS/800, sends the REPT message to SMS/800. |
Method |
Results |
1. SMS/800 will initiate a special study by sending the ENT-SSL message. |
For the case when the special study is interrupted and completes before the process is up, a REPT-SSR message with no data and status code of 5, 6 or 7 will be sent to SMS/800. |
2. SCP should generate calls against the trap criteria. |
Data for the trap criteria should be accumulated. |
3. SCP should send SSR message with status code = 4. |
For the case when the study is interrupted and completes a REPT- SSR message with no data and status code of 4 will be sent to SMS/800. |
4. SCP should send SSR message with status code = 5, 6 or 7. |
For the case when the special study is interrupted and completes before the process is up, a REPT-SSR message with no data and status code of 5, 6 or 7 will be sent to SMS/800. |
2.7 Network Management
2.7.1 Test Case # 55 Enter/Delete Manual Controls (ENT-MCL, DLT-MCL)
Keyword |
Value |
Purpose |
Manual controls by the SMS/800 will be accepted by an SCP network management process. The following error codes should also be tested: • 02 - list full (max 64 entries) • 03 - entry not found (delete) • 04 - entry already on list (add) |
Method |
Results |
1. SMS/800 sends ENT-MCL to add numbers (10) to the Manual Control List. |
SCP should send RSP-MCL message to SMS/800 to verify each number has been added. |
2. SCP should place calls against each number placed on the Manual Control List. |
SCP should send unsolicited REPT_SDR message to SMS/800 every 2.5 minutes, while the number is under manual control. |
3. SMS/800 sends DLT-MCL to delete each number from the Manual Control List. |
SCP should send RSP-MCL message to SMS/800 to verify each number has been deleted. After a number has been deleted from the manual control list, a final REPT-SDR message should contain only date and time data. This message will contain a list of numbers on the Manual Controls List. |
4. SMS/800 sends DLT-MCL to delete a specific number (already deleted in CMSDB) from the Manual Control List. |
SCP should send denied RSP-MCL message to SMS/800 with error code = 03. |
5. SMS/800 sends ENT-MCL to add numbers (65) to the Manual Control List. |
SCP should send RSP-MCL message to SMS/800 to verify each number has been added. On the attempt to add number 65, SCP should send denied RSP- MCL message to SMS/800 with error code = 02. |
6. SMS/800 sends ENT-MCL to add a specific number that has previously been added. |
SCP should send denied RSP-MCL message to SMS/800 with error code = 04. |
2.7.2 Test Case # 56 Update Call Completion Option (UPD-CCO)
Keyword |
Value |
Purpose |
This Call Completion Option(CCO) is part of the network management option. It can be activated by the SMS/800. If CCO is in effect (i.e. ‘ON’), the call processing will include a termination message request in the TCAP response to the SSP. This will cause the SSP to return call completion data for each number on either a mass calling surveillance list or control list in the form of a Termination Message to the SCP. |
Method |
Results |
1. SMS/800 sends the UPD-CCO to turn the Call Completion Collection ‘ON’ at the selected SCP. |
The SCP will transmit a response, RSP-CCO, to the SMS/800. The call completion data back to SMS/800 using REPT-SDR messages. |
2. SMS/800 sends another UPD- CCO message to turn it ‘OFF’. |
The SCP will transmit a response, RSP-CCO, to the SMS/800. |
3. The SCP will generate calls for both CCO=’ON’ and CCO=’OFF’ cases and send the call completion data back to SMS/800 using REPT- SDR messages. |
The SCP will transmit a REPT-SDR message to the SMS/800. |
2.7.3 Test Case # 57 Update Network Management Parameters (UPD-NMP)
Keyword |
Value |
Purpose |
SMS/800 must be able to change the threshold for the non-purchased area or LATA of service for detecting excessive calling to a dialed NPA-NXX and a dialed NPA-XXX-XXX within a NPA-NXX. In addition, SMS/800 must be able to change a decontrol threshold for removing non-purchased code controls.
SMS/800 must be able to change the thresholds for detecting excessive calling to vacant dialed NPA-NXX codes, and vacant dialed NPA-XXX-XXX lines within a non-vacant dialed NPA-NXX code. In addition, SMS/800 must be able to change a decontrol threshold for removing controls on vacant codes.
The CMSDB requires an exception report threshold list to control the generation of exception reports: Network List Change Report (NLC) and Network SSP Overflow Report (NSO). For each type of exception event, the list indicates the report’s threshold value, N.
The CMSDB reports only the first N exception events in a 5-minute period. |
Method |
Results |
1. SMS/800 sends the UPD-NMP message which contains the Excessive Calling Control Parameters. |
The SCP should respond back to SMS/800 with a RSP- NMP message. It should also verify the updates to the CMSDB. |
2. SMS/800 then sends the UPD- NMP message which contains Network Management Report Limits. |
The SCP should respond back to SMS/800 with a RSP- NMP message. It should also verify the updates to the CMSDB. |
2.7.4 Test Case # 58 Update Destination Threshold Table (UPD-DTT)
Keyword |
Value |
Purpose |
To control mass calling to destination numbers, SMS/800 must be able to change the assignment of a surveillance threshold (attempts/destination/150 sec.) for detecting focused overloads, and a control threshold for initiating controls to each of 15 threshold level classes in the CMSDB. Also SMS/800 can supply CMSDB with the initial gap interval level value for mass calling to be used for the first 150 seconds period that a code is on the destination number control list. The initial value is identical for all destination codes. |
Method |
Results |
1. SMS/800 will send an UPD-DTT message to the SCP. |
The SCP will verify the message sent by SMS/800 and respond with a RSP-DTT message containing the ‘completed’ condition code. The SCP will verify the update to CMSDB. |
2. Change values for Surveillance and control thresholds to be between 5001 and 20,000. |
The SCP will verify the message sent by SMS/800 and respond with a RSP-DTT message containing the ‘completed’ condition code. The SCP will verify the update to CMSDB. |
2.7.5 Test Case # 59 Report Network List Change (REPT-NLC)
Keyword |
Value |
Purpose |
This exception report is generated by the SCP when a code is automatically added or removed from surveillance or control, or when a code cannot be added to a CMSDB control list (overflow). |
Method |
Results |
1. SCP should send calls to a destination number that is assigned that NM Class such that the surveillance threshold is exceeded in a 2.5 minute period. |
A REPT-NLC message is sent to SMS/800 with a successful status (TYPE = S, STATUS = 0).
The number is added to the Surveillance List |
2. SCP should send calls to a destination number that is assigned that NM Class such that the surveillance threshold is exceeded in a 2.5 minute period. |
A REPT-NLC message is sent to SMS/800 with a successful status (TYPE = O, STATUS = 0).
The number is added to the Surveillance List. |
3. SCP should repeat until list is full and then add 1 more. |
A REPT-NLC message is sent to SMS/800 with an overflow status (TYPE = O, STATUS = 2). |
4. SCP should stop sending calls to the destination number on the list. |
A REPT-NLC message is sent to SMS/800 with a successful status (TYPE = O, STATUS = 1). The number is deleted from the Surveillance List. |
5. SCP should send calls to a destination number that is assigned that NM Class such that the surveillance and control thresholds are exceeded in a 2.5 minute period. |
A REPT-NLC message (TYPE = M, STATUS = 0) will be sent to SMS/800. The number will be deleted from the Surveillance List and then added to the Destination Control List. |
6. SCP should generate calls to a vacant NXX such that the total number of calls exceed the VAC- NXX control threshold in a 5 minute period |
A REPT-NLC message is sent to SMS/800 with a successful status (TYPE =V, STATUS = 0). The number is added to the Surveillance List. |
2.7.6 Test Case # 60 Report Network SSP Overflow (REPT-NSO)
Keyword |
Value |
Purpose |
CMSDB generates the REPT-NSO when an SSP cannot activate an automatic control because the SSP’S control list is full. The termination message is requested only when the call completion option (CCO) is set. |
Method |
Results |
1. SMS/800 should place a number on the Manual Control List (ENT- MCL) and the CCO (UPD-COO) should be set to “on”. |
The number should be on a control list in the SCP. |
2. The SCP should place calls against the number. SCP CMSDB sends a REPT-NSO message to SMS/800. |
The message format and content will be checked for correctness. |
2.7.7 Test Case # 61 Report Scheduled Destination Results (REPT-SDR)
Keyword |
Value |
Purpose |
REPT-SDR is a scheduled report generated every 2.5 minutes during which a dialed number or destination number is under control or surveillance. The report contains the number’s mass control calling control level, the destination attempt count and the destination percent failure rate. A maximum of 128 numbers can be under surveillance with auto control on, 128 numbers can be under surveillance with auto control off, 64 under manual control and 64 under automatic control. |
Method |
Results |
1. The SCP should add a number to the destination control list or surveillance list. |
A REPT-SDR is sent to SMS/800 every 2.5 minutes while the number is under control or surveillance. The message format and content will be checked for correctness. |
2. After 10 minutes, the SCP should delete the number from the list. |
After the number is deleted from the list, the last REPT- SDR message sent to SMS/800 should only contain date and time. |
2.8 Status and Control
2.8.1 Test Case # 62 Tell CMSDB Update Complete (TELL-CUC)
Keyword |
Value |
Purpose |
CMSDB Update Complete message is used by the SMS/800 to notify the SCP CMSDB Application that all the queued messages (if any) have already been sent. SMS/800 will start to empty its queued messages for the CMSDB whenever the CMSDB application is ready to receive messages. |
Method |
Results |
1. SCP should send GNT message to SMS/800. SCP should disable their auto-reconnect for this test case if any auto-reconnect was a built-in. |
SMS/800 should update its DCM status tables. |
2. SMS/800 should send UPD-UCR messages to the SCP. |
SMS/800’s DCM should queue all of the messages. |
3. SCP should send GM1 message to SMS/800. |
SMS/800 should respond with GM2 and start dequeuing the UPD- UCR messages. When all messages have been dequeued, SMS/800 should send a TELL-CUC to the SCP. |
2.8.2 Test Case # 63 Tell SMS/800 to Resend Updates (TELL-SRU)
Keyword |
Value |
Purpose |
This message is issued by CMSDB following data base recovery and update suspension periods to notify the SMS/800 to start resending all queued messages that have not been responded to by the SCP. |
Method |
Results |
1. SMS/800 should queue 100 UPD-UCR messages. |
SMS/800 DCM should queue 100 messages. |
2. SCP should send TELL-SRU message to SMS/800. |
SMS/800 should respond with a RSP-SRU and start dequeuing messages. |
2.9 Volume Tests
Volume, measured by number of messages a minute, will be simulated by queueing numbers of messages and dequeuing them all at once. UPD-UCR messages will be used. Test cases will vary only in quantity and message sizes.
2.9.1 Test Case # 64 Volume - 12K Simple Records
Keyword |
Value |
Purpose |
CMSDB should process 1200 commands from SMS/800 a minute. Most UPD-UCR messages are simple Customer Records and average about 400 bytes each. |
Method |
Results |
1. The SCP should send REPT-ISA to disable SCP CMSDB. |
SMS/800 should queue all messages until SCP CMSDB is active. |
2. SMS/800 should send 12,000 UPD-UCR messages averaging about 400 bytes each. |
All messages should be queued by SMS/800’s DCM. |
3. The SCP should send REPT-ISA to enable SCP CMSDB. |
All messages should dequeue to the SCP. Responses should be received for each command. Dequeuing should complete in approximately 10 minutes. |
2.9.2 Test Case # 65 Volume - 60K Simple Records
Keyword |
Value |
Purpose |
SCP CMSDB should process 1200 commands from SMS/800 a minute. Most UPD-UCR messages are Simple Customer Records and average about 400 bytes each. |
Method |
Results |
1. The SCP should send REPT-ISA to disable SCP CMSDB. |
SMS/800 should queue all messages until SCP CMSDB is active. |
2. SMS/800 should send 60,000 UPD-UCR messages averaging about 400 bytes each. |
All messages should be queued by SMS/800’s DCM. |
3. The SCP should send REPT-ISA to enable SCP CMSDB. |
All messages should dequeue to the SCP. Responses should be received for each command. Dequeuing should complete in approximately 60 minutes. |
2.9.3 Test Case # 66 Volume - 6K Complex Records
Keyword |
Value |
Purpose |
SCP CMSDB should process 1200 commands from SMS/800 a minute. UPD-UCR messages are complex records averaging 1200 bytes each. |
Method |
Results |
1. The SCP should send REPT-ISA to disable SCP CMSDB. |
SMS/800 should queue all messages until SCP CMSDB is active. |
2. SMS/800 should send 6,000 UPD-UCR messages averaging about 1200 bytes each. |
All messages should be queued by SMS/800’s DCM. |
3. The SCP should send REPT-ISA to enable SCP CMSDB. |
All messages should dequeue to the SCP. Responses should be received for each command. Dequeuing should complete in approximately 10 minutes. |
2.9.4 Test Case # 67 Volume - 50K Complex and Simple Records
Keyword |
Value |
Purpose |
SCP CMSDB should process 1200 commands from SMS/800 a minute. UPD-UCR messages are complex records averaging 4200 bytes each and simple records averaging 400 bytes each. |
Method |
Results |
1. The SCP should send REPT-ISA to disable SCP CMSDB. |
SMS/800 should queue all messages until SCP CMSDB is active. |
2. SMS/800 should send 50,000 UPD-UCR messages ranging from 400 bytes to 4200 bytes each. The average message length is 2300 bytes. |
All messages should be queued by SMS/800’s DCM. |
3. The SCP should send REPT-ISA to enable SCP CMSDB. |
All messages should dequeue to the SCP. Responses should be received for each command. Dequeuing should complete in approximately 45 minutes. |
2.9.5 Test Case # 68 Volume - 1 to 5K per Quarter Hour for 2 Hours
Keyword |
Value |
Purpose |
SCP CMSDB will receive approximately 100,000K transactions per day or about 1000 per quarter hour. |
Method |
Results |
1. SMS/800 should send messages of varying sizes (400bytes - 2Kbytes) at a rate of 1000 messages per quarter hour for 2 contiguous (uninterrupted consecutive) hours. |
The SCP should process and respond to each message. There should not be any backup of messages. |
2. SMS/800 should increase the rate to 3000 messages per quarter hour for 2 contiguous hours. |
The SCP should process and respond to each message. There should not be any backup of messages. |
3. SMS/800 should increase the rate to 5000 messages per quarter hour for 2 contiguous hours. |
The SCP should process and respond to each message. There should not be any backup of messages. |