Configured uplink grant for small data transmissions

Abstract

An apparatus, method, and system for an SDT procedure using CG resources are disclosed. The method (1100) includes a step of transmitting a first configured grant small data transmission of the SDT procedure to a network entity (1110) using a configured uplink grant for small data transmission. The method (1100) includes a step of inhibiting processing of a subsequent configured uplink grant allocated for a small data transmission for a first new transmission of subsequent uplink data of the SDT procedure (1115). The method (1100) includes a step of receiving a confirmation of the first configured grant small data transmission. The method (1100) includes a step of processing a subsequent configured uplink grant allocated for a small data transmission for a first new transmission of subsequent uplink data of the SDT procedure (1125) in response to receiving the confirmation of the first configured grant small data transmission.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority to U.S. Provisional Patent Application No. 63 / 287,033, filed on December 7, 2021, entitled "CG - SDT PROCEDURE FOR SMALL DATA TRANSMISSIONS IN RRC_INACTIVE" by Joachim Lohr, Prateek Basu Mallick, Alexander Golitschek, Hyung - Nam Choi, and Ravi Kuchibhotla, which is hereby incorporated by reference herein.

[0002] The subject matter disclosed herein generally relates to wireless communication, and more particularly, to configuring a user equipment (UE) for small data transmissions (SDT) using uplink resources, such as configured grants (CG).

Background Art

[0003] The new radio (NR) system of the 3rd Generation Partnership Project (3GPP) supports the RRC_INACTIVE state, and devices with low (periodic and / or aperiodic) data transmission frequencies are generally maintained in the RRC_INACTIVE state by the network. However, according to the current 3GPP standard, the RRC_INACTIVE state does not support data transmission. Therefore, a user equipment (UE) must resume the connection (i.e., transition to the RRC_CONNECTED state) in order to transmit any uplink (i.e., mobile - originating) data or receive any downlink (i.e., mobile - terminated) data.

Summary of the Invention

Means for Solving the Problems

[0004] Disclosed are procedures related to SDT procedures that use CG resources. These procedures may be implemented by apparatus, systems, methods, or computer program products.

[0005] One method in the UE includes the steps of receiving a configuration from a network entity to allocate a configured uplink grant for a small data transmission, and sending the first configured grant small data transmission of the SDT procedure to the network entity using the configured uplink grant for the small data transmission. The method includes the steps of suppressing the processing of subsequent configured uplink grants allocated for small data transmissions for the first new transmission of subsequent uplink data in the SDT procedure, and receiving confirmation of the first configured grant small data transmission from the network entity. The method includes the steps of processing subsequent configured uplink grants allocated for small data transmissions for the first new transmission of subsequent uplink data in the SDT procedure, in response to receiving confirmation of the first configured grant small data transmission.

[0006] A more detailed description of the embodiments briefly described above is made by reference to specific embodiments illustrated in the accompanying drawings. Understanding that these drawings illustrate only a few embodiments and should therefore not be considered limitations of scope, the embodiments are described and explained more specifically and in detail using the accompanying drawings. [Brief explanation of the drawing]

[0007] [Figure 1] This is a schematic block diagram showing one embodiment of a wireless communication system for an SDT procedure using CG resources. [Figure 2] This is a block diagram showing one embodiment of the protocol stack for New Radio ("NR"). [Figure 3]This figure shows one embodiment of the Wireless Resource Control ("RRC") restart procedure. [Figure 4A] This figure shows one embodiment of the procedure for an SDT procedure based on a random access channel and / or configured grant ("RACH / CG") in RRC_INACTIVE. [Figure 4B] This figure shows one embodiment of a procedure for an SDT procedure based on a random access channel ("RACH") with subsequent data transmission. [Figure 5] This flowchart illustrates one embodiment of the procedure for selecting SDT or non-SDT resources. [Figure 6] This figure shows one embodiment of the abstract syntax notation 1 ("ASN.1") for the LogicalChannelConfig information element ("IE"). [Figure 7] This figure shows one embodiment of a configured uplink grant configuration consisting of two periodicities. [Figure 8A] This figure shows one embodiment of the ASN.1 configuration of ConfiguredGrantConfig IE. [Figure 8B] This is a continuation of the ConfiguredGrantConfig IE diagram shown in Figure 8A. [Figure 9] This is a block diagram showing one embodiment of a user device that may be used for an SDT procedure that uses CG resources. [Figure 10] This is a block diagram showing one embodiment of a network device that may be used for an SDT procedure that uses CG resources. [Figure 11] This flowchart illustrates one embodiment of a first method for an SDT procedure using CG resources. [Modes for carrying out the invention]

[0008] As will be understood by those skilled in the art, embodiments of the models may be embodied as systems, apparatus, methods, or program products. Accordingly, embodiments may take the form of all hardware embodiments, all software embodiments (including firmware, resident software, microcode, etc.), or embodiments that combine software and hardware embodiments.

[0009] For example, the disclosed embodiments may be implemented as hardware circuits including custom very large-scale integrated circuits ("VLSI") or off-the-shelf semiconductors, transistors, or other discrete components such as gate arrays, logic chips, etc. The disclosed embodiments may also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, or programmable logic devices. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may be organized as objects, procedures, or functions, for example.

[0010] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereafter referred to as code. The storage device may be tangible, non-transient, and / or non-transmitting. The storage device may not embody signals. In certain embodiments, the storage device employs only signals for accessing the code.

[0011] Any combination of one or more computer-readable media may be used. The computer-readable media may be computer-readable storage media. The computer-readable storage media may be a storage device that stores code. The storage device may be, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination thereof.

[0012] More specific examples of storage devices (a non-exclusive list) include, namely, electrical connections having one or more wires, portable computer diskettes, hard disks, random access memory ("RAM"), read-only memory ("ROM"), erasable programmable read-only memory ("EPROM") or flash memory, portable compact disk read-only memory ("CD-ROM"), optical storage devices, magnetic storage devices, or any suitable combination thereof. In the context of this specification, computer-readable storage media may be any tangible medium that contains or can store programs for use by or in connection with an instruction execution system, apparatus, or device.

