DE102004049907A1 - Verfahren zum Anfordern oder Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Erfragen oder Mitteilen von Warteschlangeninformation, Push-to-talk-Client-Einheit, Push-to-talk-Steuerserverrechner und Entscheidungseinheit - Google Patents

Verfahren zum Anfordern oder Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Erfragen oder Mitteilen von Warteschlangeninformation, Push-to-talk-Client-Einheit, Push-to-talk-Steuerserverrechner und Entscheidungseinheit Download PDF

Info

Publication number
DE102004049907A1
DE102004049907A1 DE102004049907A DE102004049907A DE102004049907A1 DE 102004049907 A1 DE102004049907 A1 DE 102004049907A1 DE 102004049907 A DE102004049907 A DE 102004049907A DE 102004049907 A DE102004049907 A DE 102004049907A DE 102004049907 A1 DE102004049907 A1 DE 102004049907A1
Authority
DE
Germany
Prior art keywords
push
talk
queue
client unit
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE102004049907A
Other languages
English (en)
Inventor
Norbert Schwagmann
Andreas Schmidt
Holger Schmidt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Deutschland GmbH
Original Assignee
Infineon Technologies AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infineon Technologies AG filed Critical Infineon Technologies AG
Priority to DE102004049907A priority Critical patent/DE102004049907A1/de
Priority to CNA2005100034598A priority patent/CN1819671A/zh
Priority to CN2012102118494A priority patent/CN102710662A/zh
Priority to US11/252,361 priority patent/US7769403B2/en
Publication of DE102004049907A1 publication Critical patent/DE102004049907A1/de
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/10—Push-to-Talk [PTT] or Push-On-Call services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H04W76/45—Connection management for selective distribution or broadcast for Push-to-Talk [PTT] or Push-to-Talk over cellular [PoC] services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Es wird ein Push-to-talk-Kommunikationssystem beschrieben, bei dem zur Zuteilung des Sprachrechts im Rahmen einer Push-to-talk-Kommunikation eine Entscheidungseinheit (Chair) und/oder eine Warteschlange vorgesehen sind und entsprechende Steuernachrichten, Anforderungsnachrichten und Informationsnachrichten übertragen werden.

