Enhanced semi-persistent scheduling and HARQ feedback for quasi-periodic traffic

Abstract

A communication method implemented in a user equipment (UE) includes receiving a semi-persistent (SPS) configuration from a radio access network (RAN), the semi-persistent (SPS) configuration indicating a plurality of Downlink (DE) opportunities for receiving data transmitted from the RAN to the UE in a downlink (DE) direction within a single period of the SPS; attempting to receive first data in a first DE opportunity of the plurality of DE opportunities and to receive second data in a second DE opportunity of the plurality of DE opportunities; and transmitting respective acknowledgements for the first data and the second data within a single uplink opportunity.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of the filing date of Provisional U.S. Patent Application No. 63 / 371,380, entitled “Enhanced Semi-Persistent Scheduling and HARQ Feedback for Quasi-Periodic Traffic,” filed on August 12, 2022. The entire contents of the provisional application are hereby expressly incorporated herein by reference. Technical Field

[0003] The present disclosure relates to wireless communications, and more particularly, to managing communications using multiple semi-persistent schedules (SPS) for downlink transmission of data in the context of extended reality (XR), cloud gaming (CG) and other services that require high data rates and low latency. Background Art

[0004] The background description provided herein is for the purpose of generally presenting the background of the present disclosure. The work of the presently named inventors (to the extent that it is described in this background section) and aspects of this specification that might not have been considered prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art to the present disclosure.

[0005] Base stations operating in accordance with fifth generation (5G) New Radio (NR) requirements support much greater bandwidth than fourth generation (4G) base stations. In some cases, base stations may transmit data associated with extended reality, such as augmented reality (AR), virtual reality (VR), mixed reality (MR), cloud gaming, to user devices or user equipment (UE). This technology generally involves quasi-periodic streaming and is associated with high data rate and low latency requirements.

[0006] The periodicity of XR traffic is equal to the inverse of the XR frame rate. Therefore, if the frame rate is 60 frames per second (fps), the periodicity is 16.67 milliseconds (ms). XR traffic can have jitter due to the variation in latency when encoding the video frames at the codec. The Third Generation Partnership Project (3GPP) statistically models jitter as a truncated Gaussian distribution with a standard deviation of 2ms and a range of + / -4ms. The size of the XR packet can also vary due to changes in the content of the video frame. According to 3GPP modeling, the size also conforms to a truncated Gaussian distribution.

[0007] Semi-persistent scheduling (SPS) provides periodic data transmission with minimal control signaling overhead for such LTE and NR services as VoIP, online streaming, etc. on the radio interface between the base station and the UE. Although the base station can use the existing SPS (or "legacy SPS") to send XR data to the UE, the UE can only be configured with a fixed SPS periodicity and a fixed physical downlink shared channel (PDSCH) resource size for SPS data reception. When the base station needs to change the PDSCH resource size used to send XR packets, the base station must send a reactivation downlink control signal to change the PDSCH resource size. At least for this reason, the legacy SPS is not a good mechanism for XR traffic. However, it is not clear how to enhance SPS to address jitter and packet size variations. Summary of the invention

[0008] An example embodiment of the technology disclosed herein is a communication method implemented in a user equipment UE. The communication method includes: receiving a semi-persistent SPS configuration from a radio access network RAN, the semi-persistent SPS configuration indicating multiple DL opportunities for receiving data sent from the RAN to the UE in a downlink DL direction within a single period of the SPS; attempting to receive first data in a first DL opportunity among the multiple DL opportunities and receiving second data in a second DL opportunity among the multiple DL opportunities; and sending corresponding confirmations for the first data and the second data within a single uplink opportunity.

[0009] Another example embodiment of the technology is a method for sending data to a user equipment UE. The method is implemented in a radio access network RAN ​​and includes: sending a semi-persistent SPS configuration to the UE, the semi-persistent SPS configuration indicating a plurality of DL opportunities for sending data from the RAN node to the UE in a downlink DL direction within a single cycle of the SPS; sending first data to the UE in a first DL opportunity among the plurality of DL opportunities and sending second data to the UE in a second DL opportunity among the plurality of DL opportunities; and receiving corresponding confirmations for the first data and the second data within a single uplink opportunity.

[0010] Another example embodiment of the technology is a method for sending data to a user equipment UE. The method is implemented in a radio access network RAN ​​and includes: sending a semi-persistent SPS configuration to the UE, the semi-persistent SPS configuration indicating a plurality of opportunities for sending data from the RAN node to the UE in a downlink DL direction within a single cycle of the SPS; sending an indication to the UE of at least one opportunity among the plurality of opportunities that the RAN node uses to send the data; sending the data to the UE in the indicated one of the plurality of opportunities.

[0011] Another example embodiment of the technology is a method for receiving data in a device UE. The method includes: receiving a semi-persistent SPS configuration from a RAN node at the UE, the semi-persistent SPS configuration indicating a plurality of opportunities for sending data from the RAN node to the UE in a downlink DL direction within a single cycle of the SPS; receiving an indication of at least one opportunity in the plurality of opportunities that the RAN node uses to send the data; and receiving the data in the indicated one of the plurality of opportunities.

[0012] Yet another example embodiment of the technology is an apparatus comprising: a transceiver and processing hardware configured to implement one of the above methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1A is a block diagram of an example wireless communication system in which a RAN and / or a UE implement the disclosed techniques for managing transmission and reception of an SPS;

[0014] Figure 1B Yes, you can Figure 1A A block diagram of an example base station including a central unit (CU) and a distributed unit (DU) operating in a system of FIG.

[0015] Figure 2 yes Figure 1A A block diagram of an example protocol stack according to which a UE communicates with a base station;

[0016] Figure 3 is a message transfer diagram for an example scenario in which a base station configures an SPS with multiple PDSCH opportunities in an SPS period;

[0017] Figure 4A is a messaging diagram of an example scenario in which a base station schedules an SPS with multiple PDSCH opportunities in an SPS period and indicates actual SPS PDSCH transmissions via radio resource control (RRC) signaling and downlink modulation reference signal (DMRS);

[0018] Figure 4B is with Figure 4A Message transfer diagram of an example scenario similar to the example scenario of , but where the base station indicates the actual SPS PDSCH transmission in a medium access control (MAC) control element (CE);

[0019] Figure 5 is with Figure 4A A message delivery diagram of an example scenario substantially similar to that of , but where the retransmission uses SPS PDSCH resources;

[0020] Figure 6 is with Figure 4A A message delivery diagram of an example scenario substantially similar to that of , but wherein the base station and the UE further utilize a mechanism for extending the SPS period;

[0021] Fig. 7A is a message transfer diagram of an example scenario in which a base station schedules multiple concurrent SPS configurations;

[0022] Figure 7B is a message transfer diagram of an example scenario in which a base station schedules an SPS group having multiple SPS configurations;

[0023] Fig. 8A is a message transfer diagram of an example scenario in which a base station schedules an SPS group and configures actual PDSCH transmission;

[0024] Figure 8B is a messaging diagram of an example scenario in which a base station schedules an SPS group and configures actual PDSCH transmissions and SPS configurations of different priorities and in which some of the SPS PDSCH opportunities overlap;

[0025] Fig. 9 The UE can implement Figure 8B A flowchart of an example method for operating in a scenario;

[0026] Fig. 10A is a flow chart of an example method in a base station, the example method comprising determining whether to enable multiple SPS PDSCHs to a UE based on a core network request message and UE capabilities;

[0027] Fig. 10B is a flow chart of an example method in a base station, the example method including determining whether to configure multiple SPS PDSCHs for a UE based on attributes of traffic and UE capabilities;

[0028] Fig.11 is a flow chart of an example method in a UE, the example method including determining whether to report UE capabilities related to multiple SPS PDSCHs to a base station;

[0029] Fig. 12A is a flow chart of an example method in a UE, the example method comprising determining whether to receive a single or multiple SPS PDSCHs within an SPS period based on an SPS configuration;

[0030] Fig. 12B is a flow chart of an example method in a UE, the example method comprising determining whether to receive a single or multiple SPS PDSCHs within an SPS period based on an SPS activation command;

[0031] Fig.13is an example method for communicating with a UE according to an SPS configuration, which example method may be implemented in a RAN node; and

[0032] Fig.14 Variable jitter associated with example video traffic is illustrated. DETAILED DESCRIPTION

[0033] The base station generates an SPS configuration with multiple PDSCH opportunities in a single SPS cycle. The base station provides the SPS configuration to the UE, and when data addressed to the UE arrives from the core network (CN), uses at least some of the PDSCH opportunities to send data to the UE. This method solves the jitter problem of XR streaming by providing the base station with more opportunities to deliver early or delayed XR data to the UE. Furthermore, when the XR video frame / slice is too large to be transmitted within one PDSCH resource configured in the SPS, the base station can split the packet into two or more smaller packets (transport blocks or code blocks) and deliver the smaller packets or blocks in multiple corresponding PDSCH opportunities during one SPS cycle.

[0034] Figure 1A An example wireless communication system 100 is depicted in which the SPS scheduling and transmission techniques of the present disclosure may be implemented. The wireless communication system 100 includes a UE 102, base stations 104, 106A, 106B of a radio access network (RAN) (e.g., RAN 105), and a core network (CN) 110 communicatively coupled to the RAN 105. For example, the base stations 104, 106A, 106B may be of any suitable type, such as an evolved Node B (eNB), a next generation eNB (ng-eNB), or a 5G Node B (gNB). As a more specific example, the base station 104 may be an eNB or a gNB, and the base stations 106A and 106B may be gNBs.

[0035] Base station 104 supports cell 124, base station 106A supports cell 126A, and base station 106B supports cell 126B. Cell 124 partially overlaps with both cells 126A and 126B, so that UE 102 can be within the range of communication with base station 104 while being within the range of communication with base stations 106A and 106B (or within the range of detecting or measuring signals from both base stations 106A and 106B). For example, the overlap can enable UE 102 to switch between cells (e.g., switching from cell 124 to cell 126A or 126B) or base stations (e.g., switching from base station 104 to base station 106A or base station 106B) before UE 102 experiences a radio link failure. In addition, the overlap allows UE 102 to operate in a dual connectivity (DC) mode with RAN 105. For example, UE 102 may communicate with base station 104 (operating as a master node (MN) last night) and base station 106A (operating as a secondary node (SN)) in DC, and after completing the handover to base station 106B, may communicate with base station 106B (operating as a MN). For another example, UE 102 may communicate with base station 104 (operating as a MN) and base station 106A (operating as a SN) in DC, and after completing the SN change, may communicate with base station 104 (operating as a MN) and base station 106B (operating as a SN).

[0036] More specifically, when UE 102 is in DC with base station 104 and base station 106A, base station 104 operates as a master eNB (MeNB), a master ng-eNB (Mng-eNB) or a master gNB (MgNB), and base station 106A operates as a secondary gNB (SgNB) or a secondary ng-eNB (Sng-eNB).

[0037] Base station 104 includes processing hardware 130, which may include one or more general purpose processors (eg, CPUs) and computer readable memory storing machine readable instructions executable on the general purpose processors, and / or special purpose processing units. Figure 1A The processing hardware 130 in an example implementation of includes a base station SPS controller 132 configured to manage SPS configuration and scheduling and to send data to the UE 102 during SPS configured opportunities.

[0038] UE 102 includes processing hardware 150, which may include one or more general-purpose processors (eg, CPUs) and computer-readable memory storing machine-readable instructions executable on the general-purpose processors, and / or special-purpose processing units. Figure 1AThe processing hardware 150 in an example implementation includes a UE SPS controller 152 configured to manage or control the reception of SPS information. For example, the UE SPS controller 152 may be configured to support RRC configuration, procedures, and messaging associated with the SPS process, and / or support necessary operations, as discussed below.

[0039] CN 110 may be an evolved packet core (EPC) 111 or a fifth generation core (5GC) 160, both of which are Figure 1A . The base station 104 may be an eNB supporting an S1 interface for communicating with the EPC 111, an ng-eNB supporting an NG interface for communicating with the 5GC 160, or a gNB supporting an NR radio interface and an NG interface for communicating with the 5GC 160. The base station 106A may be an EUTRA-NR DC (EN-DC) gNB (en-gNB) with an S1 interface to the EPC 111, an en-gNB not connected to the EPC 111, a gNB supporting an NR radio interface and an NG interface to the 5GC 160, or an ng-eNB supporting an EUTRA radio interface and an NG interface to the 5GC 160. In order to exchange messages directly with each other during the scenarios discussed below, the base stations 104, 106A, 106B may support an X2 or Xn interface.

