On demand pilot signal (ODPS) for paging synchronization

Abstract

This disclosure provides systems, methods, and apparatus for on-demand pilot signals (ODPS) for paging synchronization. The UE (110) may send a request (140) to the network entity (120) during the RRC idle or RRC inactive state. The request (140) may include an explicit ODPS request, clock drift information, one or more suggested parameters for ODPS, or any combination thereof. The network entity sends an ODPS configuration (150) to the UE to configure the ODPS. The ODPS configuration may indicate an ODPS pilot pattern, number of symbols, frequency, or other information to inform the UE how to receive the ODPS. A network entity transmits an ODPS (170) during a time period prior to a paging indication or wake-up signal (WUS) (180). The UE implements time and frequency synchronization using ODPS prior to receiving a paging indication or a WUS.

Description

[0001] Cross-reference to related applications

[0002] This PCT application claims priority to U.S. Provisional Patent Application No. 63 / 590,541, filed October 16, 2023, entitled “ON-DEMAND PILOT SIGNAL (ODPS) FOR PAGING SYNCHRONIZATION”, which has been assigned to the assignee of this application, the disclosure of which is incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to wireless communications, and in some aspects to power-saving techniques using on-demand pilot signals (ODPS) for paging synchronization. Background Technology

[0004] This background description is provided for the purpose of presenting the general context of this disclosure. The work of the currently attributed inventors (to the extent described in this background section) and aspects of the specification that would not have been considered prior art at the time of filing are neither expressly nor impliedly acknowledged as prior art to this disclosure.

[0005] In wireless communication systems, network entities (such as base stations) and user equipment (UEs) can implement techniques to reduce power consumption. Several techniques seek to reduce the amount of time the UE monitors the radio channel. For example, when the UE has an active radio connection with a network entity, it operates in a Radio Resource Control (RRC) connected state. In the RRC connected state, the UE maintains clock and frequency synchronization with the radio channel based on active communication between the UE and the network entity. During periods when the UE does not have an active radio connection with a network entity, it can enter a power-saving mode. For example, the UE transitions from the RRC connected state to an RRC idle state or an RRC inactive state. In the RRC idle state, the UE releases the RRC configuration. In the RRC inactive state, the UE suspends the RRC configuration, and the RRC configuration can remain dormant until the UE transitions back to the RRC connected state.

[0006] RRC idle and RRC inactive states reduce power consumption because the UE only periodically wakes up its receiver components to monitor the radio channel in response to wake-up signals (WUS) or paging indications from network entities. However, because there is limited communication between the network entity and the UE in RRC idle and RRC inactive states, the UE may experience clock drift that affects its ability to correctly receive transmissions from the network entity. Clock drift refers to loss of synchronization with the radio channel and can include time and / or frequency drift. Time drift refers to loss of time synchronization. Frequency drift refers to loss of frequency synchronization. Depending on the amount of clock drift since the previous synchronization process, the UE may fail to successfully receive WUS or paging indications. Summary of the Invention

[0007] The systems, methods, and apparatuses disclosed herein each have several innovative aspects, but no single innovative aspect is solely responsible for the desired properties disclosed herein.

[0008] One innovative aspect of the subject matter described in this disclosure can be implemented as a method performed by a user equipment (UE). The method includes requesting an on-demand pilot signal (ODPS) from a network entity when the UE is in a Radio Resource Control (RRC) idle or inactive state. The method includes receiving an ODPS configuration from the network entity. The method includes receiving the ODPS from the network entity based on the ODPS configuration during a time period prior to receiving a Wake-up Signal (WUS) or paging indication from the network entity. The method includes obtaining time and frequency synchronization with the network entity based on the ODPS prior to receiving the WUS or paging indication.

[0009] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method performed by a network entity. The method includes configuring ODPS in cooperation with at least one UE while at least one UE is in an RRC idle or inactive state. The method includes sending ODPS to at least one UE during a time period preceding a wake-up signal (WUS) or paging indication from the network entity. The method also includes the network entity sending a WUS or paging indication after sending ODPS.

[0010] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus. This apparatus includes a communication unit and a processing system configured to control the communication unit to implement any of the methods mentioned above. Other technical features will be apparent to those skilled in the art from the following drawings, description, and claims.

[0011] Details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the following description. Other features, aspects, and advantages will become apparent from the specification, drawings, and claims. Attached Figure Description

[0012] The same reference numerals and names in the various figures indicate the same elements. It should be noted that the relative dimensions in the figures may not be drawn to scale. To facilitate identification of any particular element or action being discussed, one or more of the highest significant digits in the reference numerals indicate the figure number in which that element was first introduced.

[0013] Figure 1 An example wireless communication system and an implementation of on-demand pilot signals (ODPS) are shown.

[0014] Figure 2 An example communication flowchart is shown according to some aspects of this disclosure.

[0015] Figure 3 Example signaling from the UE and from network entities is shown in accordance with some aspects of this disclosure.

[0016] Figure 4 Example signaling from a network entity to a UE is shown in accordance with some aspects of this disclosure.

[0017] Figure 5 Example ODPS pilot modes according to various aspects of this disclosure are shown.

[0018] Figure 6 An example ODPS request and configuration using a Type 1 random access procedure according to various aspects of this disclosure is shown.

[0019] Figure 7 Another example of an ODPS request and configuration using a Type 1 random access procedure according to various aspects of this disclosure is shown.

[0020] Figure 8 An example ODPS request and configuration using a Type 2 (two-step) random access procedure according to various aspects of this disclosure is shown.

[0021] Figure 9 This illustrates an example implementation where a network entity uses a common ODPS configuration to configure multiple UEs.

[0022] Figure 10 Example operation of a UE according to various aspects of this disclosure is shown.

[0023] Figure 11 Example operations of network entities according to various aspects of this disclosure are shown.

[0024] Figure 12 A block diagram of an example user equipment (UE) and an example network entity is shown. Detailed Implementation

[0025] For the purpose of describing the innovative aspects of this disclosure, the following description relates to certain implementations. However, those skilled in the art will readily recognize that the teachings herein can be applied in many different ways. Some examples in this disclosure are based on wireless communication according to 3GPP wireless standards such as the 4th generation (4G) Long Term Evolution (LTE) standard and the 5th generation (5G) New Radio (NR) standard. However, the described implementations can be implemented in any device, system, or network capable of transmitting and receiving radio frequency signals or other known signals according to any wireless communication standard, including any of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 or 802.16 wireless standards, for communication within wireless, cellular, or Internet of Things (IoT) networks such as systems utilizing 4G, 5G, WiFi, or future radio technologies.

