WO2005086359A2

WO2005086359A2 - Wireless communication unit and method of running code therein

Info

Publication number: WO2005086359A2
Application number: PCT/EP2005/050927
Authority: WO
Inventors: Michael William Randle
Original assignee: Motorola, Inc
Priority date: 2004-03-02
Filing date: 2005-03-02
Publication date: 2005-09-15
Also published as: TW200610333A; WO2005086359A3; GB2411742A; TWI413387B; GB0404556D0

Abstract

A method of running software code (700, 800) in a wireless communication unit comprises receiving a request (705, 805) to perform a function in one or more simple commands from a client application and interpreting data content of the one or more simple commands. A virtual serial data stream interface identifies (715, 815) a communications server that is required for managing the received one or more simple commands and passing the one or more simple commands thereto; and performs (720, 820) a function in response to the data content of the one or more simple commands. A wireless communication unit is also described. In the context of telephony sub-system code for a mobile phony', the provision of a more complex virtual serial data stream interface enables the code to be portable from one hardware platform to another.

Description

WIRELESS COMMUNICATION UNIT AND METHOD OF RUNNING CODE THEREIN

Field of the Invention

This invention relates to running software in a wireless communication unit. The invention is applicable to, but not limited to, a mechanism to allow software components, such as application code in an embedded system, to access hardware resources of the wireless communication unit via a simple command interface.

Background of the Invention

In the field of this invention it is known for devices, such as wireless communication units, to comprise an Operating System (OS) . Increasingly, with devices such as Smartphones and the like, the OS of the device is a common operating system, for example that has been developed by or in conjunction with one manufacturer, and licensed to a plurality of other, original equipment manufacturers (OEMs) or the like. Each manufacturer designs and manufactures one or more hardware platforms on which the OS runs, and also writes hardware-dependent software, which interfaces between the common OS and the specific hardware platform (s).

In particular, on some cellular phones, such as phones compliant with the Global System for Mobile communication (GSM) standard, the OS and/or third party applications running on the OS have been written to configure and/or control functions of the cellular phone by use of simple command interfaces, such as the Hayes AT command interface, where AT' stands for attention. The GSM technical specification 07.07 defines the AT command set for GSM Mobile Equipment.

FIG. 1 illustrates an example of a functional software- based block diagram indicating a known flow of commands 100 in a wireless communication unit using such an OS. The OS comprises a service provider 110 and a serial data stream interface 120 that implements the software interface to hardware components 140.

Client applications 130 running on the OS are able to access functionality provided by hardware components 140 of the device via the service provider 110 of the OS. The client application 130 sends requests to a client side application programming interface (API) (not shown) of the service provider 110. The client side API preferably defines a core set of functions that are expected to be supported by all OEM hardware platforms .

The service provider 110 calls an appropriate dynamically linked library (DLL) 150, and passes the requests received from the client application 130 thereto. The DLL 150 translates the requests into a serial data stream containing, for example, AT commands, and sends the data stream to the serial data stream interface 120'.

The serial data stream interface 120 simply acts as a conduit, through which the data stream passes to an appropriate hardware component 140, or the like. The hardware component 140 receives the data stream, and provides the required functionality, depending on the AT commands received. Responses to commands and unsolicited notifications are sent by the hardware component 140 in the form of a serial data stream via the serial data stream interface 120 to the DLL 150. The DLL 150 then converts the received data stream into the required format for the client applications 130 and returns the information thereto, via the service provider 110.

As previously mentioned, devices such as mobile phones are increasingly making use of common operating system plat orms . Significantly, this results in a range of hardware platforms from a range of OEMs using the same OS . In a system where particular functions are provided by specific software components, this may result in a logical gap between the required functionality of the software components and the actual functionality of the hardware that they are designed to control.

For the example illustrated in«-FIG. 1, the OS, and in particular the service providers 110, DLL 150, and serial data stream interface 120, are written with a particular method of accessing the various hardware components 140 in mind, necessarily the particular hardware platform (s) of the manufacturer by which, or in conjunction with which, the OS has been developed. For example, the requests from the client applications are converted by the DLL 150 into AT commands, which are conveyed as a serial data stream from the DLL 150 to the hardware component 140 via the serial data stream interface 120.

