Method for enabling wireless communication device to access services provided by wireless access network and related device

Abstract

The present application provides a method, a User Equipment, UE, a Base Station, BS, and a non-transitory computer readable storage medium for enabling a wireless communication device to access a service provided by a wireless access network. In the method, a Discontinuous Reception (DRX) cycle having a DRX ON cycle for transmitting at least one type of control information or data and a DRX OFF cycle during which the transmission is suspended is configured, and in particular, the DRX cycle is a specific DRX cycle having a non-integer duration. This can eliminate a mismatch between the burst arrival interval and the DRX cycle, thereby adapting to, for example, Extended Reality (XR) / Cloud Game (CG) traffic.

Description

Technical Field

[0001] The present application relates to wireless communications, and more specifically, to a method for enabling a wireless communication device to access services provided by a wireless access network, as well as related equipment such as user equipment (UE) and a base station (BS). Background Art

[0002] This background section introduces some contents that are helpful for a better understanding of the present disclosure. Therefore, the statements in this section should be read for this purpose and should not be understood as an admission of the contents in the prior art or the contents in the non-prior art.

[0003] Communication systems and networks have evolved into broadband and mobile systems. In the cellular wireless communication system developed by the Third Generation Partnership Project (3GPP), the user equipment (UE) is connected to the radio access network (RAN) through a wireless link. The RAN includes a group of base stations (BSs) that provide wireless links to UEs within the cellular area covered by the base stations and are connected to the core network (CN) that provides overall network control. As understood, the RAN and CN each perform their functions in the overall network.

[0004] 3GPP developed the so-called Long Term Evolution (LTE) system, the Evolved Universal Mobile Telecommunication System Territorial Radio Access Network (E-UTRAN) for mobile access networks, in which one or more macro cells are supported by base stations called eNodeB or eNB (evolved Node B). More recently, in the so-called 5G or New Radio (NR) system that evolved from LTE, one or more cells are supported by base stations called gNBs.

[0005] The 5G NR standard supports a variety of different services, each with very different requirements. These services include Enhanced Mobile Broadband (eMBB) for high data rate transmission, Ultra-Reliable Low Latency Communication (URLLC) for devices with low latency and high link reliability, and Massive Machine-Type Communication (mMTC) for supporting a large number of low-power, long-lifetime, and energy-efficient communications.

[0006] In 3GPP Release 17 (Rel-17), traffic patterns for extended reality (XR) and cloud gaming (CG) were studied. The characteristics of XR / CG traffic include small traffic periods with jitter, large packet sizes, and different traffic patterns between uplink (UL) and downlink (DL). Existing enhanced mobile broadband (eMBB) and ultra-reliable low-latency communication (URLLC) power saving mechanisms may not be directly applicable to XR / CG services. 3GPP Release 18 (Rel-18) approved a study project on "NR XR Enhancement Study" (FS_NR_XR_enh) to study how to enhance standard specifications to accommodate XR / CG services. According to the objectives of the Rel-18 IoT NTN research project, how to enhance the existing power saving mechanisms, such as connected mode discontinuous reception (CDRX) and user equipment (UE) physical downlink control channel (PDCCH) monitoring for XR services, is an important issue that needs to be addressed.

[0007] Extended Reality (XR) and Cloud Gaming (CG) are important services of New Radio (NR) in Rel-18 and beyond. Cloud Gaming (CG) is a form of online gaming in which most of the game-related computations are offloaded from the UE to a remote server. Extended Reality (XR) is a term that refers to all realities combined with virtual environments and human-to-human and human-to-machine communications through handheld and wearable user devices. The use cases of XR include Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR). While XR and CG provide attractive use cases for future mobile systems, they also bring a series of challenges to NR that need to be studied and possibly solved.

[0008] Many XR and CG use cases are enabled by video streaming, which is characterized by quasi-periodic downlink (DL) traffic with possible jitter and high data rates, combined with frequent uplink (UL) updates (i.e., attitude / control updates) and / or UL video streaming. DL and UL traffic also have relatively tight packet delay budgets (PDBs). Therefore, it is necessary to study and develop possible solutions to better support these challenging services.

[0009] Many end-user XR and CG devices are expected to be mobile and miniaturized, and therefore have limited battery power resources. Therefore, additional power enhancement measures may be required to reduce the overall UE power consumption when running XR and CG services, thereby extending the effective battery life of the UE. It is understood that the current discontinuous reception (DRX) configuration is not suitable for (i) non-integer XR traffic cycles, (ii) variable XR data rates, and (iii) quasi-periodic XR cycles with jitter, therefore, enhancing the DRX configuration will help reduce the UE power consumption.

[0010] Typical XR DL frame rates are 60, 90 or 120 frames per second (fps), with frame periods of 16.67 microseconds (ms), 11.11ms and 8.33ms, respectively. Rel-15 / 16 connected mode DRX (CDRX) can be configured with long cycle values ​​of 10, 20, 32, 40, 60ms, etc., and short cycle values ​​of 2, 3, 4, 5, 6, 7, 8, 10, 14, 16, 20, 30, 32, 35, 40ms, etc. Since the CDRX cycle value only supports integer multiples of 1ms, no matter which cycle is selected from the currently available values, it cannot be completely aligned with the DL frame arrival time. Figure 1 Figure 1 shows the mismatch between 60fps and DRX cycle. With 16ms DRX cycle, traffic will gradually fall behind the DRX on cycle. With 17ms DRX cycle, traffic will gradually arrive in DRX on cycle earlier. This mismatch will lead to loss of XR capacity due to larger latency and / or increased UE power consumption to maintain the same latency performance.

[0011] The technical problem can be briefly summarized as how to enhance the current DRX configuration to adapt to XR / CG traffic, and how the eNB / UE can accurately configure and / or adjust the DRX configuration based on XR / CG traffic characteristics (such as multiple flows with non-integer periodicity and arrival time jitter). Therefore, it is urgent to develop a new method to solve the above problems.

[0012] Related technologies:

[0013] Discontinuous Reception (DRX):

[0014] DRX is a method used to save UE (User Equipment) battery power in cellular communications. DRX was introduced in LTE / NR to improve UE power consumption by allowing the UE to periodically enter the OFF state to stop monitoring the Physical Downlink Control Channel (PDCCH). During the OFF state, the UE turns off its receiver, thereby reducing the UE's power consumption. The UE will wake up periodically during the ON state to monitor the PDCCH for downlink (DL) data reception. The interval of the ON state (i.e., the ON period) is configured by the RRC parameter drx-onDurationTimer. A DRX ON period (DRX ON period) and a DRX OFF period (DRX OFF period) constitute a DRX cycle, such as Figure 2 shown.

[0015] The triggering conditions of the DRX cycle are as follows: When short DRX is configured, such as Figure 3 As shown, and data transmission / reception occurs in the previous ON period, the next ON period will start in the subframe that meets the following conditions:

[0016] [(SFN×10)+subframe number]mod(drx-ShortCycle)=(drx-StartOffset)mod(drx-ShortCycle).

[0017] Where SFN represents the System Frame Number (SFN). The actual start period starts after a specific slot offset configured by the RRC parameter drx-slotoffset. The value range of drx-slotoffset is 0 to 31, and the unit is 1 / 32ms. drx-ShortCycle defines the short DRX cycle configured for the UE, and its value range is 2 to 640ms. drx-startoffset represents the starting subframe of the short DRX cycle, and its unit is 1ms.

[0018] When drx-ShortCycleTimer (i.e., the number of short DRX cycles, ranging from 1 to 16) expires or the short DRX cycle is not configured, the UE uses the long DRX cycle. The start period of the long DRX cycle starts in the subframe that meets the following conditions:

[0019] [(SFN×10)+subframe number]mod(drx-LongCycle)=(drx-StartOffset).

[0020] Among them, drx-LongCycle defines the long DRX cycle configured for the UE, and its value range is 10 to 10240ms. The long DRX cycle configuration is the default configuration of DRX, and the short DRX cycle configuration is optional. When the short DRX cycle is configured, the duration of the long DRX cycle is an integer multiple of the duration of the short DRX cycle. Summary of the invention

[0021] In a first aspect, an embodiment of the present application provides a method for enabling a wireless communication device to access services provided by a wireless access network, wherein a DRX cycle having a discontinuous reception (DRX) on period for transmitting at least one control information or data and a DRX off period during which transmission is suspended is configured, and the DRX cycle is a specific DRX cycle with a non-integer duration.

[0022] In a second aspect, an embodiment of the present application provides a method for enabling a wireless communication device to access services provided by a wireless access network, wherein a DRX cycle is configured having a DRX on cycle for transmitting at least one control information or data and a DRX off cycle during which transmission is suspended, and the DRX cycle is modified based on a burst arrival interval to eliminate a mismatch between the burst arrival interval and the DRX cycle.

[0023] In a third aspect, an embodiment of the present application provides a method for enabling a wireless communication device to access services provided by a wireless access network, wherein a DRX cycle having a DRX on period for transmitting at least one control information or data and a DRX off period during which transmission is suspended is configured, and the DRX on period of the DRX cycle is extended to cover an arrival interval of at least one data burst plus data arrival jitter.

[0024] In a fourth aspect, an embodiment of the present application provides a method for enabling a wireless communication device to access services provided by a wireless access network, wherein a physical downlink control channel (PDCCH) monitoring period is dynamically changed based on a search space group (SSSG) switching indication, and at least two search spaces are configured, one for sparse PDCCH monitoring and the other for dense PDCCH monitoring.

[0025] In a fifth aspect, an embodiment of the present application provides a method for enabling a wireless communication device to access services provided by a wireless access network, wherein multiple DRX configurations with different start offsets and different DRX cycles are configured, and one of the DRX configurations is activated each time.

[0026] In the sixth aspect, an embodiment of the present application provides a method for enabling a wireless communication device to access multimodal services provided by a wireless access network, wherein a DRX configuration is configured for a variable-size stream, a semi-persistent scheduling (SPS) configuration is configured for a fixed-size downlink (DL) stream, and a configured grant (CG) configuration is configured for a fixed-size uplink (UL) stream.

[0027] In a seventh aspect, an embodiment of the present application provides a user equipment (UE), comprising: a memory for storing program instructions; a transceiver for sending and receiving data; and a processor coupled to the memory and the transmitter, configured to call and run the program instructions stored in the memory, and cooperate with the memory to execute any one of the methods in the above aspects.

[0028] In the eighth aspect, an embodiment of the present application provides a base station (Base Station, BS), comprising: a memory for storing program instructions; a transceiver for sending and receiving data; and a processor coupled to the memory and the transmitter, configured to call and run the program instructions stored in the memory, and cooperate with the memory to execute any one of the methods in the above aspects.

[0029] In a ninth aspect, an embodiment of the present application provides a non-transitory computer-readable storage medium configured to store a computer program, wherein the computer program enables a computer to execute any of the methods in the above aspects.

[0030] In a tenth aspect, an embodiment of the present application provides a computer-readable storage medium for storing a computer program, wherein the computer program enables a computer to execute any of the methods in the above aspects.

[0031] In an eleventh aspect, an embodiment of the present application provides a computer program product, wherein the computer program product includes computer program instructions, enabling a computer to execute any of the methods in the above aspects.

[0032] In a twelfth aspect, an embodiment of the present application provides a computer program, which, when executed on a computer, enables the computer to execute any of the methods in the above aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the embodiments of the present application or related technologies, the following briefly introduces the drawings described in the embodiments. Obviously, these drawings are only some embodiments of the present application, and ordinary technicians in this field can obtain other drawings based on these drawings without making any assumptions.

[0034] Figure 1 Schematic diagram of the mismatch between XR downlink (DL) traffic (60fps) and traditional CDRX cycles (16ms and 17ms).

[0035] Figure 2 is a schematic diagram of a long DRX configuration.

[0036] Figure 3 is a schematic diagram illustrating a short DRX configuration.

[0037] Figure 4 It is a block diagram of one or more user equipments (UEs), base stations (BSs) and network entity devices in a communication network system according to an embodiment of the present application.

[0038] Figure 5 It is a schematic diagram of the radio protocol architecture within gNB and UE.

[0039] Figure 6 is a schematic diagram of a gNB consisting of a centralized unit (CU) and multiple distributed units (DUs).

[0040] Figure 7 The figure is a schematic diagram of PDU classification of video streams in 3GPP networks.

[0041] Figure 8 is a schematic diagram of a DRX cycle modified based on burst arrival interval.

[0042] Fig. 9 It is a schematic diagram of the first subframe number of the start cycle when the short DRX cycle = 16 ms.

[0043] Fig.10 It is a schematic diagram of the first subframe number of the start cycle when the short DRX cycle = 16 ms and T = 2 ms.

[0044] Fig.11 It is a schematic diagram of the first subframe number of the start cycle when the short DRX cycle = 16 ms.

[0045] Fig.12 is a schematic diagram of a DRX configuration with a periodicity of {16ms, 17ms, 17ms} formed by three DRX configurations consisting of {0ms, 16ms, 33ms} start offsets.

[0046] Fig.13 is a schematic diagram of the adjusted on-period to accommodate jitter.

[0047] Fig.14 It is a schematic diagram of an internal short cycle configured within another external long cycle.

[0048] Fig.15 This is a schematic diagram of XR / CG energy saving based on PDCCH.

[0049] Fig.16 This is a schematic diagram of XR / CG energy saving based on PDCCH.

[0050] Fig.17 It is a schematic diagram of combining PDCCH-based energy saving with DRX-based energy saving.

[0051] Fig.18 is a schematic diagram of multiple DRX configurations.

[0052] Fig.19 It is a schematic diagram of DRX configuration, CG configuration and SPS configuration for multimodal services.

[0053] Fig. 20 It is a schematic diagram of starting / updating DRX configuration for UE. DETAILED DESCRIPTION

[0054] In order to more clearly illustrate the embodiments of the present invention or related technologies, the following briefly introduces the drawings that will be described in the embodiments. Obviously, these drawings are only part of the embodiments of the present invention, and ordinary technicians in this field can obtain other drawings based on these drawings without making any assumptions.

[0055] The present invention realizes DRX (discontinuous reception) enhancement in the following aspects:

[0056] Traffic burst of video streaming in 3GPP network:

[0057] Describe the composition and characteristics of video streams in 3GPP networks. Each frame of a video stream is classified into a set of PDUs (Protocol Data Units) and then mapped to QoS (Quality of Service) sub-flows and DRBs (Data Radio Bearers) and logical channels.

[0058] Configure a specific DRX cycle for a video stream:

[0059] Configure a non-integer DRX cycle for video streams of XR / CG (Extended Reality / Cloud Gaming) services. This non-integer value needs to be explained in the standard specification.

[0060] Modify the DRX cycle based on the trigger equation:

[0061] Fine-tune the DRX cycle within a fixed long period. The triggering equation can be described in the standard specification.

[0062] Modify the DRX cycle by configuring multiple DRX configurations:

[0063] Multiple DRX configurations need to be specified for XR / CG services in the standard specification.

[0064] Handling traffic arrival time jitter:

[0065] Configure a longer on-cycle to cover most arrival times. Configure a short DRX cycle or a different search space within the on-cycle to reduce the PDCCH (Physical Downlink Control Channel) monitoring time.

[0066] Multimodal services supporting XR / CG:

[0067] Multiple DRX configurations for XR / CG services may be specified in the standard specification.

[0068] Based on the proposed DRX enhancement, UE (User Equipment) can save power when supporting multimodal services of XR / CG applications.

[0069] Figure 4 In some embodiments, according to one embodiment of the present invention, one or more user equipment (UE) 10a, 10b, a base station (such as a gNB or an eNB) 200a, and a network entity device 300 for wireless communication in a communication network system are described. Figure 4 UE 10a, UE 10b, base station 200a and network entity device 300 perform the method of the embodiment of the present invention. The connection between the devices and the components thereof is Figure 4 1 and 12. The UE 10a may include a processor 11a, a memory 12a, and a transceiver 13a. The UE 10b may include a processor 11b, a memory 12b, and a transceiver 13b. The base station 200a may include a processor 201a, a memory 202a, and a transceiver 203a. The network entity device 300 may include a processor 301, a memory 302, and a transceiver 303. The processors 11a, 11b, 201a, and 301 may be configured to implement the functions, processes, and / or methods described in this specification. The layers of the wireless interface protocol may be implemented in the processors 11a, 11b, 201a, and 301. The memories 12a, 12b, 202a, and 302 operatively store various programs and information for running the connection processor. The transceivers 13a, 13b, 203a, and 303 are operatively coupled to the connection processor for sending and / or receiving wireless signals. Base station 200a can be an eNB, gNB or one of the other wireless nodes.

[0070] Processors 11a, 11b, 201a and 301 may include general-purpose central processing units (CPUs), application-specific integrated circuits (ASICs), other chipsets, logic circuits and / or data processing devices. Memories 12a, 12b, 202a and 302 may include read-only memories (ROMs), random access memories (RAMs), flash memory, memory cards, storage media, other storage devices and / or combinations of storage devices. Transceivers 13a, 13b, 203a and 303 may include baseband circuits and radio frequency (RF) circuits to process radio frequency signals. When implemented in software, the techniques described in this specification may be implemented by modules, processes, functions and entities that implement the described functions. These modules may be stored in memories and executed by processors. Memories may be implemented within or outside the processor, and these memories may be communicatively coupled to the processor in various ways known in the art.

[0071] The network entity device 300 may be a node in a core network (Core Network, CN). The core network may include an LTE core network or a 5G core network (5G Core, 5GC), which may include a user plane function (User Plane Function, UPF), a session management function (Session Management Function, SMF), an access and mobility management function (Access and Mobility Management Function, AMF), a unified data management (Unified Data Management, UDM), a policy control function (Policy Control Function, PCF), a control plane (ControlPlane, CP) / user plane (User Plane, UP) separation (CUPS), an authentication server function (Authentication Server Function, AUSF), a network slice selection function (Network Slice Selection Function, NSSF), a network exposure function (Network Exposure Function, NEF) and other network entities.

[0072] Figure 5The figure shows the radio protocol architecture within the base station (gNB) and UE, including Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC) and Physical Layer Protocol (PHY). In the RAN functional segmentation, the gNB is Figure 6 The figure further includes a centralized unit (CU) and multiple distributed units (DUs). The protocol stack of the CU includes an RRC layer, an optional SDAP layer, and a PDCP layer, while the protocol stack of the DU includes an RLC layer, a MAC layer, and a PHY layer. The F1 interface between the CU and the DU is established between the PDCP layer and the RLC layer of the protocol stack.

[0073] Traffic burst of video streaming in 3GPP network:

[0074] Figure 7It shows how to transport a group of pictures (GOP) from an Internet Protocol (IP) data network to a 3GPP Radio Access Network (RAN). A video stream from an XR / CG (Extended Reality / Cloud Gaming) application may consist of a series of I-frames, B-frames, and P-frames. I-frames carry completely independently coded pictures, while B / P-frames are coded based on the previous or next picture. Each frame can consist of multiple IP packets (about 1500 bytes each), depending on the frame type. When a frame (i.e., multiple IP packets) enters the 3GPP network (e.g., User Plane Function (UPF)), it is encapsulated into multiple General Packet Radio Service (GPRS) Tunneling Protocol User Plane (GTP-U) Protocol Data Units (PDUs), and these PDUs (belonging to one frame) may form a PDU set. The PDUs in a PDU set share the same Quality of Service (QoS) characteristics, such as packet size, delay budget, delay jitter, priority, etc. PDUs in different PDU sets may use different QoS requirements. PDUs in different PDU sets may be classified as different sub-flows in a QoS flow (i.e., PDUs in different PDU sets may share the same 5-tuple but have different priorities). If sub-flows are not supported, PDUs in different PDU sets may also be classified as different QoS flows. In this case, the header of each PDU shall indicate the PDU set to which it belongs.

[0075] When PDUs enter the 3GPP radio access network, the Service Data Adaptation Protocol (SDAP) layer of the gNB maps the sub-flows (or QoS flows) to different Data Radio Bearers (DRBs). Each DRB is configured with QoS parameters (such as the delay budget of the PDU set, the error rate of the PDU set, the priority, etc.), which may be different from other DRBs. The gNB creates a Packet Data Convergence Protocol (PDCP) entity for each sub-flow (or QoS flow) and maps the PDUs in each DRB to the relevant logical channels of the DRB. The advantage of this is that the traditional mapping between QoS flows and DRBs can be reused.

[0076] In another implementation, sub-flows (or QoS flows) are mapped to the same DRB. In this case, since they belong to the same DRB, the PDUs share the same QoS parameters. The PDCP entity should be able to distinguish PDUs in different PDU sets and map them to appropriate logical channels. The benefit of this approach is that the ordered delivery of PDUs can be guaranteed.

[0077] According to the priority of each DRB, the PDCP entity can configure one or more Radio Link Control (RLC) entities for each DRB. For example, if an I frame has a high priority, PDCP can configure multiple RLC entities (such as 2 or 4) and related logical channels for the DRB to achieve PDCP repetition, thereby improving the reliability of the I frame.

[0078] At the Medium Access Control (MAC) layer, the PDUs in each logical channel (LCH) are encapsulated into MAC PDUs and wait to be scheduled and sent to the UE.

[0079] Configure a specific DRX cycle for a video stream:

[0080] For the video stream of the XR / CG (extended reality / cloud gaming) service, a DRX (discontinuous reception) cycle is configured, which is a non-integer DRX cycle. The DRX cycle can be a short DRX cycle or a long DRX cycle. The DRX cycle is configured with a DRX on cycle for transmitting at least one control information or data and a DRX off cycle during which the transmission is suspended. Specifically, the DRX cycle is a specific DRX cycle with a non-integer duration. The specific DRX cycle is configured for a specific application scenario (e.g., XR / CG service) and is listed as a non-integer value in the information element. That is, the non-integer value can be described in the standard specification. For example, the non-integer duration can be 33.33, 16.67, 11.11 or 8.33 microseconds. In the case where the specific DRX cycle is a short DRX cycle, a corresponding long DRX cycle can be added to the information element, and the duration of the long DRX cycle is an integer multiple of the duration of the short DRX cycle. The specific DRX cycle can be obtained by combining the integer part of a DRX cycle listed in the information element and the possible decimal part listed in the information element. For example, the decimal part is a rational number. Further details are provided below.

