WO2003105510A1

WO2003105510A1 - Support for packet dormancy in a wireless communication device

Info

Publication number: WO2003105510A1
Application number: PCT/US2002/021783
Authority: WO
Inventors: Marcello Lioy; Nischal Abrol
Original assignee: Qualcomm Incorporated
Priority date: 2002-06-07
Filing date: 2002-07-09
Publication date: 2003-12-18
Also published as: CN1669346A; AU2002368003A1; CN100401813C; MXPA04012219A; HK1079946A1

Abstract

The disclosure is directed to techniques for indicating the status of a connection with a base station to a TE2 device. An MT2 device employing the disclosed techniques may include a processor to identify a loss of a connection with the base station, and continue to indicate to a data terminal that the connection exists unless a session-ending event has occurred. Release of the connection due to packet dormancy, loss of the connection due to fade, and loss of the connection due to a hard handoff are not necessarily session-ending events. Session-ending events are events whose occurrence indicates that connection is not needed or will not be available. An MT2 device employing the disclosed techniques may emulate a modem. The processor may indicate that connection exists by asserting a data carrier detect (DCD) pin, and that the connection is lost by deasserting the DCD pin. An MT2 device employing the disclosed techniques may override any received AT & C command.

Description

SUPPORT FOR PACKET DORMANCY IN A WIRELESS COMMUNICATION DEVICE

TECHNICAL FIELD

[0001] The disclosure relates generally to wireless communication and, more particularly, to the provisioning of wireless data services via a wireless communication device.

BACKGROUND

[0002] A data terminal (TE2 device), such as a computer, personal digital assistant (PDA), or the like, may be connected to a network such as the Internet. TE2 devices are typically connected to the network via a dial-up or network connection. Typically, these methods of connecting a TE2 device to the network involve a physical connection between the TE2 device and either the public switched telephone network (PSTN), or a network that is connected via one or more routers to the broader Internet. [0003] Users of TE2 devices may also wish to connect a TE2 device to the Internet when physical connections are unavailable. For this reason, wireless connectivity to the Internet has become increasingly desirable. Subscribers to wireless cellular telephone service, for example, can connect a TE2 device to the Internet via a wireless telecommunications system using a wireless communication device (MT2 device), such as a cellular radiotelephone, a wireless PCMCIA card incorporated within a computer, a PDA or personal computer equipped with wireless communication capabilities, or the like.

SUMMARY

[0004] In general, this disclosure is directed to techniques that may be implemented by an MT2 device to indicate the status of a connection with a wireless base station to a TE2 device. In particular, this disclosure is directed to an MT2 device that emulates a modem, but overrides received AT&C commands to assert and deassert a data carrier detect (DCD) pin according to the disclosed techniques. In this manner, the MT2 device can cause the TE2 device to maintain an existing communication session, e.g., a point-to- point protocol (PPP) session, even though connection with a remote server via an over- the-air communication channel has been temporarily lost or released, e.g., to conserve air resources when the MT2 device is inactive. [0005] In one embodiment, the disclosure is directed to a method that may be implemented by a wireless communication device, such as an MT2 device. A loss of a wireless connection between a wireless communication device and a base station is identified. An MT2 device implementing the method, however, continues to indicate to a data terminal coupled to the wireless communication device that the wireless connection exists following the loss of the wireless connection.

[0006] In another embodiment, the disclosure is directed to a wireless communication device, such as an MT2 device. The wireless communication device comprises a transceiver to provide a wireless connection with a base station and a data port to couple the wireless communication device to a data terminal. The wireless communication device further comprises a processor to identify a loss of the wireless connection with the base station and continue to indicate to the data terminal that the wireless connection exists following the loss of the connection.

[0007] In another embodiment, the disclosure is directed to a computer-readable medium containing instructions. The instructions cause a programmable processor to identify a loss of a wireless connection between a wireless communication device and a base station. The instructions further cause the processor to continue to indicate to a data terminal coupled to the wireless communication device that the wireless connection exists following the loss of the wireless connection.

[0008] In another embodiment, the disclosure is directed to a wireless communication device, such as a MT2 device. The wireless communication device comprises means for identifying a loss of a wireless connection between the wireless communication device and a base station. The wireless communication device further comprises means for continuing to indicate to a data terminal coupled to the wireless communication device that the wireless connection exists following the loss of the wireless connection.

BRIEF DESCRIPTION OF DRAWINGS

[0009] FIG. 1 is a block diagram illustrating an exemplary wireless communication system.

