Üblicherweise sind die Funktions- und die Performance-Prüfung zwei voneinander unabhängige Teile des Verfahrens zur Protokoll- und Systemverifikation. Das Scheduling wird in der Regel im Rahmen der Funktionsprüfung betrachtet, dabei ist diese Funktion von entscheidender Bedeutung für die Performance bzw. des Datendurchsatzes. »Bei den herkömmlichen Funktionsprüfverfahren entstehen riesige Protokolldateien, so genannte Logs, weil die Scheduler-Software für jedes TTI Input erhält und Entscheidungen trifft«, führt Reyes aus. »Daraus folgt, dass die Log-Analyse mühsam und zeitaufwändig ist – und daher unterbleibt. Stattdessen wird die Link Adaptation meist im Rahmen einfacher aber eingeschränkter Konfigurationen geprüft, die nicht annähernd alle realen Anwendungsfälle erfassen.«
Die Performance-Prüfung der Link Adaptation besteht in einer Messung des Datendurchsatzes. Und weil die Funktionsprüfung der Link Adaptation Einschränkungen unterliegt, muss die volle Verifikation der Funktion bis zu den Performance-Prüfungen warten – die in einer späteren Phase des Entwicklungsprojekts stattfinden. »Sehr oft hängen Performance-Probleme des Link-Adaptation-Verfahrens mit Funktionsfehlern zusammen«, so Reyes. »Werden diese Probleme beim Performance-Test erkannt, muss die Funktionalität korrigiert werden – und das kann eine teilweise Überarbeitung des Geräte-Designs und die Wiederholung einzelner Verifikationsmaßnahmen bedeuten.« Korrekte und präzise Daten aus der Performance-Prüfung seien daher eine wertvolle Quelle, die dem Entwickler eine zielgerichtete Fehlerkorrektur und Nachprüfung ermögliche.
»Leider liefern die heutzutage üblichen Performance-Prüfanordnungen nur sehr ungenaue Ergebnisse«, fährt der Experte fort. »Sie bestehen aus einer Server-Anwendung, die auf einem PC oder einer Unix-Workstation läuft, und einer Client-Anwendung auf einem Einwahl-PC. Die Server- und Client-Anwendungen implementieren das Datenkommunikationsprotokoll, führen die Messungen durch und liefern das Ergebnis. Das Problem dabei ist, dass Windows- oder Unix-Betriebssysteme in der Regel eine Timing-Genauigkeit von etwa 500 ms liefern. Zwar stimmt es, dass die tatsächliche Paketübertragung in Windows-Anwendungen normalerweise mittels NDIS-Technologie realisiert wird, die eine bessere Timing-Genauigkeit als Windows selbst liefert – aber die Messung dieser Übertragungen ist betriebssystemabhängig.« Und selbst diese grobe Timing-Genauigkeit, im Bereich mehrerer hundert Millisekunden, werde von den Betriebssystem- bzw. Rechnerherstellern nicht garantiert. Weil LTE (und einige Konfigurationen von HSPA und HSPA+) ein TTI von 1 ms haben, kann eine Windows-basierte Anwendung nach Reyes’ Überzeugung höchstens einen annähernden Durchsatzwert auf einer Anwendungsebene des OSI-Stapels liefern. Genaue Daten zur Ortung von funktionalen Problemen auf TTI-Ebene stünden einfach nicht zur Verfügung.
Welche Art von Daten man für die Fehlersuche im Fall von Durchsatzproblemen benötigt, kann man am besten an einer vereinfachten Darstellung erkennen. »Nehmen wir einen IP-Datenstrom, der über eine Basisstation übermittelt wird«, erklärt Reyes. »Beim Link-Adaptation-Verfahren verwendet der Scheduler die größte und kleinste verfügbare Blockgröße; in jeder Größe wird die gleiche Anzahl Blöcke gesendet. Wenn wir davon ausgehen, dass die kleinste Transportblockgröße 256 Bit beträgt und die größte 7480 Bit, ergäbe sich daraus ein Datendurchsatz von rund 1.948.000 Bit pro Sekunde, das heißt, etwa 2 Mbps. Aus Gründen der Vereinfachung nehme ich in diesem Beispiel die Protokoll-Header von der Berechnung aus und gehe bei den ausgewählten IP-Header- und Datengrößen von 128 Bit aus. Stellen Sie sich jetzt einmal vor, dass bei der Durchführung derselben Messung das nächste Mal die Performance des Funkprotokolls nachgelassen hat – etwa aufgrund eines Performance-Einbruchs der Protokoll-Software -, so dass jede dritte große Paketübertragung verloren geht. Die verloren gegangenen Pakete müssen erneut vom Funkprotokollstapel gesendet werden, was den Datendurchsatz auf rund 1.504.000 Bit pro Sekunde reduziert – etwa 1,5 Mbps. Das sind 25 Prozent weniger als bei der ersten Messung.«
Bei der herkömmlichen Prüfanordnung hat der Ingenieur keinen Einblick in die Ursache des reduzierten Datendurchsatzes bzw. den Ort, an dem der Fehler auftritt – das Einzige was er sehen kann, ist die Durchsatzrate. Würde das Messsystem hingegen eine hohe Timing-Genauigkeit liefern, wäre die Eingrenzung des Fehlers kein Problem. Man könnte einfach die Paketverzögerung messen.