Tehran telecom disruption on February 28, 2026: Cell Broadcast, RAN and signaling technical analysis

On February 28, 2026, an unprecedented combination of military strikes, Internet blackout and localized radio disruptions hit Tehran. Multiple sources report phones displaying “busy” near Pasteur Street, and no Cell Broadcast alert was received by the population.

At HiCellTek, we analyze mobile networks daily — layer by layer, from Layer 1 to IMS. Here is our technical breakdown of what may have happened, and most importantly, what every operator should verify in their own infrastructure to anticipate a similar scenario.

---

Timeline of events

Before diving into the technical analysis, let’s establish the facts as reported by open sources (Reuters, NetBlocks, Cloudflare Radar, international press).

Confirmed facts

• Massive Internet blackout: connectivity dropped to approximately 4% of normal levels, measured by independent monitoring organizations. A significant portion is attributable to intentional restriction, with a possible component of infrastructure damage (fiber, power).

• Localized radio disruption: reports (via Financial Times) describe the disruption of components on approximately a dozen cell towers near Pasteur Street, producing a “busy when called” effect.

• Concurrent cyberattacks: a wave of cyber operations targeting Iranian websites and applications was reported from March 1.

---

Understanding the “busy signal”: it’s not what you think

When a call returns a “busy” signal, intuition says the other party is on the phone. In reality, in mobile networks, a “busy” can mask a dozen very different technical causes.

The 3 inaccessibility scenarios in a crisis context

When a call returns “busy” during a network incident, three major scenarios emerge. Each occurs at a different layer and leaves distinct traces.

Scenario 1 — Jamming / RF Interference

A jammer or powerful interference source drowns out the useful radio signal. The terminal can no longer decode system information (MIB/SIB), the RACH procedure fails, and no RRC connection is established. The user perceives an immediate rejection or a “busy” tone.

Impacted layer: RAN — physical layer (L1) Technologies affected: 2G, 3G, 4G, 5G simultaneously if wideband jamming Observables: sudden RSRP/RSRQ drop, BLER > 30%, RLF spikes, cell selection/reselection failure

Scenario 2 — Radio congestion 2G-3G-4G

In a crisis situation, thousands of users try to call simultaneously. Radio resources become exhausted:

• 2G (GSM): TCH and SDCCH channel saturation, RACH overload
• 3G (UMTS): spreading code shortage (scrambling codes), RRC Connection rejection
• 4G (LTE): PRACH contention, RRC Connection Setup failure cause “congestion”, PRB (Physical Resource Blocks) saturation

Impacted layer: RAN — layers 2/3 (MAC, RRC) Observables: RRC failure rate > 5%, E-RAB Setup Failure increase, rejections with “congestion” cause in eNodeB counters

Scenario 3 — MSC / IMS routing failure

Radio access works, the terminal is connected to the network, but the core network cannot route the call:

• Circuit network (2G/3G via MSC): ISUP Release with cause 34 (no circuit/channel available) or cause 42 (switching equipment congestion)
• IMS network (VoLTE/VoNR): SIP 503 (Service Unavailable) or SIP 480 (Temporarily Unavailable) response from P-CSCF or S-CSCF

Impacted layer: Core CS/PS + IMS Observables: Call Setup Success Rate drop, specific rejection codes in NAS/SIP traces, Diameter S6a timeouts

”Busy signal” cause summary

Scenario	Network layer	Technical cause	Result for the caller
Jamming / Interference	RAN — physical layer	RF signal drowned, RACH impossible	”Busy” or “unreachable”
Radio congestion 2G-3G-4G	RAN — MAC/RRC layers	Resources exhausted (TCH, codes, PRB)	Rejection presented as “busy”
MSC / IMS routing failure	Core CS/PS + IMS	MSC overloaded, SIP 503/480	Busy tone
Cells turned off / barred	RAN (admin)	Cell barred, ACB activated	Systematic “busy”
Backhaul cut (fiber/MW)	Transport	Isolated cell, paging impossible	”Unreachable”

The mapping between technical cause and the tone heard by the caller depends on the operator’s implementation (ISUP/IMS) — it is not standardized. A simple “busy” alone never allows one to conclude on the nature of the failure.

