JP3515983B2 - Network access methods, including direct wireless access to the Internet - Google Patents

Description

Description: BACKGROUND OF THE INVENTION A. Field of the Invention The present invention relates to the field of data communications, in particular digital data generated by wireless users (computers with mobile telephone modems, etc.) To connect to the computer network of.

B. Description of Related Art Network access servers are known that allow remote users dialing from the public switched telephone network to access a local or wide area network. Such devices are available from 3COM (formerly US Robotics Access Cor
p.), ie from the assignee of the present application. 3COM
Company's total control network enterprise hub (Total Control
Network Enterprise Hub) is a typical network access server. This server is based on the Baum et al. Patent.
5577105: "Telephone Call Switching and Routing Method for Data Communications" and also Walsh et al., US Pat. No. 5,528,595.
No .: “Modem input / output signal processing method”.
Both Walsh et al. And Baum et al. Patents are incorporated herein by reference.

The network access server described in the Walsh et al. And Baum et al. Patents is an interface to multiple digital telephone lines, multiple modems for signal translating data from remote users, and demodulated data from the modems on a local or wide network. It has a network interface for transmitting to. A high speed midplane bus structure with a time division multiplexed bus functions as a signal path between a telephone line channel and a modem. The high speed midplane also includes a parallel bus that couples the modem and the network interface.

This network access in a single chassis
Server architectures are very popular in various applications, especially in the field of corporate network access. This network access server architecture is also popular with internet service providers for land internet users. A single network access server allows an internet service provider to handle multiple simultaneous internet access calls and provide full duplex communication between multiple remote users and a host computer on the internet.

Techniques are emerging to enable wireless users to access the Internet. There are two competing standards for wireless services: CDMA (Code Division Multiple Access, described in standard documents IS-130 and IS-135, incorporated herein by reference), and TDMA (Time Division Multiple Access, standard document). IS-99, also incorporated herein by reference). These standards define a rich form of digital wireless communication for both voice and data. The two standards differ in how digital data from multiple users is multiplexed over the air interface.

In either radio technology, wireless users send data to a mobile switching center. The mobile switching center enables connection to the public switched telephone network, performs specific multiplexing and control functions, and provides switching functions to mobile users. This allows multiplexed digital data from multiple wireless users to be sent to a communication element in the public switched telephone network via a high speed communication format (frame relay, etc.).

The invention of the present application provides a network access method and apparatus that is particularly suitable for wireless users. According to the network access method of the present invention, it becomes possible for a network access server and one or more authentication servers to cooperate to provide Internet and corporate network authentication and access. The network access server provides the functions required for cooperation between a terminal device connected to a TDMA or CDMA mobile telephone and a terminal device connected to the public switched telephone network (PSTN) and the Internet. Further, according to the present invention, there is provided an internet access method for a plurality of remote users who subscribe to a plurality of internet service providers, and the internet service providers provide more flexible service to various internet users. It becomes possible.

SUMMARY OF THE INVENTION A method for connecting a remote user having a digital data source to a computer network is provided. The digital data source produces digital data and communicates with a wireless service carrier via a wireless transmission medium. The wireless service carrier multiplexes digital data over high speed digital telephone lines and sends it to a communication chassis or server that provides network access. The method of the present invention receives digital data on a communications chassis and includes from the digital data at least one of (a) a telephone number called by the user or (b) a telephone number associated with the user. Retrieve access authentication data. The communication chassis sends the authentication data to the network authentication server for the computer network via the local area or wide area computer network connected to the network access server, and the password authentication procedure is performed with the digital data source. To be executed. The network authentication server determines whether the remote user is authorized to access the computer network based on the authentication data sent and the password authentication procedure. The authentication server thus informs the network access server of the outcome of the decision. The remote user is granted access to the computer network if the result of the decision step is positive.

The method further includes recognizing a tunneling server linked to the communication chassis via a local area or wide area network and routing digital data from the data source to the tunneling server to provide access to the computer network. be able to. The tunneling server provides a digital data source with access to a computer network. The identification of the tunneling server is performed based on the authentication data from the remote user, which data is the remote user's telephone number, dialed number, or the like. In this embodiment, the authentication server may also determine a tunneling protocol for tunneling digital data from the digital data source between the communication device and the tunneling server. This determining step can be performed, for example, by finding the tunneling server associated with the remote user (identified by the user's telephone number etc.) and the required protocol from a software lookup table. Digital data is routed through the tunneling server according to the tunneling protocol. In the preferred embodiment, PPTP
Or the TELNET protocol is used.

The second stage of access authentication is performed. It consists of a password authentication routine that takes place between the remote user and the authentication or tunneling server.

A primary object of the present invention is therefore to provide remote users, such as wireless users, with direct access to the Internet and other computer networks. This and other objects will become apparent from the detailed description below.

BRIEF DESCRIPTION OF THE DRAWINGS The presently preferred and preferred embodiments of the invention will now be described with reference to the drawings. In the drawings, like reference numbers indicate like elements.

FIG. 1 is an example of a network access system suitable for wireless users in an embodiment of the present invention.

FIG. 2 is a functional block diagram of a preferred form of the communication chassis of FIG. The communication chassis can handle not only wireless users, but also users dialing over the public switched telephone network.

FIG. 2A is a block diagram of a communication chassis suitable for embodiments that do not support analog modem calls.

FIG. 3 is a protocol stack for a tunnel interface between a remote user and the tunneling server of FIG.

FIG. 4 shows a protocol stack for an authentication and accounting interface between the communication chassis and the authentication server of FIG.

FIG. 5 is a protocol stack of a non-tunneling interface between a remote dial user and a router connecting the user to a destination terminal device.

FIG. 6 is a call flow of the PPTP protocol for tunneling in the call acceptance scenario in the preferred embodiment of the present invention.

FIG. 7 is a call flow of the TELNET protocol for tunneling a call acceptance scenario according to the preferred embodiment of the present invention.

FIG. 8 is a call flow in the authentication failure scenario.

FIG. 9 is a call flow in the tunneling server access rejection scenario.

FIG. 10 is a call flow of an authentication failure scenario when the login password authentication is executed as the second step of the network access authentication procedure in the PPTP protocol.

FIG. 11 is a call flow of an authentication failure scenario when login password authentication is executed as the second stage of the network access authentication procedure in TELNET.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 1 illustrates a network access system 10 suitable for implementing the present invention. This system is a wireless device
Used by 12, 14 users. A remote computer, such as a laptop computer with a wireless modem, or a wireless personal data assistant (PDA) 14, is capable of transmitting wireless digital data through the wireless modem according to the TDMA (Time Division Multiple Access) or CDMA (Code Division Multiple Access) standard. Communicate with the communication network.