[0010] FIG. 2 is a block diagram illustrating a connection between a data terminal and an interworking function or packet data serving node via a wireless communication device and a base station/mobile switching station. [0011] FIG. 3 is a block diagram illustrating an exemplary wireless communication device coupled to a data terminal.

[0012] FIG. 4 is a flowchart illustrating a method for selectively indicating the status of a connection between a wireless communication device and a base station to data terminal, e.g., via selective assertion and deassertion of a carrier detect pin.

[0013] FIG. 5 is a flowchart further illustrating the method illustrated in FIG. 4.

DETAILED DESCRIPTION

[0014] Techniques described herein may be implemented in an MT2 device to override received AT&C commands and thereby selectively assert and deassert a data carrier detect (DCD) pin to maintain a communication session even though connection with a remote server via an over-the-air communication channel has been temporarily lost or released. The communication channel may be released, for example, to conserve air resources when the MT2 device is inactive. An MT2 device employing the disclosed techniques may advantageously support packet dormancy by avoiding needless teardown of a point- to-point protocol (PPP) session and reestablishment cycles in the TE2 device. Teardown of the PPP session results in the loss of IP connectivity, which can have an adverse effect on any running applications. Packet dormancy supports continued IP connectivity during periods in which the communication channel has either been lost or released. Advantageously, in some embodiments, the techniques described herein may thus conserve airtime, avoid unnecessary power consumption, and decrease data transmission delays, decreasing the overall cost of the wireless data session for the user and improving quality of service.

[0015] A serial networking application software package loaded on the TE2 device can be used to connect the TE2 device to the Internet via an MT2 device. When a TE2 device is connected to the Internet via a dial-up connection, a modem, which may be attached to or integral with the TE2 device, is used. The networking software controls the operation of the modem using "AT" commands. The AT command set is well-known in the art, and is defined by the use of the ASCII prefix "AT," in either lower or upper case, followed by any one of a set of other predefined codes. For example, the AT dial command, ATD or ATDT, directs the modem to dial a telephone number. [0016] Typically, the modem dials a telephone number and connects to a remote modem, which is in turn connected, directly or indirectly, to a server maintained by an Internet service provider (ISP). The TE2 device, using the networking software, then negotiates a PPP session with the server. When the PPP session is negotiated, the TE2 device may send data packets framed according to the negotiated protocol to the server, which will reframe the data packets and forward them to the Internet. In a similar manner, the TE2 device receives packages from the Internet via the server.

[0017] When the modem connects to the remote modem, it may assert a DCD pin, which is one of a number of such connections between the modem and the TE2 device. Asserting the DCD pin ordinarily involves setting the voltage on the DCD pin high. The DCD pin is used to indicate the connection with the remote modem to the TE2 device, and is asserted so long as that connection exists. If the connection to the remote modem is lost, the modem may indicate the loss of connection to the TE2 device by deasserting the DCD pin, setting the voltage on the DCD pin low. So long as the DCD pin is asserted, the networking software maintains the state of the PPP session. [0018] The networking software is typically configured to tear down the PPP session if the DCD pin is no longer asserted, indicating that the connection to the remote server is lost. TE2 device and networking software may control the behavior of the modem with respect to the DCD pin via the AT&C commands of the AT command set. The AT&C1 command instructs the modem to indicate the loss of connection to the TE2 device by setting the DCD pin low. According to IS-707, setting the &C value to 1 means that the status of the DCD pin should follow the status of the traffic channel, i.e., the DCD pin is down when the channel is down, and up when the channel is up. The AT&C or AT&C0 command instruct the modem to always assert the DCD pin at a high level. [0019] Generally, for connection to the Internet via a wireless telecommunications system as contemplated in this disclosure, an MT2 device is coupled to the TE2 device. As will be described, the MT2 device connects the TE2 device to an interworking function (IWF) or packet data serving node (PDSN), which are part of the wireless telecommunications system infrastructure, via a base station. The TE2 may then negotiate and establish a PPP session with the IWF or PDSN and transmit and receive data packets as described above with respect to the remote server. [0020] An MT2 device may be programmed to emulate a modem in that it receives and responds to AT commands and provides the feedback to the TE2 device that it would expect to receive from a modem. This programming allows the TE2 to be connected to the Internet by dial-up or wirelessly using the same networking software. For example, the MT2 use a DCD pin, which is part of the connection between the MT2 device and the TE2 device, to indicate the status of the connection to the base station. [0021] In order to conserve the capacity of the over-the-air communication channel utilized by the MT2 device, either the MT2 device or the base station may release the connection between them during periods where no data packets are being exchanged. This feature is often referred to as packet dormancy. The MT2 device may also temporarily lose the connection due to signal fade or a hard handoff, or when a voice call is initiated. If the MT2 device indicates the loss of the connection to the TE2 device each time such a loss occurs, e.g., in response to an AT&Cl value of 1, the TE2 device may be caused to repeatedly tear down and reestablish the PPP session. This process is very inefficient in its use of system resources as it consumes airtime. In addition the airtime may be billed to the user, and this process may result in data transmission delays which will likely be noticed by the user, diminishing the user experience. [0022] If the MT2 device is instructed to always assert the DCD pin, by an AT&C or AT&C0 command, for example, the TE2 device and the user may not be aware that a session-ending event has occurred. A session-ending event is an event whose occurrence indicates that connection is not needed or will not be available. For example, traveling outside of the data service coverage area is a session-ending event. In accordance with this disclosure, the MT2 device can be configured to selectively assert and deassert the DCD pin to prevent the TE2 device from tearing down a communication session even though connection with a remote server via an over-the-air communication channel has been temporarily lost.

