Digital Subscriber Line (DSL) Communication System with Remote Back-Pressure

The present disclosure extends the flow control in a DSL communication system to include a remote back-pressure flow control within a DSL receiver of the DSL communication system. The remote back-pressure flow control can prevent a DSL transmitter of the DSL communication system from overwhelming the DSL receiver. The remote back-pressure flow control is implemented within a receiving network processor (rx-NP) of the DSL receiver to prevent the DSL transmitter from overwhelming the rx-NP.

BACKGROUND

1. Field of Disclosure

The present disclosure generally relates to flow control within communication system, including a digital subscriber line (DSL) communication system which uses remote back-pressure for flow control.

2. Related Art

Digital subscriber line (DSL) is a technology for bringing high-bandwidth information to a customer premises, such as a home or a business to provide some examples, over ordinary copper telephone lines. A conventional DSL communication system typically includes a DSL transmitter having a transmitting network processor (tx-NP) coupled to a first DSL physical layer (PHY) and a DSL receiver having a receiving network processor (rx-NP) coupled to a second DSL PHY. The conventional DSL communication system can include an asymmetric digital subscriber line (ADSL) system, a very-high-bit-rate digital subscriber line (VDSL) system, and/or a symmetrical high-speed digital subscriber line (SHDSL) system to provide some examples. Conventionally, the tx-NP provides one or more packets of information to the first DSL PHY at a first rate and the first DSL PHY converts the one or more packets of information into a continuous bit stream for transmission to the second DSL PHY at a second rate. Thereafter, the second DSL PHY converts the received bit stream into one or more packets of information for transmission to the rx-NP at a third rate. Conventionally, the first rate, the second rate, and the third rate are different with the first rate being the fastest rate and the second rate being the slowest rate.

Flow control is a process of managing a rate of data transmission between two nodes to prevent a faster node, such as a NP in either the DSL transmitter or DSL receiver, from overwhelming a slower node, such as a DSL PHY in either the DSL transmitter or DSL receiver. In a conventional DSL system, flow control between the NP and the DSL PHY is implemented using a blocking mode, also referred to as back-pressure flow control, for traffic from the NP to the first DSL PHY and by using a non-blocking mode for traffic between the DSL PHYs. In the conventional DSL system, the DSL PHY is assumed to be a bottleneck for traffic, namely, the NP provides its traffic to the DSL PHY at a much higher rate than the DSL PHY can provide its traffic. For example, the NP can provide traffic to the DSL PHY at a rate of 100 Mbps and the DSL PHY can transmit the traffic at a rate of only 15 Mbps to another DSL PHY or a rate of only 60 Mbps to the NP.

The DSL transmitter and the DSL receiver conventionally include a packet interface between their respective NPs and DSL PHYs. A conventional example of this packet interface is described in Recommendation ITU-T G.999.1, entitled “Interface between the link layer and the physical layer for digital subscriber line (DSL) transceivers,” (G.999.1 Standard) which is incorporated herein by reference in its entirety. The G.999.1 Standard defines a conventional point-to-point packet interface between the NP and the DSL PHY when the DSL PHY is supporting multiple DSL lines. In this conventional point-to-point packet interface, the back-pressure flow control between the NP and the DSL PHY is implemented by using a special indication, referred to as an Xon/Xoff signal, that is set by the DSL PHY to indicate that it is capable of receiving a packet, namely Xon, or not capable of receiving the packet, namely Xoff.

In more recent versions of DSL, the DSL PHY can no longer be assumed to be a bottleneck for the traffic, namely the NP provides its traffic to the DSL PHY at a substantially similar rate as the DSL PHY provides its traffic. For example, there are situations where the NP is interfacing with a multi-port DSL device having multiple DSL PHYs. The multi-port DSL device aggregates traffic from multiple DSL lines toward a wide area network (WAN) or a local area network (LAN) via multiple lower rate DSL links. In these situations, a WAN/LAN line rate is considerably lower than an aggregate rate of the multi-port DSL device. Moreover, in a situation where link capacity is shared, such as in a passive optical network (PON), the WAN/LAN line rate fluctuates as a result of dynamic bandwidth allocation by a centralized system, such as an optical line terminal (OLT) in the PON. The new coming DSL standard, G.Fast, is an example where an aggregate data rate of the multi-port DSL device can largely exceed the WAN/LAN line rate.

The present disclosure will now be described with reference to the accompanying drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the reference number.

