EMP Functional Changes in R1700 for FTTP and FTTC CPs ... · EMP Functional Changes in Release 1700...

Draft 1.0 Issued by Openreach © British Telecommunications plc 2010 Page 1 of 75

EMP Functional Changes in Release 1700 for FTTP and FTTC CPs Issue 1.2

EMP Functional Changes in Release 1700 for FTTP and FTTC CPs

Issue 1.2 Issued by Openreach © British Telecommunications plc 2011 Page 2 of 75

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 First issue Issue 1.1 Ruth Parry 26th September 2011 R1710 stories ORC2M-19036 and ORC2M-

20107 added. ORC2M-13141 removed Issue 1.2 Ruth Parry 3rd October 2011 R1713 story ORC2M-20655 added.



��

1� INTRODUCTION ........................................................................................................................ 7�

2� DEFINITIONS ............................................................................................................................ 8�

2.1� CLASSIFICATION ........................................................................................................................................................ 8�2.2� IMMEDIATE RELEASE IMPACT ................................................................................................................................... 8�2.3� SCHEMA UPGRADE FUNDAMENTALS ........................................................................................................................ 8�2.4� PORTAL IMPACTS ...................................................................................................................................................... 8�

3� R1700 – GEA COMMON ENHANCEMENTS (FTTC AND FTTP) .............................................. 9�

3.1� ORC2M-10738 FTTC/FTTP: CVLAN SWITCH FOR SMC TO SUPPORT CENTRAL TEST HEAD (GOLDEN END USER ONLY) ......................................................................................................................................................................... 9�

3.1.1� Story Details .................................................................................................................................................... 9�3.1.2� Introduction ...................................................................................................................................................... 9�3.1.3� Design Summary ............................................................................................................................................ 9�3.1.4� Design Change Analysis ............................................................................................................................. 10�3.1.5� Design Details ............................................................................................................................................... 10�3.1.6� Response Code Changes ........................................................................................................................... 10�

3.2� ORC2M-12748 FTTC/FTTP: SERVICE TEST UPDATE FOR ACTIVE MULTICAST IGMP JOINS .......................... 11�3.2.1� Story Details .................................................................................................................................................. 11�3.2.2� Introduction .................................................................................................................................................... 11�3.2.3� Design Summary .......................................................................................................................................... 11�3.2.4� Design Change Analysis ............................................................................................................................. 11�3.2.5� Design Details ............................................................................................................................................... 11�3.2.6� Response Code Changes ........................................................................................................................... 12�

3.3� ORC2M-13424 FVA/FTTP: MODIFY RID FUNCTIONALITY ................................................................................. 13�3.3.1� Story Details .................................................................................................................................................. 13�3.3.2� Introduction .................................................................................................................................................... 13�3.3.3� Design Summary .......................................................................................................................................... 13�3.3.4� Design Change Analysis ............................................................................................................................. 13�3.3.5� Design Details ............................................................................................................................................... 13�3.3.6� Response Codes .......................................................................................................................................... 14�

3.4� ORC2M-14271 FTTC/FTTP: EMLC ENHANCEMENTS (PCP BASED READINESS LOGIC CHANGE FOR FTTP AND FTTC) ......................................................................................................................................................................... 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� Worked Example .......................................................................................................................................... 16�3.4.7� Response Code Changes ........................................................................................................................... 16�

3.5� ORC2M-14341 FTTP/FTTC BULK INSTALL TIME WINDOW ................................................................................ 17�3.5.1� Story Details .................................................................................................................................................. 17�3.5.2� Introduction .................................................................................................................................................... 17�3.5.3� Design Summary .......................................................................................................................................... 17�3.5.4� Design Changes ........................................................................................................................................... 17�3.5.5� Design Details ............................................................................................................................................... 18�3.5.6� Response Code Changes ........................................................................................................................... 18�

3.6� ORC2M-14805 FTTC/FTTP/FVA: CONSUMPTION OF ORDER AND FAULT TRACKER RECORDS IN DIALOGUE SERVICES ............................................................................................................................................................................ 19�

3.6.1� Story Details .................................................................................................................................................. 19�3.6.2� Introduction .................................................................................................................................................... 19�3.6.3� Design Summary .......................................................................................................................................... 19�3.6.4� Design Change Analysis ............................................................................................................................. 19�



3.6.5� Design Details ............................................................................................................................................... 19�3.6.6� Response Codes .......................................................................................................................................... 21�

3.7� ORC2M-15698 FTTC/FTTP: IMPROVEMENTS TO FAULT CLOSURE PROCESSES FOR SFA REMOTE ASSURE . 22�3.7.1� Story Details .................................................................................................................................................. 22�3.7.2� Introduction .................................................................................................................................................... 22�3.7.3� Design Summary .......................................................................................................................................... 22�3.7.4� Design Changes ........................................................................................................................................... 22�3.7.5� Design Details ............................................................................................................................................... 23�3.7.6� Response Code Changes ........................................................................................................................... 23�3.7.7� Clear Codes for Non Openreach Domain Faults ..................................................................................... 25�

3.8� OR-4663 –ADDRESS MATCHING DIALOGUE SERVICE (AMDS)........................................................................... 26�3.8.1� Story Details .................................................................................................................................................. 26�3.8.2� Introduction .................................................................................................................................................... 26�3.8.3� Dialogue Services ........................................................................................................................................ 26�3.8.4� Copper Fulfilment ......................................................................................................................................... 27�3.8.5� Response Code Changes ........................................................................................................................... 28�

4� R1700 – FTTP ENHANCEMENTS ........................................................................................... 29�

4.1� ORC2M-4060 FTTP/ FVA : MANAGEMENT OF GEA-FTTP DATA TROUBLE TICKET WITH ADDITIONAL NGA SERVICE ON THE SAME ONT .............................................................................................................................................. 29�

4.1.1� Story Details .................................................................................................................................................. 29�4.1.2� Introduction .................................................................................................................................................... 29�4.1.3� Service Test Dialogue Service ................................................................................................................... 29�4.1.4� Assurance ...................................................................................................................................................... 30�

4.2� ORC2M-10241 FVA/FTTP SERVICE TEST FAILURE DURING PROVISION (WHERE MFL COMES AS “CA”) ...... 32�4.2.1� Story Details .................................................................................................................................................. 32�4.2.2� Introduction .................................................................................................................................................... 32�4.2.3� Design Summary .......................................................................................................................................... 32�4.2.4� Design Change Analysis ............................................................................................................................. 32�4.2.5� Design Details ............................................................................................................................................... 32�4.2.6� Response Code Changes ........................................................................................................................... 33�

4.3� ORC2M-12510 FTTP MDU/MOU L2C: DISPLAY MDU STATUS ON EMLC AND ACCEPT ORDERS AT AN ENABLED MDU ................................................................................................................................................................... 34�

4.3.1� Story Details .................................................................................................................................................. 34�4.3.2� Introduction .................................................................................................................................................... 34�4.3.3� Design Summary .......................................................................................................................................... 34�4.3.4� Design Change Analysis ............................................................................................................................. 34�4.3.5� Design Details ............................................................................................................................................... 35�4.3.6� Response Code Changes ........................................................................................................................... 37�

4.4� ORC2M-12511 FTTP/FVA MDU/MOU T2R: ACCEPT AND RESOLVE FAULTS IN AN MDU (MULTI-TENANCY DWELLING UNIT) CONTEXT ................................................................................................................................................. 38�

4.4.1� Story Details .................................................................................................................................................. 38�4.4.2� Introduction .................................................................................................................................................... 38�4.4.3� Design Summary .......................................................................................................................................... 38�4.4.4� Design Change Analysis ............................................................................................................................. 38�4.4.5� Design Details ............................................................................................................................................... 39�4.4.6� Response Code Changes ........................................................................................................................... 39�

4.5� ORC2M-12750 – FVA/FTTP: BATTERY BACKUP UNIT & BATTERY ................................................................... 41�4.5.1� Story Details .................................................................................................................................................. 41�4.5.2� Introduction .................................................................................................................................................... 41�4.5.3� Design Summary .......................................................................................................................................... 41�4.5.4� Design Change Analysis ............................................................................................................................. 41�4.5.5� Design Details ............................................................................................................................................... 42�4.5.6� Response Code Changes ........................................................................................................................... 43�

4.6� ORC2M-13439 – FVA/FTTP: HANDLING ONT NOT REACHABLE DUE TO POWER OFF FOR THE ONT ............. 44�4.6.1� Story Details .................................................................................................................................................. 44�4.6.2� Introduction .................................................................................................................................................... 44�4.6.3� Design Summary .......................................................................................................................................... 44�4.6.4� Design Changes ........................................................................................................................................... 44�



4.6.5� Design Details ............................................................................................................................................... 44�4.6.6� Response Code Changes ........................................................................................................................... 45�

4.7� ORC2M-13492 FVA/FTTP: ENHANCED TEST AND DIAGNOSTIC CAPABILITY FOR FVA PRODUCT .................. 46�4.7.1� Story Details .................................................................................................................................................. 46�4.7.2� Introduction .................................................................................................................................................... 46�4.7.3� Design Summary .......................................................................................................................................... 46�4.7.4� Design Change Analysis ............................................................................................................................. 46�4.7.5� Design Details ............................................................................................................................................... 47�4.7.6� Response Code Changes ........................................................................................................................... 49�

4.8� ORC2M-20107 FTTP: (CONFIG CHANGE) CHANGE IN THE LEAD TIME OF FTTP CEASE .................................. 50�4.8.1� Story Details .................................................................................................................................................. 50�4.8.2� Introduction .................................................................................................................................................... 50�4.8.3� Design Summary .......................................................................................................................................... 50�4.8.4� Design Changes ........................................................................................................................................... 50�4.8.5� Design Details ............................................................................................................................................... 50�4.8.6� Response Code Changes ........................................................................................................................... 50�

4.9� ORC2M-20655 FTTP SUPPORTING MULTIPLE HEAD ENDS - TACTICAL PROCESS SOLUTION ........................... 51�4.9.1� Story Details .................................................................................................................................................. 51�4.9.2� Introduction .................................................................................................................................................... 51�4.9.3� Design Summary .......................................................................................................................................... 51�4.9.4� Design Changes ........................................................................................................................................... 51�4.9.5� Design Details ............................................................................................................................................... 52�4.9.6� Response Code Changes ........................................................................................................................... 52�

5� R1700 – FTTC ENHANCEMENTS ........................................................................................... 53�

5.1� ORC2M-8374 FTTC: PCP-ONLY PROVIDE ......................................................................................................... 53�5.1.1� Story Details .................................................................................................................................................. 53�5.1.2� Introduction .................................................................................................................................................... 53�5.1.3� Design Summary .......................................................................................................................................... 53�5.1.4� Design Changes ........................................................................................................................................... 53�5.1.5� Design Details ............................................................................................................................................... 54�5.1.6� Response Code Changes ........................................................................................................................... 54�

5.2� ORC2M-11913 FTTC: REDUCE THE MINIMUM SPEED FOR GEA FROM 5MBIT/S TO 2MBIT/S .......................... 55�5.2.1� Story Details .................................................................................................................................................. 55�5.2.2� Introduction .................................................................................................................................................... 55�5.2.3� Design Summary .......................................................................................................................................... 55�5.2.4� Design Change Analysis ............................................................................................................................. 55�5.2.5� Design Details ............................................................................................................................................... 55�5.2.6� Response Code Changes ........................................................................................................................... 56�

5.3� ORC2M-14742 RRT IMPROVEMENTS FOR FTTC .............................................................................................. 57�5.3.1� Story Details .................................................................................................................................................. 57�5.3.2� Introduction .................................................................................................................................................... 57�5.3.3� Design Summary .......................................................................................................................................... 57�5.3.4� Design Change Analysis ............................................................................................................................. 57�5.3.5� Design Details ............................................................................................................................................... 57�5.3.6� Response Code Changes ........................................................................................................................... 58�

5.4� ORC2M-15098 FTTC: INCLUSION OF VDSL ERRORED SECONDS IN GEA SERVICE TEST ............................... 59�5.4.1� Story Details .................................................................................................................................................. 59�5.4.2� Introduction .................................................................................................................................................... 59�5.4.3� Design Summary .......................................................................................................................................... 59�5.4.4� Design Change Analysis ............................................................................................................................. 59�5.4.5� Design Details ............................................................................................................................................... 60�5.4.6� Response Code Changes ........................................................................................................................... 61�

5.5� ORC2M-19036 FTTC: ALIGN CURRENT SUB 15M DOWNSTREAM SPEED ESTIMATES TO MORE OPTIMISTIC ALGORITHM USED ON 15M+ LINES ...................................................................................................................................... 62�

5.5.1� Story Details .................................................................................................................................................. 62�5.5.2� Introduction .................................................................................................................................................... 62�5.5.3� Design Summary .......................................................................................................................................... 62�5.5.4� Design Changes ........................................................................................................................................... 62�



5.5.5� Design Details ............................................................................................................................................... 62�5.5.6� Response Code Changes ........................................................................................................................... 62�

5.6� OR-3844 ORCE-16666 CP HAS VISIBILITY OF CABLE BREAKDOWN FAULTS ...................................................... 63�5.6.1� Story Details .................................................................................................................................................. 63�5.6.2� Introduction .................................................................................................................................................... 63�5.6.3� Design Summary .......................................................................................................................................... 63�5.6.4� Design Changes ........................................................................................................................................... 63�5.6.5� Design Details ............................................................................................................................................... 63�5.6.6� Response Code Changes ........................................................................................................................... 64�

6� ENHANCEMENT SUMMARY .................................................................................................. 65�

6.1� DIALOGUE SERVICES AND REPORTS ..................................................................................................................... 65�6.2� FULFILMENT ............................................................................................................................................................ 68�6.3� ASSURANCE ............................................................................................................................................................ 72�

7� APPENDIX A – GLOSSARY OF TERMS ................................................................................ 74�



1 Introduction

This document explains the functional design changes and upgrade information for Release 1700 of the Equivalence Management Programme (EMP) for the Generic Ethernet Access (GEA) products FTTP and FTTC. 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 and/or using the Openreach Portal.



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 B2B 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 B2B schema. FULL - The functionality will become operational when the release is deployed, regardless of whether the CP uses the new version of the B2B 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 B2B schema. This classification does not apply to the Portal users since changes on the portal take effect immediately a release is live. 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. 2.4 Portal Impacts Changes to the Portal will be visible as soon as the new release goes live.

• XML changes affect which fields you see on the Portal • Data changes affect what values are allowed in fields, including the values in any drop down lists • Process changes mean you need to check whether your own processes need reviewing and changing • Response codes relate to the information/warning/error messages returned during the lifecycle of a

transaction (order, trouble report etc.) • Behaviour changes can be more subtle, and may or may not affect Portal users.

For each change, in the Design Change Analysis section, there is a category called “Portal” which summarises how changes affect you.



3 R1700 – GEA Common Enhancements (FTTC and FTTP)

3.1 ORC2M-10738 FTTC/FTTP: CVLAN switch for SMC to support Central Test Head (Golden End User Only)

Immediate Release Impacts None

Schema Upgrade Fundamentals None

3.1.1 Story Details As the Openreach SMC I want the ability to switch the Central Test Head onto a customer circuit via an existing service test So that I avoid the need for manual interactions to set this up. This story is to apply the Central Test Head as a Golden EU (End User). Golden CP was covered by ORC2M-7229 in R1500.

3.1.2 Introduction This is an extension of ORC2M-7229, which was covered in R1500. In that story, CVLAN rearrangement was designed to perform a Golden CP test. This story allows CVLAN rearrangement for a Golden EU test. The aim of the Golden EU test is to employ the CTH to emulate an EU communicating with the CP network. This will test the connectivity from the DSLAM up to the CP. The test setup is illustrated in the figure below: L2S OLT The circuit to your customer is disconnected at the DSLAM between the DSL port and the backhaul port. This is service affecting and your customer will lose all communications to you for the duration of the test. Note: Application of the CTH only affects the GEA Data VLAN, it does not affect the separate Voice VLAN. Therefore your customer’s voice service should not be affected during the test.

3.1.3 Design Summary Change Ref

Title Scope Products Classifi-cation*

Functional Summary

XML CP Impact Summary

ORC2M-10738

CVLAN Switch for SMC to Support Central Test Head (Golden End User Only)

Assurance FTTC FTTP

Full Allows additional diagnostic testing by applying a ‘Golden EU’ via the CTH

No Intrusive test on EU service

Customer R-DSLAM L2S

Access Fibre

Central Test Head

x

Acting as an Golden End User

CP



3.1.4 Design Change Analysis XML None

Data None

Process None

Behaviour Provides an additional test capability via an intrusive test on your customers service

Response Codes None

Portal None

3.1.5 Design Details A Golden EU test may be undertaken by Openreach in response to an SFA RA request from you. If you try to perform a GEA service test when a Central Test Head (either Golden CP or Golden EU) is applied the following test diagnostic outcome code will be returned: “GTC_TEST_1051- Service is under test – Please try after sometime”, the MFL will be DT with a test outcome of Inconclusive. Note: Availability of the Golden EU test is infrastructure dependent. Please refer to Openreach for the availability of this functionality after R1700.

3.1.6 Response Code Changes No response code changes.



3.2 ORC2M-12748 FTTC/FTTP: Service test update for active Multicast IGMP joins Immediate Release Impacts None


3.2.1 Story Details As a CP I want a diagnostics test that can report on the active Multicast channels on a line So that I can demarcate the root cause of failures with Multicast connections on/off the Openreach network.

3.2.2 Introduction This story will provide active Multicast Channel Information to CPs by providing the IP address of each active Multicast channel on a particular FTTC or FTTP service. This capability will be available via Portal and the B2B interface via the Service Test 2 Dialogue Service.



Functional Summary


ORC2M-12748

FTTC/FTTP: Service test update for active Multicast IGMP joins

Dialogue Services

FTTC FTTP

Full New capability within the Service Test 2 Dialogue Service to view active Multicast information

No New data New process


Data New Test category:

TestCategory Request Real Time NGA Network Data

Process New process to display active Multicast information

Behaviour None

Response Codes None

Portal New test category available and new results fields returned.

3.2.5 Design Details A new Test Category of Request Real Time NGA Network Data is provided to the Service Test 2 Dialogue Service. <dt:TestCategory>Request Real Time NGA Network Data</dt:TestCategory> The following data elements will appear in the response to CP: 1) IGMP Program IP address 2) Outcome Code 3) Outcome Description



4) Multicast - Enabled / Not Enabled xml snippet: <dt:TestResultSummary> <dt:TestCategory>Request Real Time NGA Network Data</dt:TestCategory> <dt:TestOutcomeCode>GTC_NGA_DATA_0001</dt:TestOutcomeCode> <dt:TestOutcomeDescription>Friendly text message</dt:TestOutcomeDescription> <dt:TestStartDateTime>2005-12-30T09:30:47</dt:TestStartDateTime> <dt:TestStopDateTime>2005-12-30T09:30:47</dt:TestStopDateTime> <dt:AdditionalInformation> <dt:ListOfTestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Multicast</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>Enabled</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>IGMP_Program</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>225.6.5.4</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>IGMP_Program</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>225.6.5.5</dt:FeatureValue> </dt:TestResultFeature> </dt:ListOfTestResultFeature> </dt:AdditionalInformation> </dt:TestResultSummary>




3.3 ORC2M-13424 FVA/FTTP: Modify RID Functionality Immediate Release Impacts None


3.3.1 Story Details As Openreach Product Line I want to be able to support requests of RID modification by CP's via a Modify Order journey as a Singleton request. So that Openreach records are updated with the correct RID values where the EU changes RID's.

3.3.2 Introduction If your end user changes to another retailer for his or her service, this change allows you to keep the Openreach records in step with yours. It will also allow you to add a RID to an FTTP service that was set up before RID became mandatory. Note, you will be charged for us modifying the RID.



Functional Summary


ORC2M-13424

FVA/FTTP: Modify RID functionality

Fulfilment FTTP FVA Upgrade You can modify the RID on existing FVA or FTTP services.

Yes New XML tag on modify orders and responses for RID

3.3.4 Design Change Analysis XML There will be a new XML tag for RID on modify XMLs.

Data None

Process You can now also modify the RID on an existing FVA or FTTP service.

Behaviour None

Response Codes Re-use of existing provide response codes.

Portal You can modify the RID on an existing FVA or FTTP service immediately R1700 goes

live.

3.3.5 Design Details This change allows you to modify the RID on an existing FVA service or FTTP service. It also allows to you to add a RID to an existing FTTP service where there is not one currently, again via a modify request. You can modify the RID as a stand-alone request or in conjunction with other modifications to the service.



XML Snippet The RetailerParty XML block will now be included in the Modify XML following BuyerParty, the same as in the provide XML – <utcc:RetailerParty> <utcc:Party> <utcc:PartyIdentification> <utcc:ID identificationSchemeName="RID">BAG</utcc:ID> </utcc:PartyIdentification> </utcc:Party> </utcc:RetailerParty> We will return it in the OrderPending and OrderRejected XMLs, but not in any other KCIs. Validations As with a provide order, If you enter a value for RID that we do not have on our list from OFCOM, we will reject your order with error response code 5019. If the RID you enter is the same as the RID we already hold, and there are no other modifications, we will reject your order with response code 1555. Charging If the RID you enter is the same as the RID we already hold, and there are other valid modifications in your order, we will not charge you for a RID change. If we successfully modify the RID, you will be charged.

3.3.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 1555 At least one attribute has

to be modified before submission

The order has been rejected. Ensure that at least one of the following is modified in the modify order: 1) Care Package 2) ATA Parameter 3) Hazard & Warning Notes 4) Voice Wiring Solution Option 5) BatteryBackupOption 6) RID

5019 Invalid value <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.



3.4 ORC2M-14271 FTTC/FTTP: eMLC enhancements (PCP based readiness logic change for

FTTP and FTTC) Immediate Release Impacts: New data values will be returned.


3.4.1 Story Details As a CP I want to have the best visibility possible of potential FTTC/FTTP service as early as possible before the exchange / PCPs are enabled So that I can generate interest from potential End Users and set the right expectation about what super fast technology is planned to be available to them.

3.4.2 Introduction This change introduces additional detail into the response to an enhanced Managed Line Characteristics (eMLC) request which will indicate whether there are future plans to upgrade a cabinet to provide FTTP or FTTC service. Where available, proposed ready for service dates will also be included. For completeness, the field value definitions are as follows: D = Deduced. FTTP coverage & RFS date have been deduced from the existing copper area P = Planned. The specific address point has been planned to receive GEA and the RFS date indicates when Y = Yes. Orders can be accepted N = No. GEA planning has not started on this address or there is insufficient capacity at any of the nodes S and U are existing values where there are speed issues on FTTC.



Functional Summary


ORC2M-14271

FTTC/FTTP: eMLC enhancements (PCP based readiness logic change for FTTP and FTTC)

eMLC Dialogue Services

FTTP FTTC

Full Enhancements to eMLC to return information about future plans for fibre rollout.

None New data values

3.4.4 Design Changes XML None

Data New Data Values

FTTCAvailable: P FTTPAvailable: D | P

Process None

Response Codes None

Behaviour None

Portal None



3.4.5 Design Details In response to an eMLC request we will provide, where available, additional information about future plans for fibre rollout. If we have future plans with a ready for service (RFS) date in our systems we will return “P” for planned along with the RFS in the FTTC availability flag or the FTTP availability flag as appropriate. <FTTCAvailability> <FTTCAvailable>P</FTTCAvailable> <FTTCReadyForServiceDate>2011-09-25</FTTCReadyForServiceDate> ……… Additionally for FTTP we also have a new data value of “D” for Deduced where the copper in the area maps back to a cabinet to which we plan to deploy FTTP but as yet we cannot confirm the precise set of addresses which will be served . In this case we will return the value of “D” with the RFS date. <FTTPAvailability> <FTTPAvailable>D</FTTPAvailable> <FTTPReadyForServiceDate>2011-09-25</FTTPReadyForServiceDate> It is anticipated that almost all addresses in the area will be included in the rollout, but if it is confirmed that an address will not be able to order FTTP it will move to “N”. Addresses that remain on the FTTP plans will move to “P” once their inclusion is confirmed and then “Y” once the RFS date is confirmed.

3.4.6 Worked Example When an area is designated as being eligible for fibre rollout, there will be a series of status changes on the eMLC response depending on whether a particular address is intended to get FTTC or FTTP. The table below explains the progression.

Status according to which technology an address point is intended to receive

Activity stage FTTP FTTC

No plans committed yet N N Cabinet areas allocated to FTTP or FTTC D P FTTP detailed planning commences P P FTTP detailed planning concludes that a selected address cannot be served (rare occurrence) N N/A

RFS date achieved Y Y




