NEXV3 SIR Sect M_Att M02_VOTER Testing Requirements.docx

DEPARTMENT OF TRANSPORTATION

FEDERAL AVIATION ADMINISTRATION

Operational Capabilities Test (OCT) VOTER Testing Requirements for the

Next Generation A/G Communications

(NEXCOM)

Version 3 (V3) Radio Acquisition

FAA William J. Hughes Technical Center Atlantic City International Airport, New Jersey 08405 Document Version Control

Table of Contents

List of Figures

List of Tables

OCT VOTER Test Requirements for NEXCOM V3 Radio Acquisition

OCT VOTER Test Requirements iii March 6, 2023 This document becomes uncontrolled once printed.

Introduction Purpose The purpose of this document is to describe the processes to be followed by the FAA to evaluate VoIP-based requirements during the NEXCOM V3 Radio Operational Capability Test (OCT).

These test procedures employ a test tool known as Voice over Internet Protocol (VoIP) in Air Traffic Management (ATM) Test Suite VOTER (hereinafter referred to as VOTER). Test personnel will execute a select set of the available VOTER test cases designed to demonstrate specific program requirements relating to the ED-137/1C standard.

This document will provide the methodology and strategy developed by the Air-to-Ground Communications Branch to satisfy the shall requirements identified for VOTER testing (Shall23, Shall24, Shall284, Shall289, and Shall290). These requirements are defined in the NEXCOM V3 Radio Product Description (PD), FAA-E-37021.

Scope The scope of this document is limited to the role of the Air-to-Ground Communications Branch in the OCT conduct. That is, limited to test activities involving the test tool VOTER and evaluation of select ED137/1C requirements.

This document is an expansion of the “SIPT” test case described in the NEXCOM V3 Radio Screening Information Request (SIR) Attachment M01 (OCT Plan). Given the significant scope of the VOTER-based testing, it was broken out as a separate attachment (M02) of this SIR.

The VOTER test campaigns and procedures described in this document also include a test case for Simultaneous Call Transmission (SCT). The “RSCT” test case is described in SIR Attachment M01 (OCT Plan), but will be launched by VOTER.

Reference Documents The following reference documents provide a basis of direction and guidance on which this document is built:

1. VOTER First Steps User’s Guide, v0.2.1, EUROCONTROL, Brussels, Belgium, February 2022.

2. VOTER User’s Guide, v0.1.8, EUROCONTROL, Brussels, Belgium, February, 2022.

3. ED-137/1C, “Interoperability Standards for VoIP ATM Components”, Volume 1: Radio, EUROCAE, Malakoff, France, April 2017.

4. ED-137/1C, “Interoperability Standards for VoIP ATM Components”, Volume 1: Radio, Change 1, Malakoff, France, May 2020.

5. VOTER 4.1.x TEST DESCRIPTION, Volume 1 – GRS Radio ED-137/1C compliance, Ed. 3.9, EUROCONTROL, Brussels, Belgium, October 5, 2021.

6. History and Rationale of VoIP in ATM Test Suite Development, Ver. 1.0, FAA, Washington, DC, March 14, 2012.

System Description The units to be tested are the OCT radio transmitters and OCT radio receivers. The transmitters and receivers are radios that the offeror submits for evaluation in accordance with the Screening Information Request (SIR). For this plan, the term “radio” is used to refer to an OCT receiver, an OCT transmitter, or both. The radio will work within either the VHF frequency band or the UHF frequency band respectively. The radios to be evaluated during OCT are described in the NEXCOM V3 Radio PD, FAA-E-37021.

Program Description The OCT VOTER test requirements defined within this document are also part of the V3 Radio Source Selection and will be used to evaluate and characterize whether the offeror’s system meets the V3 Radio requirements.

The OCT will be carried out by two teams within the Technical Evaluation Team (TET), the OCT Test Team and the OCT Product Team. The OCT Test Team will evaluate the V3 Radio requirements where verification and evaluation require direct physical contact with the V3 Radio equipment. The OCT VOTER test requirements’ evaluation will be conducted at the FAA William J. Hughes Tech Center (WJHTC) by the OCT Test Team. The OCT Product Team will evaluate V3 Radio requirements that can be evaluated by reviewing offeror technical and analysis documentation. The findings of both teams, inclusive of the VOTER test requirements, will be compiled into a Final Report prepared by the TET.

