WO2002052874A2 - System and method for connection-oriented access to packet data networks for wireless devices - Google Patents

Abstract

A system and method of providing internet protocol (IP) data over mobile includes an enabler interposed between a base transceiver station and a base station controller in a communications network. The enabler may be connected to an IP network and may provide IP data transmission and reception to various non-IP capable devices and base station subsystems. The enabler may provide one or more of the following features and services: Maximum Battery Utilization (MBU), Remote Rendering Service (RRS), Switched Timeslot Enhanced Packet Service (STEPS), Always-On WAP (AOW), Slotted Aloha Timeslot Multiplexing (SATM), and existing GPRS, EDGE, and HSCSD services. The MBU power control system may extend the life and run-time of the batteries powering the devices that make use of one or more of the foregoing services. The inventive methods and system architecture require no modifications to the technology already employed by the existing Base Station Subsystems (BSS), Network Subsystems (NSS), Radio Frequency (RF) subsystem, or mobile station device.

Description

SYSTEM AND METHOD FOR DATA COMMUNICATION WITH LEGACY

DEVICES

BACKGROUND OF THE INVENTION

This application claims the benefit of U.S. Provisional Application No. 60/258,431 , filed December 27, 2000, entitled "SYSTEM AND METHOD OF DELIVERING DATA IN A TELECOMMUNICATIONS SYSTEM," the disclosure of which is hereby incorporated by reference in its entirety.

1. F id of the Invention

The present invention is related generally to telecommunication systems, and more particularly to a system and method of delivering Internet

Protocol (IP) data packets to IP enabled and to non-IP enabled Mobile

Stations (MS) a in communications networks. The invention also relates to a method of conserving power, battery usage, in MS.

2. Description of the Related Art As the Internet expands its offerings and its use becomes more ubiquitous, convenient access to Internet based services is becoming more important in the daily lives of MS users. The MS communicate with one another or with fixed stations through a variety of means and transmission arrangements. These means are well known to the person skilled in the art and include but are not limited to radio frequency (RF) transmissions in a plurality of spectra, infrared, laser, and others well known to the person skilled in the art. The transmission arrangements include, but are not limited to, cellular, satellite, MS to MS, wireless, and others well known to the person skilled in the art. The MS, used in these communications, have proliferated to include a plethora of artifacts including, as an example and not as an exhaustive list, telephones, pagers, laptop and desktop computers, electronic organizers, personal digital assistants (PDA), e-mail stations, internet appliances, wrist watches, combinations of the previous devices, and others well known to the person skilled in the art.

Due to increasing market penetration of cellular telephones and enabling new technologies, such as the Global System for Mobile (GSM) communications standard and Personal Communication Systems (PCS), the telecommunications industry is experiencing a great demand for transmission of data over mobile, i.e. Internet Protocol (IP), to mobile or wireless devices. The .delivery of IP data over mobile is presently only achievable through considerable investments directed toward replacing and extending the technological and hardware infrastructures forming the framework of wireless communications. Technical limitations, legal restraints, and economic conditions provide additional barriers to the development of an efficient and practical system for delivering data to mobile or wireless communication devices. In addition to GSM, Time Division Multiple Access (TDMA), and Code

Division Multiple Access (CDMA) technologies for wireless communications, recent standards such as High Speed Circuit Switched Data (HSCSD) and General Packet Radio System (GPRS) have been developed which accommodate the delivery of data over mobile. However, conventional GSM enabled devices are not capable of making use of many of the services available in HSCSD and GPRS.

SUMMARY OF THE INVENTION

The present invention overcomes the foregoing and other shortcomings of existing telecommunications systems by providing a system and method of delivering IP data over mobile without physically altering the existing receiving devices. An Enabler is an adapter that may be interposed between a switching station (Base Station Controller, or BSC) and a radio transmission station (Base Transceiver Station, or BTS). The Enabler may provide IP data to existing GSM enabled devices without requiring modification of the existing receiver's technology. The Enabler may deliver data over mobile for both Wireless Application Protocol (WAP) and non-WAP based devices, for GPRS devices, and for appliances, such as Personal Computers (PCs), that use a wireless device to connect to the Internet.

In operation, the Enabler may have a plug-in architecture that allows data transmission with the support of existing GSM services, such as voice and Short Message Service (SMS) calls.

The Enabler may be connected to an IP network, to provide full fledged, carrier grade, data transmission and reception to various MSs without intervention on the part of the Base Station Subsystem (BSS) or the Network Subsystem (NSS). In accordance with one aspect of the present invention, the Enabler may provide IP data to a non-IP data capable BSS, and further may provide, as example and without limitation, these services: Remote Rendering Service (RRS), Switched Timeslot Enhanced Packet Service (STEPS), Always-On WAP (AOW), GPRS, Enhanced Data for GSM Evolution (EDGE), and HSCSD services. RRS, STEPS, and AOW are discussed in detail below. Additionally, Enabler may further transparently enable any other services provided by the BSS. Services may be delivered advantageously with the quality and optimization parameters desired or demanded by the BSS.

Importantly, the inventive system architecture may provide the foregoing services while requiring no modifications to the technology already employed by the existing BSS, NSS, Radio Frequency (RF) subsystem, or MS. Additionally, the Enabler may transparently enable the transmission of other services originating in the GSM device. It will be appreciated that Location Service and Voice over IP (VoIP) may power the services mentioned above.

In accordance with another aspect of the present invention, the services mentioned above may be associated with a Maximum Battery Utilization (MBU) power control strategy, discussed in detail below. The MBU power control strategy may extend the life and run-time of the batteries powering the devices that make use of the foregoing services. The MBU strategy also has utility separate from its usage in the context of the above- mentioned services. The above-mentioned, and other advantages of the present invention, will become more apparent upon examination of the following detailed description of the preferred embodiments with reference to the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a simplified block diagram illustrating the basic architecture of one embodiment of a telecommunications system employing an Enabler for delivering data over mobile.

Figure 2 is a block diagram illustrating the system elements employed in one embodiment of an Enabler. Figure 3 is a flow diagram illustrating the operation of one embodiment of an Enabler during a mobile originated GSM call.

Figure 4 is a flow diagram illustrating the operation of one embodiment of Enabler during a mobile originated STEPS call.

Figure 5 is a flow diagram illustrating the operation of one embodiment of Enabler during a communications network (CN) originated STEPS call.

Figure 6 is a flow diagram representing one embodiment of a release operation beginning with a 'Disable STEPS' request initiated by a MS, wherein the timer has not yet expired.

Figure 7 is a flow diagram illustrating the operation of one embodiment of Enabler during a MS originating GPRS call.

Figure 8 is a flow diagram illustrating the operation of one embodiment of Enabler during a MS terminating GPRS call.

Figure 9 is a simplified graph of data packets transmitted versus time during a typical CN connection. Figure 10 is a graphical representation of the problem overcome by one embodiment of a CN-based MBU system.

Figure 11 is a simplified block diagram illustrating one embodiment of a system architecture supporting RRS.

Figure 12 is a simplified block diagram illustrating the operation of one embodiment of RRS. Figure 13 is a simplified diagrammatic view of one embodiment of a timeslot multiplexing strategy.

Figure 14 is a flow diagram illustrating the interface operation between the Service Layer (SL) and Interception Process (XP) and between the SL and the AOW Daemon Manager.

Figure 15 is a flow diagram illustrating the interface operation between the XP and AOW Subscriber Process via Radio Link Protocol.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Figure 1 is a simplified block diagram illustrating the basic architecture of one embodiment of a telecommunications system employing Enabler 100 for delivering data over mobile. In the exemplary embodiment, a Base Transceiver Station (BTS) 104 may be in communication with, and may be controlled by, a Base Station Controller (BSC) 106, which in turn may communicate with a Mobile Station Controller (MSC) 108 controlling operation of a MS 120. It will be appreciated that BTS 104, BSC 106, and MSC 108 are known in the art. Importantly, the inventive system described herein requires no modification of the existing hardware. As such, the Enabler 100 is an addon feature to existing communication networks. Consequently, its incorporation into those existing communication networks can be effected without disruption of existing services.

Various wireless devices controlled by MSC 108 are also known in the art. In particular, the wireless or mobile device may be a GSM or a CDMA wireless telephone, a PCS wireless telephone, another type of wireless device operating on a previously mentioned or different telecommunications standard or data protocol, and the like. It is within the scope and contemplation of the present invention to provide data over mobile for the various existing protocols and standards employed by a given MSC 108. Additionally, the system architecture is easily adaptable to other standards and protocols that may be developed or accepted by the telecommunications industry. As illustrated in Figure 1 , Enabler 100 may be interposed between BTS 104 and BSC 106 to provide an interface with a Server 102, which may further be connected to a Network 110, such as the Internet, for example, or a Local Area Network (LAN), a Wide Area Network (WAN), a Virtual Private Network (VPN), and the like. Server 102 may provide for data transmission between Network 110 and Enabler 100, which in turn may enable enhanced data over mobile services as described below.

