DE112016005859T5 - Server, procedure and program - Google Patents

Abstract

[Task] Providing a mechanism to ensure security with an edge server.
[Solution] A server configured to provide content to another device, the server comprising: a processing unit configured to communicate with a network that is authenticated using authentication information corresponding to the server that resides in a Home Subscriber Server (HSS) is registered.

Description

Technical area

The present disclosure relates to a server, a method, and a program.

State of the art

In recent years, mobile edge computing (MEC) technology for performing data processing in a server (hereinafter also referred to as an edge server) has been attracting attention at a position physically close to a terminal such as a smart phone , For example, a standard of technology related to MEC is examined in Non-Patent Literature 1 cited below.

In the MEC, an edge server is physically located at a location close to a terminal, thus reducing communication delay as compared to a general cloud server that is concentrated, and it is possible to use an application that has high real-time Performance must have. Further, in the MEC, the edge server in the vicinity of the terminal is caused to perform distributed processing of a function which has been processed on the terminal side so far, so that high-speed network / application processing can be realized regardless of the terminal's performance. The edge server may have various functions, such as a function serving as an application server and a function serving as a content server, and may provide various services to the terminal.

List of known fonts

Non-patent literature

Non-patent literature 1: ETSI, "Mobile-Edge Computing-Introductory Technical White Paper", September, 2014, [requested on September 3, 2015] , the Internet <https://portal.etsi.org/Portals/0/TBpages/MEC/Docs/Mobile-edge_Computing_-_Introductory_Technical_White_Paper_V1%2018-09-14.pdf>

Disclosure of the invention

Technical problem

It is difficult to say that the study of non-patent literature 1 or the like has produced sufficient proposals for technology related to MEC, since such studies have only recently begun. For example, one technology that provides security for an edge server is one that does not have enough suggestions.

the solution of the problem

According to the present disclosure, there is provided a server configured to provide content to another device, the server comprising: a processing unit configured to communicate with a network that is authenticated using authentication information corresponding to the server who is registered in a Home Subscriber Server (HSS).

In addition, according to the present disclosure, there is provided a method comprising: executing, by a server configured to provide content to another device, communication with a network that is authenticated using authentication information corresponding to the server that is registered in an HSS.

In addition, in accordance with the present disclosure, a program is provided that causes a computer to function as: a server providing content to another device and having a processing unit configured to communicate with a network using Authenticated authentication information that corresponds to the server registered in an HSS.

Advantageous effects of the invention

As described above, according to the present disclosure, there is provided a mechanism for ensuring security with respect to an edge server. It is noted that the effects described above are not necessarily limiting. With or instead of the above effects, any of the effects described in this specification or other effects that can be obtained from this description can be achieved.

list of figures

• [ 1 ] 1 FIG. 10 is an explanatory diagram illustrating an example of a schematic configuration of a system 1 according to an embodiment of the present disclosure.
• [ 2 ] 2 FIG. 13 is a diagram illustrating an example of a configuration of an LTE network in which MEC is not introduced.
• [ 3 ] 3 Fig. 10 is a block diagram illustrating an example of a configuration of a network in which MEC is introduced.
• [ 4 ] 4 Fig. 10 is a diagram illustrating an example of a configuration of an LTE network in which MEC is introduced.
• [ 5 ] 5 Figure 11 is a diagram illustrating an example of a data stream of DL cache data.
• [ 6 ] 6 Figure 12 is a diagram illustrating an example of a data stream of UL caching data.
• [ 7 ] 7 Fig. 10 is an explanatory diagram for describing a architecture of a carrier.
• [ 8th ] 8th Fig. 10 is an explanatory diagram for describing an architecture of an EPS carrier.
• [ 9 ] 9 Fig. 10 is an explanatory diagram for describing a UL ID and a DL ID set in a carrier;
• [ 10 ] 10 FIG. 14 is a sequence diagram illustrating an example of a flow of a process for setting up a standard carrier. FIG.
• [ 11 ] 11 FIG. 10 is a sequence diagram illustrating an example of a flow of a process for setting up a dedicated carrier. FIG.
• [ 12 ] 12 FIG. 10 is a sequence diagram illustrating an example of a flow of an authentication process performed in an LTE network. FIG.
• [ 13 ] 13 Fig. 10 is an explanatory diagram for describing an example of use of keys used during actual communication.
• [ 14 ] 14 is a system diagram of keys.
• [ 15 ] 15 FIG. 10 is a block diagram illustrating an example of a configuration of a terminal according to an embodiment of the present disclosure.
• [ 16 ] 16 FIG. 10 is a block diagram illustrating an example of a configuration of an MEC server according to an embodiment of the present disclosure.
• [ 17 ] 17 FIG. 10 is a block diagram illustrating an example of a configuration EPC function entity according to an embodiment of the present disclosure.
• [ 18 ] 18 FIG. 10 is an explanatory diagram for describing technical features according to a first embodiment. FIG.
• [ 19 ] 19 is an explanatory diagram for describing technical features according to a second embodiment.
• [ 20 ] 20 FIG. 10 is an explanatory diagram for describing technical features according to a third embodiment. FIG.
• [ 21 ] 21 FIG. 10 is an explanatory diagram for describing technical features according to the present embodiment. FIG.
• [ 22 ] 22 FIG. 10 is an explanatory diagram for describing technical features according to a fourth embodiment. FIG.
• [ 23 ] 23 FIG. 10 is an explanatory diagram for describing technical features according to the present embodiment. FIG.
• [ 24 ] 24 FIG. 10 is an explanatory diagram for describing technical features according to the present embodiment. FIG.
• [ 25 ] 25 FIG. 10 is an explanatory diagram for describing technical features according to the present embodiment. FIG.
• [ 26 ] 26 FIG. 10 is an explanatory diagram for describing technical features according to the present embodiment. FIG.
• [ 27 ] 27 FIG. 10 is an explanatory diagram for describing technical features according to the present embodiment. FIG.
• [ 28 ] 28 FIG. 10 is an explanatory diagram for describing technical features according to the present embodiment. FIG.
• [ 29 ] 29 FIG. 10 is an explanatory diagram for describing technical features according to the present embodiment. FIG.
• [ 30 ] 30 FIG. 10 is an explanatory diagram for describing technical features according to the present embodiment. FIG.
• [ 31 ] 31 FIG. 10 is an explanatory diagram for describing technical features according to the present embodiment. FIG.
• [ 32 ] 32 Fig. 10 is a block diagram illustrating an example of a schematic configuration of a server.
• [ 33 ] 33 Fig. 10 is a block diagram illustrating an example of a schematic configuration of a smartphone.
• [ 34 ] 34 FIG. 10 is a block diagram illustrating an example of a schematic configuration of a car navigation device. FIG.

Embodiment (s) of the invention

Hereinafter, a preferred embodiment (s) of the present disclosure will be described in detail with reference to the attached drawings. It should be noted that in this specification and the appended drawings, structural elements having substantially the same function and structure are denoted by the same reference numerals, and a repeated explanation of these structural elements will be omitted.

Further, in this specification and drawings, there are cases in which elements having substantially the same function are distinguished by appending different letters to the end of the same reference number. For example, a plurality of elements having substantially the same functional configuration as the base stations 100A, 100B and 100C are discriminated as necessary. However, in a case where it is not necessary to distinguish each of the plurality of elements having substantially the same functional configuration, only the same reference numeral is added. For example, in a case where it is not necessary to particularly distinguish the base stations 100A, 100B and 100C, they are simply referred to as a "base station 100".

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

Hereinafter, the description will take place in the following order.

1. 1 Introduction
   • 1.1. Schematic system configuration
   • 1.2. MEC
   • 1.3. carrier
   • 1.4. safety
2. 2. Configuration example of each device
   • 2.1. Configuration of the terminal
   • 2.2. Configuration example of the MEC server
   • 2.3. Configuration example of the EPC function entity
3. 3. First embodiment
   • 3.1. Technical problem
   • 3.2. technical features
4. 4. Second embodiment
   • 4.1. Technical problem
   • 4.2. technical features
5. 5. Third embodiment
   • 5.1. Technical problem
   • 5.2. technical features
6. 6. Fourth Embodiment
   • 6.1. Technical problem
   • 6.2. Configuration example of the OTT server
   • 6.3. technical features
7. 7. Application examples
8. 8. Brief description

<< Introduction >>

<Schematic system configuration>

First, a schematic configuration of a system 1 according to an embodiment of the present disclosure with reference to 1 described. 1 Fig. 12 is an explanatory diagram showing an example of a schematic configuration of the system 1 in accordance with an embodiment of the present disclosure. With reference to 1 instructs the system 1 a wireless communication device 100 , a terminal 200 and an MEC server 300 on.

( 1 ) Wireless communication device 100

The wireless communication device 100 is a device that provides a wireless communication service to subordinate devices. For example, a wireless communication device 100A a base station of a cellular system (or a mobile communication system). The base station 100A performs wireless communication with a device (eg, a terminal 200A) located within a cell 10A of the base station 100A located. For example, the base station sends 100A a downlink signal to the terminal 200A and receives an uplink signal from the terminal 200A ,

This is the base station 100 also referred to as an eNodeB (or eNB). Here, the eNodeB may be an eNodeB, as defined in LTE or LTE-A, or it may be more generally interpreted as a communication device.

The base station 100A is logically connected to other base stations, for example via an X2 interface, and can perform the transmission and reception of control information and the like. Further, the base station 100A logically with a core network 40 For example, connected via an S1 interface and can perform the transmission and reception of control information and the like. Furthermore, the communication between these devices may be physically transmitted by different devices.

Here is the wireless communication device 100A , in the 1 a microcell base station and a cell 10A is a microcell. On the other hand, the wireless communication devices 100B and 100C Master devices, which are the small cells 10B and 10C. As an example, the master device is 100B a small cell base station that is permanently installed. The small cell base station 100B provides a wireless backhaul connection to the microcell base station 100A and provides an access connection to one or more terminals (for example the terminal 200B ) in a small cell 10B ago. The master device 100C is a dynamic access point (AP). The dynamic one AP 100C is a mobile device that dynamically operates the small cell 10C. The dynamic one AP 100C provides a wireless backhaul connection to the microcell base station 100A and establishes an access connection with one or more terminals (for example terminal 200C) in the small cell 10C. The dynamic one AP 100C For example, it may be a terminal equipped with hardware or software that can act as a base station or a wireless access point. In this case, the small cell 10C a localized network that is formed dynamically.

The cell 10 can operate according to any wireless communication scheme, such as LTE, LTE-A, GSM (R), UMTS, W-CDMA, CDMA 200 , WiMAX, WiMAX 2 or IEEE 802.16.

Further, the small cell may be a concept including various types of cells arranged to overlap or not overlap with the micro cell and smaller than the micro cell (for example, a femto cell, a nanocell, a picocell, a microcell or the like). In one example, the small cell is powered by a dedicated base station. In another example, the small cell is operated as a terminal serving as a master device that temporarily acts as a small cell base station. A so-called relay node can also be considered as a form of small cell base station. The wireless communication device, which functions as a master station of the relay node, is also referred to as a "donor base station". The donor base station may refer to a donor eNodeB (DeNB) in LTE or more generally refer to a master station of a relay node.