Approach and Concept The OCT consists of evaluating each offeror’s submission against the product description requirements delineated in FAA-E-37021, unless otherwise specified.

The NEXCOM V3 Radio testing consists of pre-contract award and post-contract award test and evaluation (T&E) programs. This SIR Attachment M02 describes the framework of the pre-contract award OCT program for evaluating requirements identified for VOTER test requirements (i.e., Shall23, Shall24, Shall284, Shall289, and Shall290).

Test and Evaluation Descriptions NEXCOM V3 Radio requirements in FAA-E-37021 will be evaluated as part of the OCT. SIR Attachment M03 {OCT Verification Requirements Traceability Matrix (VRTM)} defines how each requirement will be evaluated, inclusive of Shall23, Shall24, Shall284, Shall289, and Shall290.

Test Case Descriptions The VOTER OCT test procedures are attached to this document in Appendix B; each procedure includes the test description from VOTER for each test case selected for OCT. At a high level, the OCT test cases will provide coverage of the test cases from the following test case groups as defined in VOTER (see section 5.2 of this document for definitions of VOTER terminology). These are categorical groupings of the test cases selected for OCT; each VOTER test campaign contains test cases from one or more of these categories.

· Valid/NonValid Interface

· “SIP_session”

· These test cases evaluate the radio’s compliance with ED-137/1C requirements for establishing and clearing SIP sessions.

· “SIP_INV_Header”

· These test cases evaluate the radio’s compliance with ED-137/1C requirements for SIP INVITE Header signaling.

· “SIP_Message_Header”

· These test cases evaluate the radio’s compliance with ED-137/1C requirements for SIP Message Header signaling.

· “SIP_session_pre_emption”

· These test cases evaluate the radio’s compliance with ED-137/1C requirements for SIP Radio Session pre-emption.

· “SDP_attributes”

· These test cases evaluate the radio’s compliance with ED-137/1C requirements for SDP attributes signaling.

· “SDP_attribute_negotiation”

· These test cases evaluate the radio’s compliance with ED-137/1C requirements for SDP attribute negotiation signaling.

· “Real_Time_Session_Supervision_R2S”

· These test cases evaluate the radio’s compliance with ED-137/1C requirements for R2S signaling.

· “RTP_Header_Extension_operation”

· These test cases evaluate the radio’s compliance with ED-137/1C requirements for RTP header extension signaling.

· “WG67_KEY_IN”

· This event package SHALL be used to inform any User Agent in the network that has subscribed to the WG67 KEY-IN service about the current bindings that exist between all User Agent URI addresses at the various VCS endpoints that currently have SIP sessions established to the GRS Receiver, Transceiver or Transmitter endpoint and the individual ptt-id that was assigned by the GRS Receiver, Transceiver or Transmitter endpoint to each of these User Agents. (In case of Radio-TxRx or coupling sessions only).

· “Class_of_Service”

· These test cases evaluate the radio’s compliance with ED-137/1C requirements for Class of Service.

· Dynamic Delay Compression (DDC)

· These test cases evaluate the radio’s compliance with ED-137/1C requirements relating to DDC.

· Linked Session Management (LSM)

· LSM_SS_V

· These test cases evaluate the radio’s compliance with ED-137/1C requirements relating to LSM. The LSM_SS_V test cases have a valid single linked session request with LSM enabled.

· LSM_SS_NV

· These test cases evaluate the radio’s compliance with ED-137/1C requirements relating to LSM. The LSM_SS_NV test cases have a non-valid single linked session request with LSM enabled.

· LSM_SS_PTT_V

· These test cases evaluate the radio’s compliance with ED-137/1C requirements relating to LSM. The LSM_SS_PTT_V test cases have a valid single linked session establishment and PTT keying to the radio, with LSM enabled.

· LSM_DS_V

· These test cases evaluate the radio’s compliance with ED-137/1C requirements relating to LSM. The LSM_DS_V test cases have valid dual linked session requests with LSM enabled.

· LSM_DS_NV

· These test cases evaluate the radio’s compliance with ED-137/1C requirements relating to LSM. The LSM_DS_V test cases have non-valid dual linked session requests with LSM enabled.

