--- title: "Northstar Mobile scenario, glossary, and standards map" chapter: "29" --- # Real-life governed scenario: Northstar Mobile Northstar Mobile is a fictional communications provider operating mobile, fixed-IP, and messaging services. A competent authority submits a court-approved order concerning one subscriber identifier, two named services, and a precise 72-hour period. The example is intentionally non-operational: it explains governance, architecture, assurance, and evidence without target activation or collection instructions. ## 1. Intake and independent validation The warrant interface receives a signed administrative object over an approved peer relationship. Schema validation passes, but that is only the first gate. A legal specialist verifies the issuing authority, jurisdiction, dates, named services, target identifiers, and any special limits against the authoritative order. A second authorized reviewer approves the technical translation. The signed order is preserved separately. The case system stores a minimal, opaque case reference and a bounded technical scope. General service desks, cloud administrators, and product teams cannot see the target or case. ## 2. Architecture decision Northstar maps the request through these controlled responsibilities: `validated authority → administration → approved points of interception` `points → X2 IRI / X3 CC → mediation → HI2 / HI3 → approved LEMF` `independent audit ← every consequential state transition` The administration function is the sole source of desired state. Each relevant function has a dedicated workload identity and acknowledges the versioned state. Functions also enforce expiry locally, so a control-plane outage cannot extend the authorization. ## 3. Standards profile The service profile pins the applicable published ETSI TS 103 120 warrant interface, TS 103 221 internal interfaces, TS 103 280 common dictionary, and TS 102 232 delivery parts. Mobile services additionally pin one coherent 3GPP 33.126/33.127/33.128 release. National parameters are treated as a separately versioned profile. “ETSI compliant” is not accepted without this tuple. ## 4. Controlled activation evidence The platform records: - approval identities and times; - authority reference and approved scope hash; - desired-state version and effective/expiry time; - which eligible functions accepted or rejected the state; - software, schema, certificate, and profile versions; - gap, duplicate, backlog, and delivery-receipt counters; - every privileged access and change. It does not put target identifiers, communication content, or legal documents in normal logs, dashboards, traces, tickets, or cloud labels. ## 5. Delivery and assurance IRI and CC use separate mediation pools, queues, keys, and access policies. Mediation validates the active case reference and transforms only to the pinned handover profile. Synthetic fixtures already proved version compatibility with the approved LEMF. During the case, a receiver link is unavailable for 18 minutes. Bounded queues retain already authorized objects. Privacy-safe counters alert both controlled operations teams. On recovery, stable identity and sequence allow replay and duplicate handling. Source, mediation, and receiver totals reconcile; no operator opens payload to perform the check. ## 6. Expiry and closure At the legal end time, every point independently stops new observation. The administration function sends de-provisioning and reconciles acknowledgements. Queued objects are handled according to the agreed legal policy for material lawfully acquired before expiry. No new collection occurs. The closure report records final delivery status, gaps, incidents, privileged access, de-provisioning evidence, and the applicable retention or legal hold. Target-scope working data is deleted from operational systems when permitted. Audit evidence remains for the separately governed oversight period. ## What the architect must defend 1. **Authority:** no action exists without valid current authorization. 2. **Scope:** identifiers, services, jurisdiction, and time are bounded. 3. **Isolation:** administrative, IRI, CC, and audit domains have distinct trust. 4. **Correctness:** versioned state, identity, time, sequence, and transformation make gaps and duplicates visible. 5. **Availability:** failure recovery never becomes permission to overcollect. 6. **Privacy:** data and metadata are minimized and ordinary operators cannot infer case existence. 7. **Accountability:** independent reviewers can reconstruct the lifecycle. 8. **Closure:** expiry, de-provisioning, retention, and deletion are proven. ## Architecture review checklist - Is the legal authority validated by a role independent of technical intake? - Can any one person create, approve, activate, receive, and erase a case? - Are standards and national profiles pinned to exact published versions? - Does every function enforce current scope and local expiry? - Are IRI and CC isolated in transport, processing, storage, and access? - Can the platform detect missing, duplicate, late, or rejected objects? - Do telemetry and support systems avoid target and content data? - Are receiver outage and cross-border failover policies agreed in advance? - Can a restored or newly scaled function prove current authorization? - Can closure prove that all active state was removed? ## Glossary and abbreviations | Term | Plain meaning | |---|---| | **ADMF** | Administration Function that controls approved LI state | | **CC** | Content of Communication | | **CSP** | Communications Service Provider | | **DF** | Delivery Function | | **ETSI** | European Telecommunications Standards Institute | | **HI1** | Administrative/warrant-related handover information | | **HI2** | Handover of Intercept Related Information | | **HI3** | Handover of Content of Communication | | **ILHI** | Inter-LEMF Handover Interface | | **IRI** | Intercept Related Information | | **LEA** | Law Enforcement Agency/Authority | | **LEMF** | Law Enforcement Monitoring Facility | | **LD** | Lawful Disclosure of stored data | | **LI** | Lawful Interception | | **MF** | Mediation Function | | **NF / CNF / VNF** | Network Function / cloud-native / virtualized network function | | **NWO** | Network Operator | | **POI** | Point of Interception | | **RD** | Retained Data | | **SBA** | 5G Service-Based Architecture | | **SSD** | Service-Specific Details in the TS 102 232 family | | **SvP** | Service Provider | | **TS** | Technical Specification | | **X1** | Provider-internal LI administration interface | | **X2** | Provider-internal IRI delivery interface | | **X3** | Provider-internal CC delivery interface | ## Published standards snapshot This snapshot was verified against official ETSI and 3GPP catalog pages on **5 August 2026**. Standards evolve: an implementation or procurement decision must re-check the primary catalog, dependencies, national profile, and publication status. | Family | Published/status snapshot | Role and use | |---|---|---| | ETSI TS 101 331 | V1.8.1 (2021-07) | Foundational LEA requirements; verify national applicability | | ETSI TS 101 671 | Verify current applicable edition/profile | Generic/foundational handover, often relevant to legacy profiles | | ETSI TS 102 232-1 | V3.37.1 (2026-05) | Common IP delivery handover; compose with applicable SSD parts | | ETSI TS 102 657 | V2.6.1 (2025-08) | Request/delivery of retained data, not live LI | | ETSI TS 103 120 | V1.23.1 (2026-05) | Warrant information interface; a newer draft does not replace the published edition | | ETSI TS 103 221-1 | V1.20.1 (2025-05) | X1 provider-internal administration | | ETSI TS 103 221-2 | V1.9.1 (2025-08) | X2/X3 provider-internal IRI/CC delivery | | ETSI TS 103 280 | V2.18.1 (2026-03) | Common parameter dictionary and shared dependency | | ETSI TS 103 462 | V1.3.1 (2026-03) | Inter-LEMF Handover Interface | | ETSI TS 103 705 | V1.6.1 (2026-05) | Data structures for lawful disclosure | | ETSI TS 104 144 | V1.4.1 (2026-05) | EU e-Evidence Regulation interface | | 3GPP TS 33.126 | Release 19 V19.3.0 snapshot | Modern mobile LI requirements | | 3GPP TS 33.127 / .128 | Release 19 V19.5.0 status snapshot | Architecture/functions and Stage 3 protocols/procedures | | 3GPP TS 33.106 / .107 / .108 | Release-aligned legacy family | Use where the legacy service profile requires | | 3GPP TS 33.129-1 / -2 | Draft/status work in the checked report | Emerging security-assurance work; do not present as stable published guidance without re-checking | ## Official primary sources - [ETSI Technical Committee Lawful Interception](https://www.etsi.org/technical-groups/li/) - [ETSI TC LI Terms of Reference](https://portal.etsi.org/TB-SiteMap/LI/LI-ToR) - [ETSI TS 103 120 work programme](https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=79359) - [ETSI TS 103 221-1 V1.20.1](https://www.etsi.org/deliver/etsi_ts/103200_103299/10322101/01.20.01_60/ts_10322101v012001p.pdf) - [ETSI TS 103 221-2 V1.9.1](https://www.etsi.org/deliver/etsi_ts/103200_103299/10322102/01.09.01_60/ts_10322102v010901p.pdf) - [ETSI TS 103 280 published editions](https://www.etsi.org/deliver/etsi_ts/103200_103299/103280/) - [ETSI TS 102 657 V2.6.1](https://www.etsi.org/deliver/etsi_ts/102600_102699/102657/02.06.01_60/ts_102657v020601p.pdf) - [ETSI TS 103 462 V1.3.1](https://www.etsi.org/deliver/etsi_ts/103400_103499/103462/01.03.01_60/ts_103462v010301p.pdf) - [ETSI TS 101 331 V1.8.1](https://www.etsi.org/deliver/etsi_ts/101300_101399/101331/01.08.01_60/ts_101331v010801p.pdf) - [3GPP 33-series specification index](https://www.3gpp.org/dynareport/33-series.htm) - [3GPP specification status report](https://www.3gpp.org/dynareport/status-report.htm) ## Final Feynman challenge Explain the complete Northstar case without using an acronym: who grants permission, who checks it, how the provider gives each machine only the necessary bounded job, how event information and content stay separated, how the approved authority receives it, how gaps are found without reading content, how the job stops on time, and how an independent reviewer proves the whole story later.