[0013] The code for performing the operation of the embodiment may consist of any number of lines and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, and C++, conventional procedural programming languages ​​such as the C programming language, and / or machine language such as assembly language. The code may run entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the last scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network ("LAN"), a wireless LAN ("WLAN"), or a wide area network ("WAN"), or the connection to the external computer may be made (for example, via the Internet using an Internet Service Provider ("ISP").

[0014] Furthermore, the features, structures, or characteristics described in the embodiments may be combined in any suitable manner. In the following description, numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, and hardware chips, are provided to allow for a full understanding of the embodiments. However, those skilled in the art will acknowledge that embodiments may be carried out without one or more of these specific details, or using other methods, components, materials, etc. In other cases, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring the aspects of the embodiments.

[0015] Throughout this specification, any reference to “one embodiment,” “an embodiment,” or similar wording means that a particular feature, structure, or characteristic described in relation to an embodiment is included in at least one embodiment. Thus, throughout this specification, any occurrence of the phrase “in one embodiment,” “in an embodiment,” and similar wording may, but not necessarily, refer to the same embodiment and may mean “one or more, but not all, embodiments” unless otherwise specified. The terms “including,” “comprising,” “having,” and their variations mean “including, but not limited to,” unless otherwise specified. An enumerated list of items does not imply that any or all of the items are mutually exclusive unless otherwise specified. Also, the terms “a,” “an,” and “the” mean “one or more” unless otherwise specified.

[0016] As used herein, a list using the conjunction "and / or" includes any single item in the list or any combination of items in the list. For example, the list A, B, and / or C includes A only, B only, C only, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one or more of" includes any single item in the list or any combination of items in the list. For example, one or more of A, B, and C includes A only, B only, C only, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one of" includes just one of any single items in the list. For example, “one of A, B, and C” includes A only, B only, or C only, and excludes combinations of A, B, and C. When used herein, “at least one of A, B, and C” includes A only, B only, C only, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. When used herein, “a member selected from the group consisting of A, B, and C” includes just one of A, B, or C, and excludes combinations of A, B, and C. When used herein, “a member selected from the group consisting of A, B, and C and combinations thereof” includes A only, B only, C only, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C.

[0017] Aspects of the embodiments will be described below with reference to schematic flow diagrams and / or schematic block diagrams of methods, apparatuses, systems, and program products according to the embodiments. It will be understood that each block of the schematic flow diagrams and / or schematic block diagrams, and combinations of blocks in the schematic flow diagrams and / or schematic block diagrams, can be implemented by code. This code generates a machine such that the instructions executed by a processor of a computer or other programmable data processing device produce means for implementing the functions / acts specified in the flow diagram and / or block diagram, and may be provided to the processor of a general purpose computer, a dedicated computer, or other programmable data processing device to generate the machine.

[0018] The code may be stored in a storage device that can direct a computer, other programmable data processing device, or other device to function in a particular manner so as to produce a product that includes instructions stored in the storage device that perform the functions / acts specified in the flow diagram and / or block diagram.

[0019] The code may be loaded onto a computer, other programmable data processing device, or other device to cause the computer, other programmable device, or other device to execute a series of operational steps to produce a process implemented by the computer so as to provide a process for implementing the functions / acts specified in the flow diagram and / or block diagram by the code executed in the computer or other programmable device.

[0020] The call-flow diagrams, flowcharts, and / or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, systems, methods, and program products in various embodiments. In this regard, each block in the flowcharts and / or block diagrams may represent a module, segment, or portion of code containing one or more executable instructions of code for implementing a defined logical function.

[0021] It should also be noted that in some alternative implementations, the functions shown in the blocks may be performed in a different order than that shown in the diagram. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or blocks may be executed in reverse order depending on the function they relate to. Other steps and methods may be devised that are equivalent in function, logic, or effect to one or more blocks or parts of the diagram shown.

[0022] Various types of arrows and lines may be used in call flow diagrams, flowcharts, and / or block diagrams, but they are understood not to limit the scope of the corresponding embodiment. In fact, some arrows or other connectors may be used only to indicate the logical flow of the shown embodiment. For example, an arrow may indicate a waiting or monitoring period of an unspecified duration between enumerated steps of the shown embodiment. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be implemented by a system based on dedicated hardware that performs a defined function or action, or by a combination of dedicated hardware and code.

[0023] The descriptions of elements in each figure may refer to elements in the procedure diagrams. Similar numbers refer to the same element in all figures, including alternative embodiments of the same element.

[0024] In general, this disclosure describes systems, methods, and apparatus for configuring a user device ("UE") using CG-SDT resources (i.e., CG resources for SDT procedures). In certain embodiments, the method may be performed using computer code embedded in a computer-readable medium. In certain embodiments, the apparatus or system may include a computer-readable medium containing computer-readable code that, when executed by a processor, causes the apparatus or system to perform at least a portion of the solutions described below.

[0025] As mentioned above, NR supports the RRC_INACTIVE state, and UEs with infrequent (periodic and / or aperiodic) data transmissions are generally kept in the RRC_INACTIVE state by the network. However, so far, the RRC_INACTIVE state does not support data transmission. Therefore, the UE must reopen the connection (i.e., transition to the RRC_CONNECTED state) for all downlink ("DL") (e.g., mobile termination) and uplink ("UL") (e.g., mobile outbound) data. If small data transmissions are not supported in the RRC_INACTIVE state, the UE is required to set up an RRC connection (i.e., transition to the RRC_CONNECTED state) for each data transmission, regardless of how small and infrequent the data packets are, and then be released back into the RRC_INACTIVE state. This results in unnecessary power consumption and signaling overhead.

[0026] In various embodiments, small data transmissions ("SDT") are supported while the UE is in the RRC_INACTIVE state. In some embodiments, the UL small data transmission is achieved using RACH-based methods (i.e., 2-step and 4-step random access procedures). In one embodiment, user plane ("UP") data transmission of a small data packet from the RRC_INACTIVE state is performed using, for example, MsgA (i.e., for the 2-step random access procedure) or Msg3 (i.e., for the 4-step random access procedure).

[0027] Random Access Channel ("RACH") messaging may be modified to allow for a more flexible payload size than the currently possible Rel-16 Common Control Channel ("CCCH") message size for MsgA and Msg3 in the RRC_INACTIVE state, in order to support user plane data transmission in UL (the actual payload size may depend on the network configuration). In one embodiment, context fetching and data transfer (with and without anchor relocation) may occur in the RRC_INACTIVE state for a RACH-based solution.

[0028] In some embodiments, when uplink timing alignment ("TA") is enabled, transmission of UL data over a pre-configured physical uplink shared channel ("PUSCH") resource is supported (i.e., reusing a configured grant ("CG") type 1). In one embodiment, small data transmission is performed over a CG type 1 resource from the RRC_INACTIVE state. The UE may be configured using a CG type 1 resource for small data transmission in UL for the RRC_INACTIVE state.

[0029] This disclosure addresses the following issues with small data transmission when the UE is in the RRC_INACTIVE state.

[0030] For CG-SDT operation, the gNB allocates CG-SDT resources within the RRCRelease message according to the SDT bearer's traffic pattern. So far, the CG-SDT resource configuration only allocates CG PUSCH for the initial SDT transmission. However, it should also be possible to transmit subsequent UL SDT data within the SDT session on the CG-SDT resource. Furthermore, the UE should only be allowed to transmit subsequent UL SDT data when the receipt of the initial SDT message (i.e., the SDT transport block ("TB")) has been acknowledged by the gNB.

[0031] This specification describes a solution for supporting small data transmissions ("SDT") in the RRC_INACTIVE state using CG-SDT resources. In various embodiments, the network configures CG-SDT resources by using a configured grant configuration consisting of two periodics. When the UE is in the RRC_INACTIVE state and before initiating an SDT session / procedure, it considers only the first periodicity—as in legacy—to determine the CG-SDT resources, i.e., the CG-SDT resource is used only for the first SDT message. Once the SDT procedure is initiated, in response to the transmission of the first / initial SDT TB on the CG-SDT resource, the UE activates further CG-SDT resources according to the second configured periodicity. On subsequent CG-SDT resources, the UE performs a retransmission of the initial SDT TB or any further subsequent SDT UL data / TB transmissions.

[0032] By configuring multiple periodicities, the network does not need to configure multiple CG-SDT configurations on the UE to allocate multiple CG-PUSCH resources within a CG period, for example, CG-PUSCH resources for the initial SDT message and for subsequent UL SDT data transmissions. This is beneficial because multiple CG-SDT configurations come at the cost of increased signaling overhead.

[0033] In some embodiments, the UE skips sending generated TBs on an allocated uplink resource, e.g., a CG-SDT resource, when the transmission of TBs on a first CG-SDT resource of an SDT session has not been acknowledged by the gNB. In one particular implementation, the first uplink transmission on a first CG-SDT resource of an SDT session consists of at least CCCH data, e.g., an RRCResumeRequest message. TBs that the UE skips due to a lack of acknowledgment from the gNB for the initial CG-SDT transmission are held in a Hybrid Auto Retransmission Request ("HARQ") buffer and are autonomously retransmitted by the UE once acknowledgment is received from the gNB (i.e., the 5G base station).

[0034] In some embodiments, the CG-SDT resource configuration is a Type 1 configured grant configuration, but with one additional periodicity within the CG-SDT configuration. The UE considers the first periodicity to determine the CG-SDT resources when in the RRC_INACTIVE state and before initiating an SDT session / procedure, i.e., the CG-SDT resources are used only for the first SDT message. Once the SDT procedure is initiated, in response to the transmission of the first / initial SDT TB on the CG-SDT resources, the UE activates further CG-SDT resources according to the second configured periodicity.

[0035] Figure 1 shows a wireless communication system 100 for an SDT procedure using CG resources according to an embodiment of the present disclosure. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a radio access network ("RAN") 120, and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communication network. The RAN 120 may consist of a base unit 121 with which the remote unit 105 communicates using a wireless communication link 123. Although a specific number of remote units 105, base unit 121, wireless communication link 123, RAN 120, and mobile core network 140 are shown in Figure 1, a person skilled in the art will recognize that any number of remote units 105, base unit 121, wireless communication link 123, RAN 120, and mobile core network 140 may be included in the wireless communication system 100.

[0036] In one implementation, RAN 120 conforms to a 5G cellular system as defined by 3GPP® specifications. For example, RAN 120 may be a next-generation radio access network ("NG-RAN") implementing NR radio access technology ("RAT") and / or Long-Term Evolution ("LTE") RAT. In another example, RAN 120 may include a non-3GPP RAT (e.g., Wi-Fi® or a WLAN compliant with the IEEE 802.11 family). In yet another implementation, RAN 120 conforms to an LTE system as defined by 3GPP® specifications. However, more broadly, the wireless communication system 100 may implement any other open or proprietary communication network, among other things, such as Worldwide Interoperability for Microwave Access ("WiMAX") or standards of the IEEE 802.16 family. This disclosure is not intended to be limited to any specific wireless communication system architecture or protocol implementation.

[0037] In one embodiment, the remote unit 105 may include computing devices such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smartphones, smart televisions (e.g., Internet-connected televisions), smart home appliances (e.g., Internet-connected home appliances), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, and network devices (e.g., routers, switches, modems). In some embodiments, the remote unit 105 includes wearable devices such as smartwatches, fitness bands, and optical head-mounted displays. Furthermore, the remote unit 105 may be referred to as a UE, subscriber unit, mobile phone, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transmit / receive unit ("WTRU"), device, or other terms used in the art. In various embodiments, the remote unit 105 includes a subscriber identity and / or identification module ("SIM") and a mobile device ("ME") that provides mobile termination functions (e.g., radio transmission, handover, voice coding and decoding, error detection and correction, signaling, and access to the SIM). In certain embodiments, the remote unit 105 may include a terminal device ("TE") and / or be incorporated into a consumer electronics or device (e.g., the computing device described above).

[0038] The remote unit 105 may communicate directly with one or more base units 121 in the RAN 120 by UL and DL communication signals. Furthermore, the UL and DL communication signals may be carried over the wireless communication link 123. In addition, the UL communication signals may include one or more uplink channels such as the physical uplink control channel ("PUCCH") and / or PUSCH, while the DL communication signals may include one or more DL channels such as the physical downlink control channel ("PDCCH") and / or the physical downlink sharing channel ("PDSCH"). Here, the RAN 120 is an intermediate network that provides the remote unit 105 with access to the mobile core network 140.

[0039] In various embodiments, the remote units 105 may communicate directly with each other using sidelink communication (e.g., device-to-device communication) (not shown in Figure 1). Here, sidelink transmission may take place over sidelink resources. The remote units 105 may be provided with different sidelink communication resources according to different allocation modes. As used herein, “resource pool” refers to a set of resources allocated for sidelink operation. The resource pool consists of a set of resource blocks (i.e., physical resource blocks ("PRBs")) on one or more time units (e.g., orthogonal frequency division multiplexing ("OFDM") symbols, subframes, slots, subslots, etc.). In some embodiments, the set of resource blocks includes a contiguous PRB in the frequency domain. As used herein, a PRB consists of 12 contiguous subcarriers in the frequency domain.

[0040] In some embodiments, the remote unit 105 communicates with the application server 151 via a network connection to the mobile core network 140. For example, an application 107 within the remote unit 105 (e.g., a web browser, media client, telephone, and / or Voice over Internet Protocol ("VoIP") application) may trigger the remote unit 105 to establish a Protocol Data Unit ("PDU") session (or Packet Data Network ("PDN") connection) with the mobile core network 140 via the RAN 120. The PDU session represents a logical connection between the remote unit 105 and the User Plane Function ("UPF") 141. The mobile core network 140 then uses the PDU session (or other data connection) to relay traffic between the remote unit 105 and the application server 151 in the Packet Data Network 150.

[0041] To establish a PDU session (or PDN connection), the remote unit 105 must register with the mobile core network 140 (also referred to as "attaching to the mobile core network" in the context of fourth-generation ("4G") systems). Note that the remote unit 105 may establish one or more PDU sessions (or other data connections) with the mobile core network 140. Thus, the remote unit 105 may have at least one PDU session for communicating with the packet data network 150. The remote unit 105 may establish additional PDU sessions for communicating with other data networks and / or other communication peers.

[0042] In the context of a 5G system ("5GS"), the term "PDU session" refers to a data connection that provides end-to-end ("E2E") user plane ("UP") connectivity between a remote unit 105 and a specific data network ("DN") via UPF 141. A PDU session supports one or more quality of service ("QoS") flows. In certain embodiments, a one-to-one mapping may exist between QoS flows and QoS profiles such that all packets belonging to a particular QoS flow have the same 5G QoS identifier ("5QI").

[0043] In the context of 4G / LTE systems such as Evolved Packet Systems ("EPS"), a PDN connection (also called an EPS session) provides an E2E UP connection between a remote unit and the PDN. The PDN connection procedure establishes a tunnel between the EPS bearer, i.e., the remote unit 105, and the PDN gateway ("PGW", not shown in Figure 1) in the mobile core network 140. In certain embodiments, a one-to-one mapping exists between the EPS bearer and the QoS profile such that all packets belonging to a particular EPS bearer have the same QoS class identifier ("QCI").

[0044] The base units 121 may be geographically distributed. In certain embodiments, the base units 121 may also be referred to as access terminals, access points, bases, base stations, node B ("NB"), evolved node B (abbreviated as eNodeB or "eNB," also known as Evolved Universal Terrestrial Radio Access Network ("E-UTRAN") node B), 5G / NR node B ("gNB"), home node B, relay node, RAN node, or any other term used in the art. The base units 121 are generally part of a RAN, such as RAN 120, which may include one or more controllers coupled to one or more corresponding base units 121 for communication. These and other elements of the radio access network are not shown but are generally well known to those skilled in the art. The base units 121 connect to the mobile core network 140 via RAN 120.

[0045] The base unit 121 may serve a number of remote units 105 within a serving area, for example, a cell or a sector of a cell, via a wireless communication link 123. The base unit 121 may communicate directly with one or more of the remote units 105 by communication signals. Generally, the base unit 121 transmits DL communication signals to serve the remote units 105 in the time, frequency, and / or spatial domains. Furthermore, the DL communication signals may be carried over the wireless communication link 123. The wireless communication link 123 may be any suitable carrier of the radio spectrum, whether licensed or unlicensed. The wireless communication link 123 facilitates communication between one or more of the remote units 105 and / or one or more of the base units 121.

[0046] Note that during NR operation on an unlicensed spectrum (referred to as "NR-U"), the base unit 121 and the remote unit 105 communicate over an unlicensed (i.e., shared) radio spectrum. Similarly, during LTE operation on an unlicensed spectrum (referred to as "LTE-U"), the base unit 121 and the remote unit 105 also communicate over an unlicensed (i.e., shared) radio spectrum.

[0047] In one embodiment, the mobile core network 140 is a 5G core network ("5GC") or evolved packet core ("EPC") which may be coupled to a packet data network 150, such as the Internet and a private data network, among other data networks. The remote unit 105 may be subscribed to or otherwise accounted for by the mobile core network 140. In various embodiments, each mobile core network 140 belongs to a single mobile network operator ("MNO") and / or a public land mobile network ("PLMN"). This disclosure is not intended to be limited to any particular wireless communication system architecture or protocol implementation.

[0048] The mobile core network 140 includes several network functions ("NF"). As shown, the mobile core network 140 includes at least one UPF 141. The mobile core network 140 also includes several control plane ("CP") functions, including but not limited to an Access and Mobility Management Function ("AMF") 143, a Session Management Function ("SMF") 145, a Policy Control Function ("PCF") 147, a Unified Data Management Function ("UDM"), and a User Data Repository ("UDR"), which serve the RAN 120. In some embodiments, the UDM is located in the same place as the UDR and is shown as a combined entity "UDM / UDR" 149. While certain numbers and types of network functions are shown in Figure 1, those skilled in the art will acknowledge that any number and types of network functions may be included in the mobile core network 140.

[0049] UPF 141 is responsible for routing and forwarding packets for interconnecting data networks ("DNs") in a 5G architecture, packet inspection, QoS processing, and external PDU sessions. AMF 143 is responsible for terminating non-access layer ("NAS") signaling, NAS encryption and integrity protection, registration management, connectivity management, mobility management, access authentication and authorization, and security context management. SMF 145 is responsible for session management (i.e., session establishment, modification, and release), allocation and management of Internet Protocol ("IP") addresses for remote units (i.e., UEs), DL data notification, and traffic steering configuration for UPF 141 for proper traffic routing.

[0050] PCF 147 is responsible for a unified policy framework, providing policy rules to CP functions, and access / subscribe information for policy decisions in the UDR. The UDM is responsible for generating Authentication and Key Agreement (AKA) credentials, user identification, access authorization, and subscriber management. The UDR is a repository of subscriber information and may be used to serve many network functions. For example, the UDR may store subscriber data, policy-related data, and subscriber-related data that is permitted to be exposed to third-party applications.

[0051] In various embodiments, the mobile core network 140 may also include a Network Repository Function ("NRF") (which provides registration and discovery of Network Function ("NF") services, enabling NFs to identify appropriate services from one another and communicate with each other via Application Programming Interfaces ("APIs")), a Network Exposure Function ("NEF") (which is responsible for ensuring that network data and resources are readily accessible to customers and network partners), an Authentication Server Function ("AUSF"), or other NFs defined for 5GC. Where present, the AUSF may act as an Authentication Server and / or Authentication Proxy, thereby enabling the AMF 143 to authenticate the remote unit 105. In certain embodiments, the mobile core network 140 may also include an Authentication, Authorization, and Accounting ("AAA") server.

[0052] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, with each mobile data connection utilizing a specific network slice. Here, “network slice” refers to a portion of the mobile core network 140 optimized for a particular type of traffic or communication service. For example, one or more network slices may be optimized for enhanced mobile broadband (eMBB) services. Another example is that one or more network slices may be optimized for ultra-high reliability low latency (URLLC) services. In other examples, network slices may be optimized for machine-type communication (MTC) services, massive MTC (mMTC) services, or Internet of Things (IoT) services. In yet another example, network slices may be deployed for specific application services, vertical services, or specific use cases.

[0053] Network slice instances are identified by single network slice selection support information ("S-NSSAI"), while the set of network slices authorized for use by the remote unit 105 is identified by network slice selection support information ("NSSAI"). Here, "NSSAI" refers to a vector value containing one or more S-NSSAI values. In certain embodiments, various network slices may contain separate instances of network functions such as SMF 145 and UPF 141. In some embodiments, different network slices may share some common network functions such as AMF 143. For simplicity of illustration, different network slices are not shown in Figure 1, but their support is assumed.

[0054] To facilitate SDT procedures using CG resources, the base unit 121 may transmit an SDT configuration to the remote unit 105, which uses the SDT configuration to determine, for example, whether to transmit small data in RRC_INACTVE using CG resources for SDT ("CG-SDT") 125, or to transition to the RRC_CONNECTED state to perform uplink data transmission.

[0055] Figure 1 shows the components of the 5G RAN and 5G core network, but the embodiments described for SDT procedures using CG resources apply to variants of IEEE 802.11, the Global System for Mobile Communications ("GSM," i.e., 2G digital cellular networks), General Purpose Packet Radio Services ("GPRS"), Universal Mobile Communications System ("UMTS"), variants of LTE, CDMA2000, Bluetooth, ZigBee, Sigfox, and other types of communication networks and RATs.

[0056] Furthermore, in an LTE variant where the mobile core network 140 is the EPC, the network functions shown may be replaced by appropriate EPC entities such as a Mobility Management Entity ("MME"), Serving Gateway ("SGW"), PGW, and Home Subscriber Server ("HSS"). For example, the AMF 143 may be mapped to the MME, the SMF 145 to the control plane portion of the PGW and / or the MME, the UPF 141 to the user plane portions of the SGW and PGW, and the UDM / UDR 149 to the HSS.

[0057] In the following description, the term “RAN node” is used for base station / base unit, but it may be replaced by any other radio access node, such as gNB, ng-eNB, eNB, base station ("BS"), base station unit, access point ("AP"), NR BS, 5G NB, transmission and reception point ("TRP"), etc. Furthermore, the term “UE” is used for mobile station / remote unit, but it may be replaced by any other remote device, such as remote unit, MS, ME, etc. In addition, the operation is described primarily in the context of 5G NR. However, the solutions / methods described below are equally applicable to other mobile communication systems for SDT procedures using CG resources.

[0058] Figure 2 shows an NR protocol stack 200 according to an embodiment of the present disclosure. Figure 2 shows a UE 205, a RAN node 210, and an AMF 215 in the 5G core network ("5GC"), which represent a set of remote units 105 that interact with the base unit 121 and the mobile core network 140. As shown, the NR protocol stack 200 includes a user plane protocol stack 201 and a control plane protocol stack 203. The user plane protocol stack 201 includes a physical ("PHY") layer 220, a medium access control ("MAC") sublayer 225, a radio link control ("RLC") sublayer 230, a packet data convergence protocol ("PDCP") sublayer 235, and a service data adaptation protocol ("SDAP") sublayer 240. The control plane protocol stack 203 includes the PHY layer 220, MAC sublayer 225, RLC sublayer 230, and PDCP sublayer 235. The control plane protocol stack 203 also includes the RRC layer 245 and the NAS layer 250.

[0059] The Access Layer ("AS") layer 255 (also known as the "AS protocol stack") of the user plane protocol stack 201 consists of at least the SDAP, PDCP, RLC, and MAC sublayers, as well as the physical layer. The AS layer 260 of the control plane protocol stack 203 consists of at least the RRC, PDCP, RLC, MAC sublayer, and the physical layer. Layer 2 ("L2") is divided into the SDAP, PDCP, RLC, and MAC sublayers. Layer 3 ("L3") includes the RRC layer 245 and NAS layer 250 of the control plane, and also includes, for example, the IP layer and / or PDU layer (not shown) of the user plane. L1 and L2 are referred to as "lower layers," while L3 and above (e.g., transport layer, application layer) are referred to as "higher layers" or "upper layers."

[0060] The PHY layer 220 provides a transport channel to the MAC sublayer 225. The PHY layer 220 may perform beam fault detection procedures using an energy detection threshold. In certain embodiments, the PHY layer 220 may transmit beam fault indications to the MAC entity of the MAC sublayer 225. The MAC sublayer 225 provides a logical channel to the RLC sublayer 230. The RLC sublayer 230 provides an RLC channel to the PDCP sublayer 235. The PDCP sublayer 235 provides radio bearers to the SDAP sublayer 240 and / or the RRC layer 245. The SDAP sublayer 240 provides QoS flows to the core network (e.g., 5GC). The RRC layer 245 provides functions for adding, modifying, and releasing carrier aggregation and / or dual connectivity. The RRC layer 245 also manages the establishment, configuration, maintenance, and release of signaling radio bearers ("SRBs") and data radio bearers ("DRBs").

[0061] The NAS layer 250 is located between the UE 205 and the AMF 215 within the 5GC. NAS messages are passed transparently through the RAN. The NAS layer 250 manages the establishment of communication sessions and is used to maintain continuous communication with the UE 205 as it moves between different cells in the RAN. In contrast, the AS layers 255 and 260 are located between the UE 205 and the RAN (i.e., the RAN node 210) and carry information through the wireless portion of the network. Although not shown in Figure 2, the IP layer is located above the NAS layer 250, the transport layer is located above the IP layer, and the application layer is located above the transport layer.

[0062] MAC sublayer 225 is the lowest sublayer in the L2 architecture of the NR protocol stack. MAC sublayer 225 is connected to the PHY layer 220 below via the transport channel, and to the RLC sublayer 230 above via the logical channel. Thus, MAC sublayer 225 performs multiplexing and multiplexing / demultiplexing between the logical channel and the transport channel; that is, the transmitting MAC sublayer 225 constructs a MAC PDU (also known as a transport block ("TB")) from MAC service data units ("SDU") received via the logical channel, and the receiving MAC sublayer 225 recovers a MAC SDU from a MAC PDU received via the transport channel.

[0063] The MAC sublayer 225 provides data transfer services for the RLC sublayer 230 via a logical channel that is either a control logic channel carrying control data (e.g., RRC signaling) or a traffic logic channel carrying user plane data. Meanwhile, data from the MAC sublayer 225 is exchanged with the PHY layer 220 via transport channels classified as UL or DL. The data is multiplexed onto the transport channels depending on how it is transmitted wirelessly in the air.

[0064] PHY layer 220 is responsible for the actual transmission of data and control information over the radio interface; that is, PHY layer 220 carries all information from the MAC transport channel over the transmitting radio interface. Some of the key functions performed by PHY layer 220 include coding and modulation, link adaptation (e.g., Adaptive Modulation and Coding ("AMC")), power control, cell discovery and random access (for initial synchronization and handover), and other measurements (within and between 3GPP® systems (i.e., NR and / or LTE systems)) for RRC layer 245. PHY layer 220 performs transmission based on transmission parameters such as modulation scheme, coding rate (i.e., Modulation Coding Scheme ("MCS")), and PRB count.

[0065] With respect to RACH-based and CG-based SDTs, when UE 205 receives an RRC release with a Suspend configuration, UE 205 performs at least the following actions: • MAC is reset, and the default MAC cell group configuration is released. • The RLC entity for Signaling Radio Bearer #1 ("SRB1") is re-established. • SRB and DRB are suspended except for signaling radio bearer #0 ("SRB0").

[0066] With respect to both RACH-based and CG-based SDTs, when the RESUME procedure is initiated for the start of an SDT (i.e., for the first / initial SDT transmission), UE 205 re-establishes at least the SDT PDCP entity and restarts the SDT DRB configured for small data transmissions (along with SRB1).

[0067] The first UL message (i.e., MSG3 for 4-step RACH, MSGA payload for 2-step RACH, and CG transmission for CG) may contain at least the following (depending on the size of the message): • CCCH message (required) • DRB data (optional) from one or more DRBs configured by the network for small data transmission. • MAC control element ("CE") -- (e.g., Buffer Status Report ("BSR")) (Optional) • Padding bit (optional)

[0068] Logical Channel Prioritization (LCP) may be used to determine the priority of the above contents that may be included.

[0069] With respect to RACH and CG, existing Unified Access Control (UAC) procedures for determining whether an access attempt is permitted are reused for SDT.

[0070] SDT is transparent to the NAS layer (i.e., the NAS generates one of the existing resume causes, and the AS layer determines whether access is SDT or not).

[0071] In the case of RRC-based solutions, with respect to both RACH-based and CG-based SDTs, the CCCH message includes a Message Authentication Code - Integrity for Resume ("resumeMAC-I") generated using a stored security key for RRC integrity protection—i.e., the same as Rel-16.

[0072] For both RACH-based and CG-based SDTs, a new key is generated using the stored security context and the Next Hop Chaining Counter (NCC) value received in the previous RRCRelease message. These new keys are then used to generate the DRB data configured for the SDT.

[0073] With respect to SDT based on RACH, once contention resolution is successfully completed, the UE 205 monitors the Cell-specific Radio Network Temporary Identifier ("C-RNTI"). In one embodiment, the coreset / search space for the C-RNTI is a common (i.e., shared) coreset / search space. In another embodiment, the coreset / search space for the C-RNTI is a dedicated coreset / search space.

[0074] As a baseline, the RACH resource, i.e., the combination of Random Access Occasion ("RO") + preamble, differs between SDT and non-SDT. If the Random Access Occasion ("RO") differs between SDT and non-SDT, preamble differentiation between SDT and non-SDT is not required. However, if the ROs of SDT and non-SDT are the same, preamble differentiation is required.

[0075] Note that if the RACH resource, i.e., the combination of RO + preamble, differs between SDT and non-SDT, there is no further need for any distinction between Msg2 / MsgB for SDT versus non-SDT.

[0076] The configuration of the configured grant resources for UE 205 uplink small data transfers is included in the RRCRelease message. The configuration may only be for type 1 CG without a contention resolution procedure for CG.

[0077] The configuration of a configured grant resource may include one Type 1 CG configuration. In some embodiments, multiple configured CGs are allowed.

[0078] A new TA timer should be introduced for TA maintenance specified for small data transfers based on configured grants in RRC_INACTIVE. The TA timer is configured together with the CG configuration within the RRCRelease message.

[0079] The configuration of a pre-configured grant resource for sending small data on UE 205 is only valid within the same serving cell.

[0080] UE 205 can use small data transfers based on configured grants if at least the following criteria are met: (1) user data is smaller than the data volume threshold, (2) configured grant resources are configured and enabled, and (3) UE 205 has an enabled TA.

[0081] A threshold for the synchronous signal reference signal received power (SS-RSRP) is configured for the selection of synchronous signal blocks (SSBs). The UE 205 selects one of the SSBs with an SS-RSRP exceeding the threshold and selects the associated CG resource for UL data transmission. In certain embodiments, an association between the CG resource and the SSB is required for CG-based SDT.

[0082] The CG configuration mechanism for Rel-16 in the licensed bandwidth will be reused as the baseline for CG-SDT. At least for the initial transmission, we will have a mechanism to allow UE 205 to retransmit the message. UE 205 will use / select the same HARQ process for retransmission.

[0083] The "CG-SDT timer" starts at the end of a CG-SDT PUSCH transmission and during the first "valid" PDCCH opportunity. The "CG-SDT timer" can be started / restarted during the initial transmission and subsequent transmissions.

[0084] UE 205 restarts the "CG-SDT Timer" at least when PUSCH retransmits indicated by the Configured Scheduling Radio Network Temporary Identifier ("CS-RNTI") PDCCH, and / or after each CG-SDT transmission. The "CG-SDT Timer" stops at least when UE 205 receives an RRC feedback message (e.g., RRCResume, RRCSetup, RRCRelease, and RRCReject). Note that Rel-16 calculations for CG Type 1 HARQ process identifiers ("ID") for licensed bands may be reused as a baseline for CG-SDTs.

[0085] UE 205 may only initiate subsequent UL data transmissions after receiving confirmation of the initial transmission from RAN node 210. In the subsequent CG transmission phase, UE 205 may use multiple CG resources for the initial HARQ transmission, similar to Rel-16.

[0086] The following CG-SDT configurations, namely the new TA timer in RRC_INACTIVE, the threshold for the change in reference signal received power ("RSRP") for the TA verification mechanism in SDT, and the threshold for the SSB RSRP for beam selection, are per UE.

[0087] Figure 3 shows an exemplary RRC restart procedure 300. Procedure 300 involves UE 205 (e.g., an instance of remote unit 105), RAN node 210 (e.g., an instance of base unit 121), and UPF 305 (e.g., an instance of UPF 141). At the beginning of procedure 300, UE 205 is in the RRC_INACTIVE state (see block 310). Note that the RRC state of UE 205 is known to both UE 205 and RAN node 210.

[0088] In step 1, UE 205 sends an RRCResumeRequest message to RAN node 210 (see messaging 315). As shown, the RRCResumeRequest includes the Inactive Radio Network Temporary Identifier ("I-RNTI"), resumeMAC-I, and resumeCause.

[0089] In step 2, RAN node 210 sends an RRCResume message to UE 205 (see messaging 320). UE 205 transitions to the RRC_CONNECTED state in response to the RRCResume message (see block 325).

[0090] In step 3, UE 205 sends an RRCResumeComplete message to RAN node 210 in response to the transition to the RRC_CONNECTED state (see messaging 330). Optionally, UE 205 sends one or more messages containing UL data (see messaging 335).

[0091] In step 4, the RAN node 210 sends an RRCReconfiguration message to the UE 205 (see messaging 340). In some embodiments, the RRCReconfiguration message releases the radio bearer used to transfer the UL data.

[0092] In step 5, UE 205 sends an RRCReconfigutationComplete message to RAN node 210 (see messaging 345). Note that RAN node 210 forwards the UL data to UPF 305 (see messaging 350).

[0093] In step 6, the RAN node 210 sends an RRCRelease message to the UE 205, for example, with a SuspendConfig IE (see messaging 355). In some embodiments, the RRCRelease message includes configuration regarding configured uplink grants (i.e., CG resources). The UE 205 transitions to the RRC_INACTIVE state in response to the RRCRelease message (see block 360).

[0094] As mentioned above, the current 3GPP® specification requires that, regardless of how small or infrequent the data packets are, each data transmission must involve setting up the connection and subsequently releasing it to the RRC_INACTIVE state.

[0095] Figure 4A shows an exemplary Small Data Transmission ("SDT") procedure 400 for UE 205 in the RRC_INACTIVE state. Procedure 400 involves UE 205 (e.g., an instance of remote unit 105), RAN node 210 (e.g., an instance of base unit 121), and UPF 305 (e.g., an instance of UPF 141). At the beginning of procedure 400, UE 205 is in the RRC_INACTIVE state. The shown procedure 400 is based on random access ("RA") resources (i.e., on a random access channel ("RACH")) and / or configured grant ("CG") resources.

[0096] In step 0, UE 205 decides to use a RACH or CG resource for sending small data in RRC_INACTIVE (see block 405). In step 1, UE 205 sends an RRCResumeRequest with UL data (and NCC value) to RAN node 210 while in the RRC_INACTIVE state (see messaging 410). As shown, the RRCResumeRequest includes RNTI, resumeMAC-I, and resumeCause.

[0097] In step 2, RAN node 210 forwards the UL data to 5GC (i.e., UPF 305) (see messaging 415). In any step 3, UPF 305 sends DL data for UE 205 to RAN node 210 (see messaging 420).

[0098] In step 4, RAN node 210 sends an RRCRelease message to UE 205 (see messaging 425). As shown, the RRCRelease message includes I-RNTI and the new NCC value. If UPF has DL data for UE 205 (or if DL data for UE 205 is buffered at RAN node 210), the RRCRelease message includes the DL data.

[0099] Figure 4B shows another exemplary Small Data Transmission ("SDT") procedure 430 for UE 205 in the RRC_INACTIVE state. The procedure shown is based on a Random Access Channel ("RACH") resource configured for the SDT. Procedure 430 involves UE 205 (for example, an instance of remote unit 105) and RAN node 210 (for example, an instance of base unit 121). At the beginning of procedure 430, UE 205 is in the RRC_CONNECTED state (see block 435).

[0100] In step 1, RAN node 210 sends an RRCRelease message with a SuspendConfig IE (see messaging 440), and UE 205 transitions from the RRC_CONNECTED state to the RRC_INACTIVE state (see block 445). Here, the RRCRelease message with a SuspendConfig IE includes the SDT configuration (and NCC value).

[0101] Subsequently, UE 205 decides to use RACH-based SDT procedure 450 for sending small data in RRC_INACTIVE. In step 2, UE 205 sends an RA-SDT message (i.e., MsgA of the two-step random access ("RA") procedure) to RAN node 210 containing an RRCResumeRequest message with UL data (see messaging 455). Here, it is assumed that UE 205 has additional data to send.

[0102] In step 3, RAN node 210 responds to UE 205 with an RA-SDT message (i.e., MsgB for the two-step RA procedure) (see messaging 460). In step 4, UE 205 performs subsequent data transmissions using resources allocated by configured grants ("CG") and / or dynamic grants ("DG": dynamic grant) (see block 465). If the network has DL data for UE 205 (for example, if DL data for UE 205 is buffered at RAN node 210), “subsequent data transmission” in block 465 includes DL data transmission by RAN node 210.

[0103] In step 5, once the subsequent data transmission is complete, the RAN node 210 sends another RRCRelease message to the UE 205, which also contains the SDT configuration (and NCC value) for the RACH resource (see messaging 470). Upon receiving the RRCRelease message, the UE 205 transitions to the RRC_INACTIVE state (see block 475), and for example, the UE 205 remains in the RRC_INACTIVE state.

[0104] Figure 5 shows an exemplary procedure for selecting an SDT resource, namely, UE 205 determines, based on the data volume and RSRP value, whether to use CG-based SDT, RACH-based SDT, or no SDT.

[0105] As an initial decision, UE 205 determines whether to use the SDT procedure by comparing the amount of data to the data volume threshold and the measured RSRP to the SDT threshold (see block 505). The RSRP threshold is to ensure that a 4-step RACH-based procedure (corresponding to the lowest threshold) can be performed. If the amount of user data is less than the data volume threshold and the RSRP exceeds the SDT threshold, UE 205 can use the SDT procedure and proceeds to the selection of SDT resources. Otherwise, UE 205 decides to use the legacy restart procedure shown in Figure 3.

[0106] To select an SDT resource, UE 205 selects a carrier if configured by comparing the RSRP to the threshold for a normal (i.e., non-supplementary) uplink carrier ("NUL") (see block 510). If the RSRP is greater than the threshold for NUL, UE 205 selects NUL as the carrier for the SDT procedure (see block 515). Otherwise, if the RSRP is less than or equal to the threshold for NUL, UE 205 selects SUL as the carrier for the SDT procedure (see block 520).

[0107] If NUL is selected, UE 205 determines whether a CG-based procedure should be used by determining that the RSRP is sufficient for CG operation and whether UE 205 has a valid TA for CG (see block 525). If it should be used, UE 205 uses a CG-based SDT procedure for NUL, for example, as shown in Figure 4A. If it should not be used, UE 205 uses a RACH-based SDT procedure for NUL.

[0108] If a NUL-based RACH SDT procedure is selected, UE 205 determines whether a two-step RACH procedure should be used by comparing the RSRP to a two-step threshold (see block 530). If it should be used, UE 205 uses a NUL-based two-step RACH SDT procedure, for example, as shown in Figure 4B. If it should not be used, UE 205 uses a NUL-based four-step RACH SDT procedure (see block 535).

[0109] However, if SUL is selected, UE 205 determines whether a CG-based procedure should be used by determining that the RSRP is sufficient for CG operation and whether UE 205 has a valid TA for CG (see block 540). If it should be used, UE 205 uses the CG-based SDT procedure for SUL, for example, as shown in Figure 4A. If it should not be used, UE 205 uses the RACH-based SDT procedure for SUL.

[0110] If the UE 205 selects the RACH-based SDT procedure for SUL, it determines whether to use the two-step RACH procedure by comparing the RSRP with a two-step threshold (see block 545). If it should, the UE 205 uses the SDT procedure based on the two-step RACH for SUL, for example, as shown in Figure 4B. If it should not, the UE 205 uses the SDT procedure based on the four-step RACH for SUL (see block 550). Note that the UE 205 may have separate configurations for NUL and SUL, and therefore the thresholds used for CG and two-step determination of NUL may differ from the thresholds used for CG and two-step determination of SUL.

[0111] According to an embodiment of the first solution, UE 205 skips sending the generated TB on the assigned uplink resource, for example, the PUSCH resource, if it has not yet received confirmation that the previous uplink transmission was successfully received. In one implementation of the first solution, the assigned uplink resource is a configured uplink grant, i.e., CG-PUSCH. In a further implementation of the first solution, UE 205 skips sending the generated TB on the assigned uplink resource, for example, the CG-SDT resource, if the transmission of the TB on the first CG-SDT resource for the SDT session / procedure has not been confirmed by the RAN node 210.

[0112] In some embodiments, confirmation is performed by a HARQ Ack, an L2 Ack, or a new DL / UL allocation accompanied by a toggleable New Data Indicator ("NDI"). In one particular implementation, the first uplink transmission on the first CG-SDT resource of the SDT session consists of at least CCCH data, e.g., an RRCResumeRequest message.

[0113] According to the first solution, UE 205 is permitted to make subsequent UL data transmissions only when the first uplink transmission of the SDT session on the first CG-SDT resource is acknowledged / received by the RAN node 210 with a response message confirming receipt of the initial CG-SDT transmission, such as an RRCResumeRequest message.

[0114] According to one implementation of the first solution, a TB that UE 205 skips because there is no (or has not yet received) acknowledgment from RAN node 210 regarding the first CG-SDT transmission, e.g., the first UL transmission in the SDT session containing at least an RRCResumeRequest message, is left pending in the HARQ buffer and is autonomously resent by UE 205 once the acknowledgment is received from RAN node 210. The “skipping” or “suppression” of subsequent uplink data until the reception of acknowledgment regarding the first SDT transmission, e.g., RRCResumeRequest, is performed at UE 205 (e.g., at the MAC entity), similar to the case of a Listen-Before-Talk ("LBT") failure. The HARQ process may be set to “pending” in response to the skipping of a UL transmission of subsequent UL data due to the lack of acknowledgment of the initial SDT message / TB.

[0115] According to the second embodiment of the solution, UE 205 is not permitted to generate a transport block for subsequent UL data unless it has received confirmation from RAN node 210 of the first TB of a CG-SDT procedure, including the first SDT UL transmission, e.g., an RRCResumeRequest message. In other words, UE 205 may suppress the processing of subsequent configured uplink grants allocated for small data transmissions for the first new transmission of subsequent uplink data for an SDT procedure. With respect to the case where UE 205 has data available for transmission in its buffer (e.g., PDCP / RLC buffer), e.g., SDT bearer data and allocated UL resources, e.g., CG-SDT resources, UE 205 will not execute an LCP procedure and will not generate a new TB unless it has received confirmation from RAN node 210 of the first TB of a CG-SDT session carrying, e.g., an RRCResumeRequest message. As used herein, a CG-SDT session refers to an SDT procedure that uses CG resources. In the following description, the terms “SDT session” and “SDT procedure” may be used interchangeably to refer to the transfer of data units in the RRC_INACTIVE state.

[0116] According to one implementation of the second solution, a PUSCH allocation, such as a CG-SDT resource, is considered invalid for sending a new TB (i.e., the first new transmission) unless the first TB has been acknowledged by RAN node 210. Considering a PUSCH allocation (e.g., a CG-SDT resource) invalid means that UE 205 will ignore the PUSCH allocation, not generate a TB with respect to the PUSCH allocation, and will not perform a UL(PUSCH) transmission corresponding to the PUSCH allocation.

[0117] According to another implementation of the second solution, UE 205 ignores UL grants / assignments, such as dynamic UL grants communicated within the Downlink Control Information ("DCI"), unless it has received confirmation from RAN node 210 that it has received the first TB for the corresponding CG-SDT session. Ignoring UL grants / assignments means that UE 205 does not generate TBs for UL grants / assignments and does not perform UL(PUSCH) transmissions corresponding to PUSCH assignments.

[0118] According to an alternative implementation of the second solution, UE 205 suspends all allocated PUSCH resources, e.g., CG-SDT resources, for sending new TBs unless it receives confirmation from RAN node 210 regarding the first TB of a CG-SDT session (e.g., corresponding to an SDT procedure), i.e., unless RAN node 210 has confirmed receipt of the first TB (e.g., an RRCResumeRequest message). Upon receiving confirmation of receipt of the first TB, UE 205 resumes or reinitializes all allocated PUSCH resources, e.g., CG-SDT resources. Thus, UE 205 can use the CG-SDT resources or any other allocated PUSCH resources for subsequent UL data, i.e., sending new TBs.

[0119] According to some further alternative implementations of the second solution, UE 205 considers all uplink HARQ processes, except for the HARQ process used for sending the first SDT TB, e.g., the TB containing the RRCResumeRequest message, to be suspended or deactivated at the start of the CG-SDT session. Considering UL HARQ processes to be deactivated or suspended means that the HARQ processes cannot be used for UL(PUSCH) transmissions. Upon receiving confirmation of the receipt of the first TB (e.g., the RRCResumeRequest message) from RAN node 210, UE 205 considers all UL HARQ processes to be active. As a result, UE 205 can use any UL HARQ process to send new UL data.

[0120] According to one embodiment, the TB confirmation, which includes the initial SDT message, for example, an RRCResumeRequest message, may be one of the following: • PDCCH scheduling some initial PDSCH transmission: If there is some DL data for UE 205 (for example, in response to the first SDT message), the confirmation may be a PDCCH scheduling a PDSCH for the DL data. • PDCCH scheduling some initial PUSCH transmission: If the first UL message has a BSR, the confirmation may be a PDCCH that grants further UL data. • PDSCH containing an RRCRelease message: If there is no subsequent DL or UL, the network may want to terminate the SDT procedure immediately (i.e., everything is complete). In such embodiments, the DL response may be an RRCRelease scheduled using a PDCCH addressed to C-RNTI. PDSCH including Timing Advance Command (TAC): If the network is waiting for DL ​​or (further) UL traffic and you want to keep the UE 205 in SDT for the time being (e.g., during waiting time), the confirmation may be something as simple as a TAC MAC control element ("CE") or similar addressed directly to the UE 205.

[0121] According to a third embodiment of the solution, a logical channel is configured with a parameter indicating whether autonomous retransmission is supported for the data of that logical channel. If the logical channel ("LCH") configuration indicates that autonomous retransmission is supported for the corresponding LCH, the UE 205 may autonomously retransmit the TB containing the data of the corresponding LCH, for example, if the reception of the TB was not explicitly confirmed by a feedback message or the transmission of the TB could not be performed (skipped) due to some channel unavailability.

[0122] According to one implementation of the third solution, UE 205 supports autonomous retransmission for a TB (for example, in a MAC entity) if there is data for at least one LCH in the TB that supports autonomous retransmission according to the LCH configuration. In one specific implementation of the third solution, the new parameter is a new field in IE LogicalChannelConfig. Several exemplary implementations of the new parameter in the 3GPP® specification according to the third solution are shown below.

[0123] Figure 6 shows an exemplary ASN.1 representation 600 of IE LogicalChannelConfig that may be used to configure logical channel parameters.

[0124] Configuring whether any autonomous retransmission functionality is supported on a per-LCH basis allows the network (e.g., RAN node 210 or 5GC) to have finer-grained control over which types of data autonomous retransmission should be supported by UE 205. For example, with respect to SDT, the network (e.g., RAN node 210 or 5GC) can ensure through a new LCH parameter that UE 205 is only allowed to (autonomously) retransmit the first TB of an SDT session, e.g., the TB containing the RRCResumeRequest message, and not to retransmit any subsequent UL data.

[0125] According to an embodiment of the fourth solution, the configured uplink grant configuration consists of two periodicities. In one implementation of the fourth solution, multiple CG PUSCH resources are configured within a single CG period. In one embodiment of the fourth solution, the two periodicities are configured for the configured grant configuration used for SDT, i.e., for CG-SDT. The configured grant for small data transmission in RRC_INACTIVE, i.e., CG-SDT, is based on the CG type 1 configuration specified in Rel-15 NR. Essentially, UL data transmission over CG-SDT resources is based on RRC reconfiguration without any L1 signaling. RRC provides the grant configuration to UE 205 through the higher-layer IE ConfiguredGrantConfig, which includes the parameter rrc-ConfiguredUplinkGrant, without detecting any UL grants in DCI, and there are no specific activation / release procedures, for example. The CG-SDT resource signals UE 205, for example, within an RRCRelease message, i.e., sends RRC_INACTIVE to UE 205. In legacy NRs, when CG type 1 is configured, the RRC configures the following parameters: • cs-RNTI: This parameter indicates CS-RNTI for retransmission. • periodicity: This parameter indicates the periodicity of CG type 1. • timeDomainOffset: This parameter indicates the resource offset relative to system frame number ("SFN") = 0 in the time domain. • timeDomainAllocation: This parameter indicates the allocation of the configured uplink grant in the time domain including startSymbolAndLength. • nrofHARQ-Processes: This parameter indicates the number of HARQ processes for the configured grant.

[0126] According to the fourth solution, the second periodicity is configured by RRC with respect to the CG-SDT resource. According to one implementation of the fourth solution, the first periodicity (existing periodicity) configures the CG resource for the first SDT CG-PUSCH transmission of the SDT session, and the new second periodicity configures the CG-SDT resource within the SDT session for, for example, subsequent UL data transmissions or retransmissions of the initial SDT message / TB. Note that there may be multiple subsequent CG-SDT PUSCH resources within the SDT procedure that can be used for subsequent UL data transmissions.

[0127] The first periodicity refers to the periodicity of small data arrivals at the UE 205 while in the RRC_INACTIVE state. To give an example of how the two periodicities can be used, if a smart sensor reports some sensor data every 1s, the first periodicity would be set to 1s. Several uplink transmissions are required so that multiple CG-SDTs are configured within the SDT session in order to report the sensor data. The second periodicity refers to the periodicity of CG-SDT resources within the SDT session.

[0128] Figure 7 shows a configured uplink grant configuration 700 that includes two periodicities. As shown in Figure 7, there are multiple CG PUSCH resources configured within a first CG periodicity. The first periodicity (labeled "P1") is between consecutive sets of CG-SDT resources, while the second periodicity (labeled "P2") is between adjacent CG-SDT resources within a set. As shown, an SDT session begins with an SDT start and ends with an SDTrelease (including, for example, an RRCRelease message).

[0129] According to one implementation of the fourth solution, UE 205, when in the RRC_INACTIVE state and before initiating an SDT session / procedure, considers only the first periodicity—as in legacy—to determine the CG-SDT resource, i.e., the CG-SDT resource is used only for the first SDT TB consisting of, for example, an RRCResumeRequest message.

[0130] Once the SDT procedure is initiated, in response to the transmission of the first SDT TB on the CG-SDT resource (determined according to the first periodicity), UE 205 activates further CG-SDT resources according to the second configured periodicity (i.e., P2). UE 205 is permitted to retransmit the first SDT TB on subsequent CG-SDT resources allocated according to the second periodicity or to transmit any further subsequent SDT UL data / TB.

[0131] When an SDT session / procedure terminates, i.e., upon receiving an RRCRelease message or any other RRC message received from the network that keeps UE 205 in RRC_INACTIVE, UE 205 deactivates / suspends the CG-SDT resources following the second periodicity, while the CG-SDT resources following the first periodicity remain active unless RAN node 210 initiates a transition of UE 205 to a different RRC state such as RRC_IDLE or RRC_CONNECTED.

[0132] Figures 8A and 8B show an ASN.1 representation 800 of an exemplary ConfiguredGrantConfig IE according to an embodiment of the present disclosure. The IE shown includes the new additional periodicity described above. The additional periodicity used for CG-SDT resources within an SDT session / procedure is indicated by the parameter “Periodicity_SDT” (see Figure 8B), which indicates a CG-SDT resource within an SDT session and corresponds to the second periodicity described above.

[0133] According to an embodiment of the fifth solution, UE 205 maintains a new timer for each HARQ process that controls the autonomous (re)transmission of TBs sent by the relevant HARQ process. According to one implementation of the fifth solution, the new timer is started or restarted when a configured grant resource in the HARQ process, i.e., a TB on the CG PUSCH, is transmitted. Note that the MAC entity includes a HARQ entity for each serving cell with configured uplinks (including when it is configured with a supplemental uplink ("SUL")), and the HARQ entity maintains several parallel HARQ processes. As mentioned above, the timer is maintained for each HARQ process.

[0134] In one particular implementation, a new timer associated with a HARQ process is started or restarted when a TB is sent on a CG-SDT resource within that HARQ process.

[0135] In one implementation, the timer for a HARQ process is stopped when it receives a PDCCH addressed to that HARQ process, for example, a PDCCH indicating a UL or DL ​​transmission.

[0136] In one particular implementation, the timer for a HARQ process is stopped when it receives a PDCCH indicating a new first UL or DL ​​transmission related to that HARQ process. Once the timer associated with the HARQ process expires, UE 205 performs some (autonomous) (re)transmission of any TBs held in the HARQ buffer. Autonomous (re)transmission refers to the case where UE 205 performs a transmission of TBs held in the HARQ buffer without receiving any explicit network signaling indicating that it is performing a transmission of TBs.

[0137] According to some further aspects of the fifth solution, the UE 205 starts / restarts a new timer only for the first uplink transmission of an SDT session, e.g., a TB containing an RRCResumeRequest message. By starting a new timer only for the first SDT transmission, it is ensured that the autonomous (re)transmission function is supported only for the first SDT TB / message and not for subsequent UL transmissions within the SDT session.

[0138] Figure 9 shows a user device 900 that may be used for an SDT procedure using CG resources according to embodiments of the present disclosure. In various embodiments, the user device 900 is used to implement one or more of the solutions described above. The user device 900 may be one embodiment of a user endpoint such as the remote unit 105 and / or UE 205 described above. Furthermore, the user device 900 may include a processor 905, memory 910, input device 915, output device 920, and transceiver 925.

[0139] In some embodiments, the input device 915 and the output device 920 are combined into a single device such as a touchscreen. In certain embodiments, the user equipment 900 may not include any input device 915 and / or output device 920. In various embodiments, the user equipment 900 may include one or more of the processor 905, memory 910, and transceiver 925, and may not include the input device 915 and / or output device 920.

[0140] As shown, the transceiver 925 includes at least one transmitter 930 and at least one receiver 935. In some embodiments, the transceiver 925 communicates with one or more cells (or wireless coverage areas) supported by one or more base units 121. In various embodiments, the transceiver 925 is capable of operating in the unlicensed spectrum. Furthermore, the transceiver 925 may include multiple UE panels supporting one or more beams. In addition, the transceiver 925 may support at least one network interface 940 and / or application interface 945. The application interface 945 may support one or more APIs. The network interface 940 may support 3GPP® reference points such as Uu, N1, PC5, etc. Other network interfaces 940 may be supported, as will be understood by those skilled in the art.

[0141] In one embodiment, the processor 905 may include any known controller capable of executing computer-readable instructions and / or logical operations. For example, the processor 905 may be a microcontroller, microprocessor, central processing unit ("CPU"), graphics processing unit ("GPU"), auxiliary processing unit, field-programmable gate array ("FPGA"), or similar programmable controller. In some embodiments, the processor 905 executes instructions stored in memory 910 to perform the methods and routines described herein. The processor 905 is coupled to the memory 910, input device 915, output device 920, and transceiver 925 for communication.

[0142] In various embodiments, the processor 905 controls the user equipment 900 to perform the behavior of the UE described above. In certain embodiments, the processor 905 may include an application processor (also known as the “main processor”) that manages the functions of the application domain and the operating system (“OS”), and a baseband processor (also known as the “baseband radio processor”) that manages the radio functions.

[0143] In various embodiments, via the transceiver 925, the processor 905 receives a configuration from a network entity (e.g., a gNB and / or RAN node) that allocates a configured uplink grant for small data transmission. In some embodiments, to receive the configuration, the processor 905 causes the user equipment device 900 to receive an RRC release message. In such embodiments, the RRC release message includes a configuration that allocates a configured uplink grant for small data transmission.

[0144] As used herein, a configured uplink grant (also referred to as a “configured grant” or “CG”) refers to a quasi-static (e.g., quasi-persistent) allocation of an uplink resource (e.g., a CG type 1 resource for small data transmissions). As described above, small data transmissions may contain an amount of user data smaller than a data volume threshold.

[0145] Through the transceiver 925, the processor 905 sends the first configured grant small data transmission of the SDT procedure to the network entity using the configured uplink grant for small data transmission. In some embodiments, the processor 905 causes the user equipment device 900 to send the first configured grant small data transmission while the device is in an RRC inactive state (e.g., RRC_INACTIVE). In some embodiments, the first configured grant small data transmission includes a message for the CCCH logical channel. In certain embodiments, the first configured grant small data transmission includes an RRC restart request message.

[0146] The processor 905 suppresses (for example, skips) the processing of subsequent configured uplink grants allocated for small data transmissions for the first new transmission of uplink data following the SDT procedure. In some embodiments, the processor 905 suppresses the processing of configured uplink grants allocated for small data transmissions for the first new transmission of uplink data following the SDT procedure by causing the user equipment device 900 to refrain from performing the LCP procedure until confirmation of the first configured grant small data transmission is received.

[0147] In some embodiments, the processor 905 suppresses the processing of configured uplink grants allocated for small data transmissions for the first new transmission of uplink data following the SDT procedure by causing the user equipment device 900 to consider the PUSCH allocation for the new TB invalid until confirmation of the first configured grant small data transmission is received.

[0148] Through the transceiver 925, the processor 905 receives confirmation from the network entity of the initial configured grant subdata transmission. In some embodiments, the confirmation of the initial configured grant subdata transmission includes a PDCCH transmission addressed to the C-RNTI of the user equipment device 900. In one embodiment, the PDCCH transmission schedules the initial PDSCH transmission. In another embodiment, in response to the initial configured grant subdata transmission, which includes a buffer status report, the PDCCH transmission schedules the initial PUSCH transmission.

[0149] In response to receiving confirmation of the initial configured grant small data transmission, the processor 905 processes subsequent configured uplink grants allocated for small data transmissions for the first new transmission of subsequent uplink data for the SDT procedure. In some embodiments, in response to receiving confirmation of the initial configured grant small data transmission, the processor 905 further causes the user equipment 900 to A) generate a TB for subsequent uplink data for the SDT procedure and B) transmit the TB using the subsequent configured uplink grants allocated for small data transmissions.

