User device and method thereof

Abstract

The embodiments of the present disclosure relate to a method, an apparatus, and a computer-readable medium for communication. When a terminal device transmits uplink data to a network device in an inactive state, and a resumption of a connection with the network device is performed in a cell where the transmission is performed, the terminal device performs the resumption of the connection by at least one of maintaining state variables of a PDCP entity of a UM DRB or SRB in a PDCP re-establishment, and at least one of initiating PDCP recovery for a DRB supporting transmission in an inactive state, or discarding PDCP SDUs and PDCP PDUs for an SRB supporting transmission in an inactive state. Thus, security during the SDT procedure can be enhanced.

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 an inactive state may still have a small amount of infrequent data traffic to transmit. (Registered Trademark) Until Release 16, the inactive state does not support data transmission and the terminal must resume the connection (i.e. enter the connected state) for both downlink and uplink data, which causes unnecessary power consumption and signaling overhead.

[0003] In this case, small data transmission (SDT) in the inactive state has been approved in 3GPP Release 17. Therefore, the signaling overhead can be reduced. However, so far, SDT-related technologies are still underdeveloped and further development is awaited. 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, comprising: in a terminal device, transmitting uplink data to a network device in an inactive state; and performing resumption of connection with the network device according to a determination that resumption of connection is performed in a cell where the transmission was performed, by at least one of: maintaining state variables of PDCP entities of unacknowledged mode (UM) data radio bearers (DRBs) or signaling radio bearers (SRBs) in a packet data convergence protocol (PDCP) re-establishment; and at least one of initiating PDCP recovery for DRBs supporting transmission in the inactive state or discarding PDCP service data units (SDUs) and PDCP protocol data units (PDUs) for SRBs supporting transmission in the inactive state.

[0006] In a second aspect, a communication method is provided, the method including: transmitting, in a terminal device, uplink data in an inactive state to a network device; and entering an idle state according to a determination that a resumption of a connection with the network device is required to be performed in the cell in which the transmission was performed.

[0007] In a third aspect, a communication method is provided, the method including, in a terminal device, transmitting uplink data to a network device in an inactive state, where no message rejecting the transmission is received from the network device during transmission of the uplink data in the inactive state.

[0008] In a fourth aspect, a communication method is provided, comprising: in a terminal device, transmitting uplink data to a network device in an inactive state, receiving from the network device a message to reactivate a connection with the network device, the message indicating that PDCP re-establishment is performed for radio bearers that do not support transmission in the inactive state, and performing the resumption by at least one of performing the PDCP re-establishment for the radio bearers or resuming the radio bearers that do not support transmission in the inactive state.

[0009] In a fifth aspect, a communication method is provided, the method including, in a terminal device, transmitting uplink data to a network device in an inactive state, receiving downlink data from the network device, and entering an idle state according to determining that a check of integrity protection of the downlink data has failed.

[0010] In a sixth aspect, a communication method is provided, the method including: receiving, in a network device, uplink data transmitted from a terminal device in an inactive state, where after receiving the uplink data, no message rejecting the transmission is transmitted from the network device to the terminal device.

[0011] In a seventh aspect, a communication method is provided, the method including: receiving, in a network device, uplink data transmitted from a terminal device in an inactive state; and transmitting to the terminal device a message to resume a connection between the terminal device and the network device for the uplink data, where the message indicates that PDCP re-establishment is performed for radio bearers that do not support transmission in the inactive state.

[0012] In an eighth 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, second, third, fourth or fifth aspect of the present disclosure.

[0013] In a ninth 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 or seventh aspect of the present disclosure.

[0014] In a tenth aspect, there is provided a computer readable medium having stored thereon instructions which, when executed on at least one processor, cause the at least one processor to perform a method according to the first, second, third, fourth or fifth aspect of the present disclosure.

[0015] In an eleventh aspect, there is provided a computer readable medium having stored thereon instructions which, when executed on at least one processor, cause said at least one processor to perform a method according to the sixth or seventh aspect of the present disclosure.

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

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

[0018] [Figure 1A] 1 illustrates an exemplary communications network in which some embodiments of the present disclosure may be implemented;

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

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

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

[0022] [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.

[0023] [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.

[0024] [Figure 4] FIG. 13 is a schematic diagram illustrating another process for communication during an SDT procedure in accordance with an embodiment of the present disclosure.

[0025] [Diagram 5] FIG. 13 is a schematic diagram illustrating another process for communication during an SDT procedure in accordance with an embodiment of the present disclosure.

[0026] [Figure 6] FIG. 13 is a schematic diagram illustrating another process for communication during an SDT procedure in accordance with an embodiment of the present disclosure.

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

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

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

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

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

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

[0033] [Figure 13] FIG. 2 illustrates another exemplary communication method implemented in a network device, in accordance with some embodiments of the present disclosure.

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

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

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] In some scenarios, during an SDT procedure in which the terminal device transmits uplink data in an inactive state, the terminal device may trigger another RRC restart procedure for a previous data transmission or SDT due to receiving an RRCReject message or an RRCResume message or any other element, in which case security issues arise if the RRC restart procedure is triggered in the same cell as the cell for the current SDT.

[0044] In some other scenarios, during subsequent transmissions in the SDT procedure, the terminal device cannot verify the network device by checking the integrity protection of the DL RRC message because there is no DL RRC message sent from the network device before the SDT procedure ends. If the network device is a malicious party, the terminal device may continue to receive useless DL data. In that case, security problems also occur.

[0045] For the above or other potential scenarios, the embodiments of the present disclosure provide a communication solution for handling security issues during SDT procedures. The principles and implementations of the present disclosure are described in detail below with reference to the accompanying drawings. Example of communication environment

[0046] 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 plurality 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 130 is in the cell 121 of the network device 120, and the terminal device 130 may communicate with the network device 120. The cell 121 may be referred to as a serving cell of the terminal device 130.

[0047] 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.

[0048] 1A, terminal device 110 may communicate with network device 120 over a channel, such as a wireless communication channel. Communications in communication network 100 may be carried out using any of a variety of standards, including Global System for Mobile Communications (GSM), Long Term Evolution (LTE), LTE-Evolution, LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), and the like. (Registered Trademark) The communication may conform to any suitable standard, including, but not limited to, IEEE 802.11b, Code Division Multiple Access (CDMA), Global System for Mobile Communications (GMMC), Global Access Network (GERAN), Machine Type Communications (MTC), and the like. Additionally, communication may be performed according to any generation of communication protocols now known or developed in the future. Examples of communication protocols include, but are not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, and fifth generation (5G) communication protocols.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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).

[0054] 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).

[0055] 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).

[0056] 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 not to support transmission in an inactive state. The SRB may be configured to support transmission in an inactive state. Of course, the SRB may be configured not to support transmission in an inactive state.

[0057] In the RRC layer, three types of SRBs are defined: SRB0, SRB1 and SRB2. SRB0 uses CCCH to establish 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.

[0058] 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 transmission in an inactive state. Of course, the QoS flows may be configured not to support transmission in an inactive state.

[0059] 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 small and infrequent data traffic from a radio bearer that supports transmission in an inactive state to transmit. Whether a radio bearer supports transmission in an inactive state is configured by the network device 120 or other network devices. 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 cause. 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 MsgB of a two-step RACH procedure or Msg4 of a 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.

[0060] 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 cause. Upon receiving the RRC resume request with 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.

[0061] 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. Example of security implementation when initiating another RRC resumption procedure during SDT

[0062] As mentioned above, in some scenarios, during an SDT procedure in which the terminal device transmits uplink data in an inactive state, the terminal device may trigger another RRC resumption procedure for the previous data transmission or SDT. For example, in some scenarios, the terminal device may receive an RRCReject message for the SDT procedure. In some scenarios, there may be another uplink data arriving from at least one radio bearer that does not support transmission in an inactive state. In some scenarios, the terminal device may detect that a reference signal receive power (RSRP) threshold is not met during the SDT procedure. In some scenarios, the terminal device may perform cell reselection from the source cell to the target cell, or in some cases, the terminal device may return to the source cell. In these scenarios, the terminal device may trigger another RRC resumption procedure for the previous data transmission or SDT.

[0063] However, if an RRC restart procedure is triggered in the same cell using the same UE context or security keys as a previous SDT procedure, a security issue arises since different PDCP SDUs may be encrypted using the same security key and the same COUNT value.

[0064] The state variable TX_NEXT indicates the COUNT value of the next PDCP SDU to be transmitted. In some embodiments, the initial value of the state variable is 0, except for SRBs where the state variable CONTINUOUS is set.

[0065] During the PDCP Suspend procedure, TX_NEXT is set to the initial value currently in effect after the terminal equipment enters the INACTIVE state.

[0066] During the RRC resumption procedure, PDCP re-establishment is performed, where the state variables TX_NEXT for unacknowledged mode (UM) DRBs and SRBs are set to their initial values.

[0067] In this case, if an RRC restart procedure is triggered in the same cell as for the previous SDT procedure, using the current UE context, packets transmitted during or after the RRC restart procedure by SDT or legacy data transmission will be encrypted using the same security key and COUNT value as the previously transmitted packets. However, packets transmitted during or after the RRC restart procedure may be different from the previously transmitted packets in the previous SDT procedure, which would result in different packets being encrypted using the same security key and COUNT value, which is not permissible from a security point of view.

[0068] Therefore, the embodiments of the present application provide a solution to address the security issue without resetting the state variable TX_NEXT and to avoid different packets being encrypted using the same security key and COUNT value, which will be described below in connection with embodiments 1 to 4. EMBODIMENT 1

[0069] In some scenarios, the SDT procedure may be interrupted, after which the terminal device may trigger another RRC restart procedure in the same cell in which the SDT procedure was performed. This embodiment aims to provide a solution for enhancing security in these scenarios, which is described in detail below with reference to FIG.

[0070] 3 is a schematic diagram illustrating a process 300 for communication during an SDT procedure according to an embodiment of the present disclosure. For purposes of illustration, the process 300 will be described with reference to FIG 1. The process 300 may involve a terminal device 110 and a network device 120 as shown in FIG 1.

[0071] 3, the terminal device 110 transmits uplink data to the network device 120 in an inactive state (310). That is, the terminal device 110 executes an SDT procedure. In some embodiments, the terminal device 110 may abort the SDT procedure.

