Method and apparatus

Abstract

The disclosure relates to method performed by a first communication apparatus, receiving, from a second communication apparatus, at most predetermined number of transmission blocks (TBs) per transmission occasion, wherein each TB of the at most predetermined number of TBs has redundant information indicating whether the each TB is redandand version or not; buffering the at most predetermined number of TBs in a case where decoding at least one of the at most predetermined number of TBs is failed, until at least one condition is met; decoding received TBs using at most predetermined number of TBs received at a current transmission occasion and buffered at most predetermined number of TBs received previous transmission occasions before the current transmission occasion.

Description

METHOD AND APPARATUS

[0001] The present disclosure relates to a communication system.

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including LTE-Advanced, Next Generation or 5G networks, future generations, and beyond), and to radio link coding for low latency traffic.

[0003] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the terms '5G' and 'new radio' (NR) are used to refer to an evolving communication technology that is expected to support a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

[0004] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application will use the term access network node, RAN node or base station to refer to any such access nodes.

[0005] Also for simplicity, the present application will use the term mobile device, user device, or UE to refer to any communication device that is able to connect to the core network via one or more base stations. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and / or generally stationary) that can connect to a communications network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0006] The term extended reality (XR) refers to all real-and-virtual combined environments and associated human-machine interactions generated by computer technology and wearables. It includes representative forms such as augmented reality (AR), mixed reality (MR), and virtual reality (VR) and the areas interpolated among them. 3GPP Technical Report (TR) 26.928 V16.1.0 discusses eXtended Reality (XR) in the context of 5G radio and network services. This document introduces baseline technologies for XR type of services and applications, outlining the quality of experience (QoE) / quality of service (QoS) issues of XR-based services, the delivery of XR in 5G systems, and an architectural model of 5G media streaming defined in 3GPP TS 26.501 V16.9.0. In addition to the conventional service category, interactive, streaming, download, and split compute / rendering are identified as new delivery categories for XR.

[0007] NPL 1: NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN), available from https: / / www.ngmn.org / 5g-white-paper.html

[0008] Ultra Reliable Low-Latency Communication (URLLC) a requirement for critical applications such as automated driving and factory automation, which require guaranteed access within a very short time. URLLC applications may have moderate throughput (capacity) requirements, but requirements for very low latency.

[0009] There is a need for improved communication systems, and corresponding methods, for transmission of data that has both high data rate requirements and low latency requirements (for example XR traffic). For example, there is a need for more efficient air interface protocols, and for improved methods of feedback-based retransmission, for transmission of data that requires both high throughput and low latency.

[0010] The disclosure aims to provide apparatus and methods that at least partially address the above needs and / or issues.

[0011] Detailed examples of the disclosure will now be described, by way of example, with reference to the accompanying drawings in which:

[0012] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system 1;Fig. 2 illustrates a typical frame structure that may be used in the communication system 1 of Fig. 1;Fig.3 illustrates a user plane protocol stack;Fig. 4 illustrates a control plane protocol stack;Fig. 5 illustrates an example of window-based transmission without feedback;Fig. 6 illustrates an example of window-based transmission with feedback;Fig. 7 illustrates an example of radio link coding at layer 2 (L2);Fig. 8 illustrates a further example of radio link coding at L2;Fig. 9 is a schematic block diagram illustrating the main components of a UE 3 for the communication system 1 of Fig. 1;Fig. 10 is a schematic block diagram illustrating the main components of a base station 5 of a distributed type for the communication system 1 of Fig. 1; andFig. 11 is a schematic block diagram illustrating the main components of a core network node or function 7 for the communication system 1 of Fig. 1.

[0013] Overview 　　An exemplary communication system will now be described in general terms, by way of example only, with reference to Figs. 1 to 4.

[0014] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system 1 to which examples of the present disclosure are applicable.

[0015] In the communication system 1, user equipment (UEs) 3-1, 3-2, 3-3 (e.g. mobile telephones and / or other mobile devices) can communicate with each other via a radio access network (RAN) node 5 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN node 5 comprises a distributed base station 5 or 'gNB' operating one or more associated cells 9. Communication via the RAN is typically routed through an associated core network 7 (e.g. a 5G / 6G or later generations' core network or evolved packet core network (EPC)).

[0016] As those skilled in the art will appreciate, whilst three UEs 3 and one base station 5 are shown in Fig. 1 for illustration purposes, the system, when implemented, will typically include other base stations 5 and UEs 3.

[0017] Each base station 5 controls one or more associated cells 9 either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and / or the like). It will be appreciated that the base stations 5 may be configured to support 4G, 5G, 6G and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.

[0018] In this example the illustrated RAN node 5 comprises a distributed base station comprising at least one distributed unit (DU) 5b (e.g., a gNB-DU or the like), and a central unit (CU) 5c (e.g., a gNB-CU or the like). The CU 5c employs a separated control plane and user plane and so is, itself, split between a control plane function (CU-CP) and a user plane function (CU-UP) which respectively communicate, with the DU via an appropriate interface (e.g. an F1-C logical interface) and an appropriate interface (e.g. an F1-U logical interface (together forming an F1 interface (or 'reference point'))), and with one another via an appropriate interface (e.g. an E1 logical interface). It will be appreciated that while, in this example, the DU 5b includes the physical and virtual elements required to provide the functionality of the lower parts of the PHY layer and hence communicate with the UEs 3 over the air interface, the RAN may alternatively (or additionally) include one or more separate radio units (RUs) (e.g., providing this functionality of the lower parts of the PHY layer). It will, nevertheless, be appreciated that whilst distributed RAN node 5 is shown and described, the RAN node 5 may be provided in a non-distributed form, for example as an integrated base station 5.

[0019] The UEs 3 and their serving base station 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and / or the like). Neighbouring base stations 5 may be connected to each other via an appropriate base station to base station interface (such as the so-called 'X2' interface, 'Xn' interface and / or the like).

[0020] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and one or more network node entities for the communication of user data (e.g. user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g. Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g. Session Management Functions (SMFs) 10-2) and a number of other functions 10-n (such as, for example, an Authentication Server Function (AUSF) which facilitates security processes, a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorization, user registration, and data network profiles), a Policy Control Function (PCF), an Application Function (AF), and / or the like). It will be appreciated that the nodes or functions may have different names in different systems.

[0021] The RAN node 5 is connected to the core network nodes via appropriate interfaces (or 'reference points') such as an N2 reference point between the CU 5c (CU-CP) of the RAN and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the CU 5c (CU-UP) of the RAN and each UPF 11 for the communication of user data. The UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate reference point (e.g. an N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated that N1 communications are routed transparently via the RAN.

[0022] One or more UPFs 11 are connected to an external data network (e.g., an IP network such as the Internet) via an appropriate reference point (e.g. an N6 reference point) for communication of the user data.

[0023] The AMF 10-1 performs mobility management related functions, maintains the NAS connection with each UE 3 and manages UE registration. The AMF 10-1 is also responsible for managing paging. The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 also allocates IP addresses to each UE 3.

[0024] The base station 5 of the communication system 1 may be configured to operate at least one cell 9 on an associated time-division duplex (TDD) carrier that operates in unpaired spectrum. It will be appreciated that the base station 5 may also operate at least one cell 9 on an associated frequency-division duplex (FDD) carrier that operates in paired spectrum.

[0025] The base station 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originating from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originating from a higher layer.

[0026] The physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting a number of functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides UEs 3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection. The UE 3 may receive a Synchronization Signal Block (SSB), and the UE 3 may assume that reception occasions of a PBCH, primary synchronization signal (PSS) and secondary synchronization signal (SSS) are in consecutive symbols and form a SS / PBCH block. The base station 5 may transmit a number of synchronization signal (SS) blocks corresponding to different DL beams. The total number of SS blocks may be confined, for example, within a 5 ms duration as an SS burst. The periodicity of the SSB transmissions may be indicated to the UE using any suitable signalling (e.g. per serving cell using ssb-periodicityServingCell). The periodicity value for the SSB may be, for example, greater than or equal to 20 ms. For initial cell selection, the UE 3 may be configured to assume that an SS burst occurs with a periodicity of 2 frames. The UE 3 may also be provided with an indication of which SSBs within a 5 ms duration are transmitted (e.g. using ssb-PositionsInBurst).

[0027] The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the base station 5. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signal (CSI-RS).

[0028] Similarly, the UEs 3 are configured for transmission of, and the base station 5 is configured for the reception of, control information and user data via a number of uplink (UL) physical channels corresponding to REs carrying information originating from a higher layer, and UL physical signals which are used in the physical layer and correspond to REs which do not carry information originating from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and / or a physical random-access channel (PRACH). The UL physical signals may include, for example, demodulation reference signals (DMRS) for a UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

[0029] When the UE 3 initially establishes a radio resource control (RRC) connection with a base station 5 via a cell 9 it registers with an appropriate core network node (e.g., AMF, MME). The UE 3 is in the so-called RRC connected state and an associated UE context is maintained by the network. When the UE 3 is in the so-called RRC idle state, or is in the RRC inactive state, it selects an appropriate cell for camping so that the network is aware of the approximate location of the UE 3 (although not necessarily on a cell level).

[0030] As mentioned above, the base station 5 in this example is a 'distributed' base station 5 that is split between one or more distributed units (DUs) 5b and a central unit (CU) 5c, with a CU 5c typically performing higher level functions and communication with the next generation core, and with the DU 5b performing lower level functions and communication over an air interface with UEs 3 in the vicinity (i.e. in a cell operated by the base station 5). A distributed base station 5 may, for example, include the following functional units hosting the following functions: - Central Unit (CU): a logical node hosting Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP) and Packet Data Convergence Protocol (PDCP) layers of the base station 5 that controls the operation of one or more DUs 5b. The CU 5c terminates an appropriate interface (e.g. the so-called F1 interface) connected with the DU 5b. - Distributed Unit (DU): a logical node hosting Radio Link Control (RLC), Medium Access Control (MAC) and Physical (PHY) layers of the base station 5, and its operation is partly controlled by the CU 5c. One DU 5b supports one or multiple cells. One cell is supported by only one DU 5b. The DU 5b terminates an appropriate interface (e.g. the F1 interface) connected with the CU 5c. - CU-Control Plane (CU-CP): a logical node hosting the RRC and the control plane part of the PDCP protocol of the CU 5c for the base station 5. The CU-CP terminates an appropriate interface (e.g. the so-called E1 interface) connected with the CU-UP and an appropriate interface (e.g. the F1-C (F1 control plane) interface) connected with the DU 5b. - CU-User Plane (CU-UP): a logical node hosting the user plane part of the PDCP protocol and the SDAP protocol of the CU 5c for the base station 5. The CU-UP terminates an appropriate interface (e.g. the E1 interface) connected with the CU-CP and an appropriate interface (e.g. the F1-U (F1 user plane) interface) connected with the DU 5b.

