Perturbation télécom à Téhéran le 28 février 2026 : analyse technique Cell Broadcast, RAN et signalisation

Le 28 février 2026, une combinaison inédite de frappes militaires, de blackout Internet et de perturbations radio localisées a frappé Téhéran. Plusieurs sources rapportent des téléphones affichant “occupé” près de Pasteur Street, et aucune alerte Cell Broadcast n’a été reçue par la population.

Chez HiCellTek, nous analysons les réseaux mobiles au quotidien — couche par couche, du Layer 1 au IMS. Voici notre décryptage technique de ce qui a pu se passer, et surtout, ce que chaque opérateur devrait vérifier dans sa propre infrastructure pour anticiper un scénario similaire.

---

Chronologie des événements

Avant d’entrer dans l’analyse technique, posons les faits tels que rapportés par les sources ouvertes (Reuters, NetBlocks, Cloudflare Radar, presse internationale).

Les faits confirmés

• Blackout Internet massif : la connectivité est tombée à environ 4% du niveau habituel, mesurée par des organismes de monitoring indépendants. Une part significative relève d’une restriction intentionnelle, avec une composante possible de dégâts sur les infrastructures (fibre, alimentation).

• Perturbation radio localisée : des reportages (via Financial Times) décrivent la perturbation de composants d’environ une douzaine de tours cellulaires proches de Pasteur Street, produisant un effet “busy when called”.

• Cyberattaques concomitantes : une vague d’opérations cyber visant des sites et applications iraniens a été rapportée dès le 1er mars.

---

Comprendre le “busy signal” : ce n’est pas ce que vous croyez

Quand un appel retourne un signal “occupé”, l’intuition dit que le correspondant est en ligne. En réalité, dans les réseaux mobiles, un “busy” peut masquer une dizaine de causes techniques très différentes.

Les 3 scénarios d’inaccessibilité en contexte de crise

Quand un appel retourne “occupé” lors d’un incident réseau, trois grands scénarios se distinguent. Chacun intervient à une couche différente et laisse des traces distinctes.

Scénario 1 — Brouillage / Interférence RF

Un brouilleur (jammer) ou une source d’interférence puissante noie le signal radio utile. Le terminal ne peut plus décoder les informations système (MIB/SIB), la procédure RACH échoue, aucune connexion RRC n’est établie. L’utilisateur perçoit un rejet immédiat ou une tonalité “occupé”.

Couche impactée : RAN — couche physique (L1) Technologies affectées : 2G, 3G, 4G, 5G simultanément si le brouillage est large bande Observables : chute brutale RSRP/RSRQ, BLER > 30%, pics de RLF, échec cell selection/reselection

Scénario 2 — Congestion radio 2G-3G-4G

En situation de crise, des milliers d’utilisateurs tentent d’appeler simultanément. Les ressources radio s’épuisent :

• 2G (GSM) : saturation des canaux TCH et SDCCH, surcharge RACH
• 3G (UMTS) : pénurie de codes d’étalement (scrambling codes), rejet RRC Connection
• 4G (LTE) : contention PRACH, échec RRC Connection Setup cause “congestion”, saturation des PRB (Physical Resource Blocks)

Couche impactée : RAN — couches 2/3 (MAC, RRC) Observables : taux d’échec RRC > 5%, hausse E-RAB Setup Failure, rejets avec cause “congestion” dans les compteurs eNodeB

Scénario 3 — Problème de routage MSC / IMS

L’accès radio fonctionne, le terminal est connecté au réseau, mais le cœur de réseau ne peut pas acheminer l’appel :

• Réseau circuit (2G/3G via MSC) : ISUP Release avec cause 34 (no circuit/channel available) ou cause 42 (switching equipment congestion)
• Réseau IMS (VoLTE/VoNR) : réponse SIP 503 (Service Unavailable) ou SIP 480 (Temporarily Unavailable) renvoyée par le P-CSCF ou S-CSCF

Couche impactée : Core CS/PS + IMS Observables : Call Setup Success Rate en chute, codes de rejet spécifiques dans les traces NAS/SIP, timeouts Diameter S6a

Récapitulatif des causes de “busy signal”

Scénario	Couche réseau	Cause technique	Résultat pour l’appelant
Brouillage / Interférence	RAN — couche physique	Signal RF noyé, RACH impossible	”Occupé” ou “non joignable”
Congestion radio 2G-3G-4G	RAN — couches MAC/RRC	Ressources épuisées (TCH, codes, PRB)	Rejet présenté comme “occupé”
Panne routage MSC / IMS	Core CS/PS + IMS	MSC surchargé, SIP 503/480	Tonalité d’occupation
Cellules éteintes / barrées	RAN (admin)	Cell barred, ACB activé	”Occupé” systématique
Backhaul coupé (fibre/FH)	Transport	Cellule isolée, paging impossible	”Non joignable”

