User equipment, base station, circuitry, method and transmission circuitry

Abstract

The disclosure pertains to a user equipment for mobile telecommunications, wherein the user equipment includes circuitry that is configured to receive, from a transmission node, a data unit that includes at least one segment; and transmit, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing.

Description

[0001] Our ref.: 240508EPWOP 1

[0002] Sony Group Corporation

[0003] USER EQUIPMENT, BASE STATION, CIRCUITRY, METHOD AND TRANSMISSION CIRCUITRY TECHNICAL FIELD

[0004] The present disclosure generally pertains to a user equipment, a base station, circuitry, a method and transmission circuitry.

[0005] TECHNICAL BACKGROUND

[0006] Several generations of mobile telecommunications systems are known, e.g., the third generation (3G), which is based on the International Mobile Telecommunications-2000 (IMT-2000) specifications, the fourth generation (4G), which provides capabilities as defined in the International Mobile Telecommunications- Advanced Standard (IMT-Advanced Standard), the current fifth generation (5G), which has recently been put into practice and which is still being developed further, and the sixth generation (6G), which is planned to be a successor of 5G. A wireless communication technology that provides the requirements of 5G is termed New Radio (NR) Access Technology. Some aspect of NR is based on Long Term Evolution (LTE) technology, which is a wireless communications technology allowing high-speed data communications for mobile phones and data terminals, and which is already used for 4G mobile telecommunications systems. LTE and NR are standardized under the control of 3GPP (3rd Generation Partnership Project).

[0007] Additionally, support for extended reality (XR) services in 5G NR was specified.

[0008] Although there exist techniques for NR, it is generally desirable to provide an improved user equipment, an improved base station, improved circuitry, an improved method and improved transmission circuitry.

[0009] SUMMARY

[0010] According to a first aspect, the disclosure provides a user equipment for mobile telecommunications, wherein the user equipment includes circuitry that is configured to: receive, from a transmission node, a data unit that includes at least one segment; and transmit, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing. According to a second aspect, the disclosure provides a base station for mobile telecommunications, wherein the base station includes circuitry that is configured to: receive,Our ref. : 240508EPWOP 2

[0011] Sony Group Corporation

[0012] from a transmission node, a data unit that includes at least one segment; and transmit, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing. According to a third aspect, the disclosure provides circuitry for mobile telecommunications that is configured to: receive, from a transmission node, a data unit that includes at least one segment; and transmit, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing.

[0013] According to a fourth aspect, the disclosure provides a method for mobile telecommunications, wherein the method includes: receiving, from a transmission node, a data unit that includes at least one segment; and transmitting, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing.

[0014] According to a fifth aspect, the disclosure provides a user equipment for mobile telecommunications, wherein the user equipment includes transmission circuitry that is configured to communicate with a reception node; wherein the reception node includes circuitry according to the third aspect; wherein the communicating with the reception node includes: transmitting the data unit to the reception node; receiving, from the reception node, the indication that retransmission of the segment of the data unit is ongoing; and triggering a further retransmission of the segment based on the indication.

[0015] According to a sixth aspect, the disclosure provides a base station for mobile telecommunications, wherein the base station includes transmission circuitry that is configured to communicate with a reception node; wherein the reception node includes circuitry according to the third aspect; wherein the communicating with the reception node includes: transmitting the data unit to the reception node; receiving, from the reception node, the indication that retransmission of the segment of the data unit is ongoing; and triggering a further retransmission of the segment based on the indication.

[0016] According to a seventh aspect, the disclosure provides transmission circuitry for mobile telecommunications, wherein the transmission circuitry is configured to communicate with a reception node; wherein the reception node includes circuitry according to the third aspect; wherein the communicating with the reception node includes: transmitting the data unit to the reception node; receiving, from the reception node, the indication that retransmission of the segment of the data unit is ongoing; and triggering a further retransmission of the segment based on the indication.

[0017] According to an eighth aspect, the disclosure provides a method for mobile telecommunications, wherein the method includes communicating with a reception node; wherein the reception nodeOur ref. : 240508EPWOP 3

[0018] Sony Group Corporation

[0019] includes circuitry according to the third aspect; wherein the communicating with the reception node includes: transmitting the data unit to the reception node; receiving, from the reception node, the indication that retransmission of the segment of the data unit is ongoing; and triggering a further retransmission of the segment based on the indication.

[0020] Further aspects are set forth in the dependent claims, the drawings and the following description.

[0021] BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Embodiments are explained by way of example with respect to the accompanying drawings, in which:

[0023] Fig 1 illustrates an example of PDUs;

[0024] Fig. 2 illustrates examples of 5GNRRLC AMD PDU formats;

[0025] Fig. 3 illustrates an example of a STATUS PDU when no SDU segment is lost;

[0026] Fig. 4 illustrates an example of a STATUS PDU when contiguous segments are lost;

[0027] Fig. 5 illustrates an example of a STATUS PDU when multiple complete SDUs are lost;

[0028] Fig. 6 illustrates an example of a STATUS PDU when segments of multiple SDUs are lost; Fig. 7 illustrates an example of a STATUS PDU when contiguous segments across multiple SDUs are lost;

[0029] Fig. 8 illustrates an embodiment of a mobile telecommunications network;

[0030] Fig. 9 illustrates a first embodiment of a method;

[0031] Fig. 10 illustrates a second embodiment of a method;

[0032] Fig. 11 illustrates an embodiment of a STATUS report that indicates a premature NACK status; Fig. 12 illustrates a first embodiment of a STATUS report that indicates an UNKNOWN status; Fig. 13 illustrates a second embodiment of a STATUS report that indicates an UNKNOWN status;

[0033] Fig. 14 illustrates an embodiment of a STATUS report in which a CPT field is set to a value different from zero;

[0034] Fig. 15 illustrates an embodiment of a STATUS report in which a reserved bit is set that is associated with an ACK_SN;

[0035] Fig. 16 illustrates a third embodiment of a method;Our ref. : 240508EPWOP 4

[0036] Sony Group Corporation

[0037] Fig. 17 illustrates a fourth embodiment of a method;

[0038] Fig. 18 illustrates a user equipment and a base station according to an embodiment; and Fig. 19 illustrates an embodiment of a general -purpose computer.

[0039] DETAILED DESCRIPTION OF EMBODIMENTS

[0040] Before a detailed description of the embodiments under reference of Fig. 8 is given, general explanations are made.

[0041] As mentioned in the outset, several generations of mobile telecommunications systems are known, e.g., the third generation (3G), which is based on the International Mobile Telecommunications-2000 (IMT-2000) specifications, the fourth generation (4G), which provides capabilities as defined in the International Mobile Telecommunications-Advanced Standard (IMT -Advanced Standard), the current fifth generation (5G), which has recently been put into practice and which is still being developed further, and the sixth generation (6G), which is planned to be a successor of 5G.

[0042] A wireless communication technology that provides the requirements of 5G is termed New Radio (NR) Access Technology. Some aspect of NR is based on Long Term Evolution (LTE) technology, which is a wireless communications technology allowing high-speed data communications for mobile phones and data terminals, and which is already used for 4G mobile telecommunications systems. LTE and NR are standardized under the control of 3GPP (3rd Generation Partnership Project).

[0043] Additionally, support for extended reality (XR) services in 5GNR was specified. XR may be used as an umbrella term that may include virtual reality (VR), augmented reality (AR) and / or mixed reality (MR). VR may refer to a rendered version of a delivered visual and / or audio scene. AR may refer to providing a user with additional information and / or artificially generated items or content, wherein the additional information and / or artificially generated items or content may be overlaid upon the user’s current environment. MR may refer to an advanced form of AR where one or more virtual elements may be inserted into a physical scene with the intent to provide the illusion that these one or more elements are part of the real scene.

[0044] In 3GPP Release 18 (Rel-18), XR (extended Reality) was specified in NR, where the functionalities for the support of extended Reality (XR) services require high data rate and low latency communications. An overview of XR services is available in TR 38.835, while the service requirements are documented in TS 22.261.Our ref.: 240508EPWOP 5

[0045] Sony Group Corporation

[0046] From a Radio Access Network (RAN) perspective, some of the challenges related to XR that were addressed in Rel-18 are the following (as described in TS 38.300 V18.0.0, section 16.15). Regarding Power Saving, it was noted that most XR video frame rates (15, 30, 45, 60, 72, 90 and 120 fps) correspond to periodicities that are not an integer (66.66, 33.33, 22.22, 16.66, 13.88, 11.11 and 8.33 ms respectively). The gNB may configure a DRX cycle expressed in rational numbers so that the DRX cycle matches those periodicities, e.g. for the traffic with a frame rate of 60 fps, the network may configure the UE with a DRX cycle of 50 / 3 ms. Configured grants may be configured without the need for the UE to monitor possible UL retransmissions (i.e., HARQ Retransmission-less) thus increasing the number of power saving opportunities for the UE.

[0047] Regarding Capacity enhancements, the following enhancements for configured grant-based PUSCH transmission are introduced:

[0048] • Support of multiple CG PUSCH transmission occasions within a single period of a CG configuration;

[0049] • Indication of unused CG PUSCH occasion(s) of a CG configuration with Uplink Control Information multiplexed in CG PUSCH transmission of the CG configuration.

[0050] Regarding discarding outdated packets, in the uplink, the UE may be configured with PDU Set based discard operation for a specific DRB. When configured, the UE discards all packets in a PDU set when one PDU belonging to this PDU set is discarded due to discard timer expiry. Further, regarding a Delay Status Report (DSR) of buffered data, a delay status reporting (DSR) to the gNB scheduler was specified, such that the gNB may know the time remaining for the data in the UE buffer. The DSR is carried via a dedicated MAC CE.

[0051] A DSR is triggered for a Logical Channel Group (LCG) when the remaining time “before discarding” of any buffered Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) goes below a configured threshold (threshold configured per LCG by the gNB).

[0052] When a DSR is triggered for an LCG, it reports the amount of data buffered with a remaining time “before discard” below the configured threshold, together with the shortest remaining time of any PDCP SDU buffered.

[0053] Based on the DSR, the gNB scheduler becomes aware of the existence of critical data with low remaining time and gNB can schedule to the UE by sending a large UL grant.Our ref. : 240508EPWOP 6

[0054] Sony Group Corporation

[0055] In 3GPP Release 19 (Rel-19), a new work item (WI) was agreed for NR XR Phase 3 (Ph3). The Rel-19 XR Ph3 objectives are as follows:

[0056] • Specify support for multimodality in RAN for UL and DL [RAN3],

[0057] • Specify enhancements to enable transmission / reception in gaps / restrictions that are caused by RRM measurements (from inter-frequency RRM measurement gaps, or intrafrequency measurements, or other scheduling restrictions etc). [RANI, RAN2, RAN4] o Specify the corresponding measurement gap and scheduling restriction to enable the identified enhancements with RRM performance impact taken into consideration, work being triggered by LS. [RAN4]

[0058] • Specify Enhancements for support of UL scheduling to enable high XR capacity while meeting delay requirements / avoiding too late PDUs, as follows [RAN2]

[0059] o Specify additional Logical Channel priority handling using delay / deadline information of packets.

[0060] o Specify enhanced DSR (Delay Status Report) reporting with multiple pairs of remaining time and buffer size for an LCG.

[0061] • Specify the following user plane enhancements [RAN2]:

[0062] o RLC re-transmission related enhancements for operation of RLC Acknowledged Mode (AM) with small packet delay budget.

[0063] • Extend Release 18 standalone mechanism to support NR-NR dual connectivity as follows [RAN3]:

[0064] o PDU set based handling

[0065] o ECN marking

[0066] o Burst Arrival Time reporting, if needed

[0067] o PSI Discard coordination, if needed

[0068] • Specify uplink congestion signalling [RAN2]:

[0069] o Specify in MAC layer XR rate control signalling over downlink per QoS flow / per DRB to enable faster source rate adaption to uplink congestion.

[0070] • Specify Core requirements related to the above objectives as necessary [RAN4],Our ref. : 240508EPWOP 7

[0071] Sony Group Corporation

[0072] Based on the WI justification, RLC-AM may be useful to limit data loss, however RLC-AM feedback or retransmission triggering mechanisms may be not well adapted for short packet delay budgets applicable to XR traffic. Also, for RLC AM, considerable amounts of data may be in-flight, i.e. in the window, and there is no mechanism to reduce the delay gap between the initial Automatic Repeat Request (ARQ) transmission and the re-transmission of the RLC PDU in some instances.

[0073] In the following, the RLC (Radio Link Control) Acknowledged Mode (AM) is described, which is defined in TS 38.322 V18.1.0.

[0074] An RLC PDU (Protocol Data Unit) consists of an RLC header and data. From an upper (protocol) layer, RLC receives an RLC SDU (Service Data Unit). The data part of an RLC PDU is either a complete RLC SDU or an SDU segment. If there is a single RLC PDU, it maps to a single Media Access Control (MAC) SDU.

[0075] RLC has three transmission modes: transparent mode (TM), unacknowledged mode (UM) and acknowledged mode (AM). Each mode has its own data PDU formats. Further, a STATUS PDU is an RLC control PDU sent as part of AM RLC entity, and has its own format.

[0076] In some instances, every RLC SDU that comes from an upper layer is byte aligned, i.e., includes a multiple of 8 bits. A first bit of an RLC SDU becomes a first bit of an RLC PDU. UM data (UMD) and AM data (AMD) headers are byte aligned, but not the STATUS PDU header.

[0077] In some instances, NR RLC supports SDU segmentation but not concatenation. This means that an RLC SDU can be sent as multiple segments, each segment going in a separate RLC PDU. But a single RLC PDU cannot carry multiple SDUs or segments of multiple SDUs.

[0078] In some instances, the standards do not specify a value for a segment size. If the grant is big enough, an entire SDU shall go in a single PDU. Otherwise, the SDU shall be segmented, with RLC maximizing the segment size given the grant.

[0079] Fig. 1 illustrates an example of Protocol Data Units (PDUs). The PDUs carry three IP Packets 11, 12 and 13 with sequence numbers n, n+1 and m, respectively.

[0080] A Service Data Adaptation Protocol (SDAP) PDU 1 la in an SDAP layer includes a header (indicated as H in Fig. 1) and an SDAP SDU that corresponds to the IP Packet 11. A Packet Data Convergence Protocol (PDCP) PDU 1 lb in a PDCP layer includes a header and a PDCP SDU that corresponds to the SDAP PDU 1 la. An RLC PDU 11c in an RLC layer includes a header and an RLC SDU that corresponds to the PDCP PDU 11b.Our ref. : 240508EPWOP 8

[0081] Sony Group Corporation

[0082] Similarly, an SDAP PDU 12a in the SDAP layer includes a header and an SDAP SDU that corresponds to the IP Packet 12. A PDCP PDU 12b in the PDCP layer includes a header and a PDCP SDU that corresponds to the SDAP PDU 12a. An RLC PDU 12c in the RLC layer includes a header and an RLC SDU that corresponds to the PDCP PDU 12b.

[0083] Further, an SDAP PDU 13a in the SDAP layer includes a header and an SDAP SDU that corresponds to the IP Packet 13. A PDCP PDU 13b in the PDCP layer includes a header and a PDCP SDU that corresponds to the SDAP PDU 13a. The PDCP PDU 13b is segmented into two RLC PDUs 13c and 13d in the RLC layer. The RLC PDU 13c includes a header and an SDU segment that corresponds to a first portion of the PDCP PDU 13b. The RLC PDU 13d includes a header and an SDU segment that corresponds to a second portion of the PDCP PDU 13b.

[0084] The SDAP PDU Ila, the PDCP PDU 1 lb, the RLC PDU 11c, the SDAP PDU 12a, the PDCP PDU 12b and the RLC PDU 12c are included in a same radio bearer 14, RBX. The SDAP PDU 13a, the PDCP PDU 13b, the RLC PDU 13c and the RLC PDU 13d are included in a same radio bearer 15, RBy.

[0085] A MAC PDU 16 in a MAC layer includes, as one transport block, a header, the RLC PDU 11c, a further header, the RLC PDU 12c, a further header and the RLC PDU 13c. The RLC PDU 13d is included in a separate MAC PDU 17, which includes a header and a MAC SDU that corresponds to the RLC PDU 13d.

[0086] Thus, the RLC PDUs 11c and 12c each include an entire RLC SDU, whereas the RLC PDUs 13c and 13d each include segments of an RLC SDU. Accordingly, an RLC PDU includes a header and an RLC SDU or a segment of an RLC SDU.

[0087] In RLC, an AMD PDU may include the following parameters and / or fields.

[0088] An RLC AMD PDU may include a Data / Control (D / C) field, which may be a 1 -bit field. A value of 0 may indicate a control PDU and a value of 1 may indicate a data PDU. In some instances, this is necessary since an AM RLC entity may have both data and control PDUs.

[0089] An RLC AMD PDU may include a Polling bit (P). It may be set by a transmitting side to 1 if requesting a STATUS report from its peer entity.

[0090] An RLC AMD PDU may include Segmentation Information (SI), which may indicate whether the PDU contains a complete SDU or a first / last / middle segment of an SDU. The SI may have a length of 2 bit, wherein a value of SI=00 may indicate that the SI includes complete SDU, a value of SI=01 may indicate that the SI includes a first segment of an SDU, a value of SI= 10Our ref.: 240508EPWOP 9

[0091] Sony Group Corporation

[0092] may indicate that the SI includes a last segment of an SDU, and a value of SI=11 may indicate that the SI includes a middle segment of an SDU.

[0093] An RLC AMD PDU may include a Segment Offset (SO), which may indicate a position of a current segment (e.g., of an SDU segment included in the PDU) in bytes within the original RLC SDU. Numbering may start from zero and the SO may have a length of 16 bit.

[0094] An RLC AMD PDU may include a Sequence Number (SN), which may indicate a sequence number of the corresponding SDU. It is noted that the numbering refers to SDUs, not to their segments. A length of the SN may be configured by Radio Resource Control (RRC) and may be 12 or 18 bits for an AMD PDU, without limiting the disclosure to these values.

[0095] A complete SDU may be sent in a single RLC PDU by setting SI=00. Even so, an AMD PDU may always include an SN field, which may be necessary for an ARQ retransmission procedure in some instances.

[0096] Fig. 2 illustrates examples of 5GNR RLC AMD PDU formats.

[0097] A PDU 21 includes a 12-bit Sequence Number (SN) and no Segmentation Information (SO). A first octet of the PDU 21 includes a Data / Control (D / C) bit 21a, a Polling (P) bit 21b, and two bits of Segmentation Information (SI) 21c. The PDU 21 further includes a 12-bit SN 2 Id, wherein four bits of the SN 21d are included in the first octet, and eight bits of the SN 21d are included in a second octet of the PDU 21. A third to N-th octet of the PDU 21 include data 21e. A PDU 22 includes an 18-bit SN and no SO. A first octet of the PDU 22 includes a D / C bit 22a, a P bit 22b, two bits of SI 22c, as well as two reserved (R) bits 22d and 22e. The PDU 22 includes an 18-bit SN 22f, wherein four bits of the SN 22f are included in the first octet, eight bits of the SN 22f are included in a second octet of the PDU 22, and eight bits of the SN 22f are included in a third octet of the PDU 22. A fourth to N-th octet of the PDU 22 include data 22g. A PDU 23 includes a 12-bit SN and SO. A first octet of the PDU 23 includes a D / C bit 23a, a P bit 23b, and two bits of SI 23c. The PDU 23 further includes a 12-bit SN 23d, wherein four bits of the SN 23 d are included in the first octet, and eight bits of the SN 23 d are included in a second octet of the PDU 23. A third and fourth octet of the PDU 23 include a SO 23e. A fifth to N-th octet of the PDU 23 include data 23 f.

[0098] A PDU 24 includes an 18-bit SN and SO. A first octet of the PDU 24 includes a D / C bit 24a, a P bit 24b, two bits of SI 24c, as well as two R bits 24d and 24e. The PDU 24 includes an 18-bit SN 24f, wherein four bits of the SN 24f are included in the first octet, eight bits of the SN 24f are included in a second octet of the PDU 24, and eight bits of the SN 24f are included in a thirdOur ref.: 240508EPWOP 10

[0099] Sony Group Corporation

[0100] octet of the PDU 24. A fourth and fifth octet of the PDU 24 include a SO 24g. A sixth to N-th octet of the PDU 24 include data 24h.

[0101] The RLC protocol may further specify a STATUS PDU with extension bits. The STATUS PDU may be a control PDU that is applicable only to an AM RLC entity in some instances. A header of the STATUS PDU may include a 1 -bit Data / Control (D / C) field and a 3 -bit Control PDU Type (CPT) field. The STATUS PDU may be indicated with D / C=0 and CPT=000 (other values of CPT, i.e., 001 to 111 are reserved in some instances).

[0102] Following the header, the STATUS PDU may include an Acknowledgement Sequence Number (ACK_SN), a Negative Acknowledgement Sequence Number (NACK_SN), extension bits (El, E2, E3), SOstart, SOend, and NACK Range. ACK SN and El are mandatory for every STATUS PDU in some embodiments, and other fields may be used only when there is a need to indicate incorrectly received RLC SDUs and segments.

[0103] ACK_SN and NACK_SN may have a length of 12 or 18 bit, as configured by RRC. SOstart and SOend may occupy 16 bit. The NACK Range field may have a length of 8 bits.

[0104] The ACK SN field may indicate a SN of a next not received RLC SDU which is not reported as missing in the STATUS PDU (e.g., the ACK_SN may correspond to a SN which a receiving side expects for a next SDU). When a transmitting side of an AM RLC entity receives a STATUS PDU, it may interpret that all RLC SDUs up to but not including the RLC SDU with SN=ACK_SN have been received by its peer AM RLC entity (e.g., by the receiving side), excluding those RLC SDUs indicated in the STATUS PDU with NACK SN, portions of RLC SDUs indicated in the STATUS PDU with NACK SN, SOstart and SOend, RLC SDUs indicated in the STATUS PDU with NACK SN and NACK Range, and portions of RLC SDUs indicated in the STATUS PDU with NACK_SN, NACK_Rrange, SOstart and SOend.

[0105] The NACK SN field may indicate a SN of an RLC SDU (or RLC SDU segment) that has been detected as lost at the receiving side of the AM RLC entity.

[0106] The SOstart field (together with the SOend field) may indicate a portion of the RLC SDU with SN=NACK_SN (the NACK_SN to which the SOstart is associated) that has been detected as lost at the receiving side of the AM RLC entity. Specifically, the SOstart field may indicate a position of a first byte of the portion of the RLC SDU in bytes within the original RLC SDU. A first byte of the original RLC SDU may be referred to by the SOstart field value “0000000000000000”, i.e., numbering may start at zero (without limiting the disclosure thereto; the skilled person may find other suitable numbering schemes).Our ref.: 240508EPWOP 11

[0107] Sony Group Corporation

[0108] A meaning of the SOend field may depend on a value of the extension bit E3.

[0109] When E3=0, the SOend field (together with the SOstart field) may indicate the portion of the RLC SDU with SN=NACK_SN (the NACK_SN to which the SOend is associated) that has been detected as lost at the receiving side of the AM RLC entity. Specifically, the SOend field may indicate a position of a last byte of the portion of the RLC SDU in bytes within the original RLC SDU. A first byte of the original RLC SDU may be referred to by the SOend field value “0000000000000000”, i.e., numbering may start at zero (without limiting the disclosure thereto; the skilled person may find other suitable numbering schemes). The special SOend value “1111111111111111” may be used to indicate that the missing (e.g., lost) portion of the RLC SDU includes all bytes to the last byte of the RLC SDU.

[0110] When E3=l, the SOend field may indicate the portion of the RLC SDU with SN=NACK_SN + NACK range - 1 that has been detected as lost at the receiving side of the AM RLC entity. Specifically, the SOend field may indicate a position of a last byte of the portion of the RLC SDU in bytes within the original RLC SDU. A first byte of the original RLC SDU may be referred to by the SOend field value “0000000000000000”, i.e., numbering may start at zero (without limiting the disclosure thereto; the skilled person may find other suitable numbering schemes). The special SOend value “1111111111111111” may be used to indicate that the missing (e.g., lost) portion of the RLC SDU includes all bytes to the last byte of the RLC SDU. Thus, for E3=0, SOstart and SOend may indicate a missing portion within a single SDU, whereas for E3=l, SOstart and SOend may indicate a missing portion that ranges over several SDUs according to NACK_Range.

[0111] The field El may indicate whether or not a set of NACK SN, El, E2 and E3 follows. The interpretation may be that for El=0, a set of NACK SN, El, E2 and E3 does not follow, and for El=l, a set of NACK_SN, El, E2 and E3 follows.

[0112] The field E2 may indicate whether or not a set of SOstart and SOend follows. The interpretation may be that for E2=0, a set of SOstart and SOend does not follow for the associated NACK SN, and for E2=l, a set of SOstart and SOend follows for the associated NACK SN.

[0113] The field E3 may indicate whether or not information about a continuous sequence of RLC SDUs that have not been received follows. The interpretation may be that for E2=0, a NACK_Range field does not follow for the associated NACK_SN, and for E2=l, a NACK_Range field follows for the associated NACK_SN.Our ref.: 240508EPWOP 12

[0114] Sony Group Corporation

[0115] The NACK Range field may indicate a number of consecutively lost RLC SDUs starting from and including NACK_SN.

[0116] For illustrating the format of the STATUS PDU, Fig. 3 to 7 illustrate examples of loss scenarios and their corresponding STATUS PDUs. In the examples of Fig. 3 to 7, the SN has a length of 12 bit, and the SDUs have lengths of 1024 bytes and are segmented equally into four 256-byte segments. In Fig. 3 to 7, a receiving (Rx) side 31 receives SDUs from a transmitting (Tx) side 32. Here, the Rx side 31 can be a User Equipment (UE) and the Tx side 32 can be a base station. Alternatively, the Rx side 31 can be the base station and the Tx side 32 can be the UE. The Rx side can be also denoted as a Rx AM RLC entity or a Rx node, similarly the Tx side can be also denoted as a Tx AM RLC entity or a Tx node. Upon receiving a STATUS request (e.g., a PDU with the polling bit (e.g., the polling bit 21b, 22b, 23b or 24b of Fig. 2) set to 1) from the Tx side 32, the Rx side 31 sends a STATUS PDU to the Tx side 32. Each row of the illustrated STATUS PDUs corresponds to an octet.

[0117] Fig. 3 illustrates an example of a STATUS PDU 34 when no SDU segment is lost. The Rx side 31 has received an SDU 33 with SN=0 (SDU-0). There are four PDUs received with equal sizes (each 256 bytes), and in this case there is no loss for SDU-033 with SN=0. Thus, in a STATUS Reporting (SR) (STATUS PDU) 34 that corresponds to the SDU-033, a D / C bit 34a is 0, a CPT field 34b is 0, an ACK_SN 34c is 1 (the SN of the next not received RLC SDU or next to be acknowledged), an bit El 34d is 0 (a set of NACK_SN, El, E2 and E3 does not follow), and an R (reserved) field 34e is 0.

[0118] Fig. 4 illustrates an example of a STATUS PDU 37 when contiguous segments are lost. The Rx side 31 has received an SDU 35 with SN=1 (SDU-1) and an SDU 36 with SN=2 (SDU-2). From SDU-1 35, the SDU segments at segment offset (SO) 0x000 and 0x100 are received, and the SDU segments at SO 0x200 and 0x300 are not received (e.g., are lost), as illustrated by crossing diagonal lines. The SDU-236 is completely received. Since there are 8 PDUs received with equal sizes (each 256 bytes), and in this case there is no loss for SDU-236 with SN = 2, but there is loss in SDU-1 35, in an SR 37 (STATUS PDU) that corresponds to the SDUs 35 and 36, a D / C bit 37a is 0, a CPT field 37b is 0, an ACK_SN 37c is 3 (the SN of the next not received RLC SDU or next to be acknowledged), an El bit 37d is 1 (a set of NACK SN, El, E2 and E3 follows) and an R field 37e is 0. A following NACK_SN 37f is 1 to indicate the loss of SDU-1 35. In this case, an El bit 37g is 0 (nothing follows after this), an E2 bit 37h is 1 (a set of SOstart and SOend follows for this NACK_SN 37f), an E3 bit 37i is 0 (NACK_Range does not follow for this NACK_SN 37f), and an R bit 37j is 0. As the E2 bit 37h was set to 1, the lostOur ref.: 240508EPWOP 13

[0119] Sony Group Corporation

[0120] PDUs for SDU-1 35 must be identified as SOstart 37k = 0x0200 and SOend 371 = 0x03FF (the last byte of the lost PDU). Alternatively, SOend 371 can be set to OxFFFF (“1111111111111111”) to indicate that the missing portion of the RLC SDU 35 includes all bytes to the last byte of the RLC SDU 35.

[0121] Fig. 5 illustrates an example of a STATUS PDU 40 when multiple complete SDUs are lost. The Rx side 31 detects that two complete SDUs 38 and 39 (SDU-3 and SDU-4 with SN=3 and SN=4, respectively) are lost (e.g., not received). Since there are 8 PDUs received with equal sizes (each 256 bytes), and in this case both SDUs 38 and 39 are lost, in the SR 40 that corresponds to SDU-3 38 and SDU-439, a D / C bit 40a is 0, a CPT field 40b is 0, an ACK_SN 40c is 5, an El bit 40d is 1, and an R field 40e is 0. A following NACK_SN 40f is 3 to indicate the start of the consecutively lost PDUs. In this case, an El bit 40g is 0, an E2 bit 40h is 0, an E3 bit 40i is 1 (NACK_Range follows for this NACK_SN 40f), and an R bit 40j is 0. As the E3 bit 40i was set to 1, the consecutively lost PDUs must be identified by NACK_Range 40k set to 2 (i.e., NACK_SN + (NACK Range - 1) = 3 - (2 -1) = 2).

[0122] Fig. 6 illustrates an example of a STATUS PDU 44 when segments of multiple SDUs are lost. The Tx side 32 transmits to the Rx side 31 an SDU 41 with SN=5 (SDU-5), an SDU 42 with SN=6 (SDU-6) and an SDU 43 with SN=7 (SDU-7). The Rx side 31 detects that from the SDU-5 41, a segment from SO 0x100 to OxlFF is lost (not received), and from the SDU-642, segments from SO 0x000 to OxlFF are lost (not received). Since there are 12 PDUs received with equal sizes (each 256 bytes), and in this case some SDUs are lost, in an SR 44 that corresponds to the SDUs 41 to 43, a D / C bit 44a is 0, a CPT field 44b is 0, an ACK_SN 44c is 8, an El bit 44d is 1, and an R field 44e is 0. A following NACK_SN 44f is 5 to indicate the first lost PDU. In this case, an El bit 44g is 1 (to indicate there is another lost PDU following), an E2 bit 44h is 1, an E3 bit 44i is 0, and an R bit 44j is 0. As the E2 bit 44h was set to 1, the lost PDU for SDU-5 41 must be identified by SOstart 44k = 0x0100 and SOend 441 = 0x0 IFF (the last byte of the lost PDU). A following NACK_SN 44m is 6 to indicate the following lost PDUs. In this case, an El bit 44o is 0, an E2 bit 44p is 1, an E3 bit 44q is 0, and an R bit 44r is 0. As the E2 bit 44p was set to 1, the lost PDUs for SDU-642 must be identified by SOstart 44s = 0x0000 and SOend 44t = OxOlFF.

[0123] Fig. 7 illustrates an example of a STATUS PDU 48 when contiguous segments across multiple SDUs are lost. The Tx side 32 transmits to the Rx side 31 an SDU 45 with SN=8 (SDU-8), an SDU 46 with SN=9 (SDU-9) and an SDU 47 with SN=10 (SDU-10). The Rx side 31 detects that SDU segments from an SO 0x100 of SDU-946 to an SO 0x2FF of SDU-1047 are lost (notOur ref.: 240508EPWOP 14

[0124] Sony Group Corporation

[0125] received). Since there are 12 PDUs received with equal sizes (each 256 bytes), and in this case some SDUs are lost, in an SR 48 that corresponds to the SDUs 45 to 47, a D / C bit 48 is 0, a CPT field 48b is 0, an ACK_SN 48c is 11, an El bit 48d is 1, and an R field 48e is 0. A following NACK_SN 48f is 9 to indicate the first lost PDU. In this case, an El bit 48g is 0, an E2 bit 48h is 1, an E3 bit 48i is 1, and an R bit 48j is 0. As the E2 bit 48h and the E3 bit 48i were set to 1, there are contiguous lost PDUs that belong to SDU-946 and SDU-1047, and that are identified by SOstart 48k = 0x0100 and SOend 481 = 0x02FF, with the NACK_Range 48m = 2.

[0126] In the NR RLC AM mode, a user equipment (UE) may perform an initial ARQ transmission of an RLC PDU. The UE may trigger retransmission of an RLC PDU only if it receives an RLC status report from a gNB (that may receive the RLC PDU) indicating a negative acknowledgement (NACK) for the RLC PDU. For RLC status reporting, the gNB can send a NACK status for an RLC PDU when polling information is received or when detecting an SN gap between two consecutively received RLC PDUs. Such a procedure may cause a long delay for a retransmission of an RLC PDU, and it may not be suitable for an RLC PDU with a small packet delay budget (PDB). This is because, after such a long delay, the ARQ retransmission of the RLC PDU may arrive beyond the packet delay budget (PDB) of the PDU and, hence, may impact the quality of service (QoS).

[0127] Therefore, enhancing the RLC ARQ re-transmission for the operation of the RLC AM may be beneficial. To enhance the RLC re-transmission for an RLC PDU with small PDB, the delay gap between the initial ARQ transmission and the re-transmission of the RLC PDU may be reduced. It is noted that 3GPP RAN2 has been discussing two different methods:

[0128] As a first method, autonomous ARQ retransmission has been discussed, where the transmission (Tx) side may detect that a remaining lifetime of an SDU is very short and may start retransmitting without waiting for feedback from a receiving (Rx) side. It has been identified that this method is not efficient in some instances and may impact a system capacity as all SDUs may be retransmitted blindly.

[0129] As a second method, polling enhancements have been discussed, where the Tx side may rely on feedback from the Rx side before starting ARQ retransmission.

[0130] An idea of the present disclosure is that a receiver (e.g., a UE) may provide STATUS reports for an SDU or segments of an SDU (i.e., one or more PDUs) that are stuck, e.g., in lower layer HARQ retransmissions when the receiver receives a request of a STATUS report from its Tx AM RLC entity (i.e., polling information), regardless of whether a t-Reassembly timer is running or not.Our ref. : 240508EPWOP 15

[0131] Sony Group Corporation

[0132] In the current NR specification, the transmitter RLC entity (i.e., the Tx side) can send a request for a STATUS report to its Rx AM RLC entity (i.e., the Rx side) (for example, the request may include polling information). In this case, the Tx side, upon submission of an AMD PDU including a polling bit to a lower layer, shall set POLL SN to the highest SN of the AMD PDU among the AMD PDUs submitted to the lower layer. The POLL SN may be included in the PDU with the status request.

[0133] At the Rx side, there are two ways to trigger a STATUS report: a polling information from the Tx side or detection of reception failure for PDU (e.g., if there is at least one missing byte segment of the SDU):

[0134] • Polling from its peer AM RLC entity:

[0135] o When an AMD PDU with SN = x (i.e., POLL_SN) and the P field set to " 1 " is received from a lower layer, the receiving side of an AM RLC entity shall:

[0136] ■ if x < RX_Highest_Status or x >= RX_Next + AM_Window_Size:

[0137] • trigger a STATUS report.

[0138] ■ else:

[0139] • delay triggering the STATUS report until x < RX Highest Status or x >= RX_Next + AM_Window_Size.

[0140] • Detection of reception failure of an AMD PDU

[0141] o The Rx side of an AM RLC entity shall trigger a STATUS report when t- Reassembly expires.

[0142] The second trigger as above “detection of reception failure for PDU” indicates that if a t-Reassembly timer is running, the status report is not triggered due to missing PDU(s) where there may still be some HARQ retransmissions happening in the lower layers, i.e., the RLC Status report should be transmitted after HARQ reordering (i.e., after t-Reassembly expires). Furthermore, to avoid excessive RLC Status reports, there may be a t-StatusProhibit timer that controls how often the RLC Status report are sent to the transmitter side.

[0143] It is to be noted that the t-Reassembly and t-StatusProhibit timers may be set to zero or small values in order to reduce the time gap between the first ARQ transmission and retransmission. However, setting the t-Reassembly timer to zero or a small value may cause HARQ retransmissions from the lower layers to be abandoned, hence resulting in degraded radio link performance, and premature NACKs to be reported in the status report. On one hand, byOur ref. : 240508EPWOP 16

[0144] Sony Group Corporation

[0145] considering the time it may take to complete a number of HARQ retransmissions in the lower layers, it may be desirable to set the t-Reassembly timer to an appropriate value. On the other hand, the t-Reassembly timer may create a long-time gap between the first ARQ transmission and retransmission, more specifically when the remaining lifetime of the SDU is very short. In order to resolve the above issue, it is proposed to bypass the t-Reassembly timer so that the Rx side (e.g., UE) can report the segments of an SDU (i.e., one or more PDUs) that are still stuck in the HARQ retransmissions whilst the t-Reassembly timer may be still running (i.e., the HARQ processing may still be ongoing). In this case, the Tx side may retransmit (e.g., on an ARQ level) these segments of the SDU after receiving the status report, hence reducing the time gap between the first ARQ transmission and retransmission.

[0146] It is to be noted that the t-Reassembly timer may still be needed to oversee the HARQ retransmissions for the missing SDU, because in practice, HARQ retransmissions may take longer than the timer, hence, the timer may ensure that a sufficient time is given to the HARQ retransmissions to improve the radio link performance, so the result may be either a late positive acknowledgement (ACK) or a firm negative acknowledgement (NACK) which can be reported in the next status report.

[0147] The segments of an SDU (i.e., one or more PDUs) that are still stuck in the HARQ retransmissions may be given a premature NACK status in the status report, so that the Tx side can retransmit them. This means that if a PDU is successful, it may be given an ACK status (first status) otherwise either a firm NACK status (second status) or a premature NACK status (third status).

[0148] Consequently, some embodiments of the present disclosure pertain to circuitry for mobile telecommunications, that is configured to:

[0149] receive, from a transmission node, a data unit that includes at least one segment; and transmit, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing.

[0150] The circuitry may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a programmed microprocessor, or any other suitable configuration that is capable of performing the processing described herein. The circuitry may include a processing unit for data processing and / or for an overall control of the circuitry, a storage unit for storing instructions for the processing unit (e.g., firmware, software) and / or for storing data that are used or generated by the processing unit, and a communication unit for outputting data that the circuitry has received from the transmission (Tx) node. The circuitry mayOur ref. : 240508EPWOP 17

[0151] Sony Group Corporation

[0152] further include an antenna or may control an antenna connected to the circuitry. With the antenna, the circuitry may communicate with the Tx node via mobile telecommunications. For example, the circuitry may be configured as a general-purpose computer, as described with respect to Fig. 19.

[0153] The mobile telecommunications may include New Radio (NR) or any other suitable Radio Access Technology (RAT) according to the fifth generation (5G), the sixth generation (6G), or any further generation. The disclosure is not limited to NR, 5G or 6G. The skilled person may find further mobile telecommunication systems to which the present technology may be applied. The communicating with the Tx node may include the receiving of the data unit from the Tx node. Accordingly, the circuitry may be included in or configured as a reception (Rx) node for receiving the data unit from the Tx node.

[0154] The data unit may include one segment or a plurality of segments. If the data unit includes a plurality of segments, the segments may have a same size or different sizes. The Tx node may transmit each segment of the data unit separately and, e.g., prefixed with a header. The header may include header information that may indicate a sequence number (SN) of the data unit and / or a segment offset (SO) of the segment within the data unit. The circuitry may receive the segments and determine (e.g., assemble) the data unit from the received segments based on the header information.

[0155] Further, based on the header information, the circuitry may determine that a segment of the data unit has not been received. For example, a first transmission attempt of the segment may have failed, and a retransmission of the segment may still be ongoing (e.g., may not yet be completed).

[0156] The indication that retransmission of the segment is ongoing may indicate the segment whose retransmission is ongoing. For example, the indication may indicate the SN of the data unit and / or the SO of the segment within the data unit.

[0157] Thus, based on the indication, the Tx node may transmit a further instance of the segment to the circuitry, such that a time gap between a first ARQ transmission and a retransmission may be reduced.

[0158] The circuitry may be included in a user equipment (UE) or in a base station. Accordingly, some embodiments pertain to a user equipment for mobile telecommunications that includes the circuitry. Some embodiments pertain to a base station for mobile telecommunications that includes the circuitry.Our ref. : 240508EPWOP 18

[0159] Sony Group Corporation

[0160] The UE may include a smartphone, a laptop, a smartwatch, a head-mounted display, a vehicle (e.g., car, truck, bus, etc.), an unmanned aerial vehicle (UAV), an internet-of-things (loT) appliance (e.g., sensor, actuator, switch, etc.), an industrial appliance (e.g., machine, robot, etc.), or any other apparatus that is capable of communicating via mobile telecommunications. The UE may be configured similar to the UE 200 of Fig. 18.

[0161] The base station may include a gNB, an eNB, or any other logical node in a radio access network that may provide wireless communication capabilities to a UE. The base station can be also denoted as RAN node. In case of 6G, the base station can be a 6G node B or 6G RAN node. The base station may be configured similar to the base station 201 of Fig. 18.

[0162] If the circuitry is included in a UE, the Tx node may be a base station that transmits the data unit to the UE (e.g., via a Physical Downlink Shared Channel (PDSCH)). If the circuitry is included in a base station, the Tx node may be a UE that transmits the data unit to the base station (e.g., via a Physical Uplink Shared Channel (PUSCH)). However, the present technology is not limited to communication between a UE and a base station. For example, the circuitry may be included in a UE, and the Tx node may be included in a further UE (e.g., vehicle-to-vehicle (V2V), vehicle-to-everything (V2X), everything-to-everything (X2X) etc.), wherein the Tx node may transmit the data unit, e.g., via a Physical Sidelink Shared Channel (PSSCH).

[0163] In some embodiments, the data unit is configured as a Service Data Unit (SDU). The SDU may be specified for a predetermined network protocol. The SDU may include a header and / or payload. The payload may include data (e.g., an SDU or a segment of an SDU) according to a protocol from a network layer above the predetermined network protocol.

[0164] In some embodiments, the at least one segment of the data unit is included in a Protocol Data Unit (PDU). The PDU may be specified for a predetermined network protocol. The PDU may include a header and a segment of the data unit. If the data unit is segmented into a plurality of segments, each segment of the data unit may be included in a separate PDU. The header of the PDU may include header information that may indicate the SN of the data unit and / or a SO of the segment within the data unit. The circuitry may receive the PDU(s) and determine (e.g., assemble) the data unit from the received PDU(s) based on the header information.

[0165] In some embodiments, the Tx node transmits the data unit according to a Radio Link Control (RLC) protocol. The SDU may be an RLC SDU, and the PDU may be an RLC PDU. The RLC protocol may be in a network layer above a Media Access Control (MAC) protocol and / or a network layer below a Packet Data Convergence Protocol (PDCP). The data unit (RLC SDU) may include, as payload, a PDCP SDU. The RLC PDU may include the entire RLC SDU or aOur ref. : 240508EPWOP 19

[0166] Sony Group Corporation

[0167] segment of the RLC SDU. The RLC protocol may correspond to an RLC protocol as specified by a known 5GNR specification and / or to any other protocol that may provide a similar function as the 5GNRRLC protocol (e.g., to a successor protocol in a subsequent generation such as 6G, without limiting the disclosure thereto).

[0168] In some embodiments, the Tx node (Tx side) transmits the data unit in an acknowledged mode (AM). The AM may be a transmission mode in which the Rx node (Rx side) (e.g., the circuitry) provides feedback to the Tx node. The feedback may indicate whether the Rx node has successfully received the data unit or a segment of the data unit. The feedback may include a positive acknowledgement (ACK), which may indicate that the Rx node has successfully received the data unit or segment thereof, or a negative acknowledgement (NACK), which may indicate that the Rx node has not successfully received the data unit or segment thereof. The AM may further provide an error correction based on Automatic Repeat Request (ARQ). For example, the data unit may be an RLC AM SDU, and may be included in one or more RLC AM PDU(s).

[0169] In some embodiments, the transmitting of the indication is based on a Radio Link Control (RLC) protocol. The circuitry may transmit the indication according to a format that may be specified by the RLC protocol. As mentioned, the RLC protocol may correspond to an RLC protocol as specified by a known 5GNR specification and / or to any other protocol that may provide a similar function as the 5G NR RLC protocol (e.g., to a successor protocol in a subsequent generation such as 6G, without limiting the disclosure thereto).

[0170] In some embodiments, the indication is included in a Protocol Data Unit (PDU). For example, the indication may be included in an RLC PDU.

[0171] In some embodiments, the indication is included in a STATUS report. The STATUS report may be configured as an RLC PDU. The STATUS report may include the SN of the data unit. The STATUS report may indicate the segment of the data unit for which retransmission is ongoing by indicating an SO of the segment (e.g., an offset of a first byte and / or of a last byte of the segment within the data unit).

[0172] In some embodiments, the indication includes setting, in the STATUS report, a reserved bit that is associated with the segment of the data unit. In some embodiments, the indication includes setting, in the STATUS report, a reserved bit that is associated with the data unit. Setting the reserved bit (e.g., assigning a value of “1” to the reserved bit instead of a value of “0”) may indicate that the indication does not correspond to a firm NACK but that retransmission of the segment is still ongoing. The reserved bit may be included in an octet that includes at least aOur ref.: 240508EPWOP 20

[0173] Sony Group Corporation

[0174] portion of a NACK SN that indicates the data unit. The reserved bit may be included in an octet that includes an extension bit El for indicating whether a further segment (e.g., PDU) has not been successfully received (yet). The reserved bit may be included in an octet that includes an extension bit E2 for indicating whether the STATUS report includes an indication of a SO (e.g., SOstart and / or SOend) of the segment. The reserved bit may be included in an octet that includes an extension bit E3 for indicating whether the STATUS report includes an indication of a NACK Range in which the segment is included. By using the reserved bit for the indication, only a small change to a known 5GNR specification may be necessary for transmitting the indication.

[0175] In some embodiments, the indication includes setting, in the STATUS report, a reserved bit that is associated with an acknowledgement sequence number. Setting the reserved bit (e.g., assigning a value of “1” to the reserved bit instead of a value of “0”) may indicate that the STATUS report includes an indication of at least one segment for which retransmission is ongoing. The reserved bit may be a bit of a reserved field in an octet that may follow the ACK SN in the STATUS report. The reserved bit may be included in a same octet as an extension bit El for indicating that an indication of a NACK_SN follows the ACK_SN in the STATUS report. For example, setting the reserved bit may indicate that retransmission is ongoing for all segments (e.g., SDU segments) indicated in the STATUS report, or that the STATUS report includes an additional bit (e.g., reserved bit) associated with each segment or range of segments, wherein the additional bit indicates whether retransmission is still ongoing for the associated segment or range of segments. By using the reserved bit for the indication, only a small change to a known 5GNR specification may be necessary for transmitting the indication.

[0176] In some embodiments, the indication includes setting, in the STATUS report, a Control Protocol Data Unit Type (CPT) to a predetermined value different from zero. For example, the predetermined value may be “0x001”, “0x010”, “0x100”, “0x111”, or any other suitable value (e.g., a value that may be reserved in a known 5G NR specification). Setting the CPT to the predetermined value may indicate that retransmission is ongoing for all segments (e.g., SDU segments) indicated in the STATUS report, or that the STATUS report includes an additional indication (e.g., reserved bit) associated with each segment or range of segments, wherein the additional indication indicates whether retransmission is still ongoing for the associated segment or range of segments. By using the predetermined value for the CPT, only a small change to a known 5GNR specification may be necessary for transmitting the indication.Our ref. : 240508EPWOP 21

[0177] Sony Group Corporation

[0178] In some embodiments, the indication includes reporting, as a status of the segment, a status that is different from a positively acknowledged (ACK) status and from a negatively acknowledged (NACK) status. The ACK status may indicate that the data unit or the segment has been successfully received, whereas the NACK status may indicate that transmitting the data unit or the segment has failed (and, e.g., that no retransmission attempts are active). Thus, the indication may report a third status that is different from the ACK status and from the NACK status, and that may indicate that an attempt of transmitting the segment has failed, and that retransmission is ongoing. Thus, the Tx node may decide, based on the reporting of the third status, whether to start a further retransmission of the segment, e.g., for reducing a delay of the segment.

[0179] In some embodiments, the status corresponds to a premature negatively acknowledged status. Thus, the status may indicate that reception of the segment is currently not acknowledged, but that the circuitry might have successfully received the segment at a later time due to the ongoing retransmission of the segment.

[0180] In some embodiments, the status corresponds to an unknown status. Thus, the status may indicate that it is not known whether the segment will be successfully received because the retransmission is still ongoing.

[0181] In some embodiments, the retransmission is based on a lower protocol layer than a protocol layer of the data unit. For example, the data unit may be transmitted in an RLC protocol layer, and the retransmission may be performed in a protocol layer below the RLC protocol layer.

[0182] In some embodiments, the retransmission is based on a Media Access Control (MAC) protocol. The MAC protocol layer may be below the RLC protocol layer.

[0183] In some embodiments, the retransmission is based on Hybrid Automatic Repeat Request (HARQ). HARQ may be provided by the MAC protocol and may be performed in the MAC protocol layer.

[0184] In some embodiments, the circuitry is further configured to determine that retransmission of the segment is ongoing based on a determination that an associated retransmission timer is running. The retransmission timer may specify a maximum duration for the retransmission of the segment. If the circuitry has not received the segment when the retransmission timer has expired, the circuitry may determine that (re)transmission of the segment has failed and may assign a firm NACK status to the segment. Thus, as long as the retransmission timer has not expired yet but is still running, the retransmission may still be ongoing. Although the ongoing retransmission of the segment may be based on a lower protocol layer than the STATUS report, the determiningOur ref. : 240508EPWOP 22

[0185] Sony Group Corporation

[0186] whether the retransmission timer is running may be an uncomplicated way of determining whether a retransmission is ongoing in the lower protocol layer.

[0187] In some embodiments, the retransmission timer is configured as a t-Reassembly timer. For example, the retransmission timer may correspond to a t-Reassembly timer as specified by a known 5GNR specification.

[0188] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on a request from the Tx node. For example, the Tx node may send a status request to the circuitry after transmitting the data unit, such that the Tx node may determine whether the data unit has been successfully received or whether the Tx node needs to retransmit one or more segments of the data unit.

[0189] In some embodiments, the request corresponds to polling information. In some embodiments, the request includes setting a polling bit of a PDU according to an RLC protocol. The setting of the polling bit may include setting the polling bit to a predetermined value (e.g., to “1”). For example, the Tx node may set a polling bit of an RLC PDU to the predetermined value for transmitting polling information.

[0190] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on a determination that a number of received retransmissions of the segment exceeds a threshold. For example, the received retransmissions may be based on the MAC protocol and may be HARQ retransmissions. The threshold may be predetermined or may be adapted, e.g., based on a determination of a reliability of a used channel (e.g., based on a number of retransmissions that were necessary for preceding PDUs, based on a measured link quality such as a Reference Signal Received Power (RSRP) and / or a Received Signal Strength Indicator (RSSI)). For example, the threshold may correspond to 3, 6 or 8 HARQ retransmissions (without limiting the disclosure to these values; the skilled person may find other suitable values for the threshold). The (Rx node) circuitry may transmit the indication, e.g., in a STATUS report, upon detecting that the number of received (but unsuccessful) HARQ retransmissions of the segment exceeds the threshold. Thus, the Tx node may be able to retransmit the segment without transmitting a status request. Since the Rx node circuitry may transmit the indication without waiting for a status request from the Tx node, a delay before a further ARQ retransmission may be reduced.

[0191] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on detecting a gap in a sequence between successfully received PDUs. The gap may correspond to the segment. For example, the circuitry may determine, based on a respectiveOur ref.: 240508EPWOP 23

[0192] Sony Group Corporation

[0193] SN and / or SO of successfully received PDUs, that a PDU that corresponds to the segment has not been successfully received, but that a later PDU has been successfully received that corresponds to a later SO within the data unit than the segment or that corresponds to a later data unit (e.g., SDU) (e.g., with a higher SN) than the data unit. Upon such a determination, the circuitry may transmit the indication without waiting for a status request from the Tx node, such that a delay before a further ARQ retransmission of the segment may be reduced.

[0194] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on a determination that a later data unit with a higher sequence number than the data unit has been successfully received. Such a determination may correspond to detecting a gap in a sequence between successfully received PDUs. For example, the circuitry may determine that all segments of the later data unit (e.g., a later SDU) have been successfully received, but that the segment of the (earlier) data unit has not been successfully received. Upon such a determination, the circuitry may transmit the indication without waiting for a status request from the Tx node, such that a delay before a further ARQ retransmission of the segment may be reduced.

[0195] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on a determination that a segment of a later data unit with a higher sequence number than the data unit has been successfully received. Such a determination may correspond to detecting a gap in a sequence between successfully received PDUs. For example, the circuitry may determine that the Tx node has started transmission of the later data unit (e.g., SDU, wherein the segment of the later data unit may be included in a PDU) before all segments of the (earlier) data unit have been successfully received. Upon such a determination, the circuitry may transmit the indication without waiting for a status request from the Tx node, such that a delay before a further ARQ retransmission of the segment may be reduced.

[0196] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on a determination that a later segment of the data unit at a higher segment offset than the segment has been successfully received. Such a determination may correspond to detecting a gap in a sequence between successfully received PDUs. Upon such a determination, the circuitry may transmit the indication without waiting for a status request from the Tx node, such that a delay before a further ARQ retransmission of the segment may be reduced.

[0197] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on a determination that a number of segments of the data unit for which retransmission is ongoing exceeds a threshold. For example, the ongoing retransmission may beOur ref.: 240508EPWOP 24

[0198] Sony Group Corporation

[0199] a HARQ retransmission (e.g., in the MAC protocol layer). The threshold may be predetermined or may be adapted. For example, the circuitry may determine, based on the number of segments for which retransmission is ongoing and based on granted resources that are used for the retransmission, that the granted resources are not sufficient for transmitting the number of segments within a predetermined time (e.g., without violating a predetermined Packet Delay Budget (PDB)). Thus, the circuitry may transmit the indication to the Tx node without waiting for a status request, such that the Tx node may grant more resources for the retransmission of the segments, which may faster retransmissions.

[0200] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on a remaining Packet Delay Budget (PDB) associated with the data unit. For example, a remaining lifetime of the data unit may be short (e.g., below a predetermined threshold). For example, if the circuitry determines that the only a small portion of the original PDB remains, the circuitry may transmit the indication to the Tx node without waiting for a status request, such that the Tx node may grant more resources for the retransmission of the segment and the segment may be retransmitted faster.

[0201] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on granted resources that are available for the retransmission. For example, the circuitry may determine that little resources are granted for the retransmission, or that the retransmission might be accelerated by granting more resources. The circuitry may transmit the indication to the Tx node, such that the Tx node may grant more resources for the retransmission of the segment and the segment may be retransmitted faster.

[0202] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on a determination that a data amount received since a first transmission of the segment exceeds a threshold. The threshold may be predetermined or may be adapted, e.g., based on a link quality such as an RSRP and / or an RSSI. For example, the circuitry may determine that the segment has not been successfully received although the Tx node has transmitted the data amount that exceeds the threshold since transmitting the segment. Thus, the circuitry may transmit the indication to the Tx node without waiting for a status request, such that the Tx node may start a further retransmission for reducing a delay of the segment.

[0203] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on a determination that a time elapsed since a first transmission of the segment exceeds a threshold. The threshold may be predetermined or may be adapted, e.g., based on a link quality such as an RSRP and / or an RSSI. For example, the threshold may indicate that aOur ref.: 240508EPWOP 25

[0204] Sony Group Corporation

[0205] failure may have occurred in the retransmission. Thus, the circuitry may transmit the indication to the Tx node without waiting for a status request, such that the Tx node may be notified of the failure and may start a further retransmission of the segment (e.g., based on an adapted retransmission parameter), and a delay of the segment may be reduced.

[0206] In some embodiments, the circuitry is further configured to trigger the transmitting of the indication based on a determination that a number of Protocol Data Units (PDUs) that need to be retransmitted exceeds a threshold. The threshold may be predetermined or may be adapted, e.g., based on a link quality such as an RSRP and / or an RSSI. For example, the circuitry may determine, based on the threshold, that granted resources are not sufficient for transmitting the number of segments within a predetermined time (e.g., without violating a predetermined PDB). Thus, the circuitry may transmit the indication to the Tx node without waiting for a status request, such that the Tx node may grant more resources for the retransmission of the segments, which may allow faster retransmissions.

[0207] In some embodiments, the circuitry is further configured to transmit the indication based on a determination of a service to which the data unit corresponds. The circuitry may transmit the indication that retransmission of the segment is ongoing if the service requires a fast transmission of the data unit. For example, a radio bearer may be associated with the service. In some embodiments, the determination of the service includes determining that the service requires a predetermined minimum data rate. For example, the service may require at least the predetermined minimum data rate to prevent a failure of the service and / or to prevent a reduced QoS (e.g., reduced user experience) of the service. Thus, the circuitry may transmit the indication that retransmission of the segment is ongoing if the circuitry determines that the service requires a fast data connection corresponding to the predetermined minimum data rate. If the circuitry determines that the service does not require the predetermined minimum data rate, the circuitry may wait for an ACK or a firm NACK before transmitting a STATUS report to the Tx node.

[0208] In some embodiments, the determination of the service includes determining that the service requires a predetermined maximum latency. For example, the service may require at least the predetermined maximum latency to prevent a failure of the service and / or to prevent a reduced QoS (e.g., reduced user experience) of the service. Thus, the circuitry may transmit the indication that retransmission of the segment is ongoing if the circuitry determines that the service requires a fast data connection corresponding to the predetermined maximum latency. If the circuitry determines that the service does not require the predetermined maximum latency,Our ref.: 240508EPWOP 26

[0209] Sony Group Corporation

[0210] the circuitry may wait for an ACK or a firm NACK before transmitting a STATUS report to the Tx node. In this case, depending on the service based on radio bearer, RRC may configure to wait for an ACK or a firm NACK before transmitting a STATUS report or to report immediately a premature NACK / UNKNOWN status in the STATUS report.

[0211] In some embodiments, the determination of the service includes determining that the service includes an extended Reality (XR) service. XR may include VR, AR and / or MR. The XR service may include exchanging (e.g., transmitting and / or receiving) image data, audio data, position data (e.g., geolocation data, address etc.), movement data (e.g., movement speed, movement direction), posture data (e.g., viewing direction, body posture, hand gesture etc.) or the like. The XR service may require that the data exchange is sufficiently fast (e.g., satisfies a predetermined minimum data rate and / or a predetermined maximum latency) such that a desired QoS may be provided and a user of the XR service may be provided seamlessly with XR content without lags, delays, discontinuities, disruptions or the like.

[0212] In some embodiments, Radio Resource Control (RRC) is configured to control whether to transmit the indication that the retransmission is ongoing. The circuitry may receive, via RRC, an instruction from the Tx node to transmit the indication (e.g., in a STATUS report) or to not transmit the indication but to wait for an ACK or a firm NACK before generating and transmitting a STATUS report to the Tx node. The instruction may be based on the service (e.g., a maximum latency of the service, a radio bearer of the service, a kind of service (e.g. XR), etc.). The circuitry may transmit the indication according to the instruction.

[0213] In some embodiments, the circuitry is further configured to transmit the indication while an associated t-StatusProhibit timer is running. The t-StatusProhibit timer may indicate that the circuitry should not transmit a status report before the t-StatusProhibit timer has expired, such that unnecessarily frequent status reports may be avoided. The circuitry may, however, determine that waiting for the t-StatusProhibit timer to elapse might delay a retransmission of the segment, e.g., in a case where a low latency and / or a high data rate is required (e.g., for an XR service). Thus, upon such a determination, the circuitry may bypass the t-StatusProhibit timer and transmit the indication that retransmission of the segment is ongoing to the Tx node before the t-StatusProhibit timer has expired, such that the Tx node may be able to start a further ARQ retransmission (e.g., with an adapted retransmission parameter and / or via additionally granted resources).

[0214] Some embodiments pertain to a method for mobile telecommunications, wherein the method includes:Our ref. : 240508EPWOP 27

[0215] Sony Group Corporation

[0216] receiving, from a Tx node, a data unit including at least one segment; and transmitting, to the Tx node, an indication that retransmission of a segment of the data unit is ongoing.

[0217] The method may be performed by the circuitry (e.g., in a UE and / or in a base station). The method may correspond to any processing performed by the circuitry, as described herein. The method may have features that may correspond to any features described above with respect to the circuitry.

[0218] Some embodiments pertain to transmission (Tx) circuitry for mobile telecommunications, wherein the Tx circuitry is configured to communicate with a reception (Rx) node;

[0219] wherein the Rx node includes the circuitry as described above;

[0220] wherein the communicating with the Rx node includes:

[0221] transmitting the data unit to the reception node;

[0222] receiving, from the Rx node, the indication that retransmission of the segment of the data unit is ongoing; and

[0223] triggering a further retransmission of the segment based on the indication.

[0224] Similar to the circuitry described above, the Tx circuitry may include an ASIC, an FPGA, a programmed microprocessor or the like, and may include a processing unit, a storage unit and / or a communication unit. The Tx circuitry may further include or be connected to an antenna for communicating with the Rx node via the mobile telecommunications (NR, 5G, 6G, or the like, as described above). For example, the Tx circuitry may be configured as a general-purpose computer, as described with respect to Fig. 19.

[0225] The Tx circuitry may be included in the Tx node. The Tx node may be configured as a UE or as a base station. Some embodiments pertain to a UE for mobile telecommunications, wherein the UE includes the Tx circuitry described herein. Some embodiments pertain to a base station for mobile telecommunications, wherein the base station includes the Tx circuitry described herein. As mentioned, the UE may include a smartphone, a laptop, a smartwatch, a head-mounted display, a vehicle (e.g., car, truck, bus, etc.), an UAV, an loT appliance (e.g., sensor, actuator, switch, etc.), an industrial appliance (e.g., machine, robot, etc.), or any other apparatus that is capable of communicating via mobile telecommunications. The UE may be configured similar to the UE 200 of Fig. 18.

[0226] As mentioned, the base station may include a gNB, an eNB, or any other logical node in a radio access network that may provide wireless communication capabilities to a UE. The base stationOur ref.: 240508EPWOP 28

[0227] Sony Group Corporation

[0228] can be also denoted as RAN node. In case of 6G, the base station can be a 6G node B or 6G RAN node. The base station may be configured similar to the base station 201 of Fig. 18.

[0229] As mentioned, if the circuitry is included in a UE, the Tx circuitry may be included in a base station. If the circuitry is included in a base station, the Tx circuitry may be included in a UE. Further, both the circuitry and the Tx circuitry may be included in respective UEs.

[0230] The Tx circuitry may transmit the data unit (e.g., an SDU) to the Rx node. The Rx node may transmit, to the Tx circuitry, the indication that retransmission of the segment is ongoing, as described above. Upon receiving the indication, the Tx circuitry may determine to trigger a further retransmission of the segment to the Rx node (e.g., based on an adapted retransmission parameter and / or via additionally granted resources for the retransmission).

[0231] In some embodiments, the communicating with the Rx node further includes granting further resources for the retransmission of the segment. The resources may include a radio frame, a subframe, a slot, a resource block (RB), a resource element (RE), an Orthogonal Frequency-Division Multiplexing (OFDM) symbol, a subcarrier, or the like, e.g., in a PUSCH, in a PDSCH or in a PSSCH. Granting further resources may provide more capacities for transmitting the segment, such that the retransmission of the segment via the further granted resources may be faster than it would be without granting further resources.

[0232] In some embodiments, the granting of the further resources is based on a remaining Packet Delay Budget (PDB) associated with the data unit. For example, the Tx circuitry may determine that the segment and / or the data unit cannot be transmitted within the remaining PDB without granting further resources, e.g., because of a bad link quality (e.g., RSRP and / or RSSI), because of a large number of data to be transmitted (e.g., a number of bits / bytes of the segment and / or of the data unit), because of a small portion of the original PDB of the data unit that is left, or the like. Granting the further resources may allow (re)transmitting the segment and, possibly, further segments of the data unit via more radio resources (e.g., in parallel), such that the segment (and / or the entire data unit) may be transmitted faster to the Rx node.

[0233] In some embodiments, the further retransmission is based on Automatic Repeat Request (ARQ). For example, the further retransmission, which the Tx circuitry may trigger, may be on a higher protocol layer than the ongoing (e.g., HARQ) transmission that is indicated by the indication (e.g., in the STATUS report).

[0234] Some embodiments pertain to a method for mobile telecommunications, wherein the method includes communicating with a Rx node;

[0235] wherein the Rx node includes the circuitry described above;Our ref. : 240508EPWOP 29

[0236] Sony Group Corporation

[0237] wherein the communicating with the Rx node includes:

[0238] transmitting the data unit to the Rx node;

[0239] receiving, from the Rx node, the indication that retransmission of the segment of the data unit is ongoing; and

[0240] triggering a further retransmission of the segment based on the indication.

[0241] The method may be performed by the Tx circuitry (e.g., in a UE and / or in a base station). The method may correspond to any processing performed by the Tx circuitry, as described herein. The method may have features that may correspond to any features described above with respect to the Tx circuitry.

[0242] The methods as described herein are also implemented in some embodiments as a computer program causing a computer and / or a processor to perform the method, when being carried out on the computer and / or processor. In some embodiments, also a non-transitory computer-readable recording medium is provided that stores therein a computer program product, which, when executed by a processor, such as the processor described above, causes the methods described herein to be performed.

[0243] Returning to Fig. 8, Fig. 8 illustrates an embodiment of a mobile telecommunications network 50. The mobile telecommunications network 50 includes a base station 51, a user equipment (UE) 52, and a UE 53. The UEs 52 and 53 are within a radio cell 54 provided by the base station 51. The UE 52 communicates with the base station 51 via a radio link 55. The UE 53 communicates with the base station 51 via a radio link 56. Further, the UE 52 and the UE 53 can communicate with each other via a radio link 57. The radio links 55, 56 and 57 are examples of mobile telecommunications connections.

[0244] The communication between the base station 51, the UE 52 and the UE 53 includes transmitting SDUs (examples for data units), such as RLC AM SDUs. Some SDUs are entirely included in one respective RLC AM PDU as a single segment, wherein some SDUs are segmented into a plurality of RLC AM PDUs, wherein each RLC AM PDU includes one segment. The base station 51, the UE 52 and the UE 53 include circuitry that is configured to perform the communication.

[0245] It is noted that, in some embodiments, only one of the UEs 52 and 53 is provided and communicates with the base station 51. Further, in some embodiments, the UEs 52 and 53 do not communicate with each other via the radio link 57 but only with the base station 51 via the respective radio links 55 and 56. Also, in some embodiments, the UEs 52 and 53 communicate with each other via the radio link 57, but not with the base station 51.Our ref. : 240508EPWOP 30

[0246] Sony Group Corporation

[0247] Fig. 9 illustrates a first embodiment of a method 60. The method 60 pertains to mobile telecommunications between reception (Rx) node 61 and transmission (Tx) node 62. The Rx node 61 is an example of the UE 52 and of the UE 53. The Tx node 62 is an example of the base station 51.

[0248] At 63, the Tx node 62 transmits a data unit to the Rx node 61. The data unit is configured as an SDU and includes a segment. The segment of the data unit is included in a PDU. The Tx node 62 transmits the data unit according to the RLC protocol in an acknowledged mode (AM).

[0249] At 64, the Rx node 61 receives the data unit. However, the PDU that includes the segment is not successfully received, and retransmission of the segment is started based on Hybrid Automatic Repeat Request (HARQ) according to a MAC protocol. Thus, the retransmission is performed in a lower protocol layer (i.e., in a MAC protocol layer) than a protocol layer of the data unit (which is an RLC protocol layer).

[0250] At 65, the Rx node 61 determines that retransmission of the segment of the data unit is ongoing. The determination that retransmission of the segment is ongoing is based on a determination that an associated t-Reassembly timer (an example of a retransmission timer) is running.

[0251] At 66, the Rx node 61 transmits to the Tx node 62 an indication that retransmission of the segment of the data unit is ongoing. The transmitting of the indication is based on the RLC protocol. The indication is included in a STATUS report in a PDU (STATUS PDU). The indication includes reporting, as a status of the segment, a status that is different from a positively acknowledged (ACK) status and from a negatively acknowledged (NACK) status. At 67, the Tx node 62 receives from the Rx node 61 the indication that retransmission of the segment of the data unit is ongoing.

[0252] At 68, the Tx node 62 grants further resources for the retransmission of the segment to the Rx node 61. The granting of the further resources is based on a remaining PDB associated with the data unit.

[0253] At 69, the Tx node 62 triggers a further retransmission of the segment based on the indication. The further retransmission uses the further resources granted at 68.

[0254] It is noted that, in some embodiments, the determination at 65 that retransmission is ongoing is based on other criteria than on a determination that an associated t-Reassembly timer is running. It is further noted that, in some embodiments, the granting of further resources at 68 is omitted and the further retransmission at 69 uses the resources that were used for the transmitting at 63.Our ref. : 240508EPWOP 31

[0255] Sony Group Corporation

[0256] It is noted that, in some embodiments, the Rx node 61 is configured as a base station, such as the base station 51, instead of a UE, and the Tx node 62 is configured as a UE, such as the UE 52 or the UE 53, instead of a base station. Further, in some embodiments, the Rx node 61 is configured as a UE, such as the UE 52, and the Tx circuitry 62 is configured as a further UE, such as the UE 53.

[0257] Fig. 10 illustrates a second embodiment of a method 70. The method 70 is performed by the Rx node 61 before the transmitting of the indication at 66.

[0258] At 71, the Rx node 61 determines a service of the data unit received at 64. The Rx node 61 transmits the indication that retransmission is ongoing if the service of the data unit satisfies predetermined service criteria. The determining of the service of the data unit includes determining 71a whether the service requires a predetermined minimum data rate, determining 71b whether the service requires a predetermined maximum latency, and determining 71c whether the service includes an XR service. If any one of the service criteria 71a, 71b or 71c is satisfied, the Rx node 61 determines that transmitting the indication that retransmission is ongoing is appropriate. Otherwise, the Rx node 61 determines to not transmit an indication that retransmission is ongoing. Thus, the transmitting of the indication is based on a determination of the service to which the data unit corresponds.

[0259] At 72, the Rx node 61 triggers the transmitting of the indication if the Rx node 61 determines that a trigger criterion is satisfied.

[0260] A first trigger criterion 72a is satisfied if the Rx node 61 receives a status request (an example of a request) from the Tx node 62. The status request corresponds to polling information and includes setting a polling bit of a PDU according to the RLC protocol.

[0261] A second trigger criterion 72b is satisfied if the Rx node 61 determines that a number of received retransmissions of the segment exceeds a threshold.

[0262] A third trigger criterion 72c is satisfied if the Rx node 61 detects a gap in a sequence between successfully received PDUs.

[0263] A fourth trigger criterion 72d is satisfied if the Rx node 61 determines that a later data unit with a higher sequence number than the data unit has been successfully received.

[0264] A fifth trigger criterion 72e is satisfied if the Rx node 61 determines that a segment of a later data unit with a higher sequence number than the data unit has been successfully received.

[0265] A sixth trigger criterion 72f is satisfied if the Rx node 61 determines that a later segment of the data unit at a higher segment offset than the segment has been successfully received.Our ref.: 240508EPWOP 32

[0266] Sony Group Corporation

[0267] A seventh trigger criterion 72g is satisfied if the Rx node 61 determines that a number of segments of the data unit for which HARQ retransmission is ongoing exceeds a threshold.

[0268] An eighth trigger criterion 72h is satisfied if the Rx node 61 determines that a remaining PDB associated with the data unit is below a threshold. Thus, the eighth trigger criterion 72h is based on a remaining PDB associated with the data unit.

[0269] A ninth trigger criterion 72i is satisfied if the Rx node 61 determines that granted resources that are available for the retransmission are less than a threshold. Thus, the ninth trigger criterion 72i is based on granted resources that are available for the retransmission.

[0270] A tenth trigger criterion 72j is satisfied if the Rx node 61 determines that a data amount received since a first transmission of the segment exceeds a threshold.

[0271] An eleventh trigger criterion 72k is satisfied if the Rx node 61 determines that a time elapsed since a first transmission of the segment exceeds a threshold.

[0272] A twelfth trigger criterion 721 is satisfied if the Rx node 61 determines that a number of PDUs that need to be retransmitted exceeds a threshold.

[0273] If any one of the trigger criteria 72a to 721 is satisfied, the Rx node 61 triggers transmission of the indication that HARQ retransmission of the segment is ongoing to the Tx node 62. After the triggering at 72, the Rx node 61 transmits the indication at 66, as indicated by an arrow in Fig. 10.

[0274] It is noted that, in some embodiments, only one or two of the service criteria 71a to 71c are used, or the transmitting of the indication is based on other criteria of the service than the service criteria 71a to 71c. In some embodiments, the determining of the service at 71 may be omitted, and the Rx node 61 may transmit the indication regardless of the service of the data unit.

[0275] It is further noted that, in some embodiments, not all the trigger criteria 72a to 721 are used. For example, the Rx node 61 may determine if one, two or some of the trigger criteria 72a to 721 are satisfied, and may omit determining if one, two or more other ones of the trigger criteria 72a to 721 are satisfied. In some embodiments, the Rx node 61 triggers the transmission of the indication based on other trigger criteria than the trigger criteria 72a to 721.

[0276] Fig. 11 illustrates an embodiment of a STATUS report 80 that indicates a premature NACK status. The premature NACK status is different from the positively acknowledged (ACK) status and from the negatively acknowledged (NACK) status, and indicates that retransmission of a segment is ongoing. The STATUS report 80 is configured as a STATUS PDU and is an example of the indication that retransmission is ongoing, which the Rx node 61 transmits to the TxOur ref.: 240508EPWOP 33

