Patent Description:
Wireless communication systems are rapidly growing in usage. Wireless devices, particularly wireless user equipment devices (UEs), have become widespread. Additionally, there are a variety of applications (or apps) hosted on UEs that perform or depend on wireless communication, such as applications that provide messaging, email, browsing, video streaming, short video, voice streaming, real-time gaming, or various other online services.

In some instances, a UE may suspend or release a connection with a network. Messages related to resuming a connection may be vulnerable to man in the middle (MiTM) attacks. Accordingly, improvements in the field may be desired.

An apparatus and methods are disclosed for a user equipment device (UE) and cellular network to resume a suspended or released connection (e.g., a radio resource control (RRC) connection). A UE and/or network may determine support for exchanging messages (e.g., RRCResumeRequest) relating to resuming a connection using a new format. After determining support, the connection may be released/suspended. The UE may transmit a message to the network in order to resume/reestablish the connection.

A better understanding of the disclosed embodiments can be obtained when the following detailed description is considered in conjunction with the following drawings, in which:.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications falling within the scope of the present invention as defined by the appended claims.

The following acronyms may be used in the present Patent Application:.

Such descriptions should be interpreted as including the phrase "configured.

As shown, the example wireless communication system includes a base station <NUM> which communicates over a transmission medium with one or more user devices 106A, 106B, etc., through 106N.

The base station (BS) <NUM> may be a base transceiver station (BTS) or cell site (a "cellular base station"), and may include hardware that enables wireless communication with the UEs 106A through 106N.

The communication area (or coverage area) of the base station may be referred to as a "cell. " The base station <NUM> and the UEs <NUM> may be configured to communicate over the transmission medium using any of various radio access technologies (RATs), also referred to as wireless communication technologies, or telecommunication standards, such as GSM, UMTS (associated with, for example, WCDMA or TD-SCDMA air interfaces), LTE, LTE-Advanced (LTE-A), <NUM> new radio (<NUM> NR), HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), etc. Note that if the base station <NUM> is implemented in the context of LTE, it may alternately be referred to as an 'eNodeB' or 'eNB'. Note that if the base station <NUM> is implemented in the context of <NUM> NR, it may alternately be referred to as 'gNodeB' or 'gNB'.

As shown, the base station <NUM> may also be equipped to communicate with a network <NUM> (e.g., a core network of a cellular service provider, a telecommunication network such as a public switched telephone network (PSTN), and/or the Internet, among various possibilities). Thus, the base station <NUM> may facilitate communication between the user devices and/or between the user devices and the network <NUM>. In particular, the cellular base station <NUM> may provide UEs <NUM> with various telecommunication capabilities, such as voice, SMS and/or data services.

Base station <NUM> and other similar base stations operating according to the same or a different cellular communication standard may thus be provided as a network of cells, which may provide continuous or nearly continuous overlapping service to UEs 106A-N and similar devices over a geographic area via one or more cellular communication standards.

Thus, while base station <NUM> may act as a "serving cell" for UEs 106A-N as illustrated in <FIG>, each UE <NUM> may also be capable of receiving signals from (and possibly within communication range of) one or more other cells (which might be provided by other base stations 102B-N), which may be referred to as "neighboring cells".

In some embodiments, a gNB may be connected to a legacy evolved packet core (EPC) network and/or to a NR core (NRC) network. In addition, a gNB cell may include one or more transition and reception points (TRPs).

Note that a UE <NUM> may be capable of communicating using multiple wireless communication standards. For example, the UE <NUM> may be configured to communicate using a wireless networking (e.g., Wi-Fi) and/or peer-to-peer wireless communication protocol (e.g., Bluetooth, Wi-Fi peer-to-peer, etc.) in addition to at least one cellular communication protocol (e.g., GSM, UMTS (associated with, for example, WCDMA or TD-SCDMA air interfaces), LTE, LTE-A, <NUM> NR, HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), etc.). The UE <NUM> may also or alternatively be configured to communicate using one or more global navigational satellite systems (GNSS, e.g., GPS or GLONASS), one or more mobile television broadcasting standards (e.g., ATSC-M/H), and/or any other wireless communication protocol, if desired. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible.

<FIG> illustrates user equipment <NUM> (e.g., one of the devices 106A through 106N) in communication with a base station <NUM>, according to some embodiments. The UE <NUM> may be a device with cellular communication capability such as a mobile phone, a hand-held device, a computer or a tablet, or virtually any type of wireless device.

The UE <NUM> may include one or more antennas for communicating using one or more wireless communication protocols or technologies. In some embodiments, the UE <NUM> may be configured to communicate using, for example, CDMA2000 (1xRTT / 1xEV-DO / HRPD / eHRPD) or LTE using a single shared radio and/or GSM or LTE using the single shared radio. The shared radio may couple to a single antenna, or may couple to multiple antennas (e.g., for multiple-input, multiple-output or "MIMO") for performing wireless communications. In general, a radio may include any combination of a baseband processor, analog RF signal processing circuitry (e.g., including filters, mixers, oscillators, amplifiers, etc.), or digital processing circuitry (e.g., for digital modulation as well as other digital processing). Similarly, the radio may implement one or more receive and transmit chains using the aforementioned hardware. For example, the UE <NUM> may share one or more parts of a receive and/or transmit chain between multiple wireless communication technologies, such as those discussed above.

In some embodiments, the UE <NUM> may include any number of antennas and may be configured to use the antennas to transmit and/or receive directional wireless signals (e.g., beams). Similarly, the BS <NUM> may also include any number of antennas and may be configured to use the antennas to transmit and/or receive directional wireless signals (e.g., beams). To receive and/or transmit such directional signals, the antennas of the UE <NUM> and/or BS <NUM> may be configured to apply different "weight" to different antennas. The process of applying these different weights may be referred to as "precoding".

In some embodiments, UE <NUM> may communicate (e.g., concurrently) with multiple BS <NUM>. One or more BS <NUM> may make up a radio access network (RAN).

<FIG> illustrates an example simplified block diagram of a communication device <NUM>, according to some embodiments. It is noted that the block diagram of the communication device of <FIG> is only one example of a possible communication device. According to embodiments, communication device <NUM> may be a user equipment (UE) device, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, notebook, or portable computing device), a tablet and/or a combination of devices, among other devices. As shown, the communication device <NUM> may include a set of components <NUM> configured to perform core functions. For example, this set of components may be implemented as a system on chip (SOC), which may include portions for various purposes. Alternatively, this set of components <NUM> may be implemented as separate components or groups of components for the various purposes. The set of components <NUM> may be coupled (e.g., communicatively; directly or indirectly) to various other circuits of the communication device <NUM>.

In some embodiments, as further described below, cellular communication circuitry <NUM> may include dedicated receive chains (including and/or coupled to, e.g., communicatively, directly or indirectly, dedicated processors and/or radios) for multiple RATs (e.g., a first receive chain for LTE and a second receive chain for <NUM> NR).

As shown, the SOC <NUM> may include processor(s) <NUM>, which may execute program instructions for the communication device <NUM> and display circuitry <NUM>, which may perform graphics processing and provide display signals to the display <NUM>. The processor(s) <NUM> may also be coupled to memory management unit (MMU) <NUM>, which may be configured to receive addresses from the processor(s) <NUM> and translate those addresses to locations in memory (e.g., memory <NUM>, read only memory (ROM) <NUM>, NAND flash memory <NUM>) and/or to other circuits or devices, such as the display circuitry <NUM>, short range wireless communication circuitry <NUM>, cellular communication circuitry <NUM>, connector I/F <NUM>, and/or display <NUM>. The MMU <NUM> may be configured to perform memory protection and page table translation or set up. In some embodiments, the MMU <NUM> may be included as a portion of the processor(s) <NUM>.

As noted above, the communication device <NUM> may be configured to communicate using wireless and/or wired communication circuitry. The communication device <NUM> may be configured to transmit a request to attach to a first network node operating according to the first RAT and transmit an indication that the wireless device is capable of maintaining substantially concurrent connections with the first network node and a second network node that operates according to the second RAT. The wireless device may also be configured transmit a request to attach to the second network node. The request may include an indication that the wireless device is capable of maintaining substantially concurrent connections with the first and second network nodes. Further, the wireless device may be configured to receive an indication that dual connectivity (DC) with the first and second network nodes has been established.

As described herein, the communication device <NUM> may include hardware and software components for implementing features for using multiplexing to perform transmissions according to multiple radio access technologies in the same frequency carrier (e.g., and/or multiple frequency carriers), as well as the various other techniques described herein. The processor <NUM> of the communication device <NUM> may be configured to implement part or all of the features described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively (or in addition), processor <NUM> may be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array), or as an ASIC (Application Specific Integrated Circuit). Alternatively (or in addition) the processor <NUM> of the communication device <NUM>, in conjunction with one or more of the other components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may be configured to implement part or all of the features described herein.

Further, as described herein, cellular communication circuitry <NUM> and short range wireless communication circuitry <NUM> may each include one or more processing elements and/or processors. In other words, one or more processing elements or processors may be included in cellular communication circuitry <NUM> and, similarly, one or more processing elements or processors may be included in short range wireless communication circuitry <NUM>. Thus, cellular communication circuitry <NUM> may include one or more integrated circuits (ICs) that are configured to perform the functions of cellular communication circuitry <NUM>. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, etc.) configured to perform the functions of cellular communication circuitry <NUM>. Similarly, the short range wireless communication circuitry <NUM> may include one or more ICs that are configured to perform the functions of short range wireless communication circuitry <NUM>. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, etc.) configured to perform the functions of short range wireless communication circuitry <NUM>.

The radio <NUM> and at least one antenna <NUM> may be configured to operate as a wireless transceiver and may be further configured to communicate with UE devices <NUM>. The antenna <NUM> may communicate with the radio <NUM> via communication chain <NUM>.

In addition, as described herein, processor(s) <NUM> may include one or more processing elements.

Further, as described herein, radio <NUM> may include one or more processing elements.

In some embodiments, a BS <NUM> may provide access to a cellular network via a 3GPP access and/or a non-3GPP access. In some embodiments, a BS <NUM> that provides a non-3GPP access may be referred to as an access point.

<FIG> illustrates an example simplified block diagram of cellular communication circuitry, according to some embodiments. It is noted that the block diagram of the cellular communication circuitry of <FIG> is only one example of a possible cellular communication circuit; other circuits, such as circuits including or coupled to sufficient antennas for different RATs to perform uplink activities using separate antennas, are also possible. According to embodiments, cellular communication circuitry <NUM> may be included in a communication device, such as communication device <NUM> described above. As noted above, communication device <NUM> may be a user equipment (UE) device, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, notebook, or portable computing device), a tablet and/or a combination of devices, among other devices.

The cellular communication circuitry <NUM> may couple (e.g., communicatively; directly or indirectly) to one or more antennas, such as antennas 335a-b and <NUM> as shown (in <FIG>). In some embodiments, cellular communication circuitry <NUM> may include dedicated receive chains (including and/or coupled to, e.g., communicatively, directly or indirectly, dedicated processors and/or radios) for multiple RATs (e.g., a first receive chain for LTE and a second receive chain for <NUM> NR). For example, as shown in <FIG>, cellular communication circuitry <NUM> may include a modem <NUM> and a modem <NUM>. Modem <NUM> may be configured for communications according to a first RAT, e.g., such as LTE or LTE-A, and modem <NUM> may be configured for communications according to a second RAT, e.g., such as <NUM> NR.

In some embodiments, a switch (e.g., and/or combiner, multiplexer, etc.) <NUM> may couple transmit circuitry <NUM> to uplink (UL) front end <NUM>.

In some embodiments, modem <NUM> and modem <NUM> may be configured to transmit at the same time, receive at the same time, and/or transmit and receive at the same time. Thus, when cellular communication circuitry <NUM> receives instructions to transmit according to both the first RAT (e.g., as supported via modem <NUM>) and the second RAT (e.g., as supported via modem <NUM>), combiner <NUM> may be switched to a third state that allows modems <NUM> and <NUM> to transmit signals according to the first and second RATs (e.g., via a transmit circuitry <NUM> and <NUM> and UL front end <NUM>). In other words, the modems may coordinate communication activity, and each may perform transmit and/or receive functions at any time, as desired.

In some embodiments, the cellular communication circuitry <NUM> may be configured to transmit, via the first modem while the switch is in the first state, a request to attach to a first network node operating according to the first RAT and transmit, via the first modem while the switch is in a first state, an indication that the wireless device is capable of maintaining substantially concurrent connections with the first network node and a second network node that operates according to the second RAT. The wireless device may also be configured transmit, via the second radio while the switch is in a second state, a request to attach to the second network node. The request may include an indication that the wireless device is capable of maintaining substantially concurrent connections with the first and second network nodes. Further, the wireless device may be configured to receive, via the first radio, an indication that dual connectivity with the first and second network nodes has been established.

As described herein, the modem <NUM> may include hardware and software components for implementing features for using multiplexing to perform transmissions according to multiple radio access technologies in the same frequency carrier, as well as the various other techniques described herein. The processors <NUM> may be configured to implement part or all of the features described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively (or in addition), processor <NUM> may be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array), or as an ASIC (Application Specific Integrated Circuit). Alternatively (or in addition) the processor <NUM>, in conjunction with one or more of the other components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> may be configured to implement part or all of the features described herein.

In some embodiments, processor(s) <NUM>, <NUM>, etc. may be configured to implement or support implementation of part or all of the methods described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively, the processor(s) <NUM>, <NUM>, etc. may be configured as a programmable hardware element, such as an FPGA, or as an ASIC, or a combination thereof. In addition, as described herein, processor(s) <NUM>, <NUM>, etc. may include one or more processing elements. Thus, processor(s) <NUM>, <NUM>, etc. may include one or more integrated circuits (ICs) that are configured to perform the functions of processor(s) <NUM>, <NUM>, etc. In addition, each integrated circuit may include circuitry (e.g., first circuitry, second circuitry, etc.) configured to perform the functions of processor(s) <NUM>, <NUM>, etc..

In some implementations, fifth generation (<NUM>) wireless communication will initially be deployed concurrently with other wireless communication standards (e.g., LTE). For example, whereas <FIG> illustrates a possible standalone (SA) implementation of a next generation core (NGC) network <NUM> and <NUM> NR base station (e.g., gNB <NUM>), dual connectivity between LTE and <NUM> new radio (<NUM> NR or NR), such as in accordance with the exemplary non-standalone (NSA) architecture illustrated in <FIG>, has been specified as part of the initial deployment of NR. Thus, as illustrated in <FIG>, evolved packet core (EPC) network <NUM> may continue to communicate with current LTE base stations (e.g., eNB <NUM>). In addition, eNB <NUM> may be in communication with a <NUM> NR base station (e.g., gNB <NUM>) and may pass data between the EPC network <NUM> and gNB <NUM>. In some instances, the gNB <NUM> may also have at least a user plane reference point with EPC network <NUM>. Thus, EPC network <NUM> may be used (or reused) and gNB <NUM> may serve as extra capacity for UEs, e.g., for providing increased downlink throughput to UEs. In other words, LTE may be used for control plane signaling and NR may be used for user plane signaling. Thus, LTE may be used to establish connections to the network and NR may be used for data services. As will be appreciated, numerous other non-standalone architecture variants are possible.

In some embodiments, a UE may transmit one or more messages to a network in order to reestablish or resume a previously suspended/released connection, e.g., an RRC connection. For example, the UE may use an RRCResumeRequest message for this purpose. Note that, as used herein, the term "RRCResumeRequest" may include similar messages such as RRCResumeRequest1, among others.

Various messages may be protected using one or more techniques. For example, authentication tokens such as media access control (MAC) tokens may be used to allow a receiver to verify a message, e.g., which may be based on the symmetric cryptography. A ResumeMAC-I or short ResumeMAC-I may be used to protect an RRCResumeRequest message, according to some embodiments. The sender (e.g., such as a UE <NUM>) and the receiver (e.g., such as a BS <NUM> such as a gNB) may share a same, shared key for this MAC-I. When the receiver gets this message with a ResumeMAC-I or short ResumeMAC-I, it may verify the MAC-I using the shared key. If the verification using the shared key is successful, the receiver may determine that the resume request message associated with the MAC-I is genuine. Otherwise, the message may be treated as a false one. Note that for purposes of conciseness, the term "ResumeMAC-I" as used herein may be understood to include a short ResumeMAC-I and/or a long/full ResumeMAC-I.

However, some fields, such as the resumecause field in the RRCResumeRequest message may not protected by the ResumeMAC-I, according to some embodiments. Thus, the integrity of the resumecause field in the RRCResumeRequest message may not be provided, e.g., this field may not be protected. Therefore, a man in the middle (MiTM) attack (e.g., by a false base station or false UE) may be possible, e.g., by modification of the resumecause from one value to another. This attack may harm the quality or type of service offered by the network to the UE. In addition, in <NUM>, "RAN update" may be added as another value of the resumecause field. If an attacker were to modify the resumecause field value from "emergency" to "ran update", the network may not be able to detect the attack. Further, the network may (e.g., immediately) send the UE back to INACTIVE (e.g., suspend/release the RRC connection) while the UE is waiting to establish an emergency call, for example.

In some proposals, e.g., according to 3GPP technical report (TR) <NUM>, the whole RRCResumeRequest should be taken as the input of the ResumeMAC-I. In other words, all fields of the RRCResumeRequest, including the resumecause field, may be input into the ResumeMAC-I, and may thus be protected. Thus, according to such proposals, a "new" ResumeMAC-I may take the whole RRCResumeRequest message as the input (e.g., for protection according to the token). Such a "new" ResumeMAC-I and/or a RRCResumeRequest message may be referred to as a fully protected connection resume message. In other words, a fully protected connection resume message may include the resume cause field as an input to the MAC-I token. All fields of theconnection resume message except the ResumeMAC-I part may be protected, according to some embodiments. In some embodiments, all of the fields of a fully protected connection resume message may be protected. In contrast, the "old" ResumeMAC-I may leave at least one field (e.g., the resume cause field, and/or one or more other fields) unprotected. The "old" ResumeMAC-I may only take the following inputs, e.g., consistent with 3GPP technical specification (TS) <NUM>, v. <NUM>, clause <NUM>: sourcePhysCellID, targetCellIdentity and source-c-RNTI. sourcePhysCellID may be set to the physical cell identity of the primary cell (PCell) the UE was connected to prior to suspension of the RRC connection. targetCellIdentity may be an input variable used to calculate the resumeMAC-I. It may be set to the cell identity of the first public land mobile network (PLMN) identity included in the PLMN-identityinfoList broadcast in a system information block (SIB), e.g., SIB1 of the target cell, e.g., the cell that the UE is trying to resume. source-C-RNTI may be set to the cell radio network temporary identifier (C-RNTI) that the UE had in the PCell it was connected to prior to suspension of the RRC connection. However, the whole procedure of such proposals, e.g., using the "new" ResumeMAC-I may not be clarified at this time.

<FIG> is a flow chart diagram illustrating an example method of protecting messages related to resuming a connection, according to some embodiments. Aspects of the method of <FIG> may be implemented by a UE <NUM> in communication with a cellular network <NUM> (e.g., including one or more BS <NUM>), as illustrated in and described with respect to the Figures, or more generally in conjunction with any of the computer circuitry, systems, devices, elements, or components shown in the Figures, among other devices, as desired. For example, a processor (or processors) of the UE (e.g., processor(s) <NUM>, processor(s) associated with communication circuitry <NUM> or <NUM> such as processor(s) <NUM> and/or <NUM>, etc.), base station (e.g., processor(s) <NUM>, or a processor associated with radio <NUM> and/or communication chain <NUM>, among various possibilities), or network element (e.g., any component of NGC <NUM>, EPC <NUM>, such as an AMF, N3IWF, etc.), may cause the UE, base station, and/or network element(s) to perform some or all of the illustrated method elements. For example, a baseband processor or application processor of the UE may cause the UE to perform some or all of the illustrated method elements. Note that while at least some elements of the method are described in a manner relating to the use of communication techniques and/or features associated with 3GPP specification documents, such description is not intended to be limiting to the disclosure, and aspects of the method may be used in any suitable wireless communication system, as desired. In various embodiments, some of the elements of the methods shown may be performed concurrently, in a different order than shown, may be substituted for by other method elements, or may be omitted. Additional method elements may also be performed as desired. As shown, the method may operate as follows.

A UE <NUM> may establish a connection with a network <NUM> (e.g. a PLMN, which may operate according to cellular standards such as NR) (<NUM>), according to some embodiments. The connection may include an RRC connection. The UE and network may exchange data and/or control information in the uplink and/or downlink directions.

The UE <NUM> and/or network <NUM> may release the connection (<NUM>), according to some embodiments. The UE or network may initiate the release. For example, the network may transmit an RRC release message to the UE causing the UE to release the connection. Such an RRC release message may include configuration information (e.g., SuspendConfig) related to the suspension of the connection. Among various possibilities, such configuration information may include information related to how the UE may resume the connection.

The UE <NUM> may determine whether and/or how the network (or one or more BS of the network) supports (e.g., and/or how the network has configured the UE to use) a resume request using a fully protected connection resume message (<NUM>), according to some embodiments. Such a determination may be made prior to establishing the connection (e.g., prior to starting the connection establishment process), concurrently with establishing the connection, after establishing the connection and prior to releasing the connection, concurrently with releasing the connection, or subsequently to releasing the connection, among various possibilities. In other words, <NUM> may occur before, after, or concurrently with either <NUM> or <NUM>, or may occur between <NUM> and <NUM>. Among various possibilities, the determination may be based on receiving an indication from the network or based on a response of the network to a message transmitted by the UE.

Three examples are provided below of the UE receiving an indication from the network of the network's support for (e.g., and/or configuration for the UE to use) a fully protected connection resume message. Such an indication may be transmitted by the network in the form of an information element (IE), e.g., a NewResumeMAC-I IE, a RRCResumeRequest IE, or a fully protected connection resume message IE, among various possibilities.

As a first example, the UE may receive one or more SIBs or other broadcasts transmitted by one or more BS of the network, and such a SIB or other broadcast may include an indication of the support of the network (or of the support of one or more BSs) for resume requests using a fully protected connection resume message. Among various possibilities, the UE may receive a SIB1 which may include an indication whether and/or how the network (or one or more BS of the network) supports resume requests using a fully protected connection resume message. Note that such an indication may be included in a different SIB (e.g., other than SIB1) or a master information block (MIB), among various possibilities. In some embodiments, the indication may be received prior to establishing an RRC connection. For example, the BS may periodically broadcast the indication, e.g., in a SIB. Such a SIB may be received prior to establishing an RRC connection, while an RRC connection is active, or after release of an RRC connection (e.g., by a UE entering an inactive or idle state). This example is further illustrated and described with respect to <FIG>.

As a second example, the UE may receive such an indication from the network at a time associated with releasing the connection. For example, the network may include such an indication at the time of or in association with a message releasing or suspending a connection. For example, an IE for such an indication may be included in or with an RRCRelease message, a suspension configuration (e.g., SuspendConfig), etc. This example is further illustrated and described with respect to <FIG>.

In the claimed invention, the UE receives an indication at multiple times. In the claimed invention, the network includes such an indication in a SIB broadcast and in an RRC release. In other words, the network includes the indication as described in both the first and second examples above. This allows the UE to mitigate the potential for a modification (e.g., a MiTM attack) of the SIB message. Thus, if the UE does not receive the indication in the RRC release (e.g., after receiving the indication in the SIB), the UE may determine that the network does not support the fully protected connection resume message (e.g., the UE may determine to use an old ResumeMAC-I). This example is further illustrated and described with respect to <FIG>.

As mentioned above, the UE may determine support of the network (e.g., and/or the network's configuration for the UE to use) for a fully protected connection resume message based on a response of the network to one or more messages sent by the UE. In other words, the UE may indicate to the network that the UE supports a fully protected connection resume message, and may determine whether or not to use a fully protected connection resume message based on whether or how the network responds to the UE's indication. A network which does not support the fully protected connection resume message may have two options to respond to such an indication from a UE. As a first option, the network may configure the UE (e.g., upon releasing a connection, e.g., in a SuspendConfig or an RRCRelease) to use an old (e.g., not fully protected) connection resume message, e.g., an old ResumeMAC-I. In this case, the UE may receive an explicit instruction to use the old format for a connection resume message. As a second option, the network may not modify its response to the message including the UE's indication based on the UE's indication. In other words, the network may not respond to the UE's indication. However, it should be noted that the network may respond to other aspects of the message transmitted by the UE, e.g., if the message includes information in addition to the UE's indication of support for a fully protected connection resume message. Thus, the UE may not receive a response to its indication of support from the network. Based on such a lack of response and/or an explicit instruction to use the old format, the UE may determine that the network does not support a fully protected connection resume message. If the network does support a fully protected connection resume message, the network may either configure the UE (e.g., at the time of connection release) to use a fully protected connection resume message or otherwise reply with an indication that it supports this feature. Three examples of the UE providing such an indication to the network are provided below.

As a first example, the UE may include an indication upon establishing security, e.g., of the access stratum (AS). For example, the UE may include an indication of its support for a fully protected connection resume message when transmitting security mode command (SMC) complete message. This example is further illustrated and described with respect to <FIG>.

As a second example, the UE may include an indication upon registering with the network. For example, the UE may include an indication of its support for a fully protected connection resume message when transmitting a registration request message. This example is further illustrated and described with respect to <FIG>.

As a third example, the UE may include an indication upon establishing security e.g., of the non-access stratum (NAS). For example, the UE may include an indication of its support for a fully protected connection resume message when transmitting an SMC complete message, e.g., associated with the NAS. This example is further illustrated and described with respect to <FIG>.

The UE <NUM> may resume the connection with the network <NUM> (<NUM>), according to some embodiments. The UE may transmit a fully protected connection resume message, (e.g., an RRCResumeRequest using a new ResumeMAC-I) and/or a not-fully protected connection resume message (e.g., an RRCResumeRequest using an old ResumeMAC-I). According to some embodiments, the UE may select whether to use a fully protected connection resume message and/or a not-fully protected connection resume message based on the determination of whether or how the network supports a fully protected connection resume message, e.g., as determined in <NUM>. In other words, in response to a determination that the network supports (or does not support) a fully protected connection resume message, the UE may (or may not) use a fully protected connection resume message to resume the connection. In some embodiments, a UE may not use a fully protected connection resume message even if it determines that the network does support a fully protected connection resume message.

The UE and network may exchange further messages related to resuming the connection. For example, the network may transmit an RRC resume message and the UE may respond with an RRC resume complete message, according to some embodiments. The UE and network may exchange data and/or control information in the uplink and/or downlink directions.

<FIG> are a communication flow diagrams illustrating a UE <NUM> and a network <NUM> resuming a connection, according to some embodiments. It will be appreciated that the communication flows in these figures may be examples of the method of <FIG>, but these examples are not limiting. In various embodiments, some of the elements shown may be performed concurrently, in a different order than shown, may be substituted for by other elements, or may be omitted. Additional elements may also be performed as desired.

As shown in <FIG>, a UE <NUM> may receive a SIB or other message broadcast by a BS <NUM> of network <NUM> (<NUM>). The SIB or other broadcast message may include configuration information related to resuming a connection. For example, such a broadcast message may indicate what process may be used to determine whether a fully protected connection resume message is configured. In other words, the broadcast may identify what message(s) may be used by the UE and/or network to exchange indications about support for and/or configuration of connection resume messages. The UE may establish a connection, e.g., an RRC connection, with the network (<NUM>). The UE and network may establish security for AS, e.g., by the network transmitting an AS SMC command (<NUM>) and the UE responding with an AS SMC complete (<NUM>). The UE and network may perform configuration (and/or reconfiguration) of the connection (e.g., RRC reconfiguration) (<NUM>). The UE may register with the network, e.g., by transmitting an initial registration request (<NUM>) and the network may grant the registration, e.g., by transmitting a registration accept (<NUM>). The network may indicate to the UE to secure the NAS, e.g., by transmitting an NAS SMC command (<NUM>). The UE may establish NAS security and respond, e.g., with a NAS SMC complete (<NUM>). The network may determine to release the connection (e.g., by transmitting an RRCRelease, potentially including a SuspendConfig) (<NUM>).

Following release of the connection, the UE may operate in an inactive mode (<NUM>). Upon determining to resume the connection (e.g., in order to exchange data with the network), the UE may transmit a connection resume message (<NUM>), such as an RRCResumeRequest. As noted above, an RRCResumeRequest1 or other type of RRC resume request may be used, as appropriate. In the illustrated example, the connection resume message may not be fully protected (e.g., an old ResumeMAC-I may be used). However, it will be appreciated that a fully protected connection resume message and/or non-fully protected connection resume message may be used, according to some embodiments. For example, for a network which supports a fully protected connection resume message, the UE may include a new ResumeMAC-I, while for a legacy network which may not support a fully protected connection resume message, the UE may only include the old ResumeMAC-I.

The network may verify the connection resume message, e.g., using the ResumeMAC-I (<NUM>). If the connection resume message is not verified successfully, the network may reject the request and/or may not resume the connection. However, in response to successfully verifying the resume request, the network may accept the request (<NUM>), e.g., by transmitting an RRC resume message. The UE may respond with a message indicating that the connection is resumed (<NUM>) (e.g., RRC resume complete).

In some embodiments of the method of <FIG>, the UE may not determine that the network supports a fully protected connection resume message. For example, the UE and network may not exchange signaling indicating that the network supports a fully protected connection resume message. In other words, <NUM> may not be performed, according to some embodiments. Thus, the UE may (e.g., at <NUM>) use both an old ResumeMAC-I and a new ResumeMAC-I, e.g., in the same RRCResumeRequest message. The message may be described as follows: RRCResumeRequest(old ResumeMAC-I+newResumeMAC-I)/ RRCResumeRequest1(old ResumeMAC-I+newResumeMAC-I). In this way, the UE may not rely on any indication from the network whether this network supports the verification of new ResumeMAC-I or not, e.g., whether the network supports a fully protected connection resume message. If the network does not support the fully protected connection resume message, the network may only verify the old ResumeMAC-I, and may ignore the new ResumeMAC-I. However, if the network supports a fully protected connection resume message, it may verify the new ResumeMAC-I.

<FIG> illustrates an example in which the network provides an indication of its support for a fully protected connection resume message using a broadcast message, such as a SIB1. As shown, a UE <NUM> may receive a SIB broadcast by a BS <NUM> of network <NUM> (<NUM>), according to some embodiments. The SIB may include an indication, e.g., as an IE or other message or field, that the network supports a fully protected connection resume message. For example, such an indication may be a fully protected connection resume message IE such as a NewResumeMAC-I IE, or a similar element. Based on the broadcast (e.g., and/or the indication within the broadcast message), the UE may determine that the network supports a fully protected connection resume message, e.g., as described above regarding <NUM>. For example, the UE may determine to use a fully protected connection resume message in the event that the connection is suspended and to be resumed.

The UE and network may proceed to transmit/receive a broadcast, perform connection establishment, AS security, configuration, registration, NAS security, and connection release as described above with respect to <NUM>-<NUM> (note that these elements may be performed in a different order, one or more illustrated elements may be omitted, and/or additional elements may be performed). The UE may operate in inactive mode as discussed above regarding <NUM>.

Upon determining to resume the connection, the UE may transmit a connection resume message (<NUM>), according to some embodiments. In response to a determination (e.g., as discussed above with respect to <NUM>) that the network supports (e.g., or has configured the UE to use) a fully protected connection resume message, the UE may use a fully protected connection resume message. As noted above the fully protected connection resume message may include the resume cause field as an input to the MAC-I token. If the UE did not determine that the network supports (or has configured the UE to use) a fully protected connection resume message, the UE may use a non-fully protected connection resume message.

The network may then verify the connection resume message (<NUM>) and the UE and network may resume the connection (<NUM> and <NUM>), as described above.

<FIG> illustrates an example in which the network provides an indication of its support for a fully protected connection resume message using a message associated with releasing the connection. As shown, the UE and network may establish a connection, AS and NAS security, perform registration, and perform configuration as described above with respect to <NUM>-<NUM> (note that these elements may be performed in a different order, one or more illustrated elements may be omitted, and/or additional elements may be performed).

The network may determine to release the connection (e.g., by transmitting an RRCRelease, potentially including a SuspendConfig and an indication that the network supports a fully protected connection resume message) (<NUM>). For example, the parameters of the SuspendConfig may be used to configure the UE to use a fully protected connection resume message. It will be appreciated that the indication may be transmitted in any desired message and/or format associated with the connection release, e.g., in an RRCRelease or an associated message. For example, a fully protected connection resume message IE may be used. Additional configuration information related to the suspended connection may also be included.

Further, it will be appreciated that a network or base station that supports a fully protected connection resume message may configure (e.g., using parameters of the SuspendConfig) the UE to use a non-fully protected connection resume message, e.g., an old ResumeMAC-I. For example, a network may not configure use of a fully protected connection resume message (even though it supports such use) if some elements of the network (e.g., one or more BS) do not support the use of a fully protected connection resume message. Consistent connection resume messaging across BSs that do and do not support a fully protected connection resume message may be more convenient for network management. Similarly, a network that supports a fully protected connection resume message may not configure the use of a fully protected connection resume message if some of the UEs operating on the network do not support the fully protected connection resume message.

The UE may operate in inactive mode as discussed above regarding <NUM>. The UE may initiate resuming the connection and may use a fully protected or non-fully protected connection resume message (e.g., according to a determination of whether the network supports or configures a fully protected connection resume message) as described above regarding <NUM>. The network may then verify the connection resume message (<NUM>) and the UE and network may resume the connection (<NUM> and <NUM>), as described above.

<FIG> illustrates an example in which the network provides an indication of its support for a fully protected connection resume message using both a broadcast message and a message associated with releasing the connection. As shown, a UE <NUM> may receive a SIB broadcast by a BS <NUM> of network <NUM> (<NUM>), according to some embodiments. The SIB may include an indication, e.g., as an IE or other message or field, that the network supports a fully protected connection resume message. For example, such an indication may be a fully protected connection resume message IE such as a NewResumeMAC-I IE, or a similar element. Further, the message may include (e.g., in the IE or separately) an indication that the network may confirm that the UE is to use a fully protected connection resume message at the time of releasing the connection. In other words, the message may indicate that the UE should not use a fully protected connection resume message unless confirmed by the network during release, according to some embodiments. In other embodiments, the UE may be configured (e.g., based on standards) to anticipate such confirmation (e.g., and not to use a fully protected connection resume message unless such confirmation occurs), and no indication to that effect may be included in the broadcast message. Based on the broadcast (e.g., and/or the indication within the broadcast message), the UE may preliminarily determine that the network supports a fully protected connection resume message and that further confirmation is expected, e.g., as described above regarding <NUM>. For example, the UE may determine to use a fully protected connection resume message in the event that the connection is suspended and to be resumed, subject to confirmation at the time of release.

The UE and network may proceed to transmit/receive a broadcast, perform connection establishment, AS security, configuration, registration, and NAS security as described above with respect to <NUM>-<NUM> (note that these elements may be performed in a different order, one or more illustrated elements may be omitted, and/or additional elements may be performed).

The network may determine to release the connection (e.g., by transmitting an RRCRelease, potentially including a SuspendConfig and an indication/confirmation that the network supports a fully protected connection resume message) (<NUM>). In other words, the release message may confirm the preliminary indication (e.g., of <NUM>). For example, the parameters of the SuspendConfig may be used to configure the UE to use a fully protected connection resume message. It will be appreciated that the indication/confirmation may be transmitted in any desired message and/or format associated with the connection release, e.g., in an RRCRelease or an associated message. For example, a fully protected connection resume message IE may be used. Additional configuration information related to the suspended connection may also be included. Further, it will be appreciated that a network or base station that supports a fully protected connection resume message may configure (e.g., using parameters of the SuspendConfig) the UE to use a non-fully protected connection resume message, e.g., an old ResumeMAC-I. Similarly, such a network or base station may not confirm the preliminary indication (e.g., of <NUM>). Thus, the technique of <FIG> may allow the network to maintain flexibility to determine at the time of the connection release whether to configure the UE to use a fully protected connection resume message or not.

Following the connection release, the UE may operate in inactive mode as discussed above regarding <NUM>. The UE may initiate resuming the connection and may use a fully protected or non-fully protected connection resume message (e.g., according to a determination of whether the network supports or configures a fully protected connection resume message) as described above regarding <NUM>.

The example of <FIG> includes that the network may include an indication (e.g., NewResumeMAC-I IE) in both the SIB and the SuspendConfig IE in RRCRelease message if it supports and/or configures a fully protected connection resume message. For example, if the UE reads this IE in SIB1 and SuspendConfig IE, when the UE sends RRCResumeRequest message, it may use the new ResumeMAC-I. If the UE does not read this IE in both SIB1 and SuspendConfig IE, the UE may use old ResumeMAC-I.

<FIG> illustrates an example in which the UE may provide an indication to the network of its support for a fully protected connection resume message using an AS SMC complete message and the network may provide an indication of its support (or configuration of) a fully protected connection resume message in response. As shown, the UE and network may transmit/receive a broadcast and establish a connection, as described with respect to <NUM> and <NUM>. The network may transmit an AS SMC command as in <NUM>. The UE may respond with an AS SMC complete message (<NUM>), according to some embodiments. The UE may include an indication, in the AS SMC complete message, of its support for a fully protected connection resume message. The indication may be a field in the AS SMC complete message. For example, the indication may be a fully protected connection resume message IE. Accordingly, the UE may determine whether the network supports (and/or configures the UE to use) a fully protected connection resume message based on whether or how the network acknowledges or responds to the indication. Such a response or acknowledgement may be included in any later message (e.g., RRC reconfiguration as in <NUM>, registration accept as in <NUM>, NAS security as in <NUM>, and/or connection release as in <NUM>). Further, such a response or acknowledgement may be included in a different message. Such a response or acknowledgement may be or include a fully protected connection resume message IE and/or configuration information (e.g., in SuspendConfig), among various possibilities.

The UE and network may proceed to perform configuration, registration, NAS security, and connection release as described above with respect to <NUM>-<NUM> (note that these elements may be performed in a different order, one or more illustrated elements may be omitted, and/or additional elements may be performed). Note that any of <NUM>, <NUM>, <NUM>, and/or <NUM> may be modified to incorporate a response/acknowledgement from the network as discussed above. The UE may operate in inactive mode as discussed above regarding <NUM>. The UE may initiate resuming the connection and may use a fully protected or non-fully protected connection resume message (e.g., according to a determination of whether the network supports or configures a fully protected connection resume message) as described above regarding <NUM>. The network may then verify the connection resume message (<NUM>) and the UE and network may resume the connection (<NUM> and <NUM>), as described above.

<FIG> illustrates an example in which the UE may provide an indication to the network of its support for a fully protected connection resume message using a registration request message and the network may provide an indication of its support (or configuration of) a fully protected connection resume message in response. As shown, the UE and network may transmit/receive a broadcast, establish a connection, secure the AS, and perform configuration as described with respect to <NUM>-<NUM> (note that these elements may be performed in a different order, one or more illustrated elements may be omitted, and/or additional elements may be performed). The UE may initiate registration, eg. , by transmitting a registration request (<NUM>), according to some embodiments. The UE may include an indication, in the registration request message, of its support for a fully protected connection resume message. The indication may be a field in the registration request complete message. For example, the indication may be a fully protected connection resume message IE. Accordingly, the UE may determine whether the network supports (and/or configures the UE to use) a fully protected connection resume message based on whether or how the network acknowledges or responds to the indication. Such a response or acknowledgement may be included in any later message (e.g., registration accept as in <NUM>, NAS security as in <NUM>, and/or connection release as in <NUM>). Further, such a response or acknowledgement may be included in a different message. Such a response or acknowledgement may be or include a fully protected connection resume message IE and/or configuration information (e.g., in SuspendConfig), among various possibilities.

The UE and network may proceed to complete the registration, perform NAS security, and connection release as described above with respect to <NUM>-<NUM> (note that these elements may be performed in a different order, one or more illustrated elements may be omitted, and/or additional elements may be performed). Note that any of <NUM>, <NUM>, and/or <NUM> may be modified to incorporate a response/acknowledgement from the network as discussed above. The UE may operate in inactive mode as discussed above regarding <NUM>. The UE may initiate resuming the connection and may use a fully protected or non-fully protected connection resume message (e.g., according to a determination of whether the network supports or configures a fully protected connection resume message) as described above regarding <NUM>. The network may then verify the connection resume message (<NUM>) and the UE and network may resume the connection (<NUM> and <NUM>), as described above.

<FIG> illustrates an example in which the UE may provide an indication to the network of its support for a fully protected connection resume message using a NAS SMC complete message and the network may provide an indication of its support (or configuration of) a fully protected connection resume message in response. As shown, the UE and network may transmit/receive a broadcast, establish a connection, secure the AS, perform configuration, perform registration, and transmit/receive a NAS SMC command as described with respect to <NUM>-<NUM> (note that these elements may be performed in a different order, one or more illustrated elements may be omitted, and/or additional elements may be performed). The UE may include an indication, in a NAS SMC complete message (<NUM>), of its support for a fully protected connection resume message. The indication may be a field in the NAS SMC complete message. For example, the indication may be a fully protected connection resume message IE. Accordingly, the UE may determine whether the network supports (and/or configures the UE to use) a fully protected connection resume message based on whether or how the network acknowledges or responds to the indication. Such a response or acknowledgement may be included in any later message (e.g., connection release as in <NUM> or a different message). Such a response or acknowledgement may be or include a fully protected connection resume message IE and/or configuration information (e.g., in SuspendConfig), among various possibilities.

The UE and network may proceed to perform connection release as described above with respect to <NUM>. Note that <NUM> may be modified to incorporate a response/acknowledgement from the network as discussed above. The UE may operate in inactive mode as discussed above regarding <NUM>. The UE may initiate resuming the connection and may use a fully protected or non-fully protected connection resume message (e.g., according to a determination of whether the network supports or configures a fully protected connection resume message) as described above regarding <NUM>. The network may then verify the connection resume message (<NUM>) and the UE and network may resume the connection (<NUM> and <NUM>), as described above.

In some embodiments, a network may configure different UEs (or the same UE at different times) to use different types of connection resume messages. For example, under some conditions (e.g., some types of UEs, some network load conditions, etc.), the network may configure a UE to use a non-fully protected connection resume message, while under other conditions the network may configure a UE to use a fully protected connection resume message.

In some embodiments, a device (e.g., a UE) may be configured to include a processor (or a set of processors) and a memory medium, where the memory medium stores program instructions, where the processor is configured to read and execute the program instructions from the memory medium, where the program instructions are executable to implement any of the various method embodiments described herein (or, any combination of the method embodiments described herein, or, any subset of any of the method embodiments described herein, or, any combination of such subsets). The device may be realized in any of various forms.

Claim 1:
A method, comprising:
at a user equipment device, UE, (<NUM>):
establishing a connection with a network (<NUM>);
receiving, from the network (<NUM>), a broadcast message including a first indication that the network (<NUM>) supports a fully protected connection resume message, wherein all fields except a ResumeMAC-I part are protected in the fully protected connection resume message;
receiving, from the network (<NUM>), a second indication in a radio resource control, RRC, Release message with SuspendConfig that the network (<NUM>) supports the fully protected connection resume message;
releasing the connection with the network (<NUM>);
in response to both the first and second indication, determining that the network (<NUM>) supports the fully protected connection resume message; and
in response to the determination that the network (<NUM>) does support the fully protected connection resume message:
transmitting, to the network (<NUM>), the fully protected connection resume message; and
resuming the connection with the network (<NUM>).