[0026] Various aspects of this disclosure relate to clock drift. Clock drift refers to loss of synchronization with a radio channel and may include time drift and / or frequency drift. Throughout this disclosure, some references to clock drift uniformly refer to either time drift or frequency drift, or both. Several factors can affect the clock drift rate at a user equipment (UE), such as ambient temperature, processor temperature, available power, UE circuit design or component aging, and others. Depending on the amount of clock drift since a previous synchronization process, the UE may miss a paging indication or wake-up signal (WUS). Conventional mechanisms for correcting clock drift involve the UE monitoring periodic reference signals from network entities to maintain synchronization. Monitoring periodic reference signals consumes power or requires the UE to monitor the radio channel for a longer period before receiving paging channel signals. In some cases, the UE operates in Radio Resource Control (RRC) idle and RRC inactive states, during which limited communication exists between the network entity and the UE. Furthermore, in some wireless communication systems, certain reference signals (such as cell-specific reference signals (CRS)) may be omitted. For example, the 3GPP technical specifications for fifth-generation new radio (5G NR) omit the CRS (Clock Response Signal) previously broadcast by network entities of earlier generations of radio technologies. 5G NR uses the Synchronization Signal Block (SSB) instead of the CRS, which occurs less frequently and requires additional time for the UE to achieve clock synchronization.

[0027] This disclosure provides systems, methods, and apparatus for on-demand pilot signals (ODPS) for paging synchronization. ODPS may include a set of pilot signals transmitted by a network entity during a time period prior to a paging indication or WUS. A UE can receive ODPS before the WUS or paging indication to quickly achieve time and frequency synchronization. According to various aspects of this disclosure, a UE can send signaling to a network entity to request ODPS during an RRC idle or RRC inactive state. For example, the signaling may indicate a clock drift rate or indicate how many ODPS pilot symbols the UE needs to synchronize to the radio channel. In some implementations, clock drift information is calibrated (e.g., during manufacturing or testing) to determine the clock drift rate corresponding to various temperatures. The UE can measure the ambient temperature and report the clock drift rate to the network entity, allowing the network entity to select an ODPS configuration that enables the UE to synchronize to the radio channel before the WUS or paging indication.

[0028] This disclosure includes several options for a UE to explicitly or implicitly request ODPS configuration. In some implementations, the UE transmits its clock drift information, requests ODPS configuration, or may indicate a preferred ODPS pilot mode, among other examples. In some implementations, the requested ODPS pilot mode is based at least in part on the UE's time drift rate or frequency drift rate. When the UE is in an RRC idle or RRC inactive state, the UE may transmit ODPS-related control signaling. For example, the UE may use a random access procedure to occasionally (or as needed) provide updated clock drift information to network entities. In some aspects, the UE transmits ODPS-related signaling via a random access preamble transmission (MSG1) on the physical random access channel (PRACH), a random access request transmission (MSG3) on the physical uplink shared channel (PUSCH) after contention-based random access, or a random access message A (MSGA) including both a random access preamble and a random access request. In some respects, as part of or after a random access procedure with a network entity, the UE includes control signaling related to ODPS in the UE Assistance Information (UAI) message.

[0029] Network entities transmit ODPS configuration to the UE. For example, the ODPS configuration may indicate the timing of ODPS to be transmitted prior to WUS or paging indication. Alternatively or additionally, the ODPS configuration may indicate the number of symbols used for the ODPS, the number of subbands used for the ODPS, or the ODPS pilot pattern indicating the sequence or signature of the ODPS. The number of symbols used for the ODPS can be adjusted based on the time drift rate, wherein a higher time drift rate allows the ODPS to include more symbols (and therefore longer time periods), and a lower time drift rate allows the ODPS to include fewer symbols. Similarly, the number of subbands used for the ODPS can be adjusted based on the frequency drift rate. Network entities may transmit the ODPS configuration via a random access response transmission (MSG2) in response to MSG1, a contention resolution transmission (MSG4) in response to MSG3, or a random access message B (MSGB) in response to MSGA, wherein the MSGB includes both the random access response and the ODPS configuration.

[0030] In some aspects, ODPS configuration can be coordinated based on the UE's Idle Mode Discontinuous Reception (DRX) period or the network entity's Cell Discontinuous Transmission (c-DTX). Discontinuous Transmission (DTX) and Discontinuous Reception (DRX) are features of wireless communication systems used to reduce power consumption by alternating between sleep (off) and wake-up (on) radio transceiver states. As previously mentioned, UE clock drift often occurs when the radio transceiver is in sleep (off) mode. After configuring DRX in the UE, the UE can periodically activate and deactivate its radio to monitor radio frequency communications according to the DRX configuration. Typically, the paging timing for the UE is based on the UE's DRX configuration. According to various aspects of this disclosure, the UE can concurrently request DRX configuration and request ODPS, causing the network entity to transmit ODPS during the wake-up period of the DRX configuration.

[0031] In some aspects, network entities can configure a common ODPS configuration for multiple UEs. In some implementations, the network entity receives clock drift information from multiple UEs and then groups the UEs according to a similar drift rate for paging. Alternatively or additionally, the network entity can receive ODPS requests from multiple UEs and select a common ODPS configuration that satisfies multiple ODPS requests.

[0032] Specific implementations of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages. The UE can request a network entity to send ODPS during a time period just before a paging indication or WUS. This allows the UE to reduce power consumption during RRC idle or inactive states because the UE can avoid clock synchronization until the time period used for ODPS. The UE can use ODPS just before a paging indication or WUS to quickly obtain time and synchronization with the network entity. Periodic clock synchronization using SSB may take longer than clock synchronization using ODPS. Therefore, ODPS can further reduce UE power consumption. Because the ODPS configuration is based on the UE's clock drift rate, the ODPS can include a sufficient number and pattern of ODPS pilot signals, which will achieve clock synchronization while potentially reducing time or frequency resources that would be included in non-UE-specific clock synchronization signals. In some aspects, the UE proposes parameters for ODPS configuration that enable the network entity to efficiently establish an ODPS configuration for the UE or UE group.

[0033] Figure 1 An implementation of an example wireless communication system 100 and ODPS 170 is shown. The wireless communication system 100 includes a network entity 120 and an example UE 110. Although in Figure 1While shown as a smartphone, UE 110 can be implemented as any suitable computing or electronic device, such as a mobile communication device, modem, cellular phone, gaming device, navigation device, media device, laptop computer, desktop computer, tablet computer, smart appliance, vehicle-based communication system, Internet of Things (IoT) device (e.g., sensor node, controller / actuator node, combination thereof), etc. Network entity 120 supports wireless communication with one or more UEs via radio frequency (RF) signaling using one or more applicable radio access technologies (RATs) specified by one or more communication protocols or standards. Network entity 120 can employ any of a variety of RATs, such as NodeB (or Base Transceiver Station (BTS)) operation as a Universal Mobile Telecommunications System (UMTS) RAT (also known as "3G"), Enhanced NodeB ("eNB") operation as a 3GPP Long Term Evolution (LTE) RAT, 5G NodeB ("gNB") operation as a 3GPP 5G New Radio (5G NR) RAT, etc. Network entity 120 (e.g., base station, Evolved Universal Terrestrial Radio Access Network Node B (E-UTRAN Node B), Evolved Node B, eNodeB, eNB, Next Generation Node B, gNode B, gNB, ng-eNB, access point, radio head, etc.) can be implemented in macro cells, micro cells, small cells, pico cells, etc., or any combination thereof. In some aspects, the functionality of network entity 120, and therefore its hardware components, can be distributed across multiple network nodes or devices, and can be distributed in a manner used to perform the functions described herein. As an example, the functionality of network entity 120 can be distributed across radio units (RU), distributed units (DU), or central units (CU).