However, the different hardware platforms provided by the different OEMs are configured/controlled in different ways, using different commands etc. Even different platforms from the same OEM will make use of differing hardware resources and the components that control those hardware resources will also differ, and thus will also be configured/ controlled in different ways . Consequently, and problematically for the mobile phone developer, the OS is required to be adapted for use with each hardware platform.

In particular, some hardware functions may be expected to be provided by a particular hardware component, such as the modem (not shown) , but a particular OEM may have implemented them as part of some other component. In these cases the AT commands that have been used in the original implementation of the OS, and conveyed by way of a serial data stream may not be suitable for configuring and/or controlling these other hardware components of OEM platforms .

FIG. 2 illustrates >a more specific example of a functional software-based block diagram indicating a known flow of commands 200 in a wireless communication unit using the Symbian™ Operating System. The OS comprises a service provider in the form of a telephony (ETel) server 210, and a serial data stream interface in the form of a communications sub-system (CSY) 220 that implements the software interface to hardware components 240.

The CSY 220 is, in fact, provided by a dynamically linked library (DLL) that is called by a communications server 260, the CSY 220 being associated with one or more specific hardware components 240. Client applications 230 running on the OS are able to access functionality provided by hardware components of the device via the ETel server 210 of the OS. The client application 230 sends requests to a client side application programming interface (API) (not shown) of the ETel server 210.

The ETel server 210 calls a dynamically linked library in the form of a telephony sub-system (TSY) module 250, and passes the requests received from the client application 230 thereto. The TSY 250 translates the requests into a serial data stream containing AT commands, and sends the data stream to the communication server 260.

On receiving the data stream, the communication server 260 calls the required CSY 220, which simply acts as a conduit through which the data stream passes to an appropriate hardware component 240, or the like. The hardware component 240 receives the data stream, and provides the required functionality, depending on the AT commands received.

The Symbian OS is substantially a generic OS intended to be used on a range of different hardware platforms from a range of different OEMs . The Symbian OS has been designed with the intention of, in particular, telephony functionality being configured/ controlled via the ETel Server 210 and communication server 260. Requests and the like received from client applications 230 are converted by the TSY module 250 into a serial data stream of AT commands, and conveyed via the communications server 260 and CSY 220 to the relevant hardware component 240. However, not all hardware platforms will implement all expected functionality, such that it is able to be configured/ controlled by way of AT commands . Thus it is necessary for the Symbian OS to be modified in order for it to be able to configure/ control such functionality.

A traditional method of overcoming this problem is illustrated in FIG. 3. In this known implementation, the DLL 350 has been adapted by the OEM to convert the requests received from the client applications 130 into a required format, depending on the functionality required

(and thereby the hardware component responsible) . In particular, the DLL has had to be expanded, and include more complex functionality, to convert requests not only into AT commands, but also into other formats. These requests are passed to appropriate command handlers, for example the serial data stream interface 120, a platform server 310, device drivers 320 or a kernel 330, depending on the particular hardware component 140, 340 to which the request is directed.

Thus, for those hardware components 140 where AT commands are appropriate, the requests (and responses) are routed through the serial data steam interface 120. However, for hardware components 340 where AT commands are not appropriate, the DLL 350 has been adapted to pass the requests to (and receive responses from) the necessary command handler.

For the more specific example illustrated in FIG. 2, the TSY module 250 would be adapted to pass requests/ responses to the necessary command handler. The inventor of the present invention has identified a problem with this method, in that the DLL 350 comprises relatively complicated portions of code. Thus, for each hardware platform that an OEM develops, it is necessary to adapt the DLL 350, as well as to maintain the code for each platform.

It is also common practice to have a module, such as the Symbian™ TSY, developed by a third party. In such a case it may not be appropriate to provide the third party with an API specification for some OEM specific software components. Hence, it would be easier for the third party developer to encapsulate the functionality of those OEM components in a suitable command interface.

