DE60309567T2

DE60309567T2 - Verfahren und vorrichtung zum hinzufügen eines teilnehmers zu einem gruppendienst in einem gruppenkommunikationsnetzwerk

Info

Publication number: DE60309567T2
Application number: DE60309567T
Authority: DE
Inventors: Douglas M. San Diego CROCKETT; Eric C. Solana Beach ROSEN; Mark Del Mar MAGGENTI
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2002-02-14
Filing date: 2003-02-12
Publication date: 2007-08-02
Anticipated expiration: 2023-02-13
Also published as: ATE345017T1; CA2476277C; ES2274251T3; DE60309567D1; EP1474938A1; RU2316146C2; TW200303692A; KR100928859B1; AU2003211097B2; NZ534419A; EP1474938B1; DK1474938T3; KR20040077963A; US6873854B2; JP2005535156A; CN1643950A; JP2010158039A; US20030153339A1; CA2476277A1; BR0307646A

Description

GEBIET
Die vorliegende Erfindung bezieht sich auf Punkt-zu-Multi-Punkt-Kommunikationssysteme. Insbesondere bezieht sich die vorliegende Erfindung auf ein Verfahren und eine Vorrichtung für das Hinzufügen neuer Mitglieder zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk.
HINTERGRUND
Eine Klasse von Drahtlosdiensten für eine schnelle, effiziente Eins-zu-Eins- oder Einer-zu-Vielen-(Gruppen-)-Kommunikation gibt es in verschiedenen Formen seit vielen Jahren. Im Allgemeinen waren diese Dienste Halb-Duplex, wobei ein Benutzer einen "Push-to-Talk"-(PTT)-Taste auf seinem Telefon/Funkgerät drückt, um Sprache zu initiieren. Das Drücken der Taste aktiviert sein Funkgerät in einigen Implementierungen oder zeigt in einem moderierten System, in dem die Kommunikationen über einen Server irgendeiner Art auftreten, die Anfrage des Benutzers nach "Floor" bzw. "Sprechrecht" auf. Wenn ihm Sprechrecht gewährt wird oder eine Sprechererlaubnis, dann spricht der Benutzer im Allgemeinen für ein paar Sekunden, nach denen er die PTT-Taste freigibt und andere Sprecher können das Sprechrecht nachfragen. Die Kommunikation ist im Allgemeinen von einem Sprecher zu einer Gruppe von Zuhörern, aber kann auch Eins-zu-Eins sein. Dieser Dienst wurde herkömmlicher Weise in Anwendungen verwendet, in denen eine Person, ein "Dispatcher" bzw. "Einteiler", mit einer Gruppe von Leuten kommunizieren muss, wie beispielsweise Außendienstpersonal oder Taxifahrern, woher der "Dispatch"-Name für diese Art von Dienstes stammt.
Ähnliche Dienste sind im Internet angeboten worden und sind allgemein als "Sprachchat" bekannt. Diese Dienste werden üblicherweise als PC-Anwendungen (PC = personal computer) implementiert, die Vocoderrahmen in Internet-Protocol-(IP)-Paketen senden, d.h. Voice-over-IP-(VoIP)-Dienst zu einem zentralen Gruppenchatserver oder möglicherweise von Client zu Client in einem Peer-to-Peer-Dienst.
Ein Hauptmerkmal dieser Dienste ist, dass die Kommunikation schnell und spontan ist, üblicherweise einfach durch Drücken einer PTT-Taste initiiert wird, ohne eine typische Wähl- und Klingelsequenz zu durchlaufen. Kommunikation in dieser Art von Dienst ist im Allgemeinen sehr kurz, wobei individuelle Sprach-"Spurts" bzw. -"Fetzen" bzw. -"Abschnitte" im Allgemeinen in der Größenordnung von einigen Sekunden sind und "Konversationen" möglicherweise eine Minute oder weniger dauern.
Die Zeitverzögerung zwischen dem Zeitpunkt, wenn der Benutzer das Sprechrecht anfragt und wenn er eine positive oder negative Bestätigung von dem Server empfängt, dass er Sprechrecht hat und mit dem Sprechen beginnen kann, die als die PTT-Latenzzeit bekannt ist, ist ein kritischer Parameter für Halb-Duplex-Gruppenkommunikationssysteme. Wie zuvor erwähnt setzen Dispatch-Systeme eine Priorität auf kurze, schnelle Konversationen, was den Dienst weniger effektiv macht, wenn die PTT-Latenzzeit lang wird.
Bestehende Gruppenkommunikationsinfrastrukturen sehen begrenzte Möglichkeiten vor, die PTT-Latenzzeit signifikant zu verringern, d.h. die tatsächliche PTT-Latenzzeit kann möglicherweise nicht weiter reduziert werden als auf die Zeit, die benötigt wird, um Verkehrskanäle innerhalb ruhender Paketdatensitzungen wieder aufzubauen. Weiter werden Sprecher- und Zuhörerverkehrskanäle in Serie hochgebracht, weil der einzige Mechanismus, der verfügbar ist, um zu beginnen, eine ruhende Gruppe aufzuwecken, der ist, darauf zu warten, dass der Verkehrskanal des Sprechers wieder aufgebaut wird, um dem Server zu signalisieren. Momentan gibt es keinen Mechanismus, um von einem Mobiltelefon stammende Benutzersignalisierungsdaten auf irgendetwas anderem als einem Verkehrskanal zu senden – eine Einschränkung die erfordert, dass Verkehrskanäle wieder aufgebaut sind, bevor irgendeine Kommunikation zwischen Clients und dem Server stattfinden kann.
Es gibt daher einen Bedarf an Mechanismen, um sowohl die offenkundige PTT-Latenzzeit, die von dem Sprecher erfahren wird, zu reduzieren als auch die Gesamtzeit, die benötigt wird, um Verkehrskanäle für teilnehmende Mobiltelefone wieder aufzubauen, ohne die Systemkapazität, die Teilnehmerbatterielebensdauer oder andere Ressourcen negativ zu beeinflussen.
In einem Dispatch-Modell findet Kommunikation zwischen Endpunkten statt innerhalb virtueller Gruppen, wobei die Stimme eines "Sprechers" zu einem oder mehreren "Zuhörern" ausgestrahlt wird. Auf ein einzelnes Vorkommen dieser Art von Kommunikation wird im Allgemeinen als ein Dispatch-Anruf Bezug genommen oder einfach als ein Anruf. Ein Anruf ist eine Schaffung bzw. Instantiierung einer Gruppe, welche die Charakteristika des Anrufs definiert, und ist im Wesentlichen eine Mitgliederliste mit einiger assoziierter Information, wie beispielsweise einem Gruppennamen oder einer Gruppen-ID bzw. -Kennung. Eine Mitgliederliste ist eine Liste von einem oder mehreren Benutzern, die eingeladen werden an dem Anruf teilzunehmen.
Es gibt einen Bedarf nach einem Dispatch-Modell, das sowohl das Chat-Room-Modell als auch das Ad-Hoc-Modell von Gruppenanrufdiensten unterstützt. In dem Chat-Room-Modell sind die Gruppen vordefiniert, wobei dies auf dem Dispatch-Server gespeichert sein kann. In dem Ad-Hoc-Model jedoch können die Gruppen definiert und/oder modifiziert werden in Echtzeit. Die Internationale Patentanmeldung WO 95/23475 offenbart ein Verfahren und ein System zur Steuerung eines Anrufs in einem Telekommunikationssystem, welches ein Telekommunikationsnetzwerk und eine erste Teilnehmerstation und eine oder mehrere andere Teilnehmerstationen aufweist, mit denen eine Teilnehmerstation, zum Beispiel ein Dispatcher bzw. Einteiler, der an einer Telekommunikationsverbindung teilnimmt, die Gruppe der Teilnehmerstationen, beispielsweise der Mitglieder, die an dem Anruf teilnehmen, reduzieren kann, ohne den bestehenden Anruf zu unterbrechen.
ZUSAMMENFASSUNG DER ERFINDUNG
Das Verfahren und die Vorrichtung der Erfindung sind in den unabhängigen Ansprüchen definiert.
Die offenbarten Ausführungsbeispiele sehen ein Verfahren in einem Kommunikationsgerät vor zum Hinzufügen eines Mitgliedes zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk, welches das Empfangen einer Mitgliederliste von einem Benutzer und das Senden einer Anfrage an einen Server, die Mitgliederliste zu dem aktiven Gruppenanruf hinzuzufügen, aufweist, und weist weitere Schritte in dem kennzeichnenden Teil des Anspruchs 1 auf.
Gemäß einem weiteren Aspekt verkörpert ein computerlesbares Medium in einem Kommunikationsgerät ein Verfahren zum Hinzufügen eines Mitgliedes zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk, wobei das Verfahren die oben erwähnten Schritte beinhaltet.
Gemäß einem weiteren Aspekt beinhaltet eine Vorrichtung für das Hinzufügen eines Mitgliedes zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk Mittel zum Empfangen einer Mitgliederliste von einem Benutzer und Mittel zum Senden einer Anfrage an einen Server, die Mitgliederliste zu dem aktiven Gruppenanruf hinzuzufügen, und weist weitere Mittel im kennzeichnenden Teil von Anspruch 13 auf.
Die Vorrichtung zum Hinzufügen eines Mitglieds zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk kann einen Empfänger, einen Sender und einen Prozessor, der kommunikativ an den Empfänger und den Sender gekoppelt ist, aufweisen. Der Prozessor ist in der Lage, eine Mitgliederliste von einem Benutzer zu empfangen und eine Anfrage an einen Server zu senden, die Mitgliederliste zu dem aktiven Gruppenanruf hinzuzufügen. Gemäß einem Aspekt ist das Kommunikationsgerät ein Push-to-Talk-(PTT)-Gerät.
Die offenbarten Ausführungsbeispiele sehen auch ein Verfahren in einem Server für das Hinzufügen eines Mitgliedes zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk vor, welches die folgenden Schritte aufweist: Empfangen einer Anfrage, eine Mitgliederliste von einem aktiven Gruppenanruf hinzuzufügen und Hinzufügen der Mitgliederliste von dem aktiven Gruppenanruf. Gemäß einem Aspekt weist das Verfahren weiter auf, jedem Mitglied in der Mitgliederliste bekanntzugeben, dass es dem Gruppenanruf hinzugefügt wird.
Gemäß einem weiteren Aspekt der Erfindung verkörpert ein computerlesbares Medium in einem Server ein Verfahren für das Hinzufügen eines Mitglieds zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk, wobei das Verfahren die oben erwähnten Schritte aufweist.
Gemäß einem weiteren Aspekt der Erfindung weist ein Server für das Hinzufügen eines Mitgliedes zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk Mittel auf für das Empfangen einer Anfrage, eine Mitgliederliste zu einem aktiven Gruppenanruf hinzuzufügen, auf und Mittel für das Hinzufügen einer Mitgliederliste zu dem aktiven Gruppenanruf. Gemäß einem Aspekt weist der Server weiter Mittel auf, um jedem Mitglied in der Mitgliederliste bekanntzugeben, dass es dem Gruppenanruf hinzugefügt wird.
Gemäß einem weiteren Aspekt der Erfindung weist ein Server zum Hinzufügen eines Mitgliedes zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk einen Empfänger, einen Sender und einen Prozessor, der kommunikativ an den Empfänger und den Sender gekoppelt ist, auf. Der Prozessor ist in der Lage, eine Anfrage, eine Mitgliederliste zu einem aktiven Gruppenanruf hinzuzufügen, zu empfangen und die Mitgliederliste des aktiven Gruppenanrufs hinzuzufügen. Gemäß einem Aspekt ist der Prozessor weiter in der Lage, jedem Mitglied in der Mitgliederliste bekanntzugeben, dass es dem Gruppenanruf hinzugefügt wird.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Merkmale und Vorteile der vorliegenden Erfindung werden offensichtlicher aus der unten dargelegten detaillierten Beschreibung, wenn diese in Verbindung mit den Zeichnungen gesehen wird, in denen gleiche Bezugszeichen durchgehend Gleiches identifizieren, und in denen:
1 ein Gruppenkommunikationssystem darstellt;
2 darstellt, wie mehrere Anwendungen miteinander interagieren;
3 einen beispielhaften Benutzerregistrierungsprozess gemäß einem Ausführungsbeispiel darstellt;
4 einen beispielhaften lokalen, intra-regionalen Anrufaufbauprozess gemäß einem Ausführungsbeispiel darstellt;
5 einen beispielhaften entfernten, intra-regionalen Anrufaufbauprozess gemäß einem Ausführungsbeispiel darstellt;
6 einen beispielhaften lokalen, inter-regionalen Anrufaufbauprozess gemäß einem Ausführungsbeispiel darstellt;
7 einen beispielhaften entfernten, inter-regionalen Anrufaufbauprozess gemäß einem Ausführungsbeispiel darstellt;
8 einen beispielhaften Prozess für das Verlassen eines Gruppenanrufs gemäß einem Ausführungsbeispiel darstellt;
9 einen beispielhaften Prozess des Beendens eines Gruppenanrufs gemäß einem Ausführungsbeispiel darstellt;
10 einen beispielhaften Prozess für das Senden eines Hinweises für einen Gruppenanruf gemäß einem Ausführungsbeispiel darstellt;
11 einen beispielhaften Prozess für das späte Beitreten zu einem Gruppenanruf gemäß einem Ausführungsbeispiel darstellt;
12 einen beispielhaften Prozess für das Vorrang-Geben bzw. Pre-Empting eines Sprechers gemäß einem Ausführungsbeispiel darstellt;
13 einen beispielhaften Prozess für das Hinzufügen neuer Mitglieder zu einem aktiven Gruppenanruf gemäß einem Ausführungsbeispiel darstellt;
14 einen beispielhaften Prozess für das Entfernen von Teilnehmern aus einem Gruppenanruf gemäß einem Ausführungsbeispiel darstellt;
15 einen beispielhaften Prozess für das Entfernen einer Registrierung eines Benutzers gemäß einem Ausführungsbeispiel darstellt;
16 darstellt, wie mehrere Kommunikationsgeräte mit einem Kommunikationsmanager gemäß einem Ausführungsbeispiel agieren;
17 das Puffern von Medien auf der Seite des Kommunikationsmanagers gemäß einem Ausführungsbeispiel darstellt; und
18 das Puffern von Medien auf der Clientseite gemäß einem Ausführungsbeispiel darstellt.
DETAILLIERTE BESCHREIBUNG
Bevor ein Ausführungsbeispiel der Erfindung im Detail beschrieben wird, soll klar sein, dass die Erfindung in ihrer Anwendung nicht auf die Details der Konstruktion und der Anordnung der Komponenten, die in der folgenden Beschreibung dargestellt sind oder in den Zeichnungen gezeigt sind, beschränkt ist. Die Erfindung ist im Stande, in anderen Ausführungsbeispielen implementiert zu werden und auf verschiedene Arten ausgeführt zu werden. Auch ist klar, dass die Ausdrucksweise und Terminologie, die hierin verwendet wird, zum Zweck der Beschreibung dient und nicht als einschränkend angesehen werden sollte.
1 stellt ein beispielhaftes funktionales Blockdiagramm eines Gruppenkommunikationssystems 100 dar. Das Gruppenkommunikationssystem 100 ist auch bekannt als ein Push-to-Talk-(PTT)-System, ein Net-Broadcast-Dienst (NBS = net broadcast service), ein Dispatch-System oder ein Punkt-zu-Multi-Punkt-Kommunikationssystem. In einem Ausführungsbeispiel weist das Gruppenkommunikationssystem 100 Anwendungsserverkomponenten auf, wie beispielsweise Dispatcher bzw. Einteilungselemente, Standortserver bzw. Positionsserver, Mediensteuereinheitskomplexe bzw. MCU-Komplexe (MCU = media control unit), Verwendungslogserver bzw. Usage-Log-Server und Internet-Protokoll-(IP)-Clients (drahtlose und/oder drahtgebundene Geräte mit IP- Konnektivität). Die Anwendungsserverkomponenten können entweder in einem zentralisierten Einsatz eingesetzt werden oder in einem regionalisierten Einsatz, basierend auf der Funktionalität der Komponente. Der zentralisierte Einsatz kann einen Heimat-Dispatcher (HD = home dispatcher) 102, einen Heimatstandortserver (HLS = home location server) 104 und eine Benutzer/Gruppen-Datenbank 106 aufweisen. Diese Komponenten können zentral in dem Netzwerk des Dienstproviders angeordnet sein und können zugänglich sein für die regionalen Einsätze. Die zentralisierten Komponenten können für die Lokalisierung der roamenden Benutzer verwendet werden und für die Initialisierung inter-regionaler Gruppenanrufe. Ein regionalisierter Einsatz 108, 110 kann einen regionalen Standortserver (RLS = regional location server) 112, einen regionalen Dispatcher (RD) 114, einen regionalen Mediensteuereinheits-(MCU = media control unit)-Komplex 116 und einen regionalen Verwendungslogserver (ULS = usage log server) 118 aufweisen.
Die regionalen Einsätze (regional deployments) können über das Netzwerk des Dienstproviders verteilt sein, um sicherzustellen, dass die Netzwerkverzögerungen, die mit dem Anrufaufbau assoziiert sind, auf einem Minimum gehalten werden, zu dem Zweck, die Instant-Response- bzw. Sofortige-Antwort-Anfrage zu erfüllen. Das Verteilen der Anruflast über mehrere regionalisierte Systeme stellt auch sicher, dass adäquate Skalierungsschemata entwickelt werden können, um eine große Anzahl von Benutzern unterstützen zu können. Die regionalisierten Anwendungsserverkomponenten sehen Benutzerregistrierung, intra-regionalen Anrufaufbau und -management, und Hinweisinitiierung und -lieferung für die Benutzer, die in der Region registriert sind, vor.
Die Gruppenkommunikationsgeräte (Clients) 120, 122, welche in dem cdma2000-Handgerät eingesetzt werden können, fragen beispielsweise eine Paketdatensitzung an, wobei sie eine Standarddatendienstoption verwenden, und verwenden diese Sitzung, um ihre IP-Adresse bei dem Anwendungsserver zu registrieren und um Gruppenanrufinitialisierungen auszuführen. In einem Ausführungsbeispiel sind die Anwendungsserverkomponenten 108, 110 mit den Paketdatendienstknoten (PDSNs = packet data service nodes) des Dienstproviders verbunden. Die Clients 120 und 122 besitzen beim Anfragen einer Paketdatensitzung von der drahtlosen Infrastruktur IP-Konnektivität zu den Anwendungsserverkomponenten 108, 100 durch die PDSNs.
Beim Einschalten können die Clients 120, 122 eine Paketdatensitzung anfragen, wobei die Datendienstoption verwendet wird. Als Teil der Einrichtung der Paketdatensitzung wird dem Client eine IP-Adresse zugewiesen. Zu diesem Zeitpunkt empfängt der Client auch die Adresse des DNS-Servers (DNS = domain name service) 124. Der Client 120, 122 fragt beim DNS-Server 124 an, z.B. unter Verwendung einer SRV-Nachfrage (SRV = service record), um die Adresse des RLS 112 zu finden. Nach der Lokalisierung von RLS 112 kann der Client 120, 122 eine Registrierung durchführen, wobei der Anwendungsserver über seine Standortinformation, z.B. die IP-Adresse, benachrichtigt wird. Die Registrierung kann durchgeführt werden unter Verwendung eines IP-Protokolls, wie beispielsweise eines Session-Initiation-Protocols (SIP) bzw. Sitzungsinitialisierungsprotokolls (SIP = session initiation protocol) über das Benutzerdatagrammprotokoll (UDP = user datagram protocol). Die IP-Adresse des Clients 120, 122 kann verwendet werden, um den Client zu kontaktieren, wenn der Benutzer zu einem Gruppenanruf eingeladen wird.
In einem Ausführungsbeispiel kann der Client, nachdem die Registrierung vollständig ist, eine weitere DNS-SRV-Aufzeichnungsnachfrage bzw. -anfrage ausführen, um die Adresse des regionalen Dispatchers 114 zu finden. Der Client kontaktiert den regionalen Dispatcher immer dann, wenn der Benutzer anfragt, einen Anruf zu beginnen oder eine Warnung sendet. Die Schnittstelle zwischen dem regionalen Dispatcher 114 und Client 120, 124 kann das Signalisierungsprotokoll über UDP sein.
Sobald ein Gruppenanruf aufgebaut ist, tauschen Client 120, 114 und MCU-Komplex 116 Medien und Signalisierungsnachrichten. In einem Ausführungsbeispiel können Medien zwischen den Anrufteilnehmern und dem MCU-Komplex 116 gesendet werden unter Verwendung von Echtzeitprotokoll (RTP = real-time protocol) über UDP. Die Signalisierungsnachrichten können auch ein Signalisierungsprotokoll über UDP sein. Diese Protokolle und die Funktionalität die sie vorsehen werden später beschrieben.
Komponenten
Das Gruppenkommunikationssystem 100 kann die IP-Endpunkte aufweisen, die die Client-Software und regionalisierte und zentralisierte Serverkomponenten beinhalten, die benötigt werden, um den Gruppenkommunikationsdienst anzubieten. Die Gruppenkommunikations-Clients und die Anwendungsserverkomponenten sind in größerem Detail in den folgenden Abschnitten beschrieben.
Clients
Der Gruppenkommunikations-Client 120, 122 kann auf jedem IP-Endpunkt, der Zugriff zu dem passenden Vocoder (den passenden Vocodern) hat, ablaufen. Die IP-Endpunkte können Anwendungen aufweisen, die auf einem drahtlosen System ablaufen, z.B. cdma2000, einer Anwendungsentwicklungsplattform, z.B. einer binären Laufzeitumgebung für drahtlose Umgebungen bzw. BREW (BREW = binary runtime environment for wireless), und auf PCs.
Der Client kann eine Softwareanwendung aufweisen, die entwickelt werden kann unter Verwendung von BREW, und bildet eine Schnittstelle zu der Modemsoftware der Mobilstation (MSM = mobile station modem), die auf den Client heruntergeladen werden kann, der die BREW-Umgebung enthält. BREW ist eine Plattform, die Entwicklern gestattet, Anwendungen zu entwerfen, die auf Client-Kommunikationsgeräten operieren können. BREW sieht eine Isolationsschicht bzw. Trennschicht zu dem Anwendungsentwickler vor, was die Entwicklung von Anwendungen ermöglicht, ohne direkten Kontakt in die MSM-Software und die Originalausrüstungsherstellersoftware bzw. OEM-Software (OEM = original equipment manufacturer) zu haben. Dies gestattet, dass die Anwendungen schnell entwickelt werden können und sich unabhän gig von der MSM- und/oder OEM-Software weiterentwickeln. Es ermöglicht Anwendungen auch, auf jedes Gerät heruntergeladen zu werden, das die BREW-Umgebung enthält. Wie in 2 gezeigt, kann die Client-Gruppenkommunikationsanwendungssoftware 202 parallel mit anderen Anwendungen 204, 206, 208, 210 ausgeführt werden. Während diese Dienste direkt durch die OEM-212- und MSM-214-Schnittstellen angeboten werden können, sieht BREW eine Isolation hinsichtlich Modifikationen vor, die durch die Anwendung in diesen Schichten stattfinden. Dies gestattet der OEM 212 und MSM 214 sich getrennt von den Datenanwendungen 202, 204, 206, 208, 210 zu entwickeln.
Damit der Client effektiv auf einem PC arbeitet, kann der PC Zugriff zu einem kompatiblen Vocoder beinhalten, Zugriff zu Soundtreibern und IP-Konnektivität zu Anwendungsservern.
Standortserver
In einem Ausführungsbeispiel kann der Standortserver (LS = location server) Benutzerstandortinformation annehmen und/oder verwalten, d.h. die Netzwerklevel-IP-Adresse, den physischen Standort des Benutzers, wie beispielsweise die Längen- und Breitengrade, und/oder die Paketzonen-ID bzw. -Kennung, d.h. ein Systemidentifizierer, der über die Luftschnittstelle auf Vorwärts-Gemeinsamkanälen ausgestrahlt wird, welches den Umfang des PDSNs identifiziert, welcher den Paketdatendienst für diesen Sektor vorsieht. In einem Ausführungsbeispiel kann der LS eine Komponente aufweisen, die die Registrierungen von den Clients verarbeitet und Benutzerstandortinformation zu anderen Anwendungen, wie beispielsweise Instant-Messaging, die eine SIP-Schnittstelle verwenden, liefert.
Der LS kann zwei funktionale Elemente aufweisen, den regionalen Standortserver (RLS = regional location server) 112 und den Heimatstandortserver (HLS = home location server) 104. RLS 112 kann auf einer Region-zu-Region- Basis eingesetzt werden und der HLS 104 kann zentralisiert sein. Die Details dieser Elemente und ihre Funktionen werden unten beschrieben.
Regionaler Standortserver
Der RLS 112 kann Registrierungen von Clients, die sich innerhalb seiner Region befinden, verarbeiten und verwalten. In einem Ausführungsbeispiel ist der RLS 112 ein standardmäßiger SIP-basierter LS, mit assoziiertem Speicher für die Benutzerstandortinformation. Als Teil der Verwaltung der Registrierungseinträge, kann der RLS 112 die Ablaufdaten, "Verfalls"-Felder, für jede Registrierung prüfen. Der RLS stellt sicher, dass die abgelaufenen Einträge entfernt werden, und dass sowohl der regionale Dispatcher (RD) als auch der HLS über die entfernten Einträge benachrichtigt werden.
Wie zuvor beschrieben, können die Clients eine IP-Registrierung ausführen, um den Anwendungsserver über ihren Standort zu benachrichtigen. Die Clients können ihre Registrierungen für die Dauer ihrer Verfügbarkeit für den Gruppenkommunikationsdienst aufrechterhalten. Die Clients können Wieder-Registrierungen bzw. erneute Registrierungen durchführen, wenn sich die IP-Adresse der Clients verändert und wenn die Registrierung kurz davor steht abzulaufen.
Wenn sich die Clients registrieren oder erneut registrieren, dann kann der RLS 112 seinen assoziierten RD 114 benachrichtigen. Dies gestattet dem RD 114 die Benutzerdaten in Vorbereitung für Anrufaufbauanfragen vorzuladen, um somit die die Anrufaufbauzeit zu reduzieren. Der RD 114 kann die Standortinformation des Benutzers cachen, was die Notwendigkeit des RD 14 eliminiert, den RLS zu kontaktieren, um Benutzerstandortinformation während des Anrufaufbaus abzurufen.
Der RLS 112 kann den RD 114 für den Fall benachrichtigen, dass die Standortinformation des Benutzers aktualisiert oder entfernt wird vom RLS 112. Dies stellt sicher, dass RLS 112 und RD 114 synchronisiert bleiben mit der neuesten Information über Benutzer, die innerhalb der Region registriert sind.
Der RLS 112 kann auch den HLS 104 periodisch mit Standortinformation der registrierten Benutzer aktualisieren. Für den Fall, dass der RLS 112 eine Registrierung zum dem HLS 104 für einen Benutzer sendet, der bereits eine gültige Registrierung in einer anderen Region besitzt, kann der HLS den Konflikt auflösen.
Heimatstandortserver
Der HLS 104 kann Anfragen nach Benutzerstandortinformation verarbeiten. In einem Ausführungsbeispiel sieht HLS 104 eine SIP-basierte Schnittstelle vor, um anderen Anwendungen, wie beispielsweise Instant-Messaging-Anwendungen, zu gestatten, die Standortinformation für einen speziellen Benutzer anzufragen.
Falls der HLS 104 eine zentralisierte Komponente ist und die RLSs mit ihm kommunizieren, dann kann der HLS Mehrfachregistrierungen in verschiedenen Regionen für roamende Benutzer auflösen. Der HLS 104 kann Registrierungsinformation von jedem der RLSs empfangen. Falls der HLS 104 Mehrfachregistrierungen für den gleichen Benutzer empfängt, kann der HLS 104 die aktuellste Registrierung beibehalten und eine Entfernung der abgelaufenen Registrierungen) des Benutzers von den RLSs anfragen. Dies wiederum kann die Entfernung der gecachten Information für diesen Benutzer vom RD 114 auslösen, der mit dem RLS assoziiert ist, der die abgelaufene Registrierung enthält.
Dispatcher
Der Dispatcher kann einen Anrufaufbau erleichtern durch Lokalisierung der Benutzer und Zuweisen von Gruppenanrufen zu dem Mediensteuereinheitskomplex (MCU-Komplex) 116. Der Dispatcher ist die Serverkomponente, die zentral ist, um die "Instant-Access"- bzw. "Sofortiger-Zugriff"-Anforderung zu erfüllen. Um die geringsten Anrufaufbauzeiten sicherzustellen, kann der Dispatcher zwei funktionale Elemente mit ähnlicher Struktur und Funktionalität aufweisen, die jedoch unterschiedliche Einsatzstrategien besitzen. Diese zwei Elemente, der regionale Dispatcher (RD) 114 und der Heimatdispatcher (HD) 102 sind im Detail in den folgenden Abschnitten beschrieben.
Regionaler Dispatcher
Der RD 114 kann der Ausgangspunkt eines Kontaktes für Anrufaufbauanfragen und Hinweisanfragen sein. Der RD 114 kann Benutzerinformation vorladen, wenn er eine Anzeige von dem RLS 112 empfängt, dass ein Benutzer registriert worden ist. Zusammen mit der Benutzerinformation kann der RD 114 Information über Gruppenanrufe cachen, die in dem System ablaufen. Der RD 114 kann die gecachte Information für Benutzer oder Gruppen während des Anrufaufbaus verwenden, um die Aufbauzeit auf einem Minimum zu halten, d.h. keine Datenbanknachfragen bzw. -abfragen werden benötigt.
In einem Ausführungsbeispiel weist die Gruppeninformation, die der RD in dem Cache speichert, die Gruppenmitgliederliste und die Adresse des MCU-Komplexes 116 auf, auf dem die Gruppe stattfindet. Der RD 114 kann die Mitgliederliste und die MCU-Adresse für die Dauer des Anrufs verwalten. Dies hilft dem RD 114, schnell zu bestimmen, ob eine ankommende Anrufanfrage eine Gruppendefinition enthält, die identisch zu derjenigen ist, die einen assoziierten Anruf besitzt, der bereits in dem System abläuft, was dem RD gestattet, schnell auf Anrufaufbauanfragen zu antworten und zuverlässig die "Sprechrecht"-Anfrage in der Antwort zu gestatten oder abzulehnen.
Der RD 114 kann die Sprechrechtsteueranfrage gestatten oder ablehnen. Der RD 114 kann entscheiden, ob er bei dem MCU-Komplex 116 anfragen wird, den Benutzer zu dem Anruf als einen "Spätbeitritts"-Teilnehmer hinzuzufügen oder ob er einen neuen Anruf mit der assoziierten Teilnehmerliste beginnt.
Während der Anrufaufbauanfrageverarbeitung kann der RD 114 die gecachte Benutzerinformation verwenden, um die Standortinformation für die Benutzer, die in der Anrufaufbauanfrage spezifiziert sind, abzurufen. Falls ein Benutzer nicht lokalisiert werden kann, kann der RD 114 bei dem HD 102 anfragen, den Benutzer zu lokalisieren. In einem Ausführungsbeispiel fährt, wenn wenigstens ein oder mehrere Zielbenutzer lokalisiert sind, der RD 114 mit dem Anrufaufbau fort. Nachdem die Ziele lokalisiert worden sind, kann der RD 114 entscheiden, welcher MCU der Anruf zugewiesen werden sollte. Diese Bestimmung kann auf den IP-Adressen der Benutzer in der Gruppe, einschließlich veranlassenden Teilnehmers bzw. des Ausgangspunktes (Originator), basieren.
Der RD 114 kann Hinweisanfragen ähnlich wie Anrufanfragen handhaben. In einem Ausführungsbeispiel wird die Hinweisanfrage dem lokalen MCU-Komplex zur Verarbeitung zugewiesen, unabhängig vom Standort der Ziele.
In einem Ausführungsbeispiel kann die Information in dem Cache des RDs periodisch auf einen zuverlässigen Speichermechanismus geschrieben werden, so dass sie für den Fall eines Versagens wiederhergestellt werden kann. Nach der Wiederherstellung nach dem RD-Versagens kann die Benutzer- und Gruppeninformation, die auf den zuverlässigen Speichermechanismus geschrieben worden ist, wieder bzw. erneut in den Cache geladen werden, und der RD fährt damit fort, die gecachte bzw. zwischengespeicherte Information in Verbindung mit der Verarbeitung der ankommenden Anrufaufbauanfragen zu validieren bzw. zu überprüfen.
In einem Ausführungsbeispiel lädt RD 114 die Benutzerdaten in den lokalen Cache bei jeder Benutzerregistrierungsbenachrichtigung von RLS 112. Durch Eliminieren der Notwendigkeit zum Anrufaufbauzeitpunkt mehrere Datenbankanfragen auszuführen, reduziert der RD 114 signifikant die Zeitdauer, die benötigt wird, um dien Anrufaufbauanfragen oder Hinweisanfragen zu überprüfen und darauf zu antworten.
Der RD 114 kann auf die Benutzer/Gruppendatenbank 106 während des Anrufaufbaus zugreifen, um vordefinierte Gruppenadressen, falls diese in der Anfrage vorhanden sind, zu erweitern, und zwar auf Listen von individuellen Benutzern, und falls notwendig, um alternative Identifizierer von Benutzern oder Gruppen, wie z.B. Telefonnummern, Konferenz-IDs bzw. -Kennungen in (eine) kanonische Adresse(n) zu übersetzen.
Heimatdispatcher
Heimatdispatcher (HD) 102 kann die Standortinformation der registrierten Benutzer verfolgen. Der HD kann Standortinformation für die Benutzer enthalten, die Registrierungen mit RLS 112 ausgeführt haben.
Wie zuvor beschrieben, kann jeder RLS 112 einen assoziierten RD 114 jedes Mal dann benachrichtigen, wenn eine Benutzerregistrierung, erneute Registrierung, Ent-Registrierung oder ein Registrierungsablauf bzw. -verfall auftritt. RD 114 kann diese Information verwenden, um Benutzerinformation in seinen lokalen Cache zu laden oder freizugeben. Jeder RD 114 kann den HD 102 mit Benutzerstandortinformation aktualisieren. Da der HD 102 Aktualisierungen von RD 114 empfängt, kann HD 114 das Auffinden von Benutzern, die geographisch über verschiedene Regionen verteilt sind, unterstützen. Der RD 114 kann Unterstützung vom HD 102 anfragen, wenn er eine Anfrage nach einem Benutzer empfängt, der momentan nicht innerhalb der Region registriert ist, d.h. sich nicht im Benutzerinformationscache des RDs befindet.
DNS-Server
In einem Ausführungsbeispiel kann das Gruppenkommunikationssystem 100 den DNS-Server 124 des Dienstproviders verwenden, um Standortinformation für RLS 112 und RD 114 an die Clients zu liefern. Diese Information kann bei jedem regionalen Einsatz konfiguriert werden und periodisch aktualisiert werden, um ihre Richtigkeit zu gewährleisten.
In einem Ausführungsbeispiel erfährt jeder Client die Adresse des DNS-Servers durch Internetprotokollsteuerprotokollaushandlung (IPCP-Aushandlung, IPCP = Internet protocol control protocol) während der Einrichtung einer PPP-Sitzung (PPP = point-to-point protocol), wenn er eine Paketdatensitzung anfragt. Der DNS-Server 124 kann auf diese Weise auf einer Region-zu-Region-Basis angeboten werden. Das gestattet dem Client, von Region zu Region zu roamen und mit dem DNS-Server 124 in der gleichen Region, in der der Client liegt, zu kommunizieren. Der DNS-Server 124 wird auf einer Region-zu-Region-Basis eingesetzt in Verbindung mit jedem PDSN. In einem Ausführungsbeispiel kann der DNS-Server 124 mit jedem RD 124 und RLS aktualisiert werden, der den PDSN versorgt, mit dem der DNS-Server 124 assoziiert ist.
In einem Ausführungsbeispiel ist der Mechanismus, der verwendet wird, um den geeigneten RD 114 und RLS 112 zu lokalisieren auf einer Kombination aus DNS- und SIP-Adressierung basiert. Die DNS-Dienst-(SRV)-Aufzeichnungsnachfrage kann auf dem "<domain>"-Teil des SIP-URI, unter dem sich der Client registriert, durchgeführt werden. Die SRV-Aufzeichnungsnachfrage kann das Protokoll oder den Dienst aufweisen, den bzw. das der Anfrager versucht zu finden. Für den Fall zum Beispiel, das versucht wird, den RLS 112 zu lokalisieren, kann der Client einen "Registrierungsdienst" in der DNS-SRV-Aufzeichnungsnachfrage anfragen. Die DNS-Antwort kann eine oder mehrere gültige Netzwerk- oder Portadressen für den Server aufweisen, die den angefragten Dienst anbieten. Der DNS-Server 124 kann bei der Lastverteilung zwischen Servern verwendet werden, die den gleichen Dienst anbieten, und zwar durch gestatten, dass der DNS-Server 124 im Rundlauf bzw. Round-Robin-Verfahren zwischen den mehreren Servern wählen kann, und zwar beim Beantworten der Client-Anfragen.
Benutzer-/Gruppendatenbank
In einem Ausführungsbeispiel ist die Benutzer/Gruppendatenbank 106 der zentrale Aufbewahrungsort für die Benutzer- und Gruppeninformation. Für je den Benutzer kann die Datenbank Information, wie beispielsweise die Benutzeradresse, Pre-Emption-Rangfolge bzw. Vorrang-Rangfolge, Authentifizierungsinformation, Benutzerkontaktinformation und ein Lawful-Intercept-Flag bzw. Abhör-Flag aufweisen, welche anzeigt, ob der Benutzer unter Überwachung steht. Die Datenbank kann auch Definitionen von vordefinierten Gruppen aufweisen, welche Listen von Benutzern und ein assoziierter Gruppenname sind, und zwar für das Chat-Room-Modell des Dispatch-Dienstes. Jede Gruppe kann eindeutig durch beispielsweise die Gruppenadresse identifiziert werden. Der Client kann die Gruppenadresse verwenden, um die Gruppe in der Gruppenanrufaufbauanfrage zu identifizieren. Der RD 14 kann die Gruppenadresse verwenden, um die assoziierte Mitgliederliste von der Benutzer/Gruppendatenbank 106 abzurufen, wenn er eine Gruppenanrufaufbauanfrage von einer vordefinierten Gruppe darin empfängt.
Mediensteuereinheitskomplex
Der Mediensteuereinheitskomplex (MCU-Komplex) kann Mediensteuerhosts (MCH = media control host) und eine Mediensteuereinheit (MCU = media control unit) aufweisen. Der MCH kann mehrere MCU-Prozesse hosten und managen. Jeder MCU kann die Echtzeitsignalisierung und -medienverarbeitung für einen einzelnen Anruf handhaben. Die Funktionen, die die MCU für einen Anruf ausführt, können aufweisen:

– Handhaben der Anrufszuweisung von RD 114
– Senden von Last- und Statusinformation zu dem MCH
– Senden von Anrufinitialisierungsinformation zu den Clients
– Verarbeiten von In-Call-Signalisierung bzw. anrufsrelevanter Signalisierung von den Clients, wie beispielsweise PTT-Anfragen
– Sicherstellen, dass Signalisierungsnachrichten zuverlässig zu den Clients geliefert werden
– Kopieren und Verteilen Medien für "Einer-zu-Vielen"-Anrufen
– Vorsehen von Medienübersetzung unter Verwendung von geeigneten Transcodern für "gemischte" Vocoder-"Einer-zu-Vielen"-Anrufen
– Überwachen von Anrufaktivität und Initialisierung von Anrufbeendigung basierend auf Medienflussinaktivität
– Erzeugen von Benutzerinformation für Verwendungslogserver (ULS) 118
– Weiterleiten von Medien und Signalisierungsinformation zu dem geeigneten Abhörpunkt wenn dies angefragt wird.

Die MCU kann Hinweisanfragen von RD 114 verarbeiten, Hinweisbenachrichtigungen zu den Clients aussenden und auf Bestätigungen von den Clients warten. Auf den Empfang von Bestätigungen der Ziele hin, gibt die MCU jegliche Ressourcen, die der Hinweistransaktion zugewiesen sind, frei. Zu diesem Zeitpunkt kann die MCU andere Anrufzuweisungen oder Hinweisanfragen handhaben.
Verwendungslogserver
Der ULS 118 kann in jeder Region vorhanden sein und kann zusammen mit dem MCU-Komplex 116 angeordnet sein. Der ULS 118 kann Verwendungsereignisse vom MCU-Komplex 116 für jede Anruf- oder Hinweisverarbeitung sammeln, sie in eine Verwendungsdatenaufzeichnung (UDR = usage data record) formatieren und dann diese UDRs in einer Sequenz von UDR-Dateien speichern. Die UDRs für Anrufe können Informationen bezüglich individueller Anrufe, einschließlich der Liste von Teilnehmern und der Teilnehmerverwendungsgesamtzahl enthalten. Der UDR für Hinweise kann Information enthalten, die den Ausgangspunkt des Hinweises anzeigt und die Zielbenutzer, zu denen der Hinweis gesendet worden ist. Die UDR-Dateien können von dem Dienst-Provider für Zwecke der Rechnungsanalyse gesammelt werden, und können nach einer festgelegten Zeitdauer gelöscht werden.
Der ULS 118 kann einen einzelnen UDR pro Anrufvorkommnis am Ende jedes Anrufs schreiben. Der ULS 118 kann auch eine einzelne UDR jedes Mal dann schreiben, wenn eine Hinweisanfrage verarbeitet worden ist. UDRs, die von dem ULS 118 geschrieben worden sind, können die folgende Information enthalten:

– Anrufvorkommnisidentifizierer oder Hinweisvorkommnisidentifizierer
– MCU-Identifizierer, welche auch den Anrufstandort implizieren. Zu Beginn eines Anrufs kann eine geeignete MCU basierend auf dem registrierten Standort aller vorgeschlagenen Teilnehmer ausgewählt werden. Der Standort der MCU kann oder kann auch nicht in der gleichen Region wie der Ausgangspunkt bzw. veranlassende Teilnehmer sein.
– Startzeit des Anrufs oder Hinweises
– Endzeit des Anrufs oder Hinweises
– Ursprungsbenutzername und/oder Identifizierer
– Ursprungsbenutzer-IP-Adresse
– Für jeden Teilnehmer: Benutzername, Benutzeradresse, Benutzer-IP-Adresse, kumulierte bzw. aufgelaufene Teilnahmezeit, welche für Hinweise Null sein kann, und Gesamtzahl von Sekunden, die der Teilnehmer das Sprechrecht verwendet hat, welche für Hinweise Null sein kann.

In einem Ausführungsbeispiel wird für jeden Anruf eine einzelne UDR ausgegeben, die die Gesamtsammlung von Sprachsegmenten während des Anrufs repräsentieren kann. Falls UDR-Ereignis-Aufzeichnung auf einer Sprachsegmentbasis benötigt wird, kann dieses auf Kosten zusätzlicher Verarbeitungslast, Datei-I/O, und Festplattenplatzanforderungen implementiert werden.
Das Gruppenkommunikationssystem 100 führt mehrere verschiedene Funktionen aus, um die Gruppendienste zu betreiben. Diese Funktionen, die sich auf Benutzererfahrungen beziehen, weisen Folgendes auf: Registrierung, Anrufinitialisierung, Anrufbeendigung, Senden von Hinweisen, spätes Beitreten, Sprechervermittlung, Hinzufügen von Benutzern, Entfernen von Mitgliedern, Ent-Registrieren, Adressieren und Authentifizierung. Diese Funktionen, die sich auf Systemvorbereitung und den Betrieb beziehen, weisen Folgendes auf: Verwaltung und Bereitstellung, Skalierbarkeit und Zuverlässigkeit. Diese Funktionen werden im Detail in den folgenden Abschnitten beschrieben.
Registrierung
In einem drahtlosen Kommunikationssystem, z.B. einem CDMA-System, ist eine Registrierung der Prozess, durch den eine Mobilstation der drahtlosen Systeminfrastruktur ihren Standort bekannt gibt. Diese Standortinformation kann das geographische Gebiet, in dem sich die Mobilstation befindet, aufweisen und die Identifizierung der Basisstation, die die Mobilstation versorgt, die verwendet kann, um die effiziente Verwendung der Paging- und Zugriffskanäle zu unterstützen.
In einem Ausführungsbeispiel ist die Benutzerstandortinformation die IP-Adresse des Clients, unabhängig davon, ob der Client über drahtlose oder drahtgebundene Dienste verbunden ist. Ein beispielhaftes IP-Protokoll, das IP-Anwendungen ermöglicht, Clients basierend auf ihrer IP-Adresse zu lokalisieren, ist das Sitzungsinitialisierungsprotokoll (SIP = session initiation protocol). Neben anderen Funktionen sieht das SIP Verfahren für Clients vor, ihre IP-Adresse und andere Standortinformation bei einer SIP-Serverkomponente zu registrieren. Zusätzlich sieht das SiP Verfahren für IP-Anwendungen, die an dem "Auffinden" von Clients interessiert sind, vor, um dieselbe SIP-Serverkomponente nach Standortinformation, wie beispielsweise der IP-Adresse des Clients, zu fragen.
Die Registrierung kann den Vorgang eines IP-Clients, der mit einer SIP-Serverkomponente kommuniziert, um seine Standortinformation, z.B. seine IP-Adresse bekanntzugeben und beizubehalten, aufweisen. Die SIP-Serverkomponente, die diese Funktionalität vorsieht, ist der Standortserver. Das Verfahren, durch welches ein Client den Standortserver über seinen Standort oder Veränderungen seines Standorts benachrichtigt ist das SIP-REGISTRIERUNGS- bzw. SIP-REGISTER-Verfahren.
In einem Ausführungsbeispiel registrieren die Clients ihre Standortinformation bei einem regionalen Standortserver. Andere IP-basierte Anwendungen, wie zum Beispiel Instant Messaging, können davon profitieren, Kenntnis über die IP-Adresse jedes Clients zu haben, der in dem Standortserver verfügbar ist. Ein externer Dienst oder der Client können die Registrierung durchführen. 3 zeigt einen beispielhaften Anrufablauf für das das Durchführen der Registrierungsfunktion.
Beim Einschalten 302 kann der Client eine Paketdatensitzung anfragen und den Prozess der Registrierung seiner IP-Adresse bei RLS 112 beginnen. Um die Registrierung auszuführen, kann der Client eine DNS-SRV-Aufzeichnungsnachfrage 304 ausführen, um die Adresse des RLS zu bestimmen. Sobald die RLS-Adresse abgefragt worden ist 306, kann der Client seine Standortinformation registrieren, z.B. durch Verwendung einer SIP-Registrierungsnachricht 308. Der RLS kann den Benutzer authentifizieren 310 und eine Antwort 312 an den Client ausgeben. Der RLS kann den regionalen Dispatcher benachrichtigen 314, dass der Benutzer registriert worden ist, und der regionale Dispatcher kann diese Information verwenden, um die Datenaufzeichnung, die mit dem Benutzer assoziiert ist, vorzuladen, um eine schnellere Antwortzeit während des Anrufaufbaus zu ermöglichen. An diesem Punkt kann der Client mit einer Einladung, an einem Gruppenanruf teilzunehmen, kontaktiert werden. In einem Ausführungsbeispiel müssen Clients möglicherweise eine Registrierung durchführen, um einen Gruppenanruf zu empfangen, unabhängig von der Art der Datenkonnektivität die sie besitzen, d.h. drahtlos oder drahtgebunden.
Registrierungen können ein "Verfalls"-Feld haben, das mit ihnen assoziiert ist, welches anzeigt, wie lange die Registrierungsinformation des Clients als gültig erachtet werden kann. Um zu garantieren, dass der Client über IP immer erreichbar ist, kann der Client den Ablauf seiner Registrierung kennen und eine erneute Registrierung vor dem Ablaufzeitpunkt durchführen. Registrierungen können auch aufgrund anderer Umstände ungültig werden oder ablaufen, wie beispielsweise wenn sich die IP-Adresse des Clients verändert oder die Datenverbindung zwischen dem Client und dem Standortserver getrennt wird. Die Clients können den Zustand ihrer Datenkonnektivität kennen und ob sich ihre IP-Adresse verändert hat.
Nachdem die anfängliche Registrierung abgeschlossen worden ist, kann ein Client seiner Paketdatensitzung gestatten, in den Ruhezustand zu gehen, was den dedizierten Verkehrskanal freigeben kann. Der Client kann seine Paketdatensitzung überwachen, um sicherzustellen, dass sie während Perioden ausgedehnter Ruhezustände gültig bleibt. Bedingungen, die die Gültigkeit der Sitzung beeinflussen beinhalten: das Bewegen in ein Gebiet mit einer unterschiedlichen Paketzonen-ID bzw. -Kennung, Erfahren eines Fades bzw. Schwundes oder Verlusts von Dienst und das Annehmen und/oder das Platzieren eines PSTN-Anrufs. Die IP-Adresse des Clients kann sich verändern und es kann für den Client erforderlich sein, die Datenkonnektivität zu der Infrastruktur wieder aufzubauen. Wenn der Client seine Paketdatensitzung wieder aufbaut, empfängt er eine neue IP-Adresse. Die neue IP-Adresse muss dem Standortserver mitgeteilt bzw, kommuniziert werden, um sicherzustellen, dass die Standortinformation des Clients korrekt bleibt. Dies kann erreicht werden durch Ausführen einer erneuten Registrierung.
Ein drahtgebundener Client, der mit dem Standortserver durch eine Firewall kommuniziert, muss möglicherweise durch periodisches "Pingen" des Standortservers die Öffnung durch die Firewall aufrecht erhalten. Dies wird erreicht durch Durchführen von erneuten Registrierungen.
Gruppenanrufinitialisierung
Nachdem die Registrierung vollständig ist, kann der Benutzer Anrufe tätigen oder empfangen. Vor der Initialisierung des ersten Anrufs nach dem Einschalten, kann der Client eine DNS-SRV-Aufzeichnungsnachfrage durchführen, um den Standort des regionalen Dispatchers zu finden. Dies kann als Teil des Startprozesses durchgeführt werden.
Eine "Gruppe" ist mit einem veranlassenden Teilnehmer assoziiert, dem Benutzer, der die Einrichtung der Gruppe initialisiert hat, und einer Mitgliederliste, welche den oder die Zielbenutzer enthält. Die Mitgliederliste kann einen oder mehrere Benutzer enthalten, eine oder mehrere vordefinierte Gruppen, oder eine Kombination der beiden. Falls die Mitgliederliste nur einen Benutzer enthält, wird auf den Anruf, der initialisiert wird unter Verwendung der Mitgliederliste im Allgemeinen als ein Privatanruf Bezug genommen. Falls die Mitgliederliste irgendeine vordefinierte Gruppe enthält, kann der regionale Dispatcher die vordefinierten Gruppen erweitern, und zwar auf eine Liste von einem oder mehreren Zielbenutzern, z.B. durch Ersetzen des Identifizierers der vordefinierten Gruppe in der Originalmitgliederliste durch die assoziierte Mitgliederliste der vordefinierten Gruppe. Nachdem die vordefinierten Gruppen erweitert worden sind, kann die resultierende Mitgliederliste nur Zielbenutzernamen enthalten. An diesem Punkt versucht der regionale Dispatcher, die Zielbenutzer in der Mitgliederliste zu lokalisieren, z.B. durch Scannen des Caches der Benutzerinformation des regionalen Dispatchers. Falls die Ziele in dem Cache des regionalen Dispatchers liegen, können die Mitglieder der Gruppe innerhalb der gleichen Region wie der regionale Dispatcher registriert werden. Diese Art von Gruppenanruf wird als ein "intra-regionaler" Anruf bezeichnet. Falls es Benutzer gibt, die der regionale Dispatcher nicht lokalisieren konnte, kann der regionale Dispatcher Unterstützung von dem Heimdispatcher anfragen, um die Benutzer zu lokalisieren. Auf einen Anruf, der mit einer Gruppe assoziiert ist, die Mitglieder aus zwei oder mehr Regionen enthält, wird als ein "inter-regionaler" Anruf Bezug genommen.
Nachdem der regionale Dispatcher bestimmt hat, ob der Anruf ein intra-regionaler oder ein inter-regionaler ist, kann er den Prozess der Bestimmung, welche Mediensteuereinheit (MCU) den Anruf hosten soll, beginnen. Für intra-regionale Anrufe kann der regionale Dispatcher den Anruf an eine MCU, die in der gleichen Region wie der regionale Dispatcher liegt, zuweisen, falls in dieser Region MCU-Ressourcen verfügbar sind. Auf den resultierenden Anruf, der diese Art von Anrufaufbau verwendet, wird als ein "lokal gehosteter" Anruf oder lokaler Anruf Bezug genommen. Für inter-regionale Anrufe kann der regionale Dispatcher eine Wahl haben, den Anruf an eine MCU innerhalb der gleichen Region oder in einer entfernten oder fremden Region zuzuweisen. Der regionale Dispatcher kann diese Entscheidung basierend auf der Stand ortinformation der Benutzer fällen, um den optimalen Reiseweg für die IP-Pakete, die Medien und Signalisierung enthalten, zu finden. Falls eine Mehrzahl der Benutzer in einer bestimmten Region angeordnet ist, kann der Anruf dieser Region zugewiesen werden. Falls die Benutzer gleichmäßig über Regionen verteilt sind, kann der Anruf einer der Regionen, die Zielbenutzer enthalten, zugewiesen werden. Falls der inter-regionale Anruf einer MCU in einer anderen Region als der Region, in der sich der regionale Dispatcher befindet, zugewiesen ist, wird auf den Anruf als "entfernt gehosteter" oder entfernter Anruf Bezug genommen. Der regionale Dispatcher kann Kenntnis über die Netzwerktopologie und/oder die Konnektivität zwischen den MCUs und den PDSNs, die sie versorgen, haben und kann diese Kenntnis verwenden, um eine bessere Entscheidung über die Zuweisung von Anrufen zu fällen.
Intra-regionale Anrufe
Das Gruppenkommunikationssystem 100 kann eingesetzt werden um sicherzustellen, dass der Großteil der Anrufe intra-regional ist. Intra-regionale Anrufe können die Notwendigkeit für eine Kommunikation zwischen dem regionalen Dispatcher 114 und dem Heimatdispatcher 102 zur Anrufaufbauzeit eliminieren. Die Notwendigkeit für eine Kommunikation zwischen den Regionen kann auch eliminiert werden, wenn die Ziele in der gleichen Region sind und der Anruf lokal gehostet wird, wie es der Fall ist für die Mehrzahl der intra-regionalen Anrufe. Die folgenden Abschnitte beschreiben Anrufabläufe, Zeitschätzungen und Nachrichtenübertragungsschemata für intra-regionale Anrufe.
Initialisierung eines lokalen Anrufs
4 stellt einen beispielhaften Nachrichtenfluss für das Beginnen eines lokalen Gruppenanrufs dar. Der Benutzer kann einen oder mehrere Zielbenutzer auswählen 402, einen oder mehrere vordefinierte Gruppen, oder eine Kombination der beiden und kann die Push-to-Talk-(PTT)-Taste drücken. Der Client kann eine Anfrage 404 zu dem regionalen Dispatcher senden, um den Grup penanruf aufzubauen, unabhängig davon, ob die Mobilstation einen dedizierten Verkehrskanal hat oder nicht, wie später in größerem Detail beschrieben wird. Nachdem die Anfrage gesendet worden ist, kann, falls die Paketdatensitzung der Mobilstation ruht, der Client den Prozess des Wiederaufbaus der dedizierten Verkehrskanäle initiieren und die Paketdatensitzung für Medienaktivität vorbereiten. Der Client kann für eine gewisse Zeitdauer Spracheingabe, empfangen von dem Ausgangspunkt, puffern.
Wenn der regionale Dispatcher die Anfrage empfängt, kann er die vordefinierten Gruppen erweitern, was in der Anfrage spezifiziert sein kann, und zwar in Zielbenutzermitgliederlisten. Dann kann der regionale Dispatcher die Standortinformation der Zielbenutzer abfragen 406. An diesem Punkt kann der regionale Dispatcher auch bestimmen, ob die Gruppe bereits in dem System stattfindet. 4 zeigt ein Szenario, in dem die Gruppe noch nicht stattfindet. Das Anrufsszenario des späten Beitretens, welches hierin später beschrieben wird, stellt den Fall dar, in dem Gruppe bereits stattfindet.
Nachdem der regionale Dispatcher mindestens einen der Zielbenutzer lokalisiert, kann der regionale Dispatcher eine Antwort 408 zurück zu dem Client senden, die anzeigt, dass der Gruppenanruf aufgebaut wird. An diesem Punkt kann der Client auf optimistische Weise die Anfrage des Ausgangspunktes bewilligen 410, zu sprechen und kann beginnen, seine Medien zu puffern 412.
Der regionale Dispatcher kann die Standorte der Zielteilnehmer verwenden, um die Region zu bestimmen, in welcher der Anruf zugewiesen werden kann. Falls bestimmt wird, dass die Zielbenutzer in der gleichen Region sind wie der regionale Dispatcher, wie in 4, kann der regionale Dispatcher den Anruf zu einer regionalen MCU zuweisen. Die MCU kann Ankündigungen 414 an die gesamte Gruppe aussenden, die anzeigen, dass der Anruf beginnt. Für die Zielbenutzer kann das Senden der Ankündigung auslösen, dass ihre Paketdatensitzungen aus dem Ruhezustand kommen und ihre Verkehrskanäle wiederaufbauen.
Nachdem der Client die Anrufankündigung der MCU empfangen hat und der Verkehrskanal der Mobilstation wieder aufgebaut worden ist, kann der Client die gepufferten Medien zu der MCU weiterleiten 416. Die MCU kann die Medien, die sie von dem Ausgangspunkt empfangen hat, puffern 418. In einem Ausführungsbeispiel kann die MCU die Medien puffern, bis die "Zielantwortschwelle" erreicht oder überschritten ist. Die Zielantwortschwelle ist eine Anzeige der Menge der Zielantworten, die benötigt werden, um mit dem Senden der Medien fortzufahren. Diese Schwelle kann ein konfigurierbarer Parameter sein. Sobald die Schwelle erreicht ist, repliziert und leitet die MCU die Medien zu den Zielbenutzern, die auf die Ankündigung für den Anruf geantwortet 422 haben, weiter 420.
Nachrichtenübertragung über einen kurzen Datenburst oder über kurze Datenbursts
Die "Instant Response" bzw. "sofortige Antwort" bezieht sich auf die Antwortzeit, die benötigt wird, damit der Anwendungsserver auf eine PTT- oder Anrufaufbauanfrage antwortet. Das Ziel zum Antworten auf irgendeine PTT-Anfrage, was Gruppenanrufaufbauanfragen mit einschließt, ist, konsistent auf die Anfrage in einer vorbestimmten Zeitperiode zu antworten, beispielsweise in einer Sekunde oder weniger. In vielen Fällen, wenn ein Benutzer anfragt einen Gruppenanruf aufzubauen, ist die Paketdatensitzung des Benutzers ruhend, und kein dedizierter Verkehrskanal existiert. Das erneute Einrichten von dedizierten Verkehrskanälen kenn beträchtliche Zeit dauern. Daher kann die Kommunikation zum Anwendungsserver durch gewisse andere Mittel erreicht werden.
Um sicherzustellen, dass das Gruppenkommunikationssystem die "sofortige Antwort" erfüllt, können kleine IP-Datagramme zu irgendeinem Zeitpunkt in jede Richtung gesendet werden, d.h. die vom Mobiltelefon ausgehen oder beim Mobiltelefon ankommen, und zwar unabhängig vom Zustand der Paketdatenzsitzung. In einem Ausführungsbeispiel können IP-Datagramme in Form einer kurzen Datenburstnachricht (SDB = short data burst) gesendet werden.
In Situationen, wo die Paketdatensitzung ruht, wird die SDB-Nachricht über die Overhead-Kanäle gesendet. Wenn eine Konnektivität für den dedizierten Verkehrskanal vorhanden ist, wird die SDB-Nachricht über den Verkehrskanal gesendet.
Mit Bezug auf 4 kann die Gruppenanrufaufbauanfrage 404 über eine SDB-Nachricht gesendet werden. Die Gruppenanrufaufbauantwort 408 vom Anwendungsserver kann auch in einer SDB-Nachricht gesendet werden. Die Anrufaufbauanfrage und die Antwortnachrichten, die über SDB-Nachrichten gesendet werden, können das Gruppenkommunikationssystem 100 befähigen, das Ziel der "sofortigen Antwort" bzw. "Instant Response" zu erfüllen.
Um den Prozess des Aufbaus des Gruppenanrufes zu vollenden, kann die MCU Anrufankündigungen an die Benutzer in der Teilnehmerliste senden, einschließlich des Ausgangspunkts. Diese Anrufankündigungen können über die dedizierten Verkehrskanäle gesendet werden. In den meisten Fällen ruhen die Paketdatensitzungen der Gruppenmitglieder, d.h. keine dedizierten Verkehrskanäle sind eingerichtet. Dies bedeutet, dass die MCU die Anrufankündigungsnachricht nach einem aggressiven Zuverlässigkeitszeitplan erneut senden muss, bis alle Verkehrskanäle der Mitglieder wieder eingerichtet worden sind, und bis die Mitglieder die Nachricht bestätigt haben, oder bis der Zuverlässigkeitstimer ausläuft. Das aggressive Senden der Anrufankündigung stellt sicher, dass die Medienpuffer auf dem Client und der MCU auf einem Minimum gehalten werden. Der Client kann gepufferte Medien senden, sobald sein Verkehrskanal eingerichtet ist und er eine Anrufankündigung erhält, die MCU-Kontaktinformation enthält. Die MCU kann gepufferte Medien replizieren und weiterleiten, sobald die Zielantwortschwelle erreicht oder überschritten wird. Dies bedeutet, dass je schneller die Ziele die Anrufankündigung erhalten und auf sie antworten, desto schneller kann diese Schwelle erreicht werden, und dann desto schneller kann die MCU die Pufferung stoppen und damit anfangen, Medien zu senden.
Die Anrufankündigung an den Ausgangspunkt kann auch über SDB gesendet werden. Dies bietet zwei Vorteile. Erstens, da die die Anrufankündigung MCU-Kontaktinformation enthält, kann der Gruppenanrufclient damit anfangen gepufferte Medien zu der MCU zu senden, sobald der Verkehrskanal der mobilen Station wieder eingerichtet ist, was die RAM-Anforderungen an der Mobilstation zum Halten der gepufferten Medien verringern kann. Zweitens, wenn der Ausgangspunkt entscheidet, den Anruf abzubrechen oder das Sprechrecht freizugeben, was auftreten kann, bevor der Verkehrskanal wieder aufgebaut wird, kann, wenn die Anrufankündigung über SDB hereinkommt, der Client die MCU mit dieser Information benachrichtigen. Die Einflüsse des Sendens der Anrufankündigung an den Ausgangspunkt über SDB sind eine Steigerung der Last auf den Gemeinsamkanälen und eine Anfrage für die MCU, der Anrufankunftsnachricht des Ausgangpunktes eine spezielle Handhabung zukommen zu lassen.
Initialisierung eines entfernten Anrufs
Intra-regionale Anrufe können lokal gehostet werden, wenn alle Mitglieder in der gleichen Region liegen. Der regionale Dispatcher kann einen intra-regionalen Anruf zu einer entfernten Region zuweisen, und zwar aufgrund, dass lokale Ressourcen überlastet oder nicht verfügbar sind. In solchen Fällen können die Medien und die Signale zusätzliche Latenzzeit und Fehler aufgrund von erweiterten Kommunikationspfaden zwischen dem PDSN des Benutzers und der entfernten MCU erfahren. 5 veranschaulicht einen beispielhaften Anrufaufbau für einen entfernten, intra-regionalen Anruf.
Das Initialisieren eines intra-regionalen Anrufs an einem entfernten Host ist ähnlich dem Anrufaufbauszenario, welches in Verbindung mit 4 besprochen wurde, mit der Ausnahme der Anrufzuweisung des regionalen Dispatchers zu einer MCU. Nachdem der regionale Dispatcher den Standort der Gruppenmitglieder abgerufen hat, kann er die MCU bestimmen, zu der der Anruf zugewiesen werden kann. Der regionale Dispatcher kann diese Entscheidung basierend auf der Standortinformation der Benutzer, der Last und der Verfügbarkeit der MCUs fällen. In einem intra-regionalen Anruf können die Benutzer in der gleichen Region gelegen sein, daher kann der regionale Dispatcher die Last und die Verfügbarkeit des MCU-Komplexes in der lokalen Region überprüfen. Wenn der regionale Dispatcher eine Anzeige empfängt, dass der lokale MCU-Komplex überlastet ist oder temporär Versagen bzw. Betriebsausfälle erfährt, dann kann er den Anruf einer entfernten MCU zuweisen. In einem Ausführungsbeispiel können die MCUs Kopien von identischer Funktionalität sein mit Ausnahme der Anrufkonfiguration; daher kann die entfernte MCU den Anruf ähnlich wie die lokale MCU handhaben.
Inter-regionale Anrufe
Das Gruppenanrufsystem 100 kann ausgelegt sein, um es einem Benutzer zu gestatten, mit irgendeinem anderen Benutzer zu kommunizieren, und zwar ungeachtet ihres physischen Standorts oder Nähe zueinander: Das Gruppenkommunikationssystem 100 kann eingesetzt werden, um die Anzahl der Anrufe zu begrenzen, die inter-regional sind, weil die inter-regionalen Anrufe eine Kommunikation zwischen dem regionalen Dispatcher und dem Heimatdispatcher beim Anrufaufbauzeitpunkt erfordern. Die Anrufzuweisung kann zu einer MCU sein, die in einer von einem oder mehreren der Anrufteilnehmer entfernten Region ist. Die folgenden Abschnitte beschreiben beispielhafte Anrufabläufe, Zeitschätzungen und Messaging-Schemata für inter-regionale Anrufe.
Initiierung eines lokalen Anrufs
6 veranschaulicht einen beispielhaften Nachrichtenablauf zum Starten eines lokal gehosteten bzw. ablaufenden Gruppenanrufs. Der Anrufaufbau für einen lokalen, inter-regionalen Anruf ist ähnlich dem Anrufaufbau für einen lokalen, intra-regionalen Anruf, wie in Verbindung mit 4 beschrieben, und zwar mit Ausnahme des Prozesses, bei dem der regionale Dispatcher die Lokalisierungsinformation für die Zielbenutzer abruft. In einem Ausführungsbeispiel versucht der regionale Dispatcher, die Zielbenutzer in seinem Cache zu lokalisieren. Wenn einige Benutzer nicht in dem Cache gefunden werden, kann der regionale Dispatcher Unterstützung vom Heimatdispatcher anfordern, um die Benutzer zu lokalisieren. Der Heimatdispatcher kann Benutzerstandortinformation für die Benutzer enthalten, die IP-Registrierungen unter Verwendung des regionalen Standortservers ausgeführt haben. Wie zuvor beschrieben, kann der regionale Standortserver seinen assoziierten regionalen Dispatcher jedes Mal dann benachrichtigen, wenn eine Benutzerregistrierung auftritt. Jeder regionale Dispatcher kann den Heimatdispatcher der Benutzerregistrierungen benachrichtigen. Dies gestattet dem Heimatdispatcher, die regionalen Dispatcher dabei zu unterstützen, Benutzer zu finden, die geographisch über unterschiedliche Regionen verteilt sind.
Initiierung eines entfernten Anrufs
7 veranschaulicht einen beispielhaften Aufbau für einen entfernten, inter-regionalen Anruf. Die Initiierung eines inter-regionalen Anrufs auf einem entfernten Host ist ähnlich dem Anrufaufbauszenario, wie es in Verbindung mit 4 beschrieben wurde, mit Ausnahme der Anrufzuweisung des regionalen Dispatchers zu einer MCU. Nachdem der regionale Dispatcher (RD) 114 den Standort der Gruppenmitglieder abruft, kann er die MCU bestimmen, zu der der Anruf zugewiesen werden kann. Der RD 114 kann diese Entscheidung basierend auf der Standortinformation des Benutzers, der Last und der Verfügbarkeit der MCUs fällen. Unter Verwendung der Standorte der Gruppenmitglieder versucht der RD, den optimalen Reise- bzw. Ausbreitungspfad für die IP-Pakete zu finden, die Medien und Signalisierung enthalten, und zwar über das Netzwerk des Dienstproviders für einen Großteil der Mitglieder. Wenn ein Großteil der Benutzer in einer bestimmten Region liegt, kann der Anruf dieser Region zugewiesen werden. Wenn die Benutzer gleich über Regionen verteilt sind, kann der Anruf einer der Regionen, die die Zielbenutzer enthält, zugewiesen werden.
Gruppenanrufbeendigung
Ein Gruppenanruf kann aus zwei Gründen enden: entweder haben alle Teilnehmer angefragt, den Anruf zu verlassen oder alle Teilnehmer haben für eine vorbestimmte Zeitperiode, die als "Hangtime" bzw. „Wartezeit" bezeichnet wird, aufgehört zu sprechen. Jeder Teilnehmer kann wählen, die Teilnahme an dem Anruf vor dem geplanten Ende des Anrufs zu beenden. Wenn alle Teilnehmer den Anruf verlassen, kann die MCU den Anruf beenden und alle Ressourcen freigeben, die diesem zugewiesen sind. Wenn alle außer einem Teilnehmer den Anruf verlassen, kann die MCU den Teilnehmer benachrichtigen, der als der "einsame Benutzer" bzw. "lonely user" bezeichnet wird. Der einsame Benutzer hat die Option, den Anruf sofort zu verlassen oder darauf zu warten, dass der Wartezeit-Timer ausläuft, was die MCU auslösen kann, den Anruf aufzugeben.
Die MCU kann den Anruf auf das Ablaufen des Wartezeit-Timers hin beenden. Die MCU kann jeden Sprach-Fetzen bzw. -Abschnitt verfolgen und einen Timer nach der Vollendung eines Sprach-Abschnitts stellen. Dieser Timer wird als der Wartezeit-Timer bezeichnet und kann die Dauer der Stille, d.h. keines Sprechens oder keiner Medienflussaktivität, in dem Anruf verfolgen. Wenn der Anruf für die Dauer der Wartezeit, die durch den Dienstprovider konfiguriert sein kann, stumm bleibt, kann die MCU annehmen, dass die Teilnehmer nicht länger am Anruf interessiert sind, und sie beendet daher den Anruf.
Vom Benutzer initiierte Anrufbeendigung
8 veranschaulicht ein beispielhaftes Szenario, in dem ein Benutzer gewählt hat die Teilnahme an einem Gruppenanruf zu beenden. Das Szenario bildet den Nachrichtenablauf ab, um die Teilnahme des Benutzers zu beenden. Wenn der Benutzer die Wahl trifft 802, die Teilnahme an dem Gruppenanruf zu beenden, kann der Client eine Anfrage an die MCU senden 804, den Benutzer von dem Anruf zu entfernen. Die MCU kann den Benutzer von dem Anruf entfernen 806 und den Client benachrichtigen, dass der Benutzer entfernt worden ist 810.
Vom Server initiierte Anrufbeendigung
9 veranschaulicht einen beispielhaften Nachrichtenfluss, der auftritt, wenn der Wartezeit-Timer abläuft und die MCU den Gruppenanruf beendet. Auf das Ablaufen des Wartezeit-Timers 902 hin kann die MCU den Teilnehmern eine Benachrichtigung senden 904, dass der Anruf endet. Jeder Client, der eine Anrufbeendigungsbenachrichtigung empfängt, kann mit einer Bestätigung antworten 906. Auf den Empfang der Bestätigungen hin kann die MCU den RD benachrichtigen 908, dass der Anruf geendet hat und kann die Ressourcen freigeben, die dem Anruf zugewiesen waren.
Senden eines Hinweises
Der Hinweismechanismus kann verwendet werden, um die Zielbenutzer zu benachrichtigen, dass ein anderer Benutzer, der Hinweisausgangspunkt bzw. der den Hinweis veranlassende Teilnehmer, einen Wunsch ausgedrückt hat, dass sie an einem Gruppenanruf teilnehmen. Der Hinweismechanismus kann eine Textnachricht enthalten, die es dem veranlassenden Teilnehmer gestattet, den Grund für den Anruf, die erwünschte Zeit des Anrufs zu beschreiben oder irgendwelche anderen, vom Benutzer anzupassenden Textnachrichten. 10 veranschaulicht einen beispielhaften Nachrichtenablauf, der auftritt, wenn ein Benutzer einen Hinweis sendet.
Der veranlassende Teilnehmer kann einen oder mehrere Zielbenutzer auswählen 1002, eine oder mehrere vordefinierte Gruppen, oder eine Kombination der beiden, und kann anzeigen, dass ein Hinweis gesendet werden könnte. Der Client kann eine Anfrage an den RD senden 1004, um Hinweise zu den Zielbenutzern auszusenden, die in der Anfrage spezifiziert sind. Wenn der RD die Anfrage empfängt 1006, kann er die vordefinierten Gruppen, die in der Anfrage spezifiziert sind, erweitern, und zwar in Zielbenutzermitgliederlisten, und der RD kann die Standortinformation der Zielbenutzer aufrufen. Nachdem der RD zumindest einen der Zielbenutzer lokalisiert hat, kann der RD eine Antwort zurück zum Client senden 1008. Der RD kann die Hinweisanfrage einer MCU zuweisen 1010, um Hinweisnachrichten zu den Zielbenutzern auszustrahlen 1012.
Wie in 10 bemerkt, können die Hinweisanfragen über einen kurzen Datenburst (SDB = short data burst) gesendet werden. Das Senden von Hinweisen über SDB-Nachrichten gestattet, dass die Paketdatensitzungen der involvierten Parteien ruhend bleiben. Die Hinweisbenachrichtigung enthält die notwendige Information, um zu gestatten, dass die Zielbenutzer Gruppenanrufe mit dem veranlassenden Teilnehmer bzw. Urheber und dem Rest der Zielbenutzer aufbauen, beispielsweise durch Auswahl einer Hinweisbenachrichtigung und das Drücken von PTT. Wenn dies auftritt, geht der Gruppenanrufaufbau in ähnlicher Weise voran wie das Anrufaufbauszenario; welches in Verbindung mit 4 beschrieben wurde.
Später Beitritt
Eine Gruppenanrufaufbauanfrage berücksichtigt einen späten Beitritt, wenn bestimmt wird, dass die Mitgliederliste, die in der Anrufaufbauanfrage festgelegt sein kann, identisch mit einer ist, die mit einem Anruf assoziiert ist, der schon in dem System im Gang ist. Diese Situation kann auf eine von zwei Arten auftreten. Erstens kann der Benutzer eine Mitgliederliste erzeugen, die identisch zu einer ist, die bereits einen Anruf mit sich assoziiert hat, beispielsweise durch Auswahl von genau dem (den) gleichen Benutzer(n) und/oder einer Gruppe (Gruppen), und durch das Drücken der PTT-Taste. Zweitens kann der Benutzer einen Anruf auswählen, der immer noch in dem System stattfindet, und zwar aus der Anrufliste vergangener Anrufe bzw. History-Liste und kann PTT drücken. In jedem Fall kann der RD detektieren, dass der Anruf, dessen Start der Benutzer angefordert hat, schon im Gange ist, und kann den Benutzer als einen späten Beitretenden behandeln.
11 veranschaulicht einen beispielhaften späten Beitrittsfall, in dem ein Benutzer einen Anruf aus der Anrufliste vergangener Anrufe auswählen kann. Der Benutzer kann einen Anruf aus der Anrufliste vergangener Anrufe auswählen 1102, und kann die PTT-Taste drücken. Der Client kann eine Anfrage an den RD senden 1104 den Gruppenanruf zu starten. Der RD kann bestimmen, dass der Anruf bereits stattfindet 1106 und kann eine Antwort 1108 an den Client senden, dass der Benutzer zu einem im Gange befindlichen Anruf hinzugefügt wird. Wenn der Anruf bereits stattfindet, könnte dem Benutzer das Sprechrecht nicht gestattet werden, weil ein gegenwärtiger Anrufteilnehmer schon das Sprechrecht zu dem Zeitpunkt besitzen kann, wenn der spät beitretende Benutzer vorbereitet wird, Medien zu empfangen, d.h. die Paketdatensitzung wird aus dem Ruhezustand gebracht. Der RD kann bei MCU, die den Anruf hostet, anfragen bzw. anfordern 1110, dass sie den spät beitretenden Benutzer zur Gruppe hinzufügt. Die MCU fügt den Benutzer hinzu und sendet 1112 eine Ankündigung an den Benutzer, die die Kontaktinformation der MCU enthält. Nachdem der Verkehrskanal des spät beitretenden Benutzers wieder eingerichtet ist, kann der Medienfluss in dem Anruf zu dem Benutzer übertragen werden. Zu diesem Zeitpunkt kann der spät beitretende Benutzer versuchen, das Privileg zu sprechen anzufragen.
Das Szenario des späten Beitritts ist ähnlich dem Szenario für die Initiierung eines neuen Gruppenanrufs, wie in Verbindung mit 4 beschrieben. Der unterscheidende Faktor ist, dass dem spät beitretenden Benutzer das Sprechrecht ansprechend auf die anfängliche Gruppenanrufaufbauanfrage verweigert wird.
Sprechervermittlung
In einem Ausführungsbeispiel wird jedem Gruppenanrufbenutzer ein Sprecher-Pre-Emption- bzw. -Vorrang-Rang zugewiesen, der bestimmt, welches Level an Rechten der Benutzer besitzt, wenn er Privilegien anfordert, das "Sprechrecht" zu ergreifen und zu sprechen zu beginnen. Nachdem der Gruppenanruf aufgebaut ist, kann die MCU für die Sprechrechtsteuerung verant wortlich sein und bestimmen, ob ein Teilnehmer, der das Sprechrecht anfordert, sprechen darf. Die MCU kann die Sprechervermittlung ausführen, wenn zwei oder mehr Anrufteilnehmer im Wettstreit um die Steuerung des Sprechrechts für eine spezielle Gruppe sind.
12 veranschaulicht die beispielhaften Ereignisse, die während eines Vermittlungsprozesses (arbitration process) auftreten können. Das Vermittlungsschema, welches in diesem Szenario verwendet wird, gestattet das Ausstechen des Benutzers B, wenn der Benutzer A das Sprechrecht anfordert. Der Benutzer B hat die Steuerung des Sprechrechts, d.h. der Benutzer B spricht, wenn der Benutzer A eine Erlaubnis zu sprechen durch das Drücken 1202 der PTT-Taste anfordert. Der Client kann eine Nachricht an die MCU senden 1204, die die Erlaubnis zu sprechen anfordert. Die MCU kann eine Sprechervermittlung ausführen 1206 und bestimmen, dass der Benutzer B ausgestochen wird und Benutzer A das Sprechrecht erteilt wird. Um eine Unterbrechung im Medienfluss sicherzustellen, d.h. der Benutzer B kann aufhören zu sprechen, bevor die Medien des Benutzers A übertragen werden, sendet 1208 die MCU zuerst eine Nachricht an den Client für den Benutzer B, die anzeigt, dass das Sprechrecht von einem anderen Benutzer übernommen worden ist und sendet 1210 dann eine Antwort, die das Sprechrecht für Benutzer A erteilt.
Hinzufügen von Benutzern zu einem aktiven Gruppenanruf
Das Gruppenkommunikationssystem 100 gestattet, dass ein Gruppenanrufteilnehmer neue Benutzer zu einem im Gang befindlichen Gruppenanruf hinzufügt. Dies wird dadurch erreicht, dass der Anrufteilnehmer einen oder mehrere Zielbenutzer auswählt, eine oder mehrere vordefinierte Gruppen oder eine Kombination der beiden, und anzeigt, dass der Teilnehmer möchte, dass die Ziele zu dem Gruppenanruf hinzugefügt werden, in dem sich der Teilnehmer gerade befindet. 13 veranschaulicht die Ereignisse, die auftreten, wenn neue Ziele zu einem Gruppenanruf hinzugefügt werden, der im Gang befindlich ist. Der Anrufteilnehmer kann einen oder mehrere Zielbenutzer, ei ne oder mehrere Gruppen oder eine Kombination der beiden auswählen 1302, die dem Anruf hinzugefügt werden sollen. Der Client kann eine Nachricht an den RD senden 1304, die anfordert, dass die spezifizierten Zielbenutzer dem im Gang befindlichen Gruppenanruf hinzugefügt werden, was in der Anfrage spezifiziert werden kann. Wenn der RD die Anforderung bzw. Anfrage empfängt, kann er die vordefinierten Gruppen, die in der Anfrage spezifiziert sind, erweitern, und zwar in Zielbenutzermitgliederlisten. Dann kann der RD die Standortinformation der Zielbenutzer abrufen 1306. Nachdem der RD zumindest einen der Zielbenutzer lokalisiert hat, kann der RD eine Antwort zurück an den Client senden 1308, die anzeigt, dass die Ziele dem Anruf hinzugefügt werden. Der RD kann eine Anfrage an die MCU senden 1310, die spezifizierten Benutzer zu dem Anruf hinzuzufügen. Die MCU kann Anrufankündigungen an die neuen Ziele aussenden 1312, die den Prozess beginnen können, ihre Paketdatensitzungen aus dem Ruhezustand zu bringen. Die Ankündigungen können gemäß einem Zuverlässigkeitsplan gesendet werden, um sicherzustellen, dass die Ziele die Nachricht empfangen. Nachdem die Verkehrskanäle der Ziele wieder eingerichtet sind, können die Ziele Bestätigungen an die MCU senden 1314. Die zusätzlichen Ziele können in die Medien- und Signalisierungskommunikation eingeschlossen werden 1316, die in dem Anruf stattfindet.
Entfernen von Mitgliedern aus einem aktiven Gruppenanruf
Das Gruppenkommunikationssystem 100 gestattet, dass ein Gruppenanrufteilnehmer Mitglieder aus einer aktiven Gruppe entfernt. In einem Ausführungsbeispiel kann dies dadurch erreicht werden, dass ein Anrufteilnehmer einen oder mehrere Zielteilnehmer auswählt und anzeigt, dass sie aus dem Gruppenanruf entfernt werden sollten. 14 veranschaulicht die beispielhaften Ereignisse, die auftreten können, wenn Teilnehmer aus einem im Gang befindlichen Gruppenanruf entfernt werden. Der Gruppenanrufteilnehmer kann einen oder mehrere Zielteilnehmer auswählen 1402, die aus dem Anruf zu entfernen sind. Der Client kann eine Nachricht an den RD senden 1404, die anfordert, dass die Ziele, die in der Nachricht spezifiziert werden können, aus dem Gruppenanruf entfernt werden. Wenn der RD die Anfrage empfängt, kann er die Standortinformation der Ziele abrufen 1406 und eine Antwort zurück an den Client senden 1408, die anzeigt, dass die Ziele entfernt werden. Der RD kann eine Anfrage an die MCU senden 1410, die Ziele aus dem Anruf zu entfernen. Die MCU kann Nachrichten an die Ziele, die in der Entfernungsanfrage spezifiziert werden können, senden 1412, die anzeigen sie aus dem Anruf entfernt werden. Die Ziele können Bestätigungen an die MCU senden 1414.
Ent-Registrierung
Wenn ein Benutzer nicht länger von dem Anwendungsserver oder von irgendeiner anderen IP-Anwendung kontaktiert werden möchte, die die IP-Adresse des Benutzers verwendet, um den Benutzer zu kontaktieren, kann die Ent-Registrierungsfunktion ausgeführt werden. Die Ent-Registrierungsfunktion entfernt die IP-Adresse des Benutzers und andere Kontaktinformationen aus dem RLS und macht jegliche Ressourcen frei, die bezüglich dieses Anwenders zuwiesen sind. 15 veranschaulicht, wie die Registrierung des Benutzers aus dem RLS als ein Ergebnis dessen entfernt wird, dass die Mobilstation abgeschaltet wird, und zwar gemäß einem Ausführungsbeispiel. Der Client kann eine Anzeige empfangen 1502, dass die Mobilstation, in der der Client liegt, abgeschaltet wird. Als ein Teil des Abschaltprozesses kann der Client eine Nachricht an den RLS senden 1504, die anzeigt, dass die Standortinformation des Benutzers entfernt werden sollte. Der RLS kann die Anfrage authentifizieren 1506, um sicherzustellen, dass sie von einer gültigen Quelle ist. Auf eine erfolgreiche Authentifizierung hin kann der RLS den Client mit einer Erfolgsanzeige benachrichtigen 1508, und kann den RD über die Entfernung des Benutzers benachrichtigen 1510. Der RD kann die Datenaufzeichnungen des Benutzers aus seinem Cache entfernen und kann die Ressourcen freimachen, die dem Benutzer möglicherweise zugewiesen waren. Im Fall eines Versagens der Ent-Registrierung kann die Standortinformation des Benutzers schließlich aus dem RLS entfernt werden, wenn die Zeit abgelaufen ist, die mit dem Verfallsfeld assoziiert ist.
In einem Ausführungsbeispiel unterstützt das Gruppenkommunikationssystem 100 sowohl das Chat-Raom-Modell als auch das Ad-Hoc-Modell. Im Chat-Room-Modell sind die Gruppen vordefiniert, die auf dem Dispatch-Server gespeichert werden können. Die vordefinierten Gruppen können öffentlich sein, was impliziert, dass die Gruppe eine offene Mitgliederliste hat, d.h. jeglicher Dispatch-Benutzer ist ein potentieller Teilnehmer. In dem Chat-Room-Modell wird der Anruf gestartet, wenn die erste Person wählt, dem Chat-Room beizutreten, und der Anruf bleibt am Laufen, wobei dem Anruf Serverressourcen zugewiesen werden, und zwar ungeachtet der Sprachaktivität, für eine vorbestimmte Zeitdauer, die durch den Dienstprovider konfiguriert werden kann. Benutzer fragen im Einzelnen an, diesen Arten von Anrufen beizutreten und diese zu verlassen. Während Perioden der Sprachinaktivität wird jeder Anruf in einen Gruppenruhezustand gebracht, wie später beschrieben wird, bis ein Benutzer eine Erlaubnis zu sprechen anfordert.
In dem Ad-Hoc-Model können Gruppen in Echtzeit definiert werden und können eine geschlossene Mitgliederliste, die mit ihnen assoziiert ist, haben. Eine geschlossene Mitgliederliste kann festlegen, welchen Benutzern es gestattet ist, an der Gruppe teilzunehmen, kann möglicherweise nicht für Benutzer außerhalb der geschlossenen Mitgliederliste verfügbar sein, und kann nur für die Dauer des Anrufs existieren. Ad-Hoc-Gruppendefinitionen müssen nicht notwendigerweise irgendwo gespeichert werden; sie können verwendet werden, um den Anruf einzurichten, und können aufgegeben werden, nachdem der Anruf geendet hat.
Eine Ad-Hoc-Gruppe kann gebildet werden, wenn ein ursprünglicher Benutzer einen oder mehrere Zielbenutzer auswählt und eine Anfrage erzeugt, die an einen Server gesendet wird, den Anruf zu starten. Den Zielbenutzern kann einen Benachrichtigung gesendet werden, dass sie in eine Gruppe aufgenommen sind und sie können automatisch dem assoziierten Anruf beitreten, d.h. möglicherweise kann keine Benutzerhandlung erforderlich sein. Wenn ein Ad-Hoc-Anruf inaktiv wird, können die Anwendungsserver den Anruf "abbrechen" und die Ressourcen freimachen, die diesem zugewiesen sind, ein schließlich der Gruppendefinition, die verwendet wurde, um den Anruf zu starten.
Wenn sie in dem Chat-Room-Modell, in dem Gruppenkommunikationssystem 100 arbeitet, kommuniziert eine Gruppe von Kommunikationsvorrichtungsbenutzern, die einzeln als Netzmitglieder bekannt sind, mit einander unter Verwendung einer Kommunikationsvorrichtung, die jedem Netzmitglied zugewiesen ist. Der Ausdruck "Netz" bezeichnet eine Gruppe von Kommunikationsvorrichtungsbenutzern, die autorisiert sind, um miteinander zu kommunizieren.
In einem Ausführungsbeispiel kann eine zentrale Datenbank Information enthalten, die die Mitglieder von jedem speziellen Netz identifiziert. Mehr als ein Netz kann in dem gleichen Kommunikationssystem arbeiten. Beispielsweise kann ein erstes Netz derart definiert sein, dass es zehn Mitglieder hat, und ein zweites Netz kann so definiert sein, dass es zwanzig Mitglieder hat. Die zehn Mitglieder des ersten Netzes können miteinander kommunizieren, jedoch können sie nicht mit Mitgliedern des zweiten Netzes kommunizieren. In einem anderen Ausführungsbeispiel können Mitglieder von unterschiedlichen Netzen Kommunikationen zwischen Mitgliedern von mehr als einem Netz überwachen, können möglicherweise jedoch nur Information an Mitglieder in ihrem eigenen Netz übertragen.
Ein Netz kann über existierendes Kommunikationssystem arbeiten, ohne wesentliche Veränderungen an der bestehenden Infrastruktur zu erfordern. Somit können eine Steuervorrichtung und Benutzer in einem Netz in einem beliebigen System arbeiten, welches Paketinformation unter Verwendung des Internet-Protokolls (IP) übertragen und empfangen kann, wie beispielsweise einem Codemultiplex-Vielfachzugriffssystem (CDMA-System, CDMA = Code Division Multiple Access), einem Zeitmultiplex-Vielfachzugriffssystem (TDMA-System, TDMA = Time Division Multiple Access), einem GSM-System (GSM = Global System for Mobile Communications), Satellitenkommunikationssystemen wie Globalstar^TM oder Iridium^TM, oder in einer Vielzahl von anderen Systemen.
Netzmitglieder können miteinander unter Verwendung eines zugewiesenen Kommunikationsgeräts kommunizieren, gezeigt als die Kommunikationsgeräte (CDs = communication devices) 120 und 122. Die CDs 120 und 122 können drahtgebundene oder drahtlose Kommunikationsgeräte sein, wie beispielsweise terrestrische drahtlose Telefone, drahtgebundene Telefone mit Push-to-Talk-Fähigkeit, Satellitentelefone, die mit einer Push-to-Talk-Funktionalität ausgestattet sind, drahtlose Videokameras, Standbildkameras, Audiogeräte wie beispielsweise Musikrecorder oder -abspielgeräte, Laptop- oder Desktopcomputer, Paginggeräte oder irgendeine Kombination davon. Beispielsweise kann das CD 120 ein drahtloses terrestrisches Telefon mit einer Videokamera und einer Anzeige aufweisen. Weiterhin kann jedes CD fähig sein, Information entweder in einem sicheren Modus oder einem freien Modus zu senden und zu empfangen. Während der folgenden Diskussion wird unter Benennung eines einzelnen CDs Bezug auf ein drahtloses Push-to-Talk-Telefon genommen. Es sollte jedoch verständlich sein, dass die Bezugnahme auf ein CD nicht auf dieses eingeschränkt sein soll und andere Kommunikationsgeräte umfassen kann, die die Fähigkeit aufweisen, Paketinformation gemäß dem Internet-Protokoll (IP) zu senden und zu empfangen.
In dem Gruppenkommunikationssystem 100 gestattet ein Übertragungs- bzw. Sende-Privileg im Allgemeinen einem einzelnen Benutzer, Information zu anderen Netzmitgliedern zu einem gegeben Zeitpunkt zu übertragen. Das Übertragungsprivileg wird einem anfragenden Netzmitglied erteilt oder verweigert, und zwar abhängig davon, ob das Übertragungsprivileg gegenwärtig einem anderen Netzmitglied zugewiesen ist oder nicht, wenn die Anfrage empfangen wird. Der Prozess des Erteilens und des Verweigerns von Übertragungsanfragen ist als Vermittlung (arbitration) bekannt. Vermittlungsschemata können Faktoren bewerten, wie beispielsweise Prioritätsniveaus, die jedem CD zugewiesen sind, die Anzahl der nicht erfolgreichen Versuche, das Übertragungs- bzw. Sendeprivileg zu erhalten, die Zeitdauer, die ein Netzmitglied das Sende-Privileg gehabt hat oder andere Faktoren, und zwar bei der Bestimmung, ob einem anfragenden Netzmitglied das Sendeprivileg erteilt wird.
Um an dem System 100 teilzunehmen, können die CDs 120 und 122 jeweils die Fähigkeit haben, das Sendeprivileg von einer Steuervorrichtung oder einer MCU 116 anzufordern. Die MCU 116 kann den Echtzeit- und Administrationsbetrieb der Gruppen managen. Die MCU ist irgendeine Art eines Computergerätes, das mindestens einen Prozessor und einen Speicher hat. Die MCU 116 kann entfernt entweder durch einen Kommunikationssystemdienstprovider, durch Mitglieder oder beide operieren, und zwar unter der Annahme, dass eine Autorisierung durch den Dienstprovider vorgesehen wird. Die MCU 116 kann Gruppendefinitionen durch eine externe Administrationsschnittstelle empfangen. Gruppenmitglieder können administrative Handlungen durch ihren Dienstprovider anfordern oder Netzfunktionen durch definierte Systeme administrieren, wie beispielsweise einen durch ein Mitglied betriebenen Sicherheitsmanager (SM = security manager), der mit einer MCU-Administrationsschnittstelle konform ist. Die MCU 116 kann denjenigen authentifizieren, der versucht, ein Netz einzurichten oder zu modifizieren.
Der SM kann das Schlüsselmanagement, die Benutzerauthentifizierung und verwandte Aufgaben ausführen, um sichere Netze zu unterstützen. Ein einzelnes Gruppenkommunikationssystem kann mit einem oder mit mehreren SMs interagieren. Der SM kann möglicherweise in die Echtzeit-Steuerung eines Netzes nicht verwickelt sein, einschließlich der Netzaktivierung oder der PTT-Vermittlung. Der SM kann Administrationsfähigkeiten haben, die mit der MCU-Schnittstelle kompatibel sind, um Administrationsfunktionen zu automatisieren. Der SM kann auch fähig sein, als ein Datenendpunkt zum Zweck der Teilnahme in einem Netz zu dienen, zum Ausstrahlen von Netzschlüsseln oder einfach den Netzverkehr zu überwachen.
In einem Ausführungsbeispiel weisen die Mittel zum Anfordern des Sendeprivilegs von einer MCU eine Push-to-Talk-(PTT)-Taste oder einen PTT-Schalter auf. Wenn ein Benutzer in dem System 100 Information an andere Mitglieder zu senden wünscht, kann der Benutzer den Push-to-Talk-Schalter drücken, der auf seinem CD angeordnet ist, wobei er eine Sprechrechtsteueranfrage sendet, um das Sendeprivileg von der MCU 116 zu erhalten. Wenn gegenwär tig keinem anderen Netzmitglied das Sendeprivileg zugewiesen ist, kann der anfragende Benutzer das Sendeprivileg erhalten, und der Benutzer kann durch einen hörbaren, einen sichtbaren oder fühlbaren Hinweis durch das CD benachrichtigt werden. Nachdem der anfragende Benutzer das Sendeprivileg erhalten hat, kann die Information dann von diesem Benutzer zu dem anderen Mitglieder übertragen werden.
In einem Ausführungsbeispiel der vorliegenden Erfindung richtet jedes Drahtlosnetzmitglied eine Vorwärtsverbindung und eine Rückwärtsverbindung mit einer oder mehreren Basisstationen 126 ein, oder alternativ mit einem Satelliten-Gateway, wie es der Fall sein mag. Sprache und/oder Daten können in Datenpakete, beispielsweise unter Verwendung eines CD, umgewandelt werden, die für ein spezielles verteiltes Netzwerk 128 geeignet sind, durch welches Kommunikationen zu anderen Benutzern stattfinden kann. In einem Ausführungsbeispiel ist das verteilte Netzwerk 128 das Internet.
In einem Ausführungsbeispiel ist ein dedizierter Vorwärtskanal in jedem Kommunikationssystem eingerichtet, d.h. in einem terrestrischen Kommunikationssystem und einem Satellitenkommunikationssystem, um Information von jedem Netzmitglied zu den anderen Netzmitgliedern auszustrahlen. Jedes Netzmitglied kann Kommunikationen von den anderen Netzmitgliedern über den dedizierten Kanal empfangen. In einem weiteren Ausführungsbeispiel ist eine dedizierte Rückwärtsverbindung in jedem Kommunikationssystem eingerichtet bzw. aufgebaut, um Information an die MCU 116 zu senden. In einem Ausführungsbeispiel kann eine Kombination der obigen Schemata verwendet werden. Beispielsweise kann ein Schema das Einrichten eines dedizierten Vorwärts-Broadcast-Kanals bzw. -Ausstrahlkanals beinhalten, kann jedoch erfordern, dass drahtlose CDs Information an die MCU 116 über eine dedizierte Rückwärtsverbindung senden, die jedem CD zugewiesen ist.
Wenn ein erstes Netzmitglied Information zu anderen Netzmitgliedern senden möchte, kann das erste Netzmitglied das Sendeprivileg anfordern, indem es eine Push-to-Talk-Taste an seinem oder ihrem CD drückt, was eine Anfrage erzeugt, die zur Übertragung über das verteilte Netzwerk 128 formatiert ist. Im Fall der CDs 120 und 122 kann die Anfrage über die Luftschnittstelle zu einer oder mehreren Basisstationen 126 gesendet werden. Eine Mobilvermittlungsstelle (MSC = mobile switching center) 130, welche eine wohl bekannte Interworking-Funktion (IWF = inter-working function) aufweist, einen Paketdatendienstknoten (PDSN = packet data serving node) oder eine Paketsteuerfunktion (PCF = packet control function) zur Verarbeitung von Datenpaketen kann zwischen der BS 126 und dem verteilten Netzwerk 128 existieren. Die Anfrage kann durch das öffentliche Telefonvermittlungsnetzwerk (PSTN = public switched telephone network) zu einer Modembank gesendet werden, die die Anfrage empfangen kann und sie zu dem verteilten Netzwerk 128 liefern kann. Ein Terminal kann den Verkehr des Systems 100 durch seine Verbindung zu dem verteilten Netzwerk 128 überwachen.
Wenn kein anderes Mitglied gegenwärtig das Sendeprivileg inne hat, wenn die MCU 116 die Sendeprivileganfrage empfängt, kann die MCU 116 eine Nachricht an das anfragende Netzmitglied senden, die es benachrichtigt, dass das Sendeprivileg gewährt worden ist. Hörbare, sichtbare oder andere Informationen vom ersten Netzmitglied können dann zu den anderen Netzmitgliedern gesendet werden durch Senden der Information an die MCU 116 unter Verwendung von einem der gerade beschriebenen Übertragungspfade. In einem Ausführungsbeispiel liefert die MCU 116 dann die Information zu den anderen Netzmitgliedern durch Vervielfältigen der Information und Senden jedes Duplikats an die anderen Netzmitglieder. Wenn ein einziger Broadcast-Kanal verwendet wird, muss die Information nur einmal für jeden verwendeten Broadcast-Kanal dupliziert werden.
In einem alternativen Ausführungsbeispiel ist die MCU 116 in der MSC 130 aufgenommen, so dass Datenpakete von unterstützenden Basisstationen direkt zu der MCU 116 geleitet werden, ohne auf das verteilte Netzwerk 128 geleitet zu werden. In diesem Ausführungsbeispiel ist die MCU 116 noch mit dem verteilten Netzwerk 128 verbunden, so dass andere Kommunikationssysteme und -geräte an einer Gruppenkommunikation teilnehmen können. In noch einem weiteren Ausführungsbeispiel kann die MCU 116 in das PDSN oder die PCF-Module der MSC 130 aufgenommen sein.
In einem Ausführungsbeispiel verwaltet die MCU 116 eine oder mehrere Datenbanken zum Managen der Information, die sowohl einzelne Netzmitglieder betrifft als auch jedes definierte Netz. Beispielsweise kann eine Datenbank für jedes Netzmitglied Information aufweisen, wie beispielsweise den Benutzernamen, eine Kontonummer, eine Telefonnummer oder Wählnummer, die mit dem CD des Mitglieds assoziiert ist, einen mobile Identifikationsnummer, die dem CD zugewiesen ist, den gegenwärtigen Status des Mitglieds im Netz, wie beispielsweise ob das Mitglied aktiv am Netz teilnimmt, einen Prioritätscode zur Bestimmung, wie das Sendeprivileg zugewiesen ist, eine Datentelefonnummer, die mit dem CD assoziiert ist, eine IP-Adresse, die mit dem CD assoziiert ist, und eine Anzeige dafür, mit welchen das Mitglied zu kommunizieren autorisiert ist. Andere verwandte Arten von Information können auch von der Datenbank mit Bezug zu jedem Netzmitglied gespeichert werden.
In einem Ausführungsbeispiel kann das CD Verbindungen mit einzelnen Kommunikationsterminals bilden, um eine Sprechgruppe oder ein Netz zu bilden. Die MCU kann eine Vielzahl von funktionellen Fähigkeiten in Hardware und Software aufweisen, die auf unterschiedliche Arten konfigurierbar sind, um unterschiedliche Anwendungen aufzunehmen. Die MCU kann die Fähigkeit vorsehen, Echtzeit-, Administrations- und Authentizitätsoperationen der Netze, eine Push-to-Talk-(PTT)-Anfragevermittlung, eine Verwaltung und Verteilung der Netzmitgliedschafts- und Registrierungslisten, einen Anrufaufbau und -abbruch von notwendiger Kommunikation, z.B. CDMA, System- und Netzwerkressourcen so wie die Gesamtsteuerung des Netzstatus zu managen.
Die Netze können in einem allein stehenden einsetzbaren Zellularsystem oder in einer großen Konfiguration mit mehreren Standorten bzw. einer großen Mehrfachstandortkonfiguration sein. Im Fall einer großen Konfiguration können mehrere MCUs geographisch eingesetzt werden, um ein einzelnes, integ riertes System zu bilden, welches jeweils als ein Plug-In-Modul in einer existierenden zellularen Infrastruktur arbeitet. Als solche sind neue Merkmale, die von den Netzen eingeführt werden, für zellulare Benutzer verfügbar ohne Modifikationen an einer existierenden zellularen Infrastruktur zu erfordern.
Die MCU kann eine Liste von definierten Netzen enthalten. In einem Ausführungsbeispiel weist jede Netzdefinition einen Netzidentifizierer, eine Liste von Mitgliedern, einschließlich Telefonnummern und anderer Identifizierungsinformation, Benutzerprioritätsinformation und andere generische Administrationsinformation auf. Netze können statisch als entweder frei oder sicher definiert werden, und Sendungen zwischen frei und sicher können möglicherweise nicht gestattet sein. Ein sicheres Netz verwendet typischerweise eine Medienverschlüsselung, um eine Authentifizierung und einen Schutz gegen Abhören vorzusehen. Eine Medienverschlüsselung für sichere Netze ist auf einer Ende-zu-Ende-Basis implementiert, was bedeutet, dass eine Verschlüsselung und Entschlüsselung in dem Kommunikationsgerät stattfinden kann. Die MCU kann ohne Kenntnis der Sicherheitsalgorithmen, Schlüssel oder Strategien operieren.
16 veranschaulicht eine beispielhafte Gruppe 1600, um zu zeigen, wie Kommunikationsgeräte 1602, 1604 und 1606 mit einer MCU 1608 interagieren. Mehrere MCUs können eingesetzt werden, wie dies für groß bemessene Gruppen erwünscht ist. In 16 hat das CD 1602 die Erlaubnis, Medien zu anderen Mitgliedern der Gruppe zu senden. In diesem Fall ist das CD 1602 als der Sprecher bekannt und sendet Medien über einen Kanal. Wenn das CD 1602 als der Sprecher bezeichnet wird, können die restlichen Teilnehmer, CD 1604 und CD 1606 möglicherweise keine Erlaubnis haben, Medien an die Gruppe zu senden. Entsprechend werden das CD 1604 und das CD 1606 als Zuhörer bezeichnet.
Wie oben beschrieben, sind die CDs 1602, 1604 und 1606 mit der MCU 1608 unter Verwendung von mindestens einem Kanal verbunden. In einem Ausführungsbeispiel ist der Kanal in getrennte Kanäle aufgeteilt, die einen Sitzungs initiierungsprotokollkanal (SIP-Kanal, SIP = session initiation protocol) 1610, einen Mediensignalisierungskanal 1612 und einen Medienverkehrskanal 1614 aufweisen. Der SIP-Kanal 1610 und der Mediensignalisierungskanal 1612 können zu irgendeinem Zeitpunkt verwendet werden, wenn die Bandbreite dies gestattet, und zwar durch irgendeines der CDs 1602, 1604 und 1606, und zwar ungeachtet dessen, dass sie als ein Sprecher oder ein Zuhörer bezeichnet werden. Das SIP ist ein von der Internet Engineering Task Force (IETF) definiertes Anwendungsschichtprotokoll, welches Steuermechanismen beschreibt, um Multimediasitzungen einzurichten, zu modifizieren und zu beenden, die über das Internetprotokoll (IP) arbeiten. Das SIP bietet eine allgemeine Lösung für Anrufsignalisierungsprobleme für Internettelefonieanwendungen durch Unterstützung von Mechanismen zum Registrieren und Lokalisieren von Benutzern, durch Mechanismen, die die Benutzerfähigkeiten definieren und die Medienparameter beschreiben, und Mechanismen, um die Verfügbarkeit eines Benutzers, den Anrufaufbau und die Anrufhandhabung zu bestimmen.
In einem Ausführungsbeispiel wird der SIP-Kanal 1610 verwendet, um eine Teilnahme eines CD in der Gruppe 1600 zu starten und zu beenden. Ein Sitzungsbeschreibungsprotokollsignal (SDP-Signal, SDP = session description protocol) kann auch in dem SIP-Kanal 1610 verwendet werden. Wenn die Teilnahme des CD in der Gruppe aufgebaut wird, beispielsweise durch Verwendung eines SIP-Kanals 1610, findet eine Echtzeit-Anrufsteuerung und -Signalisierung zwischen dem CD und der MCU statt, beispielsweise durch Verwendung eines NBS-Mediensignalisierungskanals 1612. In einem Ausführungsbeispiel wird der Mediensignalisierungskanal 1612 verwendet, um Push-to-Talk-Anfragen und -Freigaben zu handhaben, um zwischen in Konflikt stehenden Anfragen zu vermitteln oder zur Sprechrechtsteuerung, um den Beginn und das Ende einer Informationsübertragung anzukündigen, um die Netzruhezeit bzw. den Netzruhestatus zu managen, um eine Endpunktkonnektivität zu verfolgen, um den Netzstatus anzufragen und auszutauschen und um irgendwelche Fehlernachrichten bekanntzugeben. Das Protokoll des Mediensignalisierungskanals 1612 minimiert die Länge der meisten üblichen Nach richten und vereinfacht die Aufgabe der Interpretation von Antworten und des Antwortens auf Anfragen, während eine Flexibilität für zukünftige Verbesserungen aufrecht erhalten wird. Das Protokoll des Mediensignalisierungskanals 1612 gestattet auch, dass Anfragen zurückgesetzt werden, ohne nachteilig den Protokollzustand zu beeinflussen.
In einem Ausführungsbeispiel weist der Signalisierungsverkehr auf dem Mediensignalisierungskanal 1612 einen Anrufaufbau und eine Steuersignalisierung auf, die aus Sitzungseinladungsanfragen und -bestätigungen bestehen kann, und eine Mediensignalisierung, die Echtzeit-Sprechrechtsteueranfragen und verwandte asynchrone Nachrichte aufweisen kann. Der Medienverkehr auf dem Medienverkehrskanal 1614 kann Echtzeit-Punkt-zu-Multipunkt-Sprach- und/oder -Datenausstrahlungen aufweisen. Beide Messaging-Kategorien haben einzigartige funktionale Attribute. Zusätzlich kann jedes CD DNS-Clientanfragen (DNS = domain name service) ausgeben, um das Abbilden von vollständig qualifizierten DNS-Hostnamen auf Internetnetzwerkadressen zu ermöglichen.
In einem Ausführungsbeispiel wird eine Anrufaufbau- und Anrufsteuersignalisierung gemäß SIP-Semantiken ausgeführt. Obwohl SIP unter Verwendung von entweder dem wohlbekannten Benutzerdatagrammprotokoll (UDP = user datagram protocol) oder dem TCP-Protokoll (TCP = transmission control protocol) transportiert werden kann, führt in einem Ausführungsbeispiel jedes CD SIP-basierte Signalisierungsfunktionen unter Verwendung von UDP aus. Auch kann jedes CM erwarten, SIP-Signalisierungsanfragen über UDP zu empfangen. Eine Echtzeit-Signalisierung kann über eine dynamische UDP/IP-Schnittstelle an dem CM und bei jedem CD auftreten. Eine andere Signalisierung kann über eine festgelegte TCP/IP-Schnittstelle zwischen dem CM und dem CD beispielsweise unter der Verwendung von SIP stattfinden.
PTT-Latenzzeit
In einem Ausführungsbeispiel, wenn der Paketdatendienst aktiv ist, sind Ressourcen in der Infrastruktur, beispielsweise das Basisstationstransceiversubsystem (BTS = base station transceiver subsystem), die Basisstationssteuervorrichtung (BSC = base station controller), die Interworking-Funktion (IWF) und die Funkverbindung aktiv der Mobilstation (MS) zugewiesen. In einem IP-basierten VoIP-Dispatch-Dienst bleibt, während eine aktive Konversation zwischen den Gruppenteilnehmern stattfindet, die Paketdatenverbindung für jeden Benutzer aktiv. Nach einer Periode der Inaktivität jedoch, d.h. der "Wartezeit", können in den Gruppenkommunikationen die Benutzerverkehrskanälen in den Ruhezustand übergehen.
Der Übergang zum Ruhezustand spart Systemkapazität, verringert die Dienstkosten und das Leeren der Batterie, und macht den Benutzer verfügbar, um ankommende herkömmliche Sprachanrufe zu empfangen. Wenn beispielsweise der Benutzer in einem aktiven Paketdatenanruf ist, wird er im Allgemeinen als "besetzt" für ankommende Sprachanrufe angesehen. Wenn der Paketdatenanruf des Benutzers in dem Ruhezustand ist, könnte der Benutzer in der Lage sein, ankommende Sprachanrufe empfangen. Aus diesen Gründen ist es wünschenswert, den Paketdatenanruf in den Ruhezustand zu überführen nach Perioden von Paketdateninaktivität.
Während Paketdatenanrufe aktiv sind, auch wenn keine Paketdaten ausgetauscht werden, kann Hochfrequenzenergie (HF-Energie) von den mobilen Telefonen immer noch gesendet werden, wenn auch auf einem niedrigen Pegel, um eine Synchronisation und Leistungssteuerung mit der Basisstation aufrecht zu erhalten. Diese Sendungen können einen beträchtlichen Leistungsverbrauch in dem Telefon verursachen. Im ruhenden Zustand jedoch kann das Telefon keine Hochfrequenzübertragung ausführen. Um Telefonleistung zu sparen und die Batterielebensdauer zu verlängern, kann die Wartezeit eingestellt werden, um das Telefon in den Ruhemodus übergehen zu lassen nach verlängerten Perioden ohne Datenübertragung.
Während der Paketdatendienst für alle Benutzer aktiv ist, haben PTT-Anfragen, die IP-Datagramme sein können, die zwischen der MS und dem Dispatch-Server gesendet werden, eine sehr geringe Latenzzeit. Wenn jedoch die Benutzerkanäle zuvor in den Ruhezustand übergegangen sind, kann die PTT-Latenzzeit viel länger sein. Während des Paketdatenruhestatus kann Zustandsinformation, die mit der Paketdatensitzung assoziiert ist, einschließlich der mobilen IP-Adresse, aufrechterhalten werden. Jedoch kann eine Zustandsinformation, die mit Schichten unter PPP assoziiert ist, wie beispielsweise den physikalischen Verkehrsschichten, freigegeben und/oder deren Zuteilung aufgehoben werden.
In einigen Infrastrukturen muss, um eine ruhende Datenverbindung aufzuwecken, der Verkehrskanal erneut bzw. wieder zugeteilt werden, die Ressourcen müssen erneut bzw. wiederzugewiesen werden und die Funkverbindungsprotokollschicht (RLP-Schicht, RLP = radio link protocol) muss reinitiiert werden. Die Folge davon ist, dass nachdem einen Sprechgruppe für eine Weile nicht gesprochen hat, wenn ein Benutzer seine PTT-Taste drückt, um das Sprechrecht anzufordern, die PTT-Latenzzeit für den ersten Sprachabschnitt im Allgemeinen viel länger ist als für darauf folgende Sprachabschnitte. Während dies relativ selten ist, kann dies den Nutzen des Dienstes beeinflussen und sollte minimiert werden.
Um die PTT-Latenzzeit zu verringern, können in einem Ausführungsbeispiel die Gruppenanrufsignalisierung, wie beispielsweise die Sprechrechtsteueranfragen, Sprechrechtsteuerantworten und Ruhezustandsaufwecknachrichten auf einigen verfügbaren Gemeinsamkanälen übertragen werden, ohne darauf zu warten, dass dedizierte Verkehrskanäle wieder eingerichtet werden. Solche Gemeinsamkanäle können immer verfügbar sein, und zwar ungeachtet des Zustands der Mobiltelefone und es muss nicht notwendig sein, dass sie jedes Mal angefragt und erneut zugeordnet werden, wenn ein Benutzer einen Gruppenanruf initiieren will. Daher kann die Gruppenanrufsignalisierung ausgetauscht werden, auch dann, wenn die Mobiltelefone ruhen, was ein Mittel vor sehen kann, um dedizierte Verkehrskanäle für die Sprecher- und Zuhörermobiltelefone parallel wiedereinzurichten.
In einem Ausführungsbeispiel kann das anrufende Mobiltelefon bzw. -teil eine Sprechrechtsteueranfrage an die drahtlose Infrastruktur über einige verfügbare Rückwärts-Gemeinsamkanäle anfragen, wie beispielsweise einen Rückwärtszugriffskanal und einen erweiterten Rückwärtszugriffskanal. Das anrufende Mobilteil kann auch eine Antwort auf die Sprechrechtsteueranfrage auf einigen verfügbaren Vorwärts-Gemeinsamkanälen empfangen, wie beispielsweise dem Vorwärts-Pagingkanal und dem Vorwärts-Gemeinsamsteuerkanal. In einem Ausführungsbeispiel können die ruhenden Zuhörermobilteile Ruhestatuswecknachrichten auf einigen verfügbaren Vorwärts-Gemeinsamkanälen empfangen, wie beispielsweise auf dem Vorwärts-Pagingkanal und dem Vorwärts-Gemeinsamsteuerkanal.
Kurzdatenburst-Anrufsignalisierungsnachrichten
In einem Ausführungsbeispiel kann eine signifikante Reduktion der tatsächlichen Gesamtruhestatusaufweckzeit und der PTT-Latenzzeit, die vom Sprecher wahrgenommen wird, erreicht werden durch Anwendung der Kurzdatenburstnachrichten (SDB-Nachrichten, SDB = short data burst), wie in den "TIA/EIA/IS-2000 Standards for cdma2000 Spread Spectrum Systems" vorgesehen, die im Folgenden beispielsweise als "der cdma2000-Standard" bezeichnet werden. In einem Ausführungsbeispiel können SDB-Nachrichten über beide dedizierte physische Kanäle gesendet werden, wie beispielsweise den Vorwärtsfundamentalkanal (FCH = forward fundamental channel) oder den dedizierten Vorwärts-Gemeinsamsteuerkanal (F-DCCH = forward dedicated common control channel), oder physische Gemeinsamkanäle, wie beispielsweise den Rückwärtszugriffskanal (R-ACH = reverse access channel), den erweiterten Rückwärtszugriffskanal (R-EACH = reverse enhanced access channel), den Vorwärts-Gemeinsamsteuerkanal (F-CCCH = forward common control channel) oder den Paging- bzw. Nachrichtenkanal (PCH = paging channel). SDB-Nachrichten können durch das Funkburstprotokoll (RBP = ra dio hurst protocol) transportiert werden, welches die Nachrichten auf einen geeigneten und verfügbaren physischen Schichtkanal abbildet. Weil SDB-Nachrichten beliebigen IP-Verkehr führen können und über physische Gemeinsamkanäle gesendet werden können, bieten SDB-Nachrichten einen Mechanismus, um eine Gruppenanrufsignalisierung auszutauschen, wenn ein Mobilteil eines anrufenden Clients keine dedizierten Verkehrskanäle hat.
Vom Mobilteil ausgehende Anrufsignalisierungsnachrichten
In einem Ausführungsbeispiel können Mediensignalisierungsnachrichten IP-Datagramme über die Rückwärtsverbindung oder die vom Mobilteil ausgehende Verbindung führen. Eine Client-Mobilstation kann der MCU schnell signalisieren, wann der Benutzer das Sprechrecht anfragt und ein dedizierter Rückwärtsverkehrskanal nicht sofort verfügbar ist. Unter der Annahme, dass die Client-Mobilstation alle dedizierten Verkehrskanäle freigegeben hat, kann die Client-Mobilstation sofort die Sprechrechtsteueranfrage über einen Rückwärts-Gemeinsamkanal über eine drahtlose Infrastruktur weiterleiten, was die Anfrage an die MCU verzögern kann. Beispielsweise kann entweder der Rückwärtszugriffskanal oder der erweiterte Rückwärtszugriffskanal verwendet werden, um solche Nachrichten zu senden, wenn ein dedizierter Rückwärtskanal nicht verfügbar ist. In einem Ausführungsbeispiel kann die Client-Mobilstation eine Sprechrechtanfragenachricht an die MCU als eine SDB-Nachricht senden.
Mit Bezug auf 4 kann die Client-MS in einem Ausführungsbeispiel die PTT-Sprechrechtanfrage 404 über einen Rückwärts-Gemeinsamkanal senden, wie beispielsweise den Zugriffskanal oder den erweiterten Zugriffskanal, bevor versucht wird, den dedizierten Verkehrskanal wieder einzurichten. In einem Ausführungsbeispiel kann die Client-MS die PTT-Sprechrechtanfrage 404 in einer SDB-Nachricht senden, und zwar unabhängig davon, welcher Kanal verwendet wird.
Die Client-MS kann dann beginnen, ihren dedizierten Verkehrskanal wiedereinzurichten, beispielsweise durch Ausführen der "Service Option 33 Re-Origination". Die Client-MS kann auch die Funkverbindungsprotokollsynchronisation (RLP-Synchronisation) starten. In einem Ausführungsbeispiel kann die Client-MS ihren dedizierten Verkehrskanal wieder einrichten und das RLP vorteilhafterweise parallel mit dem Senden der PTT-Sprechrechtanfrage 404 synchronisieren.
Daher verringert die Verwendung der verfügbaren Rückwärts-Gemeinsamkanäle und/oder des SDB-Merkmals, um Sprechrechtsteueranfragen an das CM zu signalisieren, wenn eine Mobilstation keine aktiven dedizierten Verkehrskanäle hat, die Gesamtzeit, die erforderlich ist, um die teilnehmenden Mobilteile aufzuwecken. Obwohl der sprechende Client möglicherweise keine Bestätigung empfängt, dass seine Sprechrechtanfrage gestattet worden ist bis der Vorwärtsverkehrskanal des Sprechers wieder eingerichtet ist, verringert die Fähigkeit, dem CM schnell zu signalisieren damit zu beginnen, die teilnehmenden Zuhörer aufzuwecken, die Gesamtlatenzzeit.
Mit Bezug auf 4 kann die drahtlose Infrastruktur die PTT-Sprechrechtsteueranfrage 404 an den Paketdatendienstknoten (PDSN) und dann zu der MCU senden. In einem Ausführungsbeispiel kann die MCU nach dem Empfang der Sprechrechtsteueranfrage die Anfrage vermitteln, die Mediensignalisierungsaufwecknachrichten (Auslöser) zu einer Gruppe von Zielteilnehmern (Zuhörern) auf eine Burst-Art aussenden, und/oder das erneute Einrichten der Verkehrskanäle 414 der Teilnehmer (Zuhörer) auslösen. Wenn die MCU die PTT-Sprechrechtanfrage gewährt, kann die MCU die PTT-Sprechrechterteilung 408 an die Client-MS senden. In einem Ausführungsbeispiel kann der RD die PTT-Sprechrechterteilung 408 an die Client-MS auf einem verfügbaren Vorwärts-Gemeinsamkanal senden, wie beispielsweise auf dem Vorwärts-Pagingkanal und auf dem Vorwärts-Gemeinsamsteuerkanal, wenn der dedizierte Verkehrskanal noch nicht wieder eingerichtet ist. In einem Ausführungsbeispiel kann die Infrastruktur die PTT-Sprechrechterteilung 408 an die Client-MS in SDB-Form ungeachtet dessen senden, welcher Kanal verwendet wird.
In einem Ausführungsbeispiel kann die MCU darauf warten, dass der Ruhestatusantworttimer abläuft, bevor sie auf die PTT-Sprechrechtsteueranfrage antwortet. Wenn der Ruhestatusantworttimer der Gruppe auf Null gesetzt ist, kann das CM sofort auf die Sprechrechtsteueranfrage antworten. In einem Ausführungsbeispiel kann, falls die Client-MS die Wiedereinrichtung ihres Verkehrskanals und die RLP-Synchronisation abgeschlossen hat, die Client-MS die Medien 416, die in der Client-MS gepuffert worden sind 412, zur MCU streamen.
Vom Netzwerk ausgehende Anrufsignalisierungsnachrichten
In einem Ausführungsbeispiel kann die MCU nach dem Empfang der Sprechrechtsteueranfrage Mediensignalisierungsaufwecknachrichten an eine Gruppe von Zielteilnehmern (Zuhörern) in Burst-Form senden und kann das Wieder- bzw. erneute Einrichten der Verkehrskanäle der Teilnehmer (Zuhörer) auslösen. Wenn der Ruhestatusantworttimer der Gruppe auf Null gesetzt wird, kann die MCU sofort auf die Sprechrechtsteueranfrage antworten. Wenn in einem Ausführungsbeispiel der Sprecher begonnen hat, seinen Verkehrskanal wiedereinzurichten, und zwar sofort auf das Senden der PTT-Anfrage hin, können die Verkehrskanäle der Anrufer und Zuhörer in vorteilhafter Weise parallel wiedereingerichtet werden.
Mit Bezug auf 4 kann die MCU, nachdem die MCU die PTT-Sprechrechtsteueranfrage empfängt, Aufweckauslöser 414 senden, die an die Zielzuhörer gerichtet sind. Die MCU kann bestimmen, ob eine Paketdatensitzung für das Zielmobilteil existiert und leitet das Auslöserpaket an das geeignete Infrastrukturelement weiter, beispielsweise eine Basisstation. Die Infrastruktur kann jede einzelne Ziel-MS pagen bzw. rufen damit zu beginnen, seinen dedizierten Verkehrskanal wiedereinzurichten. Die Ziel-MS kann dann beginnen, seinen dedizierten Verkehrskanal wiedereinzurichten, beispielswei se durch Ausführen der "Service Option 33 Re-Origination". Die Ziel-MS kann auch die Funkverbindungsprotokollsynchronisierung (RLS-Synchronisierung) starten. In einem Ausführungsbeispiel können die Ziel-MSe ihre dedizierten Verkehrskanäle wiedereinrichten und ihre RLPs auf vorteilhafte Weise parallel synchronisieren mit gleichen Funktionen, die von der Client-MS ausgeführt werden.
In einem Ausführungsbeispiel kann, nachdem die Ziel-MS die Wiedereinrichtung ihres dedizierten Verkehrskanals vollendet hat und ihr RLP synchronisiert hat, die Ziel-MS die Aufweckantwort 422 an die MCU senden, was anzeigt, dass die Ziel-MS bereit ist, Medien zu empfangen. Die MCU kann eine Sprecherankündigung an die Client-MS senden, bevor sie Medien 420 streamt, die in der MCU gepuffert worden sein können 418, und zwar zu der Ziel-MS.
In einem Ausführungsbeispiel kann die MCU den Aufweckauslöser 414 an einen Zielzuhörer über einige verfügbare Vorwärts-Gemeinsamkanäle senden, wie beispielsweise den Vorwärts-Pagingkanal und den Vorwärts-Gemeinsamsteuerkanal, während die Verkehrskanäle der Zielzuhörer noch nicht wiederaufgebaut sind. In einem Ausführungsbeispiel kann die MCU den Aufweckauslöser 414 an den Zielzuhörer in SDB-Form senden, unabhängig davon, welcher Kanal verwendet wird. Wenn die PTT-Sprechrechtsteueranfrage an den Rückwärts-Gemeinsamkanal des Sprechers als eine SDB-Nachricht gesendet wird und der Ruhezeitantworttimer der Zielgruppe bei der MCU auf Null gesetzt ist, kann die tatsächliche PTT-Latenzzeit beim Sprecher-Client auf die Zeit reduziert werden, die erforderlich ist, um eine SDB-Anfragenachricht auf der Rückwärts-Verbindung gefolgt durch eine SDB-Antwortnachricht auf der Vorwärtsverbindung zu senden.
Netzwerkschnittstellen für Anrufsignalisierungsnachrichten
Um zu bestimmen, welcher vom dem Netzwerk ausgehende spezifische Verkehr, beispielsweise SDB-Nutzlast, für eine Mobilstation im Leerlauf ohne de dizierte Verkehrskanäle gesendet wird, kann eine gewisse Infrastrukturstrategie oder -schnittstelle zur Unterscheidung von solchem speziellen Verkehr von anderem Verkehr implementiert werden.
In einem ersten Ausführungsbeispiel können IP-Datagramme basierend auf ihren Größen gefiltert werden, da die SDB-Nachrichten eine begrenzte Benutzernutzlast tragen. IP-Datagramme, die kleiner als eine vorbestimmte Größenbegrenzung sind, können als SDB-Nachrichten gesendet werden, falls sie für ein Mobilteil ohne dedizierte Verkehrskanäle bestimmt sind. Das Gruppenkommunikationssystem kann solche Filter verwenden, da die Anwendungssprechrechtanfrageantwortnachricht sehr klein ist, z.B. 34 Byte einschließlich der IP-Header.
In einem zweiten Ausführungsbeispiel kann ein Infrastrukturanbieter einen IP-basierten Dienst definieren, um einen IP-Verkehr einzukapseln, der zur Lieferung an eine Mobilstation bestimmt ist. Ein IP-Server mit Kenntnis dieses Dienstes kann eine kleine IP senden, beispielsweise UDP, Datagramme, in geeigneter Weise mit IP-Headern eingekapselt, zu diesem Dienst zur Lieferung zu einem Mobilteil, von dem vermutet wird, dass es keinen dedizierten Verkehrskanal hat. Die Gruppenkommunikationssysteme können diesen Dienst verwenden, um der Infrastruktur anzuzeigen, dass die Sprechrechtanfrageantwortnachricht zu der anfragenden Client-MS beispielsweise in SDB-Form geliefert werden kann. Die Koordination des SDB-Verkehrs mit bevorstehenden Pagen bzw. Funkrufen oder Dienstveranlassungsanfragen (service origination request) ist auch wichtig, um eine schnelle und zuverlässige Lieferung des Benutzerverkehrs sicherzustellen.
In einem dritten Ausführungsbeispiel kann ein IP-Server eine spezielle IP übertragen, beispielsweise UDP, Datagramme mit IP-Headern zur Lieferung zu einem Mobilteil, von dem vermutet wird, dass es keinen dedizierten Verkehrskanal hat. Der IP-Server kann die IP-Datagramme mit einem Tag versehen, z.B. durch Zuordnen eines speziellen Wertes in dem IP-Header, um eine Infrastruktur anzuweisen, die IP-Datagramme zu der Client-MS zu liefern. Die Gruppenkommunikationssysteme können diesen Dienst verwenden, um der Infrastruktur zu zeigen, dass die Sprechrechtanfrageantwortnachricht zu der anfragenden Client-MS beispielsweise in SDB-Form zu liefern sei. In einem dritten Ausführungsbeispiel kann ein UDP- oder TCP-Port-Bereich für das Liefern von speziellen IP-Datagrammen, z.B. SDB-Nachrichten reserviert sein.
Vom Mobilteil initiierte Dienstveranlassung und Paging
In einem Ausführungsbeispiel kann ein Client die Sprechrechtsteueranfrage 404 senden, die in SDB-Form sein kann, und sofort gefolgt mit einer Dienstveranlassungsanfrage an die drahtlose Infrastruktur, z.B. CDMA-Infrastruktur, schnell ihre Verkehrskanäle wiedereinzurichten. Wenn jedoch der Ruhestatusantworttimer auf einen kleinen Wert gesetzt ist, kann der RD auf die Sprechrechtsteueranfrage schnell antworten und eine Antwort 408 zurück zum Client senden. Wenn diese Antwort an der Infrastruktur während den frühen Phasen der Dienstveranlassungstransaktion ankommt, bemerkt die Infrastruktur, dass die Sprecher-MS keinen aktiven Verkehrskanal hat und kann versuchen, die Antwort an die Sprecher-MS zu pagen. Dieser Paging-Vorgang kann jedoch die Dienstveranlassungstransaktion abbrechen, die schon im Gang ist. In einem Ausführungsbeispiel kann die Sprecher-MS auf den Page antworten, was sicherstellt, dass die Sprechrechtsteuerantwortnachricht zu dem Sprecher geliefert wird, und eine Dienstveranlassung noch einmal anfragen, jedoch wird eine unnötige Verzögerung beim Wiedereinrichten des Verkehrskanals des Sprechers erfahren als Folge des abgebrochenen ursprünglichen Dienstveranlassungsversuchs.
In einem ersten Ausführungsbeispiel, um den Wettbewerbszustand zwischen dem Dienstveranlassungsprozess und dem Paging zu vermeiden, kann der RD konfiguriert sein, nicht sofort auf die Sprechrechtsteueranfrage 404 anzusprechen. Entsprechend kann der Ruhestatusantworttimer so angepasst werden, dass die MCU die Antwort 408 an die Sprecher-MS überträgt, nachdem der Dienstveranlassungsprozess vollendet ist.
In einem zweiten Ausführungsbeispiel werden der PDSN, der die Antwort 408 empfängt, und die Mobilvermittlungsstelle (MSC), die auf die Dienstveranlassungsanfrage des Sprechers antwortet, koordiniert. D.h., wenn der PDSN bestimmt, dass ein Paketdatendienstveranlassungsprozess für die Sprecher-MS schon im Gang ist, wenn die Antwort 408 bei der Infrastruktur ankommt, kann die MSC das Paging der Sprecher-MS verzögern. Der PDSN kann die Antwort cachen und sie über den Vorwärts-Verkehrskanal des Sprechermobilteils senden, sobald der Dienstveranlassungsprozess vollendet ist. Alternativ kann die MSC die Antwort an die Sprecher-MS als eine SDB-Nachricht senden, wenn der Dienstveranlassungsprozess immer noch im Gang ist.
In einem dritten Ausführungsbeispiel kann die Sprecher-MS den Wettbewerbszustand vermeiden, indem sie nicht eine Dienstveranlassungsanfrage ausgibt, bis zu dem Zeitpunkt, nachdem die Sprecher-MS eine Antwort auf die Sprechrechtanfrage empfangen hat. Da die Sprecher-MS keinen aktiven dedizierten Verkehrskanal hat, kann in einem Ausführungsbeispiel die MCU die Antwort an die Sprecher-MS auf einigen verfügbaren Vorwärts-Gemeinsamkanälen senden, wie beispielsweise auf dem Vorwärts-Pagingkanal und dem Vorwärts-Gemeinsamsteuerkanal. In einem Ausführungsbeispiel kann die MCU die Antwort an die Sprecher-MS in SDB-Form senden. Die Sprecher-MS kann sich auf die vom RD erzeugte Sprechrechtsteuerantwort verlassen, um ihre Verkehrskanalreaktivierung auszulösen, und zwar in der gleichen Weise, wie die Aufweckanfragen, die von der MCU gesendet werden, die Verkehrskanalreaktivierung für die Zuhörermobilteile auslösen. Der Wettbewerbszustand wird vermieden, da das die Möglichkeit einer gleichzeitigen vom Mobilteil initiierten Dienstveranlassung und eines vom Netzwerk initiierten Pagings des Mobilteils vermieden wird.
Cachen von netzwerkinitiierten Paketdatenauslösern
Das IP-Datagramm, welches den Aufweckauslöser 414 aufweist, der bei der drahtlosen Infrastruktur, z.B. der CDMA-Infrastruktur ankommt und für ein Zuhörermobilteil bestimmt ist, welches keine dedizierten Verkehrskanäle hat, kann verloren gehen, und zwar entweder durch das Netzwerk im Allgemeinen oder durch die drahtlose Infrastruktur im Speziellen. In einem Ausführungsbeispiel wird der Aufweckauslöser 414, der zum Zuhörermobilteil gesendet wird, aggressiv erneut übertragen gemäß einem definierten Zeitplan, bis die Zuhörer antworten oder der Aufwecktimer der Gruppe abläuft. Beispielsweise kann der Aufweckauslöser 414 alle 500 ms erneut gesendet werden. Jedoch kann das erneute Senden der Aufweckauslöser 414 mit dieser Rate eine maximale Verzögerung von bis zu 500 ms oder ein durchschnittliche Verzögerung von 250 ms verursachen, und zwar von dem Zeitpunkt, wenn ein Verkehrskanal eines Zuhörers wiedereingerichtet ist bis zu dem Zeitpunkt, wenn der nächste Aufweckauslöser für diesen Zuhörer bei der Infrastruktur ankommt.
In einem Ausführungsbeispiel kann die Infrastruktur oder eine andere Einheit in dem Netzwerk den Aufweckauslöser 414, der von der MCU gesendet wird, cachen, und kann ihn zu der Ziel-MS liefern, sobald die Ziel-MS ihren Verkehrskanal wiedereingerichtet hat. Dies eliminiert die Notwendigkeit zur erneuten Übertragung der Aufweckanfrage durch die MCU und verringert die gesamte Ruhestatusaufweckzeit. Das Cachen des Aufweckauslösers 414 im Gegensatz zu seiner erneuten Sendung mit einer Rate von 500 ms kann beispielsweise eine Verzögerung von bis zu 500 ms aus der gesamten Ruhestatusaufweckzeit eliminieren.
Medienpufferung
In einem Ausführungsbeispiel kann dem Benutzer gestattet sein, zu beginnen zu sprechen, nachdem der Benutzer eine Sprechrechtsteuerung angefragt hat, und zwar durch Pufferung der Medien, bevor dedizierte Kanäle zwischen dem Client und den Zuhörern wiedereingerichtet sind. Durch Pufferung der Sprache des Sprechers gestattet das System dem Sprecher zu beginnen zu sprechen, bevor die Verkehrskanäle der Zuhörer voll wiedereingerichtet worden sind. Dies gestattet, dass der Sprecher früher zu sprechen beginnt, was seine wahrnehmbare PTT-Latenzzeit reduziert. Da die Zuhörer keine PTT- Latenzzeit erfahren, ist ihre Wahrnehmung unbeeinflusst, d.h. die PTT-Latenzzeit wird vom Sprecher zu anderen Teilen des Systems verschoben. Der Sprecher kann gerade so lange warten, dass er eine Antwort von einem Zuhörer auf seinen ersten Sprachabschnitt empfängt, aber wie zuvor erwähnt wartet er schon, dass die Antwort auf seinen ersten Sprachabschnitt länger dauert als die Antwort auf die folgenden Sprachabschnitte die auftreten, während er in eine aktiven Unterhaltung involviert ist. Die Pufferung des ersten Sprachabschnitts des Sprechers kann auf der MCU-Seite oder auf der Client-MS-Seite stattfinden.
Pufferung auf der MCU-Seite
In einem Ausführungsbeispiel kann die MCU den ersten Sprachabschnitt des Sprechers puffern. Nachdem ein Benutzer seine PTT-Taste gedrückt hat und die Verkehrskanäle des Benutzers wiedereingerichtet sind, kann ihm gestattet werden, mit der MCU zu kommunizieren. Da die Zuhörerverkehrskanäle noch nicht bestehen, puffert 418 die MCU zu diesem Zeitpunkt die Sprache des Sprechers zur zukünftigen Übertragung an die Zielzuhörer. Die MCU-Pufferung kann die wahrnehmbare PTT-Latenzzeit, die der Sprecher sieht, auf die ungefähre Zeit verringern, die benötigt wird, um den Verkehrskanal des Sprechers hochzubringen. 17 zeigt die Pufferung auf der MCU-Seite gemäß einem Ausführungsbeispiel, wie unten beschrieben:

(1) Kein Anruf in Gang, die Verkehrskanäle vom Ausgangspunkt bzw. dem einleitendem Teilnehmer und dem Ziel ruhen.
(2) Der Benutzer drückt die PTT-Taste. Der Server empfängt eine "Gruppenanruf-Aufbauen"-Anfrage von dem Client.
(3) Sprechrecht wird dem Benutzer erteilt, nachdem der Client die "Aufbauim-Gang"-Antwort von dem Server empfängt oder nach einer konfigurierbaren Verzögerung (1 Sekunde) und beginnt die Benutzermedien zu puffern.
(4) Der Server beginnt den Prozess der Wiedereinrichtung von Paketdatenverkehrskanälen der Ziele.
(5) Der Server sendet eine "Gruppenanrufankündigungs"-Nachricht über SDB zu dem Client.
(6) Der Client richtet erfolgreich den Verkehrskanal wieder ein, und beginnt mit dem Senden gepufferter Medien zu dem Server.
(7) Der Client streamt Medien an den Server.
(8) Die Verkehrskanäle der Ziele sind wiedereingerichtet worden ("Zielantwortschwelle" wird erfüllt).
(9) Der Benutzer lässt die PTT-Taste los. Der Client hört auf Medien zu puffern.
(10) Der Client beendet das Streaming von gepufferten Medien zu dem Server, fordert Freigabe des Sprechrechts vom Server.
(11) Der Server sendet die Sprechrechtfreigabebestätigung zu dem Client.