[0023] FIG. 1 is a block diagram illustrating an exemplary wireless communication system 10. System 10 may include one or more wireless communication devices 12 (MT2 devices) for connection of one or more data terminals 14 (TE2 devices) to a network such as the Internet 22. TE2s 14 may be personal computers, laptop computers, handheld computers, personal digital assistants (PDAs), fax machines, or the like. MT2s 12 may be cellular radiotelephones, satellite radiotelephones, a PCMCIA card or wireless modem incorporated within a TE2 14, a PDA equipped with wireless communication capabilities, or the like. MT2s 12 within system 10 may be configured to support one or more communication standards, including standards based on code division multiple access (CDMA) techniques, frequency division multiple addressing (FDMA) techniques, time division multiple addressing (TDMA) techniques, or the like. [0024] For example, one or more of MT2s 12 may be designed to support CDMA standards such as (1) the "TIA EIA-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System" (the IS-95 standard), (2) the "TIA/EIA-98-C Recommended Minimum Standard for Dual-Mode Wideband Spread Spectrum Cellular Mobile Station" (the IS-98 standard), (3) the standard offered by the "3rd Generation Partnership Project" (3GPP) and embodied in a set of documents including Document Nos. 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, and 3G TS 25.214 (the W-CDMA standard), (4) the standard offered by the "3rd Generation Partnership Project 2" (3GPP2) and embodied in a set of documents including "TR-45.5 Physical Layer Standard for cdma2000 Spread Spectrum Systems," the "C.S0005-A Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems," and the "C.S0024 CDMA2000 High Rate Packet Data Air Interface Specification" (the CDMA2000 standard), (5) the HDR system documented in TIA/EIA- IS-856, "CDMA2000 High Rate Packet Data Air Interface Specification", or other standards. In addition, MT2s 12 may be designed to support other standards, such as the GSM standard or related standards, e.g., the DCS1800 and PCS1900 standards. GSM systems employ a combination of FDMA and TDMA modulation techniques. MT2s 12 may also support other FDMA and TDMA standards.

[0025] Base station/mobile switching station (BS/MSC) 16 may, as depicted in FIG. 1, provide a wireless connection for MT2s 12 to connect to the infrastructure of wireless communication system 10. As is known in the art, BS/MSC 16 may include a base station transceiver (BTS) (not shown), which may include radio transmitter and receiver circuitry, and with which the MT2s 12 are wirelessly connected, a base station controller (BSC) (not shown), which may be coupled to and control the operation of a number of BTSs, and a mobile switching center (MSC) (not shown) that routes calls to and from BSCs and forwards calls from BSCs to the public switched telephone network (PSTN) (not shown) or another MSC.

[0026] TE2s 14 may communicate with an interworking function (IWF) 18 or a packet data serving node (PDSN) 20 via MT2s 12 and BS/MSC 16 to support data communication. For wireless data communication, IWF 18 or PDSN 20 is a device and/or program that serves as an access point to one or more network resources. In particular, IWF 18 or PDSN 20 may serve as an access point to the Internet 22. IWF 18 or PDSN 20 may be coupled to, and often co-located with, BS/MSC 16. [0027] The operation of IWF 18 or PDSN 20 is well known in the art. In general, IWF 18 or PDSN 20 receives data packets framed according to a PPP from TE2s 14 via MT2s 12 and BS/MSC 16, and reframes the data packets for transmission to remote devices (not shown) via the Internet 22, e.g., according to the TCP/TP communication protocol. In the same manner, IWF 18 or PDSN 20 receives data packets via the Internet 22 and repackages them for transmission to TE2s 14 via the wireless network's modem interface. IWF 18 or PDSN 20 may also provide a buffer for data packets to compensate for differences between the rate of transmission across the wireless link and the rate of transmission across the links of the Internet 22.