The problems described above impede an OEM' s ability to make use of code having a generic structure, thereby making it more difficult to reuse the same code on a different hardware platform.

Thus, there exists a need for an improved and simplified mechanism for software components to be able to readily and easily access and/or control hardware resources in a communication unit, wherein the abovementioned disadvantages may be alleviated.

Statement of Invention

In accordance with a first aspect of the present invention, there is provided a method of running software code in a communication unit . The method of running software code in a wireless communication unit comprises the step of receiving a request to perform a function in one or more simple commands from a client application of the wireless communication unit at a communications server. The method further comprises the steps of interpreting data content of the one or more simple commands; identifying a virtual serial data stream interface, by the communications server, that is required for managing the received one or more simple commands and passing the one or more simple commands thereto; and performing a function by the virtual serial data stream interface in response to the data content of the one or more simple commands .

In accordance with a second aspect of the present invention, there is provided a wireless communication unit. The wireless communication unit comprises an embedded software system running software code, such as application code to access hardware resources of the wireless communication unit via a simple command interface, and a communication servers* receiving one or more simple commands. The wireless communication unit is characterised by a virtual serial data stream interface of, or operably coupled to, the communication server and configured to perform a function in response to data content of the received one or more simple commands.

Thus, unlike traditional serial data stream interfaces, such as the traditional CSY function, the serial data steam interface of the present invention, comprises a virtual CSY function that does not simply act as a conduit through which data passes. The serial data stream interface of the present invention reads and/or otherwise interprets data passing therethrough, and acts accordingly. For example, depending on the data passing therethrough, the serial data stream interface of the present invention may decode the received data in the form of one or more simple commands and translate the commands into corresponding application instructions, such as API calls for the required hardware component .

Alternatively, the serial data stream interface of the present invention may intercept and monitor the received data in the form of one or more simple commands . The monitoring of the data may include keeping a record of some/all of the data passing through. On identifying predefined data, the serial data stream interface intercepts the data, and performs a function. For example, the serial data stream interface may block further data passing therethrough, and may provide pseudo responses to the source of the data, hiding the fact that data is blocked. The serial data stream may also send alternative data to the hardware component, for example data previously sent that has been stored.

In this manner, for example when the application code is telephony sub-system based code, the preferred embodiment of the present invention proposes a mechanism to allow telephony sub-system code to access or control hardware resources through a simple command interface. Thus, a consistent interface may be maintained allowing flexibility when porting telephony sub-system application code as well as other application codes between phone platforms .

Further aspects of the present invention are provided in the dependent Claims . Brief Description of the Drawings

FIG. 1 illustrates an example of a functional software- based block diagram indicating a known flow of commands in a wireless communication unit;

FIG. 2 illustrates a more specific example of a known functional software-based block diagram indicating a known flow of commands in a wireless communication unit, using the Symbian™ Operating System; and

FIG. 3 illustrates a further example of a known functional software-based block diagram indicating a known flow of commands in a wireless communication unit.

Exemplary embodiments of the present invention will now be described, with reference to the accompanying drawings, in which:

FIG. 4 illustrates an example of a functional software- based block diagram indicating a flow of commands in a wireless communication unit;

FIG. 5 illustrates a hardware-based block diagram of a wireless communication unit capable of being adapted in accordance with the preferred embodiments of the present invention;

FIG. 6 illustrates a functional software-based block diagram indicating a preferred flow of commands via a telephony (ETel) server, in accordance with a preferred embodiment of the present invention; FIG. 7 illustrates a flowchart of a command interpretation and translation process, in accordance with a preferred embodiment of the present invention; and

FIG. 8 illustrates a flowchart of a command interception and translation process, in accordance with an alternative embodiment of the present invention.

Description of Preferred Embodiments

Referring to now FIG. 4, the preferred embodiment of the present invention is described with reference to a generic operating system (OS) . In the OS, telephony functionality is provided by a service provider 410. This uses plug-in' components, implemented as Dynamic Link Libraries (DLLs) 450. A DLL 450 is normally supplied by the OS provider, but which requires adaptation as previously mentioned by the Original Equipment Manufacturer (OEM) to provide '^ the logic necessary to translate between, for example, the C++ function calls made by the client application software 430 and whatever interface is supported by the hardware component 440 (for example an AT command stream) . The interface between the DLL 450 and the hardware component 440 is provided by a serial data stream interface 420, which has been adapted in keeping with the present invention.