[0040] Among other components, the EPC 111 may include a serving gateway (SGW) 112, a mobility management entity (MME) 114, and a packet data network gateway (PGW) 116. The SGW 112 is generally configured to transmit user plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks (e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network). The 5GC 160 includes a user plane function (UPF) 162 and an access and mobility management (AMF) 164, and / or a session management function (SMF) 166. The UPF 162 is generally configured to transmit user plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions.

[0041] In general, the wireless communication network 100 may include any suitable number of base stations supporting NR cells and / or EUTRA cells. More specifically, the EPC 111 or the 5GC 160 may be connected to any suitable number of base stations supporting NR cells and / or EUTRA cells. Although the examples below specifically relate to specific CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), in general, the techniques of the present disclosure may also be applicable to other suitable radio access technologies and / or core network technologies, such as, for example, sixth generation (6G) radio access and / or 6G core network or 5G NR-6G DC.

[0042] In different configurations or scenarios of the wireless communication system 100, the base station 104 may operate as a MeNB, Mng-eNB, or MgNB, the base station 106B may operate as a MeNB, Mng-eNB, MgNB, SgNB, or Sng-eNB, and the base station 106A may operate as a SgNB or Sng-eNB. The UE 102 may communicate with the base station 104 and the base stations 106A or 106B via the same radio access technology (RAT) such as EUTRA or NR or via different RATs.

[0043] When the base station 104 is a MeNB and the base station 106A is an SgNB, the UE 102 may be in EN-DC with the MeNB 104 and the SgNB 106A. When the base station 104 is a Mng-eNB and the base station 106A is an SgNB, the UE 102 may be in Next Generation (NG) EUTRA-NR DC (NGEN-DC) with the Mng-eNB 104 and the SgNB 106A. When the base station 104 is a MgNB and the base station 106A is an SgNB, the UE 102 may be in NR-NR DC (NR-DC) with the MgNB 104 and the SgNB 106A. When the base station 104 is a MgNB and the base station 106A is an Sng-eNB, the UE 102 may be in NR-EUTRA DC (NE-DC) with the MgNB 104 and the Sng-eNB 106A.

[0044] The core network 110 may communicate XR data with a data network 170, which may be any suitable server or set of servers coupled to the core network 110 via a local area network or a wide area network such as the Internet. In operation, the CN 110 may receive quasi-periodic XR traffic from the data network 170 and send the XR traffic to the UE 102 in a downlink direction via the RAN 105.

[0045] Figure 1BAn example distributed implementation of any one or more of the base stations 104, 106A, 106B is depicted. In this implementation, the base station 104, 106A, or 106B includes a central unit (CU) 172 and one or more distributed units (DUs) 174. The CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions that can be executed on the general-purpose processors, and / or special-purpose processing units. For example, the CU 172 may include Figure 1A processing hardware 130 or 140.

[0046] Each of the DUs 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or a dedicated processing unit. For example, the processing hardware may include: a media access control (MAC) controller configured to manage or control one or more MAC operations or processes (e.g., random access procedures); and a radio link control (RLC) controller configured to manage or control one or more RLC operations or processes when a base station (e.g., base station 106A) operates as a MN or SN. The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer operations or processes.

[0047] In some implementations, the CU 172 may include a logical node CU-CP 172A that hosts a control plane portion of a Packet Data Convergence Protocol (PDCP) protocol of the CU 172 and / or a Radio Resource Control (RRC) protocol of the CU 172. The CU 172 may also include a logical node CU-UP 172B that hosts a user plane portion of a PDCP protocol and / or a Service Data Adaptation Protocol (SDAP) protocol of the CU 172. The CU-CP 172A may transmit SPS control information as well as SPS packets and MBS packets, as described herein.

[0048] CU-CP 172A may be connected to multiple CU-UPs 172B via an E1 interface. CU-CP 172A selects an appropriate CU-UP 172B for the requested service of UE 102. In some implementations, a single CU-UP 172B may be connected to multiple CU-CPs 172A via an E1 interface. CU-CP 172A may be connected to one or more DUs 174 via an F1-C interface. CU-UP 172B may be connected to one or more DUs 174 via an F1-U interface under the control of the same CU-CP 172A. In some implementations, one DU 174 may be connected to multiple CU-UPs 172B under the control of the same CU-CP 172A. In such implementations, the connection between CU-UP 172B and DU 174 is established by CU-CP 172A using a bearer context management function.

[0049] Figure 2 An example protocol stack 200 is illustrated in a simplified manner, according to which a UE 102 may communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106A, 106B).

[0050] In the example stack 200, the physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NRRPHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides RLC channels to the NR PDCP sublayer 210. In some implementations, the UE 102 supports the following: Figure 2 Both the EUTRA and NR stacks shown are provided to support switching between EUTRA and NR base stations and / or to support DC via EUTRA and NR interfaces. Figure 2 As illustrated, the UE 102 may support layering of the NR PDCP 210 above the EUTRA RLC 206A, and layering of the SDAP sublayer 212 above the NR PDCP sublayer 210.

[0051] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets that may be referred to as service data units (SDUs) (e.g., from an Internet Protocol (IP) layer layered directly or indirectly above the PDCP layer 208 or 210), and output packets that may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). Except for cases where the difference between SDUs and PDUs is relevant, for simplicity, the present disclosure refers to both SDUs and PDUs as "packets." Packets may be XR / CG packets or non-XR / CG packets. For example, an XR / CG packet includes an XR / CG data packet that includes application content of an XR / CG service (e.g., IPv4 / IPv6 multicast delivery, IPTV, wireless software delivery, group communication, IoT applications, V2X applications, and / or emergency messages related to public safety). In another example, the XR / CG packet includes application control information for the XR / CG service.

[0052] For example, on the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide SRBs to exchange RRC messages or non-access stratum (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide DRBs to support data exchange. The data exchanged on the NR PDCP sublayer 210 may be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0053] In a scenario where the UE 102 operates in EN-DC with the base station 104 operating as a MeNB and the base station 106A operating as an SgNB, the wireless communication system 100 can provide the UE 102 with a MN terminated bearer using the EUTRA PDCP sublayer 208, or a MN terminated bearer using the NR PDCP sublayer 210. In various scenarios, the wireless communication system 100 can also provide the UE 102 with a bearer terminated at the SN, which bearer terminated at the SN uses only the NR PDCP sublayer 210. The bearer terminated at the MN can be an MCG bearer, a split bearer, or an SCG bearer terminated at the MN. The bearer terminated at the SN can be an SCG bearer, a split bearer, or an MCG bearer terminated at the SN. The bearer terminated at the MN can be an SRB (e.g., SRB1 or SRB2) or a DRB. The bearer terminated at the SN can be an SRB or a DRB.

[0054] Figure 3An example scenario 300 is illustrated in which a base station 104 configures an SPS with multiple PDSCH opportunities and transmits data during some but not all of the opportunities. The base station 104 sends 302 an SPS configuration to a UE 102, wherein each SPS period of the SPS configuration includes multiple SPS PDSCH opportunities. In some implementations, the configuration in event 302 includes a list of multiple PDSCH time domain resource allocations, and the resource allocations may be nominally continuous or non-continuous. Nominally continuous PDSCH opportunities are transmission directions configured by the base station 104. For example, the base station 104 may configure the UE 102 with a TDD transmission mode {DD UUDDDUU}, where D and U refer to downlink and uplink time slots, respectively. In this case, the SPS PDSCH candidates in the 3rd time slot (counting from the left, the D direction) and the SPS PDSCH candidates in the 6th time slot (the D direction time slot, immediately following the U direction time slot) are considered nominally continuous.

[0055] Next, the base station 104 sends 304 the first downlink control information (DCI) to the UE 102 to activate the SPS configuration. The first DCI may indicate SPS PDSCH time domain resource allocation (TDRA) and frequency domain resource allocation (FDRA), modulation and coding scheme (MCS), PDSCH to HARQ feedback timing (dl-DataToUL-ACK-K1), etc. In the scenario 300, there are four SPS PDSCH candidates in the first SPS cycle 380, and each SPS PDSCH opportunity is associated with a specific HARQ process ID (HPID) (e.g., HPID1, 2, 3, and 4). Similarly, there are four SPS PDSCH candidates in the second SPS cycle 382, ​​and each SPS PDSCH opportunity is associated with a specific HPID (e.g., HPID 5, 6, 7, and 8).

[0056] In some implementations, UE 102 may determine the HPID for an SPS PDSCH opportunity based on an RRC configured HPID set, an HPID offset, and an SPS PDSCH opportunity (identified via a slot index).In various scenarios, SPS PDSCHs in different SPS periods may be associated with the same or different HPIDs.

[0057] In the 1st SPS period 380, the base station 104 receives a data packet, for example, from the core network. If the base station is not able to send data in the 1st SPS PDSCH candidate, the base station 104 can omit 308 sending in the 1st SPS PDSCH candidate. As a result, the UE 102 fails to receive 308 the 1st SPS PDSCH candidate. After the base station 104 receives the data packet, the base station 104 divides the data into two transmission blocks (TBs), namely TB 1 and TB 2. Then, the base station 104 sends 310 a transmission of TB 1 in the 2nd SPS PDSCH candidate (referring to the 1st actual SPS PDSCH) and sends 312 a transmission of TB 2 in the 3rd SPS PDSCH candidate (referring to the 2nd actual SPS PDSCH) to the UE 102. Then, if there is no data to be sent, the base station 104 can omit 314 the 4th SPS PDSCH candidate.

[0058] In scenario 300, UE 102 successfully receives TB 1 and TB 2 from the 2nd and 3rd SPS PDSCH candidates, and fails to receive TB 1 and TB 2 from the 1st and 4th SPS PDSCH candidates. UE 102 generates 4 HARQ ACK / NACKs (e.g., {NACK, ACK, ACK, NACK}) for the 1st, 2nd, 3rd, and 4th SPS PDSCH candidates, respectively. Then, UE 102 sends 316 HARQ feedback {NACK, ACK, ACK, NACK} to base station 104 in the PUCCH opportunity indicated by the 1st DCI, which is referenced to the last SPS PDSCH candidate opportunity (i.e., the 4th SPS PDSCH candidate) in the SPS cycle.

[0059] In the 2nd SPS period 382, ​​the data packet arrives before the 1st SPS PDSCH candidate. Similar to the events in the 1st SPS period 380, the base station 104 splits the data packet into two transport blocks, namely TB 3 and TB 4. The base station 104 then sends 320 a transmission of TB 3 in the 1st SPS PDSCH candidate and sends 322 a transmission of TB 4 in the 2nd SPS PDSCH candidate opportunity. If there is no data to send, the base station 104 can omit 324 and 326 the 3rd and 4th SPS PDSCH candidates. During the 2nd SPS period 382, ​​the UE 102 fails to receive 320, 324 and 326 transmissions in the 1st, 3rd and 4th SPS PDSCH candidates, but successfully receives 322 a transmission of TB 4 in the 2nd SPS PDSCH candidate. Therefore, the UE 102 sends 328 HARQ feedback {NACK, ACK, NACK, NACK} to the base station 104. In response to the NACK for the 1st actual SPS PDSCH transmission (TB 3 in the 1st SPS PDSCH candidate), the base station 104 sends 330 the 2nd DCI to the UE 102, thereby scheduling 332 the retransmission of TB 3 with the same HPID as the initial transmission (referring to HPID 5 of the 1st SPS PDSCH candidate in the 2nd SPS period). Based on HPID 5 and other control information (e.g., NDI, MCS) indicated by the 2nd DCI, the UE 102 delivers the received signal to the HARQ process 5 for further combination and decoding. If the UE 102 successfully decodes the data, the UE 102 sends 334 ACK to the base station 104.

[0060] In one implementation, UE 102 determines the HPID of the first SPS PDSCH candidate according to the legacy formula in 3GPP TS 38.321:

[0061] HARQ Process ID (HARQ Process ID) = [floor (CURRENT_slot×10 /

[0062] (numberOfSlotsPerFrame×periodicity)))]modulo

[0063] nrofHARQ-Processes

[0064] or

[0065] HARQ Process ID (HARQ Process ID) = [floor (CURRENT_slot×10 /

[0066] (numberOfSlotsPerFrame×periodicity)))]modulo

[0067] nrofHARQ-Processes+harq-ProcID-Offset

[0068] In another implementation, the UE 102 determines the HPID of the first PDSCH candidate in the SPS period according to one of the following modified formulas:

[0069] HARQ Process ID (HARQ Process ID) = [floor (CURRENT_slot×10 /

[0070] (numberOfSlotsPerFrame×periodicity)×

[0071] numberOfPDSCHsPerSPSPeriod)]modulo nrofHARQ-Processes

[0072] or

