Communication apparatus and method for providing service in wireless communication system

Abstract

Provided is a method performed by a communication device which communicates with a terminal and provides functions of a PDCP layer. The communication device may comprise the operations of: determining whether a QoS identifier associated with a Data Radio Bearer for the terminal corresponds to a predetermined value; according to the determination that the QoS identifier does not correspond to the predetermined value, performing a reordering procedure by using a timer having a fixed value; according to the determination that the QoS identifier corresponds to the predetermined value, determining, in the PDCP layer, whether a loss event has occurred on the basis of PDCP data for the DRB received from a lower layer; and according to the determination that the loss event has occurred in the PDCP layer, performing a reordering procedure by using a timer having a reconstructed value on the basis of a loss rate. The reordering procedure may comprise, when the timer expires, transferring, to an upper layer, PDCP data stored in a reception buffer of the PDCP layer in an ascending order of count values.

Description

Communication device and method for providing services in a wireless communication system

[0001] The present disclosure relates to a communication device and a method for providing services in a wireless communication system.

[0002] A base station can transmit downlink data to a terminal. A terminal can transmit uplink data to a base station. Various protocols are used for communication between a terminal and a base station. These various protocols may include MAC (medium access control) layer protocols, RLC (radio link control) layer protocols, and PDCP (packet data convergence protocol) layer protocols.

[0003] The information described above may be provided as related art for the purpose of aiding understanding of the present disclosure. No claim or determination is made as to whether any of the foregoing may be applied as prior art related to the present disclosure.

[0004] In embodiments of the present disclosure, an apparatus is provided that provides functions of a packet data convergence protocol (PDCP) layer for communicating with a terminal. The apparatus may include at least one processor comprising a processing circuit; and a memory for storing instructions. When the instructions are executed individually or collectively by the at least one processor, the apparatus may determine whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the terminal corresponds to a predetermined value, and upon determining that the QoS identifier does not correspond to the predetermined value, perform a reordering procedure using a timer having a defined value, and upon determining that the QoS identifier corresponds to the predetermined value: in the PDCP layer, determine whether a loss event has occurred based on PDCP data for the DRB received from a lower layer, and upon determining that the loss event has occurred in the PDCP layer, perform a reordering procedure using a timer having a value identified based on the loss rate. The above reordering procedure may include transmitting PDCP data stored in the receiving buffer of the PDCP layer to the upper layer in ascending order of count values ​​when the timer expires.

[0005] In embodiments of the present disclosure, a method is provided by a device that provides functions of a packet data convergence protocol (PDCP) layer to communicate with a terminal. The method may include: an operation of determining whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the terminal corresponds to a predetermined value; an operation of performing a reordering procedure using a timer having a defined value upon determining that the QoS identifier does not correspond to the predetermined value; an operation of determining whether a loss event has occurred in the PDCP layer based on PDCP data for the DRB received from a lower layer upon determining that the QoS identifier corresponds to the predetermined value; and an operation of performing a reordering procedure using a timer having a value identified based on a loss rate upon determining that the loss event has occurred in the PDCP layer. The reordering procedure may include transmitting PDCP data stored in the receiving buffer of the PDCP layer to an upper layer in ascending order of count values ​​when the timer expires.

[0006] In embodiments of the present disclosure, a communication device is provided that communicates with a terminal and provides functions of a packet data convergence protocol (PDCP) layer. The communication device may include at least one processor comprising a processing circuit; and a memory for storing instructions. When the instructions are executed individually or collectively by the at least one processor, the communication device may determine whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the terminal corresponds to a predetermined value, and upon determining that the QoS identifier does not correspond to the predetermined value, perform a reordering procedure using a timer having a fixed value, and upon determining that the QoS identifier corresponds to the predetermined value: in the PDCP layer, determine whether a loss event has occurred based on PDCP data for the DRB received from a lower layer, and upon determining that the loss event has occurred in the PDCP layer, perform a reordering procedure using a timer having a reconfigured value based on the loss rate. The above reordering procedure may include transmitting PDCP data stored in the receiving buffer of the PDCP layer to the upper layer in ascending order of count values ​​when the timer expires.

[0007] In embodiments of the present disclosure, a method is provided by a communication device that communicates with a terminal and provides functions of a packet data convergence protocol (PDCP) layer. The method may include: determining whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the terminal corresponds to a predetermined value; performing a reordering procedure using a timer having a fixed value upon determining that the QoS identifier does not correspond to the predetermined value; determining whether a loss event has occurred in the PDCP layer based on PDCP data for the DRB received from a lower layer upon determining that the QoS identifier corresponds to the predetermined value; and performing a reordering procedure using a timer having a value reconstructed based on a loss rate upon determining that the loss event has occurred in the PDCP layer. The reordering procedure may include transmitting PDCP data stored in the receiving buffer of the PDCP layer to an upper layer in ascending order of count values ​​when the timer expires.

[0008] In embodiments of the present disclosure, a non-transient computer-readable storage medium may store instructions. The instructions may cause a communication device that communicates with a terminal and provides functions of a packet data convergence protocol (PDCP) layer, when executed collectively or individually by at least one processor, to perform operations including: determining whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the terminal corresponds to a predetermined value; performing a reordering procedure using a timer having a fixed value upon determining that the QoS identifier does not correspond to the predetermined value; determining whether a loss event has occurred in the PDCP layer based on PDCP data for the DRB received from a lower layer upon determining that the QoS identifier corresponds to the predetermined value; and performing a reordering procedure using a timer having a reconfigured value based on a loss rate upon determining that the loss event has occurred in the PDCP layer. The above reordering procedure may include transmitting PDCP data stored in the receiving buffer of the PDCP layer to the upper layer in ascending order of count values ​​when the timer expires.

[0009] Figure 1 shows an example of a wireless communication system.

[0010] Figure 2a shows an example of a control plane (C-plane).

[0011] Figure 2b shows an example of a user plane (U-plane).

[0012] Figures 3a and 3b show examples of function splitting.

[0013] Figure 4 shows an example of reordering at the PDCP (packet data convergence protocol) layer.

[0014] Figure 5 shows an example of a service provided to the UE (user equipment).

[0015] Figure 6 shows the operation flow of a communication device for performing reordering using a timer.

[0016] Figure 7 shows the operation flow of a communication device for determining the occurrence of a loss event.

[0017] Figure 8 shows an example of lost packet detection.

[0018] Figure 9 shows examples of components of a communication device.

[0019] The terms used in this disclosure are used merely to describe specific embodiments and are not intended to limit the scope of other embodiments. A singular expression may include a plural expression unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as generally understood by those skilled in the art described in this disclosure. Terms used in this disclosure that are defined in a general dictionary may be interpreted as having the same or similar meaning as they have in the context of the relevant technology, and are not to be interpreted in an ideal or overly formal sense unless explicitly defined in this disclosure. In some cases, even terms defined in this disclosure are not to be interpreted to exclude the embodiments of this disclosure.

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

[0021] Terms used in the following description to refer to signals (e.g., signal, information, message, signaling), terms to refer to data (e.g., packet, user stream, information, bit, symbol, codeword), terms to refer to resources (e.g., symbol, slot, subframe, radio frame, frame, subcarrier, RE (resource element), RB (resource block), BWP (bandwidth part), occasion), terms for operation states (e.g., step, operation, procedure), terms to refer to data (e.g., packet, user stream, protocol data unit (PDU), service data unit (SDU), information, bit, symbol, codeword), terms to refer to channels, terms to refer to network entities, terms to refer to device components, etc. are examples provided for the convenience of explanation. Accordingly, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used. Additionally, terms such as '...part', '...device', '...body' used below may refer to at least one shape structure or a unit that processes a function.

[0022] Additionally, in this disclosure, expressions of "greater than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled; however, this is merely for the purpose of expressing an example and does not exclude descriptions of "greater than" or "less than." Conditions described as "greater than" may be replaced with "greater than," conditions described as "less than" may be replaced with "less than," and conditions described as "greater than and less than" may be replaced with "greater than and less than." Furthermore, "A" to "B" below refer to at least one of elements from A (including A) to B (including B). Below, "C" and / or "D" refers to including at least one of "C" or "D," i.e., {"C", "D", "C" and "D"}.

[0023] This disclosure describes various embodiments using terms used in some communication standards (e.g., 3GPP (3rd Generation Partnership Project), ETSI (European Telecommunications Standards Institute), xRAN (extensible radio access network), O-RAN (open-radio access network), but these are merely illustrative examples. Various embodiments of this disclosure can be easily modified and applied to other communication systems.

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

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

[0026] A base station (110) is a network infrastructure that provides wireless access to a terminal (120). The base station (110) has coverage defined based on the distance over which it can transmit signals. In addition to being a base station, the base station (110) may be referred to as a 'RAN (radio access network) node', 'access point (AP)', 'eNodeB (eNB)', '5G node (5th generation node)', 'next generation nodeB (gNB)', 'wireless point', 'transmission / reception point (TRP)', 'communication node', 'communication device', 'electronic device', 'wireless communication device', 'wireless communication equipment', 'network node', 'network entity', or other terms having an equivalent technical meaning.

[0027] A terminal (120) is a device used by a user and communicates with a 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). Additionally, although not shown in FIG. 1, the terminal (120) and another terminal can 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 user involvement. According to 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 a narrowband (NB)-Internet of Things (IoT) device.

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

[0029] The base station (110) can perform beamforming with the terminal (120). 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). Additionally, 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) and a 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, beamforming may include transmit beamforming and receive beamforming. The base station (110) and the terminal (120) can impart directivity to the transmitted signal or the 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 a resource that has a QCL relationship with the resource that transmitted the serving beams.

[0030] The network between the base station (110) and the terminal (120) may be referred to as an access network or a RAN (radio access network). A set of network entities connected to the base station (110) may be referred to as a core network. For example, the core network may be a 5G core (5GC). For example, the core network may be an EPC (evolved packet core).

[0031] FIG. 2a shows an example of a control plane (C-plane). As a base station (110), a gNB is described as an example. As a terminal (120), a UE is described as an example.

[0032] Referring to FIG. 2a, in the C-plane, the UE (120) and the access and mobility management function (AMF) (235) can perform non-access stratum (NAS) signaling. The AMF (235) can provide functions related to mobility management of the UE (120), user registration, authentication, connection establishment, and / or release. In the C-plane, the UE (120) and the gNB (110) can perform communication according to a specified protocol at the radio resource control (RRC) layer, packet data convergence protocol (PDCP) layer, radio link control (RLC) layer, medium access control (MAC) layer, and physical (PHY) layer, respectively.

[0033] The main functions of the RRC layer may include at least some of the following functions.

[0034] - Broadcasting system information related to AS (Access Stratum) and NAS

[0035] - Paging initiated by 5GC (5G Core) or NG-RAN (Next Generation-Radio Access network)

[0036] - Establishment, maintenance, and release of the RRC connection between the UE and NG-RAN, including, specifically, control over RLC, MAC, and PHY:

[0037] - Adding, modifying, and removing Carrier Aggregation

[0038] - Add, modify, and disable dual connectivity between NR or E-UTRA and NR.

[0039] - Security features including Key Management;

[0040] - Setup, configuration, maintenance, and release of SRB (Signaling Radio Bearer) and DRB (Data Radio Bearer)

[0041] - Movement functions including the following:

[0042] - Handover and context transfer;

