HK1174752A - A method and a system for cyclic redundancy checksum (crc) anomaly counter normalization, and a module performing the method - Google Patents

Abstract

This invention is related to a method and a system for Cyclic Redundancy Checksum (CRC) anomaly counter normalization, and a module performing the method for reporting of Severely Errored Seconds (SES), used in a consistent manner, across a plurality of connections in a service provider network comprising: in a first transceiver, computing a local CRC octet based on a received bit stream; comparing the local CRC octet to a received CRC octet; identifying a CRC anomaly when the local CRC octet is not identical to the received CRC octet; and normalizing a CRC anomaly counter based on a value for a CRC computation period (PERp), wherein a Severely Errored Second is declared if there are more than N CRC anomalies in a second.

Description

Cyclic redundancy check exception counter normalization method, system and module

The application is a divisional application of an invention patent application with the application date of 23/9/2005, the priority date of 25/9/2004, the application number of 200580008869.X and the invention name of CRC counter normalization, from Aweil corporation.

Data of related applications

This application claims the benefit and priority of U.S. patent application No. 60/613,594 entitled "CRC counter normalization method and system," filed 9/25 2004, according to title 119 (e) of U.S. code, volume 35, which is incorporated herein by reference in its entirety.

Technical Field

The present invention relates generally to communication systems. More particularly, preferred embodiments of the present invention relate to anomaly detection in a communication system.

Background

Cyclic Redundancy Check (CRC) error detection techniques are a conventional method of detecting errors in a data stream transmitted over a communication channel. The ITU (international telecommunications union) g.992.3 standard, incorporated by reference in its entirety, describes in its section 7.7.1.2 CRC operations for ADSL systems. As described in the g.992.3 standard, the transmitter calculates transmitter CRC bits from the transmitted bit stream and transmits the CRC bits to the receiver. The receiver also calculates CRC bits from the received bit stream and compares the locally calculated CRC bits with the received CRC bits transmitted from the transmitter. If the receiver CRC bits and the transmitter CRC bits are the same, the CRC calculation predicts that there are no errors in the received bit stream. But if the received CRC bits are different from the transmitted CRC bits, the CRC calculation indicates that there is an error in the received bit stream.

DSL systems and communication systems typically use CRC errors, also referred to as anomalies, to diagnose and detect problematic service conditions. The CRC anomalies are typically calculated, counted and reported according to some basic assumptions about how often the CRC is calculated. For example, in ADSL systems, such as those described in the G.992.3 standard, the ADSL system is robustA second-error-per-second (SES) is defined as 18 or more CRC anomalies in a 1 second time interval. That is, if the CRC is calculated every 17ms (milliseconds), about 30% of the calculated CRC is erroneous. The g.992.3adsl standard requires that the CRC be calculated every 15-20 ms. In ADSL2 and VDSL2 systems, the period of CRC calculation is referred to as the overhead channel Period (PER)_P). G.992.3 standard requirements: PER is less than or equal to 15ms_P≤20ms。

Disclosure of Invention

Digital subscriber line service providers use CRC anomaly reporting as a way to diagnose and detect problematic service conditions. For example, an ADSL service provider may use SES as a method of detecting a problematic ADSL connection. For example, an ADSL service provider may specify that if an ADSL user experiences more than 30 SES in a 1 minute period, the ADSL connection needs to be repaired. Therefore, it is very important to cover all connection reporting SES in a service provider network in a consistent way.

As described above, if the ADSL system determines the CRC (PER required by the standard) once every 17ms_P) Then a critical error second (SES) is defined as 18 or more CRC anomalies occurring in a 1 second time interval, such that an SES occurs as long as about 30% of the calculated CRCs in the 1 second time interval are erroneous. If, however, the CRC is calculated, for example, every 2ms, and SES is again defined as 18 or more CRC anomalies occurring in a 1 second time interval, then the 18 CRC anomalies will correspond to approximately 3.6% of the calculated CRC being in error. In this way, the service provider may receive a repair alert and dispatch a network technician to repair the connection with only a few errors.

