Method performed in terminal device, method performed in network device, terminal device and network device

Abstract

To provide a communication method, a terminal device and a computer-readable medium for properly performing communication in an inactive state.SOLUTION: In a wireless communication system, a method implemented on a terminal device comprises: initiating a radio resource control (RRC) connection release procedure during small data transmission (SDT) performed with a network device; and disabling indication of arrival of non-small data transmission to the network device during the RRC connection release procedure. In this way, the RRC connection release procedure may be completed without any disturbance, and the state between the terminal device and the network device may be consistent.SELECTED DRAWING: Figure 4A

Description

[Technical Field]

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

[0002] In current wireless communication systems, the power consumption of terminal devices is a focus. To reduce the power consumption of terminal devices, it has been proposed that terminal devices can be set to several power saving modes / states (such as an inactive state). For terminal devices in an inactive state, it has been proposed to suspend normal data transmission. Generally, when a terminal device in an inactive state needs to perform normal transmission with a network device, the terminal device must resume connection with the network device (i.e., wake up and change to a connected state).

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

[0004] In general, exemplary embodiments of the present disclosure provide a communication solution for inactive devices. To the extent that any embodiments fall within the scope of the claims, they should be construed as examples useful for understanding various embodiments of the present disclosure. [Means for solving the problem]

[0005] In a first aspect, a communication method is provided, the communication method including: initiating, in a terminal device, a radio resource control connection release procedure while the terminal device is performing small data transmission with a network device; and disabling, while performing the radio resource control connection release procedure, indicating to the network device data arrival from a radio bearer that does not support transmission in an inactive state.

[0006] In a second aspect, a communication method is provided, the communication method including, in a terminal device, initiating a radio resource control connection release procedure while the terminal device is performing small data transmission with a network device, terminating the radio resource control connection release procedure, and indicating to the network device data arrival from a radio bearer that does not support transmission in an inactive state.

[0007] In a third aspect, a communication method is provided, the communication method including: receiving, at a terminal device, a message from the network device, the message comprising a plurality of security elements for deriving a plurality of security keys, respectively, for communicating between the terminal device and the network device when the terminal device is in an unconnected state; and performing a radio resource control connection resumption procedure with the network device when the terminal device is in the unconnected state based at least in part on the message.

[0008] In a fourth aspect, a communication method is provided, the communication method including: transmitting, at a network device, a message to the terminal device, the message comprising a plurality of security elements for respectively deriving a plurality of security keys for communication between the terminal device and the network device when the terminal device is in an unconnected state; and performing a radio resource control connection resumption procedure with the terminal device based at least in part on the message when the terminal device is in the unconnected state.

[0009] In a fifth aspect, a communication method is provided, the communication method including: receiving, at a terminal device, from a network device, information regarding a maximum number of security element-based security key generation, the security keys being used for communication between the terminal device and the network device when the terminal device is in an unconnected state; and performing a radio resource control connection resumption procedure with the network device when the terminal device is in the unconnected state based at least in part on the maximum number.

[0010] In a sixth aspect, a communication method is provided, the communication method including: transmitting, in a network device, information regarding a maximum number of security element-based security key generation to a terminal device, the security keys being used for communication between the terminal device and the network device when the terminal device is in a disconnected state; and performing a radio resource control connection resumption procedure with the terminal device based at least in part on the maximum number.

[0011] In a seventh aspect, there is provided a communication method, comprising: in a terminal device, performing a non-connected state transmission with a first cell of a network device by encrypting data with a first sequence number; discarding stored data of a radio bearer configured for the non-connected state transmission after detecting a preset event for triggering a stop of the non-connected state transmission; and performing a radio resource control connection resumption procedure, wherein the radio resource control connection resumption procedure includes performing the radio resource control connection resumption procedure with the first cell by encrypting data with an uninitialized first sequence number or performing the radio resource control connection resumption procedure with a second cell of the network device by encrypting data with an initialized first sequence number.

[0012] In an eighth aspect, there is provided a communication method, the communication method including, in a terminal device, detecting a preset event while the terminal device is performing a non-connection state transmission with a network device, and transitioning to an idle state.

[0013] In a ninth aspect, there is provided a communication method, the communication method including: performing, in a terminal device, small data transmission with a first cell to which a first frequency is set; and reducing a possibility of switching to a second cell to which a second frequency different from the first frequency is set when performing the small data transmission with the first cell.

[0014] In a tenth aspect, there is provided a communication method, comprising: receiving, in a terminal device, packet data convergence protocol configurations for radio bearers of the terminal device from a network device; and initiating a resumption procedure of a radio resource control connection for small data transmission, wherein the resumption procedure of the radio resource control connection for small data transmission comprises applying default packet data convergence protocol configurations for radio bearers configured to carry radio resource control messages and not restoring packet data convergence protocol configurations to the radio bearers; and restoring packet data convergence protocol configurations for radio bearers configured for small data transmission, excluding the radio bearers configured to carry radio resource control messages.

[0015] In an eleventh aspect, there is provided a communication method, comprising: receiving, in a terminal device, packet data convergence protocol configurations for radio bearers of the terminal device from a network device; and initiating a resumption procedure of radio resource control for small data transmission, wherein the resumption procedure of radio resource control for small data transmission comprises restoring packet data convergence protocol configurations for radio bearers configured for the small data transmission, including radio bearers configured to carry radio resource control messages.

[0016] In a twelfth aspect, there is provided a communication method, the communication method including: generating, in a network device, packet data convergence protocol configurations for radio bearers; and transmitting the packet data convergence protocol configurations to a terminal device, wherein the radio bearers include a radio bearer configured to carry radio resource control messages, and if the radio bearer is configured for small data transmission, a default packet data convergence protocol configuration is configured for the radio bearer.

[0017] In a thirteenth aspect, there is provided a terminal device comprising: a processor; and a memory, coupled to the processor, having stored thereon instructions, which, when executed by the processor, cause the terminal device to perform a method according to the first aspect.

[0018] In a fourteenth aspect, there is provided a terminal device comprising: a processor; and a memory, coupled to the processor, having stored thereon instructions, which, when executed by the processor, cause the terminal device to perform a method according to the second aspect.

[0019] In a fifteenth aspect, there is provided a terminal device comprising: a processor; and a memory, coupled to the processor, having stored thereon instructions, which, when executed by the processor, cause the terminal device to perform a method according to the third aspect.

[0020] In a sixteenth aspect, there is provided a network device comprising: a processor; and a memory, coupled to the processor, having instructions stored thereon, the instructions, when executed by the processor, causing the network device to perform a method according to the fourth aspect.

[0021] In a seventeenth aspect, there is provided a terminal device, the terminal device comprising: a processor; and a memory, coupled to the processor, having stored thereon instructions, the instructions, when executed by the processor, causing the terminal device to perform a method according to the fifth aspect.

[0022] In an eighteenth aspect, there is provided a network device comprising: a processor; and a memory, coupled to the processor, having instructions stored thereon, the instructions, when executed by the processor, causing the network device to perform a method according to the sixth aspect.

[0023] In a nineteenth aspect, there is provided a terminal device, the terminal device comprising: a processor; and a memory, coupled to the processor, having stored thereon instructions, the instructions, when executed by the processor, causing the terminal device to perform a method according to the seventh aspect.

[0024] In a twentieth aspect, there is provided a terminal device, the terminal device comprising: a processor; and a memory, coupled to the processor, having stored thereon instructions, the instructions, when executed by the processor, causing the terminal device to perform a method according to the eighth aspect.

[0025] In a twenty-first aspect, there is provided a terminal device, the terminal device comprising: a processor; and a memory, coupled to the processor, having instructions stored thereon, the instructions, when executed by the processor, causing the terminal device to perform a method according to the ninth aspect.

[0026] In a twenty-second aspect, there is provided a terminal device, the terminal device comprising: a processor; and a memory, coupled to the processor, having stored thereon instructions, the instructions, when executed by the processor, causing the terminal device to perform a method according to the tenth aspect.

[0027] In a twenty-third aspect, there is provided a terminal device, the terminal device comprising: a processor; and a memory, coupled to the processor, having stored thereon instructions, the instructions, when executed by the processor, causing the terminal device to perform a method according to the eleventh aspect.

[0028] In a 24th aspect, there is provided a network device comprising: a processor; and a memory, coupled to the processor, having instructions stored thereon, the instructions, when executed by the processor, causing the network device to perform a method according to the 12th aspect.

[0029] In a twenty-fifth aspect, there is provided a computer-readable medium having stored thereon instructions that, when executed on at least one processor, cause the at least one processor to perform a method according to any of the first to twelfth aspects above.

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

[0031] The above and other objects, features and advantages of the present disclosure will become more apparent through a more detailed description of several exemplary embodiments of the present disclosure in the accompanying drawings. [Figure 1A] 1 shows the conventional signaling flow of SDT. [Figure 1B] 1 shows the conventional signaling flow of SDT. [Figure 2] 1 illustrates an exemplary communication environment in which exemplary embodiments of the present disclosure may be practiced. [Figure 3] 1 illustrates a signaling flow for handling data arrival from a radio bearer that does not support transmission in an inactive state, according to some embodiments of the present disclosure. [Figure 4A] 1 illustrates an example method for handling data arrival from a radio bearer that does not support transmission in an inactive state, according to some embodiments of the present disclosure. [Figure 4B]1 illustrates an example method for handling data arrival from a radio bearer that does not support transmission in an inactive state, according to some embodiments of the present disclosure. [Figure 5A] 1 illustrates an example signaling flow for avoiding keystream reuse, in accordance with some embodiments of the present disclosure. [Figure 5B] 1 illustrates an example signaling flow for avoiding keystream reuse, in accordance with some embodiments of the present disclosure. [Figure 6A] 1 illustrates an exemplary method for avoiding keystream reuse, according to some embodiments of the present disclosure. [Figure 6B] 1 illustrates an exemplary method for avoiding keystream reuse, according to some embodiments of the present disclosure. [Figure 7A] 10 illustrates another exemplary method for avoiding keystream reuse, in accordance with some embodiments of the present disclosure. [Figure 7B] 10 illustrates another exemplary method for avoiding keystream reuse, in accordance with some embodiments of the present disclosure. [Figure 8] 10 illustrates another example signaling flow for avoiding keystream reuse, in accordance with some embodiments of the present disclosure. [Figure 9] 10 illustrates another exemplary method for avoiding keystream reuse, in accordance with some embodiments of the present disclosure. [Figure 10] 10 illustrates yet another exemplary method for avoiding keystream reuse, in accordance with some embodiments of the present disclosure. [Figure 11] 10 illustrates yet another exemplary method for avoiding keystream reuse, in accordance with some embodiments of the present disclosure. [Figure 12] 1 illustrates an example method for cell reselection, in accordance with some embodiments of the present disclosure. [Figure 13] 1 illustrates an exemplary method for handling PDCP configuration, according to some embodiments of the present disclosure. [Figure 14]1 shows a schematic block diagram of an apparatus suitable for practicing exemplary embodiments of the present disclosure. Throughout the drawings, the same or similar reference numbers represent the same or similar elements. DETAILED DESCRIPTION OF THE INVENTION

