Title:
Verfahren zur automatischen Clientkonfiguration von RCS-e
Document Type and Number:
Kind Code:
A1

Abstract:

Es ist Verfahren zur Automatischen Clientkonfiguration von RCS-e offenbart, bei welchem der RCS-e Applikationsserver außerhalb des Netzwerks, also des Kernnetzes bzw. international „Core Network“, des Mobilfunkanbieters angeordnet ist. Dies erhöht die Flexibilität bei der Implementierung neuer RCS-e Dienste und entlastet die kritische Kapazität des Kernnetzes des Mobilfunkanbieters. Dies gilt besonders dann, wenn alternativ oder zusätzlich auch der RCS-e Dienst außerhalb Kernnetzes des Mobilfunkanbieters durchgeführt wird, wodurch er ein OTT-Dienst wird, der dennoch auf die netzzentrische, automatische Konfiguration zugreifen kann oder der RCS-e Konfigurationsserver außerhalb des Kernnetzes des Mobilfunkanbieters betrieben wird.





Inventors:
Hellermann, Sascha (40721, Hilden, DE)
Huettig, Oliver (57290, Neunkirchen, DE)
Application Number:
DE102016109625A
Publication Date:
11/30/2017
Filing Date:
05/25/2016
Assignee:
COCUS AG, 65760 (DE)
International Classes:
G06F15/163; H04W76/02
Attorney, Agent or Firm:
Gille Hrabal Patentanwälte, 40593, Düsseldorf, DE
Claims:
1. Verfahren zur automatischen Clientkonfiguration von RCS-e Diensten mit einem mobilen Endgerät, einem über eine erste URL erreichbaren RCS-e Konfigurationsserver und einem RCS-e Applikationsserver mit folgenden Schritten:
a. Senden einer Anfrage zur Übermittlung von RCS-e Konfigurationsdaten vom Endgerät an den über die erste URL erreichbaren RCS-e Konfigurationsserver;
b. Übertragen von Authentifizierungsdaten vom RCS-e Konfigurationsserver an das Endgerät zum Herstellen einer abgesicherten Verbindung zwischen dem RCS-e Konfigurationsserver und dem Endgerät;
c. unter Verwendung der Authentifizierungsdaten, also über eine abgesicherte Verbindung, erfolgt eine zweite Anfrage zur Übermittlung von RCS-e Konfigurationsdaten vom Endgerät an den über die erste URL erreichbaren RCS-e Konfigurationsserver, beispielsweise mittels HTTPS GET; dabei
d. Übertragen der Parameter, die eine genauere Identifikation des Endgeräts und der dort gespeicherten Konfiguration erlauben, vom Endgerät an den RCS-e Konfigurationsserver über die abgesicherte Verbindung;
e. Übertragen vom RCS-e Konfigurationsserver an das Endgerät von RCS-e Konfigurationsdaten oder alternativ einer Bestätigung, dass die auf dem Endgerät gespeicherten RCS-e Konfigurationsdaten noch gültig sind;
f. Aufbauen einer Verbindung vom Endgerät zum RCS-e Applikationsserver unter Verwendung der RCS-e Konfigurationsdaten und Nutzung eines RCS-e Dienstes durch das Endgerät,
dadurch gekennzeichnet, dass
der RCS-e Applikationsserver außerhalb des Kernnetzes, des Mobilfunkanbieters angeordnet ist
und/oder
der RCS-e Dienst außerhalb des Kernnetzes, der Mobilfunkanbieters durchgeführt wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der über die erste URL erreichbare RCS-e Konfigurationsserver außerhalb des Kernnetzes des Mobilfunkanbieters angeordnet ist.

