open eir Carrier Pre-selection Industry Process Definition This service is no longer available to new customers from 8 th September 2016

open eir Carrier Pre-selection Industry Process Definition This service is no longer available to new customers from 8 th September 2016 Document No CPS 1819 Issue 10.1 2 18 th February 20098 th September 2016 STATUS ApprovedProposed

Document Control Revision History Version Date Revised by Revision Details 9.6 9.7 9.8 9.9 10.0 10.1 26 th June 2002 22 nd Dec 2002 05 th Oct 2004 14 th Dec 2007 29 th Oct 2008 18 th Feb 2009 open eir open eir open eir open eir open eir open eir 20 th Oct 2015 open eir Rebranded 10.2 08 th Sept 2016 open eir Withdrawal of CPS to new Customers. Associated Documents Title Location

Table of Contents Document Control... 2 1 Scope... 7 2 Introduction... 8 2.1 Introducing Carrier Pre Selection... 8 3 Definitions... 10 4 Overview... 12 4.1 Service Establishment... 12 4.2 Customer Advice... 12 4.3 Number Changes:... 14 4.4 Bit Stream product, ULMP and Line Sharing... 16 4.5 Proposed Time/Schedule Parameters... 16 4.6 Anti Slamming Measures.... 18 4.6.1 Reinstate Process... 21 4.6.2 Process flow description... 22 5 Order Handling... 23 5.1 Introduction... 23 5.2 Overview of CPS Gateway... 23 5.3 CPS Gateway Notifications Process... 24

5.3.1 Overview of Process Point Timelines... 25 5.3.2 C P S Gateway Notifications by Order Type... 25 5.4 Ordering Processes... 27 5.4.1 Data Request Orders for CPS (Data Request Carrier Pre-Select DRC) Introduction 27 5.4.2 Provide Orders for CPS (Provide Carrier Pre-Select PC) Introduction... 29 5.4.3 Cease Orders for CPS (Cease Carrier Pre-Select CC) Introduction... 30 5.5 CPS Loss Scenarios and Processes... 32 5.5.1 Service Change:... 32 5.5.2 Change of Number:... 32 5.5.3 Moves Orders (RF/RT):... 32 5.5.4 Transfers (Change of Name):... 32 6 Fault Handling for CPS... 34 6.1 Introduction... 34 6.2 Definitions... 34 6.3 Establishment of Contact Points... 36 6.3.1 Requirement for all CPS Operators... 36 6.4 Faults resulting from CPS Activation... 36 6.5 Faults reported to the Access Provider (AP)... 37 6.5.1 Customer Reported Faults to the AP... 37 6.5.2 Faults reported to the CPS Operator... 38

6.6 Interconnect Faults... 40 6.7 Fault Resolution... 40 7 CPS Service Enablement Testing... 41 7.1 Introduction... 41 7.1.1 Purpose... 41 7.1.2 Scope... 41 7.2 End-to-End Process Testing... 41 7.3 End-To-End Process Testing Review... 43 7.4 End-To-End Process Test Details... 43 7.4.1 Test Accounts... 43 7.4.2 Pre-requisites... 43 7.5 Account Flow Details... 45 7.5.1 Introduction... 45 7.6 7.6 Test scenarios:... 46 7.6.1 Test scenario 1... 46 7.6.2 Test scenario 2... 47 7.6.3 Test scenario 3... 48 7.6.4 Test scenario 4... 49 7.6.5 Test scenario 5...50 7.6.6 Test scenario 6... 51 7.6.7 Test scenario 7... 52

7.6.8 Test scenario 8... 54 7.7 Network Integrity Tests... 55 7.7.1 CPS Launch... 55 7.8 CPS Service Enablement trial success criteria... 56 7.8.1 Success criteria... 56 7.8.2 End-To-End Process Test... 56 7.8.3 Network Integrity Test... 57 8 IT Documentation... 64 9 Provision of forecasts... 65 10 Service Level Agreement... 66 11 CPS Change Management Process... 67 12 Document History... 69 Annex 1 Customer Authorisation Form... 69 Annex 2 Fax Forms... 71 Annex 3 CPS Order Forecast Form... 74 Annex 4 Contact Forms... 75 Annex 5 Activation Fault Report Form... 78 Annex 6 Emergency De-activation Fax... 80 Annex 7 Third Party Verification Introduction... 81 Annex 8 Supplementary CPS Manual Processes... 85 Annex 9 Bad Debt Process Process Diagram... 90

1 Scope This document defines the industry customer handling processes required to support Carrier Pre-selection. In particular the requirements for: Order Handling; Problem Management (Complaint and Fault Handling); Management Information and Service Level Statistics. The processes defined within this document will support the current (at document date) telecommunication range of products and services offered in Ireland. Future offerings may require the amendment of these processes to accommodate products and services that would otherwise not be supported.

2 Introduction The purpose of this document is to cover the inter-operator processes that are required to generate CPS orders. This document does not cover the internal operator processes, although it does contain some suggestions for operators to implement. The process requirements defined within this document are based on the industry discussions to date. All identified gaps and issues within the industry processes will be shown in this document as Italics and clear targets will be identified. Changes to this document will be controlled to ensure design integrity is maintained. Procedures for document control are to be decided at a later date. The members of the CPS committee acknowledge that a number of issues have arisen during the course of their work on this project, which have not been documented to the desired level of detail. The committee now meets every 6 weeks to review new or outstanding issues. 2.1 Introducing Carrier Pre Selection The ODTR has agreed that operators are eligible to provide CPS services to customers if they: i) Have either a Basic or General licence ii) Have a Network to Network Interface (NNI) with an Access Operator who is obliged to provide CPS facilities (currently Open eir only) iii) Comply with the Code of Practice for providing CPS services. The Code of Practice will be included in the Interconnect Agreement, which will ensure that any In some circumstances a customer may sign up for CPS through a reseller agreement. Though the existing CPS process does not specifically support resellers, the current process can accommodate them. Three CPS pre-selections will be available: 1. International Calls

2. National Calls 3. All Calls A customer may select any option individually, or a combination of the first two, with either the option.

