多接入边缘计算（MEC）第二阶段用例与需求

版权申诉

14 浏览量更新于2024-07-18 收藏 1.27MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"Phase 2 Use Cases and Requirements (MEC).pdf" 是一份由ETSI（欧洲电信标准协会）Multi-access Edge Computing (MEC) 行业规范小组(ISG) 制定的文档，该文档详细阐述了多接入边缘计算（MEC）在第二阶段的应用场景和需求。这份文档反映了参与ISG的成员的观点，但并不一定代表整个ETSI会员的立场。文档的参考编号是RGS/MEC-0002v211TechReq，关键词包括MEC（多接入边缘计算）和要求。 MEC，即多接入边缘计算，是一种分布式计算架构，它将云计算能力和服务部署在距离用户更近的网络边缘，以减少延迟、提升数据处理效率和提供更好的服务质量。在交通领域，MEC技术有着广泛的应用潜力。在交通应用中，MEC可以用于智能交通系统，如实时交通监控、自动驾驶汽车通信、车路协同（V2X）服务、以及高清地图更新等。通过在边缘节点处理交通数据，可以减少对核心网络的负担，提高数据传输速度和可靠性，这对于需要低延迟响应的交通安全应用至关重要。文档中的"Phase 2 Use Cases and Requirements"可能详细探讨了以下方面： 1. **实时交通分析**：MEC可以即时处理来自各种交通传感器和设备的数据，分析交通流量，预测拥堵情况，并向驾驶员或交通管理部门提供实时信息。 2. **自动驾驶支持**：在自动驾驶汽车中，MEC可提供高精度的位置信息、障碍物检测和道路状况更新，确保车辆能够安全、高效地运行。 3. **V2X通信**：MEC可以支持车辆与基础设施（V2I）、车辆与行人（V2P）、车辆与车辆（V2V）之间的通信，促进交通协同，减少事故风险。 4. **智能停车**：利用MEC，可以实现动态停车管理，为驾驶员提供空闲停车位信息，优化城市停车资源的使用。 5. **紧急服务响应**：在交通事故或其他紧急情况下，MEC可以快速传递信息，协助救援人员更快地到达现场。 6. **高清地图更新**：通过MEC，车辆可以实时接收地图更新，包括施工区域、封闭道路等信息，确保导航的准确性。 7. **安全和隐私保护**：MEC在本地处理数据，可以降低敏感信息在传输过程中的风险，增强数据安全性。 8. **网络资源优化**：通过在边缘处理大量数据，MEC可以减轻核心网络的压力，优化网络资源分配。文档可能还涉及了技术实施的挑战、性能指标、标准化需求以及未来发展的展望。这些内容旨在为MEC在交通领域的广泛应用提供技术和政策指导，促进智慧交通系统的构建。对于行业参与者来说，理解并遵循这些用例和要求对于成功实施MEC解决方案至关重要。

资源详情

资源推荐

ETSI

ETSI GS MEC 002 V2.1.1 (2018

10)

NGMN Next Generation Mobile Network

NTP Network Time Protocol

OBU On Board Unit

OPEX Operating Expenditure

OSS Operations Sub-System

OTT Over-The-Top

PBX Private Branch Exchange

PCC Policy Control and Charging

PCF Policy Control Function

PER Packet Error Rate

PIM Protocol-Independent-Multicast

PSS Packet Switched Streaming Service

PTP Precision Time Protocol

QCI Quality Class Indicator

QoE Quality of Experience

RAN Radio Access Network

RAT Radio Access Technology

RD Retained Data

RNC Radio Network Controller

RNI Radio Network Information

SAND Server And Network assisted DASH

SLA Service Level Agreement

SMF Session Management Function

SMS Short Message Service

SPID Subscriber Profile ID

SRS Sounding Reference Signal

STB Set Top Box

TCP Transmission Control Protocol

TEID Tunnel Endpoint ID

TEO Third-party Edge Owner

TV Television

UE User Equipment

UP User Plane

UPF User Plane Function

UTC Universal Time (Co-ordinated)

UX User Experience

V2X Vehicle-to-Everything

VM Virtual Machine

VNF Virtualised Network Function

VOD Video On Demand

VR Virtual Reality

WLAN Wireless Local Area Network

ETSI

ETSI GS MEC 002 V2.1.1 (2018

10)

4 Generic principles

4.1 Introduction

The following principles are important to understand in the context of Multi-access Edge Computing.

4.2 NFV alignment

