WO2020146661A1

WO2020146661A1 - Integrity protection for user plane edt with multiple pdcp pdus

Info

Publication number: WO2020146661A1
Application number: PCT/US2020/012969
Authority: WO
Inventors: Mazin Al-Shalash; Ahmad Muhanna
Original assignee: Futurewei Technologies, Inc.
Priority date: 2019-01-09
Filing date: 2020-01-09
Publication date: 2020-07-16

Abstract

A method for data integrity protection during resumption of a suspended data connection, where the method includes : calculating, by a user equipment (UE), a first hash value based upon a first data protocol data unit (PDU); calculating, by the UE, a second hash value based upon a second data PDU; calculating, by the UE, a message authentication code (MAC) based upon a portion of the first hash value and a portion of the second hash value; and transmitting, by the UE to a base station, a medium access control PDU comprising the first data PDU, the second data PDU, and a connection resume request comprising a portion of the MAC.

Description

Integrity Protection for User Plane EDT with Multiple PDCP PDUs

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a continuation of U.S. Provisional Patent Application No. 62/790,371, filed on January 9, 2019, which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

[0002] Embodiments of the present disclosure relate to the communications field, and in particular, to a data processing method, a data transmit end, and a data receive end.

BACKGROUND

[0003] Radio resource control (RRC) suspend/resume procedures are used to improve the power efficiency of long-term evolution (LTE) Cellular Internet of Things (CioT) devices. By utilizing the RRC suspend procedure, an evolved NodeB (eNB) requests a user equipment (UE) to retain its access stratum (AS) context and configuration when transitioning to an RRC IDLE state. Subsequently, the UE’s RRC connection can be quickly resumed, with minimal signaling overhead, thereby reducing both the latency of resuming the RRC CONNECTED state and the power consumed by the UE during the transition. FIGS. 1 and 2 illustrate message flows for RRC suspend and resume procedures 100, 200, respectively, according to the 3 Generation Partnership Project) (3GPP) Technical Specification (TS) 36.300.

[0004] An RRC connection suspend procedure 100 allows the eNB 102 to suspend an RRC connection, which the UE 104 may resume at a future time via the same eNB 102 or a different eNB. As shown in in FIG. 1, if the eNB 102 decides to suspend the RRC connection 106, the eNB 102 may send a UE Context Suspend Request 108 to a mobile management entity (MME) 110, which may then exchange signaling with a serving gateway (S-GW) 112 to release access bearers 114 for the RRC connection. Upon receiving a UE context Suspend Response 116 from the MME 110, the eNB 102 sends the UE 104 an RRC Connection Release message 118, which may include a Next Hop (NH) Chaining Counter (NCC) used for NH access key derivation. The RRC Connection Release message 118 may also include a resume identifier (resume ID) to be used for context identification and re-establishment. The resume identifier refers to an identity assigned to the UE 104 in the cell where the UE 104 was suspended (i.e., the source cell). The eNB 102 and UE 104 may each store the resume identifier together with the UE context including the AS security context.

[0005] If the UE 104 later decides to resume the RRC connection, the UE 104 can initiate the RRC connection resume procedure 200 in FIG. 2. When the RRC connection resume procedure 200 has been initiated, the UE 104 and eNB 102 may exchange a random access preamble 202 and response 204 according to a random access channel (RACH) procedure. As shown in step 1 of FIG. 2, the UE 104 may then send the eNB 102 an RRC Connection Resume Request message 206 (also known as Message 3 or MSG3 of the RACH procedure). The RRC Connection Resume Request message 206 generally includes information to be used for context identification and re-establishment in the RRC Connection Resume Request message, e.g., a resume identifier and a Short Resume message authentication code (MAC) for integrity (MAC-I) parameter (shortResumeMAC-I). The ShortResumeMAC-I is a message authentication token calculated using a stored RRC integrity key (K_RRCint) that was used with the source eNB where the UE 104 was suspended, as well as using the following inputs: a source cell radio network temporary identifier (C-RNTI), a source physical cell identity (PCI), a resume constant, and a target Cell-ID as defined by an Abstract Syntax Notation One (ASN.l) encoded UE parameter, VarShortResumeMAC-Input, in TS 36.331. The resume constant allows differentiation of VarShortResumeMAC from VarShortMAC. The VarShortResumeMAC-Input field descriptions are described below in Table 1.

Table 1

[0006] In Table 1, the c-RNTI parameter is used to identify a radio channel previously assigned to the UE 104 by the cell where the RRC connection was suspended. The physCellld parameter identifies a physical cell to which the UE 104 was connected when an RRC connection was suspended, whereas the cellldentity parameter identifies the cell currently serving the UE 104 (e.g., a target cell where the UE 104 sends the RRC Connection Resume Request message). The latter may be different from the cell where the RRC connection was suspended, e.g., if the UE 104 invokes the RRC resume procedure after being reselected to a different cell (typically due to UE mobility). In this case, the target eNB may extract the resume ID and ShortResumeMAC-I from the RRC Connection Resume Request 206. The target eNB then contacts the source eNB based on information in the resume ID by sending the source eNB a Retrieve UE Context Request message on an X2 interface including the resume ID, the ShortResumeMAC-I, and the cell-ID of the target cell in order to retrieve the UE context including the AS security context.

[0007] The shortResumeMAC-I may be used as an authentication token, such that the eNB can authenticate the UE 104 and resume its previous AS security context without the need for re- authenticating the UE 104 by the network. Re-keying is not necessary for an RRC connection resume procedure, as re-keying is typically initiated when an AS security context differs from the currently active security context. The shortResumeMAC-I comprises the 16 least significant bits of the MAC-I, where an integrity protection algorithm previously configured to the UE 104 and a previously used integrity key (e.g., a 128-bit K_RRCint used before the suspend) are used to calculate the MAC-I over the VarShortResumeMAC-Input parameter.

[0008] In 3GPP Release 15 (Rel. 15), Early Data Transmission (EDT) is being introduced. EDT enables the UE to transmit small amounts of user plane data to the network on the uplink using two approaches: (1) without first requesting to resume the RRC connection (i.e., via Control Plane EDT); or (2) in parallel with an RRC Connection Resume Request (i.e., via User Plane (UP) EDT). EDT enables communication of uplink (UL) user plane data with minimal power consumption and latency (e.g., without first completing all the signaling steps needed to resume the RRC connection).