[0031] Frame Structure 　　Referring to Fig. 2, which illustrates a typical frame structure that may be used in the communication system 1, the base station 5 and UEs 3 of the communication system 1 communicate with one another using resources that are organised, in the time domain, into frames of length 10 ms. Each frame comprises ten equally sized subframes of 1 ms length. Each subframe is divided into one or more slots comprising 14 orthogonal frequency-division multiplexing (OFDM) symbols of equal length.

[0032] As seen in Fig. 2, the communication system 1 supports multiple different numerologies (subcarrier spacing (SCS), slot lengths and hence OFDM symbol lengths). Specifically, each numerology is identified by a parameter, μ, where μ=0 represents 15 kHz (corresponding to the LTE SCS). Currently, the SCS for other values of μ can, in effect, be derived from μ = 0 by scaling up in powers of 2 (i.e. SCS = 15 x 2μkHz). The relationship between the parameter, μ, and SCS (Δf) is as shown in Table 1:

[0033] HARQ Feedback and Error Correction 　　In a wireless communication link some of the transmitted packets may be lost, or may be subject to errors introduced by noise or interference. To mitigate against such lost packets, an automatic repeat request (ARQ) process can be used in which the receiving device (e.g. the UE 3) checks for errors or lost packets within the received data, and retransmission of packets is requested when needed. ARQ can be used, for example, in an Acknowledge Mode of the RLC layer. In Hybrid ARQ (HARQ), the receiving device buffers the received data and if an error is detected then re-transmission of one or more packets is requested from the transmitter. The receiving device can then combine the re-transmitted data with the buffered data. HARQ can be used, for example, at the MAC layer.

[0034] The HARQ procedure can be used to mitigate against such packet losses and errors by using re-transmission (or selective re-transmission) of data packets. For example, a UE may receive a transmission from a base station that includes errors or missing packets. The UE may attempt to correct errors in the received transmission where possible, and may provide feedback to the base station regarding the transmission that has been received, for example including an acknowledgement (ACK) or negative acknowledgement (NACK). Based on the feedback, the base station may re-transmit some or all of the original transmission. The HARQ procedure may include a number of simultaneous HARQ processes, each used for a respective part of the transmission. Therefore, when the base station is awaiting feedback from the UE corresponding to a particular HARQ process (and therefore to a particular part of the transmission), the base station can continue transmission of data for the other HARQ processes.

[0035] When the UE 3 is receiving data for a particular service (e.g. URLLC), it transmits appropriate HARQ-ACK feedback to the base station 5 using resources associated with that service. Normally, the HARQ-ACK feedback is provided in the form of a codebook (a string of bits), the bits of the codebook representing which data has been received successfully and which not.

[0036] HARQ-ACK feedback with one bit per TB can be supported. Operation of more than one downlink (DL) HARQ processes is supported for a given UE while operation of one DL HARQ process is supported for some UEs. The UE and NR (base station) each have a minimum HARQ processing time. The HARQ processing time at least includes a delay between DL data reception timing to the corresponding HARQ-ACK transmission timing and a delay between uplink (UL) grant reception timing to the corresponding UL data transmission timing. Each serving cell may have its own HARQ entity and a corresponding set of parallel HARQ processes. A single downlink HARQ process can be associated with 1 or 2 transport blocks (TBs), and can be asynchronous (a TB is a packet of data that is passed between the MAC and PHY layers and transmitted across the air interface). A new data indicator (NDI), for example a one-bit flag, can be used to provide an indication to the UE 3 of whether transmitted data is newly transmitted data or re-transmitted data.

[0037] HARQ error detection and re-transmission may be performed per TB, in which case a negative acknowledgement indicates that the TB is to be retransmitted. Alternatively, HARQ error detection and re-transmission may be performed per code block, in which case a negative acknowledgement indicates that the code block is to be retransmitted (reducing the amount of data, compared to a TB, that need be re-transmitted, but increasing the amount of feedback that need be transmitted due to the smaller unit of data for feedback). In a further alternative, HARQ error detection and re-transmission may be performed per code block group (CBG), in which HARQ acknowledgements and retransmissions are manager per group of code blocks.

[0038] Low density parity check (LDPC) coding can be used in which systematic and parity bits (whose values depend on the values of the bits used to transmit the data) are included in the transmissions. The parity bits are determined such that the product of a parity check matrix with a vector of the parity bits generates a '0' vector. The transmitted data can be checked for errors by checking the value of the parity bits. If an error is detected, multiple parity bits can be used to reconstruct the transmitted data.

[0039] Protocol Stacks 　　Fig. 3 illustrates a user plane protocol stack that can be used in the communication system illustrated in Fig. 1. The protocol stack includes a number of protocol layers that are terminated at the UE 3 and at the base station 5. As shown in Fig. 3, the protocol stack includes a physical (PHY) layer, Medium Access Control (MAC) layer, Radio Link Control (RLC) layer, Packet Data Convergence Protocol (PDCP) layer, and Service Data Adaptation Protocol (SDAP) layer. Fig. 4 illustrates a control plane protocol stack that can be used in the communication system illustrated in Fig. 1. As shown in Fig. 5, the control plane protocol stack includes the PHY, MAC, RLC and PDCP layers, as well as the radio resource control (RRC) layer.

[0040] As described above, the SDAP and PDCP layers may be hosted at a CU 5c. The RLC, MAC and PHY layers may be hosted at a DU 5b.

[0041] The MAC layer is a layer 2 (L2) sublayer. The MAC layer receives RLC PDUs (as MAC service data units (SDU)s) from the RLC sublayer and processes them to form MAC PDUs (which are packaged as transport blocks (TBs)) for transmission via the PHY sublayer. PDCP PDUs carrying data from the upper layers may also be referred to as PDCP data PDUs to distinguish them from a PDCP control PDU carrying control data. The MAC layer supports the HARQ protocol. The PHY layer is a layer 1 (L1) layer that can apply segmentation to large TBs to maintain the transmitted packet size below the configured maximum packet size, and enables transmission and reception via the air interface. Cyclic redundancy check (CRC) bits can be included in each TB at the PHY layer, to enable the receiving device to check for errors in the received TBs.