[0150] In some embodiments, the processor 905 causes the user device 900 to: A) maintain autonomous retransmission timers for HARQ processes having HARQ process IDs; B) start each autonomous retransmission timer in response to the device sending the first configured grant subdata transmission, such that the first configured grant subdata transmission is associated with each HARQ process ID; and C) stop each autonomous retransmission timer in response to receiving confirmation of the device sending the first configured grant subdata transmission.

[0151] In some embodiments, in response to the expiration of each autonomous retransmission timer before receiving confirmation of the first configured grant small data transmission, the processor 905 causes the user equipment 900 to autonomously retransmit the first configured grant small data transmission. In certain embodiments, the processor 905 causes the user equipment 900 to retransmit the first configured grant SDT transmission using the same HARQ process (for example, having the same HARQ process ID) on the next configured uplink grant assigned for the small data transmission.

[0152] In some embodiments, confirmation of the initial configured grant small data transmission includes a PDCCH transmission addressed to each HARQ process. In certain embodiments, the PDCCH transmission schedules the initial PDSCH transmission and / or the initial PUSCH transmission for each HARQ process. In some embodiments, the processor 905 causes the user equipment 900 to start its respective autonomous retransmission timer only for the initial configured grant small data transmission, and not for subsequent transmissions in the SDT procedure.