[0032] The principles of the present disclosure will be described with reference to several exemplary embodiments. It should be understood that these embodiments are set forth for illustrative purposes only to aid those skilled in the art in understanding and practicing the present disclosure, and are not intended to imply any limitation on the scope of the present disclosure. The embodiments described herein can be implemented in a variety of ways other than those described below.

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

[0034] References in this disclosure to "one embodiment," "embodiment," "exemplary embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but not all embodiments need include such a particular feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is believed to be within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments, whether or not explicitly described.

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

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

[0037] In some instances, values, procedures, or devices are referred to as "optimum," "lowest," "highest," "minimum," "maximum," etc. It is understood that such descriptions are intended to indicate choices among multiple functional alternatives used, and that such choices are not necessarily better, smaller, higher, or more preferred than other choices.

[0038] As used herein, the term "network device" refers to a device capable of providing or hosting a cell or coverage area over which terminal devices can communicate. Examples of network devices include, but are not limited to, a Node B (NB or NB), an Evolved Node B (eNodeB or eNB), a New Radio Access Node B (gNB), a Remote Radio Unit (RRU), a Radio Head (RH), a Remote Radio Head (RRH), a low-power node such as a femto node or a pico node, a satellite network device, an aircraft network device, etc. For purposes of discussion, some exemplary embodiments will be described below with reference to an eNB as an example of a network device.

[0039] As used herein, the term "terminal" refers to any end device capable of wireless communication. By way of example and not limitation, a terminal may also be referred to as a communication device, a user equipment (UE), a subscriber equipment (SS), a portable subscriber equipment, a mobile station (MS), or an access terminal (AT). Terminal devices include, but are not limited to, mobile phones, mobile phones, smartphones, Voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, imaging terminal devices such as digital cameras, gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, wireless customer premises equipment (CPE), Internet of Things (IoT) devices, wearables such as watches, head-mounted displays (HMD), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, etc. In the following description, the terms "terminal device," "communications device," "terminal," "user equipment," and "UE" may be used interchangeably.

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

[0041] As used herein, the term "small data transmission data" or "SDT data" refers to data that can be transmitted by a terminal device in an inactive or idle state. Generally, "small data transmission data" or "SDT data" is transmitted on radio bearers (including signaling radio bearers (SRBs)) and data radio bearers (DRBs) that are configured to support SDT or that are brought about / triggered by services / functions / applications configured for SDT.

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

[0043] As used herein, the term "disconnected transmission" refers to any transmission that is supported / enabled to occur when the terminal device is not in a connected state, including but not limited to SDT, early data transmission (EDT), and preconfigured uplink resource (PUR).

[0044] As used herein, the term "circuit" may refer to a hardware circuit and / or a combination of a hardware circuit and software. For example, a circuit may be a combination of analog and / or digital hardware circuitry with software / firmware. As a further example, a circuit may be any portion of a hardware processor with software, such as a digital signal processor, software, and memory that cooperate to perform various functions in a device, such as a terminal device or network device. In yet another example, a circuit may be a hardware circuit and / or processor, such as a microprocessor or portion of a microprocessor, that requires software / firmware for operation but may be absent when not required for operation. As used herein, the term circuit also encompasses a simple hardware circuit or processor, or portion of a hardware circuit or processor, and its (or their) accompanying software and / or firmware implementation.

[0045] While the functions described herein may be performed in fixed and / or wireless network nodes in various exemplary embodiments, in other exemplary embodiments, the functions may be implemented in a user terminal device (such as a mobile phone, tablet computer, laptop computer, desktop computer, mobile IoT device, or fixed IoT device). Such a user terminal device may include corresponding functions, as appropriate, such as those described in connection with the fixed and / or wireless network nodes. The user terminal device may be a user terminal and / or a control device, such as a chipset or processor, configured to control the user terminal when attached to the user terminal. Examples of such functions include a bootstrap server function and / or a home subscriber server. Such functions may be implemented in the user terminal device by providing the user terminal device with software configured for execution by the user terminal device in terms of these functions / nodes.

[0046] As described above, in order to reduce the power consumption of a terminal device in wireless communication, the terminal device may be set to several power-saving states or modes. For example, a 3GPP work item has proposed and defined a radio resource control (RRC) inactive state. Also, as described above, in order to further reduce power consumption, a 3GPP work item has proposed a solution that enables SDT of a terminal device in an RRC inactive state. In this way, a terminal device in an inactive RRC state may remain in the inactive RRC state while enabling data transmission.

[0047] Generally, SDT is a procedure that allows data transmission while remaining in an RRC inactive state (i.e., without transitioning to an RRC connected state). Furthermore, SDT is enabled on a radio bearer basis and is initiated by a terminal device only when the amount of UL data to be transmitted across all radio bearers configured for SDT is less than a data amount threshold (e.g., a set amount) and the measured reference signal received power (RSRP) in the cell is greater than a set threshold. Due to the data amount requirements, SDT has been proposed to be applied to several specific application scenarios. Some exemplary application scenarios of SDT for smart terminal devices may include, but are not limited to, the following: ● Traffic / data / packets from instant messaging services (e.g., WhatsApp, QQ, WeChat, MSN, etc.) ● Heartbeat / keep-alive traffic / data / packets from some applications (e.g. instant applications, email applications, etc.) ● Push notifications from various applications

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

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

[0050] In the case of RA-based SDT, data for SDT is transmitted using random access procedures including a two-step-based random access procedure (referred to as two-step RACH) and a four-step-based random access procedure (referred to as four-step RACH). More specifically, the initial UL data may be transmitted by an inactive terminal device to a network device via message A of the two-step RACH procedure or message 3 of the four-step RACH procedure. In the case of CG-based SDT, the initial UL data is transmitted on CG resources.

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

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

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

[0054] The terminal device then transmits the UL data and the additional BSR to the network device (170), and the network device responds by transmitting the UL grant of the dynamic grant and additional DL data (if any) to the terminal device (175). The terminal device then transmits the UL data to the network device (180). In the example of FIG. 1B, the terminal device does not transmit a BSR to the network device because there is no data remaining to transmit. Therefore, considering there is no BSR, the network device may transmit an RRCRelease message and additional DL data to the terminal device (185).

[0055] Although some discussions / agreements have been made on the SDT, there are still some outstanding issues that need to be discussed and addressed. For example, it is desirable to propose and discuss technical details on how to handle data arrival from RBs that do not support inactive transmissions during the RRC connection release procedure, how to avoid keystream reuse, how to avoid cell reselection during the SDT, and how to restore PDCP settings (especially for SRB1s and radio bearers with SDT configured).

[0056] In the following, the SDT procedure is discussed in an exemplary scenario in which the terminal device is in an inactive state. However, such a specific exemplary scenario should not be considered as limiting the present disclosure. It should be understood that the exemplary embodiments discussed herein may also be applied to a scenario in which the terminal device is in an idle state if SDT is supported / enabled in the idle state.

[0057] In the following, the SDT procedure is used as an example of a transmission procedure to explain some exemplary embodiments of the present disclosure, although it should be understood that the exemplary embodiments of the present disclosure are equally applicable to other disconnected transmissions (such as EDT and PUR).

[0058] In the following, when the non-connected transmission is EDT or PUR, the transition to idle state operation refers to the transition to idle state without RRC suspension, and when the non-connected transmission is SDT, the transition to idle state operation refers to the transition to RRC idle state.

[0059] In the following, the terms "RBs that do not support transmission in an inactive state" and "RBs that are not configured for SDT" (and similar expressions) may be used interchangeably, while the terms "RBs that support transmission in an inactive state" and "RBs that are configured for SDT" (and similar expressions) may be used interchangeably.

[0060] Hereinafter, the phrases "running an SDT," "during an SDT," and "the timer for an SDT is running" (and similar expressions) may be used interchangeably.

[0061] Furthermore, hereinafter, the terms "Packet Data Convergence Protocol (PDCP) packet," "PDCP data," "PDCP protocol data unit (PDU)," and "PDCP service data unit (SDU)" (and similar expressions) may be used interchangeably when describing data being processed.

[0062] Also, hereinafter, the terms "Radio Link Control (RLC) packet," "RLC data," "RLC PDU," and "RLC SDU" (and similar expressions) may be used interchangeably when describing data being processed.

[0063] Furthermore, operations discussed below in several specific examples / cases / embodiments are for illustrative purposes only and do not imply any limitation. That is, such operations do not necessarily refer to the same example / case / embodiment. Furthermore, when a particular example / case / embodiment is described in connection with one example / case / embodiment, it is believed to be within the knowledge of one skilled in the art to affect such operations in connection with other embodiments, whether or not explicitly described. Additionally, although examples / cases / embodiments are discussed separately, it should be understood that such examples / cases / embodiments may be combined in any suitable manner.

[0064] Example Environment FIG. 2 illustrates an exemplary communication environment 200 in which exemplary embodiments of the present disclosure can be implemented. The communication environment 200 includes a terminal device 210 and network devices 220-1 and 220-2 that provide services to the terminal device 210. In the following text, the network devices 220-1 and 220-2 are collectively referred to as network devices 220 or individually referred to as network devices 220. Furthermore, the network devices 220 may provide multiple serving areas to the terminal device 210. In the example of FIG. 2, the network device 220-1 provides cells 230-1, 230-2, and 230-3, and the network device 220-2 provides cell 230-4. In the following text, the cells 230-1 to 230-4 are collectively referred to as serving cells 230 or individually referred to as serving cells 230.

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

[0066] In the example of FIG. 2 , the terminal device 210 may be in different states (e.g., connected, inactive, idle, etc.). When the terminal device 210 is in the connected state, the terminal device 210 can receive data transmissions from all radio bearers. Furthermore, in some embodiments, when the terminal device 210 is in the idle state, the terminal device is generally not allowed to perform any data transmissions except for certain scenarios (e.g., EDT or PUR). Also, when the terminal device 210 is in the inactive state, while SDT is supported, data transmissions for which SDT is not configured are not allowed during SDT procedures. Furthermore, the terminal device 210 in the inactive / idle state may transition to the connected state by resuming / establishing an RRC connection with the network device 220. Such a transition procedure may be initiated by either the terminal device 210 or the network device 220.