DETAILED DESCRIPTION OF THE DISCLOSURE

The exemplary embodiments described herein are provided for illustrative purposes, and are not limiting. Other exemplary embodiments are possible, and modifications can be made to the exemplary embodiments within the spirit and scope of the disclosure. Therefore, the Detailed Description is not meant to limit the disclosure. Rather, the scope of the disclosure is defined only in accordance with the following claims and their equivalents.

Embodiments of the disclosure can be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the disclosure can also be implemented as instructions stored on a machine-readable medium, which can be read and executed by one or more processors. A machine-readable medium can include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium can include non-transitory machine-readable mediums such as read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; and others. As another example, the machine-readable medium can include transitory machine-readable medium such as electrical, optical, acoustical, or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.). Further, firmware, software, routines, instructions can be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc.

For purposes of this discussion, the term “module” shall be understood to include at least one of software, firmware, and hardware (such as one or more circuits, microchips, or devices, or any combination thereof), and any combination thereof. In addition, it will be understood that each module can include one, or more than one, component within an actual device, and each component that forms a part of the described module can function either cooperatively or independently of any other component forming a part of the module. Conversely, multiple modules described herein can represent a single component within an actual device. Further, components within a module can be in a single device or distributed among multiple devices in a wired or wireless manner.

Conventional Local Back-Pressure Flow Control within a Conventional Digital Subscriber Line (DSL) Communication System

FIG. 1illustrates a block diagram of a conventional DSL communication system. A conventional DSL communication system100typically includes a conventional DSL transmitter102having a conventional transmitting network processor (tx-NP)104coupled to a conventional DSL physical layer (PHY)106and a conventional DSL receiver108having a conventional receiving network processor (rx-NP)110coupled to a conventional DSL PHY112. The conventional tx-NP104provides one or more packets of information150to the conventional DSL PHY106at a first rate over a conventional gamma-transmission (γ-tx) interface114. The conventional γ-tx interface114represents a conventional point-to-point packet interface between the conventional tx-NP104and the conventional DSL PHY106. This conventional γ-tx interface114is typically implemented in accordance to the G.999.1 Standard but other implementations are possible such as Utopia Level 2 (Utopia L2) interface or a Packet Over SONET Physical Layer (POS-PHY) interface to provide some examples.

The conventional DSL PHY106includes a conventional transmitter transport protocol specific transmission convergence (TPS-TC(TX)) module116, a conventional transmitter re-transmission (RTX(TX)) module118, and a conventional acknowledgement-receiver (ACK(RX)) module120. The conventional TPS-TC(TX) module116converts the one or more packets of information150into a continuous bit stream152for transmission to the conventional RTX(TX) module118over a conventional alpha (α) interface122at a second rate. Conventionally, the second rate is slower than the first rate. The conventional TPS-TC(TX) module116provides the continuous bit stream152over the conventional α interface122at a slower rate than it receives the one or more packets of information150over the conventional γ-tx interface114. The conventional TPS-TC(TX) module116provides conventional local back-pressure flow control to prevent the conventional tx-NP104from overwhelming the conventional DSL PHY106.

The conventional TPS-TC(TX) module116also includes a buffer which in some situations can be overflowed by the one or more packets of information150which results in some of the one or more packets of information150being discarded or lost. To prevent the overflow of the buffer, the conventional TPS-TC(TX) module116provides a flow control signal154over the conventional γ-tx interface114to regulate the flow of the one or more packets of information150over the conventional γ-tx interface114. The flow control signal154can be set to a first state Xon to indicate that the conventional TPS-TC(TX) module116is capable of receiving the one or more packets of information150over the conventional γ-tx interface114or a second state Xoff to indicate that the conventional TPS-TC(TX) module116is not capable of receiving the one or more packets of information150over the conventional γ-tx interface114. The flow control signal154can be set to the second state Xoff when the first rate, when averaged, is higher than the second rate, when averaged, or when retransmission is requested by the conventional DSL receiver108.

