DE102016105971B3

DE102016105971B3 - Verfahren und Vorrichtung zum Berichten von "Drive Test"-Messungen an ein Mobilfunknetz

Info

Publication number: DE102016105971B3
Application number: DE102016105971.4A
Authority: DE
Inventors: Bismark Okyere; Mostafa Ahmed Hussien Ibrahiem; Islam Raouf; Shadi Iskander
Original assignee: Intel IP Corp
Current assignee: Apple Inc
Priority date: 2016-04-01
Filing date: 2016-04-01
Publication date: 2017-06-01
Anticipated expiration: 2036-04-02
Also published as: WO2017167533A1

Abstract

Ein Verfahren zum Berichten von „Drive Test”-Messungen an ein Mobilfunknetz enthält Folgendes: Ausführen von mehreren „Drive Test”-Messungen zum Sammeln von Daten des Mobilfunknetzes; Protokollieren eines Ergebnisses jeder „Drive Test”-Messung; Codieren der protokollierten „Drive Test”-Messergebnisse; Speichern der codierten protokollierten „Drive Test”-Messergebnisse in einer Datenbank; Erzeugen einer Informationsantwortnachricht, die wenigstens einen Teil der codierten protokollierten „Drive Test”-Messergebnisse aus der Datenbank umfasst; und Berichten der Informationsantwortnachricht an das Mobilfunknetz.

Description

Gebiet
Die Offenbarung bezieht sich auf ein Verfahren und eine Vorrichtung zum Berichten von „Drive Test”-Messungen an ein Mobilfunknetz, insbesondere Minimierung von „Drive Tests” (MDT) gemäß einer Mobilfunknetzspezifikation wie z. B. 3GPP. Insbesondere bezieht sich die Offenbarung auf protokollierte MDT-Messungstechniken.
Hintergrund
Die Minimierung von „Drive Tests” (MDT), die in den 1 und 2 gezeigt ist, ist ein 3GPP-Merkmal, um Mobilfunkbetreiber zu unterstützen, ihr Netz (NW) 110 zu optimieren durch Anweisen von UEs 120, die dieses Merkmal unterstützen, spezielle Messungen 102, 104 zu protokollieren und sie zu berichten 102, 106. MDT ist beispielsweise in 3GPP TR 36.805 „Study on Minimization of drive-tests in Next Generation Networks”, Version 9.0.0, Dezember 2009 und TS 37.320 Version 11.3.0 „Radio measurement collection for Minimization of Drive Tests (MDT)”, März 2013 spezifiziert. Dieses Merkmal erleichtert das Reduzieren der Komplexität und der Kosten einer NW-Optimierung für Netzbetreiber. In LTE ist MDT in eine unmittelbare MDT-Betriebsart 101 und eine protokollierte MDT-Betriebsart 103 unterteilt. Die unmittelbare MDT-Betriebsart 101 beinhaltet MDT-Messungen 102, die durch das LTE-UE 120 im RRC_CONNECTED-Zustand 107 ausgeführt und in diesem Zustand unmittelbar berichtet werden 102. Die protokollierte MDT-Betriebsart 103 beinhaltet MDT-Messungen 104, die durch das LTE-UE 120 in dem IDLE-Zustand 108 und dem verbundenen Zustand 107 protokolliert werden, falls durch das NW 110 konfiguriert, und zu einem späteren Zeitpunkt 105 an das NW 110 berichtet werden 106, wenn das NW 110 ihr Berichten anfordert.
Die Druckschrift US 2002/0 069 037 A1 beschreibt ein System und ein Verfahren zum Messen von Leistungsmetriken für drahtlose Geräte und Netze. Auf einem drahtlosen Gerät ist dazu eine Software zum Sammeln von Geräteparametern, Netzwerkparametern und Ereignisdaten installiert.
Die Druckschrift US 2013/0 324 120 A1 beschreibt ein Verfahren zum Hochladen von lokalen Operationsdaten eines mobilen Gerätes über Basisstationen an einen Anwendungsserver.
Die Druckschrift US 2012/0 214 504 A1 beschreibt ein System und ein Verfahren zum Erlangen von Netzwerkdaten.
Die Druckschrift US 2013/0 188 502 A1 beschreibt Techniken zur Analyse der Uplink-Bedeckung von Basisstationen eines drahtlosen Netzes basierend auf einer Aufzeichnung der Uplink Signalqualität in einem drahtlosen Gerät
Die Druckschrift US 2015/0 223 090 A1 beschreibt ”Drive Test” Messungen in mobilen Geräten zur Netzwerkoptimierung.
Die Druckschrift US 2014/0 113 656 A1 beschreibt ein Informationsbeschaffungsverfahren, bei dem ein mobiles Gerät Orte bestimmt, an denen es einen Bedarf an Datenkommunikation mit einem mobilen Kommunikationsnetz erkannt hat.
Die Druckschrift US 2013/0 053 017 A1 beschreibt ein Verfahren zur Minimierung von ”Drive Tests”, bei dem der Speicherbedarf zur Aufzeichnung der MDT-Messungen reduziert ist.
Aufgrund begrenzter Betriebsmittel in dem UE zum Ausführen von „Drive Test”-Messungen kann es wünschenswert sein, ein Konzept zum Optimieren von Speicherverbrauch von „Drive Test”-Messungen bereitzustellen.
Kurzbeschreibung der Zeichnungen
Die begleitenden Zeichnungen sind enthalten, um ein weiteres Verstehen der Aspekte bereitzustellen, und sind in diese Spezifikation aufgenommen und bilden einen Teil davon. Die Zeichnungen stellen Aspekte dar und dienen zusammen mit der Beschreibung dazu, Prinzipien von Aspekten zu erläutern. Andere Aspekte und viele der beabsichtigten Vorteile von Aspekten werden leicht erkannt, wenn sie durch Bezug auf die folgende ausführliche Beschreibung besser verstanden werden. Gleiche Bezugszeichen bezeichnen entsprechende ähnliche Teile.
1 ist ein schematisches Diagramm eines Mobilkommunikationssystems 100, das Minimierung von „Drive Test”-Messungen (MDT-Messungen) unterstützt.
2 ist ein Nachrichtenfolgediagramm 200, das Konfiguration und Berichten von protokollierten LTE-MDT-Messungen darstellt.
3 ist ein schematisches Diagramm, das ein beispielhaftes Verfahren 300 zum Berichten von „Drive Test”-Messungen an ein Mobilfunknetz gemäß der Offenbarung darstellt.
4 ist ein schematisches Diagramm, das eine beispielhafte Vorrichtung 400 zum Berichten von „Drive Test”-Messungen an ein Mobilfunknetz gemäß der Offenbarung darstellt.
5 ist ein schematisches Diagramm, das ein beispielhaftes Verfahren 500 zum Berichten von MDT-Messungen an ein Mobilfunknetz gemäß der Offenbarung darstellt.
6 ist ein schematisches Diagramm, das ein beispielhaftes Verfahren 600 zum Berichten von MDT-Messungen an ein Mobilfunknetz gemäß der Offenbarung darstellt.
7 ist ein schematisches Diagramm, das eine ASN.1-codierte MDT-Datenbank 700 gemäß der Offenbarung darstellt.
8 ist ein schematisches Diagramm, das eine beispielhafte Struktur einer Informationsantwortnachricht 800 gemäß einer ASN.1-Implementierung darstellt.
Ausführliche Beschreibung
In der folgenden ausführlichen Beschreibung wird auf die begleitenden Zeichnungen Bezug genommen, die einen Teil davon bilden und in denen durch Darstellung spezifische Aspekte gezeigt sind, in denen die Erfindung praktiziert werden kann. Es ist zu verstehen, dass andere Aspekte genutzt werden können und strukturelle oder logische Änderungen vorgenommen werden können, ohne von dem Schutzbereich der vorliegenden Erfindung abzuweichen. Die folgende genaue Beschreibung soll deshalb nicht in einem einschränkenden Sinn verstanden werden, und der Schutzbereich der vorliegenden Erfindung ist durch die beigefügten Ansprüche definiert.

Hier werden die folgenden Begriffe, Abkürzungen und Schreibweisen verwendet:

MDT:	Minimierung von „Drive Tests”
3GPP:	Partnerschaftsprojekt der 3. Generation
LTE:	Langzeitentwicklung (Long Term Evolution)
LTE-A:	LTE erweitert, Release 10 oder höhere Versionen von 3GPP LTE
RF:	Funkfrequenz
UE:	Anwendergerät
OFDM:	orthogonales Frequenzmultiplexen
NodeB, eNB:	Basisstation
RRC:	Funkbetriebsmittelsteuerung
RRC_CONNECTED:	verbundener Zustand des UE im LTE
IDLE,
RRC_IDLE:	Leerlaufzustand des UE in LTE
UL:	Aufwärtsstrecke
DL:	Abwärtsstrecke
PER:	Paketcodierungsregeln
DCCH:	dedizierter Steuerkanal
NW:	Netz
PDCP:	Paketdatenkonvergenzprotokoll
SU:	Diensteinheit
ASN.1	Abstrakte Syntaxnotation Eins
EUTRAN:	entwickeltes terrestrisches UMTS-Funkzugangsnetz

Verfahren und Vorrichtungen, die hier beschrieben sind, können in drahtlosen Kommunikationsnetzen implementiert sein, insbesondere Kommunikationsnetzen basierend auf Mobilkommunikationsstandards wie z. B. LTE, insbesondere LTE-A und/oder OFDM. Die nachstehend beschriebenen Verfahren und Vorrichtungen können ferner in einer Basisstation oder einem Mobilgerät (oder einer Mobilstation oder Anwendergerät (UE)) implementiert sein. Die beschriebenen Vorrichtungen können integrierte Schaltungen und/oder passive Elemente enthalten und können gemäß verschiedenen Technologien hergestellt sein. Beispielsweise können die Schaltungen als integrierte logische Schaltungen, integrierte analoge Schaltungen, integrierte Mischsignalschaltungen, optische Schaltungen, Speicherschaltungen und/oder integrierte passive Elemente konstruiert sein.
Die hier beschriebenen Verfahren und Vorrichtungen können konfiguriert sein, Funksignale zu senden und/oder zu empfangen. Funksignale können Funkfrequenzsignale sein oder enthalten, die durch eine Funksendevorrichtung (oder Funksender oder Sender) mit einer Funkfrequenz, die im Bereich von etwa 3 Hz bis 300 GHz liegen, abgestrahlt werden. Der Frequenzbereich kann Frequenzen von elektrischen Wechselstromsignalen entsprechen, die verwendet werden, um Funkwellen zu produzieren und zu detektieren.
Die Verfahren und Vorrichtungen, die hier nachstehend beschrieben sind, können in Übereinstimmung mit Mobilkommunikationsstandards wie z. B. dem Langzeitentwicklung-Standard (LTE-Standard) oder seiner erweiterten Version LTE-A konstruiert sein. LTE (Langzeitentwicklung), vermarktet als 4G, 5G, LTE und darüber hinaus, ist ein Standard für drahtlose Kommunikation von Hochgeschwindigkeitsdaten für mobile Telefone und Datenendgeräte.
Die hier nachstehend beschriebenen Verfahren und Vorrichtungen können in OFDM-Systemen angewandt sein. OFDM ist ein Schema zum Codieren digitaler Daten auf mehreren Trägerfrequenzen. Eine große Anzahl von orthogonalen Unterträgersignalen mit geringem Abstand können verwendet werden, um Daten zu übertragen. Aufgrund der Orthogonalität der Unterträger kann Übersprechen zwischen Unterträgern unterdrückt sein.
Die hier nachstehend beschriebenen Verfahren und Vorrichtungen können ASN.1-Syntax zum Codieren von Messergebnissen verwenden. Die Abstrakte Syntaxnotation Eins (ASN.1) ist ein Standard und eine Notation, die Regeln und Strukturen zum Repräsentieren, Codieren, Senden und Decodieren von Daten in Telekommunikations- und Computervernetzung beschreibt. Die formalen Regeln ermöglichen Repräsentation von Objekten, die von maschinenspezifischen Codierungstechniken unabhängig sind. Formale Notation ermöglicht es, die Aufgabe zum Validieren, ob eine spezifische Instanz der Datenrepräsentation die Spezifikationen einhält, zu automatisieren, d. h. Software-Werkzeuge können für die Validierung verwendet werden. ASN.1 ist ein gemeinsamer Standard der Internationalen Organisation für Standardisierung (ISO), der Internationalen Elektrotechnischen Kommission (IEC) und des Telekommunikationsstandardisierungssektors der Internationalen Telekommunikationsunion ITU-T. Die neueste Überarbeitung der X.680-Reihe für Empfehlungen ist die Ausgabe 5.0, veröffentlicht 2015. X.691 spezifiziert paketierte ASN.1-Codierungsregeln (ASN.1-PER).
Die hier beschriebenen Verfahren und Vorrichtungen können auf „Drive Test”-Messungen, insbesondere MDT-Messungen, basieren. „Drive Tests” werden zum Sammeln von Daten von Mobilfunknetzen verwendet. Diese Daten werden zur Konfiguration und Wartung von Mobilfunknetzen benötigt. Um „Drive Tests” auszuführen, kann jede Vorrichtung, die in dem Netz aktiv ist, verwendet werden. Dieses Konzept, das als „Minimierung von „Drive Test” (MDT)” bezeichnet wird, bedeutet, dass Standard-Mobilgeräte für Messungen verwendet werden, um Daten für die Betreiber bereitzustellen.
Die hier beschriebenen Verfahren und Vorrichtungen können auf MDT-Messungen basieren, insbesondere gemäß den Mobilkommunikationsspezifikationen 3GPP 36.300 und 3GPP 36.331. 3GPP schreibt vor, dass ein LTE-UE 120 eine minimale Größe von 64 KBytes zum Speichern der protokollierten MDT-Messungen 104 zuweist. Das Berichten 106 der protokollierten MDT-Messungen 104 an das NW 110 wird über UL-DCCH (UEInformationResponse) 106b RRC-Signalisierungsnachricht ausgeführt. 2 zeigt die Signalisierung zwischen dem UE 120 und dem Netz „EUTRAN” 110. Eine Konfigurationsnachricht DL-DCCH (Logged Measurement-Configuration) 103 von UE 120 zu EUTRAN 110 initiiert das Protokollieren 104 in dem UE 120. Nach dem Protokollieren 104 wird Berichten zwischen UE 120 und EUTRAN 110 über die Nachrichten UL-DCCH (UEInformationRequest) 106a und UL-DCCH (UEInformationResponse) 106b ausgeführt.
3GPP schreibt ein Minimum von 64 KBytes Speicherplatz für protokollierte MDT-Messungen vor. Unabhängig davon, ob ein OEM 64 KBytes oder mehr/weniger zuweist, erfordern diese Messungen einen sehr großen Speicherbedarf, und es ist erwünscht, die Menge zugewiesenen Speichers zu reduzieren, ohne den Wert/die Leistung zu reduzieren. Gemäß der Mobilkommunikationsspezifikation 3GPP 36.323 kann die PDCP-SDU des LTE-UE für entweder Steuerebene oder Datenebene 8188 Oktette nicht übersteigen. Die Anzahl von MDT-Messungen, die protokolliert werden sollen, kann gemäß der ASN.1-Beschreibung der 3GPP-Spezifikation 36.331 4060 Einträge nicht übersteigen (d. h. maxLogMeas-r10 INTEGER ::= 4060). Wieder und gemäß derselben vorstehenden 3GPP-Spezifikation kann ein einzelnes UL-DCCH (UEInformationResponse), das in der UL gesendet wird, nicht die Anzahl von Einträgen protokollierter MDT-Messungen aufweisen, die 520 übersteigt (d. h. maxLogMeasReport-r10 INTEGER ::= 520).
3GPP hat dazu geführt, dass die Datenbank, die verwendet werden soll, um die protokollierten MDT-Messungen zu speichern, erweiterbar ist. Protokollstack-Chipsatz-OEMs können jede gewünschte Datenbank verwenden. Aus Gründen der Vereinfachung erfordern jedoch die meisten protokollierten MDT-Implementierungen, dass die Messungen in einer Datenbank basierend auf C/C++-Datenstrukturen der entsprechenden MDT-ASN.1-IEs (MDT-ASN.1-Informationselemente) gespeichert sind. Diese Anforderungen zusammen mit den Beschränkungen, wie sie vorstehend beschrieben sind, begrenzen die Anzahl von Einträgen von MDT-Messungen, die protokolliert werden können. Dieser traditionelle Herangehensweise für die Datenbank ist im Speicher nicht optimal.
Es ist zu verstehen, dass Anmerkungen, die im Zusammenhang mit einem beschriebenen Verfahren gemacht werden, auch für eine entsprechende Vorrichtung gelten können, die konfiguriert ist, das Verfahren auszuführen, und umgekehrt. Falls beispielsweise ein spezifischer Verfahrensschritt beschrieben ist, kann eine entsprechende Vorrichtung eine Einheit enthalten, um den beschriebenen Verfahrensschritt auszuführen, selbst wenn eine solche Einheit nicht ausdrücklich beschrieben oder in den Figuren dargestellt ist. Ferner ist zu verstehen, dass die Merkmale der verschiedenen hier beschriebenen beispielhaften Aspekte miteinander kombiniert sein können, solange nicht spezifisch anders vermerkt.
3 ist ein schematisches Diagramm, das ein beispielhaftes Verfahren 300 zum Berichten von „Drive Test”-Messungen an ein Mobilfunknetz gemäß der Offenbarung darstellt.
Das Verfahren 300 enthält Ausführen 301 von mehreren „Drive Test”-Messungen zum Sammeln von Daten des Mobilfunknetzes; Protokollieren 302 eines Ergebnisses jeder „Drive Test”-Messung; Codieren 303 der protokollierten „Drive Test”-Messergebnisse; Speichern 304 der codierten protokollierten „Drive Test”-Messergebnisse in einer Datenbank; Erzeugen 305 einer Informationsantwortnachricht, die wenigstens einen Teil der codierten protokollierten „Drive Test”-Messergebnisse aus der Datenbank umfasst; und Berichten 306 der Informationsantwortnachricht an das Mobilfunknetz.
Die Informationsantwortnachricht kann basierend auf einer Wiederwendung wenigstens eines Teils der codierten protokollierten „Drive Test”-Messergebnisse, wie sie in der Datenbank gespeichert sind, erzeugt werden. Die Informationsantwortnachricht kann ohne weiteres Decodieren oder Codieren der codierten protokollierten „Drive Test”-Messergebnisse, wie sie in der Datenbank gespeichert sind, erzeugt werden.
Das Verfahren 300 kann ferner Ausführen der mehreren „Drive Test”-Messungen durch ein Anwendergerät (UE) enthalten. Das Verfahren 300 kann ferner Protokollieren der Ergebnisse der „Drive Test”-Messungen in einer Funkbetriebsmittelsteuerung-Leerlaufbetriebsart (RRC-Leerlaufbetriebsart) des UE enthalten, z. B. gemäß der technischen 3GPP-Spezifikation 36.331. Die Leerlaufbetriebsart ist der Zustand des UE, wenn keine RRC-Verbindung aufgebaut ist und das UE weiterhin Funktionen wie z. B. PLMN-Auswahl, Zellenauswahl und -neuauswahl, Empfang von Systeminformationen ausführt, um ihm zu ermöglichen, RRC-Verbindung für Signalisierung und Datenübertragung, z. B. PLMN-Auswahl, Zellenauswahl und -neuauswahl, Eintragen des Aufenthaltsorts, Empfang von Systeminformationen, aufzubauen und um dem UE zu ermöglichen, sowohl eine RRC-Verbindung für Signalisierung und Datenübertragung aufzubauen als auch imstande zu sein, mögliche ankommende Verbindungen über Paging zu empfangen. RRC-verbunden bedeutet den Fall, in dem das UE mit dem Netz verbunden ist.
Die mehreren „Drive Test”-Messungen können Messungen zur Minimierung von „Drive Tests” (MDT-Messungen) enthalten, z. B. gemäß 3GPP TR 36.805 „Study an Minimization of drive-tests in Next Generation Networks”, Version 9.0.0, Dezember 2009 und TS 37.320 Version 11.3.0 „Radio measurement collection for Minimization of Drive Tests (MDT)”, März 2013.
Die protokollierten „Drive Test”-Messergebnisse können gemäß einer Spezifikation der Abstrakten Syntaxnotation Eins (ASN.1-Spezifikation) und gemäß Paketcodierungsregeln für ASN.1, z. B. wie in der ITU-T-Spezifikation X.691 definiert, codiert sein. Alternativ können die protokollierten „Drive Test”-Messergebnisse durch Verwenden irgendeiner anderen Art von Codierer, beispielsweise eines Zip-Codierers oder eines Rar-Codierers, codiert sein.
Die codierten protokollierten „Drive Test”-Messergebnisse können basierend auf Paketcodierungsregeln (PER) gemäß der ASN.1-Spezifikation, z. B. wie in der ITU-T-Spezifikation X.691 definiert, komprimiert sein. Alternativ kann irgendeine andere Komprimierungstechnik verwendet werden, z. B. gemäß Zip oder Rar.
Das Verfahren 300 kann ferner Folgendes enthalten: Empfangen einer Messungskonfigurationsnachricht von dem Mobilfunknetz, z. B. einer DL-DCCH (LoggedMeasurementConfiguration) 103, wie vorstehend mit Bezug auf die 1 und 2 beschrieben; und Initiieren des Protokollierens der Ergebnisse der „Drive Test”-Messungen in Reaktion auf Empfangen der Konfigurationsnachricht für protokollierte Messung.
Das Verfahren 300 kann ferner Folgendes enthalten: Empfangen einer Informationsanforderungsnachricht von dem Mobilfunknetz, z. B. einer DL-DCCH (UEInformationRequest) 106a, wie vorstehend mit Bezug auf 2 beschrieben; und Erzeugen und Berichten der Informationsantwortnachricht, z. B. einer DL-DCCH (UEInformationResponse) 106b wie vorstehend mit Bezug auf 2 beschrieben, in Reaktion auf Empfangen der Informationsanforderungsnachricht 106a.
Das Verfahren 300 kann ferner Folgendes enthalten: Segmentieren der codierten protokollierten „Drive Test”-Messergebnisse in Segmentierungsblöcke; und Speichern der Segmentierungsblöcke in der Datenbank. Jede Größe von Segmentierungsblöcken kann angewandt sein.
Die Informationsantwortnachricht 106b kann ein vorbestimmtes Format aufweisen. Eine Größe jedes Segmentierungsblocks kann an dem Format der Informationsantwortnachricht ausgerichtet sein, z. B. ausgerichtet an Strukturen, z. B. C-Strukturen, die zum Definieren der Informationsantwortnachricht verwendet werden.
Das Verfahren 300 kann ferner Folgendes enthalten: Bestimmen einer Größe von Informationselementen (IEs), die sich nicht auf die „Drive Test”-Messungen beziehen, die in der Informationsantwortnachricht gespeichert werden sollen; und Füllen eines Bereichs der Informationsantwortnachricht, der zum Speichern von Informationselementen, die sich auf die „Drive Test”-Messungen beziehen, verbleibt, mit wenigstens einem Teil der Segmentierungsblöcke, die in der Datenbank gespeichert sind. Somit kann die Informationsantwortnachricht Informationselemente, die sich nicht auf „Drive Test”-Messungen beziehen, und Informationselemente, die sich auf „Drive Test”-Messungen beziehen, enthalten. Ein Format dieser IEs, die sich auf „Drive Test”-Messungen beziehen, kann mit Bezug auf seine ursprüngliche Definition aufgrund der Erzeugung der Informationsantwortnachricht basierend auf den codierten protokollierten „Drive Test”-Messergebnissen verändert werden.
Das Verfahren 300 kann ferner Folgendes enthalten: Anpassen einer Größe der Segmentierungsblöcke an den Bereich der Informationsantwortnachricht, der zum Speichern der Informationselemente, die sich auf die „Drive Test”-Messungen beziehen, verbleibt. Das bedeutet, dass die Informationsantwortnachricht effizient mit codierten protokollierten Messergebnissen gefüllt werden kann, ohne dass ein leerer Bereich bleibt.
Die Grenze auf der PDCP-PDU kann vordefiniert sein, und das führt eine Grenze dafür ein, wie groß die codierte Informationsantwortnachricht sein kann. Die Größe der Information bzw. Nachricht ist nicht vorbestimmt, kann jedoch durch einen Standard begrenzt sein. Die Größe der Segmentierungsblöcke kann basierend auf der Standardisierungsgrenze der Größe von Informationen bzw. Nachricht vorbestimmt sein.
Das Verfahren 300 kann ferner Folgendes enthalten: Erzeugen einer ASN.1-codierten Informationsantwortnachricht, die einen Platzhalterabschnitt protokollierter „Drive Test”-Messungs-Informationselemente umfasst; und Ersetzen des Platzhalterabschnitts durch wenigstens einen Teil der codierten protokollierten „Drive Test”-Messergebnisse.
Die ASN.1-codierte Informationsantwortnachricht kann ohne optionale Informationselemente und ohne Byte-Ausrichtung erzeugt werden. Solche optionalen Informationselemente und Byte-Ausrichtung können in den ASN.1-Strukturen definiert sein, diese Definitionen können jedoch nicht für die erzeugte ASN.1-codierte Informationsantwortnachricht gemäß dieser Offenbarung angewandt werden. Ferner können obligatorische Informationselemente der Informationsantwortnachricht eine minimale Anzahl von Elementen gemäß der ASN.1-Spezifikation aufweisen.
4 ist ein schematisches Diagramm, das eine beispielhafte Vorrichtung 400 zum Berichten von „Drive Test”-Messungen an ein Mobilfunknetz gemäß der Offenbarung darstellt.
Die Vorrichtung 400 enthält einen Sender/Empfänger 401, eine Datenprotokolliereinheit 402, einen Codierer 403, eine Datenbank 404, eine Steuereinheit 405 und eine Schnittstelle 406 zu dem Mobilfunknetz. Der Sender/Empfänger 401 ist konfiguriert, mehrere „Drive Test”-Messungen 410 zum Sammeln von Daten des Mobilfunknetzes auszuführen. Die Datenprotokolliereinheit 402 ist konfiguriert, ein Ergebnis 411 jeder „Drive Test”-Messung 410 zu protokollieren. Der Codierer 403 ist konfiguriert, die protokollierten „Drive Test”-Messergebnisse 411 in bereitgestellte codierte protokollierte „Drive Test”-Messergebnisse 412 zu codieren. Die Datenbank 404 ist konfiguriert, die codierten protokollierten „Drive Test”-Messergebnisse 412 zu speichern. Die Steuereinheit 405 konfiguriert, eine Informationsantwortnachricht 414 zu erzeugen, die wenigstens einen Teil der codierten protokollierten „Drive Test”-Messergebnisse 413 aus der Datenbank 404 umfasst. Die Schnittstelle 406 zu dem Mobilfunknetz ist konfiguriert, die Informationsantwortnachricht 414 an das Mobilfunknetz zu berichten 415. Die Informationsantwortnachricht 414 kann der Informationsantwortnachricht, wie sie vorstehend mit Bezug auf 3 beschrieben ist, oder der UEInformationResponseNachricht, wie sie nachstehend mit Bezug auf die 6 und 8 beschrieben ist, entsprechen.
Die Informationsantwortnachricht kann basierend auf einer Wiederwendung wenigstens eines Teils der codierten protokollierten „Drive Test”-Messergebnisse, wie sie in der Datenbank gespeichert sind, erzeugt werden. Die Informationsantwortnachricht kann ohne weiteres Decodieren oder Codieren der codierten protokollierten „Drive Test”-Messergebnisse, wie sie in der Datenbank gespeichert sind, erzeugt werden.
Der Codierer 403 kann konfiguriert sein, die protokollierten „Drive Test”-Messergebnisse 411 gemäß einer Spezifikation der Abstrakten Syntaxnotation Eins (ASN.1-Spezifikation) zu codieren, z. B. wie in der ITU-T-Spezifikation X.691 definiert ist. Alternativ kann der Codierer 403 die protokollierten „Drive Test”-Messergebnisse 411 durch Verwenden irgendeiner anderen Art von Codierer, beispielsweise eines Zip-Codierers oder eines Rar-Codierers, codieren.
Die Steuereinheit 405 kann konfiguriert sein, eine Informationsantwortnachricht zu erzeugen, die einen Platzhalterabschnitt der protokollierten „Drive Test”-Messungs-Informationselemente umfasst, z. B. wie nachstehend mit Bezug auf die 6 bis 8 beschrieben ist, um die Informationsantwortnachricht gemäß der ASN.1-Spezifikation zu codieren, und den Platzhalterabschnitt durch wenigstens einen Teil der codierten protokollierten „Drive Test”-Messergebnisse zu ersetzen, z. B. wie nachstehend mit Bezug auf die 6 bis 8 beschrieben ist.
Die Steuereinheit 405 kann konfiguriert sein, die Informationsantwortnachricht ohne optionale Informationselemente und ohne Byte-Ausrichtung zu erzeugen; und obligatorischen Informationselementen der Informationsantwortnachricht gemäß der ASN.1-Spezifikation eine minimale Anzahl von Elementen zuzuweisen, z. B. wie nachstehend mit Bezug auf die 6 bis 8 beschrieben ist.
5 ist ein schematisches Diagramm, das ein beispielhaftes Verfahren 500 zum Berichten von Minimalisierung von „Drive Test”-Messungen (MDT-Messungen) an ein Mobilfunknetz gemäß der Offenbarung darstellt.
Das Verfahren 500 enthält Folgendes: Ausführen 501 von mehreren MDT-Messungen zum Sammeln von Daten eines Mobilfunknetzes; Protokollieren 502 eines Ergebnisses jeder MDT-Messung; Codieren 503 der protokollierten MDT-Messergebnisse gemäß einer ASN.1-Spezifikation; Speichern 504 der codierten protokollierten MDT-Messergebnisse in einer Datenbank; Erzeugen 505 einer Informationsantwortnachricht gemäß der ASN.1-Spezifikation, wobei die Informationsantwortnachricht einen Platzhalterabschnitt von MDT-Messergebnissen umfasst; Codieren 506 der Informationsantwortnachricht gemäß der ASN.1-Spezifikation; Ersetzen 507 des Platzhalterabschnitts der MDT-Messergebnisse durch wenigstens einen Teil der codierten protokollierten MDT-Messergebnisse aus der Datenbank; und Berichten 508 der Informationsantwortnachricht an das Mobilfunknetz.
Die Messungen zur Minimierung von „Drive Test” (MDT-Messungen) können gemäß 3GPP TR 36.805 „Study an Minimization of drive-tests in Next Generation Networks”, Version 9.0.0, Dezember 2009 und TS 37.320 Version 11.3.0 „Radio measurement collection for Minimization of Drive Tests (MDT)”, März 2013 definiert sein.
Das Verfahren 500 kann ferner Folgendes enthalten: Empfangen einer Konfigurationsnachricht für protokollierte Messung von dem Mobilfunknetz, z. B. einer DL-DCCH (LoggedMeasurementConfiguration) 103, wie vorstehend mit Bezug auf die 1 und 2 beschrieben ist; und Initiieren des Protokollierens der Ergebnisse der MDT-Messungen in Reaktion auf Empfangen der Messungskonfigurationsnachricht.
Das Verfahren 500 kann ferner Folgendes enthalten: Empfangen einer Informationsanforderungsnachricht von dem Mobilfunknetz, z. B. einer DL-DCCH (UEInformationRequest) 106a, wie vorstehend mit Bezug auf 2 beschrieben ist; und Ersetzen des Platzhalterabschnitts und Berichten der Informationsantwortnachricht an das Mobilfunknetz in Reaktion auf Empfangen der Informationsanforderungsnachricht, z. B. einer Informationsantwortnachricht DL-DCCH (UEInformationResponse) 106b, wie vorstehend mit Bezug auf 2 beschrieben ist.
Das Verfahren 500 kann ferner Folgendes enthalten: Protokollieren der Ergebnisse der MDT-Messungen durch ein Anwendergerät (UE) in einer Funkbetriebsmittelsteuerungs-Leerlaufbetriebsart (RRC-Leerlaufbetriebsart) des UE, z. B. wie vorstehend mit Bezug auf 3 beschrieben ist.
6 ist ein schematisches Diagramm, das ein beispielhaftes Verfahren 600 zum optimalen Speichern von MDT-Messungen und effizienten Berichten dieser Messungen an ein Mobilfunknetz gemäß dieser Offenbarung darstellt. Das Verfahren 600 ist eine Implementierung des Verfahrens 300, wie vorstehend mit Bezug auf 3 beschrieben ist, und kann durch eine Vorrichtung 400 implementiert sein, wie vorstehend mit Bezug auf 4 beschrieben ist. Das Verfahren 600 kann auch als eine Implementierung des Verfahrens 500, wie es vorstehend mit Bezug auf 5 beschrieben ist, betrachtet werden.
Das Verfahren 600 startet mit einem ersten Block 601 „MDT-Messung ausführen”. In einem zweiten Block 602 „MDT LOG Meas ASN.1 (LogMeasInfo) auffüllen” werden Ergebnisse der MDT-Messung protokolliert. Diese Ergebnisse werden in einem achten Block „LOG MDT Meas (LogMeasInfo) ASN.1-codieren” 608 ASN.1-codiert und in einer Datenbank in einem zehnten Block 610 des Verfahrens 600 gespeichert 609. In einem dritten Block „LOG MDT Meas senden?” 603 wird eine Überprüfung ausführt, ob die protokollierten Messergebnisse zu dem Mobilfunknetz gesendet werden sollen. Falls die Antwort „Nein” ist, werden weitere MDT-Messungen durch Springen zu Block 601 ausgeführt. Falls die Antwort „Ja” ist, wird in einem vierten Block „UL-DCCH (UEInforationResponse) auffüllen” die Informationsantwortnachricht mit einigen Datenstrukturen gefüllt, z. B. Datenstrukturen wie sie durch ASN.1 definiert sind, die sich nicht direkt auf die MDT-Messungen beziehen. Das können Initialisierungswerte oder Parameter sein, die eine Messumgebung beschreiben, die für die jeweilige Messung gültig ist. In einem fünften Block „UL-DCCH (UEInformationResponse) ASN.1-codieren” wird die Informationsantwortnachricht, die die Parameter enthält, die durch Block 604 eingefüllt sind, gemäß ASN.1 codiert. Zusätzlich werden wenigstens ein Teil der codierten protokollierten „Drive Test”-Messergebnisse, wie sie in der Datenbank gespeichert sind, aus der Datenbank abgerufen und in die Informationsantwortnachricht aufgenommen. Das ist durch den Rahmen 611 „die Liste von Einträgen codierter LogMeasInfo in UEInformationResponse wiederverwenden” dargestellt.
In einem sechsten Block 606 wird ASN.1 auf einen Codierungsfehler überprüft. Falls ein solcher Codierungsfehler gefunden wird, „Ja”, kann ein Alarm erzeugt werden, oder die gesamte Messung oder wenigstens Teile davon können wiederholt werden (in 6 nicht abgebildet). Falls kein solcher Codierungsfehler gefunden wird, „Nein”, wird die Informationsantwortnachricht in dem siebten Block 607 „UL-DCCH (UEInformationResponse) senden” an das Netz gesendet.
Das Verfahren 600 stellt eine Datenbanklösung mit optimalem Speicher zum Speichern von MDT-Messungen bereit. Zu jeder Zeit kann eine MDT-Messung verfügbar sein, sie kann ASN.1-codiert sein, und der codierte Byte/Bit-Strom kann stattdessen gespeichert sein. Weil die ASN.1-codierten MDT-Messungen basierend auf paketierten Codierungsregeln (PER) komprimiert sein können, sind keine anderen Komprimierungsalgorithmen oder Werkzeuge erforderlich, und als ein Ergebnis kann das UE mehr Messungen speichern.
Das Verfahren 600 führt Wiederverwenden der ASN.1-codierten MDT-Messungseinträge in der Datenbank ohne Codieren und Neucodieren ein, um die UL-DCCH(UEInformationResponse)-Nachricht zu dem NW zu senden.
Die Datenbank kann für effizientes und effektives Handhaben von MDT-Protokollier- und Berichts-Beschränkungen in Bezug auf die Implementierungsbeschränkungen des UE konstruiert sein. Das Folgende sind die UE-Beschränkungen in Bezug auf Protokollieren und Berichten: 3GPP schreibt ein Minimum von 64 KBytes Speicherplatz für protokollierte MDT-Messungen vor. Unabhängig davon, ob ein OEM 64 KBytes oder mehr/weniger zuweist, erfordern diese Messungen einen sehr großen Speicherbedarf, und es ist erwünscht, die Menge zugewiesenen Speichers zu reduzieren, ohne den Wert/die Leistung zu reduzieren. Gemäß den 3GPP-Spezifikationen 36.323 kann die PDCP-SDU des LTE-UE für entweder Steuerebene oder Datenebene 8188 Oktette nicht übersteigen. Die Anzahl von MDT-Messungen, die protokolliert werden sollen, kann gemäß der ASN.1-Beschreibung der 3GPP-Spezifikation 36.331 4060 Einträge nicht übersteigen (d. h. maxLogMeas-r10 INTEGER ::= 4060). Wieder und gemäß derselben vorstehenden 3GPP-Spezifikation kann ein einzelner UL-DCCH (UEInformationResponse), der in der UL gesendet wird, nicht die Anzahl von Einträgen protokollierter MDT-Messungen aufweisen, die 520 übersteigt (d. h. maxLogMeasReport-r10 INTEGER ::= 520).
UL_DCCH (UEInformationResponse) kann MDT-IEs und andere IEs umfassen, und diese anderen IEs dienen anderen Zwecken. Die codierte Größe dieser 2 Gruppen von IEs sollte die PDCP-Größe von 8188 Bytes nicht übersteigen. Segmentieren der MDT-Messungen in handhabbare Blöcke und deren Speichern in einer MDT-Datenbank, wo jeder Block von der Größe der maximalen UEInformationResponse minus der Nicht-MDT-IEs ist, führt zur einfachen Zusammenstellung und Wiederverwenden der Inhalte der MDT-Datenbank. Es sind hier zwei Lösungen zum Bestimmen der Größte des Inhalts/Blocks der MDT-Datenbank, der in einer einzigen UL_DCCH(UEInformationResponse)-Nachricht gesendet werden kann, vorhanden: Die erste ist die folgende: Während der endgültigen Zusammenstellung und Codierung der UL_DCCH (UEInformationResponse) kann die codierte Größe der anderen IEs (nicht der MDT-IEs) bestimmt werden, und der übrige Bereich, um die PDCP-SDU-Größe von 8188 Bytes zu erfüllen, wird der Inhalt der MDT-Datenbank sein, der wiederverwendet werden soll. Die zweite ist die folgende: Die Größe eines Blocks in der MDT-Datenbank kann basierend auf einer vorbestimmten maximalen Größe der codierten UL_DCCH (UEInformationResponse) minus Nicht-MDT-IEs vorbestimmt sein. Es wurde bestimmt, dass 2 KB ausreichend sind, um die Größe von UL_DCCH (UEInformationResponse) zu handhaben, minus MDT-IEs, selbst falls neue IEs in zukünftigen 3GPP-Releases hinzugefügt werden. Das ergibt, dass ein Block in der MDT-Datenbank 6 KB ist.
Letzterer ist während der Zusammenstellung einfach zu handhaben und erleichtert das Wiederverwendungsverfahren, das nachstehend mit Bezug auf 8 in Einzelheiten beschrieben ist.
Es ist ein gewisser Grad des Effizienzverlust vorhanden, falls in einer einzelnen gesendeten UL_DCCH (UEInformationResponse) oberhalb 2 KB nicht vollständig durch die codierte Größe der anderen IEs (nicht der MDT-IEs) verbraucht ist. Durch Berücksichtigen, dass 3GPP keine Einschränkung darüber aufweist, wie viele UL_DCCH (UEInformationResponse) in der UL gesendet werden, um alle gespeicherten MDT-Messungen zu dem NW zu weiterzuleiten, wird dieser Effizienzverlust schließlich insignifikant, falls das NW anfordert, alle gespeicherten MDT-Messungen zu senden.
Das Verfahren 600 und die Vorrichtungen, die ein solches Verfahren 600 implementieren, stellen die folgenden Vorteile bereit: Eine speicheroptimale Datenbank basierend auf ASN.1-codierten protokollierten MDT-Messungen kann eingesetzt werden. Die ASN.1-codierte protokollierte MDT-Messung in der Datenbank kann effizient wiederverwendet werden, wenn UL-DCCH (UEInformationResponse) gesendet wird, ohne Decodieren und Neucodieren. Kein signifikanter temporärer Speicher wird zum Speichern einer dekomprimierten Kopie der Messungen, die gesendet werden sollen, benötigt. Die endgültige Nachricht kann einfach zusammengestellt werden, unabhängig davon, wie viel Platz für die zusätzlich angeforderten Informationen benötigt wird. Außerdem, und das gilt für andere Komprimierungsalgorithmen, kann das UE mehr protokollierte MDT-Messungen speichern, und dadurch werden Komplexität und Kosten für die NW-Optimierung reduziert. Während z. B. 64 KB Speicher nur einige 45 Messungen in unkomprimierter Form enthalten kann (z. B. in der C-Struktur), können einige 1700 Einträge in komprimiertem ASN.1-Format gespeichert werden. Eine speicheroptimale Datenbank basierend auf ASN.1-codierten MDT-Messungen, z. B. wie nachstehend mit Bezug auf 7 beschrieben ist, unter Berücksichtigung der MDT-Protokollier- und Berichtseinschränkungen wie vorstehend beschrieben, ermöglicht es, die Messergebnisse einfach in dem temporären Speicher in große Datenblöcke von einigen 6 K vorab zu segmentieren, und erfordert es nicht, Tausende von einzelnen enthaltenen Messungen zu verfolgen. Letzteres wäre notwendig, falls die Größe der Nachricht, die gesendet werden soll, zur Zeit des Sendens bestimmt würde.
7 ist ein schematisches Diagramm, das ein Beispiel einer ASN.1-codierten MDT-Datenbank 700 gemäß der Offenbarung darstellt. In diesem Beispiel kann die Datenbank 700 eine Speichergrößeneinschränkung aufweisen, die eine maximale Größe von 64 Kilobytes erlaubt. Die Datenbank 700 enthält mehrere Speicherblöcke 701, 702, 703, z. B. Blöcke von ASN.1-codierten protokollierten MDT-Messungseinträgen, die in einer einzelnen Nachricht UL-DCCH (UEInformationResponse) gesendet werden können. Die Größe jedes Speicherblocks j kann in diesem Beispiel bestimmt werden als: Größe(Block j) <= [GrÖße(PDP-SDU) – Größe(codierte UEInformationResponse ohne MDT-Messergebnisse]. Eine Gesamtzahl von MDT-Einträgen in einem einzelnen Block kann in diesem Beispiel kleiner als oder gleich 520 sein. Die Summe über alle Blöcke j kann in diesem Beispiel kleiner als oder gleich 64 KB sein. Eine Gesamtzahl von Einträgen in allen Blöcken kann in diesem Beispiel kleiner als oder gleich 4060 sein.
Diese Offenbarung adressiert die Tatsache, dass, um eine speicheroptimale protokollierte MDT-Datenbank basierend auf ASN.1-codierten MDT-Messungen einzusetzen, wie in 7 abgebildet ist, diese ASN.1-codierten Messungen effizient wiederverwendet werden können während der Codierung von UL-DCCH (UEInformationResponse) ohne Decodieren und Neucodieren, z. B. gemäß der vorstehenden Beschreibung von 6.
In den folgenden Abschnitten ist eine beispielhafte ASN.1-Implementierung beschrieben.
8 ist ein schematisches Diagramm, das eine beispielhafte Struktur einer Informationsantwortnachricht 800 gemäß einer ASN.1-Implementierung darstellt. Der Kürze halber sind nur die interessierenden relevanten Informationselemente (IEs) in 8 gezeigt.
Für weitere Einzelheiten über die Codierungsregeln ist eine Spezifikation zum Codieren von ASN.1 unter Verwendung von gepackten Codierungsregeln (PER) in der ITU-T-Spezifikation X.691 gegeben.
In der folgenden beispielhaften Implementierung liegt der Schwerpunkt auf protokollierten MDT-Messungen von LTE. 3GPP 36.331 beschreibt die Einzelheiten der ASN.1-Beschreibung zum Berichten der UL-DCCH (UEInformationResponse).
In 7, wie vorstehend beschrieben ist, kann jeder Block (nummeriert von 0 bis N) in der Datenbank weder Nummerneinträge von MDT-Messungen, die 520 übersteigen, aufweisen, noch kann seine Größe in Bytes die PDCP-SDU-Größe minus der Anzahl von Bytes codierter UL-DCCH (UEInformationResponse) ohne MDT-Messungen übersteigen.
Jeder MDT-Messungseintrag kann die ASN.1-codierten Bytes/Bits von LogMeasInfo-r10 IE sein. Die Codierung kann nicht Byte-ausgerichtet sein, d. h. keine Füllbits sind erforderlich.
Die folgenden Blöcke von Prozeduren skizzieren, wie diese ASN.1-codierten Einträge in der Datenbank in 7 wiederverwendet werden sollen, ohne weiteres Decodieren und Neucodieren, um UL-DCCH (UEInformationResponse) zu senden.
Block 1: Füllen und Codieren von UL-DCCH (UEInformationResponse):

1> Falls protokollierte MDT-Messungen zu dem NW gesendet werden müssen,
2> In dem UL-DCCH (UEInformationResponse) Füllen der Sub-IE logMeasInfoList-r10 (Liste von MDT-Messungen) des logMeasReport-r10 mit einigen Platzhalter- jedoch gültigen Informationen nach der ASN.1-Beschreibung – keine optionalen IEs sollten enthalten sein, und jede Liste sollte die minimale Standardanzahl von Elementen gemäß der ASN.1-Beschreibung verwenden.

Bemerkung 1: Die Anzahl von Bits des codierten logMeasInfo-List-r10 kann einfach bestimmt werden. Eine Verwendung der Standard- jedoch gültigen Werte für einen einzelnen Eintrag dieser Liste wird zu 77 Bits führen, falls codiert.

2> Verwenden des vorstehenden Platzhalters logMeasInfo-List-r10 IE in logMeasReport-r10 IE. Der Rest der Sub-IEs von logMeasReport-r10 muss korrekt gefüllt werden.
2> Aufnehmen von logMeasReport-r10 Sub-IE in nonCriticalExtension IE des Typs UEInformationResponse-v1020-IEs.
2> Falls entweder connEstFailReport-r11 oder nonCriticalExtension Sub-IEs oder beide in nonCriticalExtension Sub-IE in UEInformationResponse-v1020-IEs aufgenommen werden sollten.
3> Aufnehmen von nonCriticalExtension Sub-IE in UEInformationResponse-v1020-IEs, ABER 3> In diesem Sub-IE, vorerst Ausschließen von sowohl connEstFailReport-r11 als auch nonCriticalExtension Sub-IEs.

Bemerkung 2: Obwohl sowohl connEstFailReport-r11 als auch nonCriticalExtension Sub-IEs nicht in nonCriticalExtension des Typs UEInformationResponse-v1030-IEs enthalten sind, werden die Präambel-Bits (2 Bits) verfügbar sein.

2> Füllen jedes zweiten Sub-IE, das in UL-DCCH (UEInformationResponse) erforderlich ist, dementsprechend und korrekt.
2> Codieren von UL-DCCH (UEInformationResponse), jedoch keine Byte-Ausrichtung, d. h. kein Auffüllen.

Bemerkung 3: Die codierten Bits des Platzhalters logMeasInfoList-r10 plus der 2-Bit-Präambel der nonCriticalExtension des Typs UEInformationResponse-v1030-IEs, falls gefüllt, werden jetzt die Gesamtzahl von rechts stehenden Bits des codierten UL-DCCH (UEInformationResponse) bilden.
Block 2: Wiederverwenden der ASN.1-codierten Einträge von LogMeasInfo-r10 in der speicheroptimalen MDT-Datenbank:
Bemerkung 4: Aus der vorstehenden Schrittfolge ist jetzt ein ASN.1-codierter UL-DCCH (UEInformationResponse) mit protokollierten Platzhalter-MDT-Messungen verfügbar, und diese codierten Platzhalter-Bits können effizient durch den MDT-Datenbankinhalt ersetzt werden.

2> Falls nonCriticalExtension Sub-IE in UEInformationResponse-v1020-IEs gefüllt und codiert wurde 3> Entfernen von 2 Bits (die der Präambel für nonCriticalExtension des Typs UEInformationResponse-v1030-IEs entsprechen) von UL-DCCH(UEInformationResponse)-codierten Bits.
2> Entfernen der entsprechenden codierten Bits für das Platzhalter-logMeasInfoList-r10 Sub-IE von logMeasReport-r10 aus den verbleibenden codierten Bits von UL-DCCH (UEInformationResponse). Dieses sollten 77 Bits sein, wie berechnet.
2> Zählen in der speicheroptimierten MDT-Datenbank der Anzahl codierter Einträge von LogMeasInfo-r10 in einem einzelnen Block, der zu dem NW gesendet werden muss. Codieren dieser Anzahl unter Verwendung des PER-Codierungsschemas.

Bemerkung 5: Basierend auf der ASN.1-Beschreibung für maxLogMeasReport-r10 sind nur 10 Bits erforderlich, um die Anzahl von Einträgen in einem einzelnen Block in der MDT-Datenbank, der aktuell zu dem NW gesendet werden muss, zu codieren.

2> Anhängen der codierten 10 Bits (aus dem vorstehenden Schritt) an die am Ende abgeschnittenen codierten Bits von UL-DCCH (UEInformationResponse).
2> Jetzt Anhängen der entsprechenden Bits des Blocks von Einträgen von LogMeasInfo-r10 in der MDT-Datenbank, deren Gesamtheit vorstehend codiert wurde, an die codierten Bits von UL-DCCH (UEInformationResponse).

Bemerkung 6: Zu diesem Zeitpunkt sind die codierten Bits des Platzhalters logMeasInfoList-r10 exakt ersetzt durch die interessierenden codierten protokollierten MDT-Messeinträge in der speicheroptimalen MDT-Datenbank, ohne irgendeinen Verlust der Allgemeingültigkeit.
Block 3: Neuausrichten derjenigen IEs nach logMeasInfoList-r10:

2> Falls das unmittelbare Geschwister-Sub-IE von logMeasInfoList-r10 in UEInformationResponse-v1020-IEs, d. h. non-CriticalExtension des Typs UEInformationResponse-v1130-IEs, in UL-DCCH (UEInformationResponse) aufgenommen werden muss,
3> Codieren desselben unabhängig durch Aufnehmen seiner 2 Sub-IEs connEstFailReport-r11 und nonCriticalExtension, falls sie aufgenommen werden müssen. Die codierten Bits dürfen nicht Byte-ausgerichtet sein, d. h. keine Füllbits sind erforderlich.
3> Anhängen der vorstehenden codierten Bits an das codierte UL-DCCH (UEInformationResponse).

Bemerkung 7: Jetzt sind UL-DCCH (UEInformationResponse) codierte Bits vorhanden, die zu dem NW gesendet werden müssen.

2> Jetzt Sicherstellen, dass UL-DCCH (UEInformationResponse) codierte Bits Byte-ausgerichtet sind, d. h. geeignete Füllbits hinzufügen.
2> Senden in UL des UL-DCCH (UEInformationResponse).
2> Falls UL-DCCH (UEInformationResponse) erfolgreich zu dem NW gesendet ist, Entfernen des entsprechenden Blocks codierter protokollierter MDT-Messungen, der in dieser UL-Nachricht verwendet wurde, aus der MDT-Datenbank.

Bemerkung 8: Die gesamte Prozedur kann wiederholt werden, falls mehr codierte protokollierte MDT-Messungen in der MDT-Datenbank vorhanden sind und das NW ihr Berichten anfordern sollte.
Das Konzept der Wiederverwendung der komprimierten ASN.1-codierten MDT-Messungen in einer MDT-Datenbank während der endgültigen Zusammenstellung und Codierung von UL-DCCH (UEInformationResponse) kann auf UMTS-MDT (sowohl WCDMA als auch TD-SCDMA) erweitert werden. Die Schritte in dem vorstehenden Algorithmus werden jedoch unterschiedlich sein, da die UMTS-RRC-MDT-ASN.1-IEs-Beschreibungen von denen der LTE-RRC-MDT-ASN.1-IEs verschieden sind.
Implementierungsergebnisse sind wie folgt: Bei Verwenden der MDT-Datenbank-Herangehensweise ohne Verwenden des Konzepts gemäß dieser Offenbarung, falls jeder Eintrag die Ergebnisse von 3 GSM-Frequenzen + Dienstzellenergebnisse enthält, ohne irgendeine Ortsinformationen, speichert das UE ungefähr 45 Einträge (oder 45 MDT-Zyklen) in einem 64-KB-Speicher.
Bei Verwenden der Lösung gemäß dieser Offenbarung, mit denselben Messungsinformation in jedem Eintrag, kann das UE 1700+ Einträge (MDT-Zyklen) in demselben 64-KB-Speicher speichern.
Dieses Konzept protokollierter MDT gemäß der Offenbarung kann für MBMS (multicast broadcast measurements: Gruppenruf-Rundruf-Messungen) erweitert werden, selbst wenn das UE in dem RRC_CONNECTED-Zustand ist, und wird somit auch mehr Speicher von den UEs erfordern, das zusammen mit dem tatsächlichen Einsatz durch Betreiber, wird Anbieter zwingen, Mechanismen zu untersuchen, um zu optimieren, wie derjenige, der in diesem Dokument offenbart ist.
Die Verfahren, Systeme und Vorrichtungen, die hier beschrieben sind, können als Software in einem digitalen Signalprozessor (DSP), einer Mikro-Steuereinheit oder irgendeinem anderen Nebenprozessor oder als Hardware-Schaltung auf einem Chip oder innerhalb einer anwendungsspezifischen integrierten Schaltung (ASIC) implementiert sein.
Ausführungsformen, die in dieser Offenbarung beschrieben sind, können in digitaler elektronischer Schaltungsanordnung oder in Computer-Hardware, -Firmware, -Software oder in Kombinationen davon, z. B. in verfügbarer Hardware von mobilen Vorrichtungen oder in neuer Hardware, die zum Verarbeiten der hier beschriebenen Verfahren dediziert sind, implementiert sein.
Die vorliegende Offenbarung unterstützt auch ein Computerprogrammprodukt, das computerausführbaren Code oder computerausführbare Befehle enthält, die dann, wenn sie zum Ablauf gebracht werden, bewirken, dass wenigstens ein Computer das Ausführen und Berechnen von hier beschriebenen Blöcken ausführt, insbesondere die Verfahren 300, 500, 600, 700, die vorstehend mit Bezug auf die 3, 5, 6 und 7 beschrieben sind. Ein solches Computerprogrammprodukt kann ein lesbares Speichermedium enthalten, das darauf Programmcode zur Verwendung durch einen Prozessor speichert, wobei der Programmcode Befehle zum Ausführen irgendeines der Verfahrensblöcke 300, 500, 600, 700 wie vorstehend beschrieben umfasst.
Beispiele
Die folgenden Beispiele gehören zu weiteren Ausführungsformen. Beispiel 1 ist ein Verfahren zum Berichten von „Drive Test”-Messungen an ein Mobilfunknetz, wobei das Verfahren Folgendes umfasst: Ausführen von mehreren „Drive Test”-Messungen zum Sammeln von Daten des Mobilfunknetzes; Protokollieren eines Ergebnisses jeder „Drive Test”-Messung; Codieren der protokollierten „Drive Test”-Messergebnisse; Speichern der codierten protokollierten „Drive Test”-Messergebnisse in einer Datenbank; Erzeugen einer Informationsantwortnachricht, die wenigstens einen Teil der codierten protokollierten „Drive Test”-Messergebnisse aus der Datenbank umfasst; und Berichten der Informationsantwortnachricht an das Mobilfunknetz.
In Beispiel 2 kann der Gegenstand von Beispiel 1 optional Ausführen der mehreren „Drive Test”-Messungen durch ein Anwendergerät (UE) enthalten.
In Beispiel 3 kann der Gegenstand von Beispiel 2 optional Protokollieren der Ergebnisse der „Drive Test”-Messungen in einer Funkbetriebsmittelsteuerungs-Leerlaufbetriebsart (RRC-Leerlaufbetriebsart) des UE enthalten.
In Beispiel 4, kann der Gegenstand eines der Beispiele 1–3 optional enthalten, dass die mehreren „Drive Test”-Messungen Messungen zur Minimierung von „Drive Test” (MDT-Messungen) umfassen.
In Beispiel 5 kann der Gegenstand eines der Beispiele 1–4 optional enthalten, dass die protokollierten „Drive Test”-Messergebnisse gemäß einer Spezifikation der Abstrakte Syntaxnotation Eins (ASN.1-Spezifikation) codiert werden.
In Beispiel 6 kann der Gegenstand von Beispiel 5 optional enthalten, dass die codierten protokollierten „Drive Test”-Messergebnisse basierend auf Paketcodierungsregeln (PER) gemäß der ASN.1-Spezifikation komprimiert werden.
In Beispiel 7 kann der Gegenstand eines der Beispiele 1–6 optional Folgendes enthalten: Empfangen einer Messungskonfigurationsnachricht von dem Mobilfunknetz; und Initiieren des Protokollierens der Ergebnisse der „Drive Test”-Messungen in Reaktion auf Empfangen der Messungskonfigurationsnachricht.
In Beispiel 8 kann der Gegenstand eines der Beispiele 1–7 optional Folgendes enthalten: Empfangen einer Informationsanforderungsnachricht von dem Mobilfunknetz; und Erzeugen und Berichten der Informationsantwortnachricht in Reaktion auf Empfangen der Informationsanforderungsnachricht.
In Beispiel 9 kann der Gegenstand eines der Beispiele 1–8 optional Folgendes enthalten: Segmentieren der codierten protokollierten „Drive Test”-Messergebnisse in Segmentierungsblöcke; und Speichern der Segmentierungsblöcke in der Datenbank.
In Beispiel 10 kann der Gegenstand von Beispiel 9 optional enthalten, dass die Informationsantwortnachricht ein vorbestimmtes Format aufweist; und dass eine Größe jedes Segmentierungsblocks an dem Format der Informationsantwortnachricht ausgerichtet ist.
In Beispiel 11 kann der Gegenstand von Beispiel 10 optional Folgendes enthalten: Bestimmen einer Größe von Informationselementen, die sich nicht auf die „Drive Test”-Messungen beziehen, die in der Informationsantwortnachricht gespeichert werden sollen; und Füllen eines Bereichs der Informationsantwortnachricht, der zum Speichern von Informationselementen, die sich auf die „Drive Test”-Messungen beziehen, verbleibt, mit wenigstens einem Teil der Segmentierungsblöcke, die in der Datenbank gespeichert sind.
In Beispiel 12 kann der Gegenstand von Beispiel 11 optional Folgendes enthalten: Anpassen einer Größe der Segmentierungsblöcke an den Bereich der Informationsantwortnachricht, der zum Speichern der Informationselemente, die sich auf die „Drive Test”-Messungen beziehen, verbleibt.
In Beispiel 13 kann der Gegenstand eines der Beispiele 9–12 optional enthalten, dass eine maximale Größe der Informationsantwortnachricht vorbestimmt ist.
In Beispiel 14 kann der Gegenstand von Beispiel 13 optional enthalten, dass eine Größe der Segmentierungsblöcke basierend auf der vorbestimmten Größe der Informationsantwortnachricht vorbestimmt ist.
In Beispiel 15 kann der Gegenstand eines der Beispiele 1–14 optional Folgendes enthalten: Erzeugen einer ASN.1-codierten Informationsantwortnachricht, die einen Platzhalterabschnitt protokollierter „Drive Test”-Messungs-Informationselemente umfasst; und Ersetzen des Platzhalterabschnitts durch wenigstens einen Teil der codierten protokollierten „Drive Test”-Messergebnisse.
In Beispiel 16 kann der Gegenstand von Beispiel 15 optional enthalten, dass die ASN.1-codierte Informationsantwortnachricht ohne optionale Informationselemente und ohne Byte-Ausrichtung erzeugt wird; und dass obligatorische Informationselemente der Informationsantwortnachricht eine minimale Anzahl von Elementen gemäß der ASN.1-Spezifikation aufweisen.
Beispiel 17 ist eine Vorrichtung zum Berichten von „Drive Test”-Messungen an ein Mobilfunknetz, wobei die Vorrichtung Folgendes umfasst: einen Sender/Empfänger, der konfiguriert ist, mehrere „Drive Test”-Messungen zum Sammeln von Daten des Mobilfunknetzes auszuführen; eine Datenprotokolliereinheit, die konfiguriert ist, ein Ergebnis jeder „Drive Test”-Messung zu protokollieren; einen Codierer, der konfiguriert ist, die protokollierten „Drive Test”-Messergebnisse zu codieren; eine Datenbank, die konfiguriert ist, die codierten protokollierten „Drive Test”-Messergebnisse zu speichern; eine Steuereinheit, die konfiguriert ist, eine Informationsantwortnachricht, die wenigstens einen Teil der codierten protokollierten „Drive Test”-Messergebnisse aus der Datenbank umfasst, zu erzeugen; und eine Schnittstelle zu dem Mobilfunknetz, die konfiguriert ist, die Informationsantwortnachricht an das Mobilfunknetz zu berichten.
In Beispiel 18 kann der Gegenstand von Beispiel 17 optional enthalten, dass der Codierer konfiguriert ist, die protokollierten „Drive Test”-Messergebnisse gemäß einer Spezifikation der Abstrakten Syntaxnotation Eins (ASN.1-Spezifikation) zu codieren.
In Beispiel 19 kann der Gegenstand von Beispiel 18 optional enthalten, dass die Steuereinheit konfiguriert ist: eine Informationsantwortnachricht zu erzeugen, die einen Platzhalterabschnitt von protokollierten „Drive Test”-Messungsinformationselementen umfasst, die Informationsantwortnachricht gemäß der ASN.1-Spezifikation zu codieren und den Platzhalterabschnitt durch den wenigstens Teil der codierten protokollierten „Drive Test”-Messergebnisse zu ersetzen.
In Beispiel 20 kann der Gegenstand von Beispiel 19 optional enthalten, dass die Steuereinheit konfiguriert ist: die Informationsantwortnachricht ohne optionale Informationselemente und ohne Byte-Ausrichtung zu erzeugen; und obligatorischen Informationselementen der Informationsantwortnachricht eine minimale Anzahl von Elementen gemäß der ASN.1-Spezifikation zuzuweisen.
Beispiel 21 ist ein Verfahren zum Berichten von Messungen zur Minimierung von „Drive Test” (MDT-Messungen), wobei das Verfahren Folgendes umfasst: Ausführen von mehreren MDT-Messungen zum Sammeln von Daten eines Mobilfunknetzes; Protokollieren eines Ergebnisses jeder MDT-Messung; Codieren der protokollierten MDT-Messergebnisse gemäß einer ASN.1-Spezifikation; Speichern der codierten protokollierten MDT-Messergebnisse in einer Datenbank; Erzeugen einer Informationsantwortnachricht gemäß der ASN.1-Spezifikation, wobei die Informationsantwortnachricht einen Platzhalterabschnitt von MDT-Messergebnissen umfasst; Codieren der Informationsantwortnachricht gemäß der ASN.1-Spezifikation; Ersetzen des Platzhalterabschnitts der MDT-Messergebnisse durch wenigstens einen Teil der codierten protokollierten MDT-Messergebnisse aus der Datenbank; und Berichten der Informationsantwortnachricht an das Mobilfunknetz.
In Beispiel 22 kann der Gegenstand von Beispiel 21 optional Folgendes enthalten: Empfangen einer Messungskonfigurationsnachricht von dem Mobilfunknetz; und Initiieren des Protokollierens der Ergebnisse der MDT-Messungen in Reaktion auf Empfangen der Messungskonfigurationsnachricht.
In Beispiel 23 kann der Gegenstand von Beispiel 22 optional Folgendes enthalten: Empfangen einer Informationsanforderungsnachricht von dem Mobilfunknetz; und Ersetzen des Platzhalterabschnitts und Berichten der Informationsantwortnachricht an das Mobilfunknetz in Reaktion auf Empfangen der Informationsanforderungsnachricht.
In Beispiel 24 kann der Gegenstand eines der Beispiele 21–23 optional Folgendes enthalten: Protokollieren der Ergebnisse der MDT-Messungen durch ein Anwendergerät (UE) in einer Funkbetriebsmittelsteuerungs-Leerlaufbetriebsart (RRC-Leerlaufbetriebsart) des UE.
Beispiel 25 ist ein computerlesbares nichtflüchtiges Medium, auf dem Computer-Befehle gespeichert sind, die dann, wenn sie auf einem Computer ablaufen, bewirken, dass der Computer das Verfahren nach einem der Beispiele 1 bis 16 oder 21 bis 24 ausführt.
Beispiel 26 ist eine Vorrichtung zum Berichten von „Drive Test”-Messungen an ein Mobilfunknetz, wobei die Vorrichtung Folgendes umfasst: Mittel zum Ausführen von mehreren „Drive Test”-Messungen zum Sammeln von Daten des Mobilfunknetzes; Mittel zum Protokollieren eines Ergebnisses jeder „Drive Test”-Messung; Mittel zum Codieren der protokollierten „Drive Test”-Messergebnisse; Mittel zum Speichern der codierten protokollierten „Drive Test”-Messergebnisse in einer Datenbank; Mittel zum Erzeugen einer Informationsantwortnachricht, die wenigstens einen Teil der codierten protokollierten „Drive Test”-Messergebnisse aus der Datenbank umfasst; und Mittel zum Berichten der Informationsantwortnachricht an das Mobilfunknetz.
In Beispiel 27 kann der Gegenstand von Beispiel 26 optional Mittel zum Ausführen der mehreren „Drive Test”-Messungen durch ein Anwendergerät (UE) enthalten.
In Beispiel 28 kann der Gegenstand von Beispiel 27 optional Mittel zum Protokollieren der Ergebnisse der „Drive Test”-Messungen in einer Funkbetriebsmittelsteuerungs-Leerlaufbetriebsart (RRC-Leerlaufbetriebsart) des UE enthalten.
In Beispiel 29, kann der Gegenstand von Beispiel 26 oder 27 optional enthalten, dass die mehreren „Drive Test”-Messungen Messungen zur Minimierung von „Drive Test” (MDT-Messungen) umfassen.
Beispiel 30 ist eine Vorrichtung zum Berichten von Messungen zur Minimierung von „Drive Test” (MDT-Messungen), wobei die Vorrichtung Folgendes umfasst: Mittel zum Ausführen von mehreren MDT-Messungen zum Sammeln von Daten eines Mobilfunknetzes; Mittel zum Protokollieren eines Ergebnisses jeder MDT-Messung; Mittel zum Codieren der protokollierten MDT-Messergebnisse gemäß einer ASN.1-Spezifikation; Mittel zum Mittel zum Speichern der codierten protokollierten MDT-Messergebnisse in einer Datenbank; Mittel zum Erzeugen einer Informationsantwortnachricht gemäß der ASN.1-Spezifikation, wobei die Informationsantwortnachricht einen Platzhalterabschnitt von MDT-Messergebnissen umfasst; Mittel zum Codieren der Informationsantwortnachricht gemäß der ASN.1-Spezifikation; Mittel zum Ersetzen des Platzhalterabschnitts der MDT-Messergebnisse durch wenigstens einen Teil der codierten protokollierten MDT-Messergebnisse aus der Datenbank; und Mittel zum Berichten der Informationsantwortnachricht an das Mobilfunknetz.
In Beispiel 31 kann der Gegenstand von Beispiel 30 optional Mittel zum Empfangen einer Konfigurationsnachricht für protokollierte Messung von dem Mobilfunknetz; und Mittel zum Initiieren des Protokollierees der Ergebnisse der MDT-Messungen in Reaktion auf Empfangen der Messungskonfigurationsnachricht enthalten.
Beispiel 32 ist ein System zum Berichten von „Drive Test”-Messungen an ein Mobilfunknetz, wobei das System Folgendes umfasst: ein Sender/Empfänger-Teilsystem, das konfiguriert ist, mehrere „Drive Test”-Messungen zum Sammeln von Daten des Mobilfunknetzes auszuführen; ein Datenprotokolliereinheit-Teilsystem, das konfiguriert ist, ein Ergebnis jeder „Drive Test”-Messung zu protokollieren; ein Codierer-Teilsystem, das konfiguriert ist, die protokollierten „Drive Test”-Messergebnisse zu codieren; ein Datenbank-Teilsystem, das konfiguriert ist, die codierten protokollierten „Drive Test”-Messergebnisse zu speichern; ein Steuereinheit-Teilsystem, das konfiguriert ist, eine Informationsantwortnachricht, die wenigstens einen Teil der codierten protokollierten „Drive Test”-Messergebnisse aus der Datenbank umfasst, zu erzeugen; und eine Schnittstelle zu dem Mobilfunknetz, die konfiguriert ist, die Informationsantwortnachricht an das Mobilfunknetz zu berichten.
In Beispiel 33 kann der Gegenstand von Beispiel 32 optional enthalten, dass das Codieren-Teilsystem konfiguriert ist, die protokollierten „Drive Test”-Messergebnisse gemäß einer Spezifikation der Abstrakten Syntaxnotation Eins (ASN.1-Spezifikation) zu codieren.
Beispiel 34 ist ein System zum Berichten von Messungen zur Minimierung von „Drive Test” (MDT-Messungen), wobei das System Folgendes umfasst: ein Sender/Empfänger-Teilsystem, das konfiguriert ist, mehrere MDT-Messungen zum Sammeln von Daten eines Mobilfunknetzes auszuführen; ein Datenprotokollier-Teilsystem, das konfiguriert ist, ein Ergebnis jeder MDT-Messung zu protokollieren; ein Protokollcodierungs-Teilsystem, das konfiguriert ist, die protokollierten MDT-Messergebnisse gemäß einer ASN.1-Spezifikation zu codieren; ein Datenbank-Teilsystem, das konfiguriert ist, die codierten protokollierten MDT-Messergebnisse zu speichern; ein Nachrichtenhandhabungs-Teilsystem, das konfiguriert ist, eine Informationsantwortnachricht gemäß der ASN.1-Spezifikation zu erzeugen, wobei die Informationsantwortnachricht einen Platzhalterabschnitt von MDT-Messergebnissen umfasst; ein Nachrichtencodierungs-Teilsystem, das konfiguriert ist, die Informationsantwortnachricht gemäß der ASN.1-Spezifikation zu codieren; ein Ersetzungs-Teilsystem, das konfiguriert ist, den Platzhalterabschnitt der MDT-Messergebnisse durch wenigstens einen Teil der codierten protokollierten MDT-Messergebnisse aus dem Datenbank-Teilsystem zu ersetzen; und ein Berichts-Teilsystem, das konfiguriert ist, die Informationsantwortnachricht an das Mobilfunknetz zu berichten.
In Beispiel 35 kann der Gegenstand von Beispiel 34 optional Folgendes enthalten: ein Empfänger-Teilsystem, das konfiguriert ist, eine Messungskonfigurationsnachricht von dem Mobilfunknetz zu empfangen; und ein Initiierungs-Teilsystem, das konfiguriert ist, das Protokollieren der Ergebnisse der MDT-Messungen in Reaktion auf Empfangen der Konfigurationsnachricht für protokollierte Messung zu initiieren.
Beispiel 36 ist eine Schaltung zum Berichten von „Drive Test”-Messungen an ein Mobilfunknetz, wobei die Schaltung Folgendes umfasst: eine Sender/Empfänger-Schaltung, die konfiguriert ist, mehrere „Drive Test”-Messungen zum Sammeln von Daten des Mobilfunknetzes auszuführen; eine Datenprotokolliereinheit-Schaltung, die konfiguriert ist, ein Ergebnis jeder „Drive Test”-Messung zu protokollieren; eine Codierer-Schaltung, die konfiguriert ist, die protokollierten „Drive Test”-Messergebnisse zu codieren; eine Datenbank-Schaltung, die konfiguriert ist, die codierten protokollierten „Drive Test”-Messergebnisse zu speichern; eine Steuereinheit-Schaltung, die konfiguriert ist, eine Informationsantwortnachricht, die wenigstens einen Teil der codierten protokollierten „Drive Test”-Messergebnisse aus der Datenbank umfasst, zu erzeugen; und eine Schaltung für eine Schnittstelle zu dem Mobilfunknetz, die konfiguriert ist, die Informationsantwortnachricht an das Mobilfunknetz zu berichten.
In Beispiel 37 kann der Gegenstand von Beispiel 36 optional enthalten, dass die Codierer-Schaltung konfiguriert ist, die protokollierten „Drive Test”-Messergebnisse gemäß einer Spezifikation der Abstrakten Syntaxnotation Eins (ASN.1-Spezifikation) zu codieren.
In Beispiel 38 kann der Gegenstand von Beispiel 21 optional enthalten, dass das ASN.1-Codieren für die protokollierten MDT-Messergebnisse in der Datenbank und außerdem für die Informationsantwortnachricht verwendet wird.
In Beispiel 39 kann der Gegenstand von Beispiel 21 optional enthalten, dass die ASN.1-Codierung des protokollierten MDT-Messergebnisse, die in der Datenbank gespeichert werden sollen, nicht Byte-ausgerichtet ist.
In Beispiel 40 kann der Gegenstand von Beispiel 21 optional enthalten, dass das Codieren der Informationsantwortnachricht mit protokollierten Platzhalter-Messungen nicht Byteausgerichtet ist.
In Beispiel 41 kann der Gegenstand von Beispiel 21 optional enthalten, dass eine endgültige Zusammenstellung der codierten Informationsantwortnachricht mit den codierten protokollierten MDT-Messergebnissen in der Datenbank Byte-ausgerichtet ist.
Zusätzlich, obwohl ein spezielles/r Merkmal oder Aspekt der Erfindung in Bezug auf nur eine von mehreren Implementierungen offenbart worden sein kann, kann ein solches/r Merkmal oder Aspekt mit einem oder mehreren anderen Merkmalen oder Aspekten der anderen Implementierungen kombiniert sein, wie es für irgendeine gegebene oder spezielle Anwendung erwünscht und vorteilhaft sein kann. Darüber hinaus, in dem Umfang, in dem die Begriffe „enthalten”, „aufweisen”, „mit” oder andere Varianten davon entweder in der ausführlichen Beschreibung oder in den Ansprüchen verwendet sind, sind solche Begriffe vorgesehen, dass sie auf eine Weise ähnlich dem Begriff „umfassen” einschließend sein sollen. Darüber hinaus ist zu verstehen, dass Aspekte der Erfindung in diskreten Schaltungen, teilweise integrierten Schaltungen oder voll integrierten Schaltungen oder Programmiermitteln implementiert sein können. Außerdem sind die Begriffe „beispielhaft”, „zum Beispiel”, und „z. B.” lediglich als ein Beispiel gedacht, anstatt als das Beste oder Optimale.
Obwohl spezifische Aspekte hier dargestellt und beschrieben worden sind, ist durch normale Fachleute zu verstehen, dass eine Vielzahl alternativer und/oder äquivalenter Implementierungen für die spezifischen gezeigten und beschriebenen Aspekte eingesetzt werden können, ohne von dem Schutzbereich der vorliegenden Erfindung abzuweichen. Diese Anmeldung soll alle Anpassungen oder Variationen der hier diskutierten spezifischen Aspekte abdecken.

Claims

Verfahren zum Berichten von Messungen zur Minimierung von „Drive Test”(MDT)-Messungen, wobei das Verfahren umfasst: Ausführen von mehreren MDT-Messungen zum Sammeln von Daten des Mobilfunknetzes; Protokollieren eines Ergebnisses jeder MDT-Messung; Codieren der protokollierten MDT-Messergebnisse; Speichern der codierten protokollierten MDT-Messergebnisse in einer Datenbank; Erzeugen einer Informationsantwortnachricht, wobei die Informationsantwortnachricht einen Platzhalterabschnitt von MDT-Messergebnissen umfasst; Codieren der Informationsantwortnachricht; Ersetzen des Platzhalterabschnitts der MDT-Messergebnisse durch wenigstens einen Teil der codierten protokollierten MDT-Messergebnisse aus der Datenbank; und Berichten der Informationsantwortnachricht an das Mobilfunknetz.
Verfahren nach Anspruch 1, das umfasst: Ausführen der mehreren MDT-Messungen durch ein Anwendergerät (UE).
Verfahren nach Anspruch 2, das umfasst: Protokollieren der Ergebnisse der MDT-Messungen in einer Funkbetriebsmittelsteuerungs-Leerlaufbetriebsart (RRC-Leerlaufbetriebsart) und in einer RRC-Verbindungsbetriebsart des UE.
Verfahren nach Anspruch 1, das umfasst: Empfangen einer Konfigurationsnachricht für protokollierte Messung von dem Mobilfunknetz; und Initiieren des Protokollierens der Ergebnisse der MDT-Messungen in Reaktion auf Empfangen der Konfigurationsnachricht für protokollierte Messung.
Verfahren nach Anspruch 4, das umfasst: Empfangen einer Informationsanforderungsnachricht von dem Mobilfunknetz; und Ersetzen des Platzhalterabschnitts und Berichten der Informationsantwortnachricht an das Mobilfunknetz in Reaktion auf Empfangen der Informationsanforderungsnachricht.
Verfahren nach Anspruch 1, wobei die codierten protokollierten MDT-Messergebnisse basierend auf Paketcodierungsregeln (PER) gemäß der ASN.1-Spezifikation komprimiert sind.
Verfahren nach Anspruch 1 oder 2, das umfasst: Empfangen einer Konfigurationsnachricht für protokollierte Messung von dem Mobilfunknetz; und Initiieren des Protokollierens der Ergebnisse der MDT-Messungen in Reaktion auf Empfangen der Konfigurationsnachricht für protokollierte Messung.
Verfahren nach Anspruch 1 oder 2, das umfasst: Empfangen einer Informationsanforderungsnachricht von dem Mobilfunknetz; und Erzeugen und Berichten der Informationsantwortnachricht in Reaktion auf Empfangen der Informationsanforderungsnachricht.
Verfahren nach Anspruch 1 oder 2, das umfasst: Speichern der codierten protokollierten MDT-Messergebnisse in Segmentierungsblöcken in der Datenbank.
Verfahren nach Anspruch 9, wobei die Informationsantwortnachricht ein vorbestimmtes Format aufweist; und wobei eine Größe jedes Segmentierungsblocks an dem Format der Informationsantwortnachricht ausgerichtet ist.
Verfahren nach Anspruch 10, das umfasst: Bestimmen einer Größe von Informationselementen, die sich nicht auf die MDT-Messungen beziehen, die in der Informationsantwortnachricht gespeichert werden sollen; und Füllen eines Bereichs der Informationsantwortnachricht, der zum Speichern von Informationselementen, die sich auf die MDT-Messungen beziehen, verbleibt, mit wenigstens einem Teil der Segmentierungsblöcke, die in der Datenbank gespeichert sind.
Verfahren nach Anspruch 11, das umfasst: Anpassen einer Größe der Segmentierungsblöcke an den Bereich der Informationsantwortnachricht, der zum Speichern der Informationselemente, die sich auf die MDT-Messungen beziehen, verbleibt.
Verfahren nach Anspruch 9, wobei eine maximale Größe der Informationsantwortnachricht vorbestimmt ist.
Verfahren nach Anspruch 13, wobei eine Größe der Segmentierungsblöcke basierend auf der vorbestimmten Größe der Informationsantwortnachricht vorbestimmt ist.
Verfahren nach Anspruch 1, wobei die protokollierten „Drive Test”-Messergebnisse gemäß einer Spezifikation der Abstrakten Syntaxnotation Eins (ASN.1-Spezifikation) codiert sind.
Verfahren nach Anspruch 15, wobei die ASN.1-codierte Informationsantwortnachricht ohne optionale Informationselemente und ohne Byte-Ausrichtung erzeugt wird; und wobei obligatorische Informationselemente der Informationsantwortnachricht eine minimale Anzahl von Elementen gemäß der ASN.1-Spezifikation aufweisen.
Vorrichtung zum Berichten von Messungen zur Minimierung von „Drive Test”(MDT)-Messungen, wobei die Vorrichtung umfasst: einen Sender/Empfänger, der konfiguriert ist, mehrere MDT-Messungen zum Sammeln von Daten eines Mobilfunknetzes auszuführen; eine Datenprotokolliereinheit, die konfiguriert ist, ein Ergebnis jeder MDT-Messung zu protokollieren; ein Codierer, der konfiguriert ist, die protokollierten MDT-Messergebnisse zu codieren; eine Datenbank, die konfiguriert ist, die codierten protokollierten MDT-Messergebnisse zu speichern; eine Steuereinheit, die konfiguriert ist, eine Informationsantwortnachricht zu erzeugen, wobei die Informationsantwortnachricht einen Platzhalterabschnitt von MDT-Messergebnissen umfasst, ferner die Informationsantwortnachricht zu codieren und den Platzhalterabschnitts der MDT-Messergebnisse durch wenigstens einen Teil der codierten protokollierten MDT-Messergebnisse aus der Datenbank zu ersetzen; und eine Schnittstelle zu dem Mobilfunknetz, die konfiguriert ist, die Informationsantwortnachricht an das Mobilfunknetz zu berichten.
Vorrichtung nach Anspruch 17, wobei die Steuereinheit konfiguriert ist: die Informationsantwortnachricht ohne optionale Informationselemente und ohne Byte-Ausrichtung zu erzeugen; und obligatorischen Informationselementen der Informationsantwortnachricht eine minimale Anzahl von Elementen gemäß der ASN.1-Spezifikation zuzuweisen.
Computerlesbares nichtflüchtiges Medium, auf dem Computer-Befehle gespeichert sind, die dann, wenn sie auf einem Computer ablaufen, bewirken, dass der Computer das Verfahren nach einem der Ansprüche 1 bis 16 ausführt.