3.5 ORC2M-14341 FTTP/FTTC Bulk Install time window Immediate Release Impacts You may benefit from inclusion in bulk install windows, but will not receive any explicit KCI to tell you so.

Schema Upgrade Fundamentals You will receive new XML in KCI 2 and KCI3 when an order falls within a bulk install window.

3.5.1 Story Details As Openreach Product Line I want to be able to install significant numbers of lines during a cost-efficient window So that I accelerate take up in a given area

3.5.2 Introduction This story creates new KCI XML to advise you when your FTTP/C orders are eligible for inclusion in an Openreach Bulk Install window.



Functional Summary


ORC2M-14341

FFTP/FTTC Bulk Install time window

Fulfilment FTTP FTTC

Upgrade Confirmation sent in KCI2 and KCI3 that an order falls within a bulk install window

Yes New XML in KCI2 and KCI3 New Data New process

3.5.4 Design Changes XML <gea:BulkInstallOption�Y | N </gea:BulkInstallOption>

Data <<utcc:Name>Type</utcc:Name>�

<utcc:Value>Bulk Install Option</utcc:Value> <utcc:Name>Value</utcc:Name> <utcc:Value>Completed | Cancelled</utcc:Value> <utcc:Name>Cancellation Reason</utcc:Name> <utcc:Value>Bulk Install Not applicable for the Order</utcc:Value> �

Process New process for managing orders which fall within Openreach bulk install windows.

Response Codes

None

Behaviour None

Portal None



3.5.5 Design Details In order to promote FTTP and FTTC we will publish on the Openreach Website details of exchanges where we plan to undertake bulk installations of these products. The details will include dates of a time window for the bulk installations, and if your order is within that time window it will be included in the bulk install. If your order falls within a bulk install window we will confirm this in KCI2 with the new XML tag BulkInstallOption = Y. In KCI3 we will also return the new tag BulkInstallOption = Y | N. If the BulkInstallOption is Y, the progress update will return the value of “Completed”, however if it is N the progress update will return a Value of “Cancelled” with the cancellation reason “Bulk Install Not applicable for the order”. <utcc:LineItemInformationAttribute>

<utcc:Name>Type</utcc:Name> <utcc:Value>Bulk Install Option</utcc:Value>

</utcc:LineItemInformationAttribute> <utcc:LineItemInformationAttribute>

<utcc:Name>Value</utcc:Name> <utcc:Value>Completed/Cancelled</utcc:Value>

</utcc:LineItemInformationAttribute> <utcc:LineItemInformationAttribute>

<utcc:Name>Cancellation Reason</utcc:Name> <utcc:Value>Bulk Install Not applicable for the Order</utcc:Value>

</utcc:LineItemInformationAttribute> An order which is tagged as BulkInstallOption = Y in KCI2 will be marked as BulkInstallOption = N in KCI3 if the actual delivery date falls outside the bulk install window because you have changed the CRD or your customer missed the installation appointment. If we miss the installation appointment and therefore the delivery falls outside the bulk install window we will still return BulkInstallOption = Y in KCI3 with a value of “Completed”. If an order does not fall within a bulk install window it will be progressed as BAU, and the BulkIstallOption tag will not be returned in either KCI2 or KCI3. However, if an expedite amend order brings the delivery date within a bulk install window we will then send you BulkInstallOption = Y in KCI2 and continue as above with the bulk install process. If an order which is initially tagged as Y in KCI2 is delayed by either you or your customer, and therefore falls outside the bulk install window, you will receive BulkInstallOption = N in KCI3 with the cancellation reason “Bulk Install Not applicable for the Order”. If however the delay is as a result of our own activities we will return BulkInstallOption = Y in KCI3.




3.6 ORC2M-14805 FTTC/FTTP/FVA: Consumption of order and fault tracker records in

Dialogue Services Immediate Release Impacts None


3.6.1 Story Details As a CP I want to ensure that I receive all the order and fault tracker records (that are imported to the order and fault tracker portal) in the form of a B2B interface via Sentry XML web services So that I can communicate the contents of the notes onward to my advisors and service provider customers, when they chase on order progress.

3.6.2 Introduction Currently we only pass back limited information between order commitment (KCI-2) and order completion (KCI-3) via B2B. Similarly we only pass back limited information on the progress of a fault (Trouble Report) between acceptance and clearance via B2B. Extra information is already available on portal via the order and fault trackers. This change now allows you to get this information for a single order or fault via the Sentry B2B interface so that you can better integrate it into your systems.



Functional Summary


ORC2M-14805

FTTC/FTTP/FVA: Consumption of order and fault tracker records in Dialogue Services

Sentry Dialogue Services

FTTC FTTP FVA

Upgrade New Dialogue Service to return Order and Fault tracker records.

Yes New Sentry XML interface New Response Codes

3.6.4 Design Change Analysis XML There will be new XML for these dialogue services. Please see the relevant XML

documentation for the details.

Data None

Process You can now get details of a single order or fault via Sentry

Behaviour None

Response Codes None

Portal None

3.6.5 Design Details



This change provides you with two new dialogue services to get additional order and fault information back via an XML interface instead of just being available on portal. Please note the following limitations on this dialogue service though –

They are only available via Sentry and not the B2B interface They only support FTTC, FTTP and FVA services You can only get information on one order or fault at a time There will be limits on the number of requests you can submit imposed

3.6.5.1 Order Tracker You will be able to get this information via an order Details Query on Sentry, using the XML structure AddOrderDetailsQuery. When using this dialogue service, you will need to supply the following mandatory information – XML Tag Name Validation Order Number OrderReference (outer container) Must be entered and must not include

any special characters (such as &, %, * etc).

DUNS ID RequesterParty (outer container) Must be entered Product Name SellersItemIdentification (outer

container) Must be entered and one of following

Generic Ethernet Access Generic Ethernet Access – FTTP FVA

If you do not supply one of these values or what you supply is invalid your request will be rejected with response code 2807. The order number you provide must be the Openreach order reference number we allocated to your order and notified to you in the Order Acknowledgement we send you. If we cannot find the order number on our systems, we will reject your request with response code 2823 If the order belongs to another CP we will reject your request with response code 2822. If the order is for another product we will reject your request with response code 2824. Very occasionally we may need to return response code 2802 when we are experiencing delays in communicating with our back end systems. If your request is successful, we will return response code 2800 along with the order data.

3.6.5.2 Fault Tracker You will be able to get this information via a trouble Report Details Query on Sentry, using the XML structure AddTroubleReportDetailsQuery. When using this dialogue service, you will need to supply the following mandatory information – XML Tag Name Validation Fault Number TroubleReportReference (outer

container) Must be entered and must not include any special characters (such as &, %, * etc).

DUNS ID RequesterParty (outer container) Must be entered Product Name ServiceType Must be entered and one of following

Generic Ethernet Access Generic Ethernet Access – FTTP FVA



If you do not supply one of these values or what you supply is invalid your request will be rejected with response code 2807. The fault number you provide must be the Openreach fault reference number we allocated to your trouble report and notified to you in the Trouble Report Acknowledgement we send you. If we cannot find the fault number on our systems, we will reject your request with response code 2826 If the fault belongs to another CP we will reject your request with response code 2825. If the fault is for another product we will reject your request with response code 2827. Very occasionally we may need to return response code 2802 when we are experiencing delays in communicating with our back end systems. If your request is successful, we will return response code 2800 along with the fault data.

3.6.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 2800 Request successful The request was successful. 2802 System fault encountered

– please re-submit your request at a later time. If the fault persists report the problem to Openreach

The request failed - possibly as a result of a transient or internal system fault.

2807 Mandatory field %1 contains no data or contains invalid data

The mandatory field (%1) either contains no data, or the data entered is not valid. For the Order Tracker DS, the order number must be entered and must not include any special characters (such as &, %, * etc).

2822 The order number provided belongs to another CP.

The request is rejected. The order number you have provided was placed by another CP.

2823 No results found for the order number provided.

The request is rejected. No data has been found for the order number you have provided.

2824 This request is for a product not covered by this service.

The request is rejected. This service is not available for the product specified in the order number you have provided.

2825 The fault number provided belongs to another CP.

The request is rejected. The fault number you have provided was placed by another CP.

2826 No results found for the fault number provided.

The request is rejected. No data has been found for the fault number you have provided.

2827 This request is for a product not covered by this service.

The request is rejected. This service is not available for the product specified in the fault reference you have provided.



3.7 ORC2M-15698 FTTC/FTTP: Improvements to fault closure processes for SFA Remote

Assure Immediate Release Impacts If an Openreach Domain fault is found and fixed during an SFA RA you will receive a simpler new fault cleared and close message


3.7.1 Story Details As Openreach I want to improve the process and information provided to CPs for fault closure with SFA Remote Assure So that CP’s receive relevant information and are informed when Openreach Domain faults are fixed remotely.

3.7.2 Introduction This story builds upon the changes that were introduced to the SFA Remote Assure (RA) and Visit Assure (VA) products in R1600 under ORC2M-11116 GEA FTTC/FTTP: SFA RA/VA Process Improvements. In R1600 we introduced the ability for us to treat SFA FTTx2 and FTTx3 trouble reports as FTTx1 reports when we determine the fault is in the Openreach Domain. We advise you with KCIs that it is being progressed as BAU and follow standard FTTx1 processes to resolve and close the fault. This story introduces the same change to RA that we made to VA in R1600 when we are able to promptly fix an Openreach domain fault found during the SFA investigation. The change allows us to clear and close the fault more quickly and simplify the notification you receive.



Functional Summary


ORC2M-15698

FTTC/FTTP: Improvements to fault closure processes for SFA Remote Assure

Assurance FTTC FTTP

Full Change to RA process to close Openreach Domain faults when we are able to resolve remotely and to include Clear Codes with fault closures

No Change in response codes used to clear and close an Openreach Domain fault when we are able to resolve remotely


Data None

Process Process change if an Openreach Domain fault is found and remotely fixed during an RA

investigation



Response Codes

None

Behaviour We will not be sending response codes 9201 or 4150 when we can resolve an RA remotely (as per VA).

Portal None

3.7.5 Design Details If during the course of an RA investigation we find a fault in the Openreach domain and we are able to fix it remotely, we will send you a TroubleReportStatusUpdate message with response code 3300, MFL = OK, and an appropriate Clear Code to show the fault is cleared and closed. All valid FTTC/P Clear Codes will be available. Note; we will no longer send response codes 9201 and 4150 in this scenario. If we are unable to fix the Openreach domain fault remotely we will automatically convert the fault to a standard FTTx1 fault – you will not have to submit a new Trouble Report. There is no change in this process from R1600, shown below for reference: We will reset the PONR (Point of No Return) for the fault and send response code 6017. We will then send 9201 to indicate that we have converted the fault and 4068 to advise that the MFL has been changed. If the MFL = CA we will also send response code 3261 asking you to arrange an appointment with your customer The FTTx1 BAU process will then 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. If the fault is not in the Openreach domain, we will send you one of response codes 9204, 9205 and 9206 along with the respective Clear Code 18.3, 18.4 or 18.5 as part of the fault clear and close message.

3.7.5.1 Missed appointments Missed appointment scenarios are unchanged by this story but are included for completeness. In each case the requested product will remain as an FTTx2 (RA). If we have completed testing with your customer but you are not available during the RA investigation appointment we will send response code 9203 and close the fault. We will not send a Clear Code in this instance. If your customer is not available at the agreed appointment time we will reset the PONR (Point of No Return) for the fault and send response codes 6017 and 9202. You will be expected to raise an Amend request with a new appointment. 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 we miss the scheduled appointment we will reset the PONR (Point of No Return) for the fault and send you response codes 6017 and 9207. We will schedule a new telephone appointment with your customer and then send response code 4183 with the new appointment details. 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 with the new appointment details. 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.

3.7.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 The CP needs to arrange an end user appointment if



required to arrange an appointment

one has not already been made.

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. <tr:Clear> <tr:Code>16</tr:Code> <tr:Message>Customer or end user contacted by BT and guidance given</tr:Message> </tr:Clear>

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.

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.7.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.8 OR-4663 –Address Matching Dialogue Service (AMDS) Immediate Release Impacts When placing an order for copper-based products if you use the new version of the Address Matching Dialogue Service your order will be rejected if a Copper Gold Address is not selected. A Temporary Address Reference will then need to be created. When placing an order for copper-based products if you don’t use the new version of the Address Matching Dialogue Service then the Immediate Release Impact is none.

Schema Upgrade Fundamentals Address Matching Dialogue Service changes

