DE602005005087T2 - System und verfahren zur verbesserung der audioqualität für auf ip basierende systeme unter verwendung eines amr-nutzinformationsformats - Google Patents

System und verfahren zur verbesserung der audioqualität für auf ip basierende systeme unter verwendung eines amr-nutzinformationsformats Download PDF

Info

Publication number
DE602005005087T2
DE602005005087T2 DE602005005087T DE602005005087T DE602005005087T2 DE 602005005087 T2 DE602005005087 T2 DE 602005005087T2 DE 602005005087 T DE602005005087 T DE 602005005087T DE 602005005087 T DE602005005087 T DE 602005005087T DE 602005005087 T2 DE602005005087 T2 DE 602005005087T2
Authority
DE
Germany
Prior art keywords
amr
frame
frames
rtp packet
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE602005005087T
Other languages
English (en)
Other versions
DE602005005087D1 (de
Inventor
Gary R. Cary COLE
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.)
Sony Mobile Communications AB
Original Assignee
Sony Ericsson Mobile Communications 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 Sony Ericsson Mobile Communications AB filed Critical Sony Ericsson Mobile Communications AB
Publication of DE602005005087D1 publication Critical patent/DE602005005087D1/de
Application granted granted Critical
Publication of DE602005005087T2 publication Critical patent/DE602005005087T2/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/38—Flow control; Congestion control by adapting coding or compression rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H04W28/14—Flow control between communication endpoints using intermediate storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

  • Hintergrund
  • Internet-Telefonie (VoIP) hat innerhalb von Personal-Computer- und Trägergemeinschaften stetig an Popularität gewonnen. Mit dem Fortschritt der Technologie wird das Laufenlassen ähnlicher Dienste in zellulären Einrichtungen lebensfähig. Eine technische Schlüsselfrage besteht darin, wie die Dienste anzupassen sind, so dass sie mit reduzierter Bandbreite und signifikant weniger Verarbeitungsleistung, verglichen mit einem Desktop-PC, auskommen. Gesprächsübergabe über zellulären Betrieb (PoC) definiert ein Halb-Duplex-VoIP-System für mobile Einrichtungen. Durch Benutzung der paketgeschalteten Fähigkeiten drahtloser Netzwerke ist der Dienst nicht geographisch beschränkt – im Gegensatz zu herkömmlichen Zwei-Weg-Funksystemen-, wie z.B. privatem Mobilfunk (PMR).
  • Um PoC zum Erfolg zu bringen, sollte die Leistungsfähigkeit des Handapparats und des Netzwerkes optimal sein. Eine Leistungsfähigkeit, welche Verzögerungen mit sich bringt, könnte für den Dienst den Unterschied zwischen Erfolg und Fehlschlagen bedeuten.
  • Die Audio-Qualität von PoC ist durch die verfügbare GPRS/EGPRS-Bandbreite auf dem zellulären System begrenzt. Die Audio-Daten werden über ein PoC-System gesendet, wobei adaptives Multi-Rate-(AMR-)Codieren, welches in dem Echtzeitübertragungsprotokoll (RTP) oben auf einem Benutzer-Datagrammprotokoll-(UDP-)unbestätigtem Transportprotokoll paketiert ist, gesendet. Als Ergebnis werden verlorene Pakete niemals zurückgesendet.
  • PTT ist eine Echtzeitanwendung, wo das Puffern von Audiodaten auf einem Minimum gehalten wird, um die Latenzzeit vom Beginnen eines Gesprächs-Bursts bis zum Beginnen des Rückspielens zu reduzieren. Jedes RTP-Paket ist zeitgestempelt, um dem System zu gestatten, verzögerte Pakete außer Acht zu lassen, welches umgekehrt verhindert, dass der Gesprächs-Burst unbegrenzt anwächst.
  • Aktuell wurden Techniken entwickelt, um das Strömen von AMR RTP-Paketen auf der Abwärtsstrecke durch Puffern zu verbessern, um den Jitter und das Paketrückeinordnen zu reduzieren, um Pakete zu korrigieren, welche nicht in der Reihenfolge empfangen wurden. Jedoch wurde gezeigt, dass eine begrenzte Bandbreite auf der Aufwärtsstrecke (Sendeseite) verlorene Pakete verursacht, welche nicht auf der Abwärtsstrecke korrigiert werden können. Diese Bandbreitenbegrenzung kann durch Überlastung oder durch Systeme mit minimalen Datenressourcen ausgelöst sein. Aktuell besteht der einzige Mechanismus, die Bandbreite in der Aufwärtsstrecke zu reduzieren, darin, die AMR-Codierraten zu ändern. Diese Vorgehensweise allein liefert nicht genug Reduktion in der Bandbreite, um verlorene Pakete aufgrund minimaler Bandbreite auf der GPRS-Verbindung zu verhindern. Probleme aufgrund von begrenzter Bandbreite wurden beobachtet, wobei die niedrigste 4,75-kb-AMR-Codierrate benutzt wurde.
  • ZIZHI QIAO ET AL: "A new method for VoIP quality of service control use combined adaptive sender rate and priority marking" veröffentlicht ein Verfahren zum Erhöhen der wahrgenommenen Sprachqualität für VoIP-Anwendungen, wobei ein AMR-Codec benutzt wird.
  • Was benötigt wird, ist ein System und/oder ein Verfahren, um weiter die Bandbreite in der Aufwärtsstrecke in einem PoC oder in einer anderen interaktiven Dienst-IP-basierten Anwendung zu bewahren, wobei ein AMR-Nutzlastformat benutzt wird.
  • Zusammenfassung
  • Ein Verfahren und ein System zum Verstärken der Audioqualität für Internet-Protokoll-(IP-)basierte Systeme, wobei ein adaptives Multi-Rate-(AMR-)Nutzlastformat verwendet wird, wird in den unabhängigen Ansprüchen 1 und 5 vorgestellt. Das Verfahren liefert einen zusätzlichen Grad an Intelligenz zu den Standard-RTP AMR-Rahmen-Paketierprozeduren. Wenn ein Netzwerkpuffer, indikativ für Netzwerküberfüllung, seinen Schwellwert überschreitet, wird eine Bestimmung durchgeführt, ob ein NO DATA- bzw. KEINE DATEN-Rahmen in das aktuelle RTP-Paket statt des AMR-Rahmens zu platzieren ist. Wenn die Netzwerkzustände zu überfüllt sind, dann wird ein NO DATA-Rahmen in dem aktuellen RTP-Paket platziert. Der Vorgang wird für jeden eingehenden AMR-Rahmen wiederholt. Der Vorgang sichert zuerst, dass die AMR-Codierrate auf ihre niedrigstmögliche Codierrate eingestellt wird, bevor ein AMR-Rahmen mit einem NO DATA-Rahmen ersetzt wird. Das Ersatzfeld wird über das gesamte RTP-Paket gespreizt, um Cluster von NO DATA-Rahmen zu vermeiden. Der Prozess bzw. Vorgang kann auch AMR-Rahmen niedrigerer Energiewerte heraussuchen, welche gute Kandidaten für das Ersetzen sind.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist ein Diagramm, welches den typischen Datenfluss auf der Aufwärtsstreckenseite darstellt, welcher bei Standard-PoC-Operationen benutzt wird.
  • 2 ist ein Flussdiagramm, welches den logischen Ablauf für das Implementieren der Konzepte der vorliegenden Erfindung darstellt.
  • 3 ist ein Ablaufdiagramm, welches ferner das Dezimierverfahren der vorliegenden Erfindung darstellt.
  • 4 stellt Muster-RTP-Pakete an der Quelle ohne AMR-Rahmen-Substitution dar.
  • 5 stellt Muster-RTP-Pakete an der Quelle mit bestimmten AMR-Rahmen dar, welche durch NO DATA-Rahmen ersetzt sind.
  • 6 vergleicht die RTP-Pakete nicht substituierter AMR-Rahmen mit substituierten AMR-Rahmen am Ziel.
  • Detaillierte Beschreibung
  • Die hier beschriebenen Techniken sind für jegliche herkömmliche Dienst-IP-basierte Anwendung anwendbar, welche ein AMR-Nutzlastformat oder ein Protokoll nutzt, welches AMR-Rahmen bündelt. Außerdem kann die vorliegende Erfindung in einem mobilen Endgerät oder an dem Anwendungsserver implementiert werden, um die Bandbreite während Perioden der Überfüllung zu bewahren. Die vorliegende Erfindung nutzt Push to talk over Cellular bzw. Gesprächsübergabe über zelluläre Einrichtung (PoC) als eine beispielhafte Ausführungsform, um eine Basis für das Beschreiben der Konzepte der Erfindung zu liefern. Zusätzlich beschäftigt sich die vorliegende Erfindung mit der Bandbreitenerhaltung für die Übertragungs- oder Sendeseite interaktiver Dienst-IP-basierter Anwendungen im Gegensatz zur Empfängerseite.
  • Die vorliegende Erfindung schlägt ferner das Reduzieren der Bandbreite in der Aufwärtsstrecke durch Ersetzen guter Datenrahmen in den RTP-Paketen mit NO DATA-Rahmen vor. Diese Vorgehensweise bietet ein Mittel, die Audio-Qualität teilweise aus fallen zu lassen, indem die Anzahl verlorener AMR RTP-Pakete reduziert wird.
  • Die vorliegende Erfindung nutzt die Rückkopplung von dem GPRS-Modul in dem mobilen Telefon, um die übertragenen RTP-Paketgrößen während der GPRS-Überfüllung zu reduzieren.
  • RTP-Pakete werden bei einer festen Rate von dem Audio-Untersystem in dem mobilen Endgerät während eines PTT-Gesprächs-Bursts erzeugt. Wenn diese Rate die Rate übersteigt, in welcher die Pakete über das GPRS-Netzwerk übertragen werden können, würden die Pakete gepuffert. Ungeprüft würde der Puffer ungebunden wachsen, was schließlich zu verlorenen Paketen führt. Die Pufferdaten haben auch die Wirkung, die Übertragung zu verzögern. Da ein Zeitstempel in dem RTP-Paket platziert wird, kann jeglicher beträchtlicher Verlust dazu führen, dass das Paket auf der Empfangsseite außer Acht gelassen wird, um das Strecken des Gesprächsbursts zu verhindern. Die vorliegende Erfindung reduziert die Größe der gepufferten Pakete durch das Ersetzen eines Prozentsatzes guter AMR-Rahmen mit NO DATA-Rahmen. Diese Technik würde angewendet werden, nachdem das System die AMR-Codierrate bis herunter bis zur minimalen 4,75-kb-Rate aufgegeben hat. Diese Technik komprimiert die gepufferten Pakete und bewahrt die Integrität der Sprachdaten durch Herauswerfen einiger der Daten, jedoch nicht des gesamten Paketes.
  • 1 ist ein Diagramm, welches den typischen Datenfluss auf der Aufwärtsstreckenseite darstellt, wie er in Standard-PoC-Operationen benutzt wird. Wie oben erwähnt, kann die Erfindung in dem mobilen Endgerät oder in einem PoC-Server praktiziert werden. Demnach kann die Referenznummer 100 in 1 entweder ein mobiles Endgerät oder einen PoC-Server repräsentieren. Im Rest der Beschreibung wird eine Nomenklatur des PoC-Servers mit 100 angewendet, um die Beschreibung zu vereinfachen.
  • Die Sprachdaten starten als analoge Eingabe zu einem Mikrofon 110. Ein digitaler Signalprozessor (DSP) 120 wandelt die analogen Sprachdaten in digitalisierte AMR-Rahmen bei einer Rate von einem Rahmen pro 20 Millisekunden. Der AMR-Rahmen wird dann zu einem Push-to-Talk- bzw. Gesprächsübergabe-(PTT-)Client 130 geroutet. Der PTT-Client 130 bündelt irgendwo von 1 bis 20 AMR-Rahmen in einem einzelnen RTP-AMR-Nutzlastpaket. Das RTP-Paket, welches die AMr-Rahmen-Nutzlast enthält, wird dann zu dem IP-Stapel 150 geroutet. An diesem Punkt fängt der GPRS/EGPRS-Stapel IP-Pakete von dem IP-Stapel 150, wenn die Bandbreite verfügbar wird. Wenn die Bandbreite verfügbar ist, dann wird das IP-Paket über das GPRS/EGPRS-Netzwerk 160 über die Antenne 170 gesendet. Falls die Bandbreite nicht verfügbar ist, dann wird das IP-Paket in dem GPRS-Netzwerkmodul 160 gepuffert. Falls der Puffer zu groß wird, werden Pakete verloren.
  • 2 ist ein Ablaufdiagramm, welches den logischen Fluss für das Implementieren der Konzepte der vorliegenden Erfindung darstellt. Ein AMR-formatiertes RTP-Paket enthält 1 bis 20 AMR-Rahmen. Das mobile Endgerät sammelt AMR-Rahmen 205 von dem Audio-CODEC. Unter normalen Bedingungen würden die AMR-Rahmen in ein RTP-Paket paketiert, basierend auf einem sitzungsverhandelten Parameter, und gesendet. In der vorliegenden Erfindung würde ein Paketieralgorithmus bestimmen, ob irgendwelche Rahmen mit NO DATA-Rahmen substituiert werden sollten. Der erste Schritt besteht darin, zu prüfen, ob der GPRS-Pufferschwellwert erreicht wurde, 210. Falls der GPRS-Puffer noch Raum hat, dann wird der AMR-Rahmen in ein RTP-Paket gelegt, 215. Das RTP-Paket wird geprüft, um zu sehen, ob es voll ist, 220. Falls es voll ist, wird das RTP-Paket gesendet, 225.
  • Falls es noch nicht voll ist, schiebt es die Steuerung zurück, um einen anderen AMR-Rahmen zu bekommen, 205.
  • Falls der GPRS-Pufferschwellwert erreicht wird oder übertroffen wird, dann wird eine Prüfung durchgeführt wird, ob die AMR-Codec-Rate auf ihre niedrigstmögliche Rate eingestellt ist, 230. Falls dies nicht der Fall ist, wird sie auf die niedrigste AMR-Codec-Rate (4,75 kbps) zurückgestellt, 235, und der Pufferschwellwert wird wieder geprüft, 210. Wenn jedoch der GPRS-Puffer voll ist und die AMR-Codec-Rate so niedrig ist, wie sie erreicht werden kann, dann wird eine Entscheidung getroffen, ob der aktuelle AMR-Rahmen zu dezimieren ist, 240. Wenn der Algorithmus entscheidet, den AMR-Rahmen nicht zu dezimieren, wird er in das RTP-Paket, so wie er ist, gelegt, 215. Falls der aktuelle AMR-Rahmen zu dezimieren ist, dann wird ein NO DATA-Rahmen statt des guten AMR-Rahmens in dem RTP-Paket substituiert, 245, was zu einer Datenkompression führt, welches die Belastung auf der Bandbreite erleichtert. Das RTP-Paket wird geprüft, um zu sehen, ob es voll ist, 220, und falls dem so ist, wird das RTP-Paket gesendet 225. Anderenfalls wird ein anderer AMR-Rahmen erhalten, 205, und der Prozess wird wiederholt.
  • Der Algorithmus überwacht das GPRS-(Netzwerk-)Modul, um zu bestimmen, ob IP-Pakete über die RF-Verbindung bei einer Rate gesendet werden, bei welcher sie geschaffen wurden. Das GPRS-Modul beinhaltet einen Puffer, um Daten vor der Übertragung zu speichern. Die Gestaltung des Puffers wird einen Mechanismus liefern, um das PTT-Modul in Kenntnis zu setzen, wenn der Puffer startet, sich zu füllen. Unter normalen Umständen sollte sich der Puffer nicht füllen, aber bei Überlastungszuständen wird sich der Puffer füllen. Das PTT-Modul wird das In-Kenntnis-Setzen nutzen, um zu steuern, wie es AMR-Rahmen in RTP-Pakete packt. Der Mechanismus des In-Kenntnis-Setzens von dem GPRS-Modul wird den Pufferstatus an das PTT-Modul liefern, so dass das PTT-Modul die Paketsubstitution erhöhen oder niedriger machen kann, basierend auf der Netzwerküberlastung. Unter normalen Bedingungen würde keine Rahmensubstitution auftreten. In Situationen des schlimmsten Falles würde das gesamte Paket mit NO DATA-Rahmen gefüllt werden.
  • Jede Rahmensubstitution wird bei einem Minimum eine 12-zu-1-Reduktion in der Rahmengröße liefern, da NO DATA-Rahmen keine AMR-Daten enthalten. Der Paketieralgorithmus wird bestrebt sein, um das Ersetzen von guten AMR-Rahmen mit NO DATA-Rahmen zu verbreiten, um Cluster von NO DATA-Rahmen zu vermeiden, dass diese die Effekte auf die Sprache reduzieren.
  • 3 ist ein Ablaufdiagramm, welches außerdem eine Implementierung der Dezimierungsverarbeitung der vorliegenden Erfindung darstellt. Eine Verstärkung des Algorithmus würde Rahmen mit minimaler Audio-Energie für das Ersetzen identifizieren, um weiter die Effekte auf die Sprache zu reduzieren. In dem Dezimierungsbestimmungsprozess würde der AMR-Rahmen-Energiepegel bestimmt werden, 310. Wenn dieser unterhalb eines Schwellwertpegels ist, 320, ist er ein guter Kandidat für die Substitution durch einen NO DATA-Rahmen. Falls der Energiepegel größer als der Schwellwert ist, 320, kann eine zweite Entscheidung, den AMR-Rahmen zu ersetzen, basierend auf anderen Faktoren durchgeführt werden, 330. Die Idee besteht darin, zuerst alle AMR-Rahmen mit niedriger Energie zu dezimieren.
  • 4 stellt Muster-RTP-Pakete an der Quelle ohne AMR-Rahmensubstitution dar. Diese Beispiele zeigen drei RTP-Pakete, wobei jedes zehn (10) AMR-Rahmen und einen Paket-Nachrichtenkopf für insgesamt dreißig (30) Datenrahmen enthält.
  • 5 stellt Muster-RTP-Pakete an der Quelle dar, wobei bestimmte AMR-Rahmen aufgrund von aktuellen Netzwerküberlastungszuständen entfernt sind. Verglichen mit 4 enthält jedes RTP-Paket sieben AMR-Rahmen, anstatt von zehn. Zusätzlich wurden die fehlenden oder substituierten AMR-Rahmen über die Verteilung in einem Versuch gespreizt, um Cluster von fehlenden Rahmen zu vermeiden.
  • 6 vergleicht die RTP-Pakete der nicht substituierten AMR-Rahmen mit substituierten AMR-Rahmen am Ziel. Die Spalte auf der linken Seite stellt die empfangenen RTP-Pakete von AMR-Rahmen ohne Rahmensubstitution dar, welche an der Quelle durchgeführt wurde. In diesem Beispiel sind die Quellen-RTP-Pakete diejenigen, welche in 4 gezeigt werden. Jedoch war das Netzwerk überfüllt, und der IP-Stapel war übergepuffert, was zu einem Verlust von einem der RTP-Pakete am Ziel führt. Dies wird als NO DATA-Rahmen gezeigt, wo AMR-Rahmen 11-20 gewesen sein sollten. Der Verlust eines gesamten RTP-Pakets hat einen bemerkbaren und im Wesentlichen unerwünschten Effekt auf die Audio-Qualität.
  • Die rechte Spalte der 6 stellt die empfangenen RTP-Pakete von AMR-Rahmen mit Rahmensubstitution dar, welche an der Quelle durchgeführt wurde. In diesem Beispiel sind die Quellen-RTP-Pakete diejenigen, welche in 5 gezeigt werden. Da das Netzwerk überfüllt war, hat die Quelle mehrere AMR-Rahmen mit NO DATA-Rahmen ersetzt. Die Substitution wurde über die RTP-Pakete in einer verhältnismäßig gleichmäßigen Verteilung ausgebreitet. Demnach wurde, während virtuell die gleiche Anzahl von AMR-Rahmen verloren wurde, kein gesamtes RTP-Paket verloren. Jedes RTP-Paket leidet etwas unter dem Verlust einer Anzahl von Rahmen, aber insgesamt nahm die Audio-Qualität nicht steil oder plötzlich ab, und eine Konversation kann verhältnismäßig normal weiterlaufen.
  • Es sollte beachtet werden, dass ein Computer-Programmcode in der Form verschiedener Computerprogramm-Instruktionen benutzt werden kann, um wenigstens Teile der Vorgänge zu implementieren, welche beim Ausführen der Ausführungsformen der Erfindung involviert sind. Ein derartiger Computer-Programmcode kann über ein Computerprogramm-Produkt geliefert werden, welches alle oder einen Teil der Computerprogramm-Instruktionen enthält, welche auf einem Medium gespeichert sind. Das Medium kann fest oder entfernbar sein. Ein derartiges Medium könnte ein festes Speichermedium sein, aber es könnte gerade auch ebenso leicht eine entfernbare optische oder magnetische Disk oder ein Band sein. Die Computerprogramm-Instruktionen können auf jedem Medium ruhen, das einen Computer-Programmcode enthalten, speichern, kommunizieren, laufen lassen oder transportieren kann, um über eine Art einer Computer-Plattform, eines Instruktionsausführungssystems oder einer Sammlung derartiger Systeme, welche über einen Bus oder ein Netzwerk angeschlossen sind, ausgeführt zu werden. Ein derartiges, von einem Computer lesbares Medium kann beispielsweise, es ist jedoch nicht darauf begrenzt, ein elektronisches, magnetisches, optisches, elektromagnetisches, infrarotes oder Halbleitersystem oder eine derartige Einrichtung sein.
  • Computerprogramm-Instruktionen, welche alle oder einen Teil der Erfindung implementieren, können auch in einem Informationsstrom enthalten sein, welcher über ein Netzwerk, wie z.B. das Internet, wiedergewonnen werden kann. Man beachte, dass das vom Computer nutzbare oder vom Computer lesbare Medium auch Papier oder ein anderes geeignetes Medium sein kann, auf welchem ein Computer-Programmcode gedruckt ist, da der Code elektronisch beispielsweise über ein optisches Abtasten, dann Kompilieren und Interpretieren oder in einer anderen geeigneten Weise verarbeitet werden kann.
  • Spezielle Ausführungsformen einer Erfindung werden hier veröffentlicht. Ein Fachmann wird schließlich erkennen, dass die Erfindung andere Anwendungen in anderen Umgebungen besitzen kann. Tatsächlich sind viele Ausführungsformen und Implementierungen möglich. Die folgenden Ansprüche sollen in keiner Weise den Umfang der vorliegenden Erfindung auf spezielle Ausführungsformen begrenzen, welche oben beschrieben sind. Zusätzlich soll jedes Rezitieren von "Einrichtung für" eine zusätzliche Einrichtungsfunktion eines Elementes und eines Anspruchs bedeuten, wohingegen jegliche Elemente, welche nicht speziell das Rezitieren von "Einrichtung für" benutzen, nicht Elemente für eine zusätzliche Einrichtungsfunktion bedeuten, selbst wenn der Anspruch in anderer Weise das Wort "Einrichtung" beinhaltet.

