JP6561632B2 - Edge server and method thereof - Google Patents

Description

  The present disclosure relates to mobile communication networks, and more particularly to an apparatus and method for mobile edge computing.

  European Telecommunications Standards Institute (ETSI) has started standardization of Mobile Edge Computing (MEC) (see Non-Patent Document 1). MEC provides application developers and content providers with cloud computing capabilities within the Radio Access Network (RAN) close to mobile subscribers and Provides information technology (IT) service environment. This environment provides ultra-low latency and high bandwidth, as well as wireless network information that can be leveraged by applications and services (subscriber location, cell load, etc.) Provide direct access to.

  The MEC server is arranged in an integrated manner with the RAN node. Specifically, the MEC server can be located in a Long Term Evolution (LTE) base station (eNodeB) site, a 3G Radio Network Controller (RNC) site, or a multi-technology cell aggregation site. A multi-technology cell aggregation site may be located within an enterprises (eg, hospitals, large corporate headquarters) to control a number of local multi-technology access points. It may be placed indoors / outdoors in public buildings or arenas (eg, shopping malls, stadiums).

  The MEC server provides access to computing resources, storage capacity, connectivity, and user traffic and wireless network information. More specifically, the MEC server provides a hosting environment for an application by providing an Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) facility.

  Non-Patent Document 1 shows some examples of MEC use cases. In one use case (Active Device Location Tracking), the location information (geo-location) application hosted on the MEC server tracks the location of the wireless terminal using the wireless network measurement results received from the eNodeB / RNC. The location information of the wireless terminal is transmitted to the central server. This makes it possible to provide a position-based service without using the Global Positioning System (GPS).

  In one use case (Intelligent Video Analytics), a video analysis application hosted on the MEC server receives a live video stream from a wireless terminal and triggers events (eg, object movement, abandoned) Parsing live video streams to detect parcels, missing objects, etc.) and sending low bandwidth video metadata to the central server for database searching.

  In one use case (Augmented Reality Content Delivery), an application hosted on the MEC server analyzes an object in a video shot by the built-in camera of the wireless terminal and stores it in the AR data cache of the MEC server. Send AR content to the wireless terminal. This solution can minimize round-trip times and improve quality of experience (QoE).

  In one use case (RAN-aware & Application-aware Content Optimization), an application hosted on the MEC server receives radio information (eg, cell load, link quality) of a cell or a wireless terminal from the eNodeB / RNC. This information is sent to the central server (content optimizer) for content optimization. Such dynamic content optimization can facilitate video delivery through improved video quality such as reduced video stalling and reduced time-to-start.

“Mobile-edge Computing Introductory Technical White Paper”, the European Telecommunications Standards Institute, September 2014, [retrieved on 2015-06-24], Retrieved from the Internet: <URL: https://portal.etsi.org/Portals/ 0 / TBpages / MEC / Docs / Mobile-edge_Computing _-_ Introductory_Technical_White_Paper_V1% 2018-09-14.pdf>

  The inventors of the present case have found some problems related to MEC, particularly problems related to delay (latency). As described above, MEC is expected to contribute to the reduction in delay of applications and services directed to wireless terminals, thereby contributing to improvement of user QoE. However, for example, in a situation where many wireless terminals are connected to the RAN, the RAN may not be able to satisfy the delay requirement required by the wireless terminals using or related to the MEC.

  In order to solve this problem, with regard to radio resource management (Radio Resource Management: RRM) or scheduling in the RAN, special considerations for radio terminals using or related to the MEC are given from the MEC server to the RAN node ( eNodeB / RNC) may be useful. However, Non-Patent Document 1 describes that the MEC server uses radio network information (eg, subscriber location, cell load, link quality, etc.) obtained from the RAN node (eNodeB / RNC). It does not describe that the server requests the RAN node (eNodeB / RNC) to control the access layer.

  One of the objectives that the embodiments disclosed herein seek to achieve is an apparatus, method, and program that contributes to achieving control in a radio access network suitable for a mobile edge computing environment. Is to provide.

  In a first aspect, an edge server deployed in combination with a radio access network includes an edge computing platform and a control module. The edge computing platform is configured to provide at least one of computing resources and storage resources for edge computing related to a service or application directed to a wireless terminal connected to the wireless access network. Has been. The control module is configured to determine control information used in the radio access network for radio resource management for at least one of a plurality of radio terminals including the radio terminal based on characteristics of the radio terminal Has been.

  In a second aspect, a method in an edge server arranged in combination with a radio access network includes control information used in the radio access network for radio resource management for at least one of a plurality of radio terminals. Determining based on characteristics of the wireless terminal.

  In the third aspect, the program includes a group of instructions (software code) for causing the computer to perform the second method described above when read by the computer.

  According to the above-described aspect, it is possible to provide an apparatus, a method, and a program that contribute to realizing control in a radio access network suitable for a mobile edge computing environment.

It is a figure which shows the structural example of the mobile communication network which concerns on some embodiment. It is a sequence diagram which shows an example of operation | movement of the eNodeB and MEC server which concern on 1st Embodiment. It is a flowchart which shows an example of operation | movement of the MEC server which concerns on 1st Embodiment. It is a flowchart which shows an example of operation | movement of eNodeB which concerns on 1st Embodiment. It is a sequence diagram which shows an example of operation | movement of eNodeB which concerns on 1st Embodiment. It is a sequence diagram which shows an example of operation | movement of eNodeB, PCRF, and MEC server which concern on 2nd Embodiment. It is a figure which shows the structural example of the MEC server which concerns on some embodiment. It is a figure which shows the structural example of eNodeB which concerns on some embodiment. It is a figure which shows the structural example of PCRF which concerns on some embodiment.

  Hereinafter, specific embodiments will be described in detail with reference to the drawings. In each drawing, the same or corresponding elements are denoted by the same reference numerals, and redundant description is omitted as necessary for clarification of the description.

  A plurality of embodiments shown below are described mainly for LTE and LTE-Advanced. However, these embodiments are not limited to LTE and LTE-Advanced, but other mobile communication networks or systems such as 3rd Generation Partnership Project (3GPP) Universal Mobile Telecommunications System (UMTS), 3GPP2 CDMA2000 system, Global The present invention may be applied to a System for Mobile communications (GSM (registered trademark)) / General packet radio service (GPRS) system, a WiMAX system, a mobile WiMAX system, or the like.

<First Embodiment>
FIG. 1 shows a configuration example of a mobile communication network according to some embodiments including this embodiment. In the example of FIG. 1, the mobile communication network includes a RAN 3 (Evolved UMTS Terrestrial Radio Access Network (E-UTRAN)) and a core network 4 (Evolved Packet Core (EPC)). RAN3 includes eNodeB2. The eNodeB 2 is arranged in the RAN 3 and is configured to communicate with a plurality of radio terminals 1 (User Equipment (UE)) connected to the RAN 3 and provide radio resource management for the UEs 1. Radio resource management includes, for example, establishment / modification / release of radio connection (eg, Radio Resource Control (RRC) connection) with each UE1, scheduling of radio resources to each UE1, and dedicated scheduling request (Dedicated Scheduling Request) for each UE1. (D-SR)) Resource setting and handover control of each UE1 are included.

  The eNodeB 2 shown in FIG. 1 may be a Baseband Unit (BBU) used in the Centralized Radio Access Network (C-RAN) architecture. In other words, the eNodeB 2 illustrated in FIG. 1 may be a RAN node connected to one or a plurality of Remote Radio Heads (RRH). In some implementations, the eNodeB 2 as a BBU is connected to the EPC 4 and is responsible for control plane processing including radio resource management and user plane digital baseband signal processing. On the other hand, the RRU is in charge of analog radio frequency (RF) signal processing (e.g., frequency conversion and signal amplification). Note that C-RAN is sometimes referred to as Cloud RAN. A BBU may also be called a radio equipment controller (REC) or a data unit (DU). RRH may also be called Radio Equipment (RE), Radio Unit (RU), or Remote Radio Unit (RRU).

  The core network 4 is a network managed mainly by an operator who provides mobile communication services. The core network 4 includes a plurality of user plane entities (eg, Serving Gateway (S-GW) and Packet Data Network Gateway (P-GW)), and a plurality of control plane entities (eg, Mobility Management Entity (MME) and Home Subscriber Server (HSS), Policy and Charging Rule Function (PCRF)). A plurality of user plane entities relay user data of UEs 1 between the RAN 3 and an external network (Packet Data Network (PDN)). The plurality of control plane entities perform various controls including UEs1 mobility management, session management (bearer management), subscriber information management, and charging management.

  The Mobile Edge Computing (MEC) server 5 is arranged in the RAN 3 so that it can communicate directly with the eNodeB 2 (that is, not via the core network 4). In some implementations, the MEC server 5 may be physically integrated with the eNodeB 2. In some implementations, the MEC server 5 may be located in the same building (site) as the eNodeB 2 and connected to a local area network (LAN) in the site so as to communicate with the eNodeB 2.

  The MEC server 5 is configured to provide at least one of computing resources and storage resources (storage capacity) for edge computing for services or applications directed to one or more UEs 1. ing. In some implementations, the MEC server 5 may provide a hosting environment for applications by providing IaaS or PaaS facilities.

  The MEC server 5 may further have some functions of the core network 4. For example, the MEC server 5 may have an S-GW or S-GW / P-GW function, and the user data of the UE 1 that uses the MEC may be directly terminated at the MEC server 5.

  Similar to some examples of MEC use cases described in the background art, the MEC server 5 may communicate with one or more central servers 6 to provide applications or services. Communication between the MEC server 5 and the central server 6 may be performed via the core network 4 or may be performed on a communication line or network that does not pass through the core network 4.

  Subsequently, dynamic radio resource management by the eNodeB 2 according to the present embodiment will be described below. FIG. 2 is a sequence diagram showing an example of operation of the eNodeB 2 and the MEC server 5 (process 200). In step 201, the MEC server 5 transmits a message indicating the MEC control information explicitly or implicitly to the eNodeB2. The MEC control information is derived from the characteristics of the UE 1 that uses or relates to an application (service) hosted on the MEC server 5. In some implementations, the MEC server 5 may determine MEC control information from the characteristics of the UE1.

  The characteristics of UE1 referred to for obtaining the MEC control information are, for example, UE1 terminal type (eg, car navigation system, smart meter), UE1 terminal category (eg, Access Class, UE category), and UE1 communication. It includes at least one of a data type (eg, video stream, Hypertext Transfer Protocol (HTTP)) and a type of service or application used by UE1. Further or alternatively, the UE1 characteristics include UE1 position-related information (eg, near an intersection, on the sidewalk, at home), UE1 movement characteristics (eg, high speed, low speed, movement direction), and UE1 communication characteristics. (Eg, radio quality, throughput) may be included. Further or alternatively, the characteristics of the UE 1 may include at least one of the communication interval and the communication data amount of the UE 1. Note that the communication interval or the communication data amount may be for each application or for each service, or may be a plurality or all of the applications or service units that the UE 1 is executing. Additionally or alternatively, the characteristics of the UE 1 may include the radio link quality (e.g., Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ)) of the UE 1.

The MEC control information derived from the characteristics of UE1 may be, for example, at least one of the following, or any combination.
・ Delay requirement ・ Throughput requirement ・ Priority requirement ・ Mobility requirement

  The delay requirement may specify at least one of maximum delay, average delay, delay jitter, and priority regarding delay guarantee. The delay requirement may specify a period, schedule, or number of times that the delay requirement is required. Furthermore, the delay mentioned here is, for example, the delay until UE1 completes transmitting data to RAN3, the delay until the data of UE1 reaches the transmission destination of the data (eg, server, other UE1), Any of delay until data is completely transmitted to UE1 may be used.

  The throughput requirement may specify at least one of minimum throughput (minimum throughput to be guaranteed), average throughput, and requested throughput (sufficient throughput).

  The priority requirement is relative priority or absolute priority between UE1 using MEC, or relative priority or absolute of UE1 using MEC for UE1 not using other MEC. At least one of the priorities may be designated.

  The mobility requirement may specify at least one of whether or not to guarantee mobility and a value or level (e.g. high, medium (or normal), or low) of a moving speed that guarantees mobility.

  The MEC control information may specify a data pattern, an application type, or a service type in order to specify a data flow to which the MEC control information (e.g., delay requirement) should be applied. The MEC control information may specify a cell or cell group, a frequency or frequency group, a UE or UE group, or any combination thereof in order to specify UE1 to which it is applied.

  Additionally or alternatively, the MEC control information (eg, delay requirement) specifies the number or percentage of UEs for which a predetermined requirement (eg, delay) should be guaranteed among a plurality of UEs1 belonging to a specific UE group. May be. As a specific example, the delay requirement may indicate that a predetermined delay is guaranteed for three of the ten UEs. Note that the delay requirements for each UE 1 may be the same or different.

  The MEC control information may include a Quality of Service (QoS) policy, a QoS rule, or a Policy and Charging Control (PCC) rule regarding the EPS bearer. The MEC control information may indicate, for example, Quality Class Indicator (QCI) and Allocation Retention Priority (ARP). The MEC control information (QoS policy or QoS rule) regarding the EPS bearer may be associated with E-UTRAN Radio Access Bearer (E-RAB) QoS and radio bearer QoS in the eNodeB2.

  As understood from the above description, in the present embodiment, the MEC server 5 uses the MEC or receives MEC control information (eg, delay requirement) derived from the characteristics of the UE1 related to the MEC in the RAN3. Is configured to notify the eNodeB 2 responsible for the radio resource management. Therefore, the eNodeB 2 can perform radio resource management for the UE 1 or other UE 1 that uses the MEC or is related to the MEC based on the MEC control information received from the MEC server 5. As a result, the eNodeB 2 can consider MEC control information derived from the characteristics of the UE 1 using (or related to) edge computing provided by the MEC server 5 in the radio resource management in the RAN 3.

  Subsequently, the operations of the eNodeB 2 and the MEC server 5 will be described in more detail below. FIG. 3 is a flowchart showing an example of operation of the MEC server 5 (processing 300). In block 301, the MEC server 5 determines MEC control information from the characteristics of UE1 that uses (or is related to) the MEC. In block 302, the MEC server 5 sends a message to the eNodeB 2 that explicitly or implicitly indicates the determined MEC control information.

  FIG. 4 is a flowchart illustrating an example of operation of the eNodeB 2 (processing 400). In block 401, the eNodeB 2 receives a message from the MEC server 5 that explicitly or implicitly indicates the MEC control information. In block 402, the eNodeB 2 performs radio resource management for at least one UE 1 based on the MEC control information received from the MEC server 5.

  Subsequently, some examples of radio resource management considering MEC control information from the MEC server 5 will be described. Radio resource management considering MEC control information from the MEC server 5 includes release of radio connection (eg, RRC connection) with at least one UE1, scheduling of radio resources to at least one UE1, and D for at least one UE1. -It may include at least one of SR resource setting and handover of at least one UE1.

  In some implementations, the eNodeB2 requires a requirement (eg, request delay) for UE1 that uses (or relates to) MEC, but a requirement for other UE1 that does not relate to MEC (eg, request delay). Radio resource management may be performed so that it is preferentially satisfied as compared with. Thereby, for example, it becomes easy to guarantee a predetermined delay (e.g., 10 milliseconds or less) to UE1 using (or related to) MEC.

  In some implementations, the eNodeB 2 may have a radio connection (eg, with other UE 1 not related to MEC) to satisfy MEC control information (eg, delay requirement) for UE 1 that uses (or is related to) MEC. , RRC connection) may be released.

  In some implementations, the eNodeB2 may use the DEC of the UE1 that uses (or relates to) the MEC to satisfy the MEC control information (eg, delay requirement) for the UE1 that uses (or relates to) the MEC. The period of the SR resource may be adjusted based on the MEC control information. Or eNodeB2 may adjust the period of D-SR resource of UE1 which is not related to MEC. For example, eNodeB2 uses a period (eg, 1 or 2) that is shorter (eg, 5-10 milliseconds) than the period (eg, 5-10 milliseconds) of UE1 that is not related to MEC. 2 milliseconds). Thereby, UE1 that uses (or is related to) MEC can obtain a transmission request of a scheduling request in a short period, and thus contributes to a reduction in delay (latency) of UE1 that uses (or is related to) MEC. it can.

  In some implementations, eNodeB2 is applied to UE1 using (or related) MEC to satisfy MEC control information (eg, delay requirement) for UE1 (or related) using MEC. The scheduling metric may be adjusted based on the MEC control information. Or eNodeB2 may adjust the scheduling metric applied to UE1 which is not related to MEC. For example, eNodeB2 operates on a scheduling metric applied to UE1 that uses (or is associated with) MEC so that radio resource allocation is preferentially performed for UE1 that uses (or is associated with) MEC. The weight may be adjusted. For the proportional fairness (PF) algorithm, the scheduling metric (PF metric) may be the ratio of instantaneous throughput to average throughput (i.e., instantaneous throughput / average throughput).

  The above-described adjustment of the D-SR resource and the scheduling metric is performed by maintaining some UE1 with a predetermined delay among a plurality of UEs1 requesting a predetermined delay (eg, within 10 milliseconds), and others. May be performed in order to increase the delay of UE1 or to make it the best effort. Alternatively, these adjustments are made to allow control to allow all the delays of multiple UEs1 that require a given delay (eg, within 10 milliseconds) to be lengthened (eg, within 11 milliseconds). May be.

  In some implementations, eNodeB 2 forces UEs not related to MEC to other cells to satisfy MEC control information (eg, delay requirement) for UE1 that uses (or is related to) MEC. Handover may be performed. Instead, the eNodeB 2 forcibly hands over the UE 1 that uses (or is related to) the MEC to another cell with good communication characteristics (for example, good radio quality or low cell load) for the UE 1. May be. The eNodeB2 (source eNodeB2S) may send a handover request to another eNodeB2 (target eNodeB2T) (in the case of X2 handover). If X2 handover is not available, the eNodeB 2 (source eNodeB 2S) may send a handover request to a node (ie, MME) in the core network 4.

  For example, as shown in FIG. 5, the handover request transmitted from the source eNodeB 2S to the target eNodeB 2T is whether or not the UE 1 performing the handover uses (or uses) edge computing (MEC). May be indicated, or use (or use) of MEC may be indicated. This may be performed, for example, by adding MEC Required IE to the HANDOVER REQUEST message or by adding MEC Authorized IE. In the example of FIG. 5 (process 500), the source eNodeB 2S transmits a handover request indicating whether or not MEC is required to the target eNodeB 2T (step 501). If the target eNodeB 2T cannot accept the handover of UE1 that uses (or is related to) the MEC, it may reject the handover request. In this case, the handover reject message may indicate that MEC cannot be provided, MEC is not supported, or that the delay requirement for MEC cannot be satisfied. Thereby, the target eNodeB 2T can determine whether or not to accept the handover in consideration of whether or not MEC can be provided. Alternatively, the target eNodeB 2T may designate another cell that can provide the MEC as a target cell for handover, and may transmit a handover request permission message to the source eNodeB 2S.

  For example, when the source eNodeB 2S determines a target cell from one or more target cell candidates, whether each target cell candidate can provide an MEC, or the delay expected (required) by the MEC You may consider whether you meet requirements. For this purpose, a plurality of eNodeBs 2 may exchange information such as MEC support and cell load via an inter-base station interface (e.g., X2 interface). This may be executed, for example, in an X2 interface establishment procedure (X2 Setup Procedure), or may be performed by a notification (ENB CONFIGURATION UPDATE) for updating the setting of the base station.

  Subsequently, a specific example of MEC control information derived from the characteristics of UE1 will be described below. First, some examples for determining the delay requirement as MEC control information from the characteristics of UE1 will be described. Consider a case where the UE 1 is used to transmit user (or vehicle) location information to the MEC server 5 or the central server 6. In one example, UE1 delay requirements may be determined according to the usage / type of UE1 (eg, car, truck, taxi, bike, bicycle, pedestrian, pedestrian age, pedestrian sex, etc.) . The MEC server 5 has a stricter delay requirement (eg, a smaller maximum delay, a smaller average delay, or a UE 1 with a low usage rate than a UE 1 with a low usage rate. (Small delay jitter) may be determined. The MEC server 5 may determine a stricter delay requirement for UE1 of usage / type that is seriously affected by a traffic accident than UE1 of other usage / type.

  In addition, or instead of this, when the position of UE1 is near a predetermined point (eg, an intersection, a sharp curve, a tourist attraction), the MEC server 5 is compared with the case where the position of UE1 is far from the predetermined point. Strict delay requirements may be determined. Additionally or alternatively, the MEC server 5 may determine stricter delay requirements when the UE1 is approaching a predetermined point than when the UE1 is moving away from the predetermined point. Additionally or alternatively, the MEC server 5 may determine stricter delay requirements when the UE1 is moving (running) at high speed than when the UE1 is moving (running) at low speed. .

  In addition, or instead of this, the MEC server 5 may determine the delay requirement of the UE 1 in accordance with the time of day or the congestion situation (the degree of congestion of people or vehicles). For example, the MEC server 5 may determine a stricter delay requirement when congestion is expected or when congestion occurs than when it is not.

  The determination of the delay requirement may be performed by classifying (assigning) the UE 1 to any one of a plurality of predetermined delay requirement classes.

  According to these examples, for example, it is possible to enable UE1 associated with a place where the incidence of traffic accidents such as the vicinity of an intersection or the like or a use application / type is high with low delay.

  Next, several examples for determining throughput requirements (radio bandwidth requirements) as MEC control information from the characteristics of UE1 will be described. Consider a case where each of a plurality of UEs1 is coupled to a video camera, and a plurality of UEs1 are used to transmit a video stream obtained by the video camera to the MEC server 5 or the central server 6. In one example, the MEC server 5 may determine the throughput requirements (minimum throughput (wireless bandwidth), average throughput (wireless bandwidth)) of the UE 1 coupled to the video camera according to the installation location of the video camera. For example, the MEC server 5 requests the eNodeB 2 to give high throughput to the UE1 coupled to the video camera installed near the field in the stadium, and gives low throughput to the UE1 installed far away from the field. May be requested to eNodeB2.

  Additionally or alternatively, the MEC server 5 determines the throughput requirements of the UE 1 coupled to the video camera according to the type of video camera (eg, High Definition (HD) camera or 4K Ultra HD camera). May be. In one example, MEC server 5 requires eNodeB 2 to provide high throughput to UE 1 coupled to a high resolution (4K UHD) video camera, and UE 1 coupled to a low resolution (eg., HD) video camera. ENodeB 2 may be requested to provide a low throughput.

  In addition, or instead of this, the MEC server 5 determines the video depending on the shooting status of each video camera (for example, whether an important subject is being shot or whether it is close to the important subject). The throughput requirement of UE1 coupled to the camera may be determined. In one example, the MEC server 5 may request the eNodeB 2 to provide high throughput to the UE 1 coupled to a video camera that is close to an important subject (eg, a ball in a soccer (football) game).

  In addition, or instead of this, the throughput requirement of the UE 1 may be determined according to the time of day or the congestion situation (the degree of crowded audience).

  According to these examples, for example, a wide band can be dynamically guaranteed for UE1 coupled to a video camera that is to transmit a high-resolution video stream.

  Next, consider the case of live streaming to the audience in an event venue such as a stadium or concert hall. In one example, the MEC server 5 may determine the throughput requirements (minimum throughput (wireless band), average throughput (wireless band)) of the UE 1 according to the position of the audience in the stadium or concert hall. For example, the eNodeB 2 may be requested to give a high throughput to the UE 1 of the spectator far away from the field or stage, and the eNodeB 2 may be requested to give a low throughput to the UE 1 of the spectator close to the field or stage. In addition, or instead of this, the throughput requirement of the UE 1 may be determined according to the time of day or the congestion situation (the degree of crowded audience).

  According to these examples, for example, it is possible to dynamically guarantee a wide band for UE1 of a spectator who is likely to use live streaming video distributed to UE1 because it is far from the field or stage.

<Second Embodiment>
In this embodiment, a modification of dynamic radio resource management by eNodeB 2 described in the first embodiment will be described. In the first embodiment, the example in which the MEC server 5 directly transmits to the eNodeB 2 the MEC control information derived from the characteristics of the UE 1 that uses (or is related to) the MEC has been described. Alternatively, the PCRF 7 in the core network 4 may determine the MEC control information and instruct the determined MEC control information (Policy and Charging Control (PCC) rule) to the eNodeB 2.

  FIG. 6 shows an example of a procedure (process 600) for enforcing the MEC control information derived from the characteristics of UE1 using (or related to) MEC to eNodeB2. In step 601, the MEC server 5 transmits the characteristic information of the UE 1 that uses (or is related to) the MEC to the PCRF 7. In step 602, the PCRF 7 determines MEC control information from the received UE1 characteristic information, and transmits the MEC control information to the eNodeB2. Instead of step 602, the PCRF 7 may transmit the determined MEC control information to the MEC server 5 and transmit it from the MEC server 5 to the eNodeB 2.

  In some implementations, the eNodeB 2 may have a P-GW function so that the eNodeB 2 can receive MEC control information (PCC rules) from the PCRF 7. The P-GW function may also be used for offloading user traffic in eNodeB2. The MEC control information sent from the PCRF 7 to the eNodeB 2 may indicate a Quality of Service (QoS) policy or a QoS rule regarding the EPS bearer, for example, Quality Class Indicator (QCI) and Allocation Retention Priority (ARP). The MEC control information (QoS policy or QoS rule) related to the EPS bearer is associated with E-UTRAN Radio Access Bearer (E-RAB) QoS and radio bearer QoS in eNodeB2.

  As understood from the above description, in this embodiment, the PCRF 7 transmits to the eNodeB 2 MEC control information (e.g., delay requirement, throughput requirement) derived from the characteristics of the UE 1 that uses or relates to the MEC. Accordingly, the eNodeB 2 can perform radio resource management for the UE 1 or other UE 1 that uses the MEC or is related to the MEC based on the MEC control information received from the PCRF 7.

  Finally, configuration examples of the MEC server 5, the eNodeB 2, and the PCRF 7 according to the above-described plurality of embodiments will be described. FIG. 7 is a block diagram illustrating a configuration example of the MEC server 5. Referring to FIG. 7, the MEC server 5 includes hardware components including a network interface 701, a processor 702, and a memory (storage) 703. The network interface 701 is used to communicate with the eNodeB 2 and other network nodes. The network interface 701 may include, for example, a network interface card (NIC) compliant with IEEE 802.3 series.

  The processor 702 reads the software (computer program) from the memory 703 and executes it, thereby performing the processing of the MEC server 5 described with reference to the sequence diagram and the flowchart in the above-described embodiment. The processor 702 may be, for example, a microprocessor, a micro processing unit (MPU), or a central processing unit (CPU). The processor 702 may include a plurality of processors.

  The memory 703 is configured by a combination of a volatile memory and a nonvolatile memory. The memory 703 may include a plurality of physically independent memory devices. The volatile memory is, for example, Static Random Access Memory (SRAM), Dynamic RAM (DRAM), or a combination thereof. The non-volatile memory is a mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, or hard disk drive, or any combination thereof. Memory 703 may include storage located remotely from processor 702. In this case, the processor 702 may access the memory 703 via an I / O interface (not shown).

  In the example of FIG. 7, the memory 703 is used to store a software module group 704 to 706 for MEC and a control module 707 that communicates with the eNodeB 2 or the PCRF 7. Virtualization management software 704 is executed in the processor 702, virtualizes hardware components including the network interface 701, the processor 702, and the memory 703, and implements Infrastructure as a Service (IaaS) or Platform as a Service ( PaaS) facilities, thereby providing a hosting environment for applications.

  Application platform services software 705 runs on processor 702 and provides middleware services such as communication services, wireless network information services, traffic offload functions, etc. to applications.

  One or more applications 706 are applications hosted on the MEC server 5. The one or more applications 706 may be a geo-location application, a video analysis application, a content optimization application, and the like described in the background art.

  The control module 707 is executed in the processor 702 and transmits to the eNodeB 2 MEC control information derived from the characteristics of the UE 1 that uses (or is related to) the MEC, or performs operations such as the PCRF 7 of the characteristics of the UE 1 on the processor 702. Let it be done.

  FIG. 8 is a block diagram illustrating a configuration example of the eNodeB 2 according to the above-described embodiment. Referring to FIG. 8, the eNodeB 2 includes an RF transceiver 801, a network interface 803, a processor 804, and a memory 805. The RF transceiver 801 performs analog RF signal processing to communicate with UE1. The RF transceiver 801 may include a plurality of transceivers. RF transceiver 801 is coupled with antenna 802 and processor 804. The RF transceiver 801 receives modulation symbol data (or OFDM symbol data) from the processor 804, generates a transmission RF signal, and supplies the transmission RF signal to the antenna 802. Further, the RF transceiver 801 generates a baseband received signal based on the received RF signal received by the antenna 802 and supplies this to the processor 804. As described above, the eNodeB 2 may be a BBU (REC) used in the C-RAN architecture. In this case, the eNodeB 2 may not have the RF transceiver 801.

  The network interface 803 is used to communicate with the network nodes (e.g., MME and S-GW) and the MEC server 5. The network interface 803 may include, for example, a network interface card (NIC) compliant with IEEE 802.3 series.

  The processor 804 performs digital baseband signal processing (data plane processing) and control plane processing for wireless communication. For example, in LTE and LTE-Advanced, the digital baseband signal processing by the processor 804 may include PDCP layer, RLC layer, MAC layer, and PHY layer signal processing. Further, the control plane processing by the processor 804 may include S1 protocol, RRC protocol, and MAC CE processing.

  The processor 804 may include a plurality of processors. For example, the processor 804 may include a modem processor (e.g., DSP) that performs digital baseband signal processing and a protocol stack processor (e.g., CPU or MPU) that performs control plane processing.

  The memory 805 is configured by a combination of a volatile memory and a nonvolatile memory. The volatile memory is, for example, SRAM or DRAM or a combination thereof. The non-volatile memory is, for example, an MROM, PROM, flash memory, hard disk drive, or a combination thereof. Memory 805 may include storage located remotely from processor 804. In this case, the processor 804 may access the memory 805 via the network interface 803 or an I / O interface (not shown).

  The memory 805 may store a software module (computer program) including an instruction group and data for performing processing by the eNodeB 2 described in the above-described embodiments. In some implementations, the processor 804 may be configured to read and execute the software module from the memory 805 to perform the eNodeB2 processing described using the sequence diagrams and flowcharts in the above-described embodiments. .

  In the example of FIG. 8, the communication module 806 and the control module 807 are stored in the memory 805. The processor 804 can communicate with the MEC server 5 by reading and executing the communication module 806. The processor 804 reads out and executes the control module 807, thereby receiving the MEC control information of the UE1 from the MEC server 5, and performing radio resource management while considering the MEC control information.

  FIG. 9 is a block diagram illustrating a configuration example of the PCRF 7 according to the above-described embodiment. Referring to FIG. 9, the PCRF 7 includes a network interface 901, a processor 902, and a memory 903. The network interface 901 is used to communicate with the network node (e.g., MME, HSS, P-GW, eNodeB 2) and the MEC server 5. The network interface 901 may include, for example, a network interface card (NIC) compliant with IEEE 802.3 series.

  The processor 902 reads out and executes software (computer program) from the memory 903, thereby performing the processing of the PCRF 7 described with reference to the sequence diagram and the flowchart in the above-described embodiment. The processor 902 may be, for example, a microprocessor, MPU, or CPU. The processor 902 may include a plurality of processors.

  The memory 903 is configured by a combination of a volatile memory and a nonvolatile memory. Memory 903 may include storage located remotely from processor 902. In this case, the processor 902 may access the memory 903 via an I / O interface (not shown).

  In the example of FIG. 9, the memory 903 is used to store a software module group including a communication module 904 and a control module 905. The processor 902 can perform the process of the PCRF 7 described in the above-described embodiment by reading these software module groups from the memory 903 and executing them.

  The processor 902 can communicate with the MEC server 5 by reading and executing the communication module 904. By reading and executing the control module 905, the processor 902 can receive the characteristic information of the UE1 from the MEC server 5 and transmit the MEC control information derived from the characteristic information to the eNodeB2.

  As described with reference to FIGS. 7 to 9, each of the processors included in the MEC server 5, eNodeB 2, and PCRF 7 according to the above-described embodiment has instructions for causing a computer to execute the algorithm described with reference to the drawings. Run one or more programs that contain groups. This program can be stored using various types of non-transitory computer readable media and supplied to a computer. Non-transitory computer readable media include various types of tangible storage media. Examples of non-transitory computer-readable media include magnetic recording media (eg flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (eg magneto-optical discs), compact disc read only memory (CD-ROM), CD-ROMs. R, CD-R / W, and semiconductor memory (for example, mask ROM, programmable ROM (PROM), erasable PROM (EPROM), flash ROM, random access memory (RAM)) are included. The program may also be supplied to the computer by various types of transitory computer readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves. The temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.

<Other embodiments>
In the above-described embodiment, the case where the MEC control information considered in the eNodeB 2 for radio resource management is a delay requirement has been mainly described. However, the MEC control information may include other requirements (eg, throughput requirement) instead of or in combination with the delay requirement.

  The above-described embodiment may be modified as follows. That is, in some implementations, the MEC server 5 may transmit to the PCRF 7 the MEC control information derived from the characteristics of the UE 1 that uses (or is related to) the MEC. Then, the PCRF 7 may instruct the eNodeB 2 of a QoS policy (e.g., PCC rule) based on the MEC control information received from the MEC server 5. The PCRF 7 may transmit the MEC control information received from the MEC server 5 to the eNodeB 2 as it is, or may transmit a QoS policy obtained by correcting the MEC control information received from the MEC server 5 to the eNodeB 2.

  Furthermore, the above-described embodiment is merely an example relating to application of the technical idea obtained by the present inventors. That is, the technical idea is not limited to the above-described embodiment, and various changes can be made.

1 UE
2 eNodeB
3 Wireless access network 4 Core network 5 MEC server 7 PCRF
707 Control module 806 Communication module 807 Control module 904 Communication module 905 Control module

Claims (24)

An edge server coupled to a radio access network,
An edge computing platform configured to provide at least one of computing resources and storage resources for edge computing related to a service or application directed to a wireless terminal connected to the wireless access network; ,
A control module configured to determine control information used in the radio access network for radio resource management for at least one of a plurality of radio terminals including the radio terminal based on characteristics of the radio terminal; ,
Bei to give a,
The control information includes at least one of a delay requirement, a throughput requirement, a priority requirement, and a mobility requirement.
Edge server. The characteristics of the wireless terminal include the terminal type of the wireless terminal, the communication data type of the wireless terminal, the position of the wireless terminal, the movement characteristics of the wireless terminal, the communication interval of the wireless terminal, and the communication data of the wireless terminal. Including at least one of the quantities,
The edge server according to claim 1. The delay requirement specifies at least one of maximum delay, average delay, delay jitter, and priority for delay guarantee.
The edge server according to claim 1 or 2 . The delay requirement specifies the period, schedule, or number of times that the delay requirement is required,
The edge server according to claim 1. The throughput requirement specifies at least one of minimum throughput, average throughput, required throughput, minimum radio bandwidth, average radio bandwidth, and required radio bandwidth.
The edge server according to any one of claims 1 to 4 . The control information includes the delay requirement;
The control module enables the wireless terminal to perform wireless communication with a low delay when the wireless terminal is near a predetermined point compared to when the wireless terminal is far from the predetermined point. Configured to request the radio access network to
The edge server according to any one of claims 1 to 5 . The control information includes the delay requirement;
The control module enables the wireless terminal to perform wireless communication with a low delay when the wireless terminal is approaching a predetermined point compared to a case where the wireless terminal is moving away from the predetermined point. Configured to request to the radio access network,
The edge server according to any one of claims 1 to 5 . The control information includes the delay requirement;
The control module enables the wireless terminal to perform wireless communication with a low delay when the wireless terminal is moving at a high speed compared to when the wireless terminal is moving at a low speed. Configured to require the radio access network,
The edge server according to any one of claims 1 to 5 . The control information includes the throughput requirement,
The control module provides the wireless access network with a higher throughput when the video camera to which the wireless terminal is coupled has a higher resolution than when the video camera has a lower resolution. Configured to require,
The edge server according to any one of claims 1 to 5 . The control information includes the throughput requirement,
The control module is configured to determine the throughput requirement for the wireless terminal according to a shooting situation of a video camera to which the wireless terminal is coupled.
The edge server according to any one of claims 1 to 5 . The control information includes the throughput requirement,
The control module is configured to determine the throughput requirement for the wireless terminal as a function of an installation location of a video camera to which the wireless terminal is coupled.
The edge server according to any one of claims 1 to 5 . The control information includes the throughput requirement,
The control module is configured to determine the throughput requirement for the wireless terminal as a function of an installation location of a video camera to which the wireless terminal is coupled.
The edge server according to any one of claims 1 to 5 . The control information includes the throughput requirement,
The control module is configured to determine the throughput requirement for the wireless terminal as a function of the location of the wireless terminal within a venue where an event occurs.
The edge server according to any one of claims 1 to 5 . An edge coupled to a radio access network and providing at least one of computing resources and storage resources for edge computing related to a service or application directed to a wireless terminal connected to the radio access network A method at the server,
Determining control information used in the radio access network for radio resource management for at least one of a plurality of radio terminals including the radio terminal based on characteristics of the radio terminal;
Bei to give a,
The control information includes at least one of a delay requirement, a throughput requirement, a priority requirement, and a mobility requirement.
Method. The characteristics of the wireless terminal include the terminal type of the wireless terminal, the communication data type of the wireless terminal, the position of the wireless terminal, the movement characteristics of the wireless terminal, the communication interval of the wireless terminal, and the communication data of the wireless terminal. Including at least one of the quantities,
The method according to claim 14 . The control information includes the delay requirement;
When the wireless terminal is near a predetermined point, the wireless terminal can perform wireless communication with low delay compared to a case where the wireless terminal is far from the predetermined point. Further comprising requesting the access network;
16. A method according to claim 14 or 15 . The control information includes the delay requirement;
When the wireless terminal is approaching a predetermined point, the wireless access is performed so that the wireless terminal can perform wireless communication with low delay compared to a case where the wireless terminal is away from the predetermined point. Further comprising requesting to the network,
16. A method according to claim 14 or 15 . The control information includes the delay requirement;
When the wireless terminal is moving at a high speed, the wireless access network is requested to enable the wireless terminal to perform wireless communication with a low delay compared to the case where the wireless terminal is moving at a low speed. Further comprising
16. A method according to claim 14 or 15 . The control information includes the throughput requirement,
Requesting the wireless access network to provide a higher throughput to the wireless terminal when the video camera to which the wireless terminal is coupled has a higher resolution than when the video camera has a lower resolution. Prepare
16. A method according to claim 14 or 15 . The control information includes the throughput requirement,
The determining includes determining the throughput requirement for the wireless terminal according to a shooting situation of a video camera to which the wireless terminal is coupled.
16. A method according to claim 14 or 15 . The control information includes the throughput requirement,
The determining includes determining the throughput requirement for the wireless terminal as a function of a location of a video camera to which the wireless terminal is coupled;
16. A method according to claim 14 or 15 . The control information includes the throughput requirement,
The determining includes determining the throughput requirement for the wireless terminal as a function of a location of a video camera to which the wireless terminal is coupled;
16. A method according to claim 14 or 15 . The control information includes the throughput requirement,
The determining includes determining the throughput requirement for the wireless terminal as a function of the location of the wireless terminal within a venue where an event occurs;
16. A method according to claim 14 or 15 . An edge coupled to a radio access network and providing at least one of computing resources and storage resources for edge computing related to a service or application directed to a wireless terminal connected to the radio access network A program for causing a computer to perform a method in a server,
The method includes determining control information used in the radio access network for radio resource management for at least one of a plurality of radio terminals including the radio terminal based on characteristics of the radio terminal. See
The control information includes at least one of a delay requirement, a throughput requirement, a priority requirement, and a mobility requirement.
program.

Images