Patent Description:
This section is intended to provide a background or context to the invention disclosed below. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived, implemented or described. Therefore, unless otherwise explicitly indicated herein, what is described in this section is not prior art to the description in this application and is not admitted to be prior art by inclusion in this section. Abbreviations that may be found in the specification and/or the drawing figures are defined below, at the beginning of the detailed description section.

A new Work Item (WI) for further enhancements to Machine Type Communication (MTC) / Narrow Band-Internet of Things (NB-IoT) is approved for Release <NUM> (Rel-<NUM>). One of the objectives of this WI is to support transmission over preconfigured uplink resources (PURs) for User Equipment (UEs) having valid timing advance in idle mode or connected mode. Currently, only dedicated PUR (D-PUR) in idle mode is supported. Dedicated means that a unique or dedicated time-frequency resource is reserved for each UE configured with PUR. In RAN1#<NUM>, the following D-PUR agreements relevant to the examples herein were made.

A first agreement was as follows: For dedicated PUR in idle mode, an uplink (UL) grant for Hybrid Automatic Repeat reQuest (HARQ) retransmission is transmitted in MTC Physical Downlink Control CHannel (MPDCCH) search space. It is For Further Study (FFS) as to the details on the search space (for example UE specific Search Space (USS), or Common Search Space (CSS)).

A second agreement was as follows: For dedicated PUR in idle mode, upon successful decoding by eNB of a PUR transmission, the UE can expect an explicit acknowledgement (ACK). It is FFS if the ACK is sent on MPDCCH (layer <NUM>) and/or Physical Downlink Shared CHannel (PDSCH) (layer <NUM>/<NUM>). This is to be included in a Liaison Statement (LS) to RAN2, RAN4.

A third agreement was as follows: For dedicated PUR in idle mode, upon unsuccessful decoding by eNB of a PUR transmission, the UE can expect the following:.

In a RAN2 email discussion discussing various D-PUR related signaling, Email discussion [<NUM>#<NUM>][eMTC & NB-IoT R16] D-PUR report, there is the following question raised:.

Question <NUM>. Are there other scenarios for release of a D-PUR allocation and methods to apply the release?.

Internal examination of this question by the inventors, raises another as yet unpublished question:.

How should Radio Resource Control (RRC) connections be handled that are between and overlapping with PUR opportunities?.

HUAWEI ET AL: "Feature lead summary of Support for transmission in preconfigured UL resources", vol. RAN WG1, no. Spokane, USA, November <NUM> (<NUM>-<NUM>-<NUM>) discusses about agreements on transmission on UL preconfigured resources and summarizes views and proposals from different companies.

HUAWEI ET AL: "Feature lead summary of Support for transmission in preconfigured UL resources", vol. RAN WG1, no. Chengdu, China, October <NUM> (<NUM>-<NUM>-<NUM>) also discusses about agreements on transmission on UL preconfigured resources and summarizes views and proposals from different companies.

This section is intended to include examples and is not intended to be limiting.

In an exemplary embodiment, a method is disclosed that includes determining, at a user equipment configured with an idle-mode configuration for using a preconfigured uplink resource, that data not associated with the preconfigured uplink resource is to be transmitted or to be received via a radio resource control connection. The method includes performing by the user equipment an initial access to a network for the radio resource control connection. The method also includes transitioning, by the user equipment, from radio resource control idle mode to radio resource control connected mode. The method includes the user equipment performing one of suspending the idle-mode configuration or maintaining the idle-mode configuration, for at least a duration of the radio resource control connected mode.

An additional exemplary embodiment includes a computer program, comprising code for performing the method of the previous paragraph, when the computer program is run on a processor.

An exemplary apparatus configured to perform at least the following: determining, at a user equipment configured with an idle-mode configuration for using a preconfigured uplink resource, that data not associated with the preconfigured uplink resource is to be transmitted or to be received via a radio resource control connection; performing by the user equipment an initial access to a network for the radio resource control connection; transitioning, by the user equipment, from radio resource control idle mode to radio resource control connected mode; and the user equipment performing one of suspending the idle-mode configuration or maintaining the idle-mode configuration, for at least a duration of the radio resource control connected mode.

In an exemplary embodiment, a method is disclosed that includes receiving at a base station in a wireless communication network an initial access to the network for the radio resource control (RRC) connection. The method includes determining, at the base station, that the user equipment is configured with an idle-mode configuration for using a preconfigured uplink resource. The method also includes transitioning, by the base station, the user equipment from RRC idle mode to RRC connected mode. The method includes performing communication between the base station and the user equipment to perform one or more actions to suspend or maintain the idle-mode configuration of the user equipment for at least a duration of the radio resource control connected mode.

An exemplary apparatus configured to perform at least the following: receiving at a base station in a wireless communication network an initial access to the network for the radio resource control (RRC) connection; determining, at the base station, that the user equipment is configured with an idle-mode configuration for using a preconfigured uplink resource; transitioning, by the base station, the user equipment from RRC idle mode to RRC connected mode; and performing communication between the base station and the user equipment to perform one or more actions to suspend or maintain the idle-mode configuration of the user equipment for at least a duration of the radio resource control connected mode.

The rest of this disclosure is divided into sections for ease of reference. The first section describes possible exemplary systems, the second section describes exemplary processes, the third section describes additional exemplary details, and the fourth and final section has additional comments.

The exemplary embodiments herein describe techniques for maintaining, suspending, or modifying existing PUR configuration in response to a UE entering into an RRC connected mode (also referred to as a state herein). Additional description of these techniques is presented after a system into which the exemplary embodiments may be used is described.

Turning to <FIG>, this figure shows a block diagram of one possible and non-limiting exemplary system in which the exemplary embodiments may be practiced. A user equipment (UE) <NUM>, radio access network (RAN) node <NUM>, and network element(s) <NUM> are illustrated. In <FIG>, a user equipment (UE) <NUM> is in wireless communication with a wireless network <NUM>. A UE is a wireless device that can access a wireless network and is likely a MTC/IoT UE device. The UE <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The UE <NUM> includes a PUR communication (Comm. ) module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The PUR Comm. module <NUM> may be implemented in hardware as PUR communication module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The PUR communication module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the PUR communication module <NUM> may be implemented as PUR communication module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> may be configured to, with the one or more processors <NUM>, cause the user equipment <NUM> to perform one or more of the operations as described herein. The UE <NUM> communicates with RAN node <NUM> via a wireless link <NUM>.

The RAN node <NUM> is a base station that provides access by wireless devices such as the UE <NUM> to the wireless network <NUM>. The RAN node <NUM> may be, for instance, a base station for <NUM>, also called New Radio (NR), or a base station for LTE, an eNB (evolved Node B). The latter (eNB) is assumed below, but <NUM> is also possible. In <NUM>, the RAN node <NUM> may be a NG-RAN node, which is defined as either a gNB or an ng-eNB. A gNB is a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to a 5GC (e.g., the network element(s) <NUM>). The ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC. The NG-RAN node may include multiple gNBs, which may also include a central unit (CU) (gNB-CU) <NUM> and distributed unit(s) (DUs) (gNB-DUs), of which DU <NUM> is shown. Note that the DU may include or be coupled to and control a radio unit (RU). The gNB-CU is a logical node hosting RRC, SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected with the gNB-DU. The F1 interface is illustrated as reference <NUM>, although reference <NUM> also illustrates a link between remote elements of the RAN node <NUM> and centralized elements of the RAN node <NUM>, such as between the gNB-CU <NUM> and the gNB-DU <NUM>. The gNB-DU is a logical node hosting RLC, MAC and PHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU. One gNB-CU supports one or multiple cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface <NUM> connected with the gNB-CU. Note that the DU <NUM> is considered to include the transceiver <NUM>, e.g., as part of an RU, but some examples of this may have the transceiver <NUM> as part of a separate RU, e.g., under control of and connected to the DU <NUM>. The RAN node <NUM> may also be an eNB (evolved NodeB) base station, for LTE (long term evolution), or any other suitable base station.

The RAN node <NUM> includes a PUR communication (Comm. ) module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The PUR communication module <NUM> may be implemented in hardware as PUR communication module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The PUR communication module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the PUR communication module <NUM> may be implemented as PUR communication module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the RAN node <NUM> to perform one or more of the operations as described herein. Note that the functionality of the PUR communication module <NUM> may be distributed, such as being distributed between the DU <NUM> and the CU <NUM>, or be implemented solely in the DU <NUM>.

Two or more RAN nodes <NUM> communicate using, e.g., link <NUM>. The link <NUM> may be wired or wireless or both and may implement, e.g., an Xn interface for <NUM>, an X2 interface for LTE, or other suitable interface for other standards.

The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers <NUM> may be implemented as a remote radio head (RRH) <NUM> for LTE or a distributed unit (DU) <NUM> for gNB implementation for <NUM>, with the other elements of the RAN node <NUM> possibly being physically in a different location from the RRH/DU, and the one or more buses <NUM> could be implemented in part as, e.g., fiber optic cable or other suitable network connection to connect the other elements (e.g., a central unit (CU), gNB-CU) of the RAN node <NUM> to the RRH/DU <NUM>. Reference <NUM> also indicates those suitable network link(s).

The wireless network <NUM> may include a network element or elements <NUM> that may include core network functionality, and which provides connectivity via a link or links <NUM> with a further network, such as a telephone network and/or a data communications network (e.g., the Internet). Such core network functionality for <NUM> may include access and mobility management function(s) (AMF(s)) and/or user plane functions (UPF(s)) and/or session management function(s) (SMF(s)). Such core network functionality for LTE may include MME (Mobility Management Entity)/SGW (Serving Gateway) functionality. These are merely exemplary functions that may be supported by the network element(s) <NUM>, and note that both <NUM> and LTE functions might be supported. The RAN node <NUM> is coupled via a link <NUM> to a network element <NUM>. The link <NUM> may be implemented as, e.g., an NG interface for <NUM>, or an S1 interface for LTE, or other suitable interface for other standards. The network element <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more network interfaces (N/W I/F(s)) <NUM>, interconnected through one or more buses <NUM>. The one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the network element <NUM> to perform one or more operations.

The computer readable memories <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer readable memories <NUM>, <NUM>, and <NUM> may be means for performing storage functions. The processors <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples. The processors <NUM>, <NUM>, and <NUM> may be means for performing functions, such as controlling the UE <NUM>, RAN node <NUM>, and other functions as described herein.

Having thus introduced one suitable but non-limiting technical context for the practice of the exemplary embodiments of this invention, the exemplary embodiments will now be described with greater specificity.

We envisage that devices using PUR may have long quiet periods in IDLE mode between PUR transmissions. For example, a home smart meter device using PUR may wait a whole week before sending a compressed summary of usage over that week. But during that week between PUR transmissions, an urgent unscheduled event, e.g., a temporary power cut from the device (e.g., UE) side or a network-initiated update, may require the same device to establish a temporary RRC connection with the network. What has yet to be discussed and that can affect standards is how to handle such a scenario, and whether the pre-existing PUR configuration should be allowed to continue or whether the pre-existing PUR configuration should be reconfigured.

As described above, the closest question raised so far touching this area is the following: "Question <NUM>. Are there other scenarios for release of a D-PUR allocation and methods to apply the release?" Additionally, in the RAN2 email discussion discussing various D-PUR related signaling, described above, the question of how to handle D-PUR configurations in the event of temporary RRC connections has yet to be discussed.

The exemplary embodiments address how to handle a scenario where an RRC connection with the network will be established by the UE and the UE already has an existing PUR configuration and the data for the RRC connection is not associated with that PUR configuration. In more detail, the exemplary embodiments provide examples of how to operate (e.g., setup, modify, release) a (e.g., new, spontaneous, unscheduled) RRC connection in parallel to a preconfigured UL resource (PUR) in NB-IoT (MTC/IoT UE device and base station). The PUR configuration may be dedicated (that is, a UE is assigned a dedicated or unique time/frequency resources) or shared (that is, several UEs are assigned the same or overlapping time/frequency resources). Although much of the disclosure herein concerns D-PUR, it is to be noted that the techniques described herein are applicable to PUR in general, e.g. including shared PUR (S-PUR). Dedicated PUR is also known as contention-free PUR (i.e. there is no contention on the time/frequency resources) while shared PUR is also known as contention-based PUR (i.e. there are possible contention on the time/frequency resources since multiple UEs are assigned the same or overlapping time/frequency resources). Two situations may occur: <NUM>) An RRC transmission (e.g., a transmission scheduled by the eNB when the UE is in the RRC connected mode) overlaps with D-PUR transmission and the UE is reconfigured to postpone D-PUR transmission or combine (e.g., include) data of D-PUR transmission into the RRC transmission; and <NUM>) The RRC transmission is before a next-scheduled D-PUR transmission and the UE may anticipate the transmission of data foreseen at D-PUR, e.g., and send the data for the D-PUR in the RRC transmission. The first situation (<NUM>) is illustrated, e.g., in <FIG>, and the second situation (<NUM>) is illustrated, e.g., in <FIG>.

In additional detail regarding PUR, consider the following. Dedicated preconfigured UL resource is defined as a PUSCH resource used by a single UE: PUSCH resource is time-frequency resource; and Dedicated PUR is contention-free. Contention-free shared preconfigured UL resource (CFS PUR) is defined as a PUSCH resource simultaneously used by more than one UE: The PUSCH resource is at least time-frequency resource; and CFS PUR is contention-free. Contention-based shared preconfigured UL resource (CBS PUR) is defined as a PUSCH resource simultaneously used by more than one UE: The PUSCH resource is at least time-frequency resource; and CBS PUR is contention-based (CBS PUR may require contention resolution). All of these types of PURs may be addressed by the techniques presented herein.

The following is a description of the actions taken by the UE <NUM> and the RAN node <NUM>, which will be referred to as eNB <NUM> below. Reference may be made to <FIG>, which is a logic flow diagram for RRC connection with PUR configuration, in accordance with exemplary embodiments. <FIG> illustrates the operation of an exemplary method or methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiments. The UE <NUM> performs the functions in the blocks under control of the PUR communication module <NUM>, and the eNB <NUM> performs the functions in the blocks under control of its PUR communication module <NUM>.

Before proceeding with a description of <FIG>, it is noted that it is up to the eNB whether PUR and RRC transmissions use the same or different resources. The PUR resources are preconfigured (i.e., fixed) whereas the RRC resources are dynamic (i.e., scheduled by eNB). When UE performs PUR transmission, the UE always knows where to transmit based on the existing PUR configuration. When the UE performs RRC transmission, the resources are provided per each transmission by the eNB via scheduling grant DCI.

It is assumed that the UE <NUM> is in IDLE mode and has been configured with a PUR configuration. See block <NUM>. Mobile originated (MO) or mobile terminated (MT) data arrives (e.g., the UE is paged or performs random access). See block <NUM>. There is an initial access by the UE <NUM>, which is then configured (by the network) into RRC connected mode for data transfer. See block <NUM>.

In block <NUM>, the network (e.g., eNB <NUM>) determines that the UE has ongoing PUR configured. Methods of achieving this include but are not limited to the following:.

It is possible for there to be explicit indication/negotiation for the idle-mode PUR configuration between the network and the UE. That is, an indication (or negotiation) helping the network to associate an existing PUR configuration with the same UE now transitioning into RRC CONNECTED mode. This is described in reference to block <NUM>. It is possible for there to be explicit indication/negotiation between the network and the UE. This is described in reference to block <NUM>.

In block <NUM>, without explicit indication/negotiation between the network and the UE one of the following options can be adopted:.

When UE continues to transmit uplink data using the time/frequency resources allocated in the PUR configuration, it is assumed that there are search spaces associated with the PUR configuration for the UE to receive DCI and/or ACK/NACK. Furthermore, the UE will also be configured with a control channel search space associated with connected mode transmission and reception. Note that overlap of PDSCH and the PUR DCI is an issue only for half-duplex devices, which cannot transmit (PUSCH) and receive (DCI) at the same time. Consequently, in the event that the PUSCH or PDSCH (half-duplex devices only) allocated in the RRC CONNECTED mode overlaps with the PUR DCI search space and/or PUR PUSCH, the following options exist:.

With explicit indication/negotiation between the network and the UE, via either layer <NUM> and/or layer <NUM> signaling, the network can perform one of the following with respect to the UE idle-mode PUR configuration (see block <NUM>):.

If the PUR session is still ongoing, the UE is to update the saved PUR TA to the latest value prior to releasing RRC connection and transitioning into idle mode. See block <NUM>.

If SPS is supported for the dedicated mode transmission, the eNB can configure the UE to either (see block <NUM>):.

In block <NUM>, if the RRC connection or EDT was established just prior to the D-PUR occasion to deliver the same data meant for D-PUR because a condition for PUR is not met at UE (e.g., the timing advance value is no longer valid at the UE) and if the RRC connection completes before the D-PUR occasion itself (e.g., which is possible if for instance uplink data in the form of a sensor report is available in advance prior to the D-PUR occasion to check the validity of PUR usage), then the:.

One scenario addressed by the exemplary embodiments is illustrated in <FIG> shows three PUR allocations <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM>, and corresponding D-PURs <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> in each of the PUR allocations <NUM>. The dedicated RRC connection <NUM> established for non-PUR transmission overlaps with the D-PUR <NUM>-<NUM> already assigned for the UE. There is a RRC Connection Request for non-PUR transmission (see reference <NUM>), which means a corresponding dedicated RRC connection <NUM> would completely overlap the D-PUR <NUM>-<NUM>.

Two different RRC Configurations on modifying the D-PUR resource for dedicated connection or SPS are illustrated in <FIG>, which is a signaling diagram between a UE and an eNB and illustrates two methods for RRC reconfiguration. There is an RRC Connection Setup message <NUM> from the UE <NUM> to the eNB <NUM>. There are two examples of RRC Reconfiguration messages <NUM>. For RRC Reconfiguration message <NUM>-<NUM>, this message includes a D-PUR Resource status of Release / Postpone / combine-with-dedicated PUSCH. This is Method <NUM><NUM>-<NUM>. That is, the D-PUR Resource should be one of the following: released ("Release"); postponed ("Postponed"); or combined with dedicated PUSCH ("combine-with-dedicated PUSCH"). Postponed means that the use of the D-PUR is postponed until after the RRC connection is released. Meanwhile, "suspended" is used to imply that the D-PUR is not used during the RRC connection, but the configuration is still maintained such that the configuration can be used after the RRC connection is released. The combined with dedicated PUSCH means data intended for the PUR is transferred using both the PUR and PUSCH resources granted in RRC CONNECTED.

For RRC Reconfiguration message <NUM>-<NUM>, this message includes an SPS Configuration for D-PUR Collision having a value of one of SPS Postponed / D-PUR Postponed. This is Method <NUM><NUM>-<NUM>. This is useful, e.g., for a situation as shown in <FIG>, where the D-PUR and dedicated RRC connection overlap. The value of "SPS Postponed" means that the SPS transmission is deferred until outside the D-PUR resource location (see, e.g., block <NUM> of <FIG>). The value of "D-PUR Postponed" means that the resource location for the D-PUR transmission is deferred until outside the SPS resource location (see, e.g., block <NUM> of <FIG>).

There is a case where the UE sends a packet associated with the D-PUR prior to the D-PUR occasion via an EDT procedure. See <FIG>, which is an illustration of another scenario where a UE sends a packet (in the dedicated RRC connection <NUM>) associated with the D-PUR prior to the D-PUR occasion <NUM>-<NUM> via an EDT procedure, in an exemplary embodiment. See also reference <NUM> and blocks <NUM>, <NUM>, and <NUM> of <FIG>. This may happen if the UE determines that the UE does not meet the validity criteria for using the D-PUR transmission. In such cases, as part of RRC connection release, the eNB also indicates (see reference <NUM>) to release the next D-PUR instance. Further D-PUR instances are valid, as the UE has a valid timing advance via this EDT procedure. This is applicable for RRC connection setup case also.

Referring to <FIG>, this figure is a logic flow diagram performed by a UE for maintaining, suspending, or modifying existing PUR configuration in response to the UE entering into RRC connected mode. This figure illustrates the operation of an exemplary method or methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiments. The blocks in this figure are performed by a UE <NUM>, e.g., under control of the PUR communication (Comm. ) module <NUM>, at least in part.

In block <NUM>, the flow starts with determining, at a user equipment configured with an idle-mode configuration for using a preconfigured uplink resource, that data not associated with the preconfigured uplink resource is to be transmitted or to be received via a radio resource control connection. In block <NUM>, the flow proceeds with performing by the user equipment an initial access to the network for the radio resource control connection. The UE <NUM>, in block <NUM>, performs transitioning from radio resource control idle mode to radio resource control connected mode. The UE <NUM> in block <NUM> performs one of suspending the idle-mode configuration or maintaining the idle-mode configuration, for at least a duration of the radio resource control connected mode.

Turning to <FIG>, this figure is a logic flow diagram performed by a network element for maintaining, suspending, or modifying existing PUR configuration in response to the UE entering into RRC connected mode. This figure illustrates the operation of an exemplary method or methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiments. The blocks in this figure are performed by a network element, which is assumed to be a base station such as an eNB (or other RAN node) <NUM>, e.g., under control of the PUR communication (Comm. ) module <NUM>, at least in part.

In block <NUM>, the flow starts with receiving at a base station in a wireless communication network an initial access to the network for the radio resource control (RRC) connection. The base station in block <NUM> determines that the user equipment is configured with an idle-mode configuration for using a preconfigured uplink resource. The base station performs, in block <NUM>, transitioning the user equipment from RRC idle mode to RRC connected mode. In block <NUM>, the base station performs communication between the base station and the user equipment to perform one or more actions to modify one or both of an RRC connection corresponding to the transition into the RRC connected mode or the idle-mode configuration of the user equipment.

Exemplary advantages, technical effects, and invention aspects include one or more of the following:.

For (<NUM>), some embodiments were described above where D-PUR is suspended or released during an RRC connection. This can be understood as a rule to prioritize PUSCH (granted in the RRC connection) over PUR. In other embodiments, the UE combines both PUR and PUSCH resources granted in the RRC connection. This can be interpreted as another priority rule.

Similarly, for (<NUM>), in some embodiments, a rule for the counters/timers is described as part of the rule that applies to the PUR.

Embodiments herein may be implemented in software (executed by one or more processors), hardware (e.g., an application specific integrated circuit), or a combination of software and hardware. In an example embodiment, the software (e.g., application logic, an instruction set) is maintained on any one of various conventional computer-readable media. In the context of this document, a "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted, e.g., in <FIG>. A computer-readable medium may comprise a computer-readable storage medium (e.g., memories <NUM>, <NUM>, <NUM> or other device) that may be any media or means that can contain, store, and/or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer. A computer-readable storage medium does not comprise propagating signals.

Although various aspects are set out above, other aspects comprise other combinations of features from the described embodiments, and not solely the combinations described above.

Claim 1:
A method, comprising:
determining, at a user equipment (<NUM>) configured with an idle-mode configuration for using a preconfigured uplink resource, that data not associated with the preconfigured uplink resource is to be transmitted or to be received via a radio resource control connection;
performing by the user equipment (<NUM>) an initial access to a network (<NUM>) for the radio resource control connection;
transitioning, by the user equipment (<NUM>), from radio resource control idle mode to radio resource control connected mode; and
performing, by the user equipment (<NUM>), one of suspending the idle-mode configuration or maintaining the idle-mode configuration, for at least a duration of the radio resource control connected mode.