Attachment_0005_SURAC_Test_Case_Scenarios_(A-E).pdf

Product Lead Land Mobile Radio

(PL LMR)

Subscriber Unit Radio and Accessory Contract

(SURAC)

General Test Case Scenarios

(Attachment A)

1 January 2016

Change Log Date Change

1 Description.............................................................................. Error! Bookmark not defined.

2 General Test Scenario

2.1 Test Scenario: Full Registration

2.2 Test Scenario: Group Voice Call

2.3 Test Scenario: Unit-to-Unit Voice Call

2.4 Test Scenario: Broadcast Voice Call

2.5 Test Scenario: Affiliation

2.6 Test Scenario: Announcement Group Call

2.7 Test Scenario: Emergency Alarm

2.8 Test Scenario: Emergency Group Call

2.9 Test Scenario: Emergency Unit-to-Unit Call

2.10 Test Scenario: Roaming (Multiple RF Site Systems Only)

2.11 Test Scenario: Authentication (Authentication Enabled Systems Only)

2.12 Test Scenario: Deregistration

2.13 Test Scenario: System Call

2.14 Test Scenario: Call Alert

2.15 Test Scenario: Radio Unit Disable/Re-Enable

2.16 Test Scenario: Out-of-Range Indication

2.17 Test Scenario: Site Trunking Indication

2.18 Test Scenario: Portable Keypad Disable

2.19 Test Scenario: On-Scene Communications

2.20 Test Scenario: Alerting

2.21 Test Scenario: Talkgroup Patching

2.22 Test Scenario: Talkgroup Patching - Secure

2.23 Test Scenario: Simultaneous/Multi Select

2.24 Test Scenario: Roaming

2.25 Test Scenario: Mutual Aid Interoperability

Attachment A - 1

1 Test Scenario, Case and Script Development and Execution

As each offeror may vary in how they meet the requirements, each Offeror receiving a “GO” decision from Step 1 shall develop detailed test scripts for each test case scenario needed for the radio type proposed. These test case scenarios contain APCO P25 and non-APCO P25 test case scenarios as well as integrated testing such as Patching, Simul-Select, Emergency Declaration, and Mutual Aid Interoperability. Offerors shall modify these test case scenario documents by expanding them to identify each step needed to prove the test case scenario in a test script. Test Case Scenarios need only be detailed into test scripts for those radio types proposed (e.g., if the Offeror is not testing OTAP, test scripts for OTAP test cases do not need to be provided). Since the local test location system configuration may impact the test script steps, the proposal phase will include a dry run of offeror test scripts to give offerors time to correct any test script errors.

An electronic version and hardcopies of the modified test case scenarios are deliverables. The detailed test scripts provided may be “red lined” during the on-site dry run prior to the start of the formal testing and updated copies provided to the Government both electronically and in hardcopy. Once formal testing begins, the test scripts must be followed exactly as written during on site testing. If the test script is not followed exactly the test will be marked as failed, and the equipment will not be technically acceptable.

Coupled with the offerors detailed test scripts is an Interoperability Test Completion Results form. This form, appendix C of the TEMP, is used to track testing progress and formal acceptance for all test cases the offeror executes. Both the Test Case Scenarios and the Interoperability Test Completion Results shall be modified by the offeror to match the radio types proposed.

Tests may require interaction between the offerors radios, local radios, and local consoles. Test frequencies, test talk groups, and console operators will be provided by the Government where required. The Offeror must identify where this interaction is required when submitting test scripts.

2 General Test Scenarios

2.1 Test Scenario: Full Registration

2.1.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.1.1

2.1.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.1.2

2.1.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.1.3

Attachment A - 2

2.1.3 Test Cases

2.1.3.1 Test Case 1 - Valid Registration

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.1.4.1

Offeror Test Script (Test Case 1)

Insert Test Script

2.1.3.2 Test Case 2 – Denied or Refused Registration

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.1.4.2

Offeror Test Script (Test Case 2)

2.1.3.3 Test Case 3 – Unverified Registration

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.1.4.3

Offeror Test Script (Test Case 3)

Attachment A - 3

2.2 Test Scenario: Group Voice Call

2.2.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.2.1

2.2.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.2.2

2.2.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.2.3

2.2.3 Test Cases

2.2.3.1 Test Case 1 – Group Call Granted

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.2.4.1

2.2.3.2 Test Case 2 – Group Call Denied

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.2.4.2