Most communication systems define the CRC operation in a form that limits the CRC computation to a specific and bounded repetition period (repetitiongood) or ratio to provide consistent detection and diagnostic capabilities across all connections in the network, which may be DSL subscriber connections, for example.

New designs and innovations in communication systems make it increasingly difficult to ensure that CRC calculations are defined in the form described above. For example, the g.992.3 standard specifies Seamless Rate Adaptation (SRA) and Dynamic Rate Reallocation (DRR), both of which allow ADSL systems to achieve seamless changes in online data rates. However, SRA and DRR change the data rate without changing the framing parameter. Therefore, PER_PWill vary proportionally with the change in data rate.

For example, a 10% increase in data rate will cause a PER_PThe reduction is 10%. The problem caused is that the PER_PAre allowed to vary only between 15ms-20ms, and thus SRA and DRR are limited to small data rate variations, typically within 10% -15%.

It is generally desirable to achieve a large rate change. Larger data rate variations typically cause PER_PValues outside the range of 10-20 ms. Thus, as previously mentioned, ADSL service providers will encounter problems with diagnostic procedures that detect problematic connections based on CRC anomalies.

New communication systems, such as VDSL, VDSL2 and other higher speed wired and wireless communication systems, provide for data rates that occupy a wide range, for example a range of values starting at a minimum of 500kbps and up to 100mbps or more. For such a large range, it is difficult to design a framing method for all possible data rates that includes a CRC process that limits the CRC computation to a specific and bounded repetition period.

Part of the difficulty stems from the fact that the accuracy of CRC error detection is related to the number of bits in the CRC computation cycle (as the number of bits in the CRC computation cycle increases, the accuracy of CRC error detection decreases). For example, if the CRC calculation is done every 20ms and the data rate is 1mbps, then there will be 20,000 bits in each CRC calculation period.

However, if the data rate is 100mbps and the CRC calculation period is 20ms, there will be 2 million bits in each CRC calculation period. Obviously, the CRC error detection capability will decrease in the latter case. Typically, under normal operating conditions, a one octet (octet) CRC used in DSL systems may provide sufficient error detection if the CRC computation period contains less than ten thousand bits.

Accordingly, one aspect of the present invention relates to calculating and reporting communication errors. More particularly, one aspect of the invention relates to the data rate or CRC calculation period (e.g., PER) associated with each individual connection_PNumerical value) calculates and reports CRC anomalies in a consistent manner for all communication connections in the network.

Further aspects of the invention relate to handling CRC anomalies (errors) in a manner that reports them in a consistent way regardless of data rate or CRC calculation. A preferred aspect of the embodiment defines the process of normalizing the CRC anomaly counter based on the actual CRC computation period.

According to yet another aspect of the present invention, the CRC anomaly counter normalization process is based on a current or actual PER_PThe CRC anomaly counter is numerically normalized.

According to yet another aspect of the invention, a CRC anomaly counter normalization process is applied to a plurality of communication devices in a network based at least on data rate.

According to yet another aspect of the invention, a different CRC anomaly counter normalization process is applied to each of a plurality of communication devices in a network based at least on data rate.

The above and other features and advantages of the present invention will be described or will become apparent in the following description of the embodiments.

Drawings

Embodiments of the invention will now be described with reference to the following drawings, in which:

fig. 1 shows a schematic block diagram of a preferred embodiment of a communication system according to the present invention;

FIG. 2 is a flow diagram of a preferred embodiment of a method of normalizing CRC counters according to the present invention;

FIG. 3 shows in detail a flow chart of a preferred embodiment of a CRC normalization method according to the present invention;

FIG. 4 illustrates another preferred embodiment of normalized CRC normalization according to the present invention; and

fig. 5 shows a schematic block diagram of another preferred embodiment of the communication system according to the invention.

Detailed Description