3.8.1 Story Details As a CP I want to understand what technology/infrastructure is available for a particular address So that I can select the Address Reference (NAD key) most suited for my order

3.8.2 Introduction This change allows you to see what technology/infrastructure we are able to provide at a given address and to select the correct Address Reference to use when placing your order. The change introduces a new XML element, ListOfTechnology, in the results returned by the Address Matching Dialogue Service. The ListOfTechnology element and its associated Technology attributes will only be populated if the address returned is classified as a Gold address. When receiving multiple results from the Address Matching Dialogue Service this information will help you select the most appropriate Address Reference for your order. This Address Reference key can then be used in eMLC to check specific product availability. For example, if you wanted to provide FTTC then you would select the Address Reference with a Copper technology marker and check for FTTC availability in eMLC. Please note that in this release only the Copper and PointToPointFibre attributes will be populated. FTTPBrownField and FTTPGreenfield will be populated in a future release. Because of this, any gold address key can be used to check for GEA-FTTP availability in eMLC and to place a GEA-FTTP order.

3.8.3 Dialogue Services

3.8.3.1 Design Summary Change Ref


Functional Summary


OR-4663 Address Matching Dialogue Service

Dialogue Service

LLU WLR3 PSTN ISDN30, ISDN2E FTTC FTTP Ethernet SBS

Upgrade Introduction of new technology marker for address matching.

Yes New XML New Data New Process



3.8.3.2 Design Changes XML <ListOfTechnology>

<Technology>xxx</Technology> </ListOfTechnology>

Data List of values for Technology: Copper | PointToPointFibre | FTTPBrownfield | FTTPGreenfield

Process New process for selecting the correct Gold address

Response Codes None

Behaviour None

Portal The technology markers will be returned against all Gold keys.

3.8.3.3 Design Details XML changes A new XML element, ListofTechnology, and associated Technology attributes are being added to the results returned to you from the Address Matching Dialogue Service. These will be returned in the AddressDetailsQueryAccepted.xml file. See snippet below. <ListOfTechnology> <Technology>Copper</Technology> <Technology>PointToPointFibre</Technology> <Technology>FTTPBrownfield</Technology> <Technology>FTTPGreenfield</Technology> </ListOfTechnology> The ListOfTechnology element will only be returned for Gold addresses. Process change for selecting the correct address When selecting a Gold address from the results returned by the Address Matching Dialogue Service you must ensure that you use an address that has the correct technology marker for your intended order.

• For Copper based orders only Gold addresses with the Copper technology marker should be used • Fibre based orders may be placed against any Gold address reference that is returned

3.8.4 Copper Fulfilment



Functional Summary


OR-4663 Address Matching Dialogue Service

Fulfilment LLU WLR3 PSTN ISDN30, ISDN2E FTTC

Full Use of correct Gold Address Reference

Yes New Process New Response Code

3.8.4.2 Design Changes XML None

Data None

Process New process for using non-copper Gold addresses



Response Codes New Response Code: 9418

Behaviour None

Portal You will need to ensure you select a valid Copper Gold address for your order

3.8.4.3 Design Details When placing your order for copper based products you must use a Gold Address Reference that has the Copper technology marker associated with it. If you don't, your order will be rejected and Response Code 9418 - Requested address is not copper served – will be returned to you. You will then need to run the Address Matching Dialogue Service again and select an Address Reference that has the Copper technology marker in place. If no such Address Reference exists you can create a Temporary Address Key, using the Add Address request, and re-submit the order. Key points If you are using a pre-1700 version of the Address Matching Dialogue Service with any version of the B2B Copper fulfilment journey this change will not impact you. If you are using a post-1700 version of the Address Matching Dialogue Service with any version of the B2B Copper fulfilment journey your order will be rejected if a Copper Gold Address is not selected. A Temporary Address Reference will then need to be created. As long as the correctly tagged Gold Address Key is selected, from either V1700 of the Address Matching Dialogue Service or the Portal, there will be no impact on the Copper fulfilment journey. Extra care should be taken if you use the Portal for Address Matching and the B2B for placing orders.

3.8.5 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 9418 Requested address is not copper

served The order has been rejected. Although the address provided may have returned a Gold key in the Address Matching Dialogue Service, there is no copper service to the premises. The Technology marker for copper in the DS is set to 'N'.



4 R1700 – FTTP Enhancements

4.1 ORC2M-4060 FTTP/ FVA : Management of GEA-FTTP Data trouble ticket with additional NGA service on the same ONT

Immediate Release Impacts You will receive information about existing faults on the ONT when you run a service test. Faults will be linked and you will receive new response codes


4.1.1 Story Details As an Openreach Product Manager I want: to have processes & systems in place to manage faults on the same ONT with more than one active Service (could be multiple data or voice & data combinations) So that the faults on the same ONT can be managed efficiently with optimal utilisation of the engineering resources

4.1.2 Introduction As each ONT (Optical Network Terminator) has four data ports and two voice ports it is theoretically possible for an end user to have six different services supplied by six different CPs. If a problem occurs with the ONT, an end user could report faults to each of his suppliers, who will then each raise a trouble report (TR), and each TR would then be separately progressed. This story creates the process and functionality to link all the TRs on a single ONT together, and progress them in line with highest service level fault. Additionally, when you run a service test you will receive information advising you if there is already a fault reported against that ONT and details about the target time to fix it.

4.1.3 Service Test Dialogue Service



Functional Summary


ORC2M-4060

FTTP/ FVA : Management of GEA-FTTP Data trouble ticket with additional NGA service on the same ONT

Service Test Dialogue Service

FTTP FVA

Full Information returned about existing fault appointments.

No New Data value


Data <dt:FeatureName>GEA_Fault_Target_Fix_Time</dt:FeatureName>

<dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>2009-03-13T13:51:00</dt:FeatureValue>

Process None

Response Codes

None



Behaviour None

Portal “Target Fix Date Time” returned

4.1.3.3 Design Details When you run a service test on an FTTP or FVA service we will check to see if there is already a fault reported against that ONT, if so, we will advise you of the target fix time for that fault with the new data value GEA_Fault_Target_Fix_Time, where we will return details of the anticipated fix time. <dt:TestResultFeature> <dt:FeatureName>GEA_Fault_Target_Fix_Time</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>2009-03-13T13:51:00</dt:FeatureValue> </dt:TestResultFeature> If there is an existing fault with an appointment, we will return the Appointment_Required_Flag as N.

4.1.4 Assurance



Functional Summary


ORC2M-4060


Assurance

FTTP FVA

Full Faults reported by different CPs against the same ONT will be linked together.

No New Response Codes (FVA) New process


Data None

Process New process to link faults reported against the same ONT together.

Response Codes

New response codes: KCI 9334 – Fault has been made lead fault KCI 9336 – Fault associated with lead fault

Behaviour None

Portal None

4.1.4.3 Design Details Add Trouble Report When you raise a trouble report on an FTTP or FVA service, where the Main Fault Location (MFL) is CA (Customer Apparatus), having run a service test on dialogue services, you will already know whether there is an existing TR against that ONT, and the target fix time for it. If there is an existing appointed fault, you do not



need to make an appointment for your fault, and we will return Response Code 9336 “Fault associated with Lead Fault” along with details of the lead fault target fix time. If your service level allows you to book an earlier appointment you may choose to do so. If you do, and that appointment is prior to the existing appointment, and the existing appointment is not past the point of no return (PONR), your fault will be made the Lead Fault and you will receive KCI 9334 – “Fault has been made Lead Fault”. The CPs of any other TRs will receive KCI 9336 – “Fault associated with Lead Fault” along with details of the new lead fault appointment, and their appointments will be cancelled. If you raise a level 4 non-appointed TR with 24 hour access, and the fix time for the current lead fault is outside that timeframe, your fault will be made the lead fault and you will receive KCI 9334. All other CPs will receive KCI 9336. From this point the fault(s) will be progressed as BAU and all CPs will be kept informed by the usual KCI messages. Amend Trouble Report If you amend an appointment on a trouble report which is associated with a lead fault, or change the 24 access flag or earliest and latest access times, we will check the new details against the existing lead fault appointment. If the new details provide for an earlier appointment than the current lead fault, and the current lead fault appointment is not past PONR, we will make yours the Lead Fault and send you KCI 9334. All other CPs will be sent KCI 9336. If your amendment does not provide for an earlier appointment, or the existing appointment is past PONR you will receive KCI 9336. Cancel Trouble Report If you cancel a trouble report that is linked to other faults, we will disassociate your fault from the others, and cancel it as usual. If your cancelled fault was the lead fault we will identify a new lead fault among the remaining linked faults and send the owning CP KCI 9334. All other CPs will receive KCI 9336. The CP with the new lead fault will then be requested to book an appointment.

4.1.4.4 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 9334 This fault has been made the Lead

Fault

More than one service fault has been raised on the installation. This fault has been identified as Lead Fault as it has the earliest resolution time.

9336 This fault is associated with a Lead Fault

The trouble report has been associated with a Lead Fault. If an appointment has been made this will now be ignored and the Lead Fault appointment or access arrangements will be used instead. The Lead Fault appointment details are provided where these are available. Otherwise the fault will be fixed in accordance with the timescales appropriate to the lead fault's service level, as agreed with the End User. "

NB. These codes are NEW for FVA, but reused for FTTP.



4.2 ORC2M-10241 FVA/FTTP Service Test Failure during provision (where MFL comes as

“CA”) Immediate Release Impacts None.

Schema Upgrade Fundamentals New response code for CPs upgrading to R1700

4.2.1 Story Details As Openreach Service Ops I want to be able to dispatch an engineer (MFL is determined as CA) when the service test fails during the L2C journey in an automated fashion - for subsequent Provision scenarios for FVA-FTTP/GEA-FTTP products

So that I am able to ensure provisioning is done right first time and I potentially reduce DOA scenarios.

4.2.2 Introduction This story applies to FVA and FTTP Subsequent Provide Orders; i.e. where there is no engineering visit. If the Service Test performed following attempted service provision returns a fail with MFL as ‘CA’ we will automatically try and arrange for an engineering visit to your customer’s premise. We will follow a process as though for an EU Missed Appointment scenario.



Functional Summary


ORC2M-10241

Service Test Failure during provision (where MFL comes as "CA")

Fulfilment FTTP FVA

Partial

Delay response code sent when service test on provision fails with MFL=CA

No New response code from R1700. Re-use of existing response code for R1600.


Data None

Process New automated process to arrange an engineer visit in case of service test failure on

provision where the MFL = CA.

Behaviour None

Response Codes New response code for R1700 onwards Re-use of existing response code for pre-R1700 schemas

Portal None

4.2.5 Design Details For FVA and FTTP Subsequent Provide Orders, if the Service Test performed following attempted provision returns a fail with MFL as ‘CA’ we will automatically try and arrange for an engineering visit to your customer’s premises. We will follow a process as though for an EU Missed Appointment scenario.



If you upgrade to R1700 we will send you an Order Status Update message with a new response code 9417 (Service activation failed due to an equipment issue at the end user’s premises.) to indicate to you that a fault at your customer’s premise has been identified due to which the order will be delayed. If you remain on a pre-R1700 schema we will send you an Order Status Update message with existing response code 572 (KCI-3 (Order Completed) Delayed in Processing.). We will book an appointment for 10 working days time. Details will be provided with the Order Status Update message along with a Delay Reason of ‘Customer Delay’ and Confirmation Required = ‘Y’. CRD, OTD, and CCD dates will be aligned with the appointment If you do not confirm or Amend the appointment before CCD-1 18:00 we will automatically cancel the order. If you choose to Amend the appointment you may also additionally amend any other amendable order details in the amend confirmation. The Amend Reason should be ‘In Response to Customer delay’. If you additionally amend any ATA parameters associated with an FVA service provision these will be downloaded to the ONT at 18:00 on CCD if the task has been closed successfully by an Engineer; or immediately after task closure if 18:00 has already passed. If the engineer is unable to complete the task we will follow the BAU processes. Once the engineer task is completed, we will complete the order and send you KCI3 with an Order Sub Type of ‘Sub Prov with Engg Visit’. Note: the Service Test will not fail simply because the ONT is powered-off. If the ONT is powered-off at the time of provision you will be advised by response code 9414 (The ONT is not powered up.) in KCI3. Please refer to ORC2M-13439 in this document for further details.

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 572 KCI-3 (Order Completed)

Delayed in Processing.

This is a KCI delay message. This order has now missed its committed completion date and may still be being progressed. This code will only be sent at the end of the anticipated completion date (CCD) where we have received no update on the order's status. We will notify you when we have more information. If this delay persists, you may wish to advise your end user of the delay.