[0028] PPP is a well-known protocol for providing remote access. PPP provides a standard method for transporting data packets serially between two end-point peers. PPP includes a method of framing data packets for transmission at one end of the PPP link, and receiving the data packet and removing the framing on the other end of the PPP link. [0029] FIG. 2 is a block diagram illustrating a connection between TE2 14 and IWF 18 or PDSN 20 via a MT2 12 and BS/MSC 16. TIA/EIA IS-707.5, entitled "DATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES," published February 1998, defines requirements for support of packet data transmission capability on TIA/EIA IS-95 and IS-2000 wideband spread spectrum systems. IS-707.5 also provides the requirements for communication protocols on the links between TE2 14 and MT2 12, between MT2 12 and BS/MSC 16, and between BS/MSC 16 and IWF 18 or PDSN 20.

[0030] As indicated in FIG. 2, the link between TE2 14 and MT2 12 is known in the art and referred to in the IS-707.5 standard as the R_m interface. Similarly, the link between MT2 12 and BS/MSC 16 is known and referred to as the U_m interface, and the link between BS/MSC 16 and IWF 18 or PDSN 20 is known and referred to as the L or A interfaces, respectively. The R_m link may take the form of an RS-232, universal serial bus (USB), Bluetooth, Infrared Data Association (IrDA) link or like interface. The U_m air interface may conform to IS-95 or CDMA-2000. The L or A interfaces may conform to IS-95 or TIA-2001-B, respectively.

[0031] Consistent with IS-707.5, TE2 14 may establish a PPP session with IWF 18 or PDSN 20, which will allow TE2 14 to deliver data packets to and receive data packets from the Internet 22. TE2 14 may establish a PPP session with IWF 18 or PDSN 20 by exchanging configuration packets with MT2 12, which in turn exchanges configuration packets with IWF 18 or PDSN 20. The configuration packets are exchanged to configure protocol modules, such as link-layer PPP modules and network layer IP modules, operating within TE2 14, MT2 12 and IWF 18 or PDSN 20. When the R_m and U_m interface negotiations are completed for MT2 12, data packets may be transmitted between TE2 14 and IWF 18 or PDSN 20 via the R_m, U_m and IJA interfaces. [0032] The PPP session is generally established after TE2 14 receives an indication from MT2 12 that a wireless connection to BS/MSC 16 has been acquired. TIA/EIA IS-707.4, entitled "DATA SERNICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: ASYNC DATA AND FAX SERVICES," published March 1999, provides that MT2 12 may be programmed to emulate a modem in that it receives AT commands from TE2 14 over the R_m interface, responds to the AT commands, and provides the feedback to TE2 14 over the R_m interface that it would expect to receive from a modem. The AT command set is well-known in the art, and is defined by the use of the ASCII prefix "AT," in either lower or upper case, followed by any one of a set of other predefined codes. [0033] For example, MT2 12 may receive a dial command, ATD, from TE2 14 over the R_m interface. In response to the dial command, MT2 12 may connect to BS/MSC 16 and provide one or more indications of the connection to TE2 14. In order to indicate the connection, MT2 12 may return a "CONNECT" code via the R_m interface to TE2, and/or may assert a DCD pin (not shown) as described in greater detail below. The indication notifies TE2 14 that the physical layer of the U_m and L interfaces (in an IS-95 network) have been and established, and that it may begin negotiating the other protocol layers of the PPP session. TE2 14 may transmit data packets during an established PPP session. Packets received from the Internet 22 and delivered by rWF 18 or PDSN 20 may follow the reverse path to TE2 14.

[0034] FIG. 3 is a block diagram illustrating an exemplary MT2 12 coupled to a TE2 14. MT2 12 may include a processor 30 that generally controls its operation. Processor 30 may process AT commands and packets received from TE2 14 and IWF 18 or PDSN 20. Processor 30 may, for example, be implemented as a microprocessor. Processor 30 may execute instructions stored in memory 32, which may comprise any computer-readable medium suitable for storing instructions, including random access memory (RAM), readonly memory (ROM) non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, or any other medium that can be used to store the desired information and that can be accessed by processor 30.

