> For the complete documentation index, see [llms.txt](https://zzcabbage.gitbook.io/great-oai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zzcabbage.gitbook.io/great-oai/mec-progress/dc-ca.md). # DC/CA ## 远距离场景和大延时情况下分流性能研究 探究CA远距离场景和长延时情况下下分流机制性能下降的原因：（2020.3.24） 1. HARQ增加导致丢包 2. 乱序深度增加导致TCP性能下降 ### 远距离：TCP拥塞控制机制 一种可能的原因是由于基于丢包的TCP拥塞控制机制会主动提升窗口来触发丢包，以丢包的情况来确定链路的发送能力。而这样的探测机制会导致“缓冲区膨胀”，在单链路的情况下缓冲区膨胀会造成传输中的排队时延变长，不会影响整体的吞吐率性能。但是在分流的情况下，留在不同链路缓冲区中的数据可能会导致对端接收乱序增大，降低TCP连接窗口，从而影响分流性能。 {% file src="/files/-M3eIpLly6L2gXjtEIkA" %} ### 大延时：RLC机制 在NR链路中，RLC层取消了重排序机制，只负责数据包的快速封装和解密，由PDCP保证数据包的顺序。 然而在我们的仿真实验平台中，PDCP PDU经过了不同链路之后分配到不同的RLC缓存中，它们被同时作为RLC SDU打包成RLC PDU，经过链路发送到接收端。可以合理怀疑： 1. 接收端RLC PDU不存在乱序，因为发送端RLC同时完成了数据包封装。 2. 接收端PDCP PDU不存在乱序，因为我们的实验仿真平台中RLC层存在重排序机制。 3. **可能**在RLC层解密RLC SDU的过程中，得到的PDCP PDU是乱序的，经过重排序机制按序递交到了接收端PDCP层。 ### 总结 距离是否影响性能？延时是否影响性能？应该是存在影响的。 * 从距离上来看，过小的带宽在单链路情况下对TCP机制不会有太大影响，但是分流场景会让缓冲区挤压的数据包存在乱序的可能。为什么在我们的实验场景中不存在/观测不到这样的场景，我认为的原因有两个，首先的分流场景过于简单，不容易从数值结果上发现缓冲区膨胀带来的影响；其次是分流初始比例为1：1，这与单链路带宽比较为接近，使得远距离场景性能不容易下降。 * 从时延上来看，我认为时延固然带来数据包乱序和分流机制观测上的难题，但是十几毫秒内的延时不是导致性能急剧恶化的元凶，无线系统L2的各子层对延时问题应当是具有一定的容忍度的。当然了，我对仿真平台中的X2链路实现保持怀疑的态度。 * 从理论上看，我认为在单链路带宽之和作为分流基线的情况下，与单链路带宽比例相适应的分流方法是分流机制设计的核心要素。换言之，以该比例作为基准校验分流平台参数设置和流程安排是可行的。诚然简单的分流比例配置存在一定弊端，不过其它的机制优化是高楼大厦锦上添花的装饰，不应成为撼动根基的理由。 ## LTE/5G RLC对比（2020.3.24） {% hint style="info" %} 参考3GPP R15 38.322 (5.2.3) {% endhint %} ### RLC 功能 RLC（Radio Link Control）层位于PDCP层（或RRC层）和MAC层之间。它通过RLC通道（RLC channel）与PDCP层（或RRC层）进行通信，并通过逻辑信道与MAC层进行通信。RLC配置是逻辑信道级的配置，一个RLC实体（RLC entity）只对应一个UE的一个逻辑信道。RLC实体从PDCP层接收到的数据，或发往PDCP层的数据被称作RLC SDU（或PDCP PDU）。RLC实体从MAC层接收到的数据，或发往MAC层的数据被称作RLC PDU（或MAC SDU）。 * **分段/重组RLC SDU**（segmentation / reassembly，只适用于UM和AM模式）：在一次传输机会中，一个逻辑信道可发送的所有RLC PDU的总大小是由MAC层指定的，其大小通常并不能保证每一个需要发送的RLC SDU都能完整地发送出去，所以在发送端需要对某个RLC SDU进行分段以便匹配MAC层指定的总大小。相应地，在接收端需要对被分段的RLC SDU进行重组，以恢复出原来的RLC SDU并递送给上层。 * 通过**ARQ**进行纠错（只适用于AM模式）：MAC层的HARQ机制的目标在于实现非常快速的重传，其反馈出错率大概在0.1\~1%左右。对于某些业务，如TCP传输（要求丢包率小于10-5），HARQ反馈的出错率就显得过高了。对于这类业务，RLC层的重传处理能够进一步降低反馈出错率。 * **重复包检测**（duplicate detection，只适用于AM模式，UM模式不支持重复包检测）：出现重复包的最大可能性为发送端反馈了HARQ ACK，但接收端错误地将其解释为NACK，从而导致了不必要的MAC PDU重传。当然，RLC层的重传（AM模式下）也可能带来重复包。 * 对RLC SDU分段进行**重分段**（re-segmentation，只适用于AM模式）：当一个RLC SDU分段需要重传，但MAC层指定的大小无法保证该RLC SDU分段完全发送出去时，就需要对该RLC SDU分段（注意：不是对AMD PDU进行重分段）进行重分段处理。 * **RLC SDU丢弃处理**（只适用于UM和AM模式）：当PDCP层指示RLC层丢弃一个特定的RLC SDU时，RLC层会触发RLC SDU丢弃处理。如果此时没有将该RLC SDU，或该RLC SDU的部分分段递交给MAC层，则AM RLC实体发送端或UM发送端实体会丢弃指示的RLC SDU。也就是说，如果一个RLC SDU或其任意分段已经用于生成了RLC PDU，则RLC发送端不会丢弃它，而是会完成该RLC SDU的传输（这意味着AM RLC实体发送端会持续重传该RLC SDU，直到它被对端成功接收）。当丢弃一个RLC SDU时，AM RLC实体发送端并不会引入RLC SN间隙。 * **RLC重建**：在切换流程中，RRC层会要求RLC层进行重建。此时RLC层会停止并重置所有定时器，将所有的状态变量重置为初始值，并丢弃所有的RLC SDU、RLC SDU分段和RLC PDU。在NR中，RLC重建时，接收端是不会往上层递送RLC SDU的。这是因为NR中的RLC层不支持重排序，只要收到一个完整的RLC SDU，就立即往上层送，所以接收端不会缓存完整的RLC SDU。（而在LTE中，RLC重建时，接收端可能往上层递送缓存中可以重组出的完整RLC SDU，并且这可能会导致PDCP层收到乱序的RLC SDU） ### 流程对比 ![LTE/NR RLC流程对比](/files/-M3ANlgSE5WUZH00SziS) 在LTE中，只有当MAC层通知RLC实体有一个传输机会，并同时告诉RLC实体在这次传输机会中可传输的RLC PDU的总大小时，RLC层才会分段/串联RLC SDU以生成一个匹配MAC层指定大小的RLC PDU。也就是说，针对一个逻辑信道，一次传输机会只会发送一个RLC PDU，该PDU可能由一个或多个RLC SDU或RLC SDU分段组成。 但在NR中，RLC层无需等待MAC层指示的传输机会，直接将每一个RLC SDU构造成一个RLC PDU，即每个RLC SDU对应一个RLC PDU（而在LTE中，通常由多个RLC SDU串联成一个RLC PDU），但RLC PDU要真正发往MAC层还是需要等待MAC层指示的传输机会。对于UM和AM模式而言，当MAC层指示的可发送的所有RLC PDU的总大小无法保证每一个需要发送的RLC SDU都能完整地发送出去时，某个RLC SDU可能被分段，并使用2个或更多个RLC PDU来传输（在不同的传输机会上）。也就是说，针对同一个逻辑信道，一次传输可能会发送多个RLC PDU，且每一个RLC PDU由一个RLC SDU或RLC SDU分段组成。 简单地说，在NR中，对于UM和AM模式而言，RLC层从PDCP层接收到一个RLC SDU后，可立即生成一个RLC PDU（包含了头部信息），并保存在传输buffer中（即在收到MAC层指定的传输机会之前，预先生成RLC PDU，其目的是为了降低时延）。等到MAC层指示对应逻辑信道有一个传输机会，并同时指定了这次传输机会中对应逻辑信道可传输的数据量时，MAC层会将该逻辑信道对应的传输buffer中的RLC PDU串联起来。但MAC层指定的大小未必能够保证参与串联的每一个RLC PDU都完整地发出去。如果参与串联的最后一个RLC PDU大于剩余的数据量时，该RLC PDU对应的RLC SDU就需要被分段，并重新生成RLC头部以及新的RLC PDU（包含了此RLC SDU的部分数据）。 也就是说，在NR中，**RLC层移除了RLC SDU的串联（concatenation）功能**（在LTE中，允许将多个RLC SDU或RLC SDU分段串联在一起生成一个RLC PDU，而这在NR中是不支持的），而是由MAC层负责对RLC PDU进行串联，其目的是为了使RLC和MAC层能够提前进行预处理（pre-processing），以减少处理时延。这与LTE的上行传输中，为了构造TB，RLC PDU和MAC PDU需要等接收到UL grant之后才能够生成是不同的。 在LTE中，MAC层的HARQ操作可能导致到达RLC层的报文是乱序的，所以需要RLC层对数据进行重排序（reordering），并按序将重组后的RLC SDU发送给PDCP层，也就是说，RLC SDU n必须在RLC SDU n+1之前发送给PDCP层。但是RLC层的按序递送可能会给PDCP层的解密操作带来较大的时延。假如RLC层在SDU n之前成功接收到了SDU n+1，那么PDCP层需要等到RLC层收到RLC SDU n并递送给PDCP之后才能收到RLC SDU n+1。 在NR中，移除了RLC层的重排序功能，即**RLC层不支持按序递送RLC SDU给PDCP层**。RLC层在收到一个完整的RLC SDU后，就立即递送给PDCP层处理（PDCP层可以提前做解密操作），而无需关心之前的RLC SDU是否已经成功接收到，从而降低了RLC层的处理时延。也就是说，RLC层送往PDCP层的数据可能是乱序的，数据的按序递送（包括重排序）由PDCP层来负责。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://zzcabbage.gitbook.io/great-oai/mec-progress/dc-ca.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.