DE69632469T2

DE69632469T2 - Paketvermittelte verkehrsverwaltung in einem zelluraren ubertragungssystem

Info

Publication number: DE69632469T2
Application number: DE69632469T
Authority: DE
Inventors: Magnus Carl THORNBERG; Erik Olle Grimlund; Magnus Andersson
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1995-09-18
Filing date: 1996-09-13
Publication date: 2005-05-19
Anticipated expiration: 2016-09-14
Also published as: CN1201584A; KR19990045774A; AU7004796A; US5742588A; DE69632469D1; CA2231281A1; JP2000500931A; AU720029B2; CN1092905C; EP0852100A1; WO1997011568A1; EP0852100B1

Description

Hintergrund der Erfindung
Die vorliegende Erfindung betrifft paketvermittelte Telekommunikationssysteme und insbesondere ein Verfahren und ein System zum Verwalten von paketvermitteltem Verkehr in einem zellularen Telekommunikationsnetzwerk.
Beschreibung des Standes der Technik
Da sich die Möglichkeiten zum Anbieten einer größeren Zahl und einer größeren Vielfalt an Diensten in zellularen Telekommunikationsnetzwerk-Systemen weiter entwickeln, werden paketvermittelte Dienste auf dem Gebiet der zellularen Telekommunikation eine immer wichtigere Rolle spielen. Die Anwendung vieler Computer und verwandter Datendienste in zellularen Systemen macht den Transfer von einzelnen oder multiplen Datenpaketen über die Funkverbindung eines zellularen Telekommunikationssystems erforderlich. Bestimmte dieser Dienste, wie beispielsweise e-Mail und Bankgeschäfte übers Telefon, können mit einem Speicher und einem Kurznachrichtenweiterleitungs-Dienst realisiert werden. Weitere Dienste, wie die Endgeräte-Nachahmung, die Ortsnetzwerke, der Bank-Server-Zugang, und die Kreditkartenprüfung, erfordern jedoch eine interaktive Nutzung, kurze Zeitverzögerungen und die Befähigung, Datenpakete mit sehr unterschiedlichen Längen zu behandeln. Es steht fest, dass die zukünftigen zellularen Systeme solche Dienste mit einem effizienten Paketdatendienst unterstützen müssen.
Die Erkenntnis der Bedeutung von Paketdatendiensten hat zu den gegenwärtigen Anstrengungen des European Technical Standards Institute (ETSI) geführt, solch einen Dienst für das zellulare System der European 2+ Group Special Mobile (GSM) zu entwickeln. Diese Erkenntnis hat ebenfalls zu der Bemühung um die Gestaltung der Paketdatendienst-Möglichkeiten bei Universal Mobile Telephone System (UTMS) geführt, welches sich gegenwärtig im RACE II Code Division Testbed (CODIT)-Projekt R2020 in der Entwicklung befindet. Das CODIT-Projekt wurde von der Kommission der Europäischen Gemeinschaft für den Zweck der Definition eines zukünftigen mobilen Telekommunikationssystem erarbeitet, das die Techniken des Codemultiplex-Vielfachzugriffs (CDMA) verwendet.
Der paketvermittelte Datendienst in einem zellularen Kommunikationssystems-Netzwerk ist durch Anrufe von Netzwerkbenutzern an mobile Benutzer gekennzeichnet, die zu paketvermittelten mobilen Stationen auf der Gemeinschafts-Abwärtsstrecke (DL)eines paketvermittelten Funkkanals (PRCH) übertragen werden, wobei ein oder mehrere mobile Benutzer sich die Aufwärtsstrecke (UL) des paketvermittelten Funkkanals teilen. Die Abwärtsstrecke des paketvermittelten Funkkanals wird von den Netzwerkbenutzern auf Warteschlangen-Basis gemeinsam benutzt. Die Aufwärtsstrecke (UL) des paketvermittelten Funkkanals (PRCH) wird von jedem mobilen Benutzer, der bei Bedarf auf den Kanal zufällig zugreift, um Daten zum System zu übertragen, anteilsmäßig genutzt.
Ein übliches Verfahren zur Ermöglichung eines Zugriffs auf den paketvermittelten Funkkanal ist der paketvermittelte Konkurrenz-Modus. Der gegenwärtig definierte Paket-Datendienst des CODIT UMTS (Universal Mobile Telecommunication) ist ein Dienst vom Typ des Konkurrenz-Modus. Im paketvermittelten Konkurrenz-Modus übertragen mobile Benutzer Datenpakete auf dem paketvermittelten Funkkanal, wenn Daten übertragen werden müssen. In jedem Datenpaket ist eine Identifikation des übertragenden mobilen Benutzers enthalten. Die Übermittlung der Datenpakete kann vom mobilen Benutzer zufällig oder nach dem Abtasten eines Freisignals erfolgen, das anzeigt, dass der Paketdatenkanal gegenwärtig nicht von einer anderen mobilen Station genutzt wird. Wenn sich zwei oder mehr mobile Benutzer gleichzeitig um einen freien Paketdatenkanal bewerben, ermöglicht das System nur einen Zugriff auf den Kanal. Mobile Benutzer, die keinen Erfolg beim Zugriff auf den Kanal hatten, müssen die Übertragung des Datenpakets solange wiederholen, bis das System sie akzeptiert. Ferner bewerben sich die Benutzer des Systems, die Datenpakete zu mobilen Benutzern übertragen, auch um die Abwärtsstrecke, indem sie in einer Warteschlange platziert werden.
Da in einem solchen System jeder Benutzer nach dem Zufallsprinzip auf den paketvermittelten Kanal zugreift, kann der ungesteuerte Strom von Benutzern zu, von und zwischen den paketvermittelten Funkkanälen Paketübertragungsverzögerungen im System verursachen. Die Verzögerung kann sowohl durch mobile Benutzer auf der Aufwärtsstrecke, als auch durch Netzwerkbenutzer verursacht werden, die auf der Abwärtsstrecke an mobile Benutzern übertragen. Wenn die Zahl der Paketaufrufe auf dem paketvermittelten Kanal zunimmt, nimmt auch die durchschnittliche Übertragungsverzögerung für jeden Paketruf zu. Für bestimmte Anwendungen können die Verzögerungen nicht akzeptabel sein.
WO 95/16330 betrifft Apparate und mobile Stationen für eine Bereitstellung von Paketdatenkommunikation in digitalen zellularen Zeitvielfachzugriffs-Systemen (TDMA). Es sind Apparate und mobile Stationen beschrieben, die Paketdatendienste in zellularen Zeitvielfachzugriffs-Systemen bereitstellen und die darauf beruhen, dass Gemeinschafts-Paketdatenkanäle bereitgestellt werden, die für Paketdaten optimiert wurden.
Eine erste "integrierte" Ausführungsform verwendet die gegenwärtige zellulare Infrastruktur in dem Maße, indem sie mit den Funktions- und Leistungsanforderungen übereinstimmt.
Gemeinschafts-Paketdatenkanäle (PDCH) in den Basisstationen (BTS, BSC) können auf Anforderung dynamisch bestimmt bereitgestellt werden. Ein Paketdaten-Controller in jeder Vermittlungsstelle für mobile Dienste (MSC) steuert den Zugriff auf die Paketdatendienste.
In jeder Vermittlungsstelle für mobile Dienste leitet ein Paketdaten-Router Pakete zur Dienststelle der Vermittlungsstelle für mobile Dienste und von derselben weg. Ein Haupttrassennetzwerk verbindet Paketdaten-Router und Netzanpassungsfunktionen (IWF) die die Zusammenarbeit mit dem Ethernet bereitstellen.
Eine zweite "separate" Ausführungsform verwendet zur Minimierung der Auswirkungen auf das gegenwärtige zellulare System primär den Basisstationsabschnitt des zellularen Systems für die restlichen Netzwerkteile, die auf einer separaten mobilen Paketdaten-Infrastruktur beruhen.
EP 0 332 818 bezieht sich auf ein paketvermitteltes zellulares Telefonsystem. Ein einmal vorhandenes paketvermitteltes zellulares Telefonsystem enthält einen zellularen Schalter und Basisstellen zur Bereitstellung von paketvermittelten Datendiensten für zellulare Datentelefone.
Der zellulare Schalter enthält Paketzugriffspunkte, die mit einem Paketnetzwerk gekoppelt sind, und T1 span lines (Stammleitungen), die mit dem drahtgebundenen Telefonnetz gekoppelt sind. Die Basisstellen sind über die T1 span lines mit dem zellularen Schalter gekoppelt, in dem alle Zeitschlitze freie Kanäle sind und ein Zeitschlitz für die allgemeine Kanal-Zeichengabe bestimmt ist.
Jedem Paketmodus-Funkkanal sind mehrere Datenaufrufe zugeordnet, so dass das wertvolle Funkkanalspektrum erhalten bleibt. Datenaufrufe werden auf der Grundlage der zellularen Datentelefonbewegung, der Signalstärke und/oder der Bitfehlerrate oder auf der Grundlage der Datenpaketkapazität des Funkkanals, des Datenpaketverkehrs und/oder des Datenpakets insgesamt von einem Paketmodus-Funkkanal zu einem anderen weitergereicht.
Es besteht daher Bedarf an einem Verfahren und einem System zur Steuerung der Paketübertragungsverzögerung auf einem oder mehreren paketvermittelten Funkkanälen eines zellularen Systems. Wenn miteinander konkurrierende Paketrufe selektiv zum Zugang zu einem Paketfunkkanal in Übereinstimmung mit vorab definierten Kriterien gewählt werden, können Verzögerungen für paketvermittelte Kanalbenutzer in Anwendungen vermieden und reduziert werden, bei denen eine lange Paketverzögerungszeit nicht toleriert werden kann.
Ein Verfahren und ein System zum Verwalten des Stroms von Benutzern mit Priorität zu einem oder mehreren paketvermittelten Funkkanälen, von denselben weg oder zwischen denselben, wobei jeder paketvermittelte Funkkanal eine maximal tolerierbare Paketübertragungs-Verzögerung aufweist, würde diesen Bedarf befriedigen.
Zusammenfassung der Erfindung
Die vorliegende Erfindung gibt ein Verfahren und ein System zum Verwalten von paketvermitteltem Verkehr in einem zellularen Telekommunikationssystem an. Ein Systemoperator kann Paketverkehr für Benutzer mit definierter Priorität auf einem oder mehreren paketvermittelten Funkkanälen (PRCH) verwalten, von denen jeder eine maximal tolerierbare Paketübertragungsverzögerung aufweist. Die Anzahl der Paketrufe, die den paketvermittelten Funkkanal nutzen, kann gesteuert werden, wodurch die durchschnittlichen Paketverzögerungen sowohl auf der Aufwärtsstrecke als auch auf der Abwärtsstrecke des paketvermittelten Funkkanals ebenfalls gesteuert werden können. Probleme in Verbindung mit den herkömmlichen paketvermittelten Systemen vom Konkurrenzmodus, in denen die Benutzer jeweils auf Zufallsbasis um die Nutzung des paketvermittelten Funkkanals konkurrieren, werden vermieden. In solchen herkömmlichen Systemen wird die Anzahl der Paketrufe auf einem paketvermittelten Funkkanal nicht gesteuert, und die durchschnittliche Zeitverzögerung für die Datenpaketübertragung nimmt mit der Anzahl der Benutzer zu, die sich um den paketvermittelten Funkkanal bewerben.
Gemäß einer Ausführungsform umfaßt die Erfindung eine Verwaltungsfunktion des paketvermittelten Funkkanals für jede Basisstation oder für die Basisstationen, die eine Zelle eines zellularen Systems steuert, die einen oder mehrere PRCH-Funkkanäle aufweist. Ebenfalls ist eine separate PRCH-Steuerfunktion für jeden paketvermittelten Funkkanal in der Zelle enthalten. Der PRCH-Manager kommuniziert für jede Zelle mit dem einen oder den mehreren PRCH-Controllern die die dieser Zelle zugeordneten paketvermittelten Funkkanäle steuern. Der PRCH-Manager führt die Funktionen der Auswertung der Dienste-Anforderungen der Benutzer, die die Nutzung eines paketvermittelten Funkkanals anfordern, der Auswertung der Wiederzulassung von Paketrufen, die infolge von Staus von einem paketvermittelten Funkkanal abgewiesen wurden, und der Abarbeitung der Zugangsschlange zum paketvermittelten Funkkanal sowie der Verwaltung des aktiven paketvermittelten Funkkanals einer Zelle aus. Die PRCH-Controller führen die Funktionen der Überwachung des stattfindenden Verkehrs, der Steuerung des Zugangs und der Steuerung von Verkehrsstaus für jeden einzelnen paketvermittelten Funkkanal aus. Ferner ist ein Ressourcenverwalter mit dem PRCH-Manager verbunden.
Wenn ein Benutzer Zugang zur Aufwärts- oder Abwärtsstrecke oder sowohl zur Aufwärts- als auch zur Abwärtsstrecke eines paketvermittelten Funkkanals einer Zelle benötigt, wird die PRCH-Managerfunktion der Zelle aufgerufen. Die PRCH-Managerfunktion kann in verschiedenen Situationen aufgerufen werden. Der Empfang einer Diensteanforderung über den Netzwerkprotokollstapel ruft den PRCH-Manager auf. Er wird ebenfalls aufgerufen, wenn ein Paketruf von einem paketvermittelten Funkkanal infolge eines Staus abgewiesen wurde, und es wird eine Anzeige 'Paketruf abgewiesen' von einem PRCH-Controller erhalten. Der PRCH-Manager wird auch aufgerufen, wenn im paketvermittelten Funkkanal ein intern erzeugtes Signal 'Zugang zur Schlange' erzeugt wurde, oder wenn ein Signal 'PRCH-Aufbau gewährt/abgelehnt' oder 'PRCH lösche Signal gewährt/abgelehnt' vom Ressourcenmanager empfangen wurde.
Vom PRCH-Manager kann eine Diensteanforderung erhalten werden, wenn ein neuer Benutzer einen Zugang zu einem paketvermittelten Funkkanal wünscht, wenn ein Benutzer an einen neuen paketvermittelten Funkkanal in einer neuen Zelle zu übergeben wünscht, oder wenn ein Benutzer eine verlorengegangene Verbindung wiederherzustellen wünscht. Wenn eine Diensteanforderung erhalten wurde, wertet der PRCH-Manager die Anforderung durch aufeinanderfolgendes Senden einer Zugangsanforderung an die PRCH-Controller der Zelle aus. Wenn irgendein PRCH-Controller die Anforderung genehmigt, wird dem Benutzer der entsprechende PRCH zugeordnet und über den Netzwerkprotokollstapel ein Signal 'Dienst gewährt' an den Benutzer gesendet. Wenn keiner der PRCH-Controller die Zugangsanforderung genehmigt, wertet der PRCH-Manager aus, ob die Identität des Paketrufs in eine PRCH-Zugangsschlange der Zelle (temporär ausgesetzt) gesetzt wird oder ob die Diensteanforderung abgelehnt wird. Wenn die Identität des Paketrufs in die Zugangsschlange gesetzt wird, wird über den Netzwerkprotokollstapel ein Anzeigensignal 'Paketruf ausgesetzt' an den Benutzer gesendet. Anderenfalls wird ein Signal 'Dienst abgelehnt' gesendet.
Wenn der PRCH-Manager ein Signal 'Paketruf abgewiesen' erhält, bewertet er die Anzeige 'Paketruf abgewiesen', indem er an die PRCH-Controller der Zelle nacheinander eine Zugangsanforderung sendet. Wenn irgendein PRCH-Controller der Anforderung zustimmt, wird dem abgewiesenen Benutzer der entsprechende paketvermittelte Funkkanal zugeordnet und dem Benutzer wird ein Anzeigensignal für eine Paketrufaktualisierung gesendet. Wenn keiner der PRCH-Controller der Anforderung zustimmt, beurteilt der PRCH-Manager, ob die Identität des abgelehnten Paketrufs in die PRCH-Zugangsschlange der Zelle gestellt werden soll, oder ob der abgewiesene Paketruf abgesetzt werden soll. Wird die Identität des Paketrufs in die Zugangsschlange gestellt, wird ein Anzeigensignal 'Paketruf ausgesetzt' über den Netzwerkprotokollstapel an den Benutzer gesendet. Anderenfalls wird dem Benutzer ein Anzeigensignal 'Paketruf abgesetzt' gesendet.
Wenn ein intern erzeugtes Zugangsschlangensignal erzeugt wird, führt der PRCH-Manager die Zugangsschlangenabwicklung durch. Das Zugangsschlangensignal gibt an, daß der PRCH-Manager die Zugangsschlange nach in der Schlange stehenden Paketrufen überprüft. Bei der Zugangsschlangenabwicklung sendet der PRCH-Manager nacheinander eine Zugangsanforderung für den Paketruf mit der höchsten Priorität in der Schlange an die PRCH-Controller der Zelle aus. Die Zugangsanforderungen werden in der gleichen Weise versandt, wie das bei den Schritten der Diensteanforderungs-Beurteilung und der Zugangsanforderung bei der Beurteilung 'Paketruf abgewiesen' geschieht. Wenn irgendein PRCH-Controller die Anforderung gewährt, wird der Paketruf in der Zugangsschlange dem entsprechende paketvermittelten Funkkanal zugeordnet und dem Benutzer wird ein Anzeigensignal 'Paketrufwiederaufnahme' gesendet. Gewährt keiner der PRCH-Controller die Anforderung, wird kein Anzeigensignal 'Paketrufwiederaufnahme' gesendet.
Wenn der PRCH-Manager vom Ressourcenmanager der Zelle eine Erlaubnis für den Aufbau eines paketvermittelten Funkkanals erhält, erzeugt der PRCH-Manager für den neuen paketvermittelten Funkkanal eine neue PRCH-Controller-Funktion. Wenn der PRCH-Manager vom Ressourcenmanager der Zelle eine Freigabeerlaubnis erhält, löscht der PRCH-Manager die PRCH-Controller-Funktion für den freigegebenen paketvermittelten Funkkanal.
Kurze Beschreibung der Zeichnungen
Ein umfassenderes Verständnis des Verfahrens und des Systems der vorliegenden Erfindung wird unter Bezug auf die folgende detaillierte Beschreibung im Zusammenhang mit den beigefügten Zeichnungen ermöglicht, in denen zeigen:
1 ein Blockdiagramm eines zellularen Telekommunikationssystems, in das die vorliegende Erfindung eingebaut werden kann,
2 eine Steuerebenen-Protokollarchitektur für die Paketschaltfunktionen eines zellularen Kommunikationssystems, in die die vorliegende Erfindung eingebaut werden kann,
3A und 3B den Signalaustausch auf der Abwärtsstrecke bzw. der Aufwärtsstrecke des zellularen Systems eines Paket-Funkkanals, der in Übereinstimmung mit der vorliegenden Erfindung arbeitet,
4 ein Funktionsblockdiagramm der Verwaltungsfunktionen des Paketfunkverkehrs in einem zellularen System, das in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung arbeitet,
5A–5D Flußdiagramme, die die Verarbeitungsschritte, gefolgt von der Managerfunktion des Paketfunkkanals in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigen,
6 ein Flußdiagramm, das die Verarbeitungsschritte, gefolgt von der Verkehrsüberwachungsfunktion des Paketfunkkanal-Controllers in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt,
7 ein Flußdiagramm, das die Verarbeitungsschritte, gefolgt von der Zugangssteuerfunktion des Paketfunkkanal-Controllers in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt,
8 ein Flußdiagramm, das die Verarbeitungsschritte, gefolgt von der Stausteuerfunktion des Paketfunkkanal-Controllers in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt, und
9 ein Flußdiagramm, das die Verarbeitungsschritte, gefolgt von der Ressourcenmanagerfunktion des Paketfunkkanals in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt.
Detaillierte Beschreibung
In 1 ist ein Blockdiagramm eines zellularen Telekommunikationssystems 100 gezeigt, in das die vorliegende Erfindung eingebaut werden kann. Das zellulare System 100 umfaßt einen mobilen Steuerknoten (MCN) 102, Funknetzwerk-Controller (RNC) 104 und 106, Basisstationen (BS) 108, 110, 112, 114, 116 und 118 und mobile Stationen (MS) 120, 122 und 124. Jede Basisstation 108, 110, 112, 114, 116 und 118 steuert die Funkkommunikation des Systems mit den mobilen Stationen innerhalb des durch den Funk abgedeckten Gebiets, eine Zelle der Basisstation genannt.
In Abhängigkeit davon, in welchem Gebiet des durch den Funk abgedeckten Gebiets sich die mobile Station (MS) befindet, kommunizieren die mobilen Stationen (MS) 120, 122 und 124 mit einer bestimmten Basisstation (BS) der Basisstationen (BS) 108, 110, 112, 114, 116 und 118. In 1 ist gezeigt, dass die mobilen Stationen 120, 122 und 124 über die Funkschnittstellen 128, 130 und 132 mit den Basisstationen 108, 112 bzw. 116 kommunizieren. Die Basisstationen 108, 110 und 112 sind mit dem Funknetzwerk-Controller (RNC) 104 verbunden, und die Basisstationen 114, 116 und 118 sind mit dem Funknetzwerk-Controller (RNC) 106 verbunden. Die Funknetzwerk-Controller 104 und 106 sind wiederum mit dem mobilen Steuerknoten 102 verbunden. Der mobile Steuerknoten 102 ist eine Vermittlungsstelle, die die Verbindung des zellularen Systems mit dem Festnetzwerk 126 unterstützt. Der mobile Steuerknoten 102 kann drahtgebunden oder über andere äquivalente Verbindungen mit dem Festnetzwerk 126 verbunden sein. Das Festnetzwerk 126 kann ein Internet-Netzwerk, ein öffentliches Telefonnetzwerk (PSTN), ein dienstintegriertes Digitalnetz (ISDN), ein paketvermitteltes öffentliches Datennetzwerk (PSPDN) oder ein X.25-System sein. Während das zellulare Kommunikationssystem von 1 als spezielle Konfiguration gezeigt ist, soll das Blockdiagramm nur eine beispielhafte Konfiguration eines Systems darstellen, in dem die vorliegende Erfindung implementiert werden kann. Die Erfindung kann in jedem paketvermittelten Funksystem verwendet werden, in dem Benutzer sich um einen paketvermittelten Funkkanal (PRCH) bewerben.
In einer Ausführungsform der Erfindung arbeitet das zellulare System 100 in Übereinstimmung mit Protokollen, die für das Projekt Code Division Testbed (CODIT) des Universal Mobile Telecommunication System (UMTS) entwickelt wurden, wobei der für CODIT/UMTS spezifizierte PRCH-Zugang im Konkurrenz-Modus von der PRCH-Verkehrsverwaltungsfunktion der Erfindung gesteuert wird. UMTS ist ein mobiles Kommunikationssystem, das den DS-CDMA-Zugang (Direktsequenz-Codemutliplex-Vielfachzugriff) mit einer Mehrraten-Funkschnittstellen-Architektur nutzt. Im CODIT/UMTS-System wird der Paketfunkdienst über einen oder mehrere paketvermittelte Funkkanäle an die mobilen Stationen 120, 122 und 124 geliefert. Jede Basisstation 108, 110, 112, 114, 116 und 118 richtet einen oder mehrere paketvermittelte Funkkanäle auf Anforderung der Funknetz-Controller 104 und 106 oder des mobilen Steuerknotens 102n ein und beendet denselben/dieselben. Der paketvermittelte Funkkanal ist ein vollständiger Duplex- und asymmetrischer Kanal, der sowohl auf der Aufwärts- als auch auf der Abwärtsstrecke bei variablen Datenraten der mobilen Station bis zu 9,6 kbps (Schmalbandkanal) oder bis zu 64 kbps (Mittelbandkanal) unabhängig betrieben werden kann. Der mobile Steuerknoten 102 kann mehrere mobile Stationen in einer einzigen Zelle auf einen einzigen paketvermittelten Funkkanal aufbringen. Um mehrere mobile Stationen in einem paketvermittelten Funkkanal zu unterscheiden, ordnet der mobile Steuerknoten 102 jeder mobilen Station einen virtuellen Verbindungs-Identifikator (VCI) zu, wenn er den Zugang gewährt. Der Verbindungs-Identifikator wird durch eine kBit-Zahl dargestellt und dient in dem vom mobilen Steuerknoten 102 gesteuerten Gebiet als eine einmal vorhandene Adresse.
Der paketvermittelte Funkkanal ist zur Übertragung von Fragmenten von Paketen zwischen den mobilen Stationen 120, 122 und 124 und dem Netzwerk in Zeitschlitzen von 10 msec. aufgebaut. Auf der Abwärtsstrecke kann der mobile Steuerknoten 102 Datenpakete und Informationen zur Steuerung des Zugangs und des Datentransfers auf der Aufwärtsstrecke an eine mobile Station oder gleichzeitig an mehrere mobile Stationen senden. Auf der Aufwärtsstrecke können sich die mobilen Stationen den Zugang zu einem Aufwärtsstrecken-PRCH teilen, wenn sie in dem Gebiet liegen, das durch die gleiche Basisstation abgedeckt ist. Nachdem der Zugang zum paketvermittelten Funkkanal erhalten wurde, überträgt die mobile Station das Paket über einen physischen Kanal zu dem System. Der Logik-Kanal des paketvermittelten Funkkanals ist auf zwei physischen Kanälen abgebildet, die einen physischen Datenkanal (PDCH) und einen physischen Steuerkanal (POCH) enthalten. Zur Unterstützung eines paketvermittelten Funkkanals sind zwei Basisstations-Transceiver erforderlich.
In 2 ist der Protokollstapel 200 für die Paketvermittlungsfunktionen der CODIT/UMTS gezeigt. In der mobilen Station umfaßt der Protokollstapel (MS/PS) 218 der mobilen Station eine Netzwerkschicht 202, eine Datenverbindungs-Steuerschicht (DLC) 204, eine Medium-Zugangs-Steuerschicht (MAC) 206 und die physische Schicht 208. Auf der Netzwerkseite umfaßt der Netzwerk-Protokollstapel (NW/PS) 220 eine Netzwerkschicht 210 und eine Datenverbindungs-Steuerschicht 212, wobei jede dieser Schichten entweder im mobilen Steuerknoten (MCN) oder im Funknetzwerk-Controller (RNC) angeordnet ist, eine Medium-Zugangsschicht (MAC) 214, die in der Basisstation und im mobilen Steuerknoten (MCN) oder im Funknetzwerk-Controller (RNC) angeordnet ist, und eine physische Schicht 216.
Die verbindungslose Paketdiensteeinheit (CLPS) der Netzwerkschicht 202 stellt den Paketdienst zur mobilen Station zur Verfügung. Die verbindungslose Paketdiensteeinheit der Netzwerkschicht 210 stellt die Funktionen der Eintragung, Authentisierung, Zuordnung und Verwaltung des virtuellen Verbindungs-Identifikators (VCI) und eine Schnittstelle zu einem Paketdatennetzwerk zur Verfügung. Während eines Paketrufs verwenden die verbindungslose Paketdiensteeinheiten einen Logikverbindungs-Administrator (LLA), um über einen dafür bestimmten Steuerkanal (DCCH und CC) die Aufbausignale für den Leitweg des Paketdienstes zu initialisieren. Nach dem Paketdiensteaufbau wird die mobile Station an einen paketvermittelten Funkkanal angelegt und alle Nachrichten zwischen den verbindungslosen Paketdiensteeinheiten, einschließlich der Datenpakete der mobilen Station, werden durch die Datenverbindungsschicht zu einer Paketfunk-Steuereinheit (PR) geleitet. Die Paketfunk-Steuereinheit ist auch für normale Mobiltelefon-Systemfunktionen, beispielsweise die Leitungsübergabe, die erneute Einrichtung einer Verbindung etc., verantwortlich.
Die über den paketvermittelten Funkkanal zu übertragenden Pakete sind Fragmente, die zur Erfassung von Übertragungsfehlern auf der Empfängerseite mit einem Block-Code (BC) geschützt sind, als Konvolut codiert sind, überlappt (IL) sind, durch einen Multiplexer (MUX) vermittelt und dann über den physischen Datenkanal (PDCH) übertragen werden. Steuerinformationen, z. B. zur Steuerung des Stroms, können auch über den physischen Steuerkanal (POCH) übertragen werden. Auf der Empfängerseite werden die Fragmente aus den empfangenen Teilen rekonstruiert, wieder zu Paketen zusammengestellt und zu einer verbindungslosen Paketdiensteeinheit (CLPS) geschickt. Wenn ein Block-Decodierer auf der Empfängerseite den Empfang eines fehlerhaften Paketfragments erfaßt, fordert eine Paketfunk-Steuerfunktion seine erneute Übertragung an. In einem zellularen System 100 kann es mehrere paketvermittelte Funkkanäle geben, die auf die Zellen verteilt sind, die von den Basisstationen 108, 110, 112, 114, 116 und 118 gesteuert sind.
In den 3A und 3B ist der Austausch von Signalen auf der Aufwärtsstrecke bzw. der Abwärtsstrecke eines zellularen Systems paketvermittelter Funkkanäle dargestellt, das in Übereinstimmung mit der vorliegenden Erfindung arbeitet. Die 3A und 3B zeigen den Austausch von Signalen zwischen einer mobilen Station (MS) und dem Netzwerk (NW) 302. Die mobile Station 300 ist funktionell als Protokollstapel (MS/PS) 218 der mobilen Station und Systemmanager (MS/SM) 220 der mobilen Station gezeigt. Das Netzwerk 302 ist funktionell als Netzwerk-Protokollstapel (NW/PS) 222 und Netzwerk-Systemmanager (NW/SM) 224 gezeigt. Der Protokollstapel ist für die Datenübertragung und der Systemmanager ist für die Steuerung und Überwachung der Verbindung zwischen dem Netzwerk und der mobilen Station verantwortlich.
Für die Paketübertragung und den -Empfang auf Aufwärtsstecken (UL) wird das folgende Schema verwendet (die Schritte entsprechen der Nummerierung der Pfeile in 3A).

