User device and method for user device

Abstract

The embodiments of the present disclosure relate to a communication method, an apparatus, and a computer-readable medium, the method including: when first uplink data from at least one radio bearer that does not support transmission in an inactive state arrives during transmission of second uplink data in the inactive state, a terminal device generates an indication of arrival of the first uplink data, thereby ensuring that transmission in the inactive state is completed efficiently.

Description

[Technical field]

[0001] TECHNICAL FIELD Embodiments of the present disclosure relate generally 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 technology]

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

[0003] In this case, small data transmission (SDT) in inactive state has been approved in 3GPP Release 17, thus reducing the signaling overhead. However, so far, SDT-related technologies are still underdeveloped and further development is required. Summary of the Invention [Problem to be solved by the invention]

[0004] Generally, embodiments of the present disclosure provide a communication method, apparatus, and computer storage medium. [Means for solving the problem]

[0005] In a first aspect, a communication method is provided, the method including: generating, in a terminal device according to a determination that first uplink data from at least one radio bearer not supporting transmission in an inactive state arrives during transmission of second uplink data in the inactive state, an indication of arrival of the first uplink data; and transmitting the indication to a network device.

[0006] In a second aspect, a communication method is provided, the method including: determining, in a terminal device, whether an uplink grant from a network device accommodates the uplink data and does not additionally accept a buffer status report (BSR) according to a determination that uplink data is transmitted in an inactive state; and canceling the BSR according to a determination that the uplink grant accommodates the uplink data and does not additionally accept the BSR.

[0007] In a third aspect, a communication method is provided, the method including: transmitting, in a terminal device, uplink data to a network device in an inactive state, where a power headroom report (PHR) is not triggered during the transmission of the uplink data in the inactive state.

[0008] In a fourth aspect, a communication method is provided, the method including: in a terminal device, transmitting uplink data to a network device in an inactive state; and triggering a PHR.

[0009] In a fifth aspect, a communication method is provided, the method including: in a terminal device, during transmission of uplink data in an inactive state to a network device, determining whether a reference signal receiving power (RSRP) of a serving cell of the terminal device is lower than a threshold power, and according to the determination that the RSRP of the serving cell of the terminal device is lower than the threshold power, entering an idle state or terminating the transmission of the uplink data in the inactive state while maintaining the inactive state.

[0010] In a sixth aspect, a communication method is provided, the method including receiving, in a network device, an indication from a terminal device indicating that first uplink data from at least one radio bearer that does not support transmission in an inactive state arrives during transmission of second uplink data in the inactive state.

[0011] In a seventh aspect, a terminal device is provided, the terminal device comprising: a processor; and a memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the terminal device to perform a method according to the first to fifth aspects of the present disclosure.

[0012] In an eighth aspect, there is provided a network device comprising: a processor; and a memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the network device to perform a method according to the sixth aspect of the present disclosure.

[0013] In a ninth aspect, a computer readable medium is provided having instructions stored thereon that, when executed on at least one processor, cause the at least one processor to perform a method according to the first to fifth aspects of the present disclosure.

[0014] In a tenth aspect, there is provided a computer readable medium having stored thereon instructions that, when executed on at least one processor, cause said at least one processor to perform a method according to the sixth aspect of the present disclosure.

[0015] Other features of the present disclosure will become readily apparent from the following description. [Brief description of the drawings]

[0016] The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description of several embodiments of the present disclosure in the drawings.

[0017] [Figure 1A] FIG. 1 illustrates an example communication network in which some embodiments of the present disclosure may be implemented.

[0018] [Figure 1B] FIG. 1 is a schematic diagram illustrating a user plane (UP) protocol stack in which some embodiments of the present disclosure may be implemented.

[0019] [Figure 1C] FIG. 2 is a schematic diagram illustrating a control plane (CP) protocol stack in which some embodiments of the present disclosure may be implemented.

[0020] [Figure 2A] FIG. 1 is a schematic diagram illustrating an SDT procedure in which some embodiments of the present disclosure can be implemented.

[0021] [Figure 2B] FIG. 2 is a schematic diagram illustrating an SDT procedure including an initial transmission and subsequent transmissions, in which some embodiments of the present disclosure can be implemented.

[0022] [Diagram 3] FIG. 2 is a schematic diagram illustrating a process for communication during an SDT procedure, according to an embodiment of the present disclosure.

[0023] [Figure 4] FIG. 2 illustrates an exemplary communication method implemented in a terminal device according to some embodiments of the present disclosure.

[0024] [Diagram 5] FIG. 1 illustrates another exemplary communication method implemented in a terminal device in accordance with some embodiments of the present disclosure.

[0025] [Figure 6] FIG. 1 illustrates another exemplary communication method implemented in a terminal device in accordance with some embodiments of the present disclosure.

[0026] [Figure 7] FIG. 1 illustrates another exemplary communication method implemented in a terminal device in accordance with some embodiments of the present disclosure.

[0027] [Figure 8] FIG. 1 illustrates another exemplary communication method implemented in a terminal device in accordance with some embodiments of the present disclosure.

[0028] [Figure 9] FIG. 2 illustrates an example communication method implemented in a network device, according to some embodiments of the present disclosure.

[0029] [Figure 10] FIG. 1 is a schematic block diagram of an apparatus suitable for implementing embodiments of the present disclosure.

[0030] In the drawings, the same or similar reference numbers represent the same or similar elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0033] As used herein, the term "terminal device" refers to any device having wireless or wired communication capabilities. Examples of terminal devices 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, any Internet of Things (IoE) devices, machine type communication (MTC) devices, in-vehicle devices for V2X communication, etc., where the "X" in V2X represents a pedestrian, vehicle, or infrastructure / network, or an image capture device such as a digital camera, a gaming device, a music storage and playback device, or an Internet appliance that allows wireless or wired Internet access and browsing, etc. The term "terminal device" can be used interchangeably with UE, mobile station, subscriber station, mobile terminal, user terminal, or wireless device. In addition, the term "network device" refers to a device that can provide or host a cell or coverage through which the terminal device can communicate. Examples of network devices include, but are not limited to, low power nodes such as a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), a next generation Node B (gNB), a transmit / receive point (TRP), a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), a femto node, and a pico node.

[0034] In one embodiment, the terminal device can connect to a first network device and a second network device. One of the first network device and the second network device may be a master node and the other may be a secondary node. The first network device and the second network device 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 about the different RATs may be transmitted from at least one of the first network device or the second network device to the terminal 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 to the terminal device directly or via the first network device. In one embodiment, information about the configuration of the terminal device configured by the second network device may be transmitted from the second network device via the first network device. Information regarding the reconfiguration of the terminal device configured by the second network device may be transmitted from the second network device directly to the terminal device or via the first network device.

[0035] As used herein, the singular forms "a," "an," and "said" include the plural unless the context clearly indicates otherwise. The term "comprises" and variations thereof should be understood as open-ended terms meaning "including, but not limited to." The term "based on" should be understood as "based at least in part 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," and the like can refer to different or the same object. The following may include other explicit and implicit definitions.

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

[0037] Traditionally, there are various applications that exchange data in small amounts and infrequently. For example, in some applications for 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, traffic from wearable devices (including, for example, periodic location information), etc. In some applications for non-mobile devices, SDT may include sensor data (e.g., temperature, pressure measurements transmitted periodically or in an event-triggered manner within an IoT network), metering and alarm information sent from smart meters, etc.

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

[0039] In some scenarios, if the uplink grant from the network device can accommodate all pending data, the BSR may or may not be cancelled. If the BSR is not cancelled, the transmission of the BSR during the SDT will have a negative impact since the uplink data cannot be completed in one transmission. If the BSR is not cancelled, when the BSR determines that the radio bearer does not support data transmission in the inactive state, the network device will provide a UL grant to the terminal device, but the terminal device will not be able to schedule the suspended radio bearer, causing a waste of resources.

[0040] In some other scenarios, the PHR is triggered upon configuration or reconfiguration of the power headroom reporting feature by higher layers and is not used to disable this feature. In other words, the PHR is to be triggered during SDT. Furthermore, the PHR media access control element (MAC CE) has a higher priority than data from any logical channel other than data from the uplink-common control channel (UL-CCCH).

[0041] For these and other potential scenarios, the embodiments of the present disclosure provide an improved solution for communication during SDT to ensure that the SDT is completed as soon as possible. The principles and embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0042] Example of communication environment FIG. 1A is a schematic diagram illustrating an example communication network 100 in which an embodiment of the present disclosure can be implemented. As shown in FIG. 1A, the communication network 100 may include a terminal device 110 and a number of network devices 120 and 130. The network devices 120 and 130 provide respective cells 121 and 131 to serve the terminal device. In the example of FIG. 1A, the terminal device 110 isA terminal device is located in a cell 121 of a network device 120. 110 is , may communicate with network device 120. Cell 121 may include Network device 120 This may also be referred to as the serving cell.

[0043] It should be understood that the number of devices in FIG. 1A is given for illustrative purposes and does not imply any limitations to the present disclosure. Communications network 100 may include any suitable number of network devices and / or terminal devices suitable for implementing embodiments of the present disclosure. Furthermore, each of network devices 120 and 130 may provide more cells to terminal device 110.

[0044] As shown in FIG. 1A, terminal device 110 may communicate with network device 120 via a channel, such as a wireless communication channel. Communications in communication network 100 may 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), Machine Type Communications (MTC), and the like. Furthermore, communications may be performed according to any generation of communications protocols now known or developed in the future. Examples of communications 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) communications protocols.

[0045] In some scenarios of dual connectivity, the network devices 120 and 130 may simultaneously serve the terminal device 110 as a master node (MN) or a secondary node (SN). The cells provided by the MN form a master cell group (MCG) for the terminal device 110, and the cells provided by the SN form a secondary cell group (SCG) for the terminal device 110. In some scenarios, the terminal device 110 may communicate with the network devices 120 or 130 in an inactive state.

[0046] Communications in the direction from terminal device 110 to network device 120 or 130 are referred to as UL communications, and communications in the direction from network device 120 or 130 to terminal device 110 are referred to as DL communications. Terminal device 110 may move between cells of network devices 120, 130, and possibly other network devices. In UL communications, terminal device 110 may transmit UL data and control information to network device 120 or 130 over a UL channel. In DL communications, network device 120 or 130 may transmit DL data and control information to terminal device 110 over a DL channel.

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

[0048] As shown in FIG. 1B, in the UP, each of the terminal device 110 and the network device 120 may include an L1 layer entity, i.e., a physical (PHY) layer entity (also referred to as a PHY entity), and one or more entities of upper layers (L2 layer and L3 layer, i.e., upper layers), including a medium access control (MAC) layer entity (also referred to as a MAC entity), a radio link control (RLC) layer entity (also referred to as an RLC entity), a packet data convergence protocol (PDCP) layer entity (also referred to as a PDCP entity), and a service data application protocol (SDAP) layer entity (also referred to as an SDAP entity, which is established in 5G and subsequent generation networks). In some cases, the PHY, MAC, RLC, PDCP, and SDAP entities are in a stack structure.

[0049] FIG. 1C is a schematic diagram 100C illustrating network protocol layer entities that may be established for a CP protocol stack in an apparatus according to some embodiments of the present disclosure. As shown in FIG. 1C, in a CP, each of the terminal device 110 and the network device 120 may include one or more entities of upper layers (L2 layer and L3 layer), including an L1 layer entity, i.e., a PHY layer entity (also referred to as a PHY entity), a MAC layer entity (also referred to as a MAC entity), an RLC layer entity (also referred to as an RLC entity), a PDCP layer entity (also referred to as a PDCP entity), and a radio resource control (RRC) layer entity (also referred to as an RRC entity). The RRC layer may further be referred to as an access stratum (AS) layer, and therefore the RRC entity may further be referred to as an AS entity. As shown in FIG. 1C, the terminal device 110 may further include a non-access stratum (NAS) layer entity (also referred to as a NAS entity). The NAS layer on the network side is located in a core network (CN, not shown) rather than in a network device. In some cases, these entities are stacked.

[0050] Generally, communication channels are divided into logical channels, transmission channels, and physical channels. Physical channels are channels through which the PHY layer actually transmits information. For example, physical channels 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).

[0051] The transmission channel is a channel between the PHY layer and the MAC layer. For example, the transmission 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).

[0052] A logical channel is a channel between the MAC layer and the RLC layer. For example, the 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).

[0053] Generally, a channel between the RRC layer and the PDCP layer is referred to as a radio bearer. The 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 the present disclosure, the DRB may be configured to support transmission in an inactive state (i.e., to support SDT). Of course, the DRB may be configured to not support transmission in an inactive state (i.e., to support SDT). The SRB may be configured to support SDT. Of course, the SRB may be configured to not support SDT.

[0054] In the RRC layer, three types of SRBs are defined: SRB0, SRB1 and SRB2. SRB0 uses CCCH to establish, resume or re-establish an RRC connection. SRB1 uses DCCH and is established when an RRC connection is established. SRB2 uses DCCH and is established during RRC re-configuration and after the first security activation.

[0055] Additionally, a Protocol Data Unit (PDU) session may be established in the NAS layer of the terminal device 110 to transmit data to the CN and 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 the present disclosure, the QoS flows may be configured to support the SDT. Of course, the QoS flows may be configured not to support the SDT.

[0056] In the context of the present disclosure, the terminal device 110 may communicate with the network device 120 in an inactive state. In some scenarios, the terminal device 110 may initiate an SDT procedure when the terminal device 110 has a small amount of infrequent data traffic from a radio bearer supporting SDT to transmit. FIG. 2A is a schematic diagram illustrating a one-time SDT procedure in which some embodiments of the present disclosure can be implemented. As shown in FIG. 2, the terminal device 110 in an inactive state may send an RRC resume request to the network device 120 together with UL data associated with the data traffic (201). For example, the terminal device 110 may send the RRC resume request together with the UL data in MsgA of a two-step RACH procedure or Msg3 of a four-step RACH procedure. Of course, the terminal device 110 may also send the RRC resume request together with the UL data in a configured grant (CG) resource. The RRC resume request may include a resume reason. Upon receiving the RRC resume request and the UL data, the network device 120 may send an RRC release message to the terminal device 110 together with DL data corresponding to the UL data (202). For example, the network device 120 may send the RRC release message together with the DL data in MsgA of the two-step RACH procedure or Msg4 of the four-step RACH procedure. The network device 120 may also send the RRC release message together with the DL data in response to the transmission on the CG resource. At this point, the SDT procedure 200A ends.

[0057] FIG. 2B is a schematic diagram illustrating an SDT procedure 200B including an initial transmission and subsequent transmissions, in which some embodiments of the present disclosure can be implemented. As shown in FIG. 2, the terminal device 110 in an inactive state may transmit an RRC resume request with UL data and a BSR to the network device 120 (211). For example, the terminal device 110 may transmit the RRC resume request with UL data and a BSR in MsgA of a two-step RACH procedure or Msg3 of a four-step RACH procedure. Of course, the terminal device 110 may also transmit the RRC resume request with UL data in a configured grant (CG) resource. The RRC resume request may include a resume reason. Upon receiving the RRC resume request with the UL data and a BSR, the network device 120 may transmit an indication of a subsequent transmission to the terminal device 110 (212). For example, the network device 120 may transmit an explicit RRC message indicating a subsequent transmission. As another example, the network device 120 may transmit a UL grant for another transmission to implicitly indicate a subsequent transmission. In some embodiments, the network device 120 may transmit the DL data along with the instruction to the terminal device 110. At this point, the initial transmission is complete.

[0058] Based on this indication, the terminal device 110 may transmit another UL data and a BSR to the network device 120, for example, based on a dynamic or configured authorization (213). The network device 120 may then transmit a UL authorization for the dynamic authorization to the terminal device 110 (214). In some embodiments, the network device 120 may transmit DL data to the terminal device 110 along with the UL authorization. Based on the UL authorization from the network device 120, the terminal device 110 may transmit the remaining UL data to the network device 120 (215). Thus, the network device 120 may transmit an RRC release message to the terminal device 110 (216). At this point, the subsequent transmission is complete; that is, the SDT procedure 200B ends. It should be understood that the SDT procedure 200B may include more or fewer steps in the subsequent transmission.

[0059] Example of implementation for processing non-SDT data In some scenarios, uplink data from a radio bearer that does not support SDT (i.e., non-SDT data) may arrive during an SDT procedure. In view of this, an embodiment of the present application provides a solution for indicating the arrival of non-SDT data, which will be described below with reference to FIG. 3. FIG. 3 is a schematic diagram illustrating a process 300 for communication during an SDT procedure according to an embodiment of the present disclosure. For illustrative purposes, the process 300 will be described with reference to FIG. 1. The process 300 may involve the terminal device 110 and the network device 120 as shown in FIG. 1. As shown in FIG. 3, the terminal device 110 determines (310) whether first uplink data from at least one radio bearer that does not support transmission in an inactive state arrives during transmission of second uplink data in an inactive state.

[0060] In other words, the terminal device 110 determines whether non-SDT data arrives during an SDT procedure.

[0061] In some embodiments, when the first uplink data arrives, the NAS layer of terminal device 110 may notify the AS layer of terminal device 110 that the first uplink data has arrived.

[0062] Conventionally, the NAS layer indicates to the AS layer to resume the RRC connection upon an uplink user data packet being sent for a PDU session with suspended user plane resources. However, if new non-SDT data arrives during an SDT and is from the same PDU session, it is unclear whether there is an indication from the NAS layer to the AS layer indicating the arrival of non-SDT data.

[0063] As a countermeasure for this case, when another network device configures support for SDT for a radio bearer and the terminal device 110 is in a connected state with the other network device, the other network device may configure all radio bearers with the same PDU session ID to the same configuration regarding whether or not they support SDT. In this case, the terminal device 110 may receive from the other network device a first configuration indicating that all DRBs associated with the same PDU session identity support transmission in the inactive state, or a second configuration indicating that all DRBs associated with the same PDU session identity do not support transmission in the inactive state. In this way, the radio bearers that do not support transmission in the inactive state are in a different PDU session from the radio bearers that support transmission in the inactive state, so that the NAS layer can inform the AS layer of the arrival of non-SDT data in a conventional manner, i.e., by requesting the AS layer to transition to the RRC connected state. It should be noted that the other network device may be the network device 120, or the last serving network device, or any other suitable network device.

[0064] As another measure for the above case, in some embodiments, the terminal device 110 may notify the NAS layer of the transmission of the second uplink data being performed in the inactive state from the AS layer of the terminal device 110, and may also notify information about the ID of the QoS flow. In some embodiments, the information about the QoS flow ID may be the ID of the QoS flow that does not support SDT. In some embodiments, the information about the QoS flow ID may be the ID of the QoS flow that supports SDT. Since the NAS layer knows all the QoS flow IDs, it can derive the ID of the QoS flow that does not support SDT from the ID of the QoS flow that supports SDT. That is, the NAS layer can know that the terminal device 110 is performing SDT, and can know or derive the ID of the QoS flow that does not support SDT.

[0065] If the first uplink data is associated with a QoS flow identity that does not support SDT, the terminal device 110 may notify the AS layer from the NAS layer that the first uplink data arrives during the transmission of the second uplink data in the inactive state. Thus, when new data arrives at the NAS layer, the NAS layer can know whether the new data is non-SDT data from the QoS flow ID associated with the new data. As a result, the NAS layer can indicate the arrival of the non-SDT data to the AS layer, for example, by requesting the AS layer to transition to the RRC_CONNECTED state.

[0066] When the first uplink data arrives, the AS layer 320 of the terminal device 110 generates an indication indicating the arrival of the first uplink data. In some embodiments, the terminal device 110 may determine whether an access attempt to the first uplink data is prohibited, and if the access attempt is not prohibited, the terminal device may generate the indication. That is, the terminal device 110 may perform a unified access control (UAC) procedure before generating the indication. The indication is generated only if the access attempt is not prohibited. In this way, communication efficiency can be improved.

[0067] Once the indication is generated, the terminal device 110 transmits (330) the indication to the network device 120. The indication may be generated and transmitted in a variety of ways. Several exemplary embodiments for generating and transmitting the indication are described below in conjunction with embodiments 1 to 4.

[0068] EMBODIMENT 1 In this embodiment, the terminal device 110 may generate and transmit a DCCH message as the indication. For example, the terminal device 110 may generate an RRC message using SRB1 to indicate the arrival of data from at least one radio bearer that does not support SDT. In some examples, the RRC message may be an existing RRC message, such as a UE Assistance Information message. In other examples, the RRC message may be a new RRC message that is specially introduced for the indication.

[0069] In some embodiments, the DCCH message may include a resume reason. In some embodiments, the DCCH message may include an expected RRC state, e.g., an RRC CONNECTED state or any other suitable RRC state. In some embodiments, the DCCH message may include information of the first uplink data, i.e., information of non-SDT data. For example, the information of the first uplink data may include at least one of a size of the first uplink data, an identity (ID) of the at least one radio bearer, or a type of the at least one radio bearer. For example, the type of the at least one radio bearer may be an MCG bearer or an SCG bearer, or a split bearer, which is MN-terminated or SN-terminated.

[0070] In some embodiments, the DCCH message may include expected measurement gaps for the target frequency band, e.g., measurement gap requirement information of the terminal device 110 for the NR target frequency band. In some embodiments, the DCCH message may include information of a mobility state of the terminal device 110. In some embodiments, the DCCH message may include an indication of the availability of measurement reports in an idle or inactive state. In some embodiments, the DCCH message may include an indication of the availability of at least one of logged measurements, connection establishment failure information, or radio link failure information. In some embodiments, the DCCH message may include an indication of the availability of a mobility history of the terminal device 110.

[0071] In some embodiments, the terminal device 110 may start or restart a timer (also referred to herein as a first timer for convenience) before starting the transmission of the DCCH message. For example, the terminal device 110 may reuse an existing timer, such as T319. Of course, a new timer may be introduced.

[0072] In some embodiments, the terminal device 110 may stop the first timer upon receiving a response to the DCCH message from the network device 120. For example, the response to the DCCH message may be an RRCResume message, an RRCSetup message, an RRCRelease message, an RRCRelease message with suspendConfig, or an RRCReject message. Of course, any other suitable message is also possible as a response to the DCCH message.

[0073] In some embodiments, the terminal device 110 may stop the first timer upon cell reselection of the terminal device 110. In some embodiments, the terminal device 110 may stop the first timer upon termination of a connection establishment by higher layers associated with the first uplink data.

[0074] In some embodiments, terminal device 110 may store the connection resumption failure information and enter an idle state upon expiration of the first timer. For example, terminal device 110 may perform these operations when entering the RRC IDLE state with a release reason of "RRC resumption failure."

[0075] In some embodiments in which a DCCH message is transmitted, the terminal device 110 may determine whether a first timer is running. If the first timer is not running, the terminal device 110 may transmit a DCCH message to the network device 120. In other words, while the first timer is running, the terminal device 110 is not permitted to transmit another DCCH message indicating the arrival of another non-SDT data. In this way, it can be ensured that the SDT procedure is performed efficiently.

[0076] In some embodiments, terminal device 110 may generate a BSR upon generation of a DCCH message. That is, the arrival of a DCCH message may trigger a BSR. In some embodiments, if there is no uplink grant available to transmit a BSR, terminal device 110 may trigger a scheduling request (SR) to network device 120. In some alternative embodiments, if there is no uplink grant available to transmit a BSR, terminal device 110 may initiate a random access procedure to network device 120.

[0077] In some embodiments, the terminal device 110 may receive an RRC release message (e.g., an RRCRelease message) for SDT from the network device 120. In this case, if a DCCH message has already been generated by the RRC layer of the terminal device 110 or if the first timer is running (i.e., if non-SDT data arrives before receiving the RRCRelease message), the terminal device 110 will take a very long time to recover transmission because the NAS layer of the terminal device 110 is not aware of this situation.

[0078] As a countermeasure in this case, in some embodiments, the terminal device 110 may initiate an RRC connection resumption or establishment procedure by the AS layer. In some alternative embodiments, the terminal device 110 may notify the NAS layer of the failure of the RRC connection resumption for the first uplink data from the AS layer of the terminal device 110. As a result, the NAS layer can indicate to the AS layer to re-establish or establish the RRC connection. In this way, communication efficiency can be enhanced.

[0079] EMBODIMENT 2 In this embodiment, the terminal device 110 may generate and send a MAC CE as an indication. In some embodiments, the MAC CE may have a size of zero bits. That is, the MAC CE may have no content. In some alternative embodiments, the MAC CE may include information of the first uplink data. For example, the information of the first uplink data may include at least one of a size of the first uplink data, an identity of the at least one radio bearer, or a type of the at least one radio bearer. For example, the type of the at least one radio bearer may be an MCG bearer or an SCG bearer, or a split bearer, which is MN-terminated or SN-terminated.

[0080] In some embodiments, the terminal device 110 may start or restart a timer (also referred to herein as a second timer for convenience) before starting the transmission of the MAC CE. For example, the terminal device 110 may reuse an existing timer, such as T319. Of course, a new timer may be introduced.

[0081] In some embodiments, the terminal device 110 may stop the second timer upon receiving a response to the MAC CE from the network device 120. For example, the response to the MAC CE may be an RRCResume message, an RRCSetup message, an RRCRelease message, an RRCRelease message with suspendConfig, or an RRCReject message. Of course, any other suitable message is also possible as a response to the MAC CE.

[0082] In some embodiments, the terminal device 110 may stop the second timer upon cell reselection of the terminal device 110. In some embodiments, the terminal device 110 may stop the second timer upon termination of a connection establishment by higher layers associated with the first uplink data.

[0083] In some embodiments, terminal device 110 may store the connection resumption failure information and enter an idle state upon expiration of the second timer. For example, terminal device 110 may perform these operations when entering the RRC IDLE state with a release reason of "RRC resumption failure."

[0084] In some embodiments in which a MAC CE is transmitted, the terminal device 110 may determine whether the second timer is running. If the second timer is not running, the terminal device 110 may transmit the MAC CE to the network device 120. In other words, while the second timer is running, the terminal device 110 is not permitted to transmit another MAC CE indicating the arrival of another non-SDT data. In this way, it can be ensured that the SDT procedure is performed efficiently.

[0085] In some embodiments, if no uplink grant is available to transmit a MAC CE, terminal device 110 may trigger a scheduling request (SR) to network device 120. In some alternative embodiments, if no uplink grant is available to transmit a MAC CE, terminal device 110 may initiate a random access procedure to network device 120.

[0086] In some embodiments, terminal device 110 may receive an RRC release message (e.g., an RRCRelease message) for SDT from network device 120. In this case, if a MAC CE has already been generated by the RRC layer of terminal device 110 or if a second timer is running (i.e., if non-SDT data arrives before receiving the RRCRelease message), terminal device 110 will take a very long time to recover transmission because the NAS layer of terminal device 110 is not aware of this situation.

[0087] As a countermeasure in this case, in some embodiments, the terminal device 110 may initiate an RRC connection resumption or establishment procedure by the AS layer. In some alternative embodiments, the terminal device 110 may notify the NAS layer of the failure of the RRC connection resumption for the first uplink data from the AS layer of the terminal device 110. As a result, the NAS layer can indicate to the AS layer to re-establish or establish the RRC connection. In this way, communication efficiency can be enhanced.

[0088] In some embodiments, the terminal device 110 may transmit this MAC CE with a higher priority than the priority for the MAC CE for the BSR (excluding the BSR included for padding) and lower than the priority for the MAC CE indicating the cell-radio network temporary identifier (C-RNTI) or the priority for the data from the UL-CCCH. In some alternative embodiments, the terminal device may transmit this MAC CE with a higher priority than the priority for the MAC CE for the BSR (excluding the BSR for padding). In some alternative embodiments, the terminal device may transmit this MAC CE with a lower priority than the priority for the MAC CE indicating the cell-radio network temporary identifier (C-RNTI) or the priority for the data from the UL-CCCH. In this way, it can be ensured that the SDT procedure is completed as soon as possible. For example, the logical channels can be prioritized in the following order (the highest priority is displayed as number 1): - data from the C-RNTI MAC CE or UL-CCCH, - the MAC CE for indication of new arrival of non-SDT data, - a Configured Grant Confirmation MAC CE or a BFR MAC CE or a Multiple Entry Configured Grant Confirmation MAC CE, - Sidelink configured authorization confirmation MAC CE, - LBT failure MAC CE, - the MAC CE for the preferred SL-BSR, - the MAC CE for the BSR, excluding the BSR included for padding, - a single-entry PHR MAC CE or a multi-entry PHR MAC CE, - a MAC CE for the desired guard symbol, - MAC CE for preemptive BSR, - MAC CE for SL-BSRs other than the SL-BSRs prioritized according to Clause 5.22.1.6 and those included in the padding, - Data from any logical channel except data from UL-CCCH.

[0089] EMBODIMENT 3 In this embodiment, the terminal device 110 may generate a message for requesting RRC resumption (e.g., an RRCResumeRequest message or an RRCResumeRequest1 message) as an indication. That is, if there is arrival of non-SDT data after SDT is triggered, the RRC layer of the terminal device 110 may trigger another RRC resumption procedure. The RRCResumeRequest message or the RRCResumeRequest1 message in the RRC resumption procedure is an indication about the arrival of non-SDT data.

[0090] In some embodiments, the terminal device 110 may terminate the transmission of the second uplink data (i.e., SDT) and initiate an RRC resumption procedure for the transmission of the first uplink data. In some embodiments, the terminal device 110 may terminate the SDT by at least one of discarding the current KgNB, KRRCenc, KRRCint, KUPint, and KUPenc keys, resetting the MAC entity of the terminal device 110 and releasing the default MAC cell group configuration, re-establishing the RLC entities of at least the radio bearers supporting transmission in the inactive state (i.e., all radio bearers or only the radio bearers supporting transmission in the inactive state), or suspending the SRB1 and at least the radio bearers supporting transmission in the inactive state (i.e., all radio bearers or only the radio bearers supporting transmission in the inactive state). It should be understood that the termination of the SDT may include more or less actions than those listed above.

[0091] In some embodiments for initiating an RRC restart procedure, the terminal device 110 may provide a restart reason from the AS layer to the NAS layer. In some embodiments, the restart reason may be the same as the reason used in the previous SDT procedure. Of course, the restart reason may also take any other suitable manner. For example, the AS layer may provide a restart reason other than the RNA purpose in the RRCResumeRequest1 or RRCResumeRequest2, for example if the NAS layer does not provide any new restart reason.

[0092] Considering that the UAC procedure has already been completed before starting the RRC resumption procedure or before finishing the transmission of the second uplink data, in some embodiments, the terminal device 110 may skip the UAC procedure in starting the RRC resumption procedure for the first uplink data, thereby improving communication efficiency.

[0093] EMBODIMENT 4 This embodiment is a combination of embodiments 1 to 3. In this embodiment, if an uplink grant is available to send an indication, the terminal device 110 may generate and send the indication as described in embodiment 1 or 2 by generating and sending a DCCH message or a MAC CE.

[0094] If there is no uplink grant available to send the indication, the terminal device 110 may generate and send the indication as described in embodiment 3 by initiating another RRC resumption procedure, thus significantly improving communication efficiency.

[0095] Upon receiving this indication, network device 120 may send a request to retrieve the context of terminal device 110 to another network device as the last serving network device for terminal device 110, with another indication of the arrival of non-SDT data. Example of BSR transmission during SDT

[0096] Conventionally, if an uplink grant can accept all pending data, the BSR may or may not be cancelled. If the BSR is not cancelled, sending a BSR indicating null during the SDT will have a negative effect. In view of this, the embodiment of the present disclosure proposes that the BSR of the SDT is cancelled, should be cancelled, or will be cancelled.

[0097] In some embodiments, if the uplink grant from the network device 120 accepts the uplink data and does not accept the BSR as an additional, the terminal device 110 may cancel the BSR, thus ensuring that the SDT is completed as soon as possible.

[0098] In some embodiments, if the uplink grant from the network device 120 accepts uplink data and additionally accepts a BSR, the terminal device 110 may generate a BSR without taking into account at least one suspended radio bearer. In other words, the amount of data associated with the at least one suspended radio bearer is not counted in the generation of the BSR. In this way, the amount of data related to non-SDT data is excluded, so that the SDT procedure can be performed more efficiently. Example of PHR transmission during SDT

[0099] Conventionally, the PHR is triggered when the power headroom reporting function is configured or reconfigured by higher layers, and is not used to disable this function. In other words, the PHR is triggered during the SDT. Furthermore, the PHR MAC CE has a higher priority than data from any logical channel other than data from the UL-CCCH. In this case, if the uplink grant can only accept uplink data (including UL CCCH, DCCH and DTCH), but cannot accept the PHR MAC CE and its header (3 bytes), the terminal device 110 must perform a subsequent transmission of the SDT.

[0100] In view of this, the embodiments of the present disclosure propose not to transmit a PHR if the uplink grant can accommodate all pending data available for transmission, but is insufficient to additionally accommodate the PHR MAC CE and its header. Some examples are described below in relation to embodiments 4 to 6.

[0101] EMBODIMENT 4 In this embodiment, the terminal device 110 may not trigger a PHR during an SDT procedure, for example, when a default MAC cell group configuration is applied during SDT, a PHR may not be triggered.

[0102] EMBODIMENT 5 In this embodiment, the terminal device 110 may trigger a PHR during an SDT procedure, but the MAC CE for the PHR has a lower priority than data in non-SDT DRBs and SRBs for SDT.

[0103] In some embodiments, if an uplink grant from network device 120 accepts uplink data, terminal device 110 may transmit a PHR with a lower priority than the priority for the uplink data. Otherwise, terminal device 110 may transmit a PHR with a higher priority than the priority for the uplink data.

[0104] In some embodiments, if an uplink grant from network device 120 accepts uplink data but does not additionally accept a PHR, terminal device 110 may transmit a PHR with a lower priority than the priority for the uplink data. Otherwise, terminal device 110 may transmit a PHR with a higher priority than the priority for the uplink data.

[0105] EMBODIMENT 6 In this embodiment, the terminal device 110 may cancel the PHR and start or restart a timer to trigger the generation of another PHR. For example, the timer may be a phr-PeriodicTimer or any other suitable timer.

[0106] In some embodiments, if an uplink grant from network device 120 accepts the uplink data, terminal device 110 may cancel the PHR and start or restart a timer to trigger generation of another PHR.

[0107] In some alternative embodiments, if the uplink grant from the network device 120 accepts uplink data but not an additional PHR, the terminal device 110 may cancel the PHR and start or restart a timer to trigger the generation of another PHR, thus completing the SDT procedure in one transmission. Example of implementation of handling RSRP requirements in SDT

[0108] In some cases, to ensure that as much uplink data as possible can be transmitted normally, an RSRP threshold may be used as a condition for triggering SDT or not. Thus, the terminal device 110 may check the RSRP of the camped cell or the serving cell to see whether the RSRP threshold requirement is met. However, after the SDT is triggered and during the subsequent transmission phase, the RSRP threshold may not be met. Therefore, the handling of the RSRP requirement during the SDT should be considered.

[0109] According to embodiments of the present disclosure, terminal device 110 may determine whether the RSRP of a serving cell of terminal device 110 is below a threshold power. In some embodiments, terminal device 110 may determine whether the RSRP of a serving cell of terminal device 110 is below a threshold power for a certain period of time.

[0110] In some embodiments, terminal device 110 may enter an idle state if the RSRP of the terminal device 110's serving cell is lower than a threshold power. For example, terminal device 110 may perform this action when entering an RRC IDLE state with a release reason of "RRC Restart Failure." Note that this is merely an example and is not intended to limit the disclosure.

[0111] In some embodiments, if the serving cell's RSRP is lower than the threshold power, terminal device 110 may terminate uplink data transmission in the inactive state and remain in the inactive state, e.g., terminal device 110 may suspend or terminate the current SDT procedure and remain in the RRC INACTIVE state.

[0112] In some embodiments, the terminal device 110 may terminate the SDT by at least one of discarding the current KgNB, KRRCenc, KRRCint, KUPint, and KUPenc keys, resetting the MAC entity of the terminal device 110 and releasing the default MAC cell group configuration, re-establishing the RLC entities of at least the radio bearers supporting transmission in the inactive state (i.e., all radio bearers or only the radio bearers supporting SDT), or suspending at least the radio bearers supporting transmission in the inactive state (i.e., all radio bearers or only the radio bearers supporting SDT). It should be understood that the termination of the SDT may include more or less actions than those listed above. In some embodiments, the terminal device 110 may trigger another RRC resumption procedure for the previous data transmission, if necessary.

[0113] Example of the method The embodiments of the present disclosure provide communication methods implemented in a terminal device and a network device, which will be described below with reference to FIGS.

[0114] 4 illustrates an example communication method 400 implemented in a terminal device, according to some embodiments of the present disclosure. For example, the method 400 may be performed in a terminal device 110, such as that shown in FIG. For purposes of explanation, the method 400 will be described below with reference to FIG. It should be understood that the method 400 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the present disclosure is not limited in this respect.

[0115] In block 410, the terminal device 110 determines whether first uplink data from at least one radio bearer that does not support transmission in an inactive state arrives during transmission of second uplink data in an inactive state.

[0116] If the first uplink data arrives, terminal device 110 generates an indication of the arrival of the first uplink data, at block 420. In some embodiments, terminal device 110 may determine whether an attempt to access the first uplink data is barred, and if the access attempt is not barred, terminal device 110 may generate the indication. At block 430, terminal device 110 transmits the indication to network device 120.

[0117] In some embodiments, the terminal device 110 may generate a DCCH message as an indication. In these embodiments, the terminal device 110 may transmit the DCCH message as an indication. In some embodiments, the DCCCH message may include at least one of the following: a resumption reason, an expected RRC state, information of the first uplink data, an expected measurement gap for the target frequency band, information of a mobility state of the terminal device 110, an indication of the availability of a measurement report in an idle or inactive state, an indication of the availability of at least one of the recorded measurements, connection establishment failure information or radio link failure information, and an indication of the availability of a mobility history of the terminal device 110.

[0118] In some embodiments, the terminal device 110 may start or restart the first timer before starting to transmit the DCCH message. In some embodiments, the terminal device 110 may stop the first timer upon at least one of receiving a response to the DCCH message from the network device, a cell reselection of the terminal device, or an interruption of the connection establishment associated with the first uplink data.

[0119] In some embodiments, terminal device 110 may store connection resumption failure information and enter an idle state upon expiration of the first timer. In some embodiments, terminal device 110 may determine whether the first timer is running, and may transmit a DCCH message to network device 120 in accordance with a determination that the first timer is not running.

[0120] In some embodiments, the terminal device 110 may generate a BSR when generating a DCCH message, and if there is no uplink grant available to transmit the BSR, the terminal device 110 may trigger an SR to the network device 120 or initiate a random access procedure to the network device 120.

[0121] In some embodiments in which the terminal device 110 receives an RRC release message from the network device 120, if a DCCH message has already been generated or if the first timer is running, the terminal device 110 may initiate an RRC connection resumption or establishment procedure with the AS layer of the terminal device 110, or may notify the NAS layer of the failure of the RRC connection for the first uplink data from the AS layer of the terminal device 110 to the NAS layer.

[0122] In some embodiments, terminal device 110 may generate a MAC CE having a size of zero bits as the indication. In some embodiments, terminal device 110 may generate a MAC CE including information of the first uplink data as the indication. In these embodiments, terminal device 110 may transmit the MAC CE as the indication.

[0123] In some embodiments, the information of the first uplink data may include at least one of a size of the first uplink data, an identity of the at least one radio bearer, or a type of the at least one radio bearer.

[0124] In some embodiments, terminal device 110 may start or restart a second timer before starting transmission of the MAC CE.

[0125] In some embodiments, the terminal device 110 may stop the second timer upon at least one of receiving a response to the MAC CE from the network device 120, cell reselection of the terminal device 110, or interruption of connection establishment associated with the first uplink data.

[0126] In some embodiments, terminal device 110 may store connection resumption failure information and enter an idle state upon expiration of the second timer.

[0127] In some embodiments, terminal device 110 may determine whether the second timer is running, and if the second timer is not running, terminal device 110 may send a MAC CE to network device 120.

[0128] In some embodiments, the terminal device 110 may receive an RRC release message for transmission of second uplink data in an inactive state from the network device 120, and if the second timer is running, the terminal device 110 may initiate an RRC connection resumption or establishment procedure by the AS layer of the terminal device 110, or may notify the NAS layer of failure to resume the RRC connection for the first uplink data from the AS layer of the terminal device 110.

[0129] In some embodiments, if there is no uplink grant available to transmit the MAC CE, the terminal device 110 may trigger an SR to the network device 120 or initiate a random access procedure to the network device 120.

[0130] In some embodiments, the terminal device 110 may transmit this MAC CE with a priority higher than the priority for the MAC CE for BSRs other than those included for padding, and lower than the priority for the MAC CE indicating the C-RNTI or the priority for data from the UL-CCCH.

[0131] In some embodiments, the terminal device 110 may terminate the transmission of the second uplink data and initiate an RRC resumption procedure for the transmission of the first uplink data, where during the RRC resumption procedure, a message requesting RRC resumption is generated as an indication.

[0132] In some embodiments, if an uplink grant is available for transmitting the indication, terminal device 110 may generate the indication. In some embodiments, if there is no uplink grant available for transmitting the indication, terminal device 110 may terminate the transmission of the second uplink data and initiate an RRC resumption procedure for the transmission of the first uplink data, where during the RRC resumption procedure, a message requesting RRC resumption is generated as the indication.

[0133] In some embodiments, the terminal device 110 may terminate the transmission of the second uplink data by at least one of discarding the current KgNB key, KRRCenc key, KRRCint key, KUPint key, and KUPenc key, resetting the terminal device's MAC entity and releasing the default MAC cell group configuration, re-establishing RLC entities of at least the radio bearers supporting transmission in the inactive state, or suspending SRB1 and at least the radio bearers supporting transmission in the inactive state.

[0134] In some embodiments in which terminal device 110 initiates an RRC restart procedure, terminal device 110 may provide a restart reason to the NAS layer of terminal device 110 via the AS layer of terminal device 110. In some embodiments, the restart reason is the same as the reason used in transmitting the second uplink data.

[0135] In some embodiments, terminal device 110 may initiate an RRC resumption procedure by skipping the determination that the first uplink data access attempt is allowed.

[0136] In some embodiments, the terminal device 110 may receive from another network device a first setting indicating that all DRBs associated with the same PDU session identity support transmission in an inactive state when the terminal device 110 is in a connected state with the other network device, or a second setting indicating that all DRBs associated with the same PDU session identity do not support transmission in an inactive state.

[0137] In some embodiments, the terminal device 110 may notify, from the AS layer to the NAS layer of the terminal device 110, the transmission of the second uplink data performed in the inactive state and information regarding the identity of the QoS flow that does not support transmission in the inactive state. If the first uplink data is associated with the identity of the QoS flow, the terminal device 110 may notify, from the NAS layer to the AS layer, that the first uplink data arrives during the transmission of the second uplink data in the inactive state.

[0138] In this way, the arrival of non-SDT data during an SDT can be indicated to the network side. The implementation of the method described in Figure 4 basically corresponds to the process described in relation to Figure 3, and therefore further details are omitted here.

[0139] 5 illustrates another exemplary communication method 500 implemented in a terminal device, according to some embodiments of the present disclosure. For example, the method 500 may be performed in a terminal device 110, such as that shown in FIG. For purposes of explanation, the method 500 is described below with reference to FIG. It should be understood that the method 500 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the present disclosure is not limited in this respect.

[0140] 5, in block 510, terminal device 110 determines whether uplink data is transmitted in the inactive state. If terminal device 110 determines that uplink data is transmitted in the inactive state, the process proceeds to block 520.

[0141] In block 520, the terminal device 110 determines whether the uplink grant from the network device 120 accepts uplink data and does not accept a BSR as an addition. If the terminal device 110 determines that the uplink grant accepts uplink data and does not accept a BSR as an addition, processing proceeds to block 530. In block 530, the terminal device 110 cancels the BSR. In this way, it is possible to ensure that the SDT is completed as soon as possible.

[0142] In some embodiments, if an uplink grant from the network device 120 accepts uplink data and additionally accepts a BSR, the terminal device 110 may generate a BSR without taking into account at least one radio bearer that is suspended.

[0143] 6 illustrates another exemplary communication method 600 implemented in a terminal device, according to some embodiments of the present disclosure. For example, the method 600 may be performed in a terminal device 110, such as that shown in FIG. For purposes of explanation, the method 600 will be described below with reference to FIG. It should be understood that the method 600 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the present disclosure is not limited in this respect.

[0144] 6, in block 610, the terminal device 110 transmits uplink data to a network device in an inactive state, where no PHR is triggered during the transmission of the uplink data in the inactive state, thereby ensuring that the SDT is completed as soon as possible.

[0145] 7 illustrates another exemplary communication method 700 implemented in a terminal device, according to some embodiments of the present disclosure. For example, the method 700 may be performed in a terminal device 110, such as that shown in FIG. For purposes of explanation, the method 700 will be described below with reference to FIG. 1. It should be understood that the method 700 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the present disclosure is not limited in this respect.

[0146] 7, in block 710, terminal device 110 transmits uplink data to network device 120 in an inactive state. In block 720, terminal device 110 triggers a PHR. In some embodiments, if an uplink grant from network device 120 accepts the uplink data, terminal device 110 may transmit a PHR with a lower priority than the priority for the uplink data. In some embodiments, if an uplink grant from network device 120 accepts the uplink data and does not additionally accept a PHR, terminal device 110 may transmit a PHR with a lower priority than the priority for the uplink data.

[0147] In some embodiments, if an uplink grant from the network device accepts the uplink data, terminal device 110 may cancel the PHR and start or restart a timer to trigger generation of another PHR.

[0148] In some embodiments, if an uplink grant from a network device accepts uplink data but does not accept a PHR as an addition, terminal device 110 may cancel the PHR and start or restart a timer to trigger generation of another PHR.

[0149] 8 illustrates another exemplary communication method 800 implemented in a terminal device, according to some embodiments of the present disclosure. For example, the method 800 may be performed in a terminal device 110, such as that shown in FIG. For purposes of explanation, the method 800 will be described below with reference to FIG. 1. It should be understood that the method 800 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the present disclosure is not limited in this respect.

[0150] 8, terminal device 110 determines whether the RSRP of a serving cell of terminal device 110 is lower than a threshold power during transmission of uplink data in an inactive state, block 810. In some embodiments, terminal device 110 may determine whether the RSRP is lower than a threshold power for a certain period of time.

[0151] If the RSRP of the terminal device's serving cell is lower than the threshold power, the process proceeds to block 820. In block 820, terminal device 110 enters an idle state or remains in an inactive state and terminates uplink data transmission in the inactive state.

[0152] 9 illustrates an example communication method 900 implemented in a network device according to some embodiments of the present disclosure. For example, the method 900 may be implemented in a network device 120 as shown in FIG. For purposes of explanation, the method 900 will be described below with reference to FIG. 1. It should be understood that the method 900 may include additional blocks not shown and / or omit some of the blocks shown, and that the scope of the present disclosure is not limited in this respect.

[0153] As shown in FIG. 9, in block 910, the network device 120 receives an indication from the terminal device 110 indicating that first uplink data from at least one radio bearer that does not support transmission in an inactive state arrives during transmission of second uplink data in the inactive state. In some embodiments, the network device 120 may receive a DCCH message as the indication. In some embodiments, the DCCH message may include at least one of the following: a resumption reason, an expected RRC state, information of the first uplink data, an expected measurement gap for the target frequency band, information of a mobility state of the terminal device 110, an indication of the availability of a measurement report in an idle state or an inactive state, an indication of the availability of at least one of the recorded measurements, connection establishment failure information or radio link failure information, and an indication of the availability of a mobility history of the terminal device 110.

[0154] In some embodiments, the network device 120 may receive an SR from the terminal device 110. In some embodiments, the network device 120 may receive a random access request from the terminal device 110 for execution of a random access procedure.

[0155] In some embodiments, the network device 120 may receive a MAC CE having a size of zero bits. In some embodiments, the network device 120 may receive a MAC CE including information of the first uplink data. In some embodiments, the information of the first uplink data may include at least one of a size of the first uplink data, an identity of the at least one radio bearer, or a type of the at least one radio bearer.

[0156] In some embodiments, network device 120 may send a request to retrieve the context of terminal device 110 to another network device as the last serving network device for terminal device 110, the request having another indication of the arrival of the first uplink data.

[0157] In some embodiments, when terminal device 110 is in a connected state with network device 120, network device 120 may send to terminal device 110 a first setting indicating that all DRBs associated with the same PDU session identity support transmission in an inactive state, or a second setting indicating that all DRBs associated with the same PDU session identity do not support transmission in an inactive state. Device implementation examples

[0158] Fig. 10 is a schematic block diagram of an apparatus 1000 suitable for implementing embodiments of the present disclosure. The apparatus 1000 may be considered as another exemplary implementation of the terminal device 110 or the network device 120 or 130 shown in Fig. 1. Thus, the apparatus 1000 may be implemented in or as at least a part of the terminal device 110 or the network device 120 or 130.

[0159] As shown, the apparatus 1000 comprises a processor 1010, a memory 1020 coupled to the processor 1010, a suitable transmitter (TX) and receiver (RX) 1040 coupled to the processor 1010, and a communication interface coupled to the TX / RX 1040. 1020 is , and stores at least a portion of the program 1030. The TX / RX 1040 is used for bidirectional communication. The TX / RX 1040 has at least one antenna to facilitate communication, although the access nodes referred to herein may in practice have multiple antennas. The communication interface may represent any interface required for communication with other network elements, such as an X2 / Xn interface for bidirectional communication between eNBs / gNBs, an S1 / NG interface for communication between a Mobility Management Entity (MME) / Access and Mobility Management Function (AMF) / SGW / UPF and an eNB / gNB, an Un interface for communication between an eNB / gNB and a relay node (RN), or an Uu interface for communication between an eNB / gNB and a terminal device.

[0160] It is assumed that the program 1030 includes program instructions that, when executed by an associated processor 1010, enable the device 1000 to operate according to embodiments of the present disclosure, as described herein with reference to Figures 1-9. The embodiments herein may be implemented by computer software executable by the processor 1010 of the device 1000, or by hardware, or by a combination of software and hardware. The processor 1010 may be configured to implement various embodiments of the present disclosure. Furthermore, the combination of the processor 1010 and the memory 1020 may form a processing means 1050 suitable for implementing various embodiments of the present disclosure.

[0161] The memory 1020 may be of any type suitable for a local technology network and may be implemented using any suitable data storage technology, such as, by way of non-limiting example, non-transitory computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. Although only one memory 1020 is shown in the device 1000, there may be several physically different memory modules in the device 1000. The processor 1010 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 1000 may have multiple processors, for example application specific integrated circuit chips time-slaved to a clock that synchronizes the main processor.

[0162] In some embodiments, a terminal device comprises a circuit configured to generate, in accordance with a determination that first uplink data from at least one radio bearer that does not support transmission in an inactive state arrives during transmission of second uplink data in the inactive state, an indication of arrival of the first uplink data at the terminal device and transmit the indication to a network device.

[0163] In some embodiments, the circuitry may be configured to generate the indication by determining whether an access attempt of the first uplink data is prohibited, and generating the indication in accordance with a determination that the access attempt is not prohibited.

[0164] In some embodiments, the circuitry may be configured to generate the indication by generating a DCCH including as the indication at least one of the following: a resumption reason, an expected radio resource control (RRC) state, information on first uplink data, an expected measurement gap for the target frequency band, information on a mobility state of the terminal device, an indication of availability of a measurement report in an idle or inactive state, an indication of availability of at least one of the recorded measurements, connection establishment failure information or radio link failure information, and an indication of availability of a mobility history of the terminal device.

[0165] In some embodiments, the circuitry may be configured to transmit the indication by transmitting the DCCH message. In some embodiments, the circuitry may be further configured to start or restart a first timer before commencing transmission of the DCCH message.

[0166] In some embodiments, the circuitry may be further configured to stop the first timer upon at least one of receiving a response to the DCCH message from the network device, a cell reselection of the terminal device, or an interruption of connection establishment associated with the first uplink data.

[0167] In some embodiments, the circuitry may be further configured to store connection resumption failure information and enter an idle state upon expiration of the first timer.

[0168] In some embodiments, the circuitry may be configured to determine whether the first timer is running and, in accordance with a determination that the first timer is not running, transmit the DCCH message by transmitting the DCCH message to the network device.

[0169] In some embodiments, the circuitry may be further configured to generate a BSR upon generation of the DCCH message and, following a determination that no uplink grant is available for transmitting the BSR, trigger an SR to the network device or initiate a random access procedure to the network device.

[0170] In some embodiments, the circuitry may be further configured to receive an RRC release message from the network device and, according to a determination that the DCCH message has already been generated or that the first timer is running, initiate an RRC connection resumption or establishment procedure by an access stratum layer of the terminal device, or notify a non-access stratum layer of a failure of the RRC connection resumption for the first uplink data from the access stratum layer of the terminal device to a non-access stratum layer.

[0171] In some embodiments, the circuitry may be configured to generate the indication by generating as the indication a MAC CE having a size of zero bits. In some embodiments, the circuitry may be configured to generate the indication by generating as the indication a MAC CE including information of the first uplink data. In some embodiments, the information of the first uplink data includes at least one of a size of the first uplink data, an identity of the at least one radio bearer, or a type of the at least one radio bearer.

[0172] In some embodiments, the circuitry may be configured to transmit the indication by transmitting the MAC CE. In some embodiments, the circuitry may be further configured to start or restart a second timer before commencing transmission of the MAC CE.

[0173] In some embodiments, the circuitry may be further configured to stop the second timer upon at least one of receiving a response to the MAC CE from the network device, a cell reselection of the terminal device, or an interruption of connection establishment associated with the first uplink data.

[0174] In some embodiments, the circuitry may be further configured to store connection resumption failure information and enter an idle state upon expiration of the second timer.

[0175] In some embodiments, the circuitry may be configured to transmit the MAC CE by determining whether the second timer is running and, in accordance with a determination that the second timer is not running, transmitting the MAC CE to the network device.

[0176] In some embodiments, the circuitry may be further configured to receive from the network device an RRC release message for transmission of the second uplink data in the inactive state, and, according to a determination that the second timer is running, initiate an RRC connection resumption or establishment procedure by an access stratum layer of the terminal device, or notify a non-access stratum layer of the terminal device of a failure of the RRC connection resumption for the first uplink data.

[0177] In some embodiments, the circuitry may be further configured to trigger an SR to the network device or initiate a random access procedure to the network device in accordance with a determination that no uplink grant is available for transmitting the MAC CE.

[0178] In some embodiments, the circuitry may be configured to transmit the indication by transmitting the MAC CE with a priority higher than a priority for a MAC CE for a BSR other than a BSR included for padding, and lower than a priority for a MAC CE indicating a C-RNTI or a priority for data from a UL-CCCH.

[0179] In some embodiments, the circuitry may be configured to generate the indication by terminating transmission of the second uplink data, initiating an RRC resumption procedure for transmission of the first uplink data, and generating, during the RRC resumption procedure, a message requesting RRC resumption as the indication.

[0180] In some embodiments, the circuitry may be configured to generate the indication in accordance with a determination that an uplink grant is available for transmitting the indication, and in accordance with a determination that no uplink grant is available for transmitting the indication, to terminate transmission of the second uplink data and to initiate an RRC resumption procedure for transmission of the first uplink data, and to generate the indication during the RRC resumption procedure by generating a message requesting RRC resumption as the indication.

[0181] In some embodiments, the circuitry may be configured to terminate transmission of the second uplink data by at least one of discarding the current KgNB key, KRRCenc key, KRRCint key, KUPint key and KUPenc key, resetting a MAC entity of the terminal device and releasing a default MAC cell group configuration, re-establishing RLC entities of at least the radio bearers supporting transmission in the inactive state, or suspending signaling radio bearer 1 and at least the radio bearers supporting transmission in the inactive state.

[0182] In some embodiments, the circuitry may be configured to initiate the RRC restart procedure by providing a restart reason to a non-access stratum layer of the terminal device by an access stratum layer of the terminal device. In some embodiments, the restart reason is the same as the reason used in transmitting the second uplink data. In some embodiments, the circuitry may be configured to initiate the RRC restart procedure by skipping a determination that the first uplink data access attempt is allowed.

[0183] In some embodiments, the circuitry may be further configured to receive a first setting from another network device indicating that all data radio bearers associated with the same PDU session identity support transmission in the inactive state when the terminal device is in a connected state with the other network device, or to receive a second setting from the network device indicating that all data radio bearers associated with the same PDU session identity do not support transmission in the inactive state.

[0184] In some embodiments, the circuitry may be further configured to notify, from an AS layer of the terminal device to a NAS layer, of the transmission of the second uplink data to be performed in the inactive state and information regarding an identity of a QoS flow that does not support transmission in the inactive state, and, according to a determination that the first uplink data is associated with the identity of the QoS flow, to notify, from the NAS layer to the AS layer, that the first uplink data arrives during the transmission of the second uplink data in the inactive state.

[0185] In some embodiments, the terminal device comprises a circuit configured to determine, in accordance with a determination that uplink data is transmitted in an inactive state, whether an uplink grant from a network device accepts the uplink data and does not accept a BSR as an addition, and to cancel the BSR in accordance with a determination that the uplink grant accepts the uplink data and does not accept the BSR as an addition. In some embodiments, the circuit may be further configured to generate the BSR without considering at least one radio bearer that is suspended if an uplink grant from the network device 120 accepts the uplink data and accepts the BSR as an addition.

[0186] In some embodiments, a terminal device comprises a circuit, the circuit being configured in the terminal device to transmit uplink data to a network device in an inactive state, wherein a PHR is not triggered during the transmission of the uplink data in the inactive state.

[0187] In some embodiments, a terminal device includes a circuit, the circuit configured to transmit uplink data to a network device in an inactive state at the terminal device and trigger a PHR. In some embodiments, the circuit may be configured to transmit the PHR with a lower priority than the priority for the uplink data according to a determination that an uplink grant from the network device accepts the uplink data. In some embodiments, the circuit may be configured to transmit the PHR with a lower priority than the priority for the uplink data according to a determination that an uplink grant from the network device accepts the uplink data and does not accept the PHR as an additional.

[0188] In some embodiments, the circuitry may be further configured to cancel the PHR and start or restart a timer to trigger generation of another PHR upon a determination that an uplink grant from the network device accepts the uplink data.

[0189] In some embodiments, the circuitry may be further configured to cancel the PHR and start or restart a timer to trigger generation of another PHR upon a determination that an uplink grant from the network device accepts the uplink data and does not accept the PHR as an additional.

[0190] In some embodiments, the terminal device comprises a circuit configured to determine, in the terminal device, during transmission of uplink data to a network device in an inactive state, whether an RSRP of a serving cell of the terminal device is lower than a threshold power, and, in accordance with a determination that the RSRP of the serving cell of the terminal device is lower than the threshold power, enter an idle state or terminate the transmission of the uplink data in the inactive state while maintaining the inactive state.

[0191] In some embodiments, the circuitry may be further configured to determine whether the RSRP of the serving cell of the terminal device is lower than the threshold power by determining whether the RSRP of the serving cell of the terminal device is lower than the threshold power for a certain period of time.

[0192] In some embodiments, a network device comprises circuitry configured to receive, at the network device, an indication from a terminal device indicating that first uplink data from at least one radio bearer that does not support transmission in an inactive state arrives during transmission of second uplink data in the inactive state.

[0193] In some embodiments, the circuitry may be configured to receive the indication by receiving a DCCH including as the indication at least one of the following: a resumption reason, an expected RRC state, information on first uplink data, an expected measurement gap for the target frequency band, information on a mobility state of the terminal device, an indication of the availability of a measurement report in an idle or inactive state, an indication of the availability of at least one of the recorded measurements, connection establishment failure information or radio link failure information, and an indication of the availability of a mobility history of the terminal device.

[0194] In some embodiments, the circuitry may be further configured to receive an SR from the terminal device or a random access request for performing a random access procedure from the terminal device.

[0195] In some embodiments, the circuitry may be configured to receive the indication by receiving a MAC CE having a size of zero bits. In some embodiments, the circuitry may be configured to receive the indication by receiving a medium access control MAC CE that includes information of the first uplink data.

[0196] In some embodiments, the information of the first uplink data includes at least one of a size of the first uplink data, an identity of the at least one radio bearer, or a type of the at least one radio bearer.

[0197] In some embodiments, the circuitry may be further configured to send a request to retrieve the context of the terminal device to another network device as a last serving network device for the terminal device, the request having another indication of the arrival of the first uplink data.

[0198] In some embodiments, the circuitry may be further configured to, when the terminal device is in a connected state with the network device, send to the terminal device a first setting indicating that all data radio bearers associated with the same PDU session identity support transmission in the inactive state, or send to the terminal device a second setting indicating that all data radio bearers associated with the same PDU session identity do not support transmission in the inactive state.

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

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

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

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

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

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

Claims

1. means for initiating a small data transmission (SDT) procedure; means for transmitting a dedicated control channel (DCCH) message to a network to notify the arrival of the data mapped to the radio bearer not configured for the SDT procedure, when the data mapped to the radio bearer not configured for the SDT procedure becomes available during the SDT procedure; Including, The DCCH message includes a resume reason. User Equipment (UE).

2. The DCCH message is a UE Assistance Information message; The UE of claim 1.

3. means for triggering a power headroom reporting (PHR) procedure; 3. The UE according to claim 1 or 2.

4. means for cancelling the PHR procedure when the SDT procedure is in progress and an uplink (UL) grant can accommodate all pending data available for transmission, but is insufficient to accommodate an additional PHR medium access control (MAC) control element (CE) and its header fields; The UE of claim 3 further comprising:

5. A method for a user equipment (UE), comprising: Initiating a small data transmission (SDT) procedure; sending a dedicated control channel (DCCH) message to a network to notify the arrival of the data mapped to the radio bearer not configured for the SDT procedure, if the data mapped to the radio bearer not configured for the SDT procedure becomes available during the SDT procedure; Including, The DCCH message includes a resume reason. method.

6. The DCCH message is a UE Assistance Information message; The method according to claim 5.

7. Triggering a power headroom reporting (PHR) procedure. The method of claim 5 or 6 further comprising:

8. canceling the PHR procedure if the SDT procedure is in progress and an uplink (UL) grant can accommodate all pending data available for transmission, but is insufficient to accommodate an additional PHR medium access control (MAC) control element (CE) and its header fields; The method of claim 7 further comprising:

Images