[0073] HARQ Process ID (HARQ Process ID) = [floor (CURRENT_slot×10 /

[0074] (numberOfSlotsPerFrame×periodicity))×

[0075] numberOfPDSCHsPerSPSPeriod]modulo nrofHARQ-Processes

[0076] or

[0077] HARQ Process ID (HARQ Process ID) = [floor (CURRENT_slot×10 /

[0078] (numberOfSlotsPerFrame×periodicity)×

[0079] numberOfPDSCHsPerSPSPeriod)]modulo nrofHARQ-Processes+

[0080] harq-ProcID-Offset

[0081] or

[0082] HARQ Process ID (HARQ Process ID) = [floor (CURRENT_slot×10 /

[0083] (numberOfSlotsPerFrame×periodicity))×

[0084] numberOfPDSCHsPerSPSPeriod]modulo nrofHARQ-Processes+

[0085] harq-ProcID-Offset

[0086] The parameter numberOfPDSCHsPerSPSPeriod refers to the number of SPS PDSCH candidates configured in the SPS period.

[0087] In the above implementation, the parameter CURRENT_slot = [(SFN × numberOfSlotsPerFrame) + number of slots in the frame], where numberOfSlotsPerFrame refers to the number of consecutive slots per frame specified in 3GPP TS 38.211. After determining the HPID of the first SPS PDS CH candidate, the UE 102 increases the HARQ process ID by 1 for each subsequent SPS PDSCH candidate according to the scheduling order in the SPS period, and applies a modulo operation of nrofHARQ-ProcessesForPDSCH if nrofHARQ-ProcessesForPDSCH is provided, otherwise a modulo operation of a specified maximum number (e.g., 8) is applied. If at least one of the symbols in the slot indicated by the index row of the resource allocation table used overlaps with a UL symbol indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated (if provided), the HARQ process ID is not incremented for the SPS PDSCH that was not received.

[0088] In the above implementation, if the periodicity configured by the base station 104 is a non-integer value, an additional round-up (eg, ceil(periodity)) or round-down (eg, floor(periodity)) operation may be applied to the parameter.

[0089] Figure 4A and Figure 4BAn example scenario of an SPS configuration with multiple SPS PDSCH candidates in an SPS period is depicted. The base station further indicates the actual PDSCH allocation information to the UE 102 to improve power saving and reduce HARQ feedback overhead.

[0090] Figure 4A An example scenario 400A is depicted. Initially, the base station 104 sends 402 an SPS configuration to the UE 102, wherein the SPS configuration includes a plurality of SPS PDSCH opportunities in an SPS period and a downlink modulation reference signal (DMRS) scrambling ID set (e.g., 2 DMRS scrambling IDs). Then, the base station 104 sends 404 a first DCI to the UE 102 to activate the SPS configuration.

[0091] During the SPS period 480, the base station 104 receives 406 a data packet, for example, from the core network. If the base station 104 cannot send data in the 1st SPS PDSCH candidate, the base station 104 can omit 408 sending data in the 1st SPS PDSCH opportunity. As a result, the UE 102 fails to receive 408 the 1st SPS PDSCH candidate. After the base station 104 receives the data packet at event 406, the base station 104 splits the data packet into two transport blocks, namely TB 1 and TB 2. The base station 104 then generates a 1st DMRS scrambled by the 1st DMRS scrambling ID in the configured DMRS scrambling ID set, and then sends 410 a transmission of TB 1 and the 1st DMRS (referenced to PDSCH index 1) in the 2nd SPS PDSCH candidate (referenced to the 1st actual SPS PDSCH) to the UE 102. Likewise, the base station 104 generates a 2nd DMRS scrambled by the 2nd DMRS scrambling ID in the configured DMRS scrambling ID set, and then transmits 412 a transmission of TB 2 and the 2nd DMRS (reference PDSCH index 2) in the 3rd SPS PDSCH candidate (reference 2nd actual SPS PDSCH) to the UE 102. If there is no data to be transmitted, the base station 104 may omit 414 the transmission in the 4th SPS PDSCH candidate.

[0092] Because the base station 104 transmits actual SPS PDSCH with associated DMRS in nominally consecutive SPS PDSCH opportunities or based on the PDSCH time domain resource allocation indicated in 402, the UE 102 can identify all actual SPS PDSCH transmission opportunities when detecting one of the DMRS scrambling IDs.

[0093] UE 102 fails to detect 410 the 1st DMRS of the 1st actual SPS PDSCH (2nd SPS PDSCH candidate), but successfully detects 412 the 2nd DMRS of the 2nd actual SPS PDSCH (3rd SPS PDSCH candidate). Based on the detection of the 2nd DMRS in the 2nd actual SPS PDSCH and the configured PDSCH time domain allocation information in event 402, UE 102 can identify that there is a missed 410 1st actual SPS PDSCH transmission with PDSCH index 1, and then generates a NACK for the 1st actual SPS PDSCH. If UE 102 successfully decodes the 2nd actual SPS PDSCH, UE 102 generates an ACK for the 2nd actual SPS PDSCH. Next, because the 2nd DMRS is scrambled by the last scrambling ID in the configured DMRS scrambling ID set, UE 102 determines that the data transmission in this SPS period is completed, so UE 102 omits 414 the reception of the 4th SPS PDSCH candidate. Based on the timing 412 of the last actual SPS PDSCH in the SPS cycle 480 (the second actual SPS PDSCH in the third SPS PDSCH candidate timing), the UE 102 sends 416 HARQ feedback {NACK, ACK} for the first and second actual SPS PDSCHs to the base station 104 in the PUCCH timing.

[0094] In response to the NACK for the 1st actual SPS PDSCH, the base station 104 sends 418 a 2nd DCI to the UE 102, which schedules 420 a retransmission of TB 1 having the same HPID as the transmission of TB 1 in 410 of the 1st actual SPS PDSCH. For example, if the HPID of the transmission of TB 1 in the 1st actual SPS PDSCH is HPID 1 (e.g., according to PDSCH index 1), the UE 102 delivers the received signal to the HARQ process 1 for further combining and decoding, and if the HARQ process 1 successfully decodes the retransmission of TB 1, the UE 102 sends 422 an ACK to the base station 104.

[0095] In some implementations, UE 102 determines the HPID for the SPS PDSCH according to the implementation described for scenario 300 .

[0096] In some implementations, UE 102 determines the HPID based on the DMRS scrambling ID. In one example, the SPS configuration sent by the base station 104 to the UE 102 includes a set of HPIDs and a set of DMRS scrambling IDs. If the number of HPIDs is equal to the number of DMRS scrambling IDs, the 1st HPID is associated with the 1st DMRS scrambling ID, the 2nd HPID is associated with the 2nd DMRS scrambling ID, and so on. If the number of actual SPS PDSCH transmissions in the SPS period can be changed semi-statically (e.g., by MAC CE), the number of HPIDs and DMRS scrambling IDs in the set also changes accordingly, so the actual number of SPS PDSCHs in the SPS period is equal to the number of applicable HPIDs and DMRS scrambling IDs. In another example, the SPS configuration sent by the base station 104 to the UE 102 includes a starting HPID (e.g., HPID offset), a starting DMRS scrambling ID, and the number of actual SPS PDSCH transmissions in the SPS period. The number of HPIDs and DMRS scrambling IDs applied by the UE is equal to the number of actual SPS PDSCH transmissions in the SPS period. For example, if the starting HPID is 2, the starting DMRS scrambling ID is 3, and the actual number of SPS PDSCHs in the SPS period is 4, the UE 102 applies HPIDs 2, 3, 4, and 5, and DMRS scrambling IDs 3, 4, 5, and 6 in the SPS period. If the actual number of SPS PDSCHs in the SPS period can be changed (for example, by MAC CE), the number of applicable HPIDs and DMRS scrambling IDs for the SPS period also changes accordingly. In a further example, the SPS configuration sent by the base station 104 to the UE 102 includes an HPID set and a DMRS scrambling ID set. The UE 102 applies the method described in scenario 300 to calculate the first HPID for the SPS period. Then, the UE 102 associates the first HPID with the first DMRS scrambling ID in the set, and associates the second HPID (by incrementing, such as adding 1) with the second DMRS scrambling ID, and so on, until the last applicable DMRS scrambling ID.

[0097] In some implementations, the base station 104 sends a MAC CE to the UE 102 to modify the number of actual SPS PDSCH transmissions in the SPS period, and thus the UE 102 can apply different DMRS scrambling ID sets in different SPS periods. For example, the base station 104 can configure a DMRS scrambling ID set to the UE 102 in event 402, wherein the set includes 8 DMRS scrambling IDs. Before or at the beginning of the first SPS period, the base station 104 sends a first MAC CE to the UE 102 to activate the first 4 DMRS scrambling IDs from the configured DMRS scrambling ID set. In this case, the UE 102 expects 4 actual PDSCH transmissions in the first SPS period, generates 4 HARQ feedbacks (e.g., ACK and / or NACK) for the SPS PDSCH in the first SPS period, and sends 4 HARQ feedbacks to the base station 104 on the HARQ feedback resources (e.g., PUCCH or PUSCH resources) in the PUCCH opportunity. Then, due to increased traffic, or changes in channel conditions or reliability requirements, the base station 104 may determine to use more SPS PDSCH to send data in the SPS period. In this case, the base station 104 may send a second MAC CE to the UE 102 to activate 6 of the 8 DMRS scrambling IDs from the configured DMRS scrambling ID set. In response to the second MAC CE, the UE 102 expects 6 or 8 actual PDSCH transmissions in the second SPS period, generates 6 or 8 HARQ feedbacks (e.g., ACK and / or NACK) for the SPS PDSCH in the second SPS period, and sends 6 or 8 HARQ feedbacks to the base station 104 on the HARQ feedback resources in the PUCCH opportunity. In some implementations, the UE 102 may initiate application of the changes indicated by the second MAC CE in the current SPS period or the next SPS period.

[0098] Figure 4B An example scenario 400B is shown that is similar to 400A, except that the actual SPS PDSCH information indication is indicated by using a MAC CE or a piggyback DCI. First, the base station 104 sends 401 an SPS configuration to the UE 102, wherein the SPS configuration includes multiple SPS PDSCH opportunities in the SPS period. Then, the base station 104 sends 404 a first DCI to the UE 102 to activate the SPS configuration.

