WO2002063917A2

WO2002063917A2 - Parameter negotiation techniques for vdsl scm system

Info

Publication number: WO2002063917A2
Application number: PCT/US2002/002320
Authority: WO
Inventors: Guozhu Long; Farrokh Rashid-Farrokhi; Syed A. Abbas
Original assignee: Centillium Communications, Inc.
Priority date: 2001-02-02
Filing date: 2002-01-25
Publication date: 2002-08-15
Also published as: AU2002243688A1; WO2002063917A3

Abstract

Efficient parameter negotiation techniques for communication systems, such as VDSL SCM systems, are disclosed.

Description

Parameter Negotiation Techniques for VDSL SCM Systems

RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application No. 60/266,095, filed February 2, 2001 and U.S. application No. 09/966,797 filed September 27, 2001.

FIELD OF THE INVENTION

[0002] The invention relates to telecommunications, and more particularly, to parameter negotiation techniques for very-high-bit-rate digital subscriber line communication systems employing single-carrier modulation technology.

BACKGROUND OF THE INVENTION

[0003] The American National Standards Institute (ANSI) standards group T1E1.4 is developing an industry standard for very-high-bit-rate digital subscriber line (VDSL) technology. This standard is herein incorporated by reference in its entirety. One section of the standard proposes requirements for satisfactory transmission between a transceiver pair when both transceivers utilize single-carrier modulation (SCM) technology. Characteristics such as coding, modulation, mapping, maintenance, link activation and related management functions of the physical media-specific (PMS) and physical media dependent (PMD) parts of the transmission convergence (TC) sublayers of SCM based transceivers are described by the standard.

[0004] In the transmit direction of a VDSL SCM transceiver, input frames come from the PMS-TC. Each frame is split into two streams. Each stream is encoded, modulated and sent onto the transmission line. Each data stream is transmitted in a separate frequency band that is defined by a corresponding band-pass filter. The data signal is transmitted by modulating a sine wave (called a carrier) whose frequency lies in the corresponding frequency band. Up to two carriers can be transmitted in both upstream and downstream directions. In the receive direction of a VDSL SCM transceiver, the carriers received in both bands are demodulated, decoded and multiplexed into output frames having the same structure as their corresponding input frames. Each output frame is sent to the PMS-TC. A frequency division duplexing scheme is used to separate the upstream and downstream directions. Decoupling between the transmit and receive signals is provided by band-pass filters and diplexer technology.

[0005] In each frequency band, values for transmission parameters such as symbol rate, constellation size, center frequency, transmit power spectral density level, interleaving depth and frame format may be chosen from a large set of possible values. The central office VDSL SCM transceiver (referred to as VTU-O) sends a set of transmission parameters (e.g., symbol rate and center frequency for each sub-band) to the remote VDSL SCM transceiver (referred to as VTU-O) by way of a command-type message request. The VTU-R can either reject the received set of transmission parameters by responding with an unable-to-comply message thereby indicating that one or more of the transmission parameters is unacceptable, or can accept the received set of transmission parameters by responding with an echo-type message. Note, however, that the VTU-R has no way of guiding or otherwise facilitating the selection of a suitable set of transmission parameters. Rather, the VTU-R can only reject or accept the set of transmission parameters submitted by the VTU-O. Thus, finding an acceptable set of transmission parameters is essentially a hit or miss proposition that may require several iterations before the VTU-R is satisfied and the communication link can be activated.

[0006] This situation is exacerbated when the VTU-O is unaware of the capability of the VTU-R and the downstream channel characteristics. In such a case, the downstream set of transmission parameters that the VTU-O sends to VTU-R may be less than optimal due to factors such as channel configuration, crosstalk and radio frequency interference. Also, although there are numerous parameter combinations to choose from, the VTU-R is typically configured to implement only a subset of all possible combinations so as to simplify the transceiver design. As a result, the VTU-R may not be able to support the set of transmission parameters requested by the VTU-O. If the VTU-R rejects the set of transmission parameters it receives from the VTU-O, the VTU-O remains uneducated as to why the set of transmission parameters was unacceptable or how to improve that set accordingly. Thus, the difficulty of selecting an appropriate set of transmission parameters is increased. [0007] In addition to blind activation procedures between the VTU-O and the VTU- R regarding the selection of an optimal set of transmission parameters, there is a decision that must be made regarding the type of modulation used for transmission. More specifically, the proposed VDSL SCM standard transmitter can use either QAM (quadrature amplitude) or CAP (carrierless amplitude and phase) modulation. In this case, the receiver (whether upstream or downstream) has to blindly identify which type of modulation the remote transmitter is using, and then use the appropriate receiver structure. Although it is possible for the receiver to blindly identify the type of modulation being used, such identification unnecessarily complicates the receiver design and increases implementation costs.