In accordance with the preferred embodiment of the present invention, an OEM is provided with the ability to develop a serial data stream interface 420 that has a standard interface with the DLL 450. Thus, to the DLL 450, the serial data stream interface 420 appears the same as any other serial data interface. The serial data interface 420 is configured to receive commands/requests to certain hardware components 440 and translate them into a simple command string format that is understandable by one or more hardware resources, such as the appropriate server 460, driver 470 and kernel 480 calls .

It is envisaged that the information to be retrieved by the application code may be any of a plethora of, for example, phone function information, such as back-light indications, battery level information, received signal strength indications, etc. The serial data stream interface 420 then uses the returned values to build suitable responses to pass back to the DLL 450.

In this manner, the DLL 450 is able to make its requests to the serial data stream interface 420 by way of simple AT commands and receive its re^'sponses in the expected simple AT command manner whilst remaining unaffected by and unconcerned with, the respective particular implementation.

Referring now to FIG. 5, a hardware-based block diagram of a wireless communication unit '500, adapted to support the inventive concepts of the preferred embodiments of the present invention, is shown. Generally, as known in the art, the wireless communication unit 500 contains an antenna 502 preferably coupled to a duplex filter or antenna switch 504 that provides isolation between receive and transmit chains within wireless communication unit 500. The receiver chain includes receiver front-end circuitry 506 (effectively providing reception, filtering and intermediate or base-band frequency conversion. The front-end circuit 506 is serially coupled to a general signal processing function 508 via a baseband (back-end) processing circuit 507.

The general signal processing function 508 in the preferred embodiment is a dual-processor arrangement, which comprises a first processor 540 (forming a part of a first processor system (not shown) ) and a second processor 550 (forming part of a second processor system (not shown) ) . Furthermore, the general signal processing function 508 comprises a co-processor interface (not shown) , providing a means of direct communication between the two processors 540, 550.

In the preferred embodiment of a mobile phone, the first processor system is responsible for controlling communication with a network to which the mobile communications device is^connected, for example handling a protocol stack and signal processing. Furthermore, the first processor system preferably controls, or accesses information from, components (not shown) such as a radio frequency (RF) module, baseband/audio CODEC, battery manager, subscriber identification module (SIM) card reader, etc. In this ' context, the second processor system is designed to be responsible for running a man- machine interface (MMI) and controlling a display, keypad, universal serial bus (USB) and/or IrDA interfaces etc.

For the illustrated embodiment, the mobile communication unit 500 is compatible with the Global System for Mobile (GSM) Communication standards. Thus, in use the first processor 540 has running thereon the necessary software 542 for controlling RF circuitry etc., for operating with a GSM network via a modem. Such software includes layer- 1 and GSM protocol software. The second processor 550, in use, has running thereon a man-machine interface, and a radio interface layer, through which the MMI software, and any other software (not shown) running on the second processor 550, can send and receive commands to/from the GSM software 542 running on the first processor 540.

A controller 514 is operably coupled to the front-end circuitry 506 so that the receiver can calculate receive bit-error-rate (BER) or frame-error-rate (FER) or similar link-quality measurement data from recovered information, which may also incorporate a received signal strength indication (RSSI) 512 function. The RSSI function 512 is operably coupled to the front-end circuit 506. The memory device 516 stores a wide array of device-specific data, for example decoding/encoding functions, frequency and timing information, etc. for the wireless communication unit 500.

A timer 518 is operably coupled to the controller 514 to control the timing of operations, namely the transmission or reception of time-dependent signals, within the wireless communication unit 500. As known in the art, received signals that are processed by the signal processing function are typically input to an output device, such as a speaker or display.