2.2.3.3 Test Case 3 – Group Call Request Queued

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.2.4.3

2.2.3.4 Test Case 4 – Group Call Interrupt

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.2.4.4

Offeror Test Script (Test Case 4)

Attachment A - 4

2.2.3.5 Test Case 5 – Group Call Routing

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.2.4.5

Offeror Test Script (Test Case 5)

2.2.3.6 Test Case 6 – Late Entry for Group Call

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.2.4.6

Offeror Test Script (Test Case 6)

Attachment A - 5

2.3 Test Scenario: Unit-to-Unit Voice Call

2.3.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.3.1

2.3.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.3.2

2.3.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.3.3

2.3.3 Test Cases

2.3.3.1 Test Case 1 – Unit-to-Unit Call with Target Availability Check Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.3.4.1

2.3.3.2 Test Case 2 – Unit-to-Unit Call with Target Availability Check Denied by Target Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.3.4.2

2.3.3.3 Test Case 3 – Unit-to-Unit Call with Target Availability Check – Traffic Channel Assignment after Target Availability Check

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.3.4.3

2.3.3.4 Test Case 4 – Unit-to-Unit Call with Target Availability Check – Traffic Channel Assignment before Target Availability Check

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.3.4.4

Attachment A - 6

2.3.3.5 Test Case 5 – Unit-to-Unit Call without Target Availability Check Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.3.4.5

2.3.3.6 Test Case 6 – Unit-to-Unit Call Queued without Target Availability Check Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.3.4.6

2.3.3.7 Test Case 7 – Unit-to-Unit Call Denied

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.3.4.7

Offeror Test Script (Test Case 7)

Attachment A - 7

2.4 Test Scenario: Broadcast Voice Call

2.4.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.4.1

2.4.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.4.2

2.4.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.4.3

2.4.3 Test Cases

2.4.3.1 Test Case 1 – Broadcast Voice Call

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.4.4.1

Attachment A - 8

2.5 Test Scenario: Affiliation

2.5.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.5.1

2.5.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.5.2

2.5.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.5.3

2.5.3 Test Cases

2.5.3.1 Test Case 1 – Radio Permitted to Affiliate with New Group Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.5.4.1

2.5.3.2 Test Case 2 – Radio Denied Affiliation to New Group

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.3.4.2

Attachment A - 9

2.6 Test Scenario: Announcement Group Call

2.6.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.6.1

2.6.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.6.2

2.6.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.6.3

2.6.3 Test Cases

2.6.3.1 Test Case 1 – Collection of Talk Groups Receive Call

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.6.4.1

Attachment A - 10

2.7 Test Scenario: Emergency Alarm

2.7.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.7.1

2.7.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.7.2

2.7.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.7.3

2.7.3 Test Cases

2.7.3.1 Test Case 1 – Emergency Alarm

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.7.4.1

2.7.3.2 Test Case 2 – Emergency Alarm, Invalid Radio

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.7.4.2

2.7.3.3 Test Case 3 – Emergency Alarm, Temporarily Valid Radio Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.7.4.3

Attachment A - 11

2.8 Test Scenario: Emergency Group Call

2.8.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.8.1

2.8.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.8.2

2.8.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.8.3

2.8.3 Test Cases

2.8.3.1 Test Case 1 – Emergency Call

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.8.4.1

2.8.3.2 Test Case 2 – Pre-Programmed Emergency Call

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.8.4.2

2.8.3.3 Test Case 3 – Emergency Call, Invalid Radio

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.8.4.3

2.8.3.4 Test Case 4 – Emergency Call, Temporarily Valid Radio Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.8.4.4

Attachment A - 12

2.8.3.5 Test Case 5 – Emergency Call Request Queued

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.8.4.5

2.8.3.6 Test Case 6 – Emergency Call Request Ruthless Preemption Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.8.4.6

Attachment A - 13

2.9 Test Scenario: Emergency Unit-to-Unit Call

2.9.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.9.1

2.9.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.9.2

2.9.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.9.3

2.9.3 Test Cases

2.9.3.1 Test Case 1 – Unit-to-Unit Emergency Call

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.9.4.1

Attachment A - 14

2.10 Test Scenario: Roaming (Multiple RF Site Systems Only)

2.10.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.11.1

2.10.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.11.2

2.10.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.11.3

2.10.3 Test Cases

2.10.3.1 Test Case 1 – Idle Radio

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.11.4.1

Attachment A - 15

2.11 Test Scenario: Authentication (Authentication Enabled Systems Only)

