端到端分析思路及案例介绍

端到端优化案例1、端到端优化流程核心网侧和无线侧并不是孤立的个体，在优化过程中如能结合优化，可以发现更多更深入的网络问题，利于发现网络隐患，提升用户感知。

结合最近对SGSN01的Gb口分析时发现的部分小区存在ATTACH指标异常的情况。

为了分析核心网到无线网的优化流程，因此，以这部分小区为分析基础，结合核心网侧和无线侧对这部分小区进行优化处理，并将过程形成流程，希望能起到抛砖引玉的作用，共同完善网络质量。

下面总结了本例的分析流程，以此做为数据业务端到端优化流程的参考：2、核心网侧Gb口信令分析通过对SGSN01的Gb口分析，发现部分小区的ATTACH指标异常，下面挑选ATTACH成功率小于60%，而且附着尝试数》1000的小区进行分析。

为了更直观的发现问题，可用图的形式表示：由于附着丢失次数较多，占附着尝试次数比例大，因此，通过上述指标分析可知这几个小区的接入性能不好的，需要优化手段提升用户感知。

3、无线侧统计指标分析如是无线侧的问题影响到核心网的指标，任何核心网侧指标异常都会在无线侧的指标上有所体现的。

因此，为了分析这部分小区的ATTACH指标异常的原因，我们对这部分小区无线侧的指标统计进行分析。

发现这部分小区的下行TBF掉线数均较多，收集这部分小区一天的下各COUNTER解析如下：LDISTFI:主要是由于无线资源不足导致的TBF掉线；LDISRR：由于无线原因导致的掉线，包括小区重选、RAU更新等；LDISOTH：由于其他原因导致的TBF掉线；FLUDISC：跨BSC小区重选导致的TBF掉线数。

通过分析得知，ZJRYJN1（跃进路1）小区的下行掉线数是这部分小区中最严重的，一天下行TBF掉线数超3000次；在Gb口信令分析中也发现这小区的ATTCH失败数最多，达3100多次。

为此，我们认为核心网侧的ATTACH成功率和无线侧的下行TBF建立成功率指标是相关联的，同理我们认为导致Gb侧的ATTACH分配成功率低和小区下行TBF掉线率高的原因应该是相同的，换句话说，解决了Gb侧的分配成功率低问题，无线侧的下行TBF掉线率高的问题也相应解决了。

对“端到端”原则的理解前些天读了两篇论文,一篇是J.H.Saltzer,D.P.Read 和 D.D.Clark 在80年代初发表的《The End-TO-End Arguments in System Design》，另一篇是David D.Clark在前篇论文发表近20年后写的《Rethinking the Design of the Internet-The end to end arguments vs. the brave new world》，这两篇论文都是网络设计原则方面的重要理论探讨。

《The End-TO-End Arguments in System Design》这篇论文提出了一个著名的“端到端原则”，文章考虑的一个重要问题是如何在功能之间进行合适的划分，如何将功能安置到合适的层中。

通讯系统设计的主要目标是要让传输中各种错误发生的概率降低到一个可以接受的水平。

对于一个通讯可靠系统，它的出错率应该是很低的，而且只需通过简单的多次传输就可以实现系统的目标。

当然也可以采用“端到端确认重传”来实现，这时就要考虑这些功能在系统中什么地方实现，即层次上的考虑。

设置功能时要考虑两个因素的权衡：代价和性能。

通常底层的功能可以提高系统的性能（如底层的校验机制），但全局的代价较大（overall cost）。

在文中作者通过几个例子（传输保证、安全传输、时序控制以及实务管理）来说明将一些功能放到高层（End）是有利于系统的实现和性能提高的。

同时也强调一点：任何应用对功能的需求都是有特指的，因此不可能存在一种底层的功能满足所有的上层应用需求。

任何底层功能的设定都是高全局代价的。

因此，某些功能的不完全实现往往是提高系统功能的好办法。

作者认为网络传输是不可靠的，即由于错误的复制或缓冲，硬件处理器或记忆短暂的错误等各种原因会出现数据包的丢失和损坏，因此在网络的最核心的部分应该只做数据的传输而不能去做一些其他的应用，而数据是否正确传输则应该放到应用层去检查和判断——由此产生了我们今天网络应用层上的确定重传机制。

