HANDLING OF EARLY MEASUREMENT CONFIGURATION IN 2-STEP RE-RECORDING REQUEST - RELEASE

Description

Technical Field

[0001] The present disclosure relates to measurements performed by a wireless device while in a power savings state and, in particular, handling of a measurement configuration for measurements performed by a wireless device while in a power savings state.BackgroundCarrier Aggregation (CA) and Dual Connectivity (DC) in Long Term Evolution (LTE)

[0002] In Third Generation Partnership Project (3GPP) LTE Release 10, CA was introduced to enable the User Equipment (UE) to transmit and / or receive information via multiple cells, which are referred to as Secondary Cells (SCell(s), from multiple carrier frequencies to benefit of the existence of non-contiguous and contiguous carriers. In CA terminology, the Primary Cell (PCell) is the cell towards which the UE establishes the Radio Resource Control (RRC) connection or performs handover. In CA, cells are aggregated on the Medium Access Control (MAC) level. The MAC layer gets grants for a certain cell and multiplexes data from different bearers to one transport block being sent on that cell, as illustrated in Figure 1. Also, the MAC layer controls how that process is done.

[0003] SCells can be "added" for the UE using RRC signaling (e.g., RRCConnectionReconfiguration), which takes in the order of hundreds of milliseconds. Note that "adding" an SCell is also referred to as "configuring" the SCell. A cell which is configured for the UE becomes a "serving cell" for this UE. An SCell may also be associated with an SCell state. When configured / added via RRC signaling, an SCell starts in a deactivated state. In LTE Release 15, the enhanced or evolved Node B (eNB) can indicate to activate-upon-configuration, or change the state, at least in RRCReconfiguration, as shown in the excerpt below from 3GPP Technical Specification (TS) 36.331 V15.3.0:

[0004] In LTE Release 15, a new intermediate state between the deactivated and active state has been introduced for enhanced uplink operation. A MAC Control Element (CE) can be used to change the SCell state between the three states as shown in Figure 2. There are also timers in the MAC layer to move a cell between the deactivated, activated, and dormant states. These timers are: sCellHibernationTimer, which moves the SCell from activated state to dormant state, sCellDeactivationTimer, which moves the SCell from activated state to deactivated state, and dormantSCellDeactivationTimer, which moves the SCell from dormant state to deactivated state. The MAC level SCell activation takes on the order of 20-30 milliseconds (ms).

[0005] Once the network understands the need to configure and / or activate CA, the question is which cells to initially configure and / or activate, if they are configured, and / or whether a cell / carrier is good enough in terms of radio quality / coverage (e.g., Reference Signal Receive Power (RSRP) and Reference Signal Receive Quality (RSRQ)). To understand the conditions on SCell(s) or potential SCell(s) in a given available carrier, the network may configure the UE to perform Radio Resource Management (RRM) measurements.

[0006] Typically, the network may be assisted by RRM measurements to be reported by a UE. The network may configure the UE with measurement identities (IDs) associated to reportConfig with event A1 (serving cell becomes better than threshold) in case this is a configured SCell, or A4 (neighbor cell becomes better than threshold) for carriers without a configured SCell. The measurement objects are associated to the carrier on which the network wants reports. If the network is aware of the exact cells it wants the UE to measure, a so-called white cell list can be configured in the measurement object so that the UE is only required to measure these cells in that carrier.

[0007] Figure 3 illustrates a process in which the network decides to setup CA or DC for a UE. The network then configures the UE to perform measurements, and the UE sends the appropriate measurement reports to the network. Based on the received measurement reports, the network makes a decision on SCell addition or SCell activation and then configures the UE to add the selected SCell(s).

[0008] With the introduction of DC in Release 12, it was possible to add what is called Secondary Cell Group (SCG) configuration to the UE. The main benefit would be that the UE could in principle add a cell from another eNB. Protocol-wise, that would require different MAC entities, one for each cell group. The UE will have two cell groups, one associated to the PCell (master node) and another associated to a Primary Secondary Cell (PSCell) (of the secondary eNB), where each group may possibly have their own associated SCells.

[0009] When it comes to adding SCells, when the UE is in single connectivity, the RRCConnectionReconfiguration message may carry a cell index (so MAC identifiers are optimized, i.e., shorter), cell identifier and carrier frequency, common parameters, and state information, introduced in Release 15 (activated or dormant).

[0010] Below excerpts from 3GPP TS 36.331 V15.3.0 illustrating and describing the SCellToAddModList included in the RRCConnectionReconfiguration are provided.

[0011] The procedure to add SCells to the Master Cell Group (MCG) in LTE (or to modify) is described as follows, as in TS 36.331 V15.3.0: Inter- Radio Access Technology (RA T) and Inter Fifth Generation (5G) Core (5GC) Interworking in LTE and New Radio (NR)

[0012] 5G in 3GPP introduces both a new core network, which is referred to as the 5GC, and a new Radio Access Network (RAN), which is referred to as NR. The 5GC will, however, also support RATs other than NR. It has been agreed that LTE (or Evolved Universal Terrestrial Radio Access (E-UTRA)) should also be connected to 5GC. LTE base stations (eNBs) that are connected to 5GC are called ng-eNBs and are part of Next Generation RAN (NG-RAN), which also includes NR base stations called gNBs. Figure 4 shows how the base stations are connected to each other and the nodes in 5GC. In particular, Figure 4 is the 5G System (5GS) architecture containing 5GC and NG-RAN.

[0013] There are different ways to deploy a 5G network with or without interworking with LTE (also referred to as E-UTRA) and Evolved Packet Core (EPC), as depicted in Figure 5. In principle, NR and LTE can be deployed without any interworking, denoted by NR Stand-Alone (SA) operation, that is the gNB in NR can be connected to 5GC and the eNB can be connected to EPC with no interconnection between the two (Option 1 and Option 2 in Figure 5). On the other hand, the first supported version of NR is the so-called Evolved Universal Terrestrial Radio Access Network (E-UTRAN) NR DC (EN-DC), illustrated by Option 3 in Figure 5. In such a deployment, DC between NR and LTE is applied with LTE as the master and NR as the secondary node. The RAN node (gNB) supporting NR may not have a control plane connection to the core network (EPC); instead, the gNB relies on the LTE as master node (Master eNB (MeNB)). This is also called "Non-standalone NR". Notice that in this case the functionality of an NR cell is limited and would be used for connected mode UEs as a booster and / or diversity leg, but an RRC_IDLE UE cannot camp on these NR cells.

[0014] With introduction of 5GC, other options may be also valid. As mentioned above, Option 2 in Figure 5 supports stand-alone NR deployment where the gNB is connected to 5GC. Similarly, LTE can also be connected to 5GC using Option 5 (also known as enhanced LTE (eLTE), E-UTRA / 5GC, or LTE / 5GC and the node can be referred to as an ng-eNB). In these cases, both NR and LTE are seen as part of the NG-RAN (and both the ng-eNB and the gNB can be referred to as NG-RAN nodes). It is worth noting that Option 4 and Option 7 are other variants of DC between LTE and NR which will be standardized as part of NG-RAN connected to 5GC, denoted by Multi-Radio DC (MR-DC). Under the MR-DC umbrella, we have: EN-DC (Option 3): LTE is the master node and NR is the secondary node (EPC CN employed) NR E-UTRA (NE) - DC (Option 4): NR is the master node and LTE is the secondary node (5GC employed) Next Generation DC (NGEN-DC) (Option 7): LTE is the master node and NR is the secondary node (5GC employed) NR-DC (variant of Option 2): DC where both the master and secondary nodes are NR (5GC employed).

[0015] As migration for these options may differ from different operators, it is possible to have deployments with multiple options in parallel in the same network, e.g. there could be an eNB base station supporting options 3, 5, and 7 in the same network as a NR base station supporting options 2 and 4. In combination with DC solutions between LTE and NR, it is also possible to support CA in each cell group (i.e., MCG and SCG) and DC between nodes on the same RAT (e.g., NR-NR DC). For the LTE cells, a consequence of these different deployments is the co-existence of LTE cells associated to eNBs connected to EPC, 5GC, or both EPC / 5GC.Suspend / Resume in LTE and Relation to CA / SCell and SCG Additions

[0016] A very typical scenario or use case is a UE with some burst traffic that comes and goes, e.g. some video packets and idle periods of transmission / reception, then comes live again. To save UE power, the network transitions the UE from connected to idle during these periods. Then, the UE comes back again (either via paging or UE request to get connected) and accesses the network.

[0017] In LTE Release 13, a mechanism was introduced for the UE to be suspended by the network in a suspended state similar to RRC_IDLE but with the difference that the UE stores the Access Stratum (AS) context or RRC context. This makes it possible to reduce the signaling when the UE is becoming active again by resuming the RRC connection, instead of as prior to establish the RRC connection from scratch. Reducing the signaling could have several benefits: reduced latency, e.g., for smart phones accessing the Internet, and reduced signaling leads to reduced battery consumption for machine type devices sending very little data.

[0018] The Release 13 solution is based on the UE sending a RRCConnectionResumeRequest message to the network and, in response, the UE may receive an RRCConnectionResume from the network. The RRCConnectionResume is not encrypted but integrity protected.

[0019] The resume procedure in LTE can be found in the RRC specifications (3GPP TS 36.331). As the UE performing resume is in RRC_IDLE (with suspended AS context), a transition from RRC_IDLE to RRC_CONNECTED is triggered. Hence, this is modelled in the specifications in the same subclause that captures the RRC connection establishment (i.e., 3GPP TS 36.331, subclause 5.3.3 RRC connection establishment).

[0020] There are few things relevant to highlight in the SCG configurations and SCell configurations for MCGs in relation to suspend / resume procedures. Upon suspension, it is defined that the UE stores its used RRC configuration. In other words, if the UE is operating in any DC mode (and has an SCG configuration) or has just configured SCells in the MCG, the UE stores all these configurations. However, upon resume, at least until Release 15, it is defined that the UE shall release the SCG configurations and SCell configurations, as shown in the excerpt from 3GPP TS 36.331 V15.3.0 below: Hence, when the UE comes from RRC_IDLE with the context, if the network wants to add SCell(s) to the MCG or add an SCG, the network needs to do that from scratch, even if the UE is suspending and resuming in the same cell / area where all the previous PCell and SCell configurations are still valid from a radio conditions perspective.

[0021] As the use case of UEs with burst traffic constantly being suspended and resuming in the same cell is quite typical, 3GPP has standardized a solution in LTE to enable the UE to assist the network with measurements performed while the UE is in RRC_IDLE so that the network can speed up the setup of CA or DC. That solution is described below.Existing Solution for Early Measurements upon Idle to Connected Transition in LTE (Release 15)

[0022] In LTE Release 15, it is possible to configure the UE to report so-called "early measurements" upon the transition from idle to connected state. These measurements are measurements that the UE can perform in idle state and according to a configuration provided by the source cell. The intention is for the network to receive these measurements immediately after the UE is connected such that the network can quickly set up CA and / or other forms of DC (e.g., EN-DC, MR-DC, etc.) without the need for the network to first provide a measurement configuration (measConfig) in RRC_CONNECTED, as shown in previous sections, and then wait for hundreds of milliseconds until first samples are collected, monitored, and reported to the network.

[0023] In regarding to measurement configuration for early measurements upon resume in LTE, a first aspect of the existing solution, as standardized in 3GPP TS 36.331, is described in 5.6.20 Idle Mode Measurements. The UE can receive these idle mode measurement configurations in the system information (System Information Block 5 (SIB5)) in the field MeasIleConfigSIB-r15, indicating up to 8 cells or ranges of cell IDs on which to perform measurements. In addition, the UE can be configured upon the transition from RRC_CONNECTED to RRC_IDLE with a dedicated measurement configuration in the RRCConnectionRelease message with the measIdleDedicated-r15 which overrides the broadcasted configurations in SIB5. An excerpt from 3GPP TS 36.331 V15.3.0 showing the broadcasted and dedicated signaling is provided below:

[0024] Carrier information and cell list: The UE is provided with a list of carriers and optionally with a list of cells on which the UE shall perform measurements. The fields s-NonIntraSearch in SystemInformationBlockType3 do not affect the UE measurement procedures in IDLE mode.

[0025] Timer T331: Upon the reception of that measurement configuration, the UE starts a timer T331 with the value provided in measIdleDuration, which can go from 0 to 300 seconds. The timer stops upon receiving RRCConnectionSetup, RRCConnectionResume which indicates a transition to RRC_CONNECTED. That concept exists to limit the amount of time the UE performs measurements for the purpose of early measurements.

[0026] Validity Area: Another concept introduced in the LTE Release 15 solution is a validity area, which comprises a list of Physical Cell Identities (PCIs). The intention is to limit the area where CA or DC may be setup later when the UE resumes / setups the connection, so the early measurements are somewhat useful for that purpose. If validityArea is configured, and the UE reselects to a serving cell whose PCI does not match any entry in validityArea for the corresponding carrier frequency, the timer T331 is stopped. Then, the UE stops to perform IDLE measurements and releases the configuration (i.e., VarMeasIdleConfig). Notice that this does not necessarily imply that the UE releases the idle measurements that were configured in Release and that were performed, i.e. these may still be stored and possibly requested by the network. In addition, the UE may continue with IDLE mode measurements according to the broadcasted SIB5 configuration after the timer T331 has expired or stopped.

[0027] Minimum quality threshold: Notice also that only measurements above a certain threshold shall be stored as the cell candidates for CA setup need to be within a minimum acceptable threshold. How the UE performs measurements in IDLE mode is up to UE implementation as long as RAN4 requirements for measurement reporting defined in 36.133 are met.

[0028] The excerpt below from 3GPP TS 36.331 V15.3.0 shows the UE behavior in more detail:

[0029] Notice that it is not mandatory for the source node releasing / suspending the UE to provide a dedicated idle measurement configuration for the purpose of early measurements. If the UE is released / suspended to idle without being provided with a list of carriers to be measured, the UE obtains that from SIB2, as written in the excerpt from 3GPP TS 36.331 V15.3.0 below: And, in the case of the list not being provided in RRCConnectionRelease, at every cell reselection the UE performs the SIB5 acquisition to possibly update its list of carriers to measure as shown in the excerpt from 3GPP TS 36.331 V15.3.0 below:

[0030] If the UE enters a cell within the validity area that is not broadcasting the measurement configuration in SIB5, the UE continues to perform idle measurements according to the SIB5 acquired in the source cell (i.e., the cell the UE was suspended or released).RRC_INACTIVE in NR and possible in LTE Release 15

[0031] As part of the standardized work on 5G NR in 3GPP, it has been decided that NR should support an RRC_INACTIVE state with similar properties as the suspended state in LTE Release 13. The RRC_INACTIVE has slightly different properties from the late state in that it is a separate RRC state and not part of RRC_IDLE as in LTE. Additionally, the Core Network (CN) / RAN connection (NG or N2 interface) is kept for RRC_INACTIVE while it was suspended in LTE. Figure 6 is a figure showing a state machine and possible state transitions in NR.

[0032] The properties of the states above is as follows: RRC_IDLE: ∘ A UE specific Discontinuous Reception (DRX) may be configured by upper layers; ∘ UE controlled mobility based on network configuration; ∘ The UE: ▪ Monitors a Paging channel for CN paging using 5G System Architecture Evolution Temporary Mobile Subscriber Identity (5G-S-TMSI); ▪ Performs neighboring cell measurements and cell (re-)selection; ▪ Acquires system information. RRC_INACTIVE: ∘ A UE specific DRX may be configured by upper layers or by RRC layer; ∘ UE controlled mobility based on network configuration; ∘ The UE stores the AS context; ∘ The UE: ▪ Monitors a Paging channel for CN paging using 5G-S-TMSI and RAN paging using Inactive Radio Network Temporary Identifier (I-RNTI); ▪ Performs neighboring cell measurements and cell (re-)selection; ▪ Performs RAN-based notification area updates periodically and when moving outside the RAN-based notification area; ▪ Acquires system information. RRC_CONNECTED: ∘ The UE stores the AS context. ∘ Transfer of unicast data to / from UE. ∘ At lower layers, the UE may be configured with a UE specific DRX; ∘ For UEs supporting CA, use of one or more SCells, aggregated with the Special Cell (SpCell), for increased bandwidth; ∘ For UEs supporting DC, use of one SCG, aggregated with the MCG, for increased bandwidth; ∘ Network controlled mobility, i.e. handover within NR and to / from E-UTRAN. ∘ The UE: ▪ Monitors a Paging channel; ▪ Monitors control channels associated with the shared data channel to determine if data is scheduled for it; ▪ Provides channel quality and feedback information; ▪ Performs neighboring cell measurements and measurement reporting; ▪ Acquires system information. Introducing Early Measurements upon Idle / Inactive to Connected Transition in NR (Release 16)

[0033] A work item has been approved in Release 16 to enhance the setup of CA / DC in NR. The Work Item Description (WID) "Enhancing CA Utilization" was approved in RAN#80 in RP-181469, and updated in RAN#81 in RP-182076 and, one of the objectives is the following: Early Measurement reporting: Early and fast reporting of measurements information availability from neighbor and serving cells to reduce delay setting up MR-DC and / or CA. [RAN2, RAN4] ∘ This objective applies to MR-DC, NR-NR DC and CA ∘ The objective should consider measurements in IDLE, INACTIVE mode and CONNECTED mode ∘ The impacts on UE power consumption should be minimized ∘ The LTE Rel-15 euCA work should be utilized, when applicable

[0034] Hence, 3GPP is going to investigate solutions to enable early measurements performed when the UE is in RRC_INACTIVE or RRC_IDLE state and, reporting mechanisms for when the UE enters RRC_CONNECTED.

[0035] Based on contributions submitted to RAN2#105 to Athens, three different kinds of solutions are going to be considered: 1. UE reports early measurements in UEInformationResponse after request from network in UEInformationRequest transmitted after the UE sends an RRCResumeComplete or, after security is activated when UE comes from idle without stored context (as in LTE Release 15); 2. UE reports early measurements with (e.g., multiplexed with or as part of the message) RRCResumeComplete; and 3. UE reports early measurements with (e.g., multiplexed with or as part of the message) RRCResumeRequest.

[0036] There are some differences in details of each of these solutions, and not all of them may be applicable for RRC_IDLE in the same way they are for RRC_INATIVE. However, in any of these solutions for the reporting, the UE relies on a measurement configuration, which may be provided with dedicated signaling when the UE is suspended to RRC_INACTIVE or when the UE is released to RRC_IDLE. That measurement configuration indicates how the UE shall perform these measurements to be reported when the UE resumes (in the case of coming from RRC_INACTIVE or setups up a connection, in the case of coming from RRC_IDLE).

[0037] Then, as this has not yet been agreed for NR, one can consider that the existing solution for the handling of early measurement configuration for NR is like that in LTE, i.e.: UE receives a measurement configuration (for early measurement reporting) containing a list of carrier frequencies in dedicated signaling (e.g., in RRCRelease message) when the UE is released to IDLE or suspended to INACTIVE; UE receives a measurement configuration (for early measurement reporting) not containing a list of carrier frequencies in dedicated signaling (e.g., in RRCRelease message) when the UE is released to IDLE or suspended to INACTIVE. Then, UE obtains the list of carriers from a SIB (e.g., SIB2, SIB3, SIB4, SIB5, etc.). Upon cell reselection the UE checks if it needs to update its carrier frequency list for early measurements based on a SIB of the target cell. Problems with Existing Solutions

[0038] There currently exist certain challenge(s) in regard to early measurements, particularly in NR.

[0039] Document 3GPP TSG RAN WG2 Meeting #105 R2-1900104 "Supporting early measurement reporting in NR" relates to early measurement reporting in NR.Summary

[0040] Systems and methods are disclosed herein for handling measurement configurations for a power saving state and / or handling associated measurements, upon receiving a message from a network node while performing measurements in accordance with the measurement configurations while in the power saving state.

[0041] The invention is defined by the appended claims.Brief Description of the Drawings

[0042] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure. Figure 1 illustrates Carrier Aggregation (CA) from the perspective of the Medium Access Control (MAC) layer; Figure 2 illustrates transitions between different User Equipment (UE) states; Figure 3 illustrates a process in which the network decides to setup CA or Dual-Connectivity (DC) for a UE; Figure 4 illustrates the Fifth Generation (5G) System (5GS) architecture; Figure 5 illustrates different ways to deploy a 5G network with or without interworking with Long Term Evolution (LTE); Figure 6 illustrates a state machine and possible state transitions in New Radio (NR); Figure 7 illustrates a scenario in NR in which a Radio Resource Control (RRC) connection resume is followed by a successful network suspend; Figure 8 illustrates a scenario in NR in which a RRC connection resume is followed by a successful network release; Figure 9 illustrates one example of a cellular communications network in which embodiments of the present disclosure may be implemented; Figure 10 illustrates the operation of a UE in accordance with some embodiments of the present disclosure; Figure 11 illustrate the operation of a source network node in accordance with some embodiments of the present disclosure; Figure 12 illustrate the operation of a target network node in accordance with some embodiments of the present disclosure; Figures 13 through 15 are schematic block diagrams of example embodiments of a radio access node; Figures 16 and 17 are schematic block diagrams of example embodiments of a UE; Figure 18 illustrations another example of a system in which embodiments of the present disclosure may be implemented; Figure 19 illustrates example embodiments of the host computer, base station, and UE of Figure 18; and Figures 20 through 23 are flowcharts illustrating methods implemented in a communication system, such as that of Figure 18, in accordance with some embodiments of the present disclosure. Detailed Description

[0043] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0044] Radio Node: As used herein, a "radio node" is either a radio access node or a wireless device.

