User Equipment, Radio Access Network Node, and Method

Abstract

An exemplary embodiment of the present disclosure relates to small data transmission. However, according to the present disclosure, when calculating the data amount for the small data transmission, the previously stored data is not taken into account, so that a correct data amount value can be obtained. Furthermore, the terminal device may obtain information about the amount of new data before calculating the data amount for the small data transmission. Furthermore, during the small data transmission, the buffer status report reported may indicate the actual status of the remaining small data transmission data. Furthermore, if the terminal device fails to transmit the small data transmission data via the four-step random access procedure, the terminal device may fall back to the four-step random access small data transmission appropriately.

Description

[Technical field]

[0001] TECHNICAL FIELD Embodiments of the present disclosure relate generally to the field of telecommunications, and more particularly to communication methods, apparatus, and media. [Background technology]

[0002] The power consumption of the terminal device is a focus in conventional wireless communication systems. In order to reduce the power consumption of the terminal device, it is proposed that the terminal device may be set into some power saving modes / states (e.g., inactive state). For the terminal device in the inactive state, it is proposed to suspend normal data transmission. Generally speaking, when the terminal device in the inactive state needs to perform normal transmission with the network device, the terminal device has no choice but to resume connection with the network device (i.e., wake up and transition to a connected state).

[0003] To further reduce power consumption, a work item of the third Generation Partnership Project (3GPP) proposed a solution that enables small data transmission (SDT) for terminal devices in an inactive state. Using SDT, a terminal device in an inactive state can remain in an inactive mode while enabling uplink (UL) and downlink (DL) transmissions following the original UL transmission. Summary of the Invention [Problem to be solved by the invention]

[0004] Overall, the exemplary embodiments of the present disclosure provide a communication solution for devices that are inactive. The embodiments that do not fall within the scope of the claims (if any) are to be construed as examples useful for understanding various embodiments of the present disclosure. [Means for solving the problem]

[0005] In a first aspect, a communication method is provided, the method including: discarding, in a terminal device, stored data for at least one radio bearer configured for small data transmission; and calculating an amount of data used by the terminal device to determine whether to perform small data transmission after discarding the stored data.

[0006] In a second aspect, a communication method is provided, the method including: in a network device, transmitting a message to a terminal device for suspending a radio resource control connection, the message including information regarding at least one radio bearer among the radio bearers configured by the network device for small data transmission, and an instruction to instruct the terminal device to discard the stored data for the at least one radio bearer configured for small data transmission.

[0007] In a third aspect, a communication method is provided, comprising: obtaining, in a terminal device, information on an amount of new data that needs to be transmitted to a network, the information being provided from a layer of the terminal device higher than the packet data convergence protocol layer to a layer of the terminal device responsible for calculating an amount of data used by the terminal device for deciding whether to perform a small data transmission; and, if all the new data is from at least one radio bearer configured for small data transmission, calculating, in the layer responsible for calculating the amount of data, the amount of data based at least in part on the information.

[0008] In a fourth aspect, a communication method is provided, the method including: resuming at least one radio bearer configured for small data transmission in an inactive terminal device when the terminal device detects that all new data is from at least one radio bearer; and calculating an amount of data used by the terminal device to decide whether to perform small data transmission.

[0009] In a fifth aspect, a communication method is provided, the method including: generating, in a terminal device performing small data transmission with a network device, a buffer status report indicating a buffer status associated with at least one of a radio bearer configured for small data transmission, a radio bearer that is not suspended, a logical channel corresponding to the radio bearer configured for small data transmission, or a logical channel corresponding to the radio bearer that is not suspended, and transmitting the buffer status report to the network device.

[0010] In a sixth aspect, a communication method is provided, the method including, when a logical channel group includes at least one logical channel corresponding to a radio bearer to be suspended and at least one other logical channel corresponding to a radio bearer that is not suspended, generating, in a network device and a terminal device performing small data transmission, a buffer status report for the logical channel group without considering at least one of a radio bearer not configured for small data transmission, a suspended radio bearer, a logical channel corresponding to the radio bearer not configured for small data transmission, or a logical channel corresponding to the radio bearer that is suspended, and transmitting the buffer status report to the network device.

[0011] In a seventh aspect, a communication method is provided, the method including: configuring, in a network device, at least one radio bearer corresponding to a plurality of logical channels included in at least one logical channel group for a terminal device for small data transmission, where each logical channel included in the at least one logical channel group corresponds to a radio bearer configured for small data transmission, and indicating the configuration result to the terminal device.

[0012] In an eighth aspect, a communication method is provided, the method including: when a terminal device is configured to have both a four-step random access procedure resource for small data transmission and a two-step random access procedure resource for small data transmission, receiving, in the terminal device, a parameter indicating a maximum number of times that the terminal device transmits a message A of the two-step random access procedure for the small data transmission from a network device; and performing small data transmission with the network device based on the maximum number of times.

[0013] In a ninth aspect, a communication method is provided, the method including, when a terminal device is configured to have both a four-step random access procedure resource for small data transmission and a two-step random access procedure resource for small data transmission, transmitting, in a network device, to the terminal device, a parameter indicating a maximum number of times that the terminal device transmits a message A of a two-step random access procedure for small data transmission.

[0014] In a tenth aspect, there is provided a terminal device comprising: a processor; and a memory, coupled to the processor, storing instructions, the instructions, when executed by the processor, causing the terminal device to perform the method of the first aspect.

[0015] In an eleventh aspect, there is provided a network device comprising: a processor; and a memory, coupled to the processor, storing instructions, which when executed by the processor cause the network device to perform the method of the second aspect.

[0016] In a twelfth aspect, there is provided a terminal device comprising: a processor; and a memory, coupled to the processor, storing instructions, which when executed by the processor cause the terminal device to perform the method of the third aspect.

[0017] In a thirteenth aspect, there is provided a terminal device comprising: a processor; and a memory, coupled to the processor, storing instructions, the instructions, when executed by the processor, causing the terminal device to perform the method of the fourth aspect.

[0018] In a fourteenth aspect, there is provided a terminal device comprising: a processor; and a memory, coupled to the processor, storing instructions, the instructions, when executed by the processor, causing the terminal device to perform the method of the fifth aspect.

[0019] In a fifteenth aspect, there is provided a terminal device comprising: a processor; and a memory, coupled to the processor, storing instructions, which when executed by the processor cause the terminal device to perform the method of the sixth aspect.

[0020] In a sixteenth aspect, there is provided a network device comprising: a processor; and a memory, coupled to the processor, storing instructions, which when executed by the processor cause the network device to perform the method of the seventh aspect.

[0021] In a seventeenth aspect, there is provided a terminal device comprising: a processor; and a memory, coupled to the processor, storing instructions, the instructions, when executed by the processor, causing the terminal device to perform the method of the eighth aspect.

[0022] In an eighteenth aspect, there is provided a network device comprising: a processor; and a memory, coupled to the processor, storing instructions, which when executed by the processor cause the network device to perform the method of the ninth aspect.

[0023] In a nineteenth aspect, there is provided a computer readable medium storing instructions which, when executed on at least one processor, cause the at least one processor to perform a method according to any one of the first to ninth aspects above.

[0024] It should be understood that this summary is not intended to identify key or essential features of the embodiments of the present disclosure, nor to limit the scope of the present disclosure. Other features of the present disclosure should be readily apparent from the following description. [Brief description of the drawings]

[0025] The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description of several embodiments of the present disclosure in the accompanying drawings. [Figure 1A] A diagram showing the signaling flow for SDT. [Figure 1B] A diagram showing the signaling flow for SDT. [Diagram 2] FIG. 1 illustrates an exemplary communication environment in which exemplary embodiments of the present disclosure may be practiced. [Diagram 3] FIG. 1 shows a proposed method for calculating the amount of data for an SDT. [Figure 4]FIG. 1 is a signaling diagram illustrating a process for calculating the amount of data for an SDT in accordance with some embodiments of the present disclosure. [Figure 5A] FIG. 2 illustrates an exemplary method for processing stored data in accordance with some embodiments of the present disclosure. [Figure 5B] FIG. 2 illustrates an exemplary method for processing stored data in accordance with some embodiments of the present disclosure. [Figure 6] FIG. 2 illustrates an exemplary method performed by a terminal device for processing stored data, according to some embodiments of the present disclosure. [Figure 7] FIG. 2 illustrates an example method performed by a network device to process stored data, in accordance with some embodiments of the present disclosure. [Figure 8] FIG. 2 illustrates an exemplary method performed by a terminal device to obtain an amount of new data, according to some embodiments of the present disclosure. [Figure 9] FIG. 2 illustrates an exemplary method for obtaining an amount of new data, in accordance with some embodiments of the present disclosure. [Figure 10] FIG. 2 illustrates an example method performed by a terminal device to proactively restart an RS, in accordance with some embodiments of the present disclosure. [Figure 11] FIG. 2 illustrates an example method performed by a terminal device to proactively restart an RS, in accordance with some embodiments of the present disclosure. [Figure 12] FIG. 2 is a signaling diagram for processing a buffer status report (BSR) in accordance with some embodiments of the present disclosure. [Figure 13] FIG. 1 illustrates an exemplary method for processing a BSR in accordance with some embodiments of the present disclosure. [Figure 14] FIG. 13 illustrates another exemplary method for processing a BSR, in accordance with some embodiments of the present disclosure. [Figure 15]FIG. 13 illustrates yet another exemplary method for processing a BSR, in accordance with some embodiments of the present disclosure. [Figure 16] FIG. 1 is a signaling diagram illustrating a process for falling back to a four-step random access (RA) based SDT procedure in accordance with some embodiments of the present disclosure. [Figure 17] A diagram showing an exemplary method for falling back to a 4-step RA-based SDT procedure performed by a terminal device in accordance with some embodiments of the present disclosure. [Figure 18] A diagram illustrating an example method for falling back to a four-step RA-based SDT procedure performed by a network device in accordance with some embodiments of the present disclosure. [Figure 19] 1 is a schematic block diagram of an apparatus suitable for implementing exemplary embodiments of the present disclosure, in which identical or similar reference numbers represent identical or similar elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] The principles of the present disclosure will now be described with reference to some exemplary embodiments. It should be understood that these embodiments are provided for illustrative purposes only, to assist those skilled in the art in understanding and implementing the present disclosure, and do not imply any limitations on the scope of the present disclosure. The embodiments described herein can be implemented in various ways different from those described below.