Pufferung auf der Client-Seite
In einem Ausführungsbeispiel, in dem eine kürzere wahrnehmbare Latenzzeit erwünscht ist, kann dem Sprecher gestattet sein, mit dem Sprechen zu beginnen, sogar bevor sein Verkehrskanal wiedereingerichtet ist. Weil die Client-MS noch nicht in Kommunikation mit der MCU ist, wird das Signal an den Sprecher, mit dem Sprechen zu beginnen, von der Client-MS ausgeführt. Wenn dem Sprecher gestattet wird, zu sprechen, bevor der Verkehrskanal des Sprechers wiedereingerichtet ist, kann die Client-MS die Sprache puffern 412. Weil die Kommunikation mit dem CM noch nicht eingerichtet worden ist, wird die Erlaubnis zu Sprechen "optimistisch" gegeben. 18 zeigt die Pufferung auf der Client-Seite gemäß einem Ausführungsbeispiel, wie unten beschrieben:

(1) Kein Anruf ist im Gang, der Verkehrskanal des einleitenden Teilnehmers ruht.
(2) Der Benutzer drückt die PTT-Taste. Der Client sendet eine "Gruppenanruf-Aufbauen"-Anfrage über SDB an den Server.
(3) Der Client beginnt den Prozess der Wiedereinrichtung eines Paketdatenverkehrskanals.
(4) Sprechrecht wird dem Benutzer erteilt, nachdem der Client die "Aufbauim-Gang"-Antwort von dem Server empfängt oder nach einer konfigurierbaren Verzögerung (1 Sekunde) und beginnt, die Benutzermedien zu puffern.
(5) Der Client empfängt eine "Gruppenanrufankündigungs"-Nachricht von dem Server über SDB.
(6) Der Client richtet erfolgreich den Verkehrskanal wieder ein.
(7) Der Client streamt gepufferte Medien vom Server.
(8) Der Benutzer gibt die PTT-Taste frei. Der Client stoppt die Pufferung der Medien.
(9) Der Client beendet das Streaming der gepufferten Medien zum Server, fragt die Freigabe des Sprechrechts durch den Server an.
(10) Der Client empfängt eine Bestätigung über die Sprechrechtfreigabe vom Server.