[0042] The RLC layer is a L2 sublayer. The RLC sublayer provides a radio link protocol used over the air interfaces between a UE 3 and the base station 5 (i.e., Uu). The RLC sublayer provides a number of functions depending on requirements including, for example: transfer of upper layer (PDCP) PDUs in one of three modes including acknowledged mode (AM), unacknowledged mode (UM) and transparent mode (TM); error correction through automatic repeat requests (ARQ) for AM data transfer; concatenation, segmentation and reassembly of RLC SDUs (UM and AM); re-segmentation of RLC data PDUs when a complete RLC PDU cannot be transmitted (AM); reordering of RLC data PDUs (UM and AM); duplicate detection (UM and AM); RLC SDU discard (UM and AM); RLC re-establishment; protocol error detection and recovery. One or more RLC entities may be established in the RLC sublayer for receiving data from higher layers and for processing the RLC SDUs through the RLC layer to become RLC PDUs (and vice versa). Following the processing of the RLC SDUs to form RLC PDUs, the RLC entity transfers the RLC PDUs to the MAC sublayer (where they are received as MAC SDUs). A receiving RLC entity in one device (e.g., the base station 5 or UE 3) can generate an RLC status report indicating the receive status of packets (RLC SDUs) successfully received (or not received) from a transmitting RLC entity at a corresponding peer device (e.g., the base station 5, or UE 3) and send the RLC status report as an RLC status PDU to the peer device. An RLC status report / PDU will typically include the receive status for a plurality of received RLC SDUs (and possibly RLC SDU segments). On receipt of the RLC status report / PDU, the RLC entity at the peer (transmitting) device will iterate through the positively acknowledged packets in the RLC status report / PDU and notify the PDCP layer of each RLC SDU (and hence PDCP PDU) that has been positively acknowledged. Accordingly the base station 5 and remote UE 3 may operate data radio bearers (DRBs) in an RLC acknowledge mode (AM).

[0043] The PDCP sublayer is the L2 sublayer that sits below the SDAP sublayer for user plane data, and below the RRC sublayer for control plane data. The PDCP sublayer provides a number of functions depending on requirements including, for example: transfer of user plane data (to / from the SDAP sublayer); transfer of control plane data (to / from the RRC sublayer); maintenance of PDCP sequence numbers; header compression and decompression (e.g., using the robust header compression (ROHC) protocol); ciphering and deciphering; integrity protection and integrity verification; timer based discarding of packets (PDCP SDUs); routing (e.g., for split bearers); duplication; reordering and in-order delivery; out-of-order delivery; and / or duplicate discarding.

[0044] One or more PDCP entities may be established in the PDCP sublayer for receiving data from higher layers and for processing the PDCP SDUs through the PDCP layer to become PDCP PDUs (and vice versa). Following the processing of the PDCP SDUs to form PDCP PDUs, the PDCP entity transfers the PDCP PDUs to the RLC sublayer (where they are received as RLC SDUs). A PDCP entity at the base station 5 may send a PDCP status report (a PDCP status PDU) to a corresponding peer PDCP entity at the UE 3 to indicate the received status of uplink PDCP packets at the base station 5. Similarly, a PDCP entity at the UE 3 may send a PDCP status report / PDU to a corresponding peer PDCP entity at the base station 5 to indicate the received status of downlink PDCP packets at the UE 3. A PDCP status report PDU will typically include a 'PDU type' field to identify the PDU as being a PDCP status report type of PDU. The PDCP status report will also specify a first missing count (FMC) value for the counter associated with PDCP SDUs having sequence numbers (SNs). The count value is a concatenation of a hyper frame number (HFN) and the PDCP SN. A bitmap may also, optionally, be included to indicate what count values, following the FMC, are also missing. On receipt of a PDCP status report a PDCP entity of a transmitting device (base station / UE) can thus discard all packets which have been successfully received at a PDCP entity of the peer receiving device (UE / base station).

[0045] The SDAP layer is the highest L2 sublayer of the protocol stack. It is responsible for quality of service (QoS) flow handling across the air (Uu) interface and N3 interface. The SDAP sublayer can have multiple SDAP entities (e.g., one for each protocol data unit (PDU) session between the base station 5 and remote UE 3) where SDAP entity establishment / release is initiated by RRC. The SDAP layer is responsible for the transfer of user plane data between the remote UE 3 and the core network (UPF 11). An SDAP entity maps each QoS flow from higher layers, within a particular PDU session, to a respective data radio bearer (DRB) established, via lower layers (e.g., PDCP and RLC) with the appropriate level of QoS, over the air interface between the UE 3 and the base station 5. As those skilled in the art will appreciate, the QoS flow may be in either the downlink or in the uplink and there may be more than one such QoS flow within the PDU session. It will be appreciated that the SDAP layer is not present in some architectures (e.g., in a non-stand-alone (NSA) architecture).

[0046] The RRC layer is considered to be a layer 3 (L3) sublayer and is the highest layer in the control plane of the access stratum (AS). It is also responsible for transferring messages of the non-access stratum (NAS), which is located above the RRC layer. The RRC layer is responsible for handling many RAN-related control plane procedures such as: broadcasting system Information (SI); transmission of paging messages to notify a UE about incoming connection requests; connection management; handling UE capabilities; and measurement configuration and reporting.

[0047] The application and transport layers can provide forward error correction (FEC) and retransmission in an independent manner, for example using a real-time transport protocol (RTP) or Web Real-Time Communications (WebRTC) that supports FEC and negative acknowledgement (NACK)-based retransmission. A Transmission Control Protocol (TCP) at the application / transport layer can also be used to support window-based retransmission. At L2, RLC feedback (e.g. ARQ) and window-based retransmission can be used, and duplication of transmitted data for redundancy can be implemented at the PDCP layer. At L1, channel coding utilising FEC (e.g using LDPC) can be used, and per-TB or per-CBG based retransmission can be implemented using HARQ processes. It will be appreciated, therefore, that several different feedback and error correction mechanisms are available at the various layers of the user plane protocol stack. For example, the L1 channel coding and L2 window-based retransmission can run independently, in which case the L2 retransmission can be used to mitigate against cases in which the L1 HARQ process is unsuccessful for a TB. However, the L1 HARQ and L2 ARQ processes can introduce relatively high transmission latency, which can be unsuitable for traffic having low (e.g. ultra-low) latency requirements. Whilst L2 retransmission could be disabled for latency-sensitive applications, PDSCH / PUSCH repetition-based L1 can be inefficient, for example due to the relatively coarse redundancy level granularity. The inventors have realised that improved air interface protocols that enable reliable data transmission and are suitable for data having both low latency and high data throughput requirements are needed (e.g. for XR traffic). Improved air interface protocols and improved methods of feedback-based retransmission, suitable for transmission of data that requires both high throughput and low latency, will now be described with reference to Figs. 5 to 8.

[0048] Window-Based Transmission at L1 Without Feedback 　　Fig. 5 shows an example of window-based transmission without feedback. In this example, the L1 FEC mechanism (e.g. LDPC) is improved using a window-based transmission mechanism, replacing the need for the L2 ARQ mechanism implemented at the RLC layer.

[0049] Fig. 5 illustrates transmit occasions C1 to C6, in which one or more TBs can be transmitted. A transmission buffer containing TBs 1 to 9 is illustrated, and the TBs that are decoded at the UE 3 are also illustrated. As shown in Fig. 5, in transmit occasion C1 the base station transmits TB 1 to the UE 3, but it is not successfully decoded at the UE 3. In transmit occasion C2 the base station retransmits TB 1 (re-transmitted TBs are indicated using diagonal hatching) and also transmits TB 2. Since in this example the base station 5 is not aware of which TBs the UE 3 has successfully received and decoded, the re-transmission of TB 1 can be referred to as a 'blind' re-transmission. In the illustrated example the UE 3 successfully decodes the re-transmitted TB 1 but does not successfully decode TB 2. In transmit occasion C3 the base station 5 re-transmits TB 2, and also transmits TB 3 and TB 4. The UE 3 successfully receives and decodes the re-transmitted TB 2 but does not successfully decode TB 3 or TB 4. In transmit occasion C4 the base station 5 blind-retransmits TB 2, TB 3 and TB 4; TB 3 and TB 4 are successfully received and decoded at the UE 3. In transmit occasion C5 the base station 5 re-transmits TB 4, and also transmits TB 5 and TB 6. The UE 3 successfully receives and decodes TB 5 and TB 6. In transmit occasion C6, the base station 5 re-transmits TB 6 and also transmits TB 7 and TB 8. In the illustrated example the UE 3 successfully receives and decodes TB 7.

[0050] In the example of Fig. 5 up to three TBs can be transmitted in each transmit occasion, but the maximum number of TBs that could be transmitted in each transmit occasion need not necessarily be three (for example, four or more TBs could be transmitted using a transmit occasion). The maximum number of TBs that can be transmitted in each transmit occasion can be referred to as 'K', the number of TBs that can be transmitted in a single 'transmission window'. This parameter can be provided to the UE 3 by the base station 5 (configured by the base station 5) before the actual data transmission. As shown in Fig. 5, the transmission window 'slides' along the TBs to be transmitted. For example, after the retransmission of TBs 2, 3 and 4 in transmit occasion C4, the transmission window slides along by two TBs, for the transmission of TBs 4, 5 and 6 in transmit occasion C5.

[0051] In the example of Fig. 5 the UE 3 does not transmit feedback regarding the transmitted TBs, and so all of the re-transmissions are blind retransmissions (e.g. the blind re-transmission of TBs 2, 3 and 4 in transmit occasion C4). Advantageously, the base station 5 (or the UE 3, when the UE 3 is the transmitter) is configured to determine the TB to be retransmitted based on an evaluation of the radio channel quality. For example, during transmission occasions C5 and C6 the base station 5 may determine that the radio channel quality is relatively good, and so only one TB need be retransmitted (TB 4 in transmission occasion C5, and TB 6 in transmission occasion C6). In contrast, when the base station 5 determines that the radio channel quality is relatively poor, the base station 5 may determine to increase the redundancy level. For example, in transmission occasion C4 the base station re-transmits three TBs (TB 2, TB 3 and TB 4). Beneficially, since the determination of which TBs to retransmits does not require feedback to be received from the UE 3 (or from the base station 5 in the case in which the UE 3 is the transmitter and the base station 5 is the receiver), the latency of the retransmission method is reduced.

[0052] The redundant transmission (the retransmitted TBs) in the example of Fig. 5 is L1-based retransmission. The TBs can be numbered by a sequence number (SN). For example, a 4 bit field could be used to indicate the SN ( in which case sixteen SN can be supported). However, it will be appreciated that any other suitable number of bits could be used to indicate the SN, and that maximum number of supported SN need not necessarily be sixteen. The TB is delivered to an upper (higher) layer at the receiver when the TB SN is removed.

[0053] The TBs transmitted in one transmission occasion may be separately encoded, or alternatively could be concatenated and jointly encoded at the PHY layer.

[0054] Information indicating whether a transmitted TB is a newly transmitted TB or a re-transmitted TB can be transmitted to the receiver along with the transmitted TB, or alternatively could be transmitted separately using any suitable control signalling (for example, uplink control information (UCI) or downlink control information (DCI)). Transmission window information (e.g. indicating the value of 'K' TBs that can be transmitted in a single transmission occasion) could similarly be transmitted along with the transmitted TBs or separately using any suitable control signalling (e.g. UCI or DCI). Alternatively, the transmission window information can be notified to the receiver by the transmitter before the actual transmission.

[0055] The receiver may jointly decode the received information bits (for the TBs) based on all of the received TBs, or could jointly decode one TB based on the redundant transmissions received for that TB. When the receiver jointly decodes the information bits, the receiver maintains a decoding window to buffer the received TBs within the window. The decoding window can be a time-based window, or can be based on the number of received TBs, or based on the size of received data in a buffer at the receiver. If the decoding occurs at the UE 3, the size of that decoding window can be configured by base station 5.

[0056] If decoding of a received TB is not possible, then the receiver buffers the received data for that TB and awaits a re-transmission of the TB by the transmitter. If the receiver subsequently successfully decodes the TB, then the TB can be flushed (deleted or overwritten) from the buffer. The receiver may also determine to flush a TB from the buffer if decoding of the TB is not possible, but the transmitter provides an indication that retransmission of that TB will not be performed. The indication that retransmission of that TB will not be performed could be an implicit indication or an explicit indication. For example, an implicit indication that retransmission of that TB will not be performed could be that the TBs transmitted in the previous transmission window did not include the TB stored in the buffer at the UE 3. For example, whilst in the example of Fig. 5 TB 1 is illustrated as successfully decoded following its transmission in transmission occasion C2, if TB 1 was not successfully decoded then the receiver can store the received bits of TB 1 in the buffer (for potentially combining with a retransmitted TB 1 to decode TB 1). The receiver can subsequently determine based on the TBs transmitted in transmission occasion C3 that TB 1 will not be retransmitted (since only TB 2, TB 3 and TB 4 are transmitted in transmission occasion C3), and so TB 1 can be flushed from the buffer. The receiver could also determine to flush a TB from the buffer based on expiry of a timer (e.g. a dedicated timer), which can help to avoid the window stalling.

[0057] Whilst Fig. 5 has been described with reference to the receiver being the UE 3 and the transmitter being the base station 5, this need not necessarily be the case. Alternatively, the UE 3 may be the transmitter and the base station 5 may be the receiver (in which case the UE 3 performs all the functions of the transmitter described above with reference to Fig. 5, and the base station 5 performs all the functions of the receiver described above with reference to Fig. 5).

[0058] Window-Based Transmission at L1 With Feedback 　　Fig. 6 shows an example of window-based transmission with feedback. In this example, the L1 FEC mechanism (e.g. LDPC) is improved using a window-based transmission mechanism, replacing the need for the L2 ARQ mechanism implemented at the RLC layer. The example of Fig. 6 is similar to the example described with reference to Fig. 5 above, except that feedback regarding the received TBs is provided to the transmitter by the receiver. Advantageously, in the example of Fig. 6, blind retransmission of TBs is combined with sliding the transmission window based on feedback from the receiver.

[0059] As shown in Fig. 6, in transmission occasion C1 the base station 5 transmits TB 1 to the UE 3. In transmission occasion C2 the base station 5 blindly retransmits TB 1 (e.g. based on an evaluation of the channel quality as described above), and transmits TB 2. In transmission occasion C3 the base station 5 blindly retransmits TB 1 and TB 2, and also transmits TB 3. In transmission occasion C4 the base station 5 blindly retransmits TB 1, TB 2 and TB 3. The base station 5 then receives an acknowledgement (which may also be referred to as a 'positive acknowledgement') from the UE 3 that TB 1 has been received and decoded at the UE 3. Therefore, the base station 5 determines to slide the transmission window by one TB (since re-transmission of TB 1 is not needed), and the base station transmits TB 2, TB 3 and TB 4 in transmission occasion C5. The base station 5 then receives an acknowledgement from the UE 3 that TB 2 has been received and decoded at the UE 3, and so the base station 5 determines to slide the transmission window by one TB (since re-transmission of TB 2 is not needed), and the base station transmits TB 3, TB 4 and TB 5 in transmission occasion C6. The base station then receives a negative acknowledgement (NACK) from the UE indicating that TB 3 has not been successfully decoded. Therefore, the base station 5 determines not to slide the transmission window, and retransmits TB 3, TB 4 and TB 5 in transmission occasion C7. The base station then receives a further negative acknowledgement (NACK) from the UE indicating that TB 3 has not been successfully decoded. Therefore, the base station 5 determines not to slide the transmission window, and retransmits TB 3, TB 4 and TB 5 in transmission occasion C8. The base station 5 then receives an acknowledgement from the UE 3 that TB 3, TB 4 and TB 5 have been received and decoded at the UE 3, and so the base station 5 determines to slide the transmission window by three TBs (since re-transmission of TB 3, TB 4 and TB 5 is not needed), and the base station transmits TB 6, TB 7 and TB 8 in transmission occasion C9.

[0060] As illustrated in Fig. 6, the base station 5 may determine to continue to transmit the redundant (retransmitted) TBs using the transmission window until positive feedback (ACK) is received from the UE 3. Alternatively, or additionally, the base station 5 may determine to slide the transmission window based on the expiry of a timer (e.g. a dedicated timer) which helps avoid a situation in which the transmission window stalls if positive feedback is not received from the UE 3, or based on a drop request from a higher layer (e.g. a drop request from L2).

[0061] If one or a plurality of negative feedback (NACK) is received from the UE 3, then the base station 5 may determine to increase the redundancy level of the transmitted TBs. For example, when one re-transmitted TB is transmitted in the transmission window and the base station then receives a NACK from the UE 3, the base station 5 may determine that two or more of the TBs to be transmitted in the next transmission occasions are to be re-transmitted TBs. The base station 5 may determine to retransmit a TB a predetermined number of times when a NACK is received for that TB.

[0062] Whilst in the examples shown in Fig. 5 and Fig. 6 entire TBs are illustrated as being retransmitted, this need not necessarily by the case. Alternatively, redundancy can be applied for only a portion of the information bits of a TB.

[0063] The UE 3 may provide feedback per TB, or may provide feedback per a group of TBs (e.g. a single bit for indicating of whether a plurality of TBs have been received). The feedback may be indicated per TB SN (or group of SNs). These feedback options and the corresponding parameters (e.g. the size of SN group for feedback) can be configured by the base station 5 (e.g. by transmitting configuration information to the UE 3) before the actual data transmission. Whilst the transmission of the feedback is illustrated as being generally aligned with the transmission occasions in the example of Fig. 6, this need not necessarily be the case. For example, transmission of the feedback may be relatively slow and span several transmission windows, in which case the base station 5 may determine to (blindly) slide the transmission window without yet having received feedback from the UE 3, beneficially reducing the latency.

[0064] In a case where the UE 3 transmits a NACK to the base station 5 for a TB (or group of TBs), the UE 3 stores the received parts of the TB (or TBs) in a buffer. As described above with reference to Fig. 5, the UE 3 can determine to flush the TB (or TBs) from the buffer based on a timer (e.g. a dedicated timer), or based on an explicit or implicit indication that the TB (or TBs) will not be retransmitted by the base station 5.

[0065] Whilst Fig. 6 has been described with reference to the receiver being the UE 3 and the transmitter being the base station 5, this need not necessarily be the case. Alternatively, the UE 3 may be the transmitter and the base station 5 may be the receiver (in which case the UE 3 performs all the functions of the transmitter described above with reference to Fig. 6, and the base station 5 performs all the functions of the receiver described above with reference to Fig. 6).

