PTCRB : 12 pièges courants, clause par clause

Hugues Orgitello mis à jour le 7 oct. 2026 15 min de lecture

Douze erreurs PTCRB récurrentes, et la clause qui attrape chacune d'elles. Chaque piège ci-dessous s'appuie sur une section numérotée des documents en vigueur au 7 octobre 2026 : le Program Management Document PPMD V4.2 et les exigences techniques NAPRD03 V6.26, tous deux datés d'octobre 2026, plus la liste de bandes PVG.11 V5.24.0. Trois familles : le cadrage, la performance rayonnée et l'intégration du module, la vie après la certification. Des versions antérieures de cette page donnaient des pertes en dB, des dimensions de PCB et des valeurs de condensateurs qu'aucun document PTCRB ne contient ; elles ont été supprimées, et la dernière section les recense.

Les douze pièges en un coup d'œil

#	Piège	Clause qui l'attrape
1	Prendre la PTCRB pour l'approbation américaine, ou la FCC pour une option	PPMD 1.1, 11.3.1.8
2	Concevoir sur une technologie que la PTCRB ne couvre plus	PPMD 1.1, historique des révisions V4.0
3	Soumettre un produit IoT par le mauvais parcours	PPMD 11.3.1.3, définition du Certified Chipset
4	Choisir les bandes sur la foi de rumeurs plutôt que du PVG.11	NAPRD03 2.8, 2.11
5	Supposer que le module couvre la performance rayonnée	NAPRD03 2.9, 2.9.1, 2.9.2
6	Une seule antenne de réception sur un appareil LTE de catégorie 1 ou plus	NAPRD03 2.9.4
7	Changer l'antenne après la certification	PPMD 11.6.4, 11.6.4.2
8	Changer de révision de module sans revue	PPMD 11.6.4.1, 11.6.4.2
9	Se tromper sur les règles IMEI et TAC	PPMD 8.1 à 8.6, 11.4.3.8
10	Livrer un firmware sans ECO ni nouveau SVN	PPMD 8.2.1, 11.3.2, 11.6.1, 10.1
11	Ajouter des bandes ou des fonctions par logiciel comme si c'était gratuit	PPMD 11.6.10
12	Laisser dériver la version de NAPRD03	PPMD 5.2.1, 5.2.2, 11.7, 11.11.2

Famille 1 : erreurs de cadrage

1 : Prendre la PTCRB pour l'approbation américaine, ou la FCC pour une option

La PTCRB est une certification industrielle administrée par CTIA Certification, pas une règle publique : le PPMD 1.1 qualifie le processus de « recommandé » pour les fabricants dont les appareils sont destinés à fonctionner sur les réseaux des opérateurs participants. L'exigence légale aux États-Unis est l'autorisation d'équipement FCC selon le 47 CFR Part 2, Subpart J (ISED au Canada).

Les deux sont liées dans un seul sens. Le PPMD 11.3.1.8 exige un FCC Grant couvrant toutes les technologies et toutes les bandes de fréquences prises en charge par l'appareil, selon les parties applicables du règlement (le PPMD cite les Parts 22H, 24E, 27, 90 et 30), et le FCC ID doit être saisi dans la demande PTCRB avant l'obtention de la certification PTCRB. Le Canada fonctionne de la même façon avec un certificat d'acceptation technique ISED.

Comment l'éviter : lancer les certifications FCC et ISED assez tôt pour que leurs identifiants existent à la clôture du dossier PTCRB, et vérifier que le grant couvre toutes les bandes qui seront activées sur l'appareil.

2 : Concevoir sur une technologie que la PTCRB ne couvre plus

Le PPMD V4.2 couvre les appareils UTRA, E-UTRA (y compris LTE-M et NB-IoT), NTN et NR (section 1.1). Les exigences GSM ont été retirées dans le PPMD V4.0 (octobre 2025), et les exigences d'émissions parasites rayonnées GERAN et UTRA dans la V4.1 (décembre 2025). Les bandes UTRA II et V restent des bandes PTCRB dans le NAPRD03 V6.26. Côté réseau, T-Mobile indique avoir arrêté son réseau 3G UMTS le 1er juillet 2022 et avoir fixé l'arrêt de son réseau 2G GSM au 3 août 2026.

