WO2017110193A1 - サーバ、方法及びプログラム - Google Patents

サーバ、方法及びプログラム Download PDF

Info

Publication number
WO2017110193A1
WO2017110193A1 PCT/JP2016/078848 JP2016078848W WO2017110193A1 WO 2017110193 A1 WO2017110193 A1 WO 2017110193A1 JP 2016078848 W JP2016078848 W JP 2016078848W WO 2017110193 A1 WO2017110193 A1 WO 2017110193A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
mec
authentication information
mme
key
Prior art date
Application number
PCT/JP2016/078848
Other languages
English (en)
French (fr)
Inventor
高野　裕昭
齋藤　真
亮太 木村
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to DE112016005859.4T priority Critical patent/DE112016005859T5/de
Publication of WO2017110193A1 publication Critical patent/WO2017110193A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/062—Pre-authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]

Definitions

  • This disclosure relates to a server, a method, and a program.
  • MEC mobile edge computing
  • the edge server is arranged at a position physically close to the terminal, so that communication delay is shortened compared to a general cloud server arranged in a concentrated manner, and applications that require high real-time performance are used. It becomes possible. Also, in MEC, high-speed network application processing can be realized regardless of the performance of the terminal by distributing the functions previously processed on the terminal side to the edge server close to the terminal.
  • the edge server can have various functions including, for example, a function as an application server and a function as a content server, and can provide various services to the terminal.
  • Non-Patent Document 1 The contents of the study in Non-Patent Document 1 and the like are still short after the study was started, and it is hard to say that MEC-related technologies have been sufficiently proposed.
  • a technique for ensuring the security related to the edge server is one that has not been sufficiently proposed.
  • a server that provides content to other devices and performs communication with a network that has been authenticated using authentication information corresponding to the server registered in an HSS (Home Subscriber Server) A server is provided.
  • HSS Home Subscriber Server
  • a method including performing communication with a network authenticated using authentication information corresponding to the server registered in the HSS by a server that provides content to another device. Provided.
  • a computer is a server that provides content to other devices, and performs processing for communication with a network that is authenticated using authentication information corresponding to the server registered in the HSS.
  • a program for causing a server to function as a server is provided.
  • a mechanism for ensuring security related to the edge server is provided.
  • the above effects are not necessarily limited, and any of the effects shown in the present specification, or other effects that can be grasped from the present specification, together with or in place of the above effects. May be played.
  • FIG. 2 is an explanatory diagram illustrating an example of a schematic configuration of a system 1 according to an embodiment of the present disclosure.
  • FIG. It is a figure which shows an example of a structure of the LTE network in which MEC is not introduced. It is a figure which shows an example of a structure of the LTE network in which MEC was introduce
  • elements having substantially the same functional configuration may be distinguished by adding different alphabets after the same reference numerals.
  • a plurality of elements having substantially the same functional configuration are differentiated as necessary, such as base stations 100A, 100B, and 100C.
  • base stations 100A, 100B, and 100C when there is no need to particularly distinguish each of a plurality of elements having substantially the same functional configuration, only the same reference numerals are given.
  • the base stations 100A, 100B, and 100C they are simply referred to as the base station 100.
  • FIG. 1 is an explanatory diagram illustrating an example of a schematic configuration of a system 1 according to an embodiment of the present disclosure.
  • the system 1 includes a wireless communication device 100, a terminal device 200, and an MEC server 300.
  • the wireless communication device 100 is a device that provides a wireless communication service to subordinate devices.
  • the wireless communication device 100A is a base station of a cellular system (or mobile communication system).
  • the base station 100A performs wireless communication with a device (for example, the terminal device 200A) located inside the cell 10A of the base station 100A.
  • the base station 100A transmits a downlink signal to the terminal device 200A and receives an uplink signal from the terminal device 200A.
  • the base station 100 is also called eNodeB (or eNB).
  • the eNodeB here may be an eNodeB defined in LTE or LTE-A, and may more generally mean a communication device.
  • the base station 100A is logically connected to other base stations through, for example, an X2 interface, and can transmit and receive control information and the like.
  • the base station 100A is logically connected to the core network 40 through, for example, an S1 interface, and can transmit and receive control information and the like. Note that communication between these devices can be physically relayed by various devices.
  • the radio communication device 100A shown in FIG. 1 is a macro cell base station, and the cell 10A is a macro cell.
  • the wireless communication devices 100B and 100C are master devices that operate the small cells 10B and 10C, respectively.
  • the master device 100B is a small cell base station that is fixedly installed.
  • the small cell base station 100B establishes a wireless backhaul link with the macro cell base station 100A and an access link with one or more terminal devices (for example, the terminal device 200B) in the small cell 10B.
  • the master device 100C is a dynamic AP (access point).
  • the dynamic AP 100C is a mobile device that dynamically operates the small cell 10C.
  • the dynamic AP 100C establishes a radio backhaul link with the macro cell base station 100A and an access link with one or more terminal devices (for example, the terminal device 200C) in the small cell 10C.
  • the dynamic AP 100C may be, for example, a terminal device equipped with hardware or software that can operate as a base station or a wireless access point.
  • the small cell 10C in this case is a locally formed network (Localized Network / Virtual cell).
  • the cell 10 may be operated according to any wireless communication scheme such as LTE, LTE-A (LTE-Advanced), GSM (registered trademark), UMTS, W-CDMA, CDMA200, WiMAX, WiMAX2, or IEEE 802.16, for example.
  • LTE Long Term Evolution
  • LTE-A Long Term Evolution-Advanced
  • GSM registered trademark
  • the small cell is a concept that can include various types of cells (for example, femtocells, nanocells, picocells, and microcells) that are smaller than the macrocells and that are arranged so as to overlap or not overlap with the macrocells.
  • the small cell is operated by a dedicated base station.
  • the small cell is operated by a terminal serving as a master device temporarily operating as a small cell base station.
  • So-called relay nodes can also be considered as a form of small cell base station.
  • a wireless communication device that functions as a master station of a relay node is also referred to as a donor base station.
  • the donor base station may mean a DeNB (Donor eNodeB) in LTE, or more generally a parent station of a relay node.
  • DeNB Donor eNodeB
  • Terminal device 200 The terminal device 200 can communicate in a cellular system (or mobile communication system).
  • the terminal device 200 performs wireless communication with a wireless communication device (for example, the base station 100A, the master device 100B, or 100C) of the cellular system.
  • a wireless communication device for example, the base station 100A, the master device 100B, or 100C
  • the terminal device 200A receives a downlink signal from the base station 100A and transmits an uplink signal to the base station 100A.
  • the terminal device 200 is also called a user.
  • the user may also be referred to as a UE (User Equipment).
  • 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 be Prose UE to Network Relay, which is discussed in 3GPP, and more generally communicated. It may mean equipment.
  • 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.
  • 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.
  • the wireless communication apparatus 100 provides the service provided by the application server 60 to the MEC server 300 and the user via the packet data network 50, the core network 40, and the wireless communication path.
  • the MEC server 300 is a device that provides a service (for example, content) to a user.
  • the MEC server 300 can be provided in the wireless communication device 100.
  • 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 realized as a logical functional entity, and may be formed integrally with the wireless communication device 100 or the like as shown in FIG. Of course, the MEC server 300 may be formed as an independent device as a physical entity.
  • An application operating on the MEC server 300 is also referred to as an MEC application.
  • the base station 100A provides the service provided by the MEC server 300A to the terminal device 200A connected to the macro cell 10. Also, the base station 100A provides the service provided by the MEC server 300A to the terminal device 200B connected to the small cell 10B via the master device 100B.
  • the master device 100B provides the service provided by the MEC server 300B to the terminal device 200B connected to the small cell 10B.
  • the master device 100C provides the service provided by the MEC server 300C to the terminal device 200C connected to the small cell 10C.
  • FIG. 2 is a diagram illustrating an example of a configuration of an LTE network in which an MEC is not introduced.
  • the RAN Radio Access Network
  • the RAN includes a UE and an eNodeB.
  • the UE and the eNodeB are connected by a Uu interface, and the eNodeBs are connected by an X2 interface.
  • EPC Evolved Packet Core
  • MME Mobility Management Entity
  • HSS Home Subscriber Server
  • S-GW Serving Gateway
  • P-GW Packet Gateway
  • the MME and the HSS are connected by the S6a interface
  • the MME and the S-GW are connected by the S11 interface
  • the S-GW and the P-GW are connected by the S5 interface.
  • the eNodeB and the MME are connected by an S1-MME interface
  • the eNodeB and the S-GW are connected by an S1-U interface
  • the P-GW and the PDN are connected by an SGi interface.
  • the PDN includes, for example, an original server and a cache server.
  • the original server stores the original application provided to the UE.
  • an application or cache data is stored in the cache server.
  • the UE can reduce the processing load on the original server and the communication load related to the access to the original server.
  • the cache server is located outside the RAN and the EPC (ie, PDN)
  • the communication delay ie, response delay to the request from the UE
  • the UE request includes, for example, a static request such as downloading content stored in an http server and a dynamic request such as an operation for a specific application.
  • a static request such as downloading content stored in an http server
  • a dynamic request such as an operation for a specific application.
  • the response to the request becomes faster when the cache data and the application are arranged in an entity closer to the UE.
  • the response speed depends on the number of passing entities rather than the distance between the entities. This is because the processing delays in the input unit, processing unit, and output unit in each passing entity are accumulated by the number of entities.
  • the content means data in an arbitrary format such as an application, an image (moving image or still image), sound, or text.
  • an application server that provides content to the UE or acquires content from the UE is provided in an Evolved Packet System (EPS).
  • EPS is a network including EPC and eUTRAN (ie, eNodeB).
  • An application server provided in the EPS may be referred to as an edge server or an MEC server.
  • the application server is a concept including a cache server.
  • FIG. 3 and 4 are diagrams illustrating an example of a configuration of an LTE network in which an MEC is introduced.
  • an MEC server that caches content is provided in the eNodeB.
  • MEC servers that store content are provided in the eNodeB and the S-GW.
  • the UE obtains content from the MEC server located in the eNodeB, and obtains content from the MEC server located in the S-GW when there is no cache data requested from the MEC server located in the eNodeB. To do.
  • the UE can quickly acquire the content.
  • the S-GW is an entity serving as a handover anchor point.
  • 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 outside the mobile network.
  • the P-GW also performs filtering of data coming from the outside.
  • the HSS is a database that stores subscriber information.
  • the MME processes various control signals, accesses the HSS, and performs processing such as authentication and authorization of 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, and MME and HSS are mainly related to the control plane.
  • the S-GW has a function of storing user data in order to be an anchor point for handover even in the configuration before the introduction of the MEC.
  • the eNodeB has no function of storing user data in the configuration before the introduction of the MEC, only has a function such as packet retransmission corresponding to a packet loss occurring in the Uu interface, and no content is stored.
  • the X2 interface has been used for data exchange during handover and cooperative control of interference.
  • Application caches in the MEC server include a stream cache that performs caching at the IP level and a content cache that performs caching at the application layer level.
  • the MEC server is assumed to support any type of cache. Since the content cache is mainly used at present, it is assumed that the MEC server particularly supports the content cache.
  • the application is activated and can be operated in the MEC server.
  • the cache data is recognized by the HTTP header, it is desirable that an application capable of handling HTTP can be operated in the MEC server.
  • the MEC server provides a specific application, it is desirable that the application be deployed and activated to be operational.
  • the data cached in the MEC server 300 includes data transmitted to the UE in the DL (Downlink) direction (hereinafter also referred to as DL data flow) and uploaded from the UE in the UL (Uplink) direction.
  • DL data flow Downlink
  • Uplink Uplink
  • UL data flow There are two types of data (hereinafter also referred to as UL data flow).
  • caching the DL data flow for example, when the UE accesses a web application and acquires some http data, if the same data is cached in the MEC server, the cache data is acquired. Can be mentioned.
  • the first use case is a case of uploading data such as photos generated by the UE itself.
  • the UE uploads a photo generated by itself, and the MEC server caches this photo.
  • the MEC server may transfer the cached photo to the server that stores the photo on the PDN, for example, at a timing when the transmission capacity in the core network has a margin. By shifting the transfer timing, the communication load of the core network is reduced.
  • the MEC server may transfer the cached photo to another UE, for example.
  • the sharing of the UL data flow cache with other UEs is useful, for example, in the case where a photograph taken by a spectator at a stadium is shared between spectators at the stadium.
  • the second use case is a case of uploading data acquired by the UE.
  • the UE uploads data acquired by D2D (Device to Device) communication or Wi-Fi (registered trademark), and the MEC server caches this data.
  • D2D Device to Device
  • Wi-Fi registered trademark
  • a store broadcasts product information by D2D communication or Wi-Fi, and the UE acquires the information and uploads it to the MEC server.
  • other UEs in the area of the store for example, within the range of the cell of the eNodeB where the MEC server is provided
  • the third use case is a case where data received from a different eNodeB is uploaded.
  • the UE uploads the data received from the eNodeB connected before the handover to the MEC server provided in the eNodeB connected after the handover.
  • the fourth use case is a case where the MTC terminal uploads data.
  • data for example, sales data of vending machines, gas use status data detected by a gas meter, and the like can be considered.
  • the number of MTC terminals is very large, and there is a problem that congestion occurs on the core network side when the MTC terminals try to upload data to the server on the PDN all at once.
  • these data do not require real-time properties, it is sufficient to arrive even after one hour, for example. That is, it can be said that the application regarding the data from the MTC terminal is resistant to delay.
  • the MEC server may cache the data uploaded from the MTC terminal, and transfer the cached data to the server on the PDN at a timing when there is a margin in the transmission capacity in the core network, for example.
  • the transmission capacity of the core network has a problem with the capacity of the control signal rather than the capacity of the user data. This is because many round trips of signaling are required to create a session. If a large number of MTC terminals simultaneously upload data, the signaling of the core network increases excessively.
  • the cache data of the UL data flow may be transferred in the DL direction (for example, UE) as described above, or may be transferred in the UL direction (for example, a server on the P-GW or PDN).
  • the former cache data is also referred to as DL cache data
  • the latter cache data is also referred to as UL cache data.
  • FIG. 5 is a diagram showing an example of the data flow of DL cache data.
  • the MEC server caches data uploaded by the UE, and transmits the cache data to the UE (typically, a UE different from the uploaded UE).
  • FIG. 6 is a diagram showing an example of the data flow of UL cache data.
  • the MEC server caches the data uploaded by the UE and transmits the cache data to the original server on the PDN.
  • some data may not be permitted to be handled as DL cache data.
  • data that can be shared with other UEs is allowed to be handled as DL cache data, and personal data is not allowed to be handled as DL cache data.
  • some data is not permitted to be handled as UL cache data.
  • data that requires aggregation such as data from an MTC terminal is permitted as UL cache data, and local data such as region limitation is not permitted as UL cache data.
  • whether or not the cache data can be transmitted in the DL direction (ie, to the UE) and whether or not the cache data can be transmitted in the UL direction (ie, to the PDN) is appropriately managed Is desirable.
  • the bearer is a session and is a so-called earthen pipe for performing data transmission.
  • FIG. 7 is an explanatory diagram for explaining the architecture of the bearer.
  • the end-to-end service provided from the original server to the UE is provided by data transmission using an EPS bearer and an external bearer.
  • One EPS bearer is established corresponding to one kind of QoS. For example, when the UE wants to use two types of QoS at the same time, the UE establishes two EPS bearers corresponding to the two types of QoS with the P-GW.
  • the EPS bearer is a logical session (Virtual Connection), and actually includes a radio bearer, an S1 bearer, and an S5 bearer.
  • a radio bearer is a 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.
  • the EPS bearer includes a default bearer and a dedicated bearer.
  • the UE When the UE establishes a bearer by exchanging signals with the MME, the UE first establishes a default bearer corresponding to the QoS determined as the default. Thereafter, the UE establishes a bearer corresponding to the necessary QoS as a dedicated bearer. A dedicated bearer cannot be established without a default bearer.
  • Each bearer is set with an ID for identifying the bearer.
  • This ID is used to identify a bearer used by one UE. Accordingly, by using both the UE ID and the bearer ID, each entity (eg, P-GW, S-GW, eNodeB, etc.) can identify each bearer.
  • This ID includes UL and DL.
  • FIG. 9 is an explanatory diagram for explaining the ID for UL and the ID for DL set in the bearer.
  • the ID set for the radio bearer includes “UL RB ID” for UL and “DL RB ID” for DL.
  • the S1 bearer there is a session (session exchanged by GTP Tunneling Protocol) distinguished by TEID (Tunneling End point ID), and the UL ID “UL S1 TEID” or the DL ID “ “DL S1 TEID” is set.
  • the S5 bearer has a session that is distinguished by TEID, and “UL S5 TEID” that is an ID for UL or “DL S5 TEID” that is an ID for DL is set.
  • the table below shows which entity assigns each ID. This means that the entity assigned the ID has established the corresponding session responsibly.
  • TEID is assigned by the entity on the endpoint side.
  • RB ID both UL and DL are allocated by eNodeB.
  • the following table shows a list of data flow using ID.
  • the UL data flow is transmitted in a session to which a UL ID is assigned, and the DL data flow is transmitted in a session to which a DL ID is assigned.
  • Each session ID has a one-to-one mapping relationship, and one ID is mapped to one ID. That is, one ID is not mapped to a plurality of IDs.
  • FIG. 10 is a sequence diagram showing an example of a procedure flow for establishing a default bearer. This sequence involves UE, eNodeB, MME, S-GW, P-GW, and PCRF (Policy and Charging Rules Function). As shown in FIG. 10, the default bearer is established with a request from the UE as a starting point. Requests are sent in the order of eNodeB, MME, S-GW, and P-GW, and approval is sent back in the opposite direction.
  • the PCRF is an entity that provides information related to QoS.
  • the UE transmits an attach request to the eNodeB (step S11), and the eNodeB transmits the message to the MME (step S12).
  • the MME transmits a default bearer generation request to the S-GW (step S13), and the S-GW transmits the message to the P-GW (step S14).
  • the P-GW communicates with the PCRF to establish an IP-CAN (IP Connectivity Access Network) session (step S15).
  • the P-GW transmits a default bearer generation response to the S-GW (step S16), and the S-GW transmits the message to the MME (step S17).
  • the MME transmits an attach accept to the eNodeB (step S18), and the eNodeB transmits RRC (Radio Resource Control) connection resetting to the UE (step S19).
  • the UE transmits RRC connection reconfiguration completion to the eNodeB (step S20), and the eNodeB transmits attachment completion to the MME (step S21).
  • 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).
  • FIG. 11 is a sequence diagram showing an example of a procedure flow for establishing a dedicated bearer. This sequence involves UE, eNodeB, MME, S-GW, P-GW and PCRF. As shown in FIG. 11, the establishment of the dedicated bearer is performed starting from a request from the PCRF, contrary to the default bearer. When the UE wants to create a dedicated bearer, the UE transmits a message to that effect to the application layer, and the application layer conveys the QoS necessary for the PCRF, thereby establishing the dedicated bearer starting from the UE.
  • the PCRF transmits an IP-CAN session change start to the P-GW (step S31).
  • 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).
  • the MME transmits a dedicated bearer setup request to the eNodeB (step S34), and the eNodeB transmits RRC connection reconfiguration to the UE (step S35).
  • the UE transmits RRC connection reconfiguration completion to the eNodeB (step S36), and the eNodeB transmits a dedicated bearer setup response to the MME (step S37).
  • the MME transmits a dedicated bearer generation response to the S-GW (step S38), and the S-GW transmits the message to the P-GW (step S39).
  • the P-GW transmits an IP-CAN session change end to the PCRF (step S40).
  • Authentication is to determine whether a communication partner is an appropriate partner.
  • the appropriate partner refers to a partner who is appropriate to access the operator's LTE network, for example.
  • Authorization is to determine whether the communication partner has the right to use the service.
  • the right refers to, for example, a right to access the operator's LTE network.
  • the authentication procedure is a part of the attach procedure.
  • FIG. 12 is a sequence diagram showing an example of the flow of an authentication procedure executed in the LTE network.
  • the UE stores an IMSI (International Mobile Subscriber Identity) and a key K.
  • the HSS stores the IMSI of each UE and the key K corresponding to the IMSI.
  • the UE communicates with the MME via the eNodeB.
  • the UE and the HSS perform mutual authentication using the same IMSI and key K stored in each other.
  • the UE transmits an attach request together with the IMSI to the MME (Step S51).
  • the MME transmits an authentication request together with the received IMSI to the HSS (step S52).
  • the HSS generates a random number RAND, inputs the random number RAND, the received IMSI, and the key K stored in association with the IMSI to an authentication function, and an expected response RES EXPECTED.
  • the key K ASME is obtained (step S53).
  • the HSS transmits a key K ASME , an expected response RES EXPECTED, and a random number RAND to the MME as an authentication response (step S54).
  • the MME transmits a random number RAND to the UE (step S55).
  • the UE inputs the received random number RAND, the stored IMSI, and the key K to the authentication function, and obtains a response RES and a key K ASME (step S56).
  • the UE transmits a response RES to the MME (step S57).
  • the MME authenticates the UE by comparing the expected response RES EXPECTED with the actual response RES (step S58). For more information, MME determines that there is a reliable UE (i.e., authentication is successful) when the actual and the response RES and response RES EXPECTED expected matches. On the other hand, if the expected response RES EXPECTED and the actual response RES do not match, the MME determines that the UE is not reliable (that is, authentication fails).
  • CK Cipher Key
  • IK Integrity Key
  • CK is a key for encrypting communication, and is used to prevent the contents of communication from being known to others.
  • the IK is a key for confirming the integrity of the data, and is used for confirming whether the data has been changed on the communication path.
  • AA Authentication / Authorization
  • 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 for each application based on the common key K ASME .
  • HSS Home System
  • MME Mobility Management Entity
  • eNodeB eNodeB
  • FIG. 13 is an explanatory diagram for explaining an example of use of a key used in actual communication.
  • CK for the user plane is used between the UE and the eNodeB.
  • IK and CK for RRC (Radio Resource Control) signaling are used between the UE and the eNodeB.
  • IK and CK for NAS (Non-access stratum) signaling are used between the UE and the MME.
  • K ASME generated in the AA procedure.
  • FIG. 14 is a key system diagram.
  • enc means encryption
  • int means integrity
  • RRC means RRC signaling
  • NAS means NAS signaling
  • UP means user plane.
  • the key diagram shown in FIG. 14 is common to the UE side and the network side.
  • the NAS key is generated by the MME.
  • Keys for RRC signaling and user plane other than for NAS are generated by the eNodeB. All the UE-side keys are generated by the UE.
  • the key generation shown in FIG. 14 will be described along the time series.
  • HSS and the UE the mutual authentication (Mutual authentication), generates respectively K ASME.
  • the MME and the UE generate a NAS signaling key (ie, K NASinc and K NASint ) and a base key for eNodeB (ie, K eNodeB ) based on K ASME .
  • the eNodeB and the UE generate an RRC signaling key (that is, K RRCenc and K RRCint ) and a user plane key (that is, K UPenc ) based on the eNodeB base key.
  • RRC signaling key that is, K RRCenc and K RRCint
  • K UPenc user plane key
  • FIG. 15 is a block diagram illustrating an exemplary configuration of the terminal device 200 according to an embodiment of the present disclosure.
  • the terminal device 200 includes an antenna unit 210, a wireless communication unit 220, a storage unit 230, and a processing unit 240.
  • Antenna unit 210 The antenna unit 210 radiates the signal output from the wireless communication unit 220 to the space as a radio wave. Further, the antenna unit 210 converts a radio wave in the space into a signal and outputs the signal to the wireless communication unit 220.
  • the wireless communication unit 220 transmits and receives signals.
  • the radio communication unit 220 receives a downlink signal from the base station and transmits an uplink signal to the base station.
  • Storage unit 230 The storage unit 230 temporarily or permanently stores a program for operating the terminal device 200 and various data.
  • 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.
  • the processing unit 240 may further include other components other than these components. That is, the processing unit 240 can perform operations other than the operations of these components.
  • FIG. 16 is a block diagram illustrating an exemplary configuration of the MEC server 300 according to an embodiment of the present disclosure.
  • the MEC server 300 includes a communication unit 310, a storage unit 320, and a processing unit 330.
  • the communication unit 310 is an interface for performing communication with other devices.
  • the communication unit 310 communicates with the associated device.
  • the MEC server 300 when the MEC server 300 is formed as a logical entity and included in the base station 100, the communication unit 310 performs communication with, for example, the control unit of the base station 100.
  • the MEC server 300 may have an interface for performing direct communication with a device other than a device formed integrally.
  • Storage unit 320 temporarily or permanently stores a program for operating the MEC server 300 and various data.
  • the storage unit 320 may store various contents and applications provided to the user.
  • 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.
  • the processing unit 330 may further include other components other than these components. That is, the processing unit 330 can perform operations other than the operations of these components.
  • the processing unit 330 may include a content processing unit that provides content to the UE 200 or acquires content from the UE 200.
  • FIG. 17 is a block diagram illustrating an exemplary configuration of the EPC functional entities 41 and 42 according to an embodiment of the present disclosure.
  • the EPC functional entities 41 and 42 include a communication unit 410, a storage unit 420, and a processing unit 430.
  • the communication unit 410 is an interface for performing communication with other devices.
  • the communication unit 410 communicates with other EPC functional entities.
  • Storage unit 420 The storage unit 420 temporarily or permanently stores a program for operating the MME 41 or the HSS 42 and various data.
  • 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 base station 100 is also referred to as an eNodeB 100
  • the terminal device 200 is also referred to as a UE 200.
  • First Embodiment In the present embodiment, authentication using authentication information stored in the MEC server 300 is performed.
  • Each EPS entity (P-GW, S-GW, PCRF, HSS, eNodeB, etc.) is treated as a reliable entity, and mutual authentication between these entities is not standardized. .
  • the procedure for mutual authentication with the MME is standardized.
  • the MEC server is assumed to be located near the eNodeB, but should not be treated as a reliable entity. This is because the MEC server may be provided by various service providers. Therefore, it is desirable to confirm the reliability for each MEC server.
  • the MEC server 300 communicates with a network authenticated using authentication information corresponding to the MEC server 300 registered in the HSS 42.
  • the HSS 42 (for example, the storage unit 420) stores authentication information corresponding to the MEC server 300.
  • the authentication information corresponding to the MEC server 300 is the authentication information of the MEC server 300.
  • the authentication information of the MEC server 300 includes a number that identifies the MEC server 300 (that is, IMSI) and key information that is unique to the MEC server 300 (that is, key K).
  • the HSS 42 stores the IMSI for each MEC server 300 and also stores the key K corresponding to the IMSI of the MEC server 300.
  • One IMSI is registered in one MEC server 300. However, one common IMSI may be assigned to a plurality of MEC servers 300.
  • the MME 41 for example, the processing unit 430
  • the HSS 42 for example, the processing unit 430
  • the MEC server 300 (for example, the storage unit 320) stores authentication information of the MEC server 300.
  • the MEC server 300 (for example, the authentication processing unit 331) authenticates to the network using the authentication information of the MEC server 300. That is, the MEC server 300 according to the present embodiment performs authentication of the UE using the fact that the UE and the HSS store the same authentication information as described above with reference to FIG. Authenticate using the same mechanism. Then, the MEC server 300 (for example, the communication processing unit 333) performs communication with the authenticated network. Specifically, the MEC server 300 provides content to the UE 200 or acquires content from the UE 200 via an authenticated network (for example, the eNodeB 100 in the network). In this way, the MEC server 300 is authenticated as a reliable entity and can be connected to the network.
  • an authenticated network for example, the eNodeB 100 in the network
  • the MEC server 300 may store authentication information in hardware such as USIM (Universal Subscriber Identification Module).
  • the storage unit 320 is realized as hardware such as USIM.
  • the authentication information may be realized by software having a function equivalent to that of USIM.
  • the storage unit 320 stores the software.
  • the authentication information is registered, for example, by the MEC application operator.
  • the MEC server 300 may be used while switching networks of a plurality of operators (MNO: Mobile Network Operator).
  • MNO Mobile Network Operator
  • the authentication information may be stored in eSIM (Embedded Subscriber Identity Module) and mounted on the MEC server 300, for example.
  • eSIM embedded Subscriber Identity Module
  • the authentication information can be rewritten remotely, and the MEC server 300 can operate while switching networks of a plurality of operators.
  • the entity that rewrites the authentication information changes the authentication information after establishing a concealed communication path with the MEC server 300 by the encryption process.
  • the authentication procedure of the MEC server 300 is the same as that described above with reference to FIG. 12 except that the authentication subject is changed from the UE to the MEC server 300.
  • an authentication procedure according to the present embodiment will be described with reference to FIG.
  • FIG. 18 is a sequence diagram illustrating an example of a flow of an authentication procedure executed in the system 1 according to the present embodiment.
  • the MEC server 300 stores the IMSI and the key K.
  • the HSS 42 stores the IMSI of each MEC server 300 and the key K corresponding to the IMSI.
  • the MEC server 300 communicates with the MME 41 via the eNodeB 100.
  • the MEC server 300 transmits an attach request together with the IMSI to the MME 41 (Step S102).
  • the MME 41 transmits an authentication request together with the received IMSI to the HSS 42 (step S104).
  • the HSS 42 generates a random number RAND, inputs the random number RAND, the received IMSI, and the key K stored in association with the IMSI to the authentication function, and expects the response RES EXPECTED and the key K ASME. Is obtained (step S106).
  • the HSS 42 transmits the key K ASME , the expected response RES EXPECTED, and the random number RAND as the authentication response (step S108).
  • the MME 41 transmits a random number RAND to the MEC server 300 (step S110).
  • the MEC server 300 inputs the received random number RAND, the stored IMSI, and the key K to the authentication function, and obtains a response RES and a key K ASME (step S112).
  • the MEC server 300 transmits a response RES to the MME 41 (step S114).
  • the MME 41 authenticates the MEC server 300 by comparing the expected response RES EXPECTED with the actual response RES (step S116). Specifically, the MME 41 determines that the MEC server 300 is reliable when the expected response RES EXPECTED matches the actual response RES (that is, authentication is successful). On the other hand, the MME 41 determines that the MEC server 300 is not reliable when the expected response RES EXPECTED and the actual response RES do not match (that is, authentication fails).
  • the MEC server 300 may be an application server provided in the EPS.
  • the MEC server 300 may be an application server provided in a LAN (Local Area Network) network.
  • the MEC server 300 is provided, for example, at a wireless LAN access point.
  • the MEC server 300 performs an AA procedure via ePDG (enhanced Packet Data Gateway) using its own authentication information.
  • the ePDG is one of the EPC entities and is connected to the P-GW.
  • ePDG authenticates a wireless LAN terminal.
  • Second Embodiment the UE 200 performs proxy authentication of the MEC server 300.
  • the MEC server 300 stores its own authentication information. Typically, the MEC application provider sets this authentication information in 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 in the newly added MEC server 300. This is because setting authentication information via communication is not desirable from the viewpoint of confidentiality of authentication information (particularly key K). Even when the MEC server 300 is activated (for example, activated) from a remote location via communication, it is desirable that the MEC server 300 is more securely authenticated.
  • the UE 200 (for example, the authentication processing unit 241) performs authentication on behalf of the MEC server 300.
  • the HSS 42 (for example, the storage unit 420) stores authentication information corresponding to the MEC server 300.
  • the authentication information corresponding to the MEC server 300 is the authentication information of the UE 200 associated with the MEC server 300.
  • the authentication information of the UE 200 includes a number that identifies the UE 200 (that is, IMSI) and key information that is unique to the UE 200 (that is, the key K).
  • the HSS 42 stores the identification information of the MEC server 300 in association with the UE 200.
  • this identification information is also referred to as an MEC server ID.
  • the HSS 42 stores the MEC server ID of the MEC server 300 associated with the UE 200 as the subscriber information of the UE 200.
  • 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 the UE 200 instead of the MEC server 300 after the authentication procedure of the UE 200 is completed. Specifically, first, the UE 200 performs its own authentication procedure using its own IMSI and key K. Next, the UE 200 transmits an attach request of the MEC server 300 to the MME 41 or the eNodeB 100. When transmitting to the MME 41, NAS signaling is used. When transmitting to the eNodeB 100, RRC signaling is used.
  • the attach request of the MEC server 300 includes the MEC server ID. The attach request of the MEC server 300 may be regarded as a message requesting activation of the target MEC server 300.
  • the HSS 42 When receiving the attach request including the MEC server ID, the HSS 42 (for example, the processing unit 430) confirms whether or not the MEC server ID is registered in the subscriber information corresponding to the UE 200 that is the transmission source of the attach request. To do. Then, the HSS 42 returns an attach response including the confirmation result. If registered, the HSS 42 returns an attach response including the temporary ID.
  • This temporary ID is an ID given to the MEC server 300 that has been successfully authenticated. Hereinafter, this temporary ID is also referred to as an MEC server temporary ID.
  • the HSS 42 returns an attach response that does not include the MEC server temporary ID. In this case, the MEC server 300 cannot be connected to the network.
  • the MEC server 300 (for example, the communication processing unit 333), the information (that is, the MEC) issued based on the request (that is, the attach request) by the UE 200 associated with the MEC server 300 that has been successfully authenticated to the network. Communication with the network is performed using the server temporary ID. Since the system 1 can identify whether the MEC server 300 has been authenticated based on the issued information, security is ensured. In the present embodiment, authentication can be performed without setting authentication information in the MEC server 300, and higher security is ensured.
  • the eNodeB 100 and the MME 41 acquire and store the MEC server temporary ID in the process of transferring the attach response to the UE 200, and permit access by the MEC server 300 having the MEC server temporary ID. As a result, the MEC server 300 can be connected to the network while the MEC server temporary ID is valid.
  • the attach request for each MEC server 300 has been described. However, a similar authentication procedure may be performed for each MEC application operating on the MEC server 300. For example, each time a new MEC application is activated, an attach procedure for the MEC application may be performed. In this case, the attach response including the MEC server temporary ID may be regarded as permission to start the MEC application. The attach request including the MEC server ID may be regarded as an MEC application activation request. Further, the MEC server ID and the MEC server temporary ID may be set for each MEC application.
  • FIG. 19 is a sequence diagram illustrating an example of a flow of an authentication procedure executed in the system 1 according to the present embodiment. Note that the UE 200 communicates with the MME 41 via the eNodeB 100.
  • the UE 200 performs an attach procedure (step S202).
  • this attach procedure the authentication procedure described above with reference to FIG. 12 is performed, and the UE 200 is authenticated.
  • the UE 200 transmits an attach request for the MEC server 300 to the MME 41 (step S204).
  • This attach request includes the MEC server ID of the MEC server 300 to be authenticated.
  • the MME 41 transfers the received attach request of the MEC server 300 to the HSS 42 (step S206).
  • the HSS 42 returns an attach response of the MEC server 300 to the MME 41 (step S208).
  • 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 that is the transmission source of the attach request. Below, the case where it was registered is demonstrated. That is, the MEC server temporary ID is included in the attach response.
  • the MME 41 transfers the received attach response of the MEC server 300 to the eNodeB 100 (step S210), and the eNodeB 100 transfers the received attach response of the 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).
  • the MEC server 300 succeeds in the authentication procedure according to the first embodiment or the second embodiment, the MEC server 300 can communicate with the network. For this reason, as in the case of the UE, it is desirable to generate keys (for example, CK and IK) used in actual communication after the authentication procedure. For example, it is desirable that IK and CK used in communication between the MEC application and the MME 41 and communication between the MEC application and the UE 200 are generated.
  • keys for example, CK and IK
  • the key for communication between the MEC application and the MME 41 is generated based on the authentication information of the MEC server 300 (that is, the IMSI and key K of the MEC server 300). Specifically, first, in the attach procedure of the MEC server 300, the key K ASME is generated using the authentication information of the MEC server 300. Based on the key K ASME , keys for communication between the MEC application and the MME 41 (that is, CK and IK) are generated.
  • the CK and IK are also collectively referred to as a key K MEC Application-MME . That is, the key K MEC Application-MME includes CK and IK.
  • the key for communication between the MEC application and the MME 41 is generated based on the authentication information of the UE 200 associated with the MEC server 300 (that is, the IMSI and the key K of the UE 200). . Specifically, first, in the attach procedure of the UE 200, a 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 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 UE 200 attach procedure (step S54 shown in FIG. 12).
  • the MME 41 (for example, the storage unit 420) stores this key K ASME . Then, the MME 41 (e.g., processing unit 430), if the authentication of the MEC server 300 is successful, generates a key K MEC Application-MME based on the key K ASME which has been stored, the generated key K MEC Application- The MME is notified to the MEC server 300.
  • FIG. 20 shows a system diagram of keys related to the key K MEC Application-MME .
  • a key K MEC Application-MME is generated based on the K ASME of the UE 200 that has performed the attach procedure of the MEC server 300.
  • the key for communication between the MEC application and the UE 200 is generated based on the authentication information of the UE 200 (that is, the IMSI and the key K of the UE 200). Specifically, first, in the attach procedure of the UE 200, a key K ASME is generated using the authentication information of the UE 200. Then, the generated key K eNodeB based on the key K ASME, the CK and IK for communication with the MEC application and UE200 is generated based on the key K eNodeB.
  • the CK and IK are also collectively referred to as a key K UE-MEC Application . That is, the key K UE-MEC Application includes CK and IK. Note that regarding MEC applications that operate on the same MEC server 300, the same key K UE-MEC Application may be used among a plurality of MEC applications, or different keys K UE-MEC Application may be used. Good.
  • FIG. 21 shows a system diagram of keys relating to the key K UE-MEC Application .
  • a key K eNodeB is generated based on the key K ASME generated in the attach procedure of the UE 200
  • a key K UE-MEC Application is generated based on the key K eNodeB .
  • FIG. 22 An example of the arrangement of the OTT server is shown in FIG. 22 and FIG.
  • the OTT server 500 is arranged inside the EPC.
  • the OTT server 500 is arranged 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, and the like.
  • the reliability of the OTT server 500 be confirmed in the same manner as the MEC server 300.
  • a procedure for authenticating the OTT server 500 is provided.
  • FIG. 24 is a block diagram illustrating an exemplary configuration of the OTT server 500 according to an embodiment of the present disclosure.
  • the OTT server 500 includes a communication unit 510, a storage unit 520, and a processing unit 530.
  • the communication unit 510 is an interface for performing communication with other devices.
  • the communication unit 510 communicates with the MEC server 300 directly or indirectly via the P-GW 44 and the S-GW 43.
  • Storage unit 520 temporarily or permanently stores a program for operating the OTT server 500 and various data.
  • the storage unit 520 can store various contents and applications provided to the MEC server 300.
  • 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.
  • the processing unit 530 may further include other components other than these components. That is, 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 authentication processing unit 331 and the communication processing unit 333 described above. Although omitted in FIG. 24, the processing unit 530 may include a content processing unit that provides content to the MEC server 300.
  • This case is a case where the OTT server 500 is arranged in the EPC and the OTT server 500 is handled as a reliable entity. In this case, an authentication procedure for reconfirming the reliability of the OTT server 500 is not necessary. Of course, even in this case, an authentication procedure for confirming the reliability of the OTT server 500 may be performed.
  • Second Case This case is a case where the OTT server 500 is disposed outside the EPC, or is handled as an unreliable entity although the OTT server 500 is disposed inside the EPC.
  • the OTT server 500 may be authenticated by an authentication procedure similar to that of the MEC server 300 in the first embodiment.
  • the OTT server 500 has the same technical features as the MEC server 300 according to the first embodiment.
  • Each entity such as the MME 41 and the HSS 42 has the same technical features as those in the first embodiment except that the authentication target is changed from the MEC server 300 to the OTT server 500.
  • the technical feature of this case corresponds to that obtained by replacing the MEC server 300 with the OTT server 500 in the description related to the first embodiment.
  • the HSS 42 (for example, the storage unit 420) stores authentication information corresponding to the OTT server 500.
  • the authentication information corresponding to the OTT server 500 is the authentication information of the OTT server 500.
  • the authentication information of the OTT server 500 includes a number that identifies the OTT server 500 (that is, IMSI) and key information that is unique to the OTT server 500 (that is, key K).
  • the OTT server 500 (for example, the storage unit 520) also stores the authentication information of the OTT server 500. Then, the OTT server 500 (for example, the authentication processing unit 531) performs authentication to the network using the authentication information of the OTT server 500.
  • the OTT server 500 (for example, the communication processing unit 533) performs communication with the authenticated network. Specifically, the OTT server 500 provides content to the MEC server 300 via an authenticated network (for example, the eNodeB 100 in the network). In this way, the OTT server 500 is authenticated as a reliable entity and can be connected to the network.
  • an authenticated network for example, the eNodeB 100 in the network.
  • the OTT server 500 authentication procedure is the same as that described above with reference to FIG. 18 except that the authentication subject is changed from the MEC server 300 to the OTT server 500.
  • the authentication procedure according to this case will be described with reference to FIG.
  • FIG. 25 is a sequence diagram illustrating an example of the flow of an authentication procedure executed in the system 1 according to the present embodiment.
  • the OTT server 500 stores the IMSI and the key K.
  • the HSS 42 stores a key K corresponding to the IMSI of the OTT server 500.
  • the OTT server 500 communicates with the MME 41 via the eNodeB 100.
  • the OTT server 500 transmits an attach request together with the IMSI to the MME 41 (Step S302).
  • the MME 41 transmits an authentication request together with the received IMSI to the HSS 42 (step S304).
  • the HSS 42 generates a random number RAND, inputs the random number RAND, the received IMSI, and the key K stored in association with the IMSI to the authentication function, and expects the response RES EXPECTED and the key K ASME. Is obtained (step S306).
  • HSS42 as authentication response, key K ASME
  • the MME 41 transmits a response RES EXPECTED and the random number RAND is expected (step S308).
  • the MME 41 transmits a random number RAND to the OTT server 500 (step S310).
  • the OTT server 500 inputs the received random number RAND, the stored IMSI, and the key K to the authentication function, and obtains a response RES and a key K ASME (step S312).
  • the OTT server 500 transmits a response RES to the MME 41 (Step S314).
  • the MME 41 compares the expected response RES EXPECTED with the actual response RES to authenticate the OTT server 500 (step S316). Specifically, the MME 41 determines that the OTT server 500 is reliable when the expected response RES EXPECTED matches the actual response RES (that is, authentication is successful). On the other hand, the MME 41 determines that the OTT server 500 is not reliable when the expected response RES EXPECTED and the actual response RES do not match (that is, authentication fails).
  • a case where the OTT server 500 is directly connected to the MME 41 can be considered.
  • An arrangement example of the OTT server 500 in this case is shown in FIG.
  • the OTT server 500 is disposed inside the EPC and is directly connected to the MME 41.
  • the authentication procedure in this case is the same as that described above with reference to FIG. 25 except that communication between the OTT server 500 and the MME 41 does not pass through the eNodeB 100.
  • an authentication procedure according to this case will be described with reference to FIG.
  • FIG. 27 is a sequence diagram illustrating an example of the flow of an authentication procedure executed in the system 1 according to the present embodiment.
  • the OTT server 500 stores the IMSI and the key K.
  • the HSS 42 stores a key K corresponding to the IMSI of the OTT server 500.
  • the OTT server 500 communicates with the MME 41 without going through the eNodeB 100.
  • the OTT server 500 transmits an attach request together with the IMSI to the MME 41 (Step S402).
  • the MME 41 transmits an authentication request together with the received IMSI to the HSS 42 (step S404).
  • the HSS 42 generates a random number RAND, inputs the random number RAND, the received IMSI, and the key K stored in association with the IMSI to the authentication function, and expects the response RES EXPECTED and the key K ASME. Is obtained (step S406).
  • HSS42 as authentication response, key K ASME
  • the MME 41 transmits a response RES EXPECTED and the random number RAND is expected (step S408).
  • the MME 41 transmits a random number RAND to the OTT server 500 (step S410).
  • the OTT server 500 inputs the received random number RAND, the stored IMSI, and the key K to the authentication function, and obtains a response RES and a key K ASME (step S412).
  • the OTT server 500 transmits a response RES to the MME 41 (step S414).
  • the MME 41 authenticates the OTT server 500 by comparing the expected response RES EXPECTED with the actual response RES (step S416). Specifically, the MME 41 determines that the OTT server 500 is reliable when the expected response RES EXPECTED matches the actual response RES (that is, authentication is successful). On the other hand, the MME 41 determines that the OTT server 500 is not reliable when the expected response RES EXPECTED and the actual response RES do not match (that is, authentication fails).
  • the key for communication between the OTT server 500 and the MME 41 and the key for communication between the OTT server 500 and the MEC application are generated based on the authentication information of the OTT server 500.
  • the key K ASME is generated using the authentication information of the OTT server 500.
  • a key for communication between the OTT server 500 and the MME 41 and a key for communication between the OTT server 500 and the MEC application are generated.
  • the former key is also referred to as a key K OTT Server-MME
  • the latter key is also referred to as a key K OTT Server-MEC Application .
  • the key K OTT Server-MME includes CK and IK.
  • key K OTT Server-MEC Application includes CK and IK.
  • a system diagram of these keys is shown in FIG. As shown in FIG. 28, a key K OTT Server-MME and a key K OTT Server-MEC Application are generated based on K ASME generated in the attach procedure of the OTT server 500.
  • This case is a case where the UE 200 performs proxy authentication of the OTT server 500 as in the second embodiment.
  • the OTT server 500 has the same technical features as the MEC server 300 according to the second embodiment.
  • Each entity such as the UE 200, the MME 41, and the HSS 42 has the same technical features as those of the second embodiment except that the authentication target is changed from the MEC server 300 to the OTT server 500.
  • the technical feature of this case corresponds to that obtained by replacing the MEC server 300 with the OTT server 500 in the description related to the second embodiment.
  • the HSS 42 (for example, the storage unit 420) stores authentication information corresponding to the OTT server 500.
  • the authentication information corresponding to the OTT server 500 is the authentication information of the UE 200 associated with the OTT server 500.
  • the UE 200 (for example, the authentication processing unit 241) performs authentication on behalf of the OTT server 500.
  • the OTT server 500 (for example, the communication processing unit 533) uses information issued based on a request (that is, an attach request) by the UE 200 associated with the OTT server 500 that has been successfully authenticated to the network. To communicate with the network.
  • identification information unique to the OTT server 500 corresponding to the MEC server ID in the second embodiment is also referred to as an OTT server ID below.
  • information issued based on a request by the UE 200 that has succeeded in authentication to the network corresponding to the MEC server temporary ID in the second embodiment is also referred to as an OTT server temporary ID below.
  • FIG. 29 is a sequence diagram illustrating an example of the flow of an authentication procedure executed in the system 1 according to the present embodiment. Note that the UE 200 communicates with the MME 41 via the eNodeB 100.
  • the UE 200 performs an attach procedure (step S502).
  • this attach procedure the authentication procedure described above with reference to FIG. 12 is performed.
  • the UE 200 transmits an attach request for the OTT server 500 to the MME 41 (step S504).
  • This attach request includes an OTT server ID that is identification information unique to the OTT server 500 to be authenticated.
  • the MME 41 transfers the received attach request of the OTT server 500 to the HSS 42 (step S506).
  • the HSS 42 returns an attach response of the OTT server 500 to the MME 41 (step S508).
  • 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 that is the transmission source of the attach request.
  • the attach response includes the OTT server temporary ID.
  • the MME 41 transfers the received attach response of the OTT server 500 to the eNodeB 100 (step S510), and the eNodeB 100 transfers the received attach response of the OTT server 500 to the OTT server 500 (step S512).
  • the OTT server 500 attaches to the network using the OTT server temporary ID included in the attach response (step S514).
  • the key for communication between the OTT server 500 and the MME 41 and the key for communication between the OTT server 500 and the MEC application are generated based on the authentication information of the UE 200.
  • a key K ASME is generated using the authentication information of the UE 200.
  • a key K OTT Server-MME for communication between the OTT server 500 and the MME 41 and a key K OTT Server-MEC Application for communication between the OTT server 500 and the MEC application are generated. Is done.
  • a system diagram of these keys is shown in FIG.
  • a key K OTT Server-MME and a 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.
  • This case is a case where the OTT server 500 performs authentication of the MEC server 300 as a proxy.
  • the OTT server 500 has the same technical features as the UE 200 according to the second embodiment.
  • the same technique as in the second embodiment except that the authentication procedure using the authentication information of the UE 200 is changed to the authentication procedure using the authentication information of the OTT server 500.
  • Characteristic That is, the technical feature of this case is equivalent to the UE 200 replaced with the OTT server 500 in the above description regarding the second embodiment.
  • the HSS 42 (for example, the storage unit 420) stores authentication information corresponding to the MEC server 300.
  • the authentication information corresponding to the MEC server 300 is the authentication information of the OTT server 500 associated with the MEC server 300.
  • the HSS 42 (for example, the storage unit 420) stores the identification information of the MEC server 300, that is, the MEC server ID in association with the OTT server 500.
  • the HSS 42 stores the MEC server ID of the MEC server 300 associated with the OTT server 500 as the subscriber information of the OTT server 500.
  • the OTT server 500 (for example, the authentication processing unit 531) performs authentication on behalf of the MEC server 300.
  • the MEC server 300 (for example, the communication processing unit 333) is information (that is, an attach request) issued based on a request (that is, an attach request) by the OTT server 500 associated with the MEC server 300 that has been successfully authenticated to the network.
  • MEC server temporary ID is used for communication with the network. Since the system 1 can identify whether the MEC server 300 has been authenticated based on the issued information, security is ensured.
  • the OTT server 500 itself does not have authentication information, and the UE 200 may authenticate on behalf.
  • the authentication information used for the authentication of the MEC server 300 to the network may be the authentication information of the UE 200 associated with the MEC server 300 and proxying the authentication of the OTT server 500.
  • the HSS 42 (for example, the storage unit 420) stores, for example, an OTT server ID and an MEC server ID as subscriber identification information of the UE 200.
  • FIG. 31 is a sequence diagram showing an example of the flow of an authentication procedure executed in the system 1 according to the present embodiment.
  • the OTT server 500 communicates with the MME 41 via the eNodeB 100.
  • the OTT server 500 performs an attach procedure (step S602).
  • this attach procedure the authentication procedure described above with reference to FIG. 27 or FIG. 29 is performed, and the OTT server 500 is authenticated.
  • the OTT server 500 transmits an attach request for the MEC server 300 to the MME 41 (step S604).
  • This attach request includes the MEC server ID of the MEC server 300 to be authenticated.
  • the MME 41 transfers the received attach request of the MEC server 300 to the HSS 42 (step S606).
  • the HSS 42 returns an attach response of the MEC server 300 to the MME 41 (step S608).
  • the HSS 42 confirms whether or not the MEC server ID of the MEC server 300 is registered in the subscriber information of the OTT server 500 that is the transmission source of the attach request or the UE 200 proxying the authentication of the OTT server 500. .
  • the MEC server temporary ID is included in the attach response.
  • the MME 41 transfers the received attach response of the 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).
  • the MEC server 300 attaches to the network using the MEC server temporary ID included in the attach response (step S614).
  • the MEC server 300, the MME 41, the HSS 42, or the OTT server 500 may be realized as any type of server such as a tower server, a rack server, or a blade server.
  • a module for example, an integrated circuit module configured by one die or a blade server slot mounted on the server. Card or blade).
  • the terminal device 200 is a smartphone, a tablet PC (Personal Computer), a notebook PC, a portable game terminal, a mobile terminal such as a portable / dongle type mobile router or a digital camera, or an in-vehicle terminal such as a car navigation device. It may be realized as.
  • the terminal device 200 may be realized as a terminal (also referred to as an MTC (Machine Type Communication) terminal) that performs M2M (Machine To Machine) communication.
  • MTC Machine Type Communication
  • M2M Machine To Machine
  • at least a part of the components of the terminal device 200 may be realized in a module (for example, an integrated circuit module configured by one die) mounted on these terminals.
  • FIG. 32 is a block diagram illustrating an example of a schematic configuration of a server 700 to which the technology according to the present disclosure may be applied.
  • the server 700 includes a processor 701, a memory 702, a storage 703, a network interface 704, and a bus 706.
  • the processor 701 may be a CPU (Central Processing Unit) or a DSP (Digital Signal Processor), for example, 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 703 may include a storage medium such as a semiconductor memory or a hard disk.
  • the network interface 704 is a wired communication interface for connecting the server 700 to the wired communication network 705.
  • the wired communication network 705 may be a core network such as EPC (Evolved Packet Core) or a PDN (Packet Data Network) such as the Internet.
  • EPC Evolved Packet Core
  • PDN Packet Data Network
  • the bus 706 connects the processor 701, the memory 702, the storage 703, and the network interface 704 to each other.
  • the bus 706 may include two or more buses with different speeds (eg, a high speed bus and a low speed bus).
  • one or more components included in the MEC server 300 described with reference to FIG. Also good.
  • one or more components included in the MME 41 or the HSS 42 described with reference to FIG. 17 may be implemented in the processor 701.
  • one or more components included in the OTT server 500 described with reference to FIG. 24 may be implemented in the processor 701.
  • a program for causing a processor to function as the one or more components is installed in the server 700, and the processor 701 is The program may be executed.
  • the server 700 may include a module including the processor 701 and the memory 702, and the one or more components may be mounted in the module.
  • the module may store a program for causing the processor to function as the one or more components in the memory 702 and execute the program by the processor 701.
  • the server 700 or the module may be provided as an apparatus including the one or more components, and the program for causing a processor to function as the one or more components may be provided.
  • a readable recording medium in which the program is recorded may be provided.
  • the communication unit 310 described above with reference to FIG. 16, the communication unit 410 described above with reference to FIG. 17, or the communication unit 510 described above with reference to FIG. It may be implemented in the network interface 704.
  • the storage unit 320 described above with reference to FIG. 16, the storage unit 420 described above with reference to FIG. 17, or the storage unit 520 described above with reference to FIG. May be implemented in the memory 702 or the storage 703.
  • FIG. 33 is a block diagram illustrating an example of a schematic configuration of a smartphone 900 to which the technology according to the present disclosure may be applied.
  • the smartphone 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, a wireless communication interface 912, one or more antenna switches 915.
  • One or more antennas 916, a bus 917, a battery 918 and an auxiliary controller 919 are provided.
  • the processor 901 may be, for example, a CPU or a SoC (System on Chip), and controls the functions of the application layer and other layers of the smartphone 900.
  • the memory 902 includes a RAM and a ROM, and stores programs executed by the processor 901 and data.
  • the storage 903 can include a storage medium such as a semiconductor memory or a hard disk.
  • the external connection interface 904 is an interface for connecting an external device such as a memory card or a USB (Universal Serial Bus) device to the smartphone 900.
  • the camera 906 includes, for example, an image sensor such as a CCD (Charge Coupled Device) or a CMOS (Complementary Metal Oxide Semiconductor), and generates a captured image.
  • the sensor 907 may include a sensor group such as a positioning sensor, a gyro sensor, a geomagnetic sensor, and an acceleration sensor.
  • the microphone 908 converts sound input to the smartphone 900 into an audio signal.
  • the input device 909 includes, for example, a touch sensor that detects a touch on the screen of the display device 910, a keypad, a keyboard, a button, or a switch, and receives 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 smartphone 900.
  • the speaker 911 converts an audio signal output from the smartphone 900 into audio.
  • the wireless communication interface 912 supports any cellular communication method such as LTE or LTE-Advanced, and performs wireless communication.
  • the wireless communication interface 912 may typically include a BB processor 913, an RF circuit 914, and the like.
  • the BB processor 913 may perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and performs various signal processing for wireless communication.
  • the RF circuit 914 may include a mixer, a filter, an amplifier, and the like, and transmits and receives radio signals via the antenna 916.
  • the wireless communication interface 912 may be a one-chip module in which the BB processor 913 and the RF circuit 914 are integrated.
  • the wireless communication interface 912 may include a plurality of BB processors 913 and a plurality of RF circuits 914 as illustrated in FIG.
  • FIG. 33 shows 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 includes a single BB processor 913 or a single RF circuit 914. But you can.
  • the wireless communication interface 912 may support other types of wireless communication methods such as a short-range wireless communication method, a proximity wireless communication method, or a wireless LAN (Local Area Network) method in addition to the cellular communication method.
  • a BB processor 913 and an RF circuit 914 for each wireless communication method may be included.
  • Each of the antenna switches 915 switches the connection destination of the antenna 916 among a plurality of circuits (for example, circuits for different wireless communication systems) included in the wireless communication interface 912.
  • Each of the antennas 916 includes a single or a plurality of antenna elements (for example, a plurality of antenna elements constituting a MIMO antenna), and is used for transmission / reception of a radio signal by the radio communication interface 912.
  • the smartphone 900 may include a plurality of antennas 916 as illustrated in FIG. Note that although FIG. 33 illustrates an example in which the smartphone 900 includes a plurality of antennas 916, the smartphone 900 may include a single antenna 916.
  • the smartphone 900 may include an antenna 916 for each wireless communication method.
  • the antenna switch 915 may be omitted from the configuration of the smartphone 900.
  • the bus 917 connects the processor 901, the memory 902, the storage 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 to each other.
  • the battery 918 supplies electric power to each block of the smartphone 900 shown in FIG. 33 through a power supply line partially shown by a broken line in the drawing.
  • the auxiliary controller 919 operates the minimum necessary functions of the smartphone 900 in the sleep mode.
  • the smartphone 900 illustrated 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 are implemented in the wireless communication interface 912. May be. Alternatively, at least some of these components may be implemented in the processor 901 or the auxiliary controller 919. As an example, the smartphone 900 includes a module including a part (for example, the BB processor 913) or the whole of the wireless communication interface 912, the processor 901, and / or the auxiliary controller 919, and the one or more components in the module. May be implemented.
  • the module stores a program for causing the processor to function as the one or more components (in other words, a program for causing the processor to execute the operation of the one or more components).
  • the program may be executed.
  • a program for causing a processor to function as the one or more components is installed in the smartphone 900, and the wireless communication interface 912 (eg, the BB processor 913), the processor 901, and / or the auxiliary controller 919 is The program may be executed.
  • the smartphone 900 or the module may be provided as a device including the one or more components, and a program for causing a processor to function as the one or more components may be provided.
  • a readable recording medium in which the program is recorded may be provided.
  • 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).
  • the antenna unit 210 may be mounted on the antenna 916.
  • the storage unit 230 may be mounted in the memory 902.
  • FIG. 34 is a block diagram illustrating an example of a schematic configuration of a car navigation device 920 to which the technology according to the present disclosure can be applied.
  • the car 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 storage medium interface 928, an input device 929, a display device 930, a speaker 931, and wireless communication.
  • the interface 933 includes one or more antenna switches 936, one or more antennas 937, and a battery 938.
  • the processor 921 may be a CPU or SoC, for example, and controls the navigation function and other functions of the car navigation device 920.
  • the memory 922 includes RAM and ROM, and stores programs and data executed by the processor 921.
  • the GPS module 924 measures the position (for example, latitude, longitude, and altitude) of the car navigation device 920 using GPS signals received from GPS satellites.
  • the sensor 925 may include a sensor group such as a gyro sensor, a geomagnetic sensor, and an atmospheric pressure sensor.
  • the data interface 926 is connected to the in-vehicle network 941 through a terminal (not shown), for example, and acquires data generated on the vehicle side such as vehicle speed data.
  • the content player 927 reproduces content stored in a storage medium (for example, CD or DVD) inserted into the storage 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 receives an operation or information input from the user.
  • the display device 930 has a screen such as an LCD or an OLED display, and displays a navigation function or an image of content to be reproduced.
  • the speaker 931 outputs the navigation function or the audio of the content to be played back.
  • the wireless communication interface 933 supports any cellular communication method such as LTE or LTE-Advanced, and performs wireless communication.
  • the wireless communication interface 933 may typically include a BB processor 934, an RF circuit 935, and the like.
  • the BB processor 934 may perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and performs various signal processing for wireless communication.
  • the RF circuit 935 may include a mixer, a filter, an amplifier, and the like, and transmits and receives a radio signal via the antenna 937.
  • the wireless communication interface 933 may be a one-chip module in which the BB processor 934 and the RF circuit 935 are integrated.
  • the wireless communication interface 933 may include a plurality of BB processors 934 and a plurality of RF circuits 935 as shown in FIG. 34 shows an example in which the wireless communication interface 933 includes a plurality of BB processors 934 and a plurality of RF circuits 935, the wireless communication interface 933 includes a single BB processor 934 or a single RF circuit 935. But you can.
  • the wireless communication interface 933 may support other types of wireless communication methods such as a short-range wireless communication method, a proximity wireless communication method, or a wireless LAN method in addition to the cellular communication method.
  • a BB processor 934 and an RF circuit 935 may be included for each communication method.
  • Each of the antenna switches 936 switches the connection destination of the antenna 937 among a plurality of circuits included in the wireless communication interface 933 (for example, circuits for different wireless communication systems).
  • Each of the antennas 937 has a single or a plurality of antenna elements (for example, a plurality of antenna elements constituting a MIMO antenna), and is used for transmission / reception of a radio signal by the radio communication interface 933.
  • the car navigation device 920 may include a plurality of antennas 937 as shown in FIG. FIG. 34 shows an example in which the car navigation device 920 includes a plurality of antennas 937, but the car navigation device 920 may include a single antenna 937.
  • the car navigation device 920 may include an antenna 937 for each wireless communication method.
  • the antenna switch 936 may be omitted from the configuration of the car navigation device 920.
  • the battery 938 supplies power to each block of the car navigation device 920 shown in FIG. 34 via a power supply line partially shown by a broken line in the drawing. Further, the battery 938 stores electric power supplied from the vehicle side.
  • the car navigation apparatus 920 includes a module including a part (for example, the BB processor 934) or the whole of the wireless communication interface 933 and / or the processor 921, and the one or more components are mounted in the module. May be.
  • the module stores a program for causing the processor to function as the one or more components (in other words, a program for causing the processor to execute the operation of the one or more components). The program may be executed.
  • a program for causing a processor to function as the one or more components is installed in the car navigation device 920, and the wireless communication interface 933 (eg, the BB processor 934) and / or the processor 921 executes the program.
  • the car navigation apparatus 920 or the module may be provided as an apparatus including the one or more components, and a program for causing a processor to function as the one or more components may be provided. Good.
  • a readable recording medium in which the program is recorded may be provided.
  • the radio communication unit 220 described with reference to FIG. 15 may be implemented in the radio communication interface 933 (for example, the RF circuit 935).
  • the antenna unit 210 may be mounted on the antenna 937.
  • the storage unit 230 may be implemented in the memory 922.
  • the technology according to the present disclosure may be realized as an in-vehicle system (or vehicle) 940 including one or more blocks of the car navigation device 920 described above, an in-vehicle network 941, and a vehicle side module 942. That is, the in-vehicle system (or vehicle) 940 may be provided as a device including the authentication processing unit 241 and / or the communication processing unit 243.
  • the vehicle-side module 942 generates vehicle-side data such as vehicle speed, engine speed, or failure information, and outputs the generated data to the in-vehicle network 941.
  • the MEC server 300 or the OTT server 500 communicates with the network authenticated using the authentication information corresponding to the server registered in the HSS 42 and provides the content. In this way, the MEC server 300 or the OTT server 500 whose reliability has not been confirmed is prevented from connecting to the network. Further, by providing a key for communication by the MEC server 300 or the OTT server 500, it is possible to improve the confidentiality of the communication path between the MEC server 300 or the OTT server 500 and the MME 41 or the UE 200.
  • a server that provides content to other devices A processing unit for communicating with a network authenticated using authentication information corresponding to the server registered in an HSS (Home Subscriber Server);
  • a server comprising (2) The server according to (1), wherein the authentication information corresponding to the server is authentication information of the server.
  • the server further includes a storage unit that stores authentication information of the server, The server according to (2) or (3), wherein the processing unit performs authentication to the network using authentication information of the server.
  • the processing unit communicates with the network using information issued based on a request from the terminal device associated with the server, which has been successfully authenticated to the network, (6) or The server according to (7).
  • the server according to (8) wherein a key for communication between the application operating on the server and the MME is generated based on authentication information of the terminal device associated with the server.
  • the authentication information corresponding to the server is authentication information of another server associated with the server.
  • the processing unit communicates with the network using information issued based on a request from the other server associated with the server, which has been successfully authenticated to the network, Server described in.
  • a server that provides content to other devices Communicating with an authenticated network using authentication information corresponding to the server registered in the HSS; Including methods.

