DE112013003200T5 - Ressourcenzuweisung - Google Patents

Ressourcenzuweisung Download PDF

Info

Publication number
DE112013003200T5
DE112013003200T5 DE112013003200.7T DE112013003200T DE112013003200T5 DE 112013003200 T5 DE112013003200 T5 DE 112013003200T5 DE 112013003200 T DE112013003200 T DE 112013003200T DE 112013003200 T5 DE112013003200 T5 DE 112013003200T5
Authority
DE
Germany
Prior art keywords
scheduling request
data
information
temporary
network element
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE112013003200.7T
Other languages
English (en)
Inventor
Jari Isokangas
Jianke Fan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Broadcom Corp
Original Assignee
Broadcom Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Broadcom Corp filed Critical Broadcom Corp
Publication of DE112013003200T5 publication Critical patent/DE112013003200T5/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/12Wireless traffic scheduling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W52/00Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02Power saving arrangements
    • H04W52/0209Power saving arrangements in terminal devices
    • H04W52/0212Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0216Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W52/00Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02Power saving arrangements
    • H04W52/0209Power saving arrangements in terminal devices
    • H04W52/0212Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/04Wireless resource allocation
    • H04W72/044Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446Resources in time domain, e.g. slots or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • H04W72/21Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/20Manipulation of established connections
    • H04W76/28Discontinuous transmission [DTX]; Discontinuous reception [DRX]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/12Wireless traffic scheduling
    • H04W72/1221Wireless traffic scheduling based on age of data to be sent
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/70Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Vorrichtungen, Verfahren, Computersoftware und Computerprogrammprodukte zum Verbessern von DRX- und Zeitplanungsanforderungskonfiguration für diverse Datenanwendungen. Mit Daten in einem Puffer in Zusammenhang stehende Informationen werden in einer Teilnehmervorrichtung bestimmt und an eine Basisstation übertragen. Die Basisstation stellt angemessenes DRX und ein Datenzeitplanungsanforderungs-Zeitintervall basierend darauf ein, und sie überträgt Datenzeitplanungsanforderungs-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs an die Teilnehmervorrichtung. Die Teilnehmervorrichtung überträgt eine Datenzeitplanungsanforderung an die Basisstation in dem empfangenen Datenzeitplanungsanforderungs-Zeitintervall.

Description

  • 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