A full list of the VOTER test cases selected for each test campaign is included in APPENDIX A – FAA NEXCOM V3 RADIO OCT CHECKLISTS.

Evaluation Approach In accordance with Section M.5.1.7, the FAA will evaluate the VOTER pass/fail test results generated from each offeror’s submitted OCT V3 radios, recorded in the OCT Test Log checklists, and in TLZ log files saved from VOTER.

System Under Test The System Under Test (SUT) is the Offeror’s OCT radio transmitter(s) and OCT radio receiver(s) submitted in response to the Government’s request for offer 693KA8-23-R-00005. The radio transmitter(s) and receiver(s) may support multiband operation or extended power; separate VOTER test campaigns were created for UHF vs VHF radios and for High vs Low power radios to allow pre-configuration of different IP addresses and user parts in case these variants are delivered as separate model numbers.

Interfaces Figure 41 depicts the OCT radio interface(s).

TESTER represents the VoIP in ATM Test Suite VOTER, which emulates a Voice Control System (VCS) interface. The SUT is the Offeror’s OCT radios.

Figure 41 VOTER Tester VCS Radio Interface and SUT Test Setup Configuration The test cases included in the TESTER are from VOTER release 4.1.32.1_ver20221006. The OCT test cases focus on VoIP functions and capabilities of the OCT Transmitter (Tx) IP interface and OCT Receiver (Rx) IP interface when operating with ED137/1C protocol implementations.

For testing the Offeror’s OCT radio interface, the settings to be modified from the default values provided by the test tool are VOTER fields, in PIXIT:

PX_FREQUENCY_IDENTITY

PX_SIP-Radio_Session_Limit_Max

PX_GLOBAL_TESTER_IP_ADDRESS

PX_TSYNC_TIME_LIMIT

PX_TSHUT_DOWN_TIME_LIMIT

PX_ENCODING_NAME

PX_PAYLOAD_TYPE

And in Parameters, under Open Message Building System, in Tester_VCS_Radio_UA:

[x] userpart [x] domain Where x is a value of 0-7.

And in SUT_GRS_Radio_UA [0]:

grsType userpart domain portNumber for generalSIP and generalRTP

NOTE: Other settings changes required by the test cases will be documented in the test procedures.

Figure 42 VCS Radio Test Setup

Figure 43 is a detailed OCT network diagram including ports and IP address information.

Figure 43 OCT Network Diagram Test Equipment Table 41 lists all (primary and backup) Government Furnished Equipment (GFE) to be used during OCT assessments, including all required hardware and software. All GFE listed in Table 41 will be under configuration control during OCT. The government evaluation team will use only GFE during demonstration conduct.

As shown in Section 3.3, the Government evaluation team will use four laptop computers during OCT:

· RxTESTER – a laptop loaded with TTworkbench version 32 and VOTER version 4.1.32.1_ver20221006. This laptop will execute the Rx VOTER test cases.

· TxTESTER – a laptop loaded with TTworkbench version 32 and VOTER version 4.1.32.1_ver20221006. This laptop will execute the Tx VOTER test cases.

· Test Support Station – Two laptops loaded with Wireshark network packet analyzer, and also acting as a Network Time Protocol (NTP) Server for TESTER, SUT, and Wireshark application.

The pre-configured Wireshark application will capture live packet data to and from the TESTER’s network interface. The Government evaluation team will apply a display filter in Wireshark (e.g., SIP or RTP).

NTP is a protocol and software implementation for synchronizing the clocks of computer systems over packet-switched data networks. This implementation will be pre-configured in the Test Support Station.

Table 41 OCT Government Furnished Equipment

/Model

/Serial Number

Laptop computer

Surface Pro 7

· VOTER 4.1.32.1 20221006

· Wireshark 4.0.3

48-65-EE-12-B3-75

005733395253

Surface Pro 7

· VOTER 4.1.32.1 20221006

· Wireshark 4.0.3

B8-31-B5-42-E6-DC

012664295253

E6420

D4-BE-D9-0D-5C-D3

6W42LS1

E6420

D4-BE-D9-0B-9B-35

6W4TKS1

Switch

SG250-08

Cisco IOS v2.5.9.15

SG250-08

Cisco IOS v2.5.9.15

PSZ22481SZ8

For SCT Test