[0277] Sony Group Corporation

[0278] node 62 at 66 of Fig. 9. Apart from reserved bit 80r, the STATUS report 80 is similar to the STATUS PDU 44 of Fig. 6.

[0279] The Tx node 62 transmits to the Rx node 61 an SDU 81 with SN=5 (SDU-5), an SDU 82 with SN=6 (SDU-6) and an SDU 83 with SN=7 (SDU-7). At a time of reporting (e.g., of generating the STATUS report 80), the Rx node 61 has successfully received the SDU-7 83, but from the SDU-5 81, a segment (PDU) from SO 0x100 to OxlFF is lost (not received, i.e., firm NACK), and retransmission (based on HARQ according to the MAC protocol) is ongoing for two segments (PDUs) from SO 0x000 to OxlFF of the SDU-6 82 (as indicated by hourglasses in Fig. 11). This means that after SDU-7 83 is received successfully, a t-Reassembly timer is started because the middle SDU-6 82 is missing.

[0280] In the embodiment of Fig. 11, the Rx node 61 has received polling information, bypasses the t-Reassembly timer, and transmits, to the Tx node 62, the STATUS report 80, which indicates a status of the SDU-6 82 that is stuck in HARQ retransmissions at the time of reporting. In this case, the SDU-6 82 is reported as a premature NACK status by setting a corresponding reserved bit 80r (R=l).

[0281] In detail, in the STATUS report 80, a D / C bit 80a is 0, a CPT field 80b is 0, an ACK SN 80c is 8, an El bit 80d is 1, and an R field 80e is 0. A following firm NACK_SN 80f is 5 to indicate the first lost PDU. In this case, an El bit 80g is 1 (to indicate there is another lost PDU following), an E2 bit 80h is 1, an E3 bit 80i is 0, and an R bit 80j is 0 (here, R 80j = 0 indicates a firm NACK). As the E2 bit 80h was set to 1, the lost PDU for SDU-5 81 is identified by SOstart 80k = 0x0100 and SOend 801 = 0x0 IFF (the last byte of the lost PDU). A following premature NACK SN 80m is 6 to indicate that some PDUs are under HARQ retransmissions. In this case, an El bit 80o is 0, an E2 bit 80p is 1, an E3 bit 80q is 0, and an R bit 80r is 1 (here, R 80r = 1 indicates a premature NACK). As the E2 bit 80p was set to 1, PDUs for SDU-6 82 that are lost and under HARQ retransmissions are identified by SOstart 80s = 0x0000 and SOend 80t = OxOlFF.

[0282] The reserved bit 80r of the STATUS report 80 is associated with the segments that are under HARQ retransmission (via the associated NACK SN 80m, SOstart 80s and SOend 80t) and, thus, with the SDU-6 82.

[0283] It is noted that in the embodiment of Fig. 11, during reporting, the t-Reassembly timer has been started because SDU-7 83 is received successfully, but segments of the middle SDU-6 82 are missing.Our ref.: 240508EPWOP 34

[0284] Sony Group Corporation

[0285] As described, Fig 11 shows an embodiment of a STATUS PDU 80 in which SDU segments (PDUs) that are, at the time of reporting, stuck in HARQ retransmissions (i.e., for which retransmission is ongoing) are given a premature NACK status.

[0286] In some embodiments, however, segments (PDUs) of an SDU that are stuck in HARQ retransmissions are given an UNKNOWN status in a STATUS report, such that a Tx node may become aware that these PDUs are still under process at an Rx node. The Tx node can then retransmit the PDUs, e.g., if a remaining lifetime of the SDU is very short.

[0287] Fig. 12 illustrates a first embodiment of a STATUS report 90 that indicates an UNKNOWN status. The UNKNOWN status is different from the positively acknowledged (ACK) status and from the negatively acknowledged (NACK) status, and indicates that retransmission of a segment is ongoing. The STATUS report 90 is configured as a STATUS PDU and is an example of the indication that retransmission is ongoing, which the Rx node 61 transmits to the Tx node 62 at 66 of Fig. 9. Apart from UNKNOWN_SN 90m and reserved bit 90r, the STATUS report 90 is similar to the STATUS PDU 44 of Fig. 6.

[0288] In the embodiment of Fig. 12, similar to the embodiment of Fig. 11, the Tx node 62 transmits to the Rx node 61 an SDU 91 with SN=5 (SDU-5), an SDU 92 with SN=6 (SDU-6) and an SDU 93 with SN=7 (SDU-7). After receiving polling information, the Rx node 61 bypasses the t-Reassembly timer and transmits, to the Tx node 62, the STATUS report 90, which indicates a status of the SDU-692 that is stuck in HARQ retransmissions at the time of reporting (as indicated by hourglasses in Fig. 12).

[0289] The STATUS report 90 of Fig. 12 differs from the STATUS report 80 of Fig. 11 in that SDU segments (PDUs) that are still stuck in HARQ retransmissions (i.e., for which retransmission is ongoing) are given an UNKNOWN status. In this case, an SDU-692 is reported with an UNKNOWN status by setting the reserved bit 90r (R=l).

[0290] In detail, in the STATUS report 90, a D / C bit 90a is 0, a CPT field 90b is 0, an ACK SN 90c is 8, an El bit 90d is 1, and an R field 90e is 0. A following firm NACK_SN 90f is 5 to indicate the first lost PDU. In this case, an El bit 90g is 1 (to indicate there is another lost PDU following), an E2 bit 90h is 1, an E3 bit 90i is 0, and an R bit 90j is 0 (here, R 90j = 0 indicates a firm NACK). As the E2 bit 90h was set to 1, the lost PDU for SDU-5 91 is identified by SOstart 90k = 0x0100 and SOend 901 = 0x0 IFF (the last byte of the lost PDU). A following UNKNOWN SN 90m is 6 to indicate that some PDUs are under HARQ retransmissions. In this case, an El bit 90o is 0, an E2 bit 90p is 1, an E3 bit 90q is 0, and an R bit 90r is 1 (here, R 90r = 1 indicates an UNKNOWN status). As the E2 bit 90p was set to 1, PDUs for SDU-692 that areOur ref. : 240508EPWOP 35

[0291] Sony Group Corporation

[0292] lost and under HARQ retransmissions are identified by SOstart 90s = 0x0000 and SOend 90t = OxOlFF.

[0293] It is noted that in the embodiment of Fig. 12, during reporting, the t-Reassembly timer has been started because SDU-793 is received successfully, but segments of the middle SDU-692 are missing.

[0294] As described, Fig 12 shows an embodiment of a STATUS PDU 90 in which SDU segments (PDUs) that are, at the time of reporting, stuck in HARQ retransmissions (i.e., for which retransmission is ongoing) are given an UNKNOWN status.

[0295] Fig. 13 illustrates a second embodiment of a STATUS report 100 that indicates an UNKNOWN status. The STATUS report 100 is configured as a STATUS PDU and is an example of the indication that retransmission is ongoing which the Rx node 61 transmits to the Tx node 62 at 66 of Fig. 9.

[0296] In the embodiment of Fig. 13, the Tx node 62 transmits to the Rx node 61 an SDU 101 with SN=8 (SDU-8) and an SDU 102 with SN=9 (SDU-9). After receiving polling information, the Rx node 61 transmits, to the Tx node 62, the STATUS report 100, which indicates a status of the SDU-9 102 that is stuck in HARQ retransmissions at the time of reporting (as indicated by hourglasses).

[0297] The STATUS report 100 of Fig. 13 differs from the STATUS report 90 of Fig. 12 in that SDU segments (PDUs) that are still stuck in HARQ retransmissions (i.e., for which retransmission is ongoing) are part of the last received SDU-9 102, such that a t-Reassembly timer is not running at the time of reporting (i.e., at the time of generating the STATUS report 100). In this case, the SDU-9 102 is reported with an UNKNOWN status by setting the reserved bit lOOr (R=l).

[0298] In detail, in the STATUS report 100, a D / C bit 100a is 0, a CPT field 100b is 0, an ACK_SN 100c is 10, an El bit lOOd is 1, and an R field lOOe is 0. A following firm

[0299] NACK SN lOOf is 8 to indicate the first lost PDU. In this case, an El bit 100g is 1 (to indicate there is another lost PDU following), an E2 bit lOOh is 1, an E3 bit lOOi is 0, and an R bit lOOj is 0 (here, R lOOj = 0 indicates a firm NACK). As the E2 bit lOOh was set to 1, the lost PDU for SDU-8 101 is identified by SOstart 100k = 0x0100 and SOend 1001 = 0x0 IFF (the last byte of the lost PDU). A following UNKNOWN_SN 100m is 9 to indicate that some PDUs are under HARQ retransmissions. In this case, an El bit lOOo is 0, an E2 bit lOOp is 1, an E3 bit lOOq is 0, and an R bit lOOr is 1 (here, R lOOr = 1 indicates an UNKNOWN status). As the E2 bit lOOp was set to 1, PDUs for SDU-9 102 that are lost and under HARQ retransmissions are identified by SOstart 100s = 0x0000 and SOend lOOt = OxOlFF.Our ref. : 240508EPWOP 36

[0300] Sony Group Corporation

[0301] It is noted that in the embodiment of Fig. 13, during reporting, the t-Reassembly timer is not running because the missing segments belong to the last received SDU-9 102.

[0302] It is further noted that, in some embodiments, a STATUS report that is transmitted when a t-Reassembly timer is not running (as in the embodiment of Fig. 13) indicates, for segments for which retransmission is ongoing, a premature NACK status (as in the embodiment of Fig. 11) instead of an UNKNOWN status.

[0303] In some embodiments, at the Rx side, a threshold is defined / specified based on the number of received HARQ retransmissions, or the number of received ARQ retransmissions of RLC SDU / PDUs may be beyond a threshold at the time of reporting, and the threshold triggers to report the SDU or segments of the SDU (i.e., one or more PDUs) that are still stuck in the HARQ retransmissions regardless of whether a t-Reassembly timer is still running (i.e., the HARQ processing may still be ongoing). In other words, the Rx side may ignore the t-Reassembly timer which is still running and may provide a STATUS report for an SDU or segments of an SDU (i.e., one or more PDUs) that are stuck, e.g., in lower layer HARQ retransmissions if the Rx side receives a request of a STATUS report from the Tx side while the t-Reassembly timer is running. The ignoring of the t-Reassembly timer by the Rx side may be done if the Rx side has a corresponding capability (e.g. UE capability). An indication of the capability to ignore the t-Reassembly timber may be informed from the Rx side to the Tx side in advance of the ignoring (e.g., by using UE Capability Information transmitted from the UE to the base station). For example, if the threshold is 2, and the number of received HARQ retransmissions reaches 2, then a status report may be triggered at the Rx side. This embodiment may be combined with the earlier embodiments, as indicated above.

[0304] A further way of indicating a status that corresponds to ongoing retransmission of an SDU segment is to specify a Control PDU Type (CPT) field that may be used to indicate ongoing retransmission of an SDU segment. For example, CPT=001 can be used. In a known NR specification, values of CPT from 001 to 111 are reserved, so any of the reserved values from 001 to 111 may be used in a CPT field for indicating ongoing retransmission of an SDU segment.

[0305] Fig. 14 illustrates an embodiment of a STATUS report 110 in which a CPT field 110b is set to a value different from zero. The STATUS report 110 is configured as a STATUS PDU and is an example of an indication that is transmitted by the Rx node 61 to the Tx node 62 at 66 of Fig. 9. The Tx node 62 has transmitted an SDU 111 with SN=1 and an SDU 112 with SN=2 to the Rx node 61. A PDU that includes a segment of the SDU 111 at an SO from 0x0100 to 0x0 IFF isOur ref. : 240508EPWOP 37

[0306] Sony Group Corporation

[0307] lost. A PDU that includes a segment of the SDU 112 at an SO from 0x0200 to 0x02FF is lost, and retransmission of the segment is ongoing based on HARQ according to the MAC protocol (as indicated by an hourglass in Fig. 14).

[0308] The Rx node 61 transmits to the Tx node 62 the STATUS report 110. In the STATUS report 110, a D / C bit 110a is set to 0. Also, in the STATUS report 110, a CPT field 110b is set to 100 (i.e., a first bit of the CPT field 110b is set to 1, and two further bits of the CPT field 110b are set to 0) for indicating that the STATUS report 110 indicates segments for which retransmission is ongoing. Further, in the STATUS report 110, an ACK SN 110c is 3, an El bit 1 lOd is 1 (because an indication of a failed SDU segment follows), and a reserved field 1 lOe is 0.

[0309] With respect to the SDU 111, in the STATUS report 110, a NACK_SN 1 lOf is 1, an El bit 110g is 1 (because a further indication of a failed SDU segment follows), an E2 bit 1 lOh is 1, an E3 bit 1 lOi is 0, a reserved bit 1 lOj is 0 (for indicating a firm NACK for the SDU 111), an SOstart 110k is 0x0100, and an SOend 1101 is OxlFF.

[0310] With respect to the SDU 112, in the STATUS report 110, a NACK_SN 110m is 2, an El bit 1 lOo is 0 (because no further indication of a failed SDU segment follows), an E2 bit 11 Op is 1, an E3 bit 1 lOq is 0, a reserved bit 11 Or is 1 (for indicating a premature NACK for the SDU 112), an SOstart 110s is 0x0200, and an SOend 1 lOt is 0x02FF.

[0311] Accordingly, in the embodiment of Fig. 14, the indication that retransmission of a segment is ongoing includes setting, in the STATUS report 110, a CPT to a predetermined value different from zero, and includes setting, in the STATUS report 100, a reserved bit (i.e., reserved bit 1 lOr) that is associated with the segment and, thus, associated with a data unit (i.e., SDU 112) to which the segment belongs.

[0312] It is noted that, in some embodiments, any other value than “100” may be used for the CPT field 120b as long as it is different from “000”.

[0313] Fig. 15 illustrates an embodiment of a STATUS report 120 in which a reserved bit is set that is associated with an ACK SN. The STATUS report 120 is configured as a STATUS PDU and is an example of an indication that is transmitted by the Rx node 61 to the Tx node 62 at 66 of Fig. 9.

[0314] The STATUS report 120 differs from the STATUS report 110 of Fig. 14 in that a reserved bit of a reserved field 120e that is associated with an ACK_SN 120c is set instead of setting a CPT field 120b to a value different from zero.Our ref. : 240508EPWOP 38

[0315] Sony Group Corporation

[0316] The Tx node 62 has transmitted an SDU 121 with SN=1 and an SDU 122 with SN=2 to the Rx node 61. A PDU that includes a segment of the SDU 121 at an SO from 0x0100 to OxOlFF is lost. A PDU that includes a segment of the SDU 122 at an SO from 0x0200 to 0x02FF is lost, and retransmission of the segment is ongoing based on HARQ according to the MAC protocol (as indicated by an hourglass in Fig. 15).

[0317] The Rx node 61 transmits to the Tx node 62 the STATUS report 120. In the STATUS report 120, a D / C bit 120a is set to 0, a CPT field 120b is set to “000” (i.e., three bits set to zero), an ACK SN 120c is 3, an El bit 120d is 1 (because an indication of a failed SDU segment follows), and a reserved field 120e is “1000000” (a reserved bit of the reserved field 120e is 1, and further bits of the reserved field 120e is 0) for indicating that the STATUS report 120 indicates segments for which retransmission is ongoing.

[0318] With respect to the SDU 121, in the STATUS report 120, a NACK_SN 120f is 1, an El bit 120g is 1 (because a further indication of a failed SDU segment follows), an E2 bit 120h is 1, an E3 bit 120i is 0, a reserved bit 120j is 0 (for indicating a firm NACK for the SDU 121), an SOstart 120k is 0x0100, and an SOend 1201 is OxlFF.

[0319] With respect to the SDU 122, in the STATUS report 120, a NACK_SN 120m is 2, an El bit 120o is 0 (because no further indication of a failed SDU segment follows), an E2 bit 120p is 1, an E3 bit 120q is 0, a reserved bit 120r is 1 (for indicating a premature NACK for the SDU 122), an SOstart 120s is 0x0200, and an SOend 120t is 0x02FF.

[0320] Accordingly, in the embodiment of Fig. 15, the indication that retransmission of a segment is ongoing includes setting, in the STATUS report 120, a reserved bit (within the reserved field 120e) that is associated with an acknowledgement sequence number (the ACK_SN 120c), and includes setting, in the STATUS report 120, the reserved bit 120r that is associated with the segment (via the NACK_SN 120m, the SOstart 120s and the SOend 120t) and, thus, with the SDU 122.

[0321] It is noted that, in some embodiments, any other value than “1000000” may be used for the reserved field 120e as long as it is different from “0000000” (i.e., as long as one or more (reserved) bits of the reserved field 120e are set to 1).

[0322] It is further noted that, in some embodiments, the STATUS reports 110 and 120 of Fig. 14 and 15, respectively, report an UNKNOWN status for the SDUs 112 and 122, respectively, instead of a premature NACK status, as shown in Fig. 12 and 13.Our ref. : 240508EPWOP 39

[0323] Sony Group Corporation

[0324] It is also noted that, in some embodiments, a STATUS report that reports an UNKNOWN status or a premature NACK status, as shown in Fig. 11 to 15, an E3 bit may be set for using a NACK_Range, wherein an E2 bit may be 0, similar to the case shown in Fig. 5, or an E2 bit may be 1, similar to the case shown in Fig. 7.

