Functional and Upgrade Document for NGA CPs: R1600€¦ · 3 R1600 – GEA Common Enhancements...

Draft 1.0 Issued by Openreach ��

�

Functional and Upgrade Document for NGA CPs: R1600 Issue 1.5�

�� !�"��#��$��

�

Issue 1.5 Issued by Openreach ��

�

Legal notice The contents contained in this document must not be forwarded or republished without the written consent of Openreach. Copyright © British Telecommunications plc, 2011. All rights reserved. BT maintains that all reasonable care and skill has been used in the compilation of this publication. However, BT shall not be under any liability for loss or damage (including consequential loss) whatsoever or howsoever arising as a result of the use of this publication by the reader, his servants, agents or any third party. All third-party trademarks are hereby acknowledged. Document history Revision

Author

Date

Notes

Issue 1.0 Ruth Parry 25th January 2011 First issue Issue 1.1 Ruth Parry 21st Febraury 2011 Clarification to response codes for ORC2M-

11116 Issue 1.2 Ruth Parry 21st February 2011 Response Code 4150 added to ORC2M-11116 Issue 1.3 Ruth Parry 1st March 2011 Additional clarification for ORC2M-11116 Issue 1.4 Ruth Parry 17th March 2011 Correction to Response Code in ORC2M-12869 Issue 1.5 Ruth Parry 1st August 2011 Correction to ORC2M-10064

�� !�"��#��$��

�

Issue 1.5 Issued by Openreach �� %��

�

CONTENTS

1� INTRODUCTION ........................................................................................................................ 5�

2� DEFINITIONS ............................................................................................................................ 6�

2.1� CLASSIFICATION ........................................................................................................................................................ 6�2.2� IMMEDIATE RELEASE IMPACT ................................................................................................................................... 6�2.3� SCHEMA UPGRADE FUNDAMENTALS ........................................................................................................................ 6�

3� R1600 – GEA COMMON ENHANCEMENTS (FTTC AND FTTP) .............................................. 7�

3.1� ORC2M-7219 – GEA FTTC/FTTP: CHANGE THE FORMAT OF THE MSOS AND PEWS TO ALIGN WITH OTHER OPENREACH NOTIFICATIONS ................................................................................................................................................ 7�

3.1.1� Story Details .................................................................................................................................................... 7�3.1.2� Introduction ...................................................................................................................................................... 7�3.1.3� Design Summary ............................................................................................................................................ 7�3.1.4� Design Changes ............................................................................................................................................. 7�3.1.5� Design Details ................................................................................................................................................. 7�

3.2� ORC2M-9908 – GEA NGA: AMENDMENT TO MAIN FAULT LOCATION (MFL) ..................................................... 9�3.2.1� Story Details .................................................................................................................................................... 9�3.2.2� Introduction ...................................................................................................................................................... 9�3.2.3� Design Summary ............................................................................................................................................ 9�3.2.4� Design Changes ............................................................................................................................................. 9�3.2.5� Design Details ................................................................................................................................................. 9�3.2.6� Response Code Changes ........................................................................................................................... 10�

3.3� ORC2M-10064 FTTC/FTTP: MANAGED INSTALL ENHANCEMENTS .................................................................. 11�3.3.1� Story Details .................................................................................................................................................. 11�3.3.2� Introduction .................................................................................................................................................... 11�3.3.3� Design Summary .......................................................................................................................................... 11�3.3.4� Design Changes ........................................................................................................................................... 11�3.3.5� Design Details ............................................................................................................................................... 11�3.3.6� Response Code Changes ........................................................................................................................... 14�

3.4� ORC2M-11116 GEA FTTC/FTTP: SFA RA/VA PROCESS IMPROVEMENTS .................................................... 15�3.4.1� Story Details .................................................................................................................................................. 15�3.4.2� Introduction .................................................................................................................................................... 15�3.4.3� Design Summary .......................................................................................................................................... 15�3.4.4� Design Changes ........................................................................................................................................... 15�3.4.5� Design Details ............................................................................................................................................... 16�3.4.6� Response Code Changes ........................................................................................................................... 17�3.4.7� Clear Codes for Non Openreach Domain Faults ..................................................................................... 19�

3.5� ORC2M-12869 FVA/FTTP/FTTC: RID RELATED ACTIVITIES ON FVA/FTTP/FTTC PRODUCT ...................... 20�3.5.1� Story Details .................................................................................................................................................. 20�3.5.2� Introduction .................................................................................................................................................... 20�3.5.3� Design Summary .......................................................................................................................................... 20�3.5.4� Design Changes ........................................................................................................................................... 20�3.5.5� Design Details ............................................................................................................................................... 21�3.5.6� Response Code Changes ........................................................................................................................... 21�

4� R1600 – FTTP ENHANCEMENTS ........................................................................................... 22�

4.1� NGA-923 ORCM-14798 HANDLING MISSING DP DETAILS IN SUPPORT OF THE FTTP GOLD ADDRESS TACTICAL PROCESS ............................................................................................................................................................ 22�

4.1.1� Story Details .................................................................................................................................................. 22�4.1.2� Introduction .................................................................................................................................................... 22�4.1.3� Design Summary .......................................................................................................................................... 22�4.1.4� Design Changes ........................................................................................................................................... 22�4.1.5� Design Details ............................................................................................................................................... 23�4.1.6� Response Codes .......................................................................................................................................... 23�

4.2� ORC2M-8069 FTTP: VOICE WIRING END-CUSTOMER OPT-OUT AUTHORISATION ............................................. 24�4.2.1� Story Details .................................................................................................................................................. 24�4.2.2� Introduction .................................................................................................................................................... 24�

�� !�"��#��$��

�


�

4.2.3� Design Summary .......................................................................................................................................... 24�4.2.4� Design Changes ........................................................................................................................................... 24�4.2.5� Design Details ............................................................................................................................................... 24�4.2.6� Response Code Changes ........................................................................................................................... 26�

4.3� ORC2M-8724 FTTP: L2C EXTERNAL TASK – SPLICE & CONNECT FROM SPLITTER, DP TO CSP .................. 27�4.3.1� Story Details .................................................................................................................................................. 27�4.3.2� Introduction .................................................................................................................................................... 27�4.3.3� Design Summary .......................................................................................................................................... 27�4.3.4� Design Changes ........................................................................................................................................... 27�4.3.5� Design Details ............................................................................................................................................... 27�4.3.6� Response Code Changes ........................................................................................................................... 30�

4.4� ORC2M-9412 FTTP: CAPTURE WHETHER END USER HAS CONSENTED TO ACCESS TO THE OUTSIDE OF THEIR PREMISES ............................................................................................................................................................................ 33�

4.4.1� Story Details .................................................................................................................................................. 33�4.4.2� Introduction .................................................................................................................................................... 33�4.4.3� Design Summary .......................................................................................................................................... 33�4.4.4� Design Changes ........................................................................................................................................... 33�4.4.5� Design Details ............................................................................................................................................... 34�4.4.6� Response Code Changes ........................................................................................................................... 35�

4.5� ORC2M-11753 FTTP: CHANGE FTTP BANDWIDTHS TO ACCOMMODATE THE MANAGEMENT OVERHEADS. .... 36�4.5.1� Story Details .................................................................................................................................................. 36�4.5.2� Introduction .................................................................................................................................................... 36�4.5.3� Design Summary .......................................................................................................................................... 36�4.5.4� Design Changes ........................................................................................................................................... 36�4.5.5� Design Details ............................................................................................................................................... 36�4.5.6� Response Code Changes ........................................................................................................................... 37�

4.6� ORC2M-13886 FTTP: MAKE SERVICEID/DN OPTIONAL IN MACCHECKER [‘ADDMACSTATUS’] REQUEST 38�4.6.1� Story Details .................................................................................................................................................. 38�4.6.2� Introduction .................................................................................................................................................... 38�4.6.3� Design Summary .......................................................................................................................................... 38�4.6.4� Design Changes ........................................................................................................................................... 38�4.6.5� Design Details ............................................................................................................................................... 38�

5� ENHANCEMENT SUMMARY .................................................................................................. 40�

5.1� DIALOGUE SERVICES AND REPORTS ..................................................................................................................... 40�5.2� FULFILMENT ............................................................................................................................................................ 41�5.3� ASSURANCE ............................................................................................................................................................ 43�

6� APPENDIX A – GLOSSARY OF TERMS ................................................................................ 44�

�� !�"��#��$��

�


�

1 Introduction This document explains the functional design changes and upgrade information for Release 1600 of the Equivalence Management Programme (EMP) for the Generic Ethernet Access (GEA) products. This document forms part of the technical documentation set explaining parameters passed between the Communications Providers' systems and Openreach. Please refer to the appropriate documentation, including but not limited to the Product Description, Process Manual, Product Schedule, B2B specification and Response code definition for a description of the Openreach products, terms and conditions, charges and XML specification. The first issue of this document will be published in advance of the release being operational and before testing has been completed. It is possible that changes to the scope may occur both before and after the release has been implemented, and it is important that you check the Openreach website regularly for any updates. Openreach reserves the right to change the functionality delivered as part of this release and to amend this document in accordance with any such changes. Audience The document is intended for Communications Providers' (CP) technical teams responsible for designing and building interfaces into the Openreach Business to Business (B2B) gateway.

�� !�"��#��$��

�

Issue 1.5 Issued by Openreach �� $��

�

2 Definitions This section defines some terms used in the document.

2.1 Classification Changes can be classified according to when they will become available, namely whether an upgrade to the new schema is required or whether the functionality will apply immediately the release is deployed. The following classifications are used in this document: UPGRADE –The functionality is not available until the CP uses the new version of the schema. FULL - The functionality will become operational when the release is deployed, regardless of whether the CP uses the new version of the schema. PARTIAL - Part of the functionality will become operational when the release is deployed, and part of the functionality will only become available when the CP uses the new version of the schema.

2.2 Immediate Release Impact The Immediate Release Impact describes which changes are effective immediately the EMP release is deployed. This impact analysis can be useful for the CP who wants a checklist of items which will apply immediately regardless of versioning.

2.3 Schema Upgrade Fundamentals The Schema Upgrade Fundamentals describes which changes are effective when a CP uses the new version of a schema and which the CP must be able to manage. Note, there are separate schemas for fulfilment, assurance and each dialogue service. Only some of these may have been upgraded in the release. This impact analysis can be useful for the CP who is planning to upgrade, but may not want to use all the new functionality immediately.

�� !�"��#��$��

�

Issue 1.5 Issued by Openreach �� &��

�

3 R1600 – GEA Common Enhancements (FTTC and FTTP)

�

3.1 ORC2M-7219 – GEA FTTC/FTTP: Change the format of the MSOs and PEWs to align with other Openreach notifications

�Immediate Release Impacts: Previously blank fields in the ReportableIncidentNotification2.xml message will be populated where appropriate

Schema Upgrade Fundamentals: None.

3.1.1 Story Details As Openreach I want to change the format of the MSO (Major Service Outage) and PEW (Planned Engineering Works) notifications to provide greater detail and to better align with the format of other Openreach notifications So that CPs get clearer and more detailed notifications via email, B2B and the Portal.

3.1.2 Introduction

�We are changing the format of our email communications for MSOs and PEWs and introducing more detail to the notifications sent via the B2B and Portal.

3.1.3 Design Summary

�Change

Ref Title Scope Products Classifi-

cation* Functional Summary

XML CP Impact Summary

ORC2M-7219

GEA FTTC/ FTTP: Change the format of the MSOs and PEWs to align with other Openreach notifications.

Assurance FTTC FTTP FVA

Full Additional data sent for MSO and PEW notifications

No New Data

�

3.1.4 Design Changes

�XML None

Data ExchangeAreaCode: xxxxxx

PostCode: xxxxxxx Process None Response Codes

None

Behaviour None �

3.1.5 Design Details

�When we tell you about either a MSO (Major Service Outage) or PEW (Planned Engineering Works) we will, where appropriate, include the Exchange Area Code and Postcode. This will give you greater detail as to the location of the problem. The additional data will be sent in the ReportableIncidentNotification2.xml message, populating the existing data fields that have been previously left blank. See example XML snippet below:

�� !�"��#��$��

�

Issue 1.5 Issued by Openreach �� '��

�

01394 ..... NW11 7NG

�� !�"��#��$��

�

Issue 1.5 Issued by Openreach �� (��

�

3.2 ORC2M-9908 – GEA NGA: Amendment to Main Fault Location (MFL) �Immediate Release Impacts: None

Schema Upgrade Fundamentals: None

3.2.1 Story Details As a CP I want to be notified if an incorrect fault location has been corrected on a Trouble Report and to be advised if I need to request an appointment or not. So that a Trouble Report can be resolved more quickly and an appointment is only made with my customer when needed.

3.2.2 Introduction

�As a Trouble Report is being investigated it is sometimes possible for an incorrect Main Fault Location (MFL) to be assigned. This can mean that you may be incorrectly advised to make an appointment, or not requested when one is necessary. If the Openreach SMC determines such as error has been made we will notify you through KCI update messages and advise on the correct course of action.


�Change




ORC2M-9908

GEA NGA: Amendment to Main Fault Location (MFL)

Assurance

FTTC FTTP FVA

Full

Provides updates to MFL and appointment requirements in case of an erroneous MFL entry.

No Behaviour

�


�

XML None

Data None

Process None

Behaviour Openreach is able to update the Main Fault Location on a Trouble Report using existing KCI messages

Response Codes None

�


�There are two scenarios to consider.

• The MFL is changed and an appointment is now required • The MFL is changed and an appointment request is no longer valid

�� !�"��#��$��

�


�

The MFL is changed and an appointment is now required In this situation we will send you a KCI update message with the following existing response codes:

4068 Notification only - Main fault location changed 3261 Response Required: CP is required to arrange an appointment

The response required tag will be set to response required. Y

The MFL is changed and an appointment request is no longer valid In this situation we will send you a KCI update message with the following existing response code:

4068 Notification only - Main fault location changed The response required tag will be set to no response required. N If an appointment request has already been sent to you in a previous KCI update message (response code 3261) it will no longer be possible to raise an appointment request against it. Any such amend requests will be rejected.

3.2.6 Response Code Changes • Yellow background = new codes • Green background = revised codes / text • Clear background = existing codes applicable to this scenario

Code Response to CP Explanation 3261 Response Required: CP is

required to arrange an appointment

The CP needs to arrange an End User appointment if one has not already been made.

4068 Notification only - Main fault location changed

Notification that the main fault location has changed.

�

�

�� !�"��#��$��

�


�

3.3 ORC2M-10064 FTTC/FTTP: Managed Install Enhancements Immediate Release Impacts: None

Schema Upgrade Fundamentals: You will need to use module numbers not names from R1600

3.3.1 Story Details As Openreach Product Line I want to modify the Managed Install order interface to allow CPs to order Devices based on quantity only. So that I can make the product interfaces more flexible and open to more CPs.

3.3.2 Introduction We are introducing a change to the ordering of managed install modules – in future you will be able to specify the number of modules you would like to have installed without specifying exactly which modules they are. This will allow a more flexible approach to managed installations.

3.3.3 Design Summary Change


cation* Functional Summary XML CP

Impact Summary

ORC2M-10064

FTTP/FTTC: Managed Install Enhancements

Appointing Dialogue Service Fulfilment

FTTC FTTP

Upgrade A new tag “ManagedInstallQuantity” is added to the Appointing Dialogue service and provide XML

Yes XML Changes Data Changes Process Change Reused Response Codes

3.3.4 Design Changes XML

4

Data 0 | 1 | 2 | 3 | 4 Process CP will order managed install modules by quantity and not by name. Response Codes

Response codes 251, 2115, 2136 and 9260 are being reused.

Behaviour None

3.3.5 Design Details A new tag “ManagedInstallQuantity is added to the Appointing Dialogue service and provide XML to enable you to order a number of modules to be installed. It will no longer be necessary to specify which modules are to be installed and therefore the old tag “ModuleName” will be removed. The minimum number of modules you can order is 0, and the maximum number is 4. If no number is entered, the default value will be 0. Current - R1500 and earlier

�� !�"��#��$��

�


�

BMwin/BMmac AddPCwin/AddPCmac BTV New – from R1600 Module names have been removed and replaced by the Module quantity.

4 The new tags will be included in the following XML files:

• AddOrder - GEA FTTP - Provide - NewInstallation.xml • OrderPending - GEA FTTP - Provide - New Installation.xml • OrderRejected - GEA FTTP - Provide New Installation.xml

The modules that are supported from R1600 are listed below:

Device list Value presented to CPs in KCI 3 Basic Router and 1 computer BMwin/BMmac 1 Additional computer windows or mac AddPCwin/AddPCmac Additional computer 2 windows or mac AddPCwin/AddPCmac Additional computer 3 windows or mac AddPCwin/AddPCmac BT Vision STB Reconnection BTV

Order Status Update The new tags will also be returned in KCI2 and KCI3. In KCI2 we will return the number of modules ordered and the status of the managed install order. The status will be either “Committed” or “Cancelled”. If the status is cancelled, we will also return the cancellation reason “Not applicable for the request”. In KCI3 we will return the names of the modules as recorded by the installation engineer, and the status of each module. The engineer will not install more modules than you have ordered. The two possible scenarios are:

1. X modules ordered, X modules installed on site. Each module will have the Module Status as “Completed”.

2. X modules ordered, fewer than X modules installed on site – and here there are two possible outcomes:

o If all the modules that we tried to install were listed on the Device List above, the installed Modules will have a Value of “Completed” and those not installed will have a Value of “Cancelled” with a cancellation reason. The cancellation reasons can be:

�� !�"��#��$��

�


�

� Module not available � Faulty module � EU does not require module � Unable to install module � Device not supported

o If however your end user asked us to install a module that is not on the Device List (e.g. Xbox

360) it will not be included in KCI3 – we will only include in KCI3 those modules that we have either installed or cancelled that are listed on the Device List.. Therefore it is possible that we will have installed fewer modules than you ordered, and will not have returned either “Completed” or “Cancelled” against all of them – you will have to derive from this information that the remaining module(s) were not on Device List and therefore we were unable to install them.

5

Progress Update Type Managed Install Module Value Completed Sequence No 1 Module Name BMwin/BMmac Billable Units 1 5 Progress Update

Type Managed Install Module

Value Cancelled

Sequence No 2

Module Name X360

�� !�"��#��$��

�


�

Cancellation Reason Module not found In KCI3 we will also return the new tag “ManagedInstallQuantity” with the number of modules you originally ordered – as explained above, this may be more than the number of modules which the engineer has installed.

3.3.6 Response Code Changes • Yellow background = new codes • Green background = revised codes / text • Clear background = existing codes applicable to this scenario Code Response to CP Explanation 251 Invalid value for field

“ManagedInstallQuantity” The order has been rejected as incorrect data has been entered in the field specified in the message.

2136 The request exceeds the maximum number of modules allowed.

The CP can not select more than the maximum permissible number of modules. Please refer to product information for details

2115 Invalid data/format-"Managed Install Quantity"

Invalid format of one of the input parameters

9260 The Managed Install part of this order is incompatible with the type of appointment that has been booked.

The order has been rejected. The type of appointment booked is incompatible with the requirements of all or part of the order that has been placed.

�� !�"��#��$��

�


�

3.4 ORC2M-11116 GEA FTTC/FTTP: SFA RA/VA Process Improvements �Immediate Release Impacts: None


3.4.1 Story Details �As Openreach Service I want to make changes to the SFA VA/ RA process So that tasks created are dispatched within a reduced time period and CP billing is accurate.

3.4.2 Introduction

�There are two distinct elements to this story – the first relates to the treatment of Remote Assure (RA) or Visit Assure (VA) as standard Trouble Reports when faults are found to be in the Openreach domain, and the second to the handling of missed appointments for RA / VA. Conversion to standard Trouble Report If you have performed a line test and it returns the Main Fault Location as OK it is not possible for you to raise a standard Trouble Report (FTTx1), therefore if your customer is experiencing problems you need to raise either a Remote Assure (FTTx2) or Visit Assure (VA, FTTx3) so that we can investigate the problem further. Prior to this change, if we then found a fault in our domain the RA/VA would be closed and you would have had to raise an FTTx1. This change enables us to treat the FTTx2 or FTTx3 as an FTTx1 and advise you with KCIs that it will be progressed as BAU. We will then follow the standard FTTx1 process to resolve and close the fault. Missed Appointments When RA / VA appointments are missed by any of the parties we will attempt to make new appointments and advise you of progress by KCIs.


�Change




ORC2M-11116

GEA FTTC/FTTP: SFA RA/VA Process Improvements

Assurance FTTC/FTTP Full Treat FTTx2 or 3 as FTTx1 if fault is found in Openreach domain Handling of missed appointments for RA / VA

No New Process Reuse of Response Code

�


�XML None Data None Process New process for Openreach to raise FTTx1 if a fault is found in the Openreach domain during

SFA RA/VA investigations. CPs will no longer be required to create a new Trouble Report. New process for managing missed appointments for Remote Assure and Visit Assure

Response Reuse

�� !�"��#��$��

�


�

Codes Behaviour None. �


�Openreach Domain Fault Remote Assure (FTTx2) On discovering a fault in the Openreach domain we will send informational response code 9201. We will then send informational response codes 6017 and 4068 to advise that the fault has come out of PONR (Point of No Return) state, and that the MFL has been changed. If the MFL = CA we will send response code 3261 asking you to arrange an appointment with your customer, and from then on the FTTx1 BAU process will be followed. If the MFL = Non-CA, the FTTx1 BAU process will be followed. Please note that in this process we will be treating the FTTx2 as a normal FTTx1 fault and all charges corresponding to such a fault will be levied where applicable. Visit Assure (FTTx3) If the engineer on site finds a fault in the Openreach domain and he is able to fix it, we will send you a TroubleReportStatusUpdate message with response code 3300 to show the fault is cleared and closed. Note, we will not send response code 4150 in this scenario. If our engineer is unable to fix the fault we will progress it as if it were a standard FTTX1 fault. That is we will send the relevant response code identifying the problem (see codes 4265 – 4279 in Response Code Changes section below). Once the engineer has fixed the fault, we will send you response code 4150 as part of the standard fault clear process of telling you we have cleared the fault and waiting for you to confirm. Once you have confirmed we have cleared the fault, or we have had no response within 72 hours of sending you 4150, we will send you response code 3300 to show the fault is cleared and closed. . Non Openreach Domain Faults Visit Assure (FTTx3) If the fault is not in the Openreach domain, we will send you one of response codes 9204, 9205 and 9206 along with respective Clear Code 18.3, 18.4 or 18.5 as part of the fault clear and close message. Missed Appointments Remote Assure If your customer is not available at the agreed appointment time response code 9202 will be sent. If you do not respond in 48 hours we will send response code 3231 and if there is no response after a further 24 hours we will close the fault and send response code 3302. If you are not available during the test product investigation appointment we will send response code 9203 and close the fault. If we miss the scheduled appointment we will send you response code 9027, schedule a new telephone appointment with your customer and then send response code 4183. If we are not able to contact your customer we will select an appointment within the next 2 days if available, or the next earliest appointment, and

�� !�"��#��$��

�


�

then send response code 4184. If you and your customer are both happy with the new appointment slot offered, it will be progressed. If not, you need to raise an amend request with a new appointment time. Visit Assure If our engineer misses the appointment time we will try to contact your customer to book a new appointment time . If successful we will send you response code 4183. If we are unable to contact your customer we will select a new appointment and send response code 4184. You will need to check whether this is suitable with your customer, and if not submit an amendment with a new appointment time (you can do this until PONR for the appointment details we sent you).

3.4.6 Response Code Changes • Yellow background = new codes • Green background = revised codes / text • Clear background = existing codes applicable to this scenario Code Response to CP Explanation

3231 Notification: Fault has been awaiting for CP's response for 48 hours

A reminder that the CP needs to respond to a KCI which was sent 48 hours ago. If the appropriate response is not received within the next 24 hours, the fault will be automatically cancelled.

3261 Response Required: CP is required to arrange an appointment

The CP needs to arrange an end user appointment if one has not already been made.

3263 Response Required: CP is required to arrange another EU appointment (Abortive Visit)

The end user missed the Openreach appointment.

3300 Fault is Cleared and Closed Confirmation that a fault has been cleared and closed on Openreach's systems.

3302 Fault is Cancelled and Closed: Timeout awaiting for CP's response

Confirmation that a fault has been cancelled and closed on Openreach's systems due to a timeout when waiting for the CP's response.

4068 Notification only - Main fault location changed

Notification that the main fault location has changed.

4150 Response required – fault report cleared

Informs the CP that the fault has been cleared. The message provides the clear code and requests the CP to review and accept that the fault has been cleared. 16 Customer or end user contacted by BT and guidance given

4183 Notification Only - EU contacted, new appointment arranged by Openreach.

The Openreach engineer was unable to make the scheduled appointment and has arranged a new appointment with the end user.

4184 Notification Only - EU could not be contacted, new appointment arranged by Openreach.

The Openreach engineer was unable to make the scheduled appointment and has been unable to contact the end user. The earliest available appointment has been booked.

4265 (FTTC only)

Notification Only - Further work needed - Fault proven to be with the dropwire

Further work is required as the fault location is overhead (i.e. a dropwire). The Openreach engineer cannot complete the work at this time. Openreach will ensure the further work required is completed.

4266 Notification Only - Further work needed - Fault proven into the "D" side network.

Further work is required as the fault is located on the Distribution network, including arial cables. The Openreach engineer cannot complete the work at this time. Openreach will ensure the further work required is completed.

�� !�"��#��$��

�


�

4267 (FTTC only)

Notification Only - Further work needed - Fault proven into the customer apparatus

Further work is required as the fault has been traced to the Openreach-maintained apparatus at the customer premises. The Openreach engineer cannot complete the work at this time. Openreach will ensure the further work required is completed. Note: This work excludes customer-owned equipment.

4268 Notification Only - Further work needed - Requires platform elevating

Further work is required as a hoist is needed to carry out the repair.

4269 Notification Only - Further work needed - Requires duct or maintenance dig

Further work is required as a maintenance dig or civil engineering work is needed to carry out the repair.

4270 Notification Only - Further work needed - Requires diagnostic test

Further work is required as a diagnostic test is needed to identify the fault.

4271 Notification Only - Further work needed - All faults not covered by any other code

Further work is required to rectify the fault. Note: All faults where there is no specific message will receive this message. These may include faults related to traffic lights, water pumps, generators, PTO, gully suckers, tree cutting, PPO, E-side work, where BT plant cannot be access and where roof ladders or long ladders are required to access the fault. All faults that from Openreach systems which are maintained by Openreach's business division are included. Faults where access is restricted, for example, where the customer has specified access times, closed user groups, are also included.

4272 Notification Only - Further work needed - Underground cable work required

Further work is required involving second stage repair work on underground work i.e. underground cable renewal (Excluding civil engineering work ie duct, box activities).

4273 Notification Only - Further work needed - Issued second stage activity - further work required

Further work is required to rectify the fault and a follow-up visit is needed. Note: This code should only be used for tasks issued by second-stage repair.

4274 Notification Only - Further work needed - Need extra engineer assistance to complete the Job.

Further work is required as the Openreach engineer needs additional assistance which control has been unable to provide.

4275 Notification Only - Further work needed - due to Hazard situation.

The fault requires further work due to a safety-related issue, for example, “D” poles, low wires, medical reasons, hazardous environment, mad dog, foot and mouth, violent customer.

4276 Notification Only - Further work needed - due to insufficient time.

Further work is required to rectify the fault, as the Openreach engineer has insufficient time to start or finish the work.

4278 Notification Only - Further work needed - due to lack of hardware.

Further work is needed due to lack of hardware.

4279 Notification Only - Further work needed - Fault proven to be with the dropwire

Further work is required as the fault location is overhead (i.e. a dropwire). The Openreach engineer cannot complete the work at this time. Openreach will ensure the further work required is completed.

6017 Fault has come out of PONR state The fault is not yet at the Point Of No Return (PONR). The CP can make amendments/cancel the fault report if required.

9201 Notification only - A fault has been found on the Openreach network

Openreach has detected a fault during the test product investigation.

�� !�"��#��$��

�


�

9202 Openreach has been unable to make telephone contact with the end user during the test product investigation appointment

Openreach has been unable to make telephone contact with the end user during the test product investigation appointment. This is an Assurance Product response code only. This response code is not used on standard fault reports.

9203 Openreach has been unable to make telephone contact with the CP during the test product investigation appointment

Openreach has been unable to make telephone contact with the CP during the test product investigation appointment. This is an Assurance Product response code only. This response code is not used on standard fault reports.

9204 Service demonstrated as working OK

Openreach has proved that the service is working OK. See the notes for further information. This is an Assurance Product response code only. This response code is not used on standard fault reports.

9205 CP domain Issue Openreach has proved that there is an issue with the CP domain. See the notes for further information. This is an Assurance Product response code only. This response code is not used on standard fault reports.

9206 End user domain issue Openreach has proved that there is an issue with the end user domain. See the notes for further information. This is an Assurance Product response code only. This response code is not used on standard fault reports.

9207 Openreach missed a telephone appointment

Openreach did not contact the end user or CP during the agreed telephone appointment due to an Openreach issue. This is an Assurance Product response code only. This response code is not used on standard fault reports.

�

3.4.7 Clear Codes for Non Openreach Domain Faults

Clear Code Clear Code Description

18.3 Service Demonstrated Working OK 18.4 CP Domain Issue 18.5 End User Domain Issue

�� !�"��#��$��

�


�

3.5 ORC2M-12869 FVA/FTTP/FTTC: RID related activities on FVA/FTTP/FTTC Product �Immediate Release Impacts Case sensitivity is removed when validating the Retailer Identity (“RID”) codes for FTTP; FTTC and FVA orders. All RIDs will be returned in uppercase.

Schema Upgrade Fundamentals The Retailer Identity (“RID”) becomes mandatory for all FTTP provides from R1600.

3.5.1 Story Details �As Openreach Product Line I want to capture the Retailer Identity (“RID”) at the point of ordering for FTTP Products So that I can offer, where appropriate, discount to CPs who jointly order FTTP and FVA products

3.5.2 Introduction

�This change makes the provision of the Retailer Identity (“RID”) mandatory for all FTTP and FVA provide orders from R1600 onwards. RID remains an optional field for FTTC orders, but it will be validated if provided in these cases. This story also removes case sensitivity when validating a RID for FTTP; FTTC and FVA orders. All RIDs will be returned in uppercase.


�Change




ORC2M-12869

FVA/FTTP/FTTC: RID related activities on FTTP/FTTC Product

Fulfilment FTTP FTTC FVA

Partial Makes the provision of the Retailer Identity (“RID”) mandatory for all FTTP provide orders from R1600 onwards Removes case sensitivity when validating a RID for all orders regardless of version.

No New Process New Response Code

�


�XML None Data None

Process RIDs are mandatory for FTTP provide orders. RIDs are no longer case sensitive and will always be returned in uppercase.

Response Codes

Existing code (5002) reused when the RID is not supplied as part of the provide order. New code (5019) used if the RID supplied is invalid.

Behaviour None

�� !�"��#��$��

�


�

�

3.5.5 Design Details �

When you place an order From R1600 onwards when you place an order for FTTP products the Retailer Identity (“RID”) code is mandatory. This applies to both new installations and transfers. XML snippet: BAG Your order will be rejected if no RID is supplied or if the supplied RID is invalid.

When we validate your order Regardless of the schema version you are using, when we validate the RID supplied as part of a provide order for FTTP; FTTC or FVA products we will ignore the case of the text. When we return the RID to you it will always be in uppercase. For example if you supply the RID as BaG this will be validated and returned to you as BAG.

3.5.6 Response Code Changes • Yellow background = new codes • Green background = revised codes / text • Clear background = existing codes applicable to this scenario Code Response to CP Explanation 5002 Mandatory field "[RetailerParty ID]"

contains no data The order has been rejected. No value has been provided for the Retailer Party ID in the XML submitted. BAG

5019 Invalid value for field "[Retailer Party ID]"

The Order has been Rejected. The value provided in the order for Retailer Party Id is invalid. The Retailer Party Id is issued by Ofcom.

�� !�"��#��$��

�


�

4 R1600 – FTTP Enhancements

�

4.1 NGA-923 ORCM-14798 Handling missing DP details in support of the FTTP gold address tactical process

�Immediate Release Impacts: None

Schema Upgrade Fundamentals: FTTC and copper related tags not returned if DP cannot be uniquely identified.

4.1.1 Story Details As a CP I want eMLC to still return FTTP availability if there is no design DP against the address So that if that address has been created as part of the FTTP tactical process, it can be used to place an FTTP order against.

4.1.2 Introduction �This change applies to querying eMLC (Line Characteristics Dialogue Service 2 ) :

• using a Service Id, ONT Reference or Gold Address Key

and

• where the Service Type is one of “All”, “Generic Ethernet Access” or “FVA”.

Currently, if the Distribution Point (DP) cannot be uniquely identified because it is missing or there are multiple DPs at the same address, then the request is rejected. However, there could still be valid details for FTTP and FVA. So instead of rejecting the request, we will return what information we have. This means that you could get information returned for FTTP and FVA if available, but not for FTTC or copper.

4.1.3 Design Summary �Change




NGA-923 ORC2M-14798

Handling missing DP details in support of the FTTP gold address tactical process

eMLC Dialogue Service

FTTP, FTTC, FVA, MPF

Upgrade FTTP and FVA availability returned where no DP identified. Nil return for FTTC and copper.

No New Behaviour

�

4.1.4 Design Changes �XML None Data None Process None Response None

�� !�"��#��$��

�


�

Codes Behaviour Query is no longer rejected with Response Code 2061 for the scenario where the DP is not found

or cannot be uniquely identified. If available, information will be returned for FTTP and FVA, but not for FTTC or copper.

�

4.1.5 Design Details �This change applies to querying eMLC (Line Characteristics Dialogue Service 2 ) :

• using a Service Id, ONT Reference or Gold Address Key

and

• where the Service Type is one of “All”, “Generic Ethernet Access” or “FVA”.

Currently, if the DP cannot be uniquely identified because it is missing or there are multiple DPs at the same address, then the request is rejected using Response Code 2061 (Data cannot be returned for the NAD key provided). However, there could still be valid details for FTTP and FVA if these are available. So instead of rejecting the request, we will return what information we have. This means that you could get information returned for FTTP and FVA, but not for FTTC or copper. Response Codes 2061 will still be returned under certain circumstances, namely when there is an address in Openreach’s records but this is “unstructured” (not proven).

4.1.6 Response Codes • Yellow background = new codes • Green background = revised codes / text • Clear background = existing codes applicable to this scenario

Code Response to CP Explanation 2061 Data cannot be returned for the

NAD key provided. It has not been possible to return data for the given NAD (Name & Address Database) key as there is either no associated DP or there are multiple DPs linked with it.

�

�

�� !�"��#��$��

�


�

�

4.2 ORC2M-8069 FTTP: Voice wiring end-customer opt-out authorisation �Immediate Release Impacts None

Schema Upgrade Fundamentals None

4.2.1 Story Details �As a CP I want to provide my customers with the option to opt-out of Voice Wiring where they are ordering a GEA Data only service for a new ONT So that there is no confusion as to what work needs to be done when the engineer arrives at the customer premises.

4.2.2 Introduction

�This change gives your customers the option to opt-out of the installation of voice wiring where a new ONT is being ordered for a GEA Data only service.


�Change




ORC2M-8069

FTTP: Voice wiring end-customer opt-out authorisation

Fulfilment FTTP Upgrade Allows the end customer to opt out of the installation of voice wiring to the NTE5

Yes New XML New Data New Process

�


�XML

XXXXXX XXXXXXX XXXXXXXXXX

Data Voice Wiring Solution Option : No | Order Voice Wiring Solution Status: Committed | Completed | Cancelled Cancellation Reason: Order Cancelled by Operator | Failure To Respond | Higher priority order raised | Not Required | Not applicable for the request

Process New process to manage the Voice Wiring opt-out. Response Codes

None. Existing codes reused.

Behaviour None �


�The new functionality is valid for Provide and Transfer orders where the AdditionalSiteVisitReason is “New ONT”.

�� !�"��#��$��

�


�

There is a new XML block to manage the Voice Wiring solution options and report progress. XXXXXXXX XXXXXXXX XXXXXXXXXX

Placing the order When placing the order, you can enable your customer to opt out of the Voice Wiring Solution by specifying a value of “No” in the VoiceWiringSolutionOption. No|Order If you don’t include a value then the default value is ‘Order’. If neither value is recognised, then the order will be rejected using existing Response Code 251 (Invalid value for field %1).

Order Commited - KCI2 In KCI2, we will confirm the order details.

No Voice Wiring Solution ordered If you have opted out of the VoiceWiringSolution, then we will return: No

Voice Wiring Solution ordered – valid order type If you have not opted out, and the scenario is valid (AdditionalSiteVisitReason=”New ONT”), then we will return: Order Committed

Voice Wiring Solution ordered – invalid order type If the scenario is not valid (AdditionalSiteVisitReason is not ”New ONT”), then we will cancel the Voice Wiring Solution as follows: Order Cancelled Not applicable for the request

Order Completed – KCI3 In KCI3, we will confirm what has been delivered.

No Voice Wiring Solution ordered If you have opted out of the VoiceWiringSolution, then we will return: No

Voice Wiring Solution ordered – invalid order type If the scenario is not valid (AdditionalSiteVisitReason is not ”New ONT”), then we will cancel the Voice Wiring Solution as follows: Order Cancelled

�� !�"��#��$��

�


�

Not applicable for the request

Voice Wiring Solution completed If you didn’t opt out, then we can confirm completion of the Voice Wiring Solution: Order Completed

Voice Wiring Solution Cancelled If your customer cancels the Voice Wiring Solution when the engineer is on site the following XML is returned. Order Cancelled Not Required

Order Cancelled If you cancel the order, or if the order is cancelled by Openreach, then the Cancellation Reason will reflect the same reason as the main order. Order Cancelled XXXXXXXXXX Valid cancellation reasons are: Order Cancelled by Operator | Failure To Respond | Higher priority order raised�

4.2.6 Response Code Changes • Yellow background = new codes • Green background = revised codes / text • Clear background = existing codes applicable to this scenario Code Response to CP Explanation 251 Invalid value for field

“[VoiceWiringSolutionOption]” The order has been rejected as incorrect data has been entered in the field specified in the message.

�� !�"��#��$��

�


�

4.3 ORC2M-8724 FTTP: L2C External Task – Splice & connect from Splitter, DP to CSP �Immediate Release Impacts: None


4.3.1 Story Details As a CP I want the external engineering task of a two-stage FTTP provision to be performed in advance of the CRD So that my customer can receive their new service in a timely and convenient manner.

4.3.2 Introduction

�Sometimes it is necessary for Openreach to make two separate engineering visits to your customers’ premises in order to install a new FTTP service. Firstly to perform any external work and secondly to complete the installation internally. This story covers the external engineering task associated with such a two-stage installation. Openreach will determine if a new FTTP install needs to follow a one or two stage installation process based on available survey notes.


�Change




ORC2M-8724

FTTP Provision - L2C External task - Splice & connect from Splitter, DP to CSP

Fulfilment FTTP Full Undertaking of the external engineering task as part of a two-stage FTTP provision

No New two-stage provision process

�


�

XML No changes

Data No changes

Process New two-stage installation process for new FTTP provisions where the external engineering task may be complex.

Behaviour No changes

Response Codes No new response codes

Additional explanation given for 594

�


�

�� !�"��#��$��

�


�

Openreach will determine if a new FTTP install needs to follow a one or two stage installation process based on available survey notes. From R1509 the Line Characteristics Dialogue Service 2 (eMLC) will return survey note markers in a successful response. The following mapping from survey notes to one or two stage visit has been initially defined, although these are subject to change at any time; a briefing about changes to this mapping will be issued by the NGA product line and it is strongly recommended that CPs do not hard code these mappings into their order journeys during the pilot period. Survey Notes Proposed 1 or 2 stage process UG partial Direct In Ground Survey (2-stage) UG congested duct Survey (2-stage) UG Linked duct Survey (2-stage) UG Potential Wayleave Issues Survey (2-stage) OH Feed with Line of sight problems Others Survey (1-stage) OH Potential Wayleave issues Survey (1-stage) OH Feed Not Evaluated 1-stage UG Feed Not Evaluated 2-stage UG Feed with no anticipated issues 2-Stage UG Proven Clear 2-Stage UG Part proven 2-stage UG navigable with camera 2-stage OH Dpole Hoist required 1-Stage OH Pole overloaded 1-stage (Survey) OH Pole with drop wire issues 1-stage (Survey) OH Feed crosses busy road requiring two engineers

1-Stage

OH Feed with no anticipated issues 1-Stage OH Feed with Line of sight problems Trees 1-stage (Survey) OH Supply but not yet evaluated 1-Stage ��Where ‘survey’ is indicated in the above table the order will go to a planning/checking activity before proceeding as a normal 1-stage or 2-stage installation. The external engineering visit will install the fibre to your customer’s premises up to the CSP (Customer Splice Point) on the exterior of your customer’s premises. No internal access to your customer’s premises is required and your customer may choose whether or not to be present for this visit (see ORC2M-9412). An automated appointment reminder call will be made to your customer two days prior to the appointment. If your customer has indicated that they need to be present for the external engineering task but are not present when the engineer arrives then the task will not be able to be completed and a KCI-D will be returned to you with response code 5480. Existing Amend and Cancel rules will apply for installations following a two-stage process. The point-of-no return (PONR) will be 18:00 on CCD-1. This will apply even if the external task has already been (part)completed when the Amend or Cancel is raised. The two-stage installation process will follow one of two routes depending on whether Openreach’s survey notes indicate that your customer’s premises is served by a congested underground duct or not.

No Underground Congested Duct Scenario The CCD will be calculated and both external and internal tasks will be appointed. The internal task will be on CCD whilst the external task will be on CCD-3 or as agreed with your customer. KCI2 will be sent to you with the CCD. If the external engineering task cannot be completed on the appointed day Openreach will determine whether the CCD can still be met, i.e. by completing remaining actions in the following two (or more) days prior to the

�� !�"��#��$��

�


�

CCD. If the CCD cannot be met new external and internal engineering appointments will be made and a KCI-D will be sent to you with a new CCD. The following process flow provides further detail and response codes:

Underground Congested Duct Scenario When survey notes indicate that your customer’s premises are served by a congested underground duct Openreach will perform all necessary external engineering tasks prior to sending you a KCI2 message as it will not be possible to calculate an accurate CCD. The external engineering task will be appointed on CRD-3 or as agreed with your customer. If the external engineering task can be completed on the appointed day, i.e. the duct is not found to be congested or can be cleared, we will send you KCI2 following the completion of the task. If further engineering work is required will send you KCI-D messages to keep you informed of progress. Only once the external engineering task has been completed will we send you KCI2.

�� !�"��#��$��

�


�

The following process flow provides further detail and response codes:

�

�


Code Response to CP Explanation 566 Openreach missed appointment. This is a KCI delay message.

Openreach has been unable to fulfil this appointment. The CP needs to organise a new appointment.

568 Openreach engineer has been unable to gain access due to exceptional circumstances.

This is a KCI delay message. An extraordinary event has taken place. For example, a bomb scare or flooding. This message applies to appointed orders only.

577 Openreach could not complete work in the allocated appointment slot, please await further details.

This is a delay message. Openreach could not complete work in the allocated appointment slot because the required work exceeded the time allocation.

�� !�"��#��$��

�


�

Note: For CPs on R600 or above, more information may be found in the ListOfNotes/Note tag set. The message will contain details of when the next update will be sent in the NextUpdateDateTime tag set.

578 Further work is required by Openreach to deliver the service, please await further details.

This is a delay message. There will be delay in fulfilling The order. Note: For CPs on R600 or above, more information may be found in the ListOfNotes/Note tag set. The message will contain details of when the next update will be sent in the NextUpdateDateTime tag set.

579 Openreach could not complete work because of a safety-related hazard at the End User premises, please await further details.

This is a delay message. There will be delay in fulfilling the order due to a safety related hazard at the End User premises. The CP should await further information from Openreach. More information may be found in the ListOfNotes/Note tag set. The message will contain details of when the next update will be sent in the NextUpdateDateTime tag set.

581 Openreach could not complete work due to a fault on the distribution side network, please await further details.

This is a delay message. There will be delay in fulfilling the order as a fault has been discovered on the distribution side of the Openreach network. Note: For CPs on R600 or above, more information may be found in the ListOfNotes/Note tag set. The message will contain details of when the next update will be sent in the NextUpdateDateTime tag set.

585 Further work is required to complete the tasks, please await further details.

This is a delay message. There will be delay in fulfilling The order. Note: For CPs on R600 or above, more information may be found in the ListOfNotes/Note tag set. The message will contain details of when the next update will be sent in the NextUpdateDateTime tag set.

594 Openreach Delay. This is a delay message. There has been a delay on the Openreach side. For FTTP, Openreach will try to organise a new appointment with the end user. Openreach will schedule a new appointment if the End User cannot be contacted. The CP should then contact the End User and confirm the appointment or amend the CRD if necessary. If the appointment is not confirmed or amended before the Point of No Return (PONR), the order will be cancelled. Note: More information may be found in the ListOfNotes/Note tag set. The message will contain details of when the next update will be sent in the NextUpdateDateTime tag set.

620 Openreach missed appointment . New appointment will be , please confirm appointment with End User and

Openreach missed the appointment on the date specified. The message contains details of the new appointment date.

�� !�"��#��$��

�


�

ensure access, or send Amend (Customer Required by Date) CRD request.

5462 Provision of service will be delayed due to issues with the line plant, please await further details.

Provision of service will be delayed due to issues with the line plant, please await further details. Note: More information may be found in the ListOfNotes/Note tag set. The message will contain details of when the next update will be sent in the NextUpdateDateTime tag set. 2006-07-26T00:00:00

5464 Provision of service will be delayed due to issues with provision of the underground network, please await further details.

Provision of service will be delayed due to issues with the underground network. Where further information is available, this will be found in the List of Notes. Please await an update.

5466 Provision of service will be delayed due to issues relating to permission to provide the network, please await further details.

Provision of service will be delayed due to issues relating to permission to provide the network, for example where this is required under the Traffic Management Act (TMA). Please await further details. More information may be found in the ListOfNotes/Note tag set. The message will contain details of when the next update will be sent in the NextUpdateDateTime tag set. Where TMA permission to work is required, please note that amends or cancellations may be chargeable.

5480 Openreach could not provide the service because the End User provided instructions different to those provided by the CP, the installation address was unoccupied or the premises were not ready.

Openreach is unable to provide the service as: 1) The End User provided instructions to the Openreach engineer on site which were different to the instructions provided by the CP, or 2) The installation address was unoccupied, or 3) The premises were not ready 4) There were issues with the order. These could include: Duplicate order, End user unaware of order, End user says order cancelled, Order not what the End User requested, Incorrect address, Incorrect required-by date Use the Openreach Order Tracker to obtain more information on the specific details. Note: Abortive visit charges apply.