[0043] - UE cell selection and re-selection and cell selection and re-selection control;

[0044] - Mobility between RATs.

[0045] - QoS (quality of service) management function;

[0046] - UE measurement reporting and control of reporting;

[0047] - Radio link failure detection and recovery

[0048] - Send messages from / to UE to / from NAS.

[0049] The main functions of the PDCP layer may include at least some of the following functions.

[0050] - Header compression and decompression features (ROHC only)

[0051] - User data transfer function (Transfer of user data)

[0052] - Sequential delivery function (In-order delivery of upper layer PDU (protocol data unit)s)

[0053] - Out-of-order delivery of upper layer PDUs

[0054] - Reordering function (PDCP PDU reordering for reception) (hereinafter, reordering)

[0055] - Duplicate detection function (Duplicate detection of lower layer SDUs)

[0056] - Retransmission of PDCP SDUs

[0057] - Encryption and decryption functions (Ciphering and deciphering)

[0058] - Timer-based SDU discard in uplink.

[0059] The main functions of an RLC layer may include at least some of the following functions.

[0060] - Data transfer function (Transfer of upper layer PDUs)

[0061] - Sequential delivery function (In-sequence delivery of upper layer PDUs)

[0062] - Out-of-sequence delivery of upper layer PDUs

[0063] - ARQ function (Error Correction through ARQ)

[0064] - Concatenation, segmentation, and reassembly functions of RLC SDUs

[0065] - Re-segmentation function (Re-segmentation of RLC data PDUs)

[0066] - Reordering function (Reordering of RLC data PDUs)

[0067] - Duplicate detection

[0068] - Error detection function (Protocol error detection)

[0069] - RLC SDU discard function

[0070] RLC re-establishment function

[0071] The MAC layer can be connected to multiple RLC layer devices configured in a terminal, and the main functions of the MAC may include at least some of the following functions.

[0072] - Mapping function between logical channels and transport channels

[0073] - Multiplexing and demultiplexing of MAC SDUs

[0074] - Scheduling information reporting function

[0075] Error correction through HARQ

[0076] - Priority handling between logical channels of one UE

[0077] - Priority handling between UEs by means of dynamic scheduling

[0078] - MBMS service identification function

[0079] - Transport format selection function

[0080] - Padding

[0081] The physical layer can perform operations such as channel coding and modulating upper layer data, converting it into OFDM symbols for transmission over the wireless channel, or demodulating OFDM symbols received through the wireless channel, channel decoding, and transmitting them to the upper layer.

[0082] FIG. 2b shows an example of a user plane (U-plane). As a base station (110), a gNB is described as an example. As a terminal (120), a UE is described as an example.

[0083] Referring to FIG. 2b, in the U-plane, the UE (120) and gNB (110) can communicate according to a specified protocol in each of the SDAP layer, PDCP layer, RLC layer, MAC layer, and PHY layer. For the PDCP layer, RLC layer, MAC layer, and PHY layer, excluding the SDAP layer, the description of FIG. 2a may be referenced.

[0084] The SDAP layer can provide the QoS flow of 5GC. A single protocol entity of SDAP can be configured for each individual PDU session, and the functions of the SDAP layer may include at least some of the following functions.

[0085] - Mapping between QoS flow and data wireless bearer;

[0086] - Displays the QoS flow ID (identifier) ​​(QFI) in both DL and UL packets.

[0087] FIGS. 3a and 3b illustrate examples of function splitting. A base station (e.g., base station (110)) may operate as an eNB or a gNB depending on the radio access technology (RAT) provided. For example, the base station may be referred to as an NG-RAN node. The base station may be implemented in a distributed deployment according to a central unit (CU) configured to perform the functions of the upper layers of the access network (e.g., packet data convergence protocol (PDCP), radio resource control (RRC)) and a distributed unit (DU) configured to perform the functions of the lower layers.

[0088] Referring to FIG. 3a, in the control plane, a CU (310) is connected to one or more DUs (e.g., DU (320)) and can perform functions of a layer higher than the DU. For example, the CU (310) can perform the functions of the RRC layer (311) and the PDCP layer (312). The CU (310) can transmit or receive messages through the F1 interface (340) with the DU (320). In the control plane, the DU (320) can perform the functions of the RLC layer (321), the MAC layer (322), and the PHY layer (323). To explain the functions of the RRC layer (311) of the CU (310), the description of the RRC layer in FIG. 2a may be referenced. To explain the functions of the PDCP layer (312) of the CU (310), the description of the PDCP layer in FIG. 2a may be referenced. For an explanation of the functions of the RLC layer (321) of the DU (320), the description of the RLC layer in FIG. 2a may be referenced. For an explanation of the functions of the MAC layer (322) of the DU (320), the description of the MAC layer in FIG. 2a may be referenced. For an explanation of the functions of the PHY layer (323) of the DU (320), the description of the PHY layer in FIG. 2a may be referenced. The DU (320) can perform the operation of channel coding and modulating upper layer data through the physical layer (323), creating OFDM symbols and transmitting them over a wireless channel, or demodulating OFDM symbols received through the wireless channel and channel decoding them to transmit them to the upper layer.

[0089] Referring to FIG. 3b, in the user plane, a CU (310) is connected to one or more DUs (e.g., DU (320)) and can perform functions of a layer higher than the DU. For example, the CU (310) can perform functions of the SDAP layer (361) and the PDCP layer (362). The CU (310) can send or receive messages through the DU (320) and the F1 interface (350) (e.g., F1-U). The CU (310) can be referenced as a node hosting PDCP entities for the PDCP layer (362) in terms of performing functions for the PDCP layer (362). The DU (320) can be referenced as a node interacting with the node hosting the PDCP entities for flow control. In the user plane, the DU (320) can perform the functions of the RLC layer (371), MAC layer (372), and PHY layer (373). To explain the functions of the SDAP layer (361) of the CU (310), the description of the SDAP layer in FIG. 2b may be referenced. To explain the functions of the PDCP layer (362) of the CU (310), the description of the PDCP layer in FIG. 2b may be referenced. To explain the functions of the RLC layer (321) of the DU (320), the description of the RLC layer in FIG. 2b may be referenced. To explain the functions of the MAC layer (322) of the DU (320), the description of the MAC layer in FIG. 2b may be referenced. To explain the functions of the PHY layer (323) of the DU (320), the description of the PHY layer in FIG. 2b may be referenced.

[0090] In FIG. 3a and FIG. 3b, a DU (e.g., DU (320)) is depicted as being responsible for the physical layer (e.g., physical layer (323), physical layer (373)), but embodiments of the present disclosure are not limited thereto. According to an embodiment, the DU (320) may perform some functions of the physical layer (high PHY), and the RU connected to the DU (320) may be responsible for the remaining functions of the physical layer (low PHY). Additionally, as an example, the DU (digital unit) may be included in the DU (distributed unit) (320) according to the distributed deployment implementation of the base station. As an example, the DU (digital unit) may refer to an entity including the CU and the DU (distributed unit) in a structure arranged in the order of CU, DU (distributed unit), and RU.

[0091] In FIG. 3a and 3b, the CU (310) configured to perform the functions of the control plane layer is described as performing the functions of the user plane layer, but the embodiments of the present disclosure are not limited thereto. As a non-limiting example, a node configured to perform the functions of the control plane layer and a node configured to perform the functions of the user plane layer may be implemented separately. For example, a node configured to perform the functions of the control plane layer may operate as CU-CP (control plane), and a node configured to perform the functions of the user plane layer may operate as CU-UP (user plane).

[0092] FIG. 4 illustrates an example of reordering in a PDCP (packet data convergence protocol) layer (e.g., PDCP layer (362)). The PDCP layer may provide a reordering function to ensure the packet order for uplink packets in the NR standard. In referring to data in the PDCP layer, the terms SDU or PDU may be used. For example, data containing a PDCP header may be referred to as a PDU. For example, data not containing a PDCP header may be referred to as an SDU. Hereinafter, as a term to distinguish between data packets and control packets, PDU may be a PDCP data PDU or a PDCP control PDU. For reordering according to the embodiments of the present disclosure, PDU and PDCP PDU may represent a PDCP data PDU unless otherwise specified.

[0093] Referring to FIG. 4, communication can be performed between a transmitting PDCP entity (410) and a receiving PDCP entity (460). The transmitting PDCP entity (410) and the receiving PDCP entity (460) can be distinguished according to the entity transmitting the data and the entity receiving the data. For example, in downlink data transmission, the transmitting PDCP entity (410) may correspond to a base station (110) or a CU (310), and the receiving PDCP entity (420) may correspond to a terminal (120). For example, in uplink data transmission, the transmitting PDCP entity (410) may correspond to a terminal (120), and the receiving PDCP entity (420) may correspond to a base station (110) or a CU (310). For example, in sidelink data transmission, the transmitting PDCP entity (410) corresponds to a terminal (120), and the receiving PDCP entity (420) may correspond to another terminal.

[0094] The transmitting PDCP entity (410) can receive data (e.g., PDCP SDU (service data unit)) from an upper layer (e.g., SDAP layer, RRC layer). The transmitting PDCP entity (410) can perform sequence numbering (415). The transmitting PDCP entity (410) can determine a count value for the data through sequence numbering (415). For example, the transmitting PDCP entity (410) can determine a count value corresponding to the state variable 'TX_NEXT'. The count value can be associated with the data. The transmitting PDCP entity (410) can determine a sequence number (SN) for the data. For example, the transmitting PDCP entity (410) can determine the SN of the PDCP data PDU based on the state variable 'TX_NEXT' and modulo operation. The SN may be an integer greater than or equal to 0 and less than [2[PDCP_size]-1]. 'PDCP_size' can be configured by an upper layer (e.g., RRC layer). 'PDCP_size' can be 12-bit or 18-bit. For example, if the PDCP data PDU is uplink data, 'PDCP_size' for the uplink can be configured by an upper layer (e.g., RRC layer). For example, if the PDCP data PDU is downlink data, 'PDCP_size' for the downlink can be configured by an upper layer (e.g., RRC layer). For example, if the PDCP data PDU is sidelink data, 'PDCP_size' for the sidelink can be configured by an upper layer (e.g., RRC layer). Subsequently, the transmitting PDCP entity (410) can increment the state variable 'TX_NEXT' by 1. That is, the state variable 'TX_NEXT' can be the count value of the next PDCP SDU to be transmitted.

[0095] Although not illustrated in FIG. 4, the transmitting PDCP entity (410) can perform various functions in addition to sequence numbering (415). For example, the transmitting PDCP entity (410) can perform header compression on the data using ROHC (robust header compression). For example, the transmitting PDCP entity (410) can perform integrity protection and ciphering. For example, the transmitting PDCP entity (410) can generate a PDCP PDU by adding a PDCP header to the data. The transmitting PDCP entity (410) can transmit the result of the functions performed (e.g., PDCP PDU) to the receiving PDCP entity (460). For example, the result can be provided to other nodes (e.g., terminal (120) on the downlink, base station (110) on the uplink, CU (310)) via an RLC entity, a MAC entity, and a wireless interface.

[0096] A receiving PDCP entity (460) can receive data (e.g., PDCP data PDU) from a lower layer (e.g., RLC layer). Variables may be defined to describe the operations of the receiving PDCP entity (460).

[0097] - HFN (hyper frame number): The HFN portion of the state variable (i.e., the number of MSBs (most significant bits) equal to the HFN length)