[0009] FIG. 3 illustrates an example of a message flow for the UP-EDT procedure 300 according to other approaches. This example is based on a case where a UE 104 attempts an RRC Connection Resume procedure to a cell served by the same eNB 102 (e.g., a source eNB) where the UE’s prior RRC connection was suspended. In a case where the UE attempts to resume the procedure with a different eNB (e.g., a new target eNB), the new eNB may retrieve the UE’s context from the old source eNB (i.e., before the UE’s context can be resumed with the core network) by invoking an X2-Application Protocol (X2-AP) Retrieve UE Context procedure as mentioned above. [0010] When the UE 104 decides to re-establish an RRC connection, the UE 104 may send the target eNB an RRC Connection Resume Request message 302, which may include a resume ID, resume cause parameter, and shortResumeMAC-I. For example, the UE 104 may send the RRC Connection Resume Request message 302 if the UE 104 has uplink (UL) data to send, in which case the UL data may be sent together with the RRC Connection Resume Request message 302, as shown in step 1 of FIG. 3. Upon receiving the RRC Connection Resume Request message 302, the target eNB 102 sends the MME 110 a UE Context Resume Request 304 to inform the MME 110 that the UE 104 wants to resume the RRC connection. As such, the MME 110 may exchange signaling 306 with the S-GW 112 to reactivate bearers for the RRC connection and return a UE Context Resume Response 308 to the target eNB 102, which may then send the UE’s uplink data to the S-GW 112. If the S-GW 112 has downlink data to be transmitted to the UE 104, the S-GW 112 may send the downlink data to the target eNB 102 as shown in step 6 of FIG. 3. If the target eNB 102 decides to suspend the RRC connection, the target eNB 102 may send the UE 104 an RRC Connection Release message 310, which may include a release cause parameter, a resume ID, NCC, as well as the downlink data from the S- GW.

SUMMARY

[0011] A first aspect relates to a method for data integrity protection during resumption of a suspended data connection. The method includes calculating, by a user equipment (UE), a first hash value based upon a first data protocol data unit (PDU); calculating, by the UE, a second hash value based upon a second data PDU; calculating, by the UE, a message authentication code (MAC) based upon a portion of the first hash value and a portion of the second hash value; and transmitting, by the UE to a base station, a medium access control PDU comprising the first data PDU, the second data PDU, and a connection resume request comprising a portion of the MAC.

[0012] The method provides integrity protection for user-plane EDT in data transmissions of two or more PDCP PDUs. To this end, the method proposes extending the derivation of an integrity authentication parameter carried in a RRC Connection Resume Request. In some aspects, integrity protection is provided by calculating different HASH values for each PDCP PDU and using the different HASH values as input for calculating the integrity authentication parameter. In other aspects, multiple HASH values produced from PDCP PDUs are combined into a single HASH data field to be used as input for deriving the integrity authentication parameter, thereby minimizing coordination between the medium access control layer and reducing the size of the RRC Connection Resume Request (e.g., as compared to aspects where multiple HASH data fields are used as input).

[0013] In a first implementation form of the method according to the first aspect as such, the UE calculates the MAC based upon a first hash variable comprising the portion of the first hash value and a second hash variable comprising the portion of the second hash value.

[0014] In a second implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, an ordering of the first hash variable and the second hash variable is explicitly indicated in the connection resume request.

[0015] In a third implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, an ordering of the first hash variable and the second hash variable corresponds to an order of the first data PDU and the second data PDU in the medium access control PDU.

[0016] In a fourth implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, an ordering of the first hash variable and the second hash variable corresponds to an order of channel identifiers for the first data PDU and the second data PDU in the medium access control PDU.

[0017] In a fifth implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, the UE calculates the MAC based upon a third hash variable comprising a logical function of the portion of the first hash value and the portion of the second hash value.

[0018] In a sixth implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, the logical function comprises a bitwise exclusive or (XOR) operation of the portion of the first hash value and the portion of the second hash value.

[0019] In a seventh implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, the portion of the first hash value comprises a least significant sixty-four bits of the first hash value, wherein the portion of the second hash value comprises a least significant sixty-four bits of the second hash value, and wherein the portion of the MAC comprises a least significant sixteen bits of the MAC.

[0020] In an eighth implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, the first data PDU and the second data PDU are transmitted via a first radio bearer.

[0021] In a ninth implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, the first data PDU is transmitted via a first radio bearer and the second data PDU is transmitted via a second radio bearer.

[0022] A second aspect relates to a non-transitory computer readable medium storing computer instructions executable by one or more processors to implement a method for data integrity protection during resumption of a suspended data connection. The method includes calculating, by a user equipment (UE), a first hash value based upon a first data protocol data unit (PDU); calculating, by the UE, a second hash value based upon a second data PDU; calculating, by the UE, a message authentication code (MAC) based upon a portion of the first hash value and a portion of the second hash value; and transmitting, by the UE to a base station, a medium access control PDU comprising the first data PDU, the second data PDU, and a connection resume request comprising a portion of the MAC.

[0023] The method provides integrity protection for user-plane EDT in data transmissions of two or more PDCP PDUs. To this end, the method proposes extending the derivation of an integrity authentication parameter carried in a RRC Connection Resume Request. In some aspects, integrity protection is provided by calculating different HASH values for each PDCP PDU and using the different HASH values as input for calculating the integrity authentication parameter. In other aspects, multiple HASH values produced from PDCP PDUs are combined into a single HASH data field to be used as input for deriving the integrity authentication parameter, thereby minimizing coordination between the medium access control layer and reducing the size of the RRC Connection Resume Request (e.g., as compared to aspects where multiple HASH data fields are used as input).

[0024] In a first implementation form of the method according to the second aspect as such, the UE calculates the MAC based upon a first hash variable comprising the portion of the first hash value and a second hash variable comprising the portion of the second hash value.

[0025] In a second implementation form of the method according to the second aspect as such or any preceding implementation form of the second aspect, an ordering of the first hash variable and the second hash variable is explicitly indicated in the connection resume request.

[0026] In a third implementation form of the method according to the second aspect as such or any preceding implementation form of the second aspect, an ordering of the first hash variable and the second hash variable corresponds to an order of the first data PDU and the second data PDU in the medium access control PDU.