Claims (42)

  1. Verfahren zur Verwendung bei diskontinuierlichem Empfang in einem Drahtloskommunikationsnetzwerk, 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-Zeitinvervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs von dem Netzwerkelement, wobei die empfangenen Datenzeitplanungsanforderung-Zeitintervall-Informationen auf den bestimmten Informationen basieren; und Bewirrken einer Übertragung einer Zeitplanungsanforderung an das Netzwerkelement in dem empfangenen Datenzeitplanungsanforderung-Zeitintervall.
  2. Verfahren gemäß Anspruch 1 zusätzlich mit: Empfangen von Temporärzeitplanungsanforderung-Zeitinformationen mit Temporärzeitplanungsanforderung-Startversatzinformationen von dem Netzwerkelement; und Bewirken einer Übertragung einer temporären Zeitplanungsanforderung an das Netzwerkelement nach Verstreichen des empfangenen Temporärzeitplanungsanforderung-Startversatzes ausgehend von einer Datenzeitplanungsanforderungszeit, falls Daten an das Netzwerkelement zu übertragen sind.
  3. Verfahren gemäß Anspruch 1 oder 2 zusätzlich mit: Empfangen von Temporärzeitplanungsanforderung-Inaktivitätszeitgeberinformationen von dem Netzwerkelement; Starten des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers nach Verstreichen des empfangenen Temporärzeitplanungsanforderung-Startversatzes ausgehend von der Datenzeitplanungsanforderungszeit; und Unterbinden einer Übertragung der temporären Zeitplanungsanforderung an das Netzwerkelement nach Verstreichen des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers.
  4. Verfahren gemäß einem der Ansprüche 1 bis 3 zusätzlich mit einem Bewirken einer Übertragung einer Direktzugriffskanal-Zeitplanungsanforderung an das Netzwerkelement, falls Daten an das Netzwerkelement zu übertragen sind, nach Verstreichen des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers und vor einer nachfolgenden Datenzeitplanungsanforderungszeit.
  5. Verfahren gemäß einem der Ansprüche 1 bis 4, wobei die Informationen, die mit Daten in dem Puffer in Zusammenhang stehen, durch eine Funkressourcensteuerungssignalisierung oder über einen physikalischen Uplink-Steuerkanal übertragen werden.
  6. Verfahren gemäß einem der Ansprüche 1 bis 5, wobei die Informationen, die mit Daten in dem Puffer in Zusammenhang stehen, zumindest Durchschnittsdatengrößeninformationen, Durchschnittsdatenperiodeninformationen und/oder Intervallankunftszeitinformationen von Daten in dem Puffer aufweisen.
  7. Verfahren gemäß Anspruch 6, wobei die Durchschnittsdatengrößeninformationen und Durchschnittsdatenperiodeninformationen und/oder Intervallankunftszeitinformationen von Daten in dem Puffer durch Messen einer Pufferaktivität während einer voreingestellten Zeit bestimmt werden.
  8. Verfahren gemäß einem der Ansprüche 2 bis 7, wobei der Temporärzeitplanungsanforderung-Startversatz auf 20 ms eingestellt ist.
  9. Verfahren gemäß einem der Ansprüche 3 bis 8, wobei der Wert des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers gleich dem Wert eines Inaktivitätszeitgebers für diskontinuierlichen Empfang eingestellt ist.
  10. Verfahren gemäß einem der Ansprüche 1 bis 9, wobei das Netzwerkelement eine Basisstation umfasst.
  11. Vorrichtung zur Verwendung bei diskontinuierlichem Empfang in einem Drahtloskommunikationsnetzwerk, 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-Zeitinvervall-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 Zeitplanungsanforderung an das Netzwerkelement in dem empfangenen Datenzeitplanungsanforderung-Zeitintervall.
  12. Vorrichtung gemäß Anspruch 11, wobei das Verarbeitungssystem ferner angepasst ist, die Vorrichtung zu veranlassen zum: Empfangen von Temporärzeitplanungsanforderung-Zeitinformationen mit Temporärzeitplanungsanforderung-Startversatzinformationen von dem Netzwerkelement; und Bewirken einer Übertragung einer temporären Zeitplanungsanforderung an das Netzwerkelement nach Verstreichen des empfangenen Temporärzeitplanungsanforderung-Startversatzes ausgehend von einer Datenzeitplanungsanforderungszeit, falls Daten an das Netzwerkelement zu übertragen sind.
  13. Vorrichtung gemäß Anspruch 11 oder 12, wobei das Verarbeitungssystem ferner angepasst ist, die Vorrichtung zu veranlassen zum: Empfangen von Temporärzeitplanungsanforderung-Inaktivitätszeitgeberinformationen von dem Netzwerkelement; Starten des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers nach Verstreichen des empfangenen Temporärzeitplanungsanforderung-Startversatzes ausgehend von der Datenzeitplanungsanforderungszeit; und Unterbinden einer Übertragung der temporären Zeitplanungsanforderung an das Netzwerkelement nach Verstreichen des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers.
  14. Vorrichtung gemäß einem der Ansprüche 11 bis 13, wobei das Verarbeitungssystem ferner angepasst ist, die Vorrichtung zu veranlassen zum Bewirken einer Übertragung einer Direktzugriffskanal-Zeitplanungsanforderung an das Netzwerkelement, falls Daten an das Netzwerkelement zu übertragen sind, nach Verstreichen des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers und vor einer nachfolgenden Datenzeitplanungsanforderungszeit.
  15. Vorrichtung gemäß einem der Ansprüche 11 bis 14, wobei die Informationen, die mit Daten in dem Puffer in Zusammenhang stehen, durch eine Funkressourcensteuerungssignalisierung oder über einen physikalischen Uplink-Steuerkanal übertragen werden.
  16. Vorrichtung gemäß einem der Ansprüche 11 bis 15, wobei die Informationen, die mit Daten in dem Puffer in Zusammenhang stehen, zumindest Durchschnittsdatengrößeninformationen, Durchschnittsdatenperiodeninformationen und/oder Intervallankunftszeitinformationen von Daten in dem Puffer aufweisen.
  17. Vorrichtung gemäß Anspruch 16, wobei die Durchschnittsdatengrößeninformationen und Durchschnittsdatenperiodeninformationen und/oder Intervallankunftszeitinformationen von Daten in dem Puffer durch Messen einer Pufferaktivität während einer voreingestellten Zeit bestimmt werden.
  18. Vorrichtung gemäß einem der Ansprüche 12 bis 17, wobei der Temporärzeitplanungsanforderung-Startversatz auf 20 ms eingestellt ist.
  19. Vorrichtung gemäß einem der Ansprüche 13 bis 18, wobei der Wert des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers gleich dem Wert eines Inaktivitätszeitgebers für diskontinuierlichen Empfang eingestellt ist.
  20. Vorrichtung gemäß einem der Ansprüche 11 bis 19, wobei das Netzwerkelement eine Basisstation umfasst.
  21. Vorrichtung gemäß einem der Ansprüche 11 bis 20, wobei die Vorrichtung in einer Teilnehmervorrichtung oder einem Mobiltelefon umfasst ist.
  22. Vorrichtung gemäß einem der Ansprüche 11 bis 21, wobei die Vorrichtung zu einem Long-Term-Evolution-System oder einem Long-Term-Evolution-Advanced-System gehört.
  23. Verfahren zur Verwendung bei diskontinuierlichem Empfang in einem Drahtloskommunikationsnetzwerk, 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 Datenzeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs an die Teilnehmervorrichtung.
  24. Verfahren gemäß Anspruch 23, zusätzlich mit: Einstellen eines Temporärzeitplanungsanforderung-Startversatzes; Bewirken einer Übertragung von Temporärzeitplanungsanforderung-Zeitinformationen mit Temporärzeitplanungsanforderung-Startversatzinformationen an die Teilnehmervorrichtung; und Einplanen von Ressourcen auf Empfang einer temporären Zeitplanungsanforderung von der Teilnehmervorrichtung nach Verstreichen des Temporärzeitplanungsanforderung-Startversatzes ausgehend von einer Datenzeitplanungsanforderungszeit.
  25. Verfahren gemäß Anspruch 23 oder 24, zusätzlich mit: Einstellen eines Temporärzeitplanungsanforderung-Inaktivitätszeitgebers; und Bewirken einer Übertragung von Temporärzeitplanungsanforderung-Inaktivitätszeitgeberinformationen an die Teilnehmervorrichtung.
  26. Verfahren gemäß einem der Ansprüche 23 bis 25, zusätzlich mit einem Einplanen von Ressourcen auf Empfang einer Direktzugriffskanal-Zeitplanungsanforderung von der Teilnehmervorrichtung nach Verstreichen des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers und vor einer nachfolgenden Datenzeitplanungsanforderungszeit.
  27. Verfahren gemäß einem der Ansprüche 23 bis 26, wobei die Informationen, die mit Daten in dem Puffer in Zusammenhang stehen, durch eine Funkressourcensteuerungssignalisierung oder über einen physikalischen Uplink-Steuerkanal empfangen werden.
  28. Verfahren gemäß einem der Ansprüche 23 bis 27, wobei die Informationen, die mit Daten in dem Puffer in Zusammenhang stehen, zumindest Durchschnittsdatengrößeninformationen, Durchschnittsdatenperiodeninformationen und/oder Intervallankunftszeitinformationen von Daten in dem Puffer aufweisen.
  29. Verfahren gemäß einem der Ansprüche 24 bis 28, wobei der Temporärzeitplanungsanforderung-Startversatz auf 20 ms eingestellt ist.
  30. Verfahren gemäß einem der Ansprüche 25 bis 29, wobei der Wert des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers gleich dem Wert eines Inaktivitätszeitgebers für diskontinuierlichen Empfang eingestellt ist.
  31. Vorrichtung zur Verwendung bei diskontinuierlichem Empfang in einem Drahtloskommunikationsnetzwerk, 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 Datenzeitplanungsanforderung-Zeitintervall-Informationen für eine Steuerung eines diskontinuierlichen Empfangs an die Teilnehmervorrichtung.
  32. Vorrichtung gemäß Anspruch 31, wobei das Verarbeitungssystem ferner angepasst ist, die Vorrichtung zu veranlassen zum: Einstellen eines Temporärzeitplanungsanforderung-Startversatzes; Bewirken einer Übertragung von Temporärzeitplanungsanforderung-Zeitinformationen mit Temporärzeitplanungsanforderung-Startversatzinformationen an die Teilnehmervorrichtung; und Einplanen von Ressourcen auf Empfang einer temporären Zeitplanungsanforderung von der Teilnehmervorrichtung nach Verstreichen des Temporärzeitplanungsanforderung-Startversatzes ausgehend von einer Datenzeitplanungsanforderungszeit.
  33. Vorrichtung gemäß Anspruch 31 oder 32, wobei das Verarbeitungssystem ferner angepasst ist, die Vorrichtung zu veranlassen zum: Einstellen eines Temporärzeitplanungsanforderung-Inaktivitätszeitgebers; und Bewirken einer Übertragung von Temporärzeitplanungsanforderung-Inaktivitätszeitgeberinformationen an die Teilnehmervorrichtung.
  34. Vorrichtung gemäß einem der Ansprüche 31 bis 33, wobei das Verarbeitungssystem ferner angepasst ist, die Vorrichtung zu veranlassen zum Einplanen von Ressourcen auf Empfang einer Direktzugriffskanal-Zeitplanungsanforderung von der Teilnehmervorrichtung nach Verstreichen des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers und vor einer nachfolgenden Datenzeitplanungsanforderungszeit.
  35. Vorrichtung gemäß einem der Ansprüche 31 bis 34, wobei die Informationen, die mit Daten in dem Puffer in Zusammenhang stehen, durch eine Funkressourcensteuerungssignalisierung oder über einen physikalischen Uplink-Steuerkanal empfangen werden.
  36. Vorrichtung gemäß einem der Ansprüche 31 bis 35, wobei die Informationen, die mit Daten in dem Puffer in Zusammenhang stehen, zumindest Durchschnittsdatengrößeninformationen, Durchschnittsdatenperiodeninformationen und/oder Intervallankunftszeitinformationen von Daten in dem Puffer aufweisen.
  37. Vorrichtung gemäß einem der Ansprüche 32 bis 36, wobei der Temporärzeitplanungsanforderung-Startversatz auf 20 ms eingestellt ist.
  38. Vorrichtung gemäß einem der Ansprüche 33 bis 37, wobei der Wert des Temporärzeitplanungsanforderung-Inaktivitätszeitgebers gleich dem Wert eines Inaktivitätszeitgebers für diskontinuierlichen Empfang eingestellt ist.
  39. Vorrichtung gemäß einem der Ansprüche 31 bis 38, wobei die Vorrichtung in einem Netzwerkelement oder einer Basisstation umfasst ist.
  40. Vorrichtung gemäß einem der Ansprüche 31 bis 39, wobei die Vorrichtung zu einem Long-Term-Evolution-System oder einem Long-Term-Evolution-Advanced-System gehört.
  41. Computersoftware, die angepasst ist zum Durchführen eines Verfahrens gemäß einem der Ansprüche 1 bis 10 oder 23 bis 30.
  42. Computerprogrammprodukt mit einem computerlesbaren Speichermedium mit darauf gespeicherten computerlesbaren Anweisungen, wobei die computerlesbaren Anweisungen durch eine computerbasierte Vorrichtung ausführbar sind, um die computerbasierte Vorrichtung zu veranlassen, ein Verfahren gemäß einem der Ansprüche 1 bis 10 oder 23 bis 30 durchzuführen.