[0098] - SN (sequence number): The SN portion of the state variable (i.e., the number of LSB (least significant bits) equal to the PDCP SN length)

[0099] - RCVD_SN: The PDCP SN of the received PDCP data PDU included in the PDU header

[0100] - RCVD_HFN: HFN of the received PDCP data PDU calculated by the receiving PDCP entity (460)

[0101] - RCVD_COUNT: COUNT of received PDCP data PDU = [RCVD_HFN, RCVD_SN].

[0102] A receiving PDCP entity (460) may receive a PDCP data PDU from a lower layer (e.g., an RLC entity). The PDCP data PDU may be data transmitted from a transmitting PDCP entity (410). The receiving PDCP entity (460) may determine a count value (e.g., 'RCVD_COUNT') of the received PDCP data PDU. After determining the count value (e.g., 'RCVD_COUNT') of the received PDCP data PDU, the receiving PDCP entity (460) may perform deciphering and integrity verification. If the integrity verification fails, the receiving PDCP entity (460) may discard the PDCP data PDU. The receiving PDCP entity (460) may discard the PDCP data PDU if it has previously received a PDCP data PDU corresponding to the count value, or if the count value is smaller than the count value ('RX_DELIV') (hereinafter, waiting start count value) of the first PDCP SDU that is still waiting and has not been passed to an upper layer (e.g., SDAP layer, RRC layer).

[0103] The receiving PDCP entity (460) can perform a sequential delivery function and a reordering procedure (465) for the sequential delivery function. The receiving PDCP entity (460) can store a PDCP SDU corresponding to the PDCP data PDU in a receiving buffer if the PDCP data PDU is not deleted by the procedures described above. The receiving PDCP entity (460) can determine whether the count value of the received PDCP data PDU (e.g., 'RCVD_COUNT') is greater than or equal to the count value (RX_NEXT) of the PDCP SDU expected to be received (hereinafter, expected count value). If the count value of the received PDCP data PDU (e.g., 'RCVD_COUNT') is greater than or equal to the expected count value (RX_NEXT), the receiving PDCP entity (460) may update the expected count value to the value of the received PDCP data PDU (e.g., 'RCVD_COUNT') plus 1. This is because the receiving PDCP entity (460) expects the reception of PDCP SDUs having consecutive count values. The receiving PDCP entity (460) may determine whether the count value of the received PDCP data PDU (e.g., 'RCVD_COUNT') is equal to the starting count value ('RX_DELIV'). If the count value (e.g., 'RCVD_COUNT') of the received PDCP data PDU is equal to the start count value ('RX_DELIV'), the receiving PDCP entity (460) may forward all stored PDCP SDUs corresponding to consecutive count values ​​starting from the start count value ('RX_DELIV') to an upper layer (e.g., SDAP layer, RRC layer) (after performing header decompression if they have not been previously decompressed). The start count value ('RX_DELIV') may be updated to the count value of the first PDCP SDU that is greater than the current start count value ('RX_DELIV') and has not been forwarded to an upper layer (e.g., SDAP layer, RRC layer).

[0104] If the receiving PDCP entity (460) is running a reordering timer and the start count value is greater than or equal to the count value ('RX_REORD') (hereinafter referred to as the reordering start value) following the count value associated with the PDCP data PDU that triggered the reordering timer, the receiving PDCP entity (460) may stop and reset the reordering timer. If the receiving PDCP entity (460) is not running a reordering timer and the start count value ('RX_DELIV') is less than the expected count value (RX_NEXT), the receiving PDCP entity (460) may update the reordering start value ('RX_REORD') to the expected count value (RX_NEXT). If the start count value ('RX_DELIV') is less than the expected count value (RX_NEXT), the receiving PDCP entity (460) may start the reordering timer. Even though there is data that has not yet been passed to the upper layer (e.g., SDAP layer), since the expected count value points to the PDCP SDU following the data, the receiving PDCP entity (460) can start the reordering timer as a reordering procedure (465).

[0105] When the reordering timer expires, the receiving PDCP entity (460) may forward all stored PDCP SDUs associated with count values ​​smaller than the reordering start value ('RX_REORD') to an upper layer (e.g., SDAP layer, RRC layer) (after performing header decompression if they have not been previously decompressed). Even if the intended data (e.g., PDCP SDU) has not been received because the reordering timer has expired, the PDCP SDUs currently stored in the receiving buffer may be reported to the upper layer. When the reordering timer expires, the receiving PDCP entity (460) may forward all stored PDCP SDUs having consecutive count values ​​starting from the reordering start value ('RX_REORD') to an upper layer (e.g., SDAP layer, RRC layer) (after performing header decompression if they have not been previously decompressed). The start count value ('RX_DELIV') can be updated to the count value of the first PDCP SDU that is greater than the reordering start value ('RX_REORD') and has not been passed to an upper layer (e.g., SDAP layer, RRC layer). If the start count value ('RX_DELIV') is less than the expected count value (RX_NEXT), the receiving PDCP entity (460) can update the reordering start value ('RX_REORD') to the expected count value (RX_NEXT). If the start count value ('RX_DELIV') is less than the expected count value (RX_NEXT), the receiving PDCP entity (460) can start a reordering timer. Even though there is data that has not yet been transmitted to the upper layer (e.g., SDAP layer, RRC layer), since the expected count value points to the PDCP SDU following the data, the receiving PDCP entity (460) can start the reordering timer as a reordering procedure (465).

[0106] When the reordering timer is reconfigured, the receiving PDCP entity (460) can update the reordering start value ('RX_REORD') to the expected count value (RX_NEXT). When the reordering timer is reconfigured, the receiving PDCP entity (460) can stop and restart the reordering timer.

[0107] The transmitting PDCP entity (410) can sequentially transmit data with count values ​​of 2, 3, 4, ..., 9. The receiving PDCP entity (460) can receive a PDCP data PDU with a count value of '2'. The receiving PDCP entity (460) can obtain a PDCP SDU from the above PDCP data PDU. The receiving PDCP entity (460) can forward the above PDCP SDU with a count value of '2' to an upper layer (e.g., SDAP layer, RRC layer). Subsequently, the receiving PDCP entity (460) can expect a PDCP data PDU with a count value of '3'. The receiving PDCP entity (460) can receive a PDCP data PDU with a count value of '3'. The receiving PDCP entity (460) can obtain a PDCP SDU from the above PDCP data PDU. The receiving PDCP entity (460) can forward the PDCP SDU with a count value of '3' to an upper layer (e.g., SDAP layer, RRC layer). Subsequently, the receiving PDCP entity (460) can expect a PDCP data PDU with a count value of '4'. The receiving PDCP entity (460) can receive the PDCP data PDU with a count value of '4'. The receiving PDCP entity (460) can obtain a PDCP SDU from the PDCP data PDU. The receiving PDCP entity (460) can forward the PDCP SDU with a count value of '4' to an upper layer (e.g., SDAP layer, RRC layer). Subsequently, the receiving PDCP entity (460) can set the starting count value ('RX_DELIV') to '5'. The receiving PDCP entity (460) can expect a PDCP data PDU with a count value of '5'.

[0108] In Example (471), a situation is described where a PDCP data PDU with a count value of '5' is lost. While the receiving PDCP entity (460) expects a PDCP data PDU with a count value of '5', it may receive a PDCP data PDU with a count value of '6'. Since the PDCP data PDU with a count value of '6' has been received but the starting count value ('RX_DELIV') is '5', the receiving PDCP entity (460) may not perform data delivery to an upper layer (e.g., SDAP layer, RRC layer). This is because the PDCP SDU with a count value of '5' has not yet been received. The receiving PDCP entity (460) may store the PDCP SDU corresponding to the PDCP data PDU with a count value of '6' in the receiving buffer (481). The receiving PDCP entity (460) may start a reordering timer. Since a PDCP data PDU with a count value of '6' has been received, the receiving PDCP entity (460) can expect a PDCP data PDU with a count value of '7'. For example, the receiving PDCP entity (460) can set the expected count value (RX_NEXT) to '7'. The receiving PDCP entity (460) can update the reordering start value ('RX_REORD') to the expected count value (RX_NEXT) (e.g., '7').

[0109] The receiving PDCP entity (460) may receive a PDCP data PDU with a count value of '7' while expecting a PDCP data PDU with a count value of '7'. Since the PDCP data PDU with a count value of '7' has been received but the starting count value ('RX_DELIV') is '5', the receiving PDCP entity (460) may not perform data delivery to an upper layer (e.g., SDAP layer, RRC layer). This is because a PDCP SDU with a count value of '5' has not yet been received. The receiving PDCP entity (460) may store a PDCP SDU corresponding to the PDCP data PDU with a count value of '7' in the receiving buffer (481). The reordering timer may be active. Since a PDCP data PDU with a count value of '7' has been received, the receiving PDCP entity (460) may expect a PDCP data PDU with a count value of '8'.

[0110] The receiving PDCP entity (460) may receive a PDCP data PDU with a count value of '8' while expecting a PDCP data PDU with a count value of '8'. Since the PDCP data PDU with a count value of '8' has been received but the start count value ('RX_DELIV') is '5', the receiving PDCP entity (460) may not perform data delivery to an upper layer (e.g., SDAP layer, RRC layer). This is because the PDCP SDU with a count value of '8' has not yet been received. The receiving PDCP entity (460) may store the PDCP SDU corresponding to the PDCP data PDU with a count value of '8' in the receiving buffer (481). Afterward, the reordering timer may expire. When the above reordering timer expires, the receiving PDCP entity (460) can transmit the stored PDCP SDU having a count value smaller than the reordering start value ('RX_REORD') (e.g., 7) (e.g., a PDCP SDU with a count value of 6) and the stored PDCP SDU having consecutive count values ​​greater than or equal to the reordering start value ('RX_REORD') '7' (e.g., a PDCP SDU with a count value of '7', a PDCP SDU with a count value of '8') to the upper layer (e.g., an SDAP layer, an RRC layer).

[0111] In Example (472), a situation is described where a PDCP data PDU with a count value of '5' is received late. As in Example (471), the receiving PDCP entity (460) may receive a PDCP data PDU with a count value of '6' while expecting a PDCP data PDU with a count value of '5'. Since the PDCP data PDU with a count value of '6' has been received but the starting count value ('RX_DELIV') is '5', the receiving PDCP entity (460) may not perform data delivery to an upper layer (e.g., SDAP layer, RRC layer). This is because the PDCP SDU with a count value of '5' has not yet been received. The receiving PDCP entity (460) may store the PDCP SDU corresponding to the PDCP data PDU with a count value of '6' in the receiving buffer (482). The receiving PDCP entity (460) may start a reordering timer. Since a PDCP data PDU with a count value of '6' has been received, the receiving PDCP entity (460) can expect a PDCP data PDU with a count value of '7'. For example, the receiving PDCP entity (460) can set the expected count value (RX_NEXT) to '7'. The receiving PDCP entity (460) can update the reordering start value ('RX_REORD') to the expected count value (RX_NEXT) (e.g., '7').

