Method for controlling PDCP transmitters and receivers

Abstract

This describes a method for controlling PDCP transmitters and receivers. The method describes how to control PDCP transmitters and receivers to reduce delays in PDCP PDU delivery caused by previously unreceived PDCP PDUs without excessively increasing overhead.

Description

Technical Field

[0001] The present invention generally relates to a method for controlling a PDCP transmitter and a PDCP receiver. More particularly, the present invention relates to extended reality (XR) in 3GPP's 5G NR.

Background Art

[0002] Wireless communication systems are being widely deployed to handle a wide range of applications, from mobile broadband, massive machine-type communication to ultra-reliable low-latency communication (URLLC). Such systems enable multiple user equipment (UE) or mobile terminals to share the wireless medium through a radio access network (RAN) via one or more base stations to exchange several types of data content (e.g., video, audio, messaging, etc.).

[0003] Examples of such wireless multi-connection communication systems include systems based on the 3rd Generation Partnership Project (3GPP (registered trademark)) standards, such as the 4th Generation (4G) Long Term Evolution (LTE) or the recent 5th Generation (5G) New Radio (NR) system, or systems based on IEEE802.11 standards such as Wi-Fi. Among the requirements of 5G NR, there are service requirements related to extended reality (XR).

[0004] XR (Extended Reality) applications are defined in 3GPP document RP-2200285 as "various types of extended, virtual, and mixed environments in which human-to-machine and human-to-human communications are performed with the assistance of handheld and wearable end-user devices".

[0005] Various use cases can be found in 3GPP document TR-26.928.

[0006] Many XR applications involve interaction between a wearable device (e.g., a 3D helmet or augmented reality glasses) and an application server. The wearable device and application server can be connected via a local network (such as Wi-Fi) or a cellular network (such as a 3GPP 5G cellular network, where the application server is connected to the 5G core network portion).

[0007] Some XR applications, such as cloud gaming, involve transferring compressed video data, audio data, and location information from the server to the user interface (UE), and from the UE to the server.

[0008] Some XR applications, such as virtual reality, involve transferring compressed video data, audio data, and various types of information from a server to a wearable device.

[0009] Some XR applications, such as augmented reality, involve transferring compressed video data, audio data, and various other types of information between wearable devices and servers.

[0010] In this disclosure, information exchanged between a UE or wearable device and a server is referred to as application data. For example, application data may include one or more images, video data, audio data, location information, and various other types of information.

[0011] Video and audio data are transferred between the wearable device (or user device) and the server using media transport protocols such as RTP (Real Time Protocol, RFC3550), SRTP (Secured RTP, RFC3711), HTTP (Hyper Text Transfer Protocol, RFC2616-7540), or QUIC (RFC8999, 9000, 9001, and 9002).

[0012] Video encoding and decoding can be performed according to various formats, including MPEG2, H.264, H.265, HEVC, and others.

[0013] Applications generate data by forming encoded video, audio, or location information. This data is primarily placed in data packets by the application, with application data packets representing a single unit of information being generated at the application level. 3GPP has named the set of PDUs (Protocol Data Units or Packet Data Units) required to forward application data packets a "PDU Set." Application data consists of one or more application data packets. On the downlink, 3GPP PDUs are formatted by the core network PDU layer. Similarly, on the uplink, 3GPP PDUs are formatted by the UE (User Equipment) PDU layer. In 3GPP, PDU Set delimiters (start, end, length) are not provided by the application but are generated by the core network (UEs, respectively) via Media Transport Protocol Packet Inspection. Detailed procedures can be found in 3GPP document TR-23.700-60.

[0014] A PDU Set consists of one or more PDUs (for example, a frame or video slice for an XRM service used in TR26.926) that carry the payload of a single unit of information generated at the application level. In some implementations, all PDUs in a PDU Set are required by the application layer to use the corresponding unit of information. In other implementations, the application layer can still reconstruct all or part of the information unit when some PDUs are missing. For example, a single PDU Set may contain data for a single image or frame from a video stream.

[0015] During the downlink, the PDU Set identification information calculated by the core network's UPF (User Plane Function) is inserted into the GTP-U (GPRS Tunneling Protocol-User Plane, TS29.281) header. GTP-U is the protocol used by UPF to transport data from the core network to the gNB. When the GTP-U PDU arrives at the gNB's SDAP (Service Data Adaptation Layer, TS37.324), the GTP-U header is removed, and the PDU Set identification information is no longer provided in bandwidth. Therefore, the UE (receiving side) during the downlink has no access to the PDU Set identification information.

[0016] In the uplink, the PDU Set identifier calculated by the UE's PDU layer is not inserted into any header, so the PDU Set identifier is not provided in bandwidth. Therefore, the gNB side (receiving side) in the uplink has no access to the PDU Set identifier. In summary, at all protocol layers (including the PDCP layer), the receiving entity has no knowledge of the PDU Set identifier, neither in the downlink nor the uplink.

[0017] On the transmitting side, all layers below the SDAP layer (e.g., PDCP transmitting entities) do not have access to the identification information of in-band PDU sets, but it is easy to imagine that some internal mechanisms associate out-of-band PDU set delimiter information with each PDU. For example, in a gNB, a GTP-U receiving entity can associate out-of-band PDU set delimiter information with each PDU and pass them to the PDCP transmitting entity. Another example is in an UE, where the PDU layer can associate out-of-band PDU set delimiter information with each PDU and pass them to the PDCP transmitting entity.

[0018] The network used to transfer application data may undergo perturbations and congestion. Therefore, some PDUs in a PDU set may be missing or delayed on the receiving end (the UE's PDU layer on the downlink, or the core network's UPF on the uplink).

[0019] Some video decoder implementations require the reception of complete application data packets (a full PDU Set) in a timely manner to properly decode video. Other implementations, on the other hand, can tolerate delayed arrival of data packets in the PDU Set or partial delivery of data packets. For example, these implementations rely on Forward Error Correction (FEC) or concealment techniques.

[0020] In document TR-23.700-60, 3GPP defined a PDU Set QoS parameter called PSDB (PDU Set Delay Budget) that defines the time budget allocated to the transport of PDU Sets across 5G systems. This QoS parameter, defined by the application, is used by 5G systems to evaluate whether PDU Sets (Application Data Packets) are delivered on time.

[0021] In the same 3GPP document TR-23.700-60, another QoS parameter called PSII (PDU Set Integrated Indication) is defined to characterize the decoder's tolerance for lost or stale data. When the PSII parameter is set to "true," the decoder can only process complete application data packets that are received on time. When PSII is set to "false," the decoder can tolerate both incomplete and delayed application data packets. In other 3GPP documents, the PSII QoS parameter is also referred to as PSIHI (PDU Set Integrated Handling Indication).

[0022] In a 5G system, when a PDU Set is being transmitted over the air interface within the wireless network, several pieces of information are available regarding the PDU reception status and the elapsed time of the PDU Set Delay Budget. For example, when a PDU Set is being forwarded over the air, a RAN node (Radio Access Network Node, either UE or gNB) can detect that one PDU transmission has failed despite all retransmission and error correction mechanisms. If the PSII QoS parameter is set to "true" at this time, it means that the entire PDU Set is useless to the application. In that case, if the PDUs in this "useless" PDU Set are pending transmission over the air interface, the RAN node can consider discarding the remaining transmissions of these PDUs, thus achieving resource conservation on the wireless network.

[0023] In 3GPP document RP-223502, the deactivation of PDU Sets is intended to enhance radio access networks in order to increase the ability of 5G systems to handle XR applications.

[0024] 3GPP's 5G systems have two modes for delivering data to applications: in-sequence delivery and free delivery. In-sequence delivery involves the network delivering application data packets to the application (application server or UE) in the same order in which the application (application server or UE) delivered them to the network. Free delivery means that the order of packets is not guaranteed.

[0025] In 5G RANs (Radio Access Networks), there are various causes that can alter the order of packets. For example, retransmission based on windowed acknowledgment techniques, such as Hybrid ARQ (Hybrid Automatic Repeat reQuest), used in certain configurations of the RLC (Radio Link Control, TS38.322) layer or MAC layer (TS38.321). Carrier aggregation and dual connectivity are also known to cause changes in packet order.

[0026] In 5G RANs, the PDCP (Packet Data Convergence Protocol, TS38.323) layer may be configured to perform packet reordering. Because the PDCP layer is also used to coordinate data from dual connectivity or carrier aggregation, and because higher layers above PDCP do not perform retransmission, the sequential delivery of packets is guaranteed when the PDCP layer is configured to perform packet reordering in the 5G RAN portion of a 5G system.

[0027] The PDCP layer performs in-sequence delivery by monitoring the sequence numbers of PDCP PDUs. PDCP PDUs include sequence numbers in their headers. This sequence number is incremented by the PDCP transmission entity (UE in the uplink, gNB in the downlink). When in-sequence delivery is configured, the PDCP receiving entity is assumed to check the sequence number of the PDU when receiving a new PDCP PDU, and when the new sequence number follows the previously received sequence number, the PDCP receiving entity is assumed to deliver the PDCP PDU to the upper layer. If the new sequence number does not follow the previously received sequence number, a sequence number gap is detected, and the PDCP receiving entity is assumed not to deliver the PDCP PDU to the upper layer until all missing PDCP PDUs (those with sequence numbers lower than the current sequence number and higher than the previously received sequence number) are received. The waiting for missing packets is time-limited, and after the set amount of time has elapsed, the missing PDCP PDUs are considered to be deterministically lost, and the current PDCP PDU is delivered to the higher layer (upper layer). Missing PDCP PDUs are discarded if received after the waiting time has elapsed. The waiting time is controlled by a time counter named "t-ordering", also called the reordering counter. The value of the waiting time is set by the gNB (for both uplink and downlink) within the range of 1 millisecond to 3 seconds (see 3GPP document TS38.331).

[0028] According to 3GPP document R2-2300087, from the perspective of the core network and application layer, it is preferable for the 5G RAN subsystem to provide in-sequence delivery of packets, especially when it does not induce too much additional latency.

[0029] Special care is needed to avoid excessive delay in packet reordering.

[0030] In the case of XR, two functions, namely, the discard of PDU Set and the reordering of PDUs, are processed by PDCP according to the RAN2 agreement (R2-2304202, Report on LTE legacy, XR, QoE and MUSIM).

[0031] According to the R17 PDCP standard TS38.323, Packet Data Convergence Protocol (PDCP) specification (Release 17), the discard of PDUs must be indicated to the lower layer. In the lower layer, discarding a PDU with an assigned sequence number (SN) creates a gap in the PDCP sequence number at the receiving entity.

[0032] This problem was recognized and left for implementation in previous releases, as stated in the note in TS38.323, Packet Data Convergence Protocol (PDCP) specification (Release 17): "Discarding a PDCP SDU that is already associated with a PDCP SN causes an SN gap in the transmitted PDCP data PDU, which increases the delay of PDCP reordering at the receiving PDCP entity. The method to minimize the SN gap after SDU discard depends on the UE implementation."

[0033] By combining both the discard of PDU Set and the reordering of PDUs in the PDCP layer, the following unwanted behavior may occur: Assume a PDCP transmitting entity is transmitting PDCP PDUs belonging to a first PDU Set. The PDCP transmitting entity recognizes the PDU Set's identification information thanks to out-of-band signaling. If the PDCP transmitter detects at some point that the PDU Set discard conditions for the currently transmitted PDU Set have been met, it must discard the remaining PDCP PDUs belonging to the currently transmitted PDU Set, thereby conserving radio resources. As mentioned above, the PDU Set discard conditions include QoS parameters, delay budget, and PDU loss in PSII (PDU Set Integrated Indication). Then, at some other point, the PDCP transmitting entity begins transmitting PDCP PDUs belonging to a second PDU Set.