[0099] During the SPS period 481, the base station 104 receives 406 a data packet, for example, from the core network. If the base station 104 cannot send data in the 1st SPS PDSCH candidate, the base station 104 omits 408 sending data in the 1st SPS PDSCH candidate. As a result, the UE 102 fails to receive 408 the 1st SPS PDSCH candidate. After the base station 104 receives the data packet at event 406, the base station 104 splits the data packet into two transport blocks, namely TB 1 and TB 2. Then, the base station 104 sends 409 a transmission of TB 1 in the 2nd SPS PDSCH candidate (referring to the 1st actual SPS PDSCH) to the UE 102, wherein the 2nd SPS PDSCH carries the 1st MAC CE or piggyback DCI indicating the actual SPS PDSCH information in the SPS period 481. Likewise, the base station 104 transmits 411TB 2 transmission to the UE 102 in the 3rd SPS PDSCH candidate (referring to the 2nd actual SPS PDSCH), where the 3rd SPS PDSCH candidate carries the 2nd MAC CE or piggyback DCI indicating the actual SPS PDSCH information in the SPS period 481. In one example, the actual SPS PDSCH information indicated by the 1st MAC CE and the 2nd MAC CE or piggyback DCI may be the same or different. If the UE 102 is configured to send HARQ feedback (e.g., Figure 5 If the actual SPS PDSCH information is applied to the SPS period 481, otherwise the UE applies the actual SPS PDSCH information starting from the next SPS period. If there is no data to be sent, the base station 104 can omit 414 transmission in the 4th SPS PDSCH candidate.

[0100] In one implementation, the MAC CE or the DCI includes a bitmap, wherein the length of the bitmap is equal to or greater than the number of SPS PDSCH candidates in the SPS period. The bitmap size in scenario 400B can be 4, because there are 4 SPS PDSCH candidates in the SPS period. Each bit in the bitmap indicates whether the actual SPS PDSCH is or will be sent in the SPS PDSCH candidate. For example, the base station 104 sends a transmission of 409TB 1 in the 2nd and 3rd SPS PDSCH candidates, respectively, and sends a transmission of 411TB 2. Therefore, the base station 104 indicates the 2nd and 3rd bits in the bitmap as 1 for the actual SPS PDSCH transmission, and indicates the 1st and 4th bits in the bitmap as 0 for no transmission, so that the bitmap is generated as {0,1,1,0}. In another implementation, the MAC CE or the DCI signaling includes the starting timing (e.g., 2) of the 1st actual SPS PDSCH to indicate the actual SPS PDSCH transmission and the length of the nominal continuous transmission (e.g., 2).

[0101] Referring again to scenario 400B, UE 102 receives a signal from an SPS PDSCH candidate and determines the HPID based on the implementation described for scenario 300. Similar to scenario 400A, UE 102 fails to receive 408 the 1st and 409 2nd SPS PDSCH candidates, and successfully receives 411 the 2nd actual SPS PDSCH in the 3rd PDSCH candidate. When UE 102 successfully decodes 411 the 2nd actual SPS PDSCH, UE 102 obtains actual SPS PDSCH transmission information from the MAC CE or piggyback DCI carried by the 2nd actual SPS PDSCH. Therefore, UE 102 knows that there is a missed 1st actual SPS PDSCH in the 2nd SPS PDSCH candidate, and there are 2 actual SPS PDSCH transmissions in the SPS period 481. Then, UE 102 generates NACK for the 1st actual SPS PDSCH, generates ACK for the 2nd actual SPS PDSCH, and sends 416 HARQ feedback {NACK, ACK} to base station 104 in the PUCCH opportunity. UE 102 and base station 104 determine the PUCCH timing based on the timing of the last actual SPS PDSCH (i.e., the 2nd actual SPS PDSCH in the 3rd SPS PDSCH candidate timing). Similar to scenario 400A, UE 102 can omit 414 the 4th SPS PDSCH candidate.

[0102] In response to the NACK for the 1st actual SPS PDSCH, the base station 104 sends 418 the 2nd DCI to the UE 102, thereby scheduling 420 the retransmission of TB 1 with HPID 2. Based on the HPID 2 indicated by the 2nd DCI, the UE 102 delivers the received signal to the HARQ process 2 for further combining and decoding. If the HARQ process 2 successfully decodes the retransmission of TB 1, the UE 102 sends 422 an ACK to the base station 104.

[0103] Figure 5 An example scenario 500 similar to scenario 400A is depicted. In addition, the base station 104 configures the UE 102 to send HARQ feedback between SPS PDSCH candidates (e.g., in an FDD scenario). In this scenario, the base station 104 is able to resend the transport block using the SPS PDSCH, and the UE 102 can apply a combining operation in the HARQ process for the retransmission delivered by the SPS PDSCH.

[0104] In one implementation, the base station 104 sends the actual SPS PDSCH according to the order of the DMRS scrambling IDs in the configured ID set. First, the base station 104 performs events 502, 504, and 508, respectively, which are similar to events 402, 404, and 408 in scenario 400A. At event 506, the base station 104 receives a data packet, for example, from the core network, and splits the data packet into two transport blocks, namely TB 1 and TB 2. Then, the base station 104 sends 510 a transmission of TB 1 with PDSCH index 1 in the 2nd SPS PDSCH candidate (the 1st actual SPS PDSCH) to the UE 102. If the UE 102 detects PDSCH index 1 based on the DMRS scrambling ID, but fails to receive TB 1, the UE 102 sends 522 a NACK to the base station 104. If the UE 102 does not detect the DMRS and thus does not send 522 HARQ feedback to the base station 104, the base station 104 may determine that the UE 102 missed 510 reception of TB 1 and PDSCH index 1. In response to 522 the NACK for the 1st actual SPS PDSCH, the base station 104 sends 512 a retransmission of TB 1 with PDSCH index 1 in the 3rd SPS PDSCH candidate (the 2nd actual SPS PDSCH) to the UE 102. If the UE 102 successfully receives and decodes TB 1, the UE 102 sends 524 an ACK to the base station 104. In response to 524 the ACK for the 2nd actual SPS PDSCH, the base station 104 sends 514 a transmission of TB 2 with PDSCH index 2 in the 4th SPS PDSCH candidate to the UE 102. If UE 102 fails to receive 514 the transmission of TB 2, UE 102 sends 516 a NACK to base station 104, which may then resend TB 2 using events 518, 520, and 522, respectively, similar to events 418, 420, and 422 in scenario 400A. If UE 102 successfully receives the last actual SPS PDSCH transmission (based on the PDSCH index) in SPS period 580, UE 102 may omit receiving subsequent SPS PDSCH candidates in SPS period 580.

[0105] In another implementation, the base station 104 transmits the actual SPS PDSCH with DMRS scrambling IDs in any order. For example, the base station 104 may transmit a transmission of TB2 with PDSCH index 2 before a transmission of TB1 with PDSCH index 1. In this case, when all configured PDSCH indices (all activated / configured DMRS scrambling IDs) are detected in the SPS period 580, the UE 102 may stop receiving SPS PDSCH candidates.

[0106] In another implementation, the base station 104 may send a DCI, MAC CE, or piggyback DCI indicating that the actual SPS PDSCH transmission in this SPS period is complete to the UE 102. In response, the UE 102 may omit the remaining SPS PDSCH candidates in this SPS period regardless of the number of detected PDSCH indices.

[0107] In some examples, if the delay budget has expired and base station 104 decides to discard the data packet, base station 104 can signal UE 102 (e.g., via MAC CE or piggyback DCI) to cancel detection of remaining SPS PDSCH candidate opportunities and not report associated HARQ-ACK feedback.

[0108] In another example, the base station 104 can signal the UE 102 (e.g., via a MAC CE or a piggyback DCI) to deactivate the current SPS configuration and switch to another SPS configuration (e.g., with a larger PDSCH resource) for the next SPS opportunity. In one implementation, the MAC CE or the piggyback DCI carries a target SPS configuration index.

[0109] Figure 6 An example scenario 600 is depicted that is similar to scenario 400A, except that an SPS period extension mechanism is introduced. Figure 4A The SPS configuration is configured and activated by events 602 and 604 similar to events 402 and 404 in . During the SPS period 680, at event 606, a data packet, such as a data packet from the core network, arrives at a timing at which the base station 104 cannot transmit data in the 1st, 2nd, and 3rd SPS PDSCH candidates. Therefore, the base station 104 omits 608, 610, and 612 for transmission in the 1st, 2nd, and 3rd SPS PDSCH candidates. In response to event 606, the base station 104 splits the data packet into two transmission blocks, namely TB 1 and TB 2. Then, the base station 104 sends 614 a transmission of TB 1 with PDSCH index 1 in the 4th SPS PDSCH candidate (the 1st actual SPS PDSCH) to the UE 102. The UE identifies PDSCH index 1 based on the DMRS scrambling ID and successfully receives TB 1. Therefore, UE 102 determines that there is a second actual SPS PDSCH transmission that cannot be sent in SPS period 680 because there are no remaining SPS PDSCH candidates in SPS period 680. UE 102 generates ACK for the first actual SPS PDSCH and NACK for the second actual SPS PDSCH (without detection and reception), and then sends 616 HARQ feedback {ACK, NACK} to base station 104.

[0110] In one implementation, because UE 102 does not detect the event of all activated / configured PDSCH indexes in SPS period 680, UE 102 extends 618 the SPS monitoring period to the extended SPS period 682. Base station 104 knows that UE 102 will extend the SPS period due to the same event, so base station 104 sends 620 a transmission of TB 2 with PDSCH index 2 in the 5th SPS PDSCH candidate to UE 102. In one example, the PDSCH time domain resources of the 5th SPS PDSCH candidate are nominally continuous with the 4th SPS PDSCH candidate. The number of SPS PDSCH candidates in the extended SPS period 682 is based on the number of PDSCH indexes not detected in the SPS period 680, or the number of actual SPS PDSCHs not received (e.g., the number of NACKs in HARQ feedback). In another example, base station 104 configures the number of SPS PDSCH candidates and / or PDSCH time domain resources in the extended SPS period in the case of event 602. When UE 102 is triggered to extend the SPS period, UE 102 applies the configuration of event 602 to receive additional SPS PDSCH candidates (eg, the 5th SPS PDSCH candidate) outside of the original SPS period 680. If UE 102 successfully receives TB 2, UE 102 sends 622 ACK to base station 104.

[0111] In another implementation, due to the arrival time of the data packet at event 606, the base station 104 can foresee the shortage of SPS PDSCH candidates in the SPS period 680, so the base station 104 instructs the UE 102 to extend the SPS period by sending a DCI, a MAC CE, or a piggyback DCI (carried by the actual SPS PDSCH) in the SPS period 680. In response to the indication, the UE 102 receives the additional SPS PDSCH candidates after the original SPS period 680.

[0112] In some implementations, the UE 102 determines the HPID of the SPS PDSCH in the extended SPS period by increasing the HPID of the last SPS PDSCH candidate by 1. For example, the HPID of the 5th SPS PDSCH candidate is calculated by increasing the HPID of the 4th SPS PDSCH candidate (the last actual SPS PDSCH) by 1. Similarly, if there is a 6th SPS PDSCH candidate after the 5th SPS PDSCH candidate, the HPID will be calculated by increasing the HPID of the 5th SPS PDSCH candidate by 1. In addition, a modulo operation can be applied after the increment operation to control the HPID value in the configured HPID set for the SPS configuration / period.

[0113] In other implementations, the UE 102 determines the HPID in the extended SPS period by cyclically reusing the HPID from the original SPS period. For example, the 5th SPS PDSCH candidate may be calculated as follows:

[0114] [HPID of the first PDSCH candidate + 5 - 1] modulus (number of HPIDs configured in the SPS period)

[0115] In this example, if the number of HPIDs configured in the SPS cycle is 4, the HPID of the 5th SPS PDSCH candidate will be the same as the HPID of the 1st SPS PDSCH candidate or the 1st actual SPS PDSCH in the SPS cycle.

[0116] In another implementation, the UE 102 may be signaled (eg, via a MAC CE or piggybacked DCI) to change any SPS configuration parameters, such as the MCS, for the next SPS PDSCH opportunity.

[0117] In another implementation, the UE 102 may be signaled to change configuration parameters for some specific future SPS D SCH occasions.

[0118] In another implementation, the UE 102 may be signaled to change configuration parameters for the remaining SPS PDSCH opportunities of the SPS period.

[0119] In another implementation, the UE 102 may be signaled (eg, via a MAC CE or piggybacked DCI) to change the SPS opportunity start time for the next opportunity, eg, delaying or advancing the start time by a certain offset.

[0120] In another implementation, if code block group (CBG) based transmission is configured in SPS PDSCH, ACK / NACK feedback may be per CBG per TB. Thus, UE 102 may report HARQ-ACK feedback for one or all PDSCH opportunities by concatenating ACK / NACK for one or all SPS PDSCH opportunities per CBG per TB.

[0121] Fig. 7AAn example scenario 700A is depicted of an SPS transmission mode using multiple SPS configurations to create one SPS period including multiple SPS PDSCH candidates. The base station 104 configures 702 the following two SPS configurations to the UE 102: SPS1 and SPS2, where each SPS configuration can be a legacy SPS that includes a single SPS PDSCH opportunity or multiple SPS PDSCH opportunities in the SPS period. Further, the base station 104 assigns HPIDs 1 and 2 to SPS1, and HPIDs 3 and 4 to SPS2. Similar to scenario 300, the SPS period includes multiple nominally consecutive SPS PDSCH opportunities contributed by one or more SPS configurations. If the base station 104 configures the TDD UL / DL transmission mode {DDDUUDDD UU} to the UE 102, where D and U represent downlink and uplink time slots, respectively, there is an example of nominally consecutive SPS PDSCH opportunities. In this case, the SPS PDSCH candidates of SPS1 in slot 3 and the SPS PDSCH candidates of SPS2 in slot 6 are considered nominally continuous. In another implementation, the base station 104 configures the length (with a starting position, if any) and the periodicity of the SPS period to the UE 102, so that the UE 102 considers that the SPS PDSCH candidates (of SPS1 or SPS2) within the configured length belong to the same SPS periodicity.

[0122] Next, the base station 104 sends 704 the 1st DCI and the 2nd DCI to the UE 102 to activate SPS1 and SPS2, respectively. In the 1st SPS period 780, the base station 104 receives a data packet, for example, from the core network, and the base station 104 cannot send 708 transmission in the 1st SPS PDSCH candidate. In response to receiving the data packet, the base station 104 divides the data into two transport blocks, namely TB 1 and TB 2. Then, the base station 104 sends TB 1 in the 2nd SPS PDSCH candidate (1st actual SPS PDSCH) of SPS1 and TB 2 in the 1st SPS PDSCH candidate (2nd actual SPS PDSCH) of SPS2 to the UE 102, respectively. In one example, the 1st and 2nd DCIs may indicate different PDSCH to HARQ feedback timings so that the UE 102 sends HARQ feedback (for SPS1 and SPS2 in the SPS period) in the same PUCCH opportunity. The PDSCH to HARQ feedback timing is a timing offset referenced to the last SPS PDSCH candidate of the SPS configuration in the SPS period. If there is no data to send, the base station 104 may omit 714 the 4th SPS PDSCH candidate opportunity.

[0123] In the 1st SPS cycle 780, the UE 102 successfully receives TB 1 and TB 2. Then, the UE 102 generates HARQ feedback {NACK, ACK} for the 1st and 2nd SPS PDSCH candidates, and generates HARQ feedback {ACK, NACK} for the 3rd and 4th SPS PDSCH candidates. If the base station 104 indicates the same PUCCH resource for SPS1 and SPS2, the UE 102 sends 716 multiplexed HARQ feedback {NACK, ACK, ACK, NACK} to the base station 104. Otherwise, if the base station 104 indicates different PUCCH resources for SPS1 and SPS2, the UE 102 sends HARQ feedback for SPS1 and SPS2 in different PUCCH resources, respectively.

[0124] In the 2nd SPS periodicity 782, there are only SPS PDSCH candidates for SPS2, because SPS1 and SPS2 can be configured with different periodicities. The base station receives 718 data packets, such as data packets from the core network. Then, the base station 104 divides the data packets into two transport blocks TB 3 and TB 4, and sends them in 720 the 1st SPS PDSCH candidate of SPS2 and 722 the 2nd SPS PDSCH candidate. In this example, UE 102 fails to receive TB 3 and successfully receives TB4. Therefore, UE 102 sends 724 HARQ feedback {NACK, ACK} to base station 104 in the PUCCH opportunity based on the 2nd SPS PDSCH candidate opportunity (the last SPS PDSCH candidate) of SPS2 in the SPS period 782. In response to the NACK in event 724, the base station 104 sends 726 the 3rd DCI to UE 102 to schedule 728 the retransmission of TB 3 with HPD 3. If UE 102 successfully receives and decodes TB 3 , UE 102 sends 730 ACK to base station 104 .

[0125] Figure 7B An example scenario 700B similar to 700A is depicted, which shows another method for multiple SPS configurations. The base station 104 sends 701 an SPS group configuration to the UE 102, which includes SPS1 and SPS2 configurations and a set of HPIDs (e.g., HPID 1, 2, 3, and 4). Each SPS configuration may include multiple SPS PDSCH opportunities in an SPS period. The base station 104 then sends 703 a 1st DCI to the UE 102 to activate SPS1 and / or SPS2. The remaining events are similar to Fig. 7ASimilarly, the difference is that the PDSCH to HARQ feedback timing indicated by the 1st DCI 704 only refers to the last SPS PDSCH candidate in the SPS cycle. Further, in scenario 700B, the configured HPID set applies to SPS1 and SPS 2, so SPS PDSCH candidates of SPS1 or SPS2 in different SPS cycles can be associated with the same HPID. For example, the 1st SPS PDSCH candidate of SPS1 in the 1st SPS cycle 781 and the 1st SPS PDSCH candidate of SPS2 in the 2nd SPS cycle 783 are both associated with HPID 1.

[0126] In response to the NACK for transmission 720 of TB 3 at event 724 , base station 104 sends 725 a 2nd DCI to UE 102 to schedule 728 a retransmission of TB 3 with HPID 1. If UE 102 successfully receives and decodes TB 3 , UE 102 sends 730 an ACK to base station 104 .

[0127] Fig. 8A An example scenario 800A is depicted, which has an SPS group configuration similar to scenario 700B and has an actual PDSCH timing indication mechanism (PDSCH index and DMRS scrambling ID method) as described for scenario 400A. Similar to events 701 and 703, base station 104 sends 802 and 804 to UE 102 to configure and activate the SPS group configuration. In addition, the configuration in 802 includes actual SPS PDSCH information as described for event 402. In the 1st SPS cycle 880, UE 102 successfully receives 810 the 1st and 812 the 2nd actual SPS PDSCH. Then, UE 102 generates HARQ feedback {ACK, ACK} for the 1st and 2nd actual SPS PDSCH and sends it 816 to base station 104.

[0128] Figure 8BAn example scenario 800B is depicted, where the SPS PDSCH candidate opportunities between SPS configurations may overlap. The base station 104 sends 801 an SPS group configuration to the UE 102, where the SPS group configuration in event 801 includes a high priority SPS1 with actual SPS PDSCH information, PDSCH indexes 1 and 2 (DMRS scrambling ID), and a low priority SPS2 with actual SPS PDSCH information, PDSCH index 3. As shown in the SPS period 880, there are 3 SPS PDSCH candidates for SPS1 and 3 SPS PDSCH candidates for SPS2, where the 2nd and 3rd SPS PDSCH candidates for SPS1 overlap with the 1st and 2nd SPS PDSCH candidates for SPS2, respectively. Then, the base station sends 804 the 1st DCI to the UE 102 to activate the SPS group configuration.

[0129] In the SPS period 881, the base station 104 receives 806 a data packet, for example, from the core network. Then, the base station 104 segments the data into three transport blocks TB 1, TB 2, and TB 3, where TB 1 and TB 2 have the higher priority of the two, and TB 3 has the lower priority. Next, if the base station 104 is able to send data in the 1st SPS PDSCH candidate of SPS1, the base station 104 sends 807 a transmission of TB 1 with PDSCH index 1 in the 1st SPS PDSCH candidate of SPS1 to the UE 102, and sends 809 a transmission of TB 2 with PDSCH index 2 in the 2nd SPS PDSCH candidate of SPS1 to the UE 102. Similarly, the base station 104 sends 811 a transmission of TB 3 with PDSCH index 3 in the 2nd SPS PDSCH candidate of SPS2 to the UE 102. The base station omits 813 the transmission in the 3rd SPS PDSCH candidate of SPS2 because the transmissions with all configured / activated PDSCH indices have been sent.

[0130] Then, UE 102 determines the HPID and receives the SPS PDSCH candidate using the method as described for 400A. UE 102 successfully receives 807 the 1st actual SPS PDSCH of SPS1, and obtains the actual SPS PDSCH transmission information by detecting PDSCH index 1. Based on PDSCH index 1 and the actual SPS PDSCH transmission information from event 801, UE 102 knows that there will be a 2nd actual SPS PDSCH carrying a high priority TB in the subsequent SPS PDSCH candidates, followed by a 3rd actual SPS PDSCH carrying a low priority TB. Therefore, UE 102 determines to receive the 2nd SPS PDSCH candidate of SPS1 at event 809, instead of the 1st SPS PDSCH candidate of SPS2. Similarly, the UE determines to receive the 2nd SPS PDSCH candidate of SPS2 at event 811, instead of the 3rd SPS PDSCH candidate of SPS1. The UE omits receiving 813 the 3rd SPS PDSCH candidate of SPS2 because the UE knows that there is no longer any transmission in SPS period 881. Then, UE 102 generates HARQ feedback {ACK, NACK, ACK} for the 1st, 2nd and 3rd actual SPS PDSCH transmissions and sends 815 them to base station 104. In response to the NACK for the 2nd actual SPS PDSCH of SPS1, base station 104 sends 818 a 2nd DCI with HPD 2 to schedule 820 a retransmission of TB 2 to UE 102. If UE 102 successfully receives TB 2, UE 102 sends 822 ACK to base station 104.

[0131] In another implementation, the method (MAC CE method) described for scenario 400B may be applied to scenario 800B. In some implementations, base station 104 sends a DCI, MAC CE, or piggyback DCI including the first bitmap of SPS1 and the second bitmap of SPS2 to UE 102. In other implementations, base station 104 sends a DCI, MAC CE, or piggyback DCI including a bitmap of an SPS group (a superset of SPS PDSCH candidates of SPS1 and SPS2) to UE 102. In a further example, base station 104 sends a DCI, MAC CE, or piggyback DCI including the first bitmap for the SPS group (superset) and the second bitmap for SPS1 or 2 to UE 102.

[0132] In another implementation, the SPS period extension method described for scenario 600 may be applied to scenarios 800A and 800B. In some implementations, the base station 104 configures the target SPS configuration index (SPS1 or 2) for the UE 102. If the UE 102 is triggered or indicated (via DCI or MAC CE or piggyback DCI) to perform SPS extension, the UE 102 applies the parameters (e.g., FDRA, MCS) of the target SPS configuration in the extended SPS period. In other implementations, the base station 104 indicates the target SPS configuration index for SPS period extension through a field in a DCI format, MAC CE, or piggyback DCI.

[0133] Fig. 9 Illustrated for Figure 8BAn example method 900 of a UE process for an example scenario in FIG. The method starts at box 902, where the UE receives an SPS group configuration, including a 1st SPS configuration with a higher priority, a 2nd SPS configuration with a lower priority, and actual SPS PDSCH transmission information. At box 904, the UE receives an activation command for the 1st and / or 2nd SPS configuration of the SPS group. At box 906, the UE receives a transport block from the SPS PDSCH candidate of the 1st SPS in the SPS period. At box 908, the UE identifies the actual SPS PDSCH transmission carried by the HPID and SPS PDSCH candidate. At box 910, if the current SPS PDSCH is the last SPS PDSCH candidate of the 1st SPS or the last actual SPS PDSCH transmission. In response to the actual SPS PDSCH information detected at box 908, the UE determines at box 910 whether the current SPS PDSCH candidate is the last SPS PDSCH candidate of the 1st SPS or the last actual SPS PDSCH. If the UE 102 determines that the current SPS PDSCH candidate is the last SPS PDSCH candidate of the 1st SPS or the last actual SPS PDSCH, the process proceeds to block 912. At block 912, the UE may send HARQ feedback for the SPS PDSCH of the 1st SPS in the SPS cycle to the base station 104. Otherwise, if the UE determines that the current SPS PDSCH candidate is neither the last SPS PDSCH candidate of the 1st SPS nor the last actual SPS PDSCH, the process proceeds to block 906, where the UE continues to receive the next SPS PDSCH candidate of the 1st SPS in the SPS cycle. After block 914, the UE receives the SPS PDSCH candidate of the 2nd SPS in the SPS cycle. At box 916, the UE identifies the HPID associated with each transport block based on the actual PDSCH transmission indication carried in the SPS PDSCH; at box 918, the UE determines whether the current SPS PDSCH candidate is the last SPS PDSCH candidate or the last actual SPS PDSCH of the 2nd SPS in the SPS cycle. If the UE determines that the current SPS PDSCH candidate is the last SPS PDSCH candidate or the last actual SPS PDSCH of the 2nd SPS, the process proceeds to box 920. At box 920, the UE sends HARQ feedback for the SPS PDSCH of the 2nd SPS in the SPS cycle to the base station. Otherwise, if the UE determines that the current SPS PDSCH candidate is neither the last SPS PDSCH candidate of the 2nd SPS nor the last actual SPS PDSCH, the process proceeds to box 914, where the UE continues to receive the next SPS PDSCH candidate for the 2nd SPS in the SPS cycle.If the UE does not send 912 HARQ feedback for the SPS PDSCH of the 1st SPS in the SPS cycle to the base station 104, the UE sends HARQ feedback for the SPS PDSCH of the 1st SPS and the 2nd SPS in the SPS cycle at block 920. Finally, at block 922, the UE may omit the remaining SPS PDSCH candidates in the SPS cycle and proceed to the next SPS cycle.

[0134] Fig. 10A An example method 1000A is illustrated in which a base station (e.g., base station 104) determines whether to enable multiple SPS PDSCH configurations for a UE (e.g., UE 102). Method 1000A begins at box 1002, where the base station performs communication with the UE. At box 1004, the base station receives a request message from a core network to configure resources for the UE. The core network can be CN 110 or a CN node in CN 110 (e.g., AMF 164). At box 1006, the base station determines whether the request message includes specific QoS parameters (e.g., for XR services) and whether the UE supports multiple SPS PDSCHs. If the base station determines that the request message includes specific QoS parameters (e.g., for XR services) and the UE supports multiple SPS PDSCHs, the process proceeds to box 1008. At block 1008, the base station enables multiple SPS PDSCHs for the UE (e.g., events 302, 304, 401, 402, 404, 502, 504, 602, 604, 701, 702, 703, 704, 801, 802, 804). Otherwise, if the request message does not include specific QoS parameters (e.g., for XR services) or the UE does not support multiple SPS PDSCHs, the flow proceeds to block 1010. At block 1010, the base station 104 avoids enabling multiple SPS PDSCHs for the UE.

[0135] In some implementations, the base station may send a response message to the core network in response to the request message. In some implementations, the request message and the response message are a PDU session resource setting request message and a PDU session resource setting response message, respectively. In other implementations, the request message and the response message are a PDU session resource modification request message and a PDU session resource modification response message, respectively.

[0136] After enabling multiple SPS PDSCHs, the base station may use multiple SPS PDSCHs to send data packets to the UE (e.g., events 380, 382, ​​480, 481, 780, 781, 782, 783, 880, 881). In some implementations, the base station at block 1010 may use dynamic scheduling to send data packets to the UE. In further implementations, if the UE supports a single SPS PDSCH, the base station may enable a single SPS PDSCH for the UE at block 1010 and send data packets to the UE using the single SPS PDSCH.

[0137] Fig. 10B An example method 1000B is illustrated that is similar to 1000A, except that at block 1005, the base station detects downlink data traffic for the UE according to specific traffic characteristics (e.g., for XR traffic characteristics). At block 1007, the base station determines whether the UE supports multiple SPS PDSCHs. If the base station determines that the UE supports multiple SPS PDSCHs, the process proceeds to block 1008. Otherwise, if the UE does not support multiple SPS PDSCHs, the process proceeds to block 1010.

[0138] Fig.11 An example method 1100 is illustrated in which a UE (e.g., UE 102) determines whether to send a UE capability indicating support for multiple SPS PDSCHs to a network (e.g., RAN 105 and / or CN 110, or base station 104 and / or AMF 164). The method 1100 begins at block 1102, where the UE determines to send multiple UE capabilities of the UE to the network. At block 1104, the UE determines whether the UE enables support for multiple SPS PDSCHs. If the UE determines that the UE enables support for multiple SPS PDSCHs, the process proceeds to block 1106. At block 1106, the UE sends to the network multiple UE capabilities of the UE including a capability indicating support for multiple SPS PDSCHs. Otherwise, if the UE determines that the UE disables support for multiple SPS PDSCHs, the process proceeds to block 1108. At block 1108, the UE sends to the network multiple UE capabilities of the UE that do not include a capability indicating support for multiple SPS PDSCHs.

[0139] In some implementations, the UE may be preconfigured to enable or disable support for multiple SPS PDSCHs before sending multiple UE capabilities. In one implementation, the UE has an item in a non-volatile memory to indicate whether the UE supports multiple SPS PDSCHs. If the item is set to a first value, the UE determines that support for multiple SPS PDSCHs is enabled. Otherwise, if the item is set to a second value, the UE determines that support for multiple SPS PDSCHs is disabled.

[0140] Fig. 12A An example method 1200A is illustrated in which a UE (e.g., UE 102) determines whether to receive a single SPS PDSCH or multiple SPS PDSCHs based on an SPS configuration. At block 1202, the UE receives an SPS configuration from a network (e.g., events 302, 402, 401, 502, 602, 702, 701, 802, 801). At block 1204, the UE receives an SPS activation command from the network (e.g., events 304, 404, 504, 604, 704, 703, 804). In some implementations, the UE activates the SPS configuration in response to the SPS activation command. At block 1206, the UE determines whether the SPS configuration is configured with multiple PDSCHs. If the UE determines that the SPS configuration is configured with multiple SPS PDSCHs, the process proceeds to block 1208. At block 1208, the UE periodically attempts to receive or receives multiple SPS PDSCHs based on the SPS configuration and the SPS activation command. Otherwise, the flow proceeds to block 1210. At block 1210, the UE periodically attempts to receive or receives a single SPS PDSCH according to the SPS configuration and the SPS activation command.

[0141] In some implementations, the SPS activation command is a DCI. In other implementations, the SPS activation command is a MAC CE.

[0142] In some implementations, an SPS configuration (e.g., SPS-Config) may include configuration parameters for configuring multiple SPS PDSCHs in an SPS period. For example, the configuration parameters configure the timing of SPS PDSCH candidates or transmissions. If the SPS configuration does not include configuration parameters, the SPS configuration configures a single SPS PDSCH in an SPS period.

[0143] In some implementations, the network may include the number of opportunities within the SPS cycle in the SPS configuration. The UE determines the first opportunity (i.e., the starting opportunity) in the opportunity according to the SPS activation command, and determines the remaining opportunities according to the number of opportunities, based on the first opportunity and the remaining opportunities. For example, the number of opportunities is N, where N is an integer and greater than one. The UE determines that the remaining opportunities (i.e., (N-1) opportunities) are continuous according to the number of opportunities, and there is or is no offset (i.e., gap) between two consecutive opportunities after the first opportunity. The network may include an offset (value) to indicate the gap between two consecutive opportunities.

[0144] In other implementations, the network may include one or more offsets between opportunities within the SPS cycle in the SPS configuration. The UE determines the first opportunity (i.e., the starting opportunity) in the opportunity according to the SPS activation command, and determines the remaining opportunities based on the first opportunity and the offset. The offset includes offset 1, offset 2, ..., offset (N-1), where N indicates the number of opportunities and may be greater than one. In one implementation, offset 1 indicates the offset (or gap) between the first opportunity and the second opportunity, offset 2 indicates the offset between the second opportunity and the third opportunity, ..., and offset (N-1) indicates the offset between the (N-1)th opportunity and the Nth opportunity. In another implementation, offset 1 indicates the offset (or gap) between the first opportunity and the second opportunity, offset 2 indicates the offset between the first opportunity and the third opportunity, ..., and offset (N-1) indicates the offset between the first opportunity and the Nth opportunity.

[0145] Fig. 12B An example method 1200B similar to 1200A is illustrated, except that at box 1207, if the SPS activation command activates multiple SPS PDSCHs, the process continues to box 1208, otherwise, if the activation command activates a single SPS PDSCH, the process continues to box 1210.

[0146] In some implementations, the SPS activation command for activating multiple SPS PDSCHs is different from the SPS activation command for activating a single SPS PDSCH. In one implementation, the SPS activation command for activating multiple SPS PDSCHs includes multiple downlink assignments, each of which configures a specific SPS PDSCH, and the SPS activation command for activating a single PDSCH includes a single downlink assignment for configuring a single PDSCH. Therefore, the UE can determine whether the received activation command activates multiple PDSCHs or a single PDSCH based on (the number of) downlink assignments. In another implementation, the SPS activation command for activating multiple SPS PDSCHs includes a specific field indicating that the SPS activation command is used to activate multiple SPS PDSCHs, and the SPS activation command for activating a single SPS PDSCH does not include this specific field. Therefore, the UE can determine whether the received SPS activation command activates multiple PDSCHs or a single PDSCH based on whether the specific field is included in the SPS activation command. In another implementation, the SPS activation command for activating multiple SPS PDSCHs includes a specific field set to a first value, and the SPS activation command for activating a single SPS PDSCH includes this specific field set to a second value. The first value indicates that the SPS activation command is used to activate multiple SPS PDSCHs, and the second value indicates that the SPS activation command is used to activate a single SPS PDSCH. Therefore, the UE can determine whether the received SPS activation command activates multiple PDSCHs or a single PDSCH based on whether the specific field is set to the first value or the second value. In another implementation, the SPS activation command for activating multiple SPS PDSCHs conforms to the first DCI format, and the SPS activation command for activating a single SPS PDSCH conforms to the second DCI format. Therefore, the UE can determine whether the SPS activation command activates multiple PDSCHs or a single PDSCH based on whether the received SPS activation command conforms to the first DCI format or the second DCI format.

[0147] Fig.13An example method 1300 is illustrated in which a RAN node (e.g., base station 104 or DU 174) enables multiple SPS PDSCH configurations for a UE (e.g., UE 102). Method 1300 begins at block 1302, where the RAN node communicates with the UE. At block 1304, the RAN node sends an SPS configuration (e.g., events 302, 304, 401, 402, 404, 502, 504, 602, 604, 701, 702, 703, 704, 801, 802, 804) to the UE to configure multiple SPS PDSCHs. At block 1306, the RAN node sends an SPS activation command to the UE to activate the SPS configuration. At block 1308, the RAN node periodically sends multiple SPS PDSCHs according to the SPS configuration and the SPS activation command.

[0148] against Fig. 12A and Fig. 12B The examples and implementations described may be applicable to Fig.13 .

[0149] Further discussion on XR traffic modeling

[0150] refer to Fig.14 , XR traffic is quasi-periodic traffic with a period equal to the inverse of the XR frame rate. Thus, if the frame rate is 60 frames per second (fps), the periodicity is 16.67 ms. XR traffic suffers from jitter due to the delay variation in encoding the video frames at the codec. Jitter is statistically modeled in 3GPP RAN1 Rel-17 SI [2] as a truncated Gaussian distribution with a standard deviation of 2 ms and a range of + / -4 ms.

[0151] Due to the variations in video frame sizes (I-frames, P-frames, B-frames), the XR packet size is also variable and is also statistically modeled in 3GPPRAN1 Rel-17 SI [2] as a truncated Gaussian distribution with mean = (average data rate) / (fps of video stream) / 8 [bytes] and [STD, maximum, minimum] = [10.5, 150, 50]% of the mean.

[0152] exist Fig.14 In the figure, the jitter is taken from a truncated Gaussian distribution with a mean of 0ms, a standard deviation of 2ms, and a range of [-4, +4ms]; the frame size is taken from a truncated Gaussian distribution with a mean = (average data rate) / (fps of the video stream) / 8[bytes] [STD, maximum, minimum] = [10.5, 150, 50]% of the mean. For example, for a data rate of 30Mbps and 60fps, the mean is 64Kbyte.

[0153] In the UL direction, attitude / control information is modeled in 3GPP RAN1 Rel-17 SI [2] as periodic (e.g., 4 ms periodicity is assumed in RAN1), with a fixed packet size (e.g., 100 bytes in RAN1), and without jitter.

[0154] For UL AR traffic, there is no jitter value modeled in RAN1. The jitter of UL traffic should be smaller than that of DL traffic and less severe.

[0155] Potential SPS and CG enhancements

[0156] Generally speaking, SPS is designed to allocate persistent and periodic resources for services such as VoIP. SPS and CG are also used for services such as IIoT / URLLC for small and periodic packet transmission. XR services are characterized by quasi-periodic traffic, so the motivation is to consider semi-persistent scheduling as a candidate for scheduling XR traffic to reduce control overhead and reduce latency compared to dynamic scheduling. XR traffic is also characterized by large and varying packet sizes, so using SPS / CG mechanisms such as in Rel-16 and Rel-17 is challenging. SPS / CG cannot dynamically adapt to changing packet sizes.

[0157] For example, for an XR data rate of 30Mbps and a frame rate of 60fps, the average value of the frame size is 64KB, and the range is 32KB to 96KB. It is very challenging to send such large and variable-sized video frames using SPS / CG. Scaling the allocated SPS / CG resources to the worst case (maximum frame size) is also very resource-inefficient because this over-configuration will be detrimental to system capacity. In addition, based on the 3GPP RAN1 SI evaluation, the bottleneck of the XR system capacity is not the control channel but the data channel, so it is not reasonable to use SPS / CG to improve the system capacity.

[0158] I. Enhancements to SPS / CG should be demonstrated for XR scheduling and should be evaluated against Dynamic Grant (DG) scheduling which should be considered as the baseline. Enhancements to SPS / CG should be demonstrated for XR scheduling and should be evaluated against Dynamic Grant (DG) scheduling which should be considered as the baseline.

[0159] Mismatch between SPS / CG periodicity and XR traffic periodicity: Current CG / SPS periodicity is not aligned with AR / VR frame rates. In the current CG / SPS design, the cycle is a multiple value of the time slot. However, the example packet arrival rates to be evaluated for XR are {30,60,90,120}fps, so the corresponding traffic periodicity for XR is a non-integer value {33.33,16.67,11.11,8.33}ms. There is a mismatch between XR traffic arrival periodicity and CG / SPS periodicity.

[0160] II. Support alignment between SPS / CG periodicity and XR traffic.

[0161] The alignment with XR traffic periodicity is similar for SPS / CG and C-DRX. Therefore, a unified solution that can be used to align SPS / CG cycles with XR traffic and align C-DRX with XR traffic can be studied.

[0162] It is best to use the C-DRX formula defined in the MAC specification [TS 38.321] as a starting point and adjust the formula to correct for drift. A similar formula can also be defined to align the SPS / CG periodicity with the XR traffic periodicity.

[0163] Multiple PDSCH / PUSCH transmissions per SPS / CG opportunity

[0164] In the old SPS / CG configuration, a single PDSCH / PUSCH transmission is allowed per SPS / CG opportunity, which is not suitable for XR traffic with large and varying packet sizes. Relying on multiple SPS opportunities to send large packets will hurt the traffic packet delay budget (PDB) because waiting for the next SPS opportunity will increase the scheduling delay.

[0165] Using multiple SPS configurations can partially solve the problem, but it requires additional PDCCH signaling overhead whenever an SPS configuration needs to be activated / deactivated, which increases the control overhead and is not beneficial to UE power consumption.

[0166] Therefore, SPS / CG enhancement by allowing multiple PDSCH / PUSCH opportunities per SPS / CG cycle may be further studied as a possible solution to address the varying XR packet size.

[0167] However, using multiple PDSCH / PUSCH opportunities per SPS / CG cycle may be subject to jitter. Multiple opportunities can be configured per cycle to accommodate varying packet sizes, but packets may arrive early or late, which means that some PDSCH / PUSCH opportunities can be omitted and transmissions can start anywhere in the opportunity. The UE should be able to identify at which opportunity a packet transmission has started. One approach is to use a specific DMRS scrambling ID to identify the PDSCH transmission index.

[0168] For example, a large packet may be split into TB1 and TB2. The packet arrives late due to jitter, and the first PDSCH opportunity in the SPS cycle is missed. Then, the gNB generates the 1st DMRS scrambled by the 1st DMRS scrambling ID, and sends TB1 with the 1st DMRS to the UE in the 2nd SPS PDSCH opportunity. Similarly, the gNB generates the 2nd DMRS scrambled by the 2nd DMRS scrambling ID, and sends TB2 with the 2nd DMRS to the UE in the 3rd SPS PDSCH opportunity in the SPS cycle. The HPID may also be determined based on the DMRS scrambling ID.

[0169] Failure to identify PDSCH transmissions in PDSCH opportunities means that the UE will attempt to decode all opportunities in the SPS cycle and send NACKs for empty opportunities. Therefore, UE power consumption is increased and HARQ-ACK feedback overhead is increased. Failure to identify PDSCH transmissions also means uncertainty at the UE about the start and end of the segmented packets.

[0170] HARQ-ACK feedback for multiple PDSCH opportunities can be studied. The UE may need to splice HARQ-ACK feedback from different opportunities in one PUCCH transmission. But this may introduce some latency because the gNB needs to wait for the end of all PDSCH opportunities to get HARQ-ACK feedback and be able to schedule any required retransmissions.

[0171] In addition, techniques to reduce UE power consumption and HARQ-ACK feedback overhead can be studied. For example, since XR traffic targets high reliability (99% PER) and the majority of HARQ-ACK reports will consist of ACKs, ACKs can be omitted (e.g., if all PDSCH opportunities within one SPS cycle are ACKs) to reduce UE transmissions and save UE power consumption. In addition, the HARQ-ACK feedback overhead can be reduced by sending a single bit (using an AND function) for all PDSCH opportunities within one SPS cycle. This requires further study because, although it reduces the HARQ-ACK feedback overhead, it is not very resource-efficient for PDSCH transmissions because some successful PDSCHs may be retransmitted if one or some other PDSCHs within the same SPS cycle have failed.

[0172] In addition, if the UE misses one or some of the multiple PDSCH opportunities, it should know which opportunity has been missed in order to report correct HARQ-ACK feedback.

[0173] Another option is to allocate PUCCH resources for each PDSCH opportunity in the SPS cycle to quickly report HARQ-ACK feedback and allow the network to prepare and quickly send retransmissions before the expiration of the PDB.

[0174] III. Support multiple PDSCH / PUSCH transmissions per SPS / CG cycle for XR services.

[0175] IV. Use DMRS scrambling to identify PDSCH transmissions in different PDSCH opportunities in an SPS cycle.

[0176] Dynamic Adaptation of SPS / CG Parameters: Dynamic adaptation of SPS parameters can be studied to achieve better resource efficiency without switching between different SPS configurations or activating / deactivating SPS.

[0177] Dynamic adaptation of SPS parameters can help solve jitter problems and frame size changes, and it can be used with multi-PDSCH and multi-PUSCH transmissions, for example, dynamically enabling additional PDSCH / PUSCH opportunities for large video frames and canceling / omitting PDSCH / PUSCH opportunities for small video frames to solve frame size changes. It can also be used to delay or advance PDSCH / PUSCH opportunities to solve jitter problems.

[0178] Dynamic adaptation requires additional control overhead, which goes against the motivation of using SPS / CG to obtain reduced control overhead compared to DG. Therefore, research on dynamic adaptation should consider the increased control overhead and how it detrimentally affects system capacity.

[0179] Additionally, for dynamic adaptation, the UE may miss reception of dynamic signaling and this may impair adaptive signaling, and the UE may not be able to receive subsequent opportunities due to missing new SPS parameters (eg, new time / frequency resources, etc.) for upcoming PDSCH opportunities.

[0180] Additionally, for UL AR traffic, the UE needs to carry UCI or MAC CE information to request a modification of the CG PUSCH timing, and the gNB needs to process the request and signal dynamic control information to update the CG allocation. Therefore, CG configuration type 2 is more suitable for UL AR traffic. This may require a lot of control overhead and increase latency. Therefore, for UL AR traffic, some enhancements can be utilized to rely on multiple simultaneously active CG configurations.

[0181] Multiple simultaneously active CG configurations can be configured to match UL AR traffic. However, some versions do not support joint activation of multiple CG configurations. Therefore, one possible enhancement is to study support for joint activation of multiple CG configurations through the same DCI for UL AR traffic.

[0182] V. Study the dynamic adaptation of SPS parameters for scheduling of DL XR traffic while considering the increased control overhead.

[0183] VI. Study the impact of a UE missing the reception of the dynamic adaptation of scheduled SPS parameters for DL ​​XR traffic.

[0184] VII. Study on UL AR traffic supports joint activation of multiple CG configurations using a single DCI.

[0185] CBG-based transmission for SPS: CBG-based transmission is supported for dynamic scheduling to improve spectral efficiency. If SPS will be used to send large XR video frames, CBG should be considered for SPS. In addition, the current URLLC / IIoT design does not support CBG-based transmission. Multiple URLLC / IIoT features are useful for XR to achieve low latency and high reliability transmission. Support for CBG-based transmission by this feature is worth exploring. For example, compact DCI may be useful for XR to reduce control overhead and improve control channel reliability, but compact DCI does not currently support CBG transmission.

[0186] VIII. Support CBG-based transport for SPS for scheduling of XR traffic.

[0187] BSR enhancement: The network requires UE to report auxiliary information quickly and accurately to facilitate efficient resource allocation and ensure good QoE. In NR, the gNB is informed of the UE buffer size level through the buffer status report (BSR), but since the gNB does not know when the data arrives at the UE's buffer, the gNB may not know exactly how much data is waiting for a long time. It may be beneficial to provide the gNB with timing information as part of the BSR report. With this information, the gNB can prioritize specific UEs and efficiently allocate resources to meet more UEs.

[0188] IX. Support for providing timing information as part of the BSR report.

[0189] In addition, UL XR traffic consists of multiple flows such as attitude / control information and UL AR video traffic, audio traffic, etc. The flows have different latency requirements. The attitude / control information has a more stringent latency requirement and should be delivered faster to meet its PDB. However, the BSR report does not distinguish between the flows, and the attitude / control information may be treated similarly to the UL AR video traffic by the gNB scheduler and may not be scheduled on time.

[0190] X.Support providing traffic priority information as part of BSR reporting.

[0191] Therefore, several potential enhancements for XR services can be further studied and explored to achieve XR service capacity enhancement. The above discussion includes the following proposals:

[0192] 1) SPS / CG enhancements should be demonstrated for XR scheduling and should be evaluated against Dynamic Grant (DG) scheduling, which should be considered as the baseline.