Description

  • Verfahren zum Anfordern oder Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Erfragen oder Mitteilen von Warteschlangeninformation, Push-to-talk-Client-Einheit, Pushto-talk-Steuerserverrechner und Entscheidungseinheit Die Erfindung betrifft ein Verfahren zum Anfordern eines Push-to-talk-Sprachrechts und/oder zum Erfragen von Warteschlangeninformation, ein Verfahren zum Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Mitteilen von Warteschlangeninformation, eine Push-to-talk-Client-Einheit, einen Push-to-talk-Steuerserverrechner und eine Entscheidungseinheit.
  • Der Kommunikationsdienst Push-to-talk-over-Cellular (PoC) ermöglicht es einem Benutzer eines Mobilfunk-Teilnehmergeräts, Sprachdaten an einen oder mehrere Empfänger gleichzeitig zu übermitteln.
  • Dazu ist typischerweise eine spezielle PoC-Taste an dem Mobilfunk-Teilnehmergerät vorgesehen, nach deren Betätigung der Benutzer mit dem Einsprechen von Sprachdaten beginnen kann.
  • Die Sprachdaten werden üblicherweise schon während des Einsprechens mittels eines Mobilfunk-Kommunikationsnetzwerks verteilt, das heißt an den oder die gewünschten Empfänger übermittelt. Dieser Vorgang wird als "streaming" bezeichnet.
  • Die Übermittlung erfolgt im Halb-Duplex-Verfahren, das heißt, dass während des Einsprechens und während der Übertragung nur der Sender, das heißt der Benutzer, der die Sprachdaten einspricht und versendet, Sprachdaten an die Empfänger übermitteln kann, die Empfänger aber nicht gleichzeitig Sprachdaten an den Sender senden können. Insbesondere kann der Sender nicht von den Empfängern unterbrochen werden.
  • Anschaulich entspricht eine Kommunikation mittels PoC aus Sicht des Benutzers dem herkömmlichen CB-Funk, jedoch mit der Erweiterung, dass der Sender weltweit an Empfänger, die mittels der geeigneten Vermittlungstechnik mindestens eines Mobilfunk-Kommunikationsnetzwerks erreichbar sind, Sprachdaten übermitteln kann.
  • Möchte ein Benutzer von PoC öfter Sprachnachrichten an dieselben Empfänger senden, so wird es ihm bei PoC ermöglicht, persönliche, feste Benutzergruppen zu definieren. Beispielsweise kann ein Benutzer von PoC eine Gruppe mit der Bezeichnung "Freunde" definieren, die entsprechende Mitglieder und deren jeweilige Adresse, beispielsweise eine SIP-URL (Session Initiation Protocol Uniform Resource Locator) in Form einer Telefonnummer oder in Form einer SIP-Adresse, aufweist.
  • Dieser Gruppe kann dann eine eigene Gruppenadresse in Form einer SIP-URL zugewiesen werden und beim Aufbau einer PoC-Kommunikation, das heißt einer Kommunikations-Session mittels PoC, unter Angabe der Gruppenadresse, die von einem Benutzer initiiert wird, werden alle Mitglieder der Gruppe von einem PoC-Serverrechner adressiert und zu der PoC-Kommunikation eingeladen.
  • Die Voraussetzung dafür, dass ein Mitglied der Gruppe eingeladen werden kann, ist, dass das Mitglied in dem Mobilfunk-Kommunikationsnetzwerk, mittels welchem der genutzte PoC bereitgestellt wird, angemeldet ist, das heißt "online" ist.
  • Benutzer von PoC, die in einer PoC-Kommunikation aktiv, das heißt als Sender, oder passiv, das heißt als Empfänger, involviert sind, werden im Folgenden als PoC-Teilnehmer der PoC-Kommunikation bezeichnet.
  • Derzeit werden Standardisierungsarbeiten zur Standardisierung des PoC-Kommunikationsdienstes im Rahmen der PS(packetswitched, das heißt paketvermittelt)-Domain von UMTS (Universal Mobile Telecommunications System)-Kommunikationssystemen und/oder im Rahmen der PS-Domain GPRS (General Packet Radio Service ) von GSM (Global System for Mobile Communication)-Kommunikationssystemen durchgeführt. Diese Standardisierungsarbeiten finden im Rahmen der Standardisierungsgremien OMA (Open Mobile Alliance) und 3GPP (3rd Generation Partnership Project) statt. Die in diesen Standardisierungsarbeiten verwendeten Protokolle werden teilweise in dem Standardisierungsgremien der IETF (Internet Engineering Task Force) definiert.
  • Es ist vorgesehen, dass PoC unter anderem auch auf Basis von IMS(Internet Protocol based Multimedia-Subsystem)-Kommunikationssystemen realisiert wird, in welchen das Signalisierungsprotokoll SIP (Session Initiation Protocoll) und dessen Erweiterungen verwendet wird.
  • Wie oben erwähnt erfolgt die Übermittlung von Sprachdaten im Rahmen von PoC im Halb-Duplex-Verfahren, anschaulich darf zu jedem Zeitpunkt einer PoC-Kommunikation immer nur ein PoC-Teilnehmer sprechen und alle anderen PoC-Teilnehmer können nur empfangen, das heißt können keine Sprachdaten versenden. Im Rahmen einer PoC-Kommunikation hat also immer nur ein PoC-Teilnehmer ein Sprachrecht, das heißt das Recht, Sprachdaten an andere PoC-Teilnehmer im Rahmen der PoC-Kommunikation zu versenden. Typischerweise wird im Laufe einer PoC-Kommunikation das Sprachrecht nacheinander an verschiedene PoC-Teilnehmer vergeben. Die Verwaltung und die Vergabe des Sprachrechts wird als Floor Control oder als Talk Hurst Control bezeichnet und wird von einem PoC-Steuerserverrechner, der als PoC-Serverrechner Controlling Function bezeichnet wird, oder einem Talk-Burst-Control-Serverrechner durchgeführt.
  • Die Floor Control im Rahmen einer PoC-Kommunikation wird nach dem Grundprinzip ausgeführt, dass die PoC-Client-Einheit, die von einem PoC-Teilnehmer verwendet wird, bei dem PoC-Steuerserverrechner das Sprachrecht anfordert und der PoC-Steuerserverrechner daraufhin der PoC-Client-Einheit das Sprachrecht erteilt oder verweigert und dies der PoC-Client-Einheit entsprechend signalisiert. Einer PoC-Client-Einheit wird beispielsweise das Sprachrecht verweigert, wenn zu dem Zeitpunkt, zu dem die PoC-Client-Einheit das Sprachrecht anfordert, eine andere PoC-Client-Einheit das Sprachrecht besitzt.
  • Tabelle 1 enthält eine Liste der gemäß dem Stand der Technik definierten Nachrichten für die Talk Burst Control im Rahmen einer PoC-Kommunikation.
  • Figure 00040001
  • Figure 00050001
    Tabelle 1
  • Die in Tabelle 1 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 [1] beschrieben.
  • In [2] ist das Binary Floor Control Protocol (BFCP) beschrieben.
  • Die Spezifikation von RTCP ist in [3] beschrieben.
    •
  • Der Erfindung liegt das Problem zu Grunde, erweiterte Funktionalität in Hinblick auf die Zuteilung des Sprachrechts in Push-to-talk-Kommunikationssystemen effizient bereitzustellen.
  • Das Problem wird durch ein Verfahren zum Anfordern eines Push-to-talk-Sprachrechts und/oder zum Erfragen von Warteschlangeninformation, ein Verfahren zum Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Mitteilen von Warteschlangeninformation, eine Push-to-talk-Client-Einheit, einen Push-to-talk-Steuerserverrechner und eine Entscheidungseinheit mit den Merkmalen gemäß den unabhängigen Patentansprüchen gelöst.
  • Es wird ein Verfahren zum Anfordern eines Push-to-talk-Sprachrechts im Rahmen einer Push-to-talk-Kommunikation und/oder zum Erfragen von Warteschlangeninformation über eine Warteschlange, die Einträge aufweist, die jeweils einer Anforderung nach dem Push-to-talk-Sprachrecht im Rahmen der Push-to-talk-Kommunikation entsprechen und welche Warteschlange bei der Zuteilung des Push-to-talk-Sprachrechts berücksichtigt wird, bereitgestellt, wobei eine Push-to-talk-Client-Einheit eine Real-Time-Control-Protocol-Nachricht erzeugt, die Warteschlangenverwaltungsinformation zur Verwaltung der Warteschlange enthält und/oder die Information enthält, dass die Push-to-talk-Client-Einheit Warteschlangeninformation erfragt und die Push-to-talk-Client-Einheit die Real-Time-Control-Protocol-Nachricht an einen Push-to-Talk-Steuerserverrechner sendet.
  • Ferner wird ein Verfahren zum Zuteilen eines Push-to-talk-Sprachrechts im Rahmen einer Push-to-talk-Kommunikation und/oder zum Mitteilen von Warteschlangeninformation über eine Warteschlange, die Einträge aufweist, die jeweils einer Anforderung nach dem Push-to-talk-Sprachrecht im Rahmen einer Push-to-talk-Kommunikation entsprechen und welche Warteschlange bei der Zuteilung des Push-to-talk-Sprachrechts berücksichtigt wird, bereitgestellt, wobei ein Push-to-talk-Steuerserverrechner eine Real-Time-Control-Protocol-Nachricht erzeugt, die Warteschlangenverwaltungsinformation zur Verwaltung der Warteschlange enthält und/oder die Information enthält, dass der Push-to-talk-Steuerserverrechner Warteschlangeninformation erfragt und/oder die Information enthält, dass der Push-to-talk-Steuerserverrechner Steuerinformation erfragt, die spezifiziert, wie das Push-totalk-Sprachrecht zugeteilt werden soll und der Push-to-talk-Steuerserverrechner die Real-Time-Control-Protocol-Nachricht an eine Entscheidungseinheit sendet.
  • Ferner werden eine Push-to-talk-Client-Einheit, ein Push-totalk-Steuerserverrechner und eine Entscheidungseinheit gemäß dem oben beschriebenen Verfahren zum Anfordern eines Push-totalk-Sprachrechts und/oder zum Erfragen von Warteschlangeninformation und dem oben beschriebenen Verfahren zum Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Mitteilen von Warteschlangeninformation bereitgestellt.
  • Unter Push-to-talk ist insbesondere Push-to-talk-over-Cellular (PoC) zu verstehen.
  • Die Entscheidungseinheit wird im Folgenden auch als Chair bezeichnet. Sie kann ein separat ausgestalteter Serverrechner sein oder auch mittels der Push-to-talk-Client-Einheit eines privilegierten Benutzers realisiert sein, welcher privilegierte Benutzer somit anschaulich der Moderator der Push-to-talk-Kommunikation ist. Ebenso kann die Entscheidungseinheit mittels einer Push-to-talk-Client-Einheit eines Benutzers realisiert sein, der an der Push-totalk-Kommunikation nicht teilnimmt.
  • Anschaulich werden in die Warteschlange alle Push-to-talk-Client-Einheiten eingereiht, die eine Push-to-talk-Sprachrechtanforderung stellen. Stellt eine Push-to-talk-Client-Einheit eine Push-to-talk-Sprachrechtanforderung, so wird sie beispielsweise am Ende der Warteschlange eingereiht, das heißt, es wird ein der Push-to-talk-Client-Einheit entsprechender Eintrag am Ende der Warteschlange erzeugt. Ist das Push-to-talk-Sprachrecht nicht vergeben oder wird es abgegeben, so wird es an die Push-to-talk-Client-Einheit vergeben, die dem ersten Eintrag in der Warteschlange entspricht (und dieser Eintrag wird gelöscht und alle anderen Einträge rücken nach). Anschaulich werden in diesem Beispiel die Push-to-talk-Client-Einheiten nach einem FIFO (first in first out)-Prinzip bedient, andere Alternativen sind möglich, insbesondere die Berücksichtigung einer Priorität der Pushto-talk-Client-Einheit, wenn sie in die Warteschlange eingereiht wird.
  • Eine der Erfindung zu Grunde liegende Idee kann darin gesehen werden, dass eine Erweiterung der Funktionalität von Push-totalk-Kommunikationssystemen in Hinblick auf Zuteilung des Sprachrechts, welche Funktionalität durch Bereitstellung einer Entscheidungseinheit und/oder einer Warteschlange erreicht wird, im Rahmen einer Push-to-talk-Kommunikation mittels des Real-Time-Kontrollprotokolls (Real-Time-Control-Protocol, RTCP), also mittels Real-Time-Control-Protocol-Paketen (vorzugsweise des Pakettyps für anwendungsspezifische Funktionen (APP) des Real Time-Kontrollprotokolls), realisiert wird.
  • Signalisierungsdaten werden bei Push-to-talk üblicherweise über das IMS übertragen, d.h. die entsprechenden Nachrichten werden unter Umständen über sehr viele Proxies weitergeleitet, was zu Verzögerungen bei der Signalisierung führen kann. Sprachdaten werden bei Push-to-talk hingegen mittels Real-Time-Protocol-Paketen, die nicht über das IMS sondern direkt vom Sender, z.B. einer PoC-Client-Einheit, zum Empfänger, z.B. einem PoC-Steuerserver, verlaufen, übertragen. Da Real-Time-Control-Protocol-Pakete parallel zu Real-Time-Protocol-Paketen auf dem gleichen Übertragungsweg übertragen werden können, kann auf diese Weise eine vergleichsweise sehr schnelle Signalisierung, die für das Zuteilen eines Push-to-talk-Sprachrechts benötigt wird, erreicht werden.
  • Ein weiterer Vorteil, insbesondere gegenüber der Verwendung anderer Protokolle wie z.B. des BFCP (Binary Floor Control Protocol), besteht darin, dass die in Tabelle 1 aufgeführten Nachrichten, die wie erläutert eine grundlegende Funktionalität ermöglichen, gemäß dem Stand der Technik unter Verwendung von Real-Time-Control-Protocol-Paketen realisiert werden. Somit unterstützen Push-to-talk-Client-Einheiten und Push-to-talk-Steuerserverrechner herkömmlicher Push-to-talk-Kommunikationssysteme bereits die Verwendung des Real-Time-Kontrollprotokolls, weshalb nur ein geringer Implementierungsaufwand bei der Realisierung der erweiterten Funktionalität entsteht.
  • Bevorzugte Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen. Die weiteren Ausgestaltungen der Erfindung, die im Zusammenhang mit dem Verfahren zum Anfordern eines Push-to-talk-Sprachrechts und/oder zum Erfragen von Warteschlangeninformation und dem Verfahren zum Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Mitteilen von Warteschlangeninformation beschrieben sind, gelten sinngemäß auch für die Push-to-talk-Client-Einheit, den Push-to-talk-Steuerserverrechner und die Entscheidungseinheit.
  • Im Falle des Verfahrens zum Anfordern eines Push-to-talk-Sprachrechts im Rahmen einer Push-to-talk-Kommunikation und/oder zum Erfragen von Warteschlangeninformation über eine Warteschlange ist bevorzugt, dass die Warteschlangenverwaltungsinformation eine Priorität der Pushto-talk-Client-Einheit spezifiziert und/oder spezifiziert, dass die Push-to-talk-Client-Einheit eine Anforderung der Push-to-talk-Client-Einheit nach dem Push-to-talk-Sprachrecht zurücknimmt.
  • Durch Verwendung von Prioritäten ist es möglich, dass bestimmte Push-to-talk-Client-Einheiten (die mit verhältnismäßig hoher Priorität) vor anderen (denen mit verhältnismäßig niedriger Priorität) bevorzugt das (Push-totalk-)Sprachrecht erhalten. Hat eine erste Push-to-talk-Client-Einheit eine höhere Priorität als eine zweite Push-totalk-Client-Einheit, so wird beispielsweise die erste Pushto-talk-Client-Einheit stets vor der zweiten Push-to-talk-Client-Einheit in die Warteschlange eingereiht, auch wenn sie später das Sprachrecht angefordert hat oder die erste Pushto-talk-Client-Einheit kann beispielsweise die zweite Pushto-talk-Client-Einheit unterbrechen, d.h., wenn die zweite Push-to-talk-Client-Einheit aktuell das Sprachrecht hat und die erste Push-to-talk-Client-Einheit fordert das Sprachrecht an, wird der zweiten Push-to-talk-Client-Einheit das Sprachrecht entzogen und der ersten Push-to-talk-Client-Einheit zugeteilt.
  • Es ist ferner bevorzugt, dass die Warteschlange von dem Pushto-Talk-Steuerserverrechner und/oder von einer Entscheidungseinheit verwaltet wird.
  • Die Verwendung einer Warteschlange hat beispielsweise den Vorteil, dass eine Push-to-talk-Client-Einheit nur einmal das Sprachrecht anfordern muss, auch wenn ihr das Sprachrecht nicht sofort erteilt wird. Ferner ist somit eine anschaulich gerechtere Zuteilung des Sprachrechts möglich.
  • Es ist ferner bevorzugt, dass die erfragte Warteschlangeninformation die Information über die Position des Eintrags, der einer Push-to-talk-Sprachrechtsanforderung der Push-to-talk-Client-Einheit entspricht, und/oder die Angabe der kompletten Warteschlange ist.
  • Auf diese Weise kann sich beispielsweise der Benutzer einer Push-to-talk-Client-Einheit mit Blick auf die Warteschlange darüber informieren, wann ihm und anderen Benutzern voraussichtlich das Sprachrecht erteilt wird. Beispielsweise kann ein Benutzer erkennen, dass vor dem Eintrag, der seiner Push-to-talk-Client-Einheit entspricht, ein Eintrag in der Warteschlange vorhanden ist, der der Push-to-talk-Client-Einheit eines anderen Benutzers entspricht und welchem anderen Benutzer somit vor dem Benutzer das Sprachrecht erteilt wird.
  • Es ist ferner bevorzugt, dass der Push-to-talk-Steuerserverrechner das Push-to-talk-Sprachrecht unter Berücksichtigung der Warteschlange zuteilt und/oder eine Real-Time-Control-Protocol-Antwortnachricht mit der erfragten Warteschlangeninformation erzeugt und an die Push-to-talk-Client-Einheit übermittelt.
  • Im Falle des Verfahrens zum Zuteilen eines Push-to-talk-Sprachrechts im Rahmen einer Push-to-talk-Kommunikation und/oder zum Mitteilen von Warteschlangeninformation über eine Warteschlange ist bevorzugt, dass die Warteschlangenverwaltungsinformation eine Identifikation einer Push-to-talk-Client-Einheit enthält und eine Priorität der Push-to-talk-Client-Einheit spezifiziert und/oder spezifiziert, dass die Push-to-talk-Client-Einheit eine Anforderung der Push-to-talk-Client-Einheit nach dem Push-totalk-Sprachrecht zurücknimmt.
  • Vorzugsweise wird die Warteschlange von der Entscheidungseinheit verwaltet.
  • Es ist ferner bevorzugt, dass die erfragte Warteschlangeninformation die Information über die Position des Eintrags, der einer Push-to-talk-Sprachrechtsanforderung einer Push-to-talk-Client-Einheit entspricht, und/oder eine Information über den Gesamtzustand der Warteschlange ist.
  • Es ist ferner bevorzugt, dass die Entscheidungseinheit eine erste Real-Time-Control-Protocol-Antwortnachricht mit der erfragten Steuerinformation erzeugt und an den Push-to-talk-Steuerserverrechner übermittelt und/oder eine zweite Real-Time-Control-Protocol-Antwortnachricht mit der erfragten Warteschlangeninformation erzeugt und an den Push-to-talk-Steuerserverrechner übermittelt und/oder die Warteschlange unter Berücksichtigung der Warteschlangenverwaltungsinformation verwaltet.
    •
  • Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Weiteren näher erläutert.
  • 1 zeigt ein Kommunikationssystem gemäß einem Ausführungsbeispiel der Erfindung.
  • 2 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
  • 3 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
  • 4 zeigt ein Nachrichtenflussdiagramm gemäß einem Ausführungsbeispiel der Erfindung.
  • 1 zeigt ein Kommunikationssystem 100 gemäß einem Ausführungsbeispiel der Erfindung.
  • Eine erste PoC-Client-Einheit 101, eine zweite PoC-Client-Einheit 102 und eine dritte PoC-Client-Einheit 103 sind mittels jeweils einer Schnittstelle 104 mit jeweils einem PoC-Teilnehmerserverrechner (PoC-Server Participant Function) 105 gekoppelt. Die PoC-Teilnehmerserverrechner 105 sind mit einem PoC-Steuerserverrechner (PoC-Server controlling function) 106 gekoppelt.
  • Der PoC-Steuerserverrechner 106 ist optional mit einem Chair 107 gekoppelt. Der Chair 107 kann mittels einer PoC-Client-Einheit 101, 102, 103 oder mittels eines Serverrechners des Kommunikationssystems 100 realisiert sein. Der Chair 107 ist anschaulich der Moderator der PoC-Kommunikation.
  • Beispielsweise kann der PoC-Steuerserverrechner 106 bei dem Chair 107 anfragen, an welche PoC-Client-Einheit 101, 102, 103 das Sprachrecht vergeben werden soll oder an welcher Stelle der PoC-Steuerserverrechner 106 eine PoC-Client-Einheit 101, 102, 103 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 104 werden beispielsweise mittels des RAN (Radio Access Network), des Kernnetzwerks (Core Network, CN) und des IMS (Internet Protocol based Multimedia Subsystem) eines UMTS(Universal Mobil Telecommunication System)-Kommunikationssystems oder eines GSM(Global System for Mobile Communication)-Kommunikationssystems bereitgestellt.
  • Die Schnittstellen 104 können aber auch beispielsweise mittels eines PSTN(Public Switched Telephone Network)-Kommunikationsnetzwerks bereitgestellt werden.
  • Die PoC-Client-Einheiten 101, 102, 103 sind jeweils in einem Mobilfunk-Kommunikationsendgerät, das gemäß der jeweiligen Schnittstelle 104 beispielsweise eingerichtet ist zur Kommunikation gemäß dem UMTS-Standard, dem GSM-Standard, dem GPRS(General Packet Radio Service)-Standard oder einem anderen Mobilfunk-Kommunikationsstandard, integriert.
  • Im Weiteren wird mit Bezug auf 2 ein Talk-Burst-Control-Verfahren gemäß einer Ausführungsform der Erfindung beschrieben, bei dem im PoC-Steuerserverrechner 106 eine Warteschlange gehalten wird, in der für jede PoC-Client-Einheit 101, 102, 103, die das Sprachrecht im Rahmen der PoC-Kommunikation angefordert hat, aber noch nicht erhalten hat, ein Eintrag enthalten ist. Ist beispielsweise das Sprachrecht zu einem Zeitpunkt an die erste PoC-Client-Einheit 101 vergeben, und die zweite PoC-Client-Einheit 102 fragt nach dem Sprachrecht an, reiht der PoC-Steuerserverrechner 106 (falls er die entsprechende Entscheidung trifft) die zweite PoC-Client-Einheit 102 in die Warteschlange ein, anstatt der zweiten PoC-Client-Einheit 102 das Sprachrecht zu verweigern. Die Warteschlange ist beispielsweise als FIFO(first in first out)-Warteschlange oder als LIFO(last in first out)-Warteschlange ausgestaltet.
  • Ein entsprechender Nachrichtenfluss ist in 2 dargestellt.
  • 2 zeigt ein Nachrichtenflussdiagramm 200 gemäß einem Ausführungsbeispiel der Erfindung.
  • Der in 2 dargestellte Nachrichtenfluss findet zwischen einer ersten PoC-Client-Einheit 201, einem PoC-Steuerserverrechner 202, einer zweiten PoC-Client-Einheit 203 und einer dritten PoC-Client-Einheit 204 statt, die wie oben mit Bezug auf 1 erläutert ausgestaltet und angeordnet sind.
  • In Schritt 205 fragt die erste PoC-Client-Einheit 201 bei dem PoC-Steuerserverrechner 202 an, ob sie das Sprachrecht bekommt. Dies erfolgt mittels einer Talk-Burst-Request-Nachricht 214.
  • In diesem Beispiel entscheidet der PoC-Steuerserverrechner 202, dass die erste PoC-Client-Einheit 201 das Sprachrecht bekommt und sendet dementsprechend eine Talk-Burst-Confirm-Response-Nachricht 219 in Schritt 206 an die erste PoC-Client-Einheit 201.
  • In Schritt 207 teilt der PoC-Steuerserverrechner 202 der zweiten PoC-Client-Einheit 203 und der dritten PoC-Client-Einheit 204 mittels einer Receiving-Talk-Burst-Indication-Nachricht 220 mit, dass das Sprachrecht vergeben wurde.
  • Die Talk-Burst-Request-Nachricht 214, die Talk-Burst-Confirm-Response-Nachricht 219 und die Receiving-Talk-Burst-Indication-Nachricht 220 sind wie in [1] beschrieben ausgestaltet.
  • In Schritt 208 kann nun der PoC-Teilnehmer, der die erste PoC-Client-Einheit 201 verwendet, Sprach-Nachrichten mittels des PoC-Steuerserverrechners 202 an die zweite PoC-Client-Einheit 203 und die dritte PoC-Client-Einheit 204 versenden.
  • Wie oben erwähnt, führt der PoC-Steuerserverrechner 202 eine Warteschlange mit allen PoC-Client-Einheiten 201, 203, 204, die das Sprachrecht angefordert haben, das Sprachrecht jedoch bisher noch nicht erhalten haben.
  • In Schritt 205 wurde angenommen, dass die Warteschlage leer war und dementsprechend die erste PoC-Client-Einheit 201 das Sprachrecht als Reaktion auf die Sprachrecht-Anforderung mittels der Talk-Burst-Request-Nachricht 214 erhalten hat.
  • In Schritt 210 fordert die zweite PoC-Client-Einheit 203 mittels einer weiteren Talk-Burst-Request-Nachricht 215 das Sprachrecht bei dem PoC-Steuerserverrechner 202 an. Es wird angenommen, dass die erste PoC-Client-Einheit 201 die Übermittlung von Sprachnachrichten jedoch noch nicht beendet hat.
  • Der PoC-Steuerserverrechner 202 erstellt deshalb einen Eintrag für die zweite PoC-Client-Einheit 203 in der von ihm geführten Warteschlange und teilt in Schritt 211 der zweiten PoC-Client-Einheit 203 mittels einer Talk-Burst-Request-Queued-Response-Nachricht 216 mit, dass sie in die Warteschlange eingereiht ist.
  • In Schritt 212 teilt die erste PoC-Client-Einheit 201 mittels einer Talk-Burst-Completed-Indication-Nachricht 217 dem PoC-Steuerserverrechner 202 mit, dass sie die Übermittlung von Sprachdaten beendet und das Sprachrecht abgibt.
  • Da in der von dem PoC-Steuerserverrechner 202 geführten Warteschlange ein Eintrag für die zweite PoC-Client-Einheit 203 vorhanden ist und in diesem Beispiel angenommen wird, dass kein Eintrag vor dem Eintrag für die zweite PoC-Client-Einheit 203 in der Warteschlange vorhanden ist, erteilt der PoC-Steuerserverrechner 202 jetzt der zweiten PoC-Client-Einheit 203 das Sprachrecht. Dementsprechend übermittelt der PoC-Steuerserverrechner 202 eine weitere Talk-Burst-Confirm-Response-Nachricht 218 an die zweite PoC-Client-Einheit 203.
  • Die weitere Talk-Burst-Request-Nachricht 215 und die weitere Talk-Burst-Confirm-Response-Nachricht 218 sowie die Talk-Burst-Completed-Indication-Nachricht 217 sind wie in [1] beschrieben ausgestaltet.
  • Die Talk-Burst-Request-Queued-Response-Nachricht 216 ist in diesem Ausführungsbeispiel gemäß Tabelle 2 ausgestaltet.
  • Figure 00170001
  • Figure 00180001
    Tabelle 2: Talk Burst Request Queued response
  • Die Tabelle 2 sowie die weiteren Tabellen 3 bis 22 illustrieren jeweils ein RTCP APP-Paket, das zur Realisierung einer im Rahmen der Talk-Burst-Control verwendeten Nachricht verwendet wird. Jedes der durch die Tabellen 2 bis 22 dargestellten RTCP APP-Pakete enthält ein Feld mit der Bezeichnung subtype, das einen noch nicht anderweitig belegten, für die jeweilige Nachricht spezifischen Wert enthält. Beispielsweise könnte der in dem Feld subtype Wert für die gemäß Tabelle 2 ausgestaltete Nachricht 01000 sein, für die gemäß Tabelle 3 ausgestaltete Nachricht 01001, für die gemäß Tabelle 4 ausgestaltete Nachricht der Wert 01010 u.s.w. Der in dem Feld subtype enthaltene Wert dient zur Unterscheidung der Nachrichten, das heißt zur eindeutigen Identifizierung der Nachrichten.
  • Die in den Tabellen 2 bis 22 dargestellten RTCP APP-Pakete enthalten ferner ein Feld mit der Zeichenkette PT = APP = 204. Diese Zeichenkette spezifiziert, dass es sich bei diesen RTCP Paketen um RTCP APP-Pakete handelt.
  • Jedes der dargestellten RTCP APP-Pakete weist ferner ein Feld mit der Längenspezifikation (Größenspezifikation) des jeweiligen RTCP APP-Pakets auf, z.B. length = 3 (in einer geeigneten Einheit, welche in den Tabellen der Größe einer Zeile entspricht).
  • Ferner weist jedes der dargestellten RTCP APP-Pakete eine Identifikation des Senders des jeweiligen RTCP APP-Pakets auf. Dies ist entweder eine Identifikation des PoC- Steuerserverrechners 106, gekennzeichnet durch den Eintrag SSRC of PoC server, eine Identifikation des Chair 107, gekennzeichnet durch den Eintrag SSRC of Chair, oder eine Identifikation einer PoC-Client-Einheit 101, 102, 103, gekennzeichnet durch den Eintrag SSRC of UE, je nachdem, welches Element des Kommunikationssystems 100 die entsprechende Nachricht sendet.
  • Des weiteren weist jedes der dargestellten RTCP APP-Pakete ferner ein Feld mit der Zeichenkette name = PoCl. Diese Zeichenkette spezifiziert, dass die RTCP APP-Pakete im Rahmen von PoC Version 1 genutzt werden. Dieser Wert kann je nach Standardisierungsgremium unterschiedlich sein.
  • Manche der dargestellten RTCP APP-Pakete weisen ferner in einer Zeile ein Feld mit der Bezeichnung Padding auf. Dies zeigt an, dass die entsprechende Zeile mittels so genannter Padding-Bits aufgefüllt wird.
  • Das in Tabelle 2 dargestellte RTCP APP-Paket, das wie erwähnt zur Realisierung der Talk-Burst-Request-Queued-Response-Nachricht 216 verwendet wird, weist ein Feld mit der Bezeichnung Queue-Position auf, die die Position der (in diesem Beispiel) zweiten PoC-Client-Einheit 203 enthält. In diesem Beispiel hat das Feld Queue-Position eine Größe von 8 Bit, es können jedoch, falls dies erforderlich ist, auch 16 Bit oder mehr genutzt werden.
  • Weitere, im Rahmen des in 2 dargestellten Nachrichtenflusses nicht übertragene Nachrichten können im Rahmen einer Talk-Burst-Control mit einer von dem PoC-Steuerserverrechner 106 verwalteten Warteschlange verwendet werden.
  • Beispielsweise kann eine Talk-Burst-Queue-Position-Request-Nachricht, die beispielsweise gemäß Tabelle 3 ausgestaltet ist, von einer PoC-Client-Einheit 101, 102, 103 dazu verwendet werden, beim PoC-Steuerserverrechner 106 nachzufragen, ob die PoC-Client-Einheit 101, 102, 103 in der Warteschlange geführt wird, das heißt ob ein Eintrag in der Warteschlange für die PoC-Client-Einheit 101, 102, 103 in der Warteschlange existiert und, wenn ja, an welcher Position der entsprechenden Einheit in der Warteschlange ist.
  • Figure 00200001
    Tabelle 3: Talk Burst Queue Position request
  • Solch eine Anfrage kann der PoC-Steuerserverrechner 106 mittels einer Talk-Burst-Queue-Position-Response-Nachricht, die beispielsweise gemäß Tabelle 4 ausgestaltet ist, beantworten. Ähnlich wie die Talk-Burst-Request-Queued-Response-Nachricht enthält die Talk-Burst-Queue-Position-Response-Nachricht ein Feld mit der Bezeichnung Queue Position, mittels welchem der PoC-Steuerserverrechner 106 einer PoC-Client-Einheit 101, 102, 103 die Position der PoC-Client-Einheit 101, 102, 103 entsprechenden Eintrages in der Warteschlange mitteilt.
  • Da die Talk-Burst-Queue-Position-Response-Nachricht bis auf den Eintrag des Feldes subtype, der wie erwähnt die Nachrichten eindeutig spezifiziert, identisch zu der Talk-Burst-Queue-Position-Request-Nachricht ist, können die beiden Nachrichten in einer Ausführungsform völlig identisch gewählt werden, das heißt, haben den gleichen Eintrag in dem Feld subtype, sind anschaulich also dieselbe Nachricht.
  • Figure 00210001
    Tabelle 4: Talk Burst Queue Position response
  • Mittels einer Talk-Burst-Queue-Identity-Request-Nachricht, die beispielsweise gemäß Tabelle 5 ausgestaltet ist, kann eine PoC-Client-Einheit 101, 102, 103 bei dem PoC-Steuerserverrechner 106 anfordern, dass er der PoC-Client-Einheit 101, 102, 103 den (gesamten) Zustand der Warteschlange übermittelt.
  • Figure 00210002
    Tabelle 5: Talk Burst Queue Identity request
  • Eine solche Anforderung kann der PoC-Steuerserverrechner 106 mittels einer Talk-Burst-Queue-Identity-Response-Nachricht, die beispielsweise gemäß Tabelle 6 ausgestaltet ist, beantworten, das heißt, der PoC-Client-Einheit 101, 102, 103 wird die gesamte aktuelle Warteschlange mitgeteilt.
  • Figure 00220001
    Tabelle 6: Talk Burst Queue Identity response
  • In dem RTCP APP-Paket gemäß Tabelle 6 werden in den Feldern nach dem Feld mit dem Eintrag name = PoCl alle PoC-Client-Einheiten 101, 102, 103, für die ein Eintrag in der Warteschlange vorhanden ist, entsprechend der Reihenfolge der Einträge in der Warteschlange der Reihe nach aufgelistet (wobei in der Beschreibung des entsprechenden Feldes die Warteschlangenposition angegeben wird). Die Bezeichnungen der PoC-Client-Einheiten CNAME und NAME sind in jedem Feld als SDES Items (Source Description Items, spezifiziert in [3]) in dem RTCP APP-Paket enthalten, wie es auch bei weiteren im Folgenden beschriebenen Nachrichten der Fall ist.
  • In einer anderen Ausführungsform werden die PoC-Client-Einheiten in der Warteschlange mittels der Identifikation SSRC (Synchronisation Source, spezifiziert in [3]) des jeweiligen Mobilfunk-Teilnehmergeräts spezifiziert, sodass die Talk-Burst-Queue-Identity-Response-Nachricht kürzer ist und somit gemäß Tabelle 7 ausgestaltet ist.
  • Figure 00230001
    Tabelle 7
  • Auch bei dem im Folgenden erläuterten RTCP APP-Paketen ist es stets möglich, ein Feld
    Figure 00230002
    durch ein entsprechendes Feld
    Figure 00240001
    zu ersetzen, wie dies oben bei der Talk-Burst-Queue-Identity-Response-Nachricht gemäß den Tabellen 6 und 7 der Fall ist.
  • Ferner kann eine PoC-Client-Einheit 101, 102, 103 mittels einer Talk-Burst-Request-Cancellation-Nachricht, die beispielsweise gemäß Tabelle 8 ausgestaltet ist, dem PoC-Steuerserverrechner 106 mitteilen, dass die Anforderung mittels einer Talk-Burst-Request-Nachricht der PoC-Client-Einheit 101, 102, 103, auf die eventuell der PoC-Steuerserverrechner 106 schon mit einer Talk-Burst-Request-Queued-Response-Nachricht geantwortet hat, zurückgenommen wird, das heißt, die PoC-Client-Einheit 101, 102, 103 das Sprachrecht nicht länger anfordern möchte.
  • Figure 00240002
    Tabelle 8: Talk Burst Request cancellation
  • Im Weiteren wird eine Ausführungsform erläutert, bei der der Chair 107 die Entscheidung, welche PoC-Client-Einheit 101, 102, 103 das Sprachrecht erhält, fällt.
  • 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 Sprachrecht bekommt und in welcher Reihenfolge die PoC-Client-Einheiten 101, 102, 103 das Sprachrecht bekommen, mitteilt. Der PoC-Steuerserverrechner 106 sendet daraufhin entsprechende Signalisierungen an die beteiligten PoC-Client-Einheiten 101, 102, 103.
  • Zunächst wird eine Ausführungsform erläutert, in welcher keine Warteschlange geführt wird.
  • 3 zeigt ein Nachrichtenflussdiagramm 300 gemäß einem Ausführungsbeispiel der Erfindung.
  • Der in 3 dargestellte Nachrichtenfluss findet zwischen einer ersten PoC-Client-Einheit 301, einem PoC-Steuerserverrechner 302, einem Chair 303 und einer zweiten PoC-Client-Einheit 304 statt, die wie oben mit Bezug auf 1 erläutert angeordnet und ausgestaltet sind.
  • Analog zu 2 sendet die erste PoC-Client-Einheit 301 in Schritt 306 eine Talk-Burst-Request-Nachricht 320 an den PoC-Steuerserverrechner 302, mit der sie das Sprachrecht anfordert. In Schritt 307 leitet der PoC-Steuerserverrechner 302 diese Anforderung mittels einer Chair-Talk-Burst-Request-Nachricht 321, die beispielsweise gemäß Tabelle 9 ausgestaltet ist, an den Chair 303 weiter.
  • Figure 00250001
  • Figure 00260001
    Tabelle 9: Chair Talk Burst Request
  • Da in diesem Fall der Sender der Chair-Talk-Burst-Request-Nachricht 321 der PoC-Steuerserverrechner 302 ist, ist in diesem Fall in der Chair-Talk-Burst-Request-Nachricht 321 als Absenderidentifikation die SSRC des PoC-Steuerserverrechners 302 enthalten. Deshalb enthält die Chair-Talk-Burst-Request-Nachricht 321 zusätzlich ein Feld mit der Identifikation der ersten PoC-Client-Einheit 301.
  • Die Chair-Talk-Burst-Request-Nachricht 321 enthält ferner die Priorität der ersten PoC-Client-Einheit 301. Dies ist jedoch optional, beispielsweise könnte die Chair-Talk-Burst-Request-Nachricht 321 nur dann die Priorität der ersten PoC-Client-Einheit 301 enthalten, wenn diese zum ersten Mal im Rahmen der PoC-Kommunikation das Sprachrecht anfordert. Alternativ kann die Priorität der ersten PoC-Client-Einheit 301 nur dann in der Chair-Talk-Burst-Request-Nachricht 321 enthalten sein, wenn sich die Priorität gegenüber der letzten Übermittlung der Priorität an den Chair 303 geändert hat.
  • Eine weitere Alternative, die vorzugsweise dann verwendet wird, wenn sich die Prioritäten der PoC-Client-Einheiten 101, 102, 103 im Laufe einer PoC-Kommunikation nicht ändern, ist, zu Beginn der PoC-Kommunikation in Schritt 305 eine Chair- Priorities-Indication-Nachricht 330, die beispielsweise gemäß Tabelle 10 ausgestaltet ist (von dem PoC-Steuerserverrechner 302) an den Chair 303 zu übermitteln.
  • Figure 00270001
    Tabelle 10: Chair Priorities indication
  • Wie in Tabelle 10 dargestellt, enthält die Chair-Priorities-Indication-Nachricht 330 für jede PoC-Client-Einheit 301, 304 ein Feld mit einer Identifikation der PoC-Client-Einheit 301, 304 und der Priorität der jeweiligen PoC-Client-Einheit 301, 304.
  • In einer Ausführungsform wird eine Chair-Priorities-Indication-Nachricht 330 erneut übertragen, wenn sich die Priorität einer PoC-Client-Einheit 301, 304 geändert hat.
  • In dem in 3 nicht dargestellten Fall, dass eine PoC-Client-Einheit 301, 304 das Sprachrecht hat und die Abgabe des Sprachrechts dem PoC-Steuerserver 302 mittels der Übertragung einer Talk-Burst-Completed-Indication-Nachricht signalisiert, sendet der Steuerserver 302 eine Chair-Talk-Burst-Completed-indication-Nachricht, die beispielsweise gemäß Tabelle 11 ausgestaltet ist, an den Chair 303.
  • Figure 00280001
    Tabelle 11: Chair Talk Burst Completed indication
  • In Schritt 308 teilt der Chair 303 dem PoC-Steuerserverrechner 302 das Ergebnis seiner Entscheidung, ob die erste PoC-Client-Einheit 301 das Sprachrecht erhält, mit. Diese Entscheidung kann unter Berücksichtigung der Priorität der ersten PoC-Client-Einheit 301 gefällt werden.
  • In diesem Beispiel wird angenommen, dass der Chair 303 entscheidet, dass die erste PoC-Client-Einheit 301 das Sprachrecht erhält. Dementsprechend übermittelt der Chair 303 eine Chair-Talk-Burst-Confirm-Response-Nachricht 322 in Schritt 308 an den PoC-Steuerserverrechner 302. Die Chair-Talk-Burst-Confirm-Response-Nachricht 322 ist in diesem Beispiel gemäß Tabelle 12 ausgestaltet und enthält eine Identifikation der PoC-Client-Einheit 301, 304, der das Sprachrecht erteilt werden soll, in diesem Beispiel der ersten PoC-Client-Einheit 301.
  • Figure 00290001
    Tabelle 12: Chair Talk Burst Confirm response
  • In dem Fall, dass der Chair 303 entscheidet, dass dem erste PoC-Client-Einheit 301 das Sprachrecht nicht erteilt wird, überträgt der Chair 303 in Schritt 308 eine Chair-Talk-Burst-Reject-Response-Nachricht an den PoC-Steuerserverrechner 302, die beispielsweise gemäß Tabelle 13 ausgestaltet ist, eine Identifikation der PoC-Client-Einheit 301, 304 enthält, der das Sprachrecht verweigert wird, eine Spezifikation eines Grundes für die Verweigerung (Reason Code, siehe auch [1]), die Länge einer Angabe eines Grundes (Length) und die Angabe eines Grundes (Reason Phrase).
  • Figure 00290002
  • Figure 00300001
    Tabelle 13: Chair Talk Burst Reject response
  • Da in diesem Beispiel angenommen wird, dass der ersten PoC-Client-Einheit 301 das Sprachrecht erteilt wird, sendet der PoC-Steuerserverrechner 302 entsprechend in Schritt 309 analog zu 2 eine Talk-Burst-Confirm-Response-Nachricht 323 an die erste PoC-Client-Einheit 301.
  • Analog zu Schritt 207 in 2 übermittelt der PoC-Steuerserverrechner 302 eine Receiving-Talk-Burst-Indication-Nachricht 324 an die zweite PoC-Client-Einheit 304.
  • Analog zu Schritt 208 in 2 beginnt die erste PoC-Client-Einheit 301 in Schritt 311 mit der Übermittlung von Sprachnachrichten an die zweite PoC-Client-Einheit 304.
  • Nun wird angenommen, dass in Schritt 312 die zweite PoC-Client-Einheit mittels einer weiteren Talk-Burst-Request-Nachricht 325 das Sprachrecht im Rahmen der PoC-Kommunikation anfordert.
  • Analog zu Schritt 307 übermittelt der PoC-Steuerserverrechner 302 eine weitere Chair-Talk-Burst-Request-Nachricht 331 an den Chair 303.
  • In diesem Beispiel wird angenommen, dass die Priorität der zweiten PoC-Client-Einheit 304 höher ist als die der ersten PoC-Client-Einheit 301. Entsprechend entscheidet der Chair 303, dass nun der zweiten PoC-Client-Einheit 304 das Sprachrecht erteilt werden soll und teilt dies dem PoC-Steuerserverrechner 302 mittels einer weiteren Chair-Talk-Burst-Confirm-Response-Nachricht 326 mit.
  • In Schritt 315 teilt der PoC-Steuerserverrechner der ersten PoC-Client-Einheit 301 mittels einer Stop-Talk-Burst-Indication-Nachricht 327 (siehe Tabelle 1) mit, dass die erste PoC-Client-Einheit 301 das Sprachrecht abgeben muss und dementsprechend die Übermittlung von Sprachnachrichten beenden muss.
  • In dem Fall, dass der Chair 303 selbst einer PoC-Client-Einheit 301, 304 die das Sprachrecht hat, das Sprachrecht entzieht, signalisiert er dies der PoC-Client-Einheit 301, 304 mittels einer Chair-Stop-Talk-Burst-Indication-Nachricht, die beispielsweise gemäß Tabelle 14 ausgestaltet ist.
  • Figure 00310001
    Tabelle 14: Chair Stop Talk Burst indication
  • Die in Tabelle 14 dargestellte Chair-Stop-Talk-Burst-
  • Indication-Nachricht enthält die Identifikation der PoC-Client-Einheit, die in dem Moment gerade das Sprachrecht hat und der das Sprachrecht 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 309 übermittelt der PoC-Steuerserverrechner 302 in Schritt 316 eine weitere Talk-Burst-Confirm-Response-Nachricht 328 an die zweite PoC-Client-Einheit 304.
  • Analog zu Schritt 310 übermittelt der PoC-Steuerserverrechner 302 in Schritt 317 eine weitere Receiving-Talk-Burst-Indication-Nachricht 329 an die erste PoC-Client-Einheit 301.
  • Analog zu Schritt 311 beginnt die zweite PoC-Client-Einheit 304 mit der Übermittlung von Sprachnachrichten an die erste PoC-Client-Einheit 301.
  • Im Weiteren wird eine Ausführungsform erläutert, bei der die Entscheidung, welche PoC-Client-Einheit 101, 102, 103 das Sprachrecht erhält, von dem Chair 107 gefällt wird, wobei eine Warteschlange analog zu der Warteschlange bei der mit Bezug auf 2 beschriebenen Ausführungsform von dem Steuerserverrechner 106 verwaltet wird.
  • 4 zeigt ein Nachrichtenflussdiagramm 400 gemäß einem Ausführungsbeispiel der Erfindung.
  • Der dargestellte Nachrichtenfluss findet zwischen einer ersten PoC-Client-Einheit 401, einem PoC-Steuerserverrechner 402, einem Chair 403 und einer zweiten PoC-Client-Einheit 404 statt, die wie mit Bezug auf 1 beschrieben angeordnet und ausgestaltet sind.
  • Die Schritte 405 und 406 werden analog zu den Schritten 305 und 306 in 3 durchgeführt.
  • Da in diesem Beispiel angenommen wird, dass die Warteschlange, die von dem PoC-Steuerserverrechner 402 verwaltet wird, leer ist, fragt der PoC-Steuerserverrechner 402 nicht bei dem Chair 403 nach, sondern erteilt in Schritt 407 der ersten PoC-Client-Einheit 401 analog zu Schritt 309 in 3 mittels einer Talk-Burst-Confirm-Response-Nachricht 420 das Sprachrecht.
  • Die Schritte 408 und 409 werden entsprechend den Schritten 310 und 311 durchgeführt.
  • Es wird angenommen, dass in Schritt 410 die zweite PoC-Client-Einheit 404 analog zu Schritt 312 die Anforderung nach dem Sprachrecht mittels einer Talk-Burst-Request-Nachricht 421 an den PoC-Teilnehmerserverrechner 402 sendet.
  • Da in diesem Fall das Sprachrecht aktuell an die erste PoC-Client-Einheit 401 vergeben ist, fragt der PoC-Steuerserverrechner 402 in Schritt 411 mittels einer Chair-Talk-Burst-Request-Queueing-Nachricht 422, die beispielsweise gemäß Tabelle 15 ausgestaltet ist, bei dem Chair 403 nach, an welcher Stelle die zweite PoC-Client-Einheit 404 in die von dem PoC-Steuerserverrechner 402 verwaltete Warteschlange eingereiht werden soll.
  • Figure 00330001
  • Figure 00340001
    Tabelle 15: Chair Talk Burst Request queueing
  • Wie dargestellt enthält die Chair-Talk-Burst-Request-Queueing-Nachricht 422 für jede in der Warteschlange geführte PoC-Client-Einheit 401, 404 eine Identifikation der PoC-Client-Einheit 401, 404 und die Priorität der jeweiligen PoC-Client-Einheit 401, 404 in der Reihenfolge, wie sie durch die Warteschlange festgelegt ist, sowie eine Identifikation und die Priorität der zweiten PoC-Client-Einheit 404.
  • In einer Ausführungsform kann die zweite PoC-Client-Einheit 404 der ersten PoC-Client-Einheit 401 das Sprachrecht entziehen (anstatt beispielsweise nur an die erste Position der Warteschlange eingereiht zu werden), wenn die erste PoC-Client-Einheit 401 das Sprachrecht hat und eine niedrigere Priorität als die zweite PoC-Client-Einheit 404 hat. In dieser Ausführungsform kann die Chair-Talk-Burst-Request-Queueing-Nachricht 422 beispielsweise gemäß Tabelle 15a ausgestaltet sein und die Identifikation der PoC-Client-Einheit 401, 404, die aktuell das Sprachrecht hat, sowie die Priorität dieser PoC-Client-Einheit 401, 404 enthalten. Der Chair 404 kann entsprechend mittels einer Chair-Talk-Burst-Confirm-response-Nachricht gestatten, dass der ersten PoC-Client-Einheit 401 das Sprachrecht entzogen wird und der zweiten PoC-Client-Einheit 404 zugeteilt wird, oder dies mittels einer Chair-Talk-Burst-Reject-response-Nachricht ablehnen.
  • In einer anderen Ausführungsform wird die PoC-Client-Einheit 401, 404, die aktuell das Sprachrecht hat, stets der ersten Position der Warteschlange geführt. Dementsprechend könnte eine weitere PoC-Client-Einheit 401, 404 mit einer höheren Priorität der PoC-Client-Einheit 401, 404, die aktuell das Sprachrecht hat, das Sprachrecht entziehen, indem sie an der ersten Position der Warteschlange eingereiht wird und entsprechend die PoC-Client-Einheit 401, 404, die aktuell das Sprachrecht hat, auf die zweite Position der Warteschlange zurückfällt.
  • Figure 00350001
  • Figure 00360001
    Tabelle 15a: Chair Talk Burst Request queueing (Alternative)
  • Analog zu oben kann auf die Übermittlung der Prioritäten mittels der Chair-Talk-Burst-Request-Queueing-Nachricht 422 verzichtet werden, falls in Schritt 405 die Prioritäten der PoC-Client-Einheiten 401, 404 mittels einer Chair-Priorities-Indication-Nachricht 424 übermittelt wurden.
  • In Schritt 412 übermittelt der Chair 403 dem PoC-Steuerserverrechner 402 die Position der zweiten PoC-Client-Einheit 404 mittels einer Chair-Talk-Burst-Request-Queued-Response-Nachricht 423, die gemäß Tabelle 16 ausgestaltet ist.
  • Figure 00370001
    Tabelle 16: Chair Talk Burst Request queued response
  • Alternativ kann der Chair 403 in Schritt 412 auch die Angabe der kompletten aktualisierten Warteschlange, das heißt der Warteschlange, in die die zweite PoC-Client-Einheit 404 aufgenommen ist, an den Steuerserverrechner 402 übermitteln. Dies erfolgt mittels einer Chair-Talk-Burst-Request-Queue-Result-Nachricht, die beispielsweise gemäß Tabelle 17 ausgestaltet ist und analog zu der Chair-Talk-Burst-Request- Queueing-Nachricht 422 die Angabe der (nun aktualisierten) Warteschlange enthält.
  • Figure 00380001
    Tabelle 17: Chair Talk Burst Request queue result
  • Die Position der zweiten PoC-Client-Einheit 404 in der Warteschlange bestimmt der Chair 403 unter Berücksichtigung der Priorität der zweiten PoC-Client-Einheit 404.
  • Die nun folgenden Schritte 413, 414 und 415 werden analog zu den Schritten 211, 212 und 213 in 2 durchgeführt.
  • Die Schritte 416 und 417 werden analog zu den Schritten 408 und 409 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 der Chair 107 von dem PoC-Steuerserverrechner 106 kontaktiert.
  • In diesem Fall ist neben der Übertragung einer Chair-Talk-Burst-Confirm-Response-Nachricht 322 in Schritt 308 des in 3 dargestellten Nachrichtenflussdiagramms 300 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 eine Anfrage bei dem PoC-Steuerserverrechner 106 nach der Position des der PoC-Client-Einheit 101, 102, 103 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 18 ausgestaltet ist, den Chair 107.
  • Figure 00390001
    Tabelle 18: 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, die 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 19 und analog zu der oben beschriebenen Talk-Burst-Queue-Position-Response-Nachricht ausgestaltet ist.
  • Figure 00400001
    Tabelle 19: 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 216. Stellt eine PoC-Client-Einheit 101, 102, 103 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 20 ausgestaltet ist und mittels welcher die Anfrage an den Chair 107 weitergeleitet wird.
  • Figure 00410001
    Tabelle 20: 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 21 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.
  • Figure 00410002
  • Figure 00420001
    Tabelle 21: Chair Talk Burst Queue Identity response
  • Teilt eine PoC-Client-Einheit 101, 102, 103 beispielsweise mittels einer Talk-Burst-Request-Cancellation-Nachricht wie oben erläutert mit, dass sie nicht länger das Sprachrecht anfordert, also ein der PoC-Client-Einheit 101, 102, 103 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 22 ausgestaltet ist und analog zu der Talk-Burst-Request-Cancellation-Nachricht ausgestaltet ist, an den Chair 107 weiter.
  • Figure 00420002
    Tabelle 22: Chair Talk Burst Request cancellation
  • In diesem Dokument sind folgende Veröffentlichungen zitiert:
    • [1] Push-to-Talk over Cellular (PoC) User Plane; Transport Protocols; PoC Release 1.0 – (http://www.siemensmobile.com/repository/38/3888/Push_to_talk_over_Cellular_PoC. zip)
    • [2] The Binary Floor Control Protocol (BFCP) – ftp://ftp.rfceditor.org/in-notes/internet-drafts/draft-ietf-xcon-bfcp-0l.txt
    • [3] RFC3550 "RTP: A Transport Protocol for Real-Time Applications", ftp://ftp.rfc-editor.org/innotes/std/std64.txt
    • 100
    Kommunikationssystem
    101–103
    PoC-Client-Einheit
    104
    Schnittstelle
    105
    PoC-Teilnehmerserver
    106
    PoC-Steuerserver
    107
    Chair
    200
    Nachrichtenflussdiagramm
    201
    PoC-Client-Einheit
    202
    PoC-Steuerserver
    203,204
    PoC-Client-Einheiten
    205–208
    Verabeitungsschritte
    210–213
    Verabeitungsschritte
    214–220
    Nachrichten
    300
    Nachrichtenflussdiagramm
    301
    PoC-Client-Einheit
    302
    PoC-Steuerserver
    303,304
    PoC-Client-Einheiten
    305–318
    Verabeitungsschritte
    320–331
    Nachrichten
    400
    Nachrichtenflussdiagramm
    401
    PoC-Client-Einheit
    402
    PoC-Steuerserver
    403,404
    PoC-Client-Einheiten
    405–417
    Verabeitungsschritte
    420–424
    Nachrichten

Claims (13)

  1. Verfahren zum Anfordern eines Push-to-talk-Sprachrechts im Rahmen einer Push-to-talk-Kommunikation und/oder zum Erfragen von Warteschlangeninformation über eine Warteschlange, die Einträge aufweist, die jeweils einer Anforderung nach dem Push-to-talk-Sprachrecht im Rahmen der Push-to-talk-Kommunikation entsprechen und welche Warteschlange bei der Zuteilung des Push-to-talk-Sprachrechts berücksichtigt wird, wobei – eine Push-to-talk-Client-Einheit eine Real-Time-Control-Protocol-Nachricht erzeugt, die Warteschlangenverwaltungsinformation zur Verwaltung der Warteschlange enthält und/oder die Information enthält, dass die Push-to-talk-Client-Einheit Warteschlangeninformation erfragt; und – die Push-to-talk-Client-Einheit die Real-Time-Control-Protocol-Nachricht an einen Push-to-Talk-Steuerserverrechner sendet.
  2. Verfahren gemäß Anspruch 1, wobei die Warteschlangenverwaltungsinformation eine Priorität der Pushto-talk-Client-Einheit spezifiziert und/oder spezifiziert, dass die Push-to-talk-Client-Einheit eine Anforderung der Push-to-talk-Client-Einheit nach dem Push-to-talk-Sprachrecht zurücknimmt.
  3. Verfahren gemäß Anspruch 1 oder 2, wobei die Warteschlange von dem Push-to-Talk-Steuerserverrechner und/oder von einer Entscheidungseinheit verwaltet wird.
  4. Verfahren gemäß einem der Ansprüche 1 bis 3, wobei die erfragte Warteschlangeninformation die Information über die Position des Eintrags, der einer Push-to-talk- Sprachrechtsanforderung der Push-to-talk-Client-Einheit entspricht, und/oder die Angabe der kompletten Warteschlange ist.
  5. Verfahren gemäß einem der Ansprüche 1 bis 4, wobei der Push-to-talk-Steuerserverrechner das Push-to-talk-Sprachrecht unter Berücksichtigung der Warteschlange zuteilt und/oder eine Real-Time-Control-Protocol-Antwortnachricht mit der erfragten Warteschlangeninformation erzeugt und an die Pushto-talk-Client-Einheit übermittelt.
  6. Verfahren zum Zuteilen eines Push-to-talk-Sprachrechts im Rahmen einer Push-to-talk-Kommunikation und/oder zum Mitteilen von Warteschlangeninformation über eine Warteschlange, die Einträge aufweist, die jeweils einer Anforderung nach dem Push-to-talk-Sprachrecht im Rahmen einer Push-to-talk-Kommunikation entsprechen und welche Warteschlange bei der Zuteilung des Push-to-talk-Sprachrechts berücksichtigt wird, wobei – ein Push-to-talk-Steuerserverrechner eine Real-Time-Control-Protocol-Nachricht erzeugt, die Warteschlangenverwaltungsinformation zur Verwaltung der Warteschlange enthält und/oder die Information enthält, dass der Push-to-talk-Steuerserverrechner Warteschlangeninformation erfragt und/oder die Information enthält, dass der Push-to-talk-Steuerserverrechner Steuerinformation erfragt, die spezifiziert, wie das Push-totalk-Sprachrecht zugeteilt werden soll; und – der Push-to-talk-Steuerserverrechner die Real-Time-Control-Protocol-Nachricht an eine Entscheidungseinheit sendet.
  7. Verfahren gemäß Anspruch 6, wobei die Warteschlangenverwaltungsinformation eine Identifikation einer Push-to-talk-Client-Einheit enthält und eine Priorität der Push-to-talk-Client-Einheit spezifiziert und/oder spezifiziert, dass die Push-to-talk-Client-Einheit eine Anforderung der Push-to-talk-Client-Einheit nach dem Push-totalk-Sprachrecht zurücknimmt.
  8. Verfahren gemäß Anspruch 6 oder 7, wobei die Warteschlange von der Entscheidungseinheit verwaltet wird.
  9. Verfahren gemäß einem der Ansprüche 6 bis 8, wobei die erfragte Warteschlangeninformation die Information über die Position des Eintrags, der einer Push-to-talk-Sprachrechtsanforderung einer Push-to-talk-Client-Einheit entspricht, und/oder eine Information über den Gesamtzustand der Warteschlange ist.
  10. Verfahren gemäß einem der Ansprüche 6 bis 9, wobei die Entscheidungseinheit eine erste Real-Time-Control-Protocol-Antwortnachricht mit der erfragten Steuerinformation erzeugt und an den Push-to-talk-Steuerserverrechner übermittelt und/oder eine zweite Real-Time-Control-Protocol-Antwortnachricht mit der erfragten Warteschlangeninformation erzeugt und an den Push-to-talk-Steuerserverrechner übermittelt und/oder die Warteschlange unter Berücksichtigung der Warteschlangenverwaltungsinformation verwaltet.
  11. Push-to-talk-Client-Einheit eines Push-to-talk-Kommunikationssystems aufweisend: – eine Nachrichtenerzeugungseinheit, die eingerichtet ist, eine Real-Time-Control-Protocol-Nachricht zu erzeugen, die Warteschlangenverwaltungsinformation zur Verwaltung einer Warteschlange, die Einträge aufweist, die jeweils einer Anforderung nach einem Push-to-talk-Sprachrecht im Rahmen der Push-to-talk-Kommunikation entsprechen und welche Warteschlange bei der Zuteilung des Push-to-talk-Sprachrechts berücksichtigt wird, enthält und/oder die Information enthält, dass die Push-to-talk-Client-Einheit Warteschlangeninformation erfragt; und – eine Sendeeinrichtung, die eingerichtet ist, die Push-totalk-Client-Einheit die Real-Time-Control-Protocol-Nachricht an einen Push-to-Talk-Steuerserverrechner zu senden.
  12. Push-to-talk-Steuerserverrechner eines Push-to-talk-Kommunikationssystems aufweisend: – eine Nachrichtenerzeugungseinrichtung, die eingerichtet ist, – eine erste Real-Time-Control-Protocol-Nachricht zu erzeugen, die Warteschlangenverwaltungsinformation zur Verwaltung einer Warteschlange, die Einträge aufweist, die jeweils einer Anforderung nach einem Push-to-talk-Sprachrecht im Rahmen einer Push-to-talk-Kommunikation entsprechen und welche Warteschlange bei der Zuteilung des Push-to-talk-Sprachrechts berücksichtigt wird, enthält und/oder die Information enthält, dass der Pushto-talk-Steuerserverrechner Warteschlangeninformation erfragt und/oder die Information enthält, dass der Pushto-talk-Steuerserverrechner Steuerinformation erfragt, die spezifiziert, wie das Push-to-talk-Sprachrecht zugeteilt werden soll; und/oder – eine zweite Real-Time-Control-Protocol-Nachricht zu erzeugen, die von einer Push-to-talk-Client-Einheit erfragte Warteschlangeninformation enthält; und – eine Sendeeinrichtung, die eingerichtet ist, die erste Real-Time-Control-Protocol-Nachricht an eine Entscheidungseinheit zu senden und/oder die zweite Real-Time-Control-Protocol-Nachricht an die Push-to-talk-Client-Einheit zu senden.
  13. Entscheidungseinheit eines Push-to-talk-Kommunikationssystems, aufweisend: – eine Nachrichtenerzeugungseinheit, die eingerichtet ist, eine Real-Time-Control-Protocol-Nachricht zu erzeugen, die eine von einem Push-to-talk-Steuerserverrechner erfragte Warteschlangeninformation über eine Warteschlange, die Einträge aufweist, die jeweils einer Anforderung nach einem Push-to-talk-Sprachrecht im Rahmen der Push-to-talk-Kommunikation entsprechen und welche Warteschlange bei der Zuteilung des Push-to-talk-Sprachrechts berücksichtigt wird, enthält und/oder von einem Push-to-talk-Steuerserverrechner erfragte Steuerinformation enthält, die spezifiziert, wie das Push-to-talk-Sprachrecht zugeteilt werden soll; und – eine Sendeeinrichtung, die eingerichtet ist, die Real-Time-Control-Protocol-Nachricht an den Push-to-talk-Steuerserverrechner zu senden.
DE102004049907A 2004-10-13 2004-10-13 Verfahren zum Anfordern oder Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Erfragen oder Mitteilen von Warteschlangeninformation, Push-to-talk-Client-Einheit, Push-to-talk-Steuerserverrechner und Entscheidungseinheit Ceased DE102004049907A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE102004049907A DE102004049907A1 (de) 2004-10-13 2004-10-13 Verfahren zum Anfordern oder Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Erfragen oder Mitteilen von Warteschlangeninformation, Push-to-talk-Client-Einheit, Push-to-talk-Steuerserverrechner und Entscheidungseinheit
CNA2005100034598A CN1819671A (zh) 2004-10-13 2005-10-12 关于按键通话发言权和队列信息的方法及其相关装置
CN2012102118494A CN102710662A (zh) 2004-10-13 2005-10-12 关于按键通话发言权和队列信息的方法及其相关装置
US11/252,361 US7769403B2 (en) 2004-10-13 2005-10-13 Apparatus and method for requesting or allocating a push-to-talk right to talk and/or for requesting or communicating queuing information

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102004049907A DE102004049907A1 (de) 2004-10-13 2004-10-13 Verfahren zum Anfordern oder Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Erfragen oder Mitteilen von Warteschlangeninformation, Push-to-talk-Client-Einheit, Push-to-talk-Steuerserverrechner und Entscheidungseinheit

Publications (1)

Publication Number Publication Date
DE102004049907A1 true DE102004049907A1 (de) 2006-04-20

Family

ID=36120468

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102004049907A Ceased DE102004049907A1 (de) 2004-10-13 2004-10-13 Verfahren zum Anfordern oder Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Erfragen oder Mitteilen von Warteschlangeninformation, Push-to-talk-Client-Einheit, Push-to-talk-Steuerserverrechner und Entscheidungseinheit

Country Status (3)

Country Link
US (1) US7769403B2 (de)
CN (2) CN1819671A (de)
DE (1) DE102004049907A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008049061A2 (en) 2006-10-18 2008-04-24 Sony Online Entertainment Llc System and method for regulating overlapping media messages

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005039669B3 (de) * 2005-08-22 2007-01-04 Infineon Technologies Ag Verfahren zum rechnergestützten Erstellen einer Abstimmungs-Nachricht, Verfahren zum rechnergestützten Ermitteln mindestens eines Abstimmungs-Ergebnisses, Verfahren zum rechnergestützten Bearbeiten einer Abstimmungs-Nachricht, Transportprotokoll-Steuerungsprotokoll-Einheit, Konferenz-Abstimmungs-Auswerte-Einheit, Konferenz-Servereinheit und Kommunikations-Endgerät
DE102005043003A1 (de) * 2005-09-09 2007-03-22 Infineon Technologies Ag Telekommunikationskonferenz-Server, Telekommunikations-Endgerät, Verfahren zum Erzeugen einer Telekommunikationskonferenz-Steuernachricht, Verfahren zum Steuern einer Telekommunikationskonferenz, computerlesbare Speichermedien und Computerprogrammelemente
KR101066297B1 (ko) * 2005-09-30 2011-09-20 삼성전자주식회사 동시 다중 ＰｏＣ 멀티미디어 서비스 제공 방법 및 그 장치
CN100415017C (zh) * 2005-12-01 2008-08-27 华为技术有限公司 一种发言权控制方法、装置及系统
KR100748514B1 (ko) * 2006-01-13 2007-08-14 엘지전자 주식회사 Ｓｉｐ 기반 세션 서비스의 데이터 처리 방법 및 단말
US8023978B2 (en) * 2006-02-27 2011-09-20 Motorola Solutions, Inc. Method for providing enhanced floor control for group calls between a dispatch communications network and a cellular telephone communications network
CN100531419C (zh) 2006-03-25 2009-08-19 华为技术有限公司 PoC业务媒体请求的处理方法及装置
KR101183328B1 (ko) * 2006-07-10 2012-09-14 삼성전자주식회사 ＰｏＣ 세션에서 발언권 관리 규칙 전달과 적용 방법 및이를 구현하기 위한 시스템
US20080107092A1 (en) * 2006-11-08 2008-05-08 Pouya Taaghol Universal services interface for wireless broadband networks
US20080130528A1 (en) * 2006-12-01 2008-06-05 Motorola, Inc. System and method for barging in a half-duplex communication system
US20080225821A1 (en) * 2007-03-13 2008-09-18 Michael Faith Channel access arbitration mechanism for walkie-talkie devices
US8290134B2 (en) * 2007-07-26 2012-10-16 International Business Machines Corporation Managing conference calls via a talk queue
US8005497B2 (en) * 2007-08-20 2011-08-23 Cisco Technology, Inc. Floor control over high latency networks in an interoperability and collaboration system
EP2206310A1 (de) * 2007-10-08 2010-07-14 Telefonaktiebolaget LM Ericsson (PUBL) Floor-control in telekommunikations-konferenzanrufen
JP5741172B2 (ja) * 2011-04-19 2015-07-01 ソニー株式会社 情報処理装置、通信システムおよび情報処理方法
US9680658B2 (en) 2011-12-07 2017-06-13 Qualcomm Incorporated Collaborative group communication method involving a context aware call jockey
JP6252739B2 (ja) * 2013-09-13 2017-12-27 株式会社リコー 伝送管理システム、管理方法及びプログラム
US10735915B2 (en) 2016-11-04 2020-08-04 Samsung Electronics Co., Ltd. Method of operating terminal mission critical push to talk group participating in mission critical push to talk group call in off network

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2271690B (en) * 1992-10-17 1996-09-11 Motorola Israel Ltd A communications system
JP4326700B2 (ja) 1998-08-20 2009-09-09 クゥアルコム・インコーポレイテッド セルラ電話システム中の優先アクセスチャネル割当のためのシステムおよび方法
US20030078064A1 (en) * 2001-10-22 2003-04-24 Chan Victor H. System and method for queuing talk requests in wireless dispatch system
US20050164681A1 (en) * 2004-01-22 2005-07-28 Jenkins William W. Voice message storage in a push-to-talk communication system
US7433680B2 (en) * 2004-01-22 2008-10-07 Clarity Communications Systems Inc. Incoming call management in a push-to-talk communication system
US7668149B2 (en) * 2004-02-27 2010-02-23 Research In Motion Limited Methods and apparatus for facilitating concurrent push-to-talk over cellular (PoC) group communication sessions
US7398079B2 (en) * 2004-06-30 2008-07-08 Research In Motion Limited Methods and apparatus for automatically recording push-to-talk (PTT) voice communications for replay
US20060030347A1 (en) * 2004-07-16 2006-02-09 Deepankar Biswaas Virtual push to talk (PTT) and push to share (PTS) for wireless communications systems

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008049061A2 (en) 2006-10-18 2008-04-24 Sony Online Entertainment Llc System and method for regulating overlapping media messages
EP2082616A2 (de) * 2006-10-18 2009-07-29 Sony Online Entertainment LLC System und verfahren zum regulieren von sich überlappenden media-nachrichten
EP2082616A4 (de) * 2006-10-18 2014-05-07 Sony Online Entertainment Llc System und verfahren zum regulieren von sich überlappenden media-nachrichten
US8855275B2 (en) 2006-10-18 2014-10-07 Sony Online Entertainment Llc System and method for regulating overlapping media messages

Also Published As

Publication number Publication date
US7769403B2 (en) 2010-08-03
CN1819671A (zh) 2006-08-16
US20060084455A1 (en) 2006-04-20
CN102710662A (zh) 2012-10-03

Similar Documents

Publication Publication Date Title
DE102004049907A1 (de) Verfahren zum Anfordern oder Zuteilen eines Push-to-talk-Sprachrechts und/oder zum Erfragen oder Mitteilen von Warteschlangeninformation, Push-to-talk-Client-Einheit, Push-to-talk-Steuerserverrechner und Entscheidungseinheit
DE102005016587B4 (de) Verfahren zum Bilden einer gemeinsamen Kommunikationssitzung, Verfahren zum Bilden einer ersten Kommunikationssitzung und einer zweiten Kommunikationssitzung aus einer gemeinsamen Kommunikationssitzung und Kommunikationssitzungs-Steuerungs-Server
DE102005037569B4 (de) Verfahren zum Vergeben eines Kommunikationsrechts, Kommunikationskonferenz-Sitzung-Server und Kommunikationskonferenz-Sitzung-Server-Anordnung
DE102005043003A1 (de) Telekommunikationskonferenz-Server, Telekommunikations-Endgerät, Verfahren zum Erzeugen einer Telekommunikationskonferenz-Steuernachricht, Verfahren zum Steuern einer Telekommunikationskonferenz, computerlesbare Speichermedien und Computerprogrammelemente
DE112006001922B4 (de) Verfahren und Vorrichtung zur Vergabe von Zugangsberechtigungen ("Floor-Control") in einem Kommunikationssystem
DE102005002803B3 (de) Kommunikationssystem mit einer Konferenz-Servereinrichtung, einer Konferenz-Steuereinheit, mehreren Moderator-Einheiten, mehreren Telekommunikations-Einrichtungen und einem Verfahren zum Steuern einer Konferenz
WO2006086939A1 (de) Verwaltung dynamischer gruppen in einem push-to-talk over cellular kommunikationssystems
DE102005010038B4 (de) Verfahren zum Bereitstellen mehrerer Gruppen-Kommunikationsdienste, Gruppen-Kommunikationsdienst-System und Gruppen-Kommunikationsdienst-Server-Einheit
DE102006021375B4 (de) Verfahren zum Aufbau einer Push-to-talk-Kommunikationsverbindung
DE102005042141A1 (de) Konferenz-Kommunikationssystem, Verfahren zum Betreiben eines Konferenz-Kommunikationssystems, Notifizierungseinrichtung und Verfahren zum Notifizieren eines Kommunikationsendgeräts
EP2469885B1 (de) Verfahren zur Integration von Funktionen eines Telekommunikationsnetzes in ein Datennetz
DE102004063298B4 (de) Verfahren zum rechnergestützten Verwalten von Kommunikationsrechten zum Kommunizieren mittels mehrerer unterschiedlicher Kommunikationsmedien in einer Telekommunikations-Konferenz mit mehreren Telekommunikations-Einrichtungen
EP1859599B1 (de) Daten-Gruppenrufdienst
DE102005039668B4 (de) Verfahren zum rechnergestützten Bilden einer Konferenzsitzungs-Einladungsnachricht, Verfahren zum rechnergestützten Erzeugen einer Konferenzsitzung, Verfahren zum rechnergestützten Verarbeiten von Nachrichten in einer Konferenzsitzung, Konferenzsitzungs-Einladungsnachricht-Erzeugungseinheit, Konferenzsitzungs-Erzeugungseinheit und Kommunikations-Endgeräte
DE102004010925B9 (de) Verfahren und Kommunikationsanordnung zum Aufbauen einer Push-to-talk-Kommunikationsverbindung und Push-to-talk-Client-Einheit
DE102007058948A1 (de) Verfahren zum Ermitteln von mindestens einem Teilnehmergerät für eine Telekommunikationskonferenzsitzung, Telekommunikationskonferenz-Anordnung, und Telekommunikationskonferenzsitzungs-Server
DE102005039669B3 (de) Verfahren zum rechnergestützten Erstellen einer Abstimmungs-Nachricht, Verfahren zum rechnergestützten Ermitteln mindestens eines Abstimmungs-Ergebnisses, Verfahren zum rechnergestützten Bearbeiten einer Abstimmungs-Nachricht, Transportprotokoll-Steuerungsprotokoll-Einheit, Konferenz-Abstimmungs-Auswerte-Einheit, Konferenz-Servereinheit und Kommunikations-Endgerät
DE102005043006B4 (de) Kommunikationssystem, Kommunikationssitzungs-Server-Einheit, Medienverteilungs-Einheit und Verfahren zum Übertragen von Daten im Rahmen einer Kommunikationssitzung
WO2009153176A1 (de) Verfahren zur ermittlung aktiver kommunikationssitzungen und kommunikationssitzungs-informationsserver
DE102005039366B4 (de) Telekommunikations-Endgerät, Telekommunikationssystem, Telekommunikationssitzungs-Servereinheit, Verfahren zum Erzeugen und Senden einer Telekommunikationssitzungs-Nachricht, Verfahren zum Verwalten einer Telekommunikationssitzungs-Nachricht, Computerlesbare Speichermedien und Computerprogrammelemente
DE102004045193B3 (de) Push-To-Talk-Over-Cellular (PoC) Verfahren
DE102005007342B4 (de) Kommunikationssystem und Verfahren zum Betreiben eines Kommunikationssystems
DE102004040024B4 (de) Kommunikationssystem, Verfahren zum Betreiben eines Kommunikationssystems, Server, Verfahren zum Betreiben eines Servers, Push-to-talk-Client-Einheit und Verfahren zum Betreiben einer Push-to-talk-Client-Einheit
DE102010017925A1 (de) Verfahren und Vorrichtung zum Zuweisen einer Kontroll-Rolle einer kollaborativen Kommunikationssitzung und Verfahren und Vorrichtung zum Anfordern einer Kontroll-Rolle einer kollaborativen Kommunikationssitzung
DE102005053914B9 (de) Kommunikationssystem, Verfahren zum Betreiben eines Kommunikationssystems, Server-Einheit, Verfahren zum Betreiben einer Server-Einheit, Kommunikationsdienst-Client-Einheit und Verfahren zum Betreiben einer Kommunikationsdienst-Client-Einheit

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R082 Change of representative

Representative=s name: VIERING, JENTSCHURA & PARTNER, DE

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04Q0007060000

Ipc: H04W0004100000

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04Q0007060000

Ipc: H04W0004100000

Effective date: 20130219

R081 Change of applicant/patentee

Owner name: INTEL MOBILE COMMUNICATIONS GMBH, DE

Free format text: FORMER OWNER: INFINEON TECHNOLOGIES AG, 81669 MUENCHEN, DE

Effective date: 20130207

R082 Change of representative

Representative=s name: VIERING, JENTSCHURA & PARTNER MBB PATENT- UND , DE

Effective date: 20130207

Representative=s name: VIERING, JENTSCHURA & PARTNER, DE

Effective date: 20130207

R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final

Effective date: 20130615