The wireless network 16 includes a mobile switching center (MSC) (not shown). The mobile switching center is an element within the wireless communication network 16 that provides wireless users with connectivity to public switched telephone networks, control functions and switching functions. In the embodiment of FIG. 1, the data from the wireless user is placed on the high speed digital frame relay line FR by the MSC and sent to the communication chassis 20 in the local calling area. In the preferred embodiment, the communications chassis 20 is a 3Com (previously US Robotics) integrated control network enterprise hub (Total Control Network).
k Enterprise Hub) and other integrated network access servers. In this case, the server is a frame relay line
It is modified to interface with FR and perform the tunneling, authentication, and accounting functions described below.

Communication chassis 20 is a CDMA / TDMA wireless network 1
6 and the Internet Service Provider (ISP) backbone network 26, the Internet 22 or other local area network ETH to act as a gateway between the Internet Service Provider backbone network 26. The chassis 20 provides the functions necessary for a terminal device connected to a CDMA or TDMA mobile phone to communicate with a terminal device connected to the PSTN and the Internet network. In the preferred embodiment, communication chassis 20 is a telephone company central office.
It is located in ice; TELCO CO and is maintained by an Internet service provider (ISP). Chassis 20 receives calls from wireless users 12, 14 via MSCs in wireless network 16 as local calls on line FR.

The wireless terminals 12, 14 utilize a tunneling protocol via a LAN or WAN line 28 between the communication chassis 20 and the tunneling server 30 to access the corporate / personal network 24. The tunneling server is connected to the corporate / private network 24 and to the communication chassis 20 via the backbone network 26. In the preferred embodiment, tunneling is commonly available RF
Follows the Point-to-Point Tunneling Protocol (PPTP) described in the C document PPTP RFC (June 1996). This RFC document is incorporated herein by reference.
It is of course possible to follow tunneling as well as other emerging equivalent protocols, such as L2TP. With PPTP
L2TP is not designed to support non-PPP asynchronous protocols, so the TELNET protocol is used to tunnel non-PPP asynchronous traffic over line 28. The tunneling server is also preferably the aforementioned Total Control Enterprise Network Hub or equivalent integrated network access server.

In such an architecture, the location of the original dial-up server (communication chassis 20) is the location where the intermediate network disconnects the dial-up protocol connection (PPP) and gives the tunneling server 30 access to the target network 22 or 24. Can be separated from. Internet as a target network
In addition to supporting 22, the architecture also supports access to virtual private networks to ensure that wireless users have access to their corporate or private networks, such as the corporate network 24 of FIG. To be able to do.

This architecture further enables the Internet service provider managing the local communication chassis 20 at the headquarters (CO) to provide interface access not only to ISP clients but also to clients of other interface service providers. Becomes This is accomplished by utilizing one or more authentication servers 32A, 32B connected to the backbone network 26 of the internet service provider. Authentication servers 32A, 32B perform authentication and access authorization for the first ISP client. The second tunneling server 34 is connected to the backbone network 38 of the second ISP via a private line 36 (or LAN or WAN) or directly. In this embodiment, the authentication server 32A has a client list for the first ISP operating the communication chassis 20 and dials the communication device 20 using various simple methods as described below. Is a remote user
It can be determined whether access to the Internet 22 is allowed through P's backbone 26. If access is granted (because the call is being made by one of the clients of the first Internet server provider), the call is routed to the Internet via network 22. Otherwise, another procedure as described below will be started.

The present invention takes advantage of the fact that a call from a remote user includes information indicating the caller's telephone number and the dialed telephone number. This information is used as the first stage authentication mechanism. The authentication server 32A performs this first-step authentication and the remote user is not the client of the first internet service provider (for example because the phone number does not match the client phone number list) but the second internet service provider. If so, the authentication server 32A sends an authentication request to the second authentication server 40 connected to the backbone 38 of the second Internet service provider, and the first-step authentication is performed. This communication is a dedicated line 42 (dedicated communication circuit, POTS line, etc.)
Is provided between the authentication server 32A and the authentication server 40 operated by the second Internet service provider.

If the result of the authentication is positive, the authentication server 40 informs the authentication server 32A of the result, and the wireless user 12 is given access to the Internet 22 via the network 26 or the tunneling server 34, and the remote user 12 and the second user.
Second-stage password-based authentication is performed between the authentication servers 40.

This combination of features gives ISPs or other organizations operating communication chassis 20 and authentication server 32A the ability to significantly increase the services they provide to clients. This combination also allows ISPs to provide Internet access to other Internet service providers, and in the process will likely generate revenue for such services. From a wireless user's perspective, a local call to the communication device 20 via the wireless network 16 provides access to the Internet or corporate network.

In the preferred embodiment of the present invention, communication chassis 20 is a powerful communication platform such as the integrated control network enterprise hub described above with an integrated general purpose computer platform,
That is, EdgeServer ^™ available from 3COM. By using this product, the communication chassis enables commercial standalone operating systems such as Microsoft's Windows NT and other remote access software products such as RADIUS (Remote Authentication Dial In).
User Service) can be operated. In the Internet access method described above, the billing and authentication functions are preferably used utilizing the RADIUS protocol or other commercially available or known billing software programs. The RADIUS protocol is a known protocol and is described in RFC 2058, January 1997, which is incorporated herein by reference.

In the preferred embodiment of the present invention, two-step authentication allows for the Internet 22 or corporate / private network 24.
Access is provided only to wireless users who are allowed access via network 26. The first step of authentication is based on the number dialed by the remote user 12, 14 and the number of the caller of the wireless user 12, 14 (ie, the user's telephone number associated with the computer 12 or PDA 14). The second stage of authentication is based on test username and password authentication protocols (for PPP and TELLNET tunneling), or challenge / response protocols (PPP).
Tunneling only). The details of these authentication procedures are described below.

In FIG. 1, the communication device 20 also preferably supports access to the internet 22 directly from the internet interface within the communication device, ie, without tunneling. This feature allows the communication device to perform both authentication steps, disconnect the PPP protocol, and route Internet Protocol traffic.

