WO2017104281A1

WO2017104281A1 - Device, method and program

Info

Publication number: WO2017104281A1
Application number: PCT/JP2016/082491
Authority: WO
Inventors: 高野　裕昭; 亮澤井; 齋藤　真; 亮太木村
Original assignee: ソニー株式会社
Priority date: 2015-12-15
Filing date: 2016-11-01
Publication date: 2017-06-22
Also published as: DE112016005741T5

Abstract

[Problem] To provide a configuration for appropriately establishing a pathway for transmitting data to an edge server or transferring data from the edge server. [Solution] A device provided with a processing unit which communicates using a first evolved packet system (EPS) bearer established between a packet data network gateway (P-GW) and a terminal device, via an application server which is provided within the EPS and either offers content to the terminal device or acquires content from the terminal device.

Description

Apparatus, method, and program

The present disclosure relates to an apparatus, a method, and a program.

In recent years, mobile edge computing (MEC) technology that performs data processing with a server (hereinafter also referred to as an edge server) that is physically located near a terminal such as a smartphone has been attracting attention. . For example, in the following Non-Patent Document 1, a standard of technology related to MEC is studied.

In the MEC, 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.

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. For example, a technique for appropriately setting a route for transmitting data to the edge server or transferring data from the edge server is one that has not been sufficiently proposed.

According to the present disclosure, between a terminal device and a P-GW (Packet Data Network Gateway) that is provided in the EPS and that provides content to the terminal device or passes through an application server that acquires content from the terminal device. An apparatus is provided that includes a processing unit that performs communication using the first EPS bearer established in (1).

Further, according to the present disclosure, a P-GW (Packet Data Network Gateway) provided in the EPS and via an application server that obtains content from the terminal device or acquires content from the terminal device, and the terminal device Communicating with a processor using a first EPS bearer established between them.

In addition, according to the present disclosure, the computer is provided with a P-GW (Packet Data Network Gateway) via the application server that is provided inside the EPS and provides content to the terminal device or acquires content from the terminal device. A program for functioning as a processing unit that performs communication using a first EPS bearer established with a terminal device is provided.

As described above, according to the present disclosure, a mechanism for appropriately setting a route for transmitting data to the edge server or transferring data from the edge server is provided. Note that 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.

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 | transduced. It is a figure which shows an example of a structure of the LTE network in which MEC was introduce | transduced. It is a figure which shows an example of the data flow of DL cache data. It is a figure which shows an example of the data flow of UL cache data. It is explanatory drawing for demonstrating the architecture of a bearer. It is explanatory drawing for demonstrating the architecture of an EPS bearer. It is explanatory drawing for demonstrating ID for UL and ID for DL set to a bearer. It is a sequence diagram which shows an example of the flow of the procedure for establishing a default bearer. It is a sequence diagram which shows an example of the flow of the procedure for establishing a dedicated bearer. It is explanatory drawing for demonstrating TFT. It is explanatory drawing for demonstrating in more detail about TFT. It is a block diagram which shows an example of a structure of the base station which concerns on the same embodiment. It is a block diagram which shows an example of a structure of the terminal device which concerns on the same embodiment. It is a block diagram which shows an example of a structure of the MEC server which concerns on the embodiment. It is explanatory drawing for demonstrating the MEC bearer which concerns on 1st Embodiment. It is explanatory drawing for demonstrating the architecture of the MEC bearer which concerns on the embodiment. It is a sequence diagram which shows an example of the MEC bearer establishment procedure which concerns on the embodiment. It is a sequence diagram which shows an example of the MEC bearer establishment procedure which concerns on the embodiment. It is explanatory drawing for demonstrating the bearer mapping by TFT which concerns on 2nd Embodiment. FIG. 10 is an explanatory diagram for explaining an example of a user traffic copy process according to the embodiment; FIG. 10 is an explanatory diagram for explaining an example of a user traffic copy process according to the embodiment; It is explanatory drawing for demonstrating the architecture of the MEC bearer which concerns on 3rd Embodiment. It is a sequence diagram which shows an example of the MEC bearer establishment procedure which concerns on the embodiment. It is a block diagram which shows an example of a schematic structure of a server. It is a block diagram which shows the 1st example of schematic structure of eNB. It is a block diagram which shows the 2nd example of schematic structure of eNB. It is a block diagram which shows an example of a schematic structure of a smart phone. It is a block diagram which shows an example of a schematic structure of a car navigation apparatus.

Hereinafter, preferred embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In addition, in this specification and drawing, about the component which has the substantially same function structure, duplication description is abbreviate | omitted by attaching | subjecting the same code | symbol.

In the present specification and drawings, elements having substantially the same functional configuration may be distinguished by adding different alphabets after the same reference numerals. For example, a plurality of elements having substantially the same functional configuration are differentiated as necessary, such as

base stations

100A, 100B, and 100C. However, 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. For example, when it is not necessary to distinguish the

base stations

100A, 100B, and 100C, they are simply referred to as the base station 100.

The description will be made in the following order.
1. 1. Introduction 1.1. Schematic configuration of system 1.2. MEC
1.3. Bearer 1.4. TFT and SDF
2. Configuration example of each device 2.1. Configuration example of base station 2.2. Configuration of terminal device 2.3. 2. Configuration example of MEC server First embodiment 3.1. Technical issues 3.2. Technical features 4. Second Embodiment 4.1. Technical issues 4.2. Technical features 5. Third Embodiment 5.1. Technical issues 5.2. Technical features Application example 7. Summary

<< 1. Introduction >>
<1.1. Schematic configuration of system>
First, a schematic configuration of a system 1 according to an embodiment of the present disclosure will be described with reference to FIG. 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. Referring to FIG. 1, the system 1 includes a wireless communication device 100, a terminal device 200, and an MEC server 300.

(1) Wireless communication device 100
The wireless communication device 100 is a device that provides a wireless communication service to subordinate devices. For example, 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. For example, the base station 100A transmits a downlink signal to the terminal device 200A and receives an uplink signal from the terminal device 200A.

Here, 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.

Here, the radio communication device 100A shown in FIG. 1 is a macro cell base station, and the cell 10A is a macro cell. On the other hand, the

wireless communication devices

100B and 100C are master devices that operate the

small cells

10B and 10C, respectively. As an example, 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. .

Note that 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. In one example, the small cell is operated by a dedicated base station. In another example, 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.

(2) 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. For example, the terminal device 200A receives a downlink signal from the base station 100A and transmits an uplink signal to the base station 100A.

Here, 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.

(3) Application server 60
The application server 60 is a device that provides services to users. The application server 60 is connected to a packet data network (PDN) 50. On the other hand, the base station 100 is connected to the core network 40. The core network 40 is connected to the PDN 50 via a gateway device. For this reason, 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.

(4) MEC server 300
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. In that case, the wireless communication device 100 provides the service provided by the MEC server 300 to the user via the wireless communication path. The MEC server 300 may be 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.

For example, 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.

Further, the master device 100B provides the service provided by the MEC server 300B to the terminal device 200B connected to the small cell 10B. Similarly, the master device 100C provides the service provided by the MEC server 300C to the terminal device 200C connected to the small cell 10C.

(5) Supplement Although the schematic configuration of the system 1 has been described above, the present technology is not limited to the example illustrated in FIG. For example, as a configuration of the system 1, a configuration that does not include a master device, an SCE (Small Cell Enhancement), a HetNet (Heterogeneous Network), an MTC (Machine Type Communication) network, or the like may be employed.