Le mapping entre la cause technique et le son entendu par l’appelant dépend de l’implémentation opérateur (ISUP/IMS) — il n’est pas standardisé. Un simple “busy” ne permet jamais, seul, de conclure sur la nature de la panne.

L’outil HiCellTek permet exactement ce type de diagnostic : transformer un ressenti terrain (“ça sonne occupé”) en données exploitables — “échec paging cause X”, “cell barred”, “SIP 503”, “S1AP overload”.

---

Architecture Cell Broadcast : pourquoi les alertes n’ont pas fonctionné

L’Iran a testé fin 2025 un système d’alertes mobiles via Cell Broadcast (CBS/PWS). Le 28 février, aucune alerte n’a été reçue. Voici l’architecture concernée et les 5 points de rupture possibles.

Comment fonctionne le Cell Broadcast (PWS/CBS)

Le Cell Broadcast est standardisé par le 3GPP (TS 23.041, TS 29.168). Contrairement au SMS qui est point-à-point, le CBS diffuse un message à tous les terminaux d’une zone géographique, sans congestion réseau.

flowchart TD
    subgraph AUTH ["AUTORITÉ D ALERTE"]
        CBE["CBE — Cell Broadcast Entity"]
    end
    subgraph CORE ["CŒUR DE RÉSEAU"]
        CBC["CBC — Cell Broadcast Centre"]
        MME["MME / AMF — 4G EPC / 5G Core"]
    end
    subgraph RAN_ZONE ["RÉSEAU D ACCÈS — RAN"]
        ENB["eNodeB / gNodeB — Stations de base"]
    end
    subgraph TERM ["TERMINAUX"]
        UE1["Smartphone 1"]
        UE2["Smartphone 2"]
        UE3["Smartphone 3"]
    end
    CBE -->|"Ordre alerte"| CBC
    CBC -->|"SBc-AP / N50"| MME
    MME -->|"S1-AP / NG-AP"| ENB
    ENB -->|"Broadcast SIB"| UE1
    ENB -->|"Broadcast SIB"| UE2
    ENB -->|"Broadcast SIB"| UE3
    style CBE fill:#5b5cff,color:#fff,stroke:#4344cc,stroke-width:1px
    style CBC fill:#6366f1,color:#fff,stroke:#4f46e5,stroke-width:1px
    style MME fill:#8b5cf6,color:#fff,stroke:#7c3aed,stroke-width:1px
    style ENB fill:#ff3d8d,color:#fff,stroke:#e11d48,stroke-width:1px
    style UE1 fill:#0f172a,color:#e2e8f0,stroke:#334155,stroke-width:1px
    style UE2 fill:#0f172a,color:#e2e8f0,stroke:#334155,stroke-width:1px
    style UE3 fill:#0f172a,color:#e2e8f0,stroke:#334155,stroke-width:1px
    style AUTH fill:#1e1b4b,stroke:#5b5cff,color:#a5b4fc,stroke-width:1px
    style CORE fill:#1e1b4b,stroke:#8b5cf6,color:#c4b5fd,stroke-width:1px
    style RAN_ZONE fill:#1a0a1e,stroke:#ff3d8d,color:#fda4af,stroke-width:1px
    style TERM fill:#0f172a,stroke:#64748b,color:#94a3b8,stroke-width:1px

Les 5 points de rupture du Cell Broadcast

Chaque maillon de cette chaîne est un point de défaillance potentiel. Voici les 5 scénarios qui peuvent expliquer l’absence d’alertes CBS :

flowchart LR
    A["1. Non-déclenchement"]:::orange --> RESULT["PAS D ALERTE CBS REÇUE"]:::red
    B["2. CBC indisponible"]:::orange --> RESULT
    C["3. Interface SBc/N50 rompue"]:::orange --> RESULT
    D["4. MME/AMF indisponible"]:::orange --> RESULT
    E["5. RAN hors service"]:::orange --> RESULT
    classDef red fill:#ff3d8d,color:#fff,stroke:#e11d48,stroke-width:1px
    classDef orange fill:#f59e0b,color:#fff,stroke:#d97706,stroke-width:1px

Point 1 — Non-déclenchement (doctrine) : en situation de crise et de contrôle informationnel, des autorités peuvent privilégier d’autres canaux (SMS massif, radio nationale, médias) ou choisir de ne pas pousser de CBS. Le contexte de blackout Internet suggère des restrictions intentionnelles.

