UMTSlink.at - Home  

Zurück   UMTSlink.at > UMTS / HSPA > HSPA
Registrieren Hilfe Benutzerliste Kalender Suchen Heutige Beiträge Alle Foren als gelesen markieren

» November 2009
Mo Di Mi Do Fr Sa So
262728293031 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 123456
» HSUPA Basics

HSUPA Grundlagen

Ein kleines HSUPA-Tutorial

von: Rudolf Riemer

 


Stand: Oktober 2009

Einleitung

Mit der Einführung von HSDPA (High Speed Downlink Packet Access) haben sich Mobilfunknetze als ernsthafte Alternative zu festverdrahteten Internetanbindungen etabliert. Wie in Abb.1 zu sehen ist, ist die Nachfrage bezüglich mobiler Datenanbindungen im Lauf der letzten Jahre weltweit exponentiell angestiegen - der Anstieg der klassischen Telefondiensten hingegen nur linear. Bereits zu Beginn der Einführung von HSDPA standen 3,6Mb/s Maximaldatenrate zur Verfügung und die Dienstgüte war deutlich besser als jene von herkömmlichen UMTS-Datendiensten (Rel.99). Wermutstropfen von HSDPA ist, dass die Dienstverbesserung nur im Downlink verfügbar ist; im Uplink blieb alles beim alten, nämlich eher geringe Datengeschwindigkeit (sehr oft limitiert auf 64kb/s) und ziemlich hohe Latenzzeiten, wodurch bei Uplink-Diensten die Reaktionszeiten sehr träge ist und moderne Dienste wie VoIP-Telefonie oder dynamische Online-Spiele nicht adäquat durchführbar sind.
Um dieses Manko im Uplink zu schließen, wurde die Funknetzwerkaufrüstung HSUPA (High Speed Uplink Packet Access) entwickelt, mit der analog zu HSDPA die Datengeschwindigkeiten stark angehoben und auch die Dienstgüte (Latenzzeiten) verbessert werden können. Im Jahr 2007 starteten die ersten UMTS-Netzbetreiber mit HSUPA und es wurden bereits zu Beginn Maximaldatenraten von bis zu 1,46Mb/s angeboten - also ein ziemlicher Unterschied zu den davor angebotenen 64kb/s. In der Endausbaustufe von HSUPA sind theoretisch sogar bis zu 5,76Mb/s möglich (siehe: Geräteklassen).

Abb.1: Entwicklung der Teilnehmerzahl von Mobilfunkdiensten

 

HSPA - High Speed Packet Access:
Da mit der Einführung von HSUPA nun in beiden Übertragungsrichtungen effektive und qualitativ hochwertige  PS-Dienste durchführen lassen, verwendet man für diese bidirektionale Übertragungsevolution auch den Sprachterminus HSPA.

Obwohl mit der Einführung von HSUPA durch die Release 6 bereits VoIP-Telefondienste qualitativ ansprechend durchführbar wären, sind diese Dienste erst mit der Einführung der Release 7 angedacht, da hier weitere technische Verbesserungen und Ergänzungen in die Netzwerkarchitektur integriert werden, die VoIP-Dienste effizienter durchführen lassen. Release 7 unterstützt z.B. CPC (Continous Packet Connectivity), wodurch Verbindungen von PS-Diensten mehrerer Teilnehmer auch über längere Zeitspannen aufrecht erhalten werden können, ohne dass dadurch die Störinterferenzpegel unnötig hoch sind. In Release 7 ist auch der Upgrade HSPA+ oder eHSPA, mit dem in beide Übertragungsrichtungen die Maximaldatenraten weiter ansteigen.

»  nach oben

HSUPA - Release 6: Koexistenz zu Release 99