[0035] In the embodiment of MT2 12 depicted in FIG. 3, processor 30 is coupled to a transceiver 34. Processor 30 establishes a wireless connection and communicates with BS/MSC 16 via transceiver 34. Transceiver 34 receives digital signals from processor 30, and converts the signals to RF signals for transmission to BS/MSC 16 via the wireless connection. Similarly, transceiver 34 receives RF signals from BS/MSC 16 via the wireless connection and converts the RF signals to digital signals before delivering them to processor 30. The signals may, for example, include paging messages, configuration packets, or data packets.

[0036] The processing of signals and transmission of signals via the wireless connection may be done at both MT2 12 and BS MSC 16 in accordance with the Radio Link Protocol (RLP) and the IS-95 or IS-2000 protocol, which are physical layer protocols for the U_m interface specified by IS-707.5.

[0037] MT2 12 may also include a user interface 36. User interface 36 may be used by a user to place circuit-switched voice calls. User interface 36 may include a speaker, a display and a keypad used to dial telephone numbers.

[0038] TE2 14 may, as depicted in FIG. 3, include a processor 42. Processor 42 may execute instructions stored in memory 44. The instructions may include a serial networking application software package. The networking application may cause processor 42 to send AT modem commands to MT2 12, and may be responsive to feedback received from MT2 12. The networking application may also cause processor 42 to establish a PPP session with IWF 18 or PDSN 20 via MT2 12, as described above. Further, the networking application may cause processor 42 to exchange data packets with IWF 18 or PDSN 20 via MT2 12 and BS/MSC 16, as described above. A user may interact with the networking software and other applications stored in memory 44 to control the operation of processor 42 via user interface 46. User interface 46 may include any of a display, keyboard, and pointing device such as a mouse.

[0039] In the example depicted in FIG. 3, MT2 12 is coupled to TE2 14 via data ports 38, 40 and data link 48. Specifically, processor 30 is coupled to a processor 42 of TE2 14 via data ports 38, 40 and data link 48. In some embodiments, packets transmitted between MT2 12 and TE2 14 may be transmitted serially. For example, data ports 38, 40 and data link 52 may be EIA-232 compatible, and MT2 and TE2 may transmit packets according to the EIA-232 protocol, which is a physical layer protocol for the R_m interface specified by IS-707.5.

[0040] Data port 38 of MT2 12 may, for example, be a serial data port. Data port 40 of TE2 14 may, for example, be a serial data port, universal serial bus (USB) port, or a PCMCIA slot. Data link 48 may be a cable with appropriate connectors, or an appropriate connector and a PCMCIA card. Alternatively, the components of MT2 12 may be housed in a PCMCIA card, which may then be inserted in a PCMCIA slot data port 40 of TE2 14. This alternative configuration would eliminate the need for data link 48.

[0041] As mentioned above, MT2 12 may emulate a modem by providing an indication of a connection with BS/MSC 16 to TE2 14. In particular, this indication may be provided via a data carrier detect (DCD) pin (not shown), which may be a part of data port 38 and connected through data link 48 to a corresponding pin (not shown) of data port 40.

[0042] The DCD pin may, at any given time, be in one of two states, corresponding to first and second voltage levels applied to the pin, i.e., high or low. Processor 30 may assert the DCD pin by applying a voltage at a first level to the pin, e.g., setting the pin high. Processor 30 may deassert the DCD pin applying voltage at a second level to the pin, e.g., resetting the pin low. In other words, processor 30 may deassert the DCD pin by returning the pin to the voltage level at the pin prior to assertion. [0043] Processor 30 may assert the DCD pin when a wireless connection with BS/MSC 16 has been established. Assertion of the DCD pin is used to indicate to TE2 14 that the connection, or data channel, has been established and that TE2 14 may begin negotiating a PPP session with MT2 12 and IWF 18 or PDSN 20. The DCD pin will remain asserted so long as the connection between MT2 12 and BS/MSC 16 exists, indicating to TE2 14 that it may still transmit and receive data packets. If processor 30 deasserts the DCD pin, the deassertion will indicate to TE2 14 that the connection is lost, at which point TE2 14 typically tears down, i.e., terminates, the PPP session.

[0044] TE2 14 may control the operation of MT2 12 with respect to the DCD pin via AT commands. MT2 12 may, for example, receive an AT&Cl command from TE2 14. The AT&Cl command instructs MT2 12 to assert the DCD pin while there is a connection with BS/MSC 16. An AT&C or AT&CO command instructs MT2 12 to assert the DCD pin at all times.