<1.2. MEC>
Next, the MEC will be described with reference to FIGS.

(1) Network Configuration FIG. 2 is a diagram illustrating an example of a configuration of an LTE network in which an MEC has not been introduced. As shown in FIG. 2, the RAN (Radio Access Network) includes a UE and an eNodeB. The UE and the eNodeB are connected by a Uu interface, and the eNodeBs are connected by an X2 interface. Further, EPC (Evolved Packet Core) includes MME (Mobility Management Entity), HSS (Home Subscriber Server), S-GW (Serving Gateway), and P-GW (PDN Gateway). The MME and the HSS are connected by the S6a interface, the MME and the S-GW are connected by the S11 interface, and the S-GW and the P-GW are connected by the S5 interface. The eNodeB and the MME are connected by an S1-MME interface, the eNodeB and the S-GW are connected by an S1-U interface, and 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. For example, an application or cache data is stored in the cache server. By accessing the cache server instead of the original server, the UE can reduce the processing load on the original server and the communication load related to the access to the original server. However, since 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) generated between the UE and the cache server is still a problem. It was.

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. In any case, it is obvious that the response to the request becomes faster when the cache data and the application are arranged in an entity closer to the UE. Here, typically, 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.

MEC was devised to solve this problem. In the MEC, an application server that provides content to the UE or acquires content from the UE is provided in an Evolved Packet System (EPS). Note that 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.

3 and 4 are diagrams illustrating an example of a configuration of an LTE network in which an MEC is introduced. In FIG. 3, an MEC server that caches content is provided in the eNodeB. According to this configuration, since the number of entities existing between the UE and the MEC server is reduced as compared with the example illustrated in FIG. 2, the UE can quickly acquire content. In FIG. 4, MEC servers that store content are provided in the eNodeB and the S-GW. For example, 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. In any case, since access to the original server can be avoided, the UE can quickly acquire the content.

(2) Each Entity Hereinafter, the entities appearing in FIGS. 2 to 4 will be described. 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.

Here, 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. On the other hand, 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.

(3) 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.

Here, it is important that the application is activated and can be operated in the MEC server. First, since 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. Second, if the MEC server provides a specific application, it is desirable that the application be deployed and activated to be operational.

∙ There are a wide variety of applications that support MEC. With respect to a cache application that caches data, even if it is activated and operable in the MEC server, if the target data is not cached, the UE will retrieve the data to the original server. Therefore, it is desirable to cache data in advance in a cache application.

(4) Data to be cached 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. There are two types of data (hereinafter also referred to as UL data flow).

As a use case for 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.

An example of a use case for caching the UL data flow is described below.

The first use case is a case of uploading data such as photos generated by the UE itself. Specifically, the UE uploads a photo generated by itself, and the MEC server caches this photo. Then, 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. In addition, 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. For example, the UE uploads data acquired by D2D (Device to Device) communication or Wi-Fi (registered trademark), and the MEC server caches this data. As a specific example of this use case, for example, a store broadcasts product information by D2D communication or Wi-Fi, and the UE acquires the information and uploads it to the MEC server. In that case, 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) can obtain the cached product information.

The third use case is a case where data received from a different eNodeB is uploaded. For example, 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. As such data, for example, sales data of vending machines, gas use status data detected by a gas meter, and the like can be considered. There are cases where 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. On the other hand, since 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. Therefore, 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. In particular, the transmission capacity of the core network is more problematic in terms of the capacity of control signals than the capacity of 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.

In the above, an example of a use case for caching the UL data flow has been described. In the present specification, such a cache of UL data flow will be mainly described.

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, and 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. As shown in FIG. 5, 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. As shown in FIG. 6, the MEC server caches the data uploaded by the UE and transmits the cache data to the original server on the PDN.

Note that some data may not be permitted to be handled as DL cache data. For example, it is considered that 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. Similarly, it is considered that some data is not permitted to be handled as UL cache data. For example, it is considered that 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.

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

<1.3. Bearer>
Next, bearers used in EPS, particularly EPS bearers, will be described with reference to FIGS. 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. As shown in FIG. 7, 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. As shown in FIG. 8, the EPS bearer includes a default bearer and a dedicated bearer. 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. As shown in FIG. 9, in an EPS bearer, a UL session and a DL session are distinguished from each other by different IDs. For example, the ID set for the radio bearer includes “UL RB ID” for UL and “DL RB ID” for DL. In addition, in 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. Further, 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.

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

The following table shows a list of data flow using ID. As shown in the table below, 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.

Subsequently, a procedure for establishing a bearer will be described with reference to FIG. 10 and FIG.

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.

】 This sequence will be explained in detail. First, the UE transmits an attach request to the eNodeB (step S11), and the eNodeB transmits the message to the MME (step S12). Next, the MME transmits a default bearer generation request to the S-GW (step S13), and the S-GW transmits the message to the P-GW (step S14). Then, the P-GW communicates with the PCRF to establish an IP-CAN (IP Connectivity Access Network) session (step S15). Next, 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). Next, 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). Next, the UE transmits RRC connection reconfiguration completion to the eNodeB (step S20), and the eNodeB transmits attachment completion to the MME (step S21). Next, the MME transmits a bearer update request to the S-GW (step S22), and the S-GW transmits a bearer update response to the MME (step S23).

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.

】 This sequence will be explained in detail. First, the PCRF transmits an IP-CAN session change start to the P-GW (step S31). Next, the P-GW transmits a dedicated bearer generation request to the S-GW (step S32), and the S-GW transmits the message to the MME (step S33). Next, the MME transmits a dedicated bearer setup request to the eNodeB (step S34), and the eNodeB transmits RRC connection reconfiguration to the UE (step S35). Next, 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). Next, 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). Next, the P-GW transmits an IP-CAN session change end to the PCRF (step S40).

<1.4. TFT and SDF>
One of technologies for executing QoS control is TFT (Traffic Flow Template). Hereinafter, the TFT will be described with reference to FIG.

FIG. 12 is an explanatory diagram for explaining the TFT. As shown in FIG. 12, the TFT is arranged in the P-GW for communication in the downlink direction, and is arranged in the UE for communication in the uplink direction. This arrangement is used in order for the TFT to filter the IP flow flowing into the EPS in consideration of QoS.

The functions performed in the TFT include mapping an IP flow to an EPS bearer and QoS control. The QoS control here is a function such as limiting traffic within the set Maxbit rate. The IP flow mapped to the EPS bearer is controlled not only in the UE and P-GW but also in the eNodeB and S-GW with priority control corresponding to QoS. A TFT performs QoS control while mapping an IP flow to an EPS bearer that is a unit of QoS control performed in these various entities.

FIG. 13 is an explanatory diagram for explaining the TFT in more detail. As shown in FIG. 13, the TFT maps an IP flow to an SDF (Service Data Flow). At this time, the TFT responds to the IP flow based on the QoS control information provided from the PCRF, and the source address (Source address), destination address (Destination address), and port number of the IP packet. Map to (ie, desired) QoS SDF. The SDF is then mapped to the corresponding EPS bearer. The SDF and EPS bearer have a one-to-one mapping relationship. One SDF is associated with one EPS. However, a plurality of SDFs may be associated with the EPS bearer.

The TFT will be described in more detail. The TFT is composed of a plurality of SDF templates (Service Data Flow templates). The SDF template is created corresponding to QoS, but the same QoS may be set in a plurality of SDF templates. In that case, IP flows filtered by a plurality of SDF templates in which the same QoS is set are mapped to one EPS bearer. The SDF template also performs bearer mapping and the QoS control described above.