[0072] For example, in some embodiments, the terminal device 110 may suspend the SDT procedure in response to receiving a message rejecting transmission (e.g., an RRCReject message). In some examples, the terminal device 110 may suspend the SDT procedure in response to another uplink data arriving from at least one radio bearer that does not support transmission in the inactive state (i.e., does not support SDT). In some examples, the terminal device 110 may suspend the SDT procedure in response to the NAS layer or the AS layer requesting a transition to an RRC Connected state. In some embodiments, the terminal device 110 may suspend the SDT procedure in response to a received signal power (e.g., RSRP) of the terminal device 110's serving cell being lower than a threshold power. In some embodiments, the terminal device 110 may suspend the SDT procedure in response to a cell reselection from a first cell to a second cell being performed. These are merely examples, and any other suitable conditions for aborting the SDT procedure are also possible.

[0073] In some embodiments, the terminal device 110 may abort the SDT procedure by at least one of discarding the current KgNB, KRRCenc, KRRCint, KUPint and KUPenc keys, resetting the MAC 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), suspending SRB1 and 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 noted that aborting the SDT procedure may include more or fewer actions.

[0074] If resumption of the connection with the network device 120 is initiated, the terminal device 110 determines (320) whether the resumption of the connection is performed in the cell in which the SDT procedure was performed. In some embodiments, the terminal device 110 may further determine whether the same UE context or the same security key is used as for the SDT procedure. If the resumption of the connection is performed in the cell, the terminal device 110 performs (330) the resumption of the connection as described in option 1 or option 2, or both. In some embodiments, if the resumption of the connection is performed in the cell and the same UE context or the same security key is used, the terminal device 110 may perform the resumption of the connection as described in option 1 or option 2, or both. Option 1

[0075] In some embodiments, the terminal device 110 may maintain (331) the state variables (i.e., TX_NEXT) of the PDCP entity of the unacknowledged mode (UM) DRB or SRB during PDCP re-establishment to restore the connection. That is, the TX_NEXT of the PDCP entity of the UM DRB or SRB is not set to an initial value during the RRC restart procedure. Thus, the first packet transmitted during the RRC restart procedure can be encrypted with a different COUNT value than the previously transmitted packet in the SDT procedure.

[0076] For example, the terminal device 110 may abort or terminate the SDT procedure by at least one of discarding the current KgNB key, KRRCenc key, KRRCint key, KUPint key and KUPenc key, resetting the MAC and releasing the default MAC cell group setting, re-establishing RLC entities for at least the radio bearers that support transmission in the inactive state (i.e., all radio bearers or only the radio bearers that support SDT), or suspending SRB1 and at least the radio bearers that support transmission in the inactive state (i.e., all radio bearers or only the radio bearers that support SDT).

[0077] When an RRC connection resumption for SDT or legacy data transmission is initiated, if it is a cell where an RRCReject was received during the previous SDT procedure (or a cell where the terminal device 110 performed a previous SDT procedure using the current UE context or the same security key), the terminal device 110 may perform the following actions in the RRC resumption procedure. For example, in the case of legacy data transmission, the network device 120 may configure the terminal device 110 to perform PDCP re-establishment for DRB and SRB2 in the RRCResume message. In the case of SDT, the RRC layer of the terminal device 110 may initiate PDCP re-establishment for DRB or SRB that supports transmission in the inactive state. When the RRC layer indicates to the PDCP entity of the radio bearer configured in the SDT to perform re-establishment, the RRC layer should further indicate to the PDCP that TX_NEXT is not initialized during re-establishment for UM DRB and SRB.

[0078] If the connection resumption is performed in another cell different from the cell in which the SDT procedure was performed, the terminal device 110 may perform PDCP re-establishment without indicating that TX_NEXT is not initialized for the UM DRBs and SRBs. In some embodiments, the terminal device 110 may perform PDCP suspension for the DRBs before PDCP re-establishment.

[0079] For example, the relevant content of the amended 3GPP specification is as follows: When higher layers request a PDCP entity re-establishment, the sending PDCP entity should: - for UM and AM DRBs, if drb-ContinueROHC is not configured in TS 38.331 [3], reset the ROHC protocol for the uplink and start in IR state in U-mode (as defined in RFC 3095 [8] and RFC 4815 [9]); - for UM DRB and AM DRB, if drb-ContinueEHC-UL is not configured in TS 38.331 [3], reset the EHC protocol for the uplink; - set TX_NEXT to its initial value for UM DRBs and SRBs, unless higher layers have indicated that the TX_NEXT value should be maintained; - for the SRB, discard all stored PDCP SDUs and PDCP PDUs; Option 2

[0080] In some embodiments, the terminal device 110 may perform the connection resumption by at least one of initiating PDCP recovery for at least DRBs supporting transmission in the inactive state (i.e., all DRBs or only DRBs supporting SDT) and / or discarding PDCP SDUs and PDCP PDUs for SRBs supporting transmission in the inactive state (also referred to herein as SDU discarding) (332). In this way, the state variable TX_NEXT is not reset during the connection resumption, thereby avoiding security issues.