[0027] In a fourth implementation form of the method according to the second aspect as such or any preceding implementation form of the second aspect, an ordering of the first hash variable and the second hash variable corresponds to an order of channel identifiers for the first data PDU and the second data PDU in the medium access control PDU.

[0028] In a fifth implementation form of the method according to the second aspect as such or any preceding implementation form of the second aspect, the UE calculates the MAC based upon a third hash variable comprising a logical function of the portion of the first hash value and the portion of the second hash value.

[0029] In a sixth implementation form of the method according to the second aspect as such or any preceding implementation form of the second aspect, the logical function comprises a bitwise exclusive or (XOR) operation of the portion of the first hash value and the portion of the second hash value.

[0030] In a seventh implementation form of the method according to the second aspect as such or any preceding implementation form of the second aspect, the portion of the first hash value comprises a least significant sixty-four bits of the first hash value, wherein the portion of the second hash value comprises a least significant sixty-four bits of the second hash value, and wherein the portion of the MAC comprises a least significant sixteen bits of the MAC.

[0031] In an eighth implementation form of the method according to the second aspect as such or any preceding implementation form of the second aspect, the first data PDU and the second data PDU are transmitted via a first radio bearer.

[0032] A third aspect relates to an apparatus for data integrity protection during resumption of a suspended data connection. The apparatus includes at least one processor; and a memory storing instructions executable by the at least one processor such that when executed, cause the apparatus to: calculate a first hash value based upon a first data protocol data unit (PDU); calculate a second hash value based upon a second data PDU; calculate a message authentication code (MAC) based upon a portion of the first hash value and a portion of the second hash value; and transmit a medium access control PDU to a base station, wherein the medium access control PDU comprises the first data PDU, the second data PDU, and a connection resume request comprising a portion of the MAC.

[0033] The apparatus provides integrity protection for user-plane EDT in data transmissions of two or more PDCP PDUs, by extending the derivation of an integrity authentication parameter carried in a RRC Connection Resume Request. In some aspects, integrity protection is provided by calculating different HASH values for each PDCP PDU and using the different HASH values as input for calculating the integrity authentication parameter. In other aspects, multiple HASH values produced from PDCP PDUs are combined into a single HASH data field to be used as input for deriving the integrity authentication parameter, thereby minimizing coordination between the medium access control layer and reducing the size of the RRC Connection Resume Request (e.g., as compared to aspects where multiple HASH data fields are used as input).

BRIEF DESCRIPTION OF DRAWINGS

[0034] FIG. 1 is a schematic diagram of an RRC suspend procedure according to other approaches;

[0035] FIG. 2 is a schematic diagram of an RRC resume procedure according to other approaches;

[0036] FIG. 3 is a schematic diagram of a user plane EDT procedure according to other approaches;

[0037] FIG. 4 is a schematic diagram of a UE according to an embodiment of the disclosure;

[0038] FIG. 5 is a schematic diagram of a MAC EDT variable according to an embodiment of the disclosure;

[0039] FIG. 6 is a schematic diagram of a UE according to an embodiment of the disclosure;

[0040] FIG. 7 is a schematic diagram of a UE according to an embodiment of the disclosure;

[0041] FIG. 8 is a schematic diagram of network entities according to an embodiment of the disclosure;

[0042] FIG. 9 is a schematic diagram of network entities according to an embodiment of the disclosure; [0043] FIG. 10 is a flowchart illustrating a method for providing user-plane EDT integrity protection according to an embodiment of the disclosure; and

[0044] FIG. 11 is a schematic diagram of an apparatus according to an embodiment of the present disclosure.

DESCRIPTION OF EMBODIMENTS

[0045] Disclosed herein are embodiments for providing enhancements to existing UP-EDT integrity protection approaches to address data transmissions corresponding to multiple Packet Data Convergence Protocol (PDCP) Protocol Data Units (PDUs). To this end, the present disclosure proposes extending the derivation of the shortResumeMAC-I parameter carried in the RRC Connection Resume Request to provide integrity protection for two or more PDCP PDUs. In some implementations, such integrity protection is provided by calculating different HASH values for each PDCP PDU and using the different HASH values as input for calculating the shortResumeMAC-I parameter. In other implementations, multiple HASH values produced from PDCP PDUs are combined into a single HASH data field to be used as input for deriving the shortResumeMAC-I parameter. These and other features are detailed below.

[0046] During RRC resume/suspend procedures, security functions may be implemented to provide user identity protection, authentication, and confidentiality of user data transmitted via the User Plane (UP or U-Plane) and of control signals transmitted via the Control Plane (CP or C-Plane). Non-access stratum (NAS) and RRC signaling messages are typically integrity- protected, unless one or more exceptions apply (e.g., as specified in a standard technical specification). A UE and a network entity (e.g., source eNB, target eNB, MME, etc.) may derive various keys for NAS, AS, and UP protection. Such keys may include one more of the following:

K_eNB, KuPenc, KRRCint, KRRCenc and KuPint·

[0047] A UE and network entity (e.g., eNB, MME, etc.) may derive K_eNB from an Access Security Management Entity (ASME) key (KASME) using a key derivation function (KDF). User plane encryption and integrity keys (Kup_enc and Ku_pint, respectively) are keys for protection of UP traffic, while RRC integrity and encryption keys (K_RRCint and K._RRc_cnc, respectively) are keys for protection of RRC traffic. A UE and/or network entity (e.g., eNB, MME, etc.) may derive Kup_enc, KRR_Cin_t, KRR_Cen_c, and Kupi_nt from an eNB key (K_CNB) and/or an identifier of a particular algorithm (e.g., encryption algorithm or integrity algorithm) using a KDF. Further, intermediate keys such as NH and K_eNB* may also be derived in some cases. For example, NH may be derived by a UE and MME to provide forward security, while K_eNB* may be derived by a UE and eNB when performing horizontal or vertical key derivation using a KDF.

[0048] In 3 GPP Release 15, early data transmission (EDT) has been introduced to provide a mechanism to support infrequent small data packet transmissions during random access procedures. For control plane EDT (CP-EDT), data may be integrity protected by the NAS layer. For user plane EDT (UP-EDT), data may be ciphered for protection, but such data may not be integrity protected. For example, a UE may be able to integrity protect an RRC Connection Resume Request message, but not the data that the UE seeks to transmit when initiating the RRC resume procedure (e.g.,“Uplink data” in step 1 of FIG 3). Consequently, UP-EDT data may be vulnerable to forging, tampering, and replay attacks.

