DE102005049074B4

DE102005049074B4 - Verfahren zum rechnergestützten Vergeben eines Kommunikationsrechts, Verfahren zum rechnergestützten Erzeugen einer Kommunikationsrecht-Anforderungsnachricht, Kommunikationsrecht-Vergabe-Einheit, Kommunikations-Konferenz-Servereinheit, Kommunikations-Konferenz-Nachricht-Erzeugungseinheit, Kommunikations-Endgerät und Verfahren zum rechnergestützten Initialisieren eines Konferenz-Nachrichtenflusses in einer Kommunikations-Konferenz

Info

Publication number: DE102005049074B4
Application number: DE102005049074A
Authority: DE
Inventors: Andreas Schmidt; Achim Luft; Holger Schmidt
Original assignee: Infineon Technologies AG
Current assignee: Intel Deutschland GmbH
Priority date: 2005-10-13
Filing date: 2005-10-13
Publication date: 2008-04-03
Anticipated expiration: 2025-10-14
Also published as: US20070124377A1; DE102005049074A1

Abstract

Verfahren zum rechnergestützten Vergeben eines Kommunikationsrechts in einer Kommunikations-Konferenz zwischen mehreren Kommunikations-Endgeräten an mindestens ein Kommunikations-Endgerät,
• wobei die Kommunikations-Konferenz mindestens einen anhand eines vorangegangenen Kommunikations-Beitrags eindeutig identifizierbaren Konferenz-Nachrichtenfluss aufweist,
• wobei das Kommunikationsrecht innerhalb der Kommunikations-Konferenz vergeben wird unter Berücksichtigung des Konferenz-Nachrichtenflusses.

Description

Die Erfindung betrifft ein Verfahren zum rechnergestützten Vergeben eines Kommunikationsrechts, ein Verfahren zum rechnergestützten Erzeugen einer Kommunikationsrecht-Anforderungsnachricht, eine Kommunikationsrecht-Vergabe-Einheit, eine Kommunikations-Konferenz-Servereinheit, eine Kommunikations-Konferenz-Nachricht-Erzeugungseinheit, ein Kommunikations-Endgerät sowie ein Verfahren zum rechnergestützten Initialisieren eines Konferenz-Nachrichtenflusses in einer Kommunikations-Konferenz.
Mittels eines Kommunikations-Konferenz-Systems wird es ermöglicht, mit Hilfe von Kommunikations-Endgeräten zwischen mehreren Nutzern zu kommunizieren.
Um eine geordnete Kommunikation zu ermöglichen, bekommen üblicherweise nicht alle Teilnehmer einer Konferenz beziehungsweise einer Kommunikationssitzung gleichzeitig das Recht, über ein bestimmtes Medium, wie beispielsweise Audio, Video, etc., zu kommunizieren. Das Recht zur Kommunikation wird im Folgenden auch als Kommunikationsrecht bezeichnet. Das Kommunikationsrecht wird üblicherweise nach vorgegebenen Regeln vergeben. Die Kommunikationsrechtvergabe wird häufig auch als "Floor Control" bezeichnet und die Regeln, welche befolgt werden im Rahmen der Kommunikationsrechtsvergabe, werden häufig auch als „Floor Policy" bezeichnet.
Es ist beispielsweise in großen Konferenzräumen oftmals üblich, ein Konferenzsystem einzusetzen, bei welchem den Teilnehmern mehrere Mikrophone und Lautsprecher zur sprachlichen Kommunikation zur Verfügung gestellt werden. Die Mikrophone müssen vom jeweiligen Sprecher zur Benutzung eingeschaltet werden. Ein eingeschaltetes Mikrophon sperrt alle anderen Mikrophone, so dass immer nur ein Sprecher aktiv sein kann, das heißt anders ausgedrückt, das Sprechrecht hat. Ausnahmsweise kann auch noch ein weiteres Mikrophon, beispielsweise das des Konferenzleiters, gleichzeitig aktiv sein. Das Sprechrecht wird also üblicherweise nur einem Teilnehmer und gegebenenfalls einem oder mehreren weiteren Teilnehmern, beispielsweise dem Konferenzleiter, zugeordnet.
Im Bereich der Mobilfunk-Kommunikation sind vergleichbare Kommunikationsdienste zum Bereitstellen von einer Konferenz zwischen mehreren Kommunikations-Endgeräten bekannt, beispielsweise sind in diesem Bereich so genannte Halb-Duplex-Konferenzsysteme bzw. in einem solchen Rahmen erbrachte Kommunikationsdienste bekannt, beispielsweise ein so genannter Push-to-Talk-Kommunikationsdienst (PTT), beispielsweise der Kommunikationsdienst „Direct Connect" von der Firma Nextel oder der Kommunikationsdienst Push-to-Talk over Cellular (PoC) von dem Standardisierungs-Gremium Open Mobile Alliance (OMA). Wie bei einem Walkie-Talkie muss der Sprecher in diesem Fall üblicherweise eine spezielle Taste an seinem Mobilfunk-Kommunikations-Endgerät betätigen, um Nachrichten übermitteln zu können. Die Übertragung von Nachrichten anderer Nutzer ist während dieser Zeit gesperrt.
Weiterhin ist ein anderes Konferenzsystem von dem Standardisierungs-Gremium IETF (Internet Engineering Task Force) bekannt, wobei gemäß diesem in [1] beschriebenen Conferencing Framework Kommunikationsrechte mittels eines speziellen Kommunikationsprotokolls, beispielsweise dem Binary Floor Control Protocol (BFCP), kontrolliert werden.
In heutigen Push-to-Talk Konferenzsystemen werden Kommunikationsrechte häufig mittels des so genannten Real-Time Transport Control Protocols (RTCP) gesteuert, das heißt mittels dieses Protokolls werden Kommunikationsrechte angefordert und vergeben (vergleiche [2], [3]). Alternativ können in einigen dieser Konferenzsysteme auch die Kommunikationsrechte mittels des BFCP kontrolliert werden.
Die Teilnehmer einer Konferenz können über den Zustand der Konferenz durch so genannte Notifizierungs-Nachrichten benachrichtigt werden. So kann beispielsweise den Teilnehmern mitgeteilt werden, welcher Teilnehmer das Sprechrecht, allgemein das Kommunikationsrecht für ein bestimmtes Medium, anfordert. Notifizierungs-Nachrichten werden in einem IETF-Konferenz-System unter Verwendung des Kommunikationsprotokolls Session Initiation Protocol (SIP) mitgeteilt, wie in [4] beschrieben ist. In einem heutigen Push-to-Talk-Kommunikationssystem werden die Teilnehmer unter Verwendung des Kommunikationsprotokoll Real-Time-Transport-Control-Protocol (RTCP) darüber notifiziert, welcher Teilnehmer das Sprechrecht bekommt (vergleiche [2]).
Konferenz-Systeme gemäß der IETF und Push-to-Talk-Systeme haben üblicherweise eine zentralisierte Architektur, die beispielsweise in [5] und [6] beschrieben ist.
Dies bedeutet, dass die Teilnehmer in einer von einem solchen Konferenz-System bereitgestellten Konferenz nicht direkt miteinander kommunizieren, sondern mittels einer zentralen Server-Einheit. Die zentrale Server-Einheit befindet sich bei einem mobilen Konferenzsystem üblicherweise im nicht-mobilen Teil des Kommunikationsnetzes.
Nachteilig bei der Vergabe von Kommunikationsrechten ist bei den bekannten Kommunikations-Konferenzsystemen beispielsweise, dass dem Moderator, der das Kommunikationsrecht vergibt, bei Anforderung des Kommunikationsrechts nicht bekannt ist, auf welchen vorhergehenden Kommunikations-Beitrag sich der neue Kommunikations-Beitrag beziehen wird. Daher kann der Moderator das Kommunikationsrecht nicht entsprechend den Zusammenhängen der Kommunikationsbeiträge vergeben. Somit erfolgt die Kommunikation sowie die Kommunikationsrecht-Vergabe häufig unstrukturiert.
In [8] ist ein Kommunikationsendgerät beschrieben, das mehrere Schalter aufweist, denen jeweils eine Identifikation zugeordnet ist. Beispielsweise können mehrere Benutzer das Kommunikatiosendgerät nutzen, wobei jedem Benutzer einer der Schalter zugeordnet ist, den er verwenden kann, um das Kommunikationsrecht im Rahmen einer Konferenz anzufordern.
Der Erfindung liegt das Problem zugrunde, die Kommunikationsrecht-Vergabe in einer Kommunikations-Konferenz in strukturierterer Weise zu regeln, als dies gemäß dem Stand der Technik möglich ist.
Das Problem wird durch ein Verfahren zum rechnergestützten Vergeben eines Kommunikationsrechts, durch ein Verfahren zum rechnergestützten Erzeugen einer Kommunikationsrechts-Anforderungsnachricht, durch eine Kommunikationsrecht-Vergabe-Einheit, durch eine Kommunikations-Konferenz-Servereinheit, durch eine Kommunikationsrecht-Anforderungsnachricht-Erzeugungseinheit, durch ein Kommunikations-Endgerät sowie durch ein Verfahren zum rechnergestützten Initialisieren eines Konferenz-Nachrichtenflusses in einer Kommunikations-Konferenz mit den Merkmalen gemäß den unabhängigen Patentansprüchen gelöst.
Bei einem Verfahren zum rechnergestützten Vergeben eines Kommunikationsrechts in einer Kommunikations-Konferenz zwischen mehreren Kommunikations-Endgeräten an mindestens ein Kommunikations-Endgerät, wobei die Kommunikations-Konferenz mindestens einen anhand eines vorangegangenen Kommunikations- Beitrags eindeutig identifizierbaren Konferenz-Nachrichtenfluss aufweist, wird das Kommunikationsrecht innerhalb der Kommunikations-Konferenz vergeben unter Berücksichtigung des Konferenz-Nachrichtenflusses.
Bei einem Verfahren zum rechnergestützten Erzeugen einer Kommunikations-Konferenz-Nachricht in einer Kommunikations-Konferenz zwischen mehreren Kommunikations-Endgeräten wird der Kommunikations-Konferenz-Nachricht eine Identifikationsangabe eines Konferenz-Nachrichtenflusses innerhalb der Kommunikations-Konferenz hinzugefügt zur eindeutigen Identifizierung des Konferenz-Nachrichtenflusses anhand eines vorangegangenen Kommunikations-Beitrags.
Eine Kommunikationsrecht-Vergabe-Einheit zum Vergeben eines Kommunikationsrechts in einer Kommunikations-Konferenz zwischen mehreren Kommunikations-Endgeräten an mindestens ein Kommunikations-Endgerät, wobei die Kommunikations-Konferenz mindestens einen anhand eines vorangegangenen Kommunikations-Beitrags eindeutig identifizierbaren Konferenz-Nachrichtenfluss aufweist, ist derart eingerichtet, dass das Kommunikationsrecht innerhalb der Kommunikations-Konferenz vergeben wird unter Berücksichtigung des Konferenz-Nachrichtenflusses.
Weiterhin ist eine Kommunikations-Konferenz-Servereinheit mit einer Kommunikationsrecht-Vergabe-Einheit, wie oben beschrieben, vorgesehen.
Eine Kommunikations-Konferenz-Nachricht-Erzeugungseinheit, beispielsweise eine Kommunikationsrecht-Anforderungsnachricht-Erzeugungseinheit, ist eingerichtet zum rechnergestützten Erzeugen einer Kommunikations-Konferenz-Nachricht, beispielsweise zum Erzeugen einer Kommunikationsrecht-Anforderungsnachricht, in einer Kommunikations-Konferenz zwischen mehreren Kommunikations-Endgeräten, wobei der Kommunikations-Konferenz-Nachricht, beispielsweise der Kommunikationsrecht-Anforderungsnachricht, eine Identifikationsangabe eines Konferenz-Nachrichtenflusses innerhalb der Kommunikations-Konferenz hinzugefügt werden kann zur eindeutigen Identifizierung des Konferenz-Nachrichtenflusses anhand eines vorangegangenen Kommunikations-Beitrags.
Ferner ist ein Kommunikations-Endgerät vorgesehen mit einer oben beschriebenen Kommunikations-Konferenz-Nachricht-Erzeugungseinheit, beispielsweise einer Kommunikationsrecht-Anforderungsnachricht-Erzeugungseinheit.
Bei einem Verfahren zum rechnergestützten Initialisieren eines Konferenz-Nachrichtenflusses in einer Kommunikations-Konferenz zwischen mehreren Kommunikations-Endgeräten, wird ein Konferenz-Nachrichtenfluss erzeugt in der Kommunikations-Konferenz, wobei dem Konferenz-Nachrichtenfluss eine eindeutige Identifikationsangabe zugeordnet wird zur eindeutigen Identifikation des Nachrichtenflusses innerhalb der Kommunikations-Konferenz anhand eines vorangegangenen Kommunikations-Beitrags.
Ein Aspekt der Erfindung kann darin gesehen werden, in einem Kommunikationssystem, auch bezeichnet als Konferenz-System, mit mehreren Teilnehmern, Kommunikationsrechte bezogen auf einen vorangegangenen Kommunikations-Beitrag anzufordern und zu vergeben.
Es wird in diesem Zusammenhang ohne Einschränkung der Allgemeingültigkeit angenommen, dass jeder Kommunikations-Beitrag einen Kommunikationsfluss, im Folgenden auch bezeichnet als Konferenz-Nachrichtenfluss, initiiert. Zu einem Kommunikationsfluss eines Kommunikations-Beitrags gehören alle nachfolgende Beiträge, die sich auf den ursprünglichen Kommunikations-Beitrag beziehen. Jedem Kommunikationsfluss einer Kommunikationssitzung ist eine eigene Kommunikationsrecht-Kontrolle und eine dafür vorgesehene und eingerichtete Kommunikationsrechts-Kontrolleinheit zugeordnet. Die Kommunikationsrechts-Kontrolle eines Kommunikationsflusses wird beispielsweise durch den Teilnehmer moderiert, der den Kommunikationsfluss durch seinen Kommunikations-Beitrag initiiert hat. Wenn ein Teilnehmer das Kommunikationsrecht anfordert, so kann er mitteilen, auf welchen vorangegangenen Kommunikations-Beitrag sich sein Beitrag bezieht. Sein Beitrag wird dann dem Kommunikationsfluss zugeordnet, der durch den Bezugs-Beitrag initiiert wurde.
Ein Vorteil der Erfindung kann darin gesehen werden, dass der Ablauf einer Kommunikationssitzung entsprechend den Abhängigkeiten der Kommunikations-Beiträge und damit der Kommunikations-Nachrichtenflüsse geregelt wird. Zusammengehörige Beiträge hinsichtlich eines Kommunikations-Beitrags, welcher einen jeweiligen Kommunikationsfluss initiiert, werden beispielsweise zuerst abgearbeitet, bevor andere Beiträge gemacht werden können. Auf diese Weise ist eine automatisch strukturierte Kommunikationssitzung ermöglicht. Ferner ist ein Vorteil darin zu sehen, dass bei der Anforderung des Kommunikationsrechts angegeben wird, auf welchen vorangegangenen Kommunikations-Beitrag sich der neue Beitrag bezieht. Der Bezug kann den anderen Teilnehmern übermittelt werden beziehungsweise deren Kommunikations-Endgeräten, so dass sie den Beitrag noch vor Abhören des Beitrags thematisch zuordnen können, manuell oder auch automatisch.
Weiterhin kann bei Verwendung entsprechender Kommunikationsprotokolle durch Erweiterung bestehender Kommunikationsrechts-Kontrollmechanismen die Erfindung realisiert werden, so dass sie mit den bestehenden Mechanismen zusammenarbeitet, also „rückwärts-kompatibel" ist.
Beispielhafte Ausgestaltungen der Erfindung ergeben sich aus den abhängigen Ansprüchen.
Die Ausgestaltungen der Erfindung betreffen, soweit sinnvoll, alle oben beschriebenen Verfahren wie auch die Kommunikationsrecht-Vergabe-Einheit, die Kommunikations-Konferenz-Server-Einheit, die Kommunikationsrecht-Anforderungsnachricht-Erzeugungseinheit sowie das Kommunikations-Endgerät.
Der mindestens eine Konferenz-Nachrichtenfluss kann mindestens einen Beitrag aufweisen, der sich auf die Kommunikations-Konferenz oder auf einen anderen Beitrag in der Kommunikations-Konferenz bezieht.
Die Kommunikations-Konferenz kann mehrere eindeutig identifizierbare Konferenz-Nachrichtenflüsse aufweisen, welche beispielsweise jeweils auf einen eigenen Kommunikations-Beitrag zurückzuführen sind und diesem zugeordnet sind. Das Kommunikationsrecht kann innerhalb der Kommunikations-Konferenz vergeben werden unter Berücksichtigung mindestens eines Konferenz-Nachrichtenflusses der mehreren Konferenz-Nachrichtenflüsse.
Die Erfindung ist insbesondere vorteilhaft, wenn eine Vielzahl von Kommunikations-Beiträgen, welche einen jeweiligen Konferenz-Nachrichtfluss initiiert, vorgesehen sind, und im Rahmen der Kommunikations-Konferenz eine strukturiertere und geordnetere Abarbeitung der Kommunikationsrechtsanforderungen und damit einhergehend der gesamten Kommunikations-Konferenz gewünscht ist, da gemäß dieser Ausgestaltung der Erfindung unter Verwendung der jeweiligen Identifikationsangabe es ermöglicht wird, selbst unter einer Vielzahl unterschiedlicher Konferenz-Nachrichtenflüsse jeden Nachrichtenfluss, beziehungsweise den diesen initiierenden Kommunikations-Beitrag eindeutig zu identifizieren und jeden nachfolgenden Beitrag eindeutig darauf zu referenzieren.
Das Kommunikationsrecht kann vergeben werden unter Berücksichtigung einer Kommunikationsrecht-Anforderungsnachricht, wie sie oben beschrieben wurde, wobei die Kommunikationsrecht-Anforderungsnachricht die Identifikationsangabe des jeweiligen Konferenz-Nachrichtenflusses enthält, auf welchen sich die Kommunikationsrechts-Anforderungsnachricht bezieht.
Gemäß einer Ausgestaltung wird mindestens eine Kommunikationsrecht-Anforderungsnachricht empfangen, wobei auf den Empfang der Kommunikationsrecht-Anforderungsnachricht hin das jeweilige Kommunikationsrecht ebenfalls vergeben wird.
Gemäß einer anderen Ausgestaltung der Erfindung ist es vorgesehen, dass die mindestens eine Kommunikationsrecht-Anforderungsnachricht eine Identifikationsangabe enthält zum Identifizieren des Konferenz-Nachrichtenflusses, im Rahmen dessen ein Kommunikationsrecht angefordert wird.
Ferner kann als Kommunikations-Konferenz eine Kommunikationssitzungs-basierte Kommunikations-Konferenz verwendet werden, beispielsweise eine Internet-basierte Kommunikations-Konferenz oder eine Push-to-Talk-Kommunikations-Konferenz und dabei beispielsweise eine Push-to-Talk over Cellular-Kommunikations-Konferenz verwendet werden.
Gemäß einer anderen Ausgestaltung der Erfindung ist es vorgesehen, die Kommunikations-Konferenz-Nachricht, beispielsweise die Kommunikationsrechts-Anforderungsnachricht, gemäß einem Kommunikationsrecht-Vergabe-Protokoll zu codieren, beispielsweise gemäß dem Binary Floor Control Protocol (BFCP).
Ferner kann die Kommunikations-Konferenz-Nachricht, beispielsweise die Kommunikationsrecht-Anforderungsnachricht, gemäß einem Steuerungsprotokoll zum Steuern eines Mediendaten-Übertragungs-Protokolls codiert werden, beispielsweise gemäß einem Echtzeit-Steuerungsprotokoll zum Steuern eines Echtzeit-Mediendaten-Übertragungs-Protokolls, beispielsweise gemäß dem Real-Time Transport Control Protocol (RTCP)
Bei Verwendung dieser an sich bekannten Protokolle ist ein Vorteil der Erfindung darin zu sehen, dass durch eine sehr einfache und kostengünstige Erweiterung dieser an sich bekannten Protokolle der oben beschriebene erfindungsgemäße Mechanismus realisiert werden kann, womit eine solche Realisierung „rückwärts-kompatibel" zu derzeitigen Kommunikationsmechanismen und Kommunikations-Konferenz-Systemen ist.
Das Kommunikationsrecht innerhalb der Kommunikations-Konferenz kann von dem Initiator des Konferenz-Nachrichtenflusses vergeben werden, anders ausgedrückt von dem Teilnehmer der Kommunikations-Konferenz, welcher den Kommunikations-Beitrag geliefert hat, welcher den jeweiligen Konferenz-Nachrichtfluss initiiert hat.
Der Initiator ist beispielsweise der Teilnehmer, der den Beitrag gemacht hat, auf den sich die Beiträge des Konferenz-Nachrichtenflusses beziehen.
Alternativ oder zusätzlich kann das Kommunikationsrecht innerhalb der Kommunikations-Konferenz von einem Initiator eines dem Konferenz-Nachrichtfluss hierarchisch übergeordneten Konferenz-Nachrichtenflusses, anders ausgedrückt Kommunikationsflusses, vergeben werden.
Gemäß einer anderen Ausgestaltung der Erfindung ist es vorgesehen, dass der Initiator des Konferenz-Nachrichtenflusses oder der Initiator des dem Konferenz-Nachrichtenfluss übergeordneten Konferenz-Nachrichtenflusses das Recht hat, den jeweiligen Konferenz-Nachrichtenfluss auch zu beenden. In diesem Fall ist es beispielsweise vorgesehen, dass, wenn ein Kommunikationsfluss beendet wird, alle zugeordneten noch nicht genehmigten Kommunikations-Anforderungen abgelehnt werden und gegebenenfalls ein gerade aktuell stattfindender Beitrag beendet wird. Auf diese Weise wird sichergestellt, dass die Beiträge und die Nachrichtenflüsse jeweils nicht durch themenfremde Teilnehmer der Kommunikations-Konferenz moderiert und damit hinsichtlich der Kommunikationsrecht-Vergabe gesteuert werden.
Die Kommunikations-Konferenz-Nachricht kann eine der folgenden Nachrichten sein bzw. als eine der folgenden Nachrichten ausgebildet sein:

• eine Kommunikationsrecht-Anforderungsnachricht zum Anfordern eines Kommunikationsrechts;
• eine Nachrichtenfluss-Kommunikationsrecht-Genehmigungsnachricht, wobei mit der Nachrichtenfluss-Kommunikationsrecht-Genehmigungsnachricht angegeben wird, dass in dem Nachrichtenfluss das Kommunikationsrecht genehmigt wurde;
• eine Nachrichtenfluss-Beendigungsnachricht zum Beenden des Konferenz-Nachrichtenflusses;
• eine Nachrichtenfluss-Kommunikationsrecht-Entziehungsnachricht zum Entziehen des Kommunikationsrechts in dem Nachrichtenfluss;
• eine Kommunikations-Beitrag-Beendigungsnachricht zum Beenden des Kommunikations-Beitrags;
• eine Kommunikations-Beitrag-Freigegeben-Nachricht, wobei mit der Kommunikations-Beitrag-Freigegeben-Nachricht angegeben wird, dass das Kommunikationsrecht hinsichtlich des Kommunikations-Beitrags nicht vergeben ist;
• eine Kommunikations-Beitrag-Beendigungsnachricht zum Freigeben des Kommunikations-Beitrags;
• eine Kommunikationsrecht-Vergeben-Nachricht, wobei mit der Kommunikationsrecht-Vergeben-Nachricht angegeben wird, dass das Kommunikationsrecht vergeben wurde;
• eine Kommunikations-Beitrag-Kommunikationsrecht-Entziehungsnachricht zum Entziehen des Kommunikationsrechts in dem Kommunikations-Beitrag.

