Device, method, and storage medium for providing extended reality service

Abstract

This device of a network node may comprise: a memory for storing instructions; and at least one processor. The instructions, when executed individually or collectively by the at least one processor, may instruct the device to: identify downlink data to be transmitted through a data session having a designated quality of service (QOS) profile; determine whether the downlink data is to be transmitted within an on-duration according to the cycle of short discontinuous reception (DRX) initiated when an inactivity timer of DRX configured for a terminal expires; adjust, upon determining that the downlink data is to be transmitted within the on-duration, the length of the on-duration for the DRX on the basis of channel information of a channel between the terminal and the network node; adjust the buffer size of the network node on the basis of the adjusted length of the on-duration; and transmit the downlink data to the terminal on the basis of the adjusted buffer size.

Description

Device, method, and storage medium for providing extended reality services

[0001] The descriptions below relate to devices, methods, and storage media for providing extended reality services.

[0002] To provide an enhanced user experience, electronic devices are being developed that provide extended reality services that display computer-generated information in conjunction with external objects in the real world or virtual objects in the virtual world. The electronic devices may include wearable devices that can be worn by a user. For example, the electronic devices may include user equipment, terminals, AR glasses, VR glasses, and / or head-mounted devices (HMDs) (e.g., video see-through (VST) HMDs, optical see-through (OST) HMDs).

[0003] A device of a network node may include a memory storing instructions. The device may include at least one processor. The instructions, when individually or collectively executed by the at least one processor, may cause the device to identify downlink data to be transmitted over a data session having a designated quality of service (QoS) profile. The instructions, when individually or collectively executed by the at least one processor, may cause the device to determine whether the downlink data is to be transmitted within an on-duration according to a cycle of a short DRX (discontinuous reception) that is initiated when an inactivity timer of a DRX configured for a terminal expires. The instructions, when individually or collectively executed by the at least one processor, may cause the device to adjust a length of the on-interval for the DRX based on channel information of a channel between the terminal and the network node, upon determining that the downlink data is to be transmitted within the on-interval. The instructions, when individually or collectively executed by the at least one processor, may cause the device to adjust a buffer size of the network node based on the adjusted length of the on-interval, upon determining that the downlink data is to be transmitted within the on-interval. The instructions, when individually or collectively executed by the at least one processor, may cause the device to transmit the downlink data to the terminal based on the adjusted buffer size, upon determining that the downlink data is to be transmitted within the on-interval.

[0004] A terminal may include at least one transceiver. The terminal may include a memory storing instructions and including one or more storage media. The terminal may include at least one processor including a processing circuit. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to identify uplink data to be transmitted over a data session having a designated quality of service (QoS) profile. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to determine whether the uplink data is to be transmitted within an on-duration according to a cycle of a short DRX (discontinuous reception) that is initiated when an inactivity timer of the DRX expires. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to adjust a length of the on-interval for the DRX as the uplink data is determined to be transmitted within the on-interval. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to adjust a buffer size of the terminal based on the adjusted length of the on-interval as the uplink data is determined to be transmitted within the on-interval.The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to transmit, to the network node, a signal requesting resources for transmitting the uplink data based on the adjusted buffer size within the on-interval having the adjusted length according to the cycle of the short DRX, upon determining that the uplink data is to be transmitted within the on-interval.

[0005] A method performed by a network node may include identifying downlink data to be transmitted over a data session having a designated quality of service (QoS) profile. The method may include determining whether the downlink data is to be transmitted within an on-duration according to a cycle of a short DRX (discontinuous reception) that is initiated when an inactivity timer of a DRX configured for a terminal expires. The method may include adjusting a length of the on-duration for the DRX based on channel information of a channel between the terminal and the network node, upon determining that the downlink data is to be transmitted within the on-duration. The method may include adjusting a buffer size of the network node based on the adjusted length of the on-duration, upon determining that the downlink data is to be transmitted within the on-duration. The method may include an operation of transmitting the downlink data to the terminal based on the adjusted buffer size, upon determining that the downlink data is to be transmitted within the on-interval.

[0006] A non-transitory computer-readable storage medium may store one or more programs comprising instructions that, when individually or collectively executed by at least one processor of a network node, cause the network node to identify downlink data to be transmitted over a data session having a designated quality of service (QoS) profile. The non-transitory computer-readable storage medium may store one or more programs comprising instructions that, when individually or collectively executed by the at least one processor, cause the network node to determine whether the downlink data is to be transmitted within an on-duration according to a cycle of a short DRX (discontinuous reception) that is initiated when an inactivity timer of a DRX configured for a terminal expires. The non-transitory computer-readable storage medium may store one or more programs including instructions that, when individually or collectively executed by the at least one processor, cause the network node to adjust a length of the on-interval for the DRX based on channel information of a channel between the terminal and the network node when the downlink data is determined to be transmitted within the on-interval. The non-transitory computer-readable storage medium may store one or more programs including instructions that, when individually or collectively executed by the at least one processor, cause the network node to adjust a buffer size of the network node based on the adjusted length of the on-interval when the downlink data is determined to be transmitted within the on-interval.The non-transitory computer-readable storage medium may store one or more programs including instructions that, when individually or collectively executed by the at least one processor, cause the network node to transmit the downlink data to the terminal based on the adjusted buffer size when the network node determines that the downlink data is to be transmitted within the on-interval.

[0007] Figure 1 illustrates an example of a wireless communication system.

[0008] Figure 2a illustrates an example of a perspective view of a terminal.

[0009] FIG. 2b illustrates an example of one or more hardware devices arranged within a terminal.

[0010] Figures 3a and 3b illustrate an example of the appearance of a terminal.

[0011] Figure 4 shows an example of the functional configuration of an electronic device.

[0012] Figure 5 illustrates an example of how to render data for an XR service on an XR (extended reality) device and an XR server.

[0013] Figure 6 illustrates an example of DRX (discontinuous reception).

[0014] FIG. 7a illustrates an example of an operation flow for a method of transmitting downlink data for an XR service based on adaptive DRX.

[0015] Figure 7b illustrates an example of how to adjust the buffer size in adaptive DRX.

[0016] Figure 8 illustrates an example of a protocol stack for XR data.

[0017] Figure 9 illustrates an example of an operational flow for a method in which a network node transmits downlink data based on adaptive DRX.

[0018] Figure 10 illustrates an example of an operation flow for a method in which a terminal transmits uplink data based on adaptive DRX.

[0019] The terms used in this disclosure are used only to describe specific embodiments and may not be intended to limit the scope of other embodiments. The singular expression may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by those of ordinary skill in the art described in this disclosure. Terms defined in general dictionaries among the terms used in this disclosure may be interpreted as having the same or similar meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in this disclosure. In some cases, even if a term is defined in this disclosure, it cannot be interpreted to exclude embodiments of the present disclosure.

[0020] The various embodiments of the present disclosure described below illustrate a hardware-based approach as an example. However, since the various embodiments of the present disclosure include techniques utilizing both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0021] In the following description, terms referring to signals (e.g., packet, message, signal, information, signaling), terms referring to resources (e.g., section, symbol, slot, subframe, radio frame, subcarrier, RE (resource element), RB (resource block), BWP (bandwidth part), band, spectrum), terms for operational states (e.g., step, operation, procedure), terms referring to data (e.g., packet, message, user stream, information, bit, symbol, codeword), terms referring to channels, terms referring to network entities (distributed unit (DU), radio unit (RU), central unit (CU), control plane (CU-CP), user plane (CU-UP), open radio access network (O-RAN) DU (O-DU), O-RAN RU (O-RU), Terms such as O-CU (O-RAN CU), O-CU-UP (O-RAN CU-CP), O-CU-CP (O-RAN CU-CP)), referring to components of the device, are examples for convenience of explanation. Therefore, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used. In addition, terms such as '... part', '... device', '... object', '... body', etc. used below may mean at least one shape structure or a unit that processes a function.

[0022] In addition, in the present disclosure, expressions such as "more than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled, but this is merely a description for expressing an example and does not exclude descriptions such as "more than" or "less than." A condition described as "more than" may be replaced with "more than," a condition described as "less than" may be replaced with "less than," and a condition described as "more than and less than" may be replaced with "more than and less than." In addition, hereinafter, "A" to "B" mean at least one of the elements from A (including A) to B (including B). hereinafter, "C" and / or "D" mean at least one of "C" or "D," that is, including {"C", "D", "C" and "D"}. hereinafter, the meaning of "about E" may be replaced with a value within a margin of error of ±5% or ±10% based on E.

[0023] Although this disclosure describes embodiments using terminology used in certain communication standards (e.g., 3rd Generation Partnership Project (3GPP)), this is merely an example for illustrative purposes. Embodiments of this disclosure can also be applied to other communication and broadcasting systems.

[0024] Figure 1 illustrates an example of a wireless communication system.

[0025] Referring to FIG. 1, FIG. 1 illustrates a base station (110) and a terminal (120) as some of the nodes utilizing a wireless channel in a wireless communication system. Although FIG. 1 illustrates only one base station, the wireless communication system may further include other base stations identical or similar to the base station (110).

[0026] The base station (110) is a network infrastructure that provides wireless access to the terminal (120). The base station (110) has coverage defined based on the distance at which a signal can be transmitted. In addition to the base station, the base station (110) may be referred to as an 'access point (AP)', 'eNodeB (eNB)', '5th generation node', 'next generation nodeB (gNB)', 'wireless point', 'transmission / reception point (TRP)', 'network node', or other terms having equivalent technical meanings.

[0027] The terminal (120) is a device used by a user and communicates with the base station (110) via a wireless channel. The link from the base station (110) to the terminal (120) is referred to as a downlink (DL), and the link from the terminal (120) to the base station (110) is referred to as an uplink (UL). In addition, although not shown in FIG. 1, the terminal (120) and another terminal may communicate with each other via a wireless channel. In this case, the link between the terminal (120) and another terminal (device-to-device link, D2D) is referred to as a sidelink, and the sidelink may be used interchangeably with the PC5 interface. In some other embodiments, the terminal (120) may be operated without the involvement of a user. In one embodiment, the terminal (120) is a device that performs machine type communication (MTC) and may not be carried by the user. Additionally, according to one embodiment, the terminal (120) may be an NB (narrowband)-IoT (internet of things) device.

[0028] The terminal (120) may be referred to as a terminal, or other terms such as 'user equipment (UE),' 'customer premises equipment (CPE),' 'mobile station,' 'subscriber station,' 'remote terminal,' 'wireless terminal,' 'electronic device,' or 'user device,' or other terms having equivalent technical meanings.

[0029] The base station (110) and the terminal (120) can perform beamforming. The base station (110) and the terminal (120) can transmit and receive wireless signals in a relatively low frequency band (e.g., FR 1 (frequency range 1) of NR). In addition, the base station (110) and the terminal (120) can transmit and receive wireless signals in a relatively high frequency band (e.g., FR 2 (or, FR 2-1, FR 2-2, FR 2-3), FR 3 of NR), millimeter wave (mmWave) band (e.g., 28 GHz, 30 GHz, 38 GHz, 60 GHz)). To improve channel gain, the base station (110) and the terminal (120) can perform beamforming. Here, the beamforming can include transmission beamforming and reception beamforming. The base station (110) and the terminal (120) can impart directionality to the transmitted or received signal. To this end, the base station (110) and the terminal (120) can select serving beams through a beam search or beam management procedure. After the serving beams are selected, subsequent communication can be performed through resources that have a QCL relationship with the resource that transmitted the serving beams.

[0030] If large-scale characteristics of a channel carrying a symbol on a first antenna port can be inferred from a channel carrying a symbol on a second antenna port, the first antenna port and the second antenna port can be evaluated to have a QCL relationship. For example, the large-scale characteristics may include at least one of delay spread, Doppler spread, Doppler shift, average gain, average delay, and a spatial receiver parameter.

[0031] Although both the base station (110) and the terminal (120) are described as performing beamforming in FIG. 1, the embodiments of the present disclosure are not necessarily limited thereto. In some embodiments, the terminal may or may not perform beamforming. Furthermore, the base station may or may not perform beamforming. That is, either only one of the base station and the terminal may perform beamforming, or neither the base station nor the terminal may perform beamforming.

[0032] In the present disclosure, a beam refers to a spatial flow of a signal in a wireless channel, and is formed by one or more antennas (or antenna elements), and this forming process may be referred to as beamforming. Beamforming may include at least one of analog beamforming and digital beamforming (e.g., precoding). Reference signals transmitted based on beamforming may include, for example, a demodulation-reference signal (DM-RS), a channel state information-reference signal (CSI-RS), a synchronization signal / physical broadcast channel (SS / PBCH), and a sounding reference signal (SRS). In addition, as a configuration for each reference signal, an IE such as a CSI-RS resource or an SRS-resource may be used, and this configuration may include information associated with the beam. Information associated with a beam may mean whether the configuration (e.g., a CSI-RS resource) uses the same spatial domain filter as another configuration (e.g., another CSI-RS resource within the same CSI-RS resource set) or a different spatial domain filter, or whether it is quasi-co-located (QCL) with a reference signal, and if so, what type it is (e.g., QCL type A, B, C, D).

[0033] In the past, in communication systems with relatively large cell radius of base stations, each base station was installed to include the functions of a digital processing unit (or distributed unit (DU)) and a radio frequency (RF) processing unit (or radio unit (RU)). However, as higher frequency bands are used in 4G (4th generation) and / or subsequent communication systems (e.g., 5G) and the cell coverage of base stations decreases, the number of base stations to cover a specific area has increased. The burden of installation costs on operators for installing base stations has also increased. In order to minimize the installation cost of base stations, a structure has been proposed in which the DU and RU of a base station are separated, one or more RUs are connected to one DU via a wired network, and one or more RUs are geographically distributed to cover a specific area.