[0034] In the receiving entity, while waiting for PDCP PDUs belonging to the first PDU Set that cannot be received because they are to be discarded, the delivery of PDCP PDUs belonging to the second PDU Set to higher layers may experience an additional delay of up to (1 millisecond to 3 seconds) in the value of the reordering counter.

[0035] The worst-case scenario occurs when the reordering timer only starts counting in response to the reception of the first PDCP PDU in the second PDU Set. This means that previously received PDCP PDUs will have discontinuous sequence numbers compared to the newly received PDCP PDUs.

[0036] A closer examination of the effects of reordering delay reveals that the RRC standard TS38.331, the Radio Resource Control (RRC) protocol specification (Release 17), defines the t-ordering counter value as an countable millisecond (ms) value from 0 to 3000.

[0037] In RAN2 Technical Report TR38.835, NR; Study on XR enhancements for NR (Release 18), a target latency of 10ms for video is proposed. The meaning of t-ordering values ​​of 1ms, 2ms, 4ms, 5ms, or 8ms already represents 10% to 80% of the total latency budget.

[0038] This additional delay clearly contradicts the aforementioned 3GPP statement that in-sequence delivery via RAN (UE or gNB) is preferred unless additional delays are introduced. In fact, given the end-to-end latency requirement of the order of 10 milliseconds (3GPP document TR-38.835), an additional delay of 1 millisecond to 3 seconds is unacceptable. Such uncertainties, which are managed solely by the choice of implementation, make it difficult to assess whether critical requirements for XR are met.

[0039] In document R2-2300518, Samsung suggested that PDU Set delimiter information is transmitted in bandwidth, for example, in the PDCP header. A PDCP receiver with knowledge of the PDU Set delimiter information could then perform an in-sequence delivery procedure for each PDU Set to prevent the discarding of one PDU Set from affecting the delivery time of a second PDU Set.

[0040] However, in-band signaling of PDU Set delimiter information represents excessively added overhead, posing a high risk of undermining the bandwidth saving objective of discarding PDU Sets. Therefore, a method is needed to minimize the induced overhead while minimizing the additional delay caused by in-sequence delivery of PDCP PDUs in the event of PDU Set discarding. [Overview of the project]

[0041] This disclosure relates to the transmission of data using the Packet Data Convergence Protocol (PDCP) in a communication network including transmitters and receivers. In particular, this disclosure relates to the provision of a PDU Set Keep Indication that indicates at least one PDU (e.g., from a plurality of PDUs) to be retained by the receiver and / or at least one pending PDU to be discarded by the receiver.

[0042] According to a first aspect of the present invention, a method is provided for controlling a packet data convergence protocol (PDCP) in a communication network including a transmitter and a receiver, the method comprising: the transmitter transmitting a protocol data unit (PDU) of application data to the receiver; determining that a first PDU Set of the PDUs of the application data has not been fully received by the receiver; and transmitting a PDU Set Keep Indication to the receiver indicating one or more second PDUs of the PDUs of the application data to be retained by the receiver. The one or more second PDUs do not have to belong to the first PDU Set.

[0043] The PDU Set Keep Indication may be transmitted separately from the PDU of the application data.

[0044] The PDU Set Keep Indication may be inserted into the second PDU among the one or more second PDUs of the application data, and the one or more second PDUs belong to the second PDU Set.

[0045] The aforementioned PDU Set Keep Indication may be included in the control PDU.

[0046] The PDU Set Keep Indication may be a single bit in the second PDU, or it may be an appended bit to the header of the second PDU.

[0047] The actual problem arises when a second PDU set is being transmitted, so it is not essential to send a signaling immediately when a PDCP discard occurs. Different PDU sets may be multiplexed in the same DRB. The PDCP receiving entity may have several signal-to-noise gaps, some related to explicit discard actions performed by the remote PDCP transmitting entity, and some related to transmission errors. The discard signaling sent by the remote PDCP transmitting entity shall enable the PDCP receiving entity to clearly identify it among the existing gaps.

[0048] PDCP discard signaling may include information about PDUs belonging to different PDU sets.

[0049] The method may further include setting a PDU Set Keep Indication flag to a PDCP function implemented in the transmitter for transmitting the PDU Set Keep Indication, to indicate when the second PDU of the one or more second PDUs is ready to be transmitted to the receiver.

[0050] If the received data unit of the application data belonging to the first PDU Set is transmitted to a lower layer by the PDCP function, the method may further include notifying the lower layer to discard any ongoing transmissions of the first PDU.

[0051] The method may further include initializing a discard timer in the PDCP function implemented in the transmitter in response to receiving a service data unit (SDU) from a higher layer, wherein the determination that the first PDU Set has not been fully received by the receiver may include determining that the discard timer has expired without receiving an acknowledgment of receipt of the first PDU Set from the receiver.

[0052] The discard timer may be a PDU discard timer that is started when the SDU is received from the upper layer, or a PDU Set discard timer that is started when the first SDU of a PDU Set is received.

[0053] Determining that the first PDU Set has not been fully received may include receiving a report from the receiver indicating that the first PDU Set has not been fully received.

[0054] The method may further include determining the QoS parameters of the PDU Set for the first PDU Set, where the PDU Set Keep Indication may be transmitted to the PDCP receiver only when the values ​​of the PSIHI parameters are set to predetermined values.

[0055] The PDU Set sequence number of the first PDU Set may be used to identify one or more of the first PDUs.

[0056] At least one PDU from a first PDU Set (for example, one sent to a receiver) may be configured to be stored by the receiver. At least one of one or more second PDUs may be discarded from the memory buffer.

[0057] The method may further include determining whether the first PDU Set is part of an eXtended Reality (XR) PDU Set, where the PDU Set Keep Indication may be transmitted to the PDCP receiver only if the first PDU Set is an XR PDU Set set.

[0058] A second aspect of the present invention provides a method for controlling a packet data convergence protocol (PDCP) in a communication network including a transmitter and a receiver, the method comprising: the receiver receiving a protocol data unit (PDU) of application data from the transmitter; storing the received PDU in a memory buffer; receiving a PDU Set Keep Indication from the transmitter, which indicates one or more PDUs that the receiver should keep; and / or discarding one or more pending PDUs stored in the memory buffer that are not indicated by the PDU Set Keep Indication.

[0059] Stored PDUs may belong to the first PDU Set of application data. One or more pending PDUs stored in the memory buffer do not have to belong to the first PDU Set.

[0060] This method may further include initializing a reordering timer when an out-of-order PDU is received, and resetting the reordering timer after receiving the PDU Set Keep Indication.

[0061] Receiving the PDU Set Keep Indication may involve checking the header of the PDU received for the PDU Set Keep Indication.

[0062] Receiving the PDU Set Keep Indication may involve receiving the PDU Set Keep Indication separately from the PDU of the application data.

[0063] Discarding a pending PDU may involve discarding one or more pending PDUs received prior to the PDU Set Keep Indication.

[0064] This method may further include distributing the stored PDU to a higher layer based on the PDU Set Keep Indication using the PDCP function implemented in the receiver.

[0065] The PDU Set Keep Indication may indicate that the first PDU Set has not been fully received by the receiver.

[0066] The transmitter may be a PDCP transmitter, and the receiver may be a PDCP receiver.

[0067] According to a third aspect of the present invention, a transmitter as described in claim 22 of the appended claims is provided.

[0068] According to a fourth aspect of the present invention, a receiver as described in claim 23 of the appended claims is provided.

[0069] According to a fifth aspect of the present invention, a computer program as described in claim 24 of the appended claims is provided.

[0070] According to a sixth aspect of the present invention, a computer-readable medium is provided as described in claim 25 of the appended claims.

[0071] Any feature in one aspect of the present invention may be applied to other aspects of the present invention in any suitable combination. In particular, aspects of a method may be applied to aspects of an apparatus / device / unit, and vice versa.

[0072] Furthermore, features implemented in hardware may also be implemented in software, and vice versa. Any references to software and hardware features in this specification should be interpreted accordingly. For example, according to another aspect of the present invention, a computer program is provided which, when the program is executed by one or more processing units, includes instructions causing one or more processing units to perform any of the methods described above, or examples, and a computer-readable storage medium for carrying the computer program. [Brief explanation of the drawing]

[0073] Herein, various embodiments of the present invention will be described with reference to the following drawings, merely as examples. [Figure 1] This is a schematic diagram showing a first exemplary wireless communication system in which the present invention may be implemented according to one or more embodiments of the present invention. [Figure 2] A block schematic diagram of an exemplary configuration of a UE in which the present invention may be implemented according to one or more embodiments of the present invention is shown. [Figure 3] A block schematic diagram shows an exemplary configuration of a base station in which the present invention may be implemented according to one or more embodiments of the present invention. [Figure 4] Figure 1 is a block schematic diagram showing the protocol stack of the data plane of a 5G NR system. [Figure 5] This is a block schematic diagram of an exemplary embodiment of the PDCP protocol layer according to 3GPP document TS38.323. [Figure 6a] This is a schematic and simplified diagram of an exemplary message flow illustrating the PDCP receiving entity reordering function according to 3GPP document TS38.323. [Figure 6b] This is a schematic and simplified diagram of another exemplary message flow illustrating the PDCP receiving entity reordering function according to 3GPP document TS38.323. [Figure 7a] This is a schematic and simplified diagram of an exemplary message flow illustrating the PDCP receiving entity reordering function according to an embodiment of the present invention. [Figure 7b] This is a schematic and simplified diagram of another exemplary message flow illustrating the PDCP receiving entity reordering function according to an embodiment of the present invention. [Figure 8] This flowchart shows an exemplary method performed by a PDCP transmission entity to process PDU discard conditions according to an embodiment of the present invention. [Figure 9] This flowchart shows an exemplary method performed by a PDCP transmission entity for PDU transmission according to an embodiment of the present invention. [Figure 10] This flowchart shows an exemplary method performed by a PDCP receiving entity for PDU reception according to an embodiment of the present invention. [Figure 11] This flowchart illustrates an exemplary method performed by a PDCP receiving entity for receiving a PDU Set Keep Indication control PDU according to an embodiment of the present invention. [Figure 12a] This is a block schematic diagram showing a PDCP data PDU for a DRB and MRB having a 12-bit PDCP SN, according to an embodiment of the present invention. [Figure 12b] This is a schematic block diagram showing a PDCP data PDU for a DRB and MRB having an 18-bit PDCP SN, according to an embodiment of the present invention. [Figure 12c] This is a block schematic diagram showing a PDCP data PDU for a sidelink DRB for unicast using an 18-bit PDCP SN, according to an embodiment of the present invention. [Figure 13a]This is a block schematic diagram showing a PDCP data PDU for a DRB and MRB having a 12-bit PDCP SN, according to an embodiment of the present invention. [Figure 13b] This is a schematic block diagram showing a PDCP data PDU for a DRB and MRB having an 18-bit PDCP SN, according to an embodiment of the present invention. [Figure 13c] This is a block schematic diagram showing a PDCP data PDU for a sidelink DRB for unicast using an 18-bit PDCP SN, according to an embodiment of the present invention. [Figure 14] This is a schematic block diagram showing a PDCP-controlled PDU for PDU Set Keep Indication according to an embodiment of the present invention. [Modes for carrying out the invention]