Figure 2 is a block diagram illustrating the system elements employed in one embodiment of Enabler 100. The general operation of the system elements will now be described with reference to both Figures 1 and 2. In connection with this description, it should be noted that the system elements to be described might be implemented in hardware, software, or a combination of the two.

An Ingress Protocol Termination Module (IPTM) 202 may break up messages received from BSC 106, generally corresponding to BSC 106 in Figure 1. After analyzing a data pattern in the message stream, IPTM 202 may ignore voice data, transparently passing voice data to Egress Protocol Termination Module (EPTM) 206, and may send relevant information through a Local Subscriber Probe Unit (LSPU) 240 for retention in one or more databases 242-248, as will be described in greater detail below. As indicated in Figure 2, IPTM 202 may be capable of managing multiple IPTM Control Units (ICUs) 204.

As noted above, EPTM 206 may receive voice data from IPTM 202 transparently. In addition, EPTM 206 may break up messages from BTS 104, generally corresponding to BTS 104 in Figure 1 ; that is, after analyzing a data pattern in the message stream, EPTM 206 may likewise ignore voice data (transparently passing voice data to IPTM 202), and send relevant information through LSPU 240 for retention in the database(s) 242-248. In this manner, the system may identify voice data and efficiently ignore voice data streams. Further, EPTM 206 may be capable of managing multiple EPTM Control Units (ECUs) 208. Each IPTM Control Unit (ICU) 204 may provide an interface between

IPTM 202 and BSC 106. Primary functions of each ICU 204 may involve establishment and termination of the connection with BSC 106 when required; additionally, ICU 204 may further be responsible for collecting data pertaining to a particular BTS 104.

Similarly, each EPTM Control Unit (ECU) 208 may provide an interface between EPTM 206 and BTS 104. Primary functions of each ECU 208 may involve establishment and termination of the connection with BTS 104 and collection of data pertaining to a particular BSC 106. An Auxiliary Call Processing module (ACP) 226 may analyze information provided by IPTM 202 and EPTM 206 to determine the standard and protocol required by the communication, i.e., whether a particular call is GPRS, GSM, STEPS, or the like. In operation, ACP 226 may query LSPU 240 for user information, select a protocol handling, and interface module accordingly, as described below.

A Data Switching Interface Board (DSIB) 262, shown in the lower left portion of Figure 2, may provide for data buffering and may establish any required Quality of Service (QoS) connection. A Network 110, generally corresponding to Network 110 in Figure 1 , may be accessed by the system through DSIB 262; in this respect, DSIB 262 may provide for the connection, represented by the two-way dashed arrow in Figure 1 , between Enabler 100 and Server 102.

A Special Grouping Interface (SGI) 222 may provide communication between the Enabler 100 and an External Data Interface (EDI) 260 through GPRS protocols. Additionally, SGI 222 may provide an interface to EPTM 206 using GSM protocols, thereby enabling a translation from one standard to another (for example, from GSM to GPRS, or vice versa). Further, SGI 222 may query LSPU 240 for timeslot information so as to determine the proper timeslot for transmission of STEPS data; for example, SGI 222 may move STEPS data to an alternative timeslot if any other user has been allocated the first slot for a voice call. SGI 222 may, additionally or alternatively, suspend

STEPS data transfer when interrupted by a voice call from the Network 110. An Aggregation Grouping Interface (AGI) 224 may provide communication between Enabler 100 and EDI 260 through GPRS protocols.

Additionally, AGI 224 may provide an interface to EPTM 206 using GPRS protocols and perform certain GPRS functions. AGI 224 may query LSPU 240 for timeslot information in the same manner as SGI 222 discussed above.

In accordance with the respective protocols handled by SGI 222 and

AGI 224, efficient operation of ACP 226 may involve selecting AGI 224 for protocol handling with respect to GPRS, and selecting SGI 222 for protocol handling with respect to STEPS. A Local Subscriber Probe Unit (LSPU) 240 may manage four databases, which may be independent: a Probed Home Location Register

(PHLR) 242, a Probed Visitor Location Register (PVLR) 244, a proprietary

Enabler database (EDB) 246, and a Probed Network Management System database (PNMS) 248. In operation, LSPU 240 may interface to query PHLR 242 and PVLR 244, and may collect log information from IPTM 202, EPTM

206, ACP 226, AGI 224, SGI 222, and Operation and Maintenance module

(O&M) 280 (discussed below).

A Radio Trunk Exchange Board - Ingress (RTxBI) 228 may connect to

IPTM 202 for the purpose of formatting and inserting data into appropriate timeslots. Similarly, a Radio Trunk Exchange Board - Egress (RTxBE) 230 may connect to EPTM 206 and extract data from timeslots for appropriate formatting.

A Routing & Auxiliary Board Interface (RABI) 210 may control all routing between the various boards or modules connected to the Central Switching Element (CSE) 220. As shown in Figure 2, RABI 210 may be connected to a Board Routing Database (BRDB) 212, which contains relevant data records for routing and switching purposes.

The foregoing CSE 220 may be, as an example and without limitation, an Asynchronous Transfer Mode (ATM) switch and may serve to connect all of the foregoing boards or modules. As noted briefly above, EDI 260 is designed to connect Enabler 100 to a Serving GPRS Service Node (SGSN), such as Network 110, through DSIB 262. Enabling GPRS on a GSM network requires the addition of two core modules, the Gateway GPRS Service Node (GGSN) and the Serving GPRS Service Node (SGSN).

Turning now to the databases 242-248 illustrated on the left side of Figure 2, PHLR 242 may contain a subset of Home Location Register data records; these data may be updated based on additional information provided by IPTM 202, EPTM 206, and the respective control units, ICU 204 and ECU 208. Similarly, PVLR 244 may contain a subset of Visitor Location Register data records which may be updated based on additional information provided by IPTM 202, EPTM 206, and the respective control units, ICU 204 and ECU 208.

AH information specific to the operation and functionality of Enabler 100 may be contained in EDB 246, whereas all Network Management System (NMS) data collected by the various elements of Enabler 100 may be contained in data records maintained at PNMS 248. The above-mentioned O&M 280 may orchestrate operation and maintenance of the entire system. As indicated in Figure 2, for example, one embodiment of an O&M 280 may advantageously be connected to a Software Server (S/W) 282 to enable timely and efficient software upgrades for any of the other modules in the system. Additionally or alternatively, O&M 280 may be connected to a Data Server 284 to enable timely updating of any and all data maintained on any of the other modules or required for optimum performance or operability.

An Exception Controller (EC) (not shown) may advantageously be provided to connect BSC 106 with BTS 104 while bypassing Enabler 100; in this manner, a failure in any hardware component, subsystem, or software module employed by Enabler 100 may be bypassed completely such that, while certain services offered by Enabler 100 may be inoperative, the voice communication link will not be terminated prematurely.

It will be appreciated by those skilled in the art that the foregoing arrangement of Enabler 100 may significantly augment the functionality of

Server 102 while providing IP data services to non-data capable BSS.

Network operators employing Enabler 100 may consequently provide telecommunication services such as, for example and without limitation, 3G wireless communication in their migration path with a substantially low investment.

As noted earlier, it will be further appreciated by those skilled in the art that some or all of the foregoing components of Enabler 100 may be implemented in hardware, software, or a combination of the two.

Figure 3 is a flow diagram illustrating the operation of one embodiment of Enabler 100 during a mobile originated GSM call. At step 302, EPTM 206, having received a call from a given MS, makes a request to ACP 226 for setting up a GSM call. During the call set up, ACP 226 may check to determine what type of call is to be set up, for example and without limitation, whether a GSM call, a STEPS call, or a GPRS call. Then, in step 304, ACP 226 may pass the call request on to IPTM 202 such that voice is transmitted transparently. Additionally, as indicated at step 306, ACP 226 may also update LSPU 240 with the details of the call such that relevant data may be accessed from, and written to, the appropriate databases. At this stage, as indicated at step 308, an end-to-end connection is established for voice or data communication. During a call, control messages, data streams, and the like, may be monitored passively. When a MS originated call is to be terminated, either the MS, as in step