In another embodiment of the present invention, the communication device 20 provides a direct PSTN (Public STN) for data calls originated from mobile or land.
witched Telephone Network) connection. In this embodiment, communication chassis 20, such as the Total Control Network Enterprise Hub described above, includes the required modem and telephone line interfaces and processing circuitry to perform these functions. This embodiment is particularly advantageous when the Internet service protocol is a local telephone company. According to the internet access method of the present invention, the communication device 20 extracts or retrieves the called number in the ATD command issued by the mobile data user during the mobile outgoing data call.
For most call numbers, the communication device 20 places the call normally.
Treat as a PSTN modem call. However, if the calling number is associated with Internet access, the communication chassis 20 may be called a number (either on the backbone network 26 of the ISP, or connected to the communication chassis 20 via leased lines 36, 42 or other networks). The first authentication step is performed at the authentication server 32A associated with The authentication server 32A determines whether the remote user is permitted to access the Internet 22 or the network 24 under the control of the authentication server 32A.

FIG. 2 is a functional block diagram showing in simplified form a preferred form of the communication chassis or network access server 20 of FIG. This communication chassis or network access server 20 can serve not only wireless users, but also users dialing from the public switched telephone network. As such, the chassis includes functions not required for the practice of the invention and performing other functions required in the particular embodiment of the invention in which PSTN is enabled. The network access server 20 of FIG. 2 basically aligns the architecture and design of the current model of the Total Control Network Enterprise Hub, a commercial product available from the assignee of the applicant. It should be understood that the integrated access servers of other manufacturers in the industry may be modified appropriately to obtain the functionality of the present invention, and that the present invention is not limited to only the embodiments described in this specification. .

The network access server 20 includes a telephone network interface card 50. The telephone network interface card 50 is connected to time division multiplexed digital telephone lines such as T1, E1 and ISDN basic rate interface (PRI) lines and frame relay lines. The network interface card receives digital data from the wireless smooth user via the wireless service switch on the frame relay line FR. The interface card 50 has a connector for physically accepting a telephone line. The card 50 further comprises a CSU that extracts the clock signal and data from the input signal and provides multiplexing and demultiplexing on the output and input data streams, thereby placing calls within carrier time slots. card
The input telephone signal 50 is input to the NIC / NAC (network interface card /
network application card) T1 / E1 / ISDN via bus 54
Send to PRI / Network Application Card 56. The application card 56 supplies framing to the extracted telephone line data to extract the frame relay time division multiplexed data, the T1 DS0 channel data, or the ISDN 2B + D channel data included in the ISDN PRI signal, and thereafter. A time / space switch is used to switch the channel data to a time slot on the time division multiplexed bus 60 which is part of the intra chassis bus midplane 52.

If the input signal is from the wireless service central office and arrives at the server on a frame relay line, the channel data does not require any signal conversion processing normally done in a modem and is routed through the TDM bus 60. And to the LAN / WAN interface card 62. In a Total Control Enterprise Network Hub, this card 62 is known as the "EdgeServer" card, and Ascend, Livingston and other manufacturers' network access devices also have similar interfaces. The edge server card 62 has a pair of Munich chips that incorporate data packets according to the TCP / IP protocol, and transmits directly to the destination via the LAN / WAN interface or total server.

TDM bus 6 if the call originates from a user connected to the public switched telephone network and signal conversion is required.
0 directs the call to the modem or card 64 in the multi-modem module. The internal chassis bus 52 further has a high-speed parallel packet bus 58, which transfers the demodulated / signal-converted data to the routing engine in the edge server card 62, and the modem in the card 64 to the edge server card. Connect to 62. A plurality of analog network interface cards 63 are provided to connect the modem to the serial interface 65.

The telephone line interface card 50 and the application card 56, the modem cards 63 and 64, the internal chassis bus complex 52 (including the TDM bus 60 and the parallel bus 58), and the computer network interface 66 of the edge server card 62 are the above-mentioned Baum et al. U.S. Patent No. 557710
No. 5: "Telephone call switching and routing method for data communication", and Walsh et al., US Pat. No. 5,528,595: "Modem input / output signal processing method", describes the respective constituent circuits and operations in detail. . The detailed construction of the preferred internal chassis bus is disclosed in Panzarella et al., U.S. Pat. No. 5416776, "Modem Backplane Technology." This patent is 3C
Assigned to OM Company and incorporated herein by reference. Management of chassis by management card is Panzar
Ella et al., US Pat. No. 5,436,614, "Modem Management Techniques," also describes in detail. This U.S. patent is also assigned to 3COM, Inc. and is incorporated herein by reference.

The edge server card 62 includes a general-purpose computing platform 70, and the platform 70 drives a commercially available stand-alone type or shareware operating system (such as Windows NT). Card 62 is described in detail in the Willium Verthein et al. Patent application, which is incorporated herein by reference.

Telephone line interface, application card,
Modem card, management card (not shown), and card
The computer network interface 66 of 62 exists in a known product or is described in a known document,
Those of ordinary skill in the art will appreciate how to design and fabricate such a circuit (or equivalent), and therefore a description of these components of communication access chassis 10 will be omitted. Also, details regarding the architecture or design of the communication chassis 10 are not particularly important.

The edge server card 62 has a TDM interface 72, which is connected from the frame relay FR circuit to the TDM interface.
Receives channel data via bus 60. The computing platform 70 consists of a commercially available IBM compatible personal computer, an associated central processing unit 74, and peripheral interfaces for keyboard, floppy disk, monitor and mouse. The computing platform also includes an internal storage hard disk drive 76. The computing platform further includes a packet assembly and disassembly circuit 78, which allows data packets from the modem in modem module 64 to be sent to general purpose computing platform 70.
It is assembled into an easy-to-use format. The general purpose computing platform also communicates with the normal network interface 66 via a NIC / NAC bus connection. The computing platform also communicates with the external storage expansion bus interface 84 via the second ISA bus 82. The interface
84 is connected to an external disk drive or other suitable storage device and is used to increase the storage capacity of communication chassis 20. In the preferred embodiment, the software for driving the tunneling and authentication functions within communications chassis 20 as described below is loaded into general purpose computing platform 70 within edge server card 62.

As mentioned above, the communication chassis architecture and functionality of FIG. 2 provides functionality beyond that normally required to connect remote users on a wireless network to an ISP backbone, a corporate network or the Internet. FIG. 2A is a schematic diagram of another device without a modem. This device is suitable for use in embodiments in which the PSTN disconnect function for communication devices is not provided. Figure 2A
In this embodiment, the frame relay interface 100 having the line interface unit, the demultiplexing circuit and the framing circuit is provided in one module. Interface 100 places channel data on time slots within the TDM bus complex. TDM bus complex 102 is interface 100
Connect to AN / WAN interface 104. LAN / WAN interface 104 preferably comprises a common Ethernet or other common interface. In the latter case,
It is modified by a general purpose computing platform loaded with software that performs call routing, authentication, tunneling and other functions described herein.

