Ofcom Consumer Switching
What does it mean for us all?
Bev Bytheway-Jackson
Product manager
bev.bythewayjackson@bt.com
1
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
2
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 20th June 2015
– All proposed “front end” enhancements to NoT to be adopted and implemented by
20th September 2014
– Ofcom chaired 1st industry work group on 22nd 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
3
Consumer Switching: Ofcom Proposed Milestones For A Move
To NoT
Date
January 2014
March 2014
Industry working group to agree governance arrangements and underlying
principles of harmonised process
Stakeholder agreement on implementation strategy
April 2014
Stakeholders to submit implementation commitment plans & agree e2e
process
May 2014
Openreach to issue straw man interface spec, CPs to begin detailed design
June 2014
Wholesale CPs to submit straw man of their interface spec
Sept 2014
‘Front End’ changes adopted and implemented
October 2014
November 2014
Openreach and wholesale CPs to confirm detailed design
Openreach and wholesale CPs to publish final technical spec and CPs to
begin interlock testing
January 2015
Final release of Openreach systems updates for CP testing
Jan-June 2015
Business readiness and testing
June 2015
4
Event
Launch of harmonised switching process
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
5
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
6
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
7
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)
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
• Matrix of migrations/transfers in scope (simple view)
9
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’
10
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
11
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)
12
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)
13
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)
14
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
15
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
16
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
17
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
18
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
19
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 3rd March 2014 Working Group
20
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
21
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
22
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
23
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 3rd March 2014 to focus specifically
on this strategy.
24
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?
25
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.
26
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?
27
Notification of Transfer (Today’s process)
Initial
Dialogue
Initial
Dialogue
Place
Termination
agreed
+ Migration
Order
Objection
or Raised
Receive
Cancel
Receive + Issue
migration order
Notify &
contract closure
Cancel
or Other
Progress &
complete
own order
Gaining Reseller/Retailer
Losing Reseller/ Retailer
Progress &
complete
own order
Notify & begin
cease
28
End User
Notify
Cancel
Receive + Issue
migration order
Receive
migration
order
Order
delivered
+
Notify & begin
cease
or
Cancel
Other
Cease
Order
Notify
Cancel
Gaining Wholesale CP
Losing Wholesale CP
Progress &
complete
own order
Sole Access Provider
(Openreach)
28
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.
29
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
20th June 2015 deadline set by Ofcom.
• If you are not ready on 20th June 2015 you will not be able to place migration
orders.
30
Highlights cont’d
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
31
Thank you and any questions?
32
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
33