4G到5G演进中的ETSI MEC部署
版权申诉
46 浏览量
更新于2024-07-18
收藏 1.37MB PDF 举报
"ETSI MEC Deployment in 4G and Evolution Towards 5G" 是一份由ETSI（欧洲电信标准协会）发布的白皮书，主要探讨了多接入边缘计算（Multi-Access Edge Computing, MEC）在4G网络中的部署策略以及向5G演进的路径。该白皮书由多位来自不同公司的专家共同撰写，涵盖了多个相关领域的专业知识。
MEC是一种将计算能力、存储资源和网络功能推向网络边缘的技术，旨在减少延迟、提高带宽效率和服务质量，特别是在需要低延迟和高数据吞吐量的应用场景中，如自动驾驶、虚拟现实和物联网。该技术对于4G网络的优化和5G网络的构建至关重要。
白皮书中讨论了以下关键知识点：
1. **Bump in the wire**: 这个术语通常指的是在现有网络基础设施中不引起显著性能下降的插入设备或功能。在4G MEC部署中，它可能意味着在无线接入网（RAN）和核心网之间添加MEC节点，提供本地数据处理，而无需将所有流量回传到中央数据中心。
2. **Distributed EPC (Evolved Packet Core)**: 分布式EPC是将传统集中式的核心网功能分散到网络边缘，通过MEC来实现，以降低延迟并增强网络性能。这允许更快的数据处理和更高效的资源利用，尤其是在处理大量实时数据流的场景下。
3. **Distributed S/PGW (Serving Gateway / Packet Data Network Gateway)**: 分布式S/PGW是MEC的一个具体应用，它将原本集中在中心位置的S/PGW功能分散到网络边缘，使数据处理更靠近用户终端，从而减少延迟，提高用户体验。
4. **4G网络的MEC部署挑战**: 白皮书还可能涉及4G网络中部署MEC所面临的挑战，包括网络架构的改造、技术标准化、互操作性、安全性和服务质量管理等问题。
5. **向5G的演进**: 随着5G网络的发展，MEC将在网络切片、边缘云和超低延迟服务等方面发挥更大作用。5G的特性，如更高带宽和大规模连接，将进一步推动MEC技术的广泛应用。
6. **作者简介**: 文档列出了一系列作者，他们来自不同的公司，如NEC、Athonet、Intel、ZTE等，这些公司在通信技术领域有深厚的背景，他们的贡献确保了白皮书的专业性和全面性。
这份白皮书深入探讨了MEC在4G网络中的实际部署策略，并展望了其在5G时代的未来，对于理解MEC技术如何改善移动网络性能和推动5G发展具有重要价值。
MEC Deployments in 4G and Evolution Towards 5G
5
Deploying MEC in 4G networks: scenarios and
challenges
As per the GS MEC 011 [2] specification, a key baseline functionality of the MEC platform is to route IP
packets to MEC applications which are meant to handle the traffic in the following different ways:
In Breakout mode, the session connection is redirected to a MEC application which is either hosted
locally on the MEC platform or on a remote server. Typical breakout applications include local CDN,
gaming and media content services, and enterprise LAN.
In In-line mode, the session connectivity is maintained with the original (Internet) server, while all
traffic traverses the MEC application. In-line MEC applications include transparent content caching
and security applications.
In Tap mode, specified traffic is duplicated and forwarded to the tap MEC application, for example,
when deploying virtual network probes or security applications.
In Independent mode, no traffic offloading function is needed, but still the MEC application is
registered in the MEC platform and will receive other MEC services, such as DNS, Radio Network
Information Service (RNIS), etc.
Steering traffic to/from MEC applications is achieved by configuring the MEC’s local DNS and the MEC
host’s data plane accordingly. From the list above, it appears straightforward that the implementation-
specific details of the data plane within the MEC host (as per the MEC architecture in GS MEC 003 [3]) and
the MEC platform, which is meant to program the data plane through Mp2 interface, are impacted by the
point where the MEC host is installed in the 4G architecture. Many choices are possible, but all in all they
can be condensed down into some base scenarios discussed in the following sections.
Bump in the wire
The expression “bump in the wire” encompasses all the scenarios in which the MEC platform installation
point ranges in locations between the base station itself and the mobile core network. These options
were first proposed in the MEC Introductory White Paper [1] and reproduced in Figure 1.
When the eNB implementation bundles the MEC platform into a single implementation, this latter is able
on the one hand to route plain IP packets to/from the MEC applications (i.e., local switching mode), and
on the other hand to route GTP-encapsulated packets to/from the Serving Gateway (SGW) for regular
traffic as per the operator-configured Packet Data Networks (PDNs - i.e., the legacy S1-U mode). This
deployment is very convenient e.g., in enterprise scenarios to allow intranet traffic to breakout to local
services (similar to Local IP Access - LIPA), and also when MEC is co-located with a CRAN deployment (see
the ETSI white paper “Cloud RAN and MEC: a Perfect Pairing” [4].)
In all the other locations, either in proximity of the radio node or at an aggregation point, the MEC
platform sits on the S1 interface of the 4G system architecture. In this scenario, the MEC host’s data plane
has to process user traffic encapsulated in GTP-U packets, thus requiring the appropriate handling of
these tunnels. This non-trivial operation poses some challenges, as a portion of the data may be
generated or manipulated internally in the MEC hosts or may come from a local breakout, without
passing through the core of the network. For this traffic, a dedicated solution may be required (e.g., the
MEC GW in Figure 1) to handle operations such as lawful interception and charging. This solution can
support CUPS, which ensures a 3GPP-compliant solution (see sections below). Also, in this solution, low
剩余23页未读，继续阅读
2021-09-10 上传
2021-09-30 上传
111 浏览量
2021-10-13 上传
2020-02-15 上传
2021-08-25 上传
2021-09-14 上传
2018-05-09 上传
2021-09-20 上传
samLi0620
- 粉丝: 1609
- 资源: 1万+
我的内容管理
展开
最新资源
- mattgirdler.github.io
- cloudinary_public:Dart包装器，可将媒体文件上传到cloudinary
- ulabel:基于浏览器的图像批注工具
- lickwolf.github.io
- .NET在线二手交易系统的ASP毕业设计(源代码+论文).zip
- mern-react：使用Javascript创建Staycation前端（ReactJS）
- Accuinsight-1.0.24-py2.py3-none-any.whl.zip
- js-algorithms:各种算法的 JavaScript 实现
- WebCursos
- workers-forms
- ajalabs_placeholder:AJAlabs.com当前的占位符网站
- 基于web的实验室管理系统毕业设计（自动排课功能的实现）.zip
- fbfgbfqq
- 博客
- Qt6可进行录像录音代码特性
- voxel_survival
