System and method for facilitating device authentication in a wireless communications system

This application claims the benefit of Provisional application No. 60/120,803, filed Feb. 19, 1999.

1. Field of Invention

This invention relates to communications systems. Specifically, the present invention relates to systems and methods for handling and supporting authentication protocols in a wireless communications network.

2. Description of the Related Art

Wireless communications are increasingly employed in a variety of demanding applications including Internet and local area network applications. Such applications demand wireless communications systems that efficiently accommodate various network protocols while affording users maximum security and privacy.

Laptops and other mobile computing devices often employ wireless phones and associated wireless communications networks to access the Internet and other data networks and application servers. Browser functionality required to access the Internet is often built into the mobile computing device, wireless phone, or other wireless computing device.

The wireless phone (Mobile Terminal (MT 2 )) and any accompanying electronic devices (Terminal Equipment (TE 2 )) are collectively called the mobile station. The interface between the wireless phone transceiver (Mobile Station Modem (MSM)) and an accompanying TE 2 device is called the R m interface. In mobile stations not employing separate TE 2 devices, the communications interface between the MSM and any browser functionality built into the wireless phone is also called the R m interface. The wireless communications interface between the wireless phone and associated wireless network infrastructure is called the U m interface.

A wireless communications system, such as a Code Division Multiple Access system (CDMA), typically includes a plurality of mobile stations (e.g. wireless phones, palmtop or laptop computers connected to wireless modems, and so on) in communication with one or more base stations or base station transceiver subsystems (BTS), also called cell sites.

A base station and/or BTS facilitates call routing among mobile stations and between mobile stations and a Mobile Switching Center (MSC). The MSC facilitates call routing between base stations or BTS's and other communications devices that are connected to the Public Switched Telephone Network (PSTN), also called the landline network. The MSC may also facilitate call routing between base stations and/or BTS's and the Internet via an Interworking Function (IWF). The IWF is often co-located with the MSC. The communications interface between the IWF and the MSC is called the L interface. The L interface is often designed in accordance with the IS-707 telecommunications industry standard. The IWF typically includes a router that routes calls between the IWF and the Internet via Quick Net Connect (QNC) methods.

Additional details of a wireless CDMA communications system are discussed in U.S. Pat. No. 5,103,459, entitled “SYSTEM AND METHOD FOR GENERATING SIGNAL WAVEFORMS IN A CDMA CELLULAR TELEPHONE SYSTEM”, assigned to the assignee of the present invention and incorporated herein by reference. BTS architecture is discussed more fully in U.S. Pat. No. 5,654,979, entitled “CELL SITE DEMODULATION ARCHITECTURE FOR A SPREAD SPECTRUM MULTIPLE ACCESS COMMUNICATIONS SYSTEM”, assigned to the assignee of the present invention and incorporated herein by reference.

CDMA communications systems are often built in accordance with the IS-95 telecommunications industry standard. In IS-95 systems, data is transmitted between a BTS and a mobile station in digitally encoded frames. For data services calls, the Radio Link Protocol (RLP) is used to transmit data packets inside of the IS-95 frames. RLP is, in turn, used to transmit PPP packets. PPP is the data link layer protocol that is used for IS-95 data services. PPP packets are encoded in High Level Data Link Control (HDLC) frames for transmission over the R m U m and L interfaces. Use of PPP packets with HDLC frames is discussed more fully in Request For Comment (RFC) 1662, entitled PPP IN HDLC LIKE FRAMING, published in July 1994.

The telecommunications industry standard IS-707 details the behavior of data transmission between TE 2 devices and an IWF. The IS-707 standard introduces a Network Model that specifies protocol requirements for the R m , U m , and L interfaces. In accordance with the Network Model, one Point-to-Point Protocol (PPP R ) link is established on the R m interface between the MT 2 device and associated TE 2 device, while a separate PPP link (PPP U ) link is established on the U m and L interfaces between the MT 2 device and the IWF.

