CN113366800A - 用具有不同长度的消息认证码的完整性保护 - Google Patents

用具有不同长度的消息认证码的完整性保护 Download PDF

Info

Publication number
CN113366800A
CN113366800A CN201980090627.1A CN201980090627A CN113366800A CN 113366800 A CN113366800 A CN 113366800A CN 201980090627 A CN201980090627 A CN 201980090627A CN 113366800 A CN113366800 A CN 113366800A
Authority
CN
China
Prior art keywords
message
mac
base station
rrc
length
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.)
Pending
Application number
CN201980090627.1A
Other languages
English (en)
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.)
Google LLC
Original Assignee
Google LLC
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 Google LLC filed Critical Google LLC
Publication of CN113366800A publication Critical patent/CN113366800A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

一种支持用于无线通信完整性保护的多个消息认证码(MAC)长度的用户设备中的方法，包括：从基站接收包括信息元素的第一消息(1002)，基于信息元素，确定多个MAC长度中的第一MAC长度将被用于完整性保护(1004)，然后生成包括具有第一MAC长度的MAC的第二消息(1006)。该方法还包括向基站传输第二消息(1008)。

Description

用具有不同长度的消息认证码的完整性保护
技术领域
本公开涉及无线通信的完整性保护，更具体地，涉及支持两个或更多个不同消息认证码长度的无线通信***。
背景技术
本文提供的背景描述是为了概括地呈现本公开的上下文的目的。当前命名的发明人的工作，就在本背景部分中描述的程度而言，以及在提交时可能不以其他方式符合现有技术的描述的方面，均未明示或暗示地承认为针对本公开的现有技术。
无线通信网络通常使用完整性保护技术来防止或减少网络攻击，诸如模仿有效消息的“伪造”攻击。例如，在某些蜂窝***中，传输设备使用特定的完整性保护算法和输入参数来计算消息认证码(或“MAC”，不要与更广泛使用的“媒体接入控制”的首字母缩写词混淆)，并将MAC连同正在传输的消息一起发送。接收设备使用与传输设备相同的算法和输入参数计算预期MAC，并通过将预期MAC与接收到的消息中的MAC进行比较来验证消息的数据完整性。
较长MAC增加了可能MAC值的数量，这转而降低了攻击者将能够生成与预期MAC匹配的MAC的可能性。例如，如果合法(非攻击者)传输设备使用32位MAC，“正确”MAC将是232(大约40亿)个可能序列中的一个。虽然这是一个很大的数量，但攻击者设备可能会通过用使用不同MAC的消息不断泛洪网络而最终成功。然而，256位MAC会导致2256个可能序列，这使得在任何合理的时间范围内几乎不可能匹配预期MAC。
第三代合作伙伴计划(3GPP)TS 33.501v15.2.0规定，对于第五代(5G)网络，传输设备使用特定的完整性保护算法和一组输入参数计算32位接入层MAC(“MAC-I”)或非接入层(NAS)-MAC(“NAS-MAC”)，用于控制平面和用户平面消息。为了提高安全性，3GPP发起了一项研究，以确定是否可以在不过度降低***性能的情况下将MAC-I和NAS-MAC增加到64、128甚至256位。然而，即使这样的增加不会显著降低***性能，这也可能会引入由使用不同MAC长度的不同设备引起的不兼容问题。
例如，当传输包括控制平面无线电资源控制(RRC)消息的分组数据汇聚协议(PDCP)协议数据单元(PDU)时，5G基站(例如，gNB)可能会使用256位算法计算MAC-I以附加到RRC消息，但是接收PDCP PDU的以其他方式兼容的用户设备(通常使用首字母缩写词UE，代表“用户装备”)可能会使用32位算法计算预期MAC-I(称为“XMAC-I”)。或者，传输基站可能使用32位算法计算MAC-I，而接收UE使用256位算法计算XMAC-I。在这两种场景下，由于XMAC-I与MAC-I不匹配，接收UE无法验证/认证消息，因此忽略/丢弃该消息。最终，在这种场景下，基站和UE之间的通信无法进行。
发明内容
在与本公开的用户设备交换消息期间的某个点，本公开的基站(例如，gNB)决定使用特定的消息认证码(MAC)长度用于完整性保护(例如，在接入层中)。该决定可以至少部分地基于用户设备的MAC长度能力。用户设备本身可以将用户设备MAC长度能力通知基站，或者核心网络(例如，5GC)可以在从不同的网络元件(诸如另一基站或注册服务器(例如，经由5GC的认证服务器功能或“AUSF”))获知用户设备MAC长度能力后通知基站这些能力。可替代地，核心网络可以决定使用特定MAC长度，然后将基站配置为使用该MAC长度。
在基站确定(或被通知)期望的MAC长度之后，基站向用户设备发送指示该MAC长度的消息。例如，该消息可以是包含在PDCP PDU中的RRC消息(例如，RRC重配置消息)或安全模式命令消息。在一些实现方式中，为了提供指示期望的MAC长度的消息的完整性保护，该消息包括具有不同长度的MAC。例如，用户设备最初可以默认为较短MAC长度，并且基站可以通过计算并附加具有较短长度的MAC来为指示MAC长度的消息提供完整性保护。在这样的实现方式中，用户设备例如通过计算具有较短MAC长度的预期MAC并将该预期MAC与附加的MAC进行比较来验证附加到消息的较短MAC。在用户设备接收到指示期望的MAC长度的消息并可能验证附加到该消息的另一(例如，较短)长度的MAC之后，用户设备使用所指示的MAC长度的MAC来为用户设备向基站发送和/或从基站接收的一个或多个附加消息提供完整性保护。
在一些实现方式中，基站消息指示专用于用户平面消息的期望的MAC长度，在这种情况下，用户设备将指示的MAC长度用于用户平面消息(例如，经由数据无线电承载(DRB)发送或接收的PDCP PDU)，但不一定用于控制平面消息(例如，经由信令无线电承载(SRB)发送或接收的RRC消息)。例如，用户设备可以继续针对控制平面消息使用默认(例如，较短的)MAC长度，除非基站发送指示新MAC长度将被用于控制平面消息的单独的消息。在一个这样的实现方式中，基站发送指示新MAC长度将被用于用户平面消息的安全命令消息，以及指示新MAC长度也将被用于控制平面消息的单独的RRC消息(例如，RRC重配置消息)。在其他实现方式中，基站消息指示MAC长度将被用于用户平面消息和控制平面消息两者。
这些技术的一个示例实现方式是一种支持用于无线通信的完整性保护的多个MAC长度的用户设备中的方法。该方法包括由处理硬件从基站接收包括信息元素的第一消息；由处理硬件基于信息元素确定多个MAC长度中的第一MAC长度将被用于完整性保护；并且，在确定第一MAC长度将被用于完整性保护之后，由处理硬件生成包括具有第一MAC长度的MAC的第二消息。该方法还包括向基站传输第二消息。
这些技术的另一示例实现方式是一种支持用于无线通信的完整性保护的多个MAC长度的基站中的方法。该方法包括由处理硬件确定多个MAC长度中的第一MAC长度将被用于完整性保护；由处理硬件生成包括指示第一MAC长度将被用于完整性保护的信息元素的第一消息，并且将第一消息传输到用户设备。该方法还包括在传输第一消息之后，由处理硬件从用户设备接收包括MAC的第二消息。该方法还包括由处理硬件计算具有第一MAC长度的预期MAC，并且由处理硬件将预期MAC与第二消息中的MAC进行比较以验证第二消息中的MAC是有效MAC。
这些技术的又一示例实现方式是其上存储有指令的非暂时性介质。当由支持用于无线通信的完整性保护的多个MAC长度的用户设备的处理硬件执行时，所述指令使用户设备从基站接收包括信息元素的第一消息；基于信息元素确定多个MAC长度中的第一MAC长度将被用于完整性保护；并且，在确定第一MAC长度将被用于完整性保护之后，生成包括具有第一MAC长度的MAC的第二消息。该指令还使用户设备向基站传输第二消息。
这些技术的又一示例实现方式是一个或多个核心网络元件(例如，一个或多个服务器和/或其他计算设备)中的方法。该方法包括由处理硬件从第一基站或第二基站接收包括第一信息元素的第一消息。该方法还包括由处理硬件基于第一信息元素确定用户设备支持第一基站所支持的多个MAC长度中的第一MAC长度用于完整性保护。该方法还包括由处理硬件生成第二消息，该第二消息包括指示第一MAC长度将被用于第一基站和用户设备之间的无线通信的完整性保护的第二信息元素。该方法还包括向第一基站传输第二消息以配置第一基站使用第一MAC长度用于与用户设备的无线通信。
附图说明
图1是其中本公开的用户设备和基站支持用于完整性保护的多个消息认证码(MAC)长度的示例无线通信网络的框图；
图2A-9B描绘了可能发生在图1的无线通信网络中的与MAC传输相关的各种消息传递序列；
图10是从用户设备的角度、用于应用适当的MAC长度以进行完整性保护的示例方法的流程图；以及
图11是从基站的角度、用于应用适当的MAC长度以进行完整性保护的示例方法的流程图。
具体实施方式
一般而言，本公开的技术允许用户设备(UE)和基站使用一致的消息认证码(MAC)长度来进行完整性保护，从而允许无线通信网络中的消息的认证/验证。因此，所公开的技术避免了由于缺乏认证而无法进行通信的场景。此外，所公开的技术可以避免其中所有用户设备和基站必须使用默认的、相对短的MAC长度，而不管它们的MAC长度能力如何的次优***设计。因此，在用户设备和基站都支持更稳健的完整性保护的场景中，可以加强完整性保护。
下面以参考第五代(5G)无线电接入(“NR”)网络以及有时演进的通用陆地无线电接入(EUTRA)网络的示例来讨论这些技术。此外，这些示例涉及5G核心网络(5GC)。然而，本公开的技术可以应用于其他无线电接入和/或核心网络技术。
首先参考图1，UE 102可以在示例无线通信网络100中操作。无线通信网络100包括与相应小区106-1和106-2相关联的基站104-1和104-2。虽然图1将基站104-1和104-2中的每一个描绘为仅服务于一个小区，但是应当理解，基站104-1和/或基站104-2也可以覆盖图1中未示出的一个或多个附加小区。通常，无线通信网络100可以包括任意数量的基站，并且基站中的每一个可以覆盖一个、两个、三个或任意其他合适数量的小区。
例如，基站104-1可以作为5G节点B(gNB)操作，并且基站104-2可以作为下一代演进节点B(ng-eNB)操作。如图1所示，基站104-1和基站104-2都连接到5GC 110，5GC 110转而连接到互联网112。在其他场景中，基站104-2可以不直接连接到5GC 110(例如，基站104-2可以连接到图1中未示出的另一核心网络，该另一核心网络转而与5GC 110通信)。在各种替选实现方式和/或场景中，无线通信网络100不包括基站104-2和/或小区106-2，或者基站104-2是另一gNB而小区106-2是另一NR小区等。
UE 102可以支持NR空中接口，并且当在NR小区106-1中操作时与基站104-1交换消息。在一些实现方式中，UE 102还可以支持EUTRA空中接口，并且当在NR小区106-1中操作时通过5G NR与基站104-1交换消息，并且当在EUTRA小区106-2中操作时通过EUTRA与基站104-2交换消息。在其他实现方式中，UE 102可以仅支持EUTRA。如下所讨论的，UE 102可以是能够进行无线通信的任何合适的设备。
UE 102配备有处理硬件120，其可以包括一个或多个通用处理器(例如，CPU)和存储一个或多个通用处理器可以运行的指令的非暂时性计算机可读存储器。附加地或可替代地，处理硬件120可以包括专用处理单元，诸如，例如无线通信芯片组。处理硬件120包括分组数据汇聚协议(PDCP)控制器122。PDCP控制器122负责无线通信协议栈130的对应层处的入站消息传递、出站消息传递和内部过程。例如，PDCP控制器122被配置为封装和解释嵌入了来自其他层的消息(诸如无线电资源控制(RRC)消息)的PDCP协议数据单元(PDU)。虽然图1中未示出，但处理硬件120还可以包括用于多个其他层中的每一层的控制器，诸如RRC控制器和/或移动性管理(MM)控制器。
可以使用硬件、软件和/或固件的任何合适的组合来实现PDCP控制器122。在一个示例实现方式中，PDCP控制器122是定义UE 102的操作***的相应组件的指令的集合，并且处理硬件120的一个或多个CPU执行这些指令以执行相应的PDCP功能。在另一实现方式中，PDCP控制器122使用作为无线通信芯片组的一部分的固件来实现。
图1中以简化方式示出的协议栈130包括物理层132(通常缩写为PHY)、媒体接入控制层134(其中媒体接入控制在这里不缩写为“MAC”，以避免混淆)、无线电链路控制(RLC)层136、PDCP层138、RRC层140以及可能的服务数据适配协议(SDAP)层141，作为接入层142的部分。协议栈130的非接入层(NAS)150除其他层外，还包括用于处理注册、附着或跟踪区域更新过程的一个或多个MM层160。
如图1进一步所示，协议栈130还支持用于各种服务和应用的高层协议154。例如，高层协议154可以包括互联网协议(IP)、传输控制协议和用户数据报协议(UDP)。PDCP控制器122被配置为封装和解释嵌入了高层协议(包括RRC层140和高层协议154)的数据分组的PDCP协议数据单元(PDU)。各个层132、134、136、138、140、141、152和154可以如图1所示被排序。然而，应当理解，在一些实现方式和/或情形下，所描绘的层中的一个或多个可以以不严格符合图1所示的排序的方式操作。
基站104-1配备有处理硬件160，其可以包括一个或多个通用处理器(例如，CPU)和存储所述一个或多个通用处理器可以运行的指令的非暂时性计算机可读存储器。附加地或可替代地，处理硬件160可以包括专用处理单元，诸如，例如无线通信芯片组。类似于UE 102的处理硬件120，处理硬件160包括PDCP控制器162。虽然UE 102的PDCP控制器122在用户设备侧实现PDCP层138的功能，但是，基站104-1的PDCP控制器162在基站侧实现PDCP层138的功能。虽然图1中未示出，但处理硬件160还可以包括用于多个其他层中的每一个的控制器，诸如RRC控制器和/或MM控制器。
可以使用硬件、软件和/或固件的任何合适的组合来实现PDCP控制器162。在一个示例实现方式中，PDCP控制器162是定义基站102的操作***的相应组件的指令的集合，并且处理硬件160的一个或多个CPU执行这些指令以执行相应的PDCP功能。在另一实现方式中，PDCP控制器162使用作为无线通信芯片组的一部分的固件来实现。在一些实现方式中，基站104-2包括与基站104-1的处理硬件160类似的处理硬件，但具体配置为在EUTRA小区106-2而不是NR小区106-1中操作。在其他实现方式中，基站104-2可以与基站104-2共同定位(co-locate)并且共享基站104-1的处理硬件160中的一些。
为了形成用于传输的PDCP PDU，PDCP控制器122或PDCP控制器162将PDCP报头前置(prepend)到要在PDCP PDU内传输的有效载荷(例如，数据分组或包括RRC消息的RRC PDU)，并且为了提供完整性保护，将接入层MAC(在本文中称为“MAC-I”)附加到有效载荷。为了便于解释，本文对PDCP PDU的内容的引用可能没有明确提及PDCP报头。虽然下面讨论的各种示例实现方式包括在PDCP PDU末尾处的MAC-I，但应当理解的是，在其他实现方式中，MAC-I可以改为位于PDCP PDU内的不同位置，或者可以包括在PDCP PDU以外的数据单元中。在以下描述中，对包括或包含RRC消息的PDCP PDU的任何引用被理解为意味着该PDCP PDU包括RRC PDU，该RRC PDU转而包括RRC消息。
PDCP控制器122或PDCP控制器162通过使用对具有特定值的各种参数进行操作的完整性算法(诸如在3GPP TS 38.331v15.4.0.中提及的“NIA”算法)来计算用于PDCP PDU的MAC-I。当接收到PDCP PDU时，PDCP控制器122或PDCP控制器162使用相同的(例如，NIA)算法，并且如果发送方/消息要被恰当地认证/验证，使用相同的参数和参数值计算“预期”MAC-I(在本文中称为XMAC-I)。PDCP控制器122或PDCP控制器162将XMAC-I与接收到的PDCPPDU的MAC-I进行比较，并且当且仅当XMAC-I与MAC-I匹配时验证PDCP PDU中包含的消息的真实性。例如，UE 102或基站104-1可以忽略和/或丢弃不能被验证的消息。在一些实现方式中，PDCP控制器122或PDCP控制器162通过使用对各种参数和有效载荷进行操作或对各种参数、PDCP PDU的PDCP报头和有效载荷进行操作的完整性算法来计算MAC-I或XMAC-I。
例如，NIA算法对“COUNT”参数值、“DIRECTION”参数值、“BEARER”参数值、“KEY”参数值和消息本身进行操作(即，接受作为输入)。“DIRECTION”参数具有反映传输的方向的二进制值(例如，“0”用于上行链路或“1”用于下行链路)，而“BEARER”参数具有反映无线电承载标识的5位值。在一些实现方式中，PDCP控制器122可以基于从基站104-1接收到的安全模式命令消息或RRC重配置消息来导出KEY参数值。类似地，PDCP控制器162可以基于基站104-1传输的安全模式命令消息或RRC重配置消息来导出KEY参数值。在一些实现方式中，KEY参数值针对用户平面和控制平面消息有所不同。
如下文将更详细地讨论的，UE 102的PDCP控制器122和基站104-1的PDCP控制器162各自支持至少两个MAC-I长度，包括较短的MAC-I(在本文中被称为“短MAC-I”)和较长的MAC-I(在本文中被称为“长MAC-I”)。例如，短MAC-I可以是32位MAC-I，而长MAC-I可以是64位、128位或256位MAC-I。对于本文讨论的任何给定实现方式或场景，应当理解对“短”MAC-I(或XMAC-I)的每次引用表示第一恒定位长度，并且对“长”MAC-I(或XMAC-I)的每次引用表示第二恒定位长度。因此，例如，如果引用两个消息，每个消息包含一个短MAC-I，对于特定的实现方式/场景，应当理解，这两个MAC-I具有相同的位长度。在替代实现方式中，PDCP控制122和/或PDCP控制器162还支持附加MAC-I长度(例如，和中间长度MAC-I)。
在一些实现方式中，PDCP控制器122和PDCP控制器162在计算长MAC-I或XMAC-I时各自使用较大尺寸的COUNT参数(即，具有较多位的COUNT参数值)，并且在计算短MAC-I或XMAC-I时各自使用较小尺寸的COUNT参数(即，具有较少位的COUNT参数值)。根据各种实现方式，下表提供了用于NIA算法的输入参数的位长度的示例。例如，UE 102和基站104-1可以支持示例1中所示的参数长度的组合(用于短MAC-I)和示例2至13中的任一个中所示的参数长度的组合(用于长MAC-I)两者：
Figure BDA0003184173590000081
Figure BDA0003184173590000091
在其中COUNT参数的位长度对于短MAC-I和长MAC-I不同的一些实现方式中，(例如，如果以上示例1和3都被支持)，则UE 102和基站104-1使用COUNT，如果基站104-1配置UE102使用长MAC-I，则UE 102的PDCP控制器122和基站104-1的PDCP控制器162使用用于长MAC-I的COUNT尺寸用于RRC消息或数据分组(如下面所讨论的)，并且如果基站104-1没有配置UE 102使用长MAC-I，则UE 102的PDCP控制器122和基站104-1的PDCP控制器162改为使用用于短MAC-I的COUNT尺寸用于RRC消息或数据分组。在其他实现方式中，UE 102的PDCP控制器122和基站104-1的PDCP控制器162使用相同的COUNT尺寸而不管MAC-I尺寸如何(例如，如果以上示例1和2都被支持)。
为简单起见，图1未描绘UE 102和基站104-1的各种组件。除了上面提及的层特定的控制器，例如，UE 102和基站104-1包括相应的收发器，其包括被配置为根据NR空中接口传输和接收无线信号的各种硬件、固件和软件组件。处理硬件120和处理硬件160可以根据需要用相应的收发器发送命令和交换信息以执行各种连接建立过程、执行各种RRC或MM过程、或与其他网络元件通信等。
现在将参考图2A-11讨论UE 102和/或基站104-1可以单独或与网络100的其他组件组合实现和运行的示例消息序列和方法。UE 102和/或基站104-1可以在软件、固件、硬件或软件、固件和硬件的任何合适的组合中实现以下描述的动作中的至少一些。虽然下面参考图1中描绘的组件和5G***(例如，其中基站104-1是gNB)来讨论图2A-11，通常可以使用任何合适的组件或无线通信网络。此外，虽然下面参考其中UE 102和基站104-1仅使用和/或支持两个MAC-I长度(即，短MAC-I和长MAC-I)的实现方式来讨论图2A-11，在其他实现方式中，UE 102和基站104-1支持三个或更多个MAC-I长度。
首先参考图2A和2B，消息传递图200描绘了根据一个实现方式和场景的可以在图1的UE 102和基站104-1之间交换的示例消息。在一些实现方式和/或场景中，在图2A和2B中描绘的消息序列的开始处，基站104-1还不知道UE 102支持长MAC-I，和/或UE 102还不知道基站104-1支持长MAC-I。
在消息传递图200中，在UE 102进入202RRC_IDLE状态之后，UE 102通过向基站104-1传输204RRC设立请求消息来发起RRC建立/设立过程。作为响应，基站104-1向UE 102传输206RRC设立消息。在所描绘的实现方式中，RRC设立请求和RRC设立消息不使用PDCP协议(即，两个消息绕过PDCP层138)，并且因此不被包括在PDCP PDU中。响应于RRC设立消息，UE 102进入210RRC_CONNECTED状态。
此后，UE 102的PDCP控制器122生成包含RRC设立完成消息和短(例如，32位)MAC-I的PDCP PDU。在一个实现方式中，因为基站104-1尚未配置UE 102以激活完整性保护，所以UE 102的PDCP控制器122将短MAC-I的所有位设置为零，或设置为某个其他默认值。UE 102然后向基站104-1传输212包含RRC设立完成消息和短MAC-I的PDCP PDU。
在接收到RRC设立完成消息之后，基站104-1的PDCP控制器162生成包含安全模式命令消息和短MAC-I的PDCP PDU。PDCP控制器162可以使用由安全模式命令消息中包括的RRC字段(例如，integrityProtAlgorithm字段)指示的完整性保护算法，并且还使用与该算法相关联的密钥(例如，3GPP TS 33.501的KRRCint密钥)来计算短MAC-I。例如，PDCP控制器162可以使用上面讨论的NIA算法来计算短MAC-I。基站104-1然后向UE 102传输214包含安全模式命令消息和短MAC-I的PDCP PDU。
在UE 102接收到包含安全模式命令消息和短MAC-I的PDCP PDU之后，UE 102的PDCP控制器122验证216短MAC-I以认证接收的消息。为此，PDCP控制器122导出与安全模式命令消息中指示的算法相关联的密钥(例如，与integrityProtAlgorithm相关联的KRRCint密钥)，并使用指示的算法和导出的密钥来计算短XMAC-I。例如，在没有来自基站104-1的不同命令或配置的情况下，PDCP控制器122可以默认为短MAC-I/XMAC-I格式。PDCP控制器122将接收到的PDCP PDU中的短MAC-I与计算的短XMAC-I进行比较。如果MAC-I和XMAC-I匹配，则UE 102已成功验证接收到的安全模式命令消息。
图2A和2B描绘了其中UE 102成功验证216安全模式命令消息的场景。不成功的验证(在该序列中的任何时间)可能导致UE 102丢弃该消息，或者在某些情形下，请求终止UE102和基站104-1之间的连接。因此，UE 102的PDCP控制器122生成包含安全模式完成消息和短MAC-I的PDCP PDU。PDCP控制器122可以使用由安全模式命令消息的字段指示的相同完整性保护算法并且还使用与该算法相关联的密钥(例如，KRRCint密钥)来计算短MAC-I。例如，PDCP控制器122可以使用上面讨论的NIA算法来计算短MAC-I。UE 102然后向基站104-1传输220包含安全模式完成消息和短MAC-I的PDCP PDU。在PDCP控制器122无法成功验证安全模式命令消息的其他场景中，UE 102不生成和/或发送包含安全模式完成消息的PDCP PDU。
在基站104-1接收到包含安全模式完成消息和短MAC-I的PDCP PDU之后，基站104-1的PDCP控制器162验证222短MAC-I以认证接收的消息。为此，PDCP控制器162使用相同的算法和密钥(例如，integrityProtAlgorithm和KRRCint密钥)来计算短XMAC-I。PDCP控制器162将接收到的PDCP PDU中的短MAC-I与计算的短XMAC-I进行比较。如果MAC-I和XMAC-I匹配，则基站104-1已成功验证接收到的安全模式完成消息。
如果基站104-1未能针对安全模式完成消息成功验证短MAC-I，则基站104-1可以向UE 102传输RRC释放消息以终止UE 102和基站104-1之间的连接。然而，图2A和2B描绘了其中基站104-1成功验证222安全模式完成消息的场景。在这种场景中，在验证之后的某个时间，基站104-1确定224配置为使用长(例如，64位、128位或256位)MAC-I格式。该确定可以在基站104-1获知UE 102支持长MAC-I格式之后发生，例如，如下面进一步详细讨论的(例如，结合图5)。
在确定224配置为使用长MAC-I格式之后(例如，响应于其)，基站104-1在RRC重配置消息中包括安全配置(指示长MAC-I格式)。基站104-1的PDCP控制器162生成包含RRC重配置消息和短MAC-I的PDCP PDU。PDCP控制器162可以使用相同的算法和密钥(例如，integrityProtAlgorithm和KRRCint密钥)计算短MAC-I。例如，PDCP控制器162可以使用上面讨论的NIA算法来计算短MAC-I。基站104-1然后向UE 102传输226包含RRC重配置消息和短MAC-I的PDCP PDU。
在UE 102接收到包含RRC重配置消息和短MAC-I的PDCP PDU之后，UE 102的PDCP控制器122验证230短MAC-I(如上面针对验证216所讨论的)以认证接收的消息。图2A和2B描绘了其中UE 102成功验证230RRC重配置消息的场景。因此，响应于UE 102基于安全配置和/或RRC重配置消息确定要使用长MAC-I格式，UE 102确定开始针对通过信令无线电承载(SRB)在UE 102和基站104-1之间交换的随后RRC消息使用长MAC-I格式。
在一些实现方式中，(由UE 102)对由基站104-1传输226的RRC重配置消息的成功验证仅使UE 102针对通过多个SRB的子集(例如，其中之一)在UE 102和基站104-1之间交换的RRC消息改变为长MAC-I格式。例如，UE 102可以针对通过第一SRB(例如“SRB 1”)发送的RRC消息而不针对通过第二SRB(例如“SRB 2”)发送的RRC消息应用长MAC-I格式。针对通过第二SRB发送的RRC消息，UE 102可以替代地继续使用短MAC-I格式(例如，直到由基站104-1另外配置为止)。在其他实现方式中，UE 102可以针对通过所有SRB发送的RRC消息改变为长MAC-I格式。
此外，在一些实现方式中，(由UE 102)对由基站104-1传输226的RRC重配置消息的成功验证，除了通过一个或多个SRB交换的RRC消息之外(或代替通过一个或多个SRB交换的RRC消息)，使UE 102针对通过一个或多个数据无线电承载(DRB)在UE 102和基站104-1之间交换的数据分组改变为长MAC-I格式。可替代地，UE 102可仅针对通过SRB(或所有SRB的子集，如果多于一个的话)发送的RRC消息而不针对通过任何DRB发送的数据分组改变为长MAC-I格式。例如，UE 102可以针对通过DRB发送的数据分组替代地使用短MAC-I格式。
在图2A和2B的场景中，在验证230之后，UE 102的PDCP控制器122生成包含RRC重配置完成消息和长MAC-I的PDCP PDU。PDCP控制器122可以使用由安全模式命令消息的字段指示的相同完整性保护算法以及可能还使用与该算法相关联的相同密钥(例如，KRRCint密钥)来计算长MAC-I。然而，如果安全配置和/或RRC重配置消息指示用于完整性保护的不同算法，则PDCP控制器122可以使用该算法(例如，以及KRRCint密钥)。UE 102然后向基站104-1传输232包含RRC重配置完成消息和长MAC-I的PDCP PDU，并且基站104-1使用UE 102已用于计算长MAC-I的相同完整性保护算法和密钥针对RRC重配置完成消息验证234长MAC-I。
图2A和2B的示例场景还包括UE 102或基站104-1向其附加长MAC-I的其他RRC消息的传输。例如，基站104-1生成并传输236包含另一RRC重配置消息(例如，具有用于测量配置、L1配置、媒体接入控制配置、RLC配置和/或无线电承载配置的字段)和长MAC-I(UE 102对其进行验证240)的PDCP PDU，UE 102生成并传输242包含另一RRC重配置完成消息以及长MAC-I的PDCP PDU(基站104-1对其进行验证244)，并且UE 102生成并传输246包含测量报告消息以及长MAC-I(基站104-1对其进行验证250)的PDCP PDU。在一些实现方式中，如果基站104-1未能针对从UE 102接收的任何RRC消息成功验证短MAC-I或长MAC-I，则基站104-1向UE 102传输RRC释放消息以终止UE 102和基站104-1之间的连接。
接下来参考图3A和3B，消息传递图300描绘了根据另一实现方式和/或场景的可以在图1的UE 102、基站104-1和5GC 110之间交换的示例消息。在一些实现方式和/或场景中，在图3A和3B中描绘的消息序列的开始处，基站104-1还不知道UE 102支持长MAC-I，和/或UE102还不知道基站104-1支持长MAC-I。
在消息传递图300中，在UE 102进入302RRC_IDLE状态之后，UE 102通过向基站104-1传输304RRC设立请求消息来发起RRC建立/设立过程。作为响应，基站104-1向UE 102传输306RRC设立消息。在所描绘的实现方式中，RRC设立请求和RRC设立消息不使用PDCP协议(即，两个消息绕过PDCP层138)，因此不被包括在PDCP PDU中。响应于RRC设立消息，UE102进入310RRC_CONNECTED状态。
此后，UE 102的PDCP控制器122生成包含RRC设立完成消息和短(例如，32位)MAC-I的PDCP PDU。在一个实现方式中，因为基站104-1尚未配置UE 102以激活完整性保护，所以UE 102的PDCP控制器122将短MAC-I的所有位设置为零，或设置为某个其他默认值。UE 102然后向基站104-1传输312包含RRC设立完成消息和短MAC-I的PDCP PDU。
在接收到RRC设立完成消息之后，基站104-1的PDCP控制器162生成包含安全模式命令消息和短MAC-I的PDCP PDU。PDCP控制器162可以使用由安全模式命令消息中包括的RRC字段(例如，integrityProtAlgorithm字段)指示的完整性保护算法，并且还使用与该算法相关联的密钥(例如，3GPP TS 33.501的KRRCint密钥)来计算短MAC-I。例如，PDCP控制器162可以使用上面讨论的NIA算法来计算短MAC-I。基站104-1然后向UE 102传输314包含安全模式命令消息和短MAC-I的PDCP PDU。
在UE 102接收到包含安全模式命令消息和短MAC-I的PDCP PDU之后，UE 102的PDCP控制器122验证316短MAC-I以认证接收的消息。为此，PDCP控制器122导出与安全模式命令消息中指示的算法相关联的密钥(例如，与integrityProtAlgorithm相关联的KRRCint密钥)，并使用指示的算法和导出的密钥来计算短XMAC-I。例如，在没有来自基站104-1的不同命令或配置的情况下，PDCP控制器122可以默认为短MAC-I/XMAC-I格式。PDCP控制器122将接收到的PDCP PDU中的短MAC-I与计算的短XMAC-I进行比较。如果MAC-I和XMAC-I匹配，则UE 102已成功验证接收到的安全模式命令消息。
图3A和3B描绘了其中UE 102成功验证316安全模式命令消息的场景。不成功的验证(在该序列中的任何时间)可能导致UE 102丢弃该消息，或者在某些情形下，请求终止UE102和基站104-1之间的连接。因此，UE 102的PDCP控制器122生成包含安全模式完成消息和短MAC-I的PDCP PDU。PDCP控制器122可以使用由安全模式命令消息的字段指示的相同完整性保护算法并且还使用与该算法相关联的密钥(例如，KRRCint密钥)来计算短MAC-I。例如，PDCP控制器122可以使用上面讨论的NIA算法来计算短MAC-I。UE 102然后向基站104-1传输320包含安全模式完成消息和短MAC-I的PDCP PDU。在PDCP控制器122无法成功验证安全模式命令消息的其他场景中，UE 102不生成和/或发送包含安全模式完成消息的PDCP PDU。
在基站104-1接收到包含安全模式完成消息和短MAC-I的PDCP PDU之后，基站104-1的PDCP控制器162验证322短MAC-I以认证接收的消息。为此，PDCP控制器162使用相同的算法和密钥(例如，integrityProtAlgorithm和KRRCint密钥)来计算短XMAC-I。PDCP控制器162将接收到的PDCP PDU中的短MAC-I与计算的短XMAC-I进行比较。如果MAC-I和XMAC-I匹配，则基站104-1已成功验证接收到的安全模式完成消息。
如果基站104-1未能针对安全模式完成消息成功验证短MAC-I，则基站104-1可以向UE 102传输RRC释放消息以终止UE 102和基站104-1之间的连接。然而，图3A和3B描绘了其中基站104-1成功验证322安全模式完成消息的场景。在这个场景中，在验证之后的某个时间，基站104-1确定324配置为使用长(例如，64位、128位或256位)MAC-I格式，专门用于UE102的DRB。该确定可以在基站104-1获知UE 102支持长MAC-I格式之后发生，例如，如下面进一步详细讨论的(例如，结合图5)。
在(例如，响应于)确定324配置为针对DRB使用长MAC-I格式之后，基站104-1在RRC重配置消息中包括安全配置(针对DRB指示长MAC-I格式)。基站104-1的PDCP控制器162生成包含RRC重配置消息和短MAC-I的PDCP PDU。PDCP控制器162可以使用相同的算法和密钥(例如，integrityProtAlgorithm和KRRCint密钥)计算短MAC-I。例如，PDCP控制器162可以使用上面讨论的NIA算法来计算短MAC-I。基站104-1然后向UE 102传输326包含RRC重配置消息和短MAC-I的PDCP PDU。
在UE 102接收到包含RRC重配置消息和短MAC-I的PDCP PDU之后，UE 102的PDCP控制器122验证330短MAC-I(如上面针对验证316所讨论的)以认证接收的消息。图3A和3B描绘了其中UE 102成功验证330RRC重配置消息的场景。因此，响应于UE 102(基于安全配置和/或RRC重配置消息)确定长MAC-I格式将被用于UE 102的DRB，UE 102确定开始针对通过DRB在UE 102和基站104-1之间交换的随后数据分组使用长MAC-I格式。
在图3A和3B的示例场景中，在验证330之后，UE 102的PDCP控制器122生成包含RRC重配置完成消息和短MAC-I的PDCP PDU。也就是说。图3A和3B反映了其中配置为长MAC-I格式不适用于通过SRB在UE 102和基站104-1之间交换的RRC消息的实现方式。然而，在一些实现方式中，PDCP控制器122使用由安全模式命令消息的字段指示的相同完整性保护算法以及可能还有与该算法相关联的相同密钥(例如，KRRCint钥匙)来计算短MAC-I。UE 102然后向基站104-1传输332包含RRC重配置完成消息和短MAC-I的PDCP PDU，并且基站104-1使用与UE 102已经用于计算短MAC-I相同的完整性保护算法和密钥针对RRC重配置完成消息验证334短MAC-I。
同样在图3A和3B的场景中，当UE 102需要经由DRB发送一些数据(例如，与层154相关的数据)时，UE 102的PDCP控制器122生成包含数据分组和长MAC-I的PDCP PDU(或者，在一些实现方式中为SDAP PDU)。例如，数据分组可以是互联网协议(IP)分组。如果基站104-1配置UE 102针对DRB使用SDAP，则UE 102生成包含数据分组的SDAP PDU，然后将SDAP PDU包括在PDCP PDU中。在某些实现方式和/或场景下，PDCP控制器122可以使用由安全模式命令消息的字段指示的相同完整性保护算法以及可能还有与该算法相关联的相同密钥(例如，KRRCint密钥)来计算长MAC-I。然而，如果安全配置和/或RRC重配置消息指示用于完整性保护的不同算法，则PDCP控制器122可以使用该算法(例如，以及KRRCint密钥)。UE 102然后通过DRB传输336包含数据分组和长MAC-I的PDCP PDU(或SDAP PDU)，并且基站104-1验证340PDCP PDU的长MAC-I(即，通过计算长XMAC-I并与接收到的长MAC-I进行比较)。如果基站104-1配置UE 102针对DRB使用SDAP，则基站104-1从SDAP PDU中提取数据分组。基站104-1然后向5GC 110传输342来自PDCP PDU的数据分组。
在图3A和3B的示例场景中，5GC 110然后向基站104-1传输344用于DRB的另一数据分组(例如，与层154相关的数据)。基站104-1的PDCP控制器162然后生成包含数据分组和长MAC-I的PDCP PDU(或者，在一些实现方式中为SDAP PDU)。例如，数据分组可以是IP分组。如果基站104-1配置UE 102针对DRB使用SDAP，则基站104-1生成包含数据分组的SDAP PDU，然后将SDAP PDU包括在PDCP PDU中。在某些实现方式和/或场景中，PDCP控制器162可以使用由安全模式命令消息的字段指示的相同完整性保护算法以及可能还有与该算法相关联的相同密钥(例如，KRRCint密钥)来计算PDCP PDU的长MAC-I。然而，如果安全配置和/或RRC重配置消息指示用于完整性保护的不同算法，则PDCP控制器162可以使用该算法(例如，以及KRRCint密钥)。基站104-1然后通过DRB传输346包含数据分组和长MAC-I的PDCP PDU(或SDAPPDU)，并且UE 102验证348PDCP PDU的长MAC-I(即，通过计算长XMAC-I并与接收到的长MAC-I进行比较)。
在对应于图3A和3B的示例消息图的第一实现方式中，在传输326之前，基站104-1向UE 102配置第一DRB(例如，“DRB 1”)，针对第一DRB配置完整性保护，并且向UE 102配置第二DRB(例如,“DRB 2”)，但针对第二DRB不配置完整性保护。为此，基站104-1可以(在传输326之前)在一个或多个PDCP PDU中的每一个内向UE 102传输附加RRC重配置消息和相应的短MAC-I。此后，如果UE 102针对在传输326中发送的RRC重配置消息成功验证了短MAC-I，则UE 102不针对第二DRB使用长MAC-I格式。也就是说，在该实现方式和场景中，UE 102和基站104-1在通过第二DRB交换的PDCP PDU中既不包括短MAC-I也不包括长MAC-I。
在对应于图3A和3B的示例消息图的第二实现方式中，在传输326之前，基站104-1向UE 102配置第一DRB(例如，“DRB 1”)，针对第一DRB配置完整性保护，向UE 102配置第二DRB(例如,“DRB 2”)，并且针对第二DRB配置完整性保护。为此，基站104-1可以(在传输326之前)在一个或多个PDCP PDU中的每一个内向UE 102传输附加RRC重配置消息和相应的短MAC-I。在该实现方式中，UE 102针对要通过两个DRB中的任一个传输或接收的数据分组使用短MAC-I格式(例如，来以上面讨论的方式计算短MAC-I或XMAC-I)。此后，如果UE 102针对在传输326中发送的RRC重配置消息成功验证了短MAC-I，则UE 102可以针对通过第二DRB发送的数据分组使用长MAC-I格式。也就是说，安全配置不仅适用于第一DRB，也适用于第二DRB。
在对应于图3A和3B的示例消息图的第三实现方式中，在传输326之前，基站104-1向UE 102配置第一DRB(例如，“DRB 1”)，针对第一DRB配置完整性保护，向UE 102配置第二DRB(例如,“DRB 2”)，并且针对第二DRB配置完整性保护。为此，基站104-1可以(在传输326之前)在一个或多个PDCP PDU中的每一个内向UE 102传输附加RRC重配置消息和相应的短MAC-I。在该实现方式中，UE 102针对要通过两个DRB中的任一个传输或接收的数据分组使用短MAC-I格式(例如，来以上面讨论的方式计算短MAC-I或XMAC-I)。因此，第三实现方式最初可以与上面讨论的第二实现方式相同或相似。然而，如果UE 102然后针对在传输中发送的RRC重配置消息成功地验证了短MAC-I，则UE 102针对通过第二DRB发送的数据分组不使用长MAC-I格式。也就是说，安全配置适用于第一DRB而不适用于第二DRB。
在上述第一、第二和第三实现方式中的每一个中，基站104-1可以以图3A和3B中所示的方式配置UE 102使用长MAC-I格式。因此，对于上面讨论的(一个或多个)附加RRC重配置消息中的每一个，基站104-1可以在该附加RRC重配置消息中包括安全配置(指示长MAC-I格式)，并且在PDCP PDU中向UE 102传输该附加RRC重配置消息(例如，在传输326发生之前)。
在一些实现方式中，如果基站104-1针对通过DRB接收的数据分组未能成功验证长MAC-I，则基站104-1向UE 102传输RRC释放消息以终止UE 102和基站104-1之间的连接。在替代实现方式中，如果基站104-2针对通过DRB接收的数据分组未能成功验证长MAC-I，则基站104-1忽略该数据分组。然而，在该替代实现方式中，如果基站104-1针对通过DRB接收的多个数据分组(例如，由基站104-1预先确定的某个阈值数量的数据分组)未能成功验证长MAC-I，则基站104-1向UE 102传输RRC释放消息，终止UE 102和基站104-1之间的连接。取决于实现方式，基站104-1可以仅在基站104-1连续接收到多个数据分组时才发送RRC释放消息，或者可以不管基站104-1是否连续接收到多个数据分组而发送RRC释放消息。
此外，在一些实现方式中，基站104-1可以配置UE 102针对(一个或多个)SRB和(一个或多个)DRB同时使用长MAC-I格式，如图4A和4B的示例实现方式和场景中所示。在图4A和4B中，消息传递图400描绘了根据另一实现方式和/或场景的可以在图1的UE 102、基站104-1和5GC 110之间交换的示例消息。图4A和4B中所示的动作和消息可以与图3A和3B中所示的对应动作和消息相似或相同(例如，其中图3A的302对应于图4A的402，图3A的304对应于图4A的404等)，除了：(1)在消息传递图400中基站104-1确定424针对(一个或多个)SRB和(一个或多个)DRB两者(而不仅仅是DRB)配置为使用长MAC-I格式；(2)在消息传递图400中传输426的RRC重配置消息包括针对(一个或多个)SRB和(一个或多个)DRB两者(而不仅仅是DRB)指示长MAC-I格式的安全配置；(3)(在传输432中)包含RRC重配置完成消息的PDCP PDU包括长MAC-I(而不是短MAC-I)；(4)基站验证434包含RRC重配置完成消息的PDCP PDU中的长MAC-I(而不是短MAC-I)。
如上所述，在一些实现方式中，基站104-1可能需要在尝试配置UE 102使用长MAC-I格式之前获知UE 102的MAC-I长度能力。例如，UE 102可以向基站104-1或5GC 110传输指示UE 102支持长MAC-I格式的UE能力信息。例如，基站104-1可以将来自UE 102的UE能力信息转发到核心网络。在一些实现方式和/或场景中，在向UE 102传输426配置长MAC-I格式的RRC重配置消息(例如，如前所述)之前，基站104-1从UE 102或5GC 110(例如，从接入和移动性管理功能(AMF))接收指示对长MAC-I格式的支持的UE能力信息。
例如，由UE 102传输的UE能力信息可以具有与由基站104-1接收的UE能力信息相同的格式，或者可以具有不同的格式。基站104-1可以响应于确定UE能力信息指示UE 102支持长MAC-I来确定配置长MAC-I格式。如果UE 102替代地指示不支持长MAC-I(或者基站只是没有接收到UE 102对长MAC-I的支持的指示)，则基站104-1可能无法确定向UE 102配置长MAC-I格式，或者可以明确确定不向UE 102配置长MAC-I。在其他实现方式和/或场景中，响应于5GC 110确定UE能力信息指示UE 102支持长MAC-I，5GC 110可以发送网络接口消息以配置基站104-1针对UE 102使用长MAC-I格式。
图5描绘了对应于其中可以是gNB或ng-eNB的基站104-1获知UE 102的能力的一种实现方式和场景的消息传递图500。在消息传递图500中，UE 102进入502RRC_CONNECTED状态。基站104-1的PDCP控制器162生成包含用于查询UE 102的5G NR能力的UE能力查询消息以及还包含短MAC-I的PDCP PDU。基站104-1向UE 102传输504包含UE能力查询消息和短MAC-I的PDCP PDU。
作为响应，如果UE 102成功地验证了包含UE能力查询消息的PDCP PDU中的短MAC-I，则UE 102向基站104-1传输506包含在PDCP PDU中的UE能力信息消息，该PDCP PDU还包含由PDCP控制器122计算的短MAC-I。UE能力信息消息包括UE-NR-Capability信息元素。在所描绘的场景中，UE-NR-Capability信息元素指示UE 102支持长MAC-I格式。
在成功验证附加到UE能力信息消息的短MAC-I并识别该消息中的UE-NR-Capability信息元素之后，基站104-1将UE-NR-Capability信息元素包括在网络接口消息(例如，下一代应用协议(NGAP)消息或UE RADIO CAPABILITY INFO INDICATION(无线电能力信息指示)消息)中，并向5GC 110传输510该消息。在其他实现方式中，基站104-1从5GC110接收指示UE支持长MAC-I格式或将UE 102和基站104-1之间的通信配置为长MAC-I的网络接口消息(例如，NGAP消息或INITIAL CONTEXT SETUP REQUEST(初始上下文设立请求)消息)。
在替代实现方式和/或场景中，在如本公开中别处(例如，关于传输204、304或404)描述的传输RRC设立请求消息之前的时间，在如本公开中别处(例如，关于传输226、326或426)描述的接收向UE 102配置长MAC-I格式的RRC重配置消息之前的时间，或连同本公开中别处描述的RRC设立完成消息(例如，通过在传输212、312或412中包括注册请求消息)，UE102在注册请求消息中包括指示支持长MAC-I格式的UE能力信息，并且在UE 102注册到5GC110时，经由基站(即，经由基站104-1或诸如基站104-2的另一基站)向5GC 110传输注册请求消息。此后，当UE 102经由基站104-1连接到5GC 110时，5GC 110向基站104-1传输网络接口消息，该消息包括指示UE 102支持长MAC-I格式的信息元素(例如，UE安全能力信息元素)。
在另一实现方式和/或场景中，5GC 110从基站(即，基站104-1或诸如基站104-2的另一基站)接收包括指示支持长MAC-I格式的UE能力信息的UE-NR-Capability信息元素。例如，传输基站可以将UE-NR-Capability信息元素包括在UE RADIO CAPABILITY INFOINDICATION消息中。
图6描绘了反映其中5GC 110已经以这种方式获知UE能力信息的一个示例实现方式和场景的消息传递图600。如图6所示，在UE 102进入602RRC_IDLE阶段之后，UE 102向基站104-1传输604RRC设立请求消息，基站104-1向UE 102传输606RRC设立消息，UE 102进入610RRC_CONNECTED状态，并且UE 102向基站104-1传输612包含RRC设立完成消息和短MAC-I的PDCP PDU，如上面针对其他实现方式所描述的。
在一个实现方式中，已经如上所述获知UE能力信息的5GC 110确定614配置基站104-1(关于与UE 102的通信)使用长MAC-I格式。然后，当UE 102经由基站104-1连接到5GC110时，5GC 110向基站104-1传输616消息(例如，诸如INITIAL CONTEXT SETUP REQUEST消息的NGAP消息)。该消息(例如，在长MAC-I配置信息元素中)指示/指令基站104-1将配置为使用长MAC-I格式用于与UE 102的通信。通过分析/处理该消息，基站104-1确定620配置为使用长MAC-I格式，并且(图6中未示出)可以传输网络接口消息以配置基站104-1使用长MAC-I格式。
在替代实现方式和/或场景中，5GC 110不确定614关于与UE 102的通信将基站104-1配置为长MAC-I格式。替代地，5GC 110仅传输616UE 102支持长MAC-I格式的指示(例如，在诸如NGAP消息中的UE-NR-Capability信息元素或UE安全能力信息元素的能力信息元素中)，并且基站104-1基于该指示确定620配置为使用长MAC-I格式。
图7-9示出了当5GC 110(1)配置基站104-1使用长MAC-I格式用于与UE 102的通信，或(2)指示UE支持长MAC-I格式，使得基站104-1本身可以决定使用长MAC-I格式进行与UE 102的通信时，用于配置UE 102使用长MAC-I格式的各种实现方式和/或场景。
首先参考图7A和7B，在UE 102进入702RRC_IDLE阶段之后，UE 102向基站104-1传输704RRC设立请求消息，基站104-1向UE 102传输706RRC设立消息，UE 102进入710RRC_CONNECTED状态，并且UE 102向基站104-1传输712包含RRC设立完成消息和短MAC-I的PDCPPDU，如以上针对其他实现方式(例如，关于图2A和2B)所描述的。
在一个实现方式和/或场景中，在传输712之前、期间或之后的某个点，5GC 110确定714配置基站104-1以使用长MAC-I格式(为了与UE 102的通信的目的)。例如，5GC 110可能已经以上面讨论的任何方式(例如，如以上结合图5或6讨论的)获知UE 102支持长MAC-I格式。然后，当UE 102经由基站104-1连接到5GC 110时，5GC 110向基站104-1传输716消息(例如，诸如INITIAL CONTEXT SETUP REQUEST消息的NGAP消息)。该消息(例如，在长MAC-I配置信息元素中)指示/指令基站104-1将配置为使用长MAC-I格式用于与UE 102的通信。通过分析/处理该消息，基站104-1确定720配置为使用长MAC-I格式。
在替代实现方式和/或场景中，5GC 110不确定714关于与UE 102的通信配置基站104-1以使用长MAC-I格式。替代地，在(例如，从基站104-2)接收到UE 102支持长MAC-I格式的指示(例如，在诸如UE-NR-Capability信息元素或UE安全能力信息元素的能力信息元素中)之后，5GC 110仅传输716UE 102支持长MAC-I格式的指示，并且基站104-1基于该指示确定720配置为使用长MAC-I格式。
在5GC 110不传输716UE支持长MAC-I格式的指示或配置为使用长MAC-I格式的指令的其他场景中，基站104-1不配置为使用长MAC-I格式，并且不配置UE 102使用长MAC-I格式。可替代地，在这样的场景中，基站104-1可以向UE 102传输UE能力查询消息，并且作为响应从UE 102接收UE能力信息消息，例如，如上面结合图5所讨论的。
回到图7A和7B的场景，在基站104-1确定720配置为使用长MAC-I格式之后，基站104-1的PDCP控制器162生成包含安全模式命令消息和短MAC-I的PDCP PDU。安全模式命令消息包括UE 102将配置为使用长MAC-I格式用于与基站104-1的通信的指示。例如，PDCP控制器162可以使用上面讨论的任何算法和密钥(例如，integrityProtAlgorithm和KRRCint密钥)来计算短MAC-I。基站104-1向UE 102传输722包含安全模式命令消息和短MAC-I的PDCPPDU，并且UE 102使用相同的算法和密钥验证724短MAC-I。
在短MAC-I的成功验证之后，UE 102的PDCP控制器122生成包含安全模式完成消息和长MAC-I的PDCP PDU。例如，PDCP控制器122可以使用上面讨论的任何算法和密钥(例如，integrityProtAlgorithm和KRRCint密钥)来计算长MAC-I。UE 102向基站104-1传输726包含安全模式完成消息和长MAC-I的PDCP PDU，并且基站104-1使用相同的算法和密钥验证730长MAC-I。
稍后，在图7A和7B的示例场景中，基站104-1的PDCP PDU控制器162生成包含RRC重配置消息和长MAC-I的PDCP PDU，并且基站104-1向UE 102传输732该PDCP PDU。例如，RRC重配置消息可以包括与图2的消息传递图200中的传输236的RRC重配置消息相同的字段。在UE102针对RRC重配置消息验证734长MAC-I之后，UE 102的PDCP控制器122可以生成包含RRC重配置完成消息和长MAC-I的PDCP PDU，并且UE 102可以向基站104-1传输736PDCP PDU。在基站104-1针对RRC重配置完成消息验证740长MAC-I之后的某个时间，UE 102的PDCP控制器122可以生成包含测量报告消息和长MAC-I的PDCP PDU，并且UE 102可以向基站104-1传输742PDCP PDU。基站104-1然后针对测量报告消息验证744长MAC-I。
图8A和8B描绘了反映其中基站104-1在安全模式命令消息中配置UE 102针对一个或多个SRB和一个或多个DRB使用长MAC-I格式的实现方式和场景的消息传递图800。在消息传递图800中，在UE 102进入802RRC_IDLE阶段之后，UE 102向基站104-1传输804RRC设立请求消息，基站104-1向UE 102传输806RRC设立消息，UE 102进入810RRC_CONNECTED状态，并且UE 102向基站104-1传输812包含RRC设立完成消息和短MAC-I的PDCP PDU，如上文针对其他实现方式(例如，关于图4A和4B)所描述的。
在一个实现方式和/或场景中，在传输812之前、期间或之后的某个点，5GC 110确定814将基站104-1配置为长MAC-I格式(为了与UE 102的通信的目的)。例如，5GC 110可能已经以上面讨论的任何方式(例如，如以上结合图5或6讨论的)获知UE 102支持长MAC-I格式。然后，当UE 102经由基站104-1连接到5GC 110时，5GC 110向基站104-1传输816消息(例如，诸如INITIAL CONTEXT SETUP REQUEST消息的NGAP消息)。该消息(例如，在长MAC-I配置信息元素中)指示/指令基站104-1将配置为使用长MAC-I格式用于与UE 102的通信。通过分析/处理该消息，基站104-1确定820配置为使用长MAC-I格式。
在替代实现方式和/或场景中，5GC 110不确定814关于与UE 102的通信配置基站104-1以使用长MAC-I格式。替代地，在(例如，从基站104-2)接收到UE 102支持长MAC-I格式的指示(例如，在诸如NGAP消息中的UE-NR-Capability信息元素或UE安全能力信息元素的能力信息元素中)之后，5GC 110仅向基站104-1传输816UE 102支持长MAC-I格式的指示，并且基站104-1基于该指示确定820配置为使用长MAC-I格式。
在5GC 110不传输816UE支持长MAC-I格式的指示或配置为使用长MAC-I格式的指令的其他场景中，基站104-1不配置为使用长MAC-I格式，并且不配置UE 102使用长MAC-I格式。可替代地，在这样的场景中，基站104-1可以向UE 102传输UE能力查询消息，并且作为响应从UE 102接收UE能力信息消息，例如，如上面结合图5所讨论的。
返回图8A和8B的场景，在基站104-1确定820配置为使用长MAC-I格式之后，基站104-1的PDCP控制器162生成包含安全模式命令消息和短MAC-I的PDCP PDU。安全模式命令消息包括UE 102将配置为使用长MAC-I格式用于与基站104-1的通信的指示。例如，PDCP控制器162可以使用上面讨论的任何算法和密钥(例如，integrityProtAlgorithm和KRRCint密钥)来计算短MAC-I。基站104-1向UE 102传输822包含安全模式命令消息和短MAC-I的PDCPPDU，并且UE 102使用相同的算法和密钥验证824短MAC-I。
在短MAC-I的成功验证之后，UE 102的PDCP控制器122生成包含安全模式完成消息和长MAC-I的PDCP PDU。例如，PDCP控制器122可以使用上面讨论的任何算法和密钥(例如，integrityProtAlgorithm和KRRCint密钥)来计算长MAC-I。UE 102向基站104-1传输826包含安全模式完成消息和长MAC-I的PDCP PDU，并且基站104-1使用相同的算法和密钥验证830长MAC-I。
稍后，在图8A和8B的示例场景中，基站104-1的PDCP PDU控制器162生成包含RRC重配置消息和长MAC-I的PDCP PDU。RRC重配置消息包括指示UE 102将启用针对DRB(或者，在一些实现方式中，多于一个DRB)的完整性保护的信息元素。基站104-1向UE 102传输832PDCP PDU。在UE 102验证834长MAC-I之后，UE 102启用针对DRB的完整性保护，并且UE102的PDCP控制器122可以生成包含数据分组和长MAC-I的PDCP PDU。UE 102通过DRB向基站104-1传输836PDCP PDU，并且基站104-1验证840数据分组的长MAC-I。基站104-1然后可以向5GC 110传输842数据分组。
在图8A和8B的示例场景中，5GC 110然后向基站104-1传输844用于DRB的另一数据分组(例如，与层154相关的数据)。基站104-1的PDCP控制器162然后生成包含数据分组和长MAC-I的PDCP PDU。例如，数据分组可以是IP分组。在某些实现方式和/或场景中，PDCP控制器162可以使用由安全模式命令消息的字段指示的相同完整性保护算法以及可能还有与该算法相关联的相同密钥(例如，KRRCint密钥)来计算PDCP PDU的长MAC-I。然而，如果安全配置和/或RRC重配置消息指示用于完整性保护的不同算法，则PDCP控制器162可以使用该算法(例如，以及KRRCint密钥)。基站104-1然后通过DRB传输846包含数据分组和长MAC-I的PDCPPDU，并且UE 102验证848PDCP PDU的长MAC-I(即，通过计算长XMAC-I并与接收到的长MAC-I进行比较)。在一些实现方式和/或场景中，UE 102和基站104-1可以替代地为DRB生成SDAPPDU(例如，如上面结合图3A和3B所讨论的)。
图9A和9B描绘了反映其中基站104-1在安全模式命令消息中配置UE 102为针对一个或多个SRB使用长MAC-I格式的实现方式和场景的消息传递图900。在消息传递图900中，在UE 102进入902RRC_IDLE阶段之后，UE 102向基站104-1传输904RRC设立请求消息，基站104-1向UE 102传输906RRC设立消息，UE 102进入910RRC_CONNECTED状态，并且UE 102向基站104-1传输912包含RRC设立完成消息和短MAC-I的PDCP PDU，如上面针对其他实现方式(例如，关于图4A和4B)所描述的。
在一个实现方式和/或场景中，在传输912之前、期间或之后的某个点，5GC 110确定914将基站104-1配置为长MAC-I格式(为了与UE 102的通信的目的)。例如，5GC 110可能已经以上面讨论的任何方式(例如，如以上结合图5或6讨论的)获知UE 102支持长MAC-I格式。然后，当UE 102经由基站104-1连接到5GC 110时，5GC 110向基站104-1传输916消息(例如，诸如INITIAL CONTEXT SETUP REQUEST消息的NGAP消息)。该消息(例如，在长MAC-I配置信息元素中)指示/指令基站104-1将配置为针对通过一个或多个SRB与UE 102的通信使用长MAC-I格式。通过分析/处理该消息，基站104-1确定920配置为针对(一个或多个)SRB使用长MAC-I格式。
在替代实现方式和/或场景中，5GC 110没有确定914关于通过(一个或多个)SRB与UE 102的通信配置基站104-1以使用长MAC-I格式。替代地，在(例如，从基站104-2)接收到UE 102支持长MAC-I格式的指示之后，5GC 110仅向基站104-1传输916UE 102支持长MAC-I格式的指示(例如，在诸如NGAP消息中的UE-NR-Capability信息元素或UE安全能力信息元素的能力信息元素中)，并且基站104-1基于该指示确定920配置为针对(一个或多个)SRB使用长MAC-I格式。
在5GC 110不传输916UE支持长MAC-I格式的指示或配置为使用长MAC-I格式的指令的其他场景中，基站104-1不配置为针对(一个或多个)SRB使用长MAC-I格式，并且不配置UE 102为针对(一个或多个)SRB使用长MAC-I格式。可替代地，在这样的场景中，基站104-1可以向UE 102传输UE能力查询消息，并且作为响应从UE 102接收UE能力信息消息，例如，如上面结合图5所讨论的。
返回图9A和9B的场景，在基站104-1确定920配置为针对(一个或多个)SRB使用长MAC-I格式之后，基站104-1的PDCP控制器162生成包含安全模式命令消息和短MAC-I的PDCPPDU。安全模式命令消息包括UE 102将配置为针对通过(一个或多个)SRB与基站104-1的通信使用长MAC-I格式的指示。例如，PDCP控制器162可以使用上面讨论的任何算法和密钥(例如，integrityProtAlgorithm和KRRCint密钥)来计算短MAC-I。基站104-1向UE 102传输922包含安全模式命令消息和短MAC-I的PDCP PDU，并且UE 102使用相同的算法和密钥验证924短MAC-I。
在短MAC-I的成功验证之后，UE 102的PDCP控制器122生成包含安全模式完成消息和长MAC-I的PDCP PDU。例如，PDCP控制器122可以使用上面讨论的任何算法和密钥(例如，integrityProtAlgorithm和KRRCint密钥)来计算长MAC-I。UE 102向基站104-1传输926包含安全模式完成消息和长MAC-I的PDCP PDU，并且基站104-1使用相同的算法和密钥验证930长MAC-I。
在验证930之前、期间或之后的某个时间，5GC 110确定932针对DRB或针对PDU会话(因此，针对与该PDU会话相关联的DRB)配置基站104-1为长MAC-I。5GC 110然后向基站104-1传输934消息，指令基站104-1针对DRB或PDU会话配置为使用长MAC-I格式。作为响应，基站104-1确定936针对DRB或PDU会话配置为使用长MAC-I。基站104-1的PDCP PDU控制器162然后生成包含RRC重配置消息和长MAC-I的PDCP PDU。RRC重配置消息包括指示UE 102要针对DRB或PDU会话启用完整性保护的信息元素。基站104-1向UE 102传输940PDCP PDU。
在图9A和9B的示例场景中，5GC 110然后向基站104-1传输950用于DRB的另一数据分组(例如，与层154相关的数据)。基站104-1的PDCP控制器162然后生成包含数据分组和长MAC-I的PDCP PDU。例如，数据分组可以是IP分组。在某些实现方式和/或场景中，PDCP控制器162可以使用由安全模式命令消息的字段指示的相同完整性保护算法以及可能还有与该算法相关联的相同密钥(例如，KRRCint密钥)来计算PDCP PDU的长MAC-I。然而，如果安全配置和/或RRC重配置消息指示用于完整性保护的不同算法，则PDCP控制器162可以使用该算法(例如，以及KRRCint密钥)。基站104-1然后通过DRB传输952包含数据分组和长MAC-I的PDCPPDU，并且UE 102验证954PDCP PDU的长MAC-I(即，通过计算长XMAC-I并与接收到的长MAC-I进行比较)。在一些实施例和/或场景中，UE 102和基站104-1可以替代地为DRB生成SDAPPDU(例如，如上面结合图3A和3B所讨论的)。
在UE 102验证942长MAC-I之后，UE 102针对DRB或PDU会话启用完整性保护。UE102的PDCP控制器122然后可以生成包含数据分组和长MAC-I的PDCP PDU。UE 102通过DRB(即，针对其配置UE 102的特定DRB，或与针对其配置UE 102的PDU会话相关联的DRB)向基站104-1传输944PDCP PDU，并且基站104-1针对数据分组验证946长MAC-I。基站104-1然后可以向5GC 110传输948数据分组。
对于上面结合图2A-9B讨论的实现方式和/或场景中的一个或多个，如果基站104-1在安全模式命令消息或RRC重配置消息中配置UE 102为使用长MAC-I格式，则基站104-1可以在安全模式命令消息或RRC重配置消息中配置UE 102为针对SRB或DRB重建PDCP。例如，在基站104-1向UE 102传输安全模式命令消息或RRC重配置消息之后，UE 102可以通过重建SRB或DRB的PDCP实体来进行响应。如在本公开中使用的，“PDCP实体”是指负责特定上下文的PDCP通信的任务、线程或应用。基站104-1可以响应于配置UE 102重建SRB的PDCP实体而重建SRB或DRB的PDCP实体。在重建PDCP实体之后，UE 102和基站104-1可以开始使用长MAC-I格式。在一些实现方式中，UE 102和基站104-1响应于重建PDCP实体而将PDCP实体的PDCP状态变量重置为初始值。
在其他实现方式和/或场景中，在配置UE 102使用长MAC-I格式的相同安全模式命令消息或RRC重配置消息中，基站104-1可以配置UE 102针对SRB或DRB不重建PDCP。在这种情况下，UE 102响应于安全模式命令消息或RRC重配置消息不重建SRB或DRB的PDCP实体，并且基站104-1不重建SRB或DRB的PDCP实体。当向基站104-1传输安全模式完成消息或RRC重配置完成消息时，UE 102可以开始使用长MAC-I格式。当从UE 102接收到安全模式完成消息或RRC重配置完成消息时，基站104-1可以开始使用长MAC-I格式。在一些实现方式中，如果不重建PDCP实体，则UE 102和基站104-1不将PDCP实体的PDCP状态变量重置为初始值。
在一些实现方式和/或场景中，在基站104-1将UE 102配置为针对会话使用长MAC-I格式(例如，如上所述)之后，不允许基站104-1重配置UE 102为在该会话期间使用短MAC-I格式。
现在参考图10，用于增强完整性保护的示例方法1000可以在支持多个MAC长度的用户设备(诸如，例如图1的UE 102)中实现。
在方法1000的框1002处，用户设备从基站(例如，图1的基站104-1)接收包括信息元素的第一消息。例如，第一消息可以包括RRC消息(例如，RRC重配置消息)或安全模式命令消息，其中包含信息元素。作为更具体的示例，第一消息可以与图2A的传输226、图3A的传输326、图4A的传输426、图7A的传输722、图8A的传输822或图9A的传输922相关联。
在框1004处，用户设备基于信息元素确定多个MAC长度(例如，两个MAC长度，或三个MAC长度等)中的第一MAC长度(例如，64位、128位、256位或另一合适的长度)将被用于完整性保护。用户设备可以在框1004处仅针对用户平面消息、仅针对控制平面消息或针对用户平面消息和控制平面消息两者做出确定。在以上示例中，用户设备在框230(图2A)、框330(图3B)、框430(图4B)、框724(图7A)、框824(图8A)、或框924(图9A)处做出该确定。
在框1006处，在框1004处做出确定之后，用户设备生成包括具有第一MAC长度的MAC的第二消息。例如，MAC可以是MAC-I(即，接入层MAC)。例如，框1006可以包括计算MAC(例如，使用上面讨论的任何类型的完整性保护算法)并且将MAC附加到第二消息中的有效载荷。例如，除了MAC之外，第二消息可以包括RRC消息(例如，RRC重配置完成消息)。
在框1008处，用户设备向基站传输第二消息，例如，图2B的传输232、图3B的传输332、图4B的传输432、图7A的传输726、图8A的传输826，或图9A的传输926。如果框1004处的确定是针对(至少)用户平面消息，则框1004可以包括生成数据分组，并且框1006可以包括通过DRB传输第二消息(具有数据分组和MAC)。
在一些实施方式和/或场景中，方法1000包括图10中未示出的一个或多个附加框。例如，方法1000可以包括在框1002之后发生的附加框，其中用户设备计算具有多个MAC长度中的第二MAC长度(例如，32位，或另一合适的长度)的预期MAC，并将预期MAC与第一消息中的MAC进行比较以验证第一消息中的MAC是有效MAC。例如，用户设备可以使用以上讨论的任何类型的完整性保护算法来计算预期MAC。例如，第二MAC长度可以比第一MAC长度短。
作为另一示例，在框1004处的确定是针对用户平面消息的实现方式和/或场景中，方法1000可以包括其中用户设备生成包括RRC消息(例如，RRC重配置完成消息)和具有第二MAC长度的MAC的第三消息以及其中用户设备向基站传输第三消息(例如，图3B的传输332)的附加框。
作为另一示例，在框1004处的确定是针对用户平面消息和控制平面消息两者的实现方式和/或场景中，方法1000可以包括其中用户设备生成包括RRC消息(例如，RRC重配置完成消息)和具有第一MAC长度的MAC的第三消息，以及其中用户设备向基站传输第三消息(例如图2B的传输232、图4B的传输432、或图7B的传输736)的附加框。
作为另一示例，在框1004处的确定是针对控制平面消息的实现方式和/或场景中，方法1000可以包括如下附加框，其中(1)用户设备接收包括包含另一信息元素的第二RRC消息(例如，RRC重配置消息)和具有第一MAC长度的MAC两者的第三消息；(2)用户设备(例如，使用上面讨论的任何类型的完整性保护算法)计算具有第一MAC长度的预期MAC；(3)将预期MAC与接收到的MAC进行比较以验证接收到的MAC有效；(4)基于第二RRC消息中的信息元素，确定要针对用户平面消息启用完整性保护；以及(5)向基站传输附加消息。例如，用户设备可以生成图8B的传输832。
在一些实现方式和/或场景中，用户设备在框1002处接收第一消息之前，从基站(例如，图5的传输504)接收请求用户设备的能力的消息(例如，RRC UE能力查询消息)，并且作为响应向基站传输包括指示用户设备支持第一MAC长度的信息元素的消息(例如，RRC UE能力信息消息)，例如图5的传输506。
图11描绘了可以在支持多个MAC长度的基站(诸如，例如图1的基站104-1)中实现的用于增强完整性保护的示例方法1100。例如，基站可以实现方法1100，而用户设备(例如，图1的UE 102)实现方法1000。
在方法1100的框1102处，基站确定多个MAC长度(例如，两个MAC长度，或三个MAC长度等)中的第一MAC长度(例如，64位、128位、256位或另一合适的长度)将被用于完整性保护。该确定的示例包括图2A的框224、图3A的框324、图4A的框424、图6的框620、图7的框720、图8A的框820和图9A的框920。例如，框1102可以包括向用户设备传输请求用户设备的能力的消息(例如，RRC UE能力查询消息)，并且作为响应从用户设备接收包括指示用户设备支持第一MAC长度的信息元素的消息(例如，RRC UE能力信息消息)。作为更具体的示例，该消息可以与图5的传输504相关联。可替代地，框1102可以包括从核心网络(例如，从5GC 110)接收用户设备支持第一MAC长度的指示，或使用(即，配置为)第一MAC长度的命令(例如，图6的传输616、图7A的传输716、图8A的传输816或图9A的传输916)。
在框1104处，基站生成包括指示第一MAC长度将被用于完整性保护的信息元素的第一消息。框1104可以包括计算具有多个MAC长度中的第二MAC长度(例如，短于第一MAC长度)的MAC，并且将该MAC附加到第一消息中的有效载荷。例如，基站可以使用上面讨论的任何类型的完整性保护算法来计算MAC。
在框1106处，基站向用户设备(例如，UE 102)传输第一消息。例如，第一消息可以包括RRC消息(例如，RRC重配置消息)或安全模式命令消息，并且可能还有具有第二(例如，较短)MAC长度的MAC。例如，该消息可以与图2A的传输226、图3A的传输326、图4A的传输426、图7A的传输722、图8A的传输822或图9A的传输922相关联。
在框1108处，在框1106处传输第一消息之后，基站从用户设备接收包括MAC的第二消息(例如，由基站对图2B的传输232，图3B的传输332、图4B的传输432、图7A的传输726、图8A的传输826或图9A的传输926的接收)。例如，MAC可以是MAC-I(即，接入层MAC)。在框1110处，基站(例如，使用上面讨论的任何类型的完整性保护算法)计算具有第一MAC长度的预期MAC。例如，预期MAC可以是XMAC-I(即，接入层XMAC)。在框1112处，基站将预期MAC与第二消息中的MAC进行比较以验证第二消息中的MAC是有效MAC(例如，图2B的验证234、图3B的验证334、图4B的验证434、图7A的验证730、图8A的验证830或图9A的验证930)。
以下附加考虑适用于前述讨论。
其中可以实现本公开的技术的用户设备(例如，UE 102)可以是能够进行无线通信的任何合适的设备，诸如智能电话、平板计算机、膝上型计算机、移动游戏控制台、销售点(POS)终端、健康监测设备、无人机、相机、流媒体加密狗或另一人媒体设备、诸如智能手表的可穿戴设备、无线热点、毫微微小区或宽带路由器。此外，在某些情况下，用户设备可以嵌入在电子***中，诸如车辆的头部单元或高级驾驶员辅助***(ADAS)。更进一步，用户设备可以作为物联网(IoT)设备或移动互联网设备(MID)操作。取决于类型，用户设备可以包括一个或多个通用处理器、计算机可读存储器、用户接口、一个或多个网络接口、一个或多个传感器等。
在本公开中将某些实现方式描述为包括逻辑或多个组件或模块。模块可以是软件模块(例如，存储在非暂时性机器可读介质上的代码)或硬件模块。硬件模块是能够执行某些操作的有形单元，并且可以以某种方式配置或布置。硬件模块可以包括永久配置以执行某些操作的专用电路或逻辑(例如，作为专用处理器，诸如现场可编程门阵列(FPGA)或专用集成电路(ASIC))。硬件模块还可以包括由软件临时配置以执行某些操作的可编程逻辑或电路(例如，包含在通用处理器或其他可编程处理器内)。在专用且永久配置的电路中或在临时配置的电路(例如，由软件配置)中实现硬件模块的决定可能由成本和时间考虑驱动。
当以软件实现时，该技术可以作为操作***的一部分、由多个应用使用的库、特定软件应用等提供。该软件可以由一个或多个通用处理器或一个或多个专用处理器运行。
在阅读本公开后，本领域技术人员将通过本文公开的原理理解用于在通常支持不同长度的消息认证码的无线通信网络中提供完整性保护的另外的替代结构和功能设计。因此，虽然已经图示和描述了特定的实现方式和应用，但是应当理解所公开的实现方式不限于本文公开的精确构造和组件。在不脱离所附权利要求中限定的精神和范围的情况下，可以对本文公开的方法和装置的布置、操作和细节进行对本领域普通技术人员而言显而易见的各种修改、改变和变化。

Claims (27)

1.一种支持用于无线通信的完整性保护的多个消息认证码(MAC)长度的用户设备中的方法，该方法包括：
由处理硬件从基站接收包括信息元素的第一消息；
由处理硬件基于信息元素确定多个MAC长度中的第一MAC长度将被用于完整性保护；
在确定第一MAC长度将被用于完整性保护之后，由处理硬件生成包括具有第一MAC长度的MAC的第二消息；以及
向基站传输第二消息。
2.如权利要求1所述的方法，还包括，在接收到第一消息之后：
由处理硬件计算具有多个MAC长度中的第二MAC长度的预期MAC；以及
由处理硬件将预期MAC与第一消息中的MAC进行比较，以验证第一消息中的MAC是有效MAC，
其中，生成第二消息包括：
计算具有第一MAC长度的MAC，以及
将具有第一MAC长度的MAC附加到第二消息中的有效载荷。
3.如权利要求1所述的方法，其中，接收第一消息包括接收无线电资源控制(RRC)消息。
4.如权利要求3所述的方法，其中：
RRC消息为第一RRC消息；以及
生成第二消息包括生成第二RRC消息。
5.如权利要求4所述的方法，其中：
接收第一RRC消息包括接收RRC重配置消息；以及
生成第二RRC消息包括生成RRC重配置完成消息。
6.如权利要求3所述的方法，其中：
RRC消息为第一RRC消息；
确定第一MAC长度将被用于完整性保护包括确定第一MAC长度将被用于用户平面消息；
生成第二消息包括生成数据分组；
向基站传输第二消息包括通过数据无线电承载(DRB)传输第二消息；以及
该方法还包括：
由处理硬件生成包括第二RRC消息和具有多个MAC长度中的第二MAC长度的附加MAC的第三消息，以及
向基站传输第三消息。
7.如权利要求3所述的方法，其中：
RRC消息为第一RRC消息；
确定第一MAC长度将被用于完整性保护包括确定第一MAC长度将被用于用户平面消息和控制平面消息两者；
生成第二消息包括生成数据分组；
向基站传输第二消息包括通过数据无线电承载(DRB)传输第二消息；以及
该方法还包括：
由处理硬件生成包括第二RRC消息和具有第一MAC长度的附加MAC的第三消息，以及
向基站传输第三消息。
8.如权利要求1所述的方法，其中：
接收第一消息包括接收安全模式命令消息；
确定第一MAC长度将被用于完整性保护包括确定第一MAC长度将被用于控制平面消息；
生成第二消息包括生成第一无线电资源控制(RRC)消息；以及
该方法还包括
由处理硬件接收包括(i)包含另一信息元素的第二RRC消息和(ii)具有第一MAC长度的第一MAC的第三消息，
由处理硬件计算具有第一MAC长度的预期MAC，
由处理硬件将预期MAC与第一MAC进行比较，以验证第一MAC是有效MAC，
由处理硬件基于所述另一信息元素确定针对用户平面消息启用完整性保护，
由处理硬件生成包括数据分组和具有第一MAC长度的第二MAC
的第四消息；以及
向基站传输第四消息。
9.如权利要求1所述的方法，还包括，在接收所述第一消息之前：
由处理硬件从基站接收请求用户设备的能力的消息；以及
响应于请求用户设备的能力的消息，向基站传输包括指示用户设备支持第一MAC长度的信息元素的消息。
10.一种非暂时性介质，其上存储有指令，当由支持用于无线通信的完整性保护的多个消息认证码(MAC)长度的用户设备的处理硬件执行所述指令时，使用户设备执行权利要求1至9中任一项所述的方法。
11.一种支持用于无线通信的完整性保护的多个消息认证码(MAC)长度的基站中的方法，该方法包括：
由处理硬件确定多个MAC长度中的第一MAC长度将被用于完整性保护；
由处理硬件生成包括指示第一MAC长度将被用于完整性保护的信息元素的第一消息；
向用户设备传输第一消息；
在传输第一消息之后，由处理硬件从用户设备接收包括MAC的第二消息；
由处理硬件计算具有第一MAC长度的预期MAC；以及
由处理硬件将预期MAC与第二消息中的MAC进行比较，以验证第二消息中的MAC是有效MAC。
12.如权利要求11所述的方法，其中，生成所述第一消息包括：
计算具有多个MAC长度中的第二MAC长度的附加MAC，第二MAC长度小于第一MAC长度；以及
将附加MAC附加到第一消息中的有效负载。
13.如权利要求11所述的方法，其中，确定第一MAC长度将被用于完整性保护包括：
向用户设备传输请求用户设备的能力的消息；以及
响应于请求用户设备的能力的消息，从用户设备接收包括指示用户设备支持第一MAC长度的信息元素的消息。
14.如权利要求11所述的方法，其中，确定第一MAC长度将被用于完整性保护包括：
从核心网络接收(i)用户设备支持第一MAC长度的指示，或(ii)使用第一MAC长度的命令。
15.如权利要求11所述的方法，其中，生成第一消息包括生成无线电资源控制(RRC)消息。
16.如权利要求15所述的方法，其中：
RRC消息为第一RRC消息；以及
接收第二消息包括接收第二RRC消息。
17.如权利要求16所述的方法，其中：
生成第一RRC消息包括生成RRC重配置消息；以及
接收第二RRC消息包括接收RRC重配置完成消息。
18.如权利要求15所述的方法，其中：
RRC消息为第一RRC消息；
确定第一MAC长度将被用于完整性保护包括确定第一MAC长度将被用于用户平面消息；
接收第二消息包括通过数据无线电承载(DRB)接收包括数据分组的消息；以及
该方法还包括由处理硬件从用户设备接收包括第二RRC消息和具有多个MAC长度中的第二MAC长度的附加MAC的第三消息。
19.如权利要求15所述的方法，其中：
RRC消息为第一RRC消息；
确定第一MAC长度将被用于完整性保护包括确定第一MAC长度将被用于用户平面消息和控制平面消息两者；
接收第二消息包括通过数据无线电承载(DRB)接收包括数据分组的消息；以及
该方法还包括由处理硬件从用户设备接收包括第二RRC消息和具有第一MAC长度的附加MAC的第三消息。
20.如权利要求11所述的方法，其中：
生成第一消息包括生成安全模式命令消息；
确定第一MAC长度将被用于完整性保护包括确定第一MAC长度将被用于控制平面消息；
接收第二消息包括接收第一无线电资源控制(RRC)消息；以及
该方法还包括：
由处理硬件生成包括(i)包含另一信息元素的第二RRC消息和(ii)具有第一MAC长度的第一MAC的第三消息，
向用户设备传输第三消息，以及
由处理硬件从用户设备接收包括数据分组和具有第一MAC长度的第二MAC的第四消息。
21.一种非暂时性介质，其上存储有指令，当由支持用于无线通信的完整性保护的多个消息认证码(MAC)长度的基站的处理硬件执行所述指令时，使基站执行权利要求11至20中任一项所述的方法。
22.一种在一个或多个核心网络元件中的方法，该方法包括：
由处理硬件从第一基站或第二基站接收包括第一信息元素的第一消息；
由处理硬件基于第一信息元素确定用户设备支持由第一基站支持的多个消息认证码(MAC)长度中的第一MAC长度用于完整性保护；
由处理硬件生成包括指示第一MAC长度将被用于第一基站和用户设备之间的无线通信的完整性保护的第二信息元素的第二消息；以及
向第一基站传输第二消息以配置第一基站使用第一MAC长度用于与用户设备的无线通信。
23.如权利要求22所述的方法，其中，生成所述第二消息包括生成下一代应用协议(NGAP)消息。
24.如权利要求22所述的方法，其中，生成所述第二消息包括生成初始上下文设立请求消息。
25.如权利要求22所述的方法，其中：
第二信息元素指示第一MAC长度将被用于数据无线电承载(DRB)上或协议数据单元(PDU)会话期间的无线通信的完整性保护；以及
向第一基站传输第二消息用于将第一基站配置为将第一MAC长度用于DRB上或在PDU会话期间与用户设备的无线通信。
26.如权利要求25所述的方法，还包括，在生成所述第二消息之前：
由处理硬件生成包括指示第一MAC长度将被用于一个或多个信令无线电承载(SRB)上的无线通信的完整性保护的第三信息元素的第三消息；以及
向第一基站传输第三消息以将第一基站配置为将第一MAC长度用于一个或多个SRB上与用户设备的无线通信。
27.一种非暂时性介质，其上存储有指令，当由一个或多个核心网络元件的处理硬件执行所述指令时，使所述一个或多个核心网络元件执行权利要求22至26中任一项所述的方法。
CN201980090627.1A 2019-01-29 2019-12-30 用具有不同长度的消息认证码的完整性保护 Pending CN113366800A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962798007P 2019-01-29 2019-01-29
US62/798,007 2019-01-29
PCT/US2019/068884 WO2020159654A1 (en) 2019-01-29 2019-12-30 Integrity protection with message authentication codes having different lengths