The preferred embodiments of the present invention are described below by detecting errors in a wired and/or wireless communication environment. It should be understood, however, that the system and method of the present invention may generally work well in any type of communication system in any environment.

Preferred embodiments of the system and method of the present invention will be described below with reference to DSL modems and associated communication hardware, software, and communication channels. However, to avoid unnecessarily obscuring the present invention, the following description omits well-known structures and devices that may be shown in block diagram form or otherwise summarized.

In the following description, for purposes of explanation, numerous details are set forth in order to provide a thorough understanding of the present invention. It should be noted, however, that the present invention can be practiced in a variety of ways beyond the specific details disclosed herein.

Further, while the embodiments disclosed herein show the various components of the system being co-located (collocated), it should be understood that the various components of the system may be located in various portions of a distributed network that are remote from one another, such as a telecommunications network and/or the Internet or within a dedicated protected (secured) system, an unprotected (unsecured) system and/or an encryption system. Thus, it should be appreciated that the components of the system can be incorporated into one or more devices, such as a modem, or collocated on a particular node of a distributed network, such as a telecommunications network. It will be appreciated from the following description that for reasons of computational efficiency, the components of the system may be located anywhere in a distributed network without having any effect on the operation of the system. For example, the various components may be located in a Central Office (CO or ATU-C) modem, in a customer premise modem (CPE or ATU-R), in DSL management equipment, or some combination of the above. Similarly, one or more functional portions of the system may be distributed between the modem and an associated computing device.

Further, it should be understood that the various links connecting these elements, including the communication channel 5, may be wired or wireless links, may be any combination of wired and wireless links, or may be any other known or later developed element capable of providing and/or communicating data to and from the connected elements. The term "module" as used herein may be any known or later developed hardware, software, firmware, or combination thereof that is capable of performing the functionality associated with that element. In addition, in order to simplify notation, in the present specification, the term "PER_P"will be used to represent the CRC calculation period. As used herein, the terms "determine (term), calculate (calculate), and compute (computer)" and variations thereof are used interchangeably and include any type of method, process, mathematical operation, or technique.

One preferred embodiment of the present invention relates to CRC normalization in asymmetric dsl (adsl) services. However, it should generally be understood that the present method may be applied to any one or more communication lines or digital communication lines.

Fig. 1 shows one embodiment of a communication system 10 according to the present invention. It will be appreciated that various functional components of the transceiver are omitted for brevity purposes. It should be understood, however, that both transceivers may also include standard components found in conventional communication devices in which conventional techniques are implemented.

Communication system 10 includes a transceiver 100 and a transceiver 200. The transceiver 100, which is a transmitting transceiver, includes a CRC bit calculation module 110 and a CRC bit transmission module 120. A communication channel 5 interconnects the two transceivers, and as discussed above, the communication channel 5 may be one or more of a wireline and a wireless communication channel. The transceiver 200 includes a CRC bit calculation module 210, a CRC bit reception module 220, a CRC bit comparison module 230, a CRC error counter and reporting module 240, a PER_PA determination module 250, a normalization module 260, a CRC grouping module 270, and a communication parameter module 280.

According to a preferred embodiment, the formula for counting CRC anomalies is:

PER_Pthe number/K of normalized anomalies,

wherein K is any positive integer. For example, if K is 20 and PER_PEach CRC anomaly is counted as 1.25 normalized CRC anomalies, 25. In general, K corresponds to a value equal to an expected CRC computation period from which system diagnostic information is reported. For example, in ADSL and VDSL systems, K may be equal to 15ms, since this value corresponds to approximately 66 CRCs calculated per second. As discussed previously, when more than 18 CRC anomalies occur in a second, a severe error second is reported, which corresponds to approximately 30% of the CRC calculations being in error.

Since CRC anomalies are typically reported as integers, the calculated CRC anomaly count can be rounded to the next larger integer. For example, if PER_P28, then eachThe CRC anomaly was counted as 28/20 ═ 1.4 normalized CRC anomalies. If 23 CRC anomalies are detected over a period of time, the computed CRC anomaly counter may include ceiling (23 x 1.4) ═ ceiling (32.2) ═ 33 normalized CRC anomalies, where ceiling represents rounding up.