The transmit chain essentially includes an input device 520, such as a microphone, coupled in series through a general signal processor function 508, transmitter/modulation circuitry 522 and a power amplifier 524. The general signal processor function 508, transmitter/modulation circuitry 522 and the power amplifier 524 are operationally responsive to the controller, with an output from the power amplifier coupled to the duplex filter or antenna switch 504, as known in the art.

Thus, in accordance with the preferred embodiment of the present invention, a wireless communication unit such as a mobile phone 500 comprises an embedded software system running software code, such as application code to access hardware resources of the wireless communication unit via a simple command interface. The mobile phone 500 comprises a processor, in the form of a communication server receiving one or more simple commands, such as AT commands. A virtual serial data stream interface, as further described below, is located within, or operably coupiied to, the communication server and configured to perform a function in response to data content of the received one or more simple commands .

Of course, the various components within the wireless communication unit 500 may be realised in discrete or integrated component form. Furthermore, it is within the contemplation of the invention that the wireless communication unit 500 may be any wireless communication unit, such as a portable or private mobile radio (PMR) , a mobile phone, a personal digital assistant, a wireless laptop computer, etc. More generally, any re-programming or adaptation of the general signal processor function 508, or the respective one or more processors contained therein, according to the preferred embodiment of the present invention, may be implemented in any suitable manner. For example, a new general signal processor function 508 (or individual processors) or memory device 516 may be added to a conventional wireless communication unit 500. Alternatively, existing parts of a conventional wireless communication unit may be adapted, for example by reprogramming one or more processors therein. As such the required adaptation may be implemented in the form of processor-implementable instructions stored on a storage medium, such as a floppy disk, hard disk, programmable read-only memory (PROM) , random access memory (RAM) or any combination of these or other storage media.

Referring now to FIG. 6, a further embodiment of the present invention is described with reference to a Smartphone that employs a Symbian™ operating system (OS) .

A functional software-based' diagram 600 is shown indicating the preferred flow of commands via a telephony (ETel) server 610, in accordance with the preferred embodiment of the present invention. The ETel server 610 comprises a telephony sub-system (TSY) module 650, for which it is envisaged that TSY code can be written by an original equipment manufacturer (OEM) to allow client applications 630 to directly access hardware resources of the mobile phone.

The TSY module 650 sends commands/requests, such as simple AT commands to a communication server 620. The communication server 620 routes these commands to a CSY function 625, which then routes them to hardware modem component 640, for example over a standard serial connection or via co-processor shared memory interface (CSMI) (not shown), for handling in the normal manner. The CSY functions 640 then passes any returned responses back to the TSY module 650.

However, in contrast to the known technique of accessing those hardware component 645 where simple AT commands are not suitable for passing directly through device drivers

670, kernel extensions 680 and other servers 660, access to the hardware components 645 is performed by a

*virtual' CSY function 628. In this regard, the TSY module 650 sends commands/requests, such as simple AT commands to the communication server 620 in the normal manner. The communication server 620 routes these commands to the virtual CSY function 628, which converts the AT commands into an appropriate format, such as API calls. The virtual CSY function 628 then routes these converted API calls ^(,to device drivers 670, kernel extensions 680 and other platform servers 660 for handling in the normal manner. The virtual CSY function 628 then uses any returned values from the hardware components 645 to build suitable AT command responses to pass back to the TSY module 650.

In this manner, the TSY module 650 is able to make its requests to the virtual CSY function 628 by way of normal simple command (AT) strings, which are translated and re- formatted into API commands for passing to the respective hardware component 645. In the reverse direction, the virtual CSY function 628 translates the returned API command format into simple command (AT) strings suitable for the TSY module 650. Thus, the TSY module 650 receives its responses in the expected manner whilst remaining unaffected by, and unconcerned with, the respective particular implementation.

Thus, in the preferred embodiment of the present invention, the virtual CSY function 628 maps between a simple command set, such as AT commands, and one or more complex application programming interface codes . Advantageously, there is no need for the TSY module 650 to support API calls direct. The portability benefits for the API accessing process between different mobile phone platforms comes at a slight cost to the OEM, who now has to develop a non-standard CSY, with AT command interpreter. However, the virtual CSY function 628 comprises much simpler portions of code than the TSY module 650.

Thus, the OEM adaptations etc. are kept within the smaller, simpler CSY function, and may be changed with-out the TSY module needing to be changed. In this way, adapting and maintaining the operating system code for a plurality of hardware platforms is much simpler, and a generic TSY module can be used without the need for platform specific customisation.

Where hardware components 640 are required to be accessed by way of simple AT commands, or other serial data streams, access to the hardware components 640 may also be performed by the virtual CSY function 628. In this regard, the TSY module 650 sends commands/requests, such as simple AT commands to the communication server 620 in the normal manner. The communication server 620 routes these commands to the virtual CSY function 628. The virtual CSY function 628 then routes the serial data stream containing the AT commands to the required hardware component 640 for handling in the normal manner.

Alternatively, and/or additionally, access to these hardware components 640 may be performed by a traditional CSY function 625. In this regard, the TSY module 650 sends commands/requests, such as simple AT commands to the communication server 620 in the normal manner. The communication server 620 routes these commands to the traditional CSY function 625. The traditional CSY function 625 then routes the serial data stream containing the AT commands to the required hardware component 640 for handling in the normal manner.

Unlike traditional serial data stream interfaces, such as the traditional CSY function 625, the serial data steam interface of the present invention, in particular the 'virtual CSY function 628, does not simply act as a conduit through which data passes.

The virtual serial data stream interface of the present invention reads and/or otherwise interprets data passing therethrough, preferably in the form of one or more simple commands . The virtual serial data stream interface then acts accordingly and performs a function in response to the data content of the one or more simple commands. For example, depending on the data passing therethrough, the serial data stream interface of the present invention may convert the received data into appropriate API calls for the required hardware component . In an alternative embodiment, the serial data stream interface intercepts and monitors the data passing therethrough. The monitoring of the data may include keeping a record of some/all of the data passing through. On identifying predefined data, the serial data stream interface intercepts the data, and performs a function. For example, the serial data stream interface may block further data passing therethrough, and may provide pseudo responses to the source of the data, hiding the fact that data is blocked. The serial data stream may also send alternative data to the hardware component, for example data previously sent that has been stored.

As will be appreciated, the serial data stream interface is required to have a predefined awareness of the data it receives. For example, in the case where the serial data stream interface monitors the data until it identifies certain data (e.g. certain commands or responses), the serial data stream interface Mil previously have been provided with a definition of what data to look out for.

Referring now to FIG. 7, a flowchart 700 is shown illustrating a preferred command interpretation process, in accordance with a preferred embodiment of the present invention. A client application sends a request to a service provider, such as a telephony server, for a required function to be performed, as shown in step 705. The telephony server calls a DLL, such as a TSY module, which converts the request into one or more simple commands, such as AT commands, and passes them to, for example, a communications server, in step 710. The communications server identifies a serial data stream interface, which in the preferred embodiment takes the form of a CSY function, which is required for managing the received command (s) . In accordance with the preferred embodiment of the present invention, for commands that are not suitable for passing directly through to device drivers etc., the communications server identifies a virtual serial data stream interface, or CSY function, as being the appropriate function for the particular command (s) received, and passes the AT command(s) thereto, as shown in step 715.

The virtual CSY function translates the AT command (s) into appropriate API calls and routes the API calls to identified hardware command handlers, as shown in step 720.

The hardware command handlers return appropriate results to the virtual CSY function, as in step 725. The virtual CSY function translates the results into one or more AT responses and sends them back to the TSY module, as shown in step 730.

In step 735, The TSY module parses the AT command (s) and generates any suitable results for the telephony server to pass back to the client. In this manner, information is sent to, and retrieved from, one or more hardware resources within the wireless communication unit in an efficient manner.

Referring now to FIG. 8, a flowchart 800 is shown illustrating a preferred command interpretation process, in accordance with a further embodiment of the present invention. A client application sends a request to a telephony server for a required telephony function to be performed, as shown in step 805. The telephony server calls the TSY module, which converts the request into one or more AT commands and passes them to the communications server, in step 810.

