---
title: 1. Introduction
tags: [Part 1]

---

# 1. Introduction

> Connected Services Framework (CSF) — Part 1: Framework — Version 2.0

## 1.1 Purpose of This Document

This document defines the Connected Services Framework (CSF), an open transport framework for the UK telecommunications industry. It establishes the technical and operational prerequisites, architectural design, and implementation strategy that enable Managed Access Providers (MAPs) to exchange messages securely and efficiently on behalf of their Communications Providers (CPs).

The CSF is free for any organisation to adopt. There are no licensing fees, transaction charges, or commercial dependencies on any single provider.

## 1.2 What the CSF Does

The CSF is a **transport layer** — it defines how messages are wrapped, signed, and delivered between MAPs. It does not define the content of those messages. Industry processes such as Switching for Business (SforB) or One Touch Switch (OTS) define the message content; the CSF delivers it.

In practical terms, the CSF provides:

- **Secure peer-to-peer message delivery** between MAPs using TLS 1.3, OAuth 2.0, and DKIM-based PKI signing
- **A distributed registry model** where each MAP publishes a CP Registry of its CPs, all MAPs converge these into a private Master Registry, and each MAP derives a filtered Directory for its own CPs
- **DNS-based CP verification** that puts CPs in control of which MAP represents them
- **Standardised onboarding** through peer sponsorship, removing the need for centralised administration
- **In-flight order portability** so CPs can change MAPs without disrupting active switching orders

## 1.3 Who This Document Is For

**Part 1 (this document)** is written for:

- **Senior management and decision-makers** evaluating whether to adopt the CSF
- **Solution architects** designing CP or MAP implementations
- **Programme managers** planning SforB delivery

**Part 2 (Implementation)** is written for developers and integration engineers who need API specifications, code examples, and JSON schemas.

## 1.4 Scope

The CSF covers:

- The definition of a decentralised messaging architecture independent of any centralised administrative authority
- Requirements for interoperability, security protocols, and communication standards between MAPs
- Protocols for onboarding new MAPs and transitioning CPs between MAPs
- Guidelines for maintaining data integrity, ensuring secure communications, and managing exceptional scenarios such as MAP failures, CP migrations, mergers, and administration

The CSF does **not** cover:

- How a MAP integrates with its own CPs (this is each MAP's commercial decision)
- The content of industry process messages (defined by OTS, SforB, etc.)
- The internal architecture of any MAP's platform

## 1.5 The Case for a Distributed Model

The UK telecoms switching landscape currently operates through a centralised hub model for residential switching (OTS via TOTSCo). While this model served its purpose, it introduces constraints that are unnecessary for business switching:

**Cost**: A centralised hub requires ongoing funding — through per-message fees, subscriptions, or industry levies. The CSF eliminates these costs entirely. MAPs exchange messages directly with each other at no charge.

**Independence**: In a hub model, every CP and MAP depends on a single operator for message routing, change management, and availability. The CSF distributes these responsibilities across all participants.

**Speed of innovation**: Hub changes require approval from a single vendor's change control process. CSF changes are agreed by the TAG steering group and can be adopted incrementally by MAPs through versioning and feature releases.

**Resilience**: A centralised hub is a single point of failure. The CSF's peer-to-peer architecture means that an outage at one MAP affects only that MAP's CPs — not the entire industry.

**CP freedom**: The CSF gives CPs direct control over their MAP relationship through DNS. A CP can change MAP by updating two DNS records, and their RCPID stays with them for life.

**Market access**: Any CP can become a MAP of 1 (serving only itself) and exchange messages directly with the industry. This lowers barriers to entry and avoids monopolistic lock-in.

**Additional routes, not a replacement.** MAPs and CPs can already exchange SforB traffic today via the TOTSCo Hub. The CSF does not replace that route — it adds **two additional, complementary routes** for the industry:

- **Managed via a CSF MAP** — a CP subscribes to a CSF MAP and exchanges through that MAP's CSF outbound. The CSF supports multiple competing MAPs, giving CPs real commercial choice.
- **Self-served as a MAP-of-1** — a CP runs its own MAP infrastructure, exchanging messages directly with every other MAP on the CSF network.

Together with the existing TOTSCo Hub route, this gives the industry three concurrent routes. The deliberate intent is **rapid SforB expansion**: many smaller business CPs need to become compliant in a short window, and offering them more than one route — without losing the TOTSCo Hub option — is the lever that makes industry-wide adoption practical.

> :memo: **Note**: The CSF does not preclude the use of a centralised hub. TOTSCo can operate as a Hub MAP (HMAP) within the CSF, allowing CPs connected to the hub to exchange messages with CPs connected to other MAPs seamlessly. The HMAP interface each MAP exposes to TOTSCo is **dedicated to TOTSCo and locked down** — CSF spec increments do not propagate through it, so TOTSCo's integration is a one-time build, not an evergreen one. See [Standalone — TOTSCo HMAP Integration Guide](../standalone/totsco-hmap-integration-guide.md) for the full operating model.

> :memo: **CSF directory is TOTSCo-compatible by design.** The CSF CP Registry (Part 2 §5) was designed as a **strict superset** of the TOTSCo OTS/GPLB directory shape. Parties that already consume the TOTSCo directory can ingest the CSF Registry with their existing parser; CSF-specific additions are additive and never breaking. This was a deliberate design decision so the industry could operate easily with the CSF through the JSON contract alone.

## 1.6 Initial Application: Switching for Business (SforB)

The CSF's first industry application is **Switching for Business (SforB)**, formerly known as Gaining Provider Led Business Switching (GPLB).

Key differences from OTS:

- **No mandated hub**: Ofcom has not required a centralised technical solution for business switching
- **Gaining-provider-led**: The switching process is initiated by the gaining provider
- **Larger scale**: The industry expects a tenfold increase in RCPIDs compared to OTS
- **Longer onboarding**: Industry-wide ramp-on is expected to span a considerably longer timeframe

The CSF has been designed to support SforB as its initial use case, but is architected for any future industry messaging process — including number porting, bilateral communications, and processes not yet defined.

## 1.7 Document Structure

| Chapter | Content |
|---|---|
| [Background](02-background.md) | History of OTS, the emergence of SforB, and the regulatory context |
| [Principles & Requirements](03-principles-and-requirements.md) | Industry-gathered requirements with MoSCoW prioritisation |
| [Architecture Overview](04-architecture-overview.md) | Layered model, message flow, and entity definitions |
| [CP Registry, Master Registry & Directory](05-directory-and-registry.md) | The three-tier distributed registry model |
| [Security Overview](06-security-overview.md) | Multi-layered security architecture |
| [Onboarding](07-onboarding.md) | MAP sponsorship and CP registration |
| [RCPID Management](08-rcpid-management.md) | Identifier format, allocation, and lifecycle |
| [Operational Excellence](09-operational-excellence.md) | Resilience, SLAs, and deployment patterns |
| [Governance](10-governance.md) | Standards bodies and change control |
| [Glossary](glossary.md) | Terms and abbreviations |