service performance management - sp.chorus.co.nz · 2 service performance management | may 2017...
TRANSCRIPT
Service Performance Management
Broadband and data tests overview
The following tests are used to troubleshoot broadband and data services:
TEST DESCRIPTION
Line State Diagnosis (LSD) Analyses the current state of line, Broadband configurations and the upstream
and downstream Broadband speeds provisioned on this line.
Extended Line Test (LQD) Used when your customer is experiencing DSL disconnection problems and is used to
check performance over a period of time.
Unique Service Identifier (USI)
information retrieval Only applicable to basic UBA and enhanced UBA and is used when your
customer experiences no PPP or authentication issues with their broadband
service.
Port refresh Allows you to breakdown and then rebuild the DSL port for Basic UBA and
Enhanced UBA and immediately resolve some issues.
Broadband history Produces a weekly snapshot of the broadband performance on the line.
Versioning
Version Number
Date Page number(s) Changes
1 9/12/16
1.1 20/10/2017 9-12 G.INP/RTX and Vectoring fields updated
1.2 16/11 Removed what was 2.2.1 spontaneous re-syncs, as profile based analysis is no longer valid for EUBA/VDSL.
2 Service Performance Management | May 2017
Line state diagnosis test
SPM will automatically set off a line state diagnosis test when you first enter the reference
ID number. This is to understand the current state of the line, broadband configurations
and the up and down broadband speeds provisioned on this line.
When a line state diagnosis test is completed the following information will be displayed in
the results section of the screen as shown below:
Continued…
3 Service Performance Management | May 2017
Interpret the results
Use the following table to understand the results:
FIELD DESCRIPTION
LSD results for Line The IP address of the exchange, equipment type
Inspection ID System inspection identifying number.
CPE Type The type of customer premise equipment.
DSL Type The type of digital subscriber line ,e.g.:
adsl2plus = fibre to the node operating mode non.shdsl = not single pair high speed subscriber line line.type.pots = this is the type of access to the home latency.interleaved = will be either interleaved or non- interleaved
Line ID Identifies the exchange and the DSLAM that the internet services supplied by.
User Label Identifies the user label DLSAM configurations
Spectrum Profile Name For EUBA and VDSL this is irrelevant as ddDLM overrides the profile, for BUBA this identifies the configuration parameters (operating mode: ADSL / ADSL2, noise margin, PSD / Power, masking etc.).
Service Profile Name For EUBA and VDSL this is irrelevant as ddDLM overrides the profile, for BUBA this identifies the configuration parameters profile (interleaving on or off, up and down speeds (full speed / full speed or full speed / 12bkps).
Service Template Name Identifies the service associated with the DSLAM, and weather ddDLM is managing the circuit.
Modem Vendor ID Unique vendor's modem ID.
System Vendor ID Unique system vendor's modem ID.
System Vendor Model Unique system vendor's modem model ID.
Serial Number Unique serial number of vendor's modem.
4 Service Performance Management | May 2017
Service Stability Provides information to determine service stability (stable, unstable, unknown).
Line Status If the line status is down, look at the information returned in the fields in the diagnosis results section.
If the line status is up, this means that DSLAM and modem are in sync. However, the CPE may have interoperability issues, e.g. stability, rate impact.
Problem This is normally blank.
Location Identifies the service location that is having the problem.
Description A plain english description of the diagnosis.
Impact Identifies the impact that is occurring.
Confidence Provides a degree of confidence in relation to the description.
lqd.parameter.actual.rtx.mode Determines if RTX (retransmission) is used in upstream/downstream “rtx.mode.in.use” means G.INP is running. Only displayed on FD ISAM models. Currently displayed in a less than ideal way with text that runs over both columns. This will be fixed in a future BAU SPM release.
lqd.parameter.rel.capacity.occupation
The ratio of the actual connect rate to the attainable connect rate, coded in as a percentage.
lqd.parameter.attenuation Identifies the amount of loss seen on the line and is affected by length of cable between the customer and equipment, the gauge [thicker = less loss], damage to the cable and such issues as multiples etc.
lqd.parameter.loop.attenuation The measured difference in the total power transmitted and the total power received over all subcarriers during diagnostics mode and initialization. It is measured in dB. It is only available for xDSL-managed lines (that is ADSL2(+), VDSL, and VDSL2 lines)
lqd.parameter.noise.margin Identifies the noise margin which decreases as a result of the distance, line conditions, etc.
lqd.parameter.actual.psd This is the actual power spectral density associated with the service (dBm/Hz)
lqd.parameter.power Identifies the power output value associated with the service
lqd.atm.traffic.rate.title Estimation of the ATM traffic rate. Very inaccurate (if shown at all) for LSD
lqd.parameter.actual.bitrate Identifies the throughput bitrate specified in the profile allocated to the service.
lqd.parameter.attainable.bitrate
Identifies the attainable bitrate the line can achieve (determined mainly by the attenuation and the noise margin)
lqd.parameter.actual.impulse.noise.protection
The actual, negotiated, number of symbols of Impulse noise protection
lqd.interleaving,delay The actual, negotiated, time in milliseconds for interleaving
5 Service Performance Management | May 2017
lqd.parameter.actual.expected.throughoput
The expected throughput (ETR) figure is a fixed value determined during initialization. It represents the data rate available to the higher layers when noise conditions correspond to the values defined in the RTX configuration. That is, it is the net data rate minus the RTX overhead provisioned for retransmissions.
Hence, it is not guaranteed to have a throughput of ETR all the time, as this depends on the noise conditions: In the absence of impulse noise, the throughput reaches the net data rate. In case of really bad impulse noise conditions, the throughput might decrease below ETR. Only displayed on FD ISAM models.
lqd.parameter.actual.net.data.rate
The actual net data rate (NDR) is the throughput available tow ard the higher layers when no transmission occurs – in other words, the full rate of the line when no overhead is used for retransmission. Only displayed on FD ISAM models.
Lqd.paramter.attainable.expected.throughput
Estimation of the maximum achievable expected throughput at the DSL layer for the given loop conditions. Only displayed on FD ISAM models.
Lqd.parameter.attainable.net.data.rate
Estimation of the maximum achievable net data rate for the given loop conditions. Only displayed on FD ISAM models.
Lqd.parameter.actual.inp.shine
Actual impulse noise protection against SHINE. Only displayed on FD ISAM models
Lqd.parameter.actual.inp.rein Actual impulse protection against REIN. Only displayed on FD ISAM models
Lqd.parameter.actual.rtx.delay
Actual delay used on the line for retransmissions. Only displayed on FD ISAM models.
Per band line parameters This table displays parameters for each ADSL / VDSL band
Vect line parameters, operational mode
Value determined by the Actual CPE Vert Type and the status of Vectoring (enabled, disabled, full disabled)
Vect disturber List the disturbing lines and their average magnitude and status
Extended Line Test (LQD)
The Extended Line Test should only be conducted:
When your customer is experiencing DSL disconnection problems.
By a person who has been assigned to Assure T1 advance role.
To run the test:
1. Select Extended Line Testing (LQD) from the Select test dropdown list.
2. Select the duration you want the test to be completed over, along with when the results
will be polled from the Monitoring Options dropdown list. The ‘24 hours (3 minute
collection)’ option should be used as the default. The ‘Duration One Minutes, Polling every 15
seconds’ option should only be used for training purposes.
3. Click Submit.
6 Service Performance Management | May 2017
LQD results example
Here is an example of the results for an Extended Line Test (LQD):
7 Service Performance Management | May 2017
8 Service Performance Management | May 2017
Interpret the results
Use the following table to understand the results:
FIELD DESCRIPTION
LQD results for line The IP address of the exchange, equipment type
Inspection ID System inspection identifying number.
CPE type The type of customer premise equipment.
DSL type The type of digital subscriber line, e.g.:
adsl2plus = fibre to the node operating mode
non.shdsl = not single pair high speed subscriber line
line.type.pots = this is the type of access to the home
latency.interleaved = will be either interleaved or non-interleaved
Line ID Identifies the exchange and the DSLAM that the internet services supplied by.
User label Identifies the user label DSLAM configurations
Spectrum profile name For EUBA and VDSL this is irrelevant as ddDLM overrides the profile, for BUBA this identifies the configuration parameters (operating mode: ADSL / ADSL2, noise margin, PSD / Power, masking etc.).
Service profile name For EUBA and VDSL this is irrelevant as ddDLM overrides the profile, for BUBA this identifies
the configuration parameters profile (interleaving on or off, up and down speeds (full speed /
full speed or full speed / 12bkps).
Service template name Identifies the service associated with the DSLAM, and weather ddDLM is managing the circuit.
Modem vendor ID Unique vendor's modem ID.
System vendor ID Unique system vendor's modem ID.
System vendor model Unique system vendor's modem model ID.
Serial number Unique serial number of vendor's modem.
Service stability Provides information to determine service stability (stable, unstable, unknown).
Event info See event Info below
Monitored parameters These results provide the Min (minimal), Max (maximum), Mean (average), and the StdDev (standard deviation) measurements in relation to the up and down stream values with the broadband services. See Monitored Parameters for a description of the result fields and graphs.
9 Service Performance Management | May 2017
Event info
The event info table describes a number of xDSL events which are monitored over the LQD
collection period.
Field Description
Spontaneous Re-sync The number of xDSL line resynchronization events. These can be due to line
issues, modem reboots, or port resets.
Failed Init This is a spontaneous resync which fails. ‘Failure’ is described as a
resynchronization event that takes too long, longer than expected, or is
actually multiple back-to-back resyncs.
Bitswaps The number of bits swapped between tones. Note that this is a normal DSL
event, there will almost always be a number here, but there is no action
required.
Profile Switches The number of profile switches, typically due to ddDLM
Collection Failures The number of times that the Network Analyser could not collect from the
ISAM. This is due to some kind of management network issue and will show
up in the graphs too. It is not specific to the customer’s DSL line.
Loop Diagnostics Number of Loop Diagnostics were run while the LQD was running.
Disorderly Leaving Events Number of disorderly leaving events observed during the LQD inspection.
Appears only if the line has vectoring active.
Upshift Rate Adaptations DS Events
Number of Seamless Rate Adaptations (SRA) events during the LQD
inspection. This is used as part of G.INP functionality.
Downshift Rate Adaptations DS Events
Number of Seamless Rate Adaptations (SRA) events during the LQD
inspection. This is used as part of G.INP functionality.
Upshift Rate Adaptations US events
Number of Seamless Rate Adaptations (SRA) events during the LQD
inspection. This is used as part of G.INP functionality.
Downshift Rate Adaptations US events
Number of Seamless Rate Adaptations (SRA) events during the LQD
inspection. This is used as part of G.INP functionality.
Vectoring Fallback Events Number of times the vectoring stopped working, and the original Service and
Spectrum profiles are used.
10 Service Performance Management | May 2017
Monitored parameters
Use the following table to understand the Monitored Parameters results:
Field Description
lqd.parameter.actual.rtx.delay Actual delay used on the line for retransmissions
lqd.parameter.attainable.net.datarate Estimation of the maximum achievable net data rate for the given loop
conditions.
lqd.parameter.attainable.bitrate Identifies the attainable bitrate the line can achieve (determined by the
attenuation and the noise margin)
lqd.atm.traffic.rate.title Estimated ATM throughput
lqd.interleaving.delay The time in milliseconds for interleaving
lqd.parameter.actual.expected.throughput
The expected throughput (ETR) figure is a fixed value determined
during initialization. It represents the data rate available to the higher
layers when noise conditions correspond to the values defined in the
RTX configuration. That is, it is the net data rate minus the RTX
overhead provisioned for retransmissions. Hence, it is not guaranteed
to have a throughput of ETR all the time, as this depends on the noise
conditions: In absence of impulse noise, the throughput reaches the
net data rate. In case of really bad impulse noise conditions, the
throughput might decrease below ETR.
lqd.parameter.actual.net.datarate The actual net data rate (NDR) is the throughput available toward the
higher layers when no retransmission occurs – in other words, the full
rate of the line when no overhead is used for retransmission.
lqd.parameter.actual.ino.rein Actual impulse noise protection against REIN.
lqd.parameter.re.capacity.occupation Identifies the relative capacity occupation percentage
lqd.parameter.loop.attenuation The measured difference in the total power transmitted and the total power
received over all subcarriers during diagnostics mode an initialization. Is it
measured in dB It is only available for xDSL-managed lines (that is,
ADSLs(+), VDSL, and VDSL2+ lines)
lqd.parameter.power Identifies the power output value associated with the service.
lqd.parameter.actual.bitrate Identifies the throughput bitrate specified in the profile allocated to the
service.
lqd.parameter.attainable.expected.throughput
Estimation of the maximum achievable expected throughput for the given
loop conditions.
11 Service Performance Management | May 2017
lqd.parameter.actual.impulse.noise.protection
The actual number of symbols of impulse noise protection
lqd.parameter.attenuation Identifies the amount of loss seen on the line and is affected by length of
cable between the customer and equipment, the gauge [thicker = less
loss], damage to the cable and such issues as multiples etc.
lqd.parameter.noise.margin Identifies the noise margin which decreases as a result of the distance,
line conditions etc.
Lqd.parameter.actual.inp.shine Actual impulse noise protection against SHINE
lqd.parameter.actual.psd Identifies the actual power spectral density associated with the service (dBm/Hz).
Monitored parameters graphs
The monitored parameters results are presented in more detail using graphs. Each graph is
described below, along with instructions on when to log a problem report if applicable.
The following graphs are related to G.INP (RTX), Upstream and Downstream Bitrate
(RTX), LEFTRS, RTX DTU.
Note that there are now separate User Traffic graphs instead of ATM throughput being
combined with the Bitrate graphs.
BIT LOADING CONTOUR GRAPH
The graph below is an example of a DSL your customer with degraded internet
performance. The graph shows a reduced throughput and a number of line dropouts.
If there are multiple visible dips or a dip across a large frequency range, either investigate
for possible RFI/environmental issues or log a problem report and send to the Chorus
Faults Resolution Group to investigate further. This may change the spectrum profile.
12 Service Performance Management | May 2017
BITLOADING
DSL works by creating a number of bins that contain bits of data. Each bin:
Is assigned a frequency range in the DSL signal
Can contain a number of bits depending on how well the frequencies can get through the
phone line.
This graph shows how many bits are fitting in each bin, and at what frequencies the bins
are spread out across the line. The better the line, the more bits and bins you have that
can be used, i.e. a higher bitrate. The example below shows the tones used for data
transfer, both upstream (the red band) and downstream from average traffic perspective.
This examples show that there are dips in the bit loading (mean bit loading bits) around the
70 mark.
If there are multiple visible dips or a dip across a large frequency range, either investigate
for possible RFI/environmental issues or log a problem report and send to the Chorus
Faults Resolution Group to investigate further. This may change the spectrum profile.
13 Service Performance Management | May 2017
UP/DOWN STREAM BITRATE
These graphs show the actual (red line) and attainable bitrate (blue line). The attainable
bitrate should be higher than the actual and may be fluctuating a bit.
14 Service Performance Management | May 2017
CODING VIOLATIONS
Coding violations occur when traffic is corrupted at the ATM level. In this example there
are times where the speed dropped packets were corrupted. This issue occurs when the
modem goes through the process of trying to ascertain what speed it can connect to the
DSLAM reliably.
If there are a high number of coding violations that are peaking through the testing period,
log a problem report and send to the Chorus Faults Resolution Group. They will investigate
further and may change the spectrum profile.
15 Service Performance Management | May 2017
DOWNSTREAM NOISE MARGIN
This example shows the noise margin fluctuating wildly between 6db up to 13db at the
same time periods where the attainable line speeds were being affected. The green line is
the profiled “target” noise margin for the port.
If the noise margin has not dropped to zero the DSL never dropped during testing, the
DSL has never dropped off during the test period.
If the noise margin has dropped to zero during the testing period, the modem would have
reset. Check the customer equipment.
16 Service Performance Management | May 2017
UPSTREAM NOISE MARGIN
This example shows the noise margin are not dipping to the green line and the profiled
'target' noise margin for the port is unaffected.
If the noise margin has not dropped to zero the DSL never dropped during testing, the DSL has
never dropped off during the test period.
If the noise margin has dropped to zero during the testing period, the modem would have reset.
Check the customer equipment.
17 Service Performance Management | May 2017
18 Service Performance Management | May 2017
ATTENUATION
This example shows the downstream attenuation is 60db. As this is attributable to line
length and condition the assumption is that the customer maybe some distance from the
DSLAM.
19 Service Performance Management | May 2017
OUTPUT POWER
The amount of power transmitted from the exchange and the customer’s modem. Output power
will likely increase depending on the length of the line (loop loss). Output power levels should
be consistently the same. This will be always dependant on the properties of the cable.
Variance in port output power indicates changes in the copper cable. This means that properties
of electrical levels (capacitance, resistance) are impacted likely to a physical fault. Check your
NTS results where available.
The below graph would be considered good.
TRANSFER FUNCTION MAGNITUDE (HLOG)
HLog data is reported during the modem initialization phase shows attenuation over frequency.
HLog data can indicate physical copper loop conditions, such as the presence of bridge taps
(multiples) or a capacitive problem. A clean line HLog plot should decline slowly and evenly
from left to right or from lower frequencies to higher frequencies.
20 Service Performance Management | May 2017
The below graph would be considered good
FORWARD ERROR CORRECTION
Count of errors that have been corrected due to error correction being applied to the line. Error
correction is turned on at the same time as Interleaving. It’s normal to see FEC errors on an
interleaved line and rather than anything to be too concerned about it’s more an indication that
the Interleaving & Error Correction process is working and doing what it should.
The level of error correction needs to be compared to bitrates and customer throughput
however in general a level of 100000 in a 15minute period is acceptable, and should be
unnoticeable to the customer.
21 Service Performance Management | May 2017
SIGNAL TO NOISE RATIO (SNR)
Is a measurement in decibels of the signal strength to the level of noise on the line.
The higher your SNR is, the better, as there is less background noise. Note that high SNR will
translate to a stable connection but with lower sync rates. SNR fluctuates on all lines throughout
the course of the day by various amounts. This will have a very similar look to the bit loading
graph.
UP/DOWN STREAM NOISE MARGIN
The noise margin and target noise margin should be about the same, however is more
important that the level is constant or has light fluctuations
This is fine
22 Service Performance Management | May 2017
This is not fine
QUIET LINE NOISE
Modems gather quiet line noise data when there is no DSL signal on the line, if the graph is
blank it should mean the connection didn’t drop. Below are some graphs with possible scenarios
23 Service Performance Management | May 2017
USI – Information retrieval
Use the USI (Unique Service Identifier) test when an your customer experiences ‘No PPP’ or
‘Authentication’ issues with their xUBA service. This test only applies to xUBA services and
will not work on other broadband services, an error message will display for a non-xUBA
service.
To run the test:
1. Select USI – Informational Retrieval from the Select test dropdown list.
2. Click Submit.
Interpret the results
Here is an example of the USI – Information Retrieval test results:
Use the following table to understand the results:
DESCRIPTION DETAILS
ASID Confirmation of the ASID Number.
USI The unique service identifier.
CVID
SVID
24 Service Performance Management | May 2017
HoP Handover Point, e.g. IDA100533781.
Port ID Identifies the Port ID.
Port refresh
The port refresh capability will enable you to ‘break down’ then ‘rebuild’ the DSL port for
xUBA services. This allows you to immediately resolve issues or faults for Broadband.
Port refreshes should not be submitted when there are open service orders for the service
as these are likely to corrupt the provisioning process. A list of open service orders will be
displayed. There is also a validation process in the background that will not allow a port
refresh to be successfully submitted if there are open service orders.
Steps
To run a port refresh, complete the following troubleshooting steps to determine if a port
refresh can be performed:
CHECK THE ACTION
Broadband
service Determine if:
BUBA or EUBA, go to next prequalification check
Another Broadband service such as Chorus VDSL, the customer is ineligible for a port refresh to be
performed.
DLSAM Determine if:
ISAM, ASAM, Fastmux, go to next prequalification check
Nokia or any other DLSAM, the customer is ineligible for a port refresh to be performed.
Spectru
m
Profile
Determine if:
BUBA or EUBA, go to next prequalification check
Another Broadband service such as Chorus VDSL, the customer is ineligible for a port refresh to be
performed.
History of
the your
customer
Determine if the your customer:
Is reporting a fault greater than seven days from the last time they reported a fault and a port refresh
was NOT performed on the your customer's line, go to next prequalification check
Has reported a problem in the last seven days and a port refresh was performed, the customer is
ineligible for a port refresh to be performed.
25 Service Performance Management | May 2017
Problem
your
customer is
reporting
Determine if your customer is reporting a:
No DSL, disconnection or slow speed fault, go to Run a port refresh
No PPP problem, the customer is ineligible for a port refresh to be performed.
1. Select Port Refresh from the select test dropdown list,
2. Click Submit.
1. Read the confirmation box and click Continue to submit the port refresh request.
Interpret the results
If the following message is viewed then the port refresh was successful:
Error messages
If the following error messages display, log a problem report. This will be sent to our Assure
group (as per current BAU process).
26 Service Performance Management | May 2017
FAILED PORT REFRESH
Here is an example of a failed port refresh error:
EXCEPTION PORT REFRESH
Here is an example of an exception port refresh error:
Broadband history
27 Service Performance Management | May 2017
The Broadband history is a weekly snapshot of the broadband performance of the line and
will provide you a ‘view’ over a period of time which would indicate a line fault (i.e. the
performance was within working parameters and now the history is indicating that the
performance has degraded).
The results are useful when a customer is experiencing slow speeds while downloading web
content (also known as ‘low connection’ rates). A connection rate is the speed at which the
modem connects to the exchange. If your customer is experiencing speeds of under 1Meg
would be considered to have a low connection rate.
Effective troubleshooting and using this capability will help in determining the next steps,
e.g. advising your customer accordingly and performing a self-service truck roll.
Viewing the results
The result will not be visible until you have clicked on the drop down arrow.
VIEWING THE RESULTS BEFORE THE LINE STATE DIAGNOSIS TEST IS COMPLETED
The current broadband performance is presented along with the broadband history results,
however if you click the drop down arrow before the Line State Diagnosis is completed, the
following view will be presented.
28 Service Performance Management | May 2017
VIEWING THE RESULTS AFTER THE LINE STATE DIAGNOSIS TEST IS COMPLETED
The current broadband performance will be presented along with the broadband history
results. It is recommended that you wait for the Line State Diagnosis test to be
completed.