<< 2. Configuration example of each device >>
<2.1. Example of base station configuration>
First, the configuration of the base station 100 according to an embodiment of the present disclosure will be described with reference to FIG. FIG. 14 is a block diagram illustrating an exemplary configuration of the base station 100 according to an embodiment of the present disclosure. Referring to FIG. 14, the base station 100 includes an antenna unit 110, a wireless communication unit 120, a network communication unit 130, a storage unit 140, and a processing unit 150.

(1) Antenna unit 110
The antenna unit 110 radiates a signal output from the wireless communication unit 120 to the space as a radio wave. Further, the antenna unit 110 converts radio waves in space into a signal and outputs the signal to the wireless communication unit 120.

(2) Wireless communication unit 120
The wireless communication unit 120 transmits and receives signals. For example, the radio communication unit 120 transmits a downlink signal to the terminal device and receives an uplink signal from the terminal device.

(3) Network communication unit 130
The network communication unit 130 transmits and receives information. For example, the network communication unit 130 transmits information to other nodes and receives information from other nodes. For example, the other nodes include other base stations and core network nodes.

(4) Storage unit 140
The storage unit 140 temporarily or permanently stores a program for operating the base station 100 and various data.

(5) Processing unit 150
The processing unit 150 provides various functions of the base station 100. The processing unit 150 includes a bearer establishment unit 151 and a communication processing unit 153. The processing unit 150 may further include other components other than these components. That is, the processing unit 150 can perform operations other than the operations of these components.

The bearer establishment unit 151 performs processing for establishing an MEC bearer described later. The communication processing unit 153 performs processing for performing communication using the MEC bearer or the existing EPS bearer. The operations of the bearer establishment unit 151 and the communication processing unit 153 will be described in detail later.

<2.2. Configuration of terminal device>
Next, an example of a configuration of the terminal device 200 according to the embodiment of the present disclosure will be described with reference to FIG. FIG. 15 is a block diagram illustrating an exemplary configuration of the terminal device 200 according to an embodiment of the present disclosure. Referring to FIG. 15, the terminal device 200 includes an antenna unit 210, a wireless communication unit 220, a storage unit 230, and a processing unit 240.

(1) 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.

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

(3) Storage unit 230
The storage unit 230 temporarily or permanently stores a program for operating the terminal device 200 and various data.

(4) Processing unit 240
The processing unit 240 provides various functions of the terminal device 200. The processing unit 240 includes a bearer establishment unit 241 and a communication processing unit 243. Note that 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.

The bearer establishment unit 241 performs processing for establishing an MEC bearer described later. The communication processing unit 243 performs processing for performing communication using the MEC bearer or the existing EPS bearer. The operations of the bearer establishment unit 241 and the communication processing unit 243 will be described in detail later.

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

(1) Communication unit 310
The communication unit 310 is an interface for performing communication with other devices. For example, the communication unit 310 communicates with the associated device. For example, 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.

(2) Storage unit 320
The storage unit 320 temporarily or permanently stores a program for operating the MEC server 300 and various data. For example, the storage unit 320 may store various contents and applications provided to the user.

(3) Processing unit 330
The processing unit 330 provides various functions of the MEC server 300. The processing unit 330 includes a bearer establishment unit 331 and a communication processing unit 333. Note that 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 bearer establishment unit 331 performs processing for establishing an MEC bearer described later. The communication processing unit 333 performs processing for performing communication using the MEC bearer or the existing EPS bearer. The operations of the bearer establishment unit 331 and the communication processing unit 333 will be described in detail later.

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

<< 3. First Embodiment >>
<3.1. Technical issues>
In EPS, data provided to the UE is managed in units of bearers. One QoS is associated with one bearer. Therefore, if a different QoS is used, a different bearer is newly established. The bearer here is an EPS bearer. The three bearers that constitute the EPS bearer, that is, the S5 bearer, the S1 bearer, and the radio bearer have a one-to-one mapping relationship. In the existing architecture, the bearer passing through the MEC server is not included in the EPS bearer. As an example of a method for transmitting data to or from the MEC server, it is conceivable that the eNodeB or the like switches the destination of data transmitted by the EPS bearer to the MEC server. However, such a method has a great influence on the architecture of the EPS bearer, and is not an appropriate method. For example, when a data stream flows through a plurality of paths due to switching in the middle, the principle that an EPS bearer corresponds to one QoS breaks down, and it becomes difficult to associate a QoS with an EPS bearer.

Therefore, in this embodiment, a new EPS bearer that passes through the MEC server 300 is provided.

<3.2. Technical features>
(1) MEC bearer FIG. 17 is an explanatory diagram for describing a bearer newly defined in the present embodiment. As shown in FIG. 17, each entity (eNodeB 100, UE 200, MEC server 300, S-GW 41, and P-GW 42) included in the system 1 passes between the P-GW 42 and the UE 200 via the MEC server 300. Communication is performed using an established bearer (corresponding to a first EPS bearer). Further, each entity (eNodeB 100, UE 200, S-GW 41, and P-GW 42) included in the system 1 does not pass through the MEC server 300, but is a bearer (second EPS) established between the P-GW 42 and the UE 200. Communication using a bearer may be performed. Each entity performs communication by selectively using a new EPS bearer that passes through the MEC server 300 and an existing EPS bearer that does not pass through the MEC server 300. Currently, a bearer that does not pass through the MEC server 300 is referred to as an EPS bearer. Therefore, a bearer that passes through the MEC server 300 may not be referred to as an EPS bearer. Therefore, this new EPS bearer is also referred to as an MEC bearer. In contrast, an EPS bearer that does not pass through the MEC server 300 is also referred to as an existing EPS bearer.

The MEC bearer includes a bearer whose end is the MEC server 300. And the bearer which makes MEC server 300 an end is the 1st MEC bearer (MEC Bearer 1: equivalent to the 1st bearer) for communication with UE200, and the 2nd for communication with P-GW42. MEC bearers (MEC Bearer 2: equivalent to the second bearer). The MEC bearer includes both an uplink direction bearer, a downlink direction bearer. This is the same as the existing EPS bearer.

The IP packet carried by the bearer for input to the MEC server 300 is temporarily cached by the MEC server 300 and subjected to various processes. Then, at an arbitrary timing, the cached IP packet is carried by a bearer for output from the MEC server 300. Therefore, when a protocol that involves retransmission control by returning ACK / NACK such as TCP (Transmission Control Protocol) is used, inconvenience arises if the MEC server 300 is not an endpoint. This is because ACK / NACK is not returned while being cached. In this respect, since the MEC bearer is a bearer having the MEC server 300 as an end (that is, an end point), the bearer for the end-to-end service is separated into two. For this reason, the MEC server 300 according to the present embodiment can perform retransmission control by returning ACK / NACK.

FIG. 18 is an explanatory diagram for explaining the architecture of the MEC bearer. In FIG. 18, the eNodeB 100A through which the first MEC bearer passes and the eNodeB 100B through which the second MEC bearer passes are distinguished, but the same eNodeB 100 may actually be used. As illustrated in FIG. 18, each of the first MEC bearer and the second MEC bearer includes a bearer having both ends of the MEC server 300 and the eNodeB 100. A bearer having both ends of the MEC server 300 and the eNodeB 100A is referred to as an M1 bearer, and a bearer having both ends of the MEC server 300 and the eNodeB 100B is referred to as an M2 bearer. As shown in FIG. 18, the first MEC bearer includes a radio bearer and an M1 bearer. The second MEC bearer includes an M2 bearer, an S1 bearer, and an S5 bearer.

