Communication for small data transmission

The mechanism for rejecting only the SDT portion of RRC resume requests in SDT procedures addresses resource congestion and service delays by enabling non-SDT procedures to continue, utilizing uncongested resources effectively.

JP2025137601APending Publication Date: 2025-09-19NOKIA TECHNOLOGIES OY
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2025116620
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-07-10
Publication Date
2025-09-19

AI Technical Summary

Technical Problem

Current RRC rejection messages in SDT procedures halt all RRC resume requests, including non-SDT procedures, leading to resource congestion and service delays, as they do not differentiate between SDT and non-SDT traffic.

Method used

Implement a mechanism for the network device to send a message rejecting only the SDT portion of the RRC resume request, allowing non-SDT procedures to continue, with options to specify types of SDT to reject, waiting times, and state transitions.

Benefits of technology

This approach ensures that non-SDT procedures can proceed, utilizes uncongested resources, and avoids service delays by allowing differentiated handling of SDT and non-SDT traffic.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025137601000001_ABST
    Figure 2025137601000001_ABST
Patent Text Reader

Abstract

To provide improved solutions to communication for SDT.SOLUTION: An embodiment of the present disclosure relates to communication for SDT. A first device transmits a resumption request for SDT to a second device. The second device transmits a message to the first device to reject the resumption request, regarding a first portion of data transmission including the SDT. In this way, a resumption procedure for non-SDT may still be possible. Furthermore, even in the case of an RRC rejection procedure, resources for the SDT or non-SDT may be used without congestion. Furthermore, services are not delayed.SELECTED DRAWING: Figure 4
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] FIELD Embodiments of the present disclosure relate generally to the field of telecommunications, and more particularly to communication methods, devices, apparatus, and computer-readable storage media for small data transmission (SDT). [Background technology]

[0002] Typically, a terminal device in an inactive state may still have small and infrequent data traffic to transmit, in which case the Third Generation Partnership Project (3GPP) Release 17 approved an SDT based on a Random Access Channel (RACH) and Configuration Grant (CG) scheme in an inactive state to avoid the signaling overhead and delay associated with the transition from an inactive state to a connected state.

[0003] During SDT based on these schemes, a Radio Resource Control (RRC) resume request for SDT may be sent from the terminal device to the network device. Currently, all possible RRC responses to the RRC resume request have not yet been determined. One possible response is an RRC rejection message, but this has the drawback that in its current form it is not optimal for SDT procedures because it would stop all RRC resume requests even if they were not SDT procedures. Summary of the Invention

[0004] Generally, the exemplary embodiments of the present disclosure provide an improved communication solution for SDTs.

[0005] In a first aspect, a first device is provided, the first device comprising at least one processor and at least one memory containing computer program code configured, by the at least one processor, to cause the first device to: send a request to resume an SDT to a second device; and receive a message from the second device to reject the request to resume a portion of a data transmission that includes the SDT.

[0006] In a second aspect, a second device is provided, the second device comprising at least one processor and at least one memory containing computer program code configured by the at least one processor to cause the second device to receive, from the first device, a request to resume the SDT, and to send to the first device a message to reject the request to resume a portion of a data transmission that includes the SDT.

[0007] In a third aspect, there is provided a method of communications, the method including: transmitting, at a first device, to a second device, a request to resume an SDT; and receiving, from the second device, a message to reject the request to resume a portion of a data transmission, the portion including the SDT.

[0008] In a fourth aspect, there is provided a method of communications, the method including: receiving, at a second device, from a first device, a request to resume an SDT; and transmitting to the first device a message to reject the request to resume a portion of a data transmission, the portion including the SDT.

[0009] In a fifth aspect, a communications apparatus is provided, comprising: means, at a first device, for transmitting a request to resume an SDT to a second device; and means, from the second device, for receiving a message for rejecting the request to resume a portion of a data transmission that includes the SDT.

[0010] In a sixth aspect, a communications apparatus is provided, comprising: means, at a second device, for receiving a request to resume an SDT from a first device; and means, at a second device, for transmitting a message to the first device to reject the request to resume a portion of data transmission that includes the SDT.

[0011] In a seventh aspect, there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform a method according to the third aspect.

[0012] In an eighth aspect, there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform the method according to the fourth aspect.

[0013] It should be understood that the Abstract is not intended to identify key features or essential features of the embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become readily apparent through the following description. [Brief explanation of the drawings]

[0014] Some exemplary embodiments will now be described with reference to the accompanying drawings. [Figure 1] FIG. 1 is a diagram illustrating an example communication network in which example embodiments of the present disclosure may be implemented. [Figure 2] FIG. 2 is a schematic diagram illustrating an exemplary four-step RACH procedure according to some embodiments of the present disclosure. [Figure 3] FIG. 3 is a schematic diagram illustrating an exemplary two-step RACH procedure according to some embodiments of the present disclosure. [Figure 4] FIG. 4 is a schematic diagram illustrating a process of communication according to some embodiments of the present disclosure. [Figure 5]FIG. 5 illustrates a flowchart of a method of communication implemented in a first device according to an exemplary embodiment of the present disclosure. [Figure 6] FIG. 6 illustrates a flowchart of a communication method implemented in a second device according to an exemplary embodiment of the present disclosure. [Figure 7] FIG. 7 shows a simplified block diagram of a device suitable for implementing exemplary embodiments of the present disclosure. [Figure 8] 8 illustrates a block diagram of an exemplary computer-readable medium according to an exemplary embodiment of the present disclosure. Throughout the drawings, identical or similar reference numerals represent identical or similar elements. DETAILED DESCRIPTION OF THE INVENTION