Abstract

【課題】エッジサーバに関するセキュリティを担保するための仕組みを提供する。 【解決手段】他の装置へのコンテンツを提供するサーバであって、ＨＳＳ（Home　Subscriber　Server）に登録された前記サーバに対応する認証情報を用いて認証されたネットワークとの通信を行う処理部、を備えるサーバ。

Description

サーバ、方法及びプログラム
　本開示は、サーバ、方法及びプログラムに関する。
　近年、スマートフォン等の端末と物理的に近い位置に設けられたサーバ（以下、エッジサーバとも称する）でデータ処理を行う、モバイルエッジコンピューティング（ＭＥＣ：Mobile-Edge　Computing）技術が注目を浴びている。例えば、下記非特許文献１では、ＭＥＣに関する技術の標準規格について検討されている。
　ＭＥＣでは、端末と物理的に近い位置にエッジサーバが配置されるため、集中的に配置される一般的なクラウドサーバと比較して通信遅延が短縮され、高いリアルタイム性が求められるアプリケーションの利用が可能となる。また、ＭＥＣでは、これまでは端末側で処理されていた機能を端末に近いエッジサーバに分散処理させることで、端末の性能によらず高速なネットワーク・アプリケーション処理を実現することができる。エッジサーバは、例えばアプリケーションサーバとしての機能、及びコンテンツサーバとしての機能を始め多様な機能を有し得、端末に多様なサービスを提供することができる。
ＥＴＳＩ，"Mobile-Edge　Computing-Introductory　Technical　White　Paper"，２０１４年９月，［平成２７年９月３日検索］，インターネット＜https://portal.etsi.org/Portals/0/TBpages/MEC/Docs/Mobile-edge_Computing_-_Introductory_Technical_White_Paper_V1%2018-09-14.pdf＞
　上記非特許文献１等における検討内容は、検討が開始されてから未だ日が浅く、ＭＥＣに関する技術が十分に提案されているとはいいがたい。例えば、エッジサーバに関するセキュリティを担保するための技術も、十分には提案されていないものの一つである。
　本開示によれば、他の装置へのコンテンツを提供するサーバであって、ＨＳＳ（Home　Subscriber　Server）に登録された前記サーバに対応する認証情報を用いて認証されたネットワークとの通信を行う処理部、を備えるサーバが提供される。
　また、本開示によれば、他の装置へのコンテンツを提供するサーバにより、ＨＳＳに登録された前記サーバに対応する認証情報を用いて認証されたネットワークとの通信を行うこと、を含む方法が提供される。
　また、本開示によれば、コンピュータを、他の装置へのコンテンツを提供するサーバであって、ＨＳＳに登録された前記サーバに対応する認証情報を用いて認証されたネットワークとの通信を行う処理部を含むサーバ、として機能させるためのプログラムが提供される。
　以上説明したように本開示によれば、エッジサーバに関するセキュリティを担保するための仕組みが提供される。なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。
本開示の一実施形態に係るシステム１の概略的な構成の一例を示す説明図である。 ＭＥＣが未導入のＬＴＥネットワークの構成の一例を示す図である。 ＭＥＣが導入されたＬＴＥネットワークの構成の一例を示す図である。 ＭＥＣが導入されたＬＴＥネットワークの構成の一例を示す図である。 ＤＬキャッシュデータのデータの流れの一例を示す図である。 ＵＬキャッシュデータのデータの流れの一例を示す図である。 ベアラのアーキテクチャを説明するための説明図である。 ＥＰＳベアラのアーキテクチャを説明するための説明図である。 ベアラに設定されるＵＬ用ＩＤ及びＤＬ用ＩＤを説明するための説明図である。 デフォルトベアラを確立するための手続きの流れの一例を示すシーケンス図である。 専用ベアラを確立するための手続きの流れの一例を示すシーケンス図である。 ＬＴＥネットワークにおいて実行される認証手続きの流れの一例を示すシーケンス図である。 実際の通信の際に使用される鍵の用途の例を説明するための説明図である。 鍵の系統図である。 本開示の一実施形態に係る端末装置の構成の一例を示すブロック図である。 本開示の一実施形態に係るＭＥＣサーバの構成の一例を示すブロック図である。 本開示の一実施形態に係るＥＰＣ機能エンティティの構成の一例を示すブロック図である。 第１の実施形態に係る技術的特徴を説明するための説明図である。 第２の実施形態に係る技術的特徴を説明するための説明図である。 第３の実施形態に係る技術的特徴を説明するための説明図である。 同実施形態に係る技術的特徴を説明するための説明図である。 第４の実施形態に係る技術的特徴を説明するための説明図である。 同実施形態に係る技術的特徴を説明するための説明図である。 同実施形態に係る技術的特徴を説明するための説明図である。 同実施形態に係る技術的特徴を説明するための説明図である。 同実施形態に係る技術的特徴を説明するための説明図である。 同実施形態に係る技術的特徴を説明するための説明図である。 同実施形態に係る技術的特徴を説明するための説明図である。 同実施形態に係る技術的特徴を説明するための説明図である。 同実施形態に係る技術的特徴を説明するための説明図である。 同実施形態に係る技術的特徴を説明するための説明図である。 サーバの概略的な構成の一例を示すブロック図である。 スマートフォンの概略的な構成の一例を示すブロック図である。 カーナビゲーション装置の概略的な構成の一例を示すブロック図である。
　以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
　また、本明細書及び図面において、実質的に同一の機能構成を有する要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。例えば、実質的に同一の機能構成を有する複数の要素を、必要に応じて基地局１００Ａ、１００Ｂ及び１００Ｃのように区別する。ただし、実質的に同一の機能構成を有する複数の要素の各々を特に区別する必要がない場合、同一符号のみを付する。例えば、基地局１００Ａ、１００Ｂ及び１００Ｃを特に区別する必要が無い場合には、単に基地局１００と称する。
　なお、説明は以下の順序で行うものとする。
　　１．はじめに
　　　１．１．システムの概略的な構成
　　　１．２．ＭＥＣ
　　　１．３．ベアラ
　　　１．４．セキュリティ
　　２．各装置の構成例
　　　２．１．端末装置の構成
　　　２．２．ＭＥＣサーバの構成例
　　　２．３．ＥＰＣ機能エンティティの構成例
　　３．第１の実施形態
　　　３．１．技術的課題
　　　３．２．技術的特徴
　　４．第２の実施形態
　　　４．１．技術的課題
　　　４．２．技術的特徴
　　５．第３の実施形態
　　　５．１．技術的課題
　　　５．２．技術的特徴
　　６．第４の実施形態
　　　６．１．技術的課題
　　　６．２．ＯＴＴサーバの構成例
　　　６．３．技術的特徴
　　７．応用例
　　８．まとめ
　＜＜１．はじめに＞＞
　　＜１．１．システムの概略的な構成＞
　まず、図１を参照して、本開示の一実施形態に係るシステム１の概略的な構成を説明する。図１は、本開示の一実施形態に係るシステム１の概略的な構成の一例を示す説明図である。図１を参照すると、システム１は、無線通信装置１００、端末装置２００、及びＭＥＣサーバ３００を含む。
　　（１）無線通信装置１００
　無線通信装置１００は、配下の装置に無線通信サービスを提供する装置である。例えば、無線通信装置１００Ａは、セルラーシステム（又は移動体通信システム）の基地局である。基地局１００Ａは、基地局１００Ａのセル１０Ａの内部に位置する装置（例えば、端末装置２００Ａ）との無線通信を行う。例えば、基地局１００Ａは、端末装置２００Ａへのダウンリンク信号を送信し、端末装置２００Ａからのアップリンク信号を受信する。
　ここでは、基地局１００は、ｅＮｏｄｅＢ（又はｅＮＢ）とも呼ばれる。ここでのｅＮｏｄｅＢは、ＬＴＥ又はＬＴＥ－Ａにおいて定義されているｅＮｏｄｅＢであってもよく、より一般的に通信機器を意味してもよい。
　基地局１００Ａは、他の基地局と例えばＸ２インタフェースにより論理的に接続されており、制御情報等の送受信が可能である。また、基地局１００Ａは、コアネットワーク４０と例えばＳ１インタフェースにより論理的に接続されており、制御情報等の送受信が可能である。なお、これらの装置間の通信は、物理的には多様な装置により中継され得る。
　ここで、図１に示した無線通信装置１００Ａは、マクロセル基地局であり、セル１０Ａはマクロセルである。一方で、無線通信装置１００Ｂ及び１００Ｃは、スモールセル１０Ｂ及び１０Ｃをそれぞれ運用するマスタデバイスである。一例として、マスタデバイス１００Ｂは、固定的に設置されるスモールセル基地局である。スモールセル基地局１００Ｂは、マクロセル基地局１００Ａとの間で無線バックホールリンクを、スモールセル１０Ｂ内の１つ以上の端末装置（例えば、端末装置２００Ｂ）との間でアクセスリンクをそれぞれ確立する。マスタデバイス１００Ｃは、ダイナミックＡＰ（アクセスポイント）である。ダイナミックＡＰ１００Ｃは、スモールセル１０Ｃを動的に運用する移動デバイスである。ダイナミックＡＰ１００Ｃは、マクロセル基地局１００Ａとの間で無線バックホールリンクを、スモールセル１０Ｃ内の１つ以上の端末装置（例えば、端末装置２００Ｃ）との間でアクセスリンクをそれぞれ確立する。ダイナミックＡＰ１００Ｃは、例えば、基地局又は無線アクセスポイントとして動作可能なハードウェア又はソフトウェアが搭載された端末装置であってよい。この場合のスモールセル１０Ｃは、動的に形成される局所的なネットワーク（Localized　Network／Virtual　cell）である。
　セル１０は、例えば、ＬＴＥ、ＬＴＥ－Ａ（LTE-Advanced）、ＧＳＭ（登録商標）、ＵＭＴＳ、Ｗ－ＣＤＭＡ、ＣＤＭＡ２００、ＷｉＭＡＸ、ＷｉＭＡＸ２又はＩＥＥＥ８０２．１６などの任意の無線通信方式に従って運用されてよい。
　なお、スモールセルは、マクロセルと重複して又は重複せずに配置される、マクロセルよりも小さい様々な種類のセル（例えば、フェムトセル、ナノセル、ピコセル及びマイクロセルなど）を含み得る概念である。ある例では、スモールセルは、専用の基地局によって運用される。別の例では、スモールセルは、マスタデバイスとなる端末がスモールセル基地局として一時的に動作することにより運用される。いわゆるリレーノードもまた、スモールセル基地局の一形態であると見なすことができる。リレーノードの親局として機能する無線通信装置は、ドナー基地局とも称される。ドナー基地局は、ＬＴＥにおけるＤｅＮＢ（Donor　eNodeB）を意味してもよく、より一般的にリレーノードの親局を意味してもよい。
　　（２）端末装置２００
　端末装置２００は、セルラーシステム（又は移動体通信システム）において通信可能である。端末装置２００は、セルラーシステムの無線通信装置（例えば、基地局１００Ａ、マスタデバイス１００Ｂ又は１００Ｃ）との無線通信を行う。例えば、端末装置２００Ａは、基地局１００Ａからのダウンリンク信号を受信し、基地局１００Ａへのアップリンク信号を送信する。
　ここでは、端末装置２００は、ユーザとも呼ばれる。当該ユーザは、ＵＥ（User　Equipment）とも呼ばれ得る。また、無線通信装置１００Ｃは、ＵＥ－Ｒｅｌａｙとも呼ばれる。ここでのＵＥは、ＬＴＥ又はＬＴＥ－Ａにおいて定義されているＵＥであってもよく、ＵＥ－Ｒｅｌａｙは、３ＧＰＰで議論されているＰｒｏｓｅ　ＵＥ　ｔｏ　Ｎｅｔｗｏｒｋ　Ｒｅｌａｙであってもよく、より一般的に通信機器を意味してもよい。
　　（３）アプリケーションサーバ６０
　アプリケーションサーバ６０は、ユーザへサービスを提供する装置である。アプリケーションサーバ６０は、パケットデータネットワーク（ＰＤＮ）５０に接続される。他方、基地局１００は、コアネットワーク４０に接続される。コアネットワーク４０は、ゲートウェイ装置を介してＰＤＮ５０に接続される。このため、無線通信装置１００は、アプリケーションサーバ６０により提供されるサービスを、パケットデータネットワーク５０、コアネットワーク４０及び無線通信路を介してＭＥＣサーバ３００、及びユーザへ提供する。
　　（４）ＭＥＣサーバ３００
　ＭＥＣサーバ３００は、ユーザへサービス（例えば、コンテンツ等）を提供する装置である。ＭＥＣサーバ３００は、無線通信装置１００に設けられ得る。その場合、無線通信装置１００は、ＭＥＣサーバ３００により提供されるサービスを、無線通信路を介してユーザへ提供する。ＭＥＣサーバ３００は、論理的な機能エンティティとして実現されてもよく、図１に示すように無線通信装置１００等と一体的に形成されてもよい。もちろん、ＭＥＣサーバ３００は、物理的なエンティティとして、独立した装置として形成されてもよい。ＭＥＣサーバ３００上で動作するアプリケーションを、ＭＥＣアプリケーションとも称する。
　例えば、基地局１００Ａは、ＭＥＣサーバ３００Ａにより提供されるサービスを、マクロセル１０に接続する端末装置２００Ａへ提供する。また、基地局１００Ａは、ＭＥＣサーバ３００Ａにより提供されるサービスを、マスタデバイス１００Ｂを介して、スモールセル１０Ｂに接続する端末装置２００Ｂへ提供する。
　また、マスタデバイス１００Ｂは、ＭＥＣサーバ３００Ｂにより提供されるサービスを、スモールセル１０Ｂに接続する端末装置２００Ｂへ提供する。同様に、マスタデバイス１００Ｃは、ＭＥＣサーバ３００Ｃにより提供されるサービスを、スモールセル１０Ｃに接続する端末装置２００Ｃへ提供する。
　　（５）補足
　以上、システム１の概略的な構成を示したが、本技術は図１に示した例に限定されない。例えば、システム１の構成として、マスタデバイスを含まない構成、ＳＣＥ（Small　Cell　Enhancement）、ＨｅｔＮｅｔ（Heterogeneous　Network）、ＭＴＣ（Machine　Type　Communication）ネットワーク等が採用され得る。
　　＜１．２．ＭＥＣ＞
　続いて、図２～図６を参照して、ＭＥＣについて説明する。
　　（１）ネットワーク構成
　図２は、ＭＥＣが未導入のＬＴＥネットワークの構成の一例を示す図である。図２に示すように、ＲＡＮ（Radio　Access　Network）は、ＵＥ及びｅＮｏｄｅＢを含む。ＵＥとｅＮｏｄｅＢとは、Ｕｕインタフェースにより接続されており、ｅＮｏｄｅＢ同士はＸ２インタフェースにより接続されている。また、ＥＰＣ（Evolved　Packet　Core）は、ＭＭＥ（Mobility　Management　Entity）、ＨＳＳ（Home　Subscriber　Server）、Ｓ－ＧＷ（Serving　Gateway）及びＰ－ＧＷ（PDN　Gateway）を含む。ＭＭＥとＨＳＳとは、Ｓ６ａインタフェースにより接続されており、ＭＭＥとＳ－ＧＷとは、Ｓ１１インタフェースにより接続されており、Ｓ－ＧＷとＰ－ＧＷとは、Ｓ５インタフェースにより接続されている。ｅＮｏｄｅＢとＭＭＥとは、Ｓ１－ＭＭＥインタフェースにより接続されており、ｅＮｏｄｅＢとＳ－ＧＷとは、Ｓ１－Ｕインタフェースにより接続されており、Ｐ－ＧＷとＰＤＮとは、ＳＧｉインタフェースにより接続されている。
　ＰＤＮは、例えばオリジナルサーバ、及びキャッシュサーバを含む。オリジナルサーバには、ＵＥへ提供されるオリジナルのアプリケーションが記憶されている。キャッシュサーバには、例えばアプリケーション又はキャッシュデータが記憶されている。ＵＥは、オリジナルサーバの代わりにキャッシュサーバへアクセスすることで、オリジナルサーバにおける処理負荷及びオリジナルサーバへのアクセスにかかる通信負荷を軽減することができる。ただし、キャッシュサーバがＲＡＮ及びＥＰＣの外側（即ち、ＰＤＮ）に配置されているので、ＵＥとキャッシュサーバとの間で生じる通信遅延（即ち、ＵＥからのリクエストに対する応答遅延）が依然として問題となっていた。
　ＵＥのリクエストには、例えばＨｔｔｐサーバに記憶されたコンテンツをダウンロードするといった静的なリクエストと、特定のアプリケーションに対する操作などの動的なリクエストとがある。いずれにしろ、キャッシュデータ及びアプリケーションが、ＵＥから近いエンティティに配置された方が、リクエストに対する応答が速くなることは自明である。ここで、典型的には、応答速度はエンティティ間の距離よりも経由するエンティティの数に依存する。なぜならば、経由する各々のエンティティにおける入力部、処理部及び出力部での処理遅延が、エンティティの数だけ累積するためである。なお、コンテンツとは、アプリケーション、画像（動画像又は静止画像）、音声、又はテキスト等の任意の形式のデータを意味するものとする。
　このような問題を解決するために、ＭＥＣが考案された。ＭＥＣでは、ＥＰＳ（Evolved　Packet　System）の内部に、ＵＥへのコンテンツを提供する又はＵＥからコンテンツを取得するアプリケーションサーバが設けられる。なお、ＥＰＳとは、ＥＰＣ及びｅＵＴＲＡＮ（即ち、ｅＮｏｄｅＢ）を含むネットワークである。ＥＰＳ内部に設けられるアプリケーションサーバは、エッジサーバ又はＭＥＣサーバとも称される場合がある。なお、アプリケーションサーバは、キャッシュサーバを含む概念である。
　図３及び図４は、ＭＥＣが導入されたＬＴＥネットワークの構成の一例を示す図である。図３では、コンテンツをキャッシュするＭＥＣサーバがｅＮｏｄｅＢに設けられている。この構成によれば、図２に示した例と比較して、ＵＥとＭＥＣサーバとの間に存在するエンティティの数が削減されるので、ＵＥは迅速にコンテンツを取得することができる。図４では、コンテンツを記憶するＭＥＣサーバが、ｅＮｏｄｅＢ及びＳ－ＧＷに設けられている。例えば、ＵＥは、ｅＮｏｄｅＢに配置されたＭＥＣサーバからコンテンツを取得しつつ、ｅＮｏｄｅＢに配置されたＭＥＣサーバに要求するキャッシュデータが存在しない場合に、Ｓ－ＧＷに配置されたＭＥＣサーバからコンテンツを取得する。いずれにしろ、オリジナルサーバへのアクセスを回避することができるので、ＵＥは迅速にコンテンツを取得することができる。
　　（２）各エンティティ
　以下では、図２～図４に登場するエンティティについて説明する。Ｓ－ＧＷは、ハンドオーバのアンカーポイントとなるエンティティである。Ｐ－ＧＷは、モバイルネットワークと外側（即ち、ＰＤＮ）との接続点であり、ＩＰアドレスをＵＥへ割り当て、モバイルネットワークの外側に対してアクセスすべきＩＰアドレスを提供する。Ｐ－ＧＷは、外部から到来するデータのフィルタリング等も行う。ＨＳＳは、加入者情報を記憶するデータベースである。ＭＭＥは、様々な制御信号を処理していて、ＨＳＳにアクセスして各ＵＥの認証（authentication）及び、権限付与（authorization）等の処理を行う。
　ＥＰＣネットワークは、制御プレーンとユーザプレーンとに分離されている。Ｓ－ＧＷ及びＰ－ＧＷは主にユーザプレーンに関係し、ＭＭＥ及びＨＳＳは主に制御プレーンに関係する。
　ここで、Ｓ－ＧＷは、ＭＥＣ導入前の構成でもハンドオーバのアンカーポイントなるために、ユーザデータを記憶する機能があった。一方で、ｅＮｏｄｅＢは、ＭＥＣ導入前の構成ではユーザデータを記憶する機能はなく、Ｕｕインタフェースで起きたパケットロスに対応したパケット再送等の機能があるだけで、コンテンツは記憶されていなかった。なお、Ｘ２インタフェースは、ハンドオーバ時のデータのやり取り、及び干渉の協調制御に用いられていた。
　　（３）ＭＥＣサーバにおけるアプリケーション
　キャッシュには、ＩＰレベルでキャッシュを行うストリームキャッシュと、アプリケーションレイヤレベルでキャッシュを行うコンテンツキャッシュとがある。ＭＥＣサーバは、いずれの種類のキャッシュにも対応することが想定される。現在ではコンテンツキャッシュが主として使用されていることから、ＭＥＣサーバは特にコンテンツキャッシュに対応することが想定される。
　ここで、ＭＥＣサーバにおいて、アプリケーションがアクティベートされて、動作可能な状態になっていることが重要である。第１に、キャッシュデータはＨＴＴＰヘッダにより認識されるため、ＭＥＣサーバにおいてＨＴＴＰを取扱い可能なアプリケーションが動作可能な状態になっていることが望ましいためである。第２に、ＭＥＣサーバが特定のアプリケーションを提供する場合、当該アプリケーションが配置され、且つ動作可能な状態にするためにアクティベートされていることが望ましいためである。
　ＭＥＣに対応するアプリケーションの種類は多岐にわたる。データをキャッシュするキャッシュアプリケーションに関しては、ＭＥＣサーバにおいてアクティベートされ動作可能な状態になっていたとしても、対象のデータがキャッシュされていない場合、ＵＥはオリジナルサーバまでデータを取りに行くこととなる。そのため、キャッシュアプリケーションにおいて、事前にデータをキャッシュしておくことが望ましい。
　　（４）キャッシュ対象のデータ
　ＭＥＣサーバ３００においてキャッシュされるデータには、ＤＬ（Downlink）方向でＵＥへ送信されるデータ（以下、ＤＬデータフローとも称する）と、ＵＬ（Uplink）方向でＵＥからアップロードされるデータ（以下、ＵＬデータフローとも称する）と、の２種類がある。
　ＤＬデータフローをキャッシュするユースケースとしては、例えばＵＥがＷｅｂアプリケーションにアクセスして何らかのｈｔｔｐデータを取得する際に、ＭＥＣサーバに同一のデータがキャッシュされている場合、そのキャッシュデータを取得するケースが挙げられる。
　ＵＬデータフローをキャッシュするユースケースの一例を、以下説明する。
　第１のユースケースは、ＵＥ自身が生成した写真等のデータをアップロードするケースである。詳しくは、ＵＥは、自身が生成した写真をアップロードして、ＭＥＣサーバはこの写真をキャッシュする。そして、ＭＥＣサーバは、例えばコアネットワーク内の伝送容量に余裕があるタイミングで、キャッシュした写真をＰＤＮ上の写真を格納するサーバへ転送してもよい。転送タイミングをずらすことで、コアネットワークの通信負荷が軽減される。また、ＭＥＣサーバは、例えばキャッシュした写真を他のＵＥへ転送してもよい。ＵＬデータフローのキャッシュの他のＵＥとの共有は、例えばスタジアムで観客が撮った写真をそのスタジアムにいる観客同士で共有するようなケースに有用である。
　第２のユースケースは、ＵＥが取得したデータをアップロードするケースである。例えば、ＵＥは、Ｄ２Ｄ（Device　to　Device）通信又はＷｉ－Ｆｉ（登録商標）により取得したデータをアップロードして、ＭＥＣサーバはこのデータをキャッシュする。本ユースケースの具体例としては、例えば店舗が商品の情報をＤ２Ｄ通信又はＷｉ－Ｆｉによりブロードキャストし、ＵＥがその情報を取得してＭＥＣサーバへアップロードする例が考えられる。その場合、その店舗の地域内（例えば、ＭＥＣサーバが設けられたｅＮｏｄｅＢのセルの範囲内）の他のＵＥは、キャッシュされた商品の情報を取得することができる。
　第３のユースケースは、異なるｅＮｏｄｅＢから受信したデータをアップロードするケースである。例えば、ＵＥは、ハンドオーバ前に接続していたｅＮｏｄｅＢから受信したデータを、ハンドオーバ後に接続したｅＮｏｄｅＢに設けられたＭＥＣサーバへアップロードする。
　第４のユースケースは、ＭＴＣ端末がデータをアップロードするケースである。そのようなデータとしては、例えば自動販売機の売り上げデータ、及びガスメーターにより検出されるガスの使用状況データ等が考えられる。ＭＴＣ端末は数が非常に多い場合があり、ＭＴＣ端末が一斉にデータをＰＤＮ上のサーバへアップロードしようとすると、コアネットワーク側で輻輳が生じるという問題がある。一方で、これらのデータはリアルタイム性が求められていないので、例えば１時間後にでも到達すれば十分である。即ち、ＭＴＣ端末からのデータに関するアプリケーションは、遅延に対する耐性があると言える。そのため、ＭＥＣサーバは、ＭＴＣ端末からアップロードされたデータをキャッシュしておき、例えばコアネットワーク内の伝送容量に余裕があるタイミングで、キャッシュしたデータをＰＤＮ上のサーバへ転送してもよい。特に、コアネットワークの伝送容量は、ユーザデータの容量よりも制御信号の容量の方が問題になる。セッションをつくるためには、何往復もシグナリングが必要になるからである。大量のＭＴＣ端末が一斉にデータをアップロードすると、コアネットワークのシグナリングが過度に増加することとなる。
　以上、ＵＬデータフローをキャッシュするユースケースの一例を説明した。本明細書では、このようなＵＬデータフローのキャッシュについて主に説明する。
　ＵＬデータフローのキャッシュデータは、上述したようにＤＬ方向（例えば、ＵＥ）へ転送される場合もあれば、ＵＬ方向（例えば、Ｐ－ＧＷ又はＰＤＮ上のサーバ）へ転送されることもある。前者のキャッシュデータをＤＬキャッシュデータとも称し、後者のキャッシュデータをＵＬキャッシュデータとも称する。
　図５は、ＤＬキャッシュデータのデータの流れの一例を示す図である。図５に示すように、ＭＥＣサーバは、ＵＥがアップロードしたデータをキャッシュし、ＵＥ（典型的には、アップロードしたＵＥとは異なるＵＥ）へキャッシュデータを送信する。
　図６は、ＵＬキャッシュデータのデータの流れの一例を示す図である。図６に示すように、ＭＥＣサーバは、ＵＥがアップロードしたデータをキャッシュし、ＰＤＮ上のオリジナルサーバへキャッシュデータを送信する。
　なお、データによっては、ＤＬキャッシュデータとしての取り扱いが許可されるものとされないものがあると考えられる。例えば、他のＵＥと共有可能なデータはＤＬキャッシュデータとしての取り扱いが許可され、個人的なデータはＤＬキャッシュデータとしての取り扱いが許可されないと考えられる。同様に、データによっては、ＵＬキャッシュデータとしての取り扱いが許可されるものとされないものがあると考えられる。例えば、ＭＴＣ端末からのデータ等の集計を要するデータはＵＬキャッシュデータとして許可され、地域限定等の局所的なデータはＵＬキャッシュデータとして許可されないと考えられる。
　このような事情から、ＭＥＣサーバにおいて、キャッシュデータをＤＬ方向へ（即ち、ＵＥへ）送信可能か否か、及びＵＬ方向へ（即ち、ＰＤＮへ）送信可能か否かが適切に管理されることが望ましい。
　　＜１．３．ベアラ＞
　続いて、図７～図１１を参照して、ＥＰＳにおいて用いられるベアラ、特にＥＰＳベアラについて説明する。ベアラとは、セッションのことであり、データ伝送を行うための言わば土管である。
　図７は、ベアラのアーキテクチャを説明するための説明図である。図７に示すように、オリジナルサーバからＵＥへ提供されるエンドツーエンドサービスは、ＥＰＳベアラ及び外部（External）ベアラを用いたデータ伝送により提供される。ＥＰＳベアラは、１種類のＱｏＳに対応して１つ確立される。ＵＥは、例えば２種類のＱｏＳを同時に使用したい場合、Ｐ－ＧＷとの間で２種類のＱｏＳに対応した２つのＥＰＳベアラを確立する。
　ＥＰＳベアラは、論理的なセッション（Virtual　Connection）であり、実際にはラジオベアラ、Ｓ１ベアラ、及びＳ５ベアラから成る。ラジオベアラは、ＵＥとｅＮｏｄｅＢとの間のＬＴＥ－Ｕｕインタフェース上に確立されるベアラである。Ｓ１ベアラは、ｅＮｏｄｅＢとＳ－ＧＷとの間のＳ１インタフェース上に確立されるベアラである。Ｓ５ベアラは、Ｓ－ＧＷとＰ－ＧＷとの間のＳ５インタフェース上に確立されるベアラである。
　図８は、ＥＰＳベアラのアーキテクチャを説明するための説明図である。図８に示すように、ＥＰＳベアラは、デフォルトベアラ及び専用（Dedicated）ベアラから成る。ＵＥは、ＭＭＥとの間で信号のやり取りを行ってベアラを確立する際、デフォルトとして決定されたＱｏＳに対応するデフォルトベアラを最初に確立する。その後、ＵＥは、必要なＱｏＳに対応するベアラを専用ベアラとして確立する。専用ベアラは、デフォルトベアラなしには確立することができない。
　各々のベアラには、ベアラを識別するためのＩＤが設定されている。このＩＤは、１つのＵＥが使用するベアラを識別するために使用される。従って、ＵＥのＩＤとベアラのＩＤとの両方を用いることで、各エンティティ（例えば、Ｐ－ＧＷ、Ｓ－ＧＷ及びｅＮｏｄｅＢ等）は、各々のベアラを識別することが可能である。このＩＤには、ＵＬ用とＤＬ用とがある。
　図９は、ベアラに設定されるＵＬ用ＩＤ及びＤＬ用ＩＤを説明するための説明図である。図９に示すように、ＥＰＳベアラの中では、ＵＬのセッションとＤＬのセッションとが別々のＩＤで区別して存在している。例えば、ラジオベアラに設定されるＩＤには、ＵＬ用の「ＵＬ　ＲＢ　ＩＤ」とＤＬ用の「ＤＬ　ＲＢ　ＩＤ」とがある。また、Ｓ１ベアラでは、ＴＥＩＤ（Tunneling　End　point　ID）で区別されるセッション（GTP　Tunneling　Protocolでやりとりされるセッション）があり、ＵＬ用のＩＤである「ＵＬ　Ｓ１　ＴＥＩＤ」又はＤＬ用のＩＤである「ＤＬ　Ｓ１　ＴＥＩＤ」が設定される。また、Ｓ５ベアラには、ＴＥＩＤで区別されるセッションがあり、ＵＬ用のＩＤである「ＵＬ　Ｓ５　ＴＥＩＤ」又はＤＬ用のＩＤである「ＤＬ　Ｓ５　ＴＥＩＤ」が設定される。
　下記の表に、各ＩＤがどのエンティティにより割り当てられるかを示した。ＩＤを割り当てたエンティティが、責任を持って該当のセッションを確立したことを意味している。
Figure JPOXMLDOC01-appb-T000001
　上記表を参照すると、ＴＥＩＤは、エンドポイント側のエンティティにより割り当てられる。一方で、ＲＢ　ＩＤに関しては、ＵＬもＤＬもｅＮｏｄｅＢにより割り当てられる。
　下記の表に、ＩＤを用いたデータの流れの一覧を示した。下記の表に示すように、ＵＬデータフローはＵＬ用ＩＤが割り当てられたセッションで伝送され、ＤＬデータフローはＤＬ用ＩＤが割り当てられたセッションで伝送される。なお、各セッションのＩＤは、１対１マッピングの関係を有しており、１つのＩＤが１つのＩＤにマッピングされる。即ち、１つのＩＤが複数のＩＤにマッピングされることはない。
Figure JPOXMLDOC01-appb-T000002
　続いて、図１０及び図１１を参照して、ベアラを確立するための手続きを説明する。
　図１０は、デフォルトベアラを確立するための手続きの流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ、ｅＮｏｄｅＢ、ＭＭＥ、Ｓ－ＧＷ、Ｐ－ＧＷ及びＰＣＲＦ（Policy　and　Charging　Rules　Function）が関与する。図１０に示すように、デフォルトベアラの確立は、ＵＥからのリクエストを起点として行われる。ｅＮｏｄｅＢ、ＭＭＥ、Ｓ－ＧＷ、Ｐ－ＧＷの順にリクエストが送信され、その逆方向に承認が送り返される。なお、ＰＣＲＦは、ＱｏＳに関する情報を提供するエンティティである。
　本シーケンスについて詳しく説明する。まず、ＵＥはアタッチリクエストをｅＮｏｄｅＢへ送信し（ステップＳ１１）、ｅＮｏｄｅＢは当該メッセージをＭＭＥへ送信する（ステップＳ１２）。次いで、ＭＭＥはデフォルトベアラ生成リクエストをＳ－ＧＷへ送信し（ステップＳ１３）、Ｓ－ＧＷは当該メッセージをＰ－ＧＷへ送信する（ステップＳ１４）。そして、Ｐ－ＧＷは、ＰＣＲＦとやり取りしてＩＰ－ＣＡＮ（IP　Connectivity　Access　Network）セッションを確立する（ステップＳ１５）。次に、Ｐ－ＧＷはデフォルトベアラ生成レスポンスをＳ－ＧＷへ送信し（ステップＳ１６）、Ｓ－ＧＷは当該メッセージをＭＭＥへ送信する（ステップＳ１７）。次いで、ＭＭＥは、アタッチアクセプトをｅＮｏｄｅＢへ送信し（ステップＳ１８）、ｅＮｏｄｅＢはＲＲＣ（Radio　Resource　Control）接続再設定をＵＥへ送信する（ステップＳ１９）。次に、ＵＥは、ＲＲＣ接続再設定完了をｅＮｏｄｅＢへ送信し（ステップＳ２０）、ｅＮｏｄｅＢはアタッチ完了をＭＭＥへ送信する（ステップＳ２１）。次いで、ＭＭＥはベアラアップデートリクエストをＳ－ＧＷへ送信し（ステップＳ２２）、Ｓ－ＧＷはベアラアップデートレスポンスをＭＭＥへ送信する（ステップＳ２３）。
　図１１は、専用ベアラを確立するための手続きの流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ、ｅＮｏｄｅＢ、ＭＭＥ、Ｓ－ＧＷ、Ｐ－ＧＷ及びＰＣＲＦが関与する。図１１に示すように、専用ベアラの確立は、デフォルトベアラとは逆に、ＰＣＲＦからのリクエストを起点として行われる。なお、ＵＥが専用ベアラを作りたい場合、ＵＥがその旨をアプリケーションレイヤに送信し、アプリケーションレイヤがＰＣＲＦに必要なＱｏＳを伝えることで、ＵＥを起点とする専用ベアラの確立が実現する。
　本シーケンスについて詳しく説明する。まず、ＰＣＲＦは、ＩＰ－ＣＡＮセッション変更開始をＰ－ＧＷへ送信する（ステップＳ３１）。次いで、Ｐ－ＧＷは専用ベアラ生成リクエストをＳ－ＧＷへ送信し（ステップＳ３２）、Ｓ－ＧＷは当該メッセージをＭＭＥへ送信する（ステップＳ３３）。次に、ＭＭＥは専用ベアラセットアップリクエストをｅＮｏｄｅＢへ送信し（ステップＳ３４）、ｅＮｏｄｅＢはＲＲＣ接続再設定をＵＥへ送信する（ステップＳ３５）。次いで、ＵＥは、ＲＲＣ接続再設定完了をｅＮｏｄｅＢへ送信し（ステップＳ３６）、ｅＮｏｄｅＢは専用ベアラセットアップレスポンスをＭＭＥへ送信する（ステップＳ３７）。次に、ＭＭＥは専用ベアラ生成レスポンスをＳ－ＧＷへ送信し（ステップＳ３８）、Ｓ－ＧＷは当該メッセージをＰ－ＧＷへ送信する（ステップＳ３９）。次いで、Ｐ－ＧＷは、ＩＰ－ＣＡＮセッション変更終了をＰＣＲＦへ送信する（ステップＳ４０）。
　　＜１．４．セキュリティ＞
　ＬＴＥにおけるセキュリティ技術の一例として、認証（Authentication）及び認可（Authorization）が挙げられる。認証とは、通信相手が適切な相手であるか否かを判断することである。ここで、適切な相手とは、例えばオペレータのＬＴＥネットワークにアクセスすることが適切な相手を指す。認可とは、通信相手がサービスを利用するための権利を有しているか否かを判断することである。ここで、権利とは、例えばオペレータのＬＴＥネットワークにアクセスする権利を指す。以下、図１２を参照して、認証手続きについて説明する。なお、認証手続きは、アタッチ手続きの一部である。
　図１２は、ＬＴＥネットワークにおいて実行される認証手続きの流れの一例を示すシーケンス図である。図１２に示すように、ＵＥは、ＩＭＳＩ（International　Mobile　Subscriber　Identity）及び鍵Ｋを記憶している。また、ＨＳＳは、各々のＵＥのＩＭＳＩ及びＩＭＳＩに対応する鍵Ｋを記憶している。なお、ＵＥは、ｅＮｏｄｅＢを経由してＭＭＥと通信する。ＵＥ及びＨＳＳは、以下に説明するように、互いに記憶している同一のＩＭＳＩ及び鍵Ｋを用いて相互認証を行う。
　まず、ＵＥは、ＩＭＳＩと共にアタッチリクエストをＭＭＥへ送信する（ステップＳ５１）。次いで、ＭＭＥは、受信したＩＭＳＩと共に認証リクエストをＨＳＳへ送信する（ステップＳ５２）。次に、ＨＳＳは、乱数ＲＡＮＤを発生させて、乱数ＲＡＮＤ、受信したＩＭＳＩ、及び当該ＩＭＳＩに対応付けて記憶している鍵Ｋを認証機能（Authentication　Function）に入力し、期待される応答ＲＥＳＥＸＰＥＣＴＥＤ及び鍵ＫＡＳＭＥを得る（ステップＳ５３）。次いで、ＨＳＳは、認証レスポンスとして、鍵ＫＡＳＭＥ、期待される応答ＲＥＳＥＸＰＥＣＴＥＤ及び乱数ＲＡＮＤをＭＭＥへ送信する（ステップＳ５４）。次に、ＭＭＥは、乱数ＲＡＮＤをＵＥへ送信する（ステップＳ５５）。次いで、ＵＥは、受信した乱数ＲＡＮＤ、記憶しているＩＭＳＩ及び鍵Ｋを認証機能に入力し、応答ＲＥＳ及び鍵ＫＡＳＭＥを得る（ステップＳ５６）。次に、ＵＥは、応答ＲＥＳをＭＭＥへ送信する（ステップＳ５７）。そして、ＭＭＥは、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとを比較してＵＥを認証する（ステップＳ５８）。詳しくは、ＭＭＥは、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとが一致した場合にはＵＥに信頼性があると判断する（即ち、認証が成功する）。一方で、ＭＭＥは、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとが一致しない場合にはＵＥに信頼性がないと判断する（即ち、認証が失敗する）。
　上記認証手続き後、実際の通信の際に使用される鍵が、ＫＡＳＭＥに基づいて生成される。生成される鍵には、ＣＫ（Cipher　Key）とＩＫ（Integrity　Key）の２種類がある。ＣＫは、通信を暗号化するための鍵であり、他者に通信内容が知られることを防止するために用いられる。ＩＫは、データの完全性を確認するための鍵であり、通信路上でデータが変更されていないかを確認するために用いられる。ＥＰＳにおいては、ＡＡ（Authentication/Authorization）手続き、ＣＫを用いた暗号化、及びＩＫを用いた完全性（Integrity）の確認により、セキュリティが確保される。なお、これらの各処理は、ＵＥ毎に別々に行われる。
　図１２を参照して上記説明したように、認証手続きにより、共通する鍵ＫＡＳＭＥがＵＥ側とネットワーク側との両方で生成される。ＵＥ側及びネットワーク側（ＨＳＳ、ＭＭＥ又はｅＮｏｄｅＢ）は、この共通する鍵ＫＡＳＭＥに基づいて、実際の通信の際に使用される鍵を、用途ごとに生成する。以下、図１３を参照して、実際の通信の際に使用される鍵の用途の例を説明する。
　図１３は、実際の通信の際に使用される鍵の用途の例を説明するための説明図である。図１３に示すように、ＵＥとｅＮｏｄｅＢとの間で、ユーザプレーンのためのＣＫが用いられる。また、ＵＥとｅＮｏｄｅＢとの間で、ＲＲＣ（Radio　Resource　Control）シグナリングのためのＩＫ及びＣＫが用いられる。また、ＵＥとＭＭＥとの間で、ＮＡＳ（Non-access　stratum）シグナリングのためのＩＫ及びＣＫが用いられる。このように、用途ごとに異なる鍵が用いられる。そして、これらの鍵は、ＡＡ手続きにおいて生成されたＫＡＳＭＥに基づいて生成される。以下、図１４を参照して、これらの用途ごとに生成される鍵同士の関係を説明する。
　図１４は、鍵の系統図である。図中のｅｎｃは暗号（encrypt）を意味し、ｉｎｔは完全性（integrity）を意味し、ＲＲＣはＲＲＣシグナリングを意味し、ＮＡＳはＮＡＳシグナリングを意味し、ＵＰは、ユーザプレーンを意味する。図１４に示した鍵の系統図は、ＵＥ側とネットワーク側とで共通である。ネットワーク側の鍵に関しては、ＮＡＳ用の鍵は、ＭＭＥにより生成される。ＮＡＳ用以外の、ＲＲＣシグナリング及びユーザプレーン用の鍵は、ｅＮｏｄｅＢにより生成される。ＵＥ側の鍵に関しては、全てＵＥにより生成される。
　時系列に沿って、図１４に示した鍵の生成について説明する。まず、ＨＳＳ及びＵＥは、相互認証（Mutual　authentication）により、ＫＡＳＭＥを各々生成する。次いで、ＭＭＥ及びＵＥは、ＫＡＳＭＥに基づいて、ＮＡＳシグナリング用の鍵（即ち、ＫＮＡＳｅｎｃ、及びＫＮＡＳｉｎｔ）、及びｅＮｏｄｅＢ用のベース鍵（即ち、ＫｅＮｏｄｅＢ）を生成する。そして、ｅＮｏｄｅＢ及びＵＥは、ｅＮｏｄｅＢ用のベース鍵に基づいて、ＲＲＣシグナリング用の鍵（即ち、ＫＲＲＣｅｎｃ、及びＫＲＲＣｉｎｔ）、及びユーザプレーン用の鍵（即ち、ＫＵＰｅｎｃ）を生成する。
　＜＜２．各装置の構成例＞＞
　　＜２．１．端末装置の構成＞
　続いて、図１５を参照して、本開示の実施形態に係る端末装置２００の構成の一例を説明する。図１５は、本開示の一実施形態に係る端末装置２００の構成の一例を示すブロック図である。図１５を参照すると、端末装置２００は、アンテナ部２１０、無線通信部２２０、記憶部２３０及び処理部２４０を備える。
　（１）アンテナ部２１０
　アンテナ部２１０は、無線通信部２２０により出力される信号を電波として空間に放射する。また、アンテナ部２１０は、空間の電波を信号に変換し、当該信号を無線通信部２２０へ出力する。
　（２）無線通信部２２０
　無線通信部２２０は、信号を送受信する。例えば、無線通信部２２０は、基地局からのダウンリンク信号を受信し、基地局へのアップリンク信号を送信する。
　（３）記憶部２３０
　記憶部２３０は、端末装置２００の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
　（４）処理部２４０
　処理部２４０は、端末装置２００の様々な機能を提供する。処理部２４０は、認証処理部２４１及び通信処理部２４３を含む。なお、処理部２４０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部２４０は、これらの構成要素の動作以外の動作も行い得る。
　認証処理部２４１及び通信処理部２４３の動作は、後に詳細に説明する。
　　＜２．２．ＭＥＣサーバの構成例＞
　続いて、図１６を参照して、本開示の一実施形態に係るＭＥＣサーバ３００の構成の一例を説明する。図１６は、本開示の一実施形態に係るＭＥＣサーバ３００の構成の一例を示すブロック図である。図１６を参照すると、ＭＥＣサーバ３００は、通信部３１０、記憶部３２０、及び処理部３３０を備える。
　　（１）通信部３１０
　通信部３１０は、他の装置との間で通信を行うためのインタフェースである。例えば、通信部３１０は、対応付けられた装置との間で通信を行う。例えば、ＭＥＣサーバ３００が、論理エンティティとして形成され、基地局１００に含まれる場合、通信部３１０は、例えば基地局１００の制御部との間で通信を行う。ＭＥＣサーバ３００は、一体的に形成される装置以外の装置との間で、直接的に通信を行うためのインタフェースを有していてもよい。
　　（２）記憶部３２０
　記憶部３２０は、ＭＥＣサーバ３００の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。例えば、記憶部３２０は、ユーザへ提供される多様なコンテンツ、及びアプリケーションを記憶し得る。
　　（３）処理部３３０
　処理部３３０は、ＭＥＣサーバ３００の様々な機能を提供する。処理部３３０は、認証処理部３３１及び通信処理部３３３を含む。なお、処理部３３０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部３３０は、これらの構成要素の動作以外の動作も行い得る。
　認証処理部３３１及び通信処理部３３３の動作は、後に詳細に説明する。なお、図１６では省略しているが、処理部３３０は、ＵＥ２００へのコンテンツを提供する又はＵＥ２００からコンテンツを取得するコンテンツ処理部を含んでいてもよい。
　　＜２．３．ＥＰＣ機能エンティティの構成例＞
　続いて、図１７を参照して、本開示の一実施形態に係るＥＰＣ機能エンティティの構成の一例を説明する。ここで説明するＥＰＣ機能エンティティは、例えばＭＭＥ４１又はＨＳＳ４２であり、これらは同様の構成をとるものとする。もちろん、各構成要素の動作は、ＭＭＥ４１とＨＳＳ４２とで異なる。図１７は、本開示の一実施形態に係るＥＰＣ機能エンティティ４１、４２の構成の一例を示すブロック図である。図１６を参照すると、ＥＰＣ機能エンティティ４１、４２は、通信部４１０、記憶部４２０、及び処理部４３０を備える。
　　（１）通信部４１０
　通信部４１０は、他の装置との間で通信を行うためのインタフェースである。例えば、通信部４１０は、他のＥＰＣ機能エンティティとの間で通信を行う。
　　（２）記憶部４２０
　記憶部４２０は、ＭＭＥ４１又はＨＳＳ４２の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
　　（３）処理部４３０
　処理部４３０は、ＭＭＥ４１又はＨＳＳ４２の様々な機能を提供する。処理部４３０の動作は、後に詳細に説明する。
　以上、各装置の構成例を説明した。以下では、説明の便宜上、基地局１００をｅＮｏｄｅＢ１００とも称し、端末装置２００をＵＥ２００とも称する。
　＜＜３．第１の実施形態＞＞
　本実施形態は、ＭＥＣサーバ３００に記憶された認証情報を用いた認証が行われる形態である。
　　＜３．１．技術的課題＞
　ＥＰＳの各エンティティ（Ｐ－ＧＷ、Ｓ－ＧＷ、ＰＣＲＦ、ＨＳＳ、及びｅＮｏｄｅＢ等）は、それぞれが信頼性のあるエンティティとして取り扱われており、それらのエンティティ間での相互認証は規格化されていない。一方で、ＵＥは、不特定多数のユーザが持つデバイスであることから、ＭＭＥとの間での相互認証の手続きが規格化されている。
　しかし、ＭＥＣサーバに関しては、相互認証の手続きは規格化されていない。ＭＥＣサーバは、ｅＮｏｄｅＢの近くに配置されることが想定されるものの、信頼性のあるエンティティとして取り扱うべきものではない。ＭＥＣサーバは、様々なサービスプロバイダーにより提供される可能性があるためである。そのため、ＭＥＣサーバごとに信頼性が確認されることが望ましい。
　そこで、本実施形態では、ＭＥＣサーバを認証するための手続きを提供する。
　　＜３．２．技術的特徴＞
　　（１）認証手続き
　ＭＥＣサーバ３００は、ＨＳＳ４２に登録された、ＭＥＣサーバ３００に対応する認証情報を用いて認証されたネットワークとの通信を行う。
　ＨＳＳ４２（例えば、記憶部４２０）は、ＭＥＣサーバ３００に対応する認証情報を記憶する。本実施形態では、ＭＥＣサーバ３００に対応する認証情報は、ＭＥＣサーバ３００の認証情報である。具体的には、ＭＥＣサーバ３００の認証情報は、ＭＥＣサーバ３００を特定する番号（即ち、ＩＭＳＩ）及びＭＥＣサーバ３００に固有の鍵情報（即ち、鍵Ｋ）を含む。ＨＳＳ４２は、ＭＥＣサーバ３００ごとにＩＭＳＩを記憶し、ＭＥＣサーバ３００のＩＭＳＩに対応する鍵Ｋも記憶する。なお、ひとつのＭＥＣサーバ３００にひとつのＩＭＳＩが登録される。ただし、複数のＭＥＣサーバ３００にひとつの共通するＩＭＳＩが割り当てられてもよい。そして、ＭＭＥ４１（例えば、処理部４３０）及びＨＳＳ４２（例えば、処理部４３０）は、ＭＥＣサーバ３００の認証のための各種処理を行う。
　ＭＥＣサーバ３００（例えば、記憶部３２０）は、ＭＥＣサーバ３００の認証情報を記憶する。そして、ＭＥＣサーバ３００（例えば、認証処理部３３１）は、ＭＥＣサーバ３００の認証情報を用いてネットワークへの認証を行う。即ち、本実施形態に係るＭＥＣサーバ３００は、図１２を参照して上記説明したような、ＵＥとＨＳＳとが同一の認証情報を記憶していることを用いてＵＥの認証を行う仕組みと、同様の仕組みで認証を行う。そして、ＭＥＣサーバ３００（例えば、通信処理部３３３）は、認証されたネットワークとの通信を行う。具体的には、ＭＥＣサーバ３００は、認証されたネットワーク（例えば、当該ネットワーク内のｅＮｏｄｅＢ１００）を経由してＵＥ２００へコンテンツを提供する、又はＵＥ２００からコンテンツを取得する。このようにして、ＭＥＣサーバ３００は、信頼性のあるエンティティとして認証され、ネットワークに接続することが可能となる。
　ＭＥＣサーバ３００は、例えばＵＳＩＭ（Universal　Subscriber　Identification　Module）等のハードウェアに認証情報を格納してもよい。その場合、記憶部３２０はＵＳＩＭ等のハードウェアとして実現される。他にも、認証情報は、ＵＳＩＭと同等の機能を有するソフトウェアにより実現されてもよい。その場合、記憶部３２０は、当該ソフトウェアを記憶する。認証情報は、例えばＭＥＣアプリケーションの事業者により登録される。
　ここで、ＭＥＣサーバ３００は、複数のオペレータ（ＭＮＯ：Mobile　Network　Operator）のネットワークを切り替えながら使用してもよい。その場合、認証情報は例えばｅＳＩＭ（Embedded　Subscriber　Identity　Module）に記憶されてＭＥＣサーバ３００に搭載されてもよい。これにより、認証情報をリモートで書き替えることが可能となり、ＭＥＣサーバ３００は、複数のオペレータのネットワークを切り替えながら動作することができる。その場合、認証情報を書き替えるエンティティは、ＭＥＣサーバ３００との間で暗号化処理により秘匿化された通信経路を確立した上で、認証情報を変更する。
　ＭＥＣサーバ３００の認証手続きは、認証する主体がＵＥからＭＥＣサーバ３００に変更される以外、図１２を参照して上記説明したものと同様である。以下、図１８を参照して、本実施形態に係る認証手続きについて説明する。
　図１８は、本実施形態に係るシステム１において実行される認証手続きの流れの一例を示すシーケンス図である。図１８に示すように、ＭＥＣサーバ３００は、ＩＭＳＩ及び鍵Ｋを記憶している。また、ＨＳＳ４２は、各々のＭＥＣサーバ３００のＩＭＳＩ及びＩＭＳＩに対応する鍵Ｋを記憶している。なお、ＭＥＣサーバ３００は、ｅＮｏｄｅＢ１００を経由してＭＭＥ４１と通信する。
　まず、ＭＥＣサーバ３００は、ＩＭＳＩと共にアタッチリクエストをＭＭＥ４１へ送信する（ステップＳ１０２）。次いで、ＭＭＥ４１は、受信したＩＭＳＩと共に認証リクエストをＨＳＳ４２へ送信する（ステップＳ１０４）。次に、ＨＳＳ４２は、乱数ＲＡＮＤを発生させて、乱数ＲＡＮＤ、受信したＩＭＳＩ、及び当該ＩＭＳＩに対応付けて記憶している鍵Ｋを認証機能に入力し、期待される応答ＲＥＳＥＸＰＥＣＴＥＤ及び鍵ＫＡＳＭＥを得る（ステップＳ１０６）。次いで、ＨＳＳ４２は、認証レスポンスとして、鍵ＫＡＳＭＥ、期待される応答ＲＥＳＥＸＰＥＣＴＥＤ及び乱数ＲＡＮＤをＭＭＥ４１送信する（ステップＳ１０８）。次に、ＭＭＥ４１は、乱数ＲＡＮＤをＭＥＣサーバ３００へ送信する（ステップＳ１１０）。次いで、ＭＥＣサーバ３００は、受信した乱数ＲＡＮＤ、記憶しているＩＭＳＩ及び鍵Ｋを認証機能に入力し、応答ＲＥＳ及び鍵ＫＡＳＭＥを得る（ステップＳ１１２）。次に、ＭＥＣサーバ３００は、応答ＲＥＳをＭＭＥ４１へ送信する（ステップＳ１１４）。そして、ＭＭＥ４１は、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとを比較してＭＥＣサーバ３００を認証する（ステップＳ１１６）。詳しくは、ＭＭＥ４１は、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとが一致した場合にはＭＥＣサーバ３００に信頼性があると判断する（即ち、認証が成功する）。一方で、ＭＭＥ４１は、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとが一致しない場合にはＭＥＣサーバ３００に信頼性がないと判断する（即ち、認証が失敗する）。
　　（２）ネットワークのバリエーション
　上述したように、ＭＥＣサーバ３００は、ＥＰＳの内部に設けられるアプリケーションサーバであってもよい。
　その他、ＭＥＣサーバ３００は、ＬＡＮ（Local　Area　Network）ネットワーク内に設けられるアプリケーションサーバであってもよい。この場合、ＭＥＣサーバ３００は、例えば無線ＬＡＮのアクセスポイントに設けられる。そして、ＭＥＣサーバ３００は、自身の認証情報を用いて、ｅＰＤＧ（enhanced　Packet　Data　Gateway）経由でＡＡ手続きを行う。なお、ｅＰＤＧは、ＥＰＣのエンティティのひとつであり、Ｐ－ＧＷに接続される。典型的には、ｅＰＤＧは無線ＬＡＮ端末の認証を行う。
　＜＜４．第２の実施形態＞＞
　本実施形態は、ＭＥＣサーバ３００の認証をＵＥ２００が代理で行う形態である。
　　＜４．１．技術的課題＞
　上記第１の実施形態では、ＭＥＣサーバ３００は自身の認証情報を記憶する。典型的には、ＭＥＣアプリケーションの事業者は、ＭＥＣサーバ３００にこの認証情報を設定する。しかし、ＭＥＣサーバ３００に記憶された認証情報を変更することは簡単ではないし、新たに追加されたＭＥＣサーバ３００に認証情報を即時設定することは困難であった。なぜならば、通信を介して認証情報を設定することは、認証情報（特に、鍵Ｋ）の秘匿性の観点から望ましくないためである。ＭＥＣサーバ３００が遠隔地から通信を介してアクティベート（例えば、起動）される場合にも、より安全にＭＥＣサーバ３００が認証されることが望ましい。
　そこで、本実施形態では、より安全にＭＥＣサーバ３００の認証を行うための技術を提供する。
　　＜４．２．技術的特徴＞
　本実施形態では、ＵＥ２００（例えば、認証処理部２４１）が、ＭＥＣサーバ３００の代理で認証を行う。
　ＨＳＳ４２（例えば、記憶部４２０）は、ＭＥＣサーバ３００に対応する認証情報を記憶する。本実施形態では、ＭＥＣサーバ３００に対応する認証情報は、ＭＥＣサーバ３００に対応付けられたＵＥ２００の認証情報である。具体的には、ＵＥ２００の認証情報は、ＵＥ２００を特定する番号（即ち、ＩＭＳＩ）及びＵＥ２００に固有の鍵情報（即ち、鍵Ｋ）を含む。ＨＳＳ４２は、ＵＥ２００に対応付けて、ＭＥＣサーバ３００の識別情報を記憶する。この識別情報を、以下ではＭＥＣサーバＩＤとも称する。例えば、ＨＳＳ４２は、ＵＥ２００の加入者情報として、ＵＥ２００と対応付けられたＭＥＣサーバ３００のＭＥＣサーバＩＤを記憶する。なお、このＭＥＣサーバＩＤは、テンポラリＩＤではなく、ＭＥＣサーバ３００に固有の識別情報である。
　ＵＥ２００（例えば、認証処理部２４１）は、自身の認証手続きが完了した後、自身に対応付けられたＭＥＣサーバ３００の認証手続きを、当該ＭＥＣサーバ３００に代わって行う。詳しくは、まず、ＵＥ２００は、自身のＩＭＳＩ及び鍵Ｋを用いて自身の認証手続きを行う。次いで、ＵＥ２００は、ＭＥＣサーバ３００のアタッチリクエストをＭＭＥ４１又はｅＮｏｄｅＢ１００へ送信する。ＭＭＥ４１へ送信する場合はＮＡＳシグナリングが用いられる。ｅＮｏｄｅＢ１００へ送信する場合はＲＲＣシグナリングが用いられる。ＭＥＣサーバ３００のアタッチリクエストには、ＭＥＣサーバＩＤが含まれる。ＭＥＣサーバ３００のアタッチリクエストは、対象のＭＥＣサーバ３００の活性化をリクエストするメッセージであるとも捉えられてもよい。
　ＨＳＳ４２（例えば、処理部４３０）は、ＭＥＣサーバＩＤを含むアタッチリクエストを受信した場合、アタッチリクエストの送信元のＵＥ２００に対応する加入者情報に、当該ＭＥＣサーバＩＤが登録されているか否かを確認する。そして、ＨＳＳ４２は、確認結果を含むアタッチレスポンスを返信する。登録されている場合、ＨＳＳ４２は、テンポラリＩＤを含むアタッチレスポンスを返信する。このテンポラリＩＤは、認証に成功したＭＥＣサーバ３００に付与されるＩＤである。以下では、このテンポラリＩＤを、ＭＥＣサーバテンポラリＩＤとも称する。一方で、登録されていない場合、ＨＳＳ４２は、ＭＥＣサーバテンポラリＩＤを含まないアタッチレスポンスを返信する。この場合、ＭＥＣサーバ３００はネットワークに接続することができない。
　ＭＥＣサーバ３００（例えば、通信処理部３３３）は、ネットワークへの認証に成功した、当該ＭＥＣサーバ３００に対応付けられたＵＥ２００によるリクエスト（即ち、アタッチリクエスト）に基づいて発行された情報（即ち、ＭＥＣサーバテンポラリＩＤ）を用いて、ネットワークとの通信を行う。システム１は、この発行された情報に基づいてＭＥＣサーバ３００が認証済みであるか否かを識別することが可能となるので、セキュリティが確保される。また、本実施形態では、ＭＥＣサーバ３００に認証情報を設定せずとも認証を行うことが可能となり、より高い安全性が確保される。
　ｅＮｏｄｅＢ１００及びＭＭＥ４１は、アタッチレスポンスをＵＥ２００へ転送する過程でＭＥＣサーバテンポラリＩＤを取得して記憶し、ＭＥＣサーバテンポラリＩＤを有するＭＥＣサーバ３００によるアクセスを許可する。これにより、ＭＥＣサーバ３００はＭＥＣサーバテンポラリＩＤが有効な間はネットワークに接続することが可能となる。
　なお、上記では、ＭＥＣサーバ３００単位でのアタッチリクエストについて説明したが、同様の認証手続きが、ＭＥＣサーバ３００上で動作するＭＥＣアプリケーション単位で行われてもよい。例えば、新たなＭＥＣアプリケーションが起動される度に、当該ＭＥＣアプリケーションのアタッチ手続きが行われてもよい。この場合、ＭＥＣサーバテンポラリＩＤを含むアタッチレスポンスは、ＭＥＣアプリケーションの起動許可である、とも捉えられてもよい。ＭＥＣサーバＩＤを含むアタッチリクエストは、ＭＥＣアプリケーションの起動要求である、とも捉えられてもよい。また、ＭＥＣサーバＩＤ及びＭＥＣサーバテンポラリＩＤは、ＭＥＣアプリケーション単位で設定されてもよい。
　以下、図１９を参照して、ＵＥ２００がＭＥＣサーバ３００の代理で認証を行う場合の認証手続きの流れの一例を説明する。
　図１９は、本実施形態に係るシステム１において実行される認証手続きの流れの一例を示すシーケンス図である。なお、ＵＥ２００は、ｅＮｏｄｅＢ１００を経由してＭＭＥ４１と通信する。
　図１９に示すように、まず、ＵＥ２００は、アタッチ手続きを行う（ステップＳ２０２）。このアタッチ手続きにおいて、図１２を参照して上記説明した認証手続きが行われ、ＵＥ２００が認証される。次いで、ＵＥ２００は、ＭＥＣサーバ３００のアタッチリクエストをＭＭＥ４１へ送信する（ステップＳ２０４）。このアタッチリクエストは、認証対象のＭＥＣサーバ３００のＭＥＣサーバＩＤを含む。次に、ＭＭＥ４１は、受信したＭＥＣサーバ３００のアタッチリクエストを、ＨＳＳ４２へ転送する（ステップＳ２０６）。次いで、ＨＳＳ４２は、ＭＥＣサーバ３００のアタッチレスポンスをＭＭＥ４１へ返信する（ステップＳ２０８）。このとき、ＨＳＳ４２は、アタッチリクエストの送信元のＵＥ２００の加入者情報に、当該ＭＥＣサーバ３００のＭＥＣサーバＩＤが登録されているか否かを確認する。以下では、登録されていた場合について説明する。即ち、アタッチレスポンスに、ＭＥＣサーバテンポラリＩＤが含まれる。次に、ＭＭＥ４１は受信したＭＥＣサーバ３００のアタッチレスポンスをｅＮｏｄｅＢ１００へ転送し（ステップＳ２１０）、ｅＮｏｄｅＢ１００は受信したＭＥＣサーバ３００のアタッチレスポンスをＭＥＣサーバ３００へ転送する（ステップＳ２１２）。そして、ＭＥＣサーバ３００は、アタッチレスポンスに含まれるＭＥＣサーバテンポラリＩＤを用いて、ネットワークにアタッチする（ステップＳ２１４）。
　＜＜５．第３の実施形態＞＞
　本実施形態は、ＭＥＣサーバ３００による通信に用いられる鍵を提供する形態である。
　　＜５．１．技術的課題＞
　ＭＥＣサーバ３００は、上記第１の実施形態又は第２の実施形態に係る認証手続きに成功すると、ネットワークに接続して通信することができる。そのためＵＥの場合と同様に、認証手続き後、実際の通信の際に使用される鍵（例えば、ＣＫ及びＩＫ）が生成されることが望ましい。例えば、ＭＥＣアプリケーションとＭＭＥ４１との通信、及びＭＥＣアプリケーションとＵＥ２００との通信において用いられる、ＩＫ及びＣＫが生成されることが望ましい。
　しかしなら、ＭＥＣサーバ３００による通信に使用される鍵を生成し、配布する技術は提供されていなかった。
　　＜５．２．技術的特徴＞
　　（１）ＭＥＣアプリケーションとＭＭＥ４１との通信のための鍵
　ＭＥＣアプリケーションとＭＭＥ４１との通信のための鍵（即ち、ＣＫ及びＩＫ）は、ＭＥＣアプリケーションごとに異なるものが用いられる。
　上記第１の実施形態の場合、ＭＥＣアプリケーションとＭＭＥ４１との通信のための鍵は、ＭＥＣサーバ３００の認証情報（即ち、ＭＥＣサーバ３００のＩＭＳＩ及び鍵Ｋ）に基づいて生成される。詳しくは、まず、ＭＥＣサーバ３００のアタッチ手続きにおいて、ＭＥＣサーバ３００の認証情報を用いて鍵ＫＡＳＭＥが生成される。そして、この鍵ＫＡＳＭＥに基づいて、ＭＥＣアプリケーションとＭＭＥ４１との通信のための鍵（即ち、ＣＫ及びＩＫ）が生成される。このＣＫ及びＩＫを、鍵ＫＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎ－ＭＭＥとも総称する。つまり、鍵ＫＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎ－ＭＭＥは、ＣＫ及びＩＫを含む。
　上記第２の実施形態の場合、ＭＥＣアプリケーションとＭＭＥ４１との通信のための鍵は、ＭＥＣサーバ３００に対応付けられたＵＥ２００の認証情報（即ち、ＵＥ２００のＩＭＳＩ及び鍵Ｋ）に基づいて生成される。詳しくは、まず、ＵＥ２００のアタッチ手続きにおいて、ＵＥ２００の認証情報を用いて鍵ＫＡＳＭＥが生成される。そして、ＵＥ２００の認証情報を用いて生成された鍵ＫＡＳＭＥに基づいて、ＭＥＣアプリケーションとＭＭＥ４１との通信のための鍵ＫＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎ－ＭＭＥが生成される。ここで、ＭＭＥ４１は、ＵＥ２００のアタッチ手続きにおいて鍵ＫＡＳＭＥをＨＳＳ４２から通知される（図１２に示したステップＳ５４）。しかし、ＵＥ２００のアタッチ手続きとＭＥＣサーバ３００のアタッチ手続きとは別箇の手続きであるため、ＵＥ２００のアタッチ手続きにおいて鍵ＫＡＳＭＥが生成されたタイミングで鍵ＫＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎ－ＭＭＥが生成されることは望ましくない。そこで、ＭＭＥ４１（例えば、記憶部４２０）は、この鍵ＫＡＳＭＥを記憶しておく。そして、ＭＭＥ４１（例えば、処理部４３０）は、ＭＥＣサーバ３００の認証が成功した場合、記憶していた鍵ＫＡＳＭＥに基づいて鍵ＫＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎ－ＭＭＥを生成して、生成した鍵ＫＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎ－ＭＭＥをＭＥＣサーバ３００へ通知する。
　鍵ＫＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎ－ＭＭＥに関する鍵の系統図を、図２０に示した。図２０に示すように、ＭＥＣサーバ３００のアタッチ手続きを行ったＵＥ２００のＫＡＳＭＥに基づいて、鍵ＫＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎ－ＭＭＥが生成される。
　　（２）ＭＥＣアプリケーションとＵＥ２００との通信のための鍵
　ＭＥＣアプリケーションとＵＥ２００との通信のための鍵（即ち、ＣＫ及びＩＫ）は、ＵＥ２００ごとに異なるものが用いられる。ひとつのＭＥＣサーバ３００に、複数の００が接続し得るためである。
　例えば、ＭＥＣアプリケーションとＵＥ２００との通信のための鍵は、ＵＥ２００の認証情報（即ち、ＵＥ２００のＩＭＳＩ及び鍵Ｋ）に基づいて生成される。詳しくは、まず、ＵＥ２００のアタッチ手続きにおいて、ＵＥ２００の認証情報を用いて鍵ＫＡＳＭＥが生成される。そして、鍵ＫＡＳＭＥに基づいて鍵ＫｅＮｏｄｅＢが生成され、鍵ＫｅＮｏｄｅＢに基づいてＭＥＣアプリケーションとＵＥ２００との通信のためのＣＫ及びＩＫが生成される。このＣＫ及びＩＫを、鍵ＫＵＥ－ＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎとも総称する。つまり、鍵ＫＵＥ－ＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎは、ＣＫ及びＩＫを含む。なお、同一のＭＥＣサーバ３００上で動作するＭＥＣアプリケーションに関しては、複数のＭＥＣアプリケーション間で同一の鍵ＫＵＥ－ＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎが用いられてもよいし、異なる鍵ＫＵＥ－ＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎが用いられてもよい。
　鍵ＫＵＥ－ＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎに関する鍵の系統図を、図２１に示した。図２１に示すように、ＵＥ２００のアタッチ手続きにおいて生成された鍵ＫＡＳＭＥに基づいて鍵ＫｅＮｏｄｅＢが生成され、この鍵ＫｅＮｏｄｅＢに基づいて鍵ＫＵＥ－ＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎが生成される。
　以上説明した、ＭＥＣアプリケーションとＭＭＥ４１との間の鍵、及びＭＥＣアプリケーションとＭＭＥ４１との間の鍵の特徴を、下記の表３に示した。
Figure JPOXMLDOC01-appb-T000003
　＜＜６．第４の実施形態＞＞
　本実施形態は、ＭＥＣサーバ３００に関連する他のエンティティを認証する形態である。
　　＜６．１．技術的課題＞
　ＭＥＣサーバへ、動画又はアプリケーション等のコンテンツを提供する事業者の存在が想定される。そして、ＭＥＣサーバへコンテンツを提供するためのコンテンツサーバが存在すると想定される。このようなコンテンツサーバを、以下ではＯＴＴ(Over　the　top)サーバとも称する。
　ＯＴＴサーバの配置例を、図２２及び図２３に示した。図２２に示した例では、ＯＴＴサーバ５００はＥＰＣの内部に配置されている。図２３に示した例では、ＯＴＴサーバ５００はＥＰＣの外部に配置されている。ＯＴＴサーバ５００がＥＰＣの外部に配置される場合、ＯＴＴサーバ５００はＭＥＣサーバ３００と直接的に接続されてもよいし、Ｐ－ＧＷ４４及びＳ－ＧＷ４３等を経由して接続されてもよい。
　いずれの配置例が採用されるにしろ、ＭＥＣサーバ３００と同様に、ＯＴＴサーバ５００の信頼性が確認されることが望ましい。
　そこで、本実施形態では、ＯＴＴサーバ５００を認証するための手続きを提供する。
　　＜６．２．ＯＴＴサーバの構成例＞
　続いて、図２４を参照して、本開示の一実施形態に係るＯＴＴサーバ５００の構成の一例を説明する。図２４は、本開示の一実施形態に係るＯＴＴサーバ５００の構成の一例を示すブロック図である。図２４を参照すると、ＯＴＴサーバ５００は、通信部５１０、記憶部５２０、及び処理部５３０を備える。
　　（１）通信部５１０
　通信部５１０は、他の装置との間で通信を行うためのインタフェースである。例えば、通信部５１０は、ＭＥＣサーバ３００との間で直接的に、又はＰ－ＧＷ４４及びＳ－ＧＷ４３等を経由して間接的に通信を行う。
　　（２）記憶部５２０
　記憶部５２０は、ＯＴＴサーバ５００の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。例えば、記憶部５２０は、ＭＥＣサーバ３００へ提供される多様なコンテンツ、及びアプリケーションを記憶し得る。
　　（３）処理部５３０
　処理部５３０は、ＯＴＴサーバ５００の様々な機能を提供する。処理部５３０は、認証処理部５３１及び通信処理部５３３を含む。なお、処理部５３０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部５３０は、これらの構成要素の動作以外の動作も行い得る。
　認証処理部５３１及び通信処理部５３３は、上述した認証処理部３３１及び通信処理部３３３と同様の機能を有する。なお、図２４では省略しているが、処理部５３０は、ＭＥＣサーバ３００へのコンテンツを提供するコンテンツ処理部を含んでいてもよい。
　　＜６．３．技術的特徴＞
　想定される各種ケースにおける技術的特徴を、以下に順に説明する。
　　（１）第１のケース
　本ケースは、ＯＴＴサーバ５００がＥＰＣの内部に配置されており、且つ、ＯＴＴサーバ５００が信頼性のあるエンティティとして取り扱われるケースである。本ケースでは、ＯＴＴサーバ５００の信頼性を改めて確認するための認証手続きは不要である。もちろん、この場合であっても、ＯＴＴサーバ５００の信頼性を確認するための認証手続きが行われてもよい。
　　（２）第２のケース
　本ケースは、ＯＴＴサーバ５００がＥＰＣに外部に配置されている、又はＯＴＴサーバ５００がＥＰＣの内部に配置されているものの信頼性のないエンティティとして取り扱われるケースである。この場合、ＯＴＴサーバ５００は、第１の実施形態におけるＭＥＣサーバ３００と同様の認証手続きにより認証されてもよい。
　ＯＴＴサーバ５００は、第１の実施形態に係るＭＥＣサーバ３００と同様の技術的特徴を有する。ＭＭＥ４１及びＨＳＳ４２等の各エンティティも、認証の対象がＭＥＣサーバ３００からＯＴＴサーバ５００に変更される以外、第１の実施形態と同様の技術的特徴を有する。つまり、本ケースの技術的特徴は、第１の実施形態に関する説明のうち、ＭＥＣサーバ３００をＯＴＴサーバ５００に読み替えたものに相当する。
　例えば、ＨＳＳ４２（例えば、記憶部４２０）は、ＯＴＴサーバ５００に対応する認証情報を記憶する。本ケースでは、ＯＴＴサーバ５００に対応する認証情報は、ＯＴＴサーバ５００の認証情報である。具体的には、ＯＴＴサーバ５００の認証情報は、ＯＴＴサーバ５００を特定する番号（即ち、ＩＭＳＩ）及びＯＴＴサーバ５００に固有の鍵情報（即ち、鍵Ｋ）を含む。他方、ＯＴＴサーバ５００（例えば、記憶部５２０）も、ＯＴＴサーバ５００の認証情報を記憶する。そして、ＯＴＴサーバ５００（例えば、認証処理部５３１）は、ＯＴＴサーバ５００の認証情報を用いてネットワークへの認証を行う。ＯＴＴサーバ５００（例えば、通信処理部５３３）は、認証されたネットワークとの通信を行う。具体的には、ＯＴＴサーバ５００は、認証されたネットワーク（例えば、当該ネットワーク内のｅＮｏｄｅＢ１００）を経由して、ＭＥＣサーバ３００へコンテンツを提供する。このようにして、ＯＴＴサーバ５００は、信頼性のあるエンティティとして認証され、ネットワークに接続することが可能となる。
　ＯＴＴサーバ５００認証手続きは、認証する主体がＭＥＣサーバ３００からＯＴＴサーバ５００に変更される以外、図１８を参照して上記説明したものと同様である。以下、図２５を参照して、本ケースに係る認証手続きについて説明する。
　図２５は、本実施形態に係るシステム１において実行される認証手続きの流れの一例を示すシーケンス図である。図２５に示すように、ＯＴＴサーバ５００は、ＩＭＳＩ及び鍵Ｋを記憶している。また、ＨＳＳ４２は、ＯＴＴサーバ５００のＩＭＳＩに対応する鍵Ｋを記憶している。なお、ＯＴＴサーバ５００は、ｅＮｏｄｅＢ１００を経由してＭＭＥ４１と通信する。
　まず、ＯＴＴサーバ５００は、ＩＭＳＩと共にアタッチリクエストをＭＭＥ４１へ送信する（ステップＳ３０２）。次いで、ＭＭＥ４１は、受信したＩＭＳＩと共に認証リクエストをＨＳＳ４２へ送信する（ステップＳ３０４）。次に、ＨＳＳ４２は、乱数ＲＡＮＤを発生させて、乱数ＲＡＮＤ、受信したＩＭＳＩ、及び当該ＩＭＳＩに対応付けて記憶している鍵Ｋを認証機能に入力し、期待される応答ＲＥＳＥＸＰＥＣＴＥＤ及び鍵ＫＡＳＭＥを得る（ステップＳ３０６）。次いで、ＨＳＳ４２は、認証レスポンスとして、鍵ＫＡＳＭＥ、期待される応答ＲＥＳＥＸＰＥＣＴＥＤ及び乱数ＲＡＮＤをＭＭＥ４１送信する（ステップＳ３０８）。次に、ＭＭＥ４１は、乱数ＲＡＮＤをＯＴＴサーバ５００へ送信する（ステップＳ３１０）。次いで、ＯＴＴサーバ５００は、受信した乱数ＲＡＮＤ、記憶しているＩＭＳＩ及び鍵Ｋを認証機能に入力し、応答ＲＥＳ及び鍵ＫＡＳＭＥを得る（ステップＳ３１２）。次に、ＯＴＴサーバ５００は、応答ＲＥＳをＭＭＥ４１へ送信する（ステップＳ３１４）。そして、ＭＭＥ４１は、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとを比較してＯＴＴサーバ５００を認証する（ステップＳ３１６）。詳しくは、ＭＭＥ４１は、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとが一致した場合にはＯＴＴサーバ５００に信頼性があると判断する（即ち、認証が成功する）。一方で、ＭＭＥ４１は、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとが一致しない場合にはＯＴＴサーバ５００に信頼性がないと判断する（即ち、認証が失敗する）。
　本ケースの変形例として、ＯＴＴサーバ５００がＭＭＥ４１と直接的に接続されるケースが考えられる。この場合のＯＴＴサーバ５００の配置例を、図２６に示した。図２６に示した例では、ＯＴＴサーバ５００は、ＥＰＣの内部に配置されており、且つＭＭＥ４１に直接的に接続されている。この場合の認証手続きは、ＯＴＴサーバ５００とＭＭＥ４１との通信がｅＮｏｄｅＢ１００を経由しなくなる以外、図２５を参照して上記説明したものと同様である。以下、図２７を参照して、本ケースに係る認証手続きについて説明する。
　図２７は、本実施形態に係るシステム１において実行される認証手続きの流れの一例を示すシーケンス図である。図２７に示すように、ＯＴＴサーバ５００は、ＩＭＳＩ及び鍵Ｋを記憶している。また、ＨＳＳ４２は、ＯＴＴサーバ５００のＩＭＳＩに対応する鍵Ｋを記憶している。なお、ＯＴＴサーバ５００は、ｅＮｏｄｅＢ１００を経由せずにＭＭＥ４１と通信する。
　まず、ＯＴＴサーバ５００は、ＩＭＳＩと共にアタッチリクエストをＭＭＥ４１へ送信する（ステップＳ４０２）。次いで、ＭＭＥ４１は、受信したＩＭＳＩと共に認証リクエストをＨＳＳ４２へ送信する（ステップＳ４０４）。次に、ＨＳＳ４２は、乱数ＲＡＮＤを発生させて、乱数ＲＡＮＤ、受信したＩＭＳＩ、及び当該ＩＭＳＩに対応付けて記憶している鍵Ｋを認証機能に入力し、期待される応答ＲＥＳＥＸＰＥＣＴＥＤ及び鍵ＫＡＳＭＥを得る（ステップＳ４０６）。次いで、ＨＳＳ４２は、認証レスポンスとして、鍵ＫＡＳＭＥ、期待される応答ＲＥＳＥＸＰＥＣＴＥＤ及び乱数ＲＡＮＤをＭＭＥ４１送信する（ステップＳ４０８）。次に、ＭＭＥ４１は、乱数ＲＡＮＤをＯＴＴサーバ５００へ送信する（ステップＳ４１０）。次いで、ＯＴＴサーバ５００は、受信した乱数ＲＡＮＤ、記憶しているＩＭＳＩ及び鍵Ｋを認証機能に入力し、応答ＲＥＳ及び鍵ＫＡＳＭＥを得る（ステップＳ４１２）。次に、ＯＴＴサーバ５００は、応答ＲＥＳをＭＭＥ４１へ送信する（ステップＳ４１４）。そして、ＭＭＥ４１は、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとを比較してＯＴＴサーバ５００を認証する（ステップＳ４１６）。詳しくは、ＭＭＥ４１は、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとが一致した場合にはＯＴＴサーバ５００に信頼性があると判断する（即ち、認証が成功する）。一方で、ＭＭＥ４１は、期待される応答ＲＥＳＥＸＰＥＣＴＥＤと実際の応答ＲＥＳとが一致しない場合にはＯＴＴサーバ５００に信頼性がないと判断する（即ち、認証が失敗する）。
　本ケース及び上記変形例では、ＯＴＴサーバ５００とＭＭＥ４１との通信のための鍵、及びＯＴＴサーバ５００とＭＥＣアプリケーションとの通信のための鍵は、ＯＴＴサーバ５００の認証情報に基づいて生成される。詳しくは、まず、ＯＴＴサーバ５００のアタッチ手続きにおいて、ＯＴＴサーバ５００の認証情報を用いて鍵ＫＡＳＭＥが生成される。そして、この鍵ＫＡＳＭＥに基づいて、ＯＴＴサーバ５００とＭＭＥ４１との通信のための鍵、及びＯＴＴサーバ５００とＭＥＣアプリケーションとの通信のための鍵が生成される。前者の鍵を鍵ＫＯＴＴ　Ｓｅｒｖｅｒ－ＭＭＥとも称し、後者の鍵を鍵ＫＯＴＴ　Ｓｅｒｖｅｒ－ＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎとも称する。鍵ＫＯＴＴ　Ｓｅｒｖｅｒ－ＭＭＥは、ＣＫ及びＩＫを含む。同様に、鍵ＫＯＴＴ　Ｓｅｒｖｅｒ－ＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎは、ＣＫ及びＩＫを含む。これらの鍵の系統図を、図２８に示した。図２８に示すように、ＯＴＴサーバ５００のアタッチ手続きにおいて生成されたＫＡＳＭＥに基づいて、鍵ＫＯＴＴ　Ｓｅｒｖｅｒ－ＭＭＥ及び鍵ＫＯＴＴ　Ｓｅｒｖｅｒ－ＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎが生成される。
　　（３）第３のケース
　本ケースは、上記第２の実施形態と同様に、ＯＴＴサーバ５００の認証をＵＥ２００が代理で行うケースである。
　ＯＴＴサーバ５００は、第２の実施形態に係るＭＥＣサーバ３００と同様の技術的特徴を有する。ＵＥ２００、ＭＭＥ４１及びＨＳＳ４２等の各エンティティも、認証の対象がＭＥＣサーバ３００からＯＴＴサーバ５００に変更される以外、第２の実施形態と同様の技術的特徴を有する。つまり、本ケースの技術的特徴は、第２の実施形態に関する説明のうち、ＭＥＣサーバ３００をＯＴＴサーバ５００に読み替えたものに相当する。
　例えば、ＨＳＳ４２（例えば、記憶部４２０）は、ＯＴＴサーバ５００に対応する認証情報を記憶する。本ケースでは、ＯＴＴサーバ５００に対応する認証情報は、ＯＴＴサーバ５００に対応付けられたＵＥ２００の認証情報である。ＵＥ２００（例えば、認証処理部２４１）は、ＯＴＴサーバ５００の代理で認証を行う。そして、ＯＴＴサーバ５００（例えば、通信処理部５３３）は、ネットワークへの認証に成功した、当該ＯＴＴサーバ５００に対応付けられたＵＥ２００によるリクエスト（即ち、アタッチリクエスト）に基づいて発行された情報を用いて、ネットワークとの通信を行う。なお、第２の実施形態におけるＭＥＣサーバＩＤに対応する、ＯＴＴサーバ５００に固有の識別情報を、以下ではＯＴＴサーバＩＤとも称する。また、第２の実施形態におけるＭＥＣサーバテンポラリＩＤに対応する、ネットワークへの認証に成功したＵＥ２００によるリクエストに基づいて発行される情報を、以下ではＯＴＴサーバテンポラリＩＤとも称する。
　以下、図２９を参照して、ＵＥ２００がＯＴＴサーバ５００の代理で認証を行う場合の認証手続きの流れの一例を説明する。
　図２９は、本実施形態に係るシステム１において実行される認証手続きの流れの一例を示すシーケンス図である。なお、ＵＥ２００は、ｅＮｏｄｅＢ１００を経由してＭＭＥ４１と通信する。
　図２９に示すように、まず、ＵＥ２００は、アタッチ手続きを行う（ステップＳ５０２）。このアタッチ手続きにおいて、図１２を参照して上記説明した認証手続きが行われる。次いで、ＵＥ２００は、ＯＴＴサーバ５００のアタッチリクエストをＭＭＥ４１へ送信する（ステップＳ５０４）。このアタッチリクエストは、認証対象のＯＴＴサーバ５００に固有の識別情報であるＯＴＴサーバＩＤを含む。次に、ＭＭＥ４１は、受信したＯＴＴサーバ５００のアタッチリクエストを、ＨＳＳ４２へ転送する（ステップＳ５０６）。次いで、ＨＳＳ４２は、ＯＴＴサーバ５００のアタッチレスポンスをＭＭＥ４１へ返信する（ステップＳ５０８）。このとき、ＨＳＳ４２は、アタッチリクエストの送信元のＵＥ２００の加入者情報に、当該ＯＴＴサーバ５００のＯＴＴサーバＩＤが登録されているか否かを確認する。以下では、登録されていた場合について説明する。即ち、アタッチレスポンスに、ＯＴＴサーバテンポラリＩＤが含まれる。次に、ＭＭＥ４１は受信したＯＴＴサーバ５００のアタッチレスポンスをｅＮｏｄｅＢ１００へ転送し（ステップＳ５１０）、ｅＮｏｄｅＢ１００は受信したＯＴＴサーバ５００のアタッチレスポンスをＯＴＴサーバ５００へ転送する（ステップＳ５１２）。そして、ＯＴＴサーバ５００は、アタッチレスポンスに含まれるＯＴＴサーバテンポラリＩＤを用いて、ネットワークにアタッチする（ステップＳ５１４）。
　本ケースでは、ＯＴＴサーバ５００とＭＭＥ４１との通信のための鍵、及びＯＴＴサーバ５００とＭＥＣアプリケーションとの通信のための鍵は、ＵＥ２００の認証情報に基づいて生成される。詳しくは、まず、ＵＥ２００のアタッチ手続きにおいて、ＵＥ２００の認証情報を用いて鍵ＫＡＳＭＥが生成される。そして、この鍵ＫＡＳＭＥに基づいて、ＯＴＴサーバ５００とＭＭＥ４１との通信のための鍵ＫＯＴＴ　Ｓｅｒｖｅｒ－ＭＭＥ、及びＯＴＴサーバ５００とＭＥＣアプリケーションとの通信のための鍵ＫＯＴＴ　Ｓｅｒｖｅｒ－ＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎが生成される。これらの鍵の系統図を、図３０に示した。図３０に示すように、ＯＴＴサーバ５００のアタッチ手続きを行ったＵＥ２００のＫＡＳＭＥに基づいて、鍵ＫＯＴＴ　Ｓｅｒｖｅｒ－ＭＭＥ及び鍵ＫＯＴＴ　Ｓｅｒｖｅｒ－ＭＥＣ　Ａｐｐｌｉｃａｔｉｏｎが生成される。
　　（４）第４のケース
　本ケースは、ＯＴＴサーバ５００が、ＭＥＣサーバ３００の認証を代理で行うケースである。ＯＴＴサーバ５００は、第２の実施形態に係るＵＥ２００と同様の技術的特徴を有する。ＭＥＣサーバ３００、ＭＭＥ４１及びＨＳＳ４２等の各エンティティに関しても、ＵＥ２００の認証情報を用いた認証手続きがＯＴＴサーバ５００の認証情報を用いた認証手続きに変更される以外、第２の実施形態と同様の技術的特徴を有する。つまり、本ケースの技術的特徴は、第２の実施形態に関する上記説明のうち、ＵＥ２００をＯＴＴサーバ５００に読み替えたものに相当する。
　例えば、ＨＳＳ４２（例えば、記憶部４２０）は、ＭＥＣサーバ３００に対応する認証情報を記憶する。本ケースでは、ＭＥＣサーバ３００に対応する認証情報は、ＭＥＣサーバ３００に対応付けられたＯＴＴサーバ５００の認証情報である。具体的には、ＨＳＳ４２（例えば、記憶部４２０）は、ＯＴＴサーバ５００に対応付けて、ＭＥＣサーバ３００の識別情報、即ちＭＥＣサーバＩＤを記憶する。例えば、ＨＳＳ４２は、ＯＴＴサーバ５００の加入者情報として、ＯＴＴサーバ５００と対応付けられたＭＥＣサーバ３００のＭＥＣサーバＩＤを記憶する。
　そして、ＯＴＴサーバ５００（例えば、認証処理部５３１）は、ＭＥＣサーバ３００の代理で認証を行う。ＭＥＣサーバ３００（例えば、通信処理部３３３）は、ネットワークへの認証に成功した、当該ＭＥＣサーバ３００に対応付けられたＯＴＴサーバ５００によるリクエスト（即ち、アタッチリクエスト）に基づいて発行された情報（即ち、ＭＥＣサーバテンポラリＩＤ）を用いて、ネットワークとの通信を行う。システム１は、この発行された情報に基づいてＭＥＣサーバ３００が認証済みであるか否かを識別することが可能となるので、セキュリティが確保される。
　なお、図２９を参照して上記説明したように、ＯＴＴサーバ５００自身は認証情報を有さず、ＵＥ２００が代理で認証する場合も考えられる。その場合、ＭＥＣサーバ３００のネットワークへの認証に用いられる認証情報は、ＭＥＣサーバ３００に対応付けられたＵＥ２００であって、ＯＴＴサーバ５００の認証を代理したＵＥ２００の認証情報であってもよい。その場合、ＨＳＳ４２（例えば、記憶部４２０）は、ＵＥ２００の加入者識別情報として、例えばＯＴＴサーバＩＤ及びＭＥＣサーバＩＤを記憶する。
　以下、図３１を参照して、ＯＴＴサーバ５００がＭＥＣサーバ３００の代理で認証を行う場合の認証手続きの流れの一例を説明する。
　図３１は、本実施形態に係るシステム１において実行される認証手続きの流れの一例を示すシーケンス図である。なお、ＯＴＴサーバ５００は、ｅＮｏｄｅＢ１００を経由してＭＭＥ４１と通信する。
　図３１に示すように、まず、ＯＴＴサーバ５００は、アタッチ手続きを行う（ステップＳ６０２）。このアタッチ手続きにおいて、図２７又は図２９を参照して上記説明した認証手続きが行われ、ＯＴＴサーバ５００が認証される。次いで、ＯＴＴサーバ５００は、ＭＥＣサーバ３００のアタッチリクエストをＭＭＥ４１へ送信する（ステップＳ６０４）。このアタッチリクエストは、認証対象のＭＥＣサーバ３００のＭＥＣサーバＩＤを含む。次に、ＭＭＥ４１は、受信したＭＥＣサーバ３００のアタッチリクエストを、ＨＳＳ４２へ転送する（ステップＳ６０６）。次いで、ＨＳＳ４２は、ＭＥＣサーバ３００のアタッチレスポンスをＭＭＥ４１へ返信する（ステップＳ６０８）。このとき、ＨＳＳ４２は、アタッチリクエストの送信元のＯＴＴサーバ５００又は当該ＯＴＴサーバ５００の認証を代理したＵＥ２００の加入者情報に、当該ＭＥＣサーバ３００のＭＥＣサーバＩＤが登録されているか否かを確認する。以下では、登録されていた場合について説明する。即ち、アタッチレスポンスに、ＭＥＣサーバテンポラリＩＤが含まれる。次に、ＭＭＥ４１は受信したＭＥＣサーバ３００のアタッチレスポンスをｅＮｏｄｅＢ１００へ転送し（ステップＳ６１０）、ｅＮｏｄｅＢ１００は受信したアタッチレスポンスをＭＥＣサーバ３００へ転送する（ステップＳ６１２）。そして、ＭＥＣサーバ３００は、アタッチレスポンスに含まれるＭＥＣサーバテンポラリＩＤを用いて、ネットワークにアタッチする（ステップＳ６１４）。
　＜＜７．応用例＞＞
　本開示に係る技術は、様々な製品へ応用可能である。例えば、ＭＥＣサーバ３００、ＭＭＥ４１、ＨＳＳ４２、又はＯＴＴサーバ５００は、タワーサーバ、ラックサーバ、又はブレードサーバなどのいずれかの種類のサーバとして実現されてもよい。また、ＭＥＣサーバ３００、ＭＭＥ４１、ＨＳＳ４２、又はＯＴＴサーバ５００の少なくとも一部の構成要素は、サーバに搭載されるモジュール（例えば、１つのダイで構成される集積回路モジュール、又はブレードサーバのスロットに挿入されるカード若しくはブレード）において実現されてもよい。
　また、例えば、端末装置２００は、スマートフォン、タブレットＰＣ（Personal　Computer）、ノートＰＣ、携帯型ゲーム端末、携帯型／ドングル型のモバイルルータ若しくはデジタルカメラなどのモバイル端末、又はカーナビゲーション装置などの車載端末として実現されてもよい。また、端末装置２００は、Ｍ２Ｍ（Machine　To　Machine）通信を行う端末（ＭＴＣ（Machine　Type　Communication）端末ともいう）として実現されてもよい。さらに、端末装置２００の少なくとも一部の構成要素は、これら端末に搭載されるモジュール（例えば、１つのダイで構成される集積回路モジュール）において実現されてもよい。
　　＜７．１．サーバに関する応用例＞
　図３２は、本開示に係る技術が適用され得るサーバ７００の概略的な構成の一例を示すブロック図である。サーバ７００は、プロセッサ７０１、メモリ７０２、ストレージ７０３、ネットワークインタフェース７０４及びバス７０６を備える。
　プロセッサ７０１は、例えばＣＰＵ（Central　Processing　Unit）又はＤＳＰ（Digital　Signal　Processor）であってよく、サーバ７００の各種機能を制御する。メモリ７０２は、ＲＡＭ（Random　Access　Memory）及びＲＯＭ（Read　Only　Memory）を含み、プロセッサ７０１により実行されるプログラム及びデータを記憶する。ストレージ７０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。
　ネットワークインタフェース７０４は、サーバ７００を有線通信ネットワーク７０５に接続するための有線通信インタフェースである。有線通信ネットワーク７０５は、ＥＰＣ（Evolved　Packet　Core）などのコアネットワークであってもよく、又はインターネットなどのＰＤＮ（Packet　Data　Network）であってもよい。
　バス７０６は、プロセッサ７０１、メモリ７０２、ストレージ７０３及びネットワークインタフェース７０４を互いに接続する。バス７０６は、速度の異なる２つ以上のバス（例えば、高速バス及び低速バス）を含んでもよい。
　図３２に示したサーバ７００において、図１６を参照して説明したＭＥＣサーバ３００に含まれる１つ以上の構成要素（認証処理部３３１及び／又は通信処理部３３３）は、プロセッサ７０１において実装されてもよい。また、サーバ７００において、図１７を参照して説明したＭＭＥ４１又はＨＳＳ４２に含まれる１つ以上の構成要素（処理部４３０）は、プロセッサ７０１において実装されてもよい。また、サーバ７００において、図２４を参照して説明したＯＴＴサーバ５００に含まれる１つ以上の構成要素（認証処理部５３１及び／又は通信処理部５３３）は、プロセッサ７０１において実装されてもよい。一例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）がサーバ７００にインストールされ、プロセッサ７０１が当該プログラムを実行してもよい。別の例として、サーバ７００は、プロセッサ７０１及びメモリ７０２を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムをメモリ７０２に記憶し、当該プログラムをプロセッサ７０１により実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてサーバ７００又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるための上記プログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
　図３２に示したサーバ７００において、図１６を参照して上記説明した通信部３１０、図１７を参照して上記説明した通信部４１０、又は図２４を参照して上記説明した通信部５１０は、ネットワークインタフェース７０４において実装されてもよい。また、図３２に示したサーバ７００において、図１６を参照して上記説明した記憶部３２０、図１７を参照して上記説明した記憶部４２０、又は図２４を参照して上記説明した記憶部５２０は、メモリ７０２又はストレージ７０３において実装されてもよい。
　　＜７．２．端末装置に関する応用例＞
　（第１の応用例）
　図３３は、本開示に係る技術が適用され得るスマートフォン９００の概略的な構成の一例を示すブロック図である。スマートフォン９００は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２、１つ以上のアンテナスイッチ９１５、１つ以上のアンテナ９１６、バス９１７、バッテリー９１８及び補助コントローラ９１９を備える。
　プロセッサ９０１は、例えばＣＰＵ又はＳｏＣ（System　on　Chip）であってよく、スマートフォン９００のアプリケーションレイヤ及びその他のレイヤの機能を制御する。メモリ９０２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９０１により実行されるプログラム及びデータを記憶する。ストレージ９０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。外部接続インタフェース９０４は、メモリーカード又はＵＳＢ（Universal　Serial　Bus）デバイスなどの外付けデバイスをスマートフォン９００へ接続するためのインタフェースである。
　カメラ９０６は、例えば、ＣＣＤ（Charge　Coupled　Device）又はＣＭＯＳ（Complementary　Metal　Oxide　Semiconductor）などの撮像素子を有し、撮像画像を生成する。センサ９０７は、例えば、測位センサ、ジャイロセンサ、地磁気センサ及び加速度センサなどのセンサ群を含み得る。マイクロフォン９０８は、スマートフォン９００へ入力される音声を音声信号へ変換する。入力デバイス９０９は、例えば、表示デバイス９１０の画面上へのタッチを検出するタッチセンサ、キーパッド、キーボード、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９１０は、液晶ディスプレイ（ＬＣＤ）又は有機発光ダイオード（ＯＬＥＤ）ディスプレイなどの画面を有し、スマートフォン９００の出力画像を表示する。スピーカ９１１は、スマートフォン９００から出力される音声信号を音声に変換する。
　無線通信インタフェース９１２は、ＬＴＥ又はＬＴＥ－Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９１２は、典型的には、ＢＢプロセッサ９１３及びＲＦ回路９１４などを含み得る。ＢＢプロセッサ９１３は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９１４は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９１６を介して無線信号を送受信する。無線通信インタフェース９１２は、ＢＢプロセッサ９１３及びＲＦ回路９１４を集積したワンチップのモジュールであってもよい。無線通信インタフェース９１２は、図３３に示したように複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含んでもよい。なお、図３３には無線通信インタフェース９１２が複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含む例を示したが、無線通信インタフェース９１２は単一のＢＢプロセッサ９１３又は単一のＲＦ回路９１４を含んでもよい。
　さらに、無線通信インタフェース９１２は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ（Local　Area　Network）方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９１３及びＲＦ回路９１４を含んでもよい。
　アンテナスイッチ９１５の各々は、無線通信インタフェース９１２に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９１６の接続先を切り替える。
　アンテナ９１６の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９１２による無線信号の送受信のために使用される。スマートフォン９００は、図３３に示したように複数のアンテナ９１６を有してもよい。なお、図３３にはスマートフォン９００が複数のアンテナ９１６を有する例を示したが、スマートフォン９００は単一のアンテナ９１６を有してもよい。
　さらに、スマートフォン９００は、無線通信方式ごとにアンテナ９１６を備えてもよい。その場合に、アンテナスイッチ９１５は、スマートフォン９００の構成から省略されてもよい。
　バス９１７は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２及び補助コントローラ９１９を互いに接続する。バッテリー９１８は、図中に破線で部分的に示した給電ラインを介して、図３３に示したスマートフォン９００の各ブロックへ電力を供給する。補助コントローラ９１９は、例えば、スリープモードにおいて、スマートフォン９００の必要最低限の機能を動作させる。
　図３３に示したスマートフォン９００において、図１５を参照して説明した端末装置２００に含まれる１つ以上の構成要素（認証処理部２４１及び／又は通信処理部２４３）は、無線通信インタフェース９１２において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、プロセッサ９０１又は補助コントローラ９１９において実装されてもよい。一例として、スマートフォン９００は、無線通信インタフェース９１２の一部（例えば、ＢＢプロセッサ９１３）若しくは全部、プロセッサ９０１、及び／又は補助コントローラ９１９を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがスマートフォン９００にインストールされ、無線通信インタフェース９１２（例えば、ＢＢプロセッサ９１３）、プロセッサ９０１、及び／又は補助コントローラ９１９が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてスマートフォン９００又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
　また、図３３に示したスマートフォン９００において、例えば、図１５を参照して説明した無線通信部２２０は、無線通信インタフェース９１２（例えば、ＲＦ回路９１４）において実装されてもよい。また、アンテナ部２１０は、アンテナ９１６において実装されてもよい。また、記憶部２３０は、メモリ９０２において実装されてもよい。
　（第２の応用例）
　図３４は、本開示に係る技術が適用され得るカーナビゲーション装置９２０の概略的な構成の一例を示すブロック図である。カーナビゲーション装置９２０は、プロセッサ９２１、メモリ９２２、ＧＰＳ（Global　Positioning　System）モジュール９２４、センサ９２５、データインタフェース９２６、コンテンツプレーヤ９２７、記憶媒体インタフェース９２８、入力デバイス９２９、表示デバイス９３０、スピーカ９３１、無線通信インタフェース９３３、１つ以上のアンテナスイッチ９３６、１つ以上のアンテナ９３７及びバッテリー９３８を備える。
　プロセッサ９２１は、例えばＣＰＵ又はＳｏＣであってよく、カーナビゲーション装置９２０のナビゲーション機能及びその他の機能を制御する。メモリ９２２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９２１により実行されるプログラム及びデータを記憶する。
　ＧＰＳモジュール９２４は、ＧＰＳ衛星から受信されるＧＰＳ信号を用いて、カーナビゲーション装置９２０の位置（例えば、緯度、経度及び高度）を測定する。センサ９２５は、例えば、ジャイロセンサ、地磁気センサ及び気圧センサなどのセンサ群を含み得る。データインタフェース９２６は、例えば、図示しない端子を介して車載ネットワーク９４１に接続され、車速データなどの車両側で生成されるデータを取得する。
　コンテンツプレーヤ９２７は、記憶媒体インタフェース９２８に挿入される記憶媒体（例えば、ＣＤ又はＤＶＤ）に記憶されているコンテンツを再生する。入力デバイス９２９は、例えば、表示デバイス９３０の画面上へのタッチを検出するタッチセンサ、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９３０は、ＬＣＤ又はＯＬＥＤディスプレイなどの画面を有し、ナビゲーション機能又は再生されるコンテンツの画像を表示する。スピーカ９３１は、ナビゲーション機能又は再生されるコンテンツの音声を出力する。
　無線通信インタフェース９３３は、ＬＴＥ又はＬＴＥ－Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９３３は、典型的には、ＢＢプロセッサ９３４及びＲＦ回路９３５などを含み得る。ＢＢプロセッサ９３４は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９３５は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９３７を介して無線信号を送受信する。無線通信インタフェース９３３は、ＢＢプロセッサ９３４及びＲＦ回路９３５を集積したワンチップのモジュールであってもよい。無線通信インタフェース９３３は、図３４に示したように複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含んでもよい。なお、図３４には無線通信インタフェース９３３が複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含む例を示したが、無線通信インタフェース９３３は単一のＢＢプロセッサ９３４又は単一のＲＦ回路９３５を含んでもよい。
　さらに、無線通信インタフェース９３３は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９３４及びＲＦ回路９３５を含んでもよい。
　アンテナスイッチ９３６の各々は、無線通信インタフェース９３３に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９３７の接続先を切り替える。
　アンテナ９３７の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９３３による無線信号の送受信のために使用される。カーナビゲーション装置９２０は、図３４に示したように複数のアンテナ９３７を有してもよい。なお、図３４にはカーナビゲーション装置９２０が複数のアンテナ９３７を有する例を示したが、カーナビゲーション装置９２０は単一のアンテナ９３７を有してもよい。
　さらに、カーナビゲーション装置９２０は、無線通信方式ごとにアンテナ９３７を備えてもよい。その場合に、アンテナスイッチ９３６は、カーナビゲーション装置９２０の構成から省略されてもよい。
　バッテリー９３８は、図中に破線で部分的に示した給電ラインを介して、図３４に示したカーナビゲーション装置９２０の各ブロックへ電力を供給する。また、バッテリー９３８は、車両側から給電される電力を蓄積する。
　図３４に示したカーナビゲーション装置９２０において、図１５を参照して説明した端末装置２００に含まれる１つ以上の構成要素（認証処理部２４１及び／又は通信処理部２４３）は、無線通信インタフェース９３３において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、プロセッサ９２１において実装されてもよい。一例として、カーナビゲーション装置９２０は、無線通信インタフェース９３３の一部（例えば、ＢＢプロセッサ９３４）若しくは全部及び／又はプロセッサ９２１を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがカーナビゲーション装置９２０にインストールされ、無線通信インタフェース９３３（例えば、ＢＢプロセッサ９３４）及び／又はプロセッサ９２１が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてカーナビゲーション装置９２０又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
　また、図３４に示したカーナビゲーション装置９２０において、例えば、図１５を参照して説明した無線通信部２２０は、無線通信インタフェース９３３（例えば、ＲＦ回路９３５）において実装されてもよい。また、アンテナ部２１０は、アンテナ９３７において実装されてもよい。また、記憶部２３０は、メモリ９２２において実装されてもよい。
　また、本開示に係る技術は、上述したカーナビゲーション装置９２０の１つ以上のブロックと、車載ネットワーク９４１と、車両側モジュール９４２とを含む車載システム（又は車両）９４０として実現されてもよい。即ち、認証処理部２４１及び／又は通信処理部２４３を備える装置として車載システム（又は車両）９４０が提供されてもよい。車両側モジュール９４２は、車速、エンジン回転数又は故障情報などの車両側データを生成し、生成したデータを車載ネットワーク９４１へ出力する。
　＜＜８．まとめ＞＞
　以上、図１～図３４を参照して、本開示の一実施形態について詳細に説明した。上記説明したように、ＭＥＣサーバ３００又はＯＴＴサーバ５００は、ＨＳＳ４２に登録された当該サーバに対応する認証情報を用いて認証されたネットワークとの通信を行い、コンテンツを提供する。このようにして、信頼性の確認されていないＭＥＣサーバ３００又はＯＴＴサーバ５００がネットワークに接続することが防止される。また、ＭＥＣサーバ３００又はＯＴＴサーバ５００による通信のための鍵が提供されることで、ＭＥＣサーバ３００又はＯＴＴサーバ５００とＭＭＥ４１又はＵＥ２００との間の通信路の秘匿性を高めることが可能となる。
　以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
　例えば、上記説明した各実施形態は、適宜組み合わせることが可能である。
　また、本明細書においてフローチャート及びシーケンス図を用いて説明した処理は、必ずしも図示された順序で実行されなくてもよい。いくつかの処理ステップは、並列的に実行されてもよい。また、追加的な処理ステップが採用されてもよく、一部の処理ステップが省略されてもよい。
　また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
　なお、以下のような構成も本開示の技術的範囲に属する。
（１）
　他の装置へのコンテンツを提供するサーバであって、
　ＨＳＳ（Home　Subscriber　Server）に登録された前記サーバに対応する認証情報を用いて認証されたネットワークとの通信を行う処理部、
を備えるサーバ。
（２）
　前記サーバに対応する認証情報は、前記サーバの認証情報である、前記（１）に記載のサーバ。
（３）
　前記サーバの認証情報は、前記サーバを特定する番号及び前記サーバに固有の鍵情報を含む、前記（２）に記載のサーバ。
（４）
　前記サーバは、前記サーバの認証情報を記憶する記憶部をさらに備え、
　前記処理部は、前記サーバの認証情報を用いて前記ネットワークへの認証を行う、前記（２）又は（３）に記載のサーバ。
（５）
　前記サーバ上で動作するアプリケーションとＭＭＥとの通信のための鍵は前記サーバの認証情報に基づいて生成される、前記（２）～（４）のいずれか一項に記載のサーバ。
（６）
　前記サーバに対応する認証情報は、前記サーバに対応付けられた端末装置の認証情報である、前記（１）に記載のサーバ。
（７）
　前記端末装置の認証情報は、前記端末装置を特定する番号及び前記端末装置に固有の鍵情報である、前記（６）に記載のサーバ。
（８）
　前記処理部は、前記ネットワークへの認証に成功した、前記サーバに対応付けられた前記端末装置によるリクエストに基づいて発行された情報を用いて、前記ネットワークとの通信を行う、前記（６）又は（７）に記載のサーバ。
（９）
　前記サーバ上で動作するアプリケーションとＭＭＥとの通信のための鍵は、前記サーバに対応付けられた前記端末装置の認証情報に基づいて生成される、前記（８）に記載のサーバ。
（１０）
　端末装置と前記サーバ上で動作するアプリケーションとの通信のための鍵は、前記端末装置の認証情報に基づいて生成される、前記（１）～（９）のいずれか一項に記載のサーバ。
（１１）
　前記サーバは、ＥＰＳの内部に設けられるアプリケーションサーバである、前記（１）～（１０）のいずれか一項に記載のサーバ。
（１２）
　前記サーバに対応する認証情報は、前記サーバに対応付けられた他のサーバの認証情報である、前記（１１）に記載のサーバ。
（１３）
　前記処理部は、前記ネットワークへの認証に成功した、前記サーバに対応付けられた前記他のサーバによるリクエストに基づいて発行された情報を用いて、前記ネットワークとの通信を行う、前記（１２）に記載のサーバ。
（１４）
　前記他のサーバは、前記サーバへコンテンツを提供するコンテンツサーバである、前記（１２）又は（１３）に記載のサーバ。
（１５）
　前記サーバは、ＥＰＳの内部に設けられるアプリケーションサーバへコンテンツを提供するコンテンツサーバである、前記（１）～（１０）のいずれか一項に記載のサーバ。
（１６）
　前記サーバは、基地局を経由してＭＭＥと通信する、前記（１５）に記載のサーバ。
（１７）
　前記サーバは、基地局を経由せずにＭＭＥと通信する、前記（１５）に記載のサーバ。
（１８）
　前記サーバは、無線ＬＡＮネットワーク内に設けられるアプリケーションサーバである、前記（１）～（１０）のいずれか一項に記載のサーバ。
（１９）
　他の装置へのコンテンツを提供するサーバにより、
　ＨＳＳに登録された前記サーバに対応する認証情報を用いて認証されたネットワークとの通信を行うこと、
を含む方法。
（２０）
　コンピュータを、
　他の装置へのコンテンツを提供するサーバであって、ＨＳＳに登録された前記サーバに対応する認証情報を用いて認証されたネットワークとの通信を行う処理部を含むサーバ、
として機能させるためのプログラム。
　１　　システム
　１０　　セル
　４０　　コアネットワーク
　４１　　ＭＭＥ
　４２　　ＨＳＳ
　４３　　Ｓ－ＧＷ
　４４　　Ｐ－ＧＷ
　５０　　ＰＤＮ
　６０　　アプリケーションサーバ
　１００　　無線通信装置
　２００　　端末装置
　２１０　　アンテナ部
　２２０　　無線通信部
　２３０　　記憶部
　２４０　　処理部
　２４１　　認証処理部
　２４３　　通信処理部
　３００　　ＭＥＣサーバ
　３１０　　通信部
　３２０　　記憶部
　３３０　　処理部
　３３１　　認証処理部
　３３３　　通信処理部
　４１０　　通信部
　４２０　　記憶部
　４３０　　処理部
　５００　　ＯＴＴサーバ
　５１０　　通信部
　５２０　　記憶部
　５３０　　処理部
　５３１　　認証処理部
　５３３　　通信処理部