Beispielsweise die Nachrichtenfluss-Beendigungsnachricht und/oder die Nachrichtenfluss-Kommunikationsrecht- Entziehungsnachricht können/kann von dem Moderator des Konferenz-Nachrichtenflusses erzeugt werden.
Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Folgenden näher erläutert.
Es zeigen
1 ein Kommunikationssystem gemäß einem Ausführungsbeispiel der Erfindung mit vier Teilnehmern;
2 ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung;
3 ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung;
4 ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung;
5 ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung;
6 ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung; und
7 ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
Zunächst wird zur einfacheren Darstellung der Erfindung unter Bezugnahme auf 1 eine Ausführungsform der Erfindung dargestellt, bei der das Kommunikationssystem und die darin vorgesehenen Einheiten als Push-to-Talk over Cellular-Kommunikationssystem (PoC-Kommunikationssystem) 100 eingerichtet sind, wie in [6] beschrieben, wobei eine Erweiterung des in [6] beschriebenen Kommunikationssystems vorgesehen ist dahingehend, dass ein Moderator vorgesehen ist zum Moderieren einer oder mehrerer PoC-Kommunikationssitzung(en).
Eine erste PoC-Client-Einheit 101, eine zweite PoC-Client-Einheit 102, eine dritte PoC-Client-Einheit 103 und eine vierte PoC-Client-Einheit 108 sind mittels jeweils einer Schnittstelle I 104 mit jeweils einem PoC-Teilnehmerserverrechner (PoC-Server Participating Function) 105 gekoppelt. Die PoC-Teilnehmerserverrechner 105 sind mit einem PoC-Steuerserverrechner (PoC-Server controlling function) 106 gekoppelt.
Der PoC-Steuerserverrechner 106 ist mit einem Chair 107 gekoppelt. Der Chair 107 kann mittels einer PoC-Client-Einheit 101, 102, 103, 108 oder mittels eines Serverrechners des Kommunikationssystems 100 realisiert sein. Der Chair 107 ist anschaulich der Moderator einer jeweiligen PoC-Kommunikationssitzung. Beispielsweise kann der PoC-Steuerserverrechner 106 bei dem Chair 107 anfragen, an welche PoC-Client-Einheit 101, 102, 103, 108 das Sprechrecht, allgemein das Kommunikationsrecht, vergeben werden soll oder an welcher Stelle der PoC-Steuerserverrechner 106 eine PoC-Client-Einheit 101, 102, 103, 108 in eine Warteschlange einreihen soll. Der Chair 107 kann auch selbst eine Warteschlange führen und der PoC-Steuerserverrechner 106 kann bei dem Chair 107 Informationen über den Zustand der Warteschlange anfordern.
Die Schnittstellen I 104 werden beispielsweise mittels des RAN (Radio Access Network), des Kernnetzwerks (Core Network, CN) und des INS (Internet Protocol based Multimedia Subsystem). eines UMTS(Universal Mobile Telecommunications System)-Kommunikationssystems oder eines GSM(Global System for Mobile Communication)-Kommunikationssystems bereitgestellt.
Die Schnittstellen I 104 können aber auch beispielsweise mittels eines PSTN(Public Switched Telephone Network)-Kommunikationsnetzwerks bereitgestellt werden.
Die PoC-Client-Einheiten 101, 102, 103, 108 sind jeweils in einem Mobilfunk-Kommunikationsendgerät, das gemäß der jeweiligen Schnittstelle I 104 beispielsweise eingerichtet ist zur Kommunikation gemäß dem UMTS-Standard, dem GSM-Standard, dem GPRS(General Packet Radio Service)-Standard, dem CDMA2000-Standard, dem FOMA-Standard, oder einem anderen Mobilfunk-Kommunikationsstandard, integriert.
Im Weiteren wird eine Ausführungsform erläutert, bei der der Chair 107 die Entscheidung darüber fällt, welche PoC-Client-Einheit 101, 102, 103, 108 das Sprechrecht erhält.
Anschaulich leitet dabei der PoC-Steuerserverrechner 106 die bei ihm eingehenden Talk-Burst-Control-Signalisierungen an den Chair 107 weiter, der wiederum dem PoC-Steuerserverrechner 106 seine Entscheidung, welche Poc-Client-Einheit 101, 102, 103 das Sprechrecht bekommt und in welcher Reihenfolge die PoC-Client-Einheiten 101, 102, 103, 108 das Sprechrecht bekommen, mitteilt. Der PoC-Steuerserverrechner 106 sendet daraufhin entsprechende Signalisierungen an die beteiligten PoC-Client-Einheiten 101, 102, 103, 108.
Zunächst wird eine Ausführungsform erläutert, in welcher keine Warteschlange geführt wird.
2 zeigt ein Nachrichtenflussdiagramm 200 gemäß einem Ausführungsbeispiel der Erfindung.
Der in 2 dargestellte Nachrichtenfluss findet zwischen einer ersten PoC-Client-Einheit 101, 201, einem PoC-Steuerserverrechner 106, 202, einem Chair 107, 203 und einer zweiten PoC-Client-Einheit 102, 204 statt, die wie oben mit Bezug auf 1 erläutert angeordnet und ausgestaltet sind.
Die erste PoC-Client-Einheit 101, 201 sendet in Schritt 206 eine Talk Burst Request-Nachricht 220 an den PoC-Steuerserverrechner 106, 202, mit der sie das Sprechrecht anfordert. In Schritt 207 leitet der PoC-Steuerserverrechner 106, 202 diese Anforderung mittels einer Chair_Talk_Burst_Request-Nachricht 221, die beispielsweise gemäß Tabelle 1 ausgestaltet ist, an den Chair 107, 203 weiter.
Tabelle 1: Chair_Talk_Burst_Request
Da in diesem Fall der Sender der Chair_Talk_Burst_Request-Nachricht 221 der PoC-Steuerserverrechner 106, 202 ist, ist in diesem Fall in der Chair_Talk_Burst_Request-Nachricht 221 als Absenderidentifikation die SSRC des FoC-Steuerserverrechners 202 enthalten. Deshalb enthält die Chair_Talk_Burst_Request-Nachricht 221 zusätzlich ein Feld mit der Identifikation der ersten PoC-Client-Einheit 101, 201.
Die Chair_Talk_Burst_Request-Nachricht 221 enthält ferner die Priorität der ersten PoC-Client-Einheit 101, 201. Dies ist jedoch optional. Beispielsweise könnte die Chair_Talk_Burst_Request-Nachricht 221 nur dann die Priorität der ersten PoC-Client-Einheit 101, 201 enthalten, wenn diese zum ersten Mal im Rahmen der PoC-Kommunikationssitzung das Sprechrecht anfordert. Alternativ kann die Priorität der ersten PoC-Client-Einheit 101, 201 nur dann in der Chair-Talk-Burst-Request-Nachricht 221 enthalten sein, wenn sich die Priorität gegenüber der letzten Übermittlung der Priorität an den Chair 203 geändert hat.
Eine weitere Alternative, die vorzugsweise dann verwendet wird, wenn sich die Prioritäten der PoC-Client-Einheiten 101, 102, 103, 108 im Laufe einer PoC-Kommunikation nicht ändern, ist, zu Beginn der PoC-Kommunikationssitzung in Schritt 205 eine Chair_Priorities_Indication-Nachricht 230, die beispielsweise gemäß Tabelle 2 ausgestaltet ist (von dem PoC-Steuerserverrechner 106, 202) an den Chair 107, 203 zu übermitteln.
Tabelle 2: Chair_Priorities_Indication
Wie in Tabelle 2 dargestellt, enthält die Chair_Priorities_Indication-Nachricht 230 für jede PoC-Client-Einheit 201, 204 ein Feld mit einer Identifikation der PoC-Client-Einheit 201, 204 und der Priorität der jeweiligen PoC-Client-Einheit 201, 204.
In einer Ausführungsform wird eine Chair_Priorities_Indication-Nachricht 230 erneut übertragen, wenn sich die Priorität einer PoC-Client-Einheit 201, 204 geändert hat.
In dem in 2 nicht dargestellten Fall, dass eine PoC-Client-Einheit 201, 204 das Sprechrecht hat und die Abgabe des Sprechrechts dem PoC-Steuerserver 202 mittels der Übertragung einer Talk-Burst-Completed-Indication-Nachricht signalisiert, sendet der Steuerserver 202 eine Chair_Talk_Burst_Completed Indication-Nachricht, die beispielsweise gemäß Tabelle 3 ausgestaltet ist, an den Chair 107, 203.
Tabelle 3: Chair_Talk_Burst_Completed_Indication
In Schritt 208 teilt der Chair 107, 203 dem PoC-Steuerserverrechner 106, 202 das Ergebnis seiner Entscheidung, ob die erste PoC-Client-Einheit 101, 201 das Sprechrecht erhält, mit. Diese Entscheidung kann unter Berücksichtigung der Priorität der ersten PoC-Client-Einheit 101, 201 gefällt werden.
In diesem Beispiel wird angenommen, dass der Chair 107, 203 entscheidet, dass die erste PoC-Client-Einheit 201 das Sprechrecht erhält. Dementsprechend übermittelt der Chair 107, 203 eine Chair_Talk_Burst_Confirm_Response-Nachricht 222 in Schritt 208 an den PoC-Steuerserverrechner 106, 202. Die Chair_Talk_Burst_Confirm_Response-Nachricht 222 ist in diesem Beispiel gemäß Tabelle 4 ausgestaltet und enthält eine Identifikation der PoC-Client-Einheit 201, 204, der das Sprechrecht erteilt werden soll, in diesem Beispiel der ersten PoC-Client-Einheit 101, 201.
Tabelle 4: Chair_Talk_Burst_Confirm_Response
In dem Fall, dass der Chair 107, 203 entscheidet, dass der ersten PoC-Client-Einheit 101, 201 das Sprechrecht nicht erteilt wird, überträgt der Chair 107, 203 in Schritt 208 eine Chair_Talk_Burst_Reject_Response-Nachricht an den PoC-Steuerserverrechner 202, die beispielsweise gemäß Tabelle 5 ausgestaltet ist und eine Identifikation der PoC-Client-Einheit 201, 204 enthält, der das Sprechrecht verweigert wird, eine Spezifikation eines Grundes für die Verweigerung (Reason Code), die Länge einer Angabe eines Grundes (Length) sowie die Angabe eines Grundes (Reason Phrase).
Tabelle 5: Chair_Talk_Burst_Reject_Response
Da in diesem Beispiel angenommen wird, dass der ersten PoC-Client-Einheit 101, 201 das Sprechrecht erteilt wird, sendet der PoC-Steuerserverrechner 106, 202 entsprechend in Schritt 209 eine Talk Burst Confirm Response-Nachricht 223 an die erste PoC-Client-Einheit 101, 201.
Ferner übermittelt der PoC-Steuerserverrechner 106, 202 in Schritt 210 eine Receiving_Talk_Burst_Indication-Nachricht 224 an die zweite PoC-Client-Einheit 102, 204.
Weiterhin beginnt die erste PoC-Client-Einheit 101, 201 in Schritt 211 mit der Übermittlung von Sprachnachrichten an die zweite PoC-Client-Einheit 102, 204.
Nun wird angenommen, dass in Schritt 212 die zweite PoC-Client-Einheit 102, 204 mittels einer weiteren Talk-Burst-Request-Nachricht 225 das Sprechrecht im Rahmen der PoC-Kommunikation anfordert.
Analog zu Schritt 207 übermittelt der PoC-Steuerserverrechner 106, 202 eine weitere Chair_Talk_Burst_Request-Nachricht 231 an den Chair 107, 203 (Schritt 213).
In diesem Beispiel wird angenommen, dass die Priorität der zweiten PoC-Client-Einheit 102, 204 höher ist als die der ersten PoC-Client-Einheit 101, 201. Entsprechend entscheidet der Chair 107, 203, dass nun der zweiten PoC-Client-Einheit 102, 204 das Sprechrecht erteilt werden soll und teilt dies dem PoC-Steuerserverrechner 106, 202 mittels einer weiteren Chair_Talk_Burst_Confirm_Response-Nachricht 226 mit (Schritt 214).
In Schritt 215 teilt der PoC-Steuerserverrechner 106, 202 der ersten PoC-Client-Einheit 101, 201 mittels einer Stop Talk Burst Indication-Nachricht 227 (siehe Tabelle 6) mit, dass die erste PoC-Client-Einheit 101, 201 das Sprechrecht abgeben muss und dementsprechend die Übermittlung von Sprachnachrichten beenden muss.

Tabelle 6 enthält eine Liste der an sich gemäß dem Stand der Technik definierten Nachrichten für die Talk Burst Kontrolle im Rahmen einer PoC-Kommunikationssitzung.

Richtung der Übertragung der Nachricht	Bezeichnung der Nachricht	Beschreibung der Nachricht
Client → Serverrechner	Talk Burst request	eine PoC-Client-Einheit fragt beim PoC-Steuerserverrechner an, ob sie das Sprechrecht bekommen kann
Serverrechner → Client	Talk Burst Confirm response	der PoC-Steuerserverrechner bestätigt der anfragenden PoC-Client-Einheit das Sprechrecht
Serverrechner → Client	Talk Burst Reject response	der PoC-Steuerserverrechner verweigert der anfragenden PoC-Client-Einheit das Sprechrecht
Serverrechner → Clients	Receiving Talk Burst indication	der PoC-Steuerserverrechner teilt allen PoC-Client-Einheiten (außer der PoC-Client-Einheit mit Sprechrecht) mit, dass das Sprechrecht vergeben wurde und somit nun auch Sprach-Nachrichten versendet werden
Client → Serverrechner	Talk Burst Completed indication	eine PoC-Client-Einheit mit Sprechrecht teilt dem PoC-Steuerserverrechner mit, dass sie das Sprechrecht abgibt
Serverrechner → Clients	No Talk Burst indication	der PoC-Steuerserverrechner teilt allen PoC-Client-Einheiten mit, dass momentan niemand das Sprechrecht hat und somit auch keine Sprach-Nachrichten versendet werden
Serverrechner → Client	Stop Talk Burst indication	der PoC-Steuerserverrechner entzieht einer PoC-Client-Einheit mit Sprechrecht das Sprechrecht

Tabelle 6

