TW201727524A - Server, method, and program - Google Patents

Abstract

To provide a mechanism for ensuring security relating to an edge server. A server that provides content to other devices, the server being provided with a processing unit that performs communication with a network against which the server has been authenticated by using authentication information registered in an HSS (Home Subscriber Server) and associated with the server.

Description

Server, method and program

This disclosure relates to servers, methods, and programs.

In recent years, data processing has been carried out with a server (hereinafter also referred to as an edge server) that is placed in a physical proximity to a terminal such as a smart phone, and a technique called Mobile Edge Computing (MEC) is being implemented. Received attention. For example, it is disclosed in Non-Patent Document 1 below, and the standard specifications of the MEC technology are discussed.

In the MEC, an edge server is disposed at a location close to the physical entity of the terminal, so that the communication delay is shortened compared to the general cloud server that is centrally configured, making it possible to utilize applications requiring high immediacy. . Further, in the MEC, the edge server that is close to the terminal is distributed by the function that has been processed on the terminal side so far, and high-speed network application processing can be realized without being limited to the performance of the terminal. The edge server can have various functions such as an function as an application server and a function as a content server, and can provide various services to the terminal.

[Previous Technical Literature]

[Non-patent literature]

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

The contents of the discussion in Non-Patent Document 1 and the like are not long before the start of the discussion. Therefore, the technology of the MEC is difficult to be fully proposed. For example, the technology needed to guarantee the security of edge servers is one of the technologies that have not been fully proposed.

According to the disclosure, there is provided a server that provides a server that provides content to another device, and includes a processing unit that corresponds to a server that has been registered in the HSS (Home Subscriber Server). A network that is certified to authenticate information and communicate.

Further, according to the present disclosure, there is provided a method comprising: a server authenticated by using a server that provides content to other devices, and authentication information corresponding to the server that has been registered in the HSS before login; , for communication.

Moreover, according to the present disclosure, a program can be provided for causing a computer to function as a server that provides content to other devices, and the server includes: a processing unit that is associated with the used HSS The network authenticated by logging in to the authentication information corresponding to the server before communication.

As explained above, in accordance with the present disclosure, a mechanism for securing the security of the edge server can be provided. In addition, the effect of the above is not necessarily limited to the explanation, and may be combined with the effect of the above, or the effect of the above, to achieve any of the effects to be disclosed in the present specification, or other effects that can be grasped according to the present specification.

1‧‧‧ system

10‧‧‧Hive net

40‧‧‧core network

41‧‧‧MME

42‧‧‧HSS

43‧‧‧S-GW

44‧‧‧P-GW

50‧‧‧PDN

60‧‧‧Application Server

100‧‧‧Wireless communication device

200‧‧‧ Terminals

210‧‧‧Antenna Department

220‧‧‧Wireless Communications Department

230‧‧‧Memory Department

240‧‧‧Processing Department

241‧‧‧Authorization and Processing Department

243‧‧‧Communication Processing Department

300‧‧‧MEC server

310‧‧‧Communication Department

320‧‧‧Memory Department

330‧‧‧Processing Department

331‧‧‧Authority Processing Department

333‧‧‧Communication Processing Department

410‧‧‧Communication Department

420‧‧‧Memory Department

430‧‧‧Processing Department

500‧‧‧ OTT server

510‧‧‧Communication Department

520‧‧‧Memory Department

530‧‧‧Processing Department

531‧‧‧Authority Processing Department

533‧‧‧Communication Processing Department

700‧‧‧Server

701‧‧‧ processor

702‧‧‧ memory

703‧‧‧ storage

704‧‧‧Network interface

705‧‧‧Wired communication network

706‧‧‧ Busbar

900‧‧‧Smart Phone

901‧‧‧ processor

902‧‧‧ memory

903‧‧‧ storage

904‧‧‧ External connection interface

906‧‧‧ camera

907‧‧‧ sensor

908‧‧‧ microphone

909‧‧‧Input device

910‧‧‧ display device

911‧‧‧ Speaker

912‧‧‧Wireless communication interface

913‧‧‧BB processor

914‧‧‧RF circuit

915‧‧‧Antenna switch

916‧‧‧Antenna

917‧‧ ‧ busbar

918‧‧‧Battery

919‧‧‧Auxiliary controller

920‧‧‧Driving navigation device

921‧‧‧ processor

922‧‧‧ memory

924‧‧‧GPS module

925‧‧‧ sensor

926‧‧‧Information interface

927‧‧‧Content Player

928‧‧‧Memory Media Interface

929‧‧‧ input device

930‧‧‧ display device

931‧‧‧Speakers

933‧‧‧Wireless communication interface

934‧‧‧BB processor

935‧‧‧RF circuit

936‧‧‧Antenna switch

937‧‧‧Antenna

938‧‧‧Battery

940‧‧‧In-vehicle system

941‧‧‧Car network

942‧‧‧Vehicle side module

Fig. 1 is an explanatory diagram showing an example of a schematic configuration of a system 1 according to an embodiment of the present disclosure.

FIG. 2 is a diagram showing an example of a configuration of an LTE network in which no MEC is introduced.

FIG. 3 is a diagram showing an example of a configuration of an LTE network into which an MEC has been introduced.

FIG. 4 is a diagram showing an example of a configuration of an LTE network into which an MEC has been introduced.

[Fig. 5] A diagram showing an example of the flow of data of the DL cache data.

[Fig. 6] An illustration of an example of the flow of data of UL cache data.

[Fig. 7] An explanatory diagram for explaining the architecture of the bearer.

[Fig. 8] An explanatory diagram for explaining an architecture of an EPS bearer.

FIG. 9 is an explanatory diagram for explaining a UL ID and a DL ID set in a bearer.

[Fig. 10] A program diagram of an example of a flow for establishing a program required for a preset bearer.

[Fig. 11] A program diagram of an example of a flow of a program required to establish a dedicated bearer.

[Fig. 12] A program diagram of an example of a flow of an authentication program executed in an LTE network.

[Fig. 13] An explanatory diagram for explaining an example of the use of a key used for actual communication.

[Fig. 14] A system diagram of a key.

Fig. 15 is a block diagram showing an example of a configuration of a terminal device according to an embodiment of the present disclosure.

Fig. 16 is a block diagram showing an example of the configuration of an MEC server according to an embodiment of the present disclosure.

Fig. 17 is a block diagram showing an example of the configuration of an EPC functional entity according to an embodiment of the present disclosure.

Fig. 18 is an explanatory diagram for explaining the technical features described in the first embodiment.

Fig. 19 is an explanatory diagram for explaining the technical features described in the second embodiment.

Fig. 20 is an explanatory diagram for explaining the technical features described in the third embodiment.

Fig. 21 is an explanatory diagram for explaining the technical features described in the same embodiment.

Fig. 22 is an explanatory diagram for explaining the technical features described in the fourth embodiment.

Fig. 23 is an explanatory diagram for explaining the technical features described in the same embodiment.

Fig. 24 is an explanatory diagram for explaining the technical features of the embodiment.

Fig. 25 is an explanatory diagram for explaining the technical features described in the same embodiment.

Fig. 26 is an explanatory diagram for explaining the technical features described in the same embodiment.

Fig. 27 is an explanatory diagram for explaining the technical features of the embodiment.

Fig. 28 is an explanatory diagram for explaining the technical features of the embodiment.

Fig. 29 is an explanatory diagram for explaining the technical features described in the same embodiment.

Fig. 30 is an explanatory diagram for explaining the technical features described in the same embodiment.

Fig. 31 is an explanatory diagram for explaining the technical features described in the same embodiment.

Fig. 32 is a block diagram showing an example of a schematic configuration of a server.

Fig. 33 is a block diagram showing an example of a schematic configuration of a smartphone.

Fig. 34 is a block diagram showing an example of a schematic configuration of a driving navigation device.

Hereinafter, a preferred embodiment of the present disclosure will be described in detail with reference to the accompanying drawings. In the present specification and the drawings, constituent elements that have substantially the same functional configuration are denoted by the same reference numerals, and overlapping description will be omitted.

Further, in the present specification and the drawings, elements having substantially the same functional configuration are sometimes distinguished by attaching different English letters to the same symbol. For example, a plurality of elements having substantially the same function can be distinguished as needed by the base stations 100A, 100B, and 100C. However, it is not necessary to distinguish each of the plural elements having substantially the same function, and only the same symbol is indicated. For example, if there is no particular need to distinguish the base stations 100A, 100B, and 100C, it is simply referred to as the base station 100.

In addition, the explanation is performed in the following order.

1. Introduction

1.1. The schematic structure of the system

1.2.MEC

1.3. Bearer

1.4. Security

2. Configuration example of each device

2.1. Composition of terminal devices

2.2. Configuration example of MEC server

2.3. Example of the composition of the EPC functional entity

3. First embodiment

3.1. Technical issues

3.2. Technical characteristics

4. Second embodiment

4.1. Technical issues

4.2. Technical characteristics

5. Third embodiment

5.1. Technical issues

5.2. Technical characteristics

6. Fourth Embodiment

6.1. Technical issues

6.2. Configuration example of OTT server

6.3. Technical characteristics

7. Application examples

8. Summary

<<1. Introduction>>

<1.1. Schematic configuration of the system>

First, a schematic configuration of a system 1 according to an embodiment of the present disclosure will be described with reference to Fig. 1 . Fig. 1 is an explanatory diagram showing an example of a schematic configuration of a system 1 according to an embodiment of the present disclosure. Referring to Figure 1, system 1 contains There are: a wireless communication device 100, a terminal device 200, and an MEC server 300.

(1) Wireless communication device 100

The wireless communication device 100 is a device that provides wireless communication services to its devices. For example, the wireless communication device 100A is a base station of a cellular system (or a mobile communication system). The base station 100A performs wireless communication with a device (for example, the terminal device 200A) located inside the cellular network 10A of the base station 100A. For example, the base station 100A transmits a downlink signal to the terminal device 200A, and receives the uplink signal from the terminal device 200A.

Here, the base station 100 is also referred to as an eNodeB (or eNB). The eNodeB here may be an eNodeB defined in LTE or LTE-A, and may also mean a general communication machine.

The base station 100A is logically connected to other base stations by, for example, an X2 interface, and can receive and receive control information. Further, the base station 100A is logically connected to the core network 40 by, for example, the S1 interface, and can perform reception and reception of control information and the like. In addition, communication between these devices can be physically relayed by a variety of devices.

Here, the wireless communication device 100A shown in FIG. 1 is a macro honeycomb network base station, and the cellular network 10A is a macro honeycomb network. On the other hand, the wireless communication devices 100B and 100C are master devices that use the small honeycomb networks 10B and 10C, respectively. As an example, the main device 100B is Fixed small honeycomb network base station. A small cellular network base station 100B establishes a wireless backhaul link between the macro cellular base station 100A and an access link between one or more terminal devices (for example, the terminal device 200B) in the small cellular network 10B. . The master device 100C is a dynamic AP (access point). The dynamic AP100C is a mobile device that dynamically uses the small honeycomb network 10C. The dynamic AP100C establishes a wireless backhaul link between the macrocell and the macrocell base station 100A, and establishes an access link with more than one terminal device (for example, the terminal device 200C) in the small cellular network 10C. The dynamic AP100C may be, for example, a terminal device equipped with hardware or software that can operate as a base station or a wireless access point. In this case, the small cellular network 10C is a locally formed localized network (Virtual cell).