Terminal 200

The terminal 200 can communicate in a cellular system (or mobile communication system). The terminal 200 performs wireless communication with the wireless communication device (e.g., the base station 100A and the master device 100B or 100C ) of the cellular system. For example, the terminal is receiving 200A the downlink signal from the base station 100A and sends an uplink signal to the base station 100A ,

Here is the terminal 200 also referred to as a "user". The user may also be referred to as a user equipment (UE). In addition, the wireless communication device becomes 100C also referred to as a "UE relay". Here, the UE may be a UE defined in LTE or LTE-Advanced (LTE-A), the UE relay may be a Prose UE to Network Relay explained in 3GPP or, more generally, a communication device.

Application Server 60

An application server 60 is a device that provides a service to the user. The application server 60 is with a packet data network (PDN) 50 connected. On the other hand, the base station 100 with the core network 40 connected. The core network 40 is connected to the PDN 50 via a gateway device. Therefore, the wireless communication device 100 that from the application server 60 provided service to the MEC server 300 and the user via the packet data network 50 , the core network 40 and the wireless communication path.

MEC server 300

The MEC server 300 is a service providing device that provides the user with a service (for example, content or the like). The MEC server 300 can in the wireless communication device 100 be provided. In this case, the wireless communication device 100 the user over the wireless communication path from the MEC server 300 provided service. The MEC server 300 may be implemented as a logical function entity or may be integral with the wireless communication device 100 or the like, as in 1 shown. Naturally can be the MEC server 300 be formed as an independent device as a physical entity. An application running in the MEC server 300 is also referred to as an MEC application.

For example, the base station 100A the service provided by the MEC server 300A to the terminal 200A ready with the microcell 10 connected is. Further, the base station 100A the service provided by the MEC server 300A to the terminal 200B ready to do that via the master device 100B with the small cell 10B connected is.

Further, the master device 100B the service provided by the MEC server 300B to the terminal 200B ready, with the small cell 10B connected is. Similarly, the master device 100C that from the MEC server 300C provided service to the terminal 200C ready with the small cell 10C connected is.

complement

The schematic configuration of the system 1 has been described above, however, the present technology is not on the in 1 illustrated example limited. For example, as a configuration of the system 1 a configuration that does not include a master device, a small-cell enhancement (SCE), a heterogeneous network (HetNet), a machine-communication-type network (MTC), or the like may be used.

<MEC>

Next, the MEC will be referred to 2 to 6 described.

( 1 ) Network configuration

2 FIG. 13 is a diagram illustrating an example of a configuration of an LTE network in which MEC is not introduced. As in 2 1, a radio access network (RAN) has a UE and an eNodeB. The UE and the eNodeB are connected via a Uu interface and the eNodeBs are connected via an X2 interface. An Evolved Packet Core (EPC) also has a Mobility Management Entity (MME), a Home Subscriber Server (HSS), a Serving Gateway (S-GW) and a PDN Gateway (P-GW). The MME and the HSS are connected via an S6a interface, the MME and the S-GW are connected via an S11 interface and the S-GW and the P-GW are connected via an S5 interface. The eNodeB and the MME are connected via a S1-MME interface, the eNodeB and the S-GW are connected via a S1-U interface, and the P-GW and the PDN are connected via an SGi interface.

For example, the PDN has an original server and a cache server. An original application to be provided to the UE is stored in the original server. For example, an application or cache data is stored in the cache server. By accessing the cache server instead of the original server, the UE can reduce a processing load on the original server and a communication load corresponding to the access to the original server. However, since the cache server is outside the RAN and the EPC (i.e., the PDN), a communication delay that occurs between the UE and the cache server (i.e., a response delay to a request from the UE) is still a problem.

Examples of the UE's request include a static request such as downloading content stored in an HTTP server and a dynamic request such as a workflow in a specific application. In any case, it is clear that if cache data and an application are placed in an entity near the UE, the response to the query is fast. Typically, the response speed here depends on the number of units to be traversed and not on the distance between units. This is because a processing delay in an input unit, a processing unit, and an output unit in each entity that is traversed is accumulated in accordance with the number of units. Further, the content indicates data of any format, such as an application, a picture (a moving picture or a still picture), a sound, text or the like.

The MEC was invented to solve such a problem. At the MEC, an application server providing content to or from the UE is installed in an evolved packet system (EPS). Further, the EPS is a network having an EPC and an eUTRAN (ie, an eNodeB). The application server installed in the EPS can also be referred to as an edge server or MEC server. Further, the application server is a concept that includes a cache server.

3 and 4 FIGs. are diagrams illustrating an example of a configuration of an LTE network into which MEC is introduced. In 3 An MEC server that caches content is installed in an eNodeB. According to this configuration, the number of entities arranged between the UE and the MEC server is smaller than that in FIG 2 and thus the UE can quickly grasp the content. In 4 the MEC server storing the content is installed in eNodeB and S-GW. For example, the UE detects the content of the MEC server located in the eNodeB and detects the content of the MEC server located in the S-GW in a case where no cache data is requested from the MEC server arranged in the eNodeB , Since access to the original server can be avoided, the UE can quickly capture the content in any case.

entities

In the 2 to 4 Entities shown are described below. The S-GW is an entity serving as an anchor point of delivery. The P-GW is a connection point between a mobile network and the outside (ie, a PDN), assigns an IP address to the UE, and provides an IP address that can be accessed from the exterior of the mobile network. The P-GW also performs filtering or the like on data arriving from the outside. The HSS is a database that stores subscriber information. The MME accesses the HSS to process various control signals, and performs a process such as authentication of each UE and authorization.

The EPC network is divided into a control level and a user level. The S-GW and the P-GW mainly relate to the user level, and the MME and HSS mainly relate to the control plane.

Here, the S-GW has a function of storing user data because, even in the configuration before MEC is introduced, it serves as the anchor point of the handover. On the other hand, the eNodeB has no function of storing the user data in the configuration before MEC is introduced, and has only functions such as a packet retransmission according to a packet loss that has occurred in the Uu interface, and thus is unable to store content , Further, the X2 interface is used for data exchange at the time of handover and cooperative control of the interference.

Application in MEC server

Examples of the cache include a stream cache that performs caching at an IP level and a content cache that performs caching at an application layer level. It is assumed that the MEC server supports both types of caches. Since the content cache is mainly used, it is currently assumed that the MEC server in particular supports the content cache.

Here in the MEC server it is important that an application is activated and enters an operational state. This is firstly due to the fact that cache data is detected based on an HTTP header, which is why it is desirable in the MEC server that an application capable of handling the HTTP enters the operational state. Second, in a case where the MEC server provides a specific application, it is desirable for the application to be placed and activated to enter the operational state.

Types of applications that correspond to MEC are manifold. In the case of the cache application, which caches data even though it is activated and enters the operating state in the MEC server, in a case where no destination data is cached, the UE goes to an original server to acquire data. Therefore, it is desirable to cache data in the cache application in advance.

Cache target data

As in the MEC server 300 There are two types of cached data, namely, data to be transmitted to the UE in a downlink (DL) direction (also referred to as a DL data flow hereinafter) and data received from the UE in an uplink (UL). Direction (hereafter referred to as UL data flow).

As an instance of caching the DL data flow, for example, there is a case where, when the UE accesses a Web application and detects certain http data, if the same data is cached in the MEC server, the caching data is detected.

An example of the use case for latching the UL data flow will be described below.

A first use case is a case of uploading data such as an image generated by the UE. In particular, the UE uploads an image generated by the UE, and the MEC server intermediately saves the image. Then, the MEC server may transmit the cached image to a server that stores the image on the PDN, for example, at a time when there is room in a transmission capacity in the core network. A communication load of the core network is reduced by shifting the transmission time. Further, for example, the MEC server may transmit the cached image to another UE. The sharing of the UL data cache with other UEs is useful, for example, in a case where pictures taken by onlookers in a stadium are shared among the audience in the stadium.

A second use case is a case of uploading data detected by the UE. For example, the UE uploads data detected via the device-to-device (D2D) or Wi-Fi (registered trademark) communication, and the MEC server temporarily stores the data. As a specific example of this use case, for example, an example is considered in which a store transmits information about products via D2D communication or Wi-Fi, and the UE acquires the information and uploads the information to the MEC server. In this case, other UEs within an area of the store (eg, within a cell of the eNodeB in which the MEC server is installed) may capture the cached information of the products.

A third use case is the uploading of data received from another eNodeB. For example, the UE uploads the data received from the eNodeB that is connected before handover to the MEC server installed in the eNodeB that will be connected after handover.

A fourth use case is a case where the MTC terminal is uploading data. As such data, for example, sales data of a vending machine and gas use status data are considered, which are detected by a gas meter. In some cases, the number of MTC terminals is very large, and if the MTC terminals try to upload all data to the server on the PDN, there is a problem that congestion occurs on the core network side. On the other hand, since such data does not require a real-time property, they are sufficient, although they arrive after one hour, for example. In other words, an application that relates to data from the MTC terminal may be considered to be delay resistant. Therefore, the MEC server can cache the data uploaded from the MTC terminal and transmit the cached data to the server on the PDN, for example, at the time when there is room in the transmission capacity in the core network. In particular, in the transmission capacity of the core network, the capacity of the control signal is more problematic than the capacity of the user data. To establish a session, it is necessary to signal several rounds. When a large number of MTC terminals are uploading all the data together, the signaling of the core network is excessively increased.

The example of the use case of caching the UL data flow has been described. In this specification, the description continues with the cache of the UL data flow.

The cache data of the UL data flow may be transmitted in the DL direction (for example, the UE) as described above, or may be transmitted in the UL direction (for example, the server on the P-GW or the PDN). The former cache data is also referred to as DL cache data and the latter cache data is also referred to as UL cache data.

5 is a diagram illustrating an example of the data flow of the DL cache data. As in 5 As shown, the MEC server temporarily stores the data uploaded by the UE and transmits the caching data to the UE (typically another UE than the uploading UE).

6 is a diagram illustrating an example of a data flow of UL caching data. As in 6 1, the MEC server stores the data uploaded by the UE and transmits the cache data to the original server on the PDN.

Further, depending on the data, there are cases in which the data may not be treated as DL cache data. For example, data that can be shared with other UEs may be treated as the DL caching data, and personal data may not be treated as DL caching data. Similarly, depending on the data, there are cases where the data may not be treated as UL caching data. For example, data that needs to be aggregated, such as data from the MTC terminal, is allowed as the UL caching data, and local data such as data having a regional restriction is not allowed as the UL caching data.

Under such circumstances, it is desirable in the MEC server to appropriately manage whether or not the cache data can be transmitted in the DL direction (ie, the UE) and whether the cache data is in the UL direction (that is, to the PDN) or not.

<Carrier>

Next, a carrier used in the EPS, particularly the EPS carrier, will be described with reference to FIG 7 to 11 described. The carrier refers to a session, that is, a drain pipe for data transmission.

