DE60214059T2

DE60214059T2 - Verfahren und Funkschnittstellenschicht bestehend aus einer Menge von Anwendungsprogrammierungsschnittstellen (APIs)

Info

Publication number: DE60214059T2
Application number: DE60214059T
Authority: DE
Inventors: Scott R. Shell; Roman Sherman; Alan W. Shen
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2001-02-16
Filing date: 2002-02-15
Publication date: 2006-12-07
Anticipated expiration: 2022-02-16
Also published as: US6826762B2; EP1233343A3; EP1233343B1; US20020184407A1; DE60214059D1; EP1233343A2; ATE337584T1

Description

Gebiet der Technik
Die Erfindung betrifft im Allgemeinen Anwendungsprogrammierungsschnittstellen (APIs [Application Programming Interfaces]), und im Besonderen betrifft die vorliegende Erfindung eine Funkschnittstellenschicht, die einen Satz von APIs umfasst.
Hintergrund der Erfindung
Zellulartelefone finden in der heutigen Zeit breite Anwendung. Da Benutzer immer vertrauter im Umgang mit Zellulartelefonen werden, fragen sie auch immer anspruchsvollere Verwendungsmöglichkeiten von Telefonen nach. Wenn es nach den Benutzern ginge, sollten ihre Zellulartelefone idealerweise dieselben Funktionen wie ihre Personalcomputer oder Handheld-PDAs durchführen. Um derartige Anwendungen in eine Zellulartelefonumgebung zu implementieren, müssen Anwendungsentwickler ihre Software zur Verwendung in einem Zellulartelefon entwickeln oder anpassen. Das Anpassen oder Entwickeln von Software zur Verwendung in einem Zellulartelefon eines OEMs (Original Equipment Manufacturer [Originalteilehersteller]) ist jedoch nicht notwendigerweise ein Garant dafür, dass die Softwareanwendung auf dem Zellulartelefon eines anderen Herstellers funktioniert, und zwar aufgrund der verschiedenen Funkhardwareimplementierungen der verschiedenen OEMs und aufgrund der Unterschiede bezüglich der verschiedenen Zellularumgebungen.
Um eine Softwarelösung zu konzipieren, die an mehrere unterschiedliche zellulare Systeme und Funkhardware angepasst werden kann, besteht die Notwendigkeit einer gewissen Art von Hardwareanpassungsschicht, das heißt, einer Schicht, die die Besonderheiten eines bestimmten zellularen Systems/einer bestimmten Hardware von dem Großteil des Softwaresystems isoliert. Des Weiteren besteht die Notwendigkeit einer vordefinierten Schnittstelle, die von den Softwarekomponenten verwendet wird. Darüber hinaus besteht die Notwendigkeit, dass es die Schicht den Hardwareherstellern ermögli chen sollte, die Implementierung der Hardwareschnittstelle zu ersetzen/zu modifizieren, um ihre spezifische Hardware anzupassen.
Eine derartige Schicht (TAPI) existiert bereits für die Verwendung bei der Entwicklung eines allgemeinen Telefoniesystems. Die TAPI hat jedoch zwei Nachteile, die die Verwendung in einer zellularen Umgebung erschweren: eine erhebliche Menge zellularspezifischer Funktionalität wird nicht durch die TAPI-Schnittstelle bereitgestellt, und es ist ziemlich schwierig, TAPI-Dienstanbieter (TSPs (TAPI Service Providers]) zu implementieren, wodurch es problematisch ist, das Softwaresystem an unterschiedliche Hardwaretypen anzupassen. Aus diesem Grund besteht die Notwendigkeit einer neuen Hardwareanpassungsschicht, die insbesondere besser an die zellulare Umgebung angepasst werden kann und die die Aufgabe erleichtert, die Schicht an unterschiedliche Hardwaretypen anzupassen.
EP 0 994 614 A2 betrifft eine Funkkommunikationsvorrichtung, die über ein Benutzeranwendungsprogramm, ein Telefonieprogramm und über eine Anwendungsprogrammierungsschnittstelle (API) zwischen diesen beiden Programmen verfügt. Die beschriebene Technik befasst sich mit Problemen, die sich auf die Art und Weise der Verwendung des JTAPIs als ein Telefonie-API für eine drahtlose Kommunikationsvorrichtung beziehen, und im Besonderen als ein Telefonie-API für ein GSM- (Global System for Mobile) Funktelefon. Wenn die Anwendung versucht, einen Aufruf zu initiieren, ruft sie eine Methode Provider.createCall durch einen Befehl Provider.createCall () über das API auf. Wenn sich die Vorrichtung nicht in dem Abschaltmodus befindet, wird ein Aufruf-Objekt (Call Object) erzeugt. Anschließend ruft die Anwendung eine Methode Call.connect durch einen Befehl Call.connect () über das API auf. Wenn die Kommunikationsvorrichtung einen Dienst mit einem Funkkommunikationsnetz aufgebaut hat, wird ein Befehl über die serielle Schnittstelle an die Sende-Empfangsvorrichtung gesendet, um einen Aufruf anzumelden.
WO 96/06393 A1 betrifft ein API, das eine oder mehrere Anwendungen mit einer oder mehreren Medienwechselvorrichtungen verbindet. Das API kommuniziert mit der nächst folgenden Schicht der Architektur, die eine E/A-Verwaltungsvorrichtung eines gegebenen Betriebssystems ist, über eine Leitung, die API-IOCTLs überträgt.
Zusammenfassung der Erfindung
Es ist die Aufgabe der vorliegenden Erfindung, es den Anwendungen innerhalb einer Funkkommunikationsvorrichtung zu ermöglichen, mit der Telefoniefunkhardware auf eine solche Art und Weise zu kommunizieren, so dass die Anwendungen vollständig unabhängig von der Telefoniefunkhardware oder einem Zellularnetz programmiert werden können.
Diese Aufgabe wird durch die Erfindung, wie in den unabhängigen Ansprüchen definiert, erfüllt. Ausführungsbeispiele der Erfindung sind in den abhängigen Ansprüchen aufgeführt.
Entsprechend einem Ausführungsbeispiel werden die vorangehend beschriebenen Bedürfnissee durch das Bereitstellen einer Funkschnittstellenschicht (RIL [Radio Interface Layer]), die ein Satz von APIs ist, der eine Abstraktionsebene zwischen der Funkhardware in einem Zellulartelefon und der Software des Zellulartelefons bereitstellt, erfüllt. Der Satz von APIs der RIL kann, wie in den GSM-Spezifikationen 07.05 und 07.07 definiert, im Großen und Ganzen auf der GSM-AT-Schnittstelle basieren. Der Satz von APIs kann Zugriff auf die Funktionalität, die in einem Zellulartelefon, wie beispielsweise einem GSM- oder CDMA-kompatiblen Telefon, enthalten ist, gewähren. Das Ausführungsbeispiel ermöglicht den Anwendungen, die auf einem Betriebssystem in einem Zellulartelefon laufen, Befehle ohne die Kenntnis über die zugrunde liegende Funkstruktur des Zellulartelefons und ohne die spezifische Kenntnis der GSM-Typ-Befehle zu erteilen. Beispielsweise ermöglicht das Ausführungsbeispiel den Anwendungen auf Telefonbucheinträge zuzugreifen, den Zugang zu Daten und der Funktionalität unter Verwendung von Passwörtern zu beschränken, auf den Datei- und Nachrichtenspeicher zuzugreifen und viele weitere Funktionen durchzuführen. Die RIL kann in eine hardwareunabhängige Proxyschicht, die von verschiedenen Softwarekomponenten aufgerufen wird, und eine hardwarespezifische Treiberschicht eingeteilt werden. Es wird darauf hingewiesen, dass ein OEM die Treiberschicht durch die eigene für seine Hardware implementationspezifische Schicht ersetzen kann.
Aus der folgenden ausführlichen Beschreibung der exemplarischen Ausführungsbeispiele und aus den angehängten Zeichnungen und Ansprüchen wird ersichtlich, dass die Er findung die Probleme des Standes der Technik löst und die oben beschriebenen Vorteile erzielt.
Kurze Beschreibung der Figuren
1 ist ein Blockdiagramm eines exemplarischen Personalcomputersystems.
2 ist ein Blockdiagramm, das ein exemplarisches Ausführungsbeispiel einer RIL in einem Telefon in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
3 ist ein Ablaufplan, der ein Verfahren zum Verarbeiten von Befehlen unter Verwendung der Funkschnittstellenschicht (RIL) in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
4 ist ein Blockdiagramm, das ein Verfahren für eine Anwendung zum Aufbauen eines Sprachanrufs unter Verwendung der RIL in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
Ausführliche Beschreibung der Ausführungsbeispiele der Erfindung
Ein Ausführungsbeispiel der vorliegenden Erfindung wird in einem Zellulartelefon integriert, das von der Microsoft Corporation in Redmond, Washington, vertrieben wird. Das Zellulartelefon kann ein „Smartphone" sein, dass, zusätzlich zu der Bereitstellung von Telefoniediensten, verschiedene Softwareanwendungen sowie unterschiedliche Funktionen, die normalerweise den Personalcomputern oder PDAs vorbehalten sind, ausführt. Beispielsweise kann in einem Ausführungsbeispiel das Telefon als ein PIM (Personal Information Manager [Persönlicher Informationsplaner]) zum Speichern von Terminen, Kontakten, Aufgaben und so weiter verwendet werden.
Weitere Ausführungsbeispiele der vorliegenden Erfindung können in PDAs (Personal Digital Assistant [persönlicher digitaler Assistent]), Personalcomputer und tragbare Computer integriert werden. 1 und die folgende Erörterung sollen eine kurze und allgemeine Beschreibung eines exemplarischen Personalcomputersystems zur Verwen dung mit den oben beschriebenen Ausführungsbeispielen der vorliegenden Erfindung geben. Für Personen mit gewöhnlicher Erfahrung auf dem Gebiet ist es offensichtlich, dass Softwareprodukte Routinen, Programme, Komponenten, Datenstrukturen und so weiter umfassen können, die bestimmte Aufgaben ausführen oder abstrakte Datentypen implementieren. Darüber hinaus ist es für Personen mit gewöhnlicher Erfahrung auf dem Gebiet offensichtlich, dass die Erfindung mit weiteren Computersystemkonfigurationen, die Handheld-Vorrichtungen, Multiprozessorsysteme, mikroprozessorbasierte oder programmierbare Unterhaltungselektronik, Minicomputer und Großrechner und Ähnliches umfassen, ausgeführt werden kann. Die Erfindung kann des Weiteren in Umgebungen für verteiltes Rechnen (Distributed Computing) eingesetzt werden, in denen Aufgaben durch dezentrale Verarbeitungsvorrichtungen durchgeführt werden, die durch ein Kommunikationsnetz miteinander verbunden sind. In einer Umgebung für verteiltes Rechnen können Softwareprodukte sowohl in lokalen als auch in dezentralen Speichervorrichtungen speichert werden.
In Bezug auf 1 umfasst ein exemplarisches System zum Implementieren der Erfindung einen herkömmlichen Personalcomputer 20, der eine Verarbeitungseinheit 21, einen Systemspeicher 22 und einen Systembus 23, der die Verarbeitungseinheit 21 und den Systemspeicher 22 miteinander verbindet, umfasst. Der Systemspeicher 22 umfasst einen Festwertspeicher (ROM [Read Only Memory]) 24 und einen Schreib-Lese-Speicher (RAM [Random Access Memory]) 25. Ein grundlegendes Eingabe-/Ausgabe-System (BIOS [Basic Input/Output System]), das die grundlegenden Routinen enthält, die dazu dienen, die Informationen zwischen den Elementen in dem Personalcomputer 20 zu übertragen, so beispielsweise während des Hochfahrens, ist in dem ROM 24 gespeichert. Ein Video-BIOS 60 kann ebenfalls in dem ROM 24 gespeichert sein. Der Personalcomputer 20 umfasst des Weiteren ein Festplattenlaufwerk 27, ein Magnetplattenlaufwerk 28, um beispielsweise eine entnehmbare Platte 29 zu lesen oder zu beschreiben, und ein optisches Plattenlaufwerk 30, um beispielsweise eine CD-ROM 31 zu lesen oder um weitere optische Medien zu lesen oder zu beschreiben. Das Festplattenlaufwerk 27, das Magnetplattenlaufwerk 28 und das optische Plattenlaufwerk 30 sind mit dem Systembus 23 jeweils über eine Festplattenlaufwerkschnittstelle 32, eine Magnetplattenlaufwerkschnittstelle 33 und eine optische Plattenlaufwerkschnittstelle 34 verbunden. Die Laufwerke und deren dazugehörigen computerlesbaren Medien stellen einen nicht-flüchtigen Speicher für den Personalcomputer 20 bereit. Obwohl sich die Be schreibung der vorangehend genannten computerlesbaren Medien auf eine Festplatte, eine entnehmbare Magnetplatte und eine CD-ROM-Platte bezieht, sollte es für eine Person mit gewöhnlicher Erfahrung auf dem Gebiet offensichtlich sein, dass weitere von einem Computer lesbare Typen von Medien, wie beispielsweise Magnetkassetten, Flashspeicherkarten, DVDs (Digitale Video Disks), Bernoulli-Cartridges und Ähnliches, ebenfalls in der exemplarischen Betriebsumgebung verwendet werden können.
Eine Anzahl von Softwareprodukten, die ein Betriebssystem 35, ein Softwareprodukt 36, wie beispielsweise das „OFFICE XP"-Anwendungsprogrammmodulpaket von Microsoft, andere Softwareprodukte 37 sowie Programmdaten 38 umfasst, kann auf den Laufwerken und in dem RAM 25 gespeichert werden. Ein Benutzer kann Befehle und Informationen über eine Tastatur 40 und eine Zeigevorrichtung, wie beispielsweise eine Maus 42, in den Personalcomputer 20 eingeben. Weitere Eingabevorrichtungen (nicht dargestellt) können ein Mikrofon, ein Joystick, ein Gamepad, eine Satellitenschüssel, ein Scanner oder Ähnliches sein. Diese und weitere Eingabevorrichtungen sind häufig über eine serielle Anschlussschnittstelle 46, die an den Systembus angeschlossen ist, mit der Verarbeitungseinheit 21 verbunden, sie können jedoch auch über andere Schnittstellen, wie beispielsweise einen Game-Anschluss oder einen universellen seriellen Bus (USB) angeschlossen sein. Ein Monitor 47 oder andere Typen von Anzeigevorrichtungen ist ebenfalls über eine Schnittstelle, wie beispielsweise einen Videoadapter 48, mit dem Systembus 23 verbunden. Zusätzlich zu dem Monitor umfassen Personalcomputer typischerweise weitere periphere Ausgabevorrichtungen (nicht dargestellt), wie beispielsweise Lautsprecher oder Drucker.
Der Personalcomputer 20 kann in einer vernetzten Umgebung unter Verwendung von logischen Verbindungen zu einem oder mehreren dezentralen Computern, wie beispielsweise einem dezentralen Computer 49, arbeiten. Der dezentrale Computer 49 kann ein Server, ein Router, eine gleichrangige Vorrichtung oder ein anderer gemeinsamer Netzwerkknoten sein, und schließt typischerweise viele oder alle der in Bezug auf den Personalcomputer 20 beschriebenen Elemente ein, obwohl in 1 lediglich eine Speichervorrichtung 50 dargestellt wird. Die logischen Verbindungen, die in 1 dargestellt sind, umfassen ein lokales Netzwerk (LAN [Local Area Network]) 51 und ein Großraumnetzwerk (WAN [Wide Area Network]) 52. Derartige Netzwerkumgebungen finden in Büroräumen, unternehmensweiten Computernetzwerken, den Intranets und dem Internet breite Anwendung.
Der Personalcomputer 20 ist, wenn er in einer LAN-Netzwerkumgebung eingesetzt wird, über eine Netzwerkschnittstelle 53 mit dem LAN 51 verbunden. Wenn der Personalcomputer 20 in einer WAN-Netzwerkumgebung eingesetzt wird, umfasst er typischerweise ein Modem 54 oder andere Einrichtungen zum Kommunikationsaufbau über das WAN 52, wie beispielsweise das Internet. Das Modem 54, das extern oder intern sein kann, ist über die serielle Anschlussschnittstelle 46 mit dem Systembus 23 verbunden. In einer Netzwerkumgebung können Programmmodule, die in Bezug auf den Personalcomputer 20 beschrieben wurden, oder Teile davon, in einer dezentralen Speichervorrichtung gespeichert werden. Es ist offensichtlich, dass die dargestellten Netzwerkverbindungen exemplarischer Natur sind und andere Einrichtungen zum Herstellen einer Kommunikationsverbindung zwischen den Computern verwendet werden können.
Funkschnittstellenschicht
Ein Ausführungsbeispiel der vorliegenden Erfindung, das als Funkschnittstellenschicht (RIL (Radio Interface Layer]) bekannt ist, umfasst einen Satz von APIs, der eine Abstraktionsebene zwischen der Funkhardware in einem Zellulartelefon und der Software des Zellulartelefons bereitstellt. Der Satz von APIs der RIL basiert, wie in den GSM-Spezifikationen 07.05 und 07.07 definiert, auf der GSM-AT-Schnittstelle. Der Satz von APIs gewährt Zugang zu der in einem Zellulartelefon, wie beispielsweise einem GSM- oder CDMA-kompatiblen Telefon, enthaltenen Funktionalität. Die vorliegende Erfindung ermöglicht den Anwendungen, die auf einem Betriebssystem in einem Zellulartelefon laufen, Befehle ohne die Kenntnis über die zugrunde liegende Funkstruktur des Zellulartelefons und ohne die spezifische Kenntnis der GSM-Typ-Befehle zu erteilen. Beispielsweise ermöglicht die vorliegende Erfindung den Anwendungen auf Telefonbucheinträge zuzugreifen, den Zugang zu Daten und der Funktionalität unter Verwendung von Passwörtern zu beschränken, auf den Datei- und Nachrichtenspeicher zuzugreifen und viele weitere Funktionen durchzuführen.
Die RIL ist in eine hardwareunabhängige Proxyschicht, die von verschiedenen Softwarekomponenten aufgerufen wird, und eine hardwarespezifische Treiberschicht einge teilt. Es wird darauf hingewiesen, dass ein OEM (Original Equipment Manufacturer [Originalteilehersteller]) die Treiberschicht durch die eigene für dessen Hardware implementationspezifische Schicht ersetzen kann. In einem bevorzugten Ausführungsbeispiel ist die RIL eine Kernkomponente eines von der Microsoft Corporation in Redmond, Washington, vertriebenen Zellulartelefons.
RIL-Treiberschicht
In einem bevorzugten Ausführungsbeispiel wird die Funkschnittstellenschicht- (RIL) Treiberschicht verwendet, um die Befehle, wie beispielsweise AT-Befehle, die durch ETS 300 585, Digital cellular telecommunications system (Phase 2); Use of Data Terminal Equipment – Data Circuit terminating Equipment (DTE-DCE) interface for Short Messaging Service (SMS) and Cell Broadcast Service (CBS) (GSM 07.05), fünfte Ausgabe, April 1997, und ETS 300 642, Digital cellular telecommunications system (Phase2); AT command set for GSM Mobile Equipment (ME) (GSM 07.07 Version 4.4.1), vierte Ausgabe, März 1999, spezifiziert sind, zu implementieren und diesen im Großen und Ganzen zu entsprechen. Der RIL-Treiber kann selbstverständlich verwendet werden, um andere Befehlssätze, wie beispielsweise CDMA-Befehle, oder eine Kombination aus mehreren Befehlssätzen zu implementieren und diesen zu entsprechen.
OEMs können den RIL-Treiber des bevorzugten Ausführungsbeispiels verwenden oder diesen optimieren, wenn sie es vorziehen, über private APIs anstatt über AT-Befehle (höchstwahrscheinlich aus Leistungsgründen) mit ihrer Funkhardware zu kommunizieren.
Im Allgemeinen empfängt die RIL-Treiberschicht einen RIL-API-Aufruf und veranlasst die Funkeinheit (das heißt, den Empfänger/Sender des Zellulartelefons, PDAs und so weiter), die durch das RIL-API definierte Funktion durchzuführen. In einem bevorzugten Ausführungsbeispiel empfängt der RIL-Treiber den RIL-API-Aufruf von einer RIL-Proxyschicht (im Folgenden beschrieben). Die RIL-Treiberschicht verarbeitet ebenfalls Mitteilungen, die von der Funkeinheit empfangen werden, und sendet sie zu der RIL-Proxyschicht. In einem bevorzugten Ausführungsbeispiel ist die RIL-Treiberschicht eine dynamisch gelinkte Bibliothek (DLL (Dynamic Link Library]), die als ein Gerätetreiber in dem Prozessraum eines Gerätemanagers (dem Standardmodul, das Gerätetreiber auf dem „WINDOWS CE"-Betriebssystem verwaltet) läuft. Ein Gerätemanager (device.exe) kann für das Verwalten sämtlicher Systemtreiber, einschließlich des RIL-Treibers, zuständig sein.
RIL-Proxyschicht
In einem Ausführungsbeispiel umfasst die RIL-Proxyschicht eine Schicht, die durch mehrere andere Schichten der Kernarchitektur, wie beispielsweise eine TSP-Schicht, eine ExTAPI-Schicht und einen SIM-Manager, unter Verwendung der plattformspezifischen Befehle dieser Kernarchitekturen aufgerufen wird. In einem bevorzugten Ausführungsbeispiel ist die Proxyschicht eine dynamisch gelinkte Bibliothek (DLL) von „WIN-DOWS-CE", die Rückruf-Mitteilungen und Funktions-Aufrufe zwischen den Prozessen in der RIL-Treiberschicht verwaltet. Module, die die RIL verwenden wollen, stellen einfach eine Verbindung zu dieser Proxy-DLL her. Die RIL-Proxyschicht wandelt die spezifischen Befehle der Kernarchitektur in RIL-API-Aufrufe um, die von der RIL-Treiberschicht verstanden werden.
Es gibt einige bedeutende Unterschiede zwischen der Proxyschicht und der Treiberschicht. In einem bevorzugten Ausführungsbeispiel der Erfindung wird eine separate Proxy-Instanz für jedes Modul unter Verwendung der RIL-Proxy-DLL erstellt. Demgegenüber wird in einem bevorzugten Ausführungsbeispiel der Erfindung der RIL-Gerätetreiber lediglich einmal geladen und von allen Proxyschicht-Instanzen gemeinsam genutzt. Mit anderen Worten bedeutet dies, dass ein Modul, das die RIL verwendet, wissen muss, dass lediglich ein Funkmodul vorhanden ist, selbst wenn es mit seiner eigenen Proxy-DLL verbunden ist. Darüber hinaus setzt die Steuerung der RIL-Treiberschicht durch den Gerätemanager voraus, dass der Proxy und der Treiber in verschiedenen Prozessen vorkommen (das heißt, in unterschiedlichen Adressenbereichen). Das „WINDOWS CE"-Betriebssystem stellt Mechanismen bereit, die es der Proxyschicht und der Treiberschicht ermöglichen, ohne Berücksichtigung der Prozessgrenzen zu kommunizieren.
Eine weitere wichtige Eigenschaft der Architektur der RIL ist, dass nahezu alle der Funktionen asynchron sind. Wenn sich ein Modul zuerst bei der RIL registriert, reicht es zwei Rückruf-Funktionen ein. Eine wird für unerwünschte Mitteilungen verwendet und die an dere für Antworten auf die Funktions-Aufrufe. Wenn beispielsweise ein Telefon einen neuen eingehenden Anruf empfängt, nutzt die RIL den Rückruf für unerwünschte Mitteilungen, um jedes Modul über den eingehenden Anruf zu informieren. Wenn alternativ dazu ein Modul die RIL aufruft, um die Signalstärke zu erhalten, gibt der Funktions-Aufruf umgehend einen Antwort-Identifikator zurück. Kurz danach nutzt die RIL den Funktionsantwort-Rückruf, um die Signalstärkeinformationen zu dem Modul zu übertragen. Um sicherzustellen, dass die Funktionsantwort-Rückrufe richtig mit dem Funktions-Aufrufen abgeglichen werden, enthält diese Rückruf-Struktur auch denselben Antwort-Identifikatorwert, der von dem ursprünglichen Funktions-Aufruf zurückgegeben wurde. Diese asynchrone Architektur vereinfacht die Implementierung der RIL. Wenn ein Modul RIL-Funktionen auf eine synchrone Weise aufrufen muss, muss es den Funktions-Aufruf so lange durchführen und blockieren, bis es den Funktionsantwort-Rückruf empfängt.
Ein weiteres architektonisches Leistungsmerkmal der RIL ist ein virtueller serieller Anschluss (VSP [Virtual Serial Port]). Wenn eine Anwendung eine Datenverbindung herstellt, sucht sie einen Handle zu einem virtuellen seriellen Anschluss auf (nicht den realen Datenfluss zwischen der RIL und der Funkhardware). Dies ermöglicht der RIL, den Datenfluss zwischenzuspeichern und den Ablauf des Datenflusses zu steuern, so dass Steuerbefehle erteilt werden können. Es wird beispielsweise angenommen, dass eine Anwendung eine Datenverbindung aufgebaut hat und das Internet durchsucht. Durch den virtuellen seriellen Anschluss kann die RIL Steuerbefehle erteilen, um Dinge, wie die Signalstärke, neue SMS-Nachrichten und so weiter zu überprüfen. Es wird des Weiteren angenommen, dass eine Anwendung ein Fax empfängt. Aufgrund der genauen Zeitvorgaben in dem Fall einer Faxübertragung greift die RIL auf einen zweckbestimmten Datenmodus zu, in dem die Anwendung die vollständige Kontrolle über den virtuellen seriellen Anschluss hat. Das heißt, die RIL unternimmt keinen Versuch, jegliche Befehle in den Datenfluss einzubringen. Es wird darauf hingewiesen, dass der VSP den anderen Kommunikationsanschlüssen ähnlich ist, und dass typischerweise lediglich eine Anwendung zur gleichen Zeit den Handle zu dem virtuellen seriellen Anschluss haben kann.
Im Folgenden wird in Bezug auf 2 ein Blockdiagramm beschrieben, das ein exemplarisches Ausführungsbeispiel einer RIL in einem Zellulartelefon 200 in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung darstellt. Das Zellular telefon 200 umfasst einen SIM-Manager 205, eine Notrufanwendung 210, einen TAPI-Dienstanbieter (TSP [TAPI Service Provider]) 215, eine WAP-Schicht 220, einen SMS-Manager 225, einen Daten-Stapelspeicher 230 und einen VSP 250.
Das Zellulartelefon 200 umfasst darüber hinaus eine Vielzahl von Instanzen der RIL-Proxyschicht 235. Die RIL-Proxyschicht 235 stellt Kommunikationen zwischen den Anwendungen (wie beispielsweise dem SIM-Manager 205, der Notrufanwendung 210, dem TSP 215, der WAP-Schicht 220, dem SMS-Manager 225 und der ExTAPI unter anderen) und einer RIL-Treiberschicht 240 bereit. Die RIL-Treiberschicht 240 stellt Kommunikationen zwischen der RIL-Proxyschicht und der Funkhardware 245 bereit.
Szenarien
Hinsichtlich der „Verwendung" der RIL (aus der Perspektive eines Anwendungsdesigners und eines OEMs) stellen die Proxyschicht und die Treiberschicht jeweils einen Satz von Funktionen bereit. Wenn ein Programmmodul die RIL verwenden will, muss es lediglich die in der Proxy-Header-Datei spezifizierten Funktionen verwenden und dann eine Verbindung zu der Proxy-DLL herstellen. Die Proxy-DLL wird durch die in der Treiber-Header-Datei spezifizierten Aufruffunktionen implementiert. Die Treiber-Header-Datei wird den OEMs zur Verfügung gestellt und definiert die Funktionen, die ein OEM implementieren muss. In einem Ausführungsbeispiel ist die Implementierung hardwarespezifisch, das heißt, jeder OEM ist für seine eigene Treiberimplementierung verantwortlich. Es können jedoch eine oder mehrere Referenzimplementierungen des Treibers (Quellcode eingeschlossen) den OEMs zur Verfügung gestellt werden, um sie bei diesem Schritt zu unterstützen. Wenn ein OEM Funkhardware verwendet, die durch eine dieser Referenzimplementierungen unterstützt wird, kann es sein, dass er den RIL-Code nicht ändern muss.
Verfahren zum Verarbeiten von Befehlen unter Verwendung der RIL
3 ist ein Ablaufplan, der ein Verfahren 300 zum Verarbeiten von Befehlen unter Verwendung der Funkschnittstellenschicht (RIL) in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung darstellt. Das Verfahren 300 beginnt bei Schritt 305, wenn ein Benutzer ein RIL-API in der Proxyschicht aufruft.
In dem Entscheidungsschritt 310 wird festgestellt, ob der Aufgerufene, das heißt, der aufgerufene Prozess, sich in dem Prozessraum device.exe befindet. Ist dies der Fall, geht das Verfahren zu Schritt 315 über, in dem die Treiber-APIs direkt aufgerufen werden. Wenn in dem Entscheidungsschritt 310 festgestellt wird, dass sich der Aufgerufene nicht in dem Prozessraum device.exe befindet, geht das Verfahren zu Schritt 320 über.
In Schritt 320 werden Eingabe/Ausgabe-Steuer- (IOCTL [Input/Output Control]) Codes verwendet, um die entsprechenden Informationen für das RIL-API zu dem RIL-Treiber zu senden, der in einem separaten Prozessraum läuft. In Schritt 325 informiert der RIL-Treiber die Funkhardware, den Schritt auszuführen, der durch den Befehl des RIL-APIs spezifiziert wird. In einem bevorzugten Ausführungsbeispiel informiert der RIL-Treiber die Funkhardware, den Schritt mit Hilfe einer AT-Befehlsschnittstelle, wie in den GSM-Spezifikationen (im Wesentlichen 07.05 und 07.07) definiert, durchzuführen. Es kann vorkommen, dass das Senden von AT-Befehlen für eine gegebene Funkhardware nicht optimal ist – vielleicht verfügt ein OEM über einen separaten privaten API-Satz, den er verwenden kann, um dieselbe Funktionalität wie ein gegebener AT-Befehl durchzuführen. Wenn dies der Fall ist, kann der OEM den RIL-Treiber entsprechend seinen Anforderungen ändern. In einem bevorzugten Ausführungsbeispiel ist es, da die Kernarchitektur des Telefons oberhalb eines Satzes von RIL-APIs aufgebaut wurde, der über AT-Befehle implementiert werden kann, jedoch nicht erforderlich, dass der OEM den RIL-Treiber wesentlich modifiziert, so lange die AT-Befehle von der Funkhardware verstanden werden. Aufgrund unterschiedlicher Implementierungen der AT-Schnittstelle können einige geringfügige Modifizierungen erforderlich sein.
Das Verfahren geht anschließend zu Schritt 330 über, in dem das RIL-API mit einem eindeutigen durch die RIL erzeugten Identifikator zurückgegeben wird. Es wird darauf hingewiesen, dass nach dem Senden eines AT-Befehls auf eine Antwort von der Funkhardware gewartet wird. Die RIL-APIs sind asynchron konzipiert, so dass diese APIs sofort mit einem eindeutigen dem Aufruf zugewiesenen Identifikator zurückgegeben werden.
Das Verfahren geht anschließend zu Schritt 335 über, in dem ein separater Thread auf Antworten von der Funkeinheit wartet.
Das Verfahren geht anschließend zu Schritt 340 über, in dem der RIL-Treiber die Antwort von der Funkeinheit mit dem zuvor erzeugten eindeutigen Identifikator abgleicht, und der RIL-Treiber die Antwort an den entsprechenden aufrufenden Prozess über eine Rückruffunktion sendet.
Es wird des Weiteren darauf hingewiesen, dass Funkeinheiten auch unerwünschte Mitteilungen (wenn beispielsweise das Telefon den Mobilfunkturm wechselt) senden können. In diesem Fall empfängt der RIL-Treiber eine Mitteilung von der Funkeinheit und wird eine Nachricht an alle Benutzer der RIL-Schicht rundsenden, die an dieser Mitteilungsklasse interessiert sind.
Bei einem Beispiel, das eine Implementierung des Verfahrens 300 illustriert, ist Folgendes zu beachten: das API RIL_ChangeLockingPassword ist ein RIL-API, das es ermöglicht, das Passwort eines Telefons für mehrere Sperreinrichtungen zu ändern. Dieses API wird nach dem +CPWD AT-Befehl gebildet, der in Abschnitt 7.5 der GSM-Spezifikation 07.07 definiert ist. Der AT-Befehl zum Ändern eines Passwortes benötigt eine Sperreinrichtung, das alte Passwort und das neue Passwort. Dementsprechend erscheint das API für RIL_ChangeLockingPassword als:
HRESULT RIL_ChangeLockingPassword(
HRIL hRil,
DWORD dwFacility,
LPCSTR lpszOldPassword,
LPCSTR lpszNewPassword
);
Wenn die Benutzeranwendung das Sperrpasswort ändern will, ruft sie dieses API typischerweise indirekt über eine TAPI-Schicht oder eine andere Schicht auf. Beispielsweise kann die Anwendung den TAPI-Befehl zum Ändern des Passwortes verstehen und diesen Befehl an die TAPI-Schicht senden. Die TAPI-Schicht tätigt anschließend den entsprechenden RIL-API-Aufruf an die Proxyschicht. Als Teil des RIL-APIs muss ein RIL-Handle bereitgestellt sein (der durch das Initialisieren der RIL erhalten wird), eine Sperreinrichtung muss bereitgestellt sein, das alte Passwort muss bereitgestellt sein und das neue Passwort muss bereitgestellt sein. Es wird beispielsweise angenommen, dass eine Benutzeranwendung das Passwort, das zum Sperren der SIM-Karte verwendet wird, von „1234" zu „5678" ändern möchte. Die Benutzeranwendung (oder eine Zwischenschicht, wie beispielsweise die TAPI-Schicht) würde den folgenden API-Aufruf tätigen:
RIL_ChangeLockingPassword(hRIL, RIL_LOCKFACILITY_SIM, "1234", "5678");
Wenn sich der aufrufende Prozess nicht in dem Prozessraum device.exe befindet, werden diese Parameter in einer Struktur gebündelt, und über einen IOCTL-Aufruf übertragen:
RIL_IOCTL_CHANGELOCKINGPASSWORD:
Der RIL-Treiber verwendet anschließend diese Werte und erzeugt einen AT-Befehlsstring, wie in der GSM 07.07 spezifiziert: AT + CPWD = SC,1234,5678
Es ist zu beachten, dass, wenn ein OEM den RIL-Treiber ändern sollte, um ein privates API für seine Funkhardware aufzurufen, anstatt einen AT-Befehl zu verwenden, er seine Änderung zu diesem Zeitpunkt vornehmen würde.
Nach dem Senden dieses AT-Befehls (oder des privaten APIs) an die Funkhardware kehrt der RIL-Treiber zurück, und RIL_ChangeLockingPassword kehrt zurück. Die Funkhardware hat den Befehl zu diesem Zeitpunkt noch nicht verarbeitet, demzufolge wird ein eindeutiger Identifikator als der Rückgabewert dieses RIL-APIs an den Benutzer zurückgegeben.
Nach dem Verarbeiten des Befehls gibt das Funkmodul einen Erfolgs- oder Fehlercode zurück (in diesem Fall ist es ein Erfolgscode oder ein möglicherweise beschreibender Fehlercode, wie beispielsweise „falsches Passwort"). Die Funkhardware überträgt diese Antwort zu dem RIL-Treiber, der über einen separaten Thread verfügt, der auf Antworten von dem Funkmodul wartet. Diese Antwort wird anschließend mit dem eindeutigen Identifikator des API-Aufrufs abgeglichen und über eine Rückruffunktion an die aufrufende Anwendung gesendet. Die aufrufende Anwendung kann anschließend feststellen, ob das Sperrpasswort erfolgreich geändert wurde oder nicht und entsprechend agieren.
Im Folgenden wird in Bezug auf 4 ein Beispiel beschrieben, das ein Verfahren zum Aufbauen eines Sprachanrufs durch eine Anwendung unter Verwendung der RIL in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung darstellt. Es wird darauf hingewiesen, dass das Aufbauen eines Sprachanrufs nur eine von vielen Funktionen ist, die mit Hilfe der RIL-APIs durchgeführt werden können. Das in 4 beschriebene Verfahren illustriert eine dieser Funktionen (Aufbauen eines Sprachanrufs). Das Verfahren wird in dem Telefon 400 angewandt, welches eine Anwendungsschicht 405, eine ExTAPI-Schicht 410, eine TAPI-Schicht 415, weitere Kernmodule 420, einen TSP 425, eine Funkschnittstellenschicht (RIL) 430 in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung sowie OEM-Hardware 435 umfasst. Es wird darauf hingewiesen, dass das Verfahren nicht die IOCTLs beschreibt, die von Personen mit gewöhnlicher Erfahrung auf dem Gebiet als in einem bevorzugten Ausführungsbeispiel vorhanden verstanden werden. Es wird des Weiteren darauf hingewiesen, dass die vorliegende Erfindung ohne die Verwendung von IOCTLs implementiert werden kann.
Das Verfahren beginnt, wenn die Anwendung 405 die TAPI-Funktion aufruft: lineMake-Call (Schritt 452). Die TAPI-Schicht 415 ruft den TSP 425 mit dem folgenden Funktions-Aufruf auf: TSPI_lineMakeCall (Schritt 454). Der TSP 425 ruft die RIL mit der folgenden RIL-Funktion auf: RIL_Dial (Schritt 456). Die RIL initiiert den Telefonanruf durch das Senden des entsprechenden Befehls an die OEM-Hardware (beispielsweise Funkhardware): zum Beispiel ATDT 555-1234 (Schritt 458). Der TSP gibt asynchron eine Ant wortnachricht an die TAPI-Schicht zurück, die anzeigt, dass der Anruf initiiert wurde: Nachricht LINE_REPLY (Schritt 460).
Die TAPI-Schicht leitet die Antwortnachricht (LINE_REPLY) an die Anwendung weiter (Schritt 462). Wenn die OEM-Hardware detektiert, dass eine Verbindung zu der Nummer hergestellt wurde, sendet sie eine Antwort CONNECT an die RIL (Schritt 464). Die RIL sendet eine Nachricht (RIL_NOTIFY_CONNECT) an den TSP, die anzeigt, dass eine Verbindung hergestellt wurde (Schritt 466). Der TSP sendet eine Statusänderungsmitteilung (LINE_CALLSTATE) an die TAPI-Schicht (Schritt 468). Die TAPI-Schicht leitet die Statusänderungsmitteilung (LINE_CALLSTATE) an die Anwendung 405 weiter (Schritt 470).
Wenn die Anwendung 405 den Telefonanruf beenden möchte, ruft sie die TAPI-Schicht mit einer Auflege-Anforderung auf: (lineDrop) (Schritt 472). Die TAPI-Schicht leitet die Auflege-Anforderung an den TSP weiter: (TSPI_lineDrop) (Schritt 474). Der TSP-Handler überträgt die Auflege-Anforderung an die RIL: (RIL_Hangup) (Schritt 476). Die RIL sendet die Auflege-Anforderung an die OEM-Hardware (zum Beispiel ATH) (Schritt 478).
Leistungsmerkmale
Die vorliegende Tabelle beschreibt einige der Leistungsmerkmale, die unter Verwendung eines Ausführungsbeispiels der vorliegenden Erfindung umgesetzt werden können, und gibt eine kurze Beschreibung dieser Leistungsmerkmale.
Strukturauflistung
Dieser Abschnitt beschreibt die „Datenstrukturen", die in einem Ausführungsbeispiel der vorliegenden Erfindung als Parameter an einige RIL-APIs weitergeleitet werden und mit einigen RIL-Mitteilungen wieder zurückgegeben werden.
Netzdienst-Strukturen
Anrufsteuerungs-Strukturen
Strukturen zusätzlicher Dienste
Sprach-Strukturen
Nachrichten-Strukturen
Datendienst-Strukturen
Fähigkeiten-Strukturen
SIM-Toolkit-Strukturen
Verschiedene Strukturen
Mitteilungsauflistung
Dieser Abschnitt listet einige der unerwünschten RIL_Mitteilungen auf, die zu dem Mitteilungs-Rückruf weitergeleitet werden. Hierbei ist zu beachten, dass sich diese Mitteilungen von denen unterscheiden, die als Antworten auf zu einem früheren Zeitpunkt durchgeführten Funktions-Aufrufen dem Antwort-Rückruf weitergeleitet wurden. Diese Mitteilungen wurden der Nützlichkeit halber kategorisiert. Diese Mitteilungen sind in einem Ausführungsbeispiel der Erfindung enthalten und sind nicht als die Erfindung einschränkend zu erachten. dwCode ist der numerische Identifikator, der die Mitteilung identifiziert und IpData sind die zusätzlichen Daten, die mit der Mitteilung zurückgegeben werden.
Anrufsteuerungs-Mitteilungen
Zusätzliche Dienst-Mitteilungen
Nachrichten-Mitteilungen
Telefonbuch-Mitteilungen
SIM-Toolkit-Mitteilungen
Verschiedene Mitteilungen
Funktionsauflistung
Dieser Anschnitt listet einige der RIL-Funktionen auf, wobei diese nach Gruppen aufgeteilt sind. Jeder Eintrag bezeichnet den Namen der Funktion und liefert eine kurze Beschreibung. Gegebenenfalls ist der entsprechende GSM-AT-Befehl enthalten.
Anrufsteuerungs-Funktionen
Zusätzliche Dienstfunktionen
Sprachfunktionen
Nachrichtenübermittlungs-Funktionen
Datendienst-Funktionen
Sicherheitsfunktionen
Schnittstellenfunktionen
Telefonbuch-Funktionen
SIM-Toolkit-Funktionen
Verschiedene Funktionen
Aus der vorangehenden Beschreibung sollte ersichtlich werden, dass die RIL-Proxyschicht hardwareunabhängig ist. Demgegenüber wird darauf hingewiesen, dass in verschiedenen Ausführungsbeispielen die RIL-Treiberschicht hardwarespezifisch ist. In einem Ausführungsbeispiel jedoch wird eine beispielhafte GSM-Implementierung des RIL-Treibers bereitgestellt, um mit der generischen GSM-Hardware zu funktionieren (obwohl in der Praxis wahrscheinlich einige Modifikationen für nahezu jedes zurzeit verfügbare GSM-System erforderlich sind, da die GSM-Spezifikationen interpretiert und mit geringfügigen Unterschieden von verschiedenen OEMs implementiert werden können).
Es sollte darüber hinaus aus der vorangehenden Beschreibung ersichtlich werden, dass es die vorliegende Erfindung den Softwareanwendungen ermöglicht, auf RIL-kompatiblen Telefonen unabhängig von der verwendeten Hardware und dem verwendeten Zellularnetz ausgeführt werden können. Beispielsweise würde das Wechseln von einem GSM-Netz zu einem CDMA-Netz lediglich das Ersetzen der RIL-Treiberschicht erforderlich machen, und der Rest des Telefons würde wie in dem GSM-Netz arbeiten.
Aus der vorangehenden Erfindung sollte ersichtlich werden, dass der Zweck der RIL darin besteht, einen Zugang zu der zellularen Funktionalität für jede Komponente in dem Telefon, PDA und so weiter bereitzustellen. Ohne die RIL müsste jede Komponente (TAPI, SIM-Manager, SMS-Manager und so weiter) verstehen, wie mit der Funkhardware direkt zu kommunizieren ist. Da es für Hardwarehersteller schwierig sein würde, einen TAPI-Treiber, einen SMS-Treiber, einen SIM-Treiber und so weiter zu implementieren, wurde die RIL konzipiert, um zwischen der Funkhardware und dem TAPI-Treiber, dem SMS-Treiber, dem SIM-Treiber und so weiter angeordnet zu werden.
Aus der vorangehenden Beschreibung sollte außerdem ersichtlich werden, dass, da die RIL-Proxy hardwareunabhängig ist, die RIL eine Plattform für dritte Softwareentwickler bietet. Mit den gut konzipierten APIs und Schnittstellen der RIL der vorliegenden Erfindung kann ein dritter Softwareentwickler seinen Code einmal schreiben und ihn auf allen Geräten, die eine RIL implementiert haben, wie beispielsweise Telefonen, PDAs und so weiter, arbeiten lassen. Darüber hinaus kann der Softwareentwickler die gut definierten Telefonie-Befehle, wie beispielsweise TAPI, verwenden, ohne sich Gedanken darüber machen zu müssen, ob das zugrunde liegende Gerät die zellulare Technologie, die Telefonie über das Internet und so weiter verwendet.
Es wird darauf hingewiesen, dass einer der Vorteile der RIL darin liegt, den Integrationsprozess der Softwarekomponenten mit den Hardwarekomponenten eines OEMs zu vereinfachen. Um dies umzusetzen, wickelt eine einzige Schicht sämtliche Kommunikationen zwischen den Kernmodulen und der Funkhardware eines OEMs ab. Mit der einzigen RIL können Softwarekomponenten entwickelt werden, ohne sich Gedanken bezüglich der Unterschiede bei der zugrunde liegenden Hardware machen zu müssen. Des Weiteren können OEMs mit der RIL die Softwarekomponenten mit ihrer Funkhardware integrieren, und zwar durch das Implementieren eines einzigen Funktionssatzes.
Es wird darauf hingewiesen, dass die vorangehende Beschreibung viele Einzelheiten über die Implementierung enthält, die den Umfang der vorliegenden Erfindung nicht beschränken sollen. Beispielsweise kann anstelle der Verwendung einer Proxy-Schicht und einer Treiber-Schicht die vorliegende Erfindung als eine einzige Abstraktionsschicht zwischen einer Telefonie-Funkhardware und einem Computer implementiert werden. Die Anwendungen auf dem Computer können unter Verwendung der APIs der obersten Ebene mit der Abstraktionsschicht kommunizieren. Demgegenüber würde die Telefonie-Funkhardware auf Befehle antworten, die von der Abstraktionsschicht empfangen wurden. Da die Schwierigkeiten bei der Implementierung spezifischer Module, um die verschiedenen Protokolle, wie beispielsweise TAPI, ExTAPI, SMS und so weiter zu verstehen, durch die RIL selbst beseitigt werden, verringert die vorliegende Erfindung die Schwierigkeiten, die die Funkhardwarehersteller bei der Implementierung oft haben. Darüber hinaus müssen sich die Funkhardwarehersteller nicht länger Gedanken um das Empfangen und das Aufzeichnen der Aufrufe von mehreren Client-Anwendungen machen, da sämtliche dieser Funktionen von der RIL ausgeführt werden. Entwickler von Softwareanwendungen müssen sich keine Gedanken über die zugrunde liegende Hardware eines mobilen Gerätes machen. Softwareanwendungen können für das Arbeiten mit der RIL einfach geschrieben werden, da die Anwendungen gut bekannte APIs der obersten Ebene verwenden, die an die RIL gesendet werden. Die RIL führt anschließend eine geeignete Verarbeitung dieser APIs der obersten Ebene durch und sendet, falls erforderlich, den entsprechenden Befehl an die Funkhardware, um eine spezifische Funktion durchzuführen.
Weitere unterstützte Konfigurationen
Aus der vorangehenden Beschreibung sollte ersichtlich werden, dass die vorliegende Erfindung mit Zellulartelefonen sowie mit anderen Vorrichtungen verwendet werden kann, wie beispielsweise tragbaren PDA-Vorrichtungen. Es kann vorkommen, dass einige dieser anderen Vorrichtungen über kein permanentes Funkmodul/keine permanenten Funkmodule verfügen. Gewisse Änderungen, die den Personen mit gewöhnlicher Erfahrung auf dem Gebiet bekannt sind, können erforderlich sein, um die Erfindung in einer Vorrichtung ohne ein permanentes Funkmodul/permanente Funkmodule einzusetzen. Die Erfindung muss insbesondere entnehmbare Compact Flash (CF)/PCMCIA-Funkmodule unterstützen, die leitungsvermittelte zellulare Netzverbindungen unterstützen.
Im Folgenden sind einige mögliche Gerätekonfigurationen aufgeführt:
Konfiguration 1: Zellulartelefon
Das Gerät verfügt über ein integriertes Funkmodul. Es besitzt keine Erweiterungssteckplätze, die CF- oder PCMCIA-Karten unterstützen. Demzufolge ist sichergestellt, dass das integrierte Funkmodul immer vorhanden ist und keine alternative Form der Mobilfunkkommunikation zulässig ist.
Konfiguration 2: PDA mit PCMCIA/CF-Unterstützung
Das Gerät verfügt über kein integriertes Funkmodul. Es besitzt jedoch CF- und/oder PCMCIA-Erweiterungssteckplätze. In einem bevorzugten Ausführungsbeispiel macht es die Erfindung erforderlich, dass ein unterstütztes Funkmodul in den CF- oder PCMCIA-Steckplatz hineingesteckt wird.
Konfiguration 3: PDA mit integriertem Funkmodul und PCMCIA/CF-Unterstützung
Das Gerät verfügt über ein integriertes Funkmodul. Es kann angenommen werden, dass dieses Funkmodul immer vorhanden ist. Unter Umständen können andere Geräte (einschließlich Funkmodule) in die verfügbaren Erweiterungssteckplätze (PCMCIA, USB, Bluetooth und so weiter) eingesteckt werden.
Die oben beschriebenen Geräte können ebenfalls einige Ergänzungen und Modifikationen an dem Satz von APIs erforderlich machen, wie im Folgenden in einem erklärenden Ausführungsbeispiel beschrieben:
PDA-Unterstützung API-Hinzufügungen
Fehlercodes:
RIL_E_RADIONOTPRESENT
Lässt die RIL-Aufrufe fehlschlagen, da in dem System keine Funkhardware vorhanden ist.
RIL_E_RADIOREMOVED
Lässt die RIL-Aufrufe fehlschlagen, die sich im Prozess des Ausgeführt-Werdens befanden, da die Funkhardware entfernt wurde.
PDA-Mitteilungen
RIL_NCLASS_RADIOSTATE

Funkhardwarestatus-Mitteilungen (RIL_NCLASS_RADIOSTATE)

Mitteilung Funkhardwarestatus-Werte
RIL_NOTIFY_RADIOPRESENT
Mitteilung der Situation entsprechend, in der die Funkhardware eingesetzt wird und der RIL-Treiber bereit ist, Befehle zu empfangen.
RIL_NOTIFY_RADIONOTPRESENT
Mitteilung der Situation entsprechend, wenn die Funkhardware entfernt ist und der RIL-Treiber nicht geladen ist.
Zusätzliche beziehungslose Mitteilungen
RIL_NOTIFY_RADIOOFF

Für SetEquipmentState TxundRx- [Sender- und Empfänger] Ausschaltbefehl

RIL_NOTIFY-RADIOON

Für SetEquipmentState TxundRx- [Sender- und Empfänger] Einschaltbefehl

Als Anhang A ist eine Liste der RIL-APIs eines bevorzugten Ausführungsbeispiels der vorliegenden Erfindung angehangen. Diese APIs dienen lediglich als Beispiele und sollte nicht im Sinne einer Einschränkung der Erfindung zu verstehen sein.
Anhang A

Claims

Verfahren zur Kommunikation mit einer Telefoniefunkhardware (245; 485), dadurch gekennzeichnet, dass das Verfahren folgende Schritte umfasst: Koppeln (interfacing) eines Computers (20; 49) an die Telefoniefunkhardware durch eine Abstraktionsschicht, welche eine Proxyschicht (235) und eine Treiberschicht (240) umfasst; Aufrufen eines aus einem Satz in der Abstraktionsschicht enthaltener APIs, wobei der Satz von APIs Anrufsteuertunktionen entsprechen und der Abstraktion aus mehreren Funkhardwaretechnologien ohne Kenntnis des Telefoniefunks oder des Zellularnetzes dienen; Empfangen des API-Aufrufs an einer ersten Schnittstelle der Proxyschicht; Transformieren des API-Aufrufs in einen Befehl, der von der Treiberschicht verstanden wird, und Senden des Befehls an die Treiberschicht an einer zweiten Schnittstelle; Empfangen des Befehls an der zweiten Schnittstelle; Bestimmen mindestens eines Standardtelefoniefunkhardwarebefehls, der dem aufgerufenen API entspricht, durch die Treiberschicht; und Senden des Telefoniefunkhardwarebefehls an die Telefoniefunkhardware an einer dritten Schnittstelle durch die Treiberschicht.
Verfahren nach Anspruch 1, wobei die Telefoniefunkhardware eine aus einer Vielzahl von Telefoniefunkhardware ist, welche auf Basis der Standardtelefoniefunkhardwarebefehle arbeitet.
Verfahren nach Anspruch 1 oder 2, wobei der Satz von APIs ferner SMS- (Short Messaging System) Funktionen entsprechen.
Verfahren nach einem der Ansprüche 1 bis 3, wobei der Satz von APIs ferner Netzwerkservicefunktionen entsprechen.
Verfahren nach einem der Ansprüche 1 bis 4, wobei der Satz von APIs ferner Datenverbindungsfunktionen entsprechen.
Verfahren nach einem der Ansprüche 1 bis 5, wobei der Satz von APIs ferner Schnittstellenfunktionen entsprechen.
Verfahren zum Betrieb eines Telefons (200; 400) zur Ermöglichung von Kommunikationen zwischen einem Anwendungsprogrammmodul und einer Funkhardware (245; 485), dadurch gekennzeichnet, dass das Verfahren folgende Schritte umfasst: Aufrufen (305) eines API durch eine Anwendung (205, 210, 215, 220, 225, 405), um eine bestimmte Funktion durchzuführen; Empfangen des API-Aufrufs an einer ersten Schnittstelle einer Proxyschicht (235); Transformieren des APIs in einen IOCTL durch die Proxyschicht (235), welche in einer Funkschnittstellenschicht (430) enthalten ist, wobei die Proxyschicht der Kommunikation mit der Anwendung an der ersten Schnittstelle und einer Treiberschicht an einer zweiten Schnittstelle dient und die Treiberschicht mit der Proxyschicht an der zweiten Schnittstelle und mit der Funkhardware an einer dritten Schnittstelle kommuniziert; Senden (320) des IOCTL durch die Proxyschicht an die Treiberschicht (240) an der zweiten Schnittstelle; Empfangen des IOCTL durch die Treiberschicht an der zweiten Schnittstelle; Transformieren des IOCTL in einen Befehl, der durch die Funkhardware verstanden wird, um eine bestimmte Funktion auszuführen, durch die Treiberschicht; und Senden des Funkbefehls an die Funkhardware an der dritten Schnittstelle.
Verfahren nach Anspruch 7, ferner umfassend: Empfangen von Kommunikationen von der Funkhardware, die angeben, dass die bestimmte Funktion durchgeführt wurde, durch die Treiberschicht; und Senden eines Erfolgscodes an die Proxyschicht, der angibt, dass die bestimmte Funktion durchgeführt wurde, durch die Treiberschicht.
Verfahren nach Anspruch 7 oder 8, wobei das Telefon die Proxyschicht, die Treiberschicht, die Anwendung und die Funkhardware umfasst; die Anwendung das API in der Proxyschicht aufruft; das API mit der durch die Funkhardware durchzuführenden Funktion assoziiert ist; der Befehl, der von der Funkhardware verstanden wird, der Funktion entspricht; und das Verfahren ferner das Senden (325) des Befehls an die Funkhardware umfasst.
Verfahren nach einem der Ansprüche 7 bis 9, wobei der Befehl ein AT-Befehl ist.
Verfahren nach einem der Ansprüche 7 bis 9, wobei der Befehl einer aus einem privaten API-Satz ist, welcher durch den Funkhardwarehersteller definiert wurde.
Verfahren nach einem der Ansprüche 7 bis 11, ferner umfassend das Erzeugen eines eindeutigen (unique) mit dem API assoziierten Identifikators in der Treiberschicht.
Verfahren nach Anspruch 12, ferner umfassend: Warten (335) auf eine Antwort von der Funkhardware; und wenn diese empfangen wird, Zurückrufen (335) der aufrufenden Anwendung mit der von dem Aufruf zurückgegebenen (returned) Anwort und eindeutigen Identifikator.
Verfahren nach Anspruch 13, wobei die Treiberschicht die Antwort von der Funkhardware mit dem eindeutigen Identifikator abgleicht (340); und die Treiberschicht die Antwort an die aufrufende Anwendung über eine Rückruffunktion sendet.
Verfahren nach einem der Ansprüche 1 bis 14, ferner umfassend: Erzeugen eines API-Aufrufs an einer von einer Vielzahl von Anwendungen (205, 21, 215, 220, 225, 405), um die bestimmte Funktion durchzuführen; Senden des API-Aufrufs an einen Funktreiber; Konvertieren des API-Aufrufs in einen Befehl, der von der Funkhardware verstanden wird, bei dem Funktreiber; Übertragen des Befehls an die Funkhardware; und Durchführen der bestimmten Funktion bei der Funkhardware.
Verfahren nach Anspruch 15, ferner umfassend, in Erwiderung auf eine erfolgreiche Durchführung der bestimmten Funktion, Senden eines Erfolgscodes an die eine der Vielzahl von Anwendungen, die den API-Aufruf erzeugt hat.
Verfahren nach Anspruch 16, wobei das API, der Befehl und der Erfolgscode mit einem Identifikator assoziiert sind, der sie miteinander verbindet (linking) und sie mit der einen der Vielzahl von Anwendungen verbindet, die den API-Aufruf erzeugt hat; der Funktreiber den Erfolgscode empfängt; der Funktreiber, indem er den Identifikator verwendet, den Erfolgscode mit der einen der Vielzahl von Anwendungen, die den API-Aufruf erzeugt hat, abgleicht; und der Funktreiber den Erfolgscode an die eine der Vielzahl von Anwendungen, die den API-Aufruf erzeugt hat, sendet.
Verfahren nach einem der Ansprüche 15 bis 17, ferner umfassend: Erzeugen einer Mitteilung an der Funkhardware in Erwiderung auf die Detektion von Daten, die an die eine der Vielzahl von Anwendungen berichtet werden müssen; und Senden der Mitteilung an den Funktreiber.
Verfahren nach Anspruch 18, ferner umfassend das Senden der Mitteilung von dem Funktreiber an die eine der Vielzahl von Anwendungen.
Verfahren nach Anspruch 18, ferner umfassend das Senden der Mitteilung von dem Funktreiber an jede der Vielzahl von Anwendungen.
Verfahren nach einem der Ansprüche 18 bis 20, wobei die Daten, die berichtet werden müssen, einen eingehenden Telefonanruf an die Funkhardware umfassen.
Verfahren nach einem der Ansprüche 18 bis 21, wobei die Daten, die berichtet werden müssen, eine Veränderung der Signalstärke in der Funkhardware umfassen.
Verfahren nach einem der Ansprüche 15 bis 22, wobei die eine der Vielzahl von Anwendungen ein TSP (215) ist.
Verfahren nach einem der Ansprüche 15 bis 22, wobei die eine der Vielahl von Anwendungen ein SIM-Manager (205) ist.
Verfahren nach einem der Ansprüche 15 bis 22, wobei die eine der Vielzahl von Anwendungen eine Notrufanwendung (215) zur Erzeugung von Notrufen ist.
Verfahren nach einem der Ansprüche 15 bis 22, wobei die eine der Vielzahl von Anwendungen eine WAP-Schicht (220) ist.
Verfahren nach einem der Ansprüche 15 bis 22, wobei die eine der Vielzahl von Anwendungen eine TAPI-Schnittstelle ist.
Verfahren nach einem der Ansprüche 15 bis 22, wobei die eine der Vielzahl von Anwendungen eine ExTAPI-Schnittstelle ist.
Verfahren nach einem der Ansprüche 15 bis 22, wobei die eine der Vielzahl von Anwendungen mit dem Anwendungsprogrammmodul verbunden (connected) ist und Befehle von dem Anwendungsprogrammmodul empfängt, um den API-Aufruf zu erzeugen.
Verfahren nach Anspruch 29, wobei die von dem Anwendungsprogrammmodul bereitgestellten Befehle Befehle umfassen, die durch die eine der Vielzahl von Anwendungen definiert sind; und die Befehle durch die eine der Vielzahl von Anwendungen in die API-Aufrufe konvertiert werden.
Telefongerät (200; 400), das dazu angepasst ist, das Verfahren nach einem der Ansprüche 1 bis 30 durchzuführen.