310, or the network, as in step 314, may initiate the termination by sending a control message to ACP 226. The connection break takes place in response to the control message requesting call release. Whether the termination call is originated by the MS, as in step 312, or by the network, as in step 316, ACP 226 may update LSPU 240 by providing any residual data concerning the call.

Figure 4 is a flow diagram illustrating the operation of one embodiment of Enabler 100 during a mobile originated STEPS call. At step 402, EPTM

206 may pass a STEPS enabled request to ACP 226 that in turn transmits a request to LSPU 240, at step 404, for enabling STEPS. As indicated at step 406, LSPU 240 may enable STEPS in a user profile and inform ACP 226. At step 408, ACP 226 may subsequently inform the MS initiating the call that the requested STEPS service is enabled. Subsequent to STEPS services being enabled, at step 410, the MS may request specific STEPS services, at which time ACP 226 may request authentication and timeslot information from LSPU 240, shown as step 412. LSPU 240 may then provide STEPS information at step 414, and ACP 226 may then inform SGI 222 of the STEPS service transmission, shown as step 416. Protocol transfer between SGI 222 and the MS is indicated at step 418, while protocol transfer between ACP 226 and EDI 260 is indicated at step 420.

Once the foregoing operations have been completed, SGI 222 may inform RTxBI 228 to begin inserting data into appropriate timeslots, at step 422; similarly, SGI 222 may inform RTxBE 230 to begin extracting data, at step 424. As indicated at step 426, at this point a connection between EPTM 206 and IPTM 202 is established for data communication.

At one point, SGI 222 may initiate a timer-reset operation. Steps 428 through 440 represent one embodiment of a release operation beginning with a 'Disable STEPS' request initiated by a MS wherein the timer has not yet expired. At step 428, the MS may inform ACP 226 of the request to release the call, at which point, step 430, ACP 226 logs in LSPU 240, that the STEPS call has been disabled and informs SGI 222 in step 432. Once the foregoing operations have been completed, SGI 222 may inform RTxBI 228 to stop inserting data into appropriate timeslots, at step 434; similarly, SGI 222 may inform RTxBE 230 to stop extracting data, at step 436. As indicated at step 438, SGI 222 may then apprise EDI 260 that the call is being terminated. Finally, at step 440, the MS may be informed by SGI 222 that the call is terminated.

Steps 442 and 444 depict one embodiment of a release operation beginning with a 'Disable STEPS' request initiated from a MS, wherein the timer has already expired. In this embodiment, at step 442, the MS may inform ACP 226 of the request to disable STEPS service; ACP 226 may then issue a request to LSPU 240, shown as step 444, in order to make changes in the user profile. Figure 5 is a flow diagram illustrating the operation of one embodiment of Enabler 100 during a communications network originated STEPS call. At step 502, a data packet may be transmitted from EDI 260 to ACP 222. ACP

222 in turn may query LSPU 240 at step 504 regarding user information maintained in databases PHLR 242, PVLR 244, EDB 246, and PNMS 248, relevant to the call. In step 506, LSPU 240 may respond to ACP 226 with user information extracted from one or more of the just-mentioned databases.

Subsequently, in step 508, ACP 226 may inform SGI 222 of the request to initiate protocol transfers. As indicated at step 510, SGI 222 may then query LSPU 240 regarding available and occupied timeslots; this data may be extracted from one or more of the before mentioned databases by

LSPU 240. LSPU 240 then may respond to SGI 222, at step 512, with appropriate timeslot information.

SGI 222 may then inform RTxBI 228 to begin inserting data into appropriate timeslots, as shown in step 514; similarly, SGI 222 may inform

RTxBE 230 to begin extracting data, as shown in step 516. Protocol transfer between SGI 222 and a MS, and protocol transfer between SGI 222 and EDI

260 are represented at steps 518 and 520 respectively.

As indicated at step 522, an end-to-end connectivity is established between EPTM 206 and EDI 260 for data transfer communications.

Figure 6, steps 602 through 614 represent one embodiment of a Enabler 100 release operation beginning with a 'Disable STEPS' request initiated by a MS, wherein the timer has not yet expired. By way of example only and without limitation, a MS may request that ACP 226 release the call and disable STEPS, shown as step 602, at which point ACP 226 logs in LSPU 240 that the STEPS call has been disabled, shown at step 604, and informs SGI 222, at step 606.

Once the foregoing operations have been completed, SGI 222 may inform RTxBI 228 to stop inserting data into appropriate timeslots, as shown in step 608; similarly, SGI 222 may inform RTxBE 230 to stop extracting data, at step 610. As indicated at step 612, SGI 222 may then apprise EDI 260 that the call is being terminated. Finally, at step 614, the MS may be informed by SGI 222 that the call is terminated.

Steps 616 and 618 represent one embodiment of a release operation beginning with a 'Disable STEPS' request initiated from a MS, wherein the timer has already expired. In this embodiment, at step 616, a MS, through EPTM 206, may inform SGI 222 of the request to disable STEPS service; SGI 222 may then issue a request to LSPU 240 in order to make changes in the user profile in one or more of the mentioned databases.

Figure 7 is a flow diagram illustrating the operation of one embodiment of Enabler 100 during a mobile originating GPRS call. At step 702, a MS may send a request to ACP 226 through EPTM 206 to establish a GPRS call. At step 704, ACP 226 may query LSPU 240, which may determine if the user is a STEPS or a GPRS user by extracting relevant data from one or more of the above mentioned databases. When the subscriber, or user profile data, has been extracted from the appropriate database, LSPU 240 may transmit extracted subscriber profile information to ACP 226, as shown in step 706; additionally, authentication information concerning the service requested by MS may be transmitted to ACP 226. As noted briefly above, ACP 226 preferably employs AGI 224 for protocol work with respect to GPRS calls; step 708 illustrates that ACP 226 may request that AGI 224 handle protocol operations for the duration of the GPRS call. At step 710, AGI 224 may query LSPU 240 for available and occupied timeslot information; LSPU 240 then may provide AGI 224 with the requested timeslot information, as shown in step 712. As indicated at step 714, AGI 224 may then pass on the necessary information to EPTM 206 for protocol establishment with a MS; additionally, AGI 224 may pass on the necessary information to EDI 260 for protocol establishment with a network, as shown in step 716.

Once the foregoing operations have been completed, AGI 224 may inform RTxBI 228, in step 718, to begin inserting data into appropriate timeslots; similarly, AGI 224 may inform RTxBE 230, step 720, to begin extracting data. As indicated at step 722, at this point an end-to-end connection between EPTM 206 and EDI 260 is established for data communication.

As in Figures 4 and 6, the release operation illustrated in Figure 7 may be initiated in two alternative ways. In the first scenario, depicted by steps 724 through 730, the termination request may originate at a MS; i.e. a MS sends a release message through EPTM 206 to AGI 224, as shown in step 724. Next, AGI 224 may transmit the message for call release to the network through EDI 260, as shown in step 726. Additionally, as indicated at step 728, AGI 224 may inform ACP 226 of the call release request. Finally, at step 730, AGI 224 may release the call and further update LSPU 240 with information related to the termination or release.

In the second scenario, depicted by steps 732 through 738, the termination request may originate at the network; i.e. the network may send a release message through EDI 260 to AGI 224, as shown in step 732. Next, in step 734, AGI 224 may inform the MS side of the termination request through EPTM 206. Additionally, as indicated at step 736, AGI 224 may update LSPU 240 to reflect the call release. Finally, as shown in step 738, in releasing the call in this particular embodiment, AGI 224 may transmit a request for call termination to ACP 226. Figure 8 is a flow diagram illustrating the operation of one embodiment of Enabler 100 during a mobile terminating GPRS call. At step 802, EDI 260 may send information to ACP 226 concerning an inbound call destined for a MS. Next, at step 804, ACP 226 may determine, through querying LSPU 240, whether the user, i.e. the MS, is a STEPS user or a GPRS user; LSPU 240 may query one or more of the previously mentioned databases to extract relevant user profile information. LSPU 240 may then return to ACP 226 subscriber profile information and authentication information related to the service requested for the MS, as shown in step 806.

As noted above, in the case of GPRS calls, ACP 226 may invoke the protocol handling functions of AGI 224; this invocation is represented at step

808. Next, in step 810, AGI 224 may query LSPU 240 for available and occupied timeslot information; LSPU 240 may query one or more of the previously mentioned databases for relevant information and return current timeslot information to AGI 224, as shown in step 812.

As illustrated at step 814, AGI 224 may then transmit information to EPTM 206 that is required for protocol establishment with a MS. Additionally, at step 816, AGI 224 may transmit information to EDI 260 that is required for protocol establishment with the network.

