Sowohl das Internet als auch drahtlose Zugangsnetzwerke, wie UMTS und WLAN, dienen heutzutage zur Übertragung einer Viel- zahl von Daten. Insbesondere werden diese Netze immer mehr zur Übertragung von Multimedia-Daten, beispielsweise in Form von Video-Streaming, eingesetzt. Dabei treten häufig Quali- tätsprobleme auf. Diese Qualitätsprobleme resultieren daher, dass Multimediaströme über verschiedene Netze von einem Ser- ver zu einem Client transportiert werden, weshalb es nahezu unmöglich ist, eine durchgehend hohe und gleichbleibende Qua- lität der Datenübertragung zu garantieren. Ein Kunde, dem von einem Provider ein Multimediastrom bereitgestellt wird (bei- spielsweise bei Video on Demand oder Internet-Radio), bekommt somit nicht immer eine optimale Präsentation der Multimedia- inhalte. Sofern der Provider die Bereitstellung der Multime- diainhalte dem Kunden in Rechnung stellt, ist eine Bezahlung für die schlechte Qualität für den Kunden oft nicht akzepta- bel.

Heutzutage werden Multimediainhalte gegenüber dem Kunden in Bezug auf das übertragene Datenvolumen abgerechnet. Technisch wird dies dadurch realisiert, dass bei der Anforderung eines Multimediastroms mit einem sog. Session Management Protokoll einer Streaming Session aufgebaut wird. Der Auf-und Abbau einer Session wird in Logdateien und Datenbanken gespeichert.

Eine Abrechnung für den Kunden wird dadurch erzeugt, dass die Logdateien bzw. Datenbanken nach entsprechenden Auf-und Ab- bau der Sitzung durchsucht werden und hieraus die übertragene Datenmenge extrahiert wird. Es erweist sich hierbei als

nachteilig, dass der Kunde unabhängig von der Qualität des Multimediastroms immer den vollen Preis für die Datenübertra- gung zahlt.

Aufgabe der Erfindung ist es deshalb, ein Verfahren zur Über- tragung von Daten zu schaffen, welches eine verbesserte Ab- rechnung von Übertragungskapazitäten gegenüber einem Kunden ermöglicht.

Diese Aufgabe wird durch die unabhängigen Patentansprüche ge- löst. Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen definiert.

In dem erfindungsgemäßen Verfahren werden Daten zwischen ei- nem ersten Rechner und einem zweiten Rechner übertragen, wo- bei während der Übertragung qualitätsreduzierende Ereignisse, welche zu einer Verschlechterung der Qualität der übertrage- nen Daten führen, erfasst werden. Diese qualitätsreduzieren- den Ereignisse werden protokolliert.

Der Erfindung liegt somit die Erkenntnis zugrunde, dass Er- eignisse, welche für einen Verwender der übertragenen Daten eine wahrnehmbare Qualitätsverschlechterung darstellen, de- tektiert werden können und für einen Provider wichtige Infor- mationen darstellen.

In einer besonders bevorzugten Ausführungsform wird das er- findungsgemäße Verfahren zur Übertragung von digitalisierten Videobildern (auch Video-Streaming genannt) eingesetzt, wobei in diesem Falle folgende qualitätsreduzierenden Ereignisse erfasst werden : - Einfrieren von Videobildern ; - Artefakte in videobildern ; - Verminderung der Schärfe von Videobildern.

Die Erfinder haben hierbei erkannt, dass es bei den heutzuta- ge verwendeten Übertragungsverfahren problemlos möglich ist, die oben genannten, für einen Benutzer als sehr störend emp- fundenen Ereignisse technisch zu ermitteln.

