Configured uplink grants 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, entitled “CG-SDT PROCEDURE FOR SMALL DATA TRANSMISSIONS IN RRC_INACTIVE,” filed December 7, 2021, to Joachim Lohr, Prateek Basu Mallick, Alexander Golitschek, Hyung-Nam Choi, and Ravi Kuchibhotla, which is incorporated herein by reference.

[0002] The subject matter disclosed herein relates generally to wireless communications, and more particularly to configuring user equipment ("UE") with uplink resources, e.g., Configured Grants ("CGs"), for small data transmissions ("SDTs"). [Background technology]

[0003] The 3rd Generation Partnership Project ("3GPP") New Radio ("NR") system supports the RRC_INACTIVE state, and devices that transmit data infrequently (periodic and / or non-periodic) are generally maintained in the RRC_INACTIVE state by the network. However, according to current 3GPP standards, the RRC_INACTIVE state does not support the transmission of data. Thus, 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 problem]

[0004] Disclosed are procedures relating to SDT procedures using CG resources, which may be implemented by an apparatus, a system, a method, or a computer program product.

[0005] One method in a UE includes receiving, from a network entity, a configuration allocating a configured uplink grant for small data transmission, and transmitting a first configured grant small data transmission of an SDT procedure to the network entity using the configured uplink grant for small data transmission. The method includes inhibiting processing of the subsequent configured uplink grant assigned for the small data transmission for the first new transmission of subsequent uplink data of the SDT procedure, and receiving, from the network entity, a confirmation of the first configured grant small data transmission. The method includes processing the subsequent configured uplink grant assigned for the small data transmission for the first new transmission of subsequent uplink data of the SDT procedure in response to receiving the confirmation of the first configured grant small data transmission.

[0006] A more particular description of the embodiments briefly described above will be made by reference to specific embodiments illustrated in the accompanying drawings, in which the embodiments will be described and explained with more specificity and detail, with the understanding that these drawings illustrate only some embodiments and therefore should not be considered limiting in scope. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is a schematic block diagram illustrating an embodiment of a wireless communication system for SDT procedures using CG resources. [Diagram 2] FIG. 1 is a block diagram illustrating one embodiment of a New Radio ("NR") protocol stack. [Diagram 3]FIG. 1 illustrates one embodiment of a radio resource control ("RRC") restart procedure. [Figure 4A] A diagram showing one embodiment of a procedure for SDT procedure based on a random access channel and / or configured grant ("RACH / CG") in RRC_INACTIVE. [Figure 4B] FIG. 1 illustrates one embodiment of a procedure for a random access channel ("RACH") based SDT procedure with subsequent data transmission. [Diagram 5] 1 is a flow diagram illustrating one embodiment of a procedure for selection of an SDT or non-SDT resource. [Figure 6] FIG. 1 illustrates one embodiment of an Abstract Syntax Notation One ("ASN.1") form of a LogicalChannelConfig information element ("IE"). [Figure 7] FIG. 1 illustrates one embodiment of a configured uplink grant configuration consisting of two periodicities. [Figure 8A] FIG. 13 illustrates one embodiment of the ASN.1 form of the ConfiguredGrantConfig IE. [Figure 8B] This is a continuation of the ConfiguredGrantConfig IE in Figure 8A. [Figure 9] FIG. 2 is a block diagram illustrating an embodiment of a user equipment device that may be used for SDT procedures using CG resources. [Figure 10] FIG. 2 is a block diagram illustrating an embodiment of a network device that may be used for SDT procedures using CG resources. [Figure 11] 1 is a flow diagram illustrating an embodiment of a first method for an SDT procedure using CG resources. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] As will be appreciated by one skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, the embodiments may take the form of an all-hardware embodiment, an all-software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects.

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

[0010] Furthermore, embodiments may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, hereinafter referred to as code, computer readable code, and / or program code. The storage devices may be tangible, non-transitory, and / or non-transmitting. The storage devices may not embody signals. In certain embodiments, the storage devices employ only signals to access the code.

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

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

[0013] The code for carrying out the operations of the embodiments may be 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, C++, ordinary procedural programming languages ​​such as the "C" programming language, and / or machine code 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"), wireless LAN ("WLAN"), or wide area network ("WAN"), or a connection to an external computer may be made (e.g., via the Internet using an Internet Service Provider ("ISP").

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

[0015] Reference throughout this specification to "one embodiment," "an embodiment," or similar language means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, throughout this specification, the appearance of the phrases "in one embodiment," "in an embodiment," and similar language may, but do not necessarily, all refer to the same embodiment and may mean "one or more, but not all, embodiments" unless otherwise specified. The terms "including," "comprising," "having," and variations thereof 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. Additionally, the terms "a," "an," and "the" refer to "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 a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, 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 a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, 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 only one of any single item in the list. For example, "one of A, B, and C" includes only A, only B, or only C, and excludes the combination of A, B, and C. As used herein, "at least one of A, B, and C" includes only A, only B, only C, 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 member selected from the group consisting of A, B, and C" includes only one of A, B, or C, and excludes the combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C and combinations thereof" includes only A, only B, only C, 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 are described below with reference to schematic flow charts and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that each block of the schematic flow charts and / or schematic block diagrams, and combinations of blocks in the schematic flow charts and / or schematic block diagrams, may be implemented by code. This code may be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing apparatus produce means for performing the functions / acts specified in the flow charts and / or block diagrams.

[0018] The code may be stored in a storage device that can instruct a computer, other programmable data processing apparatus, or other device to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture that includes instructions that perform the functions / acts specified in the flowcharts and / or block diagrams.

[0019] The code may be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to produce a computer-implemented process such that the code executing on the computer or other programmable apparatus provides a process for performing the functions / acts specified in the flow charts and / or block diagrams.

[0020] The call-flow diagrams, flow charts, and / or block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the flow charts and / or block diagrams may represent a module, segment, or portion of code that includes one or more executable instructions of code for implementing the specified logical function(s).

[0021] It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks of the illustrated figures, or portions thereof.

[0022] Although various arrow types and line types may be used in the call flow diagrams, flow diagrams, and / or block diagrams, it is understood that they do not limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the illustrated embodiments. For example, arrows may indicate wait or monitoring periods of unspecified duration between recited steps of the illustrated embodiments. It is also noted that each block of the block diagrams and / or flow diagrams, and combinations of blocks in the block diagrams and / or flow diagrams, may be implemented by dedicated hardware-based systems that perform the specified functions or acts, or a combination of dedicated hardware and code.

[0023] The description of the elements in each figure may refer to the elements in the procedure figures. Like numbers refer to like elements in all figures, including alternative embodiments of like elements.

[0024] Generally, this disclosure describes systems, methods, and apparatus for configuring user equipment ("UE") with CG-SDT resources (i.e., CG resources for SDT procedures). In certain embodiments, the methods may be performed using computer code embodied in a computer-readable medium. In certain embodiments, the apparatus or system may include a computer-readable medium including 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 data transmissions (periodic and / or aperiodic) are generally kept in the RRC_INACTIVE state by the network. However, so far, the RRC_INACTIVE state does not support the transmission of data. Therefore, the UE must resume the connection (i.e., transition to the RRC_CONNECTED state) for all downlink ("DL") (e.g., mobile terminated) and uplink ("UL") (e.g., mobile originated) data. If small data transmissions in the RRC_INACTIVE state were not supported, the UE would be required to set up an RRC connection (i.e., transition to the RRC_CONNECTED state) and then be released to the RRC_INACTIVE state for every data transmission, regardless of how small and infrequent the data packets are. This results in unnecessary power consumption and signaling overhead.

