NAPRD03 Version 6.14 V1
NAPRD03 Version 6.14 V1
Version 6.14
September, 2023
Any reproduction, modification, alteration, creation of a derivative work, or transmission of all or any part of this
publication, in any form, by any means, whether electronic or mechanical, including photocopying, recording, or via any
information storage and retrieval system, without the prior written permission of CTIA Certification, is unauthorized and
strictly prohibited by federal copyright law. This publication is solely for use within the PTCRB Certification Program. Any
other use of this publication is strictly prohibited unless authorized by CTIA Certification or its assigns in writing.
PTCRB Certification Program
1400 16th Street, NW
Suite 600
Washington, DC 20036
1.202.785.0081
www.ptcrb.com
List of Tables
Table 2.7.2-1 PTCRB TC Database Parameter Field Naming Rules.........................................................12
1.1 Purpose
The purpose of this Permanent Reference Document (PRD) is to provide version specific technical
framework within which GERAN, UTRA, E-UTRA, and NR device certification can take place.
Refer to the latest version of the PTCRB Program Management Document (PPMD) for the process
requirements.
2.1 Scope
The intent of this document is to define the criteria such that certification testing of devices may be
performed on a consistent basis. This document is maintained by the PTCRB Working Group within
CTIA Certification LLC and is updated on a quarterly basis.
2.2 Introduction
This document is intended to advise PTCRB authorized test laboratories (known as CTIA
Certification Authorized Test Labs or ATLs) concerning the establishment of device conformity with
the reference specifications below. Information is presented to clearly identify which conformance
requirements may be evaluated using the reference test system configuration as defined in the
PTCRB TC (Test Case) Database and which conformance requirements may be evaluated using
other defined methods or equipment.
The PTCRB Test Case (TC) Database includes a concise report of the technical status of the
reference certification test equipment implementation. Where necessary, additional information may
be presented to enable tests to be performed and the results of tests to be interpreted in a
harmonized manner. TC Database provides a separate listing of the test cases. The PTCRB TC
Database shall be used as the primary reference for the actual test cases and applicable
categories.
2.3.1 GERAN:
2.3.2 UTRA:
2.3.4 NR:
2.3.7 Positioning:
Note 2: Void.
[99] CTIA Certification Test Plan for Wireless Device Over-the-Air Performance, Version
4.0.x
[101] CTIA Certification Test Plan for Wireless Device Over-the-Air Performance,
Current Version
[102] CTIA Certification Test Plan for 2X2 Downlink MIMO and Transmit Diversity Over-
the-Air Performance, Current Version.
Found at https://ctiacertification.org/test-plans/
[103] CTIA Certification/Wi-Fi Alliance Test Plan for RF Performance Evaluation of Wi-Fi
Mobile Converged Devices, Current Version.
Found at https://ctiacertification.org/test-plans/
[121] OMA-ETS-SUPL-V1_0
[122] OMA-ETS-SUPL-V2_0
2.3.15 TTY:
Note 3: Void
[101] CTIA Certification Test Plan for Wireless Device Over-the-Air Performance Current
Version
Note 4: The core specification citations from 3GPP, OMA, and other Standards Bodies
referenced in this document, represent the definitive specification(s) for expected device
behavior as applicable.
For protocol tests, where 3GPP or OMA have developed TTCN, the official TTCN
represents the definitive specification(s) for test cases utilizing this scripting language.
Other protocol test implementations are allowed if they are based on prose for which
there is a corresponding 3GPP or OMA specification.
In the event of conflicting results between test platforms, equipment using TTCN
developed by 3GPP or OMA if available, represents the correct implementation until
proven otherwise.
Technical validation of the test systems included in this document has been conducted by the
PTCRB Validation Group (PVG). A list of members can be obtained from document PVG.02.
The PTCRB TC Database shows the status of validated tests approved for certification testing.
Where a variation or specific interpretation of a test specification or test method is required by the
PTCRB Primary Test Laboratory, this will be recorded in the PTCRB TC Database.
Any amendment proposals shall be submitted as a contribution to the PTCRB Working Group.
2.7 Data Fields Used by the PTCRB Test Case (TC) Database
A document defining the test approach for a feature or combination of features, and the
initial conditions execution conditions, and the pass/fail criteria for the related tests.
Test case as defined in the associated test specification. Note: When the test case
utilized multiple bands, such as tests pertaining to E-UTRA Carrier Aggregation, NR
Dual-Connectivity, NR Carrier Aggregation, etc. the specific bands to be tested are
denoted in a 3GPP-standardized band combination. The 3GPP-standardized band
configuration is contained within square brackets.
Test Case
Technology Parameter: Comment
Allowed Values
n2 Numeric values for the NR bands shall prepend a lower-case “n”
NR Bands
n260 to the band number without any leading zeros.
n25-n66 Numeric values representing Inter-Band between two NR bands.
DC_14A_n2 Numeric values for EN-DC configuration with at least one E-
DC_2A_n260A UTRA band(s) and one NR FR1 or FR2 band(s).
Numeric values for LTE-CA configurations with at least two E-
LTE-CA and NR-CA CA_2A-17A
UTRA component carriers or at least two NR component carriers
Bands CA_n66A-n71A
as Carrier Aggregation configurations.
Numeric values for the NR bands which utilize 4RX shall append
NR 4Rx Bands n7_RX4
“_RX4” to the band number without any leading zeros.
FDD4 Numeric values without leading zeros for the E-UTRA bands and
E-UTRA Bands
TDD41 their corresponding duplex mode shall be used.
Numeric values without leading zeros for E-UTRA bands
FDD4M applicable to LTE-M shall append an upper-case "M" to the band
number.
UTRA bands shall utilize Roman numerals to differentiate
UTRA Bands FDDII
between UTRA & E-UTRA.
GERAN bands with no qualification before or after the actual
GERAN Bands 1900
band definition.
The test case can be performed with any frequency band within a
General Band Independent
radio technology, supported by the device.
The test case can be performed with any RAT supported by the
Bearer agnostic
device
The LTE-M test case can be performed with any frequency band
BI-M
within an LTE-M radio technology, supported by the terminal.
The LTE-M test case can be performed with any frequency band
Network Independent
within an LTE-M radio technology, supported by the device.
The test case can be performed with priority EN-DC configuration
EN-BI
defined in Table 2.7.10-1, supported by the device.
The test case can be performed with priority NR band defined in
NR-BI
Table 2.7.10-1, supported by the device.
An RFT is a request by the PTCRB Working Group to include test cases for a specific
band, band combination, feature and/or function. The “RFT indication” field in the
PTCRB TC Database shows the association between any given test case and its
associated RFT. All RFTs are maintained in PTCRB PVG.03 and in the RFT portion of
the PTCRB TCDB.
Each validated test platform shall have an associated Test Platform (TP) number, the
relationship for which is maintained in the PTCRB TCDB in the fields labeled “V”. “E” or
“D”, as described below:
A PTCRB Working Group member may request inclusion of a specific test in Category
“E”. The PTCRB Operator Steering Group shall review the test and if approved by the
group, the test is moved to Category “E”. All new tests submitted by the PVG will
initially become Category "E".
This identifies the technology area of the test case. This is primarily used to determine
capabilities of a PTCRB Full Test Laboratory or PTCRB Associate Test Laboratory.
This field identifies clusters (groupings) of test cases for transfer validation purposes.
Bearer to be Tested: Defines the RAT bearer(s) and band(s) in which the device shall
be tested.
“Single” indicates that the applicable test case (e.g., protocol testing) shall be
executed in a single PTCRB Band with no specified band prioritization.
“FR Single” indicates that the applicable NR test case (e.g., protocol testing) shall be
executed in a single PTCRB NR FR1 Band and a single NR FR2 Band with no
specified band prioritization.
“NR Single prio” indicates that the applicable test case shall be executed in a single
PTCRB NR Band with a band execution priority order to be followed as specified
in Table.2.7.10-1 below
Note: Inter-band test cases shall be executed if the frequency band combinations are
supported by the device.
"All" indicates that the device shall be tested in all PTCRB Bands relevant to the RAT
under test. Section 2.8 of this document identifies all PTCRB Bands by RAT. Test
cases defined for GCF Bands shall be executed as indicated within the applicable
GCF-CC. Bands identified by both PTCRB and GCF are defined as PTCRB Bands
and test execution in these bands shall follow PTCRB rules. Inter-RAT test cases
shall be executed in all frequency band combinations supported by the device.
“I-RAT Single” – indicates an Inter-RAT test case that shall be executed in a single
band combination. Inter-RAT test cases are split into separate test case parts for
each possible band combination. Inter-RAT test cases shall be executed in
PTCRB Bands.
Blank – indicates that the test does not require a bearer
"RAT All" indicates that the applicable test case shall be executed once in each
supported RAT but only in PTCRB Bands within each supported RAT.
Audio testing shall be performed according to the rules as defined in Section 2.9.6 of this
document.
GCF Certification test results for GCF Bands (i.e., bands not listed in the latest PVG.11),
will be recognized as a substitute for PTCRB test results in the GCF bands, provided the
GCF RTO (Recognised Test Organisation) executing the tests is, at a minimum, an
active Observing member of the PVG (i.e., a lab with regulatory duties within a specific
country or PTCRB device Manufacturer).
The applicability of leveraged test results from the GCF certification test scope shall be
confirmed by the PTCRB Primary Test Laboratory responsible for the Initial PTCRB
certification of the device.
Otherwise, any GCF Band test cases assessed as potentially failing to meet PTCRB
requirements shall be performed in a PTCRB Full Test Laboratory or PTCRB Associate
Test Laboratory as delegated by the PTCRB Primary Test Laboratory. Spot-checking of
leveraged test results may be allowed at the discretion of the PTCRB Primary Laboratory.
The PTCRB Primary Test Laboratory shall be responsible for uploading the GCF
Certification test results to the PTCRB certification database along with their own test
results.
Note: An active Observing PVG member will be listed in the appropriate section of
PVG.02 Annex 2 and will attend at least one PVG meeting and one PTCRB Plenary
meeting per year.
For bearer-agnostic testing refer to NAPRD section “Application Enabler (AE) Test
Applicability”.
The following 3GPP-defined bands have been identified as PTCRB Bands in this and all other
PTCRB documents:
FDD Band 85
1
The NR FR2 bands list in this column have been included to provide FR2 conformance test coverage
and shall be considered EN-DC configurations including FR2 with LTE anchor-agnostic approach.
2
NR FR1 FDD Band 29 supports SDL-only, and as such is only supported during NR NSA EN-DC
operation.
3
E-UTRA FDD Band 29 supports SDL-only, and as such is only supported during E-UTRA CA operation.
RF Performance Evaluation is a mandatory requirement for all device types going through PTCRB
Certification (the Category Field in the PTCRB TCDB is informative only.) OTA device assessment
shall be based on the requirements described in sub-clause 2.9.1 through 2.9.5 below.
All devices (other than IoT devices) shall be tested for OTA performance as part of
PTCRB certification according to the requirements described in this section:
OTA performance requirements for IoT devices are specified in Section 2.9.2 of this
document.
The test plan to be utilized for the evaluation of OTA Performance for GERAN, UTRA, E-
UTRA, NR FR1 and/or FR2 devices is the version of “CTIA Certification Test Plan for
Wireless Device Over-the-Air Performance” [101] in effect at the time the device’s
certification request is submitted to the PTCRB certification database.
The latest version of the CTIA Certification Test Plan for Wireless Device Over-the-Air
Performance can be downloaded from CTIA Certification’s web site at
https://ctiacertification.org/test-plans/.
If the device supports GNSS or A-GNSS (Note: the GNSS or A-GNSS feature checkbox
shall be checked in the PTCRB certification database), it shall be tested according to
[101].
A listing of CTIA Certification Authorized Test Labs (ATLs) capable of conducting the
testing described in [101] can be found on the same web site (under OTA Performance
authorized testing capability).
A-GNSS tests may include the optional System Information Broadcast (SIB) messages
SIB8 and/or SIB16 according to the requirements of the device’s Target Operator(s).
Prior to lab submission, device manufacturers shall contact the device’s target
operator(s) for operator requirements concerning A-GNSS testing with SIB8 and/or
SIB16, and then make the appropriate declaration in their lab submission with respect to
A-GNSS testing with SIB8 and/or SIB16.
In their lab submission, the device manufacturer shall identify the option to be used as
defined in [99] Document 01.51, Sections 2.5.4, 2.5.5 and 2.5.6, as applicable,
concerning the possible use of SIB8 and/or SIB16.
Devices which support Carrier Aggregation shall be tested for performance of all relevant
CA combinations according to [101] and the corresponding Operator Priority List for the
set of Target Operator(s) identified by the manufacturer. No other CA combinations shall
be tested unless specifically requested by the Target Operator(s).
The device manufacturer shall consult with the Target Operator(s) to determine whether
they have unique OTA test requirements.
2.9.2 OTA Performance Test Requirements for IoT (internet of Things) Devices
OTA performance test applicability for IoT devices shall be determined as described in
[99] or [101], as applicable, with these special considerations:
Some devices include sensors which reduce the transmitter’s RF output power
when in close proximity to the user. TRP measurements of any device that
includes user proximity RF power reduction shall be made according to the
requirements of [99], Document 01.01, Section 2.1.3, Table 2.1.3-1, Note 2, as
applicable.
OTA Performance Test Applicability – IoT (Internet of Things) devices, OTA test
applicability for IoT/M2M devices shall be determined through a combination of the use of
[99], Document 01.01, Section 2.1.2 or 2.1.3 (as applicable) in conjunction with the IoT
device characteristics listed in Table 2.9.2-1 below.
The following requirements apply regardless of the responses in Table 2.9.2-1 above:
OTA testing shall only be required in the highest-order RAT supported by the
IoT device.
OTA testing is required in each supported band within the highest-order RAT
supported by the IoT device.
If the IoT device supports a band in a lower-order RAT that’s not supported in
the high-order RAT, the band in the lower-order RAT shall also be tested for
OTA performance.
If the IoT device vendor’s response to all of the questions (1) through (3) in Table 2.9.2-1
above is “N”, then the following test requirements 2.9.2.1 through 2.9.2.4 shall apply:
2.9.2.1 TRP Testing shall be performed on all supported bands and all channels as
required by [101]
2.9.2.2 TIS testing shall be performed only in the mid-channel for each supported
band above 1 GHz.
2.9.2.3 TIS testing shall be performed in the low, mid, and high channel for each
supported band below 1 GHz.
2.9.3.1 Hardware design changes applicable to any of the RATs listed in [101] as
well as GNSS
If the changes do not impact these areas AND conducted RF output power in all
supported bands has not changed by more than +/- 1 dB, then OTA performance testing
on the ECO is not necessary. The lab shall then upload a document to the PTCRB
certification database, in the Test Results area, providing this justification (see Laboratory
Test Report Content section of PPMD).
ECOs for devices supporting MIMO, which were not required to execute MIMO OTA for
the initial certification, are not required to execute the MIMO OTA testing called for in
Section 2.9.4 of this document.
2.9.4.1 If the device supports receive diversity, the diversity test conditions shall be
in accordance with [101].
2.9.4.2 If the device supports MIMO, the device shall be tested using the
methodology described in [102].
2.9.4.3 Per 3GPP TS 36.306, Category 1 and higher LTE devices are required to
support two antennas.
Any device unable to support the secondary antenna shall be required to submit a waiver
request. If the waiver request is approved, the PTCRB Primary Test Laboratory shall
check the LTE Single-Antenna Receiver checkbox in the OTA Performance Test area of
the PTCRB certification database and upload the waiver request here. This requirement
shall be checked on all devices regardless of whether they undergo OTA Performance
testing.
The purpose of this section is to eliminate the need to execute certain specified OTA and
GNSS performance tests in bands which overlap.
The overlapping band rules specified by the following references shall apply to all band-
specific OTA and GNSS performance tests.
• [99] Document 01.50, Section 5.1.1, Table 5.1.1.1-1 (NR FR1 SA TRP)
• [99] Document 01.50, Section 5.1.1, Table 5.1.1.2-1 (NR FR1 SA TIS)
2.9.5.3 Each applicable band combination per 2.9.5.2 shall be tested according to
the per-band test` configuration described in [99], Document 01.50, Section
5.1.2.
The requirements in this section are applicable to all devices which utilize a proximity
sensor for transmit power reduction.
The device manufacturer shall include documentation describing the device’s maximum
power reduction and power tolerance for each supported band in the Low, Mid and High
channels.
This test shall be performed according to [99] Document 01.01, Section 2.1.3, Table
2.1.3-1, Note 2.
Device certification shall be conducted with all frequency bands enabled according to its
capabilities. Devices shall not be reconfigured for any testing purposes.
For Initial Certifications and Parent devices, the PTCRB Primary Test Laboratory shall
ensure that the contents of the UE Capability Information Elements are correctly reported
to the network as specified in the device’s relevant PICS/PIXIT statements.
This shall be achieved by successfully running the validated test cases as follows:
2.12.4 UTRA/E-UTRA device: 3GPP TS 34.123-1 test case 8.1.5.7 and 3GPP TS
36.523-1 test case 8.5.4.1
2.12.8 E-UTRA/NR device: 3GPP TS 36.523-1 test case 8.5.4.1 and 3GPP TS
38.523-1 test case 8.2.1.1.1
2.12.10 Device with GEA1 disabled: 3GPP TS 51.010-1 test case 44.2.5.2.5
For any PTCRB Variant / ECO Request, a UE Capability Audit shall be conducted by
PTCRB Full Test Laboratory. This audit is required for all Variant / ECO Requests where
the GERAN, UTRA or E-UTRA functionality of the device has been changed or any
changes have been made to any feature group functionality. Where MMI only changes
have been implemented that have no impact on these areas, the UE Capability Audit will
not be required.
The section for E-UTRA channel bandwidth test cases has been moved to PVG.05.
This section defines the requirements for reporting TTY Total Character Error Rate (TCER)
measurements.
TTY testing is an optional PTCRB certification requirement. The device manufacturer shall consult
with the operator(s) to which they intend to deploy the device to determine whether this testing is
required. If target operator(s) do not require TTY testing the PTCRB Primary Laboratory can upload
a declaration of no testing required.
TTY test cases shall utilize TP100 to execute testing regardless of the validation status.
TTY TCER measurements results used for conformance testing shall be included in the
associated test report. TCER shall be reported to a precision of one-tenth of a percent.
2.15.2 Applicability
Requirement applies to all TCER test cases in the PTCRB Bearer Agnostic TTY Test
Specification [150]; specifically test cases 9.3, 9.4, 9.5, 9.6, 9.8, 9.9, and 9.10.
This section defines the requirements for the applicability of the current version of GSMA TS.35 IoT
Device Connection Efficiency testing.
2.16.1 Applicability
Testing requirements apply to all IoT devices supporting 3GPP Release 8 – 12 IoT
Devices.
Devices implementing eUICC shall be exempt until eUICCs are incorporated into GSMA
TS.34 and TS.35.
Test requirement is based on Test Applicability and Classification from GSMA TS.35
Annex C.
IoT Devices shall execute Connection Efficiency tests using the highest RAT supported
by both the test case and the device.
This section identifies the requirements for devices supporting Supplementary Services or NITZ.
This applies to the test cases of 3GPP TS 34.123-1, section 15.
Any new device testing or required retesting shall be done utilizing the validated test
cases of 3GPP TS 34.123-1.
Devices previously certified with the test cases of 3GPP TS 51.010 will not be required to
retest with the test cases of 3GPP TS 34.123-1 unless the ECO changes have warranted
retesting of the functionality. In this case, the 3GPP TS 34.123-1 version of the test case
shall be utilized.
This section identifies the requirements for devices supporting eSE. This refers to the
requirements of GSMA’s NFC Test Book.
This requirement applies to any new device being recertified due to eSE capability
changes. Previously certified devices are not required to retest with test cases from the
NFC Test Book unless the ECO changes have warranted retesting of the device’s eSE
functionality.
This testing must be executed by a PTCRB Full Test Laboratory technology qualified for
eSE. The PTCRB Primary Test Laboratory will upload the device’s eSE report to the
PTCRB certification database. The PTCRB Full Test Laboratory may use test results
acquired from a PTCRB Associate Test Laboratory technology qualified for eSE, of which
they sponsor.
The section for extreme test conditions has been moved to PVG.05.
2.20 Execution of Test Cases for E-UTRA Carrier Aggregation (CA) (Deleted)
The section for multi-band relaxation (MBR) declaration/execution requirements has been moved to
PVG.05.
This section identifies the applicability of Network Independent (NI) UICC test cases for devices
supporting LTE-M or NB-IoT.
If at least one LTE-M or NB-IoT frequency band is supported, Network Independent (NI)
UICC test cases of RFT029, 058 and 085 are applicable per the device’s PICS.
All devices supporting application enablers that are applicable for PTCRB certification.
Specific details on individual application enabler certification requirements are given in
the following sections.
This section lists test specifications applicable to application enablers required for
PTCRB certification. The latest approved version of the listed test specification shall be
used. If the SDO or standardization forum who has the ownership of the test specification
has approved any change requests which are yet to be incorporated into the test
specification, then these change requests should be used for validations and referenced
in the validation report.
3.1.4 ECOs
AE testing shall be conducted on an ECO if the associated changes impact any of the
following areas:
AE protocol implementation
Underlying protocols
If the changes do not impact these areas, then AE testing for an ECO is not necessary
and the PTCRB Primary Test Laboratory shall provide a declaration to the PTCRB
certification database stating that testing was not required.
Devices supporting application enablers required for PTCRB certification shall fulfill all
applicable application enabler conformance criteria.
The Certification Criteria for application enabler can include both Conformance and
Interoperability tests.
Interoperability test results shall be provided by the manufacturer and testing does not
have to be performed by a PTCRB Full Test Laboratory. Interoperability testing can be
proved through Field Trials, bi-lateral testing and/or multi-lateral events (e.g., Test Fests
hosted by OMA). The conditions for the I-lateral testing and/or multi-lateral event results
to be accepted for PTCRB certification are:
The manufacturer shall submit a declaration stating that the changes (if any)
introduced in the implementation tested in the test event, the results of which are
being presented for certification, have not changed the behavior of the
functionality tested. These results will be accepted to apply for certification if they
comply to the Certification Criteria
All test results shall be submitted to the PTCRB Primary Test Laboratory for
inclusion in the test report, to obtain the certification.
The test configuration shall be described and made available in the Certification
Declaration
Manufacturers are responsible for making all the necessary arrangements to be
able to disclose results of I-lateral and/or multi-lateral testing for Certification
purposes.
Where test Certification Criteria includes client-to-client testing, manufacturers
are also responsible for seeking the appropriate device to test against, contacting
other device manufacturers on a "reasonable effort" basis.
The manufacturer shall provide all the test results from the testing that was conducted for
original certification and any further latest test results, as appropriate.
This section gives details of the application enabler core specifications relevant for
PTCRB certification. For validation’ the latest approved version, if available, of all the
listed specifications should be used. If the SDO or standardization forum that has
ownership of the specification has approved any change requests of the content of the
specification, which are yet to be incorporated into the document, then these change
requests should be used for validations and referenced in the validation report.
The Options table, ICS or Test Case Mapping Table, as appropriate, shall be filled out by
the manufacturer to indicate the features implemented in the client. This shall be
submitted by the manufacturer to the PTCRB certification database as part of the
certification submission.
If the Options table, ICS or Test Case Mapping table is contained in external
specifications a reference to the document should be added to this section.
All mandatory features, of the implemented enablers for which certification is sought, as
specified in the applicable SDO enabler release specifications shall be implemented in
the device.
This section details how to present IOP test results and information on tested
configurations.
SUPL testing is applicable to devices that support OMA SUPL version 1.0 or 2.0.
https://www.openmobilealliance.org/release/SUPL/ETS/
The SUPL conformance test cases are captured in the PTCRB TC Database.
The following OMA SUPL core specifications shall be used as the basis for all
validations.
If the device implements audio support per3GPP Release 4 or later, the audio test cases
in Section 7 of 3GPP TS 26.132 applicable for Release 4 or later shall be applied as
certification criteria instead of the audio test cases applicable for Phase 2 and R99
devices.
Reference test position according to Section 5.3.2 of IEEE 269 – 2002 can be used and
shall accordingly be recorded in the test report if used.
Note: The PTCRB TC database audio test specification 3GPP TS 26.132 contains all
test cases from all 3GPP released specification releases.
The 3GPP TS 26.132 test specification is release specific, which differs from many test
specifications within the PTCRB TC DB. Therefore, requirements for audio tests may
differ i depending on the 3GPP release version of the TS 26.132 test spec. The PTCRB
TC DB does not take this release-specificity of 3GPP audio testing into account.
Therefore, the manufacturer shall declare a 3GPP release against which the device is
compliant.
The test plan is the CTIA Cybersecurity Certification Test Plan for IoT Devices. The latest
version of this test plan can be downloaded from https://ctiacertification.org/test-plans/.A
list of labs authorized to conduct this testing can be found on the same website (under
IoT Cybersecurity Certification Testing authorized testing capability).
IoT Cybersecurity testing is an optional PTCRB certification requirement and applies only
to IoT devices. The device manufacturer shall consult with the operator(s) to which they
intend to sell the device to determine whether this testing is required. Should this testing
be required, the device vendor shall check the “IoT Cybersecurity” checkbox when
submitting the PTCRB certification request.
4.3.1 If the device meets both criteria below, the device shall be tested to the CTIA
Certification/Wi-Fi Alliance Test Plan for RF Performance Evaluation of Wi-Fi Mobile
Converged Devices (e.g., CWG Test Plan) subject to the RF Performance Test
Applicability defined in Section 2.9.1 and/or Section 2.9.2 of this document:
1) Supports 802.11x (Note: the Wi-Fi feature checkbox shall be checked in the PTCRB
certification database) and
2) The device’s Wi-Fi support is intended for consumer use (e.g., as an Internet or
Intranet access point as opposed to use of Wi-Fi for telemetry and/or control functions)
Note: If the device meets both of the criteria above, Converged Wireless Group (CWG)
testing is required regardless of the device type/device.
802.11 coexistence testing for IoT/M2M devices shall be executed according to [99]
Document 01.20, Section 4.9,
IoT/M2M devices which do not meet the numbered criteria above are exempt from testing to
Version 2.1 of the CWG Test Plan and subsequent releases.
The latest version of the CWG Test Plan can be downloaded from CTIA Certification’s web
site at https://ctiacertification.org/test-plans/.
A listing of labs authorized to conduct CWG OTA performance testing can be found on the same web site
(under Converged Device authorized testing capability).
The test plan is the CTIA Certification Utility IoT Device Test Plan. The latest version of
this test plan can be downloaded from https://ctiacertification.org/test-plans/. A list of labs
authorized to conduct this testing can be found on the same website (under Utility IoT
Device authorized testing capability).
Utility IoT Device testing is an optional PTCRB certification requirement and applies only
to IoT devices requesting IoT Network Certified for Smart Connected Infrastructure. This
certification is recommended for devices operating in critical infrastructure applications
and may be a requirement of some utility or mobile network operators. To request this
certification, the device manufacturer shall check the “IoT Network Certified for Smart
Connected Infrastructure” checkbox when submitting the certification request.
April 2023 6.12 a) Updated Table 2.7.2-1 descriptions to align with PTCRB TC Database
b) Updated Table 2.9.1-1 bulleted notes below to numbered sections in
2.9.5 and 2.9.6
c) Updated Sections 2.9.1 through 2.9.8 bulleted requirements to
numbered paragraphs
d) Deleted Section 2.10 LTE/LTE Carrier Aggregation (CA)
Interoperability Testing
e) Removed reference to specific Band 66 LTE-CA combinations in
Section 2.20
f) Updated document to follow corrected capitalization and grammar as
ongoing task
g) Updated RAT terminology through document