Comment l'éviter : bâtir un produit à longue durée de vie sur l'E-UTRA (LTE-M, NB-IoT ou catégories supérieures) ou le NR, et vérifier la feuille de route réseau de chaque opérateur cible avant de s'appuyer sur une technologie d'accès ancienne.

3 : Soumettre un produit IoT par le mauvais parcours

Depuis le PPMD V4.0, « à l'exception des notebooks et des tablettes, les appareils intégrant un module ou un modem embarqué sont soumis à la certification IoT Network Certified » (PPMD 11.3.1.3). Un modem embarqué est toujours soumis comme IoT Device. Prévoir une « certification produit PTCRB allégée » pour un produit IoT sur module certifié, c'est prévoir un parcours qui n'existe plus.

Deux pièges voisins :

• Les résultats d'un Certified Chipset ne peuvent être réutilisés que dans un module LTE-M ou NB-IoT, ou dans un produit IoT prenant en charge le NB-IoT ou le LTE-M. Ils ne peuvent pas l'être pour les smartphones, feature phones, notebooks, tablettes ou produits IoT LTE de catégorie 1 et plus (PPMD, définition du Certified Chipset).
• Un module FR2 n'exécute que les cas d'essai protocolaires FR2 ; les essais FR2 RF, de performance et RRM passent au produit final (PPMD 11.9.2).

Comment l'éviter : choisir le parcours d'après le type d'appareil avant de réserver le laboratoire. La page procédure donne le tableau des parcours et des frais.

4 : Choisir les bandes sur la foi de rumeurs plutôt que du PVG.11

Les bandes PTCRB sont celles du tableau 2.8-1 du NAPRD03 V6.26, et le PVG.11 est la source normative : en cas de conflit, le PVG.11 prévaut (NAPRD03 2.8). Les listes de bandes copiées d'anciens guides sont souvent fausses :

Raccourci courant	Ce que disent le PVG.11 V5.24.0 et le NAPRD03 V6.26
« AT&T utilise la B17 »	La bande 17 n'est pas une bande PTCRB ; la bande 12 l'est, soutenue par AT&T, Bell, EchoStar, FirstNet, Rogers, Telus et T-Mobile
« B13 chez Verizon »	La bande 13 est soutenue par Bell, Eastlink et Telus ; Verizon n'est nommé sur aucune bande simple
« B71 chez T-Mobile »	La bande 71 est soutenue par Eastlink, Rogers et T-Mobile, et le tableau 5 du PVG.11 la marque comme normalisée pour le NB-IoT mais pas pour le LTE-M
« n66 multi-opérateur »	Exact : la n66 est soutenue par AT&T, Bell, Eastlink, EchoStar, FirstNet, Rogers, Telus et T-Mobile

Un second piège de bandes se présente au moment des essais : la certification « est conduite avec toutes les bandes de fréquences activées selon les capacités de l'appareil », et les appareils « ne doivent pas être reconfigurés pour les besoins des essais » (NAPRD03 2.11). Une bande laissée active dans le firmware est une bande testée.

Comment l'éviter : prendre le jeu de bandes dans le PVG.11 pour vos opérateurs cibles, vérifier les colonnes LTE-M et NB-IoT si vous concevez un produit LTE-M ou NB-IoT, et figer les bandes activées avant les essais. Les tableaux complets des bandes et des opérateurs sont sur la page périmètre. Les programmes opérateurs qui s'ajoutent à la PTCRB (AT&T, Verizon, T-Mobile) sont une vérification distincte : la page « Get Certified » de ptcrb.com demande aux fabricants de vérifier si l'appareil doit passer des essais supplémentaires propres à un opérateur.

Famille 2 : performance rayonnée et intégration du module

5 : Supposer que le module couvre la performance rayonnée