[0153] In one embodiment, memory 910 is a computer-readable storage medium. In some embodiments, memory 910 includes a volatile computer storage medium. For example, memory 910 may include RAM including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, memory 910 includes a non-volatile computer storage medium. For example, memory 910 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 910 includes both a volatile computer storage medium and a non-volatile computer storage medium.

[0154] In some embodiments, memory 910 stores data related to SDT procedures that use CG resources. For example, memory 910 may store the parameters, configurations, etc. In certain embodiments, memory 910 also stores program code and related data, such as an operating system or other controller algorithms that run on the user equipment device 900.

[0155] In one embodiment, the input device 915 may include any known computer input device, such as a touch panel, buttons, a keyboard, a stylus, or a microphone. In some embodiments, the input device 915 may be integrated with the output device 920, for example, as a touchscreen or similar touch display. In some embodiments, the input device 915 includes a touchscreen so that text may be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, the input device 915 includes two or more different devices, such as a keyboard and a touch panel.

[0156] In one embodiment, the output device 920 is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 920 includes an electronically controllable display or display device that can output visual data to a user. For example, the output device 920 may include, but is not limited to, a liquid crystal display ("LCD"), a light-emitting diode ("LED") display, an organic LED ("OLED") display, a projector, or a similar display device that can output images, text, etc., to a user. In another non-limiting example, the output device 920 may include a wearable display that is separate from the rest of the user equipment device 900 but coupled to communicate with them, such as a smartwatch, smart glasses, or a head-up display. Furthermore, the output device 920 may be a component of a smartphone, personal digital assistant, television, table computer, notebook (laptop) computer, personal computer, or vehicle dashboard.

