WO2024035827A1 - Method of conducting power saving for xr applications with a non-integer traffic periodicity - Google Patents

Abstract

A power saving method implemented in a user equipment (UE) includes monitoring signaling according to a periodic schedule in which a monitoring cycle having a cycle length includes an on-duration period during which the UE monitors signaling between the UE and a radio access network (RAN), and an off-duration period; communicating, with the RAN and during the monitoring, traffic with a traffic periodicity; and adjusting alignment between the monitoring and the communicating using a timer with a timer duration based on (i) the cycle length, (ii) the traffic periodicity, and (iii) the on-duration period.

Description

METHOD OF CONDUCTING POWER SAVING FOR XR APPLICATIONS WITH A NON-INTEGER TRAFFIC PERIODICITY

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63/396,598, entitled “Method of Conducting Power Saving for xR Applications with a Non-integer Traffic Periodicity,” filed on August 9, 2023. The entire contents of the provisional application are hereby expressly incorporated herein by reference.

FIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communications and, more particularly, to supporting power saving such as discontinuous reception (DRX) when low-latency data such as extended Reality (XR) arrives with a non-integer periodicity.

BACKGROUND

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] Discontinuous reception (DRX) is a feature loT or MTC devices use to reduce power consumption. With a DRX mechanism, a user device can go into a sleep mode for a certain period (e.g., an off-duration period) and then wake up after the off-duration period to monitor the DL signal from the base station (e.g., an on-duration period). The DRX cycle defines the time interval between two consecutive time periods when the UE is awake

[0005] One of the main limitations of the existing connected-mode DRX (C-DRX) design is that the C-DRX cycles do not align with certain type of traffic, such as augmented reality (AR)/virtual reality (VR), or “extended reality,” frame rates. These cycles are integer values, e.g., long DRX cycles have the duration of 10, 20, 32, 40, 60, 64, etc. ms, and short DRX cycles have the duration of 2, 3, 4, 5, 6, 7, 8, 10, 14, 16, etc. ms. However, the 3rd Generation Partnership Project (3 GPP) participants recently agreed that packet arrival rates to be evaluated for XR are 30, 60, 90, or 120 frames per second (fps), and thus the corresponding traffic periodicities of XR can be non-integer values such as 33.33, 16.67, 11.11, are 8.33 ms. There is a mismatch between the XR traffic arrival periodicities and the C-DRX cycles for both long and short cases.

[0006] This misalignment causes a time drift between the arrival of the XR video frames and the start of the C-DRX cycles. Accumulation of the time drift in turn causes the expected arrival time of the XR traffic to fall outside the C-DRX On-duration, or the period of time when a receiver is awake and capable of receiving data. The misalignment causes a larger latency for data scheduling and further reduces the XR/CG system capacity.

[0007] The existing approaches to addressing the misalignment have certain disadvantages due to additional signaling, frequent changing of DRX cycles, etc. Moreover, these approaches in general do not provide compatibility with devices that support DRX with integer-only periodicity.

SUMMARY

[0008] An example embodiment of the techniques of this disclosure is a power saving method is implemented in a user equipment (UE). The method comprises monitoring signaling according to a periodic schedule in which a monitoring cycle having a cycle length includes an on-duration period during which the UE monitors signaling between the UE and a radio access network (RAN), and an off-duration period; communicating, with the RAN and during the monitoring, traffic with a traffic periodicity; and adjusting alignment between the monitoring and the communicating using a timer with a timer duration based on (i) the cycle length, (ii) the traffic periodicity, and (iii) the on-duration period.

[0009] Another example embodiment of these techniques is a configuration method implemented in a base station operating in a radio access network (RAN), the method comprising: transmitting, to a user equipment (UE), a periodic schedule including a monitoring cycle having a cycle length with an on-duration period during which the UE monitors signaling between the UE and the radio access network (RAN), and an off-duration period; communicating, with the UE and while the UE monitors the signaling according to the periodic schedule, traffic with a traffic periodicity; and configuring the UE to adjust alignment between the monitoring and the communicating using a timer with a timer duration based on (i) the cycle length, (ii) the traffic periodicity, and (iii) the on-duration period.

[0010] Another example embodiment of these techniques is an apparatus comprising a transceiver and processing configured to implement one of the methods above.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Fig. 1 is a block diagram of an example wireless communication system in which devices can align monitoring and communication periodicity to implement power saving;

[0012] Fig. 2A illustrates an example DRX cycle;

[0013] Fig. 2B illustrates an example DRX cycle with a DRX offset;

[0014] Fig. 2C illustrates misalignment due to non-integer traffic periodicity;

[0015] Fig. 2D illustrates example jitter distribution for video traffic;

[0016] Fig. 3 is a messaging diagram of an example scenario in which a network modifies an initial configuration of DRX and notifies the UE accordingly;

[0017] Fig. 4A is a flow diagram of an example network-side method for specifying a DRX cycle in units other than subframes (e.g., OFDM symbols);

[0018] Fig. 4B a flow diagram of an example network-side method for providing a UE with a DRX configuration along with an indication of non-integer periodicity;

[0019] Fig. 5 a flow diagram of an example network-side method for providing a UE with an indication that the UE should determine the start time of a new DRX cycle based on the reception time of the indication;