Claims (20)

  1. 　他の装置へのコンテンツを提供するサーバであって、
    　ＨＳＳ（Home　Subscriber　Server）に登録された前記サーバに対応する認証情報を用いて認証されたネットワークとの通信を行う処理部、
    を備えるサーバ。
  2. 　前記サーバに対応する認証情報は、前記サーバの認証情報である、請求項１に記載のサーバ。
  3. 　前記サーバの認証情報は、前記サーバを特定する番号及び前記サーバに固有の鍵情報を含む、請求項２に記載のサーバ。
  4. 　前記サーバは、前記サーバの認証情報を記憶する記憶部をさらに備え、
    　前記処理部は、前記サーバの認証情報を用いて前記ネットワークへの認証を行う、請求項２に記載のサーバ。
  5. 　前記サーバ上で動作するアプリケーションとＭＭＥとの通信のための鍵は前記サーバの認証情報に基づいて生成される、請求項２に記載のサーバ。
  6. 　前記サーバに対応する認証情報は、前記サーバに対応付けられた端末装置の認証情報である、請求項１に記載のサーバ。
  7. 　前記端末装置の認証情報は、前記端末装置を特定する番号及び前記端末装置に固有の鍵情報である、請求項６に記載のサーバ。
  8. 　前記処理部は、前記ネットワークへの認証に成功した、前記サーバに対応付けられた前記端末装置によるリクエストに基づいて発行された情報を用いて、前記ネットワークとの通信を行う、請求項６に記載のサーバ。
  9. 　前記サーバ上で動作するアプリケーションとＭＭＥとの通信のための鍵は、前記サーバに対応付けられた前記端末装置の認証情報に基づいて生成される、請求項８に記載のサーバ。
  10. 　端末装置と前記サーバ上で動作するアプリケーションとの通信のための鍵は、前記端末装置の認証情報に基づいて生成される、請求項１に記載のサーバ。
  11. 　前記サーバは、ＥＰＳの内部に設けられるアプリケーションサーバである、請求項１に記載のサーバ。
  12. 　前記サーバに対応する認証情報は、前記サーバに対応付けられた他のサーバの認証情報である、請求項１１に記載のサーバ。
  13. 　前記処理部は、前記ネットワークへの認証に成功した、前記サーバに対応付けられた前記他のサーバによるリクエストに基づいて発行された情報を用いて、前記ネットワークとの通信を行う、請求項１２に記載のサーバ。
  14. 　前記他のサーバは、前記サーバへコンテンツを提供するコンテンツサーバである、請求項１２に記載のサーバ。
  15. 　前記サーバは、ＥＰＳの内部に設けられるアプリケーションサーバへコンテンツを提供するコンテンツサーバである、請求項１に記載のサーバ。
  16. 　前記サーバは、基地局を経由してＭＭＥと通信する、請求項１５に記載のサーバ。
  17. 　前記サーバは、基地局を経由せずにＭＭＥと通信する、請求項１５に記載のサーバ。
  18. 　前記サーバは、無線ＬＡＮネットワーク内に設けられるアプリケーションサーバである、請求項１に記載のサーバ。
  19. 　他の装置へのコンテンツを提供するサーバにより、
    　ＨＳＳに登録された前記サーバに対応する認証情報を用いて認証されたネットワークとの通信を行うこと、
    を含む方法。
  20. 　コンピュータを、
    　他の装置へのコンテンツを提供するサーバであって、ＨＳＳに登録された前記サーバに対応する認証情報を用いて認証されたネットワークとの通信を行う処理部を含むサーバ、
    として機能させるためのプログラム。
