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

上传人:b****8 文档编号:10772899 上传时间:2023-02-22 格式:DOCX 页数:13 大小:555.93KB
下载 相关 举报
5G 业务信道用户容量分析.docx_第1页
第1页 / 共13页
5G 业务信道用户容量分析.docx_第2页
第2页 / 共13页
5G 业务信道用户容量分析.docx_第3页
第3页 / 共13页
5G 业务信道用户容量分析.docx_第4页
第4页 / 共13页
5G 业务信道用户容量分析.docx_第5页
第5页 / 共13页
点击查看更多>>
下载资源
资源描述

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

《5G 业务信道用户容量分析.docx》由会员分享,可在线阅读,更多相关《5G 业务信道用户容量分析.docx(13页珍藏版)》请在冰豆网上搜索。

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

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

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

摘要:

基于精细化的业务源数据包模型,对数据包经过无线网络的协议开销进行分析,以此分析业务的空口速率需求,从而对系统承载用户容量分析。

根据不同的分析需求,将用户容量细分为等效在线用户数、实际在线用户数和背景用户数3种类型并定义其分析方法,为未来5G网络容量分析和网络运维参考提供指导。

关键词:

5G;业务信道;容量;精细化业务模型

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业务源模型。

NR业务可以分为基于TCP协议的业务和基于UDP协议的业务。

TCP协议基于比特流,面向连接,存在反馈重传机制,能保证数据的正确传输,可靠性很高,不过时延较大,类似于RLCAM模式。

FTP下载/上传和HTTP网页浏览这2种业务基于TCP传输。

TCP协议引入了丢包检测、慢启动等机制,存在发送窗口,能起到流量控制的作用,能基于底层链路特性下发或缓存数据包,从而可以控制数据下发速率。

UDP协议基于数据报文传输,不存在端到端的连接。

因为不存在ARQ机制,因此不能保证数据的正确传输,在网络出现拥塞时可靠性无保障,但传输时延较小,类似于RLCUM模式。

微信、视频流和UDP传输一般都属于这种情况。

UDP传输不能够缓存数据包。

但是为了简单起见,可以认为:

下发到SDAP层的数据速率就是业务源的数据下发速率。

根据上面的业务模型,可以得到如表2所示的结果。

2.2协议开销分析

业务对空口速率的需求分析,主要考虑业务经过高层协议栈的开销。

在考虑NR空口高层协议开销时,暂时不考虑控制平面的信令消息,例如RRC消息、NAS消息等。

在用户平面,封装了业务数据的QoS流数据包直接到达空口的SDAP子层,经历了层二的各个子层之后,被封装在传输块中经过HARQ过程实现UE与eNB之间的递交。

层二包括如下协议子层:

SDAP子层、PDCP子层、RLC子层和MAC子层。

为了完成IP数据包的有效可靠递交,每一个子层都将引入特定的协议头和控制过程开销。

本节将详细描述各个子层的开销,并汇总数据包在高层协议处理过程中引入的总开销。

各个子层之间的关系如图1所示。

2.2.1SDAP协议子层开销分析5G的QoS划分更加精细,因此引入了SDAP(ServiceDataAdaptationProtocol)适配层为QoS流和数据无线承载(DRB)之间做映射。

1个或多个QoS流可以被映射到同一个DRB上。

SDAP协议数据单元(PDU)分为数据协议数据单元(dataPDU)和控制协议数据单元(controlPDU)。

数据PDU主要用于传送SDAP头和用户面数据。

控制PDU又叫结束标记控制PDU(End-MarkerControlPDU),被UE侧的SDAP实体使用,用于指示此控制PDU不再映射QFI指示的QoS流到传输此控制PDU的DRB。

数据PDU可以带SDAP头或者不带,相应的数据PDU的协议头开销为0或8bit(见表3)

2.2.2PDCP协议子层开销分析

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

a)头压缩。

头压缩操作会影响业务数据包的开销计算。

业务初期未压缩的数据包和业务激活期半压缩的数据包,数量较少,不予考虑。

b)加密。

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

c)重排序和复制。

不影响数据包大小,此处不作分析。

d)切换过程中,PDCP子层收发端可能交互状态报告。

因为状态报告数据包出现的概率和数据比例都很小,在估算开销时暂时不予考虑。

e)封装。

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

目前协议只支持ROHC头压缩协议,ROHC头包括1B的ROHC数据包类型信息(包含格式标识、2bit的CRC和压缩序列号),以及1~2B的上下文标识(CID—ContextIdentifier)信息,共占用2~3B。

一般协议上假设CID占用2B,则ROHC头占用3B。

TCP/IP协议压缩头固定占用2B。

在本文后续章节,都假设压缩后的头长度为5B。

承载业务数据的IP数据包经过头压缩后,得到的压缩数据包的格式如图2所示。

PDCPSDU(即SDAPPDU数据包)经过PDCP子层的处理后,得到对应的PDCPPDU并递交给RLC子层进行传输。

基于协议规定,PDCP协议头开销不区分RLC模式,具体汇总如表4所示。

2.2.3RLC协议子层开销分析