[0015] 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 to help those skilled in the art understand and practice the present disclosure, and are not intended to imply any limitations on the scope of the present disclosure. The disclosure described herein may be implemented in various forms other than those described below.

[0016] 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 belongs.

[0017] References in this disclosure to "one embodiment," "an embodiment," "an exemplary embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but that all embodiments are not required to include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is understood that it is 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 stated.

[0018] Although terms such as "first" and "second" may be used herein to describe various elements, it should be understood that these elements are not limited by these terms. These terms are used only to distinguish one element from another. For example, a first element can be referred to as a second element, and similarly, a second element can be referred to as 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.

[0019] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit example embodiments. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should be further understood that as used herein, the terms "comprises," "comprising," "has," "having," "includes," and / or "including" 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.

[0020] As used herein, the term "circuitry" may refer to one or more or all of the following: (a) hardware-only circuit implementations (e.g., analog and / or digital-only implementations); and (b) a combination of hardware circuitry and software, e.g., (where applicable); (i) a combination of analog and / or digital hardware circuitry and software / firmware; and (ii) Software (including digital signal processors), software, and a portion of a hardware processor with memory(s) that work together to cause a device such as a mobile phone or server to perform various functions. (c) Hardware circuit(s) and processor(s), such as microprocessor(s) or portions of microprocessors, that require software (e.g., firmware) to operate, but that may be absent when not necessary for operation.

[0021] This definition of circuit applies to all uses of the term in this application, including any claims. As a further example, as used herein, the term circuit also covers simply a hardware circuit or processor (or processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware implementation. The term circuit also covers, for example, a baseband or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or network device, if applicable to a particular claim element.

[0022] As used herein, the term "communication network" refers to a network conforming to any suitable communication standard, such as a fifth-generation (5G) system, Long Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), or Narrowband Internet of Things (NB-IoT). Furthermore, communications between terminal equipment and network devices in a communication network may be performed 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) New Radio (NR) communication protocols, and / or other protocols currently known or developed in the future. Embodiments of the present disclosure may be applied to various communication systems. Given the rapid development of communications, there will, of course, be future communication technologies and systems in which the present disclosure may be embodied. The scope of the present disclosure should not be considered limited to only the aforementioned systems.

[0023] As used herein, the term "network device" refers to a node in a communication network through which terminal equipment accesses the network and receives services therefrom. Depending on the applicable terminology and technology, a network device may refer to a base station (BS) or access point (AP), e.g., a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), an NR NB (also known as a gNB), a remote radio unit (RRU), a radio header (RH), a remote radio head (RRH), a relay, an integrated access backhaul (IAB) node, or a low-power node such as a femto or pico node. The RAN-split architecture includes a gNB-CU (centralized unit, hosting RRC, SDAP, and PDCP) that controls multiple gNB-DUs (distributed units, hosting RLC, MAC, and PHY). A relay node corresponds to the DU portion of an IAB node.

[0024] The term "terminal equipment" refers to any terminal equipment capable of wireless communication. By way of example and not limitation, a terminal equipment may also be referred to as a communication device, user equipment (UE), subscriber station (SS), mobile subscriber station, mobile station (MS), or access terminal (AT). Terminal equipment includes, but is not limited to, mobile phones, cellular phones, smartphones, Voice over IP (VoIP), telephones, wireless local loop phones, tablets, wearable terminal equipment, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal equipment such as digital cameras, gaming terminal equipment, music storage and playback equipment, in-vehicle wireless terminal equipment, wireless endpoints, mobile stations, laptop embedded equipment (LEE), laptop mounted equipment (LME), USB dongles, smart devices, wireless CPE, Internet of Things (IoT) devices, wearables such as watches, head-mounted displays (HMD), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, etc. Terminal equipment may also correspond to the mobile termination (MT) portion of an integrated access backhaul (IAB) node (also known as a relay node). In the following description, the terms "terminal equipment", "communication equipment", "terminal", "user equipment" and "UE" may be used interchangeably.

[0025] Currently, there are various applications that involve the exchange of small, infrequent data. For example, in some applications on mobile devices, SDT includes traffic from instant messaging (IM) services, such as heartbeat or keep-alive traffic from IM or email clients and other services, push notifications for various applications, traffic from wearables (including, for example, periodic positioning information), etc. In some applications on non-mobile devices, SDT includes sensor data (e.g., temperature, pressure measurements transmitted periodically or in an event-triggered manner over IoT networks), measurement and alert information transmitted from smart meters, and / or the like.

[0026] As mentioned above, one possible response to an RRC restart request in SDT is an RRC rejection message. According to conventional solutions, when an RRC rejection message is received in response to an RRC restart request, the terminal device remains in an inactive state. If the RRC rejection message includes a waiting time, the terminal device waits until the waiting time expires before attempting a new RRC restart request.

[0027] It can be seen that the current form of RRC Rejection may stop an SDT RRC Restart request and prevent one or more further SDT or non-SDT RRC Restart requests during the waiting period. Indeed, a network device may want to admit non-SDT but not SDT when the system is congested, because SDT and non-SDT may be intended for different services (e.g., SDT is typically intended for background messages) and it would not be beneficial to deny all resources during the waiting period.

[0028] In consideration of this, embodiments of the present disclosure provide an improved solution for the RRC rejection procedure for SDT. This solution can reject the resumption procedure for a portion of data transmission including SDT. In this way, the resumption procedure for non-SDT can still be possible. Furthermore, even in the case of an RRC rejection procedure, uncongested resources for SDT or non-SDT may be used. Furthermore, there is no delay in service to the terminal device. The principles and embodiments of the present disclosure will be described in detail below with reference to the drawings.