The cellular network 10 is used, for example, according to any wireless communication method such as LTE, LTE-A (LTE-Advanced), GSM (registered trademark), UMTS, W-CDMA, CDMA200, WiMAX, WiMAX2, or IEEE802.16. can.

In addition, the small honeycomb network may include: various types of honeycomb networks (eg, a femto honeycomb network, a nano honeycomb network, a pico honeycomb) that are overlapped or non-overlapping with the macro honeycomb network and smaller than the macro honeycomb network. The concept of the network and micro-cellular network, etc.). In one example, a small hive network is used by a dedicated base station. In another example, the small honeycomb network is used as a terminal for the main device to become a small honeycomb network base station and temporarily operate. The so-called relay node is also one of the forms that can be regarded as a small honeycomb network base station. Function as a mother station of a relay node The line communication device is also referred to as a supplier base station. The provider base station may also mean a DeNB (Donor eNodeB) in LTE, and may also mean a parent station of a relay node.

(2) Terminal device 200

The terminal device 200 can communicate in a cellular network system (or a mobile communication system). The terminal device 200 performs wireless communication with a wireless communication device (for example, the base station 100A, the main device 100B or 100C) of the cellular network system. For example, the terminal device 200A receives the downlink signal from the base station 100A and transmits the uplink signal to the base station 100A.

Here, the terminal device 200 is also referred to as a user. The user, the user, may also be referred to as a UE (User Equipment). Moreover, the wireless communication device 100C is also referred to as UE-Relay. The UE here may be a UE defined in LTE or LTE-A, and the UE-Relay may also be a Prose UE to Network Relay as discussed in 3GPP, and may also mean a general communication machine.

(3) Application Server 60

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

(4) MEC server 300

The MEC server 300 is a device that provides a service (for example, content, etc.) to a user. The MEC server 300 can be provided in the wireless communication device 100. In this case, the wireless communication device 100 provides the service provided by the MEC server 300 to the user via the wireless communication path. The MEC server 300 may be implemented in a manner of a logical functional entity, or may be integrally formed with the wireless communication device 100 or the like as shown in FIG. Of course, the MEC server 300, as a physical entity, can also be formed as an independent device. The application that operates on the MEC server 300 is also referred to as an MEC application.

For example, the base station 100A supplies the service provided by the MEC server 300A to the terminal device 200A connected to the macro hive network 10. Further, the base station 100A supplies the service provided by the MEC server 300A to the terminal device 200B connected to the small honeycomb network 10B through the host device 100B.

Further, the master device 100B supplies the service provided by the MEC server 300B to the terminal device 200B connected to the small cellular network 10B. Similarly, the main device 100C supplies the service provided by the MEC server 300C to the terminal device 200C connected to the small cellular network 10C.

(5) Supplement

Although the schematic configuration of the system 1 has been described above, the present technology is not limited to the example shown in FIG. 1. For example, as the configuration of the system 1, a configuration including no main device, an SCE (Small Cell Enhancement), a HetNet (Heterogeneous Network), an MTC (Machine Type Communication) network, or the like may be used.

<1.2.MEC>

Next, the MEC will be described with reference to Figs. 2 to 6 .

(1) Network composition

2 is a diagram showing an example of a configuration of an LTE network in which no MEC is introduced. As shown in FIG. 2, the RAN (Radio Access Network) includes a UE and an eNodeB. The UE and the eNodeB are connected by the Uu interface, and the eNodeBs are connected to each other by the X2 interface. Further, EPC (Evolved Packet Core) includes MME (Mobility Management Entity), HSS (Home Subscriber Server), S-GW (Serving Gateway), and P-GW (PDN Gateway). The MME and the HSS are connected by the S6a interface, and the MME and the S-GW are connected by the S11 interface, and the S-GW and the P-GW are connected by the S5 interface. The eNodeB and the MME are connected by the S1-MME interface, and the eNodeB and the S-GW are connected by the S1-U interface, and the P-GW and the PDN are connected by the SGi interface.

PDN contains, for example: original server, and cache servo Device. The original server remembers the original application to be provided to the UE. The cache server stores, for example, an application or cached data. The UE can reduce the processing load on the original server and the communication load caused by the access to the original server by not accessing the cache server to the original server. However, the cache server is configured on the outside of the RAN and EPC (ie, PDN), so the communication delay between the UE and the cache server (that is, the delay in response to the request from the UE) will still be It is a problem.

The UE's request includes, for example, a static request to download the content memorized in the Http server, and a dynamic request for operation of a specific application or the like. Either way, the faster the cached data and applications are configured in the entity close to the UE, the faster the response to the request, which is an indisputable fact. Here, in general, the response speed is not so much dependent on the distance between entities, but rather on the number of entities that depend on it. This is because the processing delay in the input unit, the processing unit, and the output unit in each of the entities that pass through is accumulated as the number of entities increases. In addition, the content means any form of data such as an application, an image (moving image or still image), sound, or text.

In order to solve such a problem, I came up with the MEC. In the MEC, an application server for providing content to the UE or obtaining content from the UE is provided inside the EPS (Evolved Packet System). In addition, the so-called EPS is a network including EPC and eUTRAN (ie, eNodeB). Application servers that are located inside the EPS are sometimes referred to as edge servers or MEC servers. In addition, the application server It contains the concept of a cache server.

3 and 4 are diagrams showing an example of a configuration of an LTE network into which an MEC has been introduced. In Figure 3, the MEC server that caches the content is placed on the eNodeB. According to this configuration, compared with the example shown in FIG. 2, since the number of entities existing between the UE and the MEC server is reduced, the UE can quickly acquire the content. In FIG. 4, the MEC server that memorizes the content is provided in the eNodeB and the S-GW. For example, the UE acquires content from the MEC server configured in the eNodeB, and at the same time, if the cache data requested by the MEC server configured in the eNodeB does not exist, the UE is configured from the S-GW. The MEC server gets the content. In any case, since the access to the original server can be avoided, the UE can quickly acquire the content.

(2) entities

The entities appearing in Figures 2 to 4 are explained below. S-GW is an entity that becomes the anchor point for taking over. The P-GW is a connection point between the mobile network and the outside (ie, PDN), assigns an IP address to the UE, and provides an IP address to be accessed to the outside of the mobile network. The P-GW also performs filtering of data sent from the outside. HSS is a database of memory subscriber information. The MME processes various control signals and accesses the HSS to perform authentication such as authentication and authorization for each UE.

The EPC network is separated into a control plane and a user plane. S-GW and P-GW are mainly related to the user plane, MME And the HSS system is mainly related to the control plane.

Here, the S-GW is an anchor point for taking over even in the configuration before the introduction of the MEC, and therefore has a function of storing user data. On the other hand, the eNodeB does not have the function of storing user data in the configuration before the MEC is introduced, and only the function of packet retransmission corresponding to the packet loss occurring on the Uu interface does not have a memory content. In addition, the X2 interface is used for the reception of data and the coordinated control of interference when it is taken over.

(3) The application in the MEC server

In the cache, there are streaming caches that are cached at the IP level, and content caches that are cached at the application level. The MEC server is designed to be supported by any type of cache. Since content caching is currently mainly used, the MEC server is supposed to support content caching in particular.

Here, in the MEC server, it is important that the application is enabled and becomes operational. This is because, first, the cache data is recognized by the HTTP header, so that the application that can handle HTTP in the MEC server is in an operable state, which is preferable. Second, in the case where the MEC server provides a specific application, it is preferable that the application is configured and enabled to become operational.

There are different types of applications that support MEC. The cache application for caching data is even if it is served by MEC. When the server is enabled and becomes actionable, the UE will go to the original server to obtain the data if the data of the object has not been cached. Therefore, in the cache application, it is ideal to get good data beforehand.

(4) Information on the cached object

The data to be cached in the MEC server 300 is data transmitted to the UE in the DL (Downlink) direction (hereinafter also referred to as DL data stream), and from the UE in the UL (Uplink) direction. The data to be uploaded (hereinafter also referred to as UL data stream), these two types.

As a use case for the DL data stream to be cached, for example, when the UE accesses the web application and obtains some http data, when the same data is cached in the MEC server, the A case of cached data.

An example of a use case in which a UL data stream is cached is described below.

The first use case is a case in which information such as photographs generated by the UE itself is uploaded. In detail, the UE uploads the photos generated by itself, and the MEC server caches the photos. The MEC server then forwards the cached photo to the server that stores the photo on the PDN, for example, at a timing that has a margin of transmission capacity within the core network. By shifting the transfer timing, the communication load on the core network is alleviated. Moreover, the MEC server can also transfer the cached photos to other UEs, for example. The sharing of the UL data stream with other UEs is, for example, a photo taken by the viewer in the stadium, at the stadium. It is useful in such cases where the audience share each other.

The second use case is a case in which the UE uploads the acquired data. For example, the UE uploads data obtained by D2D (Device to Device) communication or Wi-Fi (registered trademark), and the MEC server caches the data. As a specific example of the use case, for example, a store broadcasts information of a product by D2D communication or Wi-Fi, and the UE acquires the information and uploads it to the MEC server. In this case, other UEs in the area of the store (for example, within the range of the cellular network of the eNodeB in which the MEC server is installed) can obtain information on the products that have been cached.

The third use case is a case in which data received from different eNodeBs is uploaded. For example, the UE uploads the data received from the eNodeB connected before the handover to the MEC server set in the eNodeB connected to the UE.

The fourth use case is a case in which the MTC terminal uploads the data. As such a data, for example, the turnover data of the vending machine and the usage information of the gas detected by the gas meter can be considered. There are a large number of MTC terminals. If the MTC terminal uploads data to the server on the PDN, there will be congestion on the core network side. On the other hand, these materials are not required to be immediacy, so for example, even if they are delivered after 1 hour, it is fast enough. That is, the related application of the data from the MTC terminal can be said to be resistant to delay. Therefore, the MEC server can also cache the data uploaded from the MTC terminal first, for example, the transmission capacity in the core network is sufficient. At the timing, the cached data is forwarded to the server on the PDN. In particular, the transmission capacity of the core network is not so much the capacity of the user data, but rather the capacity of the control signal, which is more problematic. This is because, in order to establish a meeting, it is necessary to go back and forth with multiple orders. If a large number of MTC terminals upload data together, the core network's command will increase excessively.

The above illustrates an example of a use case in which a UL data stream is cached. In this specification, the description is mainly directed to the cache of such UL data streams.

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

Fig. 5 is a diagram showing an example of the flow of data of the DL cache data. As shown in FIG. 5, the MEC server caches the data uploaded by the UE and sends the cached data to the UE (typically, a UE different from the uploaded UE).

Fig. 6 is a diagram showing an example of the flow of data of UL cache data. As shown in FIG. 6, the MEC server caches the data uploaded by the UE and sends the cached data to the original server on the PDN.