[0074] Figure 1 shows an exemplary wireless communication system 100, in particular a mobile wireless communication system such as a fifth-generation (5G) New Radio (NR) system that supports eXtended reality services (XR). While embodiments and examples of the present invention will be described in relation to a 5G NR system in the following description, it will be understood that the present invention is not limited to a 5G NR system and can be used in any wireless communication system that supports XR or similar services.

[0075] System 100 has a user device (UE) 101 (or 151) which may be a virtual reality helmet or augmented reality wearable (e.g., glasses) provided by base station 110 to communicate with a core network, such as a 5G core network 102. The UE may be any radio device, such as a radio communication device or apparatus or terminal, IoT device, machine-type communication (MTC) device, device-to-device (D2D) terminal, or user device (e.g., smartphone, laptop, mobile phone, tablet, camera, game console, wearable device), capable of radio communication with one or more core networks via one or more radio access networks. Base station 110 is a network node that provides an access point to the core network for the UE and is part of a radio access network (RAN) consisting of base stations 110 and 111. In NR, base stations are called next-generation node B (gNB), the RAN is next-generation (NG)RAN, and the core network is called 5GC. Hereafter, the terms RAN node, base station, and gNB are used interchangeably. Base stations 110 and 111 are interconnected using an Xn interface implemented on wired or wireless link 130 (as specified in 3GPP document TS38.423). Each base station is connected to the core network 102 using an NG interface implemented on wired or wireless links 140 and 141 (as specified in 3GPP document TS38.413).

[0076] Each of these base stations controls one or more cells. For example, base station 110 controls cell 120, and base station 111 controls cell 121. A cell is a geographical area of ​​a radio network, defined by the frequency used in the cell to transmit data. A cell can be uniquely identified by a UE from identification information broadcast across its geographical area. Each of base stations 110, 111 may serve several UEs, such as UE 101 or UE 151. When a UE establishes an RRC connection with a base station, the base station to which the UE connects is called the UE's serving base station or source base station, and the cell controlled by the serving base station where the UE camps is called the serving cell. The interface between the gNB and the UE is a Uu interface that uses the protocol sublayers in the user plane: SDAP (Service Data Adaptation Protocol), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical), and the protocol sublayers in the control plane: RRC (Radio Resource Control), PDCP, RLC, MAC, and PHY.

[0077] UE101 receives and / or transmits XR data for one or more multicast XR sessions generated and / or destined for the XR application server 103. The XR data is provided to base station 111, which is the base station controlling cell 121 to which UE101 is attached, via the core network 102 (through the data network 160 and user plane function 161) and via the transport bearer 106 (also known as the GTP-U tunnel) over link 141. The XR data is then transmitted from base station 111 to UE101 via a Data Radio Bearer (DRB) 154. Figure 1 also shows UE151 receiving the data via DRB 153. The radio bearer is a set of PHY (Layer 1) and MAC (Layer 2) parameters that enable higher-layer data connectivity between the UE and the gNB. 5G NR defines several types of radio bearers: SRB (Signalling Radio Bearer) for the control plane, DRB (Data Radio Bearer) which enables point-to-point communication (unicast) with a single UE in the user plane, and MRB which enables point-to-point communication and point-to-multipoint communication (multicast / broadcast) with multiple UEs in the user plane.

[0078] Figure 2 shows a block diagram of a UE device 205, such as UE101 or UE151 in Figure 1, in which the present invention may be implemented according to one or more embodiments of the present invention. The UE includes components for transmitting and receiving communications, including, for example, a UE communications manager 220, an I / O controller 255, a transceiver 235, a set of antennas 245, memory 225, and a processor (CPU: Central Processing Unit) 215. All of these elements can communicate with one another.

[0079] Memory 225 includes RAM (Random Access Memory), ROM (Read-Only Memory), or a combination of both, or, in non-exclusive examples, mass storage devices such as disks or solid-state drives. Basic Input / Output System (BIOS) instructions may be stored in memory 225.

[0080] The processor 215 is configured to execute machine-readable instructions. Execution of these machine-readable instructions causes the UE to perform various functions. These functions may involve, for example, communication with or interaction with peripheral devices such as a keyboard, screen, or mouse (not shown in Figure 2). The processor may run an operating system such as iOS, Windows, or Android. The processor 215 may be a single processor or may include two or more processors that perform the processing required for the operation of the UE 205. The number of processors and the assignment of processing functions to the processors are design choices for those skilled in the art.

[0081] The I / O controller 255 provides the necessary hardware and enables these interactions with external peripherals by managing input and output signals.

[0082] The transceiver 235 is configured to provide bidirectional wireless communication with other wireless devices. For example, it provides a modem and frequency shifter necessary for connecting to one or more wireless networks such as Wi-Fi, Bluetooth®, LTE, and 5G NR. The transceiver 235 may have a PDCP transmitter and a PDCP receiver. The PDCP transmitter and PDCP receiver may be implemented by the processor 215. The PDCP transmitter and PDCP receiver may be software-only functions implemented by the processor 215.

[0083] The wireless communication uses an antenna set 245 adapted to the spectrum of the frequency-converted signal issued from the baseband modem. The antenna set 245 may be limited to one antenna, but preferably includes several antennas to provide beamforming capability.

[0084] The UE communications manager 220 handles the establishment, control, and release of communication between the UE and the radio access network. The UE periodically receives indications from the base station of available slots for communication between the UE and the base station. The UE then knows the time and frequency at which it must wait for incoming data or transmit its own outgoing data, regardless of whether they belong to the control plane or the data plane. In an exemplary implementation, the UE communications manager 220 implements the Uu interface.

[0085] Figure 3 shows a block diagram of a base station device 305 in which the present invention may be implemented according to one or more embodiments of the present invention, such as the base station or gNB110 and 111 of Figure 1. The base station device 305 includes components for transmitting and receiving communications, including, for example, at least one of a base station communications manager 320, a core network communications manager 355, a transceiver 335, a set of antennas 345, memory 325, a processor (CPU) 315, and an inter-station communications manager 365. All of these elements can communicate with one another.

[0086] The base station communication manager 320 handles communication with multiple UEs. It is responsible for establishing, controlling, and releasing these communications. In an exemplary implementation, the base station communication manager 320 implements the Uu interface. The base station communication manager 320 includes a scheduler that assigns time-frequency slots to communications between different UEs. Information regarding the scheduling of these slots is periodically sent to the participating UEs.

[0087] The core network communication manager 355 manages communication between base stations and the core network. It may provide a standardized NG interface, such as those defined by 3GPP standards, to support these communications.

[0088] The transceiver 335 is configured to provide bidirectional wireless communication with other wireless devices. These devices may be UEs or even other base stations. The transceiver 335 provides the modem and frequency shifter necessary to connect in parallel to multiple UEs using different frequency carriers in time division duplexing (TDD) or frequency division duplexing (FDD). The transceiver 335 may include a PDCP transmitter and a PDCP receiver. The PDCP transmitter and PDCP receiver may be implemented by the processor 315. The PDCP transmitter and PDCP receiver may be software-only functions implemented by the processor 315. The transceiver 335 may be limited to one antenna, but is preferably connected to an antenna set 345 which includes several antennas to provide beamforming capability.

[0089] Memory 325 includes RAM, ROM, or a combination of both, or, in non-exclusive examples, mass storage devices such as disks or solid-state drives. BIOS instructions may be stored within memory 325 to support the operating system.

[0090] The inter-station communication manager 365 manages communication with other base stations. To support these communications, the inter-station communication manager 365 may provide a standardized Xn interface, such as those defined by 3GPP standards.

[0091] Figure 4 is a block schematic diagram showing the protocol stack of the data plane of a 5G NR system as shown in Figure 1. This data plane protocol stack is described in detail in 3GPP document TS23.501. In the downlink direction, application server 103 connects to UPF (User Plane Function) 161 via data network 160 at the PDU layer 402 level. The PDU layer corresponds to PDUs carried between UE (User Equipment) and DN (Data Network) via PDU sessions. If the PDU Session Type is IPv4, IPv6, or IPv4v6, it corresponds to IPv4 packets, IPv6 packets, or both. If the PDU Session Type is Ethernet, it corresponds to Ethernet frames. During PDU session establishment time, the core network provides session QoS parameters to the UPF, gNB, and UE. The PDU session QoS parameters include the QoS parameters of the XR PDU Set (S2-2302696): 1. PDU Set Delay Budget 2. PDU Set Error Rate 3. PDU Set Integrated Handling Indication. Formerly known as PDU Set Integrated Indication.

[0092] When a PDU (in the description of Figure 4, unless otherwise specified, PDU refers to a packet handled by PDU layer 402, all other layers handle other types of PDUs, those PDUs are prefixed with the layer name, e.g., PDCP PDU) arrives at UPF PDU layer 402, UPF performs an inspection of the application packet to determine the boundaries of the PDU set. Document S2-2302696 provides an example of how to identify a PDU set when inspecting the RTP / SRTP header, RTP header extensions, H.264 RTP payload, H.265 RTP payload, and H.266 RTP payload.

[0093] The PDU Set identification information described in S2-2303842 is determined by the UPF and sent to the NG-RAN in the GTP-U header. The PDU Set identification information includes: - PDU Set sequence number - Indication of End PDUs in a PDU Set -PDU sequence number in PDU Set - PDU Set size in bytes - PDU Set importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS flow.

[0094] At the uplink, the application is placed on the UE. As previously described, once a PDU session is established, the UE obtains PDU session QoS parameters from the core network. When the PDU generated by application 403 arrives at the UE's PDU layer 402, the UE performs an inspection of the application packet to determine the PDU set boundary, in the same manner as described above for UPF.

[0095] In both the downlink and uplink, application 103 transmits data to and receives data from NG-RAN via a GPRs tunnel (GTP-U layer 404, TS29.281).

[0096] In the downlink, the UPF detects the identification information of the PDU Set and retrieves a set of mapping rules (filtering rules) from the core network. The filtering rules define how each PDU Set is mapped to a QoS flow. QoS flows are identified by identifiers, and GTP-U PDUs are marked according to the determined QoS flow identifiers. In the gNB, relay layer 406 extracts the PDU Set identification information and QoS flow identifiers from the GTP-U PDUs and maps them to SDAP QoS flows. Multiple PDU Sets can be mapped to the same QoS flow in a single XR session, or several PDU Sets can be mapped to different QoS flows in a single XR session. Then, according to 3GPP document TR-38.835, in one option, each SDAP QoS flow can be mapped to a different PDCP DRB (Data Radio Bearer), and in a second option, all SDAP QoS flows from the same XR session are mapped to a single PDCP DRB.

[0097] In the uplink, the UE detects the PDU Set's identification information at PDU Layer 402 and retrieves a set of mapping rules (filtering rules) from the core network. The filtering rules define how each PDU Set is mapped to a QoS flow. The UE maps the XR PDUs to the relevant SDAP QoS flows according to the filtering rules. In a similar manner to the downlink, in the uplink, multiple PDU Sets can be mapped to the same QoS flow within a single XR session, or several PDU Sets can be mapped to different QoS flows within a single XR session.

[0098] Figure 5 is a block schematic diagram of an exemplary embodiment of the PDCP protocol layer according to 3GPP document TS38.323. The PDCP layer 401 consists of a PDCP transmit entity 502 and a PDCP receive entity 503. In this figure, the two PDCP entities do not belong to the same NG-RAN node. The two PDCP entities are connected by radio communication 504, which represents a simplified view of all lower layers from RLC to PHY. For example, the PDCP transmit entity 502 is located on UE101 and the PDCP receive entity 503 is located on gNB111. However, this disclosure is not limited to this particular example, and the PDCP transmit entity (PDCP transmitter) 502 may be located on gNB111, or the PDCP receive entity (PDCP receiver) 503 may be located on UE101.