[0034] Network entity 120 and UE 110 communicate using radio links. A radio link may include one or more radio links (e.g., radio links) or bearers implemented using any suitable communication protocol or standard, or a combination of communication protocols or standards (such as 3GPP LTE, 5G NR, etc.). In some implementations, multiple radio links are aggregated in carrier aggregation to provide a higher data rate for UE 110. Network entity 120 may be part of a radio access network (RAN), such as Evolved Universal Terrestrial Radio Access Network, E-UTRAN, 5G NR RAN, or NR RAN. Network entity 120 may be connected to a core network (not shown) that provides access to services or other networks. Network entity 120 and UE 110 may be configured to communicate using multi-user multiple-input multiple-output (MU-MIMO), in which network entity 120 may use beamforming and orthogonal frequency division multiplexing (OFDM) to transmit multiple downlink transmissions.

[0035] Network entity 120 and UE 110 utilize an uplink (UL) transmission path for RF transmissions from UE 110 to network entity 120 (referred to as uplink transmissions) and a downlink (DL) transmission path for RF transmissions from network entity 120 to UE 110 (referred to as downlink transmissions). The UL transmission path may include a Physical Uplink Shared Channel (PUSCH), a Physical Uplink Control Channel (PUCCH), and a Physical Random Access Channel (PRACH). The PUSCH is used for transmitting user data, such as voice data, video data, or text message data, from UE 110 to network entity 120. Additionally, the PUSCH can be used to transmit control information (e.g., uplink control information (UCI)). The PUSCH can be shared by multiple UEs. The PUCCH is used to transmit control information (e.g., UCIs) from the UE to the network, such as channel quality feedback, scheduling requests, and acknowledgments. The PRACH is used for random access in the uplink direction, enabling UE 110 to access the system without prior booking. The DL transmission path may include one or more of the Physical Downlink Shared Channel (PDSCH), Physical Downlink Control Channel (PDCCH), Physical Broadcast Channel (PBCH), or paging channel. The PDSCH is used for the transmission of user data from network entity 120 to UE 110. The PDSCH can be shared by multiple UEs. Like the PUSCH, PDSCH data can be any type of information, such as voice data, video data, or text message data. The paging channel is used to notify UE 110 of the presence of an incoming service from network entity 120.

[0036] Radio Resource Control (RRC) is a component of the radio interface protocol stack used by Network Entity 120 and UE 110 for communication. Among other functions, Network Entity 120 and UE 110 use RRC messaging to establish and / or release radio connections and resources. In the RRC connected state, UE 110 has an active radio connection with Network Entity 120. When an active radio connection is no longer needed, UE 110 can transition from the RRC connected state to the RRC idle or inactive state to release or suspend the radio connection, respectively. As previously mentioned, UE 110 may experience clock drift during the RRC idle or inactive state. Unless UE 110 is synchronized with the radio channel, and depending on the amount of clock drift since the previous synchronization process, UE 110 may fail to receive paging indications or WUS 180.

[0037] According to various aspects of this disclosure, UE 110 and network entity 120 may establish (box 130) ODPS during RRC idle or inactive states. UE 110 sends a request 140 to ODPS 170. Request 140 may be an implicit request to ODPS 170, such as by sending clock drift information indicating the clock drift rate of UE 110. Alternatively or additionally, request 140 may include an explicit request to ODPS 170, such as a request indicating or by including suggested parameters for ODPS 170. For example, suggested parameters may include a suggested number of symbols for ODPS 170, a suggested number of subbands for ODPS 170, a suggested ODPS pilot pattern, or any combination of these parameters.

[0038] Network entity 120 sends and UE 110 receives ODPS configuration 150 from network entity 120. ODPS configuration may indicate the number of symbols used for ODPS 170, the number of subbands used for ODPS 170, or an ODPS pilot pattern indicating the sequence or signature of ODPS 170, among other examples. UE 110 may implement ODPS configuration 150 in its receiver so that the receiver can use ODPS 170 for clock synchronization during a time period preceding the window used for paging indication or WUS 180. As shown in box 160, network entity 120 sends ODPS 170 before paging indication or WUS 180.

[0039] Figure 2Example communication flowchart 200 is shown according to some aspects of this disclosure. Communication flowchart 200 illustrates communication between network entity 120 and UE 110. In some implementations, UE 110 sends a message 203 to network entity 120 indicating that UE 110 supports ODPS. Message 203 can be a UAI message, a UE capability message, an ODPS request message, or any type of message notifying network entity 120 that UE 110 supports ODPS for synchronization before paging indication or WUS. At some point, when UE 110 is in RRC connected state 201, network entity 120 sends an RRC release or RRC suspension command 205. As part of the transition to RRC idle state, the RRC release command releases radio resources. As part of the transition to RRC inactive state, the RRC suspension command suspends radio resources. Based on the RRC release or RRC suspension command 205, UE 110 enters RRC idle / inactive state 207.

[0040] In communication flowchart 200, ODPS is established 230 during RRC idle / inactive state 207. UE 110 sends a request 240 for ODPS configuration to network entity 120. In some implementations, request 240 is implicit. For example, request 240 can be any message that causes network entity 120 to prepare for ODPS configuration for UE 110. Request 240 may include clock drift information, such as clock drift rate, indication of loss of clock synchronization, UE movement, or other information that network entity 120 can infer to indicate a request for ODPS configuration. In some implementations, request 240 includes explicit requests, such as ODPS requests or suggested parameters for ODPS configuration. See reference... Figures 6 to 8 Furthermore, during the RRC idle / inactive state 207, as part of the random access procedure, UE 110 may include request 240 in MSG1, MSG3, or MSGA. Although Figure 2 The example shown is request 240 sent during RRC idle / inactive state 207, but in some implementations, UE 110 may send part or all of the request for ODPS during RRC connected state 201 (such as via message 203).

[0041] In response to request 240, network entity 120 sends ODPS configuration 250 to UE 110. In some implementations, ODPS configuration 250 is UE 110-specific and based on clock drift information or the parameters suggested in request 240. (See reference...) Figures 6 to 8Furthermore, as part of the random access procedure, network entity 120 may include ODPS configuration 250 in MSG2 (in response to MSG1), MSG4 (in response to MSG3), or MSGB (in response to MSGA).