9417 Service activation failed due to an equipment issue at the end users premises.

This is a delay message. We have been unable to activate the service due to an unidentified issue with the optical network termination (ONT) at the end user's premises. Openreach will book an appointment to fix this issue. NB; This code only applies where an existing ONT is re-used to provide a new service.

9414 The ONT is not powered up. This is a warning message. Openreach has completed the service activation and our network is testing okay. However, these tests indicate that the Optical Network Terminator (ONT) is not powered up.



4.3 ORC2M-12510 FTTP MDU/MOU L2C: Display MDU status on eMLC and accept orders at an enabled MDU

Immediate Release Impacts Changes to FTTP Availability Logic from schema version R1500

Schema Upgrade Fundamentals MDU details returned in new tags

4.3.1 Story Details As a CP I want to be able to place orders at an enabled MDU using a process that is as similar to my existing fulfilment process as possible So that I can serve the widest range of customers possible

4.3.2 Introduction This story enables FTTP service provision in Multiple Dwelling Units (MDUs), i.e. in premises having more than one potential customer in the same premise/building. It provides changes in FTTP Availability logic for MDUs and displays MDU status details in an eMLC response and enables acceptance of provision orders at an enabled MDU. For B2B users the FTTP Availability logic will apply retrospectively for CPs using the R1500 version onwards of the eMLC Dialogue Service. MDU details will be returned from the R1700 version. Note: All reference to MDU in this story should be read as MDU/MOU as it refers to both Multiple Dwelling Units (i.e. residential) and Multiple Occupancy Units (i.e. business).



Functional Summary


ORC2M-12510

FTTP MDU/MOU L2C: Display MDU status on eMLC & Accept orders at an enabled MDU


FTTP Partial Provides MDU details in an eMLC response along with associated FTTP availability

New XML

New XML tags for MDU details from R1700. Change to FTTP Availability logic from R1500.

4.3.4 Design Change Analysis XML New tags:

<MDU> <MDUStatus>Not Started</MDUStatus> <MDUReadyForServiceDate>10-2011</MDUReadyForServiceDate> <MDUProgressUpdate>NA</MDUProgressUpdate> <MDUNotes>NA</MDUNotes> </MDU>

Data See table in Design Details

Process Enables FTTP orders to be placed for enabled MDU premises

Behaviour Change to FTTP Availability and TMA logic for MDU premises



Response Codes None

Portal New MDU fields displayed in eMLC response.

4.3.5 Design Details This story enhances the eMLC dialogue service to provide support for MDU premises and thereby supports the ability for FTTP provide orders to be raised for enabled MDU premises. There are two aspects to this story:

Changes to FTTP Availability Logic to include MDU details Provision of MDU details

4.3.5.1 FTTP Availability Logic For CPs using R1500 or above versions of eMLC the logic FTTP Availability flag will take into consideration the build status of the FTTP network at an MDU premise. The FTTPAvailable flag will only be given as ‘Y’ when build has been completed at the specified MDU premise. In line with BAU a provide order will only be accepted if the flag is ‘Y’.

4.3.5.2 MDU Details From the R1700 version of eMLC the following details will be provided for an MDU premises when the RequiredServiceType has been specified as All, Generic Ethernet Access, or FVA: MDU Status MDU Ready for service date MDU Progress Update MDU Notes These details will only be returned when the PremisesType is Multi Dwelling Unit Residential or Multi Dwelling Unit Business. MDU details will not be returned when the eMLC query is made against a postcode or DP. Example xml snippet: <FTTPAvailability> <FTTPAvailable>N</FTTPAvailable> <FVAAvailable>N</FVAAvailable> <TMANoticeOrPermitRequired>Y</TMANoticeOrPermitRequired> <ServingNetworkNotes>UG Feed Not evaluated</ServingNetworkNotes> <PremisesType>Multi Dwelling Unit Residential</PremisesType> <MDU> <MDUStatus>Not Started</MDUStatus> <MDUReadyForServiceDate>10-2011</MDUReadyForServiceDate> <MDUProgressUpdate>NA</MDUProgressUpdate> <MDUNotes>NA</MDUNotes> </MDU> … <FTTPAvailability> The formatting of the new tags and data is given in the table below:

Element Data Type

Data Length

Mandatory /Optional

Description of element

Notes

MDUStatus String 30 Optional Status of MDU

Possible values of MDU Status:



Not Started Build Complete Interest Expressed Landlord Contacted Permission Granted Build Started Permission not Received Build Not Possible It will be displayed when FTTPAvailable = Y or N

MDUReadyForServiceDate String 7 Optional RFS date of MDU

RFS date by which MDU will be ready. Format : Month-Year e.g. 10-2011 It will be displayed when FTTPAvailable = N

MDUProgressUpdate String 25 Optional Updates on MDU status

Possible values NA (Default) On schedule Not on schedule It will be displayed when FTTPAvailable = N

MDUNotes String 50 Optional Notes of MDU Premise

Possible values: NA (Default) TMA Issues Awaiting Network No Access Safety Issues Re-plan requested Failed Appointment Awaiting Stores It will be displayed when FTTPAvailable = N

Note: If the MDUStatus is other than Build Complete then the all MDU details, i.e. MDUStatus, MDUReadyForServiceDate, MDUProgressUpdate and MDUNotes will be displayed in the eMLC response. If MDUStatus is Build Complete only MDUStatus will be returned. Hence, if FTTPAvailability is ‘Y’ only MDUStatus = ‘Build Complete’ is returned: <FTTPAvailability> <FTTPAvailable>Y</FTTPAvailable> … <MDU> <MDUStatus>Build Complete</MDUStatus> </MDU> … <FTTPAvailability>

4.3.5.3 TMA For MDU premises the TMA flag will be updated appropriately based on the build status.



4.3.5.4 FTTP Bulk Checker Changes to FTTP Availability and TMA logic for MDUs will also be applied to the FTTP Bulk Checker.




4.4 ORC2M-12511 FTTP/FVA MDU/MOU T2R: Accept and Resolve faults in an MDU (Multi-

Tenancy Dwelling Unit) context Immediate Release Impacts Trimming of Response to CP text for response code 6511


4.4.1 Story Details As a CP I want to be able to request faults be fixed when my customer is in an MDU So that my customer continues to get good service

4.4.2 Introduction This story is concerned with the detection of proactive faults in the Distribution Optics of FTTP infrastructure to MDUs and the association of related faults across end customers within an affected MDU. When more than one fault report is raised from separate FTTP and/or FVA services within an MDU which can be linked to a known proactive fault with an MFL of DO (Distribution Optics) we will common these reports together so that they can be resolved by a single engineering visit. Such faults will be appointable and the earliest appointment raised by a CP (typically that with the highest Care Level) will be used. If Openreach does not receive any reactive fault reports within 48 hours against a proactive fault we will then automatically appoint an engineer to clear the fault. There is no change to the process for faults with an MFL of CA (Customer Apparatus). However in such circumstances, in addition to your customer’s individual flat or unit, he or she must also ensure that our engineer can have access to all necessary areas such as service rooms.



Functional Summary


ORC2M-12511

FTTP/FVA MDU/MOU T2R: Accept and Resolve faults in an MDU (Multi-Tenancy Dwelling Unit) context

Assurance FTTP FVA

Full New process associated with FTTP faults affecting an MDU

No New Process Response code changes


Data None

Process New process associated with FTTP and FVA faults affecting an MDU

Behaviour None

Response Codes Response to CP text has been trimmed for 6511.

Explanation has been extended to cover MDU scenarios for 4083 and 6511.



Portal None

4.4.5 Design Details If you are the first CP to raise a service test for an FTTP or FVA service within an MDU and a known proactive fault with an MFL of DO is found; you will be required to raise a Trouble Report with an appointment (Appointment_Required_Flag = ‘Y’). If you raise a Trouble Report without an appointment reference we will reject the request and send you response code 6511 (Appointment reference is not provided). Note, the Response to CP text for this code has been trimmed. Once the Trouble Report is accepted we will return response code 9215 (Fault associated with Openreach Proactive Infrastructure Event). If you are a second (or subsequent) CP to raise a service test you will be informed of the fault with an MFL of DO but the Appointment_Required_Flag will be ‘N’. This is because an appointment already exists from the first CP. The estimated fix date and time (GEA_Fault_Target_Fix_Time) will be given as per the original, or subsequent earlier, appointment from a prior CP’s Trouble Report. However you may request an earlier appointment if available. Once you have submitted an accepted Trouble report you will be sent response code 9215 (Fault associated with Openreach Proactive Infrastructure Event). The earliest requested appointment from any CP will be used for the fault. Later appointment slots which have been raised will be retained at this time in case of cancellation or if subsequent faults are found. When the proactive fault is cleared, the CP with the earliest appointment will receive response code 9216 (Infrastructure Event Update). Other CPs will also receive response code 9216 (Infrastructure Event Update) and those with later appointments will also receive response code 4083 (Notification Only - Appointment Not required) to cancel their appointments. Fault closure will continue as per BAU and you will be requested to accept the fault clearance.

4.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 4083 Notification Only - Appointment

Not required The CP has booked an appointment which is not required. An appointment is required where: 1) The Main Fault Location (MFL) is at the Customer Apparatus (CA), or 2) The Structured Question Code is Damage Report Wiring (DRW) or Damage Report Apparatus (DRA), or 3) The fault is associated with an MDU where an earlier appointment is already present



6511 Appointment reference is not provided.

An appointment reference is mandatory. Openreach will require access where: 1) the Main fault location is Customer Apparatus or 2) the Structured Question Code (SQC) is DRW (Damage Report Wiring) or DRO (Damage Report Overhead), or 3) the fault is associated with an MDU (Multi-tenancy Dwelling Unit).

9215 Fault associated with Openreach Proactive Infrastructure Event

Information Only - Fault associated with Openreach Proactive Infrastructure Event. Progression will continue as per Infrastructure Event Solution.

9216 Infrastructure Event Update Notification Only - Openreach Infrastructure Event is Closed. CP Trouble Report will continue.

Note: Response to CP text trimmed for 6511.



4.5 ORC2M-12750 – FVA/FTTP: Battery Backup Unit & Battery Immediate Release Impacts None


4.5.1 Story Details As Openreach Product Line I want to be able to provide the following (1) Battery Back-up unit when FVA is ordered (2) Support for stand-alone order for FVA/FTTP Battery Backup Units So that I am able to fulfil CP’s request for a Battery Backup.

4.5.2 Introduction The Battery Back Up unit (BBU) ensures continuity of voice service over FVA in case of a power failure. From R1700 Battery Backup units will become a mandatory part of any new FTTP installation and will automatically be included with any new FTTP site installation. If the end user does not want the BBU installed, the engineer will leave it with the end user. (This will change in R1800). For those FTTP services installed prior to R1700 and hence not having a BBU, you will be able to include a BBU on your FVA provide order. If you had an FVA service installed prior to R1700, we will be automatically contacting your end user to arrange an engineering visit to install a BBU. In all the above cases the BBU will include a set of re-chargeable batteries. If your end-user’s BBU gets damaged, you can request a re placement using a modify order. In this case we will dispatch a new unit, but without batteries, in the post. We do not offer replacement batteries.



Functional Summary


ORC2M-12750

FVA/FTTP: Battery Backup Unit & Battery

Fulfilment FVA FTTP Upgrade You can now request a BBU when ordering an FVA service and a replacement via FTTP or FVA.

Yes New XML tags on FVA provide and both FVA and FTTP modify orders. New response code

4.5.4 Design Change Analysis XML There will be a new XML tag for BBU on provide and modify XMLs.

Data BatteryBackupOption - No|Order

Process You can request a BBU on an FVA provide or as a replacement on FTTP and FVA



modify orders.

Behaviour In this release, you must also order Voice Wiring as well if ordering a BBU on a provision.

Response Codes Re-use of existing provide response codes.

Portal You will be able to order a BBU on a new provide, or request a replacement via a modify as soon as R1700 goes live.