In einer besonders bevorzugten Ausführungsform werden in Ab- hängigkeit von den protokollierten qualitätsreduzierenden Er- eignissen die von einem Benutzer für die Datenübertragung zu entrichtenden Kosten berechnet. Hierdurch wird einem Provider die Möglichkeit geschaffen, ein transparentes und an der Qua- lität der Daten orientiertes Abrechnungsmodell für den Kunden bereitzustellen. Die Abhängigkeit der abzurechnenden Kosten von der Datenqualität ist hierbei jedoch nur ein Beispiel ei- ner Abrechnungspolitik. Z. B. könnte auch die Möglichkeit be- stehen, eine schlechte Qualität an andere Faktoren, wie z. B.

Prämien oder ein Sonderkündigungsrecht für den Benutzer, zu koppeln.

In einer besonders bevorzugten Ausführungsform des erfin- dungsgemäßen Verfahrens ist der erste Rechner ein Server und der zweite Rechner ein Client. Unter einem Server wird ein Rechner verstanden, der Daten bereitstellt, die von einem Client, beispielsweise einem Endgerät wie Laptop oder Handy, empfangen werden. Dabei wird im Client wenigstens ein Teil der qualitätsreduzierenden Ereignisse erfasst und an dem Ser- ver mittels einer Rückmeldungs-Nachricht gemeldet. Die Erfas- sung der qualitätsreduzierenden Ereignisse erfolgt somit in dem Mediaplayer bzw. Decoder im Client, was technisch kein Problem darstellt. In einer bevorzugten Variante werden in der Rückmeldungs-Nachricht Quantifizierungsmaße übermittelt, durch welche das jeweilige qualitätsreduzierende Ereignis ka- tegorisiert und/oder spezifiziert wird. Das qualitätsreduzie- rende Ereignis kann insbesondere bei der Videoübertragung ei- ner der drei oben genannten Ereigniskategorien zugeordnet werden.

In einer weiteren Ausführungsform wird bei der Datenübertra- gung das hinlänglich aus dem Stand der Technik bekannte RTP/- RTCP-Protokoll (RTP = Real Time Protocol ; RTCP = Real Time Control Protocol, siehe Dokument [1]) eingesetzt und die Rückmeldungs-Nachricht wird im RTCP-Protokoll übermittelt.

Die Rückmeldungs-Nachricht umfasst vorzugsweise eine oder mehrere Bits, insbesondere ein Byte.

In einer weiteren Variante des erfindungsgemäßen Verfahrens ist der erste Rechner wiederum ein Server und der zweite Rechner wiederum ein Client, wobei jedoch wenigstens ein Teil der qualitätsreduzierenden Ereignisse im Server erfasst wer- den. Dies hat den Vorteil, dass die Erfassung der Ereignisse vom Client abgekoppelt ist, so dass ein etwaiger Missbrauch durch Manipulation am Client nicht möglich ist. Ein solcher Missbrauch könnte das Versenden von manipulierten Rückmel- dungs-Nachrichten sein, welche dem Server suggerieren, dass ein qualitätsreduzierendes Ereignis aufgetreten ist, was je- doch tatsächlich nicht der Fall ist. Hierdurch könnte ein Be- nutzer versuchen, den Preis für eine Datenübertragung zu ver- mindern.

Eine Möglichkeit der Erfassung von qualitätsreduzierenden Er- eignissen beim Server besteht darin, dass vom Server die ge- sendete Datenrate detektiert wird und die am Client empfange- ne Datenrate vom Client detektiert und an den Server gemeldet wird. Der Server stellt dann ein qualitätsreduzierendes Er- eignis fest, wenn der Unterschied zwischen empfangener und gesendeter Datenrate einen vorbestimmten Wert überschreitet.

Eine andere Möglichkeit zur Erfassung der qualitätsreduzie- renden Ereignisse beim Server besteht darin, dass Datenver- luste vom Client detektiert und an den Server gemeldet wer- den. Der Server stellt dann ein qualitätsreduzierendes Ereig- nis fest, wenn der Unterschied zwischen empfangener und ge- sendeter Datenrate einen vorbestimmten Wert überschreitet.

Eine andere Möglichkeit zur Erfassung der qualitätsreduzie- renden Ereignisse beim Server besteht darin, dass Datenver-