Die in Tabelle 6 enthaltenen Nachrichten werden als RTCP APP-Pakete realisiert, das heißt mittels des Pakettyps für anwendungsspezifische Funktionen (APP) des Real Time-Kontrollprotokolls (Real Time Control Protocol, RTCP). Die Spezifikationen der jeweiligen RTCP APP-Pakete sind in [2] beschrieben.
In dem Fall, dass der Chair 107, 203 selbst einer PoC-Client-Einheit 201, 204 die das Sprechrecht hat, das Sprechrecht entzieht, signalisiert er dies der PoC-Client-Einheit 201, 204 mittels einer Chair_Stop_Talk_Burst_Indication-Nachricht, die beispielsweise gemäß Tabelle 7 ausgestaltet ist.
Tabelle 7: Chair_Stop_Talk_Burst_Indication
Die in Tabelle 7 dargestellte Chair_Stop_Talk_Burst_Indication-Nachricht enthält die Identifikation der PoC-Client-Einheit, die in dem Moment gerade das Sprechrecht hat und der das Sprechrecht entzogen wird, sowie die Spezifikation eines Grundes, warum die PoC-Client-Einheit die Übermittlung von Sprachnachrichten beenden muss (Reason Code) sowie ein Feld für zusätzliche Informationen.
Analog zu Schritt 209 übermittelt der PoC-Steuerserverrechner 106, 202 in Schritt 216 eine weitere Talk_Burst_Confirm_Response-Nachricht 228 an die zweite PoC-Client-Einheit 102, 204.
Analog zu Schritt 210 übermittelt der PoC-Steuerserverrechner 106, 202 in Schritt 217 eine weitere Receiving_Talk_Burst_Indication-Nachricht 229 an die erste PoC-Client-Einheit 101, 201.
Analog zu Schritt 211 beginnt die zweite PoC-Client-Einheit 102, 204 mit der Übermittlung von Sprachnachrichten an die erste PoC-Client-Einheit 101, 201 (Schritt 218).
Im Weiteren wird eine Ausführungsform erläutert, bei der die Entscheidung, welche PoC-Client-Einheit 101, 102, 103, 108 das Sprechrecht erhält, von dem Chair 107 gefällt wird, wobei eine Warteschlange von dem PoC-Steuerserverrechner 106 verwaltet wird.
3 zeigt ein Nachrichtenflussdiagramm 300 gemäß einem Ausführungsbeispiel der Erfindung.
Der dargestellte Nachrichtenfluss findet zwischen einer ersten PoC-Client-Einheit 101, 301, einem PoC-Steuerserverrechner 106, 302, einem Chair 107, 303 und einer zweiten PoC-Client-Einheit 102, 304, statt, die wie mit Bezug auf 1 beschrieben angeordnet und ausgestaltet sind.
Die Schritte 305 (Senden einer Chair_Priorities_IndicationNachricht 324 von dem PoC-Steuerserverrechner 106, 302 zu dem Chair 107, 303) und 306 (Senden einer Talk_Burst_Request-Nachricht 325 von der ersten PoC-Client-Einheit 101, 301 zu dem PoC-Steuerserverrechner 106, 302) werden analog zu den Schritten 205 und 206 in 2 durchgeführt.
Da in diesem Beispiel angenommen wird, dass die Warteschlange, die von dem PoC-Steuerserverrechner 106, 302 verwaltet wird, leer ist, fragt der PoC-Steuerserverrechner 106, 302 nicht bei dem Chair 107, 303 nach, sondern erteilt in Schritt 307 der ersten PoC-Client-Einheit 101, 301 analog zu Schritt 209 in 2 mittels einer Talk_Burst_Confirm_Response-Nachricht 320 das Sprechrecht.
Die Schritte 308 (Senden einer Receiving_Talk_Burst_Indication-Nachricht 326 von dem PoC-Steuerserverrechner 106, 302 zu der zweiten PoC-Client-Einheit 102, 304) und 309 (Übermittlung von Sprachdaten von der ersten PoC-Client-Einheit 101, 301 mittels des PoC-Steuerserverrechner 106, 302 zu der zweiten PoC-Client-Einheit 102, 304) werden entsprechend den Schritten 210 und 211 in 2 durchgeführt.
Es wird angenommen, dass in Schritt 310 die zweite PoC-Client-Einheit 102, 304 analog zu Schritt 212 die Anforderung nach dem Sprechrecht mittels einer Talk_Burst_Request-Nachricht 321 an den PoC-Teilnehmerserverrechner 106, 302 sendet.
Da in diesem Fall das Sprechrecht aktuell an die erste PoC-Client-Einheit 101, 301 vergeben ist, fragt der PoC-Steuerserverrechner 106, 302 in Schritt 311 mittels einer Chair_Talk_Burst_Request_Queueing-Nachricht 322, die beispielsweise gemäß Tabelle 8 ausgestaltet ist, bei dem Chair 107, 303 nach, an welcher Stelle die zweite PoC-Client-Einheit 102, 304 in die von dem PoC-Steuerserverrechner 106, 302 verwaltete Warteschlange eingereiht werden soll.
Tabelle 8: Chair_Talk_Burst_Request_Queueing
Wie dargestellt enthält die Chair_Talk_Burst_Request_Queueing-Nachricht 322 für jede in der Warteschlange geführte PoC-Client-Einheit 301, 304 eine Identifikation der PoC-Client-Einheit 301, 304 und die Priorität der jeweiligen PoC-Client-Einheit 301, 304 in der Reihenfolge, wie sie durch die Warteschlange festgelegt ist, sowie eine Identifikation und die Priorität der zweiten PoC-Client-Einheit 102, 304.
In einer Ausführungsform kann die zweite PoC-Client-Einheit 102, 304 der ersten PoC-Client-Einheit 101, 301 das Sprechrecht entziehen (anstatt beispielsweise nur an die erste Position der Warteschlange eingereiht zu werden), wenn die erste PoC-Client-Einheit 101, 301 das Sprechrecht hat und eine niedrigere Priorität aufweist als die zweite PoC-Client-Einheit 102, 304. In dieser Ausführungsform kann die Chair_Talk_Burst_Request_Queueing-Nachricht 322 beispielsweise gemäß Tabelle 8a ausgestaltet sein und die Identifikation der ersten PoC-Client-Einheit 301, 304, die aktuell das Sprechrecht hat, sowie die Priorität dieser PoC-Client-Einheit 301, 304 enthalten. Der Chair 107, 304 kann entsprechend mittels einer Chair_Talk_Burst_Confirm_Response-Nachricht gestatten, dass der ersten PoC-Client-Einheit 101, 301 das Sprechrecht entzogen wird und der zweiten PoC-Client-Einheit 102, 304 zugeteilt wird, oder dies mittels einer Chair_Talk_Burst_Reject_Response-Nachricht ablehnen.
In einer anderen Ausführungsform wird die PoC-Client-Einheit, die aktuell das Sprechrecht hat, stets an der ersten Position der Warteschlange geführt. Dementsprechend könnte eine weitere PoC-Client-Einheit mit einer höheren Priorität als die PoC-Client-Einheit, die aktuell das Sprechrecht hat, das Sprechrecht entziehen, indem sie an der ersten Position der Warteschlange eingereiht wird und entsprechend die PoC-Client-Einheit, die aktuell das Sprechrecht hat, auf die zweite Position der Warteschlange zurückfällt.
Tabelle 8a: Chair_Talk_Burst_Request_Queueing (Alternative)
Analog zu oben kann auf die Übermittlung der Prioritäten mittels der Chair_Talk_Burst_Request_Queueing-Nachricht 322 verzichtet werden, falls in Schritt 305 die Prioritäten der PoC-Client-Einheiten 301, 304 mittels einer Chair_Priorities_Indication-Nachricht 324 übermittelt wurden.
In Schritt 312 übermittelt der Chair 107, 303 dem PoC-Steuerserverrechner 106, 302 die Position der zweiten PoC-Client-Einheit 102, 304 mittels einer Chair_Talk_Burst_Request_Queued_Response-Nachricht 323, die gemäß Tabelle 9 ausgestaltet ist.
Tabelle 9: Chair_Talk_Burst_Request_ Queued_Response
Alternativ kann der Chair 107, 303 in Schritt 312 auch die Angabe der kompletten aktualisierten Warteschlange, das heißt der Warteschlange, in die die zweite PoC-Client-Einheit 102, 304 aufgenommen ist, an den PoC-Steuerserverrechner 106, 302 übermitteln.
Dies erfolgt mittels einer Chair_Talk_Burst_Request_Queue_Result-Nachricht, die beispielsweise gemäß Tabelle 10 ausgestaltet ist und analog zu der Chair_Talk_Burst_Request_Queueing-Nachricht 322 die Angabe der (nun aktualisierten) Warteschlange enthält.
Tabelle 10: Chair_Talk_Burst_Request_Queue_Result
Die Position der zweiten PoC-Client-Einheit 102, 304 in der Warteschlange bestimmt der Chair 107, 303 unter Berücksichtigung der Priorität der zweiten PoC-Client-Einheit 102, 304.
Der PoC-Steuerserverrechner 106, 302 erstellt deshalb einen Eintrag für die zweite PoC-Client-Einheit 102, 304 in der von ihm geführten Warteschlange und teilt in Schritt 313 der zweiten PoC-Client-Einheit 102, 304 mittels einer weiteren Talk_Burst_Request_Queued_Response-Nachricht 327 mit, dass sie in die Warteschlange eingereiht ist.
In Schritt 314 teilt die erste PoC-Client-Einheit 101, 301 mittels einer Talk_Burst_Completed_Indication-Nachricht 328 dem PoC-Steuerserverrechner 106, 302 mit, dass sie die Übermittlung von Sprachdaten beendet und das Sprechrecht abgibt.
Da in der von dem PoC-Steuerserverrechner 106, 302 geführten Warteschlange ein Eintrag für die zweite PoC-Client-Einheit 102, 304 vorhanden ist und in diesem Beispiel angenommen wird, dass kein Eintrag vor dem Eintrag für die zweite PoC-Client-Einheit 102, 304 in der Warteschlange vorhanden ist, erteilt der PoC-Steuerserverrechner 106, 302 jetzt der zweiten PoC-Client-Einheit 102, 304 das Sprechrecht. Dementsprechend übermittelt der PoC-Steuerserverrechner 106, 302 eine weitere Talk_Burst_Confirm_Response-Nachricht 329 (Schritt 315) an die zweite PoC-Client-Einheit 102, 304.
Die weitere Talk_Burst_Request-Nachricht 321 und die weitere Talk_Burst_Confirm_Response-Nachricht 329 sowie die Talk-Burst_Completed_Indication-Nachricht 328 sind eingerichtet und aufgebaut, wie in [7] beschrieben.
Die Schritte 316 (Senden einer Receiving_Talk_Burst_Indication-Nachricht 330 von dem PoC-Steuerserverrechner 106, 302 zu der ersten PoC-Client-Einheit 101, 301) und 317 (Übermittlung von Sprachdaten von der zweiten PoC-Client-Einheit 102, 304 mittels des PoC- Steuerserverrechner 106, 302 zu der ersten PoC-Client-Einheit 101, 301) werden analog zu den Schritten 308 und 309 durchgeführt.
In einer anderen Ausführungsform verwaltet der Chair 107 eine Warteschlange. In diesem Fall wird bei jeder Anfrage der PoC-Client-Einheiten 101, 102, 103, 108 der Chair 107 von dem PoC-Steuerserverrechner 106 kontaktiert.
In diesem Fall ist neben der Übertragung einer Chair_Talk_Burst_Confirm_Response-Nachricht 222 in Schritt 208 des in 2 dargestellten Nachrichtenflussdiagramms 200 auch eine Übertragung einer Chair_Talk_Burst_Reject_Response-Nachricht oder eine Chair_Talk_Burst_Request_Queued_Response-Nachricht, wie sie oben beschrieben wurden, möglich. Stellt eine der PoC-Client-Einheiten 101, 120, 103, 108 eine Anfrage bei dem PoC-Steuerserverrechner 106 nach der Position des der PoC-Client-Einheit 101, 102, 103, 108 entsprechenden Eintrags in der Warteliste, beispielsweise mittels einer oben beschriebenen Talk_Burst_Queue_Position_Request-Nachricht, so kontaktiert der PoC-Steuerserverrechner 106 mittels einer Chair_Talk_Burst_Queue_Position_Request-Nachricht, die beispielsweise gemäß Tabelle 11 ausgestaltet ist, den Chair 107.
Tabelle 11: Chair_Talk_Burst_Queue_Position_Request
Die Chair_Talk_Burst_Queue_Position_Request-Nachricht enthält eine Spezifikation der PoC-Client-Einheit 101, 102, 103, 108, welche die Anfrage gestellt hat.
Der Chair 107 antwortet darauf dem PoC-Steuerserverrechner 106 mittels einer Chair_Talk_Burst_Queue_Position_Response-Nachricht, die gemäß Tabelle 12 und analog zu der oben beschriebenen Talk_Burst_Queue_Position_Response-Nachricht ausgestaltet ist.
Tabelle 12: Chair_Talk_Burst_Queue_Position_Response
Analog zu dem oben beschriebenen Fall ist die Chair_Talk_Burst_Queue_Position_Response-Nachricht bis auf das Feld „subtype" und auf die Spezifikation der Senderadresse identisch mit der Talk_Burst_Request_Queued_Response-Nachricht 323.
Stellt eine PoC-Client-Einheit 101, 102, 103, 108 eine Anfrage nach dem Gesamtzustand der Warteschlange, beispielsweise mittels einer Talk_Burst_Queue_Identity_Request-Nachricht, so kontaktiert der PoC-Steuerserverrechner 106 den Chair 107 mittels einer Chair_Talk_Burst_Queue_Identity_Request-Nachricht, die gemäß Tabelle 13 ausgestaltet ist und mittels welcher die Anfrage an den Chair 107 weitergeleitet wird.
Tabelle 13: Chair_Talk_Burst_Queue_Identity_Request
Der Chair 107 beantwortet diese Anfrage mittels einer Chair_Talk_Burst_Queue_Identitiy_Response-Nachricht, die beispielsweise gemäß Tabelle 14 ausgestaltet ist und bis auf das Feld „subtype" und auf das Feld, das die Spezifikation des Senders der Nachricht enthält, identisch mit der Talk Burst Queue Identity Response-Nachricht ist.
Tabelle 14: Chair_Talk_Burst_Queue_Identity_Response
Teilt eine PoC-Client-Einheit 101, 102, 103, 108 beispielsweise mittels einer Talk_Burst_Request_Cancellation-Nachricht wie oben erläutert mit, dass sie nicht länger das Sprechrecht anfordert, also ein der PoC-Client-Einheit 101, 102, 103, 108 entsprechender Eintrag aus der Warteschlange entfernt werden soll, leitet der PoC-Steuerserverrechner 106 diese Information mittels einer Chair_Talk_Burst_Request_Cancellation-Nachricht, die beispielsweise gemäß Tabelle 15 ausgestaltet ist und analog zu der Talk Burst Request Cancellation-Nachricht ausgestaltet ist, an den Chair 107 weiter.
Tabelle 15: Chair_Talk_Burst_Request_Cancellation
Im Folgenden wird eine Ausführungsform der Erfindung beschrieben, bei welcher der oben beschriebene Chair-Mechanismus (mit oder ohne Warteschlange) zum Vergeben eines Kommunikationsrechts im Rahmen einer Kommunikations-Konferenz verwendet wird.
Die im Folgenden beschriebenen Ausführungsformen basieren ebenfalls auf dem in 1 dargestellten und oben im Detail beschriebenen Kommunikationssystem, wobei im Folgenden ohne Einschränkung der Allgemeingültigkeit der Chair 107 jeweils in einer PoC-Client-Einheit, nämlich in der ersten PoC-Client-Einheit 101, welche in einem ersten Mobilfunk-Kommunikationsendgerät implementiert ist, realisiert ist. Das Push-to-Talk-Kommunikationssystem 100 und die darin vorgesehenen Komponenten sind gemäß dem OMA-Standard (vgl. [6]) eingerichtet, wobei die einzelnen Komponenten ferner eingerichtet sind, die im Folgenden beschriebenen Verfahrensschritte durchzuführen und die entsprechenden Nachrichten zu codieren bzw. zu decodieren.
Somit kommunizieren gemäß den folgenden Ausführungsformen die Teilnehmer, in diesem Fall vier Teilnehmer mit jeweils einem Mobilfunk-Kommunikationsendgerät nicht direkt miteinander, sondern mittels des zentralen PoC-Steuerserverrechners 106. Die Teilnehmer bzw. deren Mobilfunk-Kommunikationsendgeräte kommunizieren miteinander per Audio.
Die Kommunikationsrechts-Kontrolle und dabei beispielsweise auch die Kommunikationsrecht-Vergabe erfolgt unter Verwendung von RTCP-Nachrichten gemäß dem in [2] beschriebenen OMA-Kommunikationsstandard unter Verwendung der oben beschriebenen Erweiterung um den Chair 107 und den damit verbundenen Erweiterungen der RTCP-Nachrichten, wie sie oben beschrieben wurden.
Gemäß den folgenden Ausführungsformen wird angenommen, dass der erste Teilnehmer T1, das heißt der Nutzer des ersten Mobilfunk-Kommunikationsendgeräts und damit der ersten PoC-Client-Einheit 101, eine Push-to-Talk-Kommunikationssitzung (PTT-Kommunikationssitzung) erzeugt.
Dies geschieht, indem der erste Teilnehmer T1 die anderen Teilnehmer T2, T3, T4 zu der PTT-Kommunikationssitzung einlädt, beispielsweise mittels entsprechender SIP-INVITE-Nachrichten (SIP: Session Initiation Protocol) welche von der ersten PoC-Client-Einheit 101 erzeugt werden und an die jeweiligen PoC-Client-Einheiten der einzuladenden Teilnehmer T2, T3, T4 gesendet werden.
Die Mobilfunk-Kommunikationsendgeräte der Teilnehmer T2, T3, T4 bzw. deren PoC-Client-Einheiten 102, 103, 108 empfangen die jeweilige SIP-INVITE-Nachricht und nehmen die Einladung mittels entsprechender SIP-Bestätigungs-Nachrichten an, welche jeweils von der jeweiligen PoC-Client-Einheit 102, 103, 108 erzeugt wird und an die erste PoC-Client-Einheit 101 gesendet wird. Damit ist die PTT-Kommunikationssitzung erzeugt und die PoC-Client-Einheiten 101, 102, 103, 108 können nunmehr untereinander gemäß den jeweils verwendeten Kommunikationsprotokollen Daten austauschen, beispielsweise Audiodaten, alternativ oder zusätzlich Videodaten, Standbilddaten, textuelle Daten, etc.
Da der erste Teilnehmer T1 bzw. dessen erste FoC-Client-Einheit 101 die PTT-Kommunikationssitzung erzeugt hat, wird dieser bzw. diese zum Moderator der PTT-Kommunikationssitzung und hat damit das Recht zur Kommunikationsrecht-Vergabe im Rahmen dieser PTT-Kommunikationssitzung.
Das Nachrichtenflussdiagramm 400 in 4 zeigt den Datenfluss zum Anfordern, Vergeben und zum Durchführen eines Kommunikations-Beitrags, wobei gemäß 4 die PTT-Kommunikationssitzung schon vollständig, beispielsweise auf die oben beschriebene Weise, erzeugt ist.
Gemäß diesem Ausführungsbeispiel der Erfindung wird angenommen, dass der zweite Teilnehmer T2 und damit das zweite Mobilfunk-Kommunikationsendgerät und damit die zweite PoC-Client-Einheit 102 als erster das Sprechrecht bei dem PoC-Steuerserverrechner 106 mittels einer ersten TB_Request-Nachricht 401 (TB ist die im Rahmen dieser Beschreibung gewählte Abkürzung für Talk Burst) anfordert.
Die erste TB_Request-Nachricht 401 ist eine RTCP-Nachricht und enthält, wie im Folgenden noch näher erläutert wird, einen Verweis, im Folgenden auch bezeichnet als Identifikationsangabe (ID), gemäß diesem Ausführungsbeispiel eine erste Identifikationsangabe mit dem Wert „0", auf den Kommunikationsfluss, im Folgenden auch als Konferenz-Nachrichtenfluss bezeichnet, der Kommunikationssitzung. Der Verweis bedeutet, dass ein Rederecht (Sprechrecht) für den Konferenz-Nachrichtenfluss der Kommunikationssitzung angefordert wird. Die erste TB_Request-Nachricht 401 wird somit von der zweiten PoC-Client-Einheit 102 erzeugt und an den PoC-Steuerserverrechner 106 übermittelt. Der PoC-Steuerserverrechner 106 leitet die Anforderung an den Moderator, d.h. anschaulich an den Chair (in diesem Beispiel die erste PoC-Client-Einheit 101), weiter, indem der PoC-Steuerserverrechner 106 eine erste Chair_TB_Request_Nachricht 402 erzeugt und an die erste PoC-Client-Einheit 101 übermittelt. Die erste Chair_TB_Request_Nachricht 402 enthält ebenfalls die erste Identifikationsangabe mit dem Wert „0", die in der ersten TB_Request-Nachricht 401 enthalten ist.
Die folgende Tabelle 16 zeigt beispielhaft das Format der ersten TB_Request-Nachricht 401 sowie der ersten Chair_TB_Request_Nachricht 402:
Tabelle 16: TB_Request/Chair_TB_Request
Die Felder der in Tabelle 16 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• subtype: Subtyp der Nachricht, der die Nachricht als "TB_Request"- bzw. "Chair_TB_Request"-Nachricht identifiziert;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des initiierenden PoC-Teilnehmers; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den zu der RTCP-Nachricht gehörenden RTP-Paketen definiert;
• Name=PoC1: Applikations-definierter Nachrichten-Name (PoC1 = PTT over Cellular Version 1);
• Thread ID: Identifikator des Kommunikationsflusses, für den das Kommunikationsrecht angefordert wird; der Kommunikationsfluss der PTT-Kommunikationssitzung hat gemäß diesem Ausführungsbeispiel per Default den Wert "0".

