Patent Description:
Wireless communication networks typically use integrity protection techniques to prevent or reduce network attacks, such as "forgery" attacks that mimic valid messages. In some cellular systems, for example, a transmitting device uses a particular integrity protection algorithm and input parameters to compute a message authentication code (or "MAC," which is not to be confused with the more widely used acronym for "media access control"), and sends the MAC along with the message being transmitted. The receiving device computes the expected MAC using the same algorithm and input parameters as the transmitting device, and verifies the data integrity of the message by comparing the expected MAC to the MAC in the received message.

A longer MAC increases the number of possible MAC values, which in turn decreases the likelihood that an attacker will be able to generate a MAC that matches the expected MAC. If a legitimate (non-attacker) transmitting device uses a <NUM>-bit MAC, for example, the "correct" MAC will be one out of <NUM><NUM> (roughly four billion) possible sequences. While this is a large number, an attacker device might eventually succeed by continuously flooding the network with messages using different MACs. A <NUM>-bit MAC, however, would result in <NUM><NUM> possible sequences, making it virtually impossible to match the expected MAC in any reasonable time frame.

The 3rd Generation Partnership Project (3GPP) TS <NUM> v15. <NUM> specifies that, for fifth-generation (<NUM>) networks, the transmitting device computes a <NUM>-bit access stratum MAC ("MAC-I") or non-access stratum (NAS)-MAC ("NAS-MAC"), for control plane and user plane messages, using a particular integrity protection algorithm and set of input parameters. To improve security, the 3GPP has initiated a study to determine whether the MAC-I and NAS-MAC can be increased to <NUM>, <NUM> or even <NUM> bits without overly degrading system performance. Even if such an increase does not significantly degrade system performance, however, this would likely introduce incompatibility issues arising from different devices using different MAC lengths.

For example, when transmitting a packet data convergence protocol (PDCP) protocol data unit (PDU) that includes a control plane Radio Resource Control (RRC) message, a <NUM> base station (e.g., a gNB) might compute a MAC-I to append to the RRC message using a <NUM>-bit algorithm, but an otherwise-compatible user device (commonly referred to using the acronym UE, which stands for "user equipment") that receives the PDCP PDU might compute an expected MAC-I (referred to as an "XMAC-I") using a <NUM>-bit algorithm. Or, the transmitting base station might compute a MAC-I using a <NUM>-bit algorithm, while the receiving UE computes the XMAC-I using a <NUM>-bit algorithm. In both of these scenarios, because the XMAC-I does not match the MAC-I, the receiving UE fails to verify/authenticate the message, and therefore ignores/discards the message. Ultimately, in such scenarios, communication between the base station and UE cannot proceed.

<CIT> relates to a MAC PDU configuration method for a network device which includes: configuring, by a network device, an MAC PDU carrying an indication field indicating a MAC-I for a user equipment and transmitting the configured MAC PDU to the user equipment.

<CIT> relates to techniques for sending a message for random access by a user equipment (UE). The UE generates a short message authentication code for integrity protection (MAC-I) for the message. The short MAC-I may have a smaller size and may be used to authenticate the UE.

<CIT> relates to a key configuration method using a security protection algorithm.

<CIT> relates to a method that allows the transmission of a message in a single lower layer data block even when the length of the message including the MAC-I exceeds the length of the lower layer data block.

At some point during an exchange of messages with a user device of this disclosure, a base station (e.g., a gNB) of this disclosure decides to use a particular message authentication code (MAC) length for integrity protection (e.g., in the access stratum). The decision may be based at least in part on the MAC length capabilities of the user device. The user device itself may inform the base station of the user device MAC length capabilities, or a core network (e.g., a 5GC) may inform the base station of the user device MAC length capabilities after learning of those capabilities from a different network element such as another base station or a registration server (e.g., via an authentication server function or "AUSF" of 5GC). Alternatively, the core network may decide to use a particular MAC length, and then configure the base station to use that MAC length.

After the base station determines (or is informed of) the desired MAC length, the base station sends the user device a message indicating that MAC length. The message may be an RRC message (e.g., an RRC Reconfiguration message) or a Security Mode Command message contained in a PDCP PDU, for example. In some implementations, to provide integrity protection of the message that indicates the desired MAC length, the message includes a MAC having a different length. For example, the user device may initially default to a shorter MAC length, and the base station may provide integrity protection for the message that indicates MAC length by computing and appending a MAC having the shorter length. In such an implementation, the user device verifies the shorter MAC appended to the message, e.g., by computing an expected MAC having the shorter MAC length and comparing that expected MAC to the appended MAC. After the user device receives the message indicating the desired MAC length, and possibly verifies a MAC of another (e.g., shorter) length that is appended to that message, the user device uses MACs of the indicated MAC length to provide integrity protection for one or more additional messages that the user device sends to and/or receives from the base station.

In some implementations, the base station message indicates the desired MAC length specifically for user plane messages, in which case the user device uses the indicated MAC length for user plane messages (e.g., PDCP PDUs sent or received via a data radio bearer (DRB)) but not necessarily for control plane messages (e.g., RRC messages sent or received via a signal radio bearer (SRB)). For example, the user device may continue to use a default (e.g., shorter) MAC length for control plane messages, unless the base station sends a separate message indicating that the new MAC length is to be used for control plane messages. In one such implementation, the base station sends a Security Command Message indicating that the new MAC length is to be used for user plane messages, and a separate RRC message (e.g., an RRC Reconfiguration message) indicating that the new MAC length is also to be used for control plane messages. In other implementations, the base station message indicates that the MAC length is to be used for both user plane and control plane messages.

One example implementation of these techniques is a method according to independent claim <NUM>.

Another example implementation of these techniques is a method according to independent claim <NUM>.

Yet another example implementation of these techniques is a method according to independent claim <NUM>.

Further example implementations of these methods are provided in dependent claims <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM>.

Further example implementations of these techniques are a user device according to independent claim <NUM>, a base station according to independent claim <NUM> and one or more core network elements according to independent claim <NUM>.

Generally speaking, the techniques of this disclosure allow a user device (UE) and a base station to use a consistent message authentication code (MAC) length for integrity protection, thereby allowing for the authentication/verification of messages in a wireless communication network. Thus, the disclosed techniques avoid scenarios in which communications cannot proceed due to lack of authentication. Moreover, the disclosed techniques may avoid sub-optimal system designs in which all user devices and base stations must use a default, relatively short MAC length, regardless of their MAC length capabilities. Thus, integrity protection may be strengthened in scenarios where the user device and base station both support more robust integrity protection.

These techniques are discussed below with example reference to a fifth-generation (<NUM>) radio access ("NR") network and, at times, an Evolved Universal Terrestrial Radio Access (EUTRA) network. Further, the examples relate to a <NUM> core network (5GC). However, the techniques of this disclosure can apply to other radio access and/or core network technologies.

Referring first to <FIG>, a UE <NUM> can operate in an example wireless communication network <NUM>. The wireless communication network <NUM> includes base stations <NUM>-<NUM> and <NUM>-<NUM>, associated with respective cells <NUM>-<NUM> and <NUM>-<NUM>. While <FIG> depicts each of base stations <NUM>-<NUM> and <NUM>-<NUM> as serving only one cell, it is understood that the base station <NUM>-<NUM> and/or the base station <NUM>-<NUM> may also cover one or more additional cells not shown in <FIG>. In general, the wireless communication network <NUM> can include any number of base stations, and each of the base stations can cover one, two, three, or any other suitable number of cells.

The base station <NUM>-<NUM> may operate as a <NUM> Node B (gNB), and the base station <NUM>-<NUM> may operate as a next-generation evolved Node B (ng-eNB), for example. As seen in <FIG>, the base station <NUM>-<NUM> and the base station <NUM>-<NUM> are both connected to a 5GC <NUM>, which is in turn connected to the Internet <NUM>. In other scenarios, the base station <NUM>-<NUM> may not be connected directly to the 5GC <NUM> (e.g., the base station <NUM>-<NUM> may connect to another core network not shown in <FIG>, which in turn communicates with the 5GC <NUM>). In various alternative implementations and/or scenarios, the wireless communication network <NUM> does not include the base station <NUM>-<NUM> and/or the cell <NUM>-<NUM>, or the base station <NUM>-<NUM> is another gNB and the cell <NUM>-<NUM> is another NR cell, etc..

The UE <NUM> can support an NR air interface, and exchange messages with the base station <NUM>-<NUM> when operating in the NR cell <NUM>-<NUM>. In some implementations, the UE <NUM> also can support a EUTRA air interface, and exchange messages with the base station <NUM>-<NUM> over <NUM> NR when operating in the NR cell <NUM>-<NUM>, and with the base station <NUM>-<NUM> over EUTRA when operating in the EUTRA cell <NUM>-<NUM>. The UE <NUM> in still other implementations can support only EUTRA. As discussed below, the UE <NUM> can be any suitable device capable of wireless communications.

The UE <NUM> is equipped with processing hardware <NUM>, which can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors can execute. Additionally or alternatively, the processing hardware <NUM> can include special-purpose processing units, such as a wireless communication chipset, for example. The processing hardware <NUM> includes a packet data convergence protocol (PDCP) controller <NUM>. The PDCP controller <NUM> is responsible for inbound messaging, outbound messaging, and internal procedures at the corresponding layer of a wireless communication protocol stack <NUM>. For example, the PDCP controller <NUM> is configured to package and interpret PDCP protocol data units (PDUs) that embed messages from other layers, such as radio resource control (RRC) messages. While not shown in <FIG>, the processing hardware <NUM> may also include a controller for each of a number of other layers, such as an RRC controller and/or a mobility management (MM) controller.