[0157] In certain embodiments, the output device 920 includes one or more speakers for generating sound. For example, the output device 920 may generate an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device 920 includes one or more haptic devices for generating vibration, motion, or other tactile feedback. In some embodiments, all or part of the output device 920 may be integrated with the input device 915. For example, the input device 915 and the output device 920 may form a touchscreen or similar touch display. In other embodiments, the output device 920 may be located near the input device 915.

[0158] The transceiver 925 communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver 925 operates under the control of the processor 905 to transmit and receive messages, data, and other signals. For example, the processor 905 may selectively activate the transceiver 925 (or a portion thereof) at specific times to send and receive messages.

[0159] The transceiver 925 includes at least one transmitter 930 and at least one receiver 935. One or more transmitters 930 may be used to provide a UL communication signal, such as a UL transmission as described herein, to the base unit 121. Similarly, one or more receivers 935 may be used to receive a DL communication signal from the base unit 121, as described herein. Although only one transmitter 930 and one receiver 935 are illustrated, the user equipment 900 may have any suitable number of transmitters 930 and receivers 935. Furthermore, the transmitters 930 and receivers 935 may be any suitable type of transmitter and receiver. In one embodiment, the transceiver 925 includes a first transmitter / receiver pair used to communicate with a mobile communication network over a licensed radio spectrum and a second transmitter / receiver pair used to communicate with a mobile communication network over an unlicensed radio spectrum.