7 Fig. 10 is an explanatory diagram for describing the architecture of the carrier. As in 7 As shown, an end-to-end service provided to the UE from the original server is provided by data transmission using the EPS bearer and an external bearer. An EPS bearer is set up in conjunction with some sort of QoS. For example, the UE sets up two EPS carriers that correspond to two types of QoS with the P-GW, if two kinds of QoS are to be used simultaneously.

The EPS bearer is a logical session (a virtual connection) and actually comprises a radio bearer, an S1 bearer, and an S5 bearer. The radio bearer is a bearer established on the LTE-Uu interface between the UE and the eNodeB. The S1 carrier is a carrier established at the S 1 interface between the eNodeB and the S-GW. The S5 carrier is a carrier established on the S5 interface between the S-GW and the P-GW.

8th Fig. 12 is an explanatory diagram for describing the architecture of the EPS carrier. As in 8th explained, the EPS carrier has a standard carrier and a dedicated carrier. When the carrier is established by exchanging signals with the MME, the UE first sets up the standard carrier corresponding to a QoS which is decided as standard. Thereafter, the UE establishes a carrier corresponding to a necessary QoS as a dedicated carrier. The dedicated carrier can not be set up without a standard carrier.

An ID identifying the bearer is set in each bearer. The ID is used to identify the bearer used by an UE. Therefore, if both the ID of the UE and the ID of the bearer are used, it is possible that each entity (for example, the P-GW, the S-GW, the eNodeB, or the like) identifies each bearer. The ID is a UL-ID and a DL-ID.

9 Fig. 10 is an explanatory diagram for describing a UL ID and a DL ID set in a carrier. As in 9 In the EPS carrier, a UL session and a DL session are distinguished by separate IDs. For example, as the ID set in the radio bearer, there is a "UL RB ID" for the UL and a "DL RB ID" for the DL. Further, in the S1 bearer, there is a session (a session exchanged according to a GTP tunneling protocol) discriminated by a tunnel endpoint ID (TEID) and "UL S1 TEID" which is a UL ID, or "DL S1 TEID" which is a DL ID is set. Further, in the S5 bearer, there is a session discriminated by TEID, and "UL S5 TEID" which is a UL ID or "DL S5 TEID" which is a DL ID is set.

The following table shows entities that assign IDs. This means that an entity that assigns an id builds a relevant responsible session. [Table 1] entity UL DL UE eNodeB UL RB ID DL RB ID, DL S1 TEID S-GW UL S1 TEID DL S5 TEID P-GW UL S5 TEID

In the above table, the TEID is assigned by an entity on an endpoint page. On the other hand, both the UL RB ID and the DL RB ID are assigned by the eNodeB.

The following table shows a list of data flows with IDs. As shown in the following table, the UL data flow is transferred in a session assigned the UL ID, and the DL data flow is transferred in a session assigned the DL ID. Further, the ID of each session has a one-to-one mapping relationship with an ID associated with an ID. In other words, an ID is never assigned to a plurality of IDs. [Table 2] entity UL DL UE UP IP flow -> UL RB ID eNodeB UL RB ID DL S 1 TEID -> UL S1 TEID -> DL RB ID S-GW UL S1 TEID DL S5 TEID -> UL S5 TEID -> DL S1 TEID P-GW DL IP flow -> DLS5 TEID

Next, an operation for setting up the carrier will be described with reference to FIG 10 and 11 described.

10 FIG. 14 is a sequence diagram illustrating an example of a flow of a process for setting up the default bearer. FIG. The sequence includes a UE, an eNodeB, an MME, an S-GW, a P-GW and a Rules and Charges Collection Function (PCRF). As in 10 the device of the standard bearer is initiated according to a request from the UE. The request is transmitted in the order of the eNodeB, the MME, the S-GW and the P-GW, and a permit is transmitted in an opposite direction. Further, the PCRF is an entity that provides information about a QoS.

The present sequence will be described in detail. First, the UE transmits an attach request to the eNodeB (step S11), and the eNodeB transmits the message to the MME (step S12). Then, the MME transmits a standard bearer generation request to the S-GW (step S13), and the S-GW transmits the message to the P-GW (step S14). Then, the P-GW exchanges with the PCRF to establish an IP-Connectivity Access Network (IP-CAN) session (step S15). Then, the P-GW transmits a standard bearer generation response to the S-GW (step S16), and the S-GW transmits the message to the MME (step S17). Then, the MME transmits an attach acceptance to the eNodeB (step S18), and the eNodeB transmits a radio resource control (RRC) connection reconfiguration to the UE (step S19). Then, the UE transmits an RRC connection reconfiguration termination to the eNodeB (step S20), and the eNodeB transmits an attachment completion to the MME (step S21). Then, the MME transmits a bearer update request to the S-GW (step S22), and the S-GW transmits a bearer update response to the MME (step S23).

11 FIG. 12 is a sequence diagram illustrating an example of a flow of an operation for setting up the dedicated carrier. FIG. The present sequence includes the UE, the eNodeB, the MME, the S-GW, the P-GW and the PCRF. As in 11 1, the device of the dedicated carrier is initiated according to the request from the PCRF in contrast to the standard carrier. If the UE desires to set up the dedicated bearer, the UE further transmits a message indicating that the UE wishes to set up the dedicated application layer bearer, and the application layer transmits a necessary QoS to the PCRF, so that the UE initiated dedicated Carrier is implemented.

The present sequence will be described in detail. First, the PCRF sends an IP-CAN session change start to the P-GW (step S31). Then, the P-GW transmits a dedicated bearer generation request to the S-GW (step S32), and the S-GW transmits the message to the MME (step S33). Then, the MME transmits a dedicated carrier setup request to the eNodeB (step S34), and the eNodeB transmits an RRC connection reconfiguration to the UE (step S35). Then, the UE transmits an RRC connection reconfiguration termination to the eNodeB (step S36), and the eNodeB transmits a dedicated carrier setup response to the MME (step S37). Then, the MME transmits a dedicated bearer generation response to the S-GW (step S38), and the S-GW transmits the message to the P-GW (step S39). Then, the P-GW transmits an IP-CAN session change end to the PCRF (step S40).

<Security>

As an example of security technology in LTE, authentication and authorization are illustrated. Authentication determines whether a communication partner is a suitable partner. A suitable partner here is, for example, a partner who has the appropriate authorization to access an operator's LTE network. The authorization is a decision as to whether a communication partner has a right to use a service. For example, a right here is an access right to an operator's LTE network. An authentication process will be described below with reference to FIG 12 described. Here, the authentication process is part of an attach operation.

12 FIG. 10 is a sequence diagram illustrating an example of a flow of an authentication process executed in an LTE network. FIG. As in 12 In addition, the HS stores an IMSI of each UE and a key K corresponding to the IMSI. Here the UE communicates with an MME via an eNodeB. As will be described below, the UE and the HSS perform mutual authentication using the same IMSI and the key K, which are stored respectively.

First, the UE transmits a connection request together with the IMSI to the MME (step S51). Thereafter, the MME transmits an authentication request to the HSS together with the received IMSI (step S52). Next, the HSS generates a random number RAND, inputs the random number RAND, the received IMSI and the key K stored in connection with the IMSI to the authentication function and obtains an expected response RES _EXPECTED and a key K _ASME (step S53). Next, the HSS sends the key K _ASME , the expected response RES _EXPECTED, and the random number RAND to the MME as an authentication response (step S54). Next, the MME transmits the random number RAND to the UE (step S55). Next, the UE inputs the received random number RAND and the stored IMSI and the key K into the authentication function, and receives a response RES and a key K _ASME (step S56). Next, the UE sends a response RES to the MME (step S57). Then, the MME compares the expected response RES _EXPECTED with an actual response RES and authenticates the UE (step S58). In particular, if the expected response matches the actual response RES, the MME determines that the UE is reliable (that is, the authentication is successful). On the other hand, if the expected response RES _EXPECTED does not match the actual response RES, the MME determines that the UE is not reliable (that is, the authentication fails).

After the authentication process, keys that are used during actual communication are generated based on K _ASME . There are two types of keys, an encryption key (CK) and an integrity key (IK). The CK is a key to encrypting communications and is used to prevent communication content from becoming known to others. The IK is a key to verify integrity of data and is used to check if data has changed on a communication path. In the EPS, security is ensured according to an authentication / authorization (AA) process, CK encryption, and integrity checking using the IK. Here, these processes are executed separately for each UE.

As above with reference to 12 described, according to the authentication process, a common key K _ASME generated both on the UE side and on the network side. The UE side and the network side (HSS, MME or eNodeB) generate keys used during actual communication for each application based on the common key K _ASME . An example of use of keys used during actual communication will be described below with reference to FIG 13 described.

13 Fig. 10 is an explanatory diagram for describing an example of use of keys used during actual communication. As in 13 As shown, a CK is used for a user plane between the UE and the eNodeB. In addition, the IK and CK are used for radio resource control (RRC) signaling between the UE and the eNodeB. In addition, the IK and CK are used for non-access stratum (NAS) signaling between the UE and the MME. This will use a different key for each application. Then, such keys are generated based on K _ASME generated in the AA process. A relationship between keys generated for each application will be described below with reference to FIG 14 described.

14 is a system diagram of keys. In the drawing, enc encodes, int indicates an integrity, RRC indicates RRC signaling, NAS indicates NAS signaling, and UP indicates a user plane. The system diagram of in 14 The key shown is common to the UE side and the network side. Keys on the network side generate a key for NAS from MME. Keys for RRC signaling and a user level other than the key for NAS are generated by the eNodeB. With respect to the keys on the UE side, all keys are generated by the UE.

The generation of keys in 14 are described in time series. First, the HSS and the UE generate K _ASME according to a mutual authentication. Next, the MME and the UE generate a key for NAS signaling (ie K _NASenc and K _NASint ) and a base key for an eNodeB (ie KeNodeB) based on K _ASME . Then, the eNodeB and the UE generate a key for the RRC signaling (ie, K _RRCenc and K _RRCint ) and a user _plane key (ie, K _UPenc ) based on the eNodeB base key.

<< Configuration example of each device >>

<Configuration of the terminal>

First, an example of a configuration of the terminal 200 according to the embodiment of the present disclosure with reference to 15 described. 15 is a block diagram illustrating an example of a configuration of the terminal 200 in accordance with an embodiment of the present disclosure. With reference to 15 has the terminal 200 an antenna unit 210 , a wireless communication unit 220 , a storage unit 230 and a processing unit 240 on.

( 1 ) Antenna unit 210

The antenna unit 210 emits one of the wireless communication unit 220 outputted signal into a room as a radio wave. Furthermore, the antenna unit converts 210 the radio wave in the room into a signal and gives the signal to the wireless communication unit 220 out.

Wireless communication device 220

The wireless communication unit 220 transmits and receives signals. For example, the wireless communication unit receives 220 a downlink signal from the base station and transmits an uplink signal to the base station.

Storage unit 230

The storage unit 230 temporarily or permanently stores a program and various data for operation of the terminal 200 ,