HSUPA ist eine technologische Erweiterung für UMTS-Funknetze, die in der 3GPP Release 6 Berücksichtigung findet (HSDPA in der Release 5). Ebenso wie bei HSDPA können UTRAN-Funkzellen optional mit HSUPA-Technik aufgerüstet werden - müssen es aber nicht. Im UTRAN müssen nicht alle Zellen mit HSUPA aufgerüstet werden, sondern ein Netzbetreiber kann sich z.B. dafür entscheiden, dass er nur die Zellen in Ballungsgebieten mit HSUPA aufrüstet. Die wichtigsten Änderungen bezüglich der Netzwerkarchitektur betreffen praktisch ausschließlich die NodeB (MAC-e), um auch im Uplink eine Dezentralisierung von Steuerlogik, die in der Release praktisch ausschließlich im RNC stattfindet, zu erreichen. Der RNC muss um die Funktionalität des MAC-es Protokolls erweitert werden, das für die Kompatibilität von HSUPA-Diensten mit der Standard-Protokollschicht MAC-d verantwortlich ist (siehe Abb.2) aber auch für das Combining im Softhandover (nicht bei Softer-Handover -> da führt die NodeB das Combining durch) zuständig ist. Wie bei HSDPA bereits ausführlich erklärt wurde, steht durch eine Auslagerung von Steuerlogik aus dem RNC in die peripheren NodeBs mehr Rechenleistung pro Dienst zur Verfügung. Dank diesem "Mehr" an Rechenleistung, können auch bei HSUPA die zu übertragenden Paketrahmen kürzer gemacht werden, wodurch die Regelkreise für Rückbestätigungen dynamischer werden und der Datenfluss letztendlich kontinuierlicher wird. Wie in Abbildung 2 zu sehen ist ist für die technologische Umsetzung von HSUPA in der NodeB die Protokollschicht MAC-e verantwortlich, in der unteranderem die HARQ-Regelkreise und das Scheduling der Übertragungsressourcen durchgeführt wird. Im Gegensatz zu HSDPA wird bei HSUPA auch wieder Softhandover unterstützt - wie in der Release 99.

 

HSUPA-Protokollstack

Abb.2: Protokollstack von HSUPA

 

»  nach oben

Fast Scheduling - Kanalzuweisung

Systembedingt ist die technologische Umsetzung von HSUPA etwas komplexer als bei HSDPA. Bei HSDPA gibt es im Downlink nämlich nur eine Sendequelle - die Basisstation -, die somit ganz alleine und ohne Konkurrenz mit anderen Sendequellen die Vergabe und Charakteristik der Nutzdatenfunkkanäle für die einzelnen Endanwender steuern kann. Im Gegensatz zu HSDPA liegen bei HSUPA jedoch Mehrpunkt-zu-Punkt-Verbindungen (siehe Abb.3) vor, weshalb bei HSUPA auch keine "Shared"-Kanäle, sondern "Dedicated"-Kanäle verwendet werden. Es gibt also mehrere „voneinander unabhängige“ Sender - die Handys bzw. Datenkarten -, die auf den gleichen Übertragungskanal (E-DCH-Kanal) zugreifen wollen. Jedes HSUPA-Sendegerät verwendet wie in der Release 99 einen eigenen individuellen Scramblingcode, um sich vor Störeinflüssen anderer UEs zu schützen. Da die Scramblingcodes durch Asynchronizitäten (die UEs in einer Zelle sind zueinander nicht synchron!) nicht zu 100% orthogonal zueinander sind, ist die Übertragung im Uplink problematischer als im Downlink, wo es ja nur eine Sendequelle, die NodeB, gibt und die verschiedenen Teilnehmrersignale sehr wohl orthogonal zueinander sind (siehe WCDMA). Stellen bei HSDPA die verfügbaren Funkressourcen für die Endanwender die Spreizcodes des Codebaums dar, so hängen die verfügbaren Funkressourcen bei HSUPA von den Interferenzleistungen bei der NodeB als Empfänger ab, die durch die verschiedenen sendenden UEs verursacht werden. Aus diesem Grund bedarf es einer ausgeklügelten Steuerung, damit es nicht zu Kollisionen der verschiedenen Teilnehmerdaten kommt aber auch die Funkressourcen effizient verwendet werden.

 

HSUPA-Situation: Mehrpunzentrale Steuerung ist notwendig, um Kollisionen zu verhindenrkt-zu-Punkt-Verbindung -->

Abb.3: HSUPA-Problematik: Mehrpunkt-zu-Punkt-Verbindung macht zentrale Steuerung notwendig

 

Diese erwähnte Kommunikationssteuerung kann nicht vom UE als Sendequelle durchgeführt werden, da es in der Funkzelle noch andere UEs geben könnten, die ebenfalls per HSUPA Daten im Uplink versenden möchten. Wie in Abb.3 zu erkennen ist, gibt es in der Funkzelle nur einen Kommunikationspartner der für die Funkzelle zentral die Steuerung übernehmen kann, nämlich die NodeB (als Funkturm dargestellt), da sie das einzige Element ist, das zu allen aktiv senden wollenden UEs eine Verbindung hat. In der Abb.3 hat z.B. TN-A keine unmittelbare Verbindung zu TN-E - hingegen hat sowohl TN-A als auch TN-E eine Verbindung zur NodeB.

Auch bei HSUPA teilt also die NodeB die Übertragungsressourcen den UEs zu. Für optimale Kanalzuweisungen (Scheduling) werden laufende Kanalgütemessungen mitberücksichtigt. Das heißt die NodeB führt Messungen als Funkempfänger durch und bekommt auch relevante Berichte (Scheduling Report) von den UEs zwecks optimaler Kanalbewertung zugeschickt, in denen z.B. der NodeB mitgeteilt wird, wieviele und welche Art von Datenvolumina im Sendepuffer des HSUPA-UEs auf deren Übertragung warten.

Funktionsprinzip:
Der Scheduler arbeitet nach dem Request-Grant-Prinzip. Die UEs bitten den Scheduler (also eigentlich das Netzwerk) um Sendeerlaubnis und der Scheduler in der NodeB entscheidet, wann und wieviele UEs letztlich senden dürfen. Die UE-Anfrage an den Scheduler enthält auch Angaben zur Kanalqualität und zum derzeitigen Status des UE-Sendepuffers. Um den Energieverbrauch des UEs gering zu halten verwendet HSUPA im Gegensatz zu HSDPA nur ein 2PSK-Modulationsverfahren.

Leistungssteuerung:
Jedes HSUPA-UE bekommt von der NodeB mitgeteilt, welche maximale Sendeleistung es verwenden darf. Aus dieser erlaubten Sendeleistungsreserve und unter Rücksicht auf Störinterferrenzen errechnet sich das UE die maximal mögliche Sendedatenrate. Die dem UE mitgeteilte maximal erlaubte Sendeleistung kann entweder von der NodeB immer wieder neu zeitlich aktualisiert werden oder - ähnlich wie bei Rel..99-Kanälen - durch inkrementell angepasste Sendesteuerungskomandos (1 Leistungsstufe rauf oder 1 Leistungsstufe runter).

Scheduling-Mechanismen:
HSUPA kennt 2 Scheduling-Mechanismen Beide Methoden haben zum Ziel, dass die Störinterferenzen bei der Basisstation einen bestimmten Wert nicht überschreiten:

  1. Rate Scheduling (non-scheduled grant): alle Übertragungen der sendewilligen UEs erfolgen parallel/simultan, jedoch in einer ausreichend geringen Datenrate. Dadurch werden die Wartezeiten auf Kosten der Datenrate reduziert. Das Netzwerk teilt dem UE lediglich die maximale Blockgröße beim Dienstaufsetzen mit, die es während eines TTI am E-DCH übertragen darf. Das UE kann dann eigenmächtig in jedem TTI Daten senden, solange die Blockgröße pro TTI nicht größer als der signalisierte Maximalwert ist. Verändert werden kann dieser Status nur per  Dienstabbruch bzw. RRC-Neuzuweisung einer maximalen Blockgröße durch das Netzwerk. Es liegt auf der Hand, dass die zugewiesene maximale Blockgröße mit der von der NodeB zugewiesenen Sendeleistung korreliert. Dieser Scheduling-Mechanismus ist vorallem für Dienste mit konstanter Bitrate und geringen Verzögerungszeiten relevant, wie z.B. VoIP - kurzfristig die Maximaldatenrate zu erreichen ist hier weniger gefragt.
  2. Time Scheduling: nur bestimmte sendewillige UEs dürfen zu einem bestimmten Zeitpunkt übertragen. Dadurch werden höhere Spitzendatenraten auf Kosten von längeren Wartezeiten ermöglicht. Das UE horcht (über den E-AGCH Kanal) auf die NodeB, ob es von der Basisstation die Erlaubnis bekommt, Daten zu übertragen. Wenn die NodeB dem UE die Genehmigung zum Senden gibt, teilt die Basistation dem UE auch mit, mit welcher maximalen Sendeleistung das UE im jeweiligen TTI senden darf.