[0026] In various embodiments, small data transmission ("SDT") is supported while the UE is in the RRC_INACTIVE state. In some embodiments, the UL small data transmission is accomplished using a RACH-based scheme (i.e., two-step and four-step random access procedures). In one embodiment, user plane ("UP") data transmission of small data packets from the RRC_INACTIVE state uses, for example, MsgA (i.e., for two-step random access procedures) or Msg3 (i.e., for four-step random access procedures).

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

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

[0029] The present disclosure addresses the following issues of small data transmission when the UE is in RRC_INACTIVE state:

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

[0031] Described herein is a solution for supporting small data transmission ("SDT") in RRC_INACTIVE state using CG-SDT resources. In various embodiments, the network configures the CG-SDT resources by using a configured grant configuration consisting of two periodicities. The UE considers only the first periodicity -- similar to legacy -- to determine the CG-SDT resources when in RRC_INACTIVE state and before starting an SDT session / procedure, i.e., the CG-SDT resources are used only for the first SDT message. When the SDT procedure is started, 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. The UE performs retransmission of the first SDT TB or any further subsequent SDT UL data / TB transmission on the subsequent CG-SDT resources.

[0032] By configuring multiple periodicities, the network does not need to configure multiple CG-SDT configurations for the UE to allocate multiple CG-PUSCH resources within a CG period, e.g., CG PUSCH resources for the first 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 transmission of the generated TB on the assigned uplink resource, e.g., the CG-SDT resource, when the transmission of the TB on the first CG-SDT resource of the SDT session has not been acknowledged by the gNB. 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. The TB that the UE skips due to no acknowledgement received from the gNB for the first CG-SDT transmission is kept pending in a hybrid automatic repeat request ("HARQ") buffer and is retransmitted autonomously by the UE once an acknowledgement is received from the gNB (i.e., 5G base station).

[0034] In some embodiments, the CG-SDT resource configuration is a type 1 configured grant configuration, but there is one additional periodicity in the CG-SDT configuration. The UE considers the first periodicity to determine the CG-SDT resources when in RRC_INACTIVE state and before starting an SDT session / procedure, i.e., the CG-SDT resources are used only for the first SDT message. When an SDT procedure is started, 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] FIG. 1 illustrates 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 be comprised of a base unit 121 with which the remote unit 105 communicates using a wireless communication link 123. Even though a certain number of remote units 105, base units 121, wireless communication links 123, RAN 120, and mobile core network 140 are illustrated in FIG. 1, one skilled in the art will appreciate that any number of remote units 105, base units 121, wireless communication links 123, RAN 120, and mobile core network 140 may be included in the wireless communication system 100.

[0036] In one implementation, the RAN 120 complies with a 5G cellular system defined in 3GPP® specifications. For example, the RAN 120 may be a Next Generation Radio Access Network ("NG-RAN") that implements a NR radio access technology ("RAT") and / or a Long Term Evolution ("LTE") RAT. In another example, the RAN 120 may include a non-3GPP RAT (e.g., a Wi-Fi® or a WLAN that complies with the Institute of Electrical and Electronics Engineers ("IEEE") 802.11 family). In another implementation, the RAN 120 complies with an LTE system defined in 3GPP® specifications. However, more broadly, the wireless communication system 100 may implement any other open or proprietary communication network, such as the Worldwide Interoperability for Microwave Access ("WiMAX") or IEEE 802.16 family of standards, among other networks. This disclosure is not intended to be limited to any particular wireless communications system architecture or protocol implementation.

[0037] In one embodiment, the remote unit 105 may include a computing device such as a desktop computer, a laptop computer, a personal digital assistant ("PDA"), a tablet computer, a smartphone, a smart television (e.g., a television connected to the Internet), a smart appliance (e.g., an appliance connected to the Internet), a set-top box, a game console, a security system (including security cameras), an in-vehicle computer, a network device (e.g., a router, a switch, a modem), etc. In some embodiments, the remote unit 105 includes a wearable device such as a smart watch, a fitness band, an optical head mounted display, etc. Additionally, the remote unit 105 may be referred to as a UE, a subscriber unit, a mobile phone, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a subscriber station, a user terminal, a wireless transmit / receive unit ("WTRU"), a device, or other terminology used in the art. In various embodiments, the remote unit 105 includes a subscriber identity and / or identification module ("SIM") and a mobile equipment ("ME") that provides mobile termination functions (e.g., radio transmission, handover, voice encoding and decoding, error detection and correction, signaling, and access to the SIM). In particular embodiments, the remote unit 105 may include terminal equipment ("TE") and / or may be incorporated into a home appliance or device (e.g., a computing device as described above).