[0081] For example, the terminal device 110 may abort or terminate the SDT procedure by at least one of discarding the current KgNB key, KRRCenc key, KRRCint key, KUPint key and KUPenc key, resetting the MAC and releasing the default MAC cell group setting, re-establishing RLC entities for at least the radio bearers that support transmission in the inactive state (i.e., all radio bearers or only the radio bearers that support SDT), and suspending SRB1 and at least the radio bearers that support transmission in the inactive state (i.e., all radio bearers or only the radio bearers that support SDT).

[0082] When the NAS layer or AS layer requests the terminal device 110 to resume the RRC connection for SDT or legacy data transmission, if the cell is a cell where RRCReject was received during the SDT procedure or where the terminal device 110 performed the SDT procedure using the current UE context, the terminal device 110 may perform the following actions in the RRC resume procedure. For example, in the case of legacy data transmission, the network device 120 may configure the terminal device 110 to perform PDCP recovery for DRBs and SDU discard for SRBs in the RRC resume message. In the case of SDT, the RRC layer of the terminal device 110 may initiate PDCP recovery for DRBs configured in the SDT and SDU discard for SRBs configured in the SDT.

[0083] If the connection resumption is performed in another cell different from the cell in which the SDT procedure was performed, the terminal device 110 may perform PDCP re-establishment without indicating that TX_NEXT is not initialized. In some embodiments, the terminal device 110 may perform PDCP suspension for at least DRBs that support transmission in the inactive state (i.e., all DRBs or only DRBs that support SDT) before PDCP re-establishment. EMBODIMENT 2

[0084] This embodiment aims to provide a solution for enhancing security when a message (e.g., an RRCReject message) that rejects an SDT procedure is received during an SDT procedure, in which the network device 120 is not permitted to transmit a message that rejects an SDT procedure to the terminal device 110 during the SDT procedure.

[0085] In this way, the terminal device 100 does not receive an RRCReject message and does not trigger an RRC restart procedure. As a result, security issues caused by the RRC restart procedure can be avoided. EMBODIMENT 3

[0086] In this embodiment, the terminal device 110 is not allowed to initiate another RRC resumption procedure in the same cell in which the SDT procedure was performed, as will be explained in more detail below with reference to FIG.

[0087] 4 is a schematic diagram illustrating a process 400 for communication during an SDT procedure according to an embodiment of the present disclosure. For purposes of illustration, the process 400 will be described with reference to FIG 1. The process 400 may involve a terminal device 110 and a network device 120 as shown in FIG 1.

[0088] 4, the terminal device 110 transmits uplink data to the network device 120 in an inactive state (410). That is, the terminal device 110 executes an SDT procedure.

[0089] In some embodiments, the terminal device 110 may suspend the SDT procedure. For example, in some embodiments, the terminal device 110 may suspend the SDT procedure in response to receiving a message (e.g., an RRCReject message) rejecting transmission. In some examples, the terminal device 110 may suspend the SDT procedure in response to another uplink data arriving from at least one radio bearer that does not support transmission in the inactive state. In some examples, the terminal device 110 may suspend the SDT procedure in response to the NAS layer or the AS layer requesting a transition to the RRC Connected state. In some embodiments, the terminal device 110 may suspend the SDT procedure in response to a received signal power (e.g., RSRP) of the terminal device 110's serving cell being lower than a threshold power. In some embodiments, the terminal device 110 may suspend the SDT procedure in response to a cell reselection from a first cell to a second cell being performed. These are merely examples, and any other suitable conditions for ceasing the SDT procedure are also possible.

[0090] In some embodiments, the terminal device 110 may abort the SDT procedure by at least one of discarding the current KgNB, KRRCenc, KRRCint, KUPint, and KUPenc keys, resetting the MAC 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 radio bearers supporting SDT), suspending SRB1 and at least the radio bearers supporting transmission in the inactive state (i.e., all radio bearers or only radio bearers supporting SDT), or performing a PDCP suspension for at least the DRBs supporting transmission in the inactive state (i.e., all DRBs or only DRBs supporting SDT). It should be noted that aborting the SDT procedure may include more or fewer actions.

[0091] During the SDT procedure, the terminal device 110 determines (420) whether a resumption of connection with the network device 120 is required to be performed in the cell in which the SDT procedure was performed. If a resumption of connection is required to be performed in the cell, the terminal device 110 enters (430) an idle state.

[0092] For example, if the NAS layer or AS layer of the terminal device 110 requests the RRC layer of the terminal device 110 to resume an RRC connection for SDT or legacy data transmission, the terminal device 110 may perform this action when entering the RRC IDLE state with a release cause of "RRC Resume Failed" if it is a cell in which an RRCReject was received during an SDT procedure (or a cell in which the terminal device 110 performed an SDT procedure using the current UE context).

[0093] In this way, the terminal device 100 does not trigger an RRC resumption procedure during an SDT procedure, thereby avoiding security issues. EMBODIMENT 4

[0094] In the first to third embodiments, the solution is described from the viewpoint of a terminal device. In the present embodiment, the solution is proposed from the viewpoint of a network device. In the solution, the network device indicates re-establishPDCP only for radio bearers that do not support SDT in the RRCResume message during SDT. This will be described in detail below with reference to FIG. 5.

[0095] 5 is a schematic diagram illustrating a process 500 for communication during an SDT procedure, according to an embodiment of the present disclosure. For purposes of illustration, the process 500 will be described with reference to FIG. 1. The process 500 may involve a terminal device 110 and a network device 120 as shown in FIG.