[0081] Based on the frame rate (i.e. 60, 90 or 120fps), a series of MAC PDUs (Media Access Control Protocol Data Units) are periodically generated for video streaming. The gNB (Next Generation Base Station) can configure a DRX for the UE (User Equipment) to receive MAC PDUs periodically. During the DRX on period, the UE wakes up to receive MAC PDUs and enters a dormant state (i.e., the UE suspends PDCCH monitoring) during the DRX off period to save power. Table 1 below shows the possible configurations of long and short DRX cycles in the current 3GPP Technical Specification (TS) 38.331. In the current specification, only integer-valued periods can be configured for the DRX cycle. To provide non-integer periods, the most straightforward approach is to add a new value for the long / short DRX cycle. However, enumerating all non-integer values ​​is very difficult and inefficient. To cover the periodicity of 30, 60, 90, and 120fps, non-integer settings such as 1 / 3, 1 / 6, 1 / 9, etc. are required.

[0082] Table 1 - Long DRX cycle and short DRX cycle in TS 38.331:

[0083]

[0084]

[0085] One solution is to configure a DRX cycle (e.g., 30, 60, 90, 120fps) for each traffic arrival pattern. For example, four short DRX cycles can be configured for the drx-ShortCycle of Rel-18, which are 33.33ms, 16.67ms, 11.11ms, and 8.33ms to accommodate 30, 60, 90, and 120fps. Although these extensions are configured as short DRX cycles, as shown in Table 2 below, this does not limit the extensions to be configured as long DRX cycles.

[0086] Table 2 - Short DRX cycle information elements:

[0087]

[0088] The corresponding long DRX cycle should be added because the duration of the long DRX cycle is an integer multiple of the short DRX cycle duration. Table 3 below lists some examples of long DRX cycles.

[0089] Table 3 - Long DRX cycle with start offset:

[0090]

[0091]

[0092] Another solution is to combine the integer part in the existing short DRX cycle with the fractional part in the extension. Taking the short DRX cycle of 16.67ms as an example, the integer part in drx-ShortCycle (i.e. 16ms) and the fractional part in drx-ShortCycle-r18 (i.e. 2 / 3ms) constitute the short DRX cycle of 16.67ms. Table 4 below lists the possible fractional parts of the short DRX cycle in the XR / CG usage scenario.

[0093] Table 4 - Short DRX cycle information elements:

[0094]

[0095] Configuring a specific DRX cycle for a specific application scenario is the most straightforward approach, but its disadvantage is that as the number of application scenarios increases, the number of DRX cycles in the configuration will also increase. However, this approach can support specific usage scenarios in a simple way without major revisions to the standard.

[0096] Modify the DRX cycle based on the trigger equation:

[0097] For the video stream of XR / CG (extended reality / cloud gaming) services, a DRX (discontinuous reception) cycle is configured. The DRX cycle can be a short DRX cycle or a long DRX cycle. The DRX cycle is configured with a DRX on period for transmitting at least one control information or data and a DRX off period during which the transmission is suspended. Specifically, the DRX cycle is modified based on the Burst Arrival Interval. In particular, the DRX cycle is periodically fine-tuned by a trigger equation to eliminate the mismatch between the burst arrival interval and the DRX cycle. The trigger equation can be described in the standard specification. According to the trigger equation, the DRX cycle can be modified according to the cumulative difference between the burst arrival interval and the configured DRX cycle. The cumulative difference can be normalized by a predefined time interval.

[0098] Specifically, the (minimum) difference between the burst arrival interval and the configured DRX cycle can be less than 1 (a real number between 0 and 1) or not less than 1 (a real number greater than 1). The DRX cycle can be configured as an integer (listed in the information element) less than or equal to the burst arrival interval. The DRX cycle can be configured via a short DRX cycle information element or a long DRX cycle information element. Alternatively, the DRX cycle can be configured as a real number (which may or may not be listed in the information element). Depending on the trigger equation, a system frame number (SFN) wraparound counter can be added to the trigger equation. The DRX cycle based on the burst arrival interval can be provided to the base station by the user equipment (UE) and / or the application server to configure the DRX cycle. Further details are as follows.

[0099] This method does not directly configure a new DRX cycle, but modifies the DRX cycle on some cycles through the trigger equation. The advantage of this method is that the existing DRX parameters (e.g., DRX cycle, start offset, time slot offset, etc.) can be reused, and the small value of the DRX cycle can be achieved by adjusting the remainder of the modulo function in the trigger equation. However, the new trigger equation may have an impact on the existing equation. In order to instruct the UE to use the new trigger equation, some parameters (e.g., DRX indication of XR / CG or δ n ) can be configured for the UE through Radio Resource Control (RRC) messages.

[0100] Taking 60fps as an example, the burst arrival interval is 16.67ms. Figure 8 It shows that the DRX cycle needs to be modified by 2ms every 50ms to eliminate the mismatch between the burst arrival interval and the DRX cycle. In order to modify the DRX cycle, the trigger equation should be modified as follows:

[0101] [(SFN×10)+subframe number]mod(drx-ShortCycle)=(drx-StartOffset+δ n )mod(drx-ShortCycle).

[0102] Among them, δ n =round[n·(burst arrival interval-DRX cycle)], n represents the count of the DRX cycle, starting from zero, and the DRX cycle is configured as an integer less than or equal to the burst arrival interval. The offset between the start time of the DRX cycle and the starting point of the system frame (i.e., SFN=0 and subframe=0) is represented by drx-StartOffset.

[0103] Assuming that the burst arrival interval is 16.67ms, the short DRX cycle can be configured as 16ms and the drx-StartOffset is configured as 6. Fig. 9 The first subframe number of the start period of the short DRX cycle is shown. The short DRX cycle is modified to 16ms, 17ms and 17ms through the trigger equation. It should be noted that the short DRX cycle here is just an example, and we are not limited to the use of the long DRX cycle.

[0104] When the difference between the burst arrival interval and the DRX cycle exceeds T ms, the trigger equation can be modified as follows to adjust the DRX cycle:

[0105]

[0106] Fig.10 The short DRX cycle in is modified to 16ms, 16ms and 18ms through the triggering equation when T=2ms.

[0107] Mismatch problem during SFN wraparound:

[0108] SFN ranges from 0 to 1023, and subframe numbers range from 0 to 9. Therefore, [(SFN×10)+subframe number] ranges from 0 to 10239, and wraps back to 0 when it reaches 10239. Therefore, if the DRX cycle length is not a factor of 10240ms, the equation will incorrectly calculate the start point of the DRX cycle whenever the SFN value wraps around, and propagate the offset to the next cycle. To address the mismatch problem when the SFN wraps around, a counter C is added to the above equation to count the number of wraps, as follows:

[0109] [((1024xC+SFN)×10)+subframe number]mod(drx-ShortCycle)=(drx-StartOffset+δ n )mod(drx-ShortCycle).

[0110] Among them, δ n =round[n·(burst arrival interval-DRX cycle)] and C is used to count the number of wraparounds.

[0111] Take the above situation as an example, where the burst arrival interval is 16.67 ms, the short DRX cycle is configured as 16 ms, and the drx-StartOffset is configured as 6. Fig.11 It is shown that before SFN wraparound (ie C=0), the DRX cycle continues after SFN wraparound (ie C=1) without mismatch.

[0112] When the DRX cycle is configured as a real number:

[0113] The modular operation is defined by the following equation for any two real numbers x and y (y ≠ 0):

[0114]

[0115] When the DRX cycle (ie, drx-ShortCycle) is configured as a real number (for example, 33.33ms, 16.67ms, 11.11ms, 8.33ms for 30, 60, 90, and 120fps, respectively), the trigger equation can be modified as follows:

[0116]

[0117] Among them, a=drx-ShortCycle, b=drx-StartOffset.

[0118] Since [(SFN×10)+subframe number] and drx-StartOffset a are always integers, the above trigger equation can be modified as follows:

[0119]

[0120] The modified equation can reduce the computational complexity of real number modular operations.

[0121] Modify the DRX cycle by configuring multiple DRX configurations:

[0122] Multiple DRX configurations for XR / CG services can be specified in the standard specification. These multiple DRX configurations with the same period but different start offsets are combined into one DRX configuration to eliminate the mismatch between the burst arrival interval and the DRX period. In addition, the DRX timers of multiple DRX configurations can be configured separately. Further details are provided below.

[0123] according to Figure 8 , a DRX configuration with a period of {16ms, 17ms, 17ms} can also be composed of multiple DRX configurations. Consider a 60fps usage scenario, which means that 3 video frames arrive every 50ms. We can configure a DRX configuration for each video frame so that the three DRX configurations have the same period (i.e. 50ms) but different start offsets (i.e. 0ms, 16ms, 33ms). Fig.12 It explains how these three DRX configurations form a complete DRX configuration.

[0124] The advantage of this approach is that existing parameters (e.g., DRX cycle, start offset, slot offset, etc.) can be reused. In addition, the DRX timers (e.g., drx-InactivityTimer and drx-onDurationTimer) of each DRX configuration should be configured separately.

[0125] Handling traffic arrival time jitter:

[0126] A longer DRX on cycle is configured to cover most arrival times. For video streams of XR / CG services, a DRX cycle is configured. The DRX cycle includes a DRX on cycle for transmitting at least one control information or data and a DRX off cycle for suspending transmission. Specifically, the on cycle of the DRX cycle is extended to cover the arrival interval of at least one data burst plus data arrival jitter. The data arrival jitter may be provided to the base station by a user equipment (UE) and / or a network entity in the 5G core network for configuring the DRX on cycle. In response to a "enter sleep" indication in the DRX on cycle, the DRX on cycle may transition to a DRX off cycle. In response to data packet transmission within the DRX on cycle, a timer may be activated or reactivated, and the extended DRX on cycle may be further extended until the timer expires. A DRX cycle with an extended DRX on cycle may include a long DRX cycle and an associated short DRX cycle, wherein the long DRX cycle and the associated short DRX cycle are configured as a DRX configuration set. The DRX configuration set may include at least two levels, wherein the outer layer corresponds to the long DRX cycle and the inner layer corresponds to the associated short DRX cycle. In this configuration, transmission of at least one control information or data is performed only during the on period of the associated short DRX cycle.

[0127] In one aspect, in response to a "go to sleep" indication in an on period of the associated short DRX cycle, a subsequent short DRX cycle may be turned off. In another aspect, a first timer of a long DRX cycle may be used to extend an on period of the long DRX cycle, and a second timer of a short DRX cycle may be used to extend an on period of the short DRX cycle. Further details are provided below.

[0128] The arrival time of XR / CG traffic is not certain, but has a jitter value. According to the research of 3GPP Technical Report (TR) 38.838, the jitter follows a truncated Gaussian distribution with a range of [-4ms, 4ms] or [-5ms, 5ms]. This means that XR / CG traffic may arrive 4ms / 5ms before or after the start of the open period. In order to solve the impact of jitter, the most direct way is to extend the open period to cover all possible XR / CG arrival times. Fig.13As shown, the on period is configured to start 4ms / 5ms earlier and / or end 4ms / 5ms later (by appropriately configuring drx-startoffset and drx-onDurationTimer). However, the UE needs to continuously monitor the PDCCH during the on period to check for traffic arrival, which will result in increased power consumption as the on period is extended. In order to reduce power consumption, an "enter sleep" indication (e.g., DRX command MAC CE, long DRX command MAC CE, or DCI-based PDCCH skip indication) can be used to request the UE to enter the off period after completing transmission during the on period. If XR / CG traffic arrives late during the on period, drx-InactivityTimer can be used to extend the on period to complete the transmission. The drx-InactivityTimer is activated / reactivated when a data packet is received during the on period, and the UE enters the off period when the drx-InactivityTimer expires.

[0129] Extending the on period only to receive one traffic burst within the on period may not be efficient. Another approach is to configure several short DRX cycles to cover the jitter. Fig.14 The long DRX cycle and the related short DRX cycle in the DRX configuration set can be configured as a DRX configuration set. The DRX configuration set can reuse the existing DRX configuration or be configured as a specific configuration for XR / CG services. The DRX configuration set can be a two-level DRX configuration, where the outer configuration is used to solve the traffic arrival jitter and the inner configuration is used to adapt to the traffic burst arrival and reduce the power consumption of PDCCH monitoring. The UE only needs to wake up during the relatively short on period of the inner DRX cycle to monitor the PDCCH.

[0130] For example, when the traffic mode of XR / CG is 60fps and the jitter is [-4ms,4ms], Fig.14The long DRX cycle in the inner DRX cycle can be configured as 16ms and the short DRX cycle can be configured as 2ms (i.e., the on period of the inner DRX cycle is 1ms). The number of short DRX cycles can be configured as 4 (i.e., drx-ShortCycleTimer=4) to cover the jitter of a traffic burst. In this configuration, when XR / CG traffic arrives during the off period of the inner DRX cycle, the maximum waiting time for transmission is 1ms. To further reduce power consumption, an "enter sleep" indication (e.g., DRX command MAC CE, long DRX command MAC CE, or DCI-based PDCCH skip indication) can be used to request the UE to enter the off period and turn off the subsequent short DRX cycle after completing the transmission in the on period. It should be noted that the "enter sleep" indication can be transmitted by the gNB (next generation base station) to the UE for downlink transmission (i.e., the gNB needs to know the end of the burst arrival) or by the UE to the gNB for uplink transmission (i.e., the UE needs to know the end of the burst arrival). If XR / CG traffic requires more than 1ms of radio resources for transmission, the start period of the outer XR / CG cycle and the inner DRX cycle can be extended to complete the data transmission. The drx-InactivityTimer of the outer DRX cycle can be used to extend the start period of the outer DRX cycle, and the drx-InactivityTimer of the inner DRX cycle can be used to extend the start period of the inner DRX cycle.

[0131] For video streams of XR / CG services, during the on period, a short DRX cycle or a different search space is configured to reduce the time of PDCCH (physical downlink control channel) monitoring. Specifically, the PDCCH monitoring period changes dynamically according to the search space set group (SSSG) switching indication. In particular, at least two search spaces are configured, one for sparse PDCCH monitoring and the other for dense PDCCH monitoring. Monitoring is performed with a first monitoring period during sparse PDCCH monitoring, and monitoring is performed with a second monitoring period during dense PDCCH monitoring, and the first monitoring period is greater than the second monitoring period. Sparse PDCCH monitoring can be configured when no traffic arrives, and dense PDCCH monitoring can be configured when traffic arrives. In response to the SSSG switching indication, sparse PDCCH monitoring can be changed to dense PDCCH monitoring, or dense PDCCH monitoring can be changed to sparse PDCCH monitoring.

[0132] For example, the SSSG switching indication may be used to configure dense PDCCH monitoring when traffic arrives, or to configure sparse PDCCH monitoring when traffic transmission is complete. In one aspect, in response to a PDCCH skip indication sent via layer 1 signaling or a "go to sleep" indication sent via higher layer signaling, subsequent PDCCH monitoring may be skipped. In another aspect, a timer may be configured during dense PDCCH monitoring, and when the timer expires, dense PDCCH monitoring may be switched to sparse PDCCH monitoring.