Claims (8)

  1. Verfahren zum Verbessern der Audioqualität für auf Internet-Protokoll-, IP-basierte Systeme unter Verwendung eines adaptiven Multi-Rate-, AMR-Nutzinformationsformates, welches aufweist: Erhalten eines AMR-Rahmens (205); Bestimmen, ob ein Puffer von Echtzeittransport-Protokoll-, RTP-Paketen eine Schwellwertkapazität als ein Ergebnis überfüllter Netzwerkzustände erreicht hat (210); Platzieren des AMR-Rahmens in ein RTP-Paket, falls der Puffer bisher noch nicht seine Kapazität erreicht hat (215), anderenfalls Bestimmen, wann ein NO-DATA- bzw. Keine-Daten-Rahmen in dem aktuellen RTP-Paket basierend auf den aktuellen Netzwerk-Überfüllungszuständen zu platzieren ist (240); und Platzieren eines NO-DATA-Rahmens in dem aktuellen RTP-Paket, wenn die Netzwerkzustände eine zu große Überfüllung anzeigen (245).
  2. Verfahren nach Anspruch 1, welches ferner aufweist: Bestimmen, ob die AMR-Codierrate auf ihre niedrigstmögliche Einstellung (230) eingestellt ist, bevor der AMR-Rahmen in dem aktuellen RTP-Paket durch einen NO-DATA-Rahmen ersetzt wird (245), und ob nicht; Zurücksetzen der AMR-Codierrate auf ihre niedrigstmögliche Einstellung (235).
  3. Verfahren nach Anspruch 2, welches ferner aufweist: Verteilen der ersetzten NO-DATA-Rahmen über das RTP-Paket, um Cluster von NO-DATA-Rahmen zu vermeiden.
  4. Verfahren nach Anspruch 3, welches ferner aufweist: Identifizieren von AMR-Rahmen, welche unter einen spezifizierten Energiepegel fallen (320); Ersetzen der AMR-Rahmen (245), welche unterhalb des spezifizierten Energiepegels liegen, vor den AMR-Rahmen, welche einen größeren als den Schwellwert des Energiepegels besitzen, sollte eine AMR-Rahmensubstitution notwendig werden.
  5. System zum Verbessern der Audioqualität für auf Internet-Protokoll-, IP-basierte Systeme unter Verwendung eines adaptiven Vielfach-Rate-, AMR-Nutzinformationsformats, welches aufweist: eine Einrichtung zum Erhalten eines AMR-Rahmens (205); eine Einrichtung zum Bestimmen, ob ein Puffer von Echtzeittransportprotokoll-, RTP-Paketen eine Schwellwertkapazität als ein Ergebnis überfüllter Netzwerkzustände erreicht hat (210); eine Einrichtung zum Platzieren des AMR-Rahmens in ein RTP-Paket, falls der Puffer noch nicht seine Kapazität erreicht hat (215); eine Einrichtung zum Bestimmen, wenn ein NO-DATA-Rahmen in dem aktuellen RTP-Paket basierend auf aktuellen Netzwerküberfüllungszuständen zu platzieren ist (240), und eine Einrichtung zum Platzieren eines NO-DATA-Rahmens in das aktuelle RTP-Paket, wenn Netzwerkzustände eine zu große Überfüllung anzeigen (245).
  6. System nach Anspruch 5, welches ferner aufweist: eine Einrichtung zum Bestimmen, ob die AMR-Codierrate vor dem Ersetzen des AMR-Rahmens durch einen NO-DATA-Rahmen (245) in dem aktuellen RTP-Paket auf ihre niedrigstmögliche Einstellung eingestellt ist (230), und ob nicht; eine Einrichtung zum Zurücksetzen der AMR-Codierrate auf ihre niedrigstmögliche Einstellung (235).
  7. System nach Anspruch 6, welches ferner aufweist: eine Einrichtung zum Verteilen der ersetzten NO-DATA-Rahmen über das RTP-Paket, um Cluster von NO-DATA-Rahmen zu vermeiden.
  8. System nach Anspruch 7, welches ferner aufweist: eine Einrichtung zum Identifizieren von AMR-Rahmen, welche unterhalb eines spezifizierten Energiepegels fallen (230); eine Einrichtung zum Ersetzen der AMR-Rahmen (245) unterhalb des spezifizierten Energiepegels, vor den AMR-Rahmen, welche einen größeren als den Schwellwert des Energiepegels besitzen, sollte eine AMR-Rahmensubstitution notwendig werden.