[0160] In certain embodiments, a first transmitter / receiver pair used to communicate with a mobile communications network over a licensed radio spectrum, and a second transmitter / receiver pair used to communicate with a mobile communications network over an unlicensed radio spectrum, may be combined into a single transceiver unit, for example, a single chip that performs functions for use in both the licensed and unlicensed radio spectrums. In some embodiments, the first and second transmitter / receiver pairs may share one or more hardware components. For example, a particular transceiver 925, transmitter 930, and receiver 935 may be implemented as physically separate components that access shared hardware and / or software resources, such as a network interface 940.

[0161] In various embodiments, one or more transmitters 930 and / or one or more receivers 935 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an application-specific integrated circuit ("ASIC"), or other types of hardware components. In certain embodiments, one or more transmitters 930 and / or one or more receivers 935 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components, such as a network interface 940 or other hardware components / circuits, may be integrated into a single chip together with any number of transmitters 930 and / or receivers 935. In such embodiments, the transmitters 930 and receivers 935 may be logically configured as transceivers 925 using one or more common control signals, or as modular transmitters 930 and receivers 935 implemented within the same hardware chip or multi-chip module.

[0162] Figure 10 shows a network device 1000 that may be used for an SDT procedure using CG resources according to an embodiment of the present disclosure. In one embodiment, the network device 1000 may be one implementation of a network endpoint such as the base unit 121 and / or RAN node 210 described above. Furthermore, the network device 1000 may include a processor 1005, memory 1010, input device 1015, output device 1020, and transceiver 1025.