[0020] Fig. 6 is a flow diagram of an example network-side method for specifying a timer according to which the UE applies adjustment to the DRX cycle.

[0021] Fig. 7 is a flow diagram of an example UE-side method for receiving an indication of a DRX cycle in units other than subframes (e.g., OFDM symbols);

[0022] Fig. 8 a flow diagram of an example UE-side method for determining the start time of a new DRX cycle based on a time when the UE receives an appropriate indication from the base station; [0023] Fig. 9 is a flow diagram of an example UE-side method for using a timer, which can be network-specified, for applying adjustment to the DRX cycle;

[0024] Fig. 10 a flow diagram of an example UE-side method for receiving a DRX configuration along with an indication of non-integer periodicity, and calculating a timer for adjusting the DRX cycle;

[0025] Fig. 11 illustrates adjustment of DRX according to the methods of Figs. 4A and 7, for example;

[0026] Fig. 12 illustrates adjustment of DRX according to the methods of Figs. 6 and 9, for example; and

[0027] Fig. 13 illustrates an example technique for managing jitter, which the devices of Fig. 1 can implement.

DESCRIPTION OF THE DRAWINGS

[0028] A user equipment (UE) and/or a network element such a base station implement one or more of the techniques discussed below to align DRX cycles with periodic traffic, to allow the UE to save power. These techniques address the misalignment problems discussed above while reducing signaling between the UE and the network, minimizing the shifting of C-DRX cycles forward or backward with respect to traffic arrival, which can compromise the latency or the power consumption, avoiding frequent changes of the offset of a DRX cycle within a frame, and not requiring synchronization between multiple C-DRX configuration.

[0029] As discussed below, a network in some implementations transmits a DRX offset and an indication of a time to a UE, and the UE uses the offset and the indication to determine the start of the next DRX cycle. The indication of time is in units other than the subframe, e.g., OFDM symbols. In another implementation, the network transmits a message in a subframe/slot/symbol to UE, and the UE then changes the start of DRX cycle based on the frame, subframe, slot, or symbol in which UE receives the message. According to this solution, instead of using an offset given by network, the UE uses the reception time of the message to determine the start of the next DRX cycle.

[0030] In yet another implementation, the network configures a UE with a timer, or the UE configures a timer in view of parameters the network provides to the UE. When the timer expires, the UE updates the start of the next DRX cycle. The network and the UE can use the timer to track when the nominal start of xR traffic periods completely falls out of DRX on- duration time period. When the timer expires, UE autonomously (without a command from the network) changes the start of the next DRX cycle to align with XR traffic periods. In still another implementation, the UE adjusts the drift every fixed number of C-DRX cycles, and applies a fixed offset for each adjustment. In another implementation, the UE further considers the C-DRX On-Duration time. As long as the traffic arrival time is still within the On-Duration, the UE does not correct for the drift between the XR traffic arrival and the C-DRX cycles.

[0031] An example communication system in which these techniques can be implemented is discussed next with reference to Fig. 1.

[0032] An example wireless communication system 100 includes a user equipment (UE) 102 and a base stations 104 of a radio access network (RAN) 105 connected to a core network (CN) 110. In other implementations or scenarios, the wireless communication system 100 includes more or fewer UEs, and/or more or fewer base stations, than are shown in Fig. 1. The base stations 103 can be of any suitable type of a base station such as an evolved node B (eNB), a next-generation eNB (ng-eNB), or a 5G Node B (gNB), for example. The base station 104 supports a cell in which the base station 104 and the UE 102 communicate via a radio access technology such as New Radio (NR). Although the examples below refer specifically to specific CN types (EPC, 5GC) and RAT types (5GNR and EUTRA), in general the techniques of this disclosure can also apply to other suitable radio access and/or core network technologies, such as sixth generation (6G) radio access and/or 6G core network or 5G NR-6GDC, for example.

[0033] The base station 104 includes a transceiver (not shown) and processing hardware 130, which can include one or more general -purpose processors (c.g, central processing units (CPUs)) and a computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processor(s), and/or special-purpose processing units. The processing hardware 130 in the example implementation of Fig. 1 includes an XR timing controller 132 that is configured to manage, control, or facilitate the control at the UE 102, of downlink (DL) XR traffic 134 or other low-latency downlink and/or uplink traffic. The XR traffic 134 can be period or quasi-periodic. [0034] The UE 102 includes processing hardware 140, which, in some implementations, includes one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units. The processing hardware 140 in the example implementation of Fig. 1 includes a DRX controller 144 configured to manage DRX cycles and the alignment between DRX cycles the traffic 134.

[0035] The CN 110 can be connected to a streaming server 160 via wide area network 150 such as the Internet. In some implementations, the CN 110 is an evolved packet core (EPC) or a fifth-generation core (5GC). Depending on the implementation, the base station 104 is an eNB supporting an SI interface for communicating with the EPC, an ng-eNB supporting an NG interface for communicating with the 5GC, or a gNB that supports an NR radio interface as well as an NG interface for communicating with the 5GC. The RAN 105 typically multiple base stations, and at least some of the base stations can be interconnected via an X2 or Xn interface. The RAN 105 and the CN 110 are collectively referred to as below as “the network” 108.