It will be apparent from FIGS. 1, 2 and 2A that a method of connecting the digital data source 12 to a computer network 24, 22 (corporate private network, Internet, World Wide Web, etc.) is disclosed. The digital data source 12 generates digital data and communicates with a wireless server carrier via a wireless transmission medium. Carrier multiplexes digital data, circuit FR
Etc. to high-speed digital telephone lines. This method has the following steps.

(1) Receives digital data at a network access server or communication chassis 20 and has at least (a) a telephone number called by the digital data source 12 from the digital data, or (b) a telephone number associated with the digital data source. Extract network access authentication data.

(2) The authentication data is transmitted to the network authentication server 32A or 32B for the computer network 24 or 22 via the local area or wide area computer network connected to the communication device 20. The network authentication server is coupled to the communications chassis 20 via a local area or wide area computer network 26.

(3) The authentication server 32A determines whether or not the remote user is permitted to access the computer networks 22 to 24 based on the transmitted authentication data. The authentication server 32A provides the communication chassis 20 with the result of the decision step and, if the result of the decision step is positive, permits the data source 12 to access the computer network 24.

The method further identifies a tunneling server 30 or 34 coupled to the communications chassis 20 via a local area or wide area network 26 and routes digital data from the digital data source 12 to the tunneling server 30 for computer network 24. May be included. The communication chassis 20 provides digital data source 12 with access to a computer network. The identity of the tunneling server is determined in the preferred embodiment by the authentication data (ie, dialed number and dialing party number) extracted from the call that originated. In this embodiment, in the authentication server 32A or 32B, the communication device 20
The present invention can also be practiced by determining the tunneling protocol for the data source 12 used in tunneling digital data between the and tunneling server 30. This determining step can also be performed, for example, by finding in the software lookup table the tunneling server and the required protocol associated with the remote user 12 (identified by the remote user's 12 telephone number). Digital telephones are routed according to a tunneling protocol through a tunneling server. In a preferred embodiment of the invention, PPTP or TELNET
The protocol is used.

In the preferred embodiment, the communication chassis 20 of FIG.
It also provides access to the public switched telephone network via the ISDN interface 50/56. Communication chassis 20
Routes digital data from a remote user 12 to its data destination. In this way, the communication chassis 20 not only provides direct network access to the computer networks 22 and 24, but also performs signal modulation via modems within the chassis to place calls over the telephone network to remote terminals, e.g. 1 can be transmitted to the computer 13. It is well known how the communication chassis 20 provides PSTN connectivity and is described in the aforementioned Walsh et al. Patent.

In the preferred network access embodiment of the present invention, a second stage authentication routine confirms that the remote user is authorized to access the designated network. This is performed by executing a password authentication procedure such as a PAP or CHAP routine between (1) the tunneling server 30 or (2) the authentication server 32A and the remote user, or (3) the authentication server 32A and the tunneling server 30 /. Achieved by performing second level authentication by performing between 34. All of these routines are known.

In one embodiment of the present invention, an internet access method suitable for use by an internet service provider having a network access server or communications chassis 20 configured to receive telephone calls from a user 12 over a high speed telephone line is disclosed. To be done. This method has the following steps.

(1) The network access server 20 is connected to the authentication server (32A via the local or wide area network 26).
Or 32B).

(2) From the call made by the user 12, extract network access authentication data that includes at least (a) the telephone number the user called, or (b) the telephone number associated with the user.

(3) The network authentication data extracted from the generated call is routed to the authentication server 32A or 32B, and the user is authenticated based on the network access authentication data.

(4) Identify the tunneling server (eg 34) to give the user network access to the communication chassis.
Notify 20 of the tunneling server.

(5) The digital data from the communication chassis 20 is tunneled to the tunneling server 34.

(6) The digital data is sent to the Internet by the tunneling server.

In the preferred embodiment, the method is accomplished by the process of identifying a tunneling protocol for the user for the tunneling step. For example, the authentication server
32A or 32B or 40 allows the user to specify a particular tunneling protocol (PPTP or PPTP) according to the characteristics of the remote user, the requirements of the specified tunneling server,
TELNET) can be associated with. Such information is typically stored in the memory of the authentication server 32A.

Further, the present invention envisions the Internet service provider system as a wireless Internet user. This internet service provider has a network access server 20 (FIG. 2), which has the following components:

(1) A high-speed digital telephone line FR interface for receiving a call from a wireless Internet user, and an Internet gateway for transmitting digital data associated with the wireless Internet user to the Internet (WAN interface 66, etc. in FIG. 2).

(2) Network access server via communication medium 26
Internet access authentication server combined with 20 (32
A etc.). The authentication server operates in response to Internet access authentication data extracted from digital data associated with wireless Internet users.

(3) The authentication server 32A further determines the wireless Internet user 12 based on the Internet access authentication data.
Is provided with a memory for determining whether the user is allowed to access the Internet. The Internet authentication server sends an authentication response to the network access server 20. Whether the network access server 20 allows the wireless Internet user to access the Internet according to the authentication response from the authentication server,
Or perform some other action with respect to the call from the wireless Internet user. For example, the Internet service provider may forward the authentication inquiry to another authentication server (such as 40 in FIG. 1) operated by the second Internet service provider, and whether the user is a client of the second Internet service provider. Make sure.

See FIG. 3 for implementation details of the preferred embodiment of the present invention.
This will be described with reference to ~ 11.

FIG. 3 illustrates the protocol stack and architecture of the tunnel interface between the remote user 12, the communication chassis 20, the router (not shown) in the Internet service provider backbone network 26, and the designated tunneling server 30 or 34 of FIG. Is.
In FIG. 3, numbers L1 and L2 indicate lower protocols (such as the data link layer). IP stands for Internet Protocol. PPP stands for Point-to-Point Protocol. T
CP indicates a transmission control protocol. The term Async refers to an asynchronous protocol that can be associated with the remote user 12, and the TELNET protocol is used within the communication chassis 20 and tunneling server for asynchronous communication. As is clear from the figure, when the communication chassis 20 communicates with the tunneling server, PPTP or TELNET that operates on IP and lower protocols is used.