5G端到端智慧运维分析与实践的创新案例XX网络运营部XXXX年XX月目录5G端到端感知分析与实践 (3)一、概述 (3)二、创新方案 (4)2.15G新业务建模 (4)2.2现网部署方案 (7)2.3现网实践效果 (8)三、经验总结 (20)3.1价值描述 (20)3.2总结与展望 (20)5G端到端智慧运维分析与实践作者：郑淑琴、肖慧【摘要】随着5G网络业务的快速发展，网络架构越发复杂，技术难度不断攀升，多样的应用与垂直行业深度融合给网络运营维护带来了全新的挑战。

为支撑5G商用，解决业务差异化保障复杂性大、分层跨域协作运维难的问题，必须具备敏捷、集中、自动、智能的运维能力。

本文描述了XX电信在5G端到端智慧运维体系的创新方案与实践成果。

XX电信在全集团、乃至全球率先进行5G SA/NSA新业务建模，可支持识别1000+主流2C业务场景，具备8000+字段支撑感知建模评估，特别针对中国电信云VR游戏、云VR视频等5G 2C新业务建立了业界第一套完整的业务质量评价体系；同时，针对2B垂直行业构建了多元特征AI智能识别能力，识别99%典型2B行业业务，实现了SLA端到端保障、具备快速闭环自愈能力。

XX电信5G端到端智慧运维体系，实现了5G NSA/SA网络质量和5G 2C/2B业务体验的可视、可管、可回溯定位、可闭环优化，具备垂直行业的租户级运营保障能力，包含5G端到端网络运维保障、投诉支撑、市场支撑等多个模块，可节约运维成本225万元/年，带来潜在收益500万/年，实现了5G端到端网络的事先化、智能化、自动化运维，为XX电信打造高品质5G网络打下了坚实的基础。

【关键字】5G 端到端感知体验管理智慧运维【业务类别】端到端、核心网、智慧运维、感知分析一、概述5G时代已经到来，全新的网络架构以及3G/4G/5G长期共存使得网络越来越复杂；全新的技术使得OPEX不断攀升；4G时代通信业务主要是打电话、上网、玩游戏等语音和数据类业务，而5G多样的业务应用、与垂直行业深度融合使得业务差异化保障复杂性大幅提升；端到端网络云化使得分层、跨域协作运维难度加大，给网络运营维护带来多方面的挑战。

CTC Volte 组网方案CTC Volte 按大区集中建设，该方案将全国分为6个大区，控制面集中在大区中心部署，媒体面下沉至各本地网。

与分省建设不同点在于，除SBC/P-CSCF 新疆云江西贵成都西藏河南青海宁津广州广西湖南湖北海甘西安徽南京福浙蒙黑吉辽山东河北山西Volte 端到端网元及问题归类VoLTE 语音业务流程穿过网元多（18+），接口多（24+），维护困难，问题排查难附着/注册、接续、保持、切换四个维度展开分析IMS网元多连接复杂注意:CTC没有SRVCC！MMESGW PGWP-CSCF/BACI/S-CSCFIMS-HSSEPC网络IMS网络PCRFMMTEL ASUE业务配置代理网关L-DRAEPC-HSSH-DRAVoLTE 业务平台大区省附着流程•主要信令流程：•主要相关网元：UE/MME/SGw/PCRF/HS•主要步骤：附着问题分析流程1.首先关注附着环节相关指标，指标环比/同比趋势情况。

2.附着指标变差后，进一步分析附着过程相关三个主要指标VoLTE附着成功率、PDN连接建立成功率、默认承载建立成功率是否存在指标较差的情况。

3.如果存在指标劣化，再进一步采用聚类/时域分析方法，判断问题是否聚焦在某个MME、eNodeB、或SGW上。

如果存在聚焦，再采用关联分析方法，将网元维度与终端、用户进行关联分析，确定问题是否由某个终端或用户引起。

4.再根据原因值并根据归类算法给出诊断结果，输出问题的定界，定界到用户、终端、核心网及无线四个环节。

LTE端到端分析思路及案例分析LTE（Long Term Evolution）是第四代移动通信技术，具有高速率、低延迟、高能效和大容量等特点。

在进行LTE端到端分析时，可以按照以下思路展开分析，并结合案例进行具体分析。

思路一：网络架构分析首先，对LTE网络架构进行分析，包括核心网和无线接入网的组成和功能。

核心网包括Evolved Packet Core（EPC）和多媒体子系统（IMS），无线接入网包括eNodeB（eNB）和用户设备（UE）。

