DE602004003933T2 - Rückkopplungssteuerung für Multicast und Broadcast Dienste - Google Patents

Rückkopplungssteuerung für Multicast und Broadcast Dienste Download PDF

Info

Publication number
DE602004003933T2
DE602004003933T2 DE602004003933T DE602004003933T DE602004003933T2 DE 602004003933 T2 DE602004003933 T2 DE 602004003933T2 DE 602004003933 T DE602004003933 T DE 602004003933T DE 602004003933 T DE602004003933 T DE 602004003933T DE 602004003933 T2 DE602004003933 T2 DE 602004003933T2
Authority
DE
Germany
Prior art keywords
feedback
multicast
control unit
broadcast service
protocol
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE602004003933T
Other languages
English (en)
Other versions
DE602004003933D1 (de
Inventor
Jose Rey
Ivica Rimac
Rolf Hakenberg
Ralf Becker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Publication of DE602004003933D1 publication Critical patent/DE602004003933D1/de
Application granted granted Critical
Publication of DE602004003933T2 publication Critical patent/DE602004003933T2/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services

Description

  • GEBIET DER ERFINDUNG
  • Die Erfindung betrifft ein Verfahren für das Steuern des Sendens von Feedback mobiler Terminals, die über eine Funkschnittstelle eines mobilen Kommunikationssystems einen Multicast- oder Broadcast-Service empfangen, der durch eine Feedbacksteuereinheit übertragen oder weitergeleitet wird, und ein mobiles Terminal und die Feedbacksteuereinheit, die dieses Verfahren verwendet. Weiter wird ein Kommunikationssystem zur Verfügung gestellt, das eine Feedbacksteuereinheit und ein mobiles Terminal, das einen Multicast- oder Broadcast-Service empfängt, umfasst.
  • TECHNISCHER HINTERGRUND
  • Das Echtzeit-Transportprotokoll (RTP) (siehe Schulzrinne et al. „RTP: A Transport Protocol for Real-Time Applications", RFC 3550, verfügbar über http://www.ietf.org) stellt Ende-zu-Ende-Netztransportfunktionen zur Verfügung, die für Anwendungen verwendbar sind, die Echtzeitdaten, wie Audio-, Video- oder Simulationsdaten, über Multicast- oder Unicast-Netzdienste übertragen. RTP adressiert keine Ressourcenreservierung und garantiert keinen Quality-of-Service für Echtzeitdienste.
  • Der Datentransport wird durch ein Steuerprotokoll (RTCP) zur Überwachung der Datenanlieferung auf eine Weise, die auf große Multicast-Netze skalierbar ist, und um eine minimale Steuer- und Kennzeichnungsfunktionalität zur Verfügung zu stellen, erweitert. RTP und RTCP sind so entworfen worden, dass sie von den zugrundeliegenden Transport- und Netzschichten unabhängig sind.
  • Für den Multicast- oder Broadcast-Datentransport von Streaming-Services in 3G-Netzen kann das RTP verwendet werden. Wie oben erwähnt, stellt das Echtzeitsteuerprotokoll (RTCP) Mittel für die Überwachung und das Transportieren von Steuerinformationen auf einem gelieferten RTP-Strom zur Verfügung.
  • Standard-RTP/RTCP
  • RTP (und sein Begleiterprotokoll RTCP) sind ursprünglich sowohl für den Unicast- als auch den Multicast-Datentransport (RTP-Benachrichtigungsing) entworfen worden. Infolgedessen sind skalierbare Algorithmen für das Verhindern von einer Feedbackimplosion und die entsprechenden Mechanismen vorgeschlagen worden. Im Rest dieses Dokumentes wird sich auf die letztere als "Standard-RTCP-Algorithmus und -mechanismen" bezogen.
  • RTCP-Standardalgorithmus und -mechanismen sind unter der Annahme eines zugrundeliegenden Any-Source-Multicast-(ASM)-Modells entworfen worden, in dem es jedem Endsystem erlaubt ist, Daten über den bidirektionalen Transportkanal zu senden und zu empfangen.
  • Infolgedessen empfängt jedes teilnehmende Endsystem die RTP-Daten und die RTCP-Senderbenachrichtigungen (SR) und Empfängerbenachrichtigungen (RR) aller Teilnehmer. Der Empfang aller RR ermöglicht es jedem Endsystem, die Zahl der Teilnehmer einer Sitzung unabhängig von einander zu schätzen und diesen Wert zu verwenden, um das Benachrichtigungszeitintervall entsprechend dem RTCP-Standardalgorithmus zu errechnen. Des weiteren stellt er ein Mittel für die Endhosts zur Verfügung, Informationen über alle Teilnehmer zur sammeln, die für einige Anwendungen, wie Klein-Gruppen-Konferenzen, nützlich sein könnten.
  • RTCP RR für unidirektionale Multicast-Kanäle
  • Das Source-Specific-Multicast-(SSM)-Modell, wie es in S. Bhattacharyya, Ed. „An Overview of Source-Specific Multicast (SSM)" (siehe RFC 3569, verfügbar über http://www.ietf.org), beschrieben ist kann für den Gebrauch in Verbindung mit der 3GPP-MBMS-Architektur, wie sie in 3GPP TR 23.846: "Multimedia Broadcast/Multicast (MBMS); Architecture and functional description (Release 6)", V6.1.0, Dezember 2003, verfügbar über http://www.3gpp.org., spezifiziert ist, besonders geeignet sein.
  • Das SSM-Multicast-Modell führt eine geringere Kompliziertheit verglichen mit ASM ein und ermöglicht eine Zugriffssteuerung auf Subskriptionsbasis. In dem SSM wird es jedem einzelne Endsystem erlaubt, Daten unter Verwendung eines unidirektionalen Multicast-Transportkanals übertragen. Nur jene Teilnehmer, die diesen Kanal abonniert haben, empfangen die Nachrichten.
  • Anders als in ASM können RTCP-Empfängerbenachrichtigungen nicht über diesen Multicast-Kanal übertragen werden. Diese Beschränkung für das SSM kann jedoch durch jeden Empfänger überwunden werden, der über einzelne Unicast-Transportkanäle Feedback zu dem Sender sendet, und wenn der Sender diese Nachrichten über den Multicast-Kanal entsprechend den spezifizierten Empfänger- und Sender-Benachrichtigungsbandbreitenwerten wiedergibt.
  • SDP-Bandbreiten-Modifizierer für RTCP
  • Die Standard-RTCP-Mechanismen skalieren die gesamte Steuerverkehrbandbreite auf 5 % der RTP-Sitzungsbandbreite. Für das Zielanwendungsszenario mit einem einzelnen Sender beträgt der Anteil S der RTP Bandbreite, der für Senderbenachrichtigungen (SR) zugewiesen wird 1,25 %, während dem Anteil R, der von den Endsystemen in gleicher Weise für Empfängerbenachrichtigungen (RR) geteilt wird, ein Wert von 3,75 % zugewiesen wird. Um eine Zuweisung der unterschiedlicher Allokationen zu unterstützen, ist das Signalisieren von RTCP-Bandbreiten-Modifizierern innerhalb des Session Description Protokolls (SDP) von Casner, „Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth" vorgeschlagen worden (siehe RFC 3556, verfügbar über http://www.ietf.org).
  • Der SDP-Fall für die bestimmte Sitzung kann durch zwei zusätzliche Parametern erweitert werden, wobei b = RS: <bandwidth-value> und b = RR: <bandwidth-value> die gesamte Sender- bzw. Empfängerbenachrichtigungsrate spezifiziert. Die Perhost-Allokation und das Benarhrichtigungszeitintervall werden entsprechend dem Standard-RTCP-Algorithmus bestimmt.
  • Multicast-Feedbackregelung
  • Der Hauptteil der vorhandenen Arbeiten innerhalb der IETF RMT Arbeitsgruppe betrifft das Problem des Unterdrückens eines redundanten Feedbacks, z.B. negative Bestätigungen von verlorenen Datenpaketen für eine zuverlässige Multicast-Übertragung. Andere Multicast-Anwendungen verlangen nach einem Feedback des Endsystems mit einem Extremwert entsprechend einer besonderen Metrik.
  • Das Ziel dieser Entwürfe ist es, den Empfänger mit den Begrenzungsfähigkeiten (Bandbreite) in einer Multicast-Sitzung zu finden, so dass der Sender die Übertragungsrate mit Bezug auf das Feedback dieses Empfängers regelt. Ende-zu-Ende-Lösungen zu beiden Problemen verwenden normalerweise unterschiedliche Varianten der Feedbacktimer oder der Pollingmechanismen.
  • Kaum eine der vorhandenen Arbeiten beschäftigt sich mit der Feedbackregelung für das Sammeln von Statusinformationen teilnehmender Empfänger in einem Multicast. Ein bekannter Mechanismus für Videostreaming-Anwendungen, der auf dem Sammeln von Empfängerstatusinfornationen basiert, wird in Bolet et al., "Scalable Feedback Control for Multicast Video Distribution in the Internet" (Proceedings von ACM/SIGCOMM 1994, Bd. 24, Nr. 4, Okt. 1994) dargestellt. Das Primärziel der vorgeschlagenen Mechanismen ist es, die Senderate der Pakete entsprechend den berichteten Statusinformationen zu regeln.
  • Folglich wird der Satz der Zustände, über die ein Empfänger berichten kann, auf nur drei unterschiedliche Zustände begrenzt. Infolgedessen ist dieser Ansatz wegen der folgenden Probleme nicht für das Regulieren des Feedbacks von einer Statistik in 3GPP-MBMS-Sitzungen anwendbar:
    Die Zahl der teilnehmenden Endsystemen muss durch jeden Empfänger mittels RTCP-RR erkannt werden. Dieses erfordert, dass jedes teilnehmende mobile Terminal (MT, UE) einen Punkt-zu-Punkt-Feedbackkanal zu dem Sender herstellt.
  • Der Sender würde dann alle RRs wiederzugeben oder sie zusammenzufassen haben und müsste diese Informationen über den unidirektionalen Multicast-Kanal weiterleiten. Die Probleme dieser Lösung im Zusammenhang mit einer zellularen und mobilen Umgebung sind offensichtlich:
    die Kosten für die Einrichtung und die Wartung der Feedbackkanäle (einer pro MT/UE), der Overhead auf dem Multicast-Kanal, das durch die wiedergegebenen Benachrichtigungen erzeugt wird, und
    der Energieverbrauchoverhead bei den Endgeräten, welche Statusinformationen dynamisch beibehalten und aktualisieren müssen.
  • Unicast-Feedbackkanäle können eine bedeutende Menge an Ressourcen innerhalb ei ner Zelle erfordern, wenn z.B. jeder Benutzer einen bestimmten Aufwärtsstreckenkanal haben soll, der zum Beispiel einen einzelnen Spreizcode aufweist. Diese Situation kann zu einer erhöhten Wahrscheinlichkeit für ein Rufblockieren und Handoff-Dropping in den entsprechenden Zelten führen.
  • Die Bandbreite pro Empfänger bRR wird mit dem Standardalgorithmus wie folgt errechnet:
    Figure 00050001
    mit dem minimalen Zeitintervali Tmin (z.B. 5 s), der RTCP-Paketgröße PRTCP, der gesamten Empfängerbenachrichtigungsbandbreite BRR (3.75 % der RTP-Bandbreite) und der Zahl der Empfänger N. Die Bandbreite pro Empfänger bRR ist als Funktion der Gruppengröße in 1 bildlich dargestellt.
  • Bandbreite pro Empfänger, wie sie mit dem Standard-RTCP-Algorithmus errechnet wird
  • Wegen der Gruppendynamik-Empfänger können während einer fortwährenden Sitzung hinzukommen oder sich entfernen – ist die effektive Bandbreite pro Empfänger nicht a priori bekannt und kann sich erheblich verändern. Um eine häufige Wiederherstellung von Feedbackkanälen zu vermeiden um sich der gegenwärtigen Gruppengröße anzupassen, müssten Empfängerfeedbackkanäle mit Ressourcen ausgestattet werden, die für das obere Limit, d.h. im schlimmsten Fall die maximale RR-Bandbreite aufgehoben werden. Als Folge könnten reservierte Ressourcen für die Feedbackkanäle sehr ineffizient benutzt werden.
  • Das RTCP-RR-Zeitintervall T wird durch den Standard-RTP Algorithmus wie folgt errechnet: T = max(Tmin,Tcalc)wobei
    Figure 00060001
    mit dem minimalen Zeitintervall Tmin, der Zahl der Empfänger n, der RTCP-Paketgröße PRTCP und der gesamten Empfängerbenachrichtigungsbandbreite BRR.
  • 2 zeigt das RR-Zeitintervall T (errechnet entsprechend den obigen Gleichungen) gegen die Zahl der Empfänger n, die an der RTP-Sitzung teilnehmen. Das Zeitintervall erhöht sich linear mit der Zahl der teilnehmenden Empfänger.
  • Um den quantitativen Effekt zu veranschaulichen, kann das folgende Beispiel des strömenden audio-visuellen Inhalts mit einer Datenrate von 64 kbps betrachtet werden. Für eine durchschnittliche RTCP-RR-Paketgröße von 120 Bytes und n = 100 wird das Benachrichtigungszeitintervall zu T100 = 40 s berechnet, d.h. für n = 9000 erreicht es bereits T9000 = 3600 s = 1 h.
  • Nach dem Standardalgorithmus legen Empfänger ihre Benachrichtigungspakete probabilistisch innerhalb des Intervalls (0,5T, 1,5T] einer konstanten Verteilung folgend fest. D.h. in dem oben genannten Beispiel wird erwartet, dass das erste Benachrichtigungspaket nach 20 s bzw. 0,5 h sendet. Offensichtlich ist dieses resultierende RR-Zeitintervall T für praktische Zwecke nicht annehmbar.
  • Wie oben erwähnt, nimmt der Standard-RTCP-Ansatz auf die Eigenschaften des ASM-Modells Bezug, in dem jedes Endsystem Daten über einen einzelnen bidirektionalen Kanal senden und empfangen kann und weiterhin die Möglichkeit des Verlustberichtes liefert. Das Intervall würde jedoch für 3GPP-MBMS-Services leicht die Dauer einer Sitzung übersteigen, wodurch das Benachrichtigen unbrauchbar wird.
  • Weiterhin soll es bemerkt werden, dass auch für eine Broadcast-Datenanlieferung es bedacht werden kann, dass Feedback von den Empfängern eines Broacdcast-Services gegeben wird, besonders wenn ebenso eine Berechnung auf Inhaltsbasis für die Broadcast-Datenanlieferung verwendet wird, in der die Qualität des empfangenen Inhalts für die Berechnung entscheidend sein kann. Im Gegensatz zu der auf Subskription gegründeten Berechnung, bei der nur die Tatsache, dass ein bestimmter Service empfangen wird, von Wichtigkeit ist.
  • Die oben erwähnten RTP und MBMS-spezifischen Probleme können auf Multicast- oder Broadcast-Services verallgemeinert werden, die an den mobilen Terminals über eine Funkschnittstelle unter Verwendung von Protokollen empfangen werden, die das Vorsehen von Feedback von den Empfangsterminals zu der sendenden Quelle, z.B. einem Multicast- oder Broadcast-Server, ermöglichen.
  • Aus der WO 2004/040928 A1 ist ein Verfahren für das Benachrichtigen für Multiuserservices in Funknetzen bekannt. Das Konzept dieses Dokumentes besteht darin, angesammelte Feedbackbenachrichtigungen auf der Grundlage der RNC-Kenntnis der Funkschnittstellenressourcen in einem Zwischennetzbereich zu erzeugen. Ein RTCP-Feedback von den Terminals kann für den Multiuserservice, d.h. für alle Empfänger des Multiuserservices, ausgeschaltet sein. In einer Variation können alle Empfänger des Multiuserservices durch das RNC konfiguriert werden, um ein ereignisbedingtes Feedback zur Verfügung zu stellen. Diese Informationen von den Empfängern können ebenso in dem RNC verwendet werden, um das angesammelte Feedback zu bilden.
  • Das Verfahren und das System, das in der WO 2004/040928 A1 vorgeschlagen ist, verwendet die Kenntnis des RNC über die Funkressourcen des mobilen Kommunikationssystems, um angesammelte Feedbackbenachrichtigungen zu erzeugen, die zu der Quelle des Multiuserservices, dem Server, übermittelt werden. Dadurch wird das Vorsehen des Multiuserservices gemäß dem Ende-zu-Ende-Konzept aufgeopfert, da das Verfahren, dass in diesem Dokument vorgeschlagen wird, Interaktionen und Datenaustausch von unterschiedlichen Schichten, wie z.B. der Sitzungsschicht und Funkressourcensteuerung, sowie proprietäre Erweiterungen zwischen der Funkressourcenverwaltung in dem RNC und dem Zwischennetzbereich erfordert, um Daten zu kommunizieren. Diese Erweiterungen sind nicht durchführbar, wenn die Architektur für das Bereitstellen eines Multicast- oder Broadcast-Services weit angelegt ist.
  • "The RTCP gateway: scaling real-time control bandwidth for wireless networks", von Brown, K, Computer Communications, Bd. 23, Nr. 14-15, Seiten 1470-1483, identifiziert verschiedene Defizite in der Skalierung des Echtzeitprotokolls (RTP), wenn es in Schmalband- oder Funknetzen verwendet wird (siehe Zusammenfassung). Das Dokument schlägt eine Konstruktion und Implementation eines Echtzeitsteuerprotokoll (RTCP)-Gateways an der Grenze zwischen drahtlosem und festem Netz vor, der die Häufigkeit und den Inhalt von Steuernachrichten ändert, die zwischen Teilnehmern in den jeweiligen Netzen ausgetauscht werden, um die Skalierungsfunktionen zur Verfügung zu stellen, die notwendig sind, es Funkteilnehmern zu ermöglichen, an Breitband konferenzsitzungen teilzunehmen. Die vorgeschlagene RTCP-Gateway-Funktionalität ist mit den meisten allgemein verwendeten Skalierungsstrategien kompatibel und beeinflusst die RTP-Funktionen in dem festen Netz nicht.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Das Ziel der vorliegenden Erfindung ist es, ein konfigurierbares und anpassungsfähiges Feedback für Multicast- oder Broadcast-Services zu ermöglichen, die über eine Funkschnittstelle bereitgestellt werden, die das Ende-zu-Ende-Sitzungskonzept beibehält. Ein anderes Ziel kann es sein, ein konfigurierbares und anpassungsfähiges Feedback für MBMS-Services zur Verfügung zu stellen, die unter Verwendung des RTP-Protokolls bereitgestellt werden.
  • Das Ziel wird durch den Gegenstand der unabhängigen Ansprüche gelöst. Vorteilhafte Ausführungsformen der vorliegenden Erfindung sind Gegenstände der abhängigen Ansprüche.
  • Einer der Grundgedanken der Erfindung ist es, nur einer Teilmenge von Terminals, die einen Multicast- oder Broadcast-Service von einer Feedbacksteuereinheit innerhalb des mobilen Kommunikationsnetzes empfangen, zu erlauben, der sendenden Quelle, d.h. der Feedbacksteuereinheit, Feedback zu geben. Dadurch ist es möglich, das Ende-zu-Ende-Konzept beizubehalten und die geschichtete Architektur der verwendeten Protokolle nicht zu unterbrechen. Eine andere Idee der Erfindung betrifft den Gebrauch einer statistischen Benutzeraufnahme, auf Grundlage dessen die Teilmenge der Terminals, die Feedback geben, bestimmt wird.
  • Entsprechend einer Ausführungsform der Erfindung wird ein Verfahren für das Steuern des Sendens von Feedback von mobilen Terminals, die über eine Funkschnittstelle eines mobilen Kommunikationssystems einen Multicast- oder Broadcastservice empfangen, der durch eine Feedbacksteuereinheit gesendet oder weitergeleitet wird, zur Verfügung gestellt. Entsprechend diesem Verfahren kann ein mobiles Terminal den Multicast- oder Brodcast-Service über einen unidirektionalen Downlink-Kanal und durch Verwenden eines unzuverlässigen Transportprotokolls und eines Sitzungsprotokolls empfangen, wobei das Sitzungsprotokoll eine Feedbackvorkehrung von Terminals konfiguriert, die den Multicast- oder Broadcast-Service empfangen. Weiterhin kann das mobile Terminal die Parameter empfangen, auf Grundlage derer es entscheiden kann, ob oder ob nicht es der Feedbacksteuereinheit Feedback gibt.
  • In einem Entscheidungsschritt kann das mobile Terminal entscheiden, ob der Feedbacksteuereinheit auf der Grundlage der empfangenen Parameter ein durch das Sitzungsprotokoll konfiguriertes Feedback für den Multicast- oder Broadcast-Service zur Verfügung gestellt wird, und für den Fall, dass entschieden wird, dass ein durch das Sitzungsprotokoll konfiguriertes Feedback gegeben werden soll, kann ein Bearer zum Bereitstellen von Feedback an die durch das Sitzungsprotokoll konfigurierte Feedbacksteuereinheit eingerichtet werden.
  • Nach dem Einrichten des Bearers kann das mobile Terminal über den eingerichteten Bearer an die Feedbacksteuereinheit ein durch das Sitzungsprotokoll konfiguriertes Feedback, welches eine Empfangsstatistik des genannten Multicast- oder Broadcast-Services anzeigt, senden.
  • Diese Ausführungsform hat den Vorteil, dass die mobilen Terminals auf der Grundlage eines Satzes von signalisierten Parametern (oder eines einzelnen Parameters) entscheiden können, ob ein durch das Sitzungsprotokoll konfiguriertes Feedback gegeben werden soll. Wie oben erwähnt, wird ein Bearer für das Übermitteln eines durch das Sitzungsprotokoll konfigurierten Feedbacks eingerichtet, falls das mobile Terminal entscheidet, ein durch das Sitzungsprotokoll konfiguriertes Feedback zur Verfügung zu stellen, so dass Ressourcen z.B. in dem Funkschaltnetz des mobilen Kommunikationssystems nur in diesem Fall dem mobilen Terminal zugeteilt werden.
  • In einer weiteren Ausführungsform der Erfindung, zeigen die Parameter, die an dem mobilen Terminal empfangen werden, einen Wahrscheinlichkeitswert für ein Wahrscheinlichkeitsexperiment an, auf Grundlage dessen das mobile Terminal entscheidet, ob eine durch das Sitzungsprotokoll konfiguriertes Feedback gegeben werden soll. Folglich kann die Entscheidung darüber, ob ein durch das Sitzungsprotokoll konfiguriertes Feedback gegeben werden soll, auf dem Resultat eines Wahrscheinlichkeitsexperimentes basieren, das durch das mobile Terminal durchgeführt wird, worin der empfangene Wahrscheinlichkeitswert verwendet wird, um dieses Experiment durchzuführen.
  • Durch die Verwendung einer Wahrscheinlichkeitsmetrik, die den mobilen Terminals signalisiert wird, die den Multicast- oder Broadcast-Service empfangen, kann die Größe der Daten (Parameter), die von einer Feedbacksteuereinheit des mobilen Kommunikationssystems empfangen werden, verringert werden, und es kann jedem mobilen Terminal, das die Wahrscheinlichkeitsmetrik empfängt, ermöglicht werden, autonom zu bestimmen, ob ein durch das Sitzungsprotokoll konfiguriertes Feedback gegeben werden soll. Details über die Verwendung von einem Wahrscheinlichkeitsexperiment für die Entscheidung, ob oder ob nicht Feedback gegeben wird, werden unten angegeben.
  • Entsprechend einer anderen Ausführungsform der Erfindung ist das Wahrscheinlichkeitsexperiment ein Bemoulli-Experiment. Dieses kann den Vorteil haben, das Näherungswerte, welche die Berechnungen vereinfachen, wenn das Experiment durchgeführt wird, verwendet werden können, um die Berechnungskomplexität an den mobilen Terminals zu verringern.
  • In einer weiteren Ausführungsform der Erfindung werden die Parameter über einen Multicast- oder Broadcast-Datenkanal empfangen, der den Multicast- oder Broadcast-Service bereitstellt. In diesem Fall können die Daten an das Terminal unter Verwendung eines unzuverlässigen Transportprotokoll, z.B. UDP, wie oben umrissen wurde, geliefert werden.
  • Das Verfahren entsprechend einer anderen Ausführungsform der Erfindung sieht vor, die Parameter über einen Nachrichtenkanal zu empfangen, auf dem der Multicast- oder Broadcast-Service zu den möglichen Empfängern kundgegeben wird. In einer Variation dieser Ausführungsform wird ein verlässliches Kommunikationsprotokoll für den Datentransport auf dem Nachrichtenkanal verwendet.
  • Diese Ausführungsform berücksichtigt, dass es wünschenswert sein kann, dass jeder der Terminals mindestens einmal die signalisierten Parameter in einer zuverlässigen Weise empfängt. In dem Fall, in dem die Parameter mittels eines unzuverlässigen Kommunikationsprotokolls zur Verfügung gestellt werden, kann es möglicherweise nicht gesichert sein, dass jedes empfangende Terminal die notwendigen Parameter für das Entscheiden, ob es ein durch das Sitzungsprotokoll konfiguriertes Feedback gegeben werden soll, besitzt.
  • Eine andere Ausführungsform der vorliegenden Erfindung sieht vor, dass die Parameter, die an dem mobilen Terminal empfangen werden, weiterhin den Zeitpunkt anzeigen, bis zum dem der/die Parameter gültig ist/sind. In einer Variation der Ausführungsform kann das mobile Terminal einen eingerichteten Bearer für das Übermitteln eines durch das Sitzungsprotokoll konfigurierten Feedbacks, in dem Fall freigeben, in dem der Zeitpunkt, der durch die Parameter angezeigt wird, erreicht wird.
  • Dadurch kann es gewährleistet werden, dass mobile Terminals überholte Parametersätze benutzen, um zu bestimmen, ob ein durch das Sitzungsprotokoll konfiguriertes Feedback von dem jeweiligen Terminal gegeben werden sollte oder nicht. Z.B. kann dieses auf Situationen anwendbar sein, in denen die Parameter, die von der Feedbacksteuereinheit empfangen werden, (z.B. regelmäßig) aktualisiert werden und unter Verwendung eines unzuverlässigen Transportmechanismus zur Verfügung gestellt werden. In diesem Fall kann es möglicherweise nicht gewährleistet werden, dass jedes Terminal erfolgreich eine Aktualisierung des Parametersatzes empfängt, so dass es möglich sein kann, den oben umrissenen Mechanismus der Anzeige einer Gültigkeitsperiode der Parameter vorzusehen.
  • Wie bereits oben angedeutet, erleichtert eine andere Ausführungsform der Erfindung die Neukonfiguration oder das Aktualisieren von Parametern. Das mobile Terminal kann Rekonfigurationsparameter empfangen, worin die Rekonfigurationsparameter die Parameter aktualisieren, die zuvor von der Feedbacksteuereinheit empfangen worden sind.
  • In einer Variation der Ausführungsform können die Rekonfigurationsparameter eine Flag umfassen, die anzeigt, ob eine Gültigkeitsperiode für die vorher empfangenen Parameter aktualisiert werden soll, d.h. die anzeigt, ob die Parameter so zu sagen für einen „zusätzlichen" Zeitabschnitt gültig sein sollen. In diesem Fall kann das mobile Terminal die Gültigkeitsperiode der vorher empfangenen Parameter auf der Grundlage dieser Flag aktualisieren.
  • In einer weiteren Ausführungsform können nur jene mobilen Terminals, die einen Bearer für das Bereitstellen ein durch das Sitzungsprotokoll konfiguriertes Feedback eingerichtet haben, die Gültigkeitsperiode aktualisieren.
  • Außerdem können entsprechend einer weiteren Ausführungsform der Erfindung die empfangenen Rekonfigurationsparameter eine (zusätzliche) Flag umfassen, die anzeigt, ob eine neue Entscheidung über das Übermitteln eines durch das Sitzungsprotokoll konfigurierten Feedbacks durch das mobile Terminal durchgeführt werden soll. Somit kann abhängig von der Flag das mobile Terminal gesteuert werden, um zu bestimmen, ob eine neue Entscheidung über das Geben eines durch das Sitzungsprotokoll konfigurierten Feedbacks.
  • Wenn die Flag anzeigt, dieses auszuführen, kann das mobile Terminal auf der Grundlage der empfangenen Rekonfigurationsparameter entscheiden, ob ein durch das Sitzungsprotokoll konfiguriertes Feedback für den Multicast- oder Broadcast-Service der Feedbacksteuereinheit gegeben werden soll. Wie vorher umrissen, kann in dem Fall, in dem entschieden wird, ein durch das Sitzungsprotokoll konfiguriertes Feedback zu geben, ein Bearer zum Übermitteln einers durch das Sitzungsprotokoll konfigurierten Feedbacks für die Feedbacksteuereinheit eingerichtet werden, und das mobile Terminal kann ein durch das Sitzungsprotokoll konfiguriertes Feedback, welches eine Empfangsstatistik des Multicast- oder Broadcast-Service anzeigt, über den eingerichteten Bearer an die Feedbacksteuereinheit übertragen.
  • Als nächstes werden weitere Ausführungsformen in Bezug auf den Betrieb der Feedbacksteuereinheit im folgenden umrissen. Es sollte beachtet werden, dass die Feedbacksteuereinheit in einem einzelnen Netzelement enthalten sein kann oder in einem Netzelement des mobilen Kommunikationsnetzes zusammen mit der Service-Quelle, d.h. dem Multicast- oder Broadcast-Service-Provider, enthalten sein kann. Eine der verschiedenen Ausführungsformen der vorliegenden Erfindung stellt ein Verfahren für das Steuern durch eine Feedbacksteuereinheit von dem Senden von Feedback einer Mehrzahl von mobilen Terminals zur Verfügung, die über eine Funkschnittstelle eines mobilen Kommunikationssystems einen Multicast- oder Broadcast-Service empfangen, der durch eine Feedbacksteuereinheit gesendet oder weitergeleitet wird. Entsprechend diesem Verfahren kann die Feedbacksteuereinheit den Multicast- oder Broadcast-Service über einen unidirektionalen Downlink-Kanal und unter Verwenden eines unzuverlässigen Transportprotokolls und eines Sitzungsprotokolls übertragen oder weiterleiten, wobei das Sitzungsprotokoll ein Feedbackgeben der Terminals konfiguriert, die den Multicast- oder Broadcast-Service empfangen.
  • Weiterhin kann die Feedbacksteuereinheit Parameter bestimmen, die es einem mobilen Terminal ermöglichen, zu entscheiden, ob ein durch das Sitzungsprotokoll konfiguriertes Feedback an die Feedbacksteuereinheit zur Verfügung gestellt wird, und kann jene Parameter an mindestens eine Teilmenge der Mehrzahl der mobilen Terminals senden, die den Multicast- oder Broadcast-Service empfangen. Dementsprechend kann die Feedbacksteuereinheit Feedback von einer Teilmenge der Mehrzahl der mobilen Terminals empfangen, welche die Parameter empfangen haben.
  • In einer anderen Ausführungsform der Erfindung bestimmt die Feedbacksteuereinheit die Parameter auf der Grundlage von Statusinformationen des Multicast- und Broadcast-Services, die durch die Feedbacksteuereinheit behalten werden oder von einer Netzeinheit des mobilen Kommunikationssystems empfangen werden.
  • In einer weiteren Ausführungsform der Erfindung können die Parameter, die durch die Feedbacksteuereinheit bestimmt werden, einen Wahrscheinlichkeitswert für ein Wahrscheinlichkeitsexperiment anzeigen, auf Grundlage derer das mobile Terminal entscheidet, ob ein durch das Sitzungsprotokoll konfiguriertes Feedback zur Verfügung gestellt wird. Somit kann entsprechend dieser Ausführungsform die Feedbacksteuereinheit die Wahrscheinlichkeitsmetrik feststellen, die von den mobilen Terminals für das Wahrscheinlichkeitsexperiment benutzt werden soll, und kann diese Metrik mindestens einer Teilmenge der Mehrzahl der mobilen Terminals signalisieren.
  • Wie bereits oben umrissen, sieht eine Ausführungsform der vorliegenden Erfindung vor, dass der/die Parameter über einen Nachrichtenkanal übertragen wird/werden, auf dem der Multicast- oder Broadcast-Service an die möglichen Empfänger kundgegeben wird. Weiterhin kann ein zuverlässiges Kommunikationsprotokoll für den Datentransport auf dem Nachrichtenkanal verwendet werden.
  • Entsprechend einer weiteren Ausführungsform kann die Feedbacksteuereinheit den Wahrscheinlichkeitswert auf der Grundlage der Zahl der Teilnehmer an dem Multicast- oder Broadcast-Service bestimmen. Die Zahl der Teilnehmer an dem Multicast- oder Broadcast-Service kann z.B. von auf den Multicast- oder Broadcast-Service bezogenen Statusinformationen erhalten werden.
  • In einer anderen Ausführungsform der Erfindung sind die auf den Multicast- oder Broadcast-Service bezogenen Statusinformationen innerhalb des MBMS UE Context oder des MBMS Bearer Context enthalten, die an der Feedbacksteuereinheit behalten werden. Alternativ können die Statusinformationen durch die Feedbacksteuereinheit von einer Netzeinheit des mobilen Kommunikationsnetzes erhalten werden, die MBMS UE Contexts oder einen MBMS Bearer Context behält.
  • In einer weiteren Ausführungsform der Erfindung kann die Feedbacksteuereinheit die Daten des Multicast- oder Broadcast-Services von einem Multicast- oder Broadrast-Service-Provider empfangen.
  • In einer Variation dieser Ausführungsform kann die Feedbacksteuereinheit ein durch das Sitzungsprotokoll konfiguriertes Feedback, das von den mobilen Terminals empfangen wird, zu dem Multicast- oder Broadcast-Service-Provider weiterleiten.
  • In einer weiteren Variation können die Daten des Multicast-Services zu der Feedbacksteuereinheit unter Verwendung eines Transportprotokolls und eines Sitzungsprotokolls transportiert werden. Die Feedbacksteuereinheit kann mindestens eines von dem Transportprotokoll und dem Sitzungsprotokoll in ein anderes Transportprotokoll bzw. Sitzungsprotokoll vor dem Versenden oder Weiterleiten der Daten des Multicast- oder Broadcast-Services zu den mobilen Terminals übersetzen.
  • Weiterhin kann es möglich sein, dass das Feedback für den Multicast-Service zu der Feedbacksteuereinheit unter Verwendung eines Transportprotokolls und eines Sitzungsprotokolls transportiert wird. In diesem Fall kann die Feedbacksteuereinheit weiterhin mindestens eines von dem Transportprotokoll und dem Sitzungsprotokoll in ein anderes Transportprotokoll bzw. Sitzungsprotokoll vor dem Weiterleiten des Feedbacks zu dem Multicast- oder Broadcast-Service-Provider übersetzen.
  • In einer anderen Variation dieser Ausführungsform bildet die Feedbacksteuereinheit ein Aggregat des durch das Sitzungsprotokoll konfigurierten Feedbacks aus, die von den mobilen Terminals empfangen wurde, und kann das Aggregat des Feedbacks, das als Feedbackinformationen empfangen wurde, an den Multicast- oder Broadrast-Service-Provider übertragen.
  • Eine weitere Ausführungsform der Erfindung betrifft die Service-Bereitstellung unter Verwendung von RTP. In dieser Ausführungsform wird der Multicast- oder Broadcast-Service unter Verwendung des RTP-Protokolls zur Verfügung gestellt, und Feedback wird unter Verwendung des RTCP-Protokolls gegeben, worin ein Teil der verfügbaren Bandbreite für eine Sitzung, die den Multicast- oder Broadcast-Service bereitstellt, den RTCP-Protokollnachrichten zugeteilt wird.
  • Weiterhin kann in einer Alternative das durch das Sitzungsprotokoll konfigurierte Feedback in Form von Empfängerbenachrichtigungen des RTCP-Protokolls zur Verfügung gestellt werden. Es sollte beachtet werden, dass entsprechend einer Ausführungsform der Erfindung, die Empfangsstatistik, die oben erwähnt wurde, den Informationen entsprechen kann, die innerhalb einer Empfängerbenachrichtigung entsprechend dem RTCP-Protokoll signalisiert wurden.
  • Entsprechend einer anderen Ausführungsform der vorliegenden Erfindung können die Parameter, die durch die Feedbacksteuereinheit übertragen werden und von dem mobilen Terminal empfangen werden, weiterhin das Benachrichtigungszeitintervall und die verfügbare Bandbreite zum Bereitstellen des Feedbacks unter Verwendung des RTCP-Protokolls anzeigen.
  • Die Parameter, die von der Feedbacksteuereinheit signalisiert werden, können innerhalb einer Senderbenachrichtigungsnachricht des RTCP-Protokolls enthalten sein, das von der Feedbacksteuereinheit übertragen wird.
  • Eine weitere Ausführungsform betrifft ein mobiles Terminal, das über eine Funkschnittstelle eines mobilen Kommunikationssystems einen Multicast- oder Broadcast-Service empfängt, der durch eine Feedbacksteuereinheit übertragen oder weitergeleitet wird. Das mobile Terminal kann einen Empfänger für das Empfangen des Multicast- oder Broadcast-Services über einen unidirektionalen Downlink-Kanal und unter Verwenden eines unzuverlässigen Transportprotokolls enthalten. Weiterhin kann das Terminal die Parameter empfangen, auf Grundlage derer das mobile Terminal entscheidet, ob ein durch das Sitzungsprotokoll konfiguriertes Feedback der Feedbacksteuereinheit übermittelt wird, einen Prozessor für das Entscheiden auf der Grundlage der empfangenen Parameter, ob ein durch das Sitzungsprotokoll konfiguriertes Feedback der Feedbacksteuereinheit gegeben wird, und für das Einrichten eines Bearers für das Übermitteln einers durch das Sitzungsprotokoll konfigurierten Feedbacks an die Feedbacksteuereinheit, in dem Fall, in dem entschieden wird, ein durch das Sitzungsprotokoll konfiguriertes Feedback zu geben, und einen Sender zum Senden eines durch das Sitzungsprotokoll konfigurierten Feedbacks, das eine Empfangsstatistik des Multicast- oder Broadcast-Service anzeigt, über den eingerichteten Bearer an die Feedbacksteuereinheit.
  • In einer anderen Ausführungsform der Erfindung kann das mobile Terminal weiterhin Mittel enthalten, die geeignet sind, um die Schritte durchzuführen, die durch das mobile Terminal in einer der verschiedenen Ausführungsformen des Feedbackteuerverfahrens durchgeführt werden, das oben umrissen wird.
  • Eine andere Ausführungsform der Erfindung stellt eine Feedbacksteuereinheit für das Steuern des Sendens von Feedback einer Mehrzahl von mobilen Terminals zur Verfügung, die einen Multicast- oder Broadcast-Service empfangen, der durch die Feedbacksteuereinheit über eine Funkschnittstelle eines mobilen Kommunikationssystems übertragen oder weitergeleitet wird. Entsprechend dieser Ausführungsform kann die Feedbacksteuereinheit einen Sender für das Versenden oder Weiterleiten des Multicast- oder Broadcast-Services über einen unidirektionalen Downlink-Kanal und unter Verwenden eines unzuverlässigen Transportprotokolls und eines Sitzungsprotokolls umfassen, wobei das Sitzungsprotokoll ein Feedbackgeben von Terminals konfiguriert, die den Multicast- oder Broadcast-Service empfangen. Weiterhin kann die Feedbacksteuereinheit weiter einen Prozessor für die Bestimmung von Parametern umfassen, die es einem mobilen Terminal ermöglichen, zu entscheiden, ob ein durch das Sitzungsprotokoll konfiguriertes Feedback der Feedbacksteuereinheit gegeben wird, wobei der Sender eingerichtet ist, die Parameter mindestens einer Teilmenge der Mehrzahl von mobilen Terminals zu übermitteln, die den Multicast- oder Broadband-Service empfangen, und einen Empfänger für das Empfangen eines durch das Sitzungsprotokoll konfigurierten Feedbacks von einer Teilmenge der Mehrzahl der mobilen Terminals, welche die Parameter empfangen haben.
  • In einer anderen Ausführungsform der Erfindung kann die Feedbacksteuereinheit weiterhin Mittel umfassen, die geeignet sind, um die Schritte durchzuführen, die durch die Feedbacksteuereinheit in einer der verschiedenen Ausführungsformen des Feedbackteuerverfahrens durchgeführt werden, das oben umrissen wird.
  • Weiterhin betrifft eine Ausführungsform der Erfindung ein mobiles Kommunikationssystem, das eine Feedbacksteuereinheit wie oben definiert und zumindest ein mobiles Terminal für das Empfangen eines Multicast- oder des Broadcast-Services von der Feedbacksteuereinheit über eine Funkschnittstelle wie oben definiert umfasst.
  • Eine weitere Ausführungsform der Erfindung betrifft einen computerlesbaren Datenträger zum Speichern von Anweisungen, die, wenn sie von einem Prozessor eines mobilen Terminals ausgeführt werden, den Prozessor veranlassen, das Senden von Feedback des mobilen Terminals, das über eine Funkschnittstelle eines mobilen Kommunikationssystems einen Multicast- oder Broadcast-Service empfängt, der durch eine Feedbacksteuereinheit gesendet oder weitergeleitet wird, zu steuern durch: Empfangen des Multi cast- oder Broadcast-Services über einen unidirektionalen Downlink-Kanal an dem mobilen Terminal unter Verwendung eines unzuverlässigen Transportprotokolls und eines Sitzungsprotokolls, worin das Sitzungsprotokoll eine Feedbackvorkehrung von Terminals konfiguriert, die den Multicast- oder Broadcast-Service empfangen, Empfangen von Parametern an dem mobilen Terminal, auf Grundlage derer das mobile Terminal entscheidet, ob der Feedbacksteuereinheit ein durch das Sitzungsprotokoll konfiguriertes Feedback zur Verfügung gestellt wird, Entscheiden von dem mobilen Terminal darüber, ob der Feedbacksteuereinheit auf der Grundlage der empfangenen Parameter ein durch das Sitzungsprotokoll konfiguriertes Feedback für den Multicast- oder Broadcast-Service zur Verfügung gestellt wird, Einrichten eines Bearers durch das mobile Terminal zum Übermitteln eines durch das Sitzungsprotokoll konfigurierten Feedbacks an die Feedbacksteuereinheit für den Fall, dass entschieden wird, dass ein durch das Sitzungsprotokoll konfiguriertes Feedback gegeben werden soll, und Senden von Feedback, welches eine Empfangsstatistik des Multicast- oder Broadcast-Services anzeigt, von dem mobilen Terminal über den eingerichteten Bearer an die Feedbacksteuereinheit.
  • In einer anderen Ausführungsform kann der computerlesbare Datenträger weiterhin Anweisungen speichern, die, wenn sie von dem Prozessor des mobilen Terminals ausgeführt werden, den Prozessor veranlassen, die Schritte auszuführen, die von dem mobilen Terminal in einer der verschiedenen Ausführungsformen des Feedbackteuerverfahren durchgeführt werden, das oben umrissen wird.
  • Außerdem stellt eine andere Ausführungsform der Erfindung einen computerlesbaren Datenträger für die Speicherung von Anweisungen zur Verfügung, die, wenn sie durch einen Prozessor einer Feedbacksteuereinheit ausgeführt werden, den Prozessor veranlassen, die Übertragung von Feedback von mobilen Terminals zu steuern, die über eine Funkschnittstelle eines mobilen Kommunikationssystems einen Multicast- oder Broadcast-Service empfangen, der von einer Feedbacksteuereinheit übermittelt oder weitergeleitet wird, durch Weiterleiten des Multicast- oder Broadcast-Services von der Feedbacksteuereinheit über einen unidirektionalen Downlink-Kanal an mindestens ein mobiles Terminal und Verwenden eines unzuverlässigen Transportprotokoll und eines Sitzungsprotokolls, wobei das Sitzungsprotokoll ein Feedbackgeben von Terminals konfiguriert, die den Multicast- oder Broadcast-Service empfangen, Bestimmen von Parametern an der Feedbacksteuereinheit, die es einem mobilen Terminal ermöglichen, zu entscheiden, ob der Feedbacksteuereinheit ein durch das Sitzungsprotokoll konfiguriertes Feedback zur Verfügung gestellt wird, Senden der Parameter von der Feedbacksteuereinheit an zumindest eine Untermenge der Mehrzahl von mobilen Terminals, die den Multicast- oder Broadcast-Service empfangen, und Empfangen an der Feedbacksteuereinheit von Feedback von einer Untermenge der Mehrzahl von mobilen Terminals, die die Parameter empfangen haben.
  • In einer weiteren Ausführungsform kann der computerlesbare Datenträger weiterhin Anweisungen speichern, die, wenn sie durch den Prozessor der Feedbacksteuereinheit ausgeführt werden, den Prozessor veranlassen, die Schritte auszuführen, die durch die Feedbacksteuereinheit in einer der verschiedenen Ausführungsformen des Feedbackteuerverfahrens durchgeführt werden, die oben umrissen wird.
  • KURZE BESCHREIBUNG DER FIGUREN
  • Im folgenden wird die vorliegende Erfindung ausführlicher mit Bezug auf die begleitenden Figuren und Zeichnungen beschrieben. Ähnliche oder entsprechende Details in den Abbildungen werden mit den gleichen Bezugszeichen bezeichnet.
  • 1 zeigt die Benachrichtigungsbandbreite pro Empfänger als Funktion der Zahl der Empfänger n, die empfangen, welche eine RTP-Sitzung subskribiert haben,
  • 2 zeigt das Empfängerbenachrichtigungs (RR)-Zeitintervall T als eine Funktion der Zahl der Empfänger n, die empfangen, welche eine RTP-Sitzung subskribiert haben,
  • 3 zeigt ein RTCP-anwendungsdefiniertes Paket,
  • 4 zeigt das Format der anwendungsdefinierten Parameter, die in einem RTCP-anwendungsdefinierten Paket entsprechend einer Ausführungsform der Erfindung transportiert werden,
  • 5 zeigt das Format eines erweiterten RTCP-Empfänger-Benachrichtigungsblockes entsprechend einer Ausführungsform der Erfindung,
  • 6 zeigt das Format für das Transportieren von Parametern in einem RTCP-anwendungsdefinierten Paket von 3 oder in einem erweiterten RTCP-Empfängerbenachrichtigungsblock, wie in 5 gezeigt, entsprechend einer Ausfüh rungsform der Erfindung,
  • 7, 8 & 9 zeigen unterschiedliche Szenarien für das Bereitstellen eines Multicast- und Broadcast-Service für Benutzer und für das Steuern des Feedbacks der empfangenden Terminals entsprechend unterschiedlichen Ausführungsformen der Erfindung und
  • 10 & 11 zeigen ein mobiles Terminal bzw. eine Feedbacksteuereinheit entsprechend unterschiedlichen Ausführungsformen der vorliegenden Erfindung.
  • AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
  • Die folgenden Abschnitte beschreiben verschiedene Ausführungsformen der Erfindung. Nur zu exemplarischen Zwecken werden die meisten Ausführungsformen in Beziehung zu einem UMTS-Kommunikationssystem umrissen, und die Terminologie, die in den folgenden Abschnitten verwendet wird, bezieht sich hauptsächlich auf die UMTS-Terminologie. Jedoch soll die verwendete Terminologie und die Beschreibung der Ausführungsformen in Bezug auf eine UMTS-Architektur nicht die Prinzipien und die Ideen der vorliegenden Erfindung auf solche Systeme begrenzen.
  • Auch die ausführlichen Erklärungen, die in dem Abschnitt des technischen Hintergrundes oben gegeben wurden, sollen lediglich die im wesentlichen UMTS-spezifischen exemplarischen Ausführungsformen besser verständlich machen, die im folgenden beschrieben werden, und sollten nicht als Einschränkungen der vorliegenden Erfindung auf die beschriebenen spezifischen Implementierungen von Prozessen und Funktionen in dem mobilen Kommunikationsnetz verstanden werden.
  • Die Ideen und die Prinzipien, die in den folgenden Abschnitten umrissen werden, können auf Multicast- oder Broadcast-Services anwendbar sein, die an den mobilen Terminals über eine Funkschnittstelle unter Verwendung einer unidirektionalen Abwärtsstrecke sowie eines unzuverlässigen Transportprotokolls für die Datenanlieferung empfangen werden. Weiterhin werden Protokolle verwendet, die das Bereitstellen von Feedback von den empfangenden Terminals zu der sendenden Quelle, z.B. einer Feedbacksteuereinheit, ermöglichen. Es wird bemerkt, dass in dem Szenario, das oben beschrieben wird, das Feedback möglicherweise nicht über den Kanal gegeben wird, über den die Servicedaten empfangen werden, da derselbe unidirektional ist.
  • Der Schlüsselaspekt von einer Ausführungsform der Erfindung ist es, nur einer Teilmenge von Terminals, die einen Multicast- oder Broadcast-Service von einer Feedbacksteuereinheit empfangen, zu erlauben, der Feedbacksteuereinheit in dem mobilen Kommunikationsnetz Feedback zu geben, die innerhalb des Kommunikationsnetzes den Service und das Feedbackgeben, wie zuvor umrissen wurde, steuern kann. In einer Ausführungsform der Erfindung kann dieses zum Beispiel erzielt werden, indem man die mobilen Terminals, die einen Multicast- oder Broadcast-Service empfangen, entscheiden lässt – z.B. auf der Grundlage von einem Wahrscheinlichkeitsexperiment – ob sie oder ob sie nicht Feedback gibt. Indem sie Parameter, z.B. einen Wahrscheinlichkeitswert, der in dem Experiment verwendet werden soll, signalisiert, kann die Feedbacksteuereinheit Feedback steuern, indem sie die signalisierten Parameter so verändert, dass – statistisch – die gewünschte Zahl von den mobilen Terminals, die einen Service empfängt, Feedback geben soll.
  • In dieser Hinsicht ist es wichtig, zu bemerken, dass die Grundlage für einen Multicast- oder Broadcast-Service ein Ende-zu-Ende-Konzept ist, was bedeutet, dass die ausgetauschten Informationen zwischen den Endpunkten für die optionalen Zwischenknoten transparent sind. Dieses wird auch durch die verwendeten Protokolle wiedergegeben, die einer geschichteten Architektur folgen, die die übermittelten Informationen innerhalb einer bestimmten Schicht verkapselt. Informationen an einer Schicht sind zunächst nicht für andere Schichten sichtbar. Nur angrenzende Schichten können Informationen über wohldefinierte Services und Servicezugriffspunkte austauschen. Da die übertragenen Informationen des Multicast- oder Broadcast-Services nur für die sendende Quelle, d.h. für die Feedbacksteuereinheit, und die Empfänger sichtbar sind, unterstützen die Zwischenknoten nur Protokolle niedrigerer Schichten als das verwendete Übertragungsprotokoll.
  • Die Idee des Auswählens einer Teilmenge von Terminals, die den Multicast- oder Broadcast-Service empfangen, um Feedback zu geben, behält dieses Ende-zu-Ende-Konzept bei und unterbricht die geschichtete Architektur der verwendeten Protokolle nicht.
  • Demgegenüber würde das Erzeugen von Feedback in einem Zwischenknoten des UTRAN oder CN diese Konzepte unterbrechen und würde das Ändern der Protokolle in einer inkompatiblen Weise und das Erweitern der Zwischenknoten erfordern, um eine unsachgemäße Funktionalität durchzuführen. Irgendeine dieser Annahmen ist nicht er füllbar, wenn die Architektur für das Bereitstellen eines Multicast- oder Broadcast-Services weit ausgedehnt ist.
  • Eine weitere Ausführungsform der vorliegenden Erfindung basiert auf der Idee, eine konfigurierbare und adaptive Feedbacklösung für MBMS-Services zur Verfügung zu stellen. Im folgenden wird die Ausführungsform in größerer Ausführlichkeit erläutert.
  • MBMS-Services verwenden typischer Weise ein RTP-Protokol für Streaming-Medien. Das RTCP-Begleitprotokol kann dazu verwendet werden, ein RTP-Sitzungs-Feedback zu sammeln und eine lockere Steuerung der Sitzung bereitzustellen. Ein RTCP-Feedback kann verwendet werden, um eine Statistik über eine fortwährende RTP-Multicast-Sitzung zu sammeln. Als zugrundeliegendes unzuverlässiges Transportprotokoll kann UDP angenommen werden.
  • Anstelle des RTP-Standardalgorithms, d.h. die Verwendung von RTCP-RR, um die Zahl der teilnehmenden mobilen Terminals (MT) zu schätzen, verwendet das Schema, das in dieser Ausführungsform der Erfindung vorgeschlagen wird, MBMS-Signalisieren und/oder MBMS-Status-Informationen, um die genaue Zahl an MT/UE in einer Sitzung zu bestimmen. Dieser Ansatz vermeidet die Notwendigkeit für einen Feedbackkanal für jeden Empfänger, die Tatsache, dass jeder Teilnehmer sämtliche Nachrichten von dem Rest der Teilnehmer empfängt, und eliminiert den Multicast-/Broadcast- sowie Rechenoverhead.
  • Im allgemeinen sollte bemerkt werden, dass es in den MBMS-Spezifikationen zwei Arten von Statusinformationen gibt: einen MBMS Bearer Context, der einen bestimmten MBMS Bearer Service beschreibt, und einen MBMS UE Context, der UE-spezifische Informationen umfasst, die sich auf einen speziellen MBMS Bearer Service beziehen. Beide Contexts können in dem RAN, SGSN, GGSN und BM-SC erzeugt werden. Ein UE Context kann für jedes UE, das den Service empfängt, erzeugt werden. Zur Zeit enthält der Bearer Context in dem GGSN die Zahl der UEs, die den Service empfangen.
  • Es kann jedoch möglich sein, dass andere RAN- oder CN-Knoten Statusinformationen des Services innerhalb eines Context speichern, die es ermöglichen, die Zahl der an dem Service teilnehmenden UEs entweder z.B. durch Zählen der Zahl der erzeugten Contexts (d.h. jedes UE hat seinen eigenen UE-Context in dem Netzknoten) oder durch ein Feld innerhalb eines Contexts, das die Gesamtzahl der Serviceteilnehmer anzeigt, zu bestimmen.
  • In dem Fall, in dem eine MBMS-Architektur für das Bereitstellen des Services verwendet wird, kann z.B. die Zahl der Teilnehmer der UE-Contexts des BM-SC gezählt werden, oder das GGSN kann die Gesamtzahl der Teilnehmer durch Signalisieren des jeweiligen Feldwerts des Bearer Contexts an das BM-SC zur Verfügung stellen.
  • Die Verwendung eines statistischen Benutzersamplings für das Sammeln von einer Sitzungsstatistik kann dazu verwendet werden, es nur einer Teilmenge von mobilen Terminals (MT) zu erlauben, Feedback zu geben. Das heißt, dass nur ein Satz von Empfängern konfiguriert ist, Benachrichtigungen an die Feedbacksteuereinheit zu senden. Dieses steht im Gegensatz zu dem Standard-RTP-Multicast, in dem jeder Teilnehmer ein RTCP-Feedback sendet, und in dem diese typischer Weise zu allen anderen weitergeleitet wird.
  • Entsprechend dieser Ausführungsform der vorliegenden Erfindung wird der Satz der Benachrichtigungsempfänger auf eine probabilistische Weise ausgewählt. Ein Parameter, der für das Ausführen des statistischen Benutzersamplings notwendig ist, kann die Benachrichtigungswahrscheinlichkeit sein. Weitere Parameter, die verwendet/signalisiert werden können, sind das Benachrichtigungszeitintervall und die zu reservierende Feedbackbandbreite. Die eine Feedbacksteuerung sendende Einheit, z.B. das BM-SC, kann diese Parameter gemäß der Gesamtmenge an erlaubten Feedbacks setzen, da verschiedene Services unterschiedliche Benachrichtigungserfordernisse haben können.
  • Indem dieses Schema verwendet wird, kann die Zahl der Feedbackkanäle gesteuert werden und wird jeder Feedbackkanal effizienter verwendet.
  • Die Parameter für die Konfiguration des oben erwähnten Schemas können zu den Multicast-/Broadcast-Gruppenteilnehmern transportiert werden. Dieses kann erreicht werden, indem z.B. der Multicast-/Broadcast-Datenkanal oder ein Nachrichtenkanal verwendet wird.
  • Eine Variante dieser Ausführungsform stellt eine Feedbacksteuereinheit (z.B. BM-SC) mit der Möglichkeit zur Verfügung, den Benachrichtigungsempfängersatz neu zu konfigurieren und das Benachrichtigungszeitintervall während einer andauernden Sitzung unabhängig von der Gruppengröße auf einen konstanten Wert zu setzen (zurückzusetzen).
  • Hierdurch kann das Problem angegangen werden, das Benachrichtigungszeitintervall für die RR auf vernünftige Werte zu setzen.
  • Um zu verhindern, dass Terminals nach der Rekonfiguration mit unterschiedlichen Benachrichtigungsintervallen und -wahrscheinlichkeiten arbeiten, kann ein Timerwert in diesen Nachrichten enthalten sein. Dadurch kann das Signalisieren und der Overhead auf dem Multicast-Kanal auf ein Minimum gehalten werden, wie auch der Rechenoverhead, der durch die Berechnung der Parameter an jedem Endgerät entsteht.
  • Die Standard-RTP/RTCP-Algoithmen und -Mechanisms folgen einer generischen Konstruktion, um eine große Klasse an Anwendungen mit einzelnen oder mehrfachen Datenquellen und Empfängern zu unterstützen.
  • Das Ziel der Aktivitäten in dem Zusammenhang mit 3GPP MBMS ist spezieller als das Bereitstellen von RTP/RTCP und ist auf das Bereistellen unidirektionaler Datenauslieferungsservices von einem einzelnen Server an einen Satz von mobilen Terminals, d.h. Streaming- oder Downloadservices, fokussiert.
  • Somit betrifft, wie oben angegeben, eine Ausführungsform der Erfindung eine Optimierung für die letztere Umgebung, wobei RTP und RTCP Verwendung finden. Insbesondere kann es das Ziel dieser Ausführungsform sein, Feedback von einer Statistik bezüglich einer RTP-Datenzulieferungssitzung zu unterstützen, wobei einige der Probleme, die oben in dem Einleitungsabschnitt beschrieben wurden, gelöst werden.
  • Ein Teil der 3GPP-MBMS-Architektur ist der MBMS Bearer Context. In diesem Bearer Context wird die Information gesammelt, die für das Einrichten der Verbindung über das 3G-Netz notwendig ist. Der MBMS Bearer Context wird typischer Weise an jedem Knoten in dem Pfad gespeichert, über den die MBMS-Servicedaten an das Terminal geliefert werden, d.h. in BM-SC, RAN, GGSN und SGSN.
  • Die Zahl der bedienten UEs wird ebenso in dem MBMS Bearer Context in dem GGSN gespeichert. Somit kann das GGSN die Zahl der bedienten UEs an den BM-SC liefern, so dass das BM-SC eine Kenntnis über die genaue Anzahl der teilnehmenden UEs in einer MBMS-Sitzung unter Vermeiden der Verzögerung und des Overheads, der der Verwendung eines RTCP-Feedbacks, um die Zahl der Benutzer zu bestimmen, die an einer RTP-Sitzung teilnehmen, eigen ist, haben kann. Somit können Statusinformationen verwendet werden, die in dem Bearer Context gespeichert sind, anstatt die Zahl der UEs durch Sammeln von Feedbackbenachrichtigungen von jedem Teilnehmer zu bestimmen.
  • Da die Anzahl der Sitzungsteilnehmer auf der Grundlage der MBMS-Statusinformationen und ohne Verwendung von Feedback von den teilnehmenden Benutzern bestimmt werden kann, ist es nicht notwendig einen Feedbackkanal für jeden Teilnehmer beizubehalten. Somit können signifikante Einsparungen in den verfügbaren Ressourcen in dem RAN- und Core-Netz des mobilen Kommunikationssystems erreicht werden. Wie oben umrissen, sieht eine Ausführungsform der Erfindung vor, das Statusinformationen, die sich auf den Service beziehen und die in einem oder mehreren der Netzknoten in dem RAN und/oder dem CN gespeichert sein können, verwendet werden können, um die Zahl der Terminals zu bestimmen, die einen bestimmten Service empfangen. Wenn es notwendig ist, können Informationen zwischen Netzknoten ausgetauscht werden.
  • Wie zuvor angegeben, können, um die notwendigen Ressourcen, die für Feedbackzwecke zugewiesen werden, lediglich M Empfänger, die eine Untermenge der Empfänger bilden, ausgewählt werden, um M Aufwärtsstreckenkanäle für Feedback an den Server einzurichten. Der MBMS-Server kann den Wert der gesamten Feedbackbandbreite BRR sowie die Zahl der verfügbaren Feedbackkanäle M bestimmen.
  • Da die Feedbacksteuereinheit die Struktur und die mittlere Größe der Benachrichtigungspakete PRTCP kennen kann, kann sie das Benachrichtigungsintervall für jede Feedbacknachricht T gemäß der folgenden Gleichung berechnen:
    Figure 00240001
  • Entsprechend einer Ausführungsform der Erfindung kann ein probabilistischer Ansatz für das Auswählen des Satzes von Benachrichtigungsempfängern M gewählt werden. Jeder Empfänger kann ein probabilistisches Experiment, z.B. ein Bemoulli-Experiment, mit einer Erfolgswahrscheinlichkeit p ausführen. Für die Berechnung dieses Wertes kann die Wahrscheinlichkeitsdichtefunktion wie folgt gekennzeichnet werden.
  • Unter der Annahme, dass n Nutzer das Bemoulli-Experiment mit einer Wahrscheinlichkeit p ausführen, und unter der Annahme, dass jedes Experiment von den anderen unabhängig ist, kann eine Binomialverteilung erhalten werden, und die Wahrscheinlich keitsdichtefunktion kann ausgedrückt werden durch:
    Figure 00250001
  • Weiterhin ist die Wahrscheinlichkeitsdichtefunktion gegeben durch:
    Figure 00250002
  • Die Binomialverteilung kann unter bestimmten Bedingungen durch eine Gauss-Verteilung approximiert werden. Die Anforderungen sind die: np > 4 n(1 – p) = nq > 4
  • Diese Näherung kann ebenso zur Vereinfachung verwendet werden, wenn man MBMS-Services betrachtet, da es im allgemeinen angenommen werden kann, dass Multicast-Services zu einer großen Anzahl an Benutzern gesendet werden.
  • Unter dieser Vereinfachung wird die Gleichung besser handhabbar. Die Wahrscheinlichkeitsdichtefunktion der vereinfachten Binomialverteilung würde eine Gauss – Verteilung mit dem folgenden Mittelwert und der folgenden Varianz sein:
    Figure 00250003
  • Die Gesamtzahl der z.Z. teilnehmenden Empfänger in der Multicast-Sitzung n kann entsprechend dem MBMS Bearer Context, wie oben erwähnt worden ist, festgestellt werden. Auf diese Weise kann der Server sämtliche Informationen besitzen, die für die Berechnung der Erfolgwahrscheinlichkeit p gespeichert sind.
  • Somit ist es vernünftig, die Feedbacksteuereinheit die oben genannte Berechnung durchführen zu lassen und danach alle notwendigen Parameter (Zeitintervall T, Wahrscheinlichkeit p, Benachrichtigungsbandbreite pro Empfänger BRR/M = bRR) der Gruppe über den Multicast-/Broadcastkanal kundzugeben.
  • Von den oben genannten Wahrscheinlichkeitsverteilungsfunktionen können wir einen Wert für p erhalten, der eine Gesamtzahl an Benachrichtigungsempfängern M ergibt, die in dem Intervall (MMin, MMax) als der Wert von p liegen sollten, der erfüllt: p(MMIN ≤ x ≤ MMAX) = FX(MMin) – FX(MMin)
  • Diese Gleichung kann unter Verwendung der oben umrissenen Näherung oder mit anderen Verfahren gelöst werden, die in diesem Dokument nicht genauer spezifiziert werden (siehe zum Beispiel Bronstein et al., „Taschenbuch der Mathematik", 1999, Kapitel 16.2.3.1: „Binomialverteilung").
  • Sobald der Wert von p wie oben durch ein UE empfangen wird, kann es ein Bemoulli-Experiment durchführen. Nur wenn das Resultat des Experimentes positiv ist, kann der Empfänger einen Feedbackkanal mit der zur Verfügung gestellten Empfängerbenachrichtigungs-Bandbreite pro Teilnehmer bRR einrichten. Es wird bemerkt, dass ein UE die Möglichkeit haben kann, die erforderliche Bandbreite für den Bearer abhängig von dem System zu spezifizieren, in dem die Prinzipien, die in diesem Dokument umrissen werden, verwendet werden. Das UE kann sodann nach dem spezifizierten Zeitintervall T eine RTCP RR senden.
  • Entsprechend einer Ausführungsform der Erfindung können die Parameter, die für eine Empfängerkonfiguration verwendet werden, d.h. dafür, es einem UE zu ermöglichen, festzustellen, ob oder ob nicht Feedback gegeben werden soll, zu den Empfängern transportiert werden, die RTCP-Sender-Benachrichtigungsblöcke verwenden. Zu diesem Zweck können einige Optionen verfügbar sein.
  • Eine erste Möglichkeit kann es sein, anwendungsdefinierte Pakete (APP-Pakete), wie in 3 gezeigt, zu benutzen, die der RTCP-Spezifikation entsprechen. Im Allgemeinen ist das APP-Paket für den experimentellen Gebrauch, wenn neue Anwendungen und neue Eigenschaften entwickelt werden, ohne dass eine Pakettypwertregistrierung erforderlich ist, gedacht.
  • In 3 sind die Felder V, P, Subtyp, PT, Länge und SSRC in RFC 3500 definiert, Abschnitt 6.7. Das Namensfeld kann z.B. auf „MBMS" gesetzt werden, aber irgendein anderer Name, welche aus bis zu 4 Oktetten besteht, kann stattdessen verwendet werden. Weiterhin können die anwendungsabhängigen Daten an den vorher erwähnten Feldern angefügt werden.
  • In der exemplarischen Ausführungsform der Erfindung, die in 4 gezeigt wird, kann der anwendungsspezifische Teil des APP-Pakets umfassen bestehen aus mindestens den folgenden Feldern: ein Zeitintervall, das das (RTCP-) Benachrichtigungszeitintervall in Millisekunden anzeigt, ein Wahrscheinlichkeitswert der Erfolgswahrscheinlichkeit für das Wahrscheinlichkeitsexperiment in einer Festpunktdarstellung und die Benachrichtigungsbandbreite, welche die Bandbreite spezifiziert (z.B. in Bits pro Sekunde), die ein Empfänger für den Benachrichtigungskanal zuteilen muss, wenn das Wahrscheinlichkeitsexperiment erfolgreich ist.
  • Mit der Festpunktdarstellung des Wahrscheinlichkeitswertes kann die maximale Wahrscheinlichkeit p = 1 z.B. als eine Reihenfolge von 16 Bits („11111111111111111") kodiert werden. Folglich entspricht die Auflösung für p gleich 1/(216 – 1).
  • Eine weitere Ausführungsform der Erfindung sieht vor, die notwendigen Parameter mittels eines neu definierten erweiterten Empfängerbenachrichtigungsblockes (XR-Benachrichtigungsblock), wie in 5 gezeigt, zu übertragen. In „RTP Protocol Extended Reports (RTCP XR)" spezifizieren Friedman et al. (siehe RFC 3611, verfügbar über http://www.ietf.org) einen Rahmen für das Definieren von ad hoc RTCP-Benachrichtigungsblöcken mit erweiterten Fähigkeiten. Entsprechend dieser Ausführungsform kann ein solcher Block definiert werden, um die Benachrichtigungsinformationen zu übermitteln, wie oben spezifiziert (z.B. das Benachrichtigungsintervall, die Benachrichtigungswahrscheinlichkeit, etc.).
  • In dem XR-Benachrichtigungsblock, der in der 5 gezeigt wird, sind die Felder V, P, reserviert, PT, Länge, SSRC wie in RFC 3611, Abschnitt 2, definiert. Ähnlich sind die Felder BT, rsvd (für typenspezifische Informationen) und Blocklänge in Abschnitt 3 von RFC 3611 definiert. Das Feld BT (Blocktyp) nimmt einen unbenutzten Wert in dem Bereich (8, 255) an. Die Werte 0-7 werden bereits verwendet.
  • Diese Wahl hat den Vorteil, dass sie die Möglichkeit einschließt, die Logik direkt in dem RTP-Protokoll anstatt an der Anwendungsschicht zu implementieren, wenn ein APP-Benachrichtigungsblock, wie oben umrissen, verwendet wird. Die Lösung, die durch diese Ausführungsform der Erfindung vorgeschlagen wird, hat den weiteren Vorteil, dass Empfänger die erweiterten Benachrichtigungsmöglichkeiten verwenden oder zur Verfügung stellen können, die wie durch RFC 3611 vorhanden sind oder wie in diesem Dokument definiert sind.
  • In einer weiteren Ausführungsform der Erfindung wird vorgeschlagen, Verfahren wie profilspezifische Erweiterungen in dem RTP-Header, in einem ad hoc Benachrichtigungsblock oder in einer profilspezifischen Erweiterung für RTCP für das Übermitteln der Parameter zu verwenden, um den mobilen Terminals zu ermöglichen, zu bestimmen, ob Feedback zu derselben gegeben werden soll.
  • Im folgenden werden einige Varianten dafür, wie man die Benachrichtigungsinformationen (unter Verwendung teilweise unterschiedlicher Transportprotokolle) entsprechend einigen Ausführungsform der Erfindung transportiert, in den folgenden Abschnitten umrissen.
  • Wegen ihrer Wahrscheinlichkeitsnatur und in dem Fall, dass RTP über das unzuverlässige Transportprotokoll wie UDP läuft, können die oben umrissenen Ausführungsformen die Einrichtung der bevorzugten Zahl an Feedbackkanälen nicht genau garantieren.
  • Ein Grund dafür kann sein, dass keine hinreichende Anzahl an Teilnehmern die Parameter von der Feedbacksteuereinheit empfängt, so dass das angestrebte Minimum von Benachrichtigungen nicht erreicht werden kann. Wie oben erwähnt, können abwärts gerichtete Pakete wegen des Gebrauches von einem unzuverlässigen Transportmechanismus verloren gehen.
  • Ein anderer Grund kann sein, dass das Experiment darin resultiert, dass wegen der Wahrscheinlichkeitsnatur des Experimentes zu wenige Benutzer in der Tat Feedbacknachrichten senden. Dieses sollte ein seltener Fall sein, da die Gleichung p(MMIN ≤ x ≤ MMAX) = FX(MMin) – FX(MMin) (siehe auch oben)gelöst werden kann, so dass die Wahrscheinlichkeit dafür, dass zu wenige Benutzer Feedback senden, minimal ist.
  • Auch verschiedene andere Gründe, wie eine Zunahme der Benachrichtigungsbandbreite, lassen es angemessen erscheinen, eine Empfängerneukonfiguration zu erlauben.
  • Im folgenden umreißt eine Ausführungsform der Erfindung, wie die Neukonfiguration der Parameter für das Entscheiden, ob oder ob nicht Feedback an einem mobilen Terminal gegeben wird, rekonfiguriert werden kann. Zusätzlich zu den Informationen, die entsprechend der obigen Ausführungsformen (siehe 4 und 5), signalisiert werden, können zwei Flags, die eine Neukonfiguration und einige Timer-Informationen anzeigen, in den Paketen enthalten sein, welche die Parameter zu den mobilen Terminals übermitteln. Der Timer kann zum Beispiel vermeiden, dass unterschiedliche Teilnehmer unterschiedliche Einstellungen benutzen und dadurch die Aufwärtsstreckenbandbreite erschöpfen.
  • Eine Paketstruktur entsprechend dieser Ausführungsform wird in 6 gezeigt. Wie in den Ausführungsformen, die oben mit Bezug auf 4 und 5 umrissen wurden, umfasst das Paket ein Wahrscheinlichkeitsfeld. Unter der Annahme, dass das Feld 14 Bits lang ist und unter Verwendung einer Festpunktdarstellung der Erfolgwahrscheinlichkeit für das Bemoulli – Experiment ergibt sich die Auflösung für p zu 1/(214 – 1). Eine Wahrscheinlichkeit von p = 1 kann durch eine Reihenfolge von 14 vorbestimmten Bits (z.B. "11111111111111") angezeigt werden.
  • Außer dem Wahrscheinlichkeitsfeld, dem Benachrichtigungsbandbreiten- und dem Zeitintervallfeld kann die Paketstruktur eine Rekonfigurations-Flag (R), eine Delta-Flag (D) und ein Timerwertfeld (z.B. 32 Bits) umfassen, das das Zeitintervall (z.B. in Millisekunden), für das diese Parameter gültig sind, anzeigt.
  • Wenn der Timer abläuft und dieser Empfänger keinen neuen Wert empfangen hat, kann der Empfänger (mobiles Terminal) die Verwendung dieser Werte stoppen und einen aufgebauten Feedbackkanal abbauen. Dieses kann geeignet sein, um zu vermeiden, dass Terminals mit unterschiedlichen Einstellungen arbeiten, weil aufeinanderfolgende Benachrichtigungseinstellungen (Parameter) nicht von dem gleichen Satz von Teilnehmern empfangen wurden. Empfänger mit eingerichteten Feedbackkanälen können auf Benachrichtigungseinstellungen hören und können ihre Timerwerte dementsprechend aktualisieren.
  • Die Rekonfigurations-Flag (R) kann den Empfängern anzeigen, ob eine Neukonfiguration durchgeführt werden soll. Wenn die Rekonfigurations-Flag nicht gesetzt wird (z.B. R = 0), wird die Nachricht benutzt, um die Timer-Werte der Empfänger mithilfe eines bereits eingerichteten Feedbackkanals zu erneuern. Dieses dient dazu, die bestehenden Benachrichtigungsempfänger beizuhalten, und es wird keine Neukonfiguration durchgeführt. Wenn die Rekonfigurations-Flag gesetzt ist (z.B. R = 1), müssen die Empfänger das Wahrscheinlichkeitsexperiment entsprechend dem Status der Delta-Flag (D) durchführen.
  • Die Delta-Flag (D) kann den Bereich der Neukonfiguration definieren, wenn die Rekonfigurations-Flag gesetzt ist (z.B. R = 1). Wenn die Delta-Flag nicht gesetzt ist (z.B. D = 0), betrifft die Neukonfiguration alle Empfänger. In diesem Fall können alle Empfänger das Wahrscheinlichkeitsexperment entsprechend dem spezifizierten Wahrscheinlichkeitswert durchführen. Dieses kann dazu dienen, Benachrichtigungsempfänger anfänglich auszuwählen oder ein hergestelltes Benachrichtigungsszenario vollständig neu zu konfigurieren, z.B. um alle Benachrichtigungsempfänger zu stoppen.
  • In dem Fall, dass die Delta-Flag nicht gesetzt ist (z.B. D = 0), kann ein mobiles Terminal, das bereits entschieden hat, Feedback durchzuführen und folglich bereits einen Feedbackkanal zuvor aufgebaut hat, diesen Kanal beibehalten anstatt in abzubauen und eine Wiederherstellung durchzuführen. Das letztere gilt nur unter der Annahme, dass die aufgebaute Aufwärtsstrecke die selbe Bandbreite wie in der neuen Nachricht kundgegeben zur Verfügung stellt. Wenn die Bandbreite sich geändert hat, kann es sein, dass der Empfänger den alten Kanal abbauen und einen neuen Feedbackkanal (Bearer) wieder aufbauen muss.
  • Wenn die Delta-Flag gesetzt ist (z.B. D = 1) kann die Neukonfiguration nur für jene Empfänger zutreffen, die nicht bereits einen Feedbackkanal beibehalten. Nur jene Empfänger können das Wahrscheinlichkeitsexperiment entsprechend dem spezifizierten Wahrscheinlichkeitswert durchführen. Dieses kann in dem Fall nützlich sein, dass ein bestimmter bevorzugter Schwellenwert Mmin von Benachrichtigungsempfängern nicht getroffen wird und zusätzliche Empfänger Feedbackkanäle aufbauen sollten.
  • Die folgende Tabelle fasst die unterschiedlichen Neukonfigurationsoptionen zusammen:
    Figure 00310001
  • Wie aus den obigen Abschnitten ersichtlich ist, können in dem Fall, in dem ein unzuverlässiger Transportmechanismus benutzt wird, um die Benachrichtigungsparameter zu übermitteln, diese während des Transportes verloren gehen. Dieses kann insbesondere in dem Fall zutreffen, dass RTP-Pakete über das unzuverlässige UDP-Protokoll übertragen werden. UDP ist ein Transportprotokoll, das einen unzuverlässigen Datagrammservice zur Verfügung gestellt. Es wird gewöhnlich für Unicast-/Multicast-Medien (wie MPEG4) in RTP-Paketen verwendet. Die entsprechenden RTCP-Pakete werden ebenso über UDP transportiert.
  • Das BM-SC (als eine Feedbacksteuereinheit in dieser Ausführungsform dienend) kann auch entscheiden, diese Informationen in einer zuverlässigeren Weise zu senden. Es wird bemerkt, dass in den obigen Ausführungsformen das BM-SC als die Quelle der Parameter betrachtet worden ist, die den mobilen Terminals übermittelt werden. Jedoch ist es auch möglich, dass die Feedbacksteuereinheit, die den Inhalt eines Multicast- oder Broadcast-Services (Sitzung) bereitstellt, diese Parameter bestimmen und an die mobilen Terminals übertragen kann, die den Service empfangen.
  • Im Rahmen des MBMS gibt es Verfahren, die Informationen in einer zuverlässigeren Weise zu übertragen. Terminals können die Sitzungsbeschreibungsinformationen (z.B. als SDP-Beschreibung) eines MBMS-Services unter Verwendung einer Punkt-zu-Punkt-Verbindung, z.B. zu einem HTTP-Server, abfragen, oder sie können eine SMS empfangen, die diese Informationen enthält, bevor sie einer MBMS-Sitzung beitreten.
  • Eine andere Möglichkeit kann in dem Gebrauch von dem FLUTE-Protokoll bestehen (siehe Paila et al. „FLUTE – File Delivery over Unidirectional Transport", draft-ietf-rmt- flute-07.txt, Juni 2004, verfügbar über httpa/www.ietf.org). Das FLUTE-Protokoll kann für eine verlässliche Datenübertragung in der MBMS-Architektur verwendet werden. Servicenachrichteninformationen, die unter anderem die Parameter umfassen, die es den mobilen Terminals ermöglichen zu entscheiden, ob sie Feedback geben, können mit FLUTE und einem Sitzungsbeschreibungsprotokoll für das Beschreiben der angebotenen Services, z.B. SDP (Session Description Protocol), übertragen werden.
  • Folglich können, wenn eine zuverlässige Übertragung einer Sitzungsbeschreibung wie oben vorhanden ist, die Benachrichtigungsinformationen (zumindest die Benachrichtigungswahrscheinlichkeit und vielleicht zusätzlich das Benachrichtigungsintervall und wenn erforderlich die Benachrichtigungsbandbreite) in dieser Beschreibung entsprechend einer anderen Ausführungsform der Erfindung eingeschlossen sein.
  • Als nächstes werden einige mögliche Szenarien für das Bereitstellen eines Multicast- oder Broadcast-Services für Benutzer, und die in der Lage sind, die Erfindung, die in den verschiedenen Ausführungsformen oben umrissen wird, einzusetzen, zu beispielhaften Zwecken mit Bezug auf die 7, 8 und 9 umrissen.
  • In 7 stellt ein Server 701 eine Multicast- oder Broadcast-Sitzung über eine Feedbacksteuereinheit, z.B. das BM-SC 704, Benutzern zum Beispiel über ein auf IP gegründetes Netz zur Verfügung. Einige der Benutzer, welche die Servicedaten empfangen, können sich in einem mobilen Kommunikationsnetz, wie einem UMTS Netz 702, befinden, das im folgenden zu beispielhaften Zwecken betrachtet wird.
  • Entsprechend einer Ausführungsform der Erfindung kann das BM-SC 704, das sich innerhalb des UMTS-Netzes 702 befindet, das Bereitstellen von Feedback der serviceempfangenden Terminals 712, 713, wie oben umrissen, steuern. Das BM-SC 704 empfängt die Servicedaten von dem Server 701 und kann dieselben innerhalb einer MBMS-Sitzung an die Terminals 712, 713 zum Beispiel über ein GGSN (GPRS Gateway Support Node) 705 und ein SGSN (Serving GPRS Support Node) 706 des CN (CoreNetz) 703, mindestens ein RNC 709 und mindestens ein Knoten B 710, 711, übermitteln. Man beachte, dass das BM-SC 704 ebenso für das Verkünden der Service-Verfügbarkeit über einen Nachrichtenkanal in dem UMTS Netz 702 verantwortlich sein kann und in der Service-Aufnahme, d.h. UEs, die hinzukommen und den Service verfassen, mit einbezogen werden kann. Wie zuvor mit Bezug auf eine Ausführungsform der Erfindung umrissen, können die Servicenachrichten die Parameter zur Feedbackteuerung enthalten.
  • Mit Bezug nun auf 8 wird eine exemplarische Ausführungsform der Erfindung veranschaulicht, in der sich der Server 801 in dem mobilen Kommunikationssystem befindet. Im Wesentlichen treffen die gleichen Betrachtungen, die für die Ausführungsformen der Erfindung mit Bezug auf 7 oben umrissen wurden, auch hier zu, außer dass die Verwendung eines auf IP gegründeten Netzes, wie es in 7 gezeigt ist, für die Datenbereitstellung nicht notwendig zu sein braucht.
  • In 9 wird eine beispielhafte Ausführungsform der Erfindung veranschaulicht, worin der Server 901 die Quelle der Daten des Multicast- oder Broadcast-Services ist. In dieser Ausführungsform der Erfindung stellt der Server 901 die auf den Service bezogenen Datenströme direkt dem GGSN 705 zur Verfügung. Entsprechend dieser Ausführungsform kann das GGSN 705 folglich die Netzeinheit sein, die das Feedbackgeben der abwärts gerichteten Terminals steuert, die den Service empfangen. In diesem Fall kann das GGSN 705 die Zahl der Service-Teilnehmer auf der Grundlage der jeweiligen Informationen, die in den auf den Service bezogenen Kontextinformationen gespeichert werden, wie in dem MBMS Bearer Context, direkt feststellen.
  • In einer weiteren Ausführungsform der Erfindung kann die Feedbacksteuereinheit, z.B. das BM-SC, die Daten des Multicast- oder Broadrast-Services von einem Multicast- oder Broadcast-Serviceanbieter (Server 701, 801), wie in 7 und 8 gezeigt, empfangen.
  • Die Feedbacksteuereinheit kann in einem nicht-transparenten Modus für einen Multicast- oder Broadcast-Serviceanbieter betrieben werden. Dieser Modus wird im folgenden mit Bezug auf 7 erläutert.
  • In diesem Fall fungiert das BM-SC 704 (d.h. die Feedbacksteuereinheit in der exemplarischen Ausführungsform, die in 7 gezeigt ist) als ein Client, der den Multicast- oder Broadcast-Service von dem Standpunkt des Servers 701 aus (d.h. des Multicast- oder Broadcast-Serviceanbieters in der exemplarischen Ausführungsform, die in 7 gezeigt ist) empfängt. Von dem Standpunkt der Terminals 712, 713, dem Multicast- oder Broadcast-Service, aus fungiert das BM-SC 704 als ein Multicast- oder Broadcast-Server, der den Service bereitstellt.
  • Folglich kann es möglicherweise keine Ende-zu-Ende-Service-Sitzung von dem Server 701 zu den mobilen Terminals 712, 713 geben, sondern die Service-Bereitstellung wird in zwei aufeinanderfolgende Sitzungen aufgespaltet: eine zwischen den Terminals 712, 713 und dem BM-SC 704 und eine zwischen dem BM-SC 704 und dem Provider 701.
  • Für die beiden Sitzungen können unterschiedliche Protokolle, z.B. auf der Transport- und der Sitzungsschicht, verwendet werden. Z.B. kann die Sitzung zwischen BM-SC 704 und den Terminals 712, 713 ein RTP/UDP/IP (und ein RTCP-Feedback) verwenden, während die Sitzung zwischen dem Server 701 und BM-SC 704 die selben Protokolle oder unterschiedliche verwenden kann. Folglich kann das BM-SC 704 in Art eines Gateways arbeiten, der die Protokollübersetzungsmechanismen zur Verfügung stellt.
  • Wenn man nun die Sitzung zwischen dem Server 701 und BM-SC 704 betrachtet, kann das letztere folglich dem Provider 701 Feedback geben. Um die Aufnahmestatistiken, z.B. den QoS, der für die unterschiedlichen serviceempfangenden Terminal 712, 713 erhalten wird, die Paketverlustrate an die einzelnen Terminals 712, 713 oder dergleichen, die durch das Feedback wiedergegeben werden, die von dem Terminal 712, 713 empfangen wird, wiederzugeben, kann das BM-SC 704 das Feedback analysieren, die empfangen worden ist, und kann Gesamtwerte oder kumulative Werte daraus bilden, welche Empfangsstatistiken des Services innerhalb des mobilen Kommunikationssystems wiedergeben. Diese Gesamtwerte oder die kumulativen Werte können in jeder möglichen Form als Feedback dem Server 701 zur Verfügung gestellt werden. Z.B. kann das BM-SC 704 "Standard" RTCP Receiver Reports erzeugen, die die Gesamtwerte oder kumulativen Werte wiedergeben, oder es kann eine spezielle Form des Feedbackgebens zwischen dem Provider 701 und BM-SC 704 definiert werden.
  • Eine zweite Möglichkeit kann es sein, dass das BM-SC 704 das empfangene Feedback der einzelnen UEs 712, 713 an den Provider 701 weiterleitet. Auch in diesem Fall kann das BM-SC 704 irgendeine Umwandlung der Feedbackdaten durchführen, weil es eine unterschiedliche Verbindung/Sitzung zwischen dem BM-SC 704 und dem Provider 701 gibt, in der sogar ein anderes Protokoll verwendet werden kann.
  • Auf jeden Fall kann das Feedbackgeben von dem BM-SC 704 zu dem Provider 701 z.B. in dem Fall besonders geeignet sein, in dem den Benutzern ein empfangener Service, der auf dem QoS basierend erhalten worden ist, berechnet wird.
  • Eine andere Ausführungsform der vorliegenden Erfindung betrifft die Implementierung der oben beschriebenen verschiedenen Ausführungsformen unter Verwendung von Hardware und Software. Es wird erkannt, dass die verschiedenen obenerwähnten Verfahren sowie die verschiedenen logischen Blöcke, Module, die Schaltungen, die oben beschrieben werden, mit Rechenvorrichtungen (Prozessoren), wie zum Beispiel universellen Prozessoren, digitalen Signalprozessoren (DSP), anwendungsspezifischen integrierten Schaltungen (ASIC), feldprogrammierbaren Gatteranordnungen (FPGA) oder anderen programmierbaren logischen Bauteilen, etc. implementiert oder durchgeführt werden. Die verschiedenen Ausführungsformen der vorliegenden Erfindung können ebenso durch eine Kombination dieser Vorrichtungen durchgeführt oder verkörpert werden.
  • Weiterhin können die verschiedenen Ausführungsformen der vorliegenden Erfindung auch mithilfe von Software-Modulen implementiert werden, die von einem Prozessor oder direkt in Hardware ausgeführt werden. Auch eine Kombination der Software-Module und einer Hardware-Implementation kann möglich sein. Die Software-Module können auf irgendeiner Art maschinell lesbarer Speichermedien, z.B. RAM, EPROM, EEPROM, Flash-Speicher, Register, Festplatten, CD-ROM, DVD, etc. gespeichert werden.
  • In dieser Hinsicht zeigen die 10 und 11 ein mobiles Terminal bzw. eine Feedbacksteuereinheit entsprechend beispielhafter Ausführungsformen der Erfindung.
  • Das mobile Terminal kann u.a. eine Anzeige 1001 für das Anzeigen der Daten, die von der Feedbacksteuereinheit geliefert werden, sowie mindestens eine Kommunikationsschnittstelle 1004, welche den Empfang der Multicast- oder Broadcast-Sitzung und die Übertragung des Feedbacks ermöglicht, umfassen. Weiterhin kann das mobile Terminal einen Prozessor 1002 (eine Rechenvorrichtung) umfassen, der unter anderem benutzt werden kann, um Anweisungen auszuführen, die auf dem maschinell lesbaren Speichermedium 1003 gespeichert sind. Weiterhin kann der Prozessor 1002 die Kommunikationen über die Kommunikationsschnittstelle(n) 1004 steuern und kann das Wahrscheinlichkeitsexperiment durchführen, um an dem Terminal festzustellen, ob oder ob nicht Feedback gegeben werden soll, etc.
  • Die Feedbacksteuereinheit, die in 11 gezeigt wird, kann einen Prozessor 1101, ein computerlesbares Speichermedium 1102 und mindestens eine Kommunikationsschnittstelle 1104 umfassen.
  • Die Feedbacksteuereinheit kann das BM-SC des UMTS-Netzes sein, das einen Multicast- oder Broadcast-Service bereitstellt oder weiterleitet. Die Feedbacksteuereinheit kann weiterhin eine Service-Datenbank 1103 umfassen, welche die Servicedaten (z.B. Ströme), die von dem Multicast- oder Broadcast-Service den Benutzern zur Verfügung gestellt werden, speichert oder zwischenspeichert. Weiterhin kann das maschinell lesbare Medium 1102 Anweisungen, die von dem Prozessor 1101 ausführbar sind, und weitere Daten speichern.
  • Die Daten, die in dem maschinell lesbaren Medium 1102 gespeichert sind, können z.B. die Kontextinformationen des jeweiligen Services umfassen, auf Grundlage derer die Feedbacksteuereinheit die Zahl der Service-Teilnehmer feststellt. Die Anweisungen, die auf dem maschinell lesbaren Medium 1102 gespeichert sind, können der Feedbacksteuereinheit weiterhin ermöglichen, ein Feedbackgeben von den Service-Teilnehmern, wie in den verschiedenen Ausführungsformen oben skizziert, zu steuern.

Claims (37)

  1. Ein Verfahren zum Steuern des Sendens von Feedback durch mobile Terminals (712, 713), die über eine Funkschnittstelle eines mobilen Kommunikationssystems (702) einen Multicast- oder Broadcast-Service empfangen, der durch eine Feedbacksteuereinheit (704) des mobilen Kommunikationssystems gesendet oder weitergeleitet wird, wobei das Verfahren die folgenden Schritte umfasst, die von einem mobilen Terminal ausgeführt werden: Empfangen des Multicast- oder Broadcast-Services über einen unidirektionalen Downlink-Kanal und Verwenden eines unzuverlässigen Transportprotokolls und eines Sitzungsprotokolls, worin das Sitzungsprotokoll das Bereitstellen von Feedback durch Terminals konfiguriert, die den Multicast- oder Broadcast-Service empfangen, Empfangen von Parametern von der Feedbacksteuereinheit auf Grundlage derer das mobile Terminal entscheidet, ob der Feedbacksteuereinheit durch das Sitzungsprotokoll konfiguriertes Feedback gegeben werden soll, Entscheiden darüber, ob die Feedbacksteuereinheit auf der Grundlage der empfangenen Parameter durch das Sitzungsprotokoll konfiguriertes Feedback für den Multicast- oder Broadcast-Service gegeben werden soll, Einrichten eines Bearers zum Übermitteln von Feedback an die Feedbacksteuereinheit in dem Fall, dass entschieden wird, dass durch das Sitzungsprotokoll konfiguriertes Feedback gegeben wird, und Senden von durch das Sitzungsprotokoll konfiguriertem Feedback, das eine Empfangsstatistik des genannten Multicast- oder Broadcast-Services anzeigt, an die Feedbacksteuereinheit über den eingerichteten Bearer.
  2. Das Verfahren gemäß Anspruch 1, worin die Parameter, welche an dem mobilen Terminal empfangen werden, einen Wahrscheinlichkeitswert für ein Wahrschein lichkeitsexperiment anzeigen, auf Grundlage dessen das mobile Terminal entscheidet, ob es durch das Sitzungsprotokoll konfiguriertes Feedback geben soll.
  3. Das Verfahren gemäß Anspruch 2, worin die Entscheidung darüber, ob Feedback gegeben werden soll, das Ausführen eines Wahrscheinlichkeitsexperiments an dem mobilen Terminal unter Verwendung des genannten empfangenen Wahrscheinlichkeitswerts und Entscheiden darüber, ob durch das Sitzungsprotokoll konfiguriertes Feedback auf der Grundlage des Ergebnisses des Experiments gegeben wird, umfasst.
  4. Das Verfahren gemäß Anspruch 2 oder 3, worin das Wahrscheinlichkeitsexperiment ein Bemoulli-Experiment ist.
  5. Das Verfahren gemäß einem der Ansprüche 1 bis 4, worin die Parameter über einen Multicast- oder Broadcast-Datenkanal empfangen werden, der den genannten Multicast- oder Broadcast-Service zur Verfügung stellt.
  6. Das Verfahren gemäß einem der Ansprüche 1 bis 4, worin die Parameter über einen Nachrichtenkanal empfangen werden, auf dem der Multicast- oder Broadcast-Service an potentielle Empfänger kundgegeben wird.
  7. Das Verfahren gemäß Anspruch 8, worin ein verlässliches Kommunikationsprotokoll für den Datentransport auf dem Nachrichtenkanal verwendet wird.
  8. Das Verfahren gemäß einem der Ansprüche 1 bis 7, worin die Parameter, die an dem mobilen Terminal empfangen werden, weiterhin den Zeitpunkt anzeigen, bis zu dem die Parameter gültig sind.
  9. Das Verfahren gemäß Anspruch 6, weiterhin den Schritt umfassend, dass das mobile Terminal den eingerichteten Bearer für das Übermitteln von durch das Sitzungsprotokoll konfiguriertem Feedback in dem Fall freigibt, dass der Zeitpunkt erreicht wird, der durch die Parameter angezeigt wird.
  10. Das Verfahren gemäß einem der Ansprüche 1 bis 9, weiterhin den Schritt des Empfangens von Rekonfigurationsparametern umfassend, worin die Rekonfigura tionsparameter die Parameter erneuern, die zuvor von der Feedbacksteuereinheit empfangen worden sind.
  11. Das Verfahren gemäß Anspruch 10, worin die Rekonfigurationsparameter eine Flag umfassen, die anzeigt, ob eine Gültigkeitsdauer für die zuvor empfangenen Parameter aktualisiert werden soll, und worin das Verfahren weiterhin den Schritt Aktualisierens der Gültigkeitsdauer der zuvor empfangenen Parameter auf der Grundlage dieser Flag umfasst.
  12. Das Verfahren gemäß Anspruch 11, worin die Aktualisierung der Gültigkeitsdauer nur durchgeführt wird, wenn das mobile Terminal einen Bearer für das Übermitteln von durch das Sitzungsprotokoll konfiguriertem Feedback eingerichtet hat.
  13. Das Verfahren gemäß einem der Ansprüche 10 bis 12, worin die empfangenen Rekonfigurationsparameter eine Flag umfassen, die anzeigt, ob eine neue Entscheidung darüber, ob eine Übermittlung von durch das Sitzungsprotokoll konfiguriertem Feedback durch das mobile Terminal durchgeführt werden soll, und weiterhin den Schritt des Bestimmens, ob oder ob nicht eine neue Entscheidung darüber, ob eine Übermittlung von durch das Sitzungsprotokoll konfiguriertem Feedback durch das mobile Terminal durchgeführt werden soll, auf der Grundlage dieser Flag umfassend, und wenn dem so ist, Entscheiden auf der Grundlage der empfangenen Rekonfigurationsparameter darüber, ob durch das Sitzungsprotokoll konfiguriertes Feedback für den Multicast- oder Broadcast-Service an die Feedbacksteuereinheit gegeben werden soll, Einrichten eines Bearers zum Übermitteln von durch das Sitzungsprotokoll konfiguriertem Feedback an die Feedbacksteuereinheit für den Fall, dass entschieden wird, dass durch das Sitzungsprotokoll konfiguriertes Feedback gegeben wird, und Senden von Feedback über den genannten eingerichteten Bearer an die Feedbacksteuereinheit, welche eine Empfangsstatistik des genannten Multicast- oder Broadcast-Services anzeigt.
  14. Ein Verfahren zum Steuern des Sendens von Feedback einer Mehrzahl von mobilen Terminals (712, 713), die über eine Funkschnittstelle eines mobilen Kommunikationssystems (702) einen Multicast- oder Broadcast-Service empfangen, durch eine Feedbacksteuereinheit (704), wobei das Verfahren die folgenden Schritte umfasst, die von der Feedbacksteuereinheit ausgeführt werden: Senden oder Weiterleiten von Daten des Multicast- oder Broadcast-Services über einen unidirektionalen Downlink-Kanal und unter Verwenden eines unzuverlässigen Transportprotokolls an zumindest ein mobiles Terminal und eines Sitzungsprotokolls, wobei das Sitzungsprotokoll Feedbackgeben von Terminals konfiguriert, die den Multicast- oder Broadcast-Service empfangen, Bestimmen von Parametern, die es einem mobilen Terminal ermöglichen, zu entscheiden, ob es der Feedbacksteuereinheit durch das Sitzungsprotokoll konfiguriertes Feedback geben soll, Senden der genannten Parameter an zumindest eine Untermenge der genannten Mehrzahl von mobilen Terminals, die den Multicast- oder Broadcast-Service empfangen, und Empfangen von durch das Sitzungsprotokoll konfiguriertem Feedback von einer Untermenge der genannten Mehrzahl von mobilen Terminals, die die genannten Parameter empfangen haben.
  15. Das Verfahren gemäß Anspruch 14, worin die Parameter auf der Grundlage von Statusinformationen des Multicast- oder Broadcast-Services bestimmt werden, die von der Feedbacksteuereinheit erhalten werden oder von einer Netzeinheit des mobilen Kommunikationssystems empfangen werden.
  16. Das Verfahren gemäß Anspruch 14 oder 15, worin die Parameter, welche durch die Feedbacksteuereinheit bestimmt werden, einen Wahrscheinlichkeitswert für ein Wahrscheinlichkeitsexperiment anzeigen, auf dessen Grundlage das mobile Terminal entscheidet, ob es Feedback gibt.
  17. Das Verfahren gemäß Anspruch 15 oder 16, worin die Parameter über einen Nachrichtenkanal gesendet werden, auf dem der Multicast- oder Broadcast-Service an potentielle Empfänger kundgegeben wird.
  18. Das Verfahren gemäß Anspruch 17, worin ein verlässliches Kommunikationsprotokoll für den Datentransport auf dem Nachrichtenkanal verwendet wird.
  19. Das Verfahren gemäß einem der Ansprüche 14 bis 18, worin die Parameter weiterhin den Zeitpunkt anzeigen, bis zu dem die Parameter gültig sind.
  20. Das Verfahren gemäß einem der Ansprüche 15 bis 19, weiterhin den Schritt des Bestimmens des Wahrscheinlichkeitswerts auf der Grundlage der Anzahl der Teilnehmer an dem Multicast- oder Broadcast-Service umfassend.
  21. Das Verfahren gemäß Anspruch 20, weiterhin den Schritt des Erhaltens der Anzahl der Teilnehmer an dem Multicast- oder Broadcast-Service aus den Statusinformationen, die von der Feedbacksteuereinheit erhalten oder empfangen werden, umfassend.
  22. Das Verfahren gemäß Anspruch 21, worin die Statusinformationen des Multicast- oder Broadcast-Services innerhalb des in der Feedbacksteuereinheit erhaltenen MBMS UE Context oder des MBMS Bearer Context enthalten sind.
  23. Das Verfahren gemäß Anspruch 21, weiterhin den Schritt des Empfangens der Statusinformationen des Multicast- oder Broadcast-Services von einer Netzeinheit des mobilen Kommunikationsnetzes, die einen MBMS UE Context oder einen MBMS Bearer Context behält, umfassend.
  24. Das Verfahren gemäß einem der Ansprüche 14 bis 23, weiterhin den Schritt des Empfangens der Daten des Multicast- oder Broadcast-Services von einem Multicast- oder Broadcast-Serviceprovider umfassend.
  25. Das Verfahren gemäß Anspruch 24, weiterhin den Schritt des Weiterleitens von durch das Sitzungsprotokoll konfiguriertem Feedback, das an der Feedbackeinheit empfangen wird, an den Multicast- oder Broadcast-Serviceprovider umfassend.
  26. Das Verfahren gemäß Anspruch 24 oder 25, worin die Daten des Multicastservices unter Verwendung eines Transportprotokolls und eines Sitzungsprotokolls zu der Feedbacksteuereinheit transportiert werden, und worin das Verfahren weiterhin den Schritt des Übersetzens zumindest eines von dem Transportprotokoll und dem Sitzungsprotokoll in ein anderes Transportprotokoll bzw. Sitzungsprotokoll vor dem Senden oder Weiterleiten der Daten des Multicast- oder Broadcast-Services an die mobilen Terminals umfasst.
  27. Das Verfahren gemäß Anspruch 25 oder 26, worin das Feedback für den Multicastservice unter Verwendung eines Transportprotokolls und eines Sitzungsprotokolls zu der Feedbacksteuereinheit transportiert wird, und worin das Verfahren weiterhin den Schritt des Übersetzens zumindest eines von dem Transportprotokoll und dem Sitzungsprotokoll in ein anderes Transportprotokoll bzw. Sitzungsprotokoll vor dem Weiterleiten des Feedbacks an den Multicast- oder Broadcast-Serviceprovider umfasst.
  28. Das Verfahren gemäß Anspruch 24, weiterhin die Schritte des Ausbilden eines Aggregats des durch das Sitzungsprotokoll konfigurierten Feedbacks, das an der Feedbacksteuereinheit empfangen wird, und des Sendens des genannten Aggregats des durch das Sitzungsprotokoll konfigurierten Feedbacks an den Multicast- oder Broadcast-Serviceprovider umfassend.
  29. Das Verfahren gemäß einem der Ansprüche 1 bis 28, worin der Multicast- oder Broadcast-Service unter Verwendung des RTP-Protokolls übermittelt wird und Feedback unter Verwendung des RTCP-Protokolls gegeben wird, worin ein Teil der verfügbaren Bandbreite für eine Sitzung, die den Multicast- oder Broadcast-Service bereitstellt, den RTCP-Protokollnachrichten zugewiesen wird.
  30. Das Verfahren gemäß Anspruch 29, worin das durch das Sitzungsprotokoll konfigurierte Feedback in Form von Empfängerbenachrichtigungen des RTCP-Protokolls zur Verfügung gestellt wird.
  31. Das Verfahren gemäß Anspruch 29 oder 30, worin die Parameter weiterhin das Benachrichtigungszeitintervall und die verfügbare Bandbreite zum Übermittels des durch das Sitzungsprotokoll konfigurierten Feedbacks unter Verwendung des RTCP-Protokolls anzeigen.
  32. Das Verfahren gemäß einem der Ansprüche 1 bis 31, worin die Parameter in einer Senderbenachrichtungsnachricht des RTCP-Protokolls, das von der Feedbacksteuereinheit gesendet wird, enthalten sind.
  33. Ein mobiles Terminal (712, 713), welches über eine Funkschnittstelle eines mobilen Kommunikationssystems (702) einen Multicast- oder Broadcast-Service empfängt, der durch eine Feedbacksteuereinheit (704) des mobilen Kommunikationssystems gesendet oder weitergeleitet wird, wobei das mobile Terminal umfasst: einen Empfänger zum Empfangen des Multicast- oder Broadcast-Services über einen unidirektionalen Downlink-Kanal und Verwenden eines unzuverlässigen Transportprotokolls und eines Sitzungsprotokolls, worin das Sitzungsprotokoll ein Feedbackgeben von Terminals konfiguriert, die den Multicast- oder Broadcast-Service empfangen, worin der Empfänger eingerichtet ist, weiterhin Parametern von der Feedbacksteuereinheit zu empfangen, auf Grundlage derer das mobile Terminal entscheidet, ob des der Feedbacksteuereinheit durch das Sitzungsprotokoll konfiguriertes Feedback geben soll, einen Prozessor zum Entscheiden darüber, ob der Feedbacksteuereinheit auf der Grundlage der empfangenen Parameter durch das Sitzungsprotokoll konfiguriertes Feedback für den Multicast- oder Broadcast-Service gegeben werden soll und zum Einrichten eines Bearers zum Übermitteln von durch das Sitzungsprotokoll konfiguriertem Feedback an die Feedbacksteuereinheit für den Fall, dass entschieden wird, dass durch das Sitzungsprotokoll konfiguriertes Feedback gegeben werden soll, und einen Sender zum Senden von durch das Sitzungsprotokoll konfiguriertem Feedback, das eine Empfangsstatistik des genannten Multicast- oder Broadcast-Services anzeigt, an die Feedbacksteuereinheit über den genannten eingerichteten Bearer.
  34. Eine Feedbacksteuereinheit (704) zum Steuern des Sendens von Feedback einer Mehrzahl von mobilen Terminals (712, 713), die einen Multicast- oder Broadcast-Service empfangen, der durch die Feedbacksteuereinheit über eine Funkschnittstelle eines mobilen Kommunikationssystems (702) gesendet oder weitergeleitet wird, wobei die Feedbacksteuereinheit umfasst: einen Sender zum Senden oder Weiterleiten von Daten des Multicast- oder Broadcast-Services über einen unidirektionalen Downlink-Kanal an zumindest ein mobiles Terminal und Verwenden eines unzuverlässigen Transportprotokolls und eines Sitzungsprotokolls, wobei das Sitzungsprotokoll Feedback von Terminals konfiguriert, die den Multicast- oder Broadcast-Service empfangen, einen Prozessor zum Bestimmen von Parametern, die es einem mobilen Terminal ermöglichen, zu entscheiden, ob es der Feedbacksteuereinheit durch das Sitzungsprotokoll konfiguriertes Feedback geben soll, wobei der Sender eingerichtet ist, die genannten Parameter an zumindest eine Untermenge der genannten Mehrzahl von mobilen Terminals, die den Multicast- oder Broadcast-Service empfangen, zu senden, und einen Empfänger zum Empfangen von durch das Sitzungsprotokoll konfiguriertem Feedback von einer Untermenge der genannten Mehrzahl von mobilen Terminals, die die genannten Parameter empfangen haben.
  35. Ein mobiles Kommunikationssystem (702), eine Feedbacksteuereinheit (704) gemäß Anspruch 34 und zumindest ein mobiles Terminal (712, 713) gemäß Anspruch 33 zum Empfangen eines Multicast- oder Broadcast-Services von der Feedbacksteuereinheit über eine Funkschnittstelle unter Verwendung eines unidirektionalen Downlink-Kanals und eines unzuverlässigen Transportprotokolls umfassend.
  36. Ein computerlesbarer Datenträger zum Speichern von Anweisungen, die, wenn sie von einem Prozessor eines mobilen Terminals (712, 713) ausgeführt werden, den Prozessor veranlassen, das Senden von Feedback des genannten mobilen Terminals, das über eine Funkschnittstelle eines mobilen Kommunikationssys tems (702) einen Multicast- oder Broadcast-Service empfängt, der durch eine Feedbacksteuereinheit (704) gesendet oder weitergeleitet wird, zu steuern durch: Empfangen des Multicast- oder Broadcast-Services über einen unidirektionalen Downlink-Kanal an dem mobilen Terminal unter Verwendung eines unzuverlässigen Transportprotokolls und eines Sitzungsprotokolls, worin das Sitzungsprotokoll Feedbackgeben von Terminals konfiguriert, die den Multicast- oder Broadcast-Service empfangen, Empfangen von Parametern von der Feedbacksteuereinheit an dem mobilen Terminal, auf Grundlage derer das mobile Terminal entscheidet, ob es der Feedbacksteuereinheit eine durch das Sitzungsprotokoll konfiguriertes Feedback geben soll, Entscheiden von dem mobilen Terminal darüber, ob es der Feedbacksteuereinheit auf der Grundlage der empfangenen Parameter durch das Sitzungsprotokoll konfiguriertes Feedback für den Multicast- oder Broadcast-Service geben soll, Einrichten eines Bearers durch das mobile Terminal zum Bereitstellen von durch das Sitzungsprotokoll konfiguriertem Feedback an die Feedbacksteuereinheit für den Fall, dass entschieden wird, dass durch das Sitzungsprotokoll konfiguriertes Feedback gegeben werden soll, und Senden von Feedback, welches eine Empfangsstatistik des genannten Multicast- oder Broadcast-Services anzeigt, von dem mobilen Terminal über den genannten eingerichteten Bearer an die Feedbacksteuereinheit.
  37. Ein computerlesbarer Datenträger zum Speichern von Anweisungen, die, wenn sie von einem Prozessor eines mobilen Terminals (712, 713) ausgeführt werden, den Prozessor veranlassen, das Senden von Feedback mobiler Terminals, die über eine Funkschnittstelle eines mobilen Kommunikationssystems (702) einen Multicast- oder Broadcast-Service empfangen, der durch eine Feedbacksteuereinheit (704) gesendet oder weitergeleitet wird, zu steuern durch: Senden oder Weiterleiten von Daten des Multicast- oder Broadcast-Services von der Feedbacksteuereinheit über einen unidirektionalen Downlink-Kanal an zumin dest ein mobiles Terminal und Verwenden eines unzuverlässigen Transportprotokolls und eines Sitzungsprotokolls, wobei das Sitzungsprotokoll ein Feedbackgeben von Terminals konfiguriert, die den Multicast- oder Broadcast-Service empfangen, Bestimmen von Parametern an der Feedbacksteuereinheit, die es einem mobilen Terminal ermöglichen, zu entscheiden, ob es der Feedbacksteuereinheit durch das Sitzungsprotokoll konfiguriertes Feedback geben soll, Senden der genannten Parameter von der Feedbacksteuereinheit an zumindest eine Untermenge der genannten Mehrzahl von mobilen Terminals, die den Multicast- oder Broadcast-Service empfangen, und Empfangen an der Feedbacksteuereinheit von durch das Sitzungsprotokoll konfiguriertem Feedback von einer Untermenge der genannten Mehrzahl von mobilen Terminals, die die genannten Parameter empfangen haben.
DE602004003933T 2004-08-06 2004-08-06 Rückkopplungssteuerung für Multicast und Broadcast Dienste Active DE602004003933T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP04018707A EP1624610B1 (de) 2004-08-06 2004-08-06 Rückkopplungssteuerung für Multicast und Broadcast Dienste

Publications (2)

Publication Number Publication Date
DE602004003933D1 DE602004003933D1 (de) 2007-02-08
DE602004003933T2 true DE602004003933T2 (de) 2007-04-12

Family

ID=34926082

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602004003933T Active DE602004003933T2 (de) 2004-08-06 2004-08-06 Rückkopplungssteuerung für Multicast und Broadcast Dienste

Country Status (6)

Country Link
US (3) US7522935B2 (de)
EP (2) EP1624610B1 (de)
JP (2) JP4794557B2 (de)
CN (2) CN101677430B (de)
DE (1) DE602004003933T2 (de)
WO (1) WO2006012946A2 (de)

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE602004003933T2 (de) * 2004-08-06 2007-04-12 Matsushita Electric Industrial Co., Ltd., Kadoma Rückkopplungssteuerung für Multicast und Broadcast Dienste
US7907911B2 (en) * 2005-08-16 2011-03-15 Alcatel-Lucent Usa Inc. Scheduling multi-user transmission in the downlink of a multi-antenna wireless communication system
KR101268200B1 (ko) 2006-01-05 2013-05-27 엘지전자 주식회사 이동통신 시스템에서의 무선자원 할당방법
KR100912784B1 (ko) 2006-01-05 2009-08-18 엘지전자 주식회사 데이터 송신 방법 및 데이터 재전송 방법
KR101203841B1 (ko) 2006-01-05 2012-11-21 엘지전자 주식회사 무선 통신 시스템에서의 페이징 메시지 전송 및 수신 방법
KR101265628B1 (ko) 2006-01-05 2013-05-22 엘지전자 주식회사 이동 통신 시스템에서의 무선 자원 스케줄링 방법
KR101187076B1 (ko) 2006-01-05 2012-09-27 엘지전자 주식회사 이동 통신 시스템에 있어서 신호 전송 방법
KR101211807B1 (ko) 2006-01-05 2012-12-12 엘지전자 주식회사 이동통신 시스템에서 무선단말의 동기상태 관리방법
JP4806030B2 (ja) 2006-01-05 2011-11-02 エルジー エレクトロニクス インコーポレイティド 移動通信システムで信号を転送する方法
EP1969738B1 (de) 2006-01-05 2014-03-12 LG Electronics Inc. Senden von informationen in einem mobilkommunikationssystem
WO2007078171A2 (en) 2006-01-05 2007-07-12 Lg Electronics Inc. Method of transmitting feedback information in a wireless communication system
ES2526814T3 (es) * 2006-01-11 2015-01-15 Core Wireless Licensing S.à.r.l. Extensiones para el Formato de Contenedores de Medios enriquecidos para su uso por parte de servidores de flujo continuo de difusión general/multidifusión
KR101358469B1 (ko) 2006-02-07 2014-02-06 엘지전자 주식회사 무선 네트워크(ｎｅｔｗｏｒｋ) 안에서 상향(ｕｐｌｉｎｋ)및 하향(ｄｏｗｎｌｉｎｋ) 대역폭(ｂａｎｄｗｉｄｔｈ)의선택 및 신호 방법
KR101216751B1 (ko) 2006-02-07 2012-12-28 엘지전자 주식회사 이동 통신 시스템에서 식별자를 이용한 충돌 회피 방법
KR101387475B1 (ko) 2006-03-22 2014-04-22 엘지전자 주식회사 복수의 네트워크 엔터티를 포함하는 이동 통신시스템에서의 데이터 처리 방법
KR20070121513A (ko) 2006-06-21 2007-12-27 엘지전자 주식회사 이동통신 시스템의 상향 접속 방법
WO2007148881A2 (en) 2006-06-21 2007-12-27 Lg Electronics Inc. Method of supporting data retransmission in a mobile communication system
KR101369135B1 (ko) 2006-06-21 2014-03-05 엘지전자 주식회사 이동통신 시스템에서의 멀티미디어 및 방송서비스의 품질보장 방법 및 그 단말
KR20070121505A (ko) 2006-06-21 2007-12-27 엘지전자 주식회사 무선링크 재설정 방법
WO2007148935A1 (en) 2006-06-21 2007-12-27 Lg Electronics Inc. Method of transmitting and receiving radio access information using a message separation in a wireless mobile communications system
EP1890408A3 (de) * 2006-08-18 2011-10-12 Samsung Electronics Co., Ltd. Verfahren und Vorrichtung zum Melden des Empfangsverhältnisses eines Streaming-Dienstes über ein Endgerät in einem mobilen Rundfunksystem, und System dafür
US8843118B2 (en) 2006-08-21 2014-09-23 Interdigital Technology Corporation Multi-cell coordination for multimedia broadcast multicast services in a wireless communication system
WO2008052382A1 (en) * 2006-10-30 2008-05-08 Huawei Technologies Co., Ltd. User equipment operations and maintenance measurement concept for multimedia broadcast and multicast services
US20080159324A1 (en) * 2006-12-27 2008-07-03 Peter Bosch Method of providing data broadcast/multicast
JP5149314B2 (ja) * 2007-03-09 2013-02-20 トムソン ライセンシング チャネル状態をフィードバックするための方法及び受信機
US8165154B2 (en) * 2007-03-12 2012-04-24 Conexant Systems, Inc. Systems and methods for reliable broadcast and multicast transmission over wireless local area network
US8170002B2 (en) * 2007-05-31 2012-05-01 Conexant Systems, Inc. Systems and methods for indicating buffered data at an access point with efficient beacon handling
US8089908B2 (en) 2007-03-13 2012-01-03 Conexant Systems, Inc. Systems and methods for indicating buffered data at an access point using a traffic indication map broadcast
US7916666B2 (en) 2007-04-03 2011-03-29 Itt Manufacturing Enterprises, Inc. Reliable broadcast protocol and apparatus for sensor networks
US20080298486A1 (en) * 2007-06-04 2008-12-04 Nec Laboratories America, Inc. Multi-cell interference mitigation via coordinated scheduling and power allocation in downlink odma networks
US8233414B2 (en) * 2007-07-05 2012-07-31 Conexant Systems, Inc. Systems and methods for indicating buffered data at an access point using an embedded traffic indication map
JPWO2009022752A1 (ja) * 2007-08-16 2010-11-18 日本電気株式会社 無線通信システム及び方法
US7944836B2 (en) * 2007-08-29 2011-05-17 Ericsson Ab Adaptive method and apparatus for adjusting network traffic volume reporting
US8086179B2 (en) 2007-09-24 2011-12-27 Qualcomm Incorporated Mobility management of multiple clusters within a wireless communications network
US8625475B2 (en) 2007-09-24 2014-01-07 Qualcomm Incorporated Responding to an interactive multicast message within a wireless communication system
JP2009159352A (ja) * 2007-12-27 2009-07-16 Hitachi Communication Technologies Ltd 移動体通信ネットワーク
CN101662726B (zh) 2008-08-26 2014-09-17 华为技术有限公司 统计多媒体广播多播业务的收视量的方法、网元和系统
US8611898B2 (en) * 2009-04-07 2013-12-17 Qualcomm Incorporated Reducing a number of flow references in messaging associated with a multicast session in a wireless communications system
US8102817B2 (en) * 2009-04-22 2012-01-24 Infineon Technologies Delta Gmbh Method of measurement reporting and cellular radio terminal
CN101945335B (zh) * 2009-07-10 2013-10-09 华为技术有限公司 广播组播条件下发送报告的方法及装置
US20110045821A1 (en) * 2009-08-24 2011-02-24 Motorola, Inc. Sampling and reporting performance of a communication network
US8594006B2 (en) 2010-01-27 2013-11-26 Qualcomm Incorporated Setting up a multicast group communication session within a wireless communications system
US8572276B2 (en) * 2010-04-29 2013-10-29 International Business Machines Corporation Pipelining protocols in misaligned buffer cases
CN101883107B (zh) * 2010-06-18 2014-06-04 华为技术有限公司 实现上下文感知业务应用的方法和相关装置
CN102291681A (zh) * 2010-06-21 2011-12-21 中国移动通信集团公司 网络侧获取用户侧业务接收状态的方法、设备和用户终端
US8699397B2 (en) * 2010-07-28 2014-04-15 Interdigital Patent Holdings, Inc. Method and apparatus for multimedia broadcast multicast services (MBMS) service feedback
TWI444056B (zh) * 2010-10-05 2014-07-01 Inst Information Industry 微型基地台、網路資源分配方法、其電腦可讀取記錄媒體及其電腦程式產品
US9491735B2 (en) * 2010-12-19 2016-11-08 Motorola Solutions, Inc. System and method in a communication network of dynamically assigning a multimedia broadcast/multicast service bearer to a multicast channel
US20130055136A1 (en) * 2011-08-22 2013-02-28 At&T Intellectual Property I, L.P. Methods, Systems, and Products for Controlling Quality of Service and Experience
US9053487B2 (en) 2011-08-22 2015-06-09 At&T Intellectual Property I, L.P. Methods, systems, and products for notifying of enhancements to quality of service and experience
GB2482991B (en) * 2011-08-24 2012-09-12 Renesas Mobile Corp Methods and apparatus for multicast transmission
US20130051386A1 (en) * 2011-08-24 2013-02-28 Renesas Mobile Corporation Methods and Apparatus for Multicast Transmission
US8989042B2 (en) * 2012-02-03 2015-03-24 Mediatek Inc. Method and apparatus for triggering and reporting diverse traffic information in cellular networks
KR102096566B1 (ko) 2012-04-13 2020-04-02 지이 비디오 컴프레션, 엘엘씨 저지연 화상 코딩
US9345573B2 (en) 2012-05-30 2016-05-24 Neovasc Tiara Inc. Methods and apparatus for loading a prosthesis onto a delivery system
RU2635251C2 (ru) 2012-06-29 2017-11-09 ДжиИ Видео Компрешн, ЭлЭлСи Концепция потока видеоданных
GB2504701A (en) * 2012-08-06 2014-02-12 Nec Corp Determining current state of a mobile device
JP5988835B2 (ja) * 2012-11-08 2016-09-07 オリンパス株式会社 無線送信端末、無線受信端末、無線通信システム、無線通信方法、およびプログラム
US8861355B2 (en) * 2012-11-14 2014-10-14 Qualcomm Incorporated Multicast rate control
WO2015027370A1 (en) * 2013-08-26 2015-03-05 Telefonaktiebolaget L M Ericsson (Publ) A method and arrangements in a communication system for enabling feedback transmission
US9774659B2 (en) * 2013-10-24 2017-09-26 Sap Se Bi-directional channel-based progress indicator
US20230362721A1 (en) * 2020-09-25 2023-11-09 Lenovo (Beijing) Limited Method and apparatus for multicast and broadcast services
WO2022077327A1 (en) * 2020-10-15 2022-04-21 Apple Inc. Techniques in multicast and broadband services (mbs) harq feedback
US11716747B2 (en) * 2021-04-02 2023-08-01 Nokia Technologies Oy Polling and keep-alive signals for multimedia broadcast multicast service

Family Cites Families (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5384777A (en) * 1993-04-19 1995-01-24 International Business Machines Corporation Adaptive medium access control scheme for wireless LAN
US6049535A (en) * 1996-06-27 2000-04-11 Interdigital Technology Corporation Code division multiple access (CDMA) communication system
US7020111B2 (en) * 1996-06-27 2006-03-28 Interdigital Technology Corporation System for using rapid acquisition spreading codes for spread-spectrum communications
US6885652B1 (en) * 1995-06-30 2005-04-26 Interdigital Technology Corporation Code division multiple access (CDMA) communication system
US7123600B2 (en) * 1995-06-30 2006-10-17 Interdigital Technology Corporation Initial power control for spread-spectrum communications
US7072380B2 (en) * 1995-06-30 2006-07-04 Interdigital Technology Corporation Apparatus for initial power control for spread-spectrum communications
US6489793B2 (en) * 1996-10-21 2002-12-03 Delta Design, Inc. Temperature control of electronic devices using power following feedback
US6392993B1 (en) * 1998-06-29 2002-05-21 Microsoft Corporation Method and computer program product for efficiently and reliably sending small data messages from a sending system to a large number of receiving systems
US6112323A (en) * 1998-06-29 2000-08-29 Microsoft Corporation Method and computer program product for efficiently and reliably sending small data messages from a sending system to a large number of receiving systems
US6381215B1 (en) * 1998-06-29 2002-04-30 Microsoft Corporation Method and computer program product for efficiently and reliably sending small data messages from a sending system to a large number of receiving systems
US6717990B1 (en) * 2000-01-05 2004-04-06 General Dynamics Decision Systems, Inc. Communication system and method for multi-rate, channel-optimized trellis-coded quantization
CA2417863A1 (en) * 2000-08-03 2002-02-14 Unicru, Inc. Electronic employee selection systems and methods
US7107224B1 (en) * 2000-11-03 2006-09-12 Mydecide, Inc. Value driven integrated build-to-buy decision analysis system and method
US7224758B1 (en) * 2001-03-23 2007-05-29 Via Telecom Co., Ltd. Multiple transmit antenna weighting techniques
JP2003037623A (ja) * 2001-07-23 2003-02-07 Philips Japan Ltd Ｍｐｅｇネットワーク上におけるダイレクトｒｔｐ伝送方法及びシステム
KR20040095277A (ko) * 2002-03-14 2004-11-12 유니버시티 오브 오타와 다이내믹 편광 모드 분산 에뮬레이터
US7177658B2 (en) * 2002-05-06 2007-02-13 Qualcomm, Incorporated Multi-media broadcast and multicast service (MBMS) in a wireless communications system
WO2004002048A1 (en) * 2002-06-21 2003-12-31 British Telecommunications Public Limited Company Timer-based feedback in multicast communication
US7746797B2 (en) * 2002-10-09 2010-06-29 Nortel Networks Limited Non-intrusive monitoring of quality levels for voice communications over a packet-based network
US7483711B2 (en) * 2002-10-24 2009-01-27 Bbn Technologies Corp Spectrum-adaptive networking
US7734762B2 (en) * 2002-10-29 2010-06-08 Telefonaktiebolaget L M Ericsson (Publ) Reporting for multi-user services in wireless networks
KR20040040724A (ko) * 2002-11-07 2004-05-13 엘지전자 주식회사 무선 이동 통신 시스템의 상향 공통채널 및 그 운용 방법
US7079854B2 (en) * 2003-01-11 2006-07-18 Lg Electronics Inc. Packet service system and method for controlling packet transmission
US7194249B2 (en) * 2003-01-31 2007-03-20 Qwest Communications International Inc. Methods, systems and apparatus for providing urgent public information
KR100559979B1 (ko) * 2003-04-03 2006-03-13 엘지전자 주식회사 이동통신 시스템에서의 메시지 전송방법
US7103772B2 (en) * 2003-05-02 2006-09-05 Giritech A/S Pervasive, user-centric network security enabled by dynamic datagram switch and an on-demand authentication and encryption scheme through mobile intelligent data carriers
EP1475984B1 (de) * 2003-05-09 2008-02-20 Motorola, Inc. Verfahren und Vorrichtung zur Kontrolle des Zugriffs auf "multimedia broadcast multicast service" in einem Paketdatenkommunikationssystem
KR100947741B1 (ko) * 2003-05-09 2010-03-17 엘지전자 주식회사 이동통신 시스템에서의 ｒｒｃ연결설정 방법
US20040242202A1 (en) * 2003-05-12 2004-12-02 Marko Torvinen System, apparatus, and method for automated handling of messages in terminals
US7599394B2 (en) * 2003-06-16 2009-10-06 Telefonaktiebolaget Lm Ericsson (Publ) Common rate control method for reverse link channels in CDMA networks
US7293088B2 (en) * 2003-07-28 2007-11-06 Cisco Technology, Inc. Tag location, client location, and coverage hole location in a wireless network
US7519019B2 (en) * 2003-08-12 2009-04-14 Telefonaktiebolaget Lm Ericsson (Publ) Method of rate control
KR100976475B1 (ko) * 2003-08-19 2010-08-18 엘지전자 주식회사 서비스 품질 (QoS) 측정보고 전송 방법 및 수신 방법
US20050094670A1 (en) * 2003-08-20 2005-05-05 Samsung Electronics Co., Ltd. Method for acquiring header compression context in user equipment for receiving packet data service
US7331008B2 (en) * 2003-08-21 2008-02-12 Lucent Technologies Inc. Erasure decoding optimization of acknowledgment/negative acknowledgment information in a wireless communication system
FI20031260A (fi) * 2003-09-04 2005-03-05 Nokia Corp Median suoratoisto palvelimelta asiakaslaitteelle
US7325034B2 (en) * 2003-09-24 2008-01-29 International Business Machines Corporation Method and apparatus for scalable peer-to-peer inquiries in a network of untrusted parties
US8687607B2 (en) * 2003-10-08 2014-04-01 Qualcomm Incorporated Method and apparatus for feedback reporting in a wireless communications system
US20050114023A1 (en) * 2003-11-26 2005-05-26 Williamson Walton R. Fault-tolerant system, apparatus and method
US7254609B2 (en) * 2003-12-09 2007-08-07 Viasat, Inc. Method for channel congestion management
US7650379B2 (en) * 2003-12-09 2010-01-19 Viasat, Inc. Method for channel congestion management
US7295568B2 (en) * 2003-12-31 2007-11-13 Nokia Corporation Apparatus, method and system for decision making to support network selection for datascasting in hybrid networks
KR100595646B1 (ko) * 2004-01-09 2006-07-03 엘지전자 주식회사 Ｍｂｍｓ서비스를 제공하는 무선통신 시스템
US7567523B2 (en) * 2004-01-29 2009-07-28 Microsoft Corporation System and method for network topology discovery
SE0400288D0 (sv) * 2004-02-11 2004-02-11 Ericsson Telefon Ab L M Improvements in or relating to telecommunication services
US8521139B2 (en) * 2004-02-11 2013-08-27 Qualcomm Incorporated Transmission of notifications for broadcast and multicast services
US7296205B2 (en) * 2004-02-18 2007-11-13 Nokia Corporation Data repair
US7133414B2 (en) * 2004-03-11 2006-11-07 Carrier Corporation Method for enhancing broadcast message communications
EP1603339A1 (de) * 2004-06-01 2005-12-07 STMicroelectronics S.r.l. Verfahren und System zur Übertragung von Videodaten in einem Netzwerk, zugehöriges paketvermitteltes Netzwerk und Computerprogramprodukt
US7376150B2 (en) * 2004-07-30 2008-05-20 Nokia Corporation Point-to-point repair response mechanism for point-to-multipoint transmission systems
DE602004003933T2 (de) * 2004-08-06 2007-04-12 Matsushita Electric Industrial Co., Ltd., Kadoma Rückkopplungssteuerung für Multicast und Broadcast Dienste
CN1315309C (zh) * 2004-09-30 2007-05-09 华为技术有限公司 多媒体广播组播业务系统中重新计数的方法
US8099123B2 (en) * 2004-12-23 2012-01-17 Qualcomm Incorporated Adaptation of transmit subchannel gains in a system with interference cancellation
US7148754B2 (en) * 2004-12-30 2006-12-12 Lucent Technologies Inc. Self-tunable phase lock loop
US20060184482A1 (en) * 2005-02-14 2006-08-17 Manyworlds, Inc. Adaptive decision process
US7542443B2 (en) * 2005-02-15 2009-06-02 Telefonaktiebolaget L M Ericsson (Publ) Receive window updates in communication systems
WO2006117645A2 (en) * 2005-05-03 2006-11-09 Nokia Corporation Scheduling client feedback during streaming sessions
US8208402B2 (en) * 2005-05-03 2012-06-26 Lg Electronics Inc. Changing a radio access configuration between a terminal and a network
ES2526814T3 (es) * 2006-01-11 2015-01-15 Core Wireless Licensing S.à.r.l. Extensiones para el Formato de Contenedores de Medios enriquecidos para su uso por parte de servidores de flujo continuo de difusión general/multidifusión
US20070226163A1 (en) * 2006-01-13 2007-09-27 Robles Daniel R Innovation Bank; a Novel Method of Business Related to the Integration and Capitalization of Knowledge Assets
US7725549B2 (en) * 2006-01-30 2010-05-25 International Business Machines Corporation System and method for hunting out mail recipients in order to obtain a response
US8843118B2 (en) * 2006-08-21 2014-09-23 Interdigital Technology Corporation Multi-cell coordination for multimedia broadcast multicast services in a wireless communication system
US8165154B2 (en) * 2007-03-12 2012-04-24 Conexant Systems, Inc. Systems and methods for reliable broadcast and multicast transmission over wireless local area network
US8089908B2 (en) * 2007-03-13 2012-01-03 Conexant Systems, Inc. Systems and methods for indicating buffered data at an access point using a traffic indication map broadcast
US8170002B2 (en) * 2007-05-31 2012-05-01 Conexant Systems, Inc. Systems and methods for indicating buffered data at an access point with efficient beacon handling
US20090028142A1 (en) * 2007-07-25 2009-01-29 Schmidt Brian K Streaming data content in a network

Also Published As

Publication number Publication date
JP4794557B2 (ja) 2011-10-19
EP1624610A1 (de) 2006-02-08
US8478327B2 (en) 2013-07-02
US20090175212A1 (en) 2009-07-09
JP4898889B2 (ja) 2012-03-21
CN100568805C (zh) 2009-12-09
EP1760933A2 (de) 2007-03-07
US20070281726A1 (en) 2007-12-06
EP1624610B1 (de) 2006-12-27
CN1961529A (zh) 2007-05-09
US8014813B2 (en) 2011-09-06
JP2010063129A (ja) 2010-03-18
WO2006012946A2 (en) 2006-02-09
WO2006012946A3 (en) 2006-03-16
CN101677430A (zh) 2010-03-24
US20110286333A1 (en) 2011-11-24
EP1760933B1 (de) 2012-03-14
JP2008509582A (ja) 2008-03-27
DE602004003933D1 (de) 2007-02-08
CN101677430B (zh) 2014-06-25
EP1760933A3 (de) 2007-04-04
US7522935B2 (en) 2009-04-21

Similar Documents

Publication Publication Date Title
DE602004003933T2 (de) Rückkopplungssteuerung für Multicast und Broadcast Dienste
DE602005006095T2 (de) Bereitstellen von Informationen über die Beziehungen individueller Träger für mobile Endgeräte, die einen Multicast- oder Broadcastdienst empfangen
DE60303806T2 (de) Berichterstattung für mehrbenutzerdienste in drahtlosen netzwerken
DE60126998T2 (de) Übertragung von multicast und broadcast multimedia diensten über eine funkschnittstelle
DE60222158T2 (de) Multicast-unterstützung in paketvermittelten drahtlosen netzwerken
DE602004006679T2 (de) Verfahren und Vorrichtung zur Konfiguration von Protokollen für einen Multimedia Broadcast/Multicast Dienst
DE60111276T2 (de) Verfahren und vorrichtung zur mehrfachsendung in einem umts-netzwerk
DE60218992T2 (de) Verfahren und Vorrichtung zum Datenrundsenden in Netzwerken der dritten Generation
DE602004005842T2 (de) Skalierbare und adaptive QoS-Architektur für Mehrkanal Multicast/Broadcast Dienste
DE19950653B4 (de) Verfahren zum Betreiben eines Mobilfunknetzes
DE602005006230T2 (de) Sende-und empfangsbestätigung von kontrollinformation für punkt-zu-mehrpunkt-dienst in einem drahtlosen kommunikationssystem
DE60319206T2 (de) Verfahren und Vorrichtung zur Kontrolle des Zugriffs auf &#34;multimedia broadcast multicast service&#34; in einem Paketdatenkommunikationssystem
DE60120354T2 (de) Rsvp-verarbeitung in 3g-netzwerken
DE69935397T2 (de) Verfahren und Vorrichtung zur Echtzeitdatenübertragung in einem Paketfunknetz
DE69833111T2 (de) Bestimmung von trägerdiensten in einem funkzugriffsnetz
DE112005000081B4 (de) Verfahren zum Übertragen von Nachrichten in Bezug zu einem Rundruf- oder Gruppenrufdienst in einem Funkzellenkommunikationssystem
DE102005033667B4 (de) Kommunikationssitzungs-Server-Einheit, Kommunikations-Endgerät, Broadcast-Server-Einheit, Netzwerkeinheit, Verfahren zum Steuern einer Kommunikationssitzung mit mehreren Kommunikations-Endgeräten, Verfahren zum Aufbauen einer Kommunikationssitzung, Verfahren zum Übertragen von Daten im Rahmen einer Kommunikationssitzung mittels einer Broadcast-Server-Einheit und Computerprogrammelemente
DE60106457T2 (de) Zuteilung von datenübertragungsbetriebsmitteln bei der paketvermittelten datenübertragung
US20090213775A1 (en) Deterministic feedback control for multicast or broadcast services
EP1325590A2 (de) Verfahren zur übertragung von datenpaketen über eine luftschnittstelle eines mobilfunksystems
DE212014000014U1 (de) Vorrichtung zum Verbessern der Qualität von Anrufen in einem Mobilfunkkommunikationssystem
DE60218573T2 (de) Verfahren und Vorrichtung zur Mehrfachsendung
WO2003101136A1 (de) Datenübertragungsverfahren und -system in einem mobilfunksystem
WO2013167424A1 (de) Verfahren zur übertragung von daten in einem paketorientierten kommunikationsnetzwerk und entsprechend eingerichtetes teilnehmergerät an dem kommunikationsnetzwerk
DE102014019581A1 (de) Anwendungsqualitätsverwaltung in einem kommunikationssystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: PANASONIC CORP., KADOMA, OSAKA, JP