[0038] The remote units 105 may communicate directly with one or more of the base units 121 in the RAN 120 by UL and DL communication signals. Furthermore, the UL and DL communication signals may be carried over a wireless communication link 123. Furthermore, the UL communication signals may include one or more uplink channels, such as a physical uplink control channel ("PUCCH") and / or a PUSCH, while the DL communication signals may include one or more DL channels, such as a physical downlink control channel ("PDCCH") and / or a physical downlink shared channel ("PDSCH"). Here, the RAN 120 is an intermediate network that provides the remote units 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 FIG. 1 ). Here, sidelink transmissions may occur on sidelink resources. The remote units 105 may be provided with different sidelink communication resources according to different allocation modes. As used herein, a “resource pool” refers to a set of resources allocated for sidelink operation. A resource pool consists of a set of resource blocks (i.e., physical resource blocks (“PRBs”)) over 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 PRBs that are contiguous 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 with the mobile core network 140. For example, an application 107 (e.g., a web browser, a media client, a telephone and / or a voice over Internet protocol ("VoIP") application) in the remote unit 105 may trigger the remote unit 105 to establish a protocol data unit ("PDU") session (or a 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 a user plane function ("UPF") 141. The mobile core network 140 then relays traffic between the remote unit 105 and the application server 151 in the packet data network 150 using the PDU session (or other data connection).

[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 "attached to the mobile core network" in the context of fourth generation ("4G") systems). It should be noted 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 5G systems ("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 particular data network ("DN") via the UPF 141. A PDU session supports one or more Quality of Service ("QoS") flows. In certain embodiments, there may be a one-to-one mapping 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 the Evolved Packet System ("EPS"), a PDN connection (also called an EPS session) provides an E2E UP connection between a remote unit and a PDN. The PDN connection procedure establishes an EPS bearer, i.e., a tunnel between the remote unit 105 and a PDN Gateway ("PGW" - not shown in FIG. 1) in the mobile core network 140. In certain embodiments, there is a one-to-one mapping between EPS bearers and QoS profiles, such that all packets belonging to a particular EPS bearer have the same QoS Class Identifier ("QCI").

[0044] The base units 121 may be distributed across a geographic region. In certain embodiments, the base units 121 may be referred to as an access terminal, an access point, a base, a base station, a Node B ("NB"), an evolved Node B (abbreviated as eNodeB or "eNB" and also known as an evolved Universal Terrestrial Radio Access Network ("E-UTRAN") Node B), a 5G / NR Node B ("gNB"), a home Node B, a relay node, a RAN node, or any other terminology used in the art. The base units 121 are generally part of a RAN, such as the RAN 120, which may include one or more controllers communicatively coupled to one or more corresponding base units 121. These and other elements of a radio access network are not shown, but are generally familiar to those skilled in the art. The base units 121 connect to a mobile core network 140 via the RAN 120.

[0045] The base unit 121 may serve multiple remote units 105 in a serving area, e.g., a cell or a sector of a cell, via wireless communication link 123. The base unit 121 may directly communicate with one or more of the remote units 105 by communication signals. In general, 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 on the wireless communication link 123. The wireless communication link 123 may be any suitable carrier in a licensed or unlicensed radio spectrum. 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] It should be noted that during NR operation over 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 over 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") that may be coupled to a packet data network 150, such as the Internet and private data networks, among other data networks. The remote units 105 may have a subscription or other account with the mobile core network 140. In various embodiments, each mobile core network 140 belongs to a single mobile network operator ("MNO") and / or public land mobile network ("PLMN"). This disclosure is not intended to be limited to any particular wireless communications system architecture or protocol implementation.

[0048] The mobile core network 140 includes several network functions ("NFs"). As shown, the mobile core network 140 includes at least one UPF 141. The mobile core network 140 also includes multiple 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"), that serve the RAN 120. In some embodiments, the UDM is co-located with the UDR and is shown as a combined entity "UDM / UDR" 149. Although a particular number and type of network functions are shown in FIG. 1, one skilled in the art will appreciate that any number and type of network functions may be included in the mobile core network 140.

[0049] The UPF 141 is responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU sessions for interconnecting data networks ("DNs") in the 5G architecture. The AMF 143 is responsible for non-access stratum ("NAS") signaling termination, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management. The SMF 145 is responsible for session management (i.e., session establishment, modification, release), remote unit (i.e., UE) Internet Protocol ("IP") address allocation and management, DL data notification, and traffic steering configuration of the UPF 141 for proper traffic routing.

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

[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 each other's appropriate services and communicate with each other via application programming interfaces ("APIs")), a Network Exposure Function ("NEF") (responsible for making network data and resources easily accessible to customers and network partners), an Authentication Server Function ("AUSF"), or other NFs defined for 5GC. When 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 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, each of which utilizes a particular network slice. Here, a "network slice" refers to a portion of the mobile core network 140 optimized for a particular traffic type or communication service. For example, one or more network slices may be optimized for enhanced mobile broadband ("eMBB") services. As another example, one or more network slices may be optimized for ultra-reliable low-latency communication ("URLLC") services. In other examples, a network slice may be optimized for machine type communication ("MTC") services, massive MTC ("mMTC") services, Internet of Things ("IoT") services. In still other examples, a network slice may be deployed for a particular application service, vertical service, a particular use case, or the like.

[0053] A network slice instance is specified by a single network slice selection assistance information ("S-NSSAI"), while a set of network slices that the remote unit 105 is authorized to use is specified by a network slice selection assistance information ("NSSAI"), where "NSSAI" refers to a vector value that includes one or more S-NSSAI values. In certain embodiments, various network slices may include separate instances of network functions, such as the SMF 145 and the UPF 141. In some embodiments, different network slices may share some common network functions, such as the AMF 143. For ease of illustration, different network slices are not shown in FIG. 1, but support for them is assumed.

[0054] To facilitate SDT procedures using CG resources, the base unit 121 may send an SDT configuration to the remote unit 105, and the remote unit 105 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 an RRC_CONNECTED state to perform uplink data transmission.

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

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

[0057] In the following description, the term "RAN node" is used for a base station / base unit, but it may be replaced by any other radio access node, e.g., 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 a mobile station / remote unit, but it may be replaced by any other remote device, e.g., remote unit, MS, ME, etc. Furthermore, the operation is mainly described 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] FIG. 2 illustrates an NR protocol stack 200 according to an embodiment of the present disclosure. FIG. 2 illustrates a UE 205, a RAN node 210, and an AMF 215 in a 5G core network ("5GC"), which are representative of a set of remote units 105 interacting with a base unit 121 and a 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 a PHY layer 220, a MAC sublayer 225, an RLC sublayer 230, and a PDCP sublayer 235. The control plane protocol stack 203 also includes an RRC layer 245 and a NAS layer 250.

[0059] The access stratum ("AS") layer 255 (also referred to as the "AS protocol stack") of the user plane protocol stack 201 is composed of at least the SDAP, PDCP, RLC, and MAC sublayers, and a physical layer. The AS layer 260 of the control plane protocol stack 203 is composed of at least the RRC, PDCP, RLC, MAC sublayers, and a physical layer. Layer 2 ("L2") is divided into the SDAP, PDCP, RLC, and MAC sublayers. Layer 3 ("L3") includes the RRC layer 245 and the NAS layer 250 of the control plane, including, for example, the IP layer and / or the 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 transport channels to the MAC sublayer 225. The PHY layer 220 may perform a beam failure detection procedure using an energy detection threshold. In a particular embodiment, the PHY layer 220 may send an indication of beam failure to the MAC entity of the MAC sublayer 225. The MAC sublayer 225 provides logical channels to the RLC sublayer 230. The RLC sublayer 230 provides RLC channels 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 between the UE 205 and the AMF 215 in the 5GC. NAS messages are passed transparently through the RAN. The NAS layer 250 is used to manage the establishment of communication sessions and maintain continuous communication with the UE 205 as the UE 205 moves between different cells of the RAN. In contrast, the AS layers 255 and 260 are between the UE 205 and the RAN (i.e., the RAN node 210) and carry information over the wireless part of the network. Although not shown in FIG. 2, an IP layer resides above the NAS layer 250, a transport layer resides above the IP layer, and an application layer resides above the transport layer.

[0062] The MAC sublayer 225 is the lowest sublayer of the L2 architecture of the NR protocol stack. The MAC sublayer 225's connection with the PHY layer 220 below is via transport channels, and its connection with the RLC sublayer 230 above is via logical channels. Thus, the MAC sublayer 225 performs multiplexing and demultiplexing between logical and transport channels, i.e., the MAC sublayer 225 on the transmitting side builds MAC PDUs (also known as transport blocks ("TBs")) from MAC service data units ("SDUs") received over logical channels, and the MAC sublayer 225 on the receiving side recovers MAC SDUs from MAC PDUs received over transport channels.

[0063] The MAC sublayer 225 provides data transfer services for the RLC sublayer 230 over logical channels that are either control logical channels carrying control data (e.g., RRC signaling) or traffic logical channels carrying user plane data. Data from the MAC sublayer 225 is in turn transferred to and from the PHY layer 220 over transport channels classified as UL or DL. Data is multiplexed into the transport channels depending on how it is transmitted over the air wirelessly.

[0064] The PHY layer 220 is responsible for the actual transmission of data and control information over the air interface, i.e., the PHY layer 220 carries all information from the MAC transport channel over the air interface on the transmit side. Some of the important functions performed by the PHY layer 220 include coding and modulation, link adaptation (e.g., Adaptive Modulation and Coding ("AMC")), power control, cell search and random access (for initial synchronization and handover purposes), and other measurements (within and between 3GPP systems (i.e., NR and / or LTE systems)) for the RRC layer 245. The PHY layer 220 performs transmission based on transmission parameters such as modulation scheme, coding rate (i.e., modulation and coding scheme ("MCS")), number of PRBs, etc.

[0065] For RACH-based SDT and CG-based SDT, when the UE 205 receives an RRC Release with Suspend configuration, the UE 205 performs at least the following actions: -MAC is reset and default MAC cell group configuration is released The RLC entity for Signaling Radio Bearer #1 ("SRB1") is re-established ·SRBs and DRBs are suspended except for signaling radio bearer #0 ("SRB0").

[0066] For both RACH-based SDT and CG-based SDT, upon initiation of the RESUME procedure for the start of an SDT (i.e., for the first / initial SDT transmission), the UE 205 re-establishes at least the SDT PDCP entity and resumes the SDT DRBs configured for small data transmission (together 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 contents (depending on the size of the message): CCCH Message (required) DRB data from one or more DRBs configured by the network for small data transmission (optional) MAC Control Element ("CE") - (e.g., Buffer Status Report ("BSR")) (optional) Padding bits (optional)

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

[0069] The existing Unified Access Control ("UAC") procedures for determining whether an access attempt is allowed for the RACH and CG are reused for the SDT.

[0070] SDT is transparent to the NAS layer (ie, the NAS generates one of the existing resume causes and the AS layer decides between SDT vs. non-SDT access).

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

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

[0073] For RACH based SDT, 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 of the C-RNTI is a common (i.e., shared) coreset / search space. In another embodiment, the coreset / search space of the C-RNTI is a dedicated coreset / search space.

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

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

[0076] The RRCRelease message includes a configuration of configured grant resources for uplink small data transmission of the UE 205. The configuration may be for type 1 CG only without contention resolution procedures for the CG.

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

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

[0079] The configured grant resource configuration for the UE 205 small data transmission is only valid within the same serving cell.

[0080] The UE 205 may use small data transfer based on the configured grant if at least the following criteria are met: (1) user data is less than a data volume threshold, (2) configured grant resources are configured and valid, and (3) the UE 205 has a valid TA.

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

[0082] The CG configuration mechanism of Rel-16 in licensed spectrum is reused as a baseline for CG-SDT. At least for the first transmission, we will have a mechanism to allow the UE 205 to transmit the message again. The UE 205 will use / select the same HARQ process for the retransmission.

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

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

[0085] The UE 205 may be allowed to start subsequent UL data transmissions only after receiving confirmation of the first transmission from the RAN node 210. The UE 205 may use multiple CG resources for the first transmission of HARQ in the subsequent CG transmission phase, similar to Rel-16.

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

[0087] 3 illustrates an example RRC resumption procedure 300. The procedure 300 involves the UE 205 (e.g., an instance of the Remote Unit 105), the RAN node 210 (e.g., an instance of the Base Unit 121), and the UPF 305 (e.g., an instance of the UPF 141). At the beginning of the procedure 300, the UE 205 is in an RRC_INACTIVE state (see block 310). It should be noted that the RRC state of the UE 205 is known to both the UE 205 and the RAN node 210.

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

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

[0090] In step 3, the UE 205 sends an RRCResumeComplete message to the RAN node 210 in response to transitioning to the RRC_CONNECTED state (see messaging 330). Optionally, the UE 205 sends one or more messages including 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 bearers used to transfer UL data.

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

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

[0094] As mentioned above, current 3GPP specifications require that a connection setup and subsequent release to the RRC_INACTIVE state occur for every data transmission, no matter how small and infrequent the data packets.

[0095] 4A illustrates an example small data transmission ("SDT") procedure 400 for a UE 205 in an RRC_INACTIVE state. The procedure 400 involves the UE 205 (e.g., an instance of the remote unit 105), the RAN node 210 (e.g., an instance of the base unit 121), and the UPF 305 (e.g., an instance of the UPF 141). At the beginning of the procedure 400, the UE 205 is in an RRC_INACTIVE state. The illustrated 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, the UE 205 decides to use RACH or CG resources for small data transmission in RRC_INACTIVE (see block 405). In step 1, the UE 205 sends a RRCResumeRequest with UL data (and NCC value) to the 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, the RAN node 210 forwards the UL data to the 5GC (i.e., the UPF 305) (see messaging 415). In optional step 3, the UPF 305 transmits DL data for the UE 205 to the RAN node 210 (see messaging 420).

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

[0099] 4B illustrates another example small data transmission ("SDT") procedure 430 for a UE 205 in an RRC_INACTIVE state. The procedure illustrated is based on random access channel ("RACH") resources configured for SDT. The procedure 430 involves the UE 205 (e.g., an instance of the remote unit 105) and the RAN node 210 (e.g., an instance of the base unit 121). At the beginning of the procedure 430, the UE 205 is in an RRC_CONNECTED state (see block 435).

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

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

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

[0103] In step 5, once the subsequent data transmission is completed, the RAN node 210 sends another RRCRelease message to the UE 205 (see messaging 470), also including the SDT configuration (and NCC values) for the RACH resources. Upon receiving the RRCRelease message, the UE 205 transitions to the RRC_INACTIVE state (see block 475), e.g., the UE 205 continues to remain in the RRC_INACTIVE state.

[0104] FIG. 5 illustrates an example procedure 500 for SDT resource selection, i.e., the UE 205 determines whether to use a CG-based SDT, a RACH-based SDT, or a non-SDT based on the amount of data and the RSRP value.

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

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

[0107] Upon selecting NUL, the UE 205 determines that RSRP is sufficient for CG operation and determines whether to use a CG-based procedure by determining whether the UE 205 has a valid TA for CG (see block 525). If so, the UE 205 uses the NUL's CG-based SDT procedure, e.g., as shown in FIG. 4A. If not, the UE 205 uses the NUL's RACH-based SDT procedure.

[0108] If the SDT procedure based on the NUL RACH is selected, the UE 205 determines whether to use the 2-step RACH procedure by comparing the RSRP to a 2-step threshold (see block 530). If yes, the UE 205 uses the SDT procedure based on the NUL 2-step RACH, e.g., as shown in FIG. 4B. If no, the UE 205 uses the SDT procedure based on the NUL 4-step RACH (see block 535).

[0109] However, if the SUL is selected, the UE 205 determines that the RSRP is sufficient for CG operation and determines whether to use a CG-based procedure by determining whether the UE 205 has a valid TA for CG (see block 540). If so, the UE 205 uses the SUL's CG-based SDT procedure, e.g., as shown in FIG. 4A. If not, the UE 205 uses the SUL's RACH-based SDT procedure.

[0110] If the SUL RACH-based SDT procedure is selected, the UE 205 determines whether to use the 2-step RACH procedure by comparing the RSRP to a 2-step threshold (see block 545). If yes, the UE 205 uses the SUL 2-step RACH-based SDT procedure, e.g., as shown in FIG. 4B. If no, the UE 205 uses the SUL 4-step RACH-based SDT procedure (see block 550). It should be noted that the UE 205 may have separate configurations for the NUL and SUL, and thus the thresholds used for the NUL CG and NUL 2-step determination may be different from the thresholds used for the SUL CG and SUL 2-step determination.

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

[0112] In some embodiments, the acknowledgement is by a HARQ Ack, an L2 Ack, or a new DL / UL allocation with a toggled 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., a RRCResumeRequest message.

[0113] According to the first solution, the UE 205 is only allowed to make a subsequent UL data transmission when the first uplink transmission of the SDT session on the first CG-SDT resource is confirmed / acknowledged by the RAN node 210, e.g., a response message confirming receipt of the first CG-SDT transmission, including, e.g., an RRCResumeRequest message.

[0114] According to one implementation of the first solution, TBs that the UE 205 skips due to no (or not yet received) confirmation from the RAN node 210 for the first CG-SDT transmission, e.g., the first UL transmission in an SDT session including at least an RRCResumeRequest message, are kept pending in the HARQ buffer and retransmitted autonomously by the UE 205 once confirmation is received from the RAN node 210. The "skipping" or "suppression" of subsequent uplink data until receipt of confirmation for the first SDT transmission, e.g., RRCResumeRequest, is performed in the UE 205 (e.g., in the MAC entity) similarly to the case of Listen-Before-Talk ("LBT") failure. The HARQ process may be set to "pending" in response to the skipping of the UL transmission of subsequent UL data due to no confirmation of the first SDT message / TB.

[0115] According to an embodiment of the second solution, the UE 205 is not allowed to generate a transport block for subsequent UL data unless a confirmation of the first SDT UL transmission, e.g., the first TB of the CG-SDT procedure, including an RRCResumeRequest message, has been received from the RAN node 210. In other words, the UE 205 may inhibit processing of the subsequent configured uplink grant allocated for small data transmission for the first new transmission of subsequent uplink data of the SDT procedure. For the case where the UE 205 has data available for transmission in its buffer (e.g., PDCP / RLC buffer), e.g., data of an SDT bearer, and UL resources, e.g., CG-SDT resources, allocated, the UE 205 does not perform an LCP procedure and does not generate a new TB, e.g., unless the first TB of the CG-SDT session, carrying an RRCResumeRequest message, has been confirmed by the RAN node 210. 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, e.g., a CG-SDT resource, is considered not valid for a new TB transmission (i.e., the first new transmission) unless the first TB has been acknowledged by the RAN node 210. Considering a PUSCH allocation (e.g., a CG-SDT resource) as not valid (invalid) means that the UE 205 ignores the PUSCH allocation and does not generate a TB for the PUSCH allocation, nor performs a UL (PUSCH) transmission corresponding to the PUSCH allocation.

[0117] According to another implementation of the second solution, the UE 205 ignores an UL grant / allocation, e.g., a dynamic UL grant conveyed in the downlink control information ("DCI"), unless a confirmation of receipt of the first TB of the corresponding CG-SDT session has been received from the RAN node 210. Ignoring the UL grant / allocation means that the UE 205 does not generate a TB for the UL grant / allocation, nor does it perform a UL (PUSCH) transmission corresponding to the PUSCH allocation.

[0118] According to an alternative implementation of the second solution, the UE 205 suspends all allocated PUSCH resources, e.g., CG-SDT resources, for the transmission of the new TB, as long as no confirmation has been received from the RAN node 210 for the first TB of the CG-SDT session (e.g., corresponding to an SDT procedure), i.e., as long as the RAN node 210 has not confirmed the reception of the first TB (e.g., an RRCResumeRequest message). Upon receiving a confirmation of the reception of the first TB, the UE 205 resumes or reinitializes all allocated PUSCH resources, e.g., CG-SDT resources. Thus, the UE 205 can use the CG-SDT resources or any other allocated PUSCH resources for the transmission of subsequent UL data, i.e., the new TB.

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

[0120] According to one embodiment, the confirmation of the TB containing the first SDT message, for example, a RRCResumeRequest message, may be one of the following: · PDCCH to schedule any first PDSCH transmission: If there is any DL data for the UE 205 (eg, in response to the first SDT message), the confirmation may be a PDCCH to schedule a PDSCH for the DL data. · PDCCH scheduling any first PUSCH transmission: If there is a BSR in the first UL message, the confirmation may be a PDCCH containing a grant for more UL data. PDSCH with RRCRelease message: If there is no subsequent DL or UL, the network may want to immediately terminate the SDT procedure (i.e. everything is completed). In such an embodiment, the DL response may be a RRCRelease scheduled using the PDCCH addressed to the C-RNTI. PDSCH with Timing Advance Command ("TAC"): If the network is waiting for DL ​​or (further) UL traffic and wants to keep the UE 205 in SDT for the time being (e.g. for the waiting time), the acknowledgement could be something simple like a TAC MAC Control Element ("CE") or similar addressed directly to the UE 205.

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

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

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

[0124] Configuring per LCH whether any autonomous retransmission capabilities are supported allows the network (e.g., RAN node 210 or 5GC) to control with finer granularity what kind of autonomous retransmission of data should be supported by the UE 205. For example, for SDT, the network (e.g., RAN node 210 or 5GC) can ensure through new LCH parameters that the 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 for 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 in one CG period. In one embodiment of the fourth solution, two periodicities are configured for the configured grant configuration used for SDT, i.e., CG-SDT. The configured grant for small data transmission in RRC_INACTIVE, i.e., CG-SDT, is based on the CG type 1 configuration defined in Rel-15 NR. Basically, the UL data transmission on the CG-SDT resource is based on RRC reconfiguration without any L1 signaling. The RRC provides the grant configuration to the UE 205 through the higher layer IE ConfiguredGrantConfig with the parameter rrc-ConfiguredUplinkGrant without detection of any UL grant in the DCI, e.g., there is no specific activation / release procedure. The CG-SDT resources are signaled to the UE 205, for example, in an RRCRelease message, i.e., sending the UE 205 to RRC_INACTIVE. In legacy NR, when CG type 1 is configured, the RRC configures the following parameters: ·cs-RNTI: This parameter indicates the CS-RNTI for retransmission. ·periodicity: This parameter indicates the periodicity of the CG type 1. · timeDomainOffset: This parameter indicates the offset of the resource relative to the System Frame Number ("SFN") = 0 in the time domain. · timeDomainAllocation: This parameter indicates the configured uplink grant allocation in the time domain that contains the 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 the RRC for CG-SDT resources. According to one implementation of the fourth solution, the first periodicity (existing periodicity) configures CG resources for the first SDT CG-PUSCH transmission of the SDT session, and the new second periodicity configures CG-SDT resources in the SDT session for, for example, subsequent UL data transmissions or retransmissions of the first SDT message / TB. It should be noted that there may be multiple subsequent CG-SDT PUSCH resources in an SDT procedure that can be used for subsequent UL data transmissions.

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

[0128] 7 illustrates a configured uplink grant configuration 700 that includes two periodicities. As shown in FIG. 7, there are multiple CG PUSCH resources configured within a first CG periodicity. The first periodicity (denoted as "P1") is between a contiguous set of CG-SDT resources, while the second periodicity (denoted as "P2") is between adjacent CG-SDT resources in the set. As shown, an SDT session begins with an SDT start and ends with an SDT release (e.g., including an RRCRelease message).

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

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

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

[0132] 8A-8B show an ASN.1 representation 800 of an example ConfiguredGrantConfig IE according to an embodiment of the present disclosure. The illustrated IE 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 FIG. 8B), which indicates the CG-SDT resources within an SDT session and corresponds to the second periodicity described above.

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

[0134] In one particular implementation, a new timer associated with an HARQ process is started or restarted upon transmission of a TB on a CG-SDT resource for that HARQ process.

[0135] In one implementation, the timer of an HARQ process is stopped upon receiving a PDCCH addressed to that HARQ process, eg, a PDCCH indicating a UL or DL ​​transmission.

[0136] In one particular implementation, the timer of a HARQ process is stopped upon receiving a PDCCH indicating a new first UL or DL ​​transmission for that HARQ process. When the timer associated with the HARQ process expires, the UE 205 performs some (autonomous) (re)transmission of the TBs reserved in the HARQ buffer. Autonomous (re)transmission refers to the case where the UE 205 performs a transmission of the TBs reserved in the HARQ buffer without receiving any explicit network signaling indicating to perform a transmission of the 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 a RRCResumeRequest message. By starting a new timer only for the first SDT transmission, it is ensured that the autonomous (re)transmission functionality is only supported for the first SDT TB / message and not for subsequent UL transmissions within the SDT session.

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

[0139] In some embodiments, the input devices 915 and the output devices 920 are combined into a single device, such as a touch screen. In certain embodiments, the user equipment device 900 may not include any input devices 915 and / or output devices 920. In various embodiments, the user equipment device 900 may include one or more of the processor 905, the memory 910, and the transceiver 925, and may not include the input devices 915 and / or the output devices 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 operable in an unlicensed spectrum. Further, 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 appreciated by those skilled in the art.

[0141] The processor 905, in one embodiment, may include any known controller capable of executing computer-readable instructions and / or performing 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 communicatively coupled to the memory 910, the input device 915, the output device 920, and the transceiver 925.

[0142] In various embodiments, the processor 905 controls the user equipment device 900 to implement the UE behaviors described above. In particular embodiments, the processor 905 may include an application processor (also known as a “main processor”) that manages application domains and operating system (“OS”) functions, and a baseband processor (also known as a “baseband radio processor”) that manages 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 a RAN node) allocating 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 an embodiment, the RRC release message includes the configuration allocating 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 semi-static (e.g., semi-persistent) allocation of uplink resources (e.g., CG type 1 resources for small data transmissions). As mentioned above, a small data transmission may include an amount of user data that is less than a data amount threshold.