In addition, as the materials are different, it is expected that there will be licenses that are considered as DL cache data, and those who are not licensed. For example, a material that can be shared with other UEs is considered to be licensed as a DL cached material, and a personal data is not permitted to be considered as a DL cached material. Similarly, with different materials, It is expected that there will be those who are licensed to be regarded as UL cache information, and those who are not licensed. For example, it is expected that data that requires statistics from the MTC terminal is permitted as UL cache data, and local data such as regional restrictions are not permitted as UL cache data.

In view of these matters, in the MEC server, whether the cached data can be sent to the DL direction (that is, to the UE) and whether it can be sent to the UL direction (that is, to the PDN) is appropriately managed.

<1.3. Bearer>

Next, the bearers used in the EPS, particularly the EPS bearers, will be described with reference to FIGS. 7 to 11. The so-called bearer refers to the talks and is the so-called pipeline required for data transmission.

Figure 7 is an explanatory diagram for explaining the architecture of the bearer. As shown in FIG. 7, the peer-to-peer service provided from the original server to the UE is provided by using data transmission to the EPS bearer and the external bearer. The EPS bearer is established one corresponding to one type of QoS. When the UE wants to use two types of QoS at the same time, for example, two EPS bearers corresponding to two types of QoS are established with the P-GW.

The EPS bearer is a Virtual Connection, which is actually composed of a radio bearer, an S1 bearer, and an S5 bearer. The radio bearer is the bearer established on the LTE-Uu interface between the UE and the eNodeB. The S1 bearer is a bearer established on the S1 interface between the eNodeB and the S-GW. The S5 bearer is a bearer established on the S5 interface between the S-GW and the P-GW.

Fig. 8 is an explanatory diagram for explaining the architecture of the EPS bearer. As shown in FIG. 8, the EPS bearer is formed by a preset bearer and a dedicated (Dedicated) bearer, and the QoS is determined as a preset when the UE establishes a bearer between the UE and the MME. The corresponding preset bearer is initially established. Thereafter, the UE establishes the bearer corresponding to the necessary QoS as a dedicated bearer. Dedicated bearers cannot be established without a preset bearer.

Each bearer is set to identify the ID required for the bearer. This ID is used to identify the bearer used by one UE. Therefore, each bearer (for example, P-GW, S-GW, eNodeB, etc.) can identify each bearer by both the ID of the UE and the ID of the bearer. This ID is used for UL and DL.

FIG. 9 is an explanatory diagram for explaining a UL ID and a DL ID set in the bearer. As shown in FIG. 9, among the EPS bearers, the talks between the UL talks and the DL are distinguished by their respective IDs. For example, the ID set by the radio bearer includes "UL RB ID" for UL and "DL RB ID" for DL. In addition, in the S1 bearer, there is a talk that is distinguished by the TEID (Tunneling End Point ID) (a conversation that is received in the GTP Tunneling Protocol), and the ID "UL S1 TEID" for UL or the DL is used. ID "DL S1 TEID". Further, in the S5 bearer, there is a talk that is distinguished by the TEID, and the ID "UL S5 TEID" for UL or the ID "DL S5 TEID" for DL is provided.

In the table below, it is indicated which entity is each ID. Assigned. This means that the entity that has assigned the ID is responsible for establishing the appropriate meeting.

Referring to the above table, the TEID is assigned by the entity on the endpoint side. On the other hand, regarding the RB ID, both the UL and the DL are assigned by the eNodeB.

In the table below, a list of the flow of the data using the ID is shown. As shown in the table below, the UL data stream is transmitted in the session in which the UL ID is assigned, and the DL data stream is transmitted in the session in which the DL ID has been assigned. In addition, the ID of each meeting has a one-to-one mapping relationship, and one ID is mapped to one ID. That is, one ID system is not mapped to a plurality of IDs.

Referring to FIG. 10 and FIG. 11, the description is used to establish a bearer. Required procedures.

Fig. 10 is a program diagram showing an example of a flow of a program required to establish a preset bearer. In this program, UE, eNodeB, MME, S-GW, P-GW, and PCRF (Policy and Charging Rules Function) participate. As shown in FIG. 10, the establishment of the preset bearer is performed starting from the request from the UE. The request is transmitted in the order of eNodeB, MME, S-GW, and P-GW, and the reverse direction is acknowledged and returned. In addition, the PCRF is an entity that provides QoS related information.

Explain the procedure 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). Next, the MME transmits a preset 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 system interacts with the PCRF to establish an IP-CAN (IP Connectivity Access Network) talk (step S15). Next, the P-GW transmits a preset bearer generation response to the S-GW (step S16), and the S-GW transmits the message to the MME (step S17). Next, the MME transmits the attachment to the eNodeB (step S18), and the eNodeB reconfigures the RRC (Radio Resource Control) connection and transmits it to the UE (step S19). Next, the UE reconfigures the RRC connection and sends it to the eNodeB (step S20), and the eNodeB transmits the attachment to the MME (step S21). Next, 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).

Figure 11 shows the flow of the program required to establish a dedicated bearer. A program diagram of one example. In this procedure, UE, eNodeB, MME, S-GW, P-GW, and PCRF participate. As shown in FIG. 11, the establishment of the dedicated bearer is the reverse of the preset bearer, starting from the request from the PCRF. In addition, when the UE wants to establish a dedicated bearer, the UE sends the message to the application layer, and the application layer transmits the necessary QoS to the PCRF, and the establishment of the dedicated bearer starting from the UE is realized.

Explain the procedure in detail. First, the PCRF starts the IP-CAN talk change and transmits it to the P-GW (step S31). Next, 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). Next, the MME transmits a dedicated bearer setup request to the eNodeB (step S34), and the eNodeB reconfigures the RRC connection and transmits it to the UE (step S35). Next, the UE reconfigures the RRC connection and sends it to the eNodeB (step S36), and the eNodeB sends a dedicated bearer setup response to the MME (step S37). Next, the MME transmits a response to the dedicated bearer and transmits it to the S-GW (step S38), and the S-GW transmits the message to the P-GW (step S39). Next, the P-GW ends the IP-CAN talk change and transmits it to the PCRF (step S40).

<1.4. Security>

As an example of the security technology in LTE, Authentication and Authorization can be cited. The so-called authentication is to determine whether the communication object is an appropriate object. Here, the term "appropriate object" means, for example, that the access to the LTE network of the carrier is appropriate. Elephant. The so-called authorization is to determine whether the communication object has the right to use the service. Here, the term "right" refers to, for example, the right to access the LTE network of the operator. Hereinafter, an authentication procedure will be described with reference to FIG. In addition, the certification process is part of the attachment process.

Fig. 12 is a flowchart showing an example of a flow of an authentication program executed in an LTE network. As shown in FIG. 12, the UE stores the IMSI (International Mobile Subscriber Identity) and the key K. Further, the HSS stores the IMSI of each UE and the key K corresponding to the IMSI. In addition, the UE communicates with the MME via the eNodeB. The UE and the HSS perform mutual authentication using the same IMSI and key K that are stored in each other as explained below.

First, the UE transmits the IMSI together with the attach request to the MME (step S51). Next, the MME transmits the received IMSI together with the authentication request to the HSS (step S52). Next, the HSS generates a random number RAND, and inputs the random number RAND, the received IMSI, and the key K memorized in association with the IMSI, into the authentication function, and obtains the expected response RES _EXPECTED and gold. Key K _ASME (step S53). Next, the HSS, as an authentication response, transmits the key K _ASME , the expected response RES _EXPECTED, and the random number RAND to the MME (step S54). Next, the MME transmits the random number RAND to the UE (step S55). Next, the UE inputs the received random number RAND, the memorized IMSI, and the key K to the authentication function, and obtains the response RES and the key K _ASME (step S56). Next, the UE will respond to the RES and send it to the MME (step S57). Then, the MME compares the expected response RES _EXPECTED with the actual response RES to authenticate the UE (step S58). In detail, the MME determines that the UE has reliability (that is, the authentication succeeds) in the case where the _expected response RES _EXPECTED is consistent with the actual response RES. On the other hand, in the case where the _expected response RES _EXPECTED is inconsistent with the actual response RES, the MME determines that the UE has no reliability (that is, the authentication fails).

After the authentication procedure is written, the key used for actual communication is generated based on K _ASME . The generated key is of two types: CK (Cipher Key) and IK (Integrity Key). CK, the key used to encrypt communications, is used to prevent others from knowing the content of the communication. IK, the key required to confirm the integrity of the data, is used to confirm whether the data has been changed in the communication path. In the EPS, security is ensured by an AA (Authentication/Authorization) program, encryption using CK, and confirmation using INT integrity (Integrity). Further, these respective processes are performed separately for each UE.

As described above with reference to Fig. 12, the common key K _ASME is generated on both the UE side and the network side by the authentication procedure. The UE side and the network side (HSS, MME, or eNodeB) generate a key used for actual communication based on the common key K _{ASME for} each use. Hereinafter, an example of the use of the key used in actual communication will be described with reference to FIG.

Fig. 13 is an explanatory diagram for explaining an example of the use of the key used in actual communication. As shown in Figure 13, between the UE and the eNodeB, the CK required by the user plane will be used. In addition, between the UE and the eNodeB, the IK and CK required for the RRC (Radio Resource Control) command are used. In addition, between the UE and the MME, the IK and CK required for the NAS (Non-access stratum) command are used. As such, different keys are used for each use. These keys are then generated based on the K _ASME generated in the AA program. Hereinafter, the relationship between the keys generated in accordance with these uses will be described with reference to FIG. 14.

Figure 14 is a system diagram of the key. In the figure, enc means encryption, int means integrity, RRC means RRC, NAS means NAS, and UP means user plane. The system diagram of the key shown in FIG. 14 is common to the UE side and the network side. Regarding the key on the network side, the key used by the NAS is generated by the MME. The key used by the NAS, the RRC command and the user plane, is generated by the eNodeB. The keys on the UE side are all generated by the UE.

The generation of the key shown in Fig. 14 is explained along the time series. First, the HSS and the UE generate K _ASME by Mutual authentication. Next, the MME and the UE generate a NAS command key (ie, K _NASenc and K _NASint ) and a base key for the _eNodeB (ie, K _eNodeB ) based on K _ASME . Then, the eNodeB and the UE generate a key for the RRC command (ie, K _RRCenc and K _RRCint ) and a key for the user plane (ie, K _UPenc ) based on the base key for the eNodeB.

<<2. Configuration example of each device>>

<2.1. Composition of terminal device>

Next, an example of the configuration of the terminal device 200 according to the embodiment of the present disclosure will be described with reference to FIG. 15. Fig. 15 is a block diagram showing an example of the configuration of the terminal device 200 according to the embodiment of the present disclosure. Referring to Fig. 15, terminal device 200 includes antenna unit 210, wireless communication unit 220, memory unit 230, and processing unit 240.

(1) Antenna portion 210

The antenna unit 210 radiates the signal output from the wireless communication unit 220 in a space by radio waves. Further, the antenna unit 210 converts the radio wave of the space into a signal, and outputs the signal to the wireless communication unit 220.

(2) Wireless communication unit 220

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