[0133] In one embodiment, the PDCCH monitoring period may be dynamically changed within the DRX on period. The DRX on period may be terminated by a PDCCH skip indication sent by layer 1 signaling or a "enter sleep" indication sent by higher layer signaling. Further details are provided below.

[0134] Fig.15 Another method of PDCCH (Physical Downlink Control Channel) periodic monitoring based on Search Space Set Group (SSSG) switching is shown. During the on period of the XR / CG cycle, the gNB (next generation base station) can dynamically adjust the UE's PDCCH monitoring period based on the SSSG switching indication. The gNB can configure two (or more) search spaces for the UE, one for sparse PDCCH monitoring and the other for dense PDCCH monitoring. During sparse PDCCH monitoring, the UE monitors PDCCH with a larger monitoring slot period (e.g., 2 or 4 slots). Sparse PDCCH monitoring can be configured for the UE when the on period of the XR / CG cycle begins. Especially when a longer period is configured to address traffic arrival jitter, it is likely that no traffic will arrive at the beginning of the on period. Sparse PDCCH monitoring is similar to a DRX configuration with a large period. The difference is that the SSSG switching is controlled by a physical layer indication (e.g., DCI), while the DRX cycle switching is controlled by an RRC message. SSSG switching can respond to traffic arrival faster than DRX cycle switching, and gNB can dynamically adjust the PDCCH monitoring period to reduce UE power consumption.

[0135] When traffic arrives, the gNB instructs the SSSG switch to adjust the PDCCH monitoring with a small monitoring slot period (e.g., 1 slot), so that the UE can receive the traffic in the related physical downlink shared channel (PDSCH) as soon as possible. After completing the traffic burst transmission in the on period, the gNB can send a PDCCH skip indication or a "go to sleep" indication to the UE to skip the subsequent PDCCH monitoring. Another way is to let the UE continue to monitor the PDCCH until the on period ends. After the off period ends, the gNB can instruct the UE to perform SSSG switching again to trigger sparse PDCCH monitoring. A timer can be configured to be used with the PDCCH skip indication. If a timer is configured, the UE can autonomously switch back to sparse PDCCH monitoring when the timer expires. The advantage of this approach is that the gNB can dynamically adjust the PDCCH monitoring period to achieve power saving for the UE.

[0136] Fig.16 Another PDCCH-based power saving configuration is shown in Figure 2. In this configuration, PDCCH skipping can be replaced by sparse PDCCH monitoring, which can monitor traffic even if it arrives within the PDCCH skipping interval. Fig.15 Similar to the mechanism in , when traffic arrives, the gNB instructs the SSSG to switch to configure the UE for dense PDCCH monitoring. When traffic transmission is completed, the gNB instructs the SSSG to switch to configure the UE for sparse PDCCH monitoring. This method sacrifices some power consumption in exchange for the ability to detect jittery traffic.

[0137] It should be noted that PDCCH-based energy saving can be combined with DRX-based energy saving to achieve better power saving effect. Fig.17 The combination of PDCCH-based energy saving and DRX-based energy saving is shown. During the DRX on period (i.e., gray rectangle), the gNB can dynamically adjust the PDCCH monitoring period. When the gNB determines that the traffic burst transmission is completed within the on period, it can end the on period by sending a PDCCH skip indication or a "go to sleep" indication. The UE can wake up again to monitor the PDCCH according to the time interval in the PDCCH skip indication.

[0138] Multimodal services supporting XR / CG:

[0139] Multiple DRX configurations for XR / CG services can be specified in the standard specification. Specifically, these multiple DRX configurations with different start offsets and different DRX cycles are configured so that only one can be activated at the same time. That is, the current DRX configuration is deactivated and another DRX configuration is activated. For uplink (UL) bursts, an indication can be used to notify the end of the UL burst. The indication may include a buffer status report (BSR) or a DRX switching media access control (MAC) control element (CE). Each of the multiple DRX configurations may have its own parameters, which include at least an on-cycle interval, an on-cycle extension, a long DRX cycle, a short DRX cycle, and a start offset. Further details are provided below.

[0140] For XR / CG applications, tactile and multimodal data (e.g., audio, video, and tactile data) may be delivered to the UE at a specific time. Therefore, each XR / CG traffic may include multiple flows, each of which may have its burst arrival period and corresponding arrival time.

[0141] like Fig.18 As shown, it is more efficient to configure multiple DRX cycles to accommodate XR traffic. In 3GPP TS38.331, the information element (IE) DRX-ConfigSecondaryGroup is used to configure relevant parameters of the second DRX group. However, the DRX-ConfigSecondaryGroup IE is only used for cells other than the first cell, and only drx-onDurationTimer (i.e., start cycle interval) and drx-InactivityTimer (i.e., start cycle extension) can be configured for the second DRX group. The DRX cycle, start offset and time slot offset of the second DRX group are the same as those of the first DRX group. Therefore, it is not suitable to reuse the DRX-ConfigSecondaryGroup IE to configure multiple video streams in XR / CG traffic, because multiple video streams may have different cycles and arrival times. Therefore, it is necessary to configure a DRX configuration with different start offsets and different DRX cycles for XR / CG traffic.

[0142] Note that if only one (active) DRX configuration can be activated at a time, a change request may be required to switch the DRX configuration. The gNB (or network) may pre-configure multiple DRX configurations for the UE, and the gNB may then activate one of the DRX configurations for the UE. The gNB may activate the DRX configuration by sending downlink control information (DCI) or MAC control element (CE) (e.g., DRX switch MAC CE). For UL bursts where the gNB may not know the end time of the UL burst (i.e., only the UE knows whether all UL bursts have been transmitted), the UE may send an indication (e.g., buffer status report (BSR), request DRX switch MAC CE, etc.) to the gNB to notify the end of the UL burst, and the gNB may then deactivate the current DRX configuration and activate another DRX configuration for the UE.

[0143] Table 5 below is an example of a secondary DRX configuration with its own on-cycle interval (i.e., drx-onDurationTimer), on-cycle extension (i.e., drx-InactivityTimer), long DRX cycle (i.e., drx-LongCycleStartOffset), short DRX cycle (i.e., drx-ShortCycle-r18), and start offset (i.e., drx-LongCycleStartOffset). As shown in Table 6, when DRX-ConfigSecondaryGroup-r18 is set in MAC-CellGroupConfig, the secondary DRX configuration can be configured for the multi-video stream scenario of Rel-18 XR / CG.

[0144] Table 5 -DRX-ConfigSecondaryGroup information element:

[0145]

[0146] Table 6 - MAC-CellGroupConfig information elements:

[0147]

[0148]

[0149] Support of multi-modal services through DRX and SPS / CG:

[0150] To support multimodal services, a DRX configuration, an SPS (semi-persistent scheduling) configuration, and a CG (configuration grant) configuration can be configured. That is, a DRX configuration for variable-size streams, an SPS configuration for downlink (DL) fixed-size streams, and a CG configuration for uplink (UL) fixed-size streams are configured for multimodal services. In these configurations, SPS / CG operation is independent of DRX operation. This means that SPS / CG resources can be arranged even during DRX off, and the UE is allowed to wake up during DRX off to receive / send data on SPS / CG resources.

[0151] When a multimodal service contains only one variable-size stream (e.g., video stream) and other fixed-size streams (e.g., audio and haptic feedback), the gNB (next generation base station) can configure one DRX configuration for the variable-size stream, one SPS configuration for the DL fixed-size stream, and one CG configuration for the UL fixed-size stream. SPS / CG are continuous scheduled resources with a fixed size for DL / UL transmission. SPS / CG operation is independent of DRX operation, which means that SPS / CG resources can be scheduled during DRX off and allow UEs to wake up during DRX off to receive / send data on SPS / CG resources. Fig.19 The DRX, SPS and CG configurations configured for multimodal services are shown.