[0145] Through the transceiver 925, the processor 905 transmits a first configured grant small data transmission of the SDT procedure to the network entity using a configured uplink grant for small data transmission. In some embodiments, the processor 905 causes the user equipment device 900 to transmit 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 comprises a message on the CCCH logical channel. In a particular embodiment, the first configured grant small data transmission comprises an RRC resume request message.

[0146] The processor 905 inhibits (e.g., skips) processing of a subsequent configured uplink grant assigned for a small data transmission for the first new transmission of subsequent uplink data of the SDT procedure. In some embodiments, the processor 905 inhibits processing of a configured uplink grant assigned for a small data transmission for the first new transmission of subsequent uplink data of the SDT procedure by causing the user equipment device 900 to refrain from performing an LCP procedure until a confirmation of the first configured grant small data transmission is received.

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

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

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

[0150] In some embodiments, the processor 905 causes the user equipment device 900 to A) maintain autonomous retransmission timers for HARQ processes having a HARQ process ID; B) start each autonomous retransmission timer in response to transmission of a first configured grant small data transmission by the device, where the first configured grant small data transmission is associated with the respective HARQ process ID; and C) stop each autonomous retransmission timer in response to receiving an acknowledgement of the first configured grant small data transmission by the device.

[0151] In some embodiments, in response to expiration of the respective autonomous retransmission timer prior to receiving confirmation of the first configured grant small data transmission, the processor 905 causes the user equipment device 900 to perform an autonomous retransmission of the first configured grant small data transmission. In a particular embodiment, the processor 905 causes the user equipment device 900 to perform a retransmission of the first configured grant SDT transmission with the same HARQ process (e.g., having the same HARQ process ID) in the next configured uplink grant assigned for the small data transmission.

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