luste vom Client detektiert und an den Server gemeldet wer- den, wobei der Server in Abhängigkeit von der Größe der Da- tenverluste das Auftreten eines qualitätsreduzierenden Ereig- nisses erfasst. In einer bevorzugten Variante wird dabei wie- derum das RTP/RTCP-Protokoll eingesetzt, und die vom Client detektierte empfangene Datenrate und/oder die vom Client de- tektierten Datenverluste werden im RTCP-Protokoll übermit- telt. Somit können bekannte Protokolle zur Realisierung des erfindungsgemäßen Verfahrens eingesetzt werden.

Eine weitere Möglichkeit zur Erfassung von qualitätsreduzie- renden Ereignissen beim Server erfolgt über den Datenpuffer im Client. Hierbei ist die Größe des Puffers dem Server be- kannt bzw. wird sie dem Server beim Aufbau einer Übertra- gungssitzung mitgeteilt. Der Server wird dann bei Datenver- lusten vom Client darüber informiert, welche Daten verloren- gegangen sind, wobei der Server daraus den Füllstand des Puf- fers berechnet und dadurch das Auftreten von qualitätsredu- zierenden Ereignissen ermittelt. Die Information, welche Da- ten bei Datenverlusten verloren gegangen sind, wird vorzugs- weise über eine Erweiterung im RTCP-Protokoll dem Server mit- geteilt.

Das oben genannte Verfahren wird insbesondere bei Datenüber- tragungen eingesetzt, welche Daten in Form von Datenpaketen übermitteln, wie es beispielsweise beim IP-Protokoll (IP = Internet Protocol) der Fall ist.

In einer weiteren Ausführungsform der Erfindung wird die Er- fassung der qualitätsreduzierenden Ereignisse beim Server und die Erfassung der qualitätsreduzierenden Ereignisse beim Client kombiniert, so dass qualitätsreduzierende Ereignisse sowohl beim Server als auch beim Client erfasst werden. Es wird dabei ein Vergleich zwischen den beiden qualitätsredu- zierenden Ereignissen durchgeführt, wobei nur solche Ereig- nisse protokolliert werden, die sowohl vom Server als auch vom Client erfasst wurden. Es wird somit eine Plausibilitäts-

prüfung nachgeschaltet, um dadurch etwaige fälschlich detek- tierte qualitätsreduzierenden Ereignisse herauszufiltern.

Neben dem oben beschriebenen Datenübertragungsverfahren be- trifft die Erfindung ferner ein Datennetz mit wenigstens ei- nem ersten und wenigstens einem zweiten Rechner, wobei das Datennetz derart ausgestaltet ist, dass zwischen dem ersten und dem zweiten Rechner Daten gemäß dem erfindungsgemäßen Übertragungsverfahren übermittelt werden. Vorzugsweise um- fasst dieses Datennetz ein IP-Netz und/oder ein UMTS-Netz und/oder ein WLAN-Netz.

Darüber hinaus umfasst die Erfindung ein Computerprogramm- Erzeugnis, welches ein Speichermedium aufweist, auf welchem ein Computerprogramm gespeichert ist, mit dem das erfindungs- gemäße Datenübertragungsverfahren durchgeführt wird, wenn das Computerprogramm auf einem Rechner abläuft.

Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Figuren beschrieben.

Es zeigen : Figur 1 eine schematische Darstellung des erfindungsgemäßen Datenübertragungsverfahrens ; Figur 2 eine schematische Darstellung einer Rückmeldungs- Nachricht, die in einer Ausführungsform des erfin- dungsgemäßen Verfahrens verwendet wird ; und Figur 3 eine Prozessoreinheit zur Durchführung des erfin- dungsgemäßen Verfahrens.

Im Folgenden wird die Erfindung im Zusammenhang mit Video- Streaming beschrieben, bei dem ein aus einer Vielzahl von Vi- deobildern bestehender Videofilm von einem Server auf einem Client heruntergeladen und dort von einem Benutzer betrachtet

wird. Beim Video-Streaming konnten experimentell drei ver- schiedene Klassen von qualitätsreduzierenden Ereignissen er- mittelt werden, wobei diese Ereignisse dem Betrachter des Vi- deofilms negativ auffallen und damit zur Reduktion der sub- jektiven Qualität der Multimediadaten führen. Es handelt sich um folgende drei Ereignisse : 1. Einfrieren des Bildes : Bei diesem Ereignis bleibt das Bild eine Zeit lang stehen.

2. Artefakte im Videobild : Bei diesem Ereignis erscheinen Teile des Videobildes verfremdet oder verschmiert.

3. Qualitätsreduktion in der Bitrate : Bei diesem Ereignis ist die Schärfe des Videobildes und die Schärfe der Bewe- gungen im Videobild vermindert.

In Figur 1 ist ein Szenario dargestellt, bei dem das erfin- dungsgemäße Verfahren zur Anwendung kommt. Figur 1 zeigt ei- nen Server 1 und einen Client 2, wobei der Server Video- Streaming-Daten zur Verfügung stellt, die zum Client übertra- gen werden. Hierbei wird u. a. das IP-Protokoll zur Datenüber- tragung genutzt. Darüber hinaus wird in der hier beschriebe- nen Ausführungsform das sog. RTP-Protokoll eingesetzt, das hinlänglich aus dem Stand der Technik bekannt ist (siehe Druckschrift [l]). Dieses Protokoll umfasst ferner das RTCP- Protokoll, mit dem sog. Feedback-Nachrichten zur Überwachung der Datenübertragung von dem Client an den Server zurückge- sendet werden.

Durch das erfindungsgemäße Verfahren wird es ermöglicht, dass der Server über die drei oben genannten qualitätsreduzieren- den Ereignisse informiert wird und diese Ereignisse protokol- liert. In einer ersten Ausführungsform erfolgt dies dadurch, dass die Ereignisse beim Client erkannt und an den Server be- richtet werden. Voraussetzung ist hierfür, dass der Client die Ereignisse detektieren kann. Dies ist üblicherweise kein

Problem, da der Client zur Anzeige der Videodaten einen Play- er bzw. Decoder umfasst, der die drei oben genannten quali- tätsreduzierenden Ereignisse erkennt. Zur Rückmeldung dieser Ereignisse wird in der ersten Ausführungsform das RTCP- Protokoll verwendet, welches ein spezielles Erweiterungs-Byte umfasst, das in Figur 2 schematisch dargestellt ist.

Figur 2 zeigt das Erweiterungs-Byte mit den Bitpositionen 0 bis 7. Die ersten drei Bitpositionen 0 bis 2 beschreiben die entsprechenden qualitätsreduzierenden Ereignisse, wobei el für das oben genannte erste Ereignis, e2 für das oben ge- nannte zweite Ereignis und e3 für das oben genannte dritte Ereignis steht. Nach der Detektion eines qualitätsreduzieren- den Ereignisses durch den Client setzt dieser das entspre- chende Bit 0, 1 bzw. 2 auf den Wert l. Hierdurch wird mitge- teilt, welches qualitätsreduzierende Ereignis vorliegt. Die übrigen, in Figur 2 als R bezeichneten Bitfelder sind für weitere qualitätsreduzierende Ereignisse vorgesehen bzw. kön- nen zur zusätzlichen Quantifizierung dieser Ereignisse ge- nutzt werden. Beispielsweise könnte mit diesen Bits signali- siert werden, wie lange das Einfrieren eines Bildes andauert bzw. wie groß die Anzahl der auftretenden Artefakte im Video- bild ist.