[0152] Steps to configure DRX for UE:

[0153] Fig. 20 Shows the steps to configure DRX for a UE.

[0154] Step 1: The UE sends a Registration Request message to the gNB. The Registration Request message may include UE Assistance Information with UE preferred DRX parameters. The UE preferred DRX parameters may include preferredDRX-LongCycle, preferredDRX-InactivityTimer, preferredDRX-ShortCycle and / or preferredDRX-ShortCycleTimer.

[0155] NOTE 1: preferredDRX-LongCycle and / or preferredDRX-ShortCycle may include non-integer cycles of XR / CG traffic (e.g., 8.33ms, 11.11ms, 16.67ms, 33.33ms, etc.).

[0156] NOTE 2: UE support information is optional. Without this information, the AMF (Access and Mobility Management Function) can also determine the DRX parameters based on the traffic information received from the XR / CG application server.

[0157] Note 3: When the UE transmits multimodal data traffic, the UE support information may carry multiple sets of DRX parameters for the multimodal data traffic. These DRX parameters may include a set of preferredDRX-LongCycle, preferredDRX-InactivityTimer, preferredDRX-ShortCycle, preferredDRX-ShortCycleTimer, drx-StartOffset, etc.

[0158] Step 2: The gNB forwards the Registration Request message with the UE's preferred DRX parameters to the AMF.

[0159] Step 3: AMF determines whether the preferred DRX parameters are allowed. AMF replies with a Registration Accept message with the allowed DRX parameters.

[0160] NOTE 1: AMF may receive traffic information from XR / CG application server. Traffic information may include media codec, traffic burst size, traffic period, traffic rate, traffic jitter (e.g., mean and standard deviation of jitter distribution), number of consecutive packets, etc. AMF uses this information to determine the allowed DRX parameters.

[0161] NOTE 2: The AMF may reply with allowedDRX parameters for multiple DRX configurations.

[0162] NOTE 3: AMF may receive PDU aggregation information from Session Management Function (SMF) / Policy Control Function (PCF) and provide the information to gNB to configure DRX. The information may include the period of PDU aggregation (i.e., the start time of the first PDU and the end time of the last PDU), the size of PDU aggregation (e.g., the maximum or minimum size of PDU), the number of PDUs in the PDU aggregation (i.e., the number of IP packets in I / P / B frames), the QoS parameters of the PDU aggregation (e.g., the delay budget and error rate of the PDU aggregation), the arrival jitter of the PDUs in the PDU aggregation (e.g., the mean and standard deviation of the jitter distribution), etc.

[0163] Step 4: The gNB forwards the Registration Accept message to the UE. The allowed DRX parameters can be configured via an RRC message (e.g., RRCReconfiguration, RRCResume, or RRCSetup message).

[0164] NOTE 1: As described in Sections 3 and 5, the gNB can configure multiple DRX configurations for the UE.

[0165] NOTE 2: When multiple DRX configurations are configured, the gNB can activate one of the DRX configurations for the UE at a time. The gNB can activate the DRX configuration by sending an RRC message, MAC CE or DCI to the UE.

[0166] Step 5: The UE is configured with the allowed DRX parameters. The UE wakes up during the on period and transmits / receives data during the on period according to the method in Section 1-5.

[0167] Step 6: When UL traffic characteristics (e.g., traffic period, traffic burst size, traffic start / end time, traffic jitter, service type, etc.) change, the UE can request to update DRX parameters through RRC message, MAC CE or UCI. When multiple DRX configurations are configured, the UE can request to activate another DRX configuration by sending RRC message, MAC CE or UCI to the gNB.

[0168] Step 7: The gNB updates the DRX parameters through an RRC message (e.g., RRCReconfiguration, RRCResume, or RRCSetup message). When multiple DRX configurations are configured, the gNB can activate another DRX configuration for the UE by sending an RRC message, MAC CE, or DCI to the UE.

[0169] Please note that the above steps or procedure names (ie, registration process) are only an example of completing DRX configuration and should not be considered as a limitation of DRX configuration. The above DRX configuration may also be configured through other non-access stratum (NAS) or RRC processes.

[0170] The commercial benefits of some embodiments are as follows: 1. Solve problems in the prior art. 2. Realize DRX enhancement. 3. Save power consumption. 4. Support multimodal services. 5. Provide good communication performance. Some embodiments disclosed herein can be used by 5G-NR chip suppliers, V2X communication system developers, automobile manufacturers including cars, trains, trucks, buses, bicycles, motorcycles, helmets, etc., unmanned aerial vehicles (UAVs), smartphone manufacturers, public safety communication equipment manufacturers, AR / VR equipment manufacturers (for example, for games, conferences / seminars, educational purposes). Some embodiments disclosed herein are "technology / process" combinations in 3GPP specifications that can be used to create a final product. Some embodiments disclosed herein can be used in 5G NR unlicensed band communications. Some embodiments disclosed herein propose technical mechanisms.

[0171] The embodiment of the present application also provides a computer-readable storage medium for storing a computer program. The computer-readable storage medium enables a computer to execute the corresponding process implemented by the UE / BS in each method. For the sake of simplicity, it will not be described in detail.

[0172] The embodiment of the present application also provides a computer program product including computer program instructions. The computer program product enables a computer to execute the corresponding process implemented by the UE / BS in each method. For the sake of simplicity, it will not be described in detail.

[0173] The embodiment of the present application further provides a computer program. The computer program enables a computer to execute the corresponding process implemented by the UE / BS in each method. For the sake of simplicity, it will not be described in detail.

[0174] Although not shown in detail, any device or apparatus in the network may include at least one processor, a storage unit and a communication interface, wherein the processor unit, the storage unit and the communication interface are configured to perform the method of any aspect of the present invention. Further options and selections are described below.

[0175] The signal processing functions in the embodiments of the present invention, especially the signal processing functions of the gNB and the UE, can be implemented using a computing system or architecture known to those skilled in the art. The computing systems that can be used include desktops, laptops or handheld computing devices (PDAs, mobile phones, palmtops, etc.), hosts, servers, clients, or any other type of specific or general computing devices suitable for a given application or environment. The computing system may include one or more processors, which may be implemented by general or dedicated processing engines (such as microprocessors, microcontrollers, or other control modules).

[0176] The computing system may also include a main memory, such as a random access memory (RAM) or other dynamic memory, for storing information and instructions executed by the processor. The main memory may also be used to store temporary variables or other intermediate information while the processor executes instructions. The computing system may also include a read-only memory (ROM) or other static storage device for storing static information and instructions for the processor.

[0177] The computing system may also include information storage systems, such as media drives and removable storage interfaces. The media drive may include a drive or other mechanism that supports fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a tape drive, an optical drive, a CD or DVD read / write drive, etc. The storage medium may include a fixed or removable medium such as a hard disk, a floppy disk, a tape, an optical disk, a CD or a DVD, and the computer-readable storage medium may store specific software or data therein.

[0178] In alternative embodiments, the information storage system may include other similar components that allow computer programs or other instructions or data to be loaded into the computing system. For example, these components may include removable storage units and interfaces, such as program cartridges and cartridge interfaces, removable memory (e.g., flash memory or other removable storage modules) and storage slots, and other interfaces that allow software and data to be transferred from removable storage units to the computing system.

