DE60301145T2 - Mehrbenutzermultimedianachrichtendiensten - Google Patents

Mehrbenutzermultimedianachrichtendiensten Download PDF

Info

Publication number
DE60301145T2
DE60301145T2 DE60301145T DE60301145T DE60301145T2 DE 60301145 T2 DE60301145 T2 DE 60301145T2 DE 60301145 T DE60301145 T DE 60301145T DE 60301145 T DE60301145 T DE 60301145T DE 60301145 T2 DE60301145 T2 DE 60301145T2
Authority
DE
Germany
Prior art keywords
recipient
server
mms
user devices
receiving user
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.)
Expired - Lifetime
Application number
DE60301145T
Other languages
English (en)
Other versions
DE60301145D1 (de
Inventor
Frank Hundscheidt
Thorsten Lohmar
Ralf Keller
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE60301145D1 publication Critical patent/DE60301145D1/de
Application granted granted Critical
Publication of DE60301145T2 publication Critical patent/DE60301145T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • 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/1859—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/10—Multimedia 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/184—Messaging devices, e.g. message centre
    • 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
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/23—Reliability checks, e.g. acknowledgments or fault reporting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58—Message adaptation for wireless communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)
  • Telephonic Communication Services (AREA)

Description

  • Technisches Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft das Gebiet der Mobilkommunikationsnetze, insbesondere ein Verfahren sowie Vorrichtungen zum Optimieren von Mehrbenutzer-Multimedia-Messaging-Diensten.
  • Hintergrund der Erfindung
  • Der Kurznachrichtendienst (Short Message Service – SMS) hat sich im GSM-Standard (Global System for Mobile Communication – GSM) der zweiten Generation (2G) als äußerst erfolgreich erwiesen, wobei es möglich ist, eine Textübertragung in Nichtechtzeit mittels GSM-Endgeräten auszuführen, z.B. von einem Internet-Computer-Endgerät an ein Mobiltelefon oder von einem Mobiltelefon zu einem anderen. Dieser einfach zu benutzende Dienst für die Textübertragung in Nichtechtzeit soll in Mobilsystemen der 2,5G und dritten Generation (3G) von einem Multimedia-Nachrichtendienst (Multimedia Message Service – MMS) ersetzt werden. Mit dem MMS ist es den Benutzern möglich, Multimedia-Nachrichten (Multimedia Messages – MM) zu versenden und zu empfangen, nämlich unter Ausnutzung der gesamten Bandbreite von mittlerweile zur Verfügung stehenden Medienarten, z.B. Text, Bilder, Audio, Video, während gleichzeitig die Unterstützung neuer beliebter Inhaltstypen möglich ist.
  • Eine Nichtechtzeit-MM, oder auch Speichervermittlungs-MM genannt, ist eine Kombination aus einem oder mehreren verschiedenen Medienelementen in einer Multimedia-Präsentation, die zwischen Benutzervorrichtungen übertragen werden kann, ohne dass eine Echtzeitübertragung erforderlich ist. Der Nichtechtzeit-Multimedia-Messaging-Dienst soll in der Lage sein, aktuelle und künftige Multimedia-Messaging-Dienste zu unterstützen und die Fortschritte, die in der weltweiten Multimedia-Gemeinschaft erzielt werden, mit zusätzlichen mobilen Anforderungen auszunutzen.
  • In der 3rd Generation Partnership Project (3GPP) Technical Specification 22.140 V4.2.0 (2002-03) sowie der 3GPP Technical Specification 23.140 V4.6.0 (2003-03) ist der aktuelle Stand der Standardisierungsaktivitäten für den MMS beschrieben. Zum Senden einer MM von einem Absender an einen Empfänger kann das folgende Verfahren verwendet werden: Eine Benutzeragent (User Agent – UA), d.h. eine Anwendung, die sich im Benutzergerät (User Equipment – UE) des Absenders befindet, oder eine Vorrichtung, die am UE des Absenders angebracht werden kann, sendet eine MM mit einem Multimedia-Inhalt und einer Adresse des Empfängers an einen MMS Relay/Server (R/S) des Absenders. Der MMS-R/S des Absenders leitet den MM-Inhalt an einen MMS-R/S eines Empfängers, welcher anschließend einen im UE des Empfängers befindlichen UA benachrichtigt. Die Benachrichtigung enthält nicht die MM, jedoch einen Hinweis auf die aktuelle MM. Der Empfang der MM-Nachricht wird gegenüber dem MMS-R/S des Empfängers durch den MMS UA des Empfängers bestätigt, und die MM kann dann vom MMS UA des Empfängers abgerufen werden. Der Abruf der MM und das Lesen der MM durch den UA des Empfängers werden gegenüber dem MMS-R/S des Empfängers bestätigt. Ein MM-Übermittlungsbericht mit einer Identifizierung der ursprünglichen MM, der Empfängeradresse, einer Zeitangabe sowie dem Übermittlungsstatus kann durch den MMS-R/S des Empfängers erzeugt und dem MMS-R/S des Absenders gesendet werden. Der MMS-R/S des Absenders kann den Übermittlungsbericht an den MMS UA des Absenders senden, z.B. zur Angabe der Übermittlung der MM an den MMS UA des Absenders. Ein ähnliches Verfahren wird beschrieben zum Senden eines Lese-Antwort-Berichtes, der im MMS-R/S des Empfängers erzeugt wird, wenn die MM vom Empfänger gelesen wird.
  • Das Senden einer MM von einem Absender-UA an mehrere Empfänger-MMS-UAs ist möglich. Eine Alternative besteht in der Adressierung der MM an mehrere Empfänger-MMS-UAs sowie in der Durchführung der MM-Replikation direkt beim Absender-MMS-UA. Eine weitere Alternative betrifft das Senden der MM und der Adressen der mehreren Empfänger-MMS-UAs vom Absender-MMS-UA an den MMS-R/S des Absenders. Die Replikation der MM wird im Absender-MMS-R/S selbst für Empfänger-MMS-UAs ausgeführt, die vom selben Empfänger-MMS-R/S bedient werden. Zum Senden der replizierten MMs an einen oder mehrere Empfänger-MMS- R/S, die anschließend die Empfänger-MMS-UAs zum Abrufen der MM benachrichtigen, wird das Verfahren wie oben beschrieben fortgesetzt. Beide Verfahren ähneln der E-mail-Verteilung an eine Anzahl von Empfängern. Es wird entweder die gesamte Liste der Empfänger eingefügt und mehrere E-mails an jeden der Empfänger gesendet, oder es wird ein Listenserver wie Majordomo verwendet. Ein Listenserver verwaltet Adressenlisten von Benutzern, die in einer oder mehreren Gruppen angemeldet sind. Jede Gruppe kann mit einer Gruppenadresse identifiziert werden. Eine an eine der Gruppen adressierte E-mail enthält die entsprechende Gruppenadresse, aufgrund welcher sowie aufgrund der entsprechenden Liste der Listenserver die entsprechenden Benutzeradressen abrufen kann. Eine Kopie der E-mails wird an jede der entsprechenden Benutzeradressen gesendet.
  • Die oben beschriebenen Verfahren sind nicht sehr effizient. Im Falle der MM-Übermittlung an mehrere Empfänger-MMS-UAs stellt die Benachrichtigung und dann die vom Empfänger-MMS-UA ausgelöste Abrufsequenz eine Beschränkung dar. Im Falle, dass eine große Anzahl von Empfänger-UAs eine Benachrichtigung für dieselbe MM erhält, ist die Wahrscheinlichkeit, dass sämtliche oder ein hoher Bruchteil der Empfänger-MMS-UAs den Abruf der MM unmittelbar nach dem Erhalt der Benachrichtigung initiieren, eher groß. In dieser Situation sendet der Empfänger-MMS-R/S pro Empfänger-MMS-UA, der einen Abruf der MM anfordert, eine Abrufnachricht einschließlich der MM, was zu einer hohen Belastung des Empfänger-MMS-R/S und unter Umständen sogar zu einer Überlastung des Netzes führt, insbesondere in den knappen und kostenaufwendigen Funknetzen zwischen dem Empfänger-MMS-R/S und den Empfänger-MMS-UAs. Zusätzlich lösen Bestätigungen des Abrufes oder Lese-Antworten, die von den Empfänger-MMS-UAs gesendet werden, welche die MM empfangen und gelesen haben, die Erzeugung von Übermittlungs- bzw. Lese-Antwort-Berichten aus, wobei die Anzahl der Übermittlungs- bzw. Lese-Antwort-Berichte der Anzahl der Empfänger-UAs entspricht, die die MM empfangen und gelesen haben. Die Berichte können weiter an den Absender-MMS-R/S und den Absender-MMS-UA gesendet werden, was zu einer Überlastung des Netzes zwischen diesen Einrichtungen sowie zu einer Überlastung der Einrichtungen selbst führt.
  • Eine sogenannte MM1_submit.REQ-Nachricht mit Adressen und eine MM, die vom Absender-MMS-UA an den Absender-MMS-R/S gesendet wird, enthält Flags zum Anzeigen, ob ein Übermittlungsbericht, eine Antwortberechnung und eine Lese-Antwort angefordert werden. Allerdings handelt es sich hier um einfache Ja/Nein-Flags ohne jegliche Granularitätsanzeigen darüber, in welcher Form der Absender-MMS-UA den Bericht empfangen möchte. Insbesondere besteht derzeit keine Möglichkeit der Steuerung der Anzahl von Übermittlungsberichten und Lese-Antwort-Berichten an den Absender-MMS-R/S und den Absender-MM-UA, die durch Bestätigungen und Lese-Antwort-Nachrichten von den Empfänger-MMS-UAs an den Empfänger-MMS-R/S ausgelöst wurden. Insbesondere im Falle mehrerer Empfänger kann die Anzahl der Bestätigungen und Berichte sowie die für die Übertragung der Bestätigungen und Berichte erforderliche Mitteilungsübermittlung zu einer hohen Belastung der involvierten Netzeinrichtungen führen, was Überlastungssituationen oder Leistungsverminderungen nach sich zieht.
  • Die US 6,085,101 betrifft ein Verfahren und ein Kommunikationsnetz zum Senden einer einzigen Nachricht von einem Absender an eine Anzahl entfernter Empfänger mittels Multicast-Übertragung. Ein Sende-Kommunikationsendgerät sendet über eine Leitung die Nachricht und die Empfänger-Adressenliste an einen Netzserver, der die Nachricht über eine weitere Leitung an einen entfernten Netzserver weiterleitet. Der entfernte Netzserver stellt Verbindungen zu den angegebenen entfernten Empfängern zum Senden der Nachricht an die angegebenen entfernten Empfänger her.
  • In der WO 02/11398 A1 (Nokia Corp.) vom 07.02.2002 wird ein Verfahren zum Senden einer Multimedia-Nachricht von einem mobilen Sende-Endgerät über einen Kommunikationsserver an ein mobiles Empfangsendgerät offenbart. Die Möglichkeit des Multicastings wird hier nur sehr allgemein abgehandelt.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Ziel der vorliegenden Erfindung ist es, ein Verfahren, eine Vorrichtung und ein Computerprogramm anzugeben, die die Effizienz von Multimedia- Nachrichtendiensten gegenüber der Übermittlung von Multimedia-Nachrichten, und vorzugsweise gegenüber des Berichtens, erhöhen.
  • Dieses Ziel wird durch ein in Anspruch 1 beschriebenes Verfahren erreicht. Ferner wird die Erfindung mit einem Empfängerserver realisiert, der in Anspruch 15 beschrieben ist, sowie – gemäß der Beschreibung in Anspruch 16 – mit einem Computerprogramm, das in eine Verarbeitungseinheit eines Empfängerservers ladbar ist. Vorteilhafte Ausführungsformen sind in den Unteransprüchen beschrieben.
  • Es wird ein Verfahren zur effizienten Übertragung einer Multimedia-Nachricht von einer absendenden Benutzervorrichtung an empfangende Benutzervorrichtungen offenbart. Das Verfahren umfasst mehrere Schritte. In einem ersten Schritt wird eine erste Nachricht von der Absender-Benutzervorrichtung an einen Absenderserver gesendet. Die erste Nachricht umfasst die Multimedia-Nachricht sowie eine Anzeige der Adressen der empfangenden Benutzervorrichtungen. Beispiele für eine Anzeige von Adressen sind eine Gruppenadresse der empfangenden Benutzervorrichtungen oder eine Liste umfassend die Adressen der empfangenden Benutzervorrichtungen oder ein Kombination hiervon.
  • In einem zweiten Schritt wird eine Identifizierung eines Empfängerservers, der den empfangenden Benutzervorrichtungen zugeordnet ist, aufgrund der Anzeige der Adressen ausgeführt. Dieser Schritt kann das Auflösen einer Gruppenadresse umfassen. Nach der Identifizierung des Empfängerservers, dem die adressierten empfangenden Benutzervorrichtungen zugeordnet sind, wird die erste Nachricht an den identifizierten Empfängerserver gesendet. In einem folgenden Schritt werden die empfangenden Benutzervorrichtungen aufgrund der Anzeige der Adressen identifiziert, z.B. durch Auflösen einer Gruppenadresse in die Adressen der individuellen empfangenden Benutzervorrichtungen. Ferner wird eine Multicast-Übermittlung der Multimedia-Nachricht an die empfangenden Benutzervorrichtungen ausgeführt.
  • Das Verfahren erhöht die Effizienz von Multimedia-Nachrichtendiensten gegenüber der Übermittlung von Multimedia-Nachrichten an empfangende Benutzervorrichtungen aufgrund der Tatsache, dass eine Multicast-Übermittlung der Multimedia-Nachricht an die empfangenden Benutzervorrichtungen ausgeführt wird. Die Übertragung der Multimedia-Nachricht mittels Multicasting weist gegenüber der Unicast-Übertragung Vorteile auf, da der Mitteilungsübermittlungs- und Verarbeitungsaufwand für die Verteilung der Multimedia-Nachricht an die empfangenden Benutzervorrichtungen reduziert wird. Bei der Unicast-Übertragung muss der Empfängerserver an jede der empfangenden Benutzervorrichtungen eine separate Nachricht senden. Beim Multicasting kann die Multimedia-Nachricht vom Empfängerserver in einer einzigen Nachricht gesendet werden, die nahe bei den empfangenden Benutzervorrichtungen zur Übermittlung repliziert werden kann, wodurch der Mitteilungsübermittlungs- und Verarbeitungsaufwand des Empfängerservers sowie von möglichen Netzeinrichtungen zwischen dem Empfängerserver und den empfangenden Benutzervorrichtungen für die Multicast-Übermittlung reduziert wird. Mehr Effizienz wird erreicht durch die Verwendung einer oder mehrerer Gruppenadressen zur Anzeige von Adressen, was im Vergleich zu einer Liste individueller Adressen vorteilhaft ist, insbesondere für eine große Anzahl von Empfängern, da durch eine Gruppenadressierung das Senden vieler Adressen in einer Nachricht vermieden wird. Bei einer oder mehreren Gruppenadressen kann die erste Nachricht kürzer werden, wodurch die Netzbelastung sowie der Verarbeitungsaufwand der die erste Nachricht verarbeitenden Einrichtungen vermindert wird.
  • Die Multicast-Übermittlung umfasst die Schritte des Zuordnens einer Multicast-Adresse, des Sendens der Multicast-Adresse an die empfangenden Benutzervorrichtungen, des Einbettens der Multimedia-Nachricht in ein für eine Multicast-Übertragung geeignetes Objekt, des Vorbereitens durch die empfangenden Benutzervorrichtungen für einen Empfang des Objektes, des Beitretens durch die empfangenden Benutzervorrichtungen einer Multicast-Gruppe gemäß der Multicast-Adresse und des Sendens des Objektes über die Multicast-Übertragung an die empfangenden Benutzervorrichtungen. Der Schritt des Beitretens kann Teil des Vorbereitungsschrittes sein oder kann separat ausgeführt werden.
  • Gemäß einer bevorzugten Ausführungsform kann die Ausführung der Multicast-Übermittlung auf der Anzahl von empfangenden Benutzervorrichtungen basieren, z.B. durch Überprüfen eines Schwellenwertes, der, wenn er von der Anzahl der empfangenden Benutzervorrichtungen überstiegen wird, den Empfängerserver dazu veranlasst, mit einer Multicast-Übermittlung der Multimedia-Nachricht fortzufahren.
  • Gemäß einer weiteren bevorzugten Ausführungsform können die empfangenden Benutzer Vorrichtungen im Zusammenhang mit der Multicast-Adresse mindestens ein Element aus einer Gruppe umfassend eine Beschreibung eines Fehlerschutzschemas, ein Zeitfenster, einen Transaktionsschlüssel, Abrechnungsinformationen, ein URL (Uniform Resource Locator), ein URI (Uniform Resource Indicator), einen logischen Namen einer mit der Multicast-Adresse verbundenen Multicast-Gruppe, einer Übertragungsstartzeit und eine Anzahl von Übertragungen empfangen.
  • Gemäß einer weiteren bevorzugten Ausführungsform kann mindestens einer der Absenderserver und der Empfängerserver die Adressen der empfangenden Benutzervorrichtungen aus der Anzeige der Adressen auflösen. Das Auflösen der Adressen ist in dem Fall notwendig, dass eine Gruppenadresse zur Anzeige der Adressen verwendet wird. Das Auflösen kann von einem der Server ausgeführt werden, oder für die Server in einer weiteren einen auflösenden Dienst bereitstellenden Einrichtung.
  • Die empfangenden Benutzervorrichtungen können mehr als einem Empfängerserver zugeordnet sein, die aufgrund der Anzeige der Adressen identifiziert werden. In diesem Fall kann die erste Nachricht an den mehr als einen Empfängerserver gesendet werden. Jeder der mehr als einen identifizierten Empfängerserver kann dessen zugeordnete empfangenden Benutzervorrichtungen identifizieren, z.B. aufgrund der in der ersten Nachricht enthaltenen Anzeige der Adressen. Ferner kann jeder der identifizierten Empfängerserver, der die erste Nachricht empfangen hat, eine Multicast-Übermittlung der Multimedia-Nachricht an dessen zugeordnete empfangenden Benutzervorrichtungen ausführen.
  • Gemäß einer weiteren bevorzugten Ausführungsform wird ein Verfahren zum effizienten Berichten eines Übertragungszustandes einer an die empfangenden Benutzervorrichtungen adressierten Multimedia-Nachricht offenbart. Das Verfahren umfasst mehrere Schritte. In einem ersten Schritt wird eine Multimedia-Nachricht von einem Absenderserver bei einem Empfängerserver empfangen. Der Empfängerserver kann die empfangenden Benutzervorrichtungen, an die die Multimedia-Nachricht adressiert ist und die dem Empfängerserver zugeordnet sind, identifizieren. In einem nächsten Schritt, kann die Multimedia-Nachricht vom Empfängerserver an die adressierten empfangenden Benutzervorrichtungen, die dem Empfängerserver zugeordnet sind, gesendet werden. Ferner kann der Empfängerserver Statusmeldungen empfangen, die jeweils eine Anzeige eines individuellen Übertragungszustandes der Multimedia-Nachricht an einem der empfangenden Benutzervorrichtungen umfassen. Beispiele für die Anzeigen für den individuellen Übertragungszustand umfassen mindestens ein Element aus der Gruppe umfassend eine Bestätigung einer Benachrichtigung über die Multimedia-Nachricht, eine Bestätigung einer Übermittlung der Multimedia-Nachricht und eine Bestätigung eines Lesens der Multimedia-Nachricht. Die empfangenen Anzeigen können in einen Bericht, der den Übertragungszustand der Multimedia-Adresse darstellt, aggregiert werden, z.B. einen Bericht der Übermittlungs- und Lesebestätigungen umfasst, die von den empfangenden Benutzervorrichtungen in einer aggregierten Weise empfangen werden. Ferner kann der Bericht an den Absenderserver gesendet werden.
  • Das Verfahren erhöht die Effizienz von Multimedia-Nachrichtendiensten gegenüber dem Berichten eines Übertragungszustandes einer Multimedia-Nachricht, die an mehrere empfangende Benutzervorrichtungen adressiert ist. Das Berichten von Informationen in einer aggregierten Weise ist wesentlich effizienter als das Ausführen eines Berichtens durch Senden individueller Nachrichten, die jeweils einen individuellen Übertragungszustand einer adressierten empfangenden Benutzervorrichtung enthalten. Weniger Nachrichten können für aggregiertes Berichten verwendet werden, was zu einer niedrigeren Netzwerkbelastung sowie zu einem verminderten Verarbeitungsaufwand für den Empfängerserver und den Absenderserver führt, im Gegensatz zu den Lösungen gemäß dem Stand der Technik. Ferner stellt das aggregierte Berichten typischerweise eine adäquatere Übersicht über den Übertragungszustand im Vergleich zur individuellen Information zur Verfügung, wodurch eine schnellere Analyse des Übertragungszustandes möglich wird.
  • Die Multimedia-Nachricht kann von einer absendenden Benutzervorrichtung empfangen werden. Der vom Absenderserver empfangene Bericht kann an die absendende Benutzervorrichtung gesendet werden, um dieser den Übertragungszustand der Multimedia-Nachricht mitzuteilen.
  • Gemäß einer bevorzugten Ausführungsform werden die Anzeigen gemäß einer Anforderung kompiliert. Die Anforderung kann beispielsweise von mindestens einer Einrichtung aus einer Gruppe umfassend die absendende Benutzervorrichtung, den Absenderserver und den Empfängerserver hervorgerufen werden. Die kompilierten Anzeigen können erfindungsgemäß aggregiert werden. Die Anforderung kann modifizierbar sein, oder eine oder mehrere Anforderungen können der Anforderung hinzugefügt werden, z.B. vom Empfängerserver und/oder vom Absenderserver.
  • Gemäß einer bevorzugten Ausführungsform werden diejenigen der Zustandsmeldungen für den Bericht verwendet, die innerhalb eines Zeitintervalls empfangen werden. Durch das Sammeln von Statusmeldungen wie Bestätigungen innerhalb eines Zeitintervalls können lange Antwortzeiten für das Berichten vermieden werden.
  • Gemäß einer weiteren bevorzugten Ausführungsform sind eine oder mehrere der Anzeigen auf eine oder mehrere Adressen der empfangenden Benutzervorrichtungen beziehbar, und der Bericht umfasst die eine oder mehreren Adressen bezogen auf den Übertragungszustand. Das Berichten einer oder mehrerer Adressen bezogen auf den Übertragungszustand der Multimedia-Nachricht sorgt für weitere Informationen, die weiter verwendet werden können, z.B. kann eine empfangende Benutzervorrichtung, die die Multimedia-Nachricht nicht empfangen hat, nochmals zum Senden der Multimedia-Nachricht adressiert werden.
  • Gemäß einer weiteren bevorzugten Ausführungsform kann der Bericht für statistische und/oder Abrechnungszwecke verarbeitet werden.
  • Die empfangenden Benutzervorrichtungen können mehr als einem Empfängerserver zugeordnet sein. In diesem Fall kann der Absenderserver die Multimedia-Nachricht an den mehr als einen Empfängerserver senden und mehr als einen Bericht empfangen, die jeweils den Übertragungszustand der Multimedia-Nachricht bezogen auf den entsprechenden Empfängerserver darstellen. Zum Berichten des Übertragungszustandes der Multimedia-Nachricht kann der Absenderserver die mehr als einen Berichte in einen weiteren Bericht aggregieren, der den Übertragungszustand der Multimedia-Nachricht darstellt.
  • Die absendende Benutzervorrichtung kann einen Absender-Multimedia-Nachrichtendienst-Benutzeragenten umfassen. Die absendende Benutzervorrichtung kann ein Benutzerendgerät wie ein Mobiltelefon oder ein Server sein, mit Zugriff auf einen Multimedia-Nachrichtendienst zum Ausführen der Schritte des Verfahrens, soweit sich dieses auf die absendende Benutzervorrichtung bezieht.
  • Die empfangende Benutzervorrichtung kann jeweils einen Empfänger-Multimedia-Nachrichtendienst-Benutzeragenten umfassen. Entsprechend kann eine empfangende Benutzervorrichtung ein Benutzerendgerät wie ein Mobiltelefon oder ein Server sein, mit Zugriff auf einen Multimedia-Nachrichtendienst zum Ausführen der Schritte des Verfahrens, soweit sich dieses auf die empfangende Benutzervorrichtung bezieht.
  • Der Absenderserver kann ein Absender-Multimedia-Nachrichtendienst-Relay-Server und/oder der Empfängerserver kann ein Empfänger-Multimedia-Nachrichtendienst-Relay-Server sein. Der Absenderserver und der eine oder die mehreren Empfängerserver können auf separaten oder einer oder mehreren Plattformen realisiert sein.
  • Ein oder mehrere der Schritte des Verfahrens für die effiziente Übertragung einer Multimedia-Nachricht von einer absendenden Benutzervorrichtung an empfangende Benutzervorrichtungen sowie des Verfahrens für das effiziente Berichten von Informationen über einen Übertragungszustand der an die mehreren empfangenden Benutzervorrichtungen adressierten Multimedia-Nachricht können kombiniert werden. Durch die Kombination wird die Effizienz weiter erhöht, da ein Multimedia-Nachrichtendienst von der verminderten Mitteilungsübermittlung und dem reduzierten Verarbeitungsaufwand, die sowohl mit der Multicast-Übermittlung als auch mit dem verbesserten Berichten assoziiert sind, profitiert.
  • Die Erfindung wird in Vorrichtungen wie einem Empfängerserver, einem Absenderserver und einer absendenden Benutzervorrichtung realisiert, die im folgenden ausführlicher beschrieben werden sollen.
  • Offenbart wird ein Empfängerserver für die effiziente Übertragung einer Multimedia-Nachricht an empfangende Benutzervorrichtungen. Der Empfängerserver umfasst eine Empfangseinheit zum Empfangen von Nachrichten, eine Übertragungseinheit zum Senden von Nachrichten und eine Verarbeitungseinheit zum Verarbeiten von Nachrichten und Informationen. Die Empfangseinheit ist zum Empfangen einer ersten Nachricht enthaltend die Multimedia-Nachricht und eine Anzeige von Adressen der empfangenden Benutzervorrichtungen ausgestaltet. Die Verarbeitungseinheit ist zum Identifizieren der empfangenden Benutzervorrichtungen aufgrund der Anzeige der Adressen ausgestaltet. Ferner ist der Empfängerserver zum Ausführen einer Multicast-Übermittlung der Multicast-Nachricht an die empfangenden Benutzervorrichtungen ausgestaltet, wobei die Verarbeitungseinheit zum Ausführen einer Zuordnung einer Multicast-Adresse ausgestaltet ist, die Übertragungseinheit zum Senden der Multicast-Adresse an die empfangenden Benutzervorrichtungen ausgestaltet ist und die Verarbeitungseinheit zum Einbetten der Multimedia-Nachricht in ein für eine Multicast-Übertragung geeignetes Objekt ausgestaltet ist, und wobei die Übertragungseinheit zum Senden des Objektes über die Multicast-Übertragung an die empfangenden Benutzervorrichtungen ausgestaltet ist.
  • Gemäß einer bevorzugten Ausführungsform kann die Verarbeitungseinheit des Empfängerservers ausgestaltet sein, die Ausführung der Multicast-Übermittlung auf der Anzahl von empfangenden Benutzervorrichtungen zu basieren, z.B. durch das Treffen einer geeigneten Entscheidung für die Multicast-Übermittlung, wenn die Anzahl der empfangenden Benutzervorrichtungen einen Schwellenwert übersteigt.
  • Der Empfängerserver kann ausgestaltet sein, in Verbindung mit der Multicast-Adresse mindestens ein Element aus einer Gruppe umfassend eine Beschreibung eines Fehlerschutzschemas, ein Zeitfenster, einen Transaktionsschlüssel, Abrechnungsinformationen, einen URL (Uniform Resource Locator), einen URI (Uniform Resource Indicator), einen logischen Namen einer mit der Multicast-Adresse verbundenen Multicast-Gruppe, einer Übertragungsstartzeit und einer Anzahl von Übertragungen zu senden.
  • Die Verarbeitungseinheit des Empfängerservers kann ausgestaltet sein zum Auflösen der Adressen der empfangenden Benutzervorrichtungen aus der Anzeige der Adressen.
  • Gemäß einer bevorzugten Ausführungsform wird ein Empfängerserver zum effizienten Berichten eines Übertragungszustandes einer an die empfangenden Benutzervorrichtungen adressierten Multimedia-Nachricht offenbart. Der Empfängerserver umfasst eine Empfangseinheit zum Empfangen von Nachrichten, eine Übertragungseinheit zum Senden von Nachrichten und eine Verarbeitungseinheit zum Verarbeiten von Nachrichten und Informationen. Die Empfangseinheit ist zum Empfangen der Multimedia-Nachricht von einem Absenderserver ausgestaltet. Die Übertragungseinheit ist zum Senden der Multimedia-Nachricht an die adressierten empfangenden Benutzervorrichtungen, die dem Empfängerserver zugeordnet sind, ausgestaltet. Die Empfangseinheit ist zum Empfangen von Statusmeldungen ausgestaltet, jeweils umfassend eine Anzeige eines individuellen Übertragungszustandes der Multimedia-Nachricht an einer der empfangenden Benutzervorrichtungen. Die Verarbeitungseinheit ist zum Aggregieren der Anzeigen in einen Bericht, der den Übertragungszustand der Multimedia-Adresse darstellt ausgestaltet. Ferner ist die Übertragungseinheit zum Senden des Berichtes an den Absenderserver ausgestaltet.
  • Gemäß einer bevorzugten Ausführungsform des Empfängerservers kann die Verarbeitungseinheit zum Kompilieren der Anzeigen gemäß einer Anforderung, die aus mindestens einer Einrichtung aus einer Gruppe umfassend eine absendende Benutzervorrichtung, den Absenderserver und den Empfängerserver hervorgerufen wird, sowie zum Aggregieren der kompilierten Anzeigen ausgestaltet sein.
  • Die Verarbeitungseinheit des Empfängerservers kann zum Modifizieren der Anforderung und zum Kompilieren der Anzeigen gemäß der modifizierten Anforderung ausgestaltet sein. Zusätzlich oder alternativ kann die Verarbeitungseinheit zum Hinzufügen einer oder mehrerer Anforderungen sowie zum Kompilieren der Anzeigen gemäß der hinzugefügten einen oder mehreren Anforderungen ausgestaltet sein.
  • Gemäß einer weiteren bevorzugten Ausführungsform kann die Verarbeitungseinheit des Empfängerservers zum Verwenden derjenigen der Statusmeldungen für den Bericht ausgestaltet sein, die innerhalb eines Zeitintervalls empfangen werden.
  • Gemäß einer weiteren bevorzugten Ausführungsform kann die Verarbeitungseinheit des Empfängerservers zum Beziehen einer oder mehrerer der Anzeigen auf eine oder mehrere Adressen der empfangenden Benutzervorrichtungen sowie zum Beziehen der einen oder mehreren Adressen auf den Übertragungszustand in dem Bericht ausgestaltet sein.
  • Gemäß einer weiteren bevorzugten Ausführungsform kann die Verarbeitungseinheit des Empfängerservers zum Verarbeiten des Berichtes für statistische und/oder Abrechnungszwecke ausgestaltet sein.
  • Eine oder mehrere Funktionalitäten des offenbarten Empfängerservers zur effizienten Übertragung einer Multimedia-Nachricht von einer absendenden Benutzervorrichtung an empfangende Benutzervorrichtungen sowie zum effizienten Berichten eines Übertragungszustandes einer an empfangende Benutzervorrichtungen adressierten Multimedia-Nachricht können vorzugsweise kombiniert werden, wodurch die Effizienz des Multimedia-Messaging-Dienstes aufgrund der Tatsache erhöht wird, dass der Empfängerserver mit kombinierter Funktionalität zum Ausführen einer Multicast-Übermittlung sowie zum verbesserten Berichten gemäß der Erfindung ausgestaltet ist.
  • Das vorgeschlagene Verfahren wird ebenfalls in Computerprogrammen zum Ausführen von Schritten gemäß des vorgeschlagenen Verfahrens realisiert. Die Computerprogramme umfassen Teile von Softwarecodes, um das beschriebene Verfahren zum implementieren. Eines oder mehrere der Computerprogramme kann auf einem oder auf mehreren computerlesbaren Medien gespeichert sein. Ein computerlesbares Medium kann ein permanenter oder ein wiederbeschreibbarer Speicher in einer Vorrichtung wie einem Benutzerendgerät oder einem Server sein, oder kann extern angeordnet sein. Ein oder mehrere der Computerprogramme können als eine Signalfrequenz an eine Vorrichtung übertragen werden, z.B. über ein Kabel oder eine drahtlose Verbindungsstrecke.
  • Offenbart wird ein in eine Verarbeitungseinheit eines Empfängerservers ladbares Computerprogramm. Das Computerprogramm umfasst einen Code, der zum Ausführen der Schritte des Verfahrens nach einem der Ansprüche 1 bis 14 ausgestaltet ist, sofern sich diese auf den Empfängerserver beziehen.
  • Im folgenden werden ausführliche Ausführungsformen der vorliegenden Erfindung anhand der Figuren beschrieben.
  • Kurze Beschreibung der Figuren
  • 1 zeigt einen Nachrichtenfluss für MM-Übermittlung mittels Multicast;
  • 2 zeigt einen Nachrichtenfluss für Multicast-MM-Übermittlung an mehrere Empfänger-MMS-UAs;
  • 3 zeigt einen Nachrichtenfluss für einen MMS mit optimiertem Bestätigen und Berichten;
  • 4 zeigt ein vereinfachtes System zum Bereitstellen einer Multicast-MM-Übermittlung;
  • 5 zeigt eine beispielhafte Ausführungsform eines MMS-Systems.
  • Ausführliche Beschreibung der Erfindung
  • 1 zeigt eine erste Ausführungsform für einen optimierten MMS unter Verwendung der Multicast-Übertragungstechnologie für die Übermittlung einer MM. Zum Erreichen einer Effizienz beim Multicast-Transport ist eine MM vorzugsweise für eine große Anzahl von Empfängern bestimmt. Es existieren unterschiedliche Mechanismen zum Identifizieren einer MM für größere Empfängergruppen. Die Mechanismen basieren auf Gruppenadressen anstatt auf individuellen Adressen (z.B. Telefonnummer). Beispiele sind E-mail-Verteilerlisten, Majordomo-Listen oder eine dedizierte Anzeige in der MM oder eine die MM übertragende Nachricht. Am effizientesten ist jegliche Art der Übermittlungsoptimierung, z.B. durch Verwenden üblicher Funkkanäle, wenn sich eine Anzahl von Empfängern in selben geographischen Gebiet aufhalten.
  • Eine Gruppenadresse oder Gruppenkennung, wie ein Name einer Gruppe, kann in eine MM1_Submit.REQ-Nachricht M100 eingefügt werden, zum Anzeigen einer Gruppe von Benutzern, die mehreren Empfänger-MMS-R/Ss zugeordnet sind, an den Absender-MMS-R/S 101, wo die MM1_Submit.REQ-Nachricht M100 vom Absender-MMS-UA 100 an den Absender-MMS-R/S 101 gesendet wird. Im folgenden werden Gruppenadressen und Gruppenkennung als Synonyme zum Anzeigen einer Gruppe verwendet. Eine Gruppenadresse kann von einem Benutzer des UE bei dem Absender-MMS-UA 100 eingegeben werden. Somit macht die Verwendung von Gruppenadressierung und Sendemechanismen für Multimedia-Nachrichten das Verfahren für den Endbenutzer einfach und angenehm, da er von der Last befreit ist, sämtliche individuellen Adressen einzugeben, wie dies bei den MM-Lösungen gemäß dem Stand der Technik der Fall ist. Alternativ können die Adressen der mehreren Empfänger in die MM1_Submit.REQ-Nachricht M100 eingegeben werden.
  • Die MM1_Submit.REQ-Nachricht M100 umfasst zusätzlich die MM für die mehreren Empfänger. Der Empfang der MM1_Submit.REQ-Nachricht M100 kann durch den Absender-MMS-R/S 101 an den Absender-MMS-UA 100 bestätigt werden, z.B. durch eine MM1_submit.RES-Nachricht M101. Der Absender-MMS-R/S 101 identifiziert den Empfänger-MMS-R/S 102 und sendet die MM und die Gruppenadresse an den Empfänger-MMS-R/S mittels einer MM4_forward.REQ-Nachricht M102, deren Empfang vom Empfänger-MMS-R/S 102 an den Absender-MMS-R/S 101 mittels einer MM4_forward.RES-Nachricht M103 bestätigt werden kann. Falls der Empfänger-MMS-R/S 102 Gruppen-MMs nicht handhaben kann, d.h. eine MM begleitet von einer Gruppenadresse, so kann der Absender-MMS-R/S 101 die Adressen der Empfänger-MMS-UAs auflösen und leitet die MM und die Adressen mittels einer MM4_forward.REQ-Nachricht M102 an den Empfänger-MMS-R/S 102, wodurch eine Abwärtskompatibilität gewährleistet ist. Entsprechend kann der Empfang der MM4_forward.REQ-Nachricht M102 durch den Empfänger-MMS-R/S 102 an den Absender-MMS-R/S 101 mittels einer MM4_forward.RES-Nachricht M103 bestätigt werden. Werden die Empfänger-MMS-UAs von mehreren Empfänger-MMS-R/Ss bedient, können entsprechende MM4_forward.REQ-Nachrichten und MM4_forward.RES-Nachrichten an jeden bzw. von jedem der mehreren Empfänger-MMS-R/Ss gesendet werden. Vorzugsweise identifiziert der Absender-MMS-R/S 101 einen oder mehrere Empfänger-MMS-R/Ss, denen die Empfänger-MMS-UAs zugeordnet sind, aus dem Adressenfeld der MM1_Submit.REQ-Nachricht M100 und sendet eine Kopie der MM und eine oder mehrere Empfängergruppenadressen an jeden des einen oder der mehreren Empfänger-MMS-R/Ss.
  • Jeder der einen oder mehreren Empfänger-MMS-R/Ss kann seine Empfängergruppenadresse in die individuellen Adressen der Empfänger-MMS-UAs auflösen. Es gibt zwei Alternativen, um die individuellen Empfängeradressen aufzulösen: eine erste Alternative besteht darin, dass ein Gruppenauflösungsserver, der die Gruppenadresse oder Gruppenadressen in die individuellen Adressen auflöst, im Netzwerk zur Verfügung steht. Neben der der MM zugeordneten Gruppenadresse kann eine Anzeige dem Empfänger-MMS-R/S einen Auflösungsserver zum Auflösen der Adressen aus der Gruppenadresse anzeigen, z.B. eine Adresse eines Majordomo-Listenservers, der die Adressen gemäß der Gruppenadresse aufgelöst und die Adressen an den einen oder die mehreren Empfänger-MMS-R/Ss übermittelt. Die zweite Alternative besteht darin, dass die MM or eine oder mehrere der Nachrichten, die die MM enthalten, neben der Gruppenadresse eine Liste von Empfängern enthalten. Die Gruppenadresse wird zu Differenzierung zwischen verschiedenen Gruppen sowie zum Anzeigen von Gruppen-MMs verwendet. Hierdurch wird auch ein zusätzlicher Gruppenserver vermieden. Das Auflösen von Adressen in dem einen oder den mehreren Empfänger-MMS-R/Ss wird für große Benutzergruppen vorgezogen, z.B. 10.000 Empfänger-MMS-UAs, wodurch das Senden von vielen Adressen der Empfänger-MMS-UAs vom Absender-MMS-R/S an den einen oder die mehreren Empfänger-MMS-RSs vermieden wird, so dass die Netzbelastung aufgrund kürzerer Nachrichten und der Verarbeitungsaufwand bei den Absender- und Empfänger-MMS-R/Ss vermindert wird.
  • Zur effizienten Übermittlung der MM an die empfangenden UAs wird der Multimedia Broadcast/Multicast Service (MBMS) Multicast-Modus verwendet. Der MBMS wird derzeit in 3GPP standardisiert und ist in TS 22.146 und TR 23.846 (s. 3GPP TS 22.146 V5.2.0 (2002-03) bzw. 3GPP TR 23.846 0.3.0 (2002-01)) beschrieben. Für die multicast-basierte MMS-Übermittlung ordnet der Empfänger-MMS-R/S 102 eine Multicast-Adresse zu. Eine Internetprotokoll-(IP)-Multicast-Adresse identifiziert eine ganze Gruppe von Schnittstellen, anstatt nur einer. Das IGMP-Protokoll (Internet Group Multicast Protocol – s. IETF RFC2236) im Falle der IPv4 und das MLD (Multicast Listener Discovery – s. IETF RFC2710) im Falle der IPv6 werden für die Gruppenverwaltung verwendet. Die effiziente Übertragung von IP-Datagrammen ist möglich, da lediglich eine Kopie eines Paketes gesendet wird und das Paket nahe bei den Empfängern repliziert wird.
  • Die MM wird in ein Objekt eingebettet und unter Verwendung des UDP-(User Datagram Protokol)-Übertragungsprotokolls zu den Empfänger-MMS-UAs verschoben. Der Vorgang des „Einbettens" ist notwendig, um ein Transportprotokoll zum Weiterleiten der MM zur Multicast-Datenübermittlung zu verwenden, wie im folgenden beschrieben wird. Dieser Vorgang kann die Segmentierung einer großen MM in kleinere Fragmente beinhalten. Zusätzlich oder alternativ kann der Vorgang das Hinzufügen von Redundanz für die Korrektur und die Erkennung von Fehlern umfassen. Dieser Vorgang ist dem Vorbereiten von Web-Seiten für die Broadcast-Verteilung wie in DVB-T (Digital Video Broadcasting-Terrestric) sehr ähnlich. Zur Erhöhung der Zuverlässigkeit wird die Möglichkeit eines Datenkarussells für Web-Page-Broadcast in DVB-T verwendet, und diese Möglichkeit kann in ähnlicher Weise auf die Multicast-Übermittlung einer MM angewendet werden. Ein weiteres Protokollbeispiel, das für die Multicast-Übertragung geeignet ist, ist das BTFTP (Broadcast Trivial File Transfer Protocol).
  • Dieses Objekt, das die MM enthält, wird in der folgenden Beschreibung manchmal auch als „Push-Objekt" (push object) bezeichnet. Sämtliche Empfänger-MSS-UAs, die das Push-Objekt nicht empfangen, können die MM vom Empfänger-MMS-R/S 102 abrufen, nämlich gemäß dem Verfahren nach dem Stand der Technik, wie dies im Zusammenhang mit der 2 ausführlicher erläutert ist.
  • Während in der Fig. nur ein Empfänger-MMS-UA 103 gezeigt ist, stellt die 2 eine Erweiterung mit mehreren Empfänger-MMS-UAs 103, 204, 20n, 20m dar. Relevante Schritte beider 1 und 2 werden deshalb parallel beschrieben bzw. wird auf diese parallel Bezug genommen. Die 2 offenbart zusätzlich eine Anzeige eines Zeitmaßstabes, der in drei Hauptzeitdauern TP1, TP2, TP3 unterteilt ist. Eine erste Anfangsperiode kann durch die Übertragung von MM1_notification.REQ-Nachrichten M104, M204, M204n vom Empfänger-MMS-R/S 102 an die Empfänger-MMS-UAs 103, 204, 20n und die anschließende Bestätigung des Empfangs der MM1_notification.REQ-Nachrichten M104, M204, M204n durch MM1-notification.RES-Nachrichten M105, M205, M205n von den Empfänger-MMS-UAs 103, 204, 20n an den Empfänger-MMS-R/S 102 gegeben sein.
  • Die Multicast-Adresse ist in den MM1-notification.REQ-Nachrichten M104, M204, M204n enthalten, die von dem Empfänger-MMS-R/S 102 an die Empfänger-MMS-UAs 103, 204, 20n gesendet werden. Eine MM1_notification.REQ-Nachricht an den Empfänger-MMS-UA 20m ist in der Anfangsperiode TP1 gemäß 2 nicht gezeigt. Es kann vorkommen, dass nicht sämtliche MMS-UAs die MM1-notification.REQ-Nachrichten empfangen, z.B. weil nicht sämtliche Mobilendgeräte online sind oder die Übertragung gestört ist. Gemäß 2 kann beispielsweise ein Mobilendgerät, das den Empfänger-MMS-UA 20m überträgt, die an das Mobilendgerät gesendete MM1-notification.REQ-Nachricht verpassen. Das Senden einer MM1_notification.REQ-Nachricht an einen Empfänger-MMS-UA könnte nicht ausgeführt werden, wenn das UE, das diesen Empfänger-MMS-UA überträgt, offline ist.
  • Die MM1_notification-Nachrichten M104, M204, M204n umfassen die Multicast-Adresse und den Port und können mittels folgender Optionen verbessert werden. Eine erste Option ist die Verwendung eines Fehlerschutzschemas. Eine Beschreibung eines oder mehrerer Fehlerschutzschemata kann in die MM1_notification-Nachrichten M104, M204, M204n eingefügt sein. Es gibt verschiedene Wege, um ein Multicast-Push-Objekt gegen Beschädigung zu schützen.
  • Beispielsweise können Löschcodes (z.B. Reed-Solomon), bei denen Redundanz dem aktuellen Objekt hinzugefügt wird, das ein Identifizieren oder Korrigieren von Wortfehlern erlaubt, verwendet werden. Ein Wort kann auch ein einziges Bit oder eine Anzahl von Bits sein, z.B. ein Byte. Der Digital-Fountain-Mechanismus [Quelle: J. W. Byers, M. Luby, M. Mitzenmacher, A. Rege, A Digital Fountain Approach to Reliable Distribution of Bulk Data, in Proc. ACM SIGCOMM'98, September 1998] fügt gleichfalls dem ursprünglichen Objekt Redundanz hinzu. Karusselle oder Broadcast-Disks für die periodische Übertragung des Objektes können Verwendung finden. Beim Fehlen eines Wortes oder Fragmentes wartet der Empfänger-MMS-UA auf den nächsten Zyklus Die Anzahl der Zyklen ist in diesem Szenario beschränkt. Auch können Kombinationen der vorgenannten Mechanismen angewendet werden, um den MMS gegen Fehler zu schützen.
  • In der 2 ist eine zweite Zeitdauer TP2 gezeigt, in welcher die Empfänger-MMS-UAs der Multicast-Gruppe beitreten, sich auf den Empfang der MM vorbereiten, die MM empfangen und diesen bestätigen. Somit besteht eine weitere Option zum Verbessern der MM1_notification-Nachrichten in einer Anzeige eines Zeitfensters, wie der Zeitdauer TP2, während der das Push-Objekt auf dem Multicast-Kanal übertragen wird. Das Push-Objekt wird für eine unbegrenzte Zeit auf der Multicast-Gruppe nicht übertragen. Das Zeitfenster ist nicht auf eine einzige Push-Objekt-Übertragungsperiode beschränkt, da zyklische Wiederholungen möglich sind, z.B. durch ein Datenkarussell oder eine Broadcast-Disk. Die Zeitdauer TP2 als ein Beispiel für ein Zeitfenster kann durch eine Startzeit der Übertragung sowie eine Anzahl von Malen, die dieselbe MM verteilt wird, oder durch eine Start- und Stopzeit der Übertragung angezeigt werden.
  • Ferner kann eine MM1_notification-Nachricht durch Einschließen eines Transaktionsschlüssels verbessert werden, um eine Lauschabwehr zu erlangen. Wird eine derartige Benachrichtigungsnachricht über einen Unicast-Träger übertragen, so kann ein einfacher Mechanismus wie eine Anzeige eine Kanals, über den die MM an die Empfänger-MMS-UAs verteilt werden soll, sowie der Startzeit der Übertragung ausreichend sein. Die Anzeige muss nicht kodiert sein, aber der Inhalt kann verschlüsselt sein. Der Dekodierschlüssel kann über die Benachrichtigungsnachricht gesendet werden, d.h. über MM1_notification.REQ-Nachrichten M104, M204, M204n gemäß 2. Wahlweise können digitale Rechte-Verwaltungsinformationen, z.B. ein Rechte-Objekt, in der Benachrichtigungsnachricht verteilt werden, oder zusammen mit dem Inhalt selbst über einen Multicast-Transport.
  • Weitere Beispiele für die Verbesserung sind Abrechnungsinformationen, ein URL (Uniform Resource Locator)/URI (Unified Resource Indicator) für einen individuellen, z.B. zuverlässigeren, jedoch möglicherweise auch kostenaufwendigeren MMS-Inhalt-Abruf, sowie ein logischer Name für die Gruppe (die mit der Multicast-Adresse verbunden ist), um so eine bessere Anzeige gegenüber den Kunden zu schaffen. Als ein Beispiel für einen logischen Namen: Eine typische IP-Multicast-Adresse ist 224.2.4.3. Diese Gruppe kann für Informationen bezogen auf Grand Prix verwendet werden. Ein logischer Name wäre „GrandPrix" in Assoziierung mit der IP-Adresse 224.2.4.3. Der für die Multicast- Übertragung verwendete Übertragungskanal wird von der Multicast-Gruppe beschrieben, und somit von der Multicast-Adresse.
  • Die Empfänger-MMS-UAs 103, 204, 20n, die die MM1_notification.REQ-Nachrichten M104, M204; M204n innerhalb der Anfangszeitdauer TP1 empfangen haben, treten einer Multicast-Gruppe in den Vorgängen P200, P204, P20n bei und bereiten sich in den Vorgängen P200, P204, P20n zum Empfangen des Push-Objektes vor. Die Multicast-Gruppe kann aufgrund der in der MM1_notification.REQ-Nachricht enthaltenen Multicast-Adresse beitreten. Ein Empfänger-MMS-UA kann der Multicast-Gruppe beitreten durch Senden einer Nachricht wie einer IGMP- oder MLD-Nachricht an eine Einrichtung wie einen Gateway-GPRS-Supportknoten (GGSN), der einen Träger wie einen MBMS-Träger steuert, welcher für eine Multicast-MM-Übermittlung geeignet ist. Gemäß vorliegendem Beispiel senden Empfänger-MMS-UAs 103, 204, 20n die Nachrichten MC1, MC2, MC3, die beispielsweise IGMP- oder MLD-Nachrichten sind, an einen GGSN (in der 2 nicht dargestellt), um in den Vorgängen P200, P204, P20n der Multicast-Gruppe beizutreten. Zum Vorbereiten des Empfangs des Push-Objektes, kann z.B. ein Kanal zum Empfangen des Push-Objektes eingestellt werden. Alternativ oder zusätzlich kann eine Kodierung, ein Codec und/oder eine Bitanzahl angepasst werden. Ferner kann ein Speicher zum Speichern oder Verarbeiten der MM in den Empfänger-UEs reserviert werden.
  • Der Empfang der MM1_notification.REQ-Nachrichten M104, M204, M204n kann gegenüber dem Empfänger-MMS-R/S 102 durch MM1_notification-RES-Nachrichten M105, M205, M205n bestätigt werden. Mittels Multicast-Datenübermittlung wird das Push-Objekt an die Empfänger-MMS-UAs 103; 204; 20n übertragen M206. Um die korrekte Empfangswahrscheinlichkeit zu erhöhen, kann das Push-Objekt mehrere Male unter Verwendung eines Datenkarussells, wie oben erläutert, übertragen werden.
  • Der Empfang des Push-Objektes kann mit MM1_acknowledgement.REQ-Nachrichten M108, M208, M208n bestätigt werden.
  • Für solche Empfänger-MMS-UAs, die das Push-Objekt oder die MM1_notification.REQ-Nachrichten M104 verfehlen, z.B. aufgrund der Tatsache, dass das Push-Fenster verfehlt wurde, oder aufgrund einer verstümmelten Übertragung, oder aufgrund von Empfänger-MMS-UAs, die offline sind, kann das normale Abrufverfahren gemäß dem Stand der Technik zum Abrufen der MM verwendet werden. Gemäß 2 kann der Empfänger-MMS-UA 20m, der z.B. offline ist, durch eine MM1_notification.REQ-Nachricht M204n in der Zeitdauer TP3 benachrichtigt werden, wann er wieder erreichbar ist. Der MMS-UA 20m kann den Empfang der Benachrichtigungsnachricht M204m über eine MM1.notification.RES-Nachricht M205 bestätigen und kann anschließend die MM vom Empfänger-MMS-R/S 102 abrufen. Alternativ kann die Multicast-Übermittlung wiederholt werden, was bevorzugt erfolgt, wenn ein größerer Bruchteil der Empfänger-MMS-UAs die anfängliche MM1_notification.REQ-Nachrichten verfehlt hat.
  • Ein Berichten des Übertragungszustandes einer Multimedia-Nachricht und das Bestätigen von Berichten kann, wie in 1 gezeigt, gemäß dem Stand der Technik ausgeführt werden durch eine MM1_acknowledgement.REQ-Nachricht M108, eine MM4_delivery_report-REQ-Nachricht M109, eine MM4_delivery_report.RES-Nachricht M110, eine MM1_delivery.report.REQ-Nachricht M111, eine MM1_read_reply_recipient.REQ-Nachricht M112, eine MM1_read_reply_report.REQ-Nachricht M113, eine MM1_read_reply_report.RES-Nachricht M114 sowie eine MM1_read_replay_originator.REQ-Nachricht M115, oder aber gemäß einem effizienteren Berichten unter Verwendung einer Aggregation von Berichten, die im Zusammenhang mit 3 ausführlicher beschrieben ist.
  • Das beschriebene Verfahren kann, wie in 1 dargestellt, bei einem einzigen Empfänger-MMS-UA angewendet werden. Allerdings wird eine erhöhte Effizienz für mehrere Empfänger-MMS-UAs gewonnen. Der Betreiber eines Mobiltelekommunikationssystems, der MMS bereitstellt, kann die MM-Multicast-Übermittlung auf eine Anzahl von Empfänger-MMS-UAs beschränken, die einen Schwellenwert übersteigt. Bei einer Gruppe von Empfänger-MMS-UAs, die unterhalb des Schwellenwertes liegt, kann eine Unicast-Übertragung der MM Anwendung finden. Bei einer Anzahl von Empfänger-MMS-UAs, die den Schwellenwert übersteigt, wird die Multicast-MM-Übertragung zur Erhöhung der Effizienz angewendet.
  • Die Übertragung des Push-Objektes kann unmittelbar nach der Übertragung der MM1_notification.REQ-Nachrichten ausgeführt werden. Wahlweise kann ein Auslösungsereignis verwendet werden, um die MM an die Empfänger-MMS-UAs zu senden. Ein Auslösungsereignis wie eine Zeit kann vorzugsweise in Fällen sehr großer Gruppen angewendet werden, bei denen es eine Weile dauern kann, bevor sämtliche die Bestätigung der Benachrichtigungsnachricht zurückgesendet haben, d.h. durch Senden von MM1_notification.RES-Nachrichten. Das Zeitereignis kann auch verwendet werden, um unterschiedliche Zufallszeiterzeugungen in den Empfänger-MM-UA-UEs zu ermöglichen, bevor die MM1_notification.RES-Nachricht zurück an den Empfänger-MMS-R/S gesendet wird. Das Senden des Push-Objektes zu unterschiedlichen Zeiten reduziert die Belastung des Netzes, insbesondere im Falle einer hohen Dichte von MMS-UAs, die sich im selben geographischen Gebiet befinden, die z.B. mit derselben Funknetzsteuerungsvorrichtung (Radio Network Controller – RNC) verbunden sind oder sich in derselben Zelle befinden. Der Empfänger-MMS-R/S kann einen Zeitgeber verwenden, um Zeiten für die Übertragung der MM1_notification.REQ-Nachrichten und die Vorbereitung P200 für den Empfang des Push-Objektes bei den Empfänger-MMS-UAs zu berücksichtigen. Das Push-Objekt kann alternativ in Abhängigkeit des Empfangs von MM1_notification.REQ-Nachrichten gesendet werden. Erfolgreich empfange MM1_notification.REQ-Nachrichten können dem Empfänger-MMS-R/S 102 gegenüber durch MM1_notification.RES-Nachrichten angezeigt werden. Der Empfänger-MMS-R/S 102 kann das Push-Objekt senden, nachdem ein Schwellenwert für die Anzahl empfangener MM1_notification.RES-Nachrichten überstiegen ist. Auch können mehr als ein Empfänger-MMS-R/S in der MMS-Multicast-Übermittlung an mehrere Empfänger-MMS-UAs involviert sein. Ein Beispiel für ein System umfassend mehr als einen Empfänger-MMS-R/S ist in der 5. gezeigt.
  • Ein entsprechendes Prinzip kann beim WAP-Push (Wireless Application Protocol) angewendet werden. Beim WAP-Push wird zunächst eine Dienstanzeige übertragen, z.B. durch SMS. Die WAP-Over-The-Air-(OTA)-Spezificationen [s. www.wapforum.org] definieren sogenannte "Dienstanzeigen" [s. Service Indication, Version vom 31. Juli 2001, WAP-167-ServiceInd-20010731-a.pdf, verfügbar in www.wapforum.org], die eine Kurznachricht und einen URI (Universal Resource Identifier) zur Anzeige des Dienstes enthalten. Nach dem Empfang kann die Mobilvorrichtung den vom URI angezeigten Dienst starten oder auf später verschieben, z.B. kann sie ihn gemäß einer WAP-Sektion neuerer Telefone in eine „Push Inbox" verschieben. Die Erfindung kann auch zum weiteren Speichern und Weiterleiten von Lösungen verwendet werden, z.B. SMS oder erweiterte Mitteilungsübermittlungsdienste (Extended Messaging Services – EMS).
  • Teile der Gruppenverwaltung oder Gruppenauflösungsprozeduren können in einem MMS-VASP (Value Added Service Provider) implementiert sein. Ein MMS-VASP kann verwendet werden, um dem Absender-MMS-R/S anzuzeigen, ob eine MM an eine große Gruppe zu senden ist oder nicht. Der Absender-MMS-R/S kann diese Information berücksichtigen, bevor der die MM verteilt.
  • 3 zeigt ein Beispiel für einen MMS mit einer verbesserten Bestätigungs- und Berichtabwicklung. Eine MM kann von einem Absender-MMS-UA 300 an mehrere Empfänger-MMS-UAs entweder mittels Unicast-Übertragung gemäß dem Stand der Technik oder mittels des vorgeschlagenen MMS-Multicast-Übermittlungsmechanismus gesendet werden, wie er im Zusammenhang mit den 1 und 2 erläutert ist. In der 3 ist ein Unicast-Mechanismus gezeigt. Zur Vereinfachung sind lediglich ein Empfänger-MMS-R/S 302 und ein Empfänger-MMS-UA 303 gezeigt, die beispielhaft für einen oder mehrere Empfänger-MMS-R/Ss bzw. einen oder mehrere Empfänger-MMS-UAs stehen. Bei einer MM an mehrere Empfänger-MMS-UAs pro Empfänger-MMS-R/S erhöht sich die Anzahl der Nachrichten zwischen den mehreren MMS-UAs und dem Empfänger-MMS-R/S (z.B. Nachrichten M304–M308, M312). Sind mehrere Empfänger-MMS-R/Ss involviert, so erhöht sich die Anzahl der Nachrichten (z.B. Nachrichten M302, M303, M309, M310, M313, M314) zwischen dem Absender-MMS-R/S 301 und den mehreren Empfänger-MMS-R/Ss 302 mit der Anzahl der involvierten MMS-R/Ss. Ein entsprechender Anstieg findet bei den Vorgängen P302, P303, P305 im Falle mehrerer Empfänger-MMS-R/Ss statt.
  • Ein Mechanismus zum Steuern der Übermittlungs-, der Antwortabrechnungs- und/oder der Lese-Antwort-Berichte wird dem Absender-MMS-R/S 301 und/oder dem Empfänger-MMS-R/S 302 sowie vorzugsweise dem Absender-MMS-UA 300 bereitgestellt, zum Anzeigen der Art und Weise, wie der Absender-MMS-UA 300 beabsichtigt, einen oder mehrere Übermittlungs-, Antwortabrechnungs- und/oder Lese-Antwort-Berichte zu empfangen. Im folgenden wird zunächst die Anzeige vom Absender-MMS-UA 300 gegenüber dem Absender-MMS-R/S 301 beschrieben. Anschließend wird die Verarbeitung von Bestätigungen und den obenerwähnten Berichten erläutert.
  • Im Falle mehrerer Empfänger-UAs 303 werden der Übermittlungsbericht, die Antwortabrechnungs- und Lese-Antwort-Anzeiger in der MM1_submit.REQ-Nachricht M300, die vom Absender-UA 300 an den Absender-MMS-R/S 301 gesendet wird, von einem einfachen Ja/Nein- oder „Lese"/"Gelöscht ohne zu lesen"-Anzeiger so erweitert, dass sie beispielsweise die folgende Granularität enthalten.
    • • Information über individuellen Empfänger-MMS-UA erforderlich, z.B. durch Anzeigen der Adressen oder Kennungen der Empfänger-MMS-UAs gegenüber dem Absender-MMS-UA;
    • • Information erforderlich über die Anzahl oder den Prozentsatz der Empfänger-MMS-UAS, die die Nachricht innerhalb einer bestimmten Zeitdauer erhalten haben;
    • • Aggregierte Berichte erforderlich;
    • • Abrechnungs-/Berechnungsinformation angefordert.
  • Auch können Kombinationen von Anzeigern für angeforderte Berichte verwendet werden. Vorzugsweise kann der Benutzer des Absender-MMS-UA den Typ des angeforderten Berichtes auswählen, z.B. durch Auswählen von Anzeigern, die die Anforderung für einen aggregierten Bericht, der mit Abrechnungsinformationen ergänzt ist, anzeigen, und durch Senden dieser Anforderung an den Absender-MMS-R/S, z.B. über die MM1_submit_REQ-Nachricht M300. Die Auswahl kann mittels einer Eingabe-/Ausgabeeinheit erreicht werden. Die erhöhte Granularität, mit der der Absender-MMS-UA den bevorzugten Empfang von Übermittlungs-, Lese-Antwort- und Antwortabrechnungsberichten anzeigen kann, sorgt für einen erhöhten Komfort für den Endbenutzer sowie für effizientere Transportlösungen.
  • Der Absender-MMS-R/S 301 kann die Anforderung vom Absender-MMS-UA 300 über die MM4_forward.REQ-Nachricht M302 an den Empfänger-MMS-R/S 302 senden. Der Absender-MMS-R/S 301 kann auch im Vorgang P301 die Anforderung des Absender-MMS-UA 300 modifizieren und die modifizierte Anforderung an den Empfänger-MMS-R/S 302 senden. Zusätzlich oder alternativ kann der Absender-MMS-R/S eine oder mehrere Anforderungen hinzufügen, z.B. für eigene statistische oder Abrechnungs-/Berechnungszwecke, und die hinzugefügten Anforderungen an den Empfänger-MMS-R/S 302 senden. Modifizierte und/oder hinzugefügte Anforderungen werden vorzugsweise über die MM4_forward.REQ-Nachricht M302 gesendet.
  • Beispiele derartiger modifizierter oder hinzugefügter Anforderungen beinhalten:
    • • Information erforderlich über die Anzahl oder den Prozentsatz von Empfängern, die die Nachricht innerhalb einer bestimmten Zeitdauer erhalten haben;
    • • Information über den physikalischen Standort oder das Empfängernetz. Das Empfängernetz und/oder der physikalische Standort können für Abrechnungs- oder statistische Zwecke verwendet werden. Die aktuelle Entfernung zu dem einen oder mehreren Empfängernetzen oder lediglich die Tatsache, ob sich der Empfänger-MMS-R/S oder -UA im selben Netz befinden, können für Abrechnungs- und statistische Zwecke verwendet werden.
  • Der Absender-MMS-R/S 301 kann die Anzeiger speichern und die Berichte, die in der folgenden Prozedur zurückgesendet werden, verfolgen, und kann den Absender-MMS-UA 300 wie angefordert benachrichtigen. Ferner kann der Absender-MMS-R/S 301 die Information für eigene Zwecke verfolgen. Beispiele für den Gebrauch der Informationen in dem Absender-MMS-R/S 301 sind neue Multi-User-Abrechnungsmodelle, wobei z.B. die Gebühren für den Absender-MMS-UA 300 von der Anzahl der Empfänger oder der eigentlichen Verteilungsgeschwindigkeit abhängen. Die obenerwähnten Anforderungen zum Steuern der Übermittlungs-, der Antwortabrechnungs- und/oder der Lese-Antwort-Berichte kann vom Absender-MMS-UA 300 aus über den Absender-MMS-R/S 301 an die mehreren Empfänger-MMS-R/Ss ausgebreitet werden, wenn Empfänger-MMS-UAs mit verschiedenen Empfänger-MMS-R/Ss verbunden sind, wie dies z.B. in der 5 gezeigt ist. In diesem Fall kann der Absender-MMS-R/S 301 die Adressen der Empfänger-MMS-UAs auflösen und die Empfänger-MMS-UAs pro involviertem Empfänger-MMS-R/S verteilen. Mehrere MM4_forward.REQ-Nachrichten können zum Senden der MM und der obenerwähnten Anforderungen an die Empfänger-MMS-R/Ss mit einer MM4_forward-REQ-Nachricht pro involviertem Empfänger-MMS-R/S verwendet werden.
  • Nach Empfang der verbreiteten Anforderungen kann der eine oder die mehreren Empfänger-MMS-R/Ss 302 Informationen über den Typ des Berichtens speichern, dessen Übermittlung an den Absender-MMS-R/S 301 und/oder den Absender-MMS-UA 300 angefordert wurde. Der eine oder die mehreren Empfänger-MMS-R/Ss 302 können im Vorgang P302 Anforderungen hinzufügen oder die empfangenen Anforderungen im Vorgang P302 modifizieren, z.B. für eigene statistische Zwecke oder für Abrechnungs-/Berechnungszwecke, bevor der eine oder die mehreren Empfänger-MMS-UAs 303 über die MM benachrichtigt werden.
  • Die Übermittlung der MM an einen Empfänger-MMS-UA 303 kann mittels der MM1_notification.REQ-Nachricht 304, der MM1_notification.RES-Nachricht M305, der MM1_retriev.REQ-Nachricht M305 und der MM1_retrieve.Res-Nachricht M305 sowie mit entsprechenden weiteren Nachrichten erreicht werden, falls die MM an mehrere Empfänger-MMS-UAs übermittelt werden soll. Die Übermittlung an einen oder mehrere Empfänger-MMS-UAs kann auch über MMS-Multicast erreicht werden, wie im Zusammenhang mit den 1 und 2 erläutert, was z.B. im Falle großer Benutzergruppen pro involviertem Empfänger-MMS-R/S bevorzugt ist.
  • Nach Empfang der entsprechenden MM1_acknowledgement.REQ-Nachrichten M308 von den Empfänger-MMS-UAs 303 kann der eine oder die mehreren Empfänger-MMS-R/Ss 302 im Vorgang P303 die Informationen gemäß der Anforderung vom Absender-MMS-R/S 301 kompilieren. Bei der Kompilierung können die Bestätigungen, d.h. die M1_acknowledgement-REQ-Nachrichten M308 von dem einen oder den mehreren Empfänger-MMS-UAs 303 registriert werden. Weitere Informationen können aus dem MM-Übermittlungsvorgang abgeleitet werden, wie die Anzahl von Empfänger-MMS-UAs 303 aus der Anzahl von MM1_notification.RES-Nachrichten M304, die von dem einen oder den mehreren Empfänger-MMS-R/Ss 302 empfangen werden. Aufgrund der Kenntnis der Adressen der Empfänger-MMS-UAs 303 kann analysiert werden, welche der benachrichtigten MMS-UAs die Benachrichtigung empfangen haben und welche nicht. Es kann auch überprüft werden, welche der Empfänger-MMS-UAs den Empfang der MM bestätigt haben und welche nicht. Eine entsprechende Analyse kann für den einen oder die mehreren read_reply_recipient.REQ-Nachrichten M312 vorgenommen werden, die anzeigen, welche Empfänger-MMS-UAs die MM gelesen haben.
  • Um zu vermeiden, dass sämtliche Übermittlungs- oder Lesebestätigungen, d.h. die M1_acknowledgement.REQ-Nachrichten M308 und die read_reply_recipient.REQ-Nachrichten M312, die für diese MM empfangen werden, in einzelnen MM4_delivery_report.REQ-Nachrichten und MM4_read_reply_report.REQ-Nachrichten an den Absender-MMS-R/S 301 berichtet werden, kann der eine oder die mehreren Empfänger-MMS-R/Ss 302 die Übermittlungs- oder Lesebestätigungen in einem oder einigen Lese-Antwort-Berichten aggregieren.
  • Ein aggregierter Bericht kann eine Anzahl oder einen Prozentsatz der Empfänger-MMS-UAs umfassen, die die Übermittlung und/oder das Lesen der MM bestätigt haben. Der Bericht kann alternativ oder zusätzlich die Anzahl der Empfänger-MMS-UAs umfassen, die die Übermittlung und/oder das Lesen nicht bestätigt haben. Es kann für den Absender-MMS-UA 300 hilfreich sein, eine Anzeige der Adresse der Empfänger-MMS-UAs zu erhalten, die die Übermittlung oder das Lesen bestätigt oder nicht bestätigt haben. Deshalb können die Adressen der Empfänger-MSS-UAs mit den aggregierten Informationen über die Bestätigungen verknüpft werden. Um lange Berichtantwortzeiten zu vermeiden, kann der Empfänger-MMS-R/S die Bestätigungen innerhalb eines Zeitintervalls sammeln. In diesem Fall werden Bestätigungen registriert und für den Bericht kompiliert, wenn sie mit dem Zeitintervall übereinstimmen. Bestätigungen, die nicht innerhalb dieses Zeitintervalls empfangen werden, können verworfen oder für einen weiteren Bericht verwendet werden. Ein Zeitgeber, der in dem Empfänger-MMS-R/S angeordnet ist oder auf den von diesem zugegriffen werden kann, kann zum Starten des Zeitintervalls für die Registrierung von Bestätigungen sowie für das Beenden der Registrierung gemäß dem Zeitintervall verwendet werden. Der Start des Zeitgebers kann durch die MM1_notification.REQ-Nachrichten ausgelöst werden, wie eine oder mehrere Nachrichten M304 oder Nachrichten M104, M204, M204n, oder aber durch die Multicast-Übermittlung (Nachrichten M106; M206 in 1 und 2). Für einen aggregierten MMS-Bericht können empfangene Bestätigungen über die Übermittlung und das Lesen der MM auf die MM durch Verwendung einer Transaktionskennung bezogen werden, die in der MM1_notification.REQ-Nachricht an die Empfänger-MMS-UAs gesendet werden kann.
  • Ein Beispiel für einen aggregierten Bericht umfassend Informationen über die Übermittlung- und Lesebestätigung ist in der Tabelle A wiedergegeben. Der Bericht umfast eine MM-Kennung (MM ID). Ferner spezifiziert sie die Anzahl der adressierten Empfänger-MMS-UAs, d.h. die Anzahl der Empfänger-MMS-UAs, an die die MM im Falle einer Gruppe wie einer Multicast-Gruppe übermittelt werden soll. Die Anzahl der adressierten Empfänger-MMS-UAs ist die Anzahl der Empfänger-MMS-UAs in der Gruppe. Als Alternative kann die Anzahl der Empfänger-MMS-UAs die Anzahl der Adressen spezifizieren, die von dem Benutzer des Absender-MMS-UA, an den die MM übermittelt werden soll, ausgewählt wird. Die Anzahl der benachrichtigten Empfänger-MMS-UAs kann bestimmt werden, z.B. durch Zählen der Anzahl von MM1_notification.RES-Nachrichten (z.B. Nachrichten M105, M205, M205n, M305), die von den benachrichtigten Empfänger-MMS-UAs gesendet werden. Alternativ kann die Anzahl der MM1_notification.REQ-Nachrichten (z.B. Nachrichten M104, M204, M204n, M304) an die Empfänger-MMS-UAs gezählt werden. In ähnlicher Weise kann die Anzahl der Empfänger-MMS-UAs, die die MM empfangen haben, durch Zählen der MM1_acknowledgement.REQ-Nachrichten (z.B. Nachrichten M108, 208, M208n, M308) von den MMS-UAs, die die MM oder die entsprechenden Nachrichten für die Übermittlung (z.B. Nachrichten M106, M307) empfangen haben, bestimmt werden. Die Anzahl der Empfänger-MMS-UAs, die die MM gelesen haben, kann beispielsweise durch Zählen der Anzahl von MM1_read_reply_recipient.REQ-Nachrichten (z.B. M112, M312), die von den Empfänger-MMS-UAs zur Bestätigung des Lesens der MM gesendet werden, bestimmt werden.
  • Figure 00300001
    Tabelle A: Beispiel für einen aggregierten Bericht
  • Die Verwendung der obenerwähnten Nachrichten, die von den Empfänger-MMS-UAs zum Bestimmen der jeweiligen Anzahlen gesendet werden, hat den Vorteill, dass für die Erzeugung eines Berichtes bestätigte Informationen verwendet werden. Das Zählen der Nachrichten an die Empfänger-MMS-UAs hat den Vorteil, dass eine raschere Berichtserzeugung erreicht werden kann und dass Bestätigungsnachrichten von den Empfänger-MMS-UAs übersprungen werden können.
  • Das Korrelieren der individuellen Bestätigungsnachrichten mit Informationen bezogen auf die Adressen der Empfänger-MMS-UAs legt Informationen über die Adressen der Empfänger-MMS-UAs offen, die die Benachrichtigung verfehlt haben, die die Übermittlung der MM nicht bestätigen und/oder die das Lesen der MM nicht bestätigen.
  • Weitere Informationen wie die Übermittlungszeit, das Zeitintervall für den MM1_acknowledgement.REQ-Empfang und den MM1_read_reply_recipient.REQ- Empfang kann so festgelegt sein, dass dem Leser des Berichtes die jeweiligen Bestätigungsnachrichten-Sammelintervalle angezeigt werden.
  • Figure 00310001
    Tabelle B: Beispiel für einen kompilierten und aggregierten Bericht, der von dem Absender-MMS-R/S von einem ersten Empfänger-MMS-R/S empfangen wird.
  • Figure 00310002
    Tabelle C: Beispiel für einen kompilierten und aggregierten Bericht, der von dem Absender-MMS-R/S von einem zweiten Empfänger-MMS-R/S empfangen wird.
  • Figure 00310003
    Tabelle D: Beispiel für einen kompilierten und aggregierten Bericht, der von dem Absender-MMS-R/S an den Absender-MMS-UA gesendet wird.
  • Informationen wie eine Netzkennung können einem Bericht für den Fall hinzugefügt werden, dass sich einer oder mehrere der Empfänger-MMS-R/S in einem anderen Netz als dem des Absender-MMS-R/S befinden. Der eine oder die mehreren Empfänger-MMS-R/Ss sendet die aggregierten Berichte an den Absender-MMS-R/S, welcher die empfangenen Berichte vorzugsweise vor dem Senden eines Übermittlungs- und/oder Lese-Berichtes an den Absender-MMS-UA 300 kompiliert und weiter aggregiert.
  • Aus den Tabellen, B, C und D kann abgeleitet werden, dass Berichte mehr und mehr durch Kompilieren und Aggregieren komprimiert werden können. Ferner ist die Auswahl und/oder die weitere Verarbeitung von Informationen in den Berichten möglich, z.B. muss es nicht erforderlich sein, dem Benutzer des Absender-MMS-UA die Kennungen der involvierten Empfänger-MMS-R/Ss zur Verfügung zu stellen. Deshalb wird diese Information im Bericht für den Absender-MMS-UA übersprungen.
  • Die Aggregation von Übermittlungs- und Lese-Antwort-Berichten stellt adäquatere Übersichten des entsprechenden Status im Fall mehrere Empfänger derselben MM sowohl für die Absender-MMS-UA als auch den Relay/Server zur Verfügung. Die aggregierten Steuermechanismen ermöglichen eine hochtechnisiertere Gruppen-MMS-Abrechnung, die beispielsweise die Anzahl der Zielpunkte, die die MM empfangen haben, und/oder die Anzahl der Zielpunkte, die die MM gelesen haben, bei der Berechnung der Benutzer, die die MM abgesendet haben, berücksichtigen können, da z.B. der Absender- und Empfänger-MMS-Relay/Server auf die Anzahl der Empfänger-MMS-UAs, die die MM empfangen oder lesen, aufmerksam gemacht werden kann, indem entsprechende Einträge in einem oder mehreren Berichten erfindungsgemäß analysiert werden. Das Abrechnen des Benutzers des Absender-MMS-UA kann von einer weiteren Einrichtung ausgeführt werden, z.B. einem Abrechnungsserver, nämlich aufgrund eines oder mehrerer der erfindungsgemäßen Berichte. Der Absender-MMS-UA oder der Benutzer des Absender-MMS-UA kann die Informationen, die von dem/den kompilieren und aggregierten einen oder mehreren Berichten bereitgestellt werden, erfindungsgemäß analysieren, um beispielsweise eine Übertragung der MM an diejenigen der einen oder mehreren UAs zu initiieren, die die MM verfehlt, d.h. nicht empfangen haben.
  • Die aggregierte Antwortabrechnung ist ein Dienst, bei dem sich Betreiber selbst differenzieren können, da dem Absender-MMS-UA weniger berechnet werden kann, weil Übertragungsressourcen effizient ausgenutzt werden, z.B. aufgrund der verminderten Anzahl von Nachrichten, die für das Berichten des Empfangs und/oder des Lesens von MMs gebraucht werden. Im Falle der Antwortabrechnung zahlt der Absender-MMS-UA für die Antwortnachricht. Im Falle von Antwortnachrichten können der Empfänger-MMS-R/S und der Absender-MMS-R/S diese Antworten in eine zusammengefasste Antwortnachricht kompilieren. Im Falle, dass z.B. nur Ja/Nein oder 1/2 gültige Antworten darstellen, können der Absender- oder der Empfänger-MMS-R/S eine Gruppen-Antwortnachricht kompilieren, die Ja und Nein oder 1 und 2 mit den Anzahlen oder dem Prozentsatz von Empfänger-MMS-UAs anzeigen, die entsprechend geantwortet haben.
  • Gemäß dem Stand der Technik sind für eine Übermittlung einer MM an eine Anzahl von Empfänger-MMS-UAs bis zur selben Anzahl von Übermittlungsberichten und bis zur selben Anzahl von gelesenen Antworten möglich, wenn sämtliche adressierten MMS-UAs die Übermittlung und da Lesen der MM bestätigen. Gemäß der vorliegenden Erfindung ist lediglich ein Bericht an den Absender-MMS-UA erforderlich. Für den Fall, dass die Empfänger-MMS-UAs von einem Empfänger-MMS-R/S bedient werden, ist lediglich ein Bericht vom Empfänger-MMS-R/S an den Absender-MMS-RS erforderlich. Gehören die adressierten Empfänger-MMS-UAs zu verschiedenen MMS-R/Ss, so kann jeder Empfänger-MMS-R/S einen Bericht an den Absender-MMS-R/S senden, wodurch die Anzahl der Berichte geringfügig reduziert wird, im Vergleich mit dem Fall, wo mehrere Empfänger-UAs von einem Empfänger-MMS-R/S bedient werden. In jedem Fall – unabhängig von der Anzahl von involvierten Empfänger-MMS-UAs oder der Anzahl von Empfänger-MMS-R/Ss – kann sichergestellt werden, dass der Absender-MMS-UA lediglich einen aggregierten Bericht empfängt.
  • Aufgrund der Flexibilität des vorgeschlagenen Verfahrens kann dem Absender-MMS-UA auch mehr als ein Bericht bereitgestellt werden, z.B. wird dem Absender ein erster Bericht zur Verfügung gestellt, der die Anzahl der Empfänger-UAs angibt, die die MM innerhalb eines bestimmten Zeitintervalls empfangen haben, z.B. mehrere Minuten nach der Übermittlung der MM, und später, z.B. nach mehreren Stunden nach der Übermittlung der MM, mit einem zweiten Bericht, der die Anzahl der Benutzer angibt, die MM gelesen haben.
  • Ein Beispiel zeigt die Effektivität des vorgeschlagenen Verfahrens: Ein Absender sendet eine MM an 10.000 Empfänger-UAs verteilt auf 3 Empfänger-MMS-R/Ss. Gemäß dem Stand der Technik werden bis zu 10.000 Übermittlungsberichte und bis zu 10.000 gelesene Berichte erzeugt und von den Empfänger-MMS-R/Ss an den Absender-R/S übertragen, der bis zu 10.000 Übermittlungsberichte und bis zu 10.000 gelesene Berichte an den Absender-MMS-UA weiterleitet. Insgesamt werden bis 40.000 Berichtmeldungen gesendet. Zusätzlich betragen die Bestätigungsnachrichten für das Bestätigen des Empfangs der MM4_delivery_report.REQ-Nachrichten und der MM4_read_reply_report.REQ-Nachrichten, d.h. der MM4_delivery_report.RES-Nachrichten und der MM4_read_replay_report.RES-Nachrichten bis zu 10.000 für jeden Typ von Bestätigungsnachricht. Insgesamt müssen von den Einrichtungen, die gemäß des in 3GPP Technical Specification 23.140 V4.6.0 (2002-03) beschriebenen Verfahrens involviert sind, 60.000 Nachrichten erzeugt, übertragen und verarbeitet werden. Bei dem vorgeschlagenen Verfahren gemäß der vorliegenden Erfindung sind minimal 3 Berichte umfassend Übermittlungs- und Lese-Informationen vom Empfänger-MMS-R/S an den Absender-MMS-R/S erforderlich, und lediglich ein Bericht an den Absender-MMS-UA. Insgesamt sind lediglich 4 Berichte erforderlich. Fügt man 3 Nachrichten zum Bestätigen des Empfangs der Berichte, d.h. 3 Bestätigungsnachrichten, die vom Absender-MMS-R/S an die 3 Empfänger-MMS-R/Ss gesendet werden, hinzu, so beträgt die Gesamtanzahl der Nachrichten 7 und ist somit, im Vergleich zu den 60.000 Nachrichten gemäß der Lösung nach dem Stand der Technik wesentlich niedriger.
  • Die Anzahl von Nachrichten, die gemäß dem Stand der Technik und gemäß der vorgeschlagenen Erfindung für eine beliebige Anzahl von Empfänger-MMS-UAs und eine beliebige Anzahl von Empfänger-MMS-R/Ss benötigt wird, kann wie folgt berechnet werden:
    Anzahl von Empfänger-MMS-UAs: N
    Anzahl von Empfänger-MMS-R/Ss, die die N Empfänger-MMS-UAS bedienen: M
    Maximale Anzahl von Nachrichten gemäß dem Stand der Technik: 6 × N
    Minimale Anzahl von Nachrichten gemäß der Erfindung: 2 × M + 1
  • Zum Berechnen der maximalen Anzahl von Nachrichten gemäß dem Stand der Technik wurde davon ausgegangen, dass die Übermittlung und das Lesen von sämtlichen adressierten Empfänger-MMS-UAs bestätigt wurde. Lediglich die Nachrichten MM4_delivery_report.REQ, MM4_delivery_report.RES, MM1_delivery_report.REQ, MM4_read_reply_report.REQ, MM4_read_reply_report.RES und MM1_read_reply_originator.REQ wurden für die Berechnung gemäß dem Stand der Technik berücksichtigt.
  • Zum Berechnen der minimalen Anzahl von Nachrichten gemäß der Erfindung wurde davon ausgegangen, dass Übermittlungs- und Lese-Antwort-Informationen in einem Bericht aggregiert sind, d.h. die in den Nachrichten M309 und M313 enthaltenen Informationen werden in einem Bericht zusammengefasst, wodurch auch die Nachrichten M310 und M314 kombiniert werden. Zusätzlich werden die Nachricht M311 und M315 zum Berechnen der minimalen Anzahl von Nachrichten gemäß vorliegender Erfindung zusammengefasst. Allerdings gewährleistet die Kombination unterschiedlicher Berichte eine erhöhte Effektivität selbst in dem Fall, dass nur ein Empfänger-MMS-UA adressiert ist. Mit der vorliegenden Erfindung kann die Anzahl von Berichten betreffend die Übermittlung und das Lesen in jedem Fall von der Anzahl von Empfänger-MMS-UAs losgelöst werden.
  • Die 4 zeigt eine Multicast-MM-Übermittlung mit beispielhaften Vorrichtungen und Verbindungen zwischen den Vorrichtungen. Eine MM wird von einer ersten Einrichtung N400 über ein Dienstnetzwerk N401, ein Kernnetzwerk N402 und ein Funkzugangsnetzwerk N403, effizienterweise über einen gemeinsamen genutzten Kanal, an mehrere Empfänger-UAs N410, N420, N430 – hier als Mobil- und intelligente Telefone dargestellt – gesendet. Die erste Einrichtung N400 kann ein Absender-MMS-UA, ein Absender-MMS-R/S oder ein Empfänger-MMS-R/S sein. Die Verwendung einer einzigen Gruppenadresse anstelle mehrere Zieladressen ermöglicht eine effiziente und effektive Nutzung insbesondere der knappen Funkschnittstellenbetriebsmittel.
  • 5 zeigt eine beispielhafte Ausführungsform eines MMS-Systems zum Ausführen der vorgeschlagenen Erfindung mit mehreren Empfänger-MMS-UAs D02–D08, die von mehreren Empfänger-MMS-R/Ss S20, S30, S40 bedient werden. Werden die Netzelemente von einer einzigen Verwaltung gesteuert, so wird manchmal der Ausdruck MMS-Umgebung (MMS Environment – MMSE) für ein MMS-System verwendet, z.B. wie durch MMSE E100–E400 angedeutet. Gemäß dem vorliegenden Beispiel sind die mehreren Empfänger-MMS-UAs D02–D08 über Funkzugangsnetze RA02; RA03; RA04 an dem Empfänger-MMS-R/S S20, S30, S40 angeordnet. Eine MM kann von einem Absender-MMS-UA D01 über ein erstes Funknetz RA01 an einen Absender-MMS-R/S S10 gesendet werden. Bevorzugte Berichte können von dem Absender-MMS-UA D01 gegenüber dem Absender-MMS-R/S S10 angezeigt werden. Die MM kann auf die Empfänger-MMS-R/Ss S20–S40 verteilt und mittels Multicast an die Empfänger-MMS-UAs D02–D08 übermittelt werden. Erfindungsgemäß wird für die Übermittlung der MM vorzugsweise eine Multicast-Übertragung angewendet. Allerdings ist auch eine Unicast-Übertragung möglich, z.B. falls eines oder mehrere der bei der MM-Übermittlung involvierten Komponenten nicht multicast-tauglich ist oder falls die Anzahl der Empfänger-MMS-UAs pro Empfänger-MMS-R/S unterhalb eines bestimmten Schwellenwertes liegt. Auch ist eine Kombination von Multicast- und Unicast-Übermittlung möglich, z.B. die Multicast-Übermittlung für Empfänger-MMS-UAs D02–D07 und die Unicast-Übermittlung für den Empfänger-MMS-UA D08.
  • Bestätigungen wie MM1_acknowledgement.REQ- und MM1_read_reply_recipient.REQ-Nachrichten von den Empfänger-MMS-UAs D02–D08 werden von den Empfänger-MMS-R/Ss S20, S30, S40 in Berichte kompiliert und aggregiert und an den Absender-MMS-R/S S10 übertragen, der die Berichte von den Empfänger-MMS-R/Ss S20, S30, S40 vorzugsweise noch weiter kompiliert und aggregiert. Schließlich kann ein Bericht über die MM an den Absender-MMS-UA D01 gemäß den Präferenzen des Benutzers der Absender-MMS-UAs D01 oder des Betreibers, der den MMS bereitstellt, gesendet werden. Betreiberseitige Präferenzen können durch die Verwendung einer Modifizierungs- und Hinzufügungsfunktionalität gesetzt werden.
  • Zusammengefasst profitieren sowohl der Betreiber eines Telekommunikationsnetzes, der den MMS zur Verfügung stellt, als auch die Benutzer eines MMS von der erhöhten Effizienz der vorgeschlagenen Erfindung: Hohe Verarbeitungsbelastungen eines Empfänger-MMS-R/S und einer großer Aufwand bei der Mitteilungsübermittlung, die bei einem Funknetz besonders kostenaufwendig sind, können aufgrund der effizienten Multicast-Übermittlung und der Kompilierung und Aggregation von Berichten minimiert werden. Dies Einsparungsmaßnahmen bei Netzbetriebsmitteln kann die Kosten für den MMS unmittelbar verringern, und unterstützen dabei die Popularität des MMS noch mehr. Ein weiterer wichtiger Aspekt liegt darin, dass aggregierte Berichte normalerweise benutzerfreundlicher sind als der Weg des Berichtens über Einzelnachrichten gemäß dem Stand der Technik. Die Erfindung lässt sich zur Verwendung in 2G-, 2,5G- und 3G-Telekommunikationssystemen anpassen, z.B. gemäß dem GPRS-Standard (General Packet Radio Service) und dem UMTS-Standard (Universal Mobile Telecommunication System).
  • Die vorgenannten Ausführungsformen und das folgende Glossar dienen der Veranschaulichung und nicht der Beschränkung der Erfindung, und die Modifikationen, die im Sinne der Ansprüche sind, sollen hierin enthalten sein.

Claims (26)

  1. Verfahren zur effizienten Übertragung einer Multimedia-Nachricht von einer absendenden Benutzervorrichtung (100) an empfangende Benutzervorrichtungen (103, 204, 20n), wobei das Verfahren die Schritte umfasst: – Senden einer ersten Nachricht von der absendenden Benutzervorrichtung (100) an einen Absenderserver (101), wobei die erste Nachricht die Multimedia-Nachricht und eine Anzeige der Adressen der empfangenden Benutzervorrichtungen (103, 204, 20n) enthält, – Identifizieren eines Empfängerservers (102), der den empfangenden Benutzervorrichtungen (103, 204, 20n) zugeordnet ist, aufgrund der Anzeige der Adressen, – Senden der ersten Nachricht an den Empfängerserver (102), – Identifizieren der empfangenden Benutzervorrichtungen (103, 204, 20n) aufgrund der Anzeige der Adressen, gekennzeichnet durch – Ausführen einer Multicast-Übermittlung der Multimedia-Nachricht an die empfangenden Benutzervorrichtungen (103, 204, 20n) durch Zuordnen einer Multicast-Adresse, Senden der Multicast-Adresse an die empfangenden Benutzervorrichtungen (103, 204, 20n), Einbetten der Multimedia-Nachricht in ein für eine Multicast-Übertragung geeignetes Objekt, Vorbereiten durch die empfangenden Benutzervorrichtungen (103, 204, 20n) für einen Empfang des Objekts, Beitreten durch die empfangenden Benutzervorrichtungen (103, 204, 20n) einer Multicast-Gruppe gemäß der Multicast-Adresse und Senden des Objekts über die Multicast-Übertragung an die empfangenden Benutzervorrichtungen (103, 204, 20n).
  2. Verfahren nach Anspruch 1, wobei die Ausführung der Multicast-Übermittlung auf der Anzahl von empfangenden Benutzervorrichtungen (103, 204, 20n) basiert.
  3. Verfahren nach Anspruch 1 oder 2, wobei die empfangenden Benutzervorrichtungen (103, 204, 20n) in Verbindung mit der Multicast-Adresse mindestens ein Element aus einer Gruppe umfassend eine Beschreibung eines Fehlerschutzschemas, ein Zeitfenster, einen Transaktionsschlüssel, Abrechnungsinformationen, ein URL (Uniform Resource Locator), ein URI (Uniform Resource Indicator), einen logischen Namen einer mit der Multicast-Adresse verbundenen Multicast-Gruppe, einer Übertragungsstartzeit und eine Anzahl von Übertragungen empfangen.
  4. Verfahren nach einem der vorstehenden Ansprüche, wobei mindestens einer des Absenderservers (101) und des Empfängerservers (102) die Adressen der empfangenden Benutzervorrichtungen (103, 204, 20n) aus der Anzeige der Adressen auflöst.
  5. Verfahren nach einem der vorstehenden Ansprüche, wobei die empfangenden Benutzervorrichtungen (103, 204, 20n) mehr als einem Empfängerserver (102) zugeordnet sind, die aufgrund der Anzeige der Adressen identifiziert werden, die erste Nachricht an den mehr als einen Empfängerserver (102) gesendet wird und jeder der mehr als einen Empfängerserver (102) dessen zugeordnete empfangenden Benutzervorrichtungen (103, 204, 20n) identifiziert und eine Multicast-Übermittlung der Multimedia-Nachricht an dessen zugeordnete empfangenden Benutzervorrichtungen (103, 204, 20n) ausführt.
  6. Verfahren nach einem der vorstehenden Ansprüche, wobei das Verfahren weiterhin an ein effizientes Berichten eines Übertragungszustandes der an die empfangenden Benutzervorrichtungen (103, 204, 20n) adressierten Multimedia-Nachricht angepasst ist und die Schritte umfasst: – Empfangen von Statusmeldungen, jeweils umfassend eine Anzeige eines individuellen Übertragungszustandes der Multimedia-Nachricht an einem der empfangenden Benutzervorrichtungen (103, 204, 20n), – Aggregieren der Anzeigen in einen Bericht, der den Übertragungszustand der Multimedia-Adresse darstellt, und – Senden des Berichtes an den Absenderserver (101).
  7. Verfahren nach Anspruch 6, wobei mindestens eine der Anzeigen für den individuellen Übertragungszustand mindestens ein Element aus einer Gruppe umfassend eine Bestätigung einer Benachrichtigung über die Multimedia-Nachricht, eine Bestätigung einer Übermittlung der Multimedia-Nachricht und eine Bestätigung eines Lesens der Multimedia-Nachricht umfasst.
  8. Verfahren nach den Ansprüchen 6 oder 7, wobei die Anzeigen gemäß einer Anforderung kompiliert werden, die von mindestens einer Einrichtung aus einer Gruppe umfassend die absendende Benutzervorrichtung (100), den Absenderserver (101) und den Empfängerserver (102) hervorgerufen wird, und die kompilierten Anzeigen aggregiert werden.
  9. Verfahren nach Anspruch 8, wobei die Anforderung modifizierbar oder eine oder mehrere Anforderungen der Anforderung hinzufügbar sind.
  10. Verfahren nach einem der Ansprüche 6 bis 9, wobei diejenigen der Statusmeldungen für den Bericht verwendet werden, die innerhalb eines Zeitintervalls empfangen werden.
  11. Verfahren nach einem der Ansprüche 6 bis 10, wobei eine oder mehrere der Anzeigen auf eine oder mehrere Adressen der empfangenden Benutzervorrichtungen (103, 204, 20n) beziehbar sind und der Bericht die eine oder mehreren Adressen bezogen auf den Übertragungszustand umfasst.
  12. Verfahren nach einem der Ansprüche 6 bis 11, wobei der Bericht für statistische und/oder Abrechnungszwecke verarbeitet wird.
  13. Verfahren nach einem der Ansprüche 6 bis 12, wobei die empfangenden Benutzervorrichtungen (103, 204, 20n) mehr als einem Empfängerserver (102) zugeordnet sind und der Absenderserver (101) die Multimedia-Nachricht an den mehr als einen Empfängerserver (102) sendet und mehr als einen Bericht empfängt, die jeweils den Übertragungszustand der Multimedia-Nachricht bezogen auf den entsprechenden Empfängerserver (102) darstellen und der Absenderserver (101) die mehr als einen Berichte in einen weiteren Bericht aggregiert, der den Übertragungszustand der Multimedia-Nachricht darstellt.
  14. Verfahren nach einem der vorstehenden Ansprüche, wobei – die absendende Benutzervorrichtung (100) einen Absender-Multimedia-Nachrichtendienst-Benutzeragenten umfasst, und/oder – die empfangenden Benutzervorrichtungen (103, 204, 20n) jeweils einen Empfänger-Multimedia-Nachrichtendienst-Benutzeragenten umfassen, und/oder – der Absenderserver (101) ein Absender-Multimedia-Nachrichtendienst-Weitergabeserver ist, und/oder – der Empfängerserver (102) ein Empfänger-Multimedia-Nachrichtendienst-Weitergabeserver ist.
  15. Empfängerserver (102) für die effiziente Übertragung einer Multimedia-Nachricht an empfangende Benutzervorrichtungen (103, 204, 20n), wobei der Empfängerserver (102) eine Empfangseinheit zur Empfangen von Nachrichten, eine Übertragungseinheit zum Senden von Nachrichten und eine Verarbeitungseinheit zur Verarbeiten von Nachrichten und Informationen umfasst, wobei der Empfängerserver (102) zum Empfangen einer ersten Nachricht umfassend die Multimedia-Nachricht und eine Anzeige von Adressen der empfangenden Benutzervorrichtungen (103, 204, 20n), zum Identifizieren der empfangenden Benutzervorrichtungen (103, 204, 20n) aufgrund der Anzeige der Adressen ausgestaltet ist, dadurch gekennzeichnet, dass er zum Ausführen einer Multicast-Übermittlung der Multicast-Nachricht an die empfangenden Benutzervorrichtungen (103, 204, 20n) ausgestaltet ist, wobei der Empfängerserver (102) zum Zuordnen einer Multicast-Adresse, zum Einbetten der Multimedia-Nachricht in ein für eine Multicast-Übertragung geeignetes Objekt, zum Senden der Multicast-Adresse in Benachrichtigungsnachrichten an die empfangenden Benutzervorrichtungen (103, 204, 20n) zum Beitreten einer Multicast-Gruppe und zum Vorbereiten des Empfangs des Objekts, sowie zum Senden des Objekts über die Multicast-Übertragung an die empfangenden Benutzervorrichtungen (103, 204, 20n) ausgestaltet ist.
  16. Empfängerserver (102) nach Anspruch 15, wobei der Empfängerserver (102) ausgestaltet ist, die Ausführung der Multicast-Übermittlung auf der Anzahl von empfangenden Benutzervorrichtungen (103, 204, 20n) zu basieren.
  17. Empfängerserver (102) nach Anspruch 15 oder 16, wobei der Empfängerserver (102) in Verbindung mit der Multicast-Adresse zum Senden mindestens eines Elementes aus einer Gruppe umfassend eine Beschreibung eines Fehlerschutzschemas, ein Zeitfenster, einen Transaktionsschlüssels, Abrechnungsinformationen, einen URL (Uniform Resource Locator), ein URI (Uniform Resource Indicator), einen logischen Namen einer mit der Multicast-Adresse verbundenen Multicast-Gruppe, einer Übertragungsstartzeit und einer Anzahl von Übertragungen ausgestaltet ist.
  18. Empfängerserver (102) nach einem der Ansprüche 15 bis 17, wobei der Empfängerserver (102) zum Auflösen der Adressen der empfangenden Benutzervorrichtungen (103, 204, 20n) aus der Anzeige der Adressen ausgestaltet ist.
  19. Empfängerserver (102) nach einem der Ansprüche 15 bis 18, wobei der Empfängerserver (102) weiterhin zum effizienten Berichten eines Übertragungszustandes der an die empfangenden Benutzervorrichtungen (103, 204, 20n) adressierten Multimedia-Nachricht ausgestaltet ist, wobei der Empfängerserver (102) zum Empfangen von Statusmeldungen, jeweils umfassend eine Anzeige eines individuellen Übertragungszustandes der Multimedia-Nachricht an einem der empfangenden Benutzervorrichtungen (103, 204, 20n), zum Aggregieren der Anzeigen in einen Bericht, der den Übertragungszustand der Multimedia-Adresse darstellt, und zum Senden des Berichtes an den Absenderserver (101) ausgestaltet ist.
  20. Empfängerserver (102) nach Anspruch 19, wobei der Empfängerserver (102) zum Kompilieren der Anzeigen gemäß einer Anforderung, die aus mindestens einer Einrichtung aus einer Gruppe umfassend die absendende Benutzervorrichtung (100), den Absenderserver (101) und den Empfängerserver (102) hervorgerufen wird, sowie zum Aggregieren der kompilierten Anzeigen ausgestaltet ist.
  21. Empfängerserver (102) nach Anspruch 20, wobei der Empfängerserver (102) zum Modifizieren der Anforderung und zum Kompilieren der Anzeigen gemäß der modifizierten Anforderung oder zum Hinzufügen einer oder mehrerer Anforderungen sowie zum Kompilieren der Anzeigen gemäß der hinzugefügten einen oder mehreren Anforderungen ausgestaltet ist.
  22. Empfängerserver (102) nach einem der Ansprüche 19 bis 21, wobei der Empfängerserver (102) zum Verwenden derjenigen der Statusmeldungen für den Bericht ausgestaltet ist, die innerhalb eines Zeitintervalls empfangen werden.
  23. Empfängerserver (102) nach einem der Ansprüche 19 bis 22, wobei der Empfängerserver (102) zum Beziehen einer oder mehrerer der Anzeigen auf eine oder mehrere Adressen der empfangenden Benutzervorrichtungen (103, 204, 20n) sowie zum Beziehen der einen oder mehreren Adressen auf den Übertragungszustand in dem Bericht ausgestaltet ist.
  24. Empfängerserver (102) nach einem der Ansprüche 19 bis 23, wobei der Empfängerserver (102) zum Verarbeiten des Berichtes für statistische und/oder Abrechnungszwecke ausgestaltet ist.
  25. Empfängerserver (102) nach einem der Ansprüche 15 bis 24, wobei der Empfängerserver (102) ein Empfänger-Multimedia-Nachrichtendienst-Weitergabeserver ist.
  26. Ein in eine Verarbeitungseinheit eines Empfängerservers (102) ladbares Computerprogramm, wobei das Computerprogramm einen Code umfasst, der zum Ausführen der Schritte des Verfahrens nach einem der Ansprüche 1 bis 14 ausgestaltet ist, sofern sich diese auf den Empfängerserver (102) beziehen.
DE60301145T 2002-05-06 2003-05-06 Mehrbenutzermultimedianachrichtendiensten Expired - Lifetime DE60301145T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP02010050 2002-05-06
EP02010050 2002-05-06
PCT/EP2003/004731 WO2003094534A2 (en) 2002-05-06 2003-05-06 Multi-user multimedia messaging services

Publications (2)

Publication Number Publication Date
DE60301145D1 DE60301145D1 (de) 2005-09-01
DE60301145T2 true DE60301145T2 (de) 2006-04-20

Family

ID=29286112

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60301145T Expired - Lifetime DE60301145T2 (de) 2002-05-06 2003-05-06 Mehrbenutzermultimedianachrichtendiensten

Country Status (8)

Country Link
US (2) US8401032B2 (de)
EP (2) EP1601133B1 (de)
JP (1) JP4373324B2 (de)
AT (1) ATE300840T1 (de)
AU (1) AU2003239840A1 (de)
DE (1) DE60301145T2 (de)
ES (1) ES2246048T3 (de)
WO (1) WO2003094534A2 (de)

Families Citing this family (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2246048T3 (es) * 2002-05-06 2006-02-01 Telefonaktiebolaget Lm Ericsson (Publ) Servicio de mensajes multimedia multiusuario.
US7277697B2 (en) * 2003-05-23 2007-10-02 Adesh Desai Method and system for establishing a teleconference over a telephony network
KR20050015544A (ko) * 2003-08-06 2005-02-21 삼성전자주식회사 멀티미디어 방송/다중방송 서비스를 지원하는이동통신시스템에서 호출 메시지를 수신하지 못한 사용자단말기들에게 효율적으로 멀티미디어 방송/다중방송서비스를 제공하는 방법
GB0402774D0 (en) * 2004-02-09 2004-03-10 Nokia Corp Multimedia message transfer
US20050243721A1 (en) * 2004-04-29 2005-11-03 Zhijun Cai Method and apparatus for controlling access to a multimedia broadcast/multicast service
US8122145B2 (en) * 2004-05-17 2012-02-21 Nokia Corporation System, method and computer program product for grouping clients and transferring content in accordance with the same
DE102004028534A1 (de) * 2004-06-11 2006-01-05 Christian Meentzen Verfahren und Vorrichtung zur Überwachung des Verkehrs von elektronischen Nachrichten
DE102004050084B3 (de) * 2004-10-14 2006-03-02 Siemens Ag Verfahren zum Versenden einer Mehrzahl Nachrichten bei einem Kommunikationsendgerät
CN100581283C (zh) * 2004-11-16 2010-01-13 北京三星通信技术研究有限公司 适用于多媒体广播与组播业务的密码管理方法
US7673060B2 (en) * 2005-02-01 2010-03-02 Hewlett-Packard Development Company, L.P. Systems and methods for providing reliable multicast messaging in a multi-node graphics system
CN100455049C (zh) 2005-09-26 2009-01-21 华为技术有限公司 一种多媒体消息服务系统中对消息的处理方法
US20080040437A1 (en) * 2006-08-10 2008-02-14 Mayank Agarwal Mobile Social Networking Platform
US8068860B1 (en) * 2006-08-25 2011-11-29 At&T Mobility Ii Llc Short message service (SMS) protocol gateway
US20100046409A1 (en) * 2006-10-26 2010-02-25 Thorsten Lohmar Signalling Control for a Point-To-Multipoint Content Transmission Network
US20080125147A1 (en) * 2006-11-27 2008-05-29 Maguire Nicholas A Text message broadcasting
FI20061057A0 (fi) 2006-11-30 2006-11-30 Nokia Corp Välitystiedot tietoliikennejärjestelmässä
WO2008075324A1 (en) * 2006-12-21 2008-06-26 Mark Peter Dargan A system for providing group messaging services in a telecommunications network
US20080182603A1 (en) * 2007-01-30 2008-07-31 David Barnes Still Systems and methods for distributing messages to mobile devices
US9031583B2 (en) 2007-04-11 2015-05-12 Qualcomm Incorporated Notification on mobile device based on location of other mobile device
US20080254811A1 (en) 2007-04-11 2008-10-16 Palm, Inc. System and method for monitoring locations of mobile devices
US9140552B2 (en) * 2008-07-02 2015-09-22 Qualcomm Incorporated User defined names for displaying monitored location
GB0712878D0 (en) * 2007-07-03 2007-08-08 Skype Ltd Communication system and method
GB0712877D0 (en) * 2007-07-03 2007-08-08 Skype Ltd Multimedia mood messages
US20090137259A1 (en) * 2007-11-26 2009-05-28 Huawei Technologies Co., Ltd. Method and apparatus for sending message delivery reports
US20090248612A1 (en) * 2008-03-31 2009-10-01 Morris Robert P Methods, Systems, And Computer Program Products For Providing Prior Values Of A Tuple Element In A Publish/Subscribe System
US20090265643A1 (en) * 2008-04-18 2009-10-22 Alcatel Lucent Instant messaging reception indication
US8446850B2 (en) * 2008-07-08 2013-05-21 Intellectual Ventures Holding 81 Llc Method and apparatus for providing broadcast services
US8700071B2 (en) * 2008-08-01 2014-04-15 Cellco Partnership Direct mobile station-to-mobile station communication of multimedia message service (MMS) messages
WO2010075890A1 (en) * 2008-12-30 2010-07-08 Nokia Siemens Networks Oy Handling of delivery reports for messages having a one-to-many or many-to-one relationship
US9100222B2 (en) * 2008-12-31 2015-08-04 Sybase, Inc. System and method for mobile user authentication
US8380989B2 (en) 2009-03-05 2013-02-19 Sybase, Inc. System and method for second factor authentication
US8903434B2 (en) * 2008-12-31 2014-12-02 Sybase, Inc. System and method for message-based conversations
US9209994B2 (en) * 2008-12-31 2015-12-08 Sybase, Inc. System and method for enhanced application server
DE102009030219A1 (de) * 2009-06-23 2010-12-30 T-Mobile International Ag Verfahren zur Übertragung einer elektronischen Kurznachricht an mehrere Empfänger
CN101997696A (zh) * 2009-08-24 2011-03-30 华为终端有限公司 传递及接收Push消息的方法和设备
CN102223293B (zh) * 2010-04-16 2015-09-16 中兴通讯股份有限公司 消息请求的路由方法及处理系统
DE102010045683A1 (de) * 2010-09-16 2012-03-22 Heidelberger Druckmaschinen Ag Kombinierte Unicast/Multicast Softwareübertragung
EP2437428A1 (de) * 2010-10-01 2012-04-04 Koninklijke Philips Electronics N.V. Vorrichtung und Verfahren für den Datenabgleich zur Datenpaketübertragung in drahtlosen Netzwerken
EP2475139B1 (de) * 2011-01-06 2019-04-03 BlackBerry Limited Zustellung und Verwaltung von Statusbenachrichtigungen für mehrere Nachrichtenformate
EP2475138B1 (de) 2011-01-06 2019-03-13 BlackBerry Limited Lieferung und Verwaltung von Statusmeldungen bei der Gruppenbenachrichtigung
US9049025B1 (en) * 2011-06-20 2015-06-02 Cellco Partnership Method of decrypting encrypted information for unsecure phone
US9826502B2 (en) 2011-07-25 2017-11-21 Qualcomm Incorporated Managing handoff triggering between unicast and multicast services
US9208476B2 (en) 2011-09-12 2015-12-08 Microsoft Technology Licensing, Llc Counting and resetting broadcast system badge counters
US20130066979A1 (en) * 2011-09-12 2013-03-14 Microsoft Corporation Distributing events to large numbers of devices
US8825781B2 (en) * 2012-02-29 2014-09-02 Blackberry Limited Method and system for alerting unopened items in communications
CA2869505C (en) * 2012-05-14 2020-09-29 Huawei Technologies Co., Ltd. Method and system for group communication, group server, and group member device
CN103997724B (zh) * 2013-02-17 2017-12-15 阿尔卡特朗讯 一种用于聚合计费信息的方法、装置和系统
US9756097B2 (en) 2013-06-24 2017-09-05 Cisco Technology, Inc. Non-DSG mechanisms for aligning client devices with their multicast data flows in a DOCSIS network environment
IL228523A0 (en) * 2013-09-17 2014-03-31 Nds Ltd Processing private data in a cloud-based environment
JP5968930B2 (ja) * 2014-02-19 2016-08-10 京セラドキュメントソリューションズ株式会社 画像形成装置及びイベント通知システム
US9516268B2 (en) 2014-03-28 2016-12-06 International Business Machines Corporation Maintaining audio video conference continuity
US20150326513A1 (en) * 2014-05-07 2015-11-12 Mitake Information Corporation Message transmission system and method suitable for individual and organization
US20150381377A1 (en) * 2014-06-26 2015-12-31 Qualcomm Technologies International, Ltd. Method and apparatus for managing addresses and connectivity arrangements for transporting multicast data in a wireless network
US11943289B2 (en) 2014-10-14 2024-03-26 Comcast Cable Communications, Llc Manipulation of content transmissions
US11917002B2 (en) * 2014-10-14 2024-02-27 Comcast Cable Communications, Llc Manipulation and recording of content transmissions
GB2535513A (en) 2015-02-19 2016-08-24 Vodafone Ip Licensing Ltd Group messaging system
US9830603B2 (en) 2015-03-20 2017-11-28 Microsoft Technology Licensing, Llc Digital identity and authorization for machines with replaceable parts
US10469436B2 (en) * 2015-11-20 2019-11-05 Accenture Global Solutions Limited Managing messaging services
US10462093B2 (en) * 2015-12-03 2019-10-29 Facebook, Inc. Message data transfer
KR102362244B1 (ko) * 2017-03-25 2022-02-11 삼성전자주식회사 미션 크리티컬 데이터 통신 시스템에서의 데이터 송수신 방법 및 장치
US10461884B2 (en) 2017-10-05 2019-10-29 Comcast Cable Communications, Llc Server selected variable bitrate streaming
JP2019092133A (ja) * 2017-11-17 2019-06-13 株式会社東芝 送信装置、受信装置、通信システムおよびプログラム
US10862844B2 (en) * 2019-03-12 2020-12-08 Microsoft Technology Licensing, Llc Merged message storage data structure
US11012399B1 (en) * 2020-01-30 2021-05-18 Blackberry Limited Partial message delivery and status notification in an end-to-end secure messaging context
CN111464618B (zh) * 2020-03-30 2023-07-04 广州市百果园信息技术有限公司 一种消息推送方法、装置、设备和存储介质
WO2021244767A1 (en) * 2020-06-01 2021-12-09 Telefonaktiebolaget Lm Ericsson (Publ) Pfcp protocol extension related to event reporting
CN115134321A (zh) * 2021-03-12 2022-09-30 华为技术有限公司 一种消息处理方法及装置

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5920701A (en) * 1995-01-19 1999-07-06 Starburst Communications Corporation Scheduling data transmission
US6873627B1 (en) * 1995-01-19 2005-03-29 The Fantastic Corporation System and method for sending packets over a computer network
US6085101A (en) * 1996-05-17 2000-07-04 Telcordia Technologies, Inc. Communications network having a multicast capability
US6728775B1 (en) * 1997-03-17 2004-04-27 Microsoft Corporation Multiple multicasting of multimedia streams
US20030061368A1 (en) * 1997-03-17 2003-03-27 Navin Chaddha Adaptive right-sizing of multicast multimedia streams
US7031326B1 (en) * 1997-09-11 2006-04-18 At&T Corp Method and system for a Unicast endpoint client to access a multicast internet protocol (IP) session
US6115749A (en) * 1997-10-14 2000-09-05 Lucent Technologies Inc. System and method for using a window mechanism to control multicast data congestion
US5928331A (en) * 1997-10-30 1999-07-27 Matsushita Electric Industrial Co., Ltd. Distributed internet protocol-based real-time multimedia streaming architecture
US6289223B1 (en) * 1998-07-22 2001-09-11 Ericsson Inc System and method for selective multipoint transmission of short message service messages
JP2000181836A (ja) 1998-12-11 2000-06-30 Nippon Telegr & Teleph Corp <Ntt> 情報配信方法及び情報配信プログラムを記録した記録媒体
US6611872B1 (en) * 1999-01-11 2003-08-26 Fastforward Networks, Inc. Performing multicast communication in computer networks by using overlay routing
JP2001177566A (ja) 1999-12-15 2001-06-29 Nippon Telegr & Teleph Corp <Ntt> 分配選択型光スイッチングネットワーク、分配選択型光送受信ノード及びその通信制御方法
US6298058B1 (en) * 1999-12-17 2001-10-02 Motorola, Inc. Methods for implementing a talkgroup call with competing sources in a multicast IP network
US7117273B1 (en) * 2000-01-25 2006-10-03 Cisco Technology, Inc. Methods and apparatus for maintaining a map of node relationships for a network
US7298508B2 (en) * 2000-03-28 2007-11-20 Brother Kogyo Kabushiki Kaisha Device and method for using multicast to transmit print data to networked printers
JP3550349B2 (ja) 2000-03-29 2004-08-04 日本電信電話株式会社 統計的情報をフィードバックする一斉同報通信システム及び方法
FI112307B (fi) 2000-08-02 2003-11-14 Nokia Corp Viestintäpalvelu
FI110297B (fi) * 2000-08-21 2002-12-31 Mikko Kalervo Vaeaenaenen Lyhytäänisanomajärjestelmä, -menetelmä ja -päätelaite
US6973081B1 (en) * 2000-10-12 2005-12-06 Realnetworks, Inc. System and method for seamlessly joining multicast session
US6947434B2 (en) * 2000-11-16 2005-09-20 Telefonaktiebolaget Lm Ericsson (Publ) Subgroup multicasting in a communications network
ATE371319T1 (de) * 2000-11-27 2007-09-15 Siemens Ag Bandbreitenreservierung in datennetzwerken
US7133371B2 (en) * 2000-12-01 2006-11-07 Motorola, Inc. Methods for achieving reliable joins in a multicast IP network
KR100470345B1 (ko) * 2000-12-27 2005-02-21 엘지전자 주식회사 이동통신 망에서의 ｉｐ멀티캐스트/브로드캐스트 패킷 전송을 위한 링크접속제어 프로토콜 구현장치 및 방법
FI115744B (fi) * 2001-02-08 2005-06-30 Nokia Corp Kommunikaatiopalvelu
US7724744B2 (en) * 2001-04-30 2010-05-25 At&T Corp. Method and system for a unicast endpoint client to access a multicast internet protocol (IP) session
EP1255416B1 (de) * 2001-05-04 2011-04-06 Siemens Aktiengesellschaft Methode und Medium zum Speichern und Lesen von MMS (Multimedia messaging service) Daten
JP2002335281A (ja) 2001-05-07 2002-11-22 Ntt Docomo Inc マルチキャストパケット配信方法及びシステム、パケットのアドレス構造、並びに移動機
US20030031175A1 (en) * 2001-08-01 2003-02-13 Masato Hayashi Method of multicasting
US7184789B2 (en) 2001-10-03 2007-02-27 Qualcomm, Incorporated Method and apparatus for data packet transport in a wireless communication system using an internet protocol
ES2246048T3 (es) * 2002-05-06 2006-02-01 Telefonaktiebolaget Lm Ericsson (Publ) Servicio de mensajes multimedia multiusuario.
US7565443B2 (en) * 2002-12-13 2009-07-21 Sap Ag Common persistence layer

Also Published As

Publication number Publication date
EP1601133A1 (de) 2005-11-30
DE60301145D1 (de) 2005-09-01
ES2246048T3 (es) 2006-02-01
JP4373324B2 (ja) 2009-11-25
US20130173730A1 (en) 2013-07-04
AU2003239840A8 (en) 2003-11-17
US8401032B2 (en) 2013-03-19
AU2003239840A1 (en) 2003-11-17
EP1601133B1 (de) 2012-07-04
ATE300840T1 (de) 2005-08-15
US20050220064A1 (en) 2005-10-06
EP1502464A2 (de) 2005-02-02
EP1502464B1 (de) 2005-07-27
WO2003094534A2 (en) 2003-11-13
WO2003094534A3 (en) 2004-03-04
JP2005532714A (ja) 2005-10-27

Similar Documents

Publication Publication Date Title
DE60301145T2 (de) Mehrbenutzermultimedianachrichtendiensten
DE60126998T2 (de) Übertragung von multicast und broadcast multimedia diensten über eine funkschnittstelle
DE60312001T2 (de) Kurznachrichtenumsetzung zwischen verschiedenen formaten für drahtlose kommunikationssysteme
DE60110608T2 (de) Verfahren und vorrichtung für verbesserten kurznachrichtendienst
DE69830189T2 (de) Tarifierung von an mobiltelefone gerichteten kurznachrichten
DE60319206T2 (de) Verfahren und Vorrichtung zur Kontrolle des Zugriffs auf &#34;multimedia broadcast multicast service&#34; in einem Paketdatenkommunikationssystem
DE60311015T2 (de) System und verfahren zur datenzwischenspeicherung und wiederverteilung in einem drahtlosen kommunikationsnetzwerk
DE202005008603U1 (de) Melden von Endgerätfähigkeiten für die Unterstützung des Kurznachrichtendienstes
EP1283650A1 (de) Verfahren, Sende-/Empfangseinheit und Kommunikationssystem zur Übertragung von Daten von einem Versender an mehrere Empfänger
EP1230815A1 (de) Verfahren und system zur ausarbeitung und übermittlung von sms-meldungen in einem mobilfunknetz
DE19941164C2 (de) SMS-gestütztes Verfahren zur Online-/Offline-Erkennung von Benutzergruppen in Mobilfunknetzen
DE60316978T2 (de) Verfahren zum senden von multimedianachrichten zwischen unterschiedlichen multimedia-nachrichtendienstzentren
CN1859069A (zh) 改善多媒体广播/多播业务会话重传方法及其mich帧结构
EP1859599A1 (de) Daten-gruppenrufdienst
DE60133419T2 (de) Verfahren zur übertragung und zum empfang von dienstdaten, netzwerkelemente und kommunikationsnetzwerk und -system
DE60301198T2 (de) Einfügen eines hash-codierten Dienstbezeichners in eine Funkrufnachricht für einen Dienst-Gruppenruf
EP1563652A1 (de) Zugriffsbenachrichtigung eines absenders einer elektronischen nachricht
DE102017103462A1 (de) Verfahren und Vorrichtung zum Streamen mit geringer Latenz an Gruppenadressen
EP1647153A1 (de) Übertragen eines nutzdatenobjektes von einer vermittlungskomponente auf eine mobile station
DE102005044857A1 (de) Verfahren und Anordnung zum Betreiben eines Gruppendienstes in einem Kommunikationsnetz
WO2003085999A1 (de) Verfahren zur übertragung von daten, insbesondere mit multimedialen inhalten, in einem mobilfunknetz
DE10160077B4 (de) Mobiles Datenübertragungssystem
EP1832132B1 (de) System und verfahren zur vermittlung von daten zwischen einem datenanbieter und einem mobilfunkendgerät
DE60315503T2 (de) Vorrichtung und verfahren für telekommunikationsdienste
DE10248088A1 (de) Benachrichtigung eines Absenders einer elektronischen Nachricht über den Zugriff auf diese durch einen Empfänger

Legal Events

Date Code Title Description
8364 No opposition during term of opposition