[0112] The receiving PDCP entity (460) may receive a PDCP data PDU with a count value of '7' while expecting a PDCP data PDU with a count value of '7'. Since the PDCP data PDU with a count value of '7' has been received but the start count value ('RX_DELIV') is '5', the receiving PDCP entity (460) may not perform data delivery to an upper layer (e.g., SDAP layer, RRC layer). This is because a PDCP SDU with a count value of '5' has not yet been received. The receiving PDCP entity (460) may store a PDCP SDU corresponding to the PDCP data PDU with a count value of '7' in the receiving buffer (482). The reordering timer may be active. Since a PDCP data PDU with a count value of '7' has been received, the receiving PDCP entity (460) may expect a PDCP data PDU with a count value of '8'.

[0113] The receiving PDCP entity (460) may receive a PDCP data PDU with a count value of '5' while expecting a PDCP data PDU with a count value of '8'. The receiving PDCP entity (460) may receive a PDCP data PDU corresponding to the start count value ('RX_DELIV') before the reordering timer expires. Since the start count value ('RX_DELIV') is '5', the receiving PDCP entity (460) may perform data transfer to an upper layer (e.g., SDAP layer, RRC layer). The receiving PDCP entity (460) may store a PDCP SDU corresponding to the PDCP data PDU with a count value of '5' in the receiving buffer (482). The receiving buffer (482) may store a PDCP SDU associated with a count value of '6', a PDCP SDU associated with a count value of '7', and a PDCP SDU associated with a count value of '5'. The receiving PDCP entity (460) can transmit the stored PDCP SDUs to the upper layer (e.g., SDAP layer, RRC layer) in ascending order starting from '5'. Meanwhile, a PDCP data PDU with a count value of '5' is received, but since the expected count value (RX_NEXT) is '8', the expected count value (RX_NEXT) is not updated.

[0114] A PDCP layer of the NR specification (e.g., PDCP layer (362)) can provide a reordering function (e.g., reordering procedure (465)) that guarantees the packet order for uplink packets. The reordering function can be performed by a receiving PDCP entity (e.g., receiving PDCP entity (460)), as described in the examples (e.g., 471, 472)) of FIG. 4 above. When the reordering timer expires or the intended PDCP data PDU is received, the receiving PDCP entity (460) can correct the packet order by sorting the PDCP SDUs in ascending order of count values ​​(values ​​corresponding to SN) and delivering the sorted PDCP SDUs to an upper layer (e.g., SDAP layer, RRC layer). When referring to the regular procedures, if a PDCP SDU of a specific SN is not received while the reordering timer is operating, the receiving PDCP entity (460) may wait without transmitting the PDCP SDU(s) to the upper layer until the reordering timer expires. Afterward, when the reordering timer expires, the PDCP SDU(s) stored in the receiving buffer of the receiving PDCP entity (460) may be delivered to the upper layer (e.g., SDAP layer, RRC layer). That is, a delay may occur equal to the length of the reordering timer for the reordering procedure (465). For example, let us assume a situation where a terminal (120) performs a voice call (e.g., VoNR (voice over NR)) with another user's electronic device. Packets (e.g., RTP (real time protocol) / SIP (Session Initiation Protocol) packets) may be transmitted or received at regular intervals. The voice call quality varies depending on the electric field of the terminal (120), and the weaker the electric field of the terminal (120), the lower the voice call quality may be. Packets according to the VoNR service may also be included as uplink packets and may be included in the target of the reordering function.Delays of the length of the reordering timer may inevitably occur due to loss in the uplink (e.g., loss of packets with a count value of '5' in Example (471), Example (472)). Therefore, the quality of services where real-time performance is important (e.g., telephone services, VoIP (voice over internet protocol), VoNR, interactive services, streaming services) may be affected by the length of the reordering timer and / or loss.

[0115] Let us assume a situation where a terminal (120) performs a voice call (e.g., VoNR (voice over NR)) with another user's electronic device. Packets (e.g., RTP (real time protocol) / SIP (Session Initiation Protocol) packets) may be transmitted or received at regular intervals. The quality of the voice call varies depending on the electric field of the terminal (120), and the weaker the electric field of the terminal (120), the lower the quality of the voice call may be. As the electric field of the terminal (120) becomes weaker, jitter (e.g., a metric indicating the variability of packet arrival times) increases, and thus the quality of the voice call service may deteriorate. Accordingly, in the embodiments of the present disclosure, a technique for improving the quality of the service using communication is described by adaptively adjusting the length of the reordering timer. Furthermore, in the embodiments of the present disclosure, a technique for improving the quality of the service using communication is described by changing the length of the reordering timer when certain conditions regarding the loss indicator of the currently provided service are satisfied. In addition, embodiments of the present disclosure describe a technique for improving service quality using communication by changing the length of a reordering timer for services sensitive to real-time. In addition, embodiments of the present disclosure describe a technique for reducing delay and / or jitter by automatically reducing the length of a reordering timer through a loss detection algorithm.

[0116] FIG. 5 illustrates an example of a service provided to a UE (user equipment) (e.g., a terminal (120)). As a base station (110), a gNB is described as an example. As a terminal (120), a UE is described as an example.

[0117] Referring to FIG. 5, the UE (120) can communicate with the UPF (530) through the gNB (110). The UPF (530) performs the role of processing and routing user data packets and can provide appropriate processing of traffic through classification and priority as needed. Additionally, the UPF (530) is connected to a data network (DN) and can transmit packets over the internet network.

[0118] A 5G core network may provide one or more PDU sessions for a UE (120). A PDU session may represent an object for managing the transmission of data in the user plane between the UE (120) and the 5G core network. For example, a network entity of the 5G core network may include a UPF (530). One or more PDU sessions may be established across the UE (120), gNB (110), and UPF (530). For example, the one or more PDU sessions may include a first PDU session (541) and a second PDU session (542). The first PDU session (541) may be used for internet services. The second PDU session (542) may be used for IMS (Internet Protocol Multimedia Subsystem) voice services.

[0119] Each PDU session may include a GTP (General Packet Radio Service (GPRS) Tunneling Protocol)-U (user plane) tunnel. The GTP-U tunnel represents a logical channel for encapsulating user data and transmitting it so that it can pass through another network. For example, a first PDU session (541) may include a first UP (user plane) tunnel (561). A second PDU session (542) may include a second UP tunnel (562).

[0120] Each PDU session can be associated with one or more QoS flows. A QoS flow represents a unit of data flow with specific QoS requirements in a 5G network. The said QoS flow represents a logical data flow defined to guarantee QoS, such as data transmission speed, latency, and packet loss rate, required by a specific application or service. Each QoS flow corresponds to a QoS flow identifier (QFI) for identifying the corresponding QoS flow, and a 5QI (5 th It can be associated with a generation QoS identifier. The 5QI represents a scalar used as a reference for 5G QoS characteristics, namely access node-specific parameters (e.g., scheduling weight, acknowledgment threshold, queue management threshold, link layer protocol configuration, etc.) for controlling QoS forwarding treatment for QoS flows. As an example, the following table may be referenced for the 5QI.

[0121] 5QIValueResource TypeDefault Priority LevelPacket Delay Budget(NOTE 3)Packet ErrorRateDefault Maximum Data Burst Volume(NOTE 2)DefaultAveraging WindowExample Services1GBR20100 ms(NOTE 11,NOTE 13)10 -2 N / A2000 msConversational Voice2(NOTE 1)40150 ms(NOTE 11,NOTE 13)10 -3 N / A2000 msConversational Video (Live Streaming)33050 ms(NOTE 11,NOTE 13)10 -3 N / A2000 msReal Time Gaming, V2X messages (see TS 23.287

[0121] ).Electricity distribution - medium voltage, Process automation monitoring450300 ms(NOTE 11,NOTE 13)10 -6 N / A2000 msNon-Conversational Video (Buffered Streaming)65(NOTE 9,NOTE 12)775 ms(NOTE 7, NOTE 8)10 -2 N / A2000 msMission Critical user plane Push To Talk voice (e.g. MCPTT)66(NOTE 12)20100 ms(NOTE 10,NOTE 13)10 -2 N / A2000 msNon-Mission-Critical user plane Push To Talk voice67(NOTE 12)15100 ms(NOTE 10,NOTE 13)10 -3 N / A2000 msMission Critical Video user plane75(NOTE 14)7156150 ms (NOTE 11, NOTE 13, NOTE 15)10 -6N / A2000 ms"Live" Uplink Streaming (e.g. TS 26.238

[0076] )7256300 ms (NOTE 11, NOTE 13, NOTE 15)10 -4 N / A2000 ms"Live" Uplink Streaming (e.g. TS 26.238

[0076] )7356300 ms (NOTE 11, NOTE 13, NOTE 15)10 -8 N / A2000 ms"Live" Uplink Streaming (e.g. TS 26.238

[0076] )7456500 ms (NOTE 11, NOTE 15)10 -8 N / A2000 ms"Live" Uplink Streaming (e.g. TS 26.238

[0076] )7656500 ms (NOTE 11, NOTE 13, NOTE 15)10 -4 N / A2000 ms"Live" Uplink Streaming (e.g. TS 26.238

[0076] )5Non-GBR10100 msNOTE 10,NOTE 13)10 -6 N / AN / AIMS Signalling6(NOTE 1)60300 ms(NOTE 10,NOTE 13)10 -6 N / AN / AVideo (Buffered Streaming)TCP-based (e.g. www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)770100 ms(NOTE 10,NOTE 13)10 -3 N / AN / AVoice,Video (Live Streaming)Interactive Gaming880300 ms(NOTE 13)10 -6N / AN / AVideo (Buffered Streaming)TCP-based (e.g. www, e-mail, chat, ftp, p2p file sharing, progressive990video, etc.)69(NOTE 9, NOTE 12)560 ms(NOTE 7, NOTE 8)10 -6 N / AN / AMission Critical delay sensitive signalling (e.g. MC-PTT signalling)70(NOTE 12)55200 ms(NOTE 7,NOTE 10)10 -6 N / AN / AMission Critical Data (e.g. example services are the same as 5QI 6 / 8 / 9)796550 ms(NOTE 10,NOTE 13)10 -2 N / AN / AV2X messages (see TS 23.287

[0121] )806810 ms(NOTE 5,NOTE 10)10 -6 N / AN / ALow Latency eMBB applications Augmented Reality1090832ms(NOTE 13)(NOTE 17)10 -6 N / AN / AVideo (Buffered Streaming)TCP-based (e.g. www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.) and any service that can be used over satellite access type with these characteristics82Delay-critical GBR1910 ms(NOTE 4)10 -4 255 bytes2000 msDiscrete Automation (see TS 22.261 [2])832210 ms(NOTE 4)10 -41354 bytes(NOTE 3)2000 msDiscrete Automation (see TS 22.261 [2]);V2X messages (UE - RSU Platooning, Advanced Driving: Cooperative Lane Change with low LoA. See TS 22.186

[0111] , TS 23.287

[0121] )842430 ms(NOTE 6)10 -5 1354 bytes(NOTE 3)2000 msIntelligent transport systems (see TS 22.261 [2])85215 ms(NOTE 5)10 -5 255 bytes2000 msElectricity Distribution- high voltage (see TS 22.261 [2]).V2X messages (Remote Driving. See TS 22.186

[0111] , NOTE 16, see TS 23.287

[0121] )86185 ms(NOTE 5)10 -41354 bytes2000 msV2X messages (Advanced Driving: Collision Avoidance, Platooning with high LoA. See TS 22.186

[0111] , TS 23.287

[0121] )NOTE 1: A packet which is delayed more than PDB is not counted as lost, thus not included in the PER.NOTE 2: It is required that default MDBV is supported by a PLMN supporting the related 5QIs.NOTE 3: The Maximum Transfer Unit (MTU) size considerations in clause 9.3 and Annex C of TS 23.060