PPP provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP specifies methods for encapsulating multi-protocol datagrams and includes a Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. PPP also includes various Network Control Protocols (NCP's) for establishing and configuring various network-layer protocols. PPP is more fully discussed in Request For Comment (RFC) 1661, entitled THE POINT-TO-POINT PROTOCOL, published in July 1994.

When a mobile station travels between wireless communications systems or between base station coverage areas, the mobile station is handed off from the first system to the target system. If the target system is associated with a different IWF, then the U m link is renegotiated. In this case, the link between the mobile station and the first wireless communications system is eventually dropped and a new U m link is established between the mobile station and the target wireless communications system. In a network model call, U m and R m links are isolated so that handoffs and other U m link renegotiations are transparent to the R m link.

To provide such isolation, PPP stack on the wireless phone, i.e., MT 2 device, typically unframes and reframes PPP configuration packets received over the U m and R m links. The PPP configuration packets specify configuration options for the R m and U m interfaces. Unfortunately, existing MT 2 devices typically unnecessarily unframe, process, and reframe all PPP packets, and hence, some PPP packets are unnecessarily unframed, processed, and reframed. This may reduce data throughput over the R m and U m links, increase MT 2 device power consumption, decrease device battery life, and require additional MT 2 device processing resources.

Users of wireless communications devices, such as laptops connected to wireless modems, often subscribe to one or more networks services, such as Internet access, via an Internet Service Provider (ISP). Users and associated service providers often demand secure and private communications between users and the service providers. Accordingly, wireless communications networks demand efficient systems and methods to validate, i.e., authenticate users before granting access to a data network, such as the Internet. Unfortunately, existing wireless CDMA communications networks typically lack efficient systems and methods for reliably authenticating the user of a TE 2 device or the TE 2 device itself.

Hence, a need exists in the art for an efficient system and method for facilitating secure and private communications between a TE 2 device and a communications network. There is a further need for a system and method for efficiently authenticating TE 2 devices.

The need in the art is addressed by the system for efficiently accommodating an authentication protocol in a communications system of the present invention. In the illustrative embodiment, the inventive system adapted for use with Point-to-Point Protocol (PPP) and Challenge Handshake Authentication Protocol (CHAP) in a Code Division Multiple Access (CDMA) wireless communications system. The system includes a first mechanism for establishing a first communications interface (R m interface) between a first device (TE 2 device) and a second device (MT 2 device) and for establishing a second communications interface (U m interface) between the second device and a third device (BS/MSC/IWF). A second mechanism selectively relays authentication signals received by the second device between the first device and the third device. A third mechanism employs the third device and the second mechanism to authenticate the first device via the first communications link and the second communications link.

In a specific embodiment, the third mechanism further includes a fourth mechanism for selectively processing configuration signals received by the second device over the second interface. The first interface and the second interface are point-to-point protocol (PPP) interfaces. The first interface is a U m interface, and the second interface is an R m interface.

The second mechanism includes CHAP. The communications system includes a wireless CDMA communications system. The first device includes a TE 2 device and the second device includes an MT 2 device. The third device includes a base station, a Base Station Transceiver Subsystem (BTS), and/or a Mobile Switching Center (MSC) in communication with an Interworking Function (IWF). The U m interface includes a wireless interface between the MT 2 device and the base station, BTS, or MSC of the wireless communications system.

In a more specific embodiment, the MT 2 device includes a wireless phone. The TE 2 device includes a computer, such as a laptop computer. The first mechanism includes standard Point-to-Point Protocol (PPP) stacks on the third device and the first device, and modified PPP stacks on the second device. The second mechanism includes a fifth mechanism for analyzing packets received by the second device to ascertain if the packets are CHAP packets and providing a first signal in response thereto. A sixth mechanism selectively relays packets in response to the first signal. The third mechanism includes CHAP installed on the third mechanism and the first mechanism.

The novel design of the present invention is facilitated by the second mechanism, which selectively relays authentication signals and other signals not requiring IS-707 network model processing via the second device through to the first device and/or third device. This represents an unobvious alteration that yields significant advantages. Namely, the second device does not require provisioning with authentication secrets and usernames, and facilitates authenticating the first device via the third device. By avoiding provisioning the second device with shared secrets and user names, improvements in network security and efficiency are achieved as discussed more fully below. Furthermore, by avoiding unnecessary processing of CHAP on the second device, communications system throughput is enhanced and processing resources are conserved.

FIG. 1 is a diagram of a communications system constructed in accordance with the teachings of the present invention and adapted for use with the IS-707 network model.

FIG. 2 is a diagram of a conventional PPP packet encapsulated in a standard HDLC frame.

FIG. 3 is a more detailed diagram of the MT 2 device of FIG. 1 showing the CHAP packet relaying system of FIG. 1 .

FIG. 4 is a message flow diagram illustrating the operation of the CHAP packet relaying system of FIGS. 1 and 3.

FIG. 5 is a flow diagram of software employed by the communications system of FIG. 1 to facilitate efficient, private, and secure communications between the TE 2 device and the IWF of FIG. 1 via the CHAP packet relaying system of FIGS. 1 and 3 .

While the present invention is described herein with reference to illustrative embodiments for particular applications, it should be understood that the invention is not limited thereto. Those having ordinary skill in the art and access to the teachings provided herein will recognize additional modifications, applications, and embodiments within the scope thereof and additional fields in which the present invention would be of significant utility.

FIG. 1 is a diagram of a communications system 10 constructed in accordance with the teachings of the present invention and adapted for use with the IS-707 network model. For clarity, various details have been omitted from FIG. 1, however, with reference to the present teachings, one skilled in the art may readily recognize and implement additional requisite components without undue experimentation.

The system 10 includes a mobile computing device (Terminal Equipment (TE 2 device)) 12 , such as a laptop or palm top computer. The TE 2 device 12 is connected to a wireless modem (Mobile Terminal (MT 2 device)) 14 , such as a wireless phone, via an R m interface. The MT 2 device 14 includes a CHAP packet relaying system 16 . The MT 2 device 14 is connected to wireless communications system infrastructure 18 via a wireless U m interface. The infrastructure 18 may include Base Stations (BS's), Base Station Transceiver Subsystems (BTS's), Base Station Controllers (BSC's), Mobile Switching Centers (MSC's), and other wireless communications system infrastructure components. The infrastructure 18 is connected to the Public Switched Telephone Network (PSTN) 20 . The infrastructure 18 is also connected to an Interworking Function (IWF) 22 that is connected to the Internet 24 . The IWF 22 includes one or more routers and modem pools (not shown) for routing calls between the wireless infrastructure 18 and the Internet 24 .

In accordance with the IS-707 network model, the MT 2 device 14 includes two PPP MT2 stacks (not shown), one for each of the R m and U m interfaces; the TE 2 device 12 includes a PPP TE2 stack for the R m interface; and the IWF includes a PPP IWF stack for the L and U m interfaces.

In operation, the user of the TE 2 device 12 and MT 2 device 14 places a call through the MT 2 device 14 to a different communications device (not shown), such as an application server connected to the PSTN 20 , or to an Internet Service Provider (ISP) (not shown) associated with the IWF 22 and the Internet 24 . For the purposes of the present discussion, the MT 2 device 14 is a wireless phone, and the TE 2 device 12 is a laptop computer.

When the call is placed, a PPP Um,L communications link is established between the MT 2 device 14 and the IWF 22 via the PPP IWF and PPP MT2 protocol stacks. A second PPP Rm link is established between the MT 2 device 14 and the TE 2 device 12 via the PPP TE2 and PPP MT2 protocol stacks.

PPP supports the Challenge Handshake Authentication (CHAP) protocol, which is designed for inclusion in PPP stacks. Authentication protocols are often employed to verify that users attempting to access a particular service are authorized users. For an example, the IWF 22 may wish to verify that the user of the TE 2 device 12 is an authorized user of Internet access service offered via the IWF 22 .

CHAP is often employed to improve the security of the communications link between two communications devices employing PPP protocols. CHAP is included in most PPP implementations and so is expected to be found in the PPP stacks on the communications devices. PPP also defines an extensible Link Control Protocol, which allows negotiation of an authentication protocol for allowing an authenticator to authenticate a peer before allowing network layer protocols to transmit over the link.

The authenticator is generally defined as the end of the link requiring the authentication. The authenticator indicates the employed authentication protocol via a Configure-Request message sent during a PPP link establishment phase. The end of the point-to-point link that is being authenticated by the authenticator is called the peer.

A CHAP authenticator sends a random challenge to a peer. The peer responds with a hashed response based on the challenge and a shared secret. To establish communications over a PPP link, each end of the PPP link sends LCP packets to configure the link during the PPP link establishment phase. An authentication phase follows the establishment of the PPP link. A network-layer protocol phase follows the authentication phase.

If authentication of the link is desired, a PPP implementation must specify the authentication-protocol configuration option during the PPP link establishment phase. CHAP periodically verifies the identity of the peer using a 3-way handshake upon initial link establishment and at random times during the establishment of the link.

After the link establishment phase is complete, the authenticator may send a challenge message to the peer. The peer responds with a value calculated using a one-way hash function. The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged. Otherwise, the connection is terminated. At random intervals, the authenticator may send a new challenge to the peer, repeating the above steps.

CHAP packets may be framed and re-framed in the MT 2 device 14 without departing from the scope of the present invention. In this case, the unframed CHAP packets are directed to bypass any PPP state machines in the MT 2 PPP stacks 68 . This is employed in instances where unframing is required by an implementation to determine the type of the incoming frame.

The following discussion of an exemplary CHAP implementation in the system 10 is intended to facilitate an understanding of the present invention. In the present example, the IWF 22 periodically authenticates the MT 2 device 14 or the user thereof. The IWF 22 and the MT 2 device 14 have a shared secret, such as a password known by both the IWF and the MT 2 device 14 . The IWF 22 maintains a different shared secret for different MT 2 devices and categorizes the shared secrets by the identification numbers (or user names) associated with the MT 2 devices. The IWF periodically sends a CHAP challenge to the MT 2 device 14 and waits for a reply. The MT 2 device 14 then employs the shared secret, information from the CHAP challenge, and a predetermined hash function to generate a CHAP response. The CHAP response includes some form of user identification, such as mobile station ID or user name associated with the MT 2 device 14 . When the IWF 22 receives the CHAP response, the IWF employs the MT 2 ID or user name to access the corresponding hash function and shared secret and then runs the hash function employing the shared secret. The result of the hash function is compared with the response received from the MT 2 device 14 . If the result matches the CHAP response received from the MT 2 device 14 , then the MT 2 device 14 is considered authentic.

Unfortunately, authenticating the MT 2 device 14 while not authenticating the TE 2 device is often undesirable. For example, a stolen MT 2 device 14 may be connected to a laptop 12 and used to steal services associated with the MT 2 device 14 . Furthermore, implementing CHAP in the MT 2 device 14 may require provisioning the MT 2 device 14 with a user name and shared secret. This may require additional memory and software functionality to encode and store the shared secret and user name, which may undesirably increase the cost and size of the MT 2 device 14 . Alternatively, a user may enter the shared secret via a user interface, such as a keyboard or audio input device. However, this requires that the user remember the shared secret and user name and requires additional expensive user interface functionality.

It is often desirable to authenticate the TE 2 device 12 , since the TE 2 device 12 may include functionality, such as browser functionality, not included in the MT 2 device 14 , which is required to access services for which authentication is required. However, employing CHAP on the MT 2 device 14 to authenticate the TE 2 device is inefficient, redundant, and impractical in many applications.

By providing an unobvious alteration to CHAP handling functionality on the MT 2 device 14 , the preferred embodiment of the present invention overcomes the shortcomings associated with the previous example as discussed more fully below. Rather than including CHAP in the PPP MT2 stacks in the MT 2 device 14 , CHAP is included on the PPP TE2 stack of the TE 2 device 12 . CHAP packets, such as CHAP challenges received by the MT 2 device 14 from the IWF 22 are relayed by the CHAP packet relaying system 16 of the MT 2 device 14 to the TE 2 device 12 . Similarly, CHAP packets received by the MT 2 device 14 from the TE 2 device 12 are relayed by the CHAP packet relaying system 16 to the IWF 22 . Hence, CHAP authentication is performed directly between the IWF 22 (authenticator) and the TE 2 device 12 (peer), thereby bypassing PPP MT2 stacks and associated additional Network Model processing on the MT 2 device 14 . Those skilled in the art will appreciate that some form of Network Model processing may be employed in the MT 2 device 14 to determine packet type without departing from the scope of the present invention.

The preferred embodiment of the present invention passes any CHAP messages strait through the MT 2 device 14 without processing the CHAP messages in the PPP MT2 of the MT 2 device 14 . Hence CHAP works, as designed, between the user (associated with the TE 2 device 12 ) and authenticator (IWF 22 ) with no intermediary (MT 2 device 14 ).

A PPP peer should be able to respond to a CHAP challenge during any stage of PPP. If a PPP Rm link is established on the R m interface, and the MT 2 device 14 is handed of to a new IWF (not shown), CHAP on the TE 2 device 12 negotiates the new PPP Um link between the TE 2 device 12 and the IWF 22 . This provides network model functionality without requiring CHAP support in the MT 2 device 14 . This also obviates provisioning the MT 2 device 14 with the shared secret and user name.

The present invention can include additional functionality running on a controller in the MT 2 device 14 (as discussed more fully below) to accommodate problematic IWF 22 name changes. The additional functionality changes the name field associated with CHAP challenges received from the IWF 22 to a constant that remains the same across all IWF 22 's before relaying the CHAP challenge to the TE 2 device 12 . Some rare situations may necessitate changing the name field in a CHAP packet (via the additional functionality described above) in a CHAP response from the IWF 22 when the TE 2 device 12 attempts to authenticate the IWF 22 . As the CHAP challenge is passing through the MT 2 device 14 , it is possible for the MT 2 device 14 to change the name field in the challenge message to a value that remains the same for all IWF's. This requires recalculating the cyclic redundancy check bit (CRC) at the end of the packet. If the CHAP implementation on the TE 2 device 12 balks at receiving a CHAP challenge from a different host than previous challenges, this functionality provides a solution. Those skilled in the art will appreciate that the additional functionality may be implemented by one skilled in the art with access to the present teachings.

In the present embodiment, the R m link employs the RS-232 protocol. Protocols other than RS-232 may be employed for the R m link, such as Universal Serial Bus (USB) and Bluetooth protocols without departing from the scope of the present invention. Similarly, protocols in addition to or other than PPP may be employed on the U m link without departing from the scope of the present invention. In these cases, CHAP packets or other authentication protocol packets are still relayed to the TE 2 device 12 via the CHAP packet relaying system 16 in the MT 2 device 14 , which may be implemented by one skilled in the art with access to the present teachings.

The USB protocol is described in UNIVERSAL SERIAL BUS SPECIFICATION, REVISION 1.1, published in September 1998. Bluetooth is described in BLUETOOTH SPECIFICATION VERSION 1.0A CORE, published in July 1999.

IS-99 industry standards are also employed for communications between the TE 2 device 12 and the IWF 22 via the R m , U m , and L interfaces. QNC facilitates circuit switched call origination by the MT 2 device 14 . A circuit switched call is a type of packet call. The link between the packet IWF 22 and the Internet 24 may be implemented via standard connections, such as high-speed serial, T 1 , T 3 , or perhaps frame relay connections.

FIG. 2 is a diagram of a conventional PPP frame 30 . The PPP frame 30 includes a 1-byte frame delimiter flag 32 followed by a variable length information section 36 followed by another frame delimiter flag 34 . The information section 36 includes, from left to right, a 1-byte address field 38 , a 1-byte control field 40 , a 2-byte protocol-type field 42 , a 1-byte code field 44 , a 1-byte identification field 46 , a 2-byte length field 48 , a variable length option field 50 , and a 2-byte frame check field 52 . Fields 38 , 40 , 42 and 52 are part of PPP framing, while fields 44 , 46 , 48 and 50 are part of the PPP protocols, such as LCP and CHAP.

The protocol type field 42 specifies the type of information packet associated with the frame 30 . The protocol type field 42 is employed by the CHAP packet relaying system (see 16 of FIG. 1) of the present invention, as discussed more fully below, to determine if the information packet associated with the current frame 30 is a PPP configuration packet, a CHAP packet, or another type of PPP packet. Examples of PPP configuration packets are Link Control Protocol (LCP) packets and an Internet Protocol Control Protocol (IPCP) packets. PPP configuration packets typically include configuration messages, such as Configure-Request, Configure-Ack, and Configure-Nak messages. The code field 44 indicates the type of the current message, such as a Configure-Request message.

FIG. 3 is a more detailed diagram of the MT 2 device 14 of FIG. 1 showing the CHAP packet relaying system 16 constructed in accordance with the teachings of the present invention. The CHAP packet relaying system 16 includes a reverse link R m interface packet relaying system 60 and a reverse link U m interface packet relaying system 62 .

For clarity, various components have been omitted from FIG. 3, such as amplifiers, clocks, antennas, mixers, down converters, display screens, microphones, speakers, and so on. However, one skilled in the art with access to the present teachings will know where and how to implement the additional requisite components without undue experimentation.

The MT 2 device 14 includes an R m interface transceiver 64 for transmitting signals from the MT 2 device 14 and receiving signals to the MT 2 device across the R m interface. A first input of the R m interface transceiver 64 is connected to an output of an R m interface framer 66 , an input of which is connected to MT 2 PPP stacks 68 . The MT 2 PPP stacks 68 may include one or more processors and/or state machines to implement the PPP stacks. Conventional PPP stacks may be easily adapted for use with the present invention by one ordinarily skilled in the art with access to the present teachings.

A second input of the R m interface transceiver 64 is connected to an output of the reverse link U m interface packet relaying system 62 . An output the R m interface transceiver 64 is connected to the R m interface packet relaying system 60 . A first output of the R m interface transceiver 64 is connected to a first input of a U m interface transceiver 70 . A second input of the U m interface transceiver 70 is connected to an output of a U m interface framer 72 , an input of which is connected to an output of the MT 2 PPP stacks 68 . An output of the U m interface transceiver 70 is connected to an input of the reverse link U m interface packet relaying system 62 . An output of the U m interface packet relaying system 62 is connected to a U m interface unframer 74 , an output of which is connected to an input of the MT 2 PPP stacks 68 . Another input of the MT 2 PPP stacks 68 is connected to an output of a R m interface unframer 76 , an input of which is connected to an output of the R m interface packet relaying system 60 . An MT 2 controller and user interface 78 is connected to the MT 2 PPP stacks 68 . The MT 2 controller and user interface 78 facilitates updating or editing MT 2 protocol stacks 68 .

In operation, PPP links are established over the R m and U m interfaces as discussed above. PPP frames received by the MT 2 device 14 via the R m interface are sent to the R m interface packet relaying system 16 . The R m interface packet relaying system 16 analyzes each received frame to determine whether the frame should be relayed directly to the U m interface via the U m interface transceiver 70 or unframed by the R m interface unframer 76 and processed by the MT 2 PPP stacks 68 before being reframed by the U m interface framer 72 and transmitted over the U m interface via the U m interface transceiver 70 . In the present embodiment, the R m interface packet relaying system 60 analyzes a certain number of bytes from each incoming frame by first unescaping the bytes to determine the type of packet associated with the current received frame, as discussed more fully below. Systems and methods for unescaping bytes are known in the art.

If the current receive frame is associated with a CHAP packet or message then the frame is relayed or forwarded to the U m interface transceiver 70 in preparation for transmission over the U m interface. If the current received frame is associated with a PPP configuration packet, such as an LCP or an IPCP packet, the frame is sent to the R m interface unframer 76 in preparation for processing by the MT 2 PPP protocol stacks 68 . Generally, select PPP packets that are not PPP configuration packets and do not require Network Model processing via the MT 2 PPP protocol stacks 68 are relayed to the U m interface transceiver 70 in preparation for transmission over the U m interface. Hence, CHAP packets and select PPP packets other than PPP configuration packets are selectively relayed to the U m interface transceiver 70 , thereby bypassing additional processing via the R m interface unframer 76 , the MT 2 PPP stacks 68 , and the U m interface framer 72 .

Similarly, CHAP packets received over the U m interface by the U m Interface transceiver 70 and the U m interface packet relaying system 62 are relayed to the R m interface transceiver 64 in preparation for transmission over the R m interface, thereby bypassing additional processing via the U m interface unframer 74 , the MT 2 PPP stacks 68 , and the R m interface framer 66 . By selectively passing CHAP packets and select PPP packets other than PPP configuration packets through the MT 2 device 14 via the packet relaying system 16 , 60 , and 62 , the present invention avoids unnecessary processing of packets. Furthermore, the TE 2 device 12 is authenticated via CHAP rather than MT 2 device 14 , which is desirable for aforementioned reasons.

Alternatively, the R m interface packet relaying system 60 may be altered and repositioned after the R m interface unframer 76 so that the R m interface packet relaying system 60 receives unframed packets as input. Similarly, the U m interface packet relaying system 62 may be altered and repositioned after the U m interface unframer 74 so that the U m interface packet relaying system 62 receives unframed packets as input. In these cases, the packet relaying systems 60 and 62 are altered to determine the type of incoming packet by analyzing the protocol type fields (see 42 of FIG. 2) of received unframed packets rather than received framed packets. This alteration may be done by one skilled in the art will access to the present teachings.

In the present specific embodiment, the R m interface transceiver 64 is constructed in accordance with EIA-232 Electronics Industry Association standards. The U m interface transceiver 70 is constructed in accordance with IS-95 Telecommunications Industry Association standards. Those skilled in the art will appreciate that while the present embodiment is adapted for use with PPP, the packet relaying systems 60 and 62 may be altered by one skilled in the art with access to the present teachings to accommodate a different protocol to meet the needs of a given application without departing from the scope of the present invention.

FIG. 4 is a message flow diagram 80 illustrating the operation of the CHAP packet relaying system 16 of FIGS. 1 and 3. The message flow diagram 80 illustrates an exemplary message sequence between the IWF 22 , the MT 2 device 14 , and the TE 2 device 12 over the U m , L, and R m interfaces, which takes place over time, which is represented by the time axis 82 . PPP or IP packets received by the MT 2 device 14 from the TE 2 device 12 or the IWF 22 are processed in the MT 2 device 14 in accordance with the IS-707 Network Model. However, CHAP packets are passed through the MT 2 device 14 and bypass Network Model processing in the MT 2 device 14 .

CHAP may be substituted with another type of authentication protocol without departing from the scope of the present invention. In such cases, packets of the different authentication are also passed through the MT 2 device 14 and bypass Network Model processing in the MT 2 device 14 .

In the preferred embodiment, packets other than CHAP packets, such as select PPP packets that are not PPP configuration packets, are also passed through the MT 2 device 14 , thereby bypassing Network Model processing in the MT 2 device 14 and improving the efficiency of the communications links between the TE 2 device 12 and the IWF 22 .

FIG. 5 is a flow diagram of exemplary software 90 adapted for use with the communications system 10 of FIG. 1 to facilitate efficient, private, and secure communications between the TE 2 device 12 and the IWF 22 of FIG. 1 via the CHAP packet relaying system 16 , 60 , 62 of FIGS. 1 and 3. With reference to FIGS. 1, 2 , and 3 , the software 90 runs on the R m interface packet relaying system 60 and the U m interface packet relaying system 62 of FIG. 3 . The relaying systems 60 and 62 may be selectively enabled and disabled via enable inputs (not shown) from the MT 2 controller 78 of FIG. 3 . When disabled, the relaying systems 60 and 62 of the system 16 pass incoming data through to the R m interface unframer 76 and to the U m interface unframer 74 , respectively. It is also possible that the PPP packet be unframed, and by examining the protocol type field 42 , a determination is made whether to forward the packet to the PPP MT2 stacks 68 , or if it should be forwarded directly to the framer, thus bypassing the PPP MT2 stacks 68 .

In an initial scanning step, the CHAP packet relaying system 16 scans the incoming data stream from the R m interface transceiver 64 and the U m interface transceiver 70 for flags. Subsequently, control is passed to a flag-checking step 94 .

The flag-checking step 94 determines if a frame flag (See 32 and 34 of FIG. 2.) was detected in the scanning step 92 . If a frame flag was not detected, control is passed back to the scanning step 92 . Otherwise, control is passed to a first byte-checking step 96 .

The first byte-checking step 96 determines if the subsequent received byte is associated with a frame flag. If the next byte is associated with a frame flag, control is passed back to the byte-checking step 96 , which checks the subsequent byte. If the next byte is not associated with a frame flag, control is passed to a first unescaping step 100 where predetermined number (X) of subsequent bytes are unescaped. Subsequently, control is passed to a second byte-checking step 102 .

The second byte-checking step 102 determines if the X unescaped bytes include bytes associated with address and control fields (See 38 and 40 of FIG. 2 .). If the X unescaped bytes do not contain address and control fields, control is passed to a packet type-checking step 104 . Otherwise, control is passed to a second unescaping step 106 , where the next two bytes are unescaped, and control is then passed to the protocol-checking step 104 .

The protocol-checking step 104 determines if the current frame represents a CHAP packet or a PPP packet other than a PPP configuration packet. If the unescaped bytes indicate that the current frame is associated with a CHAP packet or a PPP packet that is not a PPP configuration packet, then control is passed to a relaying step 108 , where the current frame is relayed to the MT 2 transceiver 64 or 70 . If the unescaped bytes do not indicate that the current frame is associated with a CHAP packet and/or indicate that the packet is a PPP configuration packet, control is passed to an unframing step 110 , where the current frame is sent to the MT 2 unframer 74 or 76 . Subsequently, control is passed to a disable-checking step 112 .

The disable-checking step 112 determines if a disable command was received from the MT 2 controller 78 . If a disable command was received, the software 90 ends and may be restarted with an enable command. Otherwise, control is passed back to the scanning step 92 .

Software and methods other that described above for the software 90 may be employed to determine the type of incoming packet, i.e., CHAP or PPP configuration packet, without departing from the scope of the present invention.

Additional methods for determining the type of protocol packet that is associated with a received PPP frame are disclosed in co-pending U.S. patent application Ser. No. 09/392,342, filed Sep. 8, 1999, by QUALCOMM INC., entitled METHODS FOR EFFICIENT EARLY PROTOCOL DETECTION, (Atty. Docket No. 990035), assigned to the assignee of the present invention and incorporated herein by reference. Additional methods for selectively framing and unframing PPP packets are disclosed in co-pending U.S. patent application Ser. No. 09/353,109, filed Jul. 14, 1999, by QUALCOMM Incorporated, entitled SELECTIVELY FRAMING AND UNFRAMING PPP PAKCETS DEPENDING ON NEGOTIATED OPTIONS ON THE UM AND RM INTERFACES, (Atty. Docket No. QCPA 863), assigned to the assignee of the present invention and incorporated herein by reference.

Thus, the present invention has been described herein with reference to a particular embodiment for a particular application. Those having ordinary skill in the art and access to the present teachings will recognize additional modifications, applications, and embodiments within the scope thereof.

It is therefore intended by the appended claims to cover any and all such applications, modifications and embodiments within the scope of the present invention.

Accordingly,