[0099] Each NG-RAN node implements both PDCP transmitting and receiving entities, but for simplicity, not all of them are shown in this diagram.

[0100] Each functional block of a PDCP entity is described in detail in 3GPP document TS38.323. Each PDCP entity carries data for one radio bearer. A PDCP entity is associated with either the control plane or the user plane, depending on which radio bearer it carries data for. PDCP entities associated with a DRB / MRB may be configured by an RRC layer (TS38.331, control plane not shown in Figure 4) to use header compression or uplink data compression (UDC) 505. Robust header compression protocol (ROHC), Ethernet header compression protocol (EHC), and UDC are supported. Each header compression protocol is configured independently for the DRB / MRB. Compression 505 is performed by the transmitting entity 502, and decompression 509 is performed by the receiving entity 503.

[0101] The integrity protection function includes both integrity protection 506 and integrity verification 512, and is performed in the PDCP when configured by the RRC. The data units whose integrity is protected are the PDCP PDU header and the data portion of the PDCP PDU before encryption. Integrity protection is always applied to the PDCP data PDU of the SRB (Signaling Radio Bearer). Integrity protection is not applied to the PDCP control PDU.

[0102] The encryption function includes both encryption 507 and decryption 508 and is performed in the PDCP if configured. The data units to be encrypted are MAC-I (1203, 1213, 1223) and, if included in a PDCP SDU (Service Data Unit), the data portion of the PDCP data PDU excluding the SDAP header and SDAP control PDU. Encryption is not applicable to the PDCP control PDU.

[0103] If configured, the PDCP transmitting entity 502 performs buffer sequence numbering 510, as shown in more detail in Figure 9, while the PDCP receiving entity 503 performs reordering and duplicate (duplicate) discarding 511, as shown in more detail in Figure 10.

[0104] Examples of sequence numbering and reordering are given in Figures 6a and 6b.

[0105] Figure 6a is a schematic and simplified diagram of an exemplary message flow illustrating the reordering function of PDCP receiving entities according to 3GPP document TS38.323. It shows the sequence of PDCP PDUs exchanged between a PDCP sending entity 502 (e.g., gNB111) and a PDCP receiving entity 503 (e.g., UE101).

[0106] First, two PDCP PDUs 601 are transmitted sequentially by the PDCP transmitting entity and received sequentially by the PDCP receiving entity. These two PDCP PDUs are delivered to the upper layer (SDAP layer). Subsequently, a third PDCP PDU is transmitted by the PDCP transmitting entity but not received by the PDCP receiving entity. This may be due to a poor radio link condition. Lower layers such as RLC and MAC perform multiple retransmissions of the PDCP PDU 602 if configured. While the lower layers handle the retransmission of the PDCP PDU 602, the PDCP transmitting entity transmits a fourth PDCP PDU 603. The PDCP receiving entity receives the PDCP PDU 603 and detects the missing PDCP PDU 602 because there is a sequence gap between PDCP PDU 601 and PDCP PDU 603. The PDCP receiving entity stores the PDCP PDU 603 and starts the t_ordering timer. PDCP PDU603 is not delivered to the upper layer (SDAP) until PDCP PDU602 is received or the t_ordering timer has elapsed. PDCP PDU604 is sent by the PDCP transmitting entity but not received by the PDCP receiving entity. The PDCP transmitting entity sends PDCP PDU605, which is received by the PDCP receiving entity, and the PDCP receiving entity detects the missing PDCP PDU604 due to a sequence gap between PDCP PDU603 and PDCP PDU605. The PDCP receiving entity stores PDCP PDU605 while the t_ordering timer has already run. PDCP PDU605 is not delivered to the upper layer (SDAP) until PDCP PDU603 is delivered, PDCP PDU604 is received, or it is reinitialized when PDU603 is delivered and the t_ordering timer has elapsed. The PDCP transmitter then sends a set of PDCP PDU606. The PDCP receiving entity stores the PDCP PDU606 while the t_ordering timer is already running.PDCP PDU606 will not be delivered to the upper layer (SDAP) until PDCP PDU605 is delivered. PDCP PDU605 is pending delivery of PDCP PDU603, and will be reinitialized when PDU603 is delivered, after which it will receive PDCP PDU604 or the t_ordering timer will elapse. Reception of a PDCP PDU refers to reception by a PDCP receiving entity, and delivery of a PDCP PDU means delivery to the upper layer (SDAP layer) by a PDCP receiving entity. If a PDU that has already been assigned an SN is to be discarded, the PDCP transmitting entity must signal the discard operation to the remote PDCP receiving entity.

[0107] In this example, PDCP PDUs 601 through 605 are part of PDU Set 1, and PDU 606 is part of PDU Set 2. The identification information of the PDU Sets is known at the transmitting SDAP layer but not at the receiving layer.

[0108] In this example, the delivery of PDU Set2 is delayed until at least PDCP PDU602 and 604 are received by the PDCP receiving entity. In the worst case, if PDCP PDU602 is received but PDCP PDU604 is lost, the delivery of PDU Set2 is delayed for the duration of the t_ordering timer.

[0109] The worst-case scenario is more likely to occur if the PDU Set discard condition is triggered on the sender while PDCP PDUs 602 and 604 have already been sent to the lower layer. In that case, the retransmission of these PDCP PDUs to the lower layer is stopped, and therefore, there is a high probability that they will not be received by the receiving entity.

[0110] Figure 6b is a schematic and simplified diagram of another exemplary message flow illustrating the PDCP receiving entity reordering function according to 3GPP document TS38.323.

[0111] The first set of PDCP PDUs 651 are transmitted sequentially by the PDCP transmitting entity and received sequentially by the PDCP receiving entity. These three PDCP PDUs are delivered to the upper layer (SDAP layer). Three more PDCP PDUs 652 are then transmitted by the PDCP transmitting entity, but due to poor radio link conditions, lower layers such as RLC and MAC perform multiple retransmissions of the PDCP PDUs 652 before they are received by the receiving entity. These multiple retransmissions caused a significant delay 653 between the reception of the first PDCP PDU 615 and the PDCP PDU 652. Almost simultaneously, the PDCP transmitting entity then transmits another PDCP PDU 654 and detects the PDU Set discard condition 655 based on the PDU Set Delay Budget QoS parameter. Due to the retransmission delay 653, the PDU Set delay budget is elapsed. The transmission of PDCP PDU 654 is discarded by subsequent actions of the lower layers due to the PDU Set discard.

[0112] Later, the PDCP transmitting entity begins transmitting PDCP PDU656, which is associated with the second PDU Set. At the receiving entity, PDCP PDU656 is received, and PDCP PDU654 is detected as missing. In fact, there is a sequence number gap between PDCP PDU652 and PDCP PDU656. The PDCP receiving entity stores PDCP PDU656 and starts the t_ordering timer. PDCP PDU656 is not delivered to the upper layer (SDAP) until PDCP PDU654 is received or the t_ordering timer has elapsed.

[0113] Figure 7a is a schematic and simplified diagram of an exemplary message flow illustrating the PDCP receiving entity reordering function according to the first embodiment of the present invention.

[0114] The example shown in Figure 7a can be applied to solve both the problems in Figures 6a and 6b. It shows the sequence of PDCP PDUs exchanged between a PDCP transmitting entity 502 (e.g., gNB111) and a PDCP receiving entity 503 (e.g., UE101).

[0115] First, two PDCP PDU701 are transmitted sequentially by the PDCP transmitting entity and received sequentially by the PDCP receiving entity. These two PDCP PDUs are delivered to the upper layer (SDAP layer). Next, a third PDCP PDU702 is transmitted by the PDCP transmitting entity but not received by the PDCP receiving entity. This may be due to a poor radio link condition. Lower layers such as RLC and MAC, if configured, perform multiple retransmissions of the PDCP PDU702. While the lower layers handle the retransmissions of the PDCP PDU702, the PDCP transmitting entity transmits a fourth PDCP PDU703. The PDCP receiving entity receives the PDCP PDU703 and detects the missing PDCP PDU702 because there is a sequence gap between PDCP PDU701 and PDCP PDU703. The PDCP receiving entity stores the PDCP PDU703 and starts the t_ordering timer. PDCP PDU704 is sent by the PDCP sending entity but not received by the PDCP receiving entity. The PDCP sending entity then sends PDCP PDU705, which is received by the PDCP receiving entity. The PDCP receiving entity detects the missing PDCP PDU704 because there is a sequence gap between PDCP PDU703 and PDCP PDU705. The PDCP receiving entity stores PDCP PDU705 while the t_ordering timer is already running. PDCP PDU701-705 belong to the first PDU Set.

[0116] Next, the PDCP transmitting entity detects PDU Set discard condition 708 based on the "PDU Set Delay Budget" QoS parameter of the first PDU Set. The transmission of PDCP PDU 704 is discarded by subsequent actions of the lower layer due to the discard of the PDU Set.

[0117] The PDCP transmitting entity sends a "PDU Set Keep Indication" 707 to the PDCP receiving entity.

[0118] If the PDCP PDU 706 of the next PDU Set is ready to be sent, the "PDU Set Keep Indication" can be a single bit in the header of the first PDCP PDU of 706 (Figures 12a-12c).

[0119] Additionally, "PDU Set Keep Indication" can be set to a control PDCP PDU (Figure 14) where the FMC (First Missing Count) field is set to the sequence number of the first PDCP PDU (706), and there is no bitmap.

[0120] If the PDCP PDU706 for the next PDU Set is not ready to be transmitted, the "PDU Set Keep Indication" may be a control PDCP PDU (Figure 14) that has an FMC field set to the sequence number of PDCP PDU705 incremented by 1 and does not have a bitmap.

[0121] When a PDCP receiving entity receives a "PDU Set Keep Indication" 707, it may reset the t_ordering timer, discard pending PDCP PDUs 702 and 704, and deliver the received PDCP PDUs 703 and 705 to the upper layer.

[0122] Resetting the t_ordering timer means stopping the timer and setting it back to its initial value.

[0123] PDCP PDU703 and 705 may also be discarded, but since they have already been received, their behavior may depend on some setting of the PDCP receiving entity.

[0124] The “PDU Set Keep Indication” may be transmitted in the PDCP PDU 706 of the first PDCP PDU, depending on whether the “PDU Set Keep Indication Flag” is set in the PDCP transmitter in the example above. “PDU Set Keep Indication” is a term used to refer to an indicator transmitted from the PDCP transmitter to the PDCP receiver, and the function and structure of that indicator are as described in this disclosure. Similarly, “PDU Set Keep Indication Flag” is a term used to refer to an indication flag set in the PDCP transmitter, and the function of that indicator flag is as described in this disclosure.

[0125] Figure 7b is a schematic and simplified diagram of another exemplary message flow illustrating the PDCP receiving entity reordering function according to a second embodiment of the present invention.

[0126] The example shown in Figure 7b can be applied when a PDU Set of PDCP PDUs is interleaved in a PDCP transmitter entity. It shows the sequence of PDCP PDUs exchanged between a PDCP transmitter entity 502 (e.g., gNB111) and a PDCP receiver entity 503 (e.g., UE101).