DE602005005087T 2004-12-21 2005-06-20 System und verfahren zur verbesserung der audioqualität für auf ip basierende systeme unter verwendung eines amr-nutzinformationsformats Active DE602005005087T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US905198 1997-08-01
US10/905,198 US7830920B2 (en) 2004-12-21 2004-12-21 System and method for enhancing audio quality for IP based systems using an AMR payload format
PCT/US2005/021896 WO2006068659A1 (en) 2004-12-21 2005-06-20 System and method for enhancing audio quality for ip based systems using an amr payload format

Publications (2)

Publication Number Publication Date
DE602005005087D1 DE602005005087D1 (de) 2008-04-10
DE602005005087T2 true DE602005005087T2 (de) 2008-06-12

Family

ID=34993208

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602005005087T Active DE602005005087T2 (de) 2004-12-21 2005-06-20 System und verfahren zur verbesserung der audioqualität für auf ip basierende systeme unter verwendung eines amr-nutzinformationsformats

Country Status (8)

Country Link
US (1) US7830920B2 (de)
EP (1) EP1829318B1 (de)
JP (1) JP4764429B2 (de)
CN (1) CN101065946B (de)
BR (1) BRPI0518326A2 (de)
DE (1) DE602005005087T2 (de)
MX (1) MX2007007113A (de)
WO (1) WO2006068659A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0500483D0 (en) * 2005-01-11 2005-02-16 Nokia Corp Multi-party sessions in a communication system
US9485686B2 (en) * 2005-03-04 2016-11-01 Sonim Technologies, Inc. Restructuring data packets to improve voice quality at low bandwidth conditions in wireless networks
US8578046B2 (en) * 2005-10-20 2013-11-05 Qualcomm Incorporated System and method for adaptive media bundling for voice over internet protocol applications
US8300542B2 (en) * 2006-02-06 2012-10-30 Telefonaktiebolaget L M Ericsson (Publ) VoIP performance optimization for E-DCH power limitation
JP4779827B2 (ja) * 2006-06-29 2011-09-28 日本電気株式会社 ネットワーク制御システム、無線通信装置、及びネットワーク制御方法
EP2238794A4 (de) * 2008-02-05 2014-01-08 Ericsson Telefon Ab L M Übertragen von leitungsvermittelten daten über hspa
GB2495712B (en) * 2011-10-17 2014-01-08 Skype Controlling transmission of data
CN106375063B (zh) * 2016-08-30 2020-02-21 上海华为技术有限公司 一种数据传输方法及其设备

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0927808A (ja) 1995-07-11 1997-01-28 Hitachi Ltd セル組立分解装置
IL125571A0 (en) * 1997-08-01 1999-03-12 Comverse Network Syst Inc A packet-switched-network telephone system
WO1999035789A1 (en) * 1998-01-02 1999-07-15 Nokia Networks Oy. A method for adaptation of voice sample rate in a telecommunication system
JP3881157B2 (ja) * 2000-05-23 2007-02-14 株式会社エヌ・ティ・ティ・ドコモ 音声処理方法及び音声処理装置
SE0004839D0 (sv) * 2000-12-22 2000-12-22 Ericsson Telefon Ab L M Method and communication apparatus in a communication system
JP2002318599A (ja) 2001-04-23 2002-10-31 Mitsubishi Electric Corp 音声通信装置
JP2003152752A (ja) 2001-08-29 2003-05-23 Matsushita Electric Ind Co Ltd データ送受信方法
US7768978B2 (en) * 2001-11-08 2010-08-03 Mitsubishi Denki Kabushiki Kaisha Wireless communication method and mobile terminal used therefor
JP4029670B2 (ja) 2002-06-11 2008-01-09 日本電気株式会社 無線アクセスにおける輻輳制御方法並びにシステム
AU2003202593A1 (en) * 2003-01-28 2004-08-23 Telefonaktiebolaget Lm Ericsson (Publ) Method and device for congestion notification in packet networks indicating several different congestion causes
CN1555185B (zh) * 2003-12-25 2010-04-28 海信集团有限公司 Ip手机
US20050227657A1 (en) * 2004-04-07 2005-10-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for increasing perceived interactivity in communications systems
US7558286B2 (en) * 2004-10-22 2009-07-07 Sonim Technologies, Inc. Method of scheduling data and signaling packets for push-to-talk over cellular networks

