Low power wake-up receiver operation

Abstract

According to some embodiments, a method performed by a wireless device for performing wakeup signal (WUS) monitoring. The wireless device is capable of operating in a plurality of sleep modes. The method includes: operating according to a first sleep mode of a plurality of sleep modes; determining to switch from the first sleep mode to a second sleep mode of the plurality of sleep modes; and operating according to the second sleep mode.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to wireless communications, and more particularly, to low power wake-up receiver operation. Background Art

[0002] Generally, unless clearly given and / or different meanings are suggested from the context, all terms used in this article will be interpreted according to their ordinary meaning in the relevant technical field. Unless otherwise clearly stated, all references to "one / an / element, equipment, component, device, step, etc." should be openly interpreted as referring to at least one instance in an element, equipment, component, device, step, etc. Unless a step must be clearly described as being after or before another step and / or a step must be after or before another step implicitly, the steps of any method disclosed herein need not be performed in the exact order disclosed. Where appropriate, any feature of any embodiment disclosed herein may be applied to any other embodiment. Similarly, any advantage of any embodiment may be applicable to any other embodiment, and vice versa. By the description below, other purposes, features and advantages of the attached embodiments will be apparent.

[0003] Wireless devices in wireless communication networks can use wake-up signals to save power. A wake-up receiver (WUR), sometimes also referred to as a "wake-up radio," is a low-power receiver enabled in a user equipment (UE) that, upon detection of a wake-up signal (WUS), wakes up the primary (baseband / higher power) receiver to detect an incoming message, typically a page (e.g., a physical downlink control channel (PDCCH) in a paging occasion (PO) with a page message scheduled on the physical downlink shared channel (PDSCH)). The primary benefit of using WUR is reduced energy consumption and extended device battery life, or, for a fixed energy consumption, reduced downlink latency (shorter discontinuous reception (DRX) / duty cycle and more frequent checks for incoming transmissions).

[0004] Figure 1 The positions of the WUS and the paging occasions associated therewith are shown. The horizontal axis represents the time domain.

[0005] The 3rd Generation Partnership Project (3GPP) Release 15 specifies WUS for Narrowband Internet of Things (NB-IoT) and Long Term Evolution for Machines (LTE-M). The main motivation is the reduction of UE energy consumption, because with coverage enhancement, PDCCH can be repeated multiple times and WUS is relatively short, and thus UE needs less reception time. The logic is that the UE checks for WUS some time before its PO, and only if WUS is detected, the UE will continue to check PDCCH in PO, and if not detected (in most cases), the UE goes back to sleep to save energy. Due to coverage enhancement, the length of WUS can vary depending on the coverage of the UE, see Figure 2 .

[0006] Figure 2 The WUS of NB-IoT and LTE-M are shown. The horizontal axis represents the time domain.

[0007] WUS is based on the transmission of a short signal that indicates to the UE that it should continue decoding downlink control channels, such as the full NPDCCH for NB-IoT. If no such signal is present (discontinuous transmission (DTX), i.e., the UE detects no signal), the UE can return to sleep without decoding the downlink control channel. The decoding time of WUS is much shorter than that of the full NPDCCH because it only needs to contain 1 bit of information, while the NPDCCH can contain up to 35 bits of information. This in turn reduces UE power consumption and leads to longer UE battery life.

[0008] A WUS is sent only when there is paging for the UE. If there is no paging for the UE, no WUS is sent (i.e., DTX is implied), and the UE returns to deep sleep, e.g., when DTX is detected instead of a WUS. Figure 1 As shown, where white blocks indicate possible WUS and PO positions, and black blocks indicate actual WUS and PO positions.

[0009] The specifications for Rel-15WUS are distributed across multiple parts of the LTE 36 series standards, such as 36.211, 36.213, 36.304, and 36.331.

[0010] The UE reports its WUS capability to the network, as well as its WUS gap capability (see below). WUS information is also added to the paging message / request from the Mobility Management Entity (MME) to the eNB (see UE Radio Paging Capabilities). The eNB will use WUS to page the UE if and only if the following conditions are met: 1) WUS is enabled in the cell (i.e., WUS-Config is present in the System Information (SI)); and 2) the UE supports WUS according to the wakeUpSignal-r15 UE capabilities (see also the description of WUS gaps below).

[0011] Both LTE-M and NB-IoT introduce WUS, supporting both DRX and eDRX, with the former having a 1-to-1 mapping between WUS and PO, and the latter also supporting a possible configuration of 1 to N (multiple) PO. The eNB can configure one WUS gap for UEs using DRX and another WUS gap for UEs using eDRX [TS 36.331, gives an example for NB-IoT, LTE-M is similar]:

[0012] WUS-Config-NB Information Elements

[0013]

[0014]

[0015] For DRX and eDRX respectively, the UE capabilities may also indicate the minimum WUS gap required for the UE to be able to decode the PDCCH in the associated PO [TS 36.331]:

[0016] UE-RadioPagingInfo-NB information element

[0017]

[0018] The parameter wakeUpSignalMinGap-eDRX indicates the minimum gap supported by the UE between the WUS or group wake-up signal (GWUS) and the associated PO for eDRX in frequency division duplex (FDD), as specified in TS 36.304. The value ms40 corresponds to 40ms, the value ms240 corresponds to 240ms, and so on. If this field is included, the UE shall also indicate support for WUS or GWUS for paging in DRX.

[0019] At the end of Rel-15, longer WUS intervals of 1s or 2s were introduced to enable the use of WUR. That is, if WUR is used for WUS detection, it may take longer to start the primary baseband receiver. If supported by the cell, the eNB includes timeOffset-eDRX-Long in the WUS-Config in the SI (see above). In TS 36.304, the UE behavior for monitoring paging with WUS is specified, and Table 7.4-1 indicates which WUS time interval the UE (and eNB) should apply based on the reported UE capabilities. The relevant parts are reproduced below.

[0020] ********************************************************************

[0021] 7.4 Paging using wake-up signals

[0022] Paging using the wake-up signal is only used in the cell where the UE last entered RRC_IDLE and is triggered by:

[0023] - Receipt of RRC EarlyDataComplete; or

[0024] - Receipt of RRCConnectionRelease (excluding noLastCellUpdate); or

[0025] - Receipt of RRCConnectionRelease (including noLastCellUpdate) and the UE was using (G)WUS in this cell before this RRC connection attempt.

[0026] If the UE is in RRC_IDLE, the UE is not using GWUS according to clause 7.5, and the UE supports WUS and the WUS configuration is provided in the system information, the UE shall monitor WUS using the WUS parameters provided in the system information. When DRX is used and the UE detects WUS, the UE shall monitor subsequent POs. When extended DRX is used and the UE detects WUS, the UE shall monitor the subsequent numPOs POs, or until a paging message including the UE's NAS identity is received (whichever is earlier). If the UE does not detect a WUS, the UE does not need to monitor subsequent POs. If the UE misses a WUS opportunity (e.g. due to cell reselection), it monitors each PO until the next WUS starts, or until the PTW ends (whichever is earlier).

[0027] - numPOs = the number of consecutive Paging Occasions (PO) mapped to one WUS as provided in the system information, where (numPOs ≥ 1).

[0028] The WUS configuration provided in the system information includes the time offset between the end of the WUS and the start of the first of the numPOs POs that the UE needs to monitor. The time offset in subframes used to calculate the start of subframe g0 (see TS 36.213) is defined as follows:

[0029] - For UEs using DRX, this is the signaled timeoffsetDRX;

[0030] - For UEs using eDRX, if timeoffset-eDRX-Long is not broadcast, it is the signaled timeoffset-eDRX-Short;

[0031] - For UEs using eDRX, if timeoffset-eDRX-Long is broadcast, it is the value determined according to Table 7.4-1.

[0032] Table 7.4-1: Determination of the gap between the end of WUS and the associated PO

[0033]

[0034] The time offset is used to determine the actual subframe g0 as follows (taking into account the resulting SFN and / or H-SFN surround for this calculation):

[0035] g0=PO–time offset, where PO is the paging occasion subframe defined in clause 7.1.

[0036] For UEs using eDRX, for all WUS occurrences of a PTW, the same time offset applies between the end of the WUS and the associated first PO among nomos POs.

[0037] The time offset, g0, is used to calculate the start of the WUS defined in TS 36.213.

[0038] ********************************************************************

[0039] Essentially, if the UE is able to start the primary receiver as fast as indicated by the value used in the SI, it will only use WUR or timeOffset-eDRX-Long. Otherwise, it will fall back to using timeOffset-eDRX-Short (without WUR).

[0040] Figure 3 The use of eDRX and DRX WUS gaps for NB-IoT and LTE-M is shown. The horizontal axis represents the time domain.

[0041] Because the UEs share the PO, the eNB may have to send up to three WUSs for one PO in the worst case, corresponding to timeoffsetDRX, timeoffset-eDRX-Short and timeoffset-eDRX-Long.

[0042] Rel-16 WID agreed that WUS should be further developed to include UE grouping so that the number of UEs triggered by WUS is further narrowed down to a smaller subset of UEs associated with a specific paging occasion (PO).

[0043] The goal is to specify improvements for machine type communications for low complexity (BL) / coverage enhanced (CE) UEs with reduced bandwidth, e.g. including improved downlink transmission efficiency and / or UE power consumption in support of UE-GWUS.

[0044] One purpose is to reduce the false paging rate, i.e., to avoid a given UE being unnecessarily woken up by a WUS transmission intended for another UE. This feature is called Rel-16 Group WUS or GWUS. However, this is not directly related to WUR and will not be further described in this article.

[0045] Rel-17 discussions began with the introduction of WUS for NR, then known as "Paging Early Indication" (PEI). However, because coverage enhancement had not yet been specified for NR, the only benefit of Rel-17 PEI was for scenarios where a small number of UEs were in poor coverage and had large synchronization errors due to the use of longer DRX cycles. The benefit for these UEs was that, with PEI, they typically only had to acquire one SSB before decoding the PEI, compared to up to three SSBs without PEI. For most UEs, Rel-17 PEI would result in performance gains or improvements.

[0046] Rel-17 PEI will also support UE grouping for false paging reduction, similar to the Rel-16 GWUS mentioned above, which will have some gains at high paging loads.

[0047] The PEI will be PDCCH based, as described below, which makes it less interesting for WUR (ie, a primary baseband receiver is required to decode the PEI).

[0048] In Rel-18, there is considerable interest in introducing WUR for New Radio (NR). As mentioned above, the only specification support required to enable the use of WUR in the UE is the specification of a WUS and a sufficiently long time gap between the WUS and the PDCCH in the PO (to enable the UE to start the primary receiver). Therefore, the main difference from Rel-17 PEI is that the WUS in Rel-18 should not be PDCCH-based and allow for simpler and lower-power receivers, namely WUR that utilizes simple modulation and detection techniques (for example, using on-off keying (OOK) modulation and non-coherent detection).

[0049] In Rel-18, a research project on "Low-power wake-up signals and receivers for NR" has been approved. The relevant demonstrations and objectives include the following (RP-213645).

[0050] Fifth-generation (5G) systems are designed and developed with mobile phones and vertical use cases in mind. In addition to latency, reliability, and availability, UE energy efficiency is crucial for 5G. Currently, 5G devices may require weekly or daily charging, depending on individual usage. Typically, 5G devices consume tens of milliwatts in the Radio Resource Control (RRC) idle / inactive state and hundreds of milliwatts in the RRC connected state. Designing for extended battery life is essential for improved energy efficiency and a better user experience.

[0051] Energy efficiency is even more critical for UEs without a continuous energy source (for example, those using small rechargeable batteries and single coin cells). Within vertical use cases, sensors and actuators are widely deployed for monitoring, measurement, and charging. Typically, their batteries are non-rechargeable and are expected to last for at least several years, as described in TR 38.875. Wearable devices include smartwatches, rings, electronic health devices, and medical monitoring equipment. Maintaining the required power for 1-2 weeks is extremely challenging with typical battery capacities.

[0052] Power consumption depends on the length of the configured wake-up period (e.g., paging cycle). To meet the aforementioned battery life requirements, a longer eDRX cycle is expected, but this results in higher latency, making it unsuitable for services that require both long battery life and low latency. For example, in a fire detection and suppression use case, fire shutters should close and actuators should open fire sprinklers within 1-2 seconds of fire detection by sensors. A longer eDRX cycle would not meet the latency requirements. Therefore, eDRX is clearly unsuitable for latency-critical use cases. The intention is to investigate ultra-low power mechanisms that can support low latency (e.g., lower than eDRX latency) in Rel-18.