3 Definitions This document describes the process requirements to enable an Access Operator to support a definitions have been made generic. The following terms are used throughout the document: - - is the operator providing the direct network connection to the customer, also known as the local loop provider or infrastructure operator. chosen category. - is the operator selected by the customer to carry their calls of a - is the person / organisation renting the access service. Operator. - is the category of calls the customer has elected to be carried by the CPS PS traffic choice - is International Calls excluding Northern Ireland (see Decision Notice) - is National Calls (including Northern Ireland) - is All Calls (as defined in document COB Close of Business (Monday Friday 1700 hrs) is a Customer Authorisation Form, which is physically signed by the customer wishing to change CPS service prior to a CPS operator submitting an order to open eir on behalf of this customer. refers to Third Party Verification, which is an independent means of verifying a ning the customer information required to submit a change to CPS service. It is conducted via the telephone, with a recording of the call serving as a record of

refers to the paper record of a TPV call. transmitted in a specific file format. - refers to an audio record of the TPV telephone call which can be

4 Overview 4.1 Service Establishment All operators planning to provide a CPS service are required to sign the Code of Practice and follow the processes outlined in this document. 4.2 Customer Advice The CPS Operator should make the following information clear to their customers: - 1. The customer must provide their Access Provider account number. 2. If the customer has call barring on their line for the type of CPS they are wishing to utilise (e.g. International calls) they must contact their Access Provider to remove the barring. 3. If the customer changes their name they are requested to advise both their Access Provider and CPS Provider. 4. If the customer changes address, without changing their telephone number they are requested to advise their CPS Provider. 5. If the customer changes their telephone number, and does not inform the CPS Provider the calls from the new telephone number will default to the Access Provider. 6. If the customer changes their CPS options from All calls to either international and/or National only, some of their traffic will default to the Access Provider. 7. If the customer has Open eir product they are not presently charged for calls forwarded to a local number. If, however the customer chooses All Calls with the CPS Provider these local calls may be charged for. 8. The customer will continue to receive a bill for line rental from the Access Provider, and billing information for any calls that have been routed over the Access -ride code (in favour of the Access Provider) or a change in CPS status as previously described.

9. If the customer applies for additional lines with their Access Provider, and is provided with new telephone numbers the customer must contact their CPS provider to lines will default to the Access Provider.

4.3 Number Changes: The following pertains to number changes that affect only the call origination aspect of CPS calls from a CLI perspective and CPS order validation/handling issues. Number changes that pertain to non-cps call origination and call termination are outside the scope of this document. The ODTR will provide all operators with details of number changes including dates that the number change will take effect, length of parallel running, length of time that the recorded announcement should be kept on the old number after the parallel running period is finished and any other information that is relevant for the number change. Subsequent to a number change being co-ordinated for any given STD code, there is a period of 6-12 months parallel running where the old and new number can be called. After this period of parallel running is finished service ceases on the old number i.e. if the number is called it will be routed to a recorded announcement and the new number is the only method of identifying and contacting the customer. The significance of number changes in the CPS context is that the calling line identity (CLI) that is forwarded to the CPSO for originated CPS calls cannot exist in parallel with the new CLI and must be changed to the new CLI on an exchange and/or number range basis on a specific date. Once implemented for a particular exchange/number range, only the new CLI is operational and will be forwarded to the CPSO for all CPS calls originated from that exchange/number range. There is a requirement for the AP to notify the CPSO of the planned changeover dates and schedule at least 6 weeks in advance on an exchange/number range basis this will give It is also not possible for the CPS order handling hub and process to operate in parallel for the old and new CLI. Once implemented for a particular number range, only the new CLI will be recognised by the order handling system. Orders submitted with the new CLI before changeover date and orders submitted with the old CLI after the changeover date will be rejected. Furthermore orders that have been accepted with the old CLI but are not scheduled to be implemented until after the exchange changeover date will fail activation an order placement freeze is required for the appropriate CLIs five days before the changeover date. There is also a requirement for the AP to notify the CPSO of the planned system changeover dates and

schedule at least 6 weeks in advance on an exchange number basis this will give the CPSO contacts form in Annex 4. There is a requirement for the records systems to reflect the new CLI appropriately at/after the changeover date.

4.4 Bit Stream product, ULMP and Line Sharing 1 With regard to ULMP order processing open eir will check the path for CPS. An order for ULMP for a line with CPS is effectively a cease order for CPS. Where CPS is active on the path, open eir will forward a loss notification to the losing CPS operator. Note that a losing CPS operator may not then invoke the LLU retail defence process for CPS. 2 If a CPS order is submitted for a line that has been unbundled the CPS order will be rejected. 3 An order for Line Sharing will have no effect on CPS. 4 No conflicts have been identified with bitstream and the operation of CPS on the same line. The addition of bitstream to a CPS line will not affect the CPS service and vice versa. 4.5 Proposed Time/Schedule Parameters The following time parameters have been agreed for the handling of CPS orders: 1. Day References Day 0: Order sent to AP (can be activation or cease order) Day 1: Order accepted / rejected by AP Day 1- Day 5: AP activation or AP cease AP activation or cease notification will occur by close of next business day after the activation or cease has taken place. In some circumstances, activation will take place prior to the AP accepting the order. Consequently, CPSOs are advised to have any provisioning necessary on their system completed prior to the receipt of order acceptance. 2. Working Day : 09:00 17:00 Monday to Friday (excluding Irish public holidays) 3. Electronic File Transfer can take place at any time. However it must be realised that batches of orders delivered out of the working day will not be dealt with until the

commencement of the next working day. The timing of the order must therefore be monitored from the commencement of that working day. 4. Acceptance/rejection of order: - by 1700 hrs of the next working day 5. Re-presentation of order: After correction of a rejected order, the order is resubmitted to the AP. It cannot be resubmitted after 1700 hrs on Day 3. If no represent is provided on a rejected order within the specified timescale, the order will be considered to have timed out. It will therefore be necessary for the CPS Operator to issue a new Activation order. 6. Cancellation: - An order technically cannot be cancelled while it is in progress. The order will be completed and will be activated by the Access Provider. 7. Change of choice of CPS option during CPS activation process: - if a customer wishes to alter the CPS option type the CPS Provider must send a new activation order for the preferred CPS choice. The current order cannot be cancelled. 8. Total period of time elapsed from issue of request for CPS activation to CPS activation: - maximum 6 working days (including day of transmission of

order to Access Provider) where the order is accepted by the AP. 9. Notification of activation from Access Provider: - Notification should be sent to the CPS operator at latest by 17.00 hours on Day 6. 10. Advance orders. - If the customer request a CPS provision date which is beyond the normal provisioning time-cycle it is the CPS Providers responsibility to enter the order into the provisioning cycle at the correct time in order to meet the customers expectations. Advance orders will not be accepted by the Access provider. 4.6 Anti Slamming Measures. Information on the Customer Authorisation Form and anti-slamming process The CAF/TPV CAF and voice recording are held by the gaining CPS Operator, and not sent to the Access Provider The gaining CPS/TPV CAF and voice recording Operator must retain all CAF for at least six years If the CAF/TPV CAF and voice recording is the subject of a dispute it may be required to be kept for a longer period Copies of the CAF/TPV CAF and voice recording can be requested in the event of a dispute Copies can be requested from the gaining CPS Operator by either the Access Provider or the losing CPS Operator If requested by either party the gaining CPS Operator must provide a copy within 2 business days, however if the order is older than two years the CPS Provider must produce a copy within three weeks. If the requesting party is not satisfied with the copy of the CAF they can request tosee the original CAF. This will be provided within one working week.

A sample of CAFs/TPV CAFs and voice recordings can be requested once a month for audit purposes The sample must come from a batch where the requesting party is one of the two possible roles, losing CPS Operator or Access Provider Requests for, or exchange of, CAFs/TPV CAFs and voice recordings can only be made between nominated parties/areas within each company. The TPV voice file can be supplied via email in an agreed file format. If the gaining CPS Operator cannot provide a copy of the CAF/TPV CAF and voice recording within the specified Time, or the CAF/TPV CAF and voice recording is deemed invalid, the losing CPS Operator can (at the request of the customer) ask for the CPS choices to be reversed. The Access Provider will charge this transaction to the requesting operator who shall be entitled to recover this charge from the gaining

shown in Annex 1. Each CPS Operator must nominate in writing a single area (referred to (a) (b) (c) Making requests for copies or production of CAFs; and Complying with requests for copies or production of CAFs. Shall be the single location for holding CAFs by that operator. A request for a copy or production of a CAF made by an operator under this code may only be Operators and Access Network Operators providing CPS facilities must ensure that their Nominated Areas maintain statistics on: (a) (b) (i) (ii) The number of requests; and Performance in relation to: the timeframes in which the operator responds to requests: and the number of unsatisfied requests Operators must not permit its employees other than those employed within the Nominated Area to request copies or presentation of CAFs from Gaining Operators. All operators are required to support the following CPS Operator Identification Codes. At any time a customer can identify what operator they are trafficking with, for a particular call option, through use of the following CPS Operator Identification Codes (i) (ii) (iii) 19800 International Calls 19801 National Calls 19822 Local Calls

4.6.1 Reinstate Process

4.6.2 Process flow description 1. If necessary, the losing operator will contact the gaining operator to request a copy of the CAF/TPV CAF and voice recording to prove the CPS order is legitimate. 2. If a valid copy of the CAF/TPV CAF and voice recording is provided, the losing operator will have to accept this. 3. In the event of a valid CAF/TPV CAF and voice recording being produced, the matter shall be considered closed. 4. In the event of a valid CAF/TPV CAF and voice recording not being produced, steps 2-7 of the activate order will apply. 5. AP will send a cease notification to the losing operator who could not produce the CAF/TPV CAF and voice recording. (Notification of losing operator is subject to agreement and conformance to all data Protection legislation and competition law) Document CPS 18 Issue 9.8 20 th February 2009

5 Order Handling 5.1 Introduction The end-user will purchase services from the CPS Operator, entering into the necessary contractual relationship with them. The CPS Operator can take over the National, International, or All Calls. This section outlines the industry processes for the ordering of CPS call on existing accounts via the Wholesale Unified Gateway [the Gateway]. For full details of the order types refer to the latest Data Contract. All orders for Carrier Pre-Select Calls shall be placed via the wholesale Unified Gateway. Each CPS Operator shall receive a signed Customer Authorisation Form (CAF) from the customer or have on file, a TPV CAF and voice recording containing all the relevant details of their CPS order. The CAF form can be posted or faxed to the CPS Operator. The TPV voice recording can be emailed to the CPS operator or in the case of the TPV CAF, this can be emailed/faxed to the CPS operator as appropriate. This standard section is contained in Annex 1 of the Carrier Pre-Selection Industry Process Definition. This document will not be transmitted as part of the standard order exchange. The IT specifications for the data exchange between open eir and the CPSO is detailed in the Unified Gateway Data Contract (which can be accessed by CPSO system administrators from the Unified Gateway web GUI). 5.2 Overview of CPS Gateway The Gateway is implemented using an FTP protocol and the Transfer Syntax is XML. Files are delivered to an external server address, and are subsequently available for collection by the CPS Operators.

Detailed specification of the information required on placing an order and the information supplied on completion is defined in the Data Contract and should be read in conjunction with this Inter-operator Process Manual. All CPS orders shall be placed via the Unified Gateway. 5.3 CPS Gateway Notifications Process The following information is supplied by open eir for information purposes only and is intended to provide a summary view of all the notifications contained within the Wholesale Unified Gateway Data Contract for CPS Operators. The order processes utilised for CPS include four types of notifications: Accepted Rejected Undeliverable Completion

order types are explained below. cations to each of the CPS Note: Undeliverable Notification all Unified Gateway order types. An order is marked Undeliverable during the delivery process in the cases where the request cannot be implemented at time of processing or when a CPS Operator themselves requests the AP to mark the order as undeliverable. When the order is ing is done and the CPS Operator is sent an 5.3.1 Overview of Process Point Timelines There are two significant dates relating to the delivery of CPS products. These are: Validation Due Date: date by which the order is Accepted or Rejected, Delivery Due Date: date by which the order is Delivered or Undelivered. The day the order is received is Day 0. Both the Validation Due Date and the Delivery Date are calculated with reference to Day 0. The timelines outlined for each process are adhered to in respect of the various order types. However, significant proportions of these order types are delivered well within these timelines. 5.3.2 C P S Gateway Notifications by Order Type The four notifications in the table below are the only notifications types applicable for CPS order types. The content of each of these notifications is described in detail in the Data Contract.

A summary of the allowable notifications per CPS Order Type is provided in a tabular format below. Please refer to the Data Contract for details of the specific content of these order types and notifications. Order Type PC Description R A C U Provide Carrier Pre- Select: ~ ~ ~ ~ International Calls National Calls CC National & International Calls Only Cease Carrier Pre-Select ' ~ ~ ~ DRC indicate Customer Request Data Request for CPS ~ ~ ~ 5.4 Ordering Processes This section of the document outlines the three ordering processes associated with Carrier Pre- Select on the Unified Gateway. The three order types are Data Request, Provide CPS and Cease CPS and these processes are outlined in turn below. 5.4.1 Data Request Orders for CPS (Data Request Carrier Pre-Select DRC) Introduction The process below describes how a CPS Operator can obtain account details relating to CPS services on existing open eir Retail lines. Each CPS Operator shall obtain a signed CAF (Customer Authorisation Form) from their customer in order to place an enquiry with the AP. The CPS Operator must have, on file, the original CAF signed by the customer. Process:

- Data Request order (Order Type DRC) is submitted via the Gateway on Day 0. - - The Access Provider will accept or reject the order (with valid rejection codes) by close of business on day 2. - If the order is rejected, it is returned to the CPS Operator via the Unified Gateway with a rejection code stating the reason for rejection. - If the order has been accepted then the relevant details of the account will be returned within the completion notification on day 2. There are no acknowledgement notifications for this particular order type. - The completion notification contains:

o o o Customer Account Number (UAN) CLI Details DDI Block Number Ranges Detailed specification of the information required on placing an order and the information supplied on completion is defined in the Unified Gateway Data Contract and this contract should be read in conjunction with this Interoperator Process Manual. 5.4.2 Provide Orders for CPS (Provide Carrier Pre-Select PC) Introduction The process below describes how a CPS Operator places CPS orders on existing open eir Retail lines. Process: - Provide order (Order Type PC) is submitted via the Gateway on Day 0. - to apply CPS to including the CPS product type (e.g. Service Code). - customer. - The Access Provider will accept or reject the order (with valid rejection codes) by close of business on day 1. - If the order is rejected, it is returned to the CPS Operator via the Unified Gateway with a rejection code stating the reason for rejection. - If the order has been accepted, an acceptance notification is sent to the CPS Operator via the Unified Gateway with an expected Delivery Due Date. - The CPS activation will be completed by the AP between day 1 and day 5 of the process.

- On completion the CPSO will receive a completion notification. Notification of activation will be sent to the CPS provider by the close of the working day following activation. This notification contains: o Confirmation of the set up of the CPS product including the date of transfer to the CPS Operator Detailed specification of the information required on placing an order and the information supplied on completion is defined in the Unified Gateway Data Contract and this contract should be read in conjunction with this Interoperator Process Manual. Note: The PC order type contains an action flag that must be populated with either an A or a B. indicates to bring back CPS service that was removed 5.4.3 Cease Orders for CPS (Cease Carrier Pre-Select CC) Introduction The process below describes how a CPS Operator can cease a CPS service on existing open eir Retail lines. This order type is utilised for both customer-requested ceases and a credit management ceases.

Process: - Cease order (Order Type CC) is submitted via the Gateway on Day 0. - to cease CPS on including the CPS product type (e.g. Service Code). - lled as before. - The Access Provider will accept or reject the order (with valid rejection codes) by close of business on day 1. - If the order is rejected, it is returned to the CPS Operator via the Unified Gateway with a rejection code stating the reason for rejection. - If the order has been accepted, an acceptance notification is sent to the CPS Operator via the Unified Gateway with an expected Delivery Due Date. - The CPS de-activation will be completed by the AP between day 1 and day 5 of the process. - On completion the CPSO will receive a completion notification. Notification of deactivation will be sent to the CPS provider by the close of the working day following de-activation. This notification contains: o Confirmation of the de-activation of the CPS product including the date of transfer from the CPS Operator Detailed specification of the information required on placing an order and the information supplied on completion is defined in the Unified Gateway Data Contract and this contract should be read in conjunction with this Interoperator Process Manual. Note: The CC order type contains an action flag that must be populated with either an R or a T. indicates to terminate service for credit management reasons.

5.5 CPS Loss Scenarios and Processes 5.5.1 Service Change: A weekly check is done within open eir to identify if CPS was lost in cases where orders are submitted to change service on lines as follows. Hunting Removed Voicemail is applied Upgrades/Downgrades of the line If CPS is lost from the line in these scenarios it is reapplied by open eir and the OAO is notified. 5.5.2 Change of Number: CPS is lost and the OAO is notified on a weekly basis in all cases Note: As part of the number change process result in the loss of CPS. customers are advised that changing the CLI will 5.5.3 Moves Orders (RF/RT): CPS is retained in cases where there is no change in CLI. CPS is lost in cases where there is a change in CLI. 5.5.4 Transfers (Change of Name): CPS is lost off all accounts where a transfer occurs and there is a Division of Account CPS is retained on all accounts where a transfer occurs and there is a Non- Division of Account Note:

Division of Account: In this instance, the renter of the line changes even though service is uninterrupted on the line. A final bill issues to the old renter and a new account is established for the new renter. Non-Division of Account: In this instance, while the name of the account holder changes, the account number remains the same and no final bill issues.

6 Fault Handling for CPS 6.1 Introduction This section describes the post provisioning process for dealing with fault reporting, handling and escalation procedures for CPS services. 6.2 Definitions DEFINITION AP CPS Repair Centre EXPLANATION This is the incumbent operator, whose network is used to provide the CPS service. In this case the only such AP in the market is open eir. This Centre provides a fault reporting and management facility for CPS faults (including access network related faults) reported directly to them by the CPSO on behalf of their customer. This the centre will CPS Support Centre Fault This Centre deals with CPS order handling and activation related faults - or degradation to a their normal voice service quality. Fault Report This is a Ticket raised by the CPSO to the CPS Repair Centre. The CPSO may contact the repair centre using the freephone number provided where a fault report will be opened.

Trouble Ticket This is a ticket opened by the AP on receipt of a fault notification directly from a CPS customer over the phone to the AP retail fault reception area. Interconnect Ticket Trouble This is a Ticket raised by an OLO to open eir interconnect core fault NMC relating to an Internal Trouble Ticket This is

6.3 Establishment of Contact Points operator and Access Provider shall complete and exchange the essential contacts sheet shown in Annex 4. This sheet will need to be amended to include contact details for the CPS Repair Centre and appropriate equivalent contact details for the CPSO 6.3.1 Requirement for all CPS Operators As part of the Fault Handling process all operators are required to support the following CPS Operator Identification Codes. At any time a customer can identify what operator they are trafficking with, for a particular call option, through use of the following CPS Operator Identification Codes (iv) (v) (vi) 19800 International Calls 19801 National Calls 19822 Local Calls 6.4 Faults resulting from CPS Activation The CPSO may identify faults resulting from the incorrect activation of CPS category on a customers telephone line or a complete loss of CPS service These faults should be received directly from the customer to the CPSO These faults should be e:mailed by the CPSO to the AP's CPS Support Centre using part 1 of the Fault Report Form provided in Annex 5. The AP will correct the CPS category on the customers telephone line and then complete part 2 of the Fault Report Form as provided in Annex 5. This is then returned to the CPSO by e:mail. Where the CPS category has been correctly provided by the AP, the CPSO will be advised as such, in the same manner. Where an activation fault has been logged with the AP CPS support centre and the CPS category has been verified to be correctly provided on the line, the problem may be with the CPSO network. In such cases the CPSO can send a Notice of CPS Traffic Restoration request Centre. This request will follow the emergency deactivation process which ensures that such

orders will be prioritized by the AP CPS order handling staff to ensure quick turn-around in comparison to normal cease orders. The form as defined in annex 6 will be used and will be The emergency de-activation process can also be used where the customer reports a complete loss of a CPS category service to the CPSO. 6.5 Faults reported to the Access Provider (AP) 6.5.1 Customer Reported Faults to the AP Customers may report faults via the AP's normal customer retail fault process only if the fault appears to be AP / access network specific. If the customer is experiencing difficulty with incoming calls this should also be reported to the AP, in the normal manner as CPS services only operate on out-going traffic The customer should be advised that they should contact the CPSO with regard to all other CPS faults. In such cases, where the fault is AP / access network specific, the AP retail repair centre will investigate the fault and if the problem is found to be in the access

network will own and resolve the problem. The access netwo NTU/NTP If the fault is found not to be within the access network the AP retail repair centre will identify the operator providing the particular service with which the customer is experiencing difficulties. If the service is provided by a CPSO, the customer will be instructed to contact their CPSO. When contacted by the customer, the CPSO follow the process as outlined in Section 6.5.2. 6.5.2 Faults reported to the CPS Operator The CPS Operator will confirm that the fault is being reported by a valid customer. The CPSO will investigate the fault and, if the problem is found to be in their network, the CPS Operator will own and resolve the problem. The CPSO must ask the customer to confirm if the customer can successfully complete calls using the CPS over-ride code 13666. If such calls complete successfully it indicates that the sed to the CPS referred to the AP Retail Repair Centre (again assuming that the CPSO has proved the fault out If a CPSO proves a fault out of their network and 13666 calls complete successfully, the CPSO will pass on the available pertinent fault details and ownership of the fault to the CPS Repair Centre. The CPSO will indicate how the fault was proven out of the CPSO network and why it appears to be AP related. It is important that the CPSO provide the CPS repair Centre with as much detail as possible in order that the fault be isolated and resolved in a timely manner. This detail will include that the customer could complete calls using the CPS over-ride code 13666 and the CPSO trouble ticket number that was assigned to the fault to prove the fault out of the CPSO network before passing to the AP It is the responsibility of the CPSO to advise the customer that the fault has now been passed to the AP for investigation but that the customer will continue to obtain updates with regard to the fault from the CPSO, and not the AP.

The CPS Repair Centre will then investigate the fault, and if the problem is found to be in the access/ap network will own and resolve the problem. The CPSO will be able to obtain updates on the fault upon request, using the CPS repair centre telephone number as a reference where necessary. the status of action taken by the CPS Repair Centre to address the reported fault where appropriate. If the fault is not access network related the CPS Repair Centre will establish that the CPS option is correctly built in the AP's network. If the CPS option is not built correctly in the Support Centre. The CPS Support Centre will correct the CPS category and the CPSO will be advised of same and subsequent fault clearance by the CPS Repair Centre. If the fault is found not to be within the access network or with CPS category build, the CPS as appropriate. The CPS NMC and provide the CPSO with updates of same upon request. email the fault report that was initially opened with the appropriate will

updates to the CPSO and close the fault report if no update has been received from the CPSO within 24 hours. The CPSO should notify the AP of receipt of this mail by indicating to them the CPSO trouble ticket number that they have assigned to this fault. If an update has been received from the CPSO within 24 hours to indicate that a problem still exists within the AP network the fault report will be re- appropriate for final investigation before being closed Throughout the life cycle of the fault, the CPS repair centre will liaise only with the CPSO. It is the responsibility of the CPSO to liaise with the end customer. 6.6 Interconnect Faults Interconnect and core network faults relating to CPS will be handled in exactly the same manner as all other interconnect faults using the processes defined in the interconnect O&M manual. 6.7 Fault Resolution Both Parties shall resolve faults, except CPS category faults, within their normally quoted customer repair time frames. Fault escalation will be as provided for in Annex 4. Where an interconnect Trouble Ticket has been raised, the fault will be resolved within the O&M defined time frames and escalation will apply.

7 CPS Service Enablement Testing CPS industry order handling test script for use in CPS Service Enablement Tests 7.1 Introduction 7.1.1 Purpose This document defines the test schedule for the Carrier Pre-selection Service Enablement Tests (SET). The SET consists of end-to-end order handling tests with a network and call/call record validation element. It should be used in conjunction with the table at the end of Section 7 that shows the required testing scenarios for CPS. 7.1.2 Scope Testing will be undertaken under two broad headings - End-to-End Process Testing and Network Integrity Testing The purpose of the End-to-End Process Testing test schedule is to check the transport, update, interrogation and acknowledgement mechanisms used to provide CPS orders between CPS Operators, and Access Providers culminating in the successful generation of one or more test calls and mutual validation of call records. The orders will be exchanged using electronic file transfer, and will use the processes, and timescales defined in the industry CPS process document. The use of the back-up method of exchanging orders, i.e. by facsimile, will also be tested. The purpose of the Network Integrity Testing test schedule is to verify the mutual call handling capability of CPS Operator and Access Provider networks from a minimum of five Access Provider exchanges that are geographically dispersed across Ireland. There will be no mutual call record validation but the CPS operator must be able to verify that call records were received for all test calls and produce same at the Access Operators request. 7.2 End-to-End Process Testing In order to complete the tests detailed below it is expected that a CPS Operator will set up retail accounts with the Access Provider for the appropriate customer types. This will ensure that actual customer information is used for order handling. The tests presently require a CPS

Operator to have analogue single line accounts, BRA ISDN connection(s), and two-line hunt group(s). Call detail records will be generated for all test calls as part of the tests. In order to assist in the finding of the CDRs a test call sheet is shown at the back of the document, to enable the date, time, and duration of the calls to be recorded, along with the test numbers used. Testing will be conducted using the various types of customers that may wish to take CPS. The tests enable each key order type to be generated, and orders to be accepted and rejected. A total of 8 order scenarios will be available for use during testing. These will relate to valid Access Provider account details, and will allow CPS to be applied to the numbers, except for test scenario 6. The testing also includes the initiation and issue of notification of loss to the losing CPS Operator, by the Access Provider. Test scenarios will also include testing of 1) CPS forwarded calls (is not mandatory for successful test) 2) CPS with per call CLIP activation 3) CPS with per call per CLIR activation