The PDCP controller <NUM> can be implemented using any suitable combination of hardware, software, and/or firmware. In one example implementation, the PDCP controller <NUM> is a set of instructions that defines respective components of the operating system of the UE <NUM>, and one or more CPUs of the processing hardware <NUM> execute these instructions to perform the respective PDCP functions. In another implementation, the PDCP controller <NUM> is implemented using firmware as a part of a wireless communication chipset.

The protocol stack <NUM>, illustrated in a simplified manner in <FIG>, includes a physical layer <NUM> (commonly abbreviated as PHY), a medium access control layer <NUM> (with medium access control not being abbreviated as "MAC" herein, to avoid confusion), a radio link control (RLC) layer <NUM>, a PDCP layer <NUM>, an RRC layer <NUM>, and possibly a service data adaptation protocol (SDAP) layer <NUM>, as parts of an access stratum <NUM>. A non-access stratum (NAS) <NUM> of the protocol stack <NUM> includes, among other layers, one or more MM layers <NUM> for handling registration, attachment, or tracking area update procedures.

As further illustrated in <FIG>, the protocol stack <NUM> also supports higher-layer protocols <NUM> for various services and applications. For example, the higher-layer protocols <NUM> may include Internet Protocol (IP), Transmission Control Protocol and User Datagram Protocol (UDP). The PDCP controller <NUM> is configured to package and interpret PDCP protocol data units (PDUs) that embed data packets of higher-layer protocols, including the RRC layer <NUM> and the higher-layer protocols <NUM>. The various layers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> may be ordered as shown in <FIG>. It is understood, however, that in some implementations and/or situations, one or more of the depicted layers may operate in a manner that does not strictly conform to the ordering shown in <FIG>.

The base station <NUM>-<NUM> is equipped with processing hardware <NUM>, which can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors can execute. Additionally or alternatively, the processing hardware <NUM> can include special-purpose processing units, such as a wireless communication chipset, for example. Similar to the processing hardware <NUM> of UE <NUM>, the processing hardware <NUM> includes a PDCP controller <NUM>. While the PDCP controller <NUM> of the UE <NUM> implements functionality of the PDCP layer <NUM> on the user device side, however, the PDCP controller <NUM> of the base station <NUM>-<NUM> implements functionality of the PDCP layer <NUM> on the base station side. While not shown in <FIG>, the processing hardware <NUM> may also include a controller for each of a number of other layers, such as an RRC controller and/or an MM controller.

The PDCP controller <NUM> can be implemented using any suitable combination of hardware, software, and/or firmware. In one example implementation, the PDCP controller <NUM> is a set of instructions that defines respective components of the operating system of the base station <NUM>, and one or more CPUs of the processing hardware <NUM> execute these instructions to perform the respective PDCP functions. In another implementation, the PDCP controller <NUM> is implemented using firmware as a part of a wireless communication chipset. In some implementations, the base station <NUM>-<NUM> includes processing hardware similar to the processing hardware <NUM> of the base station <NUM>-<NUM>, but specifically configured to operate in the EUTRA cell <NUM>-<NUM> rather than the NR cell <NUM>-<NUM>. In other implementations, the base station <NUM>-<NUM> may be co-located with the base station <NUM>-<NUM> and share some of the processing hardware <NUM> of the base station <NUM>-<NUM>.

To form a PDCP PDU for transmission, the PDCP controller <NUM> or PDCP controller <NUM> prepends a PDCP header to the payload that is to be transmitted within the PDCP PDU (e.g., a data packet or an RRC PDU including an RRC message) and, to provide integrity protection, appends an access stratum MAC (referred to herein as a "MAC-I") to the payload. For ease of explanation, references herein to the content of PDCP PDUs may not explicitly mention the PDCP header. While the various example implementations discussed below include a MAC-I at the end of a PDCP PDU, it is understood that in other implementations the MAC-I may instead be at a different location within the PDCP PDU, or may be included in a data unit other than a PDCP PDU. In the following description, any reference to a PDCP PDU including or containing an RRC message is understood to mean that the PDCP PDU includes an RRC PDU, which in turn includes the RRC message.

The PDCP controller <NUM> or PDCP controller <NUM> computes the MAC-I for the PDCP PDU by using an integrity algorithm that operates upon various parameters having particular values, such as the "NIA" algorithm referred to in the 3GPP TS <NUM> v15. When receiving a PDCP PDU, the PDCP controller <NUM> or PDCP controller <NUM> calculates an "expected" MAC-I (referred to herein as an XMAC-I) using the same (e.g., NIA) algorithm and, if the sender/message is to be properly authenticated/verified, the same parameters and parameter values. The PDCP controller <NUM> or PDCP controller <NUM> compares the XMAC-I to the MAC-I of the received PDCP PDU, and verifies the authenticity of the message contained in the PDCP PDU if and only if the XMAC-I matches the MAC-I. The UE <NUM> or base station <NUM>-<NUM> may ignore and/or discard a message that cannot be verified, for example. In some implementations, the PDCP controller <NUM> or PDCP controller <NUM> computes the MAC-I or the XMAC-I by using the integrity algorithm that operates upon the various parameters and the payload, or operates upon the various parameters, a PDCP header of the PDCP PDU, and the payload.

The NIA algorithm, for example, operates upon (i.e., accepts as input) a "COUNT" parameter value, a "DIRECTION" parameter value, a "BEARER" parameter value, a "KEY" parameter value, and the message itself. The "DIRECTION" parameter has a binary value that reflects the direction of transmission (e.g., "<NUM>" for uplink or "<NUM>" for downlink), and the "BEARER" parameter has a <NUM>-bit value that reflects the radio bearer identity. In some implementations, the PDCP controller <NUM> may derive the KEY parameter value based on a Security Mode Command message or an RRC Reconfiguration message received from the base station <NUM>-<NUM>. Similarly, the PDCP controller <NUM> may derive the KEY parameter value based on the Security Mode Command message or the RRC Reconfiguration message that the base station <NUM>-<NUM> transmits. In some implementations, the KEY parameter value is different for user plane and control plane messages.

As will be discussed in greater detail below, the PDCP controller <NUM> of UE <NUM> and the PDCP controller <NUM> of base station <NUM>-<NUM> each support at least two MAC-I lengths, including a shorter MAC-I (referred to herein as a "short MAC-I") and a longer MAC-I (referred to herein as a "long MAC-I"). For example, a short MAC-I may be a <NUM>-bit MAC-I, while a long MAC-I may be a <NUM>-bit, <NUM>-bit or <NUM>-bit MAC-I. For any given implementation or scenario discussed herein, it is understood that each reference to a "short" MAC-I (or XMAC-I) denotes a first constant bit length, and that each reference to a "long" MAC-I (or XMAC-I) denotes a second constant bit length. Thus, for example, if reference is made to two messages each containing a short MAC-I, for a particular implementation/scenario, it is understood that both of those MAC-Is have the same bit length. In alternative implementations, PDCP control <NUM> and/or PDCP controller <NUM> also support additional MAC-I lengths (e.g., and intermediate length MAC-I).

In some implementations, the PDCP controller <NUM> and PDCP controller <NUM> each use a larger size COUNT parameter (i.e., a COUNT parameter value having more bits) when computing a long MAC-I or XMAC-I, and a smaller size COUNT parameter (i.e., a COUNT parameter value having fewer bits) when computing a short MAC-I or XMAC-I. The following table provides examples of bit lengths for input parameters of the NIA algorithm, according to various implementations. For example, the UE <NUM> and base station <NUM>-<NUM> may support both the combination of parameter lengths shown in Example <NUM> (for the short MAC-I), and the combination of parameter lengths shown in any one of Examples <NUM> through <NUM> (for the long MAC-I):.

In some implementations where the bit length of the COUNT parameter differs for the short MAC-I and long MAC-I, the UE <NUM> and base station <NUM>-<NUM> use the COUNT (e.g., if Examples <NUM> and <NUM> above are both supported), the PDCP controller <NUM> of UE <NUM> and the PDCP controller <NUM> of base station <NUM>-<NUM> use the COUNT size for the long MAC-I for an RRC message or a data packet if the base station <NUM>-<NUM> configures the UE <NUM> to use a long MAC-I (as discussed below), and instead use the COUNT size for the short MAC-I for the RRC message or data packet if the base station <NUM>-<NUM> does not configure the UE <NUM> to use a long MAC-I. In other implementations, the PDCP controller <NUM> of UE <NUM> and the PDCP controller <NUM> of base station <NUM>-<NUM> use the same COUNT size regardless of the MAC-I size (e.g., if Examples <NUM> and <NUM> above are both supported).

For simplicity, <FIG> does not depict various components of the UE <NUM> and the base station <NUM>-<NUM>. In addition to the layer-specific controllers mentioned above, for example, the UE <NUM> and the base station <NUM>-<NUM> include respective transceivers, which comprise various hardware, firmware, and software components that are configured to transmit and receive wireless signals according to the NR air interface. The processing hardware <NUM> and the processing hardware <NUM> can send commands and exchange information with the respective transceivers as needed to perform various connection establishment procedures, perform various RRC or MM procedures, or communicate with other network elements, etc..

Example message sequences and methods that the UE <NUM> and/or base station <NUM>-<NUM> can implement and execute, alone or in combination with other components of the network <NUM>, will now be discussed with reference to <FIG>. The UE <NUM> and/or base station <NUM>-<NUM> can implement at least some of the acts described below in software, firmware, hardware, or any suitable combination of software, firmware, and hardware. Although <FIG> are discussed below with reference to the components depicted in <FIG> and a <NUM> system (e.g., with the base station <NUM>-<NUM> being a gNB), in general any suitable components or wireless communication network may be used. Furthermore, although <FIG> are discussed below with reference to implementations in which the UE <NUM> and base station <NUM>-<NUM> only use and/or support two MAC-I lengths (i.e., a short MAC-I and a long MAC-I), in other implementations the UE <NUM> and base station <NUM>-<NUM> support three or more MAC-I lengths.

Referring first to <FIG> and <FIG>, a messaging diagram <NUM> depicts example messages that may be exchanged between the UE <NUM> and the base station <NUM>-<NUM> of <FIG>, according to one implementation and scenario. In some implementations and/or scenarios, at the beginning of the message sequence depicted in <FIG> and <FIG>, the base station <NUM>-<NUM> does not yet know that the UE <NUM> supports a long MAC-I, and/or the UE <NUM> does not yet know that the base station <NUM>-<NUM> supports a long MAC-I.

In the messaging diagram <NUM>, after the UE <NUM> enters <NUM> an RRC_IDLE state, the UE <NUM> initiates an RRC establishment/setup procedure by transmitting <NUM> an RRC Setup Request message to the base station <NUM>-<NUM>. In response, the base station <NUM>-<NUM> transmits <NUM> an RRC Setup message to the UE <NUM>. In the depicted implementation, the RRC Setup Request and RRC Setup messages do not use the PDCP protocol (i.e., both messages bypass the PDCP layer <NUM>), and thus are not included in PDCP PDUs. In response to the RRC Setup message, the UE <NUM> enters <NUM> an RRC_CONNECTED state.

Thereafter, the PDCP controller <NUM> of UE <NUM> generates a PDCP PDU containing an RRC Setup Complete message and a short (e.g., <NUM>-bit) MAC-I. In one implementation, because the base station <NUM>-<NUM> has not yet configured the UE <NUM> to activate integrity protection, the PDCP controller <NUM> of UE <NUM> sets all bits of the short MAC-I to zeros, or to some other default value. The UE <NUM> then transmits <NUM> the PDCP PDU containing the RRC Setup Complete message and the short MAC-I to the base station <NUM>-<NUM>.

After receiving the RRC Setup Complete message, the PDCP controller <NUM> of base station <NUM>-<NUM> generates a PDCP PDU containing a Security Mode Command message and a short MAC-I. The PDCP controller <NUM> may compute the short MAC-I using an integrity protection algorithm indicated by an RRC field (e.g., an integrityProtAlgorithm field) that is included in the Security Mode Command message, and also using a key associated with the algorithm (e.g., the KRRCint key of 3GPP TS <NUM>). The PDCP controller <NUM> may compute the short MAC-I using the NIA algorithm discussed above, for example. The base station <NUM>-<NUM> then transmits <NUM> the PDCP PDU containing the Security Mode Command message and the short MAC-I to the UE <NUM>.

After the UE <NUM> receives the PDCP PDU containing the Security Mode Command message and the short MAC-I, the PDCP controller <NUM> of UE <NUM> verifies <NUM> the short MAC-I to authenticate the received message. To this end, the PDCP controller <NUM> derives the key associated with the algorithm indicated in the Security Mode Command Message (e.g., the KRRCint key associated with the integrityProtAlgorithm), and uses the indicated algorithm and derived key to compute a short XMAC-I. The PDCP controller <NUM> may default to the short MAC-I/XMAC-I format in the absence of a different command or configuration from the base station <NUM>-<NUM>, for example. The PDCP controller <NUM> compares the short MAC-I in the received PDCP PDU to the computed short XMAC-I. If the MAC-I and XMAC-I match, the UE <NUM> has successfully verified the received Security Mode Command message.

<FIG> and <FIG> depict a scenario in which the UE <NUM> successfully verifies <NUM> the Security Mode Command message. Unsuccessful verification (at any time in this sequence) may result in the UE <NUM> discarding the message or, in some situations, requesting termination of the connection between the UE <NUM> and the base station <NUM>-<NUM>. Therefore, the PDCP controller <NUM> of UE <NUM> generates a PDCP PDU containing a Security Mode Complete message and a short MAC-I. The PDCP controller <NUM> may compute the short MAC- I using the same integrity protection algorithm that was indicated by the field of the Security Mode Command message, and also using a key associated with the algorithm (e.g., the KRRCint key). The PDCP controller <NUM> may compute the short MAC-I using the NIA algorithm discussed above, for example. The UE <NUM> then transmits <NUM> the PDCP PDU containing the Security Mode Complete message and the short MAC-I to the base station <NUM>-<NUM>. In other scenarios, where the PDCP controller <NUM> cannot successfully verify the Security Mode Command message, the UE <NUM> does not generate and/or send the PDCP PDU containing the Security Mode Complete message.

After the base station <NUM>-<NUM> receives the PDCP PDU containing the Security Mode Complete message and the short MAC-I, the PDCP controller <NUM> of base station <NUM>-<NUM> verifies <NUM> the short MAC-I to authenticate the received message. To this end, the PDCP controller <NUM> uses the same algorithm and key (e.g., the integrityProtAlgorithm and KRRCint key) to compute a short XMAC-I. The PDCP controller <NUM> compares the short MAC-I in the received PDCP PDU to the computed short XMAC-I. If the MAC-I and XMAC-I match, the base station <NUM>-<NUM> has successfully verified the received Security Mode Complete message.

If the base station <NUM>-<NUM> fails to successfully verify the short MAC-I for the Security Mode Complete message, the base station <NUM>-<NUM> may transmit an RRC Release message to the UE <NUM> to terminate the connection between the UE <NUM> and the base station <NUM>-<NUM>. However, <FIG> and <FIG> depict a scenario in which the base station <NUM>-<NUM> successfully verifies <NUM> the Security Mode Complete message. In this scenario, at some time after the verification, the base station <NUM>-<NUM> determines <NUM> to configure to use the long (e.g., <NUM>-bit, <NUM>-bit or <NUM>-bit) MAC-I format. This determination may occur after the base station <NUM>-<NUM> learns that the UE <NUM> supports the long MAC-I format, for example, as discussed in further detail below (e.g., in connection with <FIG>).

After (e.g., in response to) determining <NUM> to configure to use the long MAC-I format, the base station <NUM>-<NUM> includes a security configuration (indicating the long MAC-I format) in an RRC Reconfiguration message. The PDCP controller <NUM> of base station <NUM>-<NUM> generates a PDCP PDU containing the RRC Reconfiguration message and a short MAC-I. The PDCP controller <NUM> may compute the short MAC-I using the same algorithm and key (e.g., the integrityProtAlgorithm and KRRCint key). The PDCP controller <NUM> may compute the short MAC-I using the NIA algorithm discussed above, for example. The base station <NUM>-<NUM> then transmits <NUM> the PDCP PDU containing the RRC Reconfiguration message and the short MAC-I to the UE <NUM>.

After the UE <NUM> receives the PDCP PDU containing the RRC Reconfiguration message and the short MAC-I, the PDCP controller <NUM> of UE <NUM> verifies <NUM> the short MAC-I (as discussed above for verification <NUM>) to authenticate the received message. <FIG> and <FIG> depict a scenario in which the UE <NUM> successfully verifies <NUM> the RRC Reconfiguration message. Therefore, in response to the UE <NUM> determining that the long MAC-I format is to be used based on the security configuration and/or RRC Reconfiguration message, the UE <NUM> determines to begin using the long MAC-I format for subsequent RRC messages exchanged between the UE <NUM> and the base station <NUM>-<NUM> over a signaling radio bearer (SRB).

In some implementations, successful verification (by the UE <NUM>) of the RRC Reconfiguration message that was transmitted <NUM> by the base station <NUM>-<NUM> only causes the UE <NUM> to change to the long MAC-I format for RRC messages exchanged between UE <NUM> and base station <NUM>-<NUM> over a subset of (e.g., one of) a plurality of SRBs. For example, the UE <NUM> may apply the long MAC-I format for RRC messages sent over a first SRB (e.g., "SRB <NUM>") but not for RRC messages sent over a second SRB (e.g., "SRB <NUM>"). The UE <NUM> may instead continue to use the short MAC-I format for RRC messages sent over the second SRB (e.g., until configured otherwise by the base station <NUM>-<NUM>). In other implementations, the UE <NUM> may change to the long MAC-I format for RRC messages sent over all SRBs.

Moreover, in some implementations, successful verification (by the UE <NUM>) of the RRC Reconfiguration message that was transmitted <NUM> by the base station <NUM>-<NUM> causes the UE <NUM> to change to the long MAC-I format for data packets exchanged between UE <NUM> and base station <NUM>-<NUM> over one or more data radio bearers (DRBs), in addition to (or instead of) RRC messages exchanged over one or more SRBs. Alternatively, the UE <NUM> may change to the long MAC-I format only for RRC messages sent over SRBs (or a subset of all SRBs, if more than one) but not for data packets sent over any DRB. For example, the UE <NUM> may instead use the short MAC-I format for data packets sent over DRBs.

In the scenario of <FIG> and <FIG>, after the verification <NUM>, the PDCP controller <NUM> of UE <NUM> generates a PDCP PDU containing an RRC Reconfiguration Complete message and a long MAC-I. The PDCP controller <NUM> may compute the long MAC-I using the same integrity protection algorithm that was indicated by the field of the Security Mode Command message, and possibly also the same key associated with the algorithm (e.g., the KRRCint key). If the security configuration and/or RRC Reconfiguration message indicates a different algorithm for integrity protection, however, the PDCP controller <NUM> may use that algorithm (e.g., with the KRRCint key). The UE <NUM> then transmits <NUM> the PDCP PDU containing the RRC Reconfiguration Complete message and the long MAC-I to the base station <NUM>-<NUM>, and the base station <NUM>-<NUM> verifies <NUM> the long MAC-I for the RRC Reconfiguration Complete message using the same integrity protection algorithm and key that the UE <NUM> had used to compute the long MAC-I.

The example scenario of <FIG> and <FIG> also includes the transmission of other RRC messages to which the UE <NUM> or base station <NUM>-<NUM> appends a long MAC-I. For example, the base station <NUM>-<NUM> generates and transmits <NUM> a PDCP PDU containing another RRC Reconfiguration message (e.g., with fields for measurement configuration, L1 configuration, medium access control configuration, RLC configuration and/or radio bearer configuration) and a long MAC-I (which the UE <NUM> verifies <NUM>), the UE <NUM> generates and transmits <NUM> a PDCP PDU containing another RRC Reconfiguration Complete message with a long MAC-I (which the base station <NUM>-<NUM> verifies <NUM>), and the UE <NUM> generates and transmits <NUM> a PDCP PDU containing a Measurement Report message with a long MAC-I (which the base station <NUM>-<NUM> verifies <NUM>). In some implementations, if the base station <NUM>-<NUM> fails to successfully verify the short MAC-I or long MAC-I for any RRC message received from the UE <NUM>, the base station <NUM>-<NUM> transmits an RRC Release message to the UE <NUM> to terminate the connection between the UE <NUM> and the base station <NUM>-<NUM>.

Referring next to <FIG> and <FIG>, a messaging diagram <NUM> depicts example messages that may be exchanged between the UE <NUM>, base station <NUM>-<NUM> and 5GC <NUM> of <FIG>, according to another implementation and/or scenario. In some implementations and/or scenarios, at the beginning of the message sequence depicted in <FIG> and <FIG>, the base station <NUM>-<NUM> does not yet know that the UE <NUM> supports a long MAC-I, and/or the UE <NUM> does not yet know that the base station <NUM>-<NUM> supports a long MAC-I.

<FIG> and <FIG> depict a scenario in which the UE <NUM> successfully verifies <NUM> the Security Mode Command message. Unsuccessful verification (at any time in this sequence) may result in the UE <NUM> discarding the message or, in some situations, requesting termination of the connection between the UE <NUM> and the base station <NUM>-<NUM>. Therefore, the PDCP controller <NUM> of UE <NUM> generates a PDCP PDU containing a Security Mode Complete message and a short MAC-I. The PDCP controller <NUM> may compute the short MAC-I using the same integrity protection algorithm that was indicated by the field of the Security Mode Command message, and also using a key associated with the algorithm (e.g., the KRRCint key). The PDCP controller <NUM> may compute the short MAC-I using the NIA algorithm discussed above, for example. The UE <NUM> then transmits <NUM> the PDCP PDU containing the Security Mode Complete message and the short MAC-I to the base station <NUM>-<NUM>. In other scenarios, where the PDCP controller <NUM> cannot successfully verify the Security Mode Command message, the UE <NUM> does not generate and/or send the PDCP PDU containing the Security Mode Complete message.

If the base station <NUM>-<NUM> fails to successfully verify the short MAC-I for the Security Mode Complete message, the base station <NUM>-<NUM> may transmit an RRC Release message to the UE <NUM> to terminate the connection between the UE <NUM> and the base station <NUM>-<NUM>. However, <FIG> and <FIG> depict a scenario in which the base station <NUM>-<NUM> successfully verifies <NUM> the Security Mode Complete message. In this scenario, at some time after the verification, the base station <NUM>-<NUM> determines <NUM> to configure to use the long (e.g., <NUM>-bit, <NUM>-bit or <NUM>-bit) MAC-I format specifically for a DRB of the UE <NUM>. This determination may occur after the base station <NUM>-<NUM> learns that the UE <NUM> supports the long MAC-I format, for example, as discussed in further detail below (e.g., in connection with <FIG>).

After (e.g., in response to) determining <NUM> to configure to use the long MAC-I format for the DRB, the base station <NUM>-<NUM> includes a security configuration (indicating the long MAC-I format for the DRB) in an RRC Reconfiguration message. The PDCP controller <NUM> of base station <NUM>-<NUM> generates a PDCP PDU containing the RRC Reconfiguration message and a short MAC-I. The PDCP controller <NUM> may compute the short MAC-I using the same algorithm and key (e.g., the integrityProtAlgorithm and KRRCint key). The PDCP controller <NUM> may compute the short MAC-I using the NIA algorithm discussed above, for example. The base station <NUM>-<NUM> then transmits <NUM> the PDCP PDU containing the RRC Reconfiguration message and the short MAC-I to the UE <NUM>.

After the UE <NUM> receives the PDCP PDU containing the RRC Reconfiguration message and the short MAC-I, the PDCP controller <NUM> of UE <NUM> verifies <NUM> the short MAC-I (as discussed above for verification <NUM>) to authenticate the received message. <FIG> and <FIG> depict a scenario in which the UE <NUM> successfully verifies <NUM> the RRC Reconfiguration message. Therefore, in response to the UE <NUM> determining that the long MAC-I format is to be used for the DRB of the UE <NUM> (based on the security configuration and/or RRC Reconfiguration message), the UE <NUM> determines to begin using the long MAC-I format for subsequent data packets exchanged between the UE <NUM> and the base station <NUM>-<NUM> over the DRB.

In the example scenario of <FIG> and <FIG>, after the verification <NUM>, the PDCP controller <NUM> of UE <NUM> generates a PDCP PDU containing an RRC Reconfiguration Complete message and a short MAC-I. That is, <FIG> and <FIG> reflect an implementation in which the configuration to long MAC-I format does not apply to RRC messages exchanged between UE <NUM> and base station <NUM>-<NUM> over SRBs. In some implementations, however, the PDCP controller <NUM> computes the short MAC-I using the same integrity protection algorithm that was indicated by the field of the Security Mode Command message, and possibly also the same key associated with the algorithm (e.g., the KRRCint key). The UE <NUM> then transmits <NUM> the PDCP PDU containing the RRC Reconfiguration Complete message and the short MAC-I to the base station <NUM>-<NUM>, and the base station <NUM>-<NUM> verifies <NUM> the short MAC-I for the RRC Reconfiguration Complete message using the same integrity protection algorithm and key that the UE <NUM> had used to compute the short MAC-I.

Also in the scenario of <FIG> and <FIG>, when the UE <NUM> needs to send some data (e.g., data relating to layers <NUM>) via the DRB, the PDCP controller <NUM> of UE <NUM> generates a PDCP PDU (or, in some implementations, an SDAP PDU) containing a data packet and a long MAC-I. The data packet may be an Internet Protocol (IP) packet, for example. If the base station <NUM>-<NUM> configures the UE <NUM> to use an SDAP for the DRB, the UE <NUM> generates an SDAP PDU containing the data packet, and then includes the SDAP PDU in the PDCP PDU. The PDCP controller <NUM> may compute the long MAC-I using the same integrity protection algorithm that was indicated by the field of the Security Mode Command message, and possibly also the same key associated with the algorithm (e.g., the KRRCint key), in some implementations and/or scenarios. If the security configuration and/or RRC Reconfiguration message indicated a different algorithm for integrity protection, however, the PDCP controller <NUM> may use that algorithm (e.g., with the KRRCint key). The UE <NUM> then transmits <NUM> the PDCP PDU (or SDAP PDU) containing the data packet and the long MAC-I over the DRB, and the base station <NUM>-<NUM> verifies <NUM> the long MAC-I of the PDCP PDU (i.e., by computing a long XMAC-I and comparing to the received long MAC-I). If the base station <NUM>-<NUM> configures the UE <NUM> to use an SDAP for the DRB, the base station <NUM>-<NUM> extracts the data packet from the SDAP PDU. The base station <NUM>-<NUM> then transmits <NUM> the data packet from the PDCP PDU to the 5GC <NUM>.

In the example scenario of <FIG> and <FIG>, the 5GC <NUM> then transmits <NUM> another data packet (e.g., data relating to layers <NUM>) for the DRB to the base station <NUM>-<NUM>. The PDCP controller <NUM> of the base station <NUM>-<NUM> then generates a PDCP PDU (or, in some implementations, an SDAP PDU) containing a data packet and a long MAC-I. The data packet may be an IP packet, for example. If the base station <NUM>-<NUM> configures the UE <NUM> to use the SDAP for the DRB, the base station <NUM>-<NUM> generates an SDAP PDU containing the data packet, and then includes the SDAP PDU in the PDCP PDU. The PDCP controller <NUM> may compute the long MAC-I for the PDCP PDU using the same integrity protection algorithm that was indicated by the field of the Security Mode Command message, and possibly also the same key associated with the algorithm (e.g., the KRRCint key), in some implementations and/or scenarios. If the security configuration and/or RRC Reconfiguration message indicated a different algorithm for integrity protection, however, the PDCP controller <NUM> may use that algorithm (e.g., with the KRRCint key). The base station <NUM>-<NUM> then transmits <NUM> the PDCP PDU (or SDAP PDU) containing the data packet and the long MAC-I over the DRB, and the UE <NUM> verifies <NUM> the long MAC-I of the PDCP PDU (i.e., by computing a long XMAC-I and comparing to the received long MAC-I).

In a first implementation corresponding to the example message diagram of <FIG> and <FIG>, before the transmission <NUM>, the base station <NUM>-<NUM> configures a first DRB to the UE <NUM> (e.g., "DRB <NUM>"), configures integrity protection for the first DRB and configures a second DRB to the UE <NUM> (e.g., "DRB <NUM>"), but does not configure integrity protection for the second DRB. To do this, the base station <NUM>-<NUM> may (before transmission <NUM>) transmit to the UE <NUM>, within each of one or more PDCP PDUs, an additional RRC Reconfiguration message and respective short MAC-I. Thereafter, if the UE <NUM> successfully verifies the short MAC-I for the RRC Reconfiguration message sent in the transmission <NUM>, the UE <NUM> does not use the long MAC-I format for the second DRB. That is, in this implementation and scenario, the UE <NUM> and the base station <NUM>-<NUM> include neither a short MAC-I nor a long MAC-I in PDCP PDUs exchanged over the second DRB.

In a second implementation corresponding to the example message diagram of <FIG> and <FIG>, before the transmission <NUM>, the base station <NUM>-<NUM> configures a first DRB to the UE <NUM> (e.g., "DRB <NUM>"), configures integrity protection for the first DRB, configures a second DRB to the UE <NUM> (e.g., "DRB <NUM>"), and configures integrity protection for the second DRB. To do this, the base station <NUM>-<NUM> may (before transmission <NUM>) transmit to the UE <NUM>, within each of one or more PDCP PDUs, an additional RRC Reconfiguration message and respective short MAC-I. In this implementation, the UE <NUM> uses the short MAC-I format for data packets to be transmitted or received over either of the two DRBs (e.g., to compute a short MAC-I or XMAC-I in the manner discussed above). Thereafter, if the UE <NUM> successfully verifies the short MAC-I for the RRC Reconfiguration message sent in the transmission <NUM>, the UE <NUM> may use the long MAC-I format for data packets sent over the second DRB. That is, the security configuration is applied to not only the first DRB, but also the second DRB.

In a third implementation corresponding to the example message diagram of <FIG> and <FIG>, before the transmission <NUM>, the base station <NUM>-<NUM> configures a first DRB to the UE <NUM> (e.g., "DRB <NUM>"), configures integrity protection for the first DRB, configures a second DRB to the UE <NUM> (e.g., "DRB <NUM>"), and configures integrity protection for the second DRB. To do this, the base station <NUM>-<NUM> may (before transmission <NUM>) transmit to the UE <NUM>, within each of one or more PDCP PDUs, an additional RRC Reconfiguration message and respective short MAC-I. In this implementation, the UE <NUM> uses the short MAC-I format for data packets to be transmitted or received over either of the two DRBs (e.g., to compute a short MAC-I or XMAC-I in the manner discussed above). Thus, the third implementation may initially be identical or similar to the second implementation discussed above. However, if the UE <NUM> then successfully verifies the short MAC-I for the RRC Reconfiguration message sent in the transmission, the UE <NUM> does not use the long MAC-I format for data packets sent over the second DRB. That is, the security configuration is applied to the first DRB but not the second DRB.

In each of the first, second, and third implementations described above, the base station <NUM>-<NUM> may configure the UE <NUM> to use the long MAC-I format in the manner shown in <FIG> and <FIG>. Thus, for each of the additional RRC Reconfiguration message(s) discussed above, the base station <NUM>-<NUM> may include a security configuration (indicating the long MAC-I format) in that additional RRC Reconfiguration message, and transmits that additional RRC Reconfiguration message to the UE <NUM> in a PDCP PDU (e.g., before transmission <NUM> occurs).

In some implementations, if the base station <NUM>-<NUM> fails to successfully verify the long MAC-I for a data packet received over the DRB, the base station <NUM>-<NUM> transmits an RRC Release message to the UE <NUM> to terminate the connection between the UE <NUM> and the base station <NUM>-<NUM>. In an alternative implementation, if the base station <NUM>-<NUM> fails to successfully verify the long MAC-I for a data packet received over the DRB, the base station <NUM>-<NUM> ignores the data packet. In this alternative implementation, however, if the base station <NUM>-<NUM> fails to successfully verify the long MAC-I for multiple data packets received over the DRB (e.g., some threshold number of data packets predetermined by the base station <NUM>-<NUM>), the base station <NUM>-<NUM> transmits an RRC Release message to the UE <NUM> terminate the connection between the UE <NUM> and the base station <NUM>-<NUM>. Depending on the implementation, the base station <NUM>-<NUM> may only transmit the RRC Release message if the base station <NUM>-<NUM> receives the multiple data packets consecutively, or may transmit the RRC Release message regardless of whether the base station <NUM>-<NUM> receives the multiple data packets consecutively.

Moreover, in some implementations, the base station <NUM>-<NUM> may configure the UE <NUM> to use the long MAC-I format for the SRB(s) and DRB(s) simultaneously, as shown in the example implementation and scenario of <FIG> and <FIG>. In <FIG> and <FIG>, a messaging diagram <NUM> depicts example messages that may be exchanged between the UE <NUM>, base station <NUM>-<NUM> and 5GC <NUM> of <FIG>, according to another implementation and/or scenario. The actions and messages shown in <FIG> and <FIG> may be similar or identical to the corresponding actions and messages shown in <FIG> and <FIG> (e.g., with <NUM> of <FIG> corresponding to <NUM> of <FIG>, and <NUM> of <FIG> corresponding to <NUM> of <FIG>, etc.), with the exception that: (<NUM>) the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I format for both the SRB(s) and DRB(s) in the messaging diagram <NUM> (rather than just DRB); (<NUM>) the RRC Reconfiguration message transmitted <NUM> in the messaging diagram <NUM> includes a security configuration indicating the long MAC-I format for both the SRB(s) and DRB(s) (rather than just DRB); (<NUM>) the PDCP PDU containing the RRC Reconfiguration Complete message (in transmission <NUM>) includes a long MAC-I (rather than a short MAC-I); and (<NUM>) the base station verifies <NUM> a long MAC-I (rather than a short MAC-I) in the PDCP PDU containing the RRC Reconfiguration Complete message.

As noted above, the base station <NUM>-<NUM> may, in some implementations, need to learn the MAC-I length capabilities of the UE <NUM> before attempting to configure the UE <NUM> to use the long MAC-I format. For example, the UE <NUM> may transmit the UE capability information indicating that the UE <NUM> supports the long MAC-I format to the base station <NUM>-<NUM>, or to the 5GC <NUM>. The base station <NUM>-<NUM> may forward the UE capability information from the UE <NUM> to the core network, for example. In some implementations and/or scenarios, the base station <NUM>-<NUM> receives UE capability information indicating support of the long MAC-I format from the UE <NUM> or the 5GC <NUM> (e.g., from an Access and Mobility Management Function (AMF)), before transmitting <NUM> an RRC Reconfiguration message configuring the long MAC-I format to the UE <NUM> (e.g., as described previously).

UE capability information transmitted by the UE <NUM> may have the same format as UE capability information received by the base station <NUM>-<NUM>, for example, or may have a different format. The base station <NUM>-<NUM> may determine to configure the long MAC-I format in response to determining that the UE capability information indicates the UE <NUM> supports the long MAC-I. If the UE <NUM> instead were to indicate no support of the long MAC-I (or the base station simply does not receive an indication of support by the UE <NUM> for the long MAC-I), the base station <NUM>-<NUM> may not determine to configure the long MAC-I format to the UE <NUM>, or may explicitly determine not to configure the long MAC-I to the UE <NUM>. In other implementations and/or scenarios, the 5GC <NUM> may send a network interface message to configure the base station <NUM>-<NUM> to use the long MAC-I format for the UE <NUM>, in response to the 5GC <NUM> determining that the UE capability information indicates the UE <NUM> supports the long MAC-I.

<FIG> depicts a messaging diagram <NUM> corresponding to one implementation and scenario in which the base station <NUM>-<NUM>, which may be a gNB or an ng-eNB, learns the capabilities of the UE <NUM>. In the messaging diagram <NUM>, the UE <NUM> enters <NUM> an RRC_CONNECTED state. The PDCP controller <NUM> of base station <NUM>-<NUM> generates a PDCP PDU containing a UE Capability Enquiry message to query the <NUM> NR capability of the UE <NUM>, and also containing a short MAC-I. The base station <NUM>-<NUM> transmits <NUM> the PDCP PDU containing the UE Capability Enquiry message and the short MAC-I to the UE <NUM>.

In response, if the UE <NUM> successfully verifies the short MAC-I in the PDCP PDU containing the UE Capability Enquiry message, the UE <NUM> transmits <NUM> to the base station <NUM>-<NUM> a UE Capability Information message contained in a PDCP PDU that also contains a short MAC-I computed by PDCP controller <NUM>. The UE Capability Information message includes a UE-NR-Capability information element. In the depicted scenario, the UE-NR-Capability information element indicates that the UE <NUM> supports the long MAC-I format.

After successfully verifying the short MAC-I appended to the UE Capability Information message, and identifying the UE-NR-Capability information element in that message, the base station <NUM>-<NUM> includes the UE-NR-Capability information element in a network interface message (e.g., a Next Generation Application Protocol (NGAP) message or a UE RADIO CAPABILITY INFO INDICATION message), and transmits <NUM> the message to the 5GC <NUM>. In other implementations, the base station <NUM>-<NUM> receives from the 5GC <NUM> a network interface message (e.g., an NGAP message or an INITIAL CONTEXT SETUP REQUEST message) indicating UE support of the long MAC-I format, or configuring communications between the UE <NUM> and base station <NUM>-<NUM> to the long MAC-I.

In an alternative implementation and/or scenario, the UE <NUM> includes UE capability information indicating support of the long MAC-I format in a Registration Request message, and transmits the Registration Request message to the 5GC <NUM> via a base station (i.e., via the base station <NUM>-<NUM> or another base station such as base station <NUM>-<NUM>) when the UE <NUM> registers to the 5GC <NUM>, at a time before transmitting the RRC Setup Request message as described elsewhere in this disclosure (e.g., with respect to transmission <NUM>, <NUM> or <NUM>), at a time before receiving the RRC Reconfiguration message configuring the long MAC-I format to the UE <NUM> as described elsewhere in this disclosure (e.g., with respect to transmission <NUM>, <NUM> or <NUM>), or along with the RRC Setup Complete message as described elsewhere in this disclosure (e.g., by including the Registration Request message in transmission <NUM>, <NUM> or <NUM>). Thereafter, the 5GC <NUM> transmits the network interface message, including an information element (e.g., a UE Security Capabilities information element) indicating support of the long MAC-I format for the UE <NUM>, to the base station <NUM>-<NUM> when the UE <NUM> connects to the 5GC <NUM> via the base station <NUM>-<NUM>.

In another implementation and/or scenario, the 5GC <NUM> receives from a base station (i.e., the base station <NUM>-<NUM> or another base station such as base station <NUM>-<NUM>) a UE-NR-Capability information element that includes UE capability information indicating support of the long MAC-I format. The transmitting base station may include the UE-NR-Capability information element in a UE RADIO CAPABILITY INFO INDICATION message, for example.

<FIG> depicts a messaging diagram <NUM> that reflects one example implementation and scenario in which the 5GC <NUM> has already learned the UE capability information in such a manner. As seen in <FIG>, after the UE <NUM> enters <NUM> the RRC_IDLE stage, the UE <NUM> transmits <NUM> the RRC Setup Request message to the base station <NUM>-<NUM>, the base station <NUM>-<NUM> transmits <NUM> the RRC Setup message to the UE <NUM>, the UE <NUM> enters <NUM> the RRC_CONNECTED state, and the UE <NUM> transmits <NUM> a PDCP PDU containing the RRC Setup Complete message and a short MAC-I to the base station <NUM>-<NUM>, as described above for other implementations.

In one implementation the 5GC <NUM>, which has already learned the UE capability information as described above, determines <NUM> to configure the base station <NUM>-<NUM> to use a long MAC-I format (with respect to communications with the UE <NUM>). The 5GC <NUM> then transmits <NUM> a message (e.g., an NGAP message such as an INITIAL CONTEXT SETUP REQUEST message) to the base station <NUM>-<NUM> when the UE <NUM> connects to the 5GC <NUM> via the base station <NUM>-<NUM>. The message indicates/instructs (e.g., in a long MAC-I configuration information element) that the base station <NUM>-<NUM> is to configure to use the long MAC-I format for communications with the UE <NUM>. By analyzing/processing this message, the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I format, and (not shown in <FIG>) may transmit a network interface message to configure the base station <NUM>-<NUM> to use to long MAC-I format.

In an alternative implementation and/or scenario, the 5GC <NUM> does not determine <NUM> to configure the base station <NUM>-<NUM> to a long MAC-I format with respect to communications with the UE <NUM>. Instead, the 5GC <NUM> merely transmits <NUM> an indication (e.g., in a capability information element such as a UE-NR-Capability information element or a UE Security Capabilities information element in an NGAP message) that the UE <NUM> supports the long MAC-I format, and the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I format based on that indication.

<FIG> show various implementations and/or scenarios for configuring the UE <NUM> to use the long MAC-I format when the 5GC <NUM> either (<NUM>) configures the base station <NUM>-<NUM> to use the long MAC-I format for communications with the UE <NUM>, or (<NUM>) indicates UE support for the long MAC-I format so that the base station <NUM>-<NUM> itself can decide to use the long MAC-I format for communications with the UE <NUM>.

Referring first to <FIG> and <FIG>, after the UE <NUM> enters <NUM> the RRC_IDLE stage, the UE <NUM> transmits <NUM> the RRC Setup Request message to the base station <NUM>-<NUM>, the base station <NUM>-<NUM> transmits <NUM> the RRC Setup message to the UE <NUM>, the UE <NUM> enters <NUM> the RRC_CONNECTED state, and the UE <NUM> transmits <NUM> a PDCP PDU containing the RRC Setup Complete message and a short MAC-I to the base station <NUM>-<NUM>, as described above for other implementations (e.g., with respect to <FIG> and <FIG>).

In one implementation and/or scenario, at some point before, during, or after the transmission <NUM>, the 5GC <NUM> determines <NUM> to configure the base station <NUM>-<NUM> to use the long MAC-I format (for purposes of communications with the UE <NUM>). The 5GC <NUM> may have learned that the UE <NUM> supports the long MAC-I format in any of the ways discussed above (e.g., as discussed above in connection with <FIG> or <FIG>), for example. The 5GC <NUM> then transmits <NUM> a message (e.g., an NGAP message such as an INITIAL CONTEXT SETUP REQUEST message) to the base station <NUM>-<NUM> when the UE <NUM> connects to the 5GC <NUM> via the base station <NUM>-<NUM>. The message indicates/instructs (e.g., in a long MAC-I configuration information element) that the base station <NUM>-<NUM> is to configure to use the long MAC-I format for communications with the UE <NUM>. By analyzing/processing this message, the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I format.

In an alternative implementation and/or scenario, the 5GC <NUM> does not determine <NUM> to configure the base station <NUM>-<NUM> to use a long MAC-I format with respect to communications with the UE <NUM>. Instead, after receiving an indication (e.g., in a capability information element such as a UE-NR-Capability information element or a UE Security Capabilities information element) that the UE <NUM> supports the long MAC-I format (e.g., from base station <NUM>-<NUM>), the 5GC <NUM> merely transmits <NUM> an indication that the UE <NUM> supports the long MAC-I format, and the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I format based on that indication.

In other scenarios, where the 5GC <NUM> does not transmit <NUM> either the indication of UE support for the long MAC-I format or an instruction to configure to use the long MAC-I format, the base station <NUM>-<NUM> does not configure to use the long MAC-I format, and does not configure the UE <NUM> to use the long MAC-I format. Alternatively, in such a scenario, the base station <NUM>-<NUM> may transmit a UE Capability Enquiry message to the UE <NUM>, and receive in response a UE Capability Information message from the UE <NUM>, e.g., as discussed above in connection with <FIG>.

Returning to the scenario of <FIG> and <FIG>, after the base station <NUM>-<NUM> determines <NUM> to configure use to the long MAC-I format, the PDCP controller <NUM> of base station <NUM>-<NUM> generates a PDCP PDU containing a Security Mode Command message and a short MAC-I. The Security Mode Command message includes an indication that the UE <NUM> is to configure to use the long MAC-I format for communications with the base station <NUM>-<NUM>. The PDCP controller <NUM> may compute the short MAC-I using any algorithm and key discussed above (e.g., the integrityProtAlgorithm and KRRCint key), for example. The base station <NUM>-<NUM> transmits <NUM> the PDCP PDU containing the Security Mode Command message and the short MAC-I to the UE <NUM>, and the UE <NUM> verifies <NUM> the short MAC-I using the same algorithm and key.

After successful verification of the short MAC-I, the PDCP controller <NUM> of UE <NUM> generates a PDCP PDU containing a Security Mode Complete message and a long MAC-I. The PDCP controller <NUM> may compute the long MAC-I using any algorithm and key discussed above (e.g., the integrityProtAlgorithm and KRRCint key), for example. The UE <NUM> transmits <NUM> the PDCP PDU containing the Security Mode Complete message and the long MAC-I to the base station <NUM>-<NUM>, and the base station <NUM>-<NUM> verifies <NUM> the long MAC-I using the same algorithm and key.

Later, in the example scenario of <FIG> and <FIG>, the PDCP PDU controller <NUM> of base station <NUM>-<NUM> generates a PDCP PDU containing an RRC Reconfiguration message and a long MAC-I, and the base station <NUM>-<NUM> transmits <NUM> the PDCP PDU to the UE <NUM>. The RRC Reconfiguration message may include the same fields as the RRC Reconfiguration message of transmission <NUM> in messaging diagram <NUM> of <FIG>, for example. After the UE <NUM> verifies <NUM> the long MAC-I for the RRC Reconfiguration message, the PDCP controller <NUM> of UE <NUM> may generate a PDCP PDU containing an RRC Reconfiguration Complete message and a long MAC-I, and the UE <NUM> may transmit <NUM> the PDCP PDU to the base station <NUM>-<NUM>. At some time after the base station <NUM>-<NUM> verifies <NUM> the long MAC-I for the RRC Reconfiguration Complete message, the PDCP controller <NUM> of UE <NUM> may generate a PDCP PDU containing a Measurement Report message and a long MAC-I, and the UE <NUM> may transmit <NUM> the PDCP PDU to the base station <NUM>-<NUM>. The base station <NUM>-<NUM> then verifies <NUM> the long MAC-I for the Measurement Report message.

<FIG> and <FIG> depict a messaging diagram <NUM> reflecting an implementation and scenario in which the base station <NUM>-<NUM> configures the UE <NUM> to use the long MAC-I format for one or more SRBs and one or more DRBs in a Security Mode Command message. In the messaging diagram <NUM>, after the UE <NUM> enters <NUM> the RRC_IDLE stage, the UE <NUM> transmits <NUM> the RRC Setup Request message to the base station <NUM>-<NUM>, the base station <NUM>-<NUM> transmits <NUM> the RRC Setup message to the UE <NUM>, the UE <NUM> enters <NUM> the RRC_CONNECTED state, and the UE <NUM> transmits <NUM> a PDCP PDU containing the RRC Setup Complete message and a short MAC-I to the base station <NUM>-<NUM>, as described above for other implementations (e.g., with respect to <FIG> and <FIG>).

In one implementation and/or scenario, at some point before, during or after the transmission <NUM>, the 5GC <NUM> determines <NUM> to configure the base station <NUM>-<NUM> to the long MAC-I format (for purposes of communications with the UE <NUM>). The 5GC <NUM> may have learned that the UE <NUM> supports the long MAC-I format in any of the ways discussed above (e.g., as discussed above in connection with <FIG> or <FIG>), for example. The 5GC <NUM> then transmits <NUM> a message (e.g., an NGAP message such as an INITIAL CONTEXT SETUP REQUEST message) to the base station <NUM>-<NUM> when the UE <NUM> connects to the 5GC <NUM> via the base station <NUM>-<NUM>. The message indicates/instructs (e.g., in a long MAC-I configuration information element) that the base station <NUM>-<NUM> is to configure to use the long MAC-I format for communications with the UE <NUM>. By analyzing/processing this message, the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I format.

In an alternative implementation and/or scenario, the 5GC <NUM> does not determine <NUM> to configure the base station <NUM>-<NUM> to use a long MAC-I format with respect to communications with the UE <NUM>. Instead, after receiving an indication (e.g., in a capability information element such as a UE-NR-Capability information element or a UE Security Capabilities information element in an NGAP message) that the UE <NUM> supports the long MAC-I format (e.g., from base station <NUM>-<NUM>), the 5GC <NUM> merely transmits <NUM> an indication that the UE <NUM> supports the long MAC-I format to the base station <NUM>-<NUM>, and the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I format based on that indication.

Returning the scenario of <FIG> and <FIG>, after the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I format, the PDCP controller <NUM> of base station <NUM>-<NUM> generates a PDCP PDU containing a Security Mode Command message and a short MAC-I. The Security Mode Command message includes an indication that the UE <NUM> is to configure to use the long MAC-I format for communications with the base station <NUM>-<NUM>. The PDCP controller <NUM> may compute the short MAC-I using any algorithm and key discussed above (e.g., the integrityProtAlgorithm and KRRCint key), for example. The base station <NUM>-<NUM> transmits <NUM> the PDCP PDU containing the Security Mode Command message and the short MAC-I to the UE <NUM>, and the UE <NUM> verifies <NUM> the short MAC-I using the same algorithm and key.

Later, in the example scenario of <FIG> and <FIG>, the PDCP PDU controller <NUM> of base station <NUM>-<NUM> generates a PDCP PDU containing an RRC Reconfiguration message and a long MAC-I. The RRC Reconfiguration message include an information element indicating that the UE <NUM> is to enable integrity protection for a DRB (or, in some implementations, more than one DRB). The base station <NUM>-<NUM> transmits <NUM> the PDCP PDU to the UE <NUM>. After the UE <NUM> verifies <NUM> the long MAC-I, the UE <NUM> enables integrity protection for the DRB(s), and the PDCP controller <NUM> of UE <NUM> may generate a PDCP PDU containing a data packet and a long MAC-I. The UE <NUM> transmits <NUM> the PDCP PDU to the base station <NUM>-<NUM> over a DRB, and the base station <NUM>-<NUM> verifies <NUM> the long MAC-I for the data packet. The base station <NUM>-<NUM> may then transmit <NUM> the data packet to the 5GC <NUM>.

In the example scenario of <FIG> and <FIG>, the 5GC <NUM> then transmits <NUM> another data packet (e.g., data relating to layers <NUM>) for the DRB to the base station <NUM>-<NUM>. The PDCP controller <NUM> of the base station <NUM>-<NUM> then generates a PDCP PDU containing a data packet and a long MAC-I. The data packet may be an IP packet, for example. The PDCP controller <NUM> may compute the long MAC-I for the PDCP PDU using the same integrity protection algorithm that was indicated by the field of the Security Mode Command message, and possibly also the same key associated with the algorithm (e.g., the KRRCint key), in some implementations and/or scenarios. If the security configuration and/or RRC Reconfiguration message indicated a different algorithm for integrity protection, however, the PDCP controller <NUM> may use that algorithm (e.g., with the KRRCint key). The base station <NUM>-<NUM> then transmits <NUM> the PDCP PDU containing the data packet and the long MAC-I over the DRB, and the UE <NUM> verifies <NUM> the long MAC-I of the PDCP PDU (i.e., by computing a long XMAC-I and comparing to the received long MAC-I). In some embodiments and/or scenarios, the UE <NUM> and base station <NUM>-<NUM> may instead generate SDAP PDUs for the DRB (e.g., as discussed above in connection with <FIG> and <FIG>).

<FIG> and <FIG> depict a messaging diagram <NUM> reflecting an implementation and scenario in which the base station <NUM>-<NUM> configures the UE <NUM> to use the long MAC-I format for one or more SRBs in a Security Mode Command message. In the messaging diagram <NUM>, after the UE <NUM> enters <NUM> the RRC_IDLE stage, the UE <NUM> transmits <NUM> the RRC Setup Request message to the base station <NUM>-<NUM>, the base station <NUM>-<NUM> transmits <NUM> the RRC Setup message to the UE <NUM>, the UE <NUM> enters <NUM> the RRC_CONNECTED state, and the UE <NUM> transmits <NUM> a PDCP PDU containing the RRC Setup Complete message and a short MAC-I to the base station <NUM>-<NUM>, as described above for other implementations (e.g., with respect to <FIG> and <FIG>).

In one implementation and/or scenario, at some point before, during or after the transmission <NUM>, the 5GC <NUM> determines <NUM> to configure the base station <NUM>-<NUM> to the long MAC-I format (for purposes of communications with the UE <NUM>). The 5GC <NUM> may have learned that the UE <NUM> supports the long MAC-I format in any of the ways discussed above (e.g., as discussed above in connection with <FIG> or <FIG>), for example. The 5GC <NUM> then transmits <NUM> a message (e.g., an NGAP message such as an INITIAL CONTEXT SETUP REQUEST message) to the base station <NUM>-<NUM> when the UE <NUM> connects to the 5GC <NUM> via the base station <NUM>-<NUM>. The message indicates/instructs (e.g., in a long MAC-I configuration information element) that the base station <NUM>-<NUM> is to configure to use the long MAC-I format for communications with the UE <NUM> over one or more SRBs. By analyzing/processing this message, the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I format for the SRB(s).

In an alternative implementation and/or scenario, the 5GC <NUM> does not determine <NUM> to configure the base station <NUM>-<NUM> to use a long MAC-I format with respect to communications over the SRB(s) with the UE <NUM>. Instead, after receiving an indication that the UE <NUM> supports the long MAC-I format (e.g., from base station <NUM>-<NUM>), the 5GC <NUM> merely transmits <NUM> an indication (e.g., in a capability information element such as a UE-NR-Capability information element or a UE Security Capabilities information element in an NGAP message) that the UE <NUM> supports the long MAC-I format to the base station <NUM>-<NUM>, and the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I format for the SRB(s) based on that indication.

In other scenarios, where the 5GC <NUM> does not transmit <NUM> either the indication of UE support for the long MAC-I format or an instruction to configure to use the long MAC-I format, the base station <NUM>-<NUM> does not configure to use the long MAC-I format for the SRB(s), and does not configure the UE <NUM> to use the long MAC-I format for the SRB(s). Alternatively, in such a scenario, the base station <NUM>-<NUM> may transmit a UE Capability Enquiry message to the UE <NUM>, and receive in response a UE Capability Information message from the UE <NUM>, e.g., as discussed above in connection with <FIG>.

Returning the scenario of <FIG> and <FIG>, after the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I format for the SRB(s), the PDCP controller <NUM> of base station <NUM>-<NUM> generates a PDCP PDU containing a Security Mode Command message and a short MAC-I. The Security Mode Command message includes an indication that the UE <NUM> is to configure to use the long MAC-I format for communications with the base station <NUM>-<NUM> over the SRB(s). The PDCP controller <NUM> may compute the short MAC-I using any algorithm and key discussed above (e.g., the integrityProtAlgorithm and KRRCint key), for example. The base station <NUM>-<NUM> transmits <NUM> the PDCP PDU containing the Security Mode Command message and the short MAC-I to the UE <NUM>, and the UE <NUM> verifies <NUM> the short MAC-I using the same algorithm and key.

At some time before, during, or after the verification <NUM>, the 5GC <NUM> determines <NUM> to configure the base station <NUM>-<NUM> to the long MAC-I for a DRB, or for a PDU session (and thus, the DRB associated with the PDU session). The 5GC <NUM> then transmits <NUM> a message to the base station <NUM>-<NUM>, instructing the base station <NUM>-<NUM> to configure to use the long MAC-I format for the DRB or PDU session. In response, the base station <NUM>-<NUM> determines <NUM> to configure to use the long MAC-I for the DRB or PDU session. The PDCP PDU controller <NUM> of base station <NUM>-<NUM> then generates a PDCP PDU containing an RRC Reconfiguration message and a long MAC-I. The RRC Reconfiguration message include an information element indicating that the UE <NUM> is to enable integrity protection for the DRB or the PDU session. The base station <NUM>-<NUM> transmits <NUM> the PDCP PDU to the UE <NUM>.

After the UE <NUM> verifies <NUM> the long MAC-I, the UE <NUM> enables integrity protection for the DRB or PDU session. The PDCP controller <NUM> of UE <NUM> may then generate a PDCP PDU containing a data packet and a long MAC-I. The UE <NUM> transmits <NUM> the PDCP PDU to the base station <NUM>-<NUM> over the DRB (i.e., the specific DRB for which the UE <NUM> was configured, or a DRB associated with the PDU session for which the UE <NUM> was configured), and the base station <NUM>-<NUM> verifies <NUM> the long MAC-I for the data packet. The base station <NUM>-<NUM> may then transmit <NUM> the data packet to the 5GC <NUM>.

For one or more of the implementations and/or scenarios discussed above in connection with <FIG>, if the base station <NUM>-<NUM> configures the UE <NUM> to use the long MAC-I format in a Security Mode Command message or an RRC Reconfiguration message, the base station <NUM>-<NUM> may configure the UE <NUM> to reestablish PDCP for an SRB or a DRB in a Security Mode Command message or an RRC Reconfiguration message. After the base station <NUM>-<NUM> transmits the Security Mode Command message or RRC Reconfiguration message to the UE <NUM>, the UE <NUM> may respond by reestablishing a PDCP entity of the SRB or the DRB, for example. As used in this disclosure, "PDCP entity" refers to a task, a thread, or an application responsible for PDCP communications for a certain context. The base station <NUM>-<NUM> may reestablish a PDCP entity of the SRB or the DRB in response to configuring the UE <NUM> to reestablish the PDCP entity of the SRB. After reestablishing the PDCP entity, the UE <NUM> and the base station <NUM>-<NUM> may start using the long MAC-I format. In some implementations, the UE <NUM> and the base station <NUM>-<NUM> reset PDCP state variables of the PDCP entity to initial values in response to reestablishing the PDCP entity.

In other implementations and/or scenarios, in the same Security Mode Command message or RRC Reconfiguration message that configures the UE <NUM> to use the long MAC-I format, the base station <NUM>-<NUM> may configure the UE <NUM> to not reestablish the PDCP for an SRB or a DRB. In this case, the UE <NUM> does not reestablish a PDCP entity of the SRB or the DRB in response to the Security Mode Command message or RRC Reconfiguration message, and the base station <NUM>-<NUM> does not reestablish a PDCP entity of the SRB or the DRB. The UE <NUM> may start using the long MAC-I format when transmitting a Security Mode Complete message or RRC Reconfiguration Complete message to the base station <NUM>-<NUM>. The base station <NUM>-<NUM> may start using the long MAC-I format when receiving the Security Mode Complete message or the RRC Reconfiguration Complete message from the UE <NUM>. In some implementations, the UE <NUM> and the base station <NUM>-<NUM> do not reset PDCP state variables of the PDCP entity to initial values if not reestablishing the PDCP entity.

In some implementations and/or scenarios, after the base station <NUM>-<NUM> configures the UE <NUM> to use the long MAC-I format (e.g., as described above) for a session, the base station <NUM>-<NUM> is not permitted to reconfigure the UE <NUM> to use the short MAC-I format during that session.

Referring now to <FIG>, an example method <NUM> for enhancing integrity protection can be implemented in a user device that supports a plurality of MAC lengths, such as the UE <NUM> of <FIG>, for example.

At block <NUM> of the method <NUM>, the user device receives a first message, including an information element, from a base station (e.g., base station <NUM>-<NUM> of <FIG>). The first message may include an RRC message (e.g., an RRC Reconfiguration message), or a security Mode Command message, in which the information element is contained, for example. As a more specific example, the first message can be associated with the transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, or transmission <NUM> of <FIG>.

At block <NUM>, the user device determines, based on the information element, that a first MAC length (e.g., <NUM>-bit, <NUM>-bit, <NUM>-bit, or another suitable length), of a plurality of MAC lengths (e.g., two MAC lengths, or three MAC lengths, etc.), is to be used for integrity protection. The user device may make the determination at block <NUM> solely for user plane messages, solely for control plane messages, or for both user plane and control plane messages. In the examples above, the user device makes this determination at block <NUM>.

(<FIG>), block <NUM> (<FIG>), block <NUM> (<FIG>), block <NUM> (<FIG>), block <NUM> (<FIG>), or block <NUM> (<FIG>).

At block <NUM>, after making the determination at block <NUM>, the user device generates a second message including a MAC having the first MAC length. The MAC may be a MAC-I (i.e., an access stratum MAC), for example. Block <NUM> may include computing the MAC (e.g., using any of the types of integrity protection algorithms discussed above) and appending the MAC to payload in the second message, for example. In addition to the MAC, the second message may include an RRC message (e.g., an RRC Reconfiguration Complete message), for example.

At block <NUM>, the user device transmits the second message to the base station, e.g., transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, or transmission <NUM> of <FIG>. If the determination at block <NUM> was for (at least) user plane messages, then block <NUM> may include generating a data packet, and block <NUM> may include transmitting the second message (with data packet and MAC) over a DRB.

In some implementations and/or scenarios, the method <NUM> includes one or more additional blocks not shown in <FIG>. For example, the method <NUM> may include additional blocks, occurring after block <NUM>, in which the user device computes an expected MAC having a second MAC length (e.g., <NUM> bits, or another suitable length) of the plurality of MAC lengths, and compares the expected MAC to a MAC in the first message to verify that the MAC in the first message is a valid MAC. The user device may compute the expected MAC using any of the types of integrity protection algorithms discussed above, for example. The second MAC length may be shorter than the first MAC length, for example.

As another example, in an implementation and/or scenario where the determination at block <NUM> was for user plane messages, the method <NUM> may include additional blocks in which the user device generates a third message that includes an RRC message (e.g., an RRC Reconfiguration Complete message) and a MAC having the second MAC length, and in which the user device transmits the third message to the base station, e.g., transmission <NUM> of <FIG>.

As another example, in an implementation and/or scenario where the determination at block <NUM> was for both user plane and control plane messages, the method <NUM> may include additional blocks in which the user device generates a third message that includes an RRC message (e.g., an RRC Reconfiguration Complete message) and a MAC having the first MAC length, and in which the user device transmits the third message to the base station, e.g., transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, or transmission <NUM> of <FIG>.

As another example, in an implementation and/or scenario where the determination at block <NUM> was for control plane messages, the method <NUM> may include additional blocks in which (<NUM>) the user device receives a third message including both a second RRC message (e.g., an RRC Reconfiguration message) containing another information element, and a MAC having the first MAC length; (<NUM>) the user device computes an expected MAC having the first MAC length (e.g., using any of the types of integrity protection algorithms discussed above); (<NUM>) compares the expected MAC to the received MAC to verify that the received MAC is valid; (<NUM>) determines, based on the information element in the second RRC message, that integrity protection is to be enabled for user plane messages; and (<NUM>) transmits the additional message to the base station. For example, the user device can generate transmission <NUM> of <FIG>.

In some implementations and/or scenarios, the user device, prior to receiving the first message at block <NUM>, receives a message requesting capabilities of the user device (e.g., an RRC UE Capability Enquiry message) from the base station (e.g., transmission <NUM> of <FIG>), and in response transmits to the base station a message including an information element indicating that the user device supports the first MAC length (e.g., an RRC UE Capability Information message), e.g., transmission <NUM> of <FIG>.

<FIG> depicts an example method <NUM> for enhancing integrity protection that can be implemented in a base station that supports a plurality of MAC lengths, such as the base station <NUM>-<NUM> of <FIG>, for example. The base station may implement the method <NUM> while a user device (e.g., the UE <NUM> of <FIG>) implements the method <NUM>, for example.

At block <NUM> of the method <NUM>, the base station determines that a first MAC length (e.g., <NUM>-bit, <NUM>-bit, <NUM>-bit, or another suitable length), of a plurality of MAC lengths (e.g., two MAC lengths, or three MAC lengths, etc.), is to be used for integrity protection. Examples of this determination includes block <NUM> of <FIG>, block <NUM> of <FIG>, block <NUM> of <FIG>, block <NUM> of <FIG>, block <NUM> of <FIG>, block <NUM> of <FIG>, and block <NUM> of <FIG>. Block <NUM> may include transmitting to the user device a message requesting capabilities of the user device (e.g., an RRC UE Capability Enquiry message), and in response receiving from the user device a message including an information element indicating that the user device supports the first MAC length (e.g., an RRC UE Capability Information message), for example. As a more specific example, this message can be associated with transmission <NUM> of <FIG>. Alternatively, block <NUM> may include receiving, from a core network (e.g., from the 5GC <NUM>), either an indication that the user device supports the first MAC length, or a command to use (i.e., configure to) the first MAC length (e.g., transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, or transmission <NUM> of <FIG>).

At block <NUM>, the base station generates a first message that includes an information element indicating that the first MAC length is to be used for integrity protection. Block <NUM> may include computing a MAC having a second MAC length of the plurality of MAC lengths (e.g., shorter than the first MAC length), and appending that MAC to payload in the first message. The base station may compute the MAC using any of the types of integrity protection algorithms discussed above, for example.

At block <NUM>, the base station transmits the first message to a user device (e.g., the UE <NUM>). The first message may include an RRC message (e.g., an RRC Reconfiguration message) or a Security Mode Command message, for example, and possibly also a MAC having the second (e.g., shorter) MAC length. For example, this message can be associated with the transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, or transmission <NUM> of <FIG>.

At block <NUM>, after transmitting the first message at block <NUM>, the base station receives, from the user device, a second message including a MAC (e.g., reception by the base station of transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, transmission <NUM> of <FIG>, or transmission <NUM> of <FIG>). The MAC may be a MAC-I (i.e., an access stratum MAC), for example. At block <NUM>, the base station computes an expected MAC having the first MAC length (e.g., using any of the types of integrity protection algorithms discussed above). The expected MAC may be an XMAC-I (i.e., an access stratum XMAC), for example. At block <NUM>, the base station compares the expected MAC to the MAC in the second message to verify that the MAC in the second message is a valid MAC (e.g., verification <NUM> of <FIG>, verification <NUM> of <FIG>, verification <NUM> of <FIG>, verification <NUM> of <FIG>, verification <NUM> of <FIG>, or verification <NUM> of <FIG>).

The following additional considerations apply to the foregoing discussion.

A user device in which the techniques of this disclosure can be implemented (e.g., the UE <NUM>) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (IoT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc..

Certain implementations are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.

Claim 1:
A method performed by a user device (<NUM>) that supports a plurality of message authentication code, MAC, lengths for integrity protection of wireless communications, the method comprising:
receiving (<NUM>), from a base station (<NUM>-<NUM>), a first message (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) including i) an information element indicating a first MAC length of the plurality of MAC lengths and ii) a MAC having a second MAC length of the plurality of MAC lengths;
when the information element indicates that the first MAC length is to be used for integrity protection, generating (<NUM>) a second message (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) including a MAC having the first MAC length; and
transmitting (<NUM>) the second message (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) to the base station (<NUM>-<NUM>).