Processing unit 240

The processing unit 240 provides various functions of the terminal 200. The processing unit 240 has an authentication processing unit 241 and a communication processing unit 243 on. Furthermore, the processing unit 240 further include other components than the components described above. In other words, the processing unit 240 perform other operations than the operations of the components described above.

The workflows of the authentication processing unit 241 and the communication processing unit 243 will be described later in detail.

<Configuration example of the MEC server>

Next is an example of a configuration of the MEC server 300 according to an embodiment of the present disclosure with reference to 16 described. 16 is a block diagram illustrating an example of a configuration of the MEC server 300 in accordance with an embodiment of the present disclosure. With reference to 16 instructs the MEC server 300 a communication unit 310 , a storage unit 320 and a processing unit 330 on.

( 1 ) Communication unit 310

The communication unit 310 is an interface for performing communication with other devices. For example, the communication unit performs 310 a communication with a corresponding device. For example, the communication unit performs 310 in a case where the MEC server 300 is formed as a logical unit and in the base station 100 is included, a communication with, for example, a control unit of the base station 100 out. The MEC server 300 may have an interface for communicating directly with a device other than an integrally formed device.

Memory unit 320

The storage unit 320 temporarily or permanently saves a program and various data for the operation of the MEC server 300 , For example, the storage unit 320 store various content and applications to be provided to the user.

Processing unit 330

The processing unit 330 provides various functions of the MEC server 300 ready. The processing unit 330 has an authentication processing unit 331 and a communication processing unit 333 on. Furthermore, the processing unit 330 further include components other than such components. In other words, the processing unit 330 perform other operations than the workflows of such components.

The workflows of the authentication processing unit 331 and the communication processing unit 333 will be described in detail below. Here, though not in 16 represented, the processing unit 330 a content processing unit configured to the UE 200 To provide content or content from the UE 200 capture.

<Configuration Example of EPC Function Entity>

Next, an example of a configuration of the EPC function entity according to an embodiment of the present disclosure will be described with reference to FIG 17 described. The EPC function entity described here is for example an MME 41 or an HSS 42 , which have a similar configuration. Of course, the workflows of the components differ between the MMEs 41 and the HSS 42 , 17 FIG. 10 is a block diagram illustrating an example of a configuration of EPC function entities 41 and 42 according to an embodiment of the present disclosure. Referring to 16 have the EPC functional entities 41 and 42 a communication unit 410 , a storage unit 420 and a processing unit 430 on.

( 1 ) Communication unit 410

The communication unit 410 is an interface for performing communication with other devices. For example, the communication unit performs 410 a communication with other EPC functional entities.

Storage unit 420

The storage unit 420 temporarily or permanently saves a program and various data types for operation of the MME 41 or HSS 42 ,

Processing unit 430

The processing unit 430 represents different functions of the MME 41 or HSS 42 ready. The workflows of the processing unit 430 will be described in detail below.

The configuration examples of the respective devices have been described above. In the following, to simplify the description, the base station 100 also referred to as "eNodeB 100", and the terminal 200 is also referred to as "UE 200".

"3rd First embodiment »

The present embodiment has a form in which authentication is performed using authentication information stored in the MEC server 300 are stored.

<Technical problem>

Each of the entities (such as P-GW, S-GW, PCRF, HSS, and eNodeB) of the EPS is treated as a trusted entity, and mutual authentication between these entities is not standardized. On the other hand, since the UE is a device having a large number of unspecified users, a method of mutual authentication with the MME is standardized.

However, with respect to the MEC server, a mutual authentication procedure is not standardized. Although it is assumed that the MEC server is located near the eNodeB, it should not be treated as a trusted entity. This is because the MEC server can be provided by different service providers. Therefore, it is desirable to check the reliability for each MEC server.

Therefore, in the present embodiment, an operation for authenticating an MEC server is provided.

<Technical features>

( 1 ) Authentication process

The MEC server 300 performs communication with a network that is authenticated using authentication information provided to the MEC server 300 in the HSS 42 is registered.

The HSS 42 (For example, the storage unit 420 ) stores authentication information to the MEC server 300 correspond. In the present embodiment, the authentication information is the MEC server 300 Authentication information of the MEC server 300. More specifically, the authentication information includes the MEC server 300 a number (ie IMSI) representing the MEC server 300 identifies, and key information (ie a key K), for the MEC server 300 are specific. The HSS 42 stores an IMSI for each MEC server 300 and stores a key K, the IMSI of the MEC server 300 equivalent. Here is an IMSI in an MEC server 300 registered. Alternatively, a common IMSI of a plurality of MEC servers 300 be assigned to. Then lead the MME 41 (For example, the processing unit 430 ) and the HSS 42 (For example, the processing unit 430 ) Various processes for authenticating the MEC server 300 out.

The MEC server 300 (For example, the storage unit 320 ) stores authentication information of the MEC server 300 , Then, the MEC server 300 (for example, the authentication processing unit 331 ) authentication of the network using the authentication information of the MEC server 300 out. That is, as above with respect to 12 described that the MEC server 300 According to the present embodiment, authentication is performed according to a mechanism similar to a mechanism in which authentication of the UE is performed using the same authentication information that the UE and the HSS store. Then the MEC server performs 300 (For example, the communication processing unit 333 ) communicate with the authenticated network. Specifically represents the MEC server 300 the UE 200 Content ready or captures content from the UE 200 over the authenticated network (for example, the eNodeB 100 in the network). This will be the MEC server 300 is authenticated as a trusted entity and can be connected to the network.

For example, the MEC server 300 Store authentication information in hardware, such as a Universal Subscriber Identification Module (USIM). In this case, the storage unit is 320 implemented as hardware such as a USIM. In addition, authentication information can be implemented in software having functions similar to those of the USIM. In this case, the storage unit stores 320 the software. For example, the authentication information is registered by a corresponding operator of an MEC application.

Here is the MEC server 300 are used while networks of a plurality of operators (MNO: mobile network operators) are interposed. In this case, authentication information may be stored, for example, in an embedded subscriber identity module (SIM) and provided in the MEC server 300. Accordingly, it is possible to rewrite the authentication information remotely, using the MEC server 300 while networks are interposed by a plurality of operators. In this case, an entity rewriting authentication information sets up a communication path through an encryption process with the MEC server 300 is hidden, and then changes the authentication information.

The authentication process of the MEC server 300 is the same as above with reference to 12 with the exception that a subject performing the authentication moves from the UE to the MEC server 300 will be changed. An authentication process according to the present embodiment will be described below with reference to FIG 18 described.

18 Figure 4 is a sequence diagram illustrating an example of a flow of an authentication process occurring in the system 1 is executed according to the present embodiment. As in 18 The MEC server saves 300 an IMSI and a key K. In addition, the HSS stores 42 an IMSI of each MEC server 300 and a key K corresponding to the IMSI. This is where the MEC server communicates 300 with the MME 41 over the eNodeB 100.

First, the MEC server transmits 300 An attachment request together with the IMSI to the MME 41 (Step S102). Next, the MME transmits 41 an authentication request along with the received IMSI to the HSS 42 (Step S104). Next, the HSS generates 42 a random number RAND, the random number RAND, the received IMSI and the key K stored in connection with the IMSI are _inputted to the authentication function and receive an expected response RES _EXPECTED and a key K _ASME (step S106). Next, the HSS sends 42 the key K _ASME , the expected response RES _EXPECTED and the random number RAND to the MME 41 as an authentication response (step S108). Next, the MME transmits 41 the random number RAND to the MEC server 300 (Step S110). Next is the MEC server 300 the received random number RAND and the stored IMSI and the key K in the authentication function and receives a response RES and a key K _ASME (step S112). Next, the MEC server 300 transmits the response RES to the MME 41 (Step S114). Then the MME compares 41 the expected response RES _EXPECTED with an actual RES response and authenticates the MEC server 300 (Step S 116). In particular, if the expected response matches the actual response RES, the MME determines 41 that's the MEC server 300 reliable (that is, authentication is successful). On the other hand, if the expected response RES _EXPECTED does not match the actual response RES, the MME determines 41 that the MEC server 300 is not reliable (that is, the authentication fails).

Network variation

As described above, the MEC server can 300 an application server that is deployed within the EPS.

Alternatively, the MEC server 300 an application server provided on a Local Area Network (LAN) network. In this case, the MEC server 300 for example, provided in an access point of a wireless LAN. Then the MEC server performs 300 the AA process using the authentication information of the MEC server 300 through an extended packet data gateway (ePDG). Here, the ePDG is one of the entities of the EPC and is affiliated with P-GW. Typically, the ePDG authenticates a wireless LAN terminal.

<< Second Embodiment >>

The present embodiment has a form in which the UE 200 instead of the MEC server 300 performs an authentication.

<Technical problem>

In the first embodiment, the MEC server stores 300 Authentication information thereof. Typically, an appropriate operator of the MEC application places the authentication information in the MEC server 300 firmly. However, it is not easy to change authentication information in the MEC server 300 are stored, and it is difficult to get the authentication information in the MEC server 300 New to be added immediately. This is because the setting of authentication information by communication in consideration of the confidentiality of the authentication information (in particular, a key K) is not desirable. Even if the MEC server 300 From a remote location activated by communication (for example, starts), it is desirable that the MEC server 300 is authenticated more securely.

Therefore, in the present embodiment, a technology for securely performing the authentication of the MEC server 300 provided.

<Technical features>

In the present embodiment, the UE performs 200 (For example, the authentication processing unit 241 ) instead of the MEC server 300 an authentication.

The HSS 42 (For example, the storage unit 420 ) stores authentication information to the MEC server 300 correspond. In the present embodiment, the authentication information is the MEC server 300 correspond, authentication information of the UE 200 that the MEC server 300 assigned. In particular, the authentication information of the UE includes 200 a number (ie an IMSI) representing the UE 200 identifies, and key information (ie, a key K), for the UE 200 is specific. The HSS 42 stores identification information of the MEC server 300 that's the UE 200 assigned. The identification information will also be referred to as MEC Server ID below. For example, the HSS saves 42 the MEC server ID of the MEC server 300 that's the UE 200 is assigned as subscriber information of the UE 200 , Here, the MEC server ID is not a temporary ID, but identification information for the MEC server 300 are specific.

The UE 200 (For example, the authentication processing unit 241 ) performs in place of the MEC server 300 an authentication process of the MEC server 300 out to the UE 200 after the authentication process of the UE 200 is completed. In particular, the UE first performs 200 an authentication process of the UE 200 using the IMSI and the K key of the UE 200 out. Next, the UE transmits 200 an attachment request from the MEC server 300 to the MME 41 or the eNodeB 100. During transmission to the MME 41 a NAS signaling is used. During transmission to the eNodeB 100, RRC signaling is used. The MEC server ID is in the attach request of the MEC server 300 contain. The connection request of the MEC server 300 can be considered as a message that involves activation of the destination MEC server 300 requests.

