MRB erlaubt effektives Spitzenlast-Management beim Carrier

So funktioniert der Media Resource Broker (MRB)

| Autor / Redakteur: Dirk Srocke / Andreas Donner

Technische Finessen der Media Resource Broker erklären Whitepaper von NS-Technologies sowie das hier auszugsweise abgebildete Internet Draft der MediaCtrl Work Group innerhalb der IETF.
Technische Finessen der Media Resource Broker erklären Whitepaper von NS-Technologies sowie das hier auszugsweise abgebildete Internet Draft der MediaCtrl Work Group innerhalb der IETF. (Bild: IETF)

Als Bestandteil des IP Multimedia Subsystems (IMS) könnten Media Resource Broker künftig dazu beitragen, dass Carrier ihre VoIP-Netze effizienter und flexibler nutzen.

In ihren Netzen können Service Providern die verschiedensten Anwendungen anbieten: Von Callcenter über Telvoting und Voicemail bis zu Konferenzsystemen. Bislang mussten für all diese Dienste jeweils einzelne, dedizierte Media Server eingerichtet werden. Das bedeutet: Um Spitzenlasten abzudecken, müssen für jede Anwendung gesonderte Media Server vorgehalten werden – obwohl die meist gar nicht verwendet werden.

Sinnvoller wäre es, diese Ressourcen effizienter zu nutzen, bestehende Silos aufzubrechen und Media Server für verschiedene Anwendungen einzusetzen. Denn nicht alle Services werden zu jeder Tageszeit gebraucht. Beispiel: Während Telekonferenzen hauptsächlich zu Bürozeiten abgehalten werden, werden Televoting-Aktionen meist zur abendlichen Primetime durchgeführt. Mit Media Resource Brokern (MRB) soll es nun also gelingen, die unterschiedlichen Dienste auf identischer Hardware abzubilden.

Im aktuellen Internet-Draft Media Resource Brokering definiert die Media Control Work Group der Internet Engineering Task Force (IETF) den MRB als logische Instanz, die Informationen über verfügbare Media-Ressourcen einsammelt und entsprechend an die jeweiligen Client-Applikationen verteilt.

Dieses Konzept beschrieb Telekommunikationsanbieter AT&T bereits vor zwei Jahren im Dokument "AT&T''s Common Architecture for Real-Time Services (CARTS)". Demnach seien MRBs eine notwendige Komponente für große Service Provider, die zahlreiche Multimedia-Services an Millionen von Nutzern ausliefern wollen. Zudem müssten MRBs Funktionen für Load Distribution und Site Management bieten.

TK-Anbieter führen MRB-Technologien ein

Im Jahr 2010 kam AT&T allerdings auch zum Schluss, dass es noch keine adäquaten Lösungen auf dem Markt gebe, die all diesen Ansprüchen genügen. Das hat sich in den vergangenen Jahren offenbar geändert. Nachfragen zum Thema beantworten TK-Dienstleister zwar recht zurückhaltend – zum einen sind kompetente Ansprechpartner schwer greifbar, zum anderen bringen die Unternehmen "Wettbewerbsgründe" gegen eine Veröffentlichung von Netzinterna vor. Von Telefónica erfuhren wir aber immerhin, dass MRB-Technologien gruppenweit eingeführt würden. Auch AT&T beschäftigt das Thema wohl noch immer; so taucht der Name des Unternehmens im zuvor genannten IETF-Papier auf.

Nicht zuletzt tut sich derzeit Einiges auf Herstellerseite. So präsentierte kürzlich der britische Anbieter NS-Technologies die auf Cloud-Prinzipien beruhende Version 1.0 des eigenen MRB. Den preist das Unternehmen vollmundig als hochverfügbare und skalierbare Virtualisation Engine an, die das Media Resource Management zentralisiert und konsolidiert. Die mit marktführenden Media Servern kombinierbare Lösung biete einen ausgefeilten Algorithmus zur Auswahl passender Media Server. Zudem verspricht der Hersteller Standard-basierende Funktionen für Verwaltung und Reporting – so nutze man von der IETF definierte Protokolle, die auch Teil der vom 3GPP (3rd Gerneration Partnership Project) definierten Referenzarchitektur (IP Multimedia Subsystem, IMS) ist.

Dienste ohne zusätzliche Überprovisionierung testen

Laut Anbieter reduziere der MRB die Komplexität in Netzen und senke Investitions- und Betriebskosten. Beispielsweise lassen sich neue Services probeweise einführen und bei Erfolg flexibel skalieren. Analog führen erfolglose Dienste nicht gleich zu hohen Abschreibungen aufgrund vorauseilender Überprovisionierung, da Media Server eben nicht auf eine bestimmte Applikation festgelegt sind. Der von NS-Technologies angebotene MRB unterstütze überdies bestehende Infrastrukturen und lasse sich nahtlos in Legacy-Netze einbinden.

Genauere technische Details erläutert der Hersteller in verschiedenen Whitepapers auf der eigenen Webseite. Dort ist etwa zu lesen, dass sich ein MRB prinzipiell auf zwei verschiedene Arten implementieren lassen. Zu betrachten sind dabei In-line MRB und Query MRB. Beide Architekturen unterscheiden sich dabei lediglich hinsichtlich der genutzten Signalwege; die Algorithmen des MRB liefern in beiden Fällen identische Ergebnisse und ordnen Media Server entsprechend zu.

Legacy-tauglicher IUMM-Modus bei In-line MRB

Ein Inline MRB sitzt im Signalpfad zwischen Media Resource Client und Media Servern. Requests werden dabei per Session Initiation Protocol (SIP) übertragen, der MRB agiert in einer interaktiven Rolle. Zu unterscheiden sind hierbei wiederum zwei Rollen. Der In-line Unaware MRB Mode (IUMM) funktioniert auch mit Clients, die nicht der MRB-Spezifikation entsprechen. Demnach eignet sich diese Betriebsart, um vorhandene Systeme ohne Codeänderungen weiterzunutzen.

Der In-Line Aware MRB Mode (IAMM) erlaubt dagegen SIP-Anfragen mit zusätzlichen Kontextinformationen und bietet damit einen größeren Funktionsumfang. Dafür funktioniert der IAMM allerdings nicht mit Legacy-Anwendungen und setzt Clients voraus, die ihre SIP-Anfragen entsprechend der MRB-Spezifikation formulieren.

Query MRB für Media Server ohne SIP

Im Query MRB sitzt der MRB dagegen nicht im Signalpfad. Stattdessen handelt es sich hierbei um eine Request/Response-Lösung, bei der Media Resource Clients zunächst mit dem MRB kommunizieren. Der anschließende Informationsaustausch mit Media Servern folgt in der Regel wie gehabt per SIP. Ausnahmen sind möglich, wenn beispielsweise nicht SIP-kompatible Media Server ins Netzwerk eingebunden werden sollen.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 36769530 / Standards & Netze)