Ein Nachteil dieser ersten Ausführungsform des erfindungsge- mäßen Verfahrens besteht darin, dass der Client unter Umstän- den missbräuchlich das Auftreten von qualitätsreduzierenden Ereignissen an den Server meldet. Beispielsweise könnte der Client durch den Benutzer manipuliert werden, so dass dem Server suggeriert wird, dass eine schlechte Bildqualität vor- liegt. Dies kommt insbesondere dann in Betracht, wenn beim Auftreten von qualitätsreduzierenden Ereignissen das zu zah- lende Entgeld für die Datenübertragung entsprechend reduziert wird. Dieser Nachteil kann. gemäß einer zweiten Ausführungs- form des erfindungsgemäßen Verfahrens umgangen werden. Bei dieser zweiten Ausführungsform schließt der Server auf ein qualitätsreduzierendes Ereignis nur aufgrund der regulären

RTCP-Nachricht, die nicht um das oben beschriebene Byte er- weitert ist. Dies ist möglich, da bereits in der regulären RTCP-Nachricht Informationen zur Datenübertragung enthalten sind, mit denen der Server auf qualitätsreduzierende Ereig- nisse schließen kann. Bei dieser Ausführungsform ist die Mög- lichkeit des Missbrauchs durch einen Benutzer stark einge- schränkt, da die Qualität der Verbindung heruntergeregelt wird, wenn die reguläre RTCP-Nachricht eine ständig schlech- ter werdende Qualität berichtet. Da ein Benutzer an einer Verschlechterung der Qualität kein Interesse hat, kommt eine missbräuchliche Verwendung durch eine Manipulation der RTCP- Nachricht nicht in Betracht.

Die einzelnen qualitätsreduzierenden Ereignisse können beim Server wie folgt detektiert werden : Das Ereignis"Qualitätsreduktion in der Bitrate"ist auf Ser- verseite leicht zu detektieren, da dem Server die gesendete Bitrate bekannt ist. Der Client erfährt die gesendete Bitrate durch eine RTCP-Nachricht des Servers. Überschreitet somit die Differenz aus gesendeter und erwarteter Bitrate einen vorbestimmten Wert, liegt ein qualitätsreduzierendes Ereignis vor.

Das Ereignis"Artefakte im Bild"ist nicht so einfach zu de- tektieren. Diesem Ereignis geht in der Regel ein Datenpaket- verlust voraus. Datenpaketverluste können dem Server wiederum über das RTCP-Protokoll mitgeteilt werden. Ob ein Paketver- lust jedoch zu einem qualitätsreduzierenden Ereignis durch Artefakte im Bild führt, hängt stark'von dem verwendeten Client ab. Bei der Auswertung eines qualitätsreduzierenden Ereignisses muss der Server folglich wissen, welcher Client vorliegt. Diese Information kann dem Server beispielsweise dadurch zur Verfügung gestellt werden, dass für jeden Client ein Schwellenwert T ermittelt wird. Dieser Schwellenwert sagt aus, dass ein qualitätsreduzierendes Ereignis in der Form von Artefakten beim Client auftritt, wenn der Paketverlust größer

als T ist. Der entsprechende Wert T muss im vorhinein durch Experimente ermittelt werden. Somit wird das qualitätsredu- zierende Ereignis"Artefakte im Bild"immer dann detektiert, wenn der beim Client festgestellte Datenpaketverlust einen vom Client abhängigen Schwellenwert T überschreitet.

Das qualitätsreduzierende Ereignis"Einfrieren des Videobil- des"tritt im Allgemeinen dann auf, wenn der im Client vor- handene Puffer für die Videobilder unterläuft, d. h. nahezu leer ist. Zur Detektion dieses Ereignisses teilt der Client dem Server beim Aufbau der Datenverbindung zunächst mit, wie groß sein Puffer ist und wie voll der Puffer sein muss, damit bei ihm Multimediainhalte angezeigt werden. Bei der Daten- übertragung erfährt der Server ferner über eine Erweiterung im RTCP-Protolcoll, welche Pakete verloren gehen sowie den Zeitstempel der ankommenden Pakete. Hieraus ermittelt der Server problemlos den Pufferstand. Tritt nun der Fall auf, dass der Pufferfüllstand unterhalb des Wertes liegt, ab dem Multimediadaten angezeigt werden, tritt ein Einfrieren des Videobildes auf. Detektiert der Server einen solchen Puffer- unterlauf, protokolliert er diesen als qualitätsreduzierendes Ereignis.

In einer dritten Ausführungsform des erfindungsgemäßen Ver- fahrens werden die erste und die zweite Ausführungsform kom- biniert. D. h. die qualitätsreduzierenden Ereignisse werden sowohl vom Client als auch vom Server detektiert. Der Server vergleicht dann beide Detektionen. Sofern keine Diskrepanzen auftreten, werden die detektierten Ereignisse als qualitäts- reduzierende Ereignisse protokolliert. Sollte jedoch bei- spielsweise vom Client ein qualitätsreduzierendes Ereignis detektiert werden, das der Server nicht erfasst, liegt mit hoher Wahrscheinlichkeit ein Missbrauch vor, so dass der Ser- ver dieses Ereignis nicht protokolliert.

Das oben beschriebene Erfassen und Protokollieren der quali- tätsreduzierenden Ereignisse wird in einer bevorzugten Aus-

führungsform der Erfindung zur Berechnung der Gebühren für die Datenübertragung herangezogen. Hierdurch soll es ermög- licht werden, dass der Preis für die Datenübertragung auch von der Qualität der Daten abhängig gemacht wird. Somit muss beispielsweise der Betrachter von Multimedia-Daten weniger zahlen, wenn die Qualität unbefriedigend ist. Hierbei hängt es von dem Provider ab, wie er seine Abrechnung gegenüber dem Kunden an die qualitätsreduzierenden Ereignisse koppelt. Bei- spielsweise kann der Provider beim Auftreten einer schlechten Qualität über einen längeren Zeitraum dem Kunden Geld zurück- erstatten. Vorstellbar ist hierbei, dass dem Kunden bei schlechter Qualität ein reduzierter Preis in Rechnung ge- stellt wird oder dass der Kunde überhaupt nichts bezahlen muss.

Die oben beschriebenen Ausführungsformen betreffen die Über- tragung von Multimedia-Daten in Form von Video-Streaming, je- doch ist es für den Fachmann ersichtlich, dass die obige Er- findung auch für die Übertragung anderer Daten angewendet werden kann. Ein weiteres Anwendungsgebiet ist beispielsweise die Telefonie in einem IP-Netz, welche häufig als"Voice over IP"bezeichnet wird. Hierbei kann von einem Mobilfunkprovider in seiner Abrechnung die Sprachqualität einbezogen werden.

Der große Vorteil der oben beschriebenen Kopplung der quali- tätsreduzierenden Ereignisse an Abrechnungspreise liegt dar- in, dass ein Provider dem Kunden einen fairen Abrechnungsmo- dus bereitstellen kann, wodurch er sich gegenüber anderen Wettbewerbern einen Vorteil verschafft.

In Fig. 3 ist eine Prozessoreinheit PRZE zur Durchführung des erfindungsgemäßen Verfahrens dargestellt. Die Prozessorein- heit PRZE umfasst einen Prozessor CPU, einen Speicher MEM und eine Input/Output-Schnittstelle IOS, die über ein Interface IFC auf unterschiedliche Art und Weise genutzt wird : Über ei- ne Grafikschnittstelle wird eine Ausgabe auf einem Monitor MON sichtbar und/oder auf einem Drucker PRT ausgegeben. Eine

Eingabe erfolgt über eine Maus MAS oder eine Tastatur TAST.

Auch verfügt die Prozessoreinheit PRZE über einen Datenbus BUS, der die Verbindung von einem Speicher MEM, dem Prozessor CPU und der Input/Output-Schnittstelle IOS gewährleistet.

Weiterhin sind an den Datenbus BUS zusätzliche Komponenten anschließbar, z. B. zusätzlicher Speicher, Datenspeicher (Festplatte) oder Scanner.

Literaturverzeichnis : [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacob- son,"RTP : A transport protocol for real-time applicati- ons", RFC 1889, IETF, February 1996.