Der Verweis weist in diesem Fall eine Identifikationsangabe (Thread ID) für den Konferenz-Nachrichtenfluss der PTT-Kommunikationssitzung auf. Die Identifikationsangabe des Konferenz-Nachrichtenflusses der PTT-Kommunikationssitzung hat gemäß diesem Ausführungsbeispiel per Default den Wert "0".
Der Moderator, d.h. in diesem Fall der erste Teilnehmer T1, genehmigt die Anforderung mittels einer von der ersten PoC-Client-Einheit 101 erzeugten und an den PoC-Steuerserverrechner 106 übermittelten ersten Chair_TB_Granted Nachricht 403.
Auf den Empfang der ersten Chair_TB_Granted_Nachricht 403 hin erzeugt der PoC-Steuerserverrechner 106 eine erste TB_Granted_Nachricht 404 und übermittelt diese an die zweite PoC-Client-Einheit 102 und damit an den zweiten Teilnehmer T2. Der PoC-Steuerserverrechner 106 fügt in die erste TB_Granted_Nachricht 404 eine noch nicht verwendete Kommunikationsfluss-Identifikationsangabe ein (gemäß diesem Ausführungsbeispiel eine zweite Identifikationsangabe mit dem Wert "1"). Die Kommunikationsfluss-Identifikationsangabe dient dem Ermöglichen einer späteren Bezugnahme auf den Kommunikationsfluss des genehmigten Talk Bursts. Außerdem benachrichtigt der PPC-Steuerserverrechner 106 alle anderen Teilnehmer außer den zweiten Teilnehmer T2 mittels einer jeweiligen TB_Taken_Nachricht 405, 406, 407 darüber, dass das Rederecht 408 vergeben wurde.
Im Detail erzeugt der PoC-Steuerserverrechner 106

• eine erste TB_Taken_Nachricht 405 und übermittelt diese an die erste PoC-Client-Einheit 101 und damit an den ersten Teilnehmer T1,
• eine zweite TB_Taken_Nachricht 406 und übermittelt diese an die dritte PoC-Client-Einheit 103 und damit an den dritten Teilnehmer T3,
• eine dritte TB_Taken_Nachricht 407 und übermittelt diese an die vierte PoC-Client-Einheit 108 und damit an den vierten Teilnehmer T4.

Die TB_Taken_Nachrichten 405, 406, 407 enthalten ebenfalls jeweils die Kommunikationsfluss-Identifikationsangabe zu dem genehmigten Rede-Beitrag (allgemein dem genehmigten Kommunikations-Beitrag), in diesem Fall jeweils die zweite Identifikationsangabe mit dem Wert „1".
Die folgende Tabelle 17 zeigt beispielhaft das Format einer Chair_TB_Granted_Nachricht als RTCP-Nachricht zur Genehmigung des Kommunikationsrechts durch einen Moderator mit Angabe des Kommunikationsflusses, für den das Kommunikationsrecht vergeben wird:
Tabelle 17: Chair_TB_Granted
Die Felder der in Tabelle 17 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• subtype: Subtyp der Nachricht, der die Nachricht als "Chair_TB_Granted"-Nachricht identifiziert;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des Moderators, der das Kommunikationsrecht vergibt. Die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den zu der RTCP-Nachricht gehörenden RTP-Paketen definiert;
• Name=PoC1: Applikations-definierter Nachrichten-Name (PoC1 = PTT over Cellular Version 1);
• Thread ID: Identifikator des Kommunikationsflusses, für den das Kommunikationsrecht vergeben wird;
• SDES CNAME item followed by SDES NAME item: CNAME und NAME des Teilnehmerendgeräts, dem das Kommunikationsrecht gegeben werden soll; CNAME und NAME sind so genannte SDES items, die in SDES RTCP-Paketen definiert werden, um einen RTP-Teilnehmer zu beschreiben; CNAME ist ein eindeutiger Name des Teilnehmers, der auch außerhalb spezifischer RTP-Sessions weiter besteht (beispielsweise zusammengesetzt aus user name und host IP-Adresse); NAME ist ein beliebiger Name des Teilnehmers, der typischerweise vom Teilnehmer selbst angegeben wird; NAME muss den Teilnehmer nicht eindeutig identifizieren; Wie bei SDES RTCP-Paketen wird die Liste der SDES items CNAME und NAME durch ein SDES item vom Typ 00000000 eindeutig abgeschlossen; die Liste wird anschließend bis zu Vielfachen von 32 Bit mit Nullen gepadded, wie an sich in [3] beschrieben.

Die folgende Tabelle 18 zeigt beispielhaft das Format einer TB_Granted_Nachricht als RTCP-Nachricht zur Genehmigung des Kommunikationsrechts durch den PoC-Serverrechner 106 mit Angabe des Kommunikationsflusses, für den das Kommunikationsrecht vergeben wird und mit Angabe der ID für den neuen Kommunikationsfluss, der durch den genehmigten Kommunikations-Beitrag erzeugt wird:
Tabelle 18: TB_Granted
Die Felder der in Tabelle 18 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• subtype: Subtyp der Nachricht, der die Nachricht als "TB_Granted"-Nachricht identifiziert;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des Servers, der das Kommunikationsrecht vergibt; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den zu der RTCP-Nachricht gehörenden RTP-Paketen definiert;
• Name=PoC1: Applikations-definierter Nachrichten-Name (PoC1 = PTT over Cellular Version 1);
• Thread ID 1: Identifikator des Kommunikationsflusses, für den das Kommunikationsrecht vergeben wird;
• Thread ID 2: Identifikator des neuen Kommunikationsflusses, der durch den genehmigten Kommunikations-Beitrag erzeugt wird.

Die folgende Tabelle 19 zeigt beispielhaft das Format einer TB_Taken_Nachricht als RTCP-Nachricht zur Benachrichtigung, dass das Kommunikationsrecht vergeben wurde mit Angabe der ID des neuen Kommunikationsflusses, der durch den genehmigten Kommunikations-Beitrag erzeugt wurde:
Tabelle 19: TB_Taken
Die Felder der in Tabelle 19 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• subtype: Subtyp der Nachricht, der die Nachricht als "TB_Taken"-Nachricht identifiziert;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des Servers, der die Benachrichtigung verschickt; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den zu der RTCP-Nachricht gehörenden RTP-Paketen definiert;
• Name=PoC1: Applikations-definierter Nachrichten-Name (PoC1 = PTT over Cellular Version 1);
• Thread ID: Identifikator des neuen Kommunikationsflusses, der durch den genehmigten Kommunikations-Beitrag erzeugt wird;
• SDES CNAME item followed by SDES NAME item: CNAME und NAME des Teilnehmerendgeräts, dem das Kommunikationsrecht gegeben wurde; CNAME und NAME sind so genannte SDES items, die in SDES RTCP-Paketen definiert werden, um einen RTP-Teilnehmer zu beschreiben; CNAME ist ein eindeutiger Name des Teilnehmers, der auch außerhalb spezifischer RTP-Sessions weiter besteht (beispielsweise zusammengesetzt aus user name und host IP-Adresse); NAME ist ein beliebiger Name des Teilnehmers, der typischerweise vom Teilnehmer selbst angegeben wird. NAME muss den Teilnehmer nicht eindeutig identifizieren; wie bei SDES RTCP-Paketen wird die Liste der SDES items CNAME und NAME durch ein SDES item vom Typ 00000000 eindeutig abgeschlossen; die Liste wird anschließend bis zu Vielfachen von 32 Bit mit Nullen gepadded, wie an sich in [3] beschrieben.

Der zweite Teilnehmer T2, welcher nunmehr das Rederecht 408 zugeordnet bekommen hat, versendet seinen Rede-Beitrag (mittels der zweiten PoC-Client-Einheit 102), welcher mittels des PoC-Steuerserverrechners 106 an die anderen Teilnehmer T1, T3 und T4 weitergeleitet wird. Nach einer gewissen kurzen Zeitdauer beendet der zweite Teilnehmer T2 bzw. die zweite PoC-Client-Einheit 102 mittels einer von dieser erzeugten und an den PoC-Steuerserverrechner 106 übermittelten ersten TB_Release_Nachricht 409 seinen Beitrag.
Die folgende Tabelle 20 zeigt beispielhaft das Format einer TB_Release_Nachricht als RTCP-Nachricht zur Beendigung eines Kommunikations-Beitrags mit Angabe der Kommunikationsfluss-Identifikationsangabe, welche den Kommunikationsfluss identifiziert, der durch den beendeten Kommunikations-Beitrag erzeugt wurde:
Tabelle 20: TB_Release
Die Felder der in Tabelle 20 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• subtype: Subtyp der Nachricht, der die Nachricht als "TB_Release"-Nachricht identifiziert;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des Teilnehmerendgeräts, das seinen Kommunikations-Beitrag beendet; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den zu der RTCP-Nachricht gehörenden RTP-Paketen definiert;
• Name=PoC1: Applikations-definierter Nachrichten-Name (PoC1 = PTT over Cellular Version 1);
• Sequence number of last packet: Sequenznummer des letzten RTP-Pakets des beendeten Kommunikations-Beitrags;
• I: Indikator für das Ignorieren des Sequenznummer-Feldes;
• Padding: Null-Daten zum Auffüllen bis zur nächsten Wortgrenze;
• Thread ID: Identifikator des Kommunikationsflusses, der durch den beendeten Kommunikations-Beitrag erzeugt wurde.

Der PoC-Steuerserverrechner 106 informiert auf den Empfang der ersten TB_Release_Nachricht 409 hin die anderen Teilnehmer T1, T3, T4 darüber, dass das Kommunikationsrecht nicht mehr vergeben ist und damit darüber, dass der Kommunikations-Beitrag, der den Kommunikationsfluss mit der ID 1 erzeugt hat, beendet wurde. Hierfür erzeugt der PoC-Steuerserverrechner 106 für jeden zu informierenden Teilnehmer T1, T3, T4 jeweils eine TB_Idle-Nachricht 410, 411, 412 und versendet diese an den jeweiligen Teilnehmer T1, T3, T4.
Im Detailerzeugt der PoC-Steuerserverrechner 106

• eine erste TB_Idle-Nachricht 410 und übermittelt diese an die erste PoC-Client-Einheit 101 und damit an den ersten Teilnehmer T1,
• eine zweite TB_Idle-Nachricht 411 und übermittelt diese an die dritte PoC-Client-Einheit 103 und damit an den dritten Teilnehmer T3,
• eine dritte TB_Idle-Nachricht 412 und übermittelt diese an die vierte PoC-Client-Einheit 108 und damit an den vierten Teilnehmer T4.

Die folgende Tabelle 21 zeigt beispielhaft das Format einer TB_Idle-Nachricht als RTCP-Nachricht zur Benachrichtigung, dass das Kommunikationsrecht nicht mehr vergeben ist mit Angabe der ID des Kommunikationsflusses, der durch den letzten Kommunikations-Beitrag erzeugt wurde:
Tabelle 21: TB_Idle
Die Felder der in Tabelle 21 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• subtype: Subtyp der Nachricht, der die Nachricht als "TB_Idle"-Nachricht identifiziert;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des Servers, der die Benachrichtigung verschickt; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den zu der RTCP-Nachricht gehörenden RTP-Paketen definiert;
• Name=PoC1: Applikations-definierter Nachrichten-Name (PoC1 = PTT over Cellular Version 1);
• Thread ID: Identifikator des Kommunikationsflusses, der durch den zuletzt beendeten Kommunikations-Beitrag erzeugt wurde.

