Where 4G/5G SEP Licensing Risk Concentrates: A Protocol-Layer Map for Implementers

Short answer: 4G/5G SEP licensing risk concentrates in the radio stack, not evenly across the 3GPP standard.
ClaimsEvidence's analysis on ETSI ISLD IPR database shows that PHY carries about 67,400 declared 4G/5G patent families, RRC carries about 56,500, and TS 38.331 alone accounts for about 49,500 declared families. MAC and RAN-overall form a middle band, while System/NAS/security is materially lighter at about 11,700 families, or about 18,400 in a broader 23/24/29/33-series core-service sweep. For implementers, the practical rule is simple: modem, baseband, RF, and protocol-stack products sit closest to the densest SEP zone.
From patent counts to licensing exposure
Part 1, How Many SEPs Are There in 4G and 5G, Really? answers the denominator question: how a noisy ETSI declaration export becomes roughly 123,500 declared 4G/5G families, and why only an order of ~24,700 are plausibly essential after honest deflation. This companion uses the same May 2026 ETSI export, clipped through 2025-12-31, but changes the question from "how many?" to a question a product team needs an answer to act on:
The licensing exposure zone is not spread evenly across the standard. Where does it concentrate, and is my product in that zone?
The answer maps cleanly onto something every implementer already understands: the protocol stack.
1. The standard is not a flat thing — it's a stack
A 3GPP standard is a layered protocol stack, and 3GPP's spec numbering follows it almost perfectly. This is documented structure, not our interpretation:
| 3GPP spec | Layer | What it governs | What implements it |
|---|---|---|---|
| 38.211–215 / 36.211–214 | PHY (L1) | The air interface: modulation, coding, channels | Baseband / RF / modem silicon |
| 38.321 / 36.321 | MAC (L2) | Scheduling, HARQ, multiplexing | Modem firmware |
| 38.322 / 36.322 | RLC (L2) | Segmentation, ARQ | Modem firmware |
| 38.323 / 36.323 | PDCP (L2) | Ciphering, header compression | Modem firmware |
| 38.331 / 36.331 | RRC (L3) | Connection control, mobility, configuration | Modem protocol stack |
| 38.300 / 36.300, 38.306, 38.304 | RAN overall / UE capability | End-to-end RAN behaviour, UE feature sets | Modem + integration |
| 23.501/502, 24.501, 33.501 | System / NAS / Security | Core network, registration, security | Network core, not the device modem |
If you ship a device, the layers that matter to you stop at the modem. If you ship network infrastructure, the System/NAS layer matters more. Hold that thought — it's the whole point.
2. Where do 4G and 5G declared patent families cluster
Before slicing by protocol layer, the ETSI standard-family tags already show the basic shape. NR is the dominant bucket, with "Multi" and LTE next; GSM, IMS, codec, security, video, emergency, and IoT sit much lower on the log scale. Treat these as ETSI taxonomy tags, not additive exposure totals — "Multi" and generation tags can overlap — but the direction is clear: the declared surface is concentrated in cellular radio standards.

How to read the small IoT bar: It answers "which standards family did ETSI attach to this declaration?", not "what product feature or market use case might this patent affect?". That distinction matters for IoT. NB-IoT is a cellular radio technology, so declarations relevant to NB-IoT often sit under LTE/NR radio specifications and therefore show up in the LTE, NR, Multi, or protocol-layer buckets. They do not necessarily receive an "IoT" standard-family tag. In this export, only 3 families carry ETSI's broad IoT family tag, while a separate and much less consistently populated feature tag identifies about 118 NB-IoT families. So read IoT = 3 as "three families tagged by ETSI as IoT-standard-family," not as "only three cellular-IoT SEP families exist."
Which 3GPP layer is the most declared
Now bucket every declared 4G/5G family into the layer of the spec it was declared against. A family declared against more than one layer is counted once in each layer it touches — because it genuinely is exposure in each. The bars are not a partition; they show "how much declared SEP weight sits on this layer."

