Document change - Connecting you to your fibre broadband ...



left-814250003600452528570Scott Howitt00Scott Howitt360045273203410th August 2020Issue 1.00010th August 2020Issue 1.0right5529915This document contains information intended to support Communications Providers (CPs) with their development activities (solely in respect of their purchase of MPF, S/MOF and GEA-FTTC) and is provided for information/discussion purposes only. The information supplied should not be used for any other purpose. Using the data for another purpose could constitute a breach of General Condition A1.3. Whilst Openreach makes every effort to ensure that the information contained in this document is accurate, Openreach does not represent that it is complete. All information may be subject to change and Openreach recommends that CPs check with Openreach for the latest available information. Any development or work carried out by the CPs based on this document is entirely at the CPs’ own risk.?The contents of this document cannot be copied or reproduced in whole or in part without the written consent of Openreach.?020000This document contains information intended to support Communications Providers (CPs) with their development activities (solely in respect of their purchase of MPF, S/MOF and GEA-FTTC) and is provided for information/discussion purposes only. The information supplied should not be used for any other purpose. Using the data for another purpose could constitute a breach of General Condition A1.3. Whilst Openreach makes every effort to ensure that the information contained in this document is accurate, Openreach does not represent that it is complete. All information may be subject to change and Openreach recommends that CPs check with Openreach for the latest available information. Any development or work carried out by the CPs based on this document is entirely at the CPs’ own risk.?The contents of this document cannot be copied or reproduced in whole or in part without the written consent of Openreach.?left2251494Issue 2.000Issue 2.03600451930400Service Layer Data Guidance00Service Layer Data GuidanceContents TOC \o "1-3" \h \z \u 1.0Document change log PAGEREF _Toc45092046 \h 32.0Executive Summary PAGEREF _Toc45092047 \h 43.0Introduction PAGEREF _Toc45092048 \h 44.0Service Layer Data - Overview PAGEREF _Toc45092049 \h 5Broadband Supply Chain PAGEREF _Toc45092050 \h 55.0Interpreting Service Layer Data PAGEREF _Toc45092051 \h 66.0Engineer usage of Service Layer Data PAGEREF _Toc45092052 \h 77.0Terms of engagement PAGEREF _Toc45092053 \h 78.0Electrical standards PAGEREF _Toc45092054 \h 79.0Service Layer Data – Speed PAGEREF _Toc45092055 \h 8ADSL PAGEREF _Toc45092056 \h 8GEA-FTTC VDSL PAGEREF _Toc45092057 \h 810.0Service Layer Data – Stability PAGEREF _Toc45092058 \h 8ADSL PAGEREF _Toc45092059 \h 8GEA-FTTC VDSL PAGEREF _Toc45092060 \h 9Comparing stability measurements - DLM Indicative Line Quality (ILQ) and SLD BRAG Insights PAGEREF _Toc45092061 \h 911.0Service Layer Data - Lag PAGEREF _Toc45092062 \h 9ADSL PAGEREF _Toc45092063 \h 9GEA-FTTC VDSL PAGEREF _Toc45092064 \h 9Indicative SLD share timescales PAGEREF _Toc45092065 \h 1012.0SLD insights and interventions PAGEREF _Toc45092066 \h 1113.0Broadband service is determined by a multitude of factors PAGEREF _Toc45092067 \h 1214.0Brandenburg codes PAGEREF _Toc45092068 \h 1315.0Establishing a CP on the SLD sharing process PAGEREF _Toc45092069 \h 1416.0Reporting when things aren’t working PAGEREF _Toc45092070 \h 1417.0Service Layer Data Share File Format PAGEREF _Toc45092071 \h 1518.0Service Symptoms Excluded PAGEREF _Toc45092072 \h 15Document change logVersionAuthorDate DescriptionIssue 1.1Gareth Wilmot05/04/19Document issued. Issue 1.2Scott Howitt18/05/20Document transferred to new template, and all sections updated with internal feedback. Issue 1.3Scott Howitt21/07/20Document updated with industry feedback for publication. Issue 2.0Scott Howitt10/08/20Document updated to reflect changes to the algorithm to better manage line interventions. Executive SummaryThe purpose of this document is to give interested parties, internal and external, an understanding of what Service Layer Data (SLD) is, how it relates to broadband, and how it can be used to provide the best end customer experience. The document also contains information on how a CP should share and receive SLD, and how a CP should become established in this process. IntroductionBroadband is the key reason why many end customers now have an Openreach service via a CP. Understanding the end customer experience of their broadband service requires collaborative working between Openreach, CPs and the end customer. To achieve this, Openreach and CPs have established an industrialised method of sharing SLD.The key principles of sharing SLD are:?Red doesn’t mean fault – a line being classified as either ‘Red’ or ‘Amber’, or ‘Very Bad’ or ‘Bad’ by the SLD, is different from a fault being identified by the GEA Remote Service Test or Copper Line Test. Instead it indicates that if the end customer is reporting an issue with their service, the service is not performing as well as similar lines, and it could benefit from an engineering visit. ?Collaborative working – as an industry we recognize that providing the best broadband end customer experience requires collaboration between Openreach and CPs, and that no single CP or Openreach can do it on its own. ?Reactive repair – SLD insights have been designed to help better qualify an end customer reported issue.SLD creates a shared insight into the end customer broadband service experience, and so enables CPs and Openreach to:?More accurately set end customers’ expectations of their service experience. ?Validate, with greater accuracy, an end customer’s perception that their service is performing poorly. ?Provide CPs with tools to more effectively identify the best route to resolve the end customer issue.?Provide Openreach engineers additional tools to identify whether a broadband impairment exists.?Support CPs in identifying when the best option for the end customer is to change the product they order, i.e. ADSL to GEA-FTTC VDSL. The Service Layer Data share does not change any part of the Openreach product description, the engineering tasks, or success criteria for these products and processes, e.g. achieving a Pair Quality Test (PQT) pass. What SLD seeks to do is improve both CPs’ and engineers' ability to define and resolve end customer issues. Service Layer Data - OverviewSLD is key to providing CPs and Openreach with a single view of an end customer’s broadband service performance.Broadband Supply ChainAs illustrated above, broadband service performance can be affected by any of the elements listed. Service Layer Data insights can help to understand the quality of the end customer’s service experience, and support in isolating impairments that when removed, could improve the broadband service performance. The SLD share is facilitated over the SDEDS file transfer protocol (FTP). CPs which share their ADSL SLD with Openreach provide a daily feed of Digital Subscriber Line (DSL) service layer data collected from CP hubs or CP ADSL Digital Subscriber Line Access Multiplexers (DSLAMs). For GEA-FTTC VDSL, Openreach collects DSLAM data to provide comparable insights. Openreach stores this data, joins it with network inventory data, and builds a 7 day rolling window performance picture to create the SLD insights for speed and stability (and additional diagnostics for GEA-FTTC VDSL). The SLD insight for every LLU or GEA-FTTC VDSL line with data is then uploaded to SDEDS for CPs to access daily. The overall latency on processing the data is c.36 hours, further documented in section 10. For the SLD insights to effectively represent the end customer’s line performance post-repair, CPs should wait for c.7 days to enable Dynamic Line Management (DLM) to stabilise the service. During the DLM stabilisation period speed and stability may vary. On ADSL CPs own the DLM processes and on GEA-FTTC VDSL it’s Openreach. A summary of DLM processes on GEA-FTTC VDSL can be found in section 3.8.5 in the GEA-FTTC VDSL product description here.The SLD output takes the form of:Blue/Green/Pink/Amber/Red (BRAG) classifications for stability.Excellent/Very Good/Good/Bad/Very Bad classifications for speed.Downstream line rate (sync speed).For GEA-FTTC VDSL it also identifies the presence of specific impairment types which maybe affecting the service i.e. High Resistance, Bridge Taps etc.The exchange ID, PCP ID, DP ID and line length are also provided to help CPs compare the performance of their similar services at the line’s location. The file share format is defined in Section 15.SLD is good at identifying if an end customer’s service would benefit from an engineering visit because it provides an end to end view of an end customer’s service. What it does not do is indicate the source of an impairment, which could be within the home, CP or Openreach network. SLD does not seek to replace the current SINs (349 and 498), by which the Openreach LLU and GEA portfolios are currently measured, instead it provides guidance to CPs on how to manage the difficult end customer’s issues which are hard to resolve, in particular intermittent issues. To get the most from SLD, CPs need to integrate it into their fault review journey alongside end customer discussions, CPE (router) diagnostics, CP network diagnostics and the current line/service test. Interpreting Service Layer Data To get the most benefit from SLD CPs need to:Consume the raw indicator data on a daily basis and store it.Use it alongside the Openreach best practice guide for Raising and managing a fault, including using the appropriate Openreach remote test service.Set up their systems and applications to combine the SLD with:Raised end customer issue detailsCP router diagnosticsCP network diagnostics Interpret the data and present it back to CP service advisors for use during an end customer issue qualification. Engineer usage of Service Layer Data Openreach has invested heavily to give our engineers access to SLD insights across ADSL and GEA-FTTC VDSL. They can access a number of different tools which bring to life the end customer’s broadband experience over an extended (60 day) time period. The engineers receive detailed training on how to use these tools as part of the end customer’s issue resolution journey. As part of the Garden of Eden initiative, this training has been further enhanced, and enables the engineer to more effectively resolve intermittent and complex end customer’s issues. As part of this, the engineer can access graphs showing the end customer experience.Example graphs are:Graph of daily downstream line rate and BRAG colour codingGraph of daily instability index and BRAG colour codingGraph of daily initialisations countTerms of engagementThe Service Layer Data share does not change any part of the Openreach product description, the engineering tasks, or success criteria for these products and processes, e.g. achieving a Pair Quality Test (PQT) pass. What SLD seeks to do is improve both CPs’ and engineers' ability to define and resolve end customer issues. The terms of engagement CPs are asked to follow when using SLD are the same as the principles defined in Section 3, and copied below: Red doesn’t mean fault – a line being classified as either ‘Red’ or ‘Amber’, or ‘Very Bad’ or ‘Bad’, by the SLD is different from a fault being identified by the GEA Remote Service Test or Copper Line Test. Instead it indicates that if the end customer is reporting an issue with their service, the service is not performing as well as similar lines, and it could benefit from an engineering visit. ?Collaborative working – as an industry we recognize that providing the best broadband end customer experience requires collaboration between Openreach and CPs, and that no single CP or Openreach can do it on its own. ?Reactive repair – SLD insights have been designed to help better qualify an end customer reported issue.Electrical standardsAt this time Openreach provides LLU based on the standard SIN349 and GEA-FTTC VDSL services using SIN498. The creation of SLD insights and the development of the in-life processes for their production, have not changed this principle at this time. The full details of these standards can be found by clicking on the following hyperlinks:LLU – SIN349GEA-FTTC VDSL – SIN498 Service Layer Data – SpeedADSLThe speed of an ADSL line is classified using the Excellent (Blue), Very Good (Green), Good (Pink), Bad (Amber) and Very Bad (Red) designation. The levels are built using a ‘propensity for speed uplift’ criterion, meaning there is a very high chance that an engineering visit will uplift the speed of a Very Bad line, but very little chance of uplifting the speed of an Excellent line.The Service Layer Data parameters used to create the classification are:Downstream Line rateLine lengthNetwork Type (21CN/20CN) GEA-FTTC VDSL The speed of a GEA-FTTC VDSL line is classified using the Excellent (Blue), Very Good (Green), Good (Pink), Bad (Amber) and Very Bad (Red) designation. The levels are built using a ‘propensity for speed uplift’ criterion, meaning there is a very high chance that an engineering visit will uplift the speed of a Very Bad line, but very little chance of uplifting the speed of an Excellent line.The Service Layer Data parameters used to create the classification are:Maximum Attainable Downstream Line RateDownstream Line rateD-side line lossProduct (80 Mbps, 55 Mbps, 40 Mbps)Service Layer Data – Stability ADSL The stability of an ADSL line is classified using the Blue/Green/Pink/Amber/Red (BRAG) designation, with Blue being Very Stable through to Red being Very Unstable. The classification is based on the analysis of the level of variation of key Service Layer Data parameters over the last 7 days, when combined with fault history and propensity to repeat.The Service Layer Data parameters used to create the classification are:Maximum Attainable Downstream Line RateUpstream Line attenuationDownstream Noise MarginNumber of retrainsGEA-FTTC VDSLThe stability of a GEA-FTTC VDSL line is classified using the Blue/Green/Pink/Amber/Red (BRAG) designation, with Blue being Very Stable through to Red being Very Unstable. The classification is based on the propensity of a line to fault and repeat with an end customer reference to service stability when raising a fault.The Service Layer Data parameters used to create the classification are:Maximum Attainable Downstream Line RateDownstream Line attenuationDownstream Noise MarginNumber of retrains Comparing stability measurements - DLM Indicative Line Quality (ILQ) and SLD BRAG InsightsThe DLM ILQ assessment of stability is a 24 hour measure of a service’s performance, compared to the SLD Stability BRAG’s 7 day measure. The DLM ILQ stability measure uses errored seconds and retrains to determine a service’s stability and takes action to compensate for the impact of impairments. The SLD Stability BRAG uses Maximum Attainable Downstream Line Rate, Downstream Line attenuation, Downstream Noise Margin, and Number of retrains. These differences, plus the different thresholds used to make the assessment, mean it is possible for the two measures of stability to categorise a service’s stability differently. A CP’s usage of each measure of stability should reflect the way the service is assessed.Service Layer Data - Lag As mentioned in section 4.0 the SLD BRAG is based on a rolling 7 day window for both ADSL and GEA-FTTC VDSL. As the data requires collating and processing before SLD insights can be produced, there is a lag in the data that, when understood, can help CPs utilise the insights in the most effective way as part of fault qualification.ADSLData has to be shared, by CPs with Openreach, in the agreed format over SDEDS. Openreach processes the data and creates SLD insights for speed and stability. CPs should share the DSL data no later than 24 hours after the time it was generated. Openreach needs a further 12 hours to process and create SLD insights from the time it receives the CP data in SDEDS. Openreach will endeavour to upload SLD insights to SDEDS for a CP to access, by 10am although this time is configurable based on CP preference.GEA-FTTC VDSLAs Openreach owns the GEA-FTTC VDSL SLD data, CPs do not need to share anything with Openreach. The timescales for making the data available are as indicated below. Indicative SLD share timescales The time taken to retrieve and process the data, means that any new service impairments will start to become observable within the line’s SLD BRAG insight a minimum of 36 hours after the impairment has impacted the service, which is critical to understand for accurate diagnosis of new issues on an end customer’s service.SLD insights and interventionsTo ensure the SLD insight’s effectiveness, the algorithm includes ‘reset’ logic that prevents an SLD insight being created where there has been a recent intrusive event on a service (these events can be a provision or repair activity, an intrusive test performed by an engineer, or a DLM reset). Categorising a service’s performance by using data from both before and after an intervention leads to unreliable SLD insights, and a greater likelihood of ineffective engineer visits. To prevent this, the algorithm ‘resets’ when an intrusive event occurs, and makes the following adjustments: For the Speed BRAG, an NA result will be returned the day after the intervention. All subsequent Speed BRAG insights will be created using only data measuring the service’s performance after the intervention.For the Stability BRAG, an NA result will be returned the day after the intervention and for the next 3 days, and all subsequent Stability BRAG insights will be created using only data measuring the service’s performance after the intervention.This is explained further in the following worked example:When a ‘reset’ occurs, one of the following reset reasons will be supplied, listed in priority order:RepairProvisionDLM ResetEngineer test Only a single code will be presented against the service, however a number of these listed events could take place on one day. Of all codes that could have triggered a ‘reset’ that day, the ‘reset’ reason shown will be the one that is of highest priority, as per the order of the above list, e.g. during a repair activity, a ‘Repair’, ‘DLM reset’ and an ‘Engineer test’ would all occur, however the highest priority reason is ‘Repair’, and so this would be presented as the reset reason. Broadband service is determined by a multitude of factorsThere are a number of factors that can influence the end customer’s broadband service outside of Openreach’s control: Rate reach or line length – ADSL and GEA-FTTC VDSL services are distance limited. For ADSL services, the further the premises is from the exchange the slower the service will be. For GEA-FTTC VDSL services, the further the premises is from the DSLAM, the slower the GEA-FTTC VDSL service will work utilisation – Copper pairs are susceptible to ‘crosstalk’ from neighbouring copper pairs in a cable which can impact broadband performance. The impact of crosstalk is more noticeable on short lines. Home environment – The home wiring set up from the Network Termination Equipment (NTE) to the end customer device can affect broadband performance.Home connectivity – Most end customers now use Wi-Fi to access the internet, often via multiple devices simultaneously. End customers’ experience can be impacted by dropped Wi-Fi connections when their DSL service is stable and fast.External Noise Sources - Repetitive Electrical Impulse Noise (REIN) and Single High-Level Impulse Noise Event (SHINE) which are caused by interference from other electrical devices. Dynamic Line Management (DLM) - Is used to optimise the end customer broadband experience by balancing the speed and stability of the service. CP broadband network throughput to Internet Service Provider (ISP)/ internet connectivity – Openreach does not have visibility of the actual traffic the end customer is sending over the service for ADSL. This means the end customer maybe experiencing an issue but we don’t see it because it is beyond our network. Brandenburg codesAs part of the SLD insights output for CPs, Openreach also provides additional diagnostic data in the form of Brandenburg codes for GEA-FTTC services, to support diagnosis of more complex and hard to resolve issues. Brandenburg codeGEA Service Test outcomeExplanationBTPass - OKA bridge tap or star wiring was detected on the line.HRFailA High Resistance (joint) was detected. INTPass - OKElectrical interference of an unidentified source was detected on the line, either in the home or network.OKPass - OKNo Brandenburg impairments were detected on the line.PPIFailPPI (Physical Path Impairment): A service affecting copper impairment was detected. Changes in attenuation were detected, and this data will be used by Openreach to determine the likely location and point of intervention for an engineer. PPI1FailPPI: A service affecting copper impairment was detected. Broad changes in line attenuation were detected, the cause is likely located in the network. PPI2FailPPI: A service affecting copper impairment was detected. Un-correctable errors were detected in both upstream and downstream channels over multiple time periods. The cause is likely located close to the end customer’s premises. PPI3FailPPI: A service affecting copper impairment was detected. Simultaneous changes detected in line attenuation, both upstream and downstream. The cause is likely located in the network. RFPass - OKRadio Frequency interference was detected which is impairing VDSL performance.RNPass - OKREIN (Repetitive Electrical Impulse Noise) was detected which is impairing the VDSL performance.SPFailA ‘split pair’ has been detected.XTPass - OKCrosstalk was detected on this line that may be affecting service performance, but is a natural effect of the VDSL network, and is not an indicator of a network fault. When a Brandenburg code is provided as part of the SLD insight, this is for guidance only and does not replace a GEA Service Test (these tests include a more comprehensive assessment of the Brandenburg data, accounting for line interventions and other changes impacting a service’s performance). However the codes are a good indicator that the appropriate Openreach test should be completed, and where a test fail and MFL are provided, a fault may be submitted to Openreach. Establishing a CP on the SLD sharing process62128401661160Parallel actionsParallel actions59074051403985To set a CP up on the SLD sharing process, the actions to be completed are:RefAction OwnerIndicative DurationIndicative Cumulative Duration 1Email request to be established on the SLD BRAG to Client ManagerCPNANA2Hold Engagement call Openreach Client Manager and Subject Matter ExpertsWithin 2 Weeks2 Weeks3Share broadband guidelines documentationOpenreach Client ManagerWithin 2 Weeks2 Weeks4Agree data share processOpenreach CTIO Customer Experience Managers 2 Weeks4 Weeks5Switch on data share (release dependent)Openreach CTIO Customer Experience Managers6 Weeks10 Weeks6CPs to create plans to make use of the data CPVariableVariableReporting when things aren’t workingWhen an SLD output file is not available on SDEDS, or the file is corrupted, this should be reported to Openreach for resolution. This is done by raising a Service Request on the Openreach Portal, completing the form with the following values:‘Method of placement’ field ‘SDEDS’ ‘Issue Category’ field as ‘Data File Sharing’‘Product’ field as ‘SDEDS‘Related area’ as ‘SLD Report Access’ or ‘SLD Report Issue’If it is an incident classified as P1/P2, CPs can also use the channel listed below to raise an incident related to the SLD services.Phone: 0800 085 1287, option 3 Email: openreach.service.desk@openreach.co.ukOpenreach will send updates to the raising CP about the resolution of the issue as they become available.Service Layer Data Share File FormatThis document defines the technical format which the Service Layer Data insights are delivered in for ADSL and VDSL from Openreach. CPs wishing to consume the insights will need to use this documentation as a basis for their system designs. \sService Symptoms Excluded ‘No Sync’ – Where there is no recent broadband data for a line we are unable to provide a speed or stability classification. These issues are likely to be picked up without the need for SLD insights by CP advisor investigation with the end customer and the current remote line/service tests. ADSL Capped Rate Line – If a CP has implemented a product cap on an ADSL line, the speed classification will be corrupted. Long Lines – ADSL circuits above 5 kms and GEA-FTTC VDSL circuits with a D-side length above 1 km are considered long lines and we do not create a BRAG for these lines.DLM Stabilisation - After any intervention with the service (fix or adjustment), DLM will usually take 5-7 days to stabilize, and the accuracy of the SLD 7 day performance average will also be affected. The SLD performance average will therefore be most representative of the service’s performance 12-14 days after the intervention. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download