9390 The Order Target Date has been amended to [%1].

This is a delay message. The Order Target Date (OTD) has been amended to [%1]. This may be because of a third-party delay such as provision of duct.

�

�

�� !�"��#��$��

�

Issue 1.5 Issued by Openreach �� %%��

�

�

4.4 ORC2M-9412 FTTP: Capture whether end user has consented to access to the outside of their premises

Immediate Release Impacts: The default position for pre-R1600 schema will be that End User presence is required for external visits.

Schema Upgrade Fundamentals: A new tag will be available when you upgrade to the new version of the schema.

4.4.1 Story Details As a CP, I want my customers to be able to indicate their consent for an external visit to install a new FTTP service. So that the external work can be completed prior to the date of the internal installation either without my customer having to be there in person or on a date that is suitable to them.

4.4.2 Introduction

�Sometimes it is necessary for Openreach to make two separate engineering visits to your customers’ premises in order to install a new FTTP service. Firstly to perform any external work and secondly to complete the installation internally. For your customers’ convenience the external work may be undertaken without them needing to be there, so long as they provide their consent and have arranged for any access to the site as required (e.g. unlocking gates, tethering dogs etc.). This only applies where a new ONT is required. When two visits are needed the external work will normally be carried out three days before the internal appointment but we can change the dates to suit your customer.