[0027] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0028] References in this disclosure to "one embodiment," "an embodiment," "an exemplary embodiment," and the like indicate that the described embodiment may include a particular feature, structure, or characteristic, but each embodiment does not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is believed to be within the knowledge of one of ordinary skill in the art to affect such feature, structure, or characteristic in connection with other embodiments, whether or not explicitly described.

[0029] It should be understood that although the terms "first" and "second" etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first element may be termed a second element, and similarly, a second element may be termed a first element, without departing from the scope of the exemplary embodiments. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0030] The terms used herein are used only for the purpose of describing particular embodiments and are not intended to limit the exemplary embodiments. As used herein, the singular forms "a," "an," and "said" include the plural forms unless the context clearly indicates otherwise. It should be further understood that, as used herein, the terms "including," "including," "having," "comprising," "having," and / or "having" specify the presence of stated features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0031] In some instances, values, procedures, or devices are referred to as "best," "lowest," "highest," "minimum," "maximum," etc. Such descriptions are intended to illustrate that selections can be made from among many functional alternatives used, and it should be understood that such selections are not necessarily better, smaller, higher, or otherwise more preferred than other selections.

[0032] The term "network device" as used herein means a device capable of providing or hosting a cell or coverage in which a terminal device can communicate. Examples of network devices include, but are not limited to, a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), a Node B for New Radio Access (gNB), a Remote Radio Unit (RRU), a Radio Head (RH), a Remote Radio Head (RRH), a low power node such as a femto node or a pico node, a satellite network device, an aircraft network device, etc. In the following, for the sake of explanation, some exemplary embodiments are described with reference to an eNB as an example of a network device.

[0033] As used herein, the term "terminal" refers to any end device capable of wireless communication. By way of example and not limitation, a terminal may be referred to as a communication device, a user equipment (UE), a subscriber station (SS), a portable subscriber station (Portable Subscriber Station), a mobile station (MS), or an access terminal (AT). The terminal device may include, but is not limited to, a mobile phone, a cellular phone, a smartphone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable terminal device, a personal digital assistant (PDA), a portable computer, a desktop computer, an imaging terminal device such as a digital camera, a gaming terminal device, a music storage and playback device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop embedded device (LEE), a laptop mounted device (LME), a USB dongle, a smart device, a wireless customer premises equipment (CPE), an Internet of Things (IoT) device, a watch or other wearable device, a head mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., a robot and / or other wireless device operating in an industrial and / or automated processing chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably.

[0034] As used herein, the term "communication network" refers to a network conforming to any suitable communication standard, such as New Radio (NR), Long Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), Narrow Band Internet of Things (NB-IoT), etc. Furthermore, communication between terminal devices and network devices in a communication network may be realized according to any suitable generation of communication protocols, including, but not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, fifth generation (5G) communication protocols, and / or any other protocols now known or developed in the future. Embodiments of the present disclosure may be applied to various communication systems. In view of the rapid development of communication, there will naturally be future types of communication technologies and systems in which the present disclosure can be embodied, which should not be considered as limiting the scope of the present disclosure only to the aforementioned systems.

[0035] The term "circuitry" as used herein can refer to a hardware circuit and / or a combination of a hardware circuit and software. For example, a circuit may be a combination of analog and / or digital hardware circuitry and software / firmware. As yet another example, a circuit may be any portion of a hardware processor having software, including a digital signal processor, software, and one or more memories, that cooperate to cause a device, such as a terminal device or a network device, to perform various functions. In yet another example, a circuit may be a hardware circuit and / or a processor, such as a microprocessor or a portion thereof, that requires software / firmware for operation, but the software may not be present if not required for operation. As used herein, the term "circuitry" also includes implementations of only a hardware circuit or one or more processors, or a portion of a hardware circuit or one or more processors, and its (or their) accompanying software and / or firmware.

[0036] While the functions described herein may be performed in fixed and / or wireless network nodes in various exemplary embodiments, in other exemplary embodiments, the functions may be realized in user equipment equipment (e.g., a mobile phone, a tablet computer, a laptop computer, a desktop computer, a mobile IOT device, or a fixed IOT device). For example, the user equipment equipment may include corresponding capabilities described in connection with the fixed and / or wireless network nodes, as appropriate. The user equipment equipment may be a user equipment and / or a control device, such as a chipset or processor, configured to control the user equipment when installed in the user equipment. Examples of such functions include a bootstrap server function and / or a home subscriber server, which may be implemented in the user equipment equipment by providing the user equipment equipment with software configured to cause the user equipment equipment to perform from the perspective of these functions / nodes.

[0037] As mentioned above, in order to reduce the power consumption of the terminal device in wireless communication, the terminal device may be set in some power saving states or modes. For example, a Radio Resource Control (RRC) inactive state is proposed and defined by a 3GPP work item. Furthermore, as mentioned above, in order to further reduce power consumption, a solution is proposed by the 3GPP work item to enable SDT for a terminal device in an inactive state, so that the terminal device in an inactive RRC state can maintain the inactive RRC state while enabling data transmission.

[0038] Generally speaking, SDT is a procedure that allows data transmission while remaining in an RRC inactive state (i.e., without transitioning to an RRC connected state). Moreover, SDT is enabled on a radio bearer basis and is initiated by the terminal device only when the data volume of UL data that needs to be transmitted across all radio bearers configured for SDT is less than a data volume threshold (e.g., a configured volume) and the measured Reference Signal Receiving Power (RSRP) in the cell is higher than a configured threshold. Due to the data volume requirements, SDT is proposed to be applied to some specific application scenarios. Some exemplary application scenarios of SDT for smart terminal devices are: ● Traffic / data / packets from instant messaging services (e.g. WhatsApp, QQ, WhatsApp, MSN, etc.) and ● Heartbeat / keep-alive traffic / data / packets from some applications (instant applications, email applications, etc.) ● Push notifications from various apps, These may include, but are not limited to:

[0039] Some example application scenarios of SDT for non-smart terminal devices are: ● Traffic / data / packets from wearable devices (e.g. periodic location information, reference signals, etc.) and ● Periodic or aperiodic traffic / data / packets from sensors (e.g. temperature samples, pressure samples, parameters from industrial wireless sensor networks) and ● Periodic measurements from smart meter devices and smart meter network devices; These may include, but are not limited to:

[0040] Currently, two solutions have been proposed to enable SDT, including random access (RA) based SDT and configured grant (CG) based SDT.

[0041] For SDT based on RA, data for SDT is transmitted by using a random access channel (RACH) procedure, which includes a two-step RACH procedure and a four-step RACH procedure. More specifically, the first UL data is transmitted by a terminal device in an inactive state to a network device via message A of the two-step RACH procedure or message 3 of the four-step RACH procedure. For SDT based on CG, the first UL data is transmitted in a CG resource.

[0042] Please refer to FIG. 1A. FIG. 1A shows a signaling flow 100 for one-time SDT according to some embodiments. During operation, the network device sends an RRC release message to the terminal device (105). After receiving the RRC release message, the terminal device may transition to an inactive state. If the terminal device is in an inactive state and has SDT data (i.e., UL data) that needs to be sent to the network device, the terminal device sends an RRCResumeRequest message to the network device (110). The UL data may be sent together with the RRCResumeRequest. The network device sends an RRCRelease message to the terminal device (115). Additionally, the network device may send DL data (if any) together with the RRCRelease message to the terminal device.

[0043] In addition to the one-time SDT procedure described above, when the terminal device is in an RRC inactive state, the terminal device may send and receive multiple UL and DL packets as part of the same SDT procedure and may not transition to an RRC connected state.

[0044] Please refer to FIG. 1B. FIG. 1B illustrates a signaling flow 150 for an SDT procedure including an initial data transmission and a subsequent data transmission according to some embodiments. As shown in FIG. 1B, the network device transmits an RRC release message to the terminal device (155). After receiving the RRC release message, the terminal device may transition to an inactive state. Then, if the terminal device needs to transmit UL data to the network device, the terminal device transmits an RRCResumeRequest message and the UL data to the network device (160). In addition, the terminal device transmits a buffer status report (BSR) together with the RRCResumeRequest message, where the BSR indicates that there is remaining data that needs to be transmitted to the network device. The BSR from the terminal device informs the network device that there is remaining data that needs to be transmitted by the terminal device. The network device may respond with an indication of a subsequent transmission to the terminal device (165). Here, the indication may be an explicit RRC message or an implicit message (e.g., an UL grant for another transmission). Additionally, the network device may transmit DL data (if any) to the terminal device.