[0153] Memory 910, in one embodiment, 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, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 910 includes both volatile and non-volatile computer storage media.

[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. described above. In particular embodiments, memory 910 also stores program code and associated data, such as an operating system or other controller algorithms running on user equipment device 900.

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

[0156] The output device 920, in one embodiment, 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 capable of outputting 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 similar display device capable of outputting images, text, and the like to a user. As another non-limiting example, the output device 920 may include a wearable display that is separate from but communicatively coupled to the remainder of the user equipment device 900, such as a smart watch, smart glasses, a head-up display, and the like. Additionally, the output device 920 may be a component of a smartphone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, and the like.

[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, movement, or other haptic feedback. In some embodiments, all or a portion 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-sensitive 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 communications network via one or more access networks. The transceiver 925 operates under the control of the processor 905 to transmit messages, data, and other signals and to receive messages, data, and other signals. For example, the processor 905 may selectively activate the transceiver 925 (or a portion thereof) at particular times to transmit and receive messages.

[0159] The transceiver 925 includes at least one transmitter 930 and at least one receiver 935. The one or more transmitters 930 may be used to provide UL communication signals, such as UL transmissions described herein, to the base unit 121. Similarly, the one or more receivers 935 may be used to receive DL communication signals from the base unit 121, as described herein. Although only one transmitter 930 and one receiver 935 are shown, the user equipment device 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 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.

[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, e.g., a single chip that performs functions for use in both the licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair 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, for example, 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 in a single hardware component, such as a multi-transceiver chip, a system-on-chip, an application specific integrated circuit ("ASIC"), or other type of hardware component. In particular embodiments, one or more transmitters 930 and / or one or more receivers 935 may be implemented and / or integrated in a multi-chip module. In some embodiments, other components, such as a network interface 940 or other hardware components / circuits, may be integrated in a single chip with any number of transmitters 930 and / or receivers 935. In such embodiments, the transmitters 930 and receivers 935 may be logically configured as a transceiver 925 using one or more common control signals, or as modular transmitters 930 and receivers 935 implemented in the same hardware chip or multi-chip module.

[0162] 10 illustrates 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 an implementation of one of the network endpoints, such as the base unit 121 and / or the RAN node 210 described above. Additionally, the network device 1000 may include a processor 1005, a memory 1010, an input device 1015, an output device 1020, and a transceiver 1025.

[0163] In some embodiments, the input device 1015 and the output device 1020 are combined into a single device, such as a touch screen. 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, the memory 1010, and the transceiver 1025, and may not include the input device 1015 and / or the 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. As will be appreciated by one skilled in the art, other network interfaces 1040 may be supported.

[0165] The processor 1005, in one embodiment, may include any known controller capable of executing computer-readable instructions and / or performing 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 the memory 1010 to perform the methods and routines described herein. The processor 1005 is communicatively coupled to the memory 1010, the input device 1015, the output device 1020, and the transceiver 1025.

[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 a “main processor”) that manages application domains and operating system (“OS”) functions, and a baseband processor (also known as a “baseband radio processor”) that manages radio functions.

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

[0168] In some embodiments, the first configured grant small data transmission is received while the communication device (e.g., UE) is in an RRC inactive state. In some embodiments, the first configured grant small data transmission includes a message on a CCCH logical channel. In a particular embodiment, the first configured grant small data transmission includes an RRC resume request message.

[0169] In some embodiments, the confirmation of the first configured grant small data transmission includes a PDCCH transmission addressed to the C-RNTI of the device. In a particular embodiment, the PDCCH transmission schedules the first PDSCH transmission. In another embodiment, the PDCCH transmission schedules the first PUSCH transmission in response to the first configured grant small data transmission including a buffer status report.

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

[0171] In a particular embodiment, the first configured grant small data transmission is associated with a respective HARQ process ID. In such an embodiment, the confirmation of the first configured grant small data transmission includes a PDCCH transmission addressed to the respective HARQ process. In one embodiment, the PDCCH transmission schedules the first PDSCH transmission of the respective HARQ process. In another embodiment, the PDCCH transmission schedules the first PUSCH transmission of the respective HARQ process.

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

[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. described above. In certain embodiments, memory 1010 also stores program code and associated data, such as an operating system or other controller algorithms running on network device 1000.

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

[0175] The output device 1020, in one embodiment, 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 capable of outputting visual data to a user. For example, the output device 1020 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, and the like to a user. As another non-limiting example, the output device 1020 may include a wearable display separate from but communicatively coupled to the rest of the network device 1000, such as a smart watch, smart glasses, a head-up display, and the like. Additionally, the output device 1020 may be a component of a smartphone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, and the like.

[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, movement, or other haptic feedback. In some embodiments, all or a portion 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-sensitive 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. The one or more transmitters 1030 may be used to communicate with a UE as described herein. Similarly, the one or more receivers 1035 may be used to communicate with a network function of a PLMN and / or a RAN as described herein. Although only one transmitter 1030 and one receiver 1035 are shown, the network device 1000 may have any suitable number of transmitters 1030 and receivers 1035. Moreover, the transmitters 1030 and receivers 1035 may be any suitable type of transmitter and receiver.

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

[0179] The method 1100 includes receiving 1105 a configuration from a network entity (e.g., a gNB and / or a RAN node) allocating a configured uplink grant for small data transmission. The method 1100 includes transmitting 1110 a first configured grant small data transmission of an SDT procedure to the network entity using the configured uplink grant for small data transmission. The method 1100 includes 1115 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. The method 1100 includes receiving 1120 a confirmation of the first configured grant small data transmission from the network entity. The method 1100 includes 1125 a process 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 in response to receiving the confirmation of the first configured grant small data transmission.

[0180] Disclosed herein is a first apparatus for an SDT procedure using CG resources according to an embodiment of the present disclosure. The first apparatus may be implemented by a communication device such as the remote unit 105, UE 205, and / or user equipment device 900 described above. The first apparatus includes a processor coupled to a memory, and the processor is configured to cause the apparatus to: A) receive a configuration from a network entity (e.g., a gNB and / or a RAN node) allocating a configured uplink grant for small data transmission; B) transmit a first configured grant small data transmission of the SDT procedure to the network entity using the configured uplink grant for small data transmission; C) inhibit 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; D) receive a confirmation of the first configured grant small data transmission from the network entity; and E) process the subsequent configured uplink grant allocated for a small data transmission for a first new transmission of subsequent uplink data of the SDT procedure in response to receiving the 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 of the SDT procedure, and B) transmit the TB using a subsequent configured uplink grant assigned for small data transmission. In some embodiments, the processor is configured to cause the device to transmit a first configured grant small data transmission while the device is in an RRC inactive state (e.g., RRC_INACTIVE).