In operation, the transceiver 100, which in the preferred embodiment functions as a transmitting transceiver or transmitting modem, calculates CRC bits based on the transmitted bit stream. More specifically, a bit stream is transmitted from the transceiver 100 and the CRC bits calculation module 110 determines CRC bits based on the transmitted bit stream. The number of CRC bits is typically 8 (1 octal), but the number of bits may vary depending on, for example, the particular implementation of the invention. The transceiver 100 and the CRC bits transmission module 120 cooperate to transmit a bit stream along with corresponding calculated CRC bits to the transceiver 200 via the communication channel 5.

The transceiver 200 receives a bit stream transmitted by the transceiver 100 and the CRC bits calculation module 110 determines CRC bits in cooperation with the CRC bits reception module 220, the transceiver 200 also being referred to as a receiving transceiver or receiving modem. The CRC bits calculation module 210 also calculates CRC bits (i.e., local CRC bits) from the received bit stream when the bit stream is received. Having obtained the CRC bits determined by the CRC bits calculation module 110 and the CRC bits calculated by the CRC bits calculation module 210, the CRC bits comparison module 230 performs a comparison therebetween, and when the local CRC bits are not the same as the received CRC bits determined in the transceiver 100, the CRC bits comparison module 110 cooperates with a CRC error counter and reporting module 240 to calculate and determine a CRC anomaly.

Then, PER_PDetermination module 250 determines a CRC calculation Period (PER)_P) The numerical value of (c). The period may be, for example, in seconds or generally any time period suitable for a particular communication environment. The normalization module 260 is based on the PER_PNumerically normalizing the CRC error counter and reporting module 240, wherein the normalization of the CRC error counter 240 comprises incrementing the CRC error counter by a numerical valueM, where the value of M is PER_Pand/K, wherein K is a positive integer.

The communication parameter module 280 monitors communication parameters such as one or more of data rate, forward error correction, interleaving, framing, or any conventional communication parameters and triggers the determination of an updated value for the CRC calculation period when one or more of the above parameters changes. The CRC anomaly counter then uses the updated or another value of the period in a subsequent CRC anomaly count.

In another embodiment, CRC calculation is incorporated into ceiling (K/PER)_P) Multiple groups of CRC calculations, and any number of CRC anomalies in a group is counted as only 1 normalized CRC anomaly, where K is a positive integer. Typically, K corresponds to a value equal to the expected period of CRC computations based on which the system diagnostic information is reported by the CRC error counter and reporting module 240. The CRC computations are grouped in the manner described above to avoid over-counting CRC anomalies, as multiple CRC anomalies occurring in a particular time period (e.g., Kms) may need to be counted as a single normalized CRC anomaly.

Example (c):

k15 ms and PER _P ＝10ms: the CRC calculation is incorporated into the group of ceiling (15/10) ═ 2CRC calculations. The first 2CRC calculations are a first group, the second 2CRC calculations are a second group, and so on. One or more CRC anomalies in a group are counted as 1 normalized CRC anomaly.

K15 ms and PER _P ＝4ms: the CRC calculation is incorporated into the group of ceiling (15/4) ═ 4CRC calculations. The first 4CRC calculations are the first group, the second 4CRC calculations are the second group and so on. One or more CRC anomalies in a group are counted as 1 normalized CRC anomaly.

If the correct CRC calculation is denoted "o" and the incorrect CRC calculation (anomaly) is denoted "x", then for the following CRC calculation flow:

oooxxxooxoxoxxxxoooooxxooxoooooo

if PER_PThen 9 normalized CRC anomalies are counted:

oo ox xx oo xo xo xx xx oo oo ox xo ox oo oo oo

if PER_PThen 6 normalized CRC anomalies are counted:

ooox xxoo xoxo xxxx oooo oxxo oxoo oooo。