4.5.5 Design Details Provision The Battery Backup Unit (BBU) will be automatically included in a new FTTP installation order and therefore the FTTP provide XML will not include the BBU tags. The FTTP order is appointed and therefore the engineer will install the BBU. On an FVA provide you will be able to request a BBU. This is because existing FTTP installations do not have a BBU, but future ones will and there is no plan to retrospectively fit BBUs to FTTP installations without an associated FVA order to drive the visit. For the duration of R1700, if you do include a BBU, you must also order Voice Wiring, even if not required, and include an appointment so that the engineer can install the BBU. This is because we originally thought there would be no installation work required for the BBU and hence did not allow BBU without Voice Wiring to be appointed. This will be corrected in R1800. BBU Replacement Where an end user requires a replacement BBU, you will be able to order via a modify order. You can request this via either an FTTP modify request or an FVA modify request. In both cases we will post the BBU to the end user without batteries, regardless of any other requests in the modify order. The parcel tracker reference will be available via order tracker and the new order tracker dialogue service, but will not be returned via B2B messages. This will not require an engineering visit since it is a simple operation to unhook the existing BBU, replace it with the new unit and move the batteries across. The replacement unit will include a jiffy bag for the return of the faulty BBU, however it is not currently planned to track or chase end users for the faulty return. XML Snippets The Battery Backup XML block will now be included in the ProvisionBEnd section of an FVA Provide and the ModifyBEnd sections of both FVA and FTTP Modify XMLs – <utcc:BatteryBackupSolution> <utcc:BatteryBackupOption>No|Order</utcc:BatteryBackupOption> </utcc:BatteryBackupSolution> It is an optional tag with a default value of No. We will only return it in the OrderPending and OrderRejected XMLs as an acknowledgement and then again in KCI3, along with its status, in the Feature Output section of the XML – <utcc:BatteryBackupSolution> <utcc:BatteryBackupOption>No|Order</utcc:BatteryBackupOption>



<utcc:BatteryBackupStatus>Completed|Cancelled</utcc:BatteryBackupStatus> </utcc:BatteryBackupSolution> Validations If entered, BatteryBackupOption must be set to No or Order. Otherwise your order will be rejected with response code 251. Charging If you successfully request a replacement BBU via a modify order, we will charge you for it. BBU supplied as part of an FTTP or FVA provision order will not be charged.

4.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 251 Invalid value <Value> for field

[BatteryBackupSolution] The order has been rejected as incorrect data has been entered in the named field.

1555 At least one attribute has to be modified before submission

The order has been rejected. Ensure that at least one of the following is modified in the modify order: 1) Care Package 2) ATA Parameter 3) Hazard & Warning Notes 4) Voice Wiring Solution Option 5) BatteryBackupOption 6) RID



4.6 ORC2M-13439 – FVA/FTTP: Handling ONT not reachable due to Power off for the ONT Immediate Release Impacts New response code


4.6.1 Story Details As a CP I want to be advised when there is no power to the End Users ONT on completion of a provide order So that I can advise them to switch on the ONT and begin using the service

4.6.2 Introduction When we check the line following the installation of either an FTTP or FVA subsequent service, we will advise you if there is no power to the End Users ONT. This will enable you to contact the End User and advise them to restore power to the ONT.



Functional Summary


ORC2M-13439

FVA/FTTP: Handling ONT not reachable due to Power off for the ONT

Fulfilment FVA FTTP

Full We will advise you when, on completion of a FVA/FTTP order, there is no power to the ONT.

No New Response code New Process


Data None

Process New process to advise End User of the power status of the ONT.

Response Codes New Response Code: 9414

Behaviour None

Portal None

4.6.5 Design Details If we find the ONT is not switched on when we try to configure it or carry out the final test before completion, we will send you response code 9414 as part of KCI3. Note, we will have tested and proved that everything except the ONT is working satisfactorily, when we send you KCI3 and we will regard the order as complete.



When the End User switches the ONT on, it will automatically pick up the appropriate configuration details and self configure.

4.6.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 9414 The ONT is not powered up. This is a warning message. Openreach has completed the

service activation and our network is testing okay. However, these tests indicate that the Optical Network Terminator (ONT) is not powered up.



4.7 ORC2M-13492 FVA/FTTP: Enhanced Test and Diagnostic capability for FVA product Immediate Release Impacts New Name/Value pairs returned by Service Test DS for FVA. Changes to CP Text for FVA and FTTP Diagnostic Outcome Codes


4.7.1 Story Details As Openreach Engineering solutions I want to have Test & Diagnostics R1700 solution (which are in the Strategic direction & in synergy with overall NGA program)

So that I have the required & feasible T&D capabilities to assess & prove faults in Openreach part of the Access Network for Fibre Voice Access

4.7.2 Introduction There are several elements to this story, all associated with enhancements to the Service Test Dialogue Service for FVA.

• Providing additional ATA status information in an FVA Service Test response • Returning an appropriate Diagnostic Outcome Code if another test is already in progress • Updating the CP Text associated with a number of FVA and FTTP Diagnostic Outcome Codes to

provide greater clarity • Changing the Main Fault Location associated with certain Diagnostic Outcome Codes for FVA and

FTTP



Functional Summary


ORC2M-13492

Enhanced Test and Diagnostic capability for FVA product


FVA FTTP

Full Improvements to Service Test DS for FVA. Clarification of Diagnostic Outcome Codes for FVA and FTTP.

No New Data - Name/Value pairs Changes Diagnostic Outcome Code text


Data New Name/Value pairs in Service Test response:

FeatureName Call_Status FeatureType String FeatureValue In Call | Idle FeatureName Physical_Status FeatureType String FeatureValue On Hook | Off Hook | Fault FeatureName Registration_Status FeatureType String FeatureValue Registered | Not Registered



Changes to Diagnostic Outcome Code text: See table in the Design Details section.

Process None

Behaviour Change to Main Fault Location associated with certain Diagnostic Codes; if the ONT is not powered on, MFL = OK.

Response Codes None

Portal New fields returned in DS results

4.7.5 Design Details

4.7.5.1 New ATA status information for FVA For FVA the Service Test DS will return three new ATA status flags from R1700. These are: Call_Status In Call | Idle Physical_Status On Hook | Off Hook | Fault Registration_Status Registered | Not Registered These flags will be shown in the DS response on Portal and will be returned as Name/Value pairs within the B2B xml response, see example snippet below: <dt:TestResultSummary> … <dt:AdditionalInformation> <dt:ListOfTestResultFeature> … <dt:TestResultFeature> <dt:FeatureName>Sync_Status</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>Up</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Call_Status</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>Idle</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Physical_Status</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>On hook</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Registration_Status</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>Registered</dt:FeatureValue> </dt:TestResultFeature> … </dt:ListOfTestResultFeature> </dt:AdditionalInformation> </dt:TestResultSummary> These new flags will only be returned for FVA when they are available from the test systems, no defaults will be used. They will not be returned for FTTP.



4.7.5.2 Diagnostic Outcome Code if another test is already in progress If a Service Test is performed whilst another test is in progress that is accessing the ATA port then the following Diagnostic Outcome Code will be returned:

GTC_FVA_SERVICE_2005 No Problem found in Openreach. ATA Port is in testing mode. Please retry the test

4.7.5.3 Updating of CP Text for Diagnostic Outcome Codes The CP Text associated with the following FTTP and FVA Diagnostic Outcome Codes have been updated to change the word ‘modem’ to ‘ONT’ to correctly reflect the FTTP and FVA services:

GTC_FTTP_SERVICE_1006 ONT Device's main power and battery is Powered Off. Check that ONT is plugged in and switched on

GTC_FTTP_SERVICE_1011 Ethernet parameters breaching thresholds on Handover Port. Check that ONT is plugged in and switched on

GTC_FTTP_SERVICE_1012 Optical parameters breaching thresholds on Handover Port. Check that ONT is plugged in and switched on

GTC_FTTP_SERVICE_1013 Optical parameters breaching thresholds on GPON UNI Port. Check that ONT is plugged in and switched on

GTC_FTTP_SERVICE_1014 Ethernet parameters breaching thresholds on GPON UNI Port. Check that ONT is plugged in and switched on

GTC_FTTP_SERVICE_1015 Ethernet parameters breaching thresholds on ONT NNI Port. Check that ONT is plugged in and switched on

GTC_FTTP_SERVICE_1016 Optical parameters breaching threshold on GPON UNI Port. Check that ONT is plugged in and switched on

GTC_FTTP_SERVICE_1017 Ethernet parameters breaching thresholds on ONT UNI Port. Check that ONT is plugged in and switched on

GTC_FTTP_SERVICE_1019 ONT is down due to fault in Network Fibre or Splitter. Check that ONT is plugged in and switched on

GTC_FTTP_SERVICE_1005 ONT is down due to Hardware fault or drop cable down. Check that ONT is plugged in and switched on

GTC_FVA_SERVICE_1006 ONT Device's main power and battery is Powered Off. Check that ONT is plugged in and switched on

GTC_FVA_SERVICE_1011 Ethernet parameters breaching thresholds on Handover Port. Check that ONT is plugged in and switched on

GTC_FVA_SERVICE_1012 Optical parameters breaching thresholds on Handover Port. Check that ONT is plugged in and switched on

GTC_FVA_SERVICE_1013 Optical parameters breaching thresholds on GPON UNI Port. Check that ONT is plugged in and switched on

GTC_FVA_SERVICE_1014 Ethernet parameters breaching thresholds on GPON UNI Port. Check that ONT is plugged in and switched on

GTC_FVA_SERVICE_1015 Ethernet parameters breaching thresholds on ONT NNI Port. Check that ONT is plugged in and switched on

GTC_FVA_SERVICE_1016 Optical parameters breaching threshold on GPON UNI Port. Check that ONT is plugged in and switched on

GTC_FVA_SERVICE_1017 Ethernet parameters breaching thresholds on ONT UNI Port. Check that ONT is plugged in and switched on

GTC_FVA_SERVICE_1019 ONT is down due to fault in Network Fibre or Splitter. Check that ONT is plugged in and switched on

GTC_FVA_SERVICE_1005 ONT is down due to Hardware fault or drop cable down. Check that ONT is plugged in and switched on

4.7.5.4 Changes to Main Fault Location associated with Diagnostic Outcome Codes



When a Service Test determines that the ONT is not powered on we return the following Diagnostic Outcome Codes for FTTP and FVA as appropriate:

GTC_FTTP_SERVICE_1006 ONT Device's main power and battery is Powered Off. Check that ONT is plugged in and switched on

GTC_FVA_SERVICE_1006 ONT Device's main power and battery is Powered Off. Check that ONT is plugged in and switched on

The Main Fault Location associated with these was CA (Customer Apparatus). It will now be OK.




4.8 ORC2M-20107 FTTP: (Config Change) Change in the lead time of FTTP Cease Immediate Release Impacts: None

Schema Upgrade Fundamentals: None

4.8.1 Story Details As Openreach I want to change the lead time of FTTP ceases from the existing 3 days to 1day So that I can satisfy the CP asks for shorter lead time on ceases without ONT recovery.

4.8.2 Introduction This story reduces the Standard Lead Time (SLT) for an FTTP cease where the ONT is not being recovered (soft cease) from 3 working days to 1 working day. Note: This is an R1710 story.

4.8.3 Design Summary Change

Ref Title Scope Products Classifi-

cation* Functional Summary


ORC2M-20107

FTTP: (Config Change) Change in the lead time of FTTP Cease

Fulfilment FTTP Full Reduce soft cease SLT to 1 working day

No Behaviour


Data None

Process None

Response Codes

None

Behaviour Soft cease (no ONT removal) SLT for FTTP reduced to 1 working day

Portal None

4.8.5 Design Details As above.




4.9 ORC2M-20655 FTTP Supporting Multiple Head ends - tactical Process solution Immediate Release Impacts New process in case of FTTP capacity issues during fulfilment.


4.9.1 Story Details As a CP I want to know which Layer 2 Switch (L2S) my order will be routed to and be advised of any inflight changes to the routing of the order So that I can allocate it to the correct Cablelink.

4.9.2 Introduction During Plan and Build rollout of the FTTP infrastructure we route all the fibres that we initially configure at a splitter node back to the same Layer 2 Switch. When we approach the initial capacity provided at a splitter node this can mean that the initial routing information (Layer 2 Switch ID – L2SId) advised via the eMLC Dialogue Service may need to be revised. This is because the additional fibres configured at the Splitter node may need to be routed to a different Layer 2 Switch due to capacity being reached on the first switch. In turn, this would mean that the Cablelink ID you have specified in a Provide order would no longer be valid and you will need to provide a new Cablelink ID on the revised Layer 2 Switch. This story provides a tactical solution to promptly advise you if such a situation arises so that fulfilment of your order can progress as quickly as possible. Note: This tactical fix will be deployed in R1713.





ORC2M-20655

FTTP Supporting Multiple Head ends - tactical Process solution

Fulfilment FTTP Full Tactical process to address capacity issues during fulfilment