[0179] The computing system may also include a communication interface. The communication interface may be used to transfer software and data between the computing system and external devices. Examples of communication interfaces include modems, network interface cards (e.g., Ethernet cards), communication ports (e.g., USB ports), PCMCIA slots and cards, etc. The software and data transferred through the communication interface exist in the form of receivable signals, including electronic, electromagnetic, optical or other signals.

[0180] In this document, the terms "computer program product", "computer-readable medium", etc. may be generally used to refer to tangible media such as storage devices or storage units. These and other forms of computer-readable media may store one or more instructions for use by a processor to cause the processor to perform specified operations. These instructions are generally referred to as "computer program code" and, when executed, cause a computing system to perform the functions of embodiments of the present invention. Note that the code may directly cause a processor to perform specified operations, be compiled for execution, and / or be executed in conjunction with other software, hardware, and / or firmware elements.

[0181] Non-volatile computer readable media may include hard disks, CD-ROMs, optical storage devices, magnetic storage devices, read-only memories (ROMs), programmable read-only memories (PROMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), and flash memory. In software-implemented embodiments, the software may be stored in a computer readable medium and loaded into a computing system via a removable storage drive. The control module (software instructions or executable computer program code in this example) when executed on a processor in the computing system causes the processor to perform the functions described herein.

[0182] Furthermore, the innovative concept can be applied to any circuit in a network element that performs a signal processing function. For example, semiconductor manufacturers can employ the innovative concept in the design of a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or any other subsystem element.

[0183] It should be noted that, for the sake of clarity, the above description refers to an embodiment of a single processing logic. However, the innovative concept can also be implemented by a plurality of different functional units and processors to implement the signal processing functions. Therefore, references to specific functional units should be regarded as references to appropriate means for providing the described functions, rather than indicating a strict logical or physical structure or organization.

[0184] Various aspects of the invention may be implemented in any suitable form by hardware, software, firmware or any combination thereof. The invention may be implemented partially or completely as computer software running on one or more data processors and / or configurable module components (e.g., FPGA devices).

[0185] Therefore, the elements and components of the embodiments of the invention can be implemented in any suitable way physically, functionally and logically. In fact, the function can be implemented in a single unit, in multiple units, or as part of other functional units. Although the present invention has been described by some embodiments, it is not intended to be limited to the described form. On the contrary, the scope of the present invention is limited only by the appended claims. In addition, although some features seem to be described in connection with specific embodiments, those skilled in the art will recognize that the various features of the described embodiments can be combined according to the present invention.

[0186] The word "comprising" in a claim does not exclude the presence of other elements or steps. Furthermore, although individually listed, several means, elements or method steps may be implemented by a single unit or processor. Furthermore, although individual features may be included in different claims, these may be advantageously combined together and the inclusion in different claims does not imply that a combination of features cannot be achieved. Furthermore, the inclusion of a feature in a certain category of claims does not imply a limitation to that category but rather indicates that the feature is equally applicable to other claim categories.

[0187] The order of features in the claims does not imply that the features must be performed in this order. In particular, the order of steps in a method claim does not imply that the steps must be performed in this order. On the contrary, the steps may be performed in any suitable order. Furthermore, singular references do not exclude plural references. Thus, references to "a", "an", "first", "second" etc do not exclude a plurality.

[0188] While the present application has been described in terms of what are considered to be the most practical and preferred embodiments, it is to be understood that the application is not limited to the disclosed embodiments but is intended to cover various arrangements commensurate with the broadest interpretation of the appended claims.

Claims

1. A method for enabling a wireless communication device to access services provided by a wireless access network, characterized in that: include: A DRX cycle having a DRX on period for transmitting at least one control information or data and a DRX off period during which transmission is suspended is configured, and the DRX cycle is a specific DRX cycle having a non-integer duration.

2. The method according to claim 1, characterized in that: The specific DRX cycle is configured for a specific application scenario and is listed as a non-integer value in the information element.

3. The method according to claim 1, characterized in that The specific DRX cycle is obtained by combining an integer part of a DRX cycle listed in the information element and a possible fractional part listed in the information element.

4. The method according to claim 3, characterized in that The decimal part is a rational number.

5. The method according to claim 1, characterized in that The non-integer duration is 33.33, 16.67, 11.11 or 8.33 microseconds.

6. The method according to claim 1, characterized in that The specific DRX cycle is a short DRX cycle or a long DRX cycle.

7. The method according to claim 1, characterized in that The specific DRX cycle is a short DRX cycle, and a corresponding long DRX cycle is added in the information element, wherein the duration of the long DRX cycle is an integer multiple of the duration of the short DRX cycle.

8. A user equipment, characterized in that: include: a memory configured to store program instructions; a transceiver configured to transmit and receive data; And a processor, coupled to the memory and the transmitter, configured to call and run the program instructions stored in the memory, and cooperate with the memory to perform the method of any one of claims 1 to 7.

9. A base station BS, characterized in that: include: a memory configured to store program instructions; a transceiver configured to transmit and receive data; And a processor, coupled to the memory and the transmitter, configured to call and run the program instructions stored in the memory, and cooperate with the memory to perform the method of any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium, characterized in that: The device is configured to store a computer program, wherein the computer program enables a computer to execute the method of any one of claims 1 to 7.

11. A method for enabling a wireless communication device to access services provided by a wireless access network, characterized in that: include: The DRX cycle is configured with a DRX on period for transmitting at least one control information or data and a DRX off period during which transmission is suspended, and the DRX cycle is modified based on a burst arrival interval to eliminate a mismatch between the burst arrival interval and the DRX cycle.

12. The method according to claim 11, characterized in that The DRX cycle modifies the cycle by triggering an equation.

13. The method according to claim 12, characterized in that The DRX cycle is modified according to a cumulative difference between the burst arrival interval and the configured DRX cycle.

14. The method according to claim 13, characterized in that A difference between the burst arrival interval and the configured DRX cycle is less than 1.

15. The method according to claim 13, characterized in that The difference between the burst arrival interval and the configured DRX cycle is not less than 1.

16. The method according to claim 13, characterized in that The cumulative difference is normalized by a predetermined time interval.

17. The method according to claim 13, characterized in that The DRX cycle is configured as an integer less than or equal to the burst arrival interval.

18. The method according to claim 13, characterized in that The DRX cycle is configured as a real number.

19. The method according to claim 13, characterized in that The DRX cycle is configured by a short DRX cycle information element or a long DRX cycle information element.

20. The method according to claim 13, characterized in that A counter for the number of times the system frame number wraps around is added to the trigger equation.

21. The method according to claim 11, characterized in that A plurality of DRX configurations with the same cycle but different start offsets constitute one DRX configuration to eliminate the mismatch between the burst arrival interval and the DRX cycle.

22. The method according to claim 21, characterized in that The DRX timer for each of the multiple DRX configurations is configured separately.

23. The method according to claim 11, characterized in that The DRX cycle based on the burst arrival interval is provided by a user equipment and / or an application server to a base station to configure the DRX cycle.

24. A user equipment, characterized in that: include: a memory configured to store program instructions; a transceiver configured to transmit and receive data; and a processor, coupled to the memory and the transmitter, configured to call and run program instructions stored in the memory, and cooperate with the memory to execute the method of any one of claims 11 to 23.

25. A base station, characterized in that: include: a memory configured to store program instructions; a transceiver configured to transmit and receive data; and a processor, coupled to the memory and the transmitter, configured to call and run program instructions stored in the memory, and cooperate with the memory to execute the method of any one of claims 11 to 23.

26. A non-transitory computer-readable storage medium, characterized in that The device is configured to store a computer program, wherein the computer program enables a computer to execute the method of any one of claims 11 to 23.

Images