Service Performance Management

Transcription

1 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 Port refresh Only applicable to basic UBA and enhanced UBA and is used when your customer experiences no PPP or authentication issues with their broadband service. 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/ /10/ G.INP/RTX and Vectoring fields updated /11 Removed what was spontaneous resyncs, as profile based analysis is no longer valid for EUBA/VDSL.

2 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 2 Service Performance Management May 2017

3 Interpret the results Use the following table to understand the results: FIELD LSD results for Line DESCRIPTION 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. 3 Service Performance Management May 2017

4 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.occ upation 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 lqd.parameter.noise.margin 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) 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.bitrat e 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 4 Service Performance Management May 2017

5 lqd.parameter.actual.expecte d.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.expe cted.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.shi ne 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.dela y 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. 5 Service Performance Management May 2017

6 LQD results example Here is an example of the results for an Extended Line Test (LQD): 6 Service Performance Management May 2017

7 7 Service Performance Management May 2017

8 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 Service 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.). 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. 8 Service Performance Management May 2017

9 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. 9 Service Performance Management May 2017

10 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.through put 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.thro ughput Estimation of the maximum achievable expected throughput for the given loop conditions. 10 Service Performance Management May 2017

11 lqd.parameter.actual.impulse.noise.pro tection 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. 11 Service Performance Management May 2017

12 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. 12 Service Performance Management May 2017

13 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. 13 Service Performance Management May 2017

14 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. 14 Service Performance Management May 2017

15 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. 15 Service Performance Management May 2017

16 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. 16 Service Performance Management May 2017

17 17 Service Performance Management May 2017

18 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. 18 Service Performance Management May 2017

19 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. 19 Service Performance Management May 2017

20 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 in a 15minute period is acceptable, and should be unnoticeable to the customer. 20 Service Performance Management May 2017

21 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 21 Service Performance Management May 2017

22 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 22 Service Performance Management May 2017

23 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 ASID DETAILS Confirmation of the ASID Number. USI The unique service identifier. CVID SVID 23 Service Performance Management May 2017

24 HoP Handover Point, e.g. IDA 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. 24 Service Performance Management May 2017

25 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). 25 Service Performance Management May 2017

26 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 26 Service Performance Management May 2017

27 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. 27 Service Performance Management May 2017

28 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. 28 Service Performance Management May 2017