[0008] There is a need, therefore, for techniques that facilitate selection of an optimal set of transmission parameters and allow identification of the modulation scheme employed by a VDSL SCM System. In a more general sense, there is a need for more efficient parameter negotiation techniques for VDSL SCM Systems.

SUMMARY OF THE INVENTION

[0009] One embodiment of the present invention provides a method for negotiating a set of transmission parameters for a particular transceiver-transceiver pair. The method includes sending a request message specifying a set of proposed transmission parameters, and receiving a reply message responsive to the request message. In response to the reply message indicating the set of proposed transmission parameters is unacceptable, the method further includes interrogating acceptable transmission parameters indicated in the reply message. A new request message specifying a new set of proposed transmission parameters based on the acceptable transmission parameters indicated in the reply message is sent.

[0010] In an alternative embodiment, the method includes receiving a request message specifying a set of proposed transmission parameters. In response to the set of proposed transmission parameters being unacceptable, the method includes sending a reply message specifying acceptable transmission parameters, and receiving a new request message specifying a new set of transmission parameters based on the acceptable transmission parameters included in the reply message. Thus, the present invention can be employed in either the transmitter or the receiver of a communicating transmitter-receiver pair. [0011] Another embodiment of the present invention provides a method for establishing a modulation scheme for newly coupled transceivers included in a transceiver-transceiver pair. The method includes initiating a messaging session to effect preliminary communication between the transceivers, and sending a modulation selection message from one transceiver to the other transceiver specifying a particular modulation scheme to be used by the other transceiver. The method further includes implementing a structure associated with the specified modulation scheme in the other transceiver before data mode is entered. Thus, blind identification of the modulation scheme to be used is eliminated.

[0012] Another embodiment of the present invention provides a modem. The modem includes a management module that generally provides operation and management functions of the modem. The modem further includes a transmission parameter mux operatively coupled to the management module and a slow latency path of the modem. The transmission parameter mux is adapted to multiplex transmission parameter information with the slow latency path.

[0013] The features and advantages described in the specification are not all inclusive and, in particular, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and not to limit the scope of the inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 is a block diagram of the PMS-TC sublayer functional model for a VDSL SCM modem adapted to operate in accordance with one embodiment of the present invention.

[0015] Figure 2 is a flow chart illustrating a method for negotiating a set of transmission parameters suitable to a particular transceiver-transceiver pair in accordance with one embodiment of the present invention.

[0016] Figure 3 is a flow chart illustrating a method for negotiating a set of transmission parameters suitable to a particular transceiver-transceiver pair in accordance with another embodiment of the present invention. [0017] Figure 4 is a flow chart illustrating a method for establishing a modulation scheme suitable to a particular transceiver-transceiver pair in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0018] Figure 1 is a block diagram of the PMS-TC sublayer functional model for a VDSL SCM modem adapted to operate in accordance with one embodiment of the present invention. The PMS-TC sublayer shown includes a transmission parameter multiplexor (STP Mux) 103, scramblers 105, forward error correction (FEC) modules 110, interleaver module 115, header multiplexor (Mux) 120, management module 125, and multiplexor 130. Note that the fast and the slow latency paths have an application independent format at the transport protocol specific transmission convergence (TPS- TC) sublayer interface.

General Overview

[0019] The management module 125, which further includes processor 125a and memory 125b, generally provides operation and management functions corresponding to the PMS-TC. Header mux 120 multiplexes control and management information. The multiplexed control and management information is randomized by scrambler 105 and forms a header along with a syncword used for frame alignment. Each transmission frame output to the PMD sublayer interface is multiplexed from slow data, fast data, and a header. Data of both the fast and slow channels received from the TPS-TC interface is randomized by scramblers 105, subjected to encoding (e.g., Reed Solomon) by FEC modules 110, and multiplexed into transmission frames by multiplexor 130.

[0020] The slow latency path protection further provides interleaving with interleaver module 115. A dual latency mode is provided assuming that both the fast and slow latency paths are implemented. A single latency mode, however, may be provided also (e.g., only the slow channel is implemented). Note that the latency mode can be different in the upstream and downstream directions. The latency mode employed and transport capabilities of the corresponding channels can be set during the system configuration. Each of the STP mux 103, scramblers 105, FEC modules 110, interleaver module 115, and multiplexor 130 also provide respective complementary functions of descrambling, decoding, deinterleaving and demultiplexing of data received from the PMD sublayer interface.

[0021] In addition, the slow latency path includes STP mux 103 for multiplexing transmission parameter information into the slow channel codeword. Note that the transmission parameter information may be received, for example, by STP mux 103 from the operations and management entity, or from the management module 125. Memory 125b can be used to store various transmission parameter sets that support the desired link characteristics and required activation types. The entries in memory 125b may be indexed according to an established scheme. For instance, a first group of sets may be automatically accessed for use during peak hours of operation (e.g., 6 am to midnight). A second group of sets, on the other hand, may be automatically accessed for use during off-peak hours (e.g., midnight to 6 am). Likewise, the transmission parameters can be stored in sets based on a corresponding activation type or functional state. Numerous other such schemes will be apparent in light of this disclosure. Memory 125b may alternatively be part of the operations and management entity.

