Patent Application
20150189075
The subject matter described herein relates generally to the field of telecommunication, and more particularly to systems and methods for diagnosing and optimizing performance of a digital subscriber line (DSL).
Digital subscriber line (DSL) technologies generally include digital subscriber line equipment and services using packet-based architectures, such as, for example, Asymmetric DSL (ADSL), High-speed DSL (HDSL), Symmetric DSL (SDSL), and/or Very high-speed/Very high-bit-rate DSL (VDSL). Such DSL technologies can provide extremely high bandwidth over a twisted pair line and offers great potential for bandwidth-intensive applications. DSL services in the 30K-30 MHz band are however more dependent on line conditions (for example, the length, quality and environment of the line) than is Plain Old Telephone Service (POTS) operating in the <4K band.
While some loops are in good condition for implementing DSL (for example, having short to moderate lengths with operative micro-filters or splitters correctly installed and with no bridged taps and no bad splices), many loops are not as suitable. For example, loop length varies widely, the wire gauge for a loop may not be consistent over the length of the loop (having two or more different gauges spliced together), micro-filters can be in a fault state (e.g., absent, reversed), and many existing loops have one or more bridged taps (a length of wire pair that is connected to a loop at one end and is unconnected or poorly terminated at the other end).
Because the number of lines may be very great, line service providers typically attempt to provision lines so that a certain minimal level of line performance and stability is achieved in a manner which will require little, if any, further consideration by the provider. Also, in some locations, a DSL services wholesaler provides DSL communication equipment to form an infrastructure for such services and DSL service resellers then sell DSL services (e.g., “Internet access”) delivered over that infrastructure to individual end users. Because the DSL services wholesaler controls the equipment forming the DSL infrastructure and the DSL services reseller maintains a services relationship with the consumers, conflicts may exist between a DSL services wholesaler most interested in protecting the integrity of the infrastructure and a DSL services reseller desiring access and control of the equipment for the sake of managing service quality to their end users.
Whether the services are provided to the end customers by the wholesaler or a reseller service provider, loop impairments on the Customer Premises Equipment (CPE) side of the line, downstream of a network interface device (NID), are typically the responsibility of the customer. Microfilter faults, bridged taps, bad splices, etc. present within home wiring may not be readily deduced from the service provider side nor of particular concern to a service provider where the minimal level of line performance and stability is nonetheless attained.
As performance limiting line issues may often be best identified from the CPE side, systems and techniques capable of identifying loop impairments from the CPE side and deducing their position relative to the NID are advantageous to the customer, a CLEC (Competitive Local Exchange Carrier), or other third party providing a line management service (and who may lack any access to the central office (CO) side).
Embodiments of the present invention are illustrated by way of example, and not by way of limitation, and can be more fully understood with reference to the following detailed description when considered in connection with the figures in which:
The following detailed description of the invention will refer to one or more embodiments of the invention, but is not limited to such embodiments. Rather, the detailed description is intended only to be illustrative. Those skilled in the art will readily appreciate that the detailed description given herein with respect to the Figures is provided for explanatory purposes as the invention extends beyond these limited embodiments.
As used herein, the term “service provider” refers to any of a variety of entities that provide, sell, provision, troubleshoot, and/or maintain communication services and/or communication equipment. Exemplary service providers include a telephone operating company, a cable operating company, a wireless operating company, an internet service provider, or any service that may independently or in conjunction with a broadband communications service provider offer services that diagnose or improve broadband communications services (DSL, DSL services, cable, etc.).
As used herein, the terms “end user,” “subscriber,” and/or “customer” are used interchangeably and all refer to a person, business and/or organization to which communication services and/or equipment are provided by any of a variety of service provider(s). Further, the term “customer premises” refers to the location to which communication services are being provided by a service provider. As an example, where the Public Switched Telephone Network (PSTN) is used to provide DSL services, customer premises are located at, near and/or are associated with the network termination (NT) side of the telephone lines. Exemplary customer premises include a residence or an office building.
Described herein are systems and methods for probing and/or monitoring DSL activity on a line from the CPE side. In embodiments, detected PSTN line states are associated with line data collected to determine a state of a microfilter on the line. The PSTN state, as detected, may be employed to trigger a line probing or a DSL operational data collection event and may be further employed to categorize the collected probe data or operational data in a manner conducive to analysis techniques including line data comparisons.
In embodiments, a line is characterized based on the hierarchical detection scheme 100 illustrated in
At layer 3, in-house faults are further partitioned between microfilter issues and other in-house wire faults including bridged taps and balance issues, such as bad splices and flat wire. In one embodiment, a comparison between active and dry lines is utilized at layer 3. For layer 4, microfilter issues are partitioned into non-conforming microfilter states where the microfilter is not correctly configured, such as at least one of a “null” state where no microfilter is present on the line, a “reversed microfilter” state where a phone side of the microfilter is connected to the line side, and a “faulty” microfilter state where a microfilter is present but not fully operational. For the null microfilter state, a further distinction may be made between a perfected POTS device and a faulty POTS device which degrades DSL service even when the device is “on-hook.” In embodiments, microfilter states are determined based on comparisons with templates associated with a particular microfilter state. The templates may be stored and aggregated from field data collected from other user lines or generated from a model-based template computation.
The line 170A forms a portion of an in-house wiring side of the copper plant 120. The copper plant 120 further comprises out-house wire 122 upstream of the NID 125. The NID 125 interfaces at least the line 170A to the out-house wire 122. The line 170A is therefore “active,” supporting at least POTS service accessible through a POTS device (not illustrated) coupled to the line 170A. In the exemplary embodiment, the line 170A supports POTS and also DSL service, with the DSL service provisioned through a DSL device 115 (e.g., CPE modem) coupled to the line 170A.
Whether the DSL technology is ADSL, HDSL, SDSL, and/or VDSL, the technology is implemented in accordance with an applicable standard such as, for example, the International Telecommunications Union (I.T.U.) standard G.992.1 (a.k.a. G.dmt) for ADSL modems, the I.T.U. standard G.992.3 (a.k.a. G.dmt.bis, or G.adsl2) for ADSL2 modems, I.T.U. standard G.992.5 (a.k.a. G.adsl2plus) for ADSL2+ modems, I.T.U. standard G.993.1 (a.k.a. G.vds1) for VDSL modems, I.T.U. standard G.993.2 for VDSL2 modems, I.T.U. standard G.994.1 (G.hs) for modems implementing handshake, and/or the I.T.U. G.997.1 (a.k.a. G.ploam) standard for management of DSL modems. The DSL device 115 therefore is to implement one or more of these DLS technologies following one or more of these standards.
In the illustrated embodiment, the line analyzer 105 includes at least one line prober 102A, PSTN monitor 104A, and DSL monitor 106A coupled to the line 170A. The line prober 102A may be any device know in the art for sending a test stimulus on the line 170A and measuring a response to the stimulus. In one exemplary embodiment the line prober 102A includes a reflectometry unit, where a predetermined test signal is sent from the line prober 102A, as the test point, onto the line 170A. The line 170A, as coupled to the out-house wire 122, reflects a portion of the signal back to the line prober 102A as the stimulus response. The line prober 102A is then to provide probe data 109A to a line probing controller 108. In addition to collecting the probe data 109A, the line probing controller 108 is further to control the line probing performed by the line prober 102A, for example by triggering a line probing of a particular type based on inputs received from other parts of the system 101.
The PSTN monitor 104A is to monitor PSTN states of the line 170A. In an embodiment, the PSTN monitor 104A is to detect the presence of a Direct Current (DC) voltage on the line 170A. The presence of this “battery” voltage informs the line analyzer 105 that line 170A is “active” and has at least POTS connectivity. In further embodiments, the PSTN monitor 104A is to detect at least one of an on-hook, off-hook, or a ringing state of the line 170A. For each of the on-hook, off-hook and ringing states, a battery voltage remains present, and so detection of these states may be conditioned on the presence of DC voltage. The PSTN monitor 104A may distinguish the off-hook state from the on-hook state through line impedance measurements or DC voltage for example, as well as detect the ringing signal received by the POTS device. As shown in
In embodiments, the DSL monitor 106A is to monitor DSL activity on the line 170A and report out such activity to the line probing controller 108. In an embodiment, the line probing controller 108 is to control the DSL monitor 106A by triggering monitoring/collection of certain protocol information. Triggering of the DSL monitor 106A, may further be in response to the PSTN monitor 104A detecting the line to be in a particular PSTN state. For example, in one exemplary embodiment, where a microfilter state of the line 170A is to be determined, the probing controller 108 may trigger the DSL monitor 106A to collect signal spectrum during each of an on-hook state and off-hook state, as determined by the PSTN monitor 104A and reported to the probing controller 108.
The DSL monitor is configured to collect DSL “operational data” which is data generated by the operation of a DSL device on the line 170A. Such operational data includes the transmitted and/or received signal spectrum of a DSL device on the line 170A as well as DSL management protocol information generated by a DSL device. As one example of an embodiment employing signal spectrum, a received signal spectrum is estimated by: (1) arranging received signal as a sequence of N-sample blocks; (2) applying windowing function to each block; (3) taking Fourier transform of the windowed blocks; and (4) taking average of the Fourier transform outputs over multiple blocks. DSL management protocol information includes, but not limited to, frequency-dependent measured insertion loss, frequency-dependent measured quiet-line or active-line quiet line noise, channel average attenuation measurements (e.g. LATN, SATN), channel bit distributions, channel transmit power levels, time stamps for evaluating mutual effects and absolute time-dependent line conditions, carrier masks (e.g., CARMASK of G.997.1 or similar), and tone-spectral shaping parameters (PSDMASK), reported current data rates, reported maximum attainable data rates, reported error-correction-parity, reported use of trellis codes, HLOG[n], measured channel gain, measured channel phase, inferred data regarding individual users' power levels, operational data regarding individual users' code settings, the frequency/tone index of highest noise change in a recent time interval, the total number of bit-swaps occurring in a recent time interval, the distribution of FEC errors, code violations or errored seconds violations over several successive sub-intervals of a time interval, measured noise power variations, measured peak-to-average power ratio, measured channel logarithmic magnitude, measured quiet-line noise levels, measured active-line noise levels, mean square error per tone, MSE[n], signal-to-noise ratio per tone, SNR[n], count of ATM or other protocol cells, measured higher level protocol-throughput, count of retraining, count of failed synchronization attempts, reported carrier mask, reported tone-shaping parameters, inferred data regarding vectored or matrix channel characterization, echo response, received echo noise, and loop impedance.
Depending on the desired characterization of the line, either or both signal spectrum and protocol information may be utilized. For example, in one embodiment both received signal spectrum and Hlog (directly collected as part of protocol information or derived from other protocol information) are utilized.
In embodiments, the line probing controller 108 is to further control the line prober 102A based on the input from the DSL monitor 106A so as to minimize interference to DSL communication. For example, the line probing controller 108 may trigger the line prober 102A to perform a predetermined “inactive line” reflectometry routine in response to the DSL monitor 106A detecting that there is no DSL activity, or trigger the line prober 102A to perform a predetermined “active line” reflectometry routine in response to the DSL monitor 106A detecting that there is DSL activity. As described further elsewhere herein the “active line” reflectometry routines may be tailored based on the DSL activity detected by the DSL monitor 106A.
The line probing controller 108 is further coupled to resources external to the line analyzer 105 to which line probe and/or monitor data 111 is output and from which line probe and/or monitor control signals 114 are input. In certain embodiments, the system 101 includes a field/call center console 130 through which an interface to the line probing controller 108 is provided. In embodiments, the field/call center console 130 is a handheld or other device including a computing platform executing an application which is to perform one or more of the following: trigger the line prober 102A to probe the line 170A (e.g., as verification following a line repair); configure parameters of a line probing stimulus (e.g., to minimize interference to other communication signals on the line); configure parameters of the PSTN monitor 104A (e.g., to select a particular PSTN state to detect), configure parameters of the DSL monitor 106A (e.g., to select one of ADSL, HDSL, VDSL, etc.); configure parameters of the line probing controller 108 (e.g., to select different lines for probing); relay the probe and/or monitor data 111 (e.g. to a third party line management service); and display detection results (e.g., to a technician making a service call to troubleshoot the CPE).
The system 101 further includes a data analyzer 150 that is to receive the line probe and/or monitor data 111 from the line analyzer 105 (e.g., via the line 170A, or via the field/call center console 130) and/or receive DSL operational data collected by a DSL device on the line 170A. While the data analyzer 150 may be embedded into the line analyzer 105, in the exemplary implementation the data analyzer 150 is remote from the CPE, for example at a CLEC location or another third party location responsible for provisioning the analysis service represented by the data analyzer 150.
In one embodiment the DSL device 115 provides operational data to the data analyzer 150 through a network element management protocols such as the G.997.1 standard specification of the physical layer management for DSL transmission systems based on the clear embedded operation channel (EOC) defined in G.997.1 and G.99x standards. Notably, the DSL device reporting to the data analyzer 150 need not be a modem, but rather merely capable of collecting operational data from the line that is generated through operation of a Digital Subscriber Line (DSL) modem on a channel. Thus, while in certain embodiments, the DSL device reporting to the data analyzer 150 includes a modem, in other embodiments a separate device, such as a DSL signal booster that lacks a modem, collects the operational data generated as a result of show-time operation. In further embodiments, the DSL monitor 106A collects operational data generated as a result of show-time operation.
The data analyzer 150 includes a detector 159 that is to detect a line fault and/or position a line fault relative to the NID 125 as a means of diagnosing line faults from the CPE side. Depending on the embodiment, the detector 159 is to perform the detection, based, on either the collected line probe and/or monitor data 111 or the collected operational data. In certain embodiments, the detector 159 performs detection based on a comparison of the collected data across different PSTN lines states (as determined by the PSTN monitor 104A) and/or based on a comparison of the collected data to fault templates stored in the fault template database 158. As used herein, a database is any collection of data organized for the characterization of the line 170A. The database 158 is to be generated by one or more of: a model-based template computer 156; or a field-based template generator 154.
While the model-based template computer 156 is to compute a simulated or estimated probe response or vector of operational data parameter values for a given hypothetical line configuration, the field-based template generator 154 is to assemble sample templates from line probe and/or monitor data collected from a population of user lines 170 accessible to the data analyzer 150 (e.g., directly through a DSLAM or indirectly through a CO-side database, etc.). The field-data collector 152 is to sample the line probe and/or monitor data available from the field based on verification of a particular line characteristic. For the exemplary embodiment, where the data analyzer 150 is to determine a microfilter state of the line 170A, the fault template database 158 is to comprise templates associating probe data collected from a line in the field associated with a known microfilter state. Field data received by the field-data collector 152 that does not have a known microfilter state may either be discarded or held in abeyance until later time when a verification of the microfilter state is provided from an external source (e.g., a field technician).
The detector 159 is to report out a detection result 160. Depending on the embodiment, one or more devices may utilize the reported detection result 160 to either optimize the line 170A or to identify the line as having a particular estimated characteristic that potentially needs further diagnosis by a customer or field technician. For example, in the system 101, the detection result 160 is output to the line conditioner 110 so that a filter may reconfigure to compensate DSL communication on the line in a manner that better copes with the fault. As further illustrated in
In embodiments, the line analyzer 105 is further coupled additional lines 170N comprising the in-house wire 121. One or more of a line prober, PSTN monitor, and DSL monitor may be coupled to the additional lines 170N to probe the lines and collect probe data, as represented in
Methods performed and techniques employed by the system 101 are now described in reference to the functional components introduced in
The method 201 begins at operation 204 with monitoring of at least the PSTN state of the line. As performance degradation attributable to an improper microfilter state is dependent on the on-hook and off-hook status of a POTS device on the line, it is advantageous for the system 101 to collect and associate any data collected from the line with a particular predetermined/selected PSTN state. For example when a POTS device is in an on-hook state within an ADSL system, the performance degradation attributable to a missing, reversed, or faulty microfilter state is small compared to when the microfilter is correctly-configured. However, when the POTS device is in an off-hook state within PSTN, the downstream data rate can be reduced by 3-6 Mbps due in part to an upstream signal echo that is injected into downstream signals.
In embodiments, operation 204 entails at least one of battery detection, on-hook detection, off-hook detection, and ring detection. In the system 101 (
Following operation 204, the method 201 proceeds to either probe the line to collect probe data at operation 215A or to associate operational data at operation 215B with the PSTN state as determined at operation 204. Each of the operations 215A and 215B are illustrated in dashed line as being distinct types of data collection, and while both may be performed for a given line, they are separately described herein as alternate embodiments for the sake of clarity. Performance of either operation 215A or 215B may be triggered in response to detecting (at operation 204) the line to be in a selected PSTN state (e.g., off-hook). In a further embodiment, either operation 215A or 215B may be triggered in response to detecting the line to be in a particular DSL state. For example operation 215A may be performed in a first manner responsive to the PSTN state being “off-hook” (or “on-hook”) and the DSL state being “inactive” and a second manner responsive to the PSTN state being “off-hook” (or “on-hook”) and the DSL state being “active.” Similarly, show-time operational data may be collected at operation 215B in response to the PSTN state being “off-hook” (or “on-hook”) and the DSL state being “active,” indicating there is operational data being generated by one or more DSL device on the line that can be collected in association with the current PSTN state.
Following the collection of either probe data or operational data, the method 201 proceeds to operation 235 where the collected data is analyzed to estimate the a state for the line that best corresponds with collected data. Operation 235 is, for example, performed by the detector 159 in the system 101 with the line state output as the detection result 160 at operation 245. The method 201 may further be iterated as a means of detecting changes in the line or as a means of detecting more than one line fault. For example, where a first iteration is performed to identify a microfilter state (e.g., further following method 201 illustrated in
Generally, the line reflectometry (or other form of line probing for which the line prober 102A is configured) is to be performed with a probing signal selected to minimize the interference to/from the other communication signals (e.g., PSTN and DSL signals) on the line. The method 202 proceeds based on the DSL activity on the line (e.g., as determined by the DSL monitor 106A). If there is no DSL activity detected, inactive line reflectometry is performed at operation 216. As there is no concern that the probe stimulus will interfere with DSL communication activities on the line, one embodiment of operation 216 entails high pass filtering the probe stimulus to avoid the PSTN band if the PSTN state is off-hook. For a line in a “ringing” PSTN state, virtually any probe signal may be issued at operation 216.
If there is DSL activity detected, active line reflectometry is performed at operation 217. While in some embodiments, active line reflectometry may disrupt DSL communications, one or more techniques may be employed at operation 217 to minimize or avoid such disruption. In a first embodiment, the probe signal is high-pass filtered to avoid the PSTN band and a probe signal is injected over unused frequency tones (e.g., >1 MHz). In another embodiment, the probe signal may be applied during the SYNC symbol period. In another embodiment, the probe signal is high-pass filtered to avoid the PSTN band and the probe signal is injected over a subset of the frequency tones employed by a DSL modem on the line, with the subset being sufficiently small so as to maintain modem connectivity during the active line reflectometry. This technique essentially utilizes the disturb margin available on the line.
In further embodiments, the DSL frequency band used by the DSL modem is divided into a plurality of such frequency tone subsets and the probe signal is sequentially injected within each of the frequency tone subsets to individually disturb each subset at a given time. For example, a first subset may include DMT tones 32-42, a second subset may include tones 42-52, and a third subset may include tones 53-62. The probe data (e.g., reflection data) collected is then aggregated over the tone subsets to generate a reflectometry waveform spanning a plurality of the subsets over at least a portion of the DSL frequency band that would have caused a disruption but for the frequency band division.
In an embodiment, for either operation 216 or 217, the probing includes inducing reflection waveforms within the transition band (e.g., 10 KHz-30 KHz). Such probing is useful in differentiating between the faulty and correctly configured states of a microfilter. While the microfilter is specified to serve as a low pass filter with 60-80 dB suppression at over 30 KHz, in the interest of minimizing cost, a microfilter typically employs an elliptic filter which may be subject to ringing in the transition band. In embodiments where the line probing includes the transition band, an assessment of the transition band ringing may be included in the characterization of the microfilter state.
The method 202 continues at operation 220 where the collected reflectometric data is processed to differentiate microfilter issues from other in-house wiring faults. In one embodiment processing at operation 220 entails filtering of the traces, for example with a 500 KHz cut-off frequency, to reduce effects of short bridge taps. In another embodiment, probe trace data processing includes a comparison to previously collected traces to generate a differential signal. The previously collected traces may include any of: a trace collected from the same active line under test (e.g., line 170A in
In embodiments, multiple probe data sets for a same PSTN state may be processed at operation 220 to generate a statistic of the probe data for subsequent analysis. In other embodiments, the trace processing performed at operation 220 entails taking a difference between probe data collected while the PSTN state of the line is “on-hook” and probe data collected while the PSTN state of the line is “off-hook.” As previously described, comparisons between the off-hook and on-hook state are particularly useful for detection of the null microfilter state (e.g., at layer 4 in
In another embodiment where a probe data trace is collected from a different line collated in the same customer premises (e.g., line prober 102N collecting probe data 109N from the line 170N lacking DSL), a line comparison is performed to subtract out the contribution of in-house wiring topology not related to a microfilter. This comparison is useful for the layer 3 analysis (
Continuing with the description of
Returning to
At operation 236, the line under test (e.g., line 170A) is characterized as having the microfilter state associated with the selected reference template (and also having any of the layer 1, 2, and 4 attributes defined by the best matching template).
A characterization of the microfilter state and/or any other fault attribute is then reported out at operation 245. In embodiments, method 202 is repeated, for example for a PSTN line state newly selected at operation 239 (e.g., “off-hook” where the previous iteration of method 202 was “on-hook,” etc.) to permit the processing operation 220 to determine differences between probe traces across PSTN states. The method 202 may be repeated indefinitely as long as a trigger (e.g., user-initiated command, an indication that the line is malfunctioning in a manner consistent with a microfilter fault, etc.) is satisfied as a means of managing the CPE side of the line.
The probe data collected may be added to the plurality of reference line templates (e.g., fault template database 158) in response to a confirmation that the microfilter on the line does in fact have the characterized microfilter state (e.g., via a technician visit or customer action). In further embodiments, before adding collected probe data as a new reference line template, a determination is made whether the collected probe data will represent a unique template.
At operation 218, first DSL operational data, such as, but not limited to an operational parameter vector including insertion loss and/or received signal spectrum, is collected from the line. Referring back to the system 101 (
A second PSTN state is then selected (e.g., “on-hook” where the first PSTN state was “off-hook”) and upon detection of the second PSTN state at operation 227, second DSL operation data is collected at operation 237 in association with the second PSTN state. Generally, the first and second DSL operational data sets are to include at least some of the same line parameters. For example, in one embodiment both the first and second DSL operational data include at least insertion loss and/or received signal spectrum. At operation 238, first and second DSL operational data is compared, and at operation 242 the line from which the operational data was collected is characterized based on the comparison of the DSL operational data. For example, a null micro-filter state can be detected by noting changes in the operational parameters of the DSL system when the PSTN state changes from on-hook to off-hook, or vice versa, exceed a threshold. In another embodiment, the first and second operational data parameters (such as data rate and rate stability) are compared between on/off hook states to detect a faulty telephone where the parameter varies between the on/off hook states by more than the threshold.
At operation 244, either or both the first DSL operational data and second DSL operation data may be analyzed based on a comparison to the fault templates in substantially the same manner as was described elsewhere herein for probe trace data. For example, referring to
Referring first to
In
If at least one dry line and at least one active line are detected, method 401 then proceeds to operation 411 where a dry line is probed, as previously described. At operation 415, an active line is similarly probed to collect probe data. If no dry line is detected, method 401 may proceed to operation 413 where method 403, illustrated in
At operation 435, a comparison of the collected probe data is made with the assumption that the dry line is co-located with the first line on customer premises. In a first embodiment, a fault detection technique known in the art, or based on the template matching techniques described elsewhere herein in the context of microfilter state detection (but also applicable to other faults) is performed on both the active and dry line. If a fault (e.g., bridged tap, bad splice, etc.) is detected based on the first probe data but the fault is not detected based on the second probe data, the location of the fault is declared at operation 441A to be upstream of the NID (e.g., within in-house wire 121). Conversely, if a fault (e.g., bridged tap, bad splice, etc.) is detected based on the first probe data and the fault is also detected based on the second probe data, at operation 441B, the location of the fault is declared to be downstream of the NID (e.g., within in-house wire 121). Where either one of the in-house or out-house wire is without a line impairment, such direct comparisons between multiple lines (e.g., active and dry line) may locate a detected fault relative to an NID without any actual estimate of the NID location. Such a determination is then reported out at operation 475.
In embodiments where a plurality of characterizations of a fault location relative to an NID are made, performance of the method 401 is supplemented with performance of the method 402 (
In
In embodiments, a distance to the NID is determined. In one such embodiment, an estimated loop length for a dry line is utilized as the estimate for a distance between a probe point (e.g., line prober 102A in
In another embodiment, illustrated by
In one embodiment, a distance between the location of the splice 534 and the probe point is estimated by detecting a change in the ground plane between the shielded transmission line 535 (where the shield is at ground) and the drop wire 533 (having no shield and ground therefore being a much greater distance away). This change in ground plane may be detected based on estimating a location in the line where a common mode impedance changes by more than a threshold.
In accordance with one embodiment, line analyzer 570 includes: a signal generator 505 to inject a common mode signal probe 521 onto a first end of the 550; a signal receiver 510 to measure impedance of the common mode signal probe 521 on the line 550 at the first end; a signal detector 515 to detect an impedance anomaly 522 on the line 550 based on the measured impedance of the common mode signal probe 521. The signal analyzer 520 is to correlate an impedance anomaly 522 on the line 550 to a boundary condition 551 on the line 550. As illustrated by the dashed line box, the signal analyzer 520 may either be remote from the line analyzer 570 (e.g., part of or collocated with the data analyzer 150 at a remote third party location), or embedded in the line analyzer 570.
The line analyzer 570 may be implemented and utilized in any of the forms previously described for the line analyzer 105 (
In accordance with one embodiment, the signal receiver 510 measures the impedance of the common mode signal probe 521 on the line 550 by measuring a reflection coefficient of the common mode signal probe 521 at the first end of the line 550. In such an embodiment, the signal detector 515 detects the impedance anomaly on the line 550 by detecting a change in the impedance of the line 550 based on the measured reflection coefficient.
In one embodiment, the signal detector 515 detects the impedance anomaly on the line 550 by detecting a change in permittivity coincident with a boundary location (e.g., corresponding to the boundary condition 551) separating the unshielded portion 552 of the line 550 from the shielded portion 553 of the line 550. In such an embodiment, a first measured permittivity for the shielded portion 553 of the line 550 is consistent with a shielding material and a second measured permittivity for the unshielded portion 552 of the line 550 is consistent with an air space between a conductor of the line 550 and a ground of the line 550. Such shielding material may be, for example, Polyvinyl chloride (PVC) shielding having a permittivity in the range of approximately 2.5 to 3.0 or may be constructed from alternate shielding material, such as paper which is common in Japan. Permittivity of the air space between a conductor of the line 550 and a ground of the line 550 will typically be measured at approximately 1.0 regardless of whether the air space is a large space between the conductor and a terrestrial ground or a small air space between the conductor and a conduit housing the line 550, for example, in a sub-terrestrial environment.
Returning to
In addition to various hardware components depicted in the figures and described herein, embodiments further include various operations which are described below. The operations described in accordance with such embodiments may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the operations. Alternatively, the operations may be performed by a combination of hardware and software, including software instructions that perform the operations described herein via memory and one or more processors of a computing platform. Embodiments also relate to a system or apparatus for performing the operations herein. The disclosed system or apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, flash, NAND, solid state drives (SSDs), CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing non-transitory electronic instructions, each coupled to a computer system bus.
The exemplary computer system 700 includes a processor 702, a main memory 704 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc., static memory such as flash memory, static random access memory (SRAM), volatile but high-data rate RAM, etc.), and a secondary memory 718 (e.g., a persistent storage device including hard disk drives and persistent data base implementations), which communicate with each other via a bus 730. Main memory 704 includes information and instructions and software program components necessary for performing and executing the functions with respect to the various embodiments of the systems, methods, and line probing, monitoring, and data analysis, as described herein. Detection results 723 may be generated based on, for example, analysis of the line probe and operational data. Collected data and calculations 724 are stored within main memory 704. Detection results 723 may be stored within main memory 704. Main memory 704 and its sub-elements (e.g. 723 and 724) are operable in conjunction with processing logic 726 and/or software 722 and processor 702 to perform the methodologies discussed herein.
Processor 702 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processor 702 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processor 702 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. Processor 702 is configured to execute the processing logic 726 for performing the operations and functionality which is discussed herein.
The computer system 700 may further include one or more network interface cards 708 to communicatively interface the computer system 700 with one or more networks 720 from which information may be collected for analysis. The computer system 700 also may include a user interface 710 (such as a video display unit, a liquid crystal display (LCD), or a cathode ray tube (CRT)), an alphanumeric input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse), and a signal generation device 716 (e.g., an integrated speaker). The computer system 700 may further include peripheral device 736 (e.g., wireless or wired communication devices, memory devices, storage devices, audio processing devices, video processing devices, etc.). The computer system 700 may perform the functions of a line analyzer 705 and/or data analyzer 750 capable interfacing with digital communication lines, monitoring, collecting, analyzing, and reporting information, and initiating, triggering, and executing various line probing and operational data collection events including the execution of commands and instructions to detect conditions and/or characterize conditions on a line, as described elsewhere herein.
The secondary memory 718 may include a non-transitory machine-readable storage medium (or more specifically a non-transitory machine-accessible storage medium) 731 on which is stored one or more sets of instructions (e.g., software 722) embodying any one or more of the methodologies or functions described herein. Software 722 may also reside, or alternatively reside within main memory 704, and may further reside completely or at least partially within the processor 702 during execution thereof by the computer system 700, the main memory 704 and the processor 702 also constituting machine-readable storage media. The software 722 may further be transmitted or received over a network 720 via the network interface card 708.
The above description is illustrative, and not restrictive. For example, while flow diagrams in the figures show a particular order of operations performed by certain embodiments of the invention, it should be understood that such order may not be required (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.). Furthermore, many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. Although the present invention has been described with reference to specific exemplary embodiments, it will be recognized that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US2012/028751 | 3/12/2012 | WO | 00 | 9/10/2014 |