When the attach request including the MEC server ID is received, the HSS checks 42 (eg the processing unit 430 ), whether the MEC server ID is in subscriber information provided to the UE 200 correspond as a transmission source of the attachment request is registered. Then the HSS answers 42 with an attach response that includes the test result. When the MEC server ID is registered, the HSS responds 42 with an attach response that includes a temporary ID. The temporary ID is an ID associated with the MEC server 300 assigned to the authentification succeeded. The temporary ID is also referred to below as the temporary ID of the MEC server. On the other hand, if the MEC server ID is not registered, the HSS responds 42 with an attach response that does not include a temporary MEC server ID. In this case, it is not possible to use the MEC server 300 to connect to the network.

The MEC server 300 (For example, the communication processing unit 333 ) performs communication with the network using information (ie, temporary MEC server ID) based on the request (that is, attachment request) from the UE 200 to be issued to the MEC server 300 which has succeeded in authenticating the network. The system 1 can identify if the MEC server 300 is authenticated based on the information output, thus ensuring security. In addition, in the present embodiment, it is possible to perform authentication without setting authentication information in the MEC server 300 and higher security is ensured.

The eNodeB 100 and the MME 41 capture and store the temporary ID of the MEC server when attaching the attachment to the UE 200 and allow access through the MEC server 300 that has the temporary ID of the MEC server. Therefore, the MEC server can 300 connected to the network while the temporary ID of the MEC server is valid.

While above, the attach request for each MEC server 300 described here, a similar authentication process can be performed here for any MEC application running in the MEC server 300 is working. For example, when a new MEC application is started, an attach operation of the MEC application may be performed. In this case, the attach response, which includes the temporary ID of the MEC server, can be considered as the start permission of the MEC application. The attach request, which includes the MEC server ID, may be considered as a start request of the MEC application. In addition, the MEC server ID and the temporary MEC server ID can be set for each MEC application.

An example of a flow of an authentication process when the UE 200 authentication instead of the MEC server 300 will be explained below with reference to 19 described.

19 Figure 4 is a sequence diagram illustrating an example of a flow of an authentication process occurring in the system 1 is executed according to the present embodiment. This is where the UE communicates 200 with the MME 41 over the eNodeB 100.

As in 19 represented, the UE performs 200 First, an attaching operation (step S202). In the attachment process, the above will be described with reference to FIG 12 described authentication process executed and the UE 200 is being authenticated. Next, the UE transmits 200 an attachment request from the MEC server 300 to the MME 41 (Step S204). The attach request has an MEC server ID of the MEC server 300 which is to be authenticated. Next, the MME transmits 41 the received attach request from the MEC server 300 to the HHS 42 (Step S206). Next, the HSS answers 42 with the attachment response of the MEC server 300 on the MME 41 (Step S208). In this case, the HSS checks 42 whether the MEC server ID of the MEC server 300 in the subscriber information of the UE 200 is registered as a transmission source of the attach request. A case where the MEC server ID is registered will be described below. That is, the temporary ID of the MEC server is included in the attach response. Next, the MME transmits 41 the received attachment response of the MEC server 300 to the eNodeB 100 (step S210), and the eNodeB 100 transmits the received attach response of the MEC server 300 to the MEC server 300 (Step S212). Then the MEC server 300 is attached to the network using the temporary MEC server ID included in the attach response (step S214).

. "5 Third embodiment »

The present embodiment has a form for communication by the MEC server 300 used keys are provided.

<Technical problem>

If the authentication process according to the first embodiment or the second embodiment is successful, the MEC server may 300 connected to the network and carry out a communication. Therefore, as in the case of the UE, it is desirable that keys used during actual communication (e.g., CK and IK) be generated after the authentication process. For example, it is desirable that the IK and the CK be responsible for communication between the MEC application and the MME 41 and the communication between the MEC application and the UE 200 to be generated.

A technology for generating and distributing keys necessary for communication from the MEC server 300 but is not provided.

<Technical features>

( 1 ) Key to communication between MEC application and MME 41

Key (ie CK and IK) for communication between the MEC application and the MME 41 are used, which are different for each MEC application.

In the first embodiment, keys to communication between the MEC application and the MME become 41 based on authentication information (ie, the IMSI and the key K of the MEC server 300) of the MEC server 300 generated. Specifically, first in the attach operation of the MEC server 300 a key K _ASME using authentication information of the MEC server 300 generated. Then keys (ie CK and IK) for communication between the MEC application and the MME 41 generated on the basis of the key K _ASME . The CK and the IK are collectively referred to as a K _{MEC Application-MME} key. That is, the key K _{MEC Application-MME} includes CK and IK.

In the second embodiment, keys for communication between the MEC application and the MME 41 on the basis of authentication information (ie, the IMSI and the key K of the UE 200) of the UE 200 generated by the MEC server 300 assigned. In particular, first in the attaching operation of the UE 200 a key K _ASME using the authentication information of the UE 200 generated. Then a key K _{MEC Application-MME} for communication between the MEC application and the MME 41 generated on the basis of the key K _ASME , using the authentication information of the UE 200 is generated. Here is the MME 41 via the key K _ASME in the attachment process of the UE 200 from the HSS 42 notifies (step S54, which is in 12 is shown). However, since the attaching operation of the UE 200 and the attachment process of the MEC server 300 are separate operations, it is not desirable that a key K _{MEC Application-MME} be generated at a time when the key K _{ASME is} in the attachment process of the UE 200 is generated. Therefore, the MME saves 41 (For example, the storage unit 420 ) the key K _ASME . If then the authentication of the MEC server 300 is successful generates the MME 41 (For example, the processing unit 430 ) a key K _{MEC Application MME} based on the stored key K _ASME and notifies the MEC server 300 via the generated key K _{MEC Application-MME} .

A system diagram of keys related to the K _{MEC Application-MME} key is in _FIG 20 shown. As in 20 is represented, a key K _{MEC Application-MME} based on K _{ASME of} the UE 200 generates the attach operation of the MEC server 300 has executed.

Key to communication between the MEC application and the UE 200

Key (ie CK and IK) for communication between the MEC application and the UE 200 are used for each UE 200 are different. This is because a majority of 00s use an MEC server 300 can be connected.

For example, keys to communication between the MEC application and the UE 200 on the basis of authentication information (ie the IMSI and the key K of the UE 200 ) of the UE 200 generated. In particular, first in the attaching operation of the UE 200 a key K _ASME using the authentication information of the UE 200 generated. Then, a key K _{eNodeB is generated} on the basis of the key K _ASME , and the CK and the IK for communication between the MEC application and the UE 200 are generated on the basis of the key K _eNodeB . The CK and the IK are collectively referred to as a key K _{UE-MEC Application} . That is, the key K _{UE-MEC Application} includes the CK and the IK. Here may be in terms of MEC applications running in the same MEC server 300 The same key K _{UE-MEC Application} or different key K _{UE-MEC Application can be used} among the plurality of MEC applications.

A system diagram of keys relating to the K _{UE-MEC Application} key is in _FIG 21 shown. As in 21 a key K _{eNodeB is generated} on the basis of the key K _ASME which is used in the attachment process of the UE 200 is generated, and a key K _{UE-MEC Application} is generated on the basis of the key K _eNodeB .

Characteristics of the keys between the MEC application and the MME 41 and the key between the MEC application and the MME 41 described above are shown in the following Table 3. [Table 3] Generation time Classification of the key separation Key between MEC application and MME After attaching the MEC application Use different keys for each MEC application Key between MEC application and UE After the attaching operation of the UE It is also possible to use the same key for MEC applications running on the same MEC server.

<< Fourth Embodiment >>

The present embodiment has a form in the other with the MEC server 300 related entities are authenticated.

<Technical problem>

The presence of a corresponding operator providing content such as a video and an application to the MEC server is assumed. Further, the presence of a content server for providing content is presupposed by the MEC server. Such a content server is also referred to below as an over-the-top server (OTT).

An example in which an OTT server exists is in 22 and 23 shown. In the example that is in 22 is an OTT server 500 arranged within the EPC. In the example that is in 23 is shown is the OTT server 500 arranged outside the EPC. If the OTT server 500 located outside the EPC, the OTT server can 500 directly with the MEC server 300 and may be connected via a P-GW 44, an S-GW 43 and the like.

Regardless of which arrangement example is used, it is the same as with the MEC server 300 desirable that the reliability of the OTT server 500 is checked.

Therefore, in the present embodiment, an operation for authenticating the OTT server becomes 500 provided.

<Configuration example of the OTT server>

Next is an example of a configuration of the OTT server 500 according to an embodiment of the present disclosure with reference to 24 described. 24 is a block diagram showing an example of a configuration of the OTT server 500 in accordance with an embodiment of the present disclosure. With reference to 24 The OTT server 500 has a communication unit 510 , a storage unit 520 and a processing unit 530 on.

( 1 ) Communication unit 510

The communication unit 510 is an interface for performing communication with other devices. For example, the communication unit communicates 510 directly with the MEC server 300 or communicates indirectly with the MEC server 300 about the P-GW 44, the S-GW 43 and the like.

Storage unit 520

The storage unit 520 Temporarily or permanently saves a program and various types of data for a workflow of the OTT server 500 , For example, the storage unit 520 store various types of content and applications to the MEC server 300 to be provided.

Processing unit 530

The processing unit 530 provides various functions of the OTT server 500 ready. The processing unit 530 has an authentication processing unit 531 and a communication processing unit 533 on. Here, the processing unit 530 may further comprise components other than these components. That is, the processing unit 530 In addition to the workflows of these components, it can also perform other operations.

The authentication processing unit 531 and the communication processing unit 533 have similar functions to the above-described authentication processing unit 331 and the communication processing unit 333 , Although in 24 not shown, the processing unit 530 a content processing unit configured to the MEC server 300 To provide content.

<Technical features>

Technical features, which are assumed in different cases, are described in the following order.

( 1 ) First case

The present case is a case where the OTT server 500 is located within the EPC and the OTT server 500 is treated as a reliable entity. In this case, an authentication process is to verify the reliability of the OTT server 500 again not required. Of course, in this case too, an authentication process can be used to verify the reliability of the OTT server 500 be executed.

Second case

The present case is a case where the OTT server 500 is located outside the EPC or the OTT server 500 within the EPC, but is treated as an unreliable entity. In this case, the OTT server can 500 authenticated by an authentication process similar to that of the MEC server 300 in the first embodiment is similar.

The OTT server 500 has similar technical features as the MEC server 300 according to the first embodiment. Entities like the MME 41 and the HSS 42 have the same technical features as in the first embodiment, except that a destination to be authenticated by the MEC server 300 into the OTT server 500 will be changed. That is, the technical characteristics of the present case correspond to features in which the MEC server 300 through the OTT server 500 is replaced in the description of the first embodiment.