[0325] It is further noted that, in some embodiments, a reserved bit associated with a segment may be 0 for indicating a premature NACK status or an UNKNOWN status, and may be 1 for indicating a firm NACK status (i.e., a value of the reserved bit may be inverted as compared to the reserved bits 80j, 80r, 90j, 90r, lOOj, lOOr, HOj, HOr, 120j and / or 120r of Fig. 11 to 15, respectively. Further, the embodiments of Fig. 14 (setting a CPT field to a value different from zero) and of Fig. 15 (setting a reserved bit associated with an ACK_SN) may be combined.

[0326] Moreover, in some embodiments, setting a CPT field to a value different from zero (similar to the embodiment of Fig. 14) and / or setting a reserved bit associated with an ACK SN (similar to the embodiment of Fig. 15) may indicate that all SDUs indicated by a NACK SN have a premature NACK status or an UNKNOWN status, respectively, such that a reserved bit associated with a segment (such as the reserved bits 80j, 80r, 90j, 90r, lOOj, lOOr, 1 lOj, 1 lOr, 120j and / or 120r of Fig. 11 to 15, respectively) may not be used or may be used for other purposes than indicating ongoing transmissions.

[0327] Fig. 16 illustrates a third embodiment of a method 130. The method 130 is an example of a method that is performed by the Rx node 61.

[0328] At 131, an RLC layer of the Rx node 61 receives SDUs (which are examples of data units). The receiving of SDUs at 131 is an example of the processing at 64 of Fig. 9.

[0329] At 132, the Rx node 61 triggers a status report. The triggering of the status report is an example of the processing at 72 of Fig. 10.

[0330] At 133, the Rx node 61 detects a reception failure of a PDU that includes a segment of an SDU received at 131. The detection of the reception failure at 133 corresponds to the trigger criterion 72c of Fig. 10.

[0331] At 134, the Rx node 61 determines that a t-Reassembly timer is running. Based on the determination that the t-Reassembly timer is running, the Rx node 61 determines that HARQ retransmission of a PDU is ongoing, which is an example of the processing at 65 of Fig. 9. At 135, the Rx node 61 further receives a set polling bit (i.e., a polling bit set to 1 in a PDU) from the Tx node 62. The receiving of the set polling bit at 135 is an example of the status request 72a of Fig. 10.Our ref. : 240508EPWOP 40

[0332] Sony Group Corporation

[0333] At 136, the Rx node 61 determines a status for SDUs / PDUs for the status report. The Rx node 61 determines successfully received SDUs / PDUs 136a and assigns them an ACK status in the status report. The Rx node 61 determines failed received SDUs / PDUs 136b and assigns them a (firm) NACK status in the status report. The Rx node 61 determines missing PDUs 136c that are stuck in lower layer HARQ retransmissions and assigns them a premature NACK status (in some embodiments, the Rx node 61 assigns an UNKNOWN status instead of a premature NACK status to the missing PDUs 136c).

[0334] At 137, the Rx node 61 determines that a t-StatusProhibit timer is set to zero or is expired.

[0335] At 138, the Rx node 61 prepares and sends the status PDU to the Tx node 62. The sending of the status PDU is an example of the transmitting of the indication at 66 of Fig. 9.

[0336] Thus, the method 130 includes determining, at the RLC Rx side (i.e., by the Rx node 61) the missing PDUs and assigning to them a premature NACK or UNKNOWN status so that the Tx side (i.e., the Tx node 62) can retransmit the missing PDUs, e.g., if a remaining lifetime of the SDU is very short (such as for the trigger criterion 72h of Fig. 10). It is noted that, as defined in a known NR specification, if the Rx node 61 receives some PDUs that have already been received before, the Rx node 61 may discard the duplicated PDUs.

[0337] Fig. 17 illustrates a fourth embodiment of a method 140. The method 140 is an example of processing performed by the Rx node 61 in some embodiments.

[0338] At 141, the Rx node 61 triggers a status report. The processing at 141 is an example of the triggering at 72 of Fig. 10 and of the triggering at 132 of Fig. 16.

[0339] At 142, the Rx node 61 determines whether an associated t-StatusProhibit timer is running. If the t-StatusProhibit timer is not running, the Rx node 61 prepares and sends a status PDU at 143. The processing at 143 is an example of the transmitting at 66 of Fig. 9 and of the processing at 138 of Fig. 16.

[0340] However, if the Rx node 61 determines at 142 that the t-StatusProhibit timer is running, the Rx node 61 determines at 144 whether to report the status anyway, although the t-StatusProhibit timer is running. If a criterion for bypassing the t-StatusProhibit timer is satisfied (e.g., a service criterion such as 71a, 71b or 71c of Fig. 10, or a trigger criterion such as 72g, 72h, 72i etc. of Fig. 10), the Rx node 61 prepares and sends the status PDU (an example of an indication that retransmission of a segment (e.g., of a PDU) is ongoing) at 143 while the associated t-StatusProhibit timer is running.Our ref. : 240508EPWOP 41

[0341] Sony Group Corporation

[0342] Thus, in some embodiments, a Rx side (e.g., UE) reports, e.g., in a STATUS report, segments of a SDU (e.g., one or more PDUs) that are stuck in lower layer HARQ retransmissions when the Rx side receives a request of a STATUS report from its Tx side (e.g., polling information), regardless of whether a t-Reassembly timer is running.

[0343] In some embodiments, the segments of the SDU (e.g., one or more PDUs) that are stuck in the HARQ retransmissions are given a premature NACK status in the report.

[0344] In some embodiments, the premature NACK status is indicated by a reserved bit set to 1.

[0345] In some embodiments, the segments of the SDU (e.g., one or more PDUs) that are stuck in the HARQ retransmissions are given an UNKNOWN status in the report.

[0346] In some embodiments, the UNKNOWN status is indicated by the reserved bit set to 1.

[0347] In some embodiments, the Tx side can retransmit the segments of the SDU (e.g., one or more PDUs) that have a premature NACK status in the report.

[0348] In some embodiments, the Tx side can retransmit the segments of the SDU (e.g., one or more PDUs) that have an UNKNOWN status in the report.

[0349] In some embodiments, the Rx side employs a threshold that is based on the number of received HARQ retransmissions to trigger the status report of the SDU or segments of the SDU (e.g., one or more PDUs) that are still stuck in the HARQ retransmissions.

[0350] In some embodiments, the Rx side employs a threshold that is based on the number of received ARQ retransmissions to trigger the status report of the SDU or segments of the SDU (e.g., one or more PDUs) that are still under ARQ retransmissions.

[0351] In some instances of a legacy NR specification (e.g., up to Rel-18), polling information is sent from a Tx side, and a Rx side responds with a status request based on the polling information, to send the status of the received SDUs or segments of the SDU (one or more PDUs). In some instances of a legacy NR specification, the Rx side does not send the status report if the lower HARQ retransmissions are still ongoing or if the t-Reassembly timer is running, to avoid premature NACKs.

[0352] In some embodiments of the present technology, as described above, the status report of the received SDUs or segments of the SDU (one or more PDUs) that are stuck in the lower layer HARQ retransmissions is provided regardless of whether the t-Reassembly timer is running. The report may identify the SDUs as one of ACK, firm NACK, and premature NACK (or UNKNOWN) status for the received SDUs / segments so that the Tx side may become aware thatOur ref. : 240508EPWOP 42

[0353] Sony Group Corporation

[0354] these PDUs are still under process at the Rx side. The Tx side can retransmit them, e.g., if the remaining lifetime of the SDU is very short. RRC configuration may enable or disable whether to include a premature NACK or UNKNOWN status in a status report for a particular radio bearer / service.

[0355] In some embodiments, the Rx side is configured as a base station.

[0356] In the following, polling information as in a known NR specification (TS 38.322 V18.1.0) is described.

[0357] 5.3.3 Polling

[0358] 5.3.3.1 General

[0359] An AM RLC entity can poll its peer AM RLC entity in order to trigger STATUS reporting at the peer AM RLC entity.

[0360] 5.3.3.2 Transmission of a AMD PDU

[0361] Upon notification of a transmission opportunity by lower layer, for each AMD PDU submitted for transmission such that the AMD PDU contains either a not previously transmitted RLC SDU or an RLC SDU segment containing not previously transmitted byte segment, the transmitting side of an AM RLC entity shall:

[0362] • increment PDU WITHOUT POLL by one;

[0363] • increment BYTE WITHOUT POLL by every new byte of Data field element that it maps to the Data field of the AMD PDU;

[0364] • if PDU WITHOUT POLL >= pollPDU; or

[0365] • if B YTE WITHOUT POLL >= pollByte:

[0366] o include a poll in the AMD PDU as described below.

[0367] Upon notification of a transmission opportunity by lower layer, for each AMD PDU submitted for transmission, the transmitting side of an AM RLC entity shall:

[0368] • if both the transmission buffer and the retransmission buffer becomes empty (excluding transmitted RLC SDUs or RLC SDU segments awaiting acknowledgements) after the transmission of the AMD PDU; or

[0369] • if no new RLC SDU can be transmitted after the transmission of the AMD PDU (e.g. due to window stalling);Our ref. : 240508EPWOP 43

[0370] Sony Group Corporation

[0371] o include a poll in the AMD PDU as described below.

[0372] NOTE: Empty RLC buffer (excluding transmitted RLC SDUs or RLC SDU segments awaiting acknowledgements) should not lead to unnecessary polling when data awaits in the upper layer. Details are left up to UE implementation.

[0373] To include a poll in an AMD PDU, the transmitting side of an AM RLC entity shall:

[0374] • set the P field of the AMD PDU to " 1 " ;

[0375] • set PDU WITHOUT POLL to 0;

[0376] • set BYTE WITHOUT POLL to 0.

[0377] Upon submission of an AMD PDU including a poll to lower layer, the transmitting side of an AM RLC entity shall:

[0378] • set POLL SN to the highest SN of the AMD PDU among the AMD PDUs submitted to lower layer;

[0379] • if t-PollRetransmit is not running:

[0380] o start t-PollRetransmit.

[0381] • else:

[0382] o restart t-PollRetransmit.

[0383] 5.3.3.3 Reception of a STATUS report

[0384] Upon reception of a STATUS report from the receiving RLC AM entity the transmitting side of an AM RLC entity shall:

[0385] • if the STATUS report comprises a positive or negative acknowledgement for the RLC SDU with sequence number equal to POLL SN:

[0386] o if t-PollRetransmit is running:

[0387] ■ stop and reset t-PollRetransmit.

[0388] 5.3.3.4 Expiry of t-PollRetransmit

[0389] Upon expiry of t-PollRetransmit, the transmitting side of an AM RLC entity shall:

[0390] • if both the transmission buffer and the retransmission buffer are empty (excluding transmitted RLC SDU or RLC SDU segment awaiting acknowledgements); orOur ref.: 240508EPWOP 44

[0391] Sony Group Corporation

[0392] • if no new RLC SDU or RLC SDU segment can be transmitted (e.g. due to window stalling):

[0393] o consider the RLC SDU with the highest SN among the RLC SDUs submitted to lower layer for retransmission; or

[0394] o consider any RLC SDU which has not been positively acknowledged for retransmission.

[0395] • include a poll in an AMD PDU as described in clause 5.3.3.2.

[0396] 5.3.4 Status reporting

[0397] An AM RLC entity sends STATUS PDUs to its peer AM RLC entity in order to provide positive and / or negative acknowledgements of RLC SDUs (or portions of them).

[0398] Triggers to initiate STATUS reporting include:

[0399] • Polling from its peer AM RLC entity:

[0400] o When an AMD PDU with SN = x and the P field set to " 1 " is received from lower layer, the receiving side of an AM RLC entity shall:

[0401] ■ if the AMD PDU is to be discarded as specified in clause 5.2.3.2.2; or ■ if x < RX_Highest_Status or x >= RX_Next + AM_Window_Size:

[0402] • trigger a STATUS report.

[0403] ■ else:

[0404] • delay triggering the STATUS report until x < RX Highest Status or x >= RX_Next + AM_Window_Size.

[0405] NOTE 1 : This ensures that the RLC Status report is transmitted after HARQ reordering.

[0406] • Detection of reception failure of an AMD PDU

[0407] o The receiving side of an AM RLC entity shall trigger a STATUS report when t- Reassembly expires.

[0408] NOTE 2: The expiry of t-Reassembly triggers both RX Highest Status to be updated and a STATUS report to be triggered, but the STATUS report shall be triggered after

[0409] RX Highest Status is updated.

[0410] When STATUS reporting has been triggered, the receiving side of an AM RLC entity shall:

[0411] • if t-StatusProhibit is not running:Our ref. : 240508EPWOP 45

[0412] Sony Group Corporation

[0413] o at the first transmission opportunity indicated by lower layer, construct a STATUS PDU and submit it to lower layer.

[0414] • else:

[0415] o at the first transmission opportunity indicated by lower layer after t-StatusProhibit expires, construct a single STATUS PDU even if status reporting was triggered several times while t-StatusProhibit was running and submit it to lower layer. When a STATUS PDU has been submitted to lower layer, the receiving side of an AM RLC entity shall:

[0416] • start t-StatusProhibit.

[0417] When constructing a STATUS PDU, the AM RLC entity shall:

[0418] • for the RLC SDUs with SN such that RX Next <= SN < RX Highest Status that has not been completely received yet, in increasing SN order of RLC SDUs and increasing byte segment order within RLC SDUs, starting with SN = RX_Next up to the point where the resulting STATUS PDU still fits to the total size of RLC PDU(s) indicated by lower layer:

[0419] o for an RLC SDU for which no byte segments have been received yet:

[0420] ■ include in the STATUS PDU a NACK_SN which is set to the SN of the RLC SDU.

[0421] o for a continuous sequence of byte segments of a partly received RLC SDU that have not been received yet:

[0422] ■ include in the STATUS PDU a set of NACK SN, SOstart and SOend. o for a continuous sequence of RLC SDUs that have not been received yet:

[0423] ■ include in the STATUS PDU a set of NACK_SN and NACK range;

[0424] ■ include in the STATUS PDU, if required, a pair of SOstart and SOend. • set the ACK SN to the SN of the next not received RLC SDU which is not indicated as missing in the resulting STATUS PDU.

[0425] At least part of the present disclosure can be combined with at least one aspect of the above NR specification. For example, in case of “Detection of reception failure of an AMD PDU” in Section of 5.3.4 Status reporting, the present disclosure herein may be defined as following:

[0426] • Detection of reception failure of an AMD PDUOur ref.: 240508EPWOP 46

[0427] Sony Group Corporation

[0428] o The receiving side of an AM RLC entity shall trigger a STATUS report when t- Reassembly expires, or

[0429] o The receiving side of an AM RLC entity shall / may trigger a STATUS report regardless of whether a t-Reassembly timer is still running if the AMD PDU(s) are still stuck in the HARQ retransmissions.

[0430] Alternatively, in case of “Detection of reception failure of an AMD PDU” in Section of 5.3.4 Status reporting, the present disclosure herein may be defined as following:

[0431] • Detection of reception failure of an AMD PDU

[0432] o The receiving side of an AM RLC entity shall trigger a STATUS report when t- Reassembly expires, or

[0433] o The receiving side of an AM RLC entity may ignore the t-Reassembly timer which is still running and trigger a STATUS report if the receiving side of an AM RLC entity has a corresponding capability.

[0434] Fig. 18 illustrates a user equipment (UE) and a base station (BS) according to an embodiment. An embodiment of a UE 200 according to the present disclosure (e.g., the UEs 52 or 53 of Fig. 8), a base station (BS) 201 according to the present disclosure (e.g., NR gNB such as the base station 51 of Fig. 8), and a communication path 202 between the UE 200 and the BS 201, which are used for implementing embodiments of the present disclosure, is discussed under reference of Fig. 18.

[0435] The UE 200 has a transmitter 203, a receiver 204 and a controller 205, wherein, generally, the technical functionality of the transmitter 203, the receiver 204 and the controller 205 are known to the skilled person, and, thus, a more detailed description of these elements is omitted.

[0436] The BS 201 has a transmitter 206, a receiver 207 and a controller 208, wherein, generally, the technical functionality of the transmitter 206, the receiver 207 and the controller 208 are known to the skilled person, and, thus, a more detailed description of these elements is omitted.

[0437] The communication path 202 has an uplink path 202a, which is from the UE 200 to the BS 201, and a downlink path 202b, which is from the BS 201 to the UE 200. The communication path 202 allows a transmission of data units (e.g., SDUs), segments of data units (e.g., PDUs), status requests (e.g., PDUs with a polling bit set to 1), indications that retransmission is ongoing (e.g., STATU PDUs) according to the present disclosure. The communication path 202 is an example of the radio links 55 or 56 of Fig. 8.Our ref.: 240508EPWOP 47

[0438] Sony Group Corporation

[0439] During operation, the controller 205 of the UE 200 controls the reception of downlink signals over the downlink path 202b at the receiver 204 and the controller 205 controls the transmission of uplink signals over the uplink path 202a via the transmitter 203.

[0440] Similarly, during operation, the controller 208 of the BS 201 controls the reception of uplink signals over the uplink path 202a at the receiver 207 and the controller 208 controls the transmission of downlink signals over the downlink path 202b via the transmitter 206.

[0441] Fig. 19 illustrates an embodiment of a general -purpose computer 150. The general -purpose computer 150 can be implemented such that it can basically function as any type of user equipment, base station, Rx node, Tx node, smartphone, smart glasses, head-mounted display, smartwatch, mobile phone, mobile tablet, notebook, terminal device or the like, for example, as the UE 52, the UE 53 or the base station 51 of Fig. 8, or the Rx node 61 or the Tx node 62 of Fig. 9. The general -purpose computer 150 is an example of an information processing apparatus that includes circuitry that is configured to perform the methods according to the present technology (e.g., the methods of Fig. 9, 10, 16 or 17). The computer has components 151 to 161, which can form a circuitry, such as the circuitry included in any one of the base station 51, the UE 52, the UE 53, the Rx node 61, the Tx node 62, the UE 200 or the BS 201, or the like, as described herein.

[0442] Embodiments which use software, firmware, programs or the like for performing the methods as described herein can be installed on computer 150, which is then configured to be suitable for the concrete embodiment.

[0443] The computer 150 has a CPU 151 (Central Processing Unit), which can execute various types of procedures and methods as described herein, for example, in accordance with programs stored in a read-only memory (ROM) 152, stored in a storage 157 and loaded into a random-access memory (RAM) 153, stored on a medium 160 which can be inserted in a respective drive 159, etc.

[0444] The CPU 151, the ROM 152 and the RAM 153 are connected with a bus 161, which in turn is connected to an input / output interface 154. The number of CPUs, memories and storages is only exemplary, and the skilled person will appreciate that the computer 150 can be adapted and configured accordingly for meeting specific requirements which arise when it functions as an information processing apparatus according to the present technology.

[0445] At the input / output interface 154, several components are connected: an input 155, an output 156, the storage 157, a communication interface 158 and the drive 159, into which aOur ref.: 240508EPWOP 48

[0446] Sony Group Corporation

[0447] medium 160 (compact disc (CD), digital video disc (DVD), universal serial bus (USB) flash drive, secure digital (SD) card, CompactFlash (CF) memory, or the like) can be inserted.

[0448] The input 155 can be a pointer device (mouse, graphic table, or the like), a keyboard, a microphone, a camera, a touchscreen, an eye-tracking unit etc.

[0449] The output 156 can have a display (liquid crystal display (LCD), cathode ray tube (CRT) display, light-emitting diode (LED) display, electronic paper, etc.; e.g., included in a touchscreen), loudspeakers, etc.

[0450] The storage 157 can have a hard disk drive (HDD), a solid-state drive (SSD), a flash drive and the like.

[0451] The communication interface 158 can be adapted to communicate, for example, via universal serial bus (USB), a serial port (RS-232), parallel port (IEEE 1284), a local area network (LAN; e.g., ethemet), wireless local area network (WLAN; e.g., Wi-Fi, IEEE 802.11), mobile telecommunications system (GSM, UMTS, LTE, NR etc.), Bluetooth, near-field communication (NFC), ZigBee, infrared, etc.

[0452] It should be noted that the description above only pertains to an example configuration of computer 150. Alternative configurations may be implemented with additional or other sensors, storage devices, interfaces or the like. For example, the communication interface 158 may support other radio access technologies than the mentioned UMTS, LTE and NR.

[0453] It is noted that embodiments disclosed herein may still work if a t-Reassembly timer is disabled or set to zero.

[0454] Although Fig. 11 to 15 show a 12-bit SN and 1024-byte SDUs segmented equally into four 256-byte segments, the disclosure is not limited to these values. The SN may also have a different length (e.g., 18 bit, or any other suitable length). An SDU may also have a different length than 1024 bytes and may be segmented into more or less than four segments, or may not be segmented at all but entirely included in a single PDU. The SDU segments may have different lengths than 256 bytes, and the segment length may be equal or vary between SDU segments. It should be recognized that the embodiments describe methods with an exemplary ordering of method steps. The specific ordering of method steps is however given for illustrative purposes only and should not be construed as binding. For example, the ordering of 132 and 135 in the embodiment of Fig. 16 may be exchanged. Also, the ordering of 136 and 137 in the embodiment of Fig. 16 may be exchanged. Other changes of the ordering of method steps may be apparent to the skilled person.Our ref.: 240508EPWOP 49

[0455] Sony Group Corporation

[0456] Please note that the division of the UE 200 into units 203 to 205 and of the BS 201 into units 206 to 208 is only made for illustration purposes and that the present disclosure is not limited to any specific division of functions in specific units. For instance, the UE 200 and the BS 201 could be implemented by a respective programmed processor, field programmable gate array (FPGA) and the like.

[0457] The methods disclosed herein can also be implemented as a computer program causing a computer and / or a processor to perform the method, when being carried out on the computer and / or processor. In some embodiments, also a non-transitory computer-readable recording medium is provided that stores therein a computer program product, which, when executed by a processor, such as the processor described above, causes the method described to be performed. All units and entities described in this specification and claimed in the appended claims can, if not stated otherwise, be implemented as integrated circuit logic, for example on a chip, and functionality provided by such units and entities can, if not stated otherwise, be implemented by software.

[0458] In so far as the embodiments of the disclosure described above are implemented, at least in part, using software-controlled data processing apparatus, it will be appreciated that a computer program providing such software control and a transmission, storage or other medium by which such a computer program is provided are envisaged as aspects of the present disclosure.

[0459] Note that the present technology can also be configured as described below.

[0460] (1) Circuitry for mobile telecommunications, configured to:

[0461] receive, from a transmission node, a data unit including at least one segment; and transmit, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing.

[0462] (2) The circuitry of (1),

[0463] wherein the data unit is configured as a Service Data Unit.

[0464] (3) The circuitry of (1) or (2),

[0465] wherein the at least one segment of the data unit is included in a Protocol Data Unit. (4) The circuitry of any one of (1) to (3),

[0466] wherein the transmission node transmits the data unit according to a Radio Link Control protocol.

[0467] (5) The circuitry of any one of (1) to (4),

[0468] wherein the transmission node transmits the data unit in an acknowledged mode.Our ref. : 240508EPWOP 50

[0469] Sony Group Corporation

[0470] (6) The circuitry of any one of (1) to (5),

[0471] wherein the transmitting of the indication is based on a Radio Link Control protocol. (7) The circuitry of any one of (1) to (6),

[0472] wherein the indication is included in a Protocol Data Unit.

[0473] (8) The circuitry of any one of (1) to (7),

[0474] wherein the indication is included in a STATUS report.

[0475] (9) The circuitry of (8),

[0476] wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the segment of the data unit.

[0477] (10) The circuitry of (8) or (9),

[0478] wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the data unit.

[0479] (11) The circuitry of any one of (8) to (10),

[0480] wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with an acknowledgement sequence number.

[0481] (12) The circuitry of any one of (8) to (11),

[0482] wherein the indication includes setting, in the STATUS report, a Control Protocol Data Unit Type to a predetermined value different from zero.

[0483] (13) The circuitry of any one of (1) to (12),

[0484] wherein the indication includes reporting, as a status of the segment, a status that is different from a positively acknowledged status and from a negatively acknowledged status. (14) The circuitry of (13),

[0485] wherein the status corresponds to a premature negatively acknowledged status.

[0486] (15) The circuitry of (13),

[0487] wherein the status corresponds to an unknown status.

[0488] (16) The circuitry of any one of (1) to (15),

[0489] wherein the retransmission is based on a lower protocol layer than a protocol layer of the data unit.

[0490] (17) The circuitry of (16),

[0491] wherein the retransmission is based on a Media Access Control protocol.Our ref. : 240508EPWOP 51

[0492] Sony Group Corporation

[0493] (18) The circuitry of (16) or (17),

[0494] wherein the retransmission is based on Hybrid Automatic Repeat Request.

[0495] (19) The circuitry of any one of (1) to (18), further configured to:

[0496] determine that retransmission of the segment is ongoing based on a determination that an associated retransmission timer is running.

[0497] (20) The circuitry of (19),

[0498] wherein the retransmission timer is configured as a t-Reassembly timer.

[0499] (21) The circuitry of any one of (1) to (20), further configured to:

[0500] trigger the transmitting of the indication based on a request from the transmission node. (22) The circuitry of (21),

[0501] wherein the request corresponds to polling information.

[0502] (23) The circuitry of (21) or (22),

[0503] wherein the request includes setting a polling bit of a Protocol Data Unit according to a Radio Link Control protocol.

[0504] (24) The circuitry of any one of (1) to (23), further configured to:

[0505] trigger the transmitting of the indication based on a determination that a number of received retransmissions of the segment exceeds a threshold.

[0506] (25) The circuitry of any one of (1) to (24), further configured to:

[0507] trigger the transmitting of the indication based on detecting a gap in a sequence between successfully received Protocol Data Units.

[0508] (26) The circuitry of any one of (1) to (25), further configured to:

[0509] trigger the transmitting of the indication based on a determination that a later data unit with a higher sequence number than the data unit has been successfully received.

[0510] (27) The circuitry of any one of (1) to (26), further configured to:

[0511] trigger the transmitting of the indication based on a determination that a segment of a later data unit with a higher sequence number than the data unit has been successfully received. (28) The circuitry of any one of (1) to (27), further configured to:

[0512] trigger the transmitting of the indication based on a determination that a later segment of the data unit at a higher segment offset than the segment has been successfully received.Our ref. : 240508EPWOP 52

[0513] Sony Group Corporation

[0514] (29) The circuitry of any one of (1) to (28), further configured to:

[0515] trigger the transmitting of the indication based on a determination that a number of segments of the data unit for which retransmission is ongoing exceeds a threshold.

[0516] (30) The circuitry of any one of (1) to (29), further configured to:

[0517] trigger the transmitting of the indication based on a remaining Packet Delay Budget associated with the data unit.

[0518] (31) The circuitry of any one of (1) to (30), further configured to:

[0519] trigger the transmitting of the indication based on granted resources that are available for the retransmission.

[0520] (32) The circuitry of any one of (1) to (31), further configured to:

[0521] trigger the transmitting of the indication based on a determination that a data amount received since a first transmission of the segment exceeds a threshold.

[0522] (33) The circuitry of any one of (1) to (32), further configured to:

[0523] trigger the transmitting of the indication based on a determination that a time elapsed since a first transmission of the segment exceeds a threshold.

[0524] (34) The circuitry of any one of (1) to (33), further configured to:

[0525] trigger the transmitting of the indication based on a determination that a number of Protocol Data Units that need to be retransmitted exceeds a threshold.

[0526] (35) The circuitry of any one of (1) to (34), further configured to:

[0527] transmit the indication based on a determination of a service to which the data unit corresponds.

[0528] (36) The circuitry of (35),

[0529] wherein the determination of the service includes determining that the service requires a predetermined minimum data rate.

[0530] (37) The circuitry of (35) or (36),

[0531] wherein the determination of the service includes determining that the service requires a predetermined maximum latency.

[0532] (38) The circuitry of any one of (35) to (37),

[0533] wherein the determination of the service includes determining that the service includes an extended Reality service.Our ref. : 240508EPWOP 53

[0534] Sony Group Corporation

[0535] (39) The circuitry of any one of (1) to (38),

[0536] wherein Radio Resource Control is configured to control whether to transmit the indication that the retransmission is ongoing.

[0537] (40) The circuitry of any one of (1) to (39), further configured to:

[0538] transmit the indication while an associated t-StatusProhibit timer is running.

[0539] (41) A user equipment for mobile telecommunications, comprising the circuitry of any one of (l) to (40).

[0540] (42) A base station for mobile telecommunications, comprising the circuitry of any one of (1) to (40).

[0541] (43) A method for mobile telecommunications, comprising:

[0542] receiving, from a transmission node, a data unit including at least one segment; and transmitting, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing.

[0543] (44) The method of (43),

[0544] wherein the data unit is configured as a Service Data Unit.

[0545] (45) The method of (43) or (44),

[0546] wherein the at least one segment of the data unit is included in a Protocol Data Unit. (46) The method of any one of (43) to (45),

[0547] wherein the transmission node transmits the data unit according to a Radio Link Control protocol.

[0548] (47) The method of any one of (43) to (46),

[0549] wherein the transmission node transmits the data unit in an acknowledged mode.

[0550] (48) The method of any one of (43) to (47),

[0551] wherein the transmitting of the indication is based on a Radio Link Control protocol. (49) The method of any one of (43) to (48),

[0552] wherein the indication is included in a Protocol Data Unit.

[0553] (50) The method of any one of (43) to (49),

[0554] wherein the indication is included in a STATUS report.

[0555] (51) The method of (50),

[0556] wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the segment of the data unit.Our ref. : 240508EPWOP 54

[0557] Sony Group Corporation

[0558] (52) The method of (50) or (51),

[0559] wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the data unit.

[0560] (53) The method of any one of (50) to (52),

[0561] wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with an acknowledgement sequence number.

[0562] (54) The method of any one of (50) to (53),

[0563] wherein the indication includes setting, in the STATUS report, a Control Protocol Data Unit Type to a predetermined value different from zero.

[0564] (55) The method of any one of (43) to (54),

[0565] wherein the indication includes reporting, as a status of the segment, a status that is different from a positively acknowledged status and from a negatively acknowledged status. (56) The method of (55),

[0566] wherein the status corresponds to a premature negatively acknowledged status.

[0567] (57) The method of (55),

[0568] wherein the status corresponds to an unknown status.

[0569] (58) The method of any one of (43) to (57),

[0570] wherein the retransmission is based on a lower protocol layer than a protocol layer of the data unit.

[0571] (59) The method of (58),

[0572] wherein the retransmission is based on a Media Access Control protocol.

[0573] (60) The method of (58) or (59),

[0574] wherein the retransmission is based on Hybrid Automatic Repeat Request.

[0575] (61) The method of any one of (43) to (60), further comprising:

[0576] determining that retransmission of the segment is ongoing based on a determination that an associated retransmission timer is running.

[0577] (62) The method of (61),

[0578] wherein the retransmission timer is configured as a t-Reassembly timer.

[0579] (63) The method of any one of (43) to (62), further comprising:

[0580] triggering the transmitting of the indication based on a request from the transmission node.Our ref. : 240508EPWOP 55

[0581] Sony Group Corporation

[0582] (64) The method of (63),

[0583] wherein the request corresponds to polling information.

[0584] (65) The method of (63) or (64),

[0585] wherein the request includes setting a polling bit of a Protocol Data Unit according to a Radio Link Control protocol.

[0586] (66) The method of any one of (43) to (65), further comprising:

[0587] triggering the transmitting of the indication based on a determination that a number of received retransmissions of the segment exceeds a threshold.

[0588] (67) The method of any one of (43) to (66), further comprising:

[0589] triggering the transmitting of the indication based on detecting a gap in a sequence between successfully received Protocol Data Units.

[0590] (68) The method of any one of (43) to (67), further comprising:

[0591] triggering the transmitting of the indication based on a determination that a later data unit with a higher sequence number than the data unit has been successfully received.

[0592] (69) The method of any one of (43) to (68), further comprising:

[0593] triggering the transmitting of the indication based on a determination that a segment of a later data unit with a higher sequence number than the data unit has been successfully received. (70) The method of any one of (43) to (69), further comprising:

[0594] triggering the transmitting of the indication based on a determination that a later segment of the data unit at a higher segment offset than the segment has been successfully received. (71) The method of any one of (43) to (70), further comprising:

[0595] triggering the transmitting of the indication based on a determination that a number of segments of the data unit for which retransmission is ongoing exceeds a threshold.

[0596] (72) The method of any one of (43) to (71), further comprising:

[0597] triggering the transmitting of the indication based on a remaining Packet Delay Budget associated with the data unit.

[0598] (73) The method of any one of (43) to (72), further comprising:

[0599] triggering the transmitting of the indication based on granted resources that are available for the retransmission.Our ref. : 240508EPWOP 56

[0600] Sony Group Corporation

[0601] (74) The method of any one of (43) to (73), further comprising:

[0602] triggering the transmitting of the indication based on a determination that a data amount received since a first transmission of the segment exceeds a threshold.

[0603] (75) The method of any one of (43) to (74), further comprising:

[0604] triggering the transmitting of the indication based on a determination that a time elapsed since a first transmission of the segment exceeds a threshold.

[0605] (76) The method of any one of (43) to (75), further comprising:

[0606] triggering the transmitting of the indication based on a determination that a number of Protocol Data Units that need to be retransmitted exceeds a threshold.

[0607] (77) The method of any one of (43) to (76), further comprising:

[0608] transmitting the indication based on a determination of a service to which the data unit corresponds.

[0609] (78) The method of (77),

[0610] wherein the determination of the service includes determining that the service requires a predetermined minimum data rate.

[0611] (79) The method of (77) or (78),

[0612] wherein the determination of the service includes determining that the service requires a predetermined maximum latency.

[0613] (80) The method of any one of (77) to (79),

[0614] wherein the determination of the service includes determining that the service includes an extended Reality service.

[0615] (81) The method of any one of (43) to (80),

[0616] wherein Radio Resource Control is configured to control whether to transmit the indication that the retransmission is ongoing.

[0617] (82) The method of any one of (43) to (81), further comprising:

[0618] transmitting the indication while an associated t-StatusProhibit timer is running.

[0619] (83) A computer program comprising program code causing a computer to perform the method according to anyone of (43) to (82), when being carried out on a computer.

[0620] (84) A non-transitory computer-readable recording medium that stores therein a computer program product, which, when executed by a processor, causes the method according to anyone of (43) to (82) to be performed.Our ref.: 240508EPWOP 57

[0621] Sony Group Corporation

[0622] (85) Transmission circuitry for mobile telecommunications, configured to communicate with a reception node;

[0623] wherein the reception node includes circuitry according to any one of (1) to (40); wherein the communicating with the reception node comprises:

[0624] transmitting the data unit to the reception node;

[0625] receiving, from the reception node, the indication that retransmission of the segment of the data unit is ongoing; and

[0626] triggering a further retransmission of the segment based on the indication.

[0627] (86) The transmission circuitry of (85), wherein the communicating with the reception node further comprises:

[0628] granting further resources for the retransmission of the segment.

[0629] (87) The transmission circuitry of (86), wherein the granting of the further resources is based on a remaining Packet Delay Budget associated with the data unit.

[0630] (88) The transmission circuitry of any one of (85) to (87),

[0631] wherein the further retransmission is based on Automatic Repeat Request.

[0632] (89) A user equipment for mobile telecommunications, comprising the transmission circuitry of any one of (85) to (88).

[0633] (90) A base station for mobile telecommunications, comprising the transmission circuitry of any one of (85) to (88).

[0634] (91) A method for mobile telecommunications, comprising communicating with a reception node;

[0635] wherein the reception node includes circuitry according to any one of (1) to (40); wherein the communicating with the reception node comprises:

[0636] transmitting the data unit to the reception node;

[0637] receiving, from the reception node, the indication that retransmission of the segment of the data unit is ongoing; and

[0638] triggering a further retransmission of the segment based on the indication.

[0639] (92) The method of (91), wherein the communicating with the reception node further comprises:

[0640] granting further resources for the retransmission of the segment.Our ref.: 240508EPWOP 58

[0641] Sony Group Corporation

[0642] (93) The method of (92),

[0643] wherein the granting of the further resources is based on a remaining Packet Delay Budget associated with the data unit.

[0644] (94) The method of any one of (91) to (93),

[0645] wherein the further retransmission is based on Automatic Repeat Request.

[0646] (95) A computer program comprising program code causing a computer to perform the method according to anyone of (91) to (94), when being carried out on a computer.

[0647] (96) A non-transitory computer-readable recording medium that stores therein a computer program product, which, when executed by a processor, causes the method according to anyone of (91) to (94) to be performed.

Claims

Our ref.: 240508EPWOP 1Sony Group CorporationCLAIMS1. A user equipment for mobile telecommunications, comprising circuitry that is configured to:receive, from a transmission node, a data unit including at least one segment; and transmit, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing.

2. The user equipment of claim 1,wherein the data unit is configured as a Service Data Unit.

3. The user equipment of claim 1,wherein the at least one segment of the data unit is included in a Protocol Data Unit.

4. The user equipment of claim 1,wherein the transmission node transmits the data unit according to a Radio Link Control protocol.

5. The user equipment of claim 1,wherein the transmission node transmits the data unit in an acknowledged mode.

6. The user equipment of claim 1,wherein the transmitting of the indication is based on a Radio Link Control protocol.

7. The user equipment of claim 1,wherein the indication is included in a Protocol Data Unit.

8. The user equipment of claim 1,wherein the indication is included in a STATUS report.

9. The user equipment of claim 8,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the segment of the data unit.

10. The user equipment of claim 8,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the data unit.

11. The user equipment of claim 8,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with an acknowledgement sequence number.Our ref. : 240508EPWOP 2Sony Group Corporation12. The user equipment of claim 8,wherein the indication includes setting, in the STATUS report, a Control Protocol Data Unit Type to a predetermined value different from zero.

13. The user equipment of claim 1,wherein the indication includes reporting, as a status of the segment, a status that is different from a positively acknowledged status and from a negatively acknowledged status.

14. The user equipment of claim 13,wherein the status corresponds to a premature negatively acknowledged status.

15. The user equipment of claim 13,wherein the status corresponds to an unknown status.

16. The user equipment of claim 1,wherein the retransmission is based on a lower protocol layer than a protocol layer of the data unit.

17. The user equipment of claim 16,wherein the retransmission is based on a Media Access Control protocol.

18. The user equipment of claim 16,wherein the retransmission is based on Hybrid Automatic Repeat Request.

19. The user equipment of claim 1, further configured to:determine that retransmission of the segment is ongoing based on a determination that an associated retransmission timer is running.

20. The user equipment of claim 19,wherein the retransmission timer is configured as a t-Reassembly timer.

21. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on a request from the transmission node.

22. The user equipment of claim 21,wherein the request corresponds to polling information.

23. The user equipment of claim 21 ,wherein the request includes setting a polling bit of a Protocol Data Unit according to a Radio Link Control protocol.Our ref. : 240508EPWOP 3Sony Group Corporation24. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on a determination that a number of received retransmissions of the segment exceeds a threshold.

25. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on detecting a gap in a sequence between successfully received Protocol Data Units.

26. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on a determination that a later data unit with a higher sequence number than the data unit has been successfully received.

27. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on a determination that a segment of a later data unit with a higher sequence number than the data unit has been successfully received.

28. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on a determination that a later segment of the data unit at a higher segment offset than the segment has been successfully received.

29. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on a determination that a number of segments of the data unit for which retransmission is ongoing exceeds a threshold.

30. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on a remaining Packet Delay Budget associated with the data unit.

31. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on granted resources that are available for the retransmission.

32. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on a determination that a data amount received since a first transmission of the segment exceeds a threshold.

33. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on a determination that a time elapsed since a first transmission of the segment exceeds a threshold.Our ref. : 240508EPWOP 4Sony Group Corporation34. The user equipment of claim 1, further configured to:trigger the transmitting of the indication based on a determination that a number of Protocol Data Units that need to be retransmitted exceeds a threshold.

35. The user equipment of claim 1, further configured to:transmit the indication based on a determination of a service to which the data unit corresponds.

36. The user equipment of claim 35,wherein the determination of the service includes determining that the service requires a predetermined minimum data rate.

37. The user equipment of claim 35,wherein the determination of the service includes determining that the service requires a predetermined maximum latency.

38. The user equipment of claim 35,wherein the determination of the service includes determining that the service includes an extended Reality service.

39. The user equipment of claim 1,wherein Radio Resource Control is configured to control whether to transmit the indication that the retransmission is ongoing.

40. The user equipment of claim 1, further configured to:transmit the indication while an associated t-StatusProhibit timer is running.

41. A base station for mobile telecommunications, comprising circuitry that is configured to:receive, from a transmission node, a data unit including at least one segment; and transmit, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing.

42. The base station of claim 41,wherein the data unit is configured as a Service Data Unit.

43. The base station of claim 41,wherein the at least one segment of the data unit is included in a Protocol Data Unit.

44. The base station of claim 41,wherein the transmission node transmits the data unit according to a Radio Link Control protocol.Our ref. : 240508EPWOP 5Sony Group Corporation45. The base station of claim 41,wherein the transmission node transmits the data unit in an acknowledged mode.

46. The base station of claim 41,wherein the transmitting of the indication is based on a Radio Link Control protocol.

47. The base station of claim 41,wherein the indication is included in a Protocol Data Unit.

48. The base station of claim 41,wherein the indication is included in a STATUS report.

49. The base station of claim 48,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the segment of the data unit.

50. The base station of claim 48,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the data unit.

51. The base station of claim 48,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with an acknowledgement sequence number.

52. The base station of claim 48,wherein the indication includes setting, in the STATUS report, a Control Protocol Data Unit Type to a predetermined value different from zero.

53. The base station of claim 41,wherein the indication includes reporting, as a status of the segment, a status that is different from a positively acknowledged status and from a negatively acknowledged status.

54. The base station of claim 53,wherein the status corresponds to a premature negatively acknowledged status.

55. The base station of claim 53,wherein the status corresponds to an unknown status.

56. The base station of claim 41,wherein the retransmission is based on a lower protocol layer than a protocol layer of the data unit.Our ref. : 240508EPWOP 6Sony Group Corporation57. The base station of claim 56,wherein the retransmission is based on a Media Access Control protocol.

58. The base station of claim 56,wherein the retransmission is based on Hybrid Automatic Repeat Request.

59. The base station of claim 41, further configured to:determine that retransmission of the segment is ongoing based on a determination that an associated retransmission timer is running.

60. The base station of claim 59,wherein the retransmission timer is configured as a t-Reassembly timer.

61. The base station of claim 41, further configured to:trigger the transmitting of the indication based on a request from the transmission node.

62. The base station of claim 61,wherein the request corresponds to polling information.

63. The base station of claim 61,wherein the request includes setting a polling bit of a Protocol Data Unit according to a Radio Link Control protocol.

64. The base station of claim 41, further configured to:trigger the transmitting of the indication based on a determination that a number of received retransmissions of the segment exceeds a threshold.

65. The base station of claim 41, further configured to:trigger the transmitting of the indication based on detecting a gap in a sequence between successfully received Protocol Data Units.

66. The base station of claim 41, further configured to:trigger the transmitting of the indication based on a determination that a later data unit with a higher sequence number than the data unit has been successfully received.

67. The base station of claim 41, further configured to:trigger the transmitting of the indication based on a determination that a segment of a later data unit with a higher sequence number than the data unit has been successfully received.

68. The base station of claim 41, further configured to:trigger the transmitting of the indication based on a determination that a later segment of the data unit at a higher segment offset than the segment has been successfully received.Our ref. : 240508EPWOP 7Sony Group Corporation69. The base station of claim 41, further configured to:trigger the transmitting of the indication based on a determination that a number of segments of the data unit for which retransmission is ongoing exceeds a threshold.

70. The base station of claim 41, further configured to:trigger the transmitting of the indication based on a remaining Packet Delay Budget associated with the data unit.

71. The base station of claim 41, further configured to:trigger the transmitting of the indication based on granted resources that are available for the retransmission.

72. The base station of claim 41, further configured to:trigger the transmitting of the indication based on a determination that a data amount received since a first transmission of the segment exceeds a threshold.

73. The base station of claim 41, further configured to:trigger the transmitting of the indication based on a determination that a time elapsed since a first transmission of the segment exceeds a threshold.

74. The base station of claim 41, further configured to:trigger the transmitting of the indication based on a determination that a number of Protocol Data Units that need to be retransmitted exceeds a threshold.

75. The base station of claim 41, further configured to:transmit the indication based on a determination of a service to which the data unit corresponds.

76. The base station of claim 75,wherein the determination of the service includes determining that the service requires a predetermined minimum data rate.

77. The base station of claim 75,wherein the determination of the service includes determining that the service requires a predetermined maximum latency.

78. The base station of claim 75,wherein the determination of the service includes determining that the service includes an extended Reality service.Our ref. : 240508EPWOP 8Sony Group Corporation79. The base station of claim 41,wherein Radio Resource Control is configured to control whether to transmit the indication that the retransmission is ongoing.

80. The base station of claim 41, further configured to:transmit the indication while an associated t-StatusProhibit timer is running.

81. Circuitry for mobile telecommunications, configured to:receive, from a transmission node, a data unit including at least one segment; and transmit, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing.

82. The circuitry of claim 81,wherein the data unit is configured as a Service Data Unit.

83. The circuitry of claim 81,wherein the at least one segment of the data unit is included in a Protocol Data Unit.

84. The circuitry of claim 81,wherein the transmission node transmits the data unit according to a Radio Link Control protocol.

85. The circuitry of claim 81,wherein the transmission node transmits the data unit in an acknowledged mode.

86. The circuitry of claim 81,wherein the transmitting of the indication is based on a Radio Link Control protocol.

87. The circuitry of claim 81,wherein the indication is included in a Protocol Data Unit.

88. The circuitry of claim 81,wherein the indication is included in a STATUS report.

89. The circuitry of claim 88,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the segment of the data unit.

90. The circuitry of claim 88,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the data unit.Our ref. : 240508EPWOP 9Sony Group Corporation91. The circuitry of claim 88,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with an acknowledgement sequence number.

92. The circuitry of claim 88,wherein the indication includes setting, in the STATUS report, a Control Protocol Data Unit Type to a predetermined value different from zero.

93. The circuitry of claim 81,wherein the indication includes reporting, as a status of the segment, a status that is different from a positively acknowledged status and from a negatively acknowledged status.

94. The circuitry of claim 93,wherein the status corresponds to a premature negatively acknowledged status.

95. The circuitry of claim 93,wherein the status corresponds to an unknown status.

96. The circuitry of claim 81,wherein the retransmission is based on a lower protocol layer than a protocol layer of the data unit.

97. The circuitry of claim 96,wherein the retransmission is based on a Media Access Control protocol.

98. The circuitry of claim 96,wherein the retransmission is based on Hybrid Automatic Repeat Request.

99. The circuitry of claim 81, further configured to:determine that retransmission of the segment is ongoing based on a determination that an associated retransmission timer is running.

100. The circuitry of claim 99,wherein the retransmission timer is configured as a t-Reassembly timer.

101. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on a request from the transmission node.

102. The circuitry of claim 101,wherein the request corresponds to polling information.Our ref. : 240508EPWOP 10Sony Group Corporation103. The circuitry of claim 101,wherein the request includes setting a polling bit of a Protocol Data Unit according to a Radio Link Control protocol.

104. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on a determination that a number of received retransmissions of the segment exceeds a threshold.

105. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on detecting a gap in a sequence between successfully received Protocol Data Units.

106. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on a determination that a later data unit with a higher sequence number than the data unit has been successfully received.

107. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on a determination that a segment of a later data unit with a higher sequence number than the data unit has been successfully received.

108. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on a determination that a later segment of the data unit at a higher segment offset than the segment has been successfully received.

109. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on a determination that a number of segments of the data unit for which retransmission is ongoing exceeds a threshold.

110. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on a remaining Packet Delay Budget associated with the data unit.

111. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on granted resources that are available for the retransmission.

112. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on a determination that a data amount received since a first transmission of the segment exceeds a threshold.Our ref. : 240508EPWOP 11Sony Group Corporation113. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on a determination that a time elapsed since a first transmission of the segment exceeds a threshold.

114. The circuitry of claim 81, further configured to:trigger the transmitting of the indication based on a determination that a number of Protocol Data Units that need to be retransmitted exceeds a threshold.

115. The circuitry of claim 81, further configured to:transmit the indication based on a determination of a service to which the data unit corresponds.

116. The circuitry of claim 115,wherein the determination of the service includes determining that the service requires a predetermined minimum data rate.

117. The circuitry of claim 115,wherein the determination of the service includes determining that the service requires a predetermined maximum latency.

118. The circuitry of claim 115,wherein the determination of the service includes determining that the service includes an extended Reality service.

119. The circuitry of claim 81,wherein Radio Resource Control is configured to control whether to transmit the indication that the retransmission is ongoing.

120. The circuitry of claim 81, further configured to:transmit the indication while an associated t-StatusProhibit timer is running.

121. A method for mobile telecommunications, comprising:receiving, from a transmission node, a data unit including at least one segment; and transmitting, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing.

122. The method of claim 121,wherein the data unit is configured as a Service Data Unit.

123. The method of claim 121,wherein the at least one segment of the data unit is included in a Protocol Data Unit.Our ref. : 240508EPWOP 12Sony Group Corporation124. The method of claim 121,wherein the transmission node transmits the data unit according to a Radio Link Control protocol.

125. The method of claim 121,wherein the transmission node transmits the data unit in an acknowledged mode.

126. The method of claim 121,wherein the transmitting of the indication is based on a Radio Link Control protocol.

127. The method of claim 121,wherein the indication is included in a Protocol Data Unit.

128. The method of claim 121,wherein the indication is included in a STATUS report.

129. The method of claim 128,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the segment of the data unit.

130. The method of claim 128,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with the data unit.

131. The method of claim 128,wherein the indication includes setting, in the STATUS report, a reserved bit that is associated with an acknowledgement sequence number.

132. The method of claim 128,wherein the indication includes setting, in the STATUS report, a Control Protocol Data Unit Type to a predetermined value different from zero.

133. The method of claim 121,wherein the indication includes reporting, as a status of the segment, a status that is different from a positively acknowledged status and from a negatively acknowledged status.

134. The method of claim 133,wherein the status corresponds to a premature negatively acknowledged status.

135. The method of claim 133,wherein the status corresponds to an unknown status.Our ref. : 240508EPWOP 13Sony Group Corporation136. The method of claim 121,wherein the retransmission is based on a lower protocol layer than a protocol layer of the data unit.

137. The method of claim 136,wherein the retransmission is based on a Media Access Control protocol.

138. The method of claim 136,wherein the retransmission is based on Hybrid Automatic Repeat Request.

139. The method of claim 121, further comprising:determining that retransmission of the segment is ongoing based on a determination that an associated retransmission timer is running.

140. The method of claim 139,wherein the retransmission timer is configured as a t-Reassembly timer.

141. The method of claim 121, further comprising:triggering the transmitting of the indication based on a request from the transmission node.

142. The method of claim 141,wherein the request corresponds to polling information.

143. The method of claim 141,wherein the request includes setting a polling bit of a Protocol Data Unit according to a Radio Link Control protocol.

144. The method of claim 121, further comprising:triggering the transmitting of the indication based on a determination that a number of received retransmissions of the segment exceeds a threshold.

145. The method of claim 121, further comprising:triggering the transmitting of the indication based on detecting a gap in a sequence between successfully received Protocol Data Units.

146. The method of claim 121, further comprising:triggering the transmitting of the indication based on a determination that a later data unit with a higher sequence number than the data unit has been successfully received.Our ref. : 240508EPWOP 14Sony Group Corporation147. The method of claim 121, further comprising:triggering the transmitting of the indication based on a determination that a segment of a later data unit with a higher sequence number than the data unit has been successfully received.

148. The method of claim 121, further comprising:triggering the transmitting of the indication based on a determination that a later segment of the data unit at a higher segment offset than the segment has been successfully received.

149. The method of claim 121, further comprising:triggering the transmitting of the indication based on a determination that a number of segments of the data unit for which retransmission is ongoing exceeds a threshold.

150. The method of claim 121, further comprising:triggering the transmitting of the indication based on a remaining Packet Delay Budget associated with the data unit.

151. The method of claim 121, further comprising:triggering the transmitting of the indication based on granted resources that are available for the retransmission.

152. The method of claim 121, further comprising:triggering the transmitting of the indication based on a determination that a data amount received since a first transmission of the segment exceeds a threshold.

153. The method of claim 121, further comprising:triggering the transmitting of the indication based on a determination that a time elapsed since a first transmission of the segment exceeds a threshold.

154. The method of claim 121, further comprising:triggering the transmitting of the indication based on a determination that a number of Protocol Data Units that need to be retransmitted exceeds a threshold.

155. The method of claim 121, further comprising:transmitting the indication based on a determination of a service to which the data unit corresponds.

156. The method of claim 155,wherein the determination of the service includes determining that the service requires a predetermined minimum data rate.Our ref. : 240508EPWOP 15Sony Group Corporation157. The method of claim 155,wherein the determination of the service includes determining that the service requires a predetermined maximum latency.

158. The method of claim 155,wherein the determination of the service includes determining that the service includes an extended Reality service.

159. The method of claim 121,wherein Radio Resource Control controls whether to transmit the indication that the retransmission is ongoing.

160. The method of claim 121, further comprising:transmitting the indication while an associated t-StatusProhibit timer is running.

161. A user equipment for mobile telecommunications, comprising transmission circuitry that is configured to communicate with a reception node;wherein the reception node includes circuitry that is configured to:receive, from the user equipment, a data unit including at least one segment; and transmit, to the user equipment, an indication that retransmission of a segment of the data unit is ongoing;wherein the communicating with the reception node comprises:transmitting the data unit to the reception node;receiving, from the reception node, the indication that retransmission of the segment of the data unit is ongoing; andtriggering a further retransmission of the segment based on the indication.

162. The user equipment of claim 161, wherein the communicating with the reception node further comprises:granting further resources for the retransmission of the segment.

163. The user equipment of claim 162, wherein the granting of the further resources is based on a remaining Packet Delay Budget associated with the data unit.

164. The user equipment of claim 161,wherein the further retransmission is based on Automatic Repeat Request.

165. A base station for mobile telecommunications, comprising transmission circuitry that is configured to communicate with a reception node;wherein the reception node includes circuitry that is configured to:Our ref. : 240508EPWOP 16Sony Group Corporationreceive, from the base station, a data unit including at least one segment; and transmit, to the base station, an indication that retransmission of a segment of the data unit is ongoing;wherein the communicating with the reception node comprises:transmitting the data unit to the reception node;receiving, from the reception node, the indication that retransmission of the segment of the data unit is ongoing; andtriggering a further retransmission of the segment based on the indication.

166. The base station of claim 165, wherein the communicating with the reception node further comprises:granting further resources for the retransmission of the segment.

167. The base station of claim 166, wherein the granting of the further resources is based on a remaining Packet Delay Budget associated with the data unit.

168. The base station of claim 165,wherein the further retransmission is based on Automatic Repeat Request.

169. Transmission circuitry for mobile telecommunications, configured to communicate with a reception node;wherein the reception node includes circuitry that is configured to:receive, from the transmission circuitry, a data unit including at least one segment; andtransmit, to the transmission circuitry, an indication that retransmission of a segment of the data unit is ongoing;wherein the communicating with the reception node comprises:transmitting the data unit to the reception node;receiving, from the reception node, the indication that retransmission of the segment of the data unit is ongoing; andtriggering a further retransmission of the segment based on the indication.

170. The transmission circuitry of claim 169, wherein the communicating with the reception node further comprises:granting further resources for the retransmission of the segment.

171. The transmission circuitry of claim 170, wherein the granting of the further resources is based on a remaining Packet Delay Budget associated with the data unit.Our ref. : 240508EPWOP 17Sony Group Corporation172. The transmission circuitry of claim 169,wherein the further retransmission is based on Automatic Repeat Request.

173. A method for mobile telecommunications, comprising communicating with a reception node;wherein the reception node includes circuitry that is configured to:receive, from a transmission node, a data unit including at least one segment; and transmit, to the transmission node, an indication that retransmission of a segment of the data unit is ongoing;wherein the communicating with the reception node comprises:transmitting the data unit to the reception node;receiving, from the reception node, the indication that retransmission of the segment of the data unit is ongoing; andtriggering a further retransmission of the segment based on the indication.

174. The method of claim 173, wherein the communicating with the reception node further comprises:granting further resources for the retransmission of the segment.

175. The method of claim 174,wherein the granting of the further resources is based on a remaining Packet Delay Budget associated with the data unit.

176. The method of claim 173,wherein the further retransmission is based on Automatic Repeat Request.

Images