[0053] Currently, the UE needs to wake up regularly once during each DRX cycle, which dominates power consumption during periods without signaling or data traffic. If the UE could wake up only when it is triggered (e.g., by paging), power consumption could be significantly reduced. This could be achieved by using a wake-up signal to trigger the primary radio and having a separate receiver that monitors the wake-up signal with ultra-low power consumption. The primary radio is used for data transmission and reception and can be turned off or set to deep sleep unless turned on.

[0054] The power consumption for monitoring the wake-up signal depends on the wake-up signal design and the hardware blocks of the wake-up receiver for signal detection and processing.

[0055] Research should primarily focus on low-power WUS / WUR for power-sensitive, small devices, including IoT use cases (e.g., industrial sensors, controllers) and wearables, while not excluding other use cases (e.g., XR / smart glasses, smartphones).

[0056] In contrast to the work on UE energy conservation in previous releases, this study will not require the use of existing signals as WUS. All confirmed WUS solutions should be able to operate in cells supporting legacy UEs. These solutions should aim for substantial gains compared to existing Rel-15 / 16 / 17 UE energy conservation mechanisms. The evaluation should also cover other aspects such as detection performance, coverage, and UE complexity.

[0057] The research project includes the following objectives:

[0058] • Confirm the evaluation methodology (including use cases) and key performance indicators (KPIs). This is mainly targeted at low-power WUS / WUR for power-sensitive, small devices including IoT use cases (e.g., industrial sensors, controllers) and wearables.

[0059] • Research and evaluate low power wake-up receiver architectures

[0060] • Research and evaluate wake-up signal designs to support wake-up receivers

[0061] • Study and evaluate the Layer 1 (L1) procedures and higher layer protocol changes required to support wake-up signaling

[0062] • Study the potential UE energy savings gains and their coverage availability, as well as latency impact compared to existing Rel-15 / 16 / 17 UE energy savings mechanisms. The study should include system impacts (e.g., network power consumption, coexistence with non-low power WUR UEs, network coverage / capacity / resource overhead).

[0063] For more details regarding, for example, recommendations for WUR architecture and design, receiver power versus sensitivity tradeoffs, see, for example, RP-212005, RP-212254, RP-212367, and RP-212427.

[0064] The benefit of WUR is that it reduces the receiver's energy consumption, allowing the UE to remain in a power-saving state unless there are any paging or data requests for the UE. This will extend the device's battery life, or alternatively, enable shorter downlink latency (shorter DRX) given a fixed battery life. For short-range communications, WUR power can be low enough (~3 uW), which can even be combined with energy harvesting to enable WUR to be continuously on (i.e., without DRX or duty cycling) without the need for a battery. This can be seen as a key enabler for battery-free devices towards the sixth generation (6G).

[0065] Support for WUR was more explicit within the Institute of Electrical and Electronics Engineers (IEEE) than within 3GPP. That is, the focus was on low-power WUR from the outset, with the design using WUR not only for receiving WUS but also for receiving other control signals and signaling (e.g., synchronization and mobility information). This enabled stations (corresponding to UEs in 3GPP) to use WUR exclusively when no user plane data transmission was in progress.

[0066] Similar to the 3GPP solution, the use of WUR is enabled only in stations and is not enabled in access points (APs) which are used for downlink communications only. The AP advertises its WUR operation capability along with the WUR configuration parameters (among other information, in which band / channel the WUR can operate, which can be different from the band / channel used for data transmission using the primary receiver, e.g. WUR in the 2.4 GHz band but data communications in the 5 GHz band. Also, note that the WUR operating channel is advertised in the beacon and the WUR discovery operating channel can be different from the WUR operating channel.) The station can then request to be configured with the WUR operation mode. This request must be approved by the AP and if approved, the station will be further configured / set up for the WUR operation mode (this configuration is only valid for the connection to the associated AP and, furthermore, this configuration must be torn down / deconfigured if WUR is no longer used). Both continuous WUR (receiver always on) and duty cycle WUR (receiver only on during preconfigured time slots) operation modes are supported. For the latter, the duty cycle and length of the on-time during wake-up are part of the WUR configuration.

[0067] Unlike the 3GPP solution, the WUR mode of operation is a sub-state of normal operation, and when a WUS transmission from the AP is detected, the station will resume the power-saving mechanism that was configured before entering the WUR mode of operation. That is, the IEEE specifies a number of different power-saving mechanisms, and for example, if downlink duty cycle monitoring has been configured for the station, then when a WUS is detected, the station will switch to downlink duty cycle monitoring (i.e., unlike the specified 3GPP mechanism that only covers paging, and if a WUS is detected, the UE will continue to monitor the PDCCH). In this way, the IEEE WUR functionality is more versatile and still allows the station to monitor paging by checking the beacon from the AP for data on which stations are present when a WUS is detected, or allows the station to respond directly with an uplink transmission.

[0068] Stations receiving IEEE WUS must synchronize with the wireless medium before performing any transmissions. This is done using synchronization information from beacons sent by the AP (typically every 100ms) or from transmissions received by other stations. Synchronizing with the wireless medium, as defined in IEEE 802.11, means that a station waking up from sleep to transmit must perform a channel idleness assessment until it receives one or more frames that allow it to properly set up virtual carrier sensing. This is to prevent collisions with transmissions from hidden nodes. Virtual carrier sensing essentially tells a station to delay for a period of time even if the wireless medium appears idle. This is achieved by receiving a frame indicating the duration of an ongoing frame exchange. In WiFi, a single beacon transmission is typically sufficient for stations to synchronize (i.e., there is no need to acquire multiple transmissions due to poor coverage). Unlike operating in licensed bands, stations must also apply carrier sensing and may also reacquire channel sensing parameters before uplink transmissions.

[0069] The IEEE physical WUS consists of a complete frame that must be processed by the station. The disadvantage of this design is that it requires more processing and action in the station, compared to a simple WUR design that triggers a predefined activity upon detection of a WUS. The advantage is that it contains more information and provides a more versatile solution. The IEEE WUS includes information indicating whether the WUS is a WUR synchronization beacon (see below), a WUR discovery beacon (see below), or a regular WUS (intended to wake up the station). The WUS may also contain proprietary frames, which can be used, for example, to directly turn actuators on and off. Transmissions use on / off keying (OOK) modulation with Manchester encoding, but utilize multi-carrier OOK that can be generated by an orthogonal frequency division multiplexing (OFDM) transmitter (i.e., WUR can be enabled with a software upgrade in the AP). The WUS is 4 MHz wide, but reserves the entire 20 MHz channel. The WUS begins with a traditional 20 MHz preamble (to allow other stations to perform carrier sensing), followed by 4 MHz of Manchester-coded OOK. Two data rates are supported: 62.5kbps and 250kbps, and link adaptation is decided by the AP (each packet is self-contained and includes the data rate, i.e., in WUR there are two possible sync words for signaling the data rate).

[0070] A WUS can contain the following information: a site ID or group ID (grouping of supported stations); a payload of up to 22 bytes; short frames contain only basic information; which WUR frame type plus addressing; normal frames contain control information and, in addition, proprietary information; a WUR beacon contains a basic service set identifier (BSS-ID), synchronization information, a time counter; similar structures for WUS and WUR beacons (a synchronization word indicates the data rate, a station can then detect the header from which it can tell whether it is a WUS or a beacon, and then check the body); and a WUR discovery frame contains mobility-related information to allow low-power scanning (see below).

[0071] Regarding mobility, both WUR Sync Beacons and WUR Discovery Beacons have been specified, which only need to be received using WUR, so that the station can remain in WUR operating mode unless there is a data transmission for the station. In other words, the station only needs to switch back to the legacy Power Save Mode (PSM) when a WUS is detected (or when moving to a new AP). The station uses the WUR Sync Beacon to obtain coarse synchronization (for data transmission, the legacy beacon must still be acquired), and the WUR Discovery Beacon is used to carry (legacy) mobility information for fast / low energy scanning (if the channel quality degrades, the station is allowed to use only WUR to obtain information related to local and roaming scans for nearby APs (e.g., Service Set Identifier (SSID) and Primary Radio (MR) operating channel)).

[0072] That is, in the WUR discovery beacon, the AP can indicate one or more BSSs (Basic Service Set, and the BSS-ID has a one-to-one mapping with the assigned SSID name) that support WUR, so that the station does not need to scan all frequencies / channels. Because the WUR discovery beacon contains legacy mobility information, this means that there is some duplication / redundancy in the broadcast information. This allows low-power scanning using only WUR. However, note that mobility in IEEE is limited to the same AP and does not support switching between APs in the same way as in 3GPP, etc. If a station in WUR operating mode moves to a new AP, it must exit WUR operating mode and use the primary receiver to obtain beacons, synchronize, configure, and associate to the new AP.

[0073] Certain challenges currently exist. For example, the primary benefit of Rel-18 NR WUR lies in enabling the primary receiver to remain in a power-saving state as long as possible. The longer the primary receiver can remain in this sleep state, the greater the gain. Furthermore, deeper sleep states, namely "Ultra Deep Sleep (UDS)," have also been considered. In UDS, more functions and hardware can be shut down, further increasing WUR gains. However, this comes at the expense of longer startup times and higher conversion energy compared to conventional deep sleep.

[0074] In the current discussion, when operating with WUR, the UE's primary radio assumes that UDS is always performed in RRC Idle mode to save energy. However, under certain conditions, such as when the UE wake-up rate (paging and / or false alarm rate (FAR)) is high, UDS may not be the optimal choice. In this case, the UE needs to wake up more frequently, and the higher switching energy will offset the potential energy savings. This can also apply to connected mode operation. Therefore, a mechanism is needed on the UE side to ensure appropriate sleep states to maximize energy savings. Summary of the Invention

[0075] As mentioned above, wake-up signals (WUS) and New Radio (NR) currently present certain challenges. From the gNB's perspective, an offset is required between the WUS and the paging occasion (PO) to ensure that the user equipment (UE) wakes up before the PO. When the primary radio is in ultra-deep sleep (UDS), this offset should be long enough to cover the ramp-up and resynchronization period. However, if the discontinuous reception (DRX) cycle length is shorter than the UDS ramp-up and resynchronization time, the corresponding offset also needs to be adjusted.

[0076] Certain aspects of the present disclosure and its embodiments may provide solutions to these and other challenges. In certain embodiments, the gNB may configure different offsets after WUS detection based on various criteria, for example, based on a predefined table. The UE may switch to sleep mode based on various given conditions or specific offsets after WUS detection configured by the gNB.

[0077] According to some embodiments, a method is performed by a wireless device for performing WUS monitoring. The wireless device is capable of operating in multiple sleep modes. The method includes: operating in accordance with a first sleep mode of the multiple sleep modes; determining to switch from the first sleep mode to a second sleep mode of the multiple sleep modes; and operating in accordance with the second sleep mode.

[0078] In certain embodiments, the determination to switch from the first sleep mode to the second sleep mode is based on a time offset between WUS and PO.

[0079] In a particular embodiment, switching from a first sleep mode to a second sleep mode is determined based on one or more of: latency requirements; quality of service (QoS); discontinuous reception (DRX) or wake-up radio (WUR) duty cycle length; radio resource control (RRC) status; paging rate; traffic characteristics; WUR false alarm rate; coverage conditions and deployment scenarios; time and frequency synchronization requirements; radio resource management (RRM) measurements; receiver architecture; clock parameters; and battery power.

[0080] In certain embodiments, the switching from the first sleep mode to the second sleep mode is determined based on a WUS detection rate of the wireless device or a wake-up probability of the wireless device. In certain embodiments, the switching from the first sleep mode to the second sleep mode is determined based on a timer associated with the first sleep mode.

[0081] In certain embodiments, determining to switch from the first sleep mode to the second sleep mode includes: the wireless device automatically determining to switch from the first sleep mode to the second sleep mode. In certain embodiments, determining to switch from the first sleep mode to the second sleep mode includes: receiving an indication from a network node to switch from the first sleep mode to the second sleep mode.

[0082] In certain embodiments, the method further includes sending an indication of capabilities of the wireless device associated with the plurality of sleep modes to a network node.

[0083] In certain embodiments, the method further includes receiving an indication of an offset time between the WUS and the PO.

[0084] In certain embodiments, the method further includes receiving an indication of a wakeup probability group associated with the wireless device.

[0085] According to some embodiments, a wireless device comprises processing circuitry operable to perform any of the methods of the wireless device described above.