[0034] For example, network entities according to a distributed deployment may include a digital unit (DU) and a radio unit (RU) (or a massive multiple input multiple output (MMU) unit). For example, the network entities may be connected via a fronthaul. Unlike the backhaul between a base station and a core network, the fronthaul refers to entities (e.g., DU, RU) between a wireless LAN and a base station. Although a fronthaul structure between a DU and a single RU is exemplified, this is merely for convenience of description and the present disclosure is not limited thereto. In other words, embodiments of the present disclosure can also be applied to a fronthaul structure between a single DU and a plurality of RUs. For example, embodiments of the present disclosure can be applied to a fronthaul structure between a single DU and two RUs. Furthermore, embodiments of the present disclosure can also be applied to a fronthaul structure between a single DU and three RUs.

[0035] For example, the base station (110) may include a DU and an RU. The fronthaul between the DU and the RU may be operated via an Fx interface. For the operation of the fronthaul, an interface such as an enhanced common public radio interface (eCPRI) or radio over ethernet (ROE) may be used. Depending on the implementation example, the DU may be referred to as a baseband unit (BBU), a digital BBU, a baseband digital unit, a digital processing unit, a digital processing circuit, a baseband processing circuit, a baseband processing unit, and / or equivalent technical terms in addition to a DU (digital unit). Depending on the implementation example, the RU may be referred to as a remote unit, a radio demote head (RRH), a radio processing circuit, a radio processing unit, an antenna integrated radio, an air radio device, an air scale communication device, a radio device, a radio communication device, and / or equivalent technical terms in addition to the RU (radio unit). In addition, depending on the implementation example, although a network entity connected to a DU in the present disclosure is described as an RU, it is to be understood that a massive multiple input multiple output (MMU) unit may be connected to and used with the DU instead of the RU.

[0036] As communications technology advances, mobile data traffic increases, significantly increasing the bandwidth requirements for the fronthaul between the digital unit and the radio unit. In deployments such as C-RAN (centralized / cloud radio access network), the DU performs functions for the packet data convergence protocol (PDCP), radio link control (RLC), media access control (MAC), and physical layer (PHY), while the RU can be implemented to perform additional functions for the PHY layer in addition to its radio frequency (RF) functions.

[0037] A DU may be responsible for upper layer functions of a wireless network. For example, a DU may perform functions of a MAC layer and a part of a PHY layer. Here, a part of the PHY layer refers to functions performed at a higher level among the functions of the PHY layer, and may include, for example, channel encoding (or channel decoding), scrambling (or descrambling), modulation (or demodulation), and layer mapping (or layer demapping). In one embodiment, if a DU complies with the O-RAN standard, it may be referred to as an O-DU (O-RAN DU). If necessary, a DU may be represented by being replaced with a first network entity for a base station (e.g., gNB) in embodiments of the present disclosure.

[0038] An RU may be responsible for lower layer functions of a wireless network. For example, an RU may perform a part of a PHY layer, an RF function. Here, a part of the PHY layer refers to functions of the PHY layer that are performed at a relatively lower level than a DU, and may include, for example, iFFT transform (or FFT transform), CP insertion (CP removal), and digital beamforming. An RU may be referred to as an 'access unit (AU)', an 'access point (AP)', a 'transmission / reception point (TRP)', a 'remote radio head (RRH)', a 'radio unit (RU)', or other terms having equivalent technical meanings. In one embodiment, when an RU complies with the O-RAN standard, it may be referred to as an O-RU (O-RAN RU). An RU may be replaced with a second network entity for a base station (e.g., gNB) in embodiments of the present disclosure, as needed.

[0039] In the above example, the base station (110) is described as including a DU and an RU, but the embodiments of the present disclosure are not limited thereto. The base station (110) according to the embodiments may be implemented in a distributed deployment according to a centralized unit (CU) configured to perform functions of upper layers of an access network (e.g., packet data convergence protocol (PDCP), radio resource control (RRC)) and a distributed unit (DU) configured to perform functions of lower layers. For example, the digital unit (DU) may be implemented by separating it into a centralized unit (CU) and a distributed unit (DU). Between a core (e.g., 5G core (5GC) or next generation core (NGC)) network and a radio network (RAN), the base station (110) may be implemented in a structure in which a centralized unit (CU), a distributed unit (DU), and a radio unit (RU) are arranged in that order. The interface between the CU (centralized unit) and the DU (distributed unit) can be referred to as the F1 interface.

[0040] A centralized unit (CU) may be connected to one or more distributed units (DUs) and may be responsible for functions at a higher layer than the distributed units (DUs). For example, the CU may be responsible for functions at the radio resource control (RRC) and packet data convergence protocol (PDCP) layers, while the DU and RU may be responsible for functions at lower layers. The DU may perform some functions (high PHY) of the radio link control (RLC), media access control (MAC), and physical (PHY) layers, while the RU may be responsible for the remaining functions (low PHY) of the PHY layer. In addition, for example, a digital unit (DU) may be included in a distributed unit (DU) depending on the implementation of a distributed deployment of the base station. Hereinafter, unless otherwise defined, the operations of DU (digital unit) and RU are described, but various embodiments of the present disclosure can be applied to both a base station arrangement including a CU and an arrangement in which the DU is directly connected to the core network (i.e., a base station in which the CU and DU are integrated into one entity (e.g., an NG-RAN node)).

[0041] Figure 2a illustrates an example of a perspective view of a terminal. Figure 2b illustrates an example of one or more hardware components arranged within the terminal.

[0042] According to one embodiment, the terminal (120) may have the form of glasses that are wearable on a body part of the user (e.g., head). For example, the terminal (120) may be referred to as a wearable device. The terminal (120) of FIGS. 2A and 2B may be an example of the terminal (120) of FIG. 1. The terminal (120) may include a head-mounted display (HMD). For example, the housing of the terminal (120) may include a flexible material, such as rubber and / or silicone, that is configured to fit closely to a portion of the user's head (e.g., a portion of the face surrounding both eyes). For example, the housing of the terminal (120) may include one or more straps that are capable of being twined around the user's head, and / or one or more temples that are detachably attachable to the ears of the head.

[0043] Referring to FIG. 2A, according to one embodiment, a terminal (120) may include at least one display (250) and a frame (200) supporting at least one display (250).

[0044] According to one embodiment, the terminal (120) may be worn on a part of the user's body. The terminal (120) may provide extended reality to the user wearing the terminal (120). For example, the extended reality may include augmented reality (AR), virtual reality (VR), or mixed reality (MR) that combines augmented reality and virtual reality. For example, the terminal (120) may display a virtual reality image provided from at least one optical device (282, 284) of FIG. 2B on at least one display (250) in response to a user's designated gesture acquired through the motion recognition cameras (260-2, 260-3) of FIG. 2B.

[0045] According to one embodiment, at least one display (250) may provide visual information to a user. For example, at least one display (250) may include a transparent or translucent lens. At least one display (250) may include a first display (250-1) and / or a second display (250-2) spaced apart from the first display (250-1). For example, the first display (250-1) and the second display (250-2) may be positioned at positions corresponding to the user's left and right eyes, respectively.

[0046] Referring to FIG. 2B, at least one display (250) can provide the user with visual information transmitted from external light and other visual information distinct from the visual information through a lens included in the at least one display (250). The lens can be formed based on at least one of a Fresnel lens, a pancake lens, or a multi-channel lens. For example, at least one display (250) can include a first surface (231) and a second surface (232) opposite to the first surface (231). A display area can be formed on the second surface (232) of the at least one display (250). When the user wears the terminal (120), external light can be transmitted to the user by being incident on the first surface (231) and transmitted through the second surface (232). As another example, at least one display (250) can display an augmented reality image combined with a virtual reality image provided from at least one optical device (282, 284) on a real screen transmitted through external light, in a display area formed on the second surface (232).

[0047] In one embodiment, at least one display (250) may include at least one waveguide (233, 234) that diffracts light emitted from at least one optical device (282, 284) and transmits the diffracted light to a user. The at least one waveguide (233, 234) may be formed based on at least one of glass, plastic, or polymer. A nano-pattern may be formed on at least a portion of the exterior or interior of the at least one waveguide (233, 234). The nano-pattern may be formed based on a grating structure having a polygonal and / or curved shape. Light incident on one end of the at least one waveguide (233, 234) may be propagated to the other end of the at least one waveguide (233, 234) by the nano-pattern. At least one waveguide (233, 234) may include at least one diffractive element (e.g., a diffractive optical element (DOE), a holographic optical element (HOE)) and at least one reflective element (e.g., a reflective mirror). For example, at least one waveguide (233, 234) may be arranged within the terminal (120) to guide a screen displayed by at least one display (250) to the user's eyes. For example, the screen may be transmitted to the user's eyes based on total internal reflection (TIR) ​​occurring within the at least one waveguide (233, 234).

[0048] The terminal (120) can analyze an object included in a real image collected through a shooting camera (260-4), combine a virtual object corresponding to an object to be provided with augmented reality among the analyzed objects, and display the virtual object on at least one display (250). The virtual object can include at least one of text and an image regarding various information related to the object included in the real image. The terminal (120) can analyze the object based on a multi-camera such as a stereo camera. For the object analysis, the terminal (120) can perform spatial recognition (e.g., simultaneous localization and mapping (SLAM)) using a multi-camera and / or time-of-flight (ToF). A user wearing the terminal (120) can view an image displayed on at least one display (250).

[0049] According to one embodiment, the frame (200) may be formed as a physical structure that allows the terminal (120) to be worn on the user's body. According to one embodiment, the frame (200) may be configured so that, when the user wears the terminal (120), the first display (250-1) and the second display (250-2) can be positioned corresponding to the user's left and right eyes. The frame (200) may support at least one display (250). For example, the frame (200) may support the first display (250-1) and the second display (250-2) to be positioned corresponding to the user's left and right eyes.

[0050] Referring to FIG. 2A, the frame (200) may include a region (220) that at least partially contacts a part of the user's body when the user wears the terminal (120). For example, the region (220) of the frame (200) that contacts a part of the user's body may include a region that contacts a part of the user's nose, a part of the user's ear, and a part of the side of the user's face that the terminal (120) touches. According to one embodiment, the frame (200) may include a nose pad (210) that contacts a part of the user's body. When the terminal (120) is worn by the user, the nose pad (210) may contact a part of the user's nose. The frame (200) may include a first temple (204) and a second temple (205) that contact a part of the user's body that is distinct from the part of the user's body.