[0022] Processor 125a is adapted to access memory 125b or otherwise receive a selected transmission parameter set, and provide that set to STP mux 103. Alternatively, a selected transmission parameter set can be provided to STP mux 103 directly from the operations and management entity. The selected transmission parameter set can then be embedded in a transmission frame and provided to a remote modem. In one embodiment of the present invention, the selected transmission parameter set is embedded in the data field of the operations channel field of the slow codeword and transmitted to the remote modem by way of a VDSL overhead control (VOC) channel. The transmission frame format and VOC channel, as well as link activation and transmission parameter negotiation in accordance with embodiments of the present invention, will be discussed in more detail within the context of the VDSL standard of the ANSI standards group T1E1.4.

[0023] Variations on the functional model illustrated in Figure 1 will be apparent to one skilled in the art in light of this disclosure, and the present invention is not intended to be limited to any one modem type or configuration.

Transmission Frame Format [0024] The transmission frame format generally includes a header portion and a payload data portion. In one embodiment of the present invention, the structure of the transmission frame format is as described in the VDSL standard of the ANSI standards group T1E1.4. More specifically, the transmission frame includes a 5-octet header and a 400-octet payload. However, the present invention can operate in the context of other frame formats as well. The specific structure of the frame format depends on factors such as the underlying communication standard being employed.

[0025] Assuming the VDSL standard of the ANSI standards group for sake of discussion, the transmission frame header portion includes a syncword and a control field. The syncword contains frame alignment information. The control field includes control and management information such as the network timing reference (NTR) marker, indicator bits, and special flags for link activation. Management module 125 can be adapted to set indicator bits and flags in accordance with the VDSL standard and or other established schemes or services. A cyclic redundancy check (CRC) incorporated into the control field allows error detection in the received data.

[0026] The transmission frame payload data portion includes two equal fields for the fast channel, and two equal fields for the slow channel. In one embodiment, each fast channel field transports one Reed-Solomon (RS) codeword (fast codeword) with no interleaving. Each slow channel field, on the other hand, includes an STP mux 103 and transports one RS codeword (slow codeword) that passes through the interleaver module 115. The fast codeword includes a fast payload field and fast FEC field. The slow codeword (prior to interleaving) includes an operations channel field, a slow payload field, and a slow FEC field. The operations channel field, which can be used to transport transmission parameter information in accordance with embodiments of the present invention, includes an opcode (e.g., 1 octet) and data (e.g., second and third octets). Note that the operations channel field may be shared between an embedded operations channel (EOC) and a VDSL overhead control (VOC) channel. The received operations channel opcode can be used to associate the corresponding frame with an EOC or VOC channel.

VDSL Overhead Control Channel

[0027] The VDSL Overhead Control (VOC) channel supports VDSL link activation as well as to provide VDSL link maintenance, performance monitoring, and modification of transmission parameters. Generally, a communication sequence over the VOC channel between a VTU-O and a VTU-R is initiated by the VTU-O. The VTU-R can then reply to the VTU-O (assuming successful reception by the VTO-R). The vehicle for such communications between the VTU-O and VTU-R over a VOC channel is a VOC message. Note that in alternative embodiments, the VTU-R may initiate a communication sequence over the VOC chaimel to which the VTU-O can reply. For purposes of discussion herein, assume that the VTU-O initiates communication sequences over the VOC channel.

[0028] A VOC message typically contains an opcode and data. The opcode value distinguishes the content and type of the associated VOC message. The VDSL standard of the ANSI standards group T1E1.4, for example, specifies three types of VOC messages. The first VOC message is a command-type message. This message is sent by the VTU-O to communicate information to the VTU-R (e.g., a write command), or to request information from the VTU-R (e.g., a read command). The second message is an echo-type message. This message is a reply from the VTU-R and generally indicates receipt and acceptance of a command-type message. The third message is a status-type message. This type of message can either be an idle message or an unable-to-comply (UTC) message. An idle message is sent from both the VTU-O and VTU-R when no activity is going over the VOC channel. A UTC message, on the other hand, is sent by the VTU-R as a reply to a command-type message that indicates the VTU-R' s inability to comply with the received command (e.g., read or write request).

[0029] A VOC handshake procedure is also described in the VDSL standard of the ANSI standards group T1E1.4. At the start of the handshake procedure, both the VTU- O and VTU-R transmit idle messages. When a particular command is to be sent, the VTU-O begins and continues transmitting the corresponding command-type message. The VTU-R may then accept and latch the transmitted command-type message after it has sampled identical messages in three consequently sampled transmission frames. In this case, the VTU-R responds by beginning and continuing to transmit an echo-type message corresponding to the accepted command- type message. If the VTU-R is unable to comply with the received message, however, the VTU-R transmits a UTC message instead of echoing the command-type message. After the VTU-O samples the consecutive arrival of three correct and identical echo-type responses or three consecutive UTC messages in three consequently sampled frames, the VTU-O responds to the VTU-R by beginning and continuing to transmit idle messages.

