Title:
Server, Verfahren und Programm
Kind Code:
T5


Abstract:

[Aufgabe] Bereitstellung eines Mechanismus, um Sicherheit im Zusammenhang mit einem Edge-Server zu gewährleisten.
[Lösung] Ein Server, der konfiguriert ist, einer anderen Vorrichtung Inhalt bereitzustellen, wobei der Server Folgendes aufweist: eine Verarbeitungseinheit, die konfiguriert ist, Kommunikation mit einem Netzwerk auszuführen, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem Server entsprechen, der in einem Heimatteilnehmerserver (Home Subscriber Server - HSS) registriert ist. embedded image




Inventors:
Takano, Hiroaki (Tokyo, JP)
Saito, Shin (Tokyo, JP)
Kimura, Ryota (Tokyo, JP)
Application Number:
DE112016005859T
Publication Date:
09/06/2018
Filing Date:
09/29/2016
Assignee:
Sony Corporation (Tokyo, JP)



Attorney, Agent or Firm:
WITTE, WELLER & PARTNER Patentanwälte mbB, 70173, Stuttgart, DE
Claims:
Server, der konfiguriert ist, einer anderen Vorrichtung Inhalt bereitzustellen, wobei der Server Folgendes umfasst:
eine Verarbeitungseinheit, die konfiguriert ist, Kommunikation mit einem Netzwerk auszuführen, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem Server entsprechen, der in einem Heimatteilnehmerserver (Home Subscriber Server - HSS) registriert ist.

Server nach Anspruch 1, wobei die Authentifizierungsinformationen, die dem Server entsprechen, Authentifizierungsinformationen des Servers sind.

Server nach Anspruch 2, wobei die Authentifizierungsinformationen des Servers eine Nummer aufweisen, die den Server identifiziert, und Schlüsselinformationen, die für den Server spezifisch sind.

Server nach Anspruch 2, der ferner Folgendes umfasst:
eine Speichereinheit, die zum Speichern der Authentifizierungsinformationen des Servers konfiguriert ist,
wobei die Verarbeitungseinheit eine Authentifizierung des Netzwerks unter Verwendung der Authentifizierungsinformationen des Servers ausführt.

Server nach Anspruch 2, wobei ein Schlüssel zur Kommunikation zwischen einer Anwendung, die in dem Server arbeitet, und einer MME basierend auf den Authentifizierungsinformationen des Servers generiert wird.

Server nach Anspruch 1, wobei die Authentifizierungsinformationen, die dem Server entsprechen, Authentifizierungsinformationen eines Endgeräts sind, das dem Server zugeordnet ist.

Server nach Anspruch 6, wobei die Authentifizierungsinformationen des Endgeräts eine Nummer aufweisen, die den Server identifiziert, und Schlüsselinformationen, die für das Endgerät spezifisch sind.

Server nach Anspruch 6, wobei die Verarbeitungseinheit eine Kommunikation mit dem Netzwerk unter Verwendung von Informationen ausführt, die basierend auf einer Anfrage von dem Endgerät ausgegeben werden, das dem Server zugeordnet ist, dem die Authentifizierung des Netzwerks gelungen ist.

Server nach Anspruch 8, wobei ein Schlüssel zur Kommunikation zwischen einer Anwendung, die in dem Server arbeitet, und einer MME basierend auf den Authentifizierungsinformationen des Endgeräts generiert wird, das dem Server zugeordnet ist.

Server nach Anspruch 1, wobei ein Schlüssel für die Kommunikation zwischen einem Endgerät und einer Anwendung, die in dem Server arbeitet, basierend auf Authentifizierungsinformationen des Endgeräts generiert wird.

Server nach Anspruch 1, wobei der Server ein Anwendungsserver ist, der in einem EPS bereitgestellt ist.

Server nach Anspruch 11, wobei die Authentifizierungsinformationen, die dem Server entsprechen, Authentifizierungsinformationen eines anderen Servers sind, der dem Server zugeordnet ist.

Server nach Anspruch 12, wobei die Verarbeitungseinheit eine Kommunikation mit dem Netzwerk unter Verwendung von Informationen ausführt, die basierend auf einer Anfrage von dem anderen Server ausgegeben werden, der dem Server zugeordnet ist, dem die Authentifizierung des Netzwerks gelungen ist.

Server nach Anspruch 12, wobei der andere Server ein Inhaltsserver ist, der dem Server Inhalt bereitstellt.

Server nach Anspruch 1, wobei der Server ein Inhaltsserver ist, der einem Anwendungsserver, der in einem EPS bereitgestellt ist, Inhalt bereitstellt.

Server nach Anspruch 15, wobei der Server über eine Basisstation eine Kommunikation mit einer MME ausführt.

Server nach Anspruch 15, wobei der Server über keine Basisstation eine Kommunikation mit einer MME ausführt.

Server nach Anspruch 1, wobei der Server ein Anwendungsserver ist, der in einem drahtlosen LAN-Netzwerk bereitgestellt ist.

Verfahren, das Folgendes umfasst:
Ausführen, von einem Server, der konfiguriert ist, einer anderen Vorrichtung Inhalt bereitzustellen, einer Kommunikation mit einem Netzwerk, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem Server entsprechen, der in einem HSS registriert ist.

Programm, das einen Computer veranlasst, wie folgt zu fungieren:
als ein Server, der einer anderen Vorrichtung Inhalt bereitstellt und eine Verarbeitungseinheit aufweist, die konfiguriert ist, eine Kommunikation mit einem Netzwerk auszuführen, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem Server entsprechen, der in einem HSS registriert ist.

Description:
Technisches Gebiet

Die vorliegende Offenbarung betrifft einen Server, ein Verfahren und ein Programm.

Stand der Technik

In den letzten Jahren hat eine Mobile-Edge-Computing- (MEC-) Technologie zur Ausführung der Datenverarbeitung in einem Server (nachstehend auch als Edge-Server bezeichnet) Aufmerksamkeit erregt, der an einer Position physisch nahe bei einem Endgerät wie einem Smartphone bereitgestellt wird. Zum Beispiel wird ein Standard einer Technologie in Bezug auf MEC in der unten zitierten Nicht-Patentliteratur 1 untersucht.

Beim MEC ist ein Edge-Server an einer Position physisch nahe bei einem Endgerät angeordnet, sodass eine Kommunikationsverzögerung im Vergleich zu einem allgemeinen Cloud-Server reduziert wird, der konzentriert angeordnet ist, wobei es möglich ist, eine Anwendung zu verwenden, die eine hohe Echtzeit-Leistung aufweisen muss. Ferner wird beim MEC der Edge-Server in der Nähe des Endgeräts veranlasst, eine verteilte Verarbeitung einer Funktion auszuführen, die bisher auf der Seite des Endgeräts verarbeitet wurde, sodass ungeachtet der Leistung des Endgeräts eine Hochgeschwindigkeitsnetzwerk-/Anwendungsverarbeitung realisiert werden kann. Der Edge-Server kann verschiedene Funktionen haben, wie eine Funktion, die als ein Anwendungsserver dient, und eine Funktion, die als ein Inhaltsserver dient, und kann dem Endgerät verschiedene Dienste bereitstellen.

Liste bekannter SchriftenNicht-Patentliteratur

Nicht-Patentliteratur 1: ETSI, „Mobile-Edge Computing-Introductory Technical White Paper“, September, 2014, [gesucht am 3. September 2015], das Internet <https://portal.etsi.org/Portals/0/TBpages/MEC/Docs/Mobile-edge_Computing_-_Introductory_Technical_White_Paper_V1%2018-09-14.pdf>

Offenbarung der ErfindungTechnisches Problem

Es ist schwer zu sagen, dass das Studium von Nicht-Patentliteratur 1 oder dergleichen ausreichende Vorschläge für Technologie im Zusammenhang mit MEC hervorgebracht hat, da solche Studien erst kürzlich begonnen haben. Zum Beispiel gehört eine Technologie zur Gewährleistung der Sicherheit in Bezug auf einen Edge-Server zu einer, für die es nicht genügend Vorschläge gab.

Lösung des Problems

Gemäß der vorliegenden Offenbarung wird ein Server bereitgestellt, der konfiguriert ist, einer anderen Vorrichtung Inhalt bereitzustellen, wobei der Server Folgendes aufweist: eine Verarbeitungseinheit, die konfiguriert ist, Kommunikation mit einem Netzwerk auszuführen, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem Server entsprechen, der in einem Heimatteilnehmerserver (Home Subscriber Server - HSS) registriert ist.

Außerdem wird gemäß der vorliegenden Offenbarung ein Verfahren bereitgestellt, das Folgendes beinhaltet: Ausführen, von einem Server, der konfiguriert ist, einer anderen Vorrichtung Inhalt bereitzustellen, einer Kommunikation mit einem Netzwerk, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem Server entsprechen, der in einem HSS registriert ist.

Außerdem wird gemäß der vorliegenden Offenbarung ein Programm bereitgestellt, das einen Computer veranlasst, wie folgt zu fungieren: als ein Server, der einer anderen Vorrichtung Inhalt bereitstellt und eine Verarbeitungseinheit aufweist, die konfiguriert ist, eine Kommunikation mit einem Netzwerk auszuführen, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem Server entsprechen, der in einem HSS registriert ist.

Vorteilhafte Auswirkungen der Erfindung

Wie oben beschrieben, wird gemäß der vorliegenden Offenbarung ein Mechanismus zur Gewährleistung der Sicherheit in Bezug auf einen Edge-Server bereitgestellt. Es wird angemerkt, dass die oben beschriebenen Effekte nicht notwendigerweise beschränkend sind. Mit den oder an Stelle der obigen Effekte(n) können ein beliebiger der Effekte, die in dieser Beschreibung beschrieben sind, oder andere Effekte, die aus dieser Beschreibung erhalten werden können, erzielt werden.

Figurenliste

  • [1] 1 ist ein erläuterndes Diagramm, das ein Beispiel für eine schematische Konfiguration eines Systems 1 gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht.
  • [2] 2 ist ein Diagramm, das ein Beispiel einer Konfiguration eines LTE-Netzwerks veranschaulicht, in dem MEC nicht eingeführt ist.
  • [3] 3 ist ein Blockdiagramm, das ein Beispiel für eine Konfiguration eines Netzwerks veranschaulicht, in dem MEC eingeführt ist.
  • [4] 4 ist ein Diagramm, das ein Beispiel für eine Konfiguration eines LTE-Netzwerks veranschaulicht, in dem MEC eingeführt ist.
  • [5] 5 ist ein Diagramm, das ein Beispiel eines Datenstroms von DL-Cachedaten veranschaulicht.
  • [6] 6 ist ein Diagramm, das ein Beispiel eines Datenstroms von UL-Cachedaten veranschaulicht.
  • [7] 7 ist ein erläuterndes Diagramm zum Beschreiben einer Architektur eines Trägers.
  • [8] 8 ist ein erläuterndes Diagramm zum Beschreiben einer Architektur eines EPS-Trägers.
  • [9] 9 ist ein erläuterndes Diagramm zum Beschreiben einer UL-ID und einer DL-ID, die in einem Träger eingestellt ist;
  • [10] 10 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Vorgangs zum Einrichten eines Standardträgers veranschaulicht.
  • [11] 11 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Vorgangs zum Einrichten eines dedizierten Trägers veranschaulicht.
  • [12] 12 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Authentifizierungsvorgangs veranschaulicht, der in einem LTE-Netzwerk ausgeführt wird.
  • [13] 13 ist ein erläuterndes Diagramm zum Beschreiben eines Anwendungsbeispiels von Schlüsseln, die während einer tatsächlichen Kommunikation verwendet werden.
  • [14] 14 ist ein Systemdiagramm von Schlüsseln.
  • [15] 15 ist ein Blockdiagramm, das ein Beispiel für eine Konfiguration eines Endgeräts gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht.
  • [16] 16 ist ein Blockdiagramm, das ein Beispiel für eine Konfiguration eines MEC-Servers gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht.
  • [17] 17 ist ein Blockdiagramm, das ein Beispiel für eine Konfiguration EPC-Funktionsentität gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht.
  • [18] 18 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß einer ersten Ausführungsform.
  • [19] 19 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß einer zweiten Ausführungsform.
  • [20] 20 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß einer dritten Ausführungsform.
  • [21] 21 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß der vorliegenden Ausführungsform.
  • [22] 22 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß einer vierten Ausführungsform.
  • [23] 23 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß der vorliegenden Ausführungsform.
  • [24] 24 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß der vorliegenden Ausführungsform.
  • [25] 25 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß der vorliegenden Ausführungsform.
  • [26] 26 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß der vorliegenden Ausführungsform.
  • [27] 27 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß der vorliegenden Ausführungsform.
  • [28] 28 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß der vorliegenden Ausführungsform.
  • [29] 29 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß der vorliegenden Ausführungsform.
  • [30] 30 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß der vorliegenden Ausführungsform.
  • [31] 31 ist ein erläuterndes Diagramm zum Beschreiben von technischen Merkmalen gemäß der vorliegenden Ausführungsform.
  • [32] 32 ist ein Blockdiagramm, das ein Beispiel einer schematischen Konfiguration eines Servers veranschaulicht.
  • [33] 33 ist ein Blockdiagramm, das ein Beispiel einer schematischen Konfiguration eines Smartphones veranschaulicht.
  • [34] 34 ist ein Blockdiagramm, das ein Beispiel einer schematischen Konfiguration einer Fahrzeugnavigationsvorrichtung veranschaulicht.

Ausführungsweise(n) der Erfindung

Nachfolgend wird/werden (eine) bevorzugte Ausführungsform(en) der vorliegenden Offenbarung unter Bezugnahme auf die angehängten Zeichnungen ausführlich beschrieben. Es ist zu beachten, dass in dieser Beschreibung und den angehängten Zeichnungen strukturelle Elemente, die im Wesentlichen die gleiche Funktion und Struktur aufweisen, mit den gleichen Bezugszeichen bezeichnet werden und eine wiederholte Erläuterung dieser strukturellen Elemente ausgelassen wird.

Ferner gibt es in dieser Beschreibung und den Zeichnungen Fälle, in denen Elemente, die im Wesentlichen die gleiche Funktion haben, durch Anhängen verschiedener Buchstaben an das Ende der gleichen Bezugszahl unterschieden werden. Zum Beispiel wird eine Mehrzahl von Elementen, die im Wesentlichen die gleiche funktionale Konfiguration aufweisen, wie die Basisstationen 100A, 100B und 100C, je nach Notwendigkeit unterschieden. In einem Fall jedoch, in dem es nicht notwendig ist, jedes der Mehrzahl von Elementen zu unterscheiden, die im Wesentlichen die gleiche funktionale Konfiguration aufweisen, wird nur das gleiche Bezugszeichen hinzugefügt. Zum Beispiel werden in einem Fall, in dem es nicht notwendig ist, die Basisstationen 100A, 100B und 100C besonders zu unterscheiden, diese einfach als eine „Basisstation 100“ bezeichnet.

Nachstehend wird die Beschreibung in der folgenden Reihenfolge stattfinden.

  1. 1. Einleitung
    • 1.1. Schematische Systemkonfiguration
    • 1.2. MEC
    • 1.3. Träger
    • 1.4. Sicherheit
  2. 2. Konfigurationsbeispiel jeder Vorrichtung
    • 2.1. Konfiguration des Endgeräts
    • 2.2. Konfigurationsbeispiel des MEC-Servers
    • 2.3. Konfigurationsbeispiel der EPC-Funktionsentität
  3. 3. Erste Ausführungsform
    • 3.1. Technisches Problem
    • 3.2. Technische Merkmale
  4. 4. Zweite Ausführungsform
    • 4.1. Technisches Problem
    • 4.2. Technische Merkmale
  5. 5. Dritte Ausführungsform
    • 5.1. Technisches Problem
    • 5.2. Technische Merkmale
  6. 6. Vierte Ausführungsform
    • 6.1. Technisches Problem
    • 6.2. Konfigurationsbeispiel des OTT-Servers
    • 6.3. Technische Merkmale
  7. 7. Anwendungsbeispiele
  8. 8. Kurzdarstellung

<<Einleitung>><Schematische Systemkonfiguration>

Zunächst wird eine schematische Konfiguration eines Systems 1 gemäß einer Ausführungsform der vorliegenden Offenbarung unter Bezugnahme auf 1 beschrieben. 1 ist ein erläuterndes Diagramm, das ein Beispiel für eine schematische Konfiguration des Systems 1 gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. Unter Bezugnahme auf 1 weist das System 1 eine drahtlose Kommunikationsvorrichtung 100, ein Endgerät 200 und einen MEC-Server 300 auf.

(1) Drahtlose Kommunikationsvorrichtung 100

Die drahtlose Kommunikationsvorrichtung 100 ist eine Vorrichtung, die einen drahtlosen Kommunikationsdienst für untergeordnete Vorrichtungen bereitstellt. Zum Beispiel ist eine drahtlose Kommunikationsvorrichtung 100A eine Basisstation eines zellularen Systems (oder eines mobilen Kommunikationssystems). Die Basisstation 100A führt eine drahtlose Kommunikation mit einer Vorrichtung (beispielsweise einem Endgerät 200A) aus, die sich innerhalb einer Zelle 10A der Basisstation 100A befindet. Zum Beispiel sendet die Basisstation 100A ein Downlink-Signal an das Endgerät 200A und empfängt ein Uplink-Signal von dem Endgerät 200A.

Hier wird die Basisstation 100 auch als ein eNodeB (oder eNB) bezeichnet. Hier kann der eNodeB ein eNodeB sein, wie in LTE oder LTE-A definiert, oder er kann allgemeiner als eine Kommunikationsvorrichtung interpretiert werden.

Die Basisstation 100A ist logisch mit anderen Basisstationen beispielsweise über eine X2-Schnittstelle verbunden und kann die Übertragung und den Empfang von Steuerinformationen und dergleichen ausführen. Ferner ist die Basisstation 100A logisch mit einem Kernnetzwerk 40 beispielsweise über eine S1-Schnittstelle verbunden und kann die Übertragung und den Empfang von Steuerinformationen und dergleichen ausführen. Ferner kann die Kommunikation zwischen diesen Vorrichtungen physisch von verschiedenen Vorrichtungen übermittelt werden.