�Change




ORC2M-9412

Capture whether End User has consented to access to the outside of their premises

Fulfilment FTTP Upgrade CP is able to indicate on order if EU has consented to an engineer accessing the outside of their property in support of a 2-stage installation

Yes New XML tag

�


�

XML XXXXXXXX

Data EUConsentForExternalVisit : EU Access Granted | EU Presence Required | EU Presence reqd on Other Date

Process No changes

Behaviour No changes

�� !�"��#��$��

�


�

Response Codes No changes

�


�A new tag is added to FTTP provide orders to enable you to indicate the level of consent your customer has given to an engineer accessing the outside of their premises. This applies to the following order type:

• GEA FTTP Provide New Installation

XML snippet: EU Access Granted | EU Presence Required | EU Presence reqd on Other Date Permitted values: EU Access Granted Your customer grants access to the outside of

their premises three days prior to the requested provision date (i.e. CRD-3) without them needing to be there.

EU Presence Required Your customer needs to be present for the external installation and is available three days prior to the requested provision date (i.e. CRD-3).

EU Presence reqd on Other Date The date of CRD-3 is not convenient for your customer and a new appointment date needs to be agreed. Your customer’s presence may or may not be required.

Use of the tag is optional and will default to a value of EU Presence Required if it is missing or left blank. Invalid values will cause the order to be rejected and existing response code 251 will be returned with response text: “Invalid value for field ” If a value of EU Presence reqd on Other Date is provided Openreach will contact your customer to arrange a suitable date. Your customer can choose whether to grant access or be present on the new date. Openreach will internally update the value so the field engineer knows whether your customer should be present or not. The external and internal appointment dates need to be a minimum of 3 days apart. The new tag will be returned in OrderPending and OrderRejected KCI messages. It will not be returned in subsequent KCIs. It will not be possible for you to change the value of the new tag within an AmendOrder but you will be able to request a change to the external or internal appointment date(s) as long as the request is made prior to the PONR for the appointments already given (18:00 on the previous day). If the tag is provided within an AmendOrder it will be ignored. If an alternative appointment date needs to be arranged the Openreach SMC will contact your customer directly to arrange convenient dates for the external and internal visits. This could result in the CRD being missed. If this happens you will be notified within KCI2 with a CCD Delay reason of No Appointment Available. …