In order to test the rejection of orders some deliberate errors will be applied to certain orders. The details of these are shown in the appropriate test scenarios below. If a CPS Operator will only be offering national and/or international CPS the types of customers should be changed to reflect the appropriate CPS types. 7.3 End-To-End Process Testing Review At the end of the testing and at appropriate points throughout, the results will be compared with the expected results and agreement will be reached on the nature and ownership of any problems encountered. It is however expected that the appropriate contacts in the two companies will liase closely to identify problems as early on in the test scenarios as possible. If a test scenario has been deemed to fail by both parties it may be necessary to re-commence the testing activities for the appropriate scenario. The two Operators must agree whether the testing should commence from the beginning of the test scenario, or simply from the identified point where problems occurred. The success criteria documented in Section 7.8 will be used to identify and agree if testing between the two operators has been successful. 7.4 End-To-End Process Test Details 7.4.1 Test Accounts Testing will be done using up to a maximum of eight test scenarios. These account details will be provided by the CPS Operator and will consist of a series of different customer installations as defined below, and explained in the testing section above. 7.4.2 Pre-requisites Before testing can commence, the following must be in place, or have been exchanged between the two Operators: Tested electronic link and valid batch/order placement capability for the exchange of CPS orders

Fax numbers to be used in the event of the electronic link failing Contact telephone number for queries regarding to CPS orders Escalation points for queries on CPS orders Appropriate databuild to allow for the successful exchange of CPS calls from the point of origination, to the appropriate point of interconnect Any appropriate contracts to enable the testing to take place (if required)