[0049] To avoid such vulnerabilities, FIG 4 provides a schematic diagram of a UE 400 configured to provide integrity protection of UP-EDT data according to an embodiment of the disclosure. It should be understood that while the schematic diagram of FIG. 4 is from the perspective of the UE 400, the concepts described herein with respect to FIG. 4 are similarly applicable to network components such as an eNB (e.g., eNB 102 in FIGS. 1-3).

[0050] The UE 400 comprises an RRC processing unit 410 configured to handle RRC layer functions such as quality of service (QoS) management functions and security functions, including key management, establishment, configuration, maintenance, and release of point-to- point radio bearers, etc. The UE 400 also comprises a PDCP processing unit 420 configured to handle PDCP layer functions such as header compression and decompression, transferring user data, ciphering and deciphering, etc. For example, when receiving a PDCP service data unit (SDU) 421 comprising data (e.g., Internet Protocol (IP) packets), the PDCP processing unit 420 may perform ciphering to generate a ciphered PDCP SDU 437. The PDCP processing unit 420 may also perform header compression and add a PDCP header 426 to the PDCP SDU 421 to generate a PDCP PDU 423. The PDCP processing unit 420 may then submit the PDCP PDU 423 to the radio link control (RLC) layer as an RLC SDU 425. There, the RRC processing unit 410 may segment the RLC SDU 425 to generate an RLC PDU 427 and add a header 428 containing information (e.g., length indicator) to split the RLC PDU 427 into original packets at the receiver side. After performing segmentation, the RRC processing unit 410 may submit the RLC PDU 427 to a medium access layer as a MAC SDUi 429, which may comprise a portion of a MAC PDU such as a Message 3 MAC PDU 412 to be transmitted via a physical layer.

[0051] For discussion purposes, assume that“Message 3 MAC PDU” 412 is an RRC Connection Resume Request message (e.g., as shown in step 1 of FIG. 3) sent from the UE 400 after an eNB previously (e.g., source eNB) suspended an RRC Connection belonging to the UE 400. Further assume that prior to sending this resume message, the UE 400 initiates EDT by sending a random access preamble configured for EDT (e.g., via system information) to a target eNB (e.g., eNB 102 in FIGS. 1-3), and then the UE 400 receives a random access response from the target eNB. The random access response may include a grant with an appropriate transport block size (TBS) for EDT. Upon receiving this response, the RRC processing unit 410 may generate and send the RRC Connection Resume Request message 412 to the target eNB.

[0052] The RRC Connection Resume Request message 412 may generally comprise multiple medium access control sub-headers corresponding to multiple medium access control SDUs, which may comprise segments of data from an upper layer (e.g., RRC layer) as described above. Additionally, the RRC Connection Resume Request message 412 may comprise one sub-header for each MAC control element (CE), each MAC SDU (e.g., MAC SDUo and MAC SDUo), and/or padding (optional). Further, the RRC Connection Resume Request message 412 may be transmitted on a common control channel (CCCH) via a signaling radio bearer (SRB) such as SRBO, while uplink data may be transmitted via a data radio bearer (DRB).

[0053] As shown in block 415, the RRC Connection Resume Request message 412 may include a resume identity parameter, a shortResumeMAC-I 416, and a resume cause parameter. The RRC processing unit 410 may calculate the ShortResumeMAC-I 416 using an integrity protection algorithm 417, which may have been previously negotiated between the UE 400 and source eNB where the RRC connection was suspended. For example, the integrity protection algorithm 417 may comprise an EPS integrity algorithm (EIA) based on AS security context stored by the source eNB. Additionally, an input to the integrity protection algorithm 417 includes a stored RRC integrity key (K_RRCint) 440 that was previously used (e.g., for RRC confidentiality and integrity protection) between the UE 400 and the source eNB. As shown in FIG. 4, the stored KRRCint 440 may have been derived from an AS key (K_enB) 444 previously negotiated between the UE 400 and source eNB. Further, the ShortResumeMAC-I 416 may comprise the 16 least significant bits of the output of the integrity protection algorithm 417. [0054] In addition to K_RRCint 440, the integrity protection algorithm 417 used to calculate the ShortResumeMAC-I 416 may comprise one or more of the following inputs: source C-RNTI, source PCI, target Cell-ID, target C-RNTI, resume cause, message type, etc. Further, verification of the ShortResumeMAC-I 416 may be carried out via the source cell using the stored integrity key K_RRCint 440.

[0055] For protection of UL EDT data in the RRC Connection Resume Request message 412 (and all other subsequent RRC messages except an RRC Connection Reject message), the UE 400 (and target eNB) may derive a new AS key (K_{e B}*) 450. The new K_{e B}* 450 may be derived using a target PCI and a target Evolved Universal Terrestrial Radio Access (E-UTRA) absolute radio frequency channel number (EARFCN). The target PCI and target EARFCN may be obtained from a cell configuration database via the target Cell-ID, which identifies the target eNB where the UE 400 sends the RRC Connection Resume Request message 412. In addition to the target PCI and target EARFCN, a K_eNB/NH may also be used as an input to derive the new K_eNB* 450 based on either a horizontal key derivation or a vertical key derivation according to a next hop (NH) chaining counter (NCC) value sent to the UE 400 in the RRC Connection Suspend message (e.g., such as in step 8 of FIG. 3). For example, the horizontal key derivation may be used when the K_{e B} is used as one of the three inputs to derive the new K_{e B}* 450, whereas the vertical key derivation may be used when the next hop (NH) parameter is used rather than the K_{e B}· The NH corresponds to an NCC associated with the K_{e B}·

[0056] The UE 400 (and target eNB) may further derive new AS keys from the newly derived K_{e B}* 450. For example, the UE 400 (and target eNB) may use the K_{e B}* 450 to generate a U-plane key (Kup_enc) 432 for U-plane encryption (e.g., via block 460), an RRC integrity key (K_RRCint) 434 for integrity protection, and an encryption key (KRR_COIC) 436 for RRC encryption on the control plane. The UE 400 (and the target eNB) may use the newly derived Kup_enc 432 for ciphering/deciphering of UL EDT data in the PDCP layer, where UL EDT data may be sent concurrently with the RRC Connection Resume Request message 412. The UE 400 (and target eNB) may also use the newly derived Kup_enc 432 for ciphering/deciphering of user DL data (if included) in the PDCP layer via an RRC Connection Resume message (e.g., step 2 in FIG. 2) or an RRC Connection Suspend message (e.g., step 8 in FIG. 3).

