Terminal device and method performed by the terminal device

Abstract

The embodiments of the present disclosure relate to a method, an apparatus, and a computer-readable medium for communication. The method includes receiving, in a terminal device, a connection rejection message from a network device when the terminal device is performing a first connection resumption procedure initiated for Small Data Transmission (SDT), and initiating a second connection resumption procedure. Thus, in case of network congestion, the SDT procedure can be rejected.

Description

Technical Field

[0005] ,

[0001] Embodiments of the present disclosure generally relate to the field of telecommunications, and more particularly, to a method, apparatus, and computer storage medium for communication during data transmission in an inactive state of a terminal device.

Background Art

[0002] Typically, a terminal device in an inactive state may still have a small amount of infrequent data traffic to transmit. Until the 3rd Generation Partnership Project (3GPP) Release 16, the inactive state did not support data transmission, and the terminal device had to resume connections for both downlink and uplink data (i.e., enter the connected state). This causes unnecessary power consumption and signaling overhead.

[0003] In this case, in 3GPP Release 17, small data transmission (SDT) in the inactive state is approved. Therefore, signaling overhead can be reduced. However, so far, SDT-related technologies are still not fully developed and further development is awaited.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Generally, embodiments of the present disclosure provide a method, apparatus, and computer storage medium for communication. [[ID=​​​​​

[0006] In a second embodiment, a method of communication is provided. The method includes, while the terminal device is executing an SDT procedure, sending a message on the SRB1 to the network device indicating the arrival of non-SDT data, and continuing the SDT procedure in response to receiving a connection refusal message from the network device.

[0007] In a third embodiment, a method of communication is provided. The method includes a network device sending a connection denial message to a terminal device as a response to a first connection resumption procedure initiated for SDT, receiving a connection resumption request message for a second connection resumption procedure not initiated for SDT, and sending a connection establishment message.

[0008] In a fourth embodiment, a method of communication is provided. The method includes, in a terminal device, initiating a configuration grant-based SDT procedure; determining that there are no synchronization signal blocks (SSBs) associated with a configuration grant resource for SDT that are above a threshold; determining that a buffer status report (BSR) has been triggered or that there is buffered data to be sent; and initiating a random access procedure.

[0009] In a fifth embodiment, a terminal device is provided. The terminal device comprises a processor and a memory coupled to the processor. The memory stores, when executed by the processor, instructions causing the terminal device to perform the method described in any one of the first to second embodiments of this disclosure.

[0010] In a sixth embodiment, a network device is provided. The network device comprises a processor and a memory coupled to the processor. The memory stores instructions, when executed by the processor, that cause the network device to perform the method according to the third embodiment of this disclosure.

[0011] In a seventh embodiment, a computer-readable medium storing instructions is provided. When the instructions are executed on at least one processor, the instructions cause the at least one processor to perform a method according to any one of the first or second embodiments of the present disclosure.

[0012] In an eighth aspect, a computer-readable medium storing instructions is provided. When the instructions are executed on at least one processor, the instructions cause the at least one processor to perform the method described in the third aspect of the present disclosure.

[0013] Other features of this disclosure should be easily understood from the following explanation. [Brief explanation of the drawing]

[0014] The above-mentioned and other objectives, features, and advantages of this disclosure will be further clarified by describing in more detail some embodiments of this disclosure in the attached drawings.

[0015] [Figure 1A] This figure shows an exemplary communication network that can implement some embodiments of the present disclosure.

[0016] [Figure 1B] This is a schematic diagram showing a user plane (UP) protocol stack that can implement some embodiments of the present disclosure.

[0017] [Figure 1C] This is a schematic diagram showing a control plane (CP) protocol stack that can implement some embodiments of the present disclosure.

[0018] [Figure 2A] It is a schematic diagram showing an SDT procedure capable of implementing some embodiments of the present disclosure.

[0019] [Figure 2B] It is a schematic diagram showing an SDT procedure including an initial transmission and subsequent transmissions that can implement some embodiments of the present disclosure.

[0020] [Figure 3] It is a schematic diagram showing a process for communication during an SDT procedure according to an embodiment of the present disclosure.

[0021] [Figure 4] It is a schematic diagram showing a process for communication during an SDT procedure according to an embodiment of the present disclosure.

[0022] [Figure 5] It is a diagram showing an exemplary communication method realized in a terminal device according to some embodiments of the present disclosure.

[0023] [Figure 6] It is a diagram showing an exemplary communication method realized in a terminal device according to some embodiments of the present disclosure.

[0024] [Figure 7] It is a diagram showing an exemplary communication method realized in a network device according to some embodiments of the present disclosure.

[0025] [Figure 8] It is a diagram showing an exemplary communication method realized in a network device according to some embodiments of the present disclosure.

[0026] <0000l12>It is a schematic block diagram of a device suitable for realizing an embodiment of the present disclosure.

[0027] In the diagram, identical or similar reference numbers represent identical or similar elements. [Modes for carrying out the invention]

[0028] The principles of this disclosure will now be explained with reference to several embodiments. These embodiments are provided for illustrative purposes only and are intended to help those skilled in the art understand and implement this disclosure, and should be understood as not to imply any limitation on the scope of this disclosure. The disclosures described herein can be implemented in a variety of ways other than those described below.

[0029] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meanings as those generally understood by those skilled in the art.

[0030] As used herein, the term “Terminal Equipment” refers to any device having wireless or wired communication capabilities. Examples of Terminal Equipment include, but are not limited to, User Equipment (UE), personal computers, desktop computers, mobile phones, cellular phones, smartphones, Personal Digital Assistants (PDAs), portable computers, tablets, wearable devices, Internet of Things (IoT) devices, Internet of Everything (IoE) devices, Machine Type Communication (MTC) devices, and in-vehicle devices for V2X communication, where the “X” in V2X represents pedestrians, vehicles or infrastructure / networks, or image acquisition devices such as digital cameras, game devices, music storage and playback devices, or internet-connected home appliances that enable wireless or wired internet access and browsing. The term “Terminal Equipment” may be used interchangeably with UE, mobile station, subscriber station, mobile terminal, user terminal, or wireless device. The term “Network Equipment” refers to any device that can provide or host a cell or coverage on which Terminal Equipment can communicate. Examples of network devices include, but are not limited to, Node B (NodeB or NB), evolved Node B (eNodeB or eNB), next-generation Node B (gNB), Transmit / Receive Point (TRP), Remote Radio Unit (RRU), Radio Head (RH), Remote Radio Head (RRH), femtonode, piconode, and other low-power nodes.

[0031] In one embodiment, a terminal device can be connected to a first network device and a second network device. One of the first and second network devices may be a master node and the other a secondary node. The first and second network devices may use different radio access technologies (RATs). In one embodiment, the first network device may be a first RAT device, and the second network device may be a second RAT device. In one embodiment, the first RAT device is an eNB, and the second RAT device is a gNB. Information regarding different RATs may be transmitted to the terminal device from at least one of the first or second network device. In one embodiment, the first information may be transmitted from the first network device to the terminal device, and the second information may be transmitted from the second network device directly or via the first network device to the terminal device. In one embodiment, information regarding the settings of the terminal device set by the second network device may be transmitted from the second network device via the first network device. Information regarding the reconfiguration of terminal devices set by the second network device may be transmitted from the second network device directly to the terminal devices or via the first network device.

[0032] As used herein, the singular forms “one” and “the foregoing” also include the plural form unless explicitly indicated in the context. The term “including” and its variations should be understood as open-ended terms meaning “including, but not limited to.” The term “based on” should be understood as “at least partially based on.” The terms “one embodiment” and “embodiment” should be understood as “at least one embodiment.” The term “another embodiment” should be understood as “at least one other embodiment.” Terms such as “first,” “second,” etc., may refer to different or identical subjects. The following may include other explicit and implicit definitions.

[0033] In some examples, values, procedures, or devices are referred to as “best,” “worst,” “highest,” “minimum,” “maximum,” etc. Such descriptions are intended to show that a choice can be made from among many usable functional alternatives, and it should be understood that such a choice does not need to be better, smaller, higher, or otherwise more desirable than other choices.

[0034] Traditionally, there are various applications that perform small amounts of infrequent data exchange. For example, in some applications of mobile devices, SDT may include traffic from instant messaging (IM) services, such as heartbeat or keep-alive traffic from IM or email clients and other services, push notifications in various applications, and traffic from wearable devices (e.g., including periodic location information). In some applications of non-mobile devices, SDT may include sensor data (e.g., temperature and pressure measurements transmitted periodically or event-triggered within an IoT network), and measurement and alarm information transmitted from smart meters.

[0035] In the conventional RRC (Radio Resource Control) restart procedure, no uplink data is sent for inactive terminal devices along with the RRC restart request message. On the other hand, in the SDT procedure, uplink data can be sent to the network device for inactive terminal devices along with the RRC restart request message.

[0036] During SDT, uplink data is transmitted from at least one of the radio bearers that supports transmission in an inactive state while the terminal device is in an inactive state. Whether a radio bearer supports data transmission in an inactive state is configured by the network device. In some scenarios, new data (for convenience, also referred to here as non-SDT data) may arrive during SDT from a radio bearer that does not support transmission in an inactive state.

[0037] For the above or other potential scenarios, embodiments of the present disclosure provide improved solutions for communications during SDT to ensure that SDT is completed as quickly as possible. The principles and embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. Examples of communication environments

[0038] Figure 1A is a schematic diagram showing an exemplary communication network 100A that can implement embodiments of the present disclosure. As shown in Figure 1A, the communication network 100A may include a terminal device 110 and a plurality of network devices 120 and 130. Network devices 120 and 130 provide their respective cells 121 and 131. In the example in Figure 1A, the terminal device 110 is located in cell 121 of network device 120, and the terminal device 110 may communicate with network device 120. Cell 121 may be referred to as the serving cell of the terminal device 110.

[0039] The number of devices in Figure 1A is given for illustrative purposes only and should be understood as not implying any limitation to this disclosure. The communication network 100 may include any suitable number of network devices and / or terminal devices suitable for carrying out embodiments of this disclosure. Furthermore, each of the network devices 120 and 130 may provide more cells to the terminal device 110.

[0040] As shown in Figure 1A, the terminal device 110 may communicate with the network device 120 via a channel such as a wireless communication channel. Communication in the communication network 100 may comply with any appropriate standard, including but not limited to, the 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), and Machine Type Communication (MTC). Furthermore, communication may be performed according to any generation of communication protocol that is currently known or will be 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.

[0041] In some dual-connection scenarios, network devices 120 and 130 may simultaneously serve terminal device 110 as either a master node (MN) or a secondary node (SN). Cells provided by the MN form a master cell group (MCG) for terminal device 110, and cells provided by the SN form a secondary cell group (SCG) for terminal device 110. In some scenarios, an inactive terminal device 110 may communicate with network device 120 or 130.

[0042] Communication from terminal device 110 to network device 120 or 130 is called uplink (UL) communication, and communication from network device 120 or 130 to terminal device 110 is called downlink (DL) communication. Terminal device 110 can move between cells of network devices 120, 130, and possibly other network devices. In UL communication, terminal device 110 may transmit UL data and control information to network device 120 or 130 via the UL channel. In DL communication, network device 120 or 130 may transmit DL data and control information to terminal device 110 via the DL channel.

[0043] Communication in the communication network 100 may be performed according to the UP and CP protocol stacks. Generally speaking, in the case of a communication device (e.g., a terminal device or a network device), there may be multiple entities of the network protocol layer in the protocol stack, and these entities may be configured to perform corresponding processes on data or signaling transmitted from and received by the communication device. Figure 1B is a schematic diagram 100B showing network protocol layer entities that may be established for the UP protocol stack in a device according to some embodiments of the present disclosure.

[0044] As shown in Figure 1B, in UP, each of the terminal device 110 and the network device 120 may include one or more entities from higher layers (L2 and L3 layers, i.e., higher layers), including L1 layer entities, that is, physical (PHY) layer entities (also called PHY entities), media access control (MAC) layer entities (also called MAC entities), radio link control (RLC) layer entities (also called RLC entities), packet data convergence protocol (PDCP) layer entities (also called PDCP entities), and service data application protocol (SDAP) layer entities (also called SDAP entities, which are established in 5G and subsequent generations of networks). In some cases, the PHY, MAC, RLC, PDCP, and SDAP entities are in a stacked structure.

[0045] Figure 1C is a schematic diagram 100C showing network protocol layer entities that may be established for the CP protocol stack in devices according to some embodiments of the present disclosure. As shown in Figure 1C, in CP, each of the terminal device 110 and the network device 120 may include one or more entities of the upper layers (L2 and L3 layers), including L1 layer entities, i.e., PHY layer entities (also referred to as PHY entities), MAC layer entities (also referred to as MAC entities), RLC layer entities (also referred to as RLC entities), PDCP layer entities (also referred to as PDCP entities), and Radio Resource Control (RRC) layer entities (also referred to as RRC entities). The RRC layer may further be referred to as the access stratum (AS) layer, and for that purpose, the RRC entities may further be referred to as AS entities. As shown in Figure 1C, the terminal device 110 may further include entities of the non-access stratum (NAS) layer (also referred to as NAS entities). The network-side NAS layer is located within the core network (CN: Core Network, not shown), rather than within the network device itself. In some cases, these entities are in a stacked structure.

[0046] Generally, communication channels are divided into logical channels, transmission channels, and physical channels. A physical channel is the channel through which the PHY layer actually transmits information. For example, a physical channel may include a physical uplink control channel (PUCCH), a physical uplink shared channel (PUSCH), a physical random-access channel (PRACH), a physical downlink control channel (PDCCH), a physical downlink shared channel (PDSCH), and a physical broadcast channel (PBCH).

[0047] The transmit channel is the channel between the PHY layer and the MAC layer. For example, the transmit channel may include a broadcast channel (BCH), a downlink shared channel (DL-SCH), a paging channel (PCH), an uplink shared channel (UL-SCH), and a random access channel (RACH).

[0048] A logical channel is a channel between the MAC layer and the RLC layer. For example, a logical channel may include a dedicated control channel (DCCH), a common control channel (CCCH), a paging control channel (PCCH), a broadcast control channel (BCCH), and a dedicated traffic channel (DTCH).

[0049] Generally, the channel between the RRC layer and the PDCP layer is referred to as a radio bearer. Terminal device 110 may be configured to have at least one data radio bearer (DRB) for carrying data plane data and at least one signaling radio bearer (SRB) for carrying control plane data. In the context of this disclosure, the DRB may be configured to support transmission in an inactive state (i.e., support SDT). Of course, the DRB may also be configured not to support transmission in an inactive state (i.e., not support SDT). The SRB may also be configured to support SDT. Of course, the SRB may also be configured not to support SDT.

[0050] At the RRC layer, three types of SRBs are defined: SRB0, SRB1, and SRB2. SRB0 uses CCCH to establish, restart, or re-establish RRC connections. SRB1 uses DCCH and is established when an RRC connection is established. SRB2 uses DCCH and is established during RRC reconfiguration and after the initial security activation.

[0051] Additionally, a Protocol Data Unit (PDU) session may be established at the NAS layer of the terminal device 110 to send data to or receive data from the CN. The PDU session may correspond to an SDAP entity and may include multiple Quality of Service (QoS) flows. In the context of this disclosure, the QoS flow may be configured to support SDT. Of course, the QoS flow may also be configured not to support SDT.

[0052] In the context of this disclosure, an inactive terminal device 110 may communicate with a network device 120. In some scenarios, when the terminal device 110 has a small amount of infrequent data traffic from a wireless bearer supporting SDT to transmit, the terminal device 110 may initiate an SDT procedure. Figure 2A is a schematic diagram showing a one-time SDT procedure 200A that can be implemented in some embodiments of this disclosure. As shown in Figure 2A, an inactive terminal device 110 may send an RRC restart request to the network device 120 along with UL data associated with the data traffic (201). For example, the terminal device 110 may send the RRC restart request along with UL data in MsgA of a two-step random access procedure or Msg3 of a four-step random access procedure. Of course, the terminal device 110 may further send the RRC restart request along with UL data in a configured grant (CG) resource. The RRC restart request may include a restart cause. Upon receiving an RRC restart request and UL data, the network device 120 may send an RRC release message to the terminal device 110 along with the DL data corresponding to the UL data (202). For example, the network device 120 may send the RRC release message along with the DL data in MsgB of a two-step random access procedure or Msg4 of a four-step random access procedure. Alternatively, the network device 120 may send the RRC release message along with the DL data in response to a transmission on the CG resource. At this point, the SDT procedure 200A terminates.

[0053] Figure 2B is a schematic diagram showing an SDT procedure 200B including an initial transmission and subsequent transmissions, which can implement several embodiments of the present disclosure. As shown in Figure 2B, an inactive terminal device 110 may transmit an RRC restart request to the network device 120 along with UL data and BSR (211). For example, terminal device 110 may transmit an RRC restart request along with UL data and BSR in MsgA of a two-step random access procedure or Msg3 of a four-step random access procedure. Of course, terminal device 110 may further transmit an RRC restart request along with UL data in a configured grant (CG) resource. The RRC restart request may include a restart cause. Upon receiving an RRC restart request along with UL data and BSR, network device 120 may transmit an instruction to terminal device 110 for a subsequent transmission (212). For example, network device 120 may transmit an explicit RRC message indicating a subsequent transmission. As another example, the network device 120 may implicitly indicate a subsequent transmission by sending a UL grant for another transmission. In some embodiments, the network device 120 may send DL data along with instructions to the terminal device 110. At this point, the initial transmission is complete.

[0054] Based on these instructions, terminal device 110 may send additional UL data and BSR to network device 120, for example, based on a dynamic grant or a configuration grant (213). Network device 120 may then send a UL grant for the dynamic grant to terminal device 110 (214). In some embodiments, network device 120 may send DL data along with the UL grant to terminal device 110. Based on the UL grant from network device 120, terminal device 110 may send the remaining UL data to network device 120 (215). Thus, network device 120 may send an RRC release message to terminal device 110 (216). At this point, the subsequent transmission is complete; that is, SDT procedure 200B is finished. It should be understood that SDT procedure 200B may include more or fewer steps in subsequent transmissions. An example of how to handle RRC rejection during SDT.

[0055] As described above, during an SDT procedure, an inactive terminal device 110 may send UL data to a network device 120 along with a single RRC restart request message. The network device 120 may respond to the terminal device 110 with an RRC rejection message, for example, due to network congestion. However, the behavior of the terminal device 110 upon receiving an RRC rejection message is unclear. In view of this, embodiments of the present disclosure propose appropriate behavior to be performed by the terminal device 110 upon or after receiving an RRC rejection message during an SDT procedure.

[0056] Figure 3 is a schematic diagram showing a communication process 300 according to an embodiment of the present disclosure. For illustrative purposes, the process 300 will be described with reference to Figure 1A. The process 300 may involve a terminal device 110 and a network device 120, as shown in Figure 1A. The network device 120 may be the last serving network device for the terminal device 110 or a new network device. While the terminal device 110 is executing a first RRC restart procedure initiated for SDT, a connection denial message (e.g., an RRC denial message) may be received from the network device 120. After receiving the RRC denial message, the terminal device 110 may terminate the SDT procedure and remain in an inactive state, and initiate a second RRC restart procedure.

[0057] As shown in Figure 3, terminal device 110 is executing a first RRC restart procedure initiated for SDT and receives a connection denial message, e.g., an RRC denial message, from network device 120 (310). In some embodiments, after receiving the RRC denial message, terminal device 110 discards buffered packets in the PDCP and RLC entities of the radio bearer configured to have SDT (311). For example, terminal device 110 may perform PDCP SDU discard for an SRB configured to have SDT, where buffered PDCP SDUs and PDCP PDUs are discarded. As another example, terminal device 110 may perform RLC re-establishment for a radio bearer configured to have SDT. In this way, buffered data can be discarded before the subsequent second RRC restart procedure so that terminal device 110 can obtain a precise amount of data to determine whether the SDT procedure can be triggered for the second RRC restart procedure.

[0058] Currently, during the MAC reset procedure, all time alignment timers are considered to have expired. When the alignment timer for SDT expires, the terminal device should discard the configuration grant resources for SDT. In some embodiments, after receiving an RRC rejection message, the terminal device 110 executes the MAC reset procedure (312), and the configuration grant resources for SDT are maintained during the MAC reset procedure. For example, during the MAC reset procedure, the terminal device 110 considers all time alignment timers to have expired. However, the terminal device 110 retains the configuration grants used for SDT when the time alignment timers expire. In other words, when the time alignment timers expire, the terminal device 110 discards only the configuration grants that were not set for SDT. As another example, during the MAC reset procedure, the terminal device 110 maintains the time alignment timers for SDT, in other words, the terminal device 110 does not consider the time alignment timers to have expired. Thus, the setting grant resources for SDT can be maintained and used for the second RRC restart procedure.

[0059] If a second RRC restart procedure is initiated within the same cell, the same security key will be generated, and terminal device 110 may encrypt different packets using the same security key and the same PDCP count value. This is known as the unacceptable security key stream reuse problem.

[0060] In some embodiments, the terminal device 110 may perform a horizontal security key change to avoid the problem of reusing security key streams. In some embodiments, after receiving an RRC rejection message from the network device 120 during one SDT procedure, the terminal device 110 starts a second RRC restart procedure (320). For example, the second RRC restart procedure may be an SDT procedure or a conventional RRC restart procedure. In some embodiments, the terminal device 110 performs a horizontal key derivation to obtain the key used in the second RRC restart procedure (321). Thus, the problem of reusing security key streams is solved because the security key used in the second RRC restart procedure is different from that used in the first RRC restart procedure.

[0061] In some embodiments, during the second RRC restart procedure, the terminal device 110 transmits buffered / old data within the PDCP entity (322). For example, when performing PDCP re-establishment for an SRB configured to have an SDT, the terminal device 110 maintains the PDCP SDU within the PDCP entity. In other words, during the second RRC restart procedure, the PDCP SDU is not discarded during PDCP re-establishment for an SRB configured to have an SDT. Buffered PDCP PDUs for the SRB are transmitted during the second RRC restart procedure. As another example, for a UM DRB configured to have an SDT, the terminal device 110 transmits PDCP SDUs that have already been submitted to lower layers (e.g., RLC, MAC, PHY layers) during PDCP re-establishment in the second RRC restart procedure. In other words, for a UM DRB configured to have an SDT, during PDCP re-establishment in the second RRC restart procedure, not only PDCP SDUs that have not been submitted to lower layers before, but also PDUs that have already been submitted to lower layers before are transmitted. In this way, buffered data that could not be successfully transmitted during the first RRC restart procedure for SDT can be retransmitted during the second RRC restart procedure.

[0062] In some embodiments, to avoid the problem of reusing security streams, terminal device 110 may initiate an RRC setup procedure, or a second RRC restart procedure initiated by terminal device 110 should be a conventional RRC restart procedure. In some embodiments, after receiving an RRC rejection message from network device 120 during one SDT procedure, terminal device 110 should avoid initiating a second RRC restart procedure that encrypts a different packet by generating the same security key and the same PDCP count value (as used in the previous SDT procedure) (331). For example, if terminal device 110 determines that a different PDCP packet will be sent using the same PDCP count value and the same security key as used in the previous SDT procedure, terminal device 110 transitions to the IDLE state and initiates one RRC setup procedure. As another example, if terminal device 110 determines that a PDCP packet will be sent using the same PDCP count value and the same security key as used in the previous SDT procedure, terminal device 110 initiates a conventional RRC restart procedure, which means there is no UL data sent with the RRC restart request message. The network device 120 sends an RRC installation message to the terminal device (332). Alternatively, the network device 120 sends an RRC restart message including key update settings (332). In this way, the problem of reusing security key streams can be solved. Examples of how to handle RRC refusals in response to non-SDT instructions.

[0063] Figure 4 is a schematic diagram showing a communication process 400 according to an embodiment of the present disclosure. For illustrative purposes, the process 400 will be described with reference to Figure 1A. The process 400 may involve a terminal device 110 and a network device 120 as shown in Figure 1A. The network device 120 may be the last serving network device or a new network device for the terminal device 110.

[0064] As shown in Figure 4, during the initialization of one SDT procedure, the terminal device 110 starts a timer for detecting failures of the SDT procedure. During the SDT procedure, new uplink data (i.e., non-SDT data) may arrive from a radio bearer that does not support SDT. The terminal device 110 may send a message to the network device 120 using SRB1 to indicate the arrival of non-SDT data (410). The network device 120 may send one RRC denial message to the terminal device 110 (420). Upon receiving the RRC denial message, the terminal device 110 continues the SDT procedure (430). In some embodiments, upon receiving the RRC denial message, the terminal device 110 determines whether the timer for SDT is running. If the timer is not running, the terminal device 110 resets the MAC, releases the default MAC cell group settings, discards the security key, pauses SRB1, and notifies the upper layer of the failure to resume the RRC connection. If the timer is running, the terminal device 110 notifies the upper layer of the failure to resume the RRC connection. Here, the failure to resume the RRC connection corresponds to non-SDT data.

[0065] Thus, in response to non-SDT data arrival instructions, ongoing SDT will not be interrupted due to the receipt of RRC rejection messages. Data loss and service interruptions can be avoided. An example of how to handle situations where there are no valid CG-SDT resources.

[0066] Currently, at least one Synchronization Signal Block (SSB) is associated with one CG resource for SDT. After the CG-SDT procedure is triggered, if the Synchronization Signal Reference Signal Received Power (SS-RSRP) of at least one SSB associated with the CG resource for SDT exceeds a threshold, the terminal device 110 considers there to be a qualified setting grant to be used for the SDT procedure. Otherwise, it means there is no qualified setting grant to be used for SDT. If the terminal device 110 initiates a random access (RA) procedure each time it determines that there is no qualified setting grant, frequent triggering of the random access procedure occurs. Embodiments of this disclosure provide a solution for how to avoid this frequent RA triggering.

[0067] In some embodiments, terminal device 110 determines that there are no SSBs associated with CG resources for SDT that exceed a threshold, and determines that a BSR has been triggered, and terminal device 110 initiates a random access procedure. In some embodiments, terminal device 110 determines that there are no SSBs associated with CG resources for SDT that exceed a threshold, and determines that there is buffered data to send, and terminal device 110 initiates a random access procedure. Thus, it is not necessary to trigger a random access procedure every time it is determined that there are no eligible CG resources for SDT. During the CG-SDT procedure, a conventional time alignment timer (i.e., a time alignment timer not used for SDT) has expired and is not running. In some embodiments, during the CG-SDT procedure, terminal device 110 receives an RRC restart message or RRC set message from the network device. The RRC layer of terminal device 110 should indicate to the MAC layer of terminal device 110 to start or restart the conventional time alignment timer. When the MAC layer of terminal device 110 receives an instruction from the RRC layer of terminal device 110, terminal device 110 should start or restart the conventional time alignment timer. In this way, the conventional time alignment timer can start running for the connected terminal device. Examples of implementation of the method

[0068] Therefore, embodiments of this disclosure provide communication methods implemented in terminal devices. These methods will be described below with reference to Figures 5-7.

[0069] Figure 5 shows exemplary communication methods 500 implemented in a terminal device according to some embodiments of the present disclosure. For example, method 500 may be implemented in a terminal device 110 as shown in Figure 1A. Method 500 will now be described with reference to Figure 1A for illustrative purposes. It should be understood that method 500 may include additional blocks not shown and / or some of the illustrated blocks may be omitted, and the scope of the present disclosure is not limited in this respect.

[0070] In block 510, while terminal device 110 is executing a first connection restart procedure initiated for SDT, terminal device 110 receives a connection denial message from network device 120. In some embodiments, upon receiving the connection denial message, terminal device 110 discards buffered packets for radio bearers configured to have SDT. In some embodiments, terminal device 110 performs PDCP SDU discard for SRBs configured to have SDT. In some embodiments, upon receiving the connection denial message, terminal device 110 executes a MAC reset procedure, and the configuration grant resources for SDT are maintained during the MAC reset procedure.

[0071] In block 520, terminal device 110 isThen, a second connection restart procedure is initiated. In some embodiments, the terminal device performs a horizontal key derivation to obtain the security key to be used during the second connection restart procedure. In some embodiments, the terminal device 110 transmits buffered packets within the PDCP entity for radio bearers configured to have an SDT. In some embodiments, the terminal device 110 maintains a PDCP SDU for SRBs configured to have an SDT during the PDCP re-establishment procedure. In some embodiments, the terminal device 110 transmits a PDCP SDU for a (non-acceptance mode) UM DRB configured to have an SDT, which has already been submitted to a lower layer previously. In some embodiments, the terminal device 110 determines that different packets may be transmitted using the same security key and the same PDCP count value as those used in the first connection restart procedure initiated for the SDT, and either enters an idle state to initiate a connection establishment procedure, or initiates a second connection restart procedure that does not have any UL data to be transmitted during the inactive state.

[0072] Figure 6 shows exemplary communication methods 600 implemented in a terminal device according to some embodiments of the present disclosure. For example, method 600 may be implemented in a terminal device 110 as shown in Figure 1A. Method 600 will now be described with reference to Figure 1A for illustrative purposes. It should be understood that method 600 may include additional blocks not shown and / or some of the illustrated blocks may be omitted, and the scope of the present disclosure is not limited in this respect.

[0073] In block 610, when the terminal device 110 is executing the Small Data Transmission (SDT) procedure, it sends a message on the SRB1 to the network device 120 indicating the arrival of non-SDT data, and upon receiving a connection rejection message from the network device, the terminal device 110 continues SDT transmission.

[0074] Figure 7 shows an exemplary communication method 700 implemented in a network device according to some embodiments of the present disclosure. For example, method 700 may be implemented in a network device 120 as shown in Figure 1A. Method 700 will now be described with reference to Figure 1A for illustrative purposes. It should be understood that method 700 may include additional blocks not shown and / or some of the illustrated blocks may be omitted, and the scope of the present disclosure is not limited in this respect.

[0075] In block 710, the network device 120 sends a connection denial message to the terminal device 110 as a response to a first connection reactivation procedure initiated for SDT, receives a connection reactivation request message for a second connection reactivation procedure not initiated for SDT, and sends a connection establishment message.

[0076] Figure 8 shows exemplary communication methods 800 implemented in a terminal device according to some embodiments of the present disclosure. For example, method 800 may be implemented in a network device 120 as shown in Figure 1A. Method 800 will now be described with reference to Figure 1A for illustrative purposes. It should be understood that method 800 may include additional blocks not shown and / or some of the illustrated blocks may be omitted, and the scope of the present disclosure is not limited in this respect.

[0077] In block 810, terminal device 110 initiates a configuration grant-based SDT procedure, determines that there are no SSBs associated with configuration grant resources for SDT that exceed the threshold, determines that a Buffer Status Report (BSR) has been triggered or that there is buffered data to send, and initiates a random access procedure. Examples of these implementations

[0078] Figure 9 is a schematic block diagram of apparatus 900 suitable for realizing the embodiments of the present disclosure. Apparatus 900 is shown in Figure 1. AThis can be considered as another exemplary embodiment of the terminal device 110 or network device 120 as shown. Therefore, the device 900 may be implemented in the terminal device 110, or the network device 120 or 130, or as at least a part thereof.

[0079] As shown in the figure, the device 900 comprises a processor 910, a memory 920 coupled to the processor 910, appropriate transmitters (TX) and receivers (RX) 940 coupled to the processor 910, and a communication interface coupled to the TX / RX 940. 920 is , and stores at least a portion of program 930. The TX / RX 940 is used for bidirectional communication. The TX / RX 940 has at least one antenna to facilitate communication, but the access nodes referred to herein may actually have multiple antennas. The communication interface may represent any interface necessary for communication with other network elements, such as the X2 / Xn interface for bidirectional communication between eNBs / gNBs, the S1 / NG interface for communication between a Mobility Management Entity (MME) / Access and Mobility Management Function (AMF) / SGW / UPF and an eNB / gNB, the Un interface for communication between an eNB / gNB and a Relay Node (RN), or the Uu interface for communication between an eNB / gNB and a terminal device.

[0080] Program 930 is shown in Figure 1 AAs described herein with reference to Figure 8, it is assumed that the program instructions, when executed by the associated processor 910, enable the device 900 to operate according to embodiments of the present disclosure. Embodiments of the present disclosure may be implemented by computer software executable by the processor 910 of the device 900, by hardware, or by a combination of software and hardware. The processor 910 may be configured to implement various embodiments of the present disclosure. Furthermore, a combination of the processor 910 and the memory 920 may form a processing means 950 suitable for implementing various embodiments of the present disclosure.

[0081] Memory 920 may be of any type suitable for a local technology network and may be implemented using any suitable data storage technology, such as non-temporary computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as non-limiting examples. Although only one memory 920 is shown in device 900, there may be several physically different memory modules in device 900. Processor 910 may be of any type suitable for a local technology network and may include, as non-limiting examples, one or more of general-purpose computers, dedicated computers, microprocessors, digital signal processors (DSPs), and processors based on multi-core processor architectures. 900 is The system may have multiple processors, for example, application-specific integrated circuit chips that are time-dependent to a clock that synchronizes the main processor.

[0082] In some embodiments, the circuit includes a circuit configured to receive a connection denial message from a network device and initiate a second connection reactivation procedure when a terminal device is performing a first connection reactivation procedure initiated for SDT.

[0083] In some embodiments, the circuit may be further configured to discard buffered packets for radio bearers configured to have an SDT in response to receiving a connection rejection message.

[0084] In some embodiments, the circuit may be further configured to perform PDCP SDU discarding for signaling radio bearers configured to have an SDT.

[0085] In some embodiments, the circuit may further be configured to perform a MAC reset procedure in response to receiving a connection rejection message, and to maintain a configuration grant resource for SDT during the MAC reset procedure.

[0086] In some embodiments, the circuit may be further configured to initiate a second connection reactivation procedure by performing a horizontal key derivation to obtain a security key.

[0087] In some embodiments, the circuit may further be configured to initiate the second connection reactivation procedure and transmit buffered packets within the PDCP entity for radio bearers configured to have an SDT.

[0088] In some embodiments, the circuit may be further configured to maintain the PDCP SDU for SRBs configured to have an SDT during the PDCP re-establishment procedure, or to perform the transmission of a PDCP SDU that has already been submitted to a lower layer for UM DRBs configured to have an SDT.

[0089] In some embodiments, the circuit may further determine that different packets may be transmitted using the same security key and the same PDCP count value as those used in a first connection restart procedure initiated for SDT, and may be configured to perform at least one of the following: enter an idle state and initiate a connection setup procedure, or initiate a second connection restart procedure that does not have any UL data transmitted during the inactive state.

[0090] In some embodiments, the terminal device includes a circuit configured to send a message on the SRB1 to the network device indicating the arrival of non-SDT data when executing the SDT procedure, receive a connection rejection message from the network device, and continue the SDT transmission.

[0091] In some embodiments, the circuit may further determine that a timer for SDT failure detection is running and be configured to notify a higher layer of the failure to resume the RRC connection.

[0092] In some embodiments, the network device includes a circuit configured to send a connection denial message to a terminal device as a response to a first connection reactivation procedure initiated for SDT, receive a connection reactivation request message for a second connection reactivation procedure not initiated for SDT, and send a connection establishment message.

[0093] In some embodiments, the terminal device comprises a circuit configured to initiate a configuration grant-based SDT procedure in the terminal device, determine that there are no SSBs associated with configuration grant resources for SDT that exceed a threshold, determine that a Buffer Status Report (BSR) has been triggered or that there is buffered data to send, and initiate a random access procedure.

[0094] As used herein, the term “circuit” may mean a hardware circuit and / or a combination of a hardware circuit and software. For example, a circuit may be a combination of an analog and / or digital hardware circuit and software / firmware. In yet another example, a circuit may be any part of a hardware processor having a digital signal processor, software and one or more memories, which work together to cause a device such as a terminal or 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 part thereof that requires software / firmware for operation, but the software may not be present if it is not required for operation. As used herein, the term “circuit” also includes the implementation of a hardware circuit or one or more processors alone, or a part of a hardware circuit or one or more processors and their (or their) accompanying software and / or firmware.

[0095] Overall, various embodiments of the Disclosure may be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some embodiments may be implemented in hardware, while others may be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. Although various embodiments of the Disclosure are illustrated and described using block diagrams, flowcharts, or any other pictorial representation, it should be understood that any blocks, devices, systems, techniques, or methods described herein may be implemented, in non-limiting examples, in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or any combination thereof.

[0096] This disclosure also provides at least one computer program product tangibly stored on a non-temporary computer-readable storage medium. The computer program product is shown in Figure 1. A ~Figure 9 This includes computer-executable instructions, such as instructions contained in a program module, which are executed within a device on the target real or virtual processor, in order to perform the processes or methods described above. Generally, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform a specific task or realize a specific abstract data type. In various embodiments, the functionality of a program module may be combined or separated from other program modules as needed. The machine-executable instructions of a program module may be executed within a local or distributed device. In a distributed device, the program module may reside in both local and remote storage media.

[0097] Program code for performing the methods of this 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 dedicated computer, or other programmable data processing device, and when executed by the processor or controller, the program code may implement the functions / operations specified in the flowcharts and / or block diagrams. The program code may run entirely on a machine, partially on a machine, as an independent software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0098] The program code described above may be implemented on a machine-readable medium, which may be any tangible medium that can contain or store programs 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, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or apparatus, or any suitable combination of the aforementioned mediums. More specific examples of machine-readable storage media may include electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above.

[0099] While the operations have been described in a specific order, it should not be understood that, in order to obtain the desired results, these operations must be performed in the specific order shown, or in a sequential order, or that all of the described operations must be performed. In some cases, multitasking and parallel processing may be advantageous. Similarly, while some specific implementation details are included in the above discussion, these should not be interpreted as limitations on the scope of this disclosure, but rather as descriptions of features that may be specific to a particular embodiment. Some features described in the context of individual embodiments may be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented separately or in any suitable subcombination in multiple embodiments.

[0100] While this disclosure has been described in language specific to structural features and / or methodological behavior, it should be understood that the disclosure as defined in the attached claims is not necessarily limited to the specific features or behaviors described above. Rather, the specific features and behaviors described above are disclosed as exemplary forms of implementing the claims.

Claims

1. A means for determining whether there is data for transmission for at least one radio bearer configured for Small Data Transmission (SDT) when a Configured Grant (CG) - Small Data Transmission (SDT) is triggered, in accordance with the absence of a Synchronization Signal Block (SSB) configured for a CG - SDT having Synchronization Signal Reference Signal Received Power (SS-RSRP) above a threshold, Means for initiating a random access procedure in response to determining that there is data for transmission for at least one wireless bearer configured for the SDT, If an RRC denial message is received in response to an RRC restart request being sent while the Radio Resource Control (RRC) restart procedure for the SDT is in progress, means for a Packet Data Convergence Protocol (PDCP) entity to perform Service Data Unit (SDU) discard for a Signaling Radio Bearer (SRB) configured to have the SDT, Means for executing further RRC restart procedures, A terminal device equipped with the following features.

2. Means for receiving RRC restart messages or RRC installation messages, Means for instructing the Media Access Control (MAC) entity of the terminal device to start the time alignment timer in response to the time alignment timer not being executed, The terminal device according to claim 1, further comprising:

3. Means for considering a setting grant for the CG-SDT to be valid in accordance with the SSB set for the CG-SDT, which has the SS-RSRP exceeding a threshold when the CG-SDT is triggered. The terminal device according to claim 1, further comprising:

4. A method performed by a terminal device, When a Configured Grant (CG) - Small Data Transmission (SDT) is triggered, it determines whether there is data for transmission for at least one radio bearer configured for the CG - SDT that has a Synchronization Signal Reference Signal Received Power (SS-RSRP) above a threshold, and Initiating a random access procedure in response to determining that there is data for transmission for at least one wireless bearer configured for the SDT, If an RRC denial message is received in response to an RRC restart request being sent while the Radio Resource Control (RRC) restart procedure for the SDT is in progress, the Packet Data Convergence Protocol (PDCP) entity shall perform a Service Data Unit (SDU) discard for the Signaling Radio Bearer (SRB) configured to have the SDT, Performing further RRC restart procedures, A method that includes this.

5. Receiving an RRC restart message or an RRC installation message, In response to the time alignment timer not being executed, the Media Access Control (MAC) entity of the terminal device is instructed to start the time alignment timer, The method according to claim 4, further comprising:

6. When the CG-SDT is triggered, the setting grant for the CG-SDT is considered valid in accordance with the SSB set for the CG-SDT, which has an SS-RSRP that exceeds a threshold. The method according to claim 4, further comprising:

Images