3. Verfahren zur automatischen Clientkonfiguration von RCS-e Diensten mit einem mobilen Endgerät,
einem über eine erste URL erreichbaren RCS-e Konfigurationsserver, welcher im Kernnetz des Mobilfunkanbieters angeordnet ist;
einem über eine zweite URL erreichbaren externen RCS-e Konfigurationsserver, welcher außerhalb des Kernnetzes des Mobilfunkanbieters angeordnet ist;
und einem RCS-e Applikationsserver mit folgenden Schritten:
a. Senden einer Anfrage zur Übermittlung von RCS-e Konfigurationsdaten vom Endgerät an den über die erste URL erreichbaren RCS-e Konfigurationsserver;
i. Senden der Antwort, beispielsweise als HTTP Statuscode „301 Moved Permanently“ oder „308 Permanent Redirect“, dass der über die erste URL nachgefragte Host unter der zweiten URL erreichbar ist, vom RCS-e Konfigurationsserver an das Endgerät;
ii. Senden einer Anfrage zur Übermittlung von RCS-e Konfigurationsdaten vom Endgerät an den über die zweite URL erreichbaren externen RCS-e Konfigurationsserver;
b. Übertragen von Authentifizierungsdaten vom externen RCS-e Konfigurationsserver an das Endgerät zum Herstellen einer abgesicherten Verbindung zwischen dem externen RCS-e Konfigurationsserver und dem Endgerät;
c. unter Verwendung der Authentifizierungsdaten, also über eine abgesicherte Verbindung, erfolgt eine zweite Anfrage zur Übermittlung von RCS-e Konfigurationsdaten vom Endgerät an den über die zweite URL erreichbaren externen RCS-e Konfigurationsserver, beispielsweise mittels HTTPS GET; dabei
d. Übertragen der Parameter, die eine genauere Identifikation des Endgeräts und der dort gespeicherten Konfiguration erlauben, vom Endgerät an den externen RCS-e Konfigurationsserver über die abgesicherte Verbindung;
e. Übertragen vom externen RCS-e Konfigurationsserver an das Endgerät von RCS-e Konfigurationsdaten oder alternativ einer Bestätigung, dass die auf dem Endgerät gespeicherten RCS-e Konfigurationsdaten noch gültig sind;
f. Aufbauen einer Verbindung vom Endgerät zum RCS-e Applikationsserver unter Verwendung der RCS-e Konfigurationsdaten und Nutzung eines RCS-e Dienstes durch das Endgerät.

4. Verfahren zur automatischen Clientkonfiguration von RCS-e Diensten mit einem mobilen Endgerät,
einem über eine erste URL erreichbaren RCS-e Konfigurationsserver, welcher im Kernnetz des Mobilfunkanbieters angeordnet ist;
einem über eine zweite URL erreichbaren externen RCS-e Konfigurationsserver, welcher außerhalb des Kernnetzes des Mobilfunkanbieters angeordnet ist;
und einem RCS-e Applikationsserver mit folgenden Schritten:
a. Senden einer Anfrage zur Übermittlung von RCS-e Konfigurationsdaten vom Endgerät an den über die erste URL erreichbaren RCS-e Konfigurationsserver; und
Weiterleiten dieser Anfrage vom RCS-e Konfigurationsserver an den über die zweite URL erreichbaren externen RCS-e Konfigurationsserver;
b. Übertragen von Authentifizierungsdaten vom externen RCS-e Konfigurationsserver an den RCS-e Konfigurationsserver zum Herstellen einer abgesicherten Verbindung zwischen dem externen RCS-e Konfigurationsserver und dem Endgerät;
und Weiterleiten dieser Authentifizierungsdaten vom RCS-e Konfigurationsserver an das Endgerät;
c. unter Verwendung der Authentifizierungsdaten, also über eine abgesicherte Verbindung, erfolgt eine zweite Anfrage zur Übermittlung von RCS-e Konfigurationsdaten vom Endgerät an den RCS-e Konfigurationsserver, beispielsweise mittels HTTPS GET; und Weiterleiten dieser zweiten Anfrage vom RCS-e Konfigurationsserver an den über die zweite URL erreichbaren externen RCS-e Konfigurationsserver; dabei
d. Übertragen der Parameter, die eine genauere Identifikation des Endgeräts und der dort gespeicherten Konfiguration erlauben, vom Endgerät an den RCS-e Konfigurationsserver über die abgesicherte Verbindung; und
Weiterleiten dieser Parameter vom RCS-e Konfigurationsserver an den über die zweite URL erreichbaren externen RCS-e Konfigurationsserver;
e. Übertragen vom externen RCS-e Konfigurationsserver an den RCS-e Konfigurationsserver von RCS-e Konfigurationsdaten oder alternativ einer Bestätigung, dass die auf dem Endgerät gespeicherten RCS-e Konfigurationsdaten noch gültig sind; und
Weiterleiten dieser RCS-e Konfigurationsdaten bzw. Bestätigung vom RCS-e Konfigurationsserver an das Endgerät;
f. Aufbauen einer Verbindung vom Endgerät zum RCS-e Applikationsserver unter Verwendung der RCS-e Konfigurationsdaten und Nutzung von eines RCS-e Dienstes durch das Endgerät.

5. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass auch der RCS-e Applikationsserver außerhalb des Kernnetzes des Mobilfunkanbieters angeordnet ist.

6. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass der RCS-e Dienst außerhalb des Kernnetzes, der Mobilfunkanbieters durchgeführt wird.

7. Verfahren nach einem der vorherigen Ansprüche, wobei
auf dem externen RCS-e Konfigurationsserver für mindestens ein Endgerät eine Vielzahl von RCS-e Konfigurationsdaten hinterlegt sind; und
diese Vielzahl von landes- und anbieterspezifischen RCS-e Konfigurationsdaten, welche die RCS-e Parameter des Endgeräts beinhalten,
für eine Vielzahl von Paarungen gebildet sind aus Mobilfunkanbietern,
beispielsweise dargestellt als Mobile Network Code (MNC) und Ländern,
beispielsweise dargestellt als Mobile Country Code (MCC).

8. Verfahren nach dem vorherigen Anspruch, wobei jeder Paarung aus Land und Mobilfunkanbieter zugeordnet ist:
– eine landes- und anbieterspezifische URL über welche der externe RCS-e direkt oder indirekt erreichbar ist
– die landes- und anbieterspezifischen RCS-e Konfigurationsdaten für das mindestens eine Endgerät,
mit folgenden Schritten:
– Auswahl der landes- und anbieterspezifischen RCS-e Konfigurationsdaten für das mindestens eine Endgerät in Abhängigkeit von der landes- und anbieterspezifischen URL, über welche das Endgerät den externen RCS-e Konfigurationsserver direkt oder indirekt erreicht hat, durch den externen RCS-e Konfigurationsserver;
– direktes oder indirektes Übertragen der ausgewählten RCS-e Konfigurationsdaten vom externen RCS-e Konfigurationsserver an das Endgerät.

9. Verfahren nach einem der vorherigen Ansprüche, wobei die Vielzahl der landes- und anbieterspezifischen URL den Mobile Network Code (MNC) der Mobilfunkanbieter sowie den Mobile Country Code (MCC) des Landes beinhalten und/oder sich nur durch diese unterscheiden.

10. Verfahren nach einem der vorherigen Ansprüche, wobei die Vielzahl der landes- und anbieterspezifischen URL wie folgt parametrisiert sind:
config.rcs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org, mit
– MNC = Wert des Mobile Network Code und
– MCC = Wert des Mobile Country Code
des Mobilfunkanbieters, welcher in der IMSI des Endgerätes eingetragen ist.

Description:

Die meisten Mobilfunkanbieter weltweit nutzen das Protokoll RCS-e (Rich Communication Suite enhanced) als Gegenentwurf zu Over-The-Top (OTT) Instant Messengern (IM), also der Übermittlung von Video- und Audioinhalten über Internetzugänge, ohne dass ein Internet-Service-Provider in die Kontrolle oder Verbreitung der Inhalte involviert. Mit RCS-e soll dem schwindenden Einfluss des Short Message Service (SMS) entgegengewirkt werden. RCS-e soll es Nutzern ermöglichen, ohne Konfiguration netzanbieterübergreifend mit anderen Nutzern Kurznachrichten, Bilder und Dateien auszutauschen oder Anrufe bzw. Video-Anrufe zu tätigen. Die RCS-e basiert dabei auf zahlreichen Internetstandards und benutzt zur Signalisierung das Session Initiation Protocol (SIP), welches bereits zur Signalisierung im IP Multimedia Subsystem (IMS) verwendet wird. Das IMS spezifiziert welche Dienste intern in einem Mobilfunknetzwerk vorhanden sein müssen und wie diese miteinander interagieren. Diese IMS-Infrastruktur wird in jedem Mobilfunknetz bereitgehalten. Durch die Verwendung von SIP lässt sich RCS-e somit in ein bereits bestehendes IMS integrieren. Damit ein Client, d. h. ein Endgerät, beispielsweise Smartphone eine automatische Clientkonfiguration von RCS-e durchlaufen kann, sieht die Spezifikation von RCS-e unter anderem, eine HTTP(S) basierte Konfiguration der Endgeräte vor. Sobald sich ein Endgerät mit dem mobilen Datennetzwerk des Mobilfunkanbieters verbindet, sendet es eine Anfrage an eine definierte URL, um Konfigurationsparameter für den RCS-e Dienst abzurufen. Diese parametrisierte URL lautet:
http://config.rcs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org,
wobei die Werte des jeweiligen Mobile Network Code (MNC) sowie Mobile Country Code (MCC) des Mobilfunkanbieters, bei dem der Nutzer Kunde ist, eingesetzt werden. Beispielsweise lautet für Telekom (MCC = 01) in Deutschland (MNC = 262) die Adresse zur automatischen Clientkonfiguration von RCS-e:
http://config.rcs.mnc001.mcc262.pub.3gppnetwork.org.