[0045] The terminal device then transmits the UL data and another BSR to the network device (170), which in response transmits the UL grant for dynamic authorization and additional DL data (if any) to the terminal device (175). The terminal device then transmits the UL data to the network device (180). In the example of FIG. 1B, the terminal device does not transmit a BSR to the network device because there is no data remaining to be transmitted. Thus, in view of the absence of a BSR, the network device may transmit an RRC release message and additional DL data to the terminal device (185).

[0046] Although some discussion / agreement has been made on SDT, some discussion and open problems remain to be solved. For example, it is desirable to propose and discuss technical details on the calculation of data amount for SDT, the generation and reporting of BSR for SDT, and the fallback from the SDT procedure based on 2-step RA to the SDT procedure based on 4-step RA. In this disclosure, the open problems listed above are described in detail.

[0047] As used herein, the term "small data transmission data" or "SDT data" refers to data that may be transmitted by a terminal device in an inactive, idle, and connected state. Generally speaking, "small data transmission data" or "SDT data" is carried on radio bearers (including signaling radio bearers (SRBs) and data radio bearers (DRBs)) configured for SDT or is generated / triggered by a service / function / application configured for SDT.

[0048] As used herein, the term "non-small data transmission data" or "non-SDT data" means data that is not permitted to be transmitted during an SDT procedure. Generally speaking, "non-small data transmission data" or "non-SDT data" is carried on radio bearers (including SRBs and DRBs) that are not configured for SDT or is generated / triggered by services / functions / applications that are not configured for SDT.

[0049] In the following, the SDT procedure is discussed in an exemplary scenario of a terminal device in an inactive state. However, such a specific exemplary scenario should be considered a limitation of the present disclosure. It should be understood that the exemplary embodiments discussed herein are also applicable to the terminal device scenario in an idle state if SDT is supported / enabled in the idle state.

[0050] In the following, the SDT procedure is used as an example of a transmission procedure to describe some exemplary embodiments of the present disclosure. It should be understood that the exemplary embodiments of the present disclosure are equally applicable to other disconnected transmissions (e.g., early data transmission (EDT) or preconfigured uplink resource (PUR)).

[0051] Hereinafter, the terms "executing an SDT", "during an SDT", and "timer for a running SDT" (and their equivalents) may be used interchangeably.

[0052] Also, hereinafter, when describing the data being processed, the terms "packet data convergence protocol (PDCP) packet," "PDCP data," "PDCP protocol data unit (PDU)," and "PDCP service data unit (SDU)" (and their equivalents) may be used interchangeably.

[0053] Additionally, hereinafter, when describing data being processed, the terms “radio link control (RLC) packet”, “RLC data”, “RLC PDU”, “RLC SDU” (and their equivalents) may be used interchangeably.

[0054] Moreover, below, operations discussed in some specific examples / cases / embodiments are used for illustrative purposes only and do not imply any limitations, i.e., such operations do not necessarily refer to the same example / case / embodiment. Furthermore, when describing a particular example / case / embodiment in relation to an example / case / embodiment, it is believed to be within the knowledge of a person skilled in the art to affect such operations in relation to other embodiments, whether or not explicitly described.

[0055] Additionally, although examples / cases / embodiments are discussed separately, it should be understood that such examples / cases / embodiments may be combined in any suitable manner, for example, an example / case / embodiment for calculating the amount of data for an SDT may be combined with an example / case / embodiment for processing a BSR.

[0056] Example environment FIG. 2 illustrates an exemplary communication environment 200 in which exemplary embodiments of the present disclosure can be implemented. The communication environment 200 includes a terminal device 210 and network devices 220-1 and 220-2 serving the terminal device 210. In the following text, the network devices 220-1 and 220-2 are collectively referred to as the network device 220 or individually referred to as the network device 220. Additionally, the network device 220 may provide more than one serving area to the terminal device 210. In the specific example of FIG. 2, the network device 220-1 provides cells 230-1, 230-2, and 230-3, and the network device 220-2 provides a cell 230-4. The cells 230-1 to 230-4 are collectively referred to as the serving cells 230 or individually referred to as the serving cells 230 in the following.

[0057] In communication environment 200, a link from terminal device 210 to network device 220 is referred to as UL, and a link from network device 220 to terminal device 210 is referred to as DL. In DL, network device 220 is a transmitting (TX) device (or transmitter) and terminal device 210 is a receiving (RX) device (or receiver). In UL, terminal device 210 is a TX device (or transmitter) and network device 220 is a RX device (or receiver).

[0058] In the example of FIG. 2, the terminal device 210 may be in different states (e.g., connected, inactive, and idle). When the terminal device 210 is in the connected state, the terminal device 210 may transmit data from all radio bearers. Furthermore, in some embodiments, when the terminal device 210 is in the idle state, the terminal device is generally not allowed to perform any data transmission except for certain scenarios (e.g., EDT or PUR). Additionally, when the terminal device 210 is in the inactive state, the terminal device is not allowed to transmit data that is not configured to have SDT during the SDT procedure, even though SDT is supported. Furthermore, the terminal device 210 in the inactive / idle state may transition to the connected state by resuming / establishing an RRC connection with the network device 220. Such a transition procedure may be initiated by the terminal device 210 or the network device 220.

[0059] Additionally, in the example of Fig. 2, the terminal device 210 may move over time. As shown in Fig. 2, the terminal device 210 is located at different locations over time. When moving, the terminal device 210 may communicate with a different cell 230 or a different network device 220, which may be achieved by a cell reselection procedure or a handover procedure, etc.

[0060] Communications in the communication environment 200 may conform to any suitable standard, including, but not limited to, Long Term Evolution (LTE), LTE-Evolution, LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), and the like. Furthermore, communications may be performed according to any generation of communication protocols now known or developed in the future. Examples of communication protocols include, but are not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, and fifth generation (5G) communication protocols.

[0061] It should be understood that the number of network devices, terminal devices, and cells and their connections are used for illustrative purposes only and do not imply any limitations. The communication environment 200 may include any suitable network devices, terminal devices, and cells suitable for implementing embodiments of the present disclosure. Although not shown, it should be understood that one or more additional terminal devices may be located within each cell. It should also be understood that in some examples, the communication environment 200 may include only homogeneous network deployments or only heterogeneous network deployments.

[0062] Example Procedure for Calculating Data Volume for an SDT As mentioned above, SDT is not applicable to data transmission of large amount of data. Therefore, it is proposed to use a volume threshold as SDT selection criterion. Specifically, if the volume of SDT data falls below the volume threshold, the terminal device is allowed to execute SDT. Otherwise, a non-SDT procedure is triggered.

[0063] Several options on how to calculate the amount of data for an SDT are proposed below. ● Option 1: The data amount used for the SDT selection criteria is calculated in the same way as the buffer size (BS), in other words the data amount for SDT is the sum of the Packet Data Convergence Protocol (PDCP) data amount and the Radio Link Control (RLC) data amount without considering the RLC and Medium Access Control (MAC) headers. ● Option 2: The data amount used for the SDT selection criterion is the size of the MAC protocol data unit (PDU), in other words, the data amount for SDT is the sum of the PDCP data amount, the RLC data amount, and the MAC / RLC / PDCP / RRC / service data adaptation protocol (SDAP) overhead. - Option 3: The data volume used for the SDT selection criterion is the PDCP data volume. ● Option 4: The amount of data used for the SDT selection criteria is calculated as the sum of BS over the RBs configured for SDT. ● Option 5: The amount of data used as the SDT selection criterion is left to the UE implementation.

[0064] Therefore, the amount of data used for the SDT selection criteria may be left to the UE implementation or may follow a unified process. Also, it is preferable that the amount of data used for the SDT selection criteria can be calculated in the same way as for conventional BSs, and it is expected that the amount of data used for the SDT selection criteria should be calculated as the sum of BSs across the RBs configured for SDT.

[0065] Please refer to FIG. 3. FIG. 3 shows a proposed method 300 for calculating the amount of data for the SDT. As shown in FIG. 3, in block 310, if there is new data that needs to be transmitted to the network device, the non-access stratum of the terminal device sends a request to the access stratum of the terminal device to resume the RRC connection. In block 320, the terminal device determines whether all the new data is from RBs configured to have an SDT. If so, in block 330, the terminal device calculates the amount of data for the SDT and determines whether the calculated amount of data is below a threshold. If the calculated amount of data is below a threshold, then the terminal device may trigger the SDT. Specifically, in block 340, the terminal device performs a PDCP / RLC re-establishment procedure, in block 350, resumes the RBs configured for the SDT, and in block 360, transmits data to the network device while remaining in an inactive state. If at least a portion of the new data is from a radio bearer that is not configured to have an SDT, or if the terminal device determines that the calculated amount of data exceeds a threshold, the process proceeds to block 370. At block 370, conventional RRC resumption procedures are performed.

[0066] In the above proposed process of Fig. 3, the operation of calculating the data amount for SDT is performed before performing the PDCP / RLC re-establishment procedure, which means that when calculating the data amount for SDT, there may still be stored data in the PDCP entity for SDT SRBs and stored data in the RLC entity for SRBs and UM RBs configured to have SDT. However, the above "stored" should not be taken into consideration when calculating the data amount for SDT.

[0067] Generally speaking, when an RB is suspended (i.e., not yet resumed), new data from higher layers (e.g., NAS) cannot be calculated as the PDCP and RLC data amount. In the above proposed process of Figure 3, the operation of calculating the data amount for SDT is performed before performing the RB resume procedure, which means that the new data has not yet arrived at the PDCP layer or the RLC layer when calculating the data amount for SDT. However, the amount of new data should be taken into account when calculating the data amount for SDT.

[0068] It can be seen that the above proposed process for calculating the data amount for the SDT cannot obtain the correct data amount for the SDT. According to an exemplary embodiment of the present disclosure, at least a part of the above-mentioned problems is solved.