分析网络架构时，可以关注各个网络节点之间的接口、协议以及功能模块的组成，了解数据在网络中的流动路径和处理过程。

案例分析：可以选择一个LTE网络部署的实例，如地区的LTE网络。

通过查阅网络文档或通过网络工具获取网络架构图，分析网络中各个节点的功能和接口之间的关系。

思路二：无线接入过程分析其次，分析无线接入过程，包括eNB和UE之间的初始接入、随机接入、RRC连接过程等。

在初始接入过程中，UE需要与eNB进行物理层和随机接入过程，获取系统信息、分配RNTI等。

在随机接入过程中，UE发送随机接入信令来请求建立RRC连接。

RRC连接建立后，UE可以与eNB进行数据传输。

案例分析：选择一个UE在初始接入过程中的日志数据，通过分析日志数据中的消息序列和信令流程，了解UE与eNB之间的握手过程和数据传输过程。

思路三：移动性管理分析移动性管理是LTE网络中的重要功能，包括切换和重定向两个方面。

切换是指UE在移动过程中从一个eNB切换至另一个eNB，以保持用户的连接稳定。

重定向是指UE在移动过程中从一个小区切换至另一个小区，以改善信号质量。

移动性管理需要考虑UE的上下文切换、控制面和用户面的切换以及数据平面的持续传输等问题。

案例分析：选择一个UE在移动过程中的日志数据，分析日志中的切换消息和事件，了解UE在移动过程中发生的切换和重定向行为以及对网络性能的影响。

思路四：QoS管理分析QoS（Quality of Service）管理是为了保证不同业务的服务质量而采取的一系列策略和措施。

LTE端到端分析思路及案例分析LTE（Long Term Evolution）是第四代移动通信技术，广泛应用于现代的移动网络通信中。

LTE端到端分析是对LTE系统中从用户设备到目标服务器的数据传输进行全面、深入的分析和诊断。

下面将介绍LTE端到端分析的思路以及一个实际案例的分析。

一、LTE端到端分析思路：1.确定测试目标：确定需要分析的LTE网络中的哪一部分，比如用户设备、基站、核心网等。

2.收集数据：使用抓包工具，收集LTE系统中的网络流量数据，包括用户设备与基站之间的无线通信数据、基站与核心网之间的协议数据等。

3. 数据解析：对收集到的数据进行解析，将其转换为可读的数据格式，如Wireshark等流行的抓包工具可以对LTE协议进行解析。

4.数据分析：对解析后的数据进行分析，统计关键指标，如网络延迟、数据丢包率、带宽利用率等，以评估网络性能。

5.问题定位：根据分析结果，定位网络问题的具体位置，确定是用户设备、基站还是核心网的问题。

6.问题解决：根据问题定位结果，采取相应的措施解决网络问题，如调整用户设备的配置、优化基站的信号覆盖、调整核心网的负载等。

7.监控与优化：持续监控LTE网络的性能，不断优化网络配置，以提升用户的通信体验。

二、LTE端到端分析案例分析：假设一个LTE网络中存在用户设备连接问题，用户设备在连接到基站时出现频繁掉线的情况。

以下是一个LTE端到端分析案例的分析步骤：1.收集数据：使用抓包工具对用户设备与基站之间的无线通信数据进行抓包，收集通信过程中的数据包。

2. 数据解析：使用Wireshark对抓包数据进行解析，查看LTE协议中的消息内容，了解设备与基站之间的通信过程。

3.数据分析：通过统计解析后的数据包，计算用户设备连接成功率和掉线率等关键指标，以判断问题的严重程度。

4.问题定位：通过分析抓包数据中的消息内容，查看设备与基站之间的握手过程、认证过程等，确定问题出现在哪个环节。

端到端参数不适配导致5G语音呼叫回落2G问题处理案例案例上报省份：河南案例上报人：李军一、关键词：呼叫失败、VOLTE、AMBR限速二、案例分类1.问题分类：网络性能2.手段分类：参数调整三、优化背景随着5G牌照发放及5G终端发布，5G用户数量不断增长，关于5G网络的投诉问题开始显现。

近期河南公司按照集团要求将5G用户上行峰值速率设置为100Mbps后，出现5G用户拨打电话回落2G的问题,对此展开问题分析优化处理。

