DE60018452T2

DE60018452T2 - System und verfahren zur identifizierung von kodierungs/dekodierungs-informationen in einem mobilkommunikationsnetzwerk

Info

Publication number: DE60018452T2
Application number: DE60018452T
Authority: DE
Inventors: Jan SUUMÄKI; Hans Kallio; Juha Kalliokulju
Original assignee: Nokia Oyj; Nokia Inc
Current assignee: Nokia Oyj; Nokia Inc
Priority date: 1999-11-29
Filing date: 2000-11-27
Publication date: 2005-12-29
Anticipated expiration: 2020-11-28
Also published as: DE60018452D1; WO2001039391A2; AU1408301A; WO2001039391A3; EP1234426A2; ATE290289T1; EP1234426B1

Description

Gebiet der Erfindung
Die Erfindung bezieht sich allgemein auf ein Mobilfunksystem der zweiten und der dritten Generation und insbesondere auf die Allgemeinen Paketfunkdienste (GPRS: „General Packet Radio Services") sowie die Universellen Mobiltelekommunikationssysteme (UMTS: „Universal Mobile Telecommunications Systems").
Hintergrund der Erfindung
Gegenwärtige digitale zellulare Telefonsysteme wie etwa GSM („Global System for Mobile Communications") wurden mit einem Schwerpunkt auf Sprachkommunikationen entworfen bzw. ausgelegt. Daten werden zwischen einer Mobilstation (MS) und einem Basisstationssubsystem (BSS) über die Luftschnittstelle normalerweise unter Verwendung der so genannten „schaltungsvermittelten" Übertragungsbetriebsart übertragen, bei der ein physikalischer Kanal, d.h. eine Folge von Zeitschlitzen in regelmäßigen Abständen auf einer oder mehreren Frequenzen, für die Dauer des Rufs reserviert wird. Für Sprachkommunikationen, bei denen der zu übertragende Informationsstrom relativ kontinuierlich ist, ist die schaltungsvermittelte Übertragungsbetriebsart angemessen effizient. Während Datenrufen, z.B. Internet-Zugang, ist der Datenstrom jedoch unregelmäßig bzw. stoßartig („bursty") und die langfristige Reservierung eines physikalischen Kanals bei der schaltungsvermittelten Betriebsart stellt eine unwirtschaftliche Nutzung der Luftschnittstelle dar.
In Anbetracht dessen, dass der Bedarf für Datendienste bei digitalen zellularen Telefonsystemen rasch ansteigt, wird momentan ein neuer GSM-basierter Dienst, der als der Allgemeine Paketfunkdienst (GPRS) bekannt ist, durch das Europäische Telekommunikations-Standardisierungsinstitut (ETSI) standardisiert und ist in Empfehlung GSM 03.60 in allgemeiner Weise definiert. GPRS sieht die dynamische Zuweisung physikalischer Kanäle für eine Datenübertragung vor. Das heißt, dass ein physikalischer Kanal nur dann einer bestimmten Strecke von MS zu BSS zugewiesen ist, wenn zu übertragende Daten vorhanden sind. Die unnötige Reservierung physikalischer Kanäle, wenn keine zu übertragenden Daten vorhanden sind, wird vermieden.
GPRS ist dafür bestimmt, in Zusammenhang mit einer herkömmlichen schaltungsvermittelten GSM-Übertragung zu arbeiten, um die Luftschnittstelle sowohl für Daten- als auch für Sprachkommunikationen effizient zu nutzen. GPRS wird daher die grundlegende Kanalstruktur verwenden, die für GSM definiert ist. Bei GSM ist ein bestimmtes Frequenzband im Zeitbereich in eine Aufeinanderfolge von Rahmen aufgeteilt, die als TDMA- („Time Division Multiple Access": Zeitmultiplex) Rahmen bekannt sind. Die Länge eines TDMA-Rahmens beträgt 4,615 ms. Jeder TDMA-Rahmen ist wiederum in acht aufeinander folgende Schlitze gleicher Dauer aufgeteilt. Bei der herkömmlichen schaltungsvermittelten Übertragungsbetriebsart wird, wenn ein Ruf eingeleitet wird, ein physikalischer Kanal für diesen Ruf definiert, indem ein bestimmter Zeitschlitz (1 bis 8) in jedem einer Aufeinanderfolge von TDMA-Rahmen reserviert wird. Zum Befördern von Signalisierungsinformationen sind physikalische Kanäle in ähnlicher Weise definiert.
Mit der Einführung von GPRS wird ein „Verkehrskanal" zum Übertragen von Daten durch dynamisch zugeordnete physikalische Kanäle entweder für eine schaltungsvermittelte Übertragungsbetriebsart oder für eine paketvermittelte Übertragungsbetriebsart erzeugt. Ist der Netzwerkbedarf für eine schaltungsvermittelte Übertragungsbetriebsart hoch, kann eine große Anzahl physikalischer Kanäle für diese Betriebsart reserviert werden. Ist andererseits der Bedarf für eine GPRS-Übertragung hoch, kann eine große Anzahl physikalischer Kanäle für diese Betriebsart reserviert werden. Zusätzlich kann ein paketvermittelter Hochgeschwindigkeits-Übertragungskanal bereitgestellt werden, indem einer einzigen MS in jedem einer Aufeinanderfolge von TDMA-Rahmen zwei oder mehr Schlitze zugeordnet werden.
Die GPRS-Funkschnittstelle für GSM-Phase 2+ (GSM 03.64) kann als eine Hierarchie logischer Schichten mit spezifischen Funktionen modelliert werden, wobei die Mobilstation (MS) und das Netzwerk identische Schichten aufweisen, die über die MS/Netzwerk-Schnittstelle Um kommunizieren. Jede Schicht formatiert von der benachbarten Schicht empfangene Daten, wobei empfangene Daten von der untersten zu der höchsten Schicht verlaufen und Daten zur Übertragung von der obersten zur untersten Schicht verlaufen.
Auf der obersten Schicht in der MS befindet sich eine Anzahl von Paketdatenprotokoll- (PDP) Instanzen. Bestimmte dieser PDP-Instanzen verwenden Punkt-zu-Punkt-Protokolle (PTPs), die zum Senden von Paketdaten von einer MS zu einer anderen MS oder von einer MS zu einem festen Endgerät angepasst sind. Beispiele von PTP-Protokollen sind IP (Internet-Protokoll) und X.25, die fähig sind, eine Schnittstelle zu Benutzeranwendungen zu bilden. Es ist zu beachten, dass zwei oder mehr der PDP-Instanzen den gleichen PDP-Typ verwenden können. Ebenfalls auf der obersten Schicht befinden sich andere GPRS-Endpunktprotokollinstanzen wie etwa SMS und Signalisierung (L3M). Eine ähnliche Anordnung existiert im Netzwerk und insbesondere am Versorgungs-GPRS-Unterstützungsknoten (SGSN: „Serving GPRS Support Node).
Bestimmte der Instanzen der obersten Schicht verwenden ein gemeinsames Teilnetzwerk-abhängiges Konvergenzprotokoll (SNDCP: „Subnetwork Dependent Convergence Protocol) B GSM 04.65 B, das, wie es sein Name andeutet, die unterschiedlichen SNDCP-Benutzerdaten in eine gemeinsame Form (SNDCP-Protokolldateneinheiten) umsetzt (oder „konvergiert"), die zur weiteren Verarbeitung auf eine transparente Art und Weise geeignet ist. SNDCP-Einheiten sind bis zu 1500 Oktette groß und weisen ein Adressierungsfeld auf, das einen Netzwerkdienstzugangspunktbezeichner (NSAPI: „Network Service Access Point Identifier") enthält, der die Endpunktverbindung identifiziert bzw. kennzeichnet, d.h. den SNDCP-Benutzer. Jeder MS kann unabhängig von den anderen MSs eine Menge von NSAPIs zugeordnet werden. Diese Architektur bedeutet, dass in der Zukunft neue PDPs und Relais- bzw. Weitergabestationen entwickelt werden können, die leicht in die bestehende GPRS-Architektur eingebunden werden können.
Jede SNDCP- (oder andere GPRS-Endpunktprotokoll-) Einheit wird mittels eines Logikstreckensteuerungs- (LLC: „Logical Link Control") Rahmens über die Funkschnittstelle transportiert. Die LLC-Rahmen werden in der LLC-Schicht (GSM 04.64) gestaltet und umfassen einen Nachrichtenkopfrahmen mit Nummerierung und temporären Adressierungsfeldern, ein Informationsfeld variabler Länge und eine Rahmenprüfsequenz. Insbesondere umfassen die Adressierungsfelder einen Dienstzugangspunktbezeichner (SAPI), der zum Identifizieren bzw. Kennzeichnen eines speziellen Verbindungsendpunkts (und seiner relativen Priorität sowie Dienstgüte (QoS: „Quality of Service")) auf der Netzwerkseite und der Benutzerseite der LLC-Schnittstelle verwendet wird. Das SNDCP ist ein Verbindungsendpunkt. Andere Endpunkte umfassen den Kurznachrichtendienst (SMS) und die Verwaltungsschicht (L3M). Die LLC-Schicht formatiert von diesen unterschiedlichen Endpunktprotokollen empfangene Daten. SAPIs werden dauerhaft zugewiesen und sind für alle MSs gleich.
Die Funkstreckensteuerungs- (RLC: „Radio Link Control") Schicht definiert unter anderem die Vorgänge zum Segmentieren und Wiederaufbauen von Logikstreckensteuerungsschicht-Protokolldateneinheiten (LLC-PDUs) in RLC-Datenblöcke und zur Neuübertragung von nicht erfolgreich gelieferten RLC-Blöcken. Die Medienzugangssteuerungs- (MAC: „Medium Access Control") Schicht arbeitet oberhalb der phys. Verbindungsschicht und definiert die Vorgänge, die es mehreren MSs ermöglichen, sich ein gemeinsames Übertragungsmedium zu teilen. Die MAC-Funktion vermittelt schiedsrichterlich zwischen mehreren MSs, die versuchen, gleichzeitig zu übertragen, und stellt Kollisionsvermeidungs-, Kollisionserfassungs- und Wiederherstellungsvorgänge bereit.
Die Schicht der physikalischen Verbindung (phys. Strecke) stellt einen physikalischen Kanal zwischen der MS und dem Netzwerk bereit. Die physikalische HF-Schicht (Phys. HF) spezifiziert unter anderem die Trägerfrequenzen und GSM-Funkkanalstrukturen, die Modulation der GSM-Kanäle und Sender-/Empfänger-Eigenschaften.
Wird eine MS in einem Netzwerk aktiv, ist es notwendig, exakt zu definieren, wie Daten auf jeder der vorstehend beschriebenen Schichten zu verarbeiten sind. Dieser Prozess beinhaltet auch ein Durchführen vorläufiger Verhandlungen zwischen der MS und dem Netzwerk. Insbesondere werden Steuerparameter, die als SNDCP- Austauschidentitäts- (XID) Parameter bekannt sind, in einer XID-Parameterverhandlungsphase über die jeweiligen LLC-Schichten zwischen den beiden Partner-SNDCP-Schichten ausgetauscht. Eine Initialisierung einer XID-Verhandlung kann entweder an der MS oder am Netzwerk erfolgen. Bei Empfang eines XID-Parameters konfiguriert sich die Partnerinstanz entweder selbst gemäß diesem Parameter oder führt eine weitere Verhandlung mit der Benutzerinstanz durch. Das Feldformat für die SNDCP-XID-Parameter ist gemäß TABELLE I wie folgt gezeigt:
TABELLE I
Die Komprimierung von Protokoll- und/oder Benutzerdaten wird auf der SNDCP-Schicht optional durchgeführt (wie es in GSM-Empfehlung 04.65 beschrieben ist). Daten werden zuerst komprimiert und dann in Blöcke unterteilt, bevor der SNDCP-Nachrichtenkopf hinzugefügt und die SNDCP-Einheit aufgebaut wird.
Bei der momentanen Empfehlung GSM 04.65 können für die Komprimierung von Protokolldaten mehrere unterschiedliche Komprimierungsalgorithmen bereitgestellt sein, während zur Komprimierung von Benutzerarten nur ein einziger Komprimierungsalgorithmus speziell betrachtet wird (obwohl Vorkehrungen für zukünftige Entwicklungen getroffen sind, bei denen mehrere unterschiedliche Benutzerdaten-Komprimierungsalgorithmen zur Verfügung gestellt sind). Typischerweise wird die Entscheidung darüber, ob eine Komprimierung zu verwenden ist, von der Benutzerschnittstellenanwendung getroffen, die die Benutzerdaten erzeugt, die über einen der SNCDP-Benutzer an die SNDCP-Schicht geliefert werden. Die Entscheidung wird der SNDCP-Schicht bekannt gemacht. Eine Komprimierung kann jedoch nur verwendet werden, sofern diese an beiden Partner-SNDCP-Schichten verfügbar ist.
Während der SNDCP-XID-Parameterverhandlungen können durch den Austausch von XID-Parametern eine oder mehrere Protokoll-Komprimierungs-/Dekomprimierungsinstanzen definiert und an den beiden Partner-SNDCP-Schichten identifiziert werden. Gleichermaßen kann durch den Austausch von anderen XID-Parametern eine Benutzerdaten-Komprimierungs-/Dekomprimierungsinstanz (oder mehrere derartige Instanzen) definiert werden. GSM-Empfehlung 04.65 schlägt zu diesem Zweck die folgende XID-Nachricht vor, wie sie gemäß TABELLE II gezeigt ist:
TABELLE II
Gemäß TABELLE II identifiziert Oktett 1 einen bestimmten Algorithmus, während Oktett 2 die Anzahl von Oktetten festlegt, die in der XID-Nachricht folgen. Die folgenden Oktette definieren Parameter des gewählten Algorithmus wie etwa die Länge eines zu verwendenden Codebuchs oder die Länge des in einem Codebuch zu verwendenden Codeworts.
Wie bereits beschrieben wurde werden PDP-Kontextdaten in der SNDCP-Schicht in SNDCP-Einheiten aufgebaut bzw. zusammengestellt. Die SNDCP-Schicht fügt an jede Einheit eine PCOMP- („Protocol control information COMPression": Protokollsteuerinformationskomprimierung) Marke und eine DCOMP- („Data COMPression": Datenkomprimierung) Marke an, die einen zugeordneten Wert festlegen. Der PCOMP- und der DCOMP-Wert definieren für jedes Datenpaket ein ausgehandeltes Komprimierungsprotokoll. Insbesondere kennzeichnen sie, ob die in dieser Einheit enthaltenen Protokollsteuerinformationen und Benutzerdaten komprimiert wurden oder nicht, und wenn ja, welcher Algorithmus verwendet wurde. Bei Empfang jeder Einheit kann die empfangende SNDCP-Schicht bestimmen, ob die PDP-Kontextdaten dekomprimiert werden müssen oder nicht, und wenn ja, welche Dekomprimierungsalgorithmen verwendet werden müssen, bevor die Daten an die passende Instanz (die durch den in der empfangenen SNDCP-Einheit enthaltenen NSAPI identifiert wird) geleitet werden.
Gemäß Abschnitt 6.5.1.1.5 von 3GPP TS 04.65 V8.1.0 GPRS MS-SGSN SNDCP (2000-09) werden einem Komprimierungsalgorithmus basierend auf der Verhandlung der XID-Parameter für eine Protokollsteuerinformationskomprimierung ein oder mehrere PCOMP-Werte dynamisch zugeordnet. Jeder der zugeordneten PCOMP-Werte bezeichnet einen komprimierten Rahmentyp von diesem Komprimierungsalgorithmus.
Die Zuordnung der PCOMP-Werte folgt den folgenden allgemeinen Vorschriften:

– PCOMP soll eine Ganzzahl von 0 bis 15 sein.
– PCOMP-Wert 0 ist dauerhaft für keine Komprimierung reserviert.
– PCOMP soll unabhängig von jedem der SAPIs zugeordnet werden.
– Ein zugeordneter PCOMP-Wert gilt für alle NSAPIs, die auf den gleichen SAPI abgebildet werden.
– PCOMP-Werte sollen Komprimierungsalgorithmen, nicht Komprimierungsinstanzen zugeordnet werden (d.h. der(die) gleiche(n) PCOMP-Wert(e) soll(en) von unterschiedlichen Komprimierungsinstanzen an dem gleichen SAPI verwendet werden, der den gleichen Komprimierungsalgorithmus verwendet).
– Ein PCOMP-Wert soll sich in einem der drei Zustände befinden: nicht zugeordnet, ausgewählt oder zugeordnet.
– Ist eine neue Komprimierungsinstanz aufzustellen und wurden dem entsprechenden Komprimierungsalgorithmus noch keine PCOMP-Werte zugeordnet, soll die passende Anzahl nicht zugeordneter PCOMP-Werte ausgewählt werden. Sind nicht genügend nicht zugeordnete PCOMP-Werte übrig, soll die Komprimierungsinstanz nicht aufgestellt werden.
– Ein ausgewählter PCOMP-Wert soll in den Zustand „zugeordnet" kommen, falls die entsprechende aufgestellte Komprimierungsinstanz als Folge der XID-Verhandlung erzeugt wird, andernfalls soll er in den Zustand „nicht zugeordnet" kommen.
– Ein zugeordneter PCOMP-Wert soll in den Zustand „nicht zugeordnet" kommen, wenn der entsprechende Komprimierungsalgorithmus von keiner Komprimierungsinstanz mehr verwendet wird, oder bei Empfang des LL-RESET-Hinweisprimitivs.
– Im Fall einer Kollision (siehe Abschnitt 6.2.1.4) soll die Bearbeitung von PCOMP-Werten in Übereinstimmung mit Abschnitt 6.5.1.1.3 erfolgen.

Beim Übermitteln von Daten wird der komprimierte Rahmentyp für eine N-PDU im PCOMP-Feld des SNDCP-Nachrichtenkopfes der ersten zu der N-PDU gehörenden SNPDU transportiert. Zum Komprimieren einer N-PDU kann jeder erfolgreich ausgehandelte Algorithmus verwendet werden.
Eine Benutzerdatenkomprimierung ist wie eine Protokollsteuerinformationskomprimierung ein optionales SNDCP-Merkmal. Das Datenkomprimierungsfeldformat für eine SNDCP-XID-Verhandlung ist ähnlich dem Feldformat für eine Protokollsteuerinformationskomprimierung. Das Feldformat für die SNDCP-XID-Parameter, wie es gemäß TABELLE I und TABELLE II gezeigt ist, wird sowohl auf PCOMP als auch auf DCOMP angewandt. Die Zuordnung von DCOMP-Werten folgt den Vorschriften für die Zuordnung von PCOMP-Werten in Abschnitt 6.5.1.1.5 von 3GPP TS 04.65, wie vorstehend beschrieben.
Zur Komprimierung von Daten (sowohl von Protokoll- als auch von Benutzerdaten) in der SNDCP-Schicht geeignete Komprimierungsalgorithmen umfassen Algorithmen, die auf der Erzeugung eines Codebuchs beruhen, in dem eine Menge von Codes mittels jeweiliger Vektoren identifiziert wird. Für jedes Datensegment wird das Codebuch durchsucht, um den am besten passenden Code zu finden. Der Vektor wird dann an die Partnerinstanz übertragen, die ein identisches Codebuch enthält, das unter Verwendung des Vektors durchsucht wird, um den ursprünglichen Code wiederherzustellen. Um die Effizienz des Komprimierungsprozesses für die zu komprimierenden Daten zu optimieren, wird das Codebuch unter Verwendung der empfangenen Daten dynamisch aktualisiert. Wo der gleiche Komprimierungsalgorithmus von zwei oder mehr PDP-Instanzen verwendet, teilen sich diese Instanzen das gleiche Codebuch.
Es sollte beachtet werden, dass eine nützliche Erörterung einer Nachrichtenkopfkomprimierung in dem Artikel „Low-loss TCP/IP header compression for wireless networks" von Degermark et al. auf Seiten 375 bis 387 der Zeitschrift „Wireless Networks" (1997) zu finden ist. Degermarks Arbeit stellt Nachrichtenkopfkomprimierungsschema bereit und stellt auch hilfreiche allgemeine Hintergrundinformationen über Komprimierung bereit.
Bei einem Universellen Mobiltelekommunikationssystem (UMTS) ist Paketverkehr ähnlich zu GPRS und die Paketdaten von UMTS sind eine Entwicklung derjenigen von GPRS. Wie bei GPRS ist die Luftschnittstelle bei UMTS ein Bandbreite-begrenztes Medium. Es besteht ein Erfordernis, ein Verfahren und ein System zum Optimieren des Paketverkehrs bereitzustellen, um die Datenrate (Verwaltungsdaten bzw. Overhead) auf der Luftschnittstelle zu verringern. Außerdem ist es vorteilhaft und wünschenswert, ein Verfahren und ein System zum Optimieren des Paketverkehrs in Anbetracht der potentiellen Erfordernisse für eine zukünftige Entwicklung bereitzustellen.
Kurzfassung der Erfindung
Es ist ein primäres Ziel der Erfindung, die Nachrichtenkopf-Verwaltungsdaten auf der Luftschnittstelle eines Mobilfunknetzwerks zu reduzieren. Bei GPRS setzen momentane Optimierungsverfahren voraus, dass SNDCP ein 4 Bits langes Informationsfeld bietet, um die PCOMP-Marke zum Identifizieren des Nachrichtenkopf-Komprimierungsalgorithmustyps und des Pakettyps anzufügen. Auf die unterschiedlichen Komprimierungsverfahren, die für SNDCP-XID-Verhandlungen verfügbar sind, wird hierin als PCOMP-Werte Bezug genommen. Zum Beispiel gibt es zwei Algorithmustypen oder Komprimierungsverfahren, die momentan für eine TCP/IP- Nachrichtenkopfkomprimierung spezifiziert sind. Gemäß RFC1144 sind dem Nachrichtenkopf-Komprimierungsalgorithmus zwei PCOMP-Werte zugeordnet: PCOMP1 und PCOMP2 enthalten den PCOMP-Wert für den Rahmentyp „TCP unkomprimiert" bzw. „TCP komprimiert". Der PCOMP-Wert 0 wird für den Rahmentyp „Typ IP" verwendet. In RFC2507 wird der PCOMP-Wert 0 für reguläre IPv4- und IPv6-Pakete verwendet und die anderen fünf PCOMP-Werte sind bestimmt für die Rahmentypen „voller Nachrichtenkopf", „TCP komprimiert", „TCP-Nicht-Daten komprimiert", „Nicht-TCP komprimiert" und „Kontextzustand". Da das 4-Bit-PCOMP-Informationsfeld verwendet wird, um sieben DCOMP-Werte zu identifizieren, besteht zusätzlicher Raum für acht weitere Werte. Gleichermaßen wird ein 4 Bits langes Informationsfeld zum Anfügen einer ähnlichen DCOMP-Marke verwendet, um unterschiedliche DCOMP-Werte in Bezug auf eine Datenkomprimierung zu identifizieren, aber nur ein DCOMP-Wert (z.B. V42Bis) ist momentan zugeordnet. Dementsprechend besteht im reservierten DCOMP-Identifikationsfeld zusätzlicher Raum für vierzehn weitere Werte. Daher sind bei GPRS momentan insgesamt 8 Bit reserviert und in diesen reservierten Informationsfeldern sind zweiundzwanzig nicht verwendete Werte vorhanden. Da es möglich ist, fünfzehn kombinierte Werte zu verwenden, um die Kombinationen aller sieben PCOMP-Werte und eines DCOMP-Werts zu identifizieren, können 4 Bits in den Nachrichtenkopf-Verwaltungsdaten eingespart werden, falls das DCOMP-Identifikationsfeld und das PCOMP-Feld in ein einziges Identifikationsfeld kombiniert werden. Außerdem können weitere Bits eingespart werden, falls drei oder mehr separate Informationsfelder vorhanden sind, die in ein kombiniertes Informationsfeld einzubinden sind.
Die Erfindung kombiniert zwei oder mehr separate Informationsfelder in ein kombiniertes Informationsfeld, das hierin als das OPTimierungsinformationsfeld oder OPT-Feld bezeichnet wird, um den Komprimierungsalgorithmus und weitere für die übertragenen Daten relevanten Verarbeitungsinformationen zu kennzeichnen. Das OPT-Feld ist derart variabel, dass eine maximale Feldlänge verwendet wird, um alle möglichen Feldwerte und die Kombinationen dieser bereitzustellen, während für die typischen und üblichen Feldwerte eine minimale/normale Feldlänge verwendet wird. Damit kann der nicht verwendete Teil der separaten Informationsfelder verringert oder beseitigt werden.
Um das vorstehend erwähnte Ziel zu erreichen, ist der erste Aspekt der Erfindung ein Verfahren zum Betreiben eines Mobilfunknetzwerks in einer paketvermittelten Betriebsart, in der ein erster Index und ein zweiter Index separat verwendet werden, um Identifikationswerte in Bezug auf eine Codierung von Daten zur Übertragung festzulegen, um es einem Empfangsende zu ermöglichen, empfangene Daten gemäß den Identifikationswerten zu decodieren. Das Verfahren weist die Schritte auf:
Bereitstellen eines dritten Index, der zumindest aus dem ersten Index und dem zweiten Index hergeleitet wird; und
Bereitstellen eines Informationsfelds in den übertragenen Daten, um den dritten Index an das Empfangsende zu transportieren.
Bei diesem Verfahren werden zumindest der erste Index und der zweite Index kombiniert, um den dritten Index auf eine rekursive Art und Weise zu bilden, die zusätzlich zum ersten Index und zum zweiten Index auf eine beliebige Anzahl von Indizes anwendbar sein kann. Auch sind der erste Index und der zweite Index aus dem dritten Index herleitbar.
Insbesondere wenn die übertragenen Daten Protokolldaten und Benutzerdaten umfassen, umfasst der erste Index einen ersten Identifikationswert im Bezug auf eine Komprimierung der Protokolldaten und umfasst der zweite Index einen zweiten Identifikationswert in Bezug auf eine Komprimierung der Benutzerdaten.
Es ist möglich, dass der erste Index auf eine erste Anzahl von Werten hinweist, der zweite Index auf eine zweite Anzahl von Werten hinweist und der dritte Index auf eine dritte Anzahl von Werten hinweist, die eine Funktion der ersten Anzahl von Werten und der zweiten Anzahl von Werten ist, und wobei das Informationsfeld eine Länge aufweist, die gemäß der dritten Anzahl von Werten variabel ist.
Es ist möglich, dass der erste Identifikationswert auf einen Komprimierungsalgorithmustyp und einen Pakettyp der Protokolldaten hinweist.
Es ist möglich, dass der zweite Identifikationswert auf einen Komprimierungsalgorithmustyp und den Pakettyp der Benutzerdaten hinweist.
Es ist möglich, dass der dritte Index, wenn zum Festlegen weiterer Identifikationswerte in Bezug auf die Codierung der übertragenen Daten mindestens ein weiterer Index verwendet wird, der sich von dem ersten Index und dem zweiten Index unterscheidet, zusätzlich für den weiteren Index repräsentativ ist und das Informationsfeld zum Transportieren des weiteren Index an das Empfangsende erweiterbar ist.
Der zweite Aspekt der Erfindung ist ein System zum Betreiben eines Mobilfunknetzwerks in einer paketvermittelten Betriebsart, in der ein erster Index und ein zweiter Index separat verwendet werden, um Identifikationswerte in Bezug auf eine Codierung von Daten zur Übertragung festzulegen, um es einem Empfangsende zu ermöglichen, die Daten gemäß den Identifikationswerten zu decodieren. Das System umfasst einen Mechanismus zum Bereitstellen eines dritten Index, der für den ersten Index und den zweiten Index repräsentativ ist, sowie zum Bereitstellen eines Signals, das auf den dritten Index hinweist, und einen Mechanismus zum Bereitstellen eines Informationsfelds in den übertragenen Daten, um den dritten Index aufzunehmen.
Es ist möglich, dass der dritte Index, wenn zum Festlegen weiterer Identifikationswerte in Bezug auf die Codierung der übertragenen Daten ein vierter Index verwendet wird, der sich von dem ersten Index und dem zweiten Index unterscheidet, zusätzlich für den vierten Index repräsentativ ist und das Informationsfeld zum Transportieren des vierten Index an das Empfangsende erweiterbar ist.
Die Erfindung wird beim Lesen der Beschreibung in Zusammenhang mit 1 bis 5 ersichtlich.
Kurze Beschreibung der Zeichnungen
1 zeigt ein PDU-Format für SNDCP-Daten gemäß dem Stand der Technik.
2 zeigt ein PDU-Format für PDCP-Daten gemäß der Erfindung.
3 zeigt eine Tabelle, die die Identifikationswerte des kombinierten Informationsfelds veranschaulicht, das die Identifikationswerte des PCOMP- und des DCOMP-Felds darstellt.
4 zeigt ein Ablaufdiagramm, das ein Beispiel dafür veranschaulicht, wie die OPT-Werte definiert werden.
5 zeigt ein Blockschaltbild, das ein System zum Implementieren des OPT-Felds gemäß der Erfindung veranschaulicht.
Beste Art zum Ausführen der Erfindung
Die Nachrichtenkopfstrukturen eines PDU-Formats für SNDCP- (SNDCP = „Subnetwork Dependent Convergence Protocol": Teilnetzwerk-abhängiges Konvergenzprotokoll (GPRS)) Daten gemäß dem Stand der Technik ist gemäß 1 gezeigt. Die PDU-Parameter der SNDCP-Daten sind wie folgt definiert:
Datenkomprimierungs-Codierung (DCOMP):

0 = keine Komprimierung
1–14 = Punkte zum dynamisch ausgehandelten Daten-Komprimierungsbezeichner (siehe Abschnitt 6.6 von TS 101297 (GSM 04.65) GPRS MS-SGSN SNDCP).
15 = reserviert für zukünftige Erweiterungen.

Eine SN-PDU mit einem nicht zugewiesenen DCOMP-Wert wird von der empfangenden SNDCP-Instanz ohne Fehlermeldung ignoriert.
Protokollsteuerinformationskomprimierungs-Codierung (PCOMP):

0 = keine Komprimierung
1–14 = Punkte zum dynamisch ausgehandelten Protokollsteuerinformations-Komprimierungsbezeichner (siehe Abschnitt 6.5).
15 = reserviert für zukünftige Erweiterungen.

Eine SN-PDU mit einem nicht zugewiesenen PCOMP-Wert soll von der empfangenden SNDCP-Instanz ohne Fehlermeldung ignoriert werden.
X = freies bzw. Reservebit; F = Erstsegmenthinweisbit; T = SN-PDU-Typ; M = Zusatzbit, das zu verwenden ist, um das letzte Segment einer N-PDU zu bezeichnen.
Gemäß der Erfindung wird ein generisches bzw. allgemeines OPT-Informationsfeld eingeführt. Um einen Vorteil bezüglich der Verwaltungsdaten bzw. des Overheads im Vergleich zu GPRS zu erlangen, sollte die Länge des OPT-Felds kleiner sein als die Gesamtlänge der festen Informationsfelder von GPRS. Die tatsächliche Länge des OPT-Felds kann willkürlich definiert werden, aber eine momentane Schätzung besteht darin, dass es 4 Bits lang sein sollte, wie es gemäß 2 gezeigt ist. 2 veranschaulicht ein Beispiel der Nachrichtenkopfstrukturen eines PDU-Formats für PDCP-(„Packet Data Convergence Protocol":
Paketdatenkonvergenzprotokoll (UMTS)) Daten gemäß der Erfindung. Die PDU-Parameter der PDCP-Daten sind wie folgt definiert:
– O-Bit, OPT und OPT-Erweiterung:
Der OPT-Feldwert definiert einen verwendeten Optimierungsalgorithmus und einen Pakettyp beim PDCP. Das O-Bit gibt an, ob eine OPT-Erweiterung verwendet wird. Ein Optimierungsalgorithmus kann eine bestimmte Menge von Werten aus dem OPT-Feldwertraum reservieren, z.B. für unterschiedliche Pakettypen. Ein Empfang von PDCP führt gemäß dem OPT-Feldwert einen entgegengesetzten Arbeitsvorgang (z.B. Nachrichtenkopfdekomprimierung) durch. Es besteht kein festes Verhältnis zwischen OPT-Feldwert und verwendetem Optimierungs-/Pakettyp, sondern OPT-Feldwerte werden bei der XID-Verhandlung dynamisch definiert.
– freies bzw. Reservebit (X):
X soll auf 0 gesetzt sein. Falls ein Empfang erfolgt, wobei das freie bzw. Reservebit auf 1 gesetzt ist, soll das Feld ohne Fehlermeldung ignoriert werden.
Mit der OPT-Erweiterung reserviert jeder im OPT-Feld festgelegte Algorithmus seine eigenen Bezeichner, wie sie gemäß dem DCOMP- und dem PCOMP-Wert zugeordnet sind. Sobald die Bezeichner zugewiesen sind, werden die OPT-Werte aus diesen Bezeichnern erzeugt, wie es gemäß 4 gezeigt ist. Während des SNDCP-XID-Verhandlungsprozesses oder des LLC-XID-Verhandlungsprozesses werden statt der ursprünglichen DCOMP- und PCOMP-Werte nur die erzeugten OPT-Werte vom Absender zum Empfänger gesendet, wie es gemäß 5 gezeigt ist. Bei Empfang können die OPT-Werte in die ursprünglichen DCOMP- und PCOMP-Werte entschlüsselt werden.
Die Nachrichtenkopfstrukturen, wie sie gemäß 2 gezeigt sind, verwenden 4 Bits zum Identifizieren der OPT-Werte in dem kombinierten Informationsfeld. Falls jedoch 4 Bits nicht ausreichend sind, weil mehrere Optimierungs-/Algorithmustypen verwendet werden, ist es möglich, dieses OPT-Feld zu erweitern. Eine Schätzung besteht darin, dass das Erweiterungsfeld 8 Bits lang sein sollte, so dass die maximale Gesamtlänge 12 Bits (4096 Werte) sein sollte, wie es gemäß 2 gezeigt ist. Es sollte beachtet werden, dass eine Erweiterung nur dann verwendet wird, wenn es erforderlich ist. Da das OPT-Feld erweiterbar ist, ist es nicht notwendig, die gesamte Nachrichtenkopfstruktur zu modifizieren, um das dritte Informationsfeld für einige neue Optimierungsverfahren hinzuzufügen. Wird die Erweiterbarkeit des OPT-Felds berücksichtigt, könnte das OPT-Feld mehr Bits verwenden als die momentane GPRS-Anforderung (OPT = 12, GPRS = 8). Die durchschnittliche oder normalerweise benötigte Größe des OPT-Felds ist jedoch geringer als bei einem Ansatz vom GPRS-Typ. Es können auch Identifikationswerte dynamisch zwischen unterschiedlichen Optimierungsverfahren verteilt werden und es würde keine Situation auftreten, bei der einem Optimierungsverfahren Werte fehlen und ein anderes eine Fülle dieser aufweist.
Gemäß der Erfindung ist die Anzahl unterschiedlicher Optimierungsverfahren, die in das OPT-Feld zu kombinieren sind, nicht begrenzt. Daher würde eine Einführung eines neuen Optimierungsverfahrens kein Nach- bzw. Umarbeiten der Nachrichtenkopfstruktur bedingen. Es wird bemerkt, dass bei UMTS (in der ersten Phase) momentan nur Nachrichtenkopfkomprimierung unterstützt wird. Mit dem erweiterbaren OPT-Feld würde ein Hinzufügen von Datenkomprimierung später keine Probleme verursachen. Es sollte jedoch beachtet werden, dass eine Zuweisung jedes Bezeichners (PCOMP, DCOMP, usw.) auf eine solche Art und Weise durchgeführt werden sollte, dass die Kombination der Bezeichnerwerte nicht die maximalen OPT-Werte überschreitet (wobei die maximale Anzahl von OPT-Werten mit einem 12 Bit-OPT-Feld 4095beträgt).
Die OPT-Werte können Algorithmen und ihren Paketen auf viele unterschiedliche Weisen zugeordnet werden. Das Folgende ist ein Beispiel. Bei GPRS werden Identifikationswerte, zum Beispiel PCOMP-Werte, in einer Reihenfolge angeführt, wenn sie ausgehandelt werden. Der erste ausgehandelte Algorithmus erhält Werte 1 bis n (n = Anzahl von PCOMP-Werten, die der jeweilige Nachrichtenkopf-Komprimierungsalgorithmus benötigt, zum Beispiel einen für jeden Pakettyp). Der nächste Algorithmus erhält Werte n+1 bis m, und so weiter. Dieses Verfahren ist jedoch nicht für das OPT-Feld anwendbar, weil bei Verwendung von mehr als einem Optimierungsverfahren Kombinationen von Algorithmustypen berücksichtigt werden müssen, die bei unterschiedlichen Optimierungsverfahren verwendet werden. Mit anderen Worten können der Nachrichtenkopf und die Daten für ein bestimmtes Paket mit bestimmten Algorithmen gleichzeitig komprimiert werden (wobei nur ein Algorithmustyp pro Optimierungsverfahren für das gleiche Paket verwendet werden kann).
Die Erweiterung des OPT-Felds sollte nur bei Bedarf verwendet werden. Ist das grundlegende OPT-Feld zum Beispiel 4 Bits lang, können nur 15 Werte verwendet werden (Wert 0 ist für keine Optimierung reserviert). Im Fall, dass mehr als 15 Werte verwendet werden (zum Beispiel Werte 1 bis 30), sollte eine Optimierungserweiterung verwendet werden, um die Länge des OPT-Felds auf 5 Bits zu erhöhen. Es ist jedoch nicht vorteilhaft, die Erweiterung für jedes Paket zu verwenden, sondern zum Beispiel nur für diejenigen Pakete, die einen Identifikationswert größer als 15 tragen. In dieser Hinsicht ist keine Erweiterung notwendig, falls nur Werte 1 bis 15 ausgehandelt sind. Eine Erweiterung wird jedoch verwendet, wenn auch zusätzliche Werte 16 bis 30 ausgehandelt sind. Daher ist es vorteilhaft, dass die am häufigsten verwendeten Werte (z.B. Algorithmustypen) die kleinsten Identifikationswerte für sich zugeordnet haben sollten, damit die Verwendung einer OPT-Feld-Erweiterung minimiert wird.
Es gibt viele Arten, die OPT-Werte für das OPT-Feld zuzuordnen, das zwei oder mehr unterschiedliche Informationsfelder kombiniert. Das Folgende ist ein Beispiel, wie es gemacht werden kann:

– Zuerst werden Identifikationswerte für jedes Optimierungsverfahren auf die gleiche Art und Weise wie bei GPRS zugeordnet (z.B. PCOMP, DCOMP).
– Dann werden aus diesen Optimierungs-spezifischen Identifikationswerten mittels „rekursiver" Schleifen OPT-Werte definiert, wobei jede Schleife ein Optimierungsverfahren darstellt.

Das folgende Beispiel veranschaulicht die Zuordnung von OPT-Werten mit der Kombination von zwei Optimierungsverfahren (DCOMP und PCOMP). Diese rekursiven Schleifen bilden eine Tabelle, die die OPT-Werte für „Codierung" und „Decodierung" auflistet, wie es gemäß 3 gezeigt ist. Die gemäß 3 gezeigte Tabelle kann unter Verwendung der rekursiven Schleife erzeugt werden, wie es bei dem nachstehenden Beispielcode veranschaulicht ist. Gemäß 3 sind die PCOMP-Werte in der letzten Spalte die Werte von PCOMP_Arr[OPT] und die DCOMP-Werte in der zweiten Spalte sind die Werte von DCOMP_Arr[OPT]. Die zugeordneten OPT-Werte in der ersten Spalte sind die Werte von OPT_Arr[PCOMP][DCOMP].
Beispielcode:
Eine allgemeinere rekursive Schleife ist gemäß 4 dargestellt, wobei N Optimierungsverfahren kombiniert werden. Bei dem vorstehend gezeigten Beispielcode gilt N = 2.
Beim Senden eines Pakets an das Empfangsende wird die OPT_Arr-Tabelle verwendet, um den „codierten" OPT-Wert des Pakets zu identifizieren. Beim Empfangen des Pakets werden DCOMP_Arr und PCOMP_Arr verwendet, um die tatsächlichen PCOMP- und DCOMP-Werte der „Decodierung" zu identifizieren. Bei diesem Beispiel werden das PCOMP-Informationsfeld und das DCOMP-Informationsfeld als Indizes verwendet, die bei dem gemäß 4 gezeigtem Ablaufdiagram Param1 und Param2 entsprechen. Die Anzahl von Werten im PCOMP-Informationsfeld und die Anzahl von Werten im DCOMP-Feld sind entsprechend den Parametern MaxWertVonParam1 und MaxWertVonParam2 gemäß 4. MaxWertVonParam1 und MaxWertVonParam2 bestimmen die Dimensionen der OPT_Arr-Tabelle. Bei dieser speziellen rekursiven Schleife wurden PCOMP Werte von 0 bis 3 zugeordnet (PCOMP_Max = 3) und wurden DCOMP Werte von 0 bis 2 zugeordnet (DCOMP_Max = 2). Die OPT-Werte sind Indizes für die gemäß 2 und 3 gezeigten Tabellen.
4 zeigt ein Ablaufdiagram, das ein Verfahren zum Erzeugen von OPT-Werten unter Verwendung einer rekursiven Schleife veranschaulicht, um N separate Informationsfelder in ein OPT-Feld zu kombinieren. Wie gezeigt wird die Zuordnung der OPT-Indizes als rekursive Schleife 10 durchgeführt. Wenn die Schleife begonnen wird, wird die Variable KeinParam in Schritt 12 auf N gesetzt, wobei N die Anzahl unterschiedlicher Parameter in unterschiedlichen Informationsfeldern ist, wie etwa NSAPI, PCOMP und DCOMP, die in das OPT-Feld zu kombinieren sind. Die rekursive Schleife 10 wird in Schritt 14 initialisiert, wobei alle Variablen (Parameter) einschließlich OPT, Param1, Param2,..., ParamN alle auf 0 gesetzt werden. In Schritt 16 wird eine Tabelle zur Codierung und Decodierung von OPT-Parametern eingerichtet, die ähnlich zu der gemäß 1 gezeigten ist. Die Inhalte der Tabelle werden in jeder Schleife mit einem OPT-Parameter aufgefüllt. In Schritt 18 wird der Wert von Param1 gegenüber MaxWertVonParam1 überprüft. Es sollte beachtet werden, dass die Schleife unter der Annahme ausgelegt ist, dass jedes Informationsfeld X eine Anzahl von Parametern aufweist, die sich von 0 bis zu einem beliebigen positiven Ganzzahlenwert erstreckt, der als MaxWertVonParamX definiert ist. Wie gemäß 3 gezeigt weist das DCOMP-Informationsfeld zum Beispiel 3 Parameter auf (0, 1 und 2) und die entsprechende Variable MaxWertVonParamX ist daher 3. Gleichermaßen ist die Variable MaxWertVonParamX für das PCOMP-Informationsfeld 4 (0, 1, 2 und 3). Ist Param1 kleiner als MaxWertVonParam1, wird Param1 in Schritt 20 um 1 erhöht, so dass in Schritt 22 ein neuer OPT-Wert zugeordnet werden kann. Hat Param1 seinen Maximalwert erreicht, wird der Wert von Param1 in Schritt 24 gegenüber MaxWertVonParam2 überprüft. Ist Param2 kleiner als MaxWertVonParam2, wird Param2 in Schritt 26 um 1 erhöht, so dass in Schritt 22 ein neuer OPT-Wert zugeordnet werden kann. Hat Param2 seinen Maximalwert erreicht, wird der Wert von Param3 gegenüber MaxWertVonParam3 überprüft (was nicht gezeigt ist), und so weiter. Hat Param(N-1) seinen Maximalwert erreicht, wird der Wert von ParamN in Schritt 38 gegenüber MaxWertVonParamN überprüft. Ist ParamN kleiner als MaxWertVonParamN, wird ParamN in Schritt 40 um 1 erhöht, so dass in Schritt 22 ein neuer OPT-Wert zugeordnet werden kann. Andernfalls wird die Schleife in Schritt 50 beendet.
Gemäß 3 gibt es zwei unterschiedliche Indizes, die das DCOMP- und das PCOMP-Informationsfeld darstellen. Jeder Index weist eine Anzahl von Werten auf. Der DCOMP- Index weist 3 Werte auf und der PCOMP-Index weist 4 Werte auf. Daher ist die optimale Länge des OPT-Felds, wie es gemäß 3 dargestellt ist, gleich 12 (3 mal 4), was ausreichend ist, um den maximalen OPT-Wert von 0 bis 11 zu tragen. Sind im Allgemeinen N unterschiedliche Informationsfelder vorhanden, kann die Anzahl von Werten von Index1 durch #_Werte_von_Index1 bezeichnet werden, kann die Anzahl von Werten von Index1 durch #_Werte_von_Index1 bezeichnet werden,..., und wird die Anzahl von Werten von IndexN durch #_Werte_von_IndexN bezeichnet. Dementsprechend erstrecken sich die OPT-Werte von 0 bis X. Die Anzahl von Bits, die für ein OPT-Feld ausreichend sind, um X OPT-Werte zu tragen, ist gegeben durch M, wobei 2^M = X gilt. Gilt zum Beispiel N=3, #_Werte_von_Index1 =5, #_Werte_von_Index2 =9 und #_Werte_von_Index3 =11, gilt X=5×9×11=495. Dies bedeutet, dass sich die OPT-Werte von 0 bis 495 erstrecken. In diesem Fall sollte die Länge des OPT-Felds 9 Bits betragen, oder M=9, wobei gilt 2⁹ = 512. Werden separate Felder verwendet, um die Codierungsinformationen zu kennzeichnen, wären 11 Bits notwendig.
5 zeigt eine schematische Darstellung eines Systems 100 zum Implementieren des OPT-Felds bei einem typischen LLC-XID-Verhandlungsvorgang. Das gleiche System kann jedoch für einen XID-Verhandlungsprozess des Teilnetzwerk-abhängigen Konvergenzprotokolls (SNDCP) verwendet werden. Wie gemäß 5 gezeigt umfasst das SNDCP 120 auf der Absenderseite 110 einen Mechanismus 130, der zum Kombinieren separater Informationsfelder wie etwa des PCOMP-Felds 132 und des DCOMP-Felds 134 in ein OPT-Feld 136 fähig ist. Auf der Empfängerseite 140 umfasst das SNDCP 150 einen Mechanismus 160, der fähig ist, das kombinierte OPT-Feld 162, wie es von der Empfängerseite 140 während einer XID-Verhandlung erhalten wird, in separate Informationsfelder wie etwa das PCOMP- Feld 164 und das DCOMP-Feld 166 zu trennen. Der XID-Austauschvorgang ist im Stand der Technik wohl bekannt.
Obwohl die Erfindung im Hinblick auf ein bevorzugtes Ausführungsbeispiel dieser beschrieben wurde, wird es für einen Fachmann selbstverständlich sein, dass die vorstehenden und verschiedene andere Änderungen, Weglassungen und Abweichungen bei der Ausgestaltung und den Einzelheiten dieser gemacht werden können, ohne vom Umfang dieser Erfindung abzuweichen.

Claims

Verfahren zum Betreiben eines Mobilfunknetzwerks in einer paketvermittelten Betriebsart, in der ein erster Index (132) und ein zweiter Index (134) separat verwendet werden, um Identifikationswerte in Bezug auf eine Codierung von Daten zur Übertragung festzulegen, um es einem Empfangsende zu ermöglichen, empfangene Daten gemäß den Identifikationswerten zu decodieren, und das Verfahren ist gekennzeichnet durch die Schritte: Bereitstellen eines dritten Index (136), der zumindest aus dem ersten Index (132) und dem zweiten Index hergeleitet wird; und Bereitstellen eines Informationsfelds in den übertragenen Daten, um den dritten Index (136) an das Empfangsende zu transportieren, wobei zumindest der erste Index (132) und der zweite Index (134) kombiniert werden, um den dritten Index (136) auf eine rekursive Art und Weise zu bilden, und wobei der erste Index (132) und der zweite Index (134) aus dem dritten Index (136) herleitbar sind.
Verfahren gemäß Anspruch 1, bei dem die übertragenen Daten Protokolldaten und Teilnehmerdaten enthalten, der erste Index (132) einen ersten Identifikationswert in Bezug auf eine Komprimierung der Protokolldaten enthält und der zweite Index (134) einen zweiten Identifikationswert in Bezug auf eine Komprimierung der Teilnehmerdaten enthält.
Verfahren gemäß Anspruch 1, bei dem der erste Index (132) auf eine erste Anzahl von Werten hinweist, der zweite Index (134) auf eine zweite Anzahl von Werten hinweist und der dritte Index (136) auf eine dritte Anzahl von Werten hinweist, die eine Funktion der ersten Anzahl von Werten und der zweiten Anzahl von Werten ist, und bei dem das Informationsfeld eine Länge aufweist, die gemäß der dritten Anzahl von Werten variabel ist.
Verfahren gemäß Anspruch 2, bei dem der erste Identifikationswert auf einen Komprimierungsalgorithmustyp und einen Pakettyp der Protokolldaten hinweist.
Verfahren gemäß Anspruch 2, bei dem der erste Identifikationswert auf einen Pakettyp der Protokolldaten hinweist.
Verfahren gemäß Anspruch 2, bei dem der erste Identifikationswert auf einen Komprimierungsalgorithmustyp der Protokolldaten hinweist.
Verfahren gemäß Anspruch 2, bei dem der zweite Identifikationswert auf einen Komprimierungsalgorithmustyp und einen Pakettyp der Teilnehmerdaten hinweist.
Verfahren gemäß Anspruch 2, bei dem der zweite Identifikationswert auf einen Komprimierungsalgorithmustyp der Teilnehmerdaten hinweist.
Verfahren gemäß Anspruch 2, bei dem der zweite Identifikationswert auf einen Pakettyp der Teilnehmerdaten hinweist.
Verfahren gemäß Anspruch 1, bei dem zum Festlegen weiterer Identifikationswerte in Bezug auf die Codierung der übertragenen Daten mindestens ein weiterer Index verwendet wird, der sich von dem ersten Index (132) und dem zweiten Index (134) unterscheidet, und bei dem der dritte Index (136) zusätzlich für den weiteren Index repräsentativ ist und das Informationsfeld zum Transportieren des weiteren Index an das Empfangsende erweiterbar ist.
Verfahren gemäß Anspruch 1, bei dem der erste Index (132) in einem Feld mit einer ersten Länge bereitgestellt wird, der zweite Index (134) in einem weiteren Feld mit einer zweiten Länge bereitgestellt wird und das Informationsfeld zum Transportieren des dritten Index (136) eine dritte Länge aufweist, wobei die dritte Länge kleiner ist als eine Summe der ersten Länge und der zweiten Länge.
Verfahren gemäß Anspruch 11, bei dem die dritte Länge willkürlich bestimmt wird.
Verfahren gemäß Anspruch 11, bei dem die dritte Länge erweiterbar ist.
Verfahren gemäß Anspruch 3, bei dem der erste Index (132) in einem Feld mit einer ersten Länge bereitgestellt wird, der zweite Index (134) in einem weiteren Feld mit einer zweiten Länge bereitgestellt wird und das Informationsfeld zum Transportieren des dritten Index (136) eine dritte Länge aufweist, wobei die dritte Länge kleiner ist als eine Summe der ersten Länge und der zweiten Länge.
Verfahren gemäß Anspruch 14, bei dem die erste Anzahl von Werten veränderbar ist, die zweite Anzahl von Werten veränderbar ist und die dritte Länge gemäß der ersten Anzahl von Werten und der zweiten Anzahl von Werten veränderbar ist.
Verfahren gemäß Anspruch 15, bei dem die dritte Länge 4 Bits lang ist.
Verfahren gemäß Anspruch 3, bei dem die Länge des Informationsfelds 4 Bits lang ist.
System zum Betreiben eines Kommunikationsnetzwerks in einer paketvermittelten Betriebsart, in der ein erster Index (132) und ein zweiter Index (134) separat verwendet werden, um Identifikationswerte in Bezug auf eine Codierung von Daten zur Übertragung durch ein Absenderende festzulegen, um es einem Empfangsende zu ermöglichen, die Daten gemäß den Identifikationswerten zu decodieren, und das System ist gekennzeichnet durch: eine Einrichtung im Absenderende, die auf den ersten Index (132) und den zweiten Index anspricht, zum Bereitstellen eines dritten Index (136), der zumindest aus dem ersten Index (132) und dem zweiten Index (134) hergeleitet wird, und zum Bereitstellen eines auf den dritten Index hinweisenden Signals, und eine Einrichtung im Absenderende, die auf das Signal anspricht, zum Bereitstellen eines Informationsfelds in den übertragenen Daten, um den dritten Index aufzunehmen, wobei zumindest der erste Index (132) und der zweite Index (134) kombiniert werden, um den dritten Index (136) auf eine rekursive Art und Weise zu bilden, die zusätzlich zum ersten Index (132) und zum zweiten Index auf eine beliebige Anzahl von Indizes anwendbar ist, und wobei der erste Index (132) und der zweite Index (134) aus dem dritten Index (136) herleitbar sind.
System gemäß Anspruch 18, zusätzlich mit: einer Einrichtung im Empfangsende, die auf das Informationsfeld in den übertragenen Daten anspricht, zum Bereitstellen eines weiteren Signals, das für den dritten Index repräsentativ ist; und einer Einrichtung im Empfangsende, die auf das weitere Signal anspricht, zum Aufteilen des dritten Index (136) in den ersten Index (132) und den zweiten Index (134).
System gemäß Anspruch 18, bei dem zum Festlegen weiterer Identifikationswerte in Bezug auf die Codierung der übertragenen Daten ein vierter Index verwendet wird, der sich von dem ersten Index (132) und dem zweiten Index (134) unterscheidet, der dritte Index (136) zusätzlich für den vierten Index repräsentativ ist und das Informationsfeld zum Transportieren des vierten Index an das Empfangsende erweiterbar ist.
System gemäß Anspruch 18, bei dem der erste Index (132) in einem Feld mit einer ersten Länge bereitgestellt ist und der zweite Index (134) in einem weiteren Feld mit einer zweiten Länge bereitgestellt ist, wobei das Informationsfeld zum Aufnehmen der dritten Länge kleiner ist als eine Summe der ersten Länge und der zweiten Länge.
System gemäß Anspruch 21, bei dem die dritten Länge willkürlich definiert ist.
System gemäß Anspruch 22, bei dem die dritte Länge erweiterbar ist.
System gemäß Anspruch 18, bei dem das Kommunikationsnetzwerk ein Mobilfunknetzwerk aufweist.
Verfahren gemäß Anspruch 1, bei dem die Kombinationsmethode zum Bilden des dritten Index (136) zusätzlich zum ersten Index (132) und zum zweiten Index (134) auf eine beliebige Anzahl von Indizes anwendbar ist.
System gemäß Anspruch 18, bei dem die Kombinationsmethode zum Bilden des dritten Index (136) zusätzlich zum ersten Index (132) und zum zweiten Index (134) auf eine beliebige Anzahl von Indizes anwendbar ist.