Bezugnehmend auf 1 verläuft die Konfiguration des Endgeräts durch die Übermittlung von Konfigurationsdaten an das Endgerät. Konfigurationsdaten umfasst alle Parameter, die notwendig sind für eine Kommunikation unter RCS-e. Es werden die folgenden Schritte ausgeführt, welche in 1 mit den entsprechenden Buchstaben als Bezugszeichen versehen sind:

  • a. Das Endgerät UE sendet initial eine Anfrage an die oben genannte URL, über die der Konfigurationsserver im Netz des Mobilfunkanbieters (Kernnetz) erreicht werden kann. Dieses geschieht in der Regel automatisch und vorsorglich durch das Endgerät beispielsweise über ein „HTTP GET“. Sinngemäß fragt Das Endgerät damit an, ob RCS-e Konfigurationsdaten für Endgeräte seitens des Mobilfunkanbieters bereitgehalten wird.
  • b. Der Konfigurationsserver übertragt Authentifizierungsdaten, die die weitere Verbindung absichern an das Endgerät. Normalerweise bestätigt der Konfigurationsserver zunächst die Gültigkeit der Anfrage mit der Meldung „HTTP 200 OK“ und übertragt ein HTTP-Cookie an das Endgerät, welcher für folgende Anfragen an die gesicherte URL verwendet wird. Alternativ, z. B. im On-Net Fall ist das Endgerät im mobilen Datennetzwerk eingebucht und die Authentifizierung erfolgt beispielsweise durch Header Enrichment über die MSISDN. Falls das Endgerät nicht im mobilen Datennetz eingebucht ist, werden in der Spezifikation weitere Methoden zur Authentifizierung beschrieben.
  • c. Unter Verwendung der Authentifizierungsdaten, also über eine abgesicherte Verbindung erfolgt eine zweite Anfrage an die oben genannte URL, mittels HTTPS GET.
  • d. Dabei überträgt das Endgerät mehrere Parameter, die eine genauere Identifikation des Endgeräts und der dort gespeicherten Konfiguration (d.h. eine Versionsnummer des Konfigurationsstandes) erlauben.
  • e. Der Konfigurationsserver überträgt nun initiale oder gegebenenfalls geänderte RCS-e Konfigurationsdaten an das Endgerät, beispielsweise als XML Konfiguration, oder bestätigt gegebenenfalls dass seine gespeicherten Konfigurationsdaten noch gültig ist.
  • f. Das Endgerät baut nun unter Verwendung der RCS-e Konfigurationsdaten eine Verbindung zum RCS-e Applikationsserver auf und kann über diesen alle unterstützten Funktionen nutzen.

Der Schritt f), also die Nutzung des RCS-e Dienstes, ist nicht Gegenstand der Fig.

Der Konfigurationsserver ist gemäß RCS-e Spezifikation unter der Kontrolle des Netzanbieters, d.h. der Server wird vom Netzanbieter betrieben und verwaltet. Ebenso müssen die SSL/TLS Zertifikate für die Konfigurationsdomain vom Netzanbieter gestellt werden. RCS-e wird als Teil des IMS durch die GSMA betrachtet und es muss daher für jede einzelne Mobile Network Code – Mobile Country Code (MNC – MCC) Paarung eine IMS Infrastruktur mit den entsprechenden Lizenzen bereitgestellt werden. Bei Änderungen der über RCS-e bereitgestellten Dienste sind also für sehr viele solcher Paarungen die RCS-e Konfigurationsdaten zu ändern. Die Vielzahl der Länder und Provider sorgt für lange Abstimmungs- und Anpassungszeiten, was die Implementierung und insbesondere die versuchsweise Implementierung neue Kommunikationsanwendungen unter RCS-e verzögert und behindert. Dies ist besonders unakzeptabel, da RCS-e gegen den dynamischen Markt der Over-The-Top (OTT) Instant Messenger (IM) antritt.

Es ist Aufgabe der Erfindung ein verbessertes Verfahren zur Automatischen Clientkonfiguration von RCS-e zu schaffen.

Diese Aufgabe wird gelöst durch Verfahren zur Automatischen Clientkonfiguration von RCS-e mit den Merkmalen des Hauptanspruchs bzw. der nebengeordneten Ansprüche. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche.