[0127] First, two PDCP PDUs 751 are transmitted sequentially by the PDCP transmitting entity and received sequentially by the PDCP receiving entity. These two PDCP PDUs are delivered to the upper layer (SDAP layer). Next, a third PDCP PDU 752 is transmitted by the PDCP transmitting entity but is not received by the PDCP receiving entity. This may be due to a poor radio link condition. Lower layers such as RLC and MAC, if configured, perform multiple retransmissions of the PDCP PDU 752. The lower layers handle the retransmission of the PDCP PDU 752, but the PDCP transmitting entity transmits a fourth PDCP PDU 753. The PDCP receiving entity receives the PDCP PDU 753 and detects the missing PDCP PDU 752 because there is a sequence gap between PDCP PDU 751 and PDCP PDU 753. The PDCP receiving entity stores the PDCP PDU 753 and starts the t_ordering timer. PDCP PDU754 is sent by the PDCP transmitting entity but not received by the PDCP receiving entity. The PDCP transmitting entity sends PDCP PDU755, which is received by the PDCP receiving entity, and the PDCP receiving entity detects the missing PDCP PDU754 because there is a sequence gap between PDCP PDU753 and PDCP PDU755. The PDCP receiving entity stores PDCP PDU755 while the t_ordering timer is already running. PDCP PDU751, 752, 754, and 755 belong to the first PDU Set, and PDCP PDU753 belongs to the second PDU Set.

[0128] Next, the PDCP transmitting entity transmits PDCP PDU756, which belongs to the second PDU Set. The PDCP receiving entity receives and stores PDCP PDU756.

[0129] Up until now, the distribution of the second PDU Set has been withholding the reception of PDCP PDU752, which is blocking the distribution of PDCP PDU753.

[0130] Next, the PDCP transmitting entity detects PDU Set discard condition 757 based on the "PDU Set Delay Budget" QoS parameter of the first PDU Set. The transmissions of PDCP PDUs 752 and 754 are discarded by subsequent operations of the lower layer due to the discard of the PDU Set.

[0131] The PDCP transmitting entity sends a "PDU Set Keep Indication" 758 to the PDCP receiving entity.

[0132] Because the two PDU sets are interleaved, the PDCP transmitter cannot send a 1-bit version of the "PDU Set Keep Indication". The first PDCP PDU of the second PDU set is PDCP PDU753, which must be kept, while PDCP PDU754 must be discarded.

[0133] Therefore, if PDCP PDU759 of the next PDU Set is ready to be sent, the "PDU Set Keep Indication" can be a header extension in the header of the first PDCP PDU of PDCP PDU759 (Figures 13a-13c). The FMC field shall be set to the sequence number of PDCP PDU753, and the Bitmap field shall indicate that PDCP PDU754 and 755 should be discarded and PDCP PDU756 should be kept (0, 0, 1, 1, 1). The Bitmap length field shall be set to 5. The FMC field indicates that PDCP PDU753 is the first PDCP PDU to be kept, and therefore the Bitmap field can start from PDCP PDU754.

[0134] Furthermore, the "PDU Set Keep Indication" may be a control PDCP PDU (Figure 14) having an FMC field set to the sequence number of PDCP PDU753, and the Bitmap field shall indicate that PDCP PDU754 and 755 are discarded and PDCP PDU756 is retained (0, 0, 1, 1, 1).

[0135] If the PDCP PDU759 of the next PDU Set is not ready to be sent, the "PDU Set Keep Indication" may be a control PDCP PDU (Figure 14) having an FMC field set to the sequence number of PDCP PDU753, and the Bitmap field shall indicate that PDCP PDU754 and 755 should be discarded and PDCP PDU756 should be kept (0, 0, 1, 1, 1).

[0136] When a PDCP receiving entity receives a "PDU Set Keep Indication" 758, it may reset the t_ordering timer, discard pending PDCP PDUs 752 and 754, and deliver the received PDCP PDUs 753, 755, and 756 to the upper layer.

[0137] PDCP PDU755 can also be discarded, but since it has already been received, its behavior may depend on some setting of the PDCP receiving entity.

[0138] The “PDU Set Keep Indication” may be transmitted by the first PDCP PDU of the PDCP PDU759 depending on whether the “PDU Set Keep Indication Flag” is set in the PDCP transmitter in the example above. “PDU Set Keep Indication” is a term used to refer to an indicator transmitted from the PDCP transmitter to the PDCP receiver, and its function and structure are as described in this disclosure. Similarly, “PDU Set Keep Indication Flag” is a term used to refer to an indicator flag configured within the PDCP transmitter, and its function is as described in this disclosure.

[0139] Figure 8 is a flowchart illustrating an exemplary method performed by a PDCP transmitting entity (PDCP transmitter) to handle PDU discard conditions according to one embodiment of the present invention. The flowchart is performed in the PDCP function “Sequencing of Transmit Buffers” 510 and may be performed by CPU 215 for the UE or by CPU 315 for the gNB.

[0140] In step 801, detect the PDU Set discard condition from at least one of the following conditions: - PDCP PDU (Faulty PDU) PDU discard timer elapsed, -PDU Set discard timer elapsed, - The receiving PDCP entity receives a status report indicating that the PDCP PDU of the first PDCP PDU Set has not been received, and optionally that the RLC layer and MAC layer have not retransmitted this PDU (fault PDU). The initialization of the PDU Set discard timer and the PDU discard timer is explained in Figure 9. The PDU discard timer is started each time the PDCP transmitter receives a new SDU from the upper layer (SDAP). The PDU Set discard timer is started when the PDCP transmitter receives the first SDU of the PDU Set from the upper layer (SDAP). PDCP status reports are described in section 5.4 of 3GPP document 38.323.

[0141] In Test 802, the transmitting PDCP entity can determine if the faulty PDU is part of an XR PDU Set. This information is obtained from the SDAP layer. This test is not performed if a PDU Set discard timer is used.

[0142] If the faulty PDU is not part of the XR PDU Set (no in 802), during step 805, the PDCP transmitting entity handles the faulty PDU as instructed in 3GPP document TS38.323, section 5.3, by discarding the associated PDCP SDU, discarding the PDCP PDU, and notifying the lower layer if the PDCP PDU has already been transmitted. As a result, the lower layer should discard any ongoing transmissions of the faulty PDCP PDU.

[0143] If the faulty PDCP PDU is part of an XR PDU Set, during step 803, the corresponding PDU Set is identified by the SDAP PDU Set's identification information, "PDU Set Sequence Number".

[0144] Next, during test 804, the PSIHI (or PSII) PDU Set QoS parameter is checked. PSIHI (or PSII) stands for PDU Set Handling Integrated Indication (PDU Set Integrated Indication) and is part of the QoS parameters obtained by the SDAP layer when the session is established. PSI and PSIHI refer to the same parameter, and PSIHI will be used for the remainder of this document. If the value of PSIHI is "false" (no in 804), the PDU Set will not be discarded for one faulty PDCP PDU, and therefore only the faulty PDCP PDU will be discarded during step 805.

[0145] When using the PDU Set Destroy Timer, a faulty PDU is not identified, and PSIHI is assumed to be true.

[0146] If PSIHI is true (yes in 804), all PDCP PDUs belonging to the same PDU Set as the faulty PDU (each PDCP PDU belonging to a PDU Set identified by the PDU Set discard timer) shall be discarded during steps 809 and 810. The discarded PDU Sets are identified by the "PDU Set Sequence Number" obtained during step 803.

[0147] During step 809, all PDCP SDUs belonging to the "PDU Set Sequence Number" are discarded. Packets delivered by the SDAP layer are called SDAP PDUs or PDCP SDUs. That is, when the PDCP transmitter 502 associates a sequence number (see block 510 in Figure 5) with a PDCP SDU, the PDCP SDU becomes a PDCP PDU. More generally, a PDCP SDU is converted to a PDCP PDU by applying a layer-specific header to the PDCP SDU.

[0148] During step 810, all PDCP PDUs belonging to the "PDU Set Sequence Number" are discarded.

[0149] During step 809, only SDUs that have already been sent to the PDCP transmitter by the SDAP layer are discarded. Other SDUs belonging to the same "PDU Set Sequence Number" may be sent to the PDCP transmitter by the SDAP layer after step 809. For this purpose, the PDCP transmitting entity sets the PDU Set discard flag associated with the "PDU Set Sequence Number" during step 811.

[0150] Step 812 has different options.

[0151] In the first embodiment, during step 812, the PDCP transmitting entity sends a "PDU Set Keep Indication" to the PDCP receiving entity, rather than within the PDCP PDU itself. In this way, the keep indication is sent earlier than subsequent PDCP PDUs, giving the PDCP receiving entity more time to process past PDCP PDUs. In this embodiment, the "PDU Set Keep Indication" may be formatted as a control PDU, as further described in Figure 14.

[0152] In another embodiment, during step 812, the PDCP transmitting entity sets a “PDU Set Keep Indication flag” so that a “PDU Set Keep Indication” is sent when a PDCP PDU belonging to another PDU Set is ready to be sent (Figure 9). In this way, the “PDU Set Keep Indication” can be inserted into the PDCP data PDU, saving the overhead of sending separate control PDUs. In this embodiment, the “PDU Set Keep Indication” can be formatted as further described in Figures 12a-12c, 13a, 13b, 13c, and 14 (formatting as shown in Figure 14 is possible but offers no advantage).

[0153] The decision regarding the two options for step 812 can be made during operation. For example, if the PDU Set is not interleaved, the PDCP sending entity sets the PDU Set Keep Indication flag so that a "PDU Set Keep Indication" is sent when a PDCP PDU belonging to another PDU Set is ready to be sent. If the PDU Set Keep Indication is sent to the PDCP receiving entity rather than in the PDCP PDU of the application data, the PDU Set Keep Indication flag does not need to be set.

[0154] For all PDCP PDUs discarded during step 810, if some of them have already been sent to a lower layer (RLC) (yes in test 813), the PDCP transmitting entity may notify the lower layer that any ongoing transmissions of the discarded PDCP PDUs should be discarded.

[0155] Figure 9 is a flowchart illustrating an exemplary method performed by a PDCP transmitting entity (PDCP transmitter) for PDU transmission according to an embodiment of the present invention. The flowchart is implemented in the PDCP function “Sequencing of Transmit Buffers” 510 and may be performed by CPU 215 for the UE or by CPU 315 for the gNB. The method in Figure 8 may be triggered when a discard condition is met. The method in Figure 9 may be triggered when a new SDU is provided by the upper layer (SDAP) for transmission to the PDCP receiver. Both methods in Figure 8 and Figure 9 may be performed by the same PDCP transmitter. For example, the method in Figure 8 may set a PDU discard flag or set a PDU Set Keep Indication flag which affects the method in Figure 9. The method in Figure 9 may reset the PDU discard flag or reset the PDU Set Keep Indication flag. Either method in Figure 8 or Figure 9 may result in a PDU Set Keep Indication being transmitted from the PDCP transmitter to the PDCP receiver.

[0156] During step 901, the PDCP transmitting entity receives a PDCP SDU from the upper layer (SDAP), which may be an example of the first piece of information in the application data.

[0157] During step 902, the PDCP transmitting entity may verify with the SDAP layer whether the PDCP SDU belongs to the XR PDU Set.

[0158] If the PDCP SDU does not belong to the XR PDU Set (no in 902), during step 913, the SDU is processed for transmission as instructed in section 5.2.1 of 3GPP document TS38.823.

[0159] If not, and the PDCP SDU of the first received SDU belongs to a given PDU Set (the PDU Set is identified by the "PDU Set Sequence Number") (yes to 903), then the "PDU Set Discard Timer" is started during step 904. The timer's initialization value may be linked to the QoS parameter "PDU Set Delay Budget," or it may be defined by configuration, for example, if the PDCP sending entity is performed by a UE, its value may be set by the gNB via individual signaling (e.g., RRC).