[0086] Also disclosed is a computer program product comprising a non-transitory computer-readable medium storing computer-readable program code, the computer-readable program code being operable, when executed by a processing circuit, to perform any of the methods described above for execution by a wireless device.

[0087] According to some embodiments, a method is performed by a network node in communication with a wireless device configured to perform wake-up signal monitoring. The wireless device is capable of operating in multiple sleep modes. The method includes determining one or more timing offsets for the wireless device. The one or more timing offsets are applied to a time offset after the wireless device detects a wake-up signal (WUS). The method also includes sending the one or more timing offsets to the wireless device.

[0088] In certain embodiments, the one or more time offsets are determined based on a sleep mode of the wireless device.Determining the one or more timing offsets may also be based on one or more of a wakeup probability group and a DRX cycle associated with the wireless device.

[0089] In certain embodiments, the timing offset in the one or more timing offsets includes an offset between WUS and PO.

[0090] In certain embodiments, the method further includes sending an indication to the wireless device to switch from the first sleep mode to the second sleep mode.

[0091] In certain embodiments, the method further includes receiving, from the wireless device, an indication of capabilities of the wireless device associated with the plurality of sleep modes.

[0092] In certain embodiments, the method further includes sending an indication of a wakeup probability group associated with the wireless device to the wireless device.

[0093] According to some embodiments, a network node comprises processing circuitry operable to perform any of the above-described network node methods.

[0094] Another computer program product includes a non-transitory computer readable medium storing computer readable program code operable when executed by a processing circuit to perform any of the methods described above for execution by a network node. BRIEF DESCRIPTION OF THE DRAWINGS

[0095] For a more complete understanding of the disclosed embodiments and their features and advantages, reference is now made to the following description in conjunction with the accompanying drawings, in which:

[0096] Figure 1 The location of the wake-up signal (WUS) and its associated paging occasion are shown;

[0097] Figure 2 WUS for Narrowband IoT (NB-IoT) and Long Term Evolution for Machines (LTE-M) is shown;

[0098] Figure 3 The use of eDRX and DRX WUS gaps for NB-IoT and LTE-M is shown;

[0099] Figure 4 is a diagram illustrating different UE sleep states, each with a specific power consumption and transition energy / time to an on state;

[0100] Figure 5 The offset of the WUS signal from the primary radio drx-on start frame is shown;

[0101] Figure 6 An example of minimum time offset is shown;

[0102] Figure 7 Another example of minimum time offset is shown;

[0103] Figure 8 An example communication system according to certain embodiments is shown;

[0104] Figure 9shows an example user equipment (UE) according to certain embodiments;

[0105] Figure 10 shows an example network node according to certain embodiments;

[0106] Figure 11 A block diagram of a host computer according to some embodiments is shown;

[0107] Figure 12 illustrates a virtualized environment according to some embodiments, in which functionality implemented by some embodiments may be virtualized;

[0108] Figure 13 shows a host communicating with a UE via a network node over a partially wireless connection according to certain embodiments;

[0109] Figure 14 A method performed by a wireless device according to some embodiments is shown; and

[0110] Figure 15 A method performed by a source network node according to certain embodiments is shown. DETAILED DESCRIPTION

[0111] As described above, wake-up signals (WUS) and New Radio (NR) currently present certain challenges. Certain aspects of the present disclosure and embodiments thereof may provide solutions to these and other challenges. In certain embodiments, the gNB may configure different offsets after WUS detection based on various standards, for example, a predefined table. User equipment (UE) may switch to sleep mode based on various given conditions or the specific offset after WUS detection configured by the gNB.

[0112] Certain embodiments are described more fully with reference to the accompanying drawings. However, other embodiments are also within the scope of the subject matter disclosed herein, and thus the disclosed subject matter should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided merely as examples to convey the scope of the subject matter to those skilled in the art.

[0113] Certain embodiments are described for scenarios where a UE may enter different sleep states for energy conservation purposes. Certain embodiments include solutions for efficient UE and network node behavior to maximize UE energy conservation gains by appropriately employing sleep states and configurations.

[0114] Certain embodiments include UE configurations. Some examples assume that the master radio (MR) can operate in K sleep modes with different power consumption, transition energy, and transition time, such as Figure 4 shown.

[0115] Figure 4: is a diagram showing different UE sleep states, each state having a specific power consumption and transition energy / time to an on state (ie, non-sleep state). The vertical axis represents UE power consumption.

[0116] Sleep mode K consumes the lowest power, but requires the longest transition time and the highest energy to wake up. Lighter sleep modes consume more power, but require shorter transition times and lower energy to wake up. Specifically, in state The power is , the transition energy and transition time to state 0 (e.g., non-sleep state) are and In general, a transition can occur between any two states. and Therefore, in certain embodiments, the sleep mode of the MR is configurable to make the operation more energy-efficient for different use cases.

[0117] In one embodiment, for a UE performing WUS monitoring, the MR selects a sleep mode and switches between different sleep modes to maximize its energy savings based on various criteria, including: the offset between WUS and paging occasion (PO); latency requirements and quality of service (QoS); UE discontinuous reception (DRX) or WUR duty cycle length; radio resource control (RRC) state (idle, inactive, connected); UE paging rate (idle mode); traffic characteristics (connected mode); WUR false alarm rate; coverage conditions and deployment scenarios; time and frequency synchronization requirements; radio resource management (RRM measurements and RRM measurement relaxations); receiver architecture, clock parameters, there may be a mapping between sleep states and receiver architecture; and / or UE battery power.

[0118] In a related example, when the UE is in RRC idle mode and the MR operates in sleep mode i between POs, the MR can switch between K sleep modes based on the following criteria. When the UE's wake-up rate (defined as the rate of correct or incorrect WUS detections by the UE per time unit) falls below a certain threshold, the MR can switch to sleep mode i+m (<K). When the wake-up rate rises above a certain threshold, the MR can switch to sleep mode in (>0). The UE wake-up rate includes correct pages, incorrect pages, and false alarms.

[0119] As another example, when the delay requirement of the UE is above a certain threshold, the MR may switch to the sleep mode i+m (<K). When the delay requirement is below a certain threshold, the MR may switch to the sleep mode in (>0).

[0120] In an alternative formulation to the above, the wakeup probability can be used. The wakeup probability is defined as the probability that the UE will receive a WUS and need to activate the primary receiver in one of the UE WUS monitoring scenarios. In the same manner as above, a wakeup probability threshold can be defined for each power sleep state, and the UE is only allowed to enter a deeper sleep state if the wakeup probability is lower than the configured wakeup probability for the sleep state.

[0121]

[0122] The wakeup probability depends on the UE's downlink traffic characteristics and WUS duty cycle length, as well as the false alarm rate, WUS UE group size, and false paging. Therefore, it may be necessary to provide different wakeup probability thresholds to the UE based on the UE's WUS duty cycle length, WUS UE group size, and other configurations. Traffic characteristics do not have an impact because they are actually used to compare with the threshold.

[0123] There are various levels of network control for the above implementations. One is internal to the UE, where the UE measures the probability of waking up over a certain period of time and, based on internal thresholds, determines the most appropriate sleep state to remain in. The optimal power-saving state depends on the UE vendor and UE implementation. This option has no impact on the specification and does not require network control.

[0124] The other is full network control, where the network estimates the UE's wake-up probability based on the history of data transmissions for the UE that triggered the WUS and the WUS sent to other UEs in the UE's paging group. The mode of energy-saving state is determined by the network, and the network uses thresholds internally to determine the most suitable power sleep state for the UE and then communicates it to the UE. The specification needs to include signaling of the power state recommendation to the UE (and possibly the associated WUS-PO time offset, see below).

[0125] In a hybrid solution, power states are specified (e.g., based on a power range for each state). The mode of power saving state is determined by the network, which determines the power state thresholds based on UE configuration parameters, WUS duty cycle, etc. The UE measures the wake-up probability over a certain period of time and, based on the thresholds communicated to the UE by the network, determines the most appropriate sleep state to stay in. The specification needs to include signaling of the power state thresholds to the UE (and possibly associated WUS-PO time offsets, see below).

[0126] The above embodiment depends on whether the UE identifier can be included in the WUS payload (WUS signal design is pending). This is because if the UE identifier is not included, the WUS will trigger the UE to monitor the traditional paging process, whether due to a correct WUS, a false alarm, or a WUS for another UE, and the UE must activate the primary receiver (and incur the cost of high conversion energy). If the WUS does include the UE identifier, there will be no false paging, and the UE will directly trigger random access, and therefore only activate the primary receiver when receiving a WUS containing the UE's own identifier. Therefore, this will affect how the threshold is set.

[0127] In another related example, when the UE is in RRC connected mode and the MR operates in sleep mode i between On-Durations, the UE can switch between K sleep modes based on the following criteria: When the UE's traffic arrival rate is below a certain threshold, the MR can switch to sleep mode i+m (<K). When the traffic arrival rate is above a certain threshold, the MR can switch to sleep mode in (>0).

[0128] As another example, when the delay requirement of the UE is above a certain threshold, the MR may switch to the sleep mode i+m (<K). When the delay requirement is below a certain threshold, the MR may switch to the sleep mode in (>0).

[0129] In another embodiment, each sleep state is associated with a timer, and the UE remains in the sleep state for a specific duration. state seconds, and the parameters It can also be optimized, configured, or predetermined based on different criteria. This provides additional flexibility for controlling latency and synchronization errors. For example, prolonged periods of ultra-deep sleep with no or poor clock accuracy can result in significant time-frequency drift, which can require significant resynchronization when the UE needs to wake up. Therefore, it is beneficial to have a timer for controlling sleep states to adjust the duration of each state.

[0130] In another embodiment, each sleep state is associated with certain functions and specific receiver parameters. Furthermore, depending on the state, some receiver components (e.g., clocks, memory, low-noise amplifiers (LNAs), analog-to-digital converters (ADCs), etc.) may be active or inactive. In this case, a mapping can exist between sleep states and receiver functions and parameters / architecture / components. States can be predefined based on various factors, including desired power savings and latency requirements, and these states can then be mapped to various receiver functions / parameters / architecture / components.

[0131] In another embodiment, the UE sleep state selection and / or switching is performed periodically or dynamically (e.g., in an event-triggered manner). From now on, UE The CPU wakes up periodically to perform certain tasks.

[0132] Some embodiments include gNB configuration. Assume that the gNB can configure N different offsets between the WUS and the PO. Specifically, offset N takes the longest time. Therefore, different offsets are configurable, which enables more flexible operation and latency tolerance for different use cases.

[0133] The time offset between WUS and PO needs to be longer than the start-up time for the primary receiver. Therefore, the WUS-PO time offset limits the power sleep states that the UE can apply. In this way, the configuration of the WUS-PO time offset indirectly determines the UE's power sleep state (assuming that the UE will enter a deep sleep state whenever possible to minimize energy consumption). The problem is that a common configuration is applied to the UE for monitoring paging in both idle and inactive states. Therefore, a UE-specific WUS-PO time offset is not directly applied, which could benefit UE energy consumption.

[0134] For example, even if two UEs have the same WUS duty cycle / DRX cycle length, the optimal power sleep state for the two UEs can be different depending on the difference in wake-up probability (e.g., if the first UE is almost never paged, it will be beneficial for it to remain in a very deep sleep state compared to the second UE that is paged in every WUS / paging occasion). Therefore, it is beneficial to be able to configure different power sleep states and / or WUS-PO time offsets for the UEs. Keeping track of the UE wake-up probability requires keeping track of UE data profiles and / or historical data, which is most easily done at the core network (CN) level.

[0135] In one embodiment, a UE is configured / assigned a specific wakeup probability group (or alternatively, notified by the network of its wakeup probability group) via non-access stratum (NAS) signaling by the CN (Access and Mobility Management Function (AMF)). The CN also notifies the radio access network (RAN) of the UE's wakeup probability group during paging (e.g., as a new information element (IE) in the UE's radio paging capabilities (for CN paging in idle)) or to the anchor gNB (e.g., as a supplement to the UE context (for RAN paging in inactive)). During paging, both the UE and the network will have a common understanding of the UE's WUS duty cycle / DRX cycle in the cell and the UE's wakeup probability. Based on this information, a specific relationship (e.g., an equation or table) can be specified by which both the UE and gNB can determine the WUS-PO time offset to apply to paging the UE based on the combination of the WUS duty cycle / DRX cycle and the wakeup probability.

[0136] WUS-PO time offset = f(WUS duty cycle / DRX cycle, wake-up probability). The table in the specification is used as follows, where g0 < g1 < g2 < g3:

[0137]

[0138] Some embodiments are related to UE capabilities. The UE main receiver is composed of multiple building blocks, and these building blocks can selectively enter "sleep" mode based on the main receiver's wake-up frequency, corresponding to the different sleep modes in some previous embodiments. For example, for the deepest sleep, all receiver building blocks can enter "sleep" mode, while if the main receiver wakes up more frequently, it is best to put only part of the receiver into sleep mode.

[0139] Table 1: Wake-up times for different building blocks

[0140]

[0141] As an example, the wake-up times shown in Table 1 can be mapped to UE capabilities corresponding to different sleep modes depending on which building block to wake up, e.g., for deep sleep mode, the wake-up time can be several time slots, and for shallow sleep mode, the wake-up time can be less than hundreds of microseconds.

[0142] As another example, if the WUR is configured with the same DRX cycle as the primary receiver, after receiving the WUS signal, the offset between the WUS and the primary receiver drx_on time can be configured with different offset values ​​according to different sleep modes. For example, for a long DRx cycle, the MR can enter deep sleep, and in such a case, the offset between the WUS and the primary receiver drx-on time can be longer, which also means that the WUR drx_on timer will start earlier to prepare for receiving an earlier WUS signal from the network.

[0143] As another example, when a short DRX cycle is configured, the WUS offset from the primary receiver's drx_on timer can be configured with a shorter time. A shorter offset can be beneficial for power savings when the WUS and MR share building blocks. This is particularly useful when the short DRX cycle (e.g., 2ms, 3ms) is small and the ramp-up time to wake up the primary receiver is long (e.g., in slot time frames). Having a constant WUS offset from the MR drx_on timer may simply indicate that the primary receiver cannot be enabled in DRX mode.

[0144] Figure 5 The offset of the WUS signal from the MR drx-on start frame is shown. The horizontal axis represents the time domain.

[0145] In the RRC connected state, the connected mode DRX (cDRX) onDurationTimer determines how long the device is expected to monitor the downlink control channel (PDCCH). When the UE receives a PDCCH, the drx-InactivityTimer is triggered and the UE will monitor the PDCCH until it expires, which can exceed the end of the onDurationTimer.

[0146] The end of the onDurationTimer or drx-InactivityTimer and the start of the next onDurationTimer period define the time when the UE can enter the energy-saving sleep mode and the time when the UE can stay in the same sleep mode.

[0147] In one embodiment, UE capability signaling indicates to the network the maximum time tolerance required to switch off its primary receiver to one of one or more power saving sleep states.

[0148] The network can use this capability to configure cDRX parameters including cDRX cycle, onDurationTimer and drx-InactivityTimer to ensure that the UE has sufficient time to shut down and be in energy-saving state.

[0149] Some embodiments include configuration of minimum time offset (MTO). Figure 6 An example is shown in .

[0150] Figure 6 An example of minimum time offset is shown. The horizontal axis represents the time domain.

[0151] In an embodiment, a UE is configured (e.g., via RRC) with a minimum time offset (MTO) associated with wake-up signal (WUS) reception. Upon detecting a WUS, the UE determines a first time slot (slot n1) such that the UE is prepared to perform actions related to WUS detection in a group of time slots following the first time slot (or, alternatively, in a group of time slots starting with the first time slot). The first time slot is determined based on the time slot in which the WUS was detected (slot n0) and the configured MTO. The first time slot may also be determined based on the availability of one or more reference signals (RS) for reception by the UE. For example, the first time slot may be configured such that it occurs after the MTO (e.g., after a second time slot (slot n2), which is offset from slot n0 by the MTO), and after additional time slots containing one or more reference signals. In response to the WUS detection, the UE performs WUS-related actions in a third time slot (slot n3) in the group of time slots. Slot n3 need not be the same as slot n1, nor the slot immediately following slot n1.

[0152] The one or more reference signals (RS) may include one or more (N) instances of the following:

[0153] • Synchronization Signal Block (SSB) or

[0154] • Primary Synchronization Signal (PSS) or

[0155] • Secondary synchronization signal (SSS) or

[0156] • Tracking Reference Signal (TRS), or

[0157] • Channel State Information Reference Signal (CSI-RS) for tracking or

[0158] • The structure is based on one or more of the above reference signals

[0159] N may be predefined or preconfigured by higher layers (e.g., via RRC). The RS may be used by the UE for purposes such as time / frequency synchronization or tracking, automatic gain control (AGC), or spatial information identification (e.g., beam identification). The UE may use a wake-up receiver (WUR) for WUS detection and a primary receiver for performing WUS-related actions in response to WUS detection. In such cases, the described purpose may be applied to prepare the primary receiver to perform WUS-related actions.

[0160] WUS-related actions can include:

[0161] • PDCCH monitoring and / or detection of Downlink Control Information (DCI) formats for scheduled paging messages (e.g. if the UE is in RRC Idle mode)

[0162] • PDCCH monitoring and / or detection of Paging Early Indication (PEI) messages (e.g., DCI format with Cyclic Redundancy Check (CRC) scrambled by the PEI Radio Network Temporary Identifier (RNTI)) (e.g., if the UE is in RRC Idle mode)

[0163] • If the UE is performing procedures related to DRX operation (e.g. if the UE is in RRC connected mode), start the OnDuration timer

[0164] • Performing a Physical Random Access Channel (PRACH) transmission (e.g., if the WUS includes a paging message for the UE)

[0165] • Perform PDCCH monitoring and / or detection

[0166] • Receive data, perform CSI measurements or reports

[0167] If the WUS spans multiple time slots, time slot n0 may be the last time slot where the WUS is detected.

[0168] MTO can be configured as multiple time slots or OFDM symbols or subframes or frames defined in NR, or in time units such as milliseconds.

[0169] MTO may be included as part of higher layer WUS configuration signaling.

[0170] This mechanism helps low power UE operation. For example, if MTO=X1 is configured (e.g. Figure 5 As shown in Figure 2, the UE has a priori knowledge that if the MR portion of the UE is in a low-power state (sleep state) during WUS monitoring, then at least duration X1 is available for it to transition from the sleep state to the active state (which consumes higher power than the sleep state). If the duration of the transition from sleep to active is allowed to be longer, the operating power for the sleep state is generally lower. Therefore, the UE can determine the lowest possible power consumption state for operating its MR based on the MTO configuration.

[0171] For example, if Figure 5 (Bottom) The configuration shown is MTO = X2 < X1, then the MR may have to be prepared to wake up quickly, but the UE may still be in a dormant state with a transition time less than X2. Figure 5R0, R1, ... shown in represent one or more RSs. If MTO = X1 is configured, R2 is the first available RS that the UE can use to prepare for MR, i.e., it is the first available RS after slot n2 determined based on slot n0 and MTO. If MTO = X2 < X1 is configured, and earlier RSs R1 are available, the UE should use them to prepare for MR to perform WUS-related actions earlier than when MTO = X1.

[0172] MTO can be used regardless of whether the UE is configured for DRX operation (in RRC_IDLE mode or in RRC_CONNECTED mode).

[0173] MTO may be configured by a network node (e.g., gNB) based on the acceptable delay associated with WUS-related actions.

[0174] The UE may indicate one or more preferred time offset values ​​to the gNB. The configured MTO may be based on the preferred time offset values ​​(e.g., configuring the MTO to be at least greater than a minimum preferred value). The preferred time offset values ​​may be indicated via UE capability signaling (e.g., via RRC) or via UE assistance signaling (e.g., via RRC or medium access control (MAC0 control element (CE) or physical layer indication).

[0175] Some embodiments include WUS-triggered RS transmission after MTO.

[0176] In an embodiment, a UE is configured (e.g., via RRC) with a minimum time offset (MTO) associated with wake-up signal (WUS) reception. Upon detecting a WUS, the UE determines a first time slot (slot n1) having one or more reference signals (RS), where slot n1 is determined based on the time slot in which the WUS was detected (slot n0) and the MTO. The UE may determine a second time slot (slot n2) such that the UE is prepared to perform actions associated with WUS detection in a group of time slots following the second time slot (or, alternatively, in a group of time slots starting with the second time slot).

[0177] In response to the WUS detection, the UE performs WUS-related actions in the third time slot (time slot n3) in the group of time slots. Time slot n3 is not necessarily the same as time slot n2, nor is it necessarily the same as the time slot immediately following time slot n2.

[0178] The RS in the slot n1 may exist only in the slot n1, or may exist in a plurality of slots starting with the slot n1.

[0179] Slot n2 may be the slot immediately following the slot with RS, or may be a slot a few additional slots later than the slot with RS.Slot n2 may be the same as slot n1.

[0180] The RS may have a structure similar to one or more of the following NR signals:

[0181] • TRS or CSI-RS for tracking, or

[0182] • Aperiodic CSI-RS for tracking fast SCell activation

[0183] •PSS or

[0184] •SSS

[0185] The UE may determine the RS structure (e.g., bandwidth, duration (e.g., number of slots / repetitions)) based on higher layer signaling (e.g., RRC) and / or information provided by the WUS. The UE may determine time slot n1 based on information provided by the WUS (e.g., offset value).

[0186] RSs can be used by UEs for purposes such as achieving time / frequency synchronization or tracking, AGC, or spatial information identification (e.g., beam identification). The UE can use WURs for WUS detection and MRs for performing WUS-related actions in response to WUS detection. In such cases, the described purpose can be applied to prepare the MR to perform WUS-related actions.

[0187] The WUS-related actions may be similar to the above actions. The MTO configuration details and the details of time slot n0 may be as described above.

[0188] These embodiments facilitate low-power UE operation in a similar manner to that described above, with the added advantage of lower latency. Here, WUS is coupled with on-demand synchronization signal transmission so that the UE MR can be ready as quickly as possible without having to wait for additional time for the occurrence of periodic reference signals (e.g., reference signals within SSBs).

[0189] Figure 7 Another example of minimum time offset is shown. The horizontal axis represents the time domain. The UE detects WUS in time slot n0 and uses time slot n0 and the configured MTO to determine time slot n1. Time slot n1 has reference signal RW. The UE can use RW instead of waiting for another periodic reference signal (such as Figure 7 As shown at the top of the figure, use R2 when MTO=Y1, or Figure 7 As shown at the bottom of , using R1 with MTO=Y2<Y1), WUS-related actions can be prepared to be executed with lower latency than the previous example.

[0190] The following is an example captured as part of 3GPP Release 19 of TS 38.331 (based on v17.2.0) section 6.3.3 on how to use the new information element mr-powerDownTime-r19 to capture the MR power-down time.

[0191] IEPowSav-Parameters is used to convey the capabilities supported by the UE for energy saving preferences.

[0192] PowSav-Parameters information element

[0193]

[0194]

[0195] Figure 8 An example of a communication system 100 according to some embodiments is shown. In the example, the communication system 100 includes a telecommunications network 102, which includes an access network 104 (e.g., a radio access network (RAN)) and a core network 106 including one or more core network nodes 108. The access network 104 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which may be generally referred to as network node 110), or any other similar Third Generation Partnership Project (3GPP) access node or non-3GPP access point. The network node 110 facilitates direct or indirect connection of user equipment (UE), for example, by connecting UEs 112a, 112b, 112c, and 112d (one or more of which may be generally referred to as UE 112) to the core network 106 via one or more wireless connections.

[0196] Example wireless communications over wireless connections include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without the use of wiring, cables, or other material conductors. Additionally, in various embodiments, the communication system 100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals (whether via a wired or wireless connection). The communication system 100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0197] The UE 112 may be any of a variety of communication devices, including a wireless device that is arranged, configured, and / or operable to wirelessly communicate with the network node 110 and other communication devices. Similarly, the network node 110 is arranged, capable, configured, and / or operable to communicate directly or indirectly with the UE 112 and / or with other network nodes or devices in the telecommunications network 102 to enable and / or provide network access (e.g., wireless network access) and / or to perform other functions (e.g., management) in the telecommunications network 102.

[0198] In the depicted example, core network 106 connects network node 110 to one or more hosts (such as host 116). These connections may be direct or indirect via one or more intermediate networks or devices. In other examples, the network node may be directly coupled to the host. Core network 106 includes one or more core network nodes (e.g., core network node 108) constructed using hardware and software components. The features of these components may be substantially similar to those described for UEs, network nodes, and / or hosts, such that the descriptions generally apply to the corresponding components of core network node 108. Example core network nodes include functionality of one or more of the following: a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscription identifier dehiding function (SIDF), a unified data management (UDM), a security edge protection proxy (SEPP), a network exposure function (NEF), and / or a user plane function (UPF).