1U. Der Protokollstapel 218 der mobilen Station kann drei verschiedene Arten von Paketen an den Netzwerk-Protokollstapel 222 senden, zwei derselben benötigen eine Bestätigung.
a. Pakete, die eine Bestätigung benötigen:
– Pakete, die Benutzerdaten enthalten, und
– Pakete, die Benutzerdaten mit Huckepack-Abwärtsstrecken-Berichten (DLR) enthalten.
b. Pakete, die keine Bestätigung benötigen:
– Pakete, die nur Abwärtsstrecken-Berichte (DLR) enthalten. Im Systemmanager 220 der mobilen Station (MS/SM) wird ein Zeitgeber (Timer) eingestellt, wenn ein Paket versandt wird, das eine Bestätigung benötigt. Läuft der Zeitgeber ab, bevor eine Bestätigung empfangen wurde, wird das Paket als verlorengegangen angesehen.
2U. Für alle Aufwärtsstrecken-Datenpakete werden an den Netzwerk-Systemmanager (NW/SM) 224 Qualitätsmuster geschickt. Am Ende des Aufwärtsstrecken-Datenpakets wird an den Netzwerk-Systemmanager 224 ein Paket-Stop-Signal gesendet, das anzeigt, dass für das spezielle Paket das letzte Qualitätsmuster geschickt wurde.
3U. Nach dem Empfang eines Aufwärtsstrecken-Datenpakets wird an den Netzwerk-Systemmanager 224 ein Aufwärtsstrecken-Paketbericht gesendet. Dieser Bericht enthält Informationen, die für die Verkehrsüberwachung benötigt werden.
4U. Wenn das Aufwärtsstrecken-Paket einen Huckepack-Abwärtsstrecken-Bericht enthält, oder wenn das Paket nur ein Abwärtsstrecken-Bericht ist, wird die Abwärtsstrecken-Qualitätsbeurteilung herausgezogen und an den Netzwerk-Systemmanager 224 gesandt.
5U. Wenn das übertragene Aufwärtsstrecken-Datenpaket eine Bestätigung benötigt, wird vom Netzwerk-Protokollstapel 222 an den Protokollstapel 218 der mobilen Station eine Bestätigungsnachricht gesandt. Die Nachricht kann ein reines Informationspaket sein oder sie kann ein Informationspaket sein, das sich auf einem Informationspaket der Abwärtsstrecken-Mobilstation als Huckepack-Typ befindet.
6U. Nachdem im Protokollstapel 218 der mobilen Station eine Bestätigung erhalten wurde, wird an den Systemmanager 220 der mobilen Station ein Paketbestätigungssignal gesendet. Wird keine Bestätigung erhalten, bevor der Zeitgeber, der im Schritt 1 oben eingesetzt ist, abläuft, wird an den Systemmanager 220 der mobilen Station eine Nachricht 'Paket verloren' gesandt.