7.5 Account Flow Details 7.5.1 Introduction There are certain testing scenarios that specifically include induced errors, for the purposes of testing order rejections. However, if in any of the scenarios actual, non-induced errors are encountered then the scenario should be changed to take account of these i.e. if a provide is sent with an error, the order should be rejected even if the grid states that the order should be accepted. The failed test element must be re-tested. Orders should be acknowledged using the normal timescales for response. The table shows the maximum time allowed to respond to an order (i.e. close of business on the next working day). However, orders can be accepted or rejected at any point between receipt and the end of the next working day.

7.6 7.6 Test scenarios: 7.6.1 Test scenario 1 Single line customer, requiring International CPS only 7.6.1.1 Purpose: To prove that a Provide Order can be placed and implemented successfully, and a CPS notification of completion issued by the Access Provider. Also, to prove that a notification advising of an Access Provider Cease can be issued, corrected and accepted. The CPS Operator sends a provide order on day 1, with no errors. The Access Provider accepts the order before close of business on day 2. On day 4 CPS is applied to the customer line. The Access Provider issues a notification of activation to the CPS Operator. On receipt of the notification of activation the CPS Operator contacts the customer, and makes the appropriate tests to prove that CPS is working as required at least one test call to an International destination must be made. The details of the test calls should be documented. On day 6 the Access Provider should remove CPS from the customer line, and issue notification to the CPS Operator that they have ceased CPS. The reason for the cessation can be chosen from one of the appropriate codes documented in the CPS process document, such as the customer has changed their number. The Access Provider cease should have an induced error. The CPS Operator will reject the notification before close of business on day 7. On day 8 a corrected Access Provider cease (without error) should be issued. By close of business on day 9 the CPS Operator should accept the notification.