[0045] In order to conserve the capacity of the over-the-air communication channel utilized by the MT2 12, either the MT2 12 or BS/MSC 16 may release the connection between them during periods where no packets are being exchanged by TE2 14 and IWF 18 or PDSN 20. This feature is often referred to as packet dormancy. For example, MT2 and/or BS/MSC 16 may maintain a timer that counts down from a predetermined value each time a packet is received or transmitted. If such a timer maintained by BS/MSC 16 expires, BS/MSC 16 will send a message to MT2 12 indicating that it will release the connection, and will then release the connection. If such a timer maintained by MT2 12 expires, MT2 12 will send a release message to BS/MSC 16, which will then release the connection. The MT2 device may also temporarily lose the connection due to signal fade, or due to a hard handoff, which may occur when MT2 12 travels outside of the coverage area of the BS/MSC 16 with which the connection was established. [0046] Release of the connection due to packet dormancy, loss of the connection due to fade, and loss of the connection due to a hard handoff are not necessarily session-ending events. In fact, when these non-session-ending events occur, it is generally the case that a connection via the over-the-air channel will be available shortly or when needed. At most, MT2 12 will have to reconnect to BS MSC 16 and renegotiate the U_m interface protocol. Session-ending events, on the other hand, are events indicating that connection is not needed or will not be available. For example, traveling outside of the data service coverage area, i.e., into an area in which data service is not supported, or terminating the dial-up networking session on the TE2, are session-ending events. [0047] If the processor 30 deasserts the DCD pin every time a loss of the connection occurs, e.g., in response to an AT&Cl command, TE2 14 may be caused to repeatedly tear down the PPP session, reestablish the PPP session, and require the renegotiation of at least the R_m interface. This process may consume airtime that is billed to the user, and cause data transmission delays that are visible to the user, and defeats the purpose of packet dormancy. In addition, the repeated teardown and reestablishment of the PPP session can produce undesirable processing overhead within MT2 12, TE2 14, and BS/MSC 16, and excessive power consumption. If the processor 30 in MT2 12 is instructed to always assert the DCD pin regardless of channel state, e.g., by an AT&C or AT&CO command, TE2 14 and the user may not be aware that a legitimate session- ending event, such as traveling outside of the data service coverage area, has occurred. [0048] FIG. 4 is a flowchart illustrating a method for selectively indicating the status of a connection between MT2 12 and BS/MSC 16 to TE2 14, e.g., via selective assertion and deassertion of the carrier detect pin. In general, an MT2 12 employing the illustrated method will continue to indicate the existence of the connection with BS/MSC 16 to TE2 14, despite the temporary release or loss of the over-the-air channel connection, unless a true session-ending event has occurred. The method illustrated in FIG. 4 may advantageously support packet dormancy by avoiding needless PPP session teardown and reestablishment cycles in the TE2 14. The method illustrated by FIG. 4 may thus conserve airtime and decrease data transmission delays, and reduce undesirable processing overhead and power consumption, decreasing the cost of the wireless data session for the user and improving quality of service.

[0049] As illustrated by FIG. 4, MT2 12 may receive a dial command, such as an ATD command, over the R_m interface from TE2 14 (50).. In particular, processor 30 of MT2 12 may receive the dial command via data ports 38, 40 and data link 48. Processor 30 may also receive other AT commands from TE2 14, such as an AT&C command, at this time. [0050] In response to the received dial command, processor 30 may establish a connection with BS/MSC 16 via transceiver 34 (52). Processor 30 may establish the connection with BS/MSC 16 by sending origination messages to BS/MSC 16 via transceiver 34. These origination messages may indicate to BS/MSC 16 that a data call is requested and that a connection to IWF 28 or PDSN 20 is needed. [0051] After establishing the connection with BS/MSC 16, processor 30 may provide TE2 14 with an indication that the connection has been established (54). Processor 30 may indicate that the connection has been established by asserting a DCD pin which may be a part of data port 38 and connected through data link 48 to a corresponding pin (not shown) of data port 40 of TE2 14. Processor 30 may assert the DCD pin by applying a voltage at a first level to the pin. Processor 30 asserts the DCD pin, i.e., maintains the DCD pin at the first voltage level, until it determines that a session-ending event has occurred as described below.

[0052] The assertion of the DCD pin by processor 30 may indicate to TE2 14 that it may begin negotiating a PPP session with MT2 12 and IWF 18 or PDSN 20 as described above. When TE2 14, MT2 12 and IWF 18 or PDSN 20 successfully complete the negotiations, a PPP session between TE2 14 and IWF 18 or PDSN 20 has been established (56). TE2 14 and IWF 18 or PDSN 20 may then exchange data packets via MT2 12 using the PPP protocol as described above (58).