[0030] In response to the VTU-R receiving the idle message, it stops transmitting echo or UTC messages and starts transmitting idle messages, and the handshake procedure is completed. Note that the VTU-O continues to send the command-type message until it detects the echo or UTC message three times in a row. Similarly, note that the VTU-R continues to send the echoed message until it receives the idle message from the VTU-O. Variations on this handshake procedure will be apparent to those skilled in the art. Such handshake procedures generally ensure a reliable and robust message transport between the VTU-O and VTU-R.

VDSL Link Activation

[0031] For the sake of clarity, a VDSL link activation/deactivation process establishes a VDSL link with required transmission parameters between a transceiver- pair (e.g., communicatively coupled and powered VTU-O and VTU-R). The process can also modify transmission parameters of the VDSL link. Note that although the activation/deactivation process (as well as other management related functions) is described by utilizing the VOC, the same procedures can be established over any operation and maintenance channel having similar characteristics. Further, note that prior to activation, a handshake procedure (e.g., International Telecommunications Union or ITU-T Recommendation G.994) may be performed to establish the type of DSL equipment at the customer premises. Note that this initial handshake procedure is distinct from the VOC handshake procedure described above.

Link Transmission Parameters

[0032] Transmission characteristics of the communication link between the VTU-O and VTU-R are specified by a set of transmission parameters (sometimes referred to as STP). Such transmission parameters include, for example, symbol rate, constellation size, center frequency, modulation type (e.g., QAM or CAP), transmit power spectral density level, power spectral density mask code, interleaving depth, transmission profile code, and frame format. Other transmission parameters can be derived. For example, the bit rate of a particular carrier is defined by the corresponding symbol rate and constellation size. In addition, communication protocols can be established, such as turn around periods for effecting dynamic reconfigurations signaled during data mode (e.g., switching from one transmission parameter set to another after receipt of the second symbol following the reconfiguration signal).

[0033] Typically, the same set of transmission parameters is stored or otherwise set at both the communicating VTU-O and VTU-R. As such, the communication link remains stable regardless of its operation state, and the available activation procedures are supported. When the set of transmission parameters is modified in one location (e.g., VTU-O), the same change is made in the other location (e.g., or VTU-R) as well. In this sense, the set of transmission parameters remain synchronized. The current set of transmission parameters refers to the set currently in use. Other standard transmission parameter sets, including a default set, can also be defined (e.g., and stored in memory 125b) to provide interoperability between numerous transceiver types. Generally, any set of transmission parameters can be modified as appropriate for the specified service requirements. The process of establishing and modifying transmission parameters are described further in reference to Figures 2 through 4.

[0034] Figure 2 is a flow chart illustrating a method for negotiating a set of transmission parameters suitable to a particular transceiver-transceiver pair in accordance with one embodiment of the present invention. This method may be implemented, for example, in hardware, software, firmware or any combination thereof included in a VDSL SCM modem (e.g., VTU-O). For instance, the method may be implemented by a set of software instructions executing on a digital signal processor or equivalent processing environment. Alternatively, the method can be carried out by a set of application specific integrated circuits or chip set.

[0035] The method begins with sending 205 a request message specifying a set of proposed transmission parameters. Assume for the sake of discussion that the sending device is the VTU-O. The VTU-O may get the set of proposed transmission parameters, for example, from the local operations and management entity or network operator. Alternatively, the VTU-O may retrieve the set from a non-volatile memory or database that has various transmission parameter sets indexed according to an established scheme as previously discussed. Recall that each transmission parameter set accessible by the VTU-O can be designed to provide optimal system performance for a given set of circumstances. In one embodiment, the VTU-O sends a command-type message including a copy of the proposed transmission parameter set in its data field to the VTU- R by way of the VOC channel. This message is essentially a request to make changes to the current transmission parameter set associated with the VTU-O.

[0036] The method proceeds with receiving 210 a reply message responsive to the request message, and determining 215 whether the reply indicates acceptability of the proposed transmission parameter set. If the reply indicates that the proposed transmission parameter set is acceptable, then the method may further include storing 235 the proposed transmission parameter set at the VTU-O. Note that if the current transmission parameter set is being modified, then step 235 may alternatively be updating the current transmission parameter set to reflect the proposed and accepted transmission parameter set. Regardless of whether a transmission parameter set is being established, modified or replaced, the resulting transmission parameter set reflects the proposed and accepted transmission parameter set. In one embodiment, the reply message is an echo-type message received from the VTU-R by way of the VOC channel. The method may further include sending 240 a confirmation message (e.g., an idle-type message) thereby completing the VOC handshake procedure, and signaling completion of that particular transmission parameter negotiation session.