[0193] 2) Support alignment between SPS / CG periodicity and XR traffic.

[0194] 3) Support multiple PDSCH / PUSCH transmissions per SPS / CG cycle for XR services.

[0195] 4) Use DMRS scrambling to identify PDSCH transmissions in different PDSCH opportunities in the SPS cycle.

[0196] 5) Study the dynamic adaptation of SPS parameters for scheduling of DL XR traffic while considering the increased control overhead.

[0197] 6) Study the impact of UE missing the reception of dynamic adaptation of SPS parameters for scheduling of DL XR traffic.

[0198] 6) Research on UL AR traffic supports joint activation of multiple CG configurations using a single DCI.

[0199] 7) Support CBG-based transport for SPS for scheduling of XR traffic.

[0200] 8) Support providing timing information as part of the BSR report.

[0201] 9) Support providing traffic priority information as part of BSR report.

[0202] This disclosure contemplates at least the following examples:

[0203] Example 1. A communication method implemented in a user equipment UE, the communication method comprising: receiving a semi-persistent SPS configuration from a radio access network RAN, the semi-persistent SPS configuration indicating multiple DL opportunities for receiving data sent from the RAN to the UE in a downlink DL direction within a single cycle of the SPS; attempting to receive first data in a first DL opportunity among the multiple DL opportunities and receiving second data in a second DL opportunity among the multiple DL opportunities; and sending corresponding confirmations for the first data and the second data within a single uplink opportunity.