[0067] Furthermore, in the example of Figure 2, the terminal device 210 may move over time. As shown in Figure 2, the terminal device 210 is located in different locations over time. During movement, the terminal device 210 may communicate with different cells 230 or different network devices 220, which may be implemented by a cell reselection procedure, a handover procedure, or the like.

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

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

[0070] An exemplary process showing data arrival from an RB that does not support transmission in the inactive state As mentioned above, due to the data volume requirements, it is proposed that SDT be applied only to some specific application scenarios / RBs. Furthermore, if the terminal device determines that it needs to transmit data from an RB that does not support inactive transmission (e.g., non-SDT data) to the network device during SDT, the terminal device should indicate to the network device the arrival of data from the RB that does not support inactive transmission. This is because data from an RB that does not support inactive transmission (e.g., non-SDT data) may contain important / urgent data or information. Furthermore, during SDT, the network device may transmit an RRC release message to the terminal device. For example, the network device may decide to terminate the current SDT procedure.

[0071] Currently, when the terminal device receives an RRC release message, the terminal device does not immediately perform the RRC connection release procedure. Instead, the terminal device waits for a certain period of time (e.g., 60 ms) or optionally waits if the terminal device's lower layers indicate that reception of the RRC release message has been successfully acknowledged. Specifically, it has been agreed that when the terminal device receives an RRC release message, the terminal device should delay some operations for no more than 60 ms or optionally if the terminal device's lower layers indicate that reception of the RRC release message has been successfully acknowledged. Delayed operations include, for example, stopping timer T380 if running, stopping timer T320 if running, stopping timer T316 if running, clearing information (if any) contained in the VarRLF-Report, stopping timer T350 if running, and other specified operations.

[0072] In general, the behavior of the terminal device in different scenarios should be consistent or similar. To align the behavior of the terminal device in the SDT scenario and the connected transmission scenario, it is expected that the above-mentioned RRC connection release procedure in the connected transmission scenario can be reused in the SDT scenario. If so, for the SDT scenario, the RRC layer / entity of the terminal device selectively postpones / delays the above-mentioned operation for 60 ms from the moment the RRC release message is received or if the lower layer indicates that the reception of the RRC release message has been successfully confirmed. Therefore, during the SDT, even if the terminal device receives an RRC release message, the terminal device remains in the SDT state for a certain period of time. During this period, the terminal device may receive data (e.g., non-SDT data) from RBs that do not support inactive transmission. So far, there has been no discussion on how to indicate the arrival of data from RBs that do not support inactive transmission during this period (i.e., while the terminal device is performing the RRC connection release procedure when performing SDT with the network device).

[0073] The following text discusses in detail several exemplary embodiments to address this concern.

[0074] Exemplary Embodiments for Disabling Indication of Data Arrival from RBs That Do Not Support Transmission in an Inactive State According to some example embodiments of the present disclosure, a solution for communication is provided in which terminal device 210 does not indicate data arrival from an RB that does not support inactive transmission while performing an RRC connection release procedure (e.g., after reinstating an RRC release message during the SDT). In other words, if data from an RB that does not support inactive transmission arrives during the SDT and an RRC release message has not yet been received, terminal device 210 may indicate to network device 220 that data arrival from the RB that does not support inactive transmission. In this way, the RRC connection release procedure can be completed without interruption, and a state between terminal device 210 and network device 220 can be stabilized.

[0075] Terminal device 210 may indicate to network device 220 in any suitable manner that data has arrived from an RB that does not support transmission in an inactive state. As one example, terminal device 210 transmits a dedicated control channel (DCCH) message (SRB1) to network device 220. As another example, terminal device 210 may transmit a MAC CE to network device 220. As a further example, terminal device 210 initiates an RRC connection resumption procedure with network device 220. During the RRC connection resumption procedure, terminal device 210 may transmit a common control channel (CCCH) message (SRB0) to network device 220.

[0076] Please refer now to Figure 3, which illustrates a signaling flow 300 for handling data arrival from an RB that does not support transmission in an inactive state, in accordance with some embodiments of the present disclosure. For purposes of discussion, the signaling flow 300 will be described with reference to Figure 2. The signaling flow 300 may involve a network device 220 and a terminal device 210.

[0077] During operation, terminal device 210 performs an SDT with network device 220 (310). During the SDT, terminal device 210 initiates an RRC connection release procedure. In some exemplary embodiments, when terminal device 210 receives an RRC release message, terminal device 210 postpones / delays related operations (e.g., stopping a corresponding timer) for a period 330. Period 330 may be a predefined / configured value (e.g., 60 ms). Alternatively, period 330 may refer to the time from when the RRC release message is received to when lower layers of terminal device 210 indicate that the receipt of the RRC release message has been successfully acknowledged. As shown in FIG. 3, during this period 330, terminal device 210 determines / detects (340) data arrival from RBs that do not support inactive transmission.

[0078] In some exemplary embodiments, terminal device 210 disables indicating to network device 220 data arrival from RBs that do not support transmission in an inactive state while performing an RRC release procedure after receiving an RRC release message.

[0079] Furthermore, in some exemplary embodiments, terminal device 210 may start a timer in response to the start of an SDT and immediately stop the timer in response to receiving an RRC release message from network device 220. In this case, in a case where terminal device 210 determines that there is data to be transmitted to network device 220 from an RB that does not support inactive transmission (e.g., non-SDT data), terminal device 210 may determine whether the timer is running. If the timer is running (meaning terminal device 210 has not yet received an RRC release message) and data arrives from an RB that does not support inactive transmission, terminal device 210 indicates to network device 220 the arrival of data from an RB that does not support inactive transmission. Otherwise, if the timer is not running (meaning terminal device 210 has received an RRC release message), terminal device 210 disables indicating to network device 220 the arrival of data from an RB that does not support inactive transmission.

[0080] In summary, in some exemplary embodiments, if the SDT timer is running (meaning that an RRC release message has not yet been received) and data arrives from an RB that does not support transmission in the inactive state, terminal device 210 may indicate the arrival of data from the RB that does not support transmission in the inactive state to network device 220. Otherwise, terminal device 210 will not indicate the arrival of data from the RB that does not support transmission in the inactive state to network device 220.

[0081] Furthermore, in some exemplary embodiments, terminal device 210 indicates (350-1) to network device 220 the arrival of data from RBs that do not support transmission in an inactive state in response to completion of the RRC release procedure. In this manner, the arrival of data from RBs that do not support transmission in an inactive state can be indicated to network device 220 without significant delay.

[0082] 4A illustrates a flowchart of an exemplary method 400 according to some embodiments of the present disclosure. For example, the method 400 may be implemented in a terminal device 210 such as that illustrated in FIG.

[0083] In block 410 , terminal device 210 initiates an RRC release procedure while terminal device 210 is performing SDT with network device 220 .

[0084] In block 420, the terminal device 210 disables indicating to the network device 220 data arrival from RBs that do not support transmission in an inactive state while performing the RRC connection release procedure.

[0085] In some example embodiments, terminal device 210 indicates to network device 220 data arrival from an RB that does not support inactive transmission in response to a timer running, where the timer starts in response to the start of an SDT and stops in response to receiving an RRC release message from network device 220.

[0086] In some exemplary embodiments, terminal device 210 enables indicating to network device 220 data arrival from RBs that do not support transmission in an inactive state upon completion of the RRC connection release procedure.

[0087] In some exemplary embodiments, terminal device 210 comprises circuitry configured to initiate an RRC release procedure while terminal device 210 is performing an SDT with network device 220. The circuitry is further configured to disable indicating to network device 220 data arrival from RBs that do not support transmission in an inactive state while performing the RRC connection release procedure.

[0088] In some exemplary embodiments, the circuitry is further configured to indicate to network device 220 data arrival from an RB that does not support inactive transmission in response to a timer being running, where the timer starts in response to a start of an SDT and stops in response to receipt of an RRC release message from network device 220.

[0089] In some exemplary embodiments, the circuitry is further configured to enable, upon completion of the RRC connection release procedure, indicating to network device 220 data arrival from an RB that does not support transmission in an inactive state.

[0090] Exemplary Embodiments for Indicating Data Arrival from an RB That Does Not Support Transmission in an Inactive State Alternatively, according to some example embodiments of the present disclosure, a solution for communication is provided. In this solution, terminal device 210 may abandon / terminate the RRC connection release procedure and immediately indicate to network device 220 the arrival of data from an RB that does not support transmission in the inactive state. In summary, if data from an RB that does not support transmission in the inactive state arrives after receiving an RRC release message, terminal device 210 abandons the RRC connection release procedure and indicates to network device 220 the arrival of data from an RB that does not support transmission in the inactive state. In this way, the arrival of data from an RB that does not support transmission in the inactive state can be indicated to network device 220 without delay.

[0091] Referring again to Fig. 3, while performing the RRC connection release procedure, the terminal device 210 determines that there is data (such as non-SDT data) from an RB that does not support transmission in an inactive state to be transmitted to the network device 220. The terminal device 210 terminates the RRC connection release procedure (350-2-1) and indicates to the network device 220 the arrival of data from the RB that does not support transmission in an inactive state (350-2-2).

[0092] 4B illustrates a flowchart of an exemplary method 450 according to some embodiments of the present disclosure. For example, the method 450 may be implemented in the terminal device 210 shown in FIG.

[0093] In block 460 , terminal device 210 initiates an RRC release procedure while terminal device 210 is performing SDT with network device 220 .

[0094] In block 470, the terminal device 210 ends the RRC connection release procedure.

[0095] In block 480, terminal device 210 indicates to network device 220 the arrival of data from an RB that does not support transmission in the inactive state.

[0096] In some exemplary embodiments, terminal device 210 comprises circuitry configured to initiate an RRC release procedure while terminal device 210 is performing an SDT with network device 220. The circuitry is further configured to terminate the RRC connection release procedure. The circuitry is also configured to indicate to network device 220 data arrival from an RB that does not support transmission in an inactive state.

[0097] Security Key Example Process During SDT, the terminal may terminate / abort the SDT procedure due to several events, including but not limited to: ● Event 1) Reselection of a cell ● Event 2) SDT failure detection timer expires ● Event 3) The maximum number of retransmissions is reached in RLC. Event 4) An RRC reject message is received during the SDT. Event 5) Upper layer aborts the connection resumption procedure. Event 6) Radio Access Network (RAN) paging is received during the SDT. ● Event 7) Non-SDT data / signal arrives at the terminal device side ● Event 8) RSRP requirements are not met during the SDT. Event 9) A lower layer (such as the Media Access Control (MAC) layer) indicates the termination of the SDT, for example because of a lack of suitable resources.

[0098] If an SDT abort occurs, the terminal device performs at least one of the following procedures: Destroys the current application stratum (AS) security context, including the KgNB, KRRCenc, KRRCint, KUPint, and KUPenc keys. Reset MAC and release default MAC cell group settings ● Suspend SRB1 and RBs with SDT set, and re-establish RLC for SRB1 and other RBs with SDT set.