The HSS 42 (For example, the storage unit 420 ) stores authentication information to the OTT server 500 correspond. In the present case, the authentication information corresponding to the OTT server 500 is authentication information of the OTT server 500 , More specifically, the authentication information includes the OTT server 500 a number (ie IMSI) representing the OTT server 500 identifies, and key information (ie a key K), for the OTT server 500 are specific. On the other hand, the OTT server saves 500 (For example, the storage unit 520 ) also authentication information of the OTT server 500 , Then, the OTT server 500 (for example, the authentication processing unit 531 Authentication of the network using the Authentication information of the OTT server 500 out. The OTT server 500 (For example, the communication processing unit 533 ) performs communication with the authenticated network. Exactly puts the OTT server 500 the MEC server 300 Content over the authenticated network (for example, the eNodeB 100 in the network). This will be the OTT server 500 is authenticated as a trusted entity and can be connected to the network.

The authentication process of the OTT server 500 is the same as above with reference to 18 with the exception that a subject performing the authentication is from the MEC server 300 into the OTT server 500 will be changed. An authentication process according to the present case will be described below with reference to FIG 25 described.

25 Figure 4 is a sequence diagram illustrating an example of a flow of an authentication process occurring in the system 1 is executed according to the present embodiment. As in 25 The OTT server saves 500 the IMSI and the key K. In addition, the HSS stores 42 the key K, the IMSI of the OTT server 500 equivalent. This is where the OTT server communicates 500 with the MME 41 over the eNodeB 100.

First, the OTT server transmits 500 An attachment request together with the IMSI to the MME 41 (Step S302). Next, the MME transmits 41 an authentication request along with the received IMSI to the HSS 42 (Step S304). Next, the HSS generates 42 a random number RAND, the random number RAND, the received IMSI, and the key K stored in association with the IMSI are _input to the authentication function and receive an expected response RES _EXPECTED and a key K _ASME (step S306). Next, the HSS sends 42 the key K _ASME , the expected response RES _EXPECTED and the random number RAND to the MME 41 as an authentication response (step S308). Next, the MME transmits 41 the random number RAND to the OTT server 500 (Step S310). Next is the OTT server 500 the received random number RAND and the stored IMSI and the key K in the authentication function and receives a response RES and a key K _ASME (step S312). Next, the OTT server 500 transmits the response RES to the MME 41 (Step S314). Then the MME compares 41 the expected response RES _EXPECTED with the actual response RES and authenticates the OTT server 500 (Step S316). In particular, if the expected response matches the actual response RES, the MME determines 41 that the OTT server 500 reliable (that is, authentication is successful). On the other hand, if the expected response RES _EXPECTED does not match the actual response RES, the MME determines 41 that the OTT server 500 is not reliable (that is, the authentication fails).

As a modified example of the present case, consider a case where the OTT server 500 directly with the MME 41 connected is. An arrangement example of the OTT server 500 in this case is in 26 shown. In the example that is in 26 is shown is the OTT server 500 arranged within the EPC and directly with the MME 41 connected. The authentication process in this case is the same as the one described above with reference to FIG 25 was described except that the OTT server 500 and the MME 41 do not communicate over any eNodeB 100. An authentication process according to the present case will be described below with reference to FIG 27 described.

27 Figure 4 is a sequence diagram illustrating an example of a flow of an authentication process occurring in the system 1 is executed according to the present embodiment. As in 27 The OTT server saves 500 the IMSI and the key K. In addition, the HSS stores 42 the key K, the IMSI of the OTT server 500 equivalent. This is where the OTT server communicates 500 with the MME 41 no eNodeB 100

First, the OTT server transmits 500 An attachment request together with the IMSI to the MME 41 (Step S402). Next, the MME transmits 41 an authentication request along with the received IMSI to the HSS 42 (Step S404). Next, the HSS generates 42 a random number RAND, the random number RAND, the received IMSI and the key K stored in association with the IMSI are _inputted to the authentication function and receive an expected response RES _EXPECTED and a key K _ASME (step S406). Next, the HSS sends 42 the key K _ASME , the expected response RES _EXPECTED and the random number RAND to the MME 41 as an authentication response (step S408). Next, the MME transmits 41 the random number RAND to the OTT server 500 (Step S410). Next is the OTT server 500 the received random number RAND and the stored IMSI and the key K in the authentication function and receives a response RES and a key K _ASME (step S412). Next, the OTT server 500 transmits the response RES to the MME 41 (Step S414). Then the MME compares 41 the expected response RES _EXPECTED with an actual response RES and authenticates the OTT server 500 (Step S416). In particular, if the expected response matches the actual response RES, the MME determines 41 that the OTT server 500 reliable (that is, authentication is successful). On the other hand, if the expected response RES _EXPECTED does not match the actual response RES, the MME determines 41 that the OTT server 500 is not reliable (that is, the authentication fails).

In the present case and the modified example, keys to communication between the OTT server 500 and the MME 41 and keys for communication between the OTT server 500 and the MEC application based on the authentication information of the OTT server 500 generated. Specifically, first in the attach operation of the OTT server 500 a key K _ASME using authentication information of the OTT server 500 generated. Then keys to communication between the OTT server 500 and the MME 41 and keys for communication between the OTT server 500 and the MEC application is generated based on the KASME key. The former key is referred to as the key K _{OTT Server-MME} and the latter key is referred to as the K _{OTT Server-MEC Application} key. That is, the key K _{OTT server MME} includes CK and IK. That is, the K _{OTT Server-MEC Application} key includes CK and IK. A system diagram of this key is in 28 shown. As in 28 A key K _{OTT server MME} and a key K _{OTT Server MEC Application are} generated based on the K _ASME in the attach operation of the OTT server 500 is generated.

Third case

The present case is a case where the UE 200 instead of the OTT server 500 performs an authentication.

The OTT server 500 has similar technical features as the MEC server 300 according to the second embodiment. Entities like the UE 200 , the MME 41 and the HSS 42 have the same technical features as in the second embodiment, except that a destination to be authenticated by the MEC server 300 into the OTT server 500 will be changed. That is, the technical characteristics of the present case correspond to features in which the MEC server 300 through the OTT server 500 is replaced in the description of the second embodiment.

The HSS 42 (For example, the storage unit 420 ) stores authentication information to the OTT server 500 correspond. In the present case, the authentication information corresponding to the OTT server 500 is authentication information of the UE 200 associated with the MEC server 500. The UE 200 (For example, the authentication processing unit 241 ) performs authentication instead of the OTT server 500. The OTT server 500 (For example, the communication processing unit 533 ) performs communication with the network using information based on the request (that is, attachment request) from the UE 200 to be issued to the OTT server 500 which has succeeded in authenticating the network. Here are identification information specific to the OTT server 500 and the MEC server ID in the second embodiment, hereinafter also referred to as an OTT server ID. In addition, information based on the request from the UE 200 are issued when the authentication of the network has been successful, and which correspond to the temporary ID of the MEC server in the second embodiment, hereinafter also referred to as the temporary OTT server ID.

An example of a flow of an authentication process when the UE 200 authentication instead of the OTT server 500 will be explained below with reference to 29 described.

29 Figure 4 is a sequence diagram illustrating an example of a flow of an authentication process occurring in the system 1 is executed according to the present embodiment. This is where the UE communicates 200 with the MME 41 over the eNodeB 100.

As in 29 represented, the UE performs 200 First, an attaching operation (step S202). In the attachment process, the above will be described with reference to FIG 12 described authentication process executed. Next, the UE transmits 200 An attachment request from the OTT server 500 to the MME 41 (Step S204). The attach request has an OTT server ID, which is identifier information for the OTT server 500 are specific, which should be authenticated. Next, the MME transmits 41 the received attach request from the OTT server 500 to the HHS 42 (Step S506). Next, the HSS answers 42 with the attachment response of the OTT server 500 to the MME 41 (step S508). In this case, the HSS checks 42 , whether the OTT server ID of the OTT server 500 in the subscriber information of the UE 200 as one Transmission source of the attachment request is registered. A case where the OTT server ID is registered will be described below. That is, the temporary ID of the OTT server is included in the attach response. Next, the MME transmits 41 the received attach response of the OTT server 500 to the eNodeB 100 (step S510), and the eNodeB 100 transmits the received attach response of the OTT server 500 to the MEC server 500 (Step S512). Then the OTT server 500 is attached to the network using the temporary OTT server ID included in the attach response (step S514).

In the present case, keys for communication between the OTT server 500 and the MME 41 and keys for communication between the OTT server 500 and the MEC application based on the UE's authentication information 200 generated. In particular, first in the attaching operation of the UE 200 a key K _ASME using the authentication information of the UE 200 generated. Then a key K _{OTT server MME} for communication between the OTT server 500 and the MME 41 and a key K _{OTT Server MEC Application} for communication between the OTT server 500 and the MEC application generated based on the key KASME. A system diagram of this key is in 30 shown. As in 30 Shown are a key K _{OTT server MME} and a key K _{OTT Server MEC Application} based on K _{ASME of} the UE 200 generates the attach operation of the OTT server 500 has executed.

Fourth case

The present case is a case where the OTT server 500 instead of the MEC server 300 performs an authentication. The OTT server 500 has similar technical characteristics as the UE 200 according to the second embodiment. Entities such as the MEC server 300 , the MME 41 and the HSS 42 have the same technical features as in the second embodiment, except that the authentication process using the authentication information of the UE 200 in an authentication process using authentication information of the OTT server 500 will be changed. That is, the technical features of the present case correspond to features in which the UE 200 through the OTT server 500 is replaced in the description of the second embodiment.

The HSS 42 (For example, the storage unit 420 ) stores authentication information to the MEC server 300 correspond. In the present case, the authentication information corresponding to the MEC server 300 is authentication information of the OTT server 500 that's the MEC server 300 assigned. In particular, the HSS saves 42 (for example, the storage unit 420 ) Identification information of the MEC server 300 the OTT server 500 is assigned, ie the MEC server ID. For example, the HSS saves 42 the MEC server ID of the MEC server 300 the OTT server 500 is assigned as subscriber information of the OTT server 500 ,

After that, the OTT server will run 500 (For example, the authentication processing unit 531 ) instead of the MEC server 300 an authentication. The MEC server 300 (For example, the communication processing unit 333 ) performs communication with the network using information (ie, temporary MEC server ID) based on the request (that is, attachment request) from the OTT server 500 to be issued to the MEC server 300 which has succeeded in authenticating the network. The system 1 can identify if the MEC server 300 is authenticated based on the information output, thus ensuring security.

Here, a case is considered in which the OTT server 500 itself has no authentication information and the UE 200 instead of the OTT server 500 performs an authentication as described above with reference to 29 described. In this case, the authentication information used to authenticate the MEC server 300 used to the network, authentication information of the UE 200 be that in place of the OTT server 500 performs an authentication of the UE 200 is that the MEC server 300 assigned. In this case, the HSS saves 42 (For example, the storage unit 420 ), for example, the OTT server ID and the MEC server ID as subscriber identification information of the UE 200 ,

An example of a flow of an authentication process when the OTT server 500 instead of the MEC server 300 performs an authentication will be described below with reference to 31 described.

31 Figure 4 is a sequence diagram illustrating an example of a flow of an authentication process occurring in the system 1 is executed according to the present embodiment. Here, the OTT server 500 communicates with the MME 41 over the eNodeB 100.

As in 31 represented, the UE performs 500 first, an attaching operation (step S602). In the attachment process, the above will be described with reference to FIG 27 or 29 described authentication process executed and the OTT server 500 is being authenticated. Next, the OTT server transfers 500 an attachment request from the MEC server 300 to the MME 41 (Step S604). The attach request has an MEC server ID of the MEC server 300 which is to be authenticated. Next, the MME transmits 41 the received attach request from the MEC server 300 to the HHS 42 (Step S606). Next, the HSS answers 42 with the attachment response of the MEC server 300 on the MME 41 (Step S608). In this case, the HSS checks 42 whether the MEC server ID of the MEC server 300 in the subscriber information of the OTT server 500 is registered as a transmission source of the attachment request, or the UE 200 authentication instead of the OTT server 500 performs. A case where the MEC server ID is registered will be described below. That is, the temporary ID of the MEC server is included in the attach response. Next, the MME transmits 41 the received attachment response of the MEC server 300 to the eNodeB 100 (step S610) and the eNodeB 100 transmits the received attach response of the MEC server 300 (Step S612). Then the MEC server 300 is attached to the network using the temporary MEC server ID included in the attach response (step S614).

<< Examples >>

The technology according to the present disclosure can be applied to various products. For example, the MEC server 300, the MME 41 , the HSS 42 or the OTT server 500 be realized as a server of any type such as a tower server, a rack server, a blade server or the like. In addition, at least part of the components of the MEC server 300 , the MME 41 , the HSS 42 or the OTT server 500 may be implemented in a module mounted in a server (eg, an integrated circuit module configured in a chip, card, or blade inserted into a slot of a blade server) is.

In addition, the terminal may 200 for example, as a mobile terminal such as a smart phone, a tablet personal computer (PC), a notebook PC, a portable game terminal, a portable / dongleartiger mobile router or a digital camera or an in-vehicle terminal, such as a car navigation device or the like may be implemented. In addition, the terminal may 200 be implemented as a terminal that performs machine-to-machine (M2M) communication (also referred to as Machine Communication Type (MTC) terminal). Furthermore, at least a part of the components of the terminal 200 in a module mounted in such a terminal (for example, an IC module configured in a chip).

<Application example regarding server>

32 FIG. 10 is a block diagram showing an example of a schematic configuration of a server 700 to which the technology of the present disclosure can be applied. The server 700 includes a processor 701, a main memory 702, a memory 703, a network interface 704, and a bus 706.

The processor 701 may be, for example, a central processing unit (CPU) or a digital signal processor (DSP) and control various functions of the server 700. The main memory 702 includes a random access memory (RAM) and a read only memory (ROM) and stores programs executed by the processor 701 and data. The memory 703 may include a storage medium such as a semiconductor memory or a hard disk.

The network interface 704 is a wired communication interface for connecting the wireless access point 700 to a wired communication network 705. The wired communication network 705 may be a core network such as an evolved packet core (EPC) or a packet data network (PDN) such as the Internet.

Bus 706 interconnects processor 701, main memory 702, memory 703, and network interface 704. Bus 706 may have two or more buses operating at different speeds (eg, a high speed bus and a low speed bus).

In the server 700, the in 32 may be one or more components (the authentication processing unit 331 and / or the communication processing unit 333 ) in the MEC server 300 are included with respect to 16 described to be mounted in the processor 701. In addition, one or more components (the processing unit 430 ), which in the MME 41 or the HSS 42 are included with respect to 17 may be mounted in the processor 701. In addition, one or more components (the authentication processing unit 531 and / or the communication processing unit 533 ) in the OTT server 500 are included with respect to 24 described to be mounted in the processor 701. For example, a program for causing a processor as the one or more components (ie, a program to cause a processor to perform operations of the one or more components) may be installed in the server 700, and the processor 701 may program To run. As another example, a module including processor 701 and memory 702 may be mounted in server 700, and the one or more components may be implemented by the module. In this case, the module may store a program to cause a processor to function as the one or more components in main memory 702, and the program may be executed by processor 701. The server 700 or module may be provided as devices having the one or more components described above, as described above, or the program for causing a processor to function as the one or more components may be provided. In addition, a readable recording medium in which the program is recorded may be provided.

In the server 700, the in 32 is shown, the communication unit 310 referring to above 16 is described, the communication unit 410 referring to above 17 is described, or the communication unit 510 referring to above 24 may be mounted in the network interface 704. Also, in the server 700, which is in 32 is shown, the storage unit 320 referring to above 16 is described, the storage unit 420 referring to above 17 is described, or the storage unit 520 referring to above 24 may be mounted in the main memory 702 or the memory 703.

<Application example relating to terminal>

(First application example)

33 FIG. 10 is a block diagram showing an example of a schematic configuration of a smartphone 900 to which the technology of the present disclosure can be applied. Smartphone 900 includes processor 901, main memory 902, memory 903, external connection interface 904, camera 906, sensor 907, microphone 908, input device 909, display 910, speaker 911, wireless communication interface 912, one or more antenna switches 915, one or more antennas 916, a bus 917, a battery 918, and an auxiliary controller 919.

The processor 901 may be, for example, a CPU or a system-on-a-chip (SoC), and controls functions of an application layer and other layers of the smartphone 900. The memory 902 includes a RAM and a ROM and stores a program executed by the Processor 901 is executed, and data. The memory 903 may include a storage medium such as a semiconductor memory and a hard disk. The external connection interface 904 is an interface for connecting an external device such as a memory card and a universal serial bus (USB) device to the smartphone 900.

The camera 906 has an image sensor such as a charge-coupled device (CCD) and a complementary metal-oxide semiconductor (CMOS), and takes a captured image. The sensor 907 may include a group of sensors, such as a measurement sensor, a gyrosensor, a geomagnetic sensor, and an acceleration sensor. The microphone 908 converts sounds input to the smartphone 900 into audio signals. The input device 909 includes, for example, a touch sensor configured to detect touches on a screen of the display device 910, a key pad, a keyboard, a knob, or a switch to receive a workflow or information input from a user. The display device 910 has a screen such as a liquid crystal display (LCD) or an OLED (Organic Light Emitting Diode) display for displaying output images of the smartphone 900. The speaker 911 converts audio signals output from the smartphone 900 into sound.

The wireless communication interface 912 supports any cellular communication scheme such as LTE and LTE-Advanced, and performs wireless communication. The wireless communication interface 912 may typically include, for example, a BB processor 913 and an RF circuit 914. The BB processor 913 may perform, for example, encoding / decoding, modulating / demodulating, and multiplexing / demultiplexing, and executes various types of signal processing for wireless communication. Meanwhile, the RF circuit 914 may include, for example, a mixer, a filter and an amplifier, and transmits and receives radio signals via the antenna 916. The wireless communication interface 912 may also be a one-chip module on which the BB processor 913 and the RF circuit 914 are integrated. The wireless communication interface 912 may include the plurality of BB processors 913 and the plurality of RF circuits 914, as in FIG 33 shown. Although 33 For example, where wireless communication interface 912 includes multiple BB processors 913 and multiple RF circuits 914, wireless communication interface 912 may also include a single BB processor 913 or a single RF circuit 914.

Further, in addition to a cellular communication scheme, the wireless communication interface 912 may support another type of wireless communication scheme, such as a short distance wireless communication scheme, a near field communication scheme, and a wireless local area network (LAN) scheme. In this case, the wireless communication interface 912 may include the BB processor 913 and the RF circuitry 914 for each wireless communication scheme.

Each of the antenna switches 915 switches connection destinations of the antennas 916 between a plurality of circuits (such as circuits for different wireless communication schemes) included in the wireless communication interface 912.

Each of the antennas 916 has a single or multiple antenna elements (such as a plurality of antenna elements included in a MIMO antenna) and is used for the wireless communication interface 912 for transmitting and receiving radio signals. The smartphone 900 may include the plurality of antennas 916, as in FIG 33 shown. Although 33 Illustrating the example in which the smartphone 900 has the plurality of antennas 916, the smartphone 900 may also include a single antenna 916.

Further, the smartphone 900 may include the antenna 916 for each wireless communication scheme. In this case, the antenna switches 915 in the configuration of the smartphone 900 may be omitted.

The bus 917 connects the processor 901, the main memory 902, the memory 903, the external connection interface 904, the camera 906, the sensor 907, the microphone 908, the input device 909, the display device 910, the speaker 911, the wireless Communication interface 912 and the auxiliary control 919 with each other. The battery 918 supplies power to 33 illustrated blocks of the smartphone 900 via power supply lines, which are partially shown by dashed lines in the figure. The auxiliary controller 919 operates a minimum necessary function of the smartphone 900, for example, in a sleep mode.

In the smartphone 900, which in 33 may be one or more components included in the terminal 200 (the authentication processing unit 241 and / or the communication processing unit 243 ) in relation to 15 described by the wireless communication interface 912. Alternatively, at least some of these components may be implemented by the processor 901 or the auxiliary controller 919. For example, a module that includes a portion (eg, the BB processor 913) or the entire wireless communication interface 912, the processor 901, and / or the auxiliary controller 919 may be mounted in the smartphone 900 and the one or more components can be implemented by the module. In this case, the module may store a program to cause the processor to function as the one or more components (ie, a program to cause the processor to perform operations of the one or more components) and execute the program , As another example, the program may be installed in the smartphone 900 to cause the processor to function as the one or more components and the wireless communication interface 912 (eg, the BB processor 913), the processor 901, and / or the auxiliary controller 919 may execute the program. As described above, the smartphone 900 or module may be provided as a device having the one or more components and the program for causing the processor to be one or more Ingredients can be provided. In addition, a readable recording medium in which the program is recorded may be provided.

In the in 33 For example, the smartphone 900 illustrated may be the wireless communication unit 220 referring to above 15 described in the wireless communication interface 912 (for example, the RF circuit 914) to be mounted. Furthermore, the antenna unit 210 be mounted on the antenna 916. Furthermore, the storage unit 230 be mounted in the main memory 902.

(Second example of use)

34 FIG. 10 is a block diagram showing an example of a schematic configuration of a car navigation device 920 to which the technology of the present disclosure can be applied. The car navigation device 920 includes a processor 921, a main memory 922, a Global Positioning System (GPS) module 924, a sensor 925, a data interface 926, a content player 927, a storage media interface 928, an input device 929, a display device 930, a speaker 931 , a wireless communication interface 933, one or more antenna switches 936, one or more antennas 937, and a battery 938.

The processor 921 may be, for example, a CPU or an SOC, and controls a navigation function and other functions of the car navigation device 920. The memory 922 includes a RAM and a ROM, and stores a program executed by the processor 921 and data.

The GPS module 924 uses GPS signals received from a GPS satellite to measure a position (such as latitude, longitude, and altitude) of the car navigation device 920. The sensor 925 may include a group of sensors, such as a gyrosensor, a geomagnetic sensor, and a barometric sensor. For example, the data interface 926 is connected to an in-vehicle network 941 via a terminal, not shown, and acquires data generated by the vehicle, such as vehicle speed data.

The content player 927 reproduces content stored in a storage medium (for example, a CD and a DVD) inserted in the storage media interface 928. For example, the input device 929 includes a touch sensor configured to detect touches on a screen of the display device 930, a button or a switch, and receives a workflow or information input from a user. The display device 930 has a screen, such as an LCD or an OLED display, and displays an image of the navigation function or reproduced content. The speaker 931 outputs sounds of the navigation function or reproduced content.

The wireless communication interface 933 supports any cellular communication scheme such as LET and LTE-Advanced, and performs wireless communication. The wireless communication interface 933 may typically include, for example, a BB processor 934 and an RF circuit 935. The BB processor 934 may perform, for example, encoding / decoding, modulating / demodulating, and multiplexing / demultiplexing, and executes various types of signal processing for wireless communication. Meanwhile, the RF circuit 935 may include, for example, a mixer, a filter and an amplifier, and transmits and receives radio signals via the antenna 937. The wireless communication interface 933 may be a one-chip module on which the BB processor 934 and the RF Circuit 935 are integrated. The wireless communication interface 933 may include the plurality of BB processors 934 and the plurality of RF circuits 935, as in FIG 34 shown. Although 34 For example, where the wireless communication interface 933 includes the multiple BB processors 934 and the multiple RF circuits 935, the wireless communication interface 933 may also include a single BB processor 934 or a single RF circuit 935.

Further, in addition to a cellular communication scheme, the wireless communication interface 933 may support another type of wireless communication scheme, such as a short distance wireless communication scheme, a near field communication scheme, and a wireless LAN scheme. In this case, the wireless communication interface 933 may include the BB processor 934 and the RF circuitry 935 for each wireless communication scheme.

Each of the antenna switches 936 switches connection destinations of the antennas 937 between a plurality of circuits (such as circuits for different wireless communication schemes) included in the wireless communication interface 933.

Each of the antennas 937 has a single or multiple antenna elements (such as a plurality of antenna elements included in a MIMO antenna) and is used for the wireless communication interface 933 for transmitting and receiving radio signals. The car navigation device 920 may include the plurality of antennas 937, as in FIG 34 shown. Although 34 For example, in which the car navigation device 920 has the plurality of antennas 937, the car navigation device 920 may include a single antenna 937.

Further, the vehicle navigation device 920 may include the antenna 937 for each wireless communication scheme. In this case, the antenna switches 936 may be omitted from the configuration of the car navigation device 920.

The battery 938 supplies power to 34 illustrated blocks of the car navigation device 920 via power supply lines, which are partially shown by dashed lines in the figure. The battery 938 accumulates power supplied by the vehicle.

In the car navigation device 920 included in 34 may be one or more components included in the terminal 240 (the authentication processing unit 241 and / or the communication processing unit 243 ) in relation to 15 described be implemented by the wireless communication interface 933. Alternatively, at least some of these components may be implemented by the processor 921. For example, a module having a portion (eg, the BB processor 934) or the entire wireless communication interface 933 and / or the processor 921 may be mounted in the car navigation device 920, and the one or more components may be from the module be implemented. In this case, the module may store a program to cause the processor to function as the one or more components (ie, a program to cause the processor to perform operations of the one or more components) and execute the program , As another example, the program may be installed in the car navigation device 920 to cause the processor to function as the one or more components, and the wireless communication interface 933 (eg, the BB processor 934), the processor 921 may program To run. As described above, the car navigation device 920 or module may be provided as a device having the one or more components, and the program for causing the processor to function as the one or more components may be provided. In addition, a readable recording medium in which the program is recorded may be provided.

Furthermore, in the in 34 The vehicle navigation device 920 shown in FIG. 1, for example, the wireless communication unit 220 referring to above 15 described in the wireless communication interface 933 (for example, the RF circuit 935) to be mounted. Furthermore, the antenna unit 210 be mounted on the antenna 937. Furthermore, the storage unit 230 be mounted in the main memory 922.

The technology of the present disclosure may also be implemented as an in-vehicle system (or vehicle) 940 including one or more blocks of the car navigation device 920, the in-vehicle network 941, and a vehicle module 942. In other words, the in-vehicle system (or a vehicle) 940 may be provided as a device including the authentication processing unit 241 and / or the communication processing unit 243 having. The on-vehicle module 942 generates vehicle data such as a vehicle speed, an engine speed, and error information, and outputs the generated data to the in-vehicle network 941.

<< Summary >>

Hereinabove, embodiments of the present disclosure have been described with reference to FIG 1 to 34 described in detail. As described above, the MEC server performs 300 or the OTT server 500 communication with a network that is authenticated using authentication information similar to that in the HSS 42 registered server and provides content. This will prevent the MEC server 300 or the OTT server 500 whose reliability is not confirmed connected to the network. If key to communication through the MEC server 300 or the OTT server 500 In addition, the confidentiality of a communication path between the MEC server 300 or the OTT server 500 and the MME 41 or the UE 200 be improved.

The preferred embodiment (s) of the present disclosure has been described above with reference to the accompanying drawings, although the present disclosure is not limited to the above examples. A person skilled in the art may find various changes and modifications within the scope of the appended claims, and it should be understood that they will, of course, be within the technical scope of the present disclosure.

For example, the above-described embodiments may be appropriately combined.

It should be noted that the processes described in this specification with reference to the flowchart and the sequence diagram must be performed in the order illustrated in the flowchart. Some processing steps can be performed in parallel. Further, some additional steps may be used or some processing steps may be omitted.

Furthermore, the effects described in this specification are merely illustrative or exemplary effects and are not limiting. That is, with or instead of the above effects, the technology according to the present disclosure can achieve other effects that will be apparent to those skilled in the art from the description of this specification.

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.

In addition, the present technology may also be configured as described below.

1. (1) a server configured to provide content to another device, the server comprising:
   • a processing unit configured to communicate with a network that is authenticated using authentication information corresponding to the server registered in a Home Subscriber Server (HSS).
2. (2) Server to ( 1 ), wherein the authentication information corresponding to the server is authentication information of the server.
3. (3) The server of (2), wherein the authentication information of the server has a number identifying the server and key information specific to the server.
4. (4) The server of (2) or (3), further comprising:
   • a storage unit configured to store the authentication information of the server,
   • wherein the processing unit performs authentication of the network using the authentication information of the server.
5. (5) The server according to any one of (2) to (4), wherein a key for communication between an application operating in the server and an MME is generated based on the authentication information of the server.
6. (6) Server to ( 1 ), wherein the authentication information corresponding to the server is authentication information of a terminal associated with the server.
7. (7) The server according to (6), wherein the authentication information of the terminal has a number identifying the server and key information specific to the terminal.
8. (8) The server according to (6) or (7), wherein the processing unit performs communication with the network using information issued based on a request from the terminal associated with the server that succeeded in authenticating the network is.
9. (9) The server according to (8), wherein a key for communication between an application operating in the server and an MME is generated based on the authentication information of the terminal associated with the server.
10. (10) server after one of ( 1 ) till 9), wherein a key for the communication between a terminal and an application operating in the server is generated based on authentication information of the terminal.
11. (11) server after one of ( 1 ) to ( 10 ), where the server is an application server provided in an EPS.
12. (12) The server according to (11), wherein the authentication information corresponding to the server is authentication information of another server assigned to the server.
13. (13) The server according to (12), wherein the processing unit communicates with the network using information issued based on a request from the other server associated with the server that succeeded in authenticating the network.
14. (14) The server of (12) or (13), wherein the other server is a content server providing content to the server.
15. (15) server after one of ( 1 ) to ( 10 ), wherein the server is a content server providing content to an application server provided in an EPS.
16. (16) The server of (15), wherein the server communicates with an MME via a base station.
17. (17) The server according to (15), wherein the server does not communicate with an MME through any base station.
18. (18) Server after one of ( 1 ) to ( 10 ), wherein the server is an application server provided in a wireless LAN network.
19. (19) Method comprising:
    • Executing, from a server configured to provide content to another device, communication with a network that is authenticated using authentication information corresponding to the server registered in an HSS.
