Indication of small data transmission

Abstract

The invention relates in particular to a user equipment comprising means configured to: transmit, in a non-connected state, first data to a network in a small data transmission procedure; and transmit, in the non-connected state, an indication of a transmission of second data to the network during the small data transmission procedure, the second data becoming available for transmission after the first data is transmitted.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to, but is not limited to, communication networks such as defined by the 3GPP standards, in particular communication networks defined by the 5G standards (also referred to as New Radio, NR). More specifically, the present disclosure relates to mechanisms for small data transmission (so-called small data transmission, SDT) in an inactive state such as the RRC inactive state. BACKGROUND

[0002] Basically, three methods can be identified for small data transmission (SDT) of uplink user plane data in the radio resource control (RRC) inactive state of the 5G NR system.

[0003] One method can be a 4-step random access channel (RACH) based SDT. In this method, the user plane (UP) data is transmitted in the message 3 (Msg3) of the 4-step RACH procedure. Specifically, the small payload is multiplexed with e.g. a RRC connection resume request. This method is illustrated in Figure 2a .

[0004] Another method can be a 2-step RACH based SDT. In this method, the UP data transmission occurs with the message A (MsgA) of the 2-step RACH procedure and more specifically on a physical uplink shared channel (PUSCH) resource pre-configured by the base station (gNB) and using the associated physical transmission parameters broadcasted as system information. This method is illustrated in Figure 2b .

[0005] Another method can be a configured grant based SDT. In this case, a UE in RRC connected state can receive a CG configuration, e.g. a CG configuration type 1, indicating a specific pre-configured PUSCH resource to be used for UL data transmission in the RRC inactive state as long as the associated validity conditions are fulfilled, e.g. timing alignment is valid. This method is illustrated in Figure 2c .

[0006] The methods of Fig. 2 assume an RRC based approach. It requires the user equipment (UE) to send an RRC message including information about the UE identity and its authentication token (i.e. MAC-I). In the methods illustrated in Fig. 2, the RRC resume request message is used for this purpose. Figure 3An exemplary content of the corresponding UL MAC PDU, i.e. the UL MAC DU for CG-based SDT transmission based on RRC method or SDT Msg3 / MsgA is shown. In contrast, the non-RRC method would assume that the RRC layer does not need to be involved in the SDT operation and the necessary information such as UE identity and / or UE authentication token would be provided by the UE, e.g. in the MAC header or as MAC control element (MAC CE). Typically, both methods can be used. While the RRC-based method is assumed as baseline, the non-RRC method is considered for more limited use cases (e.g. same serving cell and / or CG). In order to decide whether to perform SDT at all or rather a legacy recovery procedure, a data volume threshold can be used for the UE.

[0007] It is desirable that multiple small data transmissions (i.e. multi-shot SDT) can be made within a single SDT procedure, which means that multiple UL and / or DL small data transmissions (SDT transmissions) are sent after the first UL SDT without transitioning the UE to the RRC connected state. However, there is a problem that additional data can become available in the UE buffer only after the UE has sent the first SDT transmission. In this case, the UE cannot indicate the presence of the additional data to the network but needs to initiate a new SDT procedure after the ongoing SDT procedure ends. This is inefficient as it leads to e.g. PRACH preamble resource inefficiency and can increase the PRACH collision probability. Furthermore, when the SDT is conducted in a new serving gNB (different from the last serving gNB), the UE context retrieval procedure has to be triggered after the network receives the first SDT transmission (i.e. after the reception of e.g. Msg3 / MsgA) and thus, a significant delay can be encountered before the UE receives the network response (MsgB / Msg4) that ends the SDT transaction. The likelihood of new data becoming available at the UE buffer depends on and increases with this delay, which is a function of the Xn latency (two-way Xn latency plus network processing delay) and can be up to 20-30 ms. This scenario is illustrated in Figure 4

[0008] Furthermore, the network can not necessarily send the RRC release message in the same MAC payload with contention resolution, e.g. due to waiting to see if DL data arrives (including application level feedback to the UL SDT) or waiting for the UE context to be retrieved.

[0009] ​Furthermore, although the UE can receive an additional resource configuration for transmitting further small data (i.e. the network can configure a dedicated preconfigured PUSCH resource, such as a configured grant, and an RRC release message (MsgB / Msg4)), this only allows for resource allocation after the UE has received the RRC release message that has terminated the ongoing small data transmission. Thus, the UE would need to repeat the complete SDT procedure, resulting in potential signaling inefficiencies. SUMMARY

[0010] Certain embodiments can have the effect that a user equipment is able to transmit an indication for new data during an ongoing small data transmission procedure and potentially also the corresponding new data during the same ongoing small data transmission procedure, avoiding resource inefficiencies, additional packet delay, and additional power consumption.

[0011] According to a first exemplary aspect, a user equipment is disclosed, the user equipment comprising means that can be configured to transmit first data to a network in a small data transmission procedure in a non-connected state. The user equipment can further be configured to transmit an indication for a transmission of second data to the network during the small data transmission procedure in the non-connected state. The second data can only become available for transmission after the first data has been transmitted.

[0012] According to the first exemplary aspect, a method performed at least by a user equipment is further disclosed. The method can comprise transmitting first data to a network in a small data transmission procedure in a non-connected state. The method can further comprise transmitting an indication for a transmission of second data to the network during the small data transmission procedure. The second data can only become available for transmission after the first data has been transmitted.

[0013] According to a second exemplary aspect, a network entity is disclosed, the network entity comprising means that can be configured to receive first data from a user equipment in a non-connected state in a small data transmission procedure. The network entity can further be configured to transmit a resource configuration to the user equipment related to a transmission of an indication of second data and / or a transmission of the second data to occur during the small data transmission procedure. The network entity can further be configured to receive the indication for a transmission of the second data from the user equipment in the non-connected state during the small data transmission procedure.

[0014] According to a second exemplary aspect, also a method performed at least by a network entity is disclosed. The method can comprise receiving first data from a user equipment in a non-connected state during a small data transmission procedure. The method can comprise transmitting, to the user equipment, a resource configuration related to transmission of an indication of second data to occur during the small data transmission procedure and / or transmission of the second data. The method can further comprise receiving, from the user equipment in the non-connected state during the small data transmission procedure, the indication of the transmission of the second data.

[0015] The user equipment (UE) of the first exemplary aspect can be an electronic device such as a mobile device or mobile station. The user equipment can in particular be a device such as a smartphone, a tablet, a wearable device, a smartwatch, etc. The user equipment can also be an IoT device (e.g., a sensor device, a smart home device, etc.) and in particular can be a low-power or battery-powered device. Such devices often need to transmit small amounts of data on a regular basis, and the methods described herein are therefore particularly advantageous. The user equipment can be understood as any device that is directly used by an end user for communicating with a network. However, the device can also operate autonomously and communicate with the network. The mobile device of the second exemplary aspect can communicate directly or indirectly with the network entity of the first exemplary aspect.

[0016] The network entity of the second exemplary aspect can be an electronic device such as an entity of a core network or a radio access network of a communication system. For example, the network entity can be or can comprise a base station (e.g., a gNodeB or gNB) or communicate with a base station. In this regard, as will be explained in more detail below, the network entity can be a last serving (or anchor) base station or a new serving base station. In general, the network entity can be a hardware or software component that implements a particular functionality. In one example, the network entity can be a network entity defined by the 3GPP 5G standards. While the network entity can be understood to be implemented in a single device or module or be a single device or module, the network entity can also be implemented across or comprise multiple devices or modules. As such, the network entity can in particular be implemented in or be a fixed device. The network entities of the first exemplary aspect can in particular establish a communication system or network, which can in particular be a New Radio (NR) or 5G system or any other mobile communication system defined by past or future standards, in particular successors of the current 3GPP standards. The network entities of the first exemplary aspect can communicate directly or indirectly with the mobile device of the second exemplary aspect.

[0017] The components of any of the disclosed apparatuses (user equipment and network entity) can be implemented in hardware and / or software. They can comprise, for example, at least one processor for executing computer program code for performing the desired functions, at least one memory for storing the program code, or both. Alternatively, they can comprise, for example, circuitry designed to implement the required functionality, for example, implemented in a chipset or a chip, such as an integrated circuit. Generally, the components can comprise, for example, one or more processing components or processors.

[0018] According to the respective example aspects of the present disclosure, therefore, also a respective apparatus (i.e., network entity and user equipment device) is disclosed, the apparatus comprising at least one processor and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform and / or control the method according to the respective example aspects of the present disclosure.

[0019] Any of the above-disclosed apparatuses can be a module or component for a device (e.g., a chip). The disclosed apparatuses can comprise the disclosed components, e.g., components, processors, memories, or can also comprise one or more additional components.

[0020] The methods of the respective aspects can, for example, be performed and / or controlled by the apparatuses according to the respective aspects (i.e., network entity or mobile device), respectively. Generally, however, the respective methods can also be performed and / or controlled by more than one apparatus. For example, the method according to the second example aspect can be performed by multiple network entities.

[0021] Further, it is to be considered that a combination of the first method and the second method is also disclosed, which is subsequently performed by the user equipment and one or more network entities together. Likewise, a system of a user equipment of the first example aspect and a network entity of the second example aspect working together to perform aspects of the present disclosure is also disclosed.

[0022] According to the first and second example aspects of the present disclosure, in each case, also a computer program is disclosed, which, when executed by a processor of an apparatus, causes the apparatus to perform the method according to the first and second aspects, respectively.

[0023] The computer program can be stored on a computer-readable storage medium, in particular on a tangible and / or non-transitory medium. The computer-readable storage medium can be, for example, a disk or a memory, etc. The computer program can be stored in the computer-readable storage medium in the form of instructions encoding the computer-readable storage medium. The computer-readable storage medium can be used for participating in the operation of a device, like an internal or external memory of a computer, for example, a read-only memory (ROM) or a hard disk of the computer, or for the distribution of programs, like an optical disc.

[0024] In the following, further exemplary features and exemplary embodiments of different aspects of the present disclosure will be described in more detail.

[0025] The non-connected state can be a state without or without providing full communication functionality but still maintaining some kind of limited functionality. In one example, the non-connected state can be an idle state (e.g. RRC idle). For example, the non-connected state can be an inactive state (e.g. RRC inactive). Therein, the user equipment does not need to fully release the respective radio connection (often referred to as idle state), but also does not need to fully maintain the respective connection (often also referred to as connected state). From the non-connected state, in particular from the inactive state, the user equipment can quickly return to the connected state. However, in the presently described approach, it is preferred that the user equipment does not leave the non-connected state for data transmission. Instead, the user equipment can stay in the non-connected state without fully returning to the connected state and still be able to transmit a certain amount of data to the network. Unless the network indicates to return to the connected state, e.g. because the data to be transmitted is too large, which will be explained in more detail below.

[0026] In particular, the inactive state (compared to the connected or idle state) can be characterized by one or more of the following features. For example, when the UE moves from the connected state to the inactive state, context information can be maintained by the UE and the network. For example, the RAN / CN connection can be kept, which can reduce state transition latency and signaling overhead over the RAN / CN interface. For example, the UE access stratum context (e.g. AS security context and DRB / SRB configuration) can be stored in the UE and the RAN. This can allow to reduce state transition latency and signaling overhead over the air interface upon resumption. For example, the UE mobility can be based on autonomous cell reselection, wherein the UE can move within its tracking area or the like (e.g. RAN notification area) without updating its location to the network. This can allow for lower UE power and network resource consumption compared to network-controlled mobility. For example, paging can be used to reach the UE. For example, the UE behavior in the inactive state can be configured based on requirements of the applications running in the UE.

[0027] For example, the user equipment can acquire information (such as suspendConfig) together with the (first) connection release message that indicates or allows the UE to enter the non-connected state (instead of the idle or disconnected state) and provides the required configuration for the non-connected state. This configuration can then be applied, resulting in the UE entering the non-connected state.

[0028] The first data (which can be referred to as first small data in particular) is transmitted by the UE in a small data transmission in a small data transmission procedure. The network entity receives the first data. The data of the small data transmission can also be referred to as small data. The first data can preferably be transmitted in a single message. For example, the data is sent together with or multiplexed with another information / message, such as a resume request. In case of RACH-based SDT, the small data transmission procedure can be considered to start with the user equipment initiating a random access procedure. For example, the small data transmission procedure can start with Msgl or MsgA of a four-step and two-step RACH procedure, respectively. For example, the small data transmission procedure can start with the UE transmitting a RACH preamble to the network. For example, the small data transmission procedure can start with a CG-based PUSCH transmission. The small data transmission procedure can end with the network sending a (second) message (e.g. a release message indicating the UE to return to the non-connected state, for example). However, for example, the second message can also indicate the UE to return to the connected state. In the methods described herein, the user equipment will remain in the non-connected state during the data transmission of the first data and during the whole small data transmission procedure, and preferably, it will be able to transmit second data during the small data procedure and will also preferably return to the non-connected state.

[0029] The UE transmits an indication to the network for the transmission of second data (also referred to as additional or further data in the following). The network receives the indication for the transmission of the second data. For example, the indication can be considered as an indication of the presence or anticipation of additional data that needs to be transmitted by the UE. The indication can indicate that the second data (i.e. data in addition to the already transmitted first data) is already present available at the UE (e.g. in a buffer of the UE). Alternatively, the indication can also indicate that the second data is anticipated, but not yet available in the buffer of the UE, for example. For example, with the indication, the UE can indicate that it also desires to transmit the second data in the non-connected state and / or during the ongoing small data transmission procedure. In one example, the indication can be considered as an indication for requesting resources (to the network) for the transmission of the second data. In one example, the indication can only indicate that the second data is available or should be transmitted, which can be implemented in its simplest form by providing a one-bit information field. However, the indication can also comprise further information. For example, the indication can also indicate the (known or anticipated) size of the second data. As will be further explained below, the described indication can be implemented by a scheduling request or a buffer status report.

[0030] The indication is understood to be transmitted during the small data transmission procedure as meaning that the indication is transmitted before the completion of the small data transmission procedure. As mentioned above, this is in particular understood to mean that the indication is transmitted before the (second) message that is considered to end the small data transmission procedure is received by the UE. As mentioned above, the UE can still be in the non-connected state when transmitting the indication.

[0031] The indication can also be an indication for the transmission of even further data (e.g. third data, fourth data, etc.). For example, the UE can also repeatedly transmit the indication during the above-described small data transmission procedure in the non-connected state (e.g. because data to be sent repeatedly arrives in the buffer of the UE), resulting in multiple indications during a single small data transmission procedure.

[0032] When the indication is received at the network, this will allow the network to still provide resources for the transmission of the second data and / or to monitor the resources already provided (as will be described in more detail below) during the same small data transmission procedure.

[0033] The described approach thus provides the UE with means to indicate the presence of new data during an ongoing small data transmission procedure and thus also enables the UE to send the respective new data during the same ongoing small data transmission procedure to avoid resource inefficiencies and additional packet delays. The present disclosure recognizes that it is advantageous to allow indications such as scheduling requests in the non-connected state during an ongoing small data transmission procedure, even though scheduling requests are originally defined in the RRC connected state only and are considered neither applicable to UEs in the RRC non-connected state nor to UEs in the idle state, for example.

[0034] As mentioned above, while the (PUSCH) resource configuration can for example be contained in the release message transmitted in the MsgB or Msg4. However, this would result in resources being allocated only after the UE has indicated the presence of further data in the first SDT transmission carrying the first data and received the RRC release message and thus terminated the small data transmission. In contrast, the present approach allows for new data generated or becoming available within a time interval after the first SDT transmission carrying the first data (i.e. between the initial transmission of the SDT payload (e.g. Msg3 in the 4-step RACH procedure or MsgA in the 2-step RACH procedure) and the reception of the second message from the network that will end the SDT procedure), wherein additional SDT data can be generated at the UE according to the duration of the small data transmission procedure.

[0035] While the described approach can be applicable to different layers, connections and protocols, in one example, the protocol used for the above-described communication between the UE and the network is the RRC protocol. The non-connected state is thus the RRC non-connected state.

[0036] Thus, the (first, second, etc.) data transmitted in a small data transmission procedure can be considered small data. For example, such (first, second, etc.) data of a small data transmission can be considered small in particular when reaching the order of kilobytes. For example, data can be considered small for reaching several kilobytes, such as reaching 10 kilobytes, 8 kilobytes, 1 kilobyte or 0.5 kilobyte or 50 kilobytes. However, if data is transmitted in multiple SDTs with one SDT procedure, there can be larger amounts of data, while the number of transmissions in a single SDT procedure can again be limited.

[0037] The first and / or second data can be user plane data in particular. For example, the data can originate from an application layer. For example, the data can be sensor data of an loT device (which typically requires transmission of small amounts of data) or background / keep-alive traffic of a smartphone, to name a few non-limiting examples. In one example, the first and / or second data is control plane data, in particular a RAN notification area update.

[0038] As will be explained in more detail below, the first and / or second (and potentially further) data can be transmitted in a two-step or four-step RACH procedure. Alternatively, a CG-based procedure can also be used, i.e. the first and / or second (and potentially further) data can in particular be transmitted in a CG-based PUSCH transmission.

[0039] The network of the first aspect comprises at least a network entity, e.g. the network entity of the second aspect. The network can in particular comprise the last serving base station and / or the new serving base station, which will be explained in more detail below.

[0040] As already mentioned, the second data can only become available for transmission after the first data has been transmitted. For example, the UE can be informed or regularly check whether there is any new data available in the buffer. The above-described approach can advantageously handle such a case, as the UE can now indicate for the expected data transmission, or can have transmitted an indication, thereby informing the network and allowing at least the second data transmission during the ongoing small data transmission procedure.

[0041] In one example, the indication requesting the transmission of the second data is transmitted prior to receiving the (second) message (e.g. release message) from the network. The second release message can be considered as ending the small data transmission procedure. Thus, the UE should transmit the indication to the network prior to such a release message being received.

[0042] Additionally or alternatively, the indication for the transmission of the second data can only be transmitted after the transmission of the first data. This can in particular be the case when additional data becomes available only after the transmission of the first data and / or if such additional data is not expected.

[0043] In one example, the indication for the transmission of the second data is transmitted after receiving a first contention resolution message, which can be considered as Msg4 for a four-step RACH procedure or as MsgB for a two-step RACH procedure, which can be received in response to the transmission of the PRACH preamble and the first data. The network can only send a contention resolution message, i.e. not at the same time or in the same MAC payload a release message, which can be due to the network waiting to see if DL data arrives (including application level feedback to UL SDT) and / or the network waiting for the UE context to be retrieved.

[0044] Alternatively, in another example, the indication for the transmission of the second data is transmitted as part of the message comprising the first data. For example, the UE can expect additional data, however, which is not yet available for transmission at the time of transmitting the first data. Thus, the indication for the transmission of the second data indicating that more data is expected can already be provided with the first data, in particular as part of the message comprising the first data.

[0045] In one example, the indication for the transmission of the second data is a scheduling request, or comprises a scheduling request. As already explained, scheduling requests were previously only defined and used in RRC connected state, and in particular should not apply to UEs in RRC non-connected state. However, with the concept of a scheduling request for non-connected state, it is allowed to indicate to the network the presence or expectation of further data, and / or to acquire a scheduling grant, i.e. resources, for the transmission of the further data. In general, the scheduling request (and scheduling grant) can be used, and can have a format(s) known from RRC connected state, for example.

[0046] In another example, the indication for the transmission of the second data is a buffer status report, or comprises a buffer status report. The buffer status report can in particular contain information about which data and how much data is in the buffer of the UE to be sent out. This can allow an efficient scheduling of resources, as only those resources can be allocated which are needed for the data in the transmission buffer.

[0047] In another example, the indication for the transmission of the second data is an indication that more data is expected. This can be indicated by a specific information field, which in the simplest form can be only a one-bit field indicating whether data is expected or not.

[0048] In one example, a (first) release message for entering the non-connected state is transmitted to the user equipment. Thus, the first release message for entering the non-connected state is received at the user equipment from the network. The release message is sent with information indicating that the UE will enter the non-connected state instead of the idle or disconnected state. Thus, the user equipment can then enter the non-connected state by applying the (first) release message received from the network. For example, the release message can comprise information (e.g. instructions or parameters) that the UE will apply for the non-connected state. For example, the release message is sent with a so-called suspendConfig, which can comprise information such as full I-RNTI, short I-RNTI, RAN paging cycle, etc. While the (first) release message and the subsequent communication can both be transmitted to and received from the same base station (anchor base station), it can also be the case that, for example, after the transmission of the (first) release message from the anchor base station (or last serving base station) to a new serving base station, the base station is handed over, e.g. because the user equipment has moved into the coverage area of a different base station after entering the non-connected state.

[0049] In one example, the transmission of the first data is conducted in a four-step RACH procedure.

[0050] To this end, a first PRACH preamble can be transmitted from the UE to the network when the UE is in the non-connected state. Thus, the first PRACH preamble can be received at the network from the user equipment.

[0051] Further, in response to the first preamble, a first random access response (RAR) can be transmitted from the network to the user equipment. Thus, the first random access response can be received at the UE from the network in response to the first random access preamble.

[0052] Further, then, in response to the first random access response, first data can be transmitted from the UE in the non-connected state to the network. Thus, the first data can be received at the network from the user equipment in response to the first random access response.

[0053] Then, in response to the transmission of the first data, a contention resolution message can be transmitted from the network to the user equipment. Thus, the contention resolution message can be received at the UE from the network in response to the transmission of the first data. The contention resolution message can be considered as an acknowledgement of the successful completion of the random access procedure (and also of the reception of the first data transmission, e.g. comprised in Msg3 (for four-step RACH) and MsgA (in two-step RACH), respectively). The payload of this message can e.g. comprise the first number of bytes of the PUSCH payload sent in Msg3 (for four-step RACH) or MsgA PUSCH (for two-step RACH).

[0054] In general, a two-step RACH procedure can also be employed in the same manner for transmission of the first data. Alternatively, a CG-based small data transmission procedure can also be employed. In general, the second (and potentially further) data can also be transmitted in the same or similar manner.

[0055] For example, the first data can be transmitted to the network immediately after the first PRACH preamble, and thus the network entity can receive the first data and the first preamble. For example, the first data can be transmitted in MsgA of the two-step RACH procedure. Thus, this example can be particularly applicable in case the first data is transmitted as part of the two-step RACH procedure.

[0056] The network entity can be configured to transmit to the user equipment threshold information whether an indication for transmission of the second data is to be transmitted, and the user equipment can be configured to receive from the network the threshold information whether an indication for transmission of the second data is to be transmitted. For example, in one example, the threshold information can comprise information on how much data is allowed to be transmitted via small data transmission. In another example, the threshold information can comprise information on or representing a threshold for the probability that additional data (e.g., present in the UE buffer) is to be sent for the UE to send an indication that more data is expected. For example, the threshold information can be based on the UE’s expectation to receive data from the UE’s upper layers, e.g., within a certain time period (e.g., corresponding to the transmission of the SDT and the reception of the RRC release message). Assuming that this duration corresponds to a certain (predefined or determined) time period or time interval (e.g., x ms), then the UE triggers an indication that more data is expected if it estimates that there is a certain (e.g., predefined or calculated) probability (e.g., y%) that a payload is generated from the upper layers. Thus, this threshold can be a certain (e.g., predefined) probability, or a y% probability over an x ms time period.

[0057] The network entity can be configured to transmit to the user equipment a resource configuration related to the transmission of the second data (i.e., related to the transmission of the indication of the second data and / or the transmission of the second data itself). Likewise, the user equipment can be configured to receive from the network a resource configuration related to the transmission of the second data. For example, the resource configuration can indicate resources that can be used directly for transmission of the second data. Alternatively, the resource configuration can indicate resources for transmission of an indication of the second data (e.g., resources for a scheduling request or a buffer status report), which in turn can lead to acquisition of resources (such as an upload grant) for subsequent transmission of the second data. Note that the transmission of the resource configuration related to the transmission of the second data or its indication can be prior to or after the reception of the first data.

[0058] In this regard, in one example, the user equipment is configured to transmit second data to the network in a small data transmission procedure in the non-connected state based on the resource configuration, and as such, the network entity is then configured to receive the second data from the user equipment in the small data transmission procedure based on the resource configuration. In another example, the user equipment is configured to transmit an indication for transmission of second data to the network based on the resource configuration, and then the network entity is configured to receive the indication for transmission of second data from the user equipment based on the resource configuration.

[0059] For example, the user equipment can be configured to activate the resource configuration after receiving a first contention resolution message, which can have been received in response to transmitting the first data. Once there is new data in the buffer of the UE, the UE can initiate transmission of the second data using the resources indicated by the resource configuration.

[0060] In this regard, in one example, the resource configuration can be or include a resource configuration for transmission of a scheduling request. The resource configuration can also be or include a resource configuration for transmission of a buffer status report. The scheduling request and the buffer status report each can be an example of an indication for transmission of the second data. At the same time, the scheduling request and the buffer status report each can allow the UE to acquire resources for actual transmission of the second data.

[0061] The resource configuration can also be or include a resource configuration for a configured grant. The resource configuration can also be or include an uplink grant. The configured grant resource and the uplink grant each can be for direct transmission of the second data. Further, the resource configuration can also be or include a resource configuration for a (second) random access preamble. For example, the random access preamble can initiate a (e.g., second) two-step or four-step RACH procedure (as part of the ongoing small data transmission procedure) for transmission of the second data, which will be described in further detail below. The (second) random access preamble can be associated with the configured grant resource (which can also be transmitted with the resource configuration as described above), and can be used to activate the configured grant resource.

[0062] In general, the resource configuration can be or include a resource configuration that includes one or more PUCCH and / or one or more PUSCH resources.

[0063] In one example, the network entity is configured to transmit the resource configuration as part of the (e.g., first) release message, and thus, the user equipment is configured to receive the resource configuration as part of the (first) release information. Additionally or alternatively, the network entity is configured to transmit the above-mentioned threshold information as part of the (e.g., first) release message, and thus, the user equipment is configured to receive the threshold information as part of the (e.g., first) release message. In another example, the network entity is configured to transmit the resource configuration as part of the (first) contention resolution message in response to the transmission of the first data, and thus, the user equipment is configured to receive the resource configuration as part of the (first) contention resolution message in response to the transmission of the first data.

[0064] In another example, the network entity is configured to transmit the resource configuration as a broadcast, and thus, the user equipment is configured to receive the resource configuration as a broadcast. In one example, the resource configuration can be included in a system information block (SIB).

[0065] In another example, the network entity is configured to transmit the resource configuration as part of the (second) release message after the transmission of the above-mentioned indication, and thus, the user equipment is configured to receive the resource configuration as part of the second release message after the transmission of the above-mentioned indication. In this case, the UE can ignore and not apply the (second) release message (thereby continuing the small data transmission procedure), and transmit the second data during the small data transmission procedure using the resources indicated by the resource configuration (such as an UL grant). Thereafter, the network can send a further (i.e., third) release message ending the small data transmission procedure. Alternatively, the UE can also store the release message (or its respective information), and apply the release message later (e.g., after having transmitted the second data and / or when no further data is to be transmitted).

[0066] In one example, the user equipment is further configured to check whether the second data is available at the user equipment. In case the second data is available at the user equipment, in the non-connected state, transmit an indication of the transmission of the second data to the network, and / or transmit the second data to the network.

[0067] Further, in one example, the UE can analyze a threshold condition. Only in case the size of the (first and / or second) data is below or does not exceed a predefined threshold, the UE will attempt to transmit the respective data in the non-connected state as described herein. In case the size of the (first and / or second) data exceeds the predefined threshold, the UE can not attempt to transmit the respective data in the non-connected state. Instead, the UE can request to transition back to the connected state. Further, the network can perform a similar analysis. For example, if the network determines (e.g., based on a received buffer status report) that the data to be transmitted exceeds a predefined threshold, the network can reject the (further) transmission in the non-connected state and, for example, force the UE to transition to the connected state.

[0068] In one example, the user equipment is further configured to transmit the second data to the network in the non-connected state in the small data transmission procedure. In this example, the network entity is correspondingly further configured to receive the second data from the user equipment in the non-connected state in the small data transmission procedure. As explained, the disclosed approach not only allows for an indication for the transmission of the second data, but also allows for the transmission of the second data in the non-connected state during the small data transmission procedure without initiating a complete new small data transmission procedure. As described above, similarly, further data (e.g., third data, fourth data, etc.) can also be indicated and transmitted like the second data.

[0069] In one example, the network entity is further configured to transmit a second release message to the user equipment. In this example, the user equipment is correspondingly configured to receive the second release message from the network. For example, the second release message can be sent by the network in the small data transmission procedure after receiving the second (and any potential further data). In other words, only after all further small data transmissions are completed, the network can transmit (and the UE can receive) a further release message. The (second) release message then ends the small data transmission procedure. However, in one example, it can also be the case that the UE only transmits the second data transmission after receiving the (second) release message, e.g., because the resource configuration for the transmission can only be provided with or after the release message. However, in this case, if the UE has second data to transmit, the UE can discard the release message, i.e., not apply the release message and transmit the second data first. The UE can then wait for a third (or respective further) release message from the network, which the UE can apply if no further data is to be transmitted. Alternatively, the UE can also store the received (second) release message and only apply it later.

[0070] As already mentioned, the second (and any further) data can be transmitted in different ways, in particular in a way similar to the transmission of the first data, more specifically, based on a RACH procedure. In one example, the second (and any further) data can be transmitted based on a four-step RACH procedure. In this example, the user equipment is further configured to transmit a second random access preamble to the network; receive a second random access response from the network in response to the second random access preamble; transmit the second data to the network in the non-connected state in response to the second random access response; and / or receive a second contention resolution message from the network. In this example, the network entity is correspondingly further configured to receive the second random access preamble from the user equipment; transmit a second random access response to the user equipment in response to the first random access preamble; receive the second data from the user equipment in the non-connected state in response to the second random access response; and / or transmit a second contention resolution message to the user equipment.

[0071] Generally, also a two-step RACH procedure can be employed in the same way in order to transmit the second data. Specifically, in case of a two-step RACH procedure, the user equipment can transmit the second data with a second random access preamble to the network, and correspondingly, the network entity can receive the second data with the second random access preamble.

[0072] In one example, the network entity is further configured to monitor a resource indicated by the transmitted resource configuration in relation to the transmission of the second data. For example, the network entity can start monitoring the (e.g., SR) resource after sending the (first) contention resolution message, which can be transmitted in response to receiving the first data. For example, the network entity can start monitoring the (e.g., CG) resource after receiving the associated random access preamble.

[0073] As already mentioned, while the (first) release message and the subsequent communication can both be transmitted to or received from the same network entity (e.g., anchor base station), it can also be the case that, for example, after the (first) release message is transmitted from the anchor base station (or last serving base station), the base station changes to a new serving base station, e.g., because the user equipment has moved into the coverage area of a different base station after entering the non-connected state. Specifically, for the latter case, the network entity can be further configured to transmit a user equipment context request to the last serving base station; and receive a user equipment context response from the last serving base station.

[0074] It should be understood that the presentation of embodiments disclosed herein is merely by way of example and not limiting.

[0075] Herein, the disclosure of a method step also shall be considered as the disclosure of a component for performing the respective method step. Likewise, the disclosure of a component for performing a method step also shall be considered as the disclosure of the respective method step.

[0076] Other features of the present disclosure will be apparent from consideration of the following detailed description taken in conjunction with the accompanying drawings. It is understood that the drawings are designed s for purposes of illustration only and not as a definition of the limits of the disclosure, for which reference should be made to the appended claims. It should be further understood that the drawings are not drawn to scale and that they are merely intended to conceptually illustrate the structures and procedures described herein. BRIEF DESCRIPTION OF DRAWINGS

[0077] Figure 1 is a schematic diagram illustrating an example radio environment in which example embodiments of the present disclosure can be implemented;

[0078] Figures 2a-2c is an example signaling diagram illustrating three small data transmission methods in which methods of the present disclosure can be employed;

[0079] Figure 3 is an example diagram of the contents of a UL MAC PDU that can be used to transmit data in RRC-based small data transmission;

[0080] Figure 4 is a comparative signaling diagram illustrating the handling of new data that appears in the UE buffer during a small data transmission procedure for a UE that is in RRC inactive without implementing the methods of the present disclosure;

[0081] Figures 5a-5d is an example signaling diagram illustrating examples of different aspects of the present disclosure;

[0082] Figures 6a-6b is an example signaling diagram illustrating examples of different aspects of the present disclosure;

[0083] Figures 7a-7d is an example signaling diagram illustrating examples of different aspects of the present disclosure;

[0084] Figure 8 is a block diagram of an example embodiment of a UE in accordance with the present disclosure;

[0085] Figure 9 is a block diagram of an example embodiment of a base station; and

[0086] Figure 10 is a schematic diagram of an example of a tangible, non-transitory computer- readable storage medium. DETAILED DESCRIPTION

[0087] The following description is intended to further deepen the understanding of the present disclosure and should be understood as supplementing the description of example embodiments of the present disclosure provided in the above “SUMMARY” section of the present specification and read together with it.

[0088] While the specific radio system used in the following examples is 5G, this is only a non-limiting example. Furthermore, in the following examples, the RRC inactive state is described as an example of a disconnected state. However, the example can generally be applied to other disconnected states, such as the RRC idle state.

[0089] Figure 1 An example environment in which this disclosure can be applied is shown. Figure 1 The diagram illustrates a 5G communication network that introduces new radio technologies and an architecture where different sublayers of the RAN can be split into two logical entities within the communication network control unit (such as a BS or gNB), called Distributed Units (DUs) and Central Units (CUs). For example, a CU is a logical node that controls the operation of one or more DUs over a fronthaul interface (called an F1 interface). A DU is a logical node that includes a subset of gNB functionality, depending on the functionality splitting options.

[0090] like Figure 1 As shown, a user equipment (UE) 10, such as a mobile device, connects to cell 1 (gNB 20) via the communication beam of cell 1. Figure 1 In the example shown, gNB 20 is equipped with CU 23, and two DUs 21 and 22 connected to CU 23 via the F1 interface. Furthermore, as... Figure 1 As shown in the example, there are multiple additional cells that UE 10 can connect to (in... Figure 1 For illustrative purposes, two cells are shown (i.e., cell 2 and cell 3). Similar to cell 1, cells 2 and 3 are controlled by gNB 25 and 26 respectively, and each cell provides multiple beams 1 to 3. Different beams in the 5G network can be used for beam diversity or beam hopping.

[0091] like Figure 1 As shown, each base station or gNB in ​​the cell is connected to the core network, such as 5GC, via a corresponding interface (indicated as the NG interface). Furthermore, each gNB in ​​the cell is connected to each other via a specific interface (e.g., referred to as the Xn-C interface).

[0092] Any network entity (such as gNB, gNB DU, gNB CU and / or 5GC) may be an example of a network entity according to the second aspect of the invention, either individually or together.

[0093] Note that, at a general level, in NR, small data transmissions are configured by the network on a per DRB basis. The minimum number of DRBs currently supported by a UE in NR is 16 without duplication and 8 per MAC entity with duplication. Up to 29 DRBs can be added in the DRB-ToAddModList, each identified by its DRB identity. Furthermore, when receiving an RRC release message with SuspendConfig, the UE suspends all configured DRBs. Buffer size reports (BSRs) sent from the UE to the gNB via MAC CEs to indicate the amount of pending data in the uplink buffer allow for explicit buffer size bit fields in NR for each logical channel group (LCG). Dedicated MAC CE formats allow for sending short (Truncated) and long (Truncated) BSRs to indicate a buffer size index corresponding to the actual buffer size level (in bytes) of one or more LCGs. The network (gNB) can then schedule uplink resources for each UE based on the QoS characteristics of the corresponding DRB for each BSR. LCGs are used to build a consolidated report of the buffer status to enable signaling overhead efficiency (i.e., reporting buffer status to aggregate data allocated to a group of LCHs assigned to the same LCG). In contrast, resource allocation is done according to logical channels. The mapping of radio bearers and logical channels to logical channel groups is done by the gNB at radio bearer setup via RRC signaling and is based on the corresponding QoS attributes of the radio bearers. Current BSR triggers include: new data arrival to an empty buffer previously; higher priority data arrival after the UE has sent a BSR and is waiting for a grant; the UE needs to periodically update the gNB on the status of the buffer, e.g., according to periodicBSR-Timer; BSR retransmission must be sent according to retxBSR-Timer to provide BSR robustness.

[0094] In RRC connected state, through dynamic UL scheduling, when a UE wants to transmit a new data packet, it triggers the transmission of a scheduling request (SR) on physical resources allocated to the physical uplink control channel (PUCCH) to request a scheduling grant (SG) from the network (if PUCCH resources have been allocated). According to the current specification, the UE is configured with PUCCH format 0 or 1 for transmitting SR. Furthermore, for transmitting multiple uplink control information (UCI) types (e.g., CSI, HARQ-ACK), the UE can be configured to use other PUCCH formats (e.g., formats 2-4) for transmitting SR. SR can also be transmitted through UCI multiplexing in PUSCH when UCI and PUSCH transmission coincide in time, either due to the transmission of an UL-SCH transport block or due to the triggering of an A-CSI transmission without an UL-SCH transport block.

[0095] The UE AS context stored at the UE in RRC inactive state and at the last serving gNB (also referred to as anchor gNB or old NG-RAN node in the following) can comprise:

[0096] - current RRC context including suspended RRC configuration (and UE radio capabilities);

[0097] - current AS security context (including UE security capabilities and security information);

[0098] - current configuration of suspended DRBs including:

[0099] - PDCP status including ROHC status,

[0100] - SDAP configuration, and

[0101] - RLC configuration;

[0102] - C-RNTI used in source PCell, cellIdentity and physical cell identity (PCI) of source PCell.

[0103] Wherein the last serving gNB is the gNB acting as anchor for the RRC inactive UE, which stores the UE AS context and maintains e.g. core network functionalities (CN level paging, user plane connection to CN, etc.).

[0104] Now turning to Figures 2a-2c , Figures 2a-2c Exemplary signaling diagrams illustrating three SDT methods in which the methods of the present disclosure can be employed are shown. Figure 2a A four-step RRC-based SDT is shown, Figure 2b A two-step RRC-based SDT is shown, Figure 2c A CG-based RRC-based SDT is shown. The above aspects of the present disclosure can be implemented in any of these methods.

[0105] Figure 3 is an exemplary diagram of the content of a UL MAC PDU that can be used to transmit data in RRC-based small data transmission in the aspects described in the present disclosure, e.g. in Msg3, MsgA or CG-based small data transmission shown in Figure 2, or in any of the Msg3 in Figures 5-7. In this case, the PDU is a RRC resume request (CCCH SDU1 including resumeID, sRMAC-I and resume cause) combined with data (DTCH SDU2 including RLC header, PDCP header and data).

[0106] Figure 4is a comparative signaling diagram illustrating the handling of new data appearing in the UE buffer during a small data transmission procedure of a UE in RRC inactive state in case of a method not implementing aspects of the present disclosure. First, the UE is in RRC connected state. The UE then receives a (first) RRC release message with suspendConfig (including the relevant parameters of the inactive state) and instructing the UE to transition to RRC inactive state. The RRC release message also includes a small data transmission configuration for a first dedicated radio bearer (DRB) of the SDT. After the UE has transitioned to the inactive state, new payload data for the first DRB appears in the UE buffer. This triggers the SDT procedure, where the UE transmits a PRACH preamble (Msgl) to the gNB, which in this case is the new serving gNB, which responds with a random access response (Msg2). The UE then transmits the first data (UL payload) to the new serving gNB via the first SDT-DRB (Msg3). At the same time, the new serving gNB transmits a UE context request and receives a UE context response from the last serving gNB. Furthermore, after the transmission of the UL payload, new payload appears again in the UE buffer, but at the same time the SDT procedure is still ongoing. Then, the UE receives a (second) RRC release message with suspendConfig for transitioning (or keeping) the UE to the inactive state. The UE applies the release message, the SDT procedure is terminated, and the UE is in the inactive state. In order to transmit the new payload in the SDT, the UE now needs to repeat the above-mentioned procedure including Msgl to Msg4 as shown in Figure 4

[0107]

[0108] Figures 5a-5d

[0109] Figure 5a Figure 5b ​​​​The case of SDT involving only one gNB (anchor gNB) is shown. In both examples, the preconfigured resources for SR and / or BSR are pre-allocated at the (first) RRC release (to inactive state) and used by the UE during the SDT procedure, i.e. after the UE receives the contention resolution message.

[0110] In more detail, in the example of Figure 5a First, the UE is in RRC connected state. The UE then receives a (first) RRC release message with suspendConfig (including parameters for the inactive state) and indicating the UE to transition to RRC inactive state. The RRC release message also includes a small data transmission configuration for a first dedicated radio bearer (DRB) for the SDT of the first data. Furthermore, the first release message also includes a resource configuration for scheduling request during the SDT procedure. After the UE has transitioned to the inactive state, new payload data for the first DRB appears in the UE buffer. This triggers the SDT procedure, where the UE transmits a PRACH preamble (Msgl) to the gNB, which in this case is the anchor gNB, which has also transmitted the first RRC release message and responds with a random access response (Msg2). The UE then transmits the first data (UL payload) to the anchor gNB via the first SDT-DRB (Msg3). The anchor gNB responds with a contention resolution message (Msg4). The UE then activates the SR resource that it has received with the first RRC release message. Furthermore, the anchor gNB has started monitoring of the SR resource after receiving the first UL payload in order to be ready to receive the second data from the UE at any time.

[0111] For example, the network only sends the contention resolution message (Msg4), i.e. not the RRC release message (to move the UE to RRC inactive state) in the same MAC payload, the reason could be that the anchor gNB is waiting to see if DL data arrives (including application level feedback to the UL SDT) or waiting for the UE context to be fetched.

[0112] Then, after the first UL payload has been transmitted, new payload (second data) appears in the UE buffer while the SDT procedure is still ongoing. The UE then transmits an indication to the anchor gNB by transmitting a scheduling request (via PUCCH or PUSCH) to the anchor gNB using the SR resource. Alternatively, the UE can use the resource to transmit a buffer status report (via PUSCH). In any case, the anchor gNB receives the indication and responds with a second RRC release message (Msg5) in the same MAC payload as the contention resolution message (Msg4). The UE then transmits the second data (UL payload) to the anchor gNB via the first SDT-DRB (Msg6). The anchor gNB responds with a contention resolution message (Msg7). The UE then activates the SR resource that it has received with the second RRC release message. Furthermore, the anchor gNB has started monitoring of the SR resource after receiving the second UL payload in order to be ready to receive the third data from the UE at any time. Figure 5aIn the example shown, the gNB determines (based on the received SR / BSR) that the second data is too large, i.e. exceeds a predefined threshold, and decides to transition the UE to RRC connected state. Hence, the gNB transmits an RRC resume message (without suspendConfig). The UE receives the RRC resume message. The UE applies the resume message and transitions to RRC connected state to transmit the second data.

[0113] In contrast, in the example shown in Fig. 2, the second data is small enough to be sent in a small data transmission procedure. Hence, the anchor gNB transmits a scheduling grant in response to the UE’s SR or BSR. Then, the UE can transmit the new payload (second data) to the anchor gNB within the same SDT procedure. Only then, the gNB transmits an (second) RRC release message with suspendConfig in order to instruct the UE to move to RRC inactive state. The UE receives and applies the release message and transitions to or stays in RRC inactive state. Hence, the UE can be considered to have never left the inactive state, but it can apply new or different configuration parameters for the inactive state (e.g. an inactive temporary identifier (I-RNTI) and / or a next hop chaining counter (NCC) provided to it as part of the RRC release message (i.e. suspendConfig)). Figure 5b

[0114] Figure 5c and Figure 5d This is related to the case where two base stations are involved, as the SDT procedure is performed in a different (non-anchor or new serving) gNB.

[0115] Figure 5c Basically, an example is described where the network can provide dedicated resources for SR and / or BSR when sending a contention resolution message to the UE.

[0116] In more detail, in the example shown in Fig. 3, the UE transmits a SR or BSR to the anchor gNB. The anchor gNB determines (based on the received SR / BSR) that the second data is small enough to be sent in a small data transmission procedure. Hence, the anchor gNB transmits a scheduling grant in response to the UE’s SR or BSR. Then, the UE can transmit the new payload (second data) to the anchor gNB within the same SDT procedure. Only then, the anchor gNB transmits an (second) RRC release message with suspendConfig in order to instruct the UE to move to RRC inactive state. The UE receives and applies the release message and transitions to or stays in RRC inactive state. Hence, the UE can be considered to have never left the inactive state, but it can apply new or different configuration parameters for the inactive state (e.g. an inactive temporary identifier (I-RNTI) and / or a next hop chaining counter (NCC) provided to it as part of the RRC release message (i.e. suspendConfig)). Figure 5c ​In the example, first, the UE (which can typically be in any state) receives a (first) RRC release message with suspendConfig (including parameters for the inactive state) and instructs the UE to transition to the RRC inactive state. The RRC release message also includes a small data transmission configuration for the first DRB of the SDT for the first data. After the UE has transitioned to the inactive state, new payload data for the first DRB appears in the UE buffer. This triggers the SDT procedure, where the UE now transmits a PRACH preamble (Msg1) to the gNB, which in this case is the new serving gNB (e.g., because the UE may have moved out of the anchor gNB's coverage area). The new serving gNB responds with a random access response (Msg2). The UE then transmits the first data (UL payload) to the new serving gNB via the first SDT-DRB (Msg3). The new serving gNB transmits a UE context request to the anchor gNB and also responds to the UE with a contention resolution message (Msg4). The contention resolution message also includes resource configuration for SR and / or BSR resources, and the UE activates the corresponding resources. In addition, the new service gNB has started monitoring SR resources after receiving the first UL payload, so as to be ready to receive the second data from the UE at any time.

[0117] Then, after the first UL payload has been transmitted, the new payload (second data) appears in the UE buffer while the SDT procedure is still in progress. The UE then transmits an indication to the new serving gNB by using SR resources to transmit a scheduling request (via PUCCH or PUSCH) or a buffer status report (via PUSCH). In response, the new serving gNB transmits a scheduling authorization. The UE can then transmit the new payload (second data) to the new serving gNB within the same SDT procedure. Simultaneously, the new serving gNB also receives the UE context response. The new serving gNB then transmits a (second) RRC release message with suspendConfig to the UE, indicating that the UE is moving to an RRC inactive state. The UE receives and applies the release message and transitions to or remains in the RRC inactive state.

[0118] Figure 5d Examples and Figure 5c The examples are the same, but in Figure 5d In the example, the network broadcast is instead of transmitting the SR / BSR resource configuration (e.g., PRACH preamble, PUCCH timing) used by the UE during the SDT process after receiving the contention resolution message, rather than transmitting the resource configuration along with the contention resolution message. The UE can then select one of the indicated SR / BSR resources based on a unique identifier (such as the TC-RNTI, which is also known to the network) to avoid conflicts with other devices.

[0119] Note that for any of the above cases, the UE can transmit multiple SRs to acquire multiple dynamic UL grants, thereby implementing in this way a multi-shot SDT procedure with more than one subsequent UL payload (i.e. also transmitting third data, fourth data, etc.). In practice, since the number of configured resources (e.g. resource occasions) for transmission of SR / BSR is limited, this corresponds to effectively limiting the maximum number of subsequent SDT UL transmissions actually supported in a multi-shot SDT procedure.

[0120] Figure 6a and Figure 6b Further example signaling diagrams illustrating examples of different aspects of the present disclosure are shown. In these examples, the configuration of the physical resources for transmitting the second data is activated to be valid for the time period between the initial SDT (at the completion of the contention resolution) and the completion of the SDT procedure (i.e. until the UE receives and applies the RRC release or resume message, depending on the release message, then the UE can transition to RRC idle, RRC inactive or RRC connected).

[0121] Figure 6a Examples of the above are related to the case where only one gNB is involved. In this embodiment, the preconfigured CG resources are activated by the UE transmitting a special PRACH preamble and upon reception of such special PRACH preamble by the network (e.g. contention-free preamble paired or associated with an indication that a new UL SDT payload has arrived at the buffer of the UE) or SR / PUCCH resources. For this special preamble, a RAR is not necessary.

[0122] In more detail, in the above Figure 6aIn an example of this, the UE is in RRC connected state. The UE then receives a (first) RRC release message with suspendConfig (including parameters for the inactive state) and instructing the UE to transition to RRC inactive state. The RRC release message also includes a small data transmission configuration for the first DRB for SDT of the first data. In addition, the first release message also includes a resource configuration for CG resources for the subsequent UL data (second data) and a dedicated second PRACH preamble paired for CG resource activation. After the UE has transitioned to inactive state, new payload data for the first DRB appears in the UE buffer. This triggers the SDT procedure, where the UE transmits a PRACH preamble (Msgl) to the gNB, which in this case is the anchor gNB, which has also transmitted the first RRC release message and responds with a random access response (Msg2). The UE then transmits the first data (UL payload) to the anchor gNB via the first SDT-DRB (Msg3). This message also includes an indication of transmission of second data to indicate that more data is expected. The anchor gNB responds with a contention resolution message (Msg4). New payload (second data) appears in the UE buffer while the SDT procedure is still ongoing. This triggers the UE to transmit a second PRACH preamble to the anchor gNB (which is associated with the CG resources). The gNB detects the second PRACH preamble and activates monitoring of the CG occasions. The UE then transmits the new payload (second data, third data, etc.) to the anchor gNB using the configured grant resources within the same SDT procedure. Only then, the gNB transmits a (second) RRC release message with suspendConfig in order to instruct the UE to move to RRC inactive state. The UE receives and applies the release message and transitions to or remains in RRC inactive state.

[0123] Figure 6b The case where the SDT procedure involves different (non-anchor) gNBs is considered. Similar to the embodiment of Figure 6a Similar to the embodiment of, the RA-based SDT is performed using a dedicated PRACH occasion and preamble. However, the resource configuration associated with this PRACH occasion / preamble is in this case broadcast by the current serving gNB.

[0124] In more detail, in the case where the SDT procedure involves different (non-anchor) gNBs, the UE receives a (first) RRC release message with suspendConfig (including parameters for the inactive state) and instructing the UE to transition to RRC inactive state. The RRC release message also includes a small data transmission configuration for the first DRB for SDT of the first data. In addition, the first release message also includes a resource configuration for CG resources for the subsequent UL data (second data) and a dedicated second PRACH preamble paired for CG resource activation. After the UE has transitioned to inactive state, new payload data for the first DRB appears in the UE buffer. This triggers the SDT procedure, where the UE transmits a PRACH preamble (Msgl) to the gNB, which in this case is the anchor gNB, which has also transmitted the first RRC release message and responds with a random access response (Msg2). The UE then transmits the first data (UL payload) to the anchor gNB via the first SDT-DRB (Msg3). This message also includes an indication of transmission of second data to indicate that more data is expected. The anchor gNB responds with a contention resolution message (Msg4). New payload (second data) appears in the UE buffer while the SDT procedure is still ongoing. This triggers the UE to transmit a second PRACH preamble to the anchor gNB (which is associated with the CG resources). The gNB detects the second PRACH preamble and activates monitoring of the CG occasions. The UE then transmits the new payload (second data, third data, etc.) to the anchor gNB using the configured grant resources within the same SDT procedure. Only then, the gNB transmits a (second) RRC release message with suspendConfig in order to instruct the UE to move to RRC inactive state. The UE receives and applies the release message and transitions to or remains in RRC inactive state. Figure 6bIn the example of FIG. 1, the UE receives a (first) RRC release message with suspendConfig (including parameters for the inactive state) and indicating the UE to transition to RRC inactive state. The RRC release message also includes a small data transmission configuration for a first DRB for SDT of first data. The UE applies the RRC release message and transitions to the inactive state. A broadcast message (here via system information block, SIB) transmitted by the new serving gNB and received by the UE includes a resource configuration of resources of a dedicated second PRACH preamble to be used during the SDT procedure after contention resolution is complete. New payload data appears in the UE buffer. As previously described, this triggers the SDT procedure, where the UE transmits a PRACH preamble (Msgl) to the new serving gNB based on the information from the first RRC release message. The new serving gNB responds with a random access response (Msg2). The UE then transmits the first data (UL payload) to the new serving gNB via the first SDT-DRB (Msg3). This message also includes an indication of transmission of second data to indicate that more data is expected. The new serving gNB transmits a UE context request to the anchor gNB and responds to the UE with a contention resolution message (Msg4). This triggers at the new serving gNB the activation of the restricted PRACH resources for transmission of the additional second data. When such new payload (second data) appears in the UE buffer, this triggers the UE to transmit a second restricted PRACH preamble (as indicated in the broadcast) to the new serving gNB (second Msgl). The gNB detects this PRACH preamble and responds with a random access response (second Msg2). The UE then transmits the new payload to the new serving gNB still in the same SDT procedure (second Msg3). The new serving gNB can again request and retrieve the UE context from the last serving gNB. Optionally, the network can respond to the UE with a contention resolution message (second Msg4). The gNB transmits a (second) RRC release message with suspendConfig to indicate the UE to move to RRC inactive state. The UE receives and applies the release message and transitions to or remains in RRC inactive state.

[0125] Figures 7a-7d Further example signaling diagrams illustrating examples of different aspects of the present disclosure are shown. In these examples, the network sends a UL grant (in a MAC CE) together with the RRC release message. The UE then uses the granted resources to indicate (e.g., via a BSR or other MAC CE with the same purpose) whether any SDT data arrived simultaneously. These embodiments are applicable to SDT procedures at both anchor gNBs and non-anchor gNBs.

[0126] Figure 7aand Figure 7b in relation to the case where the buffer of the UE is not empty.

[0127] In more detail, in Figure 7a The UE is in RRC connected state. The UE then receives a (first) RRC release message with suspendConfig (including parameters for the inactive state) and an indication for the UE to transition to RRC inactive state. The RRC release message also includes a small data transmission configuration for a first DRB for SDT of the first data. Furthermore, the first release message also includes information about a threshold for triggering an indication of the transmission of the second data. For example, the threshold can be based on an expectation of the UE receiving data from the upper layers of the UE within a time period corresponding to the transmission of the SDT and the reception of the RRC release message. Assuming that this duration corresponds to a certain (predefined or determined) time period or time interval (e.g., x ms), then the UE triggers the indication of the expectation of more data if the UE estimates that there is a certain (e.g., predefined or computed) probability (e.g., y%) of a payload generated from the upper layers. Thus, the threshold can be a certain (e.g., predefined) probability, or a y% probability of the x ms time period.

[0128] After the UE has transitioned to the inactive state, new payload data for the first DRB appears in the UE buffer. The UE analyses the threshold condition based on the information provided by the network and the SDT procedure is triggered as previously described, i.e. the UE transmits a PRACH preamble (Msgl) to the gNB, which in this case is the new serving gNB (but also in case of the anchor gNB), which responds with a random access response (Msg2). The UE then transmits first data (UL payload) to the gNB via the first SDT-DRB (Msg3). In case the threshold condition is fulfilled, this message also includes an indication of the transmission of second data to indicate that more data is expected. The responsible gNB responds with a contention resolution message (Msg4). In case the gNB is the new serving gNB, it can request the UE context as previously described. New payload (second data) subsequently appears in the UE buffer while the SDT procedure is still ongoing. Furthermore, the gNB has started a timer during which it expects more data to be transmitted for the UE in the buffer. The expiry of the timer triggers the gNB to transmit an UL grant as well as an RRC release message (with suspendConfig). The UE will discard the RRC release message and use the UL grant to transmit the new payload (second data) to the anchor gNB within the same SDT procedure. The UE can also send a buffer status report (BSR(0)) indicating that no further data is available. The UE waits for feedback from the gNB. The gNB sends a further RRC release message (with suspendConfig). The UE receives and applies the release message and transitions to or remains in the RRC inactive state.

[0129] In the example of Figure 7b the only difference is that the UE stores the content of the RRC release message instead of discarding the (second) RRC release information and uses the received UL grant for the transmission of the second data as previously described. The UE can then apply the stored RRC release message, e.g. based on a network indication or according to a timer.

[0130] Figure 7c and Figure 7d Now the case is considered where the UE buffer is empty. First, reference can be made to the examples of Figure 7a and Figure 7b However, contrary to these examples, in Figure 7c no new payload arrives at the UE’s buffer. Therefore, the UE will ignore the received UL grant and apply the received RRC release message (with suspendConfig) to transition to or remain in the RRC inactive state. In Figure 7dIn an alternative embodiment of the above, the UE will send a BSR back to the network with a buffer size index corresponding to 0 bytes (BSR(0)) in response to the UL grant and then apply the RRC release message to transition to or remain in the RRC inactive state instead of not responding at all.

[0131] Turning now to Figure 8 a block diagram illustrating an exemplary embodiment of a user equipment according to the present disclosure, such as Figure 1 a UE 10 in the form of a user equipment 800. For example, the user equipment 800 can be one of a smartphone, a tablet, a laptop, a smartwatch, a smartband, and an IoT device.

[0132] The user equipment 800 comprises a processor 801. The processor 801 can represent a single processor or two or more processors, which are at least partly coupled, e.g., via a bus. The processor 801 executes program code stored in a program memory 802 (e.g., which when executed on the processor 801 causes the user equipment 800, optionally together with the network entity 900, to perform one or more embodiments of the method according to the present disclosure, or parts thereof), and interfaces with a main memory 803. The program memory 802 can also contain an operating system for the processor 801. Some or all of the memories 802 and 803 can also be included in the processor 801.

[0133] One or both of the main memory and the program memory of the processor (e.g., the program memory 802 and the main memory 803) can be fixedly connected to the processor (e.g., the processor 801) or at least partly removed from the processor, e.g., in the form of a memory card or stick.

[0134] The program memory (e.g., the program memory 802) can for example be a non-volatile memory. For example, it can be any one of a flash memory (or a part thereof), a ROM, a PROM, an EPROM, an MRAM, or a FeRAM (or a part thereof), or a hard disk (or a part thereof), to name a few examples. For example, the program memory can for example comprise a first memory portion that is fixedly installed and a second memory portion that is removable, e.g., in the form of an SD memory card.

[0135] The main memory (e.g., the main memory 803) can for example be a volatile memory. For example, it can be a DRAM memory. For example, it can be used as a working memory of the processor 801 when executing an operating system, an application, a program, etc.

[0136] The processor 801 also controls a communication interface 804 (e.g., a radio interface) configured to receive and / or transmit data and / or information. For example, the communication interface 804 can be configured to transmit and / or receive radio signals from a radio node, such as a base station. It will be appreciated that any computer program code based processing of the received signals can be stored in the communication interface’s 804 own memory and executed by the communication interface’s 804 own processors, or it can be stored in the memory 803 and executed by the processor 801, e.g.

[0137] The communication interface 804 can in particular be configured to communicate in accordance with a cellular communications system, like a 2G / 3G / 4G / 5G or future generation cellular communications system. The user equipment 800 can use the radio interface 804 to communicate with a base station (e.g., a base station 20) shown. Figure 1

[0138] For example, the communication interface 804 can also comprise a BLE and / or Bluetooth radio interface, including a BLE transmitter, receiver or transceiver. For example, the radio interface 804 can additionally or alternatively comprise a WLAN radio interface, including at least a WLAN transmitter, receiver or transceiver.

[0139] The components 802-804 of the user equipment 800 can be connected with the processor 801, e.g., by means of one or more serial and / or parallel buses.

[0140] It will be appreciated that the user equipment 800 can comprise various other components. For example, the user equipment 800 can optionally comprise a user interface (e.g., a touch-sensitive display, a keyboard, a touchpad, a display, etc.).

[0141] Figure 9 is a block diagram of an exemplary embodiment of a network entity, such as a base station 20 and / or core network 30 (or a part thereof) of Figure 1 For example, as described above, the network entity 900 can be configured for scheduling and / or transmitting positioning reference signals to user equipment.

[0142] The network entity 900 comprises a processor 901. The processor 901 can represent a single processor or two or more processors, which are at least partially coupled, e.g., via a bus. The processor 901 executes program code stored in a program memory 902 (e.g., program code causing the network entity 900 to execute alone or together with an embodiment of a user equipment 800 or a part thereof according to the present disclosure), and interfaces with a main memory 903.

[0143] ​The program memory 902 may also include an operating system for the processor 901. Some or all of the memories 902 and 903 may also be included in the processor 901.

[0144] Furthermore, the processor 901 controls the communication interface 904, which is configured, for example, to communicate according to a cellular communication system such as 2G / 3G / 4G / 5G cellular communication systems. The communication interface 904 of the network entity 900 can, for example, be implemented by a radio head unit 30, and can be provided for... Figure 1 Communication between base station 20 and UE 10.

[0145] Components 902 to 904 of network entity 900 may be connected to processor 901, for example, by means of one or more serial and / or parallel buses.

[0146] User equipment 800, together with communication interface 804, can be specifically configured to receive signals from network entity 900 according to the method described herein.

[0147] It should be understood that devices 800 and 900 may include various other components.

[0148] Figure 10 This is a schematic diagram of an example of a tangible, non-transitory, computer-readable storage medium according to the present disclosure, which can be used, for example, to implement Figure 8 Memory 802 or Figure 9 The memory 902. Therefore, Figure 10 Examples of the inventions shown include a flash memory 1000 that can be soldered or bonded to a printed circuit board, a solid-state drive 1001 that includes multiple memory chips (e.g., flash memory chips), a magnetic hard disk drive 1002, a secure digital (SD) card 1003, a universal serial bus (USB) memory stick 1004, an optical storage medium 1005 (e.g., a CD-ROM or DVD), and a magnetic storage medium 1006.

[0149] The following embodiments are also disclosed:

[0150] 1. A user equipment comprising components configured to perform the following:

[0151] - In a connectionless state, the first data is transmitted to the network during a small data transfer process; and

[0152] - In the disconnected state, during the small data transmission process, an instruction for the transmission of second data is transmitted to the network, the second data becoming available for transmission after the first data has been transmitted.

[0153] 2. The user equipment according to Embodiment 1, wherein one or more of the following:

[0154] - the indication for transmission of second data is transmitted before receiving a release message from the network;

[0155] - the indication for transmission of second data is transmitted after transmitting the first data;

[0156] - the indication for transmission of second data is transmitted after receiving a first contention resolution message; and / or

[0157] - the indication for transmission of second data is transmitted as part of a message comprising the first data.

[0158] 3. The user equipment according to any of embodiments 1 or 2, wherein the indication for transmission of second data is one or more of or comprises one or more of:

[0159] - a scheduling request;

[0160] - a buffer status report; and / or

[0161] - an indication that there is more data expected.

[0162] 4. The user equipment according to any of embodiments 1 to 3, further configured to one or more of:

[0163] - receive a release message from the network for entering the non-connected state;

[0164] - enter the non-connected state by applying the release message received from the network;

[0165] - transmit a first random access preamble to the network;

[0166] - transmit the first data with the first random access preamble to the network;

[0167] - receive a first random access response from the network in response to the first random access preamble;

[0168] - transmit the first data to the network in the non-connected state in response to the first random access response; and / or

[0169] - receive a contention resolution message from the network in response to the transmission of the first data.

[0170] 5. The user equipment according to any of embodiments 1 to 4, further configured to at least one of:

[0171] - receive, from the network, a resource configuration related to the transmission of the indication of the second data and / or the transmission of the second data; and / or

[0172] - receive, from the network, threshold information whether the indication of the transmission of the second data is to be transmitted.

[0173] 6. The user equipment according to embodiment 5, the resource configuration is or comprises one or more of:

[0174] - a resource configuration for transmission of a scheduling request;

[0175] - a resource configuration for transmission of a buffer status report;

[0176] - a resource configuration for configured grant;

[0177] - a resource configuration for random access preamble;

[0178] - an uplink grant; and / or

[0179] - a resource configuration comprising one or more PUCCH, and / or one or more PUSCH resources.

[0180] 7. The user equipment according to any one of embodiments 5 or 6, further configured to one or more of:

[0181] - receive the threshold information as part of a release message;

[0182] - receive the resource configuration, or the resource configuration of the release message, as part of a release message;

[0183] - receive the resource configuration as part of a contention resolution message (Msg4) in response to the transmission of the first data;

[0184] - receive the resource configuration as a broadcast message; and / or

[0185] - receive the resource configuration as part of a release message after the transmission of the indication.

[0186] 8. The user equipment according to any one of embodiments 5 to 7, further configured to one or more of:

[0187] - activate the resource configuration after receiving a first contention resolution message in response to transmitting the first data;

[0188] - transmit the second data to the network in the small data transmission procedure in the non-connected state based on the resource configuration; and / or

[0189] transmitting, to the network, the indication for transmission of second data based on the resource configuration.

[0190] 9. The user equipment according to any one of embodiments 1 to 8, further configured to:

[0191] - check whether second data is available at the user equipment;

[0192] - transmit, to the network, the indication for transmission of second data and / or transmit the second data in the non-connected state in case second data is available at the user equipment.

[0193] 10. The user equipment according to any one of embodiments 1 to 9, further configured to one or more of:

[0194] - transmit the second data to the network in the small data transmission procedure in the non-connected state; and / or

[0195] - receive a release message from the network.

[0196] 11. The user equipment according to any one of embodiments 1 to 10, further configured to one or more of:

[0197] - transmit a second random access preamble to the network;

[0198] - transmit the second data to the network together with or after the second random access preamble;

[0199] - receive a second random access response from the network in response to the second random access preamble;

[0200] - transmit the second data to the network in the non-connected state in response to the second random access response; and / or

[0201] - receive a second contention resolution message from the network.

[0202] 12. The user equipment according to any one of embodiments 1 to 11, wherein one or more of:

[0203] - the non-connected state is an RRC inactive state;

[0204] - the first data and / or the second data is control plane data;

[0205] - the first data and / or the second data is a RAN notification area update;

[0206] - the first data and / or the second data is user plane data;

[0207] - the first data and / or the second data is transmitted in a two-step or four-step RACH procedure;

[0208] - the first data and / or the second data is transmitted with CG-based PUSCH transmission; and / or

[0209] - the network comprises a last serving base station and / or a new serving base station.

[0210] 13. A method performed at least by a user equipment, the method comprising:

[0211] - transmitting, in a small data transmission procedure, first data to a network in an unconnected state; and

[0212] - transmitting, to the network during the small data transmission procedure, an indication of a transmission of second data which becomes available for transmission after the first data is transmitted.

[0213] 14. A network entity comprising means configured to:

[0214] - receive, in a small data transmission procedure, first data from a user equipment in an unconnected state;

[0215] - transmit, to the user equipment, a resource configuration related to an indication of a transmission of second data and / or a transmission of the second data to occur during the small data transmission procedure; and - receive, from the user equipment in the unconnected state, the indication of a transmission of second data during the small data transmission procedure.

[0216] 15. The network entity according to embodiment 14, further configured to one or more of:

[0217] - transmit, to the user equipment, a first release message for entering the unconnected state;

[0218] - receive, from the user equipment, a first random access preamble;

[0219] - transmit, to the user equipment, a first random access response in response to the first random access preamble;

[0220] - receive, from the user equipment, the first data in response to the first random access response; and / or

[0221] - transmitting, to the user equipment, a contention resolution message in response to the transmission of the first data.

[0222] 16. The network entity according to any of embodiments 14 or 15, further configured to:

[0223] - transmit, to the user equipment, threshold information of whether or not to transmit the indication for transmission of second data.

[0224] 17. The network entity according to embodiment 16, further configured to one or more of:

[0225] - transmit the threshold information as part of a release message;

[0226] - transmit the resource configuration as part of a release message, or transmit the resource configuration as the release message;

[0227] - transmit the resource configuration as part of a contention resolution message in response to the transmission of the first data;

[0228] - transmit the resource configuration as a broadcast message; and / or

[0229] - transmit the resource configuration as part of a release message after the reception of the indication.

[0230] 18. The network entity according to any of embodiments 16 or 17, further configured to:

[0231] - monitor resources indicated by the transmitted resource configuration, the transmitted resource configuration being related to the transmission of the indication of the second data and / or to the transmission of the second data.

[0232] 19. The network entity according to any of embodiments 14 to 18, further configured to one or more of:

[0233] - receive, from the user equipment in the non-connected state, the second data during the small data transmission procedure;

[0234] - transmit, to the user equipment, a release message.

[0235] 20. The network entity according to any of embodiments 14 to 19, further configured to one or more of:

[0236] - receive, from the user equipment, a second random access preamble;

[0237] - receive, from the user equipment, the second data with the second random access preamble;

[0238] - transmitting a second random access response to the user equipment in response to the first random access preamble;

[0239] - receiving the second data from the user equipment in the non-connected state in response to the second random access response; and / or

[0240] - transmitting a second contention resolution message to the user equipment.

[0241] 21. The network entity according to any one of embodiments 14 to 20, further configured to:

[0242] - transmit a user equipment context request to a last serving base station; and

[0243] - receive a user equipment context response from a last serving base station.

[0244] 22. A method performed at least by a network entity, the method comprising:

[0245] - receiving first data from a user equipment in a non-connected state during a small data transmission procedure;

[0246] - transmitting a resource configuration to the user equipment, the resource configuration relating to transmission of an indication of second data to occur during the small data transmission procedure and / or to transmission of the second data; and

[0247] - receiving the indication for transmission of second data from the user equipment in the non-connected state during the small data transmission procedure.

[0248] 23. A computer program code which, when executed by a processor of an apparatus, causes the apparatus to perform the method according to any one of embodiments 13 or 22.

[0249] 24. A computer readable storage medium comprising the computer program code according to embodiment 23.

[0250] Any presented connection in the described embodiments should be understood in the sense that the involved components are operatively coupled. Thus, a connection can be a connection directly or indirectly with any number or combination of intermediate elements, and there can only be a functional relationship between the components.

[0251] Furthermore, as used herein the term“circuitry” refers to any one or combination of:

[0252] (a) hardware-only circuitry such as only analog and / or digital circuitry

[0253] (b) a combination of circuitry and software (and / or firmware), such as:

[0254] (i) a combination of (multiple) processors, or

[0255] (ii) parts of (multiple) processors / software (including (multiple) digital signal processors, software, and (multiple) memories), that work together to cause an apparatus, such as a mobile phone, to do

[0256] (c) a circuit, such as a microprocessor(s) or a portion of a microprocessor(s), that requires software or firmware for operation, even if the software or firmware is not physically present.

[0257] This definition of "circuitry" applies to all uses of this term in this document, including in any claims. As a further example, as used in this document, the term "circuitry" also covers an implementation that has a reconfigurable

[0258] Any processor mentioned herein (particularly but not exclusively processors 801 and 901 in FIGS. Figure 8 and Figure 9 may be any suitable type of processor. Any processor can include, but is not limited to, one or more microprocessors, one or more processors with accompanying digital signal processors (DSPs), one or more processors with accompanying ASICs, one or more field-programmable gate arrays (FPGAs), one or more controllers, one or more

[0259] Further, any actions or steps described herein or illustrated in the accompanying drawings can be implemented with executable instructions in a programmable computer or general purpose processor (e.g., a microprocessor, a Digital Signal Processor (DSP), or other processing circuitry) that excutes the instructions. Reference to a "computer readable storage medium", should be understood to encompass

[0260] Further, any actions can be implemented using executable instructions in a programmable computer or general purpose processor (e.g., a microprocessor, a Digital Signal Processor (DSP), or other processing circuitry) that excutes the instructions. Reference to a "computer readable storage medium", should be understood to encompass special purpose

[0261] The phrase “A, or B, or C, or a combination thereof” or “at least one of A, B and C” can be understood as not exhaustive, but rather includes at least the following: (i) A, or (ii) B, or (iii) C, or (iv) A and B, or (v) A and C, or (vi) B and C, or (vii) A and A and C.

[0262] It should be understood that the embodiments disclosed herein are merely exemplary, and any feature presented with respect to a particular exemplary embodiment may be used alone or in combination with any feature presented with respect to that particular exemplary embodiment or another particular exemplary embodiment and / or in combination with any other feature not mentioned, in any aspect of this disclosure. It will also be understood that any feature presented with respect to example embodiments in a particular category may also be used in a corresponding manner in example embodiments of any other category.

[0263] List of abbreviations:

[0264] AMF: Access and Mobility Management Functions

[0265] BSR: Buffer Status Report

[0266] CG: Configuration Authorization

[0267] CP: Control Plane

[0268] DRB: Data Radio Bearer

[0269] gNB: 5G Node BI-RNTI: Temporary Identifier for Inactive Radio Networks

[0270] LCG: Logical Channel Group

[0271] LCH: Logical Channel

[0272] NCC: Next Hop Link Count

[0273] NG-RAN: Next Generation Radio Access Network

[0274] NR: New Radio

[0275] PRACH: Physical Random Access Channel

[0276] RACH: Random Access Channel

[0277] RAN: Radio Access Network

[0278] RNA: RAN notification region

[0279] RNAU: RAN Notification Region Update

[0280] RRC: Radio Resource Control Protocol

[0281] SDT: small data transmission

[0282] UE: user equipment

[0283] UP: user plane

[0284] Xn: Xn network interface

Claims

1. A user equipment, comprising: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the user equipment to: in a non-connected state, transmit first data to a network entity in a small data transmission procedure; and transmit, to the network entity, an indication related to transmission of second data after the transmission of the first data, the second data becoming available after the first data has been transmitted while the small data transmission procedure is ongoing, the second data being new data and the second data to be transmitted while the user equipment is in a radio resource control, RRC, connected state, wherein the indication for transmission of second data is transmitted prior to receiving an RRC resume message from the network entity, and / or the indication for transmission of second data is transmitted after transmitting the first data.

2. The user equipment of claim 1, wherein the indication for transmission of second data is, or comprises, one or more of: a scheduling request; a buffer status report; and / or an indication of more data expected.

3. The user equipment of claim 1, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, further cause the user equipment to one or more of: receive, from the network entity, a resource configuration related to the transmission of the indication of the second data, and / or related to the transmission of the second data; and / or receive, from the network entity, threshold information of whether to transmit the indication for transmission of second data.

4. The user equipment of claim 3, the resource configuration is, or comprises, one or more of: a resource configuration for transmission of a scheduling request; a resource configuration for transmission of a buffer status report; a resource configuration for a configured grant; a resource configuration for a random access preamble; an uplink grant; and / or a resource configuration comprising one or more PUCCH, and / or one or more PUSCH resources.

5. The user equipment of claim 3, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, further cause the user equipment to one or more of: receive the threshold information as part of a release message; receive the resource configuration as part of a release message, or the resource configuration of the release message; receive the resource configuration as part of a contention resolution message in response to the transmission of the first data; receive the resource configuration as a broadcast message; and / or receive the resource configuration as part of a release message after the transmission of the indication.

6. The user equipment of claim 1, wherein the user equipment is further caused to: ​ receiving, from the network entity, an RRC resume message, the RRC resume message indicating to transition the user equipment to the RRC connected state.

7. The user equipment of claim 1, wherein the user equipment is further caused to: transition to the RRC connected state to transmit the second data; and transmit the second data to the network entity in the RRC connected state.

8. A method performed by a user equipment, the method comprising: transmitting, to a network entity, first data in a small data transmission procedure in a non-connected state; and transmitting, to the network entity, an indication related to transmission of second data after the transmission of the first data, the second data becoming available after the first data has been transmitted while the small data transmission procedure is ongoing, the second data being new data and the second data to be transmitted while the user equipment is in a radio resource control, RRC, connected state, wherein the indication for transmission of second data is transmitted prior to receiving an RRC resume message from the network entity, and / or the indication for transmission of second data is transmitted after transmitting the first data.

9. The method of claim 8, wherein the indication for transmission of second data is one or more of, or comprises one or more of: a scheduling request; a buffer status report; and / or an indication of more data expected.

10. The method of claim 8, further comprising: receiving, from the network entity, a resource configuration related to the transmission of the indication of the second data, and / or related to the transmission of the second data; and receiving, from the network entity, threshold information of whether to transmit the indication for transmission of second data.

11. The method of claim 10, the resource configuration is one or more of, or comprises one or more of: a resource configuration for transmission of a scheduling request; a resource configuration for transmission of a buffer status report; a resource configuration for a configured grant; a resource configuration for a random access preamble; an uplink grant; and / or a resource configuration comprising one or more PUCCH, and / or one or more PUSCH resources.

12. The method of claim 10, further comprising: receiving the threshold information as part of a release message; receiving the resource configuration as part of a release message, or the resource configuration of the release message; receiving the resource configuration as part of a contention resolution message in response to the transmission of the first data; receiving the resource configuration as a broadcast message; and / or receiving the resource configuration as part of a release message after the transmission of the indication.

13. The method of claim 8, further comprising: receiving, from the network entity, an RRC resume message, the RRC resume message indicating to transition the user equipment to the RRC connected state.

14. The method of claim 8, further comprising: ​ ​ transitioning to the RRC connected state for transmission of the second data; and transmitting the second data to the network entity in the RRC connected state.

15. A computer readable medium comprising program instructions which, when executed by a user equipment, cause the user equipment to perform at least the following: transmitting first data to a network entity in a small data transmission procedure in a non-connected state; and transmitting to the network entity an indication related to transmission of second data after the transmission of the first data, the second data becoming available after the first data has been transmitted while the small data transmission procedure is ongoing, the second data being new data and the second data to be transmitted while the user equipment is in a radio resource control, RRC, connected state, wherein the indication for transmission of second data is transmitted before receiving an RRC resume message from the network entity and / or the indication for transmission of second data is transmitted after transmitting the first data.

16. The computer readable medium of claim 15, wherein the program instructions further cause the user equipment to perform: receiving an RRC resume message from the network entity, the RRC resume message indicating to transition the user equipment to the RRC connected state.

17. The computer readable medium of claim 15, wherein the program instructions further cause the user equipment to perform: transitioning to the RRC connected state for transmission of the second data; and transmitting the second data to the network entity in the RRC connected state.

Images