四、问题现象5G终端在进行VOLTE呼叫过程中,出现大概率回落2G的问题,不能正常进行VOLTE语音通话，如下图所示：图1 VOLTE呼叫回落2G五、原因分析1)终端及基站问题排查：经查询，5G基站侧无告警信息，且更换基站和5G终端后分别进行测试，该问题依旧存在，初步排除终端和基站侧原因；2)信令跟踪分析：跟踪语音呼叫信令发现，VoLTE起呼时Invite消息的两个分片基站都已收到并发往核心网，但是长时间得不到核心网响应；图2 VoLTE呼叫失败主叫侧基站发出Invite消息对比正常VoLTE呼叫的Invite消息，两个分片的时间间隔较短，不到1s，而呼叫失败的Invite消息两个分片的时间间隔都超过了1s。

经核心网侧确认，如果核心网收到的Invite消息两个分片时间间隔超过1s，就会主动丢弃第二个分片，最终导致VoLTE呼叫失败：图3 VoLTE呼叫成功主叫侧基站发出Invite消息分析PDCP层对应Invite消息分片间隔，确认都已超过1s，如图4：图43)Invite消息分片时间间隔过大分析：Invite消息对应上行RLC出现大量分片，分片过多引起上行数据发送较慢，时延增大，由此推测，Invite消息两分片间隔超过1s的主要原因是上行RLC分片过多导致，如下图所示：图5进一步分析上行RLC分片过多的原因。

目前NSA网络下，上行数据传输采用锚点和5G分流机制，根据集团要求将5G用户上行峰值速率限定在100Mbps，相当于锚点+5G的总带宽限定为100Mbps，其中基站分配给锚点和5G站点的带宽通过参数NSADCMGMTCONFIG.NSADCUEMCGULAMBRRATIO进行控制。

端到端网络边缘计算系统的设计与实现随着计算能力的不断提高和网络技术的不断发展，越来越多的应用场景需要将计算任务在网络边缘进行处理。

在边缘计算的背景下，端到端网络边缘计算系统的设计和实现成为了研究热点。

本文将介绍端到端网络边缘计算系统的设计思路和实现方法。

一、系统设计思路端到端网络边缘计算系统由三个组成部分构成：边缘节点、传输网络和云端节点。

它们构成了一个完整的计算系统，可以实现计算任务在网络边缘的处理和结果的实时传输。

下面我们分别对每一部分进行详细介绍。

1.边缘节点边缘节点是端到端网络边缘计算系统的核心组成部分，它是计算任务进行处理和结果进行传输的终端节点。

边缘节点一般包括 CPU、内存、存储和网络等关键组件，以及一些特定的软件和硬件配置。

边缘节点的主要任务是接受云端节点下发的计算任务，将其分解成多个子任务后分配给本地计算节点进行处理，并将处理结果传输回云端节点。

边缘节点还需要提供与云端节点的通信服务，确保计算任务的实时运行和数据的安全传输。

2.传输网络传输网络是端到端网络边缘计算系统的连接中心，主要负责边缘节点与云端节点之间的数据传输。

传输网络一般由物理网络、传输协议和网络拓扑等组成。

在传输网络中，物理网络是数据传输的实际载体，包括有线网络和无线网络。

传输协议是数据传输的约定方式，包括 TCP/IP 协议、HTTP 协议和 WebSocket 协议等。

网络拓扑是传输网络的结构形态，包括树形结构、星形结构和混合结构等。

在端到端网络边缘计算系统中，传输网络需要提供高速、可靠、安全和低延迟的数据传输服务。

3.云端节点云端节点是端到端网络边缘计算系统的核心组成部分之一，它是计算任务的控制中心和结果的数据中转站。

云端节点一般由大量的服务器组成，包括计算服务器、存储服务器和网络服务器等。

云端节点的主要任务是接受客户端下发的计算任务，根据任务类型、任务优先级和计算资源的负载等因素，将计算任务分配给最佳的边缘节点进行处理。

端到端的流程案例一、端到端流程的概念理解。

1.1 端到端流程啊，就像是一场从起点到终点的旅行。

这可不是简单的一段路，而是涵盖了整个业务或者项目从头到尾的全过程。

打个比方，就像你要做一顿丰盛的大餐，从去菜市场买菜这个最开始的环节，一直到最后把美味的菜肴端上桌，这中间所有的步骤加起来就是一个端到端的流程。

1.2 这个流程涉及到很多不同的部分，就像一部精密的机器，每个零件都得发挥作用。

比如说企业生产产品，从原材料的采购，到产品的设计、制造、包装，再到最后的销售和售后服务，一环扣一环，缺了哪一个都不行。

这就好比一条链子，每个环节都是链子里的一环，断了一环，整个链子就散架了。

二、端到端流程案例分析。

2.1 咱们就拿电商购物来说吧。

首先呢，顾客在网上看到了心仪的商品，这就是流程的开端。

顾客在电商平台上浏览各种各样的商品，就像在一个超级大的集市里闲逛，眼睛都看花了。

这个时候，平台的界面设计、商品展示这些前端的东西就很重要，要是界面乱七八糟的，商品图片也不清晰，那顾客可能看一眼就走了，这就好比你去一家饭店，一进门发现环境脏兮兮的，立马就没了食欲。

2.2 顾客下单之后，订单就像一个接力棒，传给了商家。

商家得赶紧处理订单，检查库存有没有货。

这就像打仗的时候，指挥官得知道自己的弹药库还有多少弹药一样。

如果没货了，那可就麻烦了，就像你答应了别人一件事，结果到时候发现自己根本做不到，这不是让人空欢喜一场嘛。

有货的话，商家就要安排发货，这中间涉及到物流的选择，就像选一个靠谱的信使去送信一样。

2.3 物流呢，就得风风火火地把商品送到顾客手中。

这过程中可不能出岔子，要是包裹丢了或者损坏了，那可就坏事了。

就像你千辛万苦种的瓜，到了收获的时候被人偷走了或者摔坏了，那得多心疼啊。

顾客收到商品，如果满意呢，这个流程就算是圆满完成了；要是不满意，还有售后服务这一环节，就像给顾客吃一颗定心丸，让顾客觉得自己的权益有保障。

三、端到端流程的重要性。

VoLTE呼叫时延端到端分析案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (8)四、经验总结 (8)VoLTE呼叫时延端到端分析案例【摘要】VoLTE语音呼叫建立时延是衡量VoLTE网络质量和客户感知的关键指标之一，呼叫时延的缩短，不但对减少网络信令资源消耗和减轻网络负荷具有重要价值，对提升客户体验和客户满意度也具有显著意义。

【关键字】VoLTE VoLTE时延端到端【业务类别】端到端优化一、问题描述滁州VOLTE DT测试，使用三星S7，Mate 9测试结果如下，可以看到，在测试定远县的过程中呼叫建立时延明显高于其他区域。

二、分析过程1、VOLTE时延优化思路VoLTE呼叫建立时延主要是通过对SIP信令进行分段计算，与参考基线对比，确定呼叫建立时延的GAP存在于哪一个阶段。

2、VOLTE呼叫时延分析使用鼎力软件进行分析，通过对VoLTE DT测试LOG进行主被叫联合分析，其中主叫发送INVITE请求到收到被叫发送的183消息时延大于3s；主叫发送UPDATE消息到收到200 OK 消息时延大于2s。

选取一次通话进行信令分析，呼叫建立过程中，UE无线覆盖环境良好，无质差，时间点23:09:39.242被叫收到INVTE请求，2s后即23:09:41.379才发送183消息；时间点23:09:42.527被叫收到UPDATE消息，2s后即23:09:44.568才发送UPDATE 200消息。

时延高由于被叫UE反馈相应SIP信令消息较晚导致，分析为终端问题。

3、VOLTE呼叫时延定位确认使用S7终端进行VoLTE业务测试，概率性出现呼叫时延长>6s问题，从路测信令分析，主要集中在2段：➢被叫终端收到INVITE消息->发送183，时延>2s➢被叫终端收到UPDATE消息->UPDATE 200，时延>2s从终端日志分析，问题确实集中在这2段根据终端侧PDCP配置，RB-Cfg_Idx是终端承载表示，RB-Cfg_Idx与承载对应关系如下图所示：➢RB-Cfg Idx=1对应EPS ID = 5，对应QCI=9，用于默认承载➢RB-Cfg Idx=2对应EPS ID = 6，对应QCI=5，用于承载SIP信令➢RB-Cfg Idx=1对应EPS ID = 1， SRB承载➢RB-Cfg Idx=2对应EPS ID =2， SRB承载根据RB-Cfg Idx=2，对应QCI=5所在承载，检查终端侧上行L2 PDCP数据包：发送100trying后，PDCP看到发送一个数据包，包长442过了1.5s（终端每500ms上报1次）一直到183发送前，PDCP数据包还是只有一个，包长不变442，说明PDCP没有新增数据（说明终端RTP层没有新的数据183发送至PDCP层。