20. (20) Program that causes a computer to function as follows:
    • as a server providing content to another device and having a processing unit configured to communicate with a network that is authenticated using authentication information corresponding to the server registered in an HSS.

LIST OF REFERENCE NUMBERS

1

system

10

cell

40

Core network

41

MME

42

HSS

43

S-GW

44

P-GW

50

PDN

60

application server

100

wireless communication device

200

terminal

210

antenna unit

220

wireless communication unit

230

storage unit

240

processing unit

241

Authentication processing unit

243

Communication processing unit

300

MEC server

310

communication unit

320

storage unit

330

processing unit

331

Authentication processing unit

333

Communication processing unit

410

communication unit

420

storage unit

430

processing unit

500

OTT server

510

communication unit

520

storage unit

530

processing unit

531

Authentication processing unit

533

Communication processing unit

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• AP 100 C [0017]

Cited non-patent literature

• "Mobile Edge Computing Introductory Technical White Paper", September, 2014, [searched 3 September 2015] [0004]

Claims (20)

A server configured to provide content to another device, the server comprising: a processing unit configured to communicate with a network that is authenticated using authentication information corresponding to the server registered in a Home Subscriber Server (HSS). Server after Claim 1 wherein the authentication information corresponding to the server is authentication information of the server. Server after Claim 2 wherein the authentication information of the server comprises a number identifying the server and key information specific to the server. Server after Claim 2 further comprising: a storage unit configured to store the authentication information of the server, wherein the processing unit performs authentication of the network using the authentication information of the server. Server after Claim 2 wherein a key is generated for communication between an application operating in the server and an MME based on the authentication information of the server. Server after Claim 1 wherein the authentication information corresponding to the server is authentication information of a terminal associated with the server. Server after Claim 6 wherein the authentication information of the terminal comprises a number identifying the server and key information specific to the terminal. Server after Claim 6 wherein the processing unit communicates with the network using information issued based on a request from the terminal associated with the server that has succeeded in authenticating the network. Server after Claim 8 wherein a key for communication between an application operating in the server and an MME is generated based on the authentication information of the terminal associated with the server. Server after Claim 1 wherein a key for the communication between a terminal and an application operating in the server is generated based on authentication information of the terminal. Server after Claim 1 wherein the server is an application server provided in an EPS. Server after Claim 11 wherein the authentication information corresponding to the server is authentication information of another server associated with the server. Server after Claim 12 wherein the processing unit communicates with the network using information issued based on a request from the other server associated with the server that succeeded in authenticating the network. Server after Claim 12 where the other server is a content server that provides content to the server. Server after Claim 1 wherein the server is a content server that provides content to an application server provided in an EPS. Server after Claim 15 wherein the server communicates with an MME via a base station. Server after Claim 15 wherein the server does not communicate with an MME via any base station. Server after Claim 1 wherein the server is an application server provided on a wireless LAN network. A method comprising: Executing, from a server configured to provide content to another device, communication with a network that is authenticated using authentication information corresponding to the server registered in an HSS. Program that causes a computer to act as follows: as a server providing content to another device and having a processing unit configured to communicate with a network that is authenticated using authentication information corresponding to the server registered in an HSS.

Images