[0199] The host 116 may be owned or controlled by a service provider other than the operator or provider of the access network 104 and / or the telecommunications network 102, and may be operated by or on behalf of the service provider. The host 116 may host various applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data collection services (e.g., retrieving and compiling data about various environmental conditions detected by multiple UEs), analytics functionality, social media, functionality for controlling or otherwise interacting with remote devices, functionality for an alarm and monitoring center, or any other such functionality performed by a server.

[0200] As a whole, Figure 8The communication system 100 enables connections between UEs, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures (such as a specific standard), which includes but is not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable next-generation standards (e.g., 6G); Wireless Local Area Network (WLAN) standards, such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other suitable wireless communication standards, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards, such as LoRa and Sigfox.

[0201] In some examples, telecommunication network 102 is a cellular network that implements 3GPP standardized features. Thus, telecommunication network 102 can support network slicing to provide different logical networks to different devices connected to telecommunication network 102. For example, telecommunication network 102 can provide ultra-reliable low-latency communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or provide massive machine type communication (mMTC) / massive IoT services to yet other UEs.

[0202] In some examples, UE 112 is configured to send and / or receive information without direct human interaction. For example, the UE can be designed to send information to access network 104 on a predetermined schedule when triggered by an internal or external event, or in response to a request from access network 104. In addition, the UE can be configured to operate in a single RAT or multi-RAT or multi-standard mode. For example, the UE can operate with any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., be configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

[0203] In an example, hub 114 communicates with access network 104 to facilitate indirect communication between one or more UEs (e.g., UE 112c and / or 112d) and a network node (e.g., network node 110b). In some examples, hub 114 can be a controller, a router, a content source and analyzer, or any other communication device described herein with respect to a UE. For example, hub 114 can be a broadband router that enables a UE to access core network 106. As another example, hub 114 can be a controller that sends commands or instructions to one or more actuators in a UE. The commands or instructions can be received from a UE, network node 110, or through executable code, scripts, processes, or other instructions in hub 114. As another example, hub 114 can be a data collector that acts as a temporary storage device for UE data and, in some embodiments, can perform analysis or other processing on the data. As another example, hub 114 can be a content source. For example, for a UE that is a VR headset, display, speaker, or other media delivery device, the hub 114 can retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, and then the hub 114 provides it to the UE directly, after performing local processing, and / or after adding additional local content. In another example, the hub 114 acts as a proxy server or coordinator for the UE, especially when one or more of the UEs are low-energy IoT devices.

[0204] Hub 114 may have a continuous / persistent or intermittent connection to network node 110b. Hub 114 may also allow for different communication schemes and / or schedules between hub 114 and UEs (e.g., UE 112c and / or UE 112d), as well as between hub 114 and core network 106. In other examples, hub 114 is connected to core network 106 and / or one or more UEs via a wired connection. Furthermore, hub 114 may be configured to connect to an M2M service provider via access network 104 and / or to another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node 110 while still being connected through hub 114 via a wired or wireless connection. In some embodiments, hub 114 may be a dedicated hub—i.e., a hub whose primary function is to route communications from network node 110b to UEs / from UEs to network node 110b. In other embodiments, the hub 114 may be a non-dedicated hub—ie, a device operable to route communications between UEs and the network node 110b, but which is additionally capable of operating as a communications origin and / or endpoint for certain data channels.

[0205] Figure 9A UE 200 according to some embodiments is shown. As used herein, a UE refers to a device capable of, configured to, arranged to, and / or operable to wirelessly communicate with a network node and / or other UEs. Examples of UEs include, but are not limited to, smartphones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless customer premises equipment (CPEs), vehicle-mounted or vehicle-embedded / integrated wireless devices, and the like. Other examples include any UE identified by the Third Generation Partnership Project (3GPP), including narrowband Internet of Things (NB-IoT) UEs, machine type communication (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0206] The UE may support device-to-device (D2D) communication, dedicated short-range communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X), for example, by implementing the 3GPP standard for sidelink communication. In other examples, a UE may not necessarily have a "user" in the sense of a human user who owns and / or operates the associated device. Alternatively, a UE may represent a device that is intended to be sold to or operated by a human user but may not be, or may not initially be, associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended to be sold to or operated by an end user but may be associated with or operated for the benefit of a user (e.g., a smart meter).

[0207] UE 200 includes processing circuitry 202 operatively coupled to input / output interface 206, power supply 208, memory 210, communication interface 212, and / or any other components or any combination thereof via bus 204. Some UEs may utilize Figure 9 All or a subset of the components shown in . The level of integration between components may vary from one UE to another UE. In addition, some UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0208] Processing circuitry 202 is configured to process instructions and data and may be configured to implement any sequential state machine operable to execute instructions stored as a machine-readable computer program in memory 210. Processing circuitry 202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.); programmable logic with appropriate firmware; one or more stored computer programs, general-purpose processors (e.g., a microprocessor or a digital signal processor (DSP)) with appropriate software; or any combination thereof. For example, processing circuitry 202 may include multiple central processing units (CPUs).

[0209] In this example, the input / output interface 206 can be configured to provide one or more interfaces to an input device, an output device, or one or more input and / or output devices. Examples of output devices include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, a transmitter, a smart card, another output device, or any combination thereof. An input device can allow a user to capture information into the UE 200. Examples of input devices include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smart card, etc. A presence-sensitive display can include a capacitive or resistive touch sensor to sense input from the user. The sensor can be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. The output device can use the same type of interface port as the input device. For example, a Universal Serial Bus (USB) port can be used to provide both input and output devices.

[0210] In some embodiments, power source 208 is configured as a battery or battery pack. Other types of power sources may be used, such as an external power source (e.g., a power outlet), a photovoltaic device, or a battery cell. Power source 208 may also include power circuitry for delivering power from power source 208 itself and / or an external power source to various components of UE 200 via an input circuit or an interface such as a power cable. The delivered power may be used, for example, to charge power source 208. The power circuitry may perform any formatting, conversion, or other modifications on the power from power source 208 to make it suitable for the various components of UE 200 being powered.

[0211] The memory 210 may be or be configured to include a memory such as a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic disk, an optical disk, a hard disk, a removable tape cartridge, a flash drive, etc. In one example, the memory 210 includes one or more application programs 214 (e.g., an operating system, a web browser application, a widget, a gadget engine, or other application) and corresponding data 216. The memory 210 may store any one or a combination of various operating systems for use by the UE 200.

[0212] Memory 210 can be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disc (HD-DVD) optical drive, an internal hard drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) optical drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), an external micro-DIMM SDRAM, smart card memory (e.g., a tamper-resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or an ISIM), other memory, or any combination thereof. The UICC can be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC, commonly referred to as a "SIM card." Memory 210 can allow UE 200 to access instructions, applications, and the like stored on a temporary or non-transitory storage medium to offload or upload data. An article of manufacture, such as an article of manufacture utilizing a communication system, may be tangibly embodied as or in memory 210 , which may be or include a device-readable storage medium.

[0213] The processing circuit 202 can be configured to communicate with an access network or other network using a communication interface 212. The communication interface 212 may include one or more communication subsystems and may include an antenna 222 or be communicatively coupled to the antenna 222. The communication interface 212 may include one or more transceivers for communication (such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in the access network)). Each transceiver may include a transmitter 218 and / or a receiver 220 suitable for providing network communication (e.g., optical, electrical, frequency allocation, etc.). In addition, the transmitter 218 and the receiver 220 may be coupled to one or more antennas (e.g., antenna 222) and may share circuit components, software, or firmware, or alternatively be implemented separately.

[0214] In the illustrated embodiment, the communication functionality of the communication interface 212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near field communication, location-based communication (such as use of a global positioning system (GPS) for determining location), another similar communication functionality, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, code division multiple access (CDMA), wideband code division multiple access (WCDMA), GSM, LTE, new radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical network (SONET), asynchronous transfer mode (ATM), QUIC, hypertext transfer protocol (HTTP), etc.

[0215] Regardless of the type of sensor, the UE can provide an output of the data captured by its sensor via its communication interface 212 via a wireless connection to a network node. The data captured by the UE's sensor can be transmitted via another UE via a wireless connection to a network node. The output can be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to balance the load of reports from several sensors), in response to a trigger event (e.g., sending an alert when humidity is detected), in response to a request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0216] As another example, a UE may include an actuator, motor, or switch associated with a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input, the state of the actuator, motor, or switch may change. For example, the UE may include a motor that adjusts the control surfaces or rotors of a drone in flight based on the received input, or adjusts a robotic arm performing a medical procedure based on the received input.

[0217] When a UE takes the form of an Internet of Things (IoT) device, the UE may be a device used in one or more application areas including, but not limited to, urban wearable technology, expanded industrial applications, and healthcare. Non-limiting examples of such IoT devices are devices that are or are embedded in: a connected refrigerator or freezer, a TV, connected lighting, an electric meter, a robotic vacuum cleaner, a voice-activated smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / humidity sensor, an electronic door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smartwatch, a fitness tracker, a head-mounted display for augmented reality (AR) or virtual reality (VR), a wearable device for tactile enhancement or sensory enhancement, a sprinkler, an animal or item tracking device, a sensor for monitoring plants or animals, an industrial robot, an unmanned aerial vehicle (UAV), and any kind of medical device (such as a heart rate monitor or a teleoperated surgical robot). In addition to the above, Figure 9 In addition to the other components depicted for the illustrated UE 200 , a UE in the form of an IoT device may also include circuitry and / or software depending on the intended application of the IoT device.

[0218] As another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another UE and / or a network node. In this case, the UE may be an M2M device, which in the 3GPP context may be referred to as an MTC device. As a specific example, a UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle (e.g., a car, bus, truck, ship, or airplane) or other device capable of monitoring and / or reporting its operational status or other functions associated with its operation.

[0219] In practice, any number of UEs can be used together for a single use case. For example, the first UE could be a drone or integrated into a drone, and provide the drone's speed information (obtained via a speed sensor) to a second UE, which is the remote controller operating the drone. As the user makes changes via the remote controller, the first UE can adjust the drone's throttle (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first and / or second UEs can also include more than one of the aforementioned functionalities. For example, a UE could include both a sensor and an actuator, and handle data communications for both the speed sensor and the actuator.

[0220] Figure 10 A network node 300 according to some embodiments is shown. As used herein, a network node refers to a device capable of, configured to, arranged to, and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, NodeBs, evolved NodeBs (eNBs), and NR NodeBs (gNBs)).

[0221] Base stations can be categorized based on the amount of coverage they provide (or, in other words, their transmit power level), and therefore, depending on the amount of coverage provided, they may also be referred to as femto, pico, micro, or macro base stations. A base station may be a relay node or a relay host node that controls a relay. A network node may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU) (sometimes referred to as a remote radio head (RRH)). Such a remote radio unit may or may not be integrated with an antenna, forming an antenna-integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0222] Other examples of network nodes include a multi-transmission point (multi-TRP) 5G access node, a multi-standard radio (MSR) device (e.g., an MSR BS), a network controller (e.g., a radio network controller (RNC) or a base station controller (BSC)), a base transceiver station (BTS), a transmission point, a transmission node, a multi-cell / multicast coordination entity (MCE), an operation and maintenance (O&M) node, an operation support system (OSS) node, a self-organizing network (SON) node, a positioning node (e.g., an evolved serving mobile location center (E-SMLC)), and / or minimization of drive tests (MDT).

[0223] Network node 300 includes processing circuitry 302, memory 304, a communication interface 306, and a power supply 308. Network node 300 may be comprised of multiple physically separate components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own corresponding components. In some scenarios where network node 300 includes multiple separate components (e.g., BTS and BSC components), one or more separate components may be shared across multiple network nodes. For example, a single RNC may control multiple NodeBs. In such scenarios, each unique NodeB and RNC pair may, in some instances, be considered a single, separate network node. In some embodiments, network node 300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be replicated (e.g., separate memory 304 for different RATs), and some components may be reused (e.g., the same antenna 310 may be shared by different RATs). The network node 300 may also include various sets of components shown for different wireless technologies (e.g., GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technologies) integrated into the network node 300. These wireless technologies may be integrated into the same or different chips or chipsets and other components within the network node 300.

[0224] The processing circuitry 302 may include one or more combinations of the following: a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or encoded logic operable to provide network node 300 functionality, alone or in combination with other network node 300 components (e.g., memory 304).

[0225] In some embodiments, processing circuitry 302 comprises a system on a chip (SOC). In some embodiments, processing circuitry 302 comprises one or more of radio frequency (RF) transceiver circuitry 312 and baseband processing circuitry 314. In some embodiments, radio frequency (RF) transceiver circuitry 312 and baseband processing circuitry 314 may be on separate chips (or chipsets), boards, or units (e.g., a radio unit and a digital unit). In alternative embodiments, some or all of RF transceiver circuitry 312 and baseband processing circuitry 314 may be on the same chip, chipset, board, or unit.

[0226] Memory 304 may include any form of volatile or non-volatile computer-readable memory, including, but not limited to, permanent storage devices, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., a hard drive), removable storage media (e.g., a flash drive, a compact disk (CD), or a digital video disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions usable by processing circuitry 302. Memory 304 may store any suitable instructions, data, or information, including computer programs, software, applications including one or more of logic, rules, code, tables, and / or other instructions that are executable by processing circuitry 302 and usable by network node 300. Memory 304 may be used to store any computations performed by processing circuitry 302 and / or any data received via communication interface 306. In some embodiments, processing circuitry 302 and memory 304 are integrated.

[0227] Communication interface 306 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, communication interface 306 includes port / terminal 316 for sending and receiving data to and from the network, for example, via a wired connection. Communication interface 306 also includes radio front-end circuitry 318, which may be coupled to antenna 310 or, in some embodiments, be part of antenna 310. Radio front-end circuitry 318 includes filter 320 and amplifier 322. Radio front-end circuitry 318 may be connected to antenna 310 and processing circuitry 302. Radio front-end circuitry may be configured to condition signals communicated between antenna 310 and processing circuitry 302. Radio front-end circuitry 318 may receive digital data, which will be transmitted to other network nodes or UEs via a wireless connection. Radio front-end circuitry 318 may use a combination of filter 320 and / or amplifier 322 to convert the digital data into a radio signal having appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna 310. Similarly, when receiving data, antenna 310 may collect radio signals, which may then be converted to digital data by radio front-end circuitry 318. The digital data may be passed to processing circuitry 302. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0228] In certain alternative embodiments, network node 300 does not include separate radio front-end circuitry 318; instead, processing circuitry 302 includes the radio front-end circuitry and is connected to antenna 310. Similarly, in some embodiments, all or some of RF transceiver circuitry 312 is part of communication interface 306. In other embodiments, communication interface 306 includes one or more ports or terminals 316, radio front-end circuitry 318, and RF transceiver circuitry 312 as part of a radio unit (not shown), and communication interface 306 communicates with baseband processing circuitry 314 as part of a digital unit (not shown).

[0229] Antenna 310 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 310 may be coupled to radio front-end circuitry 318 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 310 is separate from network node 300 and may be connected to network node 300 via an interface or port.

[0230] Antenna 310, communication interface 306 and / or processing circuit 302 can be configured to perform any receiving operation and / or certain obtaining operations described herein as being performed by a network node. Any information, data and / or signals can be received from a UE, another network node and / or any other network device. Similarly, antenna 310, communication interface 306 and / or processing circuit 302 can be configured to perform any transmitting operation described herein as being performed by a network node. Any information, data and / or signals can be sent to a UE, another network node and / or any other network device.

[0231] Power supply 308 provides power to the various components of network node 300 in a form appropriate for each component (e.g., at the voltage and current levels required by each corresponding component). Power supply 308 may also include or be coupled to power management circuitry to provide power to the components of network node 300 to perform the functions described herein. For example, network node 300 may be connected to an external power source (e.g., an electrical grid, a power outlet) via an input circuit or an interface such as a cable, whereby the external power source provides power to the power circuitry of power supply 308. As another example, power supply 308 may include a power source in the form of a battery or battery pack connected to or integrated into the power circuitry. The battery may provide backup power if the external power source fails.

[0232] Embodiments of the network node 300 may include more than Figure 10Additional components to the components shown are used to provide certain aspects of the functionality of the network node, including any of the functionality described herein and / or any functionality required to support the subject matter described herein. For example, the network node 300 may include a user interface device to allow information to be input into the network node 300 and to allow information to be output from the network node 300. This may allow a user to perform diagnostic, maintenance, repair, and other management functions on the network node 300.

[0233] Figure 11 is a block diagram of a host 400 according to various aspects described herein, which may be Figure 8 1. The host 400 is an embodiment of a host 116. As used herein, the host 400 can be or include various combinations of hardware and / or software, including processing resources in a standalone server, blade server, cloud-enabled server, distributed server, virtual machine, container, or server farm. The host 400 can provide one or more services to one or more UEs.

[0234] Host 400 includes processing circuitry 402 operatively coupled to input / output interface 406, network interface 408, power supply 410, and memory 412 via bus 404. Other components may be included in other embodiments. The features of these components may be substantially similar to those described with respect to previous figures (such as Figure 3 and Figure 4 ) such that its description is generally applicable to corresponding components of the host 400.

[0235] Memory 412 may include one or more computer programs, including data 416, which may include user data, such as data generated by a UE for host 400, or data generated by host 400 for a UE, and one or more host applications 414. Embodiments of host 400 may utilize only a subset or all of the components shown. Host applications 414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., mobile phones, desktop computers, wearable display systems, head-up display systems). Host applications 414 may also provide user authentication and permission checks and may periodically report health, routing, and content availability to a central node (e.g., a device in the core network or at the edge of the core network). Thus, the host 400 can select and / or instruct the UE on a different host for over-the-top services. The host application 414 can support various protocols, such as HTTP Live Streaming (HLS), Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0236] Figure 12 is a block diagram illustrating a virtualized environment 500 in which the functionality implemented in some embodiments may be virtualized. In this context, virtualization means creating a virtual version of an apparatus or device, which may include virtualizing hardware platforms, storage devices, and network resources. As used herein, virtualization may be applied to any device or component thereof described herein and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 500 hosted by one or more hardware nodes (e.g., hardware computing devices operating as network nodes, UEs, core network nodes, or hosts). Furthermore, in embodiments where the virtual nodes do not require a radio connection (e.g., core network nodes or hosts), the nodes may be fully virtualized at this point.

[0237] Application 502 (which may alternatively be referred to as a software instance, a virtual appliance, a network function, a virtual node, a virtual network function, etc.) runs in virtualization environment Q400 to implement some features, functions and / or benefits of some embodiments disclosed herein.

[0238] Hardware 504 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein (e.g., network interfaces, input / output interfaces, etc.). The software may be executed by the processing circuitry to instantiate one or more virtualization layers 506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 508a and 508b (one or more of which may be generally referred to as VMs 508), and / or perform any of the functions, features, and / or benefits described in connection with some embodiments described herein. Virtualization layer 506 may present a virtual operating platform that appears to VMs 508 as networked hardware.

[0239] Virtual machines 508 include virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and can be run by corresponding virtualization layers 506. Different embodiments of instances of virtual devices 502 can be implemented on one or more of VMs 508, and the implementation can be done in different ways. In some contexts, hardware virtualization is referred to as network function virtualization (NFV). NFV can be used to unify numerous network device types onto industry-standard high-capacity server hardware, physical switches, and physical storage that can be located in data centers and customer premises equipment.

[0240] In the context of NFV, VMs 508 can be software implementations of physical machines that run programs as if they were executed on a physical, non-virtualized machine. Each VM 508 and the portion of hardware 504 that executes that VM (which can be hardware dedicated to that VM and / or hardware shared by that VM and other VMs in the VM stack) form a separate virtual network element. Still in the context of NFV, a virtual network function (VNF) is responsible for handling specific network functions running in one or more VMs 508 on hardware 504 and corresponds to an application 502.

[0241] Hardware 504 can be implemented in a standalone network node with general or specialized components. Hardware 504 can implement some functionality via virtualization. Alternatively, hardware 504 can be part of a larger hardware cluster (e.g., in a data center or CPE), where many hardware nodes work together and are managed via management and coordination 510, which oversees the lifecycle management of application 502. In some embodiments, hardware 504 is coupled to one or more radio units, each of which includes one or more transmitters and one or more receivers that can be coupled to one or more antennas. Radio units can communicate directly with other hardware nodes via one or more suitable network interfaces and can be used in conjunction with virtual components to provide a virtual node with radio capabilities, such as a radio access node or base station. In some embodiments, a control system 512 can be used to provide some signaling, which can alternatively be used for communication between hardware nodes and radio units.