[0045] Radio Access Node: As used herein, a "radio access node" or "radio network node" is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and / or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), and a relay node.

[0046] Core Network Node: As used herein, a "core network node" is any type of node in a core network. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), or the like.

[0047] Wireless Device: As used herein, a "wireless device" is any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting and / or receiving signals to a radio access node(s). Some examples of a wireless device include, but are not limited to, a User Equipment device (UE) in a 3GPP network and a Machine Type Communication (MTC) device.

[0048] Network Node: As used herein, a "network node" is any node that is either part of the RAN or the core network of a cellular communications network / system.

[0049] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0050] Note that, in the description herein, reference may be made to the term "cell"; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

[0051] In LTE, the idle measurements feature (sometimes called early measurements) consists of the UE receiving a measurement configuration when it transitions from RRC_CONNECTED to RRC_IDLE (RRC_IDLE with a stored context or RRC_IDLE without a stored context). The UE then starts a validity timer and, while the validity timer is running, the UE performs the so-called idle measurements according to the provided configuration. The dedicated signaling in RRCConnectionRelease may contain a list of carrier frequencies to be measured. If that is not present in the measurement configuration, the UE obtains the list of carrier frequencies in System Information Block 5 (SIB5) of the source cell from which the UE is being released. The list of carrier frequencies may be updated at every cell reselection upon acquiring SIB5 in the target cell to which the UE reselects.