[0029] Example of a communication network 1 shows a schematic diagram of an example communication network 100 in which some embodiments of the present disclosure may be implemented. As shown in FIG. 1, communication network 100 may include a first device 110 and a second device 120. In some embodiments, first device 110 may be a terminal device, and second device 120 may be a network device.

[0030] For purposes of explanation only, and without implying any limitation on the scope of the present disclosure, some embodiments will be described in the context of first device 110 being a terminal device and second device 120 being a network device. It should be understood that in other embodiments, first device 110 may be a network device and second device 120 may be a terminal device. In other words, the principles and spirit of the present disclosure may be applied to both uplink and downlink transmissions.

[0031] 1 is for illustrative purposes only, without implying any limitation. Network 100 may include any suitable number and type of first and second devices suitable for implementing embodiments of the present disclosure.

[0032] As shown in FIG. 1 , a first device 110 can communicate with a second device 120 over a channel, such as a wireless communication channel. Communications in the communication network 100 can conform to any suitable standard, including, but not limited to, Global System for Mobile Communications (GSM), Long Term Evolution (LTE), LTE-Evolution, LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), GSM Edge Radio Access Network (GERAN), Mechanical Based Communication (MTC), etc. Furthermore, communications can be performed according to any currently known or future-developed generation of communication protocols. 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.

[0033] In some scenarios, the first device 110 may want to transmit data, such as small and infrequent data traffic, to the second device 120 in an inactive state. In some embodiments, the first device 110 may perform a non-SDT procedure to transmit the data. In some embodiments, the first device 110 may perform an SDT procedure to transmit the data. For example, the first device 110 may perform a non-SDT procedure or an SDT procedure based on a random access procedure. This will be described in conjunction with FIGS. 2 and 3.

[0034] In some embodiments, the random access procedure may be a four-step RACH procedure. Figure 2 shows an example four-step RACH procedure 200 according to some embodiments of the present disclosure. For convenience, procedure 200 will be described with reference to Figure 1. Procedure 200 may include first device 110 and second device 120, as shown in Figure 1.

[0035] 2, the first device 110 may transmit a random access preamble (also referred to as Msg1) 210 to the second device 120 on a physical random access channel (PRACH). The second device 120 may transmit a random access response (also referred to as Msg2) 220 to the second device 120 on a physical downlink shared channel (PDSCH). The first device 110 may then transmit a scheduled transmission (also referred to as Msg3) 230 to the second device 120 on a physical uplink shared channel (PUSCH). The second device 120 may transmit a contention resolution (also referred to as Msg4) 240 to the first device 110 on the PDSCH.

[0036] In some embodiments, the first device 110 may send an RRC resumption request or an RRC setup request for non-SDT in Msg3. In this manner, a non-SDT procedure based on a four-step RACH may be initiated. Upon receiving the RRC resumption message from the second device 120, the first device 110 may transmit data in a non-SDT procedure based on a four-step RACH.

[0037] In some embodiments, the first device 110 may send an RRC resumption request for SDT in Msg3. In this manner, a four-step RACH-based SDT procedure may be initiated. In some embodiments, the first device 110 may send the RRC resumption request in Msg3 and transmit the data in a subsequent transmission. In some embodiments, the first device 110 may send the RRC resumption request and a portion of the data in Msg3 and transmit the remaining portion of the data in a subsequent transmission. In some embodiments, the second device 120 may send a message to the first device 110 in Msg4 to reject the RRC resumption request.

[0038] In some embodiments, the random access procedure may be a two-step RACH procedure. Figure 3 shows an example two-step RACH-based SDT procedure 300 according to some embodiments of the present disclosure. For convenience, the procedure 300 will be described with reference to Figure 1. The procedure 300 may include the first device 110 and the second device 120, as shown in Figure 1.

[0039] 3, the first device 110 may transmit a random access preamble and a PUSCH payload (also referred to as MsgA) 310 to the second device 120. The random access preamble may be transmitted on a physical random access channel (PRACH), and the PUSCH payload may be transmitted on the PUSCH. The second device 120 may then transmit a contention resolution 320 (also referred to as MsgB) to the first device 110 on the PDSCH.

[0040] In some embodiments, the first device 110 may send a non-SDT RRC resumption request in MsgA. In this manner, a two-step RACH-based non-SDT procedure may be initiated. Upon receiving the RRC resumption message from the second device 120, the first device 110 may transmit data in a two-step RACH-based non-SDT procedure.

[0041] In some embodiments, the first device 110 may transmit an SDT resumption request in MsgA. In this manner, a two-step RACH-based SDT procedure may be initiated. In some embodiments, the first device 110 may transmit data along with the RRC resumption request in MsgA. In some embodiments, the first device 110 may transmit the RRC resumption request in MsgA and transmit the data in a subsequent transmission. In some embodiments, the first device 110 may transmit the RRC resumption request and a portion of the data in MsgA and transmit the remaining portion of the data in a subsequent transmission. In some embodiments, the second device 120 may transmit a message to the first device 110 in MsgB to reject the RRC resumption request.

[0042] In some embodiments, the first device 110 may perform an SDT procedure and transmit data based on a CG scheme (not shown). For example, the first device 110 may transmit an SDT RRC resumption request and data in CG resources. As another example, the first device 110 may transmit the SDT RRC resumption request and data separately in different CG resources. In response to the SDT RRC resumption request, the second device 120 may transmit a message to the first device 110 to reject the RRC resumption request.

[0043] The embodiments of the present application provide a solution for rejecting an RRC resumption request for an SDT, which will be described in detail with reference to FIG.

[0044] Example of rejecting a SDT restart request 4 is a schematic diagram illustrating a process 400 for communication according to an embodiment of the present disclosure. For purposes of explanation, the process 400 will be described with reference to FIG. 1. The process 400 may include a first device 110 and a second device 120, as shown in FIG.

[0045] 4, the first device 110 sends a request 410 to resume the SDT to the second device 120. For example, when data, such as small and infrequent data traffic, arrives at the first device 110, the first device 110 may send the request to resume the SDT. It should be understood that the data may be any suitable data, and the present disclosure is not limited in this respect.

[0046] In some embodiments, the resume request may be an RRCResumeRequest message. In some embodiments, the resume request may be an RRCResumeRequest1 message. In some embodiments, the resume request may include a resume cause that notifies the SDT. It should be noted that the resume request may take any other appropriate form, and the present disclosure is not limited to this form.

[0047] Upon receiving the resume request, the second device 120 can know that the resume request is for an SDT. In some embodiments, if the resume request is transmitted on a random access resource reserved for an SDT, the second device 120 can determine that the resume request is for an SDT. In some embodiments, if Msg3 includes an indication that the resume request is for an SDT, the second device 120 can determine that the resume request is for an SDT. In some embodiments, if data is transmitted with the resume request, the second device 120 can determine that the resume request is for an SDT.

[0048] In this case, the second device 120 sends a message 420 to reject the request to resume the portion of the data transmission, the portion of the data transmission including the SDT. In some embodiments, the message may be an RRCReject message. Of course, any other suitable form is also possible.

[0049] In this way, a non-SDT resumption procedure is also possible. Furthermore, even in the case of an RRC rejection procedure, there is a possibility that resources for SDT or non-SDT may be used without congestion. Furthermore, there is no delay in services to terminal equipment. Below, several example embodiments will be described in accordance with embodiments 1 to 6.

[0050] Embodiment 1 In this embodiment, the message may indicate that the resume request is rejected in an SDT but not in a non-SDT.

[0051] In some embodiments, a dedicated message may be defined that specifically notifies that a resume request is rejected for an SDT but not for a non-SDT. In some embodiments, the message may include information (for convenience, also referred to herein as first information) that notifies that a resume request is rejected for an SDT. For example, the message may include a bit that notifies this information. Of course, this is just one example, and the message may take any other appropriate form.

[0052] In this way, the second device 120 can reject the SDT procedure such that only SDT resume requests are not allowed, while non-SDT resume requests are still allowed.

[0053] Embodiment 2 In this embodiment, the second device 120 can explicitly reject one or more SDT procedures that are not permitted.

[0054] In some embodiments, the message may include information (for convenience, also referred to herein as second information) notifying that the resume request is rejected for one or more predetermined types of SDT.

[0055] In some embodiments, the predetermined type of SDT may include a RACH-based SDT. For example, the predetermined type of SDT may be a two-step RACH-based SDT. As another example, the predetermined type of SDT may be a four-step RACH-based SDT. In some embodiments, the predetermined type of SDT may include a CG-based SDT. It should be understood that the present disclosure does not impose any limitations on the type of SDT, and any other suitable type may also be implemented.

[0056] In some alternative embodiments, a dedicated message may be defined that specifically notifies that a resume request is denied for a particular type of SDT.

[0057] Therefore, a specific type of SDT may not be permitted, but other specific types of SDT may be permitted. For example, if the second information does not indicate the other specific types of SDT, the first device may determine that the other specific types of SDT are permitted. A message from the second device (i.e., a rejection message rejecting at least the specific types of SDT) may additionally or alternatively indicate which types of SDT are permitted.

[0058] Embodiment 3 In this embodiment, the message may announce one or more wait times for various data transmissions.

[0059] In some embodiments, the message may include information (for convenience, also referred to herein as third information) informing at least one of a waiting time for an SDT (for convenience, also referred to herein as a first waiting time), a waiting time for one or more predetermined types of SDT (for convenience, also referred to herein as a second waiting time), or a waiting time for a non-SDT (for convenience, also referred to herein as a third waiting time). The first device 110 may start a timer for the waiting time for a particular data transmission. If the timer is running, the first device 110 is prohibited from sending a resume request for the particular data transmission.

[0060] In some embodiments, the first, second, and third wait times can be set to different values. In some embodiments, two or more of the first, second, and third wait times can be set to the same value. It should also be understood that the number of wait times is not limited to three, and more or less than three are possible.

[0061] In some embodiments, different waiting times (i.e., different values ​​of the second waiting time) may be set for different predetermined types of SDT. For example, the predetermined types of SDT may include at least one of a RACH-based SDT or a CG-based SDT. The RACH-based SDT may include at least one of a two-step RACH-based SDT or a four-step RACH-based SDT. Of course, any other suitable types are also possible. In some alternative embodiments, the same waiting time may be set for different predetermined types of SDT.

[0062] Embodiment 4 In this embodiment, the message may notify the first device 110 whether to transition to an idle state or remain in an inactive state.

[0063] In some embodiments, the message may include information (also referred to herein as fourth information for convenience) indicating whether the first device 110 will transition to an idle state or remain in an inactive state. For example, the second device 120 may cause the message to include a bit or field to indicate that the first device 110 will transition to an idle state, and may not cause the message to include a bit or field to indicate that the first device 110 will remain in an inactive state.

[0064] As another example, the second device 120 may set a first value of a bit or field included in the message to indicate that the first device 110 is transitioning to an idle state, and set a second value of the bit or field to indicate that the first device 110 is remaining in an inactive state. Of course, these are merely examples, and any other suitable method may be implemented.

[0065] In some embodiments, a dedicated message can be defined to specifically notify the first device 110 that it is going to an idle state. In some embodiments, another dedicated message can be defined to specifically notify the first device 110 that it is remaining in an inactive state.

[0066] Embodiment 5 In this embodiment, upon receiving a message to deny the SDT resume request, the first device 110 may initiate a non-SDT procedure to transmit data to the second device 120.

[0067] In some embodiments, the message may adopt the existing format of an RRC rejection message. In some embodiments, the message may be a newly defined dedicated message for notifying a rejection for an SDT, such as an SDT rejection message. Of course, other suitable formats are also suitable for the message.

[0068] In some embodiments where data is rejected from being sent using SDT, upon receiving the RRC reject message, the first device 110 may initiate a non-SDT procedure to send the data to the second device 120. In some embodiments where data was sent with a rejected resume request, the first device 110 may initiate a non-SDT procedure to send the data to the second device 120. In some embodiments where not all data that was to be sent using an SDT procedure was sent with a rejected SDT resume request, the first device 110 may also initiate a non-SDT procedure to send the data to the second device 120. In some embodiments where no data was sent with a rejected SDT resume request, the first device 110 may also initiate a non-SDT procedure to send the data to the second device 120. The data sent using a non-SDT procedure may include data sent with the SDT resume request and / or remaining data not sent with the resume request.

[0069] In some embodiments, upon receiving the RRC rejection message, the first device 110 may initiate a non-SDT procedure for transmitting subsequent data arriving at the first device 110 to the second device 120. The non-SDT procedure may be performed similarly to that described in Figures 2 and 3 and therefore will not be repeated here.

[0070] In some embodiments, the first device 110 may not be permitted to perform SDT upon receipt of the RRC reject message, but may initiate a non-SDT resumption procedure only if there is a resumption event, whether for an SDT RB, a non-SDT RB, or whether other criteria are met. In some embodiments, the first device 110 may consider the waiting time for SDT to be infinite upon receiving the RRC reject message.

[0071] In some embodiments, the first device 110 is not permitted to perform SDT upon receipt of an RRC reject message and can only initiate non-SDT procedures. In some examples, upon receiving the RRC reject message, the first device 110 enters IDLE mode (i.e., idle state) and can trigger a non-SDT establishment procedure when there is an establishment event for an SDT RB, a non-SDT RB, or whether other criteria are met. In some examples, upon receiving the RRC reject message, the first device 110 enters INACTIVE mode (i.e., inactive state) and can trigger a non-SDT restart procedure when there is a restart event for an SDT RB, a non-SDT RB, or whether other criteria are met. Alternatively, the first device 110 can trigger an SDT restart procedure when there is a restart event for an SDT RB, or whether other criteria are met. To avoid potential security threats, in some examples, the first device 110 may provide notification during a non-SDT or SDT resume procedure that a security key update is required, that the current key is being reused, or that the current key is being used multiple times in the resume procedure. Based on such notification, the second device 120 may update one or more security keys before new data is transmitted.

[0072] Embodiment 6 In this embodiment, the second device 120 may explicitly specify that a particular radio bearer (RB) for SDT is not allowed.

[0073] In some embodiments, the message may include information (for convenience, also referred to herein as fifth information) indicating that the resume request is denied for one or more predetermined types of RBs associated with the first device 110. In some embodiments, the predetermined types of RBs may include signaling radio bearers (SRBs). In some embodiments, the predetermined types of RBs may include data radio bearers (DRBs).

[0074] In some embodiments, the fifth information may indicate that the resume request is denied for an SDT RB. For example, the fifth information may indicate that the resume request is denied for an SDT SRB. As another example, the fifth information may indicate that the resume request is denied for a specific SDT DRB. In some embodiments, the fifth information may indicate that the resume request is denied for an RB other than an SDT. Note that these are merely examples and are not intended to limit the present disclosure.

[0075] In some alternative embodiments, a dedicated message may be defined that specifically notifies that a resume request is denied for a particular type of RB.

[0076] So far, the solution to the RRC rejection of SDT according to the present disclosure has been described. In this way, the non-SDT resumption procedure is still possible. Furthermore, in the case of the RRC rejection procedure, non-congested resources for SDT or non-SDT may be used, and the service to the terminal device will not be delayed.

[0077] Example of the method Some exemplary methods according to embodiments of the present disclosure will now be described in detail with reference to Figures 5-8. However, those skilled in the art will readily appreciate that the detailed descriptions provided herein with respect to these figures are for illustrative purposes, as the present disclosure extends beyond these limited embodiments.

[0078] 5 illustrates a flowchart of a method 500 of communication implemented at a first device in accordance with an exemplary embodiment of the present disclosure. Method 500 may be implemented at first device 110 shown in FIG. 1. For purposes of explanation, method 500 will be described with reference to FIG. 1. It should be understood that method 500 may further include additional blocks not shown and / or may omit some illustrated blocks, and that the scope of the present disclosure is not limited in this respect.

[0079] As shown in FIG. 5, in block 510, the first device 110 sends a request to the second device 120 to resume the SDT.

[0080] In block 520, first device 110 receives a message from second device 120 to reject a resume request for a portion of the data transmission, the portion including the SDT. In some embodiments, the message may indicate that the resume request is rejected for the SDT but not for the non-SDT. In some embodiments, the message may include first information indicating that the resume request is rejected for the SDT.

[0081] In some embodiments, the first device 110 may receive the message by receiving second information indicating that the resume request is denied for one or more predetermined types of SDTs. In other words, the message may include the second information.

[0082] In some embodiments, the first device 110 may receive the message by receiving third information indicating at least one of a first waiting time for an SDT, a second waiting time for one or more predetermined types of SDT, or a third waiting time for a non-SDT. In other words, the message may include the third information. In some embodiments, the one or more predetermined types of SDT may include at least one of a RACH-based SDT or a CG-based SDT.

[0083] In some embodiments, the first device 110 may receive the message by receiving fourth information informing it whether the first device 110 will transition to an idle state or remain in an inactive state.

[0084] In some embodiments, in response to receiving the message, first device 110 may initiate a non-SDT procedure to transmit data to second device 120. In some embodiments, the data may include at least data that was rejected from being transmitted using small data transmission. In some embodiments, the data may include data transmitted with the resume request.

[0085] In some embodiments, the first device 110 may receive the message by receiving fifth information notifying that the resume request is denied for a predetermined type of RB associated with the first device 110.

[0086] 5 correspond to the operations in the process described in FIG. 4, and other details are omitted here for brevity. The method of FIG. 5 also allows for non-SDT resumption procedures. Furthermore, even in the case of an RRC rejection procedure, uncongested resources for SDT or non-SDT can be used. Furthermore, service to the first device 110 is not delayed.

[0087] Correspondingly, embodiments of the present disclosure also provide a method of communication implemented in a second device. Figure 6 shows a flowchart of a method 600 of communication implemented in a second device, according to an exemplary embodiment of the present disclosure. Method 600 may be implemented in second device 120 shown in Figure 1. For purposes of explanation, method 600 will be described with reference to Figure 1. It should be understood that method 600 may further include additional blocks not shown and / or may omit some illustrated blocks, and that the scope of the present disclosure is not limited in this respect.

[0088] As shown in FIG. 6, in block 610, the second device 120 receives a request to resume the SDT from the first device 110.

[0089] In block 620, the second device 120 sends a message to the first device 110 to deny the resume request for a portion of the data transmission that includes the SDT. In some embodiments, the message may indicate that the resume request is denied for the SDT but not for the non-SDT. In some embodiments, the message may include first information indicating that the resume request is denied for the SDT.

[0090] In some embodiments, the second device 120 may send the message by sending second information indicating that the resume request is denied for one or more predetermined types of SDTs. In other words, the message may include the second information.

[0091] In some embodiments, the second device 120 may transmit the message by transmitting third information indicating at least one of a first waiting time for an SDT, a second waiting time for one or more predetermined types of SDT, or a third waiting time for a non-SDT. In other words, the message may include the third information. In some embodiments, the one or more predetermined types of SDT may include at least one of a RACH-based SDT or a CG-based SDT.

[0092] In some embodiments, the second device 120 may send a message by transmitting fourth information informing the first device 110 whether it will transition to an idle state or remain in an inactive state.

[0093] In some embodiments, the second device 120 may send a message by sending fifth information notifying the first device 110 that the resume request is denied for a predetermined type of RB associated with the first device 110.

[0094] The operations in the method of Figure 6 correspond to the operations in the process described in Figure 4, and other details are omitted here for brevity. In the method of Figure 6, SDT restart procedures are rejected, but non-SDT restart procedures may be allowed.

[0095] Apparatus and Device Examples In some embodiments, an apparatus capable of performing method 500 (e.g., first device 110) may comprise means for performing each step of method 500. The means may be implemented in any suitable form. For example, the means may be implemented in a circuit or a software module.

[0096] In some embodiments, the apparatus may comprise means, at the first device, for sending a request to the second device to resume the SDT, and means for receiving from the second device a message for rejecting the request to resume a portion of the data transmission, the portion including the SDT.

[0097] In some embodiments, the message for rejecting the resume request may notify that the resume request is rejected for the SDT but not for the non-SDT. In some embodiments, the message for rejecting the resume request may include first information notifying that the resume request is rejected for the SDT.

[0098] In some embodiments, the means for receiving the message may comprise means for receiving second information indicating that the resume request is rejected for one or more predetermined types of SDTs. In some embodiments, the means for receiving the message may comprise means for receiving third information indicating at least one of a first waiting time for the SDT, a second waiting time for the one or more predetermined types of SDTs, or a third waiting time for a non-SDT. In some embodiments, the one or more predetermined types of SDTs may include at least one of a RACH-based SDT or a CG-based SDT.

[0099] In some embodiments, the means for receiving the message may comprise means for receiving fourth information informing the first device of whether to transition to an idle state or remain in an inactive state.

[0100] In some embodiments, the apparatus may further comprise means for initiating a non-SDT procedure for transmitting data to the second device in response to receiving the message. In some embodiments, the data may include at least data that was refused to be transmitted using SDT. In some embodiments, the data may include data transmitted with the resume request.

[0101] In some embodiments, the means for receiving the message may comprise means for receiving fifth information indicating that the resume request is denied for a predetermined type of radio bearer associated with the first device.

[0102] In some embodiments, an apparatus capable of performing method 600 (e.g., second device 120) may comprise means for performing each step of method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuit or a software module.

[0103] In some embodiments, the apparatus may comprise means for receiving, at the second device, from the first device, a request to resume the SDT; and means for sending to the first device a message to reject the request to resume a portion of the data transmission that includes the SDT.

[0104] In some embodiments, the message for rejecting the resume request may notify that the resume request is rejected for the SDT but not for the non-SDT. In some embodiments, the message for rejecting the resume request may include first information notifying that the resume request is rejected for the SDT.

[0105] In some embodiments, the means for transmitting the message may comprise means for transmitting second information indicating that the resume request is rejected for one or more predetermined types of SDTs. In some embodiments, the means for transmitting the message may comprise means for transmitting third information indicating at least one of a first waiting time for the SDT, a second waiting time for the one or more predetermined types of SDTs, or a third waiting time for a non-SDT. In some embodiments, the one or more predetermined types of SDTs may include at least one of a RACH-based SDT or a CG-based SDT.

[0106] In some embodiments, the means for transmitting the message may comprise means for transmitting fourth information informing the first device of whether it will transition to an idle state or remain in an inactive state.

[0107] In some embodiments, the means for transmitting the message may comprise means for transmitting fifth information indicating that the resume request is denied for a predetermined type of radio bearer associated with the first device.

[0108] 7 is a simplified block diagram of a device 700 suitable for implementing embodiments of the present disclosure. The device 700 may be provided to implement a first device or a second device, such as the first device 70 or the second device 120 shown in FIG. 1. As shown, the device 700 includes one or more processors 710, one or more memories 720 coupled to the processors 710, and one or more communication modules 740 (e.g., transmitters and / or receivers) coupled to the processors 710.

[0109] The communication module 740 is for two-way communication. The communication module 740 has at least one antenna to facilitate communication. The communication interface may represent any interface necessary for communication with other network elements.

[0110] The processor 710 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 700 may have multiple processors, such as application-specific integrated circuit chips that are time-slaved to a clock that synchronizes a main processor.

[0111] The memory 720 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memory include, but are not limited to, read-only memory (ROM) 724, electrically programmable read-only memory (EPROM), flash memory, hard disks, compact disks (CDs), digital video disks (DVDs), and other magnetic and / or optical storage devices. Examples of volatile memory include, but are not limited to, random access memory (RAM) 722 and other volatile memories that do not persist through power-down periods.

[0112] The computer program 730 includes computer-executable instructions that are executed by the associated processor 710. The program 730 may be stored in the ROM 724. The processor 710 can load the program 730 into the RAM 722 to perform any suitable operations and processes.

[0113] The embodiments of the present disclosure may be implemented by a program 730 such that the device 700 can execute any process of the present disclosure, as described with reference to Figures 1 to 6. The embodiments of the present disclosure may also be implemented by hardware or a combination of software and hardware.

[0114] In some embodiments, the program 730 may be tangibly contained in a computer-readable medium, which may be included in the device 700 (such as in memory 720) or other storage accessible by the device 700. The device 700 may load the program 730 from the computer-readable medium into RAM 722 for execution. The computer-readable medium may include any type of tangible non-volatile storage device, such as a ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Figure 8 shows an example of a computer-readable medium 800 in the form of a CD or DVD, on which the program 730 is stored.

[0115] In general, 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. While various aspects of embodiments of the present disclosure are illustrated and described using block diagrams, flowcharts, or some other graphical representations, it should be understood that the blocks, apparatus, systems, techniques, or methods described herein may be implemented in, by way of non-limiting example, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller, or other computing device, or some combination thereof.

[0116] 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 those included in program modules, that execute on a target real or virtual processor device to perform methods 500-600, as described above with reference to FIGS. 5-6. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split among program modules as desired in various embodiments. The machine-executable instructions of the program modules may be executed in local or distributed devices. In distributed devices, the program modules may be located in both local and remote storage media.

[0117] Program code for implementing 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 apparatus, such that when the program code is executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are performed. The program code may run entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0118] In the context of the present disclosure, computer program code or associated data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations as described above. Examples of carriers include signals, computer-readable media, etc.

[0119] The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable medium includes, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the above. More specific examples of the computer-readable storage medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0120] Furthermore, although operations are depicted in a particular order, this should not be understood as requiring such operations to be performed in the particular order shown, or sequentially, or that all of the operations depicted be performed, to achieve desirable results. In certain situations, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

[0121] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it is to be understood that the present disclosure, as defined by 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. a first device, at least one processor; at least one memory containing computer program code; The at least one memory and the computer program code are transmitted by the at least one processor to the first device: sending a request to the second device to resume at least one radio bearer for small data transmission and at least one radio bearer for non-small data transmission; receiving, from the second device, a message rejecting the resume request for the at least one radio bearer for small data transmission and not rejecting the resume request for the at least one radio bearer for non-small data transmission; A first device configured to:

2. The first device of claim 1 , wherein the message for rejecting the resume request notifies that the resume request is rejected for small data transmissions but not for non-small data transmissions.

3. The first device according to claim 1 or 2, wherein the message for rejecting the resume request includes first information notifying that the resume request is rejected for small data transmission.

4. The first device receiving second information indicating that the resume request is denied for one or more predetermined types of small data transmissions; The first device of claim 1 , adapted to receive the message by

5. The first device a first waiting time for small data transmission; a second waiting time for one or more predetermined types of small data transmission; a third waiting time for non-small data transmission; receiving third information informing at least one of The first device of claim 1 , adapted to receive the message by

6. The one or more predetermined types of small data transmissions include: Random access based small data transmission, Configuration grant-based small data transmission, 6. The first device according to claim 4 or 5, comprising at least one of:

7. The first device receiving fourth information informing the first device whether it will transition to an idle state or remain in an inactive state; The first device of claim 1 , adapted to receive the message by

8. The first device further comprises: initiating a non-small data transmission procedure for transmitting data to the second device in response to receiving the message; 2. The first device of claim 1, adapted to execute:

9. The first device of claim 8 , wherein the data includes at least data that was refused to be transmitted using the small data transmission.