[0051] For example, the frame (200) may include a first rim (201) that surrounds at least a portion of the first display (250-1), a second rim (202) that surrounds at least a portion of the second display (250-2), a bridge (203) that is disposed between the first rim (201) and the second rim (202), a first pad (211) that is disposed along a portion of the edge of the first rim (201) from one end of the bridge (203), a second pad (212) that is disposed along a portion of the edge of the second rim (202) from the other end of the bridge (203), a first temple (204) that extends from the first rim (201) and is fixed to a portion of the wearer's ear, and a second temple (205) that extends from the second rim (202) and is fixed to a portion of the ear opposite the ear. The first pad (211) and the second pad (212) may be in contact with a portion of the user's nose, and the first temple (204) and the second temple (205) may be in contact with a portion of the user's face and a portion of the user's ear. The temples (204, 205) may be rotatably connected to the rim through the hinge units (206, 207) of FIG. 2B. The first temple (204) may be rotatably connected to the first rim (201) through the first hinge unit (206) disposed between the first rim (201) and the first temple (204). The second temple (205) may be rotatably connected to the second rim (202) through the second hinge unit (207) disposed between the second rim (202) and the second temple (205). According to one embodiment, the terminal (120) can identify an external object (e.g., a user's fingertip) touching the frame (200) and / or a gesture performed by the external object by using a touch sensor, a grip sensor, and / or a proximity sensor formed on at least a portion of a surface of the frame (200).

[0052] According to one embodiment, the terminal (120) may include hardwares that perform various functions (e.g., hardwares to be described later based on the block diagram of FIG. 4). For example, the hardwares may include a battery module (270), an antenna module (275), at least one optical device (282, 284), speakers (e.g., speakers 255-1, 255-2), a microphone (e.g., microphones 265-1, 265-2, 265-3), a light-emitting module (not shown), and / or a printed circuit board (PCB) (290) (e.g., a printed circuit board). The various hardwares may be arranged within the frame (200).

[0053] According to one embodiment, the microphones (e.g., microphones 265-1, 265-2, 265-3) of the terminal (120) may be arranged on at least a portion of the frame (200) to acquire sound signals. A first microphone (265-1) arranged on the bridge (203), a second microphone (265-2) arranged on the second rim (202), and a third microphone (265-3) arranged on the first rim (201) are illustrated in FIG. 2B, but the number and arrangement of the microphones (265) are not limited to the embodiment of FIG. 2B. When the number of microphones (265) included in the terminal (120) is two or more, the terminal (120) may identify the direction of the sound signal by using a plurality of microphones arranged on different portions of the frame (200).

[0054] According to one embodiment, at least one optical device (282, 284) may project a virtual object onto at least one display (250) to provide various image information to a user. For example, at least one optical device (282, 284) may be a projector. At least one optical device (282, 284) may be disposed adjacent to at least one display (250) or may be included within at least one display (250) as a part of at least one display (250). According to one embodiment, the terminal (120) may include a first optical device (282) corresponding to a first display (250-1) and a second optical device (284) corresponding to a second display (250-2). For example, at least one optical device (282, 284) may include a first optical device (282) disposed at an edge of a first display (250-1) and a second optical device (284) disposed at an edge of a second display (250-2). The first optical device (282) may transmit light to a first waveguide (233) disposed on the first display (250-1), and the second optical device (284) may transmit light to a second waveguide (234) disposed on the second display (250-2).

[0055] In one embodiment, the camera (260) may include a recording camera (260-4), an eye tracking camera (ET CAM) (260-1), and / or a motion recognition camera (260-2, 260-3). The recording camera (260-4), the eye tracking camera (260-1), and the motion recognition cameras (260-2, 260-3) may be positioned at different locations on the frame (200) and may perform different functions. The eye tracking camera (260-1) may output data indicating the position or gaze of the eyes of a user wearing the terminal (120). For example, the terminal (120) may detect the gaze from an image including the user's pupils obtained through the eye tracking camera (260-1). The terminal (120) can identify an object (e.g., a real object and / or a virtual object) focused on by the user using the user's gaze acquired through the gaze tracking camera (260-1). The terminal (120) that has identified the focused object can execute a function (e.g., gaze interaction) for interaction between the user and the focused object. The terminal (120) can express a part corresponding to the eye of an avatar representing the user in a virtual space using the user's gaze acquired through the gaze tracking camera (260-1). The terminal (120) can render an image (or screen) displayed on at least one display (250) based on the position of the user's eyes. For example, the visual quality of a first area related to the gaze within the image and the visual quality (e.g., resolution, brightness, saturation, grayscale, PPI) of a second area distinguished from the first area may be different from each other. The terminal (120) can obtain an image having visual quality of a first area matching the user's line of sight and visual quality of a second area using foveated rendering.For example, if the terminal (120) supports an iris recognition function, user authentication can be performed based on iris information acquired using the gaze tracking camera (260-1). An example in which the gaze tracking camera (260-1) is positioned toward the user's right eye is illustrated in FIG. 2B, but the embodiment is not limited thereto, and the gaze tracking camera (260-1) may be positioned solely toward the user's left eye, or toward both eyes.

[0056] In one embodiment, the capturing camera (260-4) can capture an actual image or background to be aligned with a virtual image to implement augmented reality or mixed reality content. The capturing camera (260-4) can be used to acquire a high-resolution image based on HR (high resolution) or PV (photo video). The capturing camera (260-4) can capture an image of a specific object existing at a location viewed by the user and provide the image to at least one display (250). The at least one display (250) can display a single image in which information about an actual image or background including the image of the specific object acquired using the capturing camera (260-4) is superimposed with a virtual image provided through at least one optical device (282, 284). The terminal (120) can compensate for depth information (e.g., the distance between the terminal (120) and an external object acquired through a depth sensor) using the image acquired through the capturing camera (260-4). The terminal (120) can perform object recognition through an image acquired using the capturing camera (260-4). The terminal (120) can perform a function of focusing on an object (or subject) in an image (e.g., auto focus) and / or an optical image stabilization (OIS) function (e.g., hand shake prevention function) using the capturing camera (260-4). The terminal (120) can perform a pass-through function to display an image acquired through the capturing camera (260-4) by overlapping at least a portion of a screen representing a virtual space on at least one display (250). In one embodiment, the capturing camera (260-4) can be disposed on a bridge (203) disposed between the first rim (201) and the second rim (202).

[0057] The gaze tracking camera (260-1) can implement more realistic augmented reality by tracking the gaze of a user wearing the terminal (120) and matching the user's gaze with visual information provided to at least one display (250). For example, when the terminal (120) looks straight ahead, the terminal (120) can naturally display environmental information related to the user's front at a location where the user is located on at least one display (250). The gaze tracking camera (260-1) can be configured to capture an image of the user's pupil to determine the user's gaze. For example, the gaze tracking camera (260-1) can receive gaze detection light reflected from the user's pupil and track the user's gaze based on the position and movement of the received gaze detection light. In one embodiment, the gaze tracking camera (260-1) can be positioned at positions corresponding to the user's left and right eyes. For example, the gaze tracking camera (260-1) may be positioned within the first rim (201) and / or the second rim (202) to face the direction in which the user wearing the terminal (120) is located.

[0058] The motion recognition camera (260-2, 260-3) can recognize the movement of the user's entire body, such as the user's torso, hand, or face, or a part of the body, and thereby provide a specific event on a screen provided on at least one display (250). The motion recognition camera (260-2, 260-3) can recognize the user's motion (gesture recognition), obtain a signal corresponding to the motion, and provide a display corresponding to the signal on at least one display (250). The processor can identify the signal corresponding to the motion, and perform a designated function based on the identification. The motion recognition camera (260-2, 260-3) can be used to perform a spatial recognition function using SLAM and / or a depth map for 6 degrees of freedom pose (6 dof pose). The processor can perform a gesture recognition function and / or an object tracking function using the motion recognition camera (260-2, 260-3). In one embodiment, the motion recognition cameras (260-2, 260-3) may be positioned on the first rim (201) and / or the second rim (202).

[0059] The camera (260) included in the terminal (120) is not limited to the above-described gaze tracking camera (260-1) and motion recognition cameras (260-2, 260-3). For example, the terminal (120) may identify an external object included in the FoV using a camera positioned toward the user's FoV. The terminal (120) identifying the external object may be performed based on a sensor for identifying the distance between the terminal (120) and the external object, such as a depth sensor and / or a time of flight (ToF) sensor. The camera (260) positioned toward the FoV may support an autofocus function and / or an optical image stabilization (OIS) function. For example, the terminal (120) may include a camera (260) (e.g., a face tracking (FT) camera) positioned toward the face in order to obtain an image including the face of a user wearing the terminal (120).

[0060] Although not shown, in one embodiment, the terminal (120) may further include a light source (e.g., an LED) that emits light toward a subject (e.g., a user's eyes, face, and / or an external object within the FoV) being photographed using the camera (260). The light source may include an infrared wavelength LED. The light source may be disposed in at least one of the frame (200) and the hinge units (206, 207).

[0061] According to one embodiment, the battery module (270) may supply power to electronic components of the terminal (120). In one embodiment, the battery module (270) may be disposed within the first temple (204) and / or the second temple (205). For example, the battery module (270) may be a plurality of battery modules (270). The plurality of battery modules (270) may be disposed within each of the first temple (204) and the second temple (205). In one embodiment, the battery module (270) may be disposed at an end of the first temple (204) and / or the second temple (205).

[0062] The antenna module (275) can transmit signals or power to the outside of the terminal (120), or receive signals or power from the outside. In one embodiment, the antenna module (275) can be positioned within the first temple (204) and / or the second temple (205). For example, the antenna module (275) can be positioned close to one surface of the first temple (204) and / or the second temple (205).

[0063] The speaker (255) can output an acoustic signal to the outside of the terminal (120). The acoustic output module may be referred to as a speaker. In one embodiment, the speaker (255) may be positioned within the first temple (204) and / or the second temple (205) so as to be positioned adjacent to the ear of a user wearing the terminal (120). For example, the speaker (255) may include a second speaker (255-2) positioned within the first temple (204) and thus positioned adjacent to the user's left ear, and a first speaker (255-1) positioned within the second temple (205) and thus positioned adjacent to the user's right ear.

[0064] The light-emitting module (not shown) may include at least one light-emitting element. The light-emitting module may emit light of a color corresponding to a specific state or emit light with an action corresponding to a specific state, in order to visually provide information regarding a specific state of the terminal (120) to the user. For example, when the terminal (120) requires charging, it may emit red light at a regular cycle. In one embodiment, the light-emitting module may be disposed on the first rim (201) and / or the second rim (202).

[0065] Referring to FIG. 2B, according to one embodiment, the terminal (120) may include a printed circuit board (PCB) (290). The PCB (290) may be included in at least one of the first temple (204) or the second temple (205). The PCB (290) may include an interposer positioned between at least two sub-PCBs. One or more hardwares included in the terminal (120) (e.g., hardwares illustrated by different blocks in FIG. 4) may be positioned on the PCB (290). The terminal (120) may include a flexible PCB (FPCB) for interconnecting the hardwares.

[0066] According to one embodiment, the terminal (120) may include at least one of a gyro sensor, a gravity sensor, and / or an acceleration sensor for detecting a posture of the terminal (120) and / or a posture of a body part (e.g., a head) of a user wearing the terminal (120). Each of the gravity sensor and the acceleration sensor may measure gravitational acceleration and / or acceleration based on mutually perpendicular designated three-dimensional axes (e.g., an x-axis, a y-axis, and a z-axis). The gyro sensor may measure an angular velocity of each of the designated three-dimensional axes (e.g., an x-axis, a y-axis, and a z-axis). At least one of the gravity sensor, the acceleration sensor, and the gyro sensor may be referred to as an inertial measurement unit (IMU). According to one embodiment, the terminal (120) may identify a motion and / or gesture of the user performed to execute or stop a specific function of the terminal (120) based on the IMU.

[0067] Figures 3a and 3b illustrate an example of the appearance of a terminal.

[0068] The terminal (120) of FIGS. 3A and 3B may be an example of the terminal (120) of FIGS. 2A and 2B. For example, FIGS. 3A and 3B may be an example of the terminal (120) of FIG. 1. According to one embodiment, an example of the appearance of a first side (310) of a housing of the terminal (120) is illustrated in FIG. 3A, and an example of the appearance of a second side (320) opposite to the first side (310) may be illustrated in FIG. 3B.

[0069] Referring to FIG. 3A, according to one embodiment, the first surface (310) of the terminal (120) may have a form attachable to a body part of a user (e.g., the face of the user). Although not shown, the wearable device (101) may further include a strap for fixing to a body part of a user, and / or one or more temples (e.g., the first temple (204) and / or the second temple (205) of FIGS. 2A and 2B). A first display (250-1) for outputting an image to a left eye among the user's two eyes, and a second display (250-2) for outputting an image to a right eye among the two eyes, may be disposed on the first surface (310). The terminal (120) is formed on the first surface (310) and may further include rubber or silicone packing to prevent interference by light (e.g., ambient light) different from the light radiated from the first display (250-1) and the second display (250-2).

[0070] According to one embodiment, the terminal (120) may include cameras (260-1) for photographing and / or tracking the eyes of the user adjacent to each of the first display (250-1) and the second display (250-2). The cameras (260-1) may be referred to as the gaze tracking camera (260-1) of FIG. 2B. According to one embodiment, the terminal (120) may include cameras (260-5, 260-6) for photographing and / or recognizing the face of the user. The cameras (260-5, 260-6) may be referred to as FT cameras. The terminal (120) may control an avatar representing the user in a virtual space based on the motion of the user's face identified using the cameras (260-5, 260-6). For example, the terminal (120) may change the texture and / or shape of a portion of the avatar (e.g., a portion of the avatar expressing a human face) using information obtained by cameras (260-5, 260-6) (e.g., FT cameras) and representing the facial expression of a user wearing the terminal (120).

[0071] Referring to FIG. 3b, a camera (e.g., cameras 260-7, 260-8, 260-9, 260-10, 260-11, 260-12)) and / or a sensor (e.g., a depth sensor (330)) for obtaining information related to the external environment of the terminal (120) may be disposed on a second surface (320) opposite to the first surface (310) of FIG. 3a. For example, the cameras (260-7, 260-8, 260-9, 260-10) may be disposed on the second surface (320) to recognize external objects. The cameras (260-7, 260-8, 260-9, 260-10) may be referred to as the motion recognition cameras (260-2, 260-3) of FIG. 2b.

[0072] For example, using cameras (260-11, 260-12), the terminal (120) can obtain images and / or videos to be transmitted to each of the user's eyes. The camera (260-11) can be placed on the second surface (320) of the terminal (120) to obtain an image to be displayed through the second display (250-2) corresponding to the right eye among the two eyes. The camera (260-12) can be placed on the second surface (320) of the terminal (120) to obtain an image to be displayed through the first display (250-1) corresponding to the left eye among the two eyes. The cameras (260-11, 260-12) can be referred to as the shooting camera (260-4) of FIG. 2B.

[0073] According to one embodiment, the terminal (120) may include a depth sensor (330) disposed on the second face (320) to identify a distance between the terminal (120) and an external object. Using the depth sensor (330), the terminal (120) may obtain spatial information (e.g., a depth map) for at least a portion of the FoV of a user wearing the terminal (120). Although not shown, a microphone may be disposed on the second face (320) of the terminal (120) to obtain sound output from an external object. The number of microphones may be one or more depending on the embodiment.

[0074] The components of the terminal (120) illustrated in FIGS. 2A to 3B are merely exemplary and the present disclosure is not limited thereto. For example, the terminal (120) may further include at least one of the components illustrated in FIGS. 2A to 3B or may not include at least one of the components. For example, the terminal (120) may include the components in a different area (or arrangement) from the area (or arrangement) where the components illustrated in FIGS. 2A to 3B are located. For example, the terminal (120) may include a different number of components than the number of each of the components (e.g., cameras or sensors) illustrated in FIGS. 2A to 3B. Hereinafter, the hardware or software configuration of the terminal (120) will be described with reference to FIG. 4.

[0075] Figure 4 shows an example of the functional configuration of an electronic device.

[0076] The configuration of the electronic device (400) illustrated in FIG. 4 may be understood as the configuration of a base station (110) of FIG. 1, a terminal (120) of FIG. 1, a terminal (120) of FIGS. 2A to 3B, or a network node. Terms such as "...unit" and "...device" used hereinafter mean a unit that processes at least one function or operation, and this may be implemented by hardware, software, or a combination of hardware and software.

[0077] Referring to FIG. 4, the electronic device (400) may include a transceiver (410), a memory (420), and a processor (430). However, the present disclosure is not limited thereto. For example, the electronic device (400) may not include at least some of the components illustrated in FIG. 4, or may further include components not illustrated in FIG. 4. For example, the electronic device (400) may not include the transceiver (410).

[0078] The transceiver (410) can perform functions for transmitting and receiving signals in a wired communication environment. The transceiver (410) can include a wired interface for controlling direct connections between devices via a transmission medium (e.g., copper wire, optical fiber). For example, the transceiver (410) can transmit electrical signals to other devices via copper wire, or perform conversion between electrical signals and optical signals.

[0079] The transceiver (410) may perform functions for transmitting and receiving signals in a wireless communication environment. For example, the transceiver (410) may perform a conversion function between baseband signals and bit streams according to the physical layer specifications of the system. For example, when transmitting data, the transceiver (410) encodes and modulates the transmitted bit stream to generate complex-valued symbols. Furthermore, when receiving data, the transceiver (410) demodulates and decodes the baseband signal to restore the received bit stream. Furthermore, the transceiver (410) may include multiple transmission and reception paths.

[0080] The transceiver (410) transmits and receives signals as described above. Accordingly, all or part of the transceiver (410) may be referred to as a "communication unit," a "transmitter," a "receiver," or a "transmitter-receiver unit." Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean that the transceiver (410) performs the processing described above.

[0081] Although not illustrated in FIG. 4, the transceiver (410) may further include a backhaul transceiver for connection to the core network or other base stations. The backhaul transceiver provides an interface for communicating with other nodes within the network. That is, the backhaul transceiver converts a bit stream transmitted from the base station to other nodes, such as other access nodes, other base stations, upper nodes, the core network, etc., into a physical signal, and converts a physical signal received from other nodes into a bit stream.

[0082] The memory (420) stores data such as basic programs, application programs, and setting information for the operation of the electronic device (400). The memory (420) may be referred to as a storage unit. The memory (420) may be composed of volatile memory, nonvolatile memory, or a combination of volatile memory and nonvolatile memory. In addition, the memory (420) provides stored data upon request from the processor (430).

[0083] For example, the processor (430) may include various processing circuits and / or multiple processors. For example, the term "processor" as used herein, including in the claims, may include various processing circuits including at least one processor, one or more of which may be configured to individually and / or collectively perform the various functions described below in a distributed manner. As used herein, when "processor," "at least one processor," and "one or more processors" are described as being configured to perform various functions, these terms encompass, for example, and without limitation, situations where one processor performs some of the recited functions and other processor(s) perform other parts of the recited functions, and also situations where one processor may perform all of the recited functions. Additionally, the at least one processor may include a combination of processors that perform the various functions enumerated / disclosed, for example, in a distributed manner. At least one processor may execute program instructions to achieve or perform the various functions.

[0084] The processor (430) controls the overall operations of the electronic device (400). The processor (430) may be referred to as a control unit. For example, the processor (430) transmits and receives signals via the transceiver (410) (or via the backhaul communication unit). In addition, the processor (430) records and reads data from the memory (420). In addition, the processor (430) may perform functions of a protocol stack required by a communication standard. Although only the processor (430) is illustrated in FIG. 4, the electronic device (400) may include two or more processors according to other implementation examples.

[0085] Figure 5 illustrates an example of how to render data for an XR service on an XR (extended reality) device and an XR server.

[0086] FIG. 5 illustrates an example of a method for rendering data for an XR service between an XR device (510) and an XR server (520). The XR device (510) of FIG. 5 may be an example of the terminal (120) of FIG. 1 or the terminal (120) of FIGS. 2A to 3B. The XR device (510) may be referred to as a client or an XR client. The XR server (520) of FIG. 5 may be an example of the base station (110) of FIG. 1. For example, the XR server (520) may be referred to as a network node, a server, an edge, or another UE. For example, the XR service may represent a service for XR. For example, data for the XR service may be referred to as XR data.

[0087] In FIG. 5, for convenience of explanation, an example is shown in which an XR device (510) and an XR server (520) perform rendering by splitting the XR data, but the present disclosure is not limited thereto. The rendering performed by the XR device (510) and the XR server (520) by splitting may be referred to as split rendering. The split rendering may provide relatively high flexibility in terms of latency requirements, processing, and bitrate.

[0088] Referring to FIG. 5, an XR device (510) may establish a connection with an XR server (520) to provide the XR service. For example, the XR service may be provided using an XR application. For example, based on the connection, the XR device (510) may provide device information of the XR device (510) (e.g., supported decoders, viewport, or supported formats) to the XR server (520). For example, the viewport may include a screen, image, or visual information displayed on the XR device (510).

[0089] For example, the XR device (510) can obtain tracking information and sensor information. For example, the tracking information and the sensor information may include information for indicating the pose of the XR device (510). For example, the tracking information and the sensor information may be obtained using depth of field (DoF) or at least one sensor. For example, the XR device (510) can provide the tracking information and the sensor information to the XR server (520) based on a specific transmission technique (e.g., fifth generation system (5GS) delivery).

[0090] For example, the XR server (520) may perform XR media generation and XR viewport pre-rendering using the received tracking information and sensor information. For example, the XR server (520) may perform pre-rendering for the XR viewport by generating one or more rendering buffers using the pose. For example, the rendering buffers may be encoded by 2D (dimensional) or 3D media encoders. For example, the XR server (520) may transmit compressed (or encoded) media and additional metadata (or XR rendering metadata) to the XR device (510) based on the specific transmission technique. For example, the metadata may represent information for describing the media. For example, the compressed media and additional metadata may be referred to as downlink data or XR data.

[0091] For example, the XR device (510) can decompress (or decode) buffers (or pre-rendered 2D / 3D media) and add the decompressed buffers to an XR rendering engine. For example, the XR rendering engine can generate a rendered viewport (XR viewport) using the buffers. For example, the XR device (510) can display the rendered viewport through a display (e.g., the display (250) of FIG. 2A) to provide the XR service.

[0092] XR technology can be utilized across various industries (e.g., gaming, health, education, and entertainment). However, as demand for XR services increases, the power consumption of wireless communication systems and terminals (120) (or XR devices (510)) increases, leading to a substantial increase in network operating costs. A method for utilizing appropriate wireless resources while reducing power consumption is required when transmitting wireless data to provide XR services. More specifically, wireless data (or XR data) for XR services can be relatively large in size due to their nature. Accordingly, a method for efficiently allocating XR data with a large amount of data while reducing power consumption is required. In addition, XR services may require relatively low delay (or jitter). Accordingly, a method for efficiently allocating, transmitting, and receiving large amounts of data while supporting low delay is required.

[0093] Hereinafter, the present disclosure can adaptively perform DRX (discontinuous reception) to reduce power consumption of a terminal (120). In the present disclosure, DRX that is adaptively performed may be referred to as adaptive DRX. For example, the present disclosure can authorize the terminal (120) to adaptively perform DRX by adjusting parameters for DRX based on channel information of a channel between the terminal (120) and a network node (e.g., the base station (110) of FIG. 1, the XR server (520) of FIG. 5). In addition, the present disclosure can adjust the buffer size of a buffer for transmitting or receiving data. For example, the present disclosure can transmit (or receive) the same data within substantially the same time interval by reducing the number of unnecessary communications and transmitting (or receiving) data stored (or buffered) in a buffer having an adjusted buffer size. Accordingly, the present disclosure can reduce the power consumption of the terminal (120) (or the network node).

[0094] In addition, the present disclosure can perform adaptive DRX by determining whether to transmit or receive data in a short DRX among DRXs to support low latency due to the characteristics of XR services. Short DRX can be used to increase opportunities for data reception within DRX operations performed to reduce power consumption and to perform reception of important data. By using short DRX, low latency of XR services can be supported. Accordingly, the present disclosure can provide users with a seamless XR service experience. Specific details related to the DRX operation can be referenced in FIG. 6 below.

[0095] Figure 6 illustrates an example of DRX (discontinuous reception).

[0096] FIG. 6 illustrates an example (600) of a DRX operation (or DRX) performed by the terminal (120) of FIG. 1 (or the terminal (120) of FIGS. 2A to 3B, the XR device (510)). The DRX operation of the example (600) of FIG. 6 is merely exemplary for convenience of explanation, and the present disclosure is not limited thereto. For example, each of a long DRX cycle and a short DRX cycle of the DRX operation may be changed. In addition, the length of the on-duration of the DRX operation may be changed.

[0097] Referring to example (600), the terminal (120) may perform a DRX operation to reduce unnecessary power consumption when there is no traffic between a network node (e.g., a base station (110) of FIG. 1, an XR server (520) of FIG. 5) and the terminal (120). For example, within the DRX operation, the terminal (120) may monitor whether a downlink signal (or downlink data) is received within a specific time period, and may stop performing the monitoring outside of the specific time period. For example, the specific time period may be referred to as an on-duration or on-time of the DRX. For example, the time period outside of the specific time period may be referred to as an off-duration or off-time of the DRX. The terminal (120) within the above-mentioned specific time period may be in wake-up mode (or on state), and outside the above-mentioned specific time period, the terminal (120) may be in sleep mode (or off state). In other words, the terminal (120) may monitor reception of downlink data by switching to the wake-up mode within the on-period, and may stop monitoring for reception of downlink data by switching to the sleep mode within the off-period. Accordingly, the terminal (120) may reduce power consumption by not performing unnecessary continuous monitoring. For example, the DRX operation may be performed in a connected state (or an RRC (radio resource control) connected state (RRC connected state)) or an idle state (or an RRC idle state) among the states of the terminal (120).

[0098] Referring to example (600), the terminal (120) can perform long DRX. For example, the terminal (120) can perform the long DRX according to the cycle (615) of the long DRX. Performing the long DRX may include the terminal (120) performing monitoring within on-intervals (611, 612, 613) according to the cycle (615) of the long DRX, and stopping monitoring within off-intervals between the on-intervals (611, 612, 613). For example, the terminal (120) can perform monitoring within the on-interval (611) according to the cycle (615) of the long DRX.

[0099] For example, the terminal (120) may identify that a downlink signal (640) is received (or receive the downlink signal (640)) while monitoring within the on-interval (611) according to the cycle (615) of the long DRX. For example, the downlink signal (640) may include a physical downlink control channel (PDCCH) signal. For example, the PDCCH may include resource allocation information (or downlink control information). For example, the resource allocation information may include uplink resource allocation information and / or downlink resource allocation information. For example, the terminal (120) may start an inactivity timer (650) for DRX when the downlink signal (640) is received. For example, the inactivity timer (650) may indicate a time for the terminal (120) to remain in the wake-up mode after the downlink signal (640) is received within the on-interval (611). For example, when the downlink signal (640) is received within the on-interval (611), the terminal (120) may not enter the sleep mode when the on-interval (611) ends, but may operate in the wake-up mode until the inactivity timer (650) expires.

[0100] For example, the terminal (120) may initiate short DRX when the inactivity timer (650) expires. For example, the terminal (120) may perform short DRX in order to monitor a downlink signal that may be additionally received when the inactivity timer (650) expires after a downlink signal (640) is received within the on-interval (611). Performing the short DRX may include the terminal (120) performing monitoring within on-intervals (621, 622, 623) according to the cycle (625) of the short DRX and stopping monitoring within off-intervals between the on-intervals (621, 622, 623). For example, the terminal (120) may perform monitoring within the on-interval (621) according to the cycle (625) of the short DRX. In example (600), the length (630) of the on-interval (611) of the long DRX may correspond to (or be identical to) the length (630) of the on-interval (621) of the short DRX.

[0101] Referring to example (600), if no additional downlink signal is received after performing the short DRX, the terminal (120) may perform the long DRX again. For example, if the number of on-intervals according to the cycle (625) of the short DRX is greater than or equal to a reference number, the terminal (120) may perform the long DRX again. For example, the reference number may be indicated by the network node. For example, the terminal (120) may perform monitoring within the on-interval (612) according to the cycle (615) of the long DRX, and then enter the sleep mode again. Referring to example (600), the terminal (120) may selectively perform one of the short DRX and the long DRX.

[0102] As described above, parameters for DRX may be set so that the terminal (120) performs the DRX operation. For example, the network node may transmit a message including parameters for DRX to the terminal (120). For example, the message may be referred to as an RRC message. For example, the parameters for DRX included in the message may include at least one of the length of the DRX on-duration (e.g., length (630)), the length of the inactivity timer (e.g., inactivity timer (650)), the length of the short DRX cycle (e.g., cycle (625)), or the length of the long DRX cycle (e.g., cycle (615)). For example, the length of the DRX on-duration may be referred to as an on-duration timer. The parameters for DRX included in the message are not limited to the above example. For example, the parameters for DRX included in the above message may further include a DRX retransmission timer. Or, for example, if the parameters for DRX included in the above message do not include parameters related to the short DRX, the terminal (120) may perform long DRX and not perform short DRX.

[0103] Referring to the above, the network node can set a DRX operation for the terminal (120) by transmitting parameters for DRX to the terminal (120). Accordingly, the network node can also identify a DRX operation to be performed in the terminal (120) or whether the terminal (120) is in wake-up mode or sleep mode. The network node can adjust parameters for DRX performed in the terminal (120) when it determines that there is downlink data to be transmitted to the terminal (120) within an on-period (e.g., on-period (621)) according to a cycle of short DRX. In addition, the network node can adjust a buffer size of a buffer for transmitting downlink data based on the adjusted parameters. Accordingly, the network node can transmit downlink data stored in a buffer having the adjusted buffer size to the terminal (120) within an on-period according to a cycle of short DRX. As described above, adjusting parameters for DRX may be referred to as performing adaptive DRX. For example, adaptive DRX may be performed according to an adaptive DRX mechanism determined by the network node. For example, the adaptive DRX mechanism may include static DRX, a DRX set, and adaptive DRX. For example, in the static DRX, parameters for fixed DRX may be used. For example, in the DRX set, candidate parameters for DRX are set to the terminal (120), and a candidate parameter selected by the terminal (120) among the candidate parameters may be used. For example, in the adaptive DRX, parameters for DRX adjusted based on a channel status may be used. The present disclosure may utilize the adaptive DRX in a DRX operation for XR data. However, the present disclosure is not limited thereto.For example, the present disclosure may utilize a DRX set in a DRX operation for XR data.

[0104] For example, adaptive DRX can dynamically adjust the cycles of sleep mode and wake-up mode. For example, the present disclosure can dynamically adjust sleep mode and wake-up mode by continuously monitoring traffic load (i.e., monitoring the cycle of uplink / downlink data) and checking network conditions (whether the channel environment is good or bad) by using adaptive DRX. For example, adaptive DRX can optimize QoS and improve QoE (quality of experience). For example, the present disclosure can perform rendering so as to secure a certain level or higher of QoS while adaptively managing the cycles of sleep mode and wake-up mode of the terminal (120) by using adaptive DRX. For example, adaptive DRX can increase the battery life of the terminal (120). For example, the present disclosure can reduce the power consumption of the terminal (120) by adjusting DRX parameters according to network traffic patterns and requirements of XR services. Accordingly, the present disclosure can provide an improved user experience when applied to an XR application of the video application type that has relatively high battery consumption.

[0105] For example, based on the adaptive DRX mechanism, power consumption of the terminal (120) can be reduced and low latency for XR services can be provided. Specific details related thereto are described below in FIG. 7a.

[0106] FIG. 7a illustrates an example of an operation flow for a method of transmitting downlink data for an XR service based on adaptive DRX.

[0107] At least some of the methods of FIG. 7A may be performed by a network node. For example, the network node may be, for example, the base station (110) of FIG. 1 or the XR server (520) of FIG. 5. For example, at least some of the methods may be controlled by a processor of the network node (e.g., the processor (430) of FIG. 4). In the embodiments described below, the operations may be performed sequentially, but are not necessarily performed sequentially. For example, the order of the operations may be changed, and at least two operations may be performed in parallel.

[0108] Although not illustrated in FIG. 7A, a data session may be established between the network node and the terminal (120). For example, the data session may include a session for performing communication between the network node and the terminal (120). For example, the data session may include a packet data unit (PDU) session. For example, the data session may include a bearer (or a data radio bearer (DRB)). For example, the data session may include a quality of service (QoS) flow. For example, the data session may correspond to (or be mapped to) a QoS class identifier (QCI). For example, exemplary services that may be provided may be mapped to the QCI. For example, the QCI may be referenced as a QoS profile.

[0109] Before performing operation (700), the network node may identify a data session having a designated QoS profile set for the terminal (120). For example, the network node may identify the data session having the designated QoS profile in order to provide an XR service to the terminal (120). For example, the designated QoS profile may correspond to (or be mapped to) the XR service. For example, the network node may use the data session having the designated QoS profile in order to provide downlink data (or XR data) for the XR service. For example, the XR data may include video data having a high level of resolution rendered in an XR application.

[0110] Before performing operation (700), the network node may transmit a message including parameters for DRX to the terminal (120). For example, the terminal (120) may perform the DRX operation using the parameters for DRX in the received message.

[0111] Before performing operation (700), the network node may transmit downlink data to the terminal (120) through the data session. For example, the network node may transmit downlink data to the terminal (120) performing the DRX operation. For example, the network node may transmit downlink data to the terminal (120) within an on-period (e.g., on-period (611) of FIG. 6) according to a cycle of long DRX during the DRX operation. The terminal (120) may start an inactivity timer for DRX (e.g., an inactivity timer (650) of FIG. 6) upon receiving downlink data within an on-period (e.g., an on-period (611) of FIG. 6) according to a cycle of long DRX. For example, the terminal (120) may perform monitoring for reception of downlink data until the inactivity timer expires. After this, the terminal (120) can initiate short DRX after the inactivity timer expires. At this time, the network node can identify that the terminal (120) initiates the inactivity timer and that the initiated inactivity timer has expired after transmitting downlink data to the terminal (120) within an on-interval (e.g., on-interval (611) of FIG. 6) according to the cycle of the long DRX. For example, the network node can identify that the terminal (120) is performing short DRX when the inactivity timer expires.

[0112] In operation (700), the network node may identify downlink data to be transmitted through the data session having the designated QoS profile. For example, the downlink data to be transmitted may represent data subsequent to downlink data transmitted within an on-interval (e.g., on-interval (611) of FIG. 6) according to a cycle of long DRX. For example, the network node may identify downlink data to be transmitted through the data session having the designated QoS profile in order to provide an XR service to the terminal (120). For example, the downlink data may be referred to as XR data.

[0113] In operation (705), the network node may determine whether the downlink data will be transmitted within an on-period (e.g., on-period (621) of FIG. 6) according to a cycle of short DRX that is initiated when the inactivity timer of the DRX set for the terminal (120) expires. For example, the network node may determine whether the downlink data will be transmitted within an on-period (e.g., on-period (621) of FIG. 6) according to a cycle of short DRX that is initiated when the inactivity timer of the DRX set for the terminal (120) expires.

[0114] In operation (705), the network node may perform operation (710) upon determining that downlink data will be transmitted within an on-period (e.g., on-period (621) of FIG. 6) according to a cycle of short DRX. Alternatively, in operation (705), the network node may perform operation (730) upon determining that downlink data will not be transmitted within an on-period (e.g., on-period (621) of FIG. 6) according to a cycle of short DRX.

[0115] In operation (710), the network node may adjust parameters for DRX based on channel information. For example, the network node may adjust parameters for DRX based on channel information when it determines that downlink data will be transmitted within an on-interval (e.g., on-interval (621) of FIG. 6) according to a cycle of short DRX. For example, adjusting parameters for DRX based on the channel information may be referred to as adaptive DRX.

[0116] For example, the channel information may include channel state information (CSI) received from the terminal (120) or channel information estimated using a reference signal (e.g., a sounding reference signal (SRS)) received from the terminal (120). For example, the network node may identify the channel information by checking packet / signaling statistics. For example, the network node may identify a value indicating the quality of a channel between the terminal (120) and the network node, as indicated by the channel information. As a non-limiting example, the value indicating the quality may include channel quality information (CQI). For example, the value indicating the quality may be referred to as a quality value or a quality level.

[0117] For example, the network node may compare the value representing the quality with reference values. For example, the reference values ​​may include a first reference value and a second reference value that is less than the first reference value. For example, based on the value that is greater than the first reference value, the network node may adjust the length of the on-interval for the DRX (e.g., length (630) of FIG. 6) from a first length to a second length that is shorter than the first length. For example, the first length may be referred to as a reference length, an initial length, or a previous length. For example, based on the value that is less than the second reference value, the network node may adjust the length of the on-interval for the DRX from the first length to a third length that is longer than the first length. For example, depending on the value between the first reference value and the second reference value, the network node may maintain (or refrain from adjusting) the length of the on-interval for the DRX to the first length. In the above example, a case of adjusting the length of the on-interval for the DRX based on the channel information is described, but the present disclosure is not limited thereto. For example, the network node may adjust a parameter for DRX (e.g., a length of an inactivity timer, a length of the cycle of short DRX, a length of the cycle of long DRX, or a length of an on-interval) based on the channel information. In addition, in the above example, a case of performing a comparison between the value and two reference values ​​is described, but the present disclosure is not limited thereto. For example, the network node may compare with one reference value or with three or more reference values. Additionally, for example, the network node may determine the second length based on the magnitude of the difference between the value exceeding the first reference value and the first reference value.For example, the greater the difference, the greater the second length may be. Referring to the foregoing, the network node may set (or adjust) the length of the on-interval to be shorter, as the better the channel condition, the higher the likelihood of receiving downlink data during the same period. However, the present disclosure is not limited thereto.

[0118] Although not shown in FIG. 7A, the network node may transmit the adjusted parameter for DRX to the terminal (120). For example, the network node may transmit a message including the adjusted parameter to the terminal (120). In the above example, the network node determines one adjusted parameter for DRX and transmits it to the terminal (120), but the present disclosure is not limited thereto. For example, the network node may determine a plurality of adjusted parameters and transmit them to the terminal (120). When the parameter is the length of an on-interval, the network node may determine a first length of the adjusted on-interval and a second length of the adjusted on-interval based on channel information, and transmit a message including the first length and the second length to the terminal (120). For example, the first length may be the length of the on-interval before downlink data is received, and the second length may be the length of the on-interval after downlink data is received. As a non-limiting example, the first length may be longer than the second length.

[0119] In operation (715), the network node may adjust a buffer size based on the adjusted parameter. For example, the buffer size may be referred to as a window size or a buffering window size. For example, the network node may adjust a buffer size of a buffer for transmitting downlink data of the network node based on the adjusted parameter for DRX. For example, the network node may determine an amount and a transmission time of downlink data to be transmitted to the terminal (120) based on a time point at which the terminal (120) can receive downlink data and a channel bandwidth predicted during a period during which the terminal (120) can receive downlink data based on the channel information. For example, the network node may adjust the buffer size of the buffer to store (or buffer) downlink data determined based on the channel information to be transmitted within an on-period for DRX determined based on the adjusted parameter. Specific details on how to adjust the buffer size of the above buffer are illustrated and described below with reference to FIG. 7b.

[0120] Figure 7b illustrates an example of how to adjust the buffer size in adaptive DRX.

[0121] FIG. 7b illustrates an example (750) of adaptive DRX in which a buffer size is adjusted based on channel information. In example (750), for convenience of explanation, downlink data (755) to be transmitted is illustrated as eight blocks, but the present disclosure is not limited thereto. For example, each of the eight blocks may be referred to as the size of the downlink data (755).

[0122] Referring to example (750), the network node may identify a buffer size of a buffer (760) for storing (or buffering) downlink data (755) when the value representing the quality of the channel is a value between the first reference value and the second reference value. For example, the buffer size of the buffer (760) may have a first size (765). For example, the first size (765) may be referred to as a default size, a reference size, or an initial size. However, the present disclosure is not limited thereto.

[0123] Referring to example (750), the network node may identify a buffer size of a buffer (770) for storing (or buffering) downlink data (755) when the value indicating the quality of the channel exceeds the first reference value. For example, the buffer size of the buffer (770) may have a second size (775). For example, the second size (775) may be larger than the first size (765). For example, the network node may increase the buffer size when the condition of the channel is relatively good.

[0124] Referring to example (750), the network node may identify a buffer size of a buffer (780) for storing (or buffering) downlink data (755) when the value indicating the quality of the channel is less than the second reference value. For example, the buffer size of the buffer (780) may have a third size (785). For example, the third size (785) may be smaller than the first size (765). For example, the network node may reduce the buffer size when the condition of the channel is relatively poor.

[0125] In the example (750) of FIG. 7B, the method for the network node to adjust the buffer size of the buffer based on a value representing the quality of the channel is illustrated, but the present disclosure is not limited thereto. For example, the network node may adjust the parameters for the DRX and adjust the buffer size using parameters related to the terminal (120). For example, the parameters related to the terminal (120) may include at least one of battery information of the terminal (120) or capacity information of the buffer of the terminal (120) for receiving downlink data.

[0126] Additionally, the network node may utilize an artificial intelligence model to adjust the buffer size. For example, the network node may adjust the buffer size based on the artificial intelligence model by utilizing the channel information (and / or parameters for the DRX). For example, the artificial intelligence model may be learned based on reinforcement learning. For example, the algorithm for the reinforcement learning may include a function (Z). For example, the function (Z) may be used to determine the condition of the predicted channel state (s) for performing a specific operation (a) using a learning rate (v). For example, when the predicted channel state (s) is relatively good, the network node may increase the buffer size to allocate more downlink data to be stored in the buffer by providing a reward (Y). For example, if the predicted channel condition (s) is relatively bad, the network node may reduce the buffer size by providing a penalty (Y) to allocate less downlink data to be stored in the buffer. For example, if the predicted channel condition (s) is normal, the network node may not perform action (a) of increasing or decreasing the buffer size. In other words, the network node may maintain the buffer size. The above-described examples are merely examples for the convenience of explanation, and the reinforcement learning algorithm according to the present disclosure is not limited to the above examples.

[0127] Referring back to FIG. 7A, at operation (720), the network node may store downlink data in a buffer. For example, the buffer may have an adjusted buffer size. Alternatively, for example, the buffer may have a buffer size that is not adjusted, depending on channel conditions. For example, the network node may store downlink data to be transmitted within an on-interval (e.g., on-interval (621) of FIG. 6) according to a short DRX cycle, in the buffer.

[0128] In operation (725), the network node may transmit the stored downlink data within an on-period according to a cycle of short DRX. For example, the network node may transmit the downlink data stored in the buffer within an on-period according to a cycle of short DRX. At this time, the on-period according to a cycle of short DRX in which the stored downlink data is transmitted may be an on-period according to a cycle of short DRX determined in operation (705) (e.g., on-period (621) of FIG. 6) or an on-period following the on-period according to a cycle of short DRX determined in operation (705) (e.g., on-period (622) or on-period (623) of FIG. 6). In one example, the on-interval according to the cycle of short DRX during which the stored downlink data is transmitted may be an on-interval according to the cycle of short DRX (e.g., on-interval (621) in FIG. 6) at which the stored downlink data was originally determined to be transmitted, when the amount of data stored in the buffer exceeds a certain level. Alternatively, the on-interval according to the cycle of short DRX during which the stored downlink data is transmitted may be an on-interval according to the cycle of short DRX (e.g., on-interval (622) or on-interval (623) in FIG. 6) after the time at which the downlink data is stored in the buffer and the stored downlink data is originally determined to be transmitted, when the amount of data stored in the buffer is less than the certain level.

[0129] In the above example, the terminal (120) can perform monitoring of downlink data by operating in wake-up mode within the on-interval according to the cycle of short DRX. The terminal (120) can receive downlink data during the monitoring.

[0130] In operation (730), the network node may identify other downlink data to be transmitted within an on-period according to a cycle of a long DRX (e.g., on-period (612) of FIG. 6). For example, the network node may identify that the terminal (120) performs the long DRX again when it determines that downlink data will not be transmitted within an on-period according to a cycle of a short DRX. For example, the terminal (120) may perform the long DRX when it identifies that downlink data is not received within on-periods according to a cycle of a short DRX (e.g., on-periods (621, 622, 623) of FIG. 6). For example, the number of on-periods of a short DRX may be set by the network node. For example, the network node may identify other downlink data to be transmitted within an on-interval (e.g., on-interval (612) of FIG. 6) according to a cycle of a long DRX performed after a short DRX.

[0131] In operation (735), the network node may store other downlink data in the buffer. For example, the network node may store other downlink data to be transmitted within the on-period (e.g., on-period (612) of FIG. 6) according to the cycle of the long DRX within the buffer for transmission by the network node. At this time, the buffer size of the buffer in which other downlink data to be transmitted within the on-period (e.g., on-period (612) of FIG. 6) according to the cycle of the long DRX is stored may be an unadjusted buffer size. In other words, the buffer size of the buffer may be a buffer size for which adjustment is not performed based on channel information. In one example, the buffer size of the buffer may have the first size (765) of FIG. 7B. However, the present disclosure is not limited thereto.

[0132] In operation (740), the network node may transmit other stored downlink data within an on-period according to a cycle of long DRX. For example, the network node may transmit other downlink data stored in the buffer within an on-period according to a cycle of long DRX. At this time, the on-period according to a cycle of long DRX in which the other stored downlink data is transmitted may be an on-period according to a cycle of long DRX determined in operation (730) (e.g., on-period (612) of FIG. 6) or an on-period following an on-period according to a cycle of long DRX determined in operation (705) (e.g., on-period (613) of FIG. 6). In one example, the on-interval according to the cycle of the long DRX during which other stored downlink data is transmitted may be an on-interval according to the cycle of the long DRX (e.g., on-interval (612) in FIG. 6) at which other stored downlink data was originally determined to be transmitted, if the amount of data stored in the buffer exceeds a certain level. Alternatively, the on-interval according to the cycle of the long DRX during which other stored downlink data is transmitted may be an on-interval according to the cycle of the long DRX after a time at which other downlink data was stored in the buffer and other stored downlink data was originally determined to be transmitted, if the amount of data stored in the buffer is less than the certain level.

[0133] In the above example, the terminal (120) can perform monitoring of downlink data by operating in wake-up mode within the on-interval according to the cycle of long DRX. The terminal (120) can receive other downlink data during the monitoring.

[0134] Although not illustrated in FIG. 7a, after performing operation (740), the network node may perform adaptive DRX. For example, the network node may adjust parameters for DRX and adjust the buffer size based on channel information.

[0135] In FIG. 7A and FIG. 7B, the network node adjusts parameters for DRX (or performs adaptive DRX) in order to transmit downlink data to a terminal (120) performing a DRX operation, but the present disclosure is not limited thereto. For example, the terminal (120) performing a DRX operation may select (or determine) a parameter for DRX from a DRX set as a parameter to be used for DRX based on channel information. For example, the DRX set may represent a set of candidate parameters for DRX. In one example, it is assumed that the parameter for DRX is the length of an on-interval for DRX. The DRX set may include a plurality of candidate lengths of an on-interval for DRX. For example, the terminal (120) may select (or determine) one of the plurality of candidate lengths as a parameter to be used for DRX based on channel information. For example, the terminal (120) may use (or adjust) the selected candidate length as the length of an on-interval for DRX, and adjust the buffer size according to the adjustment of the length. In the above example, a case of selecting the candidate length based on channel information is described, but the present disclosure is not limited thereto. For example, the candidate length among the plurality of candidate lengths may be flexibly selected based on a traffic pattern or QoS setting of the terminal (120).

[0136] In addition, in FIG. 7A and FIG. 7B, the network node adjusts the parameters for DRX for receiving downlink data by the terminal (120) and adjusts the buffer size of the buffer for transmitting the downlink data, but the present disclosure is not limited thereto. For example, the terminal (120) may transmit a signal requesting allocation of resources for transmitting uplink data within the on-interval for DRX in order to transmit uplink data. For example, the signal may include an SR (scheduling request). In this case, the timing at which the signal requesting allocation of resources for transmitting the uplink data is transmitted may be related to the buffer size within the buffer for transmitting the uplink data. For example, the terminal (120) may select (or determine) one candidate parameter from among the DRX sets in order to determine the buffer size for transmitting the uplink data. Accordingly, the terminal (120) may adjust the buffer size for transmitting the uplink data. Alternatively, for example, the base station (110) may adjust parameters for DRX by performing adaptive DRX to determine a buffer size for transmission of uplink data of the terminal (120) and transmit the adjusted parameters to the terminal (120). Accordingly, the terminal (120) may adjust the buffer size for transmission of uplink data. Specific details related thereto are described below in FIG. 10.

[0137] Figure 8 illustrates an example of a protocol stack for XR data.

[0138] FIG. 8 illustrates an example (800) of a protocol stack of a terminal (120) for processing downlink data received at the terminal (120) when the terminal (120) receives downlink data transmitted in operation (725) or operation (740). For example, the downlink data may be referred to as XR data.

[0139] Referring to example (800), the protocol stack of the terminal (120) may include a PHY / MAC (physical layer / media access control layer) (810), a RLC / PDCP (radio link control layer / packet data convergence protocol layer) (820), an IP (internet protocol) (830), a UDP (user datagram protocol) (840), an SRT (secure reliable transport) protocol (850), a codec (860), an AI module / user interface (870), and an application (880).

[0140] For example, in the protocol stack, among the PHY / MAC (810) and RLC / PDCP (820), the buffer size of the buffer for processing downlink data (or XR data) may be adjusted in the RLC. For example, the adjustment of the buffer size may be performed so that resource allocation is given priority over data for other services, depending on the characteristics of the XR data. For example, the characteristics of the XR data may include a relatively large data size, low latency, and real-time. For example, in the case of an XR application, the MAC layer can ensure low latency and high data throughput by giving priority to scheduling XR data (or XR traffic).

[0141] For example, XR data can be transmitted from a lower layer (or, PHY / MAC (810)) to an upper layer (or, RLC / PDCP (820)). For example, after processing is performed in the upper layer, the XR data can be transmitted to IP (830). For example, routing information for the XR data can be matched in IP (830).

[0142] For example, in UDP (840), SRT protocol (850), and codec (860), an encoding / decoding mechanism for XR data may be applied. For example, the encoding / decoding mechanism may include H.264.

[0143] For example, in the SRT protocol (850), processing of XR data for low latency support can be performed. Delivery of XR data (e.g., video and audio streaming) can be performed based on DASH (dynamic adaptive streaming over HTTP (hypertext transfer protocol)) to adjust the quality of the available bitrate. For example, MPEG-DASH (moving picture expert group-DASH) can be suitable for video on demand (VOD) scenarios where latency of packaging and playback is not an issue. In addition, DASH may be limited in applications such as live streaming due to the latency that may occur due to HTTP-based solutions. To address the above limitations, the SRT protocol (850) can be utilized.

[0144] For example, the adaptive DRX and buffering mechanism according to the present disclosure can provide efficient transmission of XR data with characteristics such as large capacity and low latency in RLC / MAC / PHY. In addition, the present disclosure can utilize the SRT protocol (850) to support low latency on the transport layer. The SRT protocol (850) can be suitable for applications for XR services. For example, the SRT protocol (850) can provide the best quality and lowest latency video suitable for XR applications by providing a video stream workflow. For example, the SRT protocol (850) can detect real-time network conditions between XR devices and adjust data transmission accordingly. For example, the SRT protocol (850) can compensate for jitter and bandwidth fluctuations due to network congestion. For example, the SRT protocol (850) can alleviate latency requirements to maintain a fully immersive experience of the XR device. For example, the SRT protocol (850) can support adaptive DRX mechanisms and different buffer partitioning on the network to provide flexibility in terms of bitrate, latency requirements, processing power, and split rendering for buffering.

[0145] For example, in the AI ​​module / user interface (870), XR data to be displayed in the XR application may be processed to conform to the hierarchical considerations in the application (880). For example, the AI ​​module may be utilized to provide an intelligent interface by customizing the interface to be provided to the user for the user. For example, in the application (880), display of the processed XR data may be performed. For example, the application (880) may include an XR application such as video gaming.

[0146] As described above, the present disclosure can reduce buffer delay for downlink data within a network by utilizing a cross-layer design, and provide flexibility in bitrate and latency requirements and processing capabilities for XR services. For example, in the cross-layer designed PHY layer, parameters for DRX can be adjusted using adaptive DRX. In addition, resource allocation for DRX can be performed in the cross-layer designed MAC layer, and buffering can be performed in the RLC / MAC / PHY layers. In addition, in the cross-layer designed SRT protocol, communication protocols can be integrated. Accordingly, the cross-layer design can reduce battery consumption, efficiently utilize network resources, and reduce latency by integrating adaptive technologies used in different layers of the protocol stack. For example, the cross-layer design can be utilized to ensure communication between XR devices (or an XR device and an XR server) by detecting variations in bandwidth, congestion, and latency while improving energy efficiency, resource utilization, and user experience in a wireless network. For example, the cross-layer design can be applied to 5GS delivery between an XR device (510) and an XR server (520) of FIG. 5.

[0147] Adaptive DRX according to the present disclosure can be applied to various usage scenarios. For example, a first usage scenario may be a battery saving scenario utilizing spatial mapping of collaborative XR devices. For example, a second usage scenario may be a battery saving scenario utilizing DoF according to the user interface (UI) / user experience (UX) module of the XR devices.

[0148] In the first usage scenario, when computations are performed collaboratively between XR devices, the computations may be distributed and performed among the XR devices to minimize energy consumption of the XR devices. For example, the collaborative computations among the XR devices may include a case where users are playing a game collaboratively in a video gaming application such as soccer. By distributing the computations, the computation time and processing time may be reduced. A specific XR device may change to wake mode when an object (e.g., a ball) is positioned nearby, and other XR devices may be in sleep mode. For example, the XR devices in the sleep mode may operate in sleep mode according to one of static DRX, DRX set, and adaptive DRX DRX settings. For example, the length of the sleep mode (or off-interval) may be adjusted depending on the channel condition, as it is related to the length of the on-interval. For example, XR data can be rendered and provided within a network node (e.g., an XR server (520) of FIG. 5) as shown in FIG. 5. In this case, XR devices can perform spatial mapping between XR devices to detect objects (e.g., a ball) in an unidentified external environment using simultaneous localization and mapping (SLAM). In this case, by using adaptive DRX, the energy of an application for immersive video games of XR devices can be reduced.

[0149] Regarding the second usage scenario, determining when and how to segment DoF within XR applications can be unclear. Automating the process of determining DoF segmentation based on the occurrence of specific events could potentially save energy for UI / UX design on XR devices. Furthermore, predicting the number and type of DoF could be informed through the application based on changes in content and tracking capabilities. Time-series analysis of tracking data could be performed using methods such as ARIMA or Extended Kalman filters. Furthermore, utilizing learning algorithms could increase accuracy by minimizing the error between content and tracking capabilities. Currently, manual rotation of DoF may be dominant. However, there may be an opportunity to transition to automated processing triggered by specific events. Such a predictive approach could anticipate events and adjust rotations accordingly. Battery consumption while running applications within the XR device can be further attributed to 360° rotational object tracking in yaw, roll and pitch, where the adaptive DRX mechanism can increase better user experience by reducing energy consumption on the device.

[0150] Figure 9 illustrates an example of an operational flow for a method in which a network node transmits downlink data based on adaptive DRX.

[0151] At least some of the methods of FIG. 9 may be performed by a network node. For example, the network node may be, for example, the base station (110) of FIG. 1 or the XR server (520) of FIG. 5. For example, at least some of the methods may be controlled by a processor of the network node (e.g., the processor (430) of FIG. 4). In the embodiments described below, the operations may be performed sequentially, but are not necessarily performed sequentially. For example, the order of the operations may be changed, and at least two operations may be performed in parallel.

[0152] In operation (900), the network node may identify downlink data to be transmitted via a data session having a designated QoS profile. For example, the downlink data to be transmitted may represent data subsequent to downlink data transmitted within an on-interval (e.g., on-interval (611) of FIG. 6) according to a cycle of long DRX. For example, the network node may identify the downlink data to be transmitted via the data session having the designated QoS profile in order to provide an XR service to the terminal (120). For example, the downlink data may be referred to as XR data.

[0153] In operation (910), the network node may determine whether the downlink data will be transmitted within an on-period (e.g., on-period (621) of FIG. 6) according to a cycle of short DRX that is initiated when the inactivity timer of the DRX set for the terminal (120) expires. For example, the network node may determine whether the downlink data will be transmitted within an on-period according to a cycle of short DRX that is initiated when the inactivity timer of the DRX set for the terminal (120) expires.

[0154] In operation (920), the network node may adjust the length of the on-interval for DRX based on channel information. For example, the network node may adjust the length of the on-interval for DRX based on channel information when it determines that the downlink data will be transmitted within an on-interval (e.g., on-interval (621) of FIG. 6) according to a cycle of short DRX.

[0155] For example, the channel information may include channel state information (CSI) received from the terminal (120) or channel information estimated using a reference signal (e.g., a sounding reference signal (SRS)) received from the terminal (120). For example, the network node may identify the channel information by checking packet / signaling statistics. For example, the network node may identify a value indicating the quality of a channel between the terminal (120) and the network node, as indicated by the channel information. As a non-limiting example, the value indicating the quality may include channel quality information (CQI). For example, the value indicating the quality may be referred to as a quality value or a quality level.

[0156] For example, the network node may compare the value representing the quality with reference values. For example, the reference values ​​may include a first reference value and a second reference value that is less than the first reference value. For example, based on the value that is greater than the first reference value, the network node may adjust the length of the on-interval for the DRX (e.g., length (630) of FIG. 6) from a first length to a second length that is shorter than the first length. For example, the first length may be referred to as a reference length, an initial length, or a previous length. For example, based on the value that is less than the second reference value, the network node may adjust the length of the on-interval for the DRX from the first length to a third length that is longer than the first length. For example, depending on the value between the first reference value and the second reference value, the network node may maintain (or refrain from adjusting) the length of the on-interval for the DRX to the first length. In the above example, a case of adjusting the length of the on-interval for the DRX based on the channel information is described, but the present disclosure is not limited thereto. For example, the network node may adjust a parameter for DRX (e.g., a length of an inactivity timer, a length of the cycle of a short DRX, a length of a cycle of a long DRX, or a length of an on-interval) based on the channel information.

[0157] In operation (930), the network node may adjust a buffer size based on the adjusted length of the on-interval. For example, the network node may adjust a buffer size of a buffer for transmitting downlink data of the network node based on the adjusted length of the on-interval for DRX. For example, the network node may adjust the buffer size of the buffer to store (or buffer) downlink data determined based on the channel information to be transmitted within the on-interval for DRX, which is determined based on the adjusted length of the on-interval for DRX. For specific details on a method for adjusting the buffer size of the buffer, reference may be made to FIG. 7B.

[0158] In operation (940), the network node may transmit the stored downlink data within the on-period according to the cycle of the short DRX. For example, the network node may transmit the downlink data stored in the buffer within the on-period according to the cycle of the short DRX. At this time, the on-period according to the cycle of the short DRX in which the stored downlink data is transmitted may be the on-period according to the cycle of the short DRX determined in operation (910) (e.g., on-period (621) of FIG. 6) or an on-period after the on-period according to the cycle of the short DRX determined in operation (910) (e.g., on-period (622) or on-period (623) of FIG. 6). In one example, the on-interval according to the cycle of short DRX during which the stored downlink data is transmitted may be an on-interval according to the cycle of short DRX (e.g., on-interval (621) in FIG. 6) at which the stored downlink data was originally determined to be transmitted, when the amount of data stored in the buffer exceeds a certain level. Alternatively, the on-interval according to the cycle of short DRX during which the stored downlink data is transmitted may be an on-interval according to the cycle of short DRX (e.g., on-interval (622) or on-interval (623) in FIG. 6) after the time at which the downlink data is stored in the buffer and the stored downlink data is originally determined to be transmitted, when the amount of data stored in the buffer is less than the certain level.

[0159] Figure 10 illustrates an example of an operation flow for a method in which a terminal transmits uplink data based on adaptive DRX.

[0160] At least some of the above methods of FIG. 10 may be performed by the terminal (120). For example, the terminal (120) may be an example of the terminal (120) of FIG. 1, the terminal (120) of FIGS. 2A to 3B, or the XR device (510) of FIG. 5. For example, at least some of the above methods may be controlled by a processor of the terminal (120) (e.g., the processor (430) of FIG. 4). In the following embodiments, the operations may be performed sequentially, but are not necessarily performed sequentially. For example, the order of the operations may be changed, and at least two operations may be performed in parallel.

[0161] Although not illustrated in FIG. 10, a data session may be established between a terminal (120) and a network node. For example, the network node may be an example of the base station (110) of FIG. 1 or the XR server (520) of FIG. 5. For example, the data session may include a session for performing communication between the network node and the terminal (120). For example, the data session may include a packet data unit (PDU) session. For example, the data session may include a bearer (or data radio bearer (DRB)). For example, the data session may include a quality of service (QoS) flow. For example, the data session may correspond to (or be mapped to) a QoS class identifier (QCI). For example, the QCI may be mapped to exemplary services that may be provided. For example, a QCI may be referenced as a QoS profile.

[0162] Before performing operation (1000), the terminal (120) can identify a data session having a designated QoS profile set for the terminal (120). For example, the terminal (120) can identify the data session having the designated QoS profile in order to provide an XR service. For example, the designated QoS profile can correspond to (or be mapped to) the XR service. For example, the terminal (120) can use the data session having the designated QoS profile in order to provide downlink data (or XR data) for the XR service. For example, the XR data can include video data having a high level of resolution rendered in an XR application.

[0163] Before performing operation (1000), the network node may transmit downlink data to the terminal (120) through the data session. For example, the network node may transmit downlink data to the terminal (120) performing the DRX operation. For example, the network node may transmit downlink data to the terminal (120) within an on-period (e.g., on-period (611) of FIG. 6) according to a cycle of long DRX during the DRX operation. The terminal (120) may start an inactivity timer for DRX (e.g., inactivity timer (650) of FIG. 6) upon receiving downlink data within the on-period according to the cycle of the long DRX. For example, the terminal (120) may perform monitoring for reception of downlink data until the inactivity timer expires. After this, the terminal (120) can initiate short DRX after the inactivity timer expires. At this time, the network node can identify that the terminal (120) initiates the inactivity timer after transmitting downlink data to the terminal (120) within the on-period according to the cycle of the long DRX, and that the initiated inactivity timer has expired. For example, the network node can identify that the terminal (120) is performing short DRX when the inactivity timer expires.

[0164] Before performing operation (1000), the terminal (120) may receive a message including parameters for DRX from the network node. For example, the terminal (120) may perform a DRX operation using the parameters for DRX in the received message.

[0165] In operation (1000), the terminal (120) may identify uplink data to be transmitted through a data session having a designated QoS profile. For example, the uplink data to be transmitted may indicate data to be transmitted within an on-period (e.g., on-period (621) of FIG. 6) according to a short DRX cycle following an on-period (e.g., on-period (611) of FIG. 6) according to a long DRX cycle. For example, the terminal (120) may identify the uplink data to be transmitted through the data session having the designated QoS profile in order to provide an XR service to the terminal (120). For example, the uplink data may be referred to as XR data.

[0166] In operation (1010), the terminal (120) may determine whether the uplink data will be transmitted within an on-period according to a cycle of short DRX initiated as a DRX inactivity timer expires. The terminal (120) may determine whether the uplink data identified in operation (1000) will be transmitted within an on-period according to a cycle of short DRX. In one example, the terminal (120) may determine whether the uplink data will be immediately transmitted within an on-period according to a cycle of short DRX initiated as the DRX inactivity timer expires. In this case, immediately transmitted within the on-period may include transmitted within a first on-period (or an on-period prior to a reference number of times) of short DRX.

[0167] In operation (1020), the terminal (120) may adjust the length of the on-interval for DRX. For example, the terminal (120) may adjust the length of the on-interval for DRX when it is determined that the uplink data identified in operation (1000) will be transmitted within the on-interval according to the cycle of the short DRX.

[0168] In one example, the terminal (120) may receive a DRX set from the network node. For example, the DRX set may represent a set of candidate parameters for DRX. For convenience of explanation, it is assumed below that the parameter for DRX is the length of an on-interval for DRX. For example, the DRX set may include a plurality of candidate lengths of an on-interval for DRX. For example, the terminal (120) may select (or determine) one of the plurality of candidate lengths as a parameter to be used for DRX based on channel information. For example, the terminal (120) may adjust the selected candidate length to the length of an on-interval for DRX.

[0169] Alternatively, in one example, the terminal (120) may receive a message from the network node containing parameters for DRX adjusted based on channel information. For example, the adjusted parameters for DRX may indicate a result based on adaptive DRX. For example, the adjusted parameters may include the length (or adjusted length) of an on-interval for DRX.

[0170] Alternatively, in one example, when the network node performs adaptive DRX, if there are both adjusted parameters for DRX determined by the network node for downlink transmission and adjusted parameters for DRX selected by the terminal (120), the network node may select one of the two. Accordingly, the network node may cause the terminal (120) to transmit uplink data immediately. For example, if the adjusted parameters (e.g., length of a timer, length of an on-interval) for DRX selected by the terminal (120) are shorter than the adjusted parameters for DRX selected by the network, the network node may select the adjusted parameters for DRX selected by the terminal (120). Or, for example, if the amount of data stored in the buffer of the network node for downlink transmission is not large, the network node may select the adjusted parameters for DRX selected by the network node. Accordingly, the terminal (120) can perform uplink transmission in a relatively short time (or immediately).

[0171] In operation (1030), the terminal (120) may adjust the buffer size based on the adjusted length of the on-interval. For example, the terminal (120) may adjust the buffer size based on the adjusted parameter of the DRX. However, the present disclosure is not limited thereto. For example, the terminal (120) may adjust the buffer size based on channel information acquired (or identified) by the terminal (120) and the adjusted parameter. For example, the terminal (120) may identify a value indicating the quality of the channel between the network node and the terminal (120). For example, the terminal (120) may adjust the buffer size of the terminal from a first size to a second size larger than the first size based on the parameter (or the adjusted parameter) for DRX of the message and the value exceeding a first reference value. For example, the terminal (120) may adjust the buffer size of the terminal from the first size to a third size smaller than the first size based on the parameter (or adjusted parameter) for DRX of the message and the value being less than the second reference value that is less than the first reference value. For example, the terminal (120) may maintain the buffer size of the terminal at the first size based on the parameter (or adjusted parameter) for DRX of the message and the value between the first reference value and the second reference value.

[0172] In operation (1040), the terminal (120) may transmit a signal requesting resources for transmitting uplink data based on the adjusted buffer size within an on-interval (e.g., on-interval (621) of FIG. 6) having an adjusted length according to a cycle of short DRX. For example, the terminal (120) may transmit the signal requesting allocation of resources to the network node in order to transmit the stored uplink data based on the adjusted buffer size within the on-interval having the adjusted length. For example, the signal requesting allocation of resources may include an SR.

[0173] For example, the terminal (120) can receive resource allocation information according to the SR within an on-interval (e.g., on-interval (622) of FIG. 6) having the adjusted length according to the cycle of the short DRX. For example, the terminal (120) can transmit uplink data stored in a buffer having the adjusted buffer size to the network node within an on-interval (e.g., on-interval (623) of FIG. 6) having the adjusted length according to the cycle of the short DRX.

[0174] The effects that can be obtained from the present disclosure are not limited to the effects mentioned above, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the art to which the present disclosure belongs from the description below.

[0175] A device of a network node as described above may include a memory storing instructions. The device may include at least one processor. The instructions, when individually or collectively executed by the at least one processor, may cause the device to identify downlink data to be transmitted over a data session having a designated quality of service (QoS) profile. The instructions, when individually or collectively executed by the at least one processor, may cause the device to determine whether the downlink data is to be transmitted within an on-duration according to a cycle of a short DRX (discontinuous reception) that is initiated when an inactivity timer of a DRX configured for a terminal expires. The instructions, when individually or collectively executed by the at least one processor, may cause the device to adjust a length of the on-interval for the DRX based on channel information of a channel between the terminal and the network node, upon determining that the downlink data is to be transmitted within the on-interval. The instructions, when individually or collectively executed by the at least one processor, may cause the device to adjust a buffer size of the network node based on the adjusted length of the on-interval, upon determining that the downlink data is to be transmitted within the on-interval. The instructions, when individually or collectively executed by the at least one processor, may cause the device to transmit the downlink data to the terminal based on the adjusted buffer size, upon determining that the downlink data is to be transmitted within the on-interval.

[0176] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the device to transmit other downlink data over the data session within an ON-interval according to a cycle of a long DRX of the DRX configured for the terminal before the ON-interval according to the cycle of the short DRX. The instructions, when individually or collectively executed by the at least one processor, may cause the device to identify that the inactivity timer initiated upon transmission of the other downlink data within the ON-interval according to the cycle of the long DRX has expired.

[0177] According to one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the device to transmit a message to the terminal, the message including the adjusted length of the on-interval for the DRX. The message may authorize the terminal to adjust a buffer size of the terminal using the adjusted length of the on-interval.

[0178] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the device to identify a value indicative of a quality of the channel indicated by the channel information. The instructions, when individually or collectively executed by the at least one processor, may cause the device to adjust the length of the on-interval for the DRX from a first length to a second length shorter than the first length, and based on the second length, adjust the buffer size of the network node from a first size to a second size greater than the first size. The instructions, when individually or collectively executed by the at least one processor, may cause the device to adjust the length of the on-interval for the DRX from the first length to a third length greater than the first length, and based on the third length, adjust the buffer size of the network node from the first size to a third size less than the first size. The instructions, when individually or collectively executed by the at least one processor, may cause the device to maintain the length of the on-interval for the DRX at the first length, and based on the first length, maintain the buffer size of the network node at the first size, depending on the value between the first reference value and the second reference value.

[0179] According to one embodiment, the buffer size of the network node may be adjusted from the first size to the second size or the third size, or maintained at the first size, based on an artificial intelligence model, using the length of the on-interval for the DRX.

[0180] According to one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the device to adjust a parameter for the DRX based on the channel information of the channel between the terminal and the network node, and to adjust the buffer size of the network node based on the adjusted parameter for the DRX, when the device determines that the downlink data is to be transmitted within the on-interval. The parameter for the DRX may include at least one of a length of the inactivity timer, a length of the cycle of the short DRX, a length of the cycle of the long DRX, or the length of the on-interval.

[0181] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the device to receive, from the terminal, a parameter associated with the terminal. The instructions, when individually or collectively executed by the at least one processor, may cause the device to adjust the length of the on-interval for the DRX based on the channel information and the parameter associated with the terminal, upon determining that the downlink data is to be transmitted within the on-interval. The parameter associated with the terminal may include at least one of battery information of the terminal or capacity information of a buffer of the terminal for receiving downlink data.

[0182] According to one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the device to store the downlink data in a buffer of the network node having the adjusted buffer size. The instructions, when individually or collectively executed by the at least one processor, may cause the device to transmit the stored downlink data to the terminal within an on-interval having the adjusted length according to the cycle of the short DRX.

[0183] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the device to identify other downlink data to be transmitted within an on-period according to a cycle of long DRX switched from short DRX upon determining that the downlink data will not be transmitted within the on-period. The instructions, when individually or collectively executed by the at least one processor, may cause the device to store the other downlink data within the buffer having the buffer size upon determining that the downlink data will not be transmitted within the on-period. The instructions, when individually or collectively executed by the at least one processor, may cause the device to transmit the stored other downlink data to the terminal within an on-period having the length according to the cycle of long DRX upon determining that the downlink data will not be transmitted within the on-period.

[0184] According to one embodiment, the downlink data may include data for an extended reality (XR) service. The terminal may include a device that provides the XR service. The network node may include a server that provides the XR service.

[0185] As described above, a terminal may include at least one transceiver. The terminal may include a memory storing instructions and including one or more storage media. The terminal may include at least one processor including a processing circuit. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to identify uplink data to be transmitted over a data session having a designated quality of service (QoS) profile. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to determine whether the uplink data is to be transmitted within an on-duration according to a cycle of a short DRX (discontinuous reception) that is initiated when an inactivity timer of the DRX expires. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to adjust a length of the on-interval for the DRX as the uplink data is determined to be transmitted within the on-interval. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to adjust a buffer size of the terminal based on the adjusted length of the on-interval as the uplink data is determined to be transmitted within the on-interval.The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to transmit, to a network node, a signal requesting resources for transmitting the uplink data based on the adjusted buffer size within the on-interval having the adjusted length according to the cycle of the short DRX, upon determining that the uplink data is to be transmitted within the on-interval.

[0186] According to one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the terminal to receive, from the network node, a message including the length of the on-interval for the DRX adjusted by the network node.

[0187] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the terminal to identify a value indicative of a quality of a channel between the network node and the terminal. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to adjust the buffer size of the terminal from a first size to a second size greater than the first size, based on the adjusted length of the message and the value being greater than a first threshold value. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to adjust the buffer size of the terminal from the first size to a third size less than the first size, based on the adjusted length of the message and the value being less than a second threshold value that is less than the first threshold value. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to maintain the buffer size of the terminal at the first size based on the adjusted length of the message and the value between the first reference value and the second reference value.

[0188] According to one embodiment, the buffer size of the terminal may be adjusted from the first size to the second size or the third size, or maintained at the first size, based on an artificial intelligence model, using the length and the value of the on-interval for the DRX.

[0189] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the terminal to receive, from the network node, a message including a plurality of candidate lengths of the on-interval for the DRX. The instructions, when individually or collectively executed by the at least one processor, may cause the terminal to adjust the length of the on-interval for the DRX to a candidate length among the plurality of candidate lengths.

[0190] In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the terminal to transmit, to the network node, a message including the length of the on-interval for the DRX adjusted to the candidate length among the plurality of candidate lengths. In one embodiment, the instructions, when individually or collectively executed by the at least one processor, may cause the terminal to receive, from the network node, a message including the adjusted length of the on-interval for the DRX. The adjusted length of the on-interval of the message received from the network node may be determined as one of a parameter for DRX for downlink transmission determined by the network node and a parameter for DRX for uplink transmission determined by the terminal, based on a comparison between an amount of data stored in a buffer of the network node or a parameter for DRX for downlink transmission and a parameter for DRX for uplink transmission.

[0191] The method performed by the network node as described above may include an operation of identifying downlink data to be transmitted through a data session having a designated quality of service (QoS) profile. The method may include an operation of determining whether the downlink data is to be transmitted within an on-duration according to a cycle of a short DRX (discontinuous reception) that is initiated when an inactivity timer of a DRX configured for a terminal expires. The method may include an operation of adjusting a length of the on-duration for the DRX based on channel information of a channel between the terminal and the network node, upon determining that the downlink data is to be transmitted within the on-duration. The method may include an operation of adjusting a buffer size of the network node based on the adjusted length of the on-duration, upon determining that the downlink data is to be transmitted within the on-duration. The method may include an operation of transmitting the downlink data to the terminal based on the adjusted buffer size, upon determining that the downlink data is to be transmitted within the on-interval.

[0192] According to one embodiment, the method may include an operation of transmitting other downlink data through the data session within an on-period according to a long DRX cycle of the DRX configured for the terminal, before the on-period according to the cycle of the short DRX. The method may include an operation of identifying that the inactivity timer, which is initiated upon completion of transmission of the other downlink data within the on-period according to the cycle of the long DRX, has expired.

[0193] In one embodiment, the method may include transmitting a message including the adjusted length of the on-interval for the DRX to the terminal. The message may authorize the terminal to adjust a buffer size of the terminal using the adjusted length of the on-interval.

[0194] According to one embodiment, the method may include an operation of identifying a value representing a quality of the channel indicated by the channel information. The method may include an operation of adjusting the length of the on-interval for the DRX from a first length to a second length longer than the first length, based on the value being greater than a first reference value, and an operation of adjusting the buffer size of the network node from a first size to a second size larger than the first size, based on the second length. The method may include an operation of adjusting the length of the on-interval for the DRX from the first length to a third length shorter than the first length, based on the value being less than a second reference value that is less than the first reference value, and an operation of adjusting the buffer size of the network node from the first size to a third size smaller than the first size, based on the third length. The method may include an operation of maintaining the length of the on-interval for the DRX to the first length based on the value between the first reference value and the second reference value, and an operation of maintaining the buffer size of the network node to the first size based on the first length.

[0195] The non-transitory computer-readable storage medium as described above may store one or more programs including instructions that, when individually or collectively executed by at least one processor of a network node, cause the network node to identify downlink data to be transmitted over a data session having a designated quality of service (QoS) profile. The non-transitory computer-readable storage medium may store one or more programs including instructions that, when individually or collectively executed by the at least one processor, cause the network node to determine whether the downlink data is to be transmitted within an on-duration according to a cycle of a short DRX (discontinuous reception) that is initiated when an inactivity timer of a DRX configured for a terminal expires. The non-transitory computer-readable storage medium may store one or more programs including instructions that, when individually or collectively executed by the at least one processor, cause the network node to adjust a length of the on-interval for the DRX based on channel information of a channel between the terminal and the network node when the downlink data is determined to be transmitted within the on-interval. The non-transitory computer-readable storage medium may store one or more programs including instructions that, when individually or collectively executed by the at least one processor, cause the network node to adjust a buffer size of the network node based on the adjusted length of the on-interval when the downlink data is determined to be transmitted within the on-interval.The non-transitory computer-readable storage medium may store one or more programs including instructions that, when individually or collectively executed by the at least one processor, cause the network node to transmit the downlink data to the terminal based on the adjusted buffer size when the network node determines that the downlink data is to be transmitted within the on-interval.

[0196] The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0197] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors in an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specifications of the present disclosure. The one or more programs may be provided as included in a computer program product. The computer program product may be traded between sellers and buyers as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read only memory (CD-ROM)) or an application store (e.g., Play Store). 쪠) or directly between two user devices (e.g., smart phones), online distribution (e.g., downloading or uploading). In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0198] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage devices, compact disc-ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage devices, magnetic cassettes, or may be stored in memories formed by a combination of some or all of these. In addition, each configuration memory may include multiple copies.