Once the foregoing operations have been completed, AGI 224 may pass timeslot information to RTxBI 228, in step 818, and to RTxBE 230, in step 820. AGI 224 may then inform RTxBI 228 to begin inserting data packets into appropriate timeslots; similarly, AGI 224 may inform RTxBE 230 to begin extracting data packets. As indicated at step 822, at this point an end-to-end connection is established between EPTM 206 and EDI 260 for GPRS data communication.

As in Figure 7, the release operation illustrated in Figure 8 may be initiated in two alternative ways.

In the first scenario, depicted by steps 824 through 830, the termination request may originate at a MS; i.e. the MS sends a release message through EPTM 206 to AGI 224, as shown in step 824. Next, in step 826, AGI 224 may transmit the message for call release to the network through EDI 260. Additionally, as indicated at step 828, AGI 224 may inform ACP 226 of the call release request. Finally, at step 830, AGI 224 may terminate or release the call and further update LSPU 240 with information related to the termination or release.

In the second scenario, depicted by steps 832 through 836, the termination request may originate at the network; i.e. the network may send a release message through EDI 260 to AGI 224, as shown in step 832. Next, in step 834, AGI 224 may inform the MS side of the termination request through EPTM 206. Additionally, as indicated at step 836, AGI 224 may update LSPU 240 to reflect the call release. As a final step in releasing the call in this embodiment, shown as step 838, AGI 224 may transmit a request for call termination to ACP 226. Maximum Battery Utilization (MBU)

With the introduction and subsequent increasing popularity of mobile communication through Global System for Mobile (GSM), there has been an escalating demand for mobile data capability in GSM enabled devices. Various technologies have been developed in an effort to satisfy this demand, for example and without limitation, General Packet Radio System (GPRS), Enhanced Data for GSM Evolution (EDGE), and Wireless Application Protocol (WAP), in addition to the herein disclosed and below discussed Remote Rendering Service (RRS), Switched Timeslot Enhanced Packet Service (STEPS), and Always-On WAP (AOW). Recently, mobile device users are coming to expect and to demand continuous data connectivity, including such connectivity through enhanced battery life.

In order to provide continuous connectivity, a MS, such as a conventional handset or wireless device, has to continuously monitor one or more assigned or predetermined communications network timeslots. Such monitoring has had to occur even at times when no data is transmitted between a network and the MS.

Those skilled in the art will appreciate, however, that continuous monitoring of single or multiple timeslots requires power consumption by a MS, leading to battery depletion even when the battery is not utilized for data transmission.

When a MS, or any network-enabled device, connects to a core network, such as an IP network, for example, data traffic generally flows in a predictable pattern of "request" and "response", or transmission and reception. By way of example and without limitation, a request may involve transmission of data packets to a mail Server through Post Office Protocol (POP3). In response, a POP3 Server may stream electronic mail data to the requesting device through continuous streams of IP data packets. Other protocols, such as Internet Message Access Protocol (IMAP), also are known to those skilled in the art. It will be appreciated that many user activities do not actually require data transmission. For example, when a user is browsing or reading a page on the World Wide Web, reading or drafting electronic mail, or engaging in other user-side activity, no connectivity or airtime is required, because the information being reviewed already has been downloaded to the user's device. In other words, unless a transaction between the user-side and the Server-side, requiring data transmission activity, takes place, there is no need to maintain the connection between a MS and the network. Examples of interactions which may require data transmission, include, but are not limited to, the user selecting a hyperlink, requesting access to electronic mail, or transmitting outgoing electronic mail.

On average, the time required for completion of these types of interactions, relative to the overall time a typical user remains connected to the network, is comparatively short. In other words, examination of typical IP traffic reveals that network connection time is not directly proportional to the packets transmitted and received. Of particular interest with respect to typical user behavior patterns, uplink traffic (data transmitted from the user to the network) is generally far less significant than downlink traffic (data transmitted from the network to the user). Figure 9 is a simplified graph of data packets transmitted versus time during a typical network connection. Figure 9 is provided by way of example only, and not by way of limitation. In the particular example shown in Figure 9, no data transfer is occurring from about seven minutes to about fourteen minutes after the connection is established, as shown in the center of the graph, and from about eighteen minutes to twenty minutes, as shown at the far right of the graph. During these idle times of zero data transfer activity, a user may be conducting other related or unrelated activities, such as reading downloaded electronic mail, drafting a response, or browsing the content of a web site. In accordance with one aspect of the present invention, a network- based MBU system may be provided as a stand alone service, independent of the communication system, or in combination with other services such as Remote Rendering Service (RRS), Switched Timeslot Enhanced Packet Service (STEPS), and Always-On WAP (AOW), for example.

While in operation, the MBU system may enable a MS to consume battery power only during data transmission or reception. When a MS is not actively engaged in such transmission or reception, battery power consumption, with respect to data monitoring activities, may be restricted or eliminated. By limiting or eliminating data monitoring activities, the MBU system enhances battery performance multifold permitting the user to have access to data for longer periods of time without having to recharge the battery powering the MS.

In accordance with one embodiment, the network connection to a MS may be disabled whenever a MS is not actively engaged in any data transfer. Subsequently, the connection may be reestablished using a fast call setup, or fast re-establishment procedure, making the user unaware of the fact that the MS was previously disconnected from the network. Such intermittent connectivity creates more temporary capacity in the network for the service provider, thereby increasing the potential revenue which may be generated by dynamically reallocating capacity for other users. Additionally, the increased available bandwidth can facilitate the ability of a service provider to fulfill its contractual obligations under its Service Level Agreements (SLAs) with different users.

The MBU service may be employed in a network having an architecture and technological infrastructure wherein the time required for establishing a channel path is generally shorter than the time required to transmit a data packet, and wherein the technology preferably supports an IP payload. For example, in one embodiment, the time required for making a call may be less than about 300 milliseconds, whereas the time required for establishing a channel path may be less than about 150 milliseconds. Those skilled in the art will appreciate that the foregoing time periods are provided by way of example only and not by way of limitation. Faster calls and channel path establishments are within the contemplation of the invention, and slower calls and channel path establishments also may be contemplated. The MBU system may rely generally upon utilization of a unique algorithm referred to herein as Slotted Aloha Multiplexing (SAM) or Slotted Aloha Timeslot Multiplexing (SATM). The SAM algorithm may employ a micro-timer and may recognize a ki and a k₂, i.e. timeslots during which no data packets are transmitted or received. During operation, a "watchdog" associated with Packet Surveillance Software (PSS) may detect a non-packet silence period and disconnect a Traffic Control Channel (TCH) during such periods. Additionally, the PSS may keep a channel open for lightweight signaling, preferably the Broadcast Channel (BCCH). The foregoing watchdog in this particular embodiment may include a micro-timer which may request the signaling layer to disconnect the call if packet transactions are not available, or do not occur for a predetermined time period. The PSS may monitor the communications network activity for any data packet transmission or reception from either the MS or the network. If the PSS identifies one or more data packets approaching, the PSS may instruct the signaling channel to create a call. In this embodiment, as noted above, it is desirable to ensure that the time required for establishing a call or a channel path is shorter than the time required to transmit the data packet. Additionally or alternatively, the PSS may be designed so as to buffer data packets such that even extremely high data transmission rates may be accommodated.

By way of example and without limitation, the following discussion is a mathematical explanation of the foregoing, where: X = Duration of network connection, wherein the MS connected to the network is assigned only a single timeslot;

Y = Maximum number of data packets that may be transmitted during X; U = Uplink data (i.e. data transmitted from a MS to a network); and D = Downlink data (i.e. data transmitted from a network to a MS).

With the foregoing definitions in mind, it will be appreciated that during uplink, within any given timeslot duration X, the traffic may be represented as: U traffic = Y - ni (where m < Y). The factor ni is included to represent the possibility that a MS is transmitting data packets to a network at a rate lower than the maximum bandwidth capacity.

Similarly, during downlink within any given timeslot duration X, the traffic may be represented as:

D traffic = Y - n₂ (where n₂ < Y)

The factor n₂ is included to represent the possibility that a network is transmitting data packets to a MS at a rate lower than the maximum bandwidth capacity. As noted briefly above with reference to Figure 9, in general it may accurately be assumed that ni > n₂. That is, uplink traffic is generally lighter than downlink traffic.

The effective time during uplink, when U tra_ffi_c = Y - ni, may be represented as: U time = X " kι

The factor ki represents time associated with a number of timeslots during which no data packets are transmitted.

Similarly, the effective time during downlink (when D tra_ffic = Y - n₂) may be represented as: D _tim_e = X - k₂

The factor k₂ represents time associated with a number of timeslots during which no data packets are received