The conventional RTX(TX) module118processes the continuous bit stream152to provide one or more re-transmission units (RUs)156. The processing of the conventional RTX(TX) module118can include encapsulating the continuous bit stream152, scrambling the continuous bit stream152, error correcting encoding, such as Reed-Solomon coding or Golay coding to provide some examples, the continuous bit stream152, interleaving the continuous bit stream152, multiplexing the continuous bit stream152with overhead data, or any other processing of the continuous bit stream152as described in the Recommendation ITU-T G.998.4, entitled “Improved impulse noise protection for DSL transceivers,” which is incorporated herein by reference in its entirety. The conventional RTX(TX) module118can modulate the continuous bit stream152onto a carrier wave using any suitable analog or digital modulation technique for transmission to conventional DSL receiver108over a communication link. The suitable analog or digital modulation technique may include amplitude modulation (AM), frequency modulation (FM), phase modulation (PM), phase shift keying (PSK), frequency shift keying (FSK), amplitude shift keying (ASK), quadrature amplitude modulation (QAM), discrete multi-tone (DMT) modulation, orthogonal frequency division multiplexing (OFDM), coded OFDM (COFDM) and/or any other suitable modulation technique that will be apparent to those skilled in the relevant art(s).

The conventional RTX(TX) module118stores the one or more RUs156into a retransmission queue after their transmission for retransmission if needed. The retransmission queue can include a significant amount of buffering to retain a copy of each of the one or more RUs156until its acknowledgement is received from the conventional DSL receiver108. The minimal amount of memory, typically computed in bits, is based on a roundtrip time between the conventional DSL transmitter102and the conventional DSL receiver108. The roundtrip time is equal to a maximum time between transmission of one of the one or more RUs156by the conventional DSL transmitter102and reception of its acknowledgement from the conventional DSL receiver108.

A conventional acknowledgement-receiver (ACK(RX)) module120receives one or more conventional acknowledgment messages158from the conventional DSL receiver108over the communications link. Upon receipt of the one or more conventional acknowledgment messages158, the conventional ACK(RX) module120can indicate to the conventional RTX(TX) module118to remove one or more copies of the one or more RUs156from the retransmission queue which correspond to the one or more conventional acknowledgment messages158. Additionally, the conventional ACK(RX) module120can determine whether re-transmission of the one or more RUs156is needed when acknowledgements that correspond to the one or more RUs156are not received from the conventional DSL receiver108. For example, when acknowledgements that correspond to the one or more RUs156are not received from the conventional DSL receiver108in a certain amount of time, the one or more RUs156are automatically retransmitted.

The conventional DSL PHY112includes a conventional acknowledgement-transmitter (ACK(TX)) module124, a conventional receiver re-transmission (RTX(RX)) module126, and a conventional receiver transport protocol specific transmission convergence (TPS-TC(RX)) module128. The conventional ACK(TX) module124provides the one or more conventional acknowledgment messages158to the conventional DSL transmitter102over the communications link. The conventional ACK(TX) module124can provide the one or more conventional acknowledgment messages158that correspond to the one or more RUs156that are received from the conventional DSL transmitter108.

The conventional RTX(RX) module126processes the one or more RUs156to provide a continuous bit stream160to the TPS-TC(RX)) module128over a conventional beta (β) interface130at a third rate. The processing of the conventional RTX(RX) module126can include de-encapsulating the one or more RUs156, error correcting, and/or decoding the one or more RUs156, de-interleaving the one or more RUs156, demultiplexing the overhead data from the one or more RUs156or any other processing of the one or more RUs156as described in the Recommendation ITU-T G.998.4, entitled “Improved impulse noise protection for DSL transceivers,” which is incorporated herein by reference in its entirety. The conventional RTX(RX) module126can demodulate the one or more RUs156using any suitable analog or digital demodulation technique. The suitable analog or digital modulation technique may include amplitude modulation (AM), frequency modulation (FM), phase modulation (PM), phase shift keying (PSK), frequency shift keying (FSK), amplitude shift keying (ASK), quadrature amplitude modulation (QAM), discrete multi-tone (DMT) modulation, orthogonal frequency division multiplexing (OFDM), coded OFDM (COFDM) and/or any other suitable modulation technique that will be apparent to those skilled in the relevant art(s).

The conventional TPS-TC(RX) module128converts the continuous bit stream160into one or more recovered packets162for transmission to the conventional rx-NP110over a conventional gamma-reception (γ-rx) interface126at a fourth rate. The conventional γ-rx interface126represents a conventional point-to-point packet interface between the conventional rx-NP110and the conventional DSL PHY112. This conventional γ-rx interface126is typically implemented in accordance to the G.999.1 Standard but other implementations are possible such as a Utopia L2 interface or a POS-PHY interface to provide some examples.

