Method, communication apparatus and receiving entity

Abstract

The present disclosure relates to a method performed by a communication apparatus. The method comprising: transmitting a Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set; starting a discard timer; performing at least one automatic repeat request (ARQ) retransmission of the RLC SDU in a case where the communication apparatus receives information indicating a specific RLC SDU is not received successfully and the discard timer is running; and stopping the at least one ARQ retransmission in a case where at least one of: the discard timer has been expired, a discard indication for the specific RLC SDU has been obtained from a Packet Data Convergence Protocol (PDCP) layer, or a number of the at least one ARQ retransmission has reached to a specific number.

Description

METHOD, COMMUNICATION APPARATUS AND RECEIVING ENTITY

[0001] The present disclosure relates to a communication system. 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 Long Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The disclosure has particular, although not necessarily exclusive, relevance to radio link control (RLC) acknowledge mode (AM) and unacknowledged mode (UM) in 'New Radio' systems (also referred to as 'Next Generation' systems), and similar systems.

[0002] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved Universal mobile Telecommunications System (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, NPL 1. 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.

[0003] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is a 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.

[0004] Also, for simplicity, the present application will use a term mobile device, a user device, or the 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 communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0005] In the current 5G architecture, the gNB structure may be split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of gNBs may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each gNB.

[0006] The next-generation mobile networks support diversified service requirements, which have been classified into three categories by the International Telecommunication Union (ITU): Enhanced Mobile Broadband (eMBB); Ultra-Reliable and Low-Latency Communications (URLLC); and Massive Machine Type Communications (mMTC). eMBB aims to provide enhanced support of conventional mobile broadband, with focus on services requiring large and guaranteed bandwidth such as High Definition (HD) video, Virtual Reality (VR), and Augmented Reality (AR). URLLC is a requirement for critical applications such as automated driving and factory automation, which require guaranteed access within a very short time. MMTC needs to support massive number of connected devices such as smart metering and environment monitoring but can usually tolerate certain access delay. It will be appreciated that some of these applications may have relatively lenient Quality of Service / Quality of Experience (QoS / QoE) requirements, while some applications may have relatively stringent QoS / QoE requirements (e.g. high bandwidth and / or low latency).

[0007] 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. NPL 2 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 NPL 3.

[0008] NPL 1: Next Generation Mobile Networks (NGMN) Alliance, 'NGMN 5G White Paper' V1.0, February 17, 2015 <https: / / www.ngmn.org / 5g-white-paper.html> NPL 2: 3GPP Technical Report (TR) 26.928 V16.1.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Extended Reality (XR) in 5G (Release 16), December 23, 2020 NPL 3: 3GPP TS 26.501 V16.9.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 5G Media Streaming (5GMS); General description and architecture (Release 16), April 7, 2022

[0009] In addition to the conventional service category, interactive, streaming, download, and split compute / rendering are identified as new delivery categories for XR. XR implementations present challenging service requirements, and there is a need for more efficient and reliable use of communication resources.

[0010] In a wireless communication link, some of the transmitted packets may be lost, or may be subject to errors introduced by noise or interference. The Hybrid Automatic Repeat Request (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 can similarly be used for uplink transmissions from the UE to the base station. The RLC-AM mode is useful for improving the reliability of communication by reducing data loss further. However, there is a problem that RLC-AM feedback or retransmission triggering mechanisms are not well adapted for the short packet delay budgets (PDB) applicable to XR traffic.

[0011] There is a need, therefore, for the development of improved communication devices (such as base stations and / or UEs), and corresponding methods, that support more efficient and robust mechanisms for RLC re-transmission, for example for (but not limited to) RLC-AM mode.

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

[0013] In one aspect there is provided a method performed by a communication apparatus, the method comprising: transmitting a Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set; starting a discard timer; performing an automatic repeat request (ARQ) retransmission of the RLC SDU in a case where the communication apparatus receives information indicating a specific RLC SDU is not received successfully and the discard timer is running; and stopping the ARQ retransmission in a case where at least one of: the discard timer has been expired, a discard indication for the specific RLC SDU has been obtained from a Packet Data Convergence Protocol (PDCP) layer, or a number of the at least one ARQ retransmission has reached to a specific number.

[0014] In one aspect there is provided a method performed by a receiving entity, the method comprising: transmitting, to a communication apparatus, information indicating a specific Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set is not received successfully; and receiving, from the communication apparatus, the specific RLC SDU via an automatic repeat request (ARQ) retransmission of the specific RLC SDU, and wherein the ARQ retransmission is stopped, by the communication apparatus, in a case where at least one of: a discard timer at the communication apparatus has been expired, a discard indication for the specific RLC SDU has been obtained, by the communication apparatus, from a Packet Data Convergence Protocol (PDCP) layer, or a number of the at least one ARQ retransmission has reached to a specific number.

[0015] In one aspect there is provided a communication apparatus comprising: means for transmitting a Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set; means for starting a discard timer; means for performing an automatic repeat request (ARQ) retransmission of the RLC SDU in a case where the communication apparatus receives information indicating a specific RLC SDU is not received successfully and the discard timer is running; and means for stopping the ARQ retransmission in a case where at least one of: the discard timer has been expired, a discard indication for the specific RLC SDU has been obtained from a Packet Data Convergence Protocol (PDCP) layer, or a number of the at least one ARQ retransmission has reached to a specific number.

[0016] In one aspect there is provided a receiving entity comprising: means for transmitting, to a communication apparatus, information indicating a specific Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set is not received successfully; and means for receiving, from the communication apparatus, the specific RLC SDU via an automatic repeat request (ARQ) retransmission of the specific RLC SDU, and wherein the ARQ retransmission is stopped, by the communication apparatus, in a case where at least one of: a discard timer at the communication apparatus has been expired, a discard indication for the specific RLC SDU has been obtained, by the communication apparatus, from a Packet Data Convergence Protocol (PDCP) layer, or a number of the at least one ARQ retransmission has reached to a specific number.

[0017] According to the present disclosure, it is possible to provide a method performed by a communication apparatus, a method performed by a receiving entity, a communication apparatus, and a receiving entity.

[0018] Detailed examples of the disclosure will now be described, by way of example, with reference to the accompanying drawings in which: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 shows a flow diagram illustrating an example of feedback;Fig. 6 shows an example of a transmission window for RLC-AM;Fig. 7 shows a further example of a transmission window for RLC-AM;Fig. 8 shows an example of a receiving window for RLC-AM;Fig. 9 shows an example of a receiving window for RLC-AM;Fig. 10 shows an example of a receiving window for RLC-AM;Fig. 11 shows an example of a receiving window for RLC-AM;Fig. 12 shows an example of a receiving window for RLC-AM;Fig. 13 shows an example of a receiving window for RLC-UM;Fig. 14 shows an example of a receiving window for RLC-UM;Fig. 15 shows an example of a receiving window for RLC-UM;Fig. 16 shows an example of a receiving window for RLC-UM;Fig. 17 shows a further example of a transmission window for RLC-AM;Figs. 18 shows a further example of a receiving window for RLC-AM;Fig. 19 shows a further example of a receiving window for RLC-AM;Fig. 20 shows a further example of a receiving window for RLC-AM;Fig. 21 illustrates an example of a new control PDU for reporting discarded SDUs (SN gaps) to the RX side by the TX side;Fig. 22 shows a further example of a transmission window for RLC-AM;Fig. 23 is a schematic block diagram illustrating the main components of a UE 3 for the communication system 1 of Fig. 1;Fig. 24 is a schematic block diagram illustrating the main components of a base station of a distributed type for the communication system of Fig. 1; andFig. 25 is a schematic block diagram illustrating the main components of a core network node or function for the communication system of Fig. 1.

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

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

[0021] In the communication system 1, user equipments (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) 50 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN 50 comprises a distributed base station 5 or 'gNB' operating one or more associated cells 9. Communication via the RAN 50 is typically routed through an associated core network 7 (e.g. a 5G or later generations core network or evolved packet core network (EPC)).

[0022] 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, in the implementation, will typically include other base stations 5 and UEs 3.

[0023] 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.

[0024] In this example the illustrated RAN 50 comprises a distributed base station 5 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). It will be appreciated that the DU 5b, the CU 5c or the base station 5 may be referred to as the (R)AN node 5. 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 5b via appropriate interfaces (e.g. an F1-C logical interface and 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 50 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 a distributed base station 5 is shown and described, the base station 5 may be provided in a non-distributed form, for example as an integrated base station.

[0025] 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). Since the Xn connection with neighbouring base stations 5 is via the gNB-CU, the gNB-CU can obtain information regarding neighbouring cells provided by the neighbouring base station 5.

