ARCEP 2026 Observatory: 43% Phone Spoofing, BBR Replaces Cubic, and What It Means for Field Diagnostics
Analysis of ARCEP's 2026 observatory on French telecom satisfaction: 43% phone spoofing impact, the shift from Cubic to BBR in speed measurement, SS7/SIP vulnerabilities, and implications for field diagnostic methodology.
ARCEPβs 2026 observatory on telecommunications services quality in France delivers two findings that deserve close attention from network professionals: 43% of French consumers have been affected by phone number spoofing, and ARCEP is shifting its official speed measurement methodology from Cubic to BBR congestion control. Both developments have direct implications for field diagnostics, network measurement accuracy, and the security architecture of mobile voice services.
This article provides a technical analysis of both findings, their interconnection through the signaling layer, and what RF engineers and field teams need to understand about the changing measurement landscape.
The 2026 observatory: key findings
Consumer satisfaction metrics
| Metric | Value | Year-over-Year Change |
|---|---|---|
| Overall telecom satisfaction | 7.9/10 | +0.3 |
| Mobile satisfaction | 7.8/10 | +0.2 |
| Fixed broadband satisfaction | 8.0/10 | +0.4 |
| Orange satisfaction (highest) | 8.1/10 | Stable |
| Free Mobile satisfaction | 7.6/10 | +0.3 |
| SFR satisfaction | 7.5/10 | +0.2 |
| Bouygues Telecom satisfaction | 7.7/10 | +0.2 |
| Improvement over 2 years | +7 points (percentage) | Significant trend |
The 7.9/10 average satisfaction and the 7-point improvement over two years indicate that French operators have materially improved their service quality. Orangeβs leadership at 8.1/10 reflects its infrastructure investment advantage (largest fiber and 4G/5G footprint in France).
Phone spoofing: the 43% statistic
The headline finding: 43% of French consumers report having been affected by phone number spoofing (usurpation de numero / spoofing dβidentite dβappel). This includes:
- Receiving calls displaying a trusted number (bank, government agency, utility) that is actually a scam
- Having their own number spoofed by fraudsters calling third parties
- Receiving SMS from spoofed sender IDs
This 43% figure represents a massive security failure in the telecommunications signaling infrastructure, not in the IP layer or the radio layer, but in the SS7 and SIP signaling layer that routes and identifies voice calls.
Phone spoofing: the signaling vulnerability
How caller ID spoofing works
Phone number spoofing exploits the trust model of the Public Switched Telephone Network (PSTN) and its VoIP successor architecture. The fundamental vulnerability exists at two levels:
SS7-level spoofing (legacy interconnect)
Calling Party SS7 Network Called Party
β β β
βββ IAM (Initial Address βββΊβ β
β Message) with forged β β
β Calling Party Number βββββ IAM forwarded βββββββΊβ
β β with forged CPN β
β β β
β β No verification β
β β of CPN authenticity β
The SS7 Initial Address Message (IAM) carries the Calling Party Number (CPN) field. In the original SS7 architecture (designed in the 1970s-1980s), there is no authentication of the CPN. Any SS7 interconnection point can inject an IAM with any CPN value. This design assumed that all SS7 network participants were trusted telephone companies. That assumption has not held since the deregulation of telecom in the 1990s.
SIP-level spoofing (VoIP/IMS interconnect)
SIP INVITE sip:called@operator.fr SIP/2.0
From: <sip:+33144001234@spoofed-origin.com>;tag=xyz
P-Asserted-Identity: <sip:+33144001234@trusted-carrier.fr>
In SIP-based voice (including VoLTE), the From header and P-Asserted-Identity header carry the calling number. While SIP does support identity assertion mechanisms (P-Asserted-Identity within trusted networks), the trust boundary between operators is frequently insufficient. A rogue SIP trunk provider can inject calls with arbitrary identity headers.
The STIR/SHAKEN response
The industry response to caller ID spoofing is STIR/SHAKEN (Secure Telephony Identity Revisited / Signature-based Handling of Asserted information using toKENs):
| Component | Function | Status in France (2026) |
|---|---|---|
| STIR | Cryptographic framework for signing caller ID | Specification complete (RFC 8224, 8225, 8226) |
| SHAKEN | Governance and certificate authority framework | US: mandatory since 2021. France: voluntary, adoption in progress |
| Attestation Level A | Full attestation: carrier confirms customer identity | Required for direct enterprise connections |
| Attestation Level B | Partial attestation: carrier authenticated call origin, not specific caller | Most inter-carrier calls |
| Attestation Level C | Gateway attestation: carrier received call from gateway, cannot verify origin | International/legacy interconnect |
ARCEPβs 2026 observatory implicitly confirms that STIR/SHAKEN adoption in France remains incomplete. The 43% spoofing impact rate is incompatible with full Attestation A deployment. The French implementation timeline has been slower than the US mandate, largely because:
- The European regulatory framework (EECC) does not mandate STIR/SHAKEN specifically
- French operators interconnect with legacy SS7 networks across Europe, Africa, and the Middle East where no STIR/SHAKEN exists
- The certificate authority governance for European STIR/SHAKEN is still being harmonized
What this means for field diagnostics
Phone spoofing is not a radio problem, but it manifests through the radio network. When field engineers investigate voice quality complaints, the diagnostic workflow must now include signaling verification:
New diagnostic questions for VoLTE:
- Is the P-Asserted-Identity consistent with the SIP From header?
- Does the SIP INVITE carry STIR/SHAKEN attestation headers?
- What attestation level was asserted, and by which certificate authority?
- Are there anomalous SIP headers indicating transit through untrusted intermediaries?
VoLTE diagnostic tools that capture SIP signaling (INVITE, 180 Ringing, 200 OK, BYE) already have the raw data needed to identify spoofing indicators. The analysis layer needs to evolve to flag identity inconsistencies as part of the standard call quality diagnostic.
BBR replaces Cubic: the measurement revolution
Background: what changes and why
ARCEPβs speed measurement methodology has historically used TCP Cubic as the default congestion control algorithm. Cubic, developed at NCSU and adopted as Linuxβs default in 2006, has been the de facto standard for internet speed measurement for nearly two decades.
In the 2026 methodology update, ARCEP signals a shift toward BBR (Bottleneck Bandwidth and Round-trip propagation time), developed by Google and increasingly deployed on major content delivery networks.
Cubic vs. BBR: technical differences
| Characteristic | Cubic | BBR |
|---|---|---|
| Congestion signal | Packet loss | Bandwidth estimation + RTT measurement |
| Behavior on loss | Multiplicative decrease (window reduction) | Models bottleneck bandwidth; less reactive to loss |
| Performance on lossy links | Degrades significantly (e.g., -30% at 1% loss) | Maintains throughput despite moderate loss |
| Performance with bufferbloat | Fills buffers, creates latency | Actively manages inflight data to minimize latency |
| Fairness with Cubic flows | Fair (same algorithm) | BBR can dominate Cubic flows on shared links |
| Mobile network performance | Penalized by radio link retransmissions | Better adapts to variable radio conditions |
| Default on Google servers | No (migrated to BBR) | Yes (YouTube, Google Cloud, etc.) |
| Default on Linux kernel | Yes (since 2006) | Available since 4.9 (2016), increasingly adopted |
The measurement gap: 10-30%
The switch from Cubic to BBR is not a cosmetic change. Field measurements demonstrate a 10-30% throughput difference between the two algorithms on the same network path at the same time:
| Network Condition | Cubic Throughput | BBR Throughput | Difference |
|---|---|---|---|
| Clean path (0% loss, low RTT) | 100 Mbps | 102 Mbps | +2% (negligible) |
| Moderate loss (0.5%) | 85 Mbps | 98 Mbps | +15% |
| High loss (1-2%) | 55 Mbps | 88 Mbps | +60% |
| Bufferbloated path | 70 Mbps (high latency) | 95 Mbps (lower latency) | +36% |
| LTE with handover | 60 Mbps (drops during HO) | 78 Mbps (recovers faster) | +30% |
| 5G mmWave (variable) | 800 Mbps (volatile) | 950 Mbps (smoother) | +19% |
These differences are not theoretical. They are measured. And they have profound implications for field diagnostics:
1. Historical comparison is broken. An operatorβs 2025 speed measurements (Cubic-based) cannot be directly compared with 2026 measurements (BBR-based). A 15% throughput βimprovementβ may be entirely algorithmic, not network-related.
2. Field tools must support algorithm selection. A diagnostic tool that only runs Cubic speed tests in a BBR-measured regulatory environment produces non-comparable results. Professional tools need configurable congestion control.
3. VoLTE/video QoE correlation changes. If BBR shows higher throughput than Cubic on the same link, the correlation between speed test results and application QoE may shift. An RSRP/SINR condition that previously correlated with βinsufficient throughput for HD videoβ under Cubic may show sufficient throughput under BBR.
4. Regulatory compliance requires algorithm awareness. When ARCEP publishes coverage statistics using BBR-measured throughput, operators must ensure their own internal measurements use the same algorithm to maintain comparability.
Why ARCEP is making the switch
ARCEPβs motivation is straightforward: BBR better represents actual user experience on modern networks.
The reasoning:
- 70%+ of internet traffic originates from servers running BBR (Google, YouTube, Netflix CDN, major cloud providers)
- Measuring with Cubic while users experience BBR creates a systematic negative bias in official statistics
- BBRβs resilience to packet loss better reflects the real-world performance of mobile networks where radio retransmissions are frequent
- The shift aligns France with international trends (FCC, Ofcom are evaluating similar methodology updates)
The intersection: signaling security and measurement integrity
Phone spoofing and BBR adoption may seem unrelated, but they share a common underlying theme: the signaling and protocol layers that field diagnostics must capture are becoming more complex, not less.
The expanding diagnostic scope
| Year | Field Diagnostic Focus | Protocol Layers |
|---|---|---|
| 2015 | RF coverage + throughput | L1 (RF) + L7 (speed test) |
| 2020 | RF + signaling + QoE | L1 + L3 (RRC/NAS) + L7 (VoLTE MOS) |
| 2026 | RF + signaling + QoE + security + algorithm-aware measurement | L1 + L3 + L7 + SIP security headers + TCP CC selection |
Field engineers in 2026 need tools that:
- Measure RF parameters at engineering precision (RSRP, RSRQ, SINR via chipset interface)
- Decode Layer 3 signaling in real time (RRC, NAS)
- Capture VoLTE SIP signaling for quality and security analysis
- Execute speed tests with configurable congestion control (Cubic and BBR)
- Correlate all layers with GPS positioning for spatial analysis
- Export in formats accepted by regulators and vendors
This is not a wish list. It is the minimum capability set for professional field diagnostics in the ARCEP 2026 framework.
Orange at 8.1/10: what the leader does differently
Orangeβs leading satisfaction score (8.1/10) is not accidental. It reflects structural advantages that field diagnostics help quantify:
| Factor | Orange Advantage | Measurable With Field Tools |
|---|---|---|
| Fiber coverage | 35M+ premises connectable | N/A (fixed) |
| 4G population coverage | 99.4% | RSRP/RSRQ mapping, coverage validation |
| 5G NR deployment | 8,000+ sites (SA + NSA) | NR-RSRP, SSB beam measurement, EN-DC monitoring |
| VoLTE quality | Highest MOS scores in benchmarks | VoLTE MOS per call, codec analysis |
| Handover success rate | >98.5% in drive test benchmarks | Layer 3 handover event analysis |
| Indoor coverage | DAS in major venues, small cells in enterprises | Indoor walk test, serving cell identification |
The operators trailing Orange (SFR at 7.5, Free at 7.6) have specific, measurable gaps that field diagnostics can identify and quantify. The satisfaction gap is not abstract; it maps to RF parameters, signaling events, and QoE metrics that professional tools capture.
Practical implications for field teams
Updated measurement protocol for 2026
Given ARCEPβs methodology changes, field teams should update their measurement protocols:
Speed testing:
- Execute speed tests using both Cubic and BBR congestion control
- Record the algorithm used with every measurement
- Use BBR results for ARCEP regulatory comparison
- Use Cubic results for historical trend analysis (maintaining continuity with pre-2026 data)
- Document the throughput delta between algorithms at each measurement point
VoLTE diagnostics:
- Capture full SIP signaling (INVITE through BYE) for every test call
- Check P-Asserted-Identity and STIR/SHAKEN attestation headers
- Flag calls with Attestation Level C or missing attestation
- Record MOS, jitter, and codec for quality baseline
- Document any identity header inconsistencies for security audit
RF measurement:
- No change to RSRP/RSRQ/SINR methodology
- Add NR-specific measurements for 5G sites (SS-RSRP, SS-RSRQ, SS-SINR)
- Record SSB beam index for 5G beam management analysis
- Capture CA activation status and component carrier configuration
Export requirements for ARCEP compliance
| Data Point | Format Requirement | Sampling Rate |
|---|---|---|
| GPS position | WGS84, sub-10m accuracy | Per measurement point |
| RSRP/RSRQ/SINR | Per cell (serving + neighbors) | Every 100ms minimum |
| Throughput | Per-second with algorithm noted | Continuous during test |
| VoLTE MOS | Per call | Every call |
| Timestamp | UTC with millisecond precision | Every data point |
| Cell ID (PCI, EARFCN, NR-ARFCN) | Per serving and neighbor | Every 100ms minimum |
The broader European context
ARCEPβs methodology update is not isolated. European regulators are converging on modernized measurement approaches:
| Regulator | Country | BBR Adoption Status | Spoofing Mitigation |
|---|---|---|---|
| ARCEP | France | Adopted (2026) | STIR/SHAKEN voluntary adoption |
| Ofcom | UK | Under evaluation | CLI authentication mandate (2025) |
| BNetzA | Germany | Pilot phase | National CLI verification program |
| AGCOM | Italy | Not yet announced | EU-level coordination |
| CNMC | Spain | Not yet announced | EU-level coordination |
| BIPT | Belgium | Pilot phase | National spoofing task force |
The trend is clear: European regulators are simultaneously modernizing speed measurement methodology and addressing signaling security. Field diagnostic tools that support both dimensions will be better positioned for regulatory compliance across multiple markets.
Conclusion
ARCEPβs 2026 observatory delivers two messages that the network measurement community cannot ignore. The 43% phone spoofing rate exposes a signaling security failure that extends into VoLTE diagnostic requirements. The Cubic-to-BBR transition creates a 10-30% measurement discontinuity that every field team must account for.
Both developments point in the same direction: field diagnostics in 2026 requires more protocol depth, more configurability, and more security awareness than ever before. The RF layer alone is no longer sufficient. Layer 3 signaling, SIP header analysis, and congestion control algorithm selection are now part of the professional diagnostic toolkit.
Orangeβs 8.1/10 satisfaction leadership and the 7-point improvement across all operators over two years demonstrate that French mobile networks are improving. The tools used to measure and validate that improvement must evolve at the same pace.
For field engineers and network planners, the ARCEP 2026 observatory is not just a regulatory update. It is a recalibration of what βmeasurementβ means: deeper into the signaling stack, more aware of security, and more precise about the algorithms that determine reported performance.
Founder of HiCellTek. 15+ years in telecom, operator side, vendor side, field side. Building the field tool RF engineers deserve.
Request a personalized demo of HiCellTek β 2G/3G/4G/5G network diagnostics on Android.