Mobile Einrichtungen könnten Anwendungen, Protokollstapel sowie eine für die Herstellung einer drahtlosen Verbindung mit einem Mobilkommunikationsnetz ausgelegte Modemeinheit umfassen, wobei alle besagten Entitäten auf einem Verarbeitungssystem ablaufen können. Die Modemeinheit könnte genauso gut auf einem anderen Verarbeitungsbetriebsmittel als die Anwendungen installiert sein. Darüber hinaus könnte für die Modemeinheit ein erstes Betriebssystem und für die Anwendungen ein anderes Betriebssystem verwendet werden. Es wird erwartet, dass in der Zukunft mehr und mehr Benutzerendgeräte verfügbar sein werden, die keine proprietäre Modemeinheit umfassen. Statt dessen umfassen die besagten Benutzerendgeräte eine physische Schnittstelle zum Herstellen einer Verbindung zwischen dem Benutzerendgerät und einer externen Modemeinheit, wobei die externe Modemeinheit für das Aufbauen einer drahtlosen Verbindung mit dem Mobilkommunikationsnetz verantwortlich sein wird. Darüber hinaus werden Telefone verfügbar sein, bei denen ein zusätzliches Verarbeitungsbetriebsmittel und/oder ein zusätzliches Betriebssystem, z.B. Symbian, zum Ausführen der Anwendungen vorgesehen sind. Solche Telefone werden häufig als Smart-Phones bezeichnet.

Um in einem System QoS sicherzustellen und Paketflüsse zu optimieren, ist eine Verbindung zwischen den verschiedenen Protokollschichten notwendig, insbesondere, wenn drahtlose Strecken verwendet werden. Protokolle und Anwendungen höherer Schichten müssen gemäß der zugrundeliegenden (drahtlosen) Strecke und gemäß dem tatsächlichen Status der Netzwerkverbindung (Bandbreitenverzögerung, Bitfehlerrate (BER) ...) abgestimmt werden. Deshalb müssen Messungen und Parameter aus den unteren Schichten (GPRS-Stapel, UMTS-Stapel ...) zu einem QoS-Verwaltungssystem höherer Schichten und/oder zu Protokoll-/Anwendungsoptimierern höherer Schichten transportiert werden. Diese stellen Protokolle, Anwendungen und Paketflüsse höherer Schichten durch Verwendung dieser Messungen und Parameter ein.

Während es in einem eingebetteten System relativ leicht ist, diese vertikale Verbindung zwischen den verschiedenen Schichten zu realisieren, wird es in einem verteilten System schwieriger. In einem verteilten System enthält das Modem die Informationen, die das auf der Anwendungseinheit residierende QoS-Verwaltungssystem benötigt. Verteilte Systeme sind (anders als eingebettete Systeme) gut standardisiert und werden durch wohlbekannte Spezifikationen definiert. Der Transfer von Messungen und Parametern von einem (drahtlosen) Modem zu der Anwendungseinheit ist jedoch nicht Teil dieser Spezifikationen.

Aus US 2003/0145119 ist ein System zur Bereitstellung drahtloser Datendienste mit einem drahtlosen Modem bekannt.

Eine Aufgabe der Erfindung ist die Verbesserung der Flusssteuerung in verteilten Benutzergeräten, die eine Modemeinheit und mindestens eine Anwendungseinheit umfassen.

Eine weitere Aufgabe der Erfindung ist der Transport von Messungsdaten von einem (drahtlosen) Modem zu einer Anwendungseinheit mit den folgenden Schlüsselmerkmalen:

• – Der Transfer der Daten sollte von der Schnittstelle (seriell, IRDA, Bluetooth, ...) zwischen der Anwendungseinheit und dem Modem unabhängig sein.
• – Es sollten keine Änderungen an dem Standard-AT-Befehlssatz (notwendig für die Kommunikation zwischen einer Anwendungseinheit, z.B. einem Computer, und einem Modem) erforderlich sein.
• – Es sollten keine Änderungen an dem notwendigen Modemtreiber erforderlich sein.
• – Es sollten keine Änderungen an den Betriebssystemtreibern erforderlich sein.
• – Es sollten keine Änderungen an dem PPP-(Punkt-zu-Punkt-Verbindungs)-Stapel erforderlich sein.

Diese Aufgaben der Erfindung werden durch die unabhängigen Ansprüche gelöst. Bevorzugte Ausführungsformen werden durch die anhängigen Ansprüche gezeigt.

Im folgenden werden die folgenden Definitionen von Begriffen angewandt:

Verteiltes System ist eine Kombination einer Anwendungseinheit und mindestens eines Modems. Beispiele für ein verteiltes System sind Smart-Phones und Notebooks (Laptops), die mit mindestens einem Modem kombiniert werden.

In einem eingebetteten System wird der Prozessor (und die DSP) für die Anwendungen und Protokolle höherer Schichten und die (drahtlosen) Kommunikationsstapel (z.B. GPRS) verwendet. Das klassische eingebettete System bei der Mobilkommunikation ist ein Mobiltelefon.

In einem verteilten System ist die Anwendungseinheit die Hart- und Softwareumgebung, in der die Anwendungen ablaufen. Sie besitzt mindestens einen Prozessor, Speicher und ein Betriebssystem. Der TCP/UDP/IP-Stapel läuft auch auf der Anwendungseinheit ab, die Stapel für die (mobile) Kommunikation (d.h. GSM/GPRS) laufen jedoch auf einem (externen) Modem ab und deshalb nicht auf dem Prozessor der Anwendungseinheit. Kann für Kommunikationszwecke auf verschiedene Arten von Modems zugreifen.

Ein Modem ist ein System, das Hardware und Software (hauptsächlich den Kommunikationsstapel) enthält und wird für (mobile) Kommunikation verwendet. Bei einem verteilten System führt das Modem keine Anwendungen aus.

Die Schnittstelle verbindet das Modem mit der Anwendungseinheit. Schnittstellen können z.B. eine USB-Schnittstelle, eine serielle Schnittstelle, eine IRDA-Schnittstelle, eine Bluetooth-Schnittstelle sein.

Eine Anwendungseinheit gemäß Ausführungsformen der vorliegenden Erfindung umfasst mindestens eine Anwendung, wobei die mindestens eine Anwendung dafür ausgelegt ist, Datenverkehr für drahtlose Kommunikation mit mindestens einem Protokollstapel auszutauschen.

Der mindestens eine Protokollstapel ist für den Transfer von Datenverkehr zwischen mindestens einer der Anwendungen und mindestens einer physischen Schnittstelle ausgelegt. Die mindestens eine physische Schnittstelle ist für das Senden von Datenverkehr und von Flusssteuerinformationen zwischen der Anwendungseinheit und einer Modemeinheit ausgelegt.

Die Anwendungseinheit ist über mindestens eine physische Schnittstelle mit der Modemeinheit verbunden, wobei sowohl Aufwärtsstreckenverkehr als auch Abwärtsstreckenverkehr in bezug auf die Anwendungen über die mindestens eine physische Schnittstelle übertragen werden. Gemäß der Erfindung können Flusssteuerinformationen über die mindestens eine physische Schnittstelle übertragen werden. Die Datenverkehrs- und Flusssteuerinformationen könnten z.B. in einem gemultiplexten Modus über die mindestens eine physische Schnittstelle übertragen werden. Als Alternative könnten die Flusssteuerinformationen z.B. über andere physische Schnittstellen als der Datenverkehr übertragen werden.

Bei vorbekannten Lösungen kannte die Anwendungseinheit die Flussparameter auf der Modemeinheit nicht und die Modemeinheit kannte die Anwendungen und Flussparameter auf der Anwendungseinheit nicht. Die Ausführungsformen der vorliegenden Erfindung ermöglichen einen Austausch von Flusssteuerinformationen zwischen der Anwendungseinheit und der Modemeinheit. Auf beiden dieser Einheiten sind die Flusssteuerinformationen hilfreich dabei, die verfügbaren Betriebsmittel und die verfügbare Bandbreite der drahtlosen Verbindung so effizient wie möglich auszunutzen. Jede der Einheiten wird über den Gesamtsystemzustand informiert und kann entsprechend reagieren. Als Folge wird die Gesamtleistung des Systems vergrößert. Es wird eine sanfte Anpassung der Steuereinstellungen des Systems erzielt und die QoS-Anforderungen der Anwendungen können zu einem Grad erfüllt werden, der bisher nicht möglich war.

Gemäß einer bevorzugten Ausführungsform der Erfindung wird die mindestens eine physische Schnittstelle als mindestens eine serielle Schnittstelle, insbesondere mindestens als Schnittstelle des Typs RS232, IrDA, Bluetooth, USB, PCMCIA und/oder UART realisiert oder umfasst solche. Eine serielle Schnittstelle ergibt ausreichend Bandbreite zum Senden sowohl von anwendungsbezogenem Datenverkehr als auch von Flusssteuerinformationen zwischen der Modemeinheit und der Anwendungseinheit.

Gemäß einer bevorzugten Ausführungsform der Erfindung umfassen die Flusssteuerinformationen folgendes: QoS-Profile der Anwendungen, tatsächliche Parameter, die den tatsächlichen Zustand des Datenflusses auf der Anwendungseinheit und/oder der Modemeinheit angeben, und/oder vorhergesagte Parameter, die einen zukünftigen Zustand des Datenflusses auf der Anwendungseinheit und/oder der Modemeinheit angeben. Auf der Anwendungseinheit können die Anwendungen und ihre QoS-Anforderungen bekannt sein. Durch Senden dieser QoS-Profile zu der Modemeinheit und entsprechendes Einstellen der Parameter der Modemeinheit kann der Gesamtdatenfluss des verteilten Systems optimiert werden und die QoS-Anforderungen der Anwendungen können so weit wie möglich erfüllt werden. Weiterhin könnten tatsächliche Parameter, die die tatsächliche Flusssituation des Systems angeben, auf der Anwendungseinheit und/oder der Modemeinheit gesammelt werden. Um den Gesamtdatenfluss in einem verteilten System zu optimieren, muss jede der Einheiten den Datenfluss auf den abgesetzten Einheiten kennen, weil es dadurch möglich wird, die Parameter der eigenen Einheit gemäß dem Gesamtdatenfluss des Systems einzustellen. Auf der Modemeinheit gesammelte Flussparameter und QoS-Parameter könnten z.B. als Teil der Flusssteuerinformationen der Anwendungseinheit zugeführt werden. Die Einstellungen auf der Anwendungseinheit können dann entsprechend angepasst werden. Umgekehrt könnte die Anwendungseinheit die Modemeinheit über diese Arten von Datenverkehr, über Pufferfüllstände und andere Flussparameter informieren. Der Austausch von Flussparametern hilft dabei, geeignete Steuereinstellungen zur Verbesserung des Gesamtdatenflusses zu finden. Sowohl die Modemeinheit als auch die Anwendungseinheit erhalten ein vollständiges Bild und deshalb wird die Entscheidungsfindung verbessert. Durch Prädiktionsverfahren könnten aus den tatsächlichen Flussparametern Parameter abgeleitet werden, die einen zukünftigen Systemzustand anzeigen. Die Prädiktionen könnten z.B. das Auftreten von Stau, Zellenneuauswahlen, plötzlichen Änderungen der verfügbaren Bandbreite usw. antizipieren. Durch Vorhersage des Systemverhaltens in der nahen Zukunft wird eine sanfte Steuerung der Einstellungen des Systems erreicht. Um die Anwendungseinheit über Prädiktionen, die auf der Modemeinheit berechnet wurden, zu informieren, werden die Prädiktionen als Teil der Flusssteuerinformationen zu der Anwendungseinheit gesendet. Umgekehrt könnten die Anwendungseinheit ihre Prädiktionen der Modemeinheit zuführen.