[0160] Alternatively, the PDCP transmitting entity shall set a PDU discard timer for each incoming SDU unless it is configured to use a PDU Set discard timer. For all SDUs belonging to a given PDU Set, the PDU discard timer of the first received SDU shall be linked to the QoS parameter "PDU Set Delay Budget," and all subsequent received SDUs from the same PDU Set shall have their PDU discard timers linked to both the QoS parameter "PDU Set Delay Budget" and the arrival time difference with respect to the first SDU. The initialization value of the PDU discard timer may also be defined by configuration; for example, if the PDCP transmitting entity is run by a UE, its value may be set by the gNB via individual signaling (e.g., RRC).

[0161] Subsequently, during test 905, the PDCP transmitting entity checks if there is a "PDU Set Discard" flag for any PDU Set. If there is no "PDU Set Discard" flag (no in 905), it means that the current transmission is proceeding normally and a "PDU Set Keep Indication" should not be transmitted. Then, during step 913, the SDU is processed for transmission as instructed in section 5.2.1 of 3GPP document TS38.823.

[0162] If at least one "PDU Set Discard" flag is set (yes in 905), then in test 906, the PDCP sending entity checks if the received SDU belongs to a PDU Set that has been flagged to be discarded.

[0163] If the received SDU belongs to a PDU Set that has been flagged to be discarded (yes in 906), the received SDU is discarded during step 907. If the discarded SDU was the last SDU received from a PDU Set that has been flagged to be discarded (yes in 909), the associated "PDU Set Discard" flag is reset.

[0164] If the received SDU does not belong to a PDU Set that has been flagged to be discarded (906 no), the PDCP sending entity checks if the "PDU Set Keep Indication" flag is set. For example, it is set during the method shown in Figure 8.

[0165] If the "PDU Set Keep Indication" flag is not set (no in 908), the SDU is processed for transmission during step 913 as instructed in section 5.2.1 of 3GPP document TS38.823.

[0166] If the "PDU Set Keep Indication" flag is set (yes to 908), during step 911, the PDCP sending entity sends a "PDU Set Keep Indication". The "PDU Set Keep Indication" can be formatted as follows: - One bit of the data PDCP PDU (Figures 12a, 12b, 12c) constructed from the received PDCP SDU, - The PDCP control PDU sent before the data PDCP PDU constructed from the received PDCP SDU (Figure 14), or - Additional headers for the data PDCP PDU constructed from the received PDCP SDU (Figures 13a, 13b, 13c).

[0167] The format of the PDU Set Keep Indication can be determined by the settings of the PDCP transmitter.

[0168] Next, the PDCP SDU (including any modified headers) is processed for transmission, as instructed in section 5.2.1 of 3GPP document TS38.823.

[0169] Figure 10 is a flowchart illustrating an exemplary method performed by a PDCP receiving entity (PDCP receiver) for receiving a PDU according to an embodiment of the present invention. This flowchart may be implemented in the PDCP function "receive buffer: reorder copy discard" 511, and may be executed by CPU 215 for the UE or by CPU 315 for the gNB.

[0170] In step 1001, the PDCP receiving entity receives a PDCP PDU from the lower layer (RLC).

[0171] In step 1002, the PDCP receiving entity calculates the PDCP PDU sequence number as a combination of the PDCP SN header field and the HFN (Hyper Frame Number). See section 5.2.2.1 of 3GPP document TS38.323 for details.

[0172] Next, if configured, in step 1003, the data portion of the PDCP PDU is decoded.

[0173] Next, in test 1004, the integrity of the PDCP PDU is verified. If the integrity check fails (no in 1004), the received PDCP PDU is discarded.

[0174] If the integrity check is passed (1004 yes), but the received PDCP PDU is a copy of a PDCP PDU that has already been delivered (1005 yes), the received PDCP PDU is discarded.

[0175] Otherwise, the received PDCP PDU is stored in a memory buffer during step 1007.

[0176] In test 1008, the header of the received PDCP PDU is checked for a keep indication (KI). If there is no keep indication in the header (no in 1008), the PDCP receiving entity proceeds with the received PDCP PDU during step 1009, as described in section 5.2.2.1 of 3GPP document TS38.323.

[0177] If there is a keep indication in the header (yes in 1008), the PDCP receiving entity shall reset the t_ordering timer in step 1012 if it is running.

[0178] Next, in step 1013, the PDCP receiving entity shall discard all pending PDCP PDUs before the received PDCP PDU.

[0179] Next, in step 1014, the PDCP receiving entity distributes the received PDCP PDU as a PDCP SDU to the upper layer.

[0180] Alternatively, if the header contains more than KI bits (meaning an additional header with FMC (First Missing COUNT) and a bitmap, as shown in Figures 13a-13c), the PDCP receiving entity will reset the t_ordering timer if it is running, and will not indicate that the bitmap field will hold PDUs with a lower sequence number than the FMC field that has not yet been received. Or, in other words, the PDCP receiving entity will reset the t_ordering timer if all PDCP PDUs with keep indications in the bitmap field have already been received and the t_ordering timer is running.

[0181] Next, the receiving PDCP entity discards all pending PDCP PDUs prior to the FMC sequence number that are not configured to be retained in the Bitmap field.

[0182] Next, the PDCP receiving entity recalculates the sequence of previously pending PDUs, taking into account the discarded PDUs reported in the bitmap field. The PDCP receiving entity then delivers the previously pending PDCP PDUs that are not out of order (have sequence numbers less than FMC).

[0183] Figure 11 is a flowchart illustrating an exemplary method performed by a PDCP receiving entity (PDCP receiver) for receiving a PDU Set Keep Indication controlled PDU according to an embodiment of the present invention. This flowchart may be performed in the PDCP function "Receive Buffer: Reorder Copy Discard" 511, and may be performed by CPU 215 for the UE, or by CPU 315 for the gNB.

[0184] In step 1101, the receiving PDCP entity receives a "PDU Set Keep Indication" on the control PDU (Figure 14).

[0185] In step 1102, the PDCP receiving entity resets the t_ordering timer if it is running and the bitmap field does not indicate that it holds a PDU with a sequence number lower than that of the FMC field which has not yet been received. In other words, the PDCP receiving entity resets the t_ordering timer if all PDCP PDUs with keep indications in the bitmap field have already been received and the t_ordering timer is running.

[0186] Next, in step 1103, the PDCP receiving entity shall discard all pending PDCP PDUs prior to the FMC sequence number that are not set to be retained in the Bitmap field. The PDCP receiving entity may discard pending PDUs stored in the memory buffer that are not indicated by the PDU Set Keep Indication.

[0187] Next, in step 1104, the PDCP receiving entity recalculates the sequence of previous pending PDUs, taking into account the discarded PDUs reported in the Bitmap field. The PDCP receiving entity then delivers the previous pending PDCP PDUs that are not out of order (have sequence numbers less than FMC).

[0188] Figure 12a is a block schematic diagram showing a PDCP data PDU for a DRB and MRB having a 12-bit PDCP SN, which is an example of an application data PDU according to an embodiment of the present invention.

[0189] In this embodiment, the PDU Set Keep Indication is implemented by a single bit of information in the header of the PDCP data PDU. The PDCP data PDU is an example of an application data PDU.

[0190] The "PDU Set Keep Indication" is implemented in KI bit 1201 of data PDUs for DRBs and MRBs that have a 12-bit PDCP SN. When the PDU Set Keep Indication is set to "0", no action is expected from the PDCP receiving entity, and when the PDU Set Keep Indication is set to "1", it indicates that the PDCP Sequence Number (PDCP SN) 1202 represents the first PDCP PDU to be retained, and PDUs with lower sequence numbers must be discarded. For example, the first PDCP PDU to be retained is the PDCP PDU contained in this packet, which could be the first PDU in an application data packet.

[0191] Other fields of the PDCP PDU are described in section 6.2.2.2 of 3GPP document TS38.323. The D / C field 1204 must be set to "D" for the data. The Data field 1205 contains either an uncompressed or compressed PDCP SDU. The MAC-I field 1203 carries the message authentication code.

[0192] Figure 12b is an example of an application data PDU according to an embodiment of the present invention, and is a block schematic diagram showing a PDCP data PDU for a DRB and MRB having an 18-bit PDCP SN.

[0193] In this embodiment, the PDU Set Keep Indication is implemented by a single bit of information in the header of the PDCP data PDU. The PDCP data PDU is an example of an application data PDU.

[0194] The "PDU Set Keep Indication" is implemented in KI bit 1211 of data PDUs for DRBs and MRBs with an 18-bit PDCP SN. When the PDU Set Keep Indication is set to "0", no action is expected from the PDCP receiving entity, and when the PDU Set Keep Indication is set to "1", it indicates that PDCP Sequence Number (PDCP SN) 1212 represents the first PDCP PDU to be retained, and PDUs with lower sequence numbers must be discarded. For example, the first PDCP PDU to be retained is the PDCP PDU contained in this packet, which could be the first PDU in an application data packet.

[0195] Other fields of the PDCP PDU are described in section 6.2.2.3 of 3GPP document TS38.323. The D / C field 1214 must be set to "D" for the data. The Data field 1215 contains either an uncompressed or compressed PDCP SDU. The MAC-I field 1213 carries the message authentication code.

[0196] Figure 12c is an example of an application data PDU according to an embodiment of the present invention, and is a block schematic diagram showing a PDCP data PDU for a sidelink DRB for unicast using an 18-bit PDCP SN.

[0197] In this embodiment, the PDU Set Keep Indication is implemented by a single bit of information in the header of the PDCP data PDU. The PDCP data PDU is an example of an application data PDU.

[0198] The PDU Set Keep Indication is implemented in KI bit 1221 of the data PDU for sidelink DRBs for unicast with an 18-bit PDCP SN.

[0199] If the PDU Set Keep Indication is set to "0", no action is expected from the PDCP receiving entity. If the PDU Set Keep Indication is set to "1", it indicates that PDCP Sequence Number (PDCP SN) 1222 represents the first PDCP PDU to be retained, and PDUs with lower sequence numbers must be discarded. For example, the first PDCP PDU to be retained is the PDCP PDU contained in this packet, which could be the first PDU in the application data packet.

[0200] Other fields of the PDCP PDU are described in section 6.2.2.7 of 3GPP document TS38.323. The D / C field 1224 must be set to "D" for data. The Data field 1225 contains either an uncompressed or compressed PDCP SDU. The MAC-I field 1223 carries the message authentication code. The SDU type field 1229 can be IP, non-IP, Ethernet®, Unstructured, or ARP. The KNRP field 1230 is the identity as specified in TS33.536.

[0201] In other words, a PDU Set Keep Indication implemented by a single bit refers to a PDU Set Keep Indication that adds a single bit to the PDU data of the application data in order to minimize overhead.

[0202] Figure 13a is an example of an application data PDU according to an embodiment of the present invention, and is a block schematic diagram showing a PDCP data PDU for a DRB and MRB having a 12-bit PDCP SN.

[0203] In this embodiment, the PDU Set Keep Indication is implemented by a header extension flagged by HE bit 1309. The header extension includes: - The FMC field 1306 is 32 bits wide and contains the COUNT value of the PDCP SDU to be retained. Alternatively, the FMC field 1306 may contain the COUNT value of the first PDCP PDU to be discarded. COUNT is defined in TS38.323, section 6.3.5, as "the COUNT value consists of an HFN and a PDCP SN, where the size of the HFN portion in the bits is equal to 32 minus the length of the PDCP SN." The FMC field is optional and can be replaced by the PDCP SN field 1302, which contains the PDCP sequence number of this PDCP PDU. -The bitmap length field 1307 provides the length of the bitmap field. - The bitmap field 1308 has a variable length. This field indicates which SDUs can be discarded and which SDUs must be retained by the PDCP receiving entity. The bit position of the Nth bit in the bitmap is N, i.e., the bit position of the first bit in the bitmap is 1.