it can also be based on other than ceiling (K/PER)_P) Other metrics may group CRC calculations. For example, floor (K/PER) can be used_P) Or 2 ceiling (K/PER)_P). In general, the set of CRC computations may be computed as follows: n ceiling (K/PER)_P) Wherein N and K are positive integers, and wherein floor represents rounding down.

Further, CRC anomalies in a group may be counted as more than 1 normalized CRC anomaly. For example, 1 CRC anomaly in a group may be counted as 1 normalized CRC anomaly. 2-3 CRC anomalies in a group may be counted as 2 normalized CRC anomalies. The 4-6 CRC anomalies in a group may be calculated as 4 normalized CRC anomalies and so on.

In addition, a sliding window may also be used when grouping CRC computations.

In addition, the normalized CRC anomalies may also be re-corrected (scale) by amount based on the duration of the CRC calculation group. For example, if PER_PAt 14ms, the CRC calculation is incorporated into the ceiling (15/14) — 2CRC calculation group. According to the method described above, 1 normalized CRC anomaly is calculated for each group of 2CRC calculations containing at least 1 CRC anomalyOften times. But combining CRC calculations into 2 groups yields a valid CRC calculation period of 2 x 14-28 ms, which exceeds the 20ms requirement in the g.992.3 standard. Thus, as when PER_PFor > 20ms, the CRC anomalies may be rescaled by re-scaling to make the CRC anomaly count more accurate. For example, 1 normalized CRC anomaly may be further regularized and counted as (28)/20 ═ 1.4 normalized CRC anomalies.

More generally, if the duration of the CRC calculation group exceeds the required range (e.g. 20ms as required by ADSL systems in the g.992.3 standard), then:

1 normalized group CRC anomaly [ (duration of CRC group)/K ] normalized CRC anomalies,

wherein K is a positive integer. For example, K may also have a value of 15, 17 or 20, which corresponds to PER in the g.992.3 standard_PLower, middle, and upper bounds in the numerical range.

Using the G.992.3ADSL standard as an example, to solve the problem of CRC group duration greater than 20ms, it is possible for PER_PThe normalized CRC anomaly is determined and further corrected (or normalized) quantitatively:

10＜PER _P ＜15

when PER_PWith values greater than 10 and less than 15, each set of CRC calculations contains 2CRC calculations (based on ceiling (15/PER)_P)). For this range of PERP values, the duration of each CRC group will be greater than 20 ms. For example, if PER_PThe duration of the CRC set is 2 × 12ms — 24 ms. Thus, 2 PER can be used_PK further normalizes or corrects by quantity the normalized CRC calculation, where K is an integer, e.g., equal to 15, 17, or 20.

6.67＜PER _P ＜7.5

When PER_PValues greater than 6.67 and less than 7.5, each group of CRC calculations will contain 3CRC calculations (according to ceiling (15/PER)_P)). For this PER_PThe range of values, the duration of each CRC group will be greater than 20 ms. For example, if PER_PThe duration of the CRC set will be 3 × 7ms — 21 ms. Thus, a further 3 PER may be used_PK further normalizes or corrects by quantity the normalized CRC calculation, where K is an integer, e.g., equal to 15, 17, or 20.

Thus, in one embodiment of the present invention, if PER_PValues between 10-15ms or between 6.67-7.5ms, then the normalized CRC anomaly in ADSL or VDSL2 systems will be further normalized (or corrected by volume).

In another embodiment, PER_PAs the online data rate changes, for example, due to SRA or DRR changes. Thus, the CRC normalization process will be based on the new PER_PThe value is updated, wherein the new PER_PThe value is associated with the updated data rate.

Fig. 2 shows a high-level overall view of a preferred embodiment of CRC normalization according to the present invention. Specifically, control is started at step S200 and continues to step S210. In step S210, a CRC calculation Period (PER) is received or determined_P) Or updated CRC calculation Period (PER)_P). Subsequently, in step S220, a Period (PER) is calculated based on the CRC_P) Or updated CRC calculation Period (PER)_P) Normalizing the CRC error counter. Control then passes to step S230 where the control sequence ends.