Hier ist die drahtlose Kommunikationsvorrichtung 100A, die in 1 dargestellt ist, eine Mikrozellen-Basisstation und eine Zelle 10A ist eine Mikrozelle. Andererseits sind die drahtlosen Kommunikationsvorrichtungen 100B und 100C Master-Vorrichtungen, die die kleinen Zellen 10B und 10C betreiben. Als ein Beispiel ist die Master-Vorrichtung 100B eine Kleinzellen-Basisstation, die fest installiert ist. Die Kleinzellen-Basisstation 100B stellt eine drahtlose Rückstreckenverbindung mit der Mikrozellen-Basisstation 100A her und stellt eine Zugangsverbindung mit einem oder mehreren Endgeräten (zum Beispiel dem Endgerät 200B) in einer kleinen Zelle 10B her. Die Master-Vorrichtung 100C ist ein dynamischer Zugangspunkt (AP). Der dynamische AP 100C ist eine mobile Vorrichtung, die die Kleinzelle 10C dynamisch betreibt. Der dynamische AP 100C stellt eine drahtlose Rückstreckenverbindung mit der Mikrozellen-Basisstation 100A her und stellt eine Zugangsverbindung mit einem oder mehreren Endgeräten (zum Beispiel dem Endgerät 200C) in der kleinen Zelle 10C her. Der dynamische AP 100C kann zum Beispiel ein Endgerät sein, das mit Hardware oder Software ausgerüstet ist, die als eine Basisstation oder ein drahtloser Zugangspunkt fungieren kann. In diesem Fall ist die kleine Zelle 10C ein lokalisiertes Netzwerk (Localized Network/virtuelle Zelle), das dynamisch gebildet wird.

Die Zelle 10 kann gemäß einem beliebigen drahtlosen Kommunikationsschema funktionieren, wie LTE, LTE-A, GSM (R), UMTS, W-CDMA, CDMA 200, WiMAX, WiMAX 2 oder IEEE 802.16.

Ferner kann die kleine Zelle ein Konzept sein, das verschiedene Arten von Zellen einschließt, die derart angeordnet sind, dass sie sich mit der Mikrozelle überlappen oder sich nicht mit der Mikrozelle überlappen, und kleiner als die Mikrozelle (zum Beispiel eine Femtozelle, eine Nanozelle, eine Pikozelle, eine Mikrozelle oder dergleichen) sind. In einem Beispiel wird die kleine Zelle von einer dedizierten Basisstation betrieben. In einem anderen Beispiel wird die kleine Zelle als ein Endgerät betrieben, das als eine Master-Vorrichtung dient, die temporär als eine Kleinzellen-Basisstation fungiert. Ein so genannter Relaisknoten kann auch als eine Form einer Kleinzellen-Basisstation betrachtet werden. Die drahtlose Kommunikationsvorrichtung, die als eine Master-Station des Relaisknotens fungiert, wird auch als „Spender-Basisstation“ bezeichnet. Die Spender-Basisstation kann sich auf einen Spender-eNodeB (DeNB) in LTE beziehen oder sich allgemeiner auf eine Master-Station eines Relaisknotens beziehen.

Endgerät 200

Das Endgerät 200 kann in einem zellularen System (oder einem mobilen Kommunikationssystem) kommunizieren. Das Endgerät 200 führt eine drahtlose Kommunikation mit der drahtlosen Kommunikationsvorrichtung (zum Beispiel der Basisstation 100A und der Master-Vorrichtung 100B oder 100C) des zellularen Systems aus. Zum Beispiel empfängt das Endgerät 200A das Downlink-Signal von der Basisstation 100A und sendet ein Uplink-Signal an die Basisstation 100A.

Hier wird das Endgerät 200 auch als ein „Benutzer“ bezeichnet. Der Benutzer kann auch als ein Benutzergerät (User Equipment, UE) bezeichnet werden. Außerdem wird die drahtlose Kommunikationsvorrichtung 100C auch als ein „UE-Relais“ bezeichnet. Hier kann das UE ein UE sein, das in LTE oder LTE-Advanced (LTE-A) definiert ist, das UE-Relais kann ein Prose UE to Network Relay, das in 3GPP erläutert ist, oder allgemeiner eine Kommunikationsvorrichtung sein.

Anwendungsserver 60

Ein Anwendungsserver 60 ist eine Vorrichtung, die dem Benutzer einen Dienst bereitstellt. Der Anwendungsserver 60 ist mit einem Paketdatennetzwerk (PDN) 50 verbunden. Andererseits ist die Basisstation 100 mit dem Kernnetzwerk 40 verbunden. Das Kernnetzwerk 40 ist über eine Gateway-Vorrichtung mit dem PDN 50 verbunden. Daher stellt die drahtlose Kommunikationsvorrichtung 100 den von dem Anwendungsserver 60 bereitgestellten Dienst dem MEC-Server 300 und dem Benutzer über das Paketdatennetzwerk 50, das Kernnetzwerk 40 und den drahtlosen Kommunikationsweg bereit.

MEC-Server 300

Der MEC-Server 300 ist eine Dienstbereitstellungsvorrichtung, die dem Benutzer einen Dienst (zum Beispiel Inhalt oder dergleichen) bereitstellt. Der MEC-Server 300 kann in der drahtlosen Kommunikationsvorrichtung 100 bereitgestellt sein. In diesem Fall stellt die drahtlose Kommunikationsvorrichtung 100 dem Benutzer über den drahtlosen Kommunikationsweg den vom MEC-Server 300 bereitgestellten Dienst bereit. Der MEC-Server 300 kann als eine logische Funktionsentität implementiert sein oder kann integral mit der drahtlosen Kommunikationsvorrichtung 100 oder dergleichen gebildet sein, wie in 1 dargestellt. Natürlich kann der MEC-Server 300 als eine unabhängige Vorrichtung als eine physische Entität gebildet sein. Eine Anwendung, die im MEC-Server 300 betrieben wird, wird auch als MEC-Anwendung bezeichnet.

Zum Beispiel stellt die Basisstation 100A den von dem MEC-Server 300A bereitgestellten Dienst dem Endgerät 200A bereit, das mit der Mikrozelle 10 verbunden ist. Ferner stellt die Basisstation 100A den von dem MEC-Server 300A bereitgestellten Dienst dem Endgerät 200B bereit, das über die Master-Vorrichtung 100B mit der Kleinzelle 10B verbunden ist.

Ferner stellt die Master-Vorrichtung 100B den von dem MEC-Server 300B bereitgestellten Dienst dem Endgerät 200B bereit, das mit der Kleinzelle 10B verbunden ist. In ähnlicher Weise stellt die Master-Vorrichtung 100C den von dem MEC-Server 300C bereitgestellten Dienst dem Endgerät 200C bereit, das mit der kleinen Zelle 10C verbunden ist.

Ergänzung

Die schematische Konfiguration des Systems 1 wurde oben beschrieben, jedoch ist die vorliegende Technologie nicht auf das in 1 dargestellte Beispiel beschränkt. Zum Beispiel kann als eine Konfiguration des Systems 1 eine Konfiguration, die keine Master-Vorrichtung aufweist, eine Small-Cell-Enhancement (SCE), ein heterogenes Netzwerk (HetNet), ein Netzwerk vom Maschinenkommunikationstyp (MTC) oder dergleichen verwendet werden.

<MEC>

Als Nächstes wird der MEC unter Bezugnahme auf 2 bis 6 beschrieben.

(1) Netzwerkkonfiguration

2 ist ein Diagramm, das ein Beispiel einer Konfiguration eines LTE-Netzwerks veranschaulicht, in dem MEC nicht eingeführt ist. Wie in 2 dargestellt, weist ein ein Funkzugangsnetzwerk (RAN) ein UE und einen eNodeB auf. Das UE und der eNodeB sind über eine Uu-Schnittstelle verbunden und die eNodeBs sind über eine X2-Schnittstelle verbunden. Ferner weist ein Evolved Packet Core (EPC) eine Mobility Management Entity (MME), einen Home Subscriber Server (HSS), ein Serving Gateway (S-GW) und ein PDN Gateway (P-GW) auf. Die MME und der HSS sind über eine S6a-Schnittstelle verbunden, die MME und das S-GW sind über eine S11-Schnittstelle verbunden und das S-GW und das P-GW sind über eine S5-Schnittstelle verbunden. Der eNodeB und die MME sind über eine S1-MME-Schnittstelle verbunden, der eNodeB und der S-GW sind über eine S1-U-Schnittstelle verbunden, und das P-GW und der PDN sind über eine SGi-Schnittstelle verbunden.

Der PDN weist beispielsweise einen ursprünglichen Server und einen Cacheserver auf. Eine ursprüngliche Anwendung, die dem UE bereitgestellt werden soll, ist in dem ursprünglichen Server gespeichert. Beispielsweise werden eine Anwendung oder Cachedaten im Cacheserver gespeichert. Durch Zugreifen auf den Cacheserver anstelle des ursprünglichen Servers kann das UE eine Verarbeitungslast auf dem ursprünglichen Server und eine Kommunikationslast entsprechend dem Zugriff auf den ursprünglichen Server reduzieren. Da sich der Cacheserver jedoch außerhalb des RAN und des EPC (d. h. des PDN) befindet, ist eine Kommunikationsverzögerung, die zwischen dem UE und dem Cacheserver auftritt (d. h. eine Antwortverzögerung auf eine Anfrage von dem UE) immer noch a Problem.

Beispiele für die Anfrage des UE schließen eine statische Anfrage wie das Herunterladen von Inhalt, der in einem HTTP-Server gespeichert ist, und eine dynamische Anfrage wie einen Arbeitsablauf in einer spezifischen Anwendung ein. In jedem Fall ist es klar, dass, falls Cachedaten und eine Anwendung in einer Entität in der Nähe des UE angeordnet werden, die Antwort auf die Anfrage schnell ist. Typischerweise hängt die Antwortgeschwindigkeit hier von der Anzahl der zu durchlaufenden Einheiten und nicht von der Entfernung zwischen Einheiten ab. Dies beruht darauf, dass eine Verarbeitungsverzögerung in einer Eingabeeinheit, einer Verarbeitungseinheit und einer Ausgabeeinheit in jeder Entität, die durchlaufen wird, gemäß der Anzahl von Einheiten akkumuliert wird. Ferner zeigt der Inhalt Daten eines beliebigen Formats an, beispielsweise eine Anwendung, ein Bild (ein Bewegtbild oder ein Standbild), einen Ton, Text oder dergleichen.

Das MEC wurde erfunden, um ein solches Problem zu lösen. Beim MEC wird ein Anwendungsserver, der dem UE Inhalt bereitstellt oder Inhalte von dem UE erfasst, in einem Evolved Packet System (EPS) installiert. Ferner ist das EPS ein Netzwerk, das einen EPC und einen eUTRAN (d. h. einen eNodeB) aufweist. Der im EPS installierte Anwendungsserver kann auch als Edge-Server oder MEC-Server bezeichnet werden. Ferner ist der Anwendungsserver ein Konzept, das einen Cacheserver einschließt.

3 und 4 sind Diagramme, die ein Beispiel einer Konfiguration eines LTE-Netzwerks veranschaulichen, in das MEC eingeführt wird. In 3 ist ein MEC-Server, der Inhalte zwischenspeichert, in einem eNodeB installiert. Gemäß dieser Konfiguration ist die Anzahl von Entitäten, die zwischen dem UE und dem MEC-Server angeordnet sind, im Vergleich zu dem in 2 dargestellten Beispiel verringert, und somit kann das UE den Inhalt schnell erfassen. In 4 ist der MEC-Server, der den Inhalt speichert, im eNodeB und im S-GW installiert. Zum Beispiel erfasst das UE den Inhalt von dem in dem eNodeB angeordneten MEC-Server und erfasst den Inhalt von dem in dem S-GW angeordneten MEC-Server in einem Fall, in dem keine Cachedaten von dem in dem eNodeB angeordneten MEC-Server angefordert werden. Da der Zugriff auf den ursprünglichen Server vermieden werden kann, kann das UE den Inhalt in jedem Fall schnell erfassen.

Entitäten

Die in 2 bis 4 dargestellten Entitäten werden nachstehend beschrieben. Das S-GW ist eine Entität, die als ein Ankerpunkt der Übergabe dient. Das P-GW ist ein Verbindungspunkt zwischen einem mobilen Netzwerk und dem Äußeren (d. h. einem PDN), weist dem UE eine IP-Adresse zu und stellt eine IP-Adresse bereit, auf die von dem Äußeren des Mobilnetzes zugegriffen werden kann. Das P-GW führt auch eine Filterung oder dergleichen bei Daten aus, die von außen ankommen. Der HSS ist eine Datenbank, die Teilnehmerinformationen speichert. Die MME greift auf den HSS zu, um verschiedene Steuersignale zu verarbeiten, und führt einen Prozess wie eine Authentifizierung jedes UEs und eine Autorisierung aus.

Das EPC-Netzwerk ist in eine Steuerungsebene und eine Benutzerebene unterteilt. Das S-GW und das P-GW beziehen sich hauptsächlich auf die Benutzerebene und die MME und der HSS beziehen sich hauptsächlich auf die Steuerebene.

Hier hat das S-GW eine Funktion des Speicherns von Benutzerdaten, da es selbst in der Konfiguration, bevor MEC eingeführt wird, als der Ankerpunkt der Übergabe dient. Andererseits hat der eNodeB keine Funktion des Speicherns der Benutzerdaten in der Konfiguration, bevor MEC eingeführt wird, und hat nur Funktionen wie eine Paketneuübertragung gemäß einem Paketverlust, der in der Uu-Schnittstelle aufgetreten ist, und ist somit nicht in der Lage, Inhalt zu speichern. Ferner wird die X2-Schnittstelle für den Datenaustausch zum Zeitpunkt der Übergabe und zur kooperativen Steuerung der Interferenz verwendet.

Anwendung in MEC-Server

Beispiele für den Cache schließen einen Stream-Cache, der das Zwischenspeichern auf einer IP-Ebene durchführt, und einen Inhaltscache ein, der das Zwischenspeichern auf einer Anwendungsschichtebene ausführt. Es wird angenommen, dass der MEC-Server beide Arten von Caches unterstützt. Da hauptsächlich der Inhaltscache verwendet wird, geht man derzeit davon aus, dass der MEC-Server insbesondere den Inhaltscache unterstützt.

Hier im MEC-Server ist es wichtig, dass eine Anwendung aktiviert wird und in einen betriebsbereiten Zustand eintritt. Dies beruht erstens darauf, dass Cachedaten auf der Basis eines HTTP-Headers erkannt werden, weshalb es im MEC-Server wünschenswert ist, dass eine Anwendung, die in der Lage ist, das HTTP zu handhaben, in den Betriebszustand eintritt. Zweitens ist es in einem Fall, in dem der MEC-Server eine spezifische Anwendung bereitstellt, wünschenswert, dass die Anwendung platziert und aktiviert wird, um in den Betriebszustand einzutreten.

Anwendungsarten, die MEC entsprechen, sind vielfältig. Im Falle der Cacheanwendung, die Daten zwischenspeichert, wenngleich sie aktiviert ist und in den Betriebszustand in dem MEC-Server eintritt, geht das UE in einem Fall, in dem keine Zieldaten zwischengespeichert werden, zu einem ursprünglichen Server, um Daten zu erfassen. Daher ist es wünschenswert, Daten in der Cacheanwendung im Voraus zwischenzuspeichern.

Cachezieldaten

Als in dem MEC-Server 300 zwischengespeicherte Daten gibt es zwei Arten, nämlich Daten, die an das UE in einer Downlink (DL) -Richtung (im Folgenden auch als ein DL-Datenfluss bezeichnet) übertragen werden sollen, und Daten, die von dem UE in einer Uplink (UL) -Richtung (nachfolgend als UL-Datenfluss bezeichnet) hochgeladen werden.

Als Anwendungsfall des Zwischenspeicherns des DL-Datenflusses gibt es beispielsweise einen Fall, in dem, wenn das UE auf eine Webanwendung zugreift und bestimmte http-Daten erfasst, falls die gleichen Daten in dem MEC-Server zwischengespeichert werden, die Cachedaten erfasst werden.

Ein Beispiel für den Anwendungsfall zum Zwischenspeichern des UL-Datenflusses wird nachstehend beschrieben.

Ein erster Anwendungsfall ist ein Fall des Hochladens von Daten wie eines vom UE generierten Bildes. Insbesondere lädt das UE ein vom UE generiertes Bild hoch, und der MEC-Server speichert das Bild zwischen. Dann kann der MEC-Server das zwischengespeicherte Bild an einen Server übertragen, der das Bild auf dem PDN speichert, beispielsweise zu einem Zeitpunkt, zu dem Platz in einer Übertragungskapazität in dem Kernnetzwerk vorhanden ist. Eine Kommunikationslast des Kernnetzwerks wird durch Verschieben des Übertragungszeitpunktes verringert. Ferner kann der MEC-Server beispielsweise das zwischengespeicherte Bild an ein anderes UE übertragen. Das gemeinsame Nutzen des Caches des UL-Datenflusses mit anderen UEs ist zum Beispiel für einen Fall nützlich, in dem Bilder, die von Zuschauern in einem Stadion aufgenommen werden, unter den Zuschauern im Stadion gemeinsam genutzt werden.

Ein zweiter Anwendungsfall ist ein Fall des Hochladens von Daten, die von dem UE erfasst werden. Zum Beispiel lädt das UE Daten hoch, die über die Kommunikation von Vorrichtung zu Vorrichtung (D2D) oder Wi-Fi (eine eingetragene Marke) erfasst werden, und der MEC-Server speichert die Daten zwischen. Als ein spezifisches Beispiel für diesen Anwendungsfall wird beispielsweise ein Beispiel in Betracht gezogen, in dem ein Geschäft Informationen über Produkte über D2D-Kommunikation oder Wi-Fi übermittelt und das UE die Informationen erfasst und die Informationen auf den MEC-Server hochlädt. In diesem Fall können andere UEs innerhalb eines Bereichs des Geschäfts (z. B. innerhalb einer Zelle des eNodeB, in dem der MEC-Server installiert ist) die zwischengespeicherten Informationen der Produkte erfassen.

Ein dritter Anwendungsfall ist das Hochladen von Daten, die von einem anderen eNodeB empfangen werden. Zum Beispiel lädt das UE die Daten, die von dem eNodeB empfangen werden, der vor der Übergabe verbunden wird, auf den MEC-Server hoch, der in dem eNodeB installiert ist, der nach der Übergabe verbundenen wird.

