---
title: 2. Background
tags: [Part 1]

---

# 2. Background

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

## 2.1 The Evolution of UK Telecoms Switching

The United Kingdom's telecommunications sector has undergone significant evolution, driven by government policy objectives aimed at promoting a more competitive, consumer-focused market. Central to this transformation is the **Switching General Conditions**, a regulatory framework designed to streamline switching processes by minimising inefficiencies and eliminating procedural redundancies.

## 2.2 One Touch Switch (OTS): Establishing the Foundation

Through the Switching General Conditions, the industry formed a Detail Design Group (DDG) to establish the requirements for switching residential customers' broadband and voice services — what Ofcom termed "One Touch Switch."

The DDG established several foundational principles that the CSF builds upon:

1. **JSON message format**: A standardised format separating delivery instructions (the envelope) from the message content (the body)
2. **Shared directory**: A directory of all participating CPs that could be shared by all participants
3. **Common connectivity**: A standardised way for CPs to connect, send, and receive messages
4. **Multiple delivery platforms**: Support for multiple solutions — hub, portal, and direct integration — provided by what are now known as Managed Access Providers (MAPs)

These principles now form the basis of the **JSON Asynchronous Messaging Specification (JAM)**, published on the OTA2 website and used by both OTS and SforB.

### Limitations of the OTS Implementation

To guarantee timely delivery of OTS, certain original design principles were not fully implemented:

- Ofcom mandated that all OTS messages be routed through a single centralised hub (TOTSCo), limiting direct MAP-to-MAP exchange
- Industry processes for CP transitions between MAPs were not addressed
- RCPID management — where the CP, not the MAP, owns the identity — was not fully resolved
- The directory model, while distributed in concept, remained dependent on a central operator

These gaps created the need for the TAG and the CSF.

## 2.3 Switching for Business (SforB): Removing Restrictions

Mandated by Ofcom, the business switching process was established on principles similar to OTS, with one critical distinction: **Ofcom has not mandated that all messages be routed through a centralised hub**.

This removal of the routing restriction enables MAPs and individual CPs to exchange messages directly with one another, rather than through a central intermediary.

The Switching for Business process:

- Establishes the **gaining-provider-led model** as mandated by Ofcom
- Adopts the **Switching for Business (SforB) process** — stewarded by the GPLB Steering Group (GPLB-SG) — uniformly across the industry
- **Decouples** CPs from the constraints of any specific transport mechanism
- Represents the **first industry process** designed to streamline direct inter-provider messaging

## 2.4 The Telecom Technical Architecture Group (TAG)

The TAG is a consortium of telecom industry stakeholders — including MAPs, System Integrators, and CPs — convened to:

1. Identify gaps in the OTS messaging infrastructure
2. Establish core requirements for extending the OTS foundation to support SforB and future processes
3. Design and maintain the Connected Services Framework

The TAG collaborates closely with the GPLB Steering Group (GPLB-SG) and references the Switching for Business process documentation published on the FCS website.

Before designing any solution, core requirements were gathered from all MAPs, System Integrators, and related CPs. These requirements — covering cost reduction, security enhancement, and message exchange processing — form the foundation of the CSF as documented in [Principles & Requirements](03-principles-and-requirements.md).

## 2.5 From OTS to CSF: What Changed

| Aspect          | OTS                               | CSF                                       |
|-----------------|-----------------------------------|-------------------------------------------|
| Routing         | All messages via TOTSCo Hub       | Direct MAP-to-MAP (peer-to-peer)          |
| Hub dependency  | Mandatory                         | Optional (TOTSCo can operate as HMAP)     |
| Directory       | Centralised at TOTSCo             | Each MAP publishes its own registry       |
| RCPID format    | 4-character codes (e.g., RGXD)    | UUIDv4 for scalability and uniqueness     |
| CP identity     | Managed by MAP/Hub                | CP controls via DNS records               |
| Message signing | Hub validates                     | DKIM-based PKI — any recipient can verify |
| Onboarding      | Central registration              | Peer-sponsored, self-service              |
| Cost model      | Hub subscription/per-message fees | Free — no charges between MAPs            |
| CP portability  | Limited                           | Built-in: RCPID follows the CP for life   |
| Change control  | Hub vendor process                | TAG steering group (weekly)               |