[0052] Upon receiving the measurement configuration when going to RRC_IDLE, the UE starts the validity timer (i.e., T331) with a value received as part of the configuration. The UE performs idle measurements while the timer (T331) is running. According to the LTE Radio Resource Control (RRC) specification (i.e., 3GPP Technical Specification (TS) 36.331), the UE is not required to perform these measurements if the timer (T331) is not running, which occurs in the following cases: the timer (T331) stops if the UE reselects to a cell not within the configured validity area; the timer (T331) stops when it expires; the timer (T331) stops when the UE receives an RRCConnectionResume or an RRCConnectionSetup message i.e. UE enters RRC_CONNECTED. This is summarized in the RRC specifications of LTE in the following table from 3GPP TS 36.331 V15.30: Timer Start Stop At expiry T331Upon receiving RRCConnectionRelease message including measIdleConfig.Upon receiving RRCConnectionSetup, RRCConnectionResume or, if validityArea is configured, upon reselecting to cell that does not belong to validityArea.Release the stored VarMeasIdleConfig.

[0053] When the timer expires or is stopped (i.e., in the cases above), the UE releases the measurement configuration used for the idle measurements, i.e. it releases the UE variable where the configuration is stored (VarMeasIdleConfig), as shown in the excerpt from 3GPP TS 36.331 V15.3.0 below:

[0054] The existing solution for LTE says that the UE stops performing idle measurements (i.e., to support early measurements reporting) upon cell reselection to a cell not in the UE's configured validity area or upon the reception of RRCConnectionSetup or the reception of RRCConnectionResume. This is defined by stopping the timer controlling early measurements (i.e., T331 in LTE) in these scenarios.

[0055] In NR, a first new scenario is when an RRC_INACTIVE UE transmits an RRCResumeRequest or RRCResumeRequest1 message and receives an RRCRelease message with suspend configuration in response. The reception of the RRCRelease message with suspend configuration indicates that the UE is to remain in RRC_INACTIVE, which is equivalent to doing a very quick transient transition to RRC_CONNECTED and then to RRC_INACTIVE again. This is shown in Figure 7, which illustrates an RRC connection resume followed by a successful network suspend.

[0056] In NR, a second new scenario is when an RRC_INACTIVE UE transmits an and receives an RRCRelease without a suspend configuration in response. The reception of the RRCRelease without a suspend configuration indicates that the UE is to transition to RRC_IDLE, which is equivalent to doing a very quick transient transition to RRC_CONNECTED and then to RRC_IDLE. This is shown in Figure 8, which illustrates an RRC connection resume followed by a successful network release.

[0057] There are different cases where the network may respond a Resume Request like message (RRCResumeRequest or RRCResumeRequest1 as shown in the flows of Figures 7 and 8) with an RRCRelease message, such as when the resume procedure is triggered due to a mobility-based RAN area Update or periodic RAN area Update or when the network wants to redirect the UE to another frequency (in the same Radio Access Technology (RAT) or different RAT).

[0058] If the existing solution in LTE is adopted in NR, the UE may be performing early measurements (e.g., according to a configuration provided in RRCRelease or obtained in a SIB) when it tries to resume (i.e., when it sends an RRC Resume Request like message) and receives in response a new RRCRelease message that may or may not contain a new measurement configuration for early measurements. In this scenario, it remains unclear as to what the UE is to do with the stored configuration for early measurements, the timer controlling the measurements, and the measurement results, and whether the UE is to continue to perform measurements or not.