Fig. 3 shows a preferred embodiment of CRC normalization in detail. Specifically, control is started at step S300, and proceeds to step S310. At step S310, a transceiver acting as a transmitter determines CRC bits for the transmitted bit stream. The transceiver then transmits the determined CRC bits and bit stream to the receiver at step S320.

At step S330, another transceiver using its receiving function receives the determined CRC bits and bit stream. Next, in step S340, CRC bits (local CRC bits) are determined for the received bit stream. Next, the local CRC bits are compared with CRC bits determined and transmitted by the transmitter at step S350. Control then continues to step S360.

The CRC calculation period is determined at step S360. Next, in step S370, a cycle (PER) is calculated based on the CRC_P) The CRC anomaly counter is normalized. Control then continues to step S380.

In step S380, it is determined whether a CRC error or abnormality occurs. If a CRC error occurs, control continues to step S390, otherwise control jumps to step S395.

In step S390, a CRC error count is generated and an indication of a fatal error second is reported, if appropriate. In addition to reporting fatal error seconds, other actions may be taken after a CRC error is determined. For example, an Error Second (ES) may be reported, where an error second is generally defined as the presence of one or more CRC error events in that second. Alternatively, it may be calculated in other time periods than seconds, for example minutes, hours or time intervals less than seconds.

In step S395, it is determined whether there is a change in the communication parameters. If there is a change in one or more communication parameters, control jumps back to step S300 and the entire process is repeated, wherein another or updated CRC calculation period is determined at step S360. If there is no change in one or more communication parameters, control proceeds to step S399 and the control sequence ends in step S399.

Fig. 4 shows another preferred embodiment of CRC normalization according to the present invention. Wherein control begins in step S400 and continues to step S410. At step S410, a transceiver acting as a transmitter determines CRC bits for a transmitted bit stream. The transceiver then transmits the determined CRC bits and bit stream to the receiver at step S420.

Another transceiver using its receiving function receives the determined CRC bits and bit stream at step S430. Next, in step S440, CRC bits (local CRC bits) are determined for the received bit stream. Next, the local CRC bits are compared with the CRC bits determined and transmitted by the transmitter at step S450. Control then continues to step S460.

In step S460, CRC anomalies are grouped. Next, counting is performed in step S470, and control continues to step S480. In step S480, it is determined whether a fatal error second occurs. If a fatal error second occurs, control continues to step S490.

At step S490, an indication of a fatal wrong second is generated and sent to an appropriate destination or an action is triggered, for example.

At step S495, it is determined whether there is a change in the communication parameters. If there is a change in one or more communication parameters, control jumps back to step S400 and the entire process is repeated, with the updated grouping being performed at step S460. If there is no change in one or more communication parameters, control continues to step S500 and the control sequence ends at step S500.

It should be understood that the particular functions described herein are only illustratively performed in one or more of the transceiver 100 and the transceiver 200, and that some or all of the steps may be performed in any device, which may or may not be co-located in the one or more of the transceiver 100 and the transceiver 200. For example, the PER_pThe functions performed by the determination module and the normalization module may be outsourced to another module, with the normalized values being sent back to and applied to the CRC error counter and reporting module 240. Further, the order of events described herein is for illustration purposes only, and the events may be rearranged as desired.

In particular, FIG. 5 illustrates a CRC normalization management systemA specific embodiment of the present invention. Similar to the communication system 10, the CRC normalization management system includes one or more transceivers 100, each of the transceivers 100 being connected to one or more transceivers 300 through a communication channel. Each transceiver 300 communicates with the CRC management module 500. The CRC management module 500 includes a PER_PA determination module 510, a normalization and/or grouping module 520, and a CRC error counter and reporting module 530. The CRC management module 500 at least allows for normalization and/or grouping of one or more CRC error counts from a centralized location. For example, the CRC bit comparison module 550 sends and indicates a CRC error to the CRC management module 500. Transceiver 300 may also be assisted by the PER_PDetermination module 540 to determine CRC calculation Period (PER)_P) Numerical values and sent. If necessary, the management module and the PER_PDetermination module 510, in cooperation, may also determine a cycle of CRC computations (PER) for each of one or more transceivers 300_P)。

