Product Process descriptions

A migration of existing FTTP refers to a change of CP on an existing FTTP service or a Working Line Take Over by another end customer, or both, in one transaction.

• Use the ONT details (Serial number/port number) to confirm which service is to be migrated when placing the order.

• Refer to the Change of CP section for more information about migrating an existing FTTP service between providers.

• Refer to the Working FTTP Line Takeover section for more information about arranging the cease and activation re-use of the same live ONT port on behalf of two different end customers.

An FTTP to FTTP migration will have an order subtype of Migration from GEA, the same as an FTTC to FTTP migration within the Openreach billing and MIS datasets.

A migration order can co-ordinate, through a single order instruction, all the transactions that are involved with moving:

• Changing from one technology (copper) to FTTP
• Changing from one service provider to another or from one CP wholesaler to another (whilst retaining the same customer/retailer relationship)
• Moving the phone number assignment from one service to another and one provider to another (Number port and number transfer)
• Ceasing redundant services only after the new services are working and automatically date managing the transactions if changes are needed.    

CPs specify which of these transactions they wish to incorporate into the migration order based on the parameters specified within the order, and more detail is in the Configure your product and service features section.

When you are ordering a copper to FTTP migration, it’s important to include the existing WLR or MPF service ID when placing the order.  So that both the copper voice and overlay data services are ceased.  If you only use the existing FTTC/SMPF service ID, only the data service will be ceased and the copper WLR or MPF line will be retained and will need to be ceased separately if no longer required.

Be aware that if you cease the copper WLR or MPF line separately, we may need a second, un-hosted visit to the outside of the end customer’s property to remove the copper drop-wire to avoid pole overloading which may require you to undertake an additional end customer conversation as part of the WLR or MPF cease order.

A copper to FTTP migration will have an order subtype for billing and MIS purposes depending on the copper service ID that you provide when you place the FTTP order, as follows:

•  If you use the underlying copper WLR or MPF service identifier:
  • Both the existing narrowband and any overlay broadband services will be ceased as part of the FTTP order journey.
  • The FTTP order subtype will be set as either Migration from WLR or Migration from MPF depending on which copper product is being migrated.
• If you use the broadband service identifier:
  • Only the broadband service will be ceased, leaving the underlying narrowband service active. In the case of FTTC over MPF, the FTTC service will still be soft ceased, leaving jumpers in-situ.
  • The FTTP order subtype will be set as e.g. Migration from SMPF or Migration from SOGEA or Migration from GEA in case of FTTC.

Here’s a summary of the response codes associated with copper to FTTP migrations.  These are not all the KCIs you’ll receive on an FTTP migration order, but they’re the ones specifically associated with the migration activities.

Notification of Transfer is an industry concept that is meant to prevent end customers from being sold a product or service that they don’t want.  The concept implements a 10-day cooling off period whenever an end customer is due to switch providers as part of entering into a new copper of FTTP contract with a different service provider.  During the 10-day transfer window, the losing service provider is informed of the service cease request so that they can communicate with their customer to inform them of relevant service cancellation charges and to enable the end customer to cancel the migration, via the losing service provider, if necessary.

A CP who is gaining a service (Gaining CP) can avoid the Notification of Transfer lead time if the retailer/service provider is staying the same before and after migration.  The retailer/service provider can achieve this by arranging with the losing CP (LCP) to ‘mark’ the service prior to the migration order being placed.  This is useful where a retail service provider is maintaining their relationship with the end customer, but wants to use a different wholesale supplier for the FTTP service.

By default, we will apply the Notification of Transfer on all migrations unless the losing service has been suitably “marked” and the ‘Change of retailer’ field = N in the order:

• CPs can use the ‘Same Retailer’ dialogue service on the Openreach portal to mark the losing asset to confirm there is no change in billing relationship with the end customer.

1.    Openreach will validate the ownership when the marker is set.
2.    If the marker is valid, we will progress the order without triggering the Notification of Transfer messages and lead times.

• Lead Times for an order will be decided based on the scenario identified by the ‘Same Retailer’ dialogue service, and whether the Change of Retailer value has been set to Y or N.

1.  Where Change of Retailer = Y for a migration order, or the ‘Same Retailer’ marker is not set, 10 days’ Notification of Transfer (NOT) lead-time will be applicable.
2. Where Change of Retailer = N for a migration order, and the ‘Same Retailer’ marker is set, a shorter lead-time may be used.

It is possible to change the underlying retailer, without changing the wholesaling CP.  Where this is the situation, a 10-day notification of transfer lead-time is required.  Here is a summary where the line is transferring retailers and where the line transfers wholesale CPs:

As part of a copper migration to FTTP, Openreach will initiate a managed cease of the existing copper service/s.  We will provide reasons to the existing copper voice and data providers as follows, depending on whether or not a number port request is also involved.

When an integrated number port / transfer IS NOT involved:

When an integrated number port/transfer IS involved:

Managed cease reasons when migrating only the losing broadband service:

Here’s how we trigger the various order milestone KCIs during managed cease orchestration:

CPs may request Number Port (NP), Number Transfer (NT) or Controlled Cessation (CS) while requesting migration of existing service to FTTP.

•       Only one request at a time will be dealt with.

•       If CP has supplied any two or all of these indicators on an order, Openreach will apply prioritization logic (NP > NT > CC) and accordingly CP will be informed by resetting the other parameters as part of KCI2.

•       Number Transfer is allowed only when there is no change in Retailer

Please note that for overhead served premises, where the fibre only drop-wire install process will lead to the removal of the existing copper drop-wire, the controlled cessation and parallel running process can be handled in systems, but in reality, the end customer’s copper service will no longer be functional after the copper drop-wire is removed.  And so, parallel running on overhead served premises won’t actually be possible.  Controlled Cessation and Parallel Running will still work for premises served by underground fibre.

Here are the high-level milestones associated with Number porting and transfers:

And a summary of the response codes associated with number port and controlled cessation.  These are not all the KCIs you’ll receive on an FTTP migration order, but they’re the ones specifically associated with the number port and controlled cessation activities:

While parallel running (where the existing copper line remains active for up to 10 days) can be selected on FTTP orders, the introduction of the overhead Fibre only drop wire severely limits the opportunity for actual parallel operation of the two services.  This is because when a fibre only drop-wire is used, the copper service will stop working when Openreach remove the copper to make way for the fibre on the installation day, irrespective of a CP’s desire to maintain a period of parallel running.  Actual parallel running of both services at the same time is only realistic at underground-fed premises where the existing copper lead in is not removed during installation.

How we issue KCI3 messages when parallel running has been specified on the order:

•       FTTP KCI3:

1.    If the migration order involved an engineering activity to install the ONT, then Openreach will trigger the FTTP KCI3 only after the engineer has successfully installed / activated the ONT, executed test on provision and proved the FTTP service on the CCD.

2.    If the CP ordered the FTTP service on an existing ONT and no engineering visit is required, Openreach will remotely activate the FTTP service and will trigger the FTTP KCI3 on the agreed CCD.

•       KCI3 on Losing Services:

1.    If parallel running period was not requested then,

•       Existing narrowband service will be ceased and manage cease KCI3 will be sent only after receiving KCI3 notification from gaining FTTP order.

•       Broadband service will be deactivated after receiving KCI3 notification from the order which had created the managed cease.

2.    If parallel running period was requested then

•       After receiving FTTP KCI3 notification, existing narrowband service will not be ceased but send KCI2.9 to losing CP and KCI3 notification to associated broadband managed cease order. This will cease only Broadband service.

•       When gaining FTTP order sends KCI3, losing narrowband order will send KCI2.9 to losing CP indicating start of a parallel running period.

•       During parallel period, Openreach will not accept any new fault on the losing narrowband service.

•       During parallel running window, gaining CP can use the appropriate Dialogue Service (Controlled Cessation, Number Export Activation) to end the parallel running period.

•       Openreach will complete number export or number transfer activity as requested or simply cease losing narrowband service in case of controlled cessation, either

•       At the back of execution of respective DS by gaining CP or

•       At the end of parallel running period after expiry of parallel run SLA if Porting Process = Auto-postpone or

•       As per the Fixed Porting Date requested in case of Number Port and Number Transfer only

•       Gaining FTTP CP will be informed about completion of number port/ number transfer activity by triggering an unsolicited KCI message. Losing narrowband CP will be informed of cessation of narrowband service by triggering KCI3 on the managed cease order.

In the event of FTTP install delay and delay to the sending of a KCI3 notification, it is possible to re-align the number porting instruction with the new KCI3. 

When KCI3 is sent, Openreach will move the port trigger start window to the day of KCI3 (Auto-postpone). The port window then reopens with the same duration as would have been there at the original CCD. (7 days for same CP. Up to 22:00 on KCI3 date for different CP).

At the end of the window, Openreach will auto-complete the port order if a port trigger hasn’t been received.

For fixed port, we will ignore the previously submitted fixed port date and revert the order to auto-postpone. This is to prevent an auto-port happening on the same day KCI3 is sent, without you being ready to import the number. When this occurs, we will send a new response code in KCI3 to advise you.

Note: When the exception is being closed by the Openreach SMC we will check if the current day is a working day. If it is, we will send KCI3; if not, Openreach will delay KCI3 until the next working day.

We will also change the window for Controlled Cessation to allow the Controlled Cessation trigger from GEA-FTTP KCI3 and not the CCD.

Action for CPs to take:

·         CPs will need to act on the receipt of KCI3 to initiate the import of the DN into your IP voice service.

·         You may need to change system logic on the import side of the order to allow for same day amends of your port order (if the import window has also expired). Else you will need to import the number as soon as you can.

·         If we have changed an order from Fixed Porting to Auto-Postpone we will send an additional warning response code in KCI3. This will be alongside 530 (Order Completed).

•   Response code: 9879 (The number port or transfer associated with this order has been changed to Auto Postpone. You will need to trigger the number port or transfer.)