[0056] are also applicable. IP fragmentation may have impacts to CN PDB, and details are provided in clause 5.6.10.NOTE 4: A static value for the CN PDB of 1 ms for the delay between a UPF terminating N6 and a 5G-AN should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. When a dynamic CN PDB is used, see clause 5.7.3.4.NOTE 5: A static value for the CN PDB of 2 ms for the delay between a UPF terminating N6 and a 5G-AN should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. When a dynamic CN PDB is used, see clause 5.7.3.4.NOTE 6: A static value for the CN PDB of 5 ms for the delay between a UPF terminating N6 and a 5G-AN should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. When a dynamic CN PDB is used, see clause 5.7.3.4.NOTE 7: For Mission Critical services, it may be assumed that the UPF terminating N6 is located "close" to the 5G_AN (roughly 10 ms) and is not normally used in a long distance, home routed roaming situation. Hence a static value for the CN PDB of 10 ms for the delay between a UPF terminating N6 and a 5G_AN should be subtracted from this PDB to derive the packet delay budget that applies to the radio interface.NOTE 8: In both RRC Idle and RRC Connected mode, the PDB requirement for these 5QIs can be relaxed (but not to a value greater than 320 ms) for the first packet(s) in a downlink data or signalling burst in order to permit reasonable battery saving (DRX) techniques.NOTE 9: It is expected that 5QI-65 and 5QI-69 are used together to provide Mission Critical Push to Talk service (e.g. 5QI-5 is not used for signalling). It is expected that the amount of traffic per UE will be similar or less compared to the IMS signalling.NOTE 10: In both RRC Idle and RRC Connected mode, the PDB requirement for these 5QIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques.NOTE 11: In RRC Idle mode, the PDB requirement for these 5QIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques.NOTE 12: This 5QI value can only be assigned upon request from the network side. The UE and any application running on the UE is not allowed to request this 5QI value.NOTE 13: A static value for the CN PDB of 20 ms for the delay between a UPF terminating N6 and a 5G-AN should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface.NOTE 14: This 5QI is not supported in this Release of the specification as it is only used for transmission of V2X messages over MBMS bearers as defined in TS 23.285

[0072] but the value is reserved for future use.NOTE 15: For "live" uplink streaming (see TS 26.238

[0076] ), guidelines for PDB values of the different 5QIs correspond to the latency configurations defined in TR 26.939

[0077] . In order to support higher latency reliable streaming services (above 500ms PDB), if different PDB and PER combinations are needed these configurations will have to use non-standardised 5QIs.NOTE 16: These services are expected to need much larger MDBV values to be signalled to the RAN. Support for such larger MDBV values with low latency and high reliability is likely to require a suitable RAN configuration, for which, the simulation scenarios in TR 38.824

[0112] may contain some guidance.NOTE 17: The worst case one way propagation delay for GEO satellite is expected to be ~270ms, ,~ 21 ms for LEO at 1200km, and 13 ms for LEO at 600km. The UL scheduling delay that needs to be added is also typically 1 RTD e.g. ~540ms for GEO, ~42ms for LEO at 1200km, and ~26 ms for LEO at 600km. Based on that, the 5G-AN Packet delay budget is not applicable for 5QIs that require 5G-AN PDB lower than the sum of these values when the specific types of satellite access are used (see TS 38.300

[0027] ). 5QI-<New Value> can accommodate the worst case PDB for GEO satellite type.

[0122] For example, a first PDU session (541) may be associated with a first QoS flow (571). The first QoS flow (571) may be used for internet services. For example, a second PDU session (542) may be associated with the first QoS flow (571). The second PDU session (542) may be associated with a second QoS flow (572a), a third QoS flow (572b), a fourth QoS flow (572c), and a fifth QoS flow (572d). The second QoS flow (572a) may be used for SIP services. The third QoS flow (572b) may be used for RCS services. The fourth QoS flow (572c) may be used for RTP / RTCP services. The fifth QoS flow (572d) may be used for interactive services.

[0123] Each PDU session may be associated with one or more DRBs. Each DRB may represent a logical administrative path in an access network for the transmission of user data. QoS mapping may be performed for each DRB. Mapping between DRBs and QoS may be performed within the corresponding PDU session. For example, a first PDU session (541) may be associated with a first DRB (551). For example, the first DRB (551) may be mapped to a first QoS flow (571) for internet services. For example, a second PDU session (542) may be associated with a second DRB (552a), a third DRB (552b), a fourth DRB (552c), and a fifth DRB (552d). For example, the second DRB (552a) may be mapped to a second QoS flow (572a) for a session initiation protocol (SIP). For example, the third DRB (552b) can be mapped to the third QoS flow (572b) for rich communication services (RCS). For example, the fourth DRB (552c) can be mapped to the fourth QoS flow (572c) for voice services. For example, the fifth DRB (552d) can be mapped to the fifth QoS flow (572d) for video services.

[0124] FIG. 6 illustrates the operation flow of a communication device for performing reordering using a timer. According to embodiments of the present disclosure, the communication device may be configured to provide functions of a PDCP layer (e.g., PDCP layer (312), PDCP layer (362)). For example, the communication device may be a base station (110) (e.g., gNB, eNB). As another example, the communication device may correspond to an upper network node in a distributed deployment. For example, the communication device may be a CU (e.g., CU (310)). For example, the communication device may be a CU-UP, which is a node for performing a reordering procedure in the user plane. FIG. 6 describes a situation in which the communication device corresponding to a receiving PDCP entity receives uplink data from a terminal (120) corresponding to a transmitting PDCP entity as an uplink transmission.

[0125] Referring to FIG. 6, in operation (601), the communication device can identify a QoS identifier associated with a DRB for a terminal (e.g., terminal (120)). The communication device can identify a DRB configured for the terminal. The communication device can identify a QoS flow mapped to the DRB. The communication device can identify a QoS identifier corresponding to the QoS flow. For example, the QoS identifier may be 5QI. The 5QI is a QoS class identifier and may represent QoS characteristics. For example, the QoS characteristics may include resource type (e.g., whether it is GBR (guaranteed bit rate), non-GBR, or delay-critical GBR), priority level, PDB (packet delay budget), PER (packet error rate), averaging window, and / or maximum data burst volume. As an example, [Table 1] may be referenced for the 5QI.

[0126] In operation (603), the communication device may determine whether the QoS identifier is a predetermined value. The predetermined value may be used to specify a service for adaptively adjusting the value of a timer for reordering. For example, the predetermined value may be used by the communication device to distinguish between a real-time service and a non-real-time service. According to one embodiment, the predetermined value may be '1' or '2'. If the QoS identifier is '1', the DRB may be used for a conversational voice service. For example, the PDB may be about 100ms. If the QoS identifier is '2', the DRB may be used for a conversational video service for live streaming. For example, the PDB may be about 105ms. The communication device can determine whether the DRB for the QoS identifier is a service that requires adaptive control of the value of a timer for reordering (e.g., reordering procedure (465)) by determining whether the QoS identifier is a predetermined value. For example, the communication device can determine that the DRB is a service that requires adaptive control of the value of a timer for reordering (e.g., reordering procedure (465)) if the QoS identifier is a predetermined value.

[0127] The communication device can perform operation (605) if the QoS identifier is a predetermined value. The communication device can perform operation (607) if the QoS identifier is not a predetermined value.

[0128] In operation (605), the communication device can perform a reordering procedure using a timer having a reconfigured value based on a loss event and a loss rate.

[0129] The communication device can determine whether a loss event occurs. Determining whether a loss event occurs may indicate whether a packet transmitted from a transmitting PDCP entity (e.g., transmitting PDCP entity (410)) is lost while being provided to a receiving PDCP entity (e.g., receiving PDCP entity (460)). For example, the DRB of an interactive voice service (e.g., VoNR) operates in RLC UM (unacknowledged mode), so there is a high probability of packet loss occurring. Meanwhile, the embodiments of the present disclosure are not limited to services for RLC UM. In an environment with high loss, it may be required to gradually reduce and set a small timer for reordering (hereinafter, reordering timer). In other words, it may be required to reduce the value of the reordering timer, thereby reducing the delay time for reordering and ensuring real-time performance at a certain level (e.g., 20ms) or higher. In order to determine whether to perform a reordering procedure while changing the value of the reordering timer, the communication device may determine whether a loss event occurs. The loss event refers to a situation in which at least one packet among the packets received from the terminal (120) is lost occurs more than a certain number of times. For example, if the case in which the SN of a PDCP data PDU is not received sequentially (e.g., after a PDCP data PDU with SN='3' is received, a PDCP data PDU with SN='5' is received) (hereinafter referred to as "lost packet detection") is confirmed more than a certain number of times (e.g., 5 times), the communication device may determine that the loss event has occurred. The communication device may analyze the loss pattern based on the collected packets (e.g., PDCP data PDUs). Based on the result of the analysis, the communication device may determine whether the loss event occurred as a one-time occurrence or was caused by environmental factors.If it is caused by environmental factors, continuous packet loss is expected, so adjustment of the reordering timer value may be required to improve service quality. The description of the above loss event is described in more detail through Fig. 7.

[0130] The communication device can determine the loss rate. The communication device can determine the loss rate based on the determination that a loss event has occurred. The communication device can determine that, due to the loss event, the communication environment of the terminal (120) is a communication environment where packets are being lost (e.g., weak signal, dead zone). The communication device can measure the loss rate based on PDCP data PDUs received from a lower layer (e.g., RLC layer) during a certain time interval. For example, the communication device can collect packets by driving a periodic timer (e.g., about 5 seconds) corresponding to the certain time interval. The communication device can analyze the loss pattern through the collected packets (e.g., loss pattern analysis algorithm, loss detection algorithm) and determine the loss rate based on the result of the analysis. As an example that is not limited to, the loss rate can be determined by determining whether the loss has increased compared to the previous cycle through the result of the analysis, and if the loss indicator in the current cycle indicates a greater loss than the loss indicator in the previous cycle. According to one embodiment, the predetermined time interval for collection may be determined according to the service type represented by the predetermined value. For example, in the case of an interactive voice service, the predetermined time interval may be determined as a value for receiving sufficient packets. For example, the predetermined time interval may be 10ms. For example, in the case of an interactive video service, the predetermined time interval may be determined as a value for receiving sufficient packets. For example, the predetermined time interval may be 20ms.

[0131] The communication device may determine the value of a timer for reordering based on a loss rate. According to one embodiment, the communication device may determine whether the loss rate is greater than or equal to a loss threshold. If the loss rate is less than the loss threshold, the communication device may increase the value of the reordering timer to increase the reliability (or robustness) of the service. For example, the communication device may set the value of the reordering timer to a first value greater than the current set value. The communication device may prevent service interruption (e.g., out-of-service (OoS)) by changing the value of the reordering timer in steps. As an example, but not limited to, the delta value of the step change (e.g., the difference between the current set value and the first value) may be a fixed value or determined according to the service type. If the current set value of the reordering timer is the maximum value for the reordering timer, the communication device may maintain the value of the reordering timer. For example, the maximum value of the reordering timer may be approximately 100ms. This is because a delay occurs in the event of packet loss corresponding to the value of the reordering timer, and the user perceives voice clipping above a certain level (e.g., about 100ms). According to one embodiment, the maximum value of the reordering timer may be determined according to the type of service provided through the DRB (e.g., an exemplary service indicated by a QoS identifier). If the loss rate exceeds a loss threshold, the communication device may reduce the value of the reordering timer to increase the real-time performance of the service for the DRB. For example, the communication device may set the value of the reordering timer to a second value smaller than the current set value. The communication device can ensure service quality related to real-time performance while changing the value of the reordering timer in stages.If the current setting value of the reordering timer is the minimum value for the reordering timer, the communication device may maintain the value of the reordering timer. For example, the minimum value of the reordering timer may be approximately 20ms. As an example not limited to, the delta value of the step change (e.g., the difference between the current setting value and the second value) may be a fixed value or determined according to the service type.