[0199] Additionally, the program may be stored on an attachable storage device that is accessible via a communication network, such as the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device implementing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device implementing an embodiment of the present disclosure.

[0200] In the specific embodiments of the present disclosure described above, components included in the disclosure are expressed singularly or plurally, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in plural may be composed of singular elements, or components expressed in singular may be composed of plural elements.

[0201] According to embodiments, one or more of the components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., modules or programs) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

[0202] Meanwhile, although the detailed description of the present disclosure has described specific embodiments, it is obvious that various modifications are possible within the scope of the present disclosure.

Claims

1. In the network node device, Memory that stores instructions; and Contains at least one processor, The above instructions, when individually or collectively executed by the at least one processor, cause the device to: Identify downlink data to be transmitted through a data session having a specified quality of service (QoS) profile; It is determined whether the above downlink data will be transmitted within the on-duration according to the cycle of short DRX (discontinuous reception) that is initiated when the inactivity timer of DRX (discontinuous reception) set for the terminal expires; As the above downlink data is determined to be transmitted within the above on-interval: Based on the channel information of the channel between the terminal and the network node, the length of the on-interval for the DRX is adjusted, Based on the adjusted length of the above on-interval, adjust the buffer size of the network node, and Based on the above adjusted buffer size, causing the downlink data to be transmitted to the terminal, device.