Personnel OCT activities will require four Operators. They will operate the TESTER, SUT, and Test Support Station. Table 42 lists the responsibilities of each role.

Table 42 OCT Roles and Responsibilities

· Is the operator of the VOTER test tool for Tx test cases.

· Directs test case conduct.

· Directs test case conduct.

· Under the direction of TESTER Operator, participates in test case conduct.

· Ensures proper timing synchronization across the network elements using NTP.

· Records errors and anomalies encountered during test conduct.

Location OCT location is governed by SIR Attachment M01 (OCT Plan), and accessing the FAA WJHTC is described in Attachment L03 of the NEXCOM Radio V3 Screening Information Request, 693KA8-23-R-00005.

Schedule The schedule for OCT activities conducted at the WJHTC will occur in accordance with Section L.3.4 and the notional time frame is in section 5.2 of SIR Attachment M01 (OCT Plan).

Test Conduct Requirements under Test The VOTER OCT Plan evaluates five (5) Shalls from NEXCOM V3 Radio PD, FAA-E-37021:

The associated requirement number is included in the names of each VOTER test campaign and the cover sheet and test procedure documents. Shall 284 is a high level requirement that evaluates compliance with the ED-137/1C specification; this shall is evaluated by multiple VOTER test campaigns with normal interface, nonvalid, and DDC test cases. Shall 289 is evaluated by the LSM test campaigns. Shall 290 includes test cases that use the G.729 codec. Shall 23 and Shall 24 require that the radio support a configurable number of concurrent SIP sessions, with a minimum of 7 concurrent sessions.

Test Management The primary test tool used to evaluate VoIP requirements during NEXCOM V3 Radio OCT will be VOTER (VoIP in ATM Test Suite). VOTER is test software which consists of a collection of test cases designed to evaluate the ED-137/1C specification. These test cases are executed on the TTWorkbench platform developed by Spirent Communications. The test cases provided as part of VOTER are organized by default into four (4) high level test campaigns, for Interface test cases, Non-Valid test cases, Link Session Management (LSM) test cases, and Dynamic Delay Compensation (DDC) test cases. These default test campaigns contain all the test cases to be verified during the OCT. The high level campaigns were used as templates to create new test campaigns for use in V3 OCT.

A subset of the available VOTER test cases was selected to run during OCT. These test cases have been organized into forty-two (42) test campaigns, and each test campaign will be included in a VOTER workspace. See figure below:

Figure 51 High Level OCT Evaluation Flow designed to evaluate the ED-137/1C specification

The terms “workspace”, “test campaign”, and “test case” are defined as follows:

Workspace: A VOTER workspace is a collection of one or more projects. For the purpose of the OCT evaluation, this will be the highest level used to identify the test items in the package to be delivered to the offerors. Test Adapter Parameters are global variables defined at the workspace level, which apply to all projects in the workspace. The V3 OCT will make use of two workspaces; one on the “RxTESTER” PC, and one on the “TxTESTER” PC.

Project: A collection of test campaigns to be run using the same version of VOTER.

Test Campaign: A test campaign represents a collection of test cases, parameter settings and information about the test adapter to use. It contains neither test results nor test logs. VOTER test campaigns are saved as .clf Campaign Loader files.

Test Case Group: A categorical grouping of related test cases. VOTER test campaigns include test cases from one or more different groups. See section 4.3.2 for descriptions of the test case groups included in the VOTER test campaigns.

Test Case: A VOTER test case sends a series of messages to the GRS, and expects specific responses as defined by the ED-137/1C specification. Test cases are launched by double clicking the test case name in VOTER. All VOTER test cases are at least partially automated. Some test cases are fully automated, requiring no input from the user. These fully automated test cases are referred to as “Auto” test cases in the names of the OCT test campaigns and throughout this document. Other test cases require an intervention from the user, either a parameter which must be changed before executing the test case, or a user action during the test execution, prompted by a VOTER pop-up message. These semi-automated test cases are referred to as “Semi-Auto” test cases in the names of the OCT test campaigns and throughout this document. See diagrams below:

Figure 52 High Level OCT Evaluation Flow for Shall 284

Figure 53 High Level OCT Evaluation Flow for Shall 289

Figure 54 High Level OCT Evaluation Flow for Shall 290