In more recent versions of DSL, the conventional DSL PHY106can no longer be assumed to be the bottleneck for the traffic, namely the first rate at which the conventional tx-NP104provides the one or more packets of information150to the conventional TPS-TC(TX) module116is substantially similar to the second rate at which conventional TPS-TC(TX) module116provides the continuous bit stream152to the conventional RTX(TX) module118. Rather, bottlenecks, if any, can occur at the conventional rx-NP110in the conventional DSL receiver108in these more recent versions of DSL. For example, in these more recent versions of DSL, the conventional DSL PHY106is often implemented as part of a conventional multi-port DSL transmitting device having multiple conventional DSL PHYs106. This conventional multi-port DSL transmitting device provides RUs, which include the one or more RUs156, to a conventional multi-port DSL receiving device, having multiple conventional DSL PHYs112, at a high data rate using multiple lower rate DSL links. Thereafter, the multiple conventional DSL PHYs112provide the RUs to the conventional rx-NP110. Often times, this high data rate is faster than a low data rate that the conventional rx-NP110provides one or more packets to communication devices or networks, such as a LAN or a WAN to provide some examples, coupled to the conventional DSL receiver108. As a result, the conventional local back-pressure flow control provided by the conventional TPS-TC(TX) modules116of each of the multiple conventional DSL PHYs106may no longer be adequate to prevent the multi-port DSL transmitting device from overwhelming the conventional multi-port DSL receiving device.

Overview

The present disclosure extends the flow control in a DSL communication system to include a remote back-pressure flow control within a DSL receiver of the DSL communication system. The remote back-pressure flow control can prevent a DSL transmitter of the DSL communication system from overwhelming the DSL receiver. The remote back-pressure flow control can be implemented within a receiving network processor (rx-NP) of the DSL receiver to prevent the DSL transmitter from overwhelming the rx-NP.

Exemplary Digital Subscriber Line (DSL) Communication System

FIG. 2illustrates a block diagram of an exemplary point-to-multipoint DSL communication system according to an embodiment of the present disclosure. A communications system200facilitates bi-directional communication of information, such as video, audio, and/or data to provide some examples, between a cabinet202and customer premises204.1through204.nvia a communication network206, such as a fiber optic network, a coaxial cable network, or a hybrid fiber coaxial (HFC) cable network to provide some examples. The cabinet202and the customer premises204.1through204.ncommunicate with each other using a bi-directional transfer of packet-based traffic, such re-transmission units (RUs) to provide an example. The cabinet202operates as an interface between the communication network206and a packet switched network208to transfer IP packets received from the customer premises204.1through204.nto the packet switched network208and to transfer IP packets received from the packet switched network208to the customer premises204.1through204.n.

The cabinet202includes a DSL transceiver having a DSL transmitter for communicating information in the downstream to the customer premises204.1through204.nvia the communication network206. As used herein, the term “downstream” refers to the transfer of information in a first direction from the cabinet202to the customer premises204.1through204.n. The term “upstream” refers to the transfer of information in a second direction from the customer premises204.1through204.nto the cabinet202. The DSL transceiver of the cabinet202also includes a DSL receiver for receiving information from the customer premises204.1through204.nvia the communication network206. Similarly, each of the customer premises204.1through204.ninclude a DSL transceiver having a DSL transmitter for communicating information in the upstream to the cabinet202via the communication network206. The DSL transceiver of each of the customer premises204.1through204.nalso includes a DSL receiver for receiving information from the cabinet202via the communication network206.

In an exemplary embodiment, the cabinet202is implemented as part of a multi-port DSL transceiver having multiple DSL transmitters for communicating information in the downstream to the customer premises204.1through204.nat a high data rate using multiple lower rate DSL links. The multi-port DSL transceiver can include multiple DSL receivers for receiving information from the customer premises204.1through204.nin the upstream at the high data rate using the multiple lower rate DSL links. The multiple DSL receivers provide upstream information from the customer premises204.1through204.n.to the packet switched network208at a rate that is slower than a rate at which the customer premises204.1through204.ncommunicate the upstream information to cabinet202. This slower rate can cause one or more bottlenecks within the cabinet202. The cabinet202include remote back-pressure flow controls to prevent the cabinet202from being overwhelmed by the customer premises204.1through204.n.

Exemplary Customer Premises within the DSL Communication System