[0066] Radio Link Coding at L2 　　Fig. 7 shows an example in which a new radio link coding layer at layer 2 (L2) over Uu is used to generate redundant transmissions (retransmissions) as a replacement for, or complementary to, conventional HARQ / ARQ retransmission.

[0067] The new radio link coding sublayer may be arranged, for example, between the PDCP and MAC layers, and may implement functionality of part of the conventional RLC, MAC (including HARQ) and PHY layer FEC. The radio link coding sublayer may implement packet segmentation and / or concatenation of PDCP packets at the coding layer.

[0068] Advantageously, the retransmissions at the radio link coding sublayer are based on L2 packets or L2 packet sets. The packet coding and decoding occurs at the radio link coding sublayer, at which a sequence number is assigned for each encoded packet. Advantageously, packet coding parameters such as redundancy level and size, may be based on channel conditions or reception status.

[0069] The radio link coding sublayer may be configured to apply radio link coding for a specific radio bearer (e.g. to corresponding to traffic of a particular user) that depends on the quality of service requirements for that radio bearer (e.g. latency or data throughput requirements).

[0070] Fig. 7 shows a packet stream of K packets at the PDCP sublayer. A coded packet stream is generated at the radio link coding sublayer, in which different redundancy levels can be applied to different packets or groups of packets (in other words, the packets or packet sets (or packet 'groups') are coded with redundancy in a selective manner to generate the coded packet stream, which can be based on the importance of the packets or packet sets). For example, as shown in Fig. 7 packet 1 and packet 3 are transmitted twice, whereas packet 2 is transmitted only once. The coded packet stream is then transmitted (by the UE 3 or the base station 5) to the receiver (via the MAC sublayer and the PHY layer).

[0071] Fig. 8 shows a further example of radio link coding at the radio link coding sublayer. As shown in Fig. 7, packet segmentation or concatenation is performed at the PDCP sublayer, and coding to generate a set of N' encoded packets is performed at the radio link coding sublayer. In this example, the number of N' encoded packets is determined based on the number of K packets to be encoded using the formula: N' = K × (1 + x) where x is a parameter that corresponds to the increase in the number of packets (e.g. x = 0.05 corresponds to a 5% increase in the number of packets). In this example, the packets or packet sets can be coded with redundancy using a particular algorithm (or 'dictionary') that is known at both the transmitter and the receiver.

[0072] In the examples illustrated in Figs. 7 and 8, the transmitter (which could be either the UE 3 or the base station 5) determines a redundancy level to use for each L2 packet or L2 packet set (group of L2 packets). The transmitter also determines whether feedback-based transmission or non-feedback-based transmission is to be performed.

[0073] For the case of feedback-based transmission, the transmitter can determine to continue to transmit the redundant coded packet stream in the transmission window until positive feedback is received for the transmitted packets. If positive feedback (ACK) is received for a packet or packet set, then the transmission window is pushed forward, and the packet or packet set is removed from the transmission window. Alternatively, packets may be retransmitted until the expiry of a timer (e.g. a dedicated timer), or until a drop request corresponding to the packets is received from an upper (higher) layer.

[0074] At the transmitter, the output of one coding sublayer entity can be multiplexed with the output from another coding sublayer entity (or with data from a conventional protocol stack) to generate the MAC PDUs and the TBs for PHY layer transmission.

[0075] The radio link coding sublayer at the transmitter may determine a reference redundancy level for the packet flow for a particular service based on a quality of service requirement (e.g., the importance of a packet or packet set within a particular QoS flow). Alternatively, for example, the radio link coding sublayer at the transmitter may determine a reference redundancy level based on an inference generated using an artificial intelligence and machine learning (AI / ML) model (e.g. an AI / ML model that can generate a prediction of the channel quality). The transmitter may also determine a dynamic redundancy level to use for the packets. Advantageously, dynamic adaptation of the redundancy level at L2 increases the data throughput capacity (since a fixed redundancy level can result in unnecessary redundant transmissions). The radio link coding sublayer may be configured to initially use a pessimistic (or conservative) redundancy level for the transmission of the packets, and to switch to using a more aggressive (less redundancy) redundancy level based on positive feedback (ACK) received from the receiver.

[0076] In a first option, the dynamic redundancy level is recalculated based on the channel quality (e.g. downlink channel quality), or adjusted dynamically during the data transmission based on an inference output by an AI / ML model with the ability to predict the channel quality or reception quality. Advantageously, this enables proactive adjustment (self-adjustment) of the redundancy level (e.g. without the need for an actual measurement of the channel quality).

[0077] In a second option, the transmitter performs importance-based redundant transmission, in which only a subset of the packets is transmitted redundantly based on the importance of the packets (of groups of packets). The importance-based redundant transmission could be based on the absolute importance of each packet or packet set, or the relative importance of the packets to be transmitted.

[0078] In a third option, timer-based redundant transmission could be used. For a particular packet or packet set, the radio link coding sublayer at the transmitter may continue to retransmit a packet or packet set until the expiry of a timer (e.g. a dedicated timer), which could be based on a Packet Delay Budget (PDB) that defines an upper limit for the time that a packet may be delayed, or based on a Packet Set Delay Budget (PSDB) that defines an upper limit for the time that a packet set may be delayed.

[0079] In a fourth option feedback-based redundant transmission could be used. For a particular packet or packet set, the radio link coding sublayer at the transmitter may continue to retransmit a packet or packet set until an acknowledgement (ACK) for that packet or packet set is received from the receiver (transmission of the feedback may be relatively slow compared to the duration of the transmission window, and the transmitter may transmit the packets a determined number of times until positive feedback is received).