Figure 55 High Level OCT Evaluation Flow for Shall 23 and 24 The forty-two (42) test campaigns for V3 OCT were developed by creating multiple copies of the default test campaigns provided with VOTER, removing test cases not selected for OCT conduct, and saving each test campaign with a new name and test configuration. Receiver and transmitter test cases were saved in separate test campaigns, as were “Auto” and “Semi-Auto” test cases, so that the automated test campaigns could be run as a batch of test cases without user intervention. Separate versions of the test campaigns were saved for UHF and VHF radios, as well as for high power and low power transmitters, so as to minimize parameter changes during OCT conduct. The name of each test campaign also includes the primary requirement (shall statement) being evaluated. Most test cases are mapped to Shall 284, a high level Shall that evaluates compliance to ED-137/1C. The LSM test cases map to Shall 289, and test cases evaluating the G.729 codec map to Shall 290. Shall 23 and Shall 24 share a set of test campaigns.

The High and Low power versions of the Tx test campaigns are identical except for the IP of the radio. Two test campaigns were developed in the event that the offeror submits the High and Low power transmitters as separate devices. Likewise, the UHF and VHF versions of each test campaign are identical except for the IP of the radios and the frequency. Two test campaigns were developed in the event that the offeror submits the UHF and VHF radios as separate devices.

Whether the offeror submits their UHF/VHF and High/Low Power variants as one model or multiple models, all test campaigns will be executed during OCT.

OCT VOTER Test Requirements 13 March 6, 2023

The following workspaces and test campaigns will be defined for use in OCT conduct. See Appendix A for the specific test cases included in each test campaign.

Table 5-1 Test Case Organization

OCT VOTER Test Requirements 16 March 6, 2023

The TESTER Operator will direct the actions of other operators for the execution of each test case(s). There are two types of test, valid and invalid.

Valid - Tests that handle signaling exchanges of messages, which are properly structured and correctly encoded.

Invalid - Tests that handle signaling exchanges of messages, which are either not properly structured or incorrectly encoded.

Once the test case is executed, VOTER provides one of the following five test verdicts: Error, Fail, Inconclusive, Pass, or None. Note that VOTER can sometimes return a false “Inconclusive” result (this is a known issue with VOTER); in the event of an Inconclusive result, the TESTER may re-execute the test case once and accept the new test verdict. The TESTER Operator will record the results for each test case in the FAA NEXCOM V3 RADIO OCT Checklists.

The verdicts are defined as follows:

· Error: test in progress had an issue during the execution or the test was stopped by the user

· Fail: Messages that do not conform to a given specification or best practice. Test execution not in compliance with specification or settings in the test campaign are not accurate. Other reason can be that the settings not recognized by validation process.

· Inconclusive: Message(s) contain insufficient or unexpected information, gathered to determine conformance to a given specification or best practice.

· Pass: SUT execution messages conform with given specifications or best practices.

· None: configurations within the test case are not suited for the test in progress.

Test conduct may be paused by the TESTER Operator or the Offeror. In the unlikely event that VOTER encounters an issue or a test participant errs, the actions in Table 51 should be used to record, recover, and resume. All such events will be documented by the TESTER Operator in Appendix A, the FAA NEXCOM V3 Radio OCT Checklists, or in Appendix B, the VOTER Test Case Procedures.

Table 52 Possible User Errors or Anomalies During Test Conduct

TESTER Operator will record the incident as a comment in the test procedure table or FAA NEXCOM V3 RADIO OCT Checklist using appropriate number from the Comment Key below.

Comment Key:

Testing will resume from the point of interruption (that is, from the same VOTER test case where the error occurred).

NOTE: Any test log or any record of any sort created by VOTER resulting from this event will NOT be deleted.

“Test stopped by TESTER due to no verdict from VOTER.”

Testing will resume from the point of interruption (that is, from the same VOTER test case where the error occurred).

If the “stop test execution” icon does not respond, see item 3 below.

NOTE: Any test log or any record of any sort created by VOTER resulting from this event will NOT be deleted.

Test results must be saved. If the tool is unresponsive and prevents the tester from saving the test results, the test campaign must be reloaded.