[0099] Furthermore, after SDT cancellation, the terminal device remains in an inactive state and may initiate further RRC resumption procedures in the same cell. However, as mentioned above, the current AS security context has been discarded during the SDT cancellation procedure. Even if it is assumed that the AS security context may remain and that the terminal device may later initiate further RRC resumption procedures using the same UE context (e.g., AS security context), reusing the same AS security context during further RRC resumption procedures is still undesirable and unexpectable, as different packets in the next RRC connection resumption procedure may be encrypted using the same security keys and the same count value.

[0100] One possible solution proposes that the serving gNB provide a new security element (such as NextHopChainingCount, herein referred to as NCC) at the start of every SDT to generate new security keys and an Inactive Radio Network Temporary Identifier (I-RNTI) for future use. However, this solution is not feasible if the SDT is aborted before receiving the first downlink transmission.

[0101] Another possible solution suggests that the network device should provide a new NCC / RNTI immediately after an abrupt termination of an SDT session, but since the network device may not know if an SDT abort has occurred, the network device cannot provide new security elements / keys immediately.

[0102] Exemplary Embodiments for Providing Multiple Security Elements According to some example embodiments of the present disclosure, a communication solution is provided in which new key information (e.g., multiple security elements for respectively deriving multiple security keys for communication between terminal device 210 and network device 220 when terminal device 210 is in a disconnected state) may be provided to terminal device 210. In this way, after SDT termination, terminal device 210 may initiate at least one further RRC connection resumption procedure with the new security keys. As a result, the above-mentioned key stream reuse problem can be avoided, thereby ensuring secure communication with network device 220.

[0103] Please refer now to Figure 5A, which illustrates a signaling flow 500 for avoiding keystream reuse in accordance with some embodiments of the present disclosure. For purposes of discussion, the signaling flow 500 will be described with reference to Figure 2. The signaling flow 500 may involve a network device 220 and a terminal device 210.

[0104] During operation, terminal device 210 receives (505) from network device 220 a message comprising a plurality of security elements for respectively deriving a plurality of security keys for communicating between terminal device 210 and network device 220 when terminal device 210 is in an unconnected state.

[0105] In some exemplary embodiments, the message comprising multiple security elements is an RRC release message comprising configuration for a disconnected transmission. One example of a disconnected transmission is an SDT. Another example of a disconnected transmission is an EDT. Yet another example of a disconnected transmission is a PUR.

[0106] When terminal device 210 is in a disconnected state, multiple security elements may cause terminal device 210 to perform an RRC connection resumption procedure with network device 220. Further, in some exemplary embodiments, the RRC connection resumption procedure may be associated with at least one disconnected state transmission.

[0107] In some exemplary embodiments, terminal device 210 performs a first RRC connection resumption procedure associated with an unconnected state transmission with network device 220 using a first security key derived from a first security element of the plurality of security elements (510). Furthermore, terminal device 210 discontinues the unconnected state transmission in response to detecting a pre-configured event for triggering discontinuation of the unconnected state transmission (515). After discontinuing the unconnected state transmission, terminal device 210 may initiate a further RRC connection resumption procedure. Specifically, terminal device 210 performs a second RRC connection resumption procedure with network device 220 using a second security key derived from a second security element of the plurality of security elements (520).

[0108] Furthermore, in some exemplary embodiments, any of the RRC connection resumption procedures, except for the initial RRC connection resumption, may be a normal RRC connection resumption procedure that does not carry data for a disconnected transmission, or an RRC connection resumption procedure for a disconnected transmission. For example, terminal device 210 may send an RRC connection resumption request to network device 220 without any data being sent with the RRC connection resumption request.

[0109] Furthermore, to reduce the effort of network device 220, terminal device 210 can indicate to network device 220 information regarding the security element being used. For example, in some exemplary embodiments, terminal device 210 transmits a field to network device 220 indicating the security element being used. Furthermore, in some exemplary embodiments, the field is a MAC CE.

[0110] In some exemplary embodiments, new key information (such as security elements) is configured by the network device 220 via an RRC release message with suspendconfig. For example, the network device 220 (such as a gNB) configures a list of security settings (i.e., a list of security elements, such as NextHopChainingCount) in the RRC release message that configures the SDT for the terminal device 210. The list consists of N security settings, which can be used for up to N RRC connection resumption procedures after discontinuing the SDT.

[0111] As a specific example, the multiple security elements may be multiple NCCs, and information about the security elements used may be represented as the number / index of the NCC used and may be sent to the network device 220 together with the RRC resumption request, for example, by using a MAC CE.

[0112] In some exemplary embodiments, terminal device 210 sequentially uses different security keys derived from different security elements of the plurality of security elements to perform different RRC connection resumption procedures with network device 220. This means that terminal device 210 may initiate multiple RRC connection resumption procedures with different security keys.

[0113] 5A, the second RRC connection resumption procedure is associated with non-connected state transmissions. The terminal device 210 then suspends the non-connected state transmissions in response to detecting a pre-configured event for triggering the suspension of the non-connected state transmissions (525). The terminal device 210 then initiates a third RRC connection resumption procedure with the network device 220 (530).

[0114] Furthermore, in some exemplary embodiments, if no security element (i.e., NCC) is used, when a pre-configured event occurs to trigger the cessation of disconnected transmissions, terminal device 210 performs an operation to transition to an idle state (such as an RRC idle state). In some exemplary embodiments, in the case where the disconnected transmissions are EDT or PUR, the transition to idle operation refers to a transition to idle without an RRC pause.

[0115] In some exemplary embodiments, if no security elements are available to derive security keys, terminal device 210 may transition to an idle state upon detecting a pre-configured event. Specifically, in FIG. 5A, terminal device 210 ceases transmitting the disconnected state (535) and transitions to an idle state (540).

[0116] Additionally, in some exemplary embodiments, network device 220 may provide multiple cells. Furthermore, multiple cells may be grouped together as a serving group, and cells within the same serving group may share the same security context. When terminal device 210 in an inactive state moves between cells within the same group, terminal device 210 does not need to transition to a connected state. In such a scenario, different RRC connection resumption procedures described above may occur in different cells.

[0117] See Figure 5B, which illustrates an example for providing multiple security elements. For purposes of discussion, signaling flow 550 will be described with reference to Figure 2. Signaling flow 550 may involve terminal device 210, cell 230-1, and cell 230-2. In the following text, cell 230-1 will also be referred to as first cell 230-1, and cell 230-2 will also be referred to as second cell 230-2.

[0118] During operation, terminal device 210 receives from network device 220 a message comprising a plurality of security elements for respectively deriving a plurality of security keys for communicating between the terminal device and network device 220 when the terminal device is in an unconnected state (555). For example, terminal device 210 may receive an RRC release message having a suspendConfig, where the suspendConfig may comprise a plurality of NCCs (including a base NCC (referred to as NCC0) and a list of additional NCCs (referred to as NCC1, NCC2, ...)).

[0119] The multiple security elements allow terminal device 210 to perform an RRC connection resumption procedure with either cell 230-1 or 230-2. In the example of FIG. 5B, terminal device 210 performs a first RRC connection resumption procedure associated with a disconnected transmission with first cell 230-1 using a first security key derived from a first security element of the multiple security elements (560). For example, terminal device 210 initiates an SDT procedure with first cell 230-1 using NCC0.

[0120] Subsequently, the terminal device 210 stops transmitting in the disconnected state in response to detecting a preset event for triggering the stopping of the disconnected state transmission (565).

[0121] Also, after ceasing the disconnected transmissions, terminal device 210 may initiate a further RRC connection resumption procedure with one of cells 230 (first cell 230-1, second cell 230-2, etc.). In the example of FIG. 5B, terminal device 210 performs a second RRC connection resumption procedure associated with the further disconnected transmissions with first cell 230-1 using a second security key derived from a second security element of the plurality of security elements (570). For example, terminal device 210 initiates the RRC connection resumption procedure with first cell 230-1 using a new security key generated by NCC1.

[0122] The terminal device 210 then ceases further disconnected transmissions in response to detecting a pre-configured event for triggering the cessation of disconnected transmissions, for example due to cell reselection (575).

[0123] If there are security elements available from which to derive a security key, the terminal device 210 may initiate 580 a third RRC connection resumption procedure with one of the cells 230 (first cell 230-1, second cell 230-2, etc.). In the example of FIG. 5B, the terminal device 210 performs 580 a third RRC connection resumption procedure associated with a disconnected state transmission with the second cell 230-2 using a third security key derived from a third security element of the plurality of security elements. For example, the terminal device 210 initiates 580 an RRC connection resumption procedure with the second cell 230-2 using a new security key generated by NCC2.

[0124] In some exemplary embodiments, if no security element is available from which to derive a security key, terminal device 210 transitions to an idle state upon detecting a pre-configured event. Specifically, in FIG. 5B, terminal device 210 ceases transmitting the disconnected state (585) and transitions to an idle state (590).

[0125] 6A illustrates a flowchart of an exemplary method 600 according to some embodiments of the present disclosure. For example, the method 600 may be implemented in the terminal device 210 shown in FIG.

[0126] In block 610, the terminal device 210 receives a message from the network device 220 comprising a plurality of security elements for respectively deriving a plurality of security keys for communication between the terminal device 210 and the network device 220 when the terminal device is in an unconnected state.

[0127] At block 620, when terminal device 210 is in an unconnected state, terminal device 210 performs an RRC connection resumption procedure with network device 220 based at least in part on the message.

[0128] In some exemplary embodiments, the message is an RRC release message comprising settings for non-connected transmission.

[0129] In some exemplary embodiments, terminal device 210 performs a first RRC connection resumption procedure associated with the disconnected state transmission with network device 220 using a first security key derived from a first security element of the plurality of security elements, and suspends the disconnected state transmission in response to detecting a pre-configured event for triggering suspension of the disconnected state transmission. Furthermore, terminal device 210 performs a second RRC connection resumption procedure with network device 220 using a second security key derived from a second security element of the plurality of security elements.

[0130] In some exemplary embodiments, if no security elements are available to derive security keys, terminal device 210 transitions to an idle state upon detecting a pre-configured event.

[0131] In some exemplary embodiments, terminal device 210 transmits a field to network device 220 indicating the security element being used.

[0132] In some exemplary embodiments, the field is a MAC CE.

[0133] In some demonstrative embodiments, terminal device 210 comprises circuitry configured to receive from network device 220 a message comprising a plurality of security elements for deriving a plurality of security keys, respectively, for communicating between terminal device 210 and network device 220 when terminal device 210 is in an unconnected state. The circuitry is further configured to perform an RRC connection resumption procedure with network device 220 based at least in part on the message when terminal device 210 is in an unconnected state.

[0134] In some exemplary embodiments, the message is an RRC release message comprising settings for non-connected transmission.

[0135] In some exemplary embodiments, the circuitry is further configured to perform a first RRC connection resumption procedure with network device 220 associated with the disconnected state transmission using a first security key derived from a first security element of the plurality of security elements, and in response to detecting a predetermined event for triggering the discontinuation of the disconnected state transmission, discontinue the disconnected state transmission, and perform a second RRC connection resumption procedure with network device 220 using a second security key derived from a second security element of the plurality of security elements.

[0136] In some exemplary embodiments, the circuitry is further configured to transition to an idle state upon detecting a pre-configured event if no security element is available from which to derive the security key.

[0137] In some exemplary embodiments, the circuitry is further configured to transmit a field to the network device 220 indicating the security element being used.

[0138] In some exemplary embodiments, the field is a MAC CE.

[0139] 6B illustrates a flowchart of an exemplary method 650 according to some embodiments of the present disclosure. For example, the method 650 may be implemented in the network device 220 as illustrated in FIG.

[0140] In block 660, the network device 220 sends a message to the terminal device 210 comprising a plurality of security elements for respectively deriving a plurality of security keys for communication between the terminal device 210 and the network device 220 when the terminal device 210 is in a disconnected state.

[0141] At block 670, when terminal device 210 is in an unconnected state, network device 220 performs an RRC connection resumption procedure with terminal device 210 based at least in part on the message.

[0142] In some exemplary embodiments, the message is an RRC release message comprising settings for non-connected transmission.

[0143] In some exemplary embodiments, network device 220 receives a field from terminal device 210 indicating the security element being used.

[0144] In some exemplary embodiments, the field is a MAC CE.

[0145] In some demonstrative embodiments, network device 220 comprises circuitry configured to send to terminal device 210 a message comprising a plurality of security elements for deriving a plurality of security keys, respectively, for communicating between terminal device 210 and network device 220 when terminal device 210 is in an unconnected state. The circuitry is further configured to perform an RRC connection resumption procedure with terminal device 210 based at least in part on the message when terminal device 210 is in the unconnected state.

[0146] In some exemplary embodiments, the message is an RRC release message comprising settings for non-connected transmission.

[0147] In some exemplary embodiments, the circuitry is further configured to receive a field from terminal device 210 indicating the security element being used.

[0148] In some exemplary embodiments, the field is a MAC CE.

[0149] Exemplary Embodiments for Illustrating Maximum Number of Security Key Generations According to some example embodiments of the present disclosure, a communication solution is provided. The solution provides a maximum number of security key generation based on security elements for terminal device 210. Thus, terminal device 210 may use the same security elements to generate different security keys, such as by using horizontal key derivation. In this way, after SDT termination, terminal device 210 may initiate a further RRC connection resumption procedure with new security keys. As a result, the key stream reuse problem described above can be avoided, thereby ensuring secure communication with network device 220.

[0150] In summary, terminal device 210 uses horizontal key derivation for recovery mechanisms (such as an RRC connection resumption procedure) after an abrupt termination of an SDT session (such as an SDT abort). Terminal device 210 uses horizontal key derivation to initiate an RRC connection resumption procedure after an SDT abort.

[0151] In some exemplary embodiments, horizontal key derivation can be performed X times (i.e., a maximum number), which also means that X SDT aborts can be performed. The maximum number (X) can be a predetermined number. In some exemplary embodiments, when the number of SDT aborts reaches the maximum number, terminal device 210 performs an operation to transition to an idle state (e.g., an RRC idle state) when a predefined event occurs to trigger the SDT abort.

[0152] 5, the details are explained. During operation, the terminal device 210 receives information regarding the maximum number of security key generation based on the security element (505). The security keys are used for communication between the terminal device 210 and the network device 220 when the terminal device 210 is in a disconnected state from the network device 220.

[0153] In some exemplary embodiments, the maximum number is transmitted via a message comprising a setting for a disconnected transmission. One example of a disconnected transmission is an SDT. Another example of a disconnected transmission is an EDT. Yet another example of a disconnected transmission is a PUR.

[0154] In some exemplary embodiments, when terminal device 210 is in an unconnected state, terminal device 210 performs an RRC connection resumption procedure with network device 220 based at least in part on the maximum number.

[0155] Furthermore, in some exemplary embodiments, during the RRC connection resumption procedure and / or subsequent data transmission, the data may use new security keys, but message authentication for integrity (such as MAC-I) may still be calculated based on the stored keys.

[0156] In some exemplary embodiments, terminal device 210 performs a first RRC resumption procedure associated with non-connected state transmissions with network device 220 using a first security key generated based on the security elements (510). Furthermore, terminal device 210 halts the non-connected state transmissions in response to detecting a pre-configured event for triggering the halt of the non-connected state transmissions (515). After the halt of the non-connected state transmissions, the terminal device may initiate a further RRC connection resumption procedure. Specifically, terminal device 210 performs a second RRC connection resumption procedure with network device 220 using a second security key generated based on the security elements (520). The second security key is different from the first security key.

[0157] Furthermore, to reduce the burden on network device 220, terminal device 210 can indicate to network device 220 information regarding the number of security element-based security key generations. For example, in some exemplary embodiments, terminal device 210 transmits to network device 220 a field indicating the number of security element-based security key generations. Furthermore, in some exemplary embodiments, the field is a MAC CE. As an example, terminal device 210 transmits the number of horizontal key updates to network device 220 together with an RRC resume request message, for example, by a MAC CE.

[0158] 5A, the second RRC connection resumption procedure is associated with non-connected state transmission, and the terminal device 210 suspends the non-connected state transmission in response to detecting a pre-configured event for triggering suspension of the non-connected state transmission (525).

[0159] Furthermore, in some exemplary embodiments, if the number of security key generations based on the security elements falls below the maximum number, terminal device 210 may further initiate another RRC connection resumption procedure. As shown in FIG. 5A, terminal device 210 initiates a third RRC connection resumption procedure with network device 220 (530).

[0160] Also, if the number of security keys generated based on security elements reaches the maximum number, the terminal device 210 transitions to an idle state upon detecting a preset event. Specifically, in Figure 5A, the terminal device 210 stops transmitting the disconnected state (535) and transitions to an idle state (540).

[0161] Furthermore, the above process may be applied to scenarios where the network device 220 is capable of providing multiple cells 230. A specific exemplary process will be discussed with reference to Figure 5B.

[0162] During operation, terminal device 210 receives information regarding the maximum number (555). For example, terminal device 210 receives an RRC release message with suspendConfig. In particular, the RRC release message comprises an NCC and a maximum number (X).

[0163] 5B, terminal device 210 performs a first RRC connection resumption procedure associated with a disconnected transmission with first cell 230-1 using a first security key generated based on a security element (i.e., an NCC) (560). For example, terminal device 210 initiates an SDT procedure with first cell 230-1 using the NCC.

[0164] Subsequently, the terminal device 210 stops transmitting in the disconnected state in response to detecting a preset event for triggering the stopping of the disconnected state transmission (565).

[0165] Also, after ceasing the disconnected transmissions, terminal device 210 may initiate a further RRC connection resumption procedure with one of cells 230 (first cell 230-1, second cell 230-2, etc.). In the example of Figure 5B, terminal device 210 performs 570 a second RRC connection resumption procedure associated with the disconnected transmissions with first cell 230-1 using a second security key.

[0166] For example, terminal device 210 initiates a second RRC connection resumption procedure with first cell 230-1 using a new key generated by horizontal key derivation.

[0167] The terminal device 210 then ceases (575) the disconnected transmission in response to detecting a pre-configured event for triggering the cessation of disconnected transmission, for example due to cell reselection.

[0168] If the number of security key generations based on the security elements falls below the maximum number, terminal device 210 may initiate 580 a third RRC connection resumption procedure with one of cells 230 (first cell 230-1, second cell 230-2, etc.). In the example of FIG. 5B, terminal device 210 performs 580 a third RRC connection resumption procedure associated with a disconnected state transmission with second cell 230-2 using the third security key.

[0169] For example, terminal device 210 initiates a third RRC connection resumption procedure with second cell 230-2 using a new key generated by horizontal key derivation.

[0170] In some exemplary embodiments, if the maximum number of security keys based on the security elements has been generated, terminal device 210 transitions to an idle state upon detecting a preset event. Specifically, in FIG. 5B, terminal device 210 ceases transmitting the disconnected state (585) and transitions to an idle state (590).

[0171] 7A illustrates a flowchart of an exemplary method 700 according to some embodiments of the present disclosure. For example, the method 700 may be implemented in the terminal device 210 shown in FIG.

[0172] In block 710, the terminal device 210 receives information regarding the maximum number of security key generation based on the security element from the network device 220. The security keys are used for communication between the terminal device 210 and the network device 220 when the terminal device 210 is in an unconnected state.

[0173] At block 720, when terminal device 210 is in an unconnected state, terminal device 210 performs an RRC connection resumption procedure with network device 220 based at least in part on the maximum number.

[0174] In some exemplary embodiments, the maximum number is transmitted via a message comprising settings for non-connection transmission.

[0175] In some exemplary embodiments, terminal device 210 performs a first RRC connection resumption procedure associated with the disconnected state transmission with network device 220 using a first security key generated based on the security elements. Furthermore, terminal device 210 discontinues the disconnected state transmission in response to detecting a pre-configured event for triggering the discontinuation of the disconnected state transmission. Terminal device 210 then performs a second RRC connection resumption procedure with network device 220 using a second security key generated based on the security elements.

[0176] In some exemplary embodiments, if the number of security key generation based on the security element reaches a maximum number, the terminal device 210 transitions to an idle state upon detecting a preset event.

[0177] In some exemplary embodiments, terminal device 210 transmits to network device 220 a field indicating the number of security key generations based on the security element.

[0178] In some exemplary embodiments, the field is a MAC CE.

[0179] In some demonstrative embodiments, terminal device 210 comprises circuitry configured to receive information regarding a maximum number of security element-based security key generation from network device 220. The security keys are used for communications between terminal device 210 and network device 220 when terminal device 210 is in an unconnected state. The circuitry is further configured to perform an RRC connection resumption procedure with network device 220 when terminal device 210 is in an unconnected state based at least in part on the maximum number.

[0180] In some exemplary embodiments, the maximum number is transmitted via a message comprising settings for non-connection transmission.

[0181] In some demonstrative embodiments, the circuitry is further configured to perform a first RRC connection resumption procedure with network device 220 associated with the disconnected state transmission using a first security key generated based on the security element, and in response to detecting a predetermined event for triggering the discontinuation of the disconnected state transmission, discontinue the disconnected state transmission, and perform a second RRC connection resumption procedure with network device 220 using a second security key generated based on the security element.

[0182] In some exemplary embodiments, the circuitry is further configured to transition to an idle state upon detecting a preset event when a maximum number of security keys based on the security element has been generated.

[0183] In some exemplary embodiments, the circuitry is further configured to transmit to the network device 220 a field indicating the number of security key generations based on the security element.

[0184] In some exemplary embodiments, the field is a MAC CE.

[0185] 7B illustrates a flowchart of an exemplary method 750 according to some embodiments of the present disclosure. For example, the method 750 may be implemented in the network device 220 shown in FIG.

[0186] In block 760, the network device 220 transmits information regarding the maximum number of security key generation based on the security element to the terminal device 210. The security keys are used for communication between the terminal device 210 and the network device 220 when the terminal device 210 is in a disconnected state.

[0187] At block 770, the network device 220 performs an RRC connection resumption procedure with the terminal device 210 based at least in part on the maximum number.

[0188] In some exemplary embodiments, the maximum number is transmitted via a message comprising settings for non-connection transmission.

[0189] In some exemplary embodiments, network device 220 receives from terminal device 210 a field indicating the number of security key generations based on the security element.

[0190] In some exemplary embodiments, the field is a MAC CE.

[0191] In some demonstrative embodiments, network device 220 comprises circuitry configured to transmit information regarding a maximum number of security element-based security key generation to terminal device 210. The security keys are used for communications between terminal device 210 and network device 220 when terminal device 210 is in an unconnected state. The circuitry is further configured to perform an RRC connection resumption procedure with terminal device 210 based at least in part on the maximum number.

[0192] In some exemplary embodiments, the maximum number is transmitted via a message comprising settings for non-connection transmission.

[0193] In some exemplary embodiments, the circuitry is further configured to receive from terminal device 210 a field indicating the number of security key generations based on the security element.

[0194] In some exemplary embodiments, the field is a MAC CE.

[0195] Exemplary Embodiments for Discarding Stored Data Furthermore, in addition to deriving new security keys from multiple security elements or based on the same security element, such as by horizontal key derivation, a sequence number (such as TX_NEXT / COUNT) is also used to ensure secure communication between the terminal device 210 and the network device 220. Furthermore, the terminal device 210 must also discard stored data (such as PDCP PDUs) that are configured for transmission in a disconnected state, the detailed operation of which will be discussed below.

[0196] According to some example embodiments of the present disclosure, a method for communication is provided, in which a terminal device 210 performs a disconnected transmission with a first cell (e.g., 230-1) of a network device 220 by encrypting data with a first sequence number. The method further includes discarding stored data of a radio bearer configured for the disconnected transmission after detecting a pre-configured event for triggering a halt to the disconnected transmission. Thereafter, the terminal device 210 performs an RRC connection resumption procedure with the first cell or the second cell using an uninitialized first sequence number or an initialized first sequence number.

[0197] In this way, communication between the terminal device 210 and the network device 220 is ensured without any additional operations on the network device 220 .

[0198] Please refer now to Figure 8, which illustrates a signaling flow 800 for avoiding keystream reuse in accordance with some embodiments of the present disclosure. For purposes of discussion, the signaling flow 800 will be described with reference to Figure 2. The signaling flow 800 may involve terminal device 210, cell 230-1, and cell 230-2. In the following text, cell 230-1 will also be referred to as first cell 230-1, and cell 230-2 will also be referred to as second cell 230-2.

[0199] During operation, the terminal device 210 performs 810 an unconnected transmission with the first cell 230-1 of the network device 220 by encrypting data with a first sequence number. One example of an unconnected transmission is SDT. Another example of an unconnected transmission is EDT. Yet another example of an unconnected transmission is PUR.

[0200] Additionally, in some exemplary embodiments, the first sequence number may be a unique number of the PDCP PDU, for example, TX_NEXT / COUNT.

[0201] After detecting a preset event for triggering the discontinuation of disconnected state transmission, the terminal device 210 discards the stored data in the RB configured for disconnected state transmission (820). After the discontinuation, the terminal device 210 may perform an RRC connection resumption procedure. Specifically, the terminal device 210 performs an RRC connection resumption procedure with the first cell 230-1 by encrypting data with an uninitialized first sequence number (830-1). In this way, because the first sequence number is not initialized, different sequence numbers will be used during the RRC connection resumption procedure even if the terminal device 210 continues communication with the same cell 230-1.

[0202] Alternatively, the terminal device 210 performs the RRC connection resumption procedure with the second cell 230-2 by encrypting data using the initialized first sequence number. In this way, since the RRC connection resumption procedure is performed in the second cell 230-2 different from the first cell 230-1, even if the first sequence number is initialized, data can also be encrypted uniquely because the cells are different.

[0203] As a specific example, when the RRC connection resumption procedure is executed in a cell where SDT suspension has occurred, the terminal device 210 discards the data (PDCP PDU, etc.) stored in the RB configured for SDT, and continues to use the sequence number (TX_NEXT / COUNT value, etc.) of the RB where SDT is configured. Also, when the RRC connection resumption procedure is executed in a cell different from the cell where SDT suspension has occurred, the terminal device 210 discards the data (PDCP PDU, etc.) stored in the RB configured for SDT, and the sequence number (TX_NEXT / COUNT value, etc.) of the RB where SDT is configured is initialized.

[0204] As can be seen, the above process involves at least two operations: discarding stored data and passing the value of the first sequence number (e.g., initializing or not initializing the first sequence number). Currently, the above two operations are implemented using different procedures. Specifically, a typical PDCP suspension procedure involves discarding PDCP PDUs and initializing TX_NEXT / COUNT for all DRBs. Meanwhile, a typical PDCP re-establishment procedure involves initializing TX_NEXT / COUNT for RLC unacknowledged mode (UM) and SRBs. Therefore, the current procedure does not allow the above two operations to be performed simultaneously.

[0205] According to the present disclosure, further improvements are proposed to perform the above two operations.

[0206] In some exemplary embodiments, terminal device 210 (e.g., a PDCP entity of terminal device 210) performs a PDCP suspension procedure to discontinue disconnected state transmissions. During the PDCP suspension procedure, terminal device 210 discards stored data (e.g., PDCP PDUs) in RBs configured for disconnected state transmissions and receives an instruction from the RRC layer of terminal device 210 to disable initialization of the first sequence number. Furthermore, terminal device 210 performs a PDCP re-establishment procedure while performing an RRC connection re-establishment procedure. During the PDCP re-establishment procedure, terminal device 210 disables initialization of the first sequence number when the RRC connection re-establishment procedure is performed with first cell 230-1 and initializes the first sequence number when the RRC connection re-establishment procedure is performed with second cell 230-2. In this way, the above two operations are performed in different procedures.

[0207] Alternatively, the above two operations may be implemented in a different manner. Specifically, in some exemplary embodiments, the terminal device 210 performs a PDCP re-establishment procedure while performing an RRC connection re-establishment procedure. During the PDCP re-establishment procedure, the terminal device 210 discards stored data (such as PDCP PDUs) in RBs configured for transmission in a disconnected state. Furthermore, during the PDCP re-establishment procedure, the terminal device 210 disables initialization of the first sequence number when the RRC connection re-establishment procedure is performed with the first cell 230-1, and initializes the first sequence number when the RRC connection re-establishment procedure is performed with the second cell 230-2.

[0208] To provide a better understanding of the above process, two specific exemplary embodiments are given below.

[0209] In a first specific exemplary embodiment, when transmission in the disconnected state is stopped, the terminal device 210 performs the following procedure. Specifically, the terminal device 210 discards stored data (such as PDCP PDUs) for RBs for which SDT is configured. For example, the terminal device discards the stored data by performing a PDCP suspension procedure, and indicates continuity of the sequence number for PDCP (i.e., the TX_NEXT / COUNT value) when performing PDCP suspension for RBs for which SDT is configured. Furthermore, when the terminal device 210 initiates an RRC connection resumption procedure in a cell where the terminal device 210 previously performed an SDT procedure using the current UE inactive AS context, the terminal device 210 must continue the sequence number for RBs for which SDT is configured (i.e., the TX_NEXT / COUNT value). For example, during the RRC resumption procedure, the RRC layer must indicate continuity of the sequence number for PDCP (i.e., the TX_NEXT / COUNT value) when performing PDCP reestablishment for RBs for which SDT is configured. Otherwise (i.e., when the terminal device 210 initiates the RRC connection resumption procedure in a cell different from the cell in which the terminal device 210 performed the SDT procedure), in the RRC connection resumption procedure, the terminal device 210 must initialize the sequence numbers (i.e., TX_NEXT / COUNT values) of all RBs for which SDT is configured, including RLC acknowledged mode (AM) DRBs, RLC UM DRBs, and SRBs. For example, during the RRC connection resumption procedure, the RRC layer must indicate that it will initialize the sequence numbers (i.e., TX_NEXT / COUNT values) of RLC AM RBs for which SDT is configured when performing the PDCP re-establishment procedure.

[0210] In a second specific exemplary embodiment, when the terminal device 210 initiates an RRC connection resumption procedure in a cell where the terminal device 210 previously performed an SDT procedure using the current UE inactive AS context, the terminal device 210 must discard PDCP PDUs for RBs for which SDT is configured. For example, the terminal device 210 performs a PDCP suspension procedure and indicates continuation of the sequence number for PDCP (i.e., the TX_NEXT / COUNT value) when performing the PDCP suspension procedure for the RBs for which SDT is configured. In another example, the terminal device 210 indicates that stored data (such as PDCP PDUs) will be discarded when performing a PDCP re-establishment procedure for the RBs for which SDT is configured. Furthermore, a continued sequence number (i.e., the TX_NEXT / COUNT value) must be used for the RBs for which SDT is configured. For example, when performing PDCP re-establishment during the RRC connection resumption procedure, the RRC layer must indicate continuation of the sequence number for PDCP (i.e., the TX_NEXT / COUNT value) when performing the PDCP re-establishment procedure for the RBs for which SDT is configured. Otherwise (i.e., when the terminal device 210 initiates the RRC connection resumption procedure in a cell different from the cell in which the terminal device 210 performed the SDT procedure), the terminal device 210 may discard data (PDCP PDUs, etc.) stored in RBs in which SDT is set, and initialize the sequence numbers (i.e., TX_NEXT / COUNT values) of all RBs in which SDT is set. For example, the terminal device 210 performs a PDCP suspension procedure without indicating continuation of the sequence numbers (i.e., TX_NEXT / COUNT values), and then performs a PDCP re-establishment procedure without indicating continuation of the sequence numbers (i.e., TX_NEXT / COUNT values). In another example, the terminal device 210 performs a PDCP re-establishment procedure with instructions to discard PDUs and initialize the sequence numbers (i.e., TX_NEXT / COUNT values) of RLC AM DRBs in which SDT is set.

[0211] In some exemplary embodiments, when a higher layer requests the suspension of a PDCP entity, the transmitting PDCP entity must set TX_NEXT to its initial value and discard all stored PDCP PDUs unless the higher layer indicates that TX_NEXT should continue. Also, in some exemplary embodiments, when a higher layer requests the suspension of a PDCP entity, the receiving PDCP entity must stop and reset t-Reordering if it is active, perform header recovery, and then transmit all stored PDCP SDUs to the higher layer in ascending order of their associated COUNT values, and set RX_NEXT and RX_DELIV to their initial values.

[0212] In some exemplary embodiments, when upper layers request re-establishment of a PDCP entity, the sending PDCP entity must do at least one of the following: 1) for UM and AM DRBs, if drb-ContinueROHC is not set, reset the Robust Header Compression (ROHC) protocol for the uplink and start in the Initialization and Refresh (IR) state in UM; 2) for UM and AM DRBs, if drb-ContinueEHC-UL is not set, reset the EHC protocol for the uplink; 3) for UM DRBs and SRBs, if TX_NEXT continuation is not indicated by upper layers, set TX_NEXT to its initial value; and 4) for AM DRBs, if TX_NEXT initialization is indicated by upper layers, set TX_NEXT to its initial value.

[0213] 5) For SRB, discard all stored PDCP SDUs and PDCP PDUs. For DRB, discard all stored PDCP PDUs if PDU discard is indicated by the upper layer.

[0214] 9 illustrates a flowchart of an example method 900 according to some embodiments of the present disclosure. For example, the method 900 may be implemented in the terminal device 210 shown in FIG.

[0215] In block 910, the terminal device 210 performs a disconnected transmission with the first cell 230-1 of the network device 220 by encrypting data with the first sequence number.

[0216] In block 920, the terminal device 210 discards the stored data in the RB configured for disconnected transmission after detecting a pre-configured event for triggering the discontinuation of disconnected transmission.

[0217] In block 930, the terminal device 210 performs an RRC resumption procedure. The RRC resumption procedure comprises performing an RRC connection resumption procedure with the first cell 230-1 by encrypting data with an uninitialized first sequence number, or performing an RRC connection resumption procedure with the second cell 230-2 of the network device 220 by encrypting data with an initialized first sequence number.

[0218] In some exemplary embodiments, in response to detecting the predetermined event, terminal device 210 performs a PDCP suspension procedure in a PDCP entity. The PDCP suspension procedure comprises discarding stored data for RBs configured for disconnected transmission and receiving an instruction from the RRC layer of the terminal device to disable initialization of a first sequence number. Furthermore, during the RRC connection resumption procedure, terminal device 210 performs a PDCP re-establishment procedure. The PDCP re-establishment procedure comprises disabling initialization of a first sequence number if the RRC connection resumption procedure is performed with the first cell 230-1 and initializing the first sequence number if the RRC connection resumption procedure is performed with the second cell 230-2.

[0219] In some exemplary embodiments, while performing the RRC connection resumption procedure, terminal device 210 performs a PDCP re-establishment procedure comprising discarding stored PDCP PDUs. During the PDCP re-establishment procedure, terminal device 210 disables initialization of the first sequence number if the RRC connection resumption procedure is performed with first cell 230-1 and initializes the first sequence number if the RRC connection resumption procedure is performed with second cell 230-2.

[0220] In some exemplary embodiments, terminal device 210 comprises circuitry configured to perform a disconnected transmission with a first cell 230-1 of network device 220 by encrypting data with a first sequence number. The circuitry is further configured to discard stored data in the RB configured for the disconnected transmission after detecting a pre-configured event for triggering discontinuation of the disconnected transmission. The circuitry is also configured to perform an RRC resumption procedure, the RRC resumption procedure comprising performing an RRC connection resumption procedure with first cell 230-1 by encrypting data with an uninitialized first sequence number or performing an RRC connection resumption procedure with a second cell 230-2 of network device 220 by encrypting data with an initialized first sequence number.

[0221] In some exemplary embodiments, in response to detecting the predetermined event, the circuitry is further configured to perform a PDCP suspension procedure at the PDCP entity. The PDCP suspension procedure comprises discarding stored data for RBs configured for disconnected transmission and receiving an instruction from the RRC layer of the terminal device 210 to disable initialization of the first sequence number. Furthermore, during an RRC connection resumption procedure, the circuitry is further configured to perform a PDCP re-establishment procedure. The PDCP re-establishment procedure comprises disabling initialization of the first sequence number if the RRC connection resumption procedure is performed with the first cell 230-1 and initializing the first sequence number if the RRC connection resumption procedure is performed with the second cell 230-2.

[0222] In some exemplary embodiments, while performing the RRC connection resumption procedure, the circuitry is further configured to perform a PDCP re-establishment procedure comprising discarding the stored PDCP PDUs. During the PDCP re-establishment procedure, the circuitry is further configured to disable initialization of the first sequence number if the RRC connection resumption procedure is performed with the first cell 230-1 and to initialize the first sequence number if the RRC connection resumption procedure is performed with the second cell 230-2.

[0223] Exemplary Embodiments for Transition to Idle State In addition to the exemplary process described above, terminal device 210 may transition to an idle state upon some pre-configured event while performing a disconnected state transmission.

[0224] According to some example embodiments of the present disclosure, a communication solution is provided, in which the terminal device 210 detects at least one preset event while the terminal device 210 is transmitting a disconnected state with the network device 220. Thereafter, the terminal device 210 transitions to an idle state.

[0225] See Figure 10. Figure 10 illustrates an exemplary method 1000 performed by terminal device 210 to avoid keystream reuse.

[0226] In block 1010, the terminal device 210 detects a preset event while the terminal device 210 is transmitting a disconnected state to the network device 220. In block 1020, the terminal device 210 transitions to an idle state.

[0227] An example of a disconnected transmission is SDT. Another example of a disconnected transmission is EDT. Yet another example of a disconnected transmission is PUR.

[0228] In some exemplary embodiments, terminal device 210 determines that a predetermined event has occurred when it receives an RRC rejection message from network device 220. Alternatively, terminal device 210 determines that a predetermined event has occurred when it detects that a quality requirement for performing a disconnected transmission is not met.

[0229] In some exemplary embodiments, with respect to the SDT, pre-configured events include, but are not limited to, cell reselection, expiration of the SDT failure detection timer, reaching the maximum number of retransmissions in RLC, receiving an RRC reject message during the SDT, aborting the connection resumption procedure by higher layers, receiving RAN paging during the SDT, arrival of non-SDT data / signaling at the terminal device 210, failure to meet RSRP requirements during the SDT, or a lower layer (such as the MAC layer) indicating abort of the SDT due to, for example, lack of suitable resources.

[0230] In some exemplary embodiments, for both EDT and PUR, pre-configured events include, but are not limited to, expiration of T300, receipt of an RRC connection reject, and cell reselection.

[0231] In some exemplary embodiments, for both EDT and PUR, if the terminal device 210 detects a pre-configured event, the terminal device 210 discards the security context (such as nextHopChainingCount) and indicates to higher layers the release of the RRC connection.

[0232] In some exemplary embodiments, upon detecting a pre-configured event, in particular, upon receiving an RRCReject during the SDT / RSRP requirements not being met, the terminal device 210 performs a transition procedure to RRC idle with a release cause of "RRC Restart Failure." In this way, the NAS layer will perform NAS recovery.

[0233] In some demonstrative embodiments, terminal device 210 comprises circuitry configured to detect a pre-configured event during execution of a disconnected state transmission by terminal device 210 with network device 220. The circuitry is further configured to transition to an idle state.

[0234] In some exemplary embodiments, the circuitry is further configured to receive an RRC reject message from the network device 220 or detect that a quality requirement for performing a disconnected state transmission is not met.

[0235] Exemplary Process for Cell Reselection Currently, a terminal device may perform measurements in different cells and perform cell reselection based on the measurement results. Currently, if a cell with a higher priority frequency is detected and the radio quality of that cell exceeds a certain level, the terminal device reselects that cell. If the terminal device transitions to an idle state due to cell reselection during SDT, this will result in data loss. However, if the terminal device remains in an inactive state during cell reselection, there is a security risk. Therefore, it is expected that the terminal device will be able to complete the SDT procedure in the current cell as much as possible.

[0236] According to some example embodiments of the present disclosure, a communication solution is provided in which, when a terminal device 210 performs SDT with a first cell configured with a first frequency, the terminal device 210 reduces the likelihood of switching to a second cell 230-2 configured with a second frequency different from the first frequency. In this way, the terminal device 210 does not reselect a higher priority neighbor cell during the SDT procedure unless channel conditions are very poor.

[0237] 11 illustrates a flowchart of an example method 1100 according to some embodiments of the present disclosure. For example, method 1100 may be implemented in terminal device 210 as shown in FIG. 2. For purposes of discussion, method 1100 will be described with reference to FIG. 2. Method 1100 may involve terminal device 210, cell 230-1, and cell 230-2. In the following text, cell 230-1 may also be referred to as first cell 230-1, and cell 230-2 may also be referred to as second cell 230-2.

[0238] In block 1110, the terminal device 210 performs SDT with the first cell 230-1 configured with the first frequency.

[0239] In block 1120, the terminal device 210 reduces the likelihood of switching to a second cell configured with a second frequency different from the first frequency when performing small data transmission with the first cell.

[0240] In some exemplary embodiments, terminal device 210 considers the current frequency to be the highest priority for cell reselection. Specifically, terminal device 210 increases the priority of the first frequency when performing a cell reselection procedure, thereby reducing the likelihood of switching to a second cell.

[0241] Alternatively, in some exemplary embodiments, terminal device 210 does not perform inter-frequency measurements during the SDT. Specifically, terminal device 210 disables inter-frequency measurements when performing a cell reselection procedure, thereby reducing the likelihood of switching to the second cell.

[0242] In some exemplary embodiments, terminal device 210 includes a first cell 230-1 configured with a first frequency and circuitry configured to perform SDT, the circuitry further configured to reduce a likelihood of switching to a second cell configured with a second frequency different from the first frequency when performing small data transmission with the first cell.

[0243] In some exemplary embodiments, the circuitry is further configured to reduce a likelihood of switching to a different second cell when performing a cell reselection procedure by increasing the priority of the first frequency.

[0244] In some exemplary embodiments, the circuitry is further configured to reduce the likelihood of switching to a different second cell when performing a cell reselection procedure by disabling inter-frequency measurements.