2. In claim 1, The above instructions, when individually or collectively executed by the at least one processor, cause the device to: Before the on-period according to the cycle of the short DRX, within the on-period according to the cycle of the long DRX of the DRX set to the terminal, other downlink data is transmitted through the data session; and Causing the inactivity timer, which is initiated by transmission of the other downlink data within the on-interval according to the cycle of the long DRX, to expire, device.

3. In claim 1, The above instructions, when individually or collectively executed by the at least one processor, cause the device to: Causes the terminal to transmit a message including the adjusted length of the on-interval for the DRX, The above message authorizes the terminal to adjust the buffer size of the terminal using the adjusted length of the on-interval. device.

4. In claim 1, The above instructions, when individually or collectively executed by the at least one processor, cause the device to: Identify a value representing the quality of the channel indicated by the channel information; According to the above values ​​exceeding the first reference value: Adjusting the length of the on-section for the DRX from a first length to a second length shorter than the first length, and Based on the second length, the buffer size of the network node is adjusted from the first size to a second size larger than the first size; According to the above value being less than the second reference value which is less than the first reference value: Adjusting the length of the on-section for the DRX from the first length to a third length longer than the first length, and Based on the third length, adjusting the buffer size of the network node from the first size to a third size smaller than the first size; and According to the above values ​​between the first reference value and the second reference value: Maintaining the length of the on-section for the DRX as the first length, and Based on the first length, causing the buffer size of the network node to be maintained at the first size, device.