[0042] After establishing ODPS 230, network entity 120 sends (260) ODPS and paging. ODPS 270 is sent during the period preceding the paging indication or WUS 280. In some implementations, ODPS 270 immediately precedes the paging indication or WUS 280. Before receiving the paging indication or WUS 280, UE 110 uses ODPS 270 to synchronize with the time and frequency of the radio channel.

[0043] Figure 3 Example signaling 340 from UE 110 and network entity 120 is shown according to some aspects of this disclosure. Example signaling 340 includes examples of implicit or explicit requests for ODPS (such as those referred to respectively). Figure 1 and Figure 2 The requests 140 and 240 are described. Example signaling 340 may include an explicit request for ODPS configuration 342, clock drift information 344, and / or suggested parameters 346 for ODPS. Examples of clock drift information 344 include clock drift rate and / or time drift rate. For example, suggested parameter 346 may indicate a suggested ODPS pilot pattern, suggested ODPS configuration elements (e.g., the number of symbols and / or the number of subbands), and / or the number of pilots. In some implementations, example signaling 340 also indicates a requested discontinuous reception (DRX) period 348 for UE 110. When preparing ODPS configuration, network entity 120 may avoid periods of UE 110 offline based on DRX period 348.

[0044] Figure 4 Example signaling 450 from network entity 120 to UE 110 is illustrated according to some aspects of this disclosure. Network entity 120 may send example signaling 450 to UE 110 to indicate ODPS configuration 451. In some implementations, network entity 120 also sends DRX configuration 458 with ODPS configuration 451. ODPS configuration 451 may indicate duration 452 (e.g., time value, number of symbols, or transmission time interval (TTI), etc.), one or more frequencies 453 (e.g., number of subbands, frequency set, or resource set, etc.), or ODPS pilot pattern 454, etc. ODPS configuration 451 may include any information that enables UE 110 to receive ODPS pilots within the time and frequency resources of one or more OFDM symbols.

[0045] Figure 5 Example ODPS pilot patterns according to various aspects of this disclosure are illustrated. Depending on the clock drift rate of a particular UE 110, network entity 120 can adjust the number of ODPS pilots. For example, network entity 120 can configure more symbols with ODPS pilots for UE 110 experiencing more time drift, and fewer symbols with ODPS pilots for UE 110 experiencing less time drift. Similarly, network entity 120 can configure more symbols with ODPS pilots for UEs experiencing more time drift, and fewer symbols with ODPS pilots for UEs experiencing less time drift. Figure 5 The shading in the diagram indicates the location of the ODPS pilots used for the three example ODPS 570A, 570B, and 570C. ODPS can include any number of ODPS pilots. Although Figure 5 The example ODPS 570A, 570B, and 570C shown illustrate ODPS pilots occupying consecutive subcarriers and consecutive symbols, but other ODPS configurations are possible. Network entity 120 can be configured with ODPS pilots located on non-consecutive subcarriers, non-consecutive symbols, or both.

[0046] An ODPS pilot pattern refers to the position of an ODPS pilot on a specific subcarrier among numerous OFDM symbols. Each ODPS pilot can have a different value, and an ODPS sequence refers to the values ​​filling the individual ODPS pilots. In some implementations, the ODPS pilot pattern and / or ODPS sequence are specified in the technical specification. Alternatively or additionally, the technical specification may indicate several options for the ODPS pilot pattern and corresponding ODPS sequence. These options may be associated with corresponding index values ​​in a lookup table. In some implementations, the UE may send suggested parameters for ODPS, where the suggested parameters are index values ​​referencing a predefined option in a lookup table. Similarly, network entity 120 may reference predefined options by including the index values ​​in the ODPS configuration. Using a lookup table with predefined options provides the potential technical advantage of reducing communication overhead. In some implementations, the ODPS pilot pattern and / or ODPS sequence can be customized or fully configured in the ODPS request message or ODPS configuration message. Using custom ODPS pilot patterns and / or ODPS sequences offers the potential technical advantage of ODPS configurations that are not limited to predefined options and can be optimized for specific UEs or groups of UEs.

[0047] Examples ODPS 570A, 570B, and 570C are provided to illustrate how to recommend or configure ODPS pilot modes based on different clock drift scenarios. Clock drift can include time drift, frequency drift, or both. When the UE 110 provides clock drift information, this information can indicate the clock drift rate, such as the drift rate in terms of time or frequency synchronization. Higher drift rates (in terms of time or frequency, or both) may require a larger number of ODPS pilots compared to lower drift rates.

[0048] UEs experiencing higher time drift rates can benefit from ODPS modes that include more symbols (e.g., more synchronized times) compared to UEs experiencing lower time drift rates. The first example ODPS 570A includes four ODPS pilots 572A located on two subcarriers in the first and second OFDM symbols. The second example ODPS 570B includes eight ODPS pilots 572B located on two subcarriers in each of the four OFDM symbols. The first example ODPS 570A may be suitable for UEs with lower time drift rates, while the second example ODPS 570B may be more suitable for UEs with higher time drift rates.

[0049] UEs experiencing higher frequency drift rates can benefit from ODPS modes that include more subcarriers (e.g., more frequencies for frequency synchronization) compared to UEs experiencing lower frequency drift rates. The third example ODPS 570C includes eight ODPS pilots 572C located on four subcarriers in the first and second OFDM symbols. The first example ODPS 570A may be suitable for UEs with lower frequency drift rates, while the third example ODPS 570C may be more suitable for UEs with higher frequency drift rates.

[0050] Figure 5 The examples provided are for educational purposes to explain how UE 110 or network entity 120 can take time drift and frequency drift into account when establishing ODPS. UE 110 can use clock drift information or the current condition of UE 110 (e.g., component temperature, power, and / or age) to suggest an ODPS pilot pattern. Alternatively or additionally, UE 110 can provide clock drift information to the network entity, and network entity 120 can configure the ODPS pilot pattern to take into account the UE's time drift rate and / or frequency drift rate. Figure 5 Non-limiting examples are shown of varying the number of ODPS pilots, subcarriers, and symbols based on different clock drift rates and drift types.

[0051] Figure 6An example ODPS request and configuration using a Type 1 random access procedure according to various aspects of this disclosure is shown. Timing diagram 600 illustrates network entity communication 620 of a network entity (such as network entity 120 described herein). Timing diagram 600 also illustrates UE communication 610 of a UE (such as UE 110 described herein). The example UE communication 610 and network entity communication 620 may occur during an RRC idle or inactive state 607.

[0052] The random access procedure can be referred to as a Random Access Channel (RACH) procedure. A Type 1 random access procedure can also be referred to as a 4-step RACH. A Type 1 random access procedure involves a protocol of up to four messages (referred to as MSG1, MSG2, MSG3, and MSG4). To initiate a Type 1 random access procedure, the UE sends a random access preamble in the first message (MSG1 642) via PRACH. The network entity responds to MSG1 642 by sending a second message (MSG2 652) via PDSCH. MSG2 652 is also referred to as a Random Access Response (RAR) transport. In some cases, MSG2 652 indicates the scheduled resources (in the PUSCH) available to the UE for the transport of the third message (MSG3). Where applicable, the UE sends MSG3 644 via the PUSCH resources authorized by the network entity. In response to MSG3 644, the network entity sends a fourth message (MSG4 654). MSG4 654 is also referred to as a contention resolution transport (MSG4). Note that MSG3 644 and MSG4 654 may not be required. For example, a UE may include small data transmissions with random access preambles in MSG1 642, and a network entity may include responses in MSG2 652 without granting authorization for uplink resources for MSG3 644.