[0059] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Embodiments of a method executed by a UE for handling at least one measurement configuration (e.g., provided for idle / inactive measurements, for early measurement reporting when transition to CONNECTED) are disclosed. In some embodiments, the method executed by the UE comprises one or more of the following aspects: The UE receives, while in CONNECTED state or while in a power saving state when attempting to enter CONNECTED state, an RRC Release like message to transition to a power saving state (e.g., INACTIVE, IDLE, IDLE with stored context, IDLE without stored context, etc.), stores an idle / inactive measurement configuration (e.g., for early measurement reporting) that may be contained in the message, and starts a timer possibly with a received value (e.g., timer T331). The message may contain a validity area for the idle / inactive measurements. The UE performs measurements according to the received measurement configuration upon entering the power saving state (e.g., INACTIVE or IDLE), while the timer (e.g., T331) is running. While the timer (e.g., T331) controlling measurements in power saving state (e.g., INACTIVE, IDLE, etc.) is running and the UE is trying to resume an RRC connection (e.g., transmitting an RRC Resume Request like message), the UE receives, in response to trying to resume the RRC connection, an RRC Release like message and performs a set of actions to handle the measurement configurations for power saving state (e.g., for early measurement reporting) and measurements associated to the stored measurement configuration(s). ∘ In a first solution, the UE stops the timer (e.g., T331) and performs a set of cleaning actions such as clearing / releasing the measurement configuration and measurement results. ∘ In a second solution, ▪ If the UE receives an RRC release like message in response to an RRC Resume like message while the timer T331 (or equivalent) is running and the message does not contain a measurement configuration for measurements in IDLE / INACTIVE (e.g., for early measurement reporting), the UE does not stop the timer (e.g., T331) and does not perform a set of cleaning actions (i.e., it does not clear the UE Inactive AS Context (containing the measurement configuration and measurement results). Hence, in some embodiments, the absence of a measurement configuration field (e.g., measIdleInactiveConfig-r16) in the RRC Release like message indicates that the UE shall continue performing measurements that have been previously configured according to a stored measurement configuration. That case may be applied in case the UE tried to resume and was released / suspended by the network, possibly without using context fetching (e.g., in an Radio Network Subsystem Application Part (RNSAP) User Adaptation (RNA) update without context fetching where the last serving node suspends / Releases the UE). ▪ Else, if the UE receives an RRC release like message in response to an RRC Resume like message while timer T331 (or equivalent) is running and the message contains a measurement configuration for measurements in IDLE / INACTIVE, e.g. for early measurement reporting, the UE performs a set of cleaning actions (i.e., clears the UE variables containing the measurement configuration and measurement results). ∘ In a third solution: ▪ If the UE receives an RRC release like message in response to an RRC Resume like message while timer T331 (or equivalent) is running and the message does not contain a measurement configuration for measurements in IDLE / INACTIVE e.g. for early measurement reporting, the UE does not stop the timer (e.g. T331) and does not perform a set of cleaning actions (i.e. it does not clear the UE Inactive Access Stratum (AS) Context (containing the measurement configuration and measurement results). Hence, the absence of the measurement configuration field (e.g. measIdleInactiveConfig-r16) in the RRC Release like message indicates that the UE shall continue performing measurements that have been previously configured. That case may be applied in case the UE tried to resume and was released / suspended by the network, possibly without using context fetching (e.g. in an RNA update without context fetching where the last serving node suspends / Releases the UE). ▪ Else, if the UE receives an RRC release like message (in response to an RRC Resume like message) while timer T331 (or equivalent) is running and the message contains a measurement configuration for measurements in IDLE / INACTIVE e.g. for early measurement reporting, the UE may perform at least one of the following actions: The UE adds a new entry in its stored measurement configuration i.e. the UE adds a new carrier frequency to its list of stored measurement configurations. ∘ In one variant, upon addition, the UE re-starts the timer T331 (or equivalent) with a stored value in the UE variable containing the configuration. ∘ In one variant, upon addition, the UE does not re-start the timer T331 (or equivalent). The UE modifies a stored configuration in its stored measurement configuration i.e. the UE changes any field defined per carrier frequency in its list of stored measurement configurations. ∘ In one variant, upon modification, the UE re-starts the timer T331 (or equivalent) with a stored value in the UE variable containing the configuration. ∘ In one variant, upon modification, the UE does not re-start the timer T331 (or equivalent). The UE removes an existing entry in its list of stored measurement configurations and, stops performing measurement according to the removed configuration. ∘ In a fourth solution: ▪ If the UE receives an RRC release like message in response to an RRC Resume like message while timer T331 (or equivalent) is running and the message contains a suspendConfig, i.e., an indication that the UE remains in INACTIVE state, any of the solutions described above could apply (e.g. first, second or third solutions). ▪ Else, if the message does not contain a suspendConfig, an indication that the UE shall transition to IDLE state, the UE stops the timer T331 and performs the set of clean up actions such as delete the measurements, delete the configurations, and clear the UE variables. Fifth solution: While the timer (e.g. T331) controlling measurements in power saving state (e.g. INACTIVE, IDLE, etc.) is running and the UE is trying to resume an RRC connection (i.e. transmitting an RRC Resume Request like message), the UE receives, in response to trying to resume the RRC connection, an RRC Resume like message and enters CONNECTED state. Upon that, the UE stops the timer T331 (or equivalent), stops performing the measurements, and stores the measurement configurations for power saving state (e.g. for early measurement reporting) while in CONNECTED state. ∘ In some embodiments, the inactive / idle measurement configurations may be stored in a UE variable while the UE is in CONNECTED state. ∘ In some embodiments, when the UE in CONNECTED receives an RRC Release message, the UE restores the idle / inactive measurement configuration. Further, in some embodiments, if the RRC Release message does not contain an idle / inactive measurement configuration, the UE resumes the restored configuration; otherwise, if the RRC Release message contains an idle / inactive measurement configuration, delta signaling applies. ∘ That could be useful in case the UE triggers a Non-Access Stratum (NAS) signaling procedure in INACTIVE state e.g. a Tracking Area Update that requires the UE to enter CONNECTED for a short time. Then, with this solution, the network would not need to re-configure the idle / inactive measurements.

[0060] For any of the abovementioned topics, there may be different associated network embodiments. Below, a subset of these network embodiments is described.

[0061] Embodiments of a method executed by a source network node are also disclosed. In some embodiments, the method comprises one or more of the following: The source network node transmits, to a UE in CONNECTED state, an RRC Release message with a suspend configuration indicating that the UE shall transition to INACTIVE state or without a suspend configuration indicating that the UE shall transition to IDLE, where the message comprises a measurement configuration for idle / inactive measurements e.g. for early measurement reporting, a timer value (e.g. T331), and a validity area. The source network node stores the provided idle / inactive measurement configuration in the UE Inactive AS Context. The source network node receives a request from a target network node to retrieve the UE Inactive AS Context. The source network node retrieves the context and, if the UE is verified, provides the context to the target node.

[0062] Embodiments of a method executed by a target network node are also disclosed. In some embodiments, the method comprises one or more of the following: The target network node receives a Resume Request message from an inactive UE. The target network node retrieves the UE Inactive AS Context or, identifies that the context is stored in another node. The target network node determines whether the idle / inactive measurement configuration is present. If present, the target network node determines whether they should be added, modified, or released (according to any of the solutions described above for handling the measurement configurations) in an RRC Release message to the UE.

[0063] In some embodiments, while the timer (e.g. T331) controlling measurements in power saving state (e.g. INACTIVE, IDLE, etc.) is running, the UE tries to resume an RRC connection (i.e. transmitting an RRC Resume Request like message) and receives, in response, an RRC Release like message. In some embodiments, the UE performs a set of actions to handle the measurement configurations for power saving state (e.g. for early measurement reporting) and measurements associated to the configuration(s).

[0064] Certain embodiments may provide one or more of the following technical advantage(s). By using embodiments of the present disclosure, the UE is capable of handling inactive / idle measurement configurations and stored measurements when the network responds an RRC Resume Request like message with an RRC Release like message, which may contain another inactive / idle measurement configuration. Further, embodiments of the method executed by the UE include different solutions that have different advantages, which are described below. Advantages of the first solution: Compared to the existing solution (i.e. LTE Rel-15 solution on idle measurements for early reporting), this solution is consistent and simple. It allows the possibility to receive an RRC Release in response to an RRC Resume, stop the measurements configured by the last serving node (e.g. where the UE was suspended or released), and remove the stored measurements. It also allows the network to configure the UE again with new measurement configuration for a similar purpose, if the network wants to do so. Another potential advantage of this solution is that the UE and network would not necessarily have to store the idle / inactive measurement configuration in the UE Inactive AS context; hence, there is no risk of state mismatch between the UE and the network. Advantages of the second solution: Compared to the first solution, this solution allows the network to let the UE continue to perform idle / inactive measurements according to the configuration that the UE has been configured by the source node when it was suspended last time (e.g. from CONNECTED) and possibly not bother to change that configuration (e.g. add or remove measurement configurations). At the same time, if network wants to do so, it still allows in the RRC Release to provide a new configuration. Upon that case, the UE deletes whatever it has stored and replaces it with new configurations and starts new measurements in the power saving state. Advantages of the third solution: Compared to previous solutions, this solution allows the network substantial flexibility to add, remove, or modify measurement configurations without necessarily discontinuing measurements at the UE. Advantages of the fourth solution: Compared to previous solutions, the UE only concerns itself with the handling of the idle / inactive measurement configuration when it transitions to inactive, and not idle. Advantages of the fifth solution: Compared to the existing solution, whenever a UE is configured to perform idle mode measurements in a power saving mode (INACTIVE, IDLE, etc.), the UE would store these configurations, allowing the network to release the UE back to a power saving mode without a need to signal the idle mode measurement configurations.

[0065] Embodiments of the present disclosure described herein refer to a measurement configuration provided in an RRC Release like message to be used when the UE is in a power saving state. That state may be at least an RRC state such as IDLE (without a stored context), IDLE (with a stored context), INACTIVE, etc. The power saving state may also be called sleeping or dormant state, as most of the actions require less power consumption than when the UE is in CONNECTED state.

[0066] The examples described herein explain the configuration of early measurements done by NG-RAN i.e. the UE is in CONNECTED state in NR and tries to resume in NR and, in response, receives an RRC Release like message. This should be an example, as the method is also applicable at least in any of the cases below: UE CONNECTED in NR is suspended to INACTIVE in NR and tries to resume in NR, receiving an RRC Release like message; UE CONNECTED in NR is suspended to IDLE in NR and tries to resume in NR, receiving an RRC Release like message; UE CONNECTED in LTE (or eLTE, i.e., LTE connected to 5G Core (5GC)) is suspended to INACTIVE in LTE and tries to resume in LTE, receiving an RRC Release like message; UE CONNECTED in LTE is suspended to IDLE in LTE and tries to resume in LTE, receiving an RRC Release like message; UE CONNECTED in NR is suspended to INACTIVE in NR and tries to resume in LTE, receiving an RRC Release like message; and UE CONNECTED in LTE is suspended to INACTIVE in LTE and tries to resume in NR, receiving an RRC Release like message.

[0067] Figure 9 illustrates one example of a cellular communications network 900 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications network 900 is an LTE or 5G NR network. In this example, the cellular communications network 900 includes base stations 902-1 and 902-2, which in LTE are referred to as eNBs and in 5G NR are referred to as gNBs, controlling corresponding macro cells 904-1 and 904-2. The base stations 902-1 and 902-2 are generally referred to herein collectively as base stations 902 and individually as base station 902. Likewise, the macro cells 904-1 and 904-2 are generally referred to herein collectively as macro cells 904 and individually as macro cell 904. The cellular communications network 900 may also include a number of low power nodes 906-1 through 906-4 controlling corresponding small cells 908-1 through 908-4. The low power nodes 906-1 through 906-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells 908-1 through 908-4 may alternatively be provided by the base stations 902. The low power nodes 906-1 through 906-4 are generally referred to herein collectively as low power nodes 906 and individually as low power node 906. Likewise, the small cells 908-1 through 908-4 are generally referred to herein collectively as small cells 908 and individually as small cell 908. The base stations 902 (and optionally the low power nodes 906) are connected to a core network 910.

[0068] The base stations 902 and the low power nodes 906 provide service to wireless devices 912-1 through 912-5 in the corresponding cells 904 and 908. The wireless devices 912-1 through 912-5 are generally referred to herein collectively as wireless devices 912 and individually as wireless device 912. The wireless devices 912 are also sometimes referred to herein as UEs.1 UE Methods

[0069] Embodiments of a method performed by (i.e., executed by) a UE for handling at least one measurement configuration (e.g. provided for early measurement reporting when transition to CONNECTED) are disclosed herein. In general, as illustrated in Figure 10, the method comprises the following steps. Step 1000: The UE receives Idle / Inactive Measurement Configuration(s). Step 1002: The UE performs Idle / Inactive Measurements. Step 1004: The UE performs a 2-step Resume / Release while performing the Idle / Inactive Measurements. Here, the UE handles the Idle / Inactive measurement configuration(s) when performing the 2-step resume / release, in accordance with any one of a number of solutions described herein. More specifically, the UE attempts an RRC resume by sending an RRC Resume Request like message (e.g., RRC Resume Request) (step 1004A). In response, the UE receives an RRC Release like message (e.g., an RRCRelease) or an RRC Resume like message (RRCResume) (step 1004B). The UE performs one or more actions to handle the Idle / Inactive measurement configuration(s), e.g., in accordance with any one of the first, second, third, fourth, or fifth solutions described below (step 1004C). ∘ First Solution: Upon transmitting a RRC Resume Request like message and, in response, receiving an RRC Release like message (e.g., while a timer for Idle / Inactive measurements is running), the UE releases the measurement configuration(s) and the measurement result(s). ∘ Second Solution: Upon transmitting a RRC Resume Request like message and, in response, receiving an RRC Release like message (e.g., while a timer for Idle / Inactive measurements is running), the UE keeps the measurement configuration(s) and the measurement result(s) unless the UE receives a new measurement configuration (e.g., unless the RRC Release like message includes a new Idle / Inactive measurement configuration(s)). ∘ Third Solution: Upon transmitting a RRC Resume Request like message and, in response, receiving an RRC Release like message (e.g., while a timer for Idle / Inactive measurements is running), the UE keeps and updates the measurement configuration(s) and the measurement result(s) (e.g., keeps the measurement configuration(s) if the RRC release like message does not include a new Idle / Inactive measurement configuration(s) or updates the measurement configuration(s) if the RRC Release like message does include a new Idle / Inactive measurement configuration(s)). ∘ Fourth Solution: Upon transmitting a RRC Resume Request like message and, in response, receiving an RRC Release like message (e.g., while a timer for Idle / Inactive measurements is running), the UE keeps the Idle / Inactive measurement configuration(s) if the RRC Release like message includes a suspendConfig (i.e., an indication that the UE remains in Inactive state) and otherwise releases the measurement configuration(s). ∘ Fifth Solution: Upon transmitting a RRC Resume Request like message and, in response, receiving an RRC Resume like message (e.g., while a timer for Idle / Inactive measurements is running), the UE keeps the Idle / Inactive measurement configuration(s). Additional details of each of these steps and solutions are provided below.1.1 Step 1000: Receiving Idle / Inactive Measurement Configuration(s)

[0070] While in CONNECTED state or a power saving state when attempting to enter the CONNECTED state, the UE receives an RRC Release like message that triggers the UE to transition to a power saving state (e.g. INACTIVE, IDLE, IDLE with stored context, IDLE without stored context, etc.). The UE stores an idle / inactive measurement configuration(s) (e.g. for early measurement reporting) that may be contained in the RRC Release like message, and starts a timer (e.g., timer T331) with a received value (e.g., received in the RRC Release like message).

[0071] In some embodiments, the idle / inactive measurement configuration(s) contains configurations indicating what measurements the UE is to perform in a power saving state (e.g. INACTIVE, IDLE, etc.) such as a list of frequencies. For example, the idle / inactive measurement configuration(s) may contain a list of carrier frequency locations where Synchronization Signal Blocks (SSBs) are being transmitted, possibly signaled as a list of Absolute Radio Frequency Channel Numbers (ARFCNs) and, for each of the frequencies, cell quality derivation parameters, a parameter for beam measurements, etc. In some embodiments, the idle / inactive measurement configuration(s) contains configurations indicating what to measure and how the measurements are performed or criteria to store them e.g. only store measurement above a certain threshold. Further, in some embodiments, the idle / inactive measurement configuration(s) contains a timer value e.g. measIdleInactiveDuration. A timer (e.g., timer T331) is started with the received value when the message (i.e., the RRC Release like message) containing the measurement configuration is received.

[0072] In some embodiments, the idle / inactive configuration may be carried in a field measIdleInactiveConfig of Information Element (IE) MeasIdleInactiveConfigDedicated. As shown in the example below, that may contain a list of configurations provided per frequency of the same RAT or different RATs, e.g., NR and LTE in the example below. That frequency may be an SSB frequency, indicated by the ARFCN (i.e. a frequency information) indicating in which frequency the UE shall search for the SSBs and search for cells to measure.

[0073] A UE variable to store the configuration may be defined e.g. VarMeasIdleInactiveConfig so that in the specifications a stored configuration may be used by another procedure. Upon reception of the configuration when the UE is CONNECTED this variable may be cleared i.e. it should be empty without any configuration stored. This UE variable could be defined as follows: - VarMeasIdleInactiveConfigThe UE variable VarMeasIdleInactiveConfig includes the configuration of the measurements to be performed by the UE while in RRC_IDLE or RRC_INACTIVE for NR and / or E-UTRA inter-frequency measurements. The UE performs logging of these measurements only while in RRC_IDLE or RRC_INACTIVE.

[0074] Note that, in some embodiments, part of the measurement configuration may be absent in the RRC Release like message. In that case, the UE may acquire the measurement configuration from a system information block associated to the cell the UE is being suspended to INACTIVE or released to IDLE.1.2 Step 1002: Performing Idle / Inactive Measurements

[0075] The UE performs measurements according to the received measurement configuration(s) upon entering the power saving state (e.g. INACTIVE or IDLE) while the timer (e.g. T331) (or its equivalent) is running. When the timer T331 expires, the UE stops performing the measurements. In some embodiments, the timer T331 (or equivalent) is stopped while the UE is in RRC_IDLE or RRC_INACTIVE if the UE selects / re-selects a cell that does not belong to a validity area configured in the measurement configuration, if such a concept is also defined in NR. A possible example of implementations is described below. 1.3 Step 1004: Performing a 2-step Resume / Release while Performing the Idle / Inactive Measurements, wherein the UE handles the Idle / Inactive measurement configuration(s) when performing the 2-step resume / release, in accordance with any one of a number of solutions described herein

[0076] While the timer (e.g., T331) controlling measurements in the power saving state (e.g. INACTIVE, IDLE, etc.) is running, the UE tries to resume an RRC connection (e.g., by transmitting an RRC Resume Request like message). In response, the UE receives an RRC Release like message (e.g., RRCRelease) or an RRC Resume like message (e.g., RRCResume). Below, a number of different solutions are provided including scenarios when the UE receives an RRC Release like message and when the UE receives an RRC Resume like message. In all of these scenarios, the UE performs one or more actions to handle the Idle / Inactive measurement configuration(s) for the power saving state (e.g. for early measurement reporting) and measurements associated to the configuration(s).1.3.1 First Solution: Release measurement configuration and measurement results when receiving RRC Release message

[0077] In the first solution, while the timer (e.g., T331) controlling measurements in the power saving state (e.g. INACTIVE, IDLE, etc.) is running, the UE tries to resume an RRC connection (e.g., by transmitting an RRC Resume Request like message). In response, the UE receives an RRC Release like message (e.g., RRCRelease). Upon receiving the RRC Release like message while the timer is running, the UE stops the timer (e.g. T331) and performs a set of cleaning actions such as, e.g., clearing (i.e., releasing) the measurement configuration(s) and measurement results. In some embodiments, this may be modeled by clearing UE variables storing the measurement configuration and the measurement results. In that case, UE variables are defined in case these configurations need to be used in another procedure e.g. when the UE performs cell reselection and needs to re-acquire the configuration from system information.

[0078] In some embodiments, if the RRC Release like message contains a new Idle / Inactive measurement configuration, the UE stores the new measurement configuration (e.g. in a UE variable for measurement configuration that has been cleared), starts the timer T331 (or equivalent) with the value provided in the new measurement configuration, and starts performing measurements in power saving mode according to the new measurement configuration while the timer is running.

[0079] In some embodiments, in terms of signaling, that may be implemented in the specifications by defining in the RRC Release like message that the measurement configuration is OPTIONAL with Need Code R i.e. upon absence the configuration is released.

[0080] An alternative implementation of this could be to use the need code Need S, i.e. to specify the UE behavior if the field is absent:

[0081] The UE behavior when receiving the RRCRelease message could be implemented in 3GPP TS 38.331 as e.g.:

[0082] Below, an illustration is provided of what may be reported in the idle / inactive early measurement report e.g. multiplexed with or within a Resume Request, multiplexed or within an RRC Resume Complete or within a UE Information Response e.g. in 3GPP TS 38.331:

[0083] The definition of the timer T331 can be described in 3GPP TS 38.331 as e.g.:

[0084] In one variant of the UE behavior, the UE only clears the measurements if a new configuration for new measurements is received; otherwise, the UE may still keep them stored. Notice that the UE also stops the timer when UE enters CONNECTED, but then the UE does not delete the measurements that are going to be reported.

[0085] In one variant, when the timer T331 (or equivalent) expires, the UE releases the VarMeasIdleInactiveConfig that contains the measurement configuration i.e. the variable becomes empty and UE has no configuration. Note that "releasing" the variable is also known as "clearing" or "removing" the variable. In the variant above, when the timer T331 (or equivalent) expires the UE also releases the measurements stored (i.e. it may release / remove / clear the VarMeasInactiveIdleReport, where measurements are stored). Again, note that "releasing" the measurements is also known as "clearing" or "removing" the measurements.

[0086] In another variant, when the timer T331 (or equivalent) expires, the UE does not release / remove / clear the stored measurements. Hence, even if the UE is no longer performing measurements when it resumes or setups a connection, the UE may still report the measurements.

[0087] Advantages of the first solution: Compared to existing solution, this solution is consistent and simple. It allows the possibility to receive an RRC Release in response to an RRC Resume, stop the measurements configured by the last serving node (e.g. where the UE was suspended or released) and remove the stored measurements. But, it also allows the network to configure the UE again with new measurement configuration for similar purpose. Another potential advantage of this solution is that the UE and network would not necessarily have to store the idle / inactive measurement configuration in the UE Inactive AS context.1.3.2 Second Solution: Keep idle / inactive measurement configurations when receiving RRC Release message unless receiving new configuration

[0088] In the second solution, while the timer (e.g., T331) controlling measurements in the power saving state (e.g. INACTIVE, IDLE, etc.) is running, the UE tries to resume an RRC connection (e.g., by transmitting an RRC Resume Request like message). In response, the UE receives an RRC Release like message (e.g., RRCRelease). In the second solution, the RRC Release like message is received while the timer is running and does not contain a measurement configuration for measurements in IDLE / INACTIVE e.g. for early measurement reporting. Upon receiving the RRC Release like message that does not contain a measurement configuration for measurements in Idle / Inactive while the timer is running, the UE does not stop the timer (e.g. T331) and does not perform a set of cleaning actions (e.g., does not clearing (i.e., releasing) the measurement configuration(s) and measurement results or in other words does not clear the UE (containing the measurement configuration and measurement results)). Hence, the absence of the measurement configuration (e.g., the absence of the measurement configuration field (e.g. measIdleInactiveConfig-r16)) in the RRC Release like message indicates that the UE is to continue performing measurements that have been previously configured. That case may be interesting in case the UE tried to resume and was released or suspended by the network, possibly without using context fetching (e.g. in an RNA update without context fetching where the last serving node suspends / Releases the UE).

[0089] Otherwise, if the UE receives an RRC release like message (in response to an RRC Resume like message) while timer T331 (or equivalent) is running and the message contains a measurement configuration_for measurements in IDLE / INACTIVE e.g. for early measurement reporting, the UE stops the timer (e.g. T331) and performs a set of cleaning actions (i.e. clears the UE variables containing the measurement configuration and measurement results).

[0090] In some embodiments, the measIdleInactiveConfig-r16 may be optional and have a need code N, i.e., no action is performed upon absence (and UE continues doing what it has been configured previously). In that case, the presence leads to a one-time action which is the clearing of the stored configurations, and storage of the new configuration in the UE variable.

[0091] In some embodiments, the presence of the measIdleInactiveConfig-r16 (or equivalent field with the measurement configuration) indicates that the UE first stops the timer T331, perform the clean-up actions, store the new configuration(s), and starts the measurement procedures according to it. One example implementation in 3GPP TS 38.331 is shown below.

[0092] In the variant above, when the timer T331 (or equivalent) expires, the UE releases the VarMeasIdleInactiveConfig that contains the measurement configuration i.e. the variable becomes empty and UE has no configuration. In the variant above, when the timer T331 (or equivalent) expires the UE also releases / clears / removes the measurements stored (i.e. it may release / remove / clear the VarMeasInactiveIdleReport, where measurements are stored).

[0093] In another variant, when the timer T331 (or equivalent) expires the UE does not release / remove / clear the measurements stored. Hence, even if the UE is not performing measurements any more when it resumes or setups a connection it may still report the measurements.

[0094] In another variant, instead of stopping the timer T331 (or equivalent) to then start again with the new value received in the RRC Release like message, the time is restarted with the new value. In this case, the procedure om 3GPP TS 38.331 could be updated to e.g.:

[0095] Advantages of the second solution: Compared to the first solution, this solution allows the network to let the UE continue to do what it has been configured by the source node when it was suspended last time (e.g. from CONNECTED) and possibly not bother to change that configuration (e.g. add or remove measurement configurations). At the same time, if network wants to, it still allows in the RRC Release to provide a new configuration. And, upon that case, UE deletes whatever it has stored and replaces with new configurations and starts new measurements in power saving state.1.3.3 Third Solution: Keep and update idle / inactive measurement configurations when receiving RRC Release message

[0096] In the third solution, while the timer (e.g., T331) controlling measurements in the power saving state (e.g. INACTIVE, IDLE, etc.) is running, the UE tries to resume an RRC connection (e.g., by transmitting an RRC Resume Request like message). In response, the UE receives an RRC Release like message (e.g., RRCRelease). In the third solution, the RRC Release like message is received while the timer is running and does not contain a measurement configuration for measurements in IDLE / INACTIVE e.g. for early measurement reporting. Upon receiving the RRC Release like message that does not contain a measurement configuration for measurements in Idle / Inactive while the timer is running, the UE does not stop the timer (e.g. T331) and does not perform a set of cleaning actions (e.g., does not clear (i.e., release) the measurement configuration(s) and measurement results or in other words does not clear the UE variables containing the measurement configuration and measurement results). Hence, the absence of the measurement configuration (e.g., the absence of the measurement configuration field (e.g. measIdleInactiveConfig-r16)) in the RRC Release like message indicates that the UE is to continue performing measurements that have been previously configured. That case may be applied in case the UE tried to resume and was released / suspended by the network, possibly without using context fetching (e.g. in an RNA update without context fetching where the last serving node suspends / Releases the UE).

[0097] However, differently from the second solution, else if the UE receives an RRC release like message in response to an RRC Resume like message while timer T331 (or equivalent) is running and the message contains a measurement configuration for measurements in IDLE / INACTIVE e.g. for early measurement reporting, the UE may perform at least one of the following actions: The UE adds a new entry in its stored measurement configuration i.e. the UE adds a new carrier frequency to its list of stored measurement configurations. ∘ In one variant, upon addition, the UE re-starts the timer T331 (or equivalent) with a stored value in the UE variable containing the configuration. ∘ In one variant, upon addition, the UE does not re-start the timer T331 (or equivalent). The UE modifies a stored configuration in its stored measurement configuration i.e. the UE changes any field defined per carrier frequency in its list of stored measurement configurations. ∘ In one variant, upon modification, the UE re-starts the timer T331 (or equivalent) with a stored value in the UE variable containing the configuration. ∘ In one variant, upon modification, the UE does not re-start the timer T331 (or equivalent). The UE removes an existing entry in its list of stored measurement configurations and stops performing measurement according to the removed configuration.

[0098] In some embodiments, the third solution relies on a structure based on AddMod and Remove lists for the measurement configurations. In order to add or remove items from the configurations, the top level field needs to be Need M, i.e. maintain if not included. An example of the RRC Release message is shown below:

[0099] To capture the UE behavior, the procedures in TS 38.331 can be updated to e.g.:

[0100] Advantages of the third solution: Compared to previous solutions, this solution allows the network substantial flexibility to add, remove, or modify measurement configurations without necessarily discontinuing measurements at the UE.1.3.4 Fourth Solution: Keep measurement configurations if receiving RRC Release with suspend config, otherwise release the measurement configurations

[0101] In the fourth solution, while the timer (e.g., T331) controlling measurements in the power saving state (e.g. INACTIVE, IDLE, etc.) is running, the UE tries to resume an RRC connection (e.g., by transmitting an RRC Resume Request like message). In response, the UE receives an RRC Release like message (e.g., RRCRelease). In the fourth solution, the RRC Release like message contains a suspendConfig (i.e., an indication that the UE remains in INACTIVE state). Upon receiving the RRC Release like message that contains a suspendConfig (i.e., an indication that the UE remains in INACTIVE state) while the timer is running, the UE operates in accordance with any one of the first, second, or third solutions. Else, if the RRC Release like message does not contain a suspendConfig, which is an indication that the UE is to transition to IDLE state, the UE stops the timer T331 and performs the set of clean up actions such as deleting the measurements, deleting the configurations, and clearing the UE variables.

[0102] For the different solutions for the handling of idle / inactive measurement configuration described above (perhaps with the exception of the first solution), the target network node where the UE tries to resume could know the existing inactive / idle configuration the UE has stored before making a decision to either add, remove, or delete a measurement configuration and / or making a decision to stop or continue measurements. At the UE, one solution is to store the inactive / idle measurement configuration in the UE Inactive AS Context. At the network side, the inactive / idle measurement configuration is also stored (e.g., the in UE Inactive AS Context) at the node suspending the UE. Upon transmission of an RRC Resume Request like message, since the UE may possibly receive an RRC Release message containing an indication on how the UE is to handle the idle / inactive measurement configuration, the UE restores the UE Inactive AS context including the inactive / idle measurement configuration so that it could be replaced, removed, added, etc. This may be implemented in 3GPP 38.331 as follows:

[0103] Advantages of the fourth solution: Compared to previous solutions, the UE only bothers about the handling of the idle / inactive measurement configuration when it transitions to inactive, and not idle.1.3.5 Fifth Solution: Keep idle / inactive measurement configurations when entering RRC_ CONNECTED when performing idle / inactive measurements

[0104] In the fifth solution, while the timer (e.g., T331) controlling measurements in the power saving state (e.g. INACTIVE, IDLE, etc.) is running, the UE tries to resume an RRC connection (e.g., by transmitting an RRC Resume Request like message). In response, the UE receives an RRC Resume like message (e.g., RRCResume) and enters the CONNECTED state. Upon receiving the RRC Resume like message while the timer is running, the UE stops the timer T331 (or equivalent), thereby stopping performing the measurements, and stores the measurement configuration(s) for the power saving state (e.g. for early measurement reporting).

[0105] In some embodiments, the inactive / idle measurement configuration(s) may be stored in a UE variable.

[0106] In some embodiments, when the UE in CONNECTED receives an RRC Release message, the UE restores the idle / inactive measurement configuration. If the RRC Release message does not contain an idle / inactive measurement configuration, the UE resumes the restored configuration; otherwise, if the RRC Release message contains an idle / inactive measurement configuration, delta signaling applies. This could be useful in case the UE triggers a NAS signaling procedure in INACTIVE state e.g. a Tracking Area Update that requires the UE to enter CONNECTED for a short time. Then, with this solution, network would not need to re-configure the idle / inactive measurements.

[0107] Advantages of the fifth solution: Compared to the conventional solution, whenever a UE is configured to perform idle mode measurements in a power saving mode (INACTIVE, IDLE, etc.), the UE would store these configurations, allowing the network to release the UE back to a power saving mode without a need to signal the idle mode measurement configurations.2 Network Methods

[0108] Embodiments of a method performed by (i.e., executed by) a source network node are also disclosed herein. In general, the method performed by a source network node comprises, as illustrated in Figure 11: Step 1100: The source network node provides, to a UE in CONNECTED state, an RRC Release like message (e.g., an RRCRelease) (with a suspend configuration indicating that the UE is to transition to INACTIVE state or without a suspend configuration indicating that the UE shall transition to IDLE), where the RRC Release like message contains a measurement configuration for idle / inactive measurements e.g. for early measurement reporting. Note that, in an alternative embodiment, the UE could also get the measurement configuration(s) for idle / inactive measurements while the UE is in Idle / Inactive state in the 2-step resume / release procedure described herein - i.e., the UE enters RRC INACTIVE without configurations, the UE attempts to resume by transmitting RRCResumeRequest, and the network responds with RRCRelease including measurement configurations. In that case, the UE never entered connected mode. Step 1102: The source network node stores the idle / inactive measurement configuration of the UE in the UE Inactive AS Context; Step 1104: The source network node receives a request from a target network node to retrieve the UE Inactive AS Context. Step 1106: The source network node retrieves the UE Inactive AS context of the UE and (e.g., if the UE is verified) provides the context to the target node.

[0109] Embodiments of a method performed by (i.e., executed by) a target network node are also disclosed herein. In general, the method performed by a target network node comprises, as illustrated in Figure 12: Step 1200: The target network node receives a Resume Request message from an inactive UE. Step 1202: The target network node retrieves the UE Inactive AS Context from a source network node or, identifying that the context is stored in the target node. In the illustrated embodiment, the target network node sends a request to the source network node for the UE Inactive AS context (step 1202A) and, in response, receives the UE Inactive AS context from the source network node (step 1202B). Step 1204: The target network node determines whether an idle / inactive measurement configuration of the UE is present in the UE Inactive AS context. Step 1206: If an idle / inactive measurement configuration of the UE is present in the UE Inactive AS context, the target network node determines whether the Inactive / Idle measurement configuration of the UE should be added, modified or released (e.g., according to any of the solutions described above for handling the measurement configurations) in an RRC Release message to the UE. Step 1208: If so, the target network node sends the appropriate RRC Release message to the UE. 3 Additional Aspects

[0110] Figure 13 is a schematic block diagram of a radio access node 1300 according to some embodiments of the present disclosure. The radio access node 1300 may be, for example, a base station 902 or 906. As illustrated, the radio access node 1300 includes a control system 1302 that includes one or more processors 1304 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 1306, and a network interface 1308. The one or more processors 1304 are also referred to herein as processing circuitry. In addition, the radio access node 1300 includes one or more radio units 1310 that each includes one or more transmitters 1312 and one or more receivers 1314 coupled to one or more antennas 1316. The radio units 1310 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 1310 is external to the control system 1302 and connected to the control system 1302 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 1310 and potentially the antenna(s) 1316 are integrated together with the control system 1302. The one or more processors 1304 operate to provide one or more functions of a radio access node 1300 (e.g., one or more functions of a network node described herein, e.g., as illustrated in Figures 10 through 12) as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1306 and executed by the one or more processors 1304.

[0111] Figure 14 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node 1300 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures.

[0112] As used herein, a "virtualized" radio access node is an implementation of the radio access node 1300 in which at least a portion of the functionality of the radio access node 1300 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the radio access node 1300 includes the control system 1302 that includes the one or more processors 1304 (e.g., CPUs, ASICs, FPGAs, and / or the like), the memory 1306, and the network interface 1308 and the one or more radio units 1310 that each includes the one or more transmitters 1312 and the one or more receivers 1314 coupled to the one or more antennas 1316, as described above. The control system 1302 is connected to the radio unit(s) 1310 via, for example, an optical cable or the like. The control system 1302 is connected to one or more processing nodes 1400 coupled to or included as part of a network(s) 1402 via the network interface 1308. Each processing node 1400 includes one or more processors 1404 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1406, and a network interface 1408.

[0113] In this example, functions 1410 of the radio access node 1300 described herein (e.g., one or more functions of a network node described herein, e.g., as illustrated in Figures 10 through 12) are implemented at the one or more processing nodes 1400 or distributed across the control system 1302 and the one or more processing nodes 1400 in any desired manner. In some particular embodiments, some or all of the functions 1410 of the radio access node 1300 described herein (e.g., one or more functions of a network node described herein, e.g., as illustrated in Figures 10 through 12) are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1400. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 1400 and the control system 1302 is used in order to carry out at least some of the desired functions 1410. Notably, in some embodiments, the control system 1302 may not be included, in which case the radio unit(s) 1310 communicate directly with the processing node(s) 1400 via an appropriate network interface(s).

[0114] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of radio access node 1300 (e.g., one or more functions of a network node described herein, e.g., as illustrated in Figures 10 through 12) or a node (e.g., a processing node 1400) implementing one or more of the functions 1410 of the radio access node 1300 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0115] Figure 15 is a schematic block diagram of the radio access node 1300 according to some other embodiments of the present disclosure. The radio access node 1300 includes one or more modules 1500, each of which is implemented in software. The module(s) 1500 provide the functionality of the radio access node 1300 described herein (e.g., one or more functions of a network node described herein, e.g., as illustrated in Figures 10 through 12). This discussion is equally applicable to the processing node 1400 of Figure 14 where the modules 1500 may be implemented at one of the processing nodes 1400 or distributed across multiple processing nodes 1400 and / or distributed across the processing node(s) 1400 and the control system 1302.

[0116] Figure 16 is a schematic block diagram of a UE 1600 according to some embodiments of the present disclosure. As illustrated, the UE 1600 includes one or more processors 1602 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1604, and one or more transceivers 1606 each including one or more transmitters 1608 and one or more receivers 1610 coupled to one or more antennas 1612. The transceiver(s) 1606 includes radio-front end circuitry connected to the antenna(s) 1612 that is configured to condition signals communicated between the antenna(s) 1612 and the processor(s) 1602, as will be appreciated by on of ordinary skill in the art. The processors 1602 are also referred to herein as processing circuitry. The transceivers 1606 are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE 1600 described above (e.g., one or more functions of a UE described herein, e.g., as illustrated in Figures 10 through 12) may be fully or partially implemented in software that is, e.g., stored in the memory 1604 and executed by the processor(s) 1602. Note that the UE 1600 may include additional components not illustrated in Figure 16 such as, e.g., one or more user interface components (e.g., an input / output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and / or the like and / or any other components for allowing input of information into the UE 1600 and / or allowing output of information from the UE 1600), a power supply (e.g., a battery and associated power circuitry), etc.

[0117] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the UE 1600 according to any of the embodiments described herein (e.g., one or more functions of a UE described herein, e.g., as illustrated in Figures 10 through 12) is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0118] Figure 17 is a schematic block diagram of the UE 1600 according to some other embodiments of the present disclosure. The UE 1600 includes one or more modules 1700, each of which is implemented in software. The module(s) 1700 provide the functionality of the UE 1600 described herein (e.g., one or more functions of a UE described herein, e.g., as illustrated in Figures 10 through 12).