No Appointment Available …

�� !�"��#��$��

�


�

Automated appointment reminder calls will be made to your customer 2 days prior to each of the external and internal visits.


Code Response to CP Explanation 251 Invalid value for field

%1 The order has been rejected as incorrect data has been entered in the field specified in the message.

�

�� !�"��#��$��

�

Issue 1.5 Issued by Openreach �� %$��

�

4.5 ORC2M-11753 FTTP: Change FTTP bandwidths to accommodate the management overheads.

Immediate Release Impacts: This functionality will be available to all users immediately.


4.5.1 Story Details As a CP I want to purchase service that I can market to end user customers that deliver 100Mb/s downstream at the IP layer for FTTP without any management information consuming bandwidth causing the rate delivered to drop below 100Mb/s downstream. Alongside this I want to market FTTP as per current design for Business users. So that. I can market such services in direct competition to cable type services currently sold at a 100Mb/s rate, without FTTP bandwidth offered being impacted by management overheads on the circuits.

4.5.2 Introduction We are introducing a new downstream bandwidth option of 110Mb/s in so that you are able to offer a full 100Mb/s service without consuming bandwidth with management overhead.

4.5.3 Design Summary Change




ORC2M-11753

Change FTTP bandwidths to accommodate the management overheads

Fulfilment FTTP Full CPs are able to order a new 110Mb downstream bandwidth