[0026] 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) Function 10-3 or 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. Each function is connected to the other function in the CPFs 10 via appropriate interfaces (or 'reference points') such as an N8 reference point between the UDM Function 10-3 and the AMF 10-1, an N10 reference point between the UDM Function 10-3 and SMF 10-2, an N11 reference point between the AMF 10-1 and SMF 10-2, an N7 reference point between the SMF 10-2 and one of the other functions 10-n, and so on. an N13 reference point between the UDM Function 10-3 and one of the other functions 10-n.

[0027] The base station 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 50 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 50 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 interface (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 50.

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

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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 / Physical Broadcast Channel (PBCH) 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).

[0033] 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).

[0034] 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.

[0035] In a case where 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 10-1, MME). The UE 3 is in the so-called RRC connected state and an associated UE context is maintained by the network. In a case where 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).

[0036] 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:

[0037] Central Unit (CU) 5c: 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. The CU 5c in the gNB is referred to as a gNB Central Unit (gNB-CU). 　　Distributed Unit (DU) 5b: 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. The DU 5b in the gNB is referred to as a gNB Distributed Unit (gNB-DU).

[0038] 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.

[0039] 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:

[0040]

[0041] 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. 4, the control plane protocol stack includes the PHY, MAC, RLC and PDCP layers, as well as the radio resource control (RRC) layer.

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

[0043] 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.

[0044] 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 in a case where 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).

[0045] 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.

[0046] In a case where a discard timer expires for a PDCP SDU, or the successful delivery of a PDCP SDU is confirmed by a PDCP status report, the transmitting PDCP entity may discard the PDCP SDU along with the corresponding PDCP Data PDU. If the corresponding PDCP Data PDU has already been submitted to lower layers, the discard is indicated to lower layers.

[0047] 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-4) 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 UPF 11 in the core network 7. 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).

[0048] 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.

[0049] CU-DU Information Exchange 　　In the communication system 1, various messages may be exchanged between the CU 5c and the DU 5b, for instance during a setup procedure for configuring communication between the DU 5b and CU 5c (e.g., an 'F1 setup procedure'). The purpose of the setup procedure is to exchange application level data needed for the DU 5b and the CU 5c to interoperate correctly (e.g., on the F1 interface). This procedure is the initial procedure triggered for control plane communication (e.g., over the F1-C interface) after a transport network layer (TNL) association has become operational. Typically, this procedure will use non-UE associated signalling.

[0050] During such a procedure, the DU 5b may transmit a setup request message (e.g., an F1 Setup Request) to the CU 5c. Where the setup request message is an F1 Setup Request it may, for example, include the following information: 　　gNB-DU Served Cells List IE: Information about the cells supported by the DU and associated features (e.g., NR-U); 　　gNB-DU System Information IE.

[0051] It will be appreciated that differently named information elements, having a similar purpose, may be used.

[0052] In response, the CU 5c typically transmits an F1 Setup Response message to the DU 5b. The following information may be included in the F1 Setup Response message: 　　Cells to be Activated List IE: a list of cells that the gNB-CU requests the gNB-DU to activate.

[0053] Further to the above messages, other messages (with associated information elements) may be used to update the configuration between the CU 5c and the DU 5b. For example, Public Land Mobile Network (PLMN) list, served cell information, DU Configuration Update or CU Configuration Update messages may be used to exchange information between the CU 5c and the DU 5b.

[0054] Additional messaging may be used between the CU 5c and the DU 5b, for instance, in a case of establishing a UE's context during a UE Context Setup procedure. The purpose of the UE Context Setup procedure is to establish the UE Context including, signalling radio bearer (SRB), and data radio bearer (DRB). This procedure uses UE associated signalling.

[0055] During such a procedure, the CU 5c may transmit a UE Context Setup Request message to the DU 5b (this message may comprise an RRC container used to carry additional information, e.g. in an RRC information IE). The following information may be included in the UE Context Setup Request message: 　　UE-CapabilityRAT-ContainerList: the DU 5b may take this information into account for UE specific configurations; 　　DRX Cycle IE: the DU 5b may use the provided value from the CU 5c; 　　RRC Information IE; in the case where the CU 5c receives a UEAssistanceInformation IE from the UE 3, the UEAssistanceInformation IE may be included in the RRC Information IE. The DU 5b may, if supported, take the UE's assistance information into account in a case of configuring resources for the UE 3. 　　SRB To Be Setup List; 　　DRB To Be Setup List.

[0056] In response, the DU 5b transmits a UE Context Setup Response message to the CU 5c. The following information may be included in the UE Context Setup Response message: 　　A list of DRBs (and SRBs) which are successfully established and DRBs (and SRBs) which failed to establish; 　　In a case where the DU 5b reports the unsuccessful establishment of a DRB or SRB, an associated cause value should be precise enough to enable the CU 5c to know the reason for the unsuccessful establishment. This may include the reason that a given feature is not supported by the DU 5b; 　　CellGroupConfig: As an Octet string which is included by CU 5c transparently within an RRC reconfiguration message sent to UE 3; 　　DRX Config: As an Octet string which is included by CU 5c transparently within the RRC reconfiguration message sent to UE 3.

[0057] Instead of the above messages, alternative messages (with associated information elements) may be used to update the UE's configuration between the CU 5c and the DU 5b.

[0058] For example, to further update the UE 3 configuration between CU 5c and DU 5b (e.g., DRB / SRB), UE Context Modification Request message (from CU 5c to DU 5b) or UE Context Modification Required (from DU 5b to CU 5c) messages may be used for information exchange between the CU 5c and the DU 5b.

[0059] Radio Link Monitoring (RLM) and Radio Link Failure (RLF) 　　The UE 3 or the base station 5 may be configured to perform one or more radio link monitoring (RLM) procedures to monitor a communication link between the UE 3 and the base station 5. The measurements for the RLM are performed using the physical layer. The measurement results may be passed to both the MAC and RRC layers. Radio link failure (RLF) can be detected using the measurements and the RRC layer. In other words, the RRC layer evaluates conditions for RLF based on the measurements. If it is determined that RLF has occurred, then corresponding RLF procedures are triggered, and RRC Re-establishment may be triggered. Configuration information for beam failure, and beam failure recovery parameters, may also be passed to the MAC layer from the RRC layer. Configuration information for the UE 3 measurements may be passed from the RRC layer to the physical layer, for example a set of radio link monitoring reference signal resources (RLM-RS) may be provided. The RLM-RS may comprise one or more SS / PBCH Blocks (SSB), and / or one or more channel state information reference signals (CSI-RS).

[0060] RLF may occur, for example, due to congestion in a cell of a base station 5, or due to a change in radio conditions (e.g. poor weather, or an obstruction between the UE 3 and the base station 5). In response to detecting RLF, the UE 3 or the base station 5 may cease to transmit one or more transmissions to avoid generating uplink interference (e.g. within 40 ms of detecting RLF).

[0061] The UE 3 may be configured to generate a first indication (also referred to as an Out-of-sync indication) in a case where the radio link quality of all monitored reference signals for a cell is worse than a first threshold quality (e.g. corresponding to a block error rate (BLER)). Similarly, the UE 3 may be configured to generate a second indication (also referred to as an In-sync indication) in a case where the radio link quality for at least one of the monitored reference signals for the cell is better than a second threshold quality. The Out-of-sync indications and the In-sync indications are forwarded to the RRC layer. The RRC layer uses the indications to determine whether RLF has occurred. An RLF timer is started in a case where the RRC layer receives a predetermined number of Out-of-sync indications. This timer may be referred to as 'T310', and the predetermined number of Out-of-sync indications may be referred to as 'N310'. The RLF timer is stopped if the RRC layer receives a predetermined number of In-sync indications. The predetermined number of In-sync indications may be referred to as 'N311'. If the RLF timer expires before the RRC layer receives the predetermines number of In-sync indications, then the UE 3 determines that RLF has occurred. The values of the RLF timer, the predetermined number of Out-of-sync indications, and the predetermined number of In-sync indications may be configured by the network (e.g. transmitted to the UE 3 by the base station 5). If the reference signals received by the UE 3 are measured to have a quality in between the first threshold quality and the second threshold quality, then the UE 3 may not generate either the Out-of-sync indication or the In-sync indication for a particular measurement and evaluation period.

[0062] The UE 3 or the base station 5 may also be configured to determine that RLF has occurred based on a number of re-transmissions (e.g. RLC re-transmissions) exceeding a threshold value.

[0063] Following detection of RLF at a primary serving cell, an RRC connection re-establishment procedure may be initiated, which may include a random access procedure. Following detection of RLF at the PSCell, the UE 3 may provide an indication of the RLF failure via a cell of the MCG (e.g. by transmitting SCG Failure Information) to the corresponding base station (RAN node) 5.

[0064] In a case where the UE 3 is in an RRC connected state, the UE 3 may perform RLM in the active bandwidth part (BWP) based on reference signals (SSB / CSI-RS) and the signal quality thresholds configured by the network. SSB-based RLM is based on the SSB associated to the initial DL BWP and can be configured for the initial DL BWP and for DL BWPs containing the SSB associated to the initial DL BWP. After RLF is determined, the UE 3 may remain in the RRC connected state.

[0065] XR Data Transmission 　　Whilst dynamic scheduling may be used to deal with the varying frame size associated with XR traffic, this involves overhead control signalling (PDCCH, Scheduling Requests). Due to the large Protocol Data Unit (PDU) size, the network will usually need to allocate several slots to deliver all the packets associated with a single Application Data Unit (ADU). For predictable arrival times, it is possible to use so-called configured grants (CG) (e.g. Semi-Persistent Scheduling (SPS) and / or the like).

[0066] A burst of configured grant across a number of consecutive slots may be used to deliver an XR packet. Once a start (symbol / slot) of the configured uplink grant has been determined, the UE 3 can transmit uplink XR data for a number of slots of the configured grant burst. In order to adjust the start offset of the configured grant, a symbol level offset can be used. 3GPP TS 38.321 (V16.7.0) includes formulas for determining the position of the configured uplink grant based on a number of parameters.

[0067] Once the start (symbol / slot) of the configured uplink grant has been determined, the UE 3 can transmit uplink data for a given duration. The duration refers to the number of consecutive slots of the configured grant burst which may be indicated using a suitable DCI field. In a case where configured grant resources are insufficient, additional resources may be requested using dynamic scheduling.

[0068] XR traffic may be transmitted as a periodic data burst. The periodic transmissions are subject to jitter, and may have a variable data size. A PDU set can be used for the transmissions, which defines one or more PDUs carrying a payload of information generated at the application level (for example frames or video slices for XR services). A Data Burst defines a set of multiple PDUs generated by an application in a short period of time, and may include multiple PDU sets. The data rate for XR transmissions is typically large, for example 10 to 200 Mbps, and the packet size is variable.

[0069] Multiple configured grant (CG) PUSCH transmissions occasions may be used in a period of a single CG PUSCH configuration. Dynamic indication of one or more unused CG PUSCH occasions may be provided to the base station 5 by the UE 3 using uplink control information (UCI). Use of multiple CG transmission occasions in one CG period mitigates against the effects of jitter and the variable size of a typical XR data burst, helps to reduce latency (due to the configured grant), whilst making efficient use of the radio communication resources (by indicating the unused transmission occasions).

[0070] For a variable video frame (data burst) size, the transmission occasions may or may not be adjacent in the time domain, and some transmission occasions may not be needed in a case where the data burst size is smaller than expected. For example, the final transmission occasions in the CG period may not be needed.

[0071] HARQ Feedback 　　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 base station 5) checks for errors or lost packets within the received data, and retransmission of packets is requested if necessary. ARQ can be used, for example, in an Acknowledge Mode of the RLC layer (RLC-AM).

[0072] 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. The HARQ configuration is per MAC and common for all logical channels / resource blocks (except for logical channel prioritisation restrictions), and the retransmission times may be controlled via scheduling performed by the base station 5.

[0073] The HARQ procedure can be used to mitigate against packet losses and errors by using re-transmission (or selective re-transmission) of data packets. For example, a base station 5 may receive a transmission from a UE 3 that includes errors or missing packets. The base station 5 may attempt to correct errors in the received transmission where possible, and may provide feedback to the UE 3 regarding the transmission that has been received, for example including an acknowledgement (ACK) or negative acknowledgement (NACK). Based on the feedback, the UE 3 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, in a case where the UE 3 is awaiting feedback from the base station 5 corresponding to a particular HARQ process (and therefore to a particular part of the transmission), the UE 3 can continue transmission of data for the other HARQ processes.

[0074] In a case where 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.

[0075] 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 3 and base station 5 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 or the base station 5 of whether transmitted data is newly transmitted data or re-transmitted data.

[0076] 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.

[0077] 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.

[0078] Fig. 5 shows a flow diagram illustrating an example in which HARQ feedback is transmitted by a UE 3. In this example, the UE 3 is initially configured to have HARQ feedback enabled. In step S501, a downlink transmission from a base station 5 is received at the UE 3. After receiving the downlink transmission, the UE 3 performs a HARQ procedure and, in step S502, transmits HARQ feedback to the base station 5. Based on the feedback received from the UE 3 in step S502, the base station 5 may determine to re-transmit some or all of the original data transmission of step S501. It will be appreciated that a corresponding method can be used for HARQ feedback for uplink transmissions, in which case the HARQ feedback (ACK / NACK) is transmitted to the UE 3 from the base station 5.

[0079] RLC-UM and RLC-AM 　　As described above, an RLC entity can support transparent mode RLC (RLC-TM), unacknowledged mode RLC (RLC-UM), or acknowledged mode RLC (RLC-AM). RLC-TM is applicable to the control plane.

[0080] RLC-UM 　　RLC-UM can be used for applications that have a strict delay budget and that can tolerate a degree of packet loss (since there is no ARQ feedback at the RLC layer to mitigate against packet loss, although there may be HARQ feedback from the MAC layer). For example, Voice over NR (VoNR) may use RLC-UM. RLC-UM is used for the user plane, and is not used for transferring RRC signalling message. RLC configuration information (e.g. RLC-Config) is used to provide the UE 3 with a configuration for the RLC-UM. The RLC-UM may be bi-directional, uplink-only, or downlink-only (which can be indicated in the RLC configuration information).

[0081] RLC-AM 　　RLC-AM provides more reliable data transmission by virtue of the use of ARQ feedback at the RLC layer. In RLC-AM, RLC ARQ re-transmission may be triggered after the MAC layer has attempted a set of HARQ re-transmissions. RLC-AM is applicable to both the control plane and the user plane. In RLC-AM, status reports are used to trigger the re-transmissions of RLC SDUs (or segments of RLC SDUs). The status reports are a type of Control PDU. The number of resource blocks allocated for RLC ARQ re-transmissions may be variable, and may be configurable by the network, to provide a flexible coding redundancy. The packet size for ARQ re-transmissions may also be flexible. For example, if channel conditions become poor, then packets may be re-segmented at the RLC layer before the re-transmissions are performed.

[0082] If the number of RLC re-transmissions exceeds a threshold number (or 'permitted number') then RLF may be determined to have occurred, which may result in the UE 3 being released to the RRC idle mode (or the UE 3 may initiate an RRC connection re-establishment procedure).

[0083] RLC configuration information (e.g. 'RLC-Config') can be used to provide the UE 3 with a configuration for the RLC-AM. The RLC configuration information may include an indication of whether the RLC-AM is bi-directional, unidirectional for uplink, or unidirectional for downlink.

[0084] The transmitting RLC-AM entity (e.g. what can be at the base station 5 or at the UE 3, depending on whether the RLC-AM is for uplink or downlink) uses a transmission window to limit the number of RLC SDUs that are transmitting whilst waiting for an ACK. The transmission window begins at the oldest transmitted RLC SDU which has not been acknowledged, and moves as ACKs are received to include new SDUs which can then be transmitted. If the transmission window becomes full then the RLC entity may stall, in which case no additional SDUs can be transmitted until one of the previous SDUs has been fully acknowledged. The size of the transmission window depends on the sequence number range, since the transmission window is used to prevent ambiguity between sequence numbers at the receiver (for example, the size of the transmission window may be half of the sequence number range). A status report can be transmitted by the receiver to indicate the sequence number up to which all RLC SDUs have been received. The transmitting (TX) side of an RLC entity may be configured to discard an RLC SDU if instructed to do so by the PDCP layer, for example based on a discard timer at the PDCP layer expiring before an SDU has been successfully transmitted.

[0085] Service Requirements and Packet Delay Budget (PDB) 　　As described above, XR application can present challenging delay and reliability requirements. For example, video data may require 99% of data to be received, and the data to have a maximum delay of 10 ms. Audio data may require 99% of data to be received, and the data to have a maximum delay of 30 ms (e.g., at 0.756 / 1.12 Mbps, a periodicity of 10 ms and constant packet size). Haptic data may require 99.999% of the data to be received, and the data to have a maximum delay of 5 ms (for each sensor, the arrival interval of compressed haptic data follows a random distribution with a rate of 0.8K~200Kbps, and one device may include multiple sensors). Pose data may require 99% of data to be received, and the data to have a maximum delay of 10 ms (e.g., at 0.2 Mbps, with a periodicity of 4 ms and a constant packet size).

[0086] The packet delay budget is reflected in the discard timer configuration. In a case where a PDCP SDU arrives for transmission, the discard timer is started with the configured value. In a case where the discard timer expires, the PDCP SDU is to be discarded. However, there is a problem that the PDCP SDU cannot be discarded once it has been associated with an RLC SN and submitted to the MAC layer. Therefore, the PDCP SDU will continue to be (re)transmitted over the air interface using the HARQ procedure at the MAC layer and using the ARQ procedure at the RLC layer, resulting in inefficient use of the available radio resources. The HARQ retransmission will end only if the TX side stops retransmission scheduling of the HARQ process of the transport block, and the ARQ will continue until there is successful reception or the configured maximum number of retransmissions is reached. Improved RLC-AM methods will be described later for mitigating against these issues.

[0087] At reception of a PDCP SDU from upper layers, if a discard timer for low importance (e.g. "discardTimerForLowImportance") is configured, PDU set importance (PSI) based SDU discard is activated, and if the PDCP SDU belongs to a low importance PDU set, then the transmitting PDCP entity starts the low importance discard timer associated with the PDCP SDU. Otherwise, at reception of the PDCP SDU from the upper layers, the PDCP entity starts a discard timer (e.g. "discardTimer") associated with the PDCP SDU (if configured). In a case where the discard timer (or the low importance discard timer) expires for a PDCP SDU, the PDCP entity may determine to discard all PDCP SDUs belonging to the PDU set to which the PDCP SDU belongs, along with the corresponding PDCP Data PDUs, or may determine to discard the PDCP SDU along with the corresponding PDCP Data PDU. PDCP SDUs subsequently received from upper layers are also discarded if they belong to the PDU set. If the corresponding PDCP Data PDU has already been submitted to lower layers, then the discard is indicated to the lower layers. If indicated from an upper layer (e.g. PDCP) to discard a particular RLC SDU, the TX side of an RLC-AM entity (or the transmitting RLC-UM entity) discards the indicated RLC SDU, if neither the RLC SDU nor a segment thereof has been submitted to the lower layers. The TX side of an RLC-AM entity shall not introduce an RLC SN gap in a case of discarding an RLC SDU. A delay critical PDCP SDU may be defined, if a PDU set discard parameter (e.g. "pdu-SetDiscard") is not configured, as a PDCP SDU for which the remaining time until discard timer expiry (e.g. "discardTimer" expiry) is less than the remaining time threshold (e.g. "remainingTimeThreshold"). A delay critical PDCP SDU may be defined, if the PDU set discard parameter is configured, as a PDCP SDU belonging to a PDU Set of which at least one PDCP SDU has the remaining time until the discard timer expiry less than the remaining time threshold. An RLC SDU corresponding to a PDCP PDU may be indicated as delay-critical by PDCP.

[0088] RLC-AM TX Window 　　Fig. 6 shows a simplified schematic illustration of a number of SDUs in a transmission window for RLC-AM. As illustrated in Fig. 6, for some of the SDUs an acknowledgement (ACK) or successful reception has been received from the receiver (RX) side (for SDUx+1, SDUx+2 and SDUx+4). For one of the SDUs (SDUx+5) a negative acknowledgement (NACK) has been received, and the SDU is pending for retransmission. In this example two of the SDUs (SDUx and SDUx+3) have been retransmitted after receiving a NACK from the receiving, and are pending for ARQ ACK / NACK feedback. The two final SDUs (SDUx+6 and SDUx+7) are pending for the first transmission of those SDUs.

[0089] As illustrated in Fig. 6, a parameter TX_Next_ACK is defined that holds the value of the SN of the next RLC SDU for which a positive acknowledgement is to be received in sequence. TX_Next_ACK therefore serves as the lower edge of the transmission window. A parameter TX_Next is also defined that holds the value of the SN to be assigned for the next newly generated acknowledgement-mode PDU (AMD PDU). The value of TX_Next is initiated as 0, and for each RLC SDU received from the upper layer, the AM RLC entity associates a SN with the RLC SDU equal to TX_Next and constructs an AMD PDU by setting the SN of the AMD PDU to TX_Next. The value of TX_Next is then incremented by one. A counter "RETX_COUNT" is also defined (not shown in Fig. 6) for counting the number of retransmissions of an RLC SDU. One RETX_COUNT counter is maintained per RLC SDU. This counter is initially set to zero in a case where a negative acknowledgement is received for the corresponding RLC SDU the first time, and is increased by one for each further negative acknowledgement received. RLF is triggered in a case where the value of the counter exceeds a threshold value (e.g. "maxRetxThreshold"). An acknowledgement mode window size (AM_Window_Size) parameter is also defined that is equal to 2SNbits / 2, i.e., half of the maximum SN value.

[0090] Fig. 7 shows an example in which two SDUs are received from the upper layer for transmission, ACK is received for SDUx, SDUx+5 and SDUx+7, and NACK is received for SDUx+3 and SDUx+6. As shown in the lower half of Fig. 7, the two newly received SDUs are SDUx+8 and SDUx+9, and are pending for feedback after the initial transmission. Since ACK has been received from the RX side for SDUx, the value of TX_Next_Ack is updated to indicate that SDUx+3 is the next SDU for which acknowledgement has not been received. Since NACK has been received for SDUx+3, SDUx+3 is retransmitted and the value of RETX_COUNT for SDUx+3 is increased by one. Similarly, for SDUx+6 the value of the retransmission counter will also be increased by one. If they value of RETX_COUNT for SDUx+3 or SDUx+6 has exceeded the predetermined threshold value, then an RLF procedure will be triggered.

[0091] RLC-AM RX Window 　　Fig. 8 shows a simplified schematic illustration of an RLC-AM RX window at the RX side. As shown in the Figure, some of the SDUs have been successfully received, but some of the SDUs have not been received (or have not been fully received). An RX_Next parameter is defined that holds the value of the SN following the last in-sequence completely received RLC SDU, and which therefore serves as the lower edge of the receiving window. The value of RX_Next is initially set to zero, and is updated in a case where the AM RLC entity receives an RLC SDU with a SN equal to RX_Next. In this example RX_Next indicates that SDUx is the SN following the last in-sequence completely received RLC SDU. An RX_Next_Status_Trigger variable is also illustrated that holds the value of the SN following the SN of an RLC SDU that triggers a reassembly timer (t-Reassembly). An RX_Highest_Status variable is illustrated that holds the highest possible value of the SN which can be indicated by "ACK_SN" in a case where a STATUS PDU needs to be constructed. The value of RX_Highest_Status is initially set to zero. An RX_Next_Highest state variable is also defined that holds the value of the SN following the SN of the RLC SDU with the highest SN among the received RLC SDUs. The value of RX_Next_Highest is initially set to zero.

[0092] Fig. 9 illustrates a first case, in which the next received SDU (SDUy) is SDUx. The newly received SDU is indicated by the asterisk. In this case, the value of RX_Next can be updated to indicate that SDUx+3 is now the SN following the last in-sequence completely received RLC SDU.

[0093] Fig. 10 illustrates a second case, in which the next received SDU has a SN larger than or equal to the SN indicated by RX_Next_Highest. In this case, the value of RX_Next_Highest is updated to the value of the SN following the SN of SDUy (which now has the highest SN among the received RLC SDUs).

[0094] Fig. 11 illustrates a third case, in which the received SDU corresponds to the SDU indicated by the RX_Highest_Status parameter (the highest possible value of the SN which can be indicated by "ACK_SN" in a case where a STATUS PDU needs to be constructed). In this case, the value of RX_Highest_Status is increased by one (to the SN of the next RLC SDU).

[0095] Fig. 12 illustrates a fourth case, in which the reassembly timer expires. Expiry of the reassembly timer triggers the transmission of a STATUS report to the transmitter. In the example of Fig. 12, the value of RX_Highest_Status is updated to indicate that SDUx+8 now has the highest possible value of SN which can be indicated by "ACK_SN" in a case where a STATUS PDU needs to be constructed. The value of RX_Next_Status_Trigger is also updated to indicate that the SN following the SN of the RLC SDU that triggers the reassembly timer is now SDUx+10.

[0096] RLC-UM 　　Fig. 13 shows a simplified schematic illustration of an RLC-UM RX Window. As illustrated in Fig. 13, in this example a number of the SDUs have been successfully received, but the other SDUs have not been received (or have not been fully received). The UM receiving window (UM_Rx_Window) and the reassembly window are illustrated in the figure. An RX next reassembly parameter (RX_Next_Reassembly) is defined that holds the value of the earliest SN that is still considered for reassembly. The value of RX_Next_Reassembly is initially set to zero. For groupcast and broadcast of sidelink communication or for SL-SRB4 of sidelink discovery, the value of RX_Next_Reassembly is initially set to the SN of the first received UM PDU containing an SN. For the receiving UM RLC entity configured for the multicast control channel (MCCH) or the multicast traffic channel (MTCH), the RX side may set the initial value of RX_Next_Reassembly to a suitable value before RX_Next_Highest. An RX timer trigger (RX_Timer_Trigger) is illustrated that holds the value of the SN following the SN that triggered the reassembly timer. An RX Next Highest (RX_Next_Highest) state variable is also illustrated, that holds the value of the SN following the SN of the UM PDU with the highest SN among received UM PDUs. It serves as the higher edge of the reassembly window and is initially set to 0. For groupcast and broadcast of sidelink communication or for SL-SRB4 of sidelink discovery, it is initially set to the SN of the first received UM PDU containing an SN. For the receiving UM RLC entity configured for MCCH or MTCH, it is initially set to the SN of the first received UMD PDU containing an SN.

[0097] Fig. 14 illustrates a first case for UM, in which the next SDU that is received and placed into the reception buffer corresponds to RX_Next_Reassembly. The newly received SDU (SDUx) is indicated by the asterisk. The value of RX_Next_Reassembly is updated to indicate that SDUx+3 now has the SN that is the earliest SN that is still considered for reassembly.

[0098] Fig. 15 illustrates a second case for UM, in which the next received SDU has a SN that is greater than or equal to the SN indicated by RX_Next_Highest. In this example, SDUx will not be successfully received, and the value of RX_Next_Reassembly is updated to indicate that SDUx+3 now has the SN that is the earliest SN that is still considered for reassembly. The value of RX_Next_Highest is also updated to indicate the value of the SN following SDUy.

[0099] Fig. 16 illustrates a third case for UM, in which the reassembly timer (t-Reassembly) expires before SDUx, SDUx+3, SDUx+5 or SDUx+6 have been successfully received. In this case, SDUx, SDUx+3, SDUx+5 or SDUx+6 will not be successfully received and the value of RX_Next_Reassembly is updated to indicate that SDUx+8 now has the SN that is the earliest SN that is still considered for reassembly. The value of RX_Timer_Trigger is also updated to the new value of the SN following the SN that triggered the reassembly timer.

[0100] RLC-AM 　　Improved methods for RLC-AM will now be described that advantageously avoid out-of-PDB data ARQ retransmission, and avoid RLF due to RLC retransmission reaching a maximum value. Beneficially, the methods provide an improved balance between the short delay and high reliability requirements (for example, for transmission of XR data).

[0101] Fig. 17 shows an example in which ARQ retransmission is terminated upon the expiry of the discard timer. The discard timer and indication from PDCP could be reused, or a new timer could be defined. The timer may run per PDU or per PDU set. The configuration of the timer (i.e., length) is per DRB / per QoS flow or per PDU set type). In this example, the transmission window is moved forward considering the discarded SDUs. The receiving window is also moved forward to abandon waiting for missed SDUs (missed SDUs are detected by defining a new timer).

[0102] As illustrated in Fig. 17, in this example two new SDUs (SDUx+8 and SDUx+9) are received from the upper layer (PDCP layer). A discard indication is also received from the upper layer, that indicates that SDUx and SDUx+3 are to be discarded. The discard indication is generated at the upper layer due to the expiry of a discard timer (which may be the existing PDCP discard timer, or a newly defined timer). Based on the discard indication, the transmitter no longer attempts retransmission of SDUx and SDUx+3 (the discarded SDUs are indicated by the crosses in Fig. 17). Therefore, since further retransmission of the discarded SDUs is avoided, more efficient use of the available transmission resources can be made. The discarded SDUs are treated in the same manner as SDUs for which an acknowledgement has been received from the RX side, and the low edge of the transmission window is moved to the first not acknowledged SDU that has not been discarded (by updating the value of TX_Next_Ack).