Für die Abwärtsstrecken-Paketübertragung und den -Empfang wird das folgende Schema verwendet (die Schritte entsprechen der Nummerierung der Pfeile in 3B):

1D. Der Netzwerk-Protokollstapel 222 kann drei verschiedene Arten von Paketen an den Protokollstapel 218 der mobilen Station senden, von denen zwei eine Bestätigung benötigen:
a. Pakete, die eine Bestätigung benötigen:
– Pakete, die Benutzerdaten enthalten, und
– Pakete, die Benutzerdaten mit Huckepack-Informationen 'Bestätigung/keine Bestätigung (ack/nack)' für vorher erhaltene Aufwärtsstrecken-Pakete enthalten.
b. Pakete, die keine Bestätigung benötigen:
– Pakete, die nur ack-/pack-Informationen für vorher erhaltene Aufwärtsstrecken-Pakete enthalten. Wenn Pakete gesendet werden, die eine Bestätigung benötigen, wird ein Zeitgeber eingestellt. Läuft der Zeitgeber ab, bevor eine Bestätigung empfangen wurde, wird das Paket als verlorengegangen angesehen.
2D. Wenn ein Abwärtsstrecken-Datenpaket übertragen wird, wird an den Netzwerk-Systemmanager 224 ein Abwärtsstrecken-Paketbericht gesandt. Der Bericht enthält Informationen, die für die Verkehrsüberwachung benötigt werden.
3D. Wenn ein Abwärtsstrecken-Datenpaket im Protokollstapel 218 der mobilen Station empfangen wird, werden für jeden Rahmen Qualitätsmuster genommen und an den Netzwerk-Protokollstapel 220 gesandt. Am Ende des Abwärtsstrecken-Datenpakets wird an den Netzwerk-Protokollstapel 220 ein Paket-Stop-Signal gesendet, das anzeigt, dass für das spezielle Paket das letzte Qualitätsmuster geschickt wurde.
4D. Nach dem Empfang eines Paket-Stop-Signals wird an den Protokollstapel 218 der mobilen Station eine Qualitätsbeurteilung gesandt. Diese Beurteilung ist ein Maß für die Qualität des gesamten, auf der Abwärtsstrecke versandten Pakets.
5D. An den Netzwerk-Protokollstapel 222 wird für jedes erhaltene Abwärtsstreckenpaket, das Benutzerdaten enthält, ein Abwärtsstreckenbericht (DLR) gesandt, der eine ack-/nack-Nachricht und eine Qualitätsbeurteilung enthält. Der Abwärtsstreckenbericht kann entweder einzeln oder huckepack auf einem Aufwärtsstrecken-Datenpaket eines Benutzers versandt werden. Nach dem Empfang des Abwärtsstreckenberichts im Netzwerk-Protokollstapel 222 wird die Qualitätsbeurteilung an den Netzwerk-Systemmanager 224 versandt.
6D. Wenn die ack-/nack-Information im Abwärtsstreckenbericht eine Bestätigung enthält, wird an den Netzwerk-Systemmanager 224 ein Paket-Bestätigungssignal gesandt. Wird keine Bestätigung erhalten, bevor der Zeitgeber, der im Schritt 1 oben eingesetzt wurde, abläuft, wird an den Netzwerk-Systemmanager 224 eine Nachricht 'Paket verloren' gesandt.

In 4 ist ein Funktionsblockdiagramm der Verwaltungsfunktionen des Paketfunkverkehrs in einem zellularen System dargestellt, das in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung arbeitet. Die Funktionen der Verwaltungsfunktionen des Paketfunkverkehrs, deren Logikanordnung sich im Netzwerk-Systemmanager 224 befindet, umfassen drei Hauptblöcke. Den PRCH-Manager 402, den Ressourcenmanager 404 und die PRCH-Controller 406a, 406b, 406c und 406d. Normalerweise gibt es einen PRCH-Manager 402 in jeder Basisstation des Systems. Unterstützt eine Basisstation mehr als eine Zelle, gibt es einen PRCH-Manager 402 für jede Zelle. Die Anzahl der PRCH-Controller 406a, 406b, 406c und 406d hängt von der Anzahl der erforderlichen paketvermittelten Funkkanäle und von den für den paketvermittelten Verkehr in der Zelle verfügbaren Ressourcen ab. In der in 4 gezeigten Ausführungsform sind vier paketvermittelte Funkkanäle in der Zelle. Jeder PRCH-Controller steuert einen paketvermittelten Funkkanal. Der PRCH-Manager 402 wird aufgerufen, wenn ein Benutzer einen Zugang zu einem paketvermittelten Funkkanal der Zelle benötigt. Der Empfang einer Diensteanforderung über den Netzwerk-Protokollstapel 222 ruft den PRCH-Manager 402 auf. Der PRCH-Manager 402 wird ebenfalls aufgerufen, wenn ein Paketruf infolge eines Staus von einem paketvermittelten Funkkanal abgewiesen wurde, und von einem PRCH-Controller wird eine Anzeige 'Paketruf abgewiesen' erhalten. Zusätzlich wird der PRCH-Manager 402 aufgerufen, wenn vom Ressourcen-Manager ein intern erzeugtes Zugangsschlangen-Signal oder ein Signal 'PRCH-Aufbau gewährt/abgelehnt' oder ein Signal 'Freigabe gewährt/abgelehnt' erhalten wurde.
Eine Diensteanforderung kann in einer der folgenden Situationen erhalten werden:

1) Ein neuer Benutzer wünscht einen Zugang zu einem paketvermittelten Funkkanal, um einen Paketvermittlungsdienst zu initiieren.
2) Ein Benutzer wünscht eine Weiterschaltung von einem paketvermittelten Funkkanal einer anderen Zelle zu einem paketvermittelten Funkkanal der Zelle, in der sich der PRCH-Manager 402 befinet.
3) Ein Benutzer möchte eine verlorengegangene PRCH-Verbindung wieder einrichten.
4) Ein Benutzer möchte seine Verkehrsanforderungen aktualisieren, siehe unten.

Jedes oben aufgelistete Verkehrsereignis führt zu einer Diensteanforderung, die dem PRCH-Manager geschickt wird. Die Diensteanforderung enthält Informationen, die zur Beurteilung durch die Diensteanforderungs-Beurteilungsfunktion 408 des PRCH-Managers 402 notwendig sind. Die Informationen enthalten:

– Typ der Anforderung
– Erforderlicher geschätzter durchschnittlicher Benutzer-Datenverkehr P_ave (zur maximalen Benutzer-Bitrate des paketvermittelten Funkkanals skaliert). Dieser umfaßt separate Parameter für die Aufwärts- und die Abwärtsstrecke.
– Erforderlicher geschätzter maximaler Benutzer-Datenverkehr P_max (zur maximalen Benutzer-Bitrate des paketvermittelten Funkkanals skaliert). Dieser umfaßt separate Parameter für die Aufwärts- und die Abwärtsstrecke.
– Priorität, Pri. Dieser Parameter kann einen Wert innerhalb des Intervalls [O,Pri_max] annehmen. Die Priorität kann auf der Grundlage zugeordnet werden, dass die mobile Station den Anruf initiiert oder angerufen wird oder auf einer anderen Grundlage.

Die Diensteanforderungs-Beurteilungsfunktion 408 beurteilt eine Diensteanforderung. In der Diensteanforderungs-Beurteilung sendet der PRCH-Managers 402 eine PRCH-Zulassungsanforderung für einen Paketruf an einen der PRCH-Controller 406a, 406b, 406c oder 406d. Der PRCH-Manager 402 probiert jeden PRCH-Controller 406a, 406b, 406c oder 406d, bis eine Zulassung gewährt wurde oder der Paketruf in keinem der paketvermittelten Funkkanäle zugelassen wurde. Wenn der Paketruf in keinem der vorhandenen paketvermittelten Funkkanäle zugelassen wurde (die PRCH-Zulassungsanforderung wird von allen PRCH-Controllern 406a, 406b, 406c und 406d abgelehnt), entscheidet der PRCH-Manager 402, ob die Diensteanforderung abgelehnt werden soll oder ob der Paketruf unter Anwendung der Zugangsschlangen-Abarbeitungsfunktion 410 in die Zugangsschlange 420 gestellt werden soll.
Ein Paketruf, der in die Zugangsschlange gestellt wurde, wird temporär ausgesetzt, d. h. zwischen den Benutzern wird kein Informationsaustausch zugelassen. Wenn der Paketruf nicht in die Zugangsschlange gestellt wurde, wird dem Benutzer ein Signal 'Dienst abgelehnt' gesandt. Wenn der Paketruf in die Zugangsschlange gestellt werden soll, informiert der PRCH-Manager die Benutzer, indem ein Anzeigensignal 'Paketruf ausgesetzt' gesendet wird.
Von einem PRCH-Controller wird im PRCH-Manager 402 ein Anzeigensignal 'Paketruf abgewiesen' empfangen, wenn infolge eines Staus ein Paketruf von einem paketvermittelten Funkkanal abgewiesen wird. Ein Anzeigensignal 'Paketruf abgewiesen' wird durch die Beurteilungsfunktion 422 'Paketruf abgewiesen' beurteilt. Der PRCH-Manager 402 sendet in der Beurteilungsfunktion 422 'Paketruf abgewiesen' eine PRCH-Zugangsanforderung für das abgewiesene Paket an einen der PRCH-Controller 406a, 406b, 406c oder 406d. Der PRCH-Manager 402 probiert jeden PRCH-Controller 406a, 406b, 406c oder 406d, bis der Zugang gewährt oder aber der abgewiesene Paketruf in keinem der paketvermittelten Funkkanäle zugelassen wird.
Wenn der Paketruf bei keinem der vorhandenen paketvermittelten Funkkanäle zugelassen wird, entscheidet der PRCH-Manager 402, ob der abgewiesene Paketruf in die Zugangsschlange 420 gestellt wird, indem die Zugangsschlangen-Abarbeitungsfunktion angewendet wird. Wenn der abgewiesene Paketruf in die Zugangsschlange 420 gestellt wird, wird der Paketruf temporär ausgesetzt und über den Netzwerk-Protokollstapel 222 wird an den Benutzer ein Anzeigensignal 'Paketruf ausgesetzt' gesandt. Wenn der abgewiesene Paketruf nicht in die Zugangsschlange 420 gestellt wird, wird über den Netzwerk-Protokollstapel 222 an den Benutzer ein Anzeigensignal 'Paketruf abgetrennt' gesandt.
Ein Signal 'Paketruf-Zugangsschlange' zeigt an, dass die Zugangsschlange 420 zu überprüfen ist. Das Zugangsschlangensignal kann durch einen Zeitgeber erzeugt werden, der nach den Wünschen des Operators eingestellt wurde. von der Zugangsschlangen-Abarbeitungsfunktion 410 wird ein Paketruf-Zugangsschlangen-Signal beurteilt. In der Zugangsschlangen-Abarbeitungsfunktion 410 sendet der PRCH-Manager 402 an einen der PRCH-Controller 406a, 406b, 406c oder 406d eine PRCH-Zugangsanforderung für den Paketruf mit der höchsten Priorität in der Zugangsschlange. Der PRCH-Manager 402 sendet die Zugangsanforderung an jeden PRCH-Controller 406a, 406b, 406c oder 406d, bis der Zugang gewährt wird oder der Paketruf in keinem der paketvermittelten Funkkanäle zugelassen wird. Wird der Paketruf in einem der paketvermittelten Funkkanäle zugelassen, wird dem Benutzer über den Netzwerk-Protokollstapel 222 ein Anzeigensignal 'Paketruf wieder aufgenommen' gesandt.
Der PRCH-Manager 402 entscheidet ebenfalls, wenn es erforderlich ist, einen neuen paketvermittelten Funkkanal einzurichten oder einen vorhandenen paketvermittelten Funkkanal durch die PRCH-Verwaltungsfunktion 412 freizugeben. Falls beides erfolgt, die Einrichtung eines paketvermittelten Funkkanals und die Freigabe eines paketvermittelten Funkkanals, wird an den Ressourcenmanager 404, der die Zuordnung von System-Ressourcen für die paketvermittelten Funkkanäle steuert, ein Signal 'Aufbau-Anforderung' oder 'Freigabe-Anforderung' gesandt. Der Ressourcenmanager 404 lehnt die Anforderung entweder ab oder gewährt sie, indem er ein Signal 'Aufbau-Anforderung gewährt' oder 'Aufbau-Anforderung abgelehnt' oder ein Signal 'Freigabeanforderung gewährt' oder 'Freigabeanforderung abgelehnt' an den PRCH-Manager 402 sendet.
Jeder PRCH-Controller 406a, 406b, 406c und 406d überwacht den Verkehr auf einem paketvermittelten Funkkanal der Zelle. In einer Zelle gibt es einen PRCH-Controller für jeden paketvermittelten Funkkanal. Jeder PRCH-Controller 406a, 406b, 406c und 406d empfängt auf dem paketvermittelten Funkkanal, den er steuert, Verkehrsinformationen vom Netzwerk-Protokollstapel 222 in einem Paketbericht. Der Paketbericht wird von der PRCH-Verkehrsüberwachungs-Funktion 414a, 414b, 414c oder 414d in Bezug auf den relevanten paketvermittelten Funkkanal beurteilt. Die in dem Paketbericht enthaltene Information wird dazu verwendet, zu entscheiden, ob neue Paketrufe durch die PRCH-Zugangs-Steuerfunktion 416a, 416b, 416c oder 416 zugelassen werden können, wenn vom PRCH-Manager 402 eine Zugangsanforderung erhalten wurde. Die im Paketbericht enthaltene Information kann auch dazu verwendet werden, zu entscheiden, ob die PRCH-Staufunktion 418a, 418b, 418c oder 418d angewendet werden soll, um ein bereits zugelassenes Paket aufgrund einer Überlastung des paketvermittelten Funkkanals abzuweisen. In diesem Fall wird an den PRCH-Manager ein Signal 'Paketruf abgewiesen' gesandt. Der PRCH-Manager entscheidet dann, ob der Paketruf temporär ausgesetzt oder durch die Beurteilungsfunktion 422 'Paketruf abgewiesen' abgesetzt werden kann. In Abhängigkeit von dieser Entscheidung werden die Benutzer durch ein Anzeigensignal 'Paketruf ausgesetzt' oder ein Anzeigensignal 'Paketruf abgetrennt' informiert.
Der Ressourcenmanager 404 steuert die Zuweisung von Systemressourcen für Paketfunkkanäle. Der PRCH-Manager 402 kann fordern, dass ein neuer paketvermittelter Funkkanal eingerichtet oder freigegeben wird, indem er eine Anforderung 'PRCH einrichten/freigeben' an den Ressourcenmanager 404 sendet. Der Ressourcenmanager 404 überwacht die Länge der Zugangsschlange 420 kontinuierlich. Immer dann, wenn der gesamte angeforderte Verkehr aller Paketrufe in der Zugangsschlange P_q eine für die Zugangsschlange eingerichtete Grenze P_new PRCH überschreitet, wird eine PRCH-Aufbauanforderung an den Ressourcenmanager 404 eines höheren Pegels gesendet. Wird P_new PRCH auf Null gesetzt, fordert der PRCH-Manager immer dann mehr Ressourcen an, wenn die vorhandenen paketvermittelten Funkkanäle voll sind. Sobald die Anzahl der an einen paketvermittelten Funkkanal angelegten Benutzer Null wird, wird an den Ressourcenmanager 404 eine PRCH-Freigabeanforderung gesendet. Wird diese gewährt, wird der paketvermittelte Funkkanal freigegeben.
Der PRCH-Manager 402 und die PRCH-Controller 406a, 406b, 406c und 406d können in den Basisstationen, den Funknetz-Controllern und den mobilen Steuerknoten eines zellularen Systems, beispielsweise dem in 1 gezeigten System, realisiert werden. Die tatsächliche Implementierung kann entweder als Hardware oder als Software oder als Kombination von Hardware und Software erfolgen, die in Verbindung mit einem oder mehreren Prozessoren operieren. Die Prozessoren und die Software zur Implementierung dieser Typen von Funktionen sind auf diesem Gebiet der Technik wohlbekannt.
In den 5A, 5B, 5C und 5D sind Verkehrsflußdiagramme gezeigt, die die Diensteanforderungsbeurteilung, die 'Paketruf abgewiesen'-Beurteilung, die Zugangsschlangen-Abarbeitung bzw. die PRCH-Management-Verarbeitungsschritte darstellen, worauf gemäß einer Ausführungsform der vorliegenden Erfindung der PRCH-Manager 402 folgt.
Der PRCH-Manager 402 erhält eine Eingabe, während er sich im Wartezustand von Schritt 502 in 5A befindet. Die Eingabe kann eine Diensteanforderung, eine Anzeige 'Paketruf abgewiesen', ein intern erzeugtes Zugangsschlangensignal oder ein Signal 'PRCH-Aufbau gewährt' oder 'PRCH-Aufbau abgelehnt' oder ein Signal 'Freigabe gewährt' oder 'Freigabe abgelehnt' vom Ressourcenmanager 404 sein. Im Schritt 504 wird bestimmmt, ob vom Netzwerk-Protokollstapel 222 eine Diensteanforderung erhalten wurde. Wurde keine Diensteanforderung erhalten, geht die Verarbeitung zu Schritt 534 von 5B weiter. Wenn aber eine Diensteanforderung erhalten wurde, geht die Verarbeitung zu Schritt 506 weiter und beginnt mit der Beurteilung der Diensteanforderung.
Die Beurteilung der Diensteanforderung von Schritt 506 enthält die Anforderung des PRCH-Zugangs in den Schritten 508, 510, 512, 514, 516, 518 und 520. Die Beurteilung der Diensteanforderung wird für jeden PRCH-Controller 406a, 405b, 406c, 406d nacheinander wiederholt, bis der Zugang zu einem paketvermittelten Funkkanal gewährt wird oder bis keine paketvermittelten Funkkanäle übrigbleiben. Im Schritt 508 sendet der PRCH-Manager 402 eine PRCH-Zugangsanforderung an einen der PRCH-Controller 406a, 406b, 406c oder 406d. Danach geht die Verarbeitung zu Schritt weiter, da der PRCH-Manager 402 auf eine Antwort wartet. Der PRCH-Manager 402 überprüft im Schritt 512 periodisch, um zu festzustellen, ob von den PRCH-Controllern 406a, 405b, 406c oder 406d eine Antwort erhalten wurde. Wurde keine Antwort erhalten, geht die Verarbeitung zurück zum Wartezustand im Schritt 510. Wird jedoch im Schritt 512 festgestellt, dass von den PRCH-Controllern 406a, 405b, 406c oder 406d eine Antwort erhalten wurde, wird die Verarbeitung der PRCH-Zugangsanforderung abgeschlossen und die Verarbeitung geht zu Schritt 514 weiter, in dem festgestellt wird, ob die Antwort den Zugang gewährt. Wenn das so ist, ist die Beurteilung der Diensteanforderung im Schritt 520 abgeschlossen und die Verarbeitung geht zu Schritt 522 weiter.
Wenn jedoch im Schritt 514 festgestellt wird, dass die Antwort den Zugang nicht gewährt, handelt es sich um eine Antwort 'Zugang abgelehnt' und die Verarbeitung geht zu Schritt 516 weiter, in dem festgestellt wird, ob die gegenwärtige Antwort vom letzten PRCH-Controller gesandt wurde, an den eine Zugangsanforderung gesendet werden konnte. War dieser nicht der letzte PRCH-Controller, geht die Verarbeitung zu Schritt 518 weiter und setzt die Verarbeitung der Diensteanforderungs-Beurteilung von Schritt 506 für den nächsten paketvermittelten Funkkanal fort. Die Verarbeitung der Diensteanforderungs-Beurteilung von Schritt 506 wird fortgesetzt, bis von den PRCH-Controllern 406a, 405b, 406c oder 406d eine Antwort erhalten wurde oder bis alle PRCH-Controller den Zugang abgelehnt haben. Ist die Verarbeitung der Diensteanforderungs-Beurteilung abgeschlossen, geht die Verarbeitung zu Schritt 522 weiter.
Im Schritt 522 wird bestimmt, ob von irgendeinem PRCH-Controller eine Antwort 'Zugang gewährt' erhalten wurde. Wenn von einem PRCH-Controller der Zugang gewährt wurde, geht die Verarbeitung zu Schritt 524 weiter, in dem an den Benutzer über den Netzwerk-Protokollstapel 308 ein Signal 'Dienst gewährt' gesendet wird. Die Verarbeitung geht dann von Schritt 524 zu Schritt 534 in 5B weiter. Wenn allerdings in Schritt 522 festgestellt wurde, dass von keinem PRCH-Controller ein Zugang gewährt wurde, geht die Verarbeitung zu Schritt 528 weiter. Im Schritt 528 stellt der PRCH-Manager 402 unter Verwendung der Zugangsschlangen-Abarbeitungsfunktion 410 fest, of der Paketruf in die PRCH-Zugangsschlange gestellt werden soll. Es wird bestimmt, dass der Paketruf in die PRCH-Zugangsschlange gestellt werden soll, wenn das folgende Kriterium erfüllt ist: Pave(r) + Pq(r) < Pmax(r).
P_ave(r) ist der geschätzte durchschnittliche Datenverkehr für den Benutzer als eine Funktion der Diensteanforderung r. P_q(r) ist der angeforderte Verkehr aller Paketrufe in der Zugangsschlange der Diensteanforderung vom Typ r. Es ist ein Maß der augenblicklichen Länge der Schlange. P_max(r) ist der maximal zulässige angeforderte Verkehr in der Zugangsschlange 420 als eine Funktion der Diensteanforderung. Es ist möglich, einen anderen P_max für unterschiedliche Typen von Diensteanforderungen r zu haben. Hierdurch kann unter den verschiedenen Dienstanforderungen eine Priorität eingeräumt werden. Wenn beispielsweise ein paketvermittelter Funkkanal während einer Umschaltung angefordert wird, kann P_max(r) höher sein, als der P_max(r), wenn der Zugang zu einem paketvermittelten Funkkanal das erste Mal angefordert wird.
Wenn im Schritt 528 festgestellt wird, dass der Paketruf in die PRCH-Zugangsschlange gestellt werden soll, wird die Identität des Rufs in die Zugangsschlange 420 gestellt, und die Verarbeitung geht zu Schritt 531 weiter, in dem über den Netzwerk-Protokollstapel 222 an den Benutzer ein Signal 'Dienst gewährt' gesandt wird. Danach geht die Verarbeitung zu Schritt 532 weiter, in dem ein Anzeigesignal 'Paketruf ausgesetzt' über den Netzwerk-Protokollstapel 308 an den Benutzer gesandt wird. Die Verarbeitung geht dann zu Schritt 534 von 5B weiter. Wenn aber im Schritt 528 festgestellt wird, dass der Paketruf nicht in die PRCH-Zugangsschlange 420 gestellt werden soll, geht die Verarbeitung zu Schritt 530 weiter und ein Signal 428 'Dienst abgelehnt' wird an den Benutzer gesandt. Sodann geht die Verarbeitung zu Schritt 534 von 5B.
Im Schritt 534 von 5B wird festgestellt, ob ein Signal 'Paketruf abgewiesen' erhalten wurde. War die Eingabe keine Anzeige 'Paketruf abgewiesen', geht die Verarbeitung zu Schritt 562 von 5C. Wenn aber im Schritt 534 bestimmt wird, dass eine Anzeige 'Paketruf abgewiesen' erhalten wurde, geht die Verarbeitung zu Schritt 536. Im Schritt 536 wird eine PRCH-Zugangsanforderung für den abgewiesenen Paketruf vom PRCH-Manager 402 an den PRCH-Controller 406a, 406b, 406c oder 406d gesandt. Die Zugangsanforderungsverarbeitung von Schritt 536 umfaßt die Schritte 538, 540, 542, 544, 546, 548 und 550. Der Schritt 536 wird für jeden PRCH-Controller 406a, 406b, 406c oder 406d wiederholt, bis für alle paketvermittelten Funkkanäle der Zugang angefordert wurde. Im Schritt 538 sendet der PRCH-Manager 402 an die PRCH-Controller 406a, 406b, 406c oder 406d eine PRCH-Zugangsanforderung. Dann geht die Verarbeitung zu Schritt 540 weiter, wenn der PRCH-Manager 402 auf eine Antwort wartet. Zur Feststellung, ob vom PRCH-Controller 406 eine Antwort erhalten wurde führt der PRCH-Manager 402 im Schritt 542 eine periodische Überprüfung durch. Wurde keine Antwort erhalten, geht die Verarbeitung zurück zum Wartezustand in Schritt 540. Wird jedoch im Schritt 542 festgestellt, dass von dem PRCH-Controller eine Antwort erhalten wurde, dem die Zugangsanforderung gesendet wurde, geht die Verarbeitung zu Schritt 544 weiter, in dem festgestellt wird, ob die Antwort den Zugang gewährt. Wenn das so ist, endet die Beurteilung 'Paketruf abgewiesen' im Schritt 550 und die Verarbeitung geht zu Schritt 552 weiter. Wird jedoch im Schritt 544 festgestellt, dass die Antwort keine Zugangsgewährung ist, handelt es sich um eine Antwort 'Zugang abgelehnt', und die Verarbeitung geht zu Schritt 546 weiter, in dem bestimmt wird, ob die Antwort 'Zugang abgelehnt' vom letzten PRCH-Controller gesandt wurde, an den eine Zugangsanforderung gesandt werden konnte. Handelte es sich nicht um den letzten PRCH-Controller, geht die Verarbeitung zu Schritt 566 weiter und wiederholt die Zugangsanforderungverarbeitung von Schritt 536 für den nächsten paketvermittelten Funkkanal. Die Beurteilung 'Paketruf abgewiesen' von Schritt 536 wird wiederholt, bis von einem PRCH-Controller eine Antwort 'Zugang gewährt' erhalten wird oder bis alle PRCH-Controller 406a, 406b, 406c und 406d den Zugang abgelehnt haben. Ist die Beurteilungsverarbeitung 'Paketruf abgewiesen' von Schritt 536 abgeschlossen, geht die Verarbeitung zu Schritt 552 weiter.
Im Schritt 552 wird festgestellt, ob im Schritt 536 von irgendeinem PRCH-Controller eine Antwort 'Zugang gewährt' erhalten wurde. Wenn von einem PRCH-Controller der Zugang gewährt wurde, geht die Verarbeitung zu Schritt 554 weiter, in dem dem Benutzer über den Netzwerk-Protokollstapel 222 ein Anzeigensignal 'Paketruf-Aktualisierung' gesandt wird. Von Schritt 554 geht die Verarbeitung zu Schritt 562 von 5C. Wenn aber im Schritt 552 festgestellt wurde, dass keine Zugangsgewährung erhalten wurde, geht die Verarbeitung zu Schritt 556 weiter. Im Schritt 556 stellt der PRCH-Manager 402 unter Anwendung der Zugangsschlangen-Abarbeitungsfunktion 410 fest, ob der abgewiesene Paketruf in die PRCH-Zugangsschlange gesetzt werden soll. Es werden im Schritt 556 die gleichen Kriterien angewendet, wie die für den Schritt 528 von 5A beschriebenen. Wenn im Schritt 556 bestimmt wird, den abgewiesenen Paketruf in die Zugangsschlange 420 zu setzen, geht die Verarbeitung zu Schritt 560 und es wird über den Netzwerk-Protokollstapel 222 ein Anzeigensignal 'Paketruf ausgesetzt' an den Benutzer gesandt. Die Verarbeitung geht dann zu Schritt 560 von 5C. Wenn aber im Schritt 556 festgestellt wurde, den abgewiesenen Paketruf nicht in die Zugangsschlange 420 zu setzen, geht die Verarbeitung zu Schritt 558 weiter und ein Anzeigensignal 'Paketruf abgesetzt' wird über den Netzwerk-Protokollstapel 222 an den Benutzer gesandt. Die Verarbeitung bewegt sich dann von Schritt 558 zu Schritt 562 von 5C.
Im Schritt 562 von 5C wird bestimmt, ob ein Zugangsschlangensignal erhalten wurde. Wenn kein Zugangsschlangensignal erhalten wurde, geht die Verarbeitung zu Schritt 584 von 5D weiter. Wenn jedoch festgestellt wurde, dass ein Zugangsschlangensignal erhalten wurde, geht die Verarbeitung zu Schritt 563. Im Schritt 563 wird bestimmt, ob sich Paketrufe in der PRCH-Zugangsschlange befinden. Wenn sich keine Paketrufe in der PRCH-Zugangsschlange 420 der Zelle befinden, geht die Verarbeitung zum Wartezustand von Schritt 502 in 5A weiter. Im Schritt 502 wartet die Verarbeitung auf eine Eingabe. Wenn jedoch im Schritt 563 festgestellt wird, dass die PRCH-Zugangsschlange 420 Paketrufe enthält, geht die Verarbeitung zum Schritt 564 weiter. Im Schritt 564 wird vom PRCH-Manager 402 an den PRCH-Controller 406a, 406b, 406c oder 406d eine PRCH-Zugangsanforderung für den Paketruf mit der höchsten Priorität in der Zugangsschlange 420 gesendet.
Die Verarbeitung der Zugangsanforderung von Schritt 564 wendet die Schritte 566, 568, 570, 572, 574, 576 und 578 an. Der Schritt 564 wird für jeden PRCH-Controller 406a, 406b, 406c oder 406d wiederholt, bis der Zugang zu einem paketvermittelten Funkkanal gewährt wurde oder bis bei allen paketvermittelten Funkkanälen ein Zugang angefordert wurde. Im Schritt 566 sendet der PRCH-Manager 402 eine PRCH-Zugangsanforderung zum PRCH-Controller 406a, 406b, 406c oder 406d. Die Verarbeitung geht dann zu Schritt 568 weiter, da der PRCH-Manager 402 auf Antwort wartet. Der PRCH-Manager 402 überprüft im Schritt 570 periodisch, ob vom PRCH-Controller 406 eine Antwort erhalten wurde. Wurde keine Antwort erhalten, geht die Verarbeitung zurück zum Wartezustand in Schritt 568. Wird jedoch im Schritt 570 festgestellt, dass von dem PRCH-Controller, an den die Zugangsanforderung gesandt wurde, eine Antwort erhalten wurde, geht die Verarbeitung zu Schritt 572 weiter, in dem festgestellt wird, ob die Antwort den Zugang gewährt. Wenn das so ist, endet die Verarbeitung im Schritt 578 und die Verarbeitung geht zu Schritt 586 weiter. Wenn aber im Schritt 572 festgestellt wurde, dass die Antwort keine Zugangsgewährung ist, dann ist es eine Antwort 'Zugang abgelehnt', und die Verarbeitung geht zu Schritt 574 weiter, in dem festgestellt wird, ob die Antwort 'Zugang abgelehnt' vom letzten PRCH-Controller gesandt wurde, an den eine Zugangsanforderung gesandt werden konnte.
Wenn es sich nicht um den letzten PRCH-Controller handelt, geht die Verarbeitung zu Schritt 566 weiter und wiederholt die Zugangsanforderungsverarbeitung von Schritt 564 für den nächsten paketvermittelten Funkkanal. Die Zugangsschlangenbeurteilung von Schritt 564 wird solange wiederholt, bis von einem PRCH-Controller eine Antwort 'Zugang gewährt' erhalten wird oder bis alle PRCH-Controller 406a, 406b, 406c und 406d den Zugang abgelehnt haben. Ist die Zugangsanforderungsverarbeitung von Schritt 564 abgeschlossen, geht die Verarbeitung zu Schritt 580 weiter.
Im Schritt 580 wird festgestellt, ob von einem PRCH-Controller im Schritt 564 eine Antwort 'Zugang gewährt' erhalten wurde. Wurde eine Antwort 'Zugang gewährt' von einem PRCH-Controller erhalten, wird der Paketruf mit der höchsten Priorität in der Zugangsschlange 420 aus der Zugangsschlange entfernt und die Verarbeitung geht zu Schritt 582 weiter, wo ein Anzeigensignal 'Paketrufwiederaufnahme' über den Netzwerk-Protokollstapel 222 an den Benutzer gesandt wird.
Von Schritt 582 geht die Verarbeitung dann zu Schritt 584 von 5D. Wenn im Schritt 580 jedoch festgestellt wurde, dass kein Zugang gewährt wurde, geht die Verarbeitung direkt zu Schritt 584 von 5D.
Im Schritt 584 von 5D wird festgestellt, ob vom Ressourcenmanager 402 der Aufbau eines paketvermittelten Funkkanals gewährt wurde. Wurde vom Ressourcenmanager 402 der Aufbau eines paketvermittelten Funkkanals gewährt, geht die Verarbeitung zu Schritt 586 und der PRCH-Manager erzeugt einen neuen PRCH-Controller. Sodann geht die Verarbeitung zu Schritt 592 weiter. Wenn aber im Schritt 584 festgestellt wird, dass keine Freigabegewährung für den paketvermittelten Funkkanal erhalten wurde, geht die Verarbeitung zu Schritt 588, in dem festgestellt wird, ob vom Ressourcenmanager 402 eine Freigabegewährung für den paketvermittelten Funkkanal erhalten wurde. Wenn der Aufbau eines paketvermittelten Funkkanals gewährt wurde, geht die Verarbeitung zu Schritt 590 weiter, in dem der PRCH-Manager Ressourcen vom PRCH-Controller freigibt, für die die Freigabeanforderung gesendet wurde. Sodann geht die Verarbeitung zu Schritt 592. Wird aber im Schritt 590 festgestellt, dass keine Aufbaugenehmigung für einen paketvermittelten Funkkanal erhalten wurde, geht die Verarbeitung direkt zu Schritt 592.
Im Schritt 592 wird der angeforderte Verkehr für alle Paketrufe in der Zugangsschlange beurteilt. Als nächstes wird im Schritt 594 festgestellt, ob ein neuer paketvermittelter Funkkanal benötigt wird. Wenn der gesamte angeforderte Verkehr aller Paketrufe in der Zugangsschlange P_q eine Grenze Pnew PRCH, die für die Zugangsschlange eingestellt ist, überschreitet, ist eine neuer paketvermittelter Funkkanal erforderlich und die Verarbeitung geht zu Schritt 596. Im Schritt 596 wird an den Ressourcenmanager 404 eine Anforderung zum Aufbau eines paketvermittelte Funkkanals gesandt. Von Schritt 596 geht die Verarbeitung zurück zum Wartezustand in Schritt 502. Wird jedoch im Schritt 594 festgestellt, dass kein neuer paketvermittelter Funkkanal erforderlich ist, geht die Verarbeitung zu Schritt 597. Im Schritt 597 wird die Anzahl der Paketrufe auf jedem paketvermittelten Funkkanal beurteilt. Sodann wird im Schritt 598 bestimmt, ob ein paketvermittelter Funkkanal vorhanden ist, der keine Paketrufe überträgt. Wenn festgestellt wird, dass kein paketvermittelter Funkkanal vorhanden ist, der keine Paketrufe überträgt, kehrt die Verarbeitung zu Schritt 502 von 5A zurück. Wenn jedoch im Schritt 598 festgestellt wird, dass einer oder mehrere paketvermittelte Funkkanäle vorhanden sind, die keine Paketrufe tragen, geht die Verarbeitung zu Schritt 599, in dem eine PRCH-Freigabeanforderung an den Resourcenmanager 404 für jeden paketvermittelten Funkkanal gesandt wird, der keinen Paketruf trägt. Von Schritt 599 kehrt die Verarbeitung in den Wartezustand von Schritt 502 von 5A zurück.
In den 6, 7 und 8 sind Flußdiagramme gezeigt, die gemäß einer Ausführungsform der vorliegenden Erfindung die Verarbeitungsschritte zeigen, die nach jedem PRCH-Controller 406a, 406b, 406c oder 406d für die PRCH-Verkehrsüberwachung, die PRCH-Zugangssteuerung bzw. die PRCH-Stausteuerung folgen. Jeder der PRCH-Controller 406a, 406b, 406c und 406d überwacht kontinuierlich den Datenverkehr, die durchschnittliche Paketverzögerung und empfängt ferner auch die Zugangsanforderungen für einen paketvermittelten Funkkanal.
Nach der ursprünglichen Aktivierung nach einer Eingabe vom PRCH-Manager 402 befindet sich die Verarbeitung im Wartezustand von Schritt 602 von 6. Im Wartezustand von Schritt 602 kann jeder PRCH-Controller 406a, 406b, 406c und 406d eine Eingabe in der Form eines Paketberichts vom Netzwerk-Protokollstapel 222, eine Zugangsanforderung vom PRCH-Manager 402 oder ein intern erzeugtes Aktivierungssignal erhalten, das anzeigt, dass eine Stauüberprüfung des paketvermittelten Funkkanals durchgeführt werden muß. Nach einer Eingabe geht die Verarbeitung zu Schritt 604, in dem bestimmt wird, ob ein Paketbericht erhalten wurde. Wird bestimmt, dass kein Paketbericht erhalten wurde, geht die Verarbeitung direkt zu Schritt 708 von 7 weiter. Wenn jedoch im Schritt 604 bestimmt wird, dass ein Paketbericht erhalten wurde, geht die Verarbeitung zu Schritt 606, in dem die Funktion der PRCH-Verkehrsüberwachung 428 die Verkehrsstatistik aktualisiert, die die Paketverzögerung und Die Belastung im paketvermittelten Funkkanal für den relevanten paketvermittelten Funkkanal einschließt. Die Verkehrsstatistiken werden aktualisiert, wobei Informationen verwendet werden, die im Paketbericht enthalten sind. Jeder Paketbericht enthält die folgenden Informationen:

1) Übertragung der Mobilbenutzer-Identität für die Aufwärtsstrecke oder Übertragung der Netzwerkbenutzer-Identität für die Abwärtsstrecke
2) Paketgröße
3) Zeitstempel (der anzeigt, wann das Paket erzeugt wurde)
4) Pakettyp (Aufwärtsstrecke oder Abwärtsstrecke).

Der PRCH-Controller verwendet die im Paketbericht enthaltene Information und berechnet eine Beurteilung der durchschnittlichen Paketverzögerung T und eine Beurteilung des Datenverkehrs von jedem Paketruf Pi. Diese Werte werden für die Zugangssteuerverarbeitung (7) und die Stausteuerverarbeitung (8) verwendet. Nach der Aktualisierung der Verkehrsstatistik geht die Verarbeitung dann zu Schritt 708 von 7.
7 zeigt die Schritte, die bei der Paketfunkkanal-Zugangssteuerfunktion der Erfindung durchgeführt werden. Im Schritt 708 wird bestimmt, ob die Eingabe eine Zugangsanforderung war. Wurde keine Zugangsanforderung erhalten, geht die Verarbeitung direkt zu Schritt 818 von 8 weiter. Wenn aber im Schritt 708 bestimmt wird, dass eine Zugangsanforderung erhalten wurde, geht die Verarbeitung zu Schritt 710 weiter, wo die Zugangsanforderung beurteilt wird.
Die PRCH-Zugangssteuerfunktion 416 erlaubt die PRCH-Zugangsanforderung, wenn das folgende Kriterium erfüllt ist: Pave + Σp1 < ptol, i ∈ U(Pri)