No New Data Value

4.5.4 Design Changes XML None

Data DownstreamDataBandwidth: 40Mb/s | 100Mb/s | 110Mb/s Process None Response Codes

None

Behaviour None

4.5.5 Design Details In order to enable you to accommodate the management overheads whilst offering a full 100Mb downstream service, a new data value of 110Mb/s has been added. This will only be available with an upstream bandwidth of 15Mb/s. The new value will be available for both provide and modify orders. 15Mbit/s 110Mbit/s OGHP99999999

�� !�"��#��$��

�

Issue 1.5 Issued by Openreach �� %&��

�

XXXXXXXXXXXX XXXXXXXXX

XML Elements Definition Description //LineItem/Features/GEAFeatureSet/Provision/ProvisionAEnd/UpstreamDataBandwidth

Upstream Bandwidth required by the CP.

LOV: • 2Mbit/s • 10Mbit/s • 15Mbit/s • 30Mbit/s

Indicated bandwidths are peak values. Please note that only 15Mb/s will be available with downstream value of 110Mb/s

//LineItem/Features/GEAFeatureSet/Provision/ProvisionAEnd/DownstreamDataBandwidth

Downstream Bandwidth required by the CP.

LOV: • 40Mbit/s • 100Mbit/s • 110Mbit/s (new data value)

Indicated bandwidths are peak values.

4.5.6 Response Code Changes There are no changes to response codes as a result of this enhancement.

�� !�"��#��$��

�

Issue 1.5 Issued by Openreach �� %'��

�

�

4.6 ORC2M-13886 FTTP: Make ServiceID/DN optional in MACCHECKER [‘AddMacStatus’] Request

�Immediate Release Impacts: You no longer need to enter the InstallationDN and/or ServiceID when using the MAC Status Dialogue Service


4.6.1 Story Details �As a CP I want the ServiceID & InstallationDN field to be made optional while using the MAC Status Dialogue Service So that I

Date post:	25-Jan-2021
Category:	Documents
Upload:	others
View:	12 times
Download:	0 times

Functional and Upgrade Document for NGA CPs: R1600€¦ · 3 R1600 – GEA Common Enhancements...

Documents