Ein vierter Anwendungsfall ist ein Fall, in dem das MTC-Endgerät Daten hochlädt. Als solche Daten werden beispielsweise Verkaufsdaten eines Verkaufsautomaten und Gasnutzungsstatusdaten betrachtet, die von einem Gaszähler erkannt werden. In manchen Fällen ist die Anzahl der MTC-Endgeräte sehr groß ist, und falls die MTC-Endgeräte versuchen, alle Daten auf den Server auf dem PDN hochzuladen, besteht das Problem, dass auf der Seite des Kernnetzes eine Überlastung auftritt. Da solche Daten keine Echtzeiteigenschaft erfordern, sind sie andererseits ausreichend, wenngleich sie zum Beispiel erst nach einer Stunde ankommen. Mit anderen Worten kann eine Anwendung, die sich auf Daten von dem MTC-Endgerät bezieht, als gegenüber einer Verzögerung resistent angesehen werden. Daher kann der MEC-Server die von dem MTC-Endgerät hochgeladenen Daten zwischenspeichern und die zwischengespeicherten Daten an den Server auf dem PDN übertragen, beispielsweise zu dem Zeitpunkt, an dem in der Übertragungskapazität in dem Kernnetzwerk Platz ist. Insbesondere ist in der Übertragungskapazität des Kernnetzes die Kapazität des Steuersignals problematischer als die Kapazität der Benutzerdaten. Um eine Sitzung aufzubauen, ist eine Signalisierung mehrerer Runden notwendig. Wenn eine große Anzahl von MTC-Endgeräten alle Daten zusammen hochlädt, wird die Signalisierung des Kernnetzwerks übermäßig erhöht.

Das Beispiel des Anwendungsfalles des Zwischenspeicherns des UL-Datenflusses wurde beschrieben. In dieser Spezifikation wird die Beschreibung mit dem Cache des UL-Datenflusses fortgesetzt.

Die Cachedaten des UL-Datenflusses können in der DL-Richtung (zum Beispiel das UE) wie oben beschrieben übertragen werden oder können in der UL-Richtung (zum Beispiel der Server auf dem P-GW oder dem PDN) übertragen werden. Die erstgenannten Cachedaten werden auch als DL-Cachedaten bezeichnet und die letztgenannten Cachedaten werden auch als UL-Cachedaten bezeichnet.

5 ist ein Diagramm, das ein Beispiel des Datenflusses der DL-Cache-Daten darstellt. Wie in 5 dargestellt, speichert der MEC-Server die vom UE hochgeladenen Daten zwischen und überträgt die Cachedaten an das UE (typischerweise ein anderes UE als das hochladende UE).

6 ist ein Diagramm, das ein Beispiel eines Datenflusses der UL-Cachedaten veranschaulicht. Wie in 6 dargestellt, speichert der MEC-Server die von dem UE hochgeladenen Daten und überträgt die Cachedaten an den ursprünglichen Server auf dem PDN.

Ferner gibt es in Abhängigkeit von den Daten Fälle, in denen die Daten nicht als DL-Cachedaten behandelt werden dürfen. Zum Beispiel dürfen Daten, die mit anderen UEs gemeinsam genutzt werden können, als die DL-Cachedaten behandelt werden, und persönliche Daten dürfen nicht als DL-Cachedaten behandelt werden. In ähnlicher Weise gibt es je nach Daten Fälle, in denen die Daten nicht als UL-Cachedaten behandelt werden dürfen. Zum Beispiel sind Daten, die aggregiert werden müssen, wie Daten von dem MTC-Endgerät, als die UL-Cachedaten erlaubt, und lokale Daten wie Daten, die eine regionale Beschränkung aufweisen, sind als die UL-Cachedaten nicht erlaubt.

Unter solchen Umständen ist es in dem MEC-Server wünschenswert, in geeigneter Weise zu verwalten, ob die Cachedaten in der DL-Richtung (d. h. zum UE) übertragen werden können oder nicht, und ob die Cachedaten in der UL-Richtung (das heißt, zum PDN) übertragen werden können oder nicht.

<Träger>

Als Nächstes wird ein Träger, der in dem EPS verwendet wird, insbesondere der EPS-Träger, unter Bezugnahme auf 7 bis 11 beschrieben. Der Träger bezieht sich auf eine Sitzung, das heißt ein Abflussrohr zur Datenübertragung.

7 ist ein erläuterndes Diagramm zum Beschreiben der Architektur des Trägers. Wie in 7 dargestellt, wird ein End-to-End-Dienst, der dem UE von dem ursprünglichen Server bereitgestellt wird, durch Datenübertragung unter Verwendung des EPS-Trägers und eines externen Trägers bereitgestellt. Ein EPS-Träger wird in Verbindung mit einer Art von QoS eingerichtet. Zum Beispiel richtet das UE zwei EPS-Träger ein, die zwei Arten von QoS mit dem P-GW entsprechen, falls zwei Arten von QoS gleichzeitig verwenden werden sollen.

Der EPS-Träger ist eine logische Sitzung (eine virtuelle Verbindung) und weist tatsächlich einen Funkträger, einen S1-Träger und einen S5-Träger auf. Der Funkträger ist ein Träger, der auf der LTE-Uu-Schnittstelle zwischen dem UE und dem eNodeB eingerichtet ist. Der S1-Träger ist ein Träger, der an der S 1-Schnittstelle zwischen dem eNodeB und dem S-GW eingerichtet ist. Der S5-Träger ist ein Träger, der auf der S5-Schnittstelle zwischen dem S-GW und dem P-GW eingerichtet ist.

8 ist ein erläuterndes Diagramm zum Beschreiben der Architektur des EPS-Trägers. Wie in 8 erläutert, weist der EPS-Träger einen Standardträger und einen dedizierten Träger auf. Wenn der Träger durch Austauschen von Signalen mit der MME eingerichtet wird, richtet das UE zuerst den Standardträger ein, der einer QoS entspricht, die als Standard entschieden wird. Danach richtet das UE einen Träger ein, der einer notwendigen QoS als dedizierter Träger entspricht. Der dedizierte Träger kann nicht ohne Standardträger eingerichtet werden.

Eine ID, die den Träger identifiziert, ist in jedem Träger festgelegt. Die ID wird verwendet, um den von einem UE verwendeten Träger zu identifizieren. Wenn sowohl die ID des UE als auch die ID des Trägers verwendet werden, ist es daher möglich, dass jede Entität (zum Beispiel das P-GW, das S-GW, der eNodeB oder dergleichen) jeden Träger identifiziert. Als ID gibt es eine UL-ID und eine DL-ID.

9 ist ein erläuterndes Diagramm zum Beschreiben einer UL-ID und einer DL-ID, die in einem Träger festgelegt sind. Wie in 9 dargestellt, werden in dem EPS-Träger eine UL-Sitzung und eine DL-Sitzung durch separate IDs unterschieden. Zum Beispiel gibt es als ID, die in dem Funkträger festgelegt ist, eine „UL RB ID“ für den UL und eine „DL RB ID“ für den DL. Ferner ist in dem S1-Träger eine Sitzung (eine Sitzung, die gemäß einem GTP-Tunnelprotokoll ausgetauscht wird) vorhanden, die durch eine Tunnelendpunkt-ID (TEID) unterschieden wird, und „UL S1 TEID“, die eine UL-ID ist, oder „DL S1 TEID“, die eine DL ID ist, werden festgelegt. Ferner ist in dem S5-Träger eine Sitzung vorhanden, die durch TEID unterschieden wird, und „UL S5 TEID“, die eine UL-ID ist, oder „DL S5 TEID“, das eine DL-ID ist, werden festgelegt.

Die nachstehende Tabelle zeigt Entitäten, die IDs zuweisen. Dies bedeutet, dass eine Entität, die eine ID zuweist, eine relevante Sitzung mit Verantwortung aufbaut. [Tabelle 1]

EntitätULDLUEeNodeBUL RB IDDL RB ID,DL S1 TEIDS-GWUL S1 TEIDDL S5 TEIDP-GWUL S5 TEID

In der obigen Tabelle wird die TEID von einer Entität auf einer Endpunktseite zugewiesen. Andererseits werden sowohl die UL RB ID als auch die DL RB ID von dem eNodeB zugewiesen.

Die folgende Tabelle zeigt eine Liste der Datenflüsse mit IDs. Wie in der folgenden Tabelle dargestellt, wird der UL-Datenfluss in einer Sitzung übertragen, der die UL-ID zugewiesen ist, und der DL-Datenfluss wird in einer Sitzung übertragen, der die DL-ID zugewiesen ist. Ferner weist die ID jeder Sitzung eine Eins-zu-Eins-Zuordnungsbeziehung auf, wobei eine ID einer ID zugeordnet ist. Mit anderen Worten, eine ID wird niemals einer Mehrzahl von IDs zugeordnet. [Tabelle 2]

EntitätULDLUEUP IP flow->UL RB IDeNodeBUL RB IDDL S 1 TEID->UL S1 TEID->DL RB IDS-GWUL S1 TEIDDL S5 TEID->UL S5 TEID->DL S1 TEIDP-GWDL IP flow->DLS5 TEID

Als Nächstes wird ein Vorgang zum Einrichten des Trägers unter Bezugnahme auf 10 und 11 beschrieben.

10 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Vorgangs zum Einrichten des Standardträgers veranschaulicht. Die Sequenz beinhaltet ein UE, einen eNodeB, eine MME, ein S-GW, ein P-GW und eine Vorschriften- und Entgelterhebungsfunktion (PCRF). Wie in 10 dargestellt, wird die Einrichtung des Standardträgers gemäß einer Anfrage von dem UE initiiert. Die Anfrage wird in der Reihenfolge des eNodeB, der MME, des S-GW und des P-GW übertragen, und eine Genehmigung wird in einer entgegengesetzten Richtung übertragen. Ferner ist die PCRF eine Entität, die Informationen über eine QoS bereitstellt.

Die vorliegende Sequenz wird im Detail beschrieben. Zuerst überträgt das UE eine Anfügungsanfrage an den eNodeB (Schritt S11), und der eNodeB überträgt die Nachricht an die MME (Schritt S12). Dann überträgt die MME eine Standardträger-Generierungsanfrage an das S-GW (Schritt S13), und das S-GW überträgt die Nachricht an das P-GW (Schritt S14). Dann tauscht sich das P-GW mit der PCRF aus, um eine IP-Konnektivitätszugangsnetzwerk (IP-CAN)-Sitzung aufzubauen (Schritt S15). Dann überträgt das P-GW eine Standardträger-Generierungsantwort an das S-GW (Schritt S16), und das S-GW überträgt die Nachricht an die MME (Schritt S17). Dann überträgt die MME eine Anfügungsannahme an den eNodeB (Schritt S18), und der eNodeB überträgt eine Funkressourcensteuerungs- (RRC) -Verbindungsrekonfiguration an das UE (Schritt S19). Dann überträgt das UE eine RRC-Verbindungsrekonfiguration-Beendigung an den eNodeB (Schritt S20), und der eNodeB überträgt eine Anfügungsbeendigung an die MME (Schritt S21). Dann überträgt die MME eine Trägeraktualisierungsanfrage an das S-GW (Schritt S22), und das S-GW überträgt eine Trägeraktualisierungsantwort an die MME (Schritt S23).

11 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Vorgangs zum Einrichten des dedizierten Trägers veranschaulicht. Die vorliegende Sequenz beinhaltet das UE, den eNodeB, die MME, das S-GW, das P-GW und die PCRF. Wie in 11 dargestellt, wird die Einrichtung des dedizierten Trägers gemäß der Anfrage von der PCRF im Gegensatz zu dem Standardträger eingeleitet. Falls das UE den dedizierten Träger einrichten möchte, überträgt das UE ferner eine Nachricht, die anzeigt, dass das UE den dedizierten Träger für die Anwendungsschicht einrichten möchte, und die Anwendungsschicht überträgt eine notwendige QoS an die PCRF, sodass die Einrichtung des vom UE initiierten dedizierten Trägers implementiert wird.

Die vorliegende Sequenz wird im Detail beschrieben. Zuerst sendet die PCRF einen IP-CAN-Sitzungsänderungsstart an das P-GW (Schritt S31). Dann überträgt das P-GW eine dedizierte Trägergenerierungsanfrage an das S-GW (Schritt S32), und das S-GW überträgt die Nachricht an die MME (Schritt S33). Dann überträgt die MME eine dedizierte Träger-Setup-Anfrage an den eNodeB (Schritt S34), und der eNodeB überträgt eine RRC-Verbindungsrekonfiguration an das UE (Schritt S35). Dann überträgt das UE eine RRC-Verbindungsrekonfigurationsbeendigung an den eNodeB (Schritt S36), und der eNodeB überträgt eine dedizierte Träger-Setup-Antwort an die MME (Schritt S37). Dann überträgt die MME eine dedizierte Trägergenerierungsantwort an das S-GW (Schritt S38), und das S-GW überträgt die Nachricht an das P-GW (Schritt S39). Dann überträgt das P-GW ein IP-CAN-Sitzungsänderungsende an die PCRF (Schritt S40).

<Sicherheit>

Als ein Beispiel für Sicherheitstechnologie in LTE werden Authentifizierung und Autorisierung veranschaulicht. Bei der Authentifizierung wird bestimmt, ob ein Kommunikationspartner ein geeigneter Partner ist. Ein geeigneter Partner ist hier beispielsweise ein Partner, der über die entsprechende Berechtigung zum Zugriff auf ein LTE-Netzwerk eines Betreibers verfügt. Die Autorisierung ist eine Entscheidung darüber, ob ein Kommunikationspartner ein Recht zur Nutzung eines Dienstes hat. Ein Recht ist hier beispielsweise ein Zugriffsrecht auf ein LTE-Netz eines Betreibers. Ein Authentifizierungsvorgang wird nachstehend unter Bezugnahme auf 12 beschrieben. Hier ist der Authentifizierungsvorgang ein Teil eines Anfügungsvorgangs.

12 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Authentifizierungsabaufs veranschaulicht, der in einem LTE-Netzwerk ausgeführt wird. Wie in 12 dargestellt, speichert das UE eine internationale Mobilteilnehmeridentität (IMSI) und einen Schlüssel K. Außerdem speichert der HSS eine IMSI jedes UE und einen Schlüssel K, der dem IMSI entspricht. Hier kommuniziert das UE mit einer MME über einen eNodeB. Wie nachstehend beschrieben wird, führen das UE und der HSS eine gegenseitige Authentifizierung unter Verwendung der gleichen IMSI und des Schlüssels K aus , die jeweils gespeichert werden.

Zuerst überträgt das UE eine Verbindungsanfrage zusammen mit der IMSI an die MME (Schritt S51). Danach überträgt die MME eine Authentifizierungsanfrage zusammen mit der empfangenen IMSI an den HSS (Schritt S52). Als Nächstes generiert der HSS eine Zufallszahl RAND, gibt die Zufallszahl RAND, die empfangene IMSI und den in Verbindung mit der IMSI gespeicherten Schlüssel K in die Authentifizierungsfunktion ein und erhält eine erwartete Antwort RESEXPECTED und einen Schlüssel KASME (Schritt S53). Als Nächstes sendet der HSS den Schlüssel KASME, die erwartete Antwort RESEXPECTED und die Zufallszahl RAND an die MME als Authentifizierungsantwort (Schritt S54). Als Nächstes überträgt die MME die Zufallszahl RAND an das UE (Schritt S55). Als Nächstes gibt das UE die empfangene Zufallszahl RAND und die gespeicherte IMSI und den Schlüssel K in die Authentifizierungsfunktion ein und erhält eine Antwort RES und einen Schlüssel KASME (Schritt S56). Als Nächstes sendet das UE eine Antwort RES an die MME (Schritt S57). Dann vergleicht die MME die erwartete Antwort RESEXPECTED mit einer tatsächlichen Antwort RES und authentifiziert das UE (Schritt S58). Insbesondere wenn die erwartete Antwort mit der tatsächlichen Antwort RES übereinstimmt, bestimmt die MME, dass das UE zuverlässig ist (das heißt, die Authentifizierung ist erfolgreich). Wenn andererseits die erwartete Antwort RESEXPECTED nicht mit der tatsächlichen Antwort RES übereinstimmt, bestimmt die MME, dass das UE nicht zuverlässig ist (das heißt, die Authentifizierung schlägt fehl).

Nach dem Authentifizierungsvorgang werden Schlüssel, die während der tatsächlichen Kommunikation verwendet werden, auf der Basis von KASME generiert. Es gibt zwei Arten von Schlüsseln, einen Chiffrierschlüssel (CK) und einen Integritätsschlüssel (IK). Der CK ist ein Schlüssel zur Verschlüsselung der Kommunikation und wird verwendet, um zu verhindern, dass Kommunikationsinhalte anderen bekannt werden. Die IK ist ein Schlüssel zum Prüfen einer Integrität von Daten und wird verwendet, um zu überprüfen, ob Daten auf einem Kommunikationspfad geändert wurden. Im EPS wird die Sicherheit gemäß einem Authentifizierungs-/Autorisierungsvorgang (AA), Verschlüsselung mittels eines CK und Prüfen einer Integrität unter Verwendung der IK gewährleistet. Hier werden diese Prozesse separat für jedes UE ausgeführt.

Wie oben unter Bezugnahme auf 12 beschrieben, wird gemäß dem Authentifizierungsvorgang ein gemeinsamer Schlüssel KASME sowohl auf der UE-Seite als auch auf der Netzwerkseite generiert. Die UE-Seite und die Netzwerkseite (HSS, MME oder eNodeB) generieren Schlüssel, die während der tatsächlichen Kommunikation für jede Anwendung basierend auf dem gemeinsamen Schlüssel KASME verwendet werden. Ein Anwendungsbeispiel von Schlüsseln, die während der tatsächlichen Kommunikation verwendet werden, wird nachstehend unter Bezugnahme auf 13 beschrieben.

13 ist ein erläuterndes Diagramm zum Beschreiben eines Anwendungsbeispiels von Schlüsseln, die während der tatsächlichen Kommunikation verwendet werden. Wie in 13 dargestellt, wird ein CK für eine Benutzerebene zwischen dem UE und dem eNodeB verwendet. Außerdem werden der IK und der CK für die Funkressourcensteuerungs (RRC) -Signalisierung zwischen dem UE und dem eNodeB verwendet. Außerdem werden der IK und der CK zur Nicht-Zugriffs-Stratum- (NAS-) Signalisierung zwischen dem UE und der MME verwendet. Auf diese Weise wird für jede Anwendung ein anderer Schlüssel verwendet. Dann werden solche Schlüssel auf der Grundlage von KASME generiert, das in dem AA-Vorgang generiert wird. Eine Beziehung zwischen Schlüsseln, die für jede Anwendung generiert werden, wird nachstehend unter Bezugnahme auf 14 beschrieben.

14 ist ein Systemdiagramm von Schlüsseln. In der Zeichnung gibt enc verschlüsseln, int eine Integrität an, RRC gibt eine RRC-Signalisierung an, NAS gib eine NAS-Signalisierung an und UP gibt eine Benutzerebene an. Das Systemdiagramm der in 14 dargestellten Schlüssel ist der UE-Seite und der Netzwerkseite gemeinsam. Bei Schlüsseln auf der Netzwerkseite wird ein Schlüssel für NAS von MME generiert. Schlüssel für die RRC-Signalisierung und eine andere Benutzerebene als der Schlüssel für NAS werden vom eNodeB generiert. In Bezug auf die Schlüssel auf der UE-Seite werden alle Schlüssel von dem UE generiert.