[0096] 5, the terminal device 110 transmits uplink data to the network device 120 in an inactive state (510). That is, the terminal device 110 executes an SDT procedure.

[0097] Upon receiving the uplink data, the network device 120 may indicate to the terminal device 110 to transition to a non-SDT mode. In this case, during the SDT procedure (first transmission phase or subsequent transmission phase), the network device 120 transmits (520) a message (e.g., an RRCResume message) to resume the connection with the network device 120. In some embodiments, this message indicates to perform PDCP re-establishment for radio bearers that do not support transmission in the inactive state (i.e., do not support SDT).

[0098] For example, the relevant content of the amended 3GPP specification is as follows: Re-establish the PDCP, Indicates that PDCP should be re-established. The network sets it to true whenever the security key used for this radio bearer is changed. A key change may be due to, for example, a bearer termination change, a reconfiguration with synchronization, a restoration of the RRC connection, or the first reconfiguration after re-establishment. This is also applicable for LTE procedures if NR PDCP is configured. The network shall not include this field for DRB if the bearer is configured as a DAPS bearer. When resuming the RRC connection during SDT, it is only indicated for radio bearers that do not support SDT.

[0099] Upon receiving the message, terminal device 110 performs connection resumption based on the message (530). In some embodiments, terminal device 110 may perform PDCP re-establishment only for radio bearers that do not support SDT (531). In some embodiments, terminal device 110 may resume radio bearers that do not support SDT (531).

[0100] In this way, the state variable TX_NEXT of the SDT DRB is not reset even during a connection restart, thereby avoiding security problems. Examples of subsequent in-transit security implementations

[0101] As mentioned above, during subsequent transmissions in the SDT procedure, since there is no DL RRC message sent from the network device before the SDT procedure is completed, the terminal device cannot verify the network device by checking the integrity protection of the DL RRC message. In that case, security problems will also occur. In view of this, the embodiment of the present disclosure proposes a solution to verify the network device by checking the integrity protection of the DL DRB data, which will be described in detail below with reference to FIG. 6.

[0102] 6 is a schematic diagram illustrating a process 600 for communication during an SDT procedure according to an embodiment of the present disclosure. For purposes of illustration, the process 600 will be described with reference to FIG. 1. The process 600 may involve a terminal device 110 and a network device 120 as shown in FIG.

[0103] 6, the terminal device 110 transmits uplink data to the network device 120 in an inactive state (610). That is, the terminal device 110 executes an SDT procedure.

[0104] During the SDT procedure, the terminal device 110 may receive (620) DL data from the network device 120. Accordingly, the terminal device 110 may check (630) the integrity protection of the DL data.

[0105] If the integrity protection of the downlink data fails, the terminal device 110 enters an idle state (640). In some embodiments, the terminal device 110 may store information of the failure. For example, during the SDT procedure, when an integrity protection check failure from a lower layer (e.g., PDCP) for the DRB is indicated, the RRC layer of the terminal device 110 may store connection resumption failure information. Optionally, the RRC layer may indicate the cause of the failure as an integrity check failure. For example, the terminal device 110 may perform this action when it enters the RRC IDLE state with a release cause of "RRC resumption failure".

[0106] In this way, the terminal device 110 can terminate an insecure SDT procedure upon detecting a consistency failure regarding the DRB, thereby enhancing security. Example of the method

[0107] 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 Figures 7 to 13.

[0108] 7 illustrates an example 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 of the blocks shown, and that the scope of the present disclosure is not limited in this respect.

[0109] At block 710, the terminal device 110 transmits uplink data to the network device 120 in an inactive state.

[0110] In block 720, terminal device 110 determines whether resumption of connection with the network device is performed in the cell in which the transmission was performed. If resumption of connection is performed in the cell, processing proceeds to block 730. In some embodiments, terminal device 110 may determine whether the same UE context or the same security key is used, and if the same UE context or the same security key is used, terminal device 110 may perform resumption of connection.

[0111] In block 730, the terminal device 110 performs connection resumption by at least one of maintaining state variables of the PDCP entity of the UM DRB or SRB during PDCP re-establishment and at least initiating PDCP recovery for the DRB supporting transmission in the inactive state or discarding PDCP SDUs and PDCP PDUs for the SRB supporting transmission in the inactive state.

[0112] In some embodiments, during transmission, the terminal device 110 may interrupt transmission in response to at least one of the following: receiving a message from the network device rejecting the transmission; another uplink data arrives from at least one radio bearer that does not support transmission in the inactive state; the NAS layer or AS layer of the terminal device requests a transition to a connected state; the received signal power of the serving cell of the terminal device 110 is lower than a threshold power; or cell reselection from the first cell to the second cell occurs.

[0113] In some embodiments, suspending transmission may include at least one of discarding the current KgNB, KRRCenc, KRRCint, KUPint and KUPenc keys, resetting the MAC and releasing the default MAC cell group configuration, re-establishing RLC entities for at least the radio bearers supporting transmission in the inactive state, suspending SRB1 and at least the radio bearers supporting transmission in the inactive state, or performing a PDCP suspension for at least the DRBs supporting transmission in the inactive state (i.e., all DRBs or only DRBs supporting SDT).