[0132] The communication device may reconfigure the value of the timer for reordering. If the timer is running (before expiration) and no lost packets are received, the communication device may store the received data in the receiving buffer until the timer for reordering expires. When the timer expires, the communication device may sort the PDCP data (e.g., PDCP SDU) stored in the receiving buffer of the PDCP layer in the communication device in ascending order of count value(s) and transmit the sorted data to the upper layer (e.g., SDAP layer) in ascending order. For example, as the value of the timer decreases under high loss conditions (e.g., loss rate above a loss threshold), the delay time due to lost packets may be shortened. For example, as the value of the timer increases under conditions where there is loss but relatively low loss (e.g., loss rate below a loss threshold), sufficient reliability and / or robustness against lost packets may be ensured.

[0133] In operation (607), the communication device can perform a reordering procedure using a timer with a fixed value. The reordering procedure can be performed using a timer with a fixed value regardless of the channel conditions (e.g., weak signal, dead zone) between the terminal (120) and the communication device. Therefore, even if a packet is lost, the communication device can wait for a time corresponding to the fixed value and then transmit the PDCP data (e.g., PDCP SDU) stored in the receiving buffer to an upper layer (e.g., SDAP layer).

[0134] In FIG. 6, only the situation in which a loss event occurs in operation (605) is described as an example, but embodiments of the present disclosure are not limited thereto. It may also be understood as an embodiment of the present disclosure that the communication device performs a reordering procedure using a timer having a fixed value upon the determination that no loss event occurred.

[0135] FIG. 7 illustrates the flow of operation of a communication device for determining the occurrence of a loss event. According to embodiments of the present disclosure, the communication device may be configured to provide functions of a PDCP layer (e.g., PDCP layer (312), PDCP layer (362)). For example, the communication device may be a base station (110) (e.g., gNB, eNB). For another example, the communication device may correspond to an upper network node in a distributed deployment. For example, the communication device may be a CU (e.g., CU (310)). For example, the communication device may be a CU-UP, which is a node for performing a reordering procedure in the user plane. FIG. 7 describes a situation in which the communication device corresponding to a receiving PDCP entity receives uplink data from a terminal (120) corresponding to a transmitting PDCP entity as an uplink transmission.

[0136] Referring to FIG. 7, in operation (701), the communication device can obtain a count value of a received PDCP PDU. The communication device can receive a PDCP PDU from a lower layer (e.g., an RLC layer). The PDCP PDU may be a PDCP data PDU. The communication device can identify an SN in the header of the PDCP data PDU. The communication device can obtain a count value through the SN. For the count value, the operations of the received PDCP entity (460) of FIG. 4 may be referenced. The communication device can obtain a PDCP SDU from the PDCP data PDU and store the PDCP SDU.

[0137] In operation (703), the communication device can determine whether the count value of the received PDCP PDU is greater than or equal to 1 greater than the count value of the PDCP PDU expected to be received (e.g., RX_NEXT in FIG. 4). The communication device can identify the count value of the PDCP PDU expected to be received (e.g., the count value of the PDCP SDU expected to be received (RX_NEXT), the expected count value). For example, if a PDCP data PDU with a count value of '3' was previously received, the communication device can expect a PDCP data PDU with a count value of '4'. This is because it is assumed that PDCP data PDUs will be transmitted with sequential count values. The communication device can determine whether the count value of the received PDCP PDU is greater than or equal to 1 greater than the expected count value as a received PDCP entity. If, while the communication device is expecting a PDCP data PDU with a count value of '4', a PDCP data PDU with a count value of '5' is received, the communication device can determine that a jump in SN has occurred. Such a jump may indicate that a PDCP data PDU with a count value of '4' has been lost. The jump may be referred to as a lost packet detection. In a non-limiting example, a PDCP data PDU with a count value of '4' may be delivered late, but the communication device may determine a lost packet detection if the count values ​​are not transmitted sequentially and the jump occurs.

[0138] The communication device may perform operation (705) if the count value of the received PDCP PDU is 1 or more greater than the count value of the PDCP PDU expected to be received. The communication device may perform operation (707) if the count value of the received PDCP PDU is not 1 or more greater than the count value of the PDCP PDU expected to be received.

[0139] In operation (705), the communication device can determine whether the number of loss packet detections is greater than or equal to a reference threshold. The loss packet detection refers to the case where the judgment condition of operation (703) is satisfied. The communication device can determine whether the judgment condition of operation (703) is satisfied for each PDCP data PDU among the PDCP data PDUs that are repeatedly received. If the judgment condition is satisfied, the communication device can determine loss packet detection. The communication device can analyze loss patterns based on collected packets (e.g., PDCP data PDUs). Based on the results of the analysis, the communication device can determine whether the loss packet detection occurred as a one-time occurrence (e.g., passing through an obstacle) or was caused by environmental factors (e.g., a shadow area, a congested area). If it was caused by environmental factors, it is expected that packet loss will occur continuously, so adjustment of the reordering timer value is required to improve service quality. The reference threshold can be used as a criterion for determining the adjustment of the reordering timer value. The above threshold value may be determined according to the service type for the DRB. The higher the level of QoS required by the service type, the lower the threshold value may be set. Even if packet loss is detected relatively infrequently, the communication device can adaptively respond to channel changes by adjusting the value of the reordering timer. On the other hand, the lower the level of QoS required by the service type, the higher the threshold value may be set. The communication device may adjust the value of the reordering timer only when packet loss occurs very frequently.

[0140] According to one embodiment, the communication device may determine whether the number of consecutive loss packet detections is greater than or equal to the reference threshold. In other words, the comparison target with the reference threshold may be the number of consecutive loss packet detections occurring for the received PDCP data PDUs. According to another embodiment, the communication device may determine whether the number of loss packet detections is greater than or equal to the reference threshold for a specified time. In other words, the communication device may determine the occurrence of a loss event (e.g., operation (707)) only if the number of loss packet detections within the specified time is greater than or equal to the reference threshold. As an example not limited to, the specified time may be dependent on a service parameter (e.g., 5QI) associated with the DRB of the PDCP data PDU.

[0141] The communication device may perform operation (707) when the number of loss packet detections is greater than or equal to the reference threshold. The communication device may perform operation (709) when the number of loss packet detections is greater than or equal to the reference threshold.

[0142] In operation (707), the communication device may determine that a loss event has occurred. Based on the determination that a loss event has occurred, the communication device may determine a loss rate. Due to the loss event, the communication device may determine that the communication environment of the terminal (120) is a communication environment where packets are being lost (e.g., weak signal, dead zone). Based on the loss rate, the communication device may determine the value of a timer for reordering. To operate the communication device, the descriptions of FIG. 6 may be referenced.

[0143] In operation (709), the communication device may determine that no loss event has occurred. The communication device may determine that no loss event has occurred if the count value of the received PDCP PDU is not greater than or equal to the count value of the PDCP PDU expected to be received. For example, if the count value of the received PDCP PDU is equal to the count value of the PDCP PDU expected to be received, the communication device may determine that no loss event has occurred because the data to be received has been received. For example, if the count value of the received PDCP PDU is less than the count value of the PDCP PDU expected to be received, the communication device may determine that no loss event has occurred because the data that should have been received previously has been received or data that has already been received has been received redundantly.

[0144] The communication device described above can repeatedly perform the procedures described above for each received PDCP data, not just for a single PDCP data (e.g., PDCP data PDU, PDCP SDU). According to one embodiment, by repeatedly performing the procedures described above for each received PDCP data, the communication device can provide improved service quality even in dead zones for loss-sensitive services.

[0145] FIG. 8 illustrates an example of lost packet detection. A terminal (120) (e.g., a transmitting PDCP entity (410)) can sequentially transmit data (e.g., PDCP data PDU) with count values ​​of 2, 3, 4, ..., 9. A communication device (e.g., a receiving PDCP entity (460)) can receive data (e.g., PDCP data PDU) from the terminal (120). The communication device may be configured to provide functions of a PDCP layer (e.g., PDCP layer (312), PDCP layer (362)). For example, the communication device may be a base station (110) (e.g., gNB, eNB). As another example, the communication device may correspond to an upper network node in a distributed deployment. As an example, the communication device may be a CU (e.g., CU (310)). As an example, the communication device may be a CU-UP, which is a node for performing a reordering procedure in the user plane. Figure 8 describes examples for explaining loss packet detection performed by the communication device.

[0146] Referring to FIG. 8, in example (810), the communication device may receive PDCP data PDUs in the order of '2', '3', '4', '6', '7', '5', '8', and '9'. After receiving a PDCP data PDU with a count value of '4', the communication device may expect a PDCP data PDU with a count value of '5'. However, since it receives a PDCP data PDU with a count value of '6' which is at least 1 greater than the count value of '5', it may determine to detect a lost packet. Subsequently, after receiving a PDCP data PDU with a count value of '7', the communication device may expect a PDCP data PDU with a count value of '8'. Even if a PDCP data PDU with a count value of '5' is received while expecting a PDCP data PDU with a count value of '8', the PDCP data PDU is not a lost packet. Therefore, the communication device may not determine to detect a lost packet for the corresponding PDCP data PDU.

[0147] In example (820), the communication device may receive PDCP data PDUs in the order of '2', '4', '5', '6', '3', '7', '8', '9'. After receiving a PDCP data PDU with a count value of '2', the communication device may expect a PDCP data PDU with a count value of '3'. However, since it receives a PDCP data PDU with a count value of '4' which is at least 1 greater than the count value of '3', it may determine to detect a lost packet. Subsequently, after receiving a PDCP data PDU with a count value of '6', the communication device may expect a PDCP data PDU with a count value of '7'. Even if a PDCP data PDU with a count value of '3' is received while expecting a PDCP data PDU with a count value of '7', the PDCP data PDU is not a lost packet. Therefore, the communication device may not determine to detect a lost packet for the corresponding PDCP data PDU.

[0148] In example (830), the communication device may receive PDCP data PDUs in the order of '2', '4', '5', '6', '3', '8', '9', and '7'. After receiving a PDCP data PDU with a count value of '2', the communication device may expect a PDCP data PDU with a count value of '3'. However, since it receives a PDCP data PDU with a count value of '4' which is at least 1 greater than the count value of '3', it may determine to detect a lost packet. Subsequently, after receiving a PDCP data PDU with a count value of '6', the communication device may expect a PDCP data PDU with a count value of '7'. Even if a PDCP data PDU with a count value of '3' is received while expecting a PDCP data PDU with a count value of '7', the PDCP data PDUs are not lost packets because they are packets that should have been received previously (e.g., a PDCP data PDU with a count value of '3'). Accordingly, the communication device may not determine to detect lost packets for the corresponding PDCP data PDUs. Meanwhile, while expecting a PDCP data PDU with a count value of '7', if a PDCP data PDU with a count value of '8' which is one or more greater than the count value of '7' is received, the communication device may determine to detect lost packets.