5. In claim 4, The buffer size of the network node is adjusted from the first size to the second size or the third size or maintained at the first size based on an artificial intelligence model using the length of the on-interval for the DRX. device.

6. In claim 1, The above instructions, when individually or collectively executed by the at least one processor, cause the device to: As the above downlink data is determined to be transmitted within the above on-interval: Adjusting parameters for the DRX based on the channel information of the channel between the terminal and the network node, and Based on the adjusted parameters for the DRX, causing the buffer size of the network node to be adjusted, The above parameters for the above DRX are: The length of the above inactivity timer, The length of the above cycle of the above short DRX, The length of the cycle of long DRX, or Containing at least one of the above lengths of the above on-section, device.

7. In claim 1, The above instructions, when individually or collectively executed by the at least one processor, cause the device to: Receive parameters related to the terminal from the terminal; and When the downlink data is determined to be transmitted within the on-interval, the length of the on-interval for the DRX is adjusted based on the channel information and the parameters related to the terminal. The parameter related to the terminal includes at least one of battery information of the terminal or capacity information of a buffer of the terminal for receiving downlink data. device.

8. In claim 1, The above instructions, when individually or collectively executed by the at least one processor, cause the device to: storing the downlink data in a buffer of the network node having the adjusted buffer size; and Causing the stored downlink data to be transmitted to the terminal within the on-interval having the adjusted length according to the cycle of the short DRX. device.

