USPatent applicationPatented

Supporting both packet and circuit-based wireless networks

Granted 17 Sep 2013 · 1 office action

Assignee: Intel Corporation

Law firm: Law firm · Log in to unlock

Attorney: Attorney · Log in to unlock

Inventors: Anil K. Kumar · Examiner: Kevin Mew · AU 2471 · TC 2400

Life of the application

7 dated events
⤢ drag to zoom20122014201620182020202220242026202820302032ProsecutionTerm & fees
ProsecutionTerm & feeshover for detail · click to open

Abstract

Middleware may accommodate both packet data and circuit data services in the same cellular telephone. A cellular telephone may travel between networks that are packet and circuit data service based. A protocol middleware may determine whether packet data services are available, and, if so, may determine the mobility management state of the system. Depending on the mobility management state of the system, inappropriate applications may be closed or suspended.

Description

4 parts
›CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 09/918,244 now U.S. Pat. No. 7,920,554, filed on Jul. 30, 2001.

›BACKGROUND

This application relates generally to cellular telephones.

Cellular telephone networks may be packet-based where information is divided into packets and transmitted in a packet-switched system. Alternatively, cellular telephone networks may be circuit-based or not packet-based.

In packet-based wireless networks, the user is generally charged based on the number of packets that are transmitted. Commonly in circuit-based wireless networks, the user is charged based on connection time.

Generally, cellular telephones are either packet-based or circuit-based, but not both. Some of the reasons for this are that packet-based systems utilize mobility management state information while circuit-based systems do not. Application programs in a given cellular telephone may be unable to discern when to apply packet-based protocols and when to apply circuit-based protocols. In addition, because charges are assessed based on packets in a packet-based network and time in a circuit-based network, it is difficult for conventional cellular telephones to determine how and when to accrue charges.

The 3GPP specification calls for a class A mode that supports both second generation (2G) and third generation (3G) services simultaneously. 3 rd Generation Partnership Project; General Packet Radio Service, Service description, Stage 1, (3GTS 22.060 Release 1999). However, the specification does not explain how to smoothly transition between 2G and 3G services.

For example, in third generation (2.5G or 3G) cellular telephone networks, three different mobility management states known as idle, standby and ready are available. A cellular telephone in the ready state is paged periodically to determine whether or not the cellular telephone is available and ready to receive phone calls. After the expiration of a time period without receiving a call (or under other circumstances), the telephone may be transitioned from the ready to the standby state. From the standby state, upon the expiry of a period of time without receiving any calls, the telephone may be transitioned to the idle state.

In the ready state, the phone is ready to receive calls. It is periodically paged in accordance with appropriate page messaging protocol. The standby state involves less paging. Generally, the cellular telephone is in a larger area with a plurality of cells and is paged less often than in the ready state. The least paging is done in the idle state.

Thus, an application running on a cellular telephone that operates both in third generation (2.5G or 3G) and second generation (2G) systems, must be able to handle the different circumstances that arise because of the mobility management states when (and only when) the system is in a third generation or packet-switched environment. The rest of the time the extra constraints raised by mobility management states may be ignored.

Thus, there is a need for a way to transition between circuit-based and packet-based systems in the same cellular telephone without user interaction.

›BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic depiction of one embodiment of the present invention; and

FIG. 2 is a flow chart in accordance with one embodiment of the present invention.

›DETAILED DESCRIPTION

Referring to FIG. 1 , a cellular telephone may be applicable to both second generation circuit-switched networks and third generation packet-switched networks. The cellular telephone or mobile subscriber shown in FIG. 1 may include an application processor 28 coupled to a baseband processor 32 . Basically, the baseband processor 32 handles call implementation functions and the application processor 28 handles all other functions.

A call model 18 provided with the baseband processor 32 contains a set of cooperating services that work together to process a call. The call model 18 implementation supports basic call functions such as session management including call setup, modification and tear down as well as mobility management. Since the services offered by networks vary widely, the call model 18 functionality allows multi-mode terminal implementation that is both modular and scalable as long as all access protocols adhere to a pre-defined protocol application program interface (API) described herein and all applications supporting different access protocols adhere to the protocol API.