FIG. 3illustrates an exemplary customer premises that can be implemented within the DSL communication system according to an exemplary embodiment of the present disclosure. A customer premise300includes a DSL transceiver302for communicating information, such as video, audio, and/or data, between a cabinet, such as the cabinet202to provide an example, and a customer premise304, such as one or more of the customer premises204.1through204.nto provide an example, over a communication network306.

As shown inFIG. 3, the communication network306carries the information between the cabinet and the DSL transceiver302at the customer premise304. The DSL transceiver302converts downstream communication signals from the cabinet to communication signals for the customer premise304and/or communication signals from the customer premise304to upstream communication signals for the cabinet. One or more electrical communication cables308, such as one or more copper communication cables and/or one or more coaxial communication cables to provide some examples, couple the DSL transceiver302to DSL adapters310through316. Although the DSL adapters310through316are shown as separate devices inFIG. 3, those skilled in the relevant art(s) will recognize that the DSL adapters310through316may be implemented into other hardware, such as the DSL transceiver302to provide an example, without departing from the spirit and scope of the present disclosure.

The DSL adapters310through316provide television, internet data, and/or other services to various consumer electronics and/or home networking devices within various rooms318through324of the customer premise304. It should be noted that the number of rooms and/or DSL adapters as shown inFIG. 3are for illustrative purposes only, those skilled in the relevant art(s) will recognize that a different number of rooms and/or DSL adapters may be within the customer premise304without departing from the spirit and scope of the present disclosure. The DSL adapter310within the room318couples to a set top box326and a wireless router328, which in turn, provides wireless access to a portable computer330. Similarly, the DSL adapter312within the room320couples to a video game console332and a television334to provide wireless access to the video game console332and the television334. Likewise, the DSL adapter314within the room322and the DSL adapter316within the room324couple to a personal computer336and a personal computer338, respectively. The DSL adapters310through316are configured and arranged to form a home network allowing the set top box326, the wireless router328, the portable computer330, the video game console332, the television334, the personal computer336, and/or the personal computer338to communicate amongst themselves as well as with the cabinet via the DSL transceiver302. It should be noted that the consumer electronics and/or home networking devices within the customer premise304as shown inFIG. 3is for illustrative purposes only, those skilled in the relevant art(s) will recognize that other communication devices and/or networks may be within the customer premise304without departing from the spirit and scope of the present disclosure.

The DSL transceiver302provides upstream information from the DSL adapters310through316at a rate that is faster than a rate at which the cabinet communicates the upstream information to a communication network, such as the packet switched network208to provide an example. This difference in rates can overwhelm the cabinet causing a bottleneck. For example, the DSL transceiver302can be implemented as part of a multi-port DSL transceiver having multiple DSL transmitters for communicating the upstream information to the cabinet at a high data rate using multiple lower rate DSL links. In this example, the cabinet can include multiple DSL receivers for receiving information from the DSL transceiver302in the upstream at the high data rate using the multiple lower rate DSL links. The multiple DSL receivers can provide upstream information from the DSL transceiver302to the communication network at a rate that is slower than a rate at which the DSL transceiver302communicates the upstream information to cabinet. This slower rate can cause one or more bottlenecks within the cabinet202which can overwhelm the cabinet causing the bottleneck. During the bottleneck, the cabinet can no longer store the upstream information which results in some of the upstream information being discarded or lost. The cabinet includes a remote back-pressure flow control to prevent the bottleneck.

Remote Back-Pressure Flow Control within the DSL Communication System

FIG. 4illustrates a block diagram of a first DSL communication system having remote back-pressure flow control according to an exemplary embodiment of the present disclosure. A DSL communication system400typically includes a DSL transmitter402having a transmitting network processor (tx-NP)404coupled to a DSL physical layer (PHY)406and a DSL receiver408having a receiving network processor (rx-NP)410coupled to a DSL PHY412. The DSL transmitter402can be implemented within a first DSL transceiver located at a customer premises, such as one of the customer premises204.1through204.nto provide an example, and the DSL receiver408can be implemented within a second DSL transceiver located at a at a cabinet, such as the cabinet202to provide an example, or the DSL transmitter402can be implemented within the second DSL transceiver located at the cabinet and the DSL receiver408can be implemented within the first DSL transceiver located at the customer premises. The first DSL transceiver and the second DSL transceiver create a digital subscriber line or DSL. The DSL communication system400shares some substantially similar features with the conventional DSL communication system100; therefore, only differences between the conventional DSL communication system100and the DSL communication system400are to be discussed in further detail.