– P_ave ist der durchschnittliche Datenverkehr, der für den neuen Paketruf erforderlich ist,
– p₁ ist der geschätzte Datenverkehr vom Paketruf i,
– U(Pri) sind die Paketrufe mit Prioritäten höher als oder gleich Pri, wobei Pri die Priorität für den angeforderten Paketruf ist,
– p_tol ist der maximal tolerierbare Datenverkehr auf dem paketvermittelten Funkkanal.

Aus der obigen Gleichung geht hervor, dass das Verkehrsaufkommen von den Paketrufen mit einer Priorität, die höher als oder gleich der Priorität des neuen Paketrufs ist, geringer sein muß als der maximal tolerierbare Datenverkehr p_tol. Daher kann es einem Paket mit einer hohen Priorität erlaubt sein, den paketvermittelten Funkkanal zu nutzen, obwohl der Gesamtverkehr (einschließlich aller Paketrufe unabhängig von der Priorität) den maximal tolerierbaren Datenverkehr p_tol übersteigt. In dem Fall wird die Stausteuerfunktion (8) Paketrufe mit einer niedrigen Priorität abweisen, so dass der Gesamtverkehr unter den maximal tolerierbaren Datenverkehr p_tol absinkt. In Übereinstimmung mit der folgenden Beziehung ist der maximal tolerierbare Datenverkehr p_tol mit der maximal tolerierbaren Verzögerung T_tol gekoppelt:
ΔP = f(Ttol – T)wobei bedeutet:
f eine Funktion, die das gleiche Vorzeichen wie ihr Argument hat. T ist die Beurteilung der durchschnittlichen Paketverzögerung, die von der PRCH-Verkehrsüberwachungsfunktion berechnet wird. Da die Verkehrsüberwachungsfunktion des PRCH-Controllers T kontinuierlich überwacht, wird P_tol kontinuierlich in Übereinstimmung mit den obigen Gleichungen aktualisiert. P_tol stimmt mit dem Verkehrspegel überein, der zu der maximal tolerierbaren Verzögerung T_tol führt.
Im Schritt 712 wird sodann bestimmt, ob der Zugang zu dem paketvermittelten Funkkanal gewährt oder abgelehnt wurde. Wurde der Zugang gewährt, geht die Verarbeitung zu Schritt 714 weiter, in dem eine Zugangsgewährung an den PRCH-Manager 402 gesendet wird. Wird der Zugang nicht gewährt, geht die Verarbeitung zu Schritt 716 weiter, in dem an den PRCH-Manager 402 eine Nachricht 'Zugang verweigert' gesendet wird. Nachdem die PRCH-Zugangssteuerfunktion 416 im Schritt 714 bzw. 716 eine Nachricht 'Zugang gewährt' oder 'Zugang verweigert' gesandt hat, geht die Verarbeitung zu Schritt 818 von 8 weiter.
Im Schritt 818 beurteilt die PRCH-Stausteuerfunktion 418 den Stau im paketvermittelten Funkkanal. Wenn festgestellt wird, dass im paketvermittelten Funkkanal kein Stau ist, kehrt die Verarbeitung in den Wartezustand von Schritt 602 in 6 zurück. Wenn aber im Schritt 820 festgestellt wurde, dass ein Stau aufgetreten ist, geht die Verarbeitung zu Schritt 822, wo beurteilt wird, welcher Paketruf/welche Paketrufe abgewiesen wird/werden. Zur Beurteilung des Staus wird die durchschnittliche Paketverzögerung T überprüft. Es wird ein vom Systemoperator eingestellter Verzögerungsalarmpegel T_con verwendet, um eine Stausituation zu erfassen, d. h., wann ein oder mehrere Paketrufe vom paketvermittelten Funkkanal abgewiesen werden müssen, um wieder eine tolerierbare durchschnittliche Paketverzögerung zu erreichen.
Wird festgestellt wird, dass T < T_con, gibt es keinen Stau im paketvermittelten Funkkanal und die Verarbeitung kehrt in den Wartezustand von Schritt 602 in 6 zurück. Wenn aber im Schritt 820 festgestellt wird, dass T ≥ T_con, ist ein Stau vorhanden und die Verarbeitung geht zu Schritt 822, wo beurteilt wird, welcher Paketruf/welche Paketrufe abgewiesen wird/werden. Die Beurteilung in Schritt 822 erfolgt auf die folgende Weise:

a) Beginnend mit Paketrufen einer niedrigen Priorität, erfolgt für alle Paketrufe die folgende Überprüfung: Pl ≤ Pmax(i)P_l ist der geschätzte Verkehr für den Paketruf i und P_max(i) ist der für den gleichen Paketruf erforderliche maximale Datenverkehr. Ist die obige Gleichung nicht ganz erfüllt, wird der Paketruf i vom paketvermittelten Funkkanal abgewiesen.
b) Ist die Gleichung für alle Paketrufe erfüllt, wird ein oder mehrere Paketrufe mit der niedrigsten Priorität abgewiesen.

Daher werden Paketrufe, die ein geschätztes Verkehrsaufkommen haben, das den Maximalwert überschreitet, der ihnen bei ihrer Diensteanforderung angegeben wird, als erstes abgewiesen. Wenn das geschätzte Verkehrsaufkommen für alle Paketrufe unter seinem Grenzwert liegt, wird ein Paketruf oder werden mehrere Paketrufe mit der niedrigsten Priorität abgewiesen.
Wenn ein Paketruf von einem paketvermittelten Funkkanal infolge eines Staus abgewiesen wird, wird dem PRCH-Manager 402 im Schritt 824 eine Anzeige 'Paketruf abgewiesen' (Wiederaufnahmeanforderung) gesandt, die anzeigt, welche Paketrufe vom paketvermittelten Funkkanal abzuweisen sind. Nach dem Senden einer Anzeige 'Paketruf abgewiesen', geht die Verarbeitung des PRCH-Controllers dann zum Wartezustand von Schritt 602 in 6 weiter.
In 9 zeigt ein Flußdiagramm die Verfahrensschritte, gefolgt von der Ressourcenmanagerfunktion des Paketfunkkanals in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. Die Ressourcenmanager-Verarbeitung befindet sich im Wartezustand von Schritt 902, nachdem eine Eingabe vom PRCH-Manager 402 erhalten wurde. Die Eingabe kann eine Aufbauanforderung oder eine PRCH-Freigabe-Anforderung sein. Nach dem Empfang einer Eingabe geht die Verarbeitung zu Schritt 904 weiter. Im Schritt 904 wird festgestellt, ob die Eingabe eine PRCH-Aufbauanforderung ist. Wenn das so ist, geht die Verarbeitung zu Schritt 906 weiter.
Im Schritt 906 wird die PRCH-Aufbauanforderung beurteilt. Der Ressourcenmanager beurteilt die PRCH-Aufbauanforderung durch eine Bestimmung, ob in der Zelle adequate Ressourcen vorhanden sind, um den Aufbau eines neuen paketvermittelten Funkkanals zu ermöglichen. Von Schritt 906 geht die Verarbeitung zu Schritt 910 weiter. Im Schritt 910 wird bestimmt, ob die Aufbaubeurteilung angibt, dass ein neuer paketvermittelter Funkkanal aufgebaut werden soll. Wenn bestimmt wird, dass ein neuer paketvermittelter Funkkanal aufgebaut werden kann, geht die Verarbeitung zu Schritt 916 weiter, in dem eine Aufbauerlaubnis an den PRCH-Manager 402 gesandt wird. Der Ressourcenmanager weist dann im Schritt 918 die Ressourcen für einen neuen paketvermittelten Funkkanal zu. Von Schritt 918 kehrt die Verarbeitung in den Wartezustand von Schritt 902 zurück. Wenn jedoch im Schritt 910 festgestellt wird, dass die Aufbaubeurteilung angibt, es soll kein neuer paketvermittelter Funkkanal aufgebaut werden, geht die Verarbeitung zu Schritt 914, wo dem PRCH-Manager 402 die Nachricht 'Aufbau abgelehnt' gesandt wird. Von Schritt 914 kehrt die Verarbeitung in den Wartezustand von Schritt 902 zurück.
Wenn festgestellt wird, dass die Eingabe keine PRCH-Aufbauanforderung im Schritt 904 ist, ist es eine PRCH-Freigabeanforderung. In diesem Falle geht die Verarbeitung von Schritt 904 zu Schritt 912. Im Schritt 912 wird die PRCH-Freigabeanforderung beurteilt. Der Ressourcenmanager beurteilt die PRCH-Freigabeanforderung durch eine Bestimmung, ob es von einem Gesamtgesichtspunkt aus für das System akzeptabel ist, den paketvermittelten Funkkanal freizugeben. So könnte hier zum Beispiel die Verkehrslast der paketvermittelten Funkkanäle in den umgebenden Zellen berücksichtigt werden. Von Schritt 912 geht die Verarbeitung zu Schritt 920. Im Schritt 920 wird festgestellt, ob die Beurteilung der PRCH-Freigabeanforderung angibt, dass ein paketvermittelter Funkkanal freigegeben werden kann. Wird das bejaht, geht die Verarbeitung zu Schritt 922 weiter, in dem dem PRCH-Manager 402 eine PRCH-Freigabeerlaubnis gesandt wird. Als nächstes gibt im Schritt 926 der Ressourcenmanager den paketvermittelten Funkkanal frei. Vom Schritt 926 kehrt die Verarbeitung in den Wartezustand im Schritt 902 zurück. Wird jedoch im Schritt 920 festgestellt, dass die Beurteilung der PRCH-Freigabeanforderung angibt, dass der paketvermittelte Funkkanal nicht freigegeben werden soll, geht die Verarbeitung zu Schritt 924, in dem an den PRCH-Manager eine Nachricht 'PRCH-Freigabe abgelehnt' gesandt wird. Von Schritt 924 kehrt die Verarbeitung in den Wartezustand im Schritt 902 zurück.
Wie aus der obigen Beschreibung ersichtlich ist, können das Verfahren und das System der vorliegenden Erfindung von einem Systemoperator verwendet werden, um für Benutzer mit Prioritäten den Paketverkehr auf einem oder mehreren paketvermittelten Funkkanälen eines zellularen Telekommunikationssystems zu verwalten. Der Systemoperator kann eine maximale durchschnittliche Zeitverzögerung für den paketvermittelten Funkkanal einstellen. Die Benutzer können in Übereinstimmung mit einem Diensteniveau, das für eine Priorität eingetragen ist oder dem eine Priorität automatisch zugewiesen ist, oder die vom dem Benutzer in Abhängigkeit vom Typ des zu führenden Gesprächs gewählt wurde, Prioritäten erhalten. Ein höheres Prioritätsniveau kann eine höhere Kostenrate für die Benutzung des Systems verursachen. Die Bezahlung der höheren Rate ermöglicht es dem Benutzer, in Stausituationen und beim Zugriffsversuch auf das System Vorrang vor anderen Benutzern mit niedrigeren Prioritäten zu erhalten. Indem er Entscheidungen über die Verwaltung des Paketverkehrs auf der Grundlage des geschätzten Datenverkehrs trifft, wie er für den Paketruf benötigt wird, und der Priorität des Paketrufs, kann der Systemoperator sicher sein, dass die PRCH-Benutzer keinen inakzeptablen Verzögerungen in den paketvermittelten Funkkanälen ausgesetzt sind.

