DE102005053914B9

DE102005053914B9 - Kommunikationssystem, Verfahren zum Betreiben eines Kommunikationssystems, Server-Einheit, Verfahren zum Betreiben einer Server-Einheit, Kommunikationsdienst-Client-Einheit und Verfahren zum Betreiben einer Kommunikationsdienst-Client-Einheit

Info

Publication number: DE102005053914B9
Application number: DE102005053914.9A
Authority: DE
Inventors: Norbert Schwagmann; Dr.rer.nat. Kowalewski Frank; Josef Laumen; Holger Schmidt
Original assignee: Intel Mobile Communications GmbH
Current assignee: Intel Deutschland GmbH
Priority date: 2005-11-11
Filing date: 2005-11-11
Publication date: 2014-10-23
Anticipated expiration: 2025-11-12
Also published as: DE102005053914A1; DE102005053914A9; DE102005053914B4

Abstract

Kommunikationssystem mit einer Kommunikationsdienst-Client-Einheit, weiteren Kommunikationsdienst-Client-Einheiten, einer Kommunikationsdienst-Server-Einheit und einer Server-Einheit, wobei – die Kommunikationsdienst-Client-Einheit eingerichtet ist, eine oder mehrere Nachrichten zu erzeugen, welche mindestens ein Kriterium enthalten, das von den weiteren Kommunikationsdienst-Client-Einheiten jeweils erfüllt wird oder nicht erfüllt wird und die Anforderung nach der Bereitstellung des Kommunikationsdiensts und eine Spezifikation enthalten, dass die weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, Teilnehmer des bereitgestellten Kommunikationsdiensts sein sollen; – die Server-Einheit eingerichtet ist, eine Liste der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, zu erzeugen und an die Kommunikationsdienst-Server-Einheit zu übermitteln; – die Kommunikationsdienst-Server-Einheit eingerichtet ist, den Kommunikationsdienst mit der Kommunikationsdienst-Client-Einheit und den weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, als Teilnehmern bereitzustellen; ...

Description

Die Erfindung betrifft ein Kommunikationssystem, ein Verfahren zum Betreiben eines Kommunikationssystems, eine Server-Einheit, ein Verfahren zum Betreiben einer Server-Einheit, eine Kommunikationsdienst-Client-Einheit und ein Verfahren zum Betreiben einer Kommunikationsdienst-Client-Einheit.
Der Kommunikationsdienst Push-to-talk-over-Cellular (PoC) ermöglicht es einem Benutzer eines Mobilfunk-Teilnehmergeräts, Sprachdaten an einen oder mehrere Empfänger gleichzeitig zu übermitteln.
Dazu ist typischerweise eine spezielle PoC-Taste an dem Mobilfunk-Teilnehmergerät vorgesehen, nach deren Betätigung der Benutzer mit dem Einsprechen von Sprachdaten beginnen kann.
Die Sprachdaten werden üblicherweise schon während des Einsprechens mittels eines Mobilfunk-Kommunikationsnetzwerks verteilt, das heißt an den oder die gewünschten Empfänger übermittelt. Dieser Vorgang wird als ”streaming” bezeichnet.
Die Übermittlung erfolgt im Halb-Duplex-Verfahren, das heißt, dass während des Einsprechens und während der Übertragung nur der Sender, das heißt der Benutzer, der die Sprachdaten einspricht und versendet, Sprachdaten an die Empfänger übermitteln kann, die Empfänger aber nicht gleichzeitig Sprachdaten an den Sender senden können. Insbesondere kann der Sender nicht von den Empfängern unterbrochen werden.
Anschaulich entspricht eine Kommunikation mittels PoC aus Sicht des Benutzers dem herkömmlichen CB-Funk, jedoch mit der Erweiterung, dass der Sender weltweit an Empfänger, die mittels der geeigneten Vermittlungstechnik mindestens eines Mobilfunk-Kommunikationsnetzwerks erreichbar sind, Sprachdaten übermitteln kann.
Möchte ein Benutzer von PoC öfter Sprachnachrichten an dieselben Empfänger senden, so wird es ihm bei PoC ermöglicht, persönliche, feste Benutzergruppen zu definieren. Beispielsweise kann ein Benutzer von PoC eine Gruppe mit der Bezeichnung ”Freunde” definieren, die entsprechende Mitglieder und deren jeweilige Adresse, beispielsweise eine SIP-URL (Session Initiation Protocol Uniform Resource Locator) in Form einer Telefonnummer oder in Form einer SIP-Adresse, aufweist.
Dieser Gruppe kann dann eine eigene Gruppenadresse in Form einer SIP-URL zugewiesen werden und beim Aufbau einer PoC-Session, das heißt einer Kommunikations-Session mittels PoC, unter Angabe der Gruppenadresse, die von einem Benutzer initiiert wird, werden alle Mitglieder der Gruppe von einem PoC-Serverrechner adressiert und zu der PoC-Session eingeladen.
Die Voraussetzung dafür, dass ein Mitglied der Gruppe eingeladen werden kann, ist, dass das Mitglied in dem Mobilfunk-Kommunikationsnetzwerk, mittels welchem der genutzte PoC bereitgestellt wird, angemeldet ist, das heißt ”online” ist.
Benutzer von PoC, die in einer PoC-Session aktiv, das heißt als Sender, oder passiv, das heißt als Empfänger, involviert sind, werden im Folgenden als PoC-Teilnehmer der PoC-Session bezeichnet.
Group Management (Gruppenverwaltung), wie in [1] und [2] beschrieben, ermöglicht die einfache Handhabung von Gruppen im Rahmen von PoC. Gruppen können aber auch im Rahmen anderer Kommunikationsdienste verwendet werden. Beispielsweise kann ein Benutzer unter Verwendung einer entsprechenden Gruppe eine MMS(Multimedia Message Service)-Nachricht an alle Mitglieder seiner Familie senden.
Im Falle von PoC kann ein Benutzer unter Verwendung einer entsprechenden Gruppe beispielsweise eine PoC-Session mit allen Mitgliedern seines Skat-Clubs starten. Dazu ist in einem PoC-Kommunikationsnetzwerk, d. h. in einem Kommunikationsnetzwerk, das PoC bereitstellt, ein Group Management-Server (GM-Server) vorgesehen, mittels welchen der Benutzer eine Gruppe anlegen und verwalten kann. Der Benutzer wird als Administrator der Gruppe bezeichnet.
Die Hauptkomponenten der Spezifikation einer Gruppe sind gemäß dem Stand der Technik:

– Group identifier (Gruppenidentifikation): Mittels diesem wird die Gruppe eindeutig identifiziert. Er hat beispielsweise die Form sip:[email protected]
– Group specific attributes (Gruppen-spezifische Attribute): Diese Attribute spezifizieren genauere Eigenschaften der Gruppe. Dies sind:
– Group information (Gruppeninformation): Information in Form eines einfachen Textes (beispielsweise ”Dies ist meine Familie”)
– Group visibility (Gruppensichtbarkeit): Dies spezifiziert, welche Benutzer die Gruppe (beispielsweise mittels einer Such-Funktion des GM-Servers) finden können. Beispielsweise spezifiziert die Group visibility, dass nur der Administrator der Gruppe die Gruppe finden kann.
– Group duration (Gruppendauer): Dies spezifiziert, wie lange und/oder wann die Gruppe gültig bzw. verwendbar ist. Beispielsweise kann Group duration spezifizieren, dass die Gruppe der ”Fußballstadion-Freunde” eines Benutzers nur samstags zwischen 14–18 Uhr verwendbar ist.
– Service specific info (Kommunikationsdienst-spezifische Informationen): Dies sind für den Kommunikationsdienst, in dessen Rahmen die Gruppe genutzt werden kann, spezifische Informationen. Beispielsweise existiert im Rahmen von PoC eine Unterscheidung zwischen ”pre-arranged groups” und ”chat groups”. So kann, falls die Gruppe im Rahmen von PoC genutzt werden soll, mittels der Service specific info angegeben werden, um was für einen Typ von Gruppe es sich handelt.
– Group members (Gruppen-Mitglieder): Dies ist eine Liste von Benutzern/Gruppen, die der Gruppe angehören, also von Gruppen-Mitgliedern. Jedes Gruppen-Mitglied, das insbesondere selbst eine Gruppe sein kann, wird mittels einer ID (Identifikation, beispielsweise einer SIP URI) eindeutig spezifiziert. Ferner können für jedes Gruppen-Mitglied folgende Attribute festgelegt werden:
– Member rights (Mitglied-Rechte): Diese spezifizieren die Rechte des Gruppen-Mitglieds
– Anonymity (Anonymität): Dies spezifiziert, ob das Gruppen-Mitglied bei einer Kommunikation im Rahmen der Gruppe anonym ist oder nicht
– Service specific info (Kommunikationsdienst-spezifische Informationen): Dies sind Kommunikationsdienst-spezifische Angaben. Im Falle von PoC kann beispielsweise die Funktion eines Moderators einer PoC-Session mittels der Service specific info einem Gruppen-Mitglied zugeordnet werden.

Ein Benutzer mit dem entsprechenden Recht, beispielsweise der Administrator einer Gruppe, kann im Rahmen des Group Management der Gruppe (das heißt der Gruppenverwaltung) gemäß dem Stand der Technik folgende Group Management-Operationen durchführen:

– Manipulation of groups (Gruppen-Manipulation)
– Get a list of groups (Gruppenliste anfordern)
– Create a new group (neue Gruppe erzeugen)
– Delete a group (Gruppe löschen)
– Modify group attributes (Gruppen-Attribute verändern)
– Manipulation of members in a group (Manipulation von Mitgliedern einer Gruppe)
– Get a list of members (Liste von Gruppen-Mitgliedern anfordern)
– Add a member to a group (Gruppen-Mitglied zu Gruppe hinzufügen)
– Delete a member from a group (Gruppen-Mitglied aus einer Gruppe löschen)
– Modify member attributes (Gruppen-Mitglied-Attribute verändern)