The communications server identifies a CSY function that is required for managing the received command(s) . In accordance with the present invention, for commands that may or may not be suitable for passing directly through device drivers etc, the communications server identifies a virtual CSY function as being the appropriate function for the particular command (s) received, and passes the AT command(s) thereto, as shown in step 815.

The virtual CSY function monitors the AT command (s), and identifies a predefined command, as shown in step 820, when such a command is received.

On receiving and identifying the predefined command, the virtual CSY intercepts all further commands, and performs a specific function, as in step 825. On completion of the specific function, the virtual CSY resumes the passing of AT commands therethrough, as in step 830.

It is envisaged that the specific function may, for example, provide pseudo responses to client applications attempting to access the hardware resource, to hide the fact that the commands are being intercepted. Furthermore, the virtual CSY function may have stored commands previously sent to the hardware resource, which it resends to the hardware resource. Although the preferred embodiments of the present invention have been described with reference to a dual- processor arrangement with commands routed between the two processors, it is envisaged that the inventive concepts can be equally applied in a single processor scenario. In effect, in such a single processor scenario, the processor can perform the interception and re-formatting of commands received from any inquiry device and passes them on to the respective hardware function, and in particular one that makes use of serial data stream interfaces .

Although the preferred embodiment of the present invention has been described with reference to a wireless communication unit, such as a mobile phone employing a Symbian operating system for those components, which use AT commands to access non-modem hardware resources, it is envisaged that the inventive concepts are equally applicable to any embedded system which uses such a method for controlling hardware resources .

Although the present invention has been described with reference to interpretation and translation of simple AT commands to access non-modem hardware resources, it is envisaged that the inventive concepts are equally applicable to any other relatively simple commands, for example layer-1 commands of the well-known OSI protocol stack, which are transferred via serial data interfaces.

It will be understood that the mechanisms described above, which propose a virtual CSY function that allows a TSY module to access a hardware resource through a simple AT command, tends to provide at least one or more of the following advantages : (i) A generic TSY module can be used with no platform specific customisation. (ii) All OEM adaptations are kept in the smaller, simpler CSY component and may be changed without the TSY needing to change. (iii) The more complex TSY code is then portable from one hardware platform to another. Thus, by using the aforementioned virtual CSY concept, substantial additional functionality can be obtained using a slightly modified command routeing process. (iv) The preferred mechanism can be used to support a consistent and uniform software interface through AT commands to varied and diverse hardware resources. Thus, a single simple established API to the telephony server is the only interface required to access a wide range of functions, which would otherwise need to have multiple, implementation specific APIs.

Whilst specific, and preferred, implementations of the present invention are described above, it is clear that one skilled in the art could readily apply further variations and modi ications of such inventive concepts .

Thus, a wireless communication unit and method of running software code to obtain hardware resource information in the wireless communication unit have been provided that tend to alleviate, for example, the known problems associated with using APIs to access radio hardware resources .

Claims

1. A method of running software code (700, 800) in a wireless communication unit comprising the step of: receiving a request (705, 805) to perform a function in one or more simple commands from a client application of the wireless communication unit at a communications server; wherein the method is characterised by the steps of: interpreting data content of the one or more simple commands; identifying (715, 815) a virtual serial data stream interface, by the communications server, that is required for managing the received one or more simple commands and passing the one or more simple commands thereto; and performing (720, 820) a function by the virtual serial data stream interface in response to the data content of the one or more simple commands .

2. A method of running software code (700, 800) according to Claim 1, wherein the step of performing (720) a function comprises the steps of: decoding the one or more simple commands to identify one or more hardware command handlers; translating (720) the one or more simple commands into application instructions, for example application programming interface (API) calls; and routeing (720) the application instructions to the one or more identified hardware command handlers.

3. A method of running software code (700, 800) according to Claim 2 further characterised by the step of returning (725) one or more responses, by the one or more hardware command handlers to the virtual serial data stream interface.

4. A method of running software code (700, 800) according to Claim 3 further characterised by the step of translating (730) the one or more responses into one or more simple responses by the virtual serial data stream interface .