7.6.2 Test scenario 2 Single line customer, requiring National and International CPS 7.6.2.1 Purpose: To prove that a Provide Order can be placed and implemented successfully, and a CPS notification issued. Also, to prove that a CPS Operator cease can be issued, and implemented, and the notification of completion can be issued, and accepted. The CPS Operator sends a provide order on day 1, with no errors. The Access Provider accepts the order by close of business on day 2. On day 4 CPS is applied to the customer line. The Access Provider issues a notification of completion to the CPS Operator. On receipt of the notification of completion the CPS Operator contacts the customer, and makes the appropriate tests to prove that CPS is working as required at least one test call to a National and International destination must be made. The details of the test calls should be documented. On day 6 the CPS Operator issues a request to cease CPS on the customer line. An appropriate reason for CPS cessation should be used. These are documented in the CPS process documentation. The notification to cease will be accepted by the Access Provider by close of business on day 7. On day 9 CPS will be removed by the Access Provider on the customer number. The Access Provider will issue a notification that the cease has taken place. The notification should contain no errors..

7.6.3 Test scenario 3 Single line customer, requiring CPS all calls. 7.6.3.1 Purpose: To prove that a Provide Order can be placed and implemented successfully, and a CPS notification of completion issued by the Access Operator. Also, to prove that a CPS Operator cease can be issued, and implemented, and the notification can be issued, and accepted. The CPS Operator sends a provide order on day 2, with no errors. The Access Provider accepts the order before close of business on day 3. On day 5 CPS is applied to the customer number. The Access Provider issues a notification of completion to the CPS Operator. On receipt of the notification of completion the CPS Operator contacts the customer, and makes the appropriate tests to prove that CPS is working as required at least one test call to local (without dialling the STD code), National, International and one non-geographic numbers must be made. The details of the test calls should be documented. On day 7 the CPS Operator issues a request to cease CPS on the customer line. An appropriate reason for CPS cessation should be used. These are documented in the CPS process documentation. The notification to cease will be accepted by the Access Provider by close of business on day 8. On day 10, CPS will be removed by the Access Provider on the customer number. The Access Provider will issue a notification that the cease has taken place. The notification should contain no errors.