[0069] In particular, when calculating the amount of data to be used for the SDT selection criteria, it should be understood that the described examples (i.e., exemplary embodiments for processing stored data, exemplary embodiments for obtaining the amount of new data, exemplary embodiments for proactively restarting the RS) may be implemented in any suitable combination.

[0070] Exemplary embodiments for processing stored data As described above, the previously stored data should not be taken into account when calculating the amount of data for the SDT, so it is expected that the terminal device 210 should discard the stored data before calculating the amount of data for the SDT.

[0071] According to some example embodiments of the present disclosure, a solution for communication is provided. In this solution, the terminal device 210 first discards stored data (e.g., PDCP packets, RLC packets) for at least one RB configured for SDT, and calculates the amount of data used by the terminal device 210 to determine whether to perform SDT after discarding the stored data. In this way, the stored data (e.g., data stored in PDCP and RLC entities) can be properly processed. In other words, when calculating the amount of data for SDT, the previously stored data is not taken into account, so that a correct data amount value can be obtained.

[0072] Reference is now made to Fig. 4. Fig. 4 illustrates a signaling flow 400 for calculating the amount of data for an SDT according to some embodiments of the present disclosure. For illustrative purposes, the signaling flow 400 will be described with reference to Fig. 2. The signaling flow 400 may involve a network device 220 and a terminal device 210.

[0073] In operation, the terminal device 210 discards (430) stored data for at least one RB configured for the SDT, and calculates (440) the amount of data used by the terminal device to determine whether to execute the SDT after discarding the stored data. In this way, the stored data not required for calculating the amount of data for the SDT can be appropriately processed.

[0074] In some example embodiments, the stored data to be discarded is stored in a layer 2 entity of terminal device 210. One example of a layer 2 entity is an RLC entity. Another example of a layer 2 entity is a PDCP entity.

[0075] Additionally, the stored data may be stored data that is not required to calculate the amount of data for the SDT. For the RLC layer, the stored data for the RBs configured for the SDT includes, but is not limited to, RLC SDUs, RLC SDU segments, and RLC PDUs. For the PDCP layer, the stored data for the RBs configured for the SDT includes, but is not limited to, PDCU SDUs and PDUs.

[0076] Additionally, the operation of discarding the stored data for the RBs configured for SDT may be implemented in any suitable manner. In one example, terminal device 210 may discard the stored data by performing a re-establishment procedure for the RBs configured for SDT in a layer 2 entity of terminal device 210.

[0077] An example of a re-establishment procedure is the RLC re-establishment procedure, during which the terminal device 210 discards all RLC SDUs, RLC SDU segments and RLC PDUs (if any), stops and resets all timers, and resets all state variables to their initial values.

[0078] Another example of a re-establishment procedure is a PDCP re-establishment procedure. In some exemplary embodiments, when higher layers request PDCP entity re-establishment, the terminal device 210 sets TX_NEXT to initial values ​​for UM DRBs and SRBs, and discards all stored PDCP SDUs and PDCP PDUs for SRBs.

[0079] In some example embodiments, the re-establishment procedure for RBs configured for SDT is triggered / configured by the network device 220. In one example, the IE reestablishPDCP may be used by the network device 220 to indicate to the terminal device 210 to perform a PDCH re-establishment procedure. In another example, the IE reestablishRLC may be used by the network device 220 to indicate to the terminal device 210 to perform a PLC re-establishment procedure.

[0080] In another exemplary embodiment, the terminal device 210 may discard the stored data by performing a procedure to discard the PDCP SDU. In some exemplary embodiments, if the discardTimer expires for a PDCP SDU or if successful delivery of the PDCP SDU is confirmed by a PDCP status report, the sending PDCP entity should discard the PDCP SDU together with the corresponding PDCP data PDU. Furthermore, if the corresponding PDCP data PDU has already been submitted to the lower layer, the discard is indicated to the lower layer. For an SRB, if the upper layer requests the discard of the PDCP SDU, the PDCP entity should discard all stored PDCP SDUs and PDCP PDUs.

[0081] In some example embodiments, the IE discardOnPDCP may be indicated by the network device 220 to indicate to the terminal device 210 that the PDCP entity should discard stored SDUs and PDUs.

[0082] Furthermore, the operation of discarding the stored data may be performed at any suitable occasion before calculating the amount of data. As an example, when the terminal device receives a message for suspending an RRC connection (e.g., an RRC release message) including information about at least one RB configured for an SDT (410), the terminal device 210 discards the stored data about the at least one RB configured for an SDT.

[0083] As one particular exemplary embodiment, when the terminal device 210 (i.e., UE) receives an RRCRelease with suspendConfig and there is at least one RB configured to have an SDT, the terminal device 210 discards all stored data (e.g., PDCU SDUs and PDUs) for the RBs (including SRBs and DRBs) configured to have an SDT.

[0084] As another particular exemplary embodiment, when the terminal device 210 (i.e., UE) receives an RRCRelease with suspendConfig and there is at least one RB configured to have an SDT, the terminal device 210 discards all stored data (e.g., RLC SDUs, RLC SDU segments, and RLC PDUs) for the RBs (including SRBs and DRBs) configured to have an SDT, in particular for the SRBs and UM DRBs configured to have an SDT.

[0085] Additionally, in some exemplary embodiments, a message to suspend an RRC connection may be used as an implicit request for PDCP SDU discard or PDCP re-establishment for SRBs. That is, when the terminal device 210 receives a message to suspend an RRC connection including an SDT configuration (e.g., suspendConfig), the terminal device 210 may trigger / decide to discard stored data. As one specific example, the terminal device 210 performs a PDCP SDU discard procedure or a PDCP re-establishment procedure implicitly. As another specific example, when the terminal device 210 receives an RRC release message including an SDT configuration (e.g., suspendConfig), the terminal device 210 performs an RLC re-establishment procedure implicitly for RBs configured to have an SDT.

[0086] Alternatively, in some exemplary embodiments, the message for suspending the RRC connection includes an indication indicating that the stored data for at least one RB configured for SDT is discarded. In other words, the operation of discarding the stored data may be set / triggered by the network device 220. One example of the indication is the discard on information element (IE) packet data convergence protocol (discardOnPDCP). Another example of the indication is the IE reestablish packet data convergence protocol (reestablishPDCP). Yet another example of the indication is the IE reestablish radio resource control (reestablishRLC). As one specific example, the network device 220 sets the discardOnPDCP IE or the reestablishPDCP IE for the RBs configured to have SDT in the RRC release message with suspendConfig. As another specific example, the network device 220 sets the reestablishRLC IE for the RBs configured to have SDT in the RRC release message with suspendConfig.

[0087] In addition to discarding stored data in response to receiving a message to suspend the RRC connection as described above, when the terminal device 210 is in an inactive state, if the terminal device 210 determines that all new data is from RBs configured for SDT (420), the terminal device 210 may discard stored data.

[0088] In some exemplary embodiments, the terminal device 210 discards stored data (e.g., PDCP packets) for RBs configured for SDT during the RRC resumption procedure before calculating the amount of data for the SDT. As a specific example, when the terminal device 210 is in an inactive state and all new data is from RBs configured to have SDT, the terminal device 210 discards all stored data (e.g., PDCU SDUs and PDUs) for RBs (including SRBs and DRBs) configured to have SDT. For example, the terminal device 210 implicitly performs a PDCP SDU discard procedure or a PDCP re-establishment procedure for the RBs before calculating the amount of data for the SDT status check.

[0089] In some exemplary embodiments, the terminal device 210 discards stored data (e.g., RLC packets) for RBs configured for SDT during the RRC resumption procedure before calculating the amount of data for SDT. As a specific example, when the terminal device 210 is in an inactive state and all new data is from RBs configured to have SDT, the terminal device 210 discards all stored data (e.g., RLC SDUs, RLC SDU segments, and RLC PDUs) for RBs (including SRBs and DRBs) configured to have SDT, especially for SRBs and UM DRBs configured to have SDT, before calculating the amount of data for SDT status check. For example, the terminal device 210 implicitly performs RLC re-establishment for RBs configured to have SDT before calculating the amount of data for SDT status check.

[0090] For ease of understanding only, reference is made to Figures 5A and 5B. Figures 5A and 5B show methods 500 and 550 for processing stored data. In the specific example of Figure 5A, the terminal device 210 discards stored data upon receiving a message to suspend the RRC connection. As shown in Figure 5A, in block 505, the terminal device 210 discards stored data (e.g., RLC SDUs, RLC SDU segments, RLC PDUs, PDCU SDUs, and PDCP PDUs) in response to receiving a message to suspend the RRC connection (e.g., an RRC release message), as described above. In block 510, if there is new data that needs to be sent to the network device 220, the NAS layer of the terminal device 210 sends a request to the access layer of the terminal device 210 to resume the RRC connection.

[0091] In block 515, the terminal device 210 determines whether all the new data is from RBs configured to have an SDT. If so, in block 520, the terminal device 210 calculates the amount of data for the SDT and determines whether the calculated amount of data is below a threshold. If the calculated amount of data is below a threshold, the terminal device 210 may trigger the SDT. Specifically, in block 525, the terminal device 210 performs a PDCP / RLC re-establishment procedure, in block 530, resumes the RBs configured for the SDT, and in block 535, transmits data to the network device 220 while remaining in an inactive state. If at least some of the new data is from RBs not configured to have an SDT or if the terminal device 210 determines that the calculated amount of data exceeds a threshold, the process proceeds to block 540. In block 540, a conventional RRC resumption procedure is performed.

[0092] Now, reference is made to FIG. 5B. In FIG. 5B, when the terminal device 210 is in an inactive state, the terminal device 210 discards stored data when it determines that all new data is from RBs configured for SDT. For example, the terminal device 210 discards stored data during an RRC resumption procedure before calculating the amount of data. In FIG. 5A and FIG. 5B, the same operations / elements are given the same reference numbers. Here, the same description is omitted for brevity.

[0093] As shown in FIG. 5B, after the terminal device 210 determines that all new data is from the RBs configured for SDT, the terminal device 210 discards the stored data. Furthermore, as described above, the terminal device 210 may discard the stored data by performing a re-establishment procedure for the RBs configured for SDT in the layer 2 entity of the terminal device 210 or by performing a procedure to discard PDCP SDUs. If the terminal device 210 discards the stored data by performing the re-establishment procedure, the following re-establishment procedure (at block 525) may be omitted. Specifically, the operation at block 525 may be omitted by the terminal device 210.

[0094] 6 is a flow chart of an example method 600 according to some embodiments of the present disclosure. For example, the method 600 may be implemented in the terminal device 210 as shown in FIG.

[0095] In block 610, terminal device 210 discards stored data for at least one RB configured for SDT.

[0096] In block 620, the terminal device 210 calculates the amount of data used by the terminal device 210 to determine whether to perform SDT after discarding the stored data.

[0097] In some exemplary embodiments, when the terminal device 210 receives a message to suspend the radio resource control connection from the network device 220, the message including information regarding at least one RB configured for SDT, the terminal device 210 discards the stored data about the at least one RB configured for SDT.

[0098] In some exemplary embodiments, when terminal device 210 is in an inactive state, if it determines that all new data is from at least one RB configured for SDT, terminal device 210 discards the stored data for the at least one RB configured for SDT.

[0099] In some exemplary embodiments, the message for suspending the radio resource control connection further includes an indication indicating that stored data for at least one RB configured for SDT is to be discarded.

[0100] In some exemplary embodiments, the indication is one of the following information elements: discard on packet data convergence protocol (discardOnPDCP), reestablish packet data convergence protocol (reestablishPDCP), or reestablish radio resource control (reestablishRLC).

[0101] In some exemplary embodiments, the stored data to be discarded is stored in a layer 2 entity of terminal device 210, which is an RLC entity or a PDCP entity.

[0102] In some exemplary embodiments, discarding the stored data for the at least one RB configured for SDT includes performing a re-establishment procedure for the at least one RB configured for SDT in a layer 2 entity of the terminal device 210.

[0103] In some example embodiments, discarding the stored data for the at least one RB configured for SDT includes performing a procedure to discard PDCP SDUs.

[0104] In some example embodiments, the stored data for at least one RB includes at least one RLC SDU, at least one RLC SDU segment, at least one RLC PDU, and at least one PDCP SDU, or at least one PDCP PDU.

[0105] In some exemplary embodiments, terminal device 210 includes circuitry configured to discard stored data for at least one RB configured for SDT, and further configured to calculate an amount of data used by terminal device 210 to determine whether to perform SDT after discarding the stored data.

[0106] In some demonstrative embodiments, the circuitry is further configured to discard the stored data for the at least one RB configured for SDT if the circuitry receives a message to suspend the radio resource control connection from the network device 220, the message including information regarding the at least one RB configured for SDT.

[0107] In some demonstrative embodiments, the circuitry is further configured to discard stored data for the at least one RB configured for SDT when the terminal device 210 is in an inactive state if it determines that all new data is from the at least one RB configured for SDT.

[0108] In some exemplary embodiments, the message for suspending the radio resource control connection further includes an indication indicating that stored data for at least one RB configured for SDT is to be discarded.

[0109] In some exemplary embodiments, the indication is one of the following information elements: discard on packet data convergence protocol (discardOnPDCP), reestablish packet data convergence protocol (reestablishPDCP), or reestablish radio resource control (reestablishRLC).

[0110] In some exemplary embodiments, the stored data to be discarded is stored in a layer 2 entity of terminal device 210, which is an RLC entity or a PDCP entity.

[0111] In some exemplary embodiments, the circuitry is further configured to perform, at a layer 2 entity of the terminal device 210, a re-establishment procedure for at least one RB configured for SDT.

[0112] In some exemplary embodiments, the circuitry is further configured to perform a procedure to discard PDCP SDUs.

[0113] In some example embodiments, the stored data for at least one RB includes at least one RLC SDU, at least one RLC SDU segment, at least one RLC PDU, and at least one PDCP SDU, or at least one PDCP PDU.

[0114] 7 is a flow chart of an example method 700 according to some embodiments of the present disclosure. For example, the method 700 may be implemented in the network device 220 as shown in FIG.

[0115] In block 710, the network device 220 sends a message to the terminal device 210 to suspend the radio resource control connection, the message including information regarding at least one of the RBs that has been configured by the network device 220 for the SDT, and an instruction to instruct the terminal device 210 to discard stored data for the at least one RB configured for the SDT.

[0116] In some exemplary embodiments, network device 220 includes circuitry for sending a message to terminal device 210 to suspend the radio resource control connection, the message including information regarding at least one of the RBs configured by network device 220 for SDT and an instruction to instruct terminal device 210 to discard stored data for the at least one RB configured for SDT.

[0117] Exemplary embodiments for obtaining the amount of new data As described above, the amount of new data should be taken into consideration when calculating the amount of data for the SDT. Therefore, it is expected that the terminal device 210 may obtain information about the amount of new data before calculating the amount of data for the SDT.

[0118] According to some exemplary embodiments of the present disclosure, a solution for communication is provided. In this solution, the terminal device 210 obtains information on the amount of new data that needs to be transmitted to the network device 220 from a layer of the terminal device 210 higher than the PDCP layer, which information is provided to a layer of the terminal device responsible for calculating the amount of data used by the terminal device to decide whether to perform SDT. Then, if all the new data is from at least one RB configured for SDT, the terminal device 210 calculates the amount of data based at least in part on the information. Thus, the terminal device 210 may obtain information on the amount of new data before calculating the amount of data for the SDT.

[0119] Please refer to Fig. 8. Fig. 8 illustrates an exemplary method 800 performed by terminal device 210 to obtain the amount of new data.

[0120] In block 810, the terminal device 210 obtains information about the amount of new data that needs to be transmitted to the network. In particular, the information is provided from a layer of the terminal device 210 higher than the PDCP layer to a layer of the terminal device 210 responsible for calculating the amount of data used by the terminal device 210 to decide whether to perform SDT. In this way, even if the RB configured for SDT is suspended, the layer responsible for the amount of data can obtain information about the amount of new data.

[0121] Moreover, an example of a layer higher than the PDCP layer is the SDAP layer. In some exemplary embodiments, assuming that a new packet is seen by the SDAP layer, the SDAP layer / entity provides information about the amount of data to a layer in charge of calculating the amount of data (e.g., a lower layer (MAC) or an upper layer (RRC)). Furthermore, the terminal device 210 should consider SDAP SDUs, SDAP PDUs, and SDAP control PDUs as the amount of SDAP data.

[0122] Another example of a layer above the PDCP layer is a higher layer (e.g., NAS). In some exemplary embodiments, the NAS layer / entity provides the amount of new data to a layer (e.g., lower layer (MAC)) responsible for calculating the amount of data.

[0123] In block 820, the terminal device 210 determines whether all the new data is from at least one RB configured for SDT. If so, in block 830, the terminal device 210 calculates the amount of data based at least in part on the information. In other words, in addition to factors of the PDCP data amount and the RLC data amount, the terminal device 210 (e.g., by the MAC layer or the RRC layer) calculating the amount of data for the SDT status check needs to consider the SDAP data amount or the higher layer data amount for the RBs configured to have SDT.

[0124] An example of a layer responsible for calculating the amount of data is the MAC layer. Another example of a layer responsible for calculating the amount of data is the RRC layer.

[0125] In some exemplary embodiments, terminal device 210 calculates only the amount of data for RBs configured to have SDT for SDT status check.

[0126] For ease of understanding only, reference is made to FIG. 9. FIG. 9 illustrates a method 900 for obtaining an amount of new data. As shown in FIG. 9, in block 910, if there is new data that needs to be transmitted to the network device 220, the NAS of the terminal device 210 transmits a request to the access stratum of the terminal device 210 to resume the RRC connection. Furthermore, as described above, the NAS of the terminal device 210 may provide information regarding the amount of new data. In this case, the information regarding the amount may be provided together with the RRC resume request.

[0127] In block 920, terminal device 210 determines whether all new data is from RBs configured to have SDT. If so, in block 930, terminal device 210 calculates the amount of data for the SDT and determines whether the calculated amount of data is below a threshold. In the example of FIG. 9, terminal device 210 calculates the amount of data based at least in part on information about the amount of new data. As described above, the amount of new data may be provided by a layer higher than the PDCP layer (e.g., the NAS or SDAP layer) at any suitable time and in any suitable manner.

[0128] If the calculated amount of data falls below the threshold, the terminal device 210 may trigger an SDT as a result. Specifically, the terminal device 210 performs a PDCP / RLC re-establishment procedure in block 940, resumes the RBs configured for SDT in block 950, and transmits data to the network device 220 while remaining in an inactive state in block 960. If at least some of the new data is from RBs not configured for SDT or if the terminal device 210 determines that the calculated amount of data exceeds the threshold, the process proceeds to block 970. In block 970, a conventional RRC resumption procedure is performed.

[0129] In some example embodiments, terminal device 210 comprises circuitry configured to obtain information regarding an amount of new data that needs to be transmitted to network device 220, the information being provided from a layer of terminal device 210 above the PDCP layer to a layer of the terminal device responsible for calculating the amount of data used by the terminal device to determine whether to perform SDT. The circuitry is further configured to calculate the amount of data based at least in part on the information if all the new data is from at least one RB configured for SDT.

[0130] In some exemplary embodiments, the layer responsible for calculating the amount of data is the medium access control layer or the radio resource control layer.

[0131] In some exemplary embodiments, the layer above the PDCP layer is a non-access stratum or a service data adaptation protocol layer.

[0132] Exemplary embodiments for proactively restarting RS As described above, in the conventional proposed solution for calculating the amount of data for the SDT shown in FIG. 3, the operation of calculating the amount of data for the SDT is performed before executing the RB restart procedure, which means that when calculating the amount of data for the SDT, new data has not yet arrived at the layer responsible for calculating the amount of data for the SDT.

[0133] According to some exemplary embodiments of the present disclosure, a solution for communication is provided. In this solution, when the terminal device 210 detects that all new data is from at least one RB configured for SDT, the terminal device 210 in an inactive state resumes at least one RB configured for SDT. The terminal device 210 calculates the amount of data used by the terminal device 210 to determine whether to perform SDT. In this way, when calculating the amount of data for SDT, the new data is properly processed because the new data has already arrived at the layer responsible for calculating the amount of data for SDT.

[0134] Please refer to Fig. 10. Fig. 10 illustrates an example method 1000 performed by the terminal device 210 for proactively restarting an RS.

[0135] In block 1010, if the terminal device 210 detects that all new data is from at least one RB configured for SDT, the terminal device 210, which is in an inactive state, resumes the at least one RB configured for SDT.

[0136] In block 1020, terminal device 210 calculates the amount of data used by terminal device 210 to determine whether to perform SDT.

[0137] Additionally, in some exemplary embodiments, if terminal device 210 determines not to perform SDT, terminal device 210 suspends any RBs that were previously resumed.

[0138] As a specific exemplary embodiment, if all the new data is from the RB configured to have SDT, the terminal device 210 resumes the RB configured to have SDT before calculating the amount of data for SDT status check. After the RB configured to have SDT is resumed, the SDAP layer processes and forwards the data to the PDCP layer, so the new data is regarded as a PDCP PDU. In the following, if the terminal device 210 determines that the SDT condition is not met, the terminal device 210 suspends the RB configured to have SDT. Otherwise, the terminal device 210 executes the SDT with the network device 220.

[0139] For ease of understanding only, reference is made to Fig. 11, which illustrates a method 1100 for proactively resuming an RS. As shown in Fig. 11, in block 1110, if there is new data that needs to be sent to the network device 220, the NAS of the terminal device 210 sends a request to the access stratum of the terminal device 210 to resume the RRC connection.

[0140] In block 1120, the terminal device 210 determines whether all new data is from RBs configured to have SDT. If so, in block 1130, the terminal resumes the RBs configured for SDT. As a result, the new data may be passed to a layer responsible for calculating the amount of data for the SDT. In block 1140, the terminal device 210 calculates the amount of data for the SDT and determines whether the calculated amount of data has fallen below a threshold.

[0141] If the calculated amount of data falls below the threshold, the terminal device 210 may trigger SDT as a result. Specifically, the terminal device 210 performs a PDCP / RLC re-establishment procedure in block 1150 and transmits data to the network device 220 while remaining in an inactive state in block 1160. Otherwise, if the calculated amount of data exceeds the threshold, the process proceeds to block 1170. In block 1170, the terminal device 210 suspends RBs configured for SDT and then performs a conventional RRC resumption procedure in block 1180.

[0142] Further, as shown in FIG. 11, if the terminal device 210 determines that at least some of the new data is from an RB that is not configured to have an SDT, the process proceeds to block 1180, where the terminal device 210 also performs a conventional RRC resumption procedure.

[0143] In some exemplary embodiments, terminal 210 includes circuitry configured to resume an RB configured for SDT when terminal 210 detects that all new data is from at least one RB configured for SDT, and further configured to calculate an amount of data used by terminal 210 to determine whether to perform SDT.

[0144] In some exemplary embodiments, the circuitry is further configured to suspend at least one radio bearer configured for the small data transmission in accordance with the determination not to perform the small data transmission.

[0145] Example Process for Handling BSR As mentioned above, if the SDT data cannot be transmitted within the first / original SDT or if there is remaining SDT that needs to be transmitted, the terminal device 210 will transmit a BSR to the network device 220. Therefore, it is expected that the reported BSR should indicate the actual status of the remaining SDT data.

[0146] Generally speaking, there are multiple logical channels in a communication system, and the multiple logical channels are divided into multiple logical channel groups. When reporting a BSR, the terminal device 210 notifies a BSR for each logical channel group. Furthermore, each RB may correspond to one or more logical channels.

[0147] For a terminal device that performs SDT, there may be data stored in both RBs configured to have SDT (not suspended during SDP procedure) and RBs not configured to have SDT (suspended during SDP procedure). In a conventional solution for processing BSR, the terminal device (e.g., the MAC layer of the terminal device) may include both suspended and non-suspended RBs in the BSR calculation. If the terminal device generates a BSR using the conventional solution, the network device 220 cannot obtain the actual status of the remaining SDT data. For example, if a non-SDT RB and an SDT RB are in the same logical channel group, a very large amount of data may be reported to the network device 220. In such a case, the network device 220 will be very confused about whether it can perform the subsequent SDT.

[0148] Exemplary embodiments for handling BSR in a terminal device As mentioned above, it is expected that terminal device 210 (eg, the MAC layer of terminal device 210) should not consider RBs that are not configured to have SDT during the SDT procedure for BSR calculation.

[0149] According to some exemplary embodiments of the present disclosure, a solution for communication is provided, in which when the terminal device 210 is performing SDT, the terminal device 210 should not consider RBs that are not configured to have SDT for BSR calculation, so that the network device 220 can have correct buffer size information of SDT data so that it can make an appropriate decision on whether a subsequent transmission is feasible.

[0150] Reference is now made to Fig. 12. Fig. 12 illustrates a signaling flow 1200 for processing a BSR according to some embodiments of the present disclosure. For illustrative purposes, the signaling flow 1200 will be described with reference to Fig. 2. The signaling flow 1200 may involve a network device 220 and a terminal device 210.

[0151] In operation, terminal device 210 generates 1210 a BSR during the SDT to indicate buffer status, and the BSR is associated with a particular RB or logical channel.

[0152] In some exemplary embodiments, the BSR is associated with RBs configured for SDT. Alternatively or additionally, in some exemplary embodiments, the BSR is associated with BRs that are not suspended. Alternatively or additionally, in some exemplary embodiments, the BSR is associated with a logical channel that corresponds to an RB configured for SDT. Alternatively or additionally, in some exemplary embodiments, the BSR is associated with a logical channel that corresponds to an RS that is not suspended.

[0153] As a specific example, when performing SDT, the terminal device 210 (e.g., the MAC layer of the terminal device 210) should not consider logical channels corresponding to suspended RBs (i.e., RBs not configured to have SDT) for BSR calculation. In other words, the terminal device 210 (e.g., the MAC layer of the terminal device 210) should only consider CCCHs and logical channels corresponding to non-suspended RBs (i.e., RBs configured to have SDT) for BSR calculation during SDT.

[0154] In addition, as described above, if a non-SDT RB and an SDT RB are in the same logical channel group, the network device 220 will be very confused about whether it can perform a subsequent SDT. Therefore, an improved operation may be performed on such a logical channel group.

[0155] In some exemplary embodiments, when a logical channel group includes at least one logical channel corresponding to an RB that is suspended and at least one other logical channel corresponding to an RB that is not suspended, terminal device 210 generates a BSR without taking into account RBs that are not configured for SDT.

[0156] In some exemplary embodiments, the terminal device 210 generates a BSR for multiple logical channel groups. Furthermore, the terminal device 210 may use multiple buffer size fields to indicate the buffer status of each logical channel group. For logical channel groups that include at least one logical channel corresponding to a suspended RB and at least one other logical channel corresponding to a non-suspended RB, the respective buffer sizes are calculated without considering the RBs that are not configured for SDT (i.e., suspended).

[0157] In some other example embodiments, when a logical channel group includes at least one logical channel corresponding to a suspended RB and at least one other logical channel corresponding to a non-suspended RB, terminal device 210 may generate a BSR taking into account both the non-suspended RS (i.e., SDT RB) and the suspended RS (i.e., non-SDT RB). In this case, network device 220 may consider the reported BSR to indicate SDT data if the value of the reported BSR is below a threshold.

[0158] Alternatively or additionally, in some exemplary embodiments, if a logical channel group includes at least one logical channel corresponding to a suspended RB and at least one other logical channel corresponding to a non-suspended RB, the terminal device 210 generates a BSR without taking into account the suspended RB.

[0159] Alternatively or additionally, in some exemplary embodiments, if a logical channel group includes at least one logical channel corresponding to an RB that is suspended and at least one other logical channel corresponding to an RB that is not suspended, the terminal device 210 generates a BSR without taking into account the logical channels corresponding to RBs that are not configured for SDT.

[0160] Alternatively or additionally, in some exemplary embodiments, if a logical channel group includes at least one logical channel corresponding to a suspended RB and at least one other logical channel corresponding to a non-suspended RB, the terminal device 210 generates a BSR without taking into account the logical channel corresponding to the suspended RB.

[0161] In some example embodiments, if each logical channel included in a logical channel group corresponds to a non-suspended RB, terminal device 210 may or may not transmit a BSR for that logical channel group, because network device 220 will not be confused about such a BSR.

[0162] As a specific example, when executing SDT, if a logical channel group includes both a logical channel of an SDT RB (an RB that is not paused) and a logical channel of a non-SDT RB (paused), the terminal device 210 does not include the logical channel of the paused RB in the BSR of the logical channel group.

[0163] In some example embodiments, for purposes of MAC buffer status reporting, the transmitting PDCP entity should consider the following as the PDCP data amount: PDCP SDUs for which a PDCP data PDU has not been constructed, PDCP data PDUs that have not been submitted to lower layers, PDCP control PDUs, PDCP SDUs that are retransmitted in case of AM DRBs, and PDCP data PDUs that are retransmitted in case of AM DRBs.

[0164] In some example embodiments, for purposes of MAC buffer status reporting, the UE should consider the RLC data amount to include RLC SDUs and RLC SDU segments not included in an RLC data PDU, RLC data PDUs waiting for initial transmission, and RLC data PDUs waiting for retransmission (RLC AM).

[0165] Additionally, in some example embodiments, if a status PDU has already been triggered and t-StatusProhibit is not running or has already expired, the UE should estimate the size of the status PDU to be transmitted at the next transmission opportunity and count it as part of the RLC data amount.

[0166] After generating the BSR, the terminal device 210 transmits the BSR to the network device 220 (1220).

[0167] 13 is a flowchart of an example method 1300 according to some embodiments of the present disclosure. For example, the method 1300 may be implemented in the terminal device 210 as shown in FIG.

[0168] In block 1310, the network device 220 and the terminal device 210 running the SDT generate a BSR indicating a buffer status associated with at least one of RBs configured for the SDT, non-suspended RBs, logical channels corresponding to RBs configured for the SDT, or logical channels corresponding to non-suspended RBs.

[0169] In block 1320 , the terminal device 210 transmits the BSR to the network device 220 .

[0170] In some exemplary embodiments, terminal device 210 comprises circuitry configured to generate a BSR indicating a buffer status associated with at least one of RBs configured for SDT, non-suspended RBs, logical channels corresponding to RBs configured for SDT, or logical channels corresponding to non-suspended RBs, and further configured to transmit the BSR to network device 220.

[0171] 14 is a flowchart of an example method 1400 according to some embodiments of the present disclosure. For example, the method 1400 may be implemented in a terminal device 210 as shown in FIG.

[0172] In block 1410, terminal device 210 determines whether the logical channel group includes at least one logical channel corresponding to a suspended RB and at least one other logical channel corresponding to a non-suspended RB.

[0173] If so, in block 1420, the network device 220 and the terminal device 210 running the SDT generate a BSR for the logical channel group without considering at least one of RBs not configured for SDT, RBs that are suspended, logical channels corresponding to RBs not configured for SDT, or logical channels corresponding to RBs that are suspended. In block 1430, the terminal device 210 transmits the BSR to the network device 220.

[0174] In some exemplary embodiments, the terminal device 210 includes a circuit configured to generate a BSR for a logical channel group including at least one logical channel corresponding to a suspended RB and at least one other logical channel corresponding to a non-suspended RB, when the logical channel group includes at least one logical channel corresponding to a suspended RB, and the terminal device 210 performing the SDT with the network device 220 does not consider at least one of the RBs not configured for SDT, the suspended RBs, the logical channels corresponding to the RBs not configured for SDT, or the logical channels corresponding to the suspended RBs. The circuit is further configured to transmit the BSR to the network device 220.

[0175] Exemplary embodiments for handling BSR in a network device As mentioned above, if a non-SDT RB and an SDT RB are in the same logical channel group, the network device will be very confused about whether it can execute the subsequent SDT or not.

[0176] According to some exemplary embodiments of the present disclosure, a solution for communication is provided, in which the network device 220 configures the logical channel of the SDT RB and the logical channel of the non-SDT RB (i.e., not configured for SDT) into separate logical channel groups. Thus, no additional operation is required in the terminal device 210 when notifying the BSR for the SDT.

[0177] 15 is a flowchart of an example method 1500 according to some embodiments of the present disclosure. For example, the method 1500 may be implemented in the network device 220 as shown in FIG.

[0178] In block 1510, the network device 220 configures at least one RB for the SDT, the RB corresponding to a plurality of logical channels included in the at least one logical channel group. Each logical channel included in the at least one logical channel group corresponds to the RB configured for the SDT.

[0179] In block 1520, the network device 220 indicates the result of the setting to the terminal device 210.

[0180] The network device 220 may indicate the result of the configuration to the terminal device 210 by any suitable message. One exemplary message is an RRC release message. Another exemplary message is an RRC configuration message. Another exemplary message is an RRC reconfiguration message.

[0181] In some exemplary embodiments, the network device 220 includes a circuit configured to configure at least one RB corresponding to a plurality of logical channels included in at least one logical channel group for SDT, where each logical channel included in the at least one logical channel group corresponds to an RB configured for SDT, and the circuit is further configured to indicate the configured result to the terminal device 210.

[0182] In some exemplary embodiments, the circuitry is further configured to transmit the set result to the terminal device 210 via one of a radio resource control release message, a radio resource control configuration message, or a radio resource control reconfiguration message.

[0183] An exemplary process for falling back to the 4-step RA SDT Conventionally, the parameter msgA-TransMax is used to enable fallback from a 2-step RA procedure for non-SDT to a 4-step RA procedure for non-SDT. The parameter msgA-TransMax refers to the maximum number of MSGA transmissions when both 4-step and 2-step RA resources are configured. Specifically, for the 2-step RA procedure, if the maximum number is configured (i.e., msgA-TransMax is configured), and the 2-step RA procedure is not completed successfully even after transmitting message A msgA-TransMax times, the terminal device falls back to the 4-step RA procedure (i.e., the terminal device performs an RA resource selection procedure for the 4-step RA).

[0184] As mentioned above, it has been agreed to support both SDT based on 2-step RA and SDT based on 4-step RA. In this case, if the terminal device fails to transmit SDT data via the 4-step RA procedure, it is expected that the terminal device may fall back to the 4-step RA SDT.

[0185] However, the resources for RA for non-SDT and RA for SDT are different, which means that the conventional parameter msgA-TransMax cannot be used for SDT based on RA.

[0186] According to some exemplary embodiments of the present disclosure, a solution for communication is provided, in which one parameter (which may be referred to as msgA-TransMaxSDT) is specifically set for RA-based SDT, so that the terminal device 210 can gracefully fall back from 2-step RA-based SDT to 4-step RA-based SDT.

[0187] Reference is now made to Fig. 16. Fig. 16 illustrates a signaling flow 1600 for processing a BSR according to some embodiments of the present disclosure. For illustrative purposes, the signaling flow 1600 will be described with reference to Fig. 2. The signaling flow 1600 may involve the network device 220 and the terminal device 210.

[0188] In some example embodiments, to support fallback from 2-step RA-SDT to 4-step RA-SDT, the network device 220 may, for example, configure one parameter (e.g., msgA-TransMaxSDT) specifically for SDT (1610). The parameter msgA-TransMaxSDT is the maximum number of transmissions of MSG A when both 4-step RA resources for SDT and 2-step RA type RA resources for SDT are configured.

[0189] In operation, when terminal device 210 is configured to have both a four-step RA procedure resource for SDT and a two-step RA procedure resource for SDT, terminal device 210 receives a parameter (e.g., msgA-TransMaxSDT) indicating the maximum number of times that terminal device 210 transmits message A of the two-step RA procedure for SDT.

[0190] Then, the terminal device 210 executes the SDT with the network device 220 based on the maximum number of times (1620).

[0191] In some exemplary embodiments, if the number of failures to transmit message A of the two-step RA procedure for SDT exceeds the maximum number of times, the SDT is executed by falling back to executing a four-step RA procedure for SDT, and the four-step RA procedure reuses the same preamble group configured for the two-step RA procedure.

[0192] As a specific example, when the terminal device 210 is performing a 2-step RA SDT, if msgA-TransMaxSDT is set and the RA procedure for SDT is not completed successfully even after transmitting the message msgA-TransMaxSDT times, the UE falls back to performing an SDT based on a 4-step RACH using the same preamble group as in the 2-step RA SDT.

[0193] 17 is a flowchart of an example method 1700 according to some embodiments of the present disclosure. For example, the method 1700 may be implemented in the terminal device 210 as shown in FIG.

[0194] In block 1710, in operation, if the terminal device 210 is configured to have both a four-step RA procedure resource for the SDT and a two-step RA procedure resource for the SDT, the terminal device 210 receives a parameter from the network device 220 indicating the maximum number of times the terminal device 210 transmits message A of the two-step RA procedure for the SDT.

[0195] In block 1720, the terminal device 210 performs an SDT with the network device 220 based on the maximum number of times.

[0196] In some exemplary embodiments, if the number of times that a message A of a two-step RA procedure for SDT fails to be transmitted exceeds a maximum number of times, the terminal device 210 performs the SDT by falling back to performing a four-step RA procedure for SDT, and the four-step RA procedure reuses the same preamble group configured for the two-step RA procedure.

[0197] In some exemplary embodiments, terminal device 210 comprises circuitry configured to, in operation, receive from network device 220 a parameter indicating a maximum number of times to transmit message A of a two-step RA procedure for SDT by terminal device 210 when terminal device 210 is configured to have both a four-step RA procedure resource for SDT and a two-step RA procedure resource for SDT. The circuitry is further configured to execute SDT with network device 220 based on the maximum number of times.