[0057] In some embodiments, a new input parameter for calculating and verifying the ShortResumeMAC-I 416 may be provided to integrity protect the UP data transmitted during the RRC resume procedure. For example, the new input parameter may comprise a HASH value (e.g., HASHUE-DATA) 418 of an uplink PDCP Data PDU, where the HASH value 418 may be used as an additional input for calculating the ShortResumeMAC-I 416. This way, the input of HASHUE-DATA 418 (i.e., uplink PDCP data PDU) may be integrity protected. FIG. 5 is a portion 500 of an algorithm that the UE 400 may use to encode this HASH value 418 according to an embodiment of the disclosure.

[0058] In an embodiment, the HASHuu-_data 418 may be derived according to a KDF 470 using the following inputs: Hash Key 422 and PDCP PDU 423. For example, the Hash Key 422 may comprise a 256-bit string of all zeros, while the PDCP PDU 423 may comprise uplink PDCP Data PDU. Moreover, the UE 400 may calculate the HASHu_E-data 418 as the 64 least significant bits of the 256 bits output by the KDF 470 (e.g., a hash of the uplink PDCP PDU 423). As shown in block 480, the HASHu_E-data 418 may added to a UE-based EDT variable (VarShortResumeEDT-MAC-Input) used as an input to the integrity protection algorithm 417. Accordingly, the UE 400 may then calculate the shortResumeMAC-I 416 using a source physical cell ID (PCI), source C-RNTI, target Cell-ID, and HASHu_E-data 418, as well as the old K_RRCint 440. The source PCI and source C-RNTI are associated with the prior cell where the UE 400 was suspended, while the target Cell-ID identifies the cell of the target eNB to which the UE 400 sends the RRC Connection Resume Request message 412.

[0059] The target eNB may similarly calculate a HASH_eNB-data with uplink PDCP Data PDU received from the UE 400, and may include the HASH_eNB-data in a Retrieve UE Context Request message sent to a source eNB of a the cell where the RRC connection was suspended. The source eNB may then verify the ShortResumeMAC-I 416 with the source PCI, source C-RNTI, target Cell-ID and the HASH_eNB-data stored by the source eNB.

[0060] The solutions described above with respect to FIG. 4 generally provide a comprehensive framework to support security for user plane EDT. However, the HASHu_E-data 418 used in the calculation of shortResumeMAC-I 416 may only support integrity protection of user plane EDT when the UE 400 transmits a single PDCP PDU. In some scenarios, the UE 400 may trigger user plane EDT when transmitting two or more PDCP PDUs (e.g., one data radio bearer (DRB) having two or more PDCP PDUs, or two or more DRBs each having PDUs to transmit).

[0061] FIGS. 6 and 7 provide schematic diagrams of a UE for providing integrity protection of UP-EDT data according to embodiments of the disclosure. FIGS. 6 and 7 are similar to FIG. 4, except the embodiments of FIGS. 6 and 7 extend the embodiment of FIG. 4 to cases involving a data transmission corresponding to multiple PDCP PDUs. For brevity and ease of understanding, the following discussion of FIGS. 6 and 7 is limited to features that differ from those in FIG. 4.

[0062] FIG. 6 depicts a UE 600 for providing integrity protection of UP-EDT data in a data transmission involving two PDCP PDUs. Fike FIG 4, Message 3 MAC PDU may be assumed to be an RRC Connection Resume Request message 612, except this message is triggered by two PDCP PDUs 601 and 603 rather than a single PDCP PDU (e.g., PDCP PDU 423). Additionally, the RRC Connection Resume Request message 612 may comprise one sub-header for each MAC CE, each MAC SDU (e.g., MAC SDUo and MAC SDUo), and/or padding (optional).

[0063] The UE 600 comprises an RRC processing unit 610 and a PDCP processing unit 620, which may be configured to operate in a manner similar to that described above with respect to the PDCP processing unit 420, except operation of the PDCP processing unit 620 is extended to handle two or more PDCP PDUs. For example, when receiving PDCP SDUs 621 and 622, the PDCP processing unit 620 may perform encryption (e.g., using Kup_enc 432) via blocks 660 and 661, and then perform ciphering to generate ciphered PDCP SDUs 623 and 624. The PDCP processing unit 620 may also perform header compression and add PDCP headers 625 and 626 to the PDCP SDUs 621 and 622 to generate the PDCP PDUs 601 and 603. The PDCP processing unit 620 may then submit the PDCP PDUs 601 and 603 to the RFC layer as RFC SDUs 627 and 628. There, the RRC processing unit 610 may segment the RFC SDUs 627 and 628 to generate RFC PDUs 631 and 633, and may add headers 634 and 635 containing information to split the RFC PDUs 631 and 633 into original packets at the receiver side. After performing segmentation, the RRC processing unit 610 may submit the RFC PDUs 631 and 633 to a medium access layer as MAC SDUi 636 and MAC SDU2 637, which may comprise a portion of a MAC PDU such as a Message 3 MAC PDU 612 to be transmitted via a physical layer.

[0064] The RRC processing unit 610 is configured to calculate a shortResumeMAC-I 616 such as described above with respect to FIG 4, except the RRC processing unit 610 calculates the shortResumeMAC-I 616 using more than one HASHu_E-data field. For example, a different hash value (HASHu_{E-data j}) may be calculated using PDCP PDU values from each of the two PDCP PDUs to be included in the UP-EDT data, e.g., PDCP PDU 601 and PDCP PDU 603. Accordingly, a first HASHu_E-datai 618A may be derived according to the KDF 470 using the following inputs: Hash Key 422 and PDCP PDU 601. Similarly, a second HASHu_E-data2 618B may be derived according to the KDF 470 using the following inputs: Hash Key 422 and PDCP PDU 603. Each Hash Key 422 may comprise a 256-bit string of all zeros, while the PDCP PDUs 601 and 603 comprise two uplink PDCP Data PDUs. Like FIG. 4, FIG. 6 includes a UE-based EDT variable (VarShortResumeEDT-MAC-Input) 680 to be used as an input to the integrity protection algorithm 417 for calculating the shortResumeMAC-I 616, except this variable 680 is modified to include the first HASHu_E-datai 618A and the second HASHu_E-data2 618B (i.e., rather than a single HASH value 418).