[0103] In this example, the TX side of the AM RLC entity can receive a positive acknowledgement (confirmation of successful reception by its peer AM RLC entity) for an RLC SDU by the following: STATUS PDU from its peer AM RLC entity. In a case of receiving a positive acknowledgement for an RLC SDU with SN =x, the TX side of an AM RLC entity: sends an indication to the upper layers of successful delivery of the RLC SDU; and sets TX_Next_Ack equal to the SN of the RLC SDU with the smallest SN, whose SN falls within the range TX_Next_Ack <= SN <= TX_Next and for which a positive acknowledgment has not been received yet and it has not been indicated as discarded by PDCP. In a case of receiving discard indication from upper layer for an RLC SDU with SN =x, the TX side of an AM RLC entity: sets TX_Next_Ack equal to the SN of the RLC SDU with the smallest SN, whose SN falls within the range TX_Next_Ack <= SN <= TX_Next and for which a positive acknowledgment has not been received yet and it has not been indicated as discarded by PDCP.

[0104] Figs. 18 and 19 illustrates the example of Fig. 17 but at the RX side. As illustrated in Fig. 19, SDUx and SDUx+3 will not be received since the retransmission has been abandoned at the TX side. The receiver is configured to wait for the SDUs that have not yet been received until the expiry of a corresponding timer (t-Giveup). A new RX give-up trigger variable is also illustrated, which holds the value of the SN following the SN of the RLC SDU which triggered the timer. In the example of Fig. 18 RX_Giveup_Trigger indicates that SDUx+4 has the SN following the SN of the RLC SDU which triggered the timer. Following the expiry of the timer, in this example the value of RX_Giveup_Trigger is updated to indicate that the SDU following SDUx+9 now has the SN following the SN of the RLC SDU which triggered the timer. The value of RX_Next is also updated to the new value of the SN following the last in-sequence completely received RLC SDU. The handling (initiation, update and upon expiration) of the give-up timer and corresponding variable are similar to that of the reassembly timer, and RX_Timer_Trigger of UM RLC, but advantageously the configuration of the give-up timer reflects the PDB requirements. T-giveup begins to run once there is receiving gap (i.e., one or more SDU before the SDU corresponding to RX_Next_Highest have been missed), and T-giveup expiring will trigger the RX side to give up waiting for the all SDUs with SN< RX_Giveup_Trigger, assuming these should have been discarded at the TX side due to running out of PDB.

[0105] In this example, in a case where an SDU is placed in the reception buffer, if the give-up timer (t-Giveup) is running: 　　if RX_Giveup_Trigger <= RX_Next; or if RX_Giveup_Trigger falls outside of the receiving window and RX_Timer_Trigger is not equal to RX_Next_Highest; or if RX_Next_Highest = RX_Next + 1 and there is no missing byte segment of the RLC SDU associated with SN = RX_Next before the last byte of all received segments of this RLC SDU: stop and reset t-giveup.

[0106] If t-Giveup is not running (which includes the case in which t-Giveup is stopped due to actions above): 　　if RX_Next_Highest > RX_Next + 1; or if RX_Next_Highest = RX_Next + 1 and there is at least one missing byte segment of the RLC SDU associated with SN = RX_Next before the last byte of all received segments of this RLC SDU: start t-Giveup, and set RX_Giveup_Trigger to RX_Next_Highest.

[0107] In a case where t-Giveup expires, the receiving AM RLC entity: 　　updates RX_Next to the SN of the first SN >= RX_Timer_Trigger that has not been received; 　　discards all segments with SN < updated RX_Next; 　　if RX_Next_Highest > RX_Next+ 1; or if RX_Next_Highest = RX_Next+ 1 and there is at least one missing byte segment of the RLC SDU associated with SN = RX_Next before the last byte of all received segments of this RLC SDU: starts t-Giveup, and sets RX_Giveup_Trigger to RX_Next_Highest.

[0108] Fig. 20 illustrates an alternative to the use of a give-up timer at the RX side in which, in order for the RX side to give up waiting for the SDUs that have been discarded at TX side, the TX side transmits an indication to the RX side of the SNs of the SDUs that have been discarded (and therefore will not be retransmitted). Upon reception of the indication of the discarded SDUs, the RX can be moved accordingly at the RX side. In the example of Fig. 20 the TX side transmits and indication to the RX side that SDUx and SDUx+3 have been discarded and will therefore not be re-transmitted. SDUx and SDUx+3 will not be successfully received at the receiver. The receiver therefore determines to update the value of RX_Next accordingly (to the SN of SDUx+5, the next SDU that has not been received but has also not been discarded at the TX side).

[0109] Fig. 21 illustrates an example of a new control PDU for reporting the discarded SDUs (SN gaps) to the RX side by the TX side. In a first option, the smallest possible RX_next value that the RX side is to set is indicated. This SN is the SN following the last SDU which has been discarded at TX side and will not be received at the RX side, based on the assumption that the arrival time and discard time of SDUs are in the order of SN. In a second option, the TX side reports one or multiple SN gaps using the parameters "first_SN_of_the_GAP" (which indicates the SN of the SDU corresponding to the start of the SDU gap), and "GAP_range" which indicates the size of the GAP in SNs. In a third option, the TX side transmits an indication of the SN corresponding to the first SDU of the SDU gap and a bitmap to indicate whether each of a set of SDUs following the first SDU are also discarded. In a fourth option, the TX side transmits an indication of the SN gaps in the same manner as a status report PDU. More generally, the indication of the SDUs that are discarded at the TX side may be transmitted to the RX side in any suitable manner, using any suitable transmission.

[0110] Fig. 22 illustrates a further example in which, in a case where the number of retransmissions of an SDU reaches a predetermined threshold value, the TX side gives up further retransmission. In the example illustrated in Fig. 22, NACK is received for SDUx+3 and SDUx+6. However, further retransmission of SDUx+3 would result in the retransmission threshold being exceeded, and therefore the transmitter determines that SDUx+3 is to be discarded. The value of TX_Next_Ack can then be updated accordingly (in this example, to indicate that SDUx+6 is the next SDU with the SN for which acknowledgement has not been received from the RX side). In other words, the discarded SDU (SDUx+3 in this example) is treated as if acknowledgement was received from the RX side, and the lower edge of the transmission window is moved up to the first missed SDU. Advantageously, therefore, RLF is not triggered, and instead the transmitter will simply not retransmit SDUx+3. Similarly, at the RX side, the receiver can determine to move the receiving window forward after transmitting a threshold number of NACKs to the transmitter for a particular SDU. For example, referring to Fig. 18, if the RX side transmits a NACK for SDUx and SDUx+3 a threshold number of times, then the RX side can determine that SDUx and SDUx+3 will be discarded at the TX side, and can determine to update the value of RX_Next to indicate that SDUx+5 is the next SDU that has not been successfully received at the RX side (and has not been discarded). The threshold at the RX side may be defined using any suitable counter of the number of NACKs transmitted for each SDU.

[0111] At the TX side, in a case where an RLC SDU or an RLC SDU segment is considered for retransmission, the TX side of the AM RLC entity: 　　if the RLC SDU or RLC SDU segment is considered for retransmission for the first time: sets the RETX_COUNT associated with the RLC SDU to zero. 　　Otherwise, if it (the RLC SDU or the RLC SDU segment that is considered for retransmission) is not pending for retransmission already and the RETX_COUNT associated with the RLC SDU has not been incremented due to another negative acknowledgment in the same STATUS PDU, the AM ARLC entity shall: Increment the RETX_COUNT. If RETX_COUNT = maxRetxThreshold, then the AM RLC entity shall: 　　　　Indicate to upper layers that max retransmission has been reached if skipRLF is not configured 　　　　Consider the RLC SDU or SDU segment is ACKed if skipRLF is configured (this may trigger to push the transmission window forward).

[0112] It will be appreciated that the examples described above with reference to Figs. 17 to 22 may be implemented as a modification to an existing RLC-AM mode, or could be defined as a new RLC mode.