Claims

Verfahren zum Verwalten eines Zugangs zu einer Mehrzahl von Paketfunkkanälen in einem zellularen Telekommunikationssystem, umfassend: die Mehrzahl von Paketfunkkanälen, wobei jeder Paketfunkkanal durch einen Paketfunkkanal-Controller gesteuert bzw. geregelt wird, und eine Mehrzahl von Senderempfängerstationen, wobei jede der Sende-/Empfängerstationen in der Lage ist, Datenpakete zu übermitteln und zu empfangen und einen Paketfunkkanal zu teilen, wobei das Verfahren die Schritte umfasst: Empfangen einer Anzeige, dass ein Zugang zu einem Paketfunkkanal für einen Paketruf benötigt wird; Senden einer Zugangsanfrage an einen ersten Paketfunkkanal-Controller; Empfangen einer Antwort von dem ersten Paketfunkkanal-Controller; Bestimmen, ob die Antwort anzeigt, dass der Paketruf einem Paketfunkkanal zugehen soll, der mit dem ersten Paketfunkkanal-Controller verbunden ist, und Wiederholen der Schritte (b), (c) und (d), für jeden der Mehrzahl von Paketfunkkanal-Controllern (406a, 406b, 406c, 406d), bis die Antwort anzeigt, dass der Paketruf einem der Paketfunkkanäle zugehen soll, oder bis eine negative Antwort von jedem der Mehrzahl von Paketfunkkanal-Controllern (406a, 406b, 406c, 406d) empfangen wurde.
Verfahren nach Anspruch 1, weiterhin, als Reaktion auf ein negatives Bestimmen in dem Schritt des Bestimmens, den Schritt umfassend: Bestimmen, ob der Paketruf in einer Paketfunkkanalzugangsschlange (420) platziert werden soll.
Verfahren nach Anspruch 2, wobei der Schritt des Bestimmens, ob der Paketruf in einer Paketfunkkanalzugangsschlange (420) platziert werden soll, den Schritt umfasst: Bestimmen, ob ein erforderlicher Verkehrswert für den Paketruf plus einem gesamterforderlichen Verkehrswert für einen oder mehrere Paketrufe in der Zugangsschlange (420) innerhalb eines maximal erlaubten angefragten Verkehrswerts ist, der für die Zugangsschlange (420) eingestellt ist.
Verfahren nach Anspruch 2, weiterhin, als Reaktion auf ein positives Bestimmen im Schritt des Bestimmens, ob der Paketaufruf in einer Paketfunkkanalzugangsschlange (420) platziert werden soll, den Schritt umfassend: Platzieren des Paketrufs in einer der Zugangsschlangen (420).
Verfahren nach Anspruch 1, wobei der Schritt des Empfangens ein Empfangen einer Diensteanfrage für einen Paketruf umfasst.
Verfahren nach Anspruch 5, das weiterhin, als Reaktion auf ein positives Bestimmen im Schritt des Bestimmens, den Schritt des Sendens einer Diensterteilungsnachricht für den Paketruf umfasst.
Verfahren nach Anspruch 5, wobei der Schritt des Empfangens ein Empfangen einer Diensteanforderung für einen Paketruf umfasst.
Verfahren nach Anspruch 7, das weiterhin, als Reaktion auf ein negatives Bestimmen in dem Schritt des Bestimmens, ob der Paketruf in einer Paketfunkkanalzugangsschlange (420) platziert werden soll, den Schritt des Sendens einer Diensteablehnungsnachricht für den Paketruf umfasst.
Verfahren nach Anspruch 7, weiterhin, als Reaktion auf ein positives Bestimmen in dem Schritt des Bestimmens, ob der Paketruf in einer Paketfunkkanalzugangsschlange (420) platziert werden soll, die Schritte umfassend: Platzieren des Paketrufs in der Zugangsschlange (420); Senden einer Diensterteilungsnachricht für den Paketruf, und Senden einer Paketrufaussetzungsanzeige für den Paketruf.
Verfahren nach Anspruch 1, wobei der Schritt des Empfangens den Empfang einer Paketrufverweisanzeige für einen Paketruf umfasst.
Verfahren nach Anspruch 10, dass weiterhin, als Reaktion auf ein positives Bestimmen in dem Schritt des Bestimmens, den Schritt des Sendens einer Paketruf-Aktualisierung für den Paketruf umfasst.
Verfahren nach Anspruch 3, wobei der Schritt des Empfangens den Empfang einer Paketrufverweisanzeige für einen Paketruf umfasst.
Verfahren nach Anspruch 12, das weiterhin, als Reaktion auf ein negatives Bestimmen in dem Schritt des Bestimmens, ob der Paketruf in einer Paketfunkkanalzugangsschlange (420) platziert werden soll, den Schritt des Sendens einer Paketruftrennanzeige für den Paketruf umfasst.
Verfahren nach Anspruch 12, das weiterhin, als Reaktion auf ein positives Bestimmen in dem Schritt des Bestimmens, ob der Paketruf in einer Paketfunkkanalzugangsschlange (420) platziert werden soll, den Schritt des Sendens einer Paketrufaussetzanzeige für den Paketruf umfasst.
Verfahren nach Anspruch 1, wobei das System ferner eine Zugangsschlange (420) für Paketrufe umfasst und der Schritt des Empfangens die Schritte umfasst: Empfangen eines Zugangsschlangensignals; Bestimmen, als Reaktion auf das Zugangsschlangensignal, ob die Zugangsschlange (420) einen Paketruf enthält, und Erzeugen der Anzeige als Reaktion auf ein positives Bestimmen in dem Schritt des Bestimmens.
Verfahren nach Anspruch 15, das weiterhin, als Reaktion auf ein positives Bestimmen im Schritt des Bestimmens, ob der Paketruf an den wenigstens einen Paketfunkkanal zugehen soll, den Schritt des Sendens einer Paketruffortsetzungsanzeige für den Paketruf umfasst.
Verfahren zum Verwalten von Paketfunkkanälen in einem zellularen Telekommunikationssystem, umfassend: eine Mehrzahl von Sender-/Empfängerstationen, die jeweils in der Lage sind, Datenpakete zu übermitteln und zu empfangen und einen Paketfunkkanal zu teilen, eine PRCH- Zugangsschlange (420) und einen PRCH-Ressourcenverwalter (404), wobei das Verfahren die Schritte umfasst: Bewerten des gesamten erforderlichen Verkehrs für alle Paketrufe in der Zugangsschlange (420), und Bestimmen, ob ein neuer PRCH benötigt wird, um den erforderlichen Verkehr zu behandeln; Senden einer PRCH-Setupanfrage an den Ressourcenverwalter (404), ob ein neuer PRCH erforderlich ist, um den erforderlichen Verkehr zu behandeln; Bestimmen, ob ein Paketfunkkanal ohne Paketrufe besteht, wenn ein neuer PRCH nicht erforderlich ist, um den erforderlichen Verkehr zu behandeln, und Senden einer PRCH-Freigabeanfrage an den Ressourcenverwalter (404), wenn ein Paketfunkkanal ohne Paketrufe besteht.
Verfahren nach Anspruch 17, wobei der Schritt des Bestimmens umfasst: Bestimmen, ob der gesamte angefragte Verkehr für alle Paketrufe in der Zugangsschlange (420) eine vorbestimmte Grenze überschreitet.
Eine Vorrichtung zum Verwalten eines Zugangs zu wenigstens einem Paketfunkkanal in einem zellularen Kommunikationssystem, umfassend: den wenigstens einen Paketfunkkanal und eine Mehrzahl von Sender-/Empfängerstationen, wobei jede der Sender-/Empfängerstationen in der Lage ist, Datenpakete zu übermitteln und zu empfangen und einen Paketfunkkanal zu teilen, wobei das Gerät umfasst: ein Bewertungsmittel zum Empfang einer Anzeige, dass ein Zugang für einen Paketruf für einen Paketfunkkanal benötigt wird und Erzeugen wenigstens einer Zugangsanfrage; wenigstens einen PRCH-Controller, der bzw. die jeweils einen verbundenen Paketfunkkanal steuern bzw. regeln und zum Empfang einer Zugangsanfrage vom Bewertungsmittel, Bestimmen, ob ein Paketruf dem verbundenen Paketfunkkanal zugehen soll, und Erzeugen eines Zugangserteilungssignals, wenn der Paketruf zugehen soll oder eines Zugangsablehnungssignals, wenn der Paketruf nicht zugehen soll; eine Zugangsschlange (420) zum Speichern einer Paketrufidentität für wenigstens einen Paketruf, und einen PRCH-Zugangsschlangenbehandler (410) zum Bestimmen, ob die Paketrufidentität in der Zugangsschlange (420) platziert wird, als Reaktion auf ein Zugangsablehnungssignal, das von dem mindestens einem PRCH-Controller erhalten wurde.
Vorrichtung nach Anspruch 19, wobei die Anzeige, dass ein Zugang für einen Paketruf benötigt wird, eine Paketrufidentität des Paketrufs umfasst und das Gerät ferner umfasst: eine Zugangsschlange (420) zum Speichern wenigstens einer Paketrufidentität, und einen PRCH-Zugangsschlangenbehandler (410), umfassend: Mittel zum Bestimmen, ob die Identität des Paketrufs in der Zugangsschlange (420) in Reaktion auf ein Zugangsablehnungssignal platziert werden soll, das von jedem PRCH-Controller des mindestens einen PRCH-Controllers empfangen wurde.
Vorrichtung nach Anspruch 20, wobei der PRCH-Zugangsschlangenbehandler (410) ferner umfasst: Mittel zum Bestimmen, ob die Zugangsschlange (420) wenigstens eine Paketrufidentität enthält, als Reaktion auf ein Timersignal, und Mittel zum Erzeugen einer Anzeige, dass ein Zugang für einen Paketruf benötigt wird, der einen höchsten Prioritätswert in der Zugangsschlange (420) aufweist, wenn die Zugangsschlange (420) wenigstens eine Paketrufidentität enthält, und Senden der Anzeige an das Bewertungsmittel.
Vorrichtung nach Anspruch 20, wobei das Gerät ferner umfasst: ein PRCH-Verwaltungsmittel zum Überwachen der PRCH-Zugangsschlange (420) und Erzeugen einer PRCH-Setupanfrage, wenn der gesamte angefragte Verkehr von allen Paketrufen in der Zugangsschlange (420) einen vorbestimmten Pegel überschreitet; Mittel zum Überwachen der Anzahl von Paketrufen auf dem wenigstens einen Paketfunkkanal und Erzeugen einer PRCH-Freigabeanfrage für jeden Paketfunkkanal, bei dem die Anzahl von Paketrufen Null ist, und Ressourcenverwaltungsmittel (404) zum Empfang der PRCH-Setupanfrage und zum Hinzufügen eines neuen Paketfunkkanals zu dem wenigstens einen Paketfunkkanal als Reaktion auf die Setupanfrage, und zum Empfang der PRCH-Freigabeanfrage und zur Freigabe des Paketfunkkanals, bei dem die Anzahl der Paketrufe Null ist, für den Ressourcenverwalter (404) als Reaktion auf die Freigabeanfrage.