[0149] In example (840), the communication device may receive PDCP data PDUs in the order of '2', '4', '5', '6', '1', '3', '7', and '8'. After receiving a PDCP data PDU with a count value of '2', the communication device may expect a PDCP data PDU with a count value of '3'. However, since it receives a PDCP data PDU with a count value of '4' which is at least 1 greater than the count value of '3', it may determine to detect a lost packet. Afterward, the communication device may expect a PDCP data PDU with a count value of '7' after receiving a PDCP data PDU with a count value of '6'. Even if a PDCP data PDU with a count value of '1' and a PDCP data PDU with a count value of '3' are received while expecting a PDCP data PDU with a count value of '7', the said PDCP data PDUs are not lost packets because they are packets that should have been received previously (e.g., a PDCP data PDU with a count value of '3') or packets that have already been received (e.g., a PDCP data PDU with a count value of '1'). Therefore, the communication device may not determine to detect lost packets for the corresponding PDCP data PDUs.

[0150] FIG. 9 illustrates examples of components of a communication device. According to embodiments of the present disclosure, the communication device may be configured to provide functions of a PDCP layer (e.g., PDCP layer (312), PDCP layer (362)). For example, the communication device may be a base station (110) (e.g., gNB, eNB). For another example, the communication device may correspond to a higher network node in a distributed deployment. For example, the communication device may be a CU (e.g., CU (310)). For example, the communication device may be a CU-UP, which is a node for performing a reordering procedure in the user plane. Terms such as '... unit', '... unit' used below refer to a unit that processes at least one function or operation, which may be implemented in hardware or a combination of hardware and software.

[0151] Referring to FIG. 9, the communication device (900) may include a transceiver (910), a memory (920), and a processor (930).

[0152] The transceiver (910) can perform functions for transmitting and receiving signals in a wired communication environment. The transceiver (910) may include a wired interface for controlling a direct connection between devices through a transmission medium (e.g., copper wire, optical fiber). For example, the transceiver (910) can transmit an electrical signal to another device through a copper wire or perform conversion between an electrical signal and an optical signal. According to one embodiment, a communication device (900) can communicate with a distributed unit (DU) (e.g., DU (320)) through the transceiver (910). The transceiver (910) may also perform functions for transmitting and receiving signals in a wireless communication environment. For example, the transceiver (910) can perform conversion between a baseband signal and a bit sequence according to the physical layer specifications of the system. For example, when transmitting data, the transceiver (910) generates complex symbols by encoding and modulating the transmitted bit sequence. Also, when receiving data, the transceiver (910) restores the received bit sequence by demodulating and decoding the baseband signal. Additionally, the transceiver (910) may include a plurality of transmission and reception paths. According to one embodiment, the communication device (900) may be a base station (110) and may communicate with a UE (e.g., terminal (120)) directly through a wireless access network or communicate with a UE (e.g., terminal (120)) through a radio unit (RU).

[0153] The transceiver (910) transmits and receives signals as described above. Accordingly, all or part of the transceiver (910) may be referred to as a 'communication unit', 'transmitter', 'receiver', or 'transmitter / receiver'. Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean that processing as described above is performed by the transceiver (910). Although only the transceiver (910) is shown in FIG. 9, according to other embodiments, the communication device (900) may include two or more transceivers.

[0154] Memory (920) stores data such as basic programs, application programs, and configuration information for the operation of the communication device (900). Memory (920) may be referred to as a storage unit. Memory (920) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. Additionally, memory (920) may provide stored data upon request from the processor (930). Memory (920) represents a storage space as a functional component. For example, memory (920) may be understood not only as representing memory (e.g., hard disk, flash memory, RAM) placed as a component within the communication device (900), but also as representing a space for storing instructions and / or programs.

[0155] The processor (930) controls the overall operations of the communication device (900). The processor (980) may be referred to as the control unit. For example, the processor (930) transmits and receives signals through the transceiver (910) (or through the backhaul communication unit). Additionally, the processor (930) writes and reads data to and from memory (920). Furthermore, the processor (930) can perform functions of the protocol stack required by the communication standard (e.g., functions according to the protocol layer of FIG. 2a, FIG. 2b, FIG. 3a, and FIG. 3b, functions of the PDCP layer). Although only the processor (930) is shown in FIG. 9, according to other implementation examples, the communication device (900) may include two or more processors.

[0156] The configuration of the communication device (900) shown in FIG. 9 is merely an example, and examples of components of the electronic device performing embodiments of the present disclosure are not limited from the configuration shown in FIG. 9. In some embodiments, some configurations may be added, deleted, or changed.

[0157] Through the operations of a communication device (e.g., communication device (900)) according to the embodiments of the present disclosure, service quality for a specific service (e.g., VoNR service, voice service) can be satisfied even in a dead zone. The communication device can determine, through loss events, whether the loss of a terminal (e.g., terminal (120)) connected to the communication device is caused by environmental factors or by temporary circumstances. Furthermore, by adaptively changing the value of a timer for reordering in the PDCP layer, service quality suitable for the service for the terminal and the communication environment of the terminal can be provided. As a result, jitter and voice interruptions or distortions caused by delay time due to a timer (e.g., PDCP reordering timer) in a dead zone can be reduced. By efficiently utilizing the timer, reliability can be ensured and quality related to service real-time performance can be improved.

[0158] The effects obtainable from the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure belongs from the description below.

[0159] In describing the embodiments of the present disclosure, uplink transmission has been described as an example, but the embodiments of the present disclosure are not limited thereto. Changing the value of a timer for reordering the PDCP layer based on loss events and loss rates in downlink transmission or sidelink transmission may also be understood as an embodiment of the present disclosure. The receiving PDCP entity in the downlink transmission or the receiving PDCP entity in the sidelink transmission may be referred to as a terminal (e.g., terminal (120)).

[0160] In embodiments of the present disclosure, an apparatus is provided that provides functions of a packet data convergence protocol (PDCP) layer for communicating with a terminal. The apparatus may include at least one processor comprising a processing circuit; and a memory for storing instructions. When the instructions are executed individually or collectively by the at least one processor, the apparatus may determine whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the terminal corresponds to a predetermined value, and upon determining that the QoS identifier does not correspond to the predetermined value, perform a reordering procedure using a timer having a defined value, and upon determining that the QoS identifier corresponds to the predetermined value: in the PDCP layer, determine whether a loss event has occurred based on PDCP data for the DRB received from a lower layer, and upon determining that the loss event has occurred in the PDCP layer, perform a reordering procedure using a timer having a value identified based on the loss rate. The above reordering procedure may include transmitting PDCP data stored in the receiving buffer of the PDCP layer to the upper layer in ascending order of count values ​​when the timer expires.

[0161] In embodiments of the present disclosure, a method is provided by a device that provides functions of a packet data convergence protocol (PDCP) layer to communicate with a terminal. The method may include: an operation of determining whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the terminal corresponds to a predetermined value; an operation of performing a reordering procedure using a timer having a defined value upon determining that the QoS identifier does not correspond to the predetermined value; an operation of determining whether a loss event has occurred in the PDCP layer based on PDCP data for the DRB received from a lower layer upon determining that the QoS identifier corresponds to the predetermined value; and an operation of performing a reordering procedure using a timer having a value identified based on a loss rate upon determining that the loss event has occurred in the PDCP layer. The reordering procedure may include transmitting PDCP data stored in the receiving buffer of the PDCP layer to an upper layer in ascending order of count values ​​when the timer expires.

[0162] In embodiments of the present disclosure, a communication device is provided that communicates with a terminal and provides functions of a packet data convergence protocol (PDCP) layer. The communication device may include at least one processor comprising a processing circuit; and a memory for storing instructions. When the instructions are executed individually or collectively by the at least one processor, the communication device may determine whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the terminal corresponds to a predetermined value, and upon determining that the QoS identifier does not correspond to the predetermined value, perform a reordering procedure using a timer having a fixed value, and upon determining that the QoS identifier corresponds to the predetermined value: in the PDCP layer, determine whether a loss event has occurred based on PDCP data for the DRB received from a lower layer, and upon determining that the loss event has occurred in the PDCP layer, perform a reordering procedure using a timer having a reconfigured value based on the loss rate. The above reordering procedure may include transmitting PDCP data stored in the receiving buffer of the PDCP layer to the upper layer in ascending order of count values ​​when the timer expires.

[0163] For example, the above-mentioned predetermined value may correspond to '1' representing an interactive voice service or '2' representing an interactive video service.

[0164] For example, when the above instructions are executed individually or collectively by the at least one processor, the communication device determines the number of cases in which the value obtained by subtracting the count value of the most recently received PDCP PDU before receiving the PDCP PDU from the count value of the PDCP PDU (protocol data unit) is greater than 1 in order to determine whether the loss event has occurred, and if the determined number of such cases is greater than or equal to a reference threshold, it determines that the loss event has occurred, and if the determined number of such cases is less than the reference threshold, it determines that the loss event has not occurred.

[0165] For example, when the above instructions are executed individually or collectively by the at least one processor, the communication device may be caused to perform the reordering procedure based on the current setting value of the timer according to the determination that the loss event has not occurred.

[0166] For example, the above instructions may cause the communication device to determine whether the loss rate is greater than or equal to a loss threshold value to perform the reordering procedure using a timer having a value reconfigured based on the loss rate when executed individually or collectively by the at least one processor, and to set the value of the timer for the reordering procedure to a first value greater than the current set value according to the determination that the loss rate is greater than or equal to the loss threshold value, and to set the value of the timer for the reordering procedure to a second value smaller than the current set value according to the determination that the loss rate is less than the loss threshold value.

[0167] For example, when the above instructions are executed individually or collectively by the at least one processor, the communication device may determine to maintain the current setting value of the timer when the loss rate is greater than or equal to the loss threshold and the current setting value of the timer is a minimum value, and determine to maintain the current setting value of the timer when the loss rate is less than the loss threshold and the current setting value of the timer is a maximum value, and cause the reordering procedure to be performed using the timer having the maintained current setting value. The minimum value may be 20 ms (milliseconds). The maximum value may be less than 100 ms.

[0168] For example, the difference between the current setting value and the first value or the difference between the current setting value and the second value can be determined according to the loss rate.

[0169] For example, the above loss rate can be measured through PDCP PDUs received from the lower layer during a certain time interval. The certain time interval can be determined according to the type of service represented by the predetermined value.

[0170] For example, the above DRB can support header compression using ROHC (robust header compression). The profile of the above ROHC may refer to RTP (real-time protocol).

[0171] For example, the above QoS identifier may include a 5G QoS identifier (5QI). A QoS flow mapped to the above DRB may be associated with the above QoS identifier. The above DRB may include a UM DRB utilizing radio link control (RLC) unacknowledged mode (UM). The above upper layer may correspond to a service data adaptive protocol (SDAP) layer. The above lower layer may correspond to an RLC layer. The above communication device may correspond to a gNB (next generation node base station) or gNB--CU (central unit) having the above PDCP layer.