The tx-NP404provides one or more packets of information150to the DSL PHY406at a first rate over a gamma-transmission (γ-tx) interface414. The γ-tx interface414represents a point-to-point packet interface between the tx-NP404and the DSL PHY406. This γ-tx interface414is typically implemented in accordance to the G.999.1 Standard but other implementations are possible such as Utopia Level 2 (Utopia L2) interface or a Packet Over SONET Physical Layer (POS-PHY) interface to provide some examples.

The DSL PHY406includes the conventional RTX(TX) module118, a transmitter transport protocol specific transmission convergence (TPS-TC(TX)) module416, and an acknowledgement-receiver (ACK(RX)) module422. The TPS-TC(TX) module416converts the one or more packets of information150into the continuous bit stream152for transmission to the conventional RTX(TX) module118over an alpha (a) interface424at a second rate. The TPS-TC(TX) module416provides local back-pressure flow control to prevent the tx-NP404from overwhelming the DSL PHY406in a substantially similar manner as the conventional TPS-TC(TX) module116.

The DSL PHY412includes the conventional RTX(RX) module126, the conventional TPS-TC(RX)) module128, and an acknowledgement-transmitter (ACK(TX)) module420. The conventional RTX(RX) module126processes the one or more RUs156to provide the continuous bit stream160to the TPS-TC(RX)) module128over a beta (3) interface430at the third rate. The conventional TPS-TC(RX) module128converts the continuous bit stream160into one or more recovered packets162for transmission to the rx-NP410over a gamma-reception (γ-rx) interface426at the fourth rate. The γ-rx interface426represents a point-to-point packet interface between the rx-NP410and the DSL PHY412. This γ-rx interface426is typically implemented in accordance to the G.999.1 Standard but other implementations are possible such as a Utopia L2 interface or a POS-PHY interface to provide some examples.

The rx-NP410receives the one or more packets of information162from the DSL PHY412at the fourth rate over the γ-rx interface426. When the DSL receiver408implemented within the cabinet, the rx-NP410provides the one or more packets of information162to various networks, such as the packet switched network208to provide an example. Otherwise, when the DSL receiver408implemented within the customer premises, the rx-NP410provides the one or more packets of information162to various communication devices, such as the DSL adapters310through316to provide some examples. The rx-NP410116also includes one or more buffers which in some situations can be overflowed by the one or more packets of information150which results in some of the one or more packets of information150being discarded or lost. For example, a rate at which the rx-NP410provides the one or more packets of information162to the various communication devices and/or the networks is slower than a rate at which the conventional RTX(TX) module118provides the one or more RUs156to the conventional RTX(RX)) module126. In this example, this faster rate of the conventional RTX(TX) module can overflow the one or more buffers. To prevent the overflow of the one or more buffers, the rx-NP410provides a flow control information450over the γ-rx interface426to regulate the flow of the one or more packets of information150over the γ-tx interface414. The flow control information450can be set to a first state Xon to indicate that the rx-NP410is capable of receiving the one or more RUs156from the conventional RTX(TX) module118or a second state Xoff to indicate that rx-NP410is not capable of receiving the one or more RUs156from the conventional RTX(TX) module118. The flow control information450can be set to the second state Xoff when the rate, when averaged, at which the conventional RTX(TX) module118provides the one or more RUs156is higher than the rate, when averaged, at which the rx-NP410provides the one or more packets of information162. Alternatively, the flow control information450can indicate an amount of information, typically in bytes, that can be transferred to the rx-NP410without overflowing the one or more buffers.

An acknowledgement-transmitter ACK(TX) module420provides one or more acknowledgment messages452to the DSL transmitter402over the communications link. The one or more acknowledgment messages452includes the one or more conventional acknowledgment messages158that correspond to the one or more RUs156that are received from the DSL transmitter408and the flow control information450. For example, a format of the one or one or more conventional acknowledgment messages158can be extended to include a field, typically a bit, for the flow control information450to form the one or more acknowledgment messages452. In this example, the bit can be set to a first value to indicate that the rx-NP410is capable of receiving the one or more RUs156from the conventional RTX(TX) module118or to a second value when the rx-NP410is not capable of receiving the one or more RUs156from the conventional RTX(TX) module118.