[0182] In some embodiments, the first configured grant small data transmission comprises a CCCH message. In certain embodiments, the first configured grant small data transmission comprises an RRC Resume Request message.

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

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

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

[0186] In some embodiments, to inhibit processing of a configured uplink grant allocated for small data transmission for a first new transmission of subsequent uplink data of an SDT procedure, the processor is configured to cause the device to consider a PUSCH allocation for the new TB as invalid until a 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 a HARQ process having a HARQ process ID; B) start each autonomous retransmission timer in response to transmission of a first configured grant small data transmission by the device, where the first configured grant small data transmission is associated with the respective HARQ process ID; and C) stop each autonomous retransmission timer in response to receiving an acknowledgement of the first configured grant small data transmission by the device.

[0188] In some embodiments, in response to expiration of a respective autonomous retransmission timer prior to receiving a confirmation of the first configured grant small data transmission, the processor is configured to cause the device to perform an autonomous retransmission of the first configured grant small data transmission. In a particular embodiment, the processor is configured to cause the device to perform a retransmission of the first configured grant SDT transmission with the same HARQ process (e.g., having the same HARQ process ID) in a next configured uplink grant allocated for the small data transmission.

[0189] In some embodiments, the confirmation of the first configured grant small data transmission includes a PDCCH transmission for the respective HARQ process. In a particular embodiment, the PDCCH transmission schedules the first PDSCH transmission and / or the first PUSCH transmission for the respective HARQ process. In some embodiments, the processor is configured to cause the device to start a respective autonomous retransmission timer only for the first configured grant small data transmission and not for subsequent transmissions of the SDT procedure.