[0163] In some embodiments, the input device 1015 and the output device 1020 are combined into a single device such as a touchscreen. In certain embodiments, the network device 1000 may not include any input device 1015 and / or output device 1020. In various embodiments, the network device 1000 may include one or more of the processor 1005, memory 1010, and transceiver 1025, and may not include the input device 1015 and / or output device 1020.

[0164] As shown, the transceiver 1025 includes at least one transmitter 1030 and at least one receiver 1035, where the transceiver 1025 communicates with one or more remote units 105. In addition, the transceiver 1025 may support at least one network interface 1040 and / or application interface 1045. The application interface 1045 may support one or more APIs. The network interface 1040 may support 3GPP® reference points such as Uu, N1, N2, and N3. Other network interfaces 1040 may be supported, as will be understood by those skilled in the art.

[0165] In one embodiment, the processor 1005 may include any known controller capable of executing computer-readable instructions and / or logical operations. For example, the processor 1005 may be a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar programmable controller. In some embodiments, the processor 1005 executes instructions stored in memory 1010 to perform the methods and routines described herein. The processor 1005 is coupled to the memory 1010, input device 1015, output device 1020, and transceiver 1025 for communication.

[0166] In various embodiments, the network device 1000 is a RAN node (e.g., gNB) that communicates with one or more UEs, as described herein. In such embodiments, the processor 1005 controls the network device 1000 to perform the RAN behavior described above. When operating as a RAN node, the processor 1005 may include an application processor (also known as the “main processor”) that manages application domain and operating system (“OS”) functions, and a baseband processor (also known as the “baseband radio processor”) that manages radio functions.

[0167] In various embodiments, via transceiver 1025, processor 1005 transmits a configuration to the UE to allocate a configured uplink grant for small data transmissions and receives the first configured grant small data transmission of the SDT procedure from the UE using the configured uplink grant for small data transmissions. Via transceiver 1025, processor 1005 transmits an acknowledgment of receipt of the first configured grant small data transmission to the UE and, in response to the acknowledgment, receives TBs for subsequent uplink data of the SDT procedure using the subsequent configured uplink grant allocated for small data transmissions.

[0168] In some embodiments, the initial configured grant subdata transmission is received while the communication device (e.g., UE) is in an RRC inactive state. In some embodiments, the initial configured grant subdata transmission includes a message on the CCCH logical channel. In certain embodiments, the initial configured grant subdata transmission includes an RRC restart request message.

[0169] In some embodiments, confirmation of the initial configured grant small data transmission includes a PDCCH transmission addressed to the device's C-RNTI. In certain embodiments, the PDCCH transmission schedules the initial PDSCH transmission. In other embodiments, in response to the initial configured grant small data transmission, which includes a buffer status report, the PDCCH transmission schedules the initial PUSCH transmission.

[0170] In some embodiments, to transmit a configuration, the processor 1005 causes the transceiver 1025 to send an RRC release message, the RRC release message includes a configuration that allocates a configured uplink grant for small data transmission. In some embodiments, the configuration further configures the UE for autonomous retransmission of a HARQ process having a HARQ process ID.

[0171] In certain embodiments, the initial configured grant subdata transmission is associated with each HARQ process ID. In such embodiments, confirmation of the initial configured grant subdata transmission includes a PDCCH transmission addressed to each HARQ process. In one embodiment, the PDCCH transmission schedules the first PDSCH transmission for each HARQ process. In another embodiment, the PDCCH transmission schedules the first PUSCH transmission for each HARQ process.

[0172] In one embodiment, memory 1010 is a computer-readable storage medium. In some embodiments, memory 1010 includes a volatile computer storage medium. For example, memory 1010 may include RAM, including DRAM, SDRAM, and / or SRAM. In some embodiments, memory 1010 includes a non-volatile computer storage medium. For example, memory 1010 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 1010 includes both a volatile computer storage medium and a non-volatile computer storage medium.

[0173] In some embodiments, memory 1010 stores data related to SDT procedures that use CG resources. For example, memory 1010 may store the parameters, configurations, etc. In certain embodiments, memory 1010 also stores program code and related data, such as an operating system or other controller algorithms that run on the network device 1000.

[0174] In one embodiment, the input device 1015 may include any known computer input device, such as a touch panel, buttons, a keyboard, a stylus, or a microphone. In some embodiments, the input device 1015 may be integrated with the output device 1020, for example, as a touchscreen or similar touch display. In some embodiments, the input device 1015 includes a touchscreen so that text may be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, the input device 1015 includes two or more different devices, such as a keyboard and a touch panel.

[0175] In one embodiment, the output device 1020 is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 1020 includes an electronically controllable display or display device that can output visual data to a user. For example, the output device 1020 may include, but is not limited to, an LCD display, LED display, OLED display, projector, or similar display device that can output images, text, etc., to a user. In another non-limiting example, the output device 1020 may include a wearable display, such as a smartwatch, smart glasses, or head-up display, that is separate from but coupled to the rest of the network device 1000 so as to be able to communicate with them. Furthermore, the output device 1020 may be a component of a smartphone, personal digital assistant, television, table computer, notebook (laptop) computer, personal computer, or vehicle dashboard.

[0176] In certain embodiments, the output device 1020 includes one or more speakers for generating sound. For example, the output device 1020 may generate an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device 1020 includes one or more haptic devices for generating vibration, motion, or other tactile feedback. In some embodiments, all or part of the output device 1020 may be integrated with the input device 1015. For example, the input device 1015 and the output device 1020 may form a touchscreen or similar touch display. In other embodiments, the output device 1020 may be located near the input device 1015.

[0177] The transceiver 1025 includes at least one transmitter 1030 and at least one receiver 1035. One or more transmitters 1030 may be used to communicate with the UE as described herein. Similarly, one or more receivers 1035 may be used to communicate with the PLMN and / or RAN network functions as described herein. Although only one transmitter 1030 and one receiver 1035 are illustrated, the network device 1000 may have any suitable number of transmitters 1030 and receivers 1035. Furthermore, the transmitters 1030 and receivers 1035 may be any suitable type of transmitter and receiver.

[0178] Figure 11 shows one embodiment of Method 1100 for an SDT procedure using CG resources according to embodiments of the present disclosure. In various embodiments, Method 1100 is performed by a communication device such as the remote unit 105, UE 205, and / or user equipment device 900 described above. In some embodiments, Method 1100 is performed by a processor such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0179] Method 1100 includes step 1105 receiving a configuration from a network entity (e.g., a gNB and / or RAN node) to allocate a configured uplink grant for a small data transmission. Method 1100 includes step 1110 sending the SDT procedure's first configured grant small data transmission to the network entity using the configured uplink grant for the small data transmission. Method 1100 includes step 1115 suppressing the processing of subsequent configured uplink grants allocated for small data transmissions for the SDT procedure's first new transmission of uplink data. Method 1100 includes step 1120 receiving confirmation from the network entity for the first configured grant small data transmission. Method 1100 includes step 1125 processing subsequent configured uplink grants allocated for small data transmissions for the SDT procedure's first new transmission of uplink data in response to receiving confirmation for the first configured grant small data transmission.

[0180] Disclosed herein is a first apparatus for an SDT procedure using CG resources, according to embodiments of the present disclosure. The first apparatus may be implemented by communication devices such as the remote unit 105, UE 205, and / or user equipment apparatus 900 described above. The first apparatus includes a memory-coupled processor, the processor configured to cause the apparatus to: A) receive a configuration from a network entity (e.g., a gNB and / or RAN node) to allocate a configured uplink grant for a small data transmission; B) send the first configured grant small data transmission of the SDT procedure to the network entity using the configured uplink grant for the small data transmission; C) suppress the processing of subsequent configured uplink grants allocated for small data transmissions for the first new transmission of subsequent uplink data of the SDT procedure; D) receive confirmation from the network entity of the first configured grant small data transmission; and E) process subsequent configured uplink grants allocated for small data transmissions for the first new transmission of subsequent uplink data of the SDT procedure in response to the receipt of confirmation of the first configured grant small data transmission.

[0181] In some embodiments, the processor is further configured to cause the device to A) generate a TB for subsequent uplink data following an SDT procedure, and B) transmit the TB using a subsequent configured uplink grant allocated for a small data transmission. In some embodiments, the processor is configured to cause the device to transmit the initial configured grant small data transmission while the device is in an RRC inactive state (e.g., RRC_INACTIVE).

[0182] In some embodiments, the initial configured grant subdata transmission includes a CCCH message. In certain embodiments, the initial configured grant subdata transmission includes an RRC restart request message.

[0183] In some embodiments, confirmation of the initial configured grant small data transmission includes a PDCCH transmission addressed to the device's C-RNTI. In one embodiment, the PDCCH transmission schedules the initial PDSCH transmission. In another embodiment, in response to the initial configured grant small data transmission, which includes a buffer status report, the PDCCH transmission schedules the initial PUSCH transmission.

[0184] In some embodiments, to receive configuration, the processor is configured to cause the device to receive an RRC release message. In such embodiments, the RRC release message includes configuration to allocate a configured uplink grant for small data transmission.

[0185] In some embodiments, to suppress the processing of configured uplink grants allocated for small data transmissions for the first new transmission of uplink data following an SDT procedure, the processor is configured to cause the device to refrain from performing the LCP procedure until confirmation of the first configured grant small data transmission is received.

[0186] In some embodiments, to suppress the processing of configured uplink grants allocated for small data transmissions for the first new transmission of uplink data following an SDT procedure, the processor is configured to cause the device to consider the PUSCH allocation for the new TB invalid until confirmation of the first configured grant small data transmission is received.

[0187] In some embodiments, the processor is configured to cause the device to: A) maintain autonomous retransmission timers for HARQ processes having HARQ process IDs; B) start each autonomous retransmission timer in response to the device sending the first configured grant subdata transmission, such that the first configured grant subdata transmission is associated with each HARQ process ID; and C) stop each autonomous retransmission timer in response to receiving confirmation of the device sending the first configured grant subdata transmission.

[0188] In some embodiments, the processor is configured to cause the device to autonomously retransmit the initial configured grant small data transmission in response to the expiration of each autonomous retransmission timer before receiving confirmation of the initial configured grant small data transmission. In certain embodiments, the processor is configured to cause the device to retransmit the initial configured grant SDT transmission on the next configured uplink grant assigned for the small data transmission, using the same HARQ process (for example, having the same HARQ process ID).

[0189] In some embodiments, confirmation of the initial configured grant small data transmission includes a PDCCH transmission addressed to each HARQ process. In certain embodiments, the PDCCH transmission schedules the initial PDSCH transmission and / or the initial PUSCH transmission for each HARQ process. In some embodiments, the processor is configured to cause the device to activate its respective autonomous retransmission timer only for the initial configured grant small data transmission, and not for subsequent transmissions in the SDT procedure.