DE112013003200.7T 2012-06-29 2013-06-28 Ressourcenzuweisung Withdrawn DE112013003200T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1211613.3A GB2503509A (en) 2012-06-29 2012-06-29 Data scheduling during discontinuous reception
GB1211613.3 2012-06-29
PCT/IB2013/055336 WO2014002075A2 (en) 2012-06-29 2013-06-28 Resource allocation

Publications (1)

Publication Number Publication Date
DE112013003200T5 true DE112013003200T5 (de) 2015-04-09

Family

ID=46721663

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112013003200.7T Withdrawn DE112013003200T5 (de) 2012-06-29 2013-06-28 Ressourcenzuweisung

Country Status (4)

Country Link
US (1) US20150163739A1 (de)
DE (1) DE112013003200T5 (de)
GB (1) GB2503509A (de)
WO (1) WO2014002075A2 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3042539B1 (de) * 2013-09-03 2018-11-07 Telefonaktiebolaget LM Ericsson (publ) Funkbasisstation und verfahren darin
CN106489293B (zh) * 2014-07-17 2019-12-10 瑞典爱立信有限公司 用于调度通信装置的方法和网络元件
EP3217700A4 (de) * 2014-11-06 2018-07-11 Ntt Docomo, Inc. Benutzerendgerät, drahtlose basisstation und drahtloskommunikationsverfahren
CN106793135A (zh) 2016-04-01 2017-05-31 北京展讯高科通信技术有限公司 通信资源调度方法、终端设备和基站设备
US10531384B2 (en) * 2016-04-05 2020-01-07 Qualcomm Incorporated Scheduling request collection after a discontinuous reception period
WO2018174807A1 (en) * 2017-03-24 2018-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Scheduling request handling with multiple configured ttis
EP3689044B1 (de) * 2017-09-29 2022-05-18 Telefonaktiebolaget LM Ericsson (Publ) Systeme und verfahren, die eine frühe standby-datenübertragungslösung bieten, die einen energiesparmodus ermöglicht
CN109600820B (zh) * 2017-09-30 2023-12-08 华为技术有限公司 一种数据传输方法、网络设备及终端设备
CN112136350B (zh) * 2018-05-11 2023-03-24 华为技术有限公司 资源配置方法及装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7916675B2 (en) * 2006-06-20 2011-03-29 Nokia Corporation Method and system for providing interim discontinuous reception/transmission
FI20085104A0 (fi) * 2008-02-06 2008-02-06 Nokia Corp Menetelmä ja järjestelmä epäjatkuvan vastaanoton/lähetyksen ohjaamiseksi
US8265682B2 (en) * 2008-03-18 2012-09-11 Texas Instruments Incorporated Scheduling request usage in DRX mode in wireless networks
JP2009296537A (ja) * 2008-06-09 2009-12-17 Fujitsu Ltd 無線リソース割当要求送信周期の制御方法
CN102474880B (zh) * 2009-06-29 2016-01-06 瑞典爱立信有限公司 无线通信***中的方法和布置
EP2474192B1 (de) * 2009-08-31 2019-01-16 Telefonaktiebolaget LM Ericsson (publ) Verfahren und anordnungen zur zuweisung von anfragekoordinationsressourcen in einem drahtlosen kommunikationssystem
WO2011025427A1 (en) * 2009-08-31 2011-03-03 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement in a wireless communication system
US8750224B2 (en) * 2011-09-26 2014-06-10 Nokia Corporation Preconfigured short scheduling request cycle
JP6167166B2 (ja) * 2012-03-23 2017-07-26 聯發科技股▲ふん▼有限公司Mediatek Inc. 移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法