Welche Methode (es gibt auch Hybridansätze) verwendet wird, hängt primär von der verfügbaren Sendeleistung ab, da der E-DCH zusammen mit anderen Codekanälen gebündelt übertragen wird, die nicht nur von einem bestimmten Teilnehmer-UE her stammen müssen, sondern auch von anderen Teilnehmer-UEs stammen (z.B. Telefonat-Uplinksignal eines anderen Teilnehmers in der Zelle --> alle verwenden den gleichen Frequenzkanal!).
Die Scheduling-Methoden können als entsprechend geeignete TFC-Auswahl im UE gesehen werden (die NodeB stellt dazu dem UE einen TFC-Satz zur Verfügung).

»  nach oben

Neue Kanäle für HSUPA:

Der wichtigste Kanal aus Sicht des Anwenders ist natürlich der E-DCH (Enhanced Data CHannel), da dieser dessen Nutzdaten transportiert. Der E-DCH entspricht im Modell der UTRAN-Spezifikationen einem Transportkanal, der auf den physikalischen Kanal E-DPDCH abgebildet wird. Der E-DPDCH verwendet analog zur Uplinkübertragung in der Release 99 nur die 2PSK-Modulation (keine adapt. Mod. wie HSDPA). Es können jedoch je nach Geräteklasse mehrere E-DPDCH-Kanäle parallel übertragen werden. Im Gegensatz zu HSDPA ist jedoch der Spreizfaktor adaptiv und kann die Werte SF=2 und SF=4 haben. Die Übertragung ist multicodefähig. Analog zur Rel.99 gibt es auch einen mit dem E-DPDCH korrelierenden Uplink-Steuerkanal, nämlich den E-DPCCH.
Im Downlink wurden für den HSUPA-Betrieb vier neue Steuerkanäle eingeführt (siehe unten), mit denen z.B. das Scheduling zwischen UE und Node B gesteuert und die Downlink-Steuernachrichten (z.B.: ACK, NACK) an das UE übertragen werden.

In der Übersicht gibt es also insgesamt sechs neue Kanäle für HSUPA:

  • E-DPDCH, Enhanced Dedicated Physikal Data CHannel, Uplink:
    Dieser Kanal trägt im Uplink die E-DCH-Nutzdaten. Einer Funkverbindung können 0, 1, 2, 3 oder 4 E-DPDCH zugeordnet sein. Die maximale Datenrate von 5,76Mb/s wird z.B. dadurch erreicht, dass 2 E-DPDCH mit dem Spreizfaktor SF=2 und 2 E-DPDCH mit dem Spreizfaktor SF=4 zugeordnet werden.
    Auch die Scheduling-Informationen, also Steuernachrichten, werden vom UE über den E-DPDCH an die NodeB übertragen, indem sie an das Ende der Nutzdaten angehängt werden (am Ende der MAC-e-PDU). Mit Hilfe dieser Scheduling-Informationen gibt das UE der NodeB Bescheid, welches Nutzdatenvolumen im UE darauf wartet an die NodeB übertragen zu werden und wieviel Netzwerkkapazität das UE noch zusätzlich brauchen könnte, um mehr Daten abzutransportieren können - also praktisch wieviel Sendeleistungsreserve das UE noch hat.
     
  • E-DPCCH, Enhanced Dedicated Physical Control CHannel, Uplink:
    Dieser Kanal trägt im Uplink die Steuersignale, die mit den E-DCH korrelieren. Es gibt nur einen E-DPCCH auf einer Funkverbindung. E-DPDCH und E-DPCCH werden analog zur Release-99-Uplinkübertragung (DPDCH und DPCCH) simultan übertragen. Der E-DPCCH enthält die Steuernachrichten der Protokollschicht-1 (die Steuernachrichten höherer Protokollschichten wird über den E-DPDCH übertragen!), mit deren Hilfe die NodeB die Daten des E-DPDCH Nutzkanals ordnungsgemäß dekodieren bzw. verarbeiten kann.
    Zusätzlich kann über den E-DPCCH das Singlebit Happy-Bit übertragen: über dieses Singlebit kann das UE der NodeB mitteilen, ob das UE "happy" oder "nicht happy" ist. Das UE fühlr sich dann "nicht happy", wenn es nicht mit Maximalleistung senden und innerhalb einer gewissen Zeitspanne der Dienst-Bewilligung seinen Sendepuffer nicht leeren kann. Wie groß diese Zeitspanne ist, innerhalb der Datenpakete aus dem Sendepuffer des UEs ausgetragen sein sollten, wird bei der Dienstaufsetzung per RRC-Nachricht festgesetzt. Wird diese Zeitspanne überschritten, ohne dass das Datenpaket aus dem Puffer gelöscht werden konnte, wird also mit der Sendung des Status "nicht happy" der NodeB grob mitgeteilt, dass die Übertragung über die Funkschnittstelle mit bisheriger Sendeleistung und Kodierrate nicht sehr erfolgsversprechend ist.
     
  • E-AGCH, E-DCH Absolute Grant Channel: Downlink-Common-Channel, Downlink:
    Dieser Kanal hat den festen Spreizfaktor SF=256 und überträgt die AGs (Absolut Grants) - also eine absolute Anzahl an Dienst-Bewilligungen - für den E-DCH. Der E-AGCH ist ein "Shared"-kanal, über den die Dienstbewlligungen für mehrere Endgeräte übertragen werden. Damit ein UE weiß, dass eine signalisierte Bewilligung für es selbst angedacht ist, wird jedem UE beim Dienst-Aufsetzen eine eindeutigeIdentifikationsnummer (E-RNTI) zugewiesen. Mit Hilfe dieser E-RNTI, die am E-AGCH mitübertragen wird, weiß das UE, ob die Bewilligung für es selbst oder für ein anderes UE angedacht ist.
     
  • E-RGCH, E-DCH Relative Grant Channel, Downlink:
    Dieser Kanal überträgt die Bewilligungen für den E-DCH an ein UE und hat eine fixe Rate mit dem Spreizfaktor SF=128. Die Bewilligung wird dem UE hier nicht durch einen absoluten Wert wie beim E-AGCH, sondern durch einen inkrementellen Wert mitgeteilt, der nur 3 relativen Steuerzustände kennt und sich auf den momentanigen UE-Zustand bezieht: Up, Down und Hold. Der Zustand Up kann nur dann signalisiert werden, wenn der E-RGCH Kanal zum Serving RLS gehört. Falls der E-RGCH von einer Zelle des Non-Serving RLS stammt, dann kann er nur die zwei Kommandos Down und Hold  übertragen.
    Die Kommandos Up, Down und Hold bedeuten:
    • Down: Sobald ein UE von irgendeiner Zelle das Kommando Down empfängt, muss es die Dienst-Bewilligung zurückstufen, auch wenn die anderen Zellen Up oder Hold signalisieren.
    • Hold: Empfängt das UE von allen beteiligten Zellen das Kommando Hold, behält das UE seinen Sendestatus unverändert.
    • Up: Wird hingegen vom UE zumindest ein Kommando Up und kein einziges Down empfangen, so versetzt sich das UE in den Status mit Dienst-Bewilligung.

Wenn also ein UE eine Sende-Bewilligung für das aktuelle TTI hat und ein Hold über den E_RGCH bekommt, dann darf es das nächste TTI ebenfalls zum Senden benutzen. Würde das UE hingegen ein Down signalisiert bekommen, dann dürfte das UE im nächsten TTI nicht mehr senden. Die Algorithmen, die entscheiden, ob Up, Down oder Hold gesendet wird, sind nicht in der 3GPP spezifiziert, sondern werden von den Hardware-Produzenten selbst entworfen - ähnlich also wie die Algorithmen für effizientes Scheduling. Der E-RGCH teilt sich mit dem E-HICH den gleichen Ast im WCDMA-Codebaum, die Orthogonalität wird durch ein orthogonale Bitmuster mit 40 Bits gewährleistet. Es können bis zu 20 UEs auf einen E-RCH/E-HICH-Code multiplext werden. Mit Hilfe dieser 40 Bits werden die Kommandos Up und Down realisiert. Die Identität des UEs, für das die Steuerung der Dienstbewilligung angedacht ist, wird beim E-RGCH nicht über die E-RNTI (wie beim E-AGCH), sondern über genanntes 40-stellige Bitmuster. Wird das dem UE zugedachte "Identitäts"-Bitmuster nicht am E-RGCH vom UE erkannt, so interpretiert das UE das als den Befehl Hold - also gleiche Bewiliigung (positiv oder negativ) wie im TTI zuvor.
 

  • E-HICH, E-DCH Hybrid ARQ Indicator Channel, Downlink:
    Dieser Kanal hat eine fixe Rate mit Spreizfaktor SF=128 und überträgt die HARQ-Rückbestätigungen (ACK, NACK) für den E-DCHs.
     
  • F-DPCH, Fractional Dedicated Physical Channel, Downlink:
    Dieser Kanal überträgt die Layer-1-Steuersignale (z.B. TCP-Befehle).
     
 

 

HSUPA verwendet ein TTI (Time Transmit Interval = Paketlängen) alternativ von 2ms und 10ms , wobei 2ms-Paketlängen mehr Rechenleistung abverlangt und auch nicht von allen Endgeräten unterstützt wird (siehe HSUPA-Geräteklassen in Abb.4), dafür aber eine dynamischere Dienstcharakteristik ermöglicht.

»  nach oben

HSUPA-Geräteklassen

Für HSUPA-Endgeräte wurden sechs Geräteklassen definiert, die sich durch verschiedene technische Charakteristika unterscheiden. In der Abb.4 sind pro Geräteklasse sechs Spalten mit den wichtigsten Charakteristika dargestellt. Die Spalte 2 gibt an, wieviele E-DPDCH- Kanäle das Endgerät parallel übertragen kann und mit welchem Spreizfaktor dies erfolgen kann. Die Spalte 3 definiert den kleinstmöglichen Spreizfaktor, der verwendet werden kann. Spalte 3 gibt an, welche TTI-Rahmenlängen das Endgerät verarbeiten kann (2ms zusätzlich ist gut). Spalte 4 und 5 gibt die maximale Bitzahl des TTI-Funkrahmens an, wobei Spalte 4 für TTI mit 10ms und Spalte 5 für TTI mit 2ms Länge gilt. Spalte 7 letztlich gibt die maximale Datenrate des Endgerätes an.

 

HSUPA-Geräteklassen

Abb.4: HSUPA-Geräteklassen

 

Wie in der letzten Reihe der Abb.4 zu sehen ist, bietet HSUPA eine maximale Datenrate von 5,76Mb/s, sofern das Endgerät der Kategorie 6 angehört und ein TTI von 2ms verwendet wird.

»  nach oben

HARQ - Hybrid Automatic Repeat Request

Vom allgemeinen Funktionsprinzip her gesehen gilt bei HSUPA ähnliches wie bei HSDPA und ist auf folgender Seite ausführlich nachzulesen:    HARQ bei HSDPA

Zu beachten ist, dass es bei HSUPA TTI-Intervalle von 10ms und je nach Geräteklasse optional von 2ms gibt. Auch bei HSUPA wird ein Stop-And-Wait-Protokoll verwendet und je nach verwendeter TTI-Länge kommen unterschiedlich viele HARQ-Prozesse parallel zum Einsatz:

  • TTI=10ms: 4 parallele HARQ-Prozesse
     
  • TTI=2ms: 8 parallele HARQ-Prozesse

Die NodeB quittiert als Empfänger den fehlerfreien Empfang von einem Paket eines HARQ-Prozesses, indem Sie ein ACK an das UE zurücksendet. Dieses ACK veranlasst das UE, dass das zuvor erfolgreich gesendete Datenpaket aus dem Puffer ausgetragen wird und in diesem HARQ-Prozess ein neues Datenpaket übertragen werden kann. Sollte der Empfang hingegen irreparabel fehlerbehaftet gewesen sein, so signalisiert die NodeB ein NACK zurück, wodurch das UE in diesem HARQ-Prozess das zuvor gesendete Datenpaket nochmals überträgt. ACK und NACK werden über den E-HICH Kanal übertragen.

 

HARQ-Prozesse

Abb.5 parallele HARQ-Prozesse (roter Prozess, blauer Prozess)

 

Darüber hinaus gilt bei HSUPA, dass falls für den E-DCH-Kanal HARQ verwendet wird, folgende Operationsmethoden bezüglich der Neuübertragung verfügbar sind:

  • Autonome Neuübertragung durch das UE:
    Empfängt das UE kein ACK für ein gesendetes Datenpaket, dann überträgt das UE dieses Datenpaket nochmals ohne um Erlaubnis bei der NodeB zu bitten. Das UE muss in diesem Fall nicht den Kanal überwachen, der das Scheduling für Neuübertragungen verwaltet. Es kann jedoch zu Störinterferenzen in der Zelle kommen, falls die NodeB durch die Sendeleistung dieser Neuübertragung keine Reserven eingeplant hat.
  • Zeitplanung durch die NodeB für Neuübertragungen:
    Das UE führt die Neuübertragung durch, falls es kein ACK bekommen hat und diese Neuübertragung von der NodeB genehmigt wurde. Es muss natürlich bei der Neuübertragung berücksichtigt werden, ob das zuvor gewählte TFC momentan durchführbar ist

 

Softhandover

HSUPA unterstützt im Gegensatz zu HSDPA Softhandover! Für den HARQ-Mechanismus bedeutet das, dass im Softhandoverfall das UE die Rückmeldungen (ACK) von mehreren Node Bs auswerten muss und dass nur dann eine Neuübertragung durchgeführt werden muss, wenn KEINE Node B das Paket vom UE korrekt bekommen hat. Gibt es also zumindest eine positive Empfangsbestätigung, dann wird das nächste Paket vom UE gesendet.
Ist ein UE im Softhandover mit mehreren Zellen, so empfängt es normalerweise Informationen von jeder NodeB über deren jeweiligen E-RGCH Kanal. Jene Zellen, von denen das UE ein Softcombining der E-RGCH-Nachrichten durchführen kann, bilden ein Serving RLS (Radio Link Set); jene Zelle, von der das UE den E-AGCH bezieht, bezeichnet man als Serving Cell. Softcombining bedeutet hier also, dass ein Serving RLS aus jenen Zellen besteht, die von jener NodeB terminiert werden, die auch die Serving Cell terminiert - üblicherweise sind das drei Zellen. Die Zellen eines Serving RLS müssen alle die gleichen E-RGCH-Steuersignale pro TTI aussenden. Alle Zellen, die Nachrichten über den E-RGCH an das UE senden und nicht zum Serving RLS gehören, bilden das Non-Serving RLS.
Zelle

 

»  nach oben

© Rudolf Riemer, UMTSlink.at


 

2PSK = BPSK
3GPP 3rd Generation Partnership Project www.3gpp.org
ACK Acknowledge (postive Rückbestätigung)
ADSL   Asymmetric Digital Subscriber Line
BPSK Binary Phase Shift Keying: Modulationsverfahren
BTS   Base Tranceiver Station (Basisstation)
E-AGCH Enhanced - Absolute Grant CHannel
E-DCH Enhanced - Data CHannel (HSUPA-Datenkanal)
E-DPCCH Enhanced - Dedicated Physical Control CHannel
E-DPDCH Enhanced - Dedicated Physical Data CHannel
E-HICH E-DCH - Hybrid ARQ Indicator Channel
E-RGCH Enhanced - Relative Grant CHannel
E-RNTI Enhanced - Radio Network Temporary Identity
F-DPCH Fractional - Dedicated Physical Channel
GGSN   Gateway GPRS Support Node
GPRS   General Packet Radio Service
HARQ Hybrid Automatic Repeat Requenst
HSDPA   High Speed Downlink Packet Access (Release 5)
HSPA   High Speed Packet Access = HSDPA + HSUPA
HSPA+   =eHSPA (Release 7)
HSUPA   High Speed Uplink Packet Access (Release 6)
LTE   Long Term Evolution (Release 8)
MAC-e Media Access Control - enhanced (in der NodeB/UE)
MAC-es Media Access Control - enhanced (im RNC/UE)
NACK Negative Acknowledge (negative Rückbestätigung)
NodeB   NodeB (Basisstation von UTRAN) = BTS
PDU Packet Data Unit
QoS   Quality of Service (Dienstgüte)
RLS Radio Link Set
RNC   Radio Network Controller
RRC Radio Ressource Control
SGSN   Serving GPRS Support Node
TFC Transport Format Combination
TTI Time Transmit Interval: Funkzeitrahmen
UE User Equipment (z.B. Handy oder Datenkarte)
UMTS   Universal Mobile Telecommunications System
UTRAN   Universal Terrestrial Radio Access Network
VoIP Voice over IP - Telefonie über IP-Datennetz
WCDMA   Wideband Code Division Multiple Access
WLAN Wireless Local Area Network

 

 