In einer ersten Variante der Erfindung ist zunächst vorgesehen, dass der RCS-e Applikationsserver außerhalb des Netzwerks, also des Kernnetzes bzw. international „Core Network“, des Mobilfunkanbieters angeordnet ist. Dies bedeutet, dass der Applikationsserver von einer Drittpartei im Namen des Netzbetreibers als OTT Service betrieben wird. Dies erhöht die Flexibilität bei der Implementierung neuer RCS-e Dienste und entlastet die kritische Kapazität des Kernnetzes des Mobilfunkanbieters. Dies gilt besonders dann, wenn alternativ oder zusätzlich auch der RCS-e Dienst außerhalb Kernnetzes des Mobilfunkanbieters durchgeführt wird, wodurch er ein OTT-Dienst wird, der dennoch auf die netzzentrische, automatische Konfiguration zugreifen kann.

Im Folgenden wird der Begriff Kernnetz erläutert: Mobilfunknetze unterteilen sich, genauso wie das Festnetz, in ein Kernnetzwerk und mehrere Zugangsnetze. Die Funktion des Kernnetzes besteht in der Verbindung der einzelnen Zugangsnetze, die den Endanwendern den Zugriff auf das Netz ermöglichen. Die Unterscheidung zwischen Mobilfunk- und Festnetz besteht hauptsächlich im Zugangsnetz, das in Mobilfunknetzen drahtlose Kommunikationsverbindungen aufbaut und so die Mobilität der Teilnehmer gewährleistet. Um den RCS-e Dienst extern, d.h. außerhalb des Kernnetzes und somit nicht im Netzwerk des Mobilfunkanbieters, zu betreiben ist es lediglich notwendig, dass entsprechende RCS-e Konfigurationsdaten auf das Endgerät übertragen werden. In der ersten Variante der Erfindung verbleibt der RCS-e Konfigurationsserver im Netzwerk des Mobilfunkanbieters während die Einträge in den RCS-e Konfigurationsdaten auf die externen Systeme verweisen. Der Fachmann würde den Betrieb einer extern gehosteten RCS-e Lösung nicht in Betracht ziehen, da RCS-e als Teil des IMS durch die GSMA betrachtet wird.

Vorzugsweise kann der über die erste URL erreichbare RCS-e Konfigurationsserver abweichend von den Standards außerhalb des Kernnetzes des Mobilfunkanbieters angeordnet sein, was das Kernnetz weiter entlastet. Beim Einsatz eines externen RCS-e Konfigurationsserver muss das entsprechende SSL Zertifikat auf diesem externen Server installiert werden, um zu gewährleisten, dass eine gesicherte HTTPS Verbindung aufgebaut werden kann. Der externe Server implementiert dann die in der RCS-e Spezifikation beschriebene Funktionalität. Dies setzt ein erhebliches Vertrauen seitens des Mobilfunkanbieters voraus.

Falls ein Netzbetreiber die SSL-Zertifikate nicht an einen externen Dienstleister herausgeben möchte oder die DNS Einträge für die o.g. URI ändern kann oder möchte, werden zwei alternative Varianten vorgeschlagen. Dabei handelt es sich zugleich um reine bzw. nahezu reine „Over-The-Top“ (OTT) Lösung, bei der keine oder nur wenige Systeme in Kernnetz des Mobilfunkanbieter verbleiben: Diese werden beschrieben als zweite und dritte Variante.

In einer zweiten Variante der Erfindung ist unverändert der über eine erste URL erreichbare RCS-e Konfigurationsserver im Kernnetz des Mobilfunkanbieters angeordnet. Es existiert aber auch ein über eine zweite URL erreichbarer externer RCS-e Konfigurationsserver, welcher außerhalb des Kernnetzes des Mobilfunkanbieters angeordnet ist. Dieser führt die eigentliche Konfiguration durch. Der RCS-e Konfigurationsserver im Kernnetz dient lediglich der Kompatibilität mit den Standards und dient als erste Kontaktadresse für die Endgeräte bei der RCS-e Konfigurationsanfrage.