« L'évaluation de la performance RF est une exigence obligatoire pour tous les types d'appareils passant par la certification PTCRB ou IoT Network Certified » (NAPRD03 2.9). Le plan d'essai est la version du CTIA Certification Test Plan for Wireless Device Over-the-Air Performance en vigueur au moment du dépôt de la demande. Le certificat du module ne couvre ni votre boîtier, ni l'emplacement de l'antenne, ni l'enveloppe du produit.

Le NAPRD03 ne fixe aucune valeur de TRP ou de TIS qui lui soit propre. Ce qu'il fixe :

• Pour les appareils non IoT, le fabricant « consulte le ou les opérateurs cibles pour déterminer s'ils ont des exigences OTA propres » (2.9.1).
• Pour les produits IoT, trois questions du tableau 2.9.2-1 (plus de 100 Ko par transaction, plus de 24 transactions par jour en moyenne, orientation fixe par rapport à l'horizon) déterminent l'étendue des essais OTA. Avec trois réponses « Non », le TRP est mesuré sur tous les canaux, le TIS sur le canal médian au-dessus de 1 GHz et sur les canaux bas, médian et haut en dessous de 1 GHz ; un appareil à orientation fixe passe à la place les essais NHPRP et NHPIS ±30° (2.9.2).
• Un produit IoT est testé dans sa technologie d'accès de plus haut rang, dans toutes les bandes de cette technologie (2.9.2).

Comment l'éviter : répondre aux trois questions du tableau 2.9.2-1 dès la conception, demander aux opérateurs cibles leurs exigences OTA, et faire des pré-mesures sur le boîtier définitif avant la session OTA formelle.

6 : Une seule antenne de réception sur un appareil LTE de catégorie 1 ou plus

Le NAPRD03 2.9.4 rappelle que, selon la 3GPP TS 36.306, les appareils LTE de catégorie 1 et plus doivent prendre en charge deux antennes, à l'exception de la catégorie 1bis. Un appareil qui ne peut pas prendre en charge l'antenne secondaire doit déposer une demande de dérogation (waiver) ; si elle est approuvée, le laboratoire Primary coche la case « LTE Single-Antenna Receiver ». Cette vérification s'applique à tous les appareils, qu'ils passent ou non des essais OTA.

Comment l'éviter : décider du nombre d'antennes en même temps que de la catégorie LTE. Une conception à antenne unique convient au LTE-M, au NB-IoT ou à la catégorie 1bis ; pour la catégorie 1 et plus, prévoir la seconde antenne ou la dérogation.

7 : Changer l'antenne après la certification

Pour tout ECO avec changement d'antenne, le laboratoire Primary décide si des essais TRP, C-TIS, TIS, RSE, NHPRP ou NHPIS sont nécessaires, et si des essais OTA complets ou des contrôles ponctuels suffisent (PPMD 11.6.4). Pour un ECO de produit IoT, une revue par le laboratoire est toujours requise si « l'antenne utilisée dans l'ECO a changé de quelque façon que ce soit par rapport à celle du Parent » (11.6.4.2).

Si des essais rayonnés sont nécessaires, la règle des 2 dB s'applique : le TRP de l'ECO ne peut pas être inférieur de plus de 2 dB à celui du Parent, et son TIS ou C-TIS ne peut pas lui être supérieur de plus de 2 dB ; la même règle vaut pour le NHPRP et le NHPIS lorsqu'ils remplacent le TRP et le TIS (11.6.4.2). C'est le seul chiffre en dB que les documents PTCRB associent à un changement d'antenne.

Comment l'éviter : traiter tout changement d'antenne (référence, câble, emplacement, adaptation) comme un ECO, et comparer les pré-mesures au Parent avant le dépôt.

8 : Changer de révision de module sans revue

Lorsqu'un module passe un ECO, son laboratoire Primary évalue si les produits IoT utilisant des versions antérieures du module doivent être testés pour utiliser la nouvelle (PPMD 11.6.4.1). Côté produit IoT, une revue par le laboratoire est toujours requise si une révision du module postérieure à celle du Parent indique que des essais sont nécessaires, ou si l'ECO utilise une révision de module plus ancienne que celle du Parent (11.6.4.2). Seule une modification limitée au logiciel du produit IoT, sans effet sur les exigences d'essai du 11.10.3, ne demande aucune revue de laboratoire.

Comment l'éviter : suivre la révision du module dans chaque configuration produit, lire l'évaluation d'ECO du module quand le fournisseur le modifie, et ne jamais revenir à une révision de module plus ancienne sans revue du laboratoire.

Un cas concret de l'intégration d'un module cellulaire PTCRB-certifié dans un produit IoT ? AESTECHNO peut auditer votre conception et votre plan de certification. Nous contacter

Famille 3 : erreurs post-certification

9 : Se tromper sur les règles IMEI et TAC

L'IMEI est « un code unique à 15 chiffres » (PPMD 8.1). Le Reporting Body attribue le TAC, le fabricant affecte les six chiffres de série à chaque unité, et le chiffre de contrôle utilise la formule de Luhn sur les 14 premiers chiffres (3GPP TS 23.003). Les règles qui font trébucher les projets :

Règle	PPMD V4.2
Un IMEI de test (Reporting Body Identifier 00) est réservé aux essais de prototypes, « pourrait être mis sur liste noire après les essais » et ne peut pas servir à la certification finale	8.1, 8.3.2
Le matériel final du rapport d'essai doit porter un IMEI de production	11.4.3.8
Un TAC de production commence par 01 et couvre 1 000 000 d'unités ; au-delà, un TAC supplémentaire	8.1, 8.2.10
Un TAC ne peut pas être partagé entre plusieurs références, sauf si les opérateurs l'admettent pour des modèles commercialisés comme un seul, distingués par le SVN	8.2
Une demande de TAC est réservée 120 jours, puis révoquée si l'appareil n'est pas certifié	8.6
Le fabricant de module tient la correspondance entre chaque IMEI et le fabricant ou distributeur destinataire ; l'intégrateur de notebook ou de tablette tient la correspondance entre référence et IMEI ; les deux à disposition des opérateurs sur demande	8.2.2.2

Comment l'éviter : demander le TAC de production à l'approche de la campagne d'essais, puisque la réservation tombe après 120 jours sans certification, enregistrer chaque numéro de série affecté dans une base de production qui refuse les doublons, calculer automatiquement le chiffre de Luhn, et ne jamais livrer une unité avec un IMEI de test.

10 : Livrer un firmware sans ECO ni nouveau SVN

Un ECO est requis pour toute modification du matériel ou de la version matérielle, toute modification de la pile radio ou protocolaire qui change la version logicielle ou le SVN, et toute recompilation de la pile radio ou protocolaire (PPMD 11.6.1). Le SVN doit être mis à jour quand le logiciel radio ou protocolaire change ou est recompilé « pour quelque raison que ce soit », et révisé dans un ordre croissant et séquentiel (8.2.1). Les correctifs de sécurité seuls sur le composant de la pile radio, et les modifications de la seule MMI sans effet sur les fonctions radio ou protocolaires, n'exigent pas de SVN unique (11.6.1, exemples 3 et 4).

Un logiciel chargé par FOTA doit être identique bit à bit au logiciel certifié ; sinon il doit lui-même être certifié (11.3.2). Modifier sciemment un appareil certifié d'une façon qui touche ses exigences de certification ou la performance réseau sans le recertifier est une violation de certification, et CTIA Certification peut retirer la certification (10.1).

Comment l'éviter : lier le processus de livraison logicielle au SVN : toute version qui touche la pile radio ou protocolaire reçoit un nouveau SVN et une demande d'ECO avant d'être poussée par FOTA.

11 : Ajouter des bandes ou des fonctions par logiciel comme si c'était gratuit

Le PPMD 11.6.10 limite ce qu'un ECO peut modifier :

• des bandes et des fonctions peuvent être ajoutées ou retirées par ECO seulement si elles sont activées par une mise à jour logicielle, avec un SVN mis à jour ;
• les capacités voix (voix commutée par circuit, VoLTE, VoNR) ne peuvent jamais être activées ou désactivées par ECO ;
• un changement de bande ou de fonction qui exige une modification matérielle correspondante passe par le processus Variant, avec un nouveau nom ou numéro de modèle ;
• activer une nouvelle technologie (3G, 4G, 5G) constitue une nouvelle plateforme et exige une Initial Certification.

Cette section ne s'applique pas aux IoT Devices : leurs règles de changement de bandes et de fonctions figurent dans le guide How to Get IoT Network Certified.

Comment l'éviter : décider du jeu voix et des technologies d'accès dès la première certification ; planifier un déverrouillage ultérieur de bande comme un ECO purement logiciel, et consulter le guide IoT Network Certified si le produit est un IoT Device.

12 : Laisser dériver la version de NAPRD03

« Le NAPRD03 sera publié quatre fois par an » (PPMD 5.2.1). Un appareil doit exécuter les essais applicables de l'une des deux versions les plus récentes du NAPRD03 (5.2.2), appréciées à la date du téléversement des rapports d'essai (11.7). Une campagne qui court sur plus de deux publications doit passer à une version plus récente. Au 7 octobre 2026, la version en vigueur est le NAPRD03 V6.26. Le PPMD lui-même peut être publié à tout moment, et chaque nouvelle version remplace toutes les précédentes dès sa publication (5.3).

Le PPMD ne fixe aucune date d'expiration pour la certification d'un appareil. Sa seule règle de trois ans concerne les modules intégrés dans des plateformes notebook et tablette : la version de NAPRD03 utilisée pour certifier le module reste valable pour de nouvelles plateformes pendant trois ans à compter de la dernière certification du module ayant exigé des essais, si le logiciel du module n'a pas changé ; ensuite, le module doit être recertifié selon le dernier NAPRD03 (11.11.2).

Comment l'éviter : noter la version de NAPRD03 dans le plan d'essai, suivre les publications trimestrielles pendant les essais, et traiter la recertification comme déclenchée par les modifications (ECO), pas par le calendrier.

Affirmations que les textes contredisent

Affirmation (y compris sur des versions antérieures de cette page)	Ce que disent les documents
« B12/B17 pour AT&T, B13 pour Verizon »	La bande 17 ne figure ni au tableau 2.8-1 du NAPRD03 V6.26 ni dans le PVG.11. Le PVG.11 cite Bell, Eastlink et Telus pour la bande 13 ; Verizon n'est nommé sur aucune bande simple
« Une antenne PCB compacte dégrade le TRP et le TIS de 3 à 6 dB »	Aucun document PTCRB ne donne ce chiffre. Les seuls chiffres en dB sont la règle des 2 dB par rapport au Parent pour un ECO de produit IoT (PPMD 11.6.4.2) et le seuil de ±1 dB de puissance conduite pour se dispenser d'OTA sur un ECO (NAPRD03 2.9.3)
« Respecter les antennes listées dans l'Integration Guide du module » comme règle PTCRB	Ni le PPMD V4.2 ni le NAPRD03 V6.26 ne mentionnent d'Integration Guide ; le produit final est jugé sur ses propres résultats OTA (NAPRD03 2.9)
« Prévoir un PCB d'au moins 60 mm pour les bandes basses » et un filtrage « 100 µF + 10 µF + 100 nF + ferrite »	Aucun document PTCRB ne fixe de règle de plan de masse, de taille de PCB ou de filtrage d'alimentation. L'EVM est un essai RF conduit 3GPP (TS 36.521-1, 6.5.2.1) exécuté sur l'appareil comme les autres
« Les modules dissipent 2 à 5 W et brident leurs performances »	Aucun document PTCRB ne contient d'exigence ni de chiffre thermique ; l'affirmation a été supprimée
« Le NAPRD03 évolue plusieurs fois par an »	Quatre fois par an, selon le calendrier des réunions du PTCRB Working Group (PPMD 5.2.1)
« Une certification de plus de trois ans peut exiger une recertification »	Le PPMD ne prévoit aucune expiration de la certification d'un appareil ; la règle de trois ans porte sur la validité NAPRD03 d'un module utilisé dans de nouvelles plateformes notebook ou tablette (11.11.2)
« Beaucoup d'essais FCC et PTCRB sont partageables »	Aucun document PTCRB ne prévoit une telle réutilisation ; la PTCRB repose sur les spécifications de conformité 3GPP et les plans d'essai CTIA, la FCC sur les parties du 47 CFR
« La PTCRB n'est que la première étape avant chaque opérateur »	La PTCRB est recommandée (PPMD 1.1) ; tout programme supplémentaire relève du choix de chaque opérateur, et les produits IoT sur module passent désormais par IoT Network Certified
Objectifs de maturité tels que « demande d'ECO sous 8 semaines » ou « résolution des incidents opérateur sous 30 jours »	Aucun document PTCRB ne fixe ces objectifs ; ils ont été supprimés, de même que la procédure d'incident opérateur, qui ne repose sur aucune clause PTCRB

En résumé

Les douze pièges PTCRB se répartissent en trois familles :

1. Cadrage (1 à 4) : FCC ID exigé avant l'attribution, technologie que la PTCRB ne couvre plus, mauvais parcours pour un produit IoT, bandes non tirées du PVG.11.
2. Performance rayonnée et intégration (5 à 8) : OTA obligatoire pour tous les types d'appareils, deux antennes dès la catégorie LTE 1, règle des 2 dB sur les changements d'antenne, revue des révisions de module.
3. Post-certification (9 à 12) : règles IMEI et TAC, discipline SVN et ECO, changements de bandes purement logiciels, cycle trimestriel du NAPRD03.

Pour la mise en pratique, voir Procédure PTCRB et Tests. Le dossier technique liste le contenu de la demande, le périmètre donne les tableaux de bandes et la FAQ les questions courantes.

Voir aussi

• Règles de substitution de composants : comment les changements BOM déclenchent des tests delta PTCRB.
• Gestion des changements et FCC class II permissive : garder FCC et PTCRB alignés quand la conception évolue.
• Conception d'antennes et adaptation d'impédance : erreurs antenne typiques derrière les échecs OTA PTCRB.
• Réponse à un rappel et Safety Gate : gestion d'un incident cellulaire post-marché sur les réseaux opérateurs.
• Opérateurs Japon : NTT DOCOMO, KDDI, SoftBank : pièges côté opérateur à anticiper au-delà de PTCRB.
• Vue d'ensemble PTCRB : qui certifie, documents en vigueur, frais officiels.
• FCC ID, titulaire et TCB : le FCC ID qui doit figurer dans la demande PTCRB.

Sources & références

1. PTCRB, Get Certified (processus et documents d'exigences), PTCRB / CTIA www.ptcrb.com/get-certified/
2. PTCRB Program Management Document (PPMD) V4.2, octobre 2026, CTIA Certification www.ptcrb.com/wp-content/uploads/2026/10/PTCRB-PPMD-V4.2.pdf
3. PTCRB NAPRD03 V6.26, octobre 2026, CTIA Certification www.ptcrb.com/wp-content/uploads/2026/10/NAPRD03-V6.26.pdf
4. PVG.11 V5.24.0, bandes PTCRB et opérateurs qui les soutiennent (XLSX), CTIA Certification www.ptcrb.com/wp-content/uploads/2026/10/PVG-11-V-5.24.0.xlsx
5. IoT Network Certified, CTIA Certification iotnetworkcertified.com/
6. eCFR, 47 CFR Part 2 Subpart J, procédures d'autorisation des équipements, Gouvernement des États-Unis (eCFR) www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-2/subpart-J
7. 3GPP TS 23.003, Numbering, addressing and identification, 3GPP www.3gpp.org/ftp/Specs/archive/23_series/23.003/
8. T-Mobile, évolution du réseau (dates clés), T-Mobile www.t-mobile.com/support/coverage/t-mobile-network-evolution