[0190] Disclosed herein is a first method for an SDT procedure using CG resources according to an embodiment 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 receiving a configuration from a network entity (e.g., a gNB and / or a RAN node) allocating a configured uplink grant for small data transmission, and transmitting a first configured grant small data transmission of a small data transmission ("SDT") procedure to the network entity using the configured uplink grant for small data transmission. The first method includes 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. The first method includes receiving a confirmation of the first configured grant small data transmission from the network entity, and processing the subsequent configured uplink grant allocated for a small data transmission for a first new transmission of subsequent uplink data of the SDT procedure in response to receiving the confirmation of the first configured grant small data transmission.

[0191] In some embodiments, the first method further includes generating a TB for subsequent uplink data of the SDT procedure and transmitting the TB using a subsequent configured uplink grant allocated for the 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 first configured grant small data transmission comprises a CCCH message. In certain embodiments, the first configured grant small data transmission comprises an RRC Resume Request message.

[0193] In some embodiments, the confirmation of the first configured grant small data transmission includes a PDCCH transmission addressed to the C-RNTI of the device. In a particular embodiment, the PDCCH transmission schedules the first PDSCH transmission. In another embodiment, the PDCCH transmission schedules the first PUSCH transmission in response to the first configured grant small data transmission including a buffer status report.

[0194] In some embodiments, receiving the configuration includes receiving an RRC release message, the RRC release message including a configuration allocating a configured uplink grant for small data transmission.

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

[0196] In some embodiments, the step of inhibiting processing of a configured uplink grant allocated for small data transmission for a first new transmission of subsequent uplink data of an SDT procedure includes considering a PUSCH allocation for the new TB as invalid until a confirmation of the first configured grant small data transmission is received.