2.11.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.12.1

2.11.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.12.2

2.11.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.12.3

2.11.3 Test Cases

2.11.3.1 Test Case 1 – Authentication

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.12.4.1

2.11.3.2 Test Case 2 – Authentication Failure

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.12.4.2

Attachment A - 16

2.12 Test Scenario: Deregistration

2.12.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.13.1

2.12.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.13.2

2.12.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.13.3

2.12.3 Test Cases

2.12.3.1 Test Case 1 – Deregistration

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.13.4.1

Attachment A - 17

2.13 Test Scenario: System Call

2.13.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.14.1

2.13.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.14.2

2.13.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.14.3

2.13.3 Test Cases

2.13.3.1 Test Case 1 – System Call

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.14.4.1

Attachment A - 18

2.14 Test Scenario: Call Alert

2.14.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.15.1

2.14.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.15.2

2.14.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.15.3

2.14.3 Test Cases

2.14.3.1 Test Case 1 – Call Alert

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.15.4.1

2.14.3.2 Test Case 2 – Call Alert Denied

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.15.4.2

Attachment A - 19

2.15 Test Scenario: Radio Unit Disable/Re-Enable

2.15.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.20.1

2.15.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.20.2

2.15.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.20.3

2.15.3 Test Cases

2.15.3.1 Test Case 1 – Radio Unit Disable

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.20.4.1

2.15.3.2 Test Case 2 – Radio Unit Re-Enable

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.20.4.2

Attachment A - 20

2.16 Test Scenario: Out-of-Range Indication

2.16.1 Description

Subscriber Unit shall display an indicator when it is outside of the RF coverage area. Subscriber Unit shall emit a tone when Push-to-talk is initiated while the unit is outside of the RF coverage area.

2.16.2 Expected Behavior

Subscriber Unit indicates via visual and auditory notification that it is outside of the RF coverage area.

2.16.2.1 Initial Conditions

a) Ensure that radio 1 is registered on the LMR system.

b) Ensure that radio 2 is registered on the LMR system.

Talkgroup 1 for radios 1 and 2

2.16.3 Test Cases

2.16.3.1 Test Case 1 – Out-of-Range Indication

a) Verify communications between radio 1 and radio 2

b) Move radio 1 outside of the RF coverage area.

c) PASS CRITERION: Using a manufacturer specific method, verify that radio 1 is outside of the RF coverage area.

d) Initiate a Push-to-talk from radio 1.

e) PASS CRITERION: Verify that radio 1 emits an audible tone indicating it is outside of the

RF coverage area.

Attachment A - 21

2.17 Test Scenario: Site Trunking Indication

2.17.1 Description

Remote RF site loses connection to the Master site controller, this RF site will enter “Site Trunking” mode. Subscriber Unit indicates that system is in Site Trunking mode.

2.17.2 Expected Behavior

Subscriber Units with a display shall visually indicate the affiliated RF site is in Site Trunking mode.

2.17.2.1 Initial Conditions

a) Ensure that radio 1 is affiliated with the test RF site.

b) Test RF site is not in Site Trunking mode.

2.17.3 Test Cases

2.17.3.1 Test Case 1 – Site Trunking Indication

a) Using the procedure unique to the system verify that the affiliated RF site is in Wide Area mode.

b) PASS CRITERION: Using a manufacturer specific method, verify that radio 1 indicates that affiliated RF site is in Wide Area mode.

c) Using the procedure unique to the system place the affiliated RF site into Site Trunking mode.

d) PASS CRITERION: Using a manufacturer specific method, verify that radio 1 indicates that affiliated RF site is in Site Trunking mode.

e) Using the procedure unique to the system place the affiliated RF site into Wide Area mode.

Attachment A - 22

2.18 Test Scenario: Portable Keypad Disable

2.18.1 Description

Portable Subscriber Units that are equipped with key pads shall have a means for the user to disable the keypad.

2.18.2 Expected Behavior

The Subscriber Units keypad shall be disabled.

2.18.2.1 Initial Conditions

a) Ensure that radio keypad is functional.

2.18.3 Test Cases

2.18.3.1 Test Case 1 – Portable Keypad Disable

a) Using a manufacturer specific method, disable the keypad of radio.

b) PASS CRITERION: Verify that no actions are initiated with the pressing of any keypad button on the radio.

c) Using a manufacturer specific method, enable the keypad of radio.

d) PASS CRITERION: Verify that the keypad of the radio is enabled.