[0053] According to various aspects of this disclosure (shown at box 640), the UE may include an ODPS request following the random access preamble in MSG1 642. The ODPS request may include an explicit or implicit request for ODPS configuration. In some implementations, MSG1 642 may include clock drift information or suggested parameters for ODPS, among other examples. A network entity may include ODPS configuration 650 in MSG2 652. Figure 6 The potential technical advantage of the protocol shown is that MSG3 644 and MSG4 654 can be omitted, thereby reducing power consumption and communication overhead.

[0054] Reference Figure 6In an alternative described, the UE can send an ODPS request in MSG3 644. The network entity can send an ODPS configuration in MSG4 654. A potential technical advantage of using MSG3 644 and MSG4 654 for ODPS requests and ODPS configurations, respectively, is that those message types can include a greater amount of data compared to MSG1 642 and MSG2 652. Therefore, the ODPS request can include more information to enable the network entity to prepare the ODPS configuration, and the network entity can utilize the ODPS configuration to provide further information.

[0055] After ODPS configuration 650 has been sent to the UE (via MSG2 652 or MSG4 654), the UE can implement ODPS configuration 650 in its receiver. At a later time 660, the network entity sends ODPS 670 and a paging or WUS (via PDCCH 680). Before processing PDCCH 680, the UE uses ODPS 670 to achieve time and frequency synchronization.

[0056] Figure 7 Another example of an ODPS request and configuration using a Type 1 random access procedure according to various aspects of this disclosure is shown. Figure 7 Features and References Figure 6 The descriptions are the same. In Figure 7 In this configuration, the UE sends an ODPS request via MSG3 644, and the network entity sends an ODPS configuration 650 via MSG4 654. In some implementations, the UE sends the ODPS request in a UE Assistance Information (UAI) message 740. UAI messages are typically sent during RRC connected states. However, according to various aspects of this disclosure, during RRC idle or inactive states, the UE may include the UAI message in a RACH message. The UAI message may be extended to include ODPS requests (such as clock drift information, explicit ODPS requests, and / or suggested parameters, among other examples). Figure 7 In some other implementations not shown, the UE may send an ODPS request (not shown) in the UAI during the RRC connection state.

[0057] Figure 8An example ODPS request and configuration using a Type 2 (two-step) random access procedure according to various aspects of this disclosure is shown. The Type 2 random access procedure can also be referred to as 2-step RACH. 2-step RACH is a newer protocol for random access compared to 4-step RACH. In 2-step RACH, the UE may send a random access preamble in a first message (called MSGA 840), followed by a PUSCH. The network entity responds to MSGA 840 by sending a second message (MSGB 850) via PDSCH. One way to describe 2-step RACH is that MSGA is a combination of MSG1 and MSG3 in the first transmission, while MSGB is a combination of MSG2 and MSG4 in the second transmission.

[0058] According to various aspects of this disclosure, the UE may include an ODPS request (box 640) in the MSGA 840. Network entities may send the ODPS configuration 650 via the MSGB 850. Some potential technical advantages of 2-step RACH are that it can reduce the number of signaling steps, reduce communication overhead, reduce protocol latency, and reduce power consumption.

[0059] Figure 9 An example implementation is shown in which network entity 120 uses a common ODPS configuration to configure multiple UEs. The example wireless communication system 900 includes network entity 120 and several example UEs (UEs 110, 912, 914, and 916). The wireless communication system 900 is similar to the reference... Figure 1 The wireless communication system 100 is described. Figure 9 Two types of ODPS configurations that can be used in wireless communication systems are shown.

[0060] In some aspects, network entity 120 can provide a common ODPS configuration 951 to multiple UEs (such as UEs 912, 914, and 916). In some implementations, network entity 120 can receive clock drift information from multiple UEs. Network entity 120 can group several UEs based on UEs with similar clock drift rates for use in common ODPS configuration 951 and paging. Figure 9 In the example, UEs 912, 914, and 916 have similar clock drift rates and can use the same ODPS (shown as the first ODPS 971) for time and frequency synchronization before paging or WUS windows. Alternatively or additionally, the network entity can receive ODPS requests from multiple UEs and select a common ODPS configuration that satisfies multiple ODPS requests. A common ODPS configuration can provide the potential technical advantages of reducing communication overhead and efficiently grouping UEs with similar synchronization and paging needs.

[0061] In some respects, network entity 120 may provide a unique ODPS configuration 952 for a specific UE (such as UE 110). The network may send ODPS specific to UE 110 (shown as a second ODPS 972). UE-specific ODPS configurations may provide the potential technical advantage of improving synchronization opportunities for a specific UE that has a clock drift rate different from that of other UEs in the coverage area of ​​network entity 120.

[0062] Figure 10 Example operation 1000 of a UE (such as UE 110 described herein) according to various aspects of this disclosure is illustrated. At block 1040, when the UE (110) is in an RRC idle or inactive state, the UE (110) sends a request for ODPS (140) to the network entity (120). At block 1050, the UE receives ODPS configuration (150) from the network entity. At block 1070, the UE receives ODPS (170) from the network entity (120) based on the ODPS configuration during a time period prior to a WUS or paging indication (180) from the network entity. At block 1080, the UE obtains time and frequency synchronization with the network entity (120) based on ODPS (170) before receiving the WUS or paging indication (180).

[0063] Figure 11 Example operation 1100 of a network entity (such as network entity 120 described herein) according to various aspects of this disclosure is illustrated. At block 1140, while at least one UE (110) is in an RRC idle or inactive state, the network entity receives a request for ODPS (140) from at least one UE (110). At block 1150, the network entity sends an ODPS configuration (150) to at least one UE (110). At block 1170, the network entity sends an ODPS (170) to at least one UE (110) during a time period preceding a WUS or paging indication (180) from network entity (120). At block 1180, the network entity sends a WUS or paging indication (180) after the ODPS (170).

[0064] Figure 12 Block diagrams of example UE 1210 and example network entity 1220 are shown. Note that the depicted hardware configuration represents the processing and communication components of network entity 1220 (such as network entity 120 described herein) and UE 1210 (such as UE 110 described herein). Certain components commonly found frequently implemented in such electronic devices, such as displays, peripherals, power supplies, etc., may be omitted from the depicted hardware configuration.

