#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.
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.
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: 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 and the TOTSCo HMAP Integration Guide.

#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.

#9.9 Service Level Agreements

Specific SLAs for MAP-to-MAP activity are to be formalised. The following indicative levels have been agreed:

#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 and reflected in the CSF Definitions and Terminology.
• 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.