7.6.4 Test scenario 4 An ISDN customer, requiring National and International CPS. 7.6.4.1 Purpose: To prove that a Provide Order can be placed, and rejected appropriately. The CPS Operator sends a provide order on day 3, with induced errors. An example of an appropriate error could be failing to include number, which is mandatory for multi-line orders. The Access Provider rejects the order before close of business on day 4, with the appropriate reject code(s). The CPS Operator should take no action at this time. A new provide order should be issued by the CPS Operator on day 6, with no errors. The Access Provider should accept the order by close of business on day 7. On day 9 CPS is applied to the customer line. The Access Provider issues a notification of completion to the CPS Operator. On receipt of the notification of completion the CPS Operator contacts the customer, and makes the appropriate tests to prove that CPS is working as required at least one test call to local (without dialling the STD code), national, International and non-geographic numbers must be made. The details of the test calls should be documented.

7.6.5 Test scenario 5 An ISDN customer with multiple ranges, requiring CPS all calls. 7.6.5.1 Purpose: To prove that a Provide Order can be placed and rejected appropriately by the Access Provider. Also, that the same order can be corrected, and resubmitted. The CPS Operator sends a provide order on day 2, with induced errors. An example of an appropriate error could which is mandatory for multi-line orders. The Access Provider should reject the order by close of business on day 3, using the appropriate reject code(s). The errors should be corrected, and the order re-presented by the CPS Operator by close of business on day 4. The Access Provider should accept the order by close of business on day 5. On day 7 CPS is applied to the customer number(s). The Access Provider issues a notification to the CPS Operator. On receipt of the notification of completion the CPS Operator contacts the customer, and makes the appropriate tests to prove that CPS is working as required. The details of the test calls should be documented.