5. A method of running software code (700, 800) according to Claim 4 further characterised by the step of sending (730) the one or more simple responses to the service provider.

6. A method of running software code (700, 800) according to Claim 5 further characterised by the step of parsing the one or more simple responses by the service provider to generate one or more response to return to the client application.

7. A method of running software code (700, 800) according to Claim 6 further characterised in that the step of parsing is performed by a dynamic linked library of the service provider.

8. A method of running software code (700, 800) according to any preceding Claim further characterised in that the step of receiving comprises converting the request into one or more simple commands by a dynamic linked library of the service provider.

9. A method of running software code (700, 800) according to Claim 1, wherein the step of performing (820) a function comprises the steps of: identifying a predefined command from the one or more simple commands; intercepting (825) subsequent one or more simple commands; and performing (720, 820) a function in response to the data content of the intercepted commands .

10. A method of running software code (700, 800) according to Claim 9, wherein the method is further characterised by the step of: passing (830) the one or more simple commands through the virtual serial data stream interface once the step of performing has completed.

11. A method of running software code (700, 800) according to any preceding Claim further characterised in that the service provider is a telephony server.

12. A method of running software code (700, 800) according to any preceding Claim further characterised in that the service provider comprises a dynamic linked library (DLL) , such as a telephony sub-system (TSY) module .

13. A method of running software code (700, 800) according to any preceding Claim further characterised in that the one or more simple commands are AT commands .

14. A wireless communication unit (500) comprising: an embedded software system running software code, such as application code to access hardware resources of the wireless communication unit via a simple command interface, and a communication server receiving one or more simple commands; wherein the wireless communication unit (500) is characterised by: a virtual serial data stream interface (628) of, or operably coupled to, the communication server and configured to perform a function in response to data content of the received one or more simple commands .

15. A wireless communication unit (500) according to Claim 14 further characterised in that the virtual serial data stream interface (628) is configured to read or otherwise interpret data passing therethrough, and respond thereto.

16. A wireless communication unit (500) according to Claim 14 or Claim 15, further characterised in that the virtual serial data stream ^:'interface (628) is configured to decode the one or more simple commands to identify one or more hardware command handlers and translate the received one or more simple commands into application instructions, for example application programming interface (API) calls, for routeing to the identified hardware resource.

17. A wireless communication unit (500) according to any of preceding Claims 14 to 16, further characterised in that the virtual serial data stream interface (628) is configured to receive one or more responses from the one or more hardware command handlers and configured to translate the received one or more responses to one or more simple commands to pass to the application code, for example via a telephone sub-system (TSY) module (650) .

18. A wireless communication unit (500) according to any of preceding Claims 14 to 17, further characterised in that the one or more hardware resources comprise one or more of: a server (460) , a driver (470) a kernel (480) .

19. A wireless communication unit (500) according to any of preceding Claims 14 to 18, further characterised in that the one or more hardware resources provide phone function information to be returned to the application code, such as: back-light indications, battery level information, received signal strength indications.

20. A wireless communication unit (500) according to Claim 14 or Claim 15 further characterised in that the virtual serial data stream interface (628) is configured to intercept the data passing therethrough and perform a function in response to the intercepted data content.

21. A wireless communication unit (500) according to Claim 20, further characterised in that the virtual serial data stream interface (628) is configured to block further data passing therethrough,

22. A wireless communication unit (500) according to Claim 21 further characterised in that the virtual serial data stream interface (628) is configured to provide pseudo responses to the source of the data thereby hiding the fact that data is blocked.

23. A wireless communication unit (500) according to any of preceding Claims 20 to 22, further characterised in that the virtual serial data stream interface (628) is configured to send alternative data to the hardware component, for example data previously sent that has been stored.

24. A wireless communication unit (500) according to any of preceding Claims 14 to 23 further characterised in that the virtual serial data stream (628) interface is located within, or operably coupled to, a service provider.

25. A wireless communication unit (500) according to Claim 24, further characterised in that the service provider is a telephony server (610) comprises a telephony sub-system (TSY) module (650) operably coupled to a communication server (620) .