No New Process Revised response code Explanation and CP Action Required


Data None

Process New tactical process in case of FTTP capacity issues during fulfilment

Response Codes

Revised Explanation and CP Action Required for 9255 within the Response Code Spreadsheet

Behaviour None



Portal None

4.9.5 Design Details If the situation described above should arise we will reject your order with existing response code 9255 (The Address entered is not currently served by a suitable fibre network.). The Explanation and CP Action Required for 9255 has been updated within the latest Response Code Spreadsheet. Following receipt of 9255 you should wait for 24 hours and then re-check eMLC to see if the Layer 2 Switch ID (L2SId) has changed. <OHP> <DistrictCode>CSS OHP Exchange District Code</DistrictCode> <OHPExchangeCode>OHP Exchange ID</OHPExchangeCode> <OHPExchangeName>OHP Exchange Name</OHPExchangeName> <L2SId>BAAAAA</L2SId> </OHP> If the Layer 2 Switch has changed you should resubmit your order with a Cablelink ID on the new switch. If you resubmit the same order without changing the Cablelink ID, or otherwise provide a Cablelink ID that is not on the correct Layer 2 Switch, we will reject the order with existing response code 9261 (The order has been rejected. The Handover Port Service Id quoted is not on the Openreach Handover Point equipment serving the end users PCP or Fibre DP.). If you do not currently own a Cablelink on the new switch a new Cablelink may be requested.

4.9.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 CP Action Required 9255 The Address entered

is not currently served by a suitable fibre network.

The address entered or otherwise indicated is not currently served by a suitable fibre network or there is a capacity issue within the network. FTTP can only be supplied in areas where a fibre-optic network has already been deployed. If eMLC indicated FTTP is available at this address, then there is a capacity issue within the network.

None. If your order was rejected because of a capacity issue, then please re-check the eMLC dialogue service in 24 hours to see if a new layer 2 switch id (L2SId) is shown. If so, you can resubmit your order specifying your HandoverPortServiceId connected to this new L2SId.

9261 The order has been rejected. The Handover Port Service Id quoted is not on the Openreach Handover Point equipment serving the end users PCP or Fibre DP.

The order has been rejected. The CP does not have a Handover Port on the Layer 2 Switch (L2S) or Optical Line Terminator (OLT) serving the Primary Connection Point (PCP).

Check the Handover Port service Id has been correctly entered. If necessary, request a Handover Port on the serving L2S by submitting a Customer Requirement Form (CRF). Re-submit the provision order when the Handover Port has been confirmed on the correct L2S.



5 R1700 – FTTC Enhancements

5.1 ORC2M-8374 FTTC: PCP-only provide Immediate Release Impacts None

Schema Upgrade Fundamentals You will be able to order PCP only provides for FTTC.

5.1.1 Story Details As an Openreach Product Manager I want: to offer Customer CPs the option to order a PCP-only provide So that I can give my CP customer flexibility on the installation of the service at the End User’s premises.

5.1.2 Introduction This change introduces the option for you to order a PCP only installation when ordering FTTC, which will allow you and your customer the flexibility to choose how to install their VDSL2 modem.



Functional Summary


ORC2M-8374

FTTC: PCP-only provide Appointing Dialogue Service Fulfilment

FTTC Upgrade New PCP only option available to order

Yes New XML New Data Values New process Response Code changes

5.1.4 Design Changes XML <utcc:PCPOnly>

Data <utcc:PCPOnly> N | Y

Process New process to provide PCP only FTTC installation.

You will need to arrange with your customer how to install the VDSL2 modem when ordering PCP only FTTC installation. PLEASE NOTE: The customer installation may only be completed by a CP engineer accredited by Openreach, and must use the existing Openreach modem and service specific front plate. End User Self installation is not permitted at this time.

Response Codes

New response code for FTTC – 9030 Reused response codes – 9256 and 9060

Behaviour None

Portal New PCP Only value available for selection in both Appointing Dialogue Service and FTTC Provide.



5.1.5 Design Details When placing an FTTC order you will now be able to order a PCP Only installation using the new optional XML tag “PCPOnly” which has data values of Y or N. It will be defaulted to N if any other values are entered. <gea:ProvisionBEnd> <utcc:PCPOnly>Y</utcc:PCPOnly> ……. This tag should be used in both the Appointing Dialogue Service and Provide journeys if a PCP only provision is required. A standard AM/PM appointment should be selected for a PCP only provide order; if you select a 2 hour appointment slot the order will be rejected with response code 9260 – “The %1 part of this order is incompatible with the type of appointment that has been booked”. PCP Only orders are obviously incompatible with Managed Install Modules and Home Wiring Solution requirements, and if either of those are included in a PCP Only order it will be rejected with response code 9256 – “The combination of fields is not valid for the product selected”. PCP Only is not available for FTTC transfer orders and therefore transfer orders containing the PCPOnly=Y will be rejected with response code 9030 – “PCP only provide cannot be requested on Transfer scenario”.

5.1.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 9030 %1 can not be requested on %2

The order has been rejected.PCP only Provide cannot be requested for transfer scenario. %1 is "PCP only Provide" %2 is "Transfer"scenario.

9256 The combination of fields is not valid for the product selected.

The combination of fields selected in the order is invalid. For CPs on EMP releases lower than R1600, EK (Extension Kit) and/or List of Modules for MI (Managed Installation) are only available with GEA FTTC. From R1600, List of Modules is replaced by Managed Install Quantity and EK is replaced by Home Wiring Solution Option. Managed Install Quantity and Home Wiring Solution Option cannot be ordered with an FTTC PCP only provide (available from R1700).

9260 The %1 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. %1 can be: Module Quantity Extension Kit, Home Wiring Solution Option, the name of the Managed Install Module, Managed Install Quantity a full provide or PCP only provide.



5.2 ORC2M-11913 FTTC: Reduce the minimum speed for GEA from 5Mbit/s to 2Mbit/s Immediate Release Impacts None


5.2.1 Story Details As Openreach Product Line I want to extend the GEA-FTTC product so that the order threshold and FTR are changed from 5 Mbit/s down to 2 Mbit/s. So that I can extend the reach of the FTTC product coverage to more customers. (FTR – Fault Threshold Rate)

5.2.2 Introduction This story reduces the minimum downstream bandwidth that may be supported by an FTTC service from 5 Mbit/s to 2 Mbit/s. FTTC performance is dependent on the characteristics of the line from the DSLAM to the EU. In a very small percentage of cases this will result in predictions being below 5 Mbit/s. FTTC was initially specified as being above 15 Mbit/s; the increasing range of Sub15 Mbit/s options has been as a result of further testing coupled with operational experience.



Functional Summary


ORC2M-11913

FTTC: Reduce the minimum speed for GEA from 5 Mbit/s to 2 Mbit/s

Fulfilment FTTC Full Reduce accepted minimum predicted downspeed rate from 5 Mbit/s to 2 Mbit/s

No Provides greater FTTC coverage


Data None

Process None

Behaviour Minimum supported downstream bandwidth for FTTC becomes 2 Mbit/s

Response Codes None

Portal None

5.2.5 Design Details This story allows FTTC orders to be accepted on lines where the minimum predicted downstream rate is at least 2 Mbit/s, rather than the previous 5 Mbit/s limit.



The FTTC availability flag in eMLC will be based on this new value; i.e. FTTC availability will be ‘Y’ if the minimum predicted downstream rate is 2 Mbit/s or greater. If it is less than 2 Mbit/s the flag will be ‘S’ indicating a speed issue. If you raise an order for FTTC on such a line the order will be rejected and we will return existing response code 9185 (The downstream bandwidth requested cannot be provided by Openreach on this line) as per BAU. The Fault Threshold Rate (FTR) for such lines, categorised as Sub15 Mbit/s circuits, will also be reduced to 2 Mbit/s. There is no change to the FTR for non-Sub15 Mbit/s circuits.

5.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 9185 The downstream bandwidth

requested cannot be provided by Openreach on this line

The order has been rejected. The bandwidth requested in the order cannot be provided by Openreach. For FTTC the downstream bandwidth requested is below the minimum allowed by Openreach



5.3 ORC2M-14742 RRT Improvements for FTTC Immediate Release Impacts Change to Main Fault Location associated with service test clear code


5.3.1 Story Details As Openreach Service and Operations I want to improve the operation of the existing RRT (Reactive Repair Test) functionality for FTTC So that the accuracy of the diagnosis of faulty circuits is improved and an improved customer service can be provided.

5.3.2 Introduction We are introducing changes to the algorithm associated with the Reactive Repair Test (RRT) and the historic trend analysis of DSL line functions. This will improve the correct identification of faulty circuits. As a result, the Main Fault Location (MFL) for RRT’s Mean Time Between Errors (MTBE) related failures will be converted from DT (Diagnostic Test required) to CA (Customer Apparatus).



Functional Summary


ORC2M-14742

RRT Improvements for FTTC

Dialogue Services

FTTC Full Improvement to RRT diagnostic capability

No Change in MFL associated with Clear Code


Data None

Process None

Behaviour Change to MFL for service test clear code

Response Codes None

Portal None

5.3.5 Design Details If a Mean Time Between Errors (MTBE) fault is detected on an FTTC circuit following a service test the following existing Diagnostic Code will continue to be sent: Diagnostic code Response to CP Text Scenario

GTC_FTTC_SERVICE_1607 Circuit performance appears unstable due to mean time between errors issues. Continue submitting trouble report

Service Test DS



However, the associated MFL will become CA (Customer Apparatus) rather than DT (Diagnostic Test required).




5.4 ORC2M-15098 FTTC: Inclusion of VDSL errored seconds in GEA service test Immediate Release Impacts None


5.4.1 Story Details As a CP I want the ability to look at the current results of errored seconds as part of the GEA service test So that I can relate any TV quality issues to potential problems with the VDSL line

5.4.2 Introduction This story enables VDSL error second details to be provided to the CP via the Service Test 2 Dialogue Service for FTTC. The VDSL error second parameter details are:

• CODE violation: Count of uncorrected frames (CRC-8). • Errored seconds: Count of 1-second intervals with one or more CRC/LOS (Loss of Signal)/SEF(

Severely Errored Frames)/LPR(Loss of Power) defects. • Severely Errored Seconds (SES) : Count of 1-second intervals with 18 or more CRC errors • Unavailable seconds: Count of 1-second intervals for which the VDSL line is unavailable (onset of 10

contiguous SES) CRC (Cyclic Redundancy Check) – a form of error correction.



Functional Summary


ORC2M-15098

FTTC: Inclusion of VDSL errored seconds in GEA service test

Dialogue Services

FTTC Full Provides VDSL error second details via the Service Test 2 Dialogue Service



Data New information (Name/Value pairs) returned in response to a GEA FTTC Service Test –

see Design Details.

Process New capability for displaying VDSL error seconds

Behaviour None

Response Codes None

Portal The VDSL error second details will be displayed on the service test results page



5.4.5 Design Details This capability is only for FTTC and is available via the Service Test 2 Dialogue service via the Portal or B2B interface. The following parameters must be entered to make the request:

GEA Service ID Test Category – Request Diagnostics or Request Diagnostics with OAM Service type - GEA FTTC Service Test

12 new values will be provided in the response: Last15MinBin_StartTimeStamp Last15MinBin_ingressCodingViolations Last15MinBin_egressCodingViolations Last15MinBin_unavailableSeconds Last15MinBin_severelyErroredSeconds Last15MinBin_erroredSeconds Current15MinBin_StartTimeStamp Current15MinBin_ingressCodingViolations Current15MinBin_egressCodingViolations Current15MinBin_unavailableSeconds Current15MinBin_severelyErroredSeconds Current15MinBin_erroredSeconds

xml snippet: <dt:TestResultFeature> <dt:FeatureName>Last15MinBin_StartTimeStamp</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>2011-04-12T12:01:04.349+01:00</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Current15MinBin_StartTimeStamp</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>2011-04-12T12:16:04.349+01:00</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Last15MinBin_ingressCodingViolations</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>0</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Last15MinBin_egressCodingViolations</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>0</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Last15MinBin_unavailableSeconds</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>0</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Last15MinBin_severelyErroredSeconds</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>0</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Last15MinBin_erroredSeconds</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>0</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Current15MinBin_ingressCodingViolations</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType>



