CN114615657B - 一种5g通信中的数据分段解密方法及装置 - Google Patents

一种5g通信中的数据分段解密方法及装置 Download PDF

Info

Publication number
CN114615657B
CN114615657B CN202210155206.6A CN202210155206A CN114615657B CN 114615657 B CN114615657 B CN 114615657B CN 202210155206 A CN202210155206 A CN 202210155206A CN 114615657 B CN114615657 B CN 114615657B
Authority
CN
China
Prior art keywords
pdcp pdu
rlc sdu
current
rlc
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210155206.6A
Other languages
English (en)
Other versions
CN114615657A (zh
Inventor
孙金重
郑锐
胡成松
王青松
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ASR Microelectronics Co Ltd
Original Assignee
ASR Microelectronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ASR Microelectronics Co Ltd filed Critical ASR Microelectronics Co Ltd
Priority to CN202210155206.6A priority Critical patent/CN114615657B/zh
Publication of CN114615657A publication Critical patent/CN114615657A/zh
Priority to PCT/CN2022/133067 priority patent/WO2023155516A1/zh
Application granted granted Critical
Publication of CN114615657B publication Critical patent/CN114615657B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03Protecting confidentiality, e.g. by encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10Integrity
    • H04W12/106Packet or message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请公开了一种5G通信中的数据分段解密方法。接收端的解密模块不需要等到当前PDCP PDU对应的所有RLC SDU分段包都收齐后再对PDCP PDU的完整的数据载荷密文开始解密,解密模块可以在获得PDCP PDU的序列号后就以RLC SDU分段包为单位对每个RLC SDU分段包中所包含的PDCP PDU的数据载荷区间密文段开始解密工作,从而降低了移动终端对数据包处理的时延,提升了移动终端对数据包处理的时效性。

Description

一种5G通信中的数据分段解密方法及装置
技术领域
本申请涉及一种移动通信技术,特别是涉及一种5G通信中基于RLC SDU分段包的解密方法。其中,RLC表示radio link control(无线链路控制),SDU表示service dataunit(服务数据单元)。
背景技术
基于蜂窝组网的移动通信已经从第一代发展到了第五代(5G),为了提高空口(airinterface,空中接口)数据传输的安全性,需要对数据包在发送端进行加密、在接收端进行解密。
RLC层位于PDCP层(或RRC层)和MAC层之间。RLC层通过RLC通道(RLC channel)与PDCP层(或RRC层)进行通信,并通过逻辑信道与MAC层进行通信。RLC实体(RLC entity)从PDCP层接收到的数据,或发往PDCP层的数据被称作RLC SDU(或称为PDCP PDU)。RLC实体从MAC层接收到的数据,或发往MAC层的数据被称作RLC PDU(或称为MAC SDU)。其中,PDCP表示packet data convergence protocol(分组数据汇聚协议),RRC表示radio resourcecontrol(无线资源控制),MAC表示medium access control或media access control(介质访问控制),PDU表示protocol data unit(协议数据单元)。
RLC层负责的功能之一是分段(segmentation)和重组(reassembly)RLC SDU,只适用于UM(unacknowledged mode,非确认模式)和AM模式(acknowledge mode,确认模式)。在一次传输机会中,一个逻辑信道可发送的所有RLC PDU的总大小是由MAC层指定的,其大小通常并不能保证每一个需要发送的RLC SDU都能完整地发送出去,所以在发送端的RLC层需要对某个RLC SDU进行分段得到多个RLC SDU分段包(RLC SDU segment,即RLC PDU),每个RLC SDU分段包均满足MAC层指定的大小。相应地,在接收端的RLC层需要对接收到的RLCSDU分段包进行重组,以恢复出原来的RLC SDU并递送给上层。
RLC层负责的功能之二是对RLC SDU分段包进行重分段(re-segmentation),只适用于AM模式。当一个RLC SDU分段包需要重传,但MAC层指定的大小无法保证该RLC SDU分段包完全发送出去时,就需要对该RLC SDU分段包进行重分段处理。
现有的5G通信中接收端针对RLC SDU的解密方法如下。首先,接收端的RLC层对所有RLC SDU分段包进行重组,直至重组完成得到一个完整的RLC SDU,传递给PDCP层,RLCSDU也称PDCP PDU。随后,PDCP层判断该PDCP PDU是否落在接收窗口内,如果是,则将该PDCPPDU送往解密模块。如果否,则丢弃该PDCP PDU。所述接收窗口是指由PDCP层维护的一个重排序窗口,用来对乱序收到的PDCP PDU进行重排序,进而给上层应用递交按序排列的PDCPPDU。最后,解密模块对收到的PDCP PDU进行解密运算,此时是以PDCP PDU为单位进行解密运算的。解密功能是PDCP层的一个重要功能,解密模块是PDCP层的一部分。
5G通信中,数据传输速率有了显著的提升,在极限情况下,UE(user equipment,用户设备)只有1个OFDM(orthogonal frequency-division multiplexing,正交频分复用)符号时间进行数据处理。空口中RLC SDU分段包的产生使得接收端的RLC层等待对RLC SDU分段包进行重组的时间加长,这使得PDCP层中的解密模块开始对落在接收窗口内的PDCP PDU进行解密的时间也相应被推迟,增加了移动终端系统处理业务数据包的时延。
发明内容
本申请所要解决的技术问题是当空口中存在RLC SDU分段包时,如何使接收端的PDCP层尽早地开始解密运算,从而减少移动终端系统处理业务数据包的时延。
为解决上述技术问题,本申请提出了一种5G通信中的数据分段解密方法,包括如下步骤。步骤S10:接收端的RLC层接收RLC SDU分段包,在收到每个RLC SDU分段包后均尝试解析出当前PDCP PDU的序列号。步骤S20:接收端的RLC层一旦获得当前PDCP PDU的序列号,如果当前RLC SDU分段包中包含当前PDCP PDU的数据载荷,则将两者一并发送给接收端的PDCP层;否则,接收端的RLC层仅将当前PDCP PDU的序列号发送给接收端的PDCP层。步骤S30:接收端的PDCP层判断当前PDCP PDU的序列号是否在接收窗口内,并将判断结果通知接收端的RLC层;如果在接收窗口内,进入步骤S41;如果不在接收窗口内,进入步骤S51。步骤S41:如果当前RLC SDU分段包中包含当前PDCP PDU的数据载荷,PDCP层中的解密模块对其进行解密,然后进入步骤S42;否则直接进入步骤S42。步骤S42:接收端的RLC层将后续接收到的所有不包含PDCP PDU的头部的RLC SDU分段包都直接送入PDCP层中的解密模块,解密模块以每个RLC SDU分段包为单位进行解密运算;直至接收端的RLC层开始收到包含或部分包含PDCP PDU的头部的RLC SDU分段包,则回到步骤S10。步骤S51:接收端的RLC层丢弃为解析当前PDCP PDU的序列号而接收的一个RLC SDU分段包或多个RLC SDU分段包的组合,然后进入步骤S52。步骤S52:接收端的RLC层将后续接收到的所有不包含PDCP PDU的头部的RLCSDU分段包直接丢弃;直至接收端的RLC层开始收到包含或部分包含PDCP PDU的头部的RLCSDU分段包,则回到步骤S10。
进一步地,所述步骤S10中,如果当前RLC SDU分段包中包含一个PDCP PDU的完整头部,则接收端的RLC层从中解析出当前PDCP PDU的序列号。
进一步地,所述步骤S10中,如果当前RLC SDU分段包中仅包含一个PDCP PDU的部分头部,则接收端的RLC层继续接收RLC SDU分段包,直至所接收的一个RLC SDU分段包或多个RLC SDU分段包的组合中包含一个PDCP PDU的完整头部,并从中解析出当前PDCP PDU的序列号。
进一步地,所述步骤S10中,如果当前RLC SDU分段包中不包含PDCP PDU的完整头部或部分头部,则接收端的RLC层继续接收RLC SDU分段包,直至所接收的一个RLC SDU分段包或多个RLC SDU分段包的组合中包含一个PDCP PDU的完整头部,并从中解析出当前PDCPPDU的序列号。
可选地,所述步骤S30中,接收端的RLC层还根据判断结果设置一个丢弃标识;如果在接收窗口内,丢弃标识为第一取值;如果不在接收窗口内,丢弃标识为第二取值。
进一步地,所述步骤S42中,接收端的PDCP层不再对这些不包含PDCP PDU的头部的RLC SDU分段包做接收窗口判断;这些不包含PDCP PDU的头部的RLC SDU分段包与之前接收的RLC SDU分段包属于同一个PDCP PDU,具有相同的PDCP PDU的序列号。
进一步地,所述步骤S42中,当接收端的RLC层收齐当前PDCP PDU的序列号的所有RLC SDU分段包后,接收端的RLC层将当前PDCP PDU的序列号的最后一个RLC SDU分段包传递给接收端的PDCP层中的解密模块时通知接收端的PDCP层重组完成;接收端的PDCP层中的解密模块在完成解密当前PDCP PDU的序列号的最后一个RLC SDU分段包后,接收端的PDCP层将解密后的当前PDCP PDU的完整数据包递交给上层。
可选地,所述步骤S51中,如果接收端的PDCP层判断当前PDCP PDU的序列号不在接收窗口内,则接收端的RLC层在向发送端发送的状态信息中通知发送端,以使发送端不再传输当前PDCP PDU的序列号的后续RLC SDU分段包,而开始传输具有新的PDCP PDU的序列号的RLC SDU或RLC SDU分段包。
进一步地,所述步骤S41中,解密模块新增参数soStartDecipherByte,并为其赋值为0;新增参数soStartDecipherByte的取值表示每一个RLC SDU分段包中所包含的PDCPPDU的数据载荷区间的首字节在完整的PDCP PDU的数据载荷中的位置;在识别到该新增参数soStartDecipherByte的取值为0时,解密模块认识到待解密的PDCP PDU的数据载荷区间的首字节在完整的PDCP PDU的数据载荷中的第0个字节位置即起始位置,采用现有方法进行解密。
进一步地,所述步骤S42中,新增参数soStartDecipherByte=SO-PDCP PDU的头部长度;其中SO表示除第一个RLC SDU分段包以外的RLC SDU分段包中的SO字段的取值,表示该RLC SDU分段包在原始RLC SDU中的位置;在识别到新增参数soStartDecipherByte的取值非0时,解密模块认识到待解密的PDCP PDU的数据载荷区间是原始PDCP PDU的数据载荷的某一分段;解密模块根据新增参数soStartDecipherByte计算出需要解密的密文段属于哪些16字节块以及在这些16字节块内的偏移值,通过解密密钥的二次转换计算出需要解密的密文段属于的16字节块区间的modKey,所述modKey再和密文字段做异或运算即得到解密后的PDCP PDU的数据载荷区间。
本申请还提出了一种5G通信中的数据分段解密装置,包括接收解析单元、传送丢弃单元、判断单元、分段解密单元。所述接收解析单元用于接收RLC SDU分段包,在收到每个RLC SDU分段包后均尝试解析出当前PDCP PDU的序列号。所述传送丢弃单元用于一旦获得当前PDCP PDU的序列号,就发送给判断单元;所述传送放弃单元还用于当“当前PDCP PDU的序列号在接收窗口内”时,如果当前RLC SDU分段包中包含当前PDCP PDU的数据载荷,则将其发送给分段解密单元;还将后续接收到的所有不包含PDCP PDU的头部的RLC SDU分段包都直接送入分段解密单元;所述传送丢弃单元还用于当“当前PDCP PDU的序列号不在接收窗口内”时,丢弃为解析当前PDCP PDU的序列号而接收的一个RLC SDU分段包或多个RLCSDU分段包的组合,还将后续接收的所有不包含PDCP PDU的头部的RLC SDU分段包直接丢弃。所述判断单元用于判断当前PDCP PDU的序列号是否在接收窗口内,并将判断结果通知传送丢弃单元、分段解密单元。所述分段解密单元用于当“当前PDCP PDU的序列号在接收窗口内”时,对当前RLC SDU分段包中所包含的当前PDCP PDU的数据载荷进行解密,还将后续的所有不包含PDCP PDU的头部的RLC SDU分段包都以每个RLC SDU分段包为单位进行解密运算。
本申请取得的技术效果是接收端不再需要等待RLC SDU分段包重组完成后才进行解密运算,而是在收到每个RLC SDU分段包后在符合判断条件时直接以RLC SDU分段包为单位进行解密运算,这使得对PDCP PDU进行解密的开始时间大为提前,减少了移动终端系统处理业务数据包的时延。
附图说明
图1是本申请提出的5G通信中的数据分段解密方法的流程示意图。
图2是本申请提出的5G通信中的数据分段解密装置的结构示意图。
图中附图标记说明:10为接收解析单元、20为传送放弃单元、30为判断单元、40为分段解密单元。
具体实施方式
请参阅图1,本申请提出的5G通信中的数据分段解密方法包括如下步骤。
步骤S10:接收端(例如移动终端侧)的RLC层接收RLC SDU分段包,在收到每个RLCSDU分段包后均尝试解析出当前PDCP PDU的序列号。所述RLC SDU分段包是发送端(例如移动基站侧)的RLC层为了匹配发送端的MAC层指定的逻辑信道的大小而对某个RLC SDU进行分段后获得的。所述RLC SDU分段包通过发送端的MAC层、发送端的物理层、发送端的天线、空中传输、接收端的天线、接收端的物理层、接收端的MAC层一路传输给接收端的RLC层。
如果所接收的当前RLC SDU分段包中包含一个PDCP PDU的完整头部(header),则接收端的RLC层从中解析出当前PDCP PDU的序列号(PDCP PDU SN),例如根据PDCP RB(Radio Bearer,无线承载)配置的参数pdcp-SN-SizeDL进行解析。
如果所接收的当前RLC SDU分段包中仅包含一个PDCP PDU的部分头部,则接收端的RLC层继续接收RLC SDU分段包,直至所接收的一个RLC SDU分段包或多个RLC SDU分段包的组合中包含一个PDCP PDU的完整头部,并从中解析出当前PDCP PDU的序列号。
如果所接收的当前RLC SDU分段包中不包含PDCP PDU的完整头部或部分头部,则接收端的RLC层继续接收RLC SDU分段包,直至所接收的一个RLC SDU分段包或多个RLC SDU分段包的组合中包含一个PDCP PDU的完整头部,并从中解析出当前PDCP PDU的序列号。
一个PDCP PDU(即RLC SDU)从前往后依次包含头部和数据载荷,头部是不加密的,数据载荷是加密的。PDCP PDU的头部的长度取决于移动基站侧配置的参数pdcp-SN-SizeDL,可能是2字节或3字节。因此一个RLC SDU分段包中可能包含一个PDCP PDU的完整头部,也可能仅包含一个PDCP PDU的部分头部,还可能不包含任何的PDCP PDU的头部(此时该RLC SDU分段包属于一个PDCP PDU的数据载荷的一部分)。在极限情况下,需要连续接收三个RLC SDU分段包才包含一个PDCP PDU的完整头部。PDCP PDU的数据载荷是需要解密的。在收齐一个PDCP PDU的完整头部时,当前的一个RLC SDU分段包中还可能包含当前PDCP PDU的数据载荷的一部分(起始部分)。
步骤S20:接收端的RLC层一旦获得当前PDCP PDU的序列号,就连同当前的RLC SDU分段包中所包含的当前PDCP PDU的数据载荷(有可能不存在,即使存在也往往是当前PDCPPDU的数据载荷的一部分而非全部)一并发送给接收端的PDCP层。
步骤S30:接收端的PDCP层判断当前PDCP PDU的序列号是否在接收窗口内,并将判断结果通知接收端的RLC层。如果在接收窗口内,进入步骤S41。如果不在接收窗口内,进入步骤S51。
可选地,接收端的RLC层还根据判断结果设置一个丢弃标识(discard)。如果在接收窗口内,丢弃标识为第一取值(例如false)。如果不在接收窗口内,丢弃标识为第二取值(例如true)。
步骤S41:如果接收端的PDCP层收到当前RLC SDU分段包中所包含的当前PDCP PDU的数据载荷,则由PDCP层中的解密模块进行解密。后续进入步骤S42。如果接收端的PDCP层未收到当前RLC SDU分段包中所包含的当前PDCP PDU的数据载荷,则直接进入步骤S42。
步骤S42:接收端的RLC层将后续接收到的所有不包含PDCP PDU的头部的RLC SDU分段包都直接送入PDCP层中的解密模块,解密模块以每个RLC SDU分段包为单位进行解密运算。此时,接收端的PDCP层不再对这些不包含PDCP PDU的头部的RLC SDU分段包做接收窗口判断。这些不包含PDCP PDU的头部的RLC SDU分段包与之前接收的RLC SDU分段包属于同一个PDCP PDU,具有相同的PDCP PDU的序列号。进一步地,当接收端的RLC层收齐(即完成重组)当前PDCP PDU的序列号的所有RLC SDU分段包后,接收端的RLC层将当前PDCP PDU的序列号的最后一个RLC SDU分段包传递给接收端的PDCP层中的解密模块时通知接收端的PDCP层重组完成。接收端的PDCP层中的解密模块在完成解密当前PDCP PDU的序列号的最后一个RLC SDU分段包后,接收端的PDCP层将解密后的当前PDCP PDU的完整数据包递交给上层。直至接收端的RLC层开始收到包含或部分包含PDCP PDU的头部的RLC SDU分段包,则回到步骤S10。
步骤S51:接收端的RLC层丢弃为解析当前PDCP PDU的序列号而接收的一个RLCSDU分段包或多个RLC SDU分段包的组合。后续进入步骤S52。
步骤S52:接收端的RLC层将后续接收到的所有不包含PDCP PDU的头部的RLC SDU分段包直接丢弃,不将这些RLC SDU分段包传递给接收端的PDCP层。直至接收端的RLC层开始收到包含或部分包含PDCP PDU的头部的RLC SDU分段包,则回到步骤S10。
可选地,所述步骤S51中,如果接收端的PDCP层判断当前PDCP PDU的序列号不在接收窗口内,那么当前PDCP PDU的序列号的后续RLC SDU分段包都是无效的数据包,在步骤S52中都将被丢弃。此时为了节省空口资源,接收端的RLC层向发送端发送的状态信息(status PDU)中通知发送端,以使发送端不再传输当前PDCP PDU的序列号的后续RLC SDU分段包,而开始传输具有新的PDCP PDU的序列号的RLC SDU或RLC SDU分段包。所述状态信息是指接收端回复给发送端,对接收到的RLC SDU或RLC SDU分段包(均属于RLC数据PDU,RLC data PDU)进行确认(ACK)或否认(NACK)的RLC控制PDU(RLC contrl PDU)。
下面对所述步骤S41中的解密过程举例说明。假设某个PDCP PDU的长度是1503字节,其中头部的长度是3字节,数据载荷的长度是1500字节。为便于描述,该数据载荷以字节为单位表示为区间[0,1499]。该PDCP PDU的第一个RLC SDU分段包的长度是8字节,包含该PDCP PDU的头部以及5字节的数据载荷的区间[0,4]。所述步骤S10中,因为第一个RLC SDU分段包中包含一个PDCP PDU的完整头部,则接收端的RLC层从中解析出当前PDCP PDU的序列号。所述步骤S20中,接收端的RLC层将当前PDCP PDU的序列号以及当前PDCP PDU的数据载荷区间[0,4]一并发送给接收端的PDCP层。所述步骤S30中,例如接收端的PDCP层判断当前PDCP PDU的序列号在接收窗口内,则所述步骤S31中PDCP层中的解密模块需对当前PDCPPDU的数据载荷区间[0,4]进行解密。传统的解密运算是对一个PDCP PDU的完整数据载荷密文进行的,而本申请改为对一个PDCP PDU的数据载荷区间[0,4]的密文段进行解密。为了适应这种变化,解密模块新增参数soStartDecipherByte,并在此时赋值为0。新增参数soStartDecipherByte的取值表示每一个RLC SDU分段包中所包含的PDCP PDU的数据载荷区间的首字节在完整的PDCP PDU的数据载荷中的位置。在识别到该新增参数soStartDecipherByte的取值为0时,解密模块认识到待解密的PDCP PDU的数据载荷区间的首字节在完整的PDCP PDU的数据载荷中的第0个字节位置(起始位置),根据常规解密参数(如解密长度decipherLen=5、解密密钥KEY、计数器值PDCP COUNT-C等)进行解密,解密方法和现有方法相同。
下面对所述步骤S42中的解密过程“以每个RLC SDU分段包为单位进行解密运算”举例说明,仍延续前例。接收端的RLC层后续接收的不包含PDCP PDU的头部的RLC SDU分段包可能与当前的RLC SDU分段包是连续的,也可能是不连续的,取决于基站发送给终端的RLC SDU分段包的头部中的SO(segment offset)字段(属于RLC PDU的头部)。SO字段以字节为单位,表示RLC SDU分段包在原始RLC SDU中的位置。第一个RLC SDU分段包的起始位置一定是原始完整RLC SDU的起始位置,SO一定是0,因此第一个RLC SDU分段包不携带SO字段;其余的RLC SDU分段包都包含SO字段。假设接收端的RLC层收到的第二个RLC SDU分段包中,SO字段的取值是24,第二个RLC SDU分段包的长度是20字节,那么接收端的RLC层将收到的第二个RLC SDU分段包传递给PDCP层中的解密模块后,解密模块新增参数soStartDecipherByte=SO-PDCP PDU的头部长度,本例中计算得到soStartDecipherByte=21,即第二个RLC SDU分段包中包含的是该PDCP PDU的20字节的数据载荷的区间[21,40]的密文。在识别到新增参数soStartDecipherByte的取值非0时,解密模块认识到待解密的PDCP PDU的数据载荷区间是原始PDCP PDU的数据载荷的某一分段。解密的运算过程是把需要解密的密文段以16字节块为基本单位分割进行解密工作,可记为第i块16字节块区间。例如,PDCP PDU的数据载荷区间[0,15]称为第1块16字节块,PDCP PDU的数据载荷区间[16,31]称为第2块16字节块,以此类推。具体到每块的16字节块,还有块内(也称当前区间)的偏移值,例如PDCP PDU的数据载荷区间[20,20]位于第2块16字节块且块内偏移值为4。根据新增参数soStartDecipherByte计算出需要解密的密文段属于哪些16字节块以及在这些16字节块内的偏移值。协议规范要求解密密钥KEY是16字节,解密算法会对解密密钥KEY做二次转换,重新得到转换后的modKey。本例中,待解密的PDCP PDU的数据载荷区间[21,40]分解为数据载荷区间[21,31]和数据载荷区间[32,40],表示落入第2块16字节块和第3块16字节块,也就是落入第2个和第3个modKey区间。通过解密密钥的二次转换计算出这两个区间的modKey。所述二次转换是指将16字节的解密密钥KEY分成4*4运算,以分别做行列混淆运算以及其他运算,属于现有技术。该modKey再和密文字段做异或运算即可得到解密后的数据载荷区间[21,40]的原文。
请参阅图2,本申请提出的5G通信中的数据分段解密装置包括接收解析单元10、传送丢弃单元20、判断单元30、分段解密单元40。
所述接收解析单元10用于接收RLC SDU分段包,在收到每个RLC SDU分段包后均尝试解析出当前PDCP PDU的序列号。所述接收解析单元10例如由接收端的RLC层实现。
所述传送丢弃单元20用于一旦获得当前PDCP PDU的序列号,就发送给判断单元30。所述传送放弃单元20还用于当“当前PDCP PDU的序列号在接收窗口内”时,将当前的RLCSDU分段包中所包含的当前PDCP PDU的数据载荷(如果存在)发送给分段解密单元40,还将后续接收到的所有不包含PDCP PDU的头部的RLC SDU分段包都直接送入分段解密单元40。所述传送丢弃单元20还用于当“当前PDCP PDU的序列号不在接收窗口内”时,丢弃为解析当前PDCP PDU的序列号而接收的一个RLC SDU分段包或多个RLC SDU分段包的组合,还将后续接收的所有不包含PDCP PDU的头部的RLC SDU分段包直接丢弃。所述传送丢弃单元20例如由接收端的RLC层实现。
所述判断单元30用于判断当前PDCP PDU的序列号是否在接收窗口内,并将判断结果通知传送丢弃单元20、分段解密单元40。所述判断单元30例如由接收端的PDCP层实现。
所述分段解密单元40用于当“当前PDCP PDU的序列号在接收窗口内”时,对当前RLC SDU分段包中所包含的当前PDCP PDU的数据载荷进行解密,还将后续的所有不包含PDCP PDU的头部的RLC SDU分段包都以每个RLC SDU分段包为单位进行解密运算。所述分段解密单元40例如由接收端的PDCP层中的解密模块实现。
与现有技术相比,本申请提出的5G通信中的数据分段解密方法具有如下有益效果。
第一,接收端的解密模块不需要等到当前PDCP PDU对应的所有RLC SDU分段包都收齐后再对PDCP PDU的完整的数据载荷密文开始解密,解密模块可以在获得PDCP PDU的序列号后就以RLC SDU分段包为单位对每个RLC SDU分段包中所包含的PDCP PDU的数据载荷区间密文段开始解密工作,从而降低了移动终端对数据包处理的时延,提升了移动终端对数据包处理的时效性。
第二,不需要修改发送端对数据的加密方法,仅修改了接收端对数据的解密方法,这使得本申请的通用性增强。
第三,接收端的PDCP层在判定某一个PDCP PDU的序列号落入接收窗口之外后,接收端的RLC层通过状态信息通知发送端该PDCP PDU的序列号对应的RLC SDU分段包已经收齐,发送端可以不必要再传输后续该PDCP PDU的序列号的剩余RLC SDU分段包,降低通信承载资源消耗,提高无线资源利用率,同时也能使得发送端可以尽快传输后续的PDCP PDU的序列号对应的RLC SDU分段包。
以上仅为本申请的优选实施例,并不用于限定本申请。对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。

Claims (11)

1.一种5G通信中的数据分段解密方法,其特征是,包括如下步骤;
步骤S10:接收端的RLC层接收RLC SDU分段包,在收到每个RLC SDU分段包后均尝试解析出当前PDCP PDU的序列号;
步骤S20:接收端的RLC层一旦获得当前PDCP PDU的序列号,如果当前RLC SDU分段包中包含当前PDCP PDU的数据载荷,则将两者一并发送给接收端的PDCP层;否则,接收端的RLC层仅将当前PDCP PDU的序列号发送给接收端的PDCP层;
步骤S30:接收端的PDCP层判断当前PDCP PDU的序列号是否在接收窗口内,并将判断结果通知接收端的RLC层;如果在接收窗口内,进入步骤S41;如果不在接收窗口内,进入步骤S51;
步骤S41:如果当前RLC SDU分段包中包含当前PDCP PDU的数据载荷,PDCP层中的解密模块对其进行解密,然后进入步骤S42;否则直接进入步骤S42;
步骤S42:接收端的RLC层将后续接收到的所有不包含PDCP PDU的头部的RLC SDU分段包都直接送入PDCP层中的解密模块,解密模块以每个RLC SDU分段包为单位进行解密运算;直至接收端的RLC层开始收到包含或部分包含PDCP PDU的头部的RLC SDU分段包,则回到步骤S10;
步骤S51:接收端的RLC层丢弃为解析当前PDCP PDU的序列号而接收的一个RLC SDU分段包或多个RLC SDU分段包的组合,然后进入步骤S52;
步骤S52:接收端的RLC层将后续接收到的所有不包含PDCP PDU的头部的RLC SDU分段包直接丢弃;直至接收端的RLC层开始收到包含或部分包含PDCP PDU的头部的RLC SDU分段包,则回到步骤S10。
2. 根据权利要求1所述的5G通信中的数据分段解密方法,其特征是,所述步骤S10中,如果当前RLC SDU分段包中包含一个PDCP PDU的完整头部,则接收端的RLC层从中解析出当前PDCP PDU的序列号。
3. 根据权利要求1所述的5G通信中的数据分段解密方法,其特征是,所述步骤S10中,如果当前RLC SDU分段包中仅包含一个PDCP PDU的部分头部,则接收端的RLC层继续接收RLC SDU分段包,直至所接收的一个RLC SDU分段包或多个RLC SDU分段包的组合中包含一个PDCP PDU的完整头部,并从中解析出当前PDCP PDU的序列号。
4. 根据权利要求1所述的5G通信中的数据分段解密方法,其特征是,所述步骤S10中,如果当前RLC SDU分段包中不包含PDCP PDU的完整头部或部分头部,则接收端的RLC层继续接收RLC SDU分段包,直至所接收的一个RLC SDU分段包或多个RLC SDU分段包的组合中包含一个PDCP PDU的完整头部,并从中解析出当前PDCP PDU的序列号。
5.根据权利要求1所述的5G通信中的数据分段解密方法,其特征是,所述步骤S30中,接收端的RLC层还根据判断结果设置一个丢弃标识;如果在接收窗口内,丢弃标识为第一取值;如果不在接收窗口内,丢弃标识为第二取值。
6. 根据权利要求1所述的5G通信中的数据分段解密方法,其特征是,所述步骤S42中,接收端的PDCP层不再对这些不包含PDCP PDU的头部的RLC SDU分段包做接收窗口判断;这些不包含PDCP PDU的头部的RLC SDU分段包与之前接收的RLC SDU分段包属于同一个PDCPPDU,具有相同的PDCP PDU的序列号。
7. 根据权利要求1所述的5G通信中的数据分段解密方法,其特征是,所述步骤S42中,当接收端的RLC层收齐当前PDCP PDU的序列号的所有RLC SDU分段包后,接收端的RLC层将当前PDCP PDU的序列号的最后一个RLC SDU分段包传递给接收端的PDCP层中的解密模块时通知接收端的PDCP层重组完成;接收端的PDCP层中的解密模块在完成解密当前PDCP PDU的序列号的最后一个RLC SDU分段包后,接收端的PDCP层将解密后的当前PDCP PDU的完整数据包递交给上层。
8. 根据权利要求1所述的5G通信中的数据分段解密方法,其特征是,所述步骤S51中,如果接收端的PDCP层判断当前PDCP PDU的序列号不在接收窗口内,则接收端的RLC层在向发送端发送的状态信息中通知发送端,以使发送端不再传输当前PDCP PDU的序列号的后续RLC SDU分段包,而开始传输具有新的PDCP PDU的序列号的RLC SDU或RLC SDU分段包。
9. 根据权利要求1所述的5G通信中的数据分段解密方法,其特征是,所述步骤S41中,解密模块新增参数soStartDecipherByte,并为其赋值为0;新增参数soStartDecipherByte的取值表示每一个RLC SDU分段包中所包含的PDCP PDU的数据载荷区间的首字节在完整的PDCP PDU的数据载荷中的位置;在识别到该新增参数soStartDecipherByte的取值为0时,解密模块认识到待解密的PDCP PDU的数据载荷区间的首字节在完整的PDCP PDU的数据载荷中的第0个字节位置即起始位置,进行解密。
10. 根据权利要求9所述的5G通信中的数据分段解密方法,其特征是,所述步骤S42中,新增参数soStartDecipherByte=SO-PDCP PDU的头部长度;其中SO表示除第一个RLC SDU分段包以外的RLC SDU分段包中的SO字段的取值,表示该RLC SDU分段包在原始RLC SDU中的位置;在识别到新增参数soStartDecipherByte的取值非0时,解密模块认识到待解密的PDCP PDU的数据载荷区间是原始PDCP PDU的数据载荷的某一分段;解密模块根据新增参数soStartDecipherByte计算出需要解密的密文段属于哪些16字节块以及在这些16字节块内的偏移值,通过解密密钥的二次转换计算出需要解密的密文段属于的16字节块区间的modKey,所述modKey再和密文字段做异或运算即得到解密后的PDCP PDU的数据载荷区间。
11.一种5G通信中的数据分段解密装置,其特征是,包括接收解析单元、传送丢弃单元、判断单元、分段解密单元;
所述接收解析单元用于接收RLC SDU分段包,在收到每个RLC SDU分段包后均尝试解析出当前PDCP PDU的序列号;
所述传送丢弃单元用于一旦获得当前PDCP PDU的序列号,就发送给判断单元;所述传送丢弃单元还用于当“当前PDCP PDU的序列号在接收窗口内”时,如果当前RLC SDU分段包中包含当前PDCP PDU的数据载荷,则将其发送给分段解密单元;还将后续接收到的所有不包含PDCP PDU的头部的RLC SDU分段包都直接送入分段解密单元;所述传送丢弃单元还用于当“当前PDCP PDU的序列号不在接收窗口内”时,丢弃为解析当前PDCP PDU的序列号而接收的一个RLC SDU分段包或多个RLC SDU分段包的组合,还将后续接收的所有不包含PDCPPDU的头部的RLC SDU分段包直接丢弃;
所述判断单元用于判断当前PDCP PDU的序列号是否在接收窗口内,并将判断结果通知传送丢弃单元、分段解密单元;
所述分段解密单元用于当“当前PDCP PDU的序列号在接收窗口内”时,对当前RLC SDU分段包中所包含的当前PDCP PDU的数据载荷进行解密,还将后续的所有不包含PDCP PDU的头部的RLC SDU分段包都以每个RLC SDU分段包为单位进行解密运算。
CN202210155206.6A 2022-02-21 2022-02-21 一种5g通信中的数据分段解密方法及装置 Active CN114615657B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210155206.6A CN114615657B (zh) 2022-02-21 2022-02-21 一种5g通信中的数据分段解密方法及装置
PCT/CN2022/133067 WO2023155516A1 (zh) 2022-02-21 2022-11-21 一种5g通信中的数据分段解密方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210155206.6A CN114615657B (zh) 2022-02-21 2022-02-21 一种5g通信中的数据分段解密方法及装置

Publications (2)

Publication Number Publication Date
CN114615657A CN114615657A (zh) 2022-06-10
CN114615657B true CN114615657B (zh) 2023-12-22

Family

ID=81858163

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210155206.6A Active CN114615657B (zh) 2022-02-21 2022-02-21 一种5g通信中的数据分段解密方法及装置

Country Status (2)

Country Link
CN (1) CN114615657B (zh)
WO (1) WO2023155516A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114615657B (zh) * 2022-02-21 2023-12-22 翱捷科技股份有限公司 一种5g通信中的数据分段解密方法及装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107295459A (zh) * 2016-03-30 2017-10-24 财团法人工业技术研究院 用于d2d通信的通信系统、通信装置、基站及其方法
EP3319252A1 (en) * 2016-11-04 2018-05-09 Panasonic Intellectual Property Corporation of America Efficient multiplexing of control information in transport block
CN109644381A (zh) * 2017-06-15 2019-04-16 Oppo广东移动通信有限公司 数据处理方法及相关产品
WO2019102965A1 (ja) * 2017-11-22 2019-05-31 京セラ株式会社 通信方法、無線通信装置、及びプロセッサ
CN110365609A (zh) * 2018-04-10 2019-10-22 华为技术有限公司 一种数据包分段方法、及装置
CN112153696A (zh) * 2020-09-25 2020-12-29 Oppo广东移动通信有限公司 Rlc sdu分段处理方法、装置及终端
CN114124840A (zh) * 2021-11-26 2022-03-01 哲库科技(北京)有限公司 接收pdcp包的方法、pdcp包的接收装置、终端设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10028311B2 (en) * 2014-04-22 2018-07-17 Lg Electronics Inc. Method for processing received PDCP PDUs for D2D communication system and device therefor
CN104010370B (zh) * 2014-04-28 2019-07-09 北京邮电大学 异构系统融合控制方法及装置
KR102464567B1 (ko) * 2017-01-16 2022-11-09 삼성전자 주식회사 무선 통신 시스템에서 데이터 처리 방법 및 장치
US10257329B2 (en) * 2017-09-08 2019-04-09 National Instruments Corporation Wireless communications apparatus and method for performing low latency high throughput layer 2 operations
CN113132978A (zh) * 2021-03-19 2021-07-16 翱捷科技股份有限公司 一种lte pdcp数据解密增强的方法及装置
CN114615657B (zh) * 2022-02-21 2023-12-22 翱捷科技股份有限公司 一种5g通信中的数据分段解密方法及装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107295459A (zh) * 2016-03-30 2017-10-24 财团法人工业技术研究院 用于d2d通信的通信系统、通信装置、基站及其方法
EP3319252A1 (en) * 2016-11-04 2018-05-09 Panasonic Intellectual Property Corporation of America Efficient multiplexing of control information in transport block
CN109644381A (zh) * 2017-06-15 2019-04-16 Oppo广东移动通信有限公司 数据处理方法及相关产品
WO2019102965A1 (ja) * 2017-11-22 2019-05-31 京セラ株式会社 通信方法、無線通信装置、及びプロセッサ
CN110365609A (zh) * 2018-04-10 2019-10-22 华为技术有限公司 一种数据包分段方法、及装置
CN112153696A (zh) * 2020-09-25 2020-12-29 Oppo广东移动通信有限公司 Rlc sdu分段处理方法、装置及终端
CN114124840A (zh) * 2021-11-26 2022-03-01 哲库科技(北京)有限公司 接收pdcp包的方法、pdcp包的接收装置、终端设备

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
LTE-A空口仪表RLC协议监测技术研究;李才齐;张治中;程方;;电视技术(第17期);全文 *
Samsung.R5-183227 "Editorial updates to 38.523-1".3GPP tsg_ran\wg5_test_ex-t1.2018,(第tsgr5_79_busan期),全文. *
ZTE, ZTE Microelectronics, Mediatek Inc.R2-167830 "Considerations on possible RLC optimizations".3GPP tsg_ran\WG2_RL2.2016,(第TSGR2_96期),全文. *

Also Published As

Publication number Publication date
WO2023155516A1 (zh) 2023-08-24
CN114615657A (zh) 2022-06-10

Similar Documents

Publication Publication Date Title
US10433206B2 (en) Method for processing radio protocol in mobile telecommunications system and transmitter of mobile telecommunications
KR100917205B1 (ko) 무선 통신 시스템에서의 데이터 블록 구성 방법
US7548532B2 (en) Method and apparatus to provide inline encryption and decryption for a wireless station via data streaming over a fast network
US20100309830A1 (en) Radio communication system and method having a radio link control layer
EP1892988A1 (en) Concealing device and concealing method
CN106797376B (zh) 移动通信网络中处理分组丢失的方法和装置
EP2079244A1 (en) Mobile communication system, radio base station, and handover control method
WO2010108353A1 (zh) Pdu的发送/接收方法和装置
CN114615657B (zh) 一种5g通信中的数据分段解密方法及装置
KR20020028096A (ko) 래디오 링크 콘트롤(rlc)의 인식 모드(am)에서데이터 송수신 처리방법
US9585014B2 (en) Fast recovery from ciphering key mismatch
EP1510017B1 (en) Synchronizing method and apparatus using error detection of sequence numbers to avoid synchronizing failure
US20240056802A1 (en) Method and apparatus for security of a wireless communication
CN107124435A (zh) 一种tcp报文加密电路及方法
KR20070074483A (ko) 이동통신 시스템에서 자동 재전송 요구 패킷 송수신 장치및 방법
KR20050018232A (ko) 암호화 통신 시스템에서 길이 지시자의 유효성 여부에따른 암호화 파라미터의 리셋 방법 및 장치
KR20050073904A (ko) 무선 네트워크 시스템의 무선링크제어 계층에서 데이터암호화방법 및 암호해제방법
CN116456333A (zh) 加密mac标头字段以用于wlan隐私增强

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB03 Change of inventor or designer information

Inventor after: Sun Jinzhong

Inventor after: Zheng Rui

Inventor after: Hu Chengsong

Inventor after: Wang Qingsong

Inventor before: Sun Jinzhong

Inventor before: Zheng Rui

CB03 Change of inventor or designer information
GR01 Patent grant
GR01 Patent grant