[0065] It should be understood that while the UE-based EDT variable 680 is based on an example involving two HASH values 618A and 618B derived based on two PDCP PDUs 601 and 603, this variable 680 may be modified to accommodate more than two HASH values in other examples. That is, the UE-based EDT variable 680 may include one HASHne-_{data i} for each PDCP PDU included in a user plane EDT. Hence, if five PDCP PDUs are included, the UE-based EDT variable 680 may be modified to include five HASH values (e.g., HASHu_E-datai- HASH_UE- _datas) calculated using the five respective PDCP PDUs.

[0066] Like FIG. 4, the UE-based EDT variable 680 may be used to together with the old source integrity key (K_RRCint) 440 as inputs to the integrity protection algorithm 417. However, the resulting shortResumeMAC-I 616 may depend on the order of the first I IASI I ur-datai 618A and the second HASHuE-data2 618B included in the UE-based EDT variable 680. As such, the source eNB may need to know the order of these hash values in order to correctly verify the value of the shortMAC-I.

[0067] In an embodiment, the UE 600 may be configured to identify and communicate the ordering of the first I IASI Iur-_datai 618A and the second I IASI Iu_E-data2 618B to the target eNB, which may convey this information to the source eNB (e.g., via a Retrieve UE Context Request message). According to one aspect, the UE 600 may explicitly indicate the order of the PDCP PDUs 601 and 603 in the RRC Connection Resume Request message 612. However, explicitly indicating the order may increase the size of the RRC Connection Resume Request message 612, thereby reducing the space available for user plane data in this message 612.

[0068] According to another aspect, the order of the HASHu_E-datai and I IASI Iui -_daia2 fields in the UE-based EDT variable 680 may be implicitly indicated based on the order of the DRB MAC SDUs in the Message 3 MAC PDU 612. This aspect may warrant coordination between the medium access control layer that builds the Message 3 MAC PDU 612 and the RRC layer, which defines the VarShortResumeEDT-MAC-Input parameter from which shortMAC-I is derived.

[0069] According to yet another aspect, the HASHu_E-datai and HASHu_E-data2 fields may be placed in the UE-based EDT variable 680 in order of ascending (or descending) DRB identifiers (e.g. logical channel identifiers (LCIDs)), and in order of ascending (or descending) PDCP sequence number within a single DRB. As such, this aspect may not warrant explicit signaling of the order of PDCP PDUs or inter-layer coordination within the UE 600. Like other aspects, however, implementing this aspect may raise complications in terms of defining the VarShortResumeEDT-MAC-Input parameter. For example, the ASN.l encoding used by the RRC protocol may not support arrays (e.g., sequence data types) of variable length.

[0070] FIG. 7 depicts a UE 700 for providing integrity protection of UP-EDT data in a data transmission involving two or more PDCP PDUs. Like FIG. 6, Message 3 MAC PDU may be assumed to be an RRC Connection Resume Request message 712 triggered by two PDCP PDUs 601 and 603. The UE 700 comprises an RRC processing unit 710 and a PDCP processing unit 720, which may be configured to operate in a manner similar to that described above with respect to the PDCP processing unit 620. The RRC processing unit 710 is configured to calculate a shortResumeMAC-I 716 using a single HASHu_E-data input derived from a combination of multiple HASH _iE-data variables. That is, the RRC processing unit 710 calculates the first HASHu_E-datai 618A and the second HASHu_E-data2 618B as described with respect to FIG. 6, except that rather than adding the HASH values 618A and 618B as separate fields in the UE-based EDT variable 680 as in FIG. 6, these HASH values 618A and 618B are combined to generate a single HASHu_E-data variable 718. Combining such values mitigates concerns associated with using multiple HASH values, which could potentially complicate the definition of the VarShortResumeEDT-MAC-Input, as the ASN.l encoding used by RRC may not support arrays (e.g., SEQUENCE data types) with variable length.

[0071] In an embodiment, the first HASH _iE-datai 618A and the second HASHu_E-data2 618B are combined using a commutative operation. For example, after deriving the first HASHu_E-datai 618A and the second HASHu_E-data2 618B from the KDF 470 based on the Hash Key 422 and respective PDCP PDUs 601 and 603, the first HASHu_E-datai 618A and the second HASH_EiE-data2 618B may be applied as inputs to a commutative operator 790. In some aspects, the commutative operator 790 may be used to be perform a bitwise exclusive or (XOR) operation to output a single HASHu_E-data input variable 718. In other aspects, the combining operator 790 may be configured to perform an additional modulo operation to output the single HASHu_E-data input variable 718.

[0072] In some embodiments, the length of the single HASHu_E-data input variable 718 may be the same as the length of the fields being combined via the commutative operator 790 (e.g., length of HASHu_E-data = length of HASHu_E-datai + length of HASHu_E-data2)· Furthermore, the commutative operator 790 may be configured to combine the first HASHu_E-datai 618A and the second I IASI Iui -_dau 618B such that the resulting I IASI Iui -_data value input to the integrity protection algorithm 417 to calculate the shortResumeMAC-I 716 is independent of the order of the individual HASH values (i.e., HASHu_E-datai and HASHu_E-data2) for the different PDCP PDUs (i.e., PDCP PDU 601 and PDCP PDU 603). Such as an order-independent result may be expressed as follows: HASHu_E-data ⁼ HASHu_E-datai 0 I IASI Iui -_data2 = I IASI Iui -_data2 0 HASHEE- _{datai ·} 0 represents a commutative operator that satisfies the following formula: A 0 B = B 0 A.

[0073] As shown in FIG. 7, the single HASHu_E-data input variable 718 may be included in a UE-based EDT variable 780, which may be used as an input to the integrity protection algorithm 417 to calculate the shortResumeMAC-I 716. Like previously discussed with respect to FIG. 6, it should be understood that the concepts disclosed herein with respect to FIG. 7 are similarly applicable to examples where more than two PDCP PDUs are included in user-plane EDT.