7.6.6 Test scenario 6 A large quantity of orders (50-100 orders) can be placed and accepted/rejected in one batch. The batch should be made up of live Access Operator single line and multi-line customers. CPS 7.6.6.1 Purpose: To prove that a large quantity of orders can be issued, and dealt with appropriately. The CPS Operator sends on the batch on day 4. Some orders should include induced errors, others should be correct. The Access Operator should respond appropriately to the orders by close of business on day 5. This means accepting correct orders, and rejecting orders with errors. Orders rejected should not be re- The Access Provider will issue notifications of completion that CPS has been applied during days 7 and 8. The CPS Operator may follow the appropriate processes to contact the CPS customer. However, it must be remembered that CPS has not been applied in the Access Provider network and test calls cannot be made. It is u

7.6.7 Test scenario 7 A multi-line customer, with non-contiguous numbers, not in a hunt group with inter-cps Operator dispute culminating in a request and delivery of a CAF/TPV CAF and voice recording. The type of CPS required will be national only. It is necessary for the two CPS triallists to work together during this test scenario, to test the resolution of a dispute. It must therefore be agreed which role the two triallists must take, CPS Operator 1 or 2. 7.6.7.1 Purpose: To test and prove that, if required, two CPS Operators can request and exchange a copy of the customer signature. CPS Operator number 1 sends a provide order on day 1, with no errors The Access Provider should accept the order by close of business on day 2. On day 4 CPS Operator number 2 issues a provide order, with no errors. The Access Provider accepts the order by close of business on day 5. During day 5 the CPS request issued by CPS Operator 1 will be applied to th numbers. The Access Provider issues a notification of completion to the CPS Operator. On receipt of the notification of completion the CPS Operator contacts the customer, and makes the appropriate tests to prove that CPS is working as required at least one call to a National destination is required. The details of the test calls should be documented. numbers. The Access Provider issues a notification of completion to CPS Operator 2. On receipt of the notification of completion CPS Operator 2 contacts the customer, and makes the appropriate tests to prove that CPS is working as required. The Access Provider will also issue a notification to CPS Operator 1, advising of the loss of the CPS customer.

CPS Operator 1 should accept the notification by close of business on day 8. CAF and voice recording. The contact should take place between the correct contact points between the two companies for the exchange of customer details. recording via appropriate channels. By close of business on CAF/TPV CAF and voice recording are valid, and close the dispute process.

7.6.8 Test scenario 8 A multi-line customer, with non-contiguous numbers, in a hunt group with inter CPS Operator dispute culminating in a request, failure to deliver CAF/TPV CAF and voice recording and subsequent issue of a re-instate order. The type of CPS required will be national only. A main - is necessary for the two CPS triallists to work together during this test scenario. It must therefore be agreed which role the two triallists must take, CPS Operator 1 or 2. 7.6.8.1 Purpose: sends a reinstate order on day 3, with no errors ations. CPS Operator 2 The Access Provider accepts the reinstate order by close of business on day 4. numbers. The Access Provider issues a notification of completion to CPS Operator 2. On receipt of the notification of completion the CPS Operator contacts the customer, and makes the appropriate tests to prove that CPS is working as required. The details of the test calls should be documented. The Access Provider should also issue a notification of loss to CPS Operator 1. The notification of loss should be accepted by CPS Operator 1 by close of business on day 7.

7.7 Network Integrity Tests 7.7.1 CPS Launch Section 1 All CPS Operators wishing to launch CPS operations must undertake this test. The testing will primarily verify the roll-out of the CPS functionality databuild across the Access Provider's network. CPS test calls will be generated by Access Provider Field Staff from a minimum of 5 Access Provider exchanges to each CPS Operator. The Access Provider will provide CLI, testing exchange and test schedule details in advance to each OLO. The standard list of test calls (irrespective of CPS category assigned 1 ) to be made is included at the end of Section 7. Section 2 The Access Provider Field Staff Representatives will generate a range of appropriate test calls from lines with different CPS categories. If a test call fails, the Access Provider will determine if the fault resides in it's network - if it does it will be rectified (in a period not greater than half of one day) and testing will continue. If the fault lies in the CPS operator network an equal period (not greater than 1/2 of one day) will be allotted for resolution of same. Section 3 Network Integrity Test success will deem to have been achieved for each CPS Operator when all test calls have been completed in sequence without failure (subsequent to any fault resolution) and when the CPS operator verifies that it has successfully identified call records for all tests. 1 Calls not "included" in the chosen options should be terminated via the Access Providers network and should be proven to do so,

7.8 CPS Service Enablement trial success criteria 7.8.1 Success criteria The following points define the required success criteria. The trial will prove that :- 7.8.2 End-To-End Process Test 1. A CPS provision order can be issued from a CPS Operator and implemented by the Access Provider 2. The Access Provider can accept an order within the appropriate working day lead-time 3. An order containing errors can be rejected by the Access Provider, using the appropriate rejection code(s). Also, an order can be fully checked, and all errors identified, and documented during the first issue. 4. The Access Provider can issue notification of CPS provision to the gaining CPS Operator. 5. Cease orders can be issued, accepted and rejected by both the Access Provider and the CPS Operator. 6. A reinstate order can be issued, accepted and implemented between CPS Operators and the Access Provider. 7. CPS Operators can request copies of customers CAFs/TPV CAFs and voice recordings between themselves, within agreed time periods. This should be completed without the requirement to involve the Access Provider until the dispute is resolved. 8. The Access Provider applies the required CPS option to the customers CLI(s). 9. Successful test calls can be generated for all test scenarios where appropriate. 10. hanged and validated.

11. Successful test calls involving call forward, CLIP, CLIR and local numbers can be 7.8.3 Network Integrity Test 12. All appropriate test calls are completed successfully in sequence from each of the 5 allocated exchange areas and a full detailed record of the test calls handed over to the CPSO. 13. The CPS operator can verify that all successful test calls have generated appropriate call records. The CPSO should confirm acceptable progress timers on all CPS calls ingressing / egressing on points of interconnection to the given operator point code / network. ISUP signal traces will assist CPSO's with issues under the ETSI guidelines and testing specifications outlined in the open eir technical manual Appendix title: SWD340. Routing verification can also take place at this time, where CPSO's are interconnected at points of interconnection below that of tertiary. (Dame Court and Adelaide Rd.) (**) Operators are bound under the RIO (Reference Interconnect Offering) to have service schedule 120 (Carrier Pre-Selection) completed and signed for CPS services. Interconnection capacity and forecasting on indirect routes should encompass and additional traffic expected prior to the launch of a CPS service as a CPSO. NIT testing can be carried out bi-laterally with open eir and after any core network tests are

