Methods implemented on terminal devices, methods implemented on network devices, terminal devices, and network devices
The communication method addresses the challenge of power consumption in wireless communication systems by enabling efficient small data transmission in inactive states and ensuring secure communication through new security key generation for non-connected states.
Patent Information
- Application Number
- JP2025012205
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-01-28
- Publication Date
- 2025-04-23
- Estimated Expiration
- 2041-07-05
AI Technical Summary
Current wireless communication systems face challenges in managing power consumption for terminal devices, particularly in inactive states, where small data transmission (SDT) is allowed but handling data arrivals from radio bearers that do not support transmission in inactive states is not efficiently addressed.
The proposed communication method involves initiating a procedure to release a radio resource control connection at the terminal device during SDT, while disabling the indication of data arrival from radio bearers that do not support transmission in inactive states. This method also includes receiving security elements for deriving security keys when the terminal device is in a non-connected state and resuming the RRC connection based on these elements.
This solution enables efficient power management by allowing SDT in inactive states without disrupting the RRC connection release procedure, and ensures secure communication by providing new security keys for resuming RRC connections in non-connected states.
Smart Images

Figure 2025066818000001_ABST
Abstract
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 the terminal devices can be set into several power saving modes / states (such as inactive state). For terminal devices in the inactive state, it has been proposed to suspend normal data transmission. In general, when a terminal device in the 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 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, the exemplary embodiments of the present disclosure provide a communication solution for inactive devices. To the extent that there are embodiments that do not 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, in a terminal device, a message from the network device comprising a plurality of security elements for respectively deriving a plurality of security keys 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 based at least in part on the message when the terminal device is in the unconnected state.
[0008] In a fourth aspect, a communication method is provided, the communication method including: sending, in a network device, a message to the terminal device comprising a plurality of security elements for respectively deriving a plurality of security keys 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 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, in a terminal device, information from a network device regarding a maximum number of security key generation based on a security element, where the security keys are 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 an 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 key generation based on a security element to a terminal device, the security key 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, a communication method is provided, the communication method including: 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 pre-configured event for triggering a stop of the non-connected state transmission, and performing a radio resource control connection resumption procedure, the radio resource control connection resumption procedure including performing a radio resource control connection resumption procedure with the first cell by encrypting data with an uninitialized first sequence number, or performing a 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 during execution of a non-connection state transmission by the terminal device to a network device, and transitioning to an idle state.
[0013] In a ninth aspect, a communication method is provided. The communication method includes, in a terminal device, performing small data transmission with a first cell in which a first frequency is set, and reducing a possibility of switching to a second cell in 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, a communication method is provided, the communication method including: receiving, in a terminal device, a packet data convergence protocol configuration for a radio bearer of the terminal device from a network device; and initiating a resumption procedure of a radio resource control connection for small data transmission, the resumption procedure of the radio resource control connection for small data transmission including: applying a default packet data convergence protocol configuration for a radio bearer configured to carry a radio resource control message, and not restoring a packet data convergence protocol configuration to the radio bearer; and restoring a packet data convergence protocol configuration for a radio bearer configured for small data transmission, except for the radio bearer configured to carry the radio resource control message.
[0015] In an eleventh aspect, a communication method is provided, comprising: receiving, in a terminal device, a packet data convergence protocol configuration for radio bearers of the terminal device from a network device; and initiating a resumption procedure of radio resource control for small data transmission, the resumption procedure of radio resource control for small data transmission comprising restoring a packet data convergence protocol configuration for radio bearers configured for the small data transmission, including a radio bearer configured to carry a radio resource control message.
[0016] In a twelfth aspect, a communication method is provided, 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, the radio bearers including a radio bearer configured to carry radio resource control messages, the radio bearer being configured with a default packet data convergence protocol configuration if the radio bearer is configured for small data transmission.
[0017] In a thirteenth aspect, there is provided a 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 first aspect.
[0018] In a fourteenth aspect, there is provided a 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 second aspect.
[0019] In a fifteenth aspect, there is provided a 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 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 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 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 apparatus comprising a processor and a memory coupled to the processor having instructions stored thereon which, when executed by the processor, cause the terminal apparatus to perform a method according to the seventh aspect.
[0024] In a twentieth aspect, there is provided a 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 eighth aspect.
[0025] In a twenty-first aspect, there is provided a terminal device comprising a processor and a memory coupled to the processor and 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 comprising a processor and a memory coupled to the processor and having instructions stored thereon, 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 comprising a processor and a memory coupled to the processor having instructions stored thereon which, when executed by the processor, cause the terminal device to perform a method according to the eleventh aspect.
[0028] In a twenty-fourth 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 twelfth aspect.
[0029] In a twenty-fifth aspect, there is provided a computer readable medium having stored thereon instructions which, when executed on at least one processor, cause the at least one processor to perform a method according to 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 description 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 a conventional signaling flow of SDT. [Figure 1B] 1 shows a conventional signaling flow of SDT. [Diagram 2] 1 illustrates an exemplary communication environment in which exemplary embodiments of the present disclosure may be practiced. [Diagram 3] 1 illustrates a signaling flow for handling data arrival from a radio bearer that does not support transmission in an inactive state, in accordance with 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, in accordance with 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, in accordance with 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 example method for avoiding keystream reuse in accordance with some embodiments of the present disclosure. [Figure 6B] 1 illustrates an example method for avoiding keystream reuse in accordance with some embodiments of the present disclosure. [Figure 7A] 13 illustrates another example method for avoiding keystream reuse in accordance with some embodiments of the present disclosure. [Figure 7B] 13 illustrates another example method for avoiding keystream reuse in accordance with some embodiments of the present disclosure. [Figure 8] 1 illustrates another example signaling flow for avoiding keystream reuse in accordance with some embodiments of the present disclosure. [Figure 9] 1 illustrates another example method for avoiding keystream reuse in accordance with some embodiments of the present disclosure. [Figure 10] 1 illustrates yet another exemplary method for avoiding keystream reuse, in accordance with some embodiments of the present disclosure. [Figure 11] 1 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 example method for handling PDCP settings in accordance with some embodiments of the present disclosure. [Figure 14]FIGURE 1 shows a schematic block diagram of an apparatus suitable for practicing the 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 PREFERRED EMBODIMENTS
[0032] The principles of the present disclosure will be described with reference to some exemplary embodiments. It should be understood that these embodiments are described for illustrative purposes only to aid those skilled in the art in understanding and implementing the present disclosure, and do not imply any limitations on the scope of the present disclosure. The 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," "an embodiment," "an exemplary embodiment," and the like indicate that the embodiment being described may include a particular feature, structure, or characteristic, but not all embodiments need to 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 of ordinary skill in the art to affect such feature, structure, or characteristic in connection with other embodiments, whether or not explicitly described.
[0035] In this specification, terms such as "first", "second", etc. may be used to describe various elements, but it should be understood that such elements should not be limited by these terms. These terms are used only to distinguish one element from another element. For example, a first element can be referred to as a second element, and similarly, a second element can be referred to as a first element, without departing from the scope of the exemplary embodiments. As used herein, the term "and / or" includes any one or more of the listed items, and all combinations thereof.
[0036] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the example embodiments. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise. Furthermore, it should be understood that the terms "comprise," "comprising," "having," "having," "including," and / or "including," as 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 that may be used, and that such choices are not necessarily better, smaller, higher, or more preferred than other choices.
[0038] As used herein, the term "network equipment" refers to equipment capable of providing or hosting a cell or coverage through which terminal equipment can communicate. Examples of network equipment include, but are not limited to, Node B (NB or NB), Evolved Node B (eNodeB or eNB), Node B for new radio access (gNB), Remote Radio Unit (RRU), Radio Head (RH), Remote Radio Head (RRH), low power nodes such as femto nodes, pico nodes, satellite network equipment, aircraft network equipment, etc. In the following, for the purpose of discussion, some exemplary embodiments are described with reference to an eNB as an example of a network equipment.
[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 (loT) 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", "communication 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), Narrow Band Internet of Things (NB-IoT), etc. Furthermore, communication between terminal devices and network devices in the communication network may be performed by 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 now known or developed in the future. Embodiments of the present disclosure may be applied to various communication systems. Considering the rapid development of communication, there will naturally be future communication technologies and communication systems in which the present disclosure can be embodied, and the scope of the present disclosure should not be deemed to be limited only to the aforementioned systems.
[0041] As used herein, the term "data of small data transmission" or "SDT data" refers to data that may be transmitted by a terminal device in an inactive or idle state. In general, "data of small data transmission" or "SDT data" is transmitted in radio bearers (including signaling radio bearers (SRBs)) and data radio bearers (DRBs) that are configured to support SDT or 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. In general, "non-small data transmission data" or "non-SDT data" is transmitted in radio bearers (including SRBs and DRBs) that are caused / 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 be performed 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 "circuitry" may refer to hardware circuits and / or combinations of hardware circuits and software. For example, a circuit may be a combination of analog and / or digital hardware circuits and 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 work together to perform various functions on a device, such as a terminal device or a network device. In yet another example, a circuit may be a hardware circuit and / or processor, such as a microprocessor or a portion of a microprocessor, that requires software / firmware for operation, but the software may not be present when not required for operation. As used herein, the term circuitry also encompasses merely a hardware circuit or processor, or a portion of a hardware circuit or processor, and its (or their) accompanying software and / or firmware implementations.
[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 user terminal devices may include corresponding functions, as described in connection with fixed and / or wireless network nodes, as appropriate. 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 that is configured for the user terminal device to execute in terms of these functions / nodes.
[0046] As mentioned above, in order to reduce the power consumption of the terminal device in wireless communication, the terminal device may be set to some power saving states or modes. For example, a radio resource control (RRC) inactive state is proposed and defined by a 3GPP work item. Also, as mentioned above, in order to further reduce the power consumption, a solution that enables SDT of the terminal device in the RRC inactive state is proposed by the 3GPP work item, and thus, the terminal device in the inactive RRC state may maintain 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 data volume of UL data to be transmitted across all radio bearers configured for SDT is less than a data volume threshold (such as a set volume) and the measured reference signal received power (RSRP) in a cell is greater than a set threshold. Due to the requirements of the data volume, SDT is proposed to be applied to some 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 in the case of non-smart terminal devices may include, but are not limited to, the following: ● 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 first UL data may be transmitted by a terminal device in an inactive state 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 first UL data is transmitted on CG resources.
[0051] Please refer to FIG. 1A. FIG. 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 an 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). In addition, the network device may send DL data (if any) to the terminal device together with the RRCRelease message.
[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 transmit / 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 then needs to transmit UL data to the network device, the terminal device transmits an RRC resume request message and UL data to the network device (160). In addition, the terminal device also transmits a buffer status report (BSR) together 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 further BSR to the network device (170), which in response transmits the UL grant of the dynamic grant and the further 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. Thus, considering there is no BSR, the network device may transmit an RRCRelease message and the further DL data to the terminal device (185).
[0055] Although some discussion / agreement has been made on 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 transmission during RRC connection release procedure, how to avoid key stream reuse, how to avoid cell reselection during SDT, how to restore PDCP settings (especially for SRB1 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 describe some exemplary embodiments of the present disclosure, and 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, in the case where the non-connected transmission is EDT or PUR, the transition to idle operation refers to the transition to idle without RRC pause, and in the case where the non-connected transmission is SDT, the transition to idle operation refers to the transition to RRC idle.
[0059] In the following, the phrases "RBs that do not support transmission in the inactive state" and "RBs that are not configured for SDT" (and similar expressions) may be used interchangeably, while the phrases "RBs that support transmission in the 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] Additionally, 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 the 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 the data being processed.
[0063] Furthermore, in the following, operations discussed in some 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 relation to one example / case / embodiment, it is believed to be within the knowledge of one skilled in the art to affect such operations in relation to other embodiments, whether or not explicitly described. In addition, 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 an exemplary embodiment 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 serve the terminal device 210. In the following text, the network devices 220-1 and 220-2 are collectively referred to as the network device 220 or individually referred to as the network device 220. Furthermore, the network device 220 may provide multiple serving areas to the terminal device 210. In the specific 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 a cell 230-4. In the following, the cells 230-1 to 230-4 are collectively referred to as the serving cells 230 or individually referred to as the 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 (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 (such as EDT or PUR). Also, when the terminal device 210 is in the inactive state, while SDT is supported, data transmissions that do not have SDT configured during SDT procedures are not allowed. 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 Fig. 2, the terminal device 210 may move over time. As shown in Fig. 2, the terminal device 210 is located in different locations over time. During the 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 or a handover procedure, etc.
[0068] Communications in the 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), Global System for Mobile Communications (GSM), and the like. 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. Communications environment 200 may include any suitable network devices, terminal devices, and cells suitable for implementing embodiments of the present disclosure. It should be understood that, although not shown, one or more additional terminal devices may be located within each cell. It should also be understood that in some examples, communications 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 requirement of the amount of data, it is proposed to apply SDT only to some specific application scenarios / RBs. Furthermore, during SDT, if the terminal device determines that data from RBs that do not support transmission in the inactive state (such as non-SDT data) needs to be transmitted to the network device, the terminal device should indicate the arrival of data from RBs that do not support transmission in the inactive state to the network device. This is because data from RBs that do not support transmission in the inactive state (such as non-SDT data) may include 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 decides 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 (such as 60 ms) or optionally waits if the lower layers of the terminal device indicate that the reception of the RRC release message has been successfully confirmed. Specifically, it is 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 lower layers of the terminal device indicate that the reception of the RRC release message has been successfully confirmed. The 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 terminal device's behavior in different scenarios should be consistent or similar. In order to align the terminal device's behavior 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 will selectively postpone / delay the above-mentioned operation for 60 ms from the moment the RRC release message is received or when the lower layer indicates that the reception of the RRC release message has been successfully confirmed. Thus, during the SDT, even if the terminal device receives an RRC release message, the terminal device will remain in the SDT state for a certain period of time. During this period, the terminal device may generate data (such as non-SDT data) from RBs that do not support transmission in the inactive state. So far, there has been no discussion on how to indicate data arrival from RBs that do not support transmission in the inactive state 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 details several exemplary embodiments for addressing 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 an SDT). In other words, if data from an RB that does not support inactive transmission arrives during an SDT and an RRC release message has not yet been received, terminal device 210 may indicate data arrival from an RB that does not support inactive transmission to network device 220. In this way, the RRC connection release procedure can be completed without interruption, and the state between terminal device 210 and network device 220 can be stable.
[0075] The terminal device 210 may indicate to the network device 220 the data arrival from the RB that does not support transmission in the inactive state in any suitable manner. As an example, the terminal device 210 may transmit a dedicated control channel (DCCH) message (SRB1) to the network device 220. In another example, the terminal device 210 may transmit a MAC CE to the network device 220. In a further example, the terminal device 210 may initiate an RRC connection resumption procedure with the network device 220. During the RRC connection resumption procedure, the terminal device 210 may transmit a common control channel (CCCH) message (SRB0) to the network device 220.
[0076] Reference is now made to Fig. 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 Fig. 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 (such as stopping a corresponding timer) for a period of time 330. Period 330 may be a predefined / configured value (such as 60 ms). Alternatively, period 330 refers to the time period from when the RRC release message is received to when the lower layers of terminal device 210 indicate that the reception of the RRC release message has been successfully acknowledged. As shown in FIG. 3, during this period of time 330, terminal device 210 determines / detects (340) data arrival from an RB that does not support transmission in the inactive state.
[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 the case where terminal device 210 determines that there is data (e.g., non-SDT data) from an RB that does not support transmission in an inactive state to be transmitted to network device 220, 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 transmission in an inactive state, terminal device 210 indicates to network device 220 the arrival of data from an RB that does not support transmission in an inactive state. 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 transmission in an inactive state.
[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 an inactive state, terminal device 210 may indicate to network device 220 the arrival of data from an RB that does not support transmission in an inactive state. Otherwise, terminal device 210 will not indicate to network device 220 the arrival of data from an RB that does not support transmission in an inactive state.
[0081] Furthermore, in some exemplary embodiments, terminal device 210 indicates (350-1) data arrival from an RB that does not support transmission in an inactive state to network device 220 upon completion of the RRC release procedure. In this manner, data arrival from an RB that does not support transmission in an inactive state can be indicated to network device 220 without significant delay.
[0082] 4A illustrates a flowchart of an example method 400 according to some embodiments of the present disclosure. For example, the method 400 may be implemented in a terminal device 210 as illustrated in FIG.
[0083] In block 410 , the terminal device 210 initiates an RRC release procedure while the terminal device 210 is performing an SDT with the 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 the inactive state while performing the RRC connection release procedure.
[0085] In some example embodiments, the terminal device 210 indicates to the network device 220 the arrival of data from an RB that does not support inactive transmission in response to a timer running, where the timer is started in response to a start of the SDT and is stopped in response to receiving an RRC release message from the network device 220.
[0086] In some example embodiments, terminal device 210 enables indicating to network device 220 data arrival from RBs that do not support transmission in the inactive state upon completion of the RRC connection release procedure.
[0087] In some example 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 the network device 220 data arrival from an RB that does not support inactive transmission in response to a timer running, where the timer is started in response to a start of the SDT and stopped in response to receiving an RRC release message from the 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 exemplary embodiments of the present disclosure, a solution for communication is provided. In this solution, the terminal device 210 may abandon / terminate the RRC connection release procedure and immediately indicate to the network device 220 the arrival of data from the RB that does not support transmission in the inactive state. In summary, if data from the RB that does not support transmission in the inactive state arrives after receiving the RRC release message, the terminal device 210 abandons the RRC connection release procedure and indicates to the network device 220 the arrival of data from the RB that does not support transmission in the inactive state. In this way, the arrival of data from the RB that does not support transmission in the inactive state can be indicated to the network device 220 without delay.
[0091] Please refer to Fig. 3 again. As shown in 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 ends 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 example method 450 according to some embodiments of the present disclosure. For example, the method 450 may be implemented in the terminal device 210 as illustrated in FIG.
[0093] In block 460 , the terminal device 210 initiates an RRC release procedure while the terminal device 210 is performing an SDT with the network device 220 .
[0094] In block 470, the terminal device 210 completes the RRC connection release procedure.
[0095] In block 480, terminal device 210 indicates to network device 220 data arrival 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] Exemplary Process for Security Keys During SDT, the terminal may terminate / abort the SDT procedure due to several events, including but not limited to the following: ● 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) The upper layer aborts the reconnection procedure. Event 6) Receiving Radio Access Network (RAN) paging during SDT Event 7) Non-SDT data / signal arrives at the terminal device 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 lack of suitable resources.
[0098] If an SDT abort occurs, the terminal device performs at least one of the following procedures: Destroy the current application stratum (AS) security context, including the KgNB, KRRCenc, KRRCint, KUPint, and KUPenc keys. Reset the MAC and release the 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 CANCEL, the terminal device remains in an inactive state and may initiate a further RRC resumption procedure in the same cell, although as mentioned above the current AS security context has been discarded during the SDT CANCEL procedure. Even if it is assumed that the AS security context may remain and the terminal device may later initiate a further RRC resumption procedure using the same UE context (e.g. AS security context), reusing the same AS security context during the further RRC resumption procedure is still not desirable or expected since different packets in the next RRC connection resumption procedure may be encrypted using the same security key and the same count value.
[0100] One possible solution proposes that the serving gNB provides a new security element (such as NextHopChainingCount, referred to herein 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 solution for communication is provided, in which new key information (such as multiple security elements for respectively deriving multiple security keys for communication between the terminal device 210 and the network device 220 when the terminal device 210 is in a disconnected state) may be provided to the terminal device 210. In this way, after SDT termination, the terminal device 210 may initiate at least one further RRC connection resumption procedure with the new security key. As a result, the above-mentioned key stream reuse problem can be avoided, so that the secure communication with the network device 220 is ensured.
[0103] Reference is now made to Figure 5A, which illustrates a signaling flow 500 for avoiding key stream 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, the terminal device 210 receives (505) a message from the network device 220 comprising a plurality of security elements for respectively deriving a plurality of security keys for communicating between the terminal device 210 and the network device 220 when the 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 a configuration for a non-connected transmission. One example of a non-connected transmission is an SDT. Another example of a non-connected transmission is an EDT. Yet another example of a non-connected transmission is a PUR.
[0106] When terminal device 210 is in an unconnected state, the security elements may cause terminal device 210 to perform an RRC connection resumption procedure with network device 220. Further, in some example embodiments, the RRC connection resumption procedure may be associated with at least one unconnected state transmission.
[0107] In some exemplary embodiments, terminal device 210 performs a first RRC connection resumption procedure associated with the non-connected 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 stops the non-connected state transmission in response to detecting a pre-configured event for triggering the stop of the non-connected state transmission (515). After the stop of the non-connected 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 example 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 non-connected transmission, or an RRC connection resumption procedure for a non-connected transmission. For example, terminal device 210 may send an RRC resumption request to network device 220 without any data being sent with the RRC resumption request.
[0109] Furthermore, to reduce the effort of network device 220, terminal device 210 can indicate information regarding the security element being used to network device 220. 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 (e.g., security elements) is configured by the network device 220 via an RRC release message with suspendconfig. For example, the network device 220 (e.g., gNB) configures a list of security settings (i.e., a list of security elements, e.g., NextHopChainingCount) in an RRC release message that configures an SDT for the terminal device 210. The list consists of N security settings that can be used for up to N RRC connection resumption procedures after the SDT is discontinued.
[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 resume request, for example by using a MAC CE.
[0112] In some example embodiments, terminal device 210 sequentially uses different security keys derived from different ones of the 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 a non-connected state transmission. Then, the terminal device 210 stops the non-connected state transmission in response to detecting a preset event for triggering the stop of the non-connected state transmission (525). Then, the terminal device 210 starts 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, the terminal device 210 performs an operation to transition to an idle state (such as an RRC idle state) upon the occurrence of a pre-configured event to trigger the discontinuation of the non-connected transmission. In some exemplary embodiments, in the case where the non-connected transmission is EDT or PUR, the transition to idle operation refers to a transition to the idle state without an RRC pause.
[0115] In some exemplary embodiments, if no security elements are available to derive a security key, 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] Furthermore, in some exemplary embodiments, the network device 220 may provide multiple cells. Furthermore, multiple cells may be grouped together as a serving group, and cells in the same serving group may share the same security context. When the terminal device 210 in the inactive state moves between cells in the same group, the 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] Please refer to Fig. 5B, which shows an example for providing multiple security elements. For the purpose of discussion, the signaling flow 550 will be described with reference to Fig. 2. The signaling flow 550 may involve the terminal device 210, the cell 230-1, and the cell 230-2. In the following text, the cell 230-1 will also be referred to as the first cell 230-1, and the cell 230-2 will also be referred to as the second cell 230-2.
[0118] During operation, terminal device 210 receives a message from network device 220 comprising multiple security elements for respectively deriving multiple 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 suspendConfig, which may comprise multiple 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 may allow the terminal device 210 to perform an RRC connection resumption procedure with either of the cells 230-1, 230-2. In the example of FIG. 5B, the terminal device 210 performs a first RRC connection resumption procedure associated with a disconnected transmission with the first cell 230-1 using a first security key derived from a first security element of the multiple security elements (560). For example, the terminal device 210 initiates an SDT procedure with the first cell 230-1 using NCC0.
[0120] Subsequently, the terminal device 210 stops the transmission in the disconnected state in response to detecting a preset event for triggering the stopping of the transmission in the disconnected state (565).
[0121] Also, after ceasing the disconnected transmission, the terminal device 210 may initiate a further RRC connection resumption procedure with one of the cells 230 (the first cell 230-1, the second cell 230-2, etc.). In the example of FIG. 5B, the terminal device 210 performs (570) a second RRC connection resumption procedure associated with the further disconnected transmission with the first cell 230-1 using a second security key derived from a second security element of the plurality of security elements. For example, the terminal device 210 initiates an RRC connection resumption procedure with the first cell 230-1 using a new security key generated by NCC1.
[0122] The terminal device 210 then halts further disconnected transmissions in response to detecting a pre-configured event for triggering halt of disconnected transmissions (575), for example due to cell reselection.
[0123] If there are security elements available to derive a security key, the terminal device 210 may initiate a third RRC connection resumption procedure with one of the cells 230 (the first cell 230-1, the second cell 230-2, etc.) (580). In the example of FIG. 5B, the terminal device 210 performs 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 (580). For example, the terminal device 210 initiates 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 elements are available 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 example method 600 according to some embodiments of the present disclosure. For example, the method 600 may be implemented in a terminal device 210 as illustrated 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 communicating between the terminal device 210 and the network device 220 when the terminal device is in an unconnected state.
[0127] In block 620, when the terminal device 210 is in an unconnected state, the terminal device 210 performs an RRC connection resumption procedure with the 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 a non-connected transmission.
[0129] In some exemplary embodiments, terminal device 210 performs a first RRC connection resumption procedure associated with the non-connected state transmission with network device 220 using a first security key derived from a first security element of the plurality of security elements, and terminal device 210 discontinues the non-connected state transmission in response to detecting a pre-configured event for triggering discontinuation of the non-connected 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 a security key, 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 with settings for a non-connected transmission.
[0135] In some demonstrative embodiments, the circuitry is further configured to perform a first RRC connection resumption procedure with network device 220 associated with the non-connected 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 pre-configured event for triggering the discontinuation of the non-connected state transmission, discontinue the non-connected 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 a security key.
[0137] In some exemplary embodiments, the circuitry is further configured to transmit to the network device 220 a field indicating the security element being used.
[0138] In some exemplary embodiments, the field is a MAC CE.
[0139] 6B illustrates a flowchart of an example 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 multiple security elements for respectively deriving multiple security keys for communicating between the terminal device 210 and the network device 220 when the terminal device 210 is in an unconnected state.
[0141] In block 670, when terminal device 210 is in a disconnected 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 a 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 an unconnected state.
[0146] In some exemplary embodiments, the message is an RRC release message comprising settings for a non-connected transmission.
[0147] In some exemplary embodiments, the circuitry is further configured to receive from terminal device 210 a field indicating the security element being used.
[0148] In some exemplary embodiments, the field is a MAC CE.
[0149] Exemplary embodiment to illustrate maximum number of security key generation According to some example embodiments of the present disclosure, a solution for communication is provided, in which a maximum number of security key generation based on security elements is provided for the terminal device 210. Thus, the 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, the terminal device 210 may initiate a further RRC connection resumption procedure with new security keys. As a result, the above-mentioned key stream reuse problem can be avoided, so that secure communication with the network device 220 is ensured.
[0150] In summary, terminal device 210 uses horizontal key derivation for a recovery mechanism (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 SDT aborts can be performed X times. 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 of transitioning to an idle state (such as an RRC idle state) when a predefined event occurs to trigger SDT abort.
[0152] 5 again for further details. During operation, the terminal device 210 receives information regarding the maximum number of security key generation based on the security element (505). The security key is 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 an unconnected transmission. One example of an unconnected transmission is an SDT. Another example of an unconnected transmission is an EDT. Yet another example of an unconnected 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 example 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 transmission with network device 220 using a first security key generated based on the security element (510). Furthermore, terminal device 210 stops the non-connected state transmission in response to detecting a pre-configured event for triggering the stop of the non-connected state transmission (515). After the stop of the non-connected state transmission, 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 element (520). The second security key is different from the first security key.
[0157] Furthermore, to reduce the effort of the network device 220, the terminal device 210 can indicate information regarding the number of security key generation based on the security element to the network device 220. For example, in some exemplary embodiments, the terminal device 210 transmits a field to the network device 220 indicating the number of security key generation based on the security element. Furthermore, in some exemplary embodiments, the field is a MAC CE. As an example, the terminal device 210 transmits the number of horizontal key updates to the network device 220 together with the RRC resume request message, for example, by the MAC CE.
[0158] 5A, the second RRC connection resumption procedure is associated with a non-connected state transmission, and the terminal device 210 stops the non-connected state transmission in response to detecting a preset event for triggering the stop of the non-connected state transmission (525).
[0159] Furthermore, in some exemplary embodiments, if the number of security key generation based on the security element 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, when the number of security keys generated based on security elements reaches the maximum number, the terminal device 210 transitions to the idle state upon detecting a preset event. Specifically, in FIG. 5A, the terminal device 210 stops transmitting the non-connected state (535) and transitions to the idle state (540).
[0161] Furthermore, the above-described process may be applied to scenarios in which 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] In the example of Figure 5B, the terminal device 210 performs a first RRC connection resumption procedure associated with a disconnected transmission with the first cell 230-1 using a first security key generated based on a security element (i.e., the NCC) (560). For example, the terminal device 210 initiates an SDT procedure with the first cell 230-1 using the NCC.
[0164] Subsequently, the terminal device 210 stops the transmission in the disconnected state in response to detecting a preset event for triggering the stopping of the transmission in the disconnected state (565).
[0165] Also, after ceasing the disconnected transmissions, the terminal device 210 may initiate a further RRC connection resumption procedure with one of the cells 230 (the first cell 230-1, the second cell 230-2, etc.) In the example of Figure 5B, the terminal device 210 performs (570) a second RRC connection resumption procedure associated with the disconnected transmissions with the first cell 230-1 using the second security key.
[0166] For example, the terminal device 210 initiates a second RRC connection resumption procedure with the first cell 230-1 using the 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, the terminal device 210 may initiate 580 a third RRC connection resumption procedure with one of the cells 230 (the first cell 230-1, the 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 the third security key.
[0169] For example, the terminal device 210 initiates a third RRC connection resumption procedure with the second cell 230-2 using the new key generated by horizontal key derivation.
[0170] In some exemplary embodiments, when the number of security keys generated based on the security elements reaches the maximum number, the terminal device 210 transitions to an idle state upon detecting a preset event. Specifically, in FIG. 5B, the terminal device 210 stops transmitting the non-connected state (585) and transitions to an idle state (590).
[0171] 7A illustrates a flowchart of an example method 700 according to some embodiments of the present disclosure. For example, the method 700 may be implemented in a terminal device 210 as illustrated in FIG.
[0172] In block 710, the terminal device 210 receives information regarding a 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 a disconnected 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 a setting for non-connected transmission.
[0175] In some exemplary embodiments, terminal device 210 performs a first RRC connection resumption procedure associated with the non-connected state transmission with network device 220 using a first security key generated based on the security element. Furthermore, terminal device 210 stops the non-connected state transmission in response to detecting a pre-configured event for triggering the stop of the non-connected state transmission. And terminal device 210 performs a second RRC connection resumption procedure with network device 220 using a second security key generated based on the security element.
[0176] In some exemplary embodiments, when the number of security keys generated 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 based at least in part on the maximum number when terminal device 210 is in an unconnected state.
[0180] In some exemplary embodiments, the maximum number is transmitted via a message comprising a setting for non-connected transmission.
[0181] In some demonstrative embodiments, the circuitry is further configured to perform a first RRC connection resumption procedure associated with the non-connected state transmission with the network device 220 using a first security key generated based on the security element, and in response to detecting a pre-configured event for triggering the discontinuation of the non-connected state transmission, discontinue the non-connected state transmission, and perform a second RRC connection resumption procedure with the 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 pre-defined 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 a generation number of security keys based on the security element.
[0184] In some exemplary embodiments, the field is a MAC CE.
[0185] 7B illustrates a flowchart of an example method 750 according to some embodiments of the present disclosure. For example, the method 750 may be implemented in the network device 220 as 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 key is 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 a setting for non-connected 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 a setting for non-connected 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 In addition to deriving new security keys by multiple security elements or based on the same security elements, 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. In addition, the terminal device 210 also needs to discard stored data (such as PDCP PDUs) that are set 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 solution for communication is provided, in which the terminal device 210 performs a disconnected transmission with a first cell (e.g., 230-1) of the network device 220 by encrypting data with a first sequence number. The method further comprises discarding stored data of the radio bearer configured for the disconnected transmission after detecting a preconfigured event for triggering the discontinuation of the disconnected transmission. Thereafter, the terminal device 210 performs an RRC connection resumption procedure with the first cell or the second cell using the uninitialized first sequence number or the 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 at the network device 220 .
[0198] Please refer now to FIG. 8. FIG. 8 illustrates a signaling flow 800 for avoiding key stream reuse, according to some embodiments of the present disclosure. For discussion purposes, the signaling flow 800 will be described with reference to FIG. 2. The signaling flow 800 may involve a terminal device 210, a cell 230-1, and a cell 230-2. In the following text, the cell 230-1 will also be referred to as the first cell 230-1, and the cell 230-2 will also be referred to as the 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] Furthermore, 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 pre-configured event for triggering the discontinuation of the disconnected state transmission, the terminal device 210 discards the stored data in the RB configured for the 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 a first sequence number that is not initialized (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 with 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 stored data (PDCP PDU, etc.) of the RB set for SDT, and continues to use the sequence number (TX_NEXT / COUNT value, etc.) of the RB where SDT is set. 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 stored data (PDCP PDU, etc.) of the RB set for SDT, and the sequence number (TX_NEXT / COUNT value, etc.) of the RB where SDT is set 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 by different procedures. Specifically, a typical PDCP suspension procedure comprises discarding PDCP PDUs and initializing TX_NEXT / COUNT for all DRBs, while a typical PDCP re-establishment procedure comprises RLC unacknowledged mode (UM) and initializing TX_NEXT / COUNT for SRBs. Therefore, the current procedures do 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, the terminal device 210 (e.g., a PDCP entity of the terminal device 210) performs a PDCP suspension procedure to discontinue non-connected state transmission. During the PDCP suspension procedure, the terminal device 210 discards stored data (e.g., PDCP PDUs) in RBs configured for non-connected state transmission and receives an instruction from the RRC layer of the terminal device 210 to disable initialization of the first sequence number. Furthermore, the terminal device 210 performs a PDCP re-establishment procedure while performing an RRC connection re-start procedure. During the PDCP re-establishment procedure, the terminal device 210 disables initialization of the first sequence number when the RRC connection re-start procedure is performed with the first cell 230-1 and initializes the first sequence number when the RRC connection re-start procedure is performed with the second cell 230-2. Thus, the above two operations are performed in different procedures.
[0207] Alternatively, the above two operations may be implemented in another 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 non-connected state transmission. 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 and exemplary embodiment, when the 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 the RBs for which the SDT is set. For example, the terminal device discards the stored data by performing a PDCP suspension procedure, and indicates the continuation of the sequence number for PDCP (i.e., TX_NEXT / COUNT value) when performing a PDCP suspension for the RBs for which the SDT is set. Furthermore, when the terminal device 210 initiates an RRC connection resumption procedure in a cell in which 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 the RBs for which the SDT is set (i.e., TX_NEXT / COUNT value). For example, during the RRC resumption procedure, the RRC layer must indicate the continuation of the sequence number for PDCP (i.e., TX_NEXT / COUNT value) when performing a PDCP re-establishment for the RBs for which the SDT is set. 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 initializes 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 with SDT configured. For example, the terminal device 210 performs a PDCP suspension procedure and indicates continuation of sequence numbers for PDCP (i.e., TX_NEXT / COUNT values) when performing the PDCP suspension procedure for RBs with SDT configured. In another example, the terminal device 210 indicates discarding stored data (such as PDCP PDUs) when performing a PDCP re-establishment procedure for RBs with SDT configured. Furthermore, continued sequence numbers (i.e., TX_NEXT / COUNT values) must be used for RBs with SDT configured. For example, when performing PDCP re-establishment during the RRC connection resumption procedure, the RRC layer must indicate continuation of sequence numbers for PDCP (i.e., TX_NEXT / COUNT values) when performing the PDCP re-establishment procedure for RBs with SDT 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 executed the SDT procedure), the terminal device 210 may discard stored data (PDCP PDUs, etc.) of the RBs in which the SDT is set, and initialize the sequence numbers (i.e., TX_NEXT / COUNT values) of all the RBs in which the SDT is set. For example, the terminal device 210 executes the PDCP suspension procedure without indicating the continuation of the sequence numbers (i.e., TX_NEXT / COUNT values), and then executes the PDCP re-establishment procedure without indicating the continuation of the sequence numbers (i.e., TX_NEXT / COUNT values). In another example, the terminal device 210 executes the PDCP re-establishment procedure with instructions to discard the PDUs and initialize the sequence numbers (i.e., TX_NEXT / COUNT values) of the RLC AM DRBs in which the SDT is set.
[0211] In some exemplary embodiments, when a higher layer requests the suspension of a PDCP entity, the sending PDCP entity must set TX_NEXT to its initial value and discard all stored PDCP PDUs unless TX_NEXT continuation is indicated by the higher layer. 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, transmit all stored PDCP SDUs to the higher layer in ascending order of their associated COUNT values after performing header recovery, and set RX_NEXT and RX_DELIV to their initial values.
[0212] In some exemplary embodiments, when higher layers request re-establishment of a PDCP entity, the sending PDCP entity shall do at least one of the following: 1) for UM and AM DRBs, reset the Robust Header Compression (ROHC) protocol for the uplink and start in the Initialization and Refresh (IR) state in UM if drb-ContinueROHC is not set, 2) for UM and AM DRBs, reset the EHC protocol for the uplink if drb-ContinueEHC-UL is not set, 3) for UM DRBs and SRBs, set TX_NEXT to its initial value if TX_NEXT continuation is not indicated by higher layers, and 4) for AM DRBs, set TX_NEXT to its initial value if TX_NEXT initialization is indicated by higher layers.
[0213] 5) for an SRB, discard all stored PDCP SDUs and PDCP PDUs; and 5) for a 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 a terminal device 210 as illustrated 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 state transmission after detecting a pre-configured event for triggering discontinuation of disconnected state 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 a first sequence number that is not initialized, or performing an RRC connection resumption procedure with the second cell 230-2 of the network device 220 by encrypting data with a first sequence number that is initialized.
[0218] In some example embodiments, in response to detecting the preconfigured event, the 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 indication from the terminal device's RRC layer to disable initialization of the first sequence number. Additionally, during the RRC connection resumption procedure, the terminal device 210 performs 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.
[0219] In some example 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, the terminal device 210 comprises a circuit configured to perform a disconnected transmission with a first cell 230-1 of the network device 220 by encrypting data with the first sequence number. The circuit is further configured to discard the stored data in the RB configured for disconnected transmission after detecting a pre-configured event for triggering discontinuation of the disconnected transmission. The circuit is also configured to perform an RRC resumption procedure, the RRC resumption procedure comprising 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 a second cell 230-2 of the network device 220 by encrypting data with an initialized first sequence number.
[0221] In some exemplary embodiments, in response to detecting the pre-configured event, the circuitry is further configured to perform a PDCP suspension procedure in the PDCP entity. The PDCP suspension procedure comprises discarding stored data for RBs configured for disconnected transmission and receiving an indication 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 example 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 transitioning to an idle state In addition to the exemplary process described above, terminal device 210 may transition to an idle state upon some pre-configured events while performing a disconnected state transmission.
[0224] According to some exemplary embodiments of the present disclosure, a solution for communication is provided, in which the terminal device 210 detects at least one pre-configured event during the execution of the transmission of a disconnected state by the terminal device 210 to the network device 220. Then, the terminal device 210 transitions to an idle state.
[0225] Please refer to Fig. 10. Fig. 10 illustrates an exemplary method 1000 performed by the 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 non-connected state to the network device 220. In block 1020, the terminal device 210 transitions to an idle state.
[0227] An example of a non-connected transmission is an SDT. Another example of a non-connected transmission is an EDT. Yet another example of a non-connected transmission is a PUR.
[0228] In some exemplary embodiments, terminal device 210 receives an RRC rejection message from network device 220 and then determines that the pre-configured event has occurred. Alternatively, terminal device 210 detects that a quality requirement for performing a disconnected state transmission is not met and then determines that the pre-configured event has occurred.
[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, receiving an RRC connection reject, and cell reselection.
[0231] In some exemplary embodiments, when terminal device 210 detects a pre-configured event for both EDT and PUR, 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 detection of a pre-configured event, in particular when receiving an RRCReject during the SDT / when the RSRP requirements are not met, the terminal device 210 performs a transition procedure to RRC idle with release cause "RRC Restart Failure". In this way, the NAS layer will perform NAS recovery.
[0233] In some demonstrative embodiments, terminal device 210 includes 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 demonstrative 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, the 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 condition of the cell is above a certain level, the terminal device reselects the cell. If the terminal device moves to an idle state due to cell reselection during SDT, this will lead to data loss. However, there is a security problem if the terminal device remains in an inactive state during cell reselection. Therefore, it is expected that the terminal device can finish 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 possibility 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 the channel conditions are very poor.
[0237] FIG. 11 illustrates a flowchart of an example method 1100 according to some embodiments of the present disclosure. For example, the method 1100 may be implemented in a terminal device 210 as illustrated in FIG. 2. For purposes of discussion, the method 1100 will be described with reference to FIG. 2. The method 1100 may involve the terminal device 210, a cell 230-1, and a cell 230-2. In the following text, the cell 230-1 is also referred to as the first cell 230-1, and the cell 230-2 is also referred to as the second cell 230-2.
[0238] In block 1110, the terminal device 210 performs SDT with a first cell 230-1 configured with a first frequency.
[0239] In block 1120, the terminal device 210 reduces the likelihood of switching to a second cell in which a second frequency different from the first frequency is configured when performing small data transmission with the first cell.
[0240] In some exemplary embodiments, the terminal device 210 considers the current frequency as the highest priority in cell reselection. Specifically, the terminal device 210 increases the priority of the first frequency when performing a cell reselection procedure, thereby reducing the possibility of switching to the second cell.
[0241] Alternatively, in some exemplary embodiments, the terminal device 210 does not perform inter-frequency measurements during the SDT, specifically, the 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 demonstrative 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 a 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 for receiving RRC messages. Generally, RRC messages carry important control information. Therefore, during the RRC connection resumption procedure (e.g., during the transmission of an RRC resume request message), the terminal device applies the default settings for SRB1 without restoring the PDCP settings for SRB1, so that the terminal device can receive RRC messages. Furthermore, it is agreed that in addition to DRB, 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 solution for communication is provided, in which the terminal device 210 applies default configuration for an RB (e.g., SRB1) configured to carry an RRC message, or alternatively, the terminal device 210 restores a PDCP configuration for an RB (e.g., SRB1) configured to carry an RRC message.
[0247] 12 illustrates a flowchart of an example method 1200 according to some embodiments of the present disclosure. For example, the method 1200 may be implemented in a terminal device 210 as illustrated in FIG.
[0248] In block 1210, the terminal device 210 receives PDCP configuration for the RB of the terminal device 210.
[0249] In block 1220, the terminal device 210 initiates an RRC connection resumption procedure for SDT.
[0250] In some embodiments, the terminal device 210 applies default settings for RBs (such as SRB1) configured to carry RRC messages, even if SDT is configured on them. For example, the terminal device 210 initiates an RRC connection resumption procedure for SDP. The RRC connection resumption procedure for SDP comprises applying default PDCP settings for RBs configured to carry RRC messages and not restoring PDCP settings to the radio bearer, and restoring PDCP settings for RBs configured for SDT, except for the RBs configured to carry RRC messages.
[0251] Further, in some embodiments, the terminal device 210 restores PDCP configuration from stored UE inactive AS context for RBs other than SRB1 for which SDT is configured.
[0252] Furthermore, 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, when 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 settings 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, the terminal device 210 restores PDCP for all RBs configured with the SDT. Specifically, the terminal device 210 initiates an RRC connection resumption procedure for the SDP. The RRC connection resumption procedure for the SDP includes restoring PDCP settings for RBs configured for the SDT, including RBs (such as SRB1) configured to carry RRC messages.
[0255] In some embodiments, the terminal device 210 restores the PDCP configuration from the stored UE inactive AS context for all RBs (including SRB1) for which an 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 an idle state with a release cause of 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, when 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 settings for RBs for which the SDT is not configured from the UE inactive AS context.
[0259] In some example embodiments, terminal device 210 comprises circuitry configured to receive PDCP settings 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 settings for RBs configured to carry RRC messages and not restoring PDCP settings to the RBs, and restoring PDCP settings for RBs configured for the SDT, except for the RBs configured to carry RRC messages.
[0260] In some example 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 example 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 an RRC message 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 example method 1300 according to some embodiments of the present disclosure. For example, the method 1300 may be implemented in the network device 220 as illustrated in FIG.
[0268] In block 1310, the network device 220 generates PDCP configurations for RBs, including RBs configured to carry RRC messages, and if the RB is configured for SDT, the RB is configured with a default PDCP configuration.
[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 example 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 Fig. 14 is a schematic block diagram of an apparatus 1400 suitable for implementing embodiments of the present disclosure. The apparatus 1400 can be considered as a further exemplary implementation of the terminal device 210 and the network device 220 shown in Fig. 2. Thus, the apparatus 1400 can be implemented in, or at least as part of, the terminal device 210 or the 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 discussed 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, an Un interface for communication between an eNB and a Relay Node (RN), or an 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 Figures 2-13. The embodiments of the present disclosure 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] The memory 1420 may be of any type suitable for the local technology network and may be implemented by any suitable data storage technology, including, 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 memories, etc. Although only one memory 1420 is shown in the device 1400, multiple physically distinct memory modules may be installed in the device 1400. The processor 1410 may be of any type suitable for the local technology network and may include, but is not limited to, one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), and processors based on multi-core processor configurations. The device 1400 may have multiple processors, for example application specific integrated circuit chips time-slaved to a clock synchronous with the main processor.
[0277] In general, 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, and 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, flow charts, 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 in a computer readable non-transitory storage medium. The computer program product includes computer executable instructions, such as instructions included in a program module. The instructions execute on a target real or virtual processor device to perform processes or methods, such as those described above with reference to Figures 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. 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] The program codes for carrying out the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, a special purpose computer or other programmable data processing apparatus, and when the program codes are executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are performed. The program codes 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 program code may be embodied on a machine-readable medium, which may be any tangible medium that contains or stores a program for use by or in conjunction 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] It should be noted that although operations have been described in a particular order, it should not be understood that the operations must be performed in the particular order or sequence shown, or that all of the operations shown must be performed, in order to achieve desired results. In some situations, multitasking and parallel processing may be advantageous. Similarly, although the above discussion includes some 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 certain embodiments. Some features that are described in the context of individual embodiments may be implemented in combination in an embodiment. Conversely, various features that are described in the context of an embodiment may 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, the message including a list of security parameters for deriving a security key; deriving a first security key using a first security parameter of the list of security parameters; A method performed in a terminal device, the method transmitting to the network device the first security parameters used to derive the first security key.
2. sending a message to a terminal device, the message including 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 from a network device a 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 a 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.
Citation Information
Patent Citations
Digital data transmitting device, and transmission control program
JP2007150963A
Device, method, system, and program relating to beam and security enhancement, and recording medium
WO2018029952A1