Service Performance Management - sp.chorus.co.nz · 2 Service Performance Management | May 2017...

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…


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.


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


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.


LQD results example

Here is an example of the results for an Extended Line Test (LQD):




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.


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



Upshift Rate Adaptations US events



Downshift Rate Adaptations US events



Vectoring Fallback Events Number of times the vectoring stopped working, and the original Service and

Spectrum profiles are used.


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.


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.

https://customer.chorus.co.nz/log-a-problem-report



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.




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.


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.





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.


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.


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.


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.


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.


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


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


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.


Here is an example of the USI – Information Retrieval test results:


DESCRIPTION DETAILS

ASID Confirmation of the ASID Number.

USI The unique service identifier.

CVID

SVID


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.


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.


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).



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


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.


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.

Service Performance Management - sp.chorus.co.nz · 2 Service Performance Management | May 2017...

Documents

Transcript of Service Performance Management - sp.chorus.co.nz · 2 Service Performance Management | May 2017...