Die Generierung von Schlüsseln, die in 14 dargestellt sind, wird in Zeitserien beschrieben. Zuerst generieren der HSS und das UE KASME entsprechend einer gegenseitigen Authentifizierung. Als Nächstes generieren die MME und das UE einen Schlüssel für die NAS-Signalisierung (d. h. KNASenc und KNASint) und einen Basisschlüssel für einen eNodeB (d. h. KeNodeB) auf der Basis von KASME. Dann generieren der eNodeB und das UE einen Schlüssel für die RRC-Signalisierung (d. h. KRRCenc und KRRCint) und einen Schlüssel für eine Benutzerebene (d. h. KUPenc) auf der Basis des Basisschlüssels für einen eNodeB.

<<Konfigurationsbeispiel jeder Vorrichtung>><Konfiguration des Endgeräts>

Zuerst wird ein Beispiel für eine Konfiguration des Endgeräts 200 gemäß der Ausführungsform der vorliegenden Offenbarung unter Bezugnahme auf 15 beschrieben. 15 ist ein Blockdiagramm, das ein Beispiel für eine Konfiguration des Endgeräts 200 gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. Unter Bezugnahme auf 15 weist das Endgerät 200 eine Antenneneinheit 210, eine drahtlose Kommunikationseinheit 220, eine Speichereinheit 230 und eine Verarbeitungseinheit 240 auf.

(1) Antenneneinheit 210

Die Antenneneinheit 210 strahlt ein von der drahtlosen Kommunikationseinheit 220 ausgegebenes Signal in einen Raum als eine Funkwelle ab. Ferner wandelt die Antenneneinheit 210 die Funkwelle in dem Raum in ein Signal um und gibt das Signal an die drahtlose Kommunikationseinheit 220 aus.

Drahtlose Kommunikationsvorrichtung 220

Die drahtlose Kommunikationseinheit 220 überträgt und empfängt Signale. Zum Beispiel empfängt die drahtlose Kommunikationseinheit 220 ein Downlink-Signal von der Basisstation und überträgt ein Uplink-Signal an die Basisstation.

Speichereinheit 230

Die Speichereinheit 230 speichert temporär oder permanent ein Programm und verschiedene Daten für einen Betrieb des Endgeräts 200.

Verarbeitungseinheit 240

Die Verarbeitungseinheit 240 stellt verschiedene Funktionen des Endgeräts 200 bereit. Die Verarbeitungseinheit 240 weist eine Authentifizierungsverarbeitungseinheit 241 und eine Kommunikationsverarbeitungseinheit 243 auf. Des Weiteren kann die Verarbeitungseinheit 240 ferner andere Komponenten als die oben beschriebenen Komponenten beinhalten. Mit anderen Worten kann die Verarbeitungseinheit 240 auch andere Arbeitsabläufe als die Arbeitsabläufe der oben beschriebenen Komponenten durchführen.

Die Arbeitsabläufe der Authentifizierungsverarbeitungseinheit 241 und der Kommunikationsverarbeitungseinheit 243 werden später im Detail beschrieben.

<Konfigurationsbeispiel des MEC-Servers>

Als Nächstes wird ein Beispiel für eine Konfiguration des MEC-Servers 300 gemäß einer Ausführungsform der vorliegenden Offenbarung unter Bezugnahme auf 16 beschrieben. 16 ist ein Blockdiagramm, das ein Beispiel für eine Konfiguration des MEC-Servers 300 gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. Unter Bezugnahme auf 16 weist der MEC-Server 300 eine Kommunikationseinheit 310, eine Speichereinheit 320 und eine Verarbeitungseinheit 330 auf.

(1) Kommunikationseinheit 310

Die Kommunikationseinheit 310 ist eine Schnittstelle zum Ausführen einer Kommunikation mit anderen Vorrichtungen. Zum Beispiel führt die Kommunikationseinheit 310 eine Kommunikation mit einer entsprechenden Vorrichtung aus. Zum Beispiel führt die Kommunikationseinheit 310 in einem Fall, in dem der MEC-Server 300 als eine logische Einheit gebildet ist und in der Basisstation 100 enthalten ist, eine Kommunikation mit beispielsweise einer Steuereinheit der Basisstation 100 aus. Der MEC-Server 300 kann eine Schnittstelle zum direkten Kommunizieren mit einer anderen Vorrichtung als einer integral ausgebildeten Vorrichtung aufweisen.

Speichereinheit 320

Die Speichereinheit 320 speichert temporär oder permanent ein Programm und verschiedene Daten für den Betrieb des MEC-Servers 300. Zum Beispiel kann die Speichereinheit 320 verschiedene Inhalte und Anwendungen speichern, die dem Benutzer bereitgestellt werden sollen.

Verarbeitungseinheit 330

Die Verarbeitungseinheit 330 stellt verschiedene Funktionen des MEC-Servers 300 bereit. Die Verarbeitungseinheit 330 weist eine Authentifizierungsverarbeitungseinheit 331 und eine Kommunikationsverarbeitungseinheit 333 auf. Des Weiteren kann die Verarbeitungseinheit 330 ferner andere Komponenten als solche Komponenten beinhalten. Mit anderen Worten kann die Verarbeitungseinheit 330 auch andere Arbeitsabläufe als die Arbeitsabläufe solcher Komponenten durchführen.

Die Arbeitsabläufe der Authentifizierungsverarbeitungseinheit 331 und der Kommunikationsverarbeitungseinheit 333 werden nachstehend im Detail beschrieben. Hier, wenngleich nicht in 16 dargestellt, kann die Verarbeitungseinheit 330 eine Inhaltsverarbeitungseinheit aufweisen, die konfiguriert ist, dem UE 200 Inhalte bereitzustellen oder Inhalte von dem UE 200 zu erfassen.

<Konfigurationsbeispiel der EPC-Funktionsentität>

Als Nächstes wird ein Beispiel einer Konfiguration der EPC-Funktionsentität gemäß einer Ausführungsform der vorliegenden Offenbarung unter Bezugnahme auf 17 beschrieben. Die hier beschriebene EPC-Funktionsentität ist beispielsweise eine MME 41 oder ein HSS 42, wobei diese eine ähnliche Konfiguration haben. Natürlich unterscheiden sich die Arbeitsabläufe der Bestandteile zwischen der MME 41 und dem HSS 42. 17 ist ein Blockdiagramm, das ein Beispiel einer Konfiguration von EPC-Funktionsentitäten 41 und 42 gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. Bezugnehmend auf 16 weisen die EPC-Funktionsentitäten 41 und 42 eine Kommunikationseinheit 410, eine Speichereinheit 420 und eine Verarbeitungseinheit 430 auf.

(1) Kommunikationseinheit 410

Die Kommunikationseinheit 410 ist eine Schnittstelle zum Ausführen einer Kommunikation mit anderen Vorrichtungen. Zum Beispiel führt die Kommunikationseinheit 410 eine Kommunikation mit anderen EPC-Funktionsentitäten.

Speichereinheit 420

Die Speichereinheit 420 speichert temporär oder permanent ein Programm und verschiedene Datentypen für einen Betrieb der MME 41 oder des HSS 42.

Verarbeitungseinheit 430

Die Verarbeitungseinheit 430 stellt verschiedene Funktionen der MME 41 oder des HSS 42 bereit. Die Arbeitsabläufe der Verarbeitungseinheit 430 werden nachstehend im Detail beschrieben.

Die Konfigurationsbeispiele der jeweiligen Vorrichtungen wurden oben beschrieben. Im Folgenden wird zur Vereinfachung der Beschreibung die Basisstation 100 auch als „eNodeB 100“ bezeichnet, und das Endgerät 200 wird auch als „UE 200“ bezeichnet.

«3. Erste Ausführungsform »

Die vorliegende Ausführungsform weist eine Form auf, in der eine Authentifizierung unter Verwendung von Authentifizierungsinformationen ausgeführt wird, die in dem MEC-Server 300 gespeichert sind.

<Technisches Problem>

Jede der Entitäten (wie etwa P-GW, S-GW, PCRF, HSS und eNodeB) der EPS wird als eine zuverlässige Entität behandelt, und eine gegenseitige Authentifizierung zwischen diesen Entitäten ist nicht standardisiert. Da das UE andererseits eine Vorrichtung ist, die eine große Anzahl von nicht spezifizierten Benutzern besitzt, ist ein Verfahren der gegenseitigen Authentifizierung mit der MME standardisiert.

In Bezug auf den MEC-Server ist ein Verfahren der gegenseitigen Authentifizierung jedoch nicht standardisiert. Wenngleich angenommen wird, dass der MEC-Server in der Nähe des eNodeB angeordnet ist, sollte er nicht als zuverlässige Entität behandelt werden. Dies beruht darauf, dass der MEC-Server von verschiedenen Dienstanbietern bereitgestellt werden kann. Daher ist es wünschenswert, die Zuverlässigkeit für jeden MEC-Server zu überprüfen.

Daher wird in der vorliegenden Ausführungsform ein Vorgang zum Authentifizieren eines MEC-Servers bereitgestellt.

<Technische Merkmale>(1) Authentifizierungsvorgang

Der MEC-Server 300 führt eine Kommunikation mit einem Netzwerk aus, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem MEC-Server 300 entsprechen, der in dem HSS 42 registriert ist.

Der HSS 42 (beispielsweise die Speichereinheit 420) speichert Authentifizierungsinformationen, die dem MEC-Server 300 entsprechen. In der vorliegenden Ausführungsform sind die Authentifizierungsinformationen, die dem MEC-Server 300 entsprechen, Authentifizierungsinformationen des MEC-Servers 300. Genauer beinhalten die Authentifizierungsinformationen des MEC-Servers 300 eine Nummer (d. h. IMSI), die den MEC-Server 300 identifiziert, und Schlüsselinformationen (d. h. einen Schlüssel K), die für den MEC-Server 300 spezifisch sind. Der HSS 42 speichert eine IMSI für jeden MEC-Server 300 und speichert einen Schlüssel K, der der IMSI des MEC-Servers 300 entspricht. Hier ist eine IMSI in einem MEC-Server 300 registriert. Alternativ kann eine gemeinsame IMSI einer Mehrzahl von MEC-Servern 300 zugewiesen werden. Dann führen die MME 41 (zum Beispiel die Verarbeitungseinheit 430) und der HSS 42 (zum Beispiel die Verarbeitungseinheit 430) verschiedene Prozesse zum Authentifizieren des MEC-Servers 300 aus.

Der MEC-Server 300 (beispielsweise die Speichereinheit 320) speichert Authentifizierungsinformationen des MEC-Servers 300. Dann führt der MEC-Server 300 (beispielsweise die Authentifizierungsverarbeitungseinheit 331) eine Authentifizierung des Netzwerks unter Verwendung der Authentifizierungsinformation des MEC-Servers 300 aus. Das heißt, wie oben mit Bezug auf 12 beschrieben, dass der MEC-Server 300 gemäß der vorliegenden Ausführungsform eine Authentifizierung gemäß einem Mechanismus ausführt, der einem Mechanismus ähnlich ist, bei dem eine Authentifizierung des UE unter Verwendung der gleichen Authentifizierungsinformationen ausgeführt wird, die das UE und der HSS speichern. Dann führt der MEC-Server 300 (beispielsweise die Kommunikationsverarbeitungseinheit 333) eine Kommunikation mit dem authentifizierten Netzwerk aus. Genauer stellt der MEC-Server 300 dem UE 200 Inhalt bereit oder erfasst Inhalt von dem UE 200 über das authentifizierte Netzwerk (zum Beispiel den eNodeB 100 in dem Netzwerk). Auf diese Weise wird der MEC-Server 300 als eine zuverlässige Entität authentifiziert und kann mit dem Netzwerk verbunden werden.

Zum Beispiel kann der MEC-Server 300 Authentifizierungsinformationen in Hardware speichern, wie zum Beispiel ein universelles Teilnehmeridentifikationsmodul (USIM). In diesem Fall ist die Speichereinheit 320 als Hardware wie etwa ein USIM implementiert. Außerdem können Authentifizierungsinformationen in Software realisiert werden, die Funktionen aufweist, die denen der USIM entsprechen. In diesem Fall speichert die Speichereinheit 320 die Software. Zum Beispiel werden die Authentifizierungsinformationen von einem entsprechenden Betreiber einer MEC-Anwendung registriert.

Hier kann der MEC-Server 300 verwendet werden, während Netzwerke einer Mehrzahl von Betreibern (MNO: Mobilfunknetzbetreiber) zwischengeschaltet sind. In diesem Fall können Authentifizierungsinformationen beispielsweise in einem eingebetteten Teilnehmeridentitätsmodul (SIM) gespeichert und in dem MEC-Server 300 bereitgestellt werden. Dementsprechend ist es möglich, die Authentifizierungsinformationen remot umzuschreiben, wobei der MEC-Server 300 arbeiten kann, während Netzwerke einer Mehrzahl von Betreibern zwischengeschaltet sind. In diesem Fall richtet eine Entität, die Authentifizierungsinformationen umschreibt, einen Kommunikationsweg ein, der durch einen Verschlüsselungsprozess mit dem MEC-Server 300 verborgen ist, und ändert dann die Authentifizierungsinformationen.

Der Authentifizierungsvorgang des MEC-Servers 300 ist der gleiche wie oben unter Bezugnahme auf 12 beschriebene, mit der Ausnahme, dass ein Subjekt, das die Authentifizierung ausführt, von dem UE in den MEC-Server 300 geändert wird. Ein Authentifizierungsvorgang gemäß der vorliegenden Ausführungsform wird nachstehend unter Bezugnahme auf 18 beschrieben.

18 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Authentifizierungsvorgangs veranschaulicht, der in dem System 1 gemäß der vorliegenden Ausführungsform ausgeführt wird. Wie in 18 dargestellt, speichert der MEC-Server 300 eine IMSI und einen Schlüssel K. Außerdem speichert der HSS 42 eine IMSI jedes MEC-Servers 300 und einen Schlüssel K, der der IMSI entspricht. Hier kommuniziert der MEC-Server 300 mit der MME 41 über den eNodeB 100.

Zuerst überträgt der MEC-Server 300 eine Anfügungsanfrage zusammen mit der IMSI an die MME 41 (Schritt S102). Als Nächstes überträgt die MME 41 eine Authentifizierungsanfrage zusammen mit der empfangenen IMSI an den HSS 42 (Schritt S104). Als Nächstes generiert der HSS 42 eine Zufallszahl RAND, gibt die Zufallszahl RAND, die empfangene IMSI und den in Verbindung mit der IMSI gespeicherten Schlüssel K in die Authentifizierungsfunktion ein und erhält eine erwartete Antwort RESEXPECTED und einen Schlüssel KASME (Schritt S106). Als Nächstes sendet der HSS 42 den Schlüssel KASME, die erwartete Antwort RESEXPECTED und die Zufallszahl RAND an die MME 41 als Authentifizierungsantwort (Schritt S108). Als Nächstes überträgt die MME 41 die Zufallszahl RAND an den MEC-Server 300 (Schritt S110). Als Nächstes gibt der MEC-Server 300 die empfangene Zufallszahl RAND und die gespeicherte IMSI und den Schlüssel K in die Authentifizierungsfunktion ein und erhält eine Antwort RES und einen Schlüssel KASME (Schritt S112). Als Nächstes überträgt der MEC-Server 300 die Antwort RES an die MME 41 (Schritt S114). Dann vergleicht die MME 41 die erwartete Antwort RESEXPECTED mit einer tatsächlichen Antwort RES und authentifiziert den MEC-Server 300 (Schritt S 116). Insbesondere wenn die erwartete Antwort mit der tatsächlichen Antwort RES übereinstimmt, bestimmt die MME 41, dass das der MEC-Server 300 zuverlässig ist (das heißt, die Authentifizierung ist erfolgreich). Wenn andererseits die erwartete Antwort RESEXPECTED nicht mit der tatsächlichen Antwort RES übereinstimmt, bestimmt die MME 41, dass der MEC-Server 300 nicht zuverlässig ist (das heißt, die Authentifizierung schlägt fehl).

Netzwerkvariation

Wie oben beschrieben, kann der MEC-Server 300 ein Anwendungsserver sein, der innerhalb des EPS bereitgestellt ist.

Alternativ kann der MEC-Server 300 ein Anwendungsserver sein, der in einem LAN (Local Area Network) -Netzwerk bereitgestellt ist. In diesem Fall wird der MEC-Server 300 beispielsweise in einem Zugangspunkt eines drahtlosen LAN bereitgestellt. Dann führt der MEC-Server 300 den AA-Vorgang unter Verwendung der Authentifizierungsinformationen des MEC-Servers 300 durch ein erweitertes Paketdaten-Gateway (ePDG) aus. Hier ist das ePDG eine der Entitäten des EPC und ist mit P-GW verbunden. Typischerweise authentifiziert das ePDG ein drahtloses LAN- Endgerät.

<<Zweite Ausführungsform>>

Die vorliegende Ausführungsform hat eine Form, in der das UE 200 anstelle des MEC-Servers 300 eine Authentifizierung ausführt.

<Technisches Problem>

In der ersten Ausführungsform speichert der MEC-Server 300 Authentifizierungsinformationen davon. Typischerweise legt ein entsprechender Betreiber der MEC-Anwendung die Authentifizierungsinformationen in dem MEC-Server 300 fest. Es ist jedoch nicht einfach, Authentifizierungsinformationen zu ändern, die in dem MEC-Server 300 gespeichert sind, und es ist schwierig, die Authentifizierungsinformationen in dem MEC-Server 300, der neu hinzugefügt wird, sofort festzulegen. Dies beruht darauf, dass das Festlegen von Authentifizierungsinformationen durch Kommunikation unter Berücksichtigung der Vertraulichkeit der Authentifizierungsinformationen (insbesondere eines Schlüssels K) nicht wünschenswert ist. Selbst wenn der MEC-Server 300 von einem entfernten Ort durch Kommunikation aktiviert wird (zum Beispiel startet), ist es wünschenswert, dass der MEC-Server 300 sicherer authentifiziert wird.

Daher wird in der vorliegenden Ausführungsform eine Technologie zur sicheren Ausführung der Authentifizierung des MEC-Servers 300 bereitgestellt.

<Technische Merkmale>

In der vorliegenden Ausführungsform führt das UE 200 (zum Beispiel die Authentifizierungsverarbeitungseinheit 241) anstelle des MEC-Servers 300 eine Authentifizierung aus.