9. In claim 8, The above instructions, when individually or collectively executed by the at least one processor, cause the device to: As it is determined that the above downlink data will not be transmitted within the above on-interval: Identify other downlink data to be transmitted within the on-period according to the cycle of the long DRX switched from the above short DRX; storing the other downlink data in the buffer having the buffer size; and Causing the terminal to transmit the other stored downlink data within the on-interval having the length according to the cycle of the long DRX. device.

10. In claim 1, The above downlink data includes data for XR (extended reality) service, The terminal includes a device that provides the XR service, and The above network node includes a server that provides the XR service. device.

11. In the terminal, At least one transmitter / receiver; A memory storing instructions and including one or more storage media; and At least one processor comprising a processing circuit, The above instructions, when individually or collectively executed by the at least one processor, cause the terminal to: Identify uplink data to be transmitted through a data session having a specified quality of service (QoS) profile; Determine whether the above uplink data will be transmitted within the on-duration according to the cycle of short DRX (discontinuous reception) that is initiated when the inactivity timer of DRX (discontinuous reception) expires; As the above uplink data is determined to be transmitted within the above on-interval: Adjusting the length of the above on-interval for the above DRX, and Adjusting the buffer size of the terminal based on the adjusted length of the above-mentioned on-interval; and Causing a network node to transmit a signal requesting resources for transmitting the uplink data based on the adjusted buffer size within an on-interval having the adjusted length according to the cycle of the short DRX. Terminal.