[0119] With reference to Figure 18, in accordance with an embodiment, a communication system includes a telecommunication network 1800, such as a 3GPP-type cellular network, which comprises an access network 1802, such as a RAN, and a core network 1804. The access network 1802 comprises a plurality of base stations 1806A, 1806B, 1806C, such as NBs, eNBs, gNBs, or other types of wireless Access Points (APs), each defining a corresponding coverage area 1808A, 1808B, 1808C. Each base station 1806A, 1806B, 1806C is connectable to the core network 1804 over a wired or wireless connection 1810. A first UE 1812 located in coverage area 1808C is configured to wirelessly connect to, or be paged by, the corresponding base station 1806C. A second UE 1814 in coverage area 1808A is wirelessly connectable to the corresponding base station 1806A. While a plurality of UEs 1812, 1814 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 1806.

[0120] The telecommunication network 1800 is itself connected to a host computer 1816, which may be embodied in the hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as processing resources in a server farm. The host computer 1816 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections 1818 and 1820 between the telecommunication network 1800 and the host computer 1816 may extend directly from the core network 1804 to the host computer 1816 or may go via an optional intermediate network 1822. The intermediate network 1822 may be one of, or a combination of more than one of, a public, private, or hosted network; the intermediate network 1822, if any, may be a backbone network or the Internet; in particular, the intermediate network 1822 may comprise two or more sub-networks (not shown).