Gemäß einer anderen bevorzugten Ausführungsform der Erfindung umfassen die Flusssteuerinformationen Steuereinstellungen, die dafür ausgelegt sind, den Datenfluss auf der Anwendungseinheit und/oder der Modemeinheit zu steuern. Zum Beispiel können seitens der Modemeinheit Steuereinstellungen für das gesamte System erzeugt werden. Die Steuereinstellungen umfassen Steuereinstellungen für Entitäten auf der Anwendungseinheit, die als Teil der Flusssteuerinformationen von der Modemeinheit zu der Anwendungseinheit gesendet werden müssen. Immer dann, wenn Steuereinstellungen für eine Entität auf einer abgesetzten Einheit erzeugt werden, müssen die Steuereinstellungen als Teil der Flusssteuerinformationen über die mindestens eine physische Schnittstelle übertragen werden.

Bei einer bevorzugten Ausführungsform der Erfindung ist die Anwendungseinheit dafür ausgelegt, von der Modemeinheit Steuereinstellungen für die Anwendungen, Steuereinstellungen für die Protokollstapel und/oder Steuereinstellungen für Puffer zu empfangen. Die Steuereinstellungen können als Teil der Flusssteuerinformationen übertragen werden.

Gemäß einer anderen bevorzugten Ausführungsform der Erfindung ist die Anwendungseinheit dafür ausgelegt, zu der Modemeinheit folgendes zu senden: Informationen über die Anwendungen, QoS-Profile der Anwendungen, Informationen über die von den Anwendungen verwendeten Protokolle, Arten des Datenverkehrs, Bandbreite pro Verkehrstyp, Maximalpuffergrößen und/oder Pufferfüllstände. Die Informationen werden als Teil der Flusssteuerinformationen übertragen.

Gemäß einer weiteren bevorzugten Ausführungsform ist die Anwendungseinheit dafür ausgelegt, folgendes zu der Modemeinheit zu senden: Prädiktionen in bezug auf Zellenneuauswahlen, Prädiktionen in bezug auf Durchsatz, Prädiktionen in bezug auf Bitfehlerrate, Prädiktionen in bezug auf das Codierungsverfahren, Prädiktionen in bezug auf die einseitige Verzögerung und/oder Prädiktionen in bezug auf die Gesamtlaufzeit, wobei die Prädiktionen als Teil der Flusssteuerinformationen übertragen werden. Prädiktionen, die auf der Anwendungseinheit berechnet werden müssen, könnten der Modemeinheit zugeführt werden, weil beispielsweise möglicherweise die Einstellungen des Übertragungsprotokollstapels entsprechend eingestellt werden müssen. Wegen der geringen Übertragungsverzögerung sind die Prädiktionen immer noch wertvoll, wenn sie an der Modemeinheit ankommen. Falls das Verarbeitungssystem der Modemeinheit zur Durchführung von Berechnungen verwendet wird, z.B. um Zellenneuauswahlen vorherzusagen, könnten die mit der Modemeinheit verbundenen Anwendungseinheiten benachrichtigt werden. In beiden Fällen werden die Prädiktionen als Teil der Flusssteuerinformationen über die mindestens eine physische Schnittstelle übertragen.

Gemäß einer bevorzugten Ausführungsform wird eine Menge virtueller Schnittstellen verwendet, um eine oder mehrere Datenverbindungen über die mindestens eine physische Schnittstelle aufzubauen, aufrechtzuerhalten und abzuschließen. Über die mindestens eine physische Schnittstelle müssen sehr viele verschiedene Datenströme übertragen werden, wobei die Datenströme völlig unterschiedliche Eigenschaften aufweisen könnten und wobei den Datenströmen unterschiedliche Prioritäten zugewiesen sein könnten. Ein Teil der Datenströme könnte aus verschiedenen Arten von Anwendungen stammen, andere könnten Flusssteuerinformationen enthalten usw. Die Datenströme werden verschiedenen virtuellen Schnittstellen zugeführt. Dies ermöglicht eine Unterscheidung zwischen den Datenströmen und die Verarbeitung jeder der Datenströme gemäß seiner Priorität und seinen spezifischen Bedürfnissen.

Gemäß einer bevorzugten Ausführungsform der Erfindung wird eine permanente Verbindung mit hoher Priorität zwischen der Anwendungseinheit und der Modemeinheit aufgebaut, wobei die Flusssteuerinformationen über die Verbindung mit hoher Priorität übertragen werden.

Wenn gemessene Daten, QoS-Parameter, Prädiktionen und Steuereinstellungen zwischen der Modemeinheit und der Anwendungseinheit übertragen werden, darf die Übertragungsverzögerung nicht zu hoch sein. Andernfalls sind die Flusssteuerinformationen bereits veraltet, wenn sie empfangen werden. Aus diesem Grund muss dem Flusssteuerkanal eine hohe Priorität zugewiesen werden.

Gemäß einer bevorzugten Ausführungsform ist die mindestens eine physische Schnittstelle dafür ausgelegt, den Datenverkehr und die Flusssteuerinformationen in einem gemultiplexten Modus zwischen der Anwendungseinheit und der Modemeinheit zu übertragen. Die durch die mindestens eine physische Schnittstelle bereitgestellte Übertragungsbandbreite muss gemeinsam von verschiedenen Datenströmen benutzt werden. Durch Übertragen von Daten verschiedener Datenströme in einem gemultiplexten Modus können mehrere verschiedene Datenströme gleichzeitig übertragen werden, wobei die Datenströme einander nicht stören.

Bei einer anderen bevorzugten Ausführungsform umfasst die Anwendungseinheit mindestens zwei physische Schnittstellen, wobei die Flusssteuerinformationen über andere physische Schnittstellen als der Datenverkehr übertragen werden.

Gemäß einer bevorzugten Ausführungsform der Erfindung umfasst die Anwendungseinheit ein erstes Kommunikations-Handler-Modul, das dafür ausgelegt ist, Datenverkehr zwischen funktionalen Entitäten der Anwendungseinheit und der Modemeinheit zu koordinieren und zu priorisieren. Der erste Kommunikations-Handler kann z.B. vielfältige Dienste bereitstellen, die die Zuteilung, Administration und den Abschluss von Verbindungen über die mindestens eine physische Schnittstelle betreffen. Er kann den Datenströmen, die über die mindestens eine physische Schnittstelle zu übertragen sind, Prioritäten zuweisen, um sicherzustellen, dass die wichtigsten Datenströme auch dann übertragen werden, wenn die verfügbare Bandbreite nicht ausreicht, um allen Verkehr zu führen.

Gemäß einer weiteren bevorzugten Ausführungsform der Erfindung umfasst die Anwendungseinheit ein erstes Controllermodul, das dafür ausgelegt ist, mindestens auf der Anwendungseinheit gesammelte Flusssteuerinformationen und/oder über die mindestens eine physische Schnittstelle empfangene Flusssteuerinformationen zu empfangen und aus den Eingaben Steuereinstellungen so abzuleiten, dass der Gesamtdatenfluss optimiert wird. Dem ersten Controllermodul könnten z.B. Flusssteuerinformationen aus der Anwendungseinheit, aus der Modemeinheit oder aus beiden Einheiten zugeführt werden. Das erste Controllermodul könnte z.B. die QoS-Profile der Anwendungen, den tatsächlichen Zustand des Datenflusses in dem Benutzergerät und Prädiktionen, die durchgeführt wurden, kennen. Das erste Controllermodul ist für die Entscheidungsfindung verantwortlich, d.h. es muss Steuereinstellungen aus den bekannten Informationen ableiten. Die Aufgabe besteht darin, beliebige Parameter auf der Anwendungseinheit, auf der Modemeinheit oder auf beiden Einheiten so einzustellen, dass der Gesamtdatenfluss auf dem verteilten System optimiert wird. Es wird versucht, die verfügbaren Betriebsmittel so zu benutzen, dass die Anforderungen der verschiedenen Arten von Datenverkehr so weit wie möglich erfüllt werden können.

Bei einer bevorzugten Ausführungsform der Erfindung kann das erste Controllermodul als primärer Controller wirken, der ein zweites Controllermodul auf der Modemeinheit steuert. Falls ein erstes Controllermodul auf der Anwendungseinheit und ein zweiter Controller auf der Modemeinheit existieren, könnte es vorteilhaft sein, einen der beiden Controllermodule als primären Controller auszuwählen, der für die Erzeugung der Steuereinstellungen für das gesamte System oder mindestens für Teile des gesamten Systems verantwortlich ist. Wenn eine zentrale Instanz für die Entscheidung über die Steuereinstellungen verantwortlich ist, wird ein kohärenter und gut koordinierter Satz Steuereinstellungen erzeugt. Es könnte vorteilhaft sein, das erste Controllermodul der Anwendungseinheit als primären Controller auszuwählen, weil möglicherweise auf der Anwendungseinheit viel mehr Speicher und Rechenleistung als auf der Modemeinheit verfügbar ist.

Gemäß einer weiteren bevorzugten Ausführungsform der Erfindung kann das erste Controllermodul als sekundärer Controller wirken, der durch ein zweites Controllermodul auf der Modemeinheit gesteuert wird. Das zweite Controllermodul auf der Modemeinheit könnte genauso gut als ein primärer Controller ausgewählt werden. In diesem Fall könnte das erste Controllermodul auf der Anwendungseinheit als der Slave des zweiten Controllermoduls wirken.

Insbesondere wenn zwei oder mehr Anwendungseinheiten mit einer Modemeinheit verbunden sind, ist es vorteilhaft, das zweite Controllermodul auf der Modemeinheit als primären Controller einzurichten.

Gemäß einer bevorzugten Ausführungsform der Erfindung umfasst die Anwendungseinheit mindestens ein Protokolloptimierermodul, das dafür ausgelegt ist, auf die Einstellungen entsprechender Protokollstapel vorzugsweise gemäß Steuereinstellungen zuzugreifen.

Gemäß einer bevorzugten Ausführungsform der Erfindung umfasst die Anwendungseinheit ein erstes QoS-Paketprozessormodul, das dafür ausgelegt ist, den Datenverkehr zwischen mindestens einem der Protokollstapel und der mindestens einen physischen Schnittstelle zu überwachen und/oder zu modifizieren. Bevor Datenverkehr einer beliebigen der auf der Anwendungseinheit installierten Anwendungen über die mindestens eine physische Schnittstelle zu der Modemeinheit weitergeleitet werden kann, muss der Datenverkehr den ersten QoS-Paketprozessor durchlaufen. Dadurch entsteht eine Gelegenheit zur Überwachung des Datenverkehrs, und unbekannte Typen von Datenverkehr können durch das QoS-Verwaltungssystem erkannt und berücksichtigt werden. Darüber hinaus kann das erste QoS-Paketprozessormodul bestimmte Datenströme aktiv modifizieren, indem Datenpakete zurückerhalten oder sogar verworfen werden. Das erste QoS-Paketprozessormodul könnte Steuereinstellungen von einer jeweiligen Primärsteuerung erhalten, gleichgültig, ob die Primärsteuerung sich auf der Anwendungseinheit oder der Modemeinheit befindet.

Gemäß einer bevorzugten Ausführungsform der Erfindung umfassen die Protokollstapel WAP-, TCP-, WTCP-, UDP-, UDP-Lite- und/oder RTP/RTCP-Protokoll-Stapel.