[0037] However, if the reply indicates that the proposed transmission parameter set is unacceptable, then the method further includes interrogating 220 acceptable transmission parameters indicated in the reply message. These acceptable transmission parameters can be embedded or otherwise reflected in the reply message (e.g., in a data field) by the VTU-R providing the reply. Such acceptable transmission parameters indicate the capabilities and configuration of the VTU-R and allow the VTU-O to make an informed selection regarding its next proposed transmission parameter set. In one embodiment, the reply message is a UTC message received from the VTU-R by way of the VOC channel. Alternatively, the reply message is an echo message received from the VTU-R by way of the VOC channel or other overhead (e.g., operation and maintenance) chaimel.

[0038] Regardless of the reply message type, the data field of the reply message is accessed and evaluated (or otherwise interrogated) thereby allowing the acceptable transmission parameters indicated therein to be identified by the VTU-O. In one embodiment, the reply message is deinterleaved, decoded, and descrambled. STP mux 103 then demultiplexes the acceptable transmission parameters from the descrambled data stream and provides those parameters to processor 125a of management module 125. Processor 125a can then evaluate the provided acceptable transmission parameters. Alternatively, STP mux 103 may provide the acceptable transmission parameters to the operations and management entity, which can then evaluate the provided acceptable transmission parameters.

[0039] The method proceeds with sending 225 a new request message specifying a new set of transmission parameters based on the identified acceptable transmission parameters. In one embodiment, the VTU-O sends a command-type message including a copy of the new set of transmission parameters based on the identified acceptable transmission parameters set in its data field to the VTU-R by way of the VOC channel. The new set of parameters may, for example, be retrieved by processor 125a from memory 125b, or provided by the operations and management entity. Regardless, the new set of parameters can be provided to STP mux 103, and multiplexed into the slow latency path (e.g., as a command-type message).

[0040] The method may further include receiving 230 a reply message responsive to the new request (e.g., an echo message acknowledging receipt and acceptance or a UTC message acknowledging receipt and rejection). The determination of step 215 is then repeated. Assuming that the reply indicates acceptance of the new proposed transmission parameter set, the method may proceed with steps 235 and 240 as previously described. If for whatever reason the reply indicates rejection of the new proposed transmission parameter set, then steps 220 through 230 may be repeated as necessary until an acceptable parameter set is identified. In one embodiment, a loop counter can be maintained to prevent an endless looping condition between steps 215 through 230. For example, if no acceptable transmission parameter set is identified after three passes through this loop (or some other pre-established max looping number or threshold), then a default set can be accessed and assigned to the transceiver-transceiver pair. Such a situation might arise, for example, if the VTU-R storage (e.g., transmission parameter set database) becomes corrupted or otherwise inaccessible. Assuming that the VTU-R is capable of providing acceptable transmission parameters, such a default condition would not be necessary.

[0041] Figure 3 is a flow chart illustrating a method for negotiating a set of transmission parameters suitable to a particular transceiver-transceiver pair in accordance with another embodiment of the present invention. This method may be implemented, for example, in hardware, software, firmware or any combination thereof included in a VDSL SCM modem (e.g., VTU-R). For instance, the method may be implemented by a set of software instructions executing on a digital signal processor or equivalent processing environment. Alternatively, the method can be carried out by a set of application specific integrated circuits or chip set.

[0042] The method begins with receiving 305 a request message specifying a set of proposed transmission parameters. These proposed transmission parameters can be embedded or otherwise reflected in the request message by the requesting device. Assume for the sake of discussion that the requesting device is the VTU-O. In one embodiment, the VTU-R receives a command-type message including a copy of the proposed transmission parameter set in its data field from the VTU-O. The command- type message can be sent over the VOC channel. STP mux 103 can demultiplex or otherwise extract the set of proposed transmission parameters. The set can then be provided, for example, to management module 125 or the operations and management entity.

[0043] The method proceeds with determining 310 whether the proposed transmission parameter set is acceptable. Note that the proposed transmission parameter set may be rejected for what ever reason (e.g., proposed transmission parameter value is not standard or is an optional setting). In one embodiment, STP mux 103 demultiplexes the proposed transmission parameter set from the descrambled data stream and provides those parameters to processor 125a of management module 125. Processor 125a can then analyze the set of proposed transmission parameters to determine if they are acceptable. Alternatively, STP mux 103 may provide the transmission parameters to the operations and management entity, which can then analyze the proposed set for acceptability.