[0242] Figure 13 A communication diagram is shown in which a host 602 communicates with a UE 606 via a network node 604 over a partially wireless connection according to some embodiments. Figure 13 Describe the UE discussed in the previous paragraph (e.g. Figure 8 UE 112a and / or Figure 9 UE 200 in ), network node (e.g., Figure 8 The network node 110a and / or Figure 10 300) and a host (e.g., Figure 8 Host 116 and / or Figure 11 An example implementation of a host 400 according to various embodiments.

[0243] Similar to host 400, embodiments of host 602 include hardware, such as a communication interface, processing circuitry, and memory. Host 602 also includes software, which is stored in or accessible by host 602 and executed by the processing circuitry. The software includes a host application operable to provide services to a remote user, such as a UE 606 connected via an over-the-top (OTT) connection 650 extending between UE 606 and host 602. When providing services to the remote user, the host application can provide user data sent using OTT connection 650.

[0244] The network node 604 includes hardware that enables it to communicate with the host 602 and the UE 606. The connection 660 may be direct or may go through a core network (such as Figure 8 The core network 106 of the present invention and / or one or more other intermediate networks (eg, one or more public, private, or managed networks). For example, the intermediate network can be a backbone network or the Internet.

[0245] UE 606 includes hardware and software, the software being stored in or accessible by UE 606 and executable by processing circuitry within the UE. The software includes a client application (e.g., a web browser or an operator-specific "app") operable to provide services to a human or non-human user via UE 606, with support from host 602. An executing host application within host 602 can communicate with an executing client application via an OTT connection 650 terminated between UE 606 and host 602. In providing services to a user, the UE's client application can receive request data from the host application within the host and provide user data in response to the request data. The OTT connection 650 can transmit both the request data and the user data. The UE's client application can interact with the user to generate user data that is provided to the host application via the OTT connection 650.

[0246] The OTT connection 650 may extend via a connection 660 between the host 602 and the network node 604, and via a wireless connection 670 between the network node 604 and the UE 606, to provide a connection between the host 602 and the UE 606. The connection 660 and the wireless connection 670, through which the OTT connection 650 may be provided, have been drawn abstractly to illustrate communication between the host 602 and the UE 606 via the network node 604, without explicitly mentioning any intermediate devices and the precise routing of messages via these devices.

[0247] As an example of transmitting data via OTT connection 650, in step 608, host 602 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a specific human user who interacts with UE 606. In other embodiments, the user data is associated with UE 606, which shares data with host 602 without explicit human interaction. In step 610, host 602 initiates a transmission carrying the user data to UE 606. Host 602 may initiate the transmission in response to a request sent by UE 606. The request may be initiated by human interaction with UE 606 or by operation of a client application executing on UE 606. In accordance with the teachings of embodiments described throughout this disclosure, the transmission may be via network node 604. Therefore, in step 612, network node 604 transmits the user data carried in the transmission initiated by host 602 to UE 606 in accordance with the teachings of embodiments described throughout this disclosure. In step 614 , the UE 606 receives the user data carried in the transmission, which may be performed by a client application executing on the UE 606 that is associated with a host application executed by the host 602 .

[0248] In some examples, UE 606 executes a client application that provides user data to host 602. The user data may be provided as a reaction or response to data received from host 602. Thus, in step 616, UE 606 may provide the user data, which may be performed by executing the client application. When providing the user data, the client application may also consider user input received from the user via the input / output interface of UE 606. Regardless of the specific manner in which the user data is provided, in step 618, UE 606 initiates transmission of the user data to host 602 via network node 604. In step 620, in accordance with the teachings of the embodiments described throughout this disclosure, network node 604 receives the user data from UE 606 and initiates transmission of the received user data to host 602. In step 622, host 602 receives the user data carried in the transmission initiated by UE 606.

[0249] One or more of the various embodiments improve the performance of OTT services provided to UE 606 using OTT connection 650, where wireless connection 670 forms the last leg in OTT connection 650. More specifically, the teachings of these embodiments can improve the latency of direct activation of SCells via RRC and the power consumption of the user equipment, and thereby provide benefits such as reduced user latency and extended battery life.

[0250] In an example scenario, host 602 may collect and analyze factory status information. As another example, host 602 may process audio and video data that may have been retrieved from a UE for use in creating a map. As another example, host 602 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, host 602 may store surveillance video uploaded by a UE. As another example, host 602 may store or control access to media content such as video, audio, VR, or AR, and may broadcast, multicast, or unicast the media content to the UE. As other examples, host 602 may be used for energy pricing, remote control of non-time-critical electrical loads to balance power generation demand, location services, presentation services (e.g., compiling charts based on data collected from remote devices), or any other function that collects, retrieves, stores, analyzes, and / or transmits data.

[0251] In some examples, a measurement process may be provided for the purpose of monitoring data rates, latency, and other factors improved by one or more embodiments. Optional network functionality may also be provided for reconfiguring the OTT connection 650 between the host 602 and the UE 606 in response to changes in measurement results. The measurement process and / or network functionality for reconfiguring the OTT connection may be implemented in software and hardware on the host 602 and / or the UE 606. In some embodiments, sensors (not shown) may be deployed in the communication devices through which the OTT connection 650 passes, or in association with other devices through which the OTT connection 650 passes. The sensors may participate in the measurement process by providing values ​​for the monitored quantities exemplified above, or other physical quantities that the software can use to calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 650 may include message formats, retransmission settings, preferred routing, and the like; reconfiguration may not require direct changes to the operation of the network node 604. Such processes and functionality may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates the host 602's measurement of throughput, propagation time, latency, and the like. This measurement may be achieved by software enabling the sending of a message (specifically, a null or "dummy" message) using the OTT connection 650 while monitoring propagation time, errors, etc.

[0252] Figure 14 is a flow chart illustrating an example method in a wireless device according to certain embodiments. In certain embodiments, Figure 14 One or more steps may be performed by Figure 9 The described UE 200 performs. The wireless device is capable of operating in multiple sleep modes.

[0253] The method may begin at step 1412, where a wireless device (e.g., UE 200) sends an indication of the wireless device's capabilities associated with multiple sleep modes to a network node. For example, the wireless device may send capabilities regarding wake-up times or shut-down times associated with various receiver components (e.g., a primary receiver) (see, e.g., Table 1). Additional examples are provided with respect to the embodiments and examples described herein.

[0254] At step 1414, the wireless device may receive an indication of the time offset between WUS and PO. For example, the wireless device may receive an indication of the minimum time offset, such as for Figure 6 and Figure 7 As stated.

[0255] At step 1416, the wireless device receives an indication of a wakeup probability group associated with the wireless device. For example, the AFM may configure the wireless device with the wakeup probability group to which the wireless device belongs via NAS signaling. The wakeup probability group may be used later when determining whether to switch to a sleep mode. Further examples are provided for the embodiments and examples described herein.

[0256] At step 1418, the wireless device operates according to a first sleep mode of the plurality of sleep modes. Figure 4 to operate in any of the sleep modes shown.

[0257] At step 1420, the wireless device determines to switch from the first sleep mode to a second sleep mode of the plurality of sleep modes. In certain embodiments, determining to switch from the first sleep mode to the second sleep mode is based on a time offset between the WUS and the PO.

[0258] In a particular embodiment, determining to switch from a first sleep mode to a second sleep mode is based on one or more of: latency requirements; QoS; DRX or WUR duty cycle length; RRC status; paging rate; service characteristics; WUR false alarm rate; coverage conditions and deployment scenarios; time and frequency synchronization requirements; RRM measurements; receiver architecture; clock parameters; and / or battery power.

[0259] In certain embodiments, determining to switch from the first sleep mode to the second sleep mode is based on a WUS detection rate of the wireless device or a wake-up probability of the wireless device. In certain embodiments, determining to switch from the first sleep mode to the second sleep mode is based on a timer associated with the first sleep mode. Further examples are provided for the embodiments and examples described herein.

[0260] In certain embodiments, determining to switch from the first sleep mode to the second sleep mode includes the wireless device automatically determining to switch from the first sleep mode to the second sleep mode. For example, the wireless device may measure a wake-up probability within a certain period of time and determine the most appropriate sleep state to remain in based on an internal threshold. Further examples are provided with respect to the embodiments and examples described herein.

[0261] In certain embodiments, determining to switch from a first sleep mode to a second sleep mode includes receiving an indication from a network node to switch from the first sleep mode to the second sleep mode. For example, the network node may estimate a wake-up probability for the wireless device based on a history of data transmissions for the wireless device that triggered the WUS and WUSs sent to other wireless devices in the wireless device's paging group. The network node may internally use a threshold to determine the most appropriate power sleep state for the wireless device and then communicate the threshold to the wireless device. Additional examples are provided with respect to the embodiments and examples described herein.

[0262] At step 1422, the wireless device operates according to the second sleep mode. Figure 4 Operate in any of the sleep modes shown.

[0263] Can Figure 14 Method 1400 may be modified, added, or omitted. Figure 14 One or more steps in the method may be performed in parallel or in any suitable order.

[0264] Figure 15 is a flow chart illustrating an example method in a network node according to certain embodiments. In certain embodiments, Figure 15 One or more steps may be directed to Figure 10 The network node 300 described herein performs communication with a wireless device configured to perform wake-up signal monitoring. The wireless device is capable of operating in multiple sleep modes.

[0265] The method begins at step 1512, where a network node (eg, network node 300) determines one or more timing offsets for a wireless device. The one or more timing offsets are applied to a time offset after the wireless device detects a WUS.

[0266] In certain embodiments, determining the one or more timing offsets is based on a sleep mode of the wireless device.Determining the one or more timing offsets may also be based on one or more of a wakeup probability group and a DRX cycle associated with the wireless device.

[0267] In certain embodiments, the timing offset in the one or more timing offsets includes an offset between WUS and PO.

[0268] At step 1514, the network node sends one or more timing offsets to the wireless device.Examples are provided with respect to the embodiments and examples described herein.

[0269] At step 1516, the network node may send an indication to the wireless device to switch from the first sleep mode to the second sleep mode. For example, the network node may estimate the wake-up probability of the wireless device based on the history of data transmissions for the wireless device that triggered the WUS and the WUSs sent to other wireless devices in the wireless device's paging group. The network node may internally use a threshold to determine the most appropriate power sleep state for the wireless device and then communicate it to the wireless device. Additional examples are provided with respect to the embodiments and examples described herein.

[0270] At step 1518, the network node may receive from the wireless device an indication of the wireless device's capabilities associated with a plurality of sleep modes. For example, the network node may receive functionality regarding wake-up times or shut-down times associated with various receiver components (e.g., a primary receiver) (see, e.g., Table 1). Further examples are provided with respect to the embodiments and examples described herein.

[0271] At step 1520, the network node may send an indication of a wakeup probability group associated with the wireless device to the wireless device.Examples are provided with respect to the embodiments and examples described herein.

[0272] Can Figure 15 Method 1500 may be modified, added, or omitted. Figure 15 One or more steps in the method may be performed in parallel or in any suitable order.

[0273] The foregoing description sets forth numerous specific details. However, it should be understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail so as not to obscure the understanding of this description. Using the included description, one of ordinary skill in the art will be able to implement appropriate functionality without undue experimentation.

[0274] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment may include that particular feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it should be understood that it is within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other embodiments (whether or not explicitly described).

[0275] Although the present disclosure has been described with reference to specific embodiments, variations and arrangements of the embodiments will be apparent to those skilled in the art. Therefore, the above description of the embodiments does not limit the present disclosure. Other variations, substitutions, and modifications may be present without departing from the scope of the present disclosure as defined by the appended claims.

[0276] Some example embodiments are described below.

[0277] Group A Examples

[0278] 1. A method performed by a wireless device for performing wake-up signal monitoring, the wireless device being capable of operating in multiple sleep modes, the method comprising:

[0279] - operating according to a first sleep mode of a plurality of sleep modes;

[0280] - determining to switch from a first sleep mode to a second sleep mode among a plurality of sleep modes; and

[0281] - operating according to the second sleep mode.

[0282] 2. The method according to the preceding embodiment, wherein determining to switch from the first sleep mode to the second sleep mode is based on one or more of the following:

[0283] a. The offset between the wake-up signal (WUS) and the paging opportunity (PO);

[0284] b. Delay request;

[0285] c. Quality of Service (QoS);

[0286] d. Discontinuous reception (DRX) or wake-up radio (WUR) duty cycle length;

[0287] e.RRC state (idle, inactive, connected);

[0288] f. Paging rate (idle mode);

[0289] g. Service characteristics (connection mode);

[0290] h.WUR false alarm rate;

[0291] i. Coverage conditions and deployment scenarios;

[0292] j. Time-frequency synchronization requirements;

[0293] k.RRM measurement;

[0294] l. Receiver architecture;

[0295] m. Clock parameters; and

[0296] n.Battery charge.

[0297] 3. The method according to any one of the preceding embodiments, wherein the wireless device automatically determines to switch from the first sleep mode to the second sleep mode.

[0298] 4. The method of any one of embodiments 1-2, wherein the wireless device receives an indication from a network node to switch from the first sleep mode to the second sleep mode.

[0299] 5. A method performed by a wireless device, the method comprising:

[0300] - Any one of the above steps, features or functions of the wireless device, alone or in combination with the other steps, features or functions.

[0301] 6. The method according to the above embodiment further includes: one or more additional wireless device steps, features or functions mentioned above.

[0302] 7. The method according to any of the preceding embodiments, further comprising:

[0303] - provide user data; and

[0304] - Forwarding user data to a host computer via transmission to a base station.

[0305] Group B Examples

[0306] 8. A method performed by a base station in communication with a wireless device configured to perform wake-up signal monitoring, the wireless device being capable of operating in multiple sleep modes, the method comprising:

[0307] -determining one or more timing offsets for the wireless device, wherein the one or more timing offsets are applied to a time offset after the wireless device detects a wake-up signal (WUS); and

[0308] -Sending one or more timing offsets to the wireless device.

[0309] 9. The method of any preceding embodiment, wherein determining one or more timing offsets is based on a sleep mode of the wireless device.

[0310] 10. The method of any preceding embodiment, wherein determining the one or more timing offsets is further based on one or more of a wakeup probability group and a discontinuous reception (DRX) cycle associated with the wireless device.

[0311] 11. The method as in any preceding embodiment, wherein the timing offset in the one or more timing offsets comprises an offset between a WUS and a paging occasion (PO).

[0312] 12. The method according to any of the preceding embodiments, wherein the timing offset in the one or more timing offsets comprises

[0313] 13. A method performed by a base station, the method comprising:

[0314] - Any one of the steps, features or functions described above for the base station, alone or in combination with other steps, features or functions described above.

[0315] 14. The method according to the above embodiment further includes: one or more additional base station steps, features or functions mentioned above.

[0316] 15. The method according to any of the preceding embodiments, further comprising:

[0317] - obtain user data; and

[0318] -Forward user data to a host computer or wireless device.

[0319] Group C Examples

[0320] 16. A mobile terminal, comprising:

[0321] - a processing circuit configured to perform any one of the steps of any one of the embodiments in Group A; and

[0322] - A power circuit configured to supply power to the wireless device.

[0323] 17. A base station, comprising:

[0324] - a processing circuit configured to perform any one of the steps of any one of the embodiments in Group B;

[0325] - A power circuit configured to supply power to the wireless device.

[0326] 18. A user equipment (UE), comprising:

[0327] - an antenna configured to transmit and receive wireless signals;

[0328] - a radio front-end circuit connected to the antenna and the processing circuit and configured to control signals transmitted between the antenna and the processing circuit;

[0329] - a processing circuit configured to perform any one of the steps of any one of the embodiments in Group A;

[0330] - an input interface connected to the processing circuitry and configured to allow information to be input into the UE for processing by the processing circuitry;

[0331] - an output interface connected to the processing circuit and configured to output information that has been processed by the processing circuit from the UE; and

[0332] - A battery connected to the processing circuit and configured to supply power to the UE.

[0333] 19. A communication system comprising a host computer, comprising:

[0334] - processing circuitry configured to provide user data; and

[0335] - a communication interface configured to forward user data to a cellular network for transmission to a user equipment (UE),

[0336] - wherein the cellular network comprises a base station having a radio interface and a processing circuit, the processing circuit of the base station being configured to perform any one of the steps of any one of the embodiments of Group B.

[0337] 20. The communication system according to the preceding embodiment further includes a base station.

[0338] 21. The communication system according to the first two embodiments further includes a UE, wherein the UE is configured to communicate with the base station.

[0339] 22. The communication system according to the first three embodiments, wherein:

[0340] - the processing circuitry of the host computer is configured to execute a host application, thereby providing user data; and

[0341] - The UE comprises a processing circuit configured to execute a client application associated with a host application.

[0342] 23. A method implemented in a communication system, the communication system comprising a host computer, a base station, and a user equipment (UE), the method comprising:

[0343] - at the host computer, providing user data; and

[0344] - At a host computer, initiating a transmission carrying user data to the UE via a cellular network including a base station, wherein the base station performs any one of the steps of any one of the embodiments in Group B.

[0345] 24. The method according to the preceding embodiment further includes: sending user data at a base station.

[0346] 25. The method of the two preceding embodiments, wherein the user data is provided at the host computer by executing a host application, the method further comprising executing a client application associated with the host application at the UE.

[0347] 26. A user equipment (UE) configured to communicate with a base station, the UE comprising a radio interface and a processing circuit configured to perform any of the first three embodiments.

[0348] 27. A communication system comprising a host computer, comprising:

[0349] - processing circuitry configured to provide user data; and

[0350] - a communication interface configured to forward user data to a cellular network for transmission to a user equipment (UE),

[0351] -Wherein, the UE comprises a radio interface and a processing circuit, and the components of the UE are configured to perform any one step of any one of the embodiments in Group A.

[0352] 28. The communication system according to the preceding embodiment, wherein the cellular network further comprises a base station configured to communicate with the UE.

[0353] 29. The communication system according to the two preceding embodiments, wherein:

[0354] - the processing circuitry of the host computer is configured to execute a host application, thereby providing user data; and

[0355] - The processing circuitry of the UE is configured to execute a client application associated with the host application.

[0356] 30. A method implemented in a communication system, the communication system comprising a host computer, a base station, and a user equipment (UE), the method comprising:

[0357] - at the host computer, providing user data; and

[0358] - At a host computer, initiating a transmission carrying user data to a UE via a cellular network including a base station, wherein the UE performs any one of the steps of any one of the embodiments in Group A.

[0359] 31. The method according to the preceding embodiment further includes: receiving user data from a base station at the UE.

[0360] 32. A communication system comprising a host computer, comprising:

[0361] - a communication interface configured to receive user data originating from a transmission from a user equipment (UE) to a base station,

[0362] -The UE comprises a radio interface and a processing circuit, and the processing circuit of the UE is configured to perform any one step of any one of the embodiments in Group A.

[0363] 33. The communication system according to the preceding embodiment further includes a UE.

[0364] 34. The communication system according to the two previous embodiments, further comprising a base station, wherein the base station comprises a radio interface configured to communicate with the UE and a communication interface configured to forward user data carried by transmissions from the UE to the base station to a host computer.

[0365] 35. The communication system according to the first three embodiments, wherein:

[0366] - the processing circuitry of the host computer is configured to execute the host application; and

[0367] - The processing circuitry of the UE is configured to execute a client application associated with the host application, thereby providing user data.

[0368] 36. The communication system according to the first four embodiments, wherein:

[0369] - the processing circuitry of the host computer is configured to execute the host application, thereby providing the requested data; and

[0370] - The processing circuitry of the UE is configured to execute a client application associated with the host application to provide user data in response to the request data.

[0371] 37. A method implemented in a communication system comprising a host computer, a base station, and a user equipment (UE), the method comprising:

[0372] - At a host computer, receiving user data sent from a UE to a base station, wherein the UE performs any one step of any one of the embodiments in Group A.

[0373] 38. The method according to the preceding embodiment further includes: at the UE, providing user data to the base station.

[0374] 39. The method according to the previous two embodiments, further comprising:

[0375] - At the UE, executing a client application, thereby providing user data to be sent; and

[0376] - At the host computer, executing a host application associated with the client application.

[0377] 40. The method according to the first three embodiments, further comprising:

[0378] - At the UE, executing the client application; and

[0379] - receiving, at the UE, input data to the client application, the input data being provided at a host computer by executing a host application associated with the client application,

[0380] - wherein the user data to be sent is provided by the client application in response to input data.

[0381] 41. A communication system comprising a host computer, the host computer comprising a communication interface configured to receive user data originating from a transmission from a user equipment (UE) to a base station, wherein the base station comprises a radio interface and a processing circuit, the processing circuit of the base station being configured to perform any one of the steps of any one of the embodiments in Group B.

[0382] 42. The communication system according to the preceding embodiment further includes a base station.

[0383] 43. The communication system according to the first two embodiments further includes a UE, wherein the UE is configured to communicate with the base station.

[0384] 44. The communication system according to the first three embodiments, wherein:

[0385] - the processing circuitry of the host computer is configured to execute a host application;

[0386] - The UE is configured to execute a client application in association with a host application, thereby providing user data to be received by the host computer.

[0387] 45. A method implemented in a communication system comprising a host computer, a base station, and a user equipment (UE), the method comprising:

[0388] - receiving, at a host computer, from a base station user data originating from a transmission that the base station has received from a UE, wherein the UE performs any one of the steps of any one of the embodiments of Group A.

[0389] 46. ​​The method according to the preceding embodiment further includes: receiving user data from the UE at the base station.

[0390] 47. The method according to the previous two embodiments further includes: initiating, at the base station, transmission of the received user data to the host.

Claims

1. A method performed by a wireless device for performing wake-up signal (WUS) monitoring, the wireless device being capable of operating in multiple sleep modes, the method comprising: operating according to a first sleep mode of the plurality of sleep modes (1418); determining ( 1420 ) to switch from the first sleep mode to a second sleep mode of the plurality of sleep modes; and Operating according to the second sleep mode (1422).

2. The method according to claim 1, wherein Determining to switch from the first sleep mode to the second sleep mode is based on a time offset between a WUS and a paging occasion PO.

3. The method according to any one of claims 1 to 2, wherein Determining to switch from the first sleep mode to the second sleep mode is based on one or more of the following: Delayed requests; Quality of Service (QoS); Discontinuous reception DRX or wake-up radio WUR duty cycle length; Radio Resource Control RRC state; Paging rate; Business characteristics; WUR false alarm rate; Coverage conditions and deployment scenarios; Time-frequency synchronization requirements; Radio Resource Management RRM measurements; Receiver architecture; Clock parameters; as well as Battery level.

4. The method according to any one of claims 1 to 3, wherein Determining to switch from the first sleep mode to the second sleep mode is based on a WUS detection rate of the wireless device or a wake-up probability of the wireless device.

5. The method according to any one of claims 1 to 4, wherein Determining to switch from the first sleep mode to the second sleep mode is based on a timer associated with the first sleep mode.

6. The method according to any one of claims 1 to 5, wherein Determining to switch from the first sleep mode to the second sleep mode includes: the wireless device automatically determining to switch from the first sleep mode to the second sleep mode.

7. The method according to any one of claims 1 to 5, wherein Determining to switch from the first sleep mode to the second sleep mode includes receiving an indication from a network node to switch from the first sleep mode to the second sleep mode.

8. The method according to any one of claims 1 to 7, further comprising: An indication of capabilities of the wireless device associated with the plurality of sleep modes is sent (1412) to a network node.

9. The method according to claim 8, wherein The capability includes one or more of a time to wake up the primary receiver and a time to shut down the primary receiver.

10. The method according to any one of claims 1 to 9, further comprising: An indication of an offset time between the WUS and the paging occasion PO is received (1414).

11. The method according to any one of claims 1 to 10, further comprising: An indication of a wakeup probability group associated with the wireless device is received (1416).

12. A wireless device (200) capable of performing wake-up signal (WUS) monitoring and operating in multiple sleep modes, the wireless device comprising a processing circuit (202) operative to: operating according to a first sleep mode of the plurality of sleep modes; determining to switch from the first sleep mode to a second sleep mode among the plurality of sleep modes; and Operating according to the second sleep mode.

13. The wireless device of claim 12, wherein: The processing circuit is operative to determine switching from the first sleep mode to the second sleep mode based on a time offset between a WUS and a paging occasion PO.

14. The wireless device according to any one of claims 12-13, wherein: The processing circuit is operative to determine to switch from the first sleep mode to the second sleep mode based on one or more of: Delayed requests; Quality of Service (QoS); Discontinuous reception DRX or wake-up radio WUR duty cycle length; Radio Resource Control RRC state; Paging rate; Business characteristics; WUR false alarm rate; Coverage conditions and deployment scenarios; Time-frequency synchronization requirements; Radio Resource Management RRM measurements; Receiver architecture; Clock parameters; as well as Battery level.

15. The wireless device according to any one of claims 12 to 14, wherein: The processing circuit is operative to determine to switch from the first sleep mode to the second sleep mode based on a WUS detection rate of the wireless device or a wake-up probability of the wireless device.

16. The wireless device according to any one of claims 12 to 15, wherein: The processing circuit is operative to determine to switch from the first sleep mode to the second sleep mode based on a timer associated with the first sleep mode.

17. The wireless device according to any one of claims 12 to 16, wherein: The processing circuit is operative to determine switching from the first sleep mode to the second sleep mode by automatically determining switching from the first sleep mode to the second sleep mode.

18. The wireless device according to any one of claims 12 to 16, wherein: The processing circuit is operative to determine switching from the first sleep mode to the second sleep mode by receiving an indication to switch from the first sleep mode to the second sleep mode from a network node.

19. The wireless device of any of claims 12-18, the processing circuit further operative to send an indication of capabilities of the wireless device associated with the plurality of sleep modes to a network node.

20. The wireless device of claim 19, wherein The capability includes one or more of a time to wake up the primary receiver and a time to shut down the primary receiver.

21. The wireless device of any of claims 12-20, the processing circuit further operative to receive an indication of an offset time between a WUS and a paging occasion (PO).

22. The wireless device of any of claims 12-21, the processing circuit further operative to receive an indication of a wakeup probability group associated with the wireless device.

23. A method performed by a network node in communication with a wireless device configured to perform wake-up signal monitoring, the wireless device being capable of operating in multiple sleep modes, the method comprising: determining (1512) one or more timing offsets for the wireless device, wherein the one or more timing offsets are applied to a time offset after the wireless device detects a wake-up signal WUS; and The one or more timing offsets are sent (1514) to the wireless device.

24. The method according to claim 23, wherein Determining the one or more timing offsets is based on a sleep mode of the wireless device.

25. The method according to any one of claims 23-24, wherein Determining the one or more timing offsets is further based on one or more of a wakeup probability group and a discontinuous reception (DRX) cycle associated with the wireless device.

26. The method according to any one of claims 23 to 25, wherein: The timing offset in the one or more timing offsets includes an offset between the WUS and a paging occasion PO.

27. The method according to any one of claims 23 to 26, further comprising: An indication is sent (1516) to the wireless device to switch from the first sleep mode to the second sleep mode.

28. The method according to any one of claims 23 to 27, further comprising: An indication of capabilities of the wireless device associated with the plurality of sleep modes is received (1518) from the wireless device.

29. The method according to claim 28, wherein The capability includes one or more of a time to wake up the primary receiver and a time to shut down the primary receiver.

30. The method according to any one of claims 23 to 29, further comprising: An indication of a wakeup probability group associated with the wireless device is sent (1520) to the wireless device.

31. A network node (300) capable of communicating with a wireless device configured to perform wake-up signal monitoring, the wireless device being capable of operating in a plurality of sleep modes, the network node comprising processing circuitry (302) operative to: determining one or more timing offsets for the wireless device, wherein: The one or more timing offsets are applied to a time offset after the wireless device detects a wake-up signal WUS; as well as The one or more timing offsets are sent to the wireless device.

32. The network node according to claim 31, wherein: The processing circuit is operative to determine the one or more timing offsets based on a sleep mode of the wireless device.

33. The network node according to any one of claims 31-32, wherein: The processing circuit is operative to determine the one or more timing offsets further based on one or more of a wakeup probability group and a discontinuous reception (DRX) cycle associated with the wireless device.

34. The network node according to any one of claims 31 to 33, wherein: The timing offset in the one or more timing offsets includes an offset between the WUS and a paging occasion PO.

35. The network node according to any of claims 31-34, the processing circuit is further operative to send an indication to the wireless device to switch from a first sleep mode to a second sleep mode.

36. The network node of any of claims 31-35, the processing circuit further operative to receive from the wireless device an indication of capabilities of the wireless device associated with the plurality of sleep modes.

37. The network node according to claim 36, wherein: The capability includes one or more of a time to wake up the primary receiver and a time to shut down the primary receiver.

38. The network node of any of claims 31-37, the processing circuit further operative to send an indication of a wakeup probability group associated with the wireless device to the wireless device.

Images