1. 11 Ofcom Consumer Switching What does it mean for us all? Bev Bytheway-Jackson Product manager bev.bythewayjackson@bt.com

2. 2 Confidentiality & legal statement The information contained in this presentation slide-pack is confidential information for discussion purposes only and should not be disclosed without British Telecommunications plc (BT's) permission. Please treat it accordingly and do not forward, republish or permit unauthorised access. Please note that BT has taken reasonable care to check that the information contained in this Presentation slide-pack is accurate at the time of issue, however, it is subject to change. In relation to any products/services referred to in this document which are currently under development and/or trial, BT gives no undertaking or other commitment that the product/service will be made commercially available. References to any such service and time scales contained within this document are indicative and estimates for information purposes only and these and other information do not constitute any contractual or other obligation. Applicable BT standard terms and conditions apply. © British Telecommunications plc 2013 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000

3. 3 Consumer Switching: Ofcom Final Statement Key Points (First Phase) Scope remains: –Voice and broadband switching within Openreach network –Residential and small business customers (NB all customers affected) –Other networks and services e.g. Cable and Pay TV in next phase Conclusions from consultation: –Implementation of the move from MAC to Notice of Transfer (NoT) for all voice and broadband switches to be complete by 20 th June 2015 –All proposed “front end” enhancements to NoT to be adopted and implemented by 20 th September 2014 –Ofcom chaired 1 st industry work group on 22 nd Jan, supported by OTA. A second phase will consider: –Extent and cause of erroneous transfers (largely due to Working Line Take Overs) –Feasibility of extending to include other technologies, networks and services –Further development of NoT, or hub/database solution –Details and timeline to be published in Spring 2014

4. 4 Consumer Switching: Ofcom Proposed Milestones For A Move To NoT DateEvent January 2014Industry working group to agree governance arrangements and underlying principles of harmonised process March 2014Stakeholder agreement on implementation strategy April 2014Stakeholders to submit implementation commitment plans & agree e2e process May 2014Openreach to issue straw man interface spec, CPs to begin detailed design June 2014Wholesale CPs to submit straw man of their interface spec Sept 2014‘Front End’ changes adopted and implemented October 2014Openreach and wholesale CPs to confirm detailed design November 2014Openreach and wholesale CPs to publish final technical spec and CPs to begin interlock testing January 2015Final release of Openreach systems updates for CP testing Jan-June 2015Business readiness and testing June 2015Launch of harmonised switching process

5. 5 Consumer Switching: Ofcom Points to note about NoT implementation Ofcom has listened to our views and approved a “big bang” approach Have noted that this requires more co-ordination and collaboration across industry than “normal” changes A number of issues for further debate, such as: - use of Retailer Ids (RIDs) on SMPF and FTTx - application of emergency restoration process - KPIs required to support enforcement - extra KCIs needed from wholesale CPs Acknowledged that switches of larger businesses might be impacted, but regulation will not apply, so down to commercial negotiation with Openreach

6. 6 Consumer Switching: Ofcom Enhancements to NoT Record of consent: –Call recordings of telesales, “I agree” button for online orders –To include direct record of consent, explanation from CP that it is required to create this record, customer name & address, time, date & means by which consent given, place (where appropriate), address and Calling Line Indicator (CLI) of target line –Stored and retrievable on an individual basis and retained for a minimum of 12 months, regardless if order completed, cancelled or ceased. Provision of better information on implications of switching: –NoT letters to contain precise info on Early Termination Charges (ETCs), including means by which they must be paid, calculated according to planed switching date –impact on ancillary/retained services, including price, specific to consumer –clear statement that customer does not have to contact Losing Provider Mandatory use of functionality to ensure seamless transfer of bundled services with no loss of service (e.g. Sim provide, Linked Orders, SIM2) where customer makes a single request to one Gaining Provider Mandating some best-practice elements of Working Line Takeover (WLT) process: –No WLT order placed without exact address match; GPs to take all reasonable steps to identify –Incumbent CP to send letter to “incumbent” customer, via post or another durable format if agreed, to highlight to customer that another customer has requested to takeover the service at their address on a specified date

7. 7 Consumer Switching: Items To Be Considered In A Future Third Phase Options to address “poor quality Openreach address data – a major cause of Erroneous Transfers” Whether recent industry developments, such as the MPF helpline, are sufficient to address lack of visibility of key data in identifying correct line Whether a harmonised process giving consumers a similar end-to-end process regardless of underlying technology is possible (e.g. for moves to/from cable) Whether further enhancements to the NoT process are needed (e.g. mandating use of Cancel Other) Whether a new Gaining Provider Led (GPL) solution, based on Transfer Code and an industry database, may be necessary and proportionate

8. 8 Openreach Design Principles – 1 All MAC based migration/transfer processes will change from MAC to NoT, and all AoT processes will also be uplifted to NoT Scope of impacted products (existing migration process) - WLR PSTN (AoT) - WLR ISDN2 (AoT) - WLR ISDN30 (AoT) - LLU MPF (AoT) - SLU-MPF (AoT) - LLU SMPF (MAC) - SLU-SMPF (MAC) - GEA FTTC (MAC) - GEA FTTP (MAC) - BT Classic PSTN (AoT) - BT Classic ISDN2 (AoT) - BT Classic ISDN30 (AoT)

9. 9 Openreach Design Principles – 1 All MAC based migration/transfer processes will change from MAC to NoT, and all AoT processes will also be uplifted to NoT Matrix of migrations/transfers in scope (simple view)

10. 10 Openreach Design Principles – 2 Gaining CP (GCP) will no longer need to submit order with a MAC key No changes for WLR and MPF - processes and interfaces remain ‘as-is’

11. 11 Openreach Design Principles – 2 Gaining CP (GCP) will no longer need to submit order with a MAC key SMPF Impacts - GCP will enter order with addition of mandatory RID but MAC key will not be required - RID field exists in schema, meaning version change is not required - stand-alone migrations will require CLI + Postcode - SIM1/SIM2 will require Postcode + LORN (target line will be derived from linked WLR order) - Migration with SBS (non-SIM1/SIM2) CLI + Postcode + LORN Q: It has been assumed that avoiding the need for a new schema is desirable for all CPs – is this correct? A: Provisional yes Q: Make RID mandatory for all provide orders? A: Provisional yes

12. 12 Openreach Design Principles – 2 Gaining CP (GCP) will no longer need to submit order with a MAC key GEA-FTTC Impacts - GCP will enter order as today, RID will become mandatory but MAC key will not be required - stand-alone migrations will require CLI + Postcode - SIM1/SIM2 will require LORN + Postcode - SBS (non-SIM1/SIM2) CLI + Postcode Note: No singleton migration of FTTC is allowed where target scenario is MPF+FTTC (no change to business rules)

13. 13 Openreach Design Principles – 2 Gaining CP (GCP) will no longer need to submit order with a MAC key GEA-FTTP Impacts - Proposed: GCP will enter order with addition of ONT ID plus Port number to identify target service, but MAC key will not be required - Will require schema change for migrations/transfers Alternative options: - generation of ALID (Access Line ID) for each service, mapped to ONT/Port - use of Service ID (issues over sensitivity of this data would need to be addressed) - both of above would require additional changes to dialogue services (e.g. eMLC, MLPA)

14. 14 Openreach Design Principles – 3 Losing CP (LCP) will be able to ‘cancel other’ the migration/transfer order No changes to interface or basic business process to WLR and MPF - harmonized Cancellation codes will be implemented across existing processes (see principle 6)

15. 15 Openreach Design Principles – 3 Losing CP (LCP) will be able to ‘cancel other’ the migration/transfer order SMPF impacts – Gaining CP (GCP) - GCP order can now be ‘cancelled other’ by LCP, driving a new unsolicited cancellation event and code SMPF impacts – Losing CP (LCP) - LCP will be able to ‘cancel other’ the managed cease (subject to SIM2 business rules) - LCP must include RID, cancel other flag and cancel other code - RID and Cancel Reason fields exists in schema, meaning version change is not required

16. 16 Openreach Design Principles – 3 Losing CP (LCP) will be able to ‘cancel other’ the migration/transfer order FTTC impacts – Gaining CP (GCP) - GCP order can now be ‘cancelled other’ by LCP, driving a new unsolicited cancellation event and code FTTC impacts – Losing CP (LCP) - LCP will be able to ‘cancel other’ the managed cease (subject to SIM2 business rules) - LCP must include RID, cancel other flag and cancel other code - RID and Cancel Reason fields exists in schema, meaning version change is not required

17. 17 Openreach Design Principles – 3 Losing CP (LCP) will be able to ‘cancel other’ the migration/transfer order FTTP impacts – Gaining CP (GCP) - GCP order can now be ‘cancelled other’ by LCP, driving a new unsolicited cancellation event and code FTTP impacts – Losing CP (LCP) - LCP will be able to ‘cancel other’ the managed cease (subject to SIM2 business rules) - LCP must include RID, cancel other flag and cancel other code - RID and Cancel Reason fields exists in schema, meaning version change is not required

18. 18 Openreach Design Principles – 4 MAC generation solution and MAC Checker dialogue service will be decommissioned MAC generation (via ‘ADDMAC’ and Portal requests) will be removed as a service at the same time as change to NoT goes live - any subsequent requests will be rejected MAC Checker dialogue service will remain until next appropriate release - will support MAC checks for any in-flight orders raised before change over date In-flight MAC processed orders will complete BAU - if order is cancelled (by GCP) it must be re-submitted under NoT process

19. 19 Openreach Design Principles – 5 Minimum Lead Times (MLT) for Migrations/Transfers will be harmonized across all Openreach products to a standard value MLT will be set to 10 working days (WD) - for WLR and MPF this is BAU SMPF/FTTC/FTTP Impacts - all processes will continue to accept a CRD of 5WD, but revised CCD will be returned to reflect 10WD MLT rule for Migrations/Transfers The ability to expedite Migration/Transfers previously supported for MAC based products will be restricted - no migration/transfer order can be expedited to less than 10 working days - it may still be possible to expedite to an earlier CRD/CCD, if it is equal to or greater than the MLT for migrations/transfers

20. 20 Openreach Design Principles – 6 Cancel Other reason codes will be standardized to a single set, across all products and CPs Single set of codes will remove mapping issues between PSTN and LLU MPF validation uplifted to support use of code and remove ‘text’ validation and incidences of mistranslation into ‘Cancelled by Operator’ Q: Only change Cancel Other codes or include Cancel Own as well? (would there be any value in this?) A: No strong views on this Q: What should the single code list be? Re-use one of the existing sets or create a new one? Decision deadline of 3 rd March 2014 Working Group

21. 21 Openreach Design Principles – 7 RID will be mandatory on all GCP Provide orders and for all LCP Managed Cease order cancellations Existing processes will be unchanged for WLR & MPF FTTC and FTTP inclusion of RID will change from optional to mandatory SMPF will require mandatory RID for migrations

22. 22 Openreach Design Principles – 8 The GCP provided RID will be included in Managed Cease messages generated to the LCP Existing processes will be unchanged for WLR & MPF SMPF, FTTC and FTTP managed cease notifications will change to include ‘Gaining RID’ - is in the existing schema

23. 23 Openreach Design Principles – 9 The LCP provided RID will be included in ‘Cancel Other’ messages generated to the GCP New process for all Products - potential re-use of existing schema field, but not ideal - more logical to introduce new schema with dedicated field for LCP RID in GCP cancellation KCI - will not impact roll-out of NoT processes if CP not on new schema (only receipt of LCP provided RID) Q: This is seen as delivering a long standing ‘ask’ from industry, is it still required as an immediate delivery and could CPs handle the re-use of RID fields in their systems? A: Openreach’s preference is for this to be via a new schema, Ofcom to confirm if this would be acceptable as CP’s would need time to consume

24. 24 Openreach Design Principles – 10 Transition of processes and procedures from MAC/AoT to NoT will be through a ‘big bang’ approach Once the NoT process is switched on (and AoT/MAC process off) only orders conforming to the new process will be accepted and processed Orders for SMPF, FTTC or FTTP with all NoT mandated elements plus a MAC key will be accepted, but MAC validation will be on format only. Q: Does the acceptance of MAC keys offer any advantage to CPs or could it be excluded from the design? A: Provisional yes Note: Ofcom to hold a separate session on 3 rd March 2014 to focus specifically on this strategy.

25. 25 Openreach Design Principles – 11 Openreach will not be responsible for ‘Policing’ the use or accuracy of RID, Cancellation Reason codes or Migration/Transfer processes Openreach will not hold any mapping or relationship of RID to CP - RID submitted must be in a valid format and from the published list held by Ofcom - an invalid or unrecognised RID will result in the order being rejected Openreach will validate the Cancellation reason by scenario (e.g. migration initiated managed cease) and against an agreed, published, list only Q: RID data is currently updated weekly into Openreach EMP systems, we have assumed this frequency is sufficient – is this acceptable?

26. 26 Openreach Design Principles – 12 SIM2 and SIM (aka SIM1) linked order business processes will not be directly impacted It is proposed that for a SIM2 scenario the current ‘broadband’ (SMPF/FTTC) business rules will continue to apply - the managed cease will be flagged to the LCP with a ‘Narrowband transfer’ reason and any attempt by the LCP to cancel this cease will be rejected SIM1 will continue to reject any ‘dual migration’ SMPF/FTTC order if an existing SMPF/FTTC service exists at target - no changes are proposed for this rule - cancellation of the narrowband order (WLR/MPF) can be via cancel own or cancel other, both will result in the automatic cancellation of the broadband (SMPF/FTTC) linked order Q: Will SIM1 still be actively consumed by CPs by June 2015 or will SIM2 be the default choice? A: Keep SIM1 as it provides some flexibility which SIM2 doesn’t.

27. 27 Reseller Identification (RID) Problem Statement In the December Statement on the Harmonisation of Switching Processes Ofcom mandated the use of RIDs in the switching transaction for all orders. There is some confusion within industry as to the extent of the requirement and the exact set of requirements which surround the use of the RID. The problem statement below seeks to highlight the areas where clarification is sought. What is the true definition of RID – Reseller or Retailer? What was the purpose behind Ofcom ‘s decision to mandate the use of RIDs? Which RID is required to be held at each stage in the supply chain? Is there an expectation of RIDs to be actively managed all the way back to the Openreach record? If so does that include actively managed and maintained when changes occur in the supply arrangements. e.g. when an end user customer changes supplier but the new supplier takes service from the same wholesaler as the old supplier – is the expectation that the RID change is notified up to the Openreach system. Will the use of RIDs for reporting purposes be extended to the wholesale community? Will Ofcom be refreshing the RID list to remove entries which are no longer in use?

28. 28 Notification of Transfer (Today’s process) 28 End User Gaining Reseller/Retailer Losing Reseller/ Retailer Gaining Wholesale CP Losing Wholesale CP Sole Access Provider (Openreach) Receive + Issue migration order Receive migration order Notify & begin cease Termination agreed Progress & complete own order Order delivered Initial Dialogue + Place Migration Order + or Objection Raised Cancel Other Cease Order Notify Cancel Receive Cancel Notify & contract closure

29. 29 Areas still to be discussed Urgent Service Restoration (USR) process for erroneous broadband transfers. Impact on BT Wholesale, Wholesale Calls and Carrier Pre-Select (CPS) CPs. Comprehensive contingency plan is in place if the ‘big bang’ fails on the day.

30. 30 What Does It Mean For You? Some Headlines You will need to consume a new technical specification You will need to change ‘front end’ processes, including recording consent and advising on loss of services A second phase of consultation to follow We will run monthly update webinars The timescales associated with this programme are such that the OTA are recommending that CP’s should not be waiting for full interface specifications to be published before starting their own design activities. An agile/flexible approach is the only way that we will all be able to meet the 20 th June 2015 deadline set by Ofcom. If you are not ready on 20 th June 2015 you will not be able to place migration orders.

31. 31 If anyone has any concerns regarding this approach, please flag into me as soon as possible. If anyone would like to engage bi-laterally please contact me as soon as possible. Bev Bytheway-Jackson, WBC Product Manager bev.bythewayjackson@bt.com 01244 657938 Highlights cont’d

32. 32 Thank you and any questions?

33. 33 Q&A Q:Richard Ahern (Zen) – CP’s implementation commitment plans, will that be BTW CPs. A: No, this will be for BT Wholesale to commit to delivering everything that their CPs need in time to meet the 20 June 2015 deadline. Q: Richard Ahern (Zen) – will CPs be allowed to contact their EU upon receipt of the loss notification A: No, you will not be permitted to use an NoT notification for a purpose for which it wasn't originally intended – it will be a breach of GC22. Q: Dave Palmer (Claranet) – if a 12 month contract exists on an FTTTC circuit and the End User chooses to migrate away before the 12 months will the exiting CP be held to term A: Yes, the remainder of the contract will be payable to BTW Q: Dave Palmer (Claranet) – Will the new contract on the FTTC circuit be a new 12 month contract A: Yes it will. Q; Kirsty Weller (Fourcom) – If Openreach will not be policing the migrations, who will A: An early restoration process will be key from day 1 to ensure any erroneous migrations are restored as soon as possible. Any problematical behaviour will be dealt with by Ofcom. Q: Chris Kilgour (Zen) – will CPs be able to identify which RIDs belong to which CP A: Yes, the Ofcom RID list is available in the public domain via Ofcom website http://www.ofcom.org.uk/static/numbering/ item j http://www.ofcom.org.uk/static/numbering/