Im Rahmen von PoC wird eine Gruppe durch einen Benutzer beispielsweise folgendermaßen, wie mit Bezug auf 1 erläutert, genutzt.
1 zeigt ein Nachrichtenflussdiagramm 100 gemäß dem Stand der Technik.
In Schritt 106 erzeugt der Benutzer, er sei der Benutzer einer ersten PoC-Client-Einheit 101, eine Gruppe (PoC-Gruppe), zu der eine zweite PoC-Client-Einheit 102 (bzw. der entsprechende Benutzer) und eine dritte PoC-Client-Einheit 103 (bzw. der entsprechende Benutzer) gehören, in einem GM-Serverrechner 104 durch Senden einer ersten Nachricht 120. Der PoC-Gruppe wird beispielsweise die ID (Identifikation) sip:[email protected] zugeordnet und dem Benutzer mittels einer zweiten Nachricht 121, die von dem GM-Serverrechner 104 in Schritt 107 an die erste PoC-Client-Einheit 101 gesendet wird, mitgeteilt.
In Schritt 108 wählt der Benutzer die PoC-Gruppe aus. In Schritt 109 startet der Benutzer eine PoC-Session mit der PoC-Gruppe. Dazu sendet er mittels der ersten PoC-Client-Einheit 101 eine dritte Nachricht 122 an einen PoC-Serverrechner 105. Der PoC-Serverrechner 105 stellt in Schritt 110 fest, dass die in der dritten Nachricht 122 spezifizierte ID (sip:[email protected]) eine PoC-Gruppe spezifiziert. Daraufhin sendet der PoC-Serverrechner 105 in Schritt 111 eine vierte Nachricht 123 an den GM-Serverrechner 104, um diese PoC-Gruppe aufzulösen, d. h. um zu ermitteln, welche Gruppen-Mitglieder diese PoC-Gruppe aufweist. Der GM-Serverrechner 104 sendet daraufhin in Schritt 112 mittels einer fünften Nachricht 124 eine Liste aller Gruppen-Mitglieder der PoC-Gruppe an den PoC-Serverrechner. In diesem Beispiel weist die Gruppe die zweite PoC-Client-Einheit 102 und die dritte PoC-Client-Einheit 103 auf.
Durch Senden einer sechsten Nachricht 125 in Schritt 113 an die zweite PoC-Client-Einheit 102 und durch Senden einer siebten Nachricht 126 an die dritte PoC-Client-Einheit 103 lädt der PoC-Serverrechner 105 alle Mitglieder der PoC-Gruppe zu der aufzubauenden PoC-Session ein. Sobald das erste Gruppen-Mitglied die Einladung in Schritt 114 mittels einer achten Nachricht 127 akzeptiert, in diesem Beispiel die zweite PoC-Client-Einheit 102, wird in Schritt 116 an den Initiator der PoC-Session, d. h. an die erste PoC-Client-Einheit 101 eine neunte Nachricht 128 gesendet, mittels welcher signalisiert wird, dass die PoC-Session nun gestartet ist und Sprach-Pakete im Rahmen der PoC-Session gesendet werden können.
Gemäß dem Stand der Technik müssen bei der Definition einer Gruppe, beispielsweise beim Anlegen einer Gruppe in einem GM-Server, die Mitglieder der Gruppe aufgelistet werden. Insbesondere ist die Festlegung, welche Mitglieder die Gruppe aufweist, sehr statisch. Im Falle einer Gruppe, die alle Familienmitglieder eines Benutzers als Gruppen-Mitglieder aufweist, ist dies kein schwerwiegender Nachteil, da sich die Familienmitglieder eines Benutzers nicht sehr häufig ändern.
Im Falle beispielsweise eines Taxi-Operators, der eine Gruppe anlegen und nutzen möchte, die als Gruppen-Mitglieder alle ihm zugeordneten Taxis (bzw. die entsprechenden Fahrer), die momentan frei sind, aufweist, ist es sehr unbequem, die Group Management Operation ”Add a member to the group” bzw. ”Delete a member from the group” bei dem GM-Serverrechner durchzuführen, sobald ein Taxi frei wird bzw. belegt wird.
Neben dem erheblichen Aufwand für den Taxi-Operator und einer resultierenden geringen Benutzerfreundlichkeit führt dies zu einem sehr hohen Signalisierungsaufkommen für die Nachrichten an den GM-Server, beispielsweise auf der Luftschnittstelle eines Mobilfunk-Kommunikationssystems, das für die Kommunikation verwendet wird.
Ferner liegt die Information zur Entscheidung, wer momentan Mitglied einer Gruppe sein soll, dem Benutzer (beispielsweise in seinem Mobilfunk-Teilnehmergerät) möglicherweise nicht vor. Der Benutzer muss diese möglicherweise mit erheblichen Aufwand ermitteln.
Im Falle eines Taxi-Operators, muss der Taxi-Operator (oder beispielsweise sein Mobilfunk-Teilnehmergerät) jedes Mal notifiziert werden, wenn ein Taxi frei wird oder belegt wird, so dass der Taxi-Operator stets über den aktuellen Stand informiert ist. Das ständige Übermitteln von Notifikationsnachrichten führt ebenfalls zu einem sehr hohen Signalisierungsaufkommen, beispielsweise auf der Luftschnittstelle des für die Kommunikation genutzten Mobilfunk-Kommunikationssystems.
Group Management Operationen unter Verwendung von HTTP sind in [2] beschrieben. HTTP get-Befehle sind in [3] beschrieben.
In [4] ist SIP INVITE, in [5] ist SIP SUBSCRIBE und in [6] ist SIP MESSAGE beschrieben. Dies sind Methoden gemäß dem SIP (Session Initiation Protocol).
In [7] wird ein Verfahren zum Austausch von E-Mails beschrieben, bei dem sich ein Benutzer bei einem Server anmelden kann und Kriterien angeben kann, die spezifizieren, an welche anderen Benutzer von ihm versendete E-Mails gesendet werden sollen und ein Profil angeben kann, anhand dessen entschieden wird, ob von anderen Benutzern versendete E-Mails an ihn gesendet werden.
Druckschrift [8] offenbart ein netzwerkbasiertes System und eine Methode für die dynamische Verwaltung von Benutzergruppen. Es werden periodisch dynamische Benutzerdaten mit Gruppenmitgliedsschaft-Kriterien verglichen, um die Benutzergruppen zu bestimmen.
In [9] sind ein Verfahren und eine Vorrichtung zur Erstellung und Pflege von dynamischen Gruppenadressen zur Erleichterung der Push-to-Talk over Cellular (PoC) Gruppenkommunikationssitzung zwischen Mobilstationen in einem Kommunikationsnetzwerk offenbart. Beispielsweise wird eine dynamische Gruppe für eine Kommunikationssitzung mit Benutzern von Mobilstationen in Übereinstimmung mit einer Regel aufgefüllt.
Druckschrift [10] beschreibt ein System, bei dem ein Präsenzserver mobile Endgeräte innerhalb der Umgebung eines mobilen Endgeräts, das zu einer Kommunikation einlädt, identifiziert, und ein Push-to-Talk-Server dann eine Gruppensitzung zwischen dem einladenden Endgerät und ein oder mehreren Endgeräten in der Umgebung des einladenden Endgeräts aufbaut.
Der Erfindung liegt das Problem zu Grunde, eine Möglichkeit zur Nutzung von Gruppen im Rahmen von Kommunikationsdiensten zu schaffen, bei der die oben genannten Nachteile nicht auftreten.
Das Problem wird durch ein Kommunikationssystem, ein Verfahren zum Betreiben eines Kommunikationssystems, eine Server-Einheit, ein Verfahren zum Betreiben einer Server-Einheit, eine Kommunikationsdienst-Client-Einheit und ein Verfahren zum Betreiben einer Kommunikationsdienst-Client-Einheit mit den Merkmalen gemäß den unabhängigen Patentansprüchen gelöst.
Es wird ein Kommunikationssystem mit einer Kommunikationsdienst-Client-Einheit, weiteren Kommunikationsdienst-Client-Einheiten, einer Kommunikationsdienst-Server-Einheit und einer Server-Einheit bereitgestellt, wobei die Kommunikationsdienst-Client-Einheit eingerichtet ist, eine oder mehrere Nachrichten zu erzeugen, welche mindestens ein Kriterium enthalten, das von den weiteren Kommunikationsdienst-Client-Einheiten jeweils erfüllt wird oder nicht erfüllt wird und die Anforderung nach der Bereitstellung des Kommunikationsdiensts und eine Spezifikation enthalten, dass die weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, Teilnehmer des bereitgestellten Kommunikationsdiensts sein sollen. Die Server-Einheit ist eingerichtet, eine Liste der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, zu erzeugen und an die Kommunikationsdienst-Server-Einheit zu übermitteln; die Kommunikationsdienst-Server-Einheit ist eingerichtet, den Kommunikationsdienst mit der Kommunikationsdienst-Client-Einheit und den weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, als Teilnehmern bereitzustellen; die Server-Einheit ist eingerichtet, im Laufe der Bereitstellung des Kommunikationsdiensts die Liste der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, auf Gültigkeit zu überprüfen und gegebenenfalls zu aktualisieren und die aktualisierte Liste an die Kommunikationsdienst-Server-Einheit zu übermitteln; und die Kommunikationsdienst-Server-Einheit ist eingerichtet, gemäß der aktualisierten Liste die Teilnehmer des Kommunikationsdiensts zu verändern.
Ferner wird ein Kommunikationssystem mit einer Kommunikationsdienst-Client-Einheit, weiteren Kommunikationsdienst-Client-Einheiten, einer Kommunikationsdienst-Server-Einheit und einer Server-Einheit bereitgestellt, wobei die Kommunikationsdienst-Client-Einheit eingerichtet ist, eine oder mehrere Nachrichten zu erzeugen, welche mindestens ein Kriterium enthalten, das von den weiteren Kommunikationsdienst-Client-Einheiten jeweils erfüllt wird oder nicht erfüllt wird und die Anforderung nach der Bereitstellung des Kommunikationsdiensts und eine Spezifikation enthalten, dass die weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, Teilnehmer des bereitgestellten Kommunikationsdiensts sein sollen. Die Server-Einheit ist eingerichtet, eine das mindestens eine Kriterium repräsentierende Information an die Kommunikationsdienst-Server-Einheit zu übermitteln; die Kommunikationsdienst-Server-Einheit ist eingerichtet, den Kommunikationsdienst mit der Kommunikationsdienst-Client-Einheit und den weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, als Teilnehmern bereitzustellen; und die Kommunikationsdienst-Server-Einheit ist eingerichtet, im Laufe der Bereitstellung des Kommunikationsdiensts die weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, auf Gültigkeit zu überprüfen und gegebenenfalls die Teilnehmer des Kommunikationsdiensts zu verändern.
Ferner werden Verfahren zum Betreiben eines Kommunikationssystems, Server-Einheiten, Verfahren zum Betreiben einer Server-Einheit, eine Kommunikationsdienst-Client-Einheit und ein Verfahren zum Betreiben einer Kommunikationsdienst-Client-Einheit gemäß den oben beschriebenen Kommunikationssystemen bereitgestellt.
Anschaulich spezifiziert ein Benutzer mittels seiner Kommunikationsdienst-Client-Einheit ein Kriterium, gemäß welchem, wenn der Benutzer mittels seiner Kommunikationsdienst-Client-Einheit einen Kommunikationsdienst anfordert, dynamisch eine Gruppe von weiteren Benutzern (bzw. weiteren Kommunikationsdienst-Client-Einheiten) erzeugt wird, deren Gruppen-Mitglieder zusammen mit dem Benutzer an dem bereitgestellten Kommunikationsdienst, beispielsweise einer PoC(Push to talk over Cellular)-Kommunikation, teilnehmen sollen.
Der Benutzer legt also nicht statisch eine Gruppe bei der Server-Einheit, beispielsweise einem GM(Group Management)-Server, fest, die er nur manuell durch Senden von Nachrichten an die Server-Einheit modifizieren kann, beispielsweise durch Senden einer Nachricht, die spezifiziert, dass ein bestimmter Benutzer zu der Gruppe hinzugefügt werden soll, sondern spezifiziert ein Kriterium, gemäß welchem die Server-Einheit automatisch (bei Beginn der Bereitstellung des Kommunikationsdiensts) die Gruppe dynamisch ermittelt.
Beispielsweise kann ein Benutzer in einer Taxi-Zentrale als Kriterium angeben, dass alle Fahrer von Taxis, die im Moment frei sind, zu einer PoC-Gruppe gehören sollen. Die Server-Einheit erzeugt dynamisch die PoC-Gruppe, beispielsweise durch Nachfrage bei einem Presence-Server, der für jedes Taxi die Information enthält, ob das Taxi aktuell frei ist. Auf diese Weise kann der Benutzer immer genau zu den Taxis Sprach-Nachrichten senden, die gerade frei sind, ohne stets die PoC-Gruppe manuell auf den neuesten Stand bringen zu müssen und ohne sich selbst zu informieren, welche Taxis aktuell frei sind, wozu ein erheblicher Signalisierungsaufwand erforderlich wäre.
Auf diese Weise erhöht die Erfindung die Benutzerfreundlichkeit und senkt den Signalisierungsaufwand erheblich.
In dem obigen Beispiel werden die weiteren Kommunikationsdienst-Client-Einheiten beispielsweise durch Mobilfunk-Teilnehmergeräte der Taxifahrer realisiert.
Im Rahmen der Erfindung können die erste Kommunikationsdienst-Client-Einheit und die weiteren Kommunikationsdienst-Client-Einheiten beispielsweise durch Mobilfunk-Teilnehmergeräte gemäß dem UMTS(Universal Mobile Telecommunication System)-Standard oder dem GSM(Global System for Mobile Communication)-Standard realisiert werden.
Die Erfindung ist jedoch nicht nur anwendbar, wenn der Kommunikationsdienst mittels eines Mobilfunk-Kommunikationsnetzwerks bereitgestellt wird, sondern auch, wenn der Kommunikationsdienst mittels eines Festnetzes, beispielsweise eines PSTN(Public Switched Telephone Network) bereitgestellt wird. In beiden Fällen kann der Kommunikationsdienst mittels des Internets bereitgestellt werden, beispielsweise ist der Kommunikationsdienst ein Internet-basierter Konferenz-Kommunikationsdienst und die Kommunikationsdienst-Client-Einheiten dementsprechend Konferenz-Kommunikationsendgeräte. Die Erfindung eignet sich für eine Vielzahl von Gruppen-spezifischen Kommunikationsdiensten.
Anschaulich werden die weiteren Kommunikationsdienst-Client-Einheiten, die an dem Kommunikationsdienst teilnehmen sollen, nicht (nur) mittels einer Liste spezifiziert, sondern werden anschaulich ”umschrieben”, beispielsweise aus einer Liste von potentiellen Teilnehmern gemäß dem Kriterium herausgefiltert und so mit Hilfe eines vorgebbaren Kriteriums (oder mehrerer vorgebbarer Kriterien) dynamisch festgelegt.
Die Erfindung ermöglicht somit die Nutzung von dynamisch, mit Hilfe von Kriterien definierten Gruppen im Rahmen von Kommunikationsdiensten.
Bei den unten beschriebenen Ausführungsbeispielen besteht weiterhin der Vorteil, dass diese auf bestehenden, zum Teil bereits standardisierten, Kommunikationsnetzwerken basieren. Es müssen zur Realisierung der Ausführungsbeispiele keine gegenüber den bestehenden Kommunikationsnetzwerken neue Netzwerkelemente hinzugefügt werden, die bestehenden Netzwerkelemente werden in ihrer Funktionalität erweitert. Die Ausführungsbeispiele können somit einfach und kostengünstig realisiert werden.
In einer Ausführungsform kann der Benutzer einen Wert spezifizieren, der die maximale Anzahl der weiteren Kommunikationsdienst-Client-Einheiten, die an dem Kommunikationsdienst teilnehmen sollen, beschränkt. Anschaulich hat somit der Benutzer die Kontrolle über die Größe der dynamisch erzeugten Gruppe.
Falls sich die Gruppe der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, ändert, während der Kommunikationsdienst bereits bereitgestellt ist, also während der Kommunikationsdienst besteht, so kann dies berücksichtigt werden und beispielsweise weitere Kommunikationsdienst-Client-Einheiten, die zum Zeitpunkt des Beginns der Bereitstellung das Kriterium nicht erfüllt haben, nun aber erfüllen, zu Teilnehmern werden, beispielsweise zu dem bereitgestellten Kommunikationsdienst (etwa einer Konferenz) eingeladen werden. Umgekehrt kann eine der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium nicht mehr erfüllt, von dem bereitgestellten Kommunikationsdienst ausgeschlossen werden, beispielsweise aus einer Konferenz entfernt werden. Um dies zu realisieren, kann die Server-Einheit die Kriterien periodisch überprüfen.
Die Server-Einheit und die Kommunikationsdienst-Server-Einheit können mittels desselben Serverrechners realisiert werden.
In einer Ausführungsform sendet die Kommunikationsdienst-Server-Einheit als Antwort auf die zweite Nachricht eine Nachricht an die Kommunikationsdienst-Client-Einheit, mittels welcher der Kommunikationsdienst-Client-Einheit mitgeteilt wird, welche der weiteren Kommunikationsdienst-Client-Einheiten aktuell das Kriterium erfüllen. Die Kommunikationsdienst-Client-Einheit kann daraufhin bestätigen, ob der Kommunikationsdienst tatsächlich mit den weiteren Kommunikationsdienst-Client-Einheiten, die aktuell das Kriterium erfüllen, als Teilnehmern bereitgestellt werden soll oder nicht.
Anschaulich erweitert die Erfindung die gemäß dem Stand der Technik vorgesehenen Group-Management-Operationen. Ferner werden die Anfragen, die die Kommunikationsdienst-Client-Einheit an die Kommunikationsdienst-Server-Einheit sendet, anschaulich erweitert, beispielsweise durch die Spezifikation, dass der Kommunikationsdienst mit den Gruppen-Mitgliedern einer dynamisch definierten Gruppe als Teilnehmern bereitgestellt werden soll.
Die Server-Einheit kann als Gruppenverwaltungs-Server-Einheit ausgestaltet sein und beispielsweise durch einen GM(Group Management)-Serverrechner, der entsprechend gegenüber dem Stand der Technik erweitert ist, realisiert werden, oder durch einen beliebigen anderen Serverrechner realisiert werden.
Bevorzugte Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen. Die weiteren Ausgestaltungen der Erfindung, die im Zusammenhang mit dem Kommunikationssystem beschrieben sind, gelten sinngemäß auch für die Verfahren zum Betreiben eines Kommunikationssystems, die Server-Einheiten, die Verfahren zum Betreiben einer Server-Einheit, die Kommunikationsdienst-Client-Einheit und das Verfahren zum Betreiben einer Kommunikationsdienst-Client-Einheit.
Die das mindestens eine Kriterium repräsentierende Information kann das mindestens eine Kriterium selbst sein.
Ferner kann die Kommunikationsdienst-Client-Einheit eingerichtet sein, eine oder mehrere Nachrichten mit dem mindestens einen Kriterium an die Server-Einheit zu senden.
Gemäß einer Ausgestaltung der Erfindung ist die Server-Einheit eingerichtet zum Speichern des mindestens einen Kriteriums.
Weiterhin kann die Server-Einheit als Group-Management-Server-Einheit eingerichtet sein.
Beispielsweise ist die Anforderung in einer ersten Nachricht der einen oder mehreren Nachrichten enthalten und wird von der Kommunikationsdienst-Client-Einheit an die Kommunikationsdienst-Server-Einheit übermittelt.
In einer Ausführungsform ist das Kriterium in einer zweiten Nachricht der einen oder mehreren Nachrichten enthalten und wird von der Kommunikationsdienst-Client-Einheit an die Server-Einheit übermittelt.
In einer Ausführungsform ist das Kriterium in der ersten Nachricht der einen oder mehreren Nachrichten enthalten (und wird beispielsweise von der Kommunikationsdienst-Server-Einheit an die Server-Einheit weitergeleitet).
In einer Ausführungsform ist die Server-Einheit eingerichtet zum Erzeugen der Liste der weiteren Kommunikationsdienst-Client-Einheiten an mindestens eine Informations-Server-Einheit eine dritte Nachricht zu übermitteln, welche die Anforderung nach Informationen enthält, die zum Überprüfen, ob die weiteren Kommunikationsdienst-Client-Einheiten das Kriterium erfüllen, erforderlich sind.
In einer anderen Ausführungsform ist die Kommunikationsdienst-Server-Einheit eingerichtet zum Erzeugen der Liste der weiteren Kommunikationsdienst-Client-Einheiten an mindestens eine Informations-Server-Einheit eine dritte Nachricht zu übermitteln, welche die Anforderung nach Informationen enthält, die zum Überprüfen, ob die weiteren Kommunikationsdienst-Client-Einheiten das Kriterium erfüllen, erforderlich sind.
Anschaulich fordert die Server-Einheit bzw. die Kommunikationsdienst-Server-Einheit bei einer Informations-Server-Einheit, die über für das Kriterium relevante Informationen verfügt, Informationen an, die er zur Erzeugung der Liste gemäß dem Kriterium überprüft.
Beispielsweise ist die Informations-Server-Einheit eine Presence-Server-Einheit oder eine Location-Server-Einheit. Dementsprechend sind die für das Kriterium relevanten beispielsweise Orts-Informationen oder Präsenz-Informationen.
Überprüft die Server-Einheit oder die Kommunikationsdienst-Server-Einheit die Kriterien periodisch (um stets überprüfen zu können, welche der weiteren Kommunikationsdienst-Client-Einheiten das Kriterium aktuell erfüllen), so kann sie sich beispielsweise bei einem Location-Server oder einem Presence-Server subskribieren, so dass sie über Statusänderungen der weiteren Kommunikationsdienst-Client-Einheiten stets informiert wird.
In einer Ausführungsform enthält die eine oder mehreren Nachrichten ferner eine weitere Liste eines Teils der weiteren Kommunikationsdienst-Client-Einheiten, und eine der weiteren Kommunikationsdienst-Client-Einheiten soll nur dann Teilnehmer des bereitgestellten Kommunikationsdiensts sein, falls sie auf der weiteren Liste aufgeführt wird und das Kriterium erfüllt.
Der Benutzer der Kommunikationsdienst-Client-Einheit kann also eine Liste von potentiellen Gruppen-Mitgliedern definieren, aus denen gemäß dem Kriterium die Teilnehmer des Kommunikationsdienstes herausgefiltert werden.
Beispielsweise ist der Kommunikationsdienst ein Kommunikationsdienst, der auf SIP (Session Initiation Protocol) basiert.
Mit Hilfe von Kommunikations-Ids (Kommunikationsidentifikationen) können innerhalb einer SIP-Session verschiedene Gruppen-Kommunikationen (oder Sub-Gruppen-Kommunikationen) realisiert werden, wobei dynamische Gruppen (oder Sub-Gruppen) verwendet werden. Insbesondere kann beispielsweise ”Whispering” und ”Sidebars” realisiert werden. Beispielsweise kann ein Benutzer, der an einer Gruppen-Kommunikation teilnimmt, Sprachdaten an eine dynamisch definierte Sub-Gruppe versenden, die nur von den Mitgliedern der Sub-Gruppe empfangen werden können.
In einer Ausführungsform wird in der einen oder mehreren Nachrichten das mindestens eine Kriterium gemäß XML (eXtended Markup Language) spezifiziert.
Der Kommunikationsdienst ist beispielsweise ein PoC-Kommunikationsdienst, ein Kommunikationsdienst zum Versenden von Instant Messages, ein MMS-Kommunikationsdienst oder ein Konferenz-Kommunikationsdienst.
Wie oben erwähnt überprüft die Server-Einheit im Laufe der Bereitstellung des Kommunikationsdiensts die Liste der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, (beispielsweise periodisch) auf Gültigkeit, aktualisiert diese gegebenenfalls und übermittelt die aktualisierte Liste an die Kommunikationsdienst-Server-Einheit.
Die Kommunikationsdienst-Server-Einheit ist eingerichtet, gemäß der aktualisierten Liste die Teilnehmer des Kommunikationsdiensts zu verändern.
Die Kommunikationsdienst-Server-Einheit überprüft im Laufe der Bereitstellung des Kommunikationsdiensts, ob die weiteren Kommunikationsdienst-Client-Einheiten, das Kriterium noch erfüllen, (beispielsweise periodisch) und verändert gegebenenfalls die Teilnehmer des Kommunikationsdiensts.
In einer Ausführungsform wird der Kommunikationsdienst im Rahmen eines weiteren Kommunikationsdiensts bereitgestellt, der von der Kommunikationsdienst-Server-Einheit bereitgestellt wird.
Anschaulich werden dynamisch erzeugte Untergruppen einer Gruppe im Rahmen eines Kommunikationsdiensts, der für die Gruppe bereitgestellt wird, genutzt. Beispielsweise wird eine PoC-Kommunikation im Rahmen einer PoC-Session aufgebaut, wobei die Teilnehmer der PoC-Kommunikation (bzw. die von ihnen verwendeten Client-Einheiten) das Kriterium erfüllen.
Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Weiteren näher erläutert.
1 zeigt ein Nachrichtenflussdiagramm gemäß dem Stand der Technik.
2 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
3 zeigt ein Kommunikationssystem gemäß einem Ausführungsbeispiel der Erfindung.
4 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
5 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
6 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
7 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
8 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
9 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
10 zeigt ein Nachrichtenflussdiagramm gemäß einem weiteren Ausführungsbeispiel der Erfindung.
2 zeigt ein Nachrichtenflussdiagramm 200 gemäß einem Ausführungsbeispiel der Erfindung.
Der Nachrichtenfluss 200 findet zwischen einer GM(Group Management)-Client-Einheit 201, einer ServiceX-Client-Einheit 202, einer ServiceX-Server-Einheit 203 und einer GM(Group Management)-Server-Einheit 204 statt. ServiceX steht hier für einen beliebigen Kommunikationsdienst, in dessen Rahmen Gruppen verwendet werden können.
Der ServiceX ist dementsprechend beispielsweise ein PoC(Push-to-Talk over Cellular)-Kommunikationsdienst, ein Kommunikationsdienst zum Versenden von Instant Messages, ein MMS(Multimedia Message Service)-Kommunikationsdienst oder ein Konferenz-Kommunikationsdienst. Die ServiceX-Client-Einheit 202 und die ServiceX-Server-Einheit 203 sind gemäß dem Kommunikationsdienst angeordnet und ausgestaltet. Eine Architektur zur Nutzung von PoC wird weiter unten erläutert.
In Schritt 205 legt die GM-Client-Einheit 201 bei der GM-Server-Einheit 204 eine (PoC-)Gruppe an. Dazu sendet die GM-Client-Einheit 201 eine group-creation-request-Nachricht 216 an die GM-Server-Einheit 204. Die group-creation-request-Nachricht 216 enthält:

– eine Liste von potentiellen Gruppen-Mitgliedern der Gruppe und/oder eine erste Liste von Kriterien;
– (optional) eine Spezifikation einer maximalen Anzahl von Gruppen-Mitgliedern der Gruppe;
– (optional) eine Spezifikation, dass das Automatisches-Update-Flag (automatic update flag) gesetzt ist;
– (optional) sonstige Werte von für den ServiceX spezifischen Parametern.

Die GM-Server-Einheit 204 legt daraufhin eine entsprechende Gruppe an und sendet in Schritt 206 eine Antwortnachricht 217 an die GM-Client-Einheit 201, die eine eindeutige Identifikation (ID) der angelegten Gruppe enthält.
In Schritt 207 sendet die ServiceX-Client-Einheit 202 eine Anforderungsnachricht 218 mit der Anforderung nach der Bereitstellung des ServiceX an die ServiceX-Server-Einheit 203. Die Anforderungsnachricht 218 enthält:

– die Identifikation der Gruppe und/oder eine zweite Liste von Kriterien;
– (optional) eine weitere Liste von potentiellen Gruppen-Mitgliedern; falls in der group-creation-request-Nachricht 216 bereits eine Liste von potentiellen Gruppen-Mitgliedern angegeben wurde, so kann die weitere Liste von potentiellen Gruppen-Mitgliedern eine Erweiterung der Liste von potentiellen Gruppen-Mitgliedern sein;
– (optional) die Spezifikation einer maximalen Anzahl von Gruppen-Mitgliedern der Gruppe;
– (optional) die Spezifikation, dass das Automatisches-Update-Flag gesetzt ist;
– (optional) eine Anforderungsidentifikation (request ID) für den angeforderten Kommunikationsdienst; in dem Fall, dass ServiceX ein PoC-Kommunikationsdienst ist, ist dies eine PoC-Kommunikations-ID, welche als id_proposal bezeichnet wird;
– (optional) Werte von sonstigen für den ServiceX spezifischen Parametern.

In Schritt 208 stellt die ServiceX-Server-Einheit 203 fest, dass sie die Gruppe nicht auflösen kann, d. h. dass sie die aktuellen Gruppen-Mitglieder nicht bestimmen kann. Deshalb sendet sie eine Anfrage-Nachricht 219 an die GM-Server-Einheit 204 mit der Anfrage, dass die GM-Server-Einheit 204 die Gruppe auflöst. Die Anfrage-Nachricht 219 enthält:

– die Identifikation der Gruppe;
– (optional) die zweite Liste von Kriterien;
– (optional) die Liste von potentiellen Gruppen-Mitgliedern (darunter ist im Folgenden stets die gegebenenfalls um die weitere Liste von potentiellen Gruppen-Mitgliedern erweiterte Liste von potentiellen Gruppen-Mitgliedern zu verstehen bzw. gegebenenfalls die weitere Liste von potentiellen Gruppen-Mitgliedern selbst, falls in der group-creation-request-Nachricht 216 keine Liste von potentiellen Gruppen-Mitgliedern angegeben wurde);
– (optional) die Spezifikation einer maximalen Anzahl von Gruppen-Mitgliedern in der Gruppe;
– (optional) Werte von sonstigen, für den ServiceX spezifischen Parametern.

Ist das Automatisches-Update-Flag gesetzt, so fordert die ServiceX-Server-Einheit 203 mittels der Anfrage-Nachricht 219 bei der GM-Server-Einheit 204 eine längerfristige Group-Composite-Change-Notification (Gruppenzusammensetzungsänderungs-Benachrichtigung) an. In diesem Fall wird die ServiceX-Server-Einheit 203 von der GM-Server-Einheit 204 jedes Mal darüber informiert, wenn sich die Zusammensetzung der Gruppe ändert, beispielsweise wenn ein potentielles Gruppen-Mitglied die mittels der ersten Liste von Kriterien oder mit der zweiten Liste von Kriterien angegebenen Kriterien nicht mehr oder zwischenzeitlich nicht erfüllt. Insbesondere überprüft im Falle eines gesetzten Automatisches-Update-Flags die GM-Server-Einheit 204 periodisch, welche potentiellen Gruppen-Mitglieder die Kriterien aktuell erfüllen.
Diese Subskription, d. h. die Anforderung der Group-Composite-Change-Notification kann alternativ von der ServiceX-Server-Einheit 203 auch zu einem späteren Zeitpunkt durchgeführt werden.
In Schritt 210 ermittelt die GM-Server-Einheit 204 alle Benutzer, die (falls vorhanden) in der Liste der potentiellen Gruppen-Mitgliedern angegeben sind, die die (falls vorhanden) Kriterien der ersten Liste von Kriterien erfüllen und die die (falls vorhanden) Kriterien der zweiten Liste von Kriterien erfüllen. Diese Benutzer bilden die momentane Liste von Gruppen-Mitgliedern. Die Art, wie die GM-Server-Einheit 204 die momentanen Gruppen-Mitglieder (d. h. die Mitglieder der momentanen Liste von Gruppen-Mitgliedern) ermittelt, hängt von dem mittels der ersten Liste von Kriterien bzw. der zweiten Liste von Kriterien spezifizierten Kriterien ab. Dies wird weiter unten erläutert.
In Schritt 211 sendet die GM-Server-Einheit 204 eine weitere Antwort-Nachricht 220, welche die momentane Liste von Gruppen-Mitgliedern enthält, an die ServiceX-Server-Einheit 203.
Die Schritte 212 und 213 werden optional durchgeführt. In Schritt 212 übermittelt die ServiceX-Server-Einheit 203 eine Informationsnachricht 221 an die ServiceX-Client-Einheit 202, mittels welcher sie die ServiceX-Client-Einheit 202 über die momentane Liste von Gruppen-Mitgliedern informiert. Dazu kann die Informationsnachricht 221 beispielsweise die Anzahl der momentanen Gruppen-Mitglieder enthalten oder auch die komplette momentane Liste von Gruppen-Mitgliedern.
In Schritt 213 sendet die ServiceX-Client-Einheit 202 eine Bestätigungsnachricht 222 an die ServiceX-Server-Einheit 203, womit sie die in Schritt 207 durchgeführte Anforderung des ServiceX bestätigt. Alternativ kann die ServiceX-Client-Einheit 202 in Schritt 213 die Anforderung nach dem ServiceX zurückziehen und der Ablauf wird dementsprechend beendet.
In Schritt 214 wird die in Schritt 207 durchgeführte Anforderung nach dem ServiceX, falls diese nicht in Schritt 213 zurückgezogen wurde, unter Verwendung der momentanen Liste von Gruppen-Mitgliedern von der ServiceX-Server-Einheit 203 bedient. Je nachdem, welche. Art von Kommunikationsdienst der ServiceX ist, werden dazu von der ServiceX-Server-Einheit 203 entsprechende Aktionen durchgeführt, beispielsweise eine Einladung der Gruppen-Mitglieder zu einer Gruppen-Kommunikation.
In Schritt 215 sendet die ServiceX-Server-Einheit 203 zur Bestätigung der in Schritt 207 durchgeführten Anforderung des ServiceX eine Anforderungs-Bestätigungsnachricht 223 an die ServiceX-Client-Einheit 202. Die Anforderungs-Bestätigungsnachricht 223 enthält:

– (optional) die momentane Liste von Gruppen-Mitgliedern;
– eine Antwort-Identifikation (response ID); in dem Fall, dass der ServiceX ein PoC-Kommunikationsdienst ist, ist dies eine PoC-Kommunikations-ID, welche als PK_id bezeichnet wird;
– (optional) Werte von sonstigen, für den ServiceX spezifischen Parametern.

Hat die ServiceX-Server-Einheit 203 bei der GM-Server-Einheit 204 eine Group-Composite-Change-Notification angefordert, so wird die ServiceX-Server-Einheit 203 bei einer Änderung der momentanen Liste von Gruppen-Mitgliedern über die geänderte momentane Liste von Gruppen-Mitgliedern notifiziert. So ist der ServiceX-Server-Einheit 203 stets die aktuelle Zusammensetzung der momentanen Liste von Gruppen-Mitgliedern bekannt. Je nachdem, um welche Art von Kommunikations-Dienst es sich bei dem ServiceX handelt, sind mit der Änderung der momentanen Liste von Gruppen-Mitgliedern (und der entsprechenden Notifikation der ServiceX-Server-Einheit 203) bestimmte Aktionen verbunden, beispielsweise eine Einladung eines zu der momentanen Liste von Gruppen-Mitgliedern neu hinzugekommenen Gruppen-Mitglieds zu einer Gruppen-Kommunikation.
In einer anderen Ausführungsform werden die Schritte 205 bis 211 wie oben beschrieben durchgeführt. Schritt 212 wird jedoch notwendig durchgeführt und die Informationsnachricht 221 enthält die momentane Liste der Gruppen-Mitglieder sowie eine temporäre Gruppenidentifikation. In Schritt 213 sendet die ServiceX-Client-Einheit 302 nicht eine Bestätigungsnachricht 222 an die ServiceX-Server-Einheit 203, sondern eine erneute Anforderung des ServiceX an die ServiceX-Server-Einheit 303 unter Angabe der temporären Gruppenidentifikation. Der weitere Ablauf ist analog zu oben ab Schritt 214.
In einer Ausführungsform ist die GM-Server-Einheit 204 nicht als separate Funktions-Einheit ausgestaltet, sondern die oben beschriebene Funktionalität der GM-Server-Einheit 204 wird von der ServiceX-Server-Einheit 203 übernommen. Insbesondere entfällt die Interaktion zwischen der GM-Server-Einheit 204 und der ServiceX-Server-Einheit 203 in den Schritten 219 und 220 sowie die Notifizierungen an die ServiceX-Server-Einheit 203 im Rahmen einer Group-Composite-Change-Notification.
3 zeigt ein Kommunikationssystem 300 gemäß einem Ausführungsbeispiel der Erfindung.
Eine erste PoC-Client-Einheit 301, eine zweite PoC-Client-Einheit 302 und eine dritte PoC-Client-Einheit 303 sind mittels jeweils einer Schnittstelle 304 mit jeweils einem PoC-Teilnehmerserverrechner (PoC-Serverrechner Participant Function) 305 gekoppelt. Die PoC-Teilnehmerserverrechner 305 sind mit einem PoC-Steuerserverrechner (PoC-Serverrechner controlling function) 306 gekoppelt.
Der PoC-Steuerserverrechner 306 ist mit einem Location-Serverrechner 307, einem GM(Group Management)-Serverrechner 308 und einem Presence-Serverrechner 309 gekoppelt. Der GM-Serverrechner 308, ist ebenfalls mit dem Location-Serverrechner 307 und dem Presence-Serverrechner 309 gekoppelt.
Der Location-Serverrechner 307 stellt Orts-Informationen bereit. Beispielsweise kann der GM-Serverrechner 308 bei dem Location-Serverrechner 307 den Ort der zweiten PoC-Client-Einheit 302 erfragen.
Der Presence-Serverrechner Rechner 309 stellt Präsenzinformationen bereit. Beispielsweise kann der GM-Serverrechner 308 bei dem Presence-Serverrechner 309 erfragen, ob die zweite PoC-Client-Einheit 302 derzeit verfügbar ist und nicht beispielsweise abgeschaltet ist oder aus einem anderen Grund keine Kommunikationsverbindung zu ihr aufgebaut werden kann.
Die Schnittstellen 304 werden beispielsweise mittels des RAN (Radio Access Network), des Kernnetzwerks (Core Network, CN) und des IMS (Internet Protocol based Multimedia Subsystem) eines UMTS(Universal Mobile Telecommunication System)-Kommunikationssystems oder eines GSM(Global System for Mobile Communication)-Kommunikationssystems bereitgestellt.
Die Schnittstellen 304 können aber auch beispielsweise mittels eines PSTN(Public Switched Telephone Network)-Kommunikationsnetzwerks bereitgestellt werden.
Die PoC-Client-Einheiten 301, 302, 303 sind jeweils in einem Mobilfunk-Kommunikationsendgerät, das gemäß der jeweiligen Schnittstelle 304 beispielsweise eingerichtet ist zur Kommunikation gemäß dem UMTS-Standard, dem GSM-Standard, dem GPRS(General Packet Radio Service)-Standard oder einem anderen Mobilfunk-Kommunikationsstandard, integriert.
4 zeigt ein Nachrichtenflussdiagramm 400 gemäß einem Ausführungsbeispiel der Erfindung.
Der dargestellte Nachrichtenfluss findet zwischen einer PoC-Client-Einheit 401, einem PoC-Steuerserverrechner 402, einem GM-Serverrechner 403, einem Location-Serverrechner 404, einem Presence-Serverrechner 405 sowie weiteren PoC-Client-Einheiten 406 statt, die wie mit Bezug auf 3 erläutert angeordnet und ausgestaltet sind, wobei die zweite PoC-Client-Einheit 302 und die dritte PoC-Client-Einheit 303 den weiteren PoC-Client-Einheiten 406 entsprechen.
Bei dem im Folgenden erläuterten Ausführungsbeispiel wird angenommen, dass der Benutzer der PoC-Client-Einheit 401 mit

– allen seinen Freunden,
– die sich momentan in der gleichen Stadt aufhalten wie er (in diesem Beispiel ist dies ein erstes Kriterium; criteria_1)
– und die momentan nicht arbeiten (in diesem Beispiel ist dies ein zweites Kriterium; criteria_2)

