Switch, Transfer, Takeover and Swap

Orders may be placed where there is an existing service that will be used rather than a new installation or a customer wants to move their existing service elsewhere, possibly keeping the same service(s) or changing service/technology. There are various different scenarios and also differing terminology used which are explained here. These are all forms of a provide order i.e. ProvideServiceOrder in the API

The following additional service characteristics will be required to specify the line/ONT/port.

  • ONT_REFERENCE (fibre-based service i.e. FTTP)
  • ONT_PORT (fibre-based service i.e. FTTP)
  • LINE_ID (copper-based services e.g. FTTC/SOGEA)

Start

orderType: START

In this scenario, an existing line or ONT (port) is available that is not currently in use and can be used. Also known as restart as the line/ONT may have been used before.

An appointment may or may not be required - this will be specified by the presence of installationType on the service availability response.

Transfer

orderType: TRANSFER

In this scenario, an existing line or ONT (port) is available that is currently active by a different provider and the service will be transferred to the gaining provider. This usually does not impact the customer's service. Also known as a service migration.

An appointment is usually not required - this will be specified by the presence of installationType on the service availability response.

Takeover

orderType: TAKEOVER

In this scenario, a customer is moving to a new address which already has an active service that they wish to use. Also known as a working line takeover.

An appointment is usually not required - this will be specified by the presence of installationType on the service availability response.

After placing a TAKEOVER order, the losing provider (and end customer) will be notified and will have the opportunity to object to the takeover. In certain scenarios, they can request the order be cancelled as a "cancel other" (see unsolicited cease below). This will result in the order being cancelled and the gaining provider will be notified of this via a cancel KCI.

Swap

orderType: SWAP

In this scenario, an existing line or ONT/port is currently active by the customer but the provider would like to replace the service with a different one which the current installation does not support. This is also known as a product family migration or regrade order.

An example would be moving from a copper-based service to a fibre-based service or updating the capabilities of the installed service e.g. upgrading to XG-PON or XGS-PON for increased downstream/upstream.

In most cases this will require installation work and hence an appointment will be needed. The current SERVICEID or LINEID should be sent as a service characteristic in the order.

Even though the order is initiated by the current provider, the supplier may still send an unsolicited cease for the current service - this would be sent with reason 'CP_REQUEST'.

Unsolicited Cease

In this scenario, an active customer is transferring/migrating to another provider and this is notifying the current tenant that they are leaving. Some suppliers may also send unsolicited ceases where the tenant changes access technology or performs regrades (change of line profile).

This is handled as a new order but differs in that it is created from the supplier sending a KCI so the tenant as the losing provider will not have created this order and has no ability to amend the order. Cancellation can be requested in certain scenarios (more information here).

The losing provider can also place their own cease order which will supersede the gaining provider's takeover order. This is usually required where the date of the takeover is disputed and the customer wishes their service to end on a different date to that on the unsolicited cease.

Number port

The above scenarios may also include a number port. This is where a customer has an existing service with a phone service/VOIP and are moving to a new address or to a different supplier or technology (that may or may be not installed) and they wish to retain their phone number.

The following additional service characteristics will be required:

  • DN _ PORT_NUMBER - Number to be ported
  • DN _ PORT_DATETIME - Requested date/time for the number port