[0204] Other fields of the PDCP PDU are described in section 6.2.2.2 of 3GPP document TS38.323. The D / C field 1304 must be set to "D" for the data. The Data field 1305 contains either an uncompressed or compressed PDCP SDU. The MAC-I field 1303 carries the message authentication code.

[0205] Figure 13b is an example of an application data PDU according to an embodiment of the present invention, and is a block schematic diagram showing a PDCP data PDU for a DRB and MRB having an 18-bit PDCP SN.

[0206] In this embodiment, the PDU Set Keep Indication is implemented by a header extension flagged by HE bit 1319. The header extension includes: - The FMC field 1316 is 32 bits wide and contains the COUNT value of the PDCP SDU to be retained. Alternatively, the FMC field 1306 may contain the COUNT value of the first PDCP PDU to be discarded. COUNT is defined in TS38.323, section 6.3.5, as "the COUNT value consists of an HFN and a PDCP SN, where the size of the HFN portion in the bits is equal to 32 minus the length of the PDCP SN." The FMC field is optional and can be replaced by the PDCP SN field 1312, which contains the PDCP sequence number of this PDCP PDU. -The bitmap length field 1317 provides the length of the bitmap field. - The bitmap field 1318 has a variable length. This field indicates which SDUs can be discarded and which SDUs must be retained by the receiving PDCP entity. The bit position of the Nth bit in the bitmap is N, i.e., the bit position of the first bit in the bitmap is 1.

[0207] Other fields of the PDCP PDU are described in section 6.2.2.3 of 3GPP document TS38.323. The D / C field 1314 must be set to "D" for the data. The Data field 1315 contains either an uncompressed or compressed PDCP SDU. The MAC-I field 1313 carries the message authentication code.

[0208] Figure 13c is an example of an application data PDU according to an embodiment of the present invention, and is a block schematic showing a PDCP data PDU for a sidelink DRB for unicast using an 18-bit PDCP SN.

[0209] In this embodiment, the PDU Set Keep Indication is implemented by a header extension flagged by HE bit 1329. The header extension includes: -FMC field 1326 is 32 bits wide and contains the COUNT value of the PDCP SDU to be retained. Alternatively, FMC field 1306 may contain the COUNT value of the first PDCP PDU to be discarded. COUNT is defined in TS38.323, section 6.3.5, as "the COUNT value consists of an HFN and a PDCP SN, where the size of the HFN portion in the bits is equal to 32 minus the length of the PDCP SN." FMC field 1326 is optional and can be replaced by the PDCP SN field 1322, which contains the PDCP sequence number of this PDCP PDU. -The bitmap length field 1327 provides the length of the bitmap field. - The bitmap field 1328 has a variable length. This field indicates which SDUs can be discarded and which SDUs must be retained by the receiving PDCP entity. The bit position of the Nth bit in the bitmap is N, i.e., the bit position of the first bit in the bitmap is 1.

[0210] Other fields of the PDCP PDU are described in section 6.2.2.7 of 3GPP document TS38.323. The D / C field 1324 must be set to "D" for data. The Data field 1325 contains either an uncompressed or compressed PDCP SDU. The MAC-I field 1323 carries the message authentication code. The SDU type field 1331 can be IP, non-IP, Ethernet®, Unstructured, or ARP. The KNRP field 1530 is the identity as specified in TS33.536.

[0211] Figure 14 is a block schematic diagram showing a PDCP control PDU for PDU Set Keep Indication, which is not an example of an application data PDU according to an embodiment of the present invention.

[0212] In this embodiment, the PDU Set Keep Indication is implemented in the control PDCP PDU as follows: The D / C field 1401 is 1 bit wide and must be set to C for "control".

[0213] The PDU type field 1402 is 3 bits wide and shall be set to "100" for "PDU Set Keep Indication". However, this disclosure is not limited thereto, and other values ​​such as "101", "110", or "111" may be used instead.

[0214] There are 4 reserved bits, 1403 in total.

[0215] The FMC field 1404 is 32 bits wide and contains the COUNT value of the PDCP SDU to be retained. Alternatively, the FMC field may contain the COUNT value of the first PDCP PDU to be discarded. COUNT is defined in section 6.3.5 of TS38.323.

[0216] The COUNT value consists of HFN and PDCP SN. The size of the HFN portion in a bit is equal to 32 minus the length of the PDCP SN.

[0217] The bitmap field 1405 has a variable length. This field indicates which SDUs can be discarded and which SDUs must be retained by the receiving PDCP entity. The bit position of the Nth bit in the bitmap is N, i.e., the bit position of the first bit in the bitmap is 1.

[0218] Without referring to a specific diagram, there are several configuration parameters that can be provided to the PDCP layer. In one example, the configuration is provided to the UE by the gNB via RRC signaling. In another example, the configuration is provided to the gNB and UE via core network signaling. In yet another example, the configuration parameters exist as pre-configurations in the UE and gNB.

[0219] The configuration parameters include at least the following: - Should a PDCP PDU that has been flagged as "no keep" in "PDU Set Keep Indication" be distributed if it has already been received? -Should a PDU Set with the PSIHI QoS parameter set to "true" be discarded when the PDU Set delay budget is exhausted? -Should a PDU Set discard timer be used? - Should we use "PDU Set Keep Indication"? - Is "PDU Set Keep Indication" preferred in the PDCP data PDU, or should it be sent as a PDCP control PDU?

[0220] As described above, the PDCP transmitter sends a PDU Set Keep Indication to the PDCP receiver, and when the PDCP transmitter determines that the PDUs of the first PDU Set of application data have not been fully received by the PDCP receiver, the PDCP receiver is configured to indicate the second PDU of the application data that it should retain.

[0221] The PDU Set Keep Indication may be included in the control PDU, in which case the FMC field of the control PDU may be set to indicate the PDUs to be kept and / or discarded. The Bitmap field of the control PDU may be set to indicate the PDUs to be kept and / or discarded.

[0222] Instead of including the PDU Set Keep Indication in the control PDU, you may include it in the application data PDU. In this case, the FMC field of the application data PDU may be set to indicate the PDUs to be kept and / or discarded. The Bitmap field of the application data PDU may be set to indicate the PDUs to be kept and / or discarded.

[0223] By forming a PDU Set Keep Indication as described above, it is possible to prevent an unnecessary increase in the amount of additional data (overhead) transmitted to the PDCP receiver.

[0224] Although embodiments of the present invention have been described in relation to PDCP PDUs, the present invention is not limited to this type of PDU. The methods of the present invention can be applied to the transmission and reception of arbitrarily ordered PDUs, and in particular, the present invention can be applied to in-sequence PDU transmission on any layer.

[0225] According to embodiments of the present invention, a method for controlling a PDCP transmitter and a PDCP receiver reduces delays in PDCP PDU distribution caused by unreceived previous PDCP PDUs without excessively increasing overhead.

[0226] Further details relating to further embodiments of the present invention are as follows: Liaison statement (R2-2300087, Reply LS on PDU Set Handling (S4aR230035:contact:Ericsson)), SA4 indicates that delivery of PDUs in the order they are received is preferred.

[0227] "In-sequence delivery is preferred, but without the sacrifice of introducing delay in packet delivery to the RTP layer (i.e., latency that can be caused by the lower layers on the receiver side having to buffer and reorder packets before delivery to the RTP layer). Some codecs can take advantage of the fact that packets are delivered (even if out of order) as soon as they are received at the lower layers. The SRTP / RTP receiver can perform reordering as needed."

[0228] As indicated in the previous statement, special care must be taken to avoid introducing excessive delays due to packet reordering.

[0229] In the case of XR, two functions are handled by the PDCP: the discarding of PDU sets in accordance with the RAN2 agreement (R2-2304202, Report on LTE legacy, XR, QoE and MUSIM), and the reordering of PDUs.

[0230] In accordance with the R17 PDCP standard (TS38.323, Packet Data Convergence Protocol (PDCP) specification, (Release 17)), PDU discarding shall be indicated at the lower layer.

[0231] "When the discardTimer for a PDCP SDU expires, or when the successful delivery of the PDCP SDU is confirmed by the PDCP status report, the sending PDCP entity shall discard the PDCP SDU along with the corresponding PDCP data PDU. If the corresponding PDCP data PDU has already been submitted to a lower layer, the discard shall be indicated to the lower layer."

[0232] At the lower layer, discarding PDUs with assigned sequence numbers creates gaps in PDCP sequence numbers at the receiving entity. This issue was recognized in previous releases and left for implementation, as noted in Note (TS38.323, Packet Data Convergence Protocol (PDCP) specification, (Release 17)): "Note: Discarding a PDCP SDU that is already associated with a PDCP SN creates an SN gap in the transmitted PDCP data PDU, which increases the PDCP sorting delay in the receiving PDCP entity. How to minimize the SN gap after discarding the SDU depends on the UE implementation."

[0233] Combining both PDU Set destruction and PDU reordering at the PDCP layer can lead to the following unwanted behaviors: Assuming a PDCP transmitting entity is transmitting PDCP PDUs belonging to a PDU Set, if the PDCP transmitter detects at some point that the PDU Set discard condition is met for the PDU Set currently being transmitted, it must discard the PDUs belonging to that PDU Set. The PDU Set discard condition includes PSIHI and the loss of delay budget or PDUs. At some other point, the PDCP transmitting entity begins transmitting PDCP PDUs belonging to a second PDU Set. At the receiving entity, the delivery of the PDCP PDUs belonging to the second PDU Set to the upper layer may experience an additional delay of up to (1 millisecond to 3 seconds) of the reordering counter value, while waiting for the PDCP PDUs belonging to the first PDU Set that will not be received because they will be discarded. The worst case occurs when the reordering timer starts counting only when the first PDCP PDU of the second PDU Set is received. This means that previously received PDCP PDUs have discontinuous sequence numbers compared to the newly received PDCP PDUs.

[0234] A closer examination of the effects of reordering delay reveals that the RRC standard (TS38.331, Radio Resource Control (RRC) protocol specification, (Release 17)) defines t-ordering counter values ​​as enumerated ms values ​​from 0 to 3000. The RAN2 technical report ([8]TR38.835, NR; Study on XR enhancements for NR, (Release 18)) proposes a target latency of 10ms for video. The meaning of t-ordering values ​​ms1, ms2, ms4, ms5, or ms8 already represents 10% to 80% of the total delay budget.

[0235] This additional delay clearly contradicts the aforementioned SA4 statement (R2-2300087, Reply LS on PDU Set Handling (S4aR230035; contact:Ericsson)) that in-sequence delivery via RAN (UE or gNB) is preferred unless additional delays are introduced. In fact, an additional delay of 1 to 3 milliseconds is unacceptable given the requirement of end-to-end latency on the order of 10 milliseconds (TR38.835, NR; Study on XR enhancements for NR, (Release 18)).

[0236] Leaving uncertainty that can only be managed by such implementation choices makes it difficult to assess whether the critical requirements of XR are being met.

[0237] Proposal 1: RAN2 will explore how to resolve the signal-to-noise gap problem caused by the discarding of PDCPs.

[0238] By knowing the PDU Set boundaries, a PDCP receiver could have implemented an in-sequence delivery procedure per PDU Set, preventing the discarding of one PDU Set from affecting the delivery time of a second PDU Set. However, in-band signaling of PDU Set boundary information represents excessively added overhead, and there is a high risk that discarding a PDU Set will negate the bandwidth saving objective.