Wie bereits bekannt sendet das Endgerät eine Anfrage zur Übermittlung von RCS-e Konfigurationsdaten an den über die erste URL erreichbaren RCS-e Konfigurationsserver. Dieser bearbeite jedoch die Anfrage nicht wie aus den Standards bekannt, sondern übermittelt eine Antwort, dass der über die erste URL nachgefragte Host nunmehr dauerhaft unter der zweiten URL erreichbar ist. Dies erfolgt hier beispielsweise als HTTP Statuscode „301 Moved Permanently“ oder „308 Permanent Redirect“. Ab hier finden die aus der ersten Variante bereits bekannten Schritte a)–f) statt, wobei aber die eigentliche Kommunikation zur RCS-e Konfiguration nicht zwischen dem Endgerät und dem unter der ersten URL erreichbaren RCS-e Konfigurationsserver im Kernnetz des Mobilfunkanbieters stattfindet, sondern zwischen Endgerät und dem über die zweite URL erreichbaren externen RCS-e Konfigurationsserver außerhalb des Kernnetzes.

Der Vorteil ist, dass der RCS-e Konfigurationsserver im Kernnetz des Mobilfunkanbieters verbleibt und die nötigen SSLZertifikate installiert hat. Jede Anfrage wird aber mit einem HTTP Statuscode „301 Moved Permanently“ oder „308 Permanent Redirect“ beantwortet, welche jeden Client dazu veranlassen, seine Anfrage an einen anderen Host zu stellen. Dieser neue Host wird im „Location“ Header der Antwort übertragen und verweist hier auf den externen Konfigurationsserver, z. B.: eines Dienstleisters. Die restliche Konfiguration läuft dann wie in der RCS-e Spezifikation beschrieben ab. Es müssen also keine SSL-Zertifikate auf fremden Servern installiert werden. Der verbleibende Konfigurationsserver im Kernnetz des Mobilfunkanbieters kann aber sehr minimal sein, da immer dieselbe Antwort sendet wird. Probleme können sich ergeben, wenn die RCS-e Implementierungen auf den Endgeräten die HTTP Statuscodes nicht richtig bzw. einheitlich auswerten, was bei der unüberschaubaren Menge an Endgerätentypen nicht übersehbar ist. Ferner kann es in einigen Situationen erforderlich sein, dass der Konfigurationsserver den Versand von Kurznachrichten veranlasst. Dazu muss ein Interface zurück zum Mobilfunkanbieter bestehen. Diese Probleme werden in der dritten Variante der Erfindung umgangen:
Auch die dritte Variante weist einen über eine erste URL erreichbaren RCS-e Konfigurationsserver auf, welcher im Kernnetz des Mobilfunkanbieters angeordnet ist sowie einen über eine zweite URL erreichbaren externen RCS-e Konfigurationsserver, welcher außerhalb des Kernnetzes des Mobilfunkanbieters angeordnet ist.

Jedoch kommuniziert das Endgerät ausschließlich mit dem über die erste URL erreichbaren RCS-e Konfigurationsserver im Kernnetz, welche die Anfrage jedoch verborgen weiterleitet an den über die zweite URL erreichbaren externen RCS-e Konfigurationsserver. Die Antworten vom externen RCS-e Konfigurationsserver werden daher ebenfalls nicht direkt an das Endgerät, sondern über den RCS-e Konfigurationsserver an das Endgerät weitergeleitet.

Die Vorteile sind hier, dass sich die Endgeräte an den ihnen aus den Standards bekannten RCS-e Konfigurationsserver wenden, welcher die Anfragen unverändert an den externen RCS-e Konfigurationsserver des externen Dienstleisters weiter leitet. Wichtig ist hierbei, dass der RCS-e Konfigurationsserver intern nicht blockierende Funktionen verwendet, um nicht als „bottleneck“ in der Kommunikation zu enden. Auch bei dieser Lösung müssen vorteilhafterweise keine SSL-Zertifikate auf fremden Servern installiert werden. Diese Lösung ist völlig konform zur RCS-e Spezifikation, da der grundsätzliche Ablauf der Konfiguration nicht verändert wird und kann somit fehlerfrei auch auf ungewöhnlich programmierten Endgeräten, die beispielsweise mit dem Umleitungen aus der zweiten Variante der Erfindung nicht zurechtkommen, durchgeführt werden.

Es ist zu beachten, dass der RCS-e Konfigurationsserver ein „bottleneck“ in der Kommunikation darstellen kann, wenn dieser nicht ausreichend dimensioniert ist. In einigen Situationen ist es erforderlich, dass der Konfigurationsserver den Versand von Kurznachrichten veranlasst. Dazu muss ein Interface zurück zum Mobilfunkanbieter bestehen.

Die folgenden Ausgestaltungen gelten für alle drei Varianten:
Zur Entlastung des Kernnetzes ist es bevorzugt, dass auch der RCS-e Applikationsserver außerhalb des Kernnetzes des Mobilfunkanbieters angeordnet ist und/oder der RCS-e Dienst außerhalb des Kernnetzes, der Mobilfunkanbieters durchgeführt wird.