[0113] In a further example, retransmission is triggered in a case where the remaining time is less than a threshold value, or if the data becomes delay critical. Conventionally, once NACK feedback have been received in a status report for a SDU, the SDU will be pending for retransmission and has a higher transmission priority than for a new SDU. After the retransmission / initial transmission is completed, but before feedback is received from the RX side, the SDU is pending for feedback and may not be retransmitted. However, advantageously, in the present example a remaining time threshold is defined. Once the remaining time for a SDU is less than the configured threshold, and its successful transmission has not been configured, the SDU becomes pending for retransmission and has the higher priority for transmission. The remaining time threshold may be determined based on the PDB. The TX / RX windows may also be moved forward following the retransmission as described above with reference to Figs. 17 to 22.

[0114] For any of the examples of RLC-AM described above, the receiver (e.g. UE 3) may be configured to transmit an indication to TX side (e.g. base station 5) of whether a particular RLC-AM mode or feature is supported at the receiver. The activation of a particular RLC-AM feature or mode may also be configurable by the network, for example per DRB. The activation of the RLC-AM feature or mode may be achieved using an explicit indication (e.g. with an enable bit), or implicitly (e.g. by setting the number of retransmission times to infinite). In any of the examples described above, the RX side may be permitted to deliver to the PDCP layer an SDU that is received outside of the receiving window. If t-Reordering is still running, for example, and the PDU is covered by the current reordering window, the PDCP layer can deliver the PDU to an upper layer. Otherwise, the PDCP layer may discard the PDU.

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

[0116] 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 350, 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.

[0117] 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, and a communication control module 430.

[0118] The communication 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 3 and / or core network nodes). The communication control module 430 is configured for the overall handling of uplink communication 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 communication 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 communication 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.

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

[0120] As shown, the RAN 50 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 circuit 51c, 51b.

[0121] The transceiver circuit 51b of the distributed unit 5b 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).

[0122] The transceiver circuit 51c of the central unit 5c is operable to transmit signals to and to receive signals from functions of the core network 7 and / or other RANs 50 via a network interface 55c. The network interface typically includes an N2 and / or N3 interfaces for communicating with the core network 7 and a base station to base station (e.g. Xn) interface for communicating with other RANs 50. The transceiver circuit 51c of the central unit 5c 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.

[0123] Each unit 5c, 5b includes a respective controller 57c, 57b which controls the operation of the corresponding transceiver circuit 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 communication control module 63c, 63b and a respective RLC-AM / UM module 65c, 65b.

[0124] Each communication 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 communication control module 63b of the distributed unit 5b controls communication between the distributed unit 5b and the UEs 3, and the communication 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 50.

[0125] The communication 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 communication devices served by the RAN 50 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.).

[0126] The RLC-AM / UM module 65c, 65b is configured for performing control of communication in accordance with any of the methods described above (for example, to perform any of the RLM-AM or RLM-UM methods described above).

[0127] It will be appreciated that the communication 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 communication control modules 63b of the distributed unit 5b may include a PHY sub-module, a MAC sub-module, and an RLC sub-module, whereas the communication 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).

[0128] Core Network Node / Function 　　Fig. 25 is a block diagram illustrating the main components of a core network node or function in the core network 7, such as the AMF 10-1, CPF 10, the UPF 11, the SMF 10-2 or Operations, Administration, and Management (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 one or more network interfaces 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 communication control module 760.

[0129] The communication 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.

[0130] 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 disclosure therein.

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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.).

[0139] 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.).

[0140] 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.).

[0141] 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.).

[0142] 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.

[0143] 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)).

[0144] 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. 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.

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

[0146] 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.

[0147]

[0148] 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 Telecommunication 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.

[0149] 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.

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

[0151] While the present disclosure has been particularly shown and described with reference to example embodiments thereof, the present disclosure is not limited to these example embodiments. It will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by the claims. And each example embodiment can be appropriately combined with at least one of example embodiments.

[0152] Each of the drawings or figures is merely an example to illustrate one or more example embodiments. Each Fig. may not be associated with only one particular example embodiment, but may be associated with one or more other example embodiments. As those of ordinary skill in the art will understand, various features or steps described with reference to any one of the figures can be combined with features or steps illustrated in one or more other figures, for example, to produce example embodiments that are not explicitly illustrated or described. Not all of the features or steps illustrated in any one of the figures to describe an example embodiment are necessarily essential, and some features or steps may be omitted. The order of the steps described in any of the figures may be changed as appropriate.

[0153] The whole or part of the example embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　(Supplementary Note 1) 　　A method performed by a communication apparatus, the method comprising: 　　transmitting a Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set; 　　starting a discard timer; and 　　performing at least one automatic repeat request (ARQ) retransmission of the RLC SDU in a case where the communication apparatus receives information indicating a specific RLC SDU is not received successfully and the discard timer is running; and 　　stopping the at least one ARQ retransmission in a case where at least one of: 　　　　the discard timer has been expired, 　　　　a discard indication for the specific RLC SDU has been obtained from a Packet Data Convergence Protocol (PDCP) layer, or 　　　　a number of the at least one ARQ retransmission has reached to a specific number. 　　(Supplementary Note 2) 　　The method according to supplementary note 1, further comprising: 　　updating a transmission window for the PDU or the PDU set upon the at least one ARQ retransmission. 　　(Supplementary Note 3) 　　The method according to supplementary note 2, wherein 　　the updating is performed by setting a lower edge of the transmission window equal to a sequence number (SN) of an RLC SDU with a smallest SN, whose SN falls within the transmission window and for which a positive acknowledgment has not been received yet and the SN has not been indicated as discarded by an upper layer. 　　(Supplementary Note 4) 　　The method according to any one of supplementary notes 1 to 3, wherein 　　the specific RLC SDU is abandoned by a receiving entity in a case where at least one of: 　　　　a timer of the receiving entity has been expired, or 　　　　a number of at least one transmission of negative acknowledgement regarding the specific RLC SDU has reached to a specific number. 　　(Supplementary Note 5) 　　The method according to supplementary note 4, wherein 　　a receiving window for the PDU of the PDU set is updated by the receiving entity in a case where: 　　　　the timer of the receiving entity has been expired, or 　　　　the communication apparatus has indicated at least one respective sequence number (SN) of at least one RLC SDU which has been discarded and or retransmission of the at least one RLC SDU is terminated. 　　(Supplementary Note 6) 　　The method according to supplementary note 5, wherein 　　the at least one respective SN includes at least one of: 　　　　a SN following a last RLC SDU which has been discarded at the communication apparatus, 　　　　a smallest SN corresponding to a first SDU of at least one continuous SDU which has been discarded at the communication apparatus, 　　　　a range of SNs corresponding to respective continuous SDUs which have been discarded at the communication apparatus. 　　(Supplementary Note 7) 　　The method according to any one of supplementary notes 1 to 6, further comprising: 　　disabling a radio link failure in a case where a number of the at least one ARQ retransmission has reached to a specific number. 　　(Supplementary Note 8) 　　The method according to any one of supplementary notes 1 to 7, wherein 　　the performing the at least one ARQ retransmission of the RLC SDU is prioritized in a case where a remaining time corresponding to the RLC SDU is less than a specific threshold. 　　(Supplementary Note 9) 　　A method performed by a receiving entity, the method comprising: 　　transmitting, to a communication apparatus, information indicating a specific Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set is not received successfully; and 　　receiving, from the communication apparatus, the specific RLC SDU via at least one automatic repeat request (ARQ) retransmission of the specific RLC SDU, and 　　wherein the at least one ARQ retransmission is stopped, by the communication apparatus, in a case where at least one of: 　　　　a discard timer at the communication apparatus has been expired, 　　　　a discard indication for the specific RLC SDU has been obtained, by the communication apparatus, from a Packet Data Convergence Protocol (PDCP) layer, or 　　　　a number of the at least one ARQ retransmission has reached to a specific number. 　　(Supplementary Note 10) 　　A communication apparatus comprising: 　　means for transmitting a Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set; 　　means for starting a discard timer; and 　　means for performing at least one automatic repeat request (ARQ) retransmission of the RLC SDU in a case where the communication apparatus receives information indicating a specific RLC SDU is not received successfully and the discard timer is running; and 　　means for stopping the at least one ARQ retransmission in a case where at least one of: 　　　　the discard timer has been expired, 　　　　a discard indication for the specific RLC SDU has been obtained from a Packet Data Convergence Protocol (PDCP) layer, or 　　　　a number of the at least one ARQ retransmission has reached to a specific number. 　　(Supplementary Note 11) 　　A receiving entity comprising: 　　means for transmitting, to a communication apparatus, information indicating a specific Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set is not received successfully; and 　　means for receiving, from the communication apparatus, the specific RLC SDU via at least one automatic repeat request (ARQ) retransmission of the specific RLC SDU, and 　　wherein the at least one ARQ retransmission is stopped, by the communication apparatus, in a case where at least one of: 　　　　a discard timer at the communication apparatus has been expired, 　　　　a discard indication for the specific RLC SDU has been obtained, by the communication apparatus, from a Packet Data Convergence Protocol (PDCP) layer, or 　　　　a number of the at least one ARQ retransmission has reached to a specific number.