In einem Ausführungsbeispiel können sowohl die MCU-Pufferung 418 als auch die Pufferung auf Client-Seite 412 gleichzeitig operieren. Die Pufferung auf Client-Seite kann gestatten, dass die wahrnehmbare PTT-Latenzzeit klein ist. In einem Ausführungsbeispiel kann die Client-MS Medien puffern, um die wahrnehmbare PTT-Latenzzeit zu steuern, die von dem Benutzer erfahren wird. Die Kombination der vom Mobilteil ausgehenden SDB und der Medienpufferung auf Client-Seite kann die Verzögerungen reduzieren, die mit der Wiedereinrichtung der aktiven Verkehrskanäle assoziiert sind.
Daher sehen die offenbarten Ausführungsbeispiele ein Dispatch-Modell vor, welches mindestens zwei Arten von Dispatch-Anrufen unterstützt: das Chat-Room-Modell und das Ad-Hoc-Modell. Beim Chat-Room-Modell sind die Gruppen vordefiniert, die auf dem Dispatch-Server gespeichert sein können. Bei dem Ad-Hoc-Modell können jedoch die Gruppen in Echtzeit definiert und/oder modifiziert werden.
Die offenbarten Ausführungsbeispiele sehen auch eine signifikante Verringerung der tatsächlichen gesamten Ruhestatusaufweckzeit und der PTT- Latenzzeit vor, und zwar durch Austauschen der Gruppenanrufsignalisierung, auch dann, wenn Mobilteile ruhen und kein Verkehrskanal aktiv ist. Das Verfahren und die Vorrichtung sehen einen Austausch der Gruppenanrufsignalisierung durch die Verwendung der Kurzdatenburstnachrichtensignalisierung (SDB-Nachrichtensignalisierung) vor. Das Verfahren und die Vorrichtung sehen die Wiedereinrichtung der dedizierten Verkehrskanäle für das Sprechermobilteil und die ruhenden Zuhörermobilteile auf vorteilhafte Weise parallel vor.
In einem weiteren Ausführungsbeispiel kann die Ruheaufwecklatenzzeit in einem Gruppenkommunikationsnetzwerk durch Cachen der vom Netzwerk initiierten Aufweckauslöser verringert werden, die für die Zielzuhörer bestimmt sind, und durch Lieferung eines Aufweckauslösers an eine Zielmobilstation sobald die Zielmobilstation ihren Verkehrskanal wiedereingerichtet hat.
In einem weiteren Ausführungsbeispiel wird eine gleichzeitige Dienstveranlassung und ein Paging in einem Mobilteil, das in einem Gruppenkommunikationsnetzwerk operiert, vermieden durch Übertragen einer Antwort auf eine Sprechrechtsteueranfrage, nachdem der Dienstveranlassungsprozess abgeschlossen ist. In einem Ausführungsbeispiel kann die Antwort auf die Sprechrechtsteueranfrage in SDB-Form sein, wenn der Dienstveranlassungsprozess nicht vollendet ist. In einem weiteren Ausführungsbeispiel wird der Dienstveranlassungsprozess für das Quellenkommunikationsgerät nach der Übertragung der Antwort an das Quellenkommunikationsgerät initiiert.

