Data Integrity

1
Service Management Update December 2008 Tim
Dadd Openreach
Openreach makes every effort to ensure the
information in this report is accurate at the
time of compilation, however, Openreach does not
represent that it is complete and Communications
Providers should check with Openreach for the
latest available information. Openreach reserves
the right to modify delivery criteria and
delivery dates.
2
Agenda

• Data Integrity Methodology
• MAC Issues
• MLC where are we at

3
Data Integrity Methodology

• Identify Issue
• Bridge Cases
• Clashing of Data between systems
• Immediate action
• Process Workaround
• Hand crafted system fix
• Determine Root Cause
• Test assumption across a sample
• Track live example
• Submit to systems for resolution
• Cleanse existing records
• Develop test any required cleansing tools
• Produce correction data
• Execute

4
MAC Issues and Governance

• 81,230 MACs generations accepted during November
  (87,765 placed) with a 7.4 rejection rate.
• SMC proactive monitoring taking place
• Systems help desk logging of all MAC bridge
  cases with clear feedback loop into experts
  Openreach Top Ten Issue calls.
• Regular calls and deep dive analysis in place.
• Fixes have already been put in place. Tracking is
  taking place against implemented fixes with new
  fixes currently scheduled up to R1011.
• Tactical fixes shown in next slides.

5
Overview Slide, MAC Issue Root Causes Part 1
6
Overview Slide, MAC Issue Root Causes Part 2
7
MLC

• Overview
• How does it collect data?
• What is the best way to use MLC?
• Line Prequalification vs- Line Characteristics
• Current network caveats
• Summary

8
MLC Overview

• MLC answers many questions relating to provision
  of an LLU line
• What exchange serves a line?
• Will the line support broadband?
• Signal Noise Ratio?
• Technology Conflicts?
• Who has an LLU service on the line today?
• Implemented to assist with migration problems
• MLC is not real time
• Over 600,000 hits per day is the norm
• Line test heads are already running hot
• Data is cached
• Parts of the cache are only updated every month
• It can take up to 2 months to refresh some of the
  data
• As openreach provides transparency of network
  data to CPs, the CPs see the problems we have
  (warts and all)
• They were always there
• These issues were often resolved by the service
  management centres post order capture, local
  processes and knowledge and have become more
  apparent as we move to zero touch provisioning,
  CP to NETWORK.

9
Line Characteristics
CSS (on-demand)
CELERITY (WEEKLY)
Line loss
LODE
MLC
LLC (WEEKLY)
Physical cable plant data
For each DP
For each PC
Calc Store
Aggregate View
AFM (WEEKLY)
Line Capacitance
Consolidated Data Mart
ONCE DAILY drip MONTHLY Reload
Consolidated view indexed by DN, DP Postcode
For each line determine additional characteristics
PAF (QUARTERLY)
Geographical Address Data
Line Routing, Address data, Customer data
CSS (MONTHLY)
HADES (DAILY)
Line Capacitance
10
Line Characteristics

• LODE provides line qualification and gets data
  from
• CSS (Complete copper routing customer
  information address data) on a monthly basis
  (35,000,000 lines)
• CELERITY provides teradyne measurements (e.g.
  line loss) on a weekly basis
• LLC Cable makeup within the network (e.g. cable
  length, impedance etc.) on a monthly basis
• AFM Capacitance measurements from the teradyne
  test head on a weekly basis
• HADES daily drip feed from CSS of any new
  provision of lines or re-routing of lines and
  network capacitance (from Teradyne test when line
  changed/provisioned)
• PAF Post Office Address file (used to provide
  geographical data)
• ONCE
• Data can be accessed by three keys (DN, DP and
  Postcode)

11
Line Characteristics Timing
Month 2
Month 1
12
Estimating Line Loss at Prequalification

• Use best estimator available for
  prequalification-
• Celerity - most accurate
• Special procedure that runs at weekends
• Data for new lines can take nearly 2 months to
  appear
• Google Celerity for more information
• Weve improved this recently to include STOPped
  lines and certain none broadband compatible lines
• Coverage moved from 65 to 96
• But may not be available for new lines ?
• Capacitance - reasonably accurate (AFM/LTS)
• Measurements updated through daily drip feed
• Effective line length
• Post code - least accurate (CSS)
• Use of records and not physical line test
• We cant make an intrusive line test for MPF
  services
• Least accurate line length will often be the only
  data
• Data currently expires after 2 months

13
Use line loss (Db) not line length (Km)
14
How good is the daily data
15
The Line Length Calculator

• Driven by postcode Easting/Northing Information
• Follows route of service from MDF through PCPs,
  DPs, to End User
• Doesnt consider all aspects of copper medium
  (SWG, material etc.)
• Problem is CSS data is logical not physical
  representation of the network
• CSS has limited flexibility to manage the copper
  data
• This creates conflict between the logical view
  required to provision service and actual physical
  deployment
• Often the logical view is limited by CSS heritage
• Moorgate exchange is now physically at Faraday
  but logically at Moorgate (CSS and other systems
  not changed)
• Line Loss Line Capacitance is correct
• Line Length is wrong

16
Copper network in CSS
Blocks of phone numbers can only belong to one
exchange
A DP can only relate to one exchange
17
Locksheath Whiteley
CSS cannot store services at this DP going to
both Whiteley Locks Heath
WHITELEY
In CSS all of this network looks like additional
infrastructure in Locks Heath
POTS Switch
MDF
CP
DSLAM
DP
Filter
LOCKS HEATH
DP Line length is calculated from DPs Serving
Exchange
POTS Switch
MDF
DSLAM
Filter
These two houses will show as terminated at Locks
Heath in CSS/MLC
18
Blunsdon Haydon Wick
This BBN switch is here so that customers
rerouted onto HYW could keep their number whilst
getting BB
CSS cannot store services at this DP going to
both Blunsdon Haydon Wick so two DPs exist in
CSS for each physical DP
Haydon Wick
In CSS this MDF is recorded twice, once as HYW
and once as BBN
MDF
BBN Switch
HYW Switch
This cable is here to support certain services
and isnt recorded in CSS
CP
DP
DSLAM
Filter
Blunsdon
DP Line length is calculated from DPs Serving
Exchange, even though BBN switch is in HYW
POTS Switch
MDF
DSLAM
Filter

• These houses will show 1 of 3 options
• At HYW
• At BBN but actually at HYW
• At BBN

19
Summary

• Data errors often represent limitations in legacy
  systems
• Openreachs goal of providing transparency to CPs
  is making these issues visible
• We have developed a tool to provide short term
  on-demand workarounds where these issues exist
• 45,000 lines being manipulated every month
• We often dont know about CSS specials until a
  CP complains
• We are making more effort to present Db
  Capacitance information for all lines
• MIND THE GAP
• CPs really need to use all three data sources for
  service qualification in an intelligent way
• Potential enhancements (MLC2)
• Knowledge from CPs become industry wide
• Line unable to provide BB post SFI (black lines)
• Speed achieved
• Change MLC sensitivities (e.g. data expiry time)

20
(No Transcript)