[0114] In some embodiments, when the connection resumption is performed in another cell different from the cell in which the transmission was performed, the terminal device 110 may perform the connection resumption by initializing state variables in the PDCP re-establishment. In some embodiments, the terminal device 110 may perform a PDCP suspension for at least the DRBs that support transmission in the inactive state before the PDCP re-establishment.

[0115] In this way, security issues caused by RRC resumption after SDT interruption can be avoided. The implementation of the method according to Fig. 7 substantially corresponds to that described in Option 1 and Option 2 of the first embodiment, so further details will not be repeated here.

[0116] 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.

[0117] As shown in FIG. 8, in block 810, the terminal device 110 transmits uplink data to the network device 120 in an inactive state.

[0118] In block 820, terminal device 110 determines whether a resumption of connection with the network device is requested to be performed in the cell in which the transmission was performed. If a resumption of connection is requested to be performed in the cell, the process proceeds to block 830. In some embodiments, terminal device 110 may determine whether the same UE context or the same security key is used, and if the same UE context or the same security key is used, terminal device 110 may enter an idle state.

[0119] In block 830, the terminal device 110 enters an idle state. In some embodiments, during transmission, the terminal device 110 may suspend transmission in response to at least one of receiving a message from the network device rejecting transmission, another uplink data arriving from at least one radio bearer that does not support transmission in the inactive state, the NAS layer or AS layer of the terminal device requesting a transition to a connected state, a received signal power of the terminal device's serving cell being lower than a threshold power, or a cell reselection from the first cell to the second cell.

[0120] In some embodiments, suspending transmission may include at least one of discarding the current KgNB, KRRCenc, KRRCint, KUPint and KUPenc keys, resetting the MAC and releasing the default MAC cell group configuration, re-establishing RLC entities for at least the radio bearers supporting transmission in the inactive state, suspending SRB1 and at least the radio bearers supporting transmission in the inactive state, or performing a PDCP suspension for the DRB.

[0121] In some embodiments, when the connection resumption is performed in another cell different from the cell in which the transmission was performed, the terminal device 110 may perform the connection resumption by initializing state variables in the PDCP re-establishment. In some embodiments, the terminal device 110 may perform a PDCP suspension for at least the DRBs that support transmission in the inactive state before the PDCP re-establishment.

[0122] In this way, security problems caused by RRC resumption after SDT interruption can also be avoided.The implementation of the method according to Fig. 8 substantially corresponds to that described in embodiment 3, so other details are not repeated here.

[0123] 9 illustrates another exemplary communication method 900 implemented in a terminal device, according to some embodiments of the present disclosure. For example, the method 900 may be performed in a terminal device 110, such as that shown in FIG. For purposes of explanation, the method 900 will be described below with reference to FIG. It should be understood that the method 900 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.

[0124] As shown in FIG. 9, in block 910, the terminal device 110 transmits uplink data to the network device 120 in an inactive state, where no message refusing transmission is received from the network device during the transmission of the uplink data in the inactive state.

[0125] In this way, the security problem caused by RRC restart upon receiving an RRC reject message can be avoided.The implementation of the method according to Fig. 9 substantially corresponds to that described in embodiment 2, so other details are not repeated here.

[0126] 10 illustrates another exemplary communication method 1000 implemented in a terminal device, according to some embodiments of the present disclosure. For example, the method 1000 may be performed in a terminal device 110 as shown in FIG. For purposes of explanation, the method 1000 will be described below with reference to FIG. It should be understood that the method 1000 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.

[0127] As shown in FIG. 10, in block 1010, the terminal device 110 transmits uplink data to the network device 120 in an inactive state.

[0128] In block 1020, the terminal device 110 receives a message from the network device 120 to resume a connection with the network device, indicating that PDCP re-establishment is to be performed for radio bearers that do not support transmission in the inactive state.

[0129] In block 1030, the terminal device 110 performs the resumption by at least one of performing PDCP re-establishment for the radio bearers or resuming the radio bearers that do not support transmission in the inactive state.

[0130] In this way, the security problem caused by RRC restart can be avoided from the network side. The implementation of the method in Fig. 10 substantially corresponds to that described in embodiment 4, so other details are not repeated here.

[0131] 11 illustrates another exemplary communication method 1100 implemented in a terminal device, according to some embodiments of the present disclosure. For example, method 1100 may be performed in a terminal device 110 as shown in FIG. For purposes of explanation, method 1100 will be described below with reference to FIG. It should be understood that method 1100 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.

[0132] 11, in block 1110, the terminal device 110 transmits uplink data to the network device 120 in an inactive state. In block 1120, the terminal device 110 receives downlink data from the network device 120.

[0133] In block 1130, terminal device 110 determines whether the downlink data integrity protection check failed. If the check failed, terminal device 110 enters an idle state. In some embodiments, terminal device 110 may store information of the failure.

[0134] In this way, security during subsequent transmissions in the SDT procedure can be enhanced. The implementation of the method according to Fig. 11 substantially corresponds to that described in relation to Fig. 6, so further details will not be repeated here.