<dt:FeatureValue>0</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Current15MinBin_egressCodingViolations</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>0</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Current15MinBin_unavailableSeconds</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>0</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Current15MinBin_severelyErroredSeconds</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>0</dt:FeatureValue> </dt:TestResultFeature> <dt:TestResultFeature> <dt:FeatureName>Current15MinBin_erroredSeconds</dt:FeatureName> <dt:FeatureType>String</dt:FeatureType> <dt:FeatureValue>0</dt:FeatureValue> </dt:TestResultFeature>




5.5 ORC2M-19036 FTTC: Align current Sub 15m downstream speed estimates to more

optimistic algorithm used on 15m+ lines Immediate Release Impacts: None

Schema Upgrade Fundamentals: None

5.5.1 Story Details As a CP I want Openreach to adopt a more optimistic approach to predicting Sub 15m downstream speed estimates So that the downstream values in eMLC are aligned for +15m and Sub 15m speed estimates.

5.5.2 Introduction From R1710 the algorithm used to predict the downstream speeds on Sub 15 Mbit/s FTTC lines will be aligned to that currently in use on lines above 15 Mbit/s. This will result in more optimistic speeds being displayed within eMLC results and will remove discontinuities within rate/reach predictions. Note: This is an R1710 story.





ORC2M-19036

FTTC: Align current Sub 15m downstream speed estimates to more optimistic algorithm used on 15m+ lines

Dialogue Services

FTTC Full Improvement to eMLC speed predictions for Sub 15 Mbit/s lines

No Behaviour


Data None

Process None

Response Codes

None

Behaviour More optimistic speeds displayed within eMLC results for sub 15 Mbit/s lines

Portal None

5.5.5 Design Details As above.




5.6 OR-3844 ORCE-16666 CP has visibility of cable breakdown faults Immediate Release Impacts None


5.6.1 Story Details

As a CP I want to be able to see a summary that shows me what incidents we currently have ongoing and their status So that I can inform my End Users about incidents and keep them updated on progress.

5.6.2 Introduction This story provides information on Fault Tracker about cable breakdown faults allowing information on common faults to be shared across affected services. You will be able to access information relating to cable breakdowns affecting your customers which will be updated on an hourly basis.





OR-3844 ORCE-16666

CP has visibility of cable breakdown faults

Assurance FTTC Full Provides information on Fault Tracker about cable breakdown incidents

No None


Data None

Process None

Response Codes

None

Behaviour None

Portal Cable breakdown information provided on Fault Tracker

5.6.5 Design Details Fault Tracker will display two new columns ERT2 (Estimated Response Time 2) and Cable Breakdown Information. The Cable Breakdown Information will be available as a click through on the Fault Tracker. Within the Cable Breakdown Information column the text "Cable Breakdown Information" will be hyperlinked. When clicked a pop-up window will appear displaying all the notes in a tabular form. The table will contain three columns:

• Notes Date



• Notes Type • Notes Text

Notes will be listed in descending chronological order. (Latest update displayed on the top).


Draft 1.0 Issued by Openreach © British Telecommunications plc 2010 Page 65 of 75

6 Enhancement Summary

This section summarises the potential impact of the functional enhancements. 6.1 Dialogue Services and Reports Change Ref


Functional Summary XML CP Impact Summary

Immediate Release Impact

Schema Upgrade Fundamentals

ORC2M-4060



FTTP FVA

Full Information returned about existing fault appointments.

No New Data value

You will receive information about existing faults on the ONT when you run a service test. Faults will be linked and you will receive new response codes

None

ORC2M-8374

FTTC: PCP-only provide

Appointing Dialogue Service

FTTC Upgrade New PCP only option available to order


None You will be able to order PCP only provides for FTTC.

ORC2M-12510

FTTP MDU/MOU L2C: Display MDU status on eMLC & Accept orders at an enabled MDU


FTTP Partial Provides MDU details in an eMLC response along with associated FTTP availability

Yes New XML tags for MDU details from R1700. Change to FTTP Availability logic from R1500.

Changes to FTTP Availability Logic from schema version R1500

MDU details returned in new tags



Change Ref





ORC2M-12748

FTTC/FTTP: Service test update for active Multicast IGMP joins

Dialogue Services

FTTC FTTP

Full New capability within the Service Test 2 Dialogue Service to view active Multicast information


None None

ORC2M-13492

Enhanced Test and Diagnostic capability for FVA product


FVA FTTP

Full Improvements to Service Test DS for FVA. Clarification of Diagnostic Outcome Codes for FVA and FTTP.

No New Data - Name/Value pairs Changes Diagnostic Outcome Code text

New Name/Value pairs returned by Service Test DS for FVA. Changes to CP Text for FVA and FTTP Diagnostic Outcome Codes

None

ORC2M-14271

FTTC/FTTP: eMLC enhancements (PCP based readiness logic change for FTTP and FTTC)


FTTP FTTC

Full Enhancements to eMLC to return information about future plans for fibre rollout.

None New data values

New data values will be returned

None

ORC2M-14742

RRT Improvements for FTTC

Dialogue Services

FTTC Full Improvement to RRT diagnostic capability

No Change in MFL associated with Clear Code

Change to Main Fault Location associated with service test clear code

None



Change Ref





ORC2M-14805

FTTC/FTTP/FVA: Consumption of order and fault tracker records in Dialogue Services

Sentry Dialogue Services

FTTC FTTP FVA

Upgrade New Dialogue Service to return Order and Fault tracker records.

Yes New Sentry XML interface New Response Codes

None None

ORC2M-15098

FTTC: Inclusion of VDSL errored seconds in GEA service test

Dialogue Services

FTTC Full Provides VDSL error second details via the Service Test 2 Dialogue Service


None None

ORC2M-19036

FTTC: Align current Sub 15m downstream speed estimates to more optimistic algorithm used on 15m+ lines

Dialogue Services

FTTC Full Improvement to eMLC speed predictions for Sub 15 Mbit/s lines

No Behaviour None None

OR-4663

Address Matching Dialog Service

Dialogue Service

LLU WLR3 PSTN ISDN30, ISDN2E FTTC FTTP Ethernet SBS

Upgrade Introduction of new technology marker for address matching.

Yes New XML New Data New Process

None Address Matching Dialogue Service changes



6.2 Fulfilment Change Ref





ORC2M-8374

FTTC: PCP-only provide

Fulfilment FTTC Upgrade New PCP only option available to order


None You will be able to order PCP only provides for FTTC.

ORC2M-10241

Service Test Failure during provision (where MFL comes as "CA")

Fulfilment FTTP FVA

Partial

Delay response code sent when service test on provision fails with MFL=CA

No New response code from R1700. Re-use of existing response code for R1600.

None New response code for CPs upgrading to R1700

ORC2M-11913

FTTC: Reduce the minimum speed for GEA from 5 Mbit/s to 2 Mbit/s

Fulfilment FTTC Full Reduce accepted minimum predicted downspeed rate from 5 Mbit/s to 2 Mbit/s

No Provides greater FTTC coverage

None None

ORC2M-12750

FVA/FTTP: Battery Backup Unit & Battery

Fulfilment FVA FTTP

Upgrade You can now request a BBU when ordering an FVA service and a replacement via FTTP or FVA.

Yes New XML tags on FVA provide and both FVA and FTTP modify orders. New response code

None

None



Change Ref





ORC2M-13424

FVA/FTTP: Modify RID functionality

Fulfilment FTTP FVA

Upgrade You can modify the RID on existing FVA or FTTP services.

Yes New XML tag on modify orders and responses for RID

None None

ORC2M-13439

FVA/FTTP: Handling ONT not reachable due to Power off for the ONT

Fulfilment FVA FTTP

Full We will advise you when, on completion of a FVA/FTTP order, there is no power to the ONT.

No New Response code New Process

New response code

None

ORC2M-14341

FFTP/FTTC Bulk Install time window

Fulfilment FTTP FTTC

Upgrade Confirmation sent in KCI2 and KCI3 that an order falls within a bulk install window

Yes New XML in KCI2 and KCI3 New Data New process

You may benefit from inclusion in bulk install windows, but will not receive any explicit KCI to tell you so.

You will receive new XML in KCI 2 and KCI3 when an order falls within a bulk install window.

ORC2M-20107

FTTP: (Config Change) Change in the lead time of FTTP Cease

Fulfilment FTTP Full Reduce soft cease SLT to 1 working day

No Behaviour None None



Change Ref





OR-4663

Address Matching Dialog Service

Fulfilment LLU WLR3 PSTN ISDN30, ISDN2E FTTC

Full Use of correct Gold Address Reference

Yes New Process New Response Code

When placing an order for copper-based products if you use the new version of the Address Matching Dialogue Service your order will be rejected if a Copper Gold Address is not selected. A Temporary Address Reference will then need to be created. When placing an order for copper-based products if you don’t use the new version of the Address Matching Dialogue Service then the Immediate Release Impact is none.

None



Change Ref





ORC2M-20655

FTTP Supporting Multiple Head ends - tactical Process solution

Fulfilment FTTP Full Tactical process to address capacity issues during fulfilment

No New Process Revised response code Explanation and CP Action Required

New process in case of FTTP capacity issues during fulfilment.

None



6.3 Assurance Change Ref

Title Scope Products

Classifi-cation*




ORC2M-4060


Assurance

FTTP FVA

Full Faults reported by different CPs against the same ONT will be linked together.

No New Response Codes (FVA) New process

You will receive information about existing faults on the ONT when you run a service test. Faults will be linked and you will receive new response codes

None

ORC2M-10738

CVLAN Switch for SMC to Support Central Test Head (Golden End User Only)

Assurance FTTC FTTP

Full Allows additional diagnostic testing by applying a ‘Golden EU’ via the CTH

No Intrusive test on EU service

None None

ORC2M-12511

FTTP/FVA MDU/MOU T2R: Accept and Resolve faults in an MDU (Multi-Tenancy Dwelling Unit) context

Assurance FTTP FVA

Full New process associated with FTTP faults affecting an MDU

No New Process Response code changes

Trimming of Response to CP text for response code 6511

None



Change Ref

Title Scope Products

Classifi-cation*




ORC2M-15698

FTTC/FTTP: Improvements to fault closure processes for SFA Remote Assure

Assurance FTTC FTTP

Full Change to RA process to close Openreach Domain faults when we are able to resolve remotely and to include Clear Codes with fault closures

No Change in response codes used to clear and close an Openreach Domain fault when we are able to resolve remotely

If an Openreach Domain fault is found and fixed during an SFA RA you will receive a simpler new fault cleared and close message

None

OR-3844 ORCE-16666

CP has visibility of cable breakdown faults

Assurance FTTC Full Provides information on Fault Tracker about cable breakdown incidents

No None None None



7 Appendix A – Glossary of Terms

Acronym Meaning Further Information ATA Analogue Terminal Adapter B2B Business to Business BAU Business As Usual BBU Battery Backup Unit CA Customer Apparatus CCD Customer Committed Date Date which Openreach commits to complete an

order. This value is returned in KCI2 CP Communications Provider CRC Cyclic Redundancy Check CRD Customer Required Date Date the CP has requested for the service to be

supplied as part of an order. CTH Central Test Head DN Directory Number DO Distribution Optics DRA Damage Report Apparatus DRO Damage Report Overhead DRW Damage Report Wiring DSL Digital Subsciber Line DSL Dialogue Service DT Diagnostic Test EU End User FTR Fault Threshold Rate FTTC Fibre to the Cabinet FTTP Fibre to the Premises FVA Fibre Voice Access GEA Generic Ethernet Access IGMP Internet Group Management

Protocol

IP Internet Protocol KCI Keep Customer Informed An OrderStatusUpdate message. For example,

Acknowledged, Matched, Committed, Completed, Amend, Rejected, Cancelled, Delay Notification

L2C Lead to Cash L2S Layer 2 Switch MDU Multiple Dwelling Unit

(Residential)

MFL Main Fault Location MOU Multiple Occupancy Unit

(Business)

MTBE Mean Time Between Errors NAD Network Address NGA Next Generation Access OLT Optical Line Terminal ONT Optical Network Terminator OTD Order Target Date PCP Primary Cross-connect Point Cabinet PONR Point of No Return RA Remote Assure RFS Ready For Service RID Reseller Identification RRT Reactive Repair Test



SFA Superfast Fibre Access SMC Service Management Centre T&D Test and Diagnostics T2R Trouble to Resolve TMA Traffic Management Authority TR Trouble Report VA Visit Assure XML Extensible Markup Language

Date post:	07-Apr-2018
Category:	Documents
Upload:	lytram
View:	232 times
Download:	2 times

EMP Functional Changes in R1700 for FTTP and FTTC CPs ... · EMP Functional Changes in Release 1700...

Documents