The HiCellTek tool enables exactly this type of diagnosis: transforming a field perception (“it rings busy”) into actionable data — “paging failure cause X”, “cell barred”, “SIP 503”, “S1AP overload”.

---

Cell Broadcast architecture: why alerts didn’t work

Iran tested a mobile alert system via Cell Broadcast (CBS/PWS) in late 2025. On February 28, no alert was received. Here is the architecture involved and the 5 possible break points.

How Cell Broadcast (PWS/CBS) works

Cell Broadcast is standardized by 3GPP (TS 23.041, TS 29.168). Unlike SMS which is point-to-point, CBS broadcasts a message to all terminals in a geographic area, without network congestion.

flowchart TD
    subgraph AUTH ["ALERT AUTHORITY"]
        CBE["CBE — Cell Broadcast Entity"]
    end
    subgraph CORE ["CORE NETWORK"]
        CBC["CBC — Cell Broadcast Centre"]
        MME["MME / AMF — 4G EPC / 5G Core"]
    end
    subgraph RAN_ZONE ["RADIO ACCESS NETWORK — RAN"]
        ENB["eNodeB / gNodeB — Base stations"]
    end
    subgraph TERM ["TERMINALS"]
        UE1["Smartphone 1"]
        UE2["Smartphone 2"]
        UE3["Smartphone 3"]
    end
    CBE -->|"Alert order"| 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

The 5 break points of Cell Broadcast

Each link in this chain is a potential failure point. Here are the 5 scenarios that can explain the absence of CBS alerts:

flowchart LR
    A["1. Non-triggering"]:::orange --> RESULT["NO CBS ALERT RECEIVED"]:::red
    B["2. CBC unavailable"]:::orange --> RESULT
    C["3. SBc/N50 interface broken"]:::orange --> RESULT
    D["4. MME/AMF unavailable"]:::orange --> RESULT
    E["5. RAN out of 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-triggering (doctrine): in a crisis situation with information control, authorities may prefer other channels (mass SMS, national radio, media) or choose not to push CBS. The Internet blackout context suggests intentional restrictions.

Point 2 — CBC unavailable: the Cell Broadcast Centre server may be down (power outage, cyber incident, maintenance).

Point 3 — SBc/N50 interface broken: the link from CBC to MME (4G) or to AMF (5G) via SCTP can be cut by network segmentation or “intranet” isolation.

Point 4 — MME/AMF unavailable: if the core network is saturated or partially down, injecting the alert message is impossible.

Point 5 — RAN out of service: if base stations around Pasteur Street are turned off (power, backhaul, jamming, sabotage), no CBS broadcast is possible on these cells. CBS may exist at the national level, but will not be received in the critical zone.

---

The 6 technical hypotheses: comparison

Open source analysis does not allow isolating a single cause. Here are the 6 plausible scenarios, with their prerequisites and expected traces.

flowchart TD
    A["O&M/OSS access or physical action"]:::blue --> B["Cell state change Pasteur Street"]:::purple
    B --> C["Attach / paging failures / congestion"]:::purple
    C --> D["Calls perceived busy or rejected"]:::red
    A --> E["PWS/CBS chain unavailable or not triggered"]:::purple
    E --> F["No Cell Broadcast alerts"]:::red
    G["National Internet blackout"]:::orange --> E
    G --> H["Apps and messaging out of 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

Scenario comparison table

Hypothesis	Access required	Operator traces	Field traces	Priority measures
Regulatory shutdown (Internet + services)	Authority / regulator	BGP withdraw, ACL core, MICT logs	Internet/apps down	PWS redundancy, continuous testing
Fiber/power damage	Kinetic / sabotage	Backhaul down alarms, isolated sites	Sites off-air, degraded coverage	Physical protection, power redundancy
Jamming / EW	Proximity + EW assets	RLF/RRC fail increase	RF noise, RSRP/RSRQ anomalies	RF detection, jammer geolocation
Admin shutdown (O&M)	IT/OSS compromise	Config change, admin jobs	Cells barred, ACB modified	RBAC, MFA, OAM segmentation
RAN vulnerability	OAM network access	NE crash/restart	Reboots, OAM alarms	PSIRT patches, microsegmentation
Signaling attack (SS7/Diameter)	Interconnect / roaming	Abnormal MAP/Diameter traces	Various UE effects	SS7/Diameter/GTP firewalls

---

Forensic playbook: where to look for evidence

For NOC/SOC teams and network engineers facing a similar incident, here are the traces to collect as a priority, layer by layer.

RAN layer

• “Cell out of service”, “backhaul down”, “power/rectifier/battery” alarms
• RRC counters: Connection Setup Failures, Radio Link Failures, HO failures
• E-RAB / PDU Session setup failure counters
• Baseband unit crash dumps and restart reasons

Core layer (4G/5G)

• S1-AP (SCTP): resets, association down, release cause, overload indications
• NG-AP (SCTP): same patterns on the 5G/AMF side
• Diameter S6a/S6d: auth errors, timeouts, UpdateLocation/CancelLocation bursts
• GTPv2-C / GTPv1-U: TEID losses, Error Indication bursts, bearer setup drops

IMS layer (VoLTE/VoNR)

• E-CSCF/P-CSCF logs: emergency registration failures, PSAP routing errors
• SIP rejection codes (403, 480, 503, 504)
• LRF/location errors for emergency calls

PWS/CBS layer

• CBC/CBCF/PWSIWF logs: broadcast requests, ACK/NACK, timeouts
• SBc interface (CBC to MME): SCTP associations, SBc-AP errors
• N50 interface (CBC to AMF) for 5G networks

Recommended Wireshark filters

Protocol	Layer	Wireshark filter
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)	Signaling	sctp && (m3ua || sua)
Cell Broadcast (SBc-AP)	CBC ↔ MME	sctp && (ip.addr==<CBC_IP> || ip.addr==<MME_IP>)

SIEM queries (Splunk/Elastic)

S1-AP correlation — incidents by eNodeB

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

Diameter — authentication errors

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

PWS/CBS — broadcast attempts

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

---

What this incident teaches us

For operators

1. Test Cell Broadcast under degraded conditions — not only under normal conditions. A CBS test that works on a healthy network guarantees nothing when the backhaul is cut or the core is saturated.

2. Secure the O&M/OSS chain — strict RBAC, MFA, OAM network segmentation, immutable logs. The majority of attack scenarios require pre-existing management access.

3. Correlate across layers — a “busy signal” seen from the field must be correlated with RAN counters, core traces, and IMS logs to identify the true cause.

For field engineers

The gap between what the end user perceives and what is actually happening in the network is considerable. A “phone busy” can mean:

• An administratively barred cell
• A paging failure due to congestion
• A SIP 503 response (IMS overloaded)
• Localized RF jamming

Without a protocol diagnostic tool on the terminal, it is impossible to determine the cause.

---

Synthesis

flowchart TD
    FACT1["Massive Internet blackout — 96% loss"]:::blue --> ANALYSIS["Superposition of causes"]:::purple
    FACT2["Disrupted towers — Pasteur Street"]:::orange --> ANALYSIS
    FACT3["No CBS alert received"]:::red --> ANALYSIS
    ANALYSIS --> CONCL1["Non-exploit scenarios: power / backhaul / jamming"]:::green
    ANALYSIS --> CONCL2["Exploit-adjacent: pre-existing O&M access"]:::green
    ANALYSIS --> CONCL3["Vendor vulnerability: not demonstrated"]:::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

The state of open sources points to a superposition: intentional Internet blackout + localized radio disruption + absence of CBS (by non-triggering or technical unavailability). The “vendor 0-day vulnerability” hypothesis remains undemonstrated.

What is certain: terminal-level network diagnostic tools are essential to distinguish a simple “busy” from a systemic failure, and to document incidents with actionable protocol evidence.

---

This article is an independent technical analysis based exclusively on open sources (Reuters, NetBlocks, Cloudflare Radar, 3GPP/ETSI standards, PSIRT bulletins). It does not constitute a definitive attribution nor national security advice. The opinions expressed are those of the HiCellTek technical team.