-
Technisches Gebiet
-
Die vorliegende Offenbarung bezieht sich im Allgemeinen auf Drahtloskommunikation und insbesondere auf Techniken zum Verbessern einer Konfiguration von diskontinuierlichem Empfang DRX ("discontinuous reception") und Zeitplanungsanforderung SR ("scheduling request") für diverse Datenanwendungen.
-
Hintergrund
-
In bestehenden Kommunikationssystemen ist eine große Anzahl von Kommunikationsvorrichtungen tragbar, wie etwa Funk- (oder "Mobil"-)Telefone, Smartphones, Tablet-PCs oder Laptop-PCs, usw., so dass effiziente Energiesparschemata zur Erhöhung der Betriebszeiten derartiger tragbarer batteriebetriebener Vorrichtungen notwendig sind.
-
Ein Ansatz zum Ermöglichen einer verbesserten Energieeinsparung ist ein diskontinuierlicher Empfang DRX ("discontinuous reception"). In einem Modus diskontinuierlichen Empfangs empfängt eine tragbare Vorrichtung Daten periodisch in speziellen Empfangsintervallen, wohingegen die Vorrichtung in Ruheintervallen keinerlei Daten empfängt. Im Speziellen definiert DRX Perioden, wann zum Beispiel eine Teilnehmervorrichtung UE einen physikalischen Downlink-Steuerkanal PDCCH abhört, der dann angeben kann, dass Daten für die UE vorhanden sind. Der Empfang von Daten kann dann länger als eine vorher definierte DRX-Ein-Dauer-Periode andauern. Dadurch kann das Kommunikationssystem ermöglichen, dass ein DRX-Modus einer tragbaren Vorrichtung Batterieenergie einspart, wenn das System schätzt, dass die tragbare Vorrichtung nicht in jedem Funkunterrahmen eine Übertragung von einer Basisstation empfangen muss.
-
Die Anforderungen dafür, wie die Verwaltungseffizienz in/für Uplink-Steuerkanal-Ressourcen für Teilnehmervorrichtungen UEs in Verbunden-Modus, die vorübergehend inaktiv sind, zu verbessern ist, ebenso wie für einen niedrigeren Energieverbrauch werden zu weithin beachteten Angelegenheiten.
-
In RAN#53 wurde ein Arbeitspunkt mit der Bezeichnung "LTE RAN enhancements for diverse data applications" gebilligt, wobei eine Zielsetzung von diesem auf eine RAN-(Funkzugangsnetzwerk-)Verbesserung für Anwendungen wie etwa eine Kleindatenübertragung und eine Hintergrunddatenübertragung abzielt. Die für den Arbeitspunkt ermittelten Erweiterungen bzw. Verbesserungen sind wie folgt:
- 1. Erweiterungen bzw. Verbesserungen innerhalb bestehender Funkressourcensteuerung-RRC-Zustände in RRC-Zustandssteuerungsmechanismen und Funkressourcenverwaltung-RRM-Mechanismen, die Systemeffizienzverbesserungen und/oder einen verringerten Teilnehmervorrichtung-UE-Energieverbrauch für Vorrichtungen bieten, die eine fortgesetzte, aber intermittierende Datenaktivität zeigen.
- 2. Erweiterungen bzw. Verbesserungen in DRX-Konfiguration/Steuerungsmechanismen, die besser auf die Bedürfnisse und die Aktivität entweder von einzelnen oder mehreren Anwendungen eingehen, die parallel laufen, mit einer verbesserten Anpassungsfähigkeit an zeitlich variierende Verkehrsprofile und an Anwendungsanforderungen, um dadurch eine verbesserte Optimierung des Ausgleichs bzw. Kompromisses zwischen Leistung und UE-Batterieverbrauch zu ermöglichen.
- 3. Eine effizientere Verwaltung von Systemressourcen (z.B. Uplink-UL-Steuerkanal-Ressourcen) für UEs in Verbunden-Modus, die vorübergehend inaktiv sind, was eine potentiell größere Benutzerpopulation in Verbunden-Modus ermöglicht.
- 4. Für die vorgenannten Erweiterungen bzw. Verbesserungen sollten, soweit möglich, Erkenntnisse sowohl von der UE als auch dem Netzwerk berücksichtigt werden.
-
In Referenz [3] wurde beobachtet, dass Ressourcen von einem physikalischen Uplink-Steuerkanal PUCCH hauptsächlich für SR und Kanalqualitätsindikator-CQI-("channel quality indicator"), PMI-("precoding matrix indicator") und/oder RI-("rank indicator")Berichterstattung zugewiesen werden. Wenn DRX angewandt wird, wird eine gewisse Menge von für SR zugewiesenen PUCCH-Ressourcen abhängig von DRX- und SR-Konfigurationen verschwendet. Daher wären Schemata notwendig, um die Ressourceneffizienz bei SR-Übertragung für nicht-periodischen Hintergrundverkehr zu verbessern.
-
In bestehenden Long-Term-Evolution-LTE-Systemen versorgt ein Endgerät eine Basisstation eNB mit Informationen über die Daten in seinen Puffern unter Verwendung von zwei Mechanismen: 1-Bit-Zeitplanungsanforderung SR ("scheduling request") und Pufferstatusberichte BSR. SR wird auf einem Steuerkanal (physikalischen Uplink-Steuerkanal PUCCH oder Funkzugangskanal RACH) übertragen, während BSR auf dem Datenkanal (physikalischen gemeinsamen Uplink-Kanal PUSCH) meist zusammen mit Benutzerdaten übertragen wird. In gegenwärtigen Systemen kann die SR-Ressource mit einer Periode und einem Unterrahmenversatz konfiguriert sein. Die SR-Periode kann 1ms, 2ms, 5ms, 10ms, 20ms, 40ms oder 80ms sein.
-
Wenn in einem System viele Anwendungen und UEs vorhanden sind, kann eine effiziente Nutzung der Uplink-UL-Steuerressource ein Problem sein. In einem gegenwärtigen System ist die Zahl von bis zu 36 UEs vorhanden, aber in der Praxis ist eine vernünftige Anzahl nur 18 UEs, denen eine unterschiedliche zyklische Verschiebung und orthogonale Spreizung gegeben werden kann, um unterschiedliche SR-Ressourcen in einem Ressourcenblock RB bereitzustellen.
-
In UEs gibt es aktuelle Anwendungen, die eine sogenannte Hintergrundverkehr-Datenübertragung anwenden, was bedeutet, dass die Daten ohne jedwede Benutzeraktivität übertragen werden. In einer derartigen Situation hat der Benutzer keine umfassende Kontrolle über übertragene Daten. In gegenwärtigen LTE-Systemen würde, wenn ein Paket an einer UE ankommt, dies eine periodische SR triggern bzw. auslösen, um eine UL-Ressource für eine Datenübertragung anzufordern. Dies kann eine Verschwendung einer SR-Übertragung oder einen Verlust oder eine Verzögerung der Daten verursachen.
-
Daher wären Maßnahmen zum Verbessern der Ressourceneffizient einer SR-Übertragung für nicht-periodischen Hintergrundverkehr wünschenswert. Ausführungsbeispiele der vorliegenden Offenbarung stellen Verbesserungen gegenüber bestehenden SR- und DRX-Vorgängen von LTE bereit.
-
Referenzen:
-
- [1] 3GPP TS 36.331, Radio Resource Control (RRC); Protocol Aspects
- [2] R2-112940, RAN Efficiency Improvement Schemes; Renesas
- [3] R2-113222, PUCCH evaluation; HuaWei
- [4] TR 36.213
- [5] 3GPP TR 36.822, Technical Specification Group Radio Access Network
- [6] R2-121484, PUCCH improvements for Diverse Data Applications; Renesas Mobile Europe
- [7] R2-121535, Efficient SR resource allocation on PUCCH; Ericcson, ST-Ericsson
-
Kurzfassung
-
Ausführungsbeispiele der vorliegenden Offenbarung stellen Vorrichtungen, Verfahren, Computersoftware und Computerprogrammprodukte zum Verbessern einer DRX- und einer Zeitplanungsanforderungskonfiguration für diverse Datenanwendungen bereit.
-
Gemäß einem ersten Aspekt der vorliegenden Offenbarung ist ein Verfahren zur Verwendung bei diskontinuierlichem Empfang in einem Drahtloskommunikationsnetzwerk bereitgestellt, wobei das Verfahren aufweist:
Bestimmen von Informationen, die mit Daten in einem Puffer einer Teilnehmervorrichtung in Zusammenhang stehen;
Bewirken einer Übertragung der bestimmten Informationen an ein Netzwerkelement;
Empfangen von Datenzeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs von dem Netzwerkelement, wobei die empfangenen Datenzeitplanungsanforderung-Zeitintervall-Informationen auf den bestimmten Informationen basieren; und
Bewirken einer Übertragung einer Datenzeitplanungsanforderung an das Netzwerkelement in dem empfangenen Datenzeitplanungsanforderung-Zeitintervall.
-
Gemäß einem zweiten Aspekt der vorliegenden Offenbarung ist eine Vorrichtung zur Verwendung bei diskontinuierlichem Empfang in einem Drahtloskommunikationsnetzwerk bereitgestellt, wobei die Vorrichtung ein Verarbeitungssystem aufweist, das angepasst ist, die Vorrichtung zu veranlassen zum:
Bestimmen von Informationen, die mit Daten in einem Puffer einer Teilnehmervorrichtung in Zusammenhang stehen;
Bewirken einer Übertragung der bestimmten Informationen an ein Netzwerkelement;
Empfangen von Datenzeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs von dem Netzwerkelement, wobei die empfangenen Datenzeitplanungsanforderung-Zeitintervall-Informationen auf den bestimmten Informationen basieren; und
Bewirken einer Übertragung einer Datenzeitplanungsanforderung an das Netzwerkelement in dem empfangenen Datenzeitplanungsanforderung-Zeitintervall.
-
Gemäß einem dritten Aspekt der vorliegenden Offenbarung ist ein Verfahren zur Verwendung bei diskontinuierlichem Empfang in einem Drahtloskommunikationsnetzwerk bereitgestellt, wobei das Verfahren aufweist:
Empfangen von Informationen, die mit Daten in einem Puffer einer Teilnehmervorrichtung in Zusammenhang stehen, von der Teilnehmervorrichtung;
Einstellen eines Datenzeitplanungsanforderung-Zeitintervalls für eine Steuerung eines diskontinuierlichen Empfangs basierend auf den empfangenen Informationen; und
Bewirken einer Übertragung von Zeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs an die Teilnehmervorrichtung.
-
Gemäß einem vierten Aspekt der vorliegenden Erfindung ist eine Vorrichtung zur Verwendung bei diskontinuierlichem Empfang in einem Drahtloskommunikationsnetzwerk bereitgestellt, wobei die Vorrichtung ein Verarbeitungssystem aufweist, das angepasst ist, die Vorrichtung zu veranlassen zum:
Empfangen von Informationen, die mit Daten in einem Puffer einer Teilnehmervorrichtung in Zusammenhang stehen, von der Teilnehmervorrichtung;
Einstellen eines Datenzeitplanungsanforderung-Zeitintervalls für eine Steuerung eines diskontinuierlichen Empfangs basierend auf den empfangenen Informationen; und
Bewirken einer Übertragung von Zeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs an die Teilnehmervorrichtung.
-
Gemäß einem fünften Aspekt der vorliegenden Erfindung ist Computersoftware bereitgestellt, die angepasst ist, das Verfahren des ersten Aspekts und/oder des dritten Aspekts der vorliegenden Offenbarung durchzuführen.
-
Gemäß einem sechsten Aspekt der vorliegenden Erfindung ist ein Computerprogrammprodukt bereitgestellt, das ein (nicht-vorübergehendes) computerlesbares Speichermedium mit darauf gespeicherten computerlesbaren Anweisungen aufweist, wobei die computerlesbaren Anweisungen durch eine computerbasierte Vorrichtung ausführbar sind, um die computerbasierte Vorrichtung zu veranlassen, das Verfahren des ersten Aspekts und/oder des dritten Aspekts der vorliegenden Offenbarung durchzuführen.
-
Gemäß Ausführungsbeispielen ist eine Vorrichtung bereitgestellt, die aufweist: eine Bestimmungseinrichtung zum Bestimmen von Informationen von/über Daten in einem Puffer, eine Übertragungseinrichtung zum Bewirken, dass die bestimmten Informationen an ein Netzwerkelement übertragen werden, eine Empfangseinrichtung zum Empfangen von Datenzeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs von dem Netzwerkelement, und eine Übertragungseinrichtung zum Bewirken, dass eine Datenzeitplanungsanforderung an das Netzwerkelement in dem empfangenen Datenzeitplanungsanforderung-Zeitintervall übertragen wird.
-
Gemäß Ausführungsbeispielen ist eine Vorrichtung bereitgestellt, die aufweist: eine Empfangseinrichtung zum Empfangen von Informationen von/über Daten in einem Puffer einer Teilnehmervorrichtung von der Teilnehmervorrichtung, eine Einstelleinrichtung zum Einstellen eines Datenzeitplanungsanforderung-Zeitintervalls für eine Steuerung eines diskontinuierlichen Empfangs basierend auf den empfangenen Informationen, und eine Übertragungseinrichtung zum Bewirken, dass die Datenzeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs an die Teilnehmervorrichtung übertragen werden.
-
Vorteilhafte Weiterbildungen oder Modifikationen der vorgenannten Aspekte der vorliegenden Offenbarung sind in den abhängigen Patentansprüchen dargelegt.
-
Gemäß Ausführungsbeispielen der vorliegenden Offenbarung kann die Anzahl von Zeitplanungsanforderung-SR-Übertragungen in dem Uplink UL infolgeankunft verringert werden, wodurch die Verwaltungseffizienz in/für eine UL-Steuerkanal-Ressource verbessert wird, was einen verbesserten Zeitplanungsmechanismus zum Beispiel bei einer Verwendung von einer Datenzeitplanungsanforderung DSR, einer temporären Zeitplanungsanforderung TSR und einer Zufalls- bzw. Direktzugriffskanal-Zeitplanungsanforderung RSR ermöglicht.
-
Weitere Merkmale und Vorteile von Ausführungsbeispielen werden aus der folgenden Beschreibung von bevorzugten Ausführungsbeispielen deutlich, die lediglich beispielhaft gegeben sind, wobei diese unter Bezugnahme auf die begleitenden Zeichnungen erfolgt.
-
Kurze Beschreibung von Zeichnungen
-
Für ein vollständigeres Verständnis von Ausführungsbeispielen der vorliegenden Offenbarung wird nunmehr auf die folgende Beschreibung Bezug genommen, die in Verbindung mit den begleitenden Zeichnungen zu nehmen ist, bei denen gilt:
-
1 zeigt ein prinzipielles Ablaufdiagramm eines beispielhaften Verfahrens gemäß Ausführungsbeispielen der vorliegenden Offenbarung, das in einer Teilnehmervorrichtung UE implementiert sein kann;
-
2 zeigt eine prinzipielle Konfiguration einer beispielhaften Vorrichtung gemäß Ausführungsbeispielen der vorliegenden Offenbarung;
-
3 zeigt ein prinzipielles Ablaufdiagramm eines beispielhaften Verfahrens gemäß Ausführungsbeispielen der vorliegenden Offenbarung, das in einer Basisstation eNB implementiert sein kann;
-
4 zeigt eine prinzipielle Konfiguration einer beispielhaften Vorrichtung gemäß Ausführungsbeispielen der vorliegenden Offenbarung;
-
5 zeigt ein Schema eines Paketankunftstriggers gemäß Ausführungsbeispielen der vorliegenden Offenbarung;
-
6 zeigt ein weiteres Schema eines Paketankunftstriggers gemäß Ausführungsbeispiel der vorliegenden Offenbarung;
-
7 zeigt ein weiteres Schema eines Paketankunftstriggers gemäß Ausführungsbeispielen der vorliegenden Offenbarung; und
-
8 zeigt ein Schema von einem DRX-Zyklus eines diskontinuierlichen Empfangs gemäß 3GPP Release 8, TR 36.321.
-
Aspekte der vorliegenden Offenbarung werden hierin nachstehend beschrieben. Im Speziellen werden Aspekte der vorliegenden Offenbarung hierin nachstehend unter Bezugnahme auf bestimmte nicht-einschränkende Beispiele von Ausführungsbeispielen der vorliegenden Offenbarung beschrieben. Ein Fachmann wird würdigen, dass Ausführungsbeispiele keineswegs auf diese Beispiele beschränkt sind und umfassender angewandt werden können.
-
Es ist zu beachten, dass sich die folgende Beschreibung der vorliegenden Offenbarung und deren Ausführungsbeispiele hauptsächlich auf Spezifikationen bezieht, die als nicht einschränkende Beispiele von Netzwerkkonfigurationen und -einsätzen/implementierungen verwendet werden. Die vorliegende Offenbarung und deren Ausführungsbeispiele werden nämlich hauptsächlich in Zusammenhang mit 3GPPTM-Spezifikationen beschrieben, die als nicht einschränkende Beispiele von Netzwerkkonfigurationen und -einsätzen/implementierungen verwendet werden. Insbesondere wird ein LTETM/LTE-AdvancedTM-Kommunikationssystem als ein nicht einschränkendes Beispiel für die Anwendbarkeit von hiermit beschriebenen Ausführungsbeispielen verwendet. Als solches bezieht sich die hierin gegebene Beschreibung von Ausführungsbeispielen auf eine Terminologie, die direkt damit in Zusammenhang steht. Eine solche Terminologie wird nur in Zusammenhang der vorgestellten nicht einschränkenden Beispiele verwendet und schränkt Ausführungsbeispiele natürlich in keiner Weise ein. Vielmehr kann eine beliebige andere Netzwerkkonfiguration oder Systemimplementierung, usw. eingesetzt werden, solange diese mit den hierin beschriebenen Merkmalen konform ist. Einige Beispiele von Netzwerkkonfigurationen oder Systemimplementierungen sind das Funkzugangsnetzwerk (UTRAN oder E-UTRAN) von Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE, auch bekannt als E-UTRA), Long Term Evolution Advanced (LTE-A), Wireless Local Area Network (WLAN) basierend auf IEEE (Institute of Electrical and Electronics Engineers) 802.11-Standard, Worldwide Interoperability for Microwave Access (WiMAX), BluetoothTM und Systeme unter Verwendung von Ultra-Wideband-(UWB-)Technologie.
-
Nachstehend werden hierin verschiedene Ausführungsbeispiele und Implementierungen der vorliegenden Offenbarung und deren Aspekte oder Ausführungsbeispiele unter Verwendung mehrerer Alternativen beschrieben. Es ist allgemein zu beachten, dass gemäß bestimmten Notwendigkeiten und Bedingungen alle der beschriebenen Alternativen alleine oder in einer beliebigen denkbaren Kombination (auch umfassend Kombinationen von einzelnen Merkmalen der verschiedenen Alternativen) bereitgestellt werden können.
-
1 zeigt ein prinzipielles Ablaufdiagramm eines Verfahrens gemäß Ausführungsbeispielen der vorliegenden Offenbarung.
-
In Schritt S11 werden Informationen, die mit Daten in einem Puffer in Zusammenhang stehen, bestimmt.
-
In Schritt S12 wird bewirkt, dass die bestimmten Informationen an ein Netzwerkelement übertragen werden.
-
In Schritt S13 werden Datenzeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs von dem Netzwerkelement empfangen.
-
In Schritt S14 wird bewirkt, dass eine Datenzeitplanungsanforderung in dem empfangenen Zeitplanungsanforderung-Zeitintervall an das Netzwerkelement übertragen wird.
-
2 zeigt eine prinzipielle Konfiguration einer beispielhaften Vorrichtung gemäß Ausführungsbeispielen der vorliegenden Offenbarung. Die Vorrichtung 20 umfasst ein Verarbeitungssystem und/oder zumindest einen Prozessor 21 und zumindest einen Speicher 22, der Computerprogrammcode umfasst, die durch einen Bus 24 oder dergleichen verbunden sind. Wie es in 2 mit einer gestrichelten Linie angedeutet ist, kann optional eine Schnittstelle 23 mit dem Bus 24 oder dergleichen verbunden sind, die eine Kommunikation z.B. zu/von einer Netzwerkinstanz, einer Basisstation, einer UE oder dergleichen ermöglicht. Das Verarbeitungssystem und/oder der zumindest eine Speicher und der Computerprogrammcode sind, mit dem zumindest einen Prozessor, eingerichtet, um die Vorrichtung zu veranlassen, zumindest ein Bestimmen von Informationen, die mit Daten in dem Puffer im Zusammenhang stehen, ein Bewirken einer Übertragung der bestimmten Informationen an ein Netzwerkelement, ein Empfangen von Datenzeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs von dem Netzwerkelement, und ein Bewirken einer Übertragung einer Datenzeitplanungsanforderung in dem empfangenen Datenzeitplanungsanforderung-Zeitintervall an das Netzwerkelement durchzuführen.
-
3 zeigt ein prinzipielles Ablaufdiagramm eines beispielhaften Verfahrens gemäß Ausführungsbeispielen der vorliegenden Offenbarung.
-
In Schritt S31 werden Informationen, die mit Daten in einem Puffer einer Teilnehmervorrichtung in Zusammenhang stehen, von der Teilnehmervorrichtung empfangen.
-
In Schritt S32 wird ein Datenzeitplanungsanforderung-Zeitintervall für eine Steuerung eines diskontinuierlichen Empfangs basierend auf den empfangenen Informationen eingestellt.
-
In Schritt S33 wird bewirkt, dass Datenzeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs an die Teilnehmervorrichtung übertragen werden.
-
4 zeigt eine prinzipielle Konfiguration einer beispielhaften Vorrichtung gemäß Ausführungsbeispielen der vorliegenden Offenbarung. Die Vorrichtung 40 umfasst ein Verarbeitungssystem und/oder zumindest einen Prozessor 41 und zumindest einen Speicher 42, der Computerprogrammcode umfasst, die durch einen Bus 44 oder dergleichen verbunden sind. Wie es in 4 mit einer gestrichelten Linie angedeutet ist, kann optional eine Schnittstelle 43 mit dem Bus 44 oder dergleichen verbunden sein, die eine Kommunikation z.B. zu/von einer Teilnehmervorrichtung, einer Netzwerkinstanz, einer Basisstation oder dergleichen ermöglicht. Das Verarbeitungssystem und/oder zumindest ein Speicher und der Computerprogrammcode sind, zusammen mit dem zumindest einen Prozessor, eingerichtet, um die Vorrichtung zu veranlassen, zumindest ein Empfangen von Informationen, die mit Daten in einem Puffer einer Teilnehmervorrichtung in Zusammenhang stehen, von der Teilnehmervorrichtung, ein Einstellen eines Datenzeitplanungsanforderung-Zeitintervalls für eine Steuerung eines diskontinuierlichen Empfangs basierend auf den empfangenen Informationen, und eine Bewirken einer Übertragung von Datenzeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs an die Teilnehmervorrichtung durchzuführen.
-
Gemäß Ausführungsbeispielen der vorliegenden Anmeldung ist es möglich, eine Zeitplanungsanforderung SR mit längerer Periode zu verwenden, um die belegte SR-Ressource zu verringern, falls keine häufige bzw. regelmäßige Datenübertragung erfolgt. Weiterhin ist es möglich, eine temporäre SR (TSR) zu verwenden, um das SR-Intervall vorübergehend zu verkürzen, ohne eine sehr hohe Last auf einem physikalischen Uplink-Steuerkanal PUCCH zu erfordern. Die TSR kann wirksam sein, bis ein Zeitgeber abläuft.
-
Gemäß Ausführungsbeispiel der vorliegenden Offenbarung können zwei Datenzeitplanungsanforderung-DSR-Konfigurationen für eine Teilnehmervorrichtung UE verwendet werden, eine für eine längere DSR- und eine andere für eine kürzere DSR-Periode als TSR.
-
Bei Ausführungsbeispielen kann die UE zumindest Durchschnittsdatengrößeninformationen, Durchschnittsdatenperiodeninformationen und/oder Intervallankunftszeitinformationen von Daten in dem Puffer an eine eNB senden, um der eNB zu helfen, eine angemessene längere DRX- und längere DSR-Konfiguration zu konfigurieren.
-
Zusammen mit den Durchschnittsdatengrößeninformationen, den Durchschnittsdatenperiodeninformationen und den Intervallankunftszeitinformationen von Daten in dem Puffer, die durch die UE gesendet werden, kann ein Senden einer SR eine angemessene längere DRX- und längere DSR-Konfiguration in Erwiderung auf die SR-Anforderung ermöglichen, so dass ein angemessener DRX mit einem flexiblen Startversatzparameter drxStartOffset basierend auf einem Lernvorgang der Zeitplanungseinrichtung eingestellt werden kann, was nachstehend ausführlicher beschrieben ist.
-
Der dsrTSR-StartOffset ist ein neuer DRX-Parameter. Mehrere Optionen können mithin umfasst sein, wie etwas T [ms]. Selbst wenn Ausführungsbeispiele der vorliegenden Offenbarung nicht auf einen speziellen Wert von T [ms] beschränkt sind, besteht der Grund dafür, warum T [ms] ein angemessener Parameter für dsrTSR-StartOffset sein kann, darin, dass ein Tx/Rx und eine erneute Übertragung von einer UE innerhalb der Zeitperiode von T [ms] abgeschlossen sein kann. In aktuellen LTE-Systemen wird, wenn eine UE eine erneute Übertragung zu einer Zeit n startet, die UE eine Antwort zu einer Zeit n + 4 erhalten, und kann, wenn die Antwort negativ ist, die UE dann das gleiche Paket weitere 4 ms später erneut übertragen müssen. Daher kann in LTE ein Wert von ungefähr T = 20 ms ein angemessenes Intervall für die UE sein, um eine weitere neue Paketübertragung in TSR zu berücksichtigen.
-
Bei Ausführungsbeispielen können Durchschnittsdatengrößeninformationen, Durchschnittsdatenperiodeninformationen und Intervallankunftszeitinformationen, die mit Daten in einem Puffer in Zusammenhang stehen, wobei diese durch eine UE gesendet werden, durch eine automatische Messung in einer bestimmten Zeitdauer erhalten werden (ähnlich zu der Art und Weise, um die Verkehrscharakteristik herauszufinden) oder bereits auf einer Netzwerk- und/oder einer UE-Seite mit gewissen Optionen gespeichert sein. Die UE kann die Informationen durch eine Funkressourcensteuerung-RRC-Signalisierung oder einen PUCCH zusammen mit SR senden. Das bedeutet, dass die Informationen zum Beispiel von einer UE-Seite eine Messung in einer bestimmten Zeitdauer sein können, die an eNB gesendet werden muss, oder eine vorhergehende Messung sein können, die auf einer eNB- und/oder einer UE-Seite gespeichert ist. Für den letztgenannten Fall ist zu beachten, dass die UE die Informationen nicht senden müssen kann, wenn z.B. diese nicht in dem Netzwerk gespeichert wurden.
-
Gemäß Ausführungsbeispielen der vorliegenden Anmeldung sind alternative Wege zum Konfigurieren einer Datenzeitplanungsanforderung DSR, einer temporären Zeitplanungsanforderung TSR und einer Zufalls- bzw. Direktzugriffskanal-Zeitplanungsanforderung RSR nachfolgend gezeigt.
- • Das Intervall von DSR und die ersten TSR-Gelegenheit werden durch eine angemessene Auswahl von drxTSR-startoffset definiert.
- • TSR wird zeitlich auf der ersten DSR-Gelegenheit + drxTSR-startoffset [ms] konfiguriert. Bei einigen Ausführungsbeispielen kann ein geeigneter drxTSR-startoffset-Parameter ungefähr 20 ms sein. Eine TSR-Ressource wird nach weiteren drxTSR-inactivityTimer ms automatisch freigegeben, wenn eine zugehörige Paketübertragung abgeschlossen ist. Bei einigen Ausführungsbeispielen kann eine numerischer Wert für drxTSR-inactivityTimer äquivalent zu drx-InactivityTimer sein, wie es in 3GPP 36.321 spezifiziert ist.
- • Konfigurierte TSR-Ressourcen können zur Verwendung durch andere UEs automatisch freigegeben werden, wenn während drxTSR-InactivityTimer keine Datenankunft erfolgt. Pakete, die nach einer TSR-Ressourcenfreigabe ankommen, können RSR verwenden.
-
Die vorstehend beschriebenen Verfahren können auch für einige MTC-Anwendungsfälle (MTC: "Machine-Type Communications") anwendbar sein. Einzelheiten und weitere Beispiele von alternativen Wegen sind in der Folge gezeigt.
-
Zum Beispiel ist in LTE die Zeitplanungseinrichtung in einer Basisstation eNB und der Medienzugriffssteuerung-MAC-Schicht platziert. Um die Benutzer im Uplink zeitlich einzuplanen, sendet die Zeitplanungseinrichtung Uplink-Bewilligungen auf dem PDCCH, die festlegen, welche Ressourcenblöcke RB und welches Transportformat zu verwenden sind.
-
In einem aktuellen System wird die SR basierend auf einem/einer zeitlich eingeplanten Zeitschlitz/-periode durch eine UE gesendet, falls eine Ressource verfügbar ist. Bei einigen Ausführungsbeispielen werden ein angemessener DRX und eine angemessene SR basierend auf datenunterstützten Informationen konfiguriert. Um die UL-Ressource einzusparen, kann es optimal sein, zwei DSR-Konfigurationen für eine Vorrichtung (z.B. eine Smartphone-EDDA-Vorrichtung) zu verwenden, zum Beispiel eine für eine längere DSR- und eine andere für eine kürzere DSR-Periode als TSR.
-
Bei einigen Ausführungsbeispielen kann die UE Durchschnittsdatengrößen- und Durchschnitts-IAT-Informationen an eine eNB senden, um der eNB zu helfen, eine angemessene längere DRX- und längere DSR-Konfiguration zu konfigurieren.
-
Zusammen mit den Durchschnittsdatengrößen- und Durchschnitts-IAT-Informationen, die durch die UE gesendet werden, kann ein Senden einer SR eine angemessene längere DRX- und längere DSR-Konfiguration in Erwiderung auf die SR-Anforderung ermöglichen, so dass ein angemessener DRX mit flexiblem drxStartoffset basierend auf einem Lernvorgang der Zeitplanungseinrichtung eingestellt werden kann.
-
Gemäß Ausführungsbeispielen sendet die UE in dem vorgenannten Lernvorgang einer Zeitplanungseinrichtung ihre gemessenen Anwendungsinformationen als Unterstützungsinformationen an die Zeitplanungseinrichtung der eNB, um die eNB zu triggern, angemessene Parameter an der UE einzuplanen bzw. festzulegen. Die UE kann die Anwendungsdatenübertragungscharakteristika messen, zum Beispiel die Durchschnittsdatengrößen- und Durchschnitts-IAT-Informationen innerhalb eines Zeitintervalls, und die gemessenen Informationen können an die eNB gesendet werden. Wenn die eNB diese gemessenen Datenpufferinformationen empfängt, kann die eNB einen angemessenen DRX-Zyklus und eine zugehörige angemessene SR-Konfiguration (wobei sich dies in dieser Schrift auf DSR bezieht) für die UE auswählen und derartige angemessene DRX und SR an der UE konfigurieren. Wenn das Paket an dem Datenpuffer ankommt, kann es die UE triggern, eine SR-Anforderung an die eNB zu senden, wenn die eNB diese SR empfängt, kann die eNB eine konfigurierte SR-Ressourcenkonfiguration freigeben bzw. aktivieren; andererseits, wenn es keine durch die UE gesendete SR-Anforderung gab, können die konfigurierten SR-Ressourcen für andere Verwendungen eingeplant bzw. festgelegt werden.
-
Bei einigen Ausführungsbeispielen kann eine zweite TSR-Konfiguration mit einer kurzen DSR-Konfiguration verwendet werden, um damit fertig zu werden, dass das Datenpaket in dem langen Intervall von zwei langen DSR-Gelegenheitszeiten ankommt, was als temporäre SR bezeichnet wird.
-
Im Folgenden sind unter Bezugnahme auf 5 bis 7 einige beispielhafte Wege gemäß Ausführungsbeispielen der vorliegenden Offenbarung zum Konfigurieren der Ressourcen von DSR, TSR und RSR gezeigt.
-
5 zeigt ein Schema eines Paketankunftstriggers gemäß Alternativverfahren 1, das ein Ausführungsbeispiel der vorliegenden Offenbarung zeigt.
-
Alternativverfahren 1: DSR + TSR + RSR
-
- • Das Intervall von DSR 51a, 51b, 51c und die erste TSR-Gelegenheit 52 werden durch eine angemessene Auswahl von drxTSR-startoffset 50 definiert. Dies kann ein neuer DRX-Parameter speziell für eine TSR-Konfiguration sein, so dass eine Datenankunft in dem Puffer eine der konfigurierten TSR triggert und gleichzeitig die UE zurück in einem aktiven Modus ist.
- • TSR wird zeitlich auf der ersten DSR-Gelegenheit + drxTSR-startoffset [ms] konfiguriert. Ein angemessener drxTSR-startoffset-Parameter kann zum Beispiel T [ms] sein. Daten, die vor einer konfigurierten TSR-Gelegenheit angekommen sind, werden in dem Datenpuffer warten müssen, bis eine TSR-Ressource verfügbar ist. Eine TSR-Ressource wird nach weiteren drxTSR-InactivityTimer [ms] automatisch freigegeben, wenn eine zugehörige Paketübertragung abgeschlossen ist. Der drxTSR-InactivityTimer ist ein weiterer neuer DRX-Parameter speziell für TSR. Bei einigen Ausführungsbeispielen kann ein numerischer Wert von drxTSR-InactivityTimer äquivalent zum drx-InactivityTimer sein, wie es in 3GPP 36.321 spezifiziert ist.
- • Eine konfigurierte TSR-Ressource kann zur Verwendung durch eine andere UE automatisch freigegeben werden, wenn während drxTSR-InactivityTimer keine Datenankunft erfolgt. Pakete, die nach einer TSR-Ressourcenfreigabe ankommen, können RSR 53 verwenden, wie es in 5 gezeigt ist.
-
6 zeigt ein weiteres Schema eines Paketankunftstriggers gemäß Alternativverfahren 2, das ein Ausführungsbeispiel der vorliegenden Offenbarung zeigt.
-
Alternativverfahren 2: DSR + TSR + RSR
-
- • Das Intervall von DSR 61a, 61b, 61c und die erste TSR-Gelegenheit 62 werden durch eine angemessene Auswahl eines bestehenden DRX-Parameters drx-InactivityTimer 60 definiert. So dass nach einer langen DRX- und/oder DSR-Gelegenheit (da diese identisch konfiguriert sind), und wenn ein anhängiger DSR vorliegt, die UE in einem aktiven Modus sein wird, bis drx-InactivityTimer fällig ist; dann wird die UE in einem Energiesparmodus sein.
- • Die TSR kann durch eine Datenankunft in dem Intervall von DSR ausgelöst werden, und die erste TSR-Gelegenheit und die TSR-Konfiguration liegen innerhalb eines Zeitfensters von drxTSR-InactivityTimer. Hier ist drxTSR-InactivityTimer ein neuer DRX-Parameter. Bei einigen Ausführungsbeispielen kann ein numerischer Wert der drxTSR-InactivityTimer-Optionen äquivalent zu bestehenden Datenfeldoptionen in drx-InactivityTimer sein, wie es in 3GPP36.321 spezifiziert ist. Das Netzwerk kann eine der Optionen als drxTSR-InactivityTimer auswählen, die größenmäßig nicht notwendigerweise gleich drx-InactivityTimer von DSR ist. Eine TSR-Ressource wird außerhalb des Fensters automatisch freigegeben. Eine Datenankunft jenseits des TSR-Fensters wird RACH (RSR 63) verwenden, um die SR zu senden, wie es in 6 gezeigt ist.
-
7 zeigt ein weiteres Schema eines Paketankunftstriggers gemäß Alternativverfahren 3, das ein Ausführungsbeispiel der vorliegenden Offenbarung zeigt.
-
Alternativverfahren 3: DSR + RSR
-
- • Eine weitere Alternative gegenüber Verfahren 1 besteht darin, dass in dem langen DRX/DSR-Intervall 71a, 71b, 71c, in dem angenommen wird, dass sich die UE in einem Energiesparmodus befindet, keine konfigurierte UL-SR-Ressource konfiguriert ist, und Pakete, die in dem Intervall ankommen, RACH verwenden müssen, um SR (RSR 72) zu senden und die UL-Bewilligung zu erhalten, wie es in 7 gezeigt ist.
- • Wenn SR unter Verwendung von RSR 72 ausgelöst wird, wird die UE aus dem Energiesparmodus zurück in einem aktiven Modus sein und dort bleiben, bis drxTSR-InactivityTimer 70 fällig ist.
-
Alternativverfahren 3 kann für eine Verkehrsanwendung geeignet sein, die mehr periodisch orientierte Merkmale aufweist, da es mit weniger SR-Ressource in einer UE konfiguriert ist; aber es muss einen Kompromiss mit mehr höherschichtiger Signalisierung erreichen, wenn plötzliche Paketankünfte zwischen langen DSR-Konfigurationen auftreten.
-
Alternativverfahren 1 und Verfahren 2 können für Verkehrsanwendungen mit mehr intermittierend orientierten Merkmalen geeignet sein, da sie mit mehr SR-Ressource (in TSR) in einer UE konfiguriert sind; aber sie weisen jeweils weniger höherschichtige Signalisierung auf, wenn plötzliche Paketankünfte zwischen langen DSR-Konfigurationen erfolgen.
-
8 zeigt ein Schema eines DRX-Zyklus gemäß 3GPP Release 8, TR 36.321, wenn ein DRX-Zyklus 83 in einen Ein-Dauer-Abschnitt 81 und einen eine Gelegenheit für DRX bietenden Abschnitt 82 unterteilt ist. Während des Ein-Dauer-Abschnitts 81 soll die UE den PDCCH überwachen.
-
Der drx-InactivityTimer spezifiziert die Anzahl von aufeinanderfolgenden PDCCH-Unterrahmen nach einer erfolgreichen Decodierung von einem PDCCH, der eine anfängliche UL- oder DL-Benutzerdatenübertragung für diese UE bezeichnet, was bedeutet, dass eine UE für eine InactivityTimer-Dauer in einem aktiven Modus bleiben kann, nachdem eine UE einen PDCCH empfängt, selbst wenn der DRX-Zyklus fällig ist.
-
Die Idee einer Verwendung von Durchschnittdatengrößen- und Durchschnitts-IAT-Informationen der in Puffern ankommenden Daten anstelle von einem Anwendungsfall kann eine im Verhältnis besser geeignete DRX-Konfiguration für eine UE erlangen. Noch wichtiger ist, dass, selbst wenn zu einer gewissen Zeit nur eine Anwendung auf einer Vorrichtung läuft, eine Verwendung von Durchschnittsdatengrößen- und Durchschnitts-IAT-Informationen der in Puffern ankommenden Daten eine gute DRX-Konfiguration zum Beispiel zu Zwecken einer Einsparung eines Energieverbrauchs bereitstellen kann.
-
Bei einigen Ausführungsbeispielen werden die RSR nach einer TSR-Ressourcenfreigabe zur Handhabung der in den unerwarteten Zeitdauern ankommenden Pakete verwendet. Da DRX und DSR basierend auf statistischen Informationen von Daten konfiguriert sind, z.B. unter Verwendung von Durchschnittsdatengrößen- und Durchschnitts-IAT-Informationen der in einem Puffer ankommenden Daten, kann erwartet werden, dass die DSR die meisten Paketübertragungen der UE handhabt. TSR kann verwendet werden, um die zweithäufigsten Paketübertragungen der UE zu handhaben. Und die RSR kann verwendet werden, um die Pakete außerhalb des Bereichs von DSR, TSR zu handhaben.
-
Ausführungsbeispiele der vorliegenden Offenbarung behandeln hauptsächlich Anwendungen mit nicht-periodischem Verkehr. Bei einigen Ausführungsbeispielen können die Durchschnittsdatengröße und die Durchschnittsdatenperiode oder die Durchschnittsintervallankunftszeit von Daten in einem Puffer verwendet werden, was von ein oder mehreren Anwendungen anwendbar sein kann, so dass eine eNB einen angemessenen DRX für die UE definieren kann. Die gemittelte Datengröße und die gemittelte Intervallankunftszeit sind nützliche Unterstützungsinformationen von einer UE. Wiefür einige der Anwendungen wie etwa intermittierende Anwendungen kann das kürzeste Nachrichtenintervall zu einer DRX-Konfiguration führen, die mehr UE-Leistung verbraucht.
-
Außerdem kann gemäß Ausführungsbeispielen der vorliegenden Offenbarung eine PUCCH-Ressourcenkonfiguration für eine Zeitplanungsanforderung (SR) gestaltet bzw. ausgelegt werden/sein.
-
Da Ausführungsbeispiele der vorliegenden Anwendung eine intermittierende Datenübertragung behandeln, können die hauptsächlich konfigurierten SR-(die sogenannten DSR-)Ressourcen nicht ausreichend sein. Um mit Daten fertig zu werden, die zwischen den konfigurierten SR-Ressourcen ankommen, werden bei Ausführungsbeispielen der vorliegenden Offenbarung temporäre SR und RACH-SR verwendet.
-
Die temporäre SR ist gestaltet bzw. ausgelegt, einer UE zu ermöglichen, ihre Daten in einer bestimmten Fensterlänge zu senden, in der die UE in einen aktiven Modus zurückgehen darf. Die Fensterlänge wird bei Ausführungsbeispielen der vorliegenden Offenbarung durch einen neuen DRX-Parameter definiert. Er kann derart gestaltet bzw. ausgelegt sein, dass, wenn Daten zwischen DSR und TSR, aber vor der Fensterlänge ankommen, die Daten in einem Puffer angesammelt werden können, bis die TSR-Ressource verfügbar ist und gesendet wird. Daten, die außerhalb des Fensters ankommen, würden RSR verwenden.
-
Bei einigen Ausführungsbeispielen kann der TSR-Parameter eine kurze Periode von SR sein, die aus rel.8/9 SR-Konfigurationen ausgewählt ist.
-
Gemäß Ausführungsbeispielen der vorliegenden Offenbarung werden das Intervall von DSR und die erste TSR-Gelegenheit durch eine angemessene Auswahl eines Zeitgebers T (z.B. T = 20 ms) definiert. Außerdem wird definiert, wie Ressourcen unter Verwendung von DSR, TSR und RSR zugewiesen werden.
-
Eine Kombination von DSR, TSR und RSR kann effiziente Zeitplanungsmechanismen bereitstellen, um die Pakete zu handhaben, die zu unerwarteten Zeiten ankommen. Da DRX und DSR basierend auf statistischen Informationen von Daten (z.B. unter Verwendung von Durchschnittsdatengrößen- und Durchschnitts-IAT-Informationen der in dem Puffer ankommenden Daten) konfiguriert sind, wird erwartet, dass die DSR die meisten Paketübertragungen der UE handhabt. TSR ist gestaltet bzw. ausgelegt, um die zweithäufigsten Paketübertragungen der UE zu handhaben, und RSR sollte verwendet werden, um die Pakete außerhalb des Bereichs von DSR, TSR zu handhaben.
-
Einige Ausführungsbeispiele sind basierend auf einem LTE-A-System beschrieben, aber Ausführungsbeispiele können auf andere Funkzugangstech nologien, wie etwa LTETM, WiFiTM, WLAN, UMTS, High Speed Packet Access HSPA angewandt werden, wenn eine vorrichtungsinterne Koexistenzbezeichnung vorgesehen ist.
-
Eine Vorrichtung kann eine Teilnehmervorrichtung, ein Endgerät, ein Mobiltelefon, einen Laptop, ein Smartphone, einen Tablet-PC oder eine beliebige andere Vorrichtung umfassen, die sich mit dem Mobilnetzwerk verbinden kann. Ein Netzwerkelement kann zum Beispiel ein NodeB, ein eNodeB oder eine beliebige andere Basisstation eines Funknetzwerks sein.
-
Wenn es nicht anderweitig angegeben ist oder aus dem Kontext anderweitig klar gemacht ist, bedeutet die Aussage, dass zwei Instanzen verschieden sind, dass sie in ihrem jeweiligen Netzwerk unterschiedlich adressiert sind/werden. Es bedeutet nicht notwendigerweise, dass sie auf unterschiedlicher Hardware beruhen. Das heißt, dass jede der in der vorliegenden Beschreibung beschriebenen Instanzen auf unterschiedlicher Hardware beruhen kann, oder einige oder alle der Instanzen auf der gleichen Hardware beruhen können.
-
Gemäß der vorliegenden Beschreibung sollte es daher ersichtlich sein, dass Ausführungsbeispiele der vorliegenden Erfindung zum Beispiel eine Steuerungsvorrichtung wie etwa eine Teilnehmervorrichtung, eine UE oder eine Komponente von dieser, eine Vorrichtung, die dieselbe verkörpert, ein Verfahren zum Steuern und/oder Betreiben derselben, sowie ein oder mehrere Computerprogramme, die dieselbe steuern und/oder betreiben, ebenso wie Medien, die ein oder mehrere derartige Computerprogramme tragen und ein oder mehrere Computerprogrammprodukte bilden, bereitstellen. Außerdem sollte somit ersichtlich sein, dass Ausführungsbeispiele der vorliegenden Offenbarung zum Beispiel eine Basisstationsvorrichtung wie etwa einen NodeB oder einen eNodeB oder eine Komponente von dieser, eine Vorrichtung, die dieselbe verkörpert, ein Verfahren zum Steuern und/oder Betreiben derselben, sowie ein oder mehrere Computerprogramme, die dieselbe steuern und/oder betreiben, ebenso wie Medien, die ein oder mehrere derartige Computerprogramme tragen und ein oder mehrere Computerprogrammprodukte bilden, bereitstellen.
-
Gemäß Ausführungsbeispielen der vorliegenden Offenbarung kann ein System eine beliebige denkbare Kombination der hiermit dargestellten Baugruppen/Vorrichtungen und anderer Netzwerkelemente aufweisen, die konfiguriert sind, mit einer beliebigen von diesen zusammenzuarbeiten.
-
Im Allgemeinen ist zu beachten, dass jeweilige Funktionsblöcke oder -elemente gemäß vorstehend beschriebenen Aspekten durch eine beliebige bekannte Einrichtung bzw. ein beliebiges bekanntes Mittel, entweder in Hardware und/oder Sofware/Firmware, jeweils implementiert werden können, wenn er oder es nur zum Durchführen der beschriebenen Funktionen der jeweiligen Teile angepasst ist. Die genannten Verfahrensschritte können in einzelnen Funktionsblöcken oder durch einzelne Baugruppen bzw. Vorrichtungen realisiert werden, oder ein oder mehrere der Verfahrensschritte können in einem einzigen Funktionsblock oder durch eine einzige Baugruppe bzw. Vorrichtung realisiert werden.
-
Im Allgemeinen kann sich jedes strukturelle Mittel, wie etwa ein Prozessor oder ein anderer Schaltkreis, auf eines oder mehreres des Folgenden beziehen: (a) reine Hardwareschaltungsimplementierungen (wie etwa Implementierungen in rein analogen und/oder digitalen Schaltkreisen) und (b) Kombinationen von Schaltungen und Software (und/oder Firmware), wie etwa (soweit zutreffend): (i) eine Kombination von einem oder mehreren Prozessoren oder (ii) Teile von einem oder mehreren Prozessoren bzw. Software (einschließlich eines oder mehrerer digitaler Signalprozessoren), Software und einem oder mehreren Speichern, die zusammenarbeiten, um eine Vorrichtung wie etwa ein Mobiltelefon oder einen Server zu veranlassen, verschiedene Funktionen durchzuführen, und (c) Schaltungen wie etwa ein oder mehrere Mikroprozessoren oder ein Teil von ein oder mehreren Mikroprozessoren, die Software oder Firmware zum Betrieb erfordern, selbst wenn die Software oder Firmware nicht physikalisch vorhanden ist. Auch kann eine Implementierung von lediglich einem Verarbeitungssystem oder einem Prozessor (oder mehrere Prozessoren) oder eines Teils eines Prozessors und dessen (oder deren) zugehöriger Software und/oder Firmware, eine beliebige integrierte Schaltung, oder dergleichen abgedeckt sein.
-
Im Allgemeinen ist jeder Verfahrensschritt oder jede Funktionalität geeignet, als Software/Firmware oder durch Hardware implementiert zu werden, ohne die Ideen der vorliegenden Offenbarung zu verändern. Eine solche Software kann softwarecodeunabhängig sein und unter Verwendung einer beliebigen bekannten oder zukünftig entwickelten Programmiersprache wie etwa z.B. Java, C++, C und Assembler spezifiziert sein, solange die durch die Verfahrensschritte definierte Funktionalität erhalten bleibt. Eine solche Hardware kann hardwaretypunabhängig sein und unter Verwendung einer beliebigen bekannten oder zukünftig entwickelten Hardwaretechnologie oder einer beliebigen Mischformen von diesen implementiert sein, wie etwas MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), usw., wobei zum Beispiel ASIC-(Application Specific IC (Integrated Circuit))Komponenten, FPGA-(Field-programmable Gate Arrays)Komponenten, CPLD-(Complex Programmable Logic Device)Komponenten oder DSP-(Digital Signal Processor)Komponenten verwendet werden. Eine Baugruppe bzw. Vorrichtung kann durch einen Halbleiterchip, einen Chipsatz oder ein (Hardware-)Modul mit einem solchen Chip oder Chipsatz dargestellt sein; dies schließt jedoch nicht die Möglichkeit aus, dass eine Funktionalität einer Baugruppe bzw. Vorrichtung oder eines Moduls, anstatt hardwareimplementiert zu sein, als Software in einem (Software-)Modul implementiert ist, wie etwa einem Computerprogramm oder einem Computerprogrammprodukt mit ausführbaren Softwarecodeteilen zur Ausführung bzw. zum Laufenlassen auf einem Prozessor. Eine Baugruppe bzw. Vorrichtung kann zum Beispiel als eine Baugruppe bzw. Vorrichtung oder als eine Zusammenstellung von mehr als einer Baugruppe bzw. Vorrichtung betrachtet werden, egal ob funktional in Zusammenwirkung miteinander oder funktional unabhängig von einander, aber in einem gleichen Gerätegehäuse.
-
Vorrichtungen und/oder Einrichtungen oder Teile von diesen können als individuelle Baugruppen implementiert werden, aber dies schließt nicht aus, dass sie in einer über das System hinweg verteilten Art und Weise implementiert werden, solange die Funktionalität der Baugruppe bzw. Vorrichtung erhalten bleibt. Derartige und ähnliche Prinzipien sind als für einen Fachmann bekannt zu betrachten.
-
Software im Sinne der vorliegenden Beschreibung umfasst Softwarecode als solches mit Codemitteln oder -teilen oder ein Computerprogramm oder ein Computerprogrammprodukt zum Durchführen der jeweiligen Funktionen, ebenso wie Software (oder ein Computerprogramm oder ein Computerprogrammprodukt), die auf einem dinglichen Medium wie etwa einem computerlesbaren (Speicher-)Medium verkörpert ist, das darauf eine jeweilige Datenstruktur oder Codemittel/ -teile gespeichert hat, oder in einem Signal oder in einem Chip verkörpert ist, möglicherweise während einer Verarbeitung davon.
-
Die vorliegende Offenbarung deckt auch jegliche denkbare Kombination von Verfahrensschritten und Vorgängen ab, die vorstehend beschrieben sind, sowie jegliche denkbare Kombination von Knoten, Vorrichtungen, Modulen oder Elementen, die vorstehend beschrieben sind, solange die vorstehend beschriebenen Konzepte der Methodik und der strukturellen Anordnung anwendbar sind.
-
Die vorgenannten Ausführungsbeispiele sind als veranschaulichende Beispiele zu verstehen. Weitere Ausführungsbeispiele sind vorgesehen. Es ist selbstverständlich, dass jedes Merkmal, das in Zusammenhang mit einem beliebigen Ausführungsbeispiel beschrieben ist, alleine oder in Kombination mit anderen beschriebenen Merkmalen verwendet werden kann, und auch in Kombination mit einem oder mehreren Merkmalen von einem beliebigen anderen der Ausführungsbeispiele oder einer beliebigen Kombination von einem beliebigen anderen der Ausführungsbeispiele verwendet werden kann. Außerdem können auch nicht beschriebene Äquivalente und Modifikationen eingesetzt werden, ohne von dem Umfang der Offenbarung abzuweichen, der in den begleitenden Patentansprüchen definiert ist.
-
Abkürzungsliste
-
-
- DL
- Downlink bzw. Abwärtsstrecke
- eNB
- Enhanced NodeB
- LTE
- Long Term Evolution
- LTE-A
- Long Term Evolution Advanced
- UE
- User Equipment bzw. Teilnehmervorrichtung
- UL
- Uplink bzw. Aufwärtsstrecke
- MAC
- Medium Access Control bzw. Medienzugriffssteuerung
- CE
- Control Element bzw. Steuerelement
- RF
- Radio Frequency bzw. Funkfrequenz
- UTRAN
- Universal Terrestrial Radio Access Network
- E-UTRAN
- Enhanced UTRAN
- TX
- Transmit bzw. Senden
- RX
- Receive bzw. Empfangen
- 3GPP
- Third Generation Partnership Project
- TS
- Technical Specification bzw. technische Spezifikation
- RRC
- Radio Resource Control bzw. Funkressourcensteuerung
- MAC
- Medium Access Vontrol bzw. Medienzugriffssteuerung
- RAN
- Radio Access Network bzw. Funkzugangsnetzwerk
- RAT
- Radio Access Technology bzw. Funkzugangstechnologie
- IE
- Information Element bzw. Informationselement
- MAC
- Media Access Control bzw. Medienzugriffssteuerung
- PDCCH
- Physical Downlink Control CHannel
- PRACH
- Physical Random Access CHannel
- PRB
- Physical Resource Block bzw. physikalischer Ressourcenblock
- PUCCH
- Physical Uplink Control CHannel
- PUSCH
- Physical Uplink Shared CHannel
- DSR
- Data Scheduling Request bzw. Datenzeitplanungsanforderung
- TSR
- Temporary Scheduling Request bzw. temporäre Zeitplanungsanforderung
- RSR
- RACH Scheduling Request bzw. RACH-Zeitplanungsanforderung
- IAT
- Interval Arrival Time bzw. Intervallankunftszeit