Attachment A - 23

2.19 Test Scenario: On-Scene Communications

2.19.1 Description

Subscriber Units shall be capable of supporting on-scene analog communications.

2.19.2 Expected Behavior

Subscriber Units shall communicate utilizing the provided simplex analog frequency

2.19.2.1 Initial Conditions

a) Ensure that radio 1 is set to the provided simplex frequency.

b) Ensure that radio 2 is set to the provided simplex frequency.

2.19.3 Test Cases

2.19.3.1 Test Case 1 – On-Scene Communications

a) Initiate a Simplex call from radio 1 to radio 2.

b) PASS CRITERION: Verify that radio 2 received the communication from radio 1.

c) Initiate a Simplex call from radio 2 to radio 1.

d) PASS CRITERION: Verify that radio 1 received the communication from radio 2.

Attachment A - 24

2.20 Test Scenario: Alerting

2.20.1 Description

Subscriber Unit is capable of sending a minimum of five distinctive alert tones (both warble and straight tones). The distinctive alert tones shall precede emergency message traffic. A unique tone shall be provided for emergency evacuation orders.

2.20.2 Expected Behavior

Subscriber Unit shall transmit 5 distinct alert tones.

2.20.2.1 Initial Conditions

a) Ensure that radio 1 is set to the provided simplex frequency.

b) Ensure that radio 2 is set to the provided simplex frequency.

c) Test Scenario: On-Scene Communications was successfully completed immediately before this Test Scenario.

2.20.3 Test Cases

2.20.3.1 Test Case 1 – Alerting

a) Initiate a Tone from radio 1 to radio 2.

b) PASS CRITERION: Verify that radio 2 received the Tone from radio 1.

c) Repeat steps (a) and (b) for remaining four (4) tones.

Attachment A - 25

2.21 Test Scenario: Talkgroup Patching

2.21.1 Description

Talkgroup Patching lets a dispatcher merge two or more talkgroups on one voice channel for conversation among Subscriber Unit users of different talkgroups and the dispatcher.

Dispatchers and Subscriber Unit users of the patched talkgroup can talk and listen to each other.

If the patching includes “secure” and “non-secure” talkgroups, one repeater will be used for “secure” mode and one repeater will be used for “non-secure” mode for each RF site.

2.21.2 Expected Behavior

Subscriber Units of different talkgroups will be able to talk to each other when patched by the dispatcher.

2.21.2.1 Initial Conditions

a) Ensure that radio 1 is set to test talkgroup 1.

b) Ensure that radio 2 is set to test talkgroup 2.

c) Ensure that radio 3 is set to test talkgroup 1.

d) Ensure that radio 4 is set to test talkgroup 2.

e) Ensure CONSOLE-1 is ready.

Note: All subscriber units must be on the same zone.

2.21.3 Test Cases

2.21.3.1 Test Case 1 – Alerting

a) Operator at CONSOLE-1 creates a patch between test talkgroup 1 and test talkgroup 2.

b) Operator at CONSOLE-1 initiate a patch call.

c) PASS CRITERION: Verify radio 1, radio 2, radio 3, and radio 4 can all monitor the call.

d) Subscriber Unit users initiate several calls between the radios.

e) PASS CRITERION: Verify all subscriber units can monitor the calls.

Attachment A - 26

2.22 Test Scenario: Talkgroup Patching - Secure

2.22.1 Description

Talkgroup Patching lets a dispatcher merge two or more talkgroups on one voice channel for conversation among Subscriber Unit users of different talkgroups and the dispatcher.

Dispatchers and Subsciber Unit users of the patched talkgroup can talk and listen to each other.

2.22.2 Expected Behavior

Subscriber Units of different talkgroups will be able to talk to each other when patched by the dispatcher.

2.22.2.1 Initial Conditions

a) Ensure that radio 1 is set to test talkgroup 1. (Secure Mode)

b) Ensure that radio 2 is set to test talkgroup 2. (Secure Mode)

c) Ensure that radio 3 is set to test talkgroup 1. (No secure keys loaded)

d) Ensure that radio 4 is set to test talkgroup 2. (Clear Mode with keys loaded)

e) Ensure CONSOLE-1 is ready.

Note: All subscriber units must be on the same zone.

2.22.3 Test Cases

2.22.3.1 Test Case 1 – Alerting

a) Operator at CONSOLE-1 creates a patch between test talkgroup 1 and test talkgroup 2.