The MEC server 300 and the eNodeB 100A are connected by the M1 interface. Further, the MEC server 300 and the eNodeB 100B are connected by an M2 interface. Here, regarding the UL data flow, it is desirable that the bearer in the input direction to the MEC server 300 and the bearer in the output direction from the MEC server 300 are established. Similarly, regarding the DL data flow, it is desirable that the bearer in the input direction to the MEC server 300 and the bearer in the output direction from the MEC server 300 are established. In order to distinguish and establish these four types of bearers, it is desirable that the M1 bearer and the M2 bearer are established separately.

The S5 bearer, S1 bearer, M2 bearer, M1 bearer, and radio bearer constituting the MEC bearer have a one-to-one mapping relationship. However, in reality, whether or not the M1 bearer immediately transfers data to the M2 bearer depends on the upper application. That is, the bearer mapping itself is a one-to-one mapping, while whether or not the data flow is continuous in time depends on the application. In this regard, in the bearer architecture shown in FIG. 18, since the MEC bearer uses the MEC server 300 as an endpoint, it can be said that it can respond to various application requests.

(2) Bearer establishment procedure The MEC bearer is a dedicated bearer. The MEC bearer is individually established for each UE 200 in a form accompanying the default bearer. This is the same as that in the existing EPS bearer, a dedicated bearer is individually established for each UE 200 in a form accompanying the default bearer. That is, it can be said that the bearer architecture according to the present embodiment has little change from the existing architecture.

As shown in FIG. 11, the existing dedicated bearer is established from the back of the EPC (that is, the P-GW side) starting from the PCRF that controls QoS. This is because the newly established dedicated bearer is created based on the new QoS, so it is desirable for the PCRF to trigger. Actually, the PCRF newly establishes a dedicated bearer based on the QoS request from the application server, and the application server and the UE exchange at the application level. Therefore, it can be interpreted that a dedicated bearer is established starting from the UE.

In this regard, the M1 bearer and the M2 bearer may be established with a request to the eNodeB 100 as a trigger, or may be established with a request to the MEC server 300 as a trigger. Typically, it is desirable that the M1 bearer and the M2 bearer are established with a request to the eNodeB 100 as a trigger. This is because a plurality of MEC servers 300 may be connected to the eNodeB 100. Further, it is desirable that the M1 bearer and the M2 bearer are established by a single request to the eNodeB 100. Accordingly, an example of a procedure for establishing the M1 bearer and the M2 bearer by using a request from the MME 43 to the eNodeB 100 as a trigger will be described with reference to FIG.

FIG. 19 is a sequence diagram showing an example of a procedure for establishing an MEC bearer. In this sequence, the MEC server 300, UE 200, eNodeB 100, MME 43, S-GW 41, P-GW 42, and PCRF 44 are involved.

First, the PCRF 44 transmits an IP-CAN session change start to the P-GW 42 (step S102). Next, the P-GW 42 transmits an MEC bearer generation request to the S-GW 41 (step S104), and the S-GW 41 transmits the message to the MME 43 (step S106). Next, the MME 43 transmits an MEC bearer setup request to the eNodeB 100 (step S108), and the eNodeB 100 transmits the message to the MEC server 300 (step S110). At this timing, the M1 bearer and the M2 bearer are established. Next, the MEC server 300 transmits an MEC bearer setup response to the eNodeB 100 (step S112). Next, the eNodeB 100 transmits RRC connection reconfiguration to the UE 200 (step S114). At this timing, a radio bearer is established, and a first MEC bearer is established accordingly. As described above, the first MEC bearer is established by establishing the radio bearer having both the eNodeB 100 and the UE 200 as both ends after the M1 bearer is established. Next, the UE 200 transmits RRC connection reconfiguration completion to the eNodeB 100 (step S116), and the eNodeB 100 transmits an MEC bearer setup response to the MME 43 (step S118). Next, the MME 43 transmits a MEC bearer generation response to the S-GW 41 (step S120), and the S-GW 41 transmits the message to the P-GW 42 (step S122). Next, the P-GW 42 transmits an IP-CAN session change end to the PCRF 44 (step S124).

On the other hand, it may be desirable to establish the M1 bearer and the M2 bearer by using a request to the MEC server 300 as a trigger. For example, the MEC server 300 is connected to a plurality of eNodeBs 100. This is because the aspect that the eNodeB 100 manages the MEC server 300 is thinned. Accordingly, an example of a procedure for establishing the M1 bearer and the M2 bearer by using a request from the MME 43 to the MEC server 300 as a trigger will be described with reference to FIG.

FIG. 20 is a sequence diagram showing an example of a procedure for establishing an MEC bearer. In this sequence, the MEC server 300, UE 200, eNodeB 100, MME 43, S-GW 41, P-GW 42, and PCRF 44 are involved.

First, the PCRF 44 transmits an IP-CAN session change start to the P-GW 42 (step S202). Next, the P-GW 42 transmits an MEC bearer generation request to the S-GW 41 (step S204), and the S-GW 41 transmits the message to the MME 43 (step S206). Next, the MME 43 transmits an MEC bearer setup request to the MEC server 300 (step S208). At this timing, the M1 bearer and the M2 bearer are established. Next, the MEC server 300 transmits an MEC bearer setup response to the MME 43 (step S210). Next, the MME 43 transmits an MEC bearer setup request to the eNodeB 100 (step S212), and the eNodeB 100 transmits RRC connection reconfiguration to the UE 200 (step S214). At this timing, a radio bearer is established, and a first MEC bearer is established accordingly. Next, the UE 200 transmits RRC connection reconfiguration completion to the eNodeB 100 (step S216), and the eNodeB 100 transmits an MEC bearer setup response to the MME 43 (step S218). Next, the MME 43 transmits a MEC bearer generation response to the S-GW 41 (step S220), and the S-GW 41 transmits the message to the P-GW 42 (step S222). Next, the P-GW 42 transmits an IP-CAN session change end to the PCRF 44 (step S224).

<< 4. Second Embodiment >>
<4.1. Technical issues>
According to the first embodiment, the MEC bearer is defined. However, it is difficult to use this MEC bearer effectively in the existing TFT that performs bearer mapping. Specifically, referring to FIG. 12, the existing TFT only maps the IP flow to the EPS bearer so as to satisfy QoS, and does not have a function of mapping to the MEC bearer.

Therefore, in this embodiment, an architecture capable of mapping an IP flow to an MEC bearer is provided.

<4.2. Technical features>
As described above in the first embodiment, each entity of the system 1 communicates selectively using a new EPS bearer that passes through the MEC server 300 and an existing EPS bearer that does not pass through the MEC server 300. I do. Switching between the MEC bearer and the existing EPS bearer can be performed by the UE 200 or the filter of the P-GW 42. This filter is typically a TFT.

The TFT maps the user traffic addressed to the MEC server 300 to the SDF corresponding to the MEC bearer. In addition, the TFT maps user traffic addressed to other devices (for example, UE 200 or P-GW 42) to an SDF corresponding to an existing EPS bearer. As a result, switching between the MEC bearer and the existing EPS bearer becomes possible. Hereinafter, this point will be described in detail with reference to FIG.