An acknowledgement-receiver (ACK(RX)) module422receives the one or more acknowledgment messages452from the DSL receiver408over the communications link. Upon receipt of the one or more acknowledgment messages452, the ACK(RX) module422can indicate to the RTX(TX) module118to remove one or more copies of the one or more RUs156from the retransmission queue and determine whether re-transmission of the one or more RUs156is needed in a substantially similar manner as the conventional ACK(RX) module140.

Additionally, the ACK(RX)) module422can provide the flow control information450as flow control information454to the tx-NP404over the γ-tx interface414and/or the TPS-TC(TX) module416over the α interface424. When the flow control information454is in the first state Xon to indicate that the rx-NP410is capable of receiving the one or more RUs156, the tx-NP404can continue to provide the one or more packets of information150over the γ-tx interface414and/or the TPS-TC(TX) module416can continue to provide the continuous bit stream152over the α interface424. Otherwise, when the flow control information454is in the second state Xoff to indicate that the rx-NP410is not capable of receiving the one or more RUs156, the tx-NP404can cease to provide the one or more packets of information150over the γ-tx interface414and/or the TPS-TC(TX) module416can cease to provide the continuous bit stream152over the α interface424. When the flow control information454is in the second state, the tx-NP404can store the one or more packets of information150and/or the TPS-TC(TX) module416can store the continuous bit stream152.

In some situations, the one or more acknowledgment messages452can be corrupted or expected and not received by the ACK(RX)) module422. In these situations, the ACK(RX)) module422provides the flow control information454in the second state Xoff. This is consistent with the re-transmission function of the TPS-TC(TX) module416because if the one or more acknowledgment messages452are not received or otherwise corrupted, one of the one or more RUs156whose acknowledgment message is not received or otherwise corrupted is re-transmitted. As a result, no new information will be requested from tx-NP404for transmission to the rx-NP408.

FIG. 5illustrates a block diagram of a second DSL communication system having remote back-pressure flow control according to an exemplary embodiment of the present disclosure. A DSL communication system500typically includes the DSL transmitter402having the tx-NP404coupled to the DSL PHY406and a DSL receiver502having the rx-NP410coupled to a DSL PHY504. The DSL transmitter402can be implemented within a first DSL transceiver located at a customer premises, such as one of the customer premises204.1through204.nto provide an example, and the DSL receiver502can be implemented within a second DSL transceiver located at a at a cabinet, such as the cabinet202to provide an example, or the DSL transmitter402can be implemented within the second DSL transceiver located at the cabinet and the DSL receiver502can be implemented within the first DSL transceiver located at the customer premises. The first DSL transceiver and the second DSL transceiver create a digital subscriber line or DSL. The DSL communication system500shares some substantially similar features with the conventional DSL communication system100and the DSL communication system400; therefore, only differences between the DSL communication system500and the conventional DSL communication system100and the DSL communication system400are to be discussed in further detail.

The DSL PHY504includes the conventional TPS-TC(RX) module128, the ACK(TX) module420, and a receiver re-transmission (RTX(RX)) module506. The RTX(RX) module506includes a memory, or buffer,508. In an exemplary embodiment, the memory508stores the one or more RUs156that are currently being provided by the conventional RTX(TX) module118when the rx-NP410switches the flow control information450from the first state Xon to the second state Xoff. This allows the tx-NP404to complete its processing of existing information received from various communication devices and/or networks, the TPS-TC(TX) module416to complete its processing of the one or more packets of information150, and/or the conventional RTX(TX) module118to complete its processing of the continuous bit stream152. Once the second state Xoff is detected, the RTX(RX) module506can release the one or more RUs156that are transmitted in one round trip between the DSL transmitter402and the DSL receiver502to the TPS-TC(RX) module128over the beta (β) interface430. After the release of these one or more RUs156, the RTX(RX) module506stores the one or more RUs156into the memory508until the flow control information450is set to the first state Xon. In another exemplary embodiment, as soon as the rx-NP410switches the flow control information450from the first state Xon to the second state Xoff, the RTX(RX)) module506no longer provides the continuous bit stream160over the γ interface430. The memory508begins to store or buffer the one or more RUs156. Once the memory508is at maximum capacity, the one or more RUs156are disregarded and a request for re-transmission is sent to the DSL transmitter402. A special indication within the one or more acknowledgment messages452can be used to distinguish these disregarded RUs from other RUs that are received in error by the RTX(RX) module506.

CONCLUSION