CA2264866C - Network access methods, including direct wireless to internet access - Google Patents

Abstract

A method is provided for connecting a source of digital data to a computer network. The source of digital data transmits data over a wireless transmission medium to a wireless service carrier, the wireless service carrier multiplexing the digital data onto a high speed digital telephone line. The method comprises the steps of receiving the digital data at a communications chassis such as a network access server, extracting, from the digital data, network access authentication data comprising at least one of the following: (a) a telephone number called by the source of digital data, or (b) a telephone number associated with the source of digital data;
transmitting the authentication data over a local area or wide area computer network connected to a network authentication server for the computer network;
determining, in the network authentication server, from the transmitted authentication data whether the remote user is permitted to access the computer network; and the authentication server responsively notifying the network access server the results of the step of determining; and authorizing the source of data to access the computer network if the step of determining results in a positive response.

Description

l015202530CA 02264866 2002-07-1876909-100NETWORK ACCESS METHODS, INCLUDING DIRECT VVIRELESS TOINTERNET ACCESSBACKGROUND OF THE INVENTIONA. Field of the InventionThis invention relates to the field of data communicat:ion and moreparticularly to a method of connecting a wireless user generating digital data (forexample,’ a computer having a cellular telephone modem) to a computer network,such as a corporate backbone LAN or the Internet.B. Description of Related ArtNetwork access servers that provide local or wide area network access forremote users dialing in over the public switched telephone network are known in theart. These devices are available from 3COM Corporation (previously from US.Robotics Access Corp.), the assignee of the present invention. The Total ControlNetwork Enterprise Hub from 3COM is a representative network access server. It isdescribed in U.S. Patent 5,577,105 of Baum et al., entitled “Telephone Call Switchingand Routing Techniques for Data Communications,” and US. Patent 5,528,595 of L‘ Walsh et al., entitled “Modem Input/Output Signal Processing Techniques.”The network access server described in the Walsh et al. and Baum et al.patents provides an interface to a multiplexed digital telephone line, a plurality ofmodems for performing signal conversions for the data fiom the remote users, and anetwork interface for transmitting demodulated firom the modems «onto a local orwide area network. A high speed midplane bus structure comprising a time divisionmultiplexed bus provides a signal path between the channels of the telephone line andthe modems. The high speed midplane also includes a parallel bus that couples themodems to the network interface.This network access server architecture in a single chassis has proven to bevery popular in a variety of applications, particularly corporate network access. The1015202530W0 99/01969CA 02264866 1999-03-02PCT/US98/13858network access server is also particularly popular with Internet service providers forland-based Internet users. With a single network access server, the Internet serviceprovider can handle a large number of simultaneous Internet access calls and providefull duplex communication between the multiple remote users and host computers onthe Internet.The technology for Internet access for wireless users is now emerging. Thereare two competing standards for wireless service, CDMA (Code Division MultipleAccess, described in the standards documents IS-130 and IS-135, incorporated byreference herein) and TDMA (Time Division Multiple Access, described in standardsdocument IS—99, also incorporated by reference herein). These standards specify afeature rich sets of digital wireless communications, for both voice and data. The twostandards differ in how digital data from multiple users are multiplexed on the radiointerface.In accordance with both wireless technologies, a wireless user transmits datato a mobile switching center. The mobile switching center provides connectivity tothe public switched telephonenetwork, certain multiplexing and control functions,and switching functions for the mobile users. Multiplexed digital data from a pluralityof remote wireless users is then capable of being transmitted via high speedcommunication formats (such as Frame Relay) to communication elements in thepublic switched telephone network.The present invention provides for network access methods and apparatus thatare particularly suitable for wireless users. The present invention also provides fornetwork access methods by which a network access server, in combination with one ormore authentication servers, can provide for Internet and corporate networkauthentication and access. The network access server provides for the functionsneeded for terminal equipment connected to a TDMA or CDMA mobile telephone tointer-work with terminal equipment connected to the public switched telephonenetwork (PSTN) and the Internet. Further, the invention provides for Internet accessmethods for a plurality of remote users that are subscribers of more than one Internetservice provider, thereby giving more flexibility in the ability of a particular Internetservice provider to serve diverse Internet users.101520.2530nu: - 7CA 02264866 2002-07-1876909-100SUMMARY OF THE INVENTIONAccording to a first broad aspect, the invention providesa method for connecting a source of digital data to a_computernetwork, the source of digital data generating digital data and communicating over awireless transmission medium to a wireless service carrier. The wireless service carriermultiplexes the digital data onto a high speed digital telephone line for transmission toa communications chassis or sewer providing network access. The method comprisesthe steps of receiving the digital data at the communications chassis and extracting,from the digital data, network access authentication data comprisingat least one of thefollowing: (a) a telephone number called by the source of digital data, or (b)' atelephone number associated with the source of digital data. The communicationschassis transmits the authentication data over a local area or wide area computernetwork connected to the network access sewer to a network authentication server forthe computer network. The network _ authentication server determines from thetransmitted authentication data whether the remote user is permitted to access thecomputer network. The authentication server responsively notifies the network accessserver the results of the step of determining. The remote user‘ is authorizes to accessthe computer network if the step of determining results in a positive response.The method may also comprise the further step of identifying a tunnelingserver linked via a local area or wide area network to the communications chassis tobe used to provide access for the source of digital data to the computer network, androuting digital data from the source to the tunneling server to provide the access to thecomputer network. The identification of the tunneling server is determined from theauthentication data from the remote user, such the remote user’s phone number or thedialed number.determining, in the authentication server, a tunneling protocol for the source of digitalIn this embodiment, the invention may also be practiced bydata for use in tunneling digital data between the communications device and thetunneling server. This step of determining may be practiced, for example, by lookingin a software look up table the tunneling server and required protocol associated withthe remote user (identified, for example by the remote user’s telephone number).The digital data is routed via the tunneling server in accordance with the tunnelingprotocol. Either PPTP or TELNET protocols will be used in accordance with apreferred embodiment of the invention.l015202530MIN. IVCA 02264866 2002-07-1876909-100A second phase of access authentication may beoptionally provided, comprising a password authenticationroutine that takes place between the remote user and theauthentication server or the tunneling server.According to a second broad aspect, the inventionprovides an Internet access method for use by an Internetservice provider having a communications device receivingtelephone calls from a user over a high speed telephoneline. The method includes connecting the communicationsdevice to an authentication server over a local or wide areanetwork. Network access authentication data having at leastone of a telephone number called by the user or a telephonenumber associated with the user is extracted from anincoming call from the user. The network authentication"data is routed to the authentication of the user from thenetwork access authentication data. A tunneling server isidentified for providing network access for the user andnotifying the network access server of the tunneling server.Digital data is tunneled from the network access server tothe tunneling server and the digital data is placed onto theInternet by the tunneling server.According to a third broad aspect, the inventionprovides a method of connecting a computer generatingdigital data to the Internet. The digital data is placedonto a high speed digital telephone line for transmission toan Internet service provider. The method includes the stepof receiving the digital data at a communications device atthe Internet services provider. Internet accessauthentication data having at least one of a telephonenumber called by the source of digital data or a telephonenumber associated with the computer is extracted from thedigital data. The authentication data is transmitted to al015202530CA 02264866 2002-07-1876909-100network authentication server. In the networksauthentication server, whether the remote user is authorizedto access the Internet via the network access server isdetermined from the transmitted authentication data. Theauthentication server responsively notifies the networkaccess server the results from the authorization of thecomputer to access the Internet when the remote server isauthorized.According to a fourth broad aspect, the inventionprovides an Internet service provider system for a wirelessInternet user. The system has a network access serverhaving a high speed digital telephone line interfacereceiving calls from the wireless Internet user and anInternet gateway for placing digital data associated withthe wireless Internet user onto the Internet. An Internetaccess authentication server is linked to the network accessserver via a communications medium. The Internet accessauthentication server is responsive to Internet accessauthentication data extracted from the digital dataassociated with the wireless Internet user received by thenetwork access server and is transmitted from the networkaccess server to the authentication server. Theauthentication server has a memory for determining, from theInternet access authentication data, whether the wirelessInternet user is authorized to access the Internet.Furthermore, the Internet authentication server responsivelypasses an authentication response to the network accessserver. The network access server is responsive to theauthentication response from the authentication server toeither allow the wireless Internet user to access theInternet or to take other action with respect to a call fromthe wireless Internet user.4aHIM. Ii VCA 02264866 2002-07-1876909—lOOA principal object of the invention is thus toprovide direct access to the Internet and other computernetworks for remote users such as wireless users. This, andother objects of the invention will be more apparent fromthe following detailed description.4b W0 99/019691015202530CA 02264866 1999-03-02PCT/US98/13858BRIEF DESCRIPTION OF THE DRAWINGSPresently preferred embodiments of the invention will be described inconjunction with the drawings, in which like reference numerals refer to like elementsin the various views, and in which:FIG. 1 is an illustration of an example of a preferred network access system forwireless users in accordance with an embodiment of the invention;FIG. 2 is a simplified functional block diagram of a preferred form of thecommunications chassis of FIG. 1 that can service not only wireless users but alsousers dialing in over the public switched telephone network;FIG. 2A is a simplified block diagram of a communications chassis suitable inan embodiment in which analog modern calls are not supported;FIG. 3 is an illustration of the protocol stacks for the tunnel interface betweenthe remote user and the tunneling server of FIG. 1;FIG. 4 is an illustration of the protocol stacks for authentication andaccounting interface between the communications chassis and the authenticationserver of FIG. 1;FIG. 5 is an illustration of the protocol stacks for a non—tunneling interfacebetween the remote dial user and the router connecting the user with a destinationterminal equipment;FIG. 6 is a diagram of the call flow for PPTP protocol tunneling for a callacceptance scenario in accordance with a preferred embodiment of the invention;FIG. 7 is a diagram of the call flow for TELNET protocol tunneling for a callacceptance scenario in accordance with a preferred embodiment of the invention;FIG. 8 is a diagram of the call flow for an authentication failure scenario;FIG. 9 is a diagram of the call flow for a tunneling server access rejectionscenario;FIG. 10 is a diagram of the call flow for an authentication failure scenario forthe PPTP protocol in which a log-in password authentication procedure is performedas a second phase of a network access authentication procedure; andFIG. 11 is a diagram of the call flow for an authentication failure scenario forthe TELNET in which a log-in password authentication procedure is performed as asecond phase of a network access authentication procedure.51015202530WO 99/01969CA 02264866 1999-03-02PCT/US98/13858DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTFIG. 1 is an illustration of a preferred network access system 10 for users ofwireless equipment 12, 14 that can be used to practice the invention. Remotedevices such as a laptop computer 12 with a wireless modem or a wireless personaldata assistant (PDA) 14 communicate via wireless modem to a wireless digitalcommunications network 16 in accordance with the TDMA (Time Division MultipleAccess) or the CDMA (Code Division Multiple Access) standards.The wireless network 16 includes a Mobile Switching Center (MSC) (notshown), which is an element within the wireless telecommunications network 16 thatprovides public switched telephone network connectivity, control functions andswitching functions for the wireless users. In the embodiment of FIG. 1, the MSCplaces data from the remote wireless users onto a high speed digital frame relay lineFR for transmission to a communications chassis 20 in the local calling area. In apreferred embodiment, the communications chassis 20 comprises an integratednetwork access server such as the Total Control Network Enterprise Hub of 3ComCorporation (formerly from U.S. Robotics), modified to interface with the frame relayline FR and perform tunneling, authentication and accounting functions as describedbelow.The communications chassis 20 functions as a gateway between theCDMA/TDMA wireless network 16 and an Internet service provider (ISP) backbonenetwork 26, the Internet 22, or other computer network such as a corporate or privateLAN/WAN 24 via an Ethernet or other local area network ETH and the Internetservice provider backbone network 26. The chassis 20 provides the functions neededfor terminal equipment connected to a CDMA or TDMA mobile phone tointercommunicate with terminal equipment connected to the PSTN and Internetnetworks. In one possible and presently preferred embodiment, the communicationschassis 20 is installed at the telephone company central office (TELCO CO) andmanaged by an Internet Service Provider (ISP).- The chassis 20 receives calls fromwireless users 12, 14 via the MSC in the wireless network 16 as local calls on the lineFR.10152025'30HIM! llCA 02264866 2002-07-1876909-100The wireless terminals 12, I4 access the corporate/private network 24 using atunneling protocol over LAN or WAN line 28 between the communications chassis20 and a tunneling server 30. The tunneling server is connected to a corporate/privatenetwork 24 and is connected via a backbone network 26 connected to thecommunications chassis 20. In a preferred embodiment, the tunneling is according toa Point~to—Point Tunneling Protocol (PPTP) described in theInternet Engineering Task Force Request for Comments (RFC)(PPTP) ,2637, entitled Point—to—Point Tunneling ProtocolK. Hamseh et al., July 1999, available on the internet atwww . ietf . org . The tunneling could of course be in accordance with other emergingand equivalent protocols, such as L2TP. Since PPTP and L2TP are not designed tosupport non-PPP (Point-to-Point) Asynchronous protocol, the TELNET protocol isused to tunneling non-PPP asynchronous traffic over line 28. The tunneling server isalso preferably an integrated network access server such as the Total ControlEnterprise Network Hub or the equivalent.With this architecture, it is possible to divorce the location of the initial dial-upserver (communications chassis 20) from the location at which the intermediatenetwork terminates the dial-up protocol connection (PPP) and provides access to thetarget network 22 or 24 at the tunneling server 30. In addition to supporting theInternet 22 as the target network, this architecture also supports access to virtualprivate networks, allowing the remote wireless user to gain secure ac:cess to theircorporate or private network such as the corporate enterprise network 24 illustrated inFIG. 1.The architecture also allows the Internet Service Provider operating the localcommunications chassis 20 at the central office to provide Internet access; for not onlythe ISP’s customers, but also customers of other Internet service providers. This isachieved by use of one ‘or more authentication servers 32A, 32B connected to theInternet service provider’s backbone network 26. The authentication servers 32A,32B perform authentication and access authorization for the first ISP’s customers. Asecond tunneling server 34 is connected" via a dedicated line 36 (or LAN or WAN) orotherwise to a second ISP’s backbone network 38. In this embodiment, theauthentication server 32A has a profile of its customer base for the first ISP managingthe communications chassis 20 and can determine, using a variety of simple(discussed below) whether the the7techniques remote user dialing intoW0 99/019691015202530CA 02264866 1999-03-02PCT/US98/13858communications device 20 is allowed to access the Internet 22 via the ISP’s backbone26. If access is allowed (due to the call originating from one of the first Internetservice provider customers), the call is routed through the network 22 to the Internet.If not, other procedures, described below, can be initiated.The present invention takes advantage of the fact that the call from the remoteuser 12 contains infonnation identifying the telephone number of the call originator,and the telephone number that is dialed. This information is used as a first stageauthentication mechanism. When the authentication server 32A performs the firstphase authentication and determines that the remote user is not one of the first Internetservice provider’s customers (due to, for example, the telephone number not matchingup to a table of customer phone numbers), but rather is a customer of a second Internetservice provider, the authentication server 32A directs the authentication request to asecond authentication server 40 connected to the second Internet service provider’sbackbone 38, and the first phase authentication can take place. This communication isfacilitated by providing a dedicated line 42 (e.g., leased line, POTS line, etc.) betweenthe authentication server 32A and the authentication server 40 managed by a secondInternet service provider.If the authentication results in a positive response, the authentication server 40notifies authentication server 32A of the result and the remote wireless user 12 iseither given Internet 22 access over network 26 or via tunneling server 34, or anoptional second phase pass-word type authentication may take place between theremote user 12 and the second authentication server 40.These combination of features allow the ISP or other entity managing thecommunications chassis 20 and authentication server 32A the ability to significantlyincrease the features it provides to its customers. It also allows the ISP to provideInternet access for other Internet service providers, and in the process presumablygenerate revenue for such services. For the wireless users, the Internet or corporatenetwork access is a matter of a local call through the wireless network 16 to thecommunications device 20.In a preferred form of the invention, the communications chassis 20 is a robustcommunications platform such as the Total Control Enterprise Network Hubincorporating an integral general purpose computing platform, i.e., the EdgeServer TM81015202530I nu ‘ __..CA 02264866 2002-07-18 '76909-100card commercially available fiom 3COM. This product allows the communicationschassis to run a commercially available stand alone operating system, such asWINDOWS NT 7” from Microsoft Corporation, as well as other remote accesssoftware products such as RADIUS (Remote Authentication Dial In User Service). Inthe above-described Internet access methods, the accounting and authenticationfunctions are preferably employed using the RADIUS protocol, which is a widelyknown protocol described in the Internet Engineering TaskForce Request for Comments (RFC) 2058, entitled RemoteAuthentication Dial In User Service (RADIUS), C. Rigney,A. Rubens, W. Simpson, S. Willens, dated January 1997 andavailable on the internet at www.ietf.org, or othercommercially available or known accounting software programs.In accordance with a preferred embodiment of the invention, two phases ofauthentication are implemented in order to control access to the Internet 22 or .corporate/piivate network 24 to those wireless usersthat are permitted access vianetwork 26. The first phase of authentication is based on the called number dialed bythe remote user 12, 14 and the calling number of the wireless user 12, 14 (the user’sphone number associated with the computer '12 or PDA 14). The second phase of the-authentication is based on a test user name and password authentication protocol (forPPP and TELNET tunneling) or Challenge/Response protocol (for PPP tunnelingonly). These authentication procedures are described in further detail below. ,Still referring to FIG. 1, the communications device 20 also preferablysupports non‘-tunneling Internet 22 access directly from an Internet interface in thecommunications device. With this feature, the communications device performs bothphases of authentication, termination of the PPP protocol, and routes Internet Protocoltraffic.One other possible embodiment of the invention is a scenario in which thecommunications device 20 provides direct PSTN (Public Switched TelephoneNetwork) connectivity for mobile or land originated data calls. In this scenario, thecommunications chassis 20, such as the Total Control Network Enterprise Hubdescribed previously, contains the required modems and telephone line interface andprocessing circuitry to perform these functions. This embodiment would be aparticularly advantageous in the case where the Internet service provider is also theI With the present Internet access invention, thelocal telephone company.communications device 20 will extract or screen the called number in the ATD9W0 99/0196910I5202530CA 02264866 1999-03-02PCT/US98/1 3858command issued by the mobile data user during a mobile originated data call. Formost called numbers, the communications device 20 processes the call as a standardPSTN modern call. However, if the called number is associated with Internetaccess, the communications chassis 20 will perform the first phase of authenticationwith an authentication server 32A associated with the called number (either on theISP’s backbone network 26 or connected via dedicated line 36, 42 or other network tothe communications chassis 20). The authentication server 32A determines whetherthe remote user is authorized to access the Internet 22 or network 24 serviced by theauthentication server 32A.FIG. 2 is a simplified functional block diagram of a preferred form of thecommunications chassis or network access server 20 of FIG. 1 that can service notonly wireless users but also users dialing in over the public switched telephonenetwork. As such, the chassis contains features that are not required to practice theinvention, and which perform additional functions due to a particular embodiment ofthe invention in which PSTN connectivity is also enabled. The network access server20 shown in FIG. 2 is essentially the architecture and design of the current model ofthe Total Control Network Enterprise Hub, the commercially available product of theapplicant’s assignee. It will be understood that integrated access servers of othermanufacturers in the industry can be modified as needed to provide the features of thepresent invention, and the invention should not be considered limited to the particularpreferred embodiment described herein.The network access server 20 includes the telephone network interface card 50connected to time division multiplexed digital telephone lines such as T1, El andISDN Primary Rate Interface (PRI) lines as well as a frame relay line. The networkinterface card receives digital data from the wireless remote users via the wirelessservice switch on the Frame Relay line FR. The interface card 50 has connectors thatphysically receive the telephone lines, and a CSU line interface unit to recover clocksignals and data from the incoming signals and perform multiplexing anddemultiplexing functions for outgoing and incoming data streams to place the callsinto the time slots of the carrier. The card 50 transmits the incoming telephonesignals via a NIC/NAC (network interface card/network application card) bus 54 to aT1/E1/ISDN PRI/ network application card 56. The application card 56 provides10l0I520‘2530CA 02264866 2002-07-1876909-100framing for the recovered telephone line data to extract the Frame Relay time divisionmultiplexed data, T1 DSO channel data, or ISDN 2B + D channel data incorporated 6into the ISDN PR1 signal, and then switches with a time/space switch the channeldata to time slots on a time division multiplexed bus 60 that is part of an internalchassis bus midplane 52. IWhere the incoming call is from the wireless service central office and arrivesat the server on the Frame Relay line, the channel data does not need any signalconversion processing ordinarily performed in a modem and is routed over the TDMbus 60 to the routing and LAN/WAN interface card 62. In the Total ControlEnterprise Network Hub, this card 62 is known as the “EdgeServer””‘ card, andcompeting network access devices from Ascend, Livingston and other manufacturershave analogous interfaces. The “Edgeserver” TM card 62 has a pair of Munichs chipsthat assemble packets of data in accordance with TCP/IP protocol for transmission tothe destination directly via the LAN/WAN interface or via a tunneling server.For calls that are originating from users connected to the public switchedtelephone network and signal transformations are required, the TDM. bus 60 directsthe calls to modems in multiple modem modules or cards 64. The internal chassis bus52 further includes a high speed parallel packet bus 58 connecting the modems in thecards , 64 to the Edgeserver “'1 card 62 for transmission of the data afterdemodulation/signal conversion to the routing engine in the Edgeserver card 62. Aplurality of analog network interface cards 63 for connecting the modems up to aserial interface 65 are also provided.The telephone line interface and application cards 50 and 56, respectively.modem cards 63 and 64, intemalchassis buses complex 52 (including TDM andparallel buses 60 and 58, respectively), and computer network interface 66 of theEdgeserver TM card 62 are described in great detail in temis of their componentcircuitry and operation in the above—referenced U.S. Patent 5,577,105 of ‘Baum et al.,entitled “Telephone Call Switching and Routing Techniques for DataCommunications,” and U.S. Patent 5,528,595 of Walsh et al., entitled “ModemInput/Output Signal Processing Techniques”. The detailed structure of a preferredinternal chassis bus is described in U.S. Patent No. 5,416,776 to Panzarella et al.,entitled “Modem Backplane Techniques”, also assigned to 3COM Corporation.11llllll llCA 02264866 2002-07-1876909-10010015202530The management of a chassis by a managementcard is also described in detail in U.S. Patent No. 5,436,614 to Panzarella et al.,entitled “Modem Management Techniques,” which is also assigned to 3COMCorporation . These elements are also describedin the publicly available operators manual for the Total Control Network EnterpriseHub product, which is also incorporated by reference herein.The Edgeserver TM card 62 contains a general purpose computing platform70 runningcommercially available stand-alone or share ware operating system (suchas WINDOWS_ NT TM). The card 62 is described in more detail in -U.S. Patent No. 6,249,527, William Verthein et al.Since the details of the telephone line interface and application cards, modemcards, management cards (not shown) and computer network interface 66 of the card62 exist in publicly available products, are already described elsewhere in publiclyavailable documents, and persons skilled ‘in the art already know how to build anddesign such circuits (or equivalent circuits), a detailed discussion of these componentsof the communication access chassis 10 is not necessary. Additionally, the details asto the architecture or design of the communication chassis 10 is not particularlyimportant.The Edgeserver card 62 includes a TDM interface 72 that receives channeldata from the frame relay FR line via the TDM bus 60. The computing platform 70consists of an off~the shelf IBM compatible personal computer with a integral centralprocessing unit 74, and peripheral interfaces for a keyboard, floppy disk, monitor andmouse. The computing platform also includes an internal storage hard disk drive 76.The computing platform also includes packet assembly and disassembly circuitry 78that assembles packets of data from the modems in the modem modules 64 intoformats suitable for use by the general purpose computing platform 70. The generalpurpose computing platfonn communicates with a conventional network interface 66via a NIC/NAC bus connect 80. l The computing platform also communicates via asecond ISA bus 82 to an external storage expansion bus interface: 84, which isconnected to external disk. drives or other suitable storage devices to increase thememory capacity of the communications chassis 20. In a preferred embodiment, the12WO 99/019691015202530CA 02264866 1999-03-02PCT/US98/13858software for running tunneling and authentication functions described below in thecommunications chassis 20 is loaded in the general purpose computing platform 70 inthe EdgeServer TM card 62.As noted above, the architecture and features provided by the communicationschassis of FIG. 2 provides more features than will ordinarily be necessary tointerconnect the remote users on the wireless network to the ISP backbone, corporatenetwork or Internet. FIG. 2A is simplified schematic diagram of an alternative devicewithout modems which would be suitable for an embodiment in which PSTNtermination functions are not provided for the communications device. In theembodiment of FIG. 2A, a frame relay interface 100 comprising line interface unit,Theinterface 100 places channel data on time slots in a TDM bus complex 102 whichconnects the interface 100 with a LAN/WAN interface 104. The LAN/WANconsists of an off-the-shelf Ethernet or other standarddemultiplexing circuitry and framing circuitry is provided in one module.interface 104 preferablyinterface modified with a general purpose computing platform loaded with software toperform the call routing, authentication, tunneling and other features described herein.With the above FIG.s 1 and 2 and 2A in mind, it will be appreciated that amethod of connecting a source 12 of digital data to a computer network 24, 22 (e.g.,corporate private network, Internet, World Wide Web, etc.) is provided. The source ofdigital data 12 generates digital data and communicates over a wireless transmissionmedium to a wireless service carrier. The carrier multiplexes the digital data onto ahigh speed digital telephone line, e.g., line FR. The method comprises the steps of(1) receiving the digital data at a network access server or communicationschassis 20 and extracting, from the digital data, network access authentication datacomprising at least one of the following: (a) a telephone number called by the source12 of digital data, or (b) a telephone number associated with source of digital data;(2) transmitting the authentication data over a local area or wide areacomputer network connected to the communications device 20 to a networkauthentication server 32A or 32B for the computer network 24 or 22, the networkauthentication server linked via the local area or wide area computer network 26 to thecommunications chassis 20; and13W0 99/019691015202530CA 02264866 1999-03-02PCT/US98/1 3858(3) determining, in the authentication server 32A, from the transmittedauthentication data whether the remote user is permitted to access the computernetwork 22 or 24. The authentication server 32A responsively notifies thecommunications chassis 20 the results of said step of determining and authorizes thesource 12 of data to access the computer network 24 or 22 if the step of determiningresults in a positive response.The method may also comprise the further step of identifying a tunnelingserver 30 or 34 linked via a local area or wide area network 26 to the communicationschassis 20 to be used to provide access for the source 12 of digital data to thecomputer network, and routing digital data from the source 12 of digital data to thetunneling server 30 to provide the access to the computer network 24. Theidentification of the tunneling server is determined, in a preferred embodiment, by theauthentication data extracted from the incoming call (i.e., the dialed number and thedialing number). In this embodiment, the invention may also be practiced bydetermining, in the authentication server 32A or 32B, a tunneling protocol for thesource 12 of digital data for use in tunneling digital data between the communicationsdevice 20 and the tunneling server 30. This step of determining may be practiced, forexample, by looking in a software look up table the tunneling server and requiredprotocol associated with the remote user 12 (identified by the remote user 12telephone number). The digital data is routed via the tunneling server in accordancewith the tunneling protocol. Either PPTP or TELNET protocols will be used inaccordance with a preferred embodiment of the invention.alsoIn a preferred embodiment, communications chassis 20 of FIG. 2provides access to the public switched telephone network via the T1/El/ISDNinterface 50/56. The communications chassis 20 routes digital data to a destination forthe digital data from the remote user 12. In this fashion, the communications chassis20 provides not only direct network access to computer networks 22 and 24 but alsoprovides signal modulation via modems in the chassis to allow the call to transmittedvia the telephone network to a remote terminal such as computer 13 in FIG. 1. Themanner in which the communications chassis 20 provides PSTN connectivity isknown in the art and described in the above-cited Walsh et al. patent.14W0 99/019691015202530CA 02264866 1999-03-02PCT/US98/ 13858In a preferred network access embodiment of the invention, a second phaseauthentication routine is employed to verify that the remote user is authorized toaccess the designated network. This is a accomplished by conducting a passwordauthentication procedure such PAP or CHAP routine, both of which are known in theart, between either (1) the tunneling server 30 or (2) the authentication server 32A andthe remote user, or (3) between authentication server 32A and tunneling server 30/34,thereby providing a second level of authentication.In one specific embodiment of the invention, an Internet access method isprovided for use by an Internet service provider having a network access server orcommunications chassis 20 receiving telephone calls from a user 12 over a high speedtelephone line, comprising the steps of 2(1) connecting the network access server 20 to an authentication server(e.g., 32A or 32B) over a local or wide area network 26;(2) extracting, from an incoming call from the user 12, network accessauthentication data comprising at least one of the following: (a) a telephonenumber called by the user, or (b) a telephone number associated with the user;(3) routing the network authentication data extracted from the incomingcall to the authentication server 32A or 32B for authentication of the user fromthe network access authentication data;(4) identifying a tunneling server (e. g. 34) for providing network access forthe user and notifying the communications chassis 20 of the tunneling server;and(5) tunneling digital data from the communications chassis 20 to thetunneling server 34; and(6) placing said digital data onto the Internet by said tunneling server.In a preferred embodiment, the method is accompanied by a process ofidentifying a tunneling protocol for the user for step of tunneling. For example, theauthentication server 32A or 32 B or 40 may associate the user with a particulartunneling protocol (PPTP or TELNET) by the characteristics of the remote user, therequirements of the designated tunneling server, or otherwise. Such informationwould typically be stored in the memory at the authentication server 32A.15CA 02264866 1999-03-02W0 99/01969 PCT/US98/13858Further, the invention contemplates an Internet Service Provider system forwireless Internet users, comprising a network access server 20 (FIG. 2) comprising(1) a high speed digital telephone line FR interface receiving calls from thewireless Internet user, and an Internet gateway (e.g. WAN interface 66 in5 FIG. 2) for placing digital data associated with said wireless Internet useronto the Internet;(2) an Internet access authentication server (e.g., 32A) linked to the networkaccess server 20 via a communications medium 26 and responsive toInternet access authentication data extracted from the digital data10 associated with the wireless Internet user; and(3) the authentication server 32A further comprising a memory fordetermining from the Internet access authentication data whether thewireless Internet user 12 is authorized to access the Internet, the Intemetauthentication server responsively passing an authentication response to15 the network access server 20. The network access server 20 is responsiveto the authentication response from the authentication server to either allowthe wireless Internet user to access the Internet or to take other action withrespect to a call from the wireless Internet user. For example, the Internetservice provider may forward an authentication inquiry to another20 authentication server (e.g., 40 in FIG. 1) administered by a second Internetservice provider and see if the user a customer of the second Internetservice provider.Further details conceming the implementation of presently preferredembodiments of the invention will be discussed with reference to FIG.s 3-11.25 FIG. 3 is an illustration of the protocol stacks and architecture for the tunnelinterface between the remote user 12, the communications chassis 20, a router (notshown) in the Internet service provider backbone network 26, and the designatedtunneling server 30 or 34 of FIG. 1. In FIG. 3, the legends L1 and L2 indicate lowerlevel protocols (such as the data link layer). IP indicates the Internet Protocol. PPP30 indicates the Point-To—Point Protocol. TCP indicates the transmission controlprotocol. The term Async indicates an asynchronous protocol that may be associatedwith the remote user 12 and the TELNET protocol is used in the communications16W0 99/019691015202530CA 02264866 1999-03-02PCT/US98/ 13858chassis 20 and the tunneling server for asynchronous communications. It can beseen that the communications chassis 20 communicates with the tunneling serer eitherusing PPTP or TELNET running over the IP and lower level protocols.The communications chassis 20 communicates with an authentication server(e.g., 32A) running RADIUS to implement authentication and accounting through theUDP/IP protocol stack, as shown in FIG. 4. FIG. 4 is an illustration of the protocolstacks for authentication and accounting interface between the network access serveror communications chassis 20 and the authentication server 32A of FIG. 1. UDP is aconnection—less oriented protocol built on top of the lntemet Protocol (IP).When the communications chassis 20 communicates with the Internet 22,there is no tunneling protocol. FIG. 5 is an illustration of the protocol stacks for anon—tunneling interface between the remote dial user and the router connecting theuser with a destination terminal equipment.FIG. 6 is a diagram of the call flow for PPTP protocol tunneling for a callacceptance scenario in accordance with a preferred embodiment of the invention. InFIG. 6, the process starts with an incoming call at step 100. The call is associatedwith a particular destination telephone number (1-800-123-4567 in the illustratedexample).At step 102, the communications chassis initiates an first phase authorizationaccess routine with an authentication server (e.g., 32A or 32B) connected to thecommunications chassis over a local area network. This authentication request is asoftware structure that is forwarded to the authentication server that includes fields forthe following information: (1) the telephone number associated with the remote user(which is detected during the incoming call in accordance with known calleridentification techniques or in the manner described in the above-cited Baum et al.patent); (2) the telephone number dialed, e.g., 1-800-123-4567, again extracted inknown fashion, (3) the port id., that is, the particular channel or port number in thecommunications chassis 20 that is associated with the call, and (4) the IP address ofthe communications chassis 20.At step 104, the authentication server 32A issues an Access—Reply message tothe communications chassis 20. If the user is authorized to access the networkserviced by the authentication server 32A, the message includes an identification that17W0 99/019691015202530CA 02264866 1999-03-02PCT/US98/ 13858PPTP is the proper tunneling protocol, an identification of the tunneling server’s IPaddress, and the port number of the tunneling server to receive the call. If the remoteuser is not authorized, the procedure set forth in FIG. 8, described below, is used.At step 106, the communications chassis 20 sends an Incoming-Call-Requestmessage to the tunneling server 34. The message includes an identification of thedialing number of the remote user, the telephone number dialed, and a subaddress. Atstep 108, if the tunneling server 34 is able to accept the call, an Incoming-Call-Replymessage is sent, such as Connect if the result of the access inquiry is affirmative. Ifthe tunneling server cannot accept the call, the procedure of FIG. 9 is used.At step 110, if the Connect message was received from the tunneling server34, the communications chassis 20 sends a call accept message to the remote user overthe Frame Relay line FR and wireless network. An incoming call connect message isthen relayed at step 112 from the communications chassis 20 to the tunneling server34.At step 114, a second phase authentication procedure is preferably (butSteps 116, 118, 120, 122, 124 and 126 are self-explanatory from FIG. 6 and are part of the well known PAP and CHAP passwordoptionally) implemented.authentication protocols, with which those skilled in the art are familiar.At step 128, assuming the password authentication was successful, a messageis sent from the tunneling server 34 to the remote user 12 indicating that a PPP link isestablished via the communications chassis 20 between the remote user 12 and thetunneling server 34. At this time, transfer of packets of data in accordance with theInternet Protocol between the remote user and the host on the network 22 or 24 isaccomplished.FIG. 7 is a diagram of the call flow for TELNET protocol tunneling for a callacceptance scenario in accordance with a preferred embodiment of the invention. Theprocess is largely the same as described in FIG. 6, and self-explanatory from thefigure. The establishment of a TELNET session requires a handshaking andparameter negotiation between the communications chassis 20 and the tunnelingserver 34, as indicated in steps 130 and 132. The second phase authentication usinglogin protocols such as PAP is performed as indicated. After the login acceptancemessage is sent from the tunneling server 34 to the dial user 12, asynchronous data18WO 99/019691015202530CA 02264866 1999-03-02PCT/US98/1 3858transfer takes place via the communications server 20 and the tunneling server 34between the remote user 12 and the host on the computer network (e.g., Internet).It is possible that during the first phase of the access authorization, theauthentication server determines that the remote user is not authorized to access thedesignated network served by the authentication server (due to, for example, theremote user phone number not matching with a data base of Internet customers for theInternet service provider managing the chassis 20). One preferred way of dealing withthis scenario is shown in FIG. 8, which is a diagram of the call flow for anauthentication failure scenario. When the authentication server 32A determines thatthe remote user is not authorized, an Access—Reject message is sent from theauthentication server 32 to the communications chassis 20 This message may includea field setting forth the reason why access was denied. Such reasons may include thewrong number was dialed, the ISP does not recognize the user’s telephone number,the user is in arrears in paying monthly fees, the authentication server is out ofservice, etc. The communications chassis 20 then may either send a message to theremote user 12 to either retry later, treat the call as a PSTN/modem call and try toroute the call on the PSTN system, or simply reject the call and initiate a disconnectsequence.There may also be situations where the authentication server 32A approves theaccess to the network, but the tunneling server 30 or 34 is not able to act as amechanism for transferring data between the remote user 12 and the target network 22or 24. FIG. 9 is a diagram of the call flow for a tunneling server access rejectionscenario. The first steps 100, 102, 104 and 106 are as described above in FIG. 6. Ifthe tunneling server 34 cannot process the call, the tunneling server 30 or 34 issues anIncoming-Call-Reply to the communications chassis 20 with a message or fieldindicating that the call should not be accepted. At this point, the communicationschassis 20 may either send a message to the remote user 12 to either retry later, treatthe call as a PSTN/modem call and try to route the call on the phone system, or simplyreject the call.During the second phase authentication procedure mentioned above inconnection with FIGS. 6 and 7, the user may fail the password authenticationprocedure. FIG. 10is a diagram of the call flow for an authentication failure19WO 99/019691015202530CA 02264866 1999-03-02PCT/US98/13858scenario for the PPTP protocol in which a log-in password authentication procedure isperformed as a second phase of a network access authentication procedure. At step140, an access reject message is sent to the tunneling server 30/34 from theauthentication server 32A. At this point (step 142) the tunneling server sends a loginreject message to the remote user 12.FIG. 11 is a diagram of the call flow for an authentication failure scenario forthe TELNET in which a log-in password authentication procedure is performed as asecond phase of a network access authentication procedure. The process proceedsessentially as described above.Still further details on the presently preferred implementation of PPTP andTELNET tunneling, accounting, and phase 1 and phase two authentication, as set forthherein, are described below.Protocol InterfaceThe communications chassis 20 interfaces with the Dial-user (wirelessterminal), MSC, Router, Authentication Server, and Tunneling Server. Thisspecification is only concerned with the communications chassis interfaces to theAuthentication Server and the Tunneling Server. The other interfaces will be apparentto those skilled in the art.PPTP TunnelingPPTP tunneling is enabled based on the Login-Service attribute from theRADIUS Access—Reply message during the phase one authentication. If the protocoltype has value PPTP (TBD in RFC 2058), a PPTP tunnel will be setup between thecommunications chassis and the Tunneling Server to tunnel further traffic from thecaller.The communications chassis gateway is equivalent to the PAC (PPTP AccessConcentrator) in the PPTP RFC and the Tunneling Server is equivalent to the PNS(PPTP Network Server) in the PPTP RFC. In the following PPTP description, we usethe terms PAC and PNS.20W0 99/0196910152530CA 02264866 1999-03-02PCT/US98/13858For each configured PPTP PAC-PNS pair, the interface between the PAC(communications chassis) and PNS (Tunneling Server) consists of two parallelcomponents:1. A Control connection operating over TCP.2. An IP tunnel that transports encapsulated PPP packets for user sessionsbetween the pair.PPTP Control ConnectionBefore PPP tunneling can occur between a PAC and PNS, a control connectionmust be established between them. The control connection is a standard TCP sessionover which PPTP call control and management information is passed. The controlsession is logically associated with, but separate from, the sessions being tunneledthrough a PPTP tunnel.For each PAC-PNS pair both a tunnel and a control connection exist. Thecontrol connection is responsible for establishment, management, and release ofsessions carried through the tunnel. It is the means by which a PNS is notified of anincoming call at an associated PAC, as well as the means by which a PAC isinstructed to place an outgoing dial call (this scenario is not supported at this time).The PPTP RFC does not specify when to set up each control connection. Thisis up to the implementation. To reduce call setup time, the PAC (communicationschassis) will establish the control connections at initialization.PPTP Tunnel ConnectionPPTP requires the establishment of a tunnel for each communicating PAC-PNS pair. The tunnel is used to carry all user session PPP packets for sessionsinvolving a given PAC-PNS pair. A key which is present in the GRE header indicateswhich session a particular PPP packet belongs to. In this manner, PPP packets aremultiplexed and de-multiplexed over a single tunnel between a given PAC-PNS pair.The value to use in the key field is established by the call establishment procedurewhich takes place on the control connection.21CA 02264866 2002-07-1876909-100PPTP Control Connection MessagesControl Connection Management Messages:These messages consist of the following messages0 Start-Control-Connection—Request5 0 Start-Control-Connectiom Reply0 Stop-Control-Connection—Request0 Stop—Control-Connection—Reply0 Echo-Request0 Echo—Reply 10Call Management Message:These messages consist of the following messages:0 Outgoing—Call—Request (not supported at this time)0 Outgoing—Ca1l-Reply (not supported at this time)15 0 Incoming-Call-Request0 Incoming—Call-Reply- Inc0ming—Ca1l-Connected0 Call-Clear-RequestI" o Ca1l~Disconnect-Notify20Error Reporting ~0 WAN-Error-NotifyPPP Session Control25 0 Set-Link~InfoPPTP Tunnel Connection MessagePPTP Data PDQ:Each PPP frame is encapsulated in a GRE (Generic Routing Encapsulation30 Header, described in the Reouest For Comments (RFC) 1701 (October, 1 994).22l01520'2530— um: _.CA 02264866 2002-07-1876909-100Telnet Tu'nneling _The PPTP and LZTP protocols are not designed to tunnel Asynchronoustraffic. A synchronousitraffic will be tunneled via the Telnet Protocoldescribed in the Internet Engineering Task Force Request forComments (RFC) 843, entitled Telnet Protocol Specification,J. Postel, J.K. Reynolds dated May 1, 1983, available on theinternet at www. ietf . org .The Telnet implementation must support the Telnet commands and options,such as ECHO, linemode, binary, and SUPPRESS GO AHEAD. The TunnelingServer must be able to request on a given Telnet session a switch fro-m one modeanother in the middle of a Telnet connection, such as going from ECHO to NOECHO, linemode and, subsequently, to binary transmission. In addition, the escapefunctionality must be disabled in the communications chassis gateway to prevent thedial user from entering local mode on the communications chassis gateway.Telnet tunneling is enabled based on the Login—Service attribute from theRADIUS Access-Reply message during phase one authentication. If the Login—Service attribute has value Telnet, a Telnet tunnel will be set up between thecommunications chassis and the Tunneling Server to tunnel further traffic from thecaller.RADIUS Authentication InterfaceTwo phases of authentication will be used. The first phase of authentication isbased on calling number, called number, and communications chassis IP address. Thesecond phase authentication is based on user name, password, and/orchallenge/response (optional).This section specifies both the first phase and the second phase RADIUSauthentication exchange. When using one of the tunneling options, the end userauthentication will be done by the Tunneling Server during the second phaseauthentication, which is transparent to the communications chassis. With non-tunneling Internet access, the communications chassis performs both phases ofauthentication (and may optionally skip the first phase).The following general operations apply to the RADIUS interface:1. This document complies with the IETF RADIUS Authentication RFC2058. The Authentication Server provides the RADIUS server functions23101520MIN; llCA 02264866 2002-07-1876909-100specified in the Internet Engineering Task Force RequestfOr Comments (RFC) 2058, entitled Remote AuthenticationDial In User Service (RADIUS), C. Rigney, A. Rubens, W.Simpson, S. Willens, dated January 1997, available on theinternet at www.ietf.org. The communication chassis andTunneling Server implement the RADIUS client; functions.The communications chassis shall be able to associate at least twoAuthentication Servers -with each special Internet access called number.These two (or more) Authentication Servers will provide pn'mary"andsecondary RADIUS authentication server functions. Each AuthenticationServer will be identifiable with a configurable server IP address and UDPport. The Intemet access called numbers may or may not share —Authentication Servers. 1The RADIUS shared secret I to 15 characters) will be configuredadministratively per server. This specification does not address howshared secrets are managed across communications chassis gateways andRADIUS nodes (Authentication Servers), but such details are within thecapability of persons skilled in the art.The communications chassis gateway implements a re—transn1it algorithmthat allows for Access—Requests to be lost. A configurable re—transmissioncounter determines when the Authentication Servers are out of Service for Va particular Internet access called number, in which A case thecommunications chassis optionally follows standard PSTN/modem accessprocedures.Phase 1 Authentication InterfaceAccess—Reguest Message: _The RADIUS Access-Request Message will be sent to the RADIUS server25 (the Authentication Server 32A) by communications chassis 20 to indicate anincoming call. The following list of attributes are sent along with the message:User—‘Name: Set to VENDOR—ID for all incoming calls0 User—Password: Set to null0 NAS-IP.-Address: Set to IP address of the communications chassis30NAS-Port: The port number or any other identifier that can be associatedwith the caller on the communications chassis.24W0 99/0196910152530CA 02264866 1999-03-02PCT/US98/13858Ca11ed—Station-Id: The called number dialed by the user. This will be usedto identify the service desired by the caller.Calling-Station-Id: The caller’s number or telephone identifier. This maybe used for phase I authentication.NAS—Port-Type: Specifies the type of port used by the user on thecommunications chassis switch: (TBD value for wireless access in RFC2058).Access-Accept MessageThe RADIUS Access-Accept Message is sent by RADIUS (AuthenticationServer) to the communications chassis 20 to indicate the acceptance of the incomingcall for the specific service.The following list of attributes are sent from theAuthentication Server to the communications chassis:Service-Type: Set to 1 (Login) for PPTP or Telnet tunneling. Set to 2(Framed) for non-tunneling Internet access using PPP.Login-Service: Set to either 0 - Telnet, or TBD — PPTP. Attribute unusedif Service-Type attribute set to 2 (Framed).Login-IP-Host: The IP Address of the Tunneling Server to which thecaller should be connected. Attribute unused if Service—Type attribute setto 2 (Framed).Login—TCP—Port: The TCP port on the Tunneling Server to which thecaller should be connected. Attribute unused if Service-Type is set to 2(Framed).Reply-Message: Optional, sent only for Telnet users. The communicationchassis should forward this attribute as an async string to the remote userbefore completing the TELNET tunnel to the Tunneling Server.Framed—Protocol: Set to 1 (PPP) if Service-Type attribute set to 2(Framed). Attribute is unused if Servive-Type is set to 1 (Login).Access—Rej ect MessageThe RADIUS Access-Reject message is sent by RADIUS to thecommunications chassis to deny an incoming call to the specific service.The25W0 99/0196910152025CA 02264866 1999-03-02PCT/US98/13858communications chassis, upon receiving this message, will proceed with normalPSTN/modem procedures. The Communications Chassis should forward an ASCIIstring message to the user, if the Reply Message attribute is included in the Access-Reject message. The following attribute may optionally be sent from RADIUS to thecommunications chassis:0 Reply-Message: Optional, sent only for Telnet users. The communicationschassis should forward the contents of this attribute as an async string tothe caller before proceeding with normal PSTN/modem procedures.Phase II Authentication InterfaceThis section specifies the phase two authentication messages between acommunications chassis and Authentication Server using the non-tunneling lntemetaccess option. It also provides an example of a possible phase two authenticationexchange between a Tunneling Server (RADIUS client) and Authentication Server(RADIUS server) based on either of the tunneling options.Access-Reguest MessageThe RADIUS Access-Request Message will be sent to RADIUS by thecommunications chassis to indicate an incoming call. The following list of attributesare sent along with the message:0 User—Name: This attribute indicates the name of the dial-in user to beauthenticated.0 User—Password: This attribute indicates the password of the dial-in user tobe authenticated, or the user’s input following an Access-Challenge.0 NAS-IP-Address: Set to IP address of the communications chassis.0 NAS-Port: The port number or any other identifier that can be associatedwith the caller on the communications chassis.0 Service—Type: Set to 2 (Framed).0 Framed—Protocol: Set to 1 (PPP).26CA 02264866 2002-07-187690941000 Framed-IP-Address: The dial in user 12 may optionally request the use ofits local static configured IP address. This IP address may be overwrittenby the same attribute included in the Access-Accept Message.5 Access-Accept MessageThe RADIUS Accept Message is sent by RADIUS to the communicationschassis to indicate the acceptance of the incoming call for the specific service. Thedial-user is also assigned an IP address by this message. The folllowing attribute issent fiom RADIUS to the communications chassiszi10 0 Framed-IP-Address: This attribute indicates the IP address to beassigned to the user.Access~Reject MessageThe RADIUS Access-Reject message is sent by RADIUS (authentication15 server) to the communications chassis to deny a specific service to an incoming call.a The communications chassis, upon receiving this message, will indicate that therequested service is not available and terminate the user connection.Access—Challenge Message20 The RADIUS Access-Challenge message is optionally sent by RADIUS to the. communications chassis to perform challenge/response authentication procedure toRFC 2058.RADIUS Accounting InterfaceBoth the communications chassis and the Tunneling Server will implementRADIUS accounting client functions as defined in InternetEngineering Task Force Request for Comments (RFC) 2059, entitledRADIUS Accounting, C. Rigney, dated January 1997, available} onthe internet at www.ietf.org. If an AccountingServer is associated with the Authentication Server controlling a call, each RADIUSaccounting client will send the following RADIUS accounting messages as describedin this section. I30» The accounting clients from the communications chassis and the TunnelingSewer will send the accounting Start message upon receiving the Access-Acceptmessage from the RADIUS Authentication Server.27W0 99/019691015202530CA 02264866 1999-03-02PCT/US98/13858Once a call has been dropped, cleared, or disconnect, the accounting clientswill send an accounting Stop message to the RADIUS accounting server.The accounting Start message is conveyed by the RADIUS Accounting-Request message with Acct-Status-Type value set to 1. The accounting Stop messageis conveyed by the RADIUS Accounting-Request message with Acct-Status-Typevalue set to 2.Accounting-Request MessageThe Accounting-Request packets are sent from the client to RADIUSaccounting server and convey information used to provide accounting for a serviceprovided to a user.The following are part of the accounting related attributes which may be sentalong with the message:0 Acct-Status—Type: This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop).0 Acct-Delay-Time: This attribute indicates for how many seconds the clienthas been trying to send this record, and can be subtracted from the time ofarrival on the server to find the approximate time of the event generatingthis Accounting-Request.o Acct-Input-Octets: This attribute indicates how many octets have beenreceived from the port over the course of this service being provided, andcan only be present in Accounting-Request records where the Acct-Status-Type is set to Stop.0 Acct—Output-Octets: This attribute indicates how many octets have beensent to the communications chassis in the course of delivering this service,and can only be present in Accounting-Request records where the Acct-Status-Type set to Stop.0 Acct-Session-Id: This attribute is a unique Accounting ID to make it easyto match start and stop records in a log file. The start and stop records fora given session must have the same Acct-Session-Id. It is stronglyrecommended that the Acct-Session-Id be a printable ASCII string.28WO 99101969101520CA 02264866 1999-03-02PCT/US98/l 3858Acct-Authentic: This attribute may be included in an Accounting-Requestto indicate how the user was authenticated, whether by RADIUS, thesender itself, or another remote authentication protocol. Users who aredelivered service without being authenticated should not generateAccounting records.Acct—Session-Time: This attribute indicates for how many seconds theuser has received service, and can only be present in Accounting-Requestrecords where the Acct—Status-Type is set to Stop.Acct-Input-Packets: This attribute indicates how many packets have beenreceived from the port over the course of this service being provided to aFramed User, and can only be present in Accounting-Request recordswhere the Acct—Status-Type is set to Stop.Acct-Output—Packets: This attribute indicates how many packets havebeen sent to the port in the course of delivering this service to a FramedUser, and can only be present in Accounting—Request records where theAcct—Status-Type is set to Stop.Acct-Terminate-Cause: This attribute indicates how the session wasterminated, and can only be present in Accounting-Request records wherethe Acct—Status-Type is set to Stop.Accounting—Response MessageUpon receipt of an Accounting-Request, the RADIUS accounting server mustreply with the Accounting—Response message if it successfully records the accountingpacket, and must not transmit and reply if it fails to record the accounting packet.25GLOSSARYTerms and AcronymsCode Division Multiple Access (CDMA)A North American Standard for digitalvoice and data wireless30 telecommunications in the cellular and PCS spectrum which uses the CDMAtechnique for multiplexing users on the radio interface.29a‘S!,1015202530wlllllt .‘ 1CA 02264866 2002-07-1876909-100Internet Protocol (IP)The Internet Protocol defines an unreliable, connectionless deliver mechanismfor user datagrams through the Internet.IWP-IPAn communications chassis provides the functions needed for terminalequipment connected to a TDMA or CDMA mobile phone to inter-work with terminalequipment connected to the PSTN and Internet networks.Layer Two Tunneling Protocol (LZTP)A protocol defined to pennit the tunneling of the link layer protocol of PPP.This protocol is in draft RFC form at the present time atInternet Engineering Task Force Request for (‘lomments (RFC)2661, entitled Layer Two Tunneling Protocol “L2TP”,dated August 199 9 ,W. Townsleyet al., available on the internet atwww.ietf.org and is expected to be adopted as a standard.Mobile Switching Center_(MSC)A network element within a cellular or PCS wireless telecommunicationsnetwork that provides PSTN connectivity, control functions, and switching functionsfor wireless users.PPTP Access Concentrator (PAC)A device providing external connectivity (typically via one or more PSTN orISDN lines), capable of PP? operation and of handling the PPTP protocol. The PACuses IP to tunnel user traffic to one or more PHSs. It may also tunnel non-IPprotocols.PPTP Network Server (PNS)A PNS is a communications chassis envisioned to operate on general-purposecomputing/server platforms. The PNS handles the server side of the PPTP protocol.Since PPTP relies completely on IP and is independent of the interface hardware, thePNS may use the any combination of IP interface hardware including LAN and WANdevices.30WO 99/019691015202530CA 02264866 1999-03-02PCT/US98/13858Point—to—Point Tunneling Protocol (PPTP)A protocol defined to tunnel PPP traffic between PAC and PNS. It uses GRE-like (Generic Routing Encapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets. The protocol alsosupports a “Tunnel” control and management fimction to setup and tear down acontrol connection as well as setup and tear down a data connection. There is onecontrol connection and one data connection for each pair of PAC and PNS.Public Switched Telephone Network (PSTN)The land-based telecommunications infrastructure that provides 3 KHZ circuitvoice server to fixed endpoints throughout the world today.Remote Authentication Dial In User Service (RADIUS)RADIUS servers are responsible for receiving user connection requests,authenticating the user, and then returning all configuration information necessary forthe client to deliver service to the user. A Radius server can act as a proxy client toRADIUS serversupport PPP PAP or CHAP, UNIX login, and other authentication mechanisms.other RADIUS servers or other kinds of authentication servers.TELNETTelnet was designed to support asynchronous communication between any twonetwork virtual terminals (NVT) over a TCP/IP connection. The NVT is an imaginarydevice from which both ends of the connection, the client and server, map their realterminal to and from.Time Division Multiple Access (TDMA)A North American Standard for digital voice and data wirelesstelecommunications in the cellular and PCS spectrum which uses the TDMAtechnique for multiplexing users on the radio interface.31CA 02264866 1999-03-02W0 99/01969 PCT/US98/13858Transport Control Protocol (TCP)The Transport Control Protocol provides a reliable connection-orientedmechanism for delivery of user data across an IP network.5 TS—IPTunneling Server IP addressUser Datagram Protocol (UDP)A connection-less oriented protocol built on top of IP. The service access10 point (SAP) of UDP is identified by a UDP port and the IP address.Virtual Private Network (VPN)A secure network built upon Internet to deliver secure information access.15 From the foregoing description, it will be appreciated that Variousmodifications and changes may be made to the preferred embodiments disclosedherein, without departure from the true spirit and scope of the invention. This truespirit and scope is set forth in the appended claims, to be interpreted in light of theforegoing.32

Claims (18)

WE CLAIM:

1. A method of connecting a source of digital data to a computer network, the source of digital data communicating over a wireless transmission medium to a wireless service carrier, the wireless service carrier multiplexing said digital data onto a high speed digital telephone line, the method comprising the steps of:
receiving said digital data at a communications device having a telephone line interface and a network interface;
said communications device extracting, from said digital data, network access authentication data comprising at least one of the following: (a) a telephone number called by said source of digital data, or (b) a telephone number associated with said source of digital data;
said communications device transmitting said authentication data over a local area or wide area computer network connected to said network access server to a network authentication server for said computer network;
determining, in said network authentication server, from said transmitted authentication data whether said remote user is permitted to access said computer network;
said authentication server responsively notifying said communications device the results of said step of determining and authorizing said source of data to access said computer network if said step of determining results in a positive response.

2. The method of claim 1, wherein the method further comprises the steps of:
identifying, in said authentication server, a tunneling server linked to said communications device to be used to provide access for said source of digital data to said computer network; and routing digital data from said source of digital data to said tunneling server to provide said access to said computer network.

3. The method of claim 2, further comprising the steps of:

determining, in said authentication server, a tunneling protocol for said sourceof digital data for use in tunneling digital data between said network access server and said tunneling server; and routing digital data from said source of digital data to said tunneling server in according to said tunneling protocol.

4. The method of claim 2, wherein said tunneling protocol is selected from the group of protocols comprising PPTP and TELNET.

5. The method of claim 1, wherein said computer network comprises the Internet.

6. The method of claim 1, wherein said computer network comprises a corporate local area or wide area network.

7. The method of claim 1, wherein said communications device provides access to the public switched telephone network and wherein said communications device attempts to route said digital data to a destination for said digital data via said public switched telephone network in the event that said step of determining results in a negative response.

8. The method of claim 2, further comprising the steps of:
conducting a password authentication routine between either (1) said tunneling server or (2) said authentication server and said source of digital data, thereby providing a second level of authentication between said source of digital data and said computer network.

9. An Internet access method for use by an Internet service provider having a communications device receiving telephone calls from a user over a high speed telephone line, comprising the steps of:
connecting said communications device to an authentication server over a local or wide area network;

extracting, from an incoming call from said user, network access authentication data comprising at least one of the following: (a) a telephone number called by said user, or (b) a telephone number associated with said user;
routing said network authentication data to said authentication server for authentication of said user from said network access authentication data;
identifying a tunneling server for providing network access for said user and notifying said network access server of said tunneling server;
tunneling digital data from said network access server to said tunneling server; and placing said digital data onto the Internet by said tunneling server.

10. The method of claim 9, further comprising the steps of:
identifying a tunneling protocol for said user for said step of tunneling.

11. A method of connecting a computer generating digital data to the Internet, the digital data being placed onto a high speed digital telephone line for transmission to an Internet service provider, the method comprising the steps of:
receiving said digital data at a communications device at said Internet service provider;
extracting, from said digital data, Internet access authentication data comprising at least one of the following: (a) a telephone number called by said source of digital data, or (b) a telephone number associated with said computer;
transmitting said authentication data to a network authentication server;
determining, in said network authentication server, from said transmitted authentication data, whether said remote user is authorized to access the Internet via said network access server;
said authentication server responsively notifying said network access server the results of said step of determining and authorizing said computer to access the Internet if said step of determining results in a positive response.

12 The method of claim 11, wherein the method further comprises the steps of:
identifying, in said authentication server, a tunneling server to be used to provide access for computer to the Internet; and routing digital data from said computer to said tunneling server to provide saidaccess to the Internet.

13. The method of claim 12, further comprising the steps of:
determining, in said authentication server, a tunneling protocol for use in tunneling digital data between said network access server and said tunneling server;
and routing digital data from said computer to said tunneling server in according tosaid tunneling protocol.

14. The method of claim 13, wherein said tunneling protocol is selected from the group of protocols comprising PPTP and TELNET.

15. The method of claim 11, wherein said communications device provides access to the public switched telephone network and wherein said communications device attempts to route said digital data to a destination for said digital data via said public switched telephone network in the event that said step of determining results in a negative response.

16. The method of claim 12, further comprising the steps of:
conducting a password authentication routine between either (1) said tunneling server or (2) said authentication server and said computer, thereby providing a second level of authentication between said source of digital data and said computer network.

17. An Internet service provider system for a wireless Internet user, comprising, in combination:

a network access server comprising a high speed digital telephone line interface receiving calls from said wireless Internet user and an Internet gateway for placing digital data associated with said wireless Internet user onto the Internet;
an Internet access authentication server linked to said network access server via a communications medium and responsive to Internet access authentication data extracted from said digital data associated with said wireless Internet user received by said network access server and transmitted from said network access server to said authentication server;
said authentication server further comprising a memory for determining from said Internet access authentication data whether said wireless Internet user is authorized to access the Internet, said Internet authentication server responsively passing an authentication response to said network access server;
said network access server responsive to said authentication response from said authentication server to either allow said wireless Internet user to access the Internet or to take other action with respect to a call from said wireless Internet user.

18. The Internet service provider system of claim 17, further comprising a second Internet authentication server linked to said network access server over a communications medium and responsive to authentication data from said network access server, and wherein said second Internet authentication server is managed by a second Internet service provider and provides Internet authentication responses for said wireless Internet user to either said network access server or said Internet access authentication server.