Erfindungsgemäß wird insbesondere erreicht, dass nicht mehr für jede einzelne Mobile Network Code – Mobile Country Code (MNC – MCC) Paarung eine IMS Infrastruktur mit den entsprechenden Lizenzen bereitgestellt werden. Ein externer RCS-e Konfigurationsserver bzw. -Applikationsserver kann beispielsweise für einen Mobilfunkanbieter in vielen Ländern zum Einsatz kommen, also für einen MNC, aber vielen MCC. Es können sich auch Mobilfunkanbieter zusammentun. Bei Änderungen der über RCS-e bereitgestellten Dienste sind also weniger RCS-e Konfigurationsdaten zu ändern und die Vielzahl der Länder und Provider sorgt nicht mehr für lange Abstimmungs- und Anpassungszeiten, was die Implementierung und insbesondere die versuchsweise Implementierung neuer Kommunikationsanwendungen unter RCS-e beschleunigt.

Dies ist insbesondere Gegenstand der folgenden vorzugsweisen Ausgestaltungen:
Vorzugsweise ist dazu auf dem externen RCS-e Konfigurationsserver für mindestens ein Endgerät eine Vielzahl von RCS-e Konfigurationsdaten hinterlegt. Ein einziger externer RCS-e Konfigurationsserver kann somit gleichzeitig die Endgeräte in mehreren Ländern und/oder in den Netzen verschiedener Mobilfunkanbieter konfigurieren. Dazu sind dieser Vielzahl von landes- und anbieterspezifischen RCS-e Konfigurationsdaten, welche die RCS-e Parameter des Endgeräts beinhalten, einer Vielzahl von Paarungen, gebildet aus Mobilfunkanbietern und Ländern, beispielsweise dargestellt als Mobile Network Code (MNC) bzw. Mobile Country Code (MCC), zugeordnet.

Um im RCS-e Standard zu bleiben ist vorzugsweise jeder Paarung aus Land und Mobilfunkanbieter eine landes- und anbieterspezifische URL über welche der externe RCS-e direkt oder indirekt erreichbar ist, zugeordnet. Der Term „direkte oder indirekte Erreichbarkeit“ berücksichtigt hier, dass der externe RCS-e Konfigurationsserver in einigen Varianteen der Erfindung meist nur durch Vermittlung des kernnetzinternen RCS-e Konfigurationsserver erreichbar ist.

Ferner sind jeder Paarung aus Land und Mobilfunkanbieter die landes- und anbieterspezifischen RCS-e Konfigurationsdaten für das mindestens eine Endgerät zugeordnet. Somit kann die Auswahl der landes- und anbieterspezifischen RCS-e Konfigurationsdaten für das mindestens eine Endgerät in Abhängigkeit von der landes- und anbieterspezifischen URL, über welche das Endgerät den externen RCS-e Konfigurationsserver direkt oder indirekt erreicht hat, durch den externen RCS-e Konfigurationsserver erfolgen. Dieser überträgt sodann – direkt oder indirektdie derart ausgewählten landes- und anbieterspezifischen RCS-e Konfigurationsdaten vom externen RCS-e Konfigurationsserver an das Endgerät.

Vorzugsweise und um im RCS-e Standard zu bleiben, beinhalten die Vielzahl der landes- und anbieterspezifischen URL den Mobile Network Code (MNC) der Mobilfunkanbieter sowie den Mobile Country Code (MCC) des Landes bzw. unterscheiden sich nur durch diese.

Daher kann vorzugsweise die Vielzahl der landes- und anbieterspezifischen URL wie folgt parametrisiert sein:
http://config.rcs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org,
mit MNC = Wert des jeweiligen Mobile Network Code und MCC = Wert des Mobile Country Code des Mobilfunkanbieters, bei dem das Endgerät „beheimatet“ ist, also die Werte, die in der IMSI (International Mobile Subscriber Identity) des SIM (Subscriber Identity Module) des Endgerätes eingetragen sind. Beispielsweise im Fall Vodafone in Deutschland, Ungarn und Irland würden die auf denselben externen RCS-e Konfigurationsserver – direkt oder indirekt – weisenden URL lauten:
DE: http://config.rcs.mnc009.mcc262.pub.3gppnetwork.org
HU: http://config.rcs.mnc070.mcc216.pub.3gppnetwork.org
IR: http://config.rcs.mnc001.mcc272.pub.3gppnetwork.org