Upon receiving one or more error reports from one or more of the CRC bit comparison modules 550, the normalization/grouping module updates the CRC error counter and reporting module 530 based on the value. Since each transceiver may operate under different communication parameters, the value used to update CRC error counter 550 may be transceiver-specific, applied to a portion of the transceivers or to all of the transceivers. The CRC error counter and reporting module 530 may then output a normalized CRC error count, as previously described. For example, an indication of a severely errored second may be generated and sent to an appropriate destination or trigger a corresponding action, for example.

The above system may be implemented on a wired and/or wireless telecommunication device such as a modem, a multi-carrier modem, a DSL modem, an ADSL modem, an XDSL modem, a VDSL modem, a line card (linecard), a test device, a multi-carrier transceiver, a wired and/or wireless wide area/local area network system, a satellite communication system, a modem with diagnostic capabilities or similar device, or on a separately programmed general purpose computer having a communication device or having a communication protocol comprising: CDSL, ADSL2, ADSL2+, VDSL1, VDSL2, HDSL, DSL rest (DSL Lite), IDSL, RADSL, SDSL, UDSL or similar protocols.

Furthermore, the system, method and protocol of the present invention may be implemented on: a special purpose computer, a programmed microprocessor or microcontroller and peripheral integrated circuit elements, an ASIC or other integrated circuit, a digital signal processor, a hardwired electronic or logic circuit such as a discrete element circuit, a programmable logic device such as a PLD, PLA, FPGA, PAL, a modem, a transmitter/receiver, any comparable device, or the like. In general, any device that can implement a state machine that can implement the methods disclosed herein can be used to implement the various communication methods, protocols, and techniques in accordance with this invention.

Further, the disclosed methods may also be readily implemented in software using object or object-oriented software development environments that provide portable source code that may be used on a variety of computer or workstation platforms. Alternatively, the disclosed system may be implemented partially or fully in hardware using standard logic circuits or VLSI design. The implementation of the system of the present invention in software or hardware is determined by the speed and/or efficiency requirements of the system, the particular function, and the particular software or hardware system or microprocessor or microcomputer system being used. However, the communication systems, methods, and protocols disclosed herein can be implemented by those of ordinary skill in the art using known or later developed systems or structures, devices, and/or software based on the functional descriptions provided herein and conventional knowledge in the computer and telecommunications arts.

In addition, the disclosed methods may be conveniently implemented in software that may be stored on a storage medium, executed on a programmed general purpose computer via a controller and memory, or used in a special purpose computerOn a computer, microprocessor or the like. In the above embodiments, the system and method of the present invention may be implemented on a personal computer such asAnd CGI scripts, may be implemented as resources resident on a server or computer workstation, as processes embedded in a dedicated communication system or communication component, or the like. The present system may also be implemented by physically integrating the system and/or method with a software and/or hardware system, such as the hardware and software systems of a communications transceiver.

Accordingly, the present invention provides a system and method for CRC normalization. While the present invention has been described with reference to certain specific embodiments, many alternatives, modifications, and variations of the present invention will be apparent to those of ordinary skill in the art. Accordingly, all such alternatives, modifications, equivalents and variations are intended to be included within the spirit and scope of the present invention.

Claims (33)

1. A Cyclic Redundancy Check (CRC) anomaly counter normalization method for covering multiple connections in a service provider network reporting critical error seconds (SES) in a consistent manner, the method comprising: in the first transceiver, calculating a local CRC octet from the received bit stream; comparing the local CRC octet to the received CRC octet; determining a CRC exception when the local CRC octet is not the same as the received CRC octet; calculating a Period (PER) from CRC_P) Normalizing the CRC anomaly counter by the value of (a), ifA second of severe error is declared if more than N CRC anomalies occur within one second.