Eine Modemeinheit für Mobilkommunikation gemäß Ausführungsformen der vorliegenden Erfindung umfasst eine Rundsendeeinrichtung, die dafür ausgelegt ist, eine drahtlose Verbindung für Mobilkommunikation einzurichten. Die Modemeinheit umfasst ferner mindestens einen Übertragungsprotokollstapel, der dafür ausgelegt ist, Datenverkehr zwischen der Rundsendeeinrichtung und mindestens einer physischen Schnittstelle zu transferieren. Die mindestens eine physische Schnittstelle ist dafür ausgelegt, Datenverkehr sowie Flusssteuerinformationen zwischen der Modemeinheit und mindestens einer Anwendungseinheit zu übertragen. Gemäß Ausführungsformen der vorliegenden Erfindung ermöglicht die Modemeinheit einen Austausch von Flusssteuerinformationen zwischen der mindestens einen Anwendungseinheit und der Modemeinheit. Insbesondere könnte z.B. die Modemeinheit über den Datenfluss auf der Anwendungseinheit informiert werden und könnte z.B. mindestens eine Anwendungseinheit über ihren tatsächlichen Status informieren. Durch Austausch von Flusssteuerinformationen wird die Gesamtsteuerung des Systems verbessert. Es wird eine reibungslose Anpassung der Steuereinstellungen des Systems erzielt und die QoS-Anforderungen der Anwendungen können zu einem Grad erfüllt werden, der bisher nicht möglich war.

Bei einer bevorzugten Ausführungsform der Erfindung ist die Modemeinheit dafür ausgelegt, zumindest einer der Anwendungseinheiten folgendes zu senden: Parameter der Funkverbindung, Signalstärke der drahtlosen Verbindung, Parameter des Übertragungsprotokollstapels, verfügbare Bandbreite, maximale Puffergrößen, Pufferfüllstände, Informationen über PDP-Kontexte und/oder Funkbetriebsmittelverwaltungsinformationen. Die Informationen werden als Teil der Flusssteuerinformationen gesendet.

Gemäß einer bevorzugten Ausführungsform der Erfindung ist die Modemeinheit dafür ausgelegt, von mindestens einer der Anwendungseinheiten folgendes zu empfangen: Informationen über die Anwendungen, QoS-Profile der Anwendungen, Informationen über die von den Anwendungen verwendeten Protokolle, Typen von Datenverkehr, Bandbreite pro Verkehrstyp, maximale Puffergrößen und/oder Puffer-Füllstände. Die Informationen werden als Teil der Flusssteuerinformationen gesendet. Somit können die Steuereinstellungen auf der Modemeinheit z.B. auf die QoS-Anforderungen der zu übertragenden Datenströme eingestellt werden.

Gemäß einer bevorzugten Ausführungsform der Erfindung ist die Modemeinheit dafür ausgelegt, von mindestens einer der Anwendungseinheiten folgendes zu empfangen: Steuereinstellungen für den Übertragungsprotokollstapel, Steuereinstellungen für PDP-Kontexte und/oder Steuereinstellungen für Puffer. Die Steuereinstellungen werden als Teil der Flusssteuerinformationen gesendet.

Bei einer bevorzugten Ausführungsform der Erfindung werden die Anwendungs-QoS-Profile durch folgendes berücksichtigt: Einstellung von PDP-Kontexten, Einstellung von PDP-Subkontexten, und/oder Einstellung oder Modifikation von GGSN-Filterregeln. Ein Kontext des Paketdatenprotokolls (PDP) ermöglicht die Definition der Übertragungseigenschaften für eine bestimmte Art von Datenverkehr. Mittels eines PDP-Kontexts ist es möglich, die Übertragungsparameter des Übertragungsprotokollstapels sowie die Übertragungseigenschaften der drahtlosen Verbindung bis herauf zu dem GGSN (Gateway-GPRS-Unterstützungsknoten) des Mobilkommunikationsnetzes zu spezifizieren.

Gemäß einer bevorzugten Ausführungsform der Erfindung umfasst die Modemeinheit ein zweites QoS-Paketprozessormodul, das dafür ausgelegt ist, den Datenverkehr zwischen der mindestens einen physischen Schnittstelle und dem Übertragungsprotokollstapel zu überwachen und/oder zu modifizieren. Zusätzlich zu durch Anwendungen auf der Anwendungseinheit erzeugtem Datenverkehr könnte das zweite QoS-Paketprozessormodul außerdem Verkehr erkennen, der aus Anwendungen auf der Modemeinheit entsteht, und kann Bandbreiten und QoS-Anforderungen des Datenverkehrs identifizieren. Steuereinstellungen können dann so gewählt werden, dass die jeweiligen Anforderungen der Anwendung (einschließlich derjenigen auf der Modemeinheit) so weit wie möglich erfüllt werden.

Gemäß einer bevorzugten Ausführungsform der Erfindung umfasst die Modemeinheit einen Befehls-Interpreter, der dafür ausgelegt ist, Nachrichten und/oder Befehle, die von mindestens einer der Anwendungseinheiten ausgegeben werden, insbesondere zum Empfangen und Verarbeiten von Initialisierungsnachrichten zu empfangen und zu verarbeiten. Der Befehls-Interpreter überwacht den Datenverkehr, der über die mindestens eine physische Schnittstelle zu der Modemeinheit gesendet wird. Wenn in dem Datenverkehr ein bestimmter Befehl erkannt wird, wird der Befehl interpretiert und die entsprechenden Aktionen werden ausgeführt. Die von dem Befehls-Interpreter bereitgestellten Dienste sind insbesondere nützlich, falls eine Anwendung auf einer beliebigen der Anwendungseinheiten beabsichtigt, Daten über die Funkschnittstelle zu senden, obwohl die Entitäten auf der Modemeinheit noch nicht initialisiert wurden. In diesem Fall sendet die jeweilige Anwendungseinheit Initialisierungsnachrichten über die mindestens eine physische Schnittstelle. Auf der Modemeinheit erkennt der Befehls-Interpreter die Initialisierungsnachrichten. Der Befehls-Interpreter könnte eine Initialisierung der erforderlichen Entitäten veranlassen und das Modem kann dann mit dem Übertragen von Daten über die drahtlose Verbindung beginnen. Somit ermöglicht der Befehls-Interpreter eine Ferninitialisierung von Entitäten auf der Modemeinheit.

Bei einer bevorzugten Ausführungsform der Erfindung ist der Übertragungsprotokollstapel ein Stapel für: GPRS/GSM, GPRS/EDGE, CDMA, UMTS, wireless LAN, Bluetooth und/oder HiperLan. Die Erfindung ist jedoch auf keinerlei Weise auf irgendwelche der erwähnten Übertragungsprotokolle beschränkt.

Ein Benutzergerät könnte wie oben beschrieben mindestens eine Anwendungseinheit und eine Modemeinheit umfassen, wobei die Einheiten über mindestens eine physische Schnittstelle verbunden sind. Datenverkehr sowie Flusssteuerinformationen werden über die mindestens eine physische Schnittstelle zwischen mindestens einer der Anwendungseinheiten und der Modemeinheit übertragen. Durch Austauschen von Flusssteuerinformationen zwischen der Modemeinheit und der einen oder den mehreren Anwendungseinheiten können die Einheiten enger zueinandergebracht werden. Gemessene Daten und Prädiktionen werden von verschiedenen Teilen des Systems gesammelt und die Anwendungseinheiten könnten z.B. die Modemeinheit über die QoS-Profile der verschiedenen Anwendungen informieren. Aus diesen Eingaben werden Steuereinstellungen für das gesamte System abgeleitet und die Steuereinstellungen werden zu den verschiedenen Entitäten verteilt. Folglich verschmelzen die Modemeinheit und die eine oder die mehreren Anwendungseinheiten und arbeiten zusammen als ein System.

Gemäß einer bevorzugten Ausführungsform der Erfindung werden die Modemeinheit und mindestens eine der Anwendungseinheiten als eine eingebettete mobile Einrichtung, vorzugsweise als Smartphones, implementiert. Innerhalb der eingebetteten Einrichtung könnten die Anwendungseinheit und die Modemeinheit z.B. auf verschiedenen Verarbeitungssystemen ablaufen. Auf der Modemeinheit könnte ein erstes Betriebssystem verwendet werden, während auf der Anwendungseinheit ein anderes Betriebssystem, z.B. Symbian, verwendet werden könnte, das sich besser für die jeweiligen Anwendungen eignet.

Gemäß einer weiteren bevorzugten Ausführungsform wird die Modemeinheit als separate Einrichtung implementiert, vorzugsweise als CF-Karte, als PCMCIA-Karte oder als Teil eines Mobiltelefons. Gemäß einer bevorzugten Ausführungsform der Erfindung wird mindestens eine der Anwendungseinheiten als separate Einrichtung implementiert, vorzugsweise als Laptop, als mobiles Endgerät oder als PDA. Ein Benutzerendgerät muss nicht unbedingt eine Modemeinheit umfassen. Statt dessen könnte es mindestens eine physische Schnittstelle zum Herstellen einer Verbindung mit einer externen Modemeinheit umfassen.

Die Module gemäß Ausführungsformen der vorliegenden Erfindung können teilweise oder vollständig durch geeignete Software realisiert oder unterstützt werden, die auf einer beliebigen Art von Datenträger gespeichert oder anderweitig bereitgestellt werden kann und die in oder durch eine beliebige geeignete Datenverarbeitungseinheit ausgeführt werden kann.

Weitere Aufgaben und viele der einhergehenden Vorteile der vorliegenden Erfindung werden durch Bezugnahme auf die folgende ausführliche Beschreibung in Verbindung mit den beigefügten Zeichnungen ohne weiteres ersichtlich und werden besser verständlich.

1 zeigt eine Anwendungseinheit, die Teil eines Benutzergeräts zur Mobilkommunikation ist, zusammen mit einem Teil einer Modemeinheit;

2 zeigt eine Modemeinheit, die Teil eines Benutzergeräts für Mobilkommunikation ist, zusammen mit einem Teil der Anwendungseinheit von 1;

3 zeigt die Protokollschichten, die zum Senden von Daten in einem gemultiplexten Modus über die physische Schnittstelle verwendet werden können;

4 zeigt die Struktur des zum Flusssteuerinformationstransfer von einem Modem zu einer Anwendungseinheit gemäß einer alternativen Ausführungsform verwendeten Systems;

5 zeigt Implementierungsvarianten für den Anwendungseinheit-Kollektor;

6 zeigt ein IP-Paket für Messungstransfer unter Verwendung einer proprietären Protokollerweiterung; und

7 zeigt ein UDP/IP-Paket zum Messungstransfer unter Verwendung einer proprietären Protokollerweiterung.

1 und 2 zeigen ein Benutzergerät für Mobilkommunikation, das eine Anwendungseinheit 1 und eine Modemeinheit 2 umfasst. Die Anwendungseinheit 1 und die Modemeinheit 2 sind über eine physische Schnittstelle 3 verbunden. Auf der Anwendungseinheit 1 könnten mehrere Benutzeranwendungen ablaufen. In dem in 1 gezeigten Beispiel umfassen die Anwendungen E-Mail 4, einen Web-Browser 5, DSR (Digital Surveillence Recorder), Push2Talk 6, Video Conference 7, MMS (Multimedia Messaging Service), IM (Instant Messaging) usw. Die Anwendungseinheit 1 könnte ferner Transportprotokollstapel mit Protokollschichten umfassen, wie z.B. RTP/RTCP (Real Time Transport Protocol, Real Time Transport Control Protocol), RSVP (Resource Reservation Protocol), WSP (Wireless Session Protocol), UDP (User Datagram Protocol), UD-PLite TCP (Transmission Control Protocol), WTCP (Wireless profiled TCP), WAP (Wireless Application Protocol) usw. Die Transportprotokollstapel transformieren die Nutzdaten der verschiedenen Anwendungen in Pakete des IP (Internet-Protokoll). Die anwendungsbezogenen Daten und insbesondere die IP-Pakete werden über die physische Schnittstelle 3 mit der Modemeinheit 2 ausgetauscht. Die physische Schnittstelle 3 könnte z.B. gemäß einem der Standards RS232, USB (Universal Serial Bus), Bluetooth, IrDA (Infrared Data Association), PCMCIA usw. oder UART (Universal Asynchronous Receiver – Transmitter) realisiert werden.