Nachfolgend werden Ausführungsbeispiele der Erfindung anhand von Figuren näher erläutert. Merkmale des Ausführungsbeispiels können einzeln oder in einer Mehrzahl mit dem beanspruchten Gegenstand kombiniert werden. Die Aufzählungsbuchstaben in den jeweiligen Ansprüche entsprechen den Bezugszeichen in den Figuren. Der Schritt f), also die Nutzung des RCS-e Dienstes, ist nicht Gegenstand der Figuren.

2 zeigt die erste Variante der Erfindung mit einem Externen RCS-e Konfigurationsserver, der außerhalb des Kernnetzes des Mobilfunkanbieters angeordnet ist. Die URL verweist auf den externen Konfigurationsserver. Dabei muss das entsprechende SSL Zertifikat auf dem externen Server installiert werden, um zu gewährleisten, dass eine gesicherte HTTPS Verbindung aufgebaut werden kann. Der externe Server implementiert dann die in der RCS-e Spezifikation beschriebene Funktionalität. Die Schritte a)–e) entsprechen dabei grundsätzlich dem Stand der Technik aus 1.

3 zeigt die zweite Variante nach Anspruch 3 der Erfindung mit dem üblichen RCS-e Konfigurationsserver im Kernnetz und einem externen RCS-e Konfigurationsserver, der außerhalb des Kernnetzes des Mobilfunkanbieters angeordnet ist. Der Konfigurationsserver verbleibt also im Kernnetz des Mobilfunkanbieters und hat die nötigen SSL-Zertifikate installiert. Jede Anfrage wird aber mit einem HTTP Statuscode „301 Moved Permanently“ oder „308 Permanent Redirect“ beantwortet, welche den Client dazu veranlassen, seine Anfrage an einen anderen Host, nämlich den externen RCS-e Konfigurationsserver zu stellen. Dieser neue Host wird im „Location“ Header der Antwort übertragen und verweist auf den externen Konfigurationsserver des Dienstleisters. Die restliche Konfiguration läuft dann wie in der RCS-e Spezifikation beschrieben ab. Der externe Server implementiert dann die in der RCS-e Spezifikation beschriebene Funktionalität. Die Schritte a.ii)–e) entsprechen dabei grundsätzlich dem Stand der Technik aus 1. Besonderheit der Erfindung ist also, dass der Schritt a) die mehreren Unterschritte a.i) und a.ii) umfasst und dabei verschiedene Hosts, nämlich den kernnetzinternen Konfigurationsserver und externen Konfigurationsserver kontaktiert. Der kernnetzinterne Konfigurationsserver führt dabei keine Konfiguration durch, sondern dient lediglich als dem Standard entsprechende erste Kontaktadresse für die Endgeräte UE.

4 zeigt die dritte Variante nach Anspruch 4 der Erfindung mit dem üblichen RCS-e Konfigurationsserver im Kernnetz und einem externen RCS-e Konfigurationsserver, der außerhalb des Kernnetzes des Mobilfunkanbieters angeordnet ist. Der kernnetzinterne Konfigurationsserver verbleibt also im Kernnetz des Mobilfunkanbieters und hat die nötigen SSL-Zertifikate installiert. Der Konfigurationsserver im Kernnetz des Mobilfunkanbieters dient als Relay zum externen Konfigurationsserver des externen Dienstleisters. Die Endgeräte wenden sich an den ihnen bekannten kernnetzinternen Konfigurationsserver, welcher die Anfragen unverändert an den externen Konfigurationsserver des externen Dienstleisters weiter leitet. Die Schritte a)–e) entsprechen dabei grundsätzlich dem Stand der Technik aus 1, wobei erfindungsgemäß jeder Schritt a)–e) zwischen Endgerät und externen Konfigurationsserver abläuft, welcher aber im Hintergrund und unsichtbar hinter dem kernnetzinternen Konfigurationsserver versteckt ist. Der kernnetzinterne Konfigurationsserver führt dabei keine Konfiguration durch, sondern dient lediglich als dem Standard entsprechende Kontaktadresse für die Endgeräte UE.

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Nicht-Patentliteratur

  • http://config.rcs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org [0001]
  • http://config.rcs.mnc001.mcc262.pub.3gppnetwork.org [0001]
  • http://config.rcs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org [0023]
  • http://config.rcs.mnc009.mcc262.pub.3gppnetwork.org [0023]
  • http://config.rcs.mnc070.mcc216.pub.3gppnetwork.org [0023]
  • http://config.rcs.mnc001.mcc272.pub.3gppnetwork.org [0023]