Abstract:
An application implemented at customer premises equipment automatically detects an intermediate-layer protocol used at the head end of a DSL connection and configures the DSL modem driver for that protocol. The application sets the DSL modem driver to one of the possible intermediate-layer protocols for the type (e.g., WAN or LAN) of driver being used and attempts to connect to a server at the head end. If a response is received from the head end, then the application reads the headers on the responsive message to determine whether the intermediate-layer protocol at the head end is consistent with the intermnediate-layer protocol that the DSL modem is set to. If the intermediate-layer protocols are consistent, then the settings are loaded into the driver. If no response is received from the head end when the application attempts to connect to the server, then the application initiates a series of commands for the purpose of eliciting a response from the head end. If the intermediate-layer protocol is not consistent or no response is elicited, then the DSL modem is set to another intermediate-layer protocol, and the application again attempts to connect to the server at the head end. These steps are repeated until either the correct head-end intermediate-layer protocol is found, or the possible intermediate-layer protocols are exhausted.

Description:
RELATED CASES  
       [0001]    This is a continuation of application Ser. No. 09/599,682, filed on Jun. 22, 2000, which claimed benefit of the filing date of U.S. provisional application No. 60/174,205, filed on Jan. 3, 2000 as attorney docket number Bullman 4-1. 
     
    
     
       BACKGROUND OF THE INVENTION  
         [0002]    1. Field of the Invention  
           [0003]    The present invention relates to digital communications, and, in particular, to a method for configuring a digital subscriber line (DSL) modem to a DSL connection.  
           [0004]    2. Description of the Related Art  
           [0005]    Digital subscriber line (DSL) modems are widely used in digital communications systems for Internet access. Historically, DSL modems, which are installed in the customer premises equipment (CPE), have been provided by the same entity that controls the central office (i.e., head-end) equipment, allowing the modem driver to be programmed for the network-layer protocol (i.e., transmission mode) that is used at the head end. However, as DSL modems are marketed by entities that do not control the head-end equipment, the DSL modem driver must be configured during installation for the network-layer protocol used at the head end.  
           [0006]    Currently, there are three protocols that are used for wide area network (WAN) connections (e.g., dial-up connections), and four protocols that are used for local area network (LAN) connections. According to the prior art, when installing a new DSL modem, a user must know a priori which particular protocol is used at the head end, in order to correctly configure his/her DSL modem so that it will connect to the head end. One method for determining the protocol used at the head end is to contact the entity that controls the head-end equipment. However, this solution is undesirable, because it can cause delays in DSL modem installation, and it can result in expenses incurred for service calls. Another problem is that some clients may not be capable of or even want to perform the task of configuring a DSL modem driver for the head-end protocol. Yet another problem is that when a DSL modem cannot be configured properly, a user may not be able to determine whether the problem is the wrong protocol or inadequate physical-layer settings.  
         SUMMARY OF THE INVENTION  
         [0007]    The present invention is directed to a technique for automatically detecting the network-layer protocol used by the protocol layer at the head end of a DSL connection and automatically setting the driver configuration for that protocol. According to the present invention, the DSL modem driver is set to one of the possible protocols for the type of driver being used (e.g., WAN or LAN) and attempts to connect to a server at the head end. If a response is received from the head end, then the application reads the headers on the responsive message to determine whether the protocol at the head end is consistent with the current protocol. If the protocols are consistent, then the settings are loaded onto the driver. If no response is received from the head end when the application attempts to connect to the server, then the application initiates a series of commands for the purpose of eliciting a response from the head end. If the protocols are not consistent or no response is elicited, then the DSL modem is set to another protocol, and another attempt is made to connect to the server at the head end. These steps are repeated until either the correct head-end protocol is found or the possible protocols are exhausted.  
           [0008]    The present invention can detect the network-layer protocol used at the head end of a DSL and set a modem driver configuration for that protocol. Using the present invention, a DSL modem can be installed without knowing a priori the protocol used at the head end. Nor does the user need to make a service call to determine the head-end protocol. Under the present invention, multiple protocols can be tested without the need to re-start or re-boot the system (except when switching between LAN and WAN modes, in which case the system would need to be re-started).  
           [0009]    In one embodiment, the present invention is a method, implemented by customer premises equipment (CPE), for automatically and remotely determining a digital subscriber line (DSL) intermediate-layer protocol of a head end of a DSL link between the CPE and the head end. The CPE and the head end each have a protocol stack comprising an intermediate layer located below a transport layer and above a DSL layer. The method comprises the steps of (a) attempting to initiate a DSL connection over the DSL link to the head end using a selected intermediate-layer protocol; (b) determining whether the selected intermediate-layer protocol is the intermediate-layer protocol of the head end based on results of step (a); and (c) when the selected intermediate-layer protocol is not the DSL protocol of the head end, then selecting an other intermediate-layer protocol and repeating steps (a) and (b). 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0010]    Other aspects, features, and advantages of the present invention will become more fully apparent from the following detailed description, the appended claims, and the accompanying drawings in which:  
         [0011]    [0011]FIG. 1 shows a representation of equipment used in a digital subscriber line (DSL) connection;  
         [0012]    [0012]FIG. 2 shows a representation of the communication layers of the DSL connection of FIG. 1; and  
         [0013]    [0013]FIGS. 3-6 show flow diagrams for an application for automatically determining the head-end protocol for a DSL modem, according to one embodiment of the present invention.  
     
    
     DETAILED DESCRIPTION  
       [0014]    As shown in FIG. 1, a digital subscriber line (DSL) connection typically comprises a computing unit (e.g., a personal computer) with a DSL modem, collectively known as client premises equipment (CPE)  102 . CPE  102  is connected to a head-end digital subscriber line access multiplexer (DSLAM)  104  through a physical connection  106 , such as a telephone line. Client or user applications implemented within CPE  102  communicate with the DSL modem through a software program called a driver, which is also implemented within CPE  102 . The driver should be configured for the network-layer protocol used by DSLAM  104 .  
         [0015]    Typically, Internet communications comprise multiple embedded layers. Each embedded layer of the communication has one or more protocols that generally have headers to provide the information necessary for transmitting the communication. FIG. 2 shows the DSL connection layers for the DSL connection shown in FIG. 1, where: CPE protocol stack  202  in FIG. 2 is the protocol stack at CPE  102  of FIG. 1 and head-end protocol stack  204  is the protocol stack at head-end DSLAM  104 . CPE protocol stack  202  comprises a physical layer  206 , a digital subscriber line (DSL) layer  208 , an asynchronous transfer mode (ATM) layer  210 , a network layer  212 , a transport layer  214 , and an application layer  216 . Transport layer  214  can be a LAN-type layer using a transmission control protocol/Internet protocol (TCP/IP) or a WAN-type layer using a dial-up network (DUN) protocol in addition to TCP/IP. Head-end protocol stack  204  comprises a physical layer  218 , a DSL layer  220 , an ATM layer  222 , a network layer  224 , a transport layer  226 , and an application layer  228 . For meaningful communication to take place, network layer  212  of CPE protocol stack  202  must be compatible with network layer  224  of head-end protocol stack  204 . That is, CPE  102  in FIG. 1 must be configured to use the same network-layer protocol that is used at DSLAM  104 .  
         [0016]    [0016]FIGS. 3-6 show one implementation of the invention, in which an application comprising four procedures is used to determine the head-end protocol for a DSL connection, set the driver to that protocol, and optimize the physical-layer settings. FIG. 3 shows a start-up procedure of the application. The start-up procedure establishes a connection to the head end, determines whether the protocol layer is up, and, if so, saves the protocol information. FIG. 4 shows a protocol query procedure of the application. The protocol query procedure comprises one or more steps directed at eliciting a response from the network so that the application can check the headers to determine the head-end protocol. FIG. 5 shows the disconnect procedure of the application. The disconnect procedure terminates the connection to the head end after each particular protocol is tested and can save physical layer data and loop data. FIG. 6 shows an optimal setting procedure that can further optimize the physical-layer settings for improved performance of the DSL connection following determination of the head-nd protocol.  
         [0017]    The processing of FIGS. 3-6 determines the network-layer protocol at the head end for a particular mode: either LAN or WAN. A higher-level installation application may be implemented to switch between LAN and WAN modes, in which case the system is re-booted before repeating the processing of FIGS. 3-6 for the new mode.  
         [0018]    Referring now to FIG. 3, when the application is started (with an initial DSL protocol selected), the driver is set to an initial DSLAM setting (step  302  of FIG. 3). Different DSLAM types are tested by the application. While the modem may be able to communicate with a DSLAM other than the type configured for in the DSL modem driver, the correct DSLAM configuration may help to achieve optimum driver settings. In step  304 , the transmit gain level is set to a minimum value, which, with repetition of the start-up procedure, will be incremented to a maximum value at specified increments to compensate for variations in the connection. For example, the gain level can be incremented from a minimum value of 0 dB to a maximum value of 2 dB at 2-dB increments. Steps  302  and  304  are optional steps that may improve performance of the application.  
         [0019]    In step  306 , the application determines whether the connection is a WAN-type connection or a LAN-type connection. This can be done by checking which DSL modem driver is loaded in the computing unit. If the connection is a WAN-type connection, then the application starts a dial-up networking procedure (step  308 ). If the connection is a LAN-type connection, then the application starts a LAN connection process (step  310 ). In either case, the application then determines if the physical layer is up (i.e., activated) (step  312 ). One method for determining whether the physical layer is up is to verify that a connect indication is received from the digital signal processor (DSP) at the client. If the physical layer is up, then the application records physical-layer information into a physical-layer data table (step  314 ). The physical-layer information to be recorded may include the transmit rate, the receive rate, and the receive average margin.  
         [0020]    Next, the application determines whether the ATM layer is up (step  316 ). This can be done, for example, by checking the ATM-layer status in the driver that reads ATM headers. If the ATM layer is up, then the application determines whether the head-end protocol was already found during a previous pass (e.g., at a lower transmit gain level setting using the same protocol).(step  318 ). The application searches a protocol data table within the application to determine whether the head-end protocol was previously found. If the head-end protocol has not already been found (e.g., no data is saved in the protocol data table), then the application determines whether the protocol layer is up (step  320 ) by checking the driver protocol-layer status which compares protocol-layer headers on any messages that have been received from the head end. If the protocol headers are consistent with the protocol set by the application, then the protocol information is saved to the DSL modem driver (step  322 ), and the application routes to the disconnect procedure shown in FIG. 5.  
         [0021]    If the physical layer is determined not to be up in step  312 , then errors are recorded into the physical-layer data table (step  324 ). The application then routes to the disconnect procedure shown in FIG. 5. If the physical layer is up, but the ATM layer is determined not to be up in step  316 , then the application routes to the disconnect procedure shown in FIG. 5. If the physical layer and the ATM layer are up, but the protocol layer is determine to have already been found in step  318 , then the application routes to the disconnect procedure shown in FIG. 5. If the protocol layer is not up, as determined in step  320 , then the application determines whether the protocol is known (step  326 ). If the protocol is known, then the application routes to the disconnect procedure shown in FIG. 5. If the protocol is not known, then the application routes to the protocol query procedure shown in FIG. 4.  
         [0022]    Referring now to FIG. 4, the application determines whether the connection is a WAN connection or a LAN connection (step  402 ) by checking the driver. If the connection is a WAN connection, then the application begins point-to-point protocol (PPP) negotiation (step  404 ).  
         [0023]    If the connection is a LAN connection, then the application retrieves the Adapter LAN settings from the CPE computing unit&#39;s operating system (step  406 ). These LAN settings can be in either of two modes. One mode is dynamic host configuration protocol (DHCP), in which the CPE does not need to know IP addresses that are temporarily assigned by the server or host. The other mode is static IP, in which addresses are fixed and are necessary to make a connection. The application determines whether DHCP is enabled (e.g., whether the system is in DHCP mode) (step  408 ). If DHCP is enabled, then the application attempts to renew the CPE computing unit&#39;s IP address lease (step  410 ).  
         [0024]    If DHCP is determined not to be enabled for a LAN connection in step  408 , then the application determines whether a gateway address is entered in the CPE computing unit&#39;s LAN settings (step  412 ). A gateway address is the address of a system through which the CPE computing unit can connect to the Internet. If a gateway address is entered, then the application attempts to open an FTP socket to the gateway (step  414 ). If no gateway address is entered in the LAN settings, then the application attempts to open a FTP socket to a known gateway, such as ftp.microsoft.com (step  416 ).  
         [0025]    The application&#39;s effectiveness does not depend upon whether the Internet connection or lease renewal requests are successful. The purpose for attempting them is to elicit a response from the head end, so that the application can check the protocol-layer headers to determine whether the head-end protocol is consistent with the protocol that the CPE computing unit driver is set to. The next step  418  in the application is to determine whether the head-end protocol has been found. If the head-end protocol has been found, then the application saves the protocol information to the DSL modem driver (step  420 ), and routes to the disconnect procedure shown in FIG. 5. If the head-end protocol has not been found, then the application routes directly to the disconnect procedure shown in FIG. 5.  
         [0026]    Referring now to FIG. 5, the disconnect procedure is accessed after each particular protocol is tested to terminate the connection, to determine whether the particular protocol at the head end has been found, and, if the particular head-end protocol has not be found, to select another protocol. The application records loop information (useful for determining loop length), bridge taps, and AM radio interference (step  502 ). The application then disconnects the line (e.g., the connection) that was previously established to test the current protocol (step  504 ).  
         [0027]    In step  506 , the application determines whether the physical layer was connected during the previous start-up procedure by checking the physical-layer data table, which would indicate errors if the physical layer was not up. If the physical layer was connected, then the application determines whether the protocol layer was found (step  508 ) by checking the protocol data table in the application.  
         [0028]    If the protocol layer was not found, as determined in step  508 , then the application checks the protocol data table to determine whether all protocols that are programmed into the application and driver have been tested (step  510 ). Since the application is preferably programmed for all known protocols, if the protocol layer was not yet found, the next untested protocol is then tested. However, if the protocol was not found and all protocols have been tested, the application will terminate and report an error to user (step  512 ).  
         [0029]    If all protocols have not yet been tested (step  510 ), then the application changes the protocol of the driver. To change the protocol of the driver, the application first disables the driver (step  514 ), changes the protocol in the driver (step  516 ), and re-enables the driver (step  518 ). By disabling the driver without terminating the application, the application is able to attempt connections using different protocols without having to re-boot the CPE computing unit&#39;s operating system before each new protocol is tested, providing a performance advantage. For a WAN connection, the application preferably selects the next protocol in order, from the following protocols that are written and controlled by the Internet Engineering Task Force (IETF) (www.ietf.org):  
         [0030]    WAN RFC2364 VCMUX;  
         [0031]    WAN RFC2364 LLC ENCAPSULATION; and  
         [0032]    WAN RFC2516 PPPOE.  
         [0033]    For a LAN connection, the application preferably selects the next protocol in order, from the following protocols that are also written and controlled by the IETF:  
         [0034]    LAN RFC1483 VC MUX ROUTED;  
         [0035]    LAN RFC1483 VC MUX BRIDGED;  
         [0036]    LAN RFC1483 LLC SNAP ROUTED; and  
         [0037]    LAN RFC1483 LLC SNAP BRIDGED.  
         [0038]    After enabling driver with the newly selected protocol in step  518 , processing proceeds to step  520 .  
         [0039]    If the physical layer was determined not to be connected in step  506 , or if the protocol layer was determined to have been found in step  508 , then the application routes directly to step  520 .  
         [0040]    In step  520 , the application checks the loop data table to determine whether all transmit gains have been tested. If all transmit gains have not been tested, then the application returns to the start-up procedure just prior to step  304  in FIG. 3 to repeat the processing of FIG. 3 with a different transmit gain level. Note that all gains are preferably tested for each DSLAM protocol in order to test physical-layer settings.  
         [0041]    If all transmit gains have been tested as determined in step  520 , then the application checks the loop data table to determine whether all DSLAM types have been tested (step  522 ). If all DSLAM types have not yet been tested, then the application returns to step  302  of FIG. 3 to repeat the processing of FIG. 3 with a different DSLAM type. If all DSLAM types have been tested, then the application searches the physical-layer data table for the best connect rate (step  524 ), records the settings that provide the best connect rate to the DSL modem driver (step  526 ), searches the loop data table for loop length, bridge taps, and AM radio interference data (step  528 ), and records that information to the DSL modem driver and saves the settings in the system to preserve across re-boots (step  530 ).  
         [0042]    Referring now to FIG. 6, in step  602 , the optimal line settings procedure sets the gain level to an initial, minimum gain level (e.g., −6 dB), which will be incremented (e.g., in 1-dB steps) to a maximum gain level (e.g., +1 dB) as the processing of FIG. 6 is repeated. The application checks an optimal setting physical-layer data table to determine whether all gain levels have been tested (step  604 ). If all gain levels have not yet been tested, then the application determines whether the connection is a WAN or LAN connection (step  606 ) and starts either a DUN WAN connection (step  608 ) or a LAN connection (step  610 ). After verifying that the physical layer is up (step  612 ) and that the ATM layer is up (step  614 ), the application records physical-layer data (e.g., transmit rate, receive rate, and receive average margin) (step  616 ) and, if appropriate, loop data (e.g., transmit gain, programmable gain amplifier (PGA) cutback, show time PGA, transmit state, and receive state) (step  618 ) for the current setting. The line is then disconnected (i.e., the connection is terminated) (step  620 ).  
         [0043]    If the physical layer is determined not to be up in step  612 , then errors are recorded in both the physical-layer data table (step  622 ) and the loop data table (step  624 ), before the line is disconnected in step  620 . If the physical layer is determined to be up in step  612  and if the ATM layer is determined not to be up in step  614 , then errors are recorded in the loop data table (step  624 ), before the line is disconnected in step  620 .  
         [0044]    After the application disconnects the line in step  620 , the application returns to step  602  to repeat the procedure of making a connection and recording optimal setting data with at an incremented gain level.  
         [0045]    After all gains are determined to have been tested in step  604 , the application searches the physical-layer data table for the best connection rate (step  626 ), and records the settings that provide the best connection rate (step  628 ). Next, the application searches the loop data table for the corresponding loop length, bridge taps and AM radio interference information (step  630 ), and records that data in permanent memory (e.g., in the operating system registry file) for display by other applications and the driver when it boots (step  632 ).  
         [0046]    The present invention provides an application that, when implemented on a computing unit, such as CPE  102  of FIG. 1, can determine the network-layer protocol at the head end of a DSL connection and set the DSL modem driver in the computing unit for that protocol. The present invention can also optimize physical-layer settings and provide information to determine loop length, bridge taps, and AM radio interference.  
         [0047]    The present invention can be embodied in the form of methods and apparatuses for practicing those methods. The present invention can also be embodied in the form of program code embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. The present invention can also be embodied in the form of program code, for example, whether stored in a storage medium, loaded into and/or executed by a machine, or transmitted over some transmission medium or carrier, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code segments combine with the processor to provide a unique device that operates analogously to specific logic circuits.  
         [0048]    It will be further understood that various changes in the details, materials, and arrangements of the parts which have been described and illustrated in order to explain the nature of this invention may be made by those skilled in the art without departing from the scope of the invention as expressed in the following claims. For example, the DSLAMS and protocols could be attempted in different orders. Gain levels could be set over different ranges and incremented at different increments. Additional protocols and DSLAMS could be added to the options to be attempted. Also, the invention could be applied to networks other than the Internet, such as internets or other internets.