Multi-access Edge Computing uses a virtualisation platform for running applications at the mobile network edge.

Network Functions Virtualisation (NFV) provides a virtualisation platform to network functions. The infrastructure that

hosts their respective applications or network functions is quite similar.

In order to allow operators to benefit as much as possible from their investment, it would be beneficial to reuse the

infrastructure and infrastructure management of NFV to the largest extent possible, by hosting both VNFs (Virtual

Network Functions) and MEC applications on the same or similar infrastructure. Subject to gap analysis, this might

require a number of enhancements (e.g. regarding the sharing of resources with NFV Management and Orchestration,

etc.).

4.3 Mobility support

Mobility is an essential functionality of 3GPP networks. Most devices connected to a 3GPP network are moving around

within the mobile network. Even fixed devices can "move", especially when located at cell edge, but also when

changing RATs, etc., or during exceptional events (e.g. power cut from a base station, etc.).

Some MEC applications are state-independent and do not need to keep state information related to the UEs they are

serving. For example, an application in the category "network performance and QoE improvements" will only improve

the performance of the UE traffic when the traffic goes through that MEC host. When the UE moves to a different

location covered by another MEC host, it will be the application hosted on that MEC host that will take care of the UE

after a brief transition period. Past interaction is not useful for the application.

Other MEC applications, notably in the category "consumer-oriented services", are specifically related to the user

activity. Either the whole application is specific to the user, or at least it needs to maintain some application-specific

user-related information that needs to be provided to the instance of that application running on another MEC host.

As a consequence of UE mobility, the MEC system needs to support the following:

• continuity of the service;

• mobility of application (VM); and

• mobility of application-specific user-related information.

4.4 Deployment independence

For reasons of performance, costs, scalability, operator preferred deployments, etc., different deployment scenarios need

to be supported:

• deployment at the radio node;

• deployment at an aggregation point;

• deployment at the edge of the Core Network (e.g. in a distributed data centre, at a gateway);

• etc.

In order to fulfil all these deployment options, the framework of the MEC architecture needs to allow all these scenarios

and the requirements need to be able to address all these deployment options. Requirements that cannot be fulfilled for

all deployment options cannot be made mandatory, but might be conditional or optional.

ETSI

ETSI GS MEC 002 V2.1.1 (2018

10)

When a MEC platform is deployed on a host located in a cell aggregation site, MEC services running on that platform

might need to retrieve information from the radio node(s), for instance, to readout the traffic load and resource block

usage of a specific cell.

In order to prevent the illegal access from dishonest terminals and MEC application developers, authentication and

secure tunnel communication are necessary between the radio node(s) and the MEC service.

NOTE: The interface between the radio node(s) and the MEC service is not specified in Multi-access Edge

Computing Group Specifications.

4.5 Simple and controllable APIs

In order to enable the development of a strong ecosystem for Multi-access Edge Computing, it is very important to

develop APIs that are as simple as possible and are directly answering the needs of applications. To the extent this is

possible, Multi-access Edge Computing specifications need to reuse existing APIs that fulfil the requirements.

In particular circumstances, operators might need to be able to control dynamically the access to certain APIs by a MEC

application. Examples include the mitigation of high load of a radio node or MEC host, or when the information of a

specific radio node or cell cannot be provided.

4.6 Smart application location

MEC applications have a number of requirements, in terms of computing, storage and network resources. More

importantly, some applications might have requirements in terms of latency (including latency fairness), etc.

For a certain number of MEC applications, the conditions might evolve over time and require the MEC system to

change the location of the application, e.g. as the UEs are moving from cell to cell.

Also, different locations may have different "costs" (in terms of resource availability, energy consumption, etc.), and it

might not be always the best choice to run a MEC application at the "best" location (to the detriment of other

applications).

For these reasons, MEC applications need to run "at the right place" at the right moment, and might have to move when

the conditions evolve. In order to support this, the MEC system needs to provide a system-wide lifecycle management

of applications.

4.7 Application mobility to/from an external system

In order to support service continuity when the user context and/or application instance is relocated, the system shall be

able to relocate a mobile edge application running in an external cloud environment to a MEC host fulfilling the

requirements of the MEC application and relocate a MEC application from a MEC host to an external cloud

environment outside the MEC system.

NOTE: The scenario of application relocation from a MEC host to an external cloud environment outside the

MEC system is for further study.

Two different aspects of application mobility need to be supported to enable user context and/or application instance

relocation from an external cloud environment to a MEC host. Firstly, how to transfer files running in the external cloud