Point 2 — CBC indisponible : le serveur Cell Broadcast Centre peut être hors service (coupure électrique, incident cyber, maintenance).

Point 3 — Interface SBc/N50 rompue : la liaison CBC vers MME (4G) ou vers AMF (5G) via SCTP peut être coupée par une segmentation réseau ou un isolement “intranet”.

Point 4 — MME/AMF indisponible : si le cœur de réseau est saturé ou partiellement down, l’injection du message d’alerte est impossible.

Point 5 — RAN hors service : si les stations de base autour de Pasteur Street sont éteintes (power, backhaul, jamming, sabotage), aucune diffusion CBS n’est possible sur ces cellules. Le CBS peut exister au niveau national, mais ne sera pas reçu dans la zone critique.

---

Les 6 hypothèses techniques : comparatif

L’analyse des sources ouvertes ne permet pas d’isoler une cause unique. Voici les 6 scénarios plausibles, avec leurs prérequis et les traces attendues.

flowchart TD
    A["Accès O&M/OSS ou action physique"]:::blue --> B["Changement état cellules Pasteur Street"]:::purple
    B --> C["Échecs attach / paging / congestion"]:::purple
    C --> D["Appels perçus busy ou rejetés"]:::red
    A --> E["Chaîne PWS/CBS indispo ou non déclenchée"]:::purple
    E --> F["Pas d alertes Cell Broadcast"]:::red
    G["Blackout Internet national"]:::orange --> E
    G --> H["Apps et messageries hors service"]:::red
    classDef blue fill:#5b5cff,color:#fff,stroke:#4344cc,stroke-width:1px
    classDef purple fill:#8b5cf6,color:#fff,stroke:#7c3aed,stroke-width:1px
    classDef red fill:#ff3d8d,color:#fff,stroke:#e11d48,stroke-width:1px
    classDef orange fill:#f59e0b,color:#fff,stroke:#d97706,stroke-width:1px

Tableau comparatif des scénarios

Hypothèse	Accès requis	Traces opérateur	Traces terrain	Mesures prioritaires
Coupure régulatoire (Internet + services)	Autorité / régulateur	BGP withdraw, ACL core, logs MICT	Internet/apps HS	Redondance PWS, tests continus
Dégât fibre/power	Cinétique / sabotage	Alarmes backhaul down, sites isolés	Sites off-air, couverture dégradée	Protection physique, redondance énergie
Jamming / EW	Proximité + moyens EW	Hausse RLF/RRC fail	Bruit RF, anomalies RSRP/RSRQ	Détection RF, géolocalisation jammers
Shutdown admin (O&M)	Compromission IT/OSS	Config change, jobs admin	Cells barred, ACB modifié	RBAC, MFA, segmentation OAM
Vulnérabilité RAN	Accès réseau OAM	Crash/restart NE	Redémarrages, alarmes OAM	Patch PSIRT, microsegmentation
Attaque signalisation (SS7/Diameter)	Interco / roaming	Traces MAP/Diameter anormales	Effets UE variés	Firewalls SS7/Diameter/GTP

---

Playbook forensique : où chercher la preuve

Pour les équipes NOC/SOC et les ingénieurs réseau qui feraient face à un incident similaire, voici les traces à collecter en priorité, couche par couche.

Couche RAN

• Alarmes “cell out of service”, “backhaul down”, “power/rectifier/battery”
• Compteurs RRC : Connection Setup Failures, Radio Link Failures, HO failures
• Compteurs E-RAB / PDU Session setup failures
• Crash dumps et restart reasons des unités baseband

Couche Core (4G/5G)

• S1-AP (SCTP) : resets, association down, cause de release, overload indications
• NG-AP (SCTP) : mêmes patterns côté 5G/AMF
• Diameter S6a/S6d : erreurs auth, timeouts, bursts UpdateLocation/CancelLocation
• GTPv2-C / GTPv1-U : pertes de TEID, bursts Error Indication, drops bearer setup

Couche IMS (VoLTE/VoNR)

• Journaux E-CSCF/P-CSCF : échecs registration emergency, erreurs routage vers PSAP
• Codes SIP de rejet (403, 480, 503, 504)
• Erreurs LRF/location pour appels d’urgence

Couche PWS/CBS

• Logs CBC/CBCF/PWSIWF : demandes d’émission, ACK/NACK, timeouts
• Interface SBc (CBC vers MME) : associations SCTP, erreurs SBc-AP
• Interface N50 (CBC vers AMF) pour les réseaux 5G