Also Published As

Publication number Publication date
JP4764429B2 (ja) 2011-09-07
CN101065946B (zh) 2011-10-05
WO2006068659A1 (en) 2006-06-29
BRPI0518326A2 (pt) 2008-11-25
EP1829318B1 (de) 2008-02-27
US7830920B2 (en) 2010-11-09
CN101065946A (zh) 2007-10-31
MX2007007113A (es) 2007-07-11
JP2008524921A (ja) 2008-07-10
EP1829318A1 (de) 2007-09-05
DE602005005087D1 (de) 2008-04-10
US20060133276A1 (en) 2006-06-22

Similar Documents

Publication Publication Date Title
DE602005005087T2 (de) System und verfahren zur verbesserung der audioqualität für auf ip basierende systeme unter verwendung eines amr-nutzinformationsformats
DE112005002986B4 (de) Verfahren und Medienzugangscontroller für drahtlose Breitbandkommunikation mit variabler Größe der Dateneinheiten und verzögertem Aufbau von Dateneinheiten
DE60304938T2 (de) Kompression von Protokollnachrichten in einem Mobilfunksystem
DE69834763T2 (de) Verfahren zur Unterstützung von verbindungsindividuellen Warteschlangen für rückgekoppelte Verkehrssteuerung
DE60119080T2 (de) Verfahren und vorrichtung zur herstellung von kryptosynchronismus in einem auf gepackten daten basierenden kommunikationssystem
DE60014852T2 (de) Headerkompression in echtzeitdiensten
DE60027875T2 (de) Aktualisierung des Headerkompressionszustands in Paketübertragung
DE60313377T2 (de) Vorrichtung und verfahren zur steuerung der funktionsweise mehrerer kommunikationsschichten in einem geschichteten kommunikations-szenario
DE602004002195T2 (de) Verfahren und apparat für die ablauffolgesteuerung von paketen
DE60319360T2 (de) Inhaltsablieferungsarchitektur für mobilen zugriff
DE60023334T2 (de) Beschleunigungsabhängige kanalumschaltung in mobilen telekommunikationsnetzen
DE60114253T2 (de) Verfahren und System zur Anwendung von gewichteten Abfragelisten in einem drahtlosen lokalen Netzwerk
DE60102071T2 (de) Verfahren zum Multiplexen zweier Datenflüsse auf einen Funkkommunikationskanal und dazugehörender Sender
DE112016001513T5 (de) Frame-übertragungsplanmodifikation
DE112013001313B4 (de) Ermitteln und Übergehen zu einer verbesserten VOIP-Sitzung
DE112016002847T5 (de) Dienstgüte in einem drahtlosen Backhaul
DE102006004250A1 (de) Kommunikationseinrichtung, Verfahren zum Betreiben einer Kommunkationseinrichtung und Computerprogrammelement
DE60104005T2 (de) Übertragung von paketdaten
DE602004007413T2 (de) Optimierung von ressourcengebrauch in einem paketvermittelten netzwerk
DE60302168T2 (de) Datenratenkontroller
DE60109133T2 (de) Verfahren und vorrichtung zur auswahl der besten verbindung für zusätzliche kanalzuweisung während der übergabeperiode in einem spreizband-nachrichten-übertragungssystem
DE102014019581A1 (de) Anwendungsqualitätsverwaltung in einem kommunikationssystem
DE602005002819T2 (de) Verfahren zum Identifizieren von RTP- (Real Time Protocol) und RTCP- (Real Time Control Protocol) Paketen auf Basis einer Paketeigenschaft
DE60032571T2 (de) Verfahren und Gerät zur Übertragung von Echtzeitdaten in einem Mehrfachzugangssystem
DE112004002544B4 (de) Verfahren, System und Programm zur Identifizierung von Datenüberlauf

Legal Events

Date Code Title Description
8364 No opposition during term of opposition