When a communication network utilizes a MBU system, the TCH may be disconnected such that an associated MS is not monitoring any timeslots during ki and k₂. Consequently, the battery power devoted to monitoring data transmission is substantially reduced. In particular, during ki and k₂, data transmission monitoring may be eliminated at the network level through disconnection of the channel through which the monitoring is enabled.

Figure 10 is a graphical representation of the problem overcome by one embodiment of a network-based MBU system. For clarity purposes,

Figure 10 should be seen in conjunction with Figure 9. In Figure 10, the solid horizontal lines represent time X, the duration of network connection while using a single timeslot. Indicated as A in Figure 10, a MS may typically monitor the network connection for data transmission during the entire duration X, as shown by the horizontal dashed line extending the entire length of the solid horizontal line. In contrast, the broken dashed horizontal line, indicated as B in Figure

10 represents the timeslots during which data transmission or reception is actually occurring, whereas the broken dashed horizontal line in C represents the time during which no data transmission or reception activity is occurring. Those skilled in the art will appreciate that an MBU system, which disconnects the TCH during the periods indicated in C, may result in substantial battery power savings by the MS.

In accordance with current GSM technology, a MS connected to a network in data mode, on a packet-based call, monitors every timeslot, even when neither the MS nor the network is transmitting or receiving any data. This continuous monitoring depletes battery power unnecessarily, and consequently reduces standby and talk time, restricting mobility. The MBU system employed by the foregoing embodiment of the present invention may provide an option wherein this power depletion bottleneck may be overcome. Importantly, the technology is network-based and requires no changes or alteration to the MS or handset hardware. Additionally, timeslots and network bandwidth are freed up, enabling temporary increased capacity in the network.

Remote Rendering Services (RRS)

The main difference between a GPRS enabled MS and a current GSM enabled MS resides in the fact that the former is capable of transmitting and receiving IP data packets. GPRS enabled devices generally are designed with enough memory and processing capabilities to execute resident applications, including a micro-browser facility for displaying formatted content. RRS enables a standard GSM enabled MS handset, i.e. one without

WAP capability, to access and display IP data packets. Additionally, RRS provides the functionality to execute and to process applications resident on the network side, and to transmit data preformatted for a particular display capabilities of a GSM enabled MS in a readable format such that the MS may display it. Importantly, the hardware and software employed by existing GSM enabled MS need not be modified or altered in any way to support the foregoing functionality.

Figure 11 is a simplified block diagram illustrating one embodiment of a system architecture supporting RRS. It will be appreciated that Figure 11 illustrates similar system elements as Figure 1 , in particular: a Base Transceiver Station (BTS) 104, a Base Station Controller (BSC) 106, a Network 110, a computer Server 102; and an Enabler 100.

In operation, RRS may employ one or more computer Servers, such as a dedicated RRS Server or Server 102, for example. In the following discussion with reference to Figure 11 , RRS is described as operating through Server 102, but the invention is not to be construed as so limited; it is within the scope and contemplation of the present invention to employ one or more computer servers, either dedicated exclusively to RRS or capable of multiple functions.

The arrangement illustrated in Figure 11 , in combination with an RRS module installed in Enabler 100, makes it possible for the GSM enabled MS user to access data from a particular internet site or network node. The data may be any text-based or minimal graphics-based content. This data, for example and without limitation, may be located on Network 110, or may be accessible through a LAN, a WAN, or the Internet. Numerous server-side applications may be developed to use in connection with RRS services. These applications may be installed and executed entirely on Server 102 and the data may subsequently be transmitted to a MS 120 in a format compatible with the display characteristics of the MS 120.

In accordance with one embodiment, for example, a handset or other MS 120 making use of RRS may have display characteristics similar to a Unix character terminal while communicating with server-side hardware, i.e. a computer server system such as Server 102. In this particular embodiment, Server 102 may function as a proxy whenever MS 120 makes an Internet call; that is, Server 102 itself may make the Internet call through the RRS on behalf of MS 120. As another example, MS 120 may make an SMS call to Enabler 100. The call may then be converted by Enabler 100 into a format that RRS understands.

As illustrated in Figures 1 and 11 , Server 102 may be in communication with Enabler 100, which as discussed above, establishes a link with MS 120 and effectively uses the signaling link to query or to send data across the link. Additionally, Enabler 100 may identify RRS service operations initiated at MS 120, establish a link with Server 102, request that Server 102 format the data received into packets, and send the packets across the Network 110. When a response is obtained from Network 110, Server 102 may reformat the data for display at MS 120 using the SMS signaling protocol. In one embodiment, the displayed data may include, for example and without limitation, hyperlink information prefixed or suffixed with numbers or special characters which may be selected through a keypad or other input mechanism associated with MS 120 to refresh the hyperlink.

It will be appreciated that Server 102 may advantageously be connected to Enabler 100 through DSIB 262, referred to in Figure 2. Server 102 may create a separate instance for every MS 120 requesting RRS service; these instances are indicated in Figure 11 by numerals 1104 and 1106. In one embodiment, it may be desirable to activate the RRS service functionality by dialing a predesignated telephone access number from a MS 120. In this embodiment, Enabler 100 may identify the specific number dialed, and may transmit a request for RRS to Server 102. As noted above, Enabler 100 may create a communication channel between Server 102 and MS 120.

In essence, the RRS may serve as translator between MS 120 and an IP network, such as Network 110. For example, when a user issues a query for information from MS 120, the RRS may receive the query and associate it with one or more appropriate applications installed at Server 102. The application may packetize the query data, process the request, and transmit the query to Network 110. Similarly, the RRS may monitor Network 110 for a response to the query, and receive any response on behalf of MS 120. Additionally, RRS may identify the display size and resolution used at MS 120 and format the response to match the display characteristics of MS 120. The application software and RRS at Server 102 may subsequently prepare data packets, modified according to the application and the particular functionality of the MS 120, for transmission to MS 120. In that regard, the software at Server 102 may append various alphanumeric or other characters to the display of hyperlinks, for example. These alphanumeric or other characters may be generated by depressing one or more of the corresponding alphanumeric keypad buttons or through the voice recognition capabilities of the MS 120, for example. In that manner, MS 120 may navigate the hyperlinks and access software applications. After formatting the data at Server 102 for the particular display capabilities of the MS, data packets may be transmitted to MS 120.

Data transmitted from MS 120 may generally be in the form of Dual Tone Multi Frequency (DTMF) signaling tones, as is common in the art of touch-tone telephones. Enabler 100, which may preferably be equipped with alphanumeric support, may understand such DTMF tones and may forward them to the RRS. As noted above, the connection between Enabler 100 and MS 120 may advantageously be intermittent, i.e. it need not be a regular connection. As in the embodiment discussed above with reference to the MBU system, the connection between Enabler 100 and MS 120 may be established and maintained only when data is transmitted. Figure 12 is a simplified block diagram illustrating the operation of one embodiment of RRS.

Each time a user makes a call from MS 120, the call may be sent to a Base Process 1200 in the RRS, which may determine whether the call is new. In the case of a new call, a User Process 1202 may begin, which: (a) initializes or spawns an IP Application Process 1206; (b) initializes or spawns a Formatting Process 1204, specific to the request and particular capabilities of MS 120 (this ensures that data returned to MS 120 will be in the proper format); and (c) transmits a request that the desired location in Network 110 may be accessed by IP Application Process 1206. In response, IP Application Process 1206 may send an IP request to Network 110 through a Proxy 1208 present on the network-side. Responses from Network 110 may be received by the Proxy 1208 and transmitted to IP Application Process 1206. After any required processing, IP Application Process 1206 may then transmit the returned data to Formatting Process 1204 for formatting in accordance with the requirements of MS 120. Formatted content may then be transmitted to MS 120 through Base Process 1200, in accordance with SMS standards, for display in the appropriate format.

As described above, RRS may provide IP data services to standard GSM enabled devices without requiring hardware alterations. It will be appreciated by those skilled in the art that RRS provides increased utility to GSM devices by enabling IP capability through software and hardware implemented at one or more remote servers.

Slotted Aloha Timeslot Multiplexing (SATM)