[0204] Example 2. The method of Example 1, wherein the SPS configuration includes a time division duplex (TDD) mode indicating (i) the plurality of DL opportunities and (ii) the uplink opportunities.

[0205] Example 3. The method of Example 1, further comprising: receiving downlink control information DCI from the RAN separately from the sending of the SPS configuration to activate the SPS configuration at the UE and indicate the uplink opportunity.

[0206] Example 4. The method as described in any of the preceding examples further comprises: associating each of the multiple DL opportunities with a corresponding hybrid automatic repeat request HARQ process identifier HPID, wherein the confirmation for the first data and the second data is a HARQ ACK or NACK message.

[0207] Example 5. The method of Example 4, further comprising: receiving the HPID set configuration via radio resource control (RRC) messaging.

[0208] Example 6. The method of Example 4, further comprising: determining the HPID for the plurality of DL opportunities based on a time slot number of the SPS and a periodicity of the cycle.

[0209] Example 7. The method as described in any of the preceding examples further comprises: sending a positive confirmation for each DL opportunity in the multiple DL opportunities in which the UE successfully receives a transmission; and sending a negative confirmation for each DL opportunity in the multiple DL opportunities in which the UE does not receive a transmission.

[0210] Example 8. The method of any one of Examples 1 to 6, further comprising sending a positive or negative acknowledgement for only those DL opportunities among the plurality of DL opportunities that the RAN uses for corresponding transmissions.