As shown in FIG. 4, an authentication server (32A or the like), which is a communication partner of the communication chassis 20, executes RADIUS and performs authentication and billing via the UDP / IP protocol stack. FIG. 4 shows a protocol for an authentication / billing interface between the network access server or communication chassis 20 and the authentication server 32A of FIG. UDP is a connectionless protocol that is located above the Internet Protocol (IP).

When the communication chassis 20 communicates with the Internet 22, there is no tunneling protocol. Shown in FIG. 5 is a protocol stack for a non-tunneling interface between a remote dial user and a router connecting the user to the destination terminal.

FIG. 6 shows a call flow of PPTP protocol tunneling in a call acceptance scenario in a public embodiment of the present invention. In FIG. 6, the process begins with the occurrence of a call at step 100. The call is associated with a particular destination telephone number (1-800-123-4567 in the illustrated example).

In step 102, the communication chassis initiates a first stage authentication access routine to an authentication server (32A or 32B, etc.) connected to the communication chassis via the local area network. This authentication request is a software structure that is forwarded to the authentication server and contains fields for the following information. (1) a telephone number associated with the remote user, which is detected according to known caller identification techniques or the methods described in the Baum et al. Patent; and (2) dialed telephone numbers retrieved by known methods. ;
(3) a specific channel or port number or port ID associated with the call in the communication chassis 20; and (4)
IP address of communication chassis 20.

In step 104, the authentication server 32A sends an access response message to the communication chassis 20. User authenticates on server 32
If access is permitted to the network under the jurisdiction of A, the above message confirms that PPTP is a proper tunneling protocol, confirms the IP address of the tunneling server, and the port number of the tunneling server to be called. including. If the remote user is not authorized to access, the procedure of FIG. 8 as described below is used.