PCT/JP2016/078848 2015-12-21 2016-09-29 サーバ、方法及びプログラム WO2017110193A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE112016005859.4T DE112016005859T5 (de) 2015-12-21 2016-09-29 Server, Verfahren und Programm

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015-248429 2015-12-21
JP2015248429 2015-12-21

Publications (1)

Publication Number Publication Date
WO2017110193A1 true WO2017110193A1 (ja) 2017-06-29

Family

ID=59089245

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/078848 WO2017110193A1 (ja) 2015-12-21 2016-09-29 サーバ、方法及びプログラム

Country Status (3)

Country Link
DE (1) DE112016005859T5 (ja)
TW (1) TW201727524A (ja)
WO (1) WO2017110193A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109327864A (zh) * 2018-11-07 2019-02-12 杭州迪普科技股份有限公司 流量处理方法、装置、设备及存储介质
CN114500049A (zh) * 2022-01-26 2022-05-13 北京邮电大学 物联网系统内的可移动终端设备身份认证方法和系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006221212A (ja) * 2005-02-08 2006-08-24 Hitachi Ltd コンテンツ配信システム
JP2008536379A (ja) * 2005-04-01 2008-09-04 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｉｍｓベースの通信を開始するための方法
JP2013534755A (ja) * 2010-06-18 2013-09-05 クアルコム，インコーポレイテッド リレーノード管理および認可のための方法および装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006221212A (ja) * 2005-02-08 2006-08-24 Hitachi Ltd コンテンツ配信システム
JP2008536379A (ja) * 2005-04-01 2008-09-04 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｉｍｓベースの通信を開始するための方法
JP2013534755A (ja) * 2010-06-18 2013-09-05 クアルコム，インコーポレイテッド リレーノード管理および認可のための方法および装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
YUO CHAO HU ET AL.: "Mobile Edge Computing A Key technology towards 5G", ETSI, September 2015 (2015-09-01), pages 1 - 16, XP055287768 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109327864A (zh) * 2018-11-07 2019-02-12 杭州迪普科技股份有限公司 流量处理方法、装置、设备及存储介质
CN114500049A (zh) * 2022-01-26 2022-05-13 北京邮电大学 物联网系统内的可移动终端设备身份认证方法和系统
CN114500049B (zh) * 2022-01-26 2022-11-11 北京邮电大学 物联网系统内的可移动终端设备身份认证方法和系统