[0245] Example Process for Passing PDCP Settings Currently, SRB1 is used to receive RRC messages. Generally, RRC messages carry important control information. Therefore, during the RRC connection resumption procedure (e.g., during transmission of an RRC resumption request message), the terminal device applies the default settings for SRB1 without restoring the PDCP settings for SRB1, allowing the terminal device to receive RRC messages. Furthermore, it has been agreed that in addition to DRBs, SRB1 and SRB2 can also be used for SDT. Therefore, the handling of PDCP settings for SRB1 requires further discussion.

[0246] Exemplary Embodiments for Restoring PDCP Settings According to some example embodiments of the present disclosure, a communication solution is provided in which terminal device 210 applies default configurations for RBs (e.g., SRB1) configured to carry RRC messages, or alternatively, terminal device 210 restores PDCP configurations for RBs (e.g., SRB1) configured to carry RRC messages.

[0247] 12 illustrates a flowchart of an exemplary method 1200 according to some embodiments of the present disclosure. For example, the method 1200 may be implemented in a terminal device 210 such as that illustrated in FIG.

[0248] In block 1210, terminal device 210 receives PDCP configuration for the RB of terminal device 210.

[0249] In block 1220, the terminal device 210 initiates an RRC connection resumption procedure for SDT.

[0250] In some embodiments, terminal device 210 applies default configurations for RBs configured to carry RRC messages (such as SRB1) even if SDT is configured for the RBs. For example, terminal device 210 initiates an RRC connection resumption procedure for SDP. The RRC connection resumption procedure for SDP comprises applying default PDCP configurations for RBs configured to carry RRC messages and not restoring PDCP configurations for the radio bearers, and restoring PDCP configurations for RBs configured for SDT, excluding RBs configured to carry RRC messages.

[0251] Additionally, in some embodiments, terminal device 210 restores PDCP configuration from stored UE inactive AS contexts for RBs other than SRB1 for which SDT is configured.

[0252] Additionally, in some embodiments, in response to receiving the RRC resumption message, terminal device 210 restores PDCP configuration for RBs not configured for SDT and for RBs configured to carry RRC messages.

[0253] As a specific example, if the terminal device 210 receives an RRC resumption message during an SDT and the RRC resumption message does not include fullConfig, the terminal device 210 restores the PDCP configuration from the UE inactive AS context for RBs for which an SDT is not configured and for RBs (such as SRB1) configured to carry RRC messages.

[0254] Alternatively, in some embodiments, terminal device 210 restores PDCP for all RBs configured for SDT. Specifically, terminal device 210 initiates an RRC connection resumption procedure for SDP. The RRC connection resumption procedure for SDP includes restoring PDCP settings for RBs configured for SDT, including RBs configured to carry RRC messages (such as SRB1).

[0255] In some embodiments, terminal device 210 restores PDCP configuration from stored UE inactive AS context for all RBs (including SRB1) for which SDT is configured.

[0256] Furthermore, in some embodiments, the terminal device 210 transitions to an idle state in response to detecting a failure to receive the RRC resumption message. As a specific example, if the terminal device 210 cannot respond to the RRC resumption message, the terminal device 210 performs an operation of transitioning to the idle state with the release cause set to RRC resumption failure.

[0257] Furthermore, in some embodiments, terminal device 210 restores PDCP configuration for RBs that are not configured for SDT in response to receiving the RRC resumption message.

[0258] As a specific example, if the terminal device 210 receives an RRC resumption message during an SDT and the RRC resumption message does not include fullConfig, the terminal device 210 restores the PDCP configuration for the RB for which the SDT is not configured from the UE inactive AS context.

[0259] In some exemplary embodiments, terminal device 210 comprises circuitry configured to receive PDCP configurations for RBs of terminal device 210 from network device 220. The circuitry is further configured to initiate an RRC connection resumption procedure for the SDT. The RRC connection resumption procedure comprises applying default PDCP configurations for RBs configured to carry RRC messages and not restoring PDCP configurations to RBs, and restoring PDCP configurations for RBs configured for the SDT, except for RBs configured to carry RRC messages.

[0260] In some exemplary embodiments, the circuitry is further configured to restore PDCP configuration for RBs not configured for SDT and for RBs configured to carry RRC messages in response to receiving an RRC resumption message.

[0261] In some exemplary embodiments, the RB configured to carry RRC messages is SRB1.

[0262] In some exemplary embodiments, terminal device 210 comprises circuitry configured to receive PDCP configuration for RBs of terminal device 210 from network device 220. The circuitry is further configured to initiate an RRC connection resumption procedure for the SDT. The RRC connection resumption procedure for the SDT includes restoring PDCP configuration for RBs configured for the SDT, including RBs configured to carry RRC messages.

[0263] In some exemplary embodiments, the circuitry is further configured to transition to an idle state in response to detecting a failed reception of the RRC resume message.

[0264] In some exemplary embodiments, the circuitry is further configured to restore PDCP configuration for RBs that are not configured for SDT in response to receiving an RRC resume message.

[0265] In some exemplary embodiments, the RB configured to carry RRC messages is SRB1.

[0266] Exemplary Embodiments for Configuring PDCP Settings in a Network Device According to some example embodiments of the present disclosure, a communication solution is provided in which, when a network device 220 configures an RB (such as SRB1) configured to carry RRC messages for SDT, the network device 220 must configure the PDCP setting of SRB1 with the same PDCP setting as the default SRB1 setting.

[0267] 13 illustrates a flowchart of an exemplary method 1300 according to some embodiments of the present disclosure. For example, the method 1300 may be implemented in the network device 220 as shown in FIG.

[0268] In block 1310, network device 220 generates PDCP configurations for RBs, including RBs configured to carry RRC messages, and if the RBs are configured for SDT, the RBs are configured with default PDCP configurations.

[0269] In block 1320 , the network device 220 sends the PDCP configuration to the terminal device 210 .

[0270] In some exemplary embodiments, the RB configured to carry RRC messages is SRB1.

[0271] In some exemplary embodiments, network device 220 comprises circuitry configured to generate PDCP configurations for RBs, including RBs configured to carry RRC messages, and configured with default PDCP configurations if the RBs are configured for SDT, and further configured to transmit the PDCP configurations to terminal device 210.

[0272] In some exemplary embodiments, the RB configured to carry RRC messages is SRB1.

[0273] Exemplary Apparatus Figure 14 is a schematic block diagram of an apparatus 1400 suitable for implementing embodiments of the present disclosure. Apparatus 1400 can be considered a further exemplary implementation of terminal device 210 and network device 220 shown in Figure 2. Thus, apparatus 1400 can be implemented in, or at least as part of, terminal device 210 or network device 220.

[0274] As shown, the apparatus 1400 includes 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 1420 stores at least a portion of a program 1430. The TX / RX 1440 is for bidirectional communication. The TX / RX 1440 has at least one antenna to facilitate communication, although in practice, the access nodes described herein may have multiple antennas. The communication interface may represent any interface required for communication with other network elements, such as an X2 interface for bidirectional communication between eNBs, an S1 interface for communication between a Mobility Management Entity (MME) / Serving Gateway (S-GW) and an eNB, a Un interface for communication between an eNB and a Relay Node (RN), or a Uu interface for communication between an eNB and a terminal device.

[0275] The program 1430 may be considered to include program instructions that, when executed by an associated processor 1410, enable the device 1400 to operate in accordance with embodiments of the present disclosure, as discussed herein with reference to FIGS. 2-13. The embodiments herein may be implemented by computer software, hardware, or a combination of software and hardware executable by the processor 1410 of the device 1400. The processor 1410 may be configured to implement various embodiments of the present disclosure. Additionally, the combination of the processor 1410 and the memory 1420 may constitute a processing means 1450 suitable for implementing various embodiments of the present disclosure.

[0276] Memory 1420 may be of any type suitable for a local technology network and may be implemented using any suitable data storage technology (e.g., but not limited to, computer-readable non-transitory storage media, semiconductor-based storage devices, magnetic storage devices and systems, optical storage devices and systems, fixed and removable memory, etc.). Although only one memory 1420 is shown in device 1400, device 1400 may include multiple physically distinct memory modules. Processor 1410 may be of any type suitable for a local technology network and may include, by way of example and not limitation, 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 configuration. Device 1400 may have multiple processors, e.g., application-specific integrated circuit chips time-slaved to a clock synchronous with the main processor.

[0277] Generally, various embodiments of the present disclosure may be implemented by hardware or special purpose circuits, software, logic, or any combination thereof. Some aspects may be implemented by hardware, while other aspects may be implemented by firmware or software that may be executed by a controller, microprocessor, or other computing device. Various aspects of the embodiments of the present disclosure have been shown and described as block diagrams, flowcharts, or illustrated by some other pictorial representation, and it will be understood that the blocks, apparatus, systems, techniques, or methods described herein may be implemented by, for example, but not limited to, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing device, or combinations thereof.

[0278] The present disclosure further provides at least one computer program product tangibly stored on a computer-readable, non-transitory storage medium. The computer program product includes computer-executable instructions, such as instructions included in program modules. The instructions execute on a target real or virtual processor device to perform, for example, the processes or methods described above with reference to FIGS. 2 and 4-18. Typically, 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 among program modules as desired. The machine-executable instructions for the program modules may be executed in local or distributed devices. In distributed devices, the program modules may be located in both local and remote storage media.

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

[0280] The above-described program code may be embodied on a machine-readable medium, which may be any tangible medium that contains or stores a program used by or in connection with an instruction execution system, apparatus, or device. 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, apparatus, or device, or any suitable combination of the foregoing. Even more specific examples of machine-readable storage media include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0281] Although operations have been described in a particular order, it should not be understood that performing these operations in the particular order or sequence shown, or performing all of the operations shown, is required to achieve desired results. In some situations, multitasking and parallel processing may be advantageous. Similarly, while the above discussion includes several specific implementation details, these should not be construed as limitations on the scope of the disclosure, but rather as descriptions of features that may be specific to particular embodiments. Some features that are described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination.

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

Claims

1. receiving a message from a network device that includes a list of security parameters for deriving a security key; deriving a first security key using a first security parameter from the list of security parameters; A method performed in a terminal device, transmitting to the network device the first security parameters used to derive the first security key.

2. sending a message to the terminal device containing a list of security parameters for deriving a security key; receiving a first security parameter from the list of security parameters from the terminal device; A method performed in a network device, wherein the first security parameter is used to derive a first security key.

3. means for receiving a message from a network device, the message including a list of security parameters for deriving a security key; means for deriving a first security key using a first security parameter of the list of security parameters; means for transmitting to the network device the first security parameters used to derive the first security key.

4. means for transmitting to the terminal device a message including a list of security parameters for deriving a security key; means for receiving from the terminal device a first security parameter from the list of security parameters; The first security parameter is used to derive a first security key, the first security parameter being executed in the network device.

Images