[0053] If, at some point, processor 30 determines that the connection to BS/MSC 16 is lost or released (60), processor 30 will continue to assert the DCD pin unless and until processor 30 determines that a session-ending event has occurred (62). Again, session- ending events are events indicating that connection is not needed or will not be available. A session-ending event may be receipt of a session termination request from TE2 14, IWF 18, or PDSN 20, receipt of an indication from TE2 14 that it is no longer ready to transmit or receive data, receipt of a session-ending AT command from TE2 14, detection of an attempt by a user to dial a voice call via MT2 12, inability to reconnect to BS/MSC 16 and reestablish the data session. If a session-ending event has not caused the loss of the connection, or does not occur while the connection is lost, processor 30 will reconnect to BS/MSC 16, reestablish the data session (63) and continue to transmit data packets between TE2 14 and IWF 18 or PDSN 20 (58). If a session-ending event has occurred, processor 30 will deassert the DCD pin (64), and TE2 will tear down the PPP session (66).

[0054] FIG. 5 is a flow chart further illustrating the method illustrated in FIG. 4. In particular, FIG. 5 illustrates an exemplary method of determining whether a session- ending event has occurred (62), and identifies a number of possible session-ending events. Processor 30 of MT2 12 may make this determination after identifying a loss or release of a connection to BS/MSC 16 (60), and may continue to determine whether a session-ending event has occurred during a period where the connection is released. [0055] For example, processor 30 may initially determine whether it received a PPP termination request from TE2 14, IWF 18 or PDSN 20 before the connection was lost, or detect a PPP termination request received from TE2 14 after the connection was lost (70). Receipt of a PPP termination request indicates to processor 30 either that IWF 18 or PDSN 20 will no longer be available for packet data services, or that TE2 14 no longer needs packet data services. Thus, receipt of a PPP termination request is treated as a session-ending event. If processor 30 determines that it has received a PPP termination request, it may indicate the loss of the connection with BS/MSC 16 to TE2 14 by, for example, deasserting the DCD pin (64). [0056] Processor 30 may also determine whether it continues to receive an indication from TE2 14 that it is ready to transmit and receive data (72). TE2 14 may, as is done when it is connected to a modem, assert a data terminal ready (DTR) pin when it is ready to transmit and receive data. The DTR pin may be located within data port 40, and may be coupled to data port 38 via data link 48. Processor 30 may interpret deassertion of the DTR pin by TE2 14 as an indication that TE2 14 no longer needs packet data services. Thus, in some embodiments, deassertion of the DTR pin may be interpreted as a session- ending event. If processor 30 detects a deassertion of the DTR pin by TE2 14, it may indicate the loss of the connection with BS/MSC 16 by deasserting the DCD pin (64). [0057] Processor 30 may also determine whether it has received a session-ending AT command from TE2 14 (74). For example, processor 30 may receive the hang-up command, ATH, from TE2 14. Processor 30 may interpret the receipt of an ATH command as an indication of that TE2 14 no longer needs packet data services. Thus, receipt of an ATH command is a session-ending event. If processor 30 receives an ATH, command from TE2 14, processor 30 may indicate the loss of the connection with BS/MSC 16 by deasserting the DCD pin (64).

[0058] Processor 30 may also determine whether the user is attempting to originate a voice call using MT2 12 (76). Processor 30 may make this determination based on signals received from user interface 36. Processor 30 may interpret such an attempt as an indication that the user, and thus TE2 14, no longer needs packet data services. Thus, an attempt to originate a voice call can be interpreted as a session-ending event. If processor 30 detects an attempt to place a voice call, processor 30 may indicate the loss of the connection with BS/MSC 16 by deasserting the DCD pin (64). As an alternative, however, processor 30 may be programmed to continue assertion of the DCD pin during a voice call, enabling a user to make voice calls during the course of a packet data call via packet dormancy.