Der HSS 42 (beispielsweise die Speichereinheit 420) speichert Authentifizierungsinformationen, die dem MEC-Server 300 entsprechen. In der vorliegenden Ausführungsform sind die Authentifizierungsinformationen, die dem MEC-Server 300 entsprechen, Authentifizierungsinformationen des UE 200, das dem MEC-Server 300 zugeordnet ist. Insbesondere beinhalten die Authentifizierungsinformationen des UE 200 eine Nummer (d. h. eine IMSI), die das UE 200 identifiziert, und Schlüsselinformationen (d. h. einen Schlüssel K), der für das UE 200 spezifisch ist. Der HSS 42 speichert Identifikationsinformationen des MEC-Servers 300, der dem UE 200 zugeordnet ist. Die Identifikationsinformationen werden nachfolgend auch als MEC-Server-ID bezeichnet. Zum Beispiel speichert der HSS 42 die MEC-Server-ID des MEC-Servers 300, der dem UE 200 zugeordnet ist, als Teilnehmerinformationen des UE 200. Hier ist die MEC-Server-ID keine temporäre ID, sondern Identifikationsinformationen, die für den MEC-Server 300 spezifisch sind.

Das UE 200 (zum Beispiel die Authentifizierungsverarbeitungseinheit 241) führt anstelle des MEC-Servers 300 einen Authentifizierungsvorgang des MEC-Servers 300 aus, der dem UE 200 zugeordnet ist, nachdem der Authentifizierungsvorgang des UE 200 abgeschlossen ist. Insbesondere führt zuerst das UE 200 einen Authentifizierungsvorgang des UE 200 unter Verwendung der IMSI und des Schlüssels K des UE 200 aus. Als Nächstes überträgt das UE 200 eine Anfügungsanfrage des MEC-Servers 300 an die MME 41 oder den eNodeB 100. Während der Übertragung an die MME 41 wird eine NAS-Signalisierung verwendet. Während der Übertragung an den eNodeB 100 wird die RRC-Signalisierung verwendet. Die MEC-Server-ID ist in der Anfügungsanfrage des MEC-Servers 300 enthalten. Die Verbindungsanfrage des MEC-Servers 300 kann als eine Nachricht betrachtet werden, die eine Aktivierung des Ziel-MEC-Servers 300 anfordert.

Wenn die Anfügungsanfrage einschließlich der MEC-Server-ID empfangen wird, prüft der HSS 42 (z. B. die Verarbeitungseinheit 430), ob die MEC-Server-ID in Teilnehmerinformationen, die dem UE 200 entsprechen, als eine Übertragungsquelle der Anfügungsanfrage registriert ist. Dann antwortet der HSS 42 mit einer Anfügungsantwort, die das Prüfergebnis beinhaltet. Wenn die MEC-Server-ID registriert ist, antwortet der HSS 42 mit einer Anfügungsantwort, die eine temporäre ID beinhaltet. Die temporäre ID ist eine ID, die dem MEC-Server 300 zugewiesen ist, dem die Authentifizierung gelungen ist. Die temporäre ID wird im Folgenden auch als temporäre ID des MEC-Servers bezeichnet. Wenn andererseits die MEC-Server-ID nicht registriert ist, antwortet der HSS 42 mit einer Anfügungsantwort, die keine temporäre MEC-Server-ID beinhaltet. In diesem Fall ist es nicht möglich, den MEC-Server 300 mit dem Netzwerk zu verbinden.

Der MEC-Server 300 (z. B. die Kommunikationsverarbeitungseinheit 333) führt eine Kommunikation mit dem Netzwerk unter Verwendung von Informationen (d. h. temporäre MEC-Server-ID) aus, die basierend auf der Anfrage (das heißt, Anfügungsanfrage) von dem UE 200 ausgegeben werden, das dem MEC-Server 300 zugeordnet ist, dem die Authentifizierung des Netzwerks gelungen ist. Das System 1 kann identifizieren, ob der MEC-Server 300 basierend auf den ausgegebenen Informationen authentifiziert wurde, und somit ist Sicherheit gewährleistet. Außerdem ist es in der vorliegenden Ausführungsform möglich, eine Authentifizierung ohne Festlegen von Authentifizierungsinformationen in dem MEC-Server 300 auszuführen, und eine höhere Sicherheit ist gewährleistet.

Der eNodeB 100 und die MME 41 erfassen und speichern die temporäre ID des MEC-Servers, wenn die Anfügungsantwort an das UE 200 übertragen wird, und erlauben den Zugriff durch den MEC-Server 300, der die temporäre ID des MEC-Servers aufweist. Daher kann der MEC-Server 300 mit dem Netzwerk verbunden sein, während die temporäre ID des MEC-Servers gültig ist.

Während vorstehend die Anfügungsanfrage für jeden MEC-Server 300 beschrieben wurde, kann hier ein ähnlicher Authentifizierungsvorgang für jede MEC-Anwendung ausgeführt werden, die in dem MEC-Server 300 arbeitet. Wenn beispielsweise eine neue MEC-Anwendung gestartet wird, kann ein Anfügungsvorgang der MEC-Anwendung ausgeführt werden. In diesem Fall kann die Anfügungsantwort, die die temporäre ID des MEC-Servers beinhaltet, als Startberechtigung der MEC-Anwendung betrachtet werden. Die Anfügungsanfrage, die die MEC-Server-ID beinhaltet, kann als eine Startanfrage der MEC-Anwendung betrachtet werden. Außerdem können die MEC-Server-ID und die temporäre MEC-Server-ID für jede MEC-Anwendung festgelegt werden.

Ein Beispiel eines Flusses eines Authentifizierungsvorgangs, wenn das UE 200 eine Authentifizierung anstelle des MEC-Servers 300 ausführt, wird nachstehend unter Bezugnahme auf 19 beschrieben.

19 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Authentifizierungsvorgangs veranschaulicht, der in dem System 1 gemäß der vorliegenden Ausführungsform ausgeführt wird. Hier kommuniziert das UE 200 mit der MME 41 über den eNodeB 100.

Wie in 19 dargestellt, führt das UE 200 zuerst einen Anfügungsvorgang aus (Schritt S202). In dem Anfügungsvorgang wird der oben unter Bezugnahme auf 12 beschriebene Authentifizierungsvorgang ausgeführt und das UE 200 wird authentifiziert. Als Nächstes überträgt das UE 200 eine Anfügungsanfrage des MEC-Servers 300 an die MME 41 (Schritt S204). Die Anfügungsanfrage weist eine MEC-Server-ID des MEC-Servers 300 auf, der authentifiziert werden soll. Als Nächstes überträgt die MME 41 die empfangene Anfügungsanfrage des MEC-Servers 300 an den HHS 42 (Schritt S206). Als Nächstes antwortet der HSS 42 mit der Anfügungsantwort des MEC-Servers 300 auf die MME 41 (Schritt S208). In diesem Fall prüft der HSS 42, ob die MEC-Server-ID des MEC-Servers 300 in den Teilnehmerinformationen des UE 200 als eine Übertragungsquelle der Anfügungsanfrage registriert ist. Ein Fall, in dem die MEC-Server-ID registriert ist, wird nachstehend beschrieben. Das heißt, die temporäre ID des MEC-Servers ist in der Anfügungsantwort enthalten. Als Nächstes überträgt die MME 41 die empfangene Anfügungsantwort des MEC-Servers 300 an den eNodeB 100 (Schritt S210), und der eNodeB 100 überträgt die empfangene Anfügungsantwort des MEC-Servers 300 an den MEC-Server 300 (Schritt S212). Dann wird der MEC-Server 300 unter Verwendung der temporären MEC-Server-ID, die in der Anfügungsantwort enthalten ist, an das Netzwerk angefügt (Schritt S214).

«5. Dritte Ausführungsform»

Die vorliegende Ausführungsform weist eine Form auf, in der für die Kommunikation durch den MEC-Server 300 verwendete Schlüssel bereitgestellt sind.

<Technisches Problem>

Wenn der Authentifizierungsvorgang gemäß der ersten Ausführungsform oder der zweiten Ausführungsform erfolgreich ist, kann der MEC-Server 300 mit dem Netzwerk verbunden werden und eine Kommunikation ausführen. Daher ist es wie im Fall des UE wünschenswert, dass während der tatsächlichen Kommunikation verwendete Schlüssel (zum Beispiel CK und IK) nach dem Authentifizierungsvorgang generiert werden. Zum Beispiel ist es wünschenswert, dass der IK und der CK, die für die Kommunikation zwischen der MEC-Anwendung und der MME 41 verwendet werden, und die Kommunikation zwischen der MEC-Anwendung und dem UE 200 generiert werden.

Eine Technologie zum Generieren und Verteilen von Schlüsseln, die für die Kommunikation von dem MEC-Server 300 verwendet werden, ist jedoch nicht bereitgestellt.

<Technische Merkmale>(1) Schlüssel zur Kommunikation zwischen MEC-Anwendung und MME 41

Schlüssel (d. h. CK und IK) zur Kommunikation zwischen der MEC-Anwendung und der MME 41 werden verwendet, die für jede MEC-Anwendung unterschiedlich sind.

In der ersten Ausführungsform werden Schlüssel zur Kommunikation zwischen der MEC-Anwendung und der MME 41 basierend auf Authentifizierungsinformationen (d. h. der IMSI und des Schlüssels K des MEC-Servers 300) des MEC-Servers 300 generiert. Insbesondere wird zuerst in dem Anfügungsvorgang des MEC-Servers 300 ein Schlüssel KASME unter Verwendung von Authentifizierungsinformationen des MEC-Servers 300 generiert. Dann werden Schlüssel (d. h. CK und IK) zur Kommunikation zwischen der MEC-Anwendung und der MME 41 auf der Basis des Schlüssels KASME generiert. Der CK und der IK werden zusammen als ein Schlüssel KMECApplication-MME bezeichnet. Das heißt, der Schlüssel KMEC Application-MME beinhaltet CK und IK.

In der zweiten Ausführungsform werden Schlüssel zur Kommunikation zwischen der MEC-Anwendung und der MME 41 auf der Basis von Authentifizierungsinformationen (das heißt der IMSI und des Schlüssels K des UE 200) des UE 200 generiert, das dem MEC-Server 300 zugeordnet ist. Insbesondere wird zuerst in dem Anfügungsvorgang des UE 200 ein Schlüssel KASME unter Verwendung der Authentifizierungsinformationen des UE 200 generiert. Dann wird eine Schlüssel KMECApplication-MME zur Kommunikation zwischen der MEC-Anwendung und der MME 41 auf der Basis des Schlüssels KASME generiert, der unter Verwendung der Authentifizierungsinformationen des UE 200 generiert wird. Hier wird die MME 41 über den Schlüssel KASME in dem Anfügungsvorgang des UE 200 von dem HSS 42 benachrichtigt (Schritt S54, der in 12 dargestellt ist). Da jedoch der Anfügungsvorgang des UE 200 und der Anfügungsvorgang des MEC-Servers 300 separate Vorgänge sind, ist es nicht wünschenswert, dass eine Schlüssel KMECApplication-MME zu einem Zeitpunkt generiert wird, zu dem der Schlüssel KASME in dem Anfügungsvorgang des UE 200 generiert wird. Daher speichert die MME 41 (beispielsweise die Speichereinheit 420) den Schlüssel KASME. Wenn dann die Authentifizierung des MEC-Servers 300 erfolgreich ist, generiert die MME 41 (zum Beispiel die Verarbeitungseinheit 430) eine Schlüssel KMECApplication-MME basierend auf dem gespeicherten Schlüssel KASME und benachrichtigt den MEC-Server 300 über den generierten Schlüssel KMEC Application-MME.

Ein Systemdiagramm von Schlüsseln, die sich auf den Schlüssel KMECApplication-MME beziehen, ist in 20 dargestellt. Wie in 20 dargestellt, wird eine Schlüssel KMEC Application-MME auf der Basis von KASME des UE 200 generiert, das den Anfügungsvorgang des MEC-Servers 300 ausgeführt hat.

Schlüssel zur Kommunikation zwischen der MEC-Anwendung und dem UE 200

Schlüssel (d. h. CK und IK) zur Kommunikation zwischen der MEC-Anwendung und dem UE 200 werden verwendet, die für jedes UE 200 unterschiedlich sind. Dies beruht darauf, dass eine Mehrzahl von 00s mit einem MEC-Server 300 verbunden werden kann.

Zum Beispiel werden Schlüssel zur Kommunikation zwischen der MEC-Anwendung und dem UE 200 auf der Basis von Authentifizierungsinformationen (d. h. der IMSI und des Schlüssels K des UE 200) des UE 200 generiert. Insbesondere wird zuerst in dem Anfügungsvorgang des UE 200 ein Schlüssel KASME unter Verwendung der Authentifizierungsinformationen des UE 200 generiert. Dann wird ein Schlüssel KeNodeB auf der Basis des Schlüssels KASME generiert, und der CK und der IK zur Kommunikation zwischen der MEC-Anwendung und dem UE 200 werden auf der Basis des Schlüssels KeNodeB generiert. Der CK und der IK werden zusammen als eine Schlüssel KUE-MECApplication bezeichnet. Das heißt, der Schlüssel KUE-MECApplication beinhaltet den CK und den IK. Hier können in Bezug auf MEC-Anwendungen, die in dem gleichen MEC-Server 300 betrieben werden, der gleiche Schlüssel KUE-MECApplication oder verschiedene Schlüssel KUE-MECApplication unter der Mehrzahl von MEC-Anwendungen verwendet werden.

Ein Systemdiagramm von Schlüsseln, die sich auf den Schlüssel KUE-MECApplication beziehen, ist in 21 dargestellt. Wie in 21 dargestellt, wird ein Schlüssel KeNodeB auf der Basis des Schlüssels KASME generiert, der in dem Anfügungsvorgang des UE 200 generiert wird, und ein Schlüssel KUE-MECApplication wird auf der Basis des Schlüssels KeNodeB generiert.

Merkmale der Schlüssel zwischen der MEC-Anwendung und der MME 41 und der Schlüssel zwischen der MEC-Anwendung und der MME 41, die oben beschrieben wurden, sind in der folgenden Tabelle 3 dargestellt. [Tabelle 3]

GenerierungszeitpunktEinordnung der SchlüsseltrennungSchlüssel zwischen MEC-Anwendung und MMENach dem Anfügungsvorgang der MEC-AnwendungVerwendung unterschiedlicher Schlüssel für jede MEC-AnwendungSchlüssel zwischen MEC-Anwendung und UENach dem Anfügungsvorgang des UEEs ist auch möglich, den gleichen Schlüssel für MEC-Anwendungen zu verwenden, die auf demselben MEC-Server betrieben werden.

<<Vierte Ausführungsform>>

Die vorliegende Ausführungsform weist eine Form auf, in der andere mit dem MEC-Server 300 in Beziehung stehende Entitäten authentifiziert sind.

<Technisches Problem>

Die Gegenwart eines entsprechenden Operators, der dem MEC-Server Inhalt wie ein Video und eine Anwendung bereitstellt, wird vorausgesetzt. Ferner wird die Gegenwart eines Inhaltsservers zum Bereitstellen von Inhalt dem MEC-Server vorausgesetzt. Ein solcher Inhaltsserver wird im Folgenden auch als Over-the-Top-Server (OTT) bezeichnet.

Ein Beispiel, in dem ein OTT-Server vorhanden ist, ist in 22 und 23 dargestellt. In dem Beispiel, das in 22 dargestellt ist, ist ein OTT-Server 500 innerhalb des EPC angeordnet. In dem Beispiel, das in 23 dargestellt ist, ist der OTT-Server 500 außerhalb des EPC angeordnet. Wenn der OTT-Server 500 außerhalb des EPC angeordnet ist, kann der OTT-Server 500 direkt mit dem MEC-Server 300 verbunden sein und kann über ein P-GW 44, ein S-GW 43 und dergleichen verbunden sein.

Unabhängig davon, welches Anordnungsbeispiel verwendet wird, ist es wie beim MEC-Server 300 wünschenswert, dass die Zuverlässigkeit des OTT-Servers 500 überprüft wird.

Daher wird in der vorliegenden Ausführungsform ein Vorgang zum Authentifizieren des OTT-Servers 500 bereitgestellt.

<Konfigurationsbeispiel des OTT-Servers>

Als Nächstes wird ein Beispiel für eine Konfiguration des OTT-Servers 500 gemäß einer Ausführungsform der vorliegenden Offenbarung unter Bezugnahme auf 24 beschrieben. 24 ist ein Blockdiagramm, das ein Beispiel für eine Konfiguration des OTT-Servers 500 gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. Unter Bezugnahme auf 24 weist der OTT-Server 500 eine Kommunikationseinheit 510, eine Speichereinheit 520 und eine Verarbeitungseinheit 530 auf.

(1) Kommunikationseinheit 510

Die Kommunikationseinheit 510 ist eine Schnittstelle zum Ausführen einer Kommunikation mit anderen Vorrichtungen. Zum Beispiel kommuniziert die Kommunikationseinheit 510 direkt mit dem MEC-Server 300 oder kommuniziert indirekt mit dem MEC-Server 300 über das P-GW 44, das S-GW 43 und dergleichen.

Speichereinheit 520

Die Speichereinheit 520 speichert temporär oder permanent ein Programm und verschiedene Arten von Daten für einen Arbeitsablauf des OTT-Servers 500. Zum Beispiel kann die Speichereinheit 520 verschiedene Arten von Inhalt und Anwendungen speichern, die dem MEC-Server 300 bereitgestellt werden.

Verarbeitungseinheit 530

Die Verarbeitungseinheit 530 stellt verschiedene Funktionen des OTT-Servers 500 bereit. Die Verarbeitungseinheit 530 weist eine Authentifizierungsverarbeitungseinheit 531 und eine Kommunikationsverarbeitungseinheit 533 auf. Hier kann die Verarbeitungseinheit 530 ferner andere Bestandteile als diese Bestandteile aufweisen. Das heißt, die Verarbeitungseinheit 530 kann neben den Arbeitsabläufen dieser Bestandteile auch andere Arbeitsabläufe ausführen.

Die Authentifizierungsverarbeitungseinheit 531 und die Kommunikationsverarbeitungseinheit 533 haben ähnliche Funktionen wie die oben beschriebene Authentifizierungsverarbeitungseinheit 331 und die Kommunikationsverarbeitungseinheit 333. Wenngleich in 24 nicht dargestellt, kann die Verarbeitungseinheit 530 eine Inhaltsverarbeitungseinheit aufweisen, die konfiguriert ist, dem MEC-Server 300 Inhalt bereitzustellen.

<Technische Merkmale>

Technische Merkmale, die in verschiedenen Fällen vorausgesetzt werden, werden in der folgenden Reihenfolge beschrieben.

(1) Erster Fall

