时间:2024-05-04
文/陈细生
5G gNB基站内部的完保和加密在PDCP(Packet Data Convergence Protocol,分组数据汇集协议)层具体完成,由高层配置有关密钥和算法,完保加密的输入参数包括COUNT,DIRECTION,BEARER,KEY等,完 保 主要是针对信令面的处理,对于上行方向,UE(user equipment)发送经过完保加密后的数据给基站,基站采用对应的算法和密钥进行解密和完整性校验。5G NR RLC(Radio Link Control,无线链路控制协议)的功能相比于LTE,有了一定修改,包括没有级联,没有重排序功能等,使得上行方向发给PDCP的SDU可能乱序,不再是UE发出来的原本顺序。由于SMC(SecurityModeComplete)信令前后,有的信令不完保不加密,有的只完保,有的既完保又加密,这种乱序可能会导致接入流程的一些信令完保解密失败,所以基站必须有一种排序检测机制。
为解决RLC上行发送给PDCP的信令包乱序,使得PDCP层不能适当地选用完保加密组合,本文提供了一种基于SMC信令的比较方法,可以正确地保证各条信令消息的完保解密,包括以下步骤:
步骤S1,RRC层(Radio Resource Control,无线资源控制层)配置PDCP层完保加密有关算法和密钥,PDCP层保存并对全局控制变量赋值做好标识isParseSMCNeeded =TRUE,isSMCReceived = FALSE;
步骤S2,上行方向收到RLC PDU后,进行循环逐个处理,处理前首先判断isParseSMCNeeded == TRUE,isSMCReceived == FALSE是否为真;
步骤S3,如果上述判断为真,则根据协议固定的长度和字节值解析当前包是否为SMC包,不同的情况做不同的处理,如果不成立的话则将当前信令包丢入队列最后,后续进入步骤S2再处理;
步骤S4,如果上述判断为真,则只进行完保校验不进行解密,并置相关变量isSMCReceived = TRUE,SmcSnCount = rcvCount(SMC信令的PDCP序列号),处理后发给RRC层;
步骤 S5,如果S2判断为假,则解析并判断当前包的PDCP序列号SN是否小于rcvCount(SMC信令的PDCP序列号),如果是小于则不进行完保也不进行解密,否则按照当前配置进行完保解密,处理后发给RRC层。
具体实现特点在于:通过多重的判断分支处理,对于SMC信令之前的信令,按照当前的安全参数配置进行完保解密,此时没有配置完保加密;对于SMC之后的信令,按照当前的安全参数配置进行完保解密,此时有配置完保加密;对于有配置完保加密后收到的SMC之前的信令,按照空完保空加密算法进行完保解密。
由于5G的RLC层没有了重排序的功能,即使是AM(Acknowledged Mode,确认模式),只有一个重组定时器等待SDU的完整,使得PDCP层收到的PDU可能是乱序的,虽然PDCP层有重排序的处理,但是协议规定一般是完保解密后再进行重排序,使得上述逻辑成为需要。
RRC层配置了PDCP层完保解密参数后,此时基站发送SM(securityModeCommand)给UE,此信令只完保不加密,UE收到此信令后发送SMC给基站,同样没有加密,但是此时上行来的包可能是SMC之前,之后等多种包一起乱序到达,如果不做特殊处理,必然会造成完保失败接入信令流程无法完成的可能。
本文提出的方法在PDCP层实施,在收到安全参数配置后就开始等待SMC信令的到来,根据SMC信令的PDCP序列号SN为标准,将SMC之前的信令和之后的信令识别区分开来,并引导到不同的流程去处理,可以满足不同的场景,保证了信令流程的不中断,具有很大的创新性和实用性。
测试终端采用IXIA 模拟器,按照SA(Standalone)独立组网进行多UE随机接入,进行了多次测试,测试结果证明,在PDCP信令PDU接收乱序的情况下,接入信令流程也可以顺利地完成。
我们致力于保护作者版权,注重分享,被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自各大过期杂志,内容仅供学习参考,不准确地方联系删除处理!