[0059] In some circumstances, processor 30 will be aware that the loss of the connection was caused by a release due to packet dormancy. Processor 30 may determine whether the loss of the connection was due to packet dormancy by determining whether a timer maintained by it expired or whether it received a release message from BS/MSC 16 (78). Losses not due to packet dormancy may, for example, be caused by signal fade or a hard handoff, which ordinarily are temporary and subject to restoration shortly after the channel loss. [0060] If the loss was not due to packet dormancy, processor 30 may, after having determined that the above-described session-ending events had not already occurred, attempt to reconnect to BS/MSC 16 and reestablish the packet data call (80). Processor 30 may attempt to reconnect/reoriginate by sending origination messages to BS/MSC 16. The origination messages may indicate the need for a connection with BS/MSC 16, and the need for a connection with IWF 18 or PDSN 20 for packet data services. [0061] If the reconnection is successful, processor 30 may renegotiate the U_m interface protocols and begin to transmit data packets between TE2 14 and IWF 18 or PDSN 20 (58). Processor 30 may buffer data packets received from TE2 14 during the period that the connection was unavailable in memory 32. IWF 18 or PDSN 20 may also buffer data packets during the period when the connection is lost for later delivery to TE2 14. Both processor 30 and IWF 18 or PDSN 20 may have stored information about the configuration of the U_m interface in memory.

[0062] The reconnection may not be successful. For example, processor 30 may not successfully reconnect to BS/MSC 16 after a predetermined number of attempts. This inability to reconnect to BS/MSC 16 may, for example, be caused by traffic on the air channel or traveling outside of the coverage area. Processor 30 may also determine that it is unable to reestablish the packet data call. Processor 30 may, for example, receive a message from BS/MSC 16 indicating that data service is not available. This message might be received because MT2 12 has been handed off to a BS/MSC 16 that does not support packet or data service, or because IWF 18 or PDSN 20 does not currently have the capacity to handle the call.

[0063] Processor 30 may interpret this inability to reconnect as an indication that the packet data services are no longer available. Thus, the inability to reconnect could be defined as a session-ending event. If processor 30 is unable to reconnect to BS/MSC 16, processor 30 may indicate the loss of the connection with BS/MSC 16 by deasserting the DCD pin (64).

[0064] If processor 30 determines that the loss of the connection was due to packet dormancy, processor 30 may wait to attempt to reconnect to BS/MSC 16 until it receives a data packet from TE2 14 (82). Processor 30 will continue to determine whether a session-ending event has occurred (70-76) during the period of packet dormancy until a data packet is received. When a data packet is received, processor 30 will attempt to reconnect to BS/MSC 16 as described above.

Claims

CLAIMS:

1. A method comprising: identifying a loss of a wireless connection between a wireless communication device and a base station; and indicating to a data terminal coupled to the wireless communication device that the wireless connection exists following the loss of the wireless connection.

2. The method of claim 1, wherein the loss of the wireless connection includes a release of the wireless connection by the wireless communication device.

3. The method of claim 1 , further comprising continuing to indicate to the data terminal that the wireless connection exists unless a session-ending event has occurred.

4. The method of claim 3, wherein indicating that the connection exists comprises applying a first voltage to a data carrier detect pin, and indicating the loss of the wireless comprises applying a second voltage to the data carrier detect pin.

5. The method of claim 3, further comprising: determining that the session-ending event has occurred; and indicating the loss to the data terminal based on the determination.

6. The method of claim 5, wherein determining that the session-ending event has occurred comprises receiving a session termination request from the data terminal requesting termination of a communication session over the wireless connection.

7. The method of claim 5, wherein determining that the session-ending event has occurred comprises receiving a session termination request from a remote. server requesting termination of a communication session with the wireless communication device over the wireless connection.

8. The method of claim 5, wherein determining that the session-ending event has occurred comprises receiving an indication that the data terminal is not ready to transmit and receive data.

9. The method of claim 5, wherein determining that the session-ending event has occurred comprises receiving a session-ending AT command from the data terminal.

10. The method of claim 5, wherein determining that the session-ending event has occurred comprises determining that a circuit-switched call is being initiated by a user via the wireless communication device.

11. The method of claim 5, wherein determining that the session-ending event has occurred comprises: attempting to reconnect to the base station upon loss of the wireless connection; and identifying an inability to reconnect.

12. The method of claim 11, wherein identifying the inability to reconnect comprises receiving an indication that data service is unavailable.

13. A wireless communication device for performing the method of any of claims 1- 12, the device comprising: a transceiver to provide a wireless connection with a base station; a data port to couple the wireless communication device to a data terminal; and a processor to identify the loss of the wireless connection with the base station and continue to indicate to the data terminal that the wireless connection exists following the loss of the wireless connection.

14. A computer-readable medium comprising instructions that cause a processor to perform the method of any of claims 1-12.

15. A wireless communication device for performing the method of any of claims 1- 12, the device comprising: means for identifying the loss of a wireless connection between the wireless communication device and a base station; and means for continuing to indicate to a data terminal coupled to the wireless communication device that the wireless connection exists following the loss of the wireless connection.