[0065] UE 1210 includes an antenna 1211, a radio frequency front-end (RF front-end) 1212, and radio frequency transceivers (e.g., LTE transceiver 1214 and 5G NR transceiver 1213) for communicating with network entity 1220. The RF front-end 1212 includes one or more modems, one or more analog-to-digital converters (ADCs), one or more digital-to-analog converters (DACs), signal processors, etc., configured for the corresponding RAT adopted (e.g., 3GPP 5th Generation New Radio (5G NR)). Figure 12 In the example shown, the RF front-end 1212 of UE 1210 can couple or connect a 5G NR transceiver 1213 to the antenna 1211 to facilitate various types of wireless communication. The RF front-end 1212 actually operates as a physical (PHY) transceiver interface to conduct and process signaling between one or more processors 1215 and the antenna 1211 to facilitate various types of wireless communication.

[0066] The antenna 1211 of UE 1210 includes an array of multiple antennas that can be tuned to one or more frequency bands associated with a corresponding RAT. Antenna 1211 and RF front-end 1212 are tuned to and / or tunable to one or more frequency bands defined by the 3GPP 5G NR communication standard and implemented by the 5G NR transceiver 1213. Additionally, antenna 1211, RF front-end 1212, and / or 5G NR transceiver 1213 can be configured to support beamforming for transmitting and receiving communications with network entity 1220. By way of example, and not limitation, antenna 1211 and RF front-end 1212 can be implemented for operation in sub-gigahertz bands, sub-6 GHz bands, and / or above 6 GHz bands defined by the 3GPP LTE and 5G NR communication standards.

[0067] UE 1210 also includes a processor 1215 and a computer-readable storage medium (CRM) 1216. The processor 1215 may include, for example, one or more central processing units, graphics processing units (GPUs), or other application-specific integrated circuits (ASICs). For illustration, the processor 1215 may include an application processor (AP) used by UE 1210 to execute an operating system and various user-level software applications, and one or more processors utilized by a modem or baseband processor of the RF front end 1212. CRM 1216 may include any suitable memory or storage device, such as random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), flash memory, solid-state drive (SSD), or other high-capacity storage devices, which may be used to store one or more executable software instruction sets and associated data that manipulate one or more processors 1215 and other components of UE 1210 to perform the various functions described herein and attributed to UE 1210. The executable software instruction set includes, for example, an operating system (OS) and various drivers (not shown) and various software applications (not shown), which can be executed by the processor 1215 to enable user plane communication, control plane signaling and user interaction with the UE 1210.

[0068] Switching to the hardware of network entity 1220, note that although Figure 12 The implementation of network entity 1220 is shown as a single network node (e.g., a 5G NR Node B or "gNB"), but the functionality of network entity 1220 and therefore its hardware components can be distributed across multiple network nodes or devices, and can be distributed in a manner used to perform the functions described herein. As an example, the functionality of network entity 1220 can be distributed across radio units (RUs), distributed units (DUs), or central units (CUs).

[0069] Network entity 1220 includes an antenna 1221, a radio frequency front-end (RF front-end) 1222, and one or more 5G NR transceivers 1223 for communicating with UE 1210. The RF front-end 1222 of network entity 1220 can couple or connect the 5G NR transceivers 1223 to the antenna 1221 to facilitate various types of wireless communication. Similar to RF front-end 1212, RF front-end 1222 includes one or more modems, one or more ADCs, one or more DACs, etc. RF front-end 1222 receives one or more RF signals (e.g., RF signals from UE 1210) and preprocesses one or more RF signals to generate data from the RF signals, which is provided as input to processes and / or applications performed on network entity 1220. Such preprocessing may include, for example, power amplification, conversion of band signaling to baseband signaling, initial analog-to-digital conversion, etc.

[0070] The antenna 1221 of network entity 1220 can be configured individually and / or configured as one or more arrays of multiple antennas. Antenna 1221 and RF front-end 1222 can be tuned to and / or tunable to one or more frequency bands defined by the 3GPP 5G NR communication standard and implemented by 5G NR transceiver 1223. Additionally, antenna 1221, RF front-end 1222, and 5G NR transceiver 1223 can be configured to support beamforming, such as massive MIMO, for transmitting and receiving communications with UE 1210.

[0071] Network entity 1220 also includes processor 1225 and computer-readable storage medium (CRM) 1226. Processor 1225 may include, for example, one or more central processing units, graphics processing units (GPUs), or other application-specific integrated circuits (ASICs). For illustration, processor 1225 may include an application processor (AP) used by network entity 1220 to execute an operating system and various user-level software applications, and one or more processors used by modem or baseband processor of RF front end 1222 to implement communication with UE 1210.

[0072] Figures 1 to 12 The operations described herein are examples intended to aid in understanding exemplary implementations and should not be used to limit potential implementations or the scope of the claims. Some implementations may perform additional operations, fewer operations, operations in parallel or in a different order, or some operations in different ways.

[0073] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications and variations may be made based on the foregoing disclosure, or may be derived from practice in the aspects. Although aspects of this disclosure have been described with respect to various examples, any combination of aspects from any example is also within the scope of this disclosure. Alternatively, or in addition to other examples described herein, examples include any combination of the following implementation options (identified as clauses for reference).

[0074] Terms and Conditions

[0075] Clause 1. A method performed by a user equipment (UE) (110) comprising: sending a request (140) for an on-demand pilot signal (ODPS) to a network entity (120) when the UE (110) is in a radio resource control (RRC) idle or inactive state; receiving an ODPS configuration (150) from the network entity; receiving the ODPS (170) from the network entity (120) based on the ODPS configuration during a time period prior to a wake-up signal (WUS) or paging indication (180) from the network entity; and obtaining time and frequency synchronization with the network entity (120) based on the ODPS (170) prior to receiving the WUS or the paging indication (180).

[0076] Clause 2. The method as described in Clause 1, wherein sending the request includes sending at least one of the following: a request for the ODPS configuration, clock drift information, or suggested parameters for the ODPS configuration.

[0077] Clause 3. The method as described in Clause 2, wherein the proposed parameters for the ODPS configuration include at least one of the following: the number of symbols for the ODPS, the number of subbands for the ODPS, or an ODPS pilot pattern indicating the sequence or signature of the ODPS.

[0078] Clause 4. The method as described in Clause 2 or 3, wherein the proposed parameters are based at least in part on the clock drift rate of the UE.

[0079] Clause 5. The method of any one of Clauses 1 to 4 further comprises: sending a communication to the network entity indicating the discontinuous reception (DRX) period of the UE; and wherein receiving the ODPS from the network entity is also based on the DRX period.

[0080] Clause 6. The method of any one of Clauses 1 to 5, wherein sending the request comprises sending the request via at least one of: random access preamble transmission (MSG1) on the physical random access channel (PRACH), random access request transmission (MSG3) on the physical uplink shared channel (PUSCH) after contention-based random access, or random access message A (MSGA) including both the random access preamble and the random access request.