Der vorliegende Fall ist ein Fall, in dem der OTT-Server 500 innerhalb des EPC angeordnet ist und der OTT-Server 500 als eine zuverlässige Entität behandelt wird. Im vorliegenden Fall ist ein Authentifizierungsvorgang zur Überprüfung der Zuverlässigkeit des OTT-Servers 500 wiederum nicht erforderlich. Natürlich kann auch in diesem Fall ein Authentifizierungsvorgang zum Überprüfen der Zuverlässigkeit des OTT-Servers 500 ausgeführt werden.

Zweiter Fall

Der vorliegende Fall ist ein Fall, in dem der OTT-Server 500 außerhalb des EPC angeordnet ist oder der OTT-Server 500 innerhalb des EPC angeordnet ist, jedoch als eine unzuverlässige Entität behandelt wird. In diesem Fall kann der OTT-Server 500 durch einen Authentifizierungsvorgang authentifiziert werden, der dem des MEC-Servers 300 in der ersten Ausführungsform ähnlich ist.

Der OTT-Server 500 weist ähnliche technische Merkmale wie der MEC-Server 300 gemäß der ersten Ausführungsform auf. Entitäten wie die MME 41 und der HSS 42 weisen die gleichen technischen Merkmale wie in der ersten Ausführungsform auf, mit der Ausnahme, dass ein zu authentifizierendes Ziel von dem MEC-Server 300 in den OTT-Server 500 geändert wird. Das heißt, die technischen Merkmale des vorliegenden Falles entsprechen Merkmalen, in denen der MEC-Server 300 durch den OTT-Server 500 in der Beschreibung der ersten Ausführungsform ersetzt ist.

Der HSS 42 (beispielsweise die Speichereinheit 420) speichert Authentifizierungsinformationen, die dem OTT-Server 500 entsprechen. Im vorliegenden Fall sind die Authentifizierungsinformationen, die dem OTT-Server 500 entsprechen, Authentifizierungsinformationen des OTT-Servers 500. Genauer beinhalten die Authentifizierungsinformationen des OTT-Servers 500 eine Nummer (d. h. IMSI), die den OTT-Server 500 identifiziert, und Schlüsselinformationen (d. h. einen Schlüssel K), die für den OTT-Server 500 spezifisch sind. Andererseits speichert der OTT-Server 500 (beispielsweise die Speichereinheit 520) auch Authentifizierungsinformationen des OTT-Servers 500. Dann führt der OTT-Server 500 (beispielsweise die Authentifizierungsverarbeitungseinheit 531) eine Authentifizierung des Netzwerks unter Verwendung der Authentifizierungsinformation des OTT-Servers 500 aus. Der OTT-Server 500 (beispielsweise die Kommunikationsverarbeitungseinheit 533) führt eine Kommunikation mit dem authentifizierten Netzwerk aus. Genauer stellt der OTT-Server 500 dem MEC-Server 300 Inhalt über das authentifizierte Netzwerk (zum Beispiel den eNodeB 100 in dem Netzwerk) bereit. Auf diese Weise wird der OTT-Server 500 als eine zuverlässige Entität authentifiziert und kann mit dem Netzwerk verbunden werden.

Der Authentifizierungsvorgang des OTT-Servers 500 ist der gleiche wie oben unter Bezugnahme auf 18 beschriebene, mit der Ausnahme, dass ein Subjekt, das die Authentifizierung ausführt, von dem MEC-Server 300 in den OTT-Server 500 geändert wird. Ein Authentifizierungsvorgang gemäß dem vorliegenden Fall wird nachstehend unter Bezugnahme auf 25 beschrieben.

25 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Authentifizierungsvorgangs veranschaulicht, der in dem System 1 gemäß der vorliegenden Ausführungsform ausgeführt wird. Wie in 25 dargestellt, speichert der OTT-Server 500 die IMSI und den Schlüssel K. Außerdem speichert der HSS 42 den Schlüssel K, der der IMSI des OTT-Servers 500 entspricht. Hier kommuniziert der OTT-Server 500 mit der MME 41 über den eNodeB 100.

Zuerst überträgt der OTT-Server 500 eine Anfügungsanfrage zusammen mit der IMSI an die MME 41 (Schritt S302). Als Nächstes überträgt die MME 41 eine Authentifizierungsanfrage zusammen mit der empfangenen IMSI an den HSS 42 (Schritt S304). Als Nächstes generiert der HSS 42 eine Zufallszahl RAND, gibt die Zufallszahl RAND, die empfangene IMSI und den in Verbindung mit der IMSI gespeicherten Schlüssel K in die Authentifizierungsfunktion ein und erhält eine erwartete Antwort RESEXPECTED und einen Schlüssel KASME (Schritt S306). Als Nächstes sendet der HSS 42 den Schlüssel KASME, die erwartete Antwort RESEXPECTED und die Zufallszahl RAND an die MME 41 als Authentifizierungsantwort (Schritt S308). Als Nächstes überträgt die MME 41 die Zufallszahl RAND an den OTT-Server 500 (Schritt S310). Als Nächstes gibt der OTT-Server 500 die empfangene Zufallszahl RAND und die gespeicherte IMSI und den Schlüssel K in die Authentifizierungsfunktion ein und erhält eine Antwort RES und einen Schlüssel KASME (Schritt S312). Als Nächstes überträgt der OTT-Server 500 die Antwort RES an die MME 41 (Schritt S314). Dann vergleicht die MME 41 die erwartete Antwort RESEXPECTED mit der tatsächlichen Antwort RES und authentifiziert den OTT-Server 500 (Schritt S316). Insbesondere wenn die erwartete Antwort mit der tatsächlichen Antwort RES übereinstimmt, bestimmt die MME 41, dass das der OTT-Server 500 zuverlässig ist (das heißt, die Authentifizierung ist erfolgreich). Wenn andererseits die erwartete Antwort RESEXPECTED nicht mit der tatsächlichen Antwort RES übereinstimmt, bestimmt die MME 41, dass der OTT-Server 500 nicht zuverlässig ist (das heißt, die Authentifizierung schlägt fehl).

Als ein modifiziertes Beispiel des vorliegenden Falls wird ein Fall betrachtet, in dem der OTT-Server 500 direkt mit der MME 41 verbunden ist. Ein Anordnungsbeispiel des OTT-Servers 500 in diesem Fall ist in 26 dargestellt. In dem Beispiel, das in 26 dargestellt ist, ist der OTT-Server 500 innerhalb des EPC angeordnet und direkt mit der MME 41 verbunden. Der Authentifizierungsvorgang ist in diesem Fall der gleiche wie derjenige, der oben unter Bezugnahme auf 25 beschrieben wurde, außer dass der OTT-Server 500 und die MME 41 eine Kommunikation über keinen eNodeB 100 ausführen. Ein Authentifizierungsvorgang gemäß dem vorliegenden Fall wird nachstehend unter Bezugnahme auf 27 beschrieben.

27 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Authentifizierungsvorgangs veranschaulicht, der in dem System 1 gemäß der vorliegenden Ausführungsform ausgeführt wird. Wie in 27 dargestellt, speichert der OTT-Server 500 die IMSI und den Schlüssel K. Außerdem speichert der HSS 42 den Schlüssel K, der der IMSI des OTT-Servers 500 entspricht. Hier kommuniziert der OTT-Server 500 mit der MME 41 über keinen eNodeB 100.

Zuerst überträgt der OTT-Server 500 eine Anfügungsanfrage zusammen mit der IMSI an die MME 41 (Schritt S402). Als Nächstes überträgt die MME 41 eine Authentifizierungsanfrage zusammen mit der empfangenen IMSI an den HSS 42 (Schritt S404). Als Nächstes generiert der HSS 42 eine Zufallszahl RAND, gibt die Zufallszahl RAND, die empfangene IMSI und den in Verbindung mit der IMSI gespeicherten Schlüssel K in die Authentifizierungsfunktion ein und erhält eine erwartete Antwort RESEXPECTED und einen Schlüssel KASME (Schritt S406). Als Nächstes sendet der HSS 42 den Schlüssel KASME, die erwartete Antwort RESEXPECTED und die Zufallszahl RAND an die MME 41 als Authentifizierungsantwort (Schritt S408). Als Nächstes überträgt die MME 41 die Zufallszahl RAND an den OTT-Server 500 (Schritt S410). Als Nächstes gibt der OTT-Server 500 die empfangene Zufallszahl RAND und die gespeicherte IMSI und den Schlüssel K in die Authentifizierungsfunktion ein und erhält eine Antwort RES und einen Schlüssel KASME (Schritt S412). Als Nächstes überträgt der OTT-Server 500 die Antwort RES an die MME 41 (Schritt S414). Dann vergleicht die MME 41 die erwartete Antwort RESEXPECTED mit einer tatsächlichen Antwort RES und authentifiziert den OTT-Server 500 (Schritt S416). Insbesondere wenn die erwartete Antwort mit der tatsächlichen Antwort RES übereinstimmt, bestimmt die MME 41, dass das der OTT-Server 500 zuverlässig ist (das heißt, die Authentifizierung ist erfolgreich). Wenn andererseits die erwartete Antwort RESEXPECTED nicht mit der tatsächlichen Antwort RES übereinstimmt, bestimmt die MME 41, dass der OTT-Server 500 nicht zuverlässig ist (das heißt, die Authentifizierung schlägt fehl).

Im vorliegenden Fall und dem modifizierten Beispiel werden Schlüssel zur Kommunikation zwischen dem OTT-Server 500 und der MME 41 und Schlüssel zur Kommunikation zwischen dem OTT-Server 500 und der MEC-Anwendung auf der Basis der Authentifizierungsinformationen des OTT-Servers 500 generiert. Insbesondere wird zuerst in dem Anfügungsvorgang des OTT-Servers 500 ein Schlüssel KASME unter Verwendung von Authentifizierungsinformationen des OTT-Servers 500 generiert. Dann werden Schlüssel zur Kommunikation zwischen dem OTT-Server 500 und der MME 41 und Schlüssel zur Kommunikation zwischen dem OTT-Server 500 und der MEC-Anwendung auf der Basis des Schlüssels KASME generiert. Der erstgenannte Schlüssel wird als Schlüssel KOTTServer-MME bezeichnet und der letztgenannte Schlüssel wird als Schlüssel KOTTServer-MECApplication bezeichnet. Das heißt, der Schlüssel KOTTServer-MME beinhaltet CK und IK. Das heißt, der Schlüssel KOTTServer-MECApplication beinhaltet CK und IK. Ein Systemdiagramm dieser Schlüssel ist in 28 dargestellt. Wie in 28 dargestellt, werden ein Schlüssel KOTTServer-MME und ein Schlüssel KOTTServer-MECApplication auf der Basis des KASME generiert, der in dem Anfügungsvorgang des OTT-Servers 500 generiert wird.

Dritter Fall

Der vorliegende Fall ist ein Fall, in dem das UE 200 anstelle des OTT-Servers 500 eine Authentifizierung ausführt.

Der OTT-Server 500 weist ähnliche technische Merkmale wie der MEC-Server 300 gemäß der zweiten Ausführungsform auf. Entitäten wie das UE 200, die MME 41 und der HSS 42 weisen die gleichen technischen Merkmale wie in der zweiten Ausführungsform auf, mit der Ausnahme, dass ein zu authentifizierendes Ziel von dem MEC-Server 300 in den OTT-Server 500 geändert wird. Das heißt, die technischen Merkmale des vorliegenden Falles entsprechen Merkmalen, in denen der MEC-Server 300 durch den OTT-Server 500 in der Beschreibung der zweiten Ausführungsform ersetzt ist.

Der HSS 42 (beispielsweise die Speichereinheit 420) speichert Authentifizierungsinformationen, die dem OTT-Server 500 entsprechen. Im vorliegenden Fall sind die Authentifizierungsinformationen, die dem OTT-Server 500 entsprechen, Authentifizierungsinformationen des UE 200, das dem MEC-Server 500 zugeordnet ist. Das UE 200 (zum Beispiel die Authentifizierungsverarbeitungseinheit 241) führt anstelle des OTT -Servers 500 eine Authentifizierung aus. Der OTT-Server 500 (z. B. die Kommunikationsverarbeitungseinheit 533) führt eine Kommunikation mit dem Netzwerk unter Verwendung von Informationen aus, die basierend auf der Anfrage (das heißt, Anfügungsanfrage) von dem UE 200 ausgegeben werden, das dem OTT-Server 500 zugeordnet ist, dem die Authentifizierung des Netzwerks gelungen ist. Hier werden Identifikationsinformationen, die spezifisch für den OTT-Server 500 sind und der MEC-Server-ID in der zweiten Ausführungsform entsprechen, nachstehend auch als eine OTT-Server-ID bezeichnet. Außerdem werden Informationen, die auf der Basis der Anfrage von dem UE 200 ausgegeben werden, wenn die Authentifizierung des Netzwerks erfolgreich war, und die der temporären ID des MEC-Servers in der zweiten Ausführungsform entsprechen, im Folgenden auch als temporäre OTT-Server-ID bezeichnet.

Ein Beispiel eines Flusses eines Authentifizierungsvorgangs, wenn das UE 200 eine Authentifizierung anstelle des OTT-Servers 500 ausführt, wird nachstehend unter Bezugnahme auf 29 beschrieben.

29 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Authentifizierungsvorgangs veranschaulicht, der in dem System 1 gemäß der vorliegenden Ausführungsform ausgeführt wird. Hier kommuniziert das UE 200 mit der MME 41 über den eNodeB 100.

Wie in 29 dargestellt, führt das UE 200 zuerst einen Anfügungsvorgang aus (Schritt S202). In dem Anfügungsvorgang wird der oben unter Bezugnahme auf 12 beschriebene Authentifizierungsvorgang ausgeführt. Als Nächstes überträgt das UE 200 eine Anfügungsanfrage des OTT-Servers 500 an die MME 41 (Schritt S204). Die Anfügungsanfrage weist eine OTT-Server-ID auf, die Identifizierrungsinformationen sind, die für den OTT-Server 500 spezifisch sind, der authentifiziert werden soll. Als Nächstes überträgt die MME 41 die empfangene Anfügungsanfrage des OTT-Servers 500 an den HHS 42 (Schritt S506). Als Nächstes antwortet der HSS 42 mit der Anfügungsantwort des OTT-Servers 500 auf die MME 41 (Schritt S508). In diesem Fall prüft der HSS 42, ob die OTT-Server-ID des OTT-Servers 500 in den Teilnehmerinformationen des UE 200 als eine Übertragungsquelle der Anfügungsanfrage registriert ist. Ein Fall, in dem die OTT-Server-ID registriert ist, wird nachstehend beschrieben. Das heißt, die temporäre ID des OTT-Servers ist in der Anfügungsantwort enthalten. Als Nächstes überträgt die MME 41 die empfangene Anfügungsantwort des OTT-Servers 500 an den eNodeB 100 (Schritt S510), und der eNodeB 100 überträgt die empfangene Anfügungsantwort des OTT-Servers 500 an den MEC-Server 500 (Schritt S512). Dann wird der OTT-Server 500 unter Verwendung der temporären OTT-Server-ID, die in der Anfügungsantwort enthalten ist, an das Netzwerk angefügt (Schritt S514).

Im vorliegenden Fall werden Schlüssel für die Kommunikation zwischen dem OTT-Server 500 und der MME 41 und Schlüssel für die Kommunikation zwischen dem OTT-Server 500 und der MEC-Anwendung auf der Basis der Authentifizierungsinformationen des UE 200 generiert. Insbesondere wird zuerst in dem Anfügungsvorgang des UE 200 ein Schlüssel KASME unter Verwendung der Authentifizierungsinformationen des UE 200 generiert. Dann werden ein Schlüssel KOTTServer-MME zur Kommunikation zwischen dem OTT-Server 500 und der MME 41 und eine Schlüssel KOTTServer-MECApplication zur Kommunikation zwischen dem OTT-Server 500 und der MEC-Anwendung auf der Basis des Schlüssel-KASME generiert. Ein Systemdiagramm dieser Schlüssel ist in 30 dargestellt. Wie in 30 dargestellt, werden ein Schlüssel KOTTServer-MME und ein Schlüssel KOTTServer-MECApplication auf der Basis von KASME des UE 200 generiert, das den Anfügungsvorgang des OTT-Servers 500 ausgeführt hat.

Vierter Fall

Der vorliegende Fall ist ein Fall, in dem der OTT-Server 500 anstelle des MEC-Servers 300 eine Authentifizierung ausführt. Der OTT-Server 500 weist ähnliche technische Merkmale wie das UE 200 gemäß der zweiten Ausführungsform auf. Entitäten wie der MEC-Server 300, die MME 41 und der HSS 42 weisen die gleichen technischen Merkmale wie in der zweiten Ausführungsform auf, mit der Ausnahme, dass der Authentifizierungsvorgang unter Verwendung der Authentifizierungsinformationen des UE 200 in einen Authentifizierungsvorgang unter Verwendung von Authentifizierungsinformationen des OTT-Servers 500 geändert wird. Das heißt, die technischen Merkmale des vorliegenden Falles entsprechen Merkmalen, in denen das UE 200 durch den OTT-Server 500 in der Beschreibung der zweiten Ausführungsform ersetzt ist.

Der HSS 42 (beispielsweise die Speichereinheit 420) speichert Authentifizierungsinformationen, die dem MEC-Server 300 entsprechen. Im vorliegenden Fall sind die Authentifizierungsinformationen, die dem MEC-Server 300 entsprechen, Authentifizierungsinformationen des OTT-Servers 500, der dem MEC-Server 300 zugeordnet ist. Insbesondere speichert der HSS 42 (zum Beispiel die Speichereinheit 420) Identifikationsinformationen des MEC-Servers 300, der dem OTT-Server 500 zugeordnet ist, d. h. die MEC-Server-ID. Zum Beispiel speichert der HSS 42 die MEC-Server-ID des MEC-Servers 300, der dem OTT-Server 500 zugeordnet ist, als Teilnehmerinformationen des OTT-Servers 500.

Danach führt der OTT-Server 500 (zum Beispiel die Authentifizierungsverarbeitungseinheit 531) anstelle des MEC-Servers 300 eine Authentifizierung aus. Der MEC-Server 300 (z. B. die Kommunikationsverarbeitungseinheit 333) führt eine Kommunikation mit dem Netzwerk unter Verwendung von Informationen (d. h. temporäre MEC-Server-ID) aus, die basierend auf der Anfrage (das heißt, Anfügungsanfrage) von dem OTT-Server 500 ausgegeben werden, das dem MEC-Server 300 zugeordnet ist, dem die Authentifizierung des Netzwerks gelungen ist. Das System 1 kann identifizieren, ob der MEC-Server 300 basierend auf den ausgegebenen Informationen authentifiziert wurde, und somit ist Sicherheit gewährleistet.