Effective reuse of a timeslot during calls requires efficient utilization of one specific timeslot for multiple MS for unicasting. One embodiment of the present invention may employ a Slotted Aloha Timeslot Multiplexing (SATM) technique for unicasting multiple signals in a single timeslot. SATM may be applied in conjunction with the following: GPRS call handling system, Remote Rendering Service (RRS) (discussed above), Switched Timeslot Enhanced Packet Service (STEPS) (discussed in detail below), and Always-On WAP (AOW) (discussed in detail below). The SATM technique may be effectively used in IP-based packet data services where the transmission is of variable bit rate and employs ad hoc transmission and reception. In this context, effective signaling may be used for allocating a timeslot and for de-allocating a timeslot in the Radio Frequency (RF) communication signal for a particular call. In other words, SATM may be used to supply unicast data, in a single timeslot, for multiple mobile stations requiring data. In accordance with this embodiment, signaling messages may be used to allocate a reception timeslot to a particular handset or MS. After a specified or predetermined duration, the reception timeslot may be released from that particular MS through a signaling pattern, freeing that timeslot for other uses, while the MS is assigned a different reception timeslot. That is, the reception timeslot allocated to a given MS may be changed dynamically during operation. Signaling messages are known in the art; one example of such a signaling message currently employed by GSM technology is a hand over message; such a signaling message is conventionally used for shifting a timeslot or, more commonly, for shifting the frequency allocated to a particular MS.

Figure 13 is a simplified diagrammatic view of one embodiment of a timeslot multiplexing strategy. In Frame 1 , the fourth timeslot TS3 is used for a first mobile station MS1. When a second mobile station MS2 connects to the communication system, the same timeslot TS3 may used for both MS1 and MS2. During periods in which MS1 must monitor TS3, the SATM system may allocate TS3 to MS1 , while MS2 may be assigned to an inactive timeslot through signaling messages, as discussed above. Similarly, when MS2 requires monitoring of data packets transmitted during TS3, MS1 may be sent a hand over signaling message which assigns MS1 to an idle timeslot while MS2 may be signaled to monitor timeslot TS3. In the foregoing manner, data may be served to both MS1 and MS2; the SATM system contemplates serving data either periodically or on an on-demand basis.

In one embodiment of this invention, a timeslot may be allocated for a set of MS that may be signaled and controlled in unison. For example, the third timeslot, TS2 in Figure 13, may be assigned three different mobile stations: MS2, MS5, and MS8 (not shown). The fourth timeslot TS3 may also be assigned three different mobile stations: MS1 , MS3, and MS5, for example. Note that a given mobile station, for example MS5 in the foregoing scenario, may be served by more than one timeslot.

In the example above, MS5 may have a higher priority than the other mobile stations, and thus MS5 may be served by both timeslots TS2 and TS3. Referring back to Figure 1 , such prioritizing and serving may be accomplished by the Enabler 100 without any acknowledgement or intervention on the part of the BSC 106. However, timeslots may be reassigned by BSC 106. To avoid or to preempt such reassignment of timeslots by BSC 106, two basic considerations may be addressed by the system: timeslot switching and timeslot denial.

If the timeslot that is requested by BSC 106, which is currently used by Enabler 100, is switched over to BSC 106 control, one possible repercussion is that fewer timeslots may remain available for multiplexing by Enabler 100. It is also possible that another timeslot may become available such that the same number of timeslots will be accessible by Enabler 100 for timeslot multiplexing. Current network traffic and multiplexing conditions may be taken into account before Enabler 100 either permits or denies BSC 106 access to a timeslot. If, on the other hand, Enabler 100 currently has only one timeslot available for STEPS multiplexing, or if various other channels are available for BSC 106 to allocate, Enabler 100 may deny the timeslot switch; in this case, Enabler 100 may signal this denial information to BSC 106.

Switched Timeslot Enhanced Packet Service (STEPS) As discussed above, some GPRS service classes, in particular service classes B and C, are not available for conventional GSM enabled MS. In accordance with one embodiment of the present invention, Switched Timeslot Enhanced Packet Service (STEPS) may provide full GPRS functionality, at all service classes, to a standard GSM enabled MS, with no need to modify or to alter the MS hardware. This functionality may be provided for those MS, or GSM card-equipped MS, that have the capability to connect to other, often more powerful, computer devices, such as a laptop computers for example.

STEPS functionality supports the MBU system, discussed in detail above. Additionally, STEPS may advantageously employ the SATM methodology, discussed above, to economize on required RF resources, while simultaneously increasing data transmission rates experienced at the MS.

The following description refers back to Figures 1 and 2. Through the STEPS service, Enabler 100 may provide a conventional GSM device with GPRS functionality. The GSM enabled MS 120 may monitor single or multiple timeslots and recognize IP data packets.

The STEPS service may operate as a Layer 3 switching mechanism in mobile IP network communications. Timeslots that carry IP data may be identified by reading the IP packets and the data may be switched to a different timeslot accordingly. For example, a timeslot may generally be assigned to a user in accordance with the user's IP address. In this manner, the STEPS service may create a LAN-like mechanism in the GSM network. A logical connection may be created to each of a plurality of MS, and the various mobile stations may be allocated, either individually or collectively, to one or more timeslots. Depending upon the IP address and the IP traffic on the network, a MS may be assigned a timeslot for a specific duration, and that timeslot may be dynamically allocated through the services of SATM, described above.

The Enabler 100 may provide data services to a MS 120 by sharing an Application Binary Interface Standard (ABIS) interface. As discussed in detail above, Enabler 100 may be connected through the DSIB 262 interface to a network, such as Network 110 in Figure 2. This interface opens the GSM network to the IP cloud. When MS 120 makes a call, Enabler 100 may recognize the call as a STEPS call. That is, the STEPS service may continuously monitor for new call requests, i.e. it may be an "always-on" service, and may be accessed through a specific telephone number. Calls inbound to this telephone number may automatically trigger a STEPS service.

Enabler 100 may employ a FAST call technique. A FAST call may be made by DSIB 262 to MS 120 without any intervention by BSS 112 or the NSS (not shown). Consequently, such a call may be made for transparent data services between MS 120 and Server 102; in that manner, the time required for establishing the communication path may be considerably reduced.

On receipt of a call from the foregoing telephone number, Enabler 100 may signal DSIB 262, which may negotiate Quality of Service (QoS) and priority information with Enabler 100. In operation, DSIB 262 may operate through a proxy, such as proxy 1208 in Figure 12, which will connect the Network 110 with MS 120. The respective upstream and downstream timeslots may be allocated only if there is transactional traffic.

The MBU system discussed above may be invoked to release RF resources and to enhance the life or residual capacity of the battery powering MS 120.

In accordance with the MBU system, the connection between MS 120 and Enabler 100 may be released the moment the "attach" procedure is complete. Subsequently, a FAST call may be made for any data to be transmitted to or from MS 120. As noted briefly above, MS 120 may have a permanent IP address, which may be broadcast by a proxy to the nearest router and Domain Name Server (DNS) if needed. Alternatively, MS 120 may have a dynamic IP address, for example, according to the Dynamic Host Configuration Protocol (DHCP); in this case, the DHCP server may be identified and controlled by DSIB 262. One or more timeslots may be allocated for serving MS 120. As noted above, the one or more allocated timeslots may preferably be utilized by MS 120 only for data packet transactions (both uplink and downlink).

During a call, MS 120 may signal Enabler 100 if data packets are to be sent. Responsive to this signal, Enabler 100 may immediately assign a timeslot for the data packets. The assigned timeslot may carry packets for the particular IP address associated with MS 120. DSIB 262 may establish a routine to collect data packets from the assigned timeslot and transmit such packets to a proxy from which the data may be further transmitted to Network 110. As noted above, MS 120 may transmit uplink data in one or more timeslots, depending upon the capability of MS 120 and network assignment and bandwidth. Additionally, the system may assign a different uplink timeslot to MS 120 which each uplink transaction. With each timeslot reassignment, DSIB 262 may be instructed to extract data packets from the appropriate timeslot for each connection to the proxy.

With specific reference now to Figure 2, ACP 226 may analyze the call setup, and more particularly, the telephone number of an inbound call from

MS 120, to determine if the call is requesting STEPS service. If the telephone number belongs to STEPS, ACP 226 may disconnect or release the connection with BSC 106.

When a subscriber is registered as a STEPS subscriber, a QoS parameter may be associated with the connection; alternatively, a subscriber's connection may be on a Best Effort basis. Accordingly, ACP 226 may examine timeslot availability and analyze signaling transactions to determine if the specified QoS is feasible. If the desired QoS is not feasible, ACP 226 may instruct the system to prompt the MS 120 user with QoS details, at which point the user may be given an option to accept or to reject connection, or to establish a Best Effort connection.

Additionally, ACP 226 may generate a matrix of frequency timeslots, which may be categorized by the following: timeslots allocated by BSC 106 and timeslots allocated by Enabler 100. Every field may also have another information record wherein the connection is characterized as fixed/droppable, fixed/non-droppable, switched/droppable, or switched/non- droppable.