[0121] The communication system of Figure 18 as a whole enables connectivity between the connected UEs 1812, 1814 and the host computer 1816. The connectivity may be described as an Over-the-Top (OTT) connection 1824. The host computer 1816 and the connected UEs 1812, 1814 are configured to communicate data and / or signaling via the OTT connection 1824, using the access network 1802, the core network 1804, any intermediate network 1822, and possible further infrastructure (not shown) as intermediaries. The OTT connection 1824 may be transparent in the sense that the participating communication devices through which the OTT connection 1824 passes are unaware of routing of uplink and downlink communications. For example, the base station 1806 may not or need not be informed about the past routing of an incoming downlink communication with data originating from the host computer 1816 to be forwarded (e.g., handed over) to a connected UE 1812. Similarly, the base station 1806 need not be aware of the future routing of an outgoing uplink communication originating from the UE 1812 towards the host computer 1816.

[0122] Example implementations, in accordance with an embodiment, of the UE, base station, and host computer discussed in the preceding paragraphs will now be described with reference to Figure 19. In a communication system 1900, a host computer 1902 comprises hardware 1904 including a communication interface 1906 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 1900. The host computer 1902 further comprises processing circuitry 1908, which may have storage and / or processing capabilities. In particular, the processing circuitry 1908 may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The host computer 1902 further comprises software 1910, which is stored in or accessible by the host computer 1902 and executable by the processing circuitry 1908. The software 1910 includes a host application 1912. The host application 1912 may be operable to provide a service to a remote user, such as a UE 1914 connecting via an OTT connection 1916 terminating at the UE 1914 and the host computer 1902. In providing the service to the remote user, the host application 1912 may provide user data which is transmitted using the OTT connection 1916.