Hier wird ein Fall in Betracht gezogen, in dem der OTT-Server 500 selbst keine Authentifizierungsinformationen aufweist und das UE 200 anstelle des OTT-Servers 500 eine Authentifizierung ausführt, wie oben unter Bezugnahme auf 29 beschrieben. In diesem Fall können die Authentifizierungsinformationen, die zur Authentifizierung des MEC-Servers 300 an das Netzwerk verwendet werden, Authentifizierungsinformationen des UE 200 sein, das anstelle des OTT-Servers 500 eine Authentifizierung durchführt, der das UE 200 ist, das dem MEC-Server 300 zugeordnet ist. In diesem Fall speichert der HSS 42 (beispielsweise die Speichereinheit 420) beispielsweise die OTT-Server-ID und die MEC-Server-ID als Teilnehmeridentifikationsinformationen des UE 200.

Ein Beispiel eines Flusses eines Authentifizierungsvorgangs, wenn der OTT-Server 500 anstelle des MEC-Servers 300 eine Authentifizierung ausführt, wird nachstehend unter Bezugnahme auf 31 beschrieben.

31 ist ein Sequenzdiagramm, das ein Beispiel eines Flusses eines Authentifizierungsvorgangs veranschaulicht, der in dem System 1 gemäß der vorliegenden Ausführungsform ausgeführt wird. Hier kommuniziert der OTT-Server 500 mit der MME 41 über den eNodeB 100.

Wie in 31 dargestellt, führt das UE 500 zuerst einen Anfügungsvorgang aus (Schritt S602). In dem Anfügungsvorgang wird der oben unter Bezugnahme auf 27 oder 29 beschriebene Authentifizierungsvorgang ausgeführt und der OTT-Server 500 wird authentifiziert. Als Nächstes überträgt der OTT-Server 500 eine Anfügungsanfrage des MEC-Servers 300 an die MME 41 (Schritt S604). Die Anfügungsanfrage weist eine MEC-Server-ID des MEC-Servers 300 auf, der authentifiziert werden soll. Als Nächstes überträgt die MME 41 die empfangene Anfügungsanfrage des MEC-Servers 300 an den HHS 42 (Schritt S606). Als Nächstes antwortet der HSS 42 mit der Anfügungsantwort des MEC-Servers 300 auf die MME 41 (Schritt S608). In diesem Fall prüft der HSS 42, ob die MEC-Server-ID des MEC-Servers 300 in den Teilnehmerinformationen des OTT-Servers 500 als eine Übertragungsquelle der Anfügungsanfrage registriert ist, oder das UE 200 eine Authentifizierung anstelle des OTT-Servers 500 ausführt. Ein Fall, in dem die MEC-Server-ID registriert ist, wird nachstehend beschrieben. Das heißt, die temporäre ID des MEC-Servers ist in der Anfügungsantwort enthalten. Als Nächstes überträgt die MME 41 die empfangene Anfügungsantwort des MEC-Servers 300 an den eNodeB 100 (Schritt S610), und der eNodeB 100 überträgt die empfangene Anfügungsantwort des MEC-Servers 300 (Schritt S612). Dann wird der MEC-Server 300 unter Verwendung der temporären MEC-Server-ID, die in der Anfügungsantwort enthalten ist, an das Netzwerk angefügt (Schritt S614).

<<Anwendungsbeispiele>>

Die Technologie gemäß der vorliegenden Offenbarung kann auf verschiedene Produkte angewendet werden. Zum Beispiel können der MEC-Server 300, die MME 41, der HSS 42 oder der OTT-Server 500 als ein Server eines beliebigen Typs wie beispielsweise ein Tower-Server, ein Rack-Server, ein Blade- Server oder dergleichen realisiert sein. Außerdem kann mindestens ein Teil der Bestandteile des MEC-Servers 300, der MME 41, des HSS 42 oder des OTT-Servers 500 in einem Modul realisiert sein, das in einem Server (z. B. einem integrierten Schaltungsmodul, das in einem Chip, einer Karte oder einem Blade konfiguriert ist, der in einen Schlitz eines Blade-Servers eingesetzt ist) montiert ist.

Darüber hinaus kann das Endgerät 200 beispielsweise als ein mobiles Endgerät wie ein Smartphone, ein Tablet-Personalcomputer (PC), ein Notebook-PC, ein tragbares Spieleendgerät, ein tragbarer/dongleartiger mobiler Router oder eine Digitalkamera oder ein fahrzeuginternes Endgerät, wie eine Fahrzeugnavigationsvorrichtung oder dergleichen realisiert sein. Zusätzlich kann das Endgerät 200 als ein Endgerät realisiert sein, das eine Maschine-zu-Maschine-(M2M-) Kommunikation durchführt (auch als Maschinenkommunikationstyp (MTC- ) -Endgerät bezeichnet). Ferner kann mindestens ein Teil der Bestandteile des Endgeräts 200 in einem Modul realisiert sein, das in einem solchen Endgerät montiert ist (zum Beispiel ein in einem Chip konfiguriertes IC-Modul).

<Anwendungsbeispiel in Bezug auf Server>

32 ist ein Blockdiagramm, das ein Beispiel für eine schematische Konfiguration eines Servers 700 zeigt, auf den die Technologie der vorliegenden Offenbarung angewandt werden kann. Der Server 700 weist einen Prozessor 701, einen Hauptspeicher 702, einen Speicher 703, eine Netzwerkschnittstelle 704 und einen Bus 706 auf.

Der Prozessor 701 kann beispielsweise eine zentrale Verarbeitungseinheit (CPU) oder ein digitaler Signalprozessor (DSP) sein und verschiedene Funktionen des Servers 700 steuern. Der Hauptspeicher 702 schließt einen wahlfreien Zugangs speicher (RAM) und einen Nurlesespeicher (ROM) ein und speichert Programme, die vom Prozessor 701 ausgeführt werden, und Daten. Der Speicher 703 kann ein Speichermedium, wie etwa einen Halbleiterspeicher oder eine Festplatte, beinhalten.

Die Netzwerkschnittstelle 704 ist eine drahtgebundene Kommunikationsschnittstelle zum Verbinden des drahtlosen Zugangspunktes 700 mit einem drahtgebundenen Kommunikationsnetz 705. Das verdrahtete Kommunikationsnetzwerk 705 kann ein Kernnetzwerk wie etwa ein Evolved Packet Core (EPC) oder ein Paketdatennetzwerk (PDN) wie das Internet sein.

Der Bus 706 verbindet den Prozessor 701, den Hauptspeicher 702, den Speicher 703 und die Netzwerkschnittstelle 704 miteinander. Der Bus 706 kann zwei oder mehr Busse aufweisen, die mit unterschiedlichen Geschwindigkeiten arbeiten (z. B. ein Hochgeschwindigkeitsbus und ein Niedergeschwindigkeitsbus).

In dem Server 700, der in 32 dargestellt ist, können ein oder mehrere Bestandteile (die Authentifizierungsverarbeitungseinheit 331 und/oder die Kommunikationsverarbeitungseinheit 333), die in dem MEC-Server 300 enthalten sind, der mit Bezug auf 16 beschrieben ist, in dem Prozessor 701 montiert sein. Außerdem können in dem Server 700 ein oder mehrere Bestandteile (die Verarbeitungseinheit 430), die in der MME 41 oder dem HSS 42 enthalten sind, die mit Bezug auf 17 beschrieben sind, in dem Prozessor 701 montiert sein. Außerdem können in dem Server 700 ein oder mehrere Bestandteile (die Authentifizierungsverarbeitungseinheit 531 und/oder die Kommunikationsverarbeitungseinheit 533), die in dem OTT-Server 500 enthalten sind, der mit Bezug auf 24 beschrieben ist, in dem Prozessor 701 montiert sein. Zum Beispiel kann ein Programm zum Veranlassen, dass ein Prozessor als das eine oder die mehreren Bestandteile (d. h. ein Programm zum Veranlassen, dass ein Prozessor Arbeitsabläufe des einen oder der mehreren Bestandteile ausführt) in dem Server 700 installiert sein und der Prozessor 701 kann das Programm ausführen. Als ein anderes Beispiel kann ein Modul, das den Prozessor 701 und den Speicher 702 aufweist, in dem Server 700 montiert sein, und der eine oder die mehreren Bestandteile können durch das Modul implementiert sein. In diesem Fall kann das Modul ein Programm speichern, um zu veranlassen, dass ein Prozessor als der eine oder die mehreren Bestandteile in dem Hauptspeicher 702 fungiert, und das Programm kann von dem Prozessor 701 ausgeführt werden. Der Server 700 oder das Modul können als Vorrichtungen bereitgestellt sein, die den oben beschriebenen einen oder die mehreren Bestandteile aufweisen, wie oben beschrieben, oder das Programm zum Veranlassen, dass ein Prozessor als der eine oder die mehreren Bestandteile fungiert, kann bereitgestellt sein. Außerdem kann ein lesbares Aufzeichnungsmedium, in dem das Programm aufgezeichnet ist, bereitgestellt sein.

In dem Server 700, der in 32 dargestellt ist, kann die Kommunikationseinheit 310, die oben unter Bezugnahme auf 16 beschrieben ist, die Kommunikationseinheit 410, die oben unter Bezugnahme auf 17 beschrieben ist, oder die Kommunikationseinheit 510, die oben unter Bezugnahme auf 24 beschrieben ist, in der Netzwerkschnittstelle 704 montiert sein. Außerdem kann in dem Server 700, der in 32 dargestellt ist, die Speichereinheit 320, die oben unter Bezugnahme auf 16 beschrieben ist, die Speichereinheit 420, die oben unter Bezugnahme auf 17 beschrieben ist, oder die Speichereinheit 520, die oben unter Bezugnahme auf 24 beschrieben ist, in dem Hauptspeicher 702 oder dem Speicher 703 montiert sein.

<Anwendungsbeispiel in Bezug auf Endgerät>(Erstes Anwendungsbeispiel)

33 ist ein Blockdiagramm, das ein Beispiel für eine schematische Konfiguration eines Smartphones 900 zeigt, auf das die Technologie der vorliegenden Offenbarung angewandt werden kann. Das Smartphone 900 beinhaltet einen Prozessor 901, einen Hauptspeicher 902, einen Speicher 903, eine externe Verbindungschnittstelle 904, eine Kamera 906, einen Sensor 907, ein Mikrofon 908, eine Eingabevorrichtung 909, eine Anzeigevorrichtung 910, einen Lautsprecher 911, eine drahtlose Kommunikationsschnittstelle 912, einen oder mehrere Antennenschalter 915, eine oder mehrere Antennen 916, einen Bus 917, eine Batterie 918 und eine Hilfssteuerung 919.

Der Prozessor 901 kann zum Beispiel eine CPU oder ein System-on-a-Chip (SoC) sein und steuert Funktionen einer Anwendungsschicht und anderer Schichten des Smartphones 900. Der Speicher 902 beinhaltet einen RAM und einen ROM und speichert ein Programm, das von dem Prozessor 901 ausgeführt wird, und Daten. Der Speicher 903 kann ein Speichermedium wie einen Halbleiterspeicher und eine Festplatte aufweisen. Die externe Verbindungsschnittstelle 904 ist eine Schnittstelle zum Verbinden einer externen Vorrichtung wie einer Speicherkarte und einer universellen seriellen Bus- (USB) Vorrichtung mit dem Smartphone 900.

Die Kamera 906 weist einen Bildsensor wie eine ladungsgekoppelte Vorrichtung (CCD) und einen komplementären Metalloxidhalbleiter (CMOS) auf und erstellt ein aufgenommenes Bild. Der Sensor 907 kann eine Gruppe von Sensoren aufweisen, wie einen Messsensor, einen Gyrosensor, einen geomagnetischen Sensor und einen Beschleunigungssensor. Das Mikrofon 908 wandelt Töne, die in das Smartphone 900 eingegeben werden, in Audiosignale um. Die Eingabevorrichtung 909 beinhaltet zum Beispiel einen Berührungssensor, der konfiguriert ist, Berührungen auf einem Bildschirm der Anzeigevorrichtung 910 zu erkennen, ein Tastenpad, eine Tastatur, einen Knopf oder einen Schalter, um einen Arbeitsablauf oder eine Informationseingabe von einem Benutzer zu empfangen. Die Anzeigevorrichtung 910 weist einen Bildschirm wie eine Flüssigkristallanzeige (Liquid Crystal Display - LCD) oder eine OLED (Organic Light Emitting Diode) - Anzeige zum Anzeigen von Ausgabebildern des Smartphones 900 auf. Der Lautsprecher 911 wandelt Audiosignale, die von dem Smartphone 900 ausgegeben werden, in Schall um.

Die drahtlose Kommunikationsschnittstelle 912 unterstützt ein beliebiges zellulares Kommunikationsschema wie LTE und LTE-Advanced und führt eine drahtlose Kommunikation aus. Die drahtlose Kommunikationsschnittstelle 912 kann typischerweise zum Beispiel einen BB-Prozessor 913 und eine HF-Schaltung 914 aufweisen. Der BB-Prozessor 913 kann zum Beispiel Codieren/Decodieren, Modulieren/Demodulieren und Multiplexen/Demultiplexen ausführen und führt verschiedene Arten von Signalverarbeitung für eine drahtlose Kommunikation aus. Indessen kann die HF-Schaltung 914 beispielsweise einen Mischer, ein Filter und einen Verstärker aufweisen und überträgt und empfängt Funksignale über die Antenne 916. Die drahtlose Kommunikationsschnittstelle 912 kann auch ein Ein-Chip-Modul sein, auf dem der BB-Prozessor 913 und die HF-Schaltung 914 integriert sind. Die drahtlose Kommunikationsschnittstelle 912 kann die mehreren BB-Prozessoren 913 und die mehreren HF-Schaltungen 914 aufweisen, wie in 33 dargestellt. Wenngleich 33 das Beispiel veranschaulicht, in dem die drahtlose Kommunikationsschnittstelle 912 die mehreren BB-Prozessoren 913 und die mehreren HF-Schaltungen 914 aufweist, kann die drahtlose Kommunikationsschnittstelle 912 auch einen einzelnen BB-Prozessor 913 oder eine einzelne HF-Schaltung 914 aufweisen.

Ferner kann die drahtlose Kommunikationsschnittstelle 912 zusätzlich zu einem zellularen Kommunikationsschema einen anderen Typ eines drahtlosen Kommunikationsschemas unterstützen, wie ein drahtloses Kurzentfernungs-Kommunikationsschema, ein Nahfeldkommunikationsschema und ein drahtloses lokales Netzwerk (LAN) -Schema. In diesem Fall kann die drahtlose Kommunikationsschnittstelle 912 den BB-Prozessor 913 und die HF-Schaltung 914 für jedes drahtlose Kommunikationsschema aufweisen.

Jeder der Antennenschalter 915 schaltet Verbindungsziele der Antennen 916 zwischen mehreren Schaltungen (wie zum Beispiel Schaltungen für verschiedene drahtlose Kommunikationsschemata) um, die in der drahtlosen Kommunikationsschnittstelle 912 enthalten sind.

Jede der Antennen 916 weist ein einziges oder mehrere Antennenelemente (wie mehrere Antennenelemente, die in einer MIMO-Antenne enthalten sind) auf und wird für die drahtlose Kommunikationsschnittstelle 912 zum Übertragen und Empfangen von Funksignalen verwendet. Das Smartphone 900 kann die mehreren Antennen 916 aufweisen, wie in 33 dargestellt. Wenngleich 33 das Beispiel veranschaulicht, in dem das Smartphone 900 die mehreren Antennen 916 aufweist, kann das Smartphone 900 auch eine einzige Antenne 916 aufweisen.

Ferner kann das Smartphone 900 die Antenne 916 für jedes drahtlose Kommunikationsschema aufweisen. In diesem Fall kann auf die Antennenschalter 915 in der Konfiguration des Smartphones 900 verzichtet werden.

Der Bus 917 verbindet den Prozessor 901, den Hauptspeicher 902, den Speicher 903, die Externe-Verbindung-Schnittstelle 904, die Kamera 906, den Sensor 907, das Mikrofon 908, die Eingabevorrichtung 909, die Anzeigevorrichtung 910, den Lautsprecher 911, die drahtlose Kommunikationsschnittstelle 912 und die Hilfssteuerung 919 miteinander. Die Batterie 918 liefert Leistung an in 33 dargestellte Blöcke des Smartphones 900 über Leistungsversorgungsleitungen, die teilweise durch gestrichelte Linien in der Figur dargestellt sind. Die Hilfssteuerung 919 betreibt eine minimal notwendige Funktion des Smartphones 900, beispielsweise in einem Schlafmodus.

In dem Smartphone 900, das in 33 dargestellt ist, können ein oder mehrere Bestandteile, die in dem Endgerät 200 (die Authentifizierungsverarbeitungseinheit 241 und/oder die Kommunikationsverarbeitungseinheit 243) enthalten sind, das in Bezug auf 15 beschrieben ist, durch die drahtlose Kommunikationsschnittstelle 912 implementiert sein. Alternativ können mindestens einige dieser Bestandteile von dem Prozessor 901 oder der Hilfssteuerung 919 implementiert sein. Zum Beispiel kann ein Modul, das einen Teil (zum Beispiel den BB-Prozessor 913) oder die gesamte drahtlose Kommunikationsschnittstelle 912, den Prozessor 901 und/oder die Hilfssteuerung 919 aufweist, in dem Smartphone 900 montiert sein, und der eine oder die mehreren Bestandteile können von dem Modul implementiert sein. In diesem Fall kann das Modul ein Programm speichern, um zu veranlassen, dass der Prozessor als der eine oder die mehreren Bestandteile fungiert (d. h. ein Programm zum Veranlassen, dass der Prozessor Arbeitsabläufe des einen oder der mehreren Bestandteile ausführt), und kann das Programm ausführen. Als ein anderes Beispiel kann das Programm zum Veranlassen, dass der Prozessor als der eine oder die mehreren Bestandteile fungiert, in dem Smartphone 900 installiert sein, und die drahtlose Kommunikationsschnittstelle 912 (zum Beispiel der BB-Prozessor 913), der Prozessor 901 und/oder der die Hilfssteuerung 919 können das Programm ausführen. Wie oben beschrieben, kann das Smartphone 900 oder das Modul als eine Vorrichtung bereitgestellt sein, die den einen oder die mehreren Bestandteile aufweist, und das Programm zum Veranlassen, dass der Prozessor als der eine oder die mehreren Bestandteile fungiert, kann bereitgestellt werden. Außerdem kann ein lesbares Aufzeichnungsmedium, in dem das Programm aufgezeichnet ist, bereitgestellt sein.