b) Operator at CONSOLE-1 initiate a patch call.

c) PASS CRITERION: Verify radio 1, radio 2, and radio 4 can all monitor the call except radio 3.

d) Initiate a talkgroup call on talkgroup 1 from Radio 1.

e) PASS CRITERION: Verify CONSOLE-1, radio 2 and radio 4 can all monitor the call except radio 3.

Attachment A - 27

2.23 Test Scenario: Simultaneous/Multi Select

2.23.1 Description

Simultaneous/Multi Select allows a dispatcher to converse with two or more talkgroups simultaneously but subscriber units of those talkgroups cannot talk or listen to subscriber units of other talkgroups. Only subscriber units of the same talkgroup can listen.

2.23.2 Expected Behavior

Operators at dispatch consoles can talk to two or more talkgroups simultaneously but subscriber units of different talkgroups cannot talk to each other.

2.23.2.1 Initial Conditions

a) Ensure that radio 1 is set to test talkgroup 1.

b) Ensure that radio 2 is set to test talkgroup 2.

c) Ensure that radio 3 is set to test talkgroup 3.

d) Ensure CONSOLE-1 is ready.

2.23.3 Test Cases

2.23.3.1 Test Case 1 – Alerting

a) Operator at CONSOLE-1 creates a Simultaneous/Multi Select for talkgroup 1, talkgroup 2, and talkgroup 3.

b) Operator at CONSOLE-1 initiates a Simultaneous/Multi Select call.

c) PASS CRITERION: Verify radio 1, radio 2, and radio 3 can all monitor the call.

d) Initiate a call from radio 1.

e) PASS CRITERION: Verify CONSOLE-1 can monitor the call but radio 2 and radio 3 cannot.

f) Repeat d) and e) for radio 2 and radio 3.

Attachment A - 28

2.24 Test Scenario: Roaming

2.24.1 Description

Roaming ensures that a subscriber unit traveling away from one RF site to another RF site is kept connected to the LMR network without breaking the connection.

2.24.2 Expected Behavior

A subscriber unit traveling from one RF site to another RF site will roam automatically without dropping a talkgroup call in progress.

2.24.2.1 Initial Conditions

a) Ensure that radio 1 is set to test talkgroup 1.

b) Ensure that radio 2 is set to test talkgroup 1.

c) Government System Manager is in position to verify

2.24.3 Test Cases

2.24.3.1 Test Case 1 – Alerting

a) Make sure radio 1 and 2 are registered to the same RF site.

b) Initiate a talkgroup call on talkgroup 1 from radio 1 to radio 2.

c) Move radio 1 away from the RF site until it gets into coverage of a second RF site while radio 2 stays at the start site.

d) PASS CRITERION: System Manager verifies radio 1 is roamed and registered with the second RF site while radio 2 is still registered with the start site.

e) PASS CRITERION: Verify that continuous communications can occur as radio 1 roams between RF sites.

Attachment A - 29

2.25 Test Scenario: Mutual Aid Interoperability

2.25.1 Description

Subscriber units of the LMR system can be programmed to communicate with Mutual Aid partners’ subscriber units through the means of a gateway when they are programmed to specific preset talkgroups.

2.25.2 Expected Behavior

When a subscriber unit initiates a call to a specific mutual aid partner on a pre-programmed talkgroup, it will be able to communicate with the subscriber units of the respective mutual aid partner.

2.25.2.1 Initial Conditions

a) Ensure that radio 1 is set to a talkgroup which is programmed for use with the mutual aid partner.

b) Ensure that a mutual aid partner radio is set to the respective talkgroup.

2.25.3 Test Cases

2.25.3.1 Test Case 1 – Alerting

a) Initiate a call from radio 1.

b) PASS CRITERION: Verify that the mutual aid partner radio can monitor the call.

c) Initiate a call from the mutual aid partner radio

d) PASS CRITERION: Verify that radio 1 can monitor the call.

Over the Air Programming (OTAP) Test Procedures

(Attachment B)

1 Description.............................................................................. Error! Bookmark not defined.

2 General Test Suites

2.1 Test Suite: Over the Air Programming (OTAP)

Attachment B - 1 decision from Step 1 shall develop detailed test scripts for each test case scenario needed for the radio type proposed. These test case scenarios contain APCO P25 and non-APCO P25 test case scenarios as well as integrated testing. Offerors shall modify these test case scenario documents by expanding them to identify each step needed to prove the test case scenario in a test script.

Test Case Scenarios need only be detailed into test scripts for those radio types proposed (e.g., if the Offeror is not testing OTAP, test scripts for OTAP test cases do not need to be provided).

Since the local test location system configuration may impact the test script steps, the proposal phase will include a dry run of offeror test scripts to give offerors time to correct any test script errors.

An electronic version and hardcopies of the modified test case scenarios are deliverables. The detailed test scripts provided may be “red lined” during the on-site dry run prior to the start of the formal testing and updated copies provided to the Government both electronically and in hardcopy. Once formal testing begins, the test scripts must be followed exactly as written during on site testing. If the test script is not followed exactly the test will be marked as failed, and the equipment will not be technically acceptable.

Coupled with the offerors detailed test scripts are the Interoperability Test Completion Results form. This form, appendix C of the TEMP, is used to track testing progress and formal acceptance for all test cases the offeror executes. Both the Test Case Scenarios and the Interoperability Test Completion Results shall be modified by the offeror to match the radio types proposed.

Tests may require interaction between the offerors radios, local radios, and local consoles. Test frequencies, test talk groups, and console operators will be provided by the Government where required. The offeror must identify where this interaction is required when submitting test scripts.

2 OTAP Test Suites

2.1 Test Suite: Over the Air Programming (OTAP)

2.1.1 Description

Over the Air Programming allows a user to configure a Subscriber Unit remotely by sending a sequence of commands over-the-air from the LMR system.

2.1.2 Expected Behavior

Subscriber Unit will be configured with the new changes upon completion of the OTAP procedure.

Ensure that radio is registered on the LMR system.

Attachment B - 2

2.1.3.1 Test Case 1 – Configuration Change

a) Using a manufacturer specific method, connect to radio over the network.

b) Using a manufacturer specific method, make a change to the original configuration and write to radio over the air.

c) PASS CRITERION: Using a manufacturer specific method, verify the configuration change has been implemented on radio.

d) Using a manufacturer specific method, return the configuration to the original state.

Vendor Test Script (Test Case 1)

Telephone Interconnect Test Procedures

(Attachment C)