After ACP 226 has generated the foregoing matrix, the matrix data may be dynamically available whenever BSC 106 queries BTS 104 concerning the physical resources of the communication network. If timeslots are free, BSC

106 may not allocate those timeslots that have been reserved by Enabler 100.

Additionally, ACP 226 may issue a Tunneling of Messages (TOM) instruction to SGI 222. In response, SGI 222 may take over the functionality of BSC 106 and MSC 108. In other words, all data and messaging transactions with respect to the call may be prepared by SGI 222.

Furthermore, SGI 222 may obtain parameters, such as mobile class mark and disposable timeslot information, embedded in the TOM message. SGI 222 may also spawn a daemon process that may periodically query BTS 104 in the manner ordinarily undertaken by BSC 106.

In addition, SGI 222 may create another daemon process for continuous monitoring of any changes in the timeslot matrix. If BSC 106 has reserved a timeslot for a particular MS 120, which is in conflict with a timeslot request or reservation made by Enabler 100, SGI 222 may apply an heuristic algorithm to weigh the following options.

SGI 222 may instruct Enabler 100 either to drop the voice call, to drop the STEPS call, or to switch the timeslot for one or both of the voice or STEPS calls.

Finally, SGI 222 may prepare data packets, copy the timeslot matrix, query BTS 104, and monitor timeslot status, including timeslots allocated to Traffic Control Channel (TCH), SDCCH, Broadcast Control Channel (BCCH), Access Grant Channel (AGCH), and Frequency Correction Channel (FCCH). Such monitoring may be done by a common process in SGI 222 that may serve other threads of SGI 222 working on individual calls.

In one embodiment, SGI 222 may also determine any pattern of data insertion for a particular STEPS requester; such a discernable pattern may be, for example, data insertion into every alternate timeslot or into every n^th timeslot.

To connect with Network 110, SGI 222 may issue a message to EDI 260 requesting that a network connection be established. A full duplex connection may be established between SGI 222 and EDI 260, as well as between EDI 260 and DSIB 262. In this embodiment, a permanent signaling link may exist between SGI 222 and EDI 260 and between EDI 260 and DSIB 262.

Responsive to the foregoing request, EDI 260 may return a message confirming connection. This message may include a unique connection identifier for use by SGI 222 with respect to transmission of framing pattern signals to the EDI 260/DSIB 262 link. SGI 222 may then issue a request to

ACP 226 for temporary suspension of call operations for this particular call, and provide EPTM 206 with call proceeding parameters. In turn, EPTM 206 may issue a data request with call proceeding parameters to BTS 104. Finally, SGI 222 may begin sending asynchronous messages that refer to a connection identifier. The asynchronous messages may include one or more of the following parameters: one or more timeslots into which the message should be inserted, validity of the frame, and any timeslot insertion patterns.

Preferably, these messages may be sent by SGI 222 only if there is a timeslot switch or a change in the timeslot insertion pattern, or in the case when the validity of the previous send message expires. EDI 260 may request a new asynchronous message. SGI 222 may maintain multiple connection identifiers. When a message from SGI 222 arrives, EDI 260 may use the connection identifier to determine which data packets are to be suffixed with this message.

From the foregoing, it can be seen that the present invention provides an effective system for delivering IP data over mobile to GSM devices which otherwise are not IP-enabled. The preferred embodiments disclosed herein have been described and illustrated by way of example only, and not by way of limitation. Other modifications and variations to the invention will be apparent to those skilled in the art from the foregoing detailed disclosure.

Alwavs-on WAP (AOW) According to another embodiment of this invention, Always-on Wireless

Application Protocol (WAP) enables a MS, with WAP capabilities, to access data in a packetized circuit switched manner, ensuring that the MS always is connected to the network for a WAP session. AOW reduces the latency and cost of WAP, thereby enabling a higher degree of WAP usage. AOW provides wireless communications operators with the enhanced flexibility and additional income provided by the ability to charge the customer based on the higher volume of data transfer, or the increased usage.

WAP is a specification for presenting and interacting with information, Wireless Markup Language (WML) data, on wireless and other devices. Over GSM, WAP is implemented over a circuit switched carrier network. As an example, and without limitation, there are various call scenarios possible with respect to an AOW session: normal AOW call, incoming voice call during ongoing AOW call, outgoing voice call during an ongoing AOW call, and SMS message reception during an ongoing AOW call. The Service Layer (SL) is responsible for identifying whether the call is an AOW call. If the call is an AOW call, then the AOW Daemon Manager (AOWDM) main daemon shall be informed of an AOW call.

Figure 14 is a flow diagram illustrating the interface operation between the SL and Interception Process (XP) and between the SL and the AOWDM. Whenever a MS makes an AOW call by dialing a predetermined telephone number, shown as step 1402, the XP 1450 receives a message and passes the call, at step 1404, to the SL 1452. Based upon the predetermined number dialed by the MS user, the SL 1452 validates the call as either an RRS call, a STEPS call, or an AOW call, and passes the call, shown as step 1406, to the AOWDM 1454.

Subsequently, the SL 1452 sends a message, at step 1410, to the XP 1450 whenever it receives from the AOWDM 1454 a confirmation, as in step 1408, that a user session has been established. This is followed by a SL 1452 message indicating that a connection was established. At that point, the XP 1450 starts communication, as in step 1412, with the AOW subscriber process (AOWSP) 1458 directly, without the involvement of the SL 1452.

The call is terminated when the MS user sends a disconnect request 1414 to the XP 1450, which is then forwarded to the SL 1452, shown as step 1416, and the SL 1452 acknowledges receipt of the request, as in step 1418. When the user requests an AOW service, shown as step 1420, the SL

1452 receives from XP 1450 a request, at step 1422, to begin service, and then forwards it transparently, as in step 1424, to the AOWDM 1454. The AOWDM 1454 then creates a message queue (MQ) and starts an instance of the AOW process for that user. AOWDM 1454 then sends the MQ ID, as in step 1426, to the AOWSP 1458 while spawning it. The SL 1452 then receives a notification, as in step 1428, from

AOWDM 1454 requesting a connection and subsequently returns an acknowledgement of its acceptance, as in step 1430.

Whenever the SL 1452 receives a termination request, shown as step 1432, from XP 1450, it passes this request, shown as step 1434, transparently to AOWSP 1458, which subsequently returns an acknowledgment, as in step 1436, and terminates itself. The SL 1452 forwards a termination of service message, shown as step 1438, to AOWDM

1454, so that AOWDM 1454 can remove the entries for the corresponding subscriber process.

Figure 15 is a flow diagram illustrating the interface operation between the XP and AOWSP via Radio Link Protocol (RLP). AOWSP 1454 will interface, as in step 1502, with XP 1450 after a communication has been established between them via RLP 1556. The communication between XP 1450 and AOWSP 1458 will be mainly data communication. Until the SL

1452 receives a request either to suspend or to end the connection from the

AOWDM 1454, the AOWSP 1458 will keep communicating, as in step 1502, with XP 1450 via RLP 1556. The XP 1450 sends a message, shown as step

1504, to AOWSP 1458, in the uplink direction, whenever a user exchanges data with an external network.

When AOWSP 1458 wants to send data to a particular user, it sends the data, as in step 1506, in a predetermined format to XP 1450. On reception of this data, XP 1450 places the data in the traffic channel and sends a confirmation, shown as step 1508, of the reception of data to AOWSP 1458.

Whenever XP 1450 has extra resources available, and the data rate is slow, the XP 1450 could send a message, as in step 1510, to AOWDM 1454 requesting an increase of the data rate. In return the AOWDM 1454 sends a signal, shown as step 1512, to all AOWSP 1458 to increase the data rates and sends a confirmation, shown as step 1514, back to the XP 1450.

If the XP 1450 finds difficulty in sending the downlink data to the MS, because of some problem in the availability of resources, the XP 1450 could send a message, as in step 1516, requesting a decrease of the data rate to AOWDM 1454. The AOWDM 1454 in turn would send a signal, shown as step 1518, to all AOWSP 1458 and send a confirmation, as in step 1520, back to XP 1450. The interface between AOWSP 1458 and the WAP Gateway occurs via point to point protocol (PPP) sessions. The routing is defined separately for each AOW user who is placed in a separate IP address pool.

The AOW Manager (AOWM) is responsible for the spawning of AOW user sessions when it receives a service request from the SL. These AOW sessions receive WAP data contents directly from the WAP gateway. Upon reception of WAP data, the AOW session forwards it to XP. XP will then place the data packets in the traffic channels.