Die Modemeinheit 2 wird als separate Einheit implementiert. Die Modemeinheit 2 ist für das Herstellen und Aufrechterhalten einer drahtlosen Verbindung mit einem Mobilkommunikationsnetz verantwortlich. Für diesen Zweck umfasst die Modemeinheit 2 mindestens einen Übertragungsprotokollstapel 8. Der Übertragungsprotokollstapel 8 könnte z.B. ein GPRS/GSM-Stapel, ein GPRS/EDGE-Stapel oder ein Stapel für ein zukünftiges Übertragungsprotokoll wie etwa UMTS sein. IP-Pakete, die aus der Anwendungseinheit 1 über die physische Schnittstelle 3 empfangen werden, werden zu dem Übertragungsprotokollstapel 8 transferiert. Umgekehrt werden über die drahtlose Verbindung empfangene Daten dem Übertragungsprotokollstapel 8 zugeführt und werden über die physische Schnittstelle 3 zu der Anwendungseinheit 1 geroutet. Die Modemeinheit 2 könnte ferner interne Anwendungen 9 und entsprechende Protokollstapel umfassen, die dafür ausgelegt sind, Datenverkehr mit dem Übertragungsprotokollstapel 8 auszutauschen.

Bei dem in 1 und 2 gezeigten Aufbau werden die Anwendungseinheit 1 und die Modemeinheit 2 als separate Einheiten realisiert. Zum Beispiel könnte die Anwendungseinheit 1 auf einer ersten CPU (oder einem ersten DSP) ablaufen, wobei ein erstes Betriebssystem verwendet wird, während die Modemeinheit 2 auf einer zweiten CPU (oder einem zweiten DSP) ablaufen könnte, wobei ein zweites Betriebssystem verwendet wird. Ein solcher Aufbau könnte sich zum Beispiel auf einem so genannten Smartphone befinden, wobei ein eigenes Betriebssystem wie etwa z.B. Symbian auf der Anwendungseinheit des Smartphone installiert sein könnte. Für die Endbenutzer sehen diese Einrichtungen genauso wie Mobiltelefoneinrichtungen aus, obwohl die Anwendungseinheit und die Modemeinheit als separate Einheiten implementiert sind. Die Anwendungseinheit 1 und die Modemeinheit 2 könnten genauso gut auf verschiedenen mobilen Endgeräten implementiert werden. Zum Beispiel könnte eine mobile Einrichtung wie etwa ein Telefon als Modem für eine zweite Einrichtung wie etwa z.B. ein Laptop oder ein PDA (persönlichen digitalen Assistenten) verwendet werden, wobei Anwendungen wie E-Mail, Web-Browser, VoIP-Client, Video-Anwendungen usw. seitens der zweiten Einrichtung ausgeführt werden. Das Mobiltelefon umfasst die Modemeinheit und die zweite Einrichtung wirkt als Anwendungseinheit. Als Alternative könnte die Modemeinheit 1 ein eigenes Harwareelement sein, wie etwa eine CF-Karte (Compact Flash), eine PCMCIA-Karte oder dergleichen.

Im folgenden werden die Struktur und Funktionalität eines QoS-Verwaltungssystems für die oben erwähnte Art von Benutzergeräten beschrieben. Es muss erwähnt werden, dass die Erfindung auch verwendet werden kann, wenn zwei oder mehr Anwendungseinheiten mit einer Modemeinheit verbunden sind. Weiterhin könnte die mindestens eine Anwendungseinheit mit zwei oder mehr verschiedenen Modemeinheiten verbunden sein, die verschiedene Übertragungsstandards unterstützen.

Die seitens der Anwendungseinheit 1 ablaufenden Anwendungen werden von verschiedenen Drittfirmen bereitgestellt. Ein Teil dieser Anwendungen (zum Beispiel E-Mail 4 und der Web-Browser 5) ist sich möglicherweise nicht über das QoS-Verwaltungssystem bewusst.

Andere Anwendungen, wie DSR, Push2Talk 6, Video Conference 7, MMS und IM könnten sich über das QoS-Verwaltungssystem bewusst sein. Für diese Anwendungen ist der externe Anwendungs-Manager 10 sichtbar. Die Anwendungen, die sich über das QoS-Verwaltungssystem bewusst sind, registrieren sich (11) bei dem externen Anwendungsmanager 10 und leiten ihre jeweiligen QoS-Anforderungen zu dem externen Anwendungsmanager 10 weiter. Die QoS-Anforderungen der Anwendungen werden gewöhnlich über QoS-Klassen spezifiziert. Im allgemeinen werden vier grundlegende QoS-Klassen verwendet, die von dem 3GPP (Partnerschaftsprojekt für die 3. Generation) definiert worden sind, obwohl auch andere Klassifikationen verwendet werden könnten.

Verkehr der Konversationsklasse ist sehr verzögerungsempfindlich, und Transferverzögerung und Zeitvarianz zwischen Paketen müssen unter einem bestimmten Wert bleiben, damit die menschliche Wahrnehmung die Qualität der Verbindung annimmt. Für Verkehr der Konversationsklasse ist es höchst wichtig, dass Daten rechtzeitig abgeliefert werden. Die Bitfehlerrate (BER) des Datenverkehrs ist nicht so kritisch. Beispiele für Verkehr der Konversationsklasse wären IP-Telefonie und Video-Telefonie. In dem Beispiel von 1 gehört Datenverkehr der Anwendung Video Conference 7 zu der Konversationsklasse.

Verkehr der Streaming-Klasse umfasst einseitigen Echtzeitverkehr. Für Verkehr der Streaming-Klasse ist nicht unbedingt eine niedrige Transferverzögerung erforderlich, aber die Verzögerungsschwankung in dem Echtzeit-Datenstrom sollte begrenzt sein. In 1 gehört Datenverkehr der Anwendung Push2Talk 6 zu der Streaming-Klasse.

Verkehr dieser Klasse könnte z.B. aus einer Anwendung stammen, bei der ein Benutzer Daten interaktiv mit einem Gegenüber austauscht, bei dem es sich entweder um einen anderen Benutzer oder ein Computersystem handeln könnte. Die Antwort auf eine Anforderung wird im allgemeinen innerhalb einer bestimmten Zeitgrenze erwartet. Obwohl die Transferverzögerung höher als im Fall von Verkehr der Konversationsklasse sein kann, ist die Gesamtlaufzeit (RTT) ein Schlüsselparameter. Verkehr der interaktiven Klasse sollte eine niedrige BER zeigen. Beispiele für diese Art von Verkehr wären Web-Browsing oder Telnet. In dem Beispiel von 1 gehört Datenverkehr der Anwendung IM zu der interaktiven Klasse.

Für Datenverkehr der Hintergrundklasse ist niedrige Verzögerung oder kurze Ablieferzeit kein Problem, aber die Bitfehlerrate (BER) muss niedrig sein. Datenverkehr dieser Klasse wird gewöhnlich von einem Computer empfangen. E-Mail-Verkehr ist ein typisches Beispiel für diese Art von Verkehr. Folglich gehört Datenverkehr der Anwendung E-Mail 4 in 1 zu der Hintergrundklasse.

Für mindestens bestimmte der Anwendungen, die sich über das QoS-Verwaltungssystem bewusst sind, könnten so genannte Anwendungsoptimierer installiert werden. In 1 umfassen die Anwendungen DSR, Push2Talk 6, Video Conference 7, MMS und IM entsprechende Anwendungsoptimierer 12–16. Wenn eine Anwendung beabsichtigt, Daten zu senden, könnte der entsprechende Anwendungsoptimierer die Art und Weise der Erzeugung der Daten auf den Gesamtdatenfluss einstellen, auf die verfügbare Bandbreite, auf die Eigenschaften der drahtlosen Verbindung usw. Insbesondere könnten die Anwendungsoptimierer 12–16 das Timing, die Verpackung von Daten und die Anzahl der Anwendungsrahmen pro Datenpaket beeinflussen, wobei die QoS-Profile der Anwendungen berücksichtigt werden. Während der Initialisierung registrieren sich die Anwendungsoptimierer 12–16 bei dem externen Anwendungsmanager 10. Während des Betriebes könnten die Anwendungsoptimierer 12–16 Steuerinformationen 12 von der externen Hauptsteuerung 18 empfangen, wobei die Steuerinformationen 17 Steuereinstellungen für die Anwendungsoptimierer 12–16 umfassen.

Als nächstes initialisiert der externe Anwendungsmanager 10 (19) den externen Protokollmanager 20. Der externe Protokollmanager 20 wird über die auf der Anwendungseinheit 1 ablaufenden Anwendungen, über die von den Anwendungen verwendeten Transportprotokolle und über die jeweiligen QoS-Profile des Datenverkehrs der Anwendungen informiert.

Für mindestens einen Teil der Transportprotokollstapel könnten sogenannte Protokolloptimierer installiert sein. In 1 sind Protokolloptimierer 21–25 gezeigt, die den Transportprotokollstapeln RTP/RTCP, WSP, USP, USP-Lite und TCP entsprechen. Der externe Protokollmanager 20 initialisiert (26) die Protokolloptimierer 21–25 gemäß den QoS-Profilen der Anwendungen. Jeder der Protokolloptimierer 21–25 ist dafür verantwortlich, dynamisch auf die Eigenschaften seines entsprechenden Transportprotokollstapels zuzugreifen und diese einzustellen. Die Einstellung erfolgt gemäß den entsprechenden Anwendungs-QoS-Anforderungen gemäß dem Gesamtdatenfluss und gemäß gemessenen oder vorhergesagten Systemparametern.

Als nächstes initialisiert (27) der externe Protokollmanager 20 die externe Hauptsteuerung 18 und transferiert die Steuerung der Protokolloptimierer 21–25 zu der externen Hauptsteuerung 18. Später empfangen sowohl die Protokolloptimierer 21–25 als auch der externe Protokollmanager 20 ihre jeweiligen Steuereinstellungen 28 von der externen Hauptsteuerung 18.

Während des Betriebes könnten Änderungen des Aufbaus des Systems und des von den Anwendungen erzeugten Datenverkehrs auftreten, und folglich könnte eine Neuinitialisierung des externen Anwendungsmanagers 10, der Anwendungsoptimierer 12–16, des externen Protokollmanagers 20 und/oder der Protokolloptimierer 21-25 notwendig werden. Die Neuinitialisierungen können entweder durch die Anwendungen selbst oder durch die externe Hauptsteuerung 18 veranlasst werden.

Die Anwendungseinheit 1 und die Modemeinheit 2 kommunizieren über die physische Schnittstelle 3. Zusätzlich zu Aufwärtsstrecken- und Abwärtsstrecken-Datenverkehr in bezug auf verschiedene Anwendungen werden außerdem Flusssteuerinformationen zwischen der Anwendungseinheit 1 und der Modemeinheit 2 übertragen. Die Flusssteuerinformationen könnten z.B. gemessene Parameter, die den tatsächlichen Systemzustand angeben, Prädiktionen, die einen zukünftigen Systemzustand angeben und Informationen in bezug auf die Konfiguration des Systems umfassen. Die Flusssteuerinformationen könnten auch Steuereinstellungen für Entitäten auf der Anwendungseinheit 1 und auf der Modemeinheit 2 umfassen.

Die über die physische Schnittstelle 3 übertragenen verschiedenen Datenströme sollten separat und gemäß ihren jeweiligen Prioritäten gehandhabt werden. Auf der Anwendungseinheit 1 und auf der Modemeinheit 2 werden mehrere virtuelle Schnittstellen 29–32 und 33–36 vorgesehen und die virtuellen Schnittstellen können zum Aufbauen eines oder mehrerer virtueller Kanäle zwischen der Anwendungseinheit 1 und der Modemeinheit 2 verwendet werden. Gemäß einer ersten Ausführungsform wird jeder der virtuellen Schnittstellen dergestalt eine entsprechende physische Schnittstelle zugewiesen, dass eine eindeutige Entsprechung zwischen den virtuellen Schnittstellen und den physischen Schnittstellen hergestellt wird. Wenn nur eine physische Schnittstelle verfügbar ist oder wenn weniger physische Schnittstellen als virtuelle Schnittstellen verfügbar sind, können die Datenströme als Alternative in einem gemultiplexten Modus übertragen werden. Bei dieser Ausführungsform wird sowohl auf der Anwendungseinheit 1 als auch auf der Modemeinheit 2 ein Multiplex-Protokoll 37 implementiert. Das Multiplex-Protokoll 37 ist dafür ausgelegt, mehrere separate virtuelle Schnittstellen bereitzustellen. Das Multiplex-Protokoll 37 ermöglicht ein paralleles Senden mehrerer Datenströme über verschiedene virtuelle Kanäle, wobei den Datenströmen zugewiesene Prioritäten berücksichtigt werden. Folglich kann die Übertragung von Verkehr mit niedrigerer Priorität von Verkehr mit höherer Priorität unterbrochen werden. Das Multiplexen wird durch eine MUX-Steuerung 38 auf der Anwendungseinheit 1 und durch eine MUX-Steuerung 39 auf der Modemeinheit 2 gesteuert. Die MUX-Steuerungen 38, 39 sind für das Aufbauen und Abbauen virtueller Kanäle zwischen den virtuellen Schnittstellen verantwortlich.

Zum Senden von Daten über die physische Schnittstelle 3 in einen Multiplex-Modus könnte zusammen mit bestimmten Erweiterungen die PPP-Suite (Punkt-zu-Punkt-Protokoll) verwendet werden. Die Erweiterungen ermöglichen virtuelle serielle Leitungen und Verkehrspriorisierung. Eine ausführliche Beschreibung der PPP-Protokollsuite findet sich in der Schrift IETF RFC 1661.

Als Alternative kann die PPP-Protokollsuite ohne die erwähnten Erweiterungen mit einem der durch das ETSI (europäisches Telekommunikationsnormeninstitut) definierten Multiplexprotokolle kombiniert werden. Technische Spezifikationen der Multiplexprotokolle finden sich in ETSI, 3GPP TS 07.0 10 und 27.0 10. Gemäß einer dritten Alternative könnten die Anwendungseinheit 1 und die Modemeinheit 2 durch eine IP-Verbindung verbunden werden.

Im folgenden wird die Initialisierung der Schnittstelleneinrichtung beschrieben. Die externe Hauptsteuerung 18 adressiert die MUX-Steuerung 38 und teilt eine virtuelle Schnittstelle zur Herstellung einer schnellen QoSM-Verbindung zwischen der Anwendungseinheit 1 und der Modemeinheit 2 zu. Als nächstes initialisiert (40) die externe Hauptsteuerung 18 den Comm-Handler 41 und die schnelle QoSM-Verbindung 42. Der Comm-Handler 41 ist für die Abwicklung der Kommunikation zwischen Entitäten des QoS-Verwaltungssystems, die sich auf der Anwendungseinheit 1 befinden, und Entitäten, die sich auf der Modemeinheit 2 befinden, verantwortlich. Im Fall von Stau muss der Comm-Handler 41 über die Prioritäten der verschiedenen Datenströme entscheiden.

Die schnelle QoSM-Verbindung 42 ist ein schneller Kommunikationskanal, der für das Übertragen von Flusssteuerinformationen zwischen der Anwendungseinheit 1 und der Modemeinheit 2 ausgelegt ist. Die schnelle QoSM-Verbindung 42 wird permanent auf einem Kanal der Schnittstelle aufgebaut. Flusssteuerinformationen, insbesondere gemessene Daten, Steuereinstellungen und Prädiktionen, müssen mit niedriger Verzögerung übertragen werden. Aus diesem Grund wird der schnellen QoSM-Verbindung 42 eine der höchsten verfügbaren Prioritäten zugewiesen.

Als nächstes gibt der Comm-Handler 41 der Anwendungseinheit Befehle zum Herauffahren einer Hauptsteuerung 43 und eines Comm-Handlers 44 seitens der Modemeinheit 2 aus. Die Befehle werden über die schnelle QoSM-Verbindung 42 zu der Modemeinheit 2 gesendet. Dort werden die Befehle durch einen AT-Befehlsinterpreter 45 detektiert und interpretiert. Gemäß den Befehlen wird die Hauptsteuerung 43 initialisiert (46). Dann initialisiert (47) die Hauptsteuerung 43 den Comm-Handler 44 der Modemeinheit. Zwischen dem Comm-Handler 41 der Anwendungseinheit und dem Comm-Handler 44 der Modemeinheit wird eine Verbindung hergestellt. Sobald diese Verbindung verfügbar ist, informiert der Comm-Handler 41 die externe Hauptsteuerung 18.

Die externe Hauptsteuerung 18 kann nun Flusssteuerinformationen über die Datenstrecke 48 zu dem Comm-Handler 41 weiterleiten. Von dem Comm-Handler 41 aus werden die Flusssteuerinformationen über die schnelle QoSM-Verbindung 42 zu dem Comm-Handler 44 gesendet. Der Comm-Handler 44 leitet die Flusssteuerinformationen über die Datenstrecke 49 zu der Hauptsteuerung 43 weiter. In der entgegengesetzten Richtung kann die Hauptsteuerung 43 Flusssteuerinformationen über die Datenstrecke 49, die schnelle QoSM-Verbindung 42 und die Datenstrecke 48 zu der externen Hauptsteuerung 18 senden. Die externe Hauptsteuerung 18 und die Hauptsteuerung 43 können nun alle Arten von Flusssteuerinformationen austauschen, darunter QoS-Profile, gemessene Parameter, Statistiken, Prädiktionen, Steuereinstellungen usw.

Zuerst wird die Hauptsteuerung 43 als Primärsteuerung installiert, die die externe Hauptsteuerung 18 steuert. Die externe Hauptsteuerung 18 wirkt als Sekundärsteuerung (Slawe). Die externe Hauptsteuerung und die Hauptsteuerung 43 tauschen Informationen über ihre jeweiligen Fähigkeiten und über die Konfiguration der Anwendungseinheit 1 und der Modemeinheit 2 aus. Dann muss die Hauptsteuerung 43 entscheiden, ob es günstig ist, die Primärsteuerung des QoS-Verwaltungssystems an die externe Hauptsteuerung 18 abzugeben oder nicht. Die CPU der Anwendungseinheit 1 könnte im Hinblick auf Verarbeitungsleistung und Speicher viel mehr Betriebsmittel aufweisen und die CPU der Modemeinheit würde von bestimmten ihrer Aufgaben entlastet. Wenn jedoch zwei oder mehr Anwendungseinheiten mit der Modemeinheit verbunden sind, wirkt die Hauptsteuerung 43 höchstwahrscheinlich weiter als Primärsteuerung und steuert die Aufgaben der externen Hauptsteuerungen.

Die primäre Hauptsteuerung ist für das Aufbauen des gesamten QoS-Verwaltungssystems verantwortlich. Sie muss entscheiden, wie die erforderlichen Funktionalitäten an die Entitäten des verteilten QoS-Verwaltungssystems zu verteilen sind. Dann werden die jeweiligen Entitäten entsprechend initialisiert. Zum Beispiel muss die primäre Hauptsteuerung entscheiden, ob ein Zustandsprädiktor auf der Anwendungseinheit 1, auf der Modemeinheit 2 oder auf beiden Einheiten initialisiert werden soll. Die Zustandsprädiktoren könnten komplexe Algorithmen zum Ableiten der jeweiligen Prädiktionen verwenden und folglich verlangen die Zustandsprädiktoren viel Rechenleistung. Aus diesem Grund wäre es vorteilhaft, wenn die Modemeinheit 2 einen Teil der Berechnungen einem auf der Anwendungseinheit 1 ablaufenden externen Zustandsprädiktor überlässt.

Bei dem Aufbau von 1 und 2 umfasst die Modemeinheit 2 einen Zustandsprädiktor 50 und die Anwendungseinheit 1 einen externen Zustandsprädiktor 51. Der Zustandsprädiktor 50 auf der Modemeinheit 2 wird durch die Hauptsteuerung 43 initialisiert (52).

Der Zustandsprädiktor 50 empfängt (53) gemessene Daten und Systemparameter. Die Prädiktionen des Zustandsprädiktors 50 werden aus gemessenen Daten und Systemparametern abgeleitet, die den tatsächlichen Zustand des Systems angeben. Der Zustandsprädiktor 50 umfasst eine Vielzahl verschiedener Zustandsprädiktormodule. Zum Beispiel könnte der Zustandsprädiktor 50 folgendes umfassen: ein Zustandsprädiktormodul 54, das für die Vorhersage von Einweg-Verzögerung, Gesamtlaufzeit (RTT) und Durchsatz ausgelegt ist, ein Zustandsprädiktormodul 54, das für die Vorhersage des Codierungsschemas und der BER (Bitfehlerrate) ausgelegt ist, und ein Zustandsprädiktormodul 56, das für die Vorhersage von Zellenneuauswahlen ausgelegt ist. Während einer Zellenneuauswahl wird die Datenübertragung für einen Zeitraum in der Größenordnung von Sekunden unterbrochen, und deshalb sollte die Hauptsteuerung 43 über Zellenneuauswahlen informiert werden. Die Prädiktionen des Zustandsprädiktors 50 werden der Hauptsteuerung 43 zugeführt (57). Ähnlich wird der externe Zustandsprädiktor 51 durch die externe Hauptsteuerung 18 initialisiert (58). Der externe Zustandsprädiktor 51 empfängt (59) gemessene Daten und Systemparameter. Er umfasst Zustandsprädiktormodule 60, 61 und 62, die dafür ausgelegt sind, vielfältige verschiedene Prädiktionen abzuleiten. Die Prädiktionen werden der externen Hauptsteuerung 18 zugeführt (63).

Ferner initialisiert (64) die externe Hauptsteuerung 18 einen externen QoS-Paketprozessor 65. Der externe QoS-Paketprozessor 65 ist für das Erkennen und Verfolgen verschiedener Arten von Datenverkehr zwischen den Transportprotokollstapeln und der Schnittstelleneinrichtung verantwortlich. Zu diesem Zweck überwacht er sowohl den Aufwärtsstrecken- als auch den Abwärtsstreckenverkehr. Der externe QoS-Paketprozessor 65 erkennt die Bandbreiten und die QoS-Profile der verschiedenen Arten von Datenverkehr.

Auf der Anwendungseinheit 1 könnten Anwendungen existieren, die sich nicht über das QoS-Verwaltungssystem bewusst sind. Zum Beispiel könnten die Anwendungen E-Mail 4 und Web-Browser 5 von 1 zu der Gruppe von Anwendungen gehören, die sich nicht über das QoS-Verwaltungssystem bewusst sind. Wenn eine der Anwendungen beginnt, Datenverkehr zu senden, erkennt der externe QoS-Paketprozessor 65 diese neue Art von Datenverkehr. Immer dann, wenn eine neue Art von Datenverkehr erkannt wird, identifiziert der externe QoS-Paketprozessor 65 diesen Verkehr, die Bandbreite und das QoS-Profil des Verkehrs und identifiziert die Anwendung, die den Verkehr erzeugt hat. Zusätzlich kann der externe QoS-Paketprozessor 65 den Fluss von Datenpaketen modifizieren. Zu diesem Zweck kann der externe QoS-Paketprozessor 65 IP-Pakete bestimmter Datenströme zurückhalten und puffern, wobei Datenpakete von geringer Bedeutung sogar verworfen werden können. Der externe QoS-Paketprozessor 65 empfängt Steuereinstellungen 66 von der externen Hauptsteuerung 18, die angeben, wie die Filter und Puffer einzurichten sind.

Ferner initialisiert (67) die externe Hauptsteuerung 18 einen externen Kollektor 68 auf der Anwendungseinheit 1. Der externe Kollektor 68 ist für das Sammeln von Informationen von verschiedenen Entitäten der Anwendungseinheit 1 verantwortlich. Zum Beispiel empfängt (69) der externe Kollektor 68 Informationen, darunter die Arten von Verkehr, die aktuelle Bandbreite pro Verkehrstyp, die maximalen Puffergrößen, derzeitige Füllstände verschiedener Puffer usw. von dem externen QoS-Paketprozessor 65. Weiterhin könnte der externe Kollektor 68 Rückmeldeinformationen 70 von den Transportprotokollstapeln, z.B. von dem RTP/RTCP-Protokollstapel, empfangen. Der externe Kollektor 68 führt die gesammelten Informationen dem externen Zustandsprädiktor 51 und der externen Hauptsteuerung 18 zu (59, 71). Ähnlich könnte die Modemeinheit 2 einen Kollektor 72 umfassen, der für das Sammeln von Informationen von den Entitäten der Modemeinheit 2 verantwortlich ist.

Zusätzlich zu den auf der Anwendungseinheit 1 ablaufenden Anwendungen könnten interne Anwendungen 9 und die entsprechenden Protokolle auf der Modemeinheit 2 installiert sein. Die internen Anwendungen und Protokolle, die in 2 angegeben sind, könnten zusätzlich folgendes umfassen: einen Anwendungsmanager, einen Protokollmanager, Anwendungsoptimierer und/oder Protokolloptimierer. Die Entitäten sind Teil des QoS-Verwaltungssystems. Sie werden durch die Hauptsteuerung 43 initialisiert (73) und empfangen Steuereinstellungen 74 von der Hauptsteuerung 43.

Neben dem externen QoS-Prozessor 65 auf der Anwendungseinheit 1 könnte die Modemeinheit 2 auch einen QoS-Paketprozessor 75 umfassen, der durch die Hauptsteuerung 43 initialisiert (76) wird. Der QoS-Paketprozessor 75 überwacht den Aufwärtsstrecken- und Abwärtsstrecken-Verkehr. Darüber hinaus könnte er den ihn durchlaufenden Datenverkehr modifizieren. Datenpakete könnten gepuffert werden, bevor sie zu dem Übertragungsprotokollstapel 8 weitergeleitet werden, oder könnten sogar verworfen werden.

Insbesondere erkennt und analysiert der QoS-Paketprozessor 75 Datenverkehr, der aus den internen Anwendungen 9 entsteht. Informationen über verschiedene Arten von Datenverkehr und ihre jeweiligen Bandbreiten werden zu dem Kollektor 72 weitergeleitet (77). Die primäre Hauptsteuerung, z.B. die Hauptsteuerung 43, verarbeitet die von dem externen QoS-Paketprozessor 65 und durch den QoS-Paketprozessor 65 bereitgestellten Informationen. Auf der Basis dieser Informationen entscheidet die primäre Hauptsteuerung, ob die Gesamt-QoS verbessert werden kann, indem ein anderer PDP-Kontext, ein PDP-Subkontext oder eine neue Filterliste für den GGSN (Gateway-GPRS-Unterstützungsknoten) eingerichtet wird. PDP-Kontexte und PDP-Subkontexte erlauben die Definition der Übertragungseigenschaften für eine bestimmte Art von Datenverkehr. Die primäre Hauptsteuerung könnte die Mobilitäts-/Funkbetriebsmittelverwaltung 79 anweisen (78), einen PDP-Kontext oder einen PDP-Subkontext einzurichten oder zu modifizieren. Die Parameter der PDP-Kontexte und PDP-Subkontexte werden gemäß den QoS-Anforderungen des jeweiligen Verkehrs gewählt. Wenn der jeweilige PDP-Kontext oder PDP-Subkontext aktiviert wurde, weist die primäre Hauptsteuerung den QoS-Paketprozessor 75 an (80), diesen PDP-Kontext oder PDP-Subkontext für die weitere Übertragung bestimmter Arten von Datenverkehr zu verwenden.

Der Übertragungsprotokollstapel 8 könnte z.B. ein GPRS/GSM-Stapel, ein GPRS/EDGE-Stapel, ein UMTS-Stapel oder ein Hiper-Lan-Stapel oder ein WLAN-Stapel sein. In der Zukunft könnten andere Übertragungsprotokollstapel verwendet werden, die zukünftige Übertragungsprotokolle betreffen. Im Fall eines GPRS/GSM- oder eines GPRS/EDGE-Stapels ist die oberste Schicht des Stapels eine Schicht des SNDCP (Subnetz-abhängiges Konvergenzprotokoll). Im Fall eines UMTS-Stapels ist die oberste Schicht eine Schicht des PDCP (Paketdaten-Konvergenzprotokolls). Die nachfolgende Schicht, die LLC (logische Streckensteuerung) ist für die Segmentierung der IP-Pakete in für Übertragung geeignete Datenblöcke verantwortlich. Für diesen Zweck umfasst die LLC einen LLC-Puffer 81. Die Datenblöcke werden zu einer Schicht der RLC (Funkstreckensteuerung), die einen RLC-Puffer 82 umfasst, weitergeleitet. Die Datenblöcke werden der physischen Schicht L1 zugeführt, die die niedrigste Schicht des Übertragungsprotokollstapels 8 ist. Die Hauptsteuerung 43 kann einen LLC-Manager 84 initialisieren (83) der Teil des QoS-Verwaltungssystems ist. Der LLC-Manager 84 kann verschiedene Parameter der LLC setzen, LLC-Blöcke löschen oder LLC-Blöcke umordnen. Ähnlich kann die Hauptsteuerung 43 einen RLC-Manager 86, der für das Zugreifen auf die Einstellungen der RLC und für das Modifizieren der RLC-Datenblöcke ausgelegt ist, initialisieren (85).

Die Steuereinstellungen des Übertragungsprotokollstapels 8 können durch einen Stapelmanager 88, der durch die Hauptsteuerung 43 initialisiert (89) und gesteuert (90) wird, dynamisch angepaßt (87) werden. Es bestehen vielfältige Möglichkeiten, wie der Stapelmanager 88 dies erreichen kann: Der Stapelmanager 88 kann z.B. die Mobilitäts-/Funkbetriebsmittelverwaltung 79 so beeinflussen (91), dass eine Zellenneuauswahl entweder eingeleitet oder verzögert wird. Ferner könnte er den RLC-Puffer 82 zurücksetzen und/oder gewählte PDU (Protokolldateneinheiten) in dem RLC-Puffer 82 löschen. Außerdem könnte der Stapelmanager 88 bei der Administration von PDP-Kontexten und PDP-Subkontexten beteiligt sein. Ferner könnte der Stapelmanager 88 beim Einrichten der Filterregeln des GGSN gemäß den QoS-Anforderungen des jeweiligen Verkehrs beteiligt sein. Durch Setzen des RLC-Modus könnte der Stapelmanager 88 spezifizieren, ob ein bestätigter oder ein unbestätigter Modus für die Datenübertragung verwendet werden soll, und wie die Ablieferung defekter RLC-Blöcke gehandhabt werden soll.

Die Mobilitäts-/Funkbetriebsmittelverwaltung 79 ist für die Mobilitätsverwaltung, für Autorisierung und für das Herstellen und Beenden einer drahtlosen Verbindung verantwortlich. Außerdem ist sie für die Ausführung von Zellenneuauswahlen, d.h. zum Umschalten von einer Basisstation zu einer angrenzenden Basisstation, verantwortlich. Die Mobilitäts-/Funkbetriebsmittelverwaltung wird angewiesen, PDP-Kontexte und PDP-Subkontexte mit geeigneten Attributen für alle Arten von Datenverkehr sowie Filterlisten für den GGSN einzurichten.

Nachdem der Kollektor 72 seitens der Modemeinheit 2 initialisiert (92) wurde, beginnt er mit dem Sammeln von Informationen von verschiedenen Entitäten auf der Modemeinheit 2. Zum Beispiel könnten aus der physischen Schicht L1 Informationen in bezug auf die Signalleistung und die verfügbare Bandbreite der drahtlosen Verbindung erhalten (93) werden. Der Kollektor 72 könnte ferner Informationen von der RLC (94), der LLC (95), von dem SNDCP/PDCP (96), von dem QoS-Paketprozessor 75 (77) und von den internen Anwendungen 9 (97) sammeln. Die gesammelten Daten werden dem Zustandsprädiktor 50 sowie der Hauptsteuerung 43 zugeführt (53, 98). Zwischen dem externen Kollektor 68 der Anwendungseinheit und dem Kollektor 72 der Modemeinheit könnte eine direkte Kommunikation hergestellt werden und gesammelte Daten könnten über die schnelle QoSM-Verbindung 42 ausgetauscht werden.

Während des Betriebs empfängt die jeweilige Primärsteuerung Flussparameter von dem externen Kollektor 68 der Anwendungseinheit und von dem Kollektor 72 der Modemeinheit. Ferner werden der jeweiligen Primärsteuerung Prädiktionen aus dem Zustandsprädiktor 50 und aus dem externen Zustandsprädiktor 51 zugeführt. Die Primärsteuerung ist für das Treffen von Entscheidungen verantwortlich und für das Bestimmen der Steuereinstellungen für das gesamte System gemäß vordefinierten Strategien. Das Ziel besteht darin, die Steuereinstellungen reibungslos an die Anforderungen der verschiedenen Datenströme anzupassen. Falls die externe Hauptsteuerung 18 als die Primärsteuerung ausgewählt wird, werden durch den Kollektor 72 und den Zustandsprädiktor 50 bereitgestellte Flussparameter und Prädiktionen über die schnelle QoSM-Verbindung 42 und die Datenstrecke 48 zu der externen Hauptsteuerung 18 gesendet. Für die Modemeinheit 2 bestimmte Steuereinstellungen werden über die Datenstrecke 48 und die schnelle QoSM-Verbindung 42 zu den Entitäten auf der Modemeinheit 2 gesendet. Die Hauptsteuerung 43, die als Sekundärsteuerung wirkt, könnte für das verteilen der Steuereinstellungen auf der Modemeinheit 2 verantwortlich sein.

Falls die Hauptsteuerung 43 als die Primärsteuerung ausgewählt wird, werden Flussparameter und Prädiktionen, die durch den externen Kollektor 68 und den externen Zustandsprädiktor 51 bereitgestellt werden, über die schnelle QoSM-Verbindung 42 und die Datenstrecke 49 zu der Hauptsteuerung 43 gesendet. Steuereinstellungen für die Anwendungseinheit 1 werden über die Datenstrecke 49 und die schnelle QoSM-Verbindung 42 zu den Entitäten auf der Anwendungseinheit 1 gesendet. In diesem Fall wirkt die externe Hauptsteuerung 18 als Slave der Hauptsteuerung 43. Die externe Hauptsteuerung 18 könnte für das Verteilen der Steuereinstellungen auf der Anwendungseinheit 1 verantwortlich sein.

Es muss erwähnt werden, dass das QoS-Verwaltungssystem gemäß der vorliegenden Erfindung nicht jedes einzelne der in 1 und 2 gezeigten Module umfassen muss. Ein QoS-Verwaltungssystem gemäß einer Ausführungsform der vorliegenden Erfindung könnte genauso gut eine Teilmenge der oben erwähnten Module umfassen.

3 zeigt die Schichten des Transportprotokollstapels zusammen mit den Schichten eines Multiplex-Protokolls, das zum Senden von Daten über die physische Schnittstelle 3 verwendet wird. Zum Beispiel könnten Benutzerdaten 99, die Teil eines Echtzeit-Datenverkehrs sind, auf der Anwendungseinheit 1 erzeugt werden. Es wird ein Kopfteil 100 für Nutzinformationen zu den Benutzerdaten 99 hinzugefügt und die erhaltenen Nutzinformationen 101 werden zu einem entsprechenden Transportprotokollstapel 102 weitergeleitet. In 3 umfasst der Transportprotokollstapel 102 Protokollschichten für RTP, UDP und IP. Der Transportprotokollstapel 102 führt der Schnittstelleneinrichtung IP-Pakete zu. Zum Aufbauen einer Verbindung zwischen der Anwendungseinheit 1 und der Modemeinheit 2 könnten Protokolle der PPP-Protokollsuite auf beiden Einheiten verwendet (103, 104) werden. Als Alternative oder zusätzlich könnten durch einen Comm-Handler 105 auf der Anwendungseinheit 1 und durch einen Comm-Handler 106 auf der Modemeinheit 2 bereitgestellte Dienste verwendet werden.

Um die Übertragung mehrerer Datenströme über die physische Schnittstelle 3 zu erlauben, wird auf der Anwendungseinheit 1 und auf der Modemeinheit 2 ein Multiplex-Protokoll implementiert. Zum Beispiel könnte ein Multiplex-Protokoll gemäß einem der Standards 3GPP 27.0, 10 oder 7.0 10 verwendet werden. Auf der Anwendungseinheit 1 stellt das Multiplex-Protokoll 107 eine Menge virtueller Schnittstellen 108, 109 bereit. Folglich werden die virtuellen Schnittstellen 111, 112 durch das Multiplex-Protokoll 110 auf der Modemeinheit 2 bereitgestellt. Die virtuellen Schnittstellen können zum Aufbauen virtueller Kanäle zwischen der Anwendungseinheit 1 und der Modemeinheit 2 verwendet werden. Dann können IP-Pakete von der Anwendungseinheit 1 zu der Modemeinheit 2 und umgekehrt über die physische Schicht 113 übertragen werden. Zusätzlich zu Benutzerdaten könnten über die physische Schicht 113 zwischen dem Comm-Handlern 105 und 106 Benutzerdaten, Nachrichten und Befehle übertragen werden. Der AT-Befehls-Interpreter 114 dient zum Aufbauen und Modifizieren der virtuellen Schnittstellen.

4 zeigt eine alternative Struktur und die entsprechenden Komponenten, die für den Transfer der Messungen, d.h. Flusssteuerdaten, von der Modem- zu der Anwendungseinheit verwendet werden. Es wurden die üblichen Abkürzungen für Protokollstapel für das OSI-Referenzmodell verwendet. L1 bedeutet z.B. Schicht 1 oder physische Schicht. Die Modifikationen an dem üblichen Modell werden im folgenden erläutert. Insbesondere werden die folgenden Komponenten benutzt und gezeigt:

Der Sub-Kollektor befindet sich im Modem. Er sammelt alle Messungen und Parameter aus dem (drahtlosen) Stapel, die von der Hauptsteuerung (oder der Entscheidungsvorrichtung) angefordert werden, so lange sie durch den Stapel unterstützt werden. Er baut das IP-Paket auf, indem die Messungen und Parameter zu der Anwendungseinheit transportiert werden.

Der Absender befindet sich auch im Modem. Er ist für das Senden der IP-Pakete (die die Messungen enthalten) zu der Anwendungseinheit verantwortlich. Dieser Mechanismus wird nachfolgend ausführlicher beschrieben.

Die Medien-Erfassung ist für das Erkennen verantwortlich, welche Modemeinheit gerade mit der Anwendungseinheit verbunden ist, ob dieses Modem im Moment benutzbar ist und welche Parameter durch das Modem unterstützt werden.

Der Zustandsprädiktor ist dazu fähig, die zukünftige Entwicklung von netzwerkbezogenen Parametern vorherzusagen. Die Prädiktionen basieren auf Messungen aus den (drahtlosen) Stapeln. Der SP erhält die Messungen von dem AU-Kollektor.

Die Hauptsteuerung (Entscheidungsvorrichtung) ist für das Treffen von Entscheidungen verantwortlich. Auf der Basis der (aus dem AU-Kollektor bereitgestellten) Messungen aus den drahtlosen Stapeln, der (durch den SP bereitgestellten) Prädiktionen und des (durch die Medien-Erfassung bereitgestellten) Status des Modems entscheidet sie, welche Strategien, Anpassungen und Paketflussoptimierungen in diesem Moment durchgeführt werden sollten.

Der AU-Kollektor (Anwendungseinheit-Kollektor) ruft die IP-Pakete aus dem Paketfluss ab und extrahiert die Messungen. Außerdem baut er die IP-Pakete auf, die zum Anfordern von Messungen von den Modems benutzt werden (siehe unten).

Abhängig von den Merkmalen des IP-Stapels (insbesondere ob ein RAW-IP-Socket existiert oder nicht) sind drei verschiedene Implementierungsvarianten möglich (siehe 5).

Der QoS-Paketprozessor wird implementiert. In diesem Fall werden die Messungen in einem IP-Paket mit einer proprietären Transportprotokollerweiterung transportiert. Alle IP-Pakete müssen das QoS-PP durchlaufen und können deshalb leicht die Messungspakete an den AU-Kollektor geben und die AU-Kollektorpakete in den Paketfluss zu dem Modem einsetzen.

Ein Beispiel für die proprietäre Transportprotokollerweiterung wird nachfolgend gegeben. 6 zeigt ein IP-Paket, das die proprietäre Transportprotokollerweiterung verwendet, wobei übliche Abkürzungen für IP-Pakete verwendet werden.

Das Paket enthält einen Standardkopfteil des IP (Version 4). In dem Protokollfeld wird "254" verwendet (offen für experimentelle Verwendung).

Die ersten 4 Bit der Erweiterung sind für eine Protokollnummer mit der Bezeichnung "fgProt" reserviert. Der Mechanismus kann auch zum Transport anderer Informationselemente verwendet werden. Der Messungstransport hat die Protokollnummer 1 (bitcodiert).

Die zweiten 4 Bit sind für die Protokollversion reserviert. Jedes Protokoll kann Änderungen in der Zukunft benötigen. Im Moment besitzt das Messungsprotokoll Version 1 (bitcodiert).

Die Nutzinformationen können mehrere Messungsblöcke enthalten. Die ersten 8 Bit aller Blöcke zeigen die Art der Messung, die zweiten 8 Bit zeigen die Länge dieses Messungsblocks, gefolgt durch die Messungen selbst. Jede Messung besitzt ihre eigene Struktur.

Für GPRS-Zellenneuauswahl-Prädiktionen werden die Signalstärken der versorgenden Zelle und der Nachbarzellen transferiert. Die Messungen werden in einem bestimmten Zeitintervall genommen. Die Messungszeichenkette wird das folgende Format aufweisen (ohne die Zwischenräume, Zwischenräume sind nur als Hilfe für das Auge vorgesehen):

"S 71 72 N 71 72 57 86 73 87 78 89"

Dies bedeutet:

Versorgende Zelle: C1 ARFCN 71 Signalstärke –72 dbm

Versorgende Zelle: C2 ARFCN 71 Signalstärke –72 dbm

Nachbarzelle: 02 ARFCN 57 Signalstärke –86 dbm

Nachbarzelle: 02 ARFCN 73 Signalstärke –87 dbm

Nachbarzelle: 02 ARFCN 78 Signalstärke –89 dbm

C1 und C2 sind die in der GSM/GPRS-Spezifikation spezifizierten Signalstärken. ARFCN ist die ID-Nummer der Zelle.

Die Art dieser Messung wird in einer Liste spezifiziert.

Wieder mit Bezug auf die Figur, in der die proprietäre Erweiterung gezeigt ist, werden die folgenden Felder die folgenden Attribute aufweisen:

FgProt: 1 (bitcodiert)

Vers: 1 (bitcodiert)

Art der Messung: 6 (in Bit codiert, d.h. 256 verschiedene Messungen möglich)

Länge der Messung: 22 (Messungszeichenkette benötigt 22 Byte (siehe unten), codiert auf Bit, maximale Länge 256 Byte)

Messung: S7172N7172578673877889 (hex-codiert, jedes Vorzeichen benötigt ein Byte)

Das QoS-PP ist nicht implementiert. Der IP-Stapel stellt kein RAW-IP-Socket und keine Schnittstelle bereit. In diesem Fall dient das UDP-Protokol als Transportprotokoll für die Messungen. Ein spezieller (gewöhnlich unbenutzter) Port wird geöffnet und von dem AU-Kollektor benutzt. Der AU-Kollektor wirkt wie eine unabhängige Anwendung. Messungen und Anforderungen werden als ein proprietäres Format in einem UDP/IP-Paket verpackt.

Ein Beispiel für das proprietäre Format in einem UDP/IP-Paket wird nachfolgend angegeben. 7 zeigt ein UDP/IP-Paket für Messungstransfer.

7 zeigt einen Standardkopfteil des IP (Version 4) und einen Standard-UDP-Kopfteil. Die Prüfsumme wird nicht benutzt (Null). Quellen- und Zielport werden auf dem niedrigsten verfügbaren Port des folgenden (nicht zugewiesenen) Bereichs gesetzt: 43191–44320.

Die proprietäre Erweiterung für den Transport der Messungen entspricht der mit Variante A erläuterten.

Das QoS-PP wird nicht implementiert. Der IP-Stapel stellt einen direkten oder RAW-IP-Socket als Schnittstelle bereit. In diesem Fall wird dieselbe Einkapselung wie in Variante A verwendet. Das proprietäre Transportprotokoll verbindet direkt mit der IP-Schicht. ähnlich könnte TCP-Socket (nicht gezeigt) als Schnittstelle verwendet werden.