[0081] Clause 7. The method as described in Clause 6, wherein receiving the ODPS configuration from the network entity comprises receiving the ODPS configuration via at least one of: a random access response transport (MSG2) in response to the MSG1, a contention resolution transport (MSG4) in response to the MSG3, or a random access message B (MSGB) in response to the MSGA.

[0082] Clause 8. The method of any one of Clauses 1 to 7, wherein sending the sending request includes sending a UE Assistance Information (UAI) message.

[0083] Clause 9. The method as described in Clause 8, wherein sending the UAI message includes sending the UAI via a random access channel as part of or after a random access procedure.

[0084] Clause 10. The method of any one of Clauses 1 to 9 further includes, after receiving the ODPS configuration: remaining in power-saving mode until the ODPS is received.

[0085] Clause 11. A method performed by a network entity (120) comprising: receiving a request for an on-demand pilot signal (ODPS) from at least one user equipment (UE) (110) while at least one user equipment (UE) (110) is in a radio resource control (RRC) idle or inactive state (140); sending an ODPS configuration to at least one UE (110) (150); sending the ODPS to at least one UE (110) during a time period preceding a wake-up signal (WUS) or paging indication (180) from the network entity (120) (170); and sending the WUS or the paging indication (180) after the ODPS (170).

[0086] Clause 12. The method as described in Clause 11, wherein receiving the request comprises receiving at least one of the following: a request for the ODPS configuration, clock drift information, or suggested parameters for the ODPS configuration, wherein the suggested parameters for the ODPS configuration include at least one of the following: a suggested number of symbols for the ODPS, a suggested number of subbands for the ODPS, or a suggested ODPS pilot pattern.

[0087] Clause 13. The method as described in Clause 11 or 12, wherein sending the ODPS configuration includes indicating at least one of the following: the number of symbols for the ODPS, the number of subbands for the ODPS, or an ODPS pilot pattern indicating the sequence or signature of the ODPS.

[0088] Clause 14. The method of any one of Clauses 11 to 13 further comprises: receiving from the at least one UE a communication indicating a discontinuous reception (DRX) period of the at least one UE; and determining the ODPS configuration based at least in part on the DRX period of the at least one UE.

[0089] Clause 15. The method of any one of Clauses 11 to 14, wherein transmitting the ODPS configuration comprises transmitting the ODPS configuration via at least one of: a random access response transmission (MSG2) in response to a random access preamble transmission (MSG1) from the at least one UE, a contention resolution transmission (MSG4) in response to a random access request transmission (MSG3) from the at least one UE, or a random access message B (MSGB) in response to a random access message A (MSGA) from the at least one UE.

[0090] Clause 16. The method of any one of Clauses 11 to 15 further comprises: receiving ODPS requests from a plurality of UEs; and determining a common ODPS configuration to satisfy ODPS requests from a plurality of UEs, wherein sending the ODPS configuration comprises transmitting the common ODPS configuration to the plurality of UEs.

[0091] Clause 17. The method as described in Clause 16, wherein determining the public ODPS configuration comprises at least one of: selecting a first ODPS configuration for a first UE and using the first ODPS configuration for one or more other UEs having clock drift information compatible with the first UE or an equivalent requested ODPS pilot mode, or selecting the plurality of UEs based on network criteria and determining the public ODPS configuration that satisfies the ODPS request from the plurality of UEs.

[0092] Clause 18. An apparatus comprising: a communication unit; and a processing system configured to control the communication unit to implement any one of the methods described in any one of Clauses 1 to 17.

[0093] Another innovative aspect of the subject matter described in this disclosure can be implemented as a computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform any of the aforementioned functionalities.

[0094] Another innovative aspect of the subject matter described in this disclosure can be implemented as a system having components for achieving any of the aforementioned functionalities.

[0095] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus having one or more processors configured to perform one or more operations from any of the methods described above.

[0096] As used herein, the terms “component” and “module” are intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software. As used herein, a processor is implemented in hardware, firmware, or a combination of hardware and software. As used herein, the phrase “based on” is intended to be broadly interpreted as meaning “at least partially based on”.

[0097] As used herein, the phrase “at least one of” or “one or more of” in the list of items refers to any combination of those items, including a single member. For example, “at least one of the following: a, b, or c” is intended to cover the following possibilities: only a, only b, only c, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a, b, and c.

[0098] In this disclosure, the expression “X / Y” can include the meaning of any of the following: “X or Y”, or “X and Y”, or “X and / or Y”. The expression “(A) B” or “B (A)” can include the concept of “B only”. The expression “(A) B” or “B (A)” can include the concept of “A+B” or “B+A”.

[0099] In this disclosure, the term "can" indicates capability, or alternatively, a possible implementation option. The term "may" indicates permission, or a possible implementation option.

[0100] This article describes several aspects in conjunction with thresholds. As used in this article, meeting a threshold can mean that the value is greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, or not equal to the threshold.

[0101] The various illustrative components, logic, logic blocks, modules, circuits, operations, and algorithmic processes described in conjunction with the implementations disclosed herein can be implemented as electronic hardware, firmware, software, or a combination of hardware, firmware, or software, including the structures disclosed in this specification and their structural equivalents. The interchangeability of hardware, firmware, and software has been generally described in terms of functionality and illustrated in the various illustrative components, blocks, modules, circuits, and processes described above. Whether such functionality is implemented in hardware, firmware, or software depends on the specific application and design constraints imposed on the system as a whole.

[0102] Hardware and data processing apparatuses for implementing the various illustrative components, logic, logic blocks, modules, and circuits described in conjunction with the aspects disclosed herein can be implemented or executed using general-purpose single-chip or multi-chip processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices (PLDs), discrete gate or transistor logic, discrete hardware components, or any combination thereof. A general-purpose processor can be a microprocessor, or any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. In some implementations, specific processes, operations, and methods can be performed by a circuit system specific to a given function.

[0103] As described above, some aspects of the subject matter described herein can be implemented as software. For example, the various functions of the components disclosed herein, or the various blocks or steps of the methods, operations, processes, or algorithms disclosed herein, can be implemented as one or more modules of one or more computer programs. Such computer programs may include non-transitory processor-executable instructions or computer-executable instructions encoded on one or more tangible processor-readable or computer-readable storage media for execution by, or control of, the operation of, a data processing apparatus including the devices described herein. By way of example, and not limitation, such storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store program code in the form of instructions or data structures. Combinations of the above should also be included within the scope of storage media.