If this does not work, VOTER must be closed and restarted. In either case, this will cause the test case results in the specific campaign up to that point to be erased. Test cases will have to be re-run. TESTER will note the event in the Comments area of the FAA NEXCOM V3 RADIO OCT Checklist as “VOTER not responding, reloaded test campaign,” or “VOTER not responding, restarted test tool.”

* If this event occurs consecutively for three test cases, the TESTER Operator will pause testing for no more than 15 minutes for troubleshooting. The demonstration will resume with the first paused test case, and continue uninterrupted to the final test case of the campaign. If the SUT cannot continue with the current campaign, the next campaign may be executed.

The TESTER and Offeror will indicate their readiness to continue test conduct after comments are recorded. Four to six weeks are allocated for ED-137/1C testing. This includes the following: setup verifications, test campaign execution, and report generation (if required) including time to validate file readability.

Procedures Appendix A contains a Cover Sheet checklist of test cases and Appendix B contains the test cases with verification steps. Used together, appendices A and B provide a roadmap for testing.

Reports and Data Captures Prior to OCT conduct, offerors must execute the FAA provided test cases and deliver a complete set of .tlz (Test Logging Zip) log files with pass/fail test results and all associated Wireshark traces. The offeror’s VOTER test results will be reviewed by the FAA, but will not be used as part of the OCT evaluation. FAA will conduct its own testing during OCT.

Note that one test case, TC_RAD_RTP_SCT1, requires additional test equipment to cause an SCT condition. The FAA has provided a test procedure for the SCT test case, which assumes the use of the test equipment selected by the FAA. Offerors may deviate from the TC_RAD_RTP_SCT1 procedure and conduct the SCT test using alternate test equipment, so long as the test result is recorded by VOTER.

During OCT conduct, the TESTER will record pass/fail results as well as any errors or anomalies on the Cover Sheet documents provided in Appendix A. The TESTER will save the .tlz log file after completing each test campaign.

VOTER test reports in .pdf format are generated by the TESTER for each of the test campaigns, if required. The TESTER must save the test logs (.tlz files) prior to changing or closing the test campaigns. This is required to be able to generate reports of the test conduct. The reports capture the report date, report number, test cases within the campaign and the verdicts of each event.

Wireshark network protocol analyzer capture files are saved in pcap-ng format. The captures are done within VOTER.

Government test personnel will not delete files created by VOTER or Wireshark during OCT activities.

VOTER test results will be included as part of the OCT Test Report described in the SIR Attachment M01 (OCT Plan). Distribution of the completed OCT Test Report will be limited to the FAA Contracting Officer and the TET for award considerations as described in Section M.

Test Configuration Management GFE will be configured and placed under configuration management by Government test personnel prior to test. Table 31 is a list of GFE (both primary and backup) under configuration management.

OCT VOTER Test Requirements 19 March 6, 2023

Appendix A – FAA NEXCOM V3 RADIO OCT Checklists

Tester Information

Org.

VOTER & TTworkbench Information Device Under Test (DUT) InformationDUT

Make/Model

Serial #

Software Ver. #

UHF/VHF

DUT

Serial Num.

Primary Software Ver. Num.

VOTER Ver. #

VOTER Ver. Date

TTWB Express

VOTER Ver. #

TTWB Express

TTWB Professional

Test Information Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS1 – Shall_284_Int_Rx_Semi_Auto FAA William J. Hughes Technical Center, Air-to-Ground Communications Branch (ANG-E62), N-VIT Lab

Time & Date from page 1:

(See last page for additional space)

NOTE: Remember to save TLZ files

TLZ Information File Name

Location

Enter the test case line number in the “#” column and continue the Notes from previous pages.

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS2 – Shall_284_Int_Tx_Semi-Auto

Time & Date from page 1:

File Name

Location

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS3 – Shall_284_DDC_Rx_Semi-Auto

Time & Date from page 1:

File Name

Location

Time & Date from page 1:

Tester Information

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS4 – Shall_284_DDC_Tx_Semi-Auto

Time & Date from page 1:

File Name

Location

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS5 – Shall_290_G.729_Rx_Semi-Auto

Time & Date from page 1:

File Name

Location

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS6 – Shall_290_G.729_Tx_Semi-Auto

Time & Date from page 1:

File Name

Location

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS7 – Shall_23_24_Int_Rx_Auto

Time & Date from page 1:

File Name

Location

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS8 – Shall_23_24_Int_Tx_Auto