(3) Memory unit 230

The memory unit 230 temporarily or permanently memorizes programs and various materials required for the operation of the terminal device 200.

(4) Processing unit 240

The processing unit 240 provides various functions of the terminal device 200. The processing unit 240 includes an authentication processing unit 241 and a communication processing unit 243. Further, the processing unit 240 may further include other components than these components. In other words, the processing unit 240 can perform operations other than the operations of these components.

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

<2.2. Configuration example of MEC server>

Next, an example of the configuration of the MEC server 300 according to an embodiment of the present disclosure will be described with reference to FIG. Fig. 16 is a block diagram showing an example of the configuration of the MEC server 300 according to the embodiment of the present disclosure. Referring to Fig. 16, MEC server 300 includes a communication unit 310, a storage unit 320, and a processing unit 330.

(1) Communication unit 310

The communication unit 310 is an interface required for communication with other devices. For example, the communication unit 310 communicates with the device that has been established. For example, if the MEC server 300 is formed as a logical entity and is included in the base station 100, the communication unit 310 communicates with, for example, the control unit of the base station 100. The MEC server 300 may have an interface required for direct communication with devices other than the integrally formed device.

(2) Memory unit 320

The memory unit 320 temporarily or permanently memorizes the programs and various materials required for the operation of the MEC server 300. For example, the storage unit 320 can memorize various contents and applications provided to the user.

(3) Processing unit 330

The processing unit 330 provides various functions of the MEC server 300. The processing unit 330 includes an authentication processing unit 331 and a communication processing unit 333. Further, the processing unit 330 may further include other components other than these components. In other words, the processing unit 330 can perform operations other than the operations of these components.

The operations of the authentication processing unit 331 and the communication processing unit 333 will be described in detail later. Although not shown in FIG. 16, the processing unit 330 may include a content processing unit that provides content to the UE 200 or acquires content from the UE 200.

<2.3. Configuration example of EPC functional entity>

Next, an example of the configuration of an EPC functional entity according to an embodiment of the present disclosure will be described with reference to FIG. The EPC functional entities described herein are, for example, MME 41 or HSS 42, assuming that these systems take the same configuration. Of course, the operation of each component is different between the MME 41 and the HSS 42. 17 is an EPC function according to an embodiment of the present disclosure. A block diagram of an example of the composition of the entities 41, 42. Referring to Fig. 16, EPC functional entities 41 and 42 include communication unit 410, storage unit 420, and processing unit 430.

(1) Communication unit 410

The communication unit 410 is an interface required for communication with other devices. For example, the communication unit 410 communicates with other EPC functional entities.

(2) Memory unit 420

The memory unit 420 temporarily or permanently memorizes the programs and various materials required for the operation of the MME 41 or the HSS 42.

(3) Processing unit 430

The processing unit 430 provides various functions of the MME 41 or the HSS 42. The operation of the processing unit 430 will be described in detail later.

The configuration example of each device has been described above. Hereinafter, for convenience of explanation, the base station 100 is also referred to as an eNodeB 100, and the terminal device 200 is also referred to as a UE 200.

<<3. First embodiment>>

In the present embodiment, the authentication using the authentication information stored in the MEC server 300 is performed.

<3.1. Technical issues>

Each entity of the EPS (P-GW, S-GW, PCRF, HSS, eNodeB, etc.) is regarded as a trusted entity, and the mutual authentication between these entities is not standardized. On the other hand, since the UE is a device held by a user who does not have a large number of users, the procedure for mutual authentication with the MME is standardized.

However, regarding the MEC server, the mutual authentication program is not standardized. The MEC server is intended to be configured close to the eNodeB, but should not be considered as a trusted entity. This is because the MEC server is likely to be provided by a wide variety of service providers. Therefore, it is preferable to confirm the reliability of the MEC server one by one.

Thus, in the present embodiment, the program required to authenticate the MEC server is provided.

<3.2. Technical Features>

(1) Certification procedure

The MEC server 300 communicates with a network that has been authenticated using the authentication information corresponding to the MEC server 300 registered in the HSS 42.

The HSS 42 (for example, the storage unit 420) memorizes the authentication information corresponding to the MEC server 300. In the present embodiment, the authentication information corresponding to the MEC server 300 is the authentication information of the MEC server 300. Specifically, the authentication information of the MEC server 300 includes: a number (ie, IMSI) for specifying the MEC server 300 and The key information inherent to the MEC server 300 (ie, the key K). The HSS 42 memorizes the IMSI for each MEC server 300 and also memorizes the key K corresponding to the IMSI of the MEC server 300. In addition, an IMSI is registered for one MEC server 300. However, a plurality of MEC servers 300 can also be assigned a common IMSI. Then, the MME 41 (for example, the processing unit 430) and the HSS 42 (for example, the processing unit 430) perform various processes required for the authentication of the MEC server 300.

The MEC server 300 (for example, the storage unit 320) memorizes the authentication information of the MEC server 300. Then, the MEC server 300 (for example, the authentication processing unit 331) performs authentication of the network using the authentication information of the MEC server 300. That is, the MEC server 300 according to the present embodiment is described with reference to FIG. 12, and the mechanism for authenticating the UE using the same authentication information stored by the UE and the HSS system is used, and the same mechanism is used. Certify. Then, the MEC server 300 (for example, the communication processing unit 333) communicates with the authenticated network. Specifically, the MEC server 300 provides content to the UE 200 via the authenticated network (eg, the eNodeB 100 within the network) or retrieves content from the UE 200. In this way, the MEC server 300 is authenticated as a trusted entity and can be connected to the network.

The MEC server 300 may store authentication information in a hardware such as a USIM (Universal Subscriber Identification Module). In this case, the memory unit 320 is realized by a hardware such as USIM. In addition, the certification information can also be It is implemented with software equivalent to USIM. In this case, the memory unit 320 memorizes the software. The authentication information is registered by a business person such as an MEC application.

Here, the MEC server 300 can be used while switching the network of the MNO (Mobile Network Operator). In this case, the authentication information can be stored in the MEC server 300, for example, in an eSIM (Embedded Subscriber Identity Module). In this way, the authentication information can be rewritten at the remote end, and the MEC server 300 can operate while switching the network of the plurality of operators. In this case, the entity that can rewrite the authentication information establishes a communication path that is concealed by the encryption process with the MEC server 300, and then changes the authentication information.

The authentication procedure of the MEC server 300 is the same as that described above with reference to FIG. 12, except that the main body of the authentication is changed from the UE to the MEC server 300. Hereinafter, the authentication procedure described in the embodiment will be described with reference to Fig. 18 .

Fig. 18 is a flowchart showing an example of a flow of an authentication program executed in the system 1 according to the embodiment. As shown in FIG. 18, the MEC server 300 memorizes the IMSI and the key K. Further, the HSS 42 stores the IM of the respective MEC server 300 and the key K corresponding to the IMSI. Further, the MEC server 300 communicates with the MME 41 via the eNodeB 100.

First, the MEC server 300 transmits the IMSI together with the attach request to the MME 41 (step S102). Next, the MME 41 transmits the received IMSI together with the authentication request to the HSS 42 (step S104). Next, the HSS 42 generates a random number RAND, and inputs the random number RAND, the received IMSI, and the key K memorized in association with the IMSI to the authentication function, and obtains the expected response RES _EXPECTED and the key K _ASME ( Step S106). Next, the HSS 42 transmits 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 41 transmits the random number RAND to the MEC server 300 (step S110). Next, the MEC server 300 inputs the received random number RAND, the memorized IMSI, and the key K to the authentication function, and obtains the response RES and the key K _ASME (step S112). Next, the MEC server 300 transmits a response RES to the MME 41 (step S114). Then, the MME 41 compares the expected response RES _EXPECTED with the actual response RES to authenticate the MEC server 300 (step S116). In detail, the MME 41 determines that the MEC server 300 has reliability (that is, the authentication is successful) in the case where the _expected response RES _EXPECTED coincides with the actual response RES. On the other hand, in the case where the expected response RES _EXPECTED does not coincide with the actual response RES, the MME 41 determines that the MEC server 300 has no reliability (that is, authentication failure).

(2) Network variation

As described above, the MEC server 300 may be an application server that is provided inside the EPS.

In addition, the MEC server 300 can also be set. An application server in a LAN (Local Area Network) network. In this case, the MEC server 300 is provided, for example, at an access point of the wireless LAN. Then, the MEC server 300 performs the AA program via the ePDG (enhanced Packet Data Gateway) using its own authentication information. In addition, ePDG, which is one of the entities of the EPC, is connected to the P-GW. Typically, ePDG is certified for wireless LAN terminals.

<<4. Second embodiment>>

In the present embodiment, the authentication of the MEC server 300 is performed by the UE 200.

<4.1. Technical issues>

In the first embodiment described above, the MEC server 300 memorizes the authentication information of itself. Typically, a business operator of the MEC application sets the authentication information to the MEC server 300. However, it is not easy to change the authentication information stored in the MEC server 300, and it is difficult to immediately set the authentication information to the newly added MEC server 300. This is because setting the authentication information through communication is not ideal from the point of view of the cryptographic information of the authentication information (especially the key K). When the MEC server 300 is enabled (for example, activated) from the remote end through communication, it is preferable to securely allow the MEC server 300 to be authenticated.

Thus, in the present embodiment, a technique for performing authentication of the MEC server 300 more securely is provided.

<4.2. Technical Features>

In the present embodiment, the UE 200 (for example, the authentication processing unit 241) performs authentication as a proxy of the MEC server 300.

The HSS 42 (for example, the storage unit 420) memorizes the authentication information corresponding to the MEC server 300. In the present embodiment, the authentication information corresponding to the MEC server 300 is the authentication information of the UE 200 to which the MEC server 300 is associated. Specifically, the authentication information of the UE 200 includes: a number (ie, IMSI) for specifying the UE 200 and key information (ie, the key K) inherent to the UE 200. The HSS 42 associates with the UE 200 and memorizes the identification information of the MEC server 300. This identification information, hereinafter also referred to as the MEC server ID. For example, the HSS 42, as the subscriber information of the UE 200, memorizes the MEC server ID of the MEC server 300 associated with the UE 200. Further, the MEC server ID is not a temporary ID but identification information unique to the MEC server 300.

The UE 200 (for example, the authentication processing unit 241) performs the authentication procedure of the MEC server 300 associated with itself after the completion of the authentication procedure itself, instead of the MEC server 300. In detail, first, the UE 200 uses its own IMSI and key K to perform its own authentication procedure. Next, the UE 200 transmits an attach request of the MEC server 300 to the MME 41 or the eNodeB 100. When sending to the MME 41, the NAS command is used. When sending to eNodeB100, it uses RRC command. The attachment request of the MEC server 300 is included MEC server ID. The attachment request of the MEC server 300 can also be regarded as a message for activation of the MEC server 300 to be requested.