[0074] In some embodiments, the concept of using a commutative operation as disclosed herein (e.g., bitwise XOR) may be applied to a case where the UE 700 uses regular a UP integrity protection mechanism to calculate MAC-I for each PDCP PDU. In other approaches, each PDCP PDU is usually transmitted with its UP IP MAC-I, which may cause overhead over the air, particularly for Internet of Things (IoT) devices. According to an embodiment, a similar concept may be applied by allowing the UE 700 to commutatively combine HASH values of all PDCP PDUs and transmit only the output of the commutative operation (i.e., a single output). A receiving eNB may perform a similar operation as the UE 700 to validate the integrity of the received PDCP PDUs by comparing its output for the same commutative operation to the one received from the UE 700. Further, a dynamically allocated secret key may be a pre-shared between the UE 700 and the receiving eNB, wherein this dynamically allocated secret key may be used by the UE 700 and receiving eNB to generate UP IP MAC-I according to the following respective formulas:

MAC-Iu_E-up-_data = [MAC-I(l) XOR MAC-I(2)]

MAC-I_eNB-up-_data = [MAC-I(l) XOR MAC-I(2)].

[0075] FIGS. 8 and 9 provide schematic diagrams of network entities for providing integrity protection of UP-EDT data according to embodiments of the disclosure. FIGS. 8 and 9 are substantially similar to FIGS. 6 and 7, except the embodiments in FIGS. 8 and 9 are depicted from the perspective of network entities rather than a UE.

[0076] Referring first to FIG. 8, a schematic diagram is depicted of a source eNB 800 and a target eNB 810, which is configured to receive the RRC Connection Resume Request message 612 from the UE 600 in FIG 6. Upon reception of the Message 3 MAC PDU 612, the target eNB 810 may parse the Message 3 MAC PDU 612 into the respective SRB and DRB PDCP PDUs, and decode the RRC Connection Resume Request message 612. The target eNB 810 calculates a hash value 818A and 818B for each of the user plane PDCP PDUs 601 and 603 (e.g., HASH_eNB- datai, I IASI I_CNB-data2. etc.). The target eNB 810 may then send an X2AP - UE Context Retrieve Request message to the source eNB 800. As shown in block 855, the X2AP - UE Context Retrieve Request message may include a list of the HASH_eNB-data values 818A and 818B, other parameters (e.g., resume ID), and the shortResumeMAC-I received from the UE 600.