2. The method of claim 1, further comprising, in a second transceiver, calculating CRC bits of the bit stream to be received in the first transceiver.

3. The method of claim 1, further comprising updating the value of the CRC computation period when communication parameters change.

4. The method of claim 2, wherein the first transceiver and the second transceiver each comprise a digital signal processor.

5. The method of claim 2, wherein the first transceiver and the second transceiver are DSL modems.

6. The method of claim 2, wherein the first transceiver and the second transceiver are ADSL modems.

7. The method of claim 2, wherein the first transceiver and the second transceiver are VDSL modems.

8. The method of claim 2, wherein the first transceiver and the second transceiver are multicarrier DSL modems.

9. The method of claim 1, wherein the digital subscriber line service provider uses CRC anomaly reporting as a means of diagnosing and detecting problematic service conditions.

10. The method of claim 1, wherein the first transceiver comprises an ASIC.

11. The method of claim 2, wherein at least one of the first transceiver and the second transceiver is a wireless transceiver.

12. A Cyclic Redundancy Check (CRC) anomaly counter normalization system for reporting critical error seconds (SES) in a consistent manner across multiple connections in a service provider network, the system comprising: a first transceiver that computes local CRC octets from a received bit stream; comparing the local CRC octet to the received CRC octet; determining a CRC exception when the local CRC octet is not the same as the received CRC octet; calculating a Period (PER) from CRC_P) Normalizes the CRC anomaly counter, wherein a fatal error second is declared if more than N CRC anomalies occur within one second.

13. The system of claim 12, further comprising a second transceiver that calculates CRC bits of the bit stream to be received in the first transceiver.

14. The system of claim 12, wherein the value of the CRC calculation period is updated as communication parameters change.

15. The system of claim 13, wherein the first transceiver and the second transceiver each comprise a digital signal processor.

16. The system of claim 13, wherein the first transceiver and the second transceiver are DSL modems.

17. The system of claim 13, wherein the first transceiver and the second transceiver are ADSL modems.

18. The system of claim 13, wherein the first transceiver and the second transceiver are VDSL modems.

19. The system of claim 13, wherein the first transceiver and the second transceiver are multicarrier DSL modems.

20. The system of claim 12 wherein the digital subscriber line service provider uses CRC anomaly reporting as a means of diagnosing and detecting problematic service conditions.

21. The system of claim 12, wherein the first transceiver comprises an ASIC.

22. The system of claim 13, wherein at least one of the first transceiver and the second transceiver is a wireless transceiver.

23. A method of covering multiple connections in a service provider network reporting critical error seconds (SES) in a consistent manner, comprising: receiving a bit stream; calculating local CRC bits from the received bit stream; comparing the CRC bits to the received CRC bits; determining that a CRC is abnormal when the local CRC bits are not the same as the received CRC bits; calculating a Period (PER) from CRC_P) Normalizes the CRC anomaly counter, wherein a fatal error second is declared if more than N CRC anomalies occur within one second.

24. The method of claim 23, wherein the normalizing of the CRC anomaly counter comprises incrementing the CRC anomaly counter by a value M, wherein the value M is equal to PER_Pand/K, wherein K is a positive integer.

25. The method of claim 23, wherein K-20 or 15.

26. The method of claim 23, wherein N equals 18.

27. The method of claim 23, further comprising receiving an alert.

28. The method of claim 23, further comprising dispatching a network technician to repair the connection.

29. The method of claim 23 further comprising communicating SES information to a service provider management system.

30. The method of claim 23, wherein the service provider network uses ADSL 2.

31. The method of claim 23, wherein the service provider network uses VDSL 2.

32. The method of claim 23 wherein the service provider uses a fatal wrong second to detect the DSL connection that is experiencing the problem.

33. A module capable of performing the method of claim 23.