AOWM could be responsible for maintaining context for every AOW session initiated by a MS. AOWM also could coordinate with XP to terminate, suspend, or resume any AOW session that has already been initiated by a MS. XP may end a voice call during an AOW call that will be informed to AOWDM, which in turn will enable the initiation or resumption of the AOW call session.

AOWDM could act as a controller for the AOW service and may reside in the Enabler. AOWDM could be responsible for mapping of the XP's or SL's decisions to AOW's activities. AOWDM could be responsible for the maintenance of user's AOW subscriber sessions, and could also act upon XP's decision of whether a AOW session needs to be terminated, maintained, or suspended during an voice call. The main functionality of AOW session is to work as Data Router (DR) and Buffer Manager (BM).

The BM is responsible for buffering of the data that needs to be maintained for the full WAP session. This function has particular significance for the integration of Service Operation Center (SOC) and Network Management System (NMS) with Enabler.

The DR may be responsible for the reception and transmission of data that needs to be transmitted between MS and the WAP Gateway.

Claims

WHAT IT IS CLAIMED IS:

1. A method of delivering to at least one of a plurality of mobile stations with Wireless Access Protocol (WAP) capabilities, in a wireless communications network, access on demand to data in a circuit switched manner; said method comprising: receiving a call from the at least one of a plurality of mobile stations with WAP capabilities through one of a list of designated telephone numbers; identifying the call from the at least one of a plurality of mobile stations with WAP capabilities as one selected from a group consisting of

Remote Rendering Service (RRS) call, Switched Timeslot Enhanced Packet Service (STEPS) call, Always-On WAP (AOW) call, and other call; if the call from the at least one of a plurality of mobile stations with WAP capabilities is an AOW call, then: connecting the at least one of a plurality of mobile stations with WAP capabilities AOW call to access data in a circuit switched network; and maintaining alive the call from one of a list of designated telephone numbers for as long as the at least one of a plurality of mobile stations with WAP capabilities so desires; or if the call from the at least one of a plurality of mobile stations with

WAP capabilities is not AOW call, then: disconnecting the call from the at least one of a plurality of mobile stations with WAP capabilities.

2. A method for delivering internet protocol (IP) data to a mobile station in a wireless communications network, the method comprising: monitoring at least one of a plurality of communication timeslots between the mobile station and a base station subsystem; identifying IP data in a communication between the mobile station and the base station subsystem; associating an IP address for the mobile station with the at least one of a plurality of communication timeslots; and delivering the IP data to the mobile station over the one of a plurality of communication timeslots so as to emulate a local area network within the wireless communications network.

3. The method according to claim 2 wherein the delivering comprises providing the IP data on a communication timeslot normally associated with the mobile station for voice communication.

4. The method according to claim 2 wherein each mobile station is dynamically allocated an IP address.

5. The method according to claim 2 wherein each mobile station has a permanent IP address.

6. The method according to claim 2 wherein the mobile station is allocated a timeslot for a predetermined duration.

7. The method according to claim 2 wherein the mobile station is dynamically allocated a timeslot for a variable duration according to an algorithm.

8. The method according to claim 2 wherein the mobile station is selected from the group consisting of a telephone, a computer, a pager, an e-mail device, an internet appliance, and a- device capable of communicating with the wireless communications network.

9. A method for delivering IP data packets to a mobile station, the method comprising: receiving a call from one of a designated list of telephone numbers; identifying the call as an IP data request; and connecting the call to an IP network subsystem such that an IP data communication is established with the mobile station.

10. The method according to claim 9 wherein the communication is established as a Quality of Service connection or a Best Efforts basis connection.

11.A method of managing power consumption for a battery powered mobile station for use in a wireless communications network, the battery powered mobile station communicating over the wireless communications network via at least one channel; the method comprising: monitoring data transmission timeslots between the battery powered device and the wireless communications network; detecting non-data transmission timeslots during which data is not transmitted between the battery powered mobile station device and the wireless communications network; disconnecting the at least one channel during the non-data transmission timeslots so that the battery powered mobile station device does not transmit or receive data during the non-data transmission timeslots; and reconnecting the at least one channel when a data transmission timeslot is detected.

12. The method according to claim 11 wherein the reconnecting of the at least one channel includes providing for data buffering.

13. The method according to claim 11 wherein the detecting non-data transmission timeslots includes utilizing a surveillance software module.

14. The method according to claim 13 wherein the at least one channel comprises a plurality of channels, at least one of the channels being a signaling channel, the surveillance software module maintaining open at least the signaling channel to enable detection of the data transmission timeslots.

15. The method according to claim 13 wherein the surveillance software module performs a call control function.

16. The method according to claim 13 wherein the surveillance software module is capable of dynamically allocating channel bandwidth.

17. The method according to claim 11 wherein the battery powered mobile station is selected from the group consisting of a telephone, a personal digital assistant (PDA), an e-mail device, an internet appliance, and a device capable of communicating with a wireless communications network.

18. The method according to claim 11 wherein the at least one channel comprises a plurality of channels, at least one of the channels being a traffic control channel, said disconnecting comprising disconnecting said traffic control channel during the non-data transmission timeslots.

19. The method according to claim 11 wherein the managing power consumption for a battery powered mobile station device for use in a wireless communications network is independent of the type of wireless communications network to which the mobile station device is connected.

20. The method according to claim 11 wherein the managing power consumption for a battery powered mobile station for use in a wireless communications network is used in combination with at least one service selected from a group consisting of Global System for Mobile (GSM), Generalized Packet Radio System (GPRS), Wireless Application Protocol (WAP), Remote Rendering Service (RRS), Switched Timeslot Enhanced Packet Service (STEPS), Enhanced Data for GSM Evolution (EDGE), and Always on WAP (AOW).

21. The method according to claim 11 wherein the detecting non-data transmission timeslots utilizes a Slotted Aloha Timeslot Multiplexing (SATM) algorithm.

22. The method according to claim 21 wherein the SATM algorithm is utilized as a micro timer to detect non-data transmission timeslots.

23. A method of multiplexing a data communication timeslot in a radio frequency communication signal for transmitting data to a plurality of mobile stations in a wireless communications network; said method comprising: allocating the data communications timeslot to a first of the plurality of mobile stations; selectively releasing the data communication timeslot; and reallocating the data communication timeslot to one or more remaining ones of the plurality of mobile stations.

24. The method according to claim 23 wherein the selectively releasing occurs after a predetermined duration.

25. The method according to claim 23 wherein the data communication timeslot allocated to one of the plurality of mobile stations is dynamically allocated during operation.

26. The method according to claim 23 wherein said selectively releasing occurs when another of the remaining ones of the plurality of mobile stations requires data communication in the data communication timeslot.

27. The method according to claim 23 wherein two or more of the data communication timeslots are allocated to one of the plurality of mobile stations.

28. A method of delivering data to a plurality of mobile stations associated with a base station controller of a wireless communications network; said method comprising: monitoring a transmission between one of the plurality of mobile stations and the base station controller; detecting a transmission containing data between the one of the plurality of mobile stations and the base station controller; if the transmission is a non-data transmission then: routing the non-data transmission between the one of the plurality of mobile stations and the base station controller; or if the transmission is a data transmission from the one of the plurality of mobile stations then: generating data from the one of the plurality of mobile stations; transmitting the generated data to an enabler device; translating the transmitted data from a format generated by the one of the plurality of mobile stations to a format compatible with a format used for data transmission over a network; routing the translated data from the enabler device to the network; or if the transmission is a data transmission from the network then: transmitting the generated data to the enabler device; translating the transmitted data from the format compatible with the network to a format compatible with a format used by the one of the plurality of mobile stations; formatting the translated data to fit a display of the one of the plurality of mobile stations; transmitting the formatted data from the enabler device to the one of the plurality of mobile stations; and displaying the transmitted data on the display of the one of the plurality of mobile stations.

29. The method according to claim 28 wherein the data is internet protocol data.

30. The method according to claim 28 wherein the data is at least one selected from a group consisting of text based and graphics based.

31. The method according to claim 28 wherein the data being transmitted from the one of the plurality of mobile stations is in the form of dual tone multi- frequency (DTMF) tones.

32. The method according to claim 28 wherein the data being transmitted from the one of the plurality of mobile stations is in the form of short message service message format.

33. The method according to claim 28 wherein the routing, the translating, the formatting, and the displaying are performed by one or more computer servers.

34. The method according to claim 33 wherein the one or more computer servers processes the data through one or more server-side applications.

35. The method according to claim 34 wherein the one or more server-side applications is a short message service center.

36. The method according to claim 28 wherein the displayed data is hyperlink information prefixed or suffixed with alphanumeric or special characters.