[0044] If the proposed transmission parameter set is acceptable, then the method may further include sending 325 a reply message indicating acceptance of the proposed set of transmission parameters. In one embodiment, the reply message is an echo-type message sent by the VTU-R by way of the VOC channel or other overhead (e.g., operation and maintenance) channel. The method may further include receiving 330 a confirmation message (e.g., an idle-type message) from the VTU-O thereby completing the VOC handshake procedure, and signaling completion of that particular transmission parameter negotiation session. The method may further include storing 335 the proposed transmission parameter set at the VTU-R. Note that if the current transmission parameter set is being modified, then step 335 may alternatively be updating the current transmission parameter set to reflect the proposed and accepted fransmission parameter set. Regardless of whether a new transmission parameter set is being established, or the current transmission parameter set is being modified or replaced, the resulting transmission parameter set reflects the proposed and accepted transmission parameter set.

[0045] However, if the proposed transmission parameter set is unacceptable, then the method further includes sending 315 a reply message specifying a set of acceptable transmission parameters. These acceptable transmission parameters can be embedded or otherwise reflected in the reply message (e.g., in a data field) by the VTU-R providing the reply. The acceptable transmission parameters can be retrieved, for example, from memory 125a by processor 125a, or from the operations and management entity. The retrieved parameters can then be provided to STP mux 103 for multiplexing into the slow latency path. In one embodiment, the reply message is a UTC or echo-type message received from the VTU-R by way of the VOC channel or other overhead (e.g., operation and maintenance) channel. Regardless of the reply message type, the data field of the reply message can be accessed and evaluated (or otherwise interrogated) thereby allowing the acceptable transmission parameters indicated therein to be identified by the VTU-O that ultimately receives the reply.

[0046] The method proceeds with receiving 320 a new request message specifying a new set of transmission parameters based on the acceptable transmission parameters included in the reply message of step 315. In one embodiment, the VTU-O sends a command-type message including a copy of the new set of transmission parameters based on the acceptable transmission parameters set in its data field to the VTU-R by way of the VOC channel. The determination of step 310 is then repeated. Assuming that the new proposed transmission parameter set is acceptable, the method may proceed with steps 325 through 335 as previously described. If for whatever reason the new proposed transmission parameter set is deemed unacceptable by the VTU-R, then steps 315 through 320 may be repeated as necessary until an acceptable parameter set is identified. In one embodiment, a loop counter can be maintained to prevent an endless looping condition between steps 315 through 320 as discussed in reference to Figure 2.

[0047] Figure 4 is a flow chart illustrating a method for establishing a modulation scheme suitable to a particular transceiver-transceiver pair in accordance with one embodiment of the present invention. This method may be implemented, for example, in hardware, software, firmware or any combination thereof included in a VDSL SCM modem pair (e.g., VTU-O and VTU-R). For instance, the method may be implemented by a set of software instructions executing on one or more digital signal processors or equivalent processing environments. Alternatively, the method can be carried out by a set of application specific integrated circuits or chip set. Note that a transceiver- transceiver pair may be communicating in the downstream (VTU-O to VTU-R) or upstream (VTU-R to VTU-O) directions. Further note that each transceiver or the transceiver-transceiver pair has a receiver component and a transmitter component, and that each direction of communication (e.g., downstream or upstream) effectively includes a transmitter-receiver pair that are communicatively coupled.

[0048] The method begins with initiating 405 a messaging session between the transceiver-transceiver pair. In one embodiment, this messaging session is included in a messaging scheme that effects preliminary communication between the newly coupled transceivers of the transceiver pair. In an alternative embodiment, the messaging session is included in a handshake session. Generally, a handshake session is used to exchange information, such as capabilities, mode selection, and parameters relating to service and application requirements, as well as parameters related to the particular transceivers employed. In such an embodiment, the handshake session can be performed in accordance with ITU Recommendation G.994.1 (often referred to as G.HS). Other handshake protocols or early messaging schemes can be employed here as well.

[0049] The method proceeds with determining 410 whether the transmitter or the receiver of a given transmitter-receiver pair dictate the modulation scheme to be used for communications between the associated modems. Note that if the transmitter of the pair dictates the modulation scheme, then the transmitter need only implement one mode of modulation (e.g., CAP or QAM), while the receiver has to support all modes (e.g., CAP and QAM). On the other hand, if the receiver of the pair dictates the modulation scheme, then the receiver need only implement one mode of modulation, while the fransmitter has to support all modes. Generally, the receiver structure may be simplified by allowing the receiver to dictate the modulation scheme. However, the present invention can operate in either case.

[0050] If the transmitter of the transmitter-receiver pair dictates the modulation scheme, then the method further includes sending 415 a modulation selection message from the transceiver of the transmitter to the transceiver of the receiver specifying what modulation scheme should be used by the receiver. The receiver can then implement the correct modulation scheme before the data mode is entered. In one embodiment, the modulation selection message is a 1-bit message exchanged during the messaging session or handshake procedure. In response to the bit being in a first state (e.g., logical high), then CAP modulation is used. In response to the bit being in a second state (e.g., logical low), then QAM modulation is used. In alternative embodiments, the modulation selection message may be a multi-bit message that is exchanged during the messaging session or handshake procedure thereby allowing other information to be exchanged as well (such as information relevant to the messaging session or handshake procedure, or to initialization procedures).