Publications (1)

Publication Number Publication Date
CN113366800A true CN113366800A (zh) 2021-09-07

Family

ID=69374394

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980090627.1A Pending CN113366800A (zh) 2019-01-29 2019-12-30 用具有不同长度的消息认证码的完整性保护

Country Status (4)

Country Link
US (1) US11917410B2 (zh)
EP (1) EP3903444A1 (zh)
CN (1) CN113366800A (zh)
WO (1) WO2020159654A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3903444A1 (en) * 2019-01-29 2021-11-03 Google LLC Integrity protection with message authentication codes having different lengths
US11425771B2 (en) * 2019-11-27 2022-08-23 At&T Intellectual Property I, L.P. Medium access control interface to coordinate multi-site operation for 5G or other next generation wireless network

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101199184A (zh) * 2005-06-28 2008-06-11 英特尔公司 提供认证码的方法和装置
CN101753308A (zh) * 2009-12-22 2010-06-23 中国科学院软件研究所 一种完整性认证方法
CN101904213A (zh) * 2007-12-19 2010-12-01 高通股份有限公司 用于在无线通信网络中在公共控制信道上传送消息以进行随机接入的方法和装置
CN106922217A (zh) * 2014-11-20 2017-07-04 华为技术有限公司 无线通信网络中的方法和节点
CN109246705A (zh) * 2017-06-15 2019-01-18 维沃移动通信有限公司 一种数据无线承载完整性保护配置方法、终端及网络设备

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI20002453A (fi) 2000-11-08 2002-05-09 Nokia Corp Adaptiivinen sanoman autentikointikoodi
US8493854B2 (en) * 2006-02-07 2013-07-23 Lg Electronics Inc. Method for avoiding collision using identifier in mobile network
US8277894B2 (en) 2009-07-16 2012-10-02 Rohm And Haas Electronic Materials Llc Selenium ink and methods of making and using same
CN101998561B (zh) 2009-08-17 2014-10-22 中兴通讯股份有限公司 长期演进网络中终端切换时的定位处理方法及***
KR101831448B1 (ko) 2010-02-02 2018-02-26 엘지전자 주식회사 이동 통신 시스템에서 ｐｄｃｐ 기능을 선택적으로 적용하는 방법
US8982792B2 (en) * 2011-08-15 2015-03-17 Marvell World Trade Ltd. Long range WLAN data unit format
CN106255907B (zh) 2014-03-25 2020-01-24 Nkt光子学有限公司 微结构光纤和超连续谱光源
WO2018182482A1 (en) * 2017-03-31 2018-10-04 Telefonaktiebolaget Lm Ericsson (Publ) A network node, a communications device and methods therein for secure paging
CN110493774B (zh) 2017-05-06 2023-09-26 华为技术有限公司 密钥配置方法、装置以及***
US10080098B1 (en) 2017-10-25 2018-09-18 Qualcomm Incorporated Systems and methods for uplink high efficiency transport of location information in a wireless network
CN109890076B (zh) * 2017-12-06 2023-01-06 华为技术有限公司 一种非授权频谱上的数据传输方法、设备和存储介质
WO2019109945A1 (zh) * 2017-12-06 2019-06-13 华为技术有限公司 一种非授权频谱上的数据传输方法、设备和存储介质
CN110881216A (zh) 2018-09-05 2020-03-13 电信科学技术研究院有限公司 一种定位消息的传输处理方法、设备及终端
EP3903444A1 (en) * 2019-01-29 2021-11-03 Google LLC Integrity protection with message authentication codes having different lengths

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101199184A (zh) * 2005-06-28 2008-06-11 英特尔公司 提供认证码的方法和装置
CN101904213A (zh) * 2007-12-19 2010-12-01 高通股份有限公司 用于在无线通信网络中在公共控制信道上传送消息以进行随机接入的方法和装置
CN101753308A (zh) * 2009-12-22 2010-06-23 中国科学院软件研究所 一种完整性认证方法
CN106922217A (zh) * 2014-11-20 2017-07-04 华为技术有限公司 无线通信网络中的方法和节点
US20170257762A1 (en) * 2014-11-20 2017-09-07 Huawei Technologies Co., Ltd. Methods and nodes in a wireless communication network
CN109246705A (zh) * 2017-06-15 2019-01-18 维沃移动通信有限公司 一种数据无线承载完整性保护配置方法、终端及网络设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
汪青山;傅海阳;: "TD-SCDMA***无线链路域安全机制", 电信快报, no. 11 *

Also Published As

Publication number Publication date
US20220070670A1 (en) 2022-03-03
WO2020159654A1 (en) 2020-08-06
EP3903444A1 (en) 2021-11-03
US11917410B2 (en) 2024-02-27

Similar Documents

Publication Publication Date Title
CN110073714B (zh) 用于由于无线电链路故障而重建无线电通信链路的方法及设备
CN109691159B (zh) Rrc连接恢复中的pdcp count处理
US20220264684A1 (en) Communication of Segmented Radio Resource Control Messages
EP3777066B1 (en) Pdu session for encrypted traffic detection
US11917410B2 (en) Integrity protection with message authentication codes having different lengths
EP3654579A1 (en) Methods and devices for providing message authentication code suitable for short messages
US10492056B2 (en) Enhanced mobile subscriber privacy in telecommunications networks
US20220345883A1 (en) Security key updates in dual connectivity
US10278068B2 (en) Device and method of handling cellular-wireless local area network aggregation
US10812980B2 (en) Communication method, security node network element, and terminal
US20230156820A1 (en) Data Communication In An Inactive State
US10455472B2 (en) Device and method of handling data transmissions in a wireless communication system
US20220038904A1 (en) Wireless-network attack detection
EP3881490B1 (en) Methods and devices for providing message authentication code suitable for short messages
US20220141914A1 (en) Resuming radio connections in a communication network
WO2020146661A1 (en) Integrity protection for user plane edt with multiple pdcp pdus
US20240147568A1 (en) Managing early data communication
US20240237142A1 (en) Early data communication with configured resources
EP3506699B1 (en) Data transmission methods, radio access network device and mobile terminal for configuring a preset data bearer

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