[0080] In a fifth option, 'dictionary' or algorithm based redundant transmission could be used. In this option, an algorithm (e.g., based on a type of fountain codes) is used to generate the coded packets based on the original packets (as illustrated in Fig. 8, in which a set of N' coded packets is generated based on a set of K original packets).

[0081] Any combination of the first to fifth options could also be used. For example, the timer-based redundant transmission of the third option could be combined with the feedback-based redundant transmission of the fourth option, in which case a packet or set of packets could be retransmitted until either expiry of the timer or until positive feedback is received from the receiver.

[0082] At the receiver (the UE 3 when the base station 5 is the transmitter, or the base station 5 when the UE 3 is the transmitter) a decoding window is maintained that corresponds to the coding window determined by the transmitter. The transmitter transmits an indication of the determined coding window to the receiver (for example, the coding length of the coding window, which could be indicated based on RLC SDU SN). In order to achieve aligned operation between the receiver and the transmitter, the transmitter may also transmit a notification to the receiver of the start of a new decoding window, or the end of the previous decoding window (which could be indicated using a RLC SDU SN). At the receiver, the radio link coding sublayer can deliver the received packets to an upper layer once all of the packets corresponding to the decoding window have been decoded, or upon expiry of a timer (e.g. a dedicated timer). The reception buffer can be flushed when the packets corresponding to the previous decoding window have been decoded and successfully delivered to the upper layer, if one or more packets corresponding to the next decoding window are received, or upon expiry of a timer (e.g. a dedicated timer).

[0083] Packet Coding at PDCP Sublayer 　　An example in which a network coding function block is advantageously introduced at the PDCP layer will now be described. Beneficially, the packet coding implemented at the PDCP layer improves transmission reliability.

[0084] In this example, at the transmitter (which could be the UE 3 or the base station 5), the packet coding occurs at the PDCP sublayer rather than at a lower layer. The packet coding can be based on PDCP SDUs, the segmentation of one PDCP SDU, or the concatenation of a plurality of PDCP SDUs. The length of the coding (coding length), or the length of the coding window, is determined at the PDCP sublayer based on the SNs of the PDCP SDUs, the segmentation of one PDCP SDU, or the concatenation of a plurality of PDCP SDUs. The original packets (that are used to generate the encoded packets at the PDCP sublayer) are used to generate parity packets at the PDCP sublayer. The 'K' original packets can be used to derive the additional 'M' parity packets to be transmitted to the receiver (e.g. in a manner analogous to LDPC). At the transmitter, the original K packets and the M parity packets may be processed using different RLC entities based on a determination made at the PDCP sublayer. The original K packets may be transmitted using the RLC entity of a primary communication link (e.g. primary cell, primary frequency layer or frequency resource, or primary path), and the M parity packets may be transmitted using the RLC entity of a secondary communication link (e.g. secondary cell, secondary frequency layer or frequency resource, or secondary path). At the receiver, the PDCP sublayer receives the packets transmitted via the primary communication link and the packets transmitted via the secondary communication link, and uses the packets received via both links to decode the received data.

[0085] At the receiver, a decoding window is maintained that corresponds to the coding window determined at the transmitter. The transmitter provides an indication to the receiver of the determined coding window (e.g. a determined coding window parameter such as the coding length in terms of PDCP SDU SN). In order to achieve aligned operation between the receiver and the transmitter, the transmitter may transmit, to the receiver, an indication of the start of a new decoding window or the end of the previous decoding window (e.g. in terms of PDCP SDU SN). At the receiver, the PDCP sublayer can deliver packets to an upper (higher) layer when all of the packets within the decoding window have been successfully decoded. Alternatively the packets may be delivered to the upper layer based on the expiry of a timer (e.g. a dedicated timer). At the PDCP layer of the receiver the reception layer can be flushed when packets of the previous (de)coding window have been decoded and successfully delivered to the upper layer, if one or more packets corresponding to the next (de)coding window are received, or upon expiry of a timer (e.g. a dedicated timer).

[0086] User Equipment 　　Fig. 9 is a schematic block diagram illustrating the main components of a UE 3 as shown in Fig. 1.

[0087] As shown, the UE 3 has a transceiver circuit 310 that is operable to transmit signals to and to receive signals from a base station 5 via one or more antenna 330 (e.g., comprising one or more antenna elements). The UE 3 has a controller 370 to control the operation of the UE 3. The controller 370 is associated with a memory 390 and is coupled to the transceiver circuit 310. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE 3 (e.g. a user interface 35b, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 390 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0088] The controller 370 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 390. As shown, these software instructions include, among other things, an operating system 410, a communications control module 430, and an L1 / L2 mobility module 450.

[0089] The communications control module 430 is operable to control the communication between the UE 3 and its one or more serving base stations 5 (and other communication devices connected to the base station 5, such as further UEs and / or core network nodes). The communications control module 430 is configured for the overall handling uplink communications via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communications control module 430 is also configured for the overall handling of receipt of downlink communications via associated downlink channels (e.g. via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS). The communications control module 430 is responsible, for example: for determining where to monitor for downlink control information (e.g., the location of CSSs / USSs, CORESETs, and associated PDCCH candidates to monitor); for determining the resources to be used by the UE 3 for transmission / reception of UL / DL communications (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots / symbols are configured (e.g., for UL, DL or SBFD communication, or the like); for determining which one or more bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded; for applying any SBFD specific communication configurations appropriately; and the like. The communications control module 430 may be configured to control communications in accordance with any of the methods described above (for example, to transmit feedback (e.g. ACK / NACK) according to any of the methods described above).

[0090] The L1 / L2 mobility module 450 is responsible for performing control for L1 / L2 mobility. For example, the L1 / L2 mobility module 450 may be configured to perform one or more measurements for L1 / L2 mobility, or to select a candidate cell for handover. It will be appreciated that the L1 / L2 mobility module 450 may be configured to perform control as part of any of the L1 / L2 mobility methods described above.

[0091] RAN (Distributed Type) 　　Fig. 10 is a simplified block schematic illustrating the main components of a distributed RAN comprising a distributed type of base station 5 for implementation in the system of Fig. 1.

[0092] As shown, the RAN includes a central unit 5c and a distributed unit 5b (although it may include other DUs as described above). Each unit 5c, 5b includes respective transceiver circuitry 51c, 51b.

[0093] The distributed unit 5b transceiver circuitry 51b is operable to transmit signals to and to receive signals from UEs 3 via an air interface 53b and one or more antennas and is also operable to transmit signals to and to receive signals from the central unit 5c via an interface, for example the distributed unit side of an F1 interface (which may be provided over a satellite radio interface).

[0094] The central unit 5c transceiver circuitry 51c is operable to transmit signals to and to receive signals from functions of the core network 7 and / or other RANs via a network interface 55c. The network interface typically includes an N2 and / or N3 interfaces for communicating with the core network and a base station to base station (e.g. Xn) interface for communicating with other RANs. The central unit 5c transceiver circuitry 51c is also operable to transmit signals to and to receive signals from one or more distributed units 5b, for example the central unit side of the F1 interface provided.

[0095] Each unit 5c, 5b includes a respective controller 57c, 57b which controls the operation of the corresponding transceiver circuitry 51c, 51b in accordance with software stored in the respective memories 59c and 59b of the distributed unit 5b and the central unit 5c. The software of each unit may be pre-installed in the memory 59c, 59b and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The software of each unit includes, among other things, a respective operating system 61c, 61b, a respective communications control module 63c, 63b and an L1 / L2 mobility module 65c, 65b.

[0096] Each communications control module 63c, 63b is operable to control the communication of its corresponding unit 5c, 5b including the communication from one unit to the other. The communications control module 63b of the distributed unit 5b controls communication between the distributed unit 5b and the UEs 3, and the communications control module 63c of the central unit 5c controls communication between the central unit 5c and other network entities that are connected to the distributed RAN.

[0097] The communications control modules 63c, 63b also respectively control the part played by the distributed unit 5b and central unit 5c in the flow of uplink and downlink user traffic and control data to be transmitted to the communications devices served by the RAN including, for example, control data for managing operation of the UEs 3. Each communication control module 63c, 63b is responsible, for example, for controlling the respective part played by the distributed unit 5b and central unit 5c in the reception and decoding of uplink communications, via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). Each communication control module 63c, 63b is responsible for controlling the respective part played by the distributed unit 5b and central unit 5c in the transmission of downlink communications via associated downlink channels (e.g. via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.).

[0098] It will be appreciated that the communications control modules 63b, 63c may also include a number of sub-modules (or layers) to support specific functionalities for the corresponding unit 5c, 5b. The modules included will depend on how the corresponding unit 5c, 5b is configured (e.g., the precise CU-DU split). For example, the communications control modules 63c of the distributed unit 5b may include a PHY sub-module, a MAC sub-module, and an RLC sub-module, whereas the communications control modules 63c of the central unit 5c may include a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc. The communication control modules 63b, 63c, may perform control as part of any of the methods described above (for example to provide the air interface protocols, or methods of feedback-based retransmission, described above).

[0099] The L1 / L2 mobility modules 65c, 65b are responsible for performing control for L1 / L2 mobility. For example, the L1 / L2 mobility module 65c, 65b may be configured to perform one or more measurements for L1 / L2 mobility, or to select a candidate cell for handover. It will be appreciated that the L1 / L2 mobility module 65c, 65b may be configured to perform control as part of any of the L1 / L2 mobility methods described above.

[0100] Core Network Node / Function 　　Fig. 11 is a block diagram illustrating the main components of a core network node or function, such as the AMF, CPF, the UPF, the SMF or OAM. As shown, the core network function includes a transceiver circuit 710 which is operable to transmit signals to and to receive signals from other nodes (including the UE 3, the base station 5, and other core network nodes) via a network interface 720. A controller 730 controls the operation of the core network function in accordance with software stored in a memory 740. The software may be pre-installed in the memory 740 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 750, and a communications control module 760.

[0101] The communications control module 760 is responsible for handling (generating / sending / receiving) signalling between the core network function and other nodes, such as the UE 3, the base station 5, and other core network nodes, and may perform control according to any of the methods described above.

[0102] Modifications and Alternatives 　　As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above examples whilst still benefiting from the inventions therein.

[0103] It will be appreciated, for example, that whilst cellular communication generation (2G, 3G, 4G, 5G, 6G etc.) specific terminology may be used, in the interests of clarity, to refer to specific communication entities, the technical features described for a given entity are not limited to devices of that specific communication generation. The technical features may be implemented in any functionally equivalent communication entity regardless of any differences in the terminology used to refer to them.

[0104] In the above description, the UEs and the base station are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosure, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

[0105] In the above detailed examples, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the base station or the UE in order to update their functionalities.

[0106] Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input / output (IO) circuits; internal memories / caches (program and / or data); processing registers; communication buses (e.g. control, data and / or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and / or timers; and / or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0107] The User Equipment (or "UE", "mobile station", "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

[0108] It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

[0109] The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for a long period of time.

[0110] A UE may, for example, be an item of equipment for production or manufacture and / or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and / or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and / or their application systems; tools; molds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper converting machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or implements for agriculture, forestry and / or fisheries; safety and / or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and / or application systems for any of the previously mentioned equipment or machinery etc.).

[0111] A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.). A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

[0112] A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

[0113] A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

[0114] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like.

[0115] A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

[0116] A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)", using a variety of wired and / or wireless communication technologies.

[0117] Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and / or inactive for a long period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored / tracked.

[0118] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communications network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0119] It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

[0120] Applications, services, and solutions may be an MVNO (Mobile Virtual Network Operator) service, an emergency radio communication system, a PBX (Private Branch eXchange) system, a PHS / Digital Cordless Telecommunications system, a POS (Point of sale) system, an advertise calling system, an MBMS (Multimedia Broadcast and Multicast Service), a V2X (Vehicle to Everything) system, a train radio system, a location related service, a Disaster / Emergency Wireless Communication Service, a community service, a video streaming service, a femto cell application service, a VoLTE (Voice over LTE) service, a charging service, a radio on demand service, a roaming service, an activity monitoring service, a telecom carrier / communication NW selection service, a functional restriction service, a PoC (Proof of Concept) service, a personal information management service, an ad-hoc network / DTN (Delay Tolerant Networking) service, etc.