Die Messungsanforderungen werden von dem AU-Kollektor zu dem Absender in dem Modem gesendet. Messungen werden von dem Absender in dem Modem zu dem AU-Kollektor gesendet. In beiden Fällen wird derselbe Mechanismus verwendet. Die Messungsanforderung und die Messungen werden in ein IP-Paket mit einem proprietären Transportprotokoll (AU-Kollektorimplementierung, Varianten A und C, siehe oben) oder als proprietäre Nutzinformationen in einem UDP/IP-Paket mit einem speziellen Quellen- und Zielport (AU-Kollektorimplementierung B, siehe oben) eingekapselt. Es müssen zwei Fälle unterschieden werden:

• 1. Es wird eine aktive PPP-Verbindung zwischen der Anwendungseinheit und dem Modem hergestellt (das heißt, das Modem wird benutzt und eine IP-Verbindung mit dem Netzwerk existiert).

• 2. Das Modem befindet sich im Leerlaufmodus. Es ist keine PPP-Verbindung aktiv und keine IP-Verbindung zu dem Netzwerk läuft ab.

In diesem Fall wird das Modem tatsächlich zum Transport von IP-Paketen unter Verwendung des Modems über ein (drahtloses) Netzwerk verwendet. Dies heißt, dass dieser Modemverbindung eine IP-Adresse zugewiesen wurde. Der Absender in dem Modem erzeugt IP-Pakete mit dieser zugewiesenen IP-Adresse als Ziel- oder Empfänger-IP-Adresse; andernfalls würden sie gelöscht werden. Als Absender- oder Quellen-IP-Adresse wird die nächst höhere IP-Adresse verwendet, wenn der Absender in dem Modem ein IP-Paket zu der Anwendungseinheit sendet. Der AU-Kollektor verwendet die zugewiesene IP-Adresse der Modemverbindung als Quellenadresse beim Senden von IP-Paketen zu dem Modem und setzt die nächst höchste IP-Adresse als Zieladresse. Bei der ersten Messungsanforderung von dem AU-Kollektor wird das Nutzinformationsformat definiert (Implementierungsvariante A, B, C, siehe oben), damit das Modem weiß, welche Variante zu verwenden ist. ANMERKUNG: Wenn die IP-Adresse in der Anwendungseinheit mit .254 endet, ist die nächst höchste IP-Adresse NICHT .255 (Rundsendeadresse), sondern .1!

In einem Leerlaufmodus wird dem IP-Stapel in der Anwendungseinheit für diese Modemverbindung keine IP-Adresse zugewiesen. Es ist keine PPP-Verbindung aktiv. Wenn der AU-Kollektor Messungen von dem Modem im Leerlaufmodus erhalten möchte, baut er unter Verwendung einer sehr speziellen Zeichenkette als Einwählnummer (z.B. **3*4*6**# oder **f*g*m**#), die aus dem Absender in dem Modem als seine eigene Nummer erkannt wird, eine PPP-Verbindung zu dem Modem auf. Die IP-Adresse für diese Verbindung wird auf die folgende Weise zugewiesen: Der AU-Kollektor verwendet in dem PAP (Passwort-Authentifizierungsprotokoll, Teil der PPP-Initiierung) als Benutzername eine gewünschte IP-Adresse für sich selbst (es kann sein, dass andere IP-Adressen in der Anwendungseinheit bereits definiert sind und die IP-Adresse dieser Verbindung muss eindeutig sein). Das Modem weist diese IP-Adresse bei der Aushandlung des IPCP (IP-Controllprotokolls) (die Teil der PPP-Aushandlung ist) dem IP-Stapel der Anwendungseinheit für diese Modemverbindung zu. Wieder verwendet der Absender die nächst höchste IP für sich selbst.

ANMERKUNG: Wenn die IP-Adresse in der Anwendungseinheit mit .254 endet, ist die nächst höchste IP-Adresse NICHT .255 (Rundsendeadresse), sondern .1!

Sollte das Modem zum Verbinden mit einem drahtlosen Netzwerk verwendet werden, wird diese PPP-Verbindung ersetzt und das System schaltet auf den Betrieb für Fall 1 um.

Die Hauptsteuerung 18 (siehe 1) oder die Entscheidungsvorrichtung (siehe 4) verwenden jeweils eine mehrdimensionale Entscheidungsmatrix zur Optimierung des dynamischen Paketflusses oder des Protokolls. Optimierung und Anpassung des dynamischen Paketflusses oder Protokolls sind effizienter als ein statischer Ansatz. Dynamische Optimierung und Anpassung verwendet Eingangsparameter und Ereignisse, die die Qualität oder das Verhalten der zugrundeliegenden Strecke beschreiben, z.B.:

• – Verfügbare Bandbreite
• – Verwendetes Codierungsverfahren (das Codierungsverfahren kann während der Verbindung insbesondere mit dem Mobil-EDGE-Standard häufig geändert werden)
• – Verwendete Zeitschlitze, die sehr variieren
• – Bitfehlerrate
• – Zellenneuauswahl
• – Vorübergehender Verlust der Abdeckung
• – RLC-Pufferstatus (im allgemeinen Datenstreckenschichtstapel des OSI-Referenzmodells für Mobilkommunikation)
• – usw.

Bestimmte dieser Eingangsparameter können Prädiktionen sein (die aus einem Zustandsprädiktor kommen), und andere aktuelle "Echtzeit"-Messungen. Im folgenden ist der Unterschied zwischen vorhergesagten und gemessenen Eingangsparametern nicht wichtig.

Unter Verwendung dieser Eingangsparameter als Eingabe muss die Entscheidungsvorrichtung eine Entscheidung treffen, ob eine Aktion getriggert oder bestimmte (Protokoll-)Parameter geändert werden sollen und welche Protokollparameter auf welchen Wert geändert werden müssen. Protokollparameter bedeuten in diesem Kontext Parameter der Schichten 4 (Transportschicht) bis 7 (Anwendungsschicht) des OSI-Referenzmodells für Mobilkommunikation, d.h. die höheren Schichten. Beispiele für Protokollparameter oder Aktionen sind:

• – Größe erzeugter Pakete
• – Anzahl der in einer Gruppe gesendeten Pakete
• – Häufigkeit der Paketerzeugung
• – Start/Stop von Neuübertragungstimer(n)
• – Triggern der Übertragung eines Pakets
• – Triggern der Neuübertragung eines Paketes
• – Länge des Neuübertragungs-Timers
• – Vorwärtsfehlerkorrektur
• – usw.

Nicht alle Aktionen sind in jedem Zeitintervall verfügbar, weil sie von dem aktuellen Status des Protokolls oder Paketflusses in den höheren Schichten des OSI-Referenzmodells abhängen. Es wäre sinnlos, zum Beispiel ein neues Paket auszusenden, wenn sich der Protokollstapel der höheren Schichten in dem Zustand befindet, auf eine ankommende Bestätigung für zuvor gesendete Pakete zu warten.

Das Ziel der Entscheidungsvorrichtung ist das Finden des optimalen Protokollverhaltens höherer Schichten für die aktuelle (Netzwerk-)Situation. Es wäre in bezug auf Zeit und Prozessorkapazität zu aufwendig, wenn die Entscheidungsvorrichtung eine tiefe Analyse der aktuellen Situation durchführen müsste. Die Verwendung von 4 oder 5 Eingangsparametern, die die Netzwerksituation beschreiben, und die Kenntnis aller möglichen Zustände des Protokollstapels höherer Schichten führen leicht zu Tausenden theoretischen Situationen. Damit der Entscheidungsfortschritt schnell wird, ohne Genauigkeit der Entscheidungen zu verlieren, wird eine mehrdimensionale Entscheidungsmatrix verwendet.

Zuallererst wird eine Liste aller verfügbaren Aktionen für den Protokollstapel höherer Schichten erzeugt. Die Entscheidungsvorrichtung kann nicht frei jede beliebige Aktion aus dieser Liste auswählen. Welche Aktion ausgewählt werden muss, hängt sehr von dem Zustand des Protokollstapels höherer Schichten oder anders ausgedrückt von zuvor unternommenen Aktionen ab. Für jeden Protokollstapelzustand höherer Schichten wird deshalb eine Gruppe möglicher Aktionen erzeugt (die typischerweise bis zu 4 Aktionen umfassen kann).

Z.B. können beim Senden eines TCP/IP-Pakets die folgenden Zustände angetroffen werden:

• 1. Zustand: Warten auf Bestätigung, Neuübertragungstimer nicht abgelaufen,
• 2. Zustand: IP-Paket gesendet, Neuübertragungstimer abgelaufen,
• 3. Zustand: Bestätigung empfangen.
• 4. Zustand: Start der Übertragung aller IP-Pakete (z.B. für ein MMS)
• 5. Zustand: Ende der Übertragung aller IP-Pakete.

Dies ist eine Dimension der Matrix, wobei (hier) dieser ersten Dimension 5 Werte zugeordnet werden.

Die Gruppe von Aktionen für Zustand 3 ist z.B.:

• a) nichts ändern, ein Paket mit derselben Paketlänge und derselben Gruppengröße (z.B. zwei Pakete auf einmal) wie zuvor senden,
• b) halbieren der Länge von Paketen,
• c) verdoppeln der Länge von Paketen,
• d) vergrößern der Gruppengröße um ein Paket,
• e) verkleinern der Gruppengröße um ein Paket,
• f) nichts senden, warten.

Nun werden die Eingangsparameter für die Entscheidungsvorrichtung analysiert. Sie werden auf die Eingangsparameter reduziert, die für den Optimierungs- und Anpassungsprozeß für dieses Protokoll höherer Schichten am wichtigsten sind.

Für das obige TCP/IP-Beispiel sind diese:

• – Prädiktion einer Zellenneuauswahl,
• – RLC-Pufferstatus und
• – verfügbare Bandbreite.

Dies führt zu drei weiteren Dimensionen der Matrix, wodurch die Matrix vierdimensional wird.

Für die Parameter "RLC-Pufferstatus" und "verfügbare Bandbreite" wird eine Anzahl von Intervallen (typischerweise 3 oder 4) definiert. Das Ereignis, dass ein Eingangsparameter in ein definiertes Intervall fällt, wird als Eingabe für die mehrdimensionale Entscheidungsmatrix genommen, was zu ca. 4 Eingangswerten für die letzten drei Dimensionen der Matrix führt.

Alles in allem gibt es einige Hundert Eingangsparameterkombinationen für die Matrix. Für jede Eingangsparameterkombination wird eine einzige Aktion definiert.

Ein Punkt in der Matrix wird somit durch einen Protokollzustand höherer Schichten und die Intervalle für die wichtigsten Eingangsparameter beschrieben. Mit diesem Matrixpunkt ist eine Aktion assoziiert, die die Entscheidungsvorrichtung triggern muss.

Eine Aktionsänderung wird nur betrachtet, wenn eine Eingangswertänderung für die Matrix empfangen wird. Der neue Eingangsparametersatz markiert einen neuen Punkt in der Matrix. Mit diesem Punkt kann eine Aktion assoziiert sein, die durch die Entscheidungsvorrichtung getriggert werden sollte. Es kann jedoch "leere" Punkte in der Matrix geben, bei denen keine Aktion von der Entscheidungsvorrichtung gefordert wird, wenn dieser Punkt erreicht wird.

Die beschriebenen Ausführungsformen werden in jeder Hinsicht nicht als einschränkend, sondern als beispielhaft betrachtet. Der Schutzumfang der Erfindungen werden deshalb durch die angefügten Ansprüche und nicht durch die obige Beschreibung angegeben. Alle Änderungen, die in die Bedeutung und den Äquivalenzbereich der Ansprüche kommen, sind in ihren Schutzumfang aufzunehmen.