Terminal device and method performed by a terminal device
Patent Information
- Application Number
- JP2024547528
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2022-02-11
- Publication Date
- 2025-02-26
- Estimated Expiration
- 2042-02-11
AI Technical Summary
【0013】 本開示のその他の特徴は、以下の説明により容易に理解できるはずである。
Smart Images

Figure 2025505463000001_ABST
Abstract
Description
[Technical field]
[0001] TECHNICAL FIELD Embodiments of the present disclosure relate generally to the field of telecommunications, and more particularly to a method, apparatus, and computer storage medium for communication during data transmission in an inactive state of a terminal device. [Background technology]
[0002] Typically, a terminal device in an inactive state may still have a small amount of infrequent data traffic to transmit. Until 3rd Generation Partnership Project (3GPP) Release 16, the inactive state does not support data transmission, and the terminal device must resume the connection (i.e., enter the connected state) for both downlink and uplink data. This causes unnecessary power consumption and signaling overhead.
[0003] In this case, small data transmission (SDT) in the inactive state has been approved in 3GPP Release 17. Therefore, the signaling overhead can be reduced. However, so far, SDT-related technologies are still underdeveloped and further development is awaited. Summary of the Invention [Problem to be solved by the invention]
[0004] Generally, embodiments of the present disclosure provide a communication method, apparatus, and computer storage medium. [Means for solving the problem]
[0005] In a first aspect, a method of communication is provided, the method including: receiving, in a terminal device, a connection rejection message from a network device when the terminal device is performing a first connection resumption procedure initiated for Small Data Transmission (SDT), and initiating a second connection resumption procedure.
[0006] In a second aspect, a method of communications is provided, the method including: at a terminal device, when performing an SDT procedure, sending a message on an SRB1 to a network device indicating arrival of non-SDT data, and in response to receiving a connection rejection message from the network device, continuing the SDT procedure.
[0007] In a third aspect, a method of communication is provided, the method including: in a network device, sending to a terminal device a connection rejection message in response to a first connection resumption procedure initiated for an SDT, receiving a connection resumption request message for a second connection resumption procedure not initiated for an SDT, and sending a connection establishment message.
[0008] In a fourth aspect, a method of communication is provided, the method including: initiating, in a terminal device, a configuration grant-based SDT procedure, determining that no Synchronization Signal Block (SSB) associated with a configuration grant resource for SDT is above a threshold, determining that a Buffer Status Report (BSR) has been triggered or there is buffered data to be transmitted, and initiating a random access procedure.
[0009] In a fifth aspect, a terminal device is provided, the terminal device comprising: a processor; and a memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the terminal device to perform a method according to any one of the first to second aspects of the present disclosure.
[0010] In a sixth aspect, there is provided a network device comprising a processor and a memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the network device to perform a method according to the third aspect of the present disclosure.
[0011] In a seventh 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 one of the first to second aspects of the present disclosure.
[0012] In an eighth aspect, a computer readable medium is provided having instructions stored thereon that, when executed on at least one processor, cause the at least one processor to perform a method according to the third aspect of the present disclosure.
[0013] Other features of the present disclosure will become readily apparent from the following description. [Brief description of the drawings]
[0014] The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description of several embodiments of the present disclosure in the accompanying drawings.
[0015] [Figure 1A] FIG. 1 illustrates an example communication network in which some embodiments of the present disclosure may be implemented.
[0016] [Figure 1B] FIG. 1 is a schematic diagram illustrating a User Plane (UP) protocol stack in which some embodiments of the present disclosure may be implemented.
[0017] [Figure 1C] FIG. 1 is a schematic diagram illustrating a Control Plane (CP) protocol stack in which some embodiments of the present disclosure may be implemented.
[0018] [Figure 2A] FIG. 1 is a schematic diagram illustrating an SDT procedure in which some embodiments of the present disclosure can be implemented.
[0019] [Figure 2B] FIG. 2 is a schematic diagram illustrating an SDT procedure including an initial transmission and subsequent transmissions, in which some embodiments of the present disclosure can be implemented.
[0020] [Diagram 3] FIG. 2 is a schematic diagram illustrating a process for communication during an SDT procedure, according to an embodiment of the present disclosure.
[0021] [Figure 4] FIG. 2 is a schematic diagram illustrating a process for communication during an SDT procedure, according to an embodiment of the present disclosure.
[0022] [Diagram 5] FIG. 2 illustrates an exemplary communication method implemented in a terminal device according to some embodiments of the present disclosure.
[0023] [Figure 6] FIG. 2 illustrates an exemplary communication method implemented in a terminal device according to some embodiments of the present disclosure.
[0024] [Figure 7] FIG. 2 illustrates an example communication method implemented in a network device, according to some embodiments of the present disclosure.
[0025] [Figure 8] FIG. 2 illustrates an example communication method implemented in a network device, according to some embodiments of the present disclosure.
[0026] [Figure 9] FIG. 1 is a schematic block diagram of an apparatus suitable for implementing embodiments of the present disclosure.
[0027] In the drawings, the same or similar reference numbers represent the same or similar elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0028] The principles of the present disclosure will now be described with reference to some embodiments. It should be understood that these embodiments are provided for illustrative purposes only, to assist those skilled in the art in understanding and implementing the present disclosure, and do not imply any limitations on the scope of the present disclosure. The disclosure described herein can be implemented in various ways different from those described below.
[0029] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.
[0030] As used herein, the term "terminal device" refers to any device having wireless or wired communication capabilities. Examples of terminal devices include, but are not limited to, User Equipment (UE), personal computers, desktop computers, mobile phones, cellular phones, smartphones, personal digital assistants (PDAs), portable computers, tablets, wearable devices, Internet of Things (IoT) devices, Internet of Everything (IoE) devices, Machine Type Communication (MTC) devices, in-vehicle devices for V2X communication, etc., where the "X" in V2X represents a pedestrian, vehicle, or infrastructure / network, or an image capture device such as a digital camera, a gaming device, a music storage and playback device, or an Internet appliance that allows wireless or wired Internet access and browsing, etc. The term "terminal device" may be used interchangeably with UE, mobile station, subscriber station, mobile terminal, user terminal, or wireless device. Additionally, the term "network device" refers to a device that can provide or host a cell or coverage over which the terminal device can communicate. Examples of network devices include, but are not limited to, low power nodes such as a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), a next generation Node B (gNB), a transmit / receive point (TRP), a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), a femto node, a pico node, etc.
[0031] In one embodiment, the terminal device can connect to a first network device and a second network device. One of the first network device and the second network device may be a master node and the other may be a secondary node. The first network device and the second network device may use different Radio Access Technologies (RATs). In one embodiment, the first network device may be a first RAT device and the second network device may be a second RAT device. In one embodiment, the first RAT device is an eNB and the second RAT device is a gNB. Information about the different RATs may be transmitted from at least one of the first network device or the second network device to the terminal device. In one embodiment, the first information may be transmitted from the first network device to the terminal device, and the second information may be transmitted from the second network device to the terminal device directly or via the first network device. In one embodiment, information about the configuration of the terminal device configured by the second network device may be transmitted from the second network device via the first network device. Information regarding the reconfiguration of the terminal device configured by the second network device may be transmitted from the second network device directly to the terminal device or via the first network device.
[0032] As used herein, the singular forms "a," "an," and "said" include the plural forms unless the context clearly indicates otherwise. The term "comprises" and variations thereof should be understood as open-ended terms meaning "including, but not limited to." The term "based on" should be understood as "based at least in part on." The terms "one embodiment" and "embodiment" should be understood as "at least one embodiment." The term "another embodiment" should be understood as "at least one other embodiment." Terms such as "first," "second," and the like may refer to different or the same object. The following may include other explicit and implicit definitions.
[0033] In some instances, values, procedures, or devices are referred to as "best," "lowest," "highest," "minimum," "maximum," etc. It should be understood that such descriptions are intended to illustrate that selections can be made from among many functional alternatives used, and that such selections are not necessarily better, smaller, higher, or otherwise more preferred than other selections.
[0034] Traditionally, there are various applications that exchange small amounts of data infrequently. For example, in some applications for mobile devices, SDT may include traffic from Instant Messaging (IM) services, such as heartbeat or keep-alive traffic from IM or email clients and other services, push notifications in various applications, traffic from wearable devices (including, for example, periodic location information), etc. In some applications for non-mobile devices, SDT may include sensor data (e.g., temperature, pressure measurements transmitted periodically or in an event-triggered manner within an IoT network), metering and alarm information sent from smart meters, etc.
[0035] In a conventional Radio Resource Control (RRC) resumption procedure, no uplink data is sent for an inactive terminal device together with the RRC resumption request message, whereas in the case of an SDT procedure, uplink data can be sent to a network device for an inactive terminal device together with the RRC resumption request message.
[0036] During the SDT, uplink data from at least one of the radio bearers supporting transmission in the inactive state is transmitted in the inactive state of the terminal device. Whether a radio bearer supports data transmission in the inactive state is configured by the network device. In some scenarios, new data (for convenience, also referred to herein as non-SDT data) may arrive from a radio bearer that does not support transmission in the inactive state during the SDT.
[0037] For these and other potential scenarios, the embodiments of the present disclosure provide an improved solution for communication during SDT to ensure that the SDT is completed as soon as possible. The principles and embodiments of the present disclosure are described in detail below with reference to the accompanying drawings. Example of communication environment
[0038] FIG 1A is a schematic diagram illustrating an exemplary communication network 100A in which an embodiment of the present disclosure can be implemented. As shown in FIG 1A, the communication network 100A may include a terminal device 110 and a plurality of network devices 120 and 130. The network devices 120 and 130 provide respective cells 121 and 131. In the example of FIG 1A, the terminal device 110 is in the cell 121 of the network device 120, and the terminal device 110 may communicate with the network device 120. The cell 121 may be referred to as a serving cell of the terminal device 110.
[0039] It should be understood that the number of devices in FIG. 1A is given for illustrative purposes and does not imply any limitations to the present disclosure. Communications network 100 may include any suitable number of network devices and / or terminal devices suitable for implementing embodiments of the present disclosure. Furthermore, each of network devices 120 and 130 may provide more cells to terminal device 110.
[0040] 1A, terminal device 110 may communicate with network device 120 via a channel, such as a wireless communication channel. Communications in communication network 100 may conform to any suitable standard, including, but not limited to, Global System for Mobile Communications (GSM), Long Term Evolution (LTE), LTE-Evolution, LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), GSM EDGE Radio Access Network (GERAN), Machine Type Communication (MTC), and the like. Furthermore, communications may be performed according to any generation of communication protocols now known or developed in the future. Examples of communication protocols include, but are not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, and fifth generation (5G) communication protocols.
[0041] In some scenarios of dual connectivity, the network devices 120 and 130 may simultaneously serve the terminal device 110 as a Master Node (MN) or a Secondary Node (SN). The cells provided by the MN form a Master Cell Group (MCG) for the terminal device 110, and the cells provided by the SN form a Secondary Cell Group (SCG) for the terminal device 110. In some scenarios, the terminal device 110 in an inactive state may communicate with either the network device 120 or 130.
[0042] Communications in the direction from the terminal device 110 to the network device 120 or 130 are referred to as uplink (UL) communications, and communications in the direction from the network device 120 or 130 to the terminal device 110 are referred to as downlink (DL) communications. The terminal device 110 may move between the cells of the network devices 120, 130, and possibly other network devices. In UL communications, the terminal device 110 may transmit UL data and control information to the network device 120 or 130 over a UL channel. In DL communications, the network device 120 or 130 may transmit DL data and control information to the terminal device 110 over a DL channel.
[0043] Communications in the communication network 100 may be performed according to the UP and CP protocol stacks. Generally speaking, for a communication device (e.g., a terminal device or a network device), there may be multiple entities of multiple network protocol layers in the protocol stack, and these entities may be configured to perform corresponding processes on data or signaling sent from and received by the communication device. Figure 1B is a schematic diagram 100B illustrating network protocol layer entities that may be established for a UP protocol stack in a device according to some embodiments of the present disclosure.
[0044] As shown in FIG. 1B, in the UP, each of the terminal device 110 and the network device 120 may include an L1 layer entity, i.e., a physical (PHY) layer entity (also referred to as a PHY entity), and one or more entities of upper layers (L2 layer and L3 layer, i.e., higher layers), including a media access control (MAC) layer entity (also referred to as a MAC entity), a radio link control (RLC) layer entity (also referred to as an RLC entity), a packet data convergence protocol (PDCP) layer entity (also referred to as a PDCP entity), and a service data application protocol (SDAP) layer entity (also referred to as an SDAP entity, which will be established in 5G and subsequent generation networks). In some cases, the PHY, MAC, RLC, PDCP, and SDAP entities are in a stack structure.
[0045] FIG. 1C is a schematic diagram 100C illustrating network protocol layer entities that may be established for a CP protocol stack in an apparatus according to some embodiments of the present disclosure. As shown in FIG. 1C, in a CP, each of the terminal device 110 and the network device 120 may include one or more entities of upper layers (L2 layer and L3 layer), including an L1 layer entity, i.e., a PHY layer entity (also referred to as a PHY entity), a MAC layer entity (also referred to as a MAC entity), an RLC layer entity (also referred to as an RLC entity), a PDCP layer entity (also referred to as a PDCP entity), and a radio resource control (RRC) layer entity (also referred to as an RRC entity). The RRC layer may further be referred to as an access stratum (AS) layer, and therefore the RRC entity may further be referred to as an AS entity. As shown in FIG. 1C, the terminal device 110 may further include a non-access stratum (NAS) layer entity (also referred to as a NAS entity). The NAS layer on the network side is located in a Core Network (CN, not shown) rather than in a network device. In some cases, these entities are in a stack structure.
[0046] Generally, communication channels are divided into logical channels, transmission channels, and physical channels. A physical channel is a channel through which a PHY layer actually transmits information. For example, the physical channel may include a physical uplink control channel (PUCCH), a physical uplink shared channel (PUSCH), a physical random-access channel (PRACH), a physical downlink control channel (PDCCH), a physical downlink shared channel (PDSCH), and a physical broadcast channel (PBCH).
[0047] The transmission channel is a channel between the PHY layer and the MAC layer. For example, the transmission channel may include a broadcast channel (BCH), a downlink shared channel (DL-SCH), a paging channel (PCH), an uplink shared channel (UL-SCH), and a random access channel (RACH).
[0048] A logical channel is a channel between the MAC layer and the RLC layer. For example, the logical channel may include a dedicated control channel (DCCH), a common control channel (CCCH), a paging control channel (PCCH), a broadcast control channel (BCCH), and a dedicated traffic channel (DTCH).
[0049] Generally, a channel between the RRC layer and the PDCP layer is referred to as a radio bearer. The terminal device 110 may be configured to have at least one data radio bearer (DRB) for carrying data plane data and at least one signaling radio bearer (SRB) for carrying control plane data. In the context of the present disclosure, the DRB may be configured to support transmission in an inactive state (i.e., to support SDT). Of course, the DRB may be configured to not support transmission in an inactive state (i.e., to not support SDT). The SRB may be configured to support SDT. Of course, the SRB may be configured to not support SDT.
[0050] In the RRC layer, three types of SRBs are defined: SRB0, SRB1 and SRB2. SRB0 uses CCCH to establish, resume or re-establish an RRC connection. SRB1 uses DCCH and is established when an RRC connection is established. SRB2 uses DCCH and is established during RRC re-configuration and after the first security activation.
[0051] Additionally, a Protocol Data Unit (PDU) session may be established in the NAS layer of the terminal device 110 to transmit data to the CN and receive data from the CN. The PDU session may correspond to an SDAP entity and may include multiple Quality of Service (QoS) flows. In the context of the present disclosure, the QoS flows may be configured to support the SDT. Of course, the QoS flows may be configured not to support the SDT.
[0052] In the context of the present disclosure, a terminal device 110 in an inactive state may communicate with a network device 120. In some scenarios, the terminal device 110 may initiate an SDT procedure when the terminal device 110 has a small amount of infrequent data traffic from a radio bearer supporting SDT to transmit. FIG. 2A is a schematic diagram illustrating a one-time SDT procedure 200A capable of implementing some embodiments of the present disclosure. As shown in FIG. 2A, the terminal device 110 in an inactive state may transmit an RRC resume request together with UL data associated with the data traffic to the network device 120 (201). For example, the terminal device 110 may transmit the RRC resume request together with the UL data in MsgA of a two-step random access procedure or Msg3 of a four-step random access procedure. Of course, the terminal device 110 may also transmit the RRC resume request together with the UL data in a configuration grant (CG) resource. The RRC resume request may include a resume cause. Upon receiving the RRC resumption request and the UL data, the network device 120 may send an RRC release message to the terminal device 110 together with DL data corresponding to the UL data (202). For example, the network device 120 may send the RRC release message together with the DL data in MsgB of a two-step random access procedure or Msg4 of a four-step random access procedure. The network device 120 may also send the RRC release message together with the DL data in response to the transmission on the CG resource. At this point, the SDT procedure 200A ends.
[0053] FIG. 2B is a schematic diagram illustrating an SDT procedure 200B including an initial transmission and subsequent transmissions, in which some embodiments of the present disclosure can be implemented. As shown in FIG. 2B, the terminal device 110 in an inactive state may transmit an RRC resume request together with UL data and a BSR to the network device 120 (211). For example, the terminal device 110 may transmit the RRC resume request together with the UL data and a BSR in MsgA of a two-step random access procedure or Msg3 of a four-step random access procedure. Of course, the terminal device 110 may also transmit the RRC resume request together with the UL data in a configuration grant (CG) resource. The RRC resume request may include a resume cause. Upon receiving the RRC resume request together with the UL data and a BSR, the network device 120 may transmit an indication of a subsequent transmission to the terminal device 110 (212). For example, the network device 120 may transmit an explicit RRC message indicating a subsequent transmission. As another example, the network device 120 may transmit a UL grant for another transmission to implicitly indicate a subsequent transmission. In some embodiments, the network device 120 may transmit DL data with an indication to the terminal device 110. At this point, the first transmission is complete.
[0054] Based on this indication, the terminal device 110 may transmit another UL data and a BSR to the network device 120, for example, based on a dynamic grant or a configuration grant (213). The network device 120 may then transmit a UL grant for the dynamic grant to the terminal device 110 (214). In some embodiments, the network device 120 may transmit DL data to the terminal device 110 along with the UL grant. Based on the UL grant from the network device 120, the terminal device 110 may transmit the remaining UL data to the network device 120 (215). Thus, the network device 120 may transmit an RRC release message to the terminal device 110 (216). At this point, the subsequent transmission is complete; that is, the SDT procedure 200B ends. It should be understood that the SDT procedure 200B may include more or fewer steps in the subsequent transmission. Example of implementation for handling RRC rejection during SDT
[0055] As described above, during an SDT procedure, the terminal device 110 in an inactive state may transmit UL data together with an RRC resume request message to the network device 120. The network device 120 may respond with an RRC reject message to the terminal device 110, for example, due to network congestion. However, the behavior of the terminal device 110 upon receiving the RRC reject message is unclear. In view of this, an embodiment of the present disclosure proposes an appropriate behavior to be performed by the terminal device 110 upon or after receiving an RRC reject message during an SDT procedure.
[0056] FIG. 3 is a schematic diagram illustrating a process 300 for communication according to an embodiment of the present disclosure. For illustrative purposes, the process 300 will be described with reference to FIG. 1A. The process 300 may involve a terminal device 110 and a network device 120 as shown in FIG. 1A. The network device 120 may be a last serving network device for the terminal device 110 or a new network device. When the terminal device 110 is performing a first RRC resumption procedure initiated for SDT, one connection rejection message, e.g., an RRC rejection message, may be received from the network device 120. After receiving the RRC rejection message, the terminal device 110 may terminate the SDT procedure, remain in an inactive state, and initiate a second RRC resumption procedure.
[0057] As shown in FIG. 3, the terminal device 110 is performing a first RRC resumption procedure initiated for SDT and receives a connection rejection message, such as an RRC rejection message, from the network device 120 (310). In some embodiments, after receiving the RRC rejection message, the terminal device 110 discards buffered packets in the PDCP entity and the RLC entity of the radio bearer configured to have the SDT (311). For example, the terminal device 110 may perform PDCP SDU discarding for the SRB configured to have the SDT, where the buffered PDCP SDUs and PDCP PDUs are discarded. As another example, the terminal device 110 may perform RLC re-establishment for the radio bearer configured to have the SDT. In this way, the buffered data can be discarded before the subsequent second RRC resumption procedure, so that the terminal device 110 can obtain an accurate amount of data for determining whether an SDT procedure can be triggered for the second RRC resumption procedure.
[0058] Currently, during a MAC reset procedure, all time alignment timers are considered to have expired. When the alignment timer for the SDT expires, the terminal device should discard the configured grant resources for the SDT. In some embodiments, after receiving an RRC reject message, the terminal device 110 performs a MAC reset procedure (312), and the configured grant resources for the SDT are maintained during the MAC reset procedure. For example, during a MAC reset procedure, the terminal device 110 considers all time alignment timers to have expired. However, the terminal device 110 maintains the configured grants used for the SDT upon expiration of the time alignment timer. In other words, upon expiration of the time alignment timer, the terminal device 110 discards only the configured grants that are not configured for the SDT. As another example, during a MAC reset procedure, the terminal device 110 maintains the time alignment timer for the SDT, in other words, the terminal device 110 does not consider the time alignment timer to have expired. Thus, the configured grant resources for SDT can be maintained and used for the second RRC resumption procedure.
[0059] If a second RRC resumption procedure is initiated in the same cell, the same security keys will be generated and the terminal device 110 may encrypt different packets using the same security keys and the same PDCP count value, which is called the security key stream reuse problem, which is not allowed.
[0060] In some embodiments, a horizontal security key change may be performed by the terminal device 110 to avoid the security key stream reuse problem. In some embodiments, after receiving an RRC reject message from the network device 120 during one SDT procedure, the terminal device 110 initiates a second RRC resumption procedure (320). For example, the second RRC resumption procedure may be an SDT procedure or a conventional RRC resumption procedure. In some embodiments, the terminal device 110 performs a horizontal key derivation (321) to obtain a key used in the second RRC resumption procedure. In this way, the security key used in the second RRC resumption procedure is different from the first RRC resumption procedure, and the security key stream reuse problem is solved.
[0061] In some embodiments, during the second RRC restart procedure, the terminal device 110 transmits (322) buffered / old data in the PDCP entity. For example, when performing PDCP re-establishment for an SRB configured to have an SDT, the terminal device 110 maintains PDCP SDUs in the PDCP entity. In other words, during the second RRC restart procedure, PDCP SDUs are not discarded during PDCP re-establishment for an SRB configured to have an SDT. Buffered PDCP PDUs for the SRB are transmitted during the second RRC restart procedure. As another example, for a UM DRB configured to have an SDT, the terminal device 110 performs transmission of PDCP SDUs that have already been submitted to lower layers (e.g., RLC, MAC, PHY layers) before during PDCP re-establishment of the second RRC restart procedure. In other words, for a UM DRB configured to have an SDT, not only PDCP SDUs that have not been submitted to lower layers before but also PDUs that have already been submitted to lower layers before are transmitted during PDCP re-establishment of the second RRC restart procedure. In this way, buffered data that cannot be successfully transmitted during the first RRC resumption procedure for SDT can be retransmitted during the second RRC resumption procedure.
[0062] In some embodiments, to avoid security stream reuse issues, the terminal device 110 may initiate an RRC setup procedure, or the second RRC resumption procedure initiated by the terminal device 110 should be a conventional RRC resumption procedure. In some embodiments, after receiving an RRC reject message from the network device 120 during one SDT procedure, the terminal device 110 should avoid initiating a second RRC resumption procedure that generates the same security key and the same PDCP count value (used in the previous SDT procedure) to encrypt different packets (331). For example, if the terminal device 110 determines that different PDCP packets are transmitted using the same PDCP count value and the same security key used in the previous SDT procedure, the terminal device 110 transitions to an IDLE state and initiates one RRC setup procedure. As another example, if the terminal device 110 determines that PDCP packets are transmitted using the same PDCP count value and the same security key used in the previous SDT procedure, the terminal device 110 initiates a conventional RRC resumption procedure, which means that there is no UL data transmitted with the RRC resumption request message. The network device 120 sends an RRC setup message to the terminal device (332). Alternatively, the network device 120 sends an RRC resume message including a key update setting (332). In this way, the security key stream reuse problem can be solved. Example of implementation of RRC rejection handling in response to non-SDT indication
[0063] 4 is a schematic diagram illustrating a process 400 for communication according to an embodiment of the present disclosure. For illustrative purposes, the process 400 will be described with reference to FIG. 1A. The process 400 may involve a terminal device 110 and a network device 120 as shown in FIG. 1A. The network device 120 may be a last serving network device for the terminal device 110 or a new network device.
[0064] As shown in FIG. 4, at the initialization of one SDT procedure, the terminal device 110 starts a timer for detecting failure of the SDT procedure. During the SDT procedure, new uplink data from a radio bearer that does not support SDT (i.e., non-SDT data) may arrive. The terminal device 110 may send a message to the network device 120 using SRB1 to indicate the arrival of the non-SDT data (410). The network device 120 may send an RRC reject message to the terminal device 110 (420). Upon receiving the RRC reject message, the terminal device 110 continues the SDT procedure (430). In some embodiments, upon receiving the RRC reject message, the terminal device 110 determines whether the timer for SDT is running. If the timer is not running, the terminal device 110 resets the MAC, releases the default MAC cell group configuration, revokes security keys, suspends SRB1, and notifies the upper layer of the failure to resume the RRC connection. If the timer is running, the terminal device 110 notifies higher layers of an RRC connection resumption failure, where the RRC connection resumption failure corresponds to non-SDT data.
[0065] Thus, in response to a non-SDT data arrival indication, an ongoing SDT will not be interrupted due to receipt of an RRC reject message, and data loss and service interruption can be avoided. Example of how to handle the situation when there is no valid CG-SDT resource
[0066] Currently, at least one synchronization signal block (SSB) is associated with one CG resource for SDT. If the synchronization signal reference signal received power (SS-RSRP) of at least one SSB associated with the CG resource for SDT is above a threshold after the CG-SDT procedure is triggered, the terminal device 110 considers that there is a qualified configuration grant to be used for the SDT procedure. Otherwise, it means that there is no qualified configuration grant to be used for SDT. If the terminal device 110 initiates a random access (RA) procedure every time it determines that there is no qualified configuration grant, frequent triggering of the random access procedure occurs. In an embodiment of the present disclosure, a solution is provided on how to avoid this frequent RA triggering.
[0067] In some embodiments, the terminal device 110 determines that there is no SSB associated with a CG resource for SDT that is above a threshold, and determines that a BSR is triggered, and the terminal device 110 initiates a random access procedure. In some embodiments, the terminal device 110 determines that there is no SSB associated with a CG resource for SDT that is above a threshold, and determines that there is buffered data to transmit, and the terminal device 110 initiates a random access procedure. In this way, it is not necessary to trigger a random access procedure every time it determines that there is no eligible CG resource for SDT. During a CG-SDT procedure, a conventional time alignment timer (i.e., a time alignment timer other than that used for SDT) has expired and is not running. In some embodiments, during a CG-SDT procedure, the terminal device 110 receives an RRC resume message or an RRC setup message from a network device. The RRC layer of the terminal device 110 should indicate to the MAC layer of the terminal device 110 to start or restart the conventional time alignment timer. When the MAC layer of the terminal device 110 receives an indication from the RRC layer of the terminal device 110 that the terminal device 110 should start or restart a conventional time alignment timer, the conventional time alignment timer can then start running for the terminal device in a connected state. Example of the method
[0068] Therefore, embodiments of the present disclosure provide communication methods implemented in a terminal device, which are described below with reference to Figures 5 to 7.
[0069] 5 illustrates an example communication method 500 implemented in a terminal device, according to some embodiments of the present disclosure. For example, the method 500 may be performed in a terminal device 110 as shown in FIG. 1A. For purposes of explanation, the method 500 is described below with reference to FIG. 1A. It should be understood that the method 500 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the present disclosure is not limited in this respect.
[0070] In block 510, when the terminal device 110 is performing a first connection resumption procedure initiated for the SDT, the terminal device 110 receives a connection rejection message from the network device 120. In some embodiments, in response to receiving the connection rejection message, the terminal device 110 discards buffered packets for radio bearers configured to have the SDT. In some embodiments, the terminal device 110 performs PDCP SDU discarding for SRBs configured to have the SDT. In some embodiments, in response to receiving the connection rejection message, the terminal device 110 performs a MAC reset procedure, and configured grant resources for the SDT are maintained during the MAC reset procedure.
[0071] In block 520, the terminal device 120 initiates a second connection resumption procedure. In some embodiments, the terminal device performs horizontal key derivation to obtain a security key to be used during the second connection resumption procedure. In some embodiments, the terminal device 110 transmits buffered packets in the PDCP entity for radio bearers configured with SDT. In some embodiments, the terminal device 110 maintains PDCP SDUs for SRBs configured with SDT during the PDCP re-establishment procedure. In some embodiments, the terminal device 110 performs transmission of PDCP SDUs for UM DRBs configured with SDT (unacknowledged mode) that were previously submitted to lower layers. In some embodiments, the terminal device 110 determines that different packets may be transmitted using the same security key and the same PDCP count value used in the first connection resumption procedure initiated for SDT, and enters an idle state to initiate a connection establishment procedure or initiates a second connection resumption procedure with no UL data transmitted during the inactive state.
[0072] 6 illustrates an example communication method 600 implemented in a terminal device, according to some embodiments of the present disclosure. For example, the method 600 may be performed in a terminal device 110 as shown in FIG. 1A. For purposes of explanation, the method 600 will be described below with reference to FIG. 1A. It should be understood that the method 600 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the present disclosure is not limited in this respect.
[0073] In block 610, while executing a small data transmission (SDT) procedure, the terminal device 110 transmits a message to the network device 120 on SRB1 indicating the arrival of non-SDT data, and in response to receiving a connection rejection message from the network device, the terminal device 110 continues the SDT transmission.
[0074] 7 illustrates an example communication method 700 implemented in a network device according to some embodiments of the present disclosure. For example, method 700 may be performed in network device 120 as shown in FIG. 1A. For purposes of explanation, method 700 will be described below with reference to FIG. 1A. It should be understood that method 700 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the present disclosure is not limited in this respect.
[0075] In block 710, the network device 120 sends a connection rejection message to the terminal device 110 in response to a first connection resumption procedure initiated for an SDT, receives a connection resumption request message for a second connection resumption procedure not initiated for an SDT, and sends a connection establishment message.
[0076] 8 illustrates an example communication method 800 implemented in a terminal device, according to some embodiments of the present disclosure. For example, the method 800 may be performed in a network device 120 as shown in FIG. 1A. For purposes of explanation, the method 800 will be described below with reference to FIG. 1A. It should be understood that the method 800 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the present disclosure is not limited in this respect.
[0077] In block 810, the terminal device 110 initiates a configured grant-based SDT procedure, determines that there is no SSB associated with the configured grant resources for SDT that exceed a threshold, determines that a buffer status report (BSR) has been triggered or that there is buffered data to transmit, and initiates a random access procedure. Device implementation examples
[0078] 9 is a schematic block diagram of an apparatus 900 suitable for implementing embodiments of the present disclosure. The apparatus 900 may be considered as another exemplary implementation of the terminal device 110 or the network device 120 as shown in FIG. 1. Thus, the apparatus 900 may be implemented in or as at least a part of the terminal device 110 or the network device 120 or 130.
[0079] As shown, the apparatus 900 comprises a processor 910, a memory 920 coupled to the processor 910, a suitable transmitter (TX) and receiver (RX) 940 coupled to the processor 910, and a communication interface coupled to the TX / RX 940. The memory 910 stores at least a portion of a program 930. The TX / RX 940 is used for bidirectional communication. The TX / RX 940 has at least one antenna to facilitate communication, although the access nodes referred to herein may in practice have multiple antennas. The communication interface may represent any interface required for communication with other network elements, such as an X2 / Xn interface for bidirectional communication between eNBs / gNBs, an S1 / NG interface for communication between a Mobility Management Entity (MME) / Access and Mobility Management Function (AMF) / SGW / UPF and an eNB / gNB, an Un interface for communication between an eNB / gNB and a Relay Node (RN), or a Uu interface for communication between an eNB / gNB and a terminal device.
[0080] The program 930 is assumed to include program instructions that, when executed by an associated processor 910, enable the device 900 to operate according to embodiments of the present disclosure, as described herein with reference to Figures 1-8. The embodiments of the present disclosure may be realized by computer software executable by the processor 910 of the device 900, or by hardware, or by a combination of software and hardware. The processor 910 may be configured to implement various embodiments of the present disclosure. Furthermore, the combination of the processor 910 and the memory 920 may form a processing means 950 suitable for implementing various embodiments of the present disclosure.
[0081] The memory 920 may be of any type suitable for a local technology network and may be implemented using any suitable data storage technology, such as, by way of non-limiting example, non-transitory computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. Although only one memory 920 is shown in the device 900, there may be several physically different memory modules in the device 900. The processor 910 may be of any type suitable for a local technology network and may include, by way of non-limiting example, one or more of a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP) and a processor based on a multi-core processor architecture. The device 800 may have multiple processors, for example application specific integrated circuit chips time-slaved to a clock that synchronizes the main processor.
[0082] In some embodiments, the circuitry comprises circuitry configured to receive a connection rejection message from the network device and initiate a second connection resumption procedure when the terminal device is performing a first connection resumption procedure initiated for SDT.
[0083] In some embodiments, the circuitry may be further configured to discard buffered packets for a radio bearer configured to have an SDT in response to receiving a connection reject message.
[0084] In some embodiments, the circuitry may be further configured to perform PDCP SDU discarding for signaling radio bearers configured to have an SDT.
[0085] In some embodiments, the circuitry may be further configured to, in response to receiving a connection rejection message, perform a MAC reset procedure and maintain configured grant resources for an SDT during the MAC reset procedure.
[0086] In some embodiments, the circuitry may be further configured to initiate a second connection resumption procedure by performing a horizontal key derivation to obtain a security key.
[0087] In some embodiments, the circuitry may be further configured to initiate the second connection resumption procedure and transmit buffered packets within a PDCP entity for a radio bearer configured to have an SDT.
[0088] In some embodiments, the circuitry may be further configured to maintain PDCP SDUs for an SRB configured to have an SDT during a PDCP re-establishment procedure, or to perform transmission of PDCP SDUs that have already been previously submitted to a lower layer for an UM DRB configured to have an SDT.
[0089] In some embodiments, the circuitry may be further configured to determine that different packets may be sent using the same security key and the same PDCP count value used in the first connection resumption procedure initiated for SDT, and perform at least one of: entering an idle state and initiating a connection establishment procedure, or initiating a second connection resumption procedure without UL data being transmitted during the inactive state.
[0090] In some embodiments, the terminal device comprises circuitry configured to, when performing an SDT procedure, send a message to a network device on SRB1 indicating arrival of non-SDT data, receive a connection rejection message from the network device, and continue the SDT transmission.
[0091] In some embodiments, the circuitry may be further configured to determine that one timer for SDT failure detection is running and to notify higher layers of a failure to re-start the RRC connection.
[0092] In some embodiments, the network device comprises a circuit, the circuit being configured in the network device to send a connection rejection message to the terminal device in response to a first connection resumption procedure initiated for the SDT, receive a connection resumption request message for a second connection resumption procedure not initiated for the SDT, and send a connection establishment message.
[0093] In some embodiments, a terminal device comprises circuitry configured to initiate a configuration grant-based SDT procedure in the terminal device, determine that there is no SSB associated with a configured grant resource for SDT that exceeds a threshold, determine that a buffer status report (BSR) has been triggered or that there is buffered data to be transmitted, and initiate a random access procedure.
[0094] The term "circuitry" as used herein may refer to a hardware circuit and / or a combination of a hardware circuit and software. For example, a circuit may be a combination of analog and / or digital hardware circuitry and software / firmware. As yet another example, a circuit may be any portion of a hardware processor having software, including a digital signal processor, software, and one or more memories, that cooperate to cause a device, such as a terminal device or a network device, to perform various functions. In yet another example, a circuit may be a hardware circuit and / or a processor, such as a microprocessor or a portion thereof, that requires software / firmware for operation, but the software may not be present if not required for operation. As used herein, the term "circuitry" also includes an implementation of only a hardware circuit or one or more processors, or a portion of a hardware circuit or one or more processors and its (or their) associated software and / or firmware.
[0095] Overall, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure have been illustrated and described using block diagrams, flow charts, or some other pictorial representations, it should be understood that the blocks, devices, systems, techniques, or methods described herein may be implemented, by way of non-limiting examples, in hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing device, or any combination thereof.
[0096] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in a program module, that execute in a device on a target real or virtual processor to perform a process or method as described above with reference to Figures 1-10. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or split between program modules as appropriate. The machine-executable instructions of the program modules may be executed in local or distributed devices. In a distributed device, the program modules may be located in both local and remote storage media.
[0097] Program codes for carrying out the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, a special purpose computer, or other programmable data processing device, and when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may run entirely on the machine, partially on the machine, as a separate software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.
[0098] The above program code may be implemented on a machine-readable medium, which may be any tangible medium that can contain or store a program used by or associated with an instruction execution system, device, or apparatus. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination of the aforementioned media. More specific examples of the machine-readable storage medium may include an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the aforementioned.
[0099] It should be noted that although operations have been described in a particular order, it should not be understood that such operations need to be performed in the particular order shown, or in any sequential order, or that all of the operations described must be performed in order to achieve desired results. In some cases, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure, but rather as descriptions of features that may be specific to certain embodiments. Some features described in the context of individual embodiments may be realized in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented separately in multiple embodiments or in any suitable subcombination.
[0100] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it should be understood that the present disclosure, as defined in the appended claims, is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Claims
1. 1. A method of communication comprising: receiving, in a terminal device, a connection rejection message from a network device when the terminal device is performing a first connection resumption procedure initiated for Small Data Transmission (SDT); initiating a second connection resumption procedure; and The method includes:
2. in response to receiving the connection rejection message, discarding buffered packets for a radio bearer configured to have the SDT; The method of claim 1 further comprising:
3. Discarding the buffered packets comprises: performing Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) discarding for a Signaling Radio Bearer (SRB) configured to have the SDT; 3. The method of claim 2 comprising:
4. In response to receiving the connection rejection message, performing a Medium Access Control (MAC) reset procedure; and maintaining configured grant resources for the SDT during the MAC reset procedure; The method of claim 1 further comprising:
5. Initiating the second connection resumption procedure comprises: performing a horizontal key derivation to obtain a security key; The method of claim 1 further comprising:
6. transmitting buffered packets in a PDCP entity of a radio bearer configured with the SDT during the second connection resumption procedure; The method of claim 1 further comprising:
7. maintaining PDCP SDUs for SRBs configured to have said SDT during a PDCP re-establishment procedure; or performing a transmission of the PDCP SDUs that have already been previously submitted to lower layers for Unacknowledged Mode (UM) data radio bearers (DRBs) configured with the SDT; Further comprising at least one of The method according to claim 6.
8. determining that there are different packets sent using the same security key and the same PDCP count value used in the first connection resumption procedure initiated for the SDT; Initiating the second connection resumption procedure includes initiating the second connection resumption procedure having no uplink (UL) data transmitted during an inactive state. The method of claim 1.
9. 1. A method of communication comprising: sending, in the terminal device, a message indicating arrival of non-SDT data to the network device on SRB1 when performing a Small Data Transmission (SDT) procedure; continuing the SDT procedure in response to receiving a connection rejection message from the network device; The method includes:
10. determining that a timer for SDT failure detection is running; notifying higher layers of a failure to resume the RRC connection for non-SDT data; The method of claim 9 further comprising:
11. 1. A method of communication comprising: sending, in the network device, a connection rejection message to the terminal device in response to a first connection resumption procedure initiated for Small Data Transmission (SDT); receiving a connection resumption request message for a second connection resumption procedure not initiated for the SDT; sending a connection establishment message; The method includes:
12. 1. A method of communication comprising: Initiating a Configured Grant based SDT (CG-SDT) procedure in a terminal device; determining that no Synchronization Signal Block (SSB) associated with the configured grant resource for Small Data Transmission (SDT) is above a threshold; determining that a Buffer Status Report (BSR) has been triggered or that there is buffered data to be transmitted; initiating a random access procedure; The method includes:
13. A processor configured to carry out the method according to any one of claims 1 to 10 and 12, Terminal device.
14. A processor configured to perform the method of claim 11. Network device.
15. storing instructions which, when executed on at least one processor, cause said at least one processor to perform a method according to any one of claims 1 to 10 and 12; Computer-readable medium.
16. storing instructions that, when executed on at least one processor, cause the at least one processor to perform the method of claim 11; Computer-readable medium.