[0077] The source eNB 800 may use the information in the X2AP - UE Context Retrieve Request message (e.g., UE C-RNTI) to retrieve the context for the UE 600, including the K.RR( mt 440. The source eNB 800 may then derive a shortMAC-I value using the HASH_eNB-data values and other parameters from the X2AP - UE Context Retrieve Request. The source eNB 800 compares the derived shortMAC-I value with the UE’s shortResumeMAC-I received from the target eNB 810. If the shortMAC-I derived by the source eNB 800 matches the shortResumeMAC-I from the UE 600, the source eNB 800 considers the UE 600 as being authenticated. In this case, the source eNB 800 responds to the target eNB 810 with an X2AP - UE Context Retrieve Response message 870. Otherwise, if authentication of the UE 600 fails, the source eNB 800 responds to the target eNB 810 with a X2AP - UE Context Retrieve Reject message 875.

[0078] FIG 9 depicts a schematic diagram of a source eNB 900 and a target eNB 910, which is configured to receive the RRC Connection Resume Request message 712 from the UE 700 in FIG. 7. Upon receiving this message 712 from the UE 700, the target eNB 910 may parse the Message 3 MAC PDU 712 into respective SRB and DRB PDCP PDUs, and decode the RRC Connection Resume Request message 712. The target eNB 910 calculates a hash value for each user plane PDCP PDU (e.g., HASH_eNB-datai, HASH_eNB-data2, etc.). The target eNB 910 then combines the individual HASH_eNB-data values (one for each PDCP PDU) into a single HASH_eNB- _data value, using the same commutative operator 790 (e.g. bit-by-bit XOR) used by the UE 700. The target eNB 910 then forwards the resulting single combined HASH_{eNB-d ta} value, other parameters (e.g., resume ID), and the shortResumeMAC-I received from the UE 700 in an X2AP - UE Context Retrieve Request message to the source eNB 900.

[0079] The source eNB 900 uses the information in the X2AP - UE Context Retrieve Request message 950 (e.g., UE C-RNTI) to retrieve the context for the UE 700, including the stored K.RR( int 440. The source eNB 900 then derives a shortMAC-I value using the single combined HASH_eNB-data value and other parameters from the X2AP - UE Context Retrieve Request 950. The source eNB 900 compares the derived shortMAC-I value with the UE’s shortResumeMAC-I received from the target eNB 910. If the shortMAC-I derived by the source eNB 900 matches the shortResumeMAC-I from the UE 700, the source eNB 900 considers the UE 700 as being authenticated. In this case, the source eNB 900 responds to the target eNB 910 with an X2AP - UE Context Retrieve Response message 970. Otherwise, if the authentication of the UE 700 fails, the source eNB 900 responds to the target eNB 910 with an X2AP - UE Context Retrieve Reject message 975.

[0080] Generally speaking, the target eNBs 810 and 910 in FIGS. 8 and 9 may be configured to perform similar operations as the UEs in FIG 6 and 7 in order to provide integrity protection of UP-EDT data according to embodiments disclosed herein. However, it is to be understood that some operations may be reversed where appropriate. Briefly, for example, rather than performing encryption (e.g., via blocks 660 and 661), the target eNBs 810 and 910 may use user plane encryption keys (e.g., Kup_enc 432) via blocks 860 and 861.

[0081] FIG 10 is a flowchart illustrating a method 1000 for providing user-plane EDT integrity protection according to an embodiment of the disclosure. The operations may be performed in the order shown, or in a different order. Further, two or more of the operations may be performed concurrently instead of sequentially.

[0082] At block 1002, the method 1000 comprises calculating a first hash value based upon a first data protocol data unit (PDU). At block 1004, the method 1000 comprises calculating a second hash value based upon a second data PDU. At block 1006, the method 1000 comprises calculating a message authentication code (MAC) based upon a portion of the first hash value and a portion of the second hash value. At block 1008, the method 1000 comprises transmitting a medium access control PDU comprising the first data PDU, the second data PDU, and a connection resume request comprising a portion of the MAC.

[0083] FIG. 11 is a schematic diagram illustrating an apparatus 1300 according to an embodiment of the present disclosure. The apparatus 1300 can be any type of network node, controller, router, switch, or the like. For example, the apparatus 1300 may include a base station, NB, MME, S-GW, etc. The apparatus 1300 may also be a user equipment (UE), a mobile terminal (MT), a mobile user equipment, or the like, and the apparatus 1300 may communicate with one or more core networks using a radio access network (RAN).

[0084] The apparatus 1300 includes receiver units (RX) 1320 or receiving means for receiving data via ingress ports 1310. The apparatus 1300 also includes transmitter units (TX) 1340 or transmitting means for transmitting via data egress ports 1350.

[0085] The apparatus 1300 includes a memory 1360 or data storing means for storing the instructions and various data. The memory 1360 can be any type of or combination of memory components capable of storing data and/or instructions. For example, the memory 1360 can include volatile and/or non-volatile memory such as read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and/or static random-access memory (SRAM). The memory 1360 can also include one or more disks, tape drives, and solid- state drives. In some embodiments, the memory 1360 can be used as an over- flow data storage device to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution.

[0086] The apparatus 1300 has one or more processors 1330 or other processing means (e.g., central processing unit (CPU)) to process instructions. The processor 1330 may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor 1330 is communicatively coupled via a system bus with the ingress ports 1310, RX 1320, TX 1340, egress ports 1350, and memory 1360. The processor 1330 can be configured to execute instructions stored in the memory 1360. Thus, the processor 1330 provides a means for performing any computational, comparison, determination, initiation, configuration, or any other action corresponding to the claims when the appropriate instruction is executed by the processor. In some embodiments, the memory 1360 can be memory that is integrated with the processor 1330.

[0087] In one embodiment, the memory 1360 stores an Integrity Protection Module 1370. The Integrity Protection Module 1370 includes data and executable instructions for implementing the disclosed embodiments. For instance, the Integrity Protection Module 1370 can include instructions for implementing the techniques described herein. The inclusion of the Integrity Protection Module 1370 substantially improves the functionality of the apparatus 1300 by extending the derivation of the shortResumeMAC-I to address integrity protection for two or more PDCP PDUs.

[0088] While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

[0089] In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.

Claims

CLAIMS What is claimed is:

1. A method for data integrity protection during resumption of a suspended data connection, the method comprising:

calculating, by a user equipment (UE), a first hash value based upon a first data protocol data unit (PDU);

calculating, by the UE, a second hash value based upon a second data PDU;

calculating, by the UE, a message authentication code (MAC) based upon a portion of the first hash value and a portion of the second hash value; and

transmitting, by the UE to a base station, a medium access control PDU comprising the first data PDU, the second data PDU, and a connection resume request comprising a portion of the MAC.

2. The method of claim 1, wherein the UE calculates the MAC based upon a first hash variable comprising the portion of the first hash value and a second hash variable comprising the portion of the second hash value.

3. The method of any of claim 1 or 2, wherein an ordering of the first hash variable and the second hash variable is explicitly indicated in the connection resume request.

4. The method of any of claims 1-3, wherein an ordering of the first hash variable and the second hash variable corresponds to an order of the first data PDU and the second data PDU in the medium access control PDU.

5. The method of any of claims 1-4, wherein an ordering of the first hash variable and the second hash variable corresponds to an order of channel identifiers for the first data PDU and the second data PDU in the medium access control PDU.

6. The method of any of claims 1-5, wherein the UE calculates the MAC based upon a third hash variable comprising a logical function of the portion of the first hash value and the portion of the second hash value.

7. The method of any of claims 1-6, wherein the logical function comprises a bitwise exclusive or (XOR) operation of the portion of the first hash value and the portion of the second hash value.

8. The method of any of claims 1-7, wherein the portion of the first hash value comprises a least significant sixty-four bits of the first hash value, wherein the portion of the second hash value comprises a least significant sixty- four bits of the second hash value, and wherein the portion of the MAC comprises a least significant sixteen bits of the MAC.

9. The method of any of claims 1-8, wherein the first data PDU and the second data PDU are transmitted via a first radio bearer.

10. The method of any of claims 1-9, wherein the first data PDU is transmitted via a first radio bearer and the second data PDU is transmitted via a second radio bearer.

1 1. A non-transitory computer readable medium storing computer instructions executable by one or more processors to implement a method for data integrity protection during resumption of a suspended data connection, the method comprising:

calculating, by the UE, a second hash value based upon a second data PDU;

12. The non-transitory computer readable medium of claim 1 1, wherein the UE calculates the MAC based upon a first hash variable comprising the portion of the first hash value and a second hash variable comprising the portion of the second hash value.

13. The non-transitory computer readable medium of any of claim 11 or 12, wherein an ordering of the first hash variable and the second hash variable is explicitly indicated in the connection resume request.

14. The non-transitory computer readable medium of any of claims 1 1-13, wherein an ordering of the first hash variable and the second hash variable corresponds to an order of the first data PDU and the second data PDU in the medium access control PDU.

15. The non-transitory computer readable medium of any of claims 1 1-14, wherein an ordering of the first hash variable and the second hash variable corresponds to an order of channel identifiers for the first data PDU and the second data PDU in the medium access control PDU.

16. The non-transitory computer readable medium of any of claims 11-15, wherein the UE calculates the MAC based upon a third hash variable comprising a logical function of the portion of the first hash value and the portion of the second hash value.

17. The non-transitory computer readable medium of any of claims 11-16, wherein the logical function comprises a bitwise exclusive or (XOR) operation of the portion of the first hash value and the portion of the second hash value.

18. The non-transitory computer readable medium of any of claims 11-17, wherein the portion of the first hash value comprises a least significant sixty-four bits of the first hash value, wherein the portion of the second hash value comprises a least significant sixty- four bits of the second hash value, and wherein the portion of the MAC comprises a least significant sixteen bits of the MAC.

19. The non-transitory computer readable medium of any of claims 11-18, wherein the first data PDU and the second data PDU are transmitted via a first radio bearer.

20. An apparatus for data integrity protection during resumption of a suspended data connection, the apparatus comprising:

at least one processor; and

a memory storing instructions executable by the at least one processor such that when executed, cause the apparatus to:

calculate a first hash value based upon a first data protocol data unit (PDU);

calculate a second hash value based upon a second data PDU;

calculate a message authentication code (MAC) based upon a portion of the first hash value and a portion of the second hash value; and transmit a medium access control PDU to a base station, wherein the medium access control PDU comprises the first data PDU, the second data PDU, and a connection resume request comprising a portion of the MAC.