In 5 ist in einem anderen Nachrichtenflussdiagramm 500 der weitere Verlauf der Konferenz dargestellt.
Es wird weiterhin gemäß diesem Ausführungsbeispiel der Erfindung angenommen, dass der dritte Teilnehmer T3 mittels seines Mobilfunk-Kommunikationsendgeräts und damit mittels der dritten PoC-Client-Einheit 103, und kurz darauf der vierte Teilnehmer T4 mittels seines Mobilfunk-Kommunikationsendgeräts und damit mittels der vierten PoC-Client-Einheit 108, das Rederecht mit Bezug auf den Rede-Beitrag von dem zweiten Teilnehmer T2 anfordern.
Hierzu erzeugt die dritte PoC-Client-Einheit 103 eine zweite TB_Request-Nachricht 501 und übermittelt diese an den PoC-Steuerserverrechner 106. In gleicher Weise erzeugt die vierte PoC-Client-Einheit 108 eine dritte TB_Request-Nachricht 502 und übermittelt diese ebenfalls an den PoC-Steuerserverrechner 106. In den beiden TB_Request-Nachrichten 501 und 502 ist jeweils die Kommunikationsfluss-Identifikationsangabe mit dem Wert 1 (ID 1) als Verweis enthalten, mit der auf den Rede-Beitrag des zweiten Teilnehmers T2 verwiesen wird. Die beiden TB_Request-Nachrichten 501 und 502 weisen das gleiche Format auf wie die erste TB_Request-Nachricht 401 (vgl. Tabelle 16).
Auf den Empfang einer jeweiligen TB_Request-Nachricht 501, 502 hin leitet der PoC-Steuerserverrechner 106 die Anforderung an den zweiten Teilnehmer T2, genauer an die zweite PoC-Client-Einheit 102, weiter, da die Anforderung (d.h. die Kommunikationsfluss-IDs der TB_Request-Nachrichten 501 und 502) auf den Rede-Beitrag des zweiten Teilnehmers T2 verweisen.
Das Weiterleiten der Anforderungen ist realisiert, indem der PoC-Steuerserverrechner 106 auf den Empfang der zweiten TB_Request-Nachricht 501 hin eine zweite Chair_TB_Request_Nachricht 503 erzeugt und an die zweite PoC-Client-Einheit 102 übermittelt. In gleicher Weise erzeugt der PoC-Steuerserverrechner 106 auf den Empfang der dritten TB_Request-Nachricht 502 hin eine dritte Chair_TB_Request_Nachricht 504 und übermittelt diese an die zweite PoC-Client-Einheit 102.
Der zweite Teilnehmer T2 und damit die zweite PoC-Client-Einheit 102 genehmigt dem dritten Teilnehmer T3 das Rederecht, da der dritte Teilnehmer T3 das Rederecht zuerst angefordert hat. Ferner merkt sich, anders ausgedrückt speichert, der zweite Teilnehmer T2 und damit die zweite PoC-Client-Einheit 102 die Anforderung des vierten Teilnehmers T4 in einer wie oben beschrieben optional vorgesehenen Warteschlange. Um dies zu realisieren erzeugt der zweite Teilnehmer T2 bzw. dessen zweite PoC-Client-Einheit 102 eine zweite Chair_TB_Granted_Nachricht 505 und übermittelt diese an den PoC-Steuerserverrechner 106. In diesem Zusammenhang ist anzumerken, dass sowohl in den beiden Chair_TB_Request-Nachrichten 503, 504 als auch in der zweiten Chair_TB_Granted_Nachricht 505 die Kommunikationsfluss-Identifikationsangabe mit dem Wert 1 (ID 1) enthalten ist.
Auf den Empfang der zweiten Chair_TB_Granted_Nachricht 505 hin erzeugt der PoC-Steuerserverrechner 106 eine zweite TB_Granted_Nachricht 506 und übermittelt diese an die dritte PoC-Client-Einheit 103 und damit an den dritten Teilnehmer T3. Die zweite TB_Granted_Nachricht 506 dient somit zur Genehmigung des Kommunikationsrechts zum Kommunikationsfluss mit einer zweiten Kommunikationsfluss-Identifikationsangabe ID 1 (erste Ziffer in Klammern in der zweiten TB_Granted_Nachricht 506 von 5) mit der Mitteilung, dass der durch den genehmigten Kommunikations-Beitrag erzeugte Kommunikationsfluss eine dritte Kommunikationsfluss-Identifikationsangabe ID 2 hat (zweite Ziffer in Klammern in der zweiten TB_Granted_Nachricht 506 von 5).
Außerdem benachrichtigt der PoC-Steuerserverrechner 106 alle anderen Teilnehmer außer den dritten Teilnehmer T3 mittels einer jeweiligen TB_Taken_Nachricht 507, 508, 509 darüber, dass das Rederecht (symbolisiert in 5 mit Bezugszeichen 510) vergeben wurde. Ferner dienen die TB_Taken_Nachrichten 507, 508, 509 dazu, die Teilnehmer darüber zu informieren, dass der dadurch vergebene Kommunikationsfluss die ID bekommen hat, die in der Kommunikationsfluss-Identifikationsangabe der jeweiligen TB_Taken_Nachricht 507, 508, 509 angegeben ist.
Im Detail erzeugt der PoC-Steuerserverrechner 106

• eine vierte TB_Taken_Nachricht 507 und übermittelt diese an die erste PoC-Client-Einheit 101 und damit an den ersten Teilnehmer T1,
• eine fünfte TB_Taken_Nachricht 508 und übermittelt diese an die zweite PoC-Client-Einheit 102 und damit an den zweiten Teilnehmer T2,
• eine sechste TB_Taken_Nachricht 509 und übermittelt diese an die vierte PoC-Client-Einheit 108 und damit an den vierten Teilnehmer T4.

Der dritte Teilnehmer T3, welcher nunmehr das Rederecht 510 zugeordnet bekommen hat, versendet seinen Rede-Beitrag (mittels der dritten PoC-Client-Einheit 103), welcher mittels des PoC-Steuerserverrechners 106 an die anderen Teilnehmer T1, T2 und T4 weitergeleitet wird. Nach einer gewissen Zeitdauer beendet der dritte Teilnehmer T3 bzw. die dritte PoC-Client-Einheit 103 mittels einer von dieser erzeugten und an den PoC-Steuerserverrechner 106 übermittelten zweiten TB_Release_Nachricht 511, welche die Angabe der Kommunikationsfluss-Identifikationsangabe mit dem Wert 2 des zugehörigen Kommunikationsflusses enthält. Der PoC-Steuerserverrechner 106 erzeugt auf den Empfang der zweiten TB_Release_Nachricht 511 hin eine erste Chair_TB_Release-Nachricht 512 mit der Angabe der Kommunikationsfluss-Identifikationsangabe mit dem Wert 2 des zugehörigen Kommunikationsflusses und sendet diese an die zweite PoC-Client-Einheit 102 und damit an den zweiten Teilnehmer T2.
Nachdem der dritte Teilnehmer T3 seinen Rede-Beitrag beendet hat, genehmigt der zweite Teilnehmer T2, beispielsweise auf den Empfang der ersten Chair_TB_Release-Nachricht 512 hin dem vierten Teilnehmer T4 das Rederecht.
Um dies zu realisieren erzeugt der zweite Teilnehmer T2 bzw. dessen zweite PoC-Client-Einheit 102 eine dritte Chair_TB_Granted_Nachricht 513 und übermittelt diese an den PoC-Steuerserverrechner 106, wobei in der dritten Chair_TB_Granted_Nachricht 513 die Kommunikationsfluss-Identifikationsangabe mit dem Wert 1 (ID 1) enthalten ist.
Auf den Empfang der dritten Chair_TB_Granted_Nachricht 513 hin erzeugt der PoC-Steuerserverrechner 106 eine dritte TB_Granted_Nachricht 514 und übermittelt diese an die vierte PoC-Client-Einheit 108 und damit an den vierten Teilnehmer T4. Die dritte TB_Granted_Nachricht 514 dient somit zur Genehmigung des Kommunikationsrechts zum Kommunikationsfluss mit der zweiten Kommunikationsfluss-Identifikationsangabe ID 1 (erste Ziffer in Klammern in der dritten TB_Granted_Nachricht 514 von 5) mit der Mitteilung, dass der durch den genehmigten Kommunikations-Beitrag erzeugte Kommunikationsfluss eine vierte Kommunikationsfluss-Identifikationsangabe ID mit dem Wert 3 (ID 3) hat (zweite Ziffer in Klammern in der dritten TB_Granted_Nachricht 514 von 5).
Außerdem benachrichtigt der PoC-Steuerserverrechner 106 alle anderen Teilnehmer außer den vierten Teilnehmer T4 mittels einer jeweiligen TB_Taken_Nachricht 515, 516, 517 darüber, dass das Rederecht (symbolisiert in 5 mit Bezugszeichen 518) vergeben wurde. Ferner dienen die TB_Taken_Nachrichten 515, 516, 517 dazu, die Teilnehmer darüber zu informieren, dass der dadurch vergebene Kommunikationsfluss die ID bekommen hat, die in der Kommunikationsfluss-Identifikationsangabe der jeweiligen TB_Taken_Nachricht 515, 516, 517 angegeben ist.
Im Detail erzeugt der PoC-Steuerserverrechner 106

• eine siebte TB_Taken_Nachricht 515 und übermittelt diese an die erste PoC-Client-Einheit 101 und damit an den ersten Teilnehmer T1,
• eine achte TB_Taken_Nachricht 516 und übermittelt diese an die zweite PoC-Client-Einheit 102 und damit an den zweiten Teilnehmer T2,
• eine neunte TB_Taken_Nachricht 517 und übermittelt diese an die dritte PoC-Client-Einheit 103 und damit an den dritten Teilnehmer T3.

Während der vierte Teilnehmer T4 noch spricht, anders ausgedrückt, während ihm noch das Rederecht 518 zugeordnet ist, wird gemäß diesem Ausführungsbeispiel angenommen, dass der dritte Teilnehmer T3 mittels der dritten PoC-Client-Einheit 103 das Rederecht zum Kommunikationsfluss der Kommunikationssitzung anfordert mittels einer vierten TB_Request-Nachricht 601, welche als Verweis auf die Kommunikationssitzung die erste Kommunikationsfluss-Identifikationsangabe mit dem Wert 0 aufweist und welche zu dem PoC-Steuerserverrechner 106 übermittelt wird (vgl. Nachrichtenflussdiagramm 600 in 6).
Der PoC-Steuerserverrechner 106 leitet die Anforderung an den ersten Teilnehmer T1 weiter, da der erste Teilnehmer T1 Moderator der Kommunikationssitzung ist. Dies geschieht, indem der PoC-Steuerserverrechner 106 eine vierte Chair_TB_Request_Nachricht 602 erzeugt und an die erste PoC-Client-Einheit 101 übermittelt. Die vierte Chair_TB_Request_Nachricht 602 dient anschaulich zur Anforderung des Kommunikationsrechts vom Moderator zu dem mit der Kommunikationsfluss-Identifikationsangabe mit dem Wert 0 (ID 0) identifizierten Kommunikationsfluss.
Es wird ferner angenommen, dass der erste Teilnehmer T1 der Ansicht ist, dass der von dem zweiten Teilnehmer T2 eingebrachte Rede-Beitrag und damit auch die darauf bezogenen Redebeiträge weniger wichtig sind und entzieht daher dem zweiten Teilnehmer T2 bzw. der zweiten PoC-Client-Einheit 102 seinen Kommunikationsfluss, anders ausgedrückt, das ihr zugeordnete Kommunikationsrecht. Dazu erzeugt die erste PoC-Client-Einheit 101 eine Chair_Thread_Revoke-Nachricht 603 zur Beendigung des mit der Kommunikationsfluss-Identifikationsangabe mit dem Wert 3 (ID 3) identifizierten Kommunikationsflusses und übermittelt die Chair_Thread_Revoke-Nachricht 603 an den PoC-Steuerserverrechner 106.
Der PoC-Steuerserverrechner 106 bricht nun den gerade stattfindenden Rede-Beitrag des vierten Teilnehmers T4 ab, da der Beitrag zu dem zu beendenden Kommunikationsfluss gehört. Dies geschieht, indem der PoC-Steuerserverrechner 106 eine erste TB_Revoke-Nachricht 604 erzeugt und an die vierte PoC-Client-Einheit 108 übermittelt. Danach leitet der PoC-Steuerserverrechner 106 keine weiteren Rederecht-Anforderungen mit Verweis auf den ersten Rede-Beitrag von dem zweiten Teilnehmer T2 mehr an die zweite PoC-Client-Einheit 102 und damit an den zweiten Teilnehmer T2 weiter.
Der erste Teilnehmer T1 und damit die erste PoC-Client-Einheit 101 genehmigt das Rederecht für den dritten Teilnehmer T3, indem die erste PoC-Client-Einheit 101 eine vierte Chair_TB_Granted_Nachricht 605 zur Genehmigung des Kommunikationsrechts zum Kommunikationsfluss mit der ID mit dem Wert 0 (ID 0) erzeugt und an den PoC-Steuerserverrechner 106 übermittelt.
Auf den Empfang der vierten Chair_TB_Granted_Nachricht 605 hin erzeugt der PoC-Steuerserverrechner 106 eine vierte TB_Granted_Nachricht 606 und übermittelt diese an die dritte PoC-Client-Einheit 103 und damit an den dritten Teilnehmer T3. Die vierte TB_Granted_Nachricht 606 dient somit zur Genehmigung des Kommunikationsrechts zum Kommunikationsfluss mit einer Kommunikationsfluss-Identifikationsangabe ID 0 (erste Ziffer in Klammern in der vierten TB_Granted_Nachricht 606 von 6) mit der Mitteilung, dass der durch den genehmigten Kommunikations-Beitrag erzeugte Kommunikationsfluss eine fünfte Kommunikationsfluss-Identifikationsangabe ID mit dem Wert 4 hat (zweite Ziffer in Klammern in der vierten TB_Granted_Nachricht 606 von 6).
Außerdem benachrichtigt der PoC-Steuerserverrechner 106 alle anderen Teilnehmer außer den dritten Teilnehmer T3 mittels einer jeweiligen TB_Taken_Nachricht 607, 608, 609 darüber, dass das Rederecht (symbolisiert in 6 mit Bezugszeichen 610) vergeben wurde. Ferner dienen die TB_Taken_Nachrichten 607, 608, 609 dazu, die Teilnehmer darüber zu informieren, dass der dadurch vergebene Kommunikationsfluss die ID bekommen hat, die in der Kommunikationsfluss-Identifikationsangabe der jeweiligen TB_Taken_Nachricht 607, 608, 609 angegeben ist.
Im Detail erzeugt der PoC-Steuerserverrechner 106

• eine zehnte TB_Taken_Nachricht 607 und übermittelt diese an die erste PoC-Client-Einheit 101 und damit an den ersten Teilnehmer T1,
• eine elfte TB_Taken Nachricht 608 und übermittelt diese an die zweite PoC-Client-Einheit 102 und damit an den zweiten Teilnehmer T2,
• eine zwölfte TB_Taken_Nachricht 609 und übermittelt diese an die vierte PoC-Client-Einheit 108 und damit an den vierten Teilnehmer T4.

Die folgende Tabelle 22 zeigt beispielhaft das Format einer Chair_Thread_Revoke-Nachricht als RTCP-Nachricht zur Beendigung eines Kommunikationsflusses durch den Moderator des übergeordneten Kommunikationsflusses:
Tabelle 22: Chair_Thread_Revoke
Die Felder der in Tabelle 22 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• subtype: Subtyp der Nachricht, der die Nachricht als "Chair_Thread_Revoke"-Nachricht identifiziert;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des Teilnehmerendgerätes des Moderators, der den Kommunikationsfluss beendet; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den zu der RTCP-Nachricht gehörenden RTP-Paketen definiert;
• Name=PoC1: Applikations-definierter Nachrichten-Name (PoC1 = PTT over Cellular Version 1);
• Reason Code: Code zur Identifizierung eines Beendigungs-Grundes;
• Length: Länge des "reason Phrase"-Feldes in Bytes;
• Reason Phrase: Erläuterung der Beendigung als Text;
• Thread ID: Identifikator des Kommunikationsflusses, der beendet werden soll.