The HSS 42 (for example, the processing unit 430), when receiving the attachment request including the MEC server ID, confirms whether or not the subscriber information corresponding to the UE 200 of the transmission source of the attachment request is registered in the MEC server ID. . Then, the HSS 42 returns the attachment response containing the confirmation result. In the case where there is a registration, the HSS 42 returns the attachment response containing the temporary ID. The temporary ID is an ID given to the MEC server 300 that has been successfully authenticated. The temporary ID is also referred to as an MEC server temporary ID. On the other hand, if it is not registered, the HSS 42 returns the attachment response without the temporary ID of the MEC server. In this case, the MEC server 300 cannot be connected to the network.

The MEC server 300 (for example, the communication processing unit 333) is issued based on a request (i.e., an attach request) made by the UE 200 to which the MEC server 300 is associated, based on the authentication of the network. Information (also known as the MEC server temporary ID) to communicate with the network. The system 1 identifies whether the MEC server 300 has been authenticated based on the information that has been issued, thereby ensuring security. Further, in the present embodiment, authentication can be performed without setting authentication information in the MEC server 300, and high security can be ensured.

The eNodeB 100 and the MME 41 acquire the MEC server temporary ID and memorize it during the process of forwarding the attach response to the UE 200, permitting the MEC server 300 having the MEC server temporary ID to do so. access. Thereby, the MEC server 300 can be connected to the network while the MEC server temporary ID is valid.

Further, although the above description has been made with an attachment request of 300 units of the MEC server, the same authentication procedure can be performed by the MEC application unit operating on the MEC server 300. For example, the attach procedure of the MEC application may be performed each time a new MEC application is launched. In this case, the attachment response containing the temporary ID of the MEC server can also be considered as the activation permission of the MEC application. The attach request containing the MEC server ID can also be considered as the startup request of the MEC application. Further, the MEC server ID and the MEC server temporary ID can also be set in the MEC application unit.

Hereinafter, an example of the flow of the authentication procedure when the UE 200 is used to proxy the MEC server 300 and perform authentication will be described with reference to FIG.

Fig. 19 is a flowchart showing an example of a flow of an authentication program executed in the system 1 according to the embodiment. Further, the UE 200 communicates with the MME 41 via the eNodeB 100.

As shown in FIG. 19, first, the UE 200 performs an attach procedure (step S202). In the attachment procedure, the authentication procedure described above with reference to FIG. 12 is performed, and the UE 200 is authenticated. Next, the UE 200 transmits an attach request of the MEC server 300 to the MME 41 (step S204). This attachment request is the MEC server ID of the MEC server 300 including the authentication target. Next, the MME 41 transfers the attached request of the received MEC server 300 to the HSS 42 (step S206). Next, the HSS 42 sends the attachment response of the MEC server 300 back to MME 41 (step S208). At this time, the HSS 42 confirms whether or not the MEC server ID of the MEC server 300 is registered in the subscriber information of the UE 200 to which the requesting communication source is attached. Hereinafter, the case where there is a registration will be described. That is, the attachment response contains the temporary ID of the MEC server. Next, the MME 41 transfers the attached response of the received MEC server 300 to the eNodeB 100 (step S210), and the eNodeB 100 transfers the attached response of the received MEC server 300 to the MEC server 300 (step S212). Then, the MEC server 300 attaches to the network using the MEC server temporary ID included in the attach response (step S214).

<<5. Third embodiment>>

In the present embodiment, the form of the key used in the communication by the MEC server 300 is provided.

<5.1. Technical issues>

The MEC server 300 can be connected to the network for communication if the authentication procedure described in the first embodiment or the second embodiment is successful. Therefore, as in the case of the UE, after the authentication procedure, the keys (such as CK and IK) used at the time of actual communication are generated, which is preferable. For example, it is preferable that the MEC application communicates with the MME 41 and the IK and CK are used in the communication between the MEC application and the UE 200.

However, the communication caused by the MEC server 300 is The technology used to generate and publish the key is not provided.

<5.2. Technical Features>

(1) The key required for communication between the MEC application and the MME 41

The keys (ie, CK and IK) required for communication between the MEC application and the MME 41 are used with different keys for each MEC application.

In the case of the first embodiment, the key required for communication between the MEC application and the MME 41 is generated based on the authentication information of the MEC server 300 (i.e., the IMSI and the key K of the MEC server 300). In detail, first, in the attaching procedure of the MEC server 300, the key K _ASME is generated using the authentication information of the MEC server 300. Then, based on the key K _ASME , a key (ie, CK and IK) required for communication between the MEC application and the MME 41 is generated. The CK and IK are also collectively referred to as the key K _{MEC Application-MME} . That is, the key K _{MEC Application-MME} includes CK and IK.

In the case of the second embodiment, the key required for communication between the MEC application and the MME 41 is based on the authentication information of the UE 200 (i.e., the IMSI and the key K of the UE 200) that the MEC server 300 is associated with. generate. In detail, first, in the attach procedure of the UE 200, the key K _ASME is generated using the authentication information of the UE 200. Then, based on the key K _ASME generated using the authentication information of the UE 200, a key K _{MEC Application-MME} required for communication between the MEC application and the MME 41 is generated. Here, the MME 41 is notified of the key K _ASME from the HSS 42 in the attach procedure of the UE 200 (step S54 shown in FIG. 12). However, since the attach procedure of the UE 200 and the attach procedure of the MEC server 300 are individual programs, in the attach procedure of the UE 200, the key K _{MEC Application-MME} is generated at the timing at which the key K _ASME is generated, which is not ideal. . Then, the MME 41 (for example, the storage unit 420) memorizes the key K _ASME beforehand. Then, the MME 41 (for example, the processing unit 430) generates the key K _{MEC Application-MME} based on the stored key K _ASME when the authentication of the MEC server 300 is successful, and generates the generated key K _{MEC Application - MME} , notified to the MEC server 300.

A system diagram for the key of the key K _{MEC Application-MME} is shown in FIG. As shown in FIG. 20, the key K _{MEC Application-MME is} generated based on the K _ASME of the UE 200 that has performed the attachment procedure of the MEC server 300.

(2) The key required for communication between the MEC application and the UE200

The keys (ie, CK and IK) required for communication between the MEC application and the UE 200 use different keys with each UE 200. For a MEC server 300, a plurality of 00s may be connected.

For example, the key required for communication between the MEC application and the UE 200 is generated based on the authentication information of the UE 200 (ie, the IMSI and the key K of the UE 200). In detail, first, in the attach procedure of the UE 200, the key K _ASME is generated using the authentication information of the UE 200. Then, a key K _eNodeB is generated based on the key K _{ASME ,} and CK and IK required for communication between the MEC application and the UE 200 are generated based on the key K _eNodeB . The CK and IK are also collectively referred to as the key K _{UE-MEC Application} . That is, the key K _{UE-MEC Application} includes CK and IK. Further, regarding the operation of the MEC application on the same server MEC 300, the system may use the same key K _{UE-MEC Application} MEC between plural applications, may use different keys K _{UE-MEC Application.}

A system diagram for the key of the key K _{UE-MEC Application} is shown in FIG. 21, based on the K _ASME key to be generated in the attach procedure UE200 key K _eNodeB generates, based on the generated key K _eNodeB key K _{UE-MEC Application.}

As described above, the key between the MEC application and the MME 41, and the key of the key between the MEC application and the MME 41 are shown in Table 3 below.

<<6. Fourth Embodiment>>

This embodiment is a form of authentication of other entities to which the MEC server 300 is associated.

<6.1. Technical issues>

I think there is a business that provides content such as animations or applications to the MEC server. Then, there is a content server that is needed to provide content to the MEC server. Such a content server, hereinafter also referred to as an OTT (Over the top) server.

An example of the arrangement of the OTT server is shown in FIGS. 22 and 23. In the example shown in FIG. 22, the OTT server 500 is configured inside the EPC. In the example shown in FIG. 23, the OTT server 500 is configured outside of the EPC. When the OTT server 500 is disposed outside the EPC, the OTT server 500 may be directly connected to the MEC server 300 or may be connected via the P-GW 44, the S-GW 43, or the like.

Regardless of the configuration example, it is preferable to confirm the reliability of the OTT server 500 in the same manner as the MEC server 300.

Thus, in the present embodiment, the program required to authenticate the OTT server 500 is provided.

<6.2. Configuration example of OTT server>

Next, an example of the configuration of the OTT server 500 according to the embodiment of the present disclosure will be described with reference to FIG. Fig. 24 is a block diagram showing an example of the configuration of the OTT server 500 according to the embodiment of the present disclosure. Referring to Fig. 24, OTT server 500 includes a communication unit 510, a storage unit 520, and a processing unit 530.

(1) Communication Department 510

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

(2) Memory unit 520

The memory unit 520 temporarily or permanently memorizes the programs and various materials required for the operation of the OTT server 500. For example, the storage unit 520 can memorize various contents and applications provided to the MEC server 300.

(3) Processing unit 530

The processing unit 530 provides various functions of the OTT server 500. The processing unit 530 includes an authentication processing unit 531 and a communication processing unit 533. Further, the processing unit 530 may further include other components other than these components. In other words, the processing unit 530 can perform operations other than the operations of these components.

The authentication processing unit 531 and the communication processing unit 533 have the same functions as the above-described authentication processing unit 331 and communication processing unit 333. Although not shown in FIG. 24, the processing unit 530 may include a content processing unit that provides content to the MEC server 300.

<6.3. Technical Features>

The following is a description of the technical features in the various cases that are contemplated.

(1) The first case

In this case, the OTT server 500 is configured inside the EPC, and the OTT server 500 is an example of an entity that is considered to have reliability. In this case, there is no need to reconfirm the authentication procedure required for the reliability of the OTT server 500. Of course, even in this case, the authentication procedure required to confirm the reliability of the OTT server 500 can be performed.

(2) Case 2

In this case, the OTT server 500 is configured outside the EPC, or the OTT server 500 is configured as an entity that is not trusted in the EPC. In this case, the OTT server 500 can also be authenticated by the same authentication procedure as the MEC server 300 in the first embodiment.

The OTT server 500 has the same technical features as the MEC server 300 described in the first embodiment. Each of the entities such as the MME 41 and the HSS 42 has the same technical features as those of the first embodiment, except that the authentication target is changed from the MEC server 300 to the OTT server 500. That is, the technical features of this case correspond to the replacement of the MEC server 300 with the OTT server 500 in the related description of the first embodiment.

For example, the HSS 42 (for example, the storage unit 420) memorizes the authentication information corresponding to the OTT server 500. In this case, the authentication information corresponding to the OTT server 500 is the authentication information of the OTT server 500. Specifically, the authentication information of the OTT server 500 It contains: the number (that is, IMSI) used to specify the OTT server 500 and the key information (ie, the key K) inherent to the OTT server 500. On the other hand, the OTT server 500 (for example, the storage unit 520) also memorizes the authentication information of the OTT server 500. Then, the OTT server 500 (for example, the authentication processing unit 531) performs authentication of the network using the authentication information of the OTT server 500. The OTT server 500 (for example, the communication processing unit 533) communicates with the authenticated network. Specifically, the OTT server 500 provides content to the MEC server 300 via an authenticated network (e.g., the eNodeB 100 within the network). In this way, the OTT server 500 is authenticated as a trusted entity and can be connected to the network.