[0172] In embodiments of the present disclosure, a method is provided by a communication device that communicates with a terminal and provides functions of a packet data convergence protocol (PDCP) layer. The method may include: determining whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the terminal corresponds to a predetermined value; performing a reordering procedure using a timer having a fixed value upon determining that the QoS identifier does not correspond to the predetermined value; determining whether a loss event has occurred in the PDCP layer based on PDCP data for the DRB received from a lower layer upon determining that the QoS identifier corresponds to the predetermined value; and performing a reordering procedure using a timer having a value reconstructed based on a loss rate upon determining that the loss event has occurred in the PDCP layer. The reordering procedure may include transmitting PDCP data stored in the receiving buffer of the PDCP layer to an upper layer in ascending order of count values ​​when the timer expires.

[0173] For example, the above-mentioned predetermined value may correspond to '1' representing an interactive voice service or '2' representing an interactive video service.

[0174] For example, the operation of determining whether the above loss event has occurred may include: determining the number of cases in which the value obtained by subtracting the count value of the most recently received PDCP PDU before receiving the PDCP PDU from the count value of the PDCP PDU (protocol data unit) is greater than or equal to 1; determining that the above loss event has occurred when the determined number of said cases is greater than or equal to a reference threshold; and determining that the above loss event has not occurred when the determined number of said cases is less than the reference threshold.

[0175] For example, the above method may include an operation to perform the reordering procedure based on the current setting value of the timer according to the determination that the loss event has not occurred.

[0176] For example, the operation of performing the reordering procedure using a timer having a value reconstructed based on the above loss rate may include: an operation of determining whether the loss rate is greater than or equal to a loss threshold; an operation of setting the timer for the reordering procedure to a first value greater than a current setting value according to the determination that the loss rate is greater than or equal to the loss threshold; and an operation of setting the timer for the reordering procedure to a second value smaller than the current setting value according to the determination that the loss rate is less than the loss threshold.

[0177] For example, the above method may include an operation to determine to maintain the current setting value of the timer when the loss rate is greater than or equal to the loss threshold and the current setting value of the timer is a minimum value, an operation to determine to maintain the current setting value of the timer when the loss rate is less than the loss threshold and the current setting value of the timer is a maximum value, and an operation to perform the reordering procedure using the timer having the maintained current setting value. The minimum value may be 20 ms (milliseconds). The maximum value may be less than 100 ms.

[0178] For example, the difference between the current setting value and the first value or the difference between the current setting value and the second value can be determined according to the loss rate.

[0179] For example, the above loss rate can be measured through PDCP PDUs received from the lower layer during a certain time interval. The certain time interval can be determined according to the type of service represented by the predetermined value.

[0180] For example, the above DRB can support header compression using ROHC (robust header compression). The profile of the above ROHC may refer to RTP (real-time protocol).

[0181] For example, the above QoS identifier may include a 5G QoS identifier (5QI). A QoS flow mapped to the above DRB may be associated with the above QoS identifier. The above DRB may include a UM DRB utilizing radio link control (RLC) unacknowledged mode (UM). The above upper layer may correspond to a service data adaptive protocol (SDAP) layer. The above lower layer may correspond to an RLC layer. The above communication device may correspond to a gNB (next generation node base station) or gNB--CU (central unit) having the above PDCP layer.

[0182] In embodiments of the present disclosure, a non-transient computer-readable storage medium may store instructions. The instructions may cause a communication device that communicates with a terminal and provides functions of a packet data convergence protocol (PDCP) layer, when executed collectively or individually by at least one processor, to perform operations including: determining whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the terminal corresponds to a predetermined value; performing a reordering procedure using a timer having a fixed value upon determining that the QoS identifier does not correspond to the predetermined value; determining whether a loss event has occurred in the PDCP layer based on PDCP data for the DRB received from a lower layer upon determining that the QoS identifier corresponds to the predetermined value; and performing a reordering procedure using a timer having a reconfigured value based on a loss rate upon determining that the loss event has occurred in the PDCP layer. The above reordering procedure may include transmitting PDCP data stored in the receiving buffer of the PDCP layer to the upper layer in ascending order of count values ​​when the timer expires.

[0183] For one or more embodiments, at least one of the components described in one or more of the prior art drawings may be configured to perform one or more operations, techniques, processes and / or methods as described in the present disclosure. For example, a processor (e.g., a baseband processor) described in the present disclosure in relation to one or more of the prior art drawings may be configured to operate according to one or more examples described in the present disclosure. As another example, circuits associated with user equipment (UE), a base station, a network element, etc., as described above in relation to one or more of the prior art drawings may be configured to operate according to one or more examples described herein.

[0184] Any of the embodiments described above may be combined with any other embodiment (or combination of embodiments) unless otherwise explicitly stated. The foregoing description of one or more embodiments is for illustrative and explanatory purposes only, and is not intended to limit or exhaust the scope of the embodiments in the exact form disclosed. Modifications and variations are possible in light of the foregoing teachings or may be obtained from the practice of various embodiments.

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

[0186] When implemented in software, a computer-readable storage medium (e.g., a non-transient computer-readable storage medium) storing one or more programs (software modules) may be provided. One or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. One or more programs include instructions that cause the electronic device to execute methods according to the claims or embodiments described in the specification of this disclosure. The one or more programs may be provided as a computer program product. The computer program product may be traded between a seller and a buyer 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 distributed online (e.g., download or upload) through an application store (e.g., Play Store™) or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created on a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

[0187] Such 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. Alternatively, they may be stored in memory composed of some or all of these. Additionally, each constituent memory may include multiple units.

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

[0189] In the specific embodiments of the present disclosure described above, the components included in the disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0190] According to the embodiments, one or more of the aforementioned components or operations may be omitted, or one or more other components or operations may be added. Generally or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the plurality of components in the same or similar manner as those performed by the corresponding component among the plurality of components prior to the integration. According to the embodiments, 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.

[0191] Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible within the scope of the present disclosure.

Claims

In a device that provides PDCP (packet data convergence protocol) layer functions to communicate with a terminal: At least one processor including a processing circuit; and It includes memory for storing instructions, When the above instructions are executed individually or collectively by the at least one processor, the device: Determining whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the above terminal corresponds to a predetermined value, and Based on the determination that the above QoS identifier does not correspond to the above predetermined value, a reordering procedure is performed using a timer having a defined value, and Depending on determining that the above QoS identifier corresponds to the above-determined value: In the above PDCP layer, it is determined whether a loss event has occurred based on PDCP data for the DRB received from the lower layer, and Based on the determination that the loss event has occurred in the above PDCP layer, a reordering procedure is triggered using a timer having a value identified based on the loss rate, and The above reordering procedure includes, when the timer expires, transmitting PDCP data stored in the receive buffer of the PDCP layer to the upper layer in ascending order of count values. device. In claim 1, The above-mentioned predetermined value corresponds to '1' representing an interactive voice service or '2' representing an interactive video service, device. In claim 1, When the above instructions are executed individually or collectively by the at least one processor, the device determines whether the loss event has occurred: Determine the number of cases where the value obtained by subtracting the count value of the most recently received PDCP PDU prior to receiving the PDCP PDU from the count value of the PDCP PDU is greater than 1, and If the number of the above cases determined above is greater than or equal to a reference threshold, it is determined that the loss event has occurred, and If the determined number of the above cases is less than the reference threshold, causing to determine that the loss event did not occur, device. In claim 1, When the above instructions are executed individually or collectively by the at least one processor, the device: Causing the reordering procedure to be performed based on the current setting value of the timer, in accordance with the determination that the above loss event did not occur, device. In claim 1, To perform the reordering procedure using a timer having the value identified based on the loss rate when the above instructions are executed individually or collectively by the at least one processor, the device: Determine whether the above loss rate is above a loss threshold, and Based on the determination that the above loss rate is greater than or equal to the above loss threshold, the value of the timer for the above reordering procedure is set to a first value greater than the current set value, and Causing the value of the timer for the reordering procedure to be set to a second value smaller than the current setting value, based on the determination that the above loss rate is less than the above loss threshold value, device. In claim 5, When the above instructions are executed individually or collectively by the at least one processor, the device: If the above loss rate is greater than or equal to the above loss threshold and the current setting value of the timer is a minimum value, it is decided to maintain the current setting value of the timer, and If the above loss rate is less than the above loss threshold and the current setting value of the timer is the maximum value, it is decided to maintain the current setting value of the timer, and Causing the reordering procedure to be performed using the timer having the maintained current setting value, and The above minimum value is 20ms (milliseconds), and The above maximum value is less than 100ms, device. In claim 5, The difference between the current setting value and the first value or the difference between the current setting value and the second value is determined according to the loss rate. device. In claim 1, The above loss rate is measured through PDCP PDUs received from the lower layer during a certain time interval, and The above fixed time interval is determined according to the type of service represented by the above predetermined value, device. In claim 1, The above DRB supports header compression using ROHC (robust header compression), and The above ROHC profile refers to RTP (real-time protocol), device. In claim 1, The above QoS identifier includes 5QI (5G QoS identifier), and The QoS flow mapped to the above DRB is associated with the above QoS identifier, and The above DRB includes a UM DRB that utilizes RLC (radio link control) UM (unacknowledged mode), and The above upper layer corresponds to the SDAP (service data adaptive protocol) layer, and The above lower layer corresponds to the RLC layer, and The above device corresponds to a gNB (next generation node base station) or gNB--CU (central unit) having the above PDCP layer, device. A method performed by a device that provides functions of the PDCP (packet data convergence protocol) layer to communicate with a terminal, An operation to determine whether a quality of service (QoS) identifier associated with a data radio bearer (DRB) for the above terminal corresponds to a predetermined value, and An operation to perform a reordering procedure using a timer having a defined value based on a determination that the above QoS identifier does not correspond to the above predetermined value, and Depending on determining that the above QoS identifier corresponds to the above-determined value: In the above PDCP layer, an operation to determine whether a loss event has occurred based on PDCP data for the DRB received from the lower layer, and Based on the determination that the loss event has occurred in the PDCP layer, the method includes an operation to perform a reordering procedure using a timer having a value identified based on the loss rate. The above reordering procedure includes, when the timer expires, transmitting PDCP data stored in the receive buffer of the PDCP layer to the upper layer in ascending order of count values. method. In claim 11, The above-mentioned predetermined value corresponds to '1' representing an interactive voice service or '2' representing an interactive video service, method. In claim 11, The operation to determine whether the above loss event has occurred is, An operation to determine the number of cases where the value obtained by subtracting the count value of the most recently received PDCP PDU prior to receiving the PDCP PDU from the count value of the PDCP PDU (protocol data unit) is greater than or equal to 1, and An operation to determine that the loss event has occurred when the number of the above cases determined above is greater than or equal to a reference threshold, and A method including an operation to determine that the loss event did not occur when the determined number of the above cases is less than the reference threshold value. method. In claim 11, Further including the operation of performing the reordering procedure based on the current setting value of the timer according to the determination that the above loss event did not occur, method. In claim 11, The operation of performing the reordering procedure using a timer having the value identified based on the above loss rate is: An operation to determine whether the above loss rate is above a loss threshold, and An operation to set the timer for the reordering procedure to a first value greater than the current set value, based on a determination that the above loss rate is greater than or equal to the above loss threshold value, and Based on the determination that the above loss rate is less than the above loss threshold, the operation of setting the timer for the reordering procedure to a second value smaller than the current setting value, method.

Images