FIG. 21 is an explanatory diagram for explaining bearer mapping by the TFT according to the present embodiment. As shown in FIG. 21, the TFT maps the IP flow to either the SDF corresponding to the existing EPS bearer or the SDF corresponding to the MEC bearer. This switching is performed based on, for example, the transmission source address, transmission destination address, and port number of the IP packet. Note that the TFT controls which SDF to map to among the plurality of SDFs corresponding to the existing EPS bearer based on the information for QoS control provided from the PCRF. The same applies to the MEC bearer.

The MEC server 300 can be used as a cache server. And as an example of the use of the MEC server 300 used as a cache server, the use which caches the same data as the user traffic which passes eNodeB100 is mentioned. In that case, the TFT of the P-GW 42 or the UE 200 maps the copied user traffic to one of the MEC bearer or the existing EPS bearer and maps the original traffic to the other. As a result, the same DL data flow can be transmitted from the P-GW 42 to the UE 200 and cached in the MEC server 300. Also, the same UL data flow can be transmitted from the UE 200 to the P-GW 42 and cached in the MEC server 300. Hereinafter, an example of user traffic copy processing will be described with reference to FIGS. 22 and 23.

FIG. 22 is an explanatory diagram for explaining an example of a user traffic copy process. As shown in FIG. 22, the TFT copies and maps the input original user traffic. In the example shown in FIG. 22, the TFT maps the copied IP flow to the MEC bearer, and maps the original IP flow to the existing EPS bearer. For example, the TFT maps the original IP flow to the existing EPS bearer, and copies and maps the original IP flow to the MEC bearer only when information indicating that it should be cached is input. With such a mechanism, the influence on the existing EPS bearer is minimized. Note that the TFT controls which SDF to map to among the plurality of SDFs corresponding to the existing EPS bearer based on the information for QoS control provided from the PCRF. The same applies to the MEC bearer.

FIG. 23 is an explanatory diagram for explaining an example of a user traffic copy process. As shown in FIG. 23, the TFT may map the input original user traffic and the input copied user traffic. That is, copying may be performed before the TFT. For example, the original IP flow is copied and input to the TFT only when information indicating that it should be cached is input, and otherwise, the original IP flow may not be copied. Then, the TFT may map the IP flow to an existing EPS bearer, and if a copied IP flow is input, it may map it to the MEC bearer. Note that the TFT controls which SDF to map to among the plurality of SDFs corresponding to the existing EPS bearer based on the information for QoS control provided from the PCRF. The same applies to the MEC bearer.

In the copy process given as an example, the IP packet is copied inside the P-GW 42 or the UE 200. At that time, the P-GW 42 or the UE 200 rewrites the destination address information (IP address, port number, etc.) of the copied user traffic to the MEC server 300. Since the P-GW 42 and the UE 200 are not completely included in the EPS like the S-GW 41 and the eNodeB 100, the IP address and the like can be rewritten, and the transmission destination can be switched by the rewriting.

Of course, the P-GW 42 or the UE 200 can control whether or not to perform the copy process. For example, the P-GW 42 or the UE 200 performs a copy process when caching in parallel with the transmission of user traffic, and maps the user traffic to an existing EPS bearer without performing the copy process when the cache is unnecessary. Further, when pre-cache, the P-GW 42 or the UE 200 maps user traffic to the MEC bearer without performing a copy process. As an application of the pre-cache, for example, data related to data being downloaded by the UE 200 is cached in advance.

<< 5. Third Embodiment >>
<5.1. Technical issues>
In each of the above embodiments, the example in which the MEC server 300 is provided in the eNodeB 100 has been described, but the present technology is not limited to such an example.

For example, the MEC server 300 may be provided in an arbitrary device such as the S-GW 41. In that case, what is necessary is just to read eNodeB100 in description of each said embodiment into the apparatus with which the MEC server 300 is provided.

In addition, the MEC server 300 may be provided between entities. Hereinafter, as an example of such a case, a case where the MEC server 300 is provided between the eNodeB 100 and the S-GW 41 will be described. Of course, this arrangement is an example, and the MEC server 300 may be provided between arbitrary entities.

<5.2. Technical features>
(1) MEC bearer The present embodiment has the same technical features as the first and second embodiments. For example, each entity included in the system 1 performs communication using the bearer established between the P-GW 42 and the UE 200 via the MEC server 300. The MEC bearer includes a bearer whose end is the MEC server 300, more specifically, a first MEC bearer for communication with the UE 200, and a second MEC bearer for communication with the P-GW 42. Therefore, in the following, description of technical features similar to those of the first and second embodiments will be omitted, and technical features unique to the present embodiment will be mainly described. First, the architecture of the MEC bearer according to the present embodiment will be described with reference to FIG.

FIG. 24 is an explanatory diagram for explaining the architecture of the MEC bearer. As shown in FIG. 24, the first MEC bearer includes M1 bearers having both ends of the MEC server 300 and the eNodeB 100. The second MEC bearer includes S1 bearers having both ends of the MEC server 300 and the S-GW 41. As shown in FIG. 24, the first MEC bearer includes a radio bearer and an M1 bearer. The second MEC bearer includes an S1 bearer and an S5 bearer. As described above with reference to FIG. 12, in the existing bearer architecture, the bearer having both ends of the eNodeB 100 and the S-GW 41 is the S1 bearer. In this embodiment, the MEC server 300 and the S-GW 41 are connected. The bearer at both ends is the S1 bearer. Accordingly, it can be said that the architecture of the present embodiment is little changed from the existing architecture when the eNodeB 100 and the MEC server 300 are regarded as one body.

Also in the present embodiment, each entity included in the system 1 performs communication by selectively using an MEC bearer that passes through the MEC server 300 and an existing EPS bearer that does not pass through the MEC server 300. However, in the architecture shown in FIG. 24, all IP flows pass through the MEC server 300 regardless of whether they are cached in the MEC server 300 or not. As shown in FIG. 24, in the MEC bearer, the S-GW 41 and the eNodeB 100 are separated by the S1 bearer having both ends of the S-GW 41 and the MEC server 300 and the M1 bearer having both ends of the MEC server 300 and the eNodeB 100. Connected. Since the MEC server 300 serves as an endpoint, the MEC server 300 can cache and transfer the IP flow while performing retransmission control and the like. On the other hand, as shown in FIG. 12, in the existing EPS bearer, the S-GW 41 and the eNodeB 100 are connected by the S1 bearer having the S-GW 41 and the eNodeB 100 at both ends. Since the MEC server 300 does not become an endpoint, the IP flow passes through the MEC server 300.

The architecture shown in FIG. 24 is simpler than the architecture shown in FIG. On the other hand, the architecture shown in FIG. 24 requires that the MEC server 300 has a function related to the S1 bearer.

As an example of another architecture, it is also possible to arrange the MEC server 300 between the eNodeB 100 and the UE 200. In that case, since it is necessary to mount various wireless access functions in the MEC server 300, it is difficult to say that this is a desirable architecture. As another example, the MEC server 300 may be arranged between the S-GW 41 and the P-GW 42. In that case, the distance between the UE 200 and the MEC server 300 becomes longer (more precisely, the number of entities existing between them increases), and it is difficult to achieve the initial purpose such as quick provision of content by introducing the MEC. Therefore, it is difficult to say that this is a desirable architecture. From these facts, it can be said that the architecture shown in FIGS. 18 and 24 is appropriate.

(2) Bearer establishment procedure FIG. 25 is a sequence diagram showing an example of an MEC bearer establishment procedure. In this sequence, UE 200, eNodeB 100, MEC server 300, MME 43, S-GW 41, P-GW 42, and PCRF 44 are involved.

First, the PCRF 44 transmits an IP-CAN session change start to the P-GW 42 (step S302). Next, the P-GW 42 transmits an MEC bearer generation request to the S-GW 41 (step S304), and the S-GW 41 transmits the message to the MME 43 (step S306). Next, the MME 43 transmits an MEC bearer setup request to the MEC server 300 (step S308), and the MEC server 300 transmits the message to the eNodeB 100 (step S310). At this timing, an M1 bearer is established. Next, the eNodeB 100 transmits RRC connection reconfiguration to the UE 200 (step S312). At this timing, a radio bearer is established, and a first MEC bearer is established accordingly. Next, the UE 200 transmits RRC connection reconfiguration completion to the eNodeB 100 (step S314). Next, the eNodeB 100 transmits an MEC bearer setup response to the MEC server 300 (step S316), and the MEC server 300 transmits the message to the MME 43 (step S318). Next, the MME 43 transmits an MEC bearer generation response to the S-GW 41 (step S320), and the S-GW 41 transmits the message to the P-GW 42 (step S322). Next, the P-GW 42 transmits an IP-CAN session change end to the PCRF 44 (step S324).

<< 6. Application example >>
The technology according to the present disclosure can be applied to various products. For example, the MEC server 300 may be realized as any type of server such as a tower server, a rack server, or a blade server. Further, at least a part of the components of the MEC server 300 is realized in a module (for example, an integrated circuit module configured by one die or a card or a blade inserted in a slot of the blade server) mounted on the server. May be.

Further, for example, the base station 100 may be realized as any type of eNB (evolved Node B) such as a macro eNB or a small eNB. The small eNB may be an eNB that covers a cell smaller than a macro cell, such as a pico eNB, a micro eNB, or a home (femto) eNB. Instead, the base station 100 may be realized as another type of base station such as a NodeB or a BTS (Base Transceiver Station). The base station 100 may include a main body (also referred to as a base station apparatus) that controls wireless communication, and one or more RRHs (Remote Radio Heads) that are arranged at locations different from the main body. Further, various types of terminals described later may operate as the base station 100 by temporarily or semi-permanently executing the base station function. Furthermore, at least some components of the base station 100 may be realized in a base station apparatus or a module for the base station apparatus.

Further, for example, 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. Furthermore, at least some 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.

<6.1. Application examples regarding the MEC server 300>
FIG. 26 is a block diagram illustrating an example of a schematic configuration of a server 700 to which the technology according to the present disclosure can 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.

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).

In the server 700 shown in FIG. 26, one or more components (bearer establishment unit 331 and / or communication processing unit 333) included in the processing unit 330 described with reference to FIG. Also good. As an example, a program for causing a 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) is installed in the server 700, and the processor 701 is The program may be executed. As another example, 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. In this case, 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. As described above, 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. . In addition, a readable recording medium in which the program is recorded may be provided.

In the server 700 shown in FIG. 26, the communication unit 310 described with reference to FIG. 16 may be implemented in the network interface 704. Further, the storage unit 320 may be implemented in the memory 702 or the storage 703.

<6.2. Application examples for base stations>
(First application example)
FIG. 27 is a block diagram illustrating a first example of a schematic configuration of an eNB to which the technology according to the present disclosure may be applied. The eNB 800 includes one or more antennas 810 and a base station device 820. Each antenna 810 and the base station apparatus 820 can be connected to each other via an RF cable.

Each of the antennas 810 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 and reception of radio signals by the base station apparatus 820. The eNB 800 includes a plurality of antennas 810 as illustrated in FIG. 27, and the plurality of antennas 810 may respectively correspond to a plurality of frequency bands used by the eNB 800, for example. Note that although FIG. 27 illustrates an example in which the eNB 800 includes a plurality of antennas 810, the eNB 800 may include a single antenna 810.

The base station apparatus 820 includes a controller 821, a memory 822, a network interface 823, and a wireless communication interface 825.

The controller 821 may be a CPU or a DSP, for example, and operates various functions of the upper layer of the base station apparatus 820. For example, the controller 821 generates a data packet from the data in the signal processed by the wireless communication interface 825, and transfers the generated packet via the network interface 823. The controller 821 may generate a bundled packet by bundling data from a plurality of baseband processors, and may transfer the generated bundled packet. In addition, the controller 821 is a logic that executes control such as radio resource control, radio bearer control, mobility management, inflow control, or scheduling. May have a typical function. Moreover, the said control may be performed in cooperation with a surrounding eNB or a core network node. The memory 822 includes RAM and ROM, and stores programs executed by the controller 821 and various control data (for example, terminal list, transmission power data, scheduling data, and the like).

The network interface 823 is a communication interface for connecting the base station device 820 to the core network 824. The controller 821 may communicate with the core network node or other eNB via the network interface 823. In that case, the eNB 800 and the core network node or another eNB may be connected to each other by a logical interface (for example, an S1 interface or an X2 interface). The network interface 823 may be a wired communication interface or a wireless communication interface for wireless backhaul. When the network interface 823 is a wireless communication interface, the network interface 823 may use a frequency band higher than the frequency band used by the wireless communication interface 825 for wireless communication.

The wireless communication interface 825 supports any cellular communication scheme such as LTE (Long Term Evolution) or LTE-Advanced, and provides a wireless connection to terminals located in the cell of the eNB 800 via the antenna 810. The wireless communication interface 825 may typically include a baseband (BB) processor 826, an RF circuit 827, and the like. The BB processor 826 may perform, for example, encoding / decoding, modulation / demodulation, and multiplexing / demultiplexing, and each layer (for example, L1, MAC (Medium Access Control), RLC (Radio Link Control), and PDCP). Various signal processing of (Packet Data Convergence Protocol) is executed. The BB processor 826 may have some or all of the logical functions described above instead of the controller 821. The BB processor 826 may be a module that includes a memory that stores a communication control program, a processor that executes the program, and related circuits. The function of the BB processor 826 may be changed by updating the program. Good. Further, the module may be a card or a blade inserted into a slot of the base station apparatus 820, or a chip mounted on the card or the blade. On the other hand, the RF circuit 827 may include a mixer, a filter, an amplifier, and the like, and transmits and receives a radio signal via the antenna 810.

The wireless communication interface 825 includes a plurality of BB processors 826 as shown in FIG. 27, and the plurality of BB processors 826 may correspond to a plurality of frequency bands used by the eNB 800, for example. In addition, the wireless communication interface 825 includes a plurality of RF circuits 827 as shown in FIG. 27, and the plurality of RF circuits 827 may correspond to, for example, a plurality of antenna elements, respectively. 27 shows an example in which the wireless communication interface 825 includes a plurality of BB processors 826 and a plurality of RF circuits 827, the wireless communication interface 825 includes a single BB processor 826 or a single RF circuit 827. But you can.

In the eNB 800 illustrated in FIG. 27, one or more components (bearer establishment unit 151 and / or communication processing unit 153) included in the processing unit 150 described with reference to FIG. 14 are implemented in the wireless communication interface 825. May be. Alternatively, at least some of these components may be implemented in the controller 821. As an example, the eNB 800 includes a module including a part (for example, the BB processor 826) or all of the wireless communication interface 825 and / or the controller 821, and the one or more components are mounted in the module. Good. In this case, 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. As another example, a program for causing a processor to function as the one or more components is installed in the eNB 800, and the radio communication interface 825 (eg, the BB processor 826) and / or the controller 821 executes the program. Good. As described above, the eNB 800, the base station apparatus 820, 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 is provided. May be. In addition, a readable recording medium in which the program is recorded may be provided.

27, the radio communication unit 120 described with reference to FIG. 14 may be implemented in the radio communication interface 825 (for example, the RF circuit 827) in the eNB 800 illustrated in FIG. Further, the antenna unit 110 may be mounted on the antenna 810. The network communication unit 130 may be implemented in the controller 821 and / or the network interface 823. In addition, the storage unit 140 may be implemented in the memory 822.

(Second application example)
FIG. 28 is a block diagram illustrating a second example of a schematic configuration of an eNB to which the technology according to the present disclosure may be applied. The eNB 830 includes one or more antennas 840, a base station apparatus 850, and an RRH 860. Each antenna 840 and RRH 860 may be connected to each other via an RF cable. Base station apparatus 850 and RRH 860 can be connected to each other via a high-speed line such as an optical fiber cable.

Each of the antennas 840 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 radio signals by the RRH 860. The eNB 830 includes a plurality of antennas 840 as illustrated in FIG. 28, and the plurality of antennas 840 may respectively correspond to a plurality of frequency bands used by the eNB 830, for example. Note that although FIG. 28 illustrates an example in which the eNB 830 includes a plurality of antennas 840, the eNB 830 may include a single antenna 840.

The base station device 850 includes a controller 851, a memory 852, a network interface 853, a wireless communication interface 855, and a connection interface 857. The controller 851, the memory 852, and the network interface 853 are the same as the controller 821, the memory 822, and the network interface 823 described with reference to FIG.

The wireless communication interface 855 supports a cellular communication method such as LTE or LTE-Advanced, and provides a wireless connection to a terminal located in a sector corresponding to the RRH 860 via the RRH 860 and the antenna 840. The wireless communication interface 855 may typically include a BB processor 856 and the like. The BB processor 856 is the same as the BB processor 826 described with reference to FIG. 27 except that the BB processor 856 is connected to the RF circuit 864 of the RRH 860 via the connection interface 857. The wireless communication interface 855 includes a plurality of BB processors 856 as illustrated in FIG. 28, and the plurality of BB processors 856 may respectively correspond to a plurality of frequency bands used by the eNB 830, for example. 28 shows an example in which the wireless communication interface 855 includes a plurality of BB processors 856, the wireless communication interface 855 may include a single BB processor 856.

The connection interface 857 is an interface for connecting the base station device 850 (wireless communication interface 855) to the RRH 860. The connection interface 857 may be a communication module for communication on the high-speed line that connects the base station apparatus 850 (wireless communication interface 855) and the RRH 860.

In addition, the RRH 860 includes a connection interface 861 and a wireless communication interface 863.

The connection interface 861 is an interface for connecting the RRH 860 (wireless communication interface 863) to the base station device 850. The connection interface 861 may be a communication module for communication on the high-speed line.

The wireless communication interface 863 transmits and receives wireless signals via the antenna 840. The wireless communication interface 863 may typically include an RF circuit 864 and the like. The RF circuit 864 may include a mixer, a filter, an amplifier, and the like, and transmits and receives wireless signals via the antenna 840. The wireless communication interface 863 includes a plurality of RF circuits 864 as illustrated in FIG. 28, and the plurality of RF circuits 864 may correspond to, for example, a plurality of antenna elements, respectively. 28 illustrates an example in which the wireless communication interface 863 includes a plurality of RF circuits 864, the wireless communication interface 863 may include a single RF circuit 864.

In the eNB 830 illustrated in FIG. 28, one or more components (bearer establishment unit 151 and / or communication processing unit 153) included in the processing unit 150 described with reference to FIG. 14 include the wireless communication interface 855 and / or The wireless communication interface 863 may be implemented. Alternatively, at least some of these components may be implemented in the controller 851. As an example, the eNB 830 includes a module including a part (for example, the BB processor 856) or the whole of the wireless communication interface 855 and / or the controller 851, and the one or more components are mounted in the module. Good. In this case, 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. As another example, a program for causing a processor to function as the one or more components is installed in the eNB 830, and the wireless communication interface 855 (eg, the BB processor 856) and / or the controller 851 executes the program. Good. As described above, the eNB 830, the base station apparatus 850, 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 is provided. May be. In addition, a readable recording medium in which the program is recorded may be provided.

28, for example, the wireless communication unit 120 described with reference to FIG. 14 may be implemented in the wireless communication interface 863 (for example, the RF circuit 864). The antenna unit 110 may be mounted on the antenna 840. The network communication unit 130 may be implemented in the controller 851 and / or the network interface 853. The storage unit 140 may be mounted in the memory 852.

<6.3. Application examples related to terminal devices>
(First application example)
FIG. 29 is a block diagram illustrating an example of a schematic configuration of a smartphone 900 to which the technology according to the present disclosure can 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. On the other hand, 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. 29 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.

Furthermore, 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. In that case, 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. 29 illustrates an example in which the smartphone 900 includes a plurality of antennas 916, the smartphone 900 may include a single antenna 916.

Furthermore, the smartphone 900 may include an antenna 916 for each wireless communication method. In that case, 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. 29 via a power supply line partially shown by a broken line in the drawing. For example, the auxiliary controller 919 operates the minimum necessary functions of the smartphone 900 in the sleep mode.

In the smartphone 900 shown in FIG. 29, one or more components (bearer establishment unit 241 and / or communication processing unit 243) included in the processing unit 240 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. In this case, 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. As another example, 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. As described above, 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. In addition, a readable recording medium in which the program is recorded may be provided.

29, for example, the wireless communication unit 220 described with reference to FIG. 15 may be implemented in the wireless communication interface 912 (for example, the RF circuit 914). The antenna unit 210 may be mounted on the antenna 916. The storage unit 230 may be mounted in the memory 902.

(Second application example)
FIG. 30 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. On the other hand, 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. 30 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.

Further, 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. Note that FIG. 30 illustrates an example in which the car navigation apparatus 920 includes a plurality of antennas 937, but the car navigation apparatus 920 may include a single antenna 937.

Furthermore, the car navigation device 920 may include an antenna 937 for each wireless communication method. In that case, 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. 30 through a power supply line partially shown by broken lines in the drawing. Further, the battery 938 stores electric power supplied from the vehicle side.

In the car navigation device 920 shown in FIG. 30, one or more components (bearer establishment unit 241 and / or communication processing unit 243) included in the processing unit 240 described with reference to FIG. May be implemented. Alternatively, at least some of these components may be implemented in the processor 921. As an example, 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. In this case, 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. As another example, 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. May be. As described above, 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. In addition, a readable recording medium in which the program is recorded may be provided.

Further, in the car navigation device 920 shown in FIG. 30, for example, the wireless communication unit 220 described with reference to FIG. 15 may be implemented in the wireless communication interface 933 (for example, the RF circuit 935). The antenna unit 210 may be mounted on the antenna 937. Further, the storage unit 230 may be implemented in the memory 922.

Also, 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 bearer establishment 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.

<< 7. Summary >>
The embodiment of the present disclosure has been described in detail above with reference to FIGS. As described above, each entity (eNodeB 100, UE 200, MEC server 300, S-GW 41, and P-GW 42) included in the system 1 provides content to the UE 200 or acquires content from the UE 200. Communication using the MEC bearer established between the P-GW 42 and the UE 200 via the MEC server 300 to be performed. Each entity can transmit an IP flow to the MEC server 300 or transfer an IP flow from the MEC server 300 by using the MEC bearer.

Further, switching between the existing EPS bearer and the MEC bearer is performed by the UE 200 or the TFT of the P-GW 42. Therefore, it is possible to realize the MEC bearer while maintaining the existing EPS bearer architecture.

The preferred embodiments of the present disclosure have been described in detail above with reference to the accompanying drawings, but the technical scope of the present disclosure is not limited to such examples. It is obvious that a person having ordinary knowledge in the technical field of the present disclosure can come up with various changes or modifications within the scope of the technical idea described in the claims. Of course, it is understood that it belongs to the technical scope of the present disclosure.

In addition, the processes described using the flowcharts and sequence diagrams in this specification do not necessarily have to be executed in the order shown. Some processing steps may be performed in parallel. Further, additional processing steps may be employed, and some processing steps may be omitted.

In addition, the effects described in this specification are merely illustrative or illustrative, and are not limited. That is, the technology according to the present disclosure can exhibit other effects that are apparent to those skilled in the art from the description of the present specification in addition to or instead of the above effects.

The following configurations also belong to the technical scope of the present disclosure.
(1)
First established between a P-GW (Packet Data Network Gateway) and the terminal device via an application server provided in the EPS and providing content to the terminal device or acquiring content from the terminal device A processing unit that performs communication using the EPS bearer,
A device comprising:
(2)
The apparatus according to (1), wherein the first EPS bearer includes a bearer whose end is the application server.
(3)
The bearer whose end is the application server includes a first bearer for communication with the terminal device and a second bearer for communication with the P-GW. apparatus.
(4)
The apparatus according to (3), wherein each of the first bearer and the second bearer includes a bearer having both ends of the application server and a base station.
(5)
The first bearer is established by establishing a bearer having both ends of the base station and the terminal device after a bearer having both ends of the application server and the base station is established. The apparatus as described in 4).
(6)
The apparatus according to (4) or (5), wherein a bearer having both ends of the application server and the base station is established by using a request to the base station as a trigger.
(7)
The apparatus according to (4) or (5), wherein a bearer having both ends of the application server and the base station is established with a request to the application server as a trigger.
(8)
The first bearer includes a bearer having both ends of the application server and a base station, and the second bearer includes a bearer having both ends of the application server and an S-GW (Serving Gateway). ) Device.
(9)
The apparatus according to any one of (1) to (8), wherein the first EPS bearer is a dedicated bearer.
(10)
The device according to (9), wherein the first EPS bearer is individually established for each terminal device.
(11)
The processing unit performs communication using the second EPS bearer established between the P-GW and the terminal device without passing through the application server,
The device according to any one of (1) to (10), wherein switching between using the first or second EPS bearer is performed by the terminal device or the filter of the P-GW. .
(12)
The filter maps user traffic addressed to the application server to an SDF (Service Data Flow) corresponding to the first EPS bearer, and maps user traffic addressed to another device to an SDF corresponding to the second EPS bearer. The apparatus according to (11) above.
(13)
The apparatus according to (11) or (12), wherein the filter maps the copied user traffic to one of the first or second EPS bearer and maps the original user traffic to the other.
(14)
The apparatus according to (13), wherein the filter maps copied user traffic to the first EPS bearer and maps original user traffic to the second EPS bearer.
(15)
The apparatus according to (13) or (14), wherein the processing unit rewrites destination address information of the copied user traffic to the application server.
(16)
The apparatus according to any one of (13) to (15), wherein the filter copies and maps input original user traffic.
(17)
The apparatus according to any one of (13) to (15), wherein the filter maps input original user traffic and input copied user traffic.
(18)
The apparatus according to any one of (11) to (17), wherein the filter is a TFT (Traffic Flow Templates).
(19)
First established between a P-GW (Packet Data Network Gateway) and the terminal device via an application server provided in the EPS and providing content to the terminal device or acquiring content from the terminal device Communication using the EPS bearer of the processor,
Including methods.
(20)
Computer
First established between a P-GW (Packet Data Network Gateway) and the terminal device via an application server provided in the EPS and providing content to the terminal device or acquiring content from the terminal device A processing unit that performs communication using the EPS bearer,
Program to function as.

1 System 40 Core Network 50 Packet Data Network 60 Application Server 100 Wireless Communication Device, Base Station, eNodeB
DESCRIPTION OF SYMBOLS 110 Antenna part 120 Wireless communication part 130 Network communication part 140 Storage part 150 Processing part 151 Bearer establishment part 153 Communication processing part 200 Terminal device, UE
210 Antenna unit 220 Wireless communication unit 230 Storage unit 240 Processing unit 241 Bearer establishment unit 243 Communication processing unit 300 MEC server 310 Communication unit 320 Storage unit 330 Processing unit 331 Bearer establishment unit 333 Communication processing unit

Claims

First established between a P-GW (Packet Data Network Gateway) and the terminal device via an application server provided in the EPS and providing content to the terminal device or acquiring content from the terminal device A processing unit that performs communication using the EPS bearer,
A device comprising:
The apparatus according to claim 1, wherein the first EPS bearer includes a bearer whose end is the application server.
The apparatus according to claim 2, wherein the bearer whose end is the application server includes a first bearer for communication with the terminal apparatus and a second bearer for communication with the P-GW. .
The apparatus according to claim 3, wherein each of the first bearer and the second bearer includes a bearer having both ends of the application server and a base station.
The first bearer is established by establishing a bearer having both ends of the base station and the terminal device after a bearer having both ends of the application server and the base station is established. 4. The apparatus according to 4.
The apparatus according to claim 4, wherein a bearer having both ends of the application server and the base station is established with a request to the base station as a trigger.
The apparatus according to claim 4, wherein a bearer having both ends of the application server and the base station is established with a request to the application server as a trigger.
The first bearer includes a bearer having both ends of the application server and a base station, and the second bearer includes a bearer having both ends of the application server and an S-GW (Serving Gateway). The device described in 1.
The apparatus according to claim 1, wherein the first EPS bearer is a dedicated bearer.
The apparatus according to claim 9, wherein the first EPS bearer is individually established for each terminal apparatus.
The processing unit performs communication using the second EPS bearer established between the P-GW and the terminal device without passing through the application server,
The apparatus according to claim 1, wherein switching between using the first EPS bearer or the second EPS bearer is performed by the terminal apparatus or the P-GW filter.
The filter maps user traffic addressed to the application server to an SDF (Service Data Flow) corresponding to the first EPS bearer, and maps user traffic addressed to another device to an SDF corresponding to the second EPS bearer. The apparatus of claim 11.
12. The apparatus of claim 11, wherein the filter maps the copied user traffic to one of the first or second EPS bearers and maps the original user traffic to the other.
The apparatus according to claim 13, wherein the filter maps copied user traffic to the first EPS bearer and maps original user traffic to the second EPS bearer.
The apparatus according to claim 13, wherein the processing unit rewrites destination address information of the copied user traffic to the application server.
The apparatus according to claim 13, wherein the filter copies and maps the input original user traffic.
14. The apparatus of claim 13, wherein the filter maps input original user traffic and input copied user traffic.
The apparatus according to claim 11, wherein the filter is a TFT (Traffic Flow Templates).
First established between a P-GW (Packet Data Network Gateway) and the terminal device via an application server provided in the EPS and providing content to the terminal device or acquiring content from the terminal device Communication using the EPS bearer of the processor,
Including methods.
Computer
First established between a P-GW (Packet Data Network Gateway) and the terminal device via an application server provided in the EPS and providing content to the terminal device or acquiring content from the terminal device A processing unit that performs communication using the EPS bearer,
Program to function as.