10. The first device of claim 8 or 9, wherein the data includes data sent with the resume request.

11. The first device receiving fifth information indicating that the resume request is denied for a predetermined type of radio bearer associated with the first device; The first device of claim 1 , adapted to receive the message by

12. The first device of claim 1 , wherein the first device is a terminal device and the second device is a network device.

13. a second device, at least one processor; at least one memory containing computer program code; The at least one memory and the computer program code are transmitted by the at least one processor to the second device: receiving, from the first device, a request to resume at least one radio bearer for small data transmission and at least one radio bearer for non-small data transmission; sending a message to the first device rejecting the resume request for the at least one radio bearer for small data transmission and not rejecting the resume request for the at least one radio bearer for non-small data transmission; A second device configured to cause the

14. The second device of claim 13 , wherein the message for rejecting the resume request notifies that the resume request is rejected for small data transmissions but not for non-small data transmissions.

15. The second device according to claim 13 or 14, wherein the message for rejecting the resume request includes first information notifying that the resume request is rejected for small data transmission.

16. The second device transmitting second information indicating that the resume request is denied for one or more predetermined types of small data transmissions; The second device of claim 13, adapted to transmit the message by

17. The second device a first waiting time for small data transmission; a second waiting time for one or more predetermined types of small data transmission; a third waiting time for non-small data transmission; transmitting third information notifying at least one of the above; The second device of claim 13, adapted to transmit the message by

18. The one or more predetermined types of small data transmissions include: Random access based small data transmission, Configuration grant-based small data transmission, 18. The second device according to claim 16 or 17, comprising at least one of:

19. The second device transmitting fourth information informing the first device whether it will transition to an idle state or remain in an inactive state; The second device of claim 13, adapted to transmit the message by

20. The second device sending fifth information indicating that the resume request is rejected for a predetermined type of radio bearer associated with the first device; The second device of claim 13, adapted to transmit the message by

21. The second device of claim 13 , wherein the first device is a terminal device and the second device is a network device.

22. In the first device, sending a request to a second device to resume at least one radio bearer for small data transmission and at least one radio bearer for non-small data transmission; receiving, from the second device, a message rejecting the resume request for the at least one radio bearer for small data transmission and not rejecting the resume request for the at least one radio bearer for non-small data transmission; A method of communication, including

23. 23. The method of claim 22, wherein the message to reject the resume request indicates that the resume request is rejected for small data transmissions but not for non-small data transmissions.

24. The method of claim 22 or 23, wherein the message for rejecting the resume request includes first information informing that the resume request is rejected for small data transmission.

25. Receiving the message comprises: receiving second information indicating that the resume request is denied for one or more predetermined types of small data transmissions; 23. The method of claim 22, comprising:

26. Receiving the message comprises: a first waiting time for small data transmission; a second waiting time for one or more predetermined types of small data transmission; a third waiting time for non-small data transmission; receiving third information informing at least one of 23. The method of claim 22, comprising:

27. The one or more predetermined types of small data transmissions include: Random access based small data transmission, Configuration grant-based small data transmission, 27. The method of claim 25 or 26, comprising at least one of:

28. Receiving the message comprises: receiving fourth information informing the first device whether it will transition to an idle state or remain in an inactive state; 23. The method of claim 22, comprising:

29. initiating a non-small data transmission procedure for transmitting data to the second device in response to receiving the message; 23. The method of claim 22, further comprising:

30. 30. The method of claim 29, wherein the data includes at least data that was refused to be transmitted using the small data transmission.

31. 31. The method of claim 29 or 30, wherein the data includes data sent with the resume request.

32. Receiving the message comprises: receiving fifth information indicating that the resume request is denied for a predetermined type of radio bearer associated with the first device; 23. The method of claim 22, comprising:

33. 23. The method of claim 22, wherein the first device is a terminal device and the second device is a network device.

34. receiving, at the second device, from the first device, a request to resume at least one radio bearer for small data transmission and at least one radio bearer for non-small data transmission; sending a message to the first device rejecting the resume request for the at least one radio bearer for small data transmission and not rejecting the resume request for the at least one radio bearer for non-small data transmission; A method of communication, including

35. 35. The method of claim 34, wherein the message to reject the resume request indicates that the resume request is rejected for small data transmissions but not for non-small data transmissions.

36. 36. The method of claim 34 or 35, wherein the message for rejecting the resume request includes first information informing that the resume request is rejected for small data transmission.

37. Sending the message comprises: transmitting second information indicating that the resume request is denied for one or more predetermined types of small data transmissions; 35. The method of claim 34, comprising:

38. Sending the message comprises: a first waiting time for small data transmission; a second waiting time for one or more predetermined types of small data transmission; a third waiting time for non-small data transmission; transmitting third information notifying at least one of the above; 35. The method of claim 34, comprising:

39. The one or more predetermined types of small data transmissions include: Random access based small data transmission, Configuration grant-based small data transmission, 39. The method of claim 37 or 38, comprising at least one of:

40. Sending the message comprises: transmitting fourth information informing the first device whether it will transition to an idle state or remain in an inactive state; 35. The method of claim 34, comprising:

41. Sending the message comprises: sending fifth information indicating that the resume request is rejected for a predetermined type of radio bearer associated with the first device; 35. The method of claim 34, comprising:

42. 35. The method of claim 34, wherein the first device is a terminal device and the second device is a network device.

43. A non-transitory computer readable medium containing program instructions for causing an apparatus to perform the method of any of claims 22 to 33.

44. A non-transitory computer readable medium containing program instructions for causing an apparatus to perform the method of any of claims 34 to 42.