[0036] Among other components, the EPC can include a serving gateway (SGW), a mobility management entity (MME), and a packet data network gateway (PGW). The SGW is generally configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME is configured to manage authentication, registration, paging, and other related functions. The PGW provides connectivity from a UE (e.g., the UE 102) to one or more external packet data networks, e.g., an Internet network and/or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC includes a user plane function (UPF) and an access and mobility management (AMF) 164, and/or a session management function (SMF). The UPF is generally configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF is generally configured to manage authentication, registration, paging, and other related functions, and the SMF is generally configured to manage PDU sessions.

[0037] Next, Fig. 2A illustrates an example DRX cycle 200 that includes an on-duration period 202 and an off-duration period 204, which the UE 102 can use an opportunity to sleep or, in any case, operate at a reduced power level. The on-duration period 202 and the off-duration period 204 add up to an overall length 205 of the DRC cycle 200. For example, the UE 102 can monitor signaling from the base station 104 during the period 202, and not monitor signaling from the RAN 105 in general and the base station 104 in particular during the period 204 at all, or reduce the monitoring of signaling. In particular, during the on-duration period 202, the UE 102 can monitor the Physical Downlink Control Channel (PDCCH).

[0038] Fig. 2B illustrates an example DRX cycle 200 with a DRX offset 206. As discussed below with reference to Fig. 3, the network 108 can indicate a combination of the length 205 of the DRX cycle 200 and the offset 206. The nominal start of the first DRX cycle 200 is at the first OFDM symbol of the first slot of the first subframe of the first frame. Thus, the offset 206 is a delay between the start of the nominal DRX cycle and the start of the actual DRX cycle, as illustrated in Fig. 2B.

[0039] Fig. 2C illustrates misalignment of the nominal DRX cycle with periodic or quasi- periodic traffic 220 due to non-integer traffic periodicity. In this example, the bursts 220A, 220B, etc. have the periodicity of approximately 16.67 ms, whereas the DRX cycle has the period of 16 ms, with an on-duration period of 2 ms. Accordingly, whereas the bursts 220A-D fall within the corresponding on-duration periods, the burst 220E falls outside the on-duration periods.

[0040] Fig. 2D illustrates example jitter distribution 250 for video traffic. In general, XR and Media traffic arrives at the RAN 105 from the CN 110 with a jitter. The main source of the jitter is the video encoder during the video encoding process, which takes different durations in encoding video frames depending on the frames types, content and sizes. Hence, the traffic arrival is no longer periodic but quasi-periodic with a random jitter. The jitter causes extra delay to the XR traffic if the data arrives before the DRX on-duration start time or extra power consumption if the data arrives after the DRX On-Duration start time.

[0041] XR traffic has been modeled using a statistical approach. In particular, the jitter was modelled as a truncated gaussian distribution with 2 ms standard deviation and +/-4 ms range, as illustrated in Fig. 2D.

