Mobile telephones are becoming commonplace. As users become more accustomed to using mobile telephones, they are requesting more sophisticated uses of telephones. Ideally, users would like their mobile telephones to perform the same functions as their personal computers or hand-held personal digital assistants (PDAs). Implementing such uses in a mobile telephone environment requires application developers to develop or adapt their software for use on a mobile telephone. However, adapting or developing software for use on one original equipment manufacturer's (OEM's) mobile telephone does not necessarily guarantee that the software application will function on another OEM's mobile telephone due to the different radio implementations of different OEMs and due to the differences in different mobile environments.
In order to create a software solution adaptable to multiple different mobile systems and radios, there is a need for some kind of a hardware adaptation layer, i.e., a layer that isolates the specifics of a particular mobile system/hardware from the bulk of the software system. Such a layer, the radio interface layer (RIL), already exists. The RIL is a set of APIs providing a level of abstraction between the radio on a mobile phone and the software of the mobile phone. The RIL API set is roughly based on the Global System for Mobile Communication (GSM) AT interface as defined in GSM specifications 07.05 and 07.07.
The API set provides access to functionality contained within a mobile telephone, such as a GSM or CDMA compatible telephone. Applications running on an operating system in the mobile telephone are allowed to issue commands without knowledge of the underlying radio structure of the mobile telephone and without specific knowledge of the modem-type commands. For example, the applications may be allowed to access phonebook entries, restrict access to data and functionality using passwords, access file and message storage, and perform many other functions.
Unfortunately, the packet-switched data transmission services of the GSM system and the packet transmission service of the Universal Mobile Telecommunications System (UMTS) system are not fully compatible with each other. For example, the General Packet Radio Service (GPRS) packet transmission service deviates from the UMTS standard with respect to quality of service (QoS) alternatives that can be defined for the data transmission connection. Thus, when using a wireless terminal, the problem may arise that a data transmission connection can be established only to a mobile communication network of a particular type.
U.S. patent application Ser. No. 11/092,062 discloses and claims an extension to the RIL to include an API set supporting UMTS features in Windows Mobile platforms for 3G Smartphone and PocketPC devices. Such an RIL extension may include APIs to support such features as 3G QoS, secondary PDP context, 2G and 3G switching, voice group call service, and voice broadcast call service.
A typical RIL may include a hardware-independent proxy layer and a hardware-specific driver layer. In a typical RIL proxy, however, an asynchronous mechanism may be used to communicate between clients and the RIL driver. Such an asynchronous approach may not provide an effective way for providing an efficient signal exchange due to heavy usage of the RIL. Therefore, a synchronous RIL API mechanism would be desirable to enhance the communication efficiency between the client and RIL.