[0121] Further, the above-described UE categories are merely examples of applications of the technical ideas described in the present document. Needless to say, these technical ideas are not limited to the above-described UE and various modifications can be made thereto.

[0122] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0123] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　　　(Supplementary note 1) 　　A method performed by a first communication apparatus, the method comprising: 　　receiving, from a second communication apparatus, at most predetermined number of transmission blocks (TBs) per transmission occasion, wherein each TB of the at most predetermined number of TBs has redundant information indicating whether the each TB is redandand version or not; 　　buffering the at most predetermined number of TBs in a case where decoding at least one of the at most predetermined number of TBs is failed, until at least one condition is met; 　　decoding received TBs using at most predetermined number of TBs received at a current transmission occasion and buffered at most predetermined number of TBs received previous transmission occasions before the current transmission occasion. 　　　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　each TB of the at most predetermined number of TBs has a respective sequence number, and 　　the decoding is performed based on the respective sequence number and the redundant information of the each TB. 　　　　(Supplementary note 3) 　　The method according to supplementary note 2, wherein 　　a maximum number of the respective sequence number is 16, and 　　the respective sequence number is represented by 4 bit information. 　　　　(Supplementary note 4) 　　The method according to supplementary note 2 or 3, wherein 　　a TB having redundant information indicating that the TB is redandand version is transmitted based on radio channel quality between the first communication apparatus and the second communication apparatus. 　　　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　the at least one condition includes at least one of: 　　　　the decoding the at most predetemined number of TBs has been completed, 　　　　the at least one of the at most predetermined number of TBs on which decoding was failed is not received in the current transmission occasion, or 　　　　a timer is expired. 　　　　(Supplementary note 6) 　　The method according to any one of supplementary notes 1 to 5, further comprising: 　　flushing a buffer in a case where the at least one condition is met. 　　　　(Supplementary note 7) 　　The method according to any one of supplementary notes 1 to 6, further comprising: 　　receiving, from the second communication apparatus, information for a transmission window indicating which TBs will be transmitted at the current transmission occasion, and wherein 　　at least one of the buffering or the decoding is performed based on the transmission window. 　　　　(Supplementary note 8) 　　The method according to supplementary note 7, wherein 　　the information for the transmission window is transmitted by control information. 　　　　(Supplementary note 9) 　　The method according to any one of supplementary notes 1 to 8, wherein 　　the at most predetermined number of TBs are encoded jointly or individually for each TB. 　　　　(Supplementary note 10) 　　The method according to any one of supplementary notes 1 to 9, further comprising: 　　transmitting, to the second communication apparatus, feedback information indicating whether each TB is successfully received or not, and wherein 　　TB having information indicating that the TB is redandand version is transmitted until at least one condition is met. 　　　　(Supplementary note 11) 　　The method according to supplementary note 10, wherein 　　the at least one condition includes at least one of: 　　　　feedback information indicating that the TB is successfilly received is transmitted, 　　　　a timer expires, or 　　　　a request for dropping the TS is transmitted via layer-2 signaling. 　　　　(Supplementary note 12) 　　The method according to supplementary note 10 or 11, wherein 　　at least one TB transmitted in the current transmission occasion is changed before in a case where the at least one condition is met. 　　　　(Supplementary note 13) 　　A method performed by a first communication apparatus, the method comprising: 　　receiving, from a second communication apparatus, a redundant data stream, wherein: 　　　　the redundant data stream includes at least one respective data unit, and 　　　　the at least one respective data unit includes a specific number of redundant data units that are a same data as one data unit; 　　decoding the one data unit using the specific number of redundant data units; and 　　transmitting, to the second communication apparatus, a positive feedback indicating that the one data unit has been successfully received. 　　　　(Supplementary note 14) 　　The method according to supplementary note 13, wherein 　　the specific number is determined by at least one of: 　　　　a channel condition between the first communication apparatus and the second communication apparatus, 　　　　a reception status on the first communication apparatus, 　　　　artificial intelligence / machine learning (AI / ML) algorithms used for predicting the channel condition or the reception status, 　　　　importance of a respective data unit, 　　　　a timer, 　　　　a packet delay budget, 　　　　a positive feedback indicating the the one data unit has been successfully received, or 　　　　an algorithm used to encode a respective data unit. 　　　　(Supplementary note 15) 　　The method according to supplementary note 13 or 14, wherein 　　the specific number of redundant data units are transmitted until at least one condition is met. 　　　　(Supplementary note 16) 　　The method according to supplementary note 15, wherein 　　the at least one condition includes at least one of: 　　　　feedback information indicating that the one data unit is successfilly received is transmitted, 　　　　a timer expires, or 　　　　a request for dropping the one data unit is transmitted via upper layer signaling. 　　　　(Supplementary note 17) 　　The method according to any one of supplementary notes 13 to 16, wherein 　　each data unit includes at least one of: 　　　　a radio link control (RLC) service data unit (SDU), or 　　　　a packet data convergence protocol (PDCP) SDU. 　　　　(Supplementary note 18) 　　The method according to any one of supplementary notes 13 to 17, wherein 　　the receiving is performed at a radio link control (RLC) layer or a packet data convergence protocol (PDCP) layer. 　　　　(Supplementary note 19) 　　The method according to any one of supplementary notes 13 to 18, wherein 　　te receiving is performed based on quality of service (QoS) requirement on a specific radio bearer. 　　　　(Supplementary note 20) 　　The method according to any one of supplementary notes 13 to 19, wherein 　　each of the at least one respective data unit has a same sequence number as a sequence number of the one data unit, and the method further comprises: 　　receiving, from the second communication apparatus, a number of data units which the first communication apparatus should decode as information of a specific sequence number. 　　　　(Supplementary note 21) 　　A method performed by a second communication apparatus, the method comprising: 　　transmitting, to a first communication apparatus, at most predetermined number of transmission blocks (TBs) per transmission occasion, wherein each TB included in the at most predetermined number of TBs has redundant information indicating whether the each TB is redandand version or not, wherein 　　the at most predetermined number of TBs is beffered by the first communication apparatus in a case where decoding, by the first communication apparatus, at least one of the at most predetermined number of TBs is failed, until at least one condition is met. 　　　　(Supplementary note 22) 　　A method performed by a second communication apparatus, the method comprising: 　　transmitting, to a first communication apparatus, a redundant data stream, wherein: 　　　　the redundant data stream includes at least one respective data unit, and 　　　　the at least one respective data unit includes a specific number of redundant data units that are a same data as one data unit; and 　　receiving, from the first communication apparatus, a positive feedback indicating that the one data unit has been successfully received. 　　　　(Supplementary note 23) 　　The method according to any one of supplementary notes 1 to 22, wherein 　　the first communication apparatus includes a user equipment (UE) or an access network node. 　　　　(Supplementary note 24) 　　The method according to any one of supplementary notes 1 to 23, wherein 　　the second communication apparatus includes a user equipment (UE) or an access network node. 　　　　(Supplementary note 25) 　　A first communication apparatus comprising: 　　means for receiving, from a second communication apparatus, at most predetermined number of transmission blocks (TBs) per transmission occasion, wherein each TB of the at most predetermined number of TBs has redundant information indicating whether the each TB is redandand version or not; 　　means for buffering the at most predetermined number of TBs in a case where decoding at least one of the at most predetermined number of TBs is failed, until at least one condition is met; 　　means for decoding received TBs using at most predetermined number of TBs received at a current transmission occasion and buffered at most predetermined number of TBs received previous transmission occasions before the current transmission occasion. 　　　　(Supplementary note 26) 　　A first communication apparatus comprising: 　　means for receiving, from a second communication apparatus, a redundant data stream, wherein: 　　　　the redundant data stream includes at least one respective data unit, and 　　　　the at least one respective data unit includes a specific number of redundant data units that are a same data as one data unit; 　　means for decoding the one data unit using the specific number of redundant data units; and 　　means for transmitting, to the second communication apparatus, a positive feedback indicating that the one data unit has been successfully received. 　　　　(Supplementary note 27) 　　A second communication apparatus comprising: 　　means for transmitting, to a first communication apparatus, at most predetermined number of transmission blocks (TBs) per transmission occasion, wherein each TB included in the at most predetermined number of TBs has redundant information indicating whether the each TB is redandand version or not, wherein 　　the at most predetermined number of TBs is beffered by the first communication apparatus in a case where decoding, by the first communication apparatus, at least one of the at most predetermined number of TBs is failed, until at least one condition is met. 　　　　(Supplementary note 28) 　　A second communication apparatus comprising: 　　means for transmitting, to a first communication apparatus, a redundant data stream, wherein: 　　　　the redundant data stream includes at least one respective data unit, and 　　　　the at least one respective data unit includes a specific number of redundant data units that are a same data as one data unit; and 　　means for receiving, from the first communication apparatus, a positive feedback indicating that the one data unit has been successfully received.