[0197] In some embodiments, the first method further includes maintaining autonomous retransmission timers for HARQ processes having a HARQ process ID; starting the respective autonomous retransmission timers in response to transmission of a first configured grant small data transmission by the device, the first configured grant small data transmission being associated with the respective HARQ process ID; and stopping the respective autonomous retransmission timers in response to receiving a confirmation of the first configured grant small data transmission by the device.

[0198] In some embodiments, in response to expiration of the respective autonomous retransmission timer prior to receiving a confirmation of the first configured grant small data transmission, the first method further includes 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 using the same HARQ process (e.g., having the same HARQ process ID) in the next configured uplink grant allocated for the small data transmission.

[0199] In some embodiments, the confirmation of the first configured grant small data transmission includes a PDCCH transmission for the respective HARQ process. In one embodiment, the PDCCH transmission schedules the first PDSCH transmission for the respective HARQ process. In another embodiment, the PDCCH transmission schedules the first PUSCH transmission for the respective HARQ process. In some embodiments, the respective autonomous retransmission timers are started only for the first configured grant small data transmission and are not started for subsequent transmissions of the SDT procedure.

[0200] The embodiments may be embodied in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is therefore indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope. [Explanation of symbols]

[0201] 100 Wireless communication system 105 Remote Unit 107 Applications 120 Radio Access Network, RAN 121 Base Unit 123 Wireless Communication Links 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 RAN nodes 215 AMF 220 Physical (PHY) Layer 225 MAC Sublayer 230 Radio Link Control (RLC) Sublayer 235 PDCP Sublayer 240 Service Data Adaptation Protocol (SDAP) Layer 245 RRC Layer 250 NAS Layer 255 Access Layer (AS) 260 AS Layer 300 RRC Restart Procedure 305 UPF 400 SDT Procedures 430 SDT Procedure SDT Procedure Based on 450 RACH 500 Example procedure for the selection of SDT resources 505 NF Consumer 600 ASN.1 Representation of an Exemplary IE LogicalChannelConfig 700 Configured Uplink Grant Configuration 800 ASN.1 Representation of an Exemplary ConfiguredGrantConfig IE 900 User Equipment Device 905 Processor 910 Memory 915 Input Devices 920 Output Device 925 Transceiver 1000 Network Devices 1005 Processor 1010 Memory 1025 Transceiver 1100 methods

Claims

1. A user equipment (UE) for wireless communications, comprising: At least one memory; and at least one processor coupled to the at least one memory, the at least one processor causing the UE to: receiving a configuration to allocate resources using a configured uplink grant for small data transmission (SDT); transmitting a first data transmission of the SDT procedure using a configured uplink grant for SDT; Suppressing processing of a subsequent configured uplink grant allocated for an SDT procedure, the subsequent configured uplink grant being associated with a first new transmission of subsequent uplink data of the SDT procedure; receiving a confirmation of said initial data transmission; and and processing the subsequent configured uplink grant in response to the received confirmation of the initial data transmission.

2. The at least one processor, in the UE, generating a transport block (TB) for the subsequent uplink data of the SDT procedure; 2. The UE of claim 1, further configured to: transmit the TB using the subsequent configured uplink grant allocated for an SDT.

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

4. The UE of claim 3, wherein the first data transmission includes a radio resource control (RRC) resume request message.

5. The UE of claim 1, wherein the confirmation of the first data transmission includes a Physical Downlink Control Channel (PDCCH) transmission addressed to a Cell-Specific Radio Network Temporary Identifier (C-RNTI) of the UE.

6. 6. The UE of claim 5, wherein the PDCCH transmission schedules a first physical downlink shared channel (PDSCH) transmission or schedules a first physical uplink shared channel (PUSCH) transmission.

7. The UE of claim 1, wherein the at least one processor is configured to cause the UE to transmit the first data transmission while the UE is in a radio resource control (RRC) inactive state.

8. 10. The UE of claim 1, wherein 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 including the configuration.

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

10. 2. The UE of claim 1, wherein the at least one processor is configured to cause the UE to consider a physical uplink shared channel (PUSCH) allocation for a new TB as invalid until a confirmation of the first data transmission is received, to inhibit processing of the configured uplink grant assigned for SDT for the first new transmission of the subsequent uplink data of the SDT procedure.

11. The at least one processor, in the UE, maintaining an autonomous retransmission timer for a hybrid automatic repeat request (HARQ) process having a HARQ process identifier (ID); starting a respective autonomous retransmission timer in response to the first data transmission, the first data transmission being associated with a respective HARQ process ID; 2. The UE of claim 1, configured to: stop the respective autonomous retransmission timer in response to the confirmation of the first data transmission.

12. The UE described in Claim 11, wherein the at least one processor is configured to cause the UE to perform an autonomous retransmission of the initial data transmission in response to expiration of a respective autonomous retransmission timer prior to receiving the confirmation of the initial data transmission.

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

14. The UE of claim 11, wherein the at least one processor is configured to cause the UE to start a respective autonomous retransmission timer only for the first data transmission and not for subsequent transmissions of the SDT procedure.

15. 1. A method for a user equipment (UE), comprising: receiving a configuration to allocate resources using a configured uplink grant for small data transmission (SDT); transmitting a first data transmission of the SDT procedure using a configured uplink grant for SDT; inhibiting processing of a subsequent configured uplink grant allocated for an SDT procedure, the subsequent configured uplink grant being associated with a first new transmission of uplink data following the SDT procedure; receiving a confirmation of said initial data transmission; and processing the subsequent configured uplink grant in response to the received confirmation of the initial data transmission. generating a transport block (TB) for the subsequent uplink data of the SDT procedure; transmitting the TB using the subsequent configured uplink grant allocated for an SDT; 16. The method of claim 15, further comprising:

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

18. The method of claim 15, wherein the confirmation of the first data transmission includes a Physical Downlink Control Channel (PDCCH) transmission addressed to a Cell-Specific Radio Network Temporary Identifier (C-RNTI).

19. A base station for wireless communications, comprising: At least one memory; and at least one processor coupled to the at least one memory, the at least one processor providing to the base station: transmitting a configuration to allocate resources using a configured uplink grant for small data transmission (SDT); receiving a first data transmission of an SDT procedure using a configured uplink grant for SDT, where a subsequent configured uplink grant allocated for SDT is suppressed and the subsequent configured uplink grant is associated with a first new transmission of subsequent uplink data of the SDT procedure; transmitting a confirmation of the initial data transmission, wherein the subsequent configured uplink grant is processed in response to the transmitted confirmation of the initial data transmission; An apparatus configured to:

20. A method performed by a base station, comprising: transmitting a configuration to allocate resources using a configured uplink grant for small data transmission (SDT); receiving a first data transmission of an SDT procedure using a configured uplink grant for SDT, where a subsequent configured uplink grant allocated for SDT is suppressed and the subsequent configured uplink grant is associated with a first new transmission of subsequent uplink data of the SDT procedure; transmitting a confirmation of the initial data transmission, wherein the subsequent configured uplink grant is processed in response to the transmitted confirmation of the initial data transmission; A method comprising:

Images