[0211] Example 9. The method as described in any of the preceding examples further comprises: receiving an indication from the RAN that actual transmission is to occur in the first DL opportunity of the plurality of DL opportunities and second data is to occur in a second DL opportunity of the plurality of DL opportunities.

[0212] Example 10. The method of Example 9, wherein receiving the indication of the actual transmission comprises receiving a media access channel MAC control element CE.

[0213] Example 11. The method of Example 9, wherein: receiving the indication of the actual transmission comprises receiving a piggyback DCI.

[0214] Example 12. The method as described in Example 9 further includes: receiving a downlink modulation reference signal DMRS scrambling identifier ID set for corresponding DL opportunities among the multiple DL opportunities from the RAN; wherein the reception of the indication of the actual transmission includes: receiving a first DMRS scrambling ID in the first DL opportunity among the multiple DL opportunities; and receiving a second DMRS scrambling ID in the second DL opportunity among the multiple DL opportunities.

[0215] Example 13. The method of any of the preceding examples, further comprising:

[0216] In response to a failure to receive one of the first data or the second data, the single cycle of the SPS is extended.

[0217] Example 14. A method as described in any of the preceding examples, wherein: the SPS configuration is a first SPS configuration; the method further comprises: receiving a second SPS configuration together with the first SPS configuration; and attempting to concurrently receive transmissions based on the first SPS configuration and the second SPS configuration.

[0218] Example 15. A method for sending data to a user equipment UE, the method being implemented in a radio access network RAN ​​and comprising: sending a semi-persistent SPS configuration to the UE, the semi-persistent SPS configuration indicating a plurality of DL opportunities for sending data in a downlink DL direction from the RAN node to the UE within a single cycle of the SPS; sending first data to the UE in the th DL opportunity among the plurality of DL opportunities and sending second data to the UE in a second DL opportunity among the plurality of DL opportunities; and receiving corresponding confirmations for the first data and the second data within a single uplink opportunity.

[0219] Example 16. The method of Example 15, wherein the SPS configuration comprises a time division duplex (TDD) mode having (i) the plurality of DL opportunities and (ii) the uplink opportunities.

[0220] Example 17. The method as described in Example 15 further includes: sending downlink control information DCI to the UE separately from the sending of the SPS configuration to activate the SPS configuration at the UE and indicate the uplink opportunity.

[0221] Example 18. The method as described in any one of Examples 15 to 17 further includes: associating each DL opportunity of the multiple DL opportunities with a corresponding hybrid automatic repeat request HARQ process identifier HPID, wherein the confirmation for the first data and the second data is a HARQ ACK or NACK message.