to the source MEC host, and secondly how to relocate an application instance and the user context to the target MEC

host.

For the file transfer there is a possible scenario: For OTT vendors that already have operations in the cloud, files

running in the cloud can be uploaded to a functional unit at the MEC host via a portal, such as a customer facing service

portal, where the cloud file template can be converted to an image file that can be instantiated in the MEC hosts.

ETSI

ETSI GS MEC 002 V2.1.1 (2018

10)

Relocation of an application instance from the external to the target MEC host can follow the applications relocation

approach between MEC hosts. When MEC is deployed in a 5G network, the target UPF of 5G is selected based on UE

location and DN connecting to the MEC host which the applications are running on. When the UE moves to the target

MEC host serving area the 5G network may provide the information of the target UPF to the MEC system to identify

the target MEC host for application relocation. Therefore, the external cloud can transfer both the user context (by

client, MEC system assists or other assists) and/or application instance to the target MEC host based on the information

reported by the MEC system.

4.8 Representation of features

The present document describes requirements towards the framework and architecture of Multi-access Edge

Computing.

In addition to the definition of requirements applicable to all deployments, the present document introduces the concept

of features in order to cater for the different needs of different deployments. A feature is defined as a group of related

requirements and is assigned a unique name.

Support for a feature can be mandatory, optional or conditional. Where feature level support is optional or conditional,

all other requirements (mandatory or optional) related to that feature are themselves dependent upon support for the

feature itself.

The following example illustrates an optional feature with a conditional mandatory and a conditional optional

requirement.

EXAMPLE: [Req-1] The MEC system may support a feature called XYZ.

[Req-2] When the MEC system supports the feature XYZ, the system shall…

[Req-3] When the MEC system supports the feature XYZ, the system may…

The architectural framework needs to support mechanisms to identify whether a specific feature is supported. Such

information might need to be considered when executing certain tasks, such as the instantiation of an application.

5 Generic requirements

5.1 Requirements on the framework

[Framework-01] The design of the MEC system should attempt to reuse the NFV virtualisation infrastructure and its

management functionality, as described in the NFV architecture framework in ETSI GS NFV 002 [i.4], possibly with

some enhancements. Concepts that have been developed or studied in NFV Group Specifications and that are needed

for Multi-access Edge Computing should be reused whenever possible. This might require some enhancements specific

to Multi-access Edge Computing.

[Framework-02] It shall be possible to enable the deployment of MEC applications on the same infrastructure as ETSI

NFV-based VNFs.

[Framework-03] It shall be possible to deploy the MEC platform on MEC hosts in various locations of the fixed, mobile

and wireless networks, including radio nodes, aggregation points, gateways, and in a distributed data centre at the edge

of the Mobile Core Network.

[Framework-04] It shall be possible to deploy the MEC platform, applications and services in a more centralized

location in the operator's or service provider's data centre.

[Framework-05] It shall be possible to deploy the MEC host in various stationary or moving nodes.

NOTE 1: A moving node could be e.g. an access point type device with wireless backhaul or a passenger vehicle.

NOTE 2: Some requirements might not be fulfilled by certain deployment options.

[Framework-06] The MEC system should provide capability to interact with the 5G core network on behalf of

applications to influence on the traffic routing and policy control of UPF (re)selection and allow the corresponding user

traffic to be routed to the applications running on MEC host.

剩余65页未读，继续阅读

samLi0620

粉丝: 1184
资源: 1万+

多接入边缘计算（MEC）第二阶段用例与需求

中国联通智能MEC技术白皮书.pdf

5G MEC白皮书.pdf

Optimizing Multi-UAV Deployment in 3D Space to Minimize Task Completion Time in UAV-Enabled Mobile Edge Computing Systems

Deep Reinforcement Learning Approach for UAV-Assisted Mobile Edge Computing Networks

5g mec 技术白皮书

多接入边缘计算mec及关键技术 pdf

车联网移动边缘服务器布局实现代码

MEC环境为什么是高度动态的

Python绘图中mec和mfc

mec移动边缘计算源码

matplotlib mec

多用户mec网络示意图

SDN辅助的MEC架构

5G+MEC远程医疗监测的战略与规划步骤

5G+MEC医疗监测技术风险概述

matlab mec卸载多载波 复现

边缘计算mec系统源代码

基于时间帧的多用户MEC网络模型在智能车辆的随机计算卸载中的好处

如何写5G+MEC+专网的高速体检服务体系

最新资源

matlab mec卸载多载波复现