Nach oben   HSDPA   UMTS-Start

iPhone: App-Piraterie erreicht "sehr hohes Niveau"
04.11. 2009 - 13:14 - von webgfrast
HTML clipboard4. November 2009

38 Prozent der entsperrten Geräte haben illegale Programme installiert


San Jose - Die Piraterie in Apples App Store entwickelt sich zu einem zunehmenden Problem für Betreiber und Programmierer. Wie das...[Mehr lesen]
1 Hits
Meizu M8 neues Beta Betriebssystem - Eine Konkurrenz zu iPhone und Android?
04.11. 2009 - 10:48 - von TigerLion
4. November 2009

Neues Beta Betriebssystem von Meizu - Eine Konkurrenz zu iPhone und Android?

Das Meizu M8 ist ein Internet- und Multimediafähiges multitouch Smartphone des chinesischen MP3-Player-Herstellers Meizu. Schon lange vor dessen Erscheinung regte das Handy aufgrund seiner starken Ähnlichkeit zu Apples iPhone zu...[Mehr lesen]
54 Hits
Opera Mobile 10 für Symbian S60 mit Tab-Browsing
04.11. 2009 - 10:17 - von TigerLion
4. November 2009

Opera Mobile 10 für Symbian S60 mit Tab-Browsing

Opera hat eine Betaversion von Opera Mobile 10 für Symbian S60 veröffentlicht. Sie soll deutlich schneller arbeiten als die Vorversion. Sie bietet Tab-Browsing und einen Kennwortmanager. Die Bedienoberfläche wurde überarbeitet und bietet mehr Platz für...[Mehr lesen]
32 Hits
Sony Ericsson zeigt Android-Handy X10
03.11. 2009 - 13:10 - von TigerLion
3. November 2009

Sony Ericsson zeigt Android-Handy X10

Sony Ericsson hat sein neues Smartphone-Flaggschiff Xperia X10 präsentiert. Das System setzt auf Googles Android auf, bringt aber eine eigene Oberfläche für Zugriff auf Mediendateien und Social Networks mit. Das Gerät läuft unter dem Google-Betriebssystem Android, hat...[Mehr lesen]
119 Hits
Nokia begräbt N-Gage
01.11. 2009 - 16:23 - von TigerLion
1. November 2009

Nokia begräbt N-Gage

Nokia stellt N-Gage zu Ende September 2010 ein. Ab sofort werden keine neuen Spiele mehr über die N-Gage-Plattform veröffentlicht. An die Stelle von N-Gage tritt der Ovi Store. Alle Dienste von Nokia wandern unter die Marke Ovi.

...[Mehr lesen]
182 Hits
HTC will sein Profil schärfen und zu Nokia und Apple aufholen
31.10. 2009 - 14:07 - von TigerLion
31. Oktober 2009

HTC will sein Profil schärfen und zu Nokia und Apple aufholen

Der taiwanesische Smartphone-Hersteller HTC will sein Profil schärfen. Zuletzt vor allem mit den Android-Modellen T-Mobile G1, Magic oder Hero erfolgreich, will das Unternehmen zukünftig nicht nur auf Googles Open-Source-Betriebssystem setzen und...[Mehr lesen]
183 Hits
Doppelkern-Prozessoren für Handys kommen 2010
30.10. 2009 - 11:27 - von TigerLion
30. Oktober 2009

Doppelkern-Prozessoren für Handys kommen 2010

Im Gespräch mit dem IT-Magazin Techradar.com hat der Chip-Hersteller ARM die ersten Handys mit Doppelkern-Prozessor in Aussicht gestellt. Entsprechende Geräte könnten schon 2010 auf den Markt kommen, möglicherweise aber auch erst 2011. Die neue...[Mehr lesen]
183 Hits
Powered by vBadvanced CMPS v3.0 RC1

Alle Zeitangaben in WEZ +2. Es ist jetzt 13:19 Uhr.



Powered by vBulletin® Version 3.6.8 (Deutsch)
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
(c) UMTSlink.at 2003 - 2009