Dazu legt der Benutzer der PoC-Client-Einheit 401 durch Senden einer group_generation_request-Nachricht 423 in Schritt 407 eine PoC-Gruppe in dem GM-Serverrechner 403 an. Zur Definition der PoC-Gruppe übermittelt der Benutzer eine in der group_generation_request-Nachricht 423 enthaltene Auflistung (member_list) von zwanzig unterschiedlichen Benutzern (die Freunde des Benutzers, dies sind die potentiellen Gruppen-Mitglieder) und ein in der group_generation_request-Nachricht 423 spezifiziertes erstes Kriterium (criteria_1), dass sich die Freunde zum Zeitpunkt der Benutzung der PoC-Gruppe in der Stadt Hamburg aufhalten sollen.
Das Senden der group_generation_request-Nachricht kann beispielsweise mittels eines HTTP get-Befehls realisiert werden, der gemäß Tabelle 1 ausgestaltet ist.
Tabelle 1
HTTP get-Befehle sind in [3] beschrieben (Group Management Operationen unter Verwendung von HTTP sind in [2] beschrieben).
In Tabelle 1 und in den weiteren Tabellen sind die Einträge, die gemäß den Ausführungsbeispielen gegenüber den herkömmlichen Nachrichten zusätzlich vorgesehen sind, fett dargestellt.
In Schritt 408 sendet der GM-Serverrechner 403 als Antwort eine group_generation_response-Nachricht 424, welche eine eindeutige Gruppenidentifikation der PoC-Gruppe enthält, in diesem Fall die Identifikation sip:[email protected], an die PoC-Client-Einheit 401.
In Schritt 409 wählt der Benutzer der PoC-Client-Einheit 401 die PoC-Gruppe aus und legt das zweite Kriterium (criteria_2) fest (das erste Kriterium und das zweite Kriterium können jeweils auch aus mehreren Kriterien bestehen), um mit den potentiellen Gruppen-Mitgliedern der PoC-Gruppe, welche das erste Kriterium und das zweite Kriterium erfüllen, mit Hilfe der PoC-Client-Einheit 401 eine PoC-Session zu starten. Durch das erste Kriterium und das zweite Kriterium wird die PoC-Gruppe dynamisch beschrieben, da es sich im Laufe der Zeit ändern kann, ob die potentiellen Gruppen-Mitglieder, d. h. die Benutzer, die in der group_generation_request-Nachricht 423 enthaltenen Liste von Benutzern aufgeführt sind, das erste Kriterium und das zweite Kriterium erfüllen.
Der Benutzer der PoC-Client-Einheit 401 möchte, dass während der zu startenden PoC-Session die aktuelle Zusammensetzung der PoC-Gruppe berücksichtigt wird. Die PoC-Gruppe setzt sich zu einem Zeitpunkt aktuell aus den potentiellen Gruppen-Mitgliedern zusammen, die das erste Kriterium und das zweite Kriterium erfüllen. Insbesondere sollen im Laufe der PoC-Session potentielle Gruppen-Mitglieder, die bisher nicht an der PoC-Session teilnehmen, zu der PoC-Session eingeladen werden, wenn sie das erste Kriterium und das zweite Kriterium (im Gegensatz zu vorher) erfüllen. Um dies zu erreichen, setzt der Benutzer der PoC-Client-Einheit 401 das Automatisches-Update-Flag (automatic_update_flag).
In Schritt 410 sendet der Benutzer zum Starten der PoC-Session eine INVITE-Nachricht 425 an den PoC-Steuerserverrechner 402. Die INVITE-Nachricht 425 ist gemäß einem SIP INVITE ausgestaltet. SIP INVITE wird in [4] beschrieben. Die INVITE-Nachricht 425 enthält eine Spezifikation des zweiten Kriteriums (criteria_2) sowie die Spezifikation, dass das Automatisches-Update-Flag gesetzt ist. Dies erfolgt beispielsweise mittels eines gegenüber dem Stand der Technik neu definierten Content-Type. Die INVITE-Nachricht 425 ist beispielsweise gemäß Tabelle 2 ausgestaltet.
Tabelle 2
In Schritt 411 stellt der PoC-Steuerserverrechner 402 nach Erhalt der INVITE-Nachricht 425 fest, dass er die PoC-Gruppe nicht auflösen kann, d. h., dass er nicht bestimmen kann, aus welchen Gruppen-Mitgliedern sich die PoC-Gruppe aktuell zusammensetzt.
Dementsprechend fragt der PoC-Steuerserverrechner 402 durch Übermitteln einer ersten SUBSCRIBE-Nachricht 426 in Schritt 412 bei dem GM-Serverrechner 403 an, um die aktuellen (momentanen) Gruppen-Mitglieder, d. h., die Gruppen-Mitglieder aus denen sich die PoC-Gruppe aktuell zusammensetzt, zu ermitteln. Um den GM-Serverrechner 403 zu ermöglichen, die momentanen Gruppen-Mitglieder zu ermitteln, enthält die erste SUBSCRIBE-Nachricht 426 das zweite Kriterium. Die erste SUBSCRIBE-Nachricht 426 ist in diesem Ausführungsbeispiel gemäß einem SIP SUBSCRIBE ausgestaltet, beispielsweise gemäß Tabelle 3 (SIP SUBSCRIBE wird in [5] beschrieben.).
Tabelle 3
Das zweite Kriterium besteht wie erwähnt darin, dass die Gruppen-Mitglieder momentan nicht arbeiten sollen.
Da der GM-Serverrechner 403 zum Ermitteln der momentanen Gruppen-Mitglieder sowohl den Aufenthaltsort (Location-Status) der potentiellen Gruppen-Miglieder (bzw. der von den potentiellen Gruppen-Mitgliedern verwendeten PoC-Client-Einheiten) benötigt, sendet der GM-Serverrechner 403 in Schritt 413 eine zweite SUBSCRIBE-Nachricht 427 (gemäß SIP SUSCRIBE) an den Location-Serverrechner 404 um sich bei dem Location-Serverrechner 404 zu subskribieren und über den jeweiligen Location-Status der potentiellen Gruppen-Mitglieder informiert zu werden.
Ferner benötigt der GM-Serverrechner 403 zum Ermitteln der momentanen Gruppen-Mitglieder, ob die potentiellen Gruppen-Mitglieder momentan arbeiten. Diese Information sei für jedes potentielle Gruppen-Mitglied in einer für dieses Gruppen-Mitglied von den Presence-Serverrechner 405 verwalteten Präsenz-Information (Presence-Status) enthalten. Dementsprechend sendet der GM-Serverrechner 403 eine dritte SUBSCRIBE-Nachricht 428 in Schritt 414 an den Presence-Serverrechner 405. Die zweite SUBSCRIBE-Nachricht 427 und die dritte SUBSCRIBE-Nachricht 428 werden für jedes potentielle Gruppen-Mitglied übermittelt. In 4 ist dies exemplarisch für das erste Gruppen-Mitglied mit der Identifikation sip:[email protected], welche in der ersten SUBSCRIBE-Nachricht 427 und der zweiten SUBSCRIBE-Nachricht 428 enthalten ist, dargestellt.
Wie erwähnt besteht das erste Kriterium darin, dass sich die Freunde, d. h. die potentiellen Gruppen-Mitglieder in der Stadt Hamburg aufhalten sollen. Alternativ kann das erste Kriterium auch ein Location-Kriterium sein, dass von dem Aufenthaltsort des Benutzers (bzw. der PoC-Client-Einheit 401) abhängt. Das erste Kriterium könnte beispielsweise sein, dass nur potentielle Gruppen-Mitglieder, die sich (bzw. deren PoC-Client-Einheiten) in 5 km Umkreis der Position des Benutzers bzw. der PoC-Client-Einheit 401) aufhalten. In diesem Fall benötigt der GM-Serverrechner 403 zum Ermitteln der momentanen Gruppen-Mitglieder auch die Orts-Information des Benutzers der PoC-Client-Einheit 401 und sendet dementsprechend die erste SUBSCRIBE-Nachricht 427 nicht nur jeweils für alle potentiellen Gruppen-Mitglieder an den Location-Serverrechner 404, sondern auch für den Benutzer der PoC-Client-Einheit 401. Im Weiteren wird jedoch angenommen, dass das erste Kriterium ist, dass sich die Gruppen-Mitglieder in der Stadt Hamburg aufhalten sollen.
Die erste SUBSCRIBE-Nachricht 427, die wie erwähnt jeweils für jedes potentielle Gruppen-Mitglied an den Location-Serverrechner 404 übermittelt wird, wird von dem Location-Serverrechner 404 in Schritt 415 jeweils mit einer ersten NOTIFY-Nachricht 429 beantwortet, die den Location-Status des jeweiligen Gruppen-Mitglieds enthält.
Analog wird in Schritt 416 die zweite SUBSCRIBE-Nachricht 428, gegebenenfalls für jedes Gruppen-Mitglied an den Presence-Serverrechner 405 gesendet wird, jeweils von dem Presence-Serverrechner 405 durch Übermittlung einer zweiten NOTIFY-Nachricht 430 an den GM-Serverrechner 403 beantwortet. Die zweite NOTIFY-Nachricht 430 enthält für das jeweilige potentielle Gruppen-Mitglied die Information, ob das jeweilige potentielle Gruppen-Mitglied momentan arbeitet.
Unter Verwendung der in Schritt 415 und Schritt 416 an ihn übermittelten Informationen, ermittelt der GM-Serverrechner in Schritt 417 die momentanen Gruppen-Mitglieder, indem er für jedes potentielle Gruppen-Mitglied überprüft, ob das potentielle Gruppen-Mitglied das erste Kriterium und das zweite Kriterium erfüllt. In Schritt 418 übermittelt der GM-Serverrechner 403 mittels einer dritten NOTIFY-Nachricht 431 die Liste der momentanen Gruppen-Mitglieder (current_member_list) an den PoC-Steuerserverrechner 402. Die dritte NOTIFY-Nachricht 431 ist in diesem Beispiel gemäß einem SIP NOTIFY und gemäß Tabelle 4 ausgestaltet.
Tabelle 4
Nach Empfangen der dritten NOTIFY-Nachricht 431 ist der PoC-Steuerserverrechner 402 darüber informiert, welche Benutzer momentane Gruppen-Mitglieder sind. Optional werden nun noch die Schritte 419 und 420 durchgeführt. In Schritt 419 sendet der PoC-Steuerserverrechner die Liste der momentanen Gruppen-Mitglieder (current_member_list), in einer anderen Ausführungsform nur die Angabe der Anzahl der momentanen Gruppen-Mitglieder, mittels einer MESSAGE-Nachricht 432 an die PoC-Client-Einheit 401. Die MESSAGE-Nachricht 432 ist als SIP MESSAGE ausgestaltet. SIP MESSAGE ist in [6] beschrieben.
In Schritt 420 antwortet die PoC-Client-Einheit 401 mittels einer zweiten MESSAGE-Nachricht 433, die ebenfalls gemäß SIP MESSAGE ausgestaltet ist und in diesem Beispiel spezifiziert, dass die PoC-Session mit den momentanen Gruppen-Mitgliedern tatsächlich gestartet werden soll.
In Schritt 421 sendet der PoC-Steuerserverrechner 402 eine zweite INVITE-Nachricht 434 an alle momentanen Gruppen-Mitglieder, in diesem Beispiel an alle weiteren PoC-Client-Einheiten 406. Die zweite INVITE-Nachricht 434 ist als SIP INVITE ausgestaltet. Schritt 421 ist anschaulich ein Einladen aller weiteren PoC-Client-Einheiten 406 zu der aufzubauenden PoC-Session. Dies wird auf herkömmliche Art durchgeführt. Als Antwort senden die weiteren PoC-Client-Einheiten 406 jeweils eine erste 200 OK-Nachricht 435 (gemäß SIP 200 OK) an den PoC-Steuerserverrechner 401.
Durch Senden der ersten 200 OK-Nachricht 435 akzeptiert eine der weiteren PoC-Client-Einheiten 406 (bzw. der entsprechende Benutzer) die Einladung zu der aufzubauenden PoC-Session. Nachdem der PoC-Steuerserverrechner 402 die erste 200 OK-Nachricht 435 empfangen hat (d. h. sobald eines der momentanen Gruppen-Mitglieder die Einladung zu der PoC-Session akzeptiert hat) sendet der PoC-Steuerserverrechner eine zweite 200 OK-Nachricht 436 an die PoC-Client-Einheit 401, welche signalisiert, dass eines der momentanen Gruppen-Mitglieder die Einladung zu der PoC-Session akzeptiert hat.
Nun läuft die PoC-Session mit allen Freunden des Benutzers der PoC-Client-Einheit 401, die das erste Kriterium und das zweite Kriterium erfüllen (und die Einladung zu der PoC-Session akzeptiert haben).
5 zeigt ein Nachrichtenflussdiagramm 500 gemäß einem Ausführungsbeispiel der Erfindung.
Der dargestellte Nachrichtenfluss findet analog zu dem mit Bezug auf 4 beschriebenen Ausführungsbeispiel zwischen einer PoC-Client-Einheit 501, einem PoC-Steuerserverrechner 502, einem GM-Serverrechner 503, einem Location-Serverrechner 504, einem Presence-Serverrechner 505 und weiteren PoC-Client-Einheiten 506 statt.
In diesem Ausführungsbeispiel wird davon ausgegangen, dass der Benutzer der PoC-Client-Einheit 501 mit allen Benutzern von PoC, die sich momentan in der gleichen Universität aufhalten wie er und die momentan nicht arbeiten, eine PoC-Session starten möchte. Der Ausdruck ”momentane Gruppen-Mitglieder” usw. werden im Weiteren analog zu dem mit Bezug auf 4 erläuterten Ausführungsbeispiel verwendet.
In Schritt 507 übermittelt die PoC-Client-Einheit 501 eine group_generation_request-Nachricht 524 an den GM-Serverrechner 503 um anzufordern, dass eine PoC-Gruppe erzeugt wird. Die group_generation_request-Nachricht 524 enthält die Spezifikation eines ersten Kriteriums (criteria_1), das besagt, dass sich die Gruppen-Mitglieder zum Zeitpunkt der PoC-Session, d. h. zum Zeitpunkt der Benutzung der PoC-Gruppe im Rahmen einer PoC-Session, in derselben Universität wie der Benutzer der PoC-Client-Einheit 501 aufhalten sollen. Die group_generation_request-Nachricht 524 enthält ferner eine Spezifikation eines zweiten Kriteriums (criteria_2), das besagt, dass die momentanen Gruppen-Mitglieder (der PoC-Gruppe) nicht arbeiten sollen. Die group_generation_request-Nachricht 524 ist beispielsweise gemäß Tabelle 5 ausgestaltet und der Benutzer legt durch Übermitteln der group_generation_request-Nachricht 524 die PoC-Gruppe an, die durch das erste Kriterium und das zweite Kriterium dynamisch definiert ist.
Tabelle 5
Nun ist es erforderlich, dass der GM-Serverrechner 503 alle PoC-Benutzer ermittelt, die das erste Kriterium und das zweite Kriterium erfüllen.
In einer Ausführungsform, welche nicht in 5 dargestellt ist, geht der GM-Serverrechner 530 wie folgt vor. Im Gegensatz zu der mit Bezug auf 4 erläuterten Ausführungsform wurde dem GM-Serverrechner 503 von der PoC-Client-Einheit 501 keine Liste von potentiellen Gruppen-Mitgliedern übermittelt. Deshalb ermittelt der GM-Serverrechner 503 eine Liste von potentiellen Gruppen-Mitgliedern, anschaulich eine allgemeine Mitgliederliste als Basis. Dazu fordert der GM-Serverrechner bei einer oder mehreren Netzwerkeinheiten eine Liste von bekannten oder geeigneten PoC-Client-Einheiten an. Diese Netzwerkeinheiten sind beispielsweise ein HLR (Home Location Register (des gleichen Betreibers (Operators)), der auch das Kommunikationsnetzwerk zur Kommunikation zwischen der PoC-Client-Einheit 501 und dem GM-Serverrechner 503 bereitstellt, ein ”Meta”-HLR, d. h. ein HLR, der über die Informationen von HLRs von verschiedenen Betreibern gespeichert hat, oder verschiedene HLRs von verschiedenen Betreibern.
Die so angeforderte Liste von potentiellen Gruppen-Mitgliedern verwendet der GM-Serverrechner 503 anschaulich als Basis und sendet analog zu den mit Bezug auf 4 erläuterten Schritten 413 und 414 SUBSCRIBE-Nachrichten für jedes potentielle Gruppen-Mitglied zu dem Location-Serverrechner 504 bzw. zu dem Presence-Serverrechner 505 und ermittelt auf diese Weise die zum Bestimmen der momentanen Liste von Gruppen-Mitgliedern erforderliche Location-Information und Präsenz-Information der potentiellen Gruppen-Mitglieder. Anschließend ermittelt der GM-Serverrechner 503 die momentane Liste von Gruppen-Mitgliedern (current_member_list). Da die Liste von potentiellen Gruppen-Mitgliedern, die der GM-Serverrechner 503 in dieser Ausführungsform ermittelt, typischerweise sehr groß sein kann ist insbesondere zum Erstellen der Liste von potentiellen Gruppen-Mitgliedern ein sehr hoher Signalisierungsaufwand erforderlich. Deshalb wird die folgende Ausführungsform bevorzugt, die auch in 5 illustriert ist.
In Schritt 508 sendet der GM-Serverrechner 503 eine erste SUBSCRIBE-Nachricht 525 an dem Location-Serverrechner 504. Die erste SUBSCRIBE-Nachricht 525 wird nicht nur an den Location-Serverrechner 504 gesendet, sonder an alle geeigneten Location-Server, d. h. an Location-Sever, die Orts-Informationen von PoC-Client-Einheiten verwalten.
Exemplarisch wird der weitere Ablauf anhand des Location-Serverrechners 504 erläutert. Die in Schritte 508 übermittelte erste SUBSCRIBE-Nachricht 525 weist eine Spezifikation des ersten Kriteriums (welches anschaulich Location-spezifisch ist) auf. Die erste SUBSCRIBE-Nachricht 525 ist beispielsweise gemäß Tabelle 6 ausgestaltet.
Tabelle 6
In Schritt 509 beantwortet der Location-Server 504 das Subscribe des GM-Servers 503, d. h. die erste SUBSCRIBE-Nachricht 525, durch Übermittlung einer ersten NOTIFY-Nachricht 526 an den GM-Serverrechner 503. Auf diese Weise signalisiert der Location-Serverrechner 504 dem GM-Serverrechner 503 eine Liste von (PoC-)Benutzern (bzw. eine Liste der von den Benutzern verwendeten PoC-Client-Einheiten), die das erste Kriterium erfüllen (matched_users_list_1). Die erste NOTIFY-Nachricht 526 ist beispielsweise gemäß Tabelle 7 ausgestaltet.
Tabelle 7
Analog zu den Schritten 508 und 509 werden die Schritte 510 und 511 durchgeführt. Das heißt, der GM-Serverrechner 503 übermittelt in Schritt 510 eine zweite SUBSCRIBE-Nachricht 527 mit einer Spezifikation des zweiten Kriteriums an den Presence-Serverrechner 505 (exemplarisch, analog zu oben wird jeweils eine zweite SUBSCRIBE-Nachricht an alle geeigneten Presence-Serverrechner übermittelt). In Schritt 511 antwortet der Presence-Serverrechner 505 durch Übermittlung einer zweiten NOTIFY-Nachricht 528 an dem GM-Serverrechner 503, die eine Liste der (PoC-)Benutzer (bzw. eine Liste der von den Benutzern verwendeten PoC-Client-Einheiten) enthält, die das zweite Kriterium erfüllen (matched_users_list_2).
In Schritt 512 ermittelt der GM-Serverrechner 503 die momentane Liste von Gruppen-Mitgliedern (current_member_list), indem er die Schnittmenge aus der Liste von Benutzern (bzw. der von den Benutzern verwendeten PoC-Client-Einheiten), die das erste Kriterium erfüllen, und der Liste von Benutzern (bzw. der von den Benutzern verwendeten PoC-Client-Einheiten), die das zweite Kriterium erfüllen, bildet.
In einer anderen Ausführungsform wird die zweite SUBSCRIBE-Nachricht 527 nur an solche Präsenz-Serverrechner gesendet, die Präsenz-Information über Benutzer (bzw. der von den Benutzern verwendeten PoC-Client-Einheiten), die in der NOTIFY-Nachricht 526 gelistet sind, verwalten. Anschaulich fragt der GM-Serverrechner 503 nur für die Benutzer nach, die das erste Kriterium erfüllen. Dementsprechend erhält der GM-Serverrechner 503 in Schritt 511 nur für die Benutzer, die das erste Kriterium erfüllen, Präsenz-Informationen. Unter Verwendung dieser Präsenz-Informationen und der in Schritt 509 erhaltenen Information ermittelt der GM-Serverrechner 503 in Schritt 512 die momentane Liste der Gruppen-Mitglieder.
Der weitere Verlauf ist unabhängig davon, wie die momentane Liste der Gruppen-Mitglieder ermittelt wurde, insbesondere wird der folgende Verlauf auch durchgeführt, wenn, wie oben beschrieben, der GM-Serverrechner 503 zunächst eine Liste von potentiellen Gruppen-Mitglieder ermittelt, indem er beispielsweise bei einem oder mehreren HLRs entsprechende Informationen anfordert.
In Schritt 513 beantwortet der GM-Serverrechner 503 die von der PoC-Client-Einheit 501 in Schritt 507 getätigte Anfrage durch Übermittlung einer group_generation_response-Nachricht 529 an die PoC-Client-Einheit 501. Die group_generation_response-Nachricht 529 enthält eine eindeutige Gruppen-Identifikation der angelegten PoC-Gruppe, in diesem Fall sip:[email protected], und die momentane Liste der Gruppen-Mitglieder (oder alternativ nur die Anzahl der Benutzer, die Teil der momentanen Liste von Gruppen-Mitgliedern ist).
Zu einem späteren Zeitpunkt, in Schritt 514, wählt der Benutzer der PoC-Client-Einheit 501 die PoC-Gruppe aus, um mit dem momentanen Gruppen-Mitgliedern der PoC-Gruppe mittels der ersten PoC-Client-Einheit 501 eine PoC-Session zu starten. Ferner soll auch während der PoC-Session die aktuelle Zusammensetzung der PoC-Gruppe berücksichtigt werden, d. h. es sollen stets die momentanen Gruppen-Mitglieder (auch wenn diese sich im Laufe der PoC-Session ändern) Teil der PoC-Sessions sein (wenn diese eine Einladung akzeptieren).
Beispielsweise sollen im Laufe der PoC-Session Gruppen-Mitglieder eingeladen werden, sobald diese das erste Kriterium und das zweite Kriterium erfüllen. Um dies zu erreichen, setzt der Benutzer das Automatisches-Update-Flag (automatic_update_flag).
In Schritt 515 sendet der Benutzer mittels der ersten PoC-Client-Einheit 501 eine erste INVITE-Nachricht 530 zum Starten der PoC-Session. Die erste INVITE-Nachricht 530 ist in diesem Beispiel gemäß einem SIP INVITE ausgestaltet, dass an die eindeutige Gruppenidentifikation adressiert ist. In der ersten INVITE-Nachricht 530 ist spezifiziert, dass das Automatisches-Update-Flag gesetzt ist, beispielsweise indem diese Spezifikation als SIP-Header (SIP-Nachrichtenkopf) in der ersten INVITE-Nachricht 530 enthalten ist. Dementsprechend ist die erste INVITE-Nachricht 530 gemäß Tabelle 8 ausgestaltet.

INVITE sip:[email protected] SIP/2.0

...

Updatefrequence: numerischer Wert

...

Tabelle 8
In Schritt 516 stellt der PoC-Steuerserverrechner 502 nach Erhalt der ersten INVITE-Nachricht 530 fest, dass er die mittels der Gruppenidentifikation spezifizierte PoC-Gruppe nicht auflösen kann. In Schritt 531 fordert er deshalb mittels einer dritten SUBSCRIBE-Nachricht 531 bei dem GM-Serverrechner 503 an, dass dieser die momentanen Gruppen-Mitglieder ermittelt. Die dritte SUBSCRIBE-Nachricht 531 ist gemäß einem SIP SUBSCRIBE und gemäß Tabelle 9 ausgestaltet.
Tabelle 9
In Schritt 518 antwortet der GM-Serverrechner 503 auf die dritte SUBSCRIBE-Nachricht 531, indem er die Liste der momentanen Gruppen-Mitglieder mittels einer dritten NOTIFY-Nachricht 518 an den PoC-Steuerserverrechner 502 übermittelt. Die dritte NOTIFY-Nachricht 532 ist gemäß Tabelle 10 ausgestaltet.
Tabelle 10
Nach Empfangen der dritten NOTIFY-Nachricht 532 ist der PoC-Steuerserverrechner 502 darüber informiert, welche Benutzer momentane Gruppen-Mitglieder sind. Optional werden nun noch die Schritte 519 und 520 durchgeführt. In Schritt 519 sendet der PoC-Steuerserverrechner 502 die Liste der momentanen Gruppen-Mitglieder (current_member_list), in einer anderen Ausführungsform nur die Angabe der Anzahl der momentanen Gruppen-Mitglieder, mittels einer UPDATE-Nachricht 533 an die PoC-Client-Einheit 501. Die UPDATE-Nachricht 533 ist als SIP UPDATE (oder alternativ als SIP INFO) ausgestaltet.
In Schritt 520 antwortet die PoC-Client-Einheit 501 mittels einer zweiten UPDATE-Nachricht 534, die ebenfalls gemäß SIP UPDATE ausgestaltet ist und in diesem Beispiel spezifiziert, dass die PoC-Session mit den momentanen Gruppen-Mitgliedern tatsächlich gestartet werden soll. Die PoC-Client-Einheit 501 kann zu diesem Zeitpunkt den Ablauf beenden, indem sie statt der zweiten UPDATE-Nachricht 534 eine CANCEL-Nachricht (gemäß SIP CANCEL, siehe [4]) an den PoC-Steuerserverrechner 502 übermittelt.
In Schritt 521 sendet der PoC-Steuerserverrechner 502 eine zweite INVITE-Nachricht 535 an alle momentanen Gruppen-Mitglieder, in diesem Beispiel an alle weiteren PoC-Client-Einheiten 506. Die zweite INVITE-Nachricht 535 ist als SIP INVITE ausgestaltet. Schritt 521 ist anschaulich ein Einladen aller weiteren PoC-Client-Einheiten 506 zu der aufzubauenden PoC-Session. Dies wird auf herkömmliche Art durchgeführt. Als Antwort senden die weiteren PoC-Client-Einheiten 506 jeweils eine erste 200 OK-Nachricht 536 (gemäß SIP 200 OK) an den PoC-Steuerserverrechner 401.
Durch Senden der ersten 200 OK-Nachricht 536 akzeptiert eine der weiteren PoC-Client-Einheiten 506 (bzw. der entsprechende Benutzer) die Einladung zu der aufzubauenden PoC-Session. Nachdem der PoC-Steuerserverrechner 502 die erste 200 OK-Nachricht 536 empfangen hat (d. h. sobald eines der momentanen Gruppen-Mitglieder die Einladung zu der PoC-Session akzeptiert hat) sendet der PoC-Steuerserverrechner eine zweite 200 OK-Nachricht 537 an die PoC-Client-Einheit 401, welche signalisiert, dass eines der momentanen Gruppen-Mitglieder die Einladung zu der PoC-Session akzeptiert hat.
Nun läuft die PoC-Session mit allen PoC-Benutzern, die das erste Kriterium und das zweite Kriterium erfüllen (und die Einladung zu der PoC-Session akzeptiert haben).
Nach Ablauf der in 4 und 5 dargestellten Nachrichtflüsse ist, wie erläutert, eine PoC-Session zwischen der ersten PoC-Client-Einheit 401, 501 und den PoC-Client-Einheiten, aus denen sich die momentane Liste von Gruppen-Mitgliedern zusammensetzt, aufgebaut. Im Folgenden wird mit Bezug auf 6 und 7 erläutert, wie gemäß einem Ausführungsbeispiel der Erfindung vorgegangen wird, wenn sich die Zusammensetzung der momentanen Liste von Gruppen-Mitgliedern ändert.
6 zeigt ein Nachrichtenflussdiagramm 600 gemäß einem Ausführungsbeispiel der Erfindung.
Entsprechend 4 und 5 findet der dargestellte Nachrichtfluss zwischen einer PoC-Client-Einheit 601, einem PoC-Steuerserverrechner 602, einem GM-Serverrechner 603, einen Location-Serverrechner 604 und weiteren PoC-Client-Einheiten 605 durchgeführt, die den entsprechenden in 4 und 5 dargestellten Netzwerkelementen entsprechen. Ferner ist eine neu hinzukommende PoC-Client-Einheit 606 an dem dargestellten Nachrichtenfluss beteiligt.
Wie erwähnt wird davon ausgegangen, dass eine PoC-Session mit den momentanen Gruppen-Mitgliedern als Teilnehmer aufgebaut ist, ferner wird angenommen, dass das Automatisches-Update-Flag gesetzt ist und der PoC-Steuerserverrechner 602 darüber informiert wurde, beispielsweise mittels der ersten INVITE-Nachricht 530, die in Schritt 515 übermittelt wurde.
Es wird angenommen, dass die neu hinzukommende PoC-Client-Einheit 606 (bzw. der Benutzer der neu hinzukommenden PoC-Client-Einheit) bisher nicht an der PoC-Session teilgenommen hat. Beispielsweise wird die momentane Liste von Gruppen-Mitgliedern gemäß dem Kriterium ermittelt, dass die momentanen Gruppen-Mitglieder sich (zusammen mit ihren PoC-Client-Einheiten) in Hamburg aufhalten sollen, der Benutzer der neu hinzugekommenen PoC-Client-Einheit 606, dies sei der Benutzer mit der Bezeichnung Freund_17, hat sich aber bisher nicht in Hamburg aufgehalten, kommt aber nun während der schon aufgebauten PoC-Session zurück nach Hamburg.
Es wird ferner angenommen, dass der GM-Serverrechner 603 bei dem Location-Server 604 angefordert hat, Location-Informationen über den Benutzer Freund_17 zu erhalten, beispielsweise wurde in Schritt 413 für den Benutzer Freund_17 eine entsprechende zweite SUBSCRIBE-Nachricht 427 an den Location-Server 404 übermittelt, da der Benutzer Freund_17 auf der Liste von potentiellen Gruppen-Mitgliedern auftritt. Etwaige weitere Kriterien, gemäß denen die momentane Liste von Gruppen-Mitgliedern ermittelt wird, beispielsweise wie oben ein Kriterium bezüglich der Verfügbarkeit der Gruppen-Mitglieder, werde von dem Benutzer Freund_17 erfüllt, beispielsweise hat er einen entsprechenden Präsenz-Status gesetzt.
In Schritt 607 wird der GM-Serverrechner 603 gemäß seiner Anforderung mittels einer ersten NOTIFY-Nachricht 614 darüber informiert, dass der Benutzer Freund_17 mit der neu hinzukommenden PoC-Client-Einheit 606 wieder in Hamburg ist, d. h. der GM-Serverrechner 603 wird über den Location-Status des Benutzers Freund_17 (location_status_17) informiert.
Nach Erhalt der ersten NOTIFY-Nachricht 314 ermittelt der GM-Serverrechner 603 in Schritt 608 die momentane Liste von Gruppen-Mitgliedern erneut, filtert anschaulich erneut nach den Kriterien, und stellt nun fest, dass der Benutzer Freund_17 alle vorgegebenen Kriterien erfüllt.
Wie oben beschrieben hat auch der PoC-Steuerserverrechner 602 eine SUBSCRIBE-Nachricht an den GM-Serverrechner 603 gesendet (beispielsweise die erste SUBSCRIBE-Nachricht 426 in Schritt 412) und damit angefordert, dass er über die momentane Zusammensetzung der PoC-Gruppe informiert wird.
Dementsprechend sendet der GM-Serverrechner 603 in Schritt 609 eine zweite NOTIFY-Nachricht 615 an den PoC-Steuerserverrechner 602, mittels welcher der PoC-Steuerserverrechner 602 darüber informiert wird, dass ein neues momentanes Gruppen-Mitglied (new_member_17) hinzugekommen ist.
Die nachfolgenden Schritte 610 und 611 werden optional durchgeführt.
In Schritt 610 sendet der PoC-Steuerserverrechner 602 eine erste MESSAGE-Nachricht 616 (gemäß SIP MESSAGE), an die PoC-Client-Einheit 601 und informiert so die PoC-Client-Einheit 601 über das neu hinzugekommene momentane Gruppen-Mitglied.
Die PoC-Client-Einheit 601 sendet als Antwort in Schritt 611 eine zweite MESSAGE-Nachricht 617, mittels welcher die PoC-Client-Einheit 601 bestätigt, dass der Benutzer Freund_17 zu der laufenden PoC-Session hinzugenommen, d. h. eingeladen werden soll. In Schritt 612 lädt der PoC-Steuerserverrechner 602 die neu hinzukommende PoC-Client-Einheit 606 zu der PoC-Session ein. Dies erfolgt durch Übermittlung einer INVITE-Nachricht 618. Die neu hinzukommende PoC-Client-Einheit 606 beantwortet die INVITE-Nachricht 618 in Schritt 613 mittels einer 200 OK-Nachricht 619. Die Schritte 612 und 613 werden auf herkömmliche Weise gemäß einem SIP INVITE und einem SIP 200 OK durchgeführt. Anschließend nimmt auch der Benutzer Freund_17 an der PoC-Session teil.
7 zeigt ein Nachrichtenflussdiagramm 700 gemäß einem Ausführungsbeispiel der Erfindung.
Der dargestellte Nachrichtenfluss findet wie in 6 zwischen einer PoC-Client-Einheit 701, einem PoC-Steuerserverrechner 702, einem GM-Serverrechner 703, einem Location-Serverrechner 704 und weiteren PoC-Client-Einheiten 705 statt. Es gelten die Annahmen wie zu Beginn des auf 6 erläuterten Ablaufs, nur kommt diesmal nicht im Laufe der PoC-Session ein neuer Benutzer (bzw. eine neue PoC-Client-Einheit) zu der PoC-Session hinzu, sonder eine verlassende PoC-Client-Einheit 706, welche von dem Benutzer mit der Bezeichnung Freund_05 verwendet wird, verlässt die PoC-Session.
Zunächst wird angenommen, dass der Benutzer Freund_05 mittels der verlassenden PoC-Client-Einheit 706 an der bestehenden PoC-Session teilnimmt. Insbesondere erfüllt der Benutzer Freund_05 bisher die Kriterien, gemäß welcher die momentanen Gruppen-Mitglieder bestimmt werden. Nun wird angenommen, dass der Freund_05 eines der Kriterien verletzt. Beispielsweise besteht ein Kriterium darin, dass sich die momentanen Gruppen-Mitglieder in der Stadt Hamburg aufhalten sollen, und der Benutzer Freund_05 verlässt mit der verlassenden PoC-Client-Einheit 706 die Stadt Hamburg.
Analog zu Schritt 607 sendet der Location-Serverrechner 704 daraufhin eine NOTIFY-Nachricht 714 in Schritt 707 an den GM-Serverrechner 703, mittels welcher der GM-Serverrechner über den neuen Location-Status des Benutzers Freund_05 informiert wird.
Analog zu Schritt 608 ermittelt der GM-Serverrechner 703 in Schritt 708 erneut die aktuelle Zusammensetzung der PoC-Gruppe. Dabei stellt der GM-Serverrechner 703 fest, dass der Benutzer Freund_05 die Kriterien, die die momentanen Gruppen-Mitglieder erfüllen sollen, nicht erfüllt.
Dementsprechend und analog zu Schritt 609 informiert er in Schritt 709 den PoC-Steuerserverrechner 702 mittels einer zweiten NOTIFY-Nachricht 715, dass der Benutzer Freund_05 kein momentanes Gruppen-Mitglied mehr ist.
Die Schritte 710 und 711 werden optional durchgeführt. In Schritt 710 sendet der PoC-Steuerserverrechner 702 eine erste MESSAGE-Nachricht 716 (gemäß SIP MESSAGE) ausgestaltet ist, an die PoC-Client-Einheit 701 und signalisiert so der PoC-Client-Einheit 701, dass der Benutzer Freund_05 kein momentanes Gruppen-Mitglied mehr ist (remove_member_05). In Schritt 711 bestätigt die PoC-Client-Einheit 701 mittels einer zweiten MESSAGE-Nachricht 717 (gemäß SIP MESSAGE), dass der Benutzer Freund_05 aus der bestehenden PoC-Session entfernt werden soll.
In Schritt 712 entfernt der PoC-Steuerserverrechner 702 die verlassende PoC-Client-Einheit 706 aus der bestehenden PoC-Session, indem der PoC-Steuerserverrechner 702 eine BYE-Nachricht 718 an die verlassende PoC-Client-Einheit 706 sendet.
Dies bestätigt die verlassende PoC-Client-Einheit 706 in Schritt 713 mittels einer 200 OK-Nachricht 719. Die Schritte 712 und 713 werden beispielsweise auf herkömmliche Weise durchgeführt.
Anschließend ist der Benutzer Freund_05 nicht mehr Teil der bestehenden PoC-Session.
Im Folgenden wird mit Bezug auf 8 und 9 ein Ausführungsbeispiel für einen anderen Anwendungsfall beschrieben, bei dem eine andere Signalisierung durchgeführt wird als bei den oben beschriebenen Ausführungsbeispielen.
8 zeigt ein Nachrichtenflussdiagramm 800 gemäß einem Ausführungsbeispiel der Erfindung.
Analog zu den oben beschriebenen Ausführungsbeispielen findet der dargestellte Nachrichtenfluss zwischen einer PoC-Client-Einheit 801, einem PoC-Steuerserverrechner 802, einem GM-Serverrechner 803, eine Location-Serverrechner 804, einen Presence-Serverrechner 805 sowie weiteren PoC-Client-Einheiten 806 statt.
Es werden zwei funktionale Einheiten des PoC-Steuerserverrechners 802 betrachtet: ein Session-Controller 807 sowie ein Media Mixer 808. Der Session-Controller 807 ist für die Signalisierungsaufgaben des PoC-Steuerserverrechners 802 zuständig, d. h. er führt die von dem PoC-Steuerserverrechner 802 durchzuführenden Signalisierungen durch, beispielsweise eine Signalisierung zur Einladung einer PoC-Client-Einheit zu einer PoC-Session. Diese Signalisierungen werden gemäß dem SIP (Session Initiation Protocol) durchgeführt. Der Media-Mixer (Medienmischer) 808 regelt die Verteilung der Kommunikationsdaten im Rahmen einer PoC-Session an alle an der PoC-Session teilnehmenden PoC-Client-Einheiten.
In diesem Ausführungsbeispiel wird angenommen, dass die PoC-Client-Einheit 801 die PoC-Client-Einheit einer Taxi-Zentrale eines Berliner Taxi-Unternehmens ist. Zu einer PoC-Gruppe mit der Bezeichnung ”Taxis” sollen alle Taxi-Fahrer (ausgestattet mit jeweils einer der weiteren PoC-Client-Einheiten 906) gehören. Jedes Mal, wenn die Taxi-Zentrale einen Auftrag zur Fahrgastbeförderung bekommt, soll eine PoC-Kommunikation innerhalb einer laufenden PoC-Session gestartet werden, wobei alle Taxi-Fahrer (bzw. die von ihnen verwendeten PoC-Client-Einheiten) an der PoC-Kommunikation teilnehmen sollen, die sich im Umkreis von x Kilometern des zu befördernden Fahrgast befinden und die ihren Presence-Status auf ”Taxi frei” gesetzt haben und somit signalisieren, dass sie nicht gerade einen Fahrgast transportieren.
Eine PoC-Kommunikation innerhalb der PoC-Session wird, wie unten erläutert, durch eine Identifikation eindeutig identifiziert und zwischen den Teilnehmern der PoC-Kommunikation (die eine Untergruppe der Teilnehmer der PoC-Session sind) werden (im Rahmen der PoC-Session und im Rahmen der PoC-Kommunikation) Sprachdaten ausgetauscht. Anschaulich werden beispielsweise im Laufe einer PoC-Session, die während eines ganzen Tages (zwischen allen Taxi-Fahrern und der Taxi-Zentrale) besteht, mehrere PoC-Kommunikationen aufgebaut, in deren Rahmen mehrere inhaltlich zusammenhängende Sprachnachrichten (zwischen den Teilnehmern der jeweiligen PoC-Kommunikation) übermittelt werden.
Die Erzeugung von mehreren PoC-Kommunikationen (eine für jeden eingehenden Auftrag) innerhalb einer PoC-Session hat gegenüber der Erzeugung mehrerer PoC-Sessions (einer je Auftrag) den Vorteil, dass ein erheblich geringerer Signalisierungsaufwand erforderlich ist.
Zunächst wird auf herkömmliche Weise eine PoC-Session zwischen der PoC-Client-Einheit 801 und den weiteren PoC-Client-Einheiten 806, die wie erwähnt die PoC-Client-Einheiten aller angemeldeten Taxis sind, d. h. aller Taxis, die momentan im Dienst sind (unabhängig davon, ob die Taxis frei oder belegt sind), aufgebaut (dieser Schritt ist nicht gezeigt). Dies kann auf herkömmliche Weise durchgeführt werden, beispielsweise wie mit Bezug auf 1 erläutert. Für das Weitere ist es unerheblich, ob es sich um eine sogenannte One-To-Many-To-One-Topologie handelt (d. h. die PoC-Client-Einheit 801 empfängt im Rahmen der PoC-Session Kommunikationsdaten von allen weiteren PoC-Client-Einheiten 806, aber die weiteren PoC-Client-Einheiten 806 empfangen nicht gegenseitig Kommunikationsdaten, d. h. empfangen keine Kommunikationsdaten von den jeweils anderen PoC-Client-Einheiten der weiteren PoC-Client-Einheiten 806) oder um eine One-To-Many-Topology handelt (d. h., dass die PoC-Client-Einheiten 801 und auch die weiteren PoC-Client-Einheiten 806 alle Kommunikationsdaten von den weiteren PoC-Client-Einheiten 806 empfangen, d. h. dass anschaulich jeder jeden hört).
Analog zu den oben beschriebenen Ausführungsbeispielen, beispielsweise analog zu den Schritten 413 und 415 in 4, wird zwischen dem GM-Serverrechner 803 und dem Location-Serverrechner 804 ein erstes SUBSCRIBE-NOTIFY-Nachrichtenpaar 833 für jede PoC-Client-Einheit der weiteren PoC-Client-Einheiten 806 ausgetauscht, sodass, wie oben mit Bezug auf 4 beschrieben, dem GM-Serverrechner 803 von dem Location-Serverrechner 804 stets der aktuelle Location-Status der weiteren PoC-Client-Einheiten 806 signalisiert wird.
Analog wird in Schritt 810 zwischen dem GM-Serverrechner 803 und dem Presence-Serverrechner 805 ein zweites SUBSCRIBE-NOTIFY-Nachrichtenpaar 834 ausgetauscht, sodass der GM-Serverrechner 803 von dem Presence-Serverrechner 805 stets über dem aktuellen Presence-Status der weiteren PoC-Client-Einheiten 806 informiert wird, analog zu den oben beschriebenen Ausführungsbeispielen.
In Schritt 811 besteht eine PoC-Session zwischen der ersten PoC-Client-Einheit 801 und den weiteren PoC-Client-Einheiten 806.
Nun wird angenommen, dass der erste Auftrag für die Beförderung eines Fahrgasts, der sich am Berliner Alexanderplatz befindet, bei der Taxi-Zentrale eingeht. Mittels der folgenden Ablaufschritte wird nun von der PoC Client-Einheit 801 innerhalb der bestehenden PoC-Session eine PoC-Kommunikation mit denen der weiteren PoC-Client-Einheiten 806 aufgebaut, die

– an der bestehenden PoC-Session teilnehmen
– sich im Umkreis von 3 km des Berliner Alexanderplatzes befinden (in diesem Beispiel das erste Kriterium) und
– deren Presence-Status ”Taxi frei” ist (in diesem Beispiel das zweite Kriterium).

Diese PoC-Client-Einheiten der weiteren PoC-Client-Einheiten 806 werden im Folgenden als die teilzunehmenden PoC-Client-Einheiten bezeichnet.
In Schritt 812 sendet die PoC-Client-Einheit eine re-INVITE-Nachricht 835 (ausgestaltet gemäß einem SIP re-INVITE) mit einem entsprechenden Content-Type (Application/Criteria+XML, vergleiche Tabelle 2), mittels welchem das erste Kriterium und das zweite Kriterium spezifiziert werden, an den PoC-Steuerserverrechner 802. Die re-INVITE-Nachricht 835 enthält in einer Ausführungsform eine eindeutige PoC-Kommunikationsidentifikation (PK_id_prop). In Schritt 813 generiert der PoC-Steuerserverrechner 802 eine (eigene) PoC-Kommunikationsidentifikation (PK_id). In Schritt 814 sendet der PoC-Steuerserverrechner 802 eine Bestätigung (anschaulich als vorläufige Antwort) an die PoC-Client-Einheit 801 in Form einer 183-session-processing-Nachricht 836 (ausgestaltet gemäß SIP 183 session processing), mittels welcher auch die PoC-Kommunikations-Identifikation PK_id signalisiert wird.
Eine PoC-Kommunikations-Identifikation ist beispielsweise eine Port-Nummer, die die eindeutige Adressierung einer Applikation für applikationsspezifische Daten ermöglicht. In einer Ausführungsform existieren zwei PoC-Kommunikations-Identifikationen, beispielsweise eine PoC-Kommunikations-Identifikation PK_id_prop auf Seiten der PoC-Client-Einheit 801 und eine PoC-Kommunikations-Identifikation PK_id auf Seiten des PoC-Steuerserverrechners 802.
In Schritt 815 sendet der PoC-Steuerserverrechner 802 eine SUBSCRIBE-Nachricht 837 an den GM-Serverrechner 803, mittels welcher die PoC-Kommunikations-Identifikation PK_id, das erste Kriterium und das zweite Kriterium signalisiert werden.
Wie oben erläutert, ist der GM-Serverrechner 803 stets über den aktuellen Location-Status und den aktuellen Presence-Status jeder POC-Client-Einheit der weiteren PoC-Client-Einheiten 806 informiert. Auf Basis dieser Informationen ermittelt der GM-Serverrechner 803 in Schritt 816 alle teilzunehmenden PoC-Client-Einheiten, d. h. alle PoC-Client-Einheiten der weiteren PoC-Client-Einheiten 806, die das erste Kriterium und das zweite Kriterium erfüllen.
Die teilzunehmenden PoC-Client-Einheiten 806 werden von dem GM-Serverrechner in der momentanen Liste vom Gruppen-Mitgliedern (current_member_list) spezifiziert. In Schritt 817 sendet der GM-Serverrechner 803 eine NOTIFY-Nachricht 838 an die PoC-Steuerserverrechner 802, mittels welcher er die momentane Liste von Gruppen-Mitgliedern, welche die momentane Liste von Gruppen-Mitgliedern zu der PoC-Kommunikation ist, die durch die in der SUBSCRIBE-Nachricht 837 enthaltenen PoC-Kommunikations-Identifikation PK_id spezifiziert wird, signalisiert.
Die Schritte 818 und 819 werden optional durchgeführt. In Schritt 818 signalisiert der PoC-Serverrechner 802 mittels einer ersten MESSAGE-Nachricht 839 der PoC-Client Einheit 801 welche PoC-Client-Einheiten der weiteren PoC-Client-Einheiten 806 das erste Kriterium und das zweite Kriterium erfüllen. In einer anderen Ausführungsform signalisiert der PoC-Steuerserverrechner 802 nur die Anzahl der teilzunehmenden PoC-Client-Einheiten, d. h. die Anzahl der weiteren PoC-Client-Einheiten 806, die das erste Kriterium und das zweite Kriterium erfüllen (#_of_members).
In Schritt 819 signalisiert die erste PoC-Client-Einheit 801, ob eine PoC-Kommunikation mit den PoC-Client-Einheiten, die von der aktuellen Liste von Gruppen-Mitgliedern spezifiziert werden, aufgebaut werden soll. In diesem Beispiel wird angenommen, dass keine PoC-Kommunikation mit dem von der aktuellen Liste von Gruppen-Mitgliedern spezifizierten PoC-Client-Einheiten aufgebaut werden soll. Beispielsweise weist die aktuelle Liste von PoC-Client-Einheiten die Spezifikation von 100 PoC-Client-Einheiten auf, und der Benutzer in der Taxi-Zentrale entscheidet, dass das zu viele sind.
Dementsprechend sendet die PoC-Client-Einheit 801 in Schritt 819 eine zweite MESSAGE-Nachricht 840 an den PoC-Steuerserverrechner 802, mittels welcher spezifiziert wird, dass keine PoC-Kommunikation mit den von der aktuellen Liste von Gruppen-Mitgliedern spezifizierten PoC-Client-Einheiten aufgebaut werden soll (accept=no). Ferner enthält die zweite MESSAGE-Nachricht 840 abgeänderte Kriterien (criteria_update), beispielsweise die Änderung des erste Kriteriums, das sich die teilzunehmenden PoC-Client-Einheiten nicht innerhalb von drei Kilometern des Berliner Alexanderplatzes befinden sollen, sondern in einem Umkreis von einem Kilometer des Berliner Alexanderplatzes. Gemäß den abgeänderten Kriterien wird analog zu den Schritten 815, 816 und 817 eine (neue) aktuelle Liste von Gruppen-Mitgliedern ermittelt, insbesondere wird ein drittes SUBSCRIBE-NOTIFY-Nachrichtenpaar 841 zwischen dem PoC-Steuerserverrechner 802 und dem GM-Serverrechner 803 ausgetauscht.
Analog zu Schritt 818 wird der PoC-Client-Einheit 801 die (neue) aktuelle Liste von Gruppen-Mitgliedern signalisiert (nicht gezeigt). Nun wird angenommen, dass mit dem PoC-Client-Einheiten, die von der neuen aktuellen Liste von Gruppen-Mitgliedern spezifiziert wird, eine PoC-Kommunikation aufgebaut werden soll. Dementsprechend sendet die PoC-Client-Einheit 801 im Schritt 821 eine dritte MESSAGE-Nachricht 842 an den PoC-Steuerserverrechner 802, mittels welcher die PoC-Client-Einheit 801 spezifiziert, dass eine PoC-Kommunikation mit den teilzunehmenden PoC-Client-Einheiten (die die abgeänderten Kriterien erfüllen) aufgebaut werden soll (accept=yes).
Mittels einer PK_start-Nachricht 843 signalisiert der Session-Controller 807 in Schritt 822 dem Media Mixer 808, dass eine neue PoC-Kommunikation innerhalb der bestehenden PoC-Session erzeugt wurde. Die PK_start-Nachricht 843 enthält die PoC-Kommunikationsidentifikation PK_id der erzeugten PoC-Kommunikation und die aktuelle Liste von Gruppen-Mitgliedern.
In Schritt 823 bestätigt der Media Mixer 808 den Empfang der PK_start Nachricht 843 mittels einer OK-Nachricht 844. In Schritt 824 sendet der PoC-Steuerserverrechner 802 als Antwort auf die re-INVITE-Nachricht 835 eine 200 OK-Nachricht 845.
In Schritt 825 sendet die PoC-Client-Einheit 801 eine Floor-Request-Nachricht 846 an den PoC-Steuerserverrechner 802, wodurch sie das Sprachrecht, d. h. das Recht zum Versand von Kommunikationsdaten, im Rahmen der erzeugten PoC-Kommunikation anfordert. Die Floor-Request-Nachricht 846 enthält die PoC-Kommunikations-Identifikation PK_id der erzeugten PoC-Kommunikation.
In Schritt 826 wird entschieden, ob der PoC-Client-Einheit 801 das Sprachrecht erteilt wird, dies kann von dem Session. Controller 807 oder dem Media Mixer 808 entschieden werden, deshalb werden gegebenenfalls Nachrichten zwischen dem Session Controller 807 und dem Media Mixer 808 ausgetauscht oder die Floor-Request-Nachricht 846 wird direkt an den Media Mixer 808 gesendet. Es wird angenommen, dass der PoC-Client-Einheit 801 das Sprachrecht erteilt wird. Dementsprechend sendet in Schritt 827 der Media Mixer 808 bzw. in Schritt 828 der Session Controller 807, je nachdem, welche funktionale Einheit des PoC-Steuerserverrechners 802 das Sprachrecht vergibt, eine Floor-Granted-Nachricht 848 an die PoC-Client-Einheit 801, mittels welcher der PoC-Client-Einheit 801 das Sprachrecht erteilt wird.
In Schritt 829 wird von dem Session Controller 807 bzw. in Schritt 830 von dem Media Mixer 808 (je nachdem, welche funktionale Einheit des PoC-Steuerserverrechners 802 das Sprachrecht erteilt) eine Floor-Taken-Nachricht 849 an alle teilzunehmenden PoC-Client-Einheiten gesendet, mittels welcher den teilzunehmenden PoC-Client-Einheiten, d. h. den PoC-Client-Einheiten der weiteren PoC-Client-Einheiten 806, die mittels der aktuellen Liste von Gruppen-Mitgliedern spezifiziert sind, signalisiert wird, dass das Sprachrecht im Rahmen der PoC-Kommunikation, die durch die in der Floor-Taken-Nachricht 849 enthaltenen PoC-Kommunikations-Identifikation PK_id spezifiziert wird, an die PoC-Client-Einheit 801 vergeben wurde.
In Schritt 831 sendet nun die PoC-Client-Einheit 801 Kommunikationsdaten 850 im Rahmen der erzeugten PoC-Kommunikation, die durch die PoC-Kommunikations-Identifikation PK_id spezifiziert wird, an den Media Mixer 808 zum Weiterleiten an teilzunehmenden PoC-Client-Einheit. In Schritt 832 leitet der Media Mixer 808 die Kommunikationsdaten 850 an die teilzunehmenden PoC-Client-Einheiten, über die er in Schritt 822 zuvor informiert worden ist, weiter.
Geht ein weiterer Auftrag in der Taxi-Zentrale ein, wird unabhängig von der erzeugten PoC-Kommunikation eine weitere PoC-Kommunikation mittels einer re-INVITE-Nachricht analog zu Schritt 812 gestartet. Auf diese Weise kann die Taxi-Zentrale zu jedem Auftrag eine eigenständige, von den anderen Aufträgen unabhängige PoC-Kommunikation innerhalb der einen bestehenden PoC-Session führen.
Durch Erzeugen von weiteren PoC-Kommunikationen im Rahmen der bestehenden PoC-Session können auch Sub-Gruppen-Kommunikationen parallel zu Gruppen-Kommunikationen bzw. innerhalb von Gruppen-Kommunikation realisiert werden, an denen nur ein Teil der Mitglieder einer Gruppe teilnehmen, beispielsweise ”Whispering” oder ”Sidebars”.
9 zeigt ein Nachrichtenflussdiagramm 900 gemäß einem Ausführungsbeispiel der Erfindung.
Analog zu den mit Bezug auf 8 beschriebenen Nachrichtenfluss findet der in 9 dargestellte Nachrichtenfluss zwischen einer PoC-Client-Einheit 901 (einer Taxi-Zentrale), einem PoC-Steuerserverrechner 902, der einen Session-Controller 907 und einen Media Mixer 908 aufweist, einen GM-Serverrechner 903, einen Location-Serverrechner 904, einen Presence-Serverrechner 905 und weiteren PoC-Client-Einheiten 906 (von Taxi-Fahrern) statt.
Das im Folgenden beschriebene Ausführungsbeispiel ist eine Variante des mit Bezug auf 8 beschriebenen Ausführungsbeispiels.
Die Schritte 909, 910 und 911 verlaufen analog zu den Schritten 809, 810 und 811.
In Schritt 912 sendet die PoC-Client-Einheit 901 statt einer re-INVITE-Nachricht 835 wie in Schritt 812 eine Floor-Request-Nachricht 934 an den PoC-Steuerserverrechner 902.
In den Schritten 913 und 914, 916 und 917 werden in dem Fall, dass der Media Mixer 908 die Sprachrechtvergabe regelt, Nachrichten zwischen dem Session Controller 907 und dem Media Mixer 908 ausgetauscht.
Die Schritte 915, 918 bis 927 werden analog zu den Nachrichten 813 bis 823 durchgeführt (in Schritt 918 wird allerdings eine OK-Nachricht übermittelt, nicht wie in Schritt 814 eine 183-session-processing-Nachricht). In diesem Ausführungsbeispiel wird die 200 OK-Nachricht 845 nicht gesendet, welches ja die Antwort auf die re-INVITE-Nachricht 835 ist, welche gemäß dem in 9 dargestellten Nachrichtenfluss nicht gesendet wird. Ferner wird die Floor-Request-Nachricht 846 nicht gesendet, da bereits in Schritt 912 die Floor-Request-Nachricht 934 gesendet wurde. Analog entfällt der Schritt 826. Analog zu den Schritten 827 und 828 wird in den Schritten 929 und 928 eine Floor-Granted-Nachricht 935 an die PoC-Client-Einheit 901 gesendet, welche die Antwort auf die Floor-Request-Nachricht 934 ist. Die weiteren Schritte 930–933 verlaufen analog zu den Schritten 829–832.
Analog zu den mit Bezug auf 6 und 7 beschriebenen Abläufen können auch in den Ausführungsformen gemäß 8 und 9 Gruppen-Mitglieder zu einer Gruppe hinzukommen oder eine Gruppe verlassen. Dies kann ähnlich wie mit Bezug auf 6 und 7 durchgeführt werden und wird nicht genauer erläutert.
10 zeigt ein Nachrichtenflussdiagramm 1000 gemäß einem Ausführungsbeispiel der Erfindung.
Der dargestellte Nachrichtenfluss findet zwischen einer PoC-Client-Einheit 1001, einem PoC-Steuerserverrechner 1002, einem GM-Serverrechner 1003, einem Location-Serverrechner 1004, einem Presence-Serverrechner 1005 sowie weiteren PoC-Client-Einheiten 1006 statt, die wie mit Bezug auf 3 erläutert angeordnet und ausgestaltet sind, wobei die zweite PoC-Client-Einheit 302 und die dritte PoC-Client-Einheit 303 dem weiteren PoC-Client-Einheit 1006 entsprechen.
Bei dem im Folgenden erläuterten Ausführungsbeispiel wird angenommen, dass der Benutzer der PoC-Client-Einheit 1001 mit

Dazu legt der Benutzer der PoC-Client-Einheit 1001 durch Senden einer group_generation_request-Nachricht 1023 in Schritt 1007 eine PoC-Gruppe in dem GM-Serverrechner 1003 an. Zur Definition der PoC-Gruppe übermittelt der Benutzer eine in der group_generation_request-Nachricht 1023 enthaltene Auflistung (member_list) von zwanzig unterschiedlichen Benutzern (die Freunde des Benutzers, dies sind die potentiellen Gruppen-Mitglieder) und ein in der group_generation_request-Nachricht 1023 spezifiziertes erstes Kriterium (criteria_1), dass sich die Freunde zum Zeitpunkt der Benutzung der PoC-Gruppe in der Stadt Hamburg aufhalten sollen.
Das Senden der group_generation_request-Nachricht 1023 kann beispielsweise mittels eines HTTP get-Befehls realisiert werden, der gemäß Tabelle 1 ausgestaltet ist.
Tabelle 1
HTTP get-Befehle sind in [3] beschrieben (Group Management Operationen unter Verwendung von HTTP sind in [2] beschrieben).
In Tabelle 1 und in den weiteren Tabellen sind die Einträge, die gemäß den Ausführungsbeispielen gegenüber den herkömmlichen Nachrichten zusätzlich vorgesehen sind, fett dargestellt.
In Schritt 1008 sendet der GM-Serverrechner 1003 als Antwort eine group_generation_response-Nachricht 1024, welche eine eindeutige Gruppenidentifikation der PoC-Gruppe enthält, in diesem Fall die Identifikation sip:[email protected], an die PoC-Client-Einheit 1001.
In Schritt 1009 wählt der Benutzer der PoC-Client-Einheit 1001 die PoC-Gruppe aus und legt das zweite Kriterium (criteria_2) fest (das erste Kriterium und das zweite Kriterium können jeweils auch aus mehreren Kriterien bestehen), um mit den potentiellen Gruppen-Mitgliedern der PoC-Gruppe, welche das erste Kriterium und das zweite Kriterium erfüllen, mit Hilfe der PoC-Client-Einheit 1001 eine PoC-Session zu starten. Durch das erste Kriterium und das zweite Kriterium wird die PoC-Gruppe dynamisch beschrieben, da es sich im Laufe der Zeit ändern kann, ob die potentiellen Gruppen-Mitglieder, d. h. die Benutzer, die in der group_generation_request-Nachricht 1023 enthaltenen Liste von Benutzern aufgeführt sind, das erste Kriterium und das zweite Kriterium erfüllen.
Der Benutzer der PoC-Client-Einheit 1001 möchte, dass während der zu startenden PoC-Session die aktuelle Zusammensetzung der PoC-Gruppe berücksichtigt wird. Die PoC-Gruppe setzt sich zu einem Zeitpunkt aktuell aus den potentiellen Gruppen-Mitgliedern zusammen, die das erste Kriterium und das zweite Kriterium erfüllen. Insbesondere sollen im Laufe der PoC-Session potentielle Gruppen-Mitglieder, die bisher nicht an der PoC-Session teilnehmen, zu der PoC-Session eingeladen werden, wenn sie das erste Kriterium und das zweite Kriterium (im Gegensatz zu vorher) erfüllen. Um dies zu erreichen, setzt der Benutzer der PoC-Client-Einheit 1001 das Automatisches-Update-Flag (automatic_update_flag).
In Schritt 1010 sendet der Benutzer zum Starten der PoC-Session eine INVITE-Nachricht 1025 an den PoC-Steuerserverrechner 1002. Die INVITE-Nachricht 1025 ist gemäß einem SIP INVITE ausgestaltet. SIP INVITE wird in [4] beschrieben. Die INVITE-Nachricht 1025 enthält eine Spezifikation des zweiten Kriteriums (criteria_2) sowie die Spezifikation, dass das Automatisches-Update-Flag gesetzt ist. Dies erfolgt beispielsweise mittels eines gegenüber dem Stand der Technik neu definierten Content-Type. Die INVITE-Nachricht 1025 ist beispielsweise gemäß Tabelle 2 ausgestaltet.
Tabelle 2
In Schritt 1011 stellt der PoC-Steuerserverrechner 1002 nach Erhalt der INVITE-Nachricht 1025 fest, dass er die Teilnehmerliste zu dieser PoC-Gruppe auflösen muss, d. h., dass er bestimmen soll, aus welchen Gruppen-Mitgliedern sich die PoC-Gruppe aktuell zusammensetzt.
Dementsprechend fragt der PoC-Steuerserverrechner 1002 durch Übermitteln einer Gruppen-Auflösungsanfrage-Nachricht (Group resolve request) 1026 in Schritt 1012 bei dem GM-Serverrechner 1003 an, um die Teilnehmerliste der Gruppe aufzulösen, d. h., die Gruppen-Mitglieder aus denen sich die PoC-Gruppe aktuell zusammensetzt, zu ermitteln. Die Gruppen-Auflösungsanfrage-Nachricht 1026 enthält die eindeutige Gruppenidentifikation der PoC-Gruppe, in diesem Fall die Identifikation sip:[email protected].
Der GM-Serverrechner 1003 antwortet dem PoC-Steuerserverrechner 1002 auf die Gruppen-Auflösungsanfrage-Nachricht 1026 hin mit den zu der Gruppe gehörenden Parametern, die in der group_generation_request-Nachricht 1023 festgelegt wurden (Liste von potentiellen Gruppen-Mitgliedern und/oder Kriterien 1, maximale Anzahl von Mitgliedern in der Gruppe (optional), sonstige service-spezifische Parameter (optional)) in einer Gruppen-Auflösungsantwort-Nachricht 1027 (Schritt 1013).
Der PoC-Steuerserverrechner 1002 ermittelt in einem nachfolgenden Schritt 1014 alle Teilnehmer, die auf der Liste der potentiellen Gruppen-Mitglieder stehen (falls vorhanden) und Kriterien_1 erfüllen (falls vorhanden) und Kriterien_2 erfüllen (falls vorhanden); diese Teilnehmer bilden somit die momentane Mitglieder-Liste (wie der PoC-Steuerserverrechner 1002 diese Teilnehmer ermittelt, hängt von den Kriterien ab; siehe oben beschriebene Anwendungsbeispiele)
Da der PoC-Steuerserverrechner 1002 zum Ermitteln der momentanen Gruppen-Mitglieder sowohl den Aufenthaltsort (Location-Status) der potentiellen Gruppen-Miglieder (bzw. der von den potentiellen Gruppen-Mitgliedern verwendeten PoC-Client-Einheiten) benötigt, sendet der PoC-Steuerserverrechner 1002 in Schritt 1015 eine erste SUBSCRIBE-Nachricht 1028 (gemäß SIP SUSCRIBE) an den Location-Serverrechner 1004 um sich bei dem Location-Serverrechner 1004 zu subskribieren und über den jeweiligen Location-Status der potentiellen Gruppen-Mitglieder informiert zu werden.
Ferner benötigt der PoC-Steuerserverrechner 1002 zum Ermitteln der momentanen Gruppen-Mitglieder die Information, ob die potentiellen Gruppen-Mitglieder momentan arbeiten. Diese Information sei für jedes potentielle Gruppen-Mitglied in einer für dieses Gruppen-Mitglied von dem Presence-Serverrechner 1005 verwalteten Präsenz-Information (Presence-Status) enthalten. Dementsprechend sendet der PoC-Steuerserverrechner 1002 eine zweite SUBSCRIBE-Nachricht 1029 in Schritt 1016 an den Presence-Serverrechner 1005. Die erste SUBSCRIBE-Nachricht 1028 und die zweite SUBSCRIBE-Nachricht 1029 werden für jedes potentielle Gruppen-Mitglied übermittelt. In 10 ist dies exemplarisch für das erste Gruppen-Mitglied mit der Identifikation sip:[email protected], welche in der ersten SUBSCRIBE-Nachricht 1028 und der zweiten SUBSCRIBE-Nachricht 1029 enthalten ist, dargestellt.
Wie erwähnt besteht das erste Kriterium darin, dass sich die Freunde, d. h. die potentiellen Gruppen-Mitglieder in der Stadt Hamburg aufhalten sollen. Alternativ kann das erste Kriterium auch ein Location-Kriterium sein, das von dem Aufenthaltsort des Benutzers (bzw. der PoC-Client-Einheit 1001) abhängt. Das erste Kriterium könnte beispielsweise sein, dass nur potentielle Gruppen-Mitglieder, die sich (bzw. deren PoC-Client-Einheiten) in 5 km Umkreis der Position des Benutzers bzw. der PoC-Client-Einheit 1001) aufhalten, der Gruppe angehören. In diesem Fall benötigt der PoC-Steuerserverrechner 1002 zum Ermitteln der momentanen Gruppen-Mitglieder auch die Orts-Information des Benutzers der PoC-Client-Einheit 1001 und sendet dementsprechend die erste SUBSCRIBE-Nachricht 1028 nicht nur jeweils für alle potentiellen Gruppen-Mitglieder an den Location-Serverrechner 1004, sondern auch für den Benutzer der PoC-Client-Einheit 1001. Im Weiteren wird jedoch angenommen, dass das erste Kriterium ist, dass sich die Gruppen-Mitglieder in der Stadt Hamburg aufhalten sollen.
Die erste SUBSCRIBE-Nachricht 1028, die wie erwähnt jeweils für jedes potentielle Gruppen-Mitglied an den Location-Serverrechner 1004 übermittelt wird, wird von dem Location-Serverrechner 1004 in Schritt 1017 jeweils mit einer ersten NOTIFY-Nachricht 1030 beantwortet, die den Location-Status des jeweiligen Gruppen-Mitglieds enthält (beispielsweise location_status_01).
Analog wird in Schritt 1018 die zweite SUBSCRIBE-Nachricht 1029, die gegebenenfalls für jedes Gruppen-Mitglied an den Presence-Serverrechner 1005 gesendet wird, jeweils von dem Presence-Serverrechner 1005 durch Übermittlung einer zweiten NOTIFY-Nachricht 1031 an den PoC-Steuerserverrechner 1002 beantwortet. Die zweite NOTIFY-Nachricht 1031 enthält für das jeweilige potentielle Gruppen-Mitglied die Information, ob das jeweilige potentielle Gruppen-Mitglied momentan arbeitet (beispielsweise presence_status_01).
Gegebenenfalls unter Verwendung der in Schritt 1017 und Schritt 1018 an ihn übermittelnden Informationen, ermittelt der PoC-Steuerserverrechner 1002 in Schritt 1019 die momentanen Gruppen-Mitglieder, indem er für jedes potentielle Gruppen-Mitglied überprüft, ob das potentielle Gruppen-Mitglied das erste Kriterium und das zweite Kriterium erfüllt.
Damit ist der PoC-Steuerserverrechner 1002 darüber informiert, welche Benutzer momentane Gruppen-Mitglieder sind. Optional werden nun noch die Schritte 1020 und 1021 durchgeführt. In Schritt 1020 sendet der PoC-Steuerserverrechner 1002 die Liste der momentanen Gruppen-Mitglieder (current_member_list), in einer anderen Ausführungsform nur die Angabe der Anzahl der momentanen Gruppen-Mitglieder, mittels einer ersten MESSAGE-Nachricht 1032 an die PoC-Client-Einheit 1001. Die erste MESSAGE-Nachricht 1032 ist als SIP MESSAGE ausgestaltet. SIP MESSAGE ist in [6] beschrieben.
In Schritt 1021 antwortet die PoC-Client-Einheit 1001 mittels einer zweiten MESSAGE-Nachricht 1033, die ebenfalls gemäß SIP MESSAGE ausgestaltet ist und in diesem Beispiel spezifiziert, dass die PoC-Session mit den momentanen Gruppen-Mitgliedern tatsächlich gestartet werden soll.
In Schritt 1022 sendet der PoC-Steuerserverrechner 1002 eine zweite INVITE-Nachricht 1034 an alle momentanen Gruppen-Mitglieder, in diesem Beispiel an alle weiteren PoC-Client-Einheiten 1006. Die zweite INVITE-Nachricht 1034 ist als SIP INVITE ausgestaltet. Schritt 1022 veranschaulicht ein Einladen aller weiteren PoC-Client-Einheiten 1006 zu der aufzubauenden PoC-Session. Dies wird auf herkömmliche Art durchgeführt. Als Antwort senden die weiteren PoC-Client-Einheiten 1006 jeweils eine erste 200 OK-Nachricht 1035 (gemäß SIP 200 OK) an den PoC-Steuerserverrechner 1002 (Schritt 1036).
Durch Senden der ersten 200 OK-Nachricht 1035 akzeptiert eine jeweilige PoC-Client-Einheit der weiteren PoC-Client-Einheiten 1006 (bzw. der entsprechende Benutzer) die Einladung zu der aufzubauenden PoC-Session. Nachdem der PoC-Steuerserverrechner 1002 die erste 200 OK-Nachricht 1035 empfangen hat (d. h. sobald eines der momentanen Gruppen-Mitglieder die Einladung zu der PoC-Session akzeptiert hat) erzeugt der PoC-Steuerserverrechner 1002 eine zweite 200 OK-Nachricht 1037 und sendet diese an die PoC-Client-Einheit 1001, wobei die zweite 200 OK-Nachricht 1037 signalisiert, dass eines der momentanen Gruppen-Mitglieder die Einladung zu der PoC-Session akzeptiert hat.
Nun läuft die PoC-Session mit allen Freunden des Benutzers der PoC-Client-Einheit 1001, die das erste Kriterium und das zweite Kriterium erfüllen (und die Einladung zu der PoC-Session akzeptiert haben).
Falls in der ersten INVITE-Nachricht 1025 der automatic update flag gesetzt war, beobachtet der PoC-Steuerserverrechner 1002 nun weiterhin, ob ein bisheriges Gruppen-Mitglied die Kriterien nicht mehr bzw. ein neuer Teilnehmer zwischenzeitlich doch erfüllt, so dass ihm immer die aktuelle Zusammensetzung der Gruppe bekannt ist und, so dass er die Gruppen-Mitglieder entsprechend aus- bzw. einladen kann.
In einer anderen Ausführungsform ist der Kommunikationsdienst, in dessen Rahmen die Erfindung eingesetzt wird, das von 3GPP (3rd Generation Partnership Project) spezifizierte ”IMS Conferencing”. Dies ist ein Konferenz-Kommunikationsdienst, der auf der IMS(Internet Protocol based Multimedia Subsystem)-Architektur basiert. Die Funktionalität eines GM-Serverrechners wird in diesem Fall von einem Conference-Policy-Server abgedeckt. Ein Conference-Policy-Server verwaltet die Regeln und Stati, die im Rahmen einer Konferenz verwendet werden, mittels eines Conference-Policy-Dokuments.
Eine Conference-Client-Einheit sendet in dieser Ausführungsform Kriterien, gemäß welcher eine Gruppe von Konferenzteilnehmern dynamisch erzeugt werden soll, gemäß CPCP (Conference Policy Control Protocol) an den Conference-Policy-Server, welcher die Kriterien in einem entsprechenden Format in dem Conference-Policy-Dokument ablegt. In einer Ausführungsform hält der Conference-Policy-Server sowohl die Kriterien als auch die Liste der momentanen Gruppen-Mitglieder in dem Conference-Policy-Dokument fest. Zum erzeugen der Liste der momentanen Gruppen-Mitglieder erforderliche Informationen (beispielsweise wie oben Präsenz-Informationen und Orts-Informationen) ermittelt der Conference-Policy-Server analog zu den oben beschriebenen Ausführungsbeispielen.
In den oben erläuterten Ausführungsbeispielen wurde nur der Anwendungsfall (Use Case) behandelt, dass mögliche Teilnehmer (bzw. entsprechende Client-Einheiten) zu einem Kommunikationsdienst (beispielsweise einer PoC-Session) eingeladen werden, wenn (oder sobald) sie vorgebbare Kriterien erfüllen.
Die Erfindung ist jedoch auch einsetzbar, wenn mögliche Teilnehmer (bzw. entsprechende Client-Einheiten) nicht eingeladen werden, sondern sich selber aktiv einwählen müssen, d. h. selber ihre Teilnahme initiieren müssen. Ein Beispiel hierfür ist eine Chat-Session (oder PoC-Session), zu der sich Benutzer selbst einwählen müssen.
Beispielsweise möchte ein Benutzer sich mittels einer von ihm verwendete Client-Einheit bei einem PoC-Steuerserverrechner, der eine PoC-Session bereitstellt, einwählen, beispielsweise durch Senden einer Einwählnachricht gemäß SIP INVITE, um an der PoC-Session teilnehmen zu können. Analog zu den obigen Ausführungsbeispielen seien Kriterien festgelegt und der PoC-Steuerserverrechner überprüft, beispielsweise analog zu oben durch Nachfrage bei einem GM-Serverrechner, ob der Benutzer, der sich einwählen möchte, die festgelegten Kriterien erfüllt. Nur wenn der Benutzer (bzw. die von ihm verwendete Client-Einheit) die Kriterien erfüllt, wird das Einwählen akzeptiert und (beispielsweise gemäß SIP 200 OK) bestätigt und der Benutzer ist anschließend Teilnehmer der PoC-Session. Erfüllt der Benutzer die Kriterien nicht, wird die Einwählnachricht ablehnend beantwortet, beispielsweise mittels einer Ablehnungs-Nachricht gemäß SIP REJECT, die auch eine Angabe des Grundes für die Ablehnung enthalten kann, und der Benutzer wird nicht Teilnehmer der PoC-Session.
In diesem Dokument sind folgende Veröffentlichungen zitiert:

[1] 3GPP TS 22.250 V6.0.0 (2002-12), ”IP Multimedia Subsystem (IMS) group management”
[2] Push to Talk over Cellular (PoC); List Management and Do-not-Disturb; PoC Release 2.0
[3] RFC ”Hypertext Transfer Protocol -- HTTP/1.1”
[4] RF3261 ”SIP: Session Initiation Protocol”
[5] RFC3265 ”Session Initiation Protocol(SIP)-Specific Event Notification”
[6] RFC3428 ”Session Initiation Protocol (SIP) Extension for Instant Messaging”
[7] WO 00/16209
[8] WO 02/103570 A1
[9] US 2005/0233776 A1
[10] US 2005/0186970 A1

Bezugszeichenliste

100: Nachrichtenflussdiagramm
101–103: PoC-Client-Einheiten
104: GM-Serverrechner
105: PoC-Serverrechner
106–116: Ablaufschritte
120–128: Nachrichten
200: Nachrichtenflussdiagramm
201: GM-Client-Einheit
202: ServiceX-Client-Einheit
203: ServiceX-Server-Einheit
204: GM-Server-Einheit
205–215: Ablaufschritte
216–223: Nachrichten
300: Kommunikationssystem
301–303: PoC-Client-Einheiten
304: Schnittstelle
305: PoC-Teilnehmerserverrechner
306: PoC-Steuerserverrechner
307: Chair
308: GM(Group Management)-Serverrechner
309: Presence-Serverrechner
400: Nachrichtenflussdiagramm
401: PoC-Client-Einheit
402: PoC-Steuerserverrechner
403: GM-Serverrechner
404: Location-Serverrechner
405: Presence-Serverrechner
406: weitere PoC-Client-Einheiten
407–422: Ablaufschritte
423–436: Nachrichten
500: Nachrichtenflussdiagramm
501: PoC-Client-Einheit
502: PoC-Steuerserverrechner
503: GM-Serverrechner
504: Location-Serverrechner
505: Presence-Serverrechner
506: weitere PoC-Client-Einheiten
507–522: Ablaufschritte
524–537: Nachrichten
601: PoC-Client-Einheit
602: PoC-Steuerserverrechner
603: GM-Serverrechner
604: Location-Serverrechner
605: weitere PoC-Client-Einheiten
606: neu hinzukommende PoC-Client-Einheit
607–613: Ablaufschritte
614–619: Nachrichten
701: PoC-Client-Einheit
702: PoC-Steuerserverrechner
703: GM-Serverrechner
704: Location-Serverrechner
705: weitere PoC-Client-Einheiten
706: verlassende PoC-Client-Einheit
707–713: Ablaufschritte
714–719: Nachrichten
801: PoC-Client-Einheit
802: PoC-Steuerserverrechner
803: GM-Serverrechner
804: Location-Serverrechner
805: Presence-Serverrechner
806: weitere PoC-Client-Einheiten
807: Session Controller
808: Media Mixer
809–832: Ablaufschritte
833–850: Nachrichten
901: PoC-Client-Einheit
902: PoC-Steuerserverrechner
903: GM-Serverrechner
904: Location-Serverrechner
905: Presence-Serverrechner
906: weitere PoC-Client-Einheiten
907: Session Controller
908: Media Mixer
909–933: Ablaufschritte
934–950: Nachrichten
1000: Nachrichtenflussdiagramm
1001: PoC-Client-Einheit
1002: PoC-Steuerserverrechner
1003: GM-Serverrechner
1004: Location-Serverrechner
1005: Presence-Serverrechner
1006: weitere PoC-Client-Einheiten
1007–1022: Ablaufschritte
1023–1035: Nachrichten
1036: Ablaufschritt
1037: Nachricht

Claims

Kommunikationssystem mit einer Kommunikationsdienst-Client-Einheit, weiteren Kommunikationsdienst-Client-Einheiten, einer Kommunikationsdienst-Server-Einheit und einer Server-Einheit, wobei – die Kommunikationsdienst-Client-Einheit eingerichtet ist, eine oder mehrere Nachrichten zu erzeugen, welche mindestens ein Kriterium enthalten, das von den weiteren Kommunikationsdienst-Client-Einheiten jeweils erfüllt wird oder nicht erfüllt wird und die Anforderung nach der Bereitstellung des Kommunikationsdiensts und eine Spezifikation enthalten, dass die weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, Teilnehmer des bereitgestellten Kommunikationsdiensts sein sollen; – die Server-Einheit eingerichtet ist, eine Liste der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, zu erzeugen und an die Kommunikationsdienst-Server-Einheit zu übermitteln; – die Kommunikationsdienst-Server-Einheit eingerichtet ist, den Kommunikationsdienst mit der Kommunikationsdienst-Client-Einheit und den weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, als Teilnehmern bereitzustellen; – die Server-Einheit eingerichtet ist, im Laufe der Bereitstellung des Kommunikationsdiensts die Liste der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, auf Gültigkeit zu überprüfen und gegebenenfalls zu aktualisieren und die aktualisierte Liste an die Kommunikationsdienst-Server-Einheit zu übermitteln; und – die Kommunikationsdienst-Server-Einheit eingerichtet ist, gemäß der aktualisierten Liste die Teilnehmer des Kommunikationsdiensts zu verändern.
Kommunikationssystem mit einer Kommunikationsdienst-Client-Einheit, weiteren Kommunikationsdienst-Client-Einheiten, einer Kommunikationsdienst-Server-Einheit und einer Server-Einheit, wobei – die Kommunikationsdienst-Client-Einheit eingerichtet ist, eine oder mehrere Nachrichten zu erzeugen, welche mindestens ein Kriterium enthalten, das von den weiteren Kommunikationsdienst-Client-Einheiten jeweils erfüllt wird oder nicht erfüllt wird und die Anforderung nach der Bereitstellung des Kommunikationsdiensts und eine Spezifikation enthalten, dass die weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, Teilnehmer des bereitgestellten Kommunikationsdiensts sein sollen; – die Server-Einheit eingerichtet ist, eine das mindestens eine Kriterium repräsentierende Information an die Kommunikationsdienst-Server-Einheit zu übermitteln; – die Kommunikationsdienst-Server-Einheit eingerichtet ist, den Kommunikationsdienst mit der Kommunikationsdienst-Client-Einheit und den weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, als Teilnehmern bereitzustellen; und – die Kommunikationsdienst-Server-Einheit eingerichtet ist, im Laufe der Bereitstellung des Kommunikationsdiensts die weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, auf Gültigkeit zu überprüfen und gegebenenfalls die Teilnehmer des Kommunikationsdiensts zu verändern.
Kommunikationssystem gemäß Anspruch 1 oder 2, wobei die das mindestens eine Kriterium repräsentierende Information das mindestens eine Kriterium ist.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 3, wobei die Kommunikationsdienst-Client-Einheit eingerichtet ist, eine oder mehrere Nachrichten mit dem mindestens einen Kriterium an die Server-Einheit zu senden.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 4, wobei die Server-Einheit eingerichtet ist zum Speichern des mindestens einen Kriteriums.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 5, wobei die Server-Einheit als eine Group Management-Server-Einheit eingerichtet ist.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 6, wobei die Anforderung in einer ersten Nachricht der einen oder mehreren Nachrichten enthalten ist und von der Kommunikationsdienst-Client-Einheit an die Kommunikationsdienst-Server-Einheit übermittelt wird.
Kommunikationssystem gemäß Anspruch 7, wobei das Kriterium in einer zweiten Nachricht der mehreren Nachrichten enthalten ist und von der Kommunikationsdienst-Client-Einheit an die Server-Einheit übermittelt wird.
Kommunikationssystem gemäß Anspruch 7, wobei das Kriterium in der ersten Nachricht der einen oder mehreren Nachrichten enthalten ist.
Kommunikationssystem gemäß Anspruch 1 oder gemäß den Ansprüchen 1 und (4 oder 5), wobei die Server-Einheit eingerichtet ist, zum Erzeugen der Liste der weiteren Kommunikationsdienst-Client-Einheiten an mindestens eine Informations-Server-Einheit eine dritte Nachricht zu übermitteln, welche die Anforderung nach Informationen enthält, die zum Überprüfen, ob die weiteren Kommunikationsdienst-Client-Einheiten das Kriterium erfüllen, erforderlich sind.
Kommunikationssystem gemäß Anspruch 2 oder gemäß den Ansprüchen 2 und (3 bis 5), wobei die Kommunikationsdienst-Server-Einheit eingerichtet ist, zum Erzeugen der Liste der weiteren Kommunikationsdienst-Client-Einheiten an mindestens eine Informations-Server-Einheit eine dritte Nachricht zu übermitteln, welche die Anforderung nach Informationen enthält, die zum Überprüfen, ob die weiteren Kommunikationsdienst-Client-Einheiten das Kriterium erfüllen, erforderlich sind.
Kommunikationssystem gemäß Anspruch 10 oder 11, wobei die Informations-Server-Einheit eine Presence-Server-Einheit oder eine Location-Server-Einheit ist.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 12, wobei die eine oder mehreren Nachrichten ferner eine weitere Liste eines Teils der weiteren Kommunikationsdienst-Client-Einheiten enthält, und eine der weiteren Kommunikationsdienst-Client-Einheiten nur dann Teilnehmer des bereitgestellten Kommunikationsdiensts sein soll, falls sie auf der weiteren Liste aufgeführt wird und das Kriterium erfüllt.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 13, wobei der Kommunikationsdienst ein Kommunikationsdienst ist, der auf SIP basiert.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 14, wobei in der einen oder mehreren Nachrichten das mindestens eine Kriterium gemäß XML spezifiziert wird.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 15, wobei der Kommunikationsdienst im Rahmen eines weiteren Kommunikationsdiensts bereitgestellt wird, der von der Kommunikationsdienst-Server-Einheit bereitgestellt wird.
Kommunikationssystem gemäß einem der Ansprüche 1 bis 16, wobei der Kommunikationsdienst ein PoC-Kommunikationsdienst, ein Kommunikationsdienst zum Versenden von Instant Messages, ein MMS-Kommunikationsdienst oder ein Konferenz-Kommunikationsdienst ist.
Verfahren zum Betreiben eines Kommunikationssystems, welches Kommunikationssystem eine Kommunikationsdienst-Client-Einheit, weitere Kommunikationsdienst-Client-Einheiten, eine Kommunikationsdienst-Server-Einheit und eine Server-Einheit aufweist, wobei gemäß dem Verfahren – die Kommunikationsdienst-Client-Einheit eine oder mehrere Nachrichten erzeugt, welche mindestens ein Kriterium enthalten, das von den weiteren Kommunikationsdienst-Client-Einheiten jeweils erfüllt wird oder nicht erfüllt wird und die Anforderung nach der Bereitstellung des Kommunikationsdiensts und eine Spezifikation enthalten, dass die weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, Teilnehmer des bereitgestellten Kommunikationsdiensts sein sollen; – die Server-Einheit eine Liste der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, erzeugt und an die Kommunikationsdienst-Server-Einheit übermittelt; – die Kommunikationsdienst-Server-Einheit den Kommunikationsdienst mit der Kommunikationsdienst-Client-Einheit und den weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, als Teilnehmern bereitstellt; – die Server-Einheit im Laufe der Bereitstellung des Kommunikationsdiensts die Liste der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, auf Gültigkeit überprüft und gegebenenfalls aktualisiert und die aktualisierte Liste an die Kommunikationsdienst-Server-Einheit übermittelt; und – die Kommunikationsdienst-Server-Einheit gemäß der aktualisierten Liste die Teilnehmer des Kommunikationsdiensts verändert.
Verfahren zum Betreiben eines Kommunikationssystems, welches Kommunikationssystem eine Kommunikationsdienst-Client-Einheit, weitere Kommunikationsdienst-Client-Einheiten, eine Kommunikationsdienst-Server-Einheit und eine Server-Einheit aufweist, wobei gemäß dem Verfahren – die Kommunikationsdienst-Client-Einheit eine oder mehrere Nachrichten erzeugt, welche mindestens ein Kriterium enthalten, das von den weiteren Kommunikationsdienst-Client-Einheiten jeweils erfüllt wird oder nicht erfüllt wird und die Anforderung nach der Bereitstellung des Kommunikationsdiensts und eine Spezifikation enthalten, dass die weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, Teilnehmer des bereitgestellten Kommunikationsdiensts sein sollen; – die Server-Einheit eine das mindestens eine Kriterium repräsentierende Information an die Kommunikationsdienst-Server-Einheit übermittelt; – die Kommunikationsdienst-Server-Einheit, den Kommunikationsdienst mit der Kommunikationsdienst-Client-Einheit und den weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, als Teilnehmern bereitstellt; und – die Kommunikationsdienst-Server-Einheit im Laufe der Bereitstellung des Kommunikationsdiensts die weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, auf Gültigkeit überprüft und gegebenenfalls die Teilnehmer des Kommunikationsdiensts verändert.
Server-Einheit eines Kommunikationssystems, welches Kommunikationssystem Kommunikationsdienst-Client-Einheiten und eine Kommunikationsdienst-Server-Einheit aufweist, wobei die Server-Einheit eingerichtet ist – eine Nachricht, welche mindestens ein Kriterium enthält, das von den Kommunikationsdienst-Client-Einheiten jeweils erfüllt wird oder nicht erfüllt wird, zu empfangen; und – eine Liste der Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, zu erzeugen und an die Kommunikationsdienst-Server-Einheit zu übermitteln; und – im Laufe der Bereitstellung des Kommunikationsdiensts die Liste der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, auf Gültigkeit zu überprüfen und gegebenenfalls zu aktualisieren und die aktualisierte Liste an die Kommunikationsdienst-Server-Einheit zu übermitteln.
Verfahren zum Betreiben einer Server-Einheit eines Kommunikationssystems, welches Kommunikationssystem Kommunikationsdienst-Client-Einheiten und eine Kommunikationsdienst-Server-Einheit aufweist, wobei gemäß dem Verfahren die Server-Einheit – eine Nachricht, welche mindestens ein Kriterium enthält, das von den Kommunikationsdienst-Client-Einheiten jeweils erfüllt wird oder nicht erfüllt wird, empfängt; und – eine Liste der Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, erzeugt und an die Kommunikationsdienst-Server-Einheit übermittelt; und – im Laufe der Bereitstellung des Kommunikationsdiensts die Liste der weiteren Kommunikationsdienst-Client-Einheiten, die das Kriterium erfüllen, auf Gültigkeit überprüft und gegebenenfalls aktualisiert und die aktualisierte Liste an die Kommunikationsdienst-Server-Einheit übermittelt.