Filtres Wireshark recommandés

Protocole	Couche	Filtre Wireshark
S1-AP (LTE)	RAN ↔ Core	sctp && s1ap
NG-AP (5G)	RAN ↔ Core	sctp && ngap
Diameter (S6a/S6d)	Core (auth)	diameter || tcp.port==3868 || sctp.port==3868
GTP user-plane	Transport	gtp && udp.port==2152
SIGTRAN (M3UA/SUA)	Signalisation	sctp && (m3ua || sua)
Cell Broadcast (SBc-AP)	CBC ↔ MME	sctp && (ip.addr==<CBC_IP> || ip.addr==<MME_IP>)

Requêtes SIEM type (Splunk/Elastic)

Corrélation S1-AP — incidents par eNodeB

sourcetype="s1ap" ("SCTP_ASSOC_DOWN"
  OR "SCTP_RESET" OR "Overload")
| stats count by enb_id mme_id cause

Diameter — erreurs d’authentification

sourcetype="diameter"
  (result_code!=2001 OR error_message=*)
| stats count by peer, app_id, result_code

PWS/CBS — tentatives de broadcast

sourcetype="pws_cbc" ("WRITE_REPLACE"
  OR "STOP_BROADCAST" OR "DELIVERY_FAILED")
| stats count by tai, cell_id, message_id

---

Ce que cet incident nous apprend

Pour les opérateurs

1. Tester le Cell Broadcast en conditions dégradées — pas seulement en conditions normales. Un test CBS qui fonctionne sur un réseau sain ne garantit rien quand le backhaul est coupé ou le cœur saturé.

2. Sécuriser la chaîne O&M/OSS — RBAC strict, MFA, segmentation réseau OAM, journaux immuables. La majorité des scénarios d’attaque nécessitent un accès management préexistant.

3. Corréler les couches — un “busy signal” vu du terrain doit être corrélé avec les compteurs RAN, les traces core, et les logs IMS pour identifier la vraie cause.

Pour les ingénieurs terrain

Le fossé entre ce que perçoit l’utilisateur final et ce qui se passe réellement dans le réseau est considérable. Un “téléphone occupé” peut signifier :

• Une cellule barrée administrativement
• Un échec de paging par congestion
• Une réponse SIP 503 (IMS surchargé)
• Un jamming RF localisé

Sans outil de diagnostic protocolaire sur le terminal, impossible de trancher.

---

Synthèse

flowchart TD
    FACT1["Blackout Internet massif — 96% de perte"]:::blue --> ANALYSIS["Superposition de causes"]:::purple
    FACT2["Tours perturbées — Pasteur Street"]:::orange --> ANALYSIS
    FACT3["Aucune alerte CBS reçue"]:::red --> ANALYSIS
    ANALYSIS --> CONCL1["Scénarios non-exploit : power / backhaul / jamming"]:::green
    ANALYSIS --> CONCL2["Exploit-adjacent : accès O&M préexistant"]:::green
    ANALYSIS --> CONCL3["Vulnérabilité vendor : non démontrée"]:::dark
    classDef blue fill:#5b5cff,color:#fff,stroke:#4344cc,stroke-width:1px
    classDef orange fill:#f59e0b,color:#fff,stroke:#d97706,stroke-width:1px
    classDef red fill:#ff3d8d,color:#fff,stroke:#e11d48,stroke-width:1px
    classDef purple fill:#8b5cf6,color:#fff,stroke:#7c3aed,stroke-width:1px
    classDef green fill:#22c55e,color:#fff,stroke:#16a34a,stroke-width:1px
    classDef dark fill:#0f172a,color:#94a3b8,stroke:#334155,stroke-width:1px

L’état des sources ouvertes pointe vers une superposition : blackout Internet intentionnel + perturbation radio localisée + absence de CBS (par non-déclenchement ou indisponibilité technique). L’hypothèse “vulnérabilité 0-day vendor” reste non démontrée.

Ce qui est certain : les outils de diagnostic réseau au niveau terminal sont essentiels pour distinguer un simple “busy” d’une panne systémique, et pour documenter les incidents avec des preuves protocolaires exploitables.

---

Cet article est une analyse technique indépendante basée exclusivement sur des sources ouvertes (Reuters, NetBlocks, Cloudflare Radar, normes 3GPP/ETSI, bulletins PSIRT). Il ne constitue ni une attribution définitive ni un conseil en sécurité nationale. Les opinions exprimées sont celles de l’équipe technique HiCellTek.