The call model 18 residing on the baseband processor 32 supports both circuit data service (CDS) and packet data service (PDS) through a protocol API. The call model 18 provides PDS availability information as well as mobility management (MM) state information to the application processor 28 as indicated at 10 , for example, through a baseband protocol API. The application execution environment uses this information to open, suspend, or close the wireless PDS applications.

The mobility management information provided by the call model 18 includes mobility management state as well as roaming information. The application execution environment checks the mobility management state before allowing the mobile subscriber to open new PDS applications. The application execution environment can be part of a protocol API or middleware 24 residing between the baseband processor 32 and the application processor 28 .

As a result, the application processor 28 can handle applications or programs 20 a relating to 2G implementations as well as applications 20 b related to 3G or 2.5G implementations. This is despite the fact that 2.5G and 3G applications and 2G applications may involve considerably different parameters. Again, 2G applications do not generally involve mobility management state information and use time-based charges while packet-based systems use mobility management state and must contend with idle, ready and standby mobility management states and charge based on numbers of packets.

Thus, referring to FIG. 2 , the protocol middleware 24 initially determines whether PDS is currently available to the mobile subscriber as indicated in diamond 26 . If not, all PDS applications are automatically closed as indicated in block 40 . Closing applications in this circumstance may reduce the likelihood of erroneous results or crashes in some embodiments.

If PDS is currently available, the mobility management state of the mobile subscriber is determined as indicated in diamond 30 . If the mobile subscriber is in the idle state, all PDS applications are closed as indicated in block 42 . Similarly, if the mobile subscriber is in the ready state, new PDS applications are opened or active PDS applications may be continued as indicated in block 44 . Finally, if the mobile subscriber is in the standby state, all PDS applications currently operating are suspended upon transition to standby as indicated in block 46 .

Thus, in accordance with embodiments of the present invention, the application execution environment may be automatically controlled without user interaction to support wireless networks based on either circuit or packet data service. This method of managing the application execution environment may increase the battery life of the packet-based cellular telephone in some embodiments. Embodiments of the present invention may be used in 2.5G and 3G packet-based mobile terminals irrespective of what type of air interface is utilized.

As a result, in some embodiments, the application environment may suspend or shut down high data rate applications when the mobile subscriber is in a 2G network without degrading the performance of other applications. Similarly, when packet data service applications are applicable, the mobility management state of the system may be determined and used to handle applications appropriately.

While the middleware 24 is illustrated as residing on or being associated with the application processor 28 alternatively it may reside on or be associated with the baseband processor 32 . As still another embodiment, portions of the middleware 24 may reside on or be associated with each of said application and baseband processors 28 and 32 . In still other embodiments, the baseband and application processor functionalities may be accomplished in a single integrated circuit.

While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.

Claims as granted

4 claims

Log in to read the claims of this application.

Log in to unlock

Classifications

10 codes
IPC · International Patent Classification
Section H — Electricity
  • H04M1/725
  • H04L12/56
  • H04W76/06
  • H04W76/04
  • H04W88/06
  • H04L12/66
  • H04L12/28
USPC · US Patent Classification
370/354455/422.1370/328

Claim changes

Soon
Coming soonHow the claims changed between publication and grant

See which claims were amended, added or cancelled during examination, with every added and removed word marked.

AmendedAddedCancelledUnchanged

The published claims of this application are not paired with the granted ones in what we hold.

File wrapper

⤢ drag to zoomJan 2011Apr 2011Jul 2011Oct 2011Jan 2012Apr 2012Jul 2012Oct 2012Jan 2013Apr 2013Jul 2013Oct 2013USPTOApplicantNon-final rejectionResponse after non-final
USPTOApplicanthover for detail · click to open
Pendency
2.6 y
939 days filing → grant
Office actions
1
non-final + final
Responses
1
no RCE
Examiner
Kevin Mew
art unit 2471 · TC 2400
Citations: 36 back · 0 forward

See the full prosecution history — every USPTO and applicant action on this file, in order.

Log in to unlock

Documents

Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.

Log in to unlock

Chain of title

No assignments have been recorded for this application yet.