[0198] In some exemplary embodiments, the circuitry is further configured to perform the SDT by falling back to performing a four-step RA procedure for the SDT if the number of times that the circuitry fails to transmit message A of the two-step RA procedure for the SDT exceeds a maximum number of times, and the four-step RA procedure reuses the same preamble group configured for the two-step RA procedure.

[0199] 18 is a flowchart of an example method 1800 according to some embodiments of the present disclosure. For example, the method 1800 may be implemented in the network device 220 as shown in FIG.

[0200] In block 1810, if the terminal device 210 is configured to have both a four-step RA procedure resource for SDT and a two-step RA procedure resource for SDT, the network device 220 transmits a parameter to the terminal device 210 indicating the maximum number of times that the terminal device 210 transmits message A of the two-step RA procedure for SDT.

[0201] In some exemplary embodiments, network device 220 comprises circuitry configured to transmit a parameter to terminal device 210 indicating the maximum number of times that terminal device 210 transmits message A of a two-step RA procedure for SDT when terminal device 210 is configured to have both a four-step RA procedure resource for SDT and a two-step RA procedure resource for SDT.

[0202] Equipment example Fig. 19 is a schematic block diagram of an apparatus 1900 suitable for implementing an embodiment of the present disclosure. The apparatus 1900 may be considered as another exemplary implementation of the terminal apparatus 210 and the network apparatus 220 shown in Fig. 2. Thus, the apparatus 1900 may be implemented in the terminal apparatus 210, the network apparatus 220, or at least as a part thereof.

[0203] As shown, the apparatus 1900 comprises a processor 1910, a memory 1920 coupled to the processor 1910, a suitable transmitter (TX) and receiver (RX) 1940 coupled to the processor 1910, and a communication interface coupled to the TX / RX 1940. The memory 1920 stores at least a portion of a program 1930. The TX / RX 1940 is used for bidirectional communication. The TX / RX 1940 has at least one antenna to facilitate communication, although the access nodes referred to herein may actually have multiple antennas. The communication interface may represent any interface required for communication with other network elements, such as an X2 interface for bidirectional communication between eNBs, an S1 interface for communication between a mobility management entity (MME) / serving gateway (S-GW) and an eNB, an Un interface for communication between an eNB and a relay node (RN), or an Uu interface for communication between an eNB and a terminal device.

[0204] The program 1930 is assumed to include program instructions that, when executed by an associated processor 1910, enable the device 1900 to operate according to embodiments of the present disclosure, as described herein with reference to Figures 2 and 4-18. The embodiments herein may be implemented by computer software executable by the processor 1910 of the device 1900, or by hardware, or by a combination of software and hardware. The processor 1910 may be configured to implement various embodiments of the present disclosure. Furthermore, the combination of the processor 1910 and the memory 1920 may form a processing means 1950 suitable for implementing various embodiments of the present disclosure.

[0205] The memory 1920 may be of any type suitable for a local technology network and may be implemented using any suitable data storage technology, such as, by way of non-limiting example, non-transitory computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. Although only one memory 1920 is shown in the device 1900, there may be several physically different memory modules in the device 1900. The processor 1910 may be of any type suitable for a local technology network and may include, by way of non-limiting example, one or more of a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. The device 1900 may have multiple processors, for example application specific integrated circuit chips time-slaved to a clock that synchronizes the main processor.

[0206] Overall, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure have been illustrated and described using block diagrams, flow charts, or some other pictorial representations, it should be understood that the blocks, devices, systems, techniques, or methods described herein may be implemented, by way of non-limiting examples, in hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing device, or any combination thereof.

[0207] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in a program module, that execute in a device on a target real or virtual processor to perform a process or method as described above with reference to FIG. 2 and FIG. 4-FIG. 18. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or split between program modules as appropriate. The machine-executable instructions of the program modules may be executed in local or distributed devices. In a distributed device, the program modules may be located in both local and remote storage media.

[0208] Program codes for carrying out the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, a special purpose computer, or other programmable data processing device, and when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may run entirely on the machine, partially on the machine, as a separate software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0209] The above program code may be implemented on a machine-readable medium, which may be any tangible medium that can contain or store a program used by or associated with an instruction execution system, device, or apparatus. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination of the aforementioned media. More specific examples of the machine-readable storage medium may include an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the aforementioned.

[0210] It should be understood that although operations have been described in a particular order, it is not required that such operations be performed in the particular order shown, or in any sequential order, or that all of the operations described be performed, in order to achieve desired results. In some cases, multitasking or parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure, but rather as descriptions of features that may be specific to certain embodiments. Some features described in the context of individual embodiments may be realized in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented separately in multiple embodiments or in any suitable subcombination.

[0211] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it should be understood that the present disclosure, as defined in the appended claims, is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. means for receiving a radio resource control (RRC) release message from a network; means for triggering a Packet Data Convergence Protocol (PDCP) entity to perform a Service Data Unit (SDU) discard for a Signaling Radio Bearer (SRB) when the RRC release message is received and a Small Data Transmission (SDT) configuration is included in the RRC release message; Including, User Equipment (UE).

2. means for re-establishing a Radio Link Control (RLC) entity for an RLC bearer when the RRC release message is received and the SDT configuration is included in the RRC release message. The user device of claim 1.

3. means for initiating an SDT procedure when the RRC release message is received and the SDT configuration is included in the RRC release message; 3. A user device according to claim 1 or 2.

4. means for calculating an amount of pending uplink data for an SDT procedure; means for initiating the SDT procedure when the RRC release message is received and the SDT configuration is included in the RRC release message, and the data volume is less than or equal to a data volume threshold; Further comprising:

3. A user device according to claim 1 or 2.

5. means for determining whether a data amount of pending uplink data for an SDT procedure is less than or equal to a data amount threshold; means for initiating the SDT procedure when the RRC release message is received and the SDT configuration is included in the RRC release message, and the data volume is less than or equal to the data volume threshold; Further comprising:

3. A user device according to claim 1 or 2.

6. and calculating a data amount of pending uplink data for the SDT procedure after the SDU discard is performed. The user device of claim 1.

7. and determining whether a data amount of pending uplink data for the SDT procedure is less than or equal to a data amount threshold after the SDU discard is performed. The user device of claim 1.

8. and calculating a data amount of pending uplink data for an SDT procedure after the RLC entity is re-established and SDU discard is performed.

3. A user device according to claim 2.

9. After the RLC entity is re-established and SDU discard is performed, further comprising: means for determining whether a data amount of pending uplink data for an SDT procedure is less than or equal to a data amount threshold.

3. A user device according to claim 2.

10. means for transmitting a radio resource control (RRC) release message having a small data transmission (SDT) configuration to a user equipment (UE), the SDT configuration being configured to cause the UE to trigger a packet data convergence protocol (PDCP) entity to perform a service data unit (SDU) discard for a signaling radio bearer (SRB); means for receiving an RRC resumption message and uplink SDT data from the UE; Including, A Radio Access Network (RAN) node.

11. The SDT configuration is configured to cause the UE to re-establish a Radio Link Control (RLC) entity for an RLC bearer. A radio access network node according to claim 10.

12. A method for a user equipment (UE), comprising: receiving a radio resource control (RRC) release message from a network; triggering a Packet Data Convergence Protocol (PDCP) entity to perform a Service Data Unit (SDU) discard for a Signaling Radio Bearer (SRB) when the RRC release message is received and a Small Data Transmission (SDT) configuration is included in the RRC release message; Including, method.

13. and re-establishing a Radio Link Control (RLC) entity for the RLC bearer when the RRC release message is received and the SDT configuration is included in the RRC release message. The method of claim 12.

14. If the RRC release message is received and the SDT configuration is included in the RRC release message, initiating an SDT procedure.

14. The method according to claim 12 or 13.

15. Calculating a data amount of pending uplink data for an SDT procedure; If the RRC release message is received and the SDT configuration is included in the RRC release message, and the data volume is less than or equal to a data volume threshold, initiating the SDT procedure; Further comprising:

14. The method according to claim 12 or 13.

16. determining whether a data amount of pending uplink data for an SDT procedure is less than or equal to a data amount threshold; if the RRC release message is received and the SDT configuration is included in the RRC release message, and the data volume is less than or equal to the data volume threshold, initiating the SDT procedure; Further comprising:

14. The method according to claim 12 or 13.

17. and calculating an amount of pending uplink data for the SDT procedure after the SDU discard is performed. The method of claim 12.

18. and determining whether a data amount of pending uplink data for the SDT procedure is less than or equal to a data amount threshold after the SDU discard is performed. The method of claim 12.

19. Calculating an amount of pending uplink data for an SDT procedure after the RLC entity is re-established and SDU discard is performed. The method of claim 13.

20. After the RLC entity is re-established and the SDU discard is performed, determining whether a data amount of pending uplink data for an SDT procedure is less than or equal to a data amount threshold. The method of claim 13.

21. 1. A method of a radio access network (RAN) node, comprising: sending a radio resource control (RRC) release message having a small data transmission (SDT) configuration to a user equipment (UE), the SDT configuration being configured to cause the UE to trigger a packet data convergence protocol (PDCP) entity to perform a service data unit (SDU) discard for a signaling radio bearer (SRB); receiving an RRC resumption message and uplink SDT data from the UE; Including, method.

22. The SDT configuration is configured to cause the UE to re-establish a Radio Link Control (RLC) entity for an RLC bearer.

22. The method of claim 21.

Images