Also Published As

Publication number Publication date
TW201727524A (zh) 2017-08-01
DE112016005859T5 (de) 2018-09-06

Similar Documents

Publication Publication Date Title
JP7041212B2 (ja) 仮想化されたモバイルコアネットワークへの接続
EP3614730B1 (en) Parameter determination method and communication entity
CN107852407B (zh) 用于集成小型小区和Wi-Fi网络的统一认证
CN109964498B (zh) 经由独立不可信非3gpp接入网络将远程单元附连到移动核心网络的方法和装置
JP6953706B2 (ja) 基地局
JPWO2017085978A1 (ja) 装置及び方法
JP7286785B2 (ja) プロトコルデータユニットセッションの確立
CN111869261A (zh) Lwa 通信中的发现与安全
EP3751817A1 (en) Method of dynamically provisioning a key for authentication in relay device
JP2019512903A (ja) 無線通信方法、及び装置
JP2017528074A5 (ja)
CN110447267A (zh) 交换用户设备的服务能力暴露功能（scef）相关信息
WO2017104281A1 (ja) 装置、方法及びプログラム
US9106421B1 (en) Securing communications over a first communication link with encryption managed by a second communication link
WO2022199451A1 (zh) 会话切换的方法和装置
EP4181542A1 (en) Proximity service communication method, management network element, terminal device, and communication system
WO2017110193A1 (ja) サーバ、方法及びプログラム
CN116723507B (zh) 针对边缘网络的终端安全方法及装置
WO2023011630A1 (zh) 授权验证的方法及装置
WO2020034378A1 (en) Location reporting for mobile devices
JP2019110552A (ja) ネットワークスライス選択
KR20230011294A (ko) 무선 통신 시스템에서 신호 송수신 방법 및 장치
WO2021134719A1 (zh) 一种通信方法及装置
WO2017094360A1 (ja) 装置、方法及びプログラム
WO2023020481A1 (zh) 用于传输数据的方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16878091

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 112016005859

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16878091

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP