5G业务信道用户容量分析

曹艳霞，尹志宁，张忠皓（.中国联通研究院，北京 00048；.大唐移动通信设备有限公司，北京 00083）

1 概述

随着中国5G 牌照的发放，5G 建设大幕正式开启。如何高效规划一张5G 网络是运营商关注的重点。5G提出了三大应用场景：增强移动带宽（eMBB）、大连接物联网（mMTC）、超高可靠低时延通信（uRLLC）。与4G 相比，5G 的应用场景更加细化，5G 网络承载的业务形态也更加复杂，随着5G 生态的演进与完善，必将产生大量业务应用，准确掌握5G网络承载能力是保障网络业务体验的重要前提，5G网络容量研究分析将是贯穿5G建设始终的重要课题。

本文从网络承载用户数量角度，以典型的eMBB业务为基础、通过精细化的业务模型和无线协议层开销分析的方法，对5G 网络系统容量进行分析，并定义多种用户容量，包括等效在线用户数、实际在线用户数和背景用户数，以用于不同的网络容量参考。

2 业务速率分析

本文对用户容量的分析方法，是基于精细化的业务源数据包模型，通过对数据包经过无线网络的协议开销进行分析，以此分析业务的空口速率需求，从而对系统承载用户容量分析。精细化分析方法中的“精细”体现在空口速率的获取过程中，本文所指的空口速率是指到达物理层的HARQ 初传数据速率。具体步骤如下。

a）基于核心网的抓包数据，得到5G 业务源模型，进而得到业务源的数据下发速率。

b）基于空口高层协议开销分析，可以求得每种业务对应的空口速率。

c）基于仿真得到的小区平均频谱效率以及基于带宽、上下行时隙配置和时隙内符号配比，可以得到上下行可承载的数据速率，即小区平均吞吐速率。

d）基于话务模型，得到混合业务状态下的5G 系统业务信道容量。

2.1 业务源模型

本文的业务源模型以eMBB 为基础，覆盖了传统业务及5G 新兴的个人业务。除了新兴业务，5G 的业务比例也发生了变化，比如流媒体业务的比例增大了。本文的NR容量计算基于如表1所示的NR业务源模型。

表1 5G业务源模型

NR 业务可以分为基于TCP 协议的业务和基于UDP协议的业务。TCP协议基于比特流，面向连接，存在反馈重传机制，能保证数据的正确传输，可靠性很高，不过时延较大，类似于RLC AM 模式。FTP下载/上传和HTTP 网页浏览这2 种业务基于TCP 传输。TCP协议引入了丢包检测、慢启动等机制，存在发送窗口，能起到流量控制的作用，能基于底层链路特性下发或缓存数据包，从而可以控制数据下发速率。UDP 协议基于数据报文传输，不存在端到端的连接。因为不存在ARQ 机制，因此不能保证数据的正确传输，在网络出现拥塞时可靠性无保障，但传输时延较小，类似于RLC UM 模式。微信、视频流和UDP 传输一般都属于这种情况。UDP 传输不能够缓存数据包。但是为了简单起见，可以认为：下发到SDAP 层的数据速率就是业务源的数据下发速率。根据上面的业务模型，可以得到如表2所示的结果。

表2 业务源数据下发速率

2.2 协议开销分析

业务对空口速率的需求分析，主要考虑业务经过高层协议栈的开销。在考虑NR 空口高层协议开销时，暂时不考虑控制平面的信令消息，例如RRC 消息、NAS 消息等。在用户平面，封装了业务数据的QoS 流数据包直接到达空口的SDAP 子层，经历了层二的各个子层之后，被封装在传输块中经过HARQ 过程实现UE 与eNB 之间的递交。层二包括如下协议子层：SDAP 子层、PDCP 子层、RLC 子层和MAC 子层。为了完成IP 数据包的有效可靠递交，每一个子层都将引入特定的协议头和控制过程开销。本节将详细描述各个子层的开销，并汇总数据包在高层协议处理过程中引入的总开销。各个子层之间的关系如图1所示。

2.2.1 SDAP协议子层开销分析

5G 的QoS 划分更加精细，因此引入了SDAP（Service Data Adaptation Protocol）适配层为QoS 流和数据无线承载（DRB）之间做映射。1 个或多个QoS 流可以被映射到同一个DRB上。

SDAP 协议数据单元（PDU）分为数据协议数据单元（data PDU）和控制协议数据单元（control PDU）。数据PDU 主要用于传送SDAP 头和用户面数据。控制PDU 又叫结束标记控制PDU（End-Marker Control PDU），被UE 侧的SDAP 实体使用，用于指示此控制PDU 不再映射QFI指示的QoS流到传输此控制PDU 的DRB。数据PDU 可以带SDAP 头或者不带，相应的数据PDU的协议头开销为0或8 bit（见表3）。

2.2.2 PDCP协议子层开销分析

在PDCP 子层，对于用户平面的IP数据包，一般会执行如下操作。

a）头压缩。头压缩操作会影响业务数据包的开销计算。业务初期未压缩的数据包和业务激活期半压缩的数据包，数量较少，不予考虑。

图1 高层结构视图

表3 SDAP协议头开销

b）加密。加密操作不影响数据包的大小，因此不作分析。

c）重排序和复制。不影响数据包大小，此处不作分析。

d）切换过程中，PDCP 子层收发端可能交互状态报告。因为状态报告数据包出现的概率和数据比例都很小，在估算开销时暂时不予考虑。

e）封装。PDCP 子层对IP 数据包进行封装，添加SN 等信息，以辅助实现此协议子层的功能，需要分析PDCP子层PDU格式引入的协议头开销。

目前协议只支持ROHC 头压缩协议，ROHC 头包括1 B 的ROHC 数据包类型信息（包含格式标识、2 bit的CRC和压缩序列号），以及1～2 B的上下文标识（CID——Context Identifier）信息，共占用2～3 B。一般协议上假设CID 占用2 B，则ROHC 头占用3 B。TCP/IP 协议压缩头固定占用2 B。在本文后续章节，都假设压缩后的头长度为5 B。承载业务数据的IP 数据包经过头压缩后，得到的压缩数据包的格式如图2所示。

PDCP SDU（即SDAP PDU数据包）经过PDCP子层的处理后，得到对应的PDCP PDU 并递交给RLC 子层进行传输。基于协议规定，PDCP 协议头开销不区分RLC模式，具体汇总如表4所示。

2.2.3 RLC协议子层开销分析

图2 压缩数据包格式

表4 PDCP协议头开销

RLC 层功能较多，包括分段/重组RLC SDU（只适用于UM 和AM 模式），ARQ 纠错（只适用于AM 模式），重复包检测（只适用于AM 模式），重分段（只适用于AM 模式），RLC SDU 丢弃处理（只适用于UM 和AM 模式），RLC 重建等。与LTE 相比，NR 的RLC 层移除了RLC SDU 的串联（concatenation）功能，转由MAC 层实现，移除了RLC 层的重排序功能，转由PDCP 层负责，其目的都是为了降低RLC层的处理时延。

RLC PDUs 可以分为数据PDUs 和控制PDUs。数据PDUs 涉及3 种RLC 模式：TM 模式、UM 模式和AM模式，其中TM 模式只用于控制平面，所以不做展开讨论，下面分析UM和AM模式。

UM 模式不存在引入额外开销的控制机制，因此只考虑协议头开销。一个UMD PDU 包含一个完整的RLC SDU 或者RLC SDU 分段。UMD PDU 头的长度与SN 长度有关，如表5 所示。当UMD PDU 包含一个完整的RLC SDU 时，UMP PDU 头不包含SN。SN 长度由高层根据需要配置，仅当业务数据速率要求较高且无线链路质量较好时才能配置采用6 bit的SN，正常情况下都配置采用12 bit 的SN。仅当UMD PDU 包含RLC SDU 分段且此分段不是第一个分段时，UMD PDU 头才包含16 bit的SO（Segment Offset）。

表5 UMD PDU头长度

AM 模式除了考虑包格式封装引入的协议头开销之外，还需要考虑ARQ 机制引入的重传开销和状态报告开销。

a）协议头开销分析。一个AMD PDU 包含一个完整的RLC SDU 或者RLC SDU 分段。仅当AMD PDU 包含RLC SDU 分段且此分段不是第一个分段时，AMD PDU 头才包含16 bit的SO（Segment Offset）。如表6 所示。

b）重传开销。经过低层的HARQ 传输后，RLCPDU 的成功递交概率已经很高，一般认为能够达到10-3级别。ARQ 机制用来重传HARQ 传输失败的PDU。一般经过一次ARQ 重传后，PDU 总传输功率已经足够高，剩余传输失败的PDU 可以不再单独考虑。在PDU重传时刻，如果MAC子层在传输机会中指示的可下发数据量无法容纳整个待重传的PDU，则需要对此重传PDU 对应的SDU 进行重分段。MAC 子层指示的可下发数据量由调度决定，考虑信道质量、缓冲区数据量、资源占用情况等因素会随机变化。重传PDU对应的RLC SDU 是否需要重分段以及重分段后得到的AMD PDU 分段数目都由此可下发数据量决定。重传和重分段引入的具体开销大小与协议头开销有关，在协议头开销中统一考虑。

表6 AMD PDU协议头长度

c）状态报告开销。状态报告有基于来自对端的探询和基于PDU丢失检测2种触发机制。当链路质量较好时，基于对端探询的状态报告触发机制占主导。这种机制依赖于PDU 中P 字段的设置，而P 字段的设置机制一般考虑基于传输的新AMD PDU 数目设置P字段。假设每收到一个设置了P 字段的PDU 后，触发传输一个仅包含ACK_SN 字段的状态报告。当无线链路质量较差时，基于PDU 丢失检测的状态报告触发机制占主导地位，这种机制在接收端重排序定时器超时后触发一个状态报告的发送，可以假设一个丢失的PDU（即重传PDU）对应一个只包含一个NACK_SN 记录的状态报告。

基于以上的分析，可以得出如下状态报告开销考虑方案。

a）每发送pollPDU 个新AMD PDU，则考虑对端AM 实体的接收侧触发发送一个只包含ACK_SN 字段的状态报告（基于对端探询的状态报告触发机制），大小为3 B。

b）AM 实体接收侧每检测到一个待重传PDU，则考虑触发发送一个只包含一个NACK_SN 记录的状态报告（基于PDU 丢失检测的状态报告触发机制），大小为5 B。

2.2.4 MAC协议子层开销分析

MAC子层主要考虑以下开销。

a）寻呼传输开销。寻呼的触发原因包括核心网触发、通知系统信息修改、通知ETWS消息等。其中核心网触发的寻呼一般用于通知用户呼叫的到来，与下行业务发起特性有关。系统信息修改触发的寻呼与网络系统信息修改的频繁程度有关。寻呼过程涉及的数据量相对较小，本文暂不考虑。

b）随机接入开销。随机接入过程中下行的随机接入响应消息和竞争解决消息，以及上行的Msg3都在共享信道上传输，影响业务数据的资源占用。随机接入响应消息中包含UE的Msg3传输资源分配信息和初始TA 调整信息。Msg3 中一般包含高层信令消息（RRC 连接请求消息、RRC 连接重建请求消息、RRC 连接重配完成消息）或者C-RNTI（上/下行数据到达触发的随机接入过程）。竞争解决消息仅在Msg3包含高层信令消息时包含竞争解决MAC CE 涉及开销，其他情况下通过PDCCH 直接实现竞争解决。因此这几种消息的大小都相对较小，对业务数据传输的资源影响较小，而且分析起来较为复杂。本文暂不考虑随机接入过程引入的开销。

c）MAC CE 开销。在正常数据传输过程中，通常涉及如下MAC CE 类型：BSR、PHR、DRX 命令、TA 命令。

（a）BSR 机制涉及常规BSR、周期BSR 和捎带BSR 3 种触发类型，BSR 的具体触发时刻和数据量与业务的突发特性、数据的传输情况和高层参数配置等因素密切相关，分析起来较为复杂。另外，BSR机制对MAC 子层的性能影响较大，从仿真平台的验证过程来看，有时候涉及的数据量较大，不能忽略。为了简化考虑，假设每一个MAC PDU（即传输块）都携带一个短BSR MAC CE。

（b）PHR 机制引入的PHR MAC CE 数据量与高层参数配置、UE的移动特性、网络部署环境、数据的传输情况等都有关。PHR 机制引入的数据量较小，尤其在UE低速移动的情况下。为了简化考虑，本文暂不考虑PHR开销。

（c）DRX 命令用于网络通知UE 立即终止激活状态进入DRX 静默期。这种命令一般使用的概率比较小。为了简化考虑，本文暂不考虑DRX 命令涉及的开销。

（d）TA 命令用于网络指示终端调整上行同步提前量，一般发送较为频繁，以保证终端与网络之间的上行同步，避免上行失步导致的随机接入等，保证业务传输的时延。TA 命令的发送与高层参数配置、UE的移动特性、网络部署环境等有关。为了简化考虑，假设每一个MAC PDU（即传输块）都携带一个TAC MAC CE。

d）协议头开销。MAC PDU 的协议头由1 到多个MAC PDU 子头构成，每个子头与一个MAC SDU（RLC PDU）、MAC CE 或填充部分一一对应。MAC 子头的长度如表7 所示。

表7 MAC子头长度

考虑到所有MAC CE 的长度都固定，因此对应的MAC 子头长度为1 B。当在MAC PDU 中添加一个短BSR MAC CE 时，引入2 B 的开销；当在MAC PDU 中添加一个TAC MAC CE 时，引入2 B 的开销。对于MAC SDU（RLC PDU），基于下发的RLC PDU 大小确定对应的MAC子头长度。

MAC 子层在单个逻辑信道上向RLC 子层请求的数据大小限制了每次下发的RLC PDUs 大小。本文假定新传输数据PDU 大小即为请求的数据大小。对于RLC AM 模式，重传PDU 与STATUS PDU 基于对应的方案计算大小，一般这些PDU 的大小不会超过请求的大小，在MAC 子层可以通过级联在一个MAC PDU 中封装1 到多个RLC PDU。为了统一考虑RLC 子层的2种模式，假设每个MAC PDU 承载RLC_PDU_Size 大小的RLC PDU数据，基于RLC子层下发的PDU总数据量可以求出MAC PDU 数目，基于此MAC PDU 数目便可以计算MAC CE 的数据量。注意基于各种RLC PDU与MAC PDU 之间的大小关系，假设新传输AMD PDU（以及完整下发的重传AMD PDU）都与MAC PDU 中的最后一个MAC 子头对应，包含RLC SDU 分段的AMD PDU 和STATUS PDU 都不与MAC PDU 中的最后一个MAC 子头对应，基于此假设确定对应的MAC 子头长度。对于UM 模式，假设UMD PDU 都与MAC PDU 中的最后一个MAC 子头对应，基于此假设确定对应的MAC子头长度。

2.3 业务空口速率

前面分析了空口的高层协议开销，考虑典型的市区场景，对高层的关键参数取值如表8所示。

根据计算可以得到各业务需求的空口速率如表9所示。

表8 高层协议开销关键参数取值

表9 单业务的空口支持速率需求

3 小区容量分析

3.1 小区吞吐速率

通过仿真或测试的方法，可以获取在一定参数配置下的5G网络小区吞吐速率，本文采用仿真的方法分析，其中物理层控制信道和参考符号等开销，统一折合到小区平均频谱效率中体现。仿真终端采用4T4R，天线采用45°交叉极化，天线间距为半个波长；基站采用64T64R，天线采用45°交叉极化，天线间距为半个波长；仿真时考虑SIBs 开销以及物理层开销，包括PDCCH 开销（下行控制区域内的OFDM 符号数为2）、SSB、CSI-RS、PDSCH DMRS、PUCCH（格式1+格式3）、PRACH（格式0）、SRS以及PUSCH DMRS 的开销；仿真时的参数取值如表10所示。

小区平均频谱效率仿真结果：上行码本传输小区平均频谱效率为8.34 bit/s/Hz；下行非码本传输小区平均频谱效率为9.27 bit/s/Hz。

根据上述仿真条件，在10 ms内有大约6个等效的上行时隙、12.667个等效的下行时隙，即上下行等效带宽分别为30 MHz、63.3 MHz。根据小区平均频谱效率，可以得到小区上下行可承载的平均数据速率分别为250.2和587.1 Mbit/s。

3.2 业务信道用户容量

而实际网络应用中，终端用户由于处于不同的状态，不同的分析目的对用户数量的关注角度不同，本文将用户容量定义为3种：等效在线用户、实际在线用户数和背景用户数。其中等效在线用户数关注的是将1个或多个实体用户等效为一个持续发送接收业务状态的虚拟用户后的虚拟用户数量；实际在线用户数关注的是处于RRC_ACTIVE 和RRC_INACTIVE 状态的实体用户数量；背景用户数关注的是小区覆盖范围内包括RRC_IDLE 状态在内的所有实体用户数量，也就是该小区能力允许的放号数量。

本文基于假设的话务模型如表11所示。

等效在线用户容量：

实际在线用户容量：

背景用户容量：

表11 话务模型

式中：

MAC_PDU_Data——各种业务空口速率需求

η——网络目标负荷

OTA——系统满负荷吞吐量

p——该业务的渗透率

T——该业务的平均使用时长

λ——该业务的用户忙时发起率

β——该业务的在线激活率

i、k——各种不同的业务的对应值

表12给出了基于精细化业务模型的系统容量。

表12 基于精细化业务模型的系统容量（单位：用户数/小区）

4 总结

网络容量的研究对于网络规划、部署、建设以及网络运维具有重要的参考意义。一套合理的无线网络容量研究方法论，能够分析给定场景配置下的网络容量，在网络部署规划阶段指导运营商合理规划网络规模，估算建网成本；在网络运维阶段，作为网络容量衡量参考，及时发现网络负荷问题，提早执行网络扩容分析。本文基于5G的关键技术特性和经验的业务、话务模型，给出了一套分析网络容量的方法，对未来5G网络建设和运维提供参考指导。