completed. As paths are similar to indirect paths, where indirect services had existed for Carrier Access and Carrier Selection, NIT tests may only be necessary. Operators would be expected to have nodal capacity at relevant minimum points of interconnection Tertiary nodes Dame Court and Adelaide Rd. (at this time) and be compliant with RIO standard forecasting and augmentation process under RIO contract for licensed operators, before attempting to launch a CPS network service as a CPSO.

End to End Process - CPS test call record Name of CPS Operator: Scenario number: Calling party number: Local number dialled: Time of call: Duration of call: Standard format CLIP digits dialled CLIR digits dialled National number dialled: Time of call: Duration of call: Standard format CLIP digits dialled CLIR digits dialled International number dialled: Time of call: Duration of call: Standard format CLIP digits dialled CLIR digits dialled Rules of use: 1. The numbers dialled must cause CDRs to be generated, i.e. the called party should not send an answer no charge message back. 2. The test numbers should be appropriate to the CPS type being tested, e.g. an International call should be made in international format.

3. Where appropriate local test calls should be made with and without the customer dialled STD code.

Version 10.1

Version 10.1 Notes Test 6 No provisioning will take place this test is only for validation purposes. Real CLIs will be provided but these can be picked randomly. This is a paper exercise only. Notification of completion will be sent by the Access Provider. Test Need to clean up these CPS activations and test AP and CPS Cease types this would take place in Week 3 4-8

List of test calls to be made per line per Access Provider exchange. National 1 National 2 National 3 International 1 International 2 International 3 Local 1 Local 2 Local 3 1800 #1 1850 #1 1890 #1 1550 #1 1901 10 11811/11818 / 11850 086 #1 087 #1 999/112 Emergency Call 114 Clip/Clir Call Forward

8 IT Documentation See CPS 16: IT functional specification and IT testing documentation

9 Provision of forecasts This section deals with the need for operators to exchange order forecasts. CPS operator order forecasts are required by the Access Operator to plan service desk resource and the dimensioning of order systems. The forecast will provide a forward look on a quarterly basis for four quarters and will be submitted/updated on a rolling basis each quarter one quarter in advance. The tolerances between successive forecasts for individual quarters shall be in accordance with the SLA. The forecast shall indicate the quantity of CLIs which will require CPS functionality to be provided. An example of the order forecast form is shown at Annex 3. Assumptions can be drawn as to the even distribution of order placement during a month. Operators will give reasonable advance notice of expected peaks. The due date for each forecast shall be the first working Friday of the quarter preceding the forecast period. The Access Provider shall respond to the forecast within one working week. Acceptance of the forecast will not be unreasonably withheld. The quarter periods are January to March, April to June, July to September and October to December.

10 Service Level Agreement An SLA will be agreed between open eir January 2000). It will be shown in this document as a pro-forma. st

11 CPS Change Management Process Any CPS operator or the AP can initiate a change in the CPS documentation by following this process. This operator must draw up a brief note setting out: > What the issue is > Why a change is required > Which CPS documents and Working Groups are impacted > What change(s) in CPS documentation are required > Suggestions for changes to document texts > Suggestion for the optimal decision making process and a timescale for this > Suggestion for an implementation programme (and review) if the change is agreed The change note must be sent to the ODTR who will then forward the proposal to the members of the relevant Working Groups. The ODTR should assess whether any regulatory implications arise. The Working Group must decide on the importance of the issue(s) and what decision process is required. Suggested approaches include: > Email sign-off by Working Group > Sign-off by meeting of Working Group > Sign-off by meeting of CPS Committee Where all parties agree then the email sign-off approach can be used to allow an interim solution to be put in place. Email sign-off must be unanimous. Any interim solution agreed in this manner must be circulated to all Committee members by the ODTR. Failing unanimous agreement Working Group or Committee sign-off will be required.

If a Working Group meeting is to be held, then this must be set up by the Working Group Head. Committee meetings must be set up by the ODTR. The process for agreeing changes in Working Group and/or Committee is the same as that used for the initial CPS project. All final changes to documentation must be formally signed off by a meeting of the CPS Committee. Following formal Committee sign-off the new amended CPS documentation must be circulated to the Committee and all Working Group members by the ODTR and must also be posted to the All agreed changes will be implemented according to an industry agreed implementation plan. The implementation plan will specify in detail the proposed change, roll-out methodology and schedule. The implementation process will be managed on a per change request basis at a level that is deemed suitable by all Operators i.e. at e-mail or Working Group level. Regular Committee meetings should be scheduled by the ODTR. These should take place on a quarterly basis during 2000 and on a 6-monthly basis thereafter.

12 Document History Issue Date Notes Issue 1.0 Issued to Process group for review 6/9/99 Issue 1.1 Issue 1.2 Issued to Process group for agreement 30.9.99 Issue 2.0 Issued to Process group for comments Issue 3.0 Issued to Process Group for comments/approval Issue 3.1 Incorporates comments from Maeve McFadden Issue 3.2 Incorporates comments from Open eir 4/11/99 Issue 6.0 Incorporates Fault management from open eir and Testing (SET/NIT) from Esat. Issued to CPS Process Issue 8 Incorporates comments from CPS Process Review meeting 20 th April 00 Issue 9 Incorporates comments from CPS Process Review meeting 27 th Sept 2000 Issue 9.1 14-Feb-01 Underlines changes made in Issue 9.0 + Incorporates amendments documented at CPS Review meetings 06 th February 2001 Issue 9.2 13-Apr-01 Includes change agreed at CPS Process Review meeting 8 th March 2001 Issue 9.3 28-Jun-01 Includes changes proposed at CPS Committee Issue 9.4 24-Jul-01 Includes changes approved at CPS Committee Issue 9.5 05-Nov-01 Includes changed approved at CPS Committee Issue 9.6 27-Jun-02 Includes changes approved at CPS Committee Annex 1 Customer Authorisation Form Carrier Pre Selection Customer Authorisation Form (CAF) - to be attached to all CPS operator order forms.

Most operators will be able to pre-print name and address details so that the customer will not have to re write them on this