In dem in 33 dargestellten Smartphone 900 kann zum Beispiel die drahtlose Kommunikationseinheit 220, die oben unter Bezugnahme auf 15 beschrieben ist, in der drahtlosen Kommunikationsschnittstelle 912 (beispielsweise der HF-Schaltung 914) montiert sein. Ferner kann die Antenneneinheit 210 an der Antenne 916 montiert sein. Ferner kann die Speichereinheit 230 in dem Hauptspeicher 902 montiert sein.

(Zweites Anwendungsbeispiel)

34 ist ein Blockdiagramm, das ein Beispiel für eine schematische Konfiguration einer Fahrzeugnavigationsvorrichtung 920 zeigt, auf die die Technologie der vorliegenden Offenbarung angewandt werden kann. Die Fahrzeugnavigationsvorrichtung 920 beinhaltet einen Prozessor 921, einen Hauptspeicher 922, ein Global Positioning System (GPS) -Modul 924, einen Sensor 925, eine Datenschnittstelle 926, einen Inhaltsabspieler 927, eine Speichermedienschnittstelle 928, eine Eingabevorrichtung 929, eine Anzeigevorrichtung 930, einen Lautsprecher 931, eine drahtlose Kommunikationsschnittstelle 933, einen oder mehrere Antennenschalter 936, eine oder mehrere Antennen 937 und eine Batterie 938.

Der Prozessor 921 kann zum Beispiel eine CPU oder ein SOC sein und steuert eine Navigationsfunktion und andere Funktionen der Fahrzeugnavigationsvorrichtung 920. Der Speicher 922 beinhaltet einen RAM und einen ROM und speichert ein Programm, das von dem Prozessor 921 ausgeführt wird, und Daten.

Das GPS-Modul 924 verwendet GPS-Signale, die von einem GPS-Satelliten empfangen werden, um eine Position (wie Breitengrad, Längengrad und Höhe) der Fahrzeugnavigationsvorrichtung 920 zu messen. Der Sensor 925 kann eine Gruppe von Sensoren umfassen, wie einen Gyrosensor, einen geomagnetischen Sensor und einen barometrischen Sensor. Die Datenschnittstelle 926 ist zum Beispiel über ein Endgerät, das nicht dargestellt ist, mit einem fahrzeuginternen Netz 941 verbunden und erfasst Daten, die von dem Fahrzeug generiert werden, wie Fahrzeuggeschwindigkeitsdaten.

Der Inhaltsabspieler 927 reproduziert Inhalt, der in einem Speichermedium (zum Beispiel einer CD und einer DVD), das in die Speichermedienschnittstelle 928 eingesetzt ist, gespeichert ist. Die Eingabevorrichtung 929 beinhaltet zum Beispiel einen Berührungssensor, der konfiguriert ist, Berührungen auf einem Bildschirm der Anzeigevorrichtung 930 zu erkennen, einen Knopf oder einen Schalter und empfängt einen Arbeitsablauf oder eine Informationseingabe von einem Benutzer. Die Anzeigevorrichtung 930 weist einen Bildschirm, wie eine LCD- oder eine OLED-Anzeige auf und zeigt ein Bild der Navigationsfunktion oder reproduzierten Inhalt an. Der Lautsprecher 931 gibt Töne der Navigationsfunktion oder reproduzierten Inhalt aus.

Die drahtlose Kommunikationsschnittstelle 933 unterstützt ein beliebiges zellulares Kommunikationsschema wie LET und LTE-Advanced und führt eine drahtlose Kommunikation aus. Die drahtlose Kommunikationsschnittstelle 933 kann typischerweise zum Beispiel einen BB-Prozessor 934 und eine HF-Schaltung 935 aufweisen. Der BB-Prozessor 934 kann zum Beispiel Codieren/Decodieren, Modulieren/Demodulieren und Multiplexen/Demultiplexen ausführen und führt verschiedene Arten von Signalverarbeitung für eine drahtlose Kommunikation aus. Indessen kann die HF-Schaltung 935 beispielsweise einen Mischer, ein Filter und einen Verstärker aufweisen und überträgt und empfängt Funksignale über die Antenne 937. Die drahtlose Kommunikationsschnittstelle 933 kann ein Ein-Chip-Modul sein, auf dem der BB-Prozessor 934 und die HF-Schaltung 935 integriert sind. Die drahtlose Kommunikationsschnittstelle 933 kann die mehreren BB-Prozessoren 934 und die mehreren HF-Schaltungen 935 aufweisen, wie in 34 dargestellt. Wenngleich 34 das Beispiel veranschaulicht, in dem die drahtlose Kommunikationsschnittstelle 933 die mehreren BB-Prozessoren 934 und die mehreren HF-Schaltungen 935 aufweist, kann die drahtlose Kommunikationsschnittstelle 933 auch einen einzelnen BB-Prozessor 934 oder eine einzelne HF-Schaltung 935 aufweisen.

Ferner kann die drahtlose Kommunikationsschnittstelle 933 zusätzlich zu einem zellularen Kommunikationsschema einen anderen Typ eines drahtlosen Kommunikationsschemas unterstützen, wie ein drahtloses Kurzentfernungs-Kommunikationsschema, ein Nahfeldkommunikationsschema und ein drahtloses LAN-Schema. In diesem Fall kann die drahtlose Kommunikationsschnittstelle 933 den BB-Prozessor 934 und die HF-Schaltung 935 für jedes drahtlose Kommunikationsschema aufweisen.

Jeder der Antennenschalter 936 schaltet Verbindungsziele der Antennen 937 zwischen mehreren Schaltungen (wie zum Beispiel Schaltungen für verschiedene drahtlose Kommunikationsschemata) um, die in der drahtlosen Kommunikationsschnittstelle 933 enthalten sind.

Jede der Antennen 937 weist ein einziges oder mehrere Antennenelemente (wie mehrere Antennenelemente, die in einer MIMO-Antenne enthalten sind) auf und wird für die drahtlose Kommunikationsschnittstelle 933 zum Übertragen und Empfangen von Funksignalen verwendet. Die Fahrzeugnavigationsvorrichtung 920 kann die mehreren Antennen 937 aufweisen, wie in 34 dargestellt. Wenngleich 34 das Beispiel veranschaulicht, in dem die Fahrzeugnavigationsvorrichtung 920 die mehreren Antennen 937 aufweist, kann die Fahrzeugnavigationsvorrichtung 920 auch eine einzige Antenne 937 aufweisen.

Ferner kann die Fahrzeugnavigationsvorrichtung 920 die Antenne 937 für jedes drahtlose Kommunikationsschema aufweisen. In diesem Fall können die Antennenschalter 936 aus der Konfiguration der Fahrzeugnavigationsvorrichtung 920 weggelassen werden.

Die Batterie 938 liefert Leistung an in 34 dargestellte Blöcke der Fahrzeugnavigationsvorrichtung 920 über Leistungsversorgungsleitungen, die teilweise durch gestrichelte Linien in der Figur dargestellt sind. Die Batterie 938 akkumuliert Leistung, die von dem Fahrzeug geliefert wird.

In der Fahrzeugnavigationsvorrichtung 920, die in 34 dargestellt ist, können ein oder mehrere Bestandteile, die in dem Endgerät 240 (die Authentifizierungsverarbeitungseinheit 241 und/oder die Kommunikationsverarbeitungseinheit 243) enthalten sind, das in Bezug auf 15 beschrieben ist, durch die drahtlose Kommunikationsschnittstelle 933 implementiert sein. Alternativ können mindestens einige dieser Bestandteile von dem Prozessor 921 implementiert sein. Zum Beispiel kann ein Modul, das einen Teil (zum Beispiel den BB-Prozessor 934) oder die gesamte drahtlose Kommunikationsschnittstelle 933 und/oder den Prozessor 921 aufweist, in der Fahrzeugnavigationsvorrichtung 920 montiert sein, und der eine oder die mehreren Bestandteile können von dem Modul implementiert sein. In diesem Fall kann das Modul ein Programm speichern, um zu veranlassen, dass der Prozessor als der eine oder die mehreren Bestandteile fungiert (d. h. ein Programm zum Veranlassen, dass der Prozessor Arbeitsabläufe des einen oder der mehreren Bestandteile ausführt), und kann das Programm ausführen. Als ein anderes Beispiel kann das Programm zum Veranlassen, dass der Prozessor als der eine oder die mehreren Bestandteile fungiert, in der Fahrzeugnavigationsvorrichtung 920 installiert sein, und die drahtlose Kommunikationsschnittstelle 933 (zum Beispiel der BB-Prozessor 934), der Prozessor 921 können das Programm ausführen. Wie oben beschrieben, kann die Fahrzeugnavigationsvorrichtung 920 oder das Modul als eine Vorrichtung bereitgestellt sein, die den einen oder die mehreren Bestandteile aufweist, und das Programm zum Veranlassen, dass der Prozessor als der eine oder die mehreren Bestandteile fungiert, kann bereitgestellt werden. Außerdem kann ein lesbares Aufzeichnungsmedium, in dem das Programm aufgezeichnet ist, bereitgestellt sein.

Ferner kann in der in 34 dargestellten Fahrzeugnavigationsvorrichtung 920 zum Beispiel die drahtlose Kommunikationseinheit 220, die oben unter Bezugnahme auf 15 beschrieben ist, in der drahtlosen Kommunikationsschnittstelle 933 (beispielsweise der HF-Schaltung 935) montiert sein. Ferner kann die Antenneneinheit 210 an der Antenne 937 montiert sein. Ferner kann die Speichereinheit 230 in dem Hauptspeicher 922 montiert sein.

Die Technologie der vorliegenden Offenbarung kann auch als ein fahrzeuginternes System (oder ein Fahrzeug) 940 einschließlich eines oder mehrerer Blöcke der Fahrzeugnavigationsvorrichtung 920, das fahrzeuginternes Netz 941 und ein Fahrzeugmodul 942 realisiert werden. Mit anderen Worten kann das fahrzeuginterne System (oder ein Fahrzeug) 940 kann als eine Vorrichtung bereitgestellt werden, die die Authentifizierungsverarbeitungseinheit 241 und/oder die Kommunikationsverarbeitungseinheit 243 aufweist. Das fahrzeugseitige Modul 942 generiert Fahrzeugdaten wie eine Fahrzeuggeschwindigkeit, eine Motordrehzahl und Fehlerinformationen, und gibt die generierten Daten an das fahrzeuginterne Netz 941 aus.

<<Kurzdarstellung>>

Vorstehend wurden Ausführungsformen der vorliegenden Offenbarung unter Bezugnahme auf 1 bis 34 ausführlich beschrieben. Wie oben beschrieben, führt der MEC-Server 300 oder der OTT-Server 500 eine Kommunikation mit einem Netzwerk aus, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem in dem HSS 42 registrierten Server entsprechen, und stellt Inhalt bereit. Auf diese Weise wird verhindert, dass der MEC-Server 300 oder der OTT-Server 500, dessen Zuverlässigkeit nicht bestätigt ist, mit dem Netzwerk verbunden ist. Wenn Schlüssel zur Kommunikation durch den MEC-Server 300 oder den OTT-Server 500 bereitgestellt werden, kann außerdem die Vertraulichkeit eines Kommunikationspfades zwischen dem MEC-Server 300 oder dem OTT-Server 500 und der MME 41 oder dem UE 200 verbessert werden.

Die bevorzugte(n) Ausführungsform(en) der vorliegenden Offenbarung wurde(n) oben unter Bezugnahme auf die begleitenden Zeichnungen beschrieben, obwohl die vorliegende Offenbarung nicht auf die obigen Beispiele beschränkt ist. Ein Fachmann kann verschiedene Abänderungen und Modifikationen innerhalb des Schutzumfangs der angehängten Ansprüche finden und es versteht sich, dass sie natürlich in dem technischen Schutzumfang der vorliegenden Offenbarung liegen werden.

Zum Beispiel können die oben beschriebenen Ausführungsformen in geeigneter Weise kombiniert werden.

Es sei angemerkt, dass die Prozesse, die in dieser Beschreibung mit Bezug auf das Flussdiagramm und das Sequenzdiagramm beschrieben sind, in der Reihenfolge ausgeführt werden müssen, die in dem Flussdiagramm dargestellt ist. Einige Verarbeitungsschritte können parallel ausgeführt werden. Ferner können einige zusätzliche Schritte angewendet werden oder manche Verarbeitungsschritte können ausgelassen werden.

Des Weiteren sind die in dieser Beschreibung beschriebenen Effekte lediglich veranschaulichende oder beispielhafte Effekte und sind nicht beschränkend. Das heißt, dass die Technologie gemäß der vorliegenden Offenbarung mit oder anstelle der obigen Effekte andere Effekte erzielen kann, die Fachleuten auf dem Gebiet aus der Beschreibung dieser Spezifikation ersichtlich sind.

Außerdem kann die vorliegende Technologie auch wie unten beschrieben konfiguriert sein.

  1. (1) Server, der konfiguriert ist, einer anderen Vorrichtung Inhalt bereitzustellen, wobei der Server Folgendes aufweist:
    • eine Verarbeitungseinheit, die konfiguriert ist, Kommunikation mit einem Netzwerk auszuführen, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem Server entsprechen, der in einem Heimatteilnehmerserver (Home Subscriber Server - HSS) registriert ist.
  2. (2) Server nach (1),
    wobei die Authentifizierungsinformationen, die dem Server entsprechen, Authentifizierungsinformationen des Servers sind.
  3. (3) Server nach (2),
    wobei die Authentifizierungsinformationen des Servers eine Nummer aufweisen, die den Server identifiziert, und Schlüsselinformationen, die für den Server spezifisch sind.
  4. (4) Server nach (2) oder (3), der ferner Folgendes aufweist:
    • eine Speichereinheit, die zum Speichern der Authentifizierungsinformationen des Servers konfiguriert ist,
    • wobei die Verarbeitungseinheit eine Authentifizierung des Netzwerks unter Verwendung der Authentifizierungsinformationen des Servers ausführt.
  5. (5) Server nach einem von (2) bis (4),
    wobei ein Schlüssel zur Kommunikation zwischen einer Anwendung, die in dem Server arbeitet, und einer MME basierend auf den Authentifizierungsinformationen des Servers generiert wird.
  6. (6) Server nach (1),
    wobei die Authentifizierungsinformationen, die dem Server entsprechen, Authentifizierungsinformationen eines Endgeräts sind, das dem Server zugeordnet ist.
  7. (7) Server nach (6),
    wobei die Authentifizierungsinformationen des Endgeräts eine Nummer aufweisen, die den Server identifiziert, und Schlüsselinformationen, die für das Endgerät spezifisch sind.
  8. (8) Server nach (6) oder (7),
    wobei die Verarbeitungseinheit eine Kommunikation mit dem Netzwerk unter Verwendung von Informationen ausführt, die basierend auf einer Anfrage von dem Endgerät ausgegeben werden, das dem Server zugeordnet ist, dem die Authentifizierung des Netzwerks gelungen ist.
  9. (9) Server nach (8),
    wobei ein Schlüssel zur Kommunikation zwischen einer Anwendung, die in dem Server arbeitet, und einer MME basierend auf den Authentifizierungsinformationen des Endgeräts generiert wird, das dem Server zugeordnet ist.
  10. (10) Server nach einem von (1) bis (9),
    wobei ein Schlüssel für die Kommunikation zwischen einem Endgerät und einer Anwendung, die in dem Server arbeitet, basierend auf Authentifizierungsinformationen des Endgeräts generiert wird.
  11. (11) Server nach einem von (1) bis (10),
    wobei der Server ein Anwendungsserver ist, der in einem EPS bereitgestellt ist.
  12. (12) Server nach (11),
    wobei die Authentifizierungsinformationen, die dem Server entsprechen, Authentifizierungsinformationen eines anderen Servers sind, der dem Server zugeordnet ist.
  13. (13) Server nach (12),
    wobei die Verarbeitungseinheit eine Kommunikation mit dem Netzwerk unter Verwendung von Informationen ausführt, die basierend auf einer Anfrage von dem anderen Server ausgegeben werden, der dem Server zugeordnet ist, dem die Authentifizierung des Netzwerks gelungen ist.
  14. (14) Server nach (12) oder (13),
    wobei der andere Server ein Inhaltsserver ist, der dem Server Inhalt bereitstellt.
  15. (15) Server nach einem von (1) bis (10),
    wobei der Server ein Inhaltsserver ist, der einem Anwendungsserver, der in einem EPS bereitgestellt ist, Inhalt bereitstellt.
  16. (16) Server nach (15),
    wobei der Server über eine Basisstation eine Kommunikation mit einer MME ausführt.
  17. (17) Server nach (15),
    wobei der Server über keine Basisstation eine Kommunikation mit einer MME ausführt.
  18. (18) Server nach einem von (1) bis (10),
    wobei der Server ein Anwendungsserver ist, der in einem drahtlosen LAN-Netzwerk bereitgestellt ist.
  19. (19) Verfahren, das Folgendes aufweist:
    • Ausführen, von einem Server, der konfiguriert ist, einer anderen Vorrichtung Inhalt bereitzustellen, einer Kommunikation mit einem Netzwerk, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem Server entsprechen, der in einem HSS registriert ist.
  20. (20) Programm, das einen Computer veranlasst, wie folgt zu fungieren:
    • als ein Server, der einer anderen Vorrichtung Inhalt bereitstellt und eine Verarbeitungseinheit aufweist, die konfiguriert ist, eine Kommunikation mit einem Netzwerk auszuführen, das unter Verwendung von Authentifizierungsinformationen authentifiziert wird, die dem Server entsprechen, der in einem HSS registriert ist.

Bezugszeichenliste

1
System
10
Zelle
40
Kernnetzwerk
41
MME
42
HSS
43
S-GW
44
P-GW
50
PDN
60
Anwendungsserver
100
drahtlose Kommunikationsvorrichtung
200
Endgerät
210
Antenneneinheit
220
drahtlose Kommunikationseinheit
230
Speichereinheit
240
Verarbeitungseinheit
241
Authentifizierungsverarbeitungseinheit
243
Kommunikationsverarbeitungseinheit
300
MEC-Server
310
Kommunikationseinheit
320
Speichereinheit
330
Verarbeitungseinheit
331
Authentifizierungsverarbeitungseinheit
333
Kommunikationsverarbeitungseinheit
410
Kommunikationseinheit
420
Speichereinheit
430
Verarbeitungseinheit
500
OTT-Server
510
Kommunikationseinheit
520
Speichereinheit
530
Verarbeitungseinheit
531
Authentifizierungsverarbeitungseinheit
533
Kommunikationsverarbeitungseinheit

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 Patentliteratur

  • AP 100 C [0017]

Zitierte Nicht-Patentliteratur

  • „Mobile-Edge Computing-Introductory Technical White Paper“, September, 2014, [gesucht am 3. September 2015] [0004]