[0124] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2312577.6, filed on August 17, 2023, the disclosure of which is incorporated herein in its entirety by reference.

[0125] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 BASE STATION 5b DISTRIBUTED UNIT (DU) 5c CENTRAL UNIT (CU) 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 20 EXTERNAL DATA NETWORK 310 TRANSCEIVER CIRCUIT 330 ANTENNA 350 USER INTERFACE 370 CONTROLLER 390 MEMORY 410 OPERATING SYSTEM 430 COMMUNICATIONS CONTROL MODULE 51b TRANSCEIVER CIRCUIT (DU) 51c TRANSCEIVER CIRCUIT (CU) 53b AIR INTERFACE 55c NETWORK INTERFACE 57b DU CONTROLLER 57c UC CONTROLLER 59b DU MEMORY 59c CU MEMORY 61b DU OPERATING SYSTEM 61c CU OPERATING SYSTEM 63b DU MOMMUNICATIONS CONTROL MODULE 63c CU MOMMUNICATIONS CONTROL MODULE 710 TRANSCEIVER CIRCUIT 720 NETWORK INTERFACE 730 CONTROLLER 740 MEMORY 750 OPERATING SYSTEM 760 COMMUNICATIONS CONTROL MODULE

Claims

1. A method performed by a first communication apparatus, the method comprising: 　　receiving, from a second communication apparatus, at most predetermined number of transmission blocks (TBs) per transmission occasion, wherein each TB of the at most predetermined number of TBs has redundant information indicating whether the each TB is redandand version or not; 　　buffering the at most predetermined number of TBs in a case where decoding at least one of the at most predetermined number of TBs is failed, until at least one condition is met; 　　decoding received TBs using at most predetermined number of TBs received at a current transmission occasion and buffered at most predetermined number of TBs received previous transmission occasions before the current transmission occasion.

2. The method according to claim 1, wherein 　　each TB of the at most predetermined number of TBs has a respective sequence number, and 　　the decoding is performed based on the respective sequence number and the redundant information of the each TB.

3. The method according to claim 2, wherein 　　a maximum number of the respective sequence number is 16, and 　　the respective sequence number is represented by 4 bit information.

4. The method according to claim 2 or 3, wherein 　　a TB having redundant information indicating that the TB is redandand version is transmitted based on radio channel quality between the first communication apparatus and the second communication apparatus.

5. The method according to any one of claims 1 to 4, wherein 　　the at least one condition includes at least one of: 　　　　the decoding the at most predetemined number of TBs has been completed, 　　　　the at least one of the at most predetermined number of TBs on which decoding was failed is not received in the current transmission occasion, or 　　　　a timer is expired.

6. The method according to any one of claims 1 to 5, further comprising: 　　flushing a buffer in a case where the at least one condition is met.

7. The method according to any one of claims 1 to 6, further comprising: 　　receiving, from the second communication apparatus, information for a transmission window indicating which TBs will be transmitted at the current transmission occasion, and wherein 　　at least one of the buffering or the decoding is performed based on the transmission window.

8. The method according to claim 7, wherein 　　the information for the transmission window is transmitted by control information.

9. The method according to any one of claims 1 to 8, wherein 　　the at most predetermined number of TBs are encoded jointly or individually for each TB.

10. The method according to any one of claims 1 to 9, further comprising: 　　transmitting, to the second communication apparatus, feedback information indicating whether each TB is successfully received or not, and wherein 　　TB having information indicating that the TB is redandand version is transmitted until at least one condition is met.

11. The method according to claim 10, wherein 　　the at least one condition includes at least one of: 　　　　feedback information indicating that the TB is successfilly received is transmitted, 　　　　a timer expires, or 　　　　a request for dropping the TS is transmitted via layer-2 signaling.

12. The method according to claim 10 or 11, wherein 　　at least one TB transmitted in the current transmission occasion is changed before in a case where the at least one condition is met.

13. A method performed by a first communication apparatus, the method comprising: 　　receiving, from a second communication apparatus, a redundant data stream, wherein: 　　　　the redundant data stream includes at least one respective data unit, and 　　　　the at least one respective data unit includes a specific number of redundant data units that are a same data as one data unit; 　　decoding the one data unit using the specific number of redundant data units; and 　　transmitting, to the second communication apparatus, a positive feedback indicating that the one data unit has been successfully received.

14. The method according to claim 13, wherein 　　the specific number is determined by at least one of: 　　　　a channel condition between the first communication apparatus and the second communication apparatus, 　　　　a reception status on the first communication apparatus, 　　　　artificial intelligence / machine learning (AI / ML) algorithms used for predicting the channel condition or the reception status, 　　　　importance of a respective data unit, 　　　　a timer, 　　　　a packet delay budget, 　　　　a positive feedback indicating the the one data unit has been successfully received, or 　　　　an algorithm used to encode a respective data unit.

15. The method according to claim 13 or 14, wherein 　　the specific number of redundant data units are transmitted until at least one condition is met.

16. The method according to claim 15, wherein 　　the at least one condition includes at least one of: 　　　　feedback information indicating that the one data unit is successfilly received is transmitted, 　　　　a timer expires, or 　　　　a request for dropping the one data unit is transmitted via upper layer signaling.

17. The method according to any one of claims 13 to 16, wherein 　　each data unit includes at least one of: 　　　　a radio link control (RLC) service data unit (SDU), or 　　　　a packet data convergence protocol (PDCP) SDU.

18. The method according to any one of claims 13 to 17, wherein 　　the receiving is performed at a radio link control (RLC) layer or a packet data convergence protocol (PDCP) layer.

19. The method according to any one of claims 13 to 18, wherein 　　te receiving is performed based on quality of service (QoS) requirement on a specific radio bearer.

20. The method according to any one of claims 13 to 19, wherein 　　each of the at least one respective data unit has a same sequence number as a sequence number of the one data unit, and the method further comprises: 　　receiving, from the second communication apparatus, a number of data units which the first communication apparatus should decode as information of a specific sequence number.

21. A method performed by a second communication apparatus, the method comprising: 　　transmitting, to a first communication apparatus, at most predetermined number of transmission blocks (TBs) per transmission occasion, wherein each TB included in the at most predetermined number of TBs has redundant information indicating whether the each TB is redandand version or not, wherein 　　the at most predetermined number of TBs is beffered by the first communication apparatus in a case where decoding, by the first communication apparatus, at least one of the at most predetermined number of TBs is failed, until at least one condition is met.

22. A method performed by a second communication apparatus, the method comprising: 　　transmitting, to a first communication apparatus, a redundant data stream, wherein: 　　　　the redundant data stream includes at least one respective data unit, and 　　　　the at least one respective data unit includes a specific number of redundant data units that are a same data as one data unit; and 　　receiving, from the first communication apparatus, a positive feedback indicating that the one data unit has been successfully received.

23. The method according to any one of claims 1 to 22, wherein 　　the first communication apparatus includes a user equipment (UE) or an access network node.

24. The method according to any one of claims 1 to 23, wherein 　　the second communication apparatus includes a user equipment (UE) or an access network node.

25. A first communication apparatus comprising: 　　means for receiving, from a second communication apparatus, at most predetermined number of transmission blocks (TBs) per transmission occasion, wherein each TB of the at most predetermined number of TBs has redundant information indicating whether the each TB is redandand version or not; 　　means for buffering the at most predetermined number of TBs in a case where decoding at least one of the at most predetermined number of TBs is failed, until at least one condition is met; 　　means for decoding received TBs using at most predetermined number of TBs received at a current transmission occasion and buffered at most predetermined number of TBs received previous transmission occasions before the current transmission occasion.

26. A first communication apparatus comprising: 　　means for receiving, from a second communication apparatus, a redundant data stream, wherein: 　　　　the redundant data stream includes at least one respective data unit, and 　　　　the at least one respective data unit includes a specific number of redundant data units that are a same data as one data unit; 　　means for decoding the one data unit using the specific number of redundant data units; and 　　means for transmitting, to the second communication apparatus, a positive feedback indicating that the one data unit has been successfully received.

27. A second communication apparatus comprising: 　　means for transmitting, to a first communication apparatus, at most predetermined number of transmission blocks (TBs) per transmission occasion, wherein each TB included in the at most predetermined number of TBs has redundant information indicating whether the each TB is redandand version or not, wherein 　　the at most predetermined number of TBs is beffered by the first communication apparatus in a case where decoding, by the first communication apparatus, at least one of the at most predetermined number of TBs is failed, until at least one condition is met.

28. A second communication apparatus comprising: 　　means for transmitting, to a first communication apparatus, a redundant data stream, wherein: 　　　　the redundant data stream includes at least one respective data unit, and 　　　　the at least one respective data unit includes a specific number of redundant data units that are a same data as one data unit; and 　　means for receiving, from the first communication apparatus, a positive feedback indicating that the one data unit has been successfully received.

Images