[0239] Proposal 2: RAN2 studies how to minimize additional delays caused by in-sequence delivery of PDCP PDUs in the event of PDU Set discarding, while minimizing induced overhead.

[0240] When discarding a PDU that has already been assigned an SN, the PDCP transmitting entity shall signal the discard operation to a remote PDCP receiving entity.

[0241] The actual problem arises when the second PDU Set is being sent, so it is not essential to send a signal immediately when a PDCP is dropped.

[0242] Proposal 3: When discarding a PDU that has already been assigned an SN, the PDCP transmitting entity shall signal the discard operation to the remote PDCP receiving entity when the second PDU Set is transmitted.

[0243] Different PDU sets may be multiplexed in the same DRB. A PDCP receiving entity may have several signal-to-noise gaps, some related to explicit discard actions performed by a remote PDCP transmitting entity, and some related to transmission errors. Discard signaling sent by a remote PDCP transmitting entity allows the PDCP receiving entity to clearly identify existing gaps.

[0244] Proposal 4: PDCP discard signaling should include information about PDUs belonging to different PDU sets.

[0245] Further details relating to and describing further embodiments of the present invention are as follows: In document R2-2313946 (Necessity of PDCP discard notification to receive PDCP entities), the effect of the delay is identified as the t_ordering timer duration. Assuming this timer is typically set to approximately the PDB (PDU delay budget), it is shown that the effect of the delay does not exceed the PDB and is therefore transparent.

[0246] The impact should be measured in relation to the PSDB (PDU Set Delay Budget), not the PDB. XR users are affected when PDU Sets are delivered outside the PSDB window. It is possible for each PDU to reach the PSDB window while respecting its individual PDB. According to the Stage 2 specification of 3GPP document TS38.300 (v18.0.0.0), the PSDB replaces the PDB: As defined in PSDB:TS23.501 (e.g., TR38.835, NR; Study on XR enhancements for NR, (Release 18)), the upper limit of the duration between the time the first PDU is received (in the UPF for download (DL), in the UE for upload (UL)) and the time all PDUs in a PDU Set are successfully received (in the UE for DL, in the UPF for UL). A QoS flow is associated with only one PSDB, which, if available, applies to both DL and upload UL and supersedes the PDB for the QoS flow.

[0247] Observation 1: The effect of the t_ordering timer should be measured against the PSDB, not the PDB.

[0248] Looking more closely at the impact of reordering delay in the RRC specification (TS38.331, Radio Resource Control (RRC) protocol specification, (Release 17)), the t-ordering counter value is defined as containing an enumerated ms value from 0 to 3000. The RAN2 technical report (TR38.835, NR; Study on XR enhancements for NR, (Release 18)) proposes a target latency of 10 ms for video. The meaning of t-ordering values ​​ms1, ms2, ms4, ms5, or ms8 already represents 10% to 80% of the total PSDB.

[0249] This additional delay contradicts the SA4 statement (R2-2300087, Reply LS on PDU Set Handling (S4aR230035)), which previously states that in-sequence delivery by RAN (UE or gNB) is preferred unless an additional delay is introduced. In fact, an additional delay of 1 to 3 milliseconds is unacceptable given the end-to-end latency requirement of the order of 10 milliseconds (TR38.835, NR; Study on XR enhancements for NR, (Release 18)).

[0250] Observation 2: Under stringent latency requirements, the impact of the t_ordering timer on the PSDB is unacceptable.

[0251] Furthermore, PDU Set interleaving can occur when PDUs from different PDU Sets are multiplexed into a single DRB, typically different slices with common QoS requirements. When PDUs from different PDU Sets are multiplexed, one t_ordering timer on one PDU from one PDU Set blocks the other PDU from the second PDU Set.

[0252] Assuming a PDCP transmitting entity is transmitting PDCP PDUs belonging to a PDU Set, the PDCP transmitter will discard PDUs belonging to a PDU Set if it detects at some point that the PDU Set discard conditions are met for the PDU Set currently being transmitted. PDU Set discard conditions include PSIHI and loss of delay budget or PDUs. At some other point, the PDCP transmitting entity begins transmitting PDCP PDUs belonging to a second PDU Set. While the receiving entity waits for PDCP PDUs belonging to the first PDU Set that are not received due to being discarded, the delivery of PDCP PDUs belonging to the second PDU Set to higher layers may experience an additional delay in the value of the reordering counter (from 1 millisecond to a maximum of 3 seconds). The worst-case scenario occurs when the reordering timer starts counting upon reception of the first PDCP PDU of the second PDU Set, i.e., when previously received PDCP PDUs have discontinuous sequence numbers compared to this first PDCP PDU of the second PDU Set.

[0253] Observation 3: The impact is even worse when PDU sets are duplicated.

[0254] A second alternative concept is conceivable: signaling discarded PDUs in a new PDCP control message similar to the PDCP status report.

[0255] While the present invention has been described with reference to examples and embodiments, it should be understood that the present invention is not limited to the disclosed examples and embodiments. It will be understood by those skilled in the art that various changes and modifications can be made without departing from the scope of the invention, as defined in the appended claims. All features disclosed herein (including any appended claims, abstract, and drawings) and / or all steps of any method or process disclosed herein may be combined in any combination, except for any combination in which at least some of such features and / or steps are mutually exclusive. Each feature disclosed in the specification (including any appended claims, abstract, and drawings) may be replaced by an alternative feature serving the same, equivalent, or similar purpose unless otherwise expressly stated. Thus, unless specifically stated otherwise, each feature disclosed is merely an example of a general set of equivalent or similar functions.

[0256] In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude the plural. The mere fact that different features are described in different dependent claims does not imply that combinations of these features cannot be used advantageously.

[0257] In the embodiments described above, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on or transmitted through a computer-readable medium and executed by a hardware-based processing unit.

[0258] Computer-readable media may include computer-readable storage media corresponding to tangible media such as data storage media, or communication media including any media that facilitates the transfer of computer programs from one location to another according to a communication protocol, for example. Thus, computer-readable media may generally correspond to (1) non-transient tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the techniques described herein. Computer program products may include computer-readable media.

[0259] As an example, and not an limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory, or any other media that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer. Also, any connection is appropriately called computer-readable media. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave may be included in the definition of media. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other temporary media, but instead refer to non-temporary tangible storage media. The discs and discs used herein include compact discs (CDs), laser discs, optical discs, digital multipurpose discs (DVDs), floppy disks, and Blu-ray discs, where discs typically reproduce data magnetically, and discs reproduce data optically using a laser. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. A method for controlling a package data convergence protocol (PDCP) in a communication network including a transmitter (502) and a receiver (503), wherein in the transmitter (502): Transmitting a protocol data unit (PDU) of the application data to the receiver (503), and determining that the first PDU Set of the PDU of the application data has not been fully received by the receiver (503), The receiver (503) transmits a PDU Set Keep Indication to the receiver (503) indicating one or more second PDUs of the application data PDU that the receiver (503) should hold. A method wherein the one or more second PDUs do not belong to the first PDU Set.

2. The method according to claim 1, wherein the PDU Set Keep Indication is transmitted separately from the PDU of the application data.

3. The method according to claim 1, wherein the PDU Set Keep Indication is inserted into the second PDU of the one or more second PDUs of the application data, and the one or more second PDUs belong to the second PDU Set.

4. The method according to claim 2, wherein the PDU Set Keep Indication is included in the control PDU.

5. The method according to claim 3, wherein the PDU Set Keep Indication is a bit in the second PDU or an addition to the header of the second PDU.

6. The method according to any one of claims 1 to 5, further comprising setting a PDU Set Keep Indication flag to indicate when the second PDU of the one or more second PDUs is ready to be transmitted to the receiver, with respect to a PDCP function implemented in the transmitter for transmitting the PDU Set Keep Indication.

7. The method according to any one of claims 1 to 6, further comprising setting a PDU Set Discard flag to instruct a PDCP function implemented in the transmitter to discard data units received from higher layers of the application data belonging to the first PDU Set.

8. The method according to claim 7, further comprising notifying the lower layer to discard any ongoing transmissions of the first PDU when the received data unit of the application data belonging to the first PDU Set has been transmitted to a lower layer by the PDCP function.

9. The method according to any one of claims 1 to 8, further comprising initializing a discard timer in response to receiving a Service Data Unit (SDU) from a higher layer in the PDCP function implemented in the transmitter, wherein the determination that the first PDU Set has not been fully received by the receiver includes determining that the discard timer has expired without receiving an acknowledgment of receipt of the first PDU Set from the receiver.

10. The method according to claim 9, wherein the discard timer is a PDU discard timer that is started when the SDU is received from the upper layer, or a PDU Set discard timer that is started when the first SDU of a PDU Set is received.

11. The method according to any one of claims 1 to 8, wherein determining that the first PDU Set has not been fully received includes receiving a report from the receiver indicating that the first PDU Set has not been fully received.

12. The method according to any one of claims 1 to 11, further comprising determining the QoS parameters of the PDU Set for the first PDU Set, wherein the PDU Set Keep Indication is transmitted to the PDCP receiver only when the values ​​of the parameters of the PSIHI are set to predetermined values.

13. The method according to any one of claims 1 to 12, wherein the PDU Set sequence number of the first PDU Set is used to identify the first PDU.

14. The method according to any one of claims 1 to 13, further comprising determining whether the first PDU Set is part of an Extended Reality (XR) PDU Set, wherein the PDU Set Keep Indication is transmitted to the PDCP receiver only if the first PDU Set is an XR PDU Set set.

15. A method for controlling a package data convergence protocol (PDCP) in a communication network including a transmitter (502) and a receiver (503), wherein in the receiver (503): The transmitter (502) receives a protocol data unit (PDU) of application data, The received PDU is stored in a memory buffer (225, 325), A PDU Set Keep Indication, which indicates one or more PDUs to be held by the receiver (503), is received from the transmitter (502), Discard one or more pending PDUs stored in the memory buffers (225, 325) that are not indicated by the PDU Set Keep Indication, A method of having.

16. The method according to claim 15, further comprising initializing a reordering timer when an out-of-order PDU is received, and resetting the reordering timer after receiving the PDU Set Keep Indication.

17. The method according to claim 15 or 16, wherein receiving the PDU Set Keep Indication comprises checking the header of the PDU received for the PDU Set Keep Indication.

18. The method according to claim 15 or 16, wherein receiving the PDU Set Keep Indication means receiving the PDU Set Keep Indication separately from the PDU of the application data.

19. The method according to any one of claims 15 to 18, wherein discarding the one or more pending PDUs comprises discarding one or more pending PDUs received prior to the PDU Set Keep Indication.

20. The method according to any one of claims 15 to 19, further comprising distributing the stored PDU to a higher layer based on the PDU Set Keep Indication by a PDCP function implemented in the receiver.

21. The method according to any one of claims 1 to 20, wherein the transmitter is a PDCP transmitter and the receiver is a PDCP receiver.

22. A transmitter (502) configured to perform the method described in any one of claims 1 to 14.

23. A receiver (503) configured to perform the method described in any one of claims 15 to 20.

24. A computer program comprising, when the computer program is executed by a transmitter (502), an instruction causing the transmitter (502) to perform the method described in any one of claims 1 to 14, or when the computer program is executed by a receiver (503), an instruction causing the receiver (503) to perform the method described in any one of claims 15 to 20.

25. A computer-readable medium for transporting the computer program described in claim 24.

Images