[0190] Disclosed herein is a first method for an SDT procedure using CG resources, according to embodiments of the present disclosure. The first method may be performed by a communication device such as the remote unit 105, UE 205, and / or user equipment device 900 described above. The first method includes the steps of receiving a configuration from a network entity (e.g., a gNB and / or RAN node) to allocate a configured uplink grant for a small data transmission, and sending the first configured grant small data transmission of the Small Data Transmission ("SDT") procedure to the network entity using the configured uplink grant for the small data transmission. The first method includes the step of suppressing the processing of subsequent configured uplink grants allocated for small data transmissions for the first new transmission of subsequent uplink data in the SDT procedure. The first method includes the steps of receiving an acknowledgment of the first configured grant small data transmission from the network entity, and processing subsequent configured uplink grants allocated for small data transmissions for the first new transmission of subsequent uplink data in the SDT procedure in response to the receipt of the acknowledgment of the first configured grant small data transmission.

[0191] In some embodiments, the first method further includes the steps of generating a TB for subsequent uplink data following an SDT procedure and transmitting the TB using a subsequent configured uplink grant allocated for a small data transmission. In some embodiments, the initial configured grant small data transmission is transmitted while the communication device (e.g., UE) is in an RRC inactive state.

[0192] In some embodiments, the initial configured grant subdata transmission includes a CCCH message. In certain embodiments, the initial configured grant subdata transmission includes an RRC restart request message.

[0193] In some embodiments, confirmation of the initial configured grant small data transmission includes a PDCCH transmission addressed to the device's C-RNTI. In certain embodiments, the PDCCH transmission schedules the initial PDSCH transmission. In other embodiments, in response to the initial configured grant small data transmission, which includes a buffer status report, the PDCCH transmission schedules the initial PUSCH transmission.

[0194] In some embodiments, the step of receiving a configuration includes receiving an RRC release message, the RRC release message including a configuration that allocates a configured uplink grant for small data transmissions.

[0195] In some embodiments, the step of suppressing the processing of a configured uplink grant allocated for a small data transmission for the first new transmission of uplink data following an SDT procedure includes refraining from performing the LCP procedure until confirmation of the first configured grant small data transmission is received.

[0196] In some embodiments, the step of suppressing the processing of configured uplink grants allocated for small data transmissions for the first new transmission of uplink data following an SDT procedure includes considering PUSCH allocations for new TBs invalid until confirmation of the first configured grant small data transmission is received.

[0197] In some embodiments, the first method further includes the steps of: maintaining an autonomous retransmission timer for a HARQ process having a HARQ process ID; starting each autonomous retransmission timer in response to the transmission of the first configured grant subdata transmission by the device, wherein the first configured grant subdata transmission is associated with each HARQ process ID; and stopping each autonomous retransmission timer in response to the receipt of confirmation of the first configured grant subdata transmission by the device.

[0198] In some embodiments, depending on the expiration of each autonomous retransmission timer before receiving confirmation of the first configured grant small data transmission, the first method further includes the step of performing an autonomous retransmission of the first configured grant small data transmission. In certain embodiments, the retransmission is performed with respect to the first configured grant SDT transmission on the next configured uplink grant assigned for the small data transmission, using the same HARQ process (for example, having the same HARQ process ID).

[0199] In some embodiments, confirmation of the initial configured grant small data transmission includes a PDCCH transmission addressed to each HARQ process. In one embodiment, the PDCCH transmission schedules the first PDSCH transmission for each HARQ process. In another embodiment, the PDCCH transmission schedules the first PUSCH transmission for each HARQ process. In some embodiments, each autonomous retransmission timer is started only for the initial configured grant small data transmission and not for subsequent transmissions in the SDT procedure.

[0200] The embodiments may be carried out in other specific forms. The embodiments described should be considered illustrative in all respects only and not restrictive. Accordingly, the scope of the invention is indicated not by the above description but by the appended claims. All modifications that fall within the meaning and scope equivalent to the claims should be incorporated within the scope of the claims. [Explanation of Symbols]

[0201] 100 Wireless Communication Systems 105 Remote Unit 107 applications 120 Wireless Access Networks, RAN 121 Base Unit 123 Wireless communication link 125 SDT ("CG-SDT") 140 Mobile Core Network 141 User Plane Function (UPF) 143 AMF 145 SMF 147 PCF 149 UDM / UDR 150 packet data network 151 Application Server 200 NR protocol stack 201 User Plane Protocol Stack 203 Control Plane Protocol Stack 205 UE 210 RANNode 215 AMF 220 Physical (PHY) Layers 225 MAC sublayer 230 Wireless Link Control (RLC) Sublayer 235 PDCP sublayer 240 Service Data Adaptive Protocol (SDAP) Layer 245 RRC Layers 250 NAS layers 255 Access Layer (AS) 260 AS Layers 300 RRC Restart Procedure 305 UPF 400 SDT Procedures 430 SDT Procedure SDT procedure based on 450 RACH Example steps for selecting 500 SDT resources 505 NF Consumer 600 Exemplary IE LogicalChannelConfig ASN.1 representation 700 configured uplink grant configurations 800 Example of ConfiguredGrantConfig IE's ASN.1 representation 900 User Equipment 905 Processor 910 memory 915 Input Devices 920 Output Devices 925 Transceiver 1000 network devices 1005 Processor 1010 memory 1025 Transceiver 1100 methods

Claims

1. User equipment (UE) for wireless communication, At least one memory, The system comprises at least one processor coupled to the at least one memory, and the at least one processor provides the UE, Receiving a configuration to allocate resources using a configured uplink grant for Small Data Transmission (SDT), Sending the initial data transmission of the SDT procedure using the configured uplink grant for SDT, The processing of subsequent configured uplink grants allocated for SDT is suppressed such that the subsequent configured uplink grants are associated with the first new transmission of subsequent uplink data in the SDT procedure. Receiving confirmation of the initial data transmission, wherein the confirmation of the initial data transmission includes a physical downlink control channel (PDCCH) transmission addressed to the UE's cell-specific radio network temporary identifier (C-RNTI), and the PDCCH transmission schedules either the initial physical downlink shared channel (PDSCH) transmission or the initial physical uplink shared channel (PUSCH) transmission. A UE is configured to process the subsequent configured uplink grant in response to the received confirmation of the initial data transmission.

2. The aforementioned at least one processor provides the UE, The SDT procedure generates a transport block (TB) for the subsequent uplink data, The UE according to claim 1, further configured to transmit the TB using the subsequent configured uplink grant allocated for the SDT.

3. The UE according to claim 1, wherein the initial data transmission includes a common control channel (CCCH) message.

4. The UE according to claim 3, wherein the initial data transmission includes a radio resource control (RRC) restart request message.

5. The UE according to claim 1, wherein the at least one processor is configured to cause the UE to send the initial data transmission while the UE is in a radio resource control (RRC) inactive state.

6. The UE according to claim 1, wherein, in order to receive the configuration, the at least one processor is configured to cause the UE to receive a radio resource control (RRC) release message, the RRC release message comprising the configuration.

7. The UE according to claim 1, wherein, in order to suppress the processing of the configured uplink grant allocated for the SDT for the first new transmission of the subsequent uplink data of the SDT procedure, at least one processor is configured to cause the UE to refrain from performing a logical channel prioritization (LCP) procedure until the acknowledgment of the first data transmission is received.

8. The UE according to claim 1, wherein, in order to suppress the processing of the configured uplink grant allocated for the SDT for the first new transmission of the subsequent uplink data of the SDT procedure, at least one processor is configured to cause the UE to consider the physical uplink shared channel (PUSCH) allocation for the new TB invalid until the confirmation of the first data transmission is received.

9. The aforementioned at least one processor provides the UE, Maintain an autonomous retransmission timer for HARQ processes that have a Hybrid Automatic Retransmission Request (HARQ) process identifier (ID), In response to the initial data transmission, each autonomous retransmission timer is started, wherein the initial data transmission is associated with each HARQ process ID. The UE according to claim 1, configured to stop each of the autonomous retransmission timers in response to the confirmation of the initial data transmission.

10. The UE according to claim 9, wherein the at least one processor is configured to cause the UE to perform an autonomous retransmission of the first data transmission in response to the expiration of each autonomous retransmission timer prior to receiving the acknowledgment of the first data transmission.

11. The UE according to claim 10, wherein the at least one processor is configured to cause the UE to perform the autonomous retransmission of the initial data transmission using the same HARQ process on the next configured uplink grant allocated for SDT.

12. The UE according to claim 9, wherein the at least one processor is configured to cause the UE to start its respective autonomous retransmission timer only for the first data transmission and not for subsequent transmissions in the SDT procedure.

13. A method for user equipment (UE), The steps include receiving a configuration to allocate resources using a configured uplink grant for Small Data Transmission (SDT), The steps include sending the initial data transmission of the SDT procedure using a configured uplink grant for SDT, A step of suppressing the processing of subsequent configured uplink grants allocated for SDT, wherein the subsequent configured uplink grant is associated with the first new transmission of subsequent uplink data for the SDT procedure, A step of receiving confirmation of the initial data transmission, wherein the confirmation of the initial data transmission includes a physical downlink control channel (PDCCH) transmission addressed to the cell-specific radio network temporary identifier (C-RNTI) of the UE, and the PDCCH transmission schedules either the initial physical downlink shared channel (PDSCH) transmission or the initial physical uplink shared channel (PUSCH) transmission. A method comprising the step of processing the subsequent configured uplink grant in response to the received confirmation of the initial data transmission.

14. The steps of the SDT procedure include generating a transport block (TB) for the subsequent uplink data, The steps include: transmitting the TB using the subsequent configured uplink grant allocated for the SDT; The method according to claim 13, further comprising:

15. The method according to claim 13, wherein the initial data transmission includes a common control channel (CCCH) message.

16. The method according to claim 13, wherein the confirmation of the initial data transmission includes a physical downlink control channel (PDCCH) transmission addressed to a cell-specific radio network temporary identifier (C-RNTI).

17. A base station for wireless communications, At least one memory, The system comprises at least one processor coupled to the at least one memory, and the at least one processor is connected to the base station. Sending a configuration to the user equipment (UE) that allocates resources using a configured uplink grant for small data transmission (SDT), Receiving the initial data transmission of an SDT procedure using a configured uplink grant for SDT, wherein subsequent configured uplink grants allocated for SDT are suppressed from processing, and the subsequent configured uplink grants are associated with the initial new transmission of subsequent uplink data for the SDT procedure. Sending an acknowledgment of the initial data transmission, wherein the subsequent configured uplink grant is processed in response to the transmitted acknowledgment of the initial data transmission, the acknowledgment of the initial data transmission includes a physical downlink control channel (PDCCH) transmission addressed to the UE's cell-specific radio network temporary identifier (C-RNTI), and the PDCCH transmission schedules either the initial physical downlink shared channel (PDSCH) transmission or the initial physical uplink shared channel (PUSCH) transmission. A device configured to cause something to happen.

18. A method performed by a base station, The steps include sending a configuration to the user equipment (UE) that allocates resources using a configured uplink grant for small data transmission (SDT), A step of receiving the first data transmission of an SDT procedure using a configured uplink grant for SDT, wherein a subsequent configured uplink grant allocated for SDT is suppressed from processing, and the subsequent configured uplink grant is associated with the first new transmission of subsequent uplink data for the SDT procedure. A step of sending an acknowledgment of the initial data transmission, wherein the subsequent configured uplink grant is processed in response to the transmitted acknowledgment of the initial data transmission, the acknowledgment of the initial data transmission includes a physical downlink control channel (PDCCH) transmission addressed to the UE's cell-specific radio network temporary identifier (C-RNTI), and the PDCCH transmission schedules either the initial physical downlink shared channel (PDSCH) transmission or the initial physical uplink shared channel (PUSCH) transmission. Methods that include...

Images