[0051] Similarly, if the receiver of the transmitter-receiver pair dictates the modulation scheme, then the method further includes sending 420 a modulation selection message from the transceiver of the receiver to the transceiver of the transmitter specifying what modulation scheme should be used by the transmitter. The transmitter can then implement the correct modulation scheme before the data mode is entered. In one embodiment, the modulation selection message is a 1-bit message exchanged during the messaging session or handshake procedure. In response to the bit being in a first state (e.g., logical high), then CAP modulation is used. In response to the bit being in a second state (e.g., logical low), then QAM modulation is used.

[0052] Thus, regardless of what transceiver or transceiver component (e.g., receiver or transmitter) dictates the modulation scheme to be used, the method generally includes sending a modulation selection message from one transceiver to the other transceiver. The modulation message specifies a particular modulation scheme to be used by the other transceiver. As such, the modulation scheme employed is known by the transceiver-transceiver pair prior to entering the data mode, and the respective transceiver component can then implement the structure associated with the specified particular modulation scheme. In addition, blind identification of the modulation scheme is eliminated. The method may further include exchanging 425 capabilities and other information thereby identifying common modes of operation of the transceivers, and terminating 430 the messaging session between the transceiver-transceiver pair.

[0053] The foregoing description of the embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. For example, the principles and concepts underlying the present invention may be employed by other single carrier modulation based communication systems and or systems employing overhead control channels and messaging schemes, and need not be limited to VDSL SCM systems. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto.

Claims

What is claimed is:

1. A method for negotiating a set of transmission parameters for a particular VDSL SCM transceiver-transceiver pair communicatively coupled, the method comprising: sending a request message specifying a set of proposed transmission parameters; receiving a reply message responsive to the request message; in response to the reply message indicating the set of proposed transmission parameters is unacceptable: interrogating acceptable transmission parameters indicated in the reply message; and sending a new request message specifying a new set of proposed transmission parameters based on the acceptable transmission parameters indicated in the reply message.

2. The method of claim 1 further comprising: in response to the reply message indicating acceptability of the set of proposed transmission parameters: storing the set of proposed transmission parameters; and sending a confirmation message thereby signaling completion of a transmission parameter negotiation session.

3. The method of claim 1 wherein the steps are repeated a number of times until an acceptable set of transmission parameters is negotiated between the transceiver- transceiver pair.

4. The method of claim 3 wherein a default set of transmission parameters is assigned to the transceiver-transceiver pair in response to the number being greater than a pre-established threshold.

5. The method of claim 1 further comprising: receiving a reply message responsive to the new request message acknowledging receipt and acceptance of the new set of proposed transmission parameters specified in the new request message.

6. The method of claim 1 wherein the method is carried out by a central office VDSL SCM transceiver included in the transceiver-transceiver pair.

7. The method of claim 1 wherein the method is carried out at least in part by a set of software instructions executing on one or more digital signal processors.

8. The method of claim 1 wherein the request messages are command-type messages, and the associated set of proposed fransmission parameters is included in a data field of the command-type message.

9. The method of claim 1 wherein the request and reply messages are exchanged between the transceiver-transceiver pair by way of an overhead channel.

10. The method of claim 1 wherein the reply message responsive to the request message is an unable-to-comply-type message, and the acceptable transmission parameters are included in a data field of the unable-to-comply-type message.

11. The method of claim 1 wherein the reply message responsive to the request message is an echo-type message, and the acceptable transmission parameters are included in a data field of the echo-type message.

12. The method of claim 1 wherein a reply message received in response to the new request message is an echo-type message acknowledging receipt and acceptance of the new set of proposed transmission parameters specified in the new request message.

13. The method of claim 1 wherein sending the request message specifying the set of proposed transmission parameters further includes: multiplexing the set of proposed transmission parameters into a slow latency path.

14. The method of claim 1 wherein a transmission parameter set includes at least one or more of the following: symbol rate, bit rate, modulation type, constellation size, center frequency, transmit power spectral density level, power spectral density mask code, interleaving depth, transmission profile code, frame format, and communication protocols.

15. A method for negotiating a set of fransmission parameters for a particular VDSL SCM transceiver-transceiver pair communicatively coupled, the method comprising: receiving a request message specifying a set of proposed transmission parameters; in response to the set of proposed transmission parameters being unacceptable: sending a reply message specifying acceptable transmission parameters; and receiving a new request message specifying a new set of transmission parameters based on the acceptable transmission parameters included in the reply message.

16. The method of claim 15 further comprising: in response to the set of proposed transmission parameters being acceptable: sending a reply message indicating acceptance of the set of proposed transmission parameters; receiving a confirmation message thereby signaling completion of a transmission parameter negotiation session; and storing the set of proposed transmission parameters.

17. The method of claim 15 wherein the steps are repeated a number of times until an acceptable set of transmission parameters is negotiated between the transceiver- transceiver pair.

