--- title: 9. Operational Excellence tags: [Part 1] --- # 9. Operational Excellence > Connected Services Framework (CSF) — Part 1: Framework — Version 2.0 ## 9.1 Core Principles The CSF is built on three operational cornerstones: - **Security**: Strong encryption, robust authentication, and digital signing - **Efficiency**: Accurate and timely telecom service transitions - **Reliability**: Resilient architecture ensuring continuous availability ## 9.2 Availability Target MAPs MUST target **99.95% availability** (three nines & a five) for switching services. This equates to 21 minutes and 55 seconds of downtime per month, or about 4 hours and 23 minutes of downtime per year and aligns with TOTSCo Availability Target. ## 9.3 High Availability and Redundancy MAPs SHOULD: - Deploy **multiple geographically distributed** instances (subject to GDPR) to eliminate single points of failure - Implement **automatic failover** mechanisms capable of instantly transitioning operations to backup systems without noticeable service disruption - Maintain **fully redundant network paths** and infrastructure components ## 9.4 Continuous Operations During Maintenance MAPs MUST implement rolling updates and upgrades to ensure that maintenance activities — including software updates and security patching — do not impact service continuity. Recommended deployment strategies: - **Blue-Green Deployment**: Maintain two identical production environments. Deploy updates to the inactive environment, validate, then seamlessly switch traffic. This enables rapid rollback if issues are discovered. - **Canary Deployment**: Gradually roll out updates to a small subset of traffic, monitor performance, and incrementally increase exposure based on positive outcomes. MAPs SHOULD clearly communicate planned maintenance activities — even when designed to have no service impact — to maintain transparency and stakeholder confidence. ## 9.5 Monitoring and Alerting MAPs MUST provide: - **Real-time, proactive monitoring** with automated alerting capable of detecting and addressing issues before they affect availability - **Mandatory status indication** in the MAP Registry when an incident occurs, including clearly recorded planned changes highlighting any periods of potential risk MAPs SHOULD provide: - A transparent, real-time **status dashboard** accessible by connected providers, showing platform health and operational metrics ## 9.6 Disaster Recovery MAPs MUST: - Regularly **test and validate** disaster recovery procedures, including full failover scenarios and restoration processes - Establish **Recovery Time Objectives (RTO)** and **Recovery Point Objectives (RPO)** that align with the commitment to continuous availability ## 9.7 Security and Compliance MAPs MUST: - Maintain rigorous security standards and apply timely patches without disrupting ongoing service - Adopt **secure-by-design** principles to ensure resilience includes robust protections against cyber threats - Conduct **regular security audits** and vulnerability assessments to identify and mitigate risks proactively ## 9.8 Guaranteed Message Delivery ### Pre-Send Verification Before sending a message, the originating MAP SHOULD verify the resilience status of the receiving MAP using information from the MAP Directory. This includes checking: - Whether the receiving MAP is currently online - Whether they are in a known period of planned change or experiencing an incident ### Retry Policy If the originating MAP does not receive a synchronous `HTTP 202` acknowledgement (e.g. it receives a `4xx`, `5xx`, or times out), it MUST: 1. Apply the **1 second connection timeout** and **3 second response timeout** specified in [Part 2 §4.7.2](../part2-implementation/04-message-api.md#472-required-behaviours-csf-map-to-map). 2. Automatically retry message delivery using **exponential backoff with jitter** — never a linear or fixed-cadence schedule. The architectural rationale for this is set out in [Part 2 §4.7.5](../part2-implementation/04-message-api.md#475-why-exponential-backoff-and-not-linear--fixed-cadence-retry). 3. Implement a **circuit-breaker pattern** after N consecutive failures (recommended `N = 5`, tunable per MAP) to stop overwhelming a struggling destination. 4. Honour `Retry-After` on `HTTP 429` / `503` responses. 5. Maintain comprehensive **audit trails** of all message exchanges, delivery attempts, and outcomes. 6. Define a **bounded maximum retry period** — the framework recommends hours, not days. Beyond the window, the sender raises `9008` and the failure escalates to the operational-engagement path in [Part 2 §4.7.3](../part2-implementation/04-message-api.md#473-operational-engagement-escalation): `map/outage[]` publication by the failing MAP, alert on the sender, inter-MAP engagement via `map/contact[]`. The retry policy applies to **CSF MAP-to-MAP traffic**. Traffic crossing the **HMAP boundary** to TOTSCo follows the GPLB hub schedules on TOTSCo's side — see [Part 2 §4.7.4](../part2-implementation/04-message-api.md#474-the-hmap-boundary) and the [TOTSCo HMAP Integration Guide](../standalone/totsco-hmap-integration-guide.md). ### Asynchronous Error Handling The CSF employs asynchronous error codes (8xxx series) to signal and assist MAPs during message processing. These codes are designed for self-healing and promoting good practices, complementing the industry-standard 9xxx codes used by OTS/TOTSCo. > For details on error codes and message delivery failure formats, see [Part 2: Message API](../part2-implementation/04-message-api.md). ## 9.9 Service Level Agreements Specific SLAs for MAP-to-MAP activity are to be formalised. The following indicative levels have been agreed: | Category | Target | |---|---| | Platform availability | 24x7 high availability (queue and retry during unavailability) | | Directory freshness | Near-real-time updates (never delete the last compiled directory) | | Working hours | Core business hours for support | | Planned maintenance | Outside business hours (with objective of minimal planned outages) | | MAP-to-MAP response time | 1 working day | | Priority 1 (MAP unavailable) | Fix within 4 working hours | | Priority 2 (CP unavailable) | Fix within 1 working day | | Priority 3 (Service degradation) | Fix within 2 working days | | Priority 4 (Change requests) | Actioned within 1 working week | ## 9.10 Capacity Planning MAPs should scale their infrastructure to align with their CP base. The following minimum rate calculation has been agreed by the TAG and applies for CSF v2.0: **Messages per second** = Total Switchable Asset Base / 1,000 With an **absolute minimum of 2 messages/second**. ### What counts as a Switchable Asset The **Switchable Asset Base** is the total count of customer services across all of a MAP's CPs that can be switched as part of the **Switching for Business (SforB)** protocol. Two service types are in scope: - **IAS — Internet Access Service.** Broadband or internet connectivity provided to end customers — e.g. fibre-to-the-premise (FTTP), fibre-to-the-cabinet (FTTC), cable broadband, fixed-wireless access. Defined in the [Switching General Conditions](https://www.ofcom.org.uk/) and reflected in the CSF [Definitions and Terminology](../standalone/definitions.md). - **NBICS — Number-Based Interpersonal Communications Service.** Voice telephony provided to end customers via an assigned number — e.g. traditional landline, VoIP, hosted business voice. Also covered by the Switching General Conditions. A "switchable asset" is therefore one IAS line *or* one NBICS line. A single business customer can therefore contribute multiple assets to the count (one IAS + one NBICS = two switchable assets for that customer). The Switchable Asset Base aggregates this across every CP a MAP serves. This figure is the input to the capacity formula above and to several SLA / governance calculations elsewhere in the CSF. **Examples**: - MAP with 5,000 switchable assets: 5,000 / 1,000 = 5 msg/s - MAP with 20,000 switchable assets: 20,000 / 1,000 = 20 msg/s MAPs can enhance acceptance rates using hardware acceleration and internal queuing, as SLAs for business switching are significantly longer than the 60-second Switch Match response times required by OTS.