[0222] Example 19. The method of Example 18, further comprising: configuring the HPID set via radio resource control (RRC) messaging.

[0223] Example 20. The method as described in any one of Examples 15 to 19 further includes: receiving a positive confirmation for each DL opportunity in the multiple DL opportunities in which the UE successfully receives a transmission; and receiving a negative confirmation for each DL opportunity in the multiple DL opportunities in which the UE does not receive a transmission.

[0224] Example 21. The method of any one of Examples 15 to 20, further comprising: receiving a positive or negative acknowledgement only for those DL opportunities among the plurality of DL opportunities that the RAN uses for corresponding transmissions.

[0225] Example 22. The method as described in any one of Examples 15 to 21 further includes: sending an indication to the UE that actual transmission is to occur in the first DL opportunity among the multiple DL opportunities and second data is to occur in the second DL opportunity among the multiple DL opportunities.

[0226] Example 23. The method of Example 22, wherein sending the indication of the actual transmission comprises sending a media access channel MAC control element CE.

[0227] Example 24. The method of Example 22, wherein sending the indication of the actual transmission comprises sending a piggyback DCI.

[0228] Example 25. The method as described in Example 22 further includes: sending a downlink modulation reference signal DMRS scrambling identifier ID set for the corresponding DL opportunities among the multiple DL opportunities to the UE; wherein the sending of the indication of the actual transmission includes: sending a first DMRS scrambling ID in the first DL opportunity among the multiple DL opportunities; and sending a second DMRS scrambling ID in the second DL opportunity among the multiple DL opportunities.

[0229] Example 26. The method as described in any one of Examples 15 to 25 further includes: in response to determining that the UE fails to receive one of the first data or the second data, extending the single cycle of the SPS.

[0230] Example 27. A method as described in any one of Examples 15 to 26, wherein: the SPS configuration is a first SPS configuration; the method further includes: sending a second SPS configuration together with the first SPS configuration; and sending concurrently according to the first SPS configuration and the second SPS configuration.

[0231] Example 28. The method as described in any one of Examples 15 to 27 further includes: receiving a data packet from a core network; in response to determining that the size of the data packet exceeds the capacity of each DL opportunity among the multiple opportunities: sending a first part of the data packet as the first data in the first DL opportunity among the multiple DL opportunities, and sending a second part of the data packet as the second data in the second DL opportunity among the multiple opportunities.

[0232] Example 29. A method as described in any of the preceding examples, wherein the multiple opportunities are physical downlink shared channel PDSCH opportunities.

[0233] Example 30. A method as described in any of the preceding examples, wherein the uplink opportunity is a physical uplink control channel PUCCH opportunity.

[0234] Example 31. A method as described in any of the preceding examples, wherein each of the first data and the second data is sent as a corresponding transmission block TB.

[0235] Example 33. A method as described in any of the preceding examples, wherein the SPS configuration is provided via RRC messaging.

[0236] Example 34. A method for sending data to a user equipment UE, the method being implemented in a radio access network RAN ​​and comprising: sending a semi-persistent SPS configuration to the UE, the semi-persistent SPS configuration indicating a plurality of opportunities for sending data in a downlink DL direction from the RAN node to the UE within a single cycle of the SPS; sending an indication to the UE of at least one opportunity among the plurality of opportunities for the RAN node to use for sending the data; and sending the data to the UE in the indicated one of the plurality of opportunities.

[0237] Example 35. The method as described in Example 34 further includes: sending downlink control information DCI to the UE separately from the sending of the SPS configuration to activate the SPS configuration at the UE and indicate the uplink opportunity.

[0238] Example 36. The method of Example 34 or 35, wherein the indication of the at least one of the plurality of opportunities comprises a media access channel MAC control element CE.

[0239] Example 37. A method as described in Example 34 or 35, wherein: the indication of the at least one of the multiple occasions includes a DCI.

[0240] Example 38. The method as described in Example 34 or 35 further includes: sending a downlink modulation reference signal (DMRS) scrambling identifier (ID) set for the corresponding DL opportunity among the multiple DL opportunities to the UE; wherein sending the indication includes: sending the corresponding DMRS scrambling ID.

[0241] The following description can be applied to the above description.

[0242] In general, the description of one of the above figures may apply to another of the above figures. The above events or boxes may be optional or omitted. For example, the events or boxes with dotted lines in the accompanying drawings may be optional. In some implementations, "message" is used and "information element (IE)" can be used to replace "message", and vice versa. In some implementations, "IE" is used, and "field" can be used to replace "IE", and vice versa. In some implementations, "configuration (configuration(s))" or "configuration parameter" can be used to replace "configuration (configuration)", and vice versa. In some implementations, "PDSCH" can be replaced with "PDSCH transmission" or "transmission on PDSCH". In some implementations, "PUSCH" can be replaced with "PUSCH transmission" or "transmission on PUSCH". "HPID for SPS PDSCH" or "HPID associated with SPS PDSCH" can be used to replace "HPID of SPS PDSCH". In some implementations, “multiple SPS PDSCHs” may be replaced by “multiple SPS PDSCHs in an SPS period” or “multiple SPS PDSCHs configured by a (single) SPS configuration”.

[0243] Although the above description is described for DL ​​SPS, the description may also be applied to UL SPS (i.e., configuration grant). For example, "PDSCH", "SPS PDSCH", "PDSCH" or "SPS PDSCH" may be replaced with "PUSCH", "transmission on PUSCH with configuration grant", "PUSCH" or "transmission on PUSCH with configuration grant".

[0244] In some implementations, the SPS configuration (e.g., SPS-Config) includes at least one of the following configuration parameters:

[0245] • Periodicity of multiple SPS PDSCHs or a single SPS PDSCH. In some implementations, the UE and the network may determine the periodicity based on the configured subcarrier spacing.

[0246] The number of HARQ processes used to receive multiple SPS PDSCHs or a single SPS PDSCH

[0247] HARQ codebook ID: It indicates the HARQ-ACK codebook index of the corresponding HARQ-ACK codebook for SPS PDSCH and ACK for SPS PDSCH release.

[0248] HARQ process ID offset (eg, harq-ProcID-Offset): This indicates the offset used to derive the HARQ process ID.

[0249] MCS table: It indicates the MCS table that the UE applies to DL SPS. If this parameter is configured, the UE and the base station (i.e., the network) use the MCS table of the low SE 64QAM table indicated in Table 5.1.3.1-3 of the 3GPP specification 38.214 for multiple SPS PDSCHs or a single SPS PDSCH in the SPS period. If this parameter is not configured, and the parameter mcs-table in the PDSCH-Config IE is set to 'qam256', and the DCI being activated has format 1_1, the UE and the base station shall apply the 256QAM table indicated in Table 5.1.3.1-2 of the 3GPP specification 38.214 for multiple SPS PDSCHs or a single SPS PDSCH in the SPS period. If this parameter is not configured, and the parameter mcs-table-r17 in the PDSCH-Config IE is set to 'qam1024', and the DCI being activated is format 1_1, the UE and the base station shall apply the 1024QAM table indicated in Table 5.1.3.1-4 of 3GPP specification 38.214 for multiple SPS PDSCHs or a single SPS PDSCH in the SPS period. Otherwise, the UE shall apply the non-low SE 64QAM table indicated in Table 5.1.3.1-1 of 3GPP specification 38.214 for multiple SPS PDSCHs or a single SPS PDSCH in the SPS period.

[0250] PUCCH resource ID configures PUCCH resources for HARQ feedback for multiple SPS PDSCHs or a single SPS PDSCH. In some implementations, the base station configures the PUCCH resources to a specific format (e.g., format 0, 1, 2, 3, 4, 5, or 6). The UE and the base station determine the actual PUCCH resources based on the PUCCH-Config IE and the PUCCH resource ID.

[0251] The user device (e.g., UE 102) in which the technology of the present disclosure can be implemented can be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile game console, a point of sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smart watch, a wireless hotspot, a femtocell or a broadband router. Further, in some cases, the user device can be embedded in an electronic system, such as a head unit (headunit) or an advanced driver assistance system (ADAS) of a vehicle. Further, the user device can be operated as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0252] Certain implementations are described in the present disclosure as including logic or multiple components or modules. A module may be a software module (e.g., a code or machine-readable instruction stored on a non-temporary machine-readable medium) or a hardware module. A hardware module is a tangible unit that is capable of performing certain operations and may be configured or arranged in a particular manner. A hardware module may include dedicated circuitry or logic that is permanently configured to perform certain operations (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.). A hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations (e.g., as contained in a general-purpose processor or other programmable processor). The decision to implement a hardware module with a dedicated and permanently configured circuitry or with a temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0253] When implemented in software, the techniques may be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software may be executed by one or more general-purpose processors or one or more special-purpose processors.

Claims

1. A communication method implemented in a user equipment UE, the communication method comprising: receiving a semi-persistent SPS configuration from a radio access network RAN, the semi-persistent SPS configuration indicating a plurality of DL opportunities within a single period of the SPS for receiving data sent in a downlink DL direction from the RAN to the UE; attempting to receive first data in a first DL opportunity among the plurality of DL opportunities and receiving second data in a second DL opportunity among the plurality of DL opportunities; and Respective acknowledgements for the first data and the second data are sent within a single uplink opportunity.

2. The method of claim 1, wherein the SPS configuration includes a time division duplex (TDD) mode indicating (i) the plurality of DL opportunities and (ii) the uplink opportunities.

3. The method of claim 1, further comprising: Separately from the sending of the SPS configuration, downlink control information (DCI) is received from the RAN to activate the SPS configuration at the UE and indicate the uplink opportunity.

4. The method according to any one of the preceding claims, further comprising: associating each DL opportunity of the plurality of DL opportunities with a corresponding hybrid automatic repeat request HARQ process identifier HPID, The confirmation for the first data and the second data is a HARQ ACK or NACK message.

5. The method of claim 4, further comprising: The HPID set configuration is received via Radio Resource Control, RRC messaging.

6. The method of claim 4, further comprising: The HPIDs for the plurality of DL opportunities are determined based on a slot number of the SPS and a periodicity of the cycle.

7. The method of any one of the preceding claims, further comprising: sending a positive acknowledgement for each DL opportunity in the plurality of DL opportunities in which the UE successfully received a transmission; as well as For each DL opportunity in the plurality of DL opportunities in which the UE did not receive a transmission, a negative acknowledgement is sent.

8. The method according to any one of claims 1 to 6, further comprising: Positive or negative acknowledgement is sent only for those DL opportunities of the plurality of DL opportunities which are used by the RAN for corresponding transmissions.

9. The method of any one of the preceding claims, further comprising: An indication is received from the RAN that actual transmission is to occur in the first of the plurality of DL opportunities and that second data is to occur in a second of the plurality of DL opportunities.

10. The method of claim 9, further comprising: receiving, from the RAN, a downlink modulation reference signal (DMRS) scrambling identifier (ID) set for corresponding DL opportunities among the plurality of DL opportunities; wherein said receiving of said indication of said actual transmission comprises: receiving a first DMRS scrambling ID in the first DL opportunity among the plurality of DL opportunities; as well as A second DMRS scrambling ID is received in the second DL opportunity among the plurality of DL opportunities.

11. The method of any one of the preceding claims, further comprising: In response to a failure to receive one of the first data or the second data, the single cycle of the SPS is extended.

12. A method as claimed in any one of the preceding claims, wherein: The SPS configuration is a first SPS configuration; The method further comprises: receiving a second SPS configuration along with the first SPS configuration; and Attempting to concurrently receive transmissions according to the first SPS configuration and the second SPS configuration.

13. A method for sending data to a user equipment UE, the method being implemented in a radio access network RAN ​​and comprising: sending a semi-persistent SPS configuration to the UE, the semi-persistent SPS configuration indicating a plurality of DL opportunities for sending data in a downlink DL direction from the RAN node to the UE within a single period of the SPS; transmitting first data to the UE in a first DL opportunity among the plurality of DL opportunities and transmitting second data to the UE in a second DL opportunity among the plurality of DL opportunities; and Respective acknowledgements for the first data and the second data are received within a single uplink opportunity.

14. The method of any one of the preceding claims, further comprising: receiving data packets from a core network; In response to determining that the size of the data packet exceeds the capacity of each of the plurality of opportunities: transmitting a first portion of the data packet as the first data in the first DL opportunity among the plurality of DL opportunities, and The second part of the data packet is transmitted as the second data at the second timing among the plurality of timings.

15. A device comprising: Transceiver; as well as Processing hardware configured to implement a method according to any one of the preceding claims.

Images