[0042] Fig. 3 illustrates an example scenario 300 in which the network 108 (e.g., the base station 104 and/or the CN 110) modifies an initial configuration of DRX and notifies the UE accordingly. [0043] The network 108 transmits 310 a DRX configuration in a first message which can be for example RR(S Reconfiguration, RRCSetup, RRCReestablishment, RRCReestablishment, RRCResume, etc. The first message can include the length of the DRX cycle and the first offset that UE 102 uses to determine the start of DRX cycles. In some implementations, the network 108 transmits 310 an indicator that indicates a combination of the length of a DRX cycle and an offset, so that the nominal start of the first DRX cycle is at the first OFDM symbol of the first slot of the first subframe of the first frame, and the offset is a delay between the start of the nominal DRX cycle and the start of the actual DRX cycle (see Fig. 2B). Example information the network 108 transmits are discussed below with reference to Figs. 4A-B, 7, and 9-10.

[0044] The UE 102 the processes 320 the first message and begins monitoring signaling according to the configuration. For example, the UE 102 computes the start time of DRX cycles. In one implementation, the start of a short DRX cycle is given by

[ SEA x 10) + subframe number] modulo (clrx-Short('ycle) = (final offset) modulo (drx- ShortCycle) (Eq. 1), and the start position of a long DRX cycle is

[(SFN x 10) + subframe number] modulo (drx-LongCycle) = final offset (Eq. 2), where the final offset is the first offset value, SFN is the current system frame number, and subframe number is the current subframe number (i.e. 0 - 9).

[0045] The network 108 transmits 330 DL data traffic to the UE 102. At some point, the network 108 also can transmit 340 a modification to the DRX configuration, in a “second” message. In one implementation, the second message is a MAC PDU. In some implementations, the network 108 transmits the second message on a PDCCH that is addressed to a dedicated RNTI. The UE 102 identifies the second message using the dedicated RNTI.

[0046] The UE 102 transmits 360 a Third” message to acknowledge the reception of the second message. The third message can be a HARQ ACK or a MAC PDU with a field/indicator in MAC CE or sub-header.

[0047] If the network 108 does not receive the third message, it will retransmit the second message to the UE 102. [0048] Referring to Fig. 4A, the network 108 can implement an example method 400A for specifying a DRX cycle in units other than subframes (e.g., OFDM symbols). Generally speaking, according to this approach, the network 108 transmits a DRX offset and a time unit to the UE 102, and the UE 102 uses the offset and the time unit to determine the start of the next DRX cycle. The UE 102 then determines the start of DRX cycles using this information.

[0049] At block 412, the network 108 transmits, to the UE 102, a DRX configuration and an indication of a time unit other than a subframe, in a (first) message. The first message also includes a first time unit or an indicator of a first time unit. Rather than specifying only the subframe, the network 108 can utilize a different time unit such as one or more of frames, slots, OFDM symbols, etc., so as to provide better granularity. For example, if the first offset is 10 and the first time unit is one OFDM symbol, the offset is 10 OFDM symbols.

[0050] At block 430, the network 108 transmits data traffic, such as XR traffic for example, with non-integer periodicity.

[0051] Optionally, at block 440, the network 108 transmits a command to modify the DRX configuration. For example, the second message can include a second offset or an indicator of a second offset. In another implementation, the second offset is a difference that is added or subtracted from the current offset value. For example, if the current offset is 10 OFDM symbols, the second offset is 5, the resulting offset is 10 + 5 symbols.

[0052] The second message can include an indicator that indicates whether the second offset is a delta difference or is an absolute offset. If the second message does not include the second offset, the UE 102 can use the first offset instead.

[0053] The second message may include a second time unit or an indicator of a second time unit. Similar to the first time unit, the second time unit can be one or plural of frames, subframes, slots, OFDM symbols, etc. For example, the second time unit can be 2 slots. UE applies the second time unit to the second offset. If the second message does not include the second time unit, UE uses the first time unit instead.

[0054] The second message can include a first field/indicator that commands the UE 102 to use the second offset and/or the second time unit to compute the start of DRX cycles. For example, if the first field/indicator is set to a pre-defined value, the UE 102 uses the second offset and/or the second time unit to compute the start of DRX cycles.

[0055] In one implementation, the second message is a MAC PDU that contains a MAC subheader. According to the NR MAC specification, a MAC PDU can contain a single MAC subheader or a pair of a MAC subheader and a MAC CE. The MAC subheader also contains a logical channel ID that distinguishes itself from other MAC subheaders. The MAC subheader can contain a dedicated logical channel ID that distinguishes itself from other MAC subheaders. The MAC subheader contains the first field/indicator. The MAC CE associated with the MAC subheader in the same MAC PDU can contain the second offset and the second time unit

[0056]

[0057] Fig. 4B a flow diagram of an example network-side method for providing a UE with a DRX configuration along with an indication of non-integer periodicity;

[0058] Next, Fig. 5 illustrates an example 500 method for providing a UE with an indication that the UE should determine the start time of a new DRX cycle based on the reception time of the indication. The method 500 also can be implemented in the network 108. Generally speaking, this approach involves the network transmitting a message in a subframe/slot/symbol to UE and then the UE changes the start of DRX cycles based on the frame/ subframe/slot/symbol that UE receives the message. In this solution, instead of using an offset given by network, UE uses receiving time of the message to determine the start of the next DRX cycle.

[0059] Fig. 6 illustrates an example method 600 for specifying a timer according to which the UE applies adjustment to the DRX cycle, which also can be implemented in the network 108. This approach generally requires that the network configure a UE with a timer. When the timer expires, the UE autonomously changes the start of the next DRX cycle. The timer tracks when the nominal start of xR traffic periods completely falls out of DRX on-duration time period. When the timer expires, the UE autonomously changes the start of the next DRX cycle to align with xR traffic periods.

[0060] At block 602, the network 108 calculates the timer value, which can be a multiple of XR traffic periods. Optionally, the network 108 associates the timer value with one or more channels and/or one or more bearers. At block 614, the network 108 then transmits a message (the “first message”) to the UE 102 and includes the DRX configuration and the timer value in the message. At block 630, the network 108 transmits or forwards the traffic with non-integer periodicity to the UE 102.

[0061] The first message can include a first length value for a first timer or an indicator of a first length for a first timer. When the timer expires, the UE 102 can change the start of the next DRX cycle to align with xR traffic periods. Otherwise, the next nominal xR period falls out of DRX on-duration, as illustrated in Fig. 2C.

[0062] In an example implementation, the length of the first timer is one or several of the XR traffic periods. For example, if the nominal start of 4th XR traffic period falls out of DRX on- duration, the length of the first timer can be 3 times the XR traffic periodicity. When the first timer expires, the UE 102 changes the start of the next DRX cycle.

[0063] As indicated above, the first timer may be associated with a channel (e.g. a logical channel or radio bearer) or a group of channels.

[0064] In another implementation, the first message includes a first periodicity (e.g. 16.67ms, 11.11ms, 8.33ms) of the data traffic (or an indicator / index associated with the first periodicity). With the first periodicity and the DRX configuration (ie. DRX cycle length, on-duration time length) that are included in the first message, the UE 102 can derive the first length value.

[0065] Specifically, if n x (periodicity - DRX-cycle-length ) >= ( on-duration-time-length - diff the first length value will be n x periodicity, where n is the smallest integer that satisfies the equation. The difference can be a constant given in the first message or pre-defined. For example, the difference can be the jitter of XR traffic arriving time. In another implementation, n is the smallest integer that satisfies the inequality, minus a certain predefined integer value. In yet another implementation, the network 108 indicates the value of n in the first message.

[0066] The product (n x periodicity) may not correspond to an integer number subframes, but in most systems the on-duration time period always starts at the start of a subframe. For this reason, the first length value can be the ceiling or floor of the product (n x periodicity).

[0067] Tn another implementation, the first length value is set to (n x drx-cycle-length) instead of the product (n x periodicity). Because drx-cycle-length is an integer number of subframes, the product (77 x drx-cycle-length') is an integer number of sub-frames. The UE 102 can use a second counter to count the time / subframes.

[0068] For example, referring to Fig. 12, the DRX-cycle-length in the scenario 1200 is 6, the on-duration-time-length is 2; and the XR data periodicity is 7. Thus, n=2 because 2 x 6 + 2 <= 2 x 7, and 2 is the smallest integer satisfying the inequality above. As a result, the first length value will be 2 x 7 = 14.

[0069] Further, the first message can include a time unit or an indicator of a time unit. The time unit can apply to the first length value.

[0070] In some implementations, the network 108 transmits a second message to the UE 102. In particular, the network 108 can change the length of the first timer by including a second length value (or an indicator of the second length value) in the second message. The second message may also contain a time unit (or an indicator of the time unit) for the second length value. The UE 102 can (re)start the first timer with a length that is derived from the second length value and/or the time unit. In other implementations, the network 108 changes the periodicity of the data traffic.

[0071] In another embodiment, the UE 102 receives the second message at time t. The second message contains a command to ask UE to (re)start the on-duration time at time t or time t+N, where A is predefined or included in the first message.

[0072] In another embodiment, the second message contains a third field/indicator that instructs the UE 102 to restart / stop the first timer. For example, if the third field/indicator is set to a pre-defined value, the UE 102 restarts / stops the first timer.

[0073] In some implementations, the second message is a MAC PDU that includes a MAC subheader. The MAC subheader can contain a logical channel ID that distinguishes itself from other MAC subheaders in the same MAC PDU.

[0074] In one implementation, the MAC subheader contain the third field/indicator. In one implementation, the MAC CE associated with the MAC subheader in the same MAC PDU contains the second length value and its time unit. Tn another impementation, the second message is a DCI that is addressed to a unique RNTI. The RNTI can be provided in the first message [0075] Fig. 7 illustrates an example method 700 for receiving an indication of a DRX cycle in units other than subframes (e.g., OFDM symbols). The method 700 can be implemented in the UE 102 or another suitable UE.

[0076] At block 710, the UE 102 receives a DRC configuration and an indication of a time unit. The UE 102 configures the DRX cycle using the indication, at block 722. In one implementation, the UE 102 uses the equations (1) and (2) above for the time unit of a slot, OFDM symbol, etc. by converting the subframe into slots or OFDM symbols. For example, for the slot time unit, equation (1) becomes [(SFN * 10 + subframe number) * number of slots per subframe modulo (drx-ShortCycle x number of slots _per subframe) = (final offset x number of slots _per subframe) modulo drx-ShortCycle x number of slots per subframey and the start of a long DRX cycle is given by [(SFA x 10 + subframe number) x number of slots per subframe modulo (drx-LongCycle x number of slots _per subframe) = final offset x number of slots per subframe, where the final_offset is the first/second offset value.

[0077] At block 730, the UE receives traffic in accordance with the DRX cycle.

[0078] Optionally, at block 740, the UE receives a modification of the DRX configuration, including a new offset and/or a new time unit. At block 750, the UE applies the received modification. The UE 102 uses the second offset and the second time unit to determine the start of the DRX cycles. For example, the the UE 102 performs step 320 (see Fig. 3) to compute the start of the next DRX cycle.

[0079] Fig. 8 a flow diagram of an example UE-side method for determining the start time of a new DRX cycle based on a time when the UE receives an appropriate indication from the base station.

[0080] Here, at block 842, the UE 102 receives a “second” message (see event 340 in Fig. 3) that contains a second field/indicator instructing the UE 102 to use the reception time of the second message to compute the start of DRX cycles. For example, if the second field/indicator is set to a pre-defined value, the UE 102 should change the start of DRX cycles base on the receiving time of the second message. [0081] In one implementation, the second message is a MAC PDU that includes a MAC subheader. MAC subheader can contain a logical channel ID that distinguishes itself from other MAC subheaders. The MAC subheader can contain the second field/indicator. In an implementation, the MAC CE associated with the MAC subheader in the same MAC PDU contains an offset and a time unit. The UE 102 uses the receiving time, the offset, and the time unit to compute the start of DRX cycles.

[0082] The UE can uses the time that it receives the second message to derive the start time of the next DRX cycle. The network 108 may configure the UE 102 with an offset. For example, the start of the next DRX cycles is the P-th subframe/slot/symbol after the end of the reception of the second message, where P is pre-determined or given in the first message (i.e. semi-static) or the second message (i.e. dynamic ). The P value included in the second message overrides the P value in the first message.

[0083] Fig. 9 is a flow diagram of an example method 900 for using a (first) timer, which can be network-specified, for applying adjustment to the DRX cycle. The method 900 can be implemented in the UE 102 for example. The method 900 begins at block 912, where the UE 102 receives a DRX configuration and a timer value. At block 915, the UE 102 start a timer at the beginning of the DRX cycle. At block 930, the UE 102 receives traffic in accordance with the DRX cycle. At block 950, the UE 102 applies the adjust to the DRX cycle upon timer expiration. The UE 102 also can restart the timer, and the flow can return to block 930.

[0084] In particular, after the UE 102 receives the first message, the UE 102 can restart the first timer. For example, if the UE 102 receives the first message at time /, the UE 102 starts the first timer at the start of the next DRX cycle after time t. The UE 102 can derive the start of the next DRX cycle from the first offset included in the first message. In another embodiment, yhe UE 102 starts the first timer at time t.

[0085] When the first timer (or the counter) expires, the UE 102 changes the start of the next DRX cycle. For example, if the first timer expires in the subframe/slot/symbol M, UE changes the start of the next DRX cycle to subframe/slot/symbol M+N, where N is pre-determined (e.g. A=0) or given in the first message. The UE 102 then computes a new DRX offset. For example, the new DRX offset is the difference between the start of the nominal DRX cycle, and the new start of the next DRX cycle. The UE 102 uses this new DRX offset to determine the start of rest of DRX cycles.

[0086] In another implementation, the first message includes a first delta value ( or an indicator of the first delta value). The first delta value is associated with the first length value. When the first timer expires, the UE 102 uses the first delta value to compute the new DRX offset. For example, the UE 102 adds the first delta value to the current DRX offset and then uses the new DRX offset to determine the start of the rest of DRX cycles. In another implementation, the first delta value is derived from the first periodicity given in the first message. The first delta value can be given by (periodicity - drx-cycle-length)*n).

[0087] Referring again to Fig. 12, the length of a DRX cycle is 6 and the length of on-duration is 2. The length of the periodicity of the xR traffic is 7. The first DRX offset is 0 and the first delta value is 2. When the first timer expires, the UE 102 computes a new DRX offset using the first delta value. The new DRX offset is the current DRX offset plus the delta value so the new DRX offset so it is 0 + 2. The UE 102 uses this new DRX offset value to determine the start of the next DRX cycle. Similarly, after the first timer expires again, the UE 102 computes a new DRX offset which is 2 + 2.

[0088] For example, the UE 102 can use the following formula to determine when to start on- duration timer:

[( W x 10) + subframe number] modulo (drxCycle) = (DRXOffset + (m x delta) - const) modulo (drxCycle (Eq. 3), where m is increased by 1 whenever the first timer expires, and the const can be used to cover jitter. The const can be pre-defined or provided in the first message. In another implementation, the UE 102 increases m by 1 for every n DRX cycles in response at the end of n-th DRX cycle.

[0089] If delta (A) is a non-integer number we take ceiling fix¹) or floor (_LXj) of (m * delta). The equation accordingly changes to

[ STfiV x 10) + subframe number] modulo (drx-Cycle) = (drx-StartOffset + floor(m x delta)) modulo (drx-Cycle) (Eq. 4)

[0090] Further, the UE 102 can address the SFN wraparound issue by modifying the equation to be [(s/c x 10) + subframe number modulo (drx-Cycle) = ((drx-StartOffset) + ceiling (m x delta) ) modulo (drx-Cycle)) (Eq. 5) where sfc (system frame counter) is set to the current SFN when DRX is configured, and then increases by 1 whenever SFN is changed.

[0091] In another implementation, the UE 102 derives the first delta value from the first periodicity. Specifically, the first delta value is (the first periodicity - DRX cycle length) x n. In the example of Fig. 12, the first delta value is (7-6) x 2 = 2.

[0092] When the first timer expires, the UE 102 (re)starts the first timer. The expiration of the first timer serves as a trigger to periodically adjust the start of DRX cycles.

[0093] Further, when the first timer expires, the UE 102 (re)starts the drx-onDurationTimer. The UE 102 uses the drx-onDurationTimer timer to determine the “on duration” of a DRX cycle that it should monitor PDCCH for downlink assignment or uplink grant.

[0094] In another implementation, the UE 102 is configured with a first DRX configuration and a second DRX configuration. When the first DRX configuration is activated, i.e. the UE 102 is using the first DRX configuration, and when the first timer expires, the UE 102 activates the second DRX configuration, i.e. the UE 102 switches to the second DRX configuration. The on- duration time of the second DRX configuration covers the nominal start of the XR traffic.

[0095] After the UE 102 receives the second message, the UE 102 also (re)starts the first timer. For example, the UE (re)starts the first timer with the timer length derived from the second length value and its time unit that are given in the second message.

[0096] After UE receives 102 the second message, the UE changes the start of the next DRX cycle.

[0097] In an embodiment, if the UE 102 receives the second message in subframe/slot/symbol M, UE changes the start of the next DRX cycle to subframe/slot/symbol M+N, where N is predetermined or given in the first message or the second message. Then the UE 102 computes a new DRX offset. For example, the new DRX offset is the difference between the start of the current nominal DRX cycle, described in bullet 1.1.2, and the new start of the next DRX cycle, described in this bullet. The UE 102 uses this new DRX offset to determine the start of rest of DRX cycles [0098] In another embodiment, the second message include a second offset (or an indicator associated with the second offset) that UE uses to determine the start of the next DRX cycle. The second message may include the time unit for the second offset. UE uses the second offset to compute the start of the rest of DRX cycles.

[0099] After the UE 102 receives the second message UE starts the first timer at the start of the next DRX cycle.

[0100] When the first timer expires, the UE 102 (re)starts the first timer. The expiry of the first timer serves as a trigger to periodically adjust the start of DRX cycles.

[0101] In the second message, the network 108 includes a second delta value. The second delta value is associated with the second length value. If the first timer expires, the the UE 102 uses the second delta value to compute a new DRX offset. For example, the UE 102 adds the first delta value to the current DRX off-set and then uses the new DRX offset to determine the start of the rest of DRX cycle.

[0102] In another embodiment, the network 108 transmits the second delta value in the first message. Then NW transmits the indicator of the second length value. When the UE 102 receives the indicator of the second length value, the UE 102 uses the second delta value to compute the new DRX offset.

[0103] Further discussion

• Option 1;

In this option, the system adjust the drift every fixed number of C-DRX cycles and we adjust with a fixed offset. For example for a Frame Rate = 30 fps (33.33 ms periodicity) and drx-Cycle = 32, we will adjust every 3 cycles with an offset equal to 4.

We propose to introduce three new parameters: o drx-CyclesAdjust: number of cycles to apply a correction shift o drx-CyclesOffset: the value of the offset to apply every drx-CyclesAdjust cycles o drx-CorrectionCounter: A counter to apply the offset

And apply the following algorithm:

1. Increment the counter: drx-CorrectionCounter = 0; if (( [(SFN x 10) + subframe number] modulo [(drx-CorrectionCounter + 1) x drx-CyclesAdjust x drx-Cycle = drx-CorrectionCounter x drx-CyclesOffset ) && [(SFN x 10) + subframe number - drx- StartOff set > 0 ] ) drx-CorrectionCounter = drx-CorrectionCounter + 1;

2. Start of On-Duration:

[(SFN x 10) + subframe number] modulo (drx-Cycle) = ( drx-StartOffset + [drx- CorrectionCounter x drx-CyclesOffset]) modulo (drx-Cycle), where SFN is the current System Frame Number, and the subframe number is the current subframe number.

The formulas are evaluated in Error! Reference source not found. B-l as case-1 and case-2. Introducing a drx-Cycle = 33 can further reduce the residual error as shown in in Error!

Reference source not found. B-l as case-3 gNB can use the frame rate irreducible fraction to determine drx-Cycles Adjust and drx- CyclesOffset. e.g. if Frame Rate = 30 fps and drx-Cycle = 32: o 30 f

^J ps = — = — 1000 100 o drx-CyclesAdjust = 3 o drx-CyclesOffset = 100 - drx-CyclesAdjust x drx-Cycle = 4

• Option 2:

In this option, it is proposed to take the C-DRX On-Duration time into consideration and as long as the traffic arrival time is still within the On-Duration there is no need to correct for the drift between the XR traffic arrival and the C-DRX cycles.

A timer is introduced and when the timer expires, the system apply a correction of the drift. The timer duration is t = (n x periodicity) where n is the smallest integer that fulfils the following inequation: ( x drx-Cycle + On-Duration) < (n x periodicity)

Hence, the formula can be written as:

Where A = n x (periodicity - drx-Cycle) and m is incremented every n drx-Cycles

The formula is evaluated in Error! Reference source not found. B-l as case-4.

Note 1: Define new C-DRX cycles for the XR traffic.

• FFS: 9 ms, 11 ms, 17 ms, 33 ms, 34 ms.

• FFS: rounding XR traffic periodicities up and down to nearest integers ( if it is not already supported) Note 2:Re-use the 38.321 equation with some modification for the start of On-Duration timer .

Note 3: Adopt one of the two porposed formulas for the start of On-Duration timer:

• Option 1:

1. Increment the counter: drx-CorrectionCounter = 0; if (([(SFN x 10) + subframe number] modido [(drx-CorrectionCounter + 1) x drx-CyclesAdjust x drx-Cycle] = drx-CorrectionCounter x drx-CyclesOffset ) && [(SFN x 10) + subframe number - drx-StartOffset > 0 ] ) drx-CorrectionCounter = drx-CorrectionCounter - 1;

Note 1: Adopt the two stages C-DRX configurations to handle the jitter.

Note 2: If coarse and fine C-DRX cycles are used for the Jitter, adopt non-uniform On-Durations pattern for the fine C-DRX cycle to match the jitter distribution.

• Adjustment of the C-DRX On-Duration based on the traffic arrival. The adjustment could be an extension, e.g. PDCCH monitoring in an extra time duration after the end of the On-Duration if the data is not received in the On-Duration Error! Reference source not found.. The adjustment could also be an early termination, e.g. stopping the On-Duration at the first data arrival and then relying on the Inactivity Timer Error! Reference source not found..

• Implicit SSSG switching conditioned on data reception: the UE can switch implicitly within the DRX On-Duration from sparse PDCCH monitoring to dense PDCCH monitoring after the data arrival Error! Reference source not found.Error! Reference source not found.. C-DRX Enhancement for multiple XR traffic flows

XR traffic is composed of multiple data flows, like video, audio, pose/control information, haptic, etc. These flows have different traffic characteristics (periodicities, offsets, packet sizes, etc.) and different QoS requirements.

The adoption of multiple simultaneously active C-DRX configurations to support the multi-flow XR traffic has been discussed in RANl#109e Error! Reference source not found.. The main motivation is to reduce the UE power consumption by having a dedicated and optimized C-DRX configuration per XR traffic flow. For example, different C-DRX configurations could be configured for video, audio, haptic flows. Even further, different C-DRX configurations could be used for I-frames vs. P-frames.

Dynamic Adaptation of C-DRX Configuration

The adoption of dynamic adaptation of the C-DRX configuration parameters (On-Duration, Inactivity Timer, Start Offset) has been mentioned in RANl#109e Error! Reference source not found..

Although this technique can help address the jitter and the periodicity alignment issues, it requires the network to have a priori knowledge about the jitter of the traffic burst arriving in the next C-DRX occasion. This requires the network to have instantaneous information from the XR server /video codec about the jitter or the network to do jitter prediction.

Summary of options:

Note 1: Define new C-DRX cycles for the XR traffic:

• FFS: 9 ms, 11 ms, 17 ms, 33 ms, 34 ms.

FFS: include the rounding ofXR traffic periodicities up and down to nearest integers (if it is not already supported)

Note 2: Re-use the 38.321 equation with some modification for the start of On-Duration timer .

Note 3: Adopt one of the two porposed formulas for the start of On-Duration timer:

• Approach 1:

1. Increment the counter: drx-CorrectionCounter = 0; if (([(SFN x 10) + subframe number] modulo [(drx-CorrectionCounter + 1) x drx-CyclesAdjust x drx-Cycle ] = drx-CorrectionCounter x drx-CyclesOffset ) && f(SFN x 10) + subframe number - drx-StartOffset > 0 ] ) drx-CorrectionCounter = drx-CorrectionCounter - 1;

2. Start of On-Duration:

[(SFN x 10) + subframe number] modulo (drx-Cycle) — (drx-StartOffset + [drx- CorrectionCounter x drx-Cycle sOff set]) modulo (drx-Cycle), where SFN is the current System Frame Number, and the subframe number is the current subframe number.

Note 4: Adopt the two stages C-DRX configurations to handle the jitter.

Note 5: If coarse and fine C-DRX cycles are used for the jitter, adopt non-uniform On-Durations pattern for the fine C-DRX cycle to match the jitter distribution.

[0104] The following description may be applied to the description above.

[0105] A user device in which the techniques of this disclosure can be implemented (e.g. , the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an intemet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0106] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code, or machine- readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0107] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general -purpose processors or one or more specialpurpose processors.

Claims

What is claimed is:

1. A power saving method implemented in a user equipment (UE), the method comprising: monitoring signaling according to a periodic schedule in which a monitoring cycle having a cycle length includes an on-duration period during which the UE monitors signaling between the UE and a radio access network (RAN), and an off-duration period; communicating, with the RAN and during the monitoring, traffic with a traffic periodicity; and adjusting alignment between the monitoring and the communicating using a timer with a timer duration based on (i) the cycle length, (ii) the traffic periodicity, and (iii) the on-duration period.

2. The method of claim 1, wherein the adjusting of the alignment includes: starting a timer when a start of the monitoring cycle coincides with a start of a period of the traffic; and in response to the timer expiring, applying a correction to re-align the monitoring cycle with the period of the traffic.

3. The method of claim 2, further comprising: receiving the correction from the RAN.

4. The method of claim 3, wherein the correction is received along with a configuration for the monitoring of the signaling.

5. The method of claim 3, wherein the correction is received subsequently to receiving a configuration for the monitoring of the signaling, in a dedicated message.

6. The method of any of the preceding claims, further comprising: setting the timer duration to an integer multiple of the traffic periodicity.

7. The method of claim 6, wherein the setting of the timer duration including setting n to a smallest integer value that satisfies

(n * drx_Cycle + On — Duration) < (n * typeriodicity), where the timer duration is /. the integer multiple is n, the on-duration period is On-Duration, the cycle length is drx Cycle, and the traffic periodicity is t _periodicity.

8. The method of claim 7, further comprising: determining the correction (A) according to:

[(m + A)] mod drx_Cycle), where a System Frame Number is SFN, a subframe number is SF num, an offset of the monitoring cycle is drx star Offset. and a counter incremented every n instances of the monitoring cycle is m.

9. The method of any of the preceding claims, wherein the monitoring and the communicating correspond to connected-mode discontinuous reception (C-DRX).

10. The method of any of the preceding claims, further comprising: receiving the timer duration from the RAN.

11. A configuration method implemented in a base station operating in a radio access network (RAN), the method comprising: transmitting, to a user equipment (UE), a periodic schedule including a monitoring cycle having a cycle length with an on-duration period during which the UE monitors signaling between the UE and the radio access network (RAN), and an off-duration period; communicating, with the UE and while the UE monitors the signaling according to the periodic schedule, traffic with a traffic periodicity; and configuring the UE to adjust alignment between the monitoring and the communicating using a timer with a timer duration based on (i) the cycle length, (ii) the traffic periodicity, and (iii) the on-duration period.

12. The method of claim 11, wherein the configuring includes: transmitting, to the UE, at least one of (i) the timer duration or (ii) a correction for realigning the monitoring cycle with a period of the traffic.

13. The method of claim 12, wherein: the at least one of the timer duration and the correction are transmitted along with the periodic schedule.

14. The method of claim 12, wherein: the at least one of the timer duration and the correction are transmitted subsequently to the transmitting of the periodic schedule, in a dedicated message.

15. An apparatus comprising: a transceiver; and processing hardware configured to implement a method according to any of the preceding claims.