The authentication procedure of the OTT server 500 is the same as that described above with reference to FIG. 18 except that the main body of the authentication is changed from the MEC server 300 to the OTT server 500. Hereinafter, the authentication procedure described in this case will be described with reference to FIG. 25.

Fig. 25 is a flowchart showing an example of a flow of an authentication program executed in the system 1 according to the embodiment. As shown in FIG. 25, the OTT server 500 memorizes the IMSI and the key K. Further, the HSS 42 stores the key K corresponding to the IMSI of the OTT server 500. Further, the OTT server 500 communicates with the MME 41 via the eNodeB 100.

First, the OTT server 500 transmits the IMSI together with the attach request to the MME 41 (step S302). Next, the MME 41 transmits the received IMSI together with the authentication request to the HSS 42 (step S304). Next, the HSS 42 generates a random number RAND, and inputs the random number RAND, the received IMSI, and the key K memorized in association with the IMSI to the authentication function, and obtains the expected response RES _EXPECTED and the key K _ASME ( Step S306). Next, the HSS 42 transmits 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 41 transmits the random number RAND to the OTT server 500 (step S310). Next, the OTT server 500 inputs the received random number RAND, the memorized IMSI, and the key K to the authentication function, and obtains the response RES and the key K _ASME (step S312). Next, the OTT server 500 transmits a response RES to the MME 41 (step S314). Then, the MME 41 compares the expected response RES _EXPECTED with the actual response RES to authenticate the OTT server 500 (step S316). In detail, the MME 41 determines that the OTT server 500 is reliable (that is, the authentication is successful) in the case where the _expected response RES _EXPECTED is consistent with the actual response RES. On the other hand, in the case where the expected response RES _EXPECTED is inconsistent with the actual response RES, the MME 41 determines that the OTT server 500 has no reliability (that is, authentication failure).

As a modification of this case, a case in which the OTT server 500 is directly connected to the MME 41 is considered. An example of the arrangement of the OTT server 500 in this case is shown in FIG. In the example shown in FIG. 26, the OTT server 500 is configured inside the EPC and is directly connected to the MME 41. In the authentication procedure in this case, the communication between the OTT server 500 and the MME 41 does not pass through the eNodeB 100, and the same as described above with reference to FIG. 25. Hereinafter, the present case will be described with reference to FIG. The certification procedure described in the example.

Fig. 27 is a flowchart showing an example of the flow of the authentication program executed in the system 1 according to the embodiment. As shown in FIG. 27, the OTT server 500 memorizes the IMSI and the key K. Further, the HSS 42 stores the key K corresponding to the IMSI of the OTT server 500. Further, the OTT server 500 communicates with the MME 41 without going through the eNodeB 100.

First, the OTT server 500 transmits the IMSI together with the attach request to the MME 41 (step S402). Next, the MME 41 transmits the received IMSI together with the authentication request to the HSS 42 (step S404). Next, the HSS 42 generates a random number RAND, and inputs the random number RAND, the received IMSI, and the key K memorized in association with the IMSI to the authentication function, and obtains the expected response RES _EXPECTED and the key K _ASME ( Step S406). Next, the HSS 42 transmits 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 41 transmits the random number RAND to the OTT server 500 (step S410). Next, the OTT server 500 inputs the received random number RAND, the memorized IMSI, and the key K to the authentication function, and obtains the response RES and the key K _ASME (step S412). Next, the OTT server 500 transmits a response RES to the MME 41 (step S414). Then, the MME 41 compares the expected response RES _EXPECTED with the actual response RES to authenticate the OTT server 500 (step S416). In detail, the MME 41 determines that the OTT server 500 is reliable (that is, the authentication is successful) in the case where the _expected response RES _EXPECTED is consistent with the actual response RES. On the other hand, in the case where the expected response RES _EXPECTED is inconsistent with the actual response RES, the MME 41 determines that the OTT server 500 has no reliability (that is, authentication failure).

In this case and the above variant, the key required for communication between the OTT server 500 and the MME 41, and the key required for communication between the OTT server 500 and the MEC application are based on the authentication information of the OTT server 500. Was generated. In detail, first, in the attach procedure of the OTT server 500, the key K _ASME is generated using the authentication information of the OTT server 500. Then, based on the key K _ASME , the key required for communication between the OTT server 500 and the MME 41, and the key required for communication between the OTT server 500 and the MEC application are generated. The former key is also known as the key K _{OTT Server-MME} , and the latter key is also called the key K _{OTT Server-MEC Application} . The key K _{OTT Server-MME} contains CK and IK. Similarly, the key K _{OTT Server-MEC Application} contains CK and IK. A systematic diagram of these keys is shown in Figure 28. As shown in FIG. 28, the key K _{OTT Server-MME} and the key K _{OTT Server-MEC Application} are generated based on the K _ASME generated in the attach procedure of the OTT server 500.

(3) Case 3

In the case of the second embodiment, the authentication of the OTT server 500 is performed by the UE 200.

The OTT server 500 has the same technical features as the MEC server 300 described in the second embodiment. The entities such as UE200, MME41, and HSS42 are also authenticated objects from the MEC server. 300 is changed to the OTT server 500, and has the same technical features as the second embodiment. That is, the technical features of this case correspond to the replacement of the MEC server 300 with the OTT server 500 in the related description of the second embodiment.

For example, the HSS 42 (for example, the storage unit 420) memorizes the authentication information corresponding to the OTT server 500. In this case, the authentication information corresponding to the OTT server 500 is the authentication information of the UE 200 to which the OTT server 500 is established. The UE 200 (for example, the authentication processing unit 241) performs proxy authentication by the proxy OTT server 500. Then, the OTT server 500 (for example, the communication processing unit 533) is used based on a request (i.e., an attach request) made by the UE 200 to which the OTT server 500 is associated, based on the authentication of the network. Information published to communicate with the network. Further, the identification information unique to the OTT server 500 corresponding to the MEC server ID in the second embodiment is hereinafter referred to as an OTT server ID. Further, based on the MEC server temporary ID in the second embodiment, the information to be issued for the request made by the UE 200 whose network authentication has succeeded is also referred to as an OTT server temporary ID.

Hereinafter, an example of the flow of the authentication procedure when the UE 200 is used to proxy the OTT server 500 and perform authentication will be described with reference to FIG.

Fig. 29 is a flowchart showing an example of the flow of the authentication program executed in the system 1 according to the embodiment. Further, the UE 200 communicates with the MME 41 via the eNodeB 100.

As shown in FIG. 29, first, the UE 200 performs an attach procedure. (Step S502). In this attachment procedure, the authentication procedure described above with reference to Fig. 12 is performed. Next, the UE 200 transmits an attach request of the OTT server 500 to the MME 41 (step S504). The attachment request is an identification information inherent to the OTT server 500 including the authentication target, that is, an OTT server ID. Next, the MME 41 transfers the attached request of the received OTT server 500 to the HSS 42 (step S506). Next, the HSS 42 returns the attachment response of the OTT server 500 to the MME 41 (step S508). At this time, the HSS 42 confirms whether or not the OTT server ID of the OTT server 500 is registered in the subscriber information of the UE 200 to which the requesting communication source is attached. Hereinafter, the case where there is a registration will be described. That is, the attachment response contains the OTT server temporary ID. Next, the MME 41 transfers the attached response of the received OTT server 500 to the eNodeB 100 (step S510), and the eNodeB 100 forwards the attached response of the received OTT server 500 to the OTT server 500 (step S512). Then, the OTT server 500 attaches to the network using the OTT server temporary ID included in the attach response (step S514).

In this case, the key required for communication between the OTT server 500 and the MME 41, and the key required for communication between the OTT server 500 and the MEC application are generated based on the authentication information of the UE 200. In detail, first, in the attach procedure of the UE 200, the key K _ASME is generated using the authentication information of the UE 200. Then, based on the key K _ASME , the key K _{OTT Server-MME} required for communication between the OTT server 500 and the MME 41, and the key required for communication between the OTT server 500 and the MEC application K _{OTT Server-MEC Application} , is generated. A systematic diagram of these keys is shown in Figure 30. As shown in FIG. 30, the key K _{OTT Server-MME} and the key K _{OTT Server-MEC Application} are generated based on the K _ASME of the UE 200 that has performed the attach procedure of the OTT server 500.

(4) Case 4

This case is an example in which the OTT server 500 is used to perform authentication of the MEC server 300. The OTT server 500 has the same technical features as the UE 200 described in the second embodiment. For each entity such as the MEC server 300, the MME 41, and the HSS 42, the authentication program using the authentication information of the UE 200 is changed to the authentication program using the authentication information of the OTT server 500, and the other is the second and the second. The same technical features are implemented. That is, the technical features of this case correspond to the description of the second embodiment, and the UE 200 is replaced with the OTT server 500.

For example, the HSS 42 (for example, the storage unit 420) memorizes the authentication information corresponding to the MEC server 300. In this case, the authentication information corresponding to the MEC server 300 is the authentication information of the OTT server 500 to which the MEC server 300 is established. Specifically, the HSS 42 (for example, the storage unit 420) associates with the OTT server 500 to memorize the identification information of the MEC server 300, that is, the MEC server ID. For example, the HSS 42, as the subscriber information of the OTT server 500, memorizes the MEC server ID of the MEC server 300 associated with the OTT server 500.

Then, the OTT server 500 (for example, the authentication processing unit 531) performs authentication by proxying the MEC server 300. The MEC server 300 (for example, the communication processing unit 333) uses a request (that is, an attach request) based on the OTT server 500 to which the MEC server 300 is associated, based on the authentication of the network. The published information (ie, the MEC server temporary ID) is used to communicate with the network. The system 1 identifies whether the MEC server 300 has been authenticated based on the information that has been issued, thereby ensuring security.

Further, as described with reference to FIG. 29, the OTT server 500 itself does not have authentication information, and the case where the UE 200 authenticates the authentication is also considered. In this case, the authentication information used by the MEC server 300 for authentication of the network may be the UE 200 that is associated with the MEC server 300 and authenticated by the UE 200 that authenticates the OTT server 500. News. In this case, the HSS 42 (for example, the storage unit 420), as the subscriber identification information of the UE 200, memorizes, for example, the OTT server ID and the MEC server ID.

Hereinafter, an example of the flow of the authentication procedure when the OTT server 500 is used to proxy the MEC server 300 and perform authentication will be described with reference to FIG.

Fig. 31 is a flowchart showing an example of the flow of the authentication program executed in the system 1 according to the embodiment. Further, the OTT server 500 communicates with the MME 41 via the eNodeB 100.

As shown in FIG. 31, first, the OTT server 500 performs an attach procedure (step S602). In the attaching procedure, refer to FIG. 27 or The authentication procedure described above will be performed and the OTT server 500 will be authenticated. Next, the OTT server 500 transmits an attach request of the MEC server 300 to the MME 41 (step S604). This attachment request is the MEC server ID of the MEC server 300 including the authentication target. Next, the MME 41 transfers the attached request of the received MEC server 300 to the HSS 42 (step S606). Next, the HSS 42 returns the attachment response of the MEC server 300 to the MME 41 (step S608). At this time, the HSS 42 confirms whether or not the OTT server 500 of the source of the request for the attachment or the subscriber information of the UE 200 that authenticates the OTT server 500 is registered with the MEC server ID of the MEC server 300. Hereinafter, the case where there is a registration will be described. That is, the attachment response contains the temporary ID of the MEC server. Next, the MME 41 transfers the attached response of the received MEC server 300 to the eNodeB 100 (step S610), and the eNodeB 100 transfers the received attach response to the MEC server 300 (step S612). Then, the MEC server 300 attaches to the network using the MEC server temporary ID included in the attach response (step S614).