[0154] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2403413.4, filed on March 8, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0155] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 3-1 USER EQUIPMENT 3-2 USER EQUIPMENT 3-3 USER EQUIPMENT 5 BASE STATION 5b DISTRIBUTED UNIT 5c CENTRAL UNIT 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTION 10-1 ACCESS MANAGEMENT FUNCTION 10-2 SESSION MANAGEMENT FUNCTION 10-3 UNIFIED DATA MANAGEMENT FUNCTION 10-n OTHER FUNCTIONS 11 USER PLANE FUNCTION 20 EXTERNAL DATA NETWORK 50 RAN 51b TRANSCEIVER CIRCUIT 53b AIR INTERFACE 57b DU CONTROLLER 59b DU MEMORY 61b DU OPERATING SYSTEM 63b DU COMMUNICATION CONTROL MODULE 65b RLC-AM / LM MODULE 51c TRANSCEIVER CIRCUIT 55c NETWORK INTERFACE 57c CU CONTROLLER 59c CU MEMORY 61c CU OPERATING SYSTEM 63c CU COMMUNICATION CONTROL MODULE 65c RLC-AM / LM MODULE 310 TRANCEIVER CIRCUIT 330 ANTENNA 350 USER INTERFACE 370 CONTROLLER 390 MEMORY 410 OPERATING SYSTEM 430 COMMUNICATION CONTROL MODULE 710 TRANCEIVER CIRCUIT 720 NETWORK INTERFACE 730 CONTROLLER 740 MEMORY 750 OPERATING SYSTEM 760 COMMUNICATION CONTROL MODULE E1 LOGICAL INTERFACE F1 INTERFACE F1-C LOGICAL INTERFACE F1-U LOGICAL INTERFACE N1, N2, N3, N4, N7, N8, N10, N11, N12, N13, N15 REFERENCE POINT NG-UU AIR INTERFACE

Claims

1. A method performed by a communication apparatus, the method comprising: 　　transmitting a Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set; 　　starting a discard timer; 　　performing at least one automatic repeat request (ARQ) retransmission of the RLC SDU in a case where the communication apparatus receives information indicating a specific RLC SDU is not received successfully and the discard timer is running; and 　　stopping the at least one ARQ retransmission in a case where at least one of: 　　　　the discard timer has been expired, 　　　　a discard indication for the specific RLC SDU has been obtained from a Packet Data Convergence Protocol (PDCP) layer, or 　　　　a number of the at least one ARQ retransmission has reached to a specific number.

2. The method according to claim 1, further comprising: 　　updating a transmission window for the PDU or the PDU set upon the at least one ARQ retransmission.

3. The method according to claim 2, wherein 　　the updating is performed by setting a lower edge of the transmission window equal to a sequence number (SN) of an RLC SDU with a smallest SN, whose SN falls within the transmission window and for which a positive acknowledgment has not been received yet and the SN has not been indicated as discarded by an upper layer.

4. The method according to any one of claims 1 to 3, wherein 　　the specific RLC SDU is abandoned by a receiving entity in a case where at least one of: 　　　　a timer of the receiving entity has been expired, or 　　　　a number of at least one transmission of negative acknowledgement regarding the specific RLC SDU has reached to a specific number.

5. The method according to claim 4, wherein 　　a receiving window for the PDU of the PDU set is updated by the receiving entity in a case where: 　　　　the timer of the receiving entity has been expired, or 　　　　the communication apparatus has indicated at least one respective sequence number (SN) of at least one RLC SDU which has been discarded and or retransmission of the at least one RLC SDU is terminated.

6. The method according to claim 5, wherein 　　the at least one respective SN includes at least one of: 　　　　a SN following a last RLC SDU which has been discarded at the communication apparatus, 　　　　a smallest SN corresponding to a first SDU of at least one continuous SDU which has been discarded at the communication apparatus, 　　　　a range of SNs corresponding to respective continuous SDUs which have been discarded at the communication apparatus.

7. The method according to any one of claims 1 to 6, further comprising: 　　disabling a radio link failure in a case where a number of the at least one ARQ retransmission has reached to a specific number.

8. The method according to any one of claims 1 to 7, wherein 　　the performing the at least one ARQ retransmission of the RLC SDU is prioritized in a case where a remaining time corresponding to the RLC SDU is less than a specific threshold.

9. A method performed by a receiving entity, the method comprising: 　　transmitting, to a communication apparatus, information indicating a specific Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set is not received successfully; and 　　receiving, from the communication apparatus, the specific RLC SDU via at least one automatic repeat request (ARQ) retransmission of the specific RLC SDU, and 　　wherein the at least one ARQ retransmission is stopped, by the communication apparatus, in a case where at least one of: 　　　　a discard timer at the communication apparatus has been expired, 　　　　a discard indication for the specific RLC SDU has been obtained, by the communication apparatus, from a Packet Data Convergence Protocol (PDCP) layer, or 　　　　a number of the at least one ARQ retransmission has reached to a specific number.

10. A communication apparatus comprising: 　　means for transmitting a Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set; 　　means for starting a discard timer; 　　means for performing at least one automatic repeat request (ARQ) retransmission of the RLC SDU in a case where the communication apparatus receives information indicating a specific RLC SDU is not received successfully and the discard timer is running; and 　　means for stopping the at least one ARQ retransmission in a case where at least one of: 　　　　the discard timer has been expired, 　　　　a discard indication for the specific RLC SDU has been obtained from a Packet Data Convergence Protocol (PDCP) layer, or 　　　　a number of the at least one ARQ retransmission has reached to a specific number.

11. A receiving entity comprising: 　　means for transmitting, to a communication apparatus, information indicating a specific Radio Link Control (RLC) Service Data Unit (SDU) corresponding to a Protocol Data Unit (PDU) or a PDU set is not received successfully; and 　　means for receiving, from the communication apparatus, the specific RLC SDU via at least one automatic repeat request (ARQ) retransmission of the specific RLC SDU, and 　　wherein the at least one ARQ retransmission is stopped, by the communication apparatus, in a case where at least one of: 　　　　a discard timer at the communication apparatus has been expired, 　　　　a discard indication for the specific RLC SDU has been obtained, by the communication apparatus, from a Packet Data Convergence Protocol (PDCP) layer, or 　　　　a number of the at least one ARQ retransmission has reached to a specific number.

Images