The shape is unambiguous:
- PHY (L1): ~67,400 families. The air interface is the single densest zone of declared SEPs in the entire standard.
- RRC (L3 control): ~56,500 families. Connection setup, mobility, measurement configuration — the second densest.
- MAC and RAN-overall: ~26,200–29,000 each.
- System / NAS / Security: ~11,700. Materially lighter than the radio layers. A broader 23/24/29/33 core-service sweep is larger, about ~18,400 families, but still far below PHY or RRC.
- RLC and PDCP: ~5,000 each. The thin, stable L2 sublayers attract an order of magnitude fewer declarations than PHY or RRC.
To put it in one sentence: the declared SEP weight of 4G/5G is overwhelmingly a radio-interface phenomenon. PHY plus RRC alone account for more declared layer-touches than every other mapped layer combined. The single most-declared spec in the entire 4G/5G dataset is TS 38.331 — 5G NR Radio Resource Control — at ~49,500 families on its own.
Which 3GPP spec (TS) is the most declared
The spec-level ranking confirms the same point from a different angle. The top of the list is dominated by TS 38.331 and the 38.2xx/36.2xx radio-interface specifications. Core-network specifications such as TS 23.501 and TS 23.502 matter, but they are not where the declaration density peaks.

3. What this means for your product
This is the implementer payoff, and it's a genuinely useful planning lens:
If you build baseband, RF, or modem silicon/firmware, you are squarely in the densest part of the SEP surface. PHY + MAC + RLC + PDCP + RRC is exactly your implementation footprint, and it is exactly where declared SEPs pile up. Your exposure is structurally high and there is no architectural way around it — the air interface is the standard.
If you build a device that integrates a certified modem (the common case — a phone, a router, an IoT product using a Qualcomm/MediaTek/etc. module), the radio-layer SEP question often starts with the modem supplier's license position. That is not automatic immunity: certification is not the same as patent exhaustion, and pass-through depends on the supplier license, the component sale, and the asserted patents. But "we use a licensed module" can be a real risk-reduction argument when the facts support it — the chart shows why it works structurally.
That device-level inquiry pairs naturally with LTE category and 5G RedCap capability classification, because the modem profile tells you which feature paths are plausible before claim review.
If you build network-core or application-layer software over the cellular link (a 5G core function, an MEC application, a private-5G orchestrator), your direct footprint usually starts in System/NAS/security and adjacent core-service specs. The selected System/NAS/Security bucket shown here is ~11,700 families; a broader core-service sweep across 23/24/29/33-series specs is about ~18,400 families. Either way, it is materially lighter than the ~67,400 PHY zone. You are generally outside the densest radio-interface zone. That is a defensible scoping argument, not wishful thinking.
The standard's encumbrance is not a uniform fog. It is a map:
The closer your product sits to the air interface, the heavier your declared SEP exposure — predictably and structurally.
4. Not all declarations are equally assessable
There is a second axis an implementer should care about, and it does not appear in conventional SEP analyses at all.
When a holder declares, ETSI lets them optionally cite the specific spec clause(s) the patent reads on. Most don't. A declaration that says "essential to clause 5.3.5.3 of TS 38.331" is cheap to assess — you can read that clause against the claims. A declaration that just says "essential to TS 38.331" (the whole ~1,000-page spec) is expensive to assess and is the SEP equivalent of a blanket assertion.
We measured the clause-pinpoint rate per layer:

- Overall, only ~38% of declared 4G/5G families pinpoint a specific clause. Roughly two-thirds are blanket "essential to the whole spec" declarations.
- PHY (~37%), RRC (~35%), System/NAS (~39%) sit near the average.
- RLC stands out at ~7% and PDCP at ~13% — declarations against the thin L2 sublayers are almost entirely blanket. Holders rarely bother pinpointing a clause in a small, stable protocol.
The implementer takeaway: a blanket declaration is not stronger than a pinpointed one — it's just less examined. Roughly two-thirds of the declared surface has never been narrowed down by the holder to a specific spec clause, which is one more reason the raw count overstates real essentiality. It also tells you where AI-native essentiality analysis, like ClaimsEvidence pays off most: the blanket-heavy layers are where manual essentiality assesments relying on expert billable hours don't scale.
Layer density tells you where to look, but claim-level essentiality analysis with cited clauses will tell you if the asserted claims are actually a licensing problem for your product.
5. Product comparison: where to start the SEP review
For teams responding to a live assertion, this table is a compact SEP demand letter triage starting point.
| Product footprint | First SEP review zone | Declared family signal | Practical read |
|---|---|---|---|
| Baseband / RF / modem silicon | PHY + MAC + RRC | ~67k / ~26k / ~56k | Structurally high exposure. The air interface is the standard; there is no architectural escape. |
| Device using a modem module | Supplier license, module scope, residual integration layers | Radio exposure may be supplier-addressed; residual review often moves to integration/system behavior | "Licensed module" helps only if license, pass-through, and exhaustion facts support it. |
| Network core / app-layer software | System/NAS/security plus adjacent 23/24/29/33 specs | ~11.7k in the selected bucket; ~18.4k in a broader core-service sweep | Materially lighter than radio layers, but not empty. Scope the product before accepting portfolio-wide assertions. |
| Any cellular implementer | Clause-pinpointed vs. blanket declarations | ~38% pinpointed overall | Two-thirds of declarations are blanket; declared does not mean assessed or essential. |
6. FAQ
| Question | Short answer |
|---|---|
| Where do 4G and 5G SEP declarations concentrate? | Around the radio interface. In this ETSI IPR dataset, PHY has about 67,400 declared 4G/5G families and RRC has about 56,500, materially more than MAC, RLC, PDCP, System/NAS/security, or the broader core-service sweep. |
| Which 3GPP specification has the most declared 4G/5G SEP families? | TS 38.331, the 5G NR Radio Resource Control specification, is the largest single spec bucket in this dataset, with about 49,500 declared families. |
| How should cellular-IoT and NB-IoT products scope SEP exposure? | Do not scope them from the small ETSI IoT tag alone. NB-IoT is implemented through cellular radio specifications, so relevant declarations often sit under LTE/NR and PHY/RRC buckets. In this export, the sparse feature labels identify at least 118 NB-IoT families, while only about 417 audited 4G/5G families have any feature label at all. Treat 118 as a floor, then map the product to the LTE/NR specs it actually implements. |
| Does using a licensed modem module reduce SEP licensing risk? | It can, but it is not automatic. A licensed module can reduce radio-layer exposure when the supplier license, sale, and exhaustion/pass-through facts cover the asserted patents. Product teams still need to check residual device, integration, and system-layer exposure. |
| Are network-core and application-layer products in the same SEP risk zone as modem products? | Usually no. Network-core and application-layer products generally sit outside the densest PHY/RRC radio-interface zone. Their review should focus on System/NAS/security and adjacent core-service specifications. |
| What is an ETSI illustrative part? | It is the optional ETSI declaration field where a declarer identifies specific standard clauses. A declaration with an illustrative part is easier to assess than a blanket declaration against an entire 3GPP specification. However, only ~38% of declarations note an illustrative part, making manual analysis very expensive for most declarations. That's where agentic AI like ClaimsEvidence brings the most value. |
The encumbrance map of 4G/5G is stable and structural. Knowing where your product sits on the protocol stack — and how much of the surface above you is blanket-declared rather than pinpointed — tells you more about your real licensing exposure than a headline patent count. Turning that map into a per-claim, product-specific essentiality position is the work of product-specific SEP landscaping.
About ClaimsEvidence
ClaimsEvidence is the evidence layer for FRAND licensing. We combine experienced patent litigators with purpose-built agentic AI to deliver claim-level SEP analysis — essentiality assessments, prior art searches, and defense strategies — at a scale and cost that makes per-patent evidence practical, not aspirational. If you're sizing your SEP exposure or preparing for a licensing negotiation, contact ClaimsEvidence.
About the Author
Konstantinos Poulinakis is the Co-Founder & CEO of ClaimsEvidence. He has 7+ years of experience architecting and leading AI solutions, for the highly-regulated, high-stakes industries of legal and finance. Former Senior AI engineer at Deutsche Bank and Aleph Alpha, the German frontier AI lab.
LinkedIn