Time & Date from page 1:

File Name

Location

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

File Name

Location

V3 OCT TEST LOG – CS9 – Shall_284_Int_Rx_Auto

Time & Date from page 1:

Tester Information

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS10 – Shall_284_Int_Tx_Auto

Time & Date from page 1:

File Name

Location

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS11 – Shall_284_NonValid_Rx_Auto

Time & Date from page 1:

File Name

Location

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS12 – Shall_284_NonValid_Tx_Auto

Time & Date from page 1:

File Name

Location

Org.

Serial #

TTWB Express

VOTER Ver. #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS13 – Shall_289_LSM_Rx_Auto

Time & Date from page 1:

File Name

Location

Org.

Serial #

Workspace

Date

Time

ED-137 Ver.

High Level Req. Doc.

V3 OCT TEST LOG – CS14 – Shall_289_LSM_Tx_Auto

Time & Date from page 1:

File Name

Location

Appendix B – VOTER Test Case Procedure Steps

OCT VOTER Test Requirements B-33 March 6, 2023

Test Procedure 1 – Shall_284_Int_Rx_SemiAuto

Tester: __________________________________________________ Org: _________________________________ Date: ______________

Witness: _________________________________________________ Org: _________________________________ Date: ______________

For This Test Procedure:

Test Case: TC_RAD_R2S_4c Description: SQUELCH OFF repetition value test Tester establishes a SIP session to the GRS Transceiver or Transmitter during which SDP attribute “ptt_rep” value is negotiated to 0.

ptt_rep:3 implies 4 packets without audio sent with SQUOFF following SQUELCH deactivation. The GRS Transceiver or Transmitter activates SQUELCH. Tester verifies that it receives RTP audio packets from GRS Transceiver or Transmitter with PT = 8 or 0 and an incrementing timestamp of for G.711 A-Law or U-law codecs; The Tester sends R2S-Keepalive packets at the R2SKeepAlivePeriod to the GRS Transceiver or Transmitter with PT = 123 with an incrementing timestamp of for G.711 A-law or U-law codecs; The GRS Transceiver or Transmitter then deactivates SQUELCH. Tester verifies that it receives 4 RTP packets without audio indicating SQU OFF before it starts receiving R2S-Keepalive packets again at the R2S-KeepAlivePeriod from the GRS Transceiver or Transmitter with PT = 123 and an incrementing timestamp (i.e. increment of x for G.711 A-law or U-law codecs and SQU OFF.

Reason = “Expected Message 200 OK was received.”

If VOTER reported an inconclusive test result, double click TC_RAD_R2S_4c to re-execute the test case once. Record the second test result, then continue with the test procedure

Verdict = pass

Test Case: TC_RAD_R2S_5 Description: SQUELCH activation following R2S-Keepalive packet transmission Tester establishes a SIP session to the GRS Transceiver or Receiver. The Tester sends R2S-Keepalive packets at the R2SKeepAlivePeriod to the GRS Transceiver or Receiver with PT = 123 and an incrementing timestamp for G.711 A-law or U-law codecs. The Tester verifies that it receives R2S-Keepalive packets at the R2S-KeepAlivePeriod from the GRS Transceiver or Receiver with PT = 123 with an incrementing timestamp for G.711 A-law or Ulaw codecs. The GRS activates SQUELCH-ON. The Tester verifies that GRS Transceiver or Receiver does not wait until next R2S-Keepalive packet to indicate SQU ON, but sends an RTP audio packet immediately with PT = 8 or 0 and an incrementing timestamp for each period that has elapsed since previous R2S-Keepalive packet was sent.

If VOTER reported an inconclusive test result, double click TC_RAD_R2S_5 to re-execute the test case once. Record the second test result, then continue with the test procedure

Test Case: TC_RAD_RTP_SCT1 Description: Simultaneous Call Transmission Bit With a session established between Tester and GRS. Activate Stepped on radio transmissions detection bit (SCT) at GRS endpoint.

Tester verifies that RTPRx Header extension has SQU ON, PTT-OFF and SCT=1.

Deactivate Stepped on radio transmissions detection bit (SCT) at GRS endpoint. Tester verifies that RTPRx Header extension has SQU ON, PTT-OFF and SCT=0.

Calibration Procedure for SCT