---
title: "ETSI TS 102 232 series: IP handover and service-specific details"
chapter: "11"
---

# ETSI TS 102 232 series: IP handover and service-specific details

The TS 102 232 family provides a common IP-based delivery framework plus service-specific details (SSDs). Part 1 defines general HI2/HI3 IP handover aspects. Other parts specialize messaging, internet access, Layer 2, IP multimedia, PSTN/ISDN, and mobile-service material. Implementations select only the parts applicable to the authorized service and national profile.

> **Safety boundary:** this chapter teaches lawful, governed system design from
> public standards. It does not provide operational targeting, activation,
> decryption, surveillance-evasion, or covert collection instructions.

## The mental model

| Concept | Plain meaning | Control that must travel with it |
|---|---|---|
| **Part 1** | Common IP handover envelope, delivery, and control concepts | Pin the current published edition |
| **Part 2** | Service-specific details for messaging services | Service semantics and provider capability matter |
| **Part 3** | Service-specific details for internet access services | Identity-to-access binding is time-sensitive |
| **Part 4** | Service-specific details for Layer 2 services | Avoid assuming Layer 3 visibility |
| **Parts 5–7** | IP multimedia, PSTN/ISDN, and mobile-service details | Choose by actual service and network generation |
| **Profile composition** | Part 1 plus one or more SSDs and national parameters | Mixed versions require explicit compatibility |

## Apply it as a controlled workflow

1. Inventory offered services and identify applicable SSD parts.
2. Pin Part 1, SSD, common-parameter, and external dependency editions as one profile.
3. Define supported information classes and transformations at a conceptual level.
4. Validate delivery security, sequencing, error, keepalive, and availability behavior.
5. Run synthetic interoperability tests with the receiving facility.
6. Repeat testing whenever one part or national profile changes.

## Evidence to demand

- A bill of standards records every composed version and dependency.
- Unknown service payloads are quarantined, not guessed.
- Performance testing covers high-volume CC and bursty IRI separately.
- Transformation logs contain version and outcome, not communication material.

## Failure to reason about

Provider and receiver both claim TS 102 232 compliance, but one uses a newer Part 1 with an older mobile SSD and different national parameters. Family-level labels hide incompatibility. Pin and test the exact profile tuple.

## Feynman check

Part 1 is the shipping box. The SSD parts describe how different kinds of permitted service material fit inside. The receiver and sender must agree on the exact box instructions.