<<7. Application examples>>

The technology described in 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 can be implemented as any type of server such as a tower server, a rack server, or a blade server. Further, at least a part of the MEC server 300, the MME 41, the HSS 42, or the OTT server 500 constitutes The element can also be implemented in a module mounted on a server (for example, an integrated circuit module composed of one wafer or a card inserted into a slot of a blade server or a blade). .

Further, for example, the terminal device 200 can be realized as a mobile terminal, a tablet PC (Personal Computer), a notebook PC, a portable game terminal, a portable/key type mobile router, or a mobile terminal such as a digital camera. Or an in-vehicle terminal such as a driving navigation device. Further, the terminal device 200 may be implemented as a terminal (also referred to as an MTC (Machine Type Communication) terminal) that performs M2M (Machine To Machine) communication. Further, at least a part of the components of the terminal device 200 can be realized by a module (for example, an integrated circuit module including one wafer) mounted on the terminals.

<7.1. Application examples of the server>

32 is a block diagram showing an example of a schematic configuration of a server 700 to which the technique described in the present disclosure is applicable. The server 700 includes a processor 701, a memory 702, a storage 703, a network interface 704, and a bus 706.

The processor 701 can be, for example, a CPU (Central Processing Unit) or a DSP (Digital Signal Processor), and controls various functions of the server 700. The memory 702 includes a RAM (Random Access Memory) and a ROM (Read Only Memory), and stores programs and data executed by the processor 701. The storage medium 703 may include a memory medium such as a semiconductor memory or a hard disk.

The network interface 704 is the wired communication interface required to connect the server 700 to the wired communication network 705. The wired communication network 705 can be a core network such as EPC (Evolved Packet Core), or can be a PDN (Packet Data Network) such as the Internet.

The bus 706 connects the processor 701, the memory 702, the storage 703, and the network interface 704 to each other. The busbar 706 system may also include two or more busbars having different speeds (for example, a high speed bus bar and a low speed bus bar).

In the server 700 shown in FIG. 32, one or more components (the authentication processing unit 331 and/or the communication processing unit 333) included in the MEC server 300 described with reference to FIG. 16 may be implemented. It is made in the processor 701. Further, in the server 700, one or more constituent elements (processing unit 430) included in the MME 41 or the HSS 42 described with reference to FIG. 17 may be implemented in the processor 701. Further, in the server 700, one or more components (the authentication processing unit 531 and/or the communication processing unit 533) included in the OTT server 500 described with reference to FIG. 24 may be implemented for processing. In 701. As an example, a program necessary for causing the processor to operate as one or more components (in other words, a program necessary for the processor to execute one or more components) may be mounted to the servo. The program 700 is executed by the processor 701. As another example, the server 700 may be equipped with a module including the processor 701 and the memory 702, and one or more components are actually implemented in the module. In this case, the above-mentioned module can also be used to remember the program required to make the processor operate as one or more components. The memory 702 is executed by the processor 701. As described above, the server 700 or the upper module may be provided by means of a device having one or more components as described above, and the above-mentioned memory for operating the processor to be one or more components may be provided. Program. Further, a readable recording medium on which the above program is recorded may be provided.

In the server 700 shown in FIG. 32, the communication unit 310 described with reference to FIG. 16, the communication unit 410 described with reference to FIG. 17, or the communication unit 510 described with reference to FIG. 24 may be used. In the network interface 704. Further, in the server 700 shown in FIG. 32, the memory unit 320 described with reference to FIG. 16, the memory unit 420 described with reference to FIG. 17, or the memory unit 520 described with reference to FIG. 24 may be used. It is implemented in the memory 702 or the storage 703.

<7.2. Related Application Examples of Terminal Devices>

(First application example)

Fig. 33 is a block diagram showing an example of a schematic configuration of a smartphone 900 to which the technology described in the present disclosure is applicable. The smart phone 900 includes a processor 901, a memory 902, a storage 903, an external connection interface 904, a camera 906, a sensor 907, a microphone 908, an input device 909, a display device 910, a speaker 911, and a wireless communication interface 912. One or more antenna switches 915, one or more antennas 916, a bus bar 917, a battery 918, and an auxiliary controller 919.

The processor 901 can be, for example, a CPU or a SoC (System on Chip), and controls an application layer of the smart phone 900 and other layers. can. The memory 902 includes a RAM and a ROM, and stores programs and data executed by the processor 901. The storage 903 may contain a memory medium such as a semiconductor memory or a hard disk. The external connection interface 904 may also be an interface required to connect an external device such as a memory card or a USB (Universal Serial Bus) device to the smart phone 900.

The camera 906 has an imaging element such as a CCD (Charge Coupled Device) or a CMOS (Complementary Metal Oxide Semiconductor), and generates an imaging image. The sensor 907 can include, for example, a sensor group of a positioning sensor, a gyro sensor, a geomagnetic sensor, and an acceleration sensor. The microphone 908 converts the sound input to the smart phone 900 into an audio signal. The input device 909 includes, for example, a touch sensor, a key pad, a keyboard, a button or a switch for detecting a touch on the screen of the display device 910, and accepts an operation or information input from a user. The display device 910 has a screen such as a liquid crystal display (LCD) or an organic light emitting diode (OLED) display, and displays an output image of the smart phone 900. The speaker 911 converts the sound signal output from the smartphone 900 into sound.

The wireless communication interface 912 supports any cellular communication method such as LTE or LTE-Advanced to perform wireless communication. The wireless communication interface 912 typically includes a BB processor 913, an RF circuit 914, and the like. The BB processor 913 is, for example, capable of performing encoding/decoding, modulation/demodulation, and multiplexing/reverse multiplexing, and performs various signal processing required for wireless communication. On the other hand, the RF circuit 914 may include a mixer, a filter, an amplifier, and the like, and transmits a wireless signal through the antenna 916. Wireless communication The interface 912 may also be a single-wafer module that is condensed by the BB processor 913 and the RF circuit 914. The wireless communication interface 912 can also include a plurality of BB processors 913 and a plurality of RF circuits 914 as shown in FIG. In addition, although FIG. 33 illustrates an example in which the wireless communication interface 912 includes a plurality of BB processors 913 and a plurality of RF circuits 914, the wireless communication interface 912 may also include a single BB processor 913 or a single RF circuit 914.

In addition, the wireless communication interface 912 can support short-range wireless communication methods, proximity wireless communication methods, or wireless LAN (Local Area Network) methods, etc., in addition to the cellular communication mode. It may include a BB processor 913 and an RF circuit 914 for each wireless communication method.

Each of the antenna switches 915 switches the connection destination of the antenna 916 between a plurality of circuits (for example, circuits used in different wireless communication methods) included in the wireless communication interface 912.

Each of the antennas 916 has a single or complex antenna element (e.g., a plurality of antenna elements that form a MIMO antenna) that is used to receive the wireless signals of the wireless communication interface 912. The smart phone 900 can also have a plurality of antennas 916 as shown in FIG. In addition, although FIG. 33 illustrates an example in which the smart phone 900 has a plurality of antennas 916, the smart phone 900 may have a single antenna 916.

Even the smart phone 900 can be equipped with an antenna 916 having a wireless communication method. In this case, the antenna switch 915 can be omitted from the configuration of the smartphone 900.

The bus 917 is a processor 901, a memory 902, The storage body 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 controller 919 are connected to each other. The battery 918 supplies power to each block of the smartphone 900 shown in FIG. 33 through a power supply line shown by a broken line in the figure. The auxiliary controller 919, for example, in the sleep mode, operates the minimum necessary function of the smartphone 900.

In the smartphone 900 shown in FIG. 33, one or more components (the authentication processing unit 241 and/or the communication processing unit 243) included in the terminal device 200 described with reference to FIG. 15 may be used. In the wireless communication interface 912. Alternatively, at least a part of these constituent elements may be implemented in the processor 901 or the auxiliary controller 919. As an example, the smart phone 900 can also be equipped with a module including a part of the wireless communication interface 912 (for example, the BB processor 913) or all, the processor 901, and/or the auxiliary controller 919, and implemented in the module. One or more components are listed above. In this case, the above-mentioned module can also be used to make the processor operate as a program for one or more components (in other words, a program required for the processor to execute one or more components). ) to remember and execute the program. As another example, a program required to make the processor operate as one or more components may be installed in the smart phone 900, by a wireless communication interface 912 (for example, the BB processor 913), the processor 901, and / or auxiliary controller 919 to execute the program. As described above, it is also possible to provide the smart phone 900 or the upper model by means of a device having one or more constituent elements. The group provides a program required to make the processor operate as one or more components. Further, a readable recording medium on which the above program is recorded may be provided.

Further, in the smartphone 900 shown in FIG. 33, for example, the wireless communication unit 220 described with reference to FIG. 15 may be implemented in the wireless communication interface 912 (for example, the RF circuit 914). Further, the antenna unit 210 can also be implemented in the antenna 916. Further, the memory unit 230 can also be implemented in the memory 902.

(Second application example)

Fig. 34 is a block diagram showing an example of a schematic configuration of a driving navigation device 920 to which the technique described in the present disclosure is applicable. The driving navigation device 920 includes a processor 921, a memory 922, a GPS (Global Positioning System) module 924, a sensor 925, a data interface 926, a content player 927, a memory medium interface 928, an input device 929, and 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 can be, for example, a CPU or SoC, controlling the navigation functions and other functions of the driving navigation device 920. The memory 922 includes a RAM and a ROM, and stores programs and data executed by the processor 921.

The GPS module 924 uses the GPS signals received from the GPS satellites to determine the position (eg, latitude, longitude, and altitude) of the driving navigation device 920. The sensor 925 can include, for example, a gyroscope sensor, A sensor group such as a geomagnetic sensor and a barometric sensor. The data interface 926 is connected to the in-vehicle network 941 via a terminal (not shown), for example, and acquires data generated by the vehicle side such as vehicle speed data.

The content player 927 reproduces the content stored in a memory medium (for example, a CD or a DVD) to be inserted into the memory medium interface 928. The input device 929 includes, for example, a touch sensor, a button or a switch that detects a touch on the screen of the display device 930, and accepts an operation 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 the content being reproduced. The speaker 931 outputs the sound of the navigation function or the content to be reproduced.

