A network service provider can provide telephone service and/or high speed data service to its customers using a DSL (digital subscriber line) system. A DSL system can use existing metallic (e.g., copper) drop wires (referred to as drop connections) that extend from a distribution point to the customer premises to provide the telephone service and/or high speed data service to the customer. If there are anomalies or defects (e.g., a bad splice or a “high open” condition) associated with the drop connection, the customer may experience problems (e.g., intermittent echoes) with his or her service.
Due to the intermittent nature of some of the anomalies or defects, the identification of the source of the anomaly or defect can be difficult for maintenance personnel. Some DSL systems may implement echo cancellation techniques that can be used to locate the source of the anomaly or defect in a drop connection. However, not all DSL systems can use echo cancellation techniques to identify the source of the anomalies or defects in a drop connection because not all of the DSL protocols that may be used by the DSL systems require the use of echo cancellation. Further, even if the DSL system does include echo cancellation techniques, the echo cancellation techniques may not be available for use by maintenance personnel to identify the source of an anomaly or defect in a drop connection because the echo cancellation techniques may be encapsulated within third party hardware components and be inaccessible to maintenance personnel.
Alternatively, a maintenance person can attempt to identify the source of anomaly or defect in a drop connection by travelling to the distribution point and using test equipment to identify the source of the anomaly or defect in the drop connection. However, sending a maintenance person to the distribution point in order to identify the source of an anomaly or defect can be expensive and time consuming.
Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like parts.
The present application generally pertains to identifying and locating faults in a telecommunication line used to communicate signals or messages in accordance with a discrete multi-tone (DMT) modulation scheme. The DMT modulation scheme may be associated with a DSL (digital subscriber line) protocol used for communication over the telecommunication line. A telecommunication line can be suspected of having a fault condition present if the corresponding port for the telecommunication line at an intermediate point located between the central office and the customer premises has to go through a retraining sequence or process a predetermined number of times within a predetermined time period (e.g., 24 hours). Alternatively, a telecommunication line can be suspected of a having a fault condition if the service provider receives a complaint from a customer regarding the customer's service that is provided over the telecommunication line. Once a telecommunication line is identified as having a possible fault condition, a plurality of line tests can be performed on the telecommunication line. The plurality of line tests can be performed within a maintenance window for the telecommunication line, prior to performing a retraining sequence on the telecommunication line, within the window for the retraining sequence associated with the telecommunication line, or during a self-generated window resulting from the halting of communications over the telecommunication line. The plurality of line tests can be a single ended line test (SELT) that can be incorporated within the DSL protocol being used to implement the DMT modulation scheme. In an embodiment, the SELT can include sending a test signal for each tone used by the DMT modulation scheme.
The results received from the SELT can be in the frequency domain and can correspond to an impedance for the telecommunication line. An inverse fast Fourier transform can be applied to the received results to convert the results from the frequency domain to the time domain. The transformed results, which can include values at several different times, can then be compared to the values of other transformed results from other line tests to determine the differences (if any) between the corresponding values of the transformed results being compared. The comparison of the transformed results can involve a comparison of actual values, magnitudes or derivative values of the transformed results. Alternatively, the received results may be compared in the frequency domain prior to transforming the results.
Once the differences between the values of the results have been determined, the differences can be analyzed to determine if there is a fluctuation in one or more of the differences. The determination of a fluctuation in one or more of the differences can confirm the presence of a fault in the telecommunication line. A fluctuation in the differences can be determined from a specific difference value or the sum of several corresponding specific difference values exceeding a predetermined threshold value. A fault in the telecommunication line can cause intermittent changes in impedance, which can cause variations in the transformed results. Such variations can result in the generation of corresponding difference values that can be large enough to be considered fluctuations. After a fluctuation is identified, the location of the fluctuation can be determined from the corresponding difference values since the transformed results, which are in the time domain, used to generate the differences can correspond to a distance from the intermediate point originating the telecommunication line.
The present application also pertains to a method for identifying and locating intermittent high open, bad splice behavior which can cause chronic port retrains in ADSL, VDSL and vectored VDSL equipped hardware (e.g., a DSLAM (DSL Access Multiplexer)). The method first identifies a troubled port by determining if a port has been retrained more than a predetermined number of times within a certain time period (e.g., 24 hours). Alternatively, a customer can call with a complaint that is used to identify the troubled port. Next, for the troubled port, a periodic SELT (single ended line test) can be forced on the troubled port or the SELT can be executed multiple times following a retrain event. The FDR (frequency domain reflectometry) result from the SELT test can be processed using an IFFT (inverse fast Fourier transform) to create a TDR (time domain reflectometry) type response for each SELT FDR capture. The differences between the series of SELT FDR captures, either from the FDR results or the processed TDR results, are computed. Using the differences, which may be actual values, magnitudes, or their first and/or second derivatives, with some corresponding thresholds, changes in the differences can be detected to see fluctuations on the line. The distance from the DSLAM to the line fluctuation can be located and an alarm or message indicating the fluctuation's existence and location can be provided.
The high-speed data connection 20 provides a high-speed channel that carries a data stream between the intermediate point 18 and the network facility 14. While the embodiment in
As shown by
The service unit 50 can process data packets in both the downstream and upstream directions. In the downstream direction, the service unit 50 receives, from the communication circuitry 52, at least a portion of the data packets provided to the intermediate point 18 by the network 16 via high-speed data connection 20. The service unit 50 can then de-multiplex the data for transmission across a plurality of subscriber lines or drop connections 24. In the upstream direction, the service unit 50 receives a plurality of data packets from a plurality of subscriber lines or drop connections 24 and multiplexes the data into a high-speed data signal that can be provided to communication circuitry 52 for transmission upstream to the network 16. In one embodiment, the service unit 50 can be a DSL Access Multiplexer (DSLAM).
The communication circuitry 52 can be used to process upstream and downstream packet flows for the high-speed data service (HSDS). The communication circuitry 52 can include an optical network units (ONU) (not specifically shown) that can receive at least one packet flow from the high-speed data connection 20 and convert the received packet flow(s) from the optical domain to the electrical domain. At least a portion of the converted packet flow(s) can then be forwarded to a switch matrix 54 of the service unit 50 and then sent to the customer premises 12 using a plurality of transceivers 56. The transceivers 56 can communicate using DSL (digital subscriber line) protocols such as asymmetric DSL (ADSL), very-high-bit-rate DSL (VDSL), G.fast, or vectored VDSL. However, in other embodiments, other DSL protocols such as high-bit-rate DSL (HDSL) and VDSL2 or other known protocols can also be used.
The switch matrix 54 can be configured to forward the data packets of the high-speed data stream from the communication circuitry 52 to the transceivers 56 based on the destination addresses in the data packets such that each data packet is ultimately received by the CPE (e.g., the HSDU 28) identified by the packet's destination address. In one embodiment, the switch matrix 54 can be a field programmable gate array (FPGA), but other type of control or switching devices can be used for the switch matrix 54 in other embodiments. In one embodiment, the data packets can be communicated across the drop connections 24 using discrete multi-tone (DMT) modulation in accordance with the corresponding DSL protocol being used. DMT modulation uses a sequence of equally spaced frequencies or tones, each of which is modulated using quadrature amplitude modulation (QAM), to encode multiple carrier signals at different frequencies with digital data. However, other modulation formats may be used in other embodiments.
The service unit 50 can include logic 72, referred to herein as “fault detection logic,” for detecting faults between the intermediate point 18 and the customer premises 12. The fault detection logic 72 can perform line tests and identify the location of a detected fault based on information stored in performance metric data 70. The fault detection logic 72 can be implemented in software, hardware, firmware or any combination thereof. In the service unit 50 shown in
The service unit 50 can include at least one conventional processor 66, which has processing hardware for executing instructions stored in memory 68. As an example, the processor 66 may include a central processing unit (CPU), a digital signal processor (DSP), a microprocessor or a network processor. The processor 66 can communicate with and drive other elements within the service unit 50 via a local interface (not shown), which can include at least one bus.
The troubled drop connection 24 can be automatically identified based on retrain information for each port (or drop connection) of the service unit 50 stored in performance metric data 70. The performance metric data 70 can store performance metrics, such as the number of retrains, for each transceiver 56. Each time a transceiver 56 is retrained (or reinitialized) as a result of an error, signal margin fluctuation, or other similar triggering event, the performance metric data 70 associated with that transceiver can be updated to indicate that the transceiver 56 has been retrained. The information regarding the number of retrains for a transceiver 56 (or port) in the performance metric data 70 can be accessed by the processor 66 of the service unit 50 to determine if the transceiver 56 (or port) has been retrained the predetermined number of times within the predetermined time period. In another embodiment, a network management device or management entity that is connected to the intermediate point 18 can retrieve the performance metric data 70 from the service unit 50 and analyze the data to determine if a transceiver 56 (or port) has been retrained the predetermined number of times within the predetermined time period. If the network management device determines that a transceiver 56 (or port) has been retrained the predetermined number of times within the predetermined time period, the network management device can notify the corresponding service unit 50 of the troubled drop connection at the service unit 50. In one embodiment, the network management device can be a management element at the network facility 14. In another embodiment, as shown in
In one embodiment, the performance metric data 70 may also store other information on the transceivers 56 in addition to the number of times the transceiver has been retrained. For example, the performance metric data 70 can include information on the number of bits sent and received by the transceiver 56, the number of seconds the transceiver 56 was unavailable, the number of erred seconds for the transceiver 56 and the number of severely erred seconds for the transceiver 56. The information can be obtained from the transceivers 56 at a predetermined time interval (e.g., every 15 minutes) and stored in performance metric data 70.
Once the troubled drop connection is identified, a plurality of line tests are performed on the troubled drop connection (step 404) by the fault detection logic 72. Each line test may be performed during a maintenance window for the troubled drop connection. Alternatively, communications using the troubled drop connection may be halted in order to perform the line test. A further option for performing the line test is to perform the line test between the time when a fault is detected for a transceiver and the retraining of the transceiver occurs (e.g., prior to starting the retraining of the transceiver). In one embodiment, the plurality of line tests can be periodically performed on the troubled drop connection at a predefined interval (e.g., every 15 minutes). However, in other embodiments, different intervals can be used between two lines tests and the interval can vary between 5 minutes and 30 minutes.
In one embodiment, a single ended line test (SELT) can be performed a predetermined number of times (e.g., 5 times) on the troubled drop connection when performing the plurality of line tests. The SELT can be incorporated within the corresponding DSL protocol (e.g., VDSL or ADSL) and can provide a frequency domain measurement of input impedance. For example, when using DMT modulation, the SELT can send a test signal for each tone used by the DMT modulation and receive a corresponding reflection (or echo) for each tone. In one embodiment, the test signal can be a sinusoid having a fixed amplitude and phase and the received signal (the reflection) can have its own amplitude and phase which are shifted from the amplitude and phase of the test signal. In one embodiment, the results of the SELT for each tone in the DMT modulation can be a complex number that corresponds to the phase and gain shift of the transmitted signal. However, other types of line tests (e.g., a dual ended line test (DELT) or a TScan) can be performed on the troubled drop connection in addition to or in place of the SELT in other embodiments.
The results from the plurality of line tests are then individually processed by the fault detection logic 72 (step 406), which may include processing the responses for each tone when DMT modulation is used. In one embodiment, the processing of each of the line test results can include converting line test results that are in the frequency domain (e.g., a frequency domain reflectometry (FDR) response) to results that are in the time domain (e.g., a time domain reflectometry (TDR) response) using an inverse fast Fourier transform (IFFT). For example, the IFFT can be provided a set of complex numbers from a SELT on a DMT modulated drop connection to get a response in the time domain. In one embodiment, the TDR response can indicate reflections on the line with respect to distance, which is based on the elapsed time between when a test signal is sent and when the reflection is received.
The differences between the individual test results are then computed by the fault detection logic 72 (step 408). The differences between the individual test results can be determined by comparing a value at a specific instance in time (corresponding to a distance) from a base test result (e.g., the first test result from the plurality of line tests) to a corresponding value at the same specific instance in time (corresponding to a distance) from each of the other test results (e.g., the subsequent test results from the plurality of line tests).
As an example, a point on a curve for one of the curves may represent a measurement (e.g., amplitude) of a reflection of a signal received at the transceiver at a certain time after transmission of the signal from the transceiver. Such measurement corresponds to a distance along the subscriber line to the point at which the reflection was reflected back toward the transceiver since it takes a certain finite time for the signal to travel to the reflection point and reflect from such point back to the transceiver. Thus, points on the curves for all of the tests at the same horizontal coordinate of the graph of
In this regard, referring to
The distance from a reference location to the defect(s) in the drop connection 24 can then be determined based on the detected fluctuation(s) (step 412). In one embodiment, the reference location can be the intermediate point 18, but the reference location can correspond to other physical locations in other embodiments. An alarm and/or message can then be provided to a user to inform the user of the defect and the probable location of the defect relative to the intermediate point 18. For example, Point A of
Although the figures herein may show a specific order of method steps, the order of the steps may differ from what is depicted. Also, two or more steps may be performed concurrently or with partial concurrence. Variations in step performance can depend on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the application. Software implementations could be accomplished with standard programming techniques, with rule based logic and other logic to accomplish the various connection steps, processing steps, comparison steps and decision steps.
It should be understood that the identified embodiments are offered by way of example only. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present application. Accordingly, the present application is not limited to a particular embodiment, but extends to various modifications that nevertheless fall within the scope of the application. It should also be understood that the phraseology and terminology employed herein is for the purpose of description only and should not be regarded as limiting.
Number | Name | Date | Kind |
---|---|---|---|
5500879 | Webster | Mar 1996 | A |
6334219 | Hill | Dec 2001 | B1 |
6538451 | Galli | Mar 2003 | B1 |
6628754 | Murphy | Sep 2003 | B1 |
6721394 | Murphy | Apr 2004 | B1 |
6744813 | Ko | Jun 2004 | B1 |
6870901 | Gudmundsson | Mar 2005 | B1 |
7177350 | Long | Feb 2007 | B1 |
7558315 | Cioffi | Jul 2009 | B2 |
7835431 | Belge | Nov 2010 | B2 |
8199905 | Barrett | Jun 2012 | B1 |
8208604 | Chu | Jun 2012 | B1 |
8509421 | Dollinger | Aug 2013 | B2 |
8855177 | Wilson | Oct 2014 | B1 |
9124723 | Kuipers | Sep 2015 | B2 |
9191496 | Barrett | Nov 2015 | B1 |
9380152 | Joffe | Jun 2016 | B2 |
10530527 | Wilson | Jan 2020 | B1 |
20020110221 | Norrell | Aug 2002 | A1 |
20030112967 | Hausman | Jun 2003 | A1 |
20030198217 | Redfern | Oct 2003 | A1 |
20030223484 | Suzuki | Dec 2003 | A1 |
20030223485 | Noma | Dec 2003 | A1 |
20050123030 | Belge | Jun 2005 | A1 |
20060098725 | Rhee | May 2006 | A1 |
20060193444 | Aufenast | Aug 2006 | A1 |
20060251160 | Fazlollahi | Nov 2006 | A1 |
20090210554 | Schmitt | Aug 2009 | A1 |
20120224674 | Goodson | Sep 2012 | A1 |
20120250492 | Schneider | Oct 2012 | A1 |
20130022178 | Rhee | Jan 2013 | A1 |
20150030138 | Kalavai | Jan 2015 | A1 |
20150085996 | Mohseni | Mar 2015 | A1 |
20150163349 | Ardestani | Jun 2015 | A1 |
20150180596 | Berg | Jun 2015 | A1 |
20160028866 | Ahmadi | Jan 2016 | A1 |
20160191118 | Kalavai | Jun 2016 | A1 |
20160337512 | Kalavai | Nov 2016 | A1 |
20170180549 | Zahedi | Jun 2017 | A1 |
20180027113 | Mohseni | Jan 2018 | A1 |
Entry |
---|
Arlynn Wayne Wilson, U.S. Appl. No. 16/232,904, entitled, “Systems and Methods for Detecting Faults in a Telecommunication System Using Retrain Data,” filed Dec. 26, 2018. |