[0135] 12 illustrates an exemplary communication method 1200 implemented in a network device according to some embodiments of the present disclosure. For example, method 1200 may be implemented in network device 120 as shown in FIG. 1. For purposes of explanation, method 1200 will be described below with reference to FIG. 1. It should be understood that method 1200 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.

[0136] As shown in FIG. 12, in block 1210, the network device 120 receives uplink data transmitted from the terminal device 110 in an inactive state, where after receiving the uplink data, no message refusing transmission is transmitted from the network device 120 to the terminal device 110.

[0137] In this way, security issues caused by RRC restart upon receiving an RRC reject message can be avoided. The implementation of the method in Fig. 12 substantially corresponds to that described in embodiment 2, so other details will not be repeated here.

[0138] 13 illustrates an example communication method 1300 implemented in a network device according to some embodiments of the present disclosure. For example, method 1300 may be implemented in network device 120 as shown in FIG. 1. For purposes of explanation, method 1300 will be described below with reference to FIG. 1. It should be understood that method 1300 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.

[0139] As shown in FIG. 13, in block 1310, the network device 120 receives uplink data transmitted from the terminal device 120 in an inactive state.

[0140] In block 1320, the network device 120 sends a message to the terminal device 110 to resume the connection between the terminal device 110 and the network device 120 for uplink data, the message indicating that PDCP re-establishment is performed for radio bearers that do not support transmission in the inactive state.

[0141] In this way, the security problem caused by RRC restart can be avoided on the network side. The implementation of the method in Fig. 13 substantially corresponds to that described in embodiment 4, so other details are not repeated here. Device implementation examples

[0142] Fig. 14 is a schematic block diagram of an apparatus 1400 suitable for implementing embodiments of the present disclosure. The apparatus 1400 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 1400 may be implemented in or as at least a part of the terminal device 110 or the network device 120 or 130.

[0143] As shown, the apparatus 1400 comprises a processor 1410, a memory 1420 coupled to the processor 1410, a suitable transmitter (TX) and receiver (RX) 1440 coupled to the processor 1410, and a communication interface coupled to the TX / RX 1440. The memory 1410 stores at least a portion of a program 1430. The TX / RX 1440 is used for bidirectional communication. The TX / RX 1440 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 a Uu interface for communication between an eNB / gNB and a terminal device.

[0144] The program 1430 is assumed to include program instructions that, when executed by an associated processor 1410, enable the device 1400 to operate according to embodiments of the present disclosure, as described herein with reference to Figures 1-13. The embodiments herein may be implemented by computer software executable by the processor 1410 of the device 1400, or by hardware, or by a combination of software and hardware. The processor 1410 may be configured to implement various embodiments of the present disclosure. Furthermore, the combination of the processor 1410 and the memory 1420 may form a processing means 1450 suitable for implementing various embodiments of the present disclosure.

[0145] The memory 1420 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 1420 is shown in the device 1400, there may be several physically different memory modules in the device 1400. The processor 1410 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 1400 may have multiple processors, for example application specific integrated circuit chips time-slaved to a clock that synchronizes the main processor.

[0146] In some embodiments, the terminal device comprises a circuit configured to transmit uplink data in the terminal device to a network device in an inactive state and, in accordance with a determination that resumption of a connection with the network device is performed in a cell in which the transmission was made, perform resumption of the connection by at least one of: maintaining state variables of a PDCP entity of a UM DRB or SRB in a PDCP re-establishment; and at least one of initiating PDCP recovery for a DRB supporting transmission in an inactive state or discarding PDCP SDUs and PDCP PDUs for an SRB supporting transmission in an inactive state.

[0147] In some embodiments, the circuitry may be further configured to determine whether the same UE context or the same security keys are used, and perform a resumption of the connection if the same UE context or the same security keys are used.

[0148] In some embodiments, the circuitry may be configured to interrupt transmission in response to at least one of the following during transmission: receiving a message from the network device rejecting the transmission; another uplink data arrives from at least one radio bearer that does not support transmission in the inactive state; the NAS layer or AS layer of the terminal device requests a transition to a connected state; the received signal power of the terminal device's serving cell is lower than a threshold power; or cell reselection occurs from the first cell to the second cell.

[0149] In some embodiments, the circuitry may be configured to suspend transmission by at least one of discarding the current KgNB, KRRCenc, KRRCint, KUPint and KUPenc keys, resetting the MAC and releasing the default MAC cell group configuration, re-establishing RLC entities for at least the radio bearers supporting transmission in the inactive state, suspending SRB1 and at least the radio bearers supporting transmission in the inactive state, or performing a PDCP suspension for the DRB.

[0150] In some embodiments, the circuitry may be further configured to perform resumption of the connection by initializing the state variables in the PDCP re-establishment according to a determination that resumption of the connection with the network device is performed in another cell different from the cell in which the transmission was performed. In some embodiments, the circuitry may be configured to perform a PDCP suspension prior to PDCP re-establishment, at least for DRBs supporting transmission in an inactive state.

[0151] In some embodiments, the 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 and enter an idle state in accordance with a determination that a resumption of a connection with the network device is requested to be performed in the cell in which the transmission was performed. In some embodiments, the circuit may be further configured to determine whether the same UE context or the same security key is used and to enter the idle state if the same UE context or the same security key is used.