`1 January 2015

1 Description.............................................................................. Error! Bookmark not defined.

2 General Test Suites

2.1 Test Suite: Unit-to-PSTN Telephone Interconnect Call

2.2 Test Suite: PSTN-to-Unit Telephone Interconnect Call

2.3 Test Suite: PSTN-to-Group Telephone Interconnect Call

Attachment C - 1 decision from Step 1 shall develop detailed test scripts for each test case scenario needed for the radio type proposed. These test case scenarios contain APCO P25 and non-APCO P25 tests.

Offerors shall modify these test case scenario documents by expanding them to identify each step needed to prove the test case scenario in a test script. Test Case Scenarios need only be detailed into test scripts for those radio types proposed (e.g., if the Offeror is not testing OTAP, test scripts for OTAP test cases do not need to be provided). Since the local test location system configuration may impact the test script steps, the proposal phase will include a dry run of offeror test scripts to give offerors time to correct any test script errors.

An electronic version and hardcopies of the modified test case scenarios are deliverables. The detailed test scripts provided may be “red lined” during the on-site dry run prior to the start of the formal testing and updated copies provided to the Government both electronically and in hardcopy. Once formal testing begins, the test scripts must be followed exactly as written during on site testing. If the test script is not followed exactly the test will be marked as failed, and the equipment will not be technically acceptable.

Coupled with the offerors detailed test scripts are the Interoperability Test Completion Results form. This form, appendix C of the TEMP, is used to track testing progress and formal acceptance for all test cases the offeror executes. Both the Test Case Scenarios and the Interoperability Test Completion Results shall be modified by the offeror to match the radio types proposed.

Tests may require interaction between offerors radios, local radios, and local consoles. Test frequencies, test talk groups, and console operators will be provided by the Government where required. The offeror must identify where this interaction is required when submitting test scripts.

2 Telephone Interconnect Test Suites

2.1 Test Suite: Unit-to-PSTN Telephone Interconnect Call

2.1.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.23.1

2.1.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.23.2

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.23.3

Attachment C - 2

2.1.3.1 Test Case 1 - Unit-to-PSTN Telephone Interconnect

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.23.4.1

2.1.3.2 Test Case 2 – Unit-to-PSTN Telephone Interconnect Denied Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.23.4.2

Vendor Test Script (Test Case 2)

2.1.3.3 Test Case 3 – Unverified Registration

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.23.4.3

Vendor Test Script (Test Case 3)

Attachment C - 3

2.2 Test Suite: PSTN-to-Unit Telephone Interconnect Call

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.24.1

2.2.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.24.2

2.2.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.24.3

2.2.3 Test Cases

2.2.3.1 Test Case 1 - PSTN-to-Unit Telephone Interconnect

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.24.4.1

2.2.3.2 Test Case 2 – PSTN-to-Unit Telephone Interconnect - Denied By Target Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.24.4.2

2.2.3.3 Test Case 3 – PSTN-to-Unit Telephone Interconnect - Queued Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.24.4.3

Vendor Test Script (Test Case 3)

Attachment C - 4

2.3 Test Suite: PSTN-to-Group Telephone Interconnect Call

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.25.1

2.3.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.25.2

2.3.2.1 Initial Conditions

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.25.3

2.3.3 Test Cases

2.3.3.1 Test Case 1 - PSTN-to-Group Telephone Interconnect

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.25.4.1

Over the Air Rekeying (OTAR) Test Procedures

(Attachment E)

1 Description.............................................................................. Error! Bookmark not defined.

2 General Test Suites

2.1 Test Suite: Warm-Start Command

2.2 Test Suite: Rekey-Command

2.3 Test Suite: Changeover-Command

2.4 Test Suite: Modify-Key-Command

2.5 Test Suite: Delete-Key-Command

2.6 Test Suite: Change-RSI-Command

2.7 Test Suite: Zeroize-Command

Attachment E - 1 decision from Step 1 shall develop detailed test scripts for each test case scenario needed for the radio type proposed. These test case scenarios contain APCO P25 and non-APCO P25 test case scenarios as well as integrated testing. Offerors shall modify these test case scenario documents by expanding them to identify each step needed to prove the test case scenario in a test script.

Test Case Scenarios need only be detailed into test scripts for those radio types proposed (e.g., if the Offeror is not testing OTAP, test scripts for OTAP test cases do not need to be provided).

Since the local test location system configuration may impact the test script steps, the proposal phase will include a dry run of offeror test scripts to give offerors time to correct any test script errors.

An electronic version and hardcopies of the modified test case scenarios are deliverables. The detailed test scripts provided may be “red lined” during the on-site dry run prior to the start of the formal testing and updated copies provided to the Government both electronically and in hardcopy. Once formal testing begins, the test scripts must be followed exactly as written during on site testing. If the test script is not followed exactly the test will be marked as failed, and the equipment will not be technically acceptable.

Coupled with the offerors detailed test scripts are the Interoperability Test Completion Results form. This form, appendix C of the TEMP, is used to track testing progress and formal acceptance for all test cases the offeror executes. Both the Test Case Scenarios and the Interoperability Test Completion Results shall be modified by the offeror to match the radio types proposed.

Tests may require local interaction between the offerors radios, local radios, and local consoles.

Test Frequencies, test talk groups, and console operators will be provided by the Government where required. The offeror must identify where this interaction is required when submitting test scripts.

2 OTAR Test Suites

2.1 Test Suite: Warm-Start Command

2.1.1 Description

This test verifies that the Key Management Facility (KMF) can add a Traffic Encryption Key (TEK) to a radio.

2.1.2 Expected Behavior

Verification of TIA-102.CABB section 4.1 validation statements.

Refer to TIA-102.CABB section 4.1.A.

Attachment E - 2

2.1.3.1 Test Case 1 – Warm-Start Command

Refer to TIA-102.CABB section 4.1.B. – 4.1.F.

Attachment E - 3

2.2 Test Suite: Rekey-Command

This test verifies that the KMF can add a Traffic Encryption Key (TEK) to a radio.

2.2.2 Expected Behavior

Verification of TIA-102.CABB section 4.2 validation statements.

2.2.2.1 Initial Conditions

Refer to TIA-102.CABB section 4.2.A.

2.2.3 Test Cases

2.2.3.1 Test Case 1 – Rekey-Command

Refer to TIA-102.CABB section 4.2.B – 4.2.L

Attachment E - 4

2.3 Test Suite: Changeover-Command

This test verifies that the KMF can make an inactive keyset the active keyset in a radio.

2.3.2 Expected Behavior

Verification of TIA-102.CABB section 4.3 validation statements.

2.3.2.1 Initial Conditions

Refer to TIA-102.CABB section 4.3.A.

2.3.3 Test Cases

2.3.3.1 Test Case 1 – Changeover Command

Refer to TIA-102.CABB section 4.3.B – 4.3.F.

Attachment E - 5

2.4 Test Suite: Modify-Key-Command

2.4.1 Description

This test verifies that the KMF can add, modify, or delete a key in a radio.

2.4.2 Expected Behavior

Verification of TIA-102.CABB section 4.4 validation statements.

2.4.2.1 Initial Conditions

Refer to TIA-102.CABB section 4.4.A.

2.4.3 Test Cases

2.4.3.1 Test Case 1 – Modify-Key Command

Refer to TIA-102.CABB section 4.4.B – 4.4.E.

Attachment E - 6

2.5 Test Suite: Delete-Key-Command

2.5.1 Description

This test verifies that the KMF can delete a key from radio.

2.5.2 Expected Behavior

Verification of TIA-102.CABB section 4.5 validation statements.

2.5.2.1 Initial Conditions

Refer to TIA-102.CABB section 4.5.A.

2.5.3 Test Cases

2.5.3.1 Test Case 1 – Delete-Key Command

Refer to TIA-102.CABB section 4.5.B – 4.5.H.

Attachment E - 7

2.6 Test Suite: Change-RSI-Command

2.6.1 Description

This test verifies that the KMF can add, modify, and delete Radio Set Identifiers (RSIs).

2.6.2 Expected Behavior

Verification of TIA-102.CABB section 4.6 validation statements.

2.6.2.1 Initial Conditions

Refer to TIA-102.CABB section 4.6.A.

2.6.3 Test Cases

2.6.3.1 Test Case 1 – Change-RSI Command

Refer to TIA-102.CABB section 4.6.B – 4.6.O.

Attachment E - 8

2.7 Test Suite: Zeroize-Command

2.7.1 Description

This test verifies that the KMF can remove Unique Key Encryption Key (UKEK) and TEK keys from the radio.

2.7.2 Expected Behavior

Verification of TIA-102.CABB section 4.7 validation statements.

2.7.2.1 Initial Conditions

Refer to TIA-102.CABB section 4.7.A.

2.7.3 Test Cases

2.7.3.1 Test Case 1 – Zeroize-Command

Refer to TIA-102.CABB section 4.7.B – 4.7.E.

AES Encryption Test Procedures

(Attachment D)

1 Description.............................................................................. Error! Bookmark not defined.

2 General Test Suites

2.1 Test Suite: AES Encryption

Attachment D - 1 decision from Step 1 shall develop detailed test scripts for each test case scenario needed for the radio type proposed. Test scenarios and test cases are provided by the Government and contain APCO P25 and non-APCO P25 tests as well as integrated testing. Offerors shall modify these test case scenario documents by expanding them to identify each step needed to prove the test case scenario in a test script. Test Case Scenarios need only be detailed into test scripts for those radio types proposed (e.g., if the Offeror is not testing OTAP, test scripts for OTAP test cases do not need to be provided). Since the local test location system configuration may impact the test script steps, the proposal phase will include a dry run of offeror test scripts to give offerors time to correct any test script errors.

An electronic version and hardcopies of the modified test case scenarios are deliverables. The detailed test scripts provided may be “red lined” during the on-site dry run prior to the start of the formal testing and updated copies provided to the Government both electronically and in hardcopy. Once formal testing begins, the test scripts must be followed exactly as written during on site testing. If the test script is not followed exactly the test will be marked as failed, and the equipment will not be technically acceptable.

Coupled with the offerors detailed test scripts are the Interoperability Test Completion Results form. This form, appendix C of the TEMP, is used to track testing progress and formal acceptance for all test cases the offeror executes. Both the Test Case Scenarios and the Interoperability Test Completion Results shall be modified by the offeror to match the radio types proposed.

Tests may require interaction between the offerors radios, local radios, and local consoles. Test frequencies, test talk groups, and console operators will be provided by the Government where required. The Offeror must identify where this interaction is required when submitting test scripts.

2 AES Encryption Test Suites

2.1 Test Suite: AES Encryption

2.1.1 Description

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.10.1

2.1.2 Expected Behavior

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.10.2

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.10.3

Attachment D - 2

2.1.3.1 Test Case 1 – Call Privacy for Encrypted Call (including Groups) Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.10.4.1

2.1.3.2 Test Case 2 – Late Entry for Encrypted Call

Refer to TIA-102.CABC-B/TIA-102.CABC-B-1, section 2.2.10.4.2