[0104] As used herein, the terms “user device,” “user equipment” (e.g., UE 110), “wireless communication device,” “mobile communication device,” “communication device,” or “mobile device” mean any or all of the following: cellular phone, smartphone, portable computing device, personal or mobile multimedia player, laptop computer, tablet computer, smartbook, Internet of Things (IoT) device, handheld computer, wireless email receiver, cellular phone with multimedia Internet support, wireless game controller, display subsystem, driver assistance system, vehicle controller, vehicle system controller, vehicle communication system, infotainment system, vehicle telematics system or subsystem, vehicle display system or subsystem, vehicle data controller, point-of-sale (POS) terminal, health monitoring device, drone, camera, media streaming dongle or other personal media device, wearable device (such as smartwatch), wireless hotspot, femtocell, broadband router, or other type of router, as well as similar electronic devices including programmable processors and memories and circuitry systems configured to perform the operations described herein. Furthermore, in some cases, the user device may be embedded in an electronic system (such as the main unit of a vehicle or an advanced driver assistance system (ADAS)). Furthermore, mobile internet devices (MIDs). Depending on the type, a user device may include one or more general-purpose processors, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.

[0105] Various modifications to the implementations described in this disclosure will be apparent to those skilled in the art, and the general principles defined herein can be applied to other implementations without departing from the scope of this disclosure. Therefore, the claims are not intended to be limited to the implementations shown herein, but are given the widest scope consistent with this disclosure, the principles disclosed herein, and the novel features.

[0106] Furthermore, the various features described in this specification in the context of individual implementations may also be implemented in combination in a single implementation. Conversely, the various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations. Thus, although features may be described above as functioning in a particular combination and even initially claimed in this way, in some cases one or more features from the claimed combination may be removed from that combination, and the claimed combination may involve sub-combinations or variations of sub-combinations.

[0107] Similarly, although operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring such operations to be performed in the specific order shown or in sequential order, or requiring all shown operations to achieve the desired result. Furthermore, the drawings may schematically depict one or more example processes in the form of a flowchart or table. However, other operations not depicted may be incorporated into the schematically shown example processes. For example, one or more additional operations may be performed before, after, simultaneously with, or between any of the shown operations. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of the various system components in the implementations described above should not be construed as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. Additionally, other implementations are within the scope of the appended claims. In some cases, the actions set forth in the claims may be performed in a different order and still achieve the desired result.

[0108] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications and variations can be made based on the foregoing disclosure, or from practice in the aspects. Although aspects of this disclosure have been described with reference to various examples, any combination of aspects from any example is also within the scope of this disclosure. The examples in this disclosure are provided for illustrative purposes only.

Claims

1. A method performed by a user equipment (UE) (110), comprising: When the UE (110) is in a Radio Resource Control (RRC) idle or inactive state, it sends a request (140) for the On-Demand Pilot Signal (ODPS) to the network entity (120); In response to the request (140), ODPS configuration is received from the network entity (150); During the time period preceding the wake-up signal WUS or paging indication (180) from the network entity, the ODPS (170) is received from the network entity (120) based on the ODPS configuration; and Before receiving the WUS or the paging instruction (180), time and frequency synchronization with the network entity (120) is obtained based on the ODPS (170).

2. The method as described in claim 1, wherein, Sending the request includes sending at least one of the following: Request for the ODPS configuration, Clock drift information, or Recommended parameters for the ODPS configuration.

3. The method as described in claim 2, wherein, The proposed parameters for the ODPS configuration include at least one of the following: The number of symbols used for the ODPS The number of subbands used for the ODPS, or The ODPS pilot pattern indicating the sequence or signature of the ODPS.

4. The method as described in claim 2 or 3, wherein, The proposed parameters are based, at least in part, on the clock drift rate of the UE.

5. The method according to any one of claims 1 to 4, further comprising: Send a communication to the network entity indicating the UE's discontinuous reception of DRX periods; and The ODPS received from the network entity is also based on the DRX period.

6. The method according to any one of claims 1 to 5, wherein, Sending the request includes sending the request via at least one of the following: Random access preamble transmission MSG1 on the physical random access channel PRACH Random access request transmission MSG3 on the physical uplink shared channel PUSCH following contention-based random access, or A random access message A MSGA includes both the random access preamble and the random access request.

7. The method of claim 6, wherein, Receiving the ODPS configuration from the network entity includes receiving the ODPS configuration via at least one of the following: In response to the random access response transmission MSG2 of MSG1, In response to the contention resolution of MSG3, MSG4 is transmitted, or In response to the random access message B MSGB of the MSGA.

8. The method according to any one of claims 1 to 7, wherein, Sending the request includes sending a UE Assistance Information (UAI) message.

9. The method of claim 8, wherein, Sending the UAI message may be done as part of a random access procedure or after a random access procedure via a random access channel.

10. The method of any one of claims 1 to 9, further comprising, after receiving the ODPS configuration: Stay in power saving mode until the ODPS is received.

11. A method performed by a network entity (120), comprising: When at least one user equipment (UE) (110) is in a radio resource control (RRC) idle or inactive state, a request (140) for an on-demand pilot signal (ODPS) is received from the at least one UE (110); Send ODPS configuration (150) to the at least one UE (110); During the time period preceding the wake-up signal WUS or paging indication (180) from the network entity (120), the ODPS (170) is transmitted to the at least one UE (110); and The WUS or the paging instruction (180) is sent after the ODPS (170).

12. The method of claim 11, wherein, Receiving the request includes receiving at least one of the following: Request for the ODPS configuration, Clock drift information, or The proposed parameters for the ODPS configuration include at least one of the following: a proposed number of symbols for the ODPS, a proposed number of subbands for the ODPS, or a proposed ODPS pilot pattern.

13. The method of claim 11 or 12, wherein, Sending the ODPS configuration includes indicating at least one of the following: The number of symbols used for the ODPS The number of subbands used for the ODPS, or The ODPS pilot pattern indicating the sequence or signature of the ODPS.

14. The method of any one of claims 11 to 13, further comprising: Receive communication from the at least one UE indicating the discontinuous reception DRX cycle of the at least one UE; as well as The ODPS configuration is determined at least in part based on the DRX cycle of the at least one UE.

15. The method according to any one of claims 11 to 14, wherein, Sending the ODPS configuration includes transmitting the ODPS configuration via at least one of the following: In response to the random access preamble transmission MSG1 from the at least one UE, a random access response transmission MSG2 is transmitted. In response to the random access request transmission MSG3 from the at least one UE, a contention-resolving transmission MSG4, or Random access message B MSGB in response to random access message A MSGA from the at least one UE.

16. The method of any one of claims 11 to 15, further comprising: Receive ODPS requests from numerous UEs; as well as Determine a common ODPS configuration to satisfy ODPS requests from multiple UEs among the multitude of UEs, wherein sending the ODPS configuration includes transmitting the common ODPS configuration to the multiple UEs.

17. The method of claim 16, wherein, The public ODPS configuration is determined to include at least one of the following: Select a first ODPS configuration for the first UE, and use the first ODPS configuration for one or more other UEs having clock drift information compatible with the first UE or an equivalent requested ODPS pilot mode, or The plurality of UEs are selected based on network criteria, and the common ODPS configuration that satisfies the ODPS requests from the plurality of UEs is determined.

18. An apparatus comprising: Communication unit; and A processing system configured to control the communication unit to implement any one of the methods claimed in any one of claims 1 to 17.

Images