RLC层功能较多,包括分段/重组RLCSDU(只适用于UM和AM模式),ARQ纠错(只适用于AM模式),重复包检测(只适用于AM模式),重分段(只适用于AM模式),RLCSDU丢弃处理(只适用于UM和AM模式),RLC重建等。

与LTE相比,NR的RLC层移除了RLCSDU的串联(concatenation)功能,转由MAC层实现,移除了RLC层的重排序功能,转由PDCP层负责,其目的都是为了降低RLC层的处理时延。

RLCPDUs可以分为数据PDUs和控制PDUs。

数据PDUs涉及3种RLC模式:

TM模式、UM模式和AM模式,其中TM模式只用于控制平面,所以不做展开讨论,下面分析UM和AM模式。

UM模式不存在引入额外开销的控制机制,因此只考虑协议头开销。

一个UMDPDU包含一个完整的RLCSDU或者RLCSDU分段。

UMDPDU头的长度与SN长度有关,如表5所示。

当UMDPDU包含一个完整的RLCSDU时,UMPPDU头不包含SN。

SN长度由高层根据需要配置,仅当业务数据速率要求较高且无线链路质量较好时才能配置采用6bit的SN,正常情况下都配置采用12bit的SN。

仅当UMDPDU包含RLCSDU分段且此分段不是第一个分段时,UMDPDU头才包含16bit的SO(SegmentOffset)。

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

a)协议头开销分析。

一个AMDPDU包含一个完整的RLCSDU或者RLCSDU分段。

仅当AMDPDU包含RLCSDU分段且此分段不是第一个分段时,AMDPDU头才包含16bit的SO(SegmentOffset)。

如表6所示。

b)重传开销。

经过低层的HARQ传输后,RLCPDU的成功递交概率已经很高,一般认为能

够达到10-3级别。

ARQ机制用来重传HARQ传输失败的PDU。

一般经过一次ARQ重传后,PDU总传输功率已经足够高,剩余传输失败的PDU可以不再单独考虑。

在PDU重传时刻,如果MAC子层在传输机会中指示的可下发数据量无法容纳整个待重传的PDU,则需要对此重传PDU对应的SDU进行重分段。

MAC子层指示的可下发数据量由调度决定,考虑信道质量、缓冲区数据量、资源占用情况等因素会随机变化。

重传PDU对应的RLCSDU是否需要重分段以及重分段后得到的AMDPDU分段数目都由此可下发数据量决定。

重传和重分段引入的具体开销大小与协议头开销有关,在协议头开销中统一考虑。

c)状态报告开销。

状态报告有基于来自对端的探询和基于PDU丢

失检测2种触发机制。

当链路质量较好时,基于对端探询的状态报告触发机制占主导。

这种机制依赖于PDU中P字段的设置,而P字段的设置机制一般考虑基于传输的新AMDPDU数目设置P字段。

假设每收到一个设置了P字段的PDU后,触发传输一个仅包含ACK_SN字段的状态报告。

当无线链路质量较差时,基于PDU丢失检测的状态报告触发机制占主导地位,这种机制在接收端重排序定时器超时后触发一个状态报告的发送,可以假设一个丢失的PDU(即重传PDU)对应一个只包含一个NACK_SN记录的状态报告。

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

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

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

2.2.4MAC协议子层开销分析MAC子层主要考虑以下开销。

a)寻呼传输开销。

寻呼的触发原因包括核心网

触发、通知系统信息修改、通知ETWS消息等。

其中核心网触发的寻呼一般用于通知用户呼叫的到来,与下行业务发起特性有关。

系统信息修改触发的寻呼与网络系统信息修改的频繁程度有关。

寻呼过程涉及的数据量相对较小,本文暂不考虑。

b)随机接入开销。

随机接入过程中下行的随机接入响应消息和竞争解决消息,以及上行的Msg3都在共享信道上传输,影响业务数据的资源占用。

随机接入响应消息中包含UE的Msg3传输资源分配信息和初始TA调整信息。

Msg3中一般包含高层信令消息

(RRC连接请求消息、RRC连接重建请求消息、RRC连接重配完成消息)或者C-RNT(I上/下行数据到达触发的随机接入过程)。

竞争解决消息仅在Msg3包含高层信令消息时包含竞争解决MACCE涉及开销,其他情况下通过PDCCH直接实现竞争解决。

因此这几种消息的大小都相对较小,对业务数据传输的资源影响较小,而且分析起来较为复杂。

本文暂不考虑随机接入过程引入的开销。

c)MACCE开销。

在正常数据传输过程中,通常涉及如下MACCE类型:

BSR、PHR、DRX命令、TA命令。

(a)BSR机制涉及常规BSR、周期BSR和捎带BSR3种触发类型,BSR的具体触发时刻和数据量与业务的突发特性、数据的传输情况和高层参数配置等因素密切相关,分析起来较为复杂。

另外,BSR机制对MAC子层的性能影响较大,从仿真平台的验证过程来看,有时候涉及的数据量较大,不能忽略。

为了简化考虑,假设每一个MACPDU(即传输块)都携带一个短BSRMACCE。