12. In claim 11, The above instructions, when individually or collectively executed by the at least one processor, cause the terminal to: Causing the network node to receive a message including the length of the on-interval for the DRX adjusted by the network node, Terminal.

13. In claim 12, The above instructions, when individually or collectively executed by the at least one processor, cause the terminal to: Identify a value representing the quality of the channel between the network node and the terminal; Based on the adjusted length of the message and the value exceeding the first reference value, the buffer size of the terminal is adjusted from the first size to a second size larger than the first size; Based on the adjusted length of the message and the value being less than the second reference value which is less than the first reference value, adjusting the buffer size of the terminal from the first size to a third size smaller than the first size; and Causing the buffer size of the terminal to be maintained at the first size based on the adjusted length of the message and the value between the first reference value and the second reference value. Terminal.

14. In claim 13, The buffer size of the terminal is adjusted from the first size to the second size or the third size or maintained at the first size based on an artificial intelligence model using the length and the value of the on-interval for the DRX. Terminal.

15. In a non-transitory computer-readable storage medium, when individually or collectively executed by at least one processor of a network node, said network node: Identify downlink data to be transmitted through a data session having a specified quality of service (QoS) profile; It is determined whether the above downlink data will be transmitted within the on-duration according to the cycle of short DRX (discontinuous reception) that is initiated when the inactivity timer of DRX (discontinuous reception) set for the terminal expires; As the above downlink data is determined to be transmitted within the above on-interval: Based on the channel information of the channel between the terminal and the network node, the length of the on-interval for the DRX is adjusted, Based on the adjusted length of the above on-interval, adjust the buffer size of the network node, and storing one or more programs including instructions that cause the downlink data to be transmitted to the terminal based on the adjusted buffer size; Non-transitory computer-readable storage medium.

Images