Nun gibt der dritte Teilnehmer T3 seinen Rede-Beitrag ab, woraufhin der vierte Teilnehmer T4 mit Bezug auf den dritten Teilnehmer T3 das Rederecht anfordert und von dem dritten Teilnehmer T3 genehmigt bekommt. Dies geschieht, indem die vierte PoC-Client-Einheit 108 eine fünfte TB_Request-Nachricht 701 zur Anforderung des Kommunikationsrechts zum Kommunikationsfluss mit der ID 4 vom PoC-Steuerserverrechner 106 erzeugt und an den PoC-Steuerserverrechner 106 übermittelt (siehe Nachrichtenflussdiagramm 700 in 7).
Ferner erzeugt der PoC-Steuerserverrechner 106 auf den Empfang der fünften TB_Request-Nachricht 701 hin eine fünfte Chair_TB_Request_Nachricht 702 zur Anforderung des Kommunikationsrechts zum Kommunikationsfluss mit der ID 4 vom Moderator und übermittelt diese an die dritte PoC-Client-Einheit 103, welche für diesen Kommunikationsfluss als Moderator fungiert, da sie diesen Kommunikationsfluss erzeugt hat. Die dritte PoC-Client-Einheit 103 genehmigt das angeforderte Kommunikationsrecht mittels einer von ihr erzeugten und an den PoC-Steuerserverrechner 106 übermittelten fünften Chair_TB_Granted_Nachricht 703 zur Genehmigung des Kommunikationsrechts zum Kommunikationsfluss mit der ID 4 vom Moderator.
Auf den Empfang der fünften Chair_TB_Granted_Nachricht 703 hin erzeugt der PoC-Steuerserverrechner 106 eine fünfte TB_Granted_Nachricht 704 und übermittelt diese an die vierte PoC-Client-Einheit 108 und damit an den vierten Teilnehmer T4. Die fünfte TB_Granted_Nachricht 704 dient somit zur Genehmigung des Kommunikationsrechts zum Kommunikationsfluss mit der fünften Kommunikationsfluss-Identifikationsangabe ID 4 (erste Ziffer in Klammern in der fünften TB_Granted_Nachricht 704 von 7) mit der Mitteilung, dass der durch den genehmigten Kommunikations-Beitrag erzeugte Kommunikationsfluss eine sechste Kommunikationsfluss-Identifikationsangabe ID mit dem Wert 5 (ID 5) hat (zweite Ziffer in Klammern in der fünften TB_Granted_Nachricht 704 von 7).
Außerdem benachrichtigt der PoC-Steuerserverrechner 106 alle anderen Teilnehmer außer den vierten Teilnehmer T4 mittels einer jeweiligen TB_Taken_Nachricht 705, 706, 707 darüber, dass das Rederecht (symbolisiert in 7 mit Bezugszeichen 708) vergeben wurde. Ferner dienen die TB_Taken_Nachrichten 705, 706, 707 dazu, die Teilnehmer darüber zu informieren, dass der dadurch vergebene Kommunikationsfluss die ID bekommen hat, die in der Kommunikationsfluss-Identifikationsangabe der jeweiligen TB_Taken_Nachricht 705, 706, 707 angegeben ist.
Im Detail erzeugt der PoC-Steuerserverrechner 106

• eine dreizehnte TB_Taken_Nachricht 705 und übermittelt diese an die erste PoC-Client-Einheit 101 und damit an den ersten Teilnehmer T1,
• eine vierzehnte TB_Taken_Nachricht 706 und übermittelt diese an die zweite PoC-Client-Einheit 102 und damit an den zweiten Teilnehmer T2,
• eine fünfzehnte TB_Taken_Nachricht 707 und übermittelt diese an die dritte PoC-Client-Einheit 103 und damit an den dritten Teilnehmer T3.

Nach einer Weile ist der dritte Teilnehmer T3 der Ansicht, dass der vierte Teilnehmer T4 alles Wichtige zu dem Kommunikations-Beitrag gesagt hat und beendet daher den Kommunikationsfluss. Dazu erzeugt der dritte Teilnehmer T3 eine Thread Release-Nachricht 709 zur Beendigung des Kommunikationsflusses mit der ID 4 durch den Moderator des Kommunikationsflusses und übermittelt diese an den PoC-Steuerserverrechner 106.
Die folgende Tabelle 23 zeigt beispielhaft das Format einer Thread Release-Nachricht als RTCP-Nachricht zur Beendigung eines Kommunikationsflusses durch den Moderator des Kommunikationsflusses:
Tabelle 23: Thread Release
Die Felder der in Tabelle 23 dargestellten RTCP-Nachricht bedeuten im Einzelnen:

• V=2: RTP-Versions-Nummer;
• P: Indikator für Padding;
• subtype: Subtyp der Nachricht, der die Nachricht als "Thread Release"-Nachricht identifiziert;
• PT=APP=204: Indikator für Applikations-definierte RTCP-Nachricht;
• Length: Länge der Nachricht nach dem length-Feld in Wörtern (32Bit);
• SSRC: Synchronisation Source des Teilnehmerendgeräts, das seinen Kommunikationsfluss beendet; die SSRC identifiziert den Sender von Medien-Strömen eindeutig; sie wird in den zu der RTCP-Nachricht gehörenden RTP-Paketen definiert;
• Name=PoC1: Applikations-definierter Nachrichten-Name (PoC1 = PTT over Cellular Version 1);
• Thread ID: Identifikator des Kommunikationsflusses, der beendet werden soll.

Der PoC-Steuerserverrechner 106 entzieht auf den Empfang der Thread Release-Nachricht 709 dem vierten Teilnehmer T4 das Rederecht mittels einer von dem PoC-Steuerserverrechner 106 erzeugten und an die vierte PoC-Client-Einheit 108 übermittelten zweiten TB_Revoke-Nachricht 710 zum Entzug des Kommunikationsrechts für den Beitrag, der den Kommunikationsfluss mit der ID 5 erzeugt hat.
Ferner informiert der PoC-Steuerserverrechner 106 die anderen Teilnehmer T1, T2, T3 darüber, dass das Kommunikationsrecht nicht mehr vergeben ist und damit darüber, dass der Kommunikations-Beitrag, der den Kommunikationsfluss mit der ID 5 erzeugt hat, beendet wurde. Hierfür erzeugt der PoC-Steuerserverrechner 106 für jeden zu informierenden Teilnehmer T1, T2, T3 jeweils eine TB_Idle-Nachricht 711, 712, 713 und versendet diese an den jeweiligen Teilnehmer T1, T2, T3.
Im Detail erzeugt der PoC-Steuerserverrechner 106

• eine vierte TB_Idle-Nachricht 711 und übermittelt diese an die erste PoC-Client-Einheit 101 und damit an den ersten Teilnehmer T1,
• eine fünfte TB_Idle-Nachricht 712 und übermittelt diese an die zweite PoC-Client-Einheit 102 und damit an den zweiten Teilnehmer T2,
• eine sechste TB_Idle-Nachricht 713 und übermittelt diese an die dritte PoC-Client-Einheit 103 und damit an den dritten Teilnehmer T3.

Im Folgenden werden zu obigen Ausführungsbeispielen einige alternative Ausführungsformen aufgezeigt.
Für den Kommunikationsfluss der Kommunikationssitzung kann auch eine andere Default-Identifikationsangabe (Default-ID) verwendet werden als der Wert "0".
Das Kommunikationsrecht kann auch mit Bezug auf einen eigenen Beitrag angefordert werden. Dies bedeutet, ein Teilnehmer kann das Kommunikationsrecht zu einem Kommunikationsfluss anfordern, den er selbst moderiert.
Die Kommunikationsrecht-Kontrolle kann auch maschinell, das heißt automatisch, erfolgen. Der Moderator ist in diesem Fall keine Person, sondern ein entsprechend eingerichtetes Gerät. Das Gerät vergibt das Kommunikationsrecht automatisch, beispielsweise unter Verwendung einer oben beschriebenen Warteschlange und/oder mit einer vorgebbaren maximalen Kommunikationszeit.
Ferner kann vorgesehen sein, dass auch zugelassen ist, mehrere Kommunikationsrechte zu verschiedenen Kommunikationsflüssen durch einen Teilnehmer anzufordern. Der Teilnehmer ist dann mehrfacher Moderator (für die Kommunikationsflüsse seiner Beiträge). Wenn es nicht zugelassen ist, mehrere Kommunikationsrechte anzufordern, dann ist die Kommunikationsfluss-ID in den Grant-Nachrichten überflüssig, und für diese Nachrichten können Formate ohne eine ID verwendet werden.
Es kann ferner vorgesehen sein, dass der Moderator eines Kommunikationsflusses automatisch das Kommunikationsrecht für seinen eigenen Kommunikationsfluss erhält, wenn kein anderer Teilnehmer das Kommunikationsrecht für den Kommunikationsfluss hat. Die automatische Kommunikationsrechtsvergabe kann beispielsweise im PTT-Server oder im Endgerät des Moderators realisiert sein. Wenn die Vergabe im PTT-Server realisiert ist, vergibt der Server das Kommunikationsrecht automatisch mit einer TB_Granted-Nachricht an den Moderator. Wenn die Vergabe im Endgerät des Moderators realisiert ist, vergibt die Endgeräte-Applikation das Kommunikationsrecht automatisch an den Moderator, indem sie eine entsprechende Chair_TB_Granted-Nachricht an den PTT-Server versendet. Der PTT-Server leitet die Nachricht wie im obigen Beispiel als TB_Granted_Nachricht an den Moderator als Kommunikationsteilnehmer weiter.
Die Kommunikationsfluss-Identifikationsangabe kann auch mit Kommunikationskontroll-Nachrichten verwendet werden, die keine Kommunikationsfluss-Identifikationsangaben enthalten. Diese Nachrichten beziehen sich dann immer auf den Kommunikationsfluss der PTT-Sitzung. Dadurch werden die Ausführungsformen der Erfindung mit den bisherigen beispielsweise in [2] für PTT-Systeme definierten Kommunikationskontroll-Nachrichten kompatibel. Außerdem spart der Einsatz von Kommunikationskontroll-Nachrichten ohne Kommunikationsfluss-Identifikationsangaben Übertragungsbandbreite.
Es kann auch vorgesehen sein, die Identifikationsangabe eines neuen Kommunikationsflusses mit dem Kommunikations-Beitrag zu versenden, der den Kommunikationsfluss initiiert. Dann ist es nicht mehr erforderlich, die Identifikationsangabe des neuen Kommunikationsflusses mit einer TB_Taken-Nachricht allen Teilnehmern, die den Kommunikations-Beitrag empfangen, mitzuteilen.
Die Kommunikationsrechtskontroll-Nachrichten können auch mit anderen Protokollen als mit RTCP versendet werden, beispielsweise mit dem Binary Floor Control Protocol (BFCP), wie es in [1] beschrieben ist, oder mit Erweiterungen oder Weiterentwicklungen davon.
Die Erfindung kann nicht nur in einem PTT-System zur Übertragung von Audiodaten eingesetzt werden, sondern auch in Systemen zur Übertragung anderer Daten, insbesondere Mediendaten wie beispielsweise Videodaten, Standbilddaten, textuelle Daten, etc.
Die Erfindung kann nicht nur in einem PTT-System eingesetzt werden, sondern auch in anderen Systemen mit Kommunikationsrechts-Kontrolle, insbesondere allgemein in jedem Konferenz-Kommunikationssystem.
In diesem Dokument sind folgende Veröffentlichungen zitiert:

[1] G. Camarillo, XCON Working Group, IETF Internet-Draft, The Binary Floor Control Protocol (BFCP), im Internet erhältlich unter der URL-Adresse: http://vesuvio.ipv6.cselt.it/internet-drafts/draft-ietf-xcon-bfcp-04.txt;
[2] Open Mobile Alliance, PoC User Plane Version 1.0, Candidate Version 1.0, OMA-TS PoC-UserPlane-V1 0-20050428-C, April 2005;
[3] H. Schulzrinne et al, Network Working Group, Request for Comments 3550, RTP: a Transport Protocol for Real-Time Applications, Juli 2003;
[4] J. Rosenberg et al, SIPPING, Internet Draft, A Session Initiation Protocol (SIP) Event Package for Conference State, draft-ietf-sipping-conference-package-06 im Internet erhältlich unter der URL-Adresse: http://tools.ietf.org/wg/sipping/draft-ietf-sipping-conference-package/draft-ietf-sipping-conference-package- 06.txt
[5] J. Rosenberg, IETF Internet-Draft, A Framework for Conferencing with the Session Initiation Protocol, draft-ietf-sipping-conferencing-framework-00.txt, Mai 2003;
[6] Open Mobile Alliance, Push to talk over Cellular (PoC) – Architecture, Candidate Version 1.0, OMA-AD PoC-V1 0-20050428-C, April 2005;
[7] Push-to-Talk over Cellular (PoC) User Plane; Transport Protocols; PoC Release 1.0 – (http://www.siemens-mobile.com/repository/38/3888/Push_to_talk_over_Cellular_PoC.zip)
[8] DE 10 2004 041 884 A1

100: PoC-Kommunikationssystem
101: erste PoC-Client-Einheit
102: zweite PoC-Client-Einheit
103: dritte PoC-Client-Einheit
104: Schnittstelle
105: PoC-Teilnehmerserverrechner
106: PoC-Steuerserverrechner
107: Chair
108: vierte PoC-Client-Einheit
200: Nachrichtenflussdiagramm
201: erste PoC-Client-Einheit
202: PoC-Steuerserverrechner
203: Chair
204: zweite PoC-Client-Einheit
205: Verfahrensschritt
206: Verfahrensschritt
207: Verfahrensschritt
208: Verfahrensschritt
209: Verfahrensschritt
210: Verfahrensschritt
211: Verfahrensschritt
212: Verfahrensschritt
213: Verfahrensschritt
214: Verfahrensschritt
215: Verfahrensschritt
216: Verfahrensschritt
217: Verfahrensschritt
218: Verfahrensschritt
220: Talk_Burst_Request-Nachricht
221: Chair_Talk_Burst_Request-Nachricht
222: Chair_Talk_Burst_Confirm_Response-Nachricht
223: Talk_Burst_Confirm_Response-Nachricht
224: Receiving_Talk_Burst_Indication-Nachricht
225: Talk-Burst-Request-Nachricht
226: Chair_Talk_Burst_Confirm_Response-Nachricht
227: Stop_Talk_Burst_Indication-Nachricht
228: Talk_Burst_Confirm_Response-Nachricht
229: Receiving_Talk_Burst_Indication-Nachricht
230: Chair_Priorities_Indication-Nachricht
231: Chair_Talk_Burst_Request-Nachricht
300: Nachrichtenflussdiagramm
301: erste PoC-Client-Einheit
302: PoC-Steuerserverrechner
303: Chair
304: zweite PoC-Client-Einheit
305: Verfahrensschritt
306: Verfahrensschritt
307: Verfahrensschritt
308: Verfahrensschritt
309: Verfahrensschritt
310: Verfahrensschritt
311: Verfahrensschritt
312: Verfahrensschritt
313: Verfahrensschritt
314: Verfahrensschritt
315: Verfahrensschritt
316: Verfahrensschritt
317: Verfahrensschritt
320: Talk_Burst_Confirm_Response-Nachricht
321: Talk_Burst_Request-Nachricht
322: Chair_Talk_Burst_Request_Queueing-Nachricht
323: Chair_Talk_Burst_Request_Queued_Response-Nachricht
324: Chair_Priorities_Indication-Nachricht
325: Talk_Burst_Request-Nachricht
326: Receiving_Talk_Burst_Indication-Nachricht
327: Talk_Burst_Request_Queued_Response-Nachricht
328: Talk_Burst_Completed_Indication-Nachricht
329: Talk_Burst_Confirm_Response-Nachricht
330: Receiving_Talk_Burst_Indication-Nachricht
400: Nachrichtenflussdiagramm
401: erste TB_Request-Nachricht
402: erste Chair_TB_Request_Nachricht
403: erste Chair_TB_Granted_Nachricht
404: erste TB_Granted_Nachricht
405: erste TB_Taken_Nachricht
406: zweite TB_Taken_Nachricht
407: dritte TB_Taken_Nachricht
408: Rederecht
409: erste TB_Release_Nachricht
410: erste TB_Idle-Nachricht
411: zweite TB_Idle-Nachricht
412: dritte TB_Idle-Nachricht
500: Nachrichtenflussdiagramm
501: zweite TB_Request-Nachricht
502: dritte TB_Request-Nachricht
503: zweite Chair_TB_Request_Nachricht
504: dritte Chair_TB_Request_Nachricht
505: zweite Chair_TB_Granted_Nachricht
506: zweite TB_Granted_Nachricht
507: vierte TB_Taken_Nachricht
508: fünfte TB_Taken_Nachricht
509: sechste TB_Taken_Nachricht
510: Rederecht
511: zweite TB_Release_Nachricht
512: erste Chair_TB_Release-Nachricht
513: dritte Chair_TB_Granted_Nachricht
514: dritte TB_Granted_Nachricht
515: siebte TB_Taken_Nachricht
516: achte TB_Taken_Nachricht
517: neunte TB_Taken_Nachricht
518: Rederecht
600: Nachrichtenflussdiagramm
601: vierte TB_Request-Nachricht
602: vierte Chair_TB_Request_Nachricht
603: Chair_Thread_Revoke-Nachricht
604: erste TB_Revoke-Nachricht
605: vierte Chair_TB_Granted_Nachricht
606: vierte TB_Granted_Nachricht
607: zehnte TB_Taken_Nachricht
608: elfte TB_Taken_Nachricht
609: zwölfte TB_Taken_Nachricht
610: Rederecht
700: Nachrichtenflussdiagramm
701: fünfte TB_Request-Nachricht
702: fünfte Chair_TB_Request_Nachricht
703: fünfte Chair_TB_Granted_Nachricht
704: fünfte TB_Granted_Nachricht
705: dreizehnte TB_Taken_Nachricht
706: vierzehnte TB_Taken_Nachricht
707: fünfzehnte TB_Taken_Nachricht
708: Rederecht
709: Thread_Release-Nachricht
710: zweite TB_Revoke-Nachricht
711: vierte TB_Idle-Nachricht
712: fünfte TB_Idle-Nachricht
713: sechste TB_Idle-Nachricht

Claims

Verfahren zum rechnergestützten Vergeben eines Kommunikationsrechts in einer Kommunikations-Konferenz zwischen mehreren Kommunikations-Endgeräten an mindestens ein Kommunikations-Endgerät, • wobei die Kommunikations-Konferenz mindestens einen anhand eines vorangegangenen Kommunikations-Beitrags eindeutig identifizierbaren Konferenz-Nachrichtenfluss aufweist, • wobei das Kommunikationsrecht innerhalb der Kommunikations-Konferenz vergeben wird unter Berücksichtigung des Konferenz-Nachrichtenflusses.
Verfahren gemäß Anspruch 1, wobei der mindestens eine Konferenz-Nachrichtenfluss mindestens einen Beitrag aufweist, der sich auf die Kommunikations-Konferenz oder auf einen anderen Beitrag in der Kommunikations-Konferenz bezieht.
Verfahren gemäß Anspruch 1 oder 2, • wobei die Kommunikations-Konferenz mehrere eindeutig identifizierbare Konferenz-Nachrichtenflüsse aufweist, • wobei das Kommunikationsrecht innerhalb der Kommunikations-Konferenz vergeben wird unter Berücksichtigung mindestens eines Konferenz-Nachrichtenflusses der mehreren Konferenz-Nachrichtenflüsse.
Verfahren gemäß einem der Ansprüche 1 bis 3, wobei das Kommunikationsrecht vergeben wird unter Berücksichtigung einer Kommunikationsrecht-Anforderungsnachricht.
Verfahren gemäß Anspruch 4, wobei mindestens eine Kommunikationsrecht-Anforderungsnachricht empfangen wird.
Verfahren gemäß Anspruch 4 oder 5, wobei die mindestens eine Kommunikationsrecht-Anforderungsnachricht eine Identifikations-Angabe enthält zum Identifizieren des Konferenz-Nachrichtenflusses, im Rahmen dessen ein Kommunikationsrecht angefordert wird.
Verfahren gemäß einem der Ansprüche 1 bis 6, wobei als Kommunikations-Konferenz eine Kommunikationssitzung-basierte Kommunikations-Konferenz verwendet wird.
Verfahren gemäß einem der Ansprüche 1 bis 7, wobei als Kommunikations-Konferenz eine Internet-basierte Kommunikations-Konferenz verwendet wird.
Verfahren gemäß einem der Ansprüche 1 bis 8, wobei als Kommunikations-Konferenz eine Push-to-Talk-Kommunikations-Konferenz verwendet wird.
Verfahren gemäß Anspruch 9, wobei als Kommunikations-Konferenz eine Push-to-Talk over Cellular-Kommunikations-Konferenz verwendet wird.
Verfahren gemäß einem der Ansprüche 4 bis 10, wobei die Kommunikationsrecht-Anforderungsnachricht gemäß einem Kommunikationsrecht-Vergabe-Protokoll codiert wird.
Verfahren gemäß Anspruch 11, wobei die Kommunikationsrecht-Anforderungsnachricht gemäß dem Binary Floor Control Protocol codiert wird.
Verfahren gemäß einem der Ansprüche 4 bis 11, wobei die Kommunikationsrecht-Anforderungsnachricht gemäß einem Steuerungsprotokoll zum Steuern eines Mediendaten-Übertragungs-Protokolls codiert wird.
Verfahren gemäß Anspruch 13, wobei die Kommunikationsrecht-Anforderungsnachricht gemäß einem Echtzeit-Steuerungsprotokoll zum Steuern eines Echtzeit-Mediendaten-Übertragungs-Protokolls codiert wird.
Verfahren gemäß Anspruch 14, wobei die Kommunikationsrecht-Anforderungsnachricht gemäß dem Real-Time Transport Control Protocol codiert wird.
Verfahren gemäß einem der Ansprüche 1 bis 15, wobei das Kommunikationsrecht innerhalb der Kommunikations-Konferenz vergeben wird von dem Moderator des Konferenz-Nachrichtenflusses.
Verfahren gemäß Anspruch 16, wobei das Kommunikationsrecht innerhalb der Kommunikations-Konferenz vergeben wird von dem Initiator des Konferenz-Nachrichtenflusses.
Verfahren gemäß Anspruch 17, wobei das Kommunikationsrecht innerhalb der Kommunikations-Konferenz vergeben wird von dem Teilnehmer, der den Beitrag gemacht hat, auf den sich die Beiträge des Konferenz-Nachrichtenflusses beziehen.
Verfahren gemäß Anspruch 18, wobei der Konferenz-Nachrichtenfluss beendet wird von dem Initiator des Konferenz-Nachrichtenflusses.
Verfahren zum rechnergestützten Erzeugen einer Kommunikations-Konferenz-Nachricht in einer Kommunikations-Konferenz zwischen mehreren Kommunikations-Endgeräten, wobei der Kommunikations-Konferenz-Nachricht eine Identifikationsangabe eines Konferenz-Nachrichtenflusses innerhalb der Kommunikations-Konferenz hinzugefügt wird zur eindeutigen Identifizierung des Konferenz-Nachrichtenflusses anhand eines vorangegangenen Kommunikations-Beitrags.
Verfahren gemäß Anspruch 20, wobei die Kommunikations-Konferenz-Nachricht eine Kommunikationsrecht-Anforderungsnachricht ist zum Anfordern eines Kommunikationsrechts.
Verfahren gemäß Anspruch 20, wobei die Kommunikations-Konferenz-Nachricht eine Nachrichtenfluss-Kommunikationsrecht-Genehmigungsnachricht ist, wobei mit der Nachrichtenfluss-Kommunikationsrecht-Genehmigungsnachricht angegeben wird, dass in dem Nachrichtenfluss das Kommunikationsrecht genehmigt wurde.
Verfahren gemäß Anspruch 20, wobei die Kommunikations-Konferenz-Nachricht eine Nachrichtenfluss-Beendigungsnachricht ist zum Beenden des Konferenz-Nachrichtenflusses.
Verfahren gemäß Anspruch 24, wobei die Nachrichtenfluss-Beendigungsnachricht von dem Moderator des Konferenz-Nachrichtenflusses erzeugt wird.
Verfahren gemäß Anspruch 20, wobei die Kommunikations-Konferenz-Nachricht eine Nachrichtenfluss-Kommunikationsrecht-Entziehungsnachricht ist zum Entziehen des Kommunikationsrechts in dem Nachrichtenfluss.
Verfahren gemäß Anspruch 25, wobei die Nachrichtenfluss-Kommunikationsrecht-Entziehungsnachricht von dem Moderator des Konferenz-Nachrichtenflusses erzeugt wird.
Verfahren gemäß Anspruch 20, wobei die Kommunikations-Konferenz-Nachricht eine Kommunikationsrecht-Vergeben-Nachricht ist, wobei mit der Kommunikationsrecht-Vergeben-Nachricht angegeben wird, dass das Kommunikationsrecht vergeben wurde.
Verfahren gemäß einem der Ansprüche 20 bis 27, wobei der mindestens eine Konferenz-Nachrichtenfluss mindestens einen Beitrag aufweist, der sich auf die Kommunikations-Konferenz oder auf einen anderen Beitrag in der Kommunikations-Konferenz bezieht.
Verfahren gemäß Anspruch 20 und 28, wobei die Kommunikations-Konferenz-Nachricht eine Kommunikations-Beitrag-Freigegeben-Nachricht ist, wobei mit der Kommunikations-Beitrag-Freigegeben-Nachricht angegeben wird, dass das Kommunikationsrecht hinsichtlich des Kommunikations-Beitrags nicht vergeben ist.
Verfahren gemäß Anspruch 20 und 28, wobei die Kommunikations-Konferenz-Nachricht eine Kommunikations-Beitrag-Beendigungsnachricht ist zum Beenden des Kommunikations-Beitrags.
Verfahren gemäß Anspruch 20 und 27, wobei die Kommunikations-Konferenz-Nachricht eine Kommunikations-Beitrag-Kommunikationsrecht-Entziehungsnachricht ist zum Entziehen des Kommunikationsrechts in dem Kommunikations-Beitrag.
Verfahren gemäß einem der Ansprüche 20 bis 31, wobei die Kommunikations-Konferenz-Nachricht gemäß einem Kommunikationsrecht-Vergabe-Protokoll codiert wird.
Verfahren gemäß Anspruch 32, wobei die Kommunikations-Konferenz-Nachricht gemäß dem Binary Floor Control Protocol codiert wird.
Verfahren gemäß einem der Ansprüche 20 bis 32, wobei die Kommunikations-Konferenz-Nachricht gemäß einem Steuerungsprotokoll zum Steuern eines Mediendaten-Übertragungs-Protokolls codiert wird.
Verfahren gemäß Anspruch 34, wobei die Kommunikations-Konferenz-Nachricht gemäß einem Echtzeit-Steuerungsprotokoll zum Steuern eines Echtzeit-Mediendaten-Übertragungs-Protokolls codiert wird.
Verfahren gemäß Anspruch 35, wobei die Kommunikations-Konferenz-Nachricht gemäß dem Real-Time Transport Control Protocol codiert wird.
Kommunikationsrecht-Vergabe-Einheit zum Vergeben eines Kommunikationsrechts in einer Kommunikations-Konferenz zwischen mehreren Kommunikations-Endgeräten an mindestens ein Kommunikations-Endgerät, • wobei die Kommunikations-Konferenz mindestens einen anhand eines vorangegangenen Kommunikations-Beitrags eindeutig identifizierbaren Konferenz-Nachrichtenfluss aufweist, • wobei die Kommunikationsrecht-Vergabe-Einheit derart eingerichtet ist, dass das Kommunikationsrecht innerhalb der Kommunikations-Konferenz vergeben wird unter Berücksichtigung des Konferenz-Nachrichtenflusses.
Kommunikations-Konferenz-Servereinheit mit einer Kommunikationsrecht-Vergabe-Einheit gemäß Anspruch 37.
Kommunikations-Konferenz-Nachricht-Erzeugungseinheit, eingerichtet zum rechnergestützten Erzeugen einer Kommunikations-Konferenz-Nachricht in einer Kommunikations-Konferenz zwischen mehreren Kommunikations-Endgeräten, wobei der Kommunikations-Konferenz-Nachricht eine Identifikationsangabe eines Konferenz-Nachrichtenflusses innerhalb der Kommunikations-Konferenz hinzugefügt werden kann zur eindeutigen Identifizierung des Konferenz-Nachrichtenflusses anhand eines vorangegangenen Kommunikations-Beitrags.
Kommunikations-Endgerät mit einer Kommunikations-Konferenz-Nachricht-Erzeugungseinheit gemäß Anspruch 39.
Verfahren zum rechnergestützten Initialisieren eines Konferenz-Nachrichtenflusses in einer Kommunikations-Konferenz zwischen mehreren Kommunikations-Endgeräten, • wobei ein Konferenz-Nachrichtenfluss erzeugt wird in der Kommunikations-Konferenz, • wobei dem Konferenz-Nachrichtenfluss eine eindeutige Identifikationsangabe zugeordnet wird zur eindeutigen Identifikation des Nachrichtenflusses innerhalb der Kommunikations-Konferenz anhand eines vorangegangenen Kommunikations-Beitrags.