[0152] In some embodiments, the circuitry may be configured to interrupt transmission in response to at least one of the following during transmission: receiving a message from a network device rejecting transmission; another uplink data arrives from at least one radio bearer that does not support transmission in an inactive state; the NAS layer or AS layer of the terminal device requests a transition to a connected state; the received signal power of the serving cell of the terminal device 110 is lower than a threshold power; or cell reselection from the first cell to the second cell occurs.

[0153] In some embodiments, the circuitry may be configured to suspend transmission by at least one of discarding the current KgNB, KRRCenc, KRRCint, KUPint and KUPenc keys, resetting the MAC and releasing the default MAC cell group configuration, re-establishing RLC entities for radio bearers supporting transmission in the inactive state, suspending SRB1 and at least the radio bearers supporting transmission in the inactive state, or performing a PDCP suspension for the DRB.

[0154] In some embodiments, the circuitry may be further configured to perform a resumption of the connection by initializing the state variables in the PDCP re-establishment according to a determination that resumption of the connection with the network device is performed in another cell different from the cell in which the transmission was performed. In some embodiments, the circuitry may be further configured to perform a PDCP suspension for at least DRBs supporting transmission in an inactive state prior to the PDCP re-establishment.

[0155] 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, where no message rejecting the transmission is received from the network device during transmission of the uplink data in the inactive state.

[0156] In some embodiments, a terminal device comprises circuitry configured to, in the terminal device, transmit uplink data to a network device in an inactive state, receive from the network device a message to resume a connection with the network device indicating that PDCP re-establishment is to be performed for a radio bearer that does not support transmission in the inactive state, and perform the resumption by at least one of performing the PDCP re-establishment for the radio bearer or resuming the radio bearer that does not support transmission in the inactive state.

[0157] In some embodiments, the terminal device comprises a circuit configured to transmit uplink data to a network device in an inactive state, receive downlink data from the network device, and enter an idle state in accordance with a determination that a check of integrity protection of the downlink data has failed. In some embodiments, the circuit may be further configured to store information of the failure.

[0158] In some embodiments, a network device comprises circuitry, the circuitry being configured in the network device to receive uplink data transmitted from a terminal device in an inactive state, where after receiving the uplink data, a message rejecting the transmission is not transmitted from the network device to the terminal device.

[0159] In some embodiments, a network device comprises a circuit configured in the network device to receive uplink data transmitted from a terminal device in an inactive state and to transmit a message to the terminal device to resume a connection between the terminal device and the network device for the uplink data, the message indicating that PDCP re-establishment is to be performed for radio bearers that do not support transmission in the inactive state.

[0160] 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.

[0161] 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-13. 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.

[0162] 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, cause the program code to implement the functions / operations specified in the flowcharts and / or block diagrams. 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.

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

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

[0165] 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 receiving a radio resource control (RRC) rejection message; means for re-establishing a Radio Link Control (RLC) entity for a radio bearer configured for the SDT procedure when the RRC reject message is received if the SDT procedure is initiated; The radio bearer includes a data radio bearer (DRB), and if the SDT procedure is initiated, means for performing a Packet Data Convergence Protocol (PDCP) pause for the DRB when the RRC reject message is received. User Equipment (UE).

2. and means for suspending a signaling radio bearer 1 (SRB1) and the radio bearers when the RRC reject message is received if the SDT procedure is initiated. The UE of claim 1.

3. When the RRC rejection message is received, the current K ｇＮＢ key, K ＲＲＣｅｎｃ key, K ＲＲＣｉｎｔ key, K ＵＰｉｎｔ Key and K ＵＰｅｎｃ further comprising means for destroying the key; 3. The UE according to claim 1 or claim 2.

4. means for resetting a Medium Access Control (MAC) and releasing a default MAC cell group configuration when the RRC reject message is received; A UE as claimed in any one of claims 1 to 3.

5. The method further comprises: a means for transmitting a Buffer Status Report (BSR) to a next generation Node B (gNB); The SDT procedure is based on the BSR. A UE as claimed in any one of claims 1 to 4.

6. A method for a user equipment (UE), comprising: Initiating a small data transmission (SDT) procedure; receiving a radio resource control (RRC) rejection message; and if the SDT procedure is initiated, when the RRC reject message is received, re-establishing a Radio Link Control (RLC) entity for a radio bearer configured for the SDT procedure; The radio bearer includes a data radio bearer (DRB), If the SDT procedure is initiated, performing a Packet Data Convergence Protocol (PDCP) pause for the DRB when the RRC reject message is received. method.

7. and if the SDT procedure is initiated, suspending a Signaling Radio Bearer 1 (SRB1) and the radio bearers when the RRC reject message is received. The method according to claim 6.

8. When the RRC rejection message is received, the current K ｇＮＢ key, K ＲＲＣｅｎｃ key, K ＲＲＣｉｎｔ key, K ＵＰｉｎｔ Key and K ＵＰｅｎｃ further comprising destroying the key; The method according to claim 6 or claim 7.

9. resetting a medium access control (MAC) and releasing a default MAC cell group configuration when receiving the RRC reject message. The method according to any one of claims 6 to 8.

10. The method further includes transmitting a Buffer Status Report (BSR) to a next generation Node B (gNB), The SDT procedure is based on the BSR. The method according to any one of claims 6 to 9.

Images