18. The method of claim 17 wherein a default set of transmission parameters is assigned to the transceiver-transceiver pair in response to the number being greater than a pre-established threshold.

19. The method of claim 15 further comprising: sending a reply message responsive to the new request message acknowledging receipt and acceptance of the new set of proposed transmission parameters specified in the new request message.

20. The method of claim 15 wherein the method is carried out by a remote VDSL transceiver included in the transceiver-transceiver pair.

21. The method of claim 15 wherein the method is carried out at least in part by a set of software instructions executing on one or more digital signal processors.

22. The method of claim 15 wherein the request messages are command-type messages, and the associated set of proposed transmission parameters is included in a data field of the command-type message.

23. The method of claim 15 wherein the request and reply messages are exchanged between the transceiver-transceiver pair by way of an overhead channel.

24. The method of claim 15 wherein the reply message is an unable-to- comply-type message, and the acceptable transmission parameters are included in a data field of the unable-to-comply-type message.

25. The method of claim 15 wherein the reply message is an echo-type message, and the acceptable transmission parameters are included in a data field of the echo-type message.

26. The method of claim 15 wherein a reply message sent in response to the new request message is an echo-type message acknowledging receipt and acceptance of the new set of proposed fransmission parameters specified in the new request message.

27. The method of claim 15 wherein receiving the request message specifying the set of proposed fransmission parameters further includes: demultiplexing the set of proposed transmission parameters from a slow latency path.

28. The method of claim 15 wherein receiving the request message specifying the set of proposed transmission parameters further includes: analyzing the set of proposed fransmission parameters to determine if they are acceptable.

29. The method of claim 15 wherein a transmission parameter set includes at least one or more of the following: symbol rate, bit rate, modulation type, constellation size, center frequency, transmit power spectral density level, power spectral density mask code, interleaving depth, transmission profile code, frame format, and communication protocols.

30. A method for establishing a modulation scheme for newly coupled transceivers included in a VDSL SCM transceiver-transceiver pair, the method comprising: initiating a messaging session to effect preliminary communication between the transceivers; sending a modulation selection message from one transceiver to the other transceiver specifying a particular modulation scheme to be used by the other transceiver; and implementing a structure associated with the specified modulation scheme in the other transceiver before data mode is entered thereby eliminating blind identification of the modulation scheme.

31. The method of claim 30 further comprising : exchanging capabilities information thereby identifying common modes of operation associated with each of the transceivers; and terminating the messaging session between the transceivers.

32. The method of claim 30 wherein a transmitter included in one of the fransceivers of the transceiver-transceiver pair dictates the modulation scheme, and the step of sending the modulation selection message is performed by the transmitter's transceiver.

33. The method of claim 30 wherein a receiver included in one of the transceivers of the transceiver-transceiver pair dictates the modulation scheme, and the step of sending the modulation selection message is performed by the receiver's transceiver.

34. The method of claim 30 wherein at least a portion of the method is implemented by a set of software instructions executing on one or more digital signal processors.

35. The method of claim 30 wherein the step of initiating a messaging session is followed by determining what componentry included in the transceiver- transceiver pair dictates the modulation scheme.

36. The method of claim 35 wherein either receiver componentry or transmitter componentry included in the transceiver-transceiver pair dictates the modulation scheme.

37. The method of claim 30 wherein the modulation selection message is a 1- bit message.

38. The method of claim 30 wherein the modulation selection message has a first state that indicates a first type of modulation and a second state that indicates a second type of modulation.

39. The method of claim 38 wherein the first type of modulation is carrierless amplitude and phase modulation and the second type of modulation is quadrature amplitude modulation.

40. A VDSL SCM modem comprising: a management module having a processor, the management module for providing operation and management functions of the modem; and a transmission parameter mux operatively coupled to the management module and a slow latency path of the modem, the transmission parameter mux adapted to multiplex transmission parameter information with the slow latency path.

41. The modem of claim 40 wherein the transmission parameter mux is further adapted to demultiplex transmission parameter information from the slow latency path.

42. The modem of claim 41 wherein the transmission parameter information that is demultiplexed from the slow latency path is provided by the transmission parameter mux to the management module.

43. The modem of claim 41 wherein the transmission parameter information that is demultiplexed from the slow latency path is analyzed for acceptability by the management module.

44. The modem of claim 40 wherein the transmission parameter information is provided to the transmission parameter mux by the management module.

45. The modem of claim 44 wherein the transmission parameter information that is provided to the transmission parameter mux by the management module is based on fransmission parameters established as acceptable by a remote modem with which the modem is communicatively coupled.

46. The modem of claim 40 wherein a transmission parameter information includes at least one or more of the following: symbol rate, bit rate, modulation type, constellation size, center frequency, transmit power spectral density level, power spectral density mask code, interleaving depth, transmission profile code, frame format, and communication protocols.