The wireless communication interface 933 supports any cellular communication method such as LTE or LTE-Advanced to perform wireless communication. The wireless communication interface 933, typically, may include a BB processor 934, an RF circuit 935, and the like. The BB processor 934 is, for example, capable of performing encoding/decoding, modulation/demodulation, and multiplexing/reverse multiplexing, and performs various signal processing required for wireless communication. On the other hand, the RF circuit 935 may also include a mixer, a filter, an amplifier, etc., and transmit the wireless signal through the antenna 937. The wireless communication interface 933 may also be a single-wafer module that is condensed by the BB processor 934 and the RF circuit 935. The wireless communication interface 933 may also include a plurality of BB processors 934 and a plurality of RF circuits 935 as shown in FIG. In addition, although the wireless communication interface 933 is illustrated in FIG. 34 as an example including a plurality of BB processors 934 and a plurality of RF circuits 935, the wireless communication interface 933 may also include a single BB processor 934 or a single RF circuit 935.

In addition, the wireless communication interface 933 can also support other types of wireless communication methods such as short-range wireless communication, proximity wireless communication, or wireless LAN, in addition to the cellular communication mode. In this case, each of the wireless communication interfaces may be included. BB processor 934 and RF circuit 935 of wireless communication mode.

Each of the antenna switches 936 switches the connection destination of the antenna 937 between a plurality of circuits (for example, circuits used in different wireless communication methods) included in the wireless communication interface 933.

Each of the antennas 937 has a single or multiple antenna elements (e.g., a plurality of antenna elements that form a MIMO antenna) that are used to receive wireless signals from the wireless communication interface 933. The driving navigation device 920 may also have a plurality of antennas 937 as shown in FIG. In addition, although FIG. 34 illustrates an example in which the driving navigation device 920 has a plurality of antennas 937, the driving navigation device 920 may have a single antenna 937.

Even the driving navigation device 920 can be provided with an antenna 937 for each wireless communication method. In this case, the antenna switch 936 can be omitted from the configuration of the driving navigation device 920.

The battery 938 is supplied with electric power to each block of the driving navigation device 920 shown in Fig. 34 through a power supply line shown by a broken line in the figure. Further, the battery 938 stores electric power supplied from the vehicle side.

In the navigation device 920 shown in FIG. 34, one or more components (the authentication processing unit 241 and/or the communication processing unit 243) included in the terminal device 200 described with reference to FIG. 15 may be used. In the wireless communication interface 933. Or at least one of these components The points can also be implemented in the processor 921. As an example, the driving navigation device 920 may be equipped with a module including a part of the wireless communication interface 933 (for example, the BB processor 934) or all of the processor 921, and one or more of the modules may be implemented in the module. Elements. In this case, the above-mentioned module can also be used to make the processor operate as a program for one or more components (in other words, a program required for the processor to execute one or more components). ) to remember and execute the program. As another example, a program required to operate the processor as one or more components may be installed in the navigation device 920 by a wireless communication interface 933 (eg, BB processor 934) and/or processor 921. To execute the program. As described above, it is also possible to provide the driving navigation device 920 or the above-described module by means of a device having one or more constituent elements, and to provide a processor for operating one or more components. Program. Further, a readable recording medium on which the above program is recorded may be provided.

Further, in the driving navigation device 920 shown in FIG. 34, for example, the wireless communication unit 220 described with reference to FIG. 15 may be implemented in the wireless communication interface 933 (for example, the RF circuit 935). Further, the antenna unit 210 can also be implemented in the antenna 937. Further, the memory unit 230 can also be implemented in the memory 922.

Further, the technology described in the present disclosure may be implemented as an in-vehicle system (or vehicle) 940 including one or more blocks of the above-described driving navigation device 920 and an in-vehicle network 941 and a vehicle-side module 942. In other words, the device of the authentication processing unit 241 and/or the communication processing unit 243 may be provided. In a way, an in-vehicle system (or vehicle) 940 is provided. The vehicle side module 942 generates vehicle side data such as vehicle speed, engine revolution number, or failure information, and outputs the generated data to the in-vehicle network 941.

<<8. Summary>>

Hereinabove, an embodiment of the present disclosure has been described in detail with reference to Figs. 1 to 34. As described above, the MEC server 300 or the OTT server 500 communicates with the network that has been authenticated using the authentication information corresponding to the server registered in the HSS 42 to provide content. In this way, it is possible to prevent the untrusted MEC server 300 or the OTT server 500 from being connected to the network. Moreover, by providing the key required for communication by the MEC server 300 or the OTT server 500, the occlusion of the communication path between the MEC server 300 or the OTT server 500 and the MME 41 or the UE 200 can be provided.

Although the preferred embodiment of the present disclosure has been described in detail above with reference to the accompanying drawings, the technical scope of the disclosure is not limited to the examples. As long as it is a person having ordinary knowledge in the technical field of the present disclosure, various modifications and modifications can be conceived within the scope of the technical idea described in the application scope, and these are of course also within the technical scope of the present disclosure.

For example, each of the embodiments described above can be combined as appropriate.

Further, the processes described in the flowcharts and the flowcharts in the present specification are not necessarily executed in the order shown. also A number of processing steps are performed in parallel. Further, an additional processing step may be employed, or some of the processing steps may be omitted.

Further, the effects described in the present specification are merely illustrative or exemplary, and are not intended to be construed as limiting. That is, the technology described in the present disclosure may also be used in addition to the effects described above, or may replace the effects of the above, to achieve other effects that the practitioner can self-evident according to the description of the present specification.

Further, the following configurations are also within the technical scope of the present disclosure.

(1)

A server is a server that provides content to another device, and includes a processing unit that is authenticated by using authentication information corresponding to a server registered in the HSS (Home Subscriber Server). , for communication.

(2)

The server described in (1) above, wherein the authentication information corresponding to the pre-log server is the authentication information of the pre-log server.

(3)

The server described in (2) above, wherein the authentication information of the pre-registration server includes: a number used to specify the pre-registration server and a key information inherent to the pre-registration server.

(4)

The server described in (2) or (3) above, wherein the pre-log server further includes: a memory unit, which is a memory pre-log server. The authentication information is used by the pre-recording department to authenticate the pre-recorded network using the authentication information of the pre-recorded server.

(5)

The server described in any one of the preceding paragraphs (2) to (4), wherein the key required for communication between the application operating on the server and the MME is based on the authentication information of the preceding server. generate.

(6)

The server described in the above (1), wherein the authentication information corresponding to the pre-log server is the authentication information of the terminal device to which the pre-recording server is established.

(7)

The server described in the above (6), wherein the authentication information of the pre-recording terminal device includes: a number for specifying the pre-recording terminal device and key information unique to the pre-recording terminal device.

(8)

The server described in the above (6) or (7), wherein the pre-processing unit uses a request made by the pre-recording server to establish a corresponding pre-recording terminal device based on the authentication of the pre-recorded network. The information being distributed to communicate with the pre-recorded network.

(9)

The server described in the above (8), wherein the key required for communication between the application operating on the pre-reporting server and the MME is based on the authentication information of the pre-recorded server that is associated with the previously recorded terminal device. Health to make.

(10)

The server described in any one of (1) to (9), wherein the key required for communication between the terminal device and the application operating on the preamble server is based on the authentication information of the pre-recorded terminal device. Was generated.

(11)

The server described in any one of the above (1) to (10), wherein the pre-log server is an application server provided inside the EPS.

(12)

The server described in the above (11), wherein the authentication information corresponding to the pre-recording server is the authentication information of the other server to which the pre-recording server is established.

(13)

The server described in the above (12), wherein the pre-processing unit is issued using a request made by another server based on the authentication of the pre-recorded network that was established before the pre-registration server was established. Information to communicate with the pre-recorded network.

(14)

The server described in (12) or (13) above, wherein the other server is a content server that provides content to the server.

(15)

The server described in any one of (1) to (10), wherein the pre-log server is a content server that provides content to an application server provided in the EPS.

(16)

The server described in (15) above, wherein the preamble server communicates with the MME via the base station.

(17)

The server described in the above (15), wherein the preamble server communicates with the MME without going through the base station.

(18)

The server described in any one of the above (1) to (10), wherein the preamble server is an application server provided in the wireless LAN network.

(19)

A method includes communicating with a network that has been authenticated by using a server that provides content to another device and that has been authenticated using the authentication information corresponding to the server registered in the HSS.

(20)

A program for causing a computer to function as a server that provides content to other devices, and the server includes: a processing unit that is associated with the authentication information corresponding to the server that has been registered in the HSS before being registered. The authenticated network communicates.

1‧‧‧ system

10A~10C‧‧‧Hive Network

40‧‧‧core network

50‧‧‧PDN

60‧‧‧Application Server

100A~100C‧‧‧Wireless communication device

200A~200C‧‧‧ terminal device

300A~300C‧‧‧MEC Server

Claims (20)

A server is a server that provides content to another device, and includes a processing unit that is authenticated by using authentication information corresponding to a server registered in the HSS (Home Subscriber Server). , for communication. The server described in claim 1, wherein the authentication information corresponding to the pre-log server is the authentication information of the pre-log server. The server according to claim 2, wherein the authentication information of the pre-registration server includes: a number used to specify the pre-log server and a key information inherent to the pre-log server. The server described in claim 2, wherein the pre-recording server further includes: a memory unit that authenticates the authentication information of the server; and the pre-processing unit uses the authentication information of the pre-log server to perform the pre-recording network. Certification. The server described in claim 2, wherein the key required for communication between the application operating on the preamble server and the MME is generated based on the authentication information of the preamble server. The server according to claim 1, wherein the authentication information corresponding to the pre-recording server is the authentication information of the terminal device to which the pre-recording server is established. The server according to claim 6, wherein the authentication information of the pre-recording terminal device includes: a number for specifying the pre-recording terminal device and the front Record the key information inherent to the terminal device. The server described in claim 6, wherein the pre-recording processing unit uses information that is issued based on a request made by the pre-recording server to establish a corresponding pre-recording terminal device based on the authentication of the pre-recorded network. To communicate with the pre-recorded network. The server according to claim 8, wherein the key required for communication between the application operating on the pre-reporting server and the MME is generated based on the authentication information of the pre-recorded server that is associated with the previously recorded terminal device. . The server according to claim 1, wherein the key required for communication between the terminal device and the application operating on the preamble server is generated based on the authentication information of the pre-recorded terminal device. The server described in claim 1, wherein the pre-log server is an application server provided inside the EPS. The server according to claim 11, wherein the authentication information corresponding to the pre-log server is the authentication information of the other server to which the pre-recording server is established. The server described in claim 12, wherein the pre-processing unit uses information that is issued based on a request made by another server based on the authentication of the pre-recorded network and the pre-recording server is established to correspond to the previous server. To communicate with the pre-recorded network. The server described in claim 12, wherein the other server is a content server that provides content to the server. The server described in claim 1, wherein the preamble server It is a content server that provides content to an application server that is set inside the EPS. The server according to claim 15, wherein the preamble server communicates with the MME via the base station. The server described in claim 15, wherein the preamble server communicates with the MME without going through the base station. The server described in claim 1, wherein the preamble server is an application server provided in the wireless LAN network. A method includes communicating with a network that has been authenticated by using a server that provides content to another device and that has been authenticated using the authentication information corresponding to the server registered in the HSS. A program for causing a computer to function as a server that provides content to other devices, and the server includes: a processing unit that is associated with the authentication information corresponding to the server that has been registered in the HSS before being registered. The authenticated network communicates.