In step 106, the communication chassis 20 issues the originating call request (Inc
oming-Call-Request) message to the tunneling server 34. This message includes the identification of the remote user's dial number, the dialed telephone number, and the subaddress. In step 108, the tunneling server 34
Is able to accept the call, the incoming call response (Incoming-
If the result of the call-reply message, for example, the access inquiry is affirmative, "connect" is transmitted. If the tunneling server cannot accept the call, the procedure of FIG. 9 is used.

In step 110, if a "Connect" message is received from the tunneling server 34, the communication chassis 20 sends a call accept message to the remote user via the frame relay line FR and the wireless network. The incoming call connection message is then relayed from the communication chassis 20 to the tunneling server 34 in step 112.

In step 114, the second stage authentication procedure is performed. Steps 116, 118, 120, 122, 124 and 126 are shown in FIG.
Is obvious and is part of the well-known PAP and CHAP password authentication protocols, and will be apparent to those skilled in the art.

In step 128, assuming that the password authentication has been passed, the tunneling server 34 sends a message to the remote user 12 via the communication chassis 20 that the PPP link is established between the remote user 12 and the tunneling server 34. . At this point, the transmission of data packets according to the Internet Protocol between the remote user and the host on the network 22 or 24 is complete.

FIG. 7 illustrates the TELNET protocol tunneling call flow for a call acceptance scenario in the preferred embodiment of the present invention. The process is generally similar to that described in Figure 6 and is self-explanatory. Handshaking and parameter negotiation between the communication chassis 20 and the tunneling server 34 are required to establish a TELNET session. This is shown in steps 130 and 132. PA
The second stage of authentication, using a login protocol such as P, is performed as shown. When a login acceptance message is sent from the tunneling server 34 to the dial user 12, asynchronous transmission is executed between the remote user 12 and a host on a computer network (Internet or the like) via the communication server 20 and the tunneling server 34. .

In the first step of access authentication, the authentication server does not allow the remote user access to the specified network under the control of the authentication server (eg, the remote user's telephone number operates the chassis 20). It does not match the Internet client database of the Internet service provider that is being used).
A preferred method of addressing this scenario is shown in FIG. That is, FIG. 8 shows a call flow in the authentication failure scenario. If the authentication server 32A determines that the remote user is not authorized, the authentication server 32 sends an access refusal message to the communication chassis 20. This message may include a field indicating the reason for the access denial. Such reasons are, for example, the wrong dialed phone number, the ISP does not recognize the user's phone number, the user's monthly payment is delayed,
The authentication server has been suspended, etc. Communication chassis 20 then either sends a message to remote user 12 to try again later, treats the call as a PSTN / modem call, routes the call on the PSTN system, or rejects and disconnects the call. Start the sequence.

Further, it is possible that the authentication server 32A permits access to the network, but the tunneling server 30 or 34 cannot function as a mechanism for data transfer between the remote user 12 and the target networks 22-24. FIG. 9 shows a call flow in the tunneling server access rejection scenario. First step 100, 102, 104
And 106 are common to FIG. If tunneling server 34 cannot handle the call, tunneling server 30 or
34 sends to the communication chassis 20 an incoming call response with a message or field that the call cannot be accepted.
At this point, the communications chassis 20 either sends a message to the remote user 12 to try again later, or makes the call to the PSTN.
/ Treat as a modem call and route on the phone system, or just reject the call.

In the second stage of authentication described with reference to FIGS. 6 and 7 above, the user may fail in the password authentication procedure. FIG. 10 shows a call flow in an authentication failure scenario in the PPTP protocol. In the PPTP protocol, the login password authentication procedure is executed as the second step of the network access authentication procedure. In step 140, an access refusal message is sent from the authentication server 32A to the tunneling server 30/34. At this point (step 142), the tunneling server sends a login reject message to the remote user 12.

FIG. 11 shows a call flow in the authentication failure scenario for TELNET, in which the login password authentication procedure is executed as the second step of the network access authentication procedure. This process proceeds essentially as described above.

A preferred embodiment of two-step authentication of PPTP and TELNET tunneling, charging and first and second will be described in detail below.

Protocol Interface The communication chassis 20 interfaces with dial users (wireless terminals), MSCs, routers, authentication servers, and tunneling servers. In this specification, only the communication chassis interface for the authentication server and the tunneling server will be described. Other interfaces will be apparent to those skilled in the art.

PPTP tunneling PPTP tunneling is enabled based on the login service attributes from the RADIUS access response message during the first phase of authentication. If the protocol is PPTP value (RFC205
8 has TBD), PPTP tunneling is set up between the communication chassis and the tunneling server, and subsequent traffic from the caller is tunneled.

The communication chassis gateway is equivalent to PAC (PPTP access concentrator) in PPTP RFC, and the tunneling server is PNS (PPTP network server) in PPTP RFC.
Is equivalent to In the following PPTP description, the terms PAC and PNS are used.

For each configured PPTP PAC-PNS pair, the interface between the PAC (communication chassis) and the PNS (tunneling server) consists of two parallel elements. A control connection running over TCP 2. an IP tunnel carrying encapsulated PPP packets for user sessions between individual pairs.

PPTP control connection Before PPP tunneling can occur between PAC and PNS, a control connection must be established between them. The control connection is a standard TCP session, over which PPTP call control and management information passes. The control session is a separate session, although it is logically associated with the session tunneled over the PPTP tunnel.

PPTP tunnel connection PPTP requires establishing a tunnel at each communicating PAC-PNS pair. Tunnel is PAC-P
Used to carry all user session PPP packets for sessions involving NS pairs. The key in the GRE header indicates to which session a particular PPP packet belongs. In this way, PPP packets are multiplexed and demultiplexed on a single tunnel between a given PAC-PNS pair. The value used in the key field is established by the call establishment procedure executed on the control connection.

PPTP control connection message   Control connection management message:   It consists of the following messages.

・ Request to start control connection ・ Control connection start response ・ Control connection stop request ・ Control connection stop response ・ Echo request ・ Echo reply   Call management message:   It consists of the following messages.

-Output call request (no support at this point) -Output call response (no support at this point) -Input call request-Input call response-Input call connection completion-Call clear request-Call disconnection notification error report-WAN error notification PPP Session control / set link information PPTP tunnel connection message PPTP data PDU: Each PPP frame is GRE (Generic Routing Encaps
ulation Header; general-purpose routing encapsulation header)
Encapsulated within. GRE is described in the request for comment (RFC1701, October 1994), which is incorporated herein by reference.

Telnet Tunneling PPTP and L2TP protocols are not designed to tunnel asynchronous traffic. Synchronous traffic is tunneled by the Telnet protocol (see RFC854).

Telnet implementation is ECHO, linemode, binary, SUPPRESS GO
It must support Telnet commands and options such as AHEAD. The tunneling server must be able to request a switch from one mode to another during the Telnet connection in any Telnet session. This switching is, for example, from ECHO to NO ECHO and line mode to binary transmission. In addition, the escape function must be disabled in the communication chassis gateway to prevent dial users from entering local mode on the communication chassis gateway.

Telnet tunneling is enabled during first stage authentication based on login service characteristics from the RADIUS access response message. Login service attribute has value Te
If it has lnet, Telnet is set up between the communication chassis and the tunneling server, and the subsequent traffic from the caller is tunneled.

RADIUS authentication interface Two-step authentication is used. The first stage of authentication is based on the calling number, called number, and communication chassis IP address. The second step of authentication is username, password,
And / or based on a call / response (optional).

Here, the exchange of RADIUS authentication in both the first and second steps will be described. When using any one of the tunneling options, the end user authentication is done by the tunneling server in the second stage of the authentication which is transparent to the communication chassis. In the case of non-tunneling Internet access, the communication chassis performs both stages of authentication (the first stage can optionally be omitted).

The following general operations apply to the RADIUS interface.

1. This document complies with IETF RADIUS Authentication RFC 2058. The authentication server supplies the RADIUS server function specified in RFC. The communication chassis and tunneling server implement the RADIUS client function.

2. The communication chassis shall be able to associate at least two authentication servers with each special Internet access called number. These two (or more) authentication servers provide the first and second RADIUS authentication server functions. Each authentication server can be identified by a configurable server IP address and UDP port. Multiple Internet access called numbers may or may not share an authentication server.

3. The RADIUS shared secret (1 to 15 characters) is administratively configured for each server. Although this specification does not discuss how the shared secret is managed between the communication chassis gateway and the RADIUS node (authentication server), such details will be apparent to those skilled in the art.

4. The communication chassis gateway implements a retransmission algorithm, which can deal with the loss of access request. A configurable retransmit counter determines when the authentication server for a particular Internet access calling number is down and the communication chassis optionally follows standard PSTN / modem access procedures while down.

Authentication interface first stage access request message: RADIUS access request message is sent by the communication chassis 20.
It is sent to the RADIUS server (authentication server 32A) to indicate the incoming call. The following is a list of attributes sent with the message.

-User name: Set to VENDORID for all input calls.

User password: set to zero.

-NAS-IP address: Set to the IP address of the communication chassis.

NAS port: A port number or other identifier that can be associated with the calling party on the communication chassis. Called station ID: The number or telephone identifier of the called party. It is used to identify the service desired by the caller.

Calling station ID: The number or telephone identifier of the calling party. It can also be used for the first stage of authentication.

-NAS port type: Identifies the type of port used by the user on the communication chassis switch. (Radio Access TBD Value in RFC2058) Access Accept Message A RADIUS access accept message is sent by RADIUS (authentication server) to the communication chassis 20 to indicate acceptance of an input call for a particular service. The following is a list of attributes sent from the authentication server to the communication 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 0-Telnet or TBD-PPTP.
This attribute is not used when the service type attribute is set to 2 (framed).

• Login IP host: The IP address of the tunneling server to which the caller should connect. Attribute not used if the service type attribute is set to 2 (framed).

Login TCP port: TCP port on the tunneling server to which the caller should connect. This attribute is not used if the service type is set to 2 (framed).

• Response message: An option that is sent only to Telnet users. The communication chassis must transfer this attribute as an asynchronous string before completing TELNET tunneling to the tunneling service.

Framed protocol: If the service type attribute is set to 2 (framed), it is set to 1. This attribute is not used if the service type is set to 1 (login).

Access Denied Message A RADIUS Access Denied message is sent by RADIUS to the communication chassis to deny incoming calls to a particular service. When the communication chassis receives this message, it proceeds to the normal PSTN / modem procedure. If the response message attribute is included in the access denied message, the communication chassis sends an ASCII string message to the user. The following attributes can optionally be sent from RADIUS to the communication chassis.

• Response message: An option that is sent only to Telnet users. The communication chassis must send the contents of this attribute to the caller as an asynchronous string before proceeding with normal PSTN / modem procedures.

Second Step Authentication Interface Here we specify the second step authentication message between the communication chassis and the authentication server using the non-tunneling Internet access option. Further, an example of possible second-stage authentication exchange between the tunneling server (RADIUS client) and the authentication server (RADIUS server) based on any tunneling option will be described.

Access request message RADIUS Access request message is sent from the communication chassis to RADIUS.
Sent to the US, indicating an incoming call. The following list is the attributes that are sent with the message.

Username: This attribute indicates the name of the dial-in user who wishes to authenticate.

User password: This attribute indicates the password of the dial-in user who wishes to authenticate, or the input of the user after the access challenge.

-NAS-IP address: Set to the IP address of the communication chassis.

NAS-Port: A port number or other identifier that can be associated with the caller on the communication chassis.

-Service type: Set to 2 (framed).

Framed Protocol: Set to 1 (PPP) Framed IP Address: Dial-in user 12 can optionally request a Local Static Configuration IP Address. This IP address can be rewritten with similar attributes contained in the access acceptance message.

Access Accept Message A RADIUS accept message is sent by RADIUS to the communication chassis to indicate acceptance of an incoming call for a particular service. The dial user is also assigned an IP address by this message. The following attributes are sent from RADIUS to the communication chassis.

Framed IP address: This attribute indicates the IP address assigned to the user.

Access Rejection Message A RADIUS Access Rejection message is sent by RADIUS (Authentication Server) to the communication chassis to reject a specific service for incoming calls. When the communication chassis receives this message, it indicates that the requested service is unavailable and disconnects the user connection.

Access Challenge Message A RADIUS Access Challenge message is optionally sent by RADIUS to the communication chassis to perform the Challenge / Response authentication procedure in accordance with RFC2058.

RADIUS accounting interface Both communication chassis and tunneling server are RFC2059
Implement the RADIUS accounting client function as specified in. If the billing server is associated with the authentication server that controls the call, then each RADIUS billing client sends the following RADIUS billing message as described herein.

The charging client from the communication chassis and the tunneling server, upon receiving the access acceptance message from the RADIUS authentication server, sends a charging start message.

Once the call is abandoned, cleared, or disconnected, the billing client sends a billing stop message to the RADIUS billing server.

The charging start message is transmitted with the charging status value set to 1 by the RADIUS charging request. The accounting stop message is the RADIUS accounting request message,
The charging status type value is set to 2 and transmitted.

Billing Request Message A billing request packet is sent from the client to the RADIUS billing server and carries information to provide billing for the service provided to the user.

The following are some of the billing-related attributes that can be sent with the message:

Billing status type: This attribute indicates whether this billing request is the start (start) or end (stop) of the user service.

Billing Delay: This attribute indicates how many seconds the client has been trying to send this record. By extracting this attribute from the arrival time at the server, it is possible to know the approximate time of the event for which the billing request is generated.

• Billing Input Octets: This attribute indicates how many octets have been received from the port since this service was provisioned, and is only present in billing request records with the Billing Status Type set to Stop.

• Billing Output Octets: This attribute indicates how many octets have been sent to the communication chassis since it began providing this service, and is only present in billing request records with the Billing Status Type set to Stop.

-Billing Session ID: This attribute is an individual billing ID that facilitates matching start and stop records in the log file. Any start / stop record must have the same billing session ID. It is recommended that the billing session ID be a printable ASCII string.

Billing Authentication: This attribute can be included in the billing request and indicates how the user was authenticated, ie by RADIUS, by the sender or by another remote authentication protocol. Users who are served without authentication should not generate billing records.

Charging session time: This attribute indicates how many seconds the user has received the service and can only be present in the charging request record with the charging status type set to stop.

• Billing Input Packets: This attribute indicates how many packets have been received from the port since service was provided to the framing user and is only present in billing request records with the Billing Status Type set to Stop. obtain.

• Billing Output Packets: This attribute indicates how many packets have been sent to the port since the service was provided to the framing user and is only present in billing request records with the Billing Status Type set to Stop. You can

• Charging Abort Cause: This attribute indicates how the session was aborted and can only be present in a billing request record with the Billing Status Type set to Stop.

Billing Response Message Upon receipt of the Billing Request, the RADIUS Billing Server shall respond with a Billing Response Message as to whether the recording of the billing packet was successful. It is not sent if the recording of the charging packet fails.

Glossary Terminology and Abbreviations CDMA (Code Division Multiple Access) A North American standard for digital voice and data wireless communications in the mobile telephone and PCS spectrum. A technique for multiplexing users over a wireless interface.

Internet Protocol (IP) Defines a mechanism for unreliable and connectionless transmission of user datagrams over the Internet.

The IWP-IP communication chassis provides the functionality for cooperating terminal equipment connected to TDMA or CDMA mobile telephones with terminal equipment connected to PSTN and Internet networks.

Second Layer Tunneling Protocol (L2TP) A protocol defined to enable tunneling of the PPP link layer protocol. Currently draft RF
Although it is in stage C, it is expected to be adopted as a standard.

Mobile Switching Center (MSC) A network element within a mobile telephone or PCS wireless telecommunications network that serves wireless users
Provides PSTN connectivity, control functions, and switching functions.

PPTP Access Concentrator (PAC) External connectivity (typically one or more
Equipment that supplies) via PSTN or ISDN lines. It can handle PPP operations and PPTP protocols. PAC is IP
User traffic to one or more PHS using
Tunnel to. It may also tunnel non-IP protocols.

PPTP Network Server (PNS) A communications chassis designed to run on a general purpose computing / server platform. Handles the PPTP protocol server side. Because PPTP is completely IP dependent and independent of interface hardware, PNS can use any combination of IP interface hardware, including LAN and WAN devices.

Point-to-Point Tunneling Protocol (PPTP) A protocol defined for tunneling PPP traffic between a PAC and a PNS. GRE (Generic Routing Encap
provides a flow / congestion control encapsulated datagram service for transmitting PPP packets using the general purpose routing encapsulation mechanism. It also supports “tunnel” control and function management, and sets / releases control connections and sets / releases data connections. There is one control connection and one data connection for each pair of PAC and PNS.

Public Switched Telephone Network (PSTN) A terrestrial telecommunications infrastructure that today supplies 3KHz line voice servers to fixed endpoints around the world.

Remote Authentication Dial-In User Service (RADIUS) Accepts user connection requests, authenticates users, and returns all configuration information needed by the client to send the service to the user. The RADIUS service can act as a proxy client to other RADIUS servers or other types of authentication servers. RADIUS server is PP
Supports P PAP, CHAP, UNIX login, and other authentication mechanisms.

TELNET Telnet is designed to support asynchronous communication between two Network Virtual Terminals (NVTs) over a TCP / IP connection. The NVT is a virtual device where both connections, the client and the server, map their actual output and input terminals.

Time Division Multiple Access (TDMA) A North American standard for data wireless telecommunications over mobile phones and the PCS spectrum. A technology for multiplexing users over a wireless interface.

Transmission Control Protocol (TCP) A highly reliable connection-oriented transmission mechanism for user data on an IP network.

TS-IP Tunneling server IP address User Datagram Protocol (UDP) A connectionless protocol built on IP. Service access (SAP) is identified by UDP port and IP address.

Virtual Private Network (VPN) A secure network built on the Internet for sending secure information access.

It will be apparent to those skilled in the art that various modifications and variations can be made to the embodiments disclosed herein without departing from the spirit and scope of the invention. The spirit and scope of the invention are set forth in the following claims, which are to be construed in light of the above detailed description.

─────────────────────────────────────────────────── ─── Continuation of the front page (51) Int.Cl. ⁷ Identification code FI H04M 3/00 H04L 11/00 310C 11/00 303 H04B 7/26 109M H04Q 7/38 109S (56) Reference European patent application publication 762261 (EP, A 1) International Publication 95/008900 (WO, A 1) Katsuko Tokutomi, Security Tools “Secure Acces s”, which is a key point of intranet / extranet, Computer & Network LAN, Japan, Ohmsha Co., Ltd. , June 1, 1997, Volume 15, No. 6, pages 89-91, Vijay K. Varma et. Al. , Architecture for interworking Data over PCS, IEEE Communications Magazine, USA, IEEE, September 1996, p124-130 MARKKU KYLANPAA et. al. , NOMADIC ACE SS TO INFORMATION SERVICES BY A GSM PHONE, Computer & Graphics, United Kingdom, Elsevier Sciences, 1996, Vol. 20, No. 5, pp 651-658 Charles Perkins et. al. , IMHP: A mobile host protocol for the Internet, Compputer Networks and ISDN Systems, UK, ELSEVIER, 1994, Vol. 27, pp479-491 (58) Fields investigated (Int.Cl. ⁷ , DB name) H04L 12/56 H04L 12/28 H04L 12/46 H04L 12/66 H04L 29/08 H04M 3/00

Claims (14)

(57) [Claims] 1. A method of connecting a remote user having a digital data source to a computer network, the digital data source communicating with a wireless service carrier over a wireless transmission medium, the wireless service carrier communicating the digital data. Multiplexing to a line, the method comprising the step of receiving the digital data at a communication device connecting the digital data source to the computer network via the wireless service carrier, wherein the communication device is the communication line. A local area or wide area packet switched computer network interface to the communication device from the digital data to the network associated with the digital data source. Network access authentication data, wherein the network access authentication data comprises at least (1) either a telephone number called by the user or (2) a telephone number associated with the user. Wherein the communication device has a step of transmitting the authentication data to a network authentication server for the computer network via the local area or wide area computer network connected to the communication device, and the digital data source Performing an authentication procedure between the two, determining whether the remote user is authorized to access the computer network based on both the transmitted authentication data and the authentication procedure. Have The authentication server notifies the communication device of the result of the determination step, and if the result of the determination step is a positive response, allowing the remote user to access the computer network, the digital data A method of tunneling digital data from a source to a tunneling server via said communication device to provide said access to said computer network. 2. The method of claim 1, further comprising identifying at the authentication server a tunneling server linked to the communication device that is used to provide the digital data source with access to the computer network. The method described. 3. The authentication server is used to tunnel digital data between the network access server and the tunneling server.
3. The method of claim 2, further comprising: determining a tunneling protocol for the digital data source, and tunneling digital data from the digital data source to the tunneling server according to the tunneling protocol. 4. The tunneling protocol is PPTP and
The method of claim 2, wherein the method is selected from the group of tunneling protocols including TELNET. 5. The method of claim 1, wherein the computer network comprises the Internet. 6. The method of claim 1, wherein the computer network comprises a corporate local area or wide area network. 7. The communication device provides access to a public switched telephone network, and the communication device, if the result of the determination step is a negative response, sends the digital signal via the public switched telephone network. The method of claim 1, wherein the method attempts to route data to a destination of the digital data. 8. (1) The tunneling server or (2)
The method of claim 2, further comprising the step of performing a password authentication routine between the authentication server and the digital data source, thereby providing authentication between the digital data source and the computer network. 9. An internet access method for an internet service provider having a communication device for receiving calls from a plurality of wireless remote users via a high speed communication line connected to a wireless network, wherein the communication device is local or wide area. Connecting to an authentication server via a network, and including at least (1) a telephone number called by the user or (2) a telephone number associated with the user from communication from the user, Extracting network access authentication data associated with the digital data source; routing the network authentication data to the authentication server to authenticate the user from the network authentication data; Identifying a tunneling server that provides network access and notifying the network access server of the tunneling server; and performing a password authentication procedure between the user and at least one of the tunneling server and the network access server. And a step of tunneling digital data from the network access server to the tunneling server and passing the digital data to the internet by the tunneling server. 10. The method of claim 9, further comprising identifying a tunneling protocol for the user for the tunneling step. 11. The method of claim 1, wherein the digital data from the user is tunneled to a tunneling server and encapsulated in a GRE header. 12. The method of claim 9, encapsulating the tunneled data in a GRE header. 13. An internet service provider system for a plurality of wireless internet users, comprising: a network access server; a first internet access authentication server managed by a first internet service provider; and a second internet service provider. A managed second Internet access authentication server, the network access server having an interface for receiving communication from the wireless Internet user and a gateway for passing digital data related to the wireless Internet user to a packet switching network. The first Internet access authentication server is linked to the network access server via a communication medium, Extracting Internet access authentication data from the communication from the wireless Internet user subscribing to one Internet service provider, the first authentication server further based on the Internet access authentication data. The first authentication server transfers an authentication response to the network access server, and the network access server includes the memory for determining whether or not access to the Internet is permitted. Responding to the authentication response from the authentication server of the wireless internet user, or permitting the wireless internet user to take other action if the authentication is negative. Bird The second Internet access authentication server is linked to the network access server via a communication medium, and for the wireless Internet users subscribed to the second Internet service provider, the network access server or the An internet service provider system, characterized in that it provides an internet authentication response to any of the second internet access authentication servers. 14. The system of claim 13, tunneling the digital data from the wireless user authorized to access the Internet to a tunneling server and encapsulating the digital data in a GRE header.