Claims

Ein Verfahren zum Hinzufügen eines neuen Mitgliedes (120) zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk (100); wobei das Verfahren Folgendes aufweist: Empfangen einer Anfrage zum Hinzufügen einer Mitgliederliste zu einem aktiven Gruppenanruf; Hinzufügen der Mitgliederliste zu dem aktiven Gruppenanruf; dadurch gekennzeichnet, dass das Verfahren weiterhin Folgendes aufweist: Ankündigen des Gruppenanrufs an jedes Mitglied (120, 122) in der Mitgliederliste, wobei das Ankündigen das Senden einer Nachricht auf einem Vorwärts-Gemeinsam-Kanal bzw. Forward Common Channel eines drahtlosen Netzwerks beinhaltet; Empfangen einer Bestätigung gesendet auf einem Rückwärts-Gemeinsam-Kanal von einem Mitglied (120) in der Mitgliederliste, das wünscht an dem Gruppenanruf teilzunehmen; Puffern bzw. Zwischenspeichern von Medien (418); und Weiterleiten von gepufferten Medien zu dem Mitglied (120).
Verfahren nach Anspruch 1, das weiterhin das Triggern des Mitglieds (120) zum erneuten Aufbauen bzw. Einrichten seines Verkehrskanals vor dem Weiterleiten der Medien aufweist.
Verfahren nach Anspruch 2, das weiterhin das Puffern (418) von Medien für die Übertragung zu dem Mitglied (120) nach dem erneuten Aufbau seines Verkehrskanals aufweist.
Verfahren nach Anspruch 1, wobei das Senden das Senden der Nachricht auf einem Vorwärts-Paging-Kanal (F-PCH = forward paging channel) des drahtlosen Netzwerks aufweist.
Verfahren nach Anspruch 1, wobei das Senden das Senden der Nachricht auf einem Vorwärts-Gemeinsam-Steuerkanal (F-CCCH = forward common control channel) des drahtlosen Netzwerks aufweist.
Verfahren nach Anspruch 1, wobei das Senden das Senden der Nachricht in Form von Kurzdatenbursts bzw. short data bursts (SDB) aufweist.
Ein computerlesbares Medium (116), das Instruktionen verwendet zum Initiieren eines Gruppenanrufs in einem Gruppenkommunikationsnetzwerk (100), das Kommunikationsgeräte aufweist, wobei die Instruktionen die Kommunikationsgeräte anpassen um: eine Anfrage zum Hinzufügen einer Mitgliederliste zu einem aktiven Gruppenanruf zu empfangen; die Mitgliederliste zu dem aktiven Gruppenanruf hinzuzufügen; dadurch gekennzeichnet, dass die Instruktionen weiterhin die Kommunikationsgeräte anpassen zum: Ankündigen des Gruppenanrufs an jedes Mitglied (120, 122) in der Mitgliederliste, wobei das Ankündigen das Senden einer Nachricht auf einem Vorwärts-Gemeinsam-Kanal eines drahtlosen Netzwerks aufweist; Empfangen einer Bestätigung gesendet auf einem Rückwärts-Gemeinsam-Kanal von einem Mitglied (120) in der Mitgliederliste, das wünscht an einem Gruppenanruf teilzunehmen; Puffern von Medien (418); und Weiterleiten der gepufferten Medien zu dem Mitglied (120)
Computerlesbares Medium nach Anspruch 7, wobei die Kommunikationsgeräte weiterhin durch die Instruktionen angepasst werden zum Triggern bzw. Auslösen, dass das Mitglied (120) erneut seinen Verkehrskanal aufbaut.
Computerlesbares Medium nach Anspruch 8, wobei die Kommunikationsgeräte weiterhin angepasst sind durch die Instruktionen zum Puffern (418) von Medien für die Übertragung zu dem Mitglied (120, 122), nachdem dessen Verkehrskanal wiederaufgebaut ist.
Computerlesbares Medium nach Anspruch 7, wobei die Kommunikationsgeräte weiterhin angepasst sind durch die Instruktionen zum Senden der Nachricht auf einem Vorwärts-Paging-Kanal (F-PCH) des drahtlosen Netzwerks.
Computerlesbares Medium nach Anspruch 7, wobei die Kommunikationsgeräte weiterhin angepasst sind durch die Instruktionen zum Senden der Nachricht auf einem Vorwärts-Gemeinsam-Steuer-Kanal (F-CCCH) des drahtlosen Netzwerks.
Computerlesbares Medium nach Anspruch 7, wobei die Kommunikationsgeräte weiterhin durch die Instruktionen angepasst sind zum Senden der Nachricht in Form eines Kurzdatenbursts (SDB).
Eine Vorrichtung zum Hinzfügen eines neuen Mitglieds (120) zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk (100), wobei die Vorrichtung Folgendes aufweist: Mittel zum Empfangen einer Anfrage zum Hinzufügen einer Mitgliederliste zu einem aktiven Gruppenanruf; und Mittel zum Hinzufügen der Mitgliederliste zu dem aktiven Gruppenanruf; dadurch gekennzeichnet, dass die Vorrichtung weiterhin Folgendes aufweist: Mittel zum Ankündigen des Gruppenanrufs an jedes Mitglied (120, 122) in der Mitgliederliste, wobei die Mittel weiterhin angepasst sind zum Senden einer Nachricht auf einem Vorwärts-Gemeinsam-Kanal eines drahtlosen Netzwerks; Mittel zum Empfangen einer Bestätigung gesendet über einen Rückwärts-Gemeinsam-Kanal von einem Mitglied (120) in der Mitgliederliste, das wünscht an einem Gruppenanruf teilzunehmen. Mittel zum Puffern von Medien (418); und Mittel zum Weiterleiten der gepufferten Medien an das Mitglied (120);
Vorrichtung nach Anspruch 13, das weiterhin Mittel aufweist das Mitglied (120) zu veranlassen seinen Verkehrskanal erneut aufzubauen.
Vorrichtung nach Anspruch 14, das weiterhin Mittel aufweist zum Puffern (418) von Medien für die Übertragung zu dem Mitglied (120), nachdem sein Verkehrskanal erneut aufgebaut ist.
Vorrichtung nach Anspruch 13, wobei die Mittel zum Ankündigen weiterhin Mittel zum Senden der Nachricht auf einem Vorwärts-Paging-Kanal (F-PCH) des drahtlosen Netzwerks aufweist.
Vorrichtung nach Anspruch 13, wobei die Mittel zum Ankündigen Mittel aufweisen zum Senden der Nachricht auf einem Vorwärts-Gemeinsam-Steuer-Kanal (F-CCCH) des drahtlosen Netzwerks.
Vorrichtung nach Anspruch 13, wobei die Mittel zum Ankündigen Mittel aufweisen zum Senden der Nachricht in Form von einem Kurzdatenburst bzw. Kurzdatenbursts (SDB).
Vorrichtung gemäß Anspruch 13, wobei die Vorrichtung einen Empfänger (116) und einen Sender (116) aufweist und die Mittel einen Prozessor (116) aufweisen kommunikativ gekoppelt mit dem Empfänger und dem Sender zum Hinzufügen eines neuen Mitglieds zu einem aktiven Gruppenanruf in einem Gruppenkommunikationsnetzwerk, das angepasst ist zum Empfangen der Anfrage, zum Hinzufügen des Mitglieds, zum Ankündigen des Gruppenanrufs, zum Empfangen einer Bestätigung und zum Puffern und Weiterleiten von Medien.
Vorrichtung nach Anspruch 19, wobei der Prozessor weiterhin angepasst ist zum Triggern bzw. Veranlassen des Mitglieds (120) seinen Verkehrskanal erneut aufzubauen.
Vorrichtung nach Anspruch 20, wobei der Prozessor weiterhin angepasst ist zum Puffern (418) von Medien für die Übertragung zu einem Mitglied (120), nachdem sein Verkehrkanal erneut aufgebaut ist.
Vorrichtung nach Anspruch 19, wobei der Prozessor weiterhin angepasst ist zum Senden der Nachricht auf einem Vorwärts-Paging-Kanal (F-PCH) des drahtlosen Netzwerks.
Vorrichtung nach Anspruch 22, wobei der Prozessor weiterhin angepasst ist zum Senden der Nachricht auf einem Vorwärts-Gemeinsam-Steuerkanal (F-CCCH) des drahtlosen Netzwerks.
Vorrichtung nach Anspruch 22, wobei der Prozessor weiterhin angepasst ist zum Senden der Nachricht in Form von Kurzdatenbursts (SDB).
Vorrichtung nach einem der Ansprüche 13 bis 18, die weiterhin Folgendes aufweist: einen Dispatcher bzw. Einteiler (102, 114) angepasst zum Empfangen der Anfrage zum Hinzufügen des neuen Mitglieds (120) zu dem aktiven Gruppenanruf basierend auf der Mitgliederliste; und ein Steuerelement (116) zum Ankündigen des Gruppenanrufs basierend auf der Mitgliederliste; wobei der Verteiler (102, 114) weiterhin angepasst ist zum Bestimmen von Ortsinformation für jedes Mitglied (120, 122) in der Mitgliederliste; und das Steuerelement (116) weiterhin angepasst ist, um ein lokales Steuerelement für ein Mitglied (120), das innerhalb einer Lokalregion angeordnet ist, zu beinhalten.
Vorrichtung nach Anspruch 25, wobei das Steuerelement (116) ein entferntes Steuerelement (116) für ein Mitglied (120) aufweist, das außerhalb eines Lokalbereichs angeordnet ist.