Also Published As

Publication number Publication date
WO2014002075A3 (en) 2014-03-20
GB201211613D0 (en) 2012-08-15
US20150163739A1 (en) 2015-06-11
GB2503509A (en) 2014-01-01
WO2014002075A2 (en) 2014-01-03

Similar Documents

Publication Publication Date Title
DE112013003200T5 (de) Ressourcenzuweisung
DE102015206888B4 (de) Deterministische RRC-Verbindungen
DE102015222734B4 (de) Anwendungsbezogene Lösung zur Koexistenz mehrerer drahtloser Funkzugangstechnologien und Timesharing zwischen mehreren Funkzugangstechnologien zur Koexistenz im Gerät
DE112013002434B4 (de) Verfahren und Vorrichtung zur Erkennung und Abschwächung einer Interferenz aufgrund einer Koexistenz innerhalb der Vorrichtung
DE102015017294B3 (de) System und Verfahren für Niedrigenergiesignalisierung in einem Wireless Local Area Network
DE102015215345B4 (de) Funkzugangstechnologie mit diskontinuierlicher und periodischer pusch-übertragung
DE102015206889A1 (de) Verzögerung von Übertragungen von Anwendungsdaten basierend auf einer Netzwerkbelastung
DE102015206976A1 (de) Koordination zwischen Anwendungs- und Basisbandschicht-Betrieb
DE112013000242T5 (de) Betrieb mit verschiedenen Zeitgebern in einem drahtlosen Kommunikationssystem
DE112014004464B4 (de) System und Verfahren zur selektiven Verhinderung der Übertragung einer Scheduling-Anforderung
EP3154299B1 (de) Verfahren und vorrichtung zur gewinnung von uplink-ressourcen
DE102010036590B4 (de) Verfahren zum Koordinieren von Sende- und Empfangs-Betriebsvorgängen von Funkmodulen in einem Kommunikations-Gerät und Kommunikations-Gerät dafür
DE102015202500A1 (de) System und Verfahren zum Drosseln einer Carrier-Aggregation-Aktivierung
DE112013004578B4 (de) DRX-Betrieb in einem drahtlosen Kommunikationssystem
DE102012112278B4 (de) Optimierung des Daten-Handovers zu Wireless Wide Area Networks
HUE029945T2 (en) Reduced signaling over radio resource control (RRC) status transitions
DE102016206944B4 (de) Verwendung von Basisband-Triggern zum Verschmelzen von Anwendungsdatenaktivität
DE112013007545B4 (de) Leistungsoptimierung für Benutzereinrichtung
DE112012007166T5 (de) Verfahren und Vorrichtungen für einen diskontinuierlichen Empfang
DE112017002926T5 (de) Adaptiver Durchsatz und Bandbreite für eine verbesserte Kategorie von mobilen Vorrichtungen
DE102014200013A1 (de) Verfahren und Gerät für eine erweiterte Steuerungssignalisierung in einem LTE-Netzwerk
DE102015009779B4 (de) Leistungsoptimierung für Kanalzustandsmeldungen in einem drahtlosen Kommunikationsnetz
DE102016200617B4 (de) Optimierung eines Betriebs einer eingeschränkten Benutzerausrüstung
DE102016207025B4 (de) Verschmelzende Anwendungsdatenaktivitäten von mehreren Anwendungen
DE202017105525U1 (de) Kleinzellige thermische Steuerung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: BOSCH JEHLE PATENTANWALTSGESELLSCHAFT MBH, DE

R016 Response to examination communication
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04W0076040000

Ipc: H04W0076200000

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee