DE112013005157T5

DE112013005157T5 - Systeme und Verfahren zur Teilung von Bandbreite über eine Vielzahl von Videodatenströmen

Info

Publication number: DE112013005157T5
Application number: DE112013005157.5T
Authority: DE
Inventors: Satyanarayana Tummalapenta; Tyrone D. Bekiares; Steven D. Tine; Srikanth Vukkadapu
Original assignee: Motorola Solutions Inc
Current assignee: Motorola Solutions Inc
Priority date: 2012-10-26
Filing date: 2013-10-24
Publication date: 2015-08-13
Anticipated expiration: 2033-10-25
Also published as: WO2014066600A4; DE112013005157B4; CA2886681A1; US9100698B2; WO2014066600A2; US20140122652A1; AU2013334593A1; AU2013334593B2; WO2014066600A3; CA2886681C

Abstract

Ein Client-basiertes Verfahren, ein Server-basiertes Verfahren und ein Client-Gerät ermöglichen die Datenübertragung mehrerer Videodatenströme unter Verwendung standardisierter Verfahre, während sie sicherstellen, dass die Vielzahl von Videodatenströmen eine Bandbreite über eine einzige, variable Verbindung, wie eine drahtlose Verbindung, teilen. Diese Verfahren und das Gerät erlauben eine gleichmäßige Aufteilung der Bandbreite über mehrere Videodatenströme, die sich dasselbe physische Medium teilen. Ferner können diese Verfahren und das Gerät eine selektive Priorisierung von jedem der mehreren Datenströme ermöglichen.

Description

GEBIET DER OFFENBARUNG
Die vorliegende Offenbarung betrifft allgemein drahtlose Netzwerke und spezielle Systeme und Verfahren zur Aufteilung von Bandbreite über eine Vielzahl von Videodatenströmen in einem drahtlosen Netzwerk.
HINTERGRUND
In drahtlosen Netzwerken kann die verfügbare effektive Bandbreite von Zeit zu Zeit abhängig von den Kanalbedingungen variieren. Für Video über drahtlose Netzwerke und für eine gute Nutzererfahrung, müssen Videosender die Übertragungsbitrate basierend auf einer verfügbaren Bandbreite anpassen. Die Videosender können sich auf eine Rückmeldung von Empfängern verlassen, um die verfügbare Bandbreite zu ”erraten”. Die Rückmeldung kann eine RTP-Steuerungsprokotoll(RTCP)-Empfängernachricht in einem Echtzeitübertragungsprotokoll (RTP) für Nutzerdatenpaketprotokoll(UDP)-basierenden Systemen oder den effektiven Durchsatz, wie er von dem Sender im Falle Hypertext-Übertragungsprotokoll(HTTP)-basierten Systemen gesehen wird, umfassen. Es ist zu beachten, dass diese Rückmeldung auf einer Per-Datenstrom-Basis erfolgt, beispielsweise gibt es für jeden RTP-Mediendatenstrom einen korrespondierenden RTCP-Rückmeldungskanal, der nur eine Rückmeldung über den und nur den Mediendatenstrom überträgt. In Clients (Empfänger), die mehr als einen Videodatenstrom zur gleichen Zeit empfangen, bestehen unterschiedliche Probleme in konventionellen Systemen und Verfahren. Beispielsweise, da RTCP-Empfangsnachrichten unabhängig und für einen Datenstrom spezifisch sind, werden die aufgrund dieser Nachrichten erfolgten Maßnahmen nur auf diese Datenströme angewendet. Beispielsweise erfolgen Hochschaltungen und Herunterschaltungen von Bitraten unabhängig für jeden Datenstrom. Die Rückmeldungsintervalle werden üblicherweise nicht aufeinander abgestimmt (obwohl sie eine gleiche Dauer aufweisen), da jeder Datenstrom eine unabhängige Sitzung ist und zu unterschiedlichen Zeitpunkten hätte aufgebaut werden können. Aufgrund des Nichtabstimmens kann oder kann nicht eine hohe Anzahl von Verlusten in allen Datenströmen dazu führen, dass sie zur gleichen Zeit herunterschalten und einige überhaupt nicht herunterschalten. Ähnlich dazu können oder können nicht keine in einer Zeitdauer auftretenden Verluste in allen Datenströmen dazu führen, dass sie hochschalten und einige überhaupt nicht hochschalten. Dieses unsynchronisierte Verhalten wird einige Datenströme dazu veranlassen, zu weit herunterzuschalten und andere Datenströmen dazu veranlassen, zu weit hochzuschalten, was zu asymmetrischen Profilen führt. Aus Sicht des Nutzers würde das dazu führen, einen Datenstrom mit guter Qualität und einen anderen Datenstrom mit schlechter Qualität über die gleiche drahtlose Verbindung zu sehen.
Entsprechend gibt es einen Bedarf für eine gleichmäßige Teilung der Bandbreite über eine Vielzahl von Videodatenströmen in einem drahtlosen Netzwerk. Entsprechend könnte es in einigen Situationen einen Bedarf für den Client geben zwischen einer Vielzahl von Datenströmen in Bezug auf eine Qualität in verlustreichen Bedingungen während einer Sitzung zu unterscheiden. Es könnte einigen Datenströmen eine höhere Priorität im Vergleich zu anderen zuweisen wollen.
KURZE BESCHREIBUNG DER FIGUREN
Die beiliegenden Figuren, in denen sich gleiche Bezugszeichen auf identische oder funktional ähnliche Elemente in unterschiedlichen Ansichten beziehen, zusammen mit der unten angegebenen detaillierten Beschreibung, sind in die Beschreibung eingebunden und bilden einen Teil davon, und dienen dazu, Ausführungsbeispiele von Konzepten zu beschreiben, die die beanspruchte Erfindung umfassen und erklären verschiedene Prinzipien und Vorteile dieser Ausführungsbeispiele.
1 ist ein Blockdiagramm eines multiplen Videodatenstromsystems zur gleichmäßigen Bandbreitenteilung in einem drahtlosen Netzwerk gemäß einigen Ausführungsbeispielen.
2 ist ein Blockdiagramm eines beispielhaften Betriebs von fünf Videodatenströmen, die drahtlos an ein Client-Gerät mit fünf Profilen gemäß einigen Ausführungsbeispielen gesendet werden.
3 ist ein Flussdiagramm eines Client-basierten Verfahrens zur gleichmäßigen Aufteilung von Bandbreite über mehrere Videodatenströme gemäß einigen Ausführungsbeispielen.
4 ist ein Flussdiagramm eines RTP-Protokoll-Verfahrens zur Verwendung mit dem Client-basierten Verfahren nach 3 gemäß einigen Ausführungsbeispielen.
5 ist ein Flussdiagramm eines gemittelten Benachrichtigungsverfahrens zur Verwendung mit dem Client-basierten Verfahren von 3 gemäß einigen Ausführungsbeispielen.
6 ist ein Flussdiagramm eines Manipulierter-Bericht-Verfahrens zur Verwendung mit dem Client-basierten Verfahren nach 3 gemäß einigen Ausführungsbeispielen.
7 ist ein Flussdiagramm eines Hochschalte-/Herunterschalte-Verfahrens zur Verwendung mit dem Client-basierten Verfahren von 3 gemäß einigen Ausführungsbeispielen.
8 ist ein Flussdiagramm eines UDP-Verfahrens zur Verwendung mit dem Client-basierten Verfahren von 3 gemäß einigen Ausführungsbeispielen.
9 ist ein Flussdiagramm eines Server-basierten Verfahrens zur gleichmäßigen Aufteilung von Bandbreite über mehrere Videodatenströme gemäß einigen Ausführungsbeispielen.
10 ist ein Flussdiagramm eines Übertragungssteuerungsprotokolls(TCP)-Verfahrens zur Verwendung mit dem Server-basierten Verfahren von 9 gemäß einigen Ausführungsbeispielen.
11 ist ein Diagramm eines beispielhaften Betriebs eines gemittelten Benachrichtigungsverfahrens gemäß einigen Ausführungsbeispielen.
12 ist ein Diagramm eines beispielhaften Betriebs eines manipulierten Benachrichtigungsverfahrens gemäß einigen Ausführungsbeispielen.
13 ist ein Blockdiagramm eines Servers zur Verwendung in dem System von 1 und den unterschiedlichen Verfahren gemäß einigen Ausführungsbeispielen.
14 ist ein Blockdiagramm, welches das Client-Gerät 12 zur Verwendung in dem System 10 und den unterschiedlichen Verfahren darstellt, gemäß einigen Ausführungsbeispielen zeigt.
Der Fachmann erkennt, dass die in den Figuren dargestellten Elemente der Einfachheit und Klarheit halber dargestellt sind und nicht notwendigerweise maßstabsgetreu gezeichnet sind. Beispielsweise können die Ausdehnungen einiger der Elemente in den Figuren übertrieben gegenüber den anderen Elementen dargestellt sein, um dabei zu helfen, das Verständnis der Ausführungsbeispiele der vorliegenden Erfindung zu verbessern.
Die Vorrichtungs- und Verfahrenskomponenten wurden, wo es zweckdienlich ist, durch konventionelle Symbole in den Zeichnungen dargestellt, wobei nur diejenigen spezifischen Details dargestellt sind, die für das Verständnis der Ausführungsbeispiele der vorliegenden Erfindung wichtig sind, so dass die Offenbarung nicht mit Details verzerrt wird, die von dem Fachmann bei der Lektüre der vorliegenden Beschreibung als selbstverständlich angesehen werden.
DETAILLIERTE BESCHREIBUNG
In einem Ausführungsbeispiel umfasst ein Client-basiertes Verfahren Empfangen einer Vielzahl von Videodatenströmen an einem Client-Gerät über eine drahtlose Verbindung, wobei jede der Vielzahl von Videodatenströmen gemäß einem von einer Vielzahl von assoziierten Profilen arbeitet, Bestimmen einer Rückmeldung für jeden der Vielzahl von Videodatenströmen, Bestimmen einer modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen basierend auf der Rückmeldung für jeden der Vielzahl von Videodatenströmen, und Übertragen der modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen an eine assoziierte Quelle von jedem der Vielzahl von Videodatenströmen.
In einem anderen Ausführungsbeispiel umfasst ein Server-basiertes Verfahren Übertragen einer Vielzahl von Videodatenströmen an ein Client-Gerät von zumindest einem Server, wobei jeder der Vielzahl von Videodatenströmen nach einem von einer Vielzahl von assoziierten Profilen betrieben wird, Empfangen einer Rückmeldung für jeden der Vielzahl von Videodatenströmen, wobei die Rückmeldung durch zumindest einen Server modifiziert ist, so dass jeder der Vielzahl von Videodatenströmen im Wesentlichen die gleiche Bandbreite hat, Bestimmen, ob Änderungen an den assoziierten Profilen von jedem der Vielzahl von Videodatenströmen vorgenommen werden müssen, und, wenn Änderungen vorgenommen werden müssen, Übertragen der Vielzahl von Videodatenströmen nach unterschiedlichen assoziierten Profilen der Vielzahl von assoziierten Profilen basierend auf den Änderungen.
In einem weiteren Ausführungsbeispiel umfasst ein Client-Gerät eine Netzwerk-Schnittstelle, die kommunikativ mit einem drahtlosen Netzwerk verbunden ist, einen Prozessor, der kommunikativ mit der Netzwerkschnittstelle verbunden ist und einen Speicher, der Befehle speichert, die, wenn ausgeführt, den Prozessor und die Netzwerkschnittstelle dazu veranlassen: eine Vielzahl von Videodatenströmen an einem Client-Gerät über das drahtlose Netzwerk zu empfangen, wobei jeder der Vielzahl von Videodatenströmen nach einem von einer Vielzahl von assoziierten Profilen betrieben wird, eine Rückmeldung für jeden von der Vielzahl von Videodatenströmen zu bestimmen, eine modifizierte Rückmeldung für jeden der Vielzahl von Videodatenströmen basierend auf der Rückmeldung für jeden der Vielzahl von Videodatenströmen zu bestimmen, und die modifizierte Rückmeldung für jeden der Vielzahl von Videodatenströmen an eine assoziierte Quelle von jedem der Vielzahl von Videodatenströmen zu übertragen.
Unter Bezugnahme auf 1, in einem Ausführungsbeispiel, zeigt ein Blockdiagramm ein multiples Videodatenstromsystem 10 zu gleichmäßigen Aufteilung von Bandbreite in einem drahtlosen Netzwerk. Insbesondere umfasst das System 10 ein Client-Gerät 12 mit einer drahtlosen Verbindung 14 an ein Netzwerk 16. Beispielsweise kann das Clientgerät 12 ein digitales Mobiltelefon, ein Smartphone, einen persönlichen digitalen Assistenten, ein Tabletgerät, ein Ultrabook, ein Netbook, ein mobiles Datenterminal, einen Desktop mit einer drahtlosen Schnittstelle oder ähnliches umfassen. Das System 10 umfasst ferner einen oder mehrere Server 20, die kommunikativ mit dem Netzwerk 16 gekoppelt sind. In einem Ausführungsbeispiel kann das Netzwerk 16 das Internet, virtuelle private Netzwerke (VPNs), lokale Netzwerke (LANs), drahtlose Netzwerk-Provider (z. B. 2G, 4G, und so weiter), drahtloses LAN (WiFi) und Kombinationen daraus umfassen. Das heißt, das Client-Gerät 12 kann sich mit einem drahtlosen Netzwerk, das kommunikativ mit einem privaten oder öffentlichen IP-Netzwerk (beispielweise dem Internet) verbunden ist, verbinden. Die Server 20 können sich mit einem LAN verbinden, das kommunikativ mit dem Netzwerk (beispielsweise dem Internet) verbunden ist. In 1 sind diese unterschiedlichen Netzwerke durch das Netzwerk 16 zu Darstellungszwecken zusammengefasst dargestellt.
Im Betrieb umfasst das System 10 die Server 20 und das Client-Gerät 12, das mehrere Videodatenströme dazwischen mittels unterschiedlicher Mechanismen für ein effektives Bitraten-Management der mehreren Videodatenströme in einer konsolidierten oder gemeinsamen Weise überträgt. Es ist wichtig, dass diese Mechanismen in dem System sicherstellen, dass der Nutzer des Client-Geräts 12 nicht beobachtet, dass einer der Datenströme in das unterste Profil (beispielweise mit der geringsten Qualität) wechselt, während die anderen Datenströme in einem höheren Profil (mit einer höheren Qualität) bleiben, wenn alle Datenströme das gleiche physische Medium teilen und erwartet werden kann, dass sie die gleichen Kanalbedingungen vorfinden. In unterschiedlichen Ausführungsbeispielen kann das System 10 RTCP, RTP, UDP, HTTP, und so weiter verwenden. RTCP und RTP sind in RFC 3550 (Juli 2003) definiert, ”RTP: Ein Übertragungsprotokoll für Echtzeitanwendungen (englisch: RTP: A Transport Protocol for Real-Time Applications)”, wobei die Inhalte davon unter Bezugnahme hierin eingefügt sind.
Auf unterschiedliche Weisen werden Bitratenmanagementsysteme und -verfahren in das System 10 eingebunden, wobei der Betrieb der unterschiedlichen Standards und Protokolle vollständig erhalten bleibt, wodurch ein Zusammenwirken mit existierenden Geräten nicht beeinträchtigt wird. Diese Bitratenmanagementsysteme und -verfahren können in einem von dem Client-Gerät 12 und den Servern 20 implementiert sein. Sind beispielsweise die Bitratenmanagementsysteme und -verfahren in dem Client-Gerät 12 implementiert, kann der Server 20 vollständig gemäß bestehender Standards und Protokolle, ohne modifiziert zu werden, arbeiten. Andersherum, wenn die Bitratenmanagementsysteme und -verfahren in dem Server 20 implementiert sind, kann das Client-Gerät 12 vollständig gemäß bestehender Standards und Protokolle, ohne modifiziert zu werden, arbeiten. Es sind keine Erweiterungen an RTP, RTCP, usw. Protokollnachrichten nötig, so dass die Bitratenmanagementsysteme und -verfahren mit standardkonformen Geräten arbeiten können.
Unter Bezugnahme auf 2, in einem Ausführungsbeispiel, zeigt ein Blockdiagramm einen beispielhaften Betrieb 25 von fünf Videodatenströmen 26, die drahtlos an ein Client-Gerät mit fünf Profilen 28 gesendet werden. Wie hierin beschrieben, kann die verfügbare effektive Bandbreite in verlustreichen drahtlosen Netzwerken in Abhängigkeit von den Kanalbedingungen von Zeit zu Zeit variieren. Um die Nutzererfahrung zu verbessern, passen Videosender (beispielweise die Server 20) ihre Bitrate basierend auf der verfügbaren Bandbreite an. Die Videosender verlassen sich auf eine Rückmeldung der Empfänger (beispielsweise das Client-Gerät 12), um die verfügbare Bandbreite zu ”erraten”. Die Rückmeldung ist üblicherweise eins der folgenden: eine RTCP-Empfangsnachricht in RTP/UDP-basierten Systemen oder der effektive Datendurchsatz, wie er durch den Sender im Falle von HTTP-basierten System gesehen wird. Wie hierin beschrieben, definiert ein Profil, wie eine Quelle von dem Videosender an den Client in Bezug auf Bitraten, Frameraten, Auflösung, und so weiter übertragen wird. Es wird erwartet, dass jede Quelle mehrere Profile aufweist, zu/von denen basierend auf aktuellen Kanalbedingungen hochgeschaltet oder heruntergeschaltet werden kann. RTP/RTCP Empfangsberichte sind in RFC 3550 beschrieben und Erweiterungen sind in RFC 3611 (November 2003) beschrieben, die Inhalte von ”RTP Steuerprotokoll-erweiterten Nachrichten (RTCP XR)” sind hierin unter Bezugnahme aufgenommen.
Der Videosender, beispielsweise die Server 20, kann die folgenden Techniken einsetzen. Der Videosender kann einen Satz vordefinierter Profile beibehalten, beispielsweise die Profile 28 und hat typischerweise mit jedem Profil eine unterschiedliche Bitrate und möglicherweise eine unterschiedliche Auflösung und Framerate. Abhängig von der Rückmeldung und ”Erratener-Kanal-Bandbreite”, bewegt sich der Videosender zu dem am besten für diese Kanalbedingungen geeigneten Profil. Die Rückmeldungsnachricht ist gewöhnlich für ein vorbestimmtes Intervall (beispielweise handelt es sich im Fall von RTCP um das Empfangsbericht(RR)-Intervall oder es handelt sich im Fall von HTTP um den effektiven Durchsatz, wie er von dem Sender während diesem Intervall gesehen wird). Mehrere solcher Berichte (aufeinanderfolgend) werden für eine Entscheidung zum Herunterschalten (Bewegen zu einem niedrigeren Profil) oder Hochschalten (Bewegen zu einem höheren Profil) in Betracht gezogen, um auf zufälligen Einmal-Ereignissen basierende Entscheidungen zu vermeiden. Der Videosender wird in Abhängigkeit davon, ob er eine Vergrößerung oder Verringerung der Bandbreite sieht, hochschalten oder herunterschalten. Vorteilhaft hilft dies dem Endnutzer eine bessere Fernseherfahrung zu empfangen.
In dem beispielhaften Betrieb 25 sieht das Client-Gerät die fünf Datenströme 26 gleichzeitig. Jeder der Datenströme 26 hat fünf korrespondierende Profile 28 und ein Standardprofil (bezeichnet mit einem (D) in 2). Diese Profile und Standardprofile können von dem Administrator basierend auf dem Client-Netzwerk und anderen Bedingungen vorkonfiguriert sein. Zu beachten ist, dass das Standardprofil nicht das mittlere Profil 34 sein muss. Beispielsweise nimmt man Quelle A (Src A) als ein Beispiel, hat Profil Pa1 eine niedrigere Bitrate, niedrigere Auflösung und/oder niedrigere Framerate als das Profil Pa2, das Profil Pa2 ist niedriger als das Profil Pa3, und so weiter. Wenn sich der Client mit dem Videosender verbindet, startet der Videosender typischerweise mit dem Standardprofil. Wenn der Videosender schlechte Kanalbedingungen sieht, schaltet der Videosender zu einem niedrigeren Profil herunter, und wenn der Videosender gute Kanalbedingungen sieht, versucht der Videosender zu einem höheren Profil hochzuschalten.
In herkömmlichen Systemen und Verfahren erfolgt die Rückmeldung auf einer per Datenstrombasis. In dem System 10 und mit den darauf implementierten Bitratenmanagementsystemen und -verfahren, erfolgt die Rückmeldung auf einer über alle Datenströme zusammengefassten Basis. In einem Ausführungsbeispiel, das RTCP verwendet, wird die Rückmeldung an dem Client-Gerät 12 modifiziert, so dass jeder der Server 20 jeden der Videodatenströme in gleicher Weise hochschaltet oder herunterschaltet. In solchen Konfigurationen können die Server 20 vollständig konform zu RTCP ausgebildet sein, ohne Modifikationen vornehmen zu müssen, um die Bitratenmanagementsysteme und -verfahren zu implementieren. Hierbei sendet das Client-gerät 12 auch die RTCP RR Nachrichten in einer vollständig zu RTCP konformen Weise mit fertig vorberechneten Daten, um sicherzustellen, dass die Videodatenströme in gleichförmiger Weise behandelt werden. In einem weiteren Ausführungsbeispiel können die Server 20 den effektiven Durchsatz im HTTP verwenden, um sicherzustellen, dass die Videodatenströme in gleichförmiger Weise behandelt werden.
Entsprechend, unter Verwendung der Bitratenmanagementsysteme und -verfahren, schaltet einer der Datenströme 26 sein Profil 28 nicht herunter, während ein anderer der Datenströme 26 sein Profil 28 hochschaltet. Die bestehenden Standards und Protokolle umfassen Rückmeldungsschleifen, um Videodatenströme über unterschiedliche Kanäle, beispielsweise drahtlose, zu verwalten. Allerdings arbeiten diese Rückmeldungsschleifen autonom auf separaten Datenströmen auf der gleichen physischen Verbindung. Die Bitratenmanagementsysteme und -verfahren verwenden diese Feedbackschleifen durch Verwalten des Eingangs oder Ausgangs auf jeder Seite dieser Feedbackschleifen, um eine Kompatibilität mit bestehenden Standards und Protokollen beizubehalten, während sie gleichzeitig diese autonomen Betriebe auf separaten Datenströmen auf der gleichen physischen Verbindung entfernen. Dadurch stellen die Bitratenmanagementsysteme und -verfahren ein einheitliches Sehen von mehreren Videodatenströmen in einer standardkonformen Weise bereit, ohne die drahtlose Signalübertragung zu modifizieren, wobei alle Modifikationen entweder an dem Client-Gerät 12 oder dem Server 20 vorgenommen werden.
Unter Bezugnahme auf 3, in einem Ausführungsbeispiel, zeigt ein Flussdiagramm ein Client-basiertes Verfahren 30 zur gleichmäßigen Aufteilung von Bandbreite über mehrere Videodatenströme. In einem Ausführungsbeispiel kann das Client-basierte Verfahren 30 durch das Client-Gerät 12 in dem System 10 implementiert sein. Beispielsweise kann das Client-Gerät 12 eine Netzwerkschnittstelle, die kommunikativ mit einem drahtlosen Netzwerk gekoppelt ist, beispielsweise über die drahtlose Verbindung 14, einen Prozessor, der kommunikativ mit der Netzwerkschnittstelle gekoppelt ist, und einen Speicher, der Befehle speichert, die, wenn ausgeführt, den Prozessor und die Netzwerkschnittstelle veranlassen, unterschiedliche hierin beschriebene Schritte auszuführen. Das Client-basierte Verfahren 30 umfasst Empfangen einer Vielzahl von Videodatenströmen an einem cient-Gerät über eine drahtlose Verbindung, wobei jeder der Vielzahl von Videodatenströmen gemäß einem von einer Vielzahl von assoziierten Profilen (Schritt 31) arbeitet.
Das Client-basierte Verfahren 30 umfasst Bestimmen einer Rückmeldung für jeden der Vielzahl von Videodatenströmen (Schritt 32). Das Client-basierte Verfahren 30 betrifft eine Verwendung mit verschiedenen Protokollen, die sich auf Rückmeldungsschleifen von dem Client-Gerät an die assoziierten Videoquellen verlassen, um entsprechende Einstellungen zu bestimmen. Beispielsweise betrifft das Client-basierte Verfahren 30 die Verwendung von RTP, RTCP, UDP, und so weiter, und nicht ein Übertragungssteuerprotokoll (TCP), das ein verbindungsorientiertes Protokoll ist, bei dem die Videoquellen bereits den Durchsatz kennen, ohne auf eine Rückmeldung von Client-Gerät angewiesen zu sein. Es ist eine Aufgabe des Client-basierten Verfahrens 30, Eingänge oder Ausgänge dieser Rückmeldungsschleifen zu modifizieren, so dass keine Änderungen oder Erweiterungen an bestehenden Protokollen (das heißt RTP, RTCP, UDP, und so weiter) vorgenommen werden müssen und so dass die Vielzahl von Videodatenströmen in einer konsistent ähnlichen Weise gesehen werden, das heißt, dass jedem der Vielzahl von Videodatenströmen etwa die gleiche Menge an Bandbreite auf der gleichen drahtlosen Verbindung zur Verfügung steht.
Die Rückmeldung kann jeden Mechanismus umfassen, der die assoziierten Quellen von jedem der Vielzahl von Videodatenströmen über die erforderlichen Anpassungen alarmiert (oder nicht). In einem Ausführungsbeispiel kann die Rückmeldung ein Paketverlustverhältnis (oder eine Paketverlustrate) über einem Meldeintervall sein, zum Beispiel 5s. Diese Rückmeldung berichtet den assoziierten Quellen, ob die Vielzahl der Videodatenströme angepasst (das heißt im Profil hochgeschaltet oder heruntergeschaltet) werden müssen. Das Client-basierte Verfahren 30 umfasst Bestimmen einer modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen basierend auf der Rückmeldung für jeden der Vielzahl von Videodatenströmen (Schritt 33). Es ist eine Aufgabe des Client-basierten Verfahrens 30, diese Rückmeldung an das Client-Gerät zu modifizieren, um eine Konsistenz der Vielzahl von Videodatenströmen zu gewährleisten und um den Betrieb gemäß den bestehenden Standards und Protokollen zu erhalten. Schließlich umfasst das Client-basierte Verfahren Übertragen der modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen zu einer assoziierten Quelle von jedem der Vielzahl von Videodatenströmen (Schritt 34).
Das Bestimmen der modifizierten Rückmeldung kann unter Verwendung verschiedener Techniken durch das Client-Gerät erfolgen, um Konsistenz zwischen der Vielzahl von Videodatenströmen sicherzustellen. In einem Ausführungsbeispiel kann die modifizierte Rückmeldung ein Senden ”gemittelter” Meldungen an die assoziierten Quellen umfassen. Hierin kann das Client-Gerät einzelne Datenströme als ein Einzeldatenstrom bei der Berechnung des Paketverlustverhältnisses (PLR) gruppieren. Der über mehrere Datenströme berechnete, gewichtete Durchschnitts-PLR, kann als die PLR für Einzelströme weitergeleitet werden. Damit behandeln die assoziierten Quellen alle der Vielzahl von Videodatenströmen auf ähnliche Weise, das heißt das Hochschalten oder Herunterschalten geschieht für alle Datenströme gleichzeitig.
In einem anderen Ausführungsbeispiel kann die modifizierte Rückmeldung Senden ”manipulierter” Berichte an die assoziierten Quellen umfassen. Dabei sendet das Client-Gerät Berichte basierend auf dem, was das Client-Gerät den assoziierten Quellen zeigen möchte, und nicht, was das Client-Gerät tatsächlich auf der Vielzahl von Videodatenströmen sieht. Zum Beispiel, wenn die assoziierten Quellen zwei Datenströme mit jeweils 380 und 280 kbps senden, aber das Client-Gerät sie mit 360 kbps und 280 kbps empfängt, und das Client-Gerät beabsichtigt, dass sie die verfügbaren 640 kbps Bandbreite gleichmäßig teilen, dann berichtet das Client-Gerät die Verluste auf eine solche Weise, dass beide Datenströme sich auf 320 kbps begeben.
In diesem ”Manipulierter”-Bericht-Verfahren kann das Client-Gerät die assoziierten Quellen, die gemäß demselben Profil für alle Datenströme arbeiten, möglicherweise nicht sehen, da tatsächlich das Client-Gerät bestimmt, was die absolute Bitrate für jeden Datenstrom sein sollte.
Unter Bezugnahme auf 4, in einem Ausführungsbeispiel, zeigt ein Flussdiagramm ein RTP-Protokoll-Verfahren 40 zur Verwendung mit dem Client-basierten Verfahren 30 der 3. Das RTP-Protokoll-Verfahren 40 umfasst die Verwendung eines Echtzeitsteuerungsprotokolls und eines Echtzeitprotokolls zwischen dem Client-Gerät und der assoziierten Quelle von jedem der Vielzahl von Videodatenströmen (Schritt 41). Wiederum, wie hierin beschrieben, ist es eine Aufgabe des RTP-Protokoll-Verfahrens 40 eine standardkonforme, drahtlose Signalisierung zwischen dem Client-Gerät und den assoziierten Quellen aufrechtzuerhalten. Das RTP-Protokoll-Verfahren 40 umfasst Betreiben jeder der assoziierten Quellen von jedem der Vielzahl von Videodatenströmen gemäß dem Echtzeitsteuerungsprotokoll und dem Echtzeitprotokoll (Schritt 42). Das RTP-Protokoll-Verfahren 40 umfasst Bestimmen der modifizierten Rückmeldung durch das Client-Gerät (Schritt 43).
Das RTP-Protokoll-Verfahren 40 umfasst ferner Übertragen der modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen an die assoziierten Quellen von jedem der Vielzahl von Videodatenströmen, ohne Erweiterungen oder Modifikationen an dem Echtzeitsteuerungsprotokoll und an dem Echtzeitprotokoll zu erfordern (Schritt 44). Das RTP-Protokoll-Verfahren 40 umfasst ferner Bestimmen der Rückmeldung für jeden der Vielzahl von Videodatenströmen unter Verwendung des Paketverlustverhältnisses (Schritt 45). Das RTP-Protokoll-Verfahren 40 umfasst ferner Übertragen der modifizierten Rückmeldung in einem Empfangsberichtspaket an jede der assoziierten Quellen von jedem der Vielzahl von Videodatenströmen. Zu beachten ist, dass das Empfangsberichtspaket in RFC 3550 definiert ist.
Unter Bezugnahme auf 5, in einem Ausführungsbeispiel, zeigt ein Flussdiagramm eines Gemittelter-Bericht-Verfahrens 50 zur Verwendung mit dem Client-basierten Verfahren 30 der 3. Beispielsweise kann das Gemittelter-Bericht-Verfahren 50 eine Implementierung der hier beschriebenen ”gemittelten” Berichte sein. Das Gemittelter-Bericht-Verfahren 50 umfasst Gruppieren der Vielzahl von Videodatenströmen als Einzeldatenstrom zum Bestimmen der Rückmeldung (Schritt 51). Es ist zu beachten, dass die Vielzahl von Videodatenströmen weiterhin separat empfangen und angezeigt wird, aber für die Rückmeldungsbestimmung gruppiert ist. Das Gemittelter-Bericht-Verfahren 50 umfasst Berechnen eines Paketverlustverhältnisses über den Einzeldatenstrom (Schritt 52).
Das Gemittelter-Bericht-Verfahren 50 umfasst ferner Bestimmen eines gewichteten Durchschnitts des Paketverlustverhältnisses (Schritt 53). Zum Beispiel kann dieses Bestimmen durch die folgende Gleichung durchgeführt werden:
Wobei PLR_t das Gesamtpaketverlustverhältnis (PLR) ist, PLR_i die PLR einzelner Videodatenströme i ist, wobei i die Anzahl der Videodatenströme, und R_i die Bitrate der einzelnen Videodatenströme ist.
Das Gemittelter-Bericht-Verfahren 50 umfasst ferner Übertragen des gewichteten Durchschnitts in einem Empfängerberichtspaket an jede der assoziierten Quellen von jedem der Vielzahl von Videodatenströmen (Schritt 54). Schließlich umfasst das Gemittelter-Bericht-Verfahren 50 ein Hochschalten oder ein Herunterschalten zu einem der Vielzahl von assoziierten Profilen an jeder der assoziierten Quellen von jedem der Vielzahl von Videodatenströmen in einer ähnlichen, einheitlichen Weise nach Empfang des gewichteten Durchschnitts in dem Empfängerberichtspaket.
Unter Bezugnahme auf 6, in einem Ausführungsbeispiel, zeigt ein Flussdiagramm eines Manipulierter-Bericht-Verfahrens 60 zur Verwendung mit dem Client-basierten Verfahren 30 der 3. So kann beispielsweise Manipulierter-Bericht-Verfahren 60 eine Implementierung der hierin beschriebenen ”manipulierten” Berichte sein. Das Manipulierter-Bericht-Verfahren 60 umfasst Bestimmen einer verfügbaren Bandbreite für das Client-Gerät über die drahtlose Verbindung (Schritt 61). Das Manipulierter-Bericht-Verfahren 60 umfasst Bestimmen einer aktuellen Bandbreite für jeden der Vielzahl von Videodatenströmen, wobei die aktuelle Bandbreite für jeden der Vielzahl von Videodatenströmen auf der Rückmeldung für jeden der Vielzahl von Videodatenströmen basiert (Schritt 62).
Das Manipulierter-Bericht-Verfahren 60 umfasst Bestimmen der modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen, so dass jede der Vielzahl von Videodatenströmen eine im Wesentlichen gleiche Menge der verfügbaren Bandbreite verwendet (Schritt 63). In einem Ausführungsbeispiel arbeiten zumindest zwei der Vielzahl von Videodatenströmen nach unterschiedlichen Profilen der Vielzahl von assoziierten Profilen. Genauer gesagt, schaltet das Manipulierter-Bericht-Verfahren 60 die Vielzahl der Videodatenströme nicht konsolidiert oder einheitlich hoch und/oder herunter. Vielmehr versucht das Manipulierter-Bericht-Verfahren 60, die erwartete Bitrate an dem Client-Gerät zu verwalten, so dass jeder der Vielzahl von Videodatenströmen im Wesentlichen die gleiche Menge an Bandbreite aufweist.
Unter Bezugnahme auf 7, in einem Ausführungsbeispiel, zeigt ein Flussdiagramm ein Hochschalte-/Herunterschalte-Verfahren 70 zur Verwendung mit dem Client-basierten Verfahren 30 der 3. Das Hochschalte-/Herunterschalte-Verfahren 70 umfasst, nach dem Übertragen der modifizierten Rückmeldung und wenn die modifizierte Rückmeldung oberhalb einer Herunterschalt-Schwelle liegt, Empfangen der Vielzahl von Videodatenströmen auf dem Client-Gerät über die drahtlose Verbindung mit jeder der Vielzahl von Videodatenströmen, die zu einem aus der Vielzahl von assoziierten Profilen heruntergeschaltet sind (Schritt 71). Das Hochschalte-/Herunterschalte-Verfahren 70 umfasst, nach dem Übertragen der modifizierten Rückmeldung und wenn die modifizierte Rückmeldung unterhalb einer Hochschalt-Schwelle liegt, Empfangen der Vielzahl von Videodatenströmen auf dem Client-Gerät über die drahtlose Verbindung mit jeder der Vielzahl von Videodatenströmen, die zu einem aus der Vielzahl von assoziierten Profilen hochgeschaltet sind (Schritt 72).
Das Hochschalte-/Herunterschalte-Verfahren 70 umfasst, nach dem Hochschalten, wenn das Client-Gerät unterhalb einer Schwelle liegende Paketverluste erfährt, Aufrechterhalten der Vielzahl von Videodatenströmen, die zu einem der Vielzahl von assoziierten hochgeschaltet sind (Schritt 73). Das Hochschalte-/Herunterschalte-Verfahren 70 umfasst ferner, wenn das Client-Gerät an oder oberhalb einer Schwelle liegender Paketverluste erfährt, Durchführen eines Back-off-Prozesses, bis das Client-Gerät Paketverluste unterhalb der Schwelle erfährt (Schritt 74). Das Hochschalte-/Herunterschalte-Verfahren 70 umfasst ferner das Ausführen des Back-Off-Prozesses durch Zurücksetzen eines Datenstroms aus der Vielzahl von Datenströmen mit einer höchsten Bitrate und Fortsetzen des Zurücksetzens weiterer Datenströme aus der Vielzahl von Datenströmen mit nächsthöheren Bitraten, bis das Client-Gerät Paketverluste unterhalb der Schwelle erfährt (Schritt 75).
Unter Bezugnahme auf 8, in einem Ausführungsbeispiel, zeigt ein Flussdiagramm ein UDP-Verfahren 80 zur Verwendung mit dem Client-basierten Verfahren 30 der 3. Das UDP-Verfahren 80 umfasst Betreiben jeder der assoziierten Quellen von jeder der Vielzahl von Videodatenströmen gemäß dem Nutzerdatenpaketprotokoll (Schritt 81). Das UDP-Verfahren 80 umfasst ferner Bestimmen der modifizierten Rückmeldung durch das Client-Gerät als ein durchschnittliches Paketverlustverhältnis über alle der Vielzahl von Videodatenströmen (Schritt 82). Schließlich umfasst das UDP-Verfahren 80 Übermitteln der modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen an die assoziierte Quelle von jeder der Vielzahl von Videodatenströmen ohne Erweiterungen oder Modifikationen an dem Nutzerdatenpaketprotokoll zu benötigen (Schritt 83).
Unter Bezugnahme auf 9, in einem Ausführungsbeispiel, zeigt ein Flussdiagramm ein Server-basiertes Verfahren 90 zur gleichmäßigen Aufteilung von Bandbreite auf mehrere Video-Streams. In einem Ausführungsbeispiel kann das Server-basierte Verfahren 90 durch den Server 20 in dem System 10 implementiert sein. Beispielsweise kann der Server 20 eine Netzwerkschnittstelle, die kommunikativ mit einem Netzwerk, beispielsweise dem Netzwerk 16, gekoppelt ist, einen Prozessor, der kommunikativ mit der Netzwerkschnittstelle gekoppelt ist, und einen Speicher umfassen, der Anweisungen speichert, die, wenn sie ausgeführt werden, bewirken, dass der Prozessor und die Netzwerkschnittstelle die hierin beschriebenen verschiedenen Schritte auszuführen. Das Server-basierte Verfahren 90 umfasst Übertragen einer Vielzahl von Videodatenströmen an ein Client-Gerät von zumindest einem Server, wobei jeder der Vielzahl von Videodatenströmen gemäß einem aus einer Vielzahl von assoziierten Profilen arbeitet (Schritt 91).
Das Server-basierte Verfahren 90 umfasst ferner Empfangen einer Rückmeldung für jeden der Vielzahl von Videodatenströmen, wobei die Rückmeldung durch eines von dem Client-Gerät und von dem zumindest einen Server modifiziert ist, so dass jeder der Vielzahl von Videodatenströmen im Wesentlichen dieselbe Bandbreite aufweist (Schritt 92). Die Rückmeldung kann durch die verschiedenen hierin beschriebenen Verfahren modifiziert werden. Das Server-basierte Verfahren 90 umfasst Bestimmen, ob Änderungen an den assoziierten Profilen von jedem der Vielzahl von Videodatenströmen vorgenommen werden müssen (Schritt 93). Schließlich kann das Server-basierte Verfahren 90, wenn Änderungen vorgenommen werden müssen, Übertragen der Vielzahl von Videodatenströmen gemäß anderen assoziierten Profilen der Vielzahl von assoziierten Profilen basierend auf den Änderungen umfassen (Schritt 94).
Unter Bezugnahme auf 10, in einem Ausführungsbeispiel, zeigt ein Flussdiagramm ein TCP-Verfahren 100 zur Verwendung mit dem Server-basierten Verfahren 90 von 9. Das TCP-Verfahren 100 umfasst Übertragen der Vielzahl von Videodatenströmen an das Client-Gerät von dem zumindest einen das Übertragungssteuerungsprotokoll verwendenden Server (Schritt 101). Das TCP-Verfahren 100 umfasst ferner Empfangen der Rückmeldung an dem zumindest einen Server über den Durchsatz über das Übertragungssteuerungsprotokoll (Schritt 102). Schließlich umfasst das TCP-Verfahren 100 Einstellen der Vielzahl von Videodatenströmen in einer konsolidierten Weise basierend auf dem Durchsatz über das Übertragungssteuerungsprotokoll (Schritt 103).
Unter Bezugnahme auf 11, in einem Ausführungsbeispiel, zeigt ein Diagramm einen beispielhaften Betrieb 200 eines Durchschnittlicher-Bericht-Verfahrens. Der beispielhafte Betrieb 200 umfasst fünf Datenströme 202 an das Client-Gerät 12, was ein Paketverlustverhältnis für eine Vielzahl von Berichtsintervalle 204 (beschriftet 204-1, 204-2, 204-n) aufweist. In dem ersten Berichtsintervall 204-1 weist der Datenstrom 1 ein PLR = 20% auf, Datenstrom 2 weist ein PLR = 25% auf, Datenstrom 3 weist ein PLR = 16% auf, Datenstrom 4 weist ein PLR = 19% auf, und der Datenstrom 5 weist ein PLR = 0% auf. Dies ergibt einen durchschnittlichen PLR = 16%, der jeder der zugeordneten Quellen von jedem der Datenströme 202 gemeldet wird. Das heißt, Datenstrom 1 meldet einen PLR = 16%, obwohl sein tatsächlicher PLR = 20% ist und so weiter. Unter der Annahme einer Schwelle von 15%, wird jeder der Datenströme im Berichtsintervall 204-1 herunterschalten. In dem Berichtsintervall 204-2, weist jeder Datenstrom ein PLR = 0% auf, außer dem Datenstrom 5, der ein PLR = 20% aufweist. So wird in dem Berichtsintervall 204-2 auf dieser Grundlage jeder Datenstrom ein PLR = 4% berichten.
Unter Bezugnahme auf 12, in einem Ausführungsbeispiel, zeigt ein Diagramm einen beispielhaften Betrieb 250 eines Manipulierter-Bericht-Verfahrens. Insbesondere ist der beispielhafte Betrieb 250 mit zwei Kurven 252, 254 aus vier Datenströmen 256 dargestellt. Die Kurve 252 stellt den tatsächlich erfahrenen Verlust von jedem der vier Datenströme 256 dar, das heißt 30%, 25%, 16%, und 29%. Die Kurve 254 stellt den unter Verwendung des Manipulierter-Bericht-Verfahrens berichteten tatsächlichen Verlust von jedem der vier Datenströme 256 dar. Insbesondere manipuliert der Client, der die vier Datenströme 256 empfängt, die an einen Server gesendeten aktuellen Berichte. In dem beispielhaften Betrieb 250 weist der erste Datenstrom eine hohe Priorität auf, so dass der Client das Paketverlustverhältnis auf 0% manipuliert und 0% berichtet. Der tatsächliche Verlust des ersten Datenstroms, das heißt 30%, kann gleichmäßig über die verbleibenden Datenströme verteilt werden, das heißt jeweils 10%. Somit wird unter Verwendung des Manipulierter-Bericht-Verfahrens der erste Datenstrom 1 aufgrund der manipulierten Berichte nicht heruntergeschaltet.
Unter Bezugnahme auf 13, in einem Ausführungsbeispiel, zeigt ein Blockdiagramm den Server 20 zur Verwendung in dem System 10 und den verschiedenen Verfahren. Der Server 20 kann ein digitaler Computer sein, der in Bezug auf die Hardware-Architektur im Allgemeinen einen Prozessor 302, Eingabe-/Ausgabe-(E/A)Schnittstellen 304, eine Netzwerkschnittstelle 306, einen Datenspeicher 308 und einen Speicher 310 umfasst. Es versteht sich für einen Fachmann, dass 13 den Server 20 in einer vereinfachten Weise zeigt, und eine praktische Ausführungsform zusätzliche Komponenten und eine geeignet ausgestaltete Verarbeitungslogik umfassen kann, um bekannte oder herkömmliche Betriebsfunktionen, die hier nicht im Detail beschrieben werden, zu unterstützen. Die Komponenten (302, 304, 306, 308 und 310) sind kommunikativ über eine lokale Schnittstelle 312 gekoppelt. Die lokale Schnittstelle 312 kann zum Beispiel, ist aber nicht darauf beschränkt, ein oder mehrere Busse oder andere drahtgebundene oder drahtlose Verbindungen aus dem Stand der Technik sein. Die lokale Schnittstelle 312 kann zusätzliche Elemente aufweisen, die der Einfachheit halber weggelassen werden, wie unter vielen anderen, Regler, Puffer (Zwischenspeicher), Treiber, Verstärker und Empfänger, um Kommunikationen zu ermöglichen. Ferner kann die lokale Schnittstelle 312 Adress-, Steuer- und/oder Datenverbindungen umfassen, um geeignete Kommunikationen zwischen den zuvor erwähnten Komponenten zu ermöglichen.
Der Prozessor 302 ist eine Hardwarevorrichtung zum Ausführen von Softwareanweisungen. Der Prozessor 302 kann jeder einzeln angefertigte oder ein kommerziell erhältlicher Prozessor, eine zentrale Verarbeitungseinheit (CPU), ein Hilfsprozessor unter mehreren Prozessoren, die mit dem Server 20 verbunden sind, ein Halbleiter-basierter Mikroprozessor (in der Form eines Mikrochips oder Chipsatzes), oder im Allgemeinen jede Vorrichtung zum Ausführen von Softwareanweisungen sein. Wenn der Server 20 in Betrieb ist, ist der Prozessor 302 dazu geeignet, die im Speicher 310 gespeicherte Software auszuführen, um Daten zu und von dem Speicher 310 zu übertragen und um allgemein Operationen des Servers 20 gemäß der Softwareanweisungen zu steuern. Die E/A-Schnittstellen 304 können verwendet werden, um von einem oder mehreren Geräten oder Komponenten Benutzereingaben zu empfangen und/oder Systemausgaben bereitzustellen. Benutzereingaben können zum Beispiel über eine Tastatur, ein Touchpad, und/oder eine Maus zur Verfügung gestellt werden. Eine Systemausgabe kann über eine Anzeigevorrichtung und einen Drucker (nicht gezeigt) ausgegeben werden. E/A-Schnittstellen 304 können zum Beispiel eine serielle Schnittstelle, eine parallele Schnittstelle, eine Kleincomputersystemschnittstelle (SCSI), eine serielle ATA (SATA), ein Faserkanal, Infiniband, iSCSI, eine PCI-Express-Schnittstelle (PCI-x), eine Infrarotschnittstelle (IR), eine Hochfrequenzschnittstelle (HF) und/oder eine Universeller-serieller-Bus-Schnittstelle (USB) sein.
Die Netzwerkschnittstelle 306 kann verwendet werden, um den Server 20 in die Lage zu versetzen, über ein Netzwerk zu kommunizieren, beispielsweise das Netzwerk 16, um Parameter, die mit mobilen Geräten assoziiert sind, zu empfangen. Die Netzwerkschnittstelle 306 kann zum Beispiel eine Ethernet-Karte oder ein Adapter (zum Beispiel 10 BaseT, Fast Ethernet, Gigabit Ethernet, 1 OGbE) oder eine Karte oder einen Adapter (zum Beispiel 802.11 a/b/g/n) für ein drahtloses lokales Netzwerk (WLAN) umfassen. Die Netzwerkschnittstelle 306 kann Adress-, Steuer- und/oder Datenverbindungen umfassen, um geeignete Kommunikationen auf dem Netzwerk zu ermöglichen. Ein Datenspeicher 308 kann verwendet werden, um Daten zu speichern. Der Datenspeicher 308 kann ein beliebiger aus flüchtigen Speicherelementen (beispielsweise einem Direktzugriffsspeicher (RAM, wie DRAM, SRAM, SDRAM und dergleichen)), nichtflüchtigen Speicherelementen (zum Beispiel ROM, Festplatte, Band, CDROM und dergleichen) und deren Kombinationen sein. Darüber hinaus kann der Datenspeicher 308 elektronische, magnetische, optische und/oder andere Arten von Speichermedien umfassen. In einem Beispiel kann der Datenspeicher 308 intern im Server 20 angeordnet sein, wie beispielsweise eine mit der lokalen Schnittstelle 312 verbundene interne Festplatte in dem Server 20. Zusätzlich kann der Datenspeicher 308 in einer anderen Ausführungsform außerhalb des Servers 20 angeordnet sein, wie beispielsweise eine mit E/A-Schnittstellen 304 verbundene externe Festplatte (zum Beispiel eine SCSI oder USB-Verbindung). In einer weiteren Ausführungsform kann der Datenspeicher 308 mit dem Server 20 über ein Netzwerk verbunden sein, beispielsweise einem netzgebundenen Datei-Server.
Der Speicher 310 kann ein Beliebiger aus flüchtigen Speicherelementen (beispielsweise einem Direktzugriffsspeicher (RAM, wie DRAM, SRAM, SDRAM und dergleichen)), nichtflüchtigen Speicherelementen (zum Beispiel ROM, Festplatte, Band, CDROM und dergleichen) und deren Kombinationen sein. Darüber hinaus kann der Speicher 310 elektronische, magnetische, optische und/oder andere Arten von Speichermedien umfassen. Es ist zu beachten, dass der Speicher 310 eine verteilte Architektur aufweisen kann, bei der verschiedene Komponenten entfernt voneinander angeordnet sind, aber auf die der Prozessor 302 zugreifen kann. Die Software auf dem Speicher 310 kann ein oder mehrere Softwareprogramme umfassen, von denen jedes eine geordnete Liste ausführbarer Befehle zur Implementierung logischer Funktionen umfasst. Die Software in dem Speicher 310 umfasst ein geeignetes Betriebssystem (BIS) 314 und ein oder mehrere Programme 316. Das Betriebssystem 314 steuert im Wesentlichen die Ausführung anderer Computerprogramme, wie zum Beispiel das eine oder die mehreren Programme 316, und stellt eine Terminierung, Eingabe-Aufgabe-Steuerung, eine Datei- und Datenverwaltung, eine Speicherverwaltung und eine Kommunikationssteuerung und verwandte Dienste bereit. Das eine oder die mehreren Programme 316 können geeignet sein, um hierin beschriebene verschiedene Prozesse, Algorithmen, Verfahren, Techniken, und so weiter zu implementieren. Zum Beispiel können die Programme 316 geeignet sein, um die hierin beschriebenen Verfahren zu ermöglichen.
Unter Bezugnahme auf 14, in einem Ausführungsbeispiel, zeigt ein Blockdiagramm das Client-Gerät 12 zur Verwendung in dem System 10 und den verschiedenen Verfahren. Das Client-Gerät 12 kann ein digitales Gerät sein, das, in Bezug auf die Hardwarearchitektur, allgemein einen Prozessor 412, eine Eingabe-/Ausgabe-(E/A)Schnittstelle 414, ein Radio 416, einen Datenspeicher 418 und einen Speicher 422 umfasst. Der Fachmann sollte erkennen, dass in 14 das Client-Gerät 12 in einer vereinfachten Weise dargestellt ist, und eine praktische Ausführungsform zusätzliche Komponenten und eine geeignet ausgestaltete Verarbeitungslogik umfassen kann, um bekannte oder herkömmliche Betriebsfunktionen, die hier nicht im Detail beschrieben werden, zu unterstützen. Die Komponenten (412, 414, 416, 418 und 422) sind kommunikativ über eine lokale Schnittstelle 424 gekoppelt. Die lokale Schnittstelle 424 kann bekannter Weise zum Beispiel, ist aber nicht darauf beschränkt, ein oder mehrere Busse oder andere drahtgebundene oder drahtlose Verbindungen sein. Die lokale Schnittstelle 424 kann zusätzliche Elemente aufweisen, die der Einfachheit halber weggelassen sind, wie, unter vielen anderen, Regler, Puffer (Zwischenspeicher), Treiber, Verstärker und Empfänger, um Kommunikationen zu ermöglichen. Ferner kann die lokale Schnittstelle 424 Adress-, Steuer- und/oder Datenverbindungen umfassen, um geeignete Kommunikationen zwischen den zuvor erwähnten Komponenten zu ermöglichen.
Der Prozessor 412 ist ein Hardwaregerät zum Ausführen von Softwarebefehlen. Der Prozessor 412 kann jeder einzeln angefertigte oder ein kommerziell erhältlicher Prozessor, eine zentrale Verarbeitungseinheit (CPU), ein Hilfsprozessor unter mehreren Prozessoren, die mit dem Client-Gerät 12 assoziiert sind, ein halbleiterbasierter Mikroprozessor (in der Form eines Mikrochips oder Chipsatzes) oder im allgemeinen jede Vorrichtung zum Ausführen von Softwarebefehlen sein. Wenn das Client-Gerät 12 im Betrieb ist, ist der Prozessor 412 dazu geeignet, die auf dem Speicher 422 gespeicherte Software auszuführen, um Daten zu und von dem Speicher 422 zu übertragen und um allgemein Operationen des Client-Geräts 12 nach den Anweisungen der Software zu steuern. In einer beispielhaften Ausführungsform kann der Prozessor 412 einen für mobile Anwendungen optimierten Prozessor umfassen, beispielsweise optimiert für die Leistungsaufnahme und mobile Anwendungen. Die E/A-Schnittstellen 414 können verwendet werden, um Benutzereingaben zu empfangen und/oder Systemausgaben bereitzustellen. Benutzereingaben können beispielsweise über eine Tastatur, einen Touchscreen, einen Scrollball, eine Bildlaufleiste, Knöpfe, Barcode-Scanner und dergleichen eingebeben werden. Eine Systemausgabe kann über ein Anzeigegerät, wie beispielsweise eine Flüssigkristallanzeige (LCD), einen Touchscreen, und dergleichen ausgegeben werden. Die E/A-Schnittstellen 414 können beispielsweise auch eine serielle Schnittstelle, eine parallele Schnittstelle, eine Kleincomputersysteminterface (SCSI), eine Infrarotschnittstelle (IR), eine Hochfrequenzschnittstelle (HF), eine Universeller-serieller-Bus-Schnittstelle (USB) und dergleichen umfassen. Die E/A-Schnittstellen 414 können eine grafische Benutzeroberfläche (GUI) umfassen, die es einem Benutzer ermöglicht, mit dem Client-Gerät 12 zu interagieren. Zusätzlich können die E/A-Schnittstellen 414 ferner ein Bilderzeugungsgerät, das heißt eine Kamera, Videokamera und so weiter umfassen.
Das Funkgerät 416 ermöglicht drahtlose Kommunikation mit einem externen Zugangsgerät oder Netzwerk. Eine beliebige Anzahl von geeigneten drahtlosen Datenkommunikationsprotokollen, Techniken oder Methoden können durch das Funkgerät 416 unterstützt werden, ohne Einschränkung fallen darunter: RF; LMR; IrDA (Infrarot); Bluetooth; ZigBee (und andere Varianten des IEEE 802.15-Protokolls); IEEE 802.11 (jede Variante); IEEE 802.16 (WiMAX oder jegliche weitere Variante); Direct Sequence Spread Spectrum; Frequency Hopping Spread Spectrum; Long Term Evolution (LTE); zelluläre/drahtlose/kabellose Telekommunikationsprotokolle (zum Beispiel 3G/4G, und so weiter); Drahtlos-Heimnetzwerk-Kommunikationsprotokolle; Seitenadressierungs-Netzwerkprotokolle; magnetische Induktion; Satelliten-Datenübertragungsprotokolle; drahtlose Krankenhaus- oder Gesundheitseinrichtungsnetzwerkprotokolle, wie sie in den WMTS Bändern betrieben werden; GPRS; proprietäre drahtlose Datenkommunikationsprotokolle wie Varianten von drahtlosem USB; und andere Protokolle für die drahtlose Kommunikation. Der Datenspeicher 418 kann verwendet werden, um Daten zu speichern. Der Datenspeicher 418 kann ein Beliebiger aus flüchtigen Speicherelementen (beispielsweise einen Direktzugriffsspeicher (RAM, wie DRAM, SRAM, SDRAM und dergleichen)), nichtflüchtigen Speicherelementen (zum Beispiel ROM, Festplatte, Band, CDROM und dergleichen) und deren Kombinationen sein. Darüber hinaus kann der Datenspeicher 418 elektronische, magnetische, optische und/oder andere Arten von Speichermedien umfassen.
Der Speicher 422 kann ein Beliebiger aus flüchtigen Speicherelementen (beispielsweise ein Direktzugriffsspeicher (RAM, wie DRAM, SRAM, SDRAM und dergleichen)), nichtflüchtigen Speicherelementen (zum Beispiel ROM, Festplatte, Band, CDROM und dergleichen) und deren Kombinationen sein. Darüber hinaus kann der Speicher 422 elektronische, magnetische, optische und/oder andere Arten von Speichermedien umfassen. Es ist zu beachten, dass der Speicher 422 eine verteilte Architektur aufweisen kann, bei der verschiedene Komponenten entfernt voneinander angeordnet sind, bei der verschiedene Komponenten entfernt voneinander angeordnet sind, aber auf die der Prozessor 412 zugreifen kann. Die Software in dem Speicher 422 kann ein oder mehrere Softwareprogramme umfassen, von denen jedes eine geordnete Liste von ausführbaren Befehlen zum Implementieren logischer Funktionen umfasst. In dem Beispiel von 13 umfasst die Software in dem Speichersystem 422 ein geeignetes Betriebssystem (B/S) 426 und Programme 428. Das Betriebssystem 426 steuert im Wesentlichen die Ausführung anderer Computerprogramme und stellt eine Terminierung, eine Eingabe-Ausgabe-Kontrolle, eine Datei- und Datenverwaltung, eine Speicherverwaltung und eine Kommunikationssteuerung und verwandte Dienste bereit. Die Programme 428 können verschiedene Anwendungen und Erweiterungen und so weiter umfassen, die geeignet sind, Endnutzer-Funktionalität auf dem Client-Gerät 12 bereit zu stellen. Zum Beispiel können Beispielprogramme 428, sind aber nicht beschränkt auf, einen Web-Browser, Soziale-Netzwerk-Anwendungen, Datenstrom-Medien-Anwendungen, Spiele, Kartierungs- und Lokalisierungsanwendungen, E-Mail-Anwendungen, Finanzanwendungen und dergleichen umfassen.
In einem Ausführungsbeispiel umfassen die Programme 428 Befehle, die, wenn sie ausgeführt werden, den Prozessor und die Netzwerkschnittstelle dazu veranlassen, eine Vielzahl von Videodatenströmen an einem Client-Gerät über das drahtlose Netzwerk zu empfangen, wobei jedes aus der Vielzahl von Videodatenströmen gemäß einem aus einer Vielzahl von assoziierten Profilen arbeitet, eine Rückmeldung für jeden der Vielzahl von Videodatenströmen zu bestimmen, eine modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen auf der Basis der Rückmeldung für jeden der Vielzahl von Videodatenströmen zu bestimmen, und die modifizierte Rückmeldung für jeden der Vielzahl von Videodatenströmen an eine assoziierte Quelle von jedem der Vielzahl von Videodatenströmen zu übertragen.
Die Befehle, wenn sie ausgeführt werden, können ferner den Prozessor und die Netzwerkschnittstelle dazu veranlassen: ein Echtzeitsteuerprotokoll und ein Echtzeitprotokoll zwischen der assoziierten Quelle für jeden der Vielzahl von Videodatenströmen zu verwenden, die Rückmeldung für jeden der Vielzahl von Videodatenströmen unter Verwendung eines Paketverlustverhältnisses zu bestimmen, und die modifizierte Rückmeldung in einem Empfängerberichtspaket für jeden der Vielzahl von Videodatenströmen zu der assoziierten Quelle von jedem der Vielzahl von Videodatenströmen zu übertragen, ohne Erweiterungen oder Modifikationen an dem Echtzeitsteuerprotokoll oder dem Echtzeitprotokoll zu benötigen. Die Befehle, wenn sie ausgeführt werden, können ferner den Prozessor und die Netzwerkschnittstelle dazu veranlassen: die Vielzahl von Videodatenströmen als Einzeldatenstrom zur Bestimmung der Rückmeldung zu gruppieren, ein Paketverlustverhältnis über den Einzeldatenstrom zu berechnen, einen gewichteten Durchschnitt des Paketverlustverhältnisses zu bestimmen und den gewichteten Durchschnitt in einem Empfängerberichtspaket an jede der assoziierten Quellen von jedem der Vielzahl von Videodatenströmen zu übertragen.
Die Befehle, wenn sie ausgeführt werden, können den Prozessor und die Netzwerkschnittstelle ferner dazu veranlassen: eine verfügbare Bandbreite für das Client-Gerät über die drahtlose Verbindung zu bestimmen, eine aktuelle Bandbreite für jeden der Vielzahl von Videodatenströmen zu bestimmen, wobei die aktuelle Bandbreite für jeden der Vielzahl von Videodatenströmen auf der Rückmeldung für jeden der Vielzahl von Videodatenströmen basiert, und die modifizierte Rückmeldung für jeden der Vielzahl von Videodatenströmen zu bestimmen, so dass jeder der Vielzahl von Videodatenströmen eine im Wesentlichen gleiche Menge der verfügbaren Bandbreite verwendet.
Die Befehle, wenn sie ausgeführt werden, können den Prozessor und die Netzwerkschnittstelle ferner dazu veranlassen: zwischen jeder der assoziierten Quellen für jeden der Vielzahl von Videodatenströmen gemäß dem Nutzerdatenstromprotokoll zu arbeiten, die modifizierte Rückmeldung als ein durchschnittliches Paketverlustverhältnis über alle der Vielzahl von Videodatenströmen zu bestimmen, und die modifizierte Rückmeldung für jeden der Vielzahl von Videodatenströmen an die assoziierten Quelle von jedem der Vielzahl von Videodatenströmen zu übertragen, ohne Erweiterungen oder Modifikationen an dem Nutzerdatenstromprotokoll zu benötigen.
In der vorangehenden Beschreibung wurden spezifische Ausführungsformen der vorliegenden Erfindung beschrieben. Aber ein Durchschnittsfachmann wird erkennen, dass unterschiedliche Modifikationen und Änderungen vorgenommen werden können, ohne den Schutzumfang der vorliegenden Erfindung, wie in den Ansprüchen unten angegeben, zu verlassen. Entsprechend sollen die Beschreibung und die Figuren eher in einem beispielhaften als in einem restriktiven Sinn verstanden werden, und alle solche Modifikationen sollen als in den Schutzumfang der vorliegenden Erfindung fallend gelten.
Der Nutzen, die Vorteile und die Lösungen zu Problemen und irgendein oder irgendwelche Element(e), die einen Nutzen, einen Vorteil oder eine Lösung hervorrufen oder hervorbringen, sollen nicht als ein kritisches, benötigtes oder wesentliches Merkmal oder Element von einem oder allen Ansprüchen angesehen werden. Die Erfindung wird allein durch die anliegenden Ansprüche, umfassend alle Änderungen, die während der Anhängigkeit dieser Anmeldung erfolgen, und alle Äquivalente dieser herausgegebenen Ansprüche, definiert.
Darüber hinaus können in diesem Dokument relative Begriffe, wie beispielsweise erster und zweiter, oberer und unterer, und dergleichen allein dafür genutzt sein, um eine Einheit oder Handlung von einer anderen Einheit oder Handlung zu unterscheiden, ohne zwingend vorauszusetzen oder zu implizieren, dass eine tatsächliche solche Relation oder Anordnung zwischen den Einheiten oder Handlungen besteht. Die Begriffe ”umfasst”, ”umfassend”, ”hat”, ”habend”, ”beinhaltet”, ”beinhaltend”, ”enthält”, ”enthaltend” oder dergleichen, sollen eine nicht-ausschließliche Einbindung darstellen, so dass ein Prozess, ein Verfahren, ein Gegenstand oder eine Vorrichtung, das/der/die eine Liste von Elementen umfasst, hat, beinhaltet, enthält, nicht nur diese Elemente beinhaltet, sondern auch andere Elemente, die nicht ausdrücklich aufgelistet oder zu einem solchen Prozess, Verfahren, Gegenstand oder Vorrichtung inhärent sind, beinhalten kann. Ein Element, dem ”umfasst... ein”, ”hat... ein”, ”beinhaltet... ein”, ”enthält... ein” vorangestellt ist, schließt nicht ohne weitere Einschränkungen die Existenz zusätzlicher identischer Elemente in dem Prozess, Verfahren, Gegenstand oder der Vorrichtung, welche das Element umfasst, hat, beinhaltet oder enthält, aus. Der Begriff ”ein” ist definiert als ein oder mehrere, wenn hierin nichts anderes ausdrücklich erwähnt wird. Die Begriffe ”wesentlich”, ”essentiell”, ”näherungsweise”, ”um” oder dergleichen, sind definiert als so nahe wie möglich als es der Fachmann verstehen würde, und in nicht einschränkender Weise ist der Begriff als innerhalb von 10%, in einer anderen Ausführungsform innerhalb von 5%, in einer anderen Ausführungsform innerhalb von 1% und in einer anderen Ausführungsform innerhalb von 0,1% liegend zu verstehen. Der hierin verwendete Begriff ”gekoppelt” ist als – wenn auch nicht zwingend – direkt oder – nicht zwingend – mechanisch definiert. Ein Gerät oder eine Struktur, die auf eine bestimmte Weise ”konfiguriert” ist, ist zumindest auf diese Weise konfiguriert, aber kann auch auf eine nicht aufgelistete andere Weise konfiguriert sein.
Es versteht sich, dass einige Ausführungsbeispiele aus einem oder mehreren generischen oder spezialisierten Prozessoren (oder ”Rechengeräten”) bestehen können, wie beispielweise aus Mikroprozessoren, digitalen Signalprozessoren, individuellen Prozessoren und im Feld programmierbaren Gatteranordnungen (FPGAs) und einzig-artigen gespeicherten Programmbefehlen (umfassend sowohl Software als auch Firmware), die den einen oder die mehreren Prozessoren steuern, um, in Verbindung mit bestimmten Nichtprozessorschaltkreisen, einige, die meisten oder alle der Funktionen des hierin beschriebenen Verfahrens und/oder der Vorrichtung zu implementieren. Alternativ könnten einige oder alle Funktionen durch einen Zustandsautomaten, der keine gespeicherten Programmbefehle aufweist, oder in einem oder mehreren anwendungsspezifischen integrierten Schaltkreisen (ASICs) implementiert werden, wobei jede Funktion oder einige Kombinationen spezieller Funktionen als individuelle Logik verwirklicht sind. Natürlich kann eine Kombination der beiden Herangehensweisen verwendet werden.
Darüber hinaus kann eine Ausführungsform als computerlesbares Speichermedium mit computerlesbarem Code, der darauf zur Programmierung eines Computers (beispielsweise umfassend einen Prozessor) zur Ausführung eines Verfahrens, wie beschrieben und beansprucht hierin gespeichert ist, implementiert sein. Beispiele solcher computerlesbaren Speichermedien umfassen, sind aber nicht beschränkt auf eine Festplatte, eine CD-ROM, ein optisches Speichergerät, ein magnetisches Speichergerät, ein ROM (Read Only Memory), ein PROM (Programmable Read Only Memory), ein EPROM (Erasable Programmable Read Only Memory), ein EEPROM (Electrically Erasable Programmable Read Only Memory) und einen Flashspeicher. Ferner wird erwartet, dass der Durchschnittsfachmann, ungeachtet möglichen signifikanten Aufwandes und ungeachtet vieler Konstruktionsentscheidungen, die beispielsweise von zur Verfügung stehender Zeit, gegenwärtiger Technologie und ökonomischen Überlegungen beeinflusst sind, wenn er von den hier offenbarten Konzepten und Prinzipien angeleitet ist, schnell in der Lage ist, solche Softwarebefehle und Programme und integrierten Schaltkreise mit minimalem Versuchsaufwand zu erzeugen.
Die Zusammenfassung der Offenbarung wird zur Verfügung gestellt, um dem Leser die Natur der technischen Offenbarung schnell zu vermitteln. Sie wird mit dem Verständnis übermittelt, dass sie nicht für die Interpretation oder Beschränkung des Schutzumfangs oder der Bedeutung der Ansprüche herangezogen wird. Zusätzlich kann der vorangegangenen detaillierten Beschreibung entnommen werden, dass unterschiedliche Merkmale in unterschiedlichen Ausführungsformen zusammen gruppiert sind, um die Offenbarung zu straffen. Diese Offenbarungsmethode darf nicht als Absicht zu einer Wiedergabe interpretiert werden, dass die beanspruchten Ausführungsformen mehr Merkmale benötigen als ausdrücklich in jedem Anspruch wiedergegeben sind. Vielmehr, wie die nachfolgenden Ansprüche wiederspiegeln, liegt der erfinderische Gegenstand in weniger als allen Merkmalen eines einzigen offenbarten Ausführungsbeispiels. Daher sind die nachfolgenden Ansprüche hiermit in die detaillierte Beschreibung eingebunden, wobei jeder Anspruch für sich selbst genommen als separat beanspruchter Gegenstand anzusehen ist.

Claims

Client-basiertes Verfahren, umfassend: Empfangen einer Vielzahl von Videodatenströmen an einem Client-Gerät über eine drahtlose Verbindung, wobei jeder der Vielzahl von Videodatenströmen gemäß einem aus einer Vielzahl von assoziierten Profilen arbeitet; Bestimmen einer Rückmeldung für jeden der Vielzahl von Videodatenströmen; Bestimmen einer modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen gemäß der Rückmeldung für jeden der Vielzahl von Videodatenströmen; und Übertragen der modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen an eine assoziierte Quelle von jedem der Vielzahl von Videodatenströmen.
Client-basiertes Verfahren nach Anspruch 1, ferner umfassend: Verwenden eines Echtzeit-Steuerprotokolls und eines Echtzeitprotokolls zwischen dem Client-Gerät und der assoziierten Quelle von jedem der Vielzahl von Videodatenströmen.
Client-basiertes Verfahren nach Anspruch 2, ferner umfassend: Bedienen jeder der assoziierten Quellen von jedem der Vielzahl von Videodatenströmen gemäß dem Echtzeit-Steuerprotokoll und dem Echtzeitprotokoll; Bestimmen der modifizierten Rückmeldung durch das Client-Gerät; und Übertragen der modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen an die assoziierte Quelle von jedem der Vielzahl von Videodatenströmen ohne Erweiterung oder Modifikationen an dem Echtzeit-Steuerprotokoll und dem Echtzeitprotokoll zu benötigen.
Client-basiertes Verfahren nach Anspruch 2, ferner umfassend: Bestimmen der Rückmeldung für jeden der Vielzahl von Videodatenströmen unter Verwendung eines Paketverlustverhältnisses; und Übertragen der modifizierten Rückmeldung in einem Empfangsmeldungspaket an jede der assoziierten Quellen von jedem der Vielzahl von Videodatenströmen.
Client-basiertes Verfahren nach Anspruch 1, ferner umfassend: Gruppieren der Vielzahl von Videodatenströmen als Einzeldatenstrom zur Bestimmung der Rückmeldung; Berechnen eines Paketverlustverhältnisses über den Einzeldatenstrom; Bestimmen eines gewichteten Durchschnitts des Paketverlustverhältnisses; und Übermitteln des gewichteten Durchschnitts in einem Empfangsmeldungspaket an jede der assoziierten Quellen von jedem der Vielzahl von Videodatenströmen.
Client-basiertes Verfahren nach Anspruch 5, ferner umfassend: Hochschalten oder Herunterschalten zu einem der Vielzahl von assoziierten Profilen an jeder der assoziierten Quellen von jedem der Vielzahl von Videodatenströmen in einer ähnlichen, uniformen Weise nach Empfang des gewichteten Durchschnitts in dem Empfangsmeldungspaket.
Client-basiertes Verfahren nach Anspruch 1, ferner umfassend: Bestimmen einer verfügbaren Bandbreite für das Client-Gerät über die drahtlose Verbindung; Bestimmen einer aktuellen Bandbreit für jeden der Vielzahl von Videodatenströmen, wobei die aktuelle Bandbreite für jeden der Vielzahl von Videodatenströmen auf der Rückmeldung für jeden der Vielzahl von Videodatenströmen basiert; und Bestimmen der modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen, so dass jeder der Vielzahl von Videodatenströmen im Wesentlichen die gleiche Menge von der verfügbaren Bandbreite verwendet.
Client-basiertes Verfahren nach Anspruch 7, wobei zumindest zwei der Vielzahl von Videodatenströmen gemäß unterschiedlichen Profilen aus der Vielzahl von assoziierten Profilen betrieben werden.
Client-basiertes Verfahren nach Anspruch 1, ferner umfassend: nach dem Übertragen der modifizierten Rückmeldung und wenn die modifizierte Rückmeldung oberhalb einer Herunterschalt-Schwelle liegt, Empfangen der Vielzahl von Videodatenströmen an dem Client-Gerät über eine drahtlose Verbindung mit jedem der Vielzahl von Videodatenströmen, die zu einem der Vielzahl von assoziierten Profilen heruntergeschaltet sind.
Client-basiertes Verfahren nach Anspruch 1, ferner umfassend: nach dem Übertragen der modifizierten Rückmeldung und wenn die modifizierte Rückmeldung unterhalb einer Hochschalt-Schwelle liegt, Empfangen der Vielzahl von Videodatenströmen an dem Client-Gerät über die drahtlose Verbindung mit jedem der Vielzahl von Videodatenströmen, die zu einem der Vielzahl von assoziierten Profilen hochgeschaltet sind.
Client-basiertes Verfahren nach Anspruch 10, ferner umfassend: wenn das Client-Gerät unterhalb einer Schwelle liegende Paketverluste erfährt, Aufrechterhalten der Vielzahl von Videodatenströmen, die zu einem der Vielzahl von assoziierten [Profilen] hochgeschaltet sind; und wenn das Client-Gerät Paketverluste an oder über der Schwelle erfährt, Ausführen eines Back-Off-Prozesses bis das Clientgerät Paketverluste unterhalb der Schwelle erfährt.
Client-basiertes Verfahren nach Anspruch 11, ferner umfassend: Ausführen des Back-Off-Prozesses durch Zurücksetzen eines Datenstroms der Vielzahl von Datenströmen mit einer höchsten Bitrate und Fortsetzen eines Zurücksetzens weiterer Datenströme der Vielzahl von Datenströmen mit nächsthöheren Bitraten bis das Client-Gerät Paketverluste unterhalb der Schwelle erfährt.
Client-basiertes Verfahren nach Anspruch 1, ferner umfassend: Bedienen jeder der assoziierten Quellen von jeder der Vielzahl von Videodatenströmen gemäß dem Nutzerdatenpaketprotokoll; Bestimmen der modifizierten Rückmeldung durch das Client-Gerät als ein durchschnittliches Paketverlustverhältnis über alle der Vielzahl von Videodatenströmen; und Übermitteln der modifizierten Rückmeldung für jeden der Vielzahl von Videodatenströmen an die assoziierte Quelle von jeder der Vielzahl von Videodatenströmen, ohne Erweiterungen oder Modifikationen an dem Nutzerdatenpaketprotokoll zu benötigen.
Server-basiertes Verfahren, umfassend: Übertragen eine Vielzahl von Videodatenströmen an ein Client-Gerät von zumindest einem Server, wobei jeder der Vielzahl von Videodatenströmen gemäß einem aus einer Vielzahl von assoziierten Profilen arbeitet; Empfangen einer Rückmeldung für jeden der Vielzahl von Videodatenströmen, wobei die Rückmeldung durch eines der Client-Geräte und zumindest den einen Server modifiziert ist, so dass jeder der Vielzahl von Videodatenströmen im Wesentlichen dieselbe Bandbreite aufweist; Bestimmen, ob Änderungen an assoziierten Profilen von jedem der Vielzahl von Videodatenströmen vorgenommen werden müssen; und wenn Änderungen vorgenommen werden müssen, Übertragen der Vielzahl von Videodatenströmen gemäß anderen assoziierten Profilen der Vielzahl von assoziierten Profilen basierend auf den Änderungen.
Server-basiertes Verfahren nach Anspruch 14, ferner umfassend: Übertragen der Vielzahl von Videodatenströmen an das Client-Gerät von dem zumindest einen ein Übertragungssteuerungsprotokoll verwendenden Server; Empfangen der Rückmeldung an dem zumindest einen Server über ein Durchreichen über das Übertragungssteuerungsprotokoll; und Einstellen der Vielzahl von Videodatenströmen in einer konsolidierten Weise basierend auf dem Durchreichen über das Übertragungssteuerungsprotokoll.
Client-Gerät, umfassend: eine Netzwerkschnittstelle, die kommunikativ mit einem drahtlosen Netzwerk gekoppelt ist; einen Prozessor, dem mit der Netzwerkschnittstelle kommunikativ gekoppelt ist; und Befehle speichernden Speicher, die, wenn ausgeführt, den Prozessor und die Netzwerkschnittstelle veranlassen: eine Vielzahl von Videodatenströmen an einem Client-Gerät über eine drahtlose Verbindung, wobei jeder der Vielzahl von Videodatenströmen gemäß einem aus einer Vielzahl von assoziierten Profilen arbeitet, zu empfangen; eine Rückmeldung für jeden der Vielzahl von Videodatenströmen zu bestimmen; eine modifizierte Rückmeldung für jeden der Vielzahl von Videodatenströmen gemäß der Rückmeldung für jeden der Vielzahl von Videodatenströmen zu bestimmen; und die modifizierte Rückmeldung für jeden der Vielzahl von Videodatenströmen an eine assoziierte Quelle von jedem der Vielzahl von Videodatenströmen zu übertragen.
Client-Gerät nach Anspruch 16, wobei die Befehle, wenn sie ausgeführt werden, ferner den Prozessor und die Netzwerkschnittstelle dazu veranlassen: ein Echtzeitsteuerungsprotokoll und ein Echtzeitprotokoll zwischen den assoziierten Quellen von jedem der Vielzahl von Videodatenströmen zu verwenden; die Rückmeldung für jede der Vielzahl von Videodatenströmen unter Verwendung eines Paketverlustverhältnisses zu bestimmen; und die modifizierte Rückmeldung in einem Empfangsmeldungspaket für jede der Vielzahl von Videodatenströmen an die assoziierte Quelle von jeder der Vielzahl von Videodatenströmen zu übertragen, ohne Erweiterungen oder Modifikationen an dem Echtzeitsteuerungsprotokoll und dem Echtzeitprotokoll zu benötigen.
Client-Gerät nach Anspruch 16, wobei die Befehle, wenn sie ausgeführt werden, ferner den Prozessor und die Netzwerkschnittstelle dazu veranlassen: die Vielzahl der Videodatenströme als einen Einzeldatenstrom zur Bestimmung der Rückmeldung zu gruppieren; ein Paketverlustverhältnis über den Einzeldatenstrom zu berechnen; einen gewichteten Durchschnitt des Paketverlustverhältnisses zu bestimmten; und den gewichteten Durchschnitt in einem Empfangsmeldungspaket an jede der assoziierten Quellen von jeder der Vielzahl von Videodatenströmen zu übertragen.
Client-Gerät nach Anspruch 16, wobei die Befehle, wenn sie ausgeführt werden, ferner den Prozessor und die Netzwerkschnittstelle dazu veranlassen: eine verfügbare Bandbreite für das Client-Gerät über die drahtlose Verbindung zu bestimmen; eine aktuelle Bandbreite für jede der Vielzahl von Videodatenströmen zu bestimmen, wobei die aktuelle Bandbreite für jeden der Vielzahl von Videodatenströmen auf der Rückmeldung für jeden der Vielzahl von Videodatenströmen basiert; und die modifizierte Rückmeldung für jeden der Vielzahl von Videodatenströmen zu bestimmen, so dass jeder der Vielzahl von Videodatenströmen im Wesentlichen die gleiche Menge von der verfügbaren Bandbreite verwendet.
Client-Gerät nach Anspruch 16, wobei die Befehle, wenn sie ausgeführt werden, ferner den Prozessor und die Netzwerkschnittstelle dazu veranlassen: zwischen jeder der assoziierten Quellen von jeder der Vielzahl von Videodatenströmen gemäß dem Nutzerdatenpaketprotokoll zu arbeiten; die modifizierten Rückmeldung als ein durchschnittliches Paketverlustverhältnis über alle der Vielzahl von Videodatenströmen zu bestimmen; und die modifizierte Rückmeldung für jeden der Vielzahl von Videodatenströmen an die assoziierte Quelle von jeder der Vielzahl von Videodatenströmen zu übertragen, ohne Erweiterungen oder Modifikationen an dem Nutzerdatenpaketprotokoll zu benötigen.