(b)PHR机制引入的PHRMACCE数据量与高层参数配置、UE的移动特性、网络部署环境、数据的传输情况等都有关。

PHR机制引入的数据量较小,尤其在UE低速移动的情况下。

为了简化考虑,本文暂不考虑PHR开销。

(c)DRX命令用于网络通知UE立即终止激活状态进入DRX静默期。

这种命令一般使用的概率比较小。

为了简化考虑,本文暂不考虑DRX命令涉及的开销。

(d)TA命令用于网络指示终端调整上行同步提前量,一般发送较为频繁,以保证终端与网络之间的上行同步,避免上行失步导致的随机接入等,保证业务传输的时延。

TA命令的发送与高层参数配置、UE的移动特性、网络部署环境等有关。

为了简化考虑,假设每一个MACPDU(即传输块)都携带一个TACMACCE。

d)协议头开销。

MACPDU的协议头由1到多个MACPDU子头构成,每个子头与一个MACSDU(RLCPDU)、MACCE或填充部分一一对应。

MAC子头的长度如表7所示。

考虑到所有MACCE的长度都固定,因此对应的MAC子头长度为1B。

当在MACPDU中添加一个短BSRMACCE时,引入2B的开销;当在MACPDU中添加一个TACMACCE时,引入2B的开销。

对于MACSDU(RLCPDU),基于下发的RLCPDU大小确定对应的MAC子头长度。

MAC子层在单个逻辑信道上向RLC子层请求的数据大小限制了每次下发的RLCPDUs大小。

本文假定新传输数据PDU大小即为请求的数据大小。

对于RLCAM模式,重传PDU与STATUSPDU基于对应的方案计算大小,一般这些PDU的大小不会超过请求的大小,在MAC子层可以通过级联在一个MACPDU中封装1到多个RLCPDU。

为了统一考虑RLC子层的2种模式,假设每个MACPDU承载RLC_PDU_Size大小的RLCPDU数据,基于RLC子层下发的PDU总数据量可以求出MACPDU数目,基于此MACPDU数目便可以计算MACCE的数据量。

注意基于各种RLCPDU与MACPDU之间的大小关系,假设新传输AMDPDU(以及完整下发的重传AMDPDU)都与MACPDU中的最后一个MAC子头对应,包含RLCSDU分段的AMDPDU和STATUSPDU都不与MACPDU中的最后一个MAC子头对应,基于此假设确定对应的MAC子头长度。

对于UM模式,假设UMDPDU都与MACPDU中的最后一个MAC子头对应,基于此假设确定对应的MAC子头长度。

2.3业务空口速率

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

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

3小区容量分析

3.1小区吞吐速率

通过仿真或测试的方法,可以获取在一定参数配置下的5G网络小区吞吐速率,本文采用仿真的方法分析,其中物理层控制信道和参考符号等开销,统一折合到小区平均频谱效率中体现。

仿真终端采用4T4R,天线采用45°交叉极化,天线间距为半个波长;基站采用64T64R,天线采用45°交叉极化,天线间距为半个波长;仿真时考虑SIBs开销以及物理层开销,包括PDCCH开销(下行控制区域内的OFDM符号数为2)、SSB、CSI-RS、PDSCHDMRS、PUCCH(格式1+格式3)、PRACH(格式0)、SRS以及PUSCHDMRS的开销;仿真时的参数取值如表10所示。

小区平均频谱效率仿真结果:

上行码本传输小区平均频谱效率为8.34bit/s/Hz;下行非码本传输小区平均频谱效率为9.27bit/s/Hz。

根据上述仿真条件,在10ms内有大约6个等效的上行时隙、12.667个等效的下行时隙,即上下行等效带宽分别为30MHz、63.3MHz。

根据小区平均频谱效率,可以得到小区上下行可承载的平均数据速率分别为250.2和587.1Mbit/s。

3.2业务信道用户容量

而实际网络应用中,终端用户由于处于不同的状态,不同的分析目的对用户数量的关注角度不同,本文将用户容量定义为3种:

等效在线用户、实际在线用户数和背景用户数。

其中等效在线用户数关注的是将1个或多个实体用户等效为一个持续发送接收业务状态的虚拟用户后的虚拟用户数量;实际在线用户数关注的是处于RRC_ACTIVE和RRC_INACTIVE状态的实体用户数量;背景用户数关注的是小区覆盖范围内包括RRC_IDLE状态在内的所有实体用户数量,也就是该小区能力允许的放号数量。

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

等效在线用户容量:

4总结

网络容量的研究对于网络规划、部署、建设以及网络运维具有重要的参考意义。

一套合理的无线网络容量研究方法论,能够分析给定场景配置下的网络容量,在网络部署规划阶段指导运营商合理规划网络规模,估算建网成本;在网络运维阶段,作为网络容量衡量参考,及时发现网络负荷问题,提早执行网络扩容分析。

本文基于5G的关键技术特性和经验的业务、话务模型,给出了一套分析网络容量的方法,对未来5G网络建设和运维提供参考指导。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 工学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1