[0123] The communication system 1900 further includes a base station 1918 provided in a telecommunication system and comprising hardware 1920 enabling it to communicate with the host computer 1902 and with the UE 1914. The hardware 1920 may include a communication interface 1922 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 1900, as well as a radio interface 1924 for setting up and maintaining at least a wireless connection 1926 with the UE 1914 located in a coverage area (not shown in Figure 19) served by the base station 1918. The communication interface 1922 may be configured to facilitate a connection 1928 to the host computer 1902. The connection 1928 may be direct or it may pass through a core network (not shown in Figure 19) of the telecommunication system and / or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 1920 of the base station 1918 further includes processing circuitry 1930, which may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The base station 1918 further has software 1932 stored internally or accessible via an external connection.

[0124] The communication system 1900 further includes the UE 1914 already referred to. The UE's 1914 hardware 1934 may include a radio interface 1936 configured to set up and maintain a wireless connection 1926 with a base station serving a coverage area in which the UE 1914 is currently located. The hardware 1934 of the UE 1914 further includes processing circuitry 1938, which may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The UE 1914 further comprises software 1940, which is stored in or accessible by the UE 1914 and executable by the processing circuitry 1938. The software 1940 includes a client application 1942. The client application 1942 may be operable to provide a service to a human or non-human user via the UE 1914, with the support of the host computer 1902. In the host computer 1902, the executing host application 1912 may communicate with the executing client application 1942 via the OTT connection 1916 terminating at the UE 1914 and the host computer 1902. In providing the service to the user, the client application 1942 may receive request data from the host application 1912 and provide user data in response to the request data. The OTT connection 1916 may transfer both the request data and the user data. The client application 1942 may interact with the user to generate the user data that it provides.

[0125] It is noted that the host computer 1902, the base station 1918, and the UE 1914 illustrated in Figure 19 may be similar or identical to the host computer 1816, one of the base stations 1806A, 1806B, 1806C, and one of the UEs 1812, 1814 of Figure 18, respectively. This is to say, the inner workings of these entities may be as shown in Figure 19 and independently, the surrounding network topology may be that of Figure 18.

[0126] In Figure 19, the OTT connection 1916 has been drawn abstractly to illustrate the communication between the host computer 1902 and the UE 1914 via the base station 1918 without explicit reference to any intermediary devices and the precise routing of messages via these devices. The network infrastructure may determine the routing, which may be configured to hide from the UE 1914 or from the service provider operating the host computer 1902, or both. While the OTT connection 1916 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

[0127] The wireless connection 1926 between the UE 1914 and the base station 1918 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 1914 using the OTT connection 1916, in which the wireless connection 1926 forms the last segment.

[0128] A measurement procedure may be provided for the purpose of monitoring data rate, latency, and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1916 between the host computer 1902 and the UE 1914, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection 1916 may be implemented in the software 1910 and the hardware 1904 of the host computer 1902 or in the software 1940 and the hardware 1934 of the UE 1914, or both. In some embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 1916 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which the software 1910, 1940 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1916 may include message format, retransmission settings, preferred routing, etc.; the reconfiguring need not affect the base station 1918, and it may be unknown or imperceptible to the base station 1918. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer 1902's measurements of throughput, propagation times, latency, and the like. The measurements may be implemented in that the software 1910 and 1940 causes messages to be transmitted, in particular empty or 'dummy' messages, using the OTT connection 1916 while it monitors propagation times, errors, etc.

[0129] Figure 20 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 18 and 19. For simplicity of the present disclosure, only drawing references to Figure 20 will be included in this section. In step 2000, the host computer provides user data. In sub-step 2002 (which may be optional) of step 2000, the host computer provides the user data by executing a host application. In step 2004, the host computer initiates a transmission carrying the user data to the UE. In step 2006 (which may be optional), the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 2008 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0130] Figure 21 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 18 and 19. For simplicity of the present disclosure, only drawing references to Figure 21 will be included in this section. In step 2100 of the method, the host computer provides user data. In an optional sub-step (not shown) the host computer provides the user data by executing a host application. In step 2102, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In step 2104 (which may be optional), the UE receives the user data carried in the transmission.

[0131] Figure 22 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 18 and 19. For simplicity of the present disclosure, only drawing references to Figure 22 will be included in this section. In step 2200 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 2202, the UE provides user data. In sub-step 2204 (which may be optional) of step 2200, the UE provides the user data by executing a client application. In sub-step 2206 (which may be optional) of step 2202, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in sub-step 2208 (which may be optional), transmission of the user data to the host computer. In step 2210 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

[0132] Figure 23 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 18 and 19. For simplicity of the present disclosure, only drawing references to Figure 23 will be included in this section. In step 2300 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step 2302 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 2304 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0133] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0134] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0135] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s). • 3GPPThird Generation Partnership Project• 5GFifth Generation• 5GCFifth Generation Core• 5GSFifth Generation System• 5G-S-TMSI5G System Architecture Evolution Temporary Mobile Subscriber Identity• APAccess Point• ARFCNAbsolute Radio Frequency Channel Number• ASAccess Stratum• ASICApplication Specific Integrated Circuit• CACarrier Aggregation• CEControl Element• CNCore Network• CPUCentral Processing Unit• DCDual Connectivity• DRXDiscontinuous Reception• DSPDigital Signal Processor• eLTEEnhanced Long Term Evolution• eNBEnhanced or Evolved Node B• EN-DCEvolved Universal Terrestrial Radio Access Network New Radio Dual Connectivity• EPCEvolved Packet Core• E-UTRAEvolved Universal Terrestrial Radio Access• E-UTRANEvolved Universal Terrestrial Radio Access Network• FPGAField Programmable Gate Array• gNBNew Radio Base Station• IDIdentity• IEInformation Element• I-RNTIInactive Radio Network Temporary Identifier• LTELong Term Evolution• MACMedium Access Control• MCGMaster Cell Group• MeNBMaster Enhanced or Evolved Node B• MMEMobility Management Entity• MR-DCMulti-Radio Dual Connectivity• msMillisecond• MTCMachine Type Communication• NASNon-Access Stratum• NENew Radio Evolved Universal Terrestrial Radio Access• NGEN-DCNext Generation Dual Connectivity• NG-RANNext Generation Radio Access Network• NRNew Radio• OTTOver-the-Top• PCellPrimary Cell• PCIPhysical Cell Identity• P-GWPacket Data Network Gateway• PSCellPrimary Secondary Cell• RAMRandom Access Memory• RANRadio Access Network• RATRadio Access Technology• RNARadio Network Subsystem Application Part User Adaptation• RNSAPRadio Network Subsystem Application Part• ROMRead Only Memory• RRCRadio Resource Control• RRHRemote Radio Head• RRMRadio Resource Management• RSRPReference Signal Received Power• RSRQReference Signal Received Quality• SAStand-Alone• SCEFService Capability Exposure Function• SCellSecondary Cell• SCGSecondary Cell Group• SIBSystem Information Block• SpCellSpecial Cell• SSBSynchronization Signal Block• TSTechnical Specification• UEUser Equipment• WIDWork Item Description

Claims

1. A method performed by a wireless device, the method comprising: receiving (1000) at least one measurement configuration for a power saving state; performing (1002) measurements in the power saving state in accordance with the at least one measurement configuration; while performing (1002) the measurements in the power saving state: sending (1004A), to a network node, an RRC Resume Request like message; receiving (1004, 1004B), an RRC Release like message from the network node; and determining whether the RRC Release like message contains a measurement configuration for measurements in a power saving state, and; characterised in that • upon determining that the RRC Release like message does not contain a measurement configuration for measurements in a power saving state: ∘ keeping the at least one measurement configuration and the measurements performed in accordance with the at least one measurement configuration; and ∘ continuing to perform measurements in accordance with the at least one measurement configuration; • upon determining that the RRC Release like message does contain a measurement configuration for measurements in a power saving state: ∘ stop performing measurements in the power saving state in accordance with the at least one measurement configuration; and ∘ performing a set of actions with respect to the at least one measurement configuration, the measurements, or both the at least one measurement configuration and the measurements..

2. The method of claim 1 wherein the message received from the network node is a message that may or may not include a measurement configuration for measurements in the power saving state.

3. The method of claim 1 wherein the message received from the network node is a message that indicates to the wireless device that the wireless device is to remain in the power saving state or transition to another power saving state.

4. The method of claim 1 wherein the message received from the network node is an RRC Release like message.

5. The method of claim 1 wherein the RRC Release like message is an RRCRelease message or an RRCConnectionRelease message.

6. The method of any of claims 1 to 5 wherein the RRC Resume Request like message is an RRCResumeRequest or RRCResumeRequest1 or RRCConnectionResumeRequest, and the RRC Release like message is an RRCRelease message or an RRCConnectionRelease message.

7. The method of any of claim 1 to 6 wherein the RRC Release like message does contain a measurement configuration for measurements in a power saving state, and performing (1004, 1004C) the one or more actions to handle the at least one measurement configuration, the measurements, or both the measurement configuration and the measurements comprises at least one of the following actions: adding a new entry in the at least one measurement configuration based on the measurement configuration contained in the RRC Release like message; modifying the at least one measurement configuration based on the measurement configuration contained in the RRC Release like message; and removing an existing entry in the at least one measurement configuration based on the measurement configuration contained in the RRC Release like message.

8. The method of any of claims 1 to 6 further comprising determining whether the RRC Release like message contains a measurement configuration for measurements in a power saving state, and performing (1004, 1004C) the one or more actions to handle the at least one measurement configuration, the measurements, or both the measurement configuration and the measurements comprises: • upon determining that the RRC Release like message does not contain a measurement configuration for measurements in a power saving state: ∘ keeping the at least one measurement configuration and the measurements performed in accordance with the at least one measurement configuration; and ∘ continuing to perform measurements in accordance with the at least one measurement configuration; and • upon determining that the RRC Release like message does contain a measurement configuration for measurements in a power saving state, at least one of the following: ∘ adding a new entry in the at least one measurement configuration based on the measurement configuration contained in the RRC Release like message; ∘ modifying the at least one measurement configuration based on the measurement configuration contained in the RRC Release like message; and ∘ removing an existing entry in the at least one measurement configuration based on the measurement configuration contained in the RRC Release like message.

9. A wireless device (912; 1600) for a cellular communications system (900), the wireless device (912; 1600) adapted to: receive (1000) at least one measurement configuration for a power saving state; perform (1002) measurements in the power saving state in accordance with the at least one measurement configuration; while performing (1002) the measurements in the power saving state: send (1004A), to a network node, an RRC Resume Request like message; receiving (1004, 1004B), an RRC Release like message from the network node; and determine whether the RRC Release like message contains a measurement configuration for measurements in a power saving state, and; characterised in that • upon determining that the RRC Release like message does not contain a measurement configuration for measurements in a power saving state: ∘ keep the at least one measurement configuration and the measurements performed in accordance with the at least one measurement configuration; and ∘ continue to perform measurements in accordance with the at least one measurement configuration; • upon determining that the RRC Release like message does contain a measurement configuration for measurements in a power saving state: ∘ stop perform measurements in the power saving state in accordance with the at least one measurement configuration; and perform a set of actions with respect to the at least one measurement configuration, the measurements, or both the at least one measurement configuration and the measurements.

10. The wireless device (912; 1600) of claim 9 wherein the wireless device (912; 1600) is further adapted to perform the method of any one of claims 2 to 8.