User device and method for user device

Abstract

The embodiments of the present disclosure relate to a communication method, an apparatus, and a computer-readable medium. A terminal device determines whether a radio link control (RLC) entity re-establishment is to be performed for a radio bearer configured to have data transmission in an inactive state. If it is determined that the RLC entity re-establishment is to be performed, the terminal device re-establishes the RLC entity. Then, the terminal device transmits uplink data in an inactive state on the radio bearer. In this way, it is possible to process the RLC entity re-establishment for a radio bearer configured to have an SDT if the terminal device determines that the RLC entity re-establishment needs to be performed for the SDT, thereby improving the performance of the SDT procedure.

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: determining, in a terminal device, whether a Radio Link Control (RLC) entity re-establishment is performed for a radio bearer configured to have data transmission in an inactive state, re-establishing an RLC entity according to a determination that the RLC entity re-establishment is performed, and transmitting uplink data on the radio bearer in the inactive state to a network device.

[0006] In a second aspect, a method of communications is provided, the method including, in response to receiving uplink data and a Radio Resource Control (RRC) resume request message from a terminal device in an inactive state, transmitting to the terminal device a Radio Link Control (RRC) resume message including an indication for RLC entity re-establishment for radio bearers not configured with data transmission in an inactive state.

[0007] In a third aspect, a method of communication is provided, the method including, in a terminal device performing transmission of uplink data in an inactive state, performing at least one of: determining whether on-demand information is available or not, and triggering transmission of a request for the on-demand information to a network device or avoiding transmission of the request for the on-demand information to the network device according to a determination that the on-demand information is unavailable.

[0008] In a fourth aspect, a method of communication is provided, comprising: in a terminal device, suspending transmission of uplink data in an inactive state in response to at least one of receiving a paging message addressed to the terminal device from the network device, receiving a connection establishment interrupt from a non-access stratum layer in a radio resource control (RRC) layer of the terminal device, expiry of a first timer associated with transmission of the uplink data in the inactive state, reaching a maximum number of radio link control (RLC) retransmissions, a predetermined number of failures in a first uplink data transmission, and a media access control (MAC) layer of the terminal device providing an instruction to cancel transmission of the uplink data in the inactive state to the RRC layer.

[0009] In a fifth aspect, a method of communication is provided, the method including: determining, in a terminal device, a parameter of a Message Authentication Code Integrity (MAC-I) for an RRC resumption procedure based on a first value associated with the RRC resumption procedure, and transmitting an RRC Resumption Request message including the parameter to initiate the RRC resumption procedure, the first value being different from a second value for determining a MAC-I for another RRC resumption procedure.

[0010] In a sixth aspect, a method of communication is provided, the method including: triggering, in a terminal device, a power headroom report (PHR), determining whether an uplink grant accepts the uplink data and does not accept the PHR as an addition according to a determination that the uplink data is transmitted in an inactive state, allocating resources to the uplink data according to a determination that the uplink grant accepts the uplink data and does not accept the PHR as an addition, and transmitting the uplink data to a network device using the allocated resources.

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

[0012] In an eighth aspect, a network device is provided, the 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 second aspect of the present disclosure.

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

[0014] In a tenth 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 second aspect of the present disclosure.

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

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

[0017] [Figure 1A] FIG. 1 illustrates an example communication network in which some embodiments of the present disclosure may be implemented. [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. [Figure 1C] FIG. 2 is a schematic diagram illustrating a control plane (CP) protocol stack in which some embodiments of the present disclosure may be implemented. [Figure 2A] FIG. 1 is a schematic diagram illustrating an SDT procedure in which some embodiments of the present disclosure can be implemented. [Figure 2B] FIG. 2 is a schematic diagram illustrating an SDT procedure including an initial data transmission phase and a subsequent data transmission phase, in which some embodiments of the present disclosure can be implemented. [Diagram 3] FIG. 2 illustrates a signaling flow for an SDT procedure in accordance with some embodiments of the present disclosure. [Figure 4] FIG. 2 illustrates a signaling flow for an SDT procedure in accordance with some embodiments of the present disclosure. [Diagram 5] FIG. 2 illustrates a signaling flow for an SDT procedure in accordance with some embodiments of the present disclosure. [Figure 6] FIG. 2 illustrates a signaling flow for an SDT procedure in accordance with some embodiments of the present disclosure. [Figure 7] FIG. 2 illustrates a signaling flow for an SDT procedure in accordance with some embodiments of the present disclosure. [Figure 8] FIG. 2 illustrates an exemplary communication method implemented in a terminal device according to some embodiments of the present disclosure. [Figure 9] FIG. 2 illustrates another exemplary communication method implemented in a network device, in accordance with some embodiments of the present disclosure. [Figure 10] FIG. 1 illustrates another exemplary communication method implemented in a terminal device in accordance with some embodiments of the present disclosure. [Figure 11] FIG. 1 illustrates another exemplary communication method implemented in a terminal device in accordance with some embodiments of the present disclosure. [Figure 12] FIG. 1 illustrates another exemplary communication method implemented in a terminal device in accordance with some embodiments of the present disclosure. [Figure 13] FIG. 1 illustrates another exemplary communication method implemented in a terminal device in accordance with some embodiments of the present disclosure. [Figure 14] FIG. 1 is a schematic block diagram of an apparatus suitable for implementing embodiments of the present disclosure.

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

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

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

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

[0022] 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 to the terminal device from at least one of the first network device or the second network device. In one embodiment, the first information may be transmitted to the terminal device from the first network device, and the second information may be transmitted to the terminal device from the second network 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 to the terminal device directly from the second network device or via the first network device.

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

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

[0025] Example of communication environment 1A illustrates an example communication system 100A in which some embodiments of the present disclosure may be implemented. The communication system 100A, which is part of a communication network, includes terminal devices 110-1, 110-2, ..., 110-N, which may be collectively referred to as "terminal devices 110." The number N may be any suitable integer.

[0026] The communication system 100A further includes a network device 120. In some embodiments, the network device 120 may be a gNB. Alternatively, the network device 120 may be an IAB. Although not shown, there may be two or more network devices 120 in the communication system 100A.

[0027] In the communication system 100A, the network devices 120 and the terminal devices 110 may communicate data and control information with each other. The number of terminal devices 110 and network devices 120 shown in FIG. 1 is shown for illustrative purposes only and does not imply any limitation.

[0028] As shown in FIG. 1A, terminal device 110 may communicate with network device 120 via a channel, such as a wireless communication channel. Communications in communication network 100A may conform to any suitable standard, including, but not limited to, Global System for Mobile Communications (GSM), Long Term Evolution (LTE), LTE-Evolution, LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), GSM EDGE Radio Access Network (GERAN), Machine Type Communications (MTC), and the like. Furthermore, communications may be performed according to any generation of communications protocols now known or developed in the future. Examples of communications protocols include, but are not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, and fifth generation (5G) communications protocols.

[0029] Communications in the direction from the terminal device 110 to the network device 120 are referred to as UL communications, and communications in the direction from the network device 120 to the terminal device 110 are referred to as DL communications. The terminal device 110 may move between cells of the network device 120 and possibly other network devices. In UL communications, the terminal device 110 may transmit UL data (e.g., data transmitted using a data radio bearer (DRB) and / or data transmitted using a signaling radio bearer (SRB)) to the network device 120 via a UL channel. In DL communications, the network device 120 may transmit DL data to the terminal device 110 via a DL channel.

[0030] Communications in the communication network 100A may be performed according to the UP and CP protocol stacks. Generally speaking, for a communication device (e.g., a terminal device 110 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.

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

[0032] 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 higher 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 be further referred to as an access stratum (AS) layer, and therefore the RRC entity may be further 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 form a stack structure.

[0033] Generally, communication channels are divided into logical channels, transmission channels, and physical channels. Physical channels are channels through which the PHY layer actually transmits information. For example, physical channels may include a physical uplink control channel (PUCCH), a physical uplink shared channel (PUSCH), a physical random-access channel (PRACH), a physical downlink control channel (PDCCH), a physical downlink shared channel (PDSCH), and a physical broadcast channel (PBCH).

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

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

[0036] In general, a channel between the RRC layer and the PDCP layer or between the SDAP layer and the PDCP layer is referred to as a radio bearer. The terminal device 110 may be configured to have at least one DRB for carrying data plane data and at least one SRB for carrying control plane data. In the context of the present disclosure, the DRB may be configured to support transmission in an inactive state (i.e., to support SDT). Of course, the DRB may be configured not to support transmission in an inactive state. The SRB may be configured to support transmission in an inactive state. Of course, the SRB may be configured not to support transmission in an inactive state.

[0037] In the RRC layer, three types of SRBs are defined: SRB0, SRB1 and SRB2. SRB0 uses CCCH for establishing or re-establishing 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.

[0038] As mentioned above, 3GPP Release 17 approves small data transmission (SDT) in inactive state. There are various applications that exchange small amount and infrequently data. For example, in some applications of 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 periodic location information, for example), etc. In some applications of 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.

[0039] In the context of the present disclosure, terminal device 110 in an inactive state may communicate with network device 120. In some embodiments, for example, terminal device 110 may enter the inactive state upon receiving an RRC Release with suspendConfig.

[0040] In some scenarios, when the terminal device 110 has small and infrequent data traffic from a radio bearer that supports transmission in an inactive state to transmit, the terminal device 110 may initiate an SDT procedure. Whether a radio bearer supports transmission in an inactive state is configured by the network device 120 or other network devices.

[0041] FIG. 2A is a schematic diagram illustrating a one-time SDT procedure in which some embodiments of the present disclosure can be implemented. The procedure illustrated in FIG. 2A includes only an initial data transmission phase. As illustrated in FIG. 2A, a terminal device 110 in an inactive state may transmit an RRC Resume Request message to a network device 120 together with UL data associated with data traffic (i.e., uplink data, e.g., data transmitted using an SRB or DRB configured to have an SDT) (201). For example, the terminal device 110 may transmit the RRC Resume Request message together with the UL data in Msg A of a two-step RACH procedure or Msg 3 of a four-step RACH procedure. Of course, the terminal device 110 may also transmit the RRC Resume Request message together with the UL data in a configured grant (CG) resource. The RRC Resume Request message may include a recovery MAC-I.

[0042] Upon receiving the RRC Resume Request message 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 Msg B of a two-step RACH procedure or Msg4 of a four-step RACH procedure. The network device 120 may also send the RRC Release message together with the DL data in response to the transmission on the CG resource. The SDT procedure 200A then ends.

[0043] FIG. 2B is a schematic diagram illustrating an SDT procedure 200B including a first data transmission phase and a subsequent data transmission phase, in which some embodiments of the present disclosure can be implemented. As shown in FIG. 2, the terminal device 110 in an inactive state may send an RRC Resume Request message together with UL data and a buffer status report (BSR) to the network device 120 (211). For example, the terminal device 110 may send the RRC Resume Request message together with UL data and a BSR in Msg A of a two-step RACH procedure or Msg 3 of a four-step RACH procedure. Of course, the terminal device 110 may also send the RRC Resume Request message together with UL data in a configured grant (CG) resource. The RRC Resume Request message may include a recovery MAC-I.

[0044] Upon receiving the RRC resume request message with the UL data and BSR, network device 120 may send an indication of a subsequent data transmission to terminal device 110 (212). For example, network device 120 may send an explicit RRC message indicating the subsequent data transmission. As another example, network device 120 may send an uplink grant (UL grant) for another transmission to implicitly indicate the subsequent data transmission. In some embodiments, network device 120 may also send DL data along with the indication to terminal device 110. At this point, the initial data transmission is complete.

[0045] Based on the indication, terminal device 110 may send (213) other UL data and a BSR to network device 120, e.g., based on a dynamic or configured grant. Network device 120 may then send (214) a UL grant for the dynamic grant to terminal device 110. In some embodiments, network device 120 may send DL data to terminal device 110 along with the UL grant.

[0046] Based on the UL authorization from the network device 120, the terminal device 110 may transmit the remaining UL data to the network device 120 (215). Accordingly, the network device 120 may transmit an RRC release message to the terminal device 110 (216). At this point, the subsequent data transmission is completed; 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 data transmission, and the scope of protection of the present disclosure is not limited in this respect.

[0047] In the above, possible SDT procedures are illustrated with reference to Figures 2A and 2B. In the following, some specific scenarios related to SDT are introduced.

[0048] It should be understood that throughout this disclosure, the term "during the SDT" may be used interchangeably with "a timer for the SDT is running." For example, a timer may be started at the beginning of the SDT.

[0049] However, the inventors of the present disclosure have noticed that there are still some issues to be resolved in certain scenarios (e.g., handling RLC re-establishment for SDT, on-demand SI / PI during SDT, SDT interruption, security issues related to resumeMAC-I calculation, power headroom report (PHR), etc.) to provide a more robust and secure solution for SDT. To address these issues or issues in other potential scenarios, embodiments of the present disclosure provide a communication solution for handling issues during SDT procedures.

[0050] The details of the above problems found for each scenario and the corresponding solutions are introduced in the following sections respectively. Hereinafter, the principles and embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

[0051] Implementation of RLC re-establishment procedure for SDT If higher layers (e.g., RRC) request RLC entity re-establishment, the terminal device 110 may discard all RLC service data units (SDUs), RLC SDU segments, and RLC protocol data units (PDUs) (if any). During the RLC entity re-establishment, all timers are stopped and reset. This process also resets all state variables to their initial values.

[0052] In one example, one of the purposes of the RLC entity re-establishment is to avoid buffered data (e.g., data that is supposed to be transmitted when the terminal device 110 was located in the previous cell) being transmitted in a subsequent data transmission because the buffered data is encrypted using an old key. If the buffered data is transmitted by the terminal device 110 when the terminal device 110 moves to a new cell, an error will occur. Therefore, the buffered data should be discarded and not transmitted.

[0053] reestablishRLC is used to indicate that the RLC needs to be re-established. The network device 120 sets it to true at least whenever the security key used for the radio bearer associated with the RLC entity changes. It is also set to true for SRB2 and DRB at the first reconfiguration during RRC connection restart or after re-establishment.

[0054] However, the inventors of the present disclosure have noticed that the RLC entity re-establishment is performed only if the network device 120 configures the terminal device 110 with RLC re-establishment (i.e., reestablishRLC). However, in the case of SDT, the terminal device 110 will transmit an RRC resume request message together with uplink data (e.g., data transmitted using an SRB or DRB configured to have an SDT) that is directly transmitted as described above with reference to FIG. 2A and FIG. 2B, and at this point, the terminal device 110 has not yet received the configuration (e.g., reestablishRLC) from the network device 120. In other words, the network device 120 is not capable of configuring (e.g., reestablishRLC) at the initialization of the SDT. Therefore, if the RLC re-establishment is not performed for the SDT, problems such as those described above will occur (e.g., old buffered data will be transmitted, which is undesirable). Therefore, the RLC entity re-establishment needs to be performed before or at the start of the SDT.

[0055] In view of this, the embodiment of the present application provides a solution for handling RLC entity re-establishment for SDT. In this solution, the terminal device 110 first determines whether RLC entity re-establishment is performed for a radio bearer configured to have data transmission in an inactive state. Then, if it is determined that RLC entity re-establishment is performed, the terminal device 110 re-establishes the RLC entity. Then, the terminal device 110 transmits uplink data in an inactive state on the radio bearer to the network device 120. In this way, it is possible to handle RLC entity re-establishment for a radio bearer configured to have SDT if the terminal device 110 determines that the RLC entity re-establishment needs to be performed for the SDT, thereby improving the performance of the SDT procedure.

[0056] Reference is now made to Figure 3, which illustrates a signaling flow 300 for an SDT procedure according to some embodiments of the present disclosure. For illustrative purposes, the signaling flow 300 will be described with reference to Figure 1A. The signaling flow 300 involves a terminal device 110 and a network device 120 as shown in Figure 1A.

[0057] 3, the terminal device 110 determines whether an RLC entity re-establishment is to be performed for a radio bearer (310) that is configured to have uplink data transmission in an inactive state (i.e., a radio bearer that is configured to have an SDT).

[0058] In some embodiments, the terminal device 110 may determine whether or not uplink data transmission is performed in an inactive state. If uplink data transmission is performed in an inactive state, the terminal device 110 may determine whether or not RLC entity re-establishment is performed. Thus, for radio bearers configured to have an SDT, RLC re-establishment can be performed implicitly in the terminal device 110, i.e., without an explicit indication of RLC re-establishment to the network.

[0059] In some other embodiments, when an RRC release message is received from the network device 120 and the RRC release message includes an instruction for RLC entity re-establishment for a radio bearer configured to have uplink data transmission in an inactive state, the terminal device 110 may determine that an RLC entity re-establishment is performed. Thus, the network device 120 may configure reestablishRLC for the SDT radio bearer in RRCRelease using suspendConfig, thereby processing the RLC entity re-establishment for the radio bearer configured to have SDT.

[0060] It should be understood that terminal device 110 may also determine that RLC entity re-establishment is performed in another manner, and the scope of the present disclosure is not limited in this respect.

[0061] After determining that RLC entity re-establishment is performed, terminal device 110 may re-establish the RLC entity (320). In some embodiments, when an upper layer (e.g., PDCP, RRC, or NAS) of terminal device 110 requests RLC entity re-establishment, the RLC layer of terminal device 110 may discard all RLC SDUs, RLC SDU segments, and RLC protocol data units (PDUs) (if any). In some other embodiments, during RLC entity re-establishment, terminal device 110 may stop and reset all timers. Alternatively, terminal device 110 may reset all state variables to their initial values. The RLC layer of terminal device 110 may perform other operations to re-establish the RLC entity, and the scope of the disclosure is not limited in this respect.

[0062] Once the RLC entity is re-established, the terminal device 110 transmits (330) uplink data in the inactive state on the radio bearer to the network device 120. In some embodiments, the terminal device 110 may transmit the uplink data in the inactive state using the RA-based or CG-based SDT introduced with reference to Figures 1 and 2.

[0063] In some examples, if the CG-based SDT criteria are met, the terminal device 110 may select the CG-based SDT. Otherwise, if the RA-based SDT criteria are met, the terminal device 110 may select the RA-SDT.

[0064] In such an example, the CG-SDT criterion may be considered to be met if one or more of the following conditions are met: 1) available data amount≦data amount threshold, 2) reference signal received power (RSRP) is equal to or greater than a configured threshold, or 3) CG-based SDT resources are configured and valid on the selected UL carrier. On the other hand, the RA-based SDT criterion may be considered to be met if one or more of the following conditions are met: 1) available data amount≦data amount threshold, 2) RSRP is equal to or greater than a configured threshold, 3) 4-step RA-based SDT resources are configured on the selected UL carrier and the criteria for selecting 4-step RA-based SDT are met, or 2-step RA-based SDT resources are configured on the selected UL carrier and the criteria for selecting 2-step RA-based SDT are met.

[0065] For example, with the above solution, unwanted, buffered, old data is not sent during SDT, providing a more robust SDT solution.

[0066] Conventionally, the network device 120 may send an RRC resume message to the terminal device 110 during SDT to indicate the terminal device 110 to transition to a non-SDT mode. According to a conventional solution, the network device 120 may indicate RLC re-establishment when resuming the RRC connection. However, for an SDT radio bearer, when the network device 120 indicates RLC re-establishment, the buffered RLC packets are cleaned up, which causes packet loss.

[0067] To address the above problem, in some embodiments, when receiving uplink data and a radio resource control (RRC) resume request message from terminal device 110 in an inactive state, network device 120 may send an RRC resume message to terminal device 110. The RRC resume message may include instructions for RLC entity re-establishment for radio bearers that are not configured to have data transmission in the inactive state.

[0068] Upon receiving the RRC resume message from the network device 120, the terminal device 110 may reestablish an RLC entity to transmit data in a connected state. In other words, the network device 120 sets reestablishRLC only for non-SDT radio bearers in the RRC resume message during SDT. As a result, for SDT radio bearers, buffered RLC packets are not cleaned up.

[0069] Thus, for example, the relevant content of the modified 3GPP specification becomes "reestablishRLC indicates that RLC should be re-established". And the network device 120 may set it to true whenever the security key used for at least the radio bearer associated with the RLC entity changes. For SRB2 and DRB, it is also set to true at the first reconfiguration during or after the RRC connection is resumed. This is only indicated for radio bearers that do not support SDT when resuming the RRC connection during SDT.

[0070] It should be understood that this solution (i.e., network device 120 sending to terminal device 110 an RRC resumption message including instructions for RLC entity re-establishment for radio bearers that are not configured to have data transmission in an inactive state) may function independently of or in conjunction with the solution for handling RLC entity re-establishment for SDT described above, and the scope of the present disclosure is not limited in this respect.

[0071] On-demand system / location request implementation example System information (SI) includes a minimum SI and other SIs. The minimum SI includes basic information required for initial access and information to obtain any other SIs. The minimum SI includes a master information block (MIB) and a system information block 1 (SIB1).

[0072] In some examples, the other SI covers all SIBs that are not broadcast within the minimum SI. In such examples, for example, these SIBs may be broadcast periodically in the DL-SCH. In another example, the SIBs may also be broadcast as needed in the DL-SCH (i.e., upon request from the terminal device 110 in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED). Alternatively, these SIBs may be transmitted in a dedicated manner in the DL-SCH to UEs in RRC_CONNECTED (i.e., upon request, if configured by the network from a UE in RRC_CONNECTED, or if the UE has an active BWP that does not have a configured common search space).

[0073] Furthermore, in addition to the SI, in some examples, terminal device 110 may also need to obtain location information (PI). In such examples, the PI may be broadcast by network device 120 when requested by terminal device 110 (i.e., may be broadcast as needed). Thus, the location of terminal device 110 may be obtained via parameters included in the PI broadcast from network device 120.

[0074] However, the inventors of the present disclosure have noticed that during SDT (i.e., uplink transmission by the terminal device 110 in an inactive state), the terminal device 110 may need to request an on-demand SI / PI. Thus, in one aspect, a request for on-demand SI / PI may be transmitted in the first uplink SDT transmission together with the uplink data transmission in the inactive state. That is, two CCCH messages (because the RRC resume request message and the RRC_System_Info_Request message are both transmitted via CCCH messages) need to be transmitted at the same time. However, in the conventional solution, the size of the UL grant is designed for at least one CCCH message, and the mode of the RLC for the CCCH message is transparent mode (TM), which means that the CCCH message should not be segmented when transmitted. That is, if the size of the UL grant is insufficient to transmit two CCCH messages, the second CCCH message cannot be transmitted in a decoupled manner (i.e., a part of the CCCH message is transmitted in the UL grant, and another part of the CCCH message is transmitted in the next UL grant). Thus, if two CCCH messages are transmitted within a UL grant and the size of the UL grant is too small to hold the two CCCH messages, this may cause a failure in the transmission of the second of the two CCCH messages.

[0075] In another aspect, the inventors further noticed that, after the first uplink SDT transmission, if there is a subsequent uplink data transmission in the inactive state, the terminal device 110 may continue to perform transmission in the inactive state. At this time, if the terminal device 110 needs to request an on-demand SI / PI, there is no solution on how to transmit a request for on-demand SI / PI together with the subsequent SDT transmission in the subsequent data transmission phase. In other words, there is no solution on how to transmit a CCCH message during the subsequent uplink data transmission phase for the terminal device 110 in the inactive state. Thus, for example, considering that the CCCH message cannot be segmented as described above, this may be problematic if the size of the UL grant for the subsequent uplink data transmission is insufficient for the CCCH message.

[0076] In some other aspects, the on-demand SI / PI may also be obtained via a RACH procedure, and the first data transmission phase for the uplink transmission in the inactive state (i.e., SDT) may be performed via the SDT based on the RA as described above. As a result, two parallel RACH procedures (i.e., one for the on-demand SI / PI and the other for the first data transmission phase for the uplink transmission in the inactive state) may be triggered, which is not allowed. However, the MAC entity of the terminal device 110 only allows the execution of one RACH procedure, so triggering two parallel RACH procedures is also problematic as a result.

[0077] In short, there is no solution on how to deal with the problematic scenario as described above. In other words, a solution is needed for the scenario where on-demand SI / PI information requests are triggered during SDT.

[0078] In order to solve at least one of the above problems, a solution of SDT is provided. In this solution, the terminal device 110 performing uplink data transmission in an inactive state (i.e., the terminal device 110 performing SDT) first determines whether on-demand information is available. If it is determined that on-demand information is unavailable, the terminal device 110 performs at least one of the following operations. First, the terminal device 110 triggers the transmission of a request for on-demand information to the network device 120. Alternatively, the terminal device 110 avoids the transmission of a request for on-demand information to the network device 120. In other words, the terminal device 110 does not transmit a request for on-demand information to the network device 120.

[0079] Thus, the terminal device 110 can allow requests for on-demand information (e.g., on-demand SI / PI) during the SDT or avoid sending on-demand information requests during the SDT, thus improving the robustness of the SDT solution, since on-demand information requests triggered during the SDT can be appropriately handled (e.g., without interrupting the existing SDT).

[0080] Reference is now made to Figure 4, which illustrates a signaling flow 400 for an SDT procedure in accordance with some embodiments of the present disclosure. For purposes of illustration, the signaling flow 400 will be described with reference to Figure IA. 400 involves a terminal device 110 and a network device 120 as shown in FIG. 1A.

[0081] 4, the terminal device 110 performing uplink data transmission in an inactive state determines whether on-demand information is available (410). In one example, the on-demand information may include an on-demand SI. In another example, the on-demand information may also include an on-demand PI. It should be understood that the on-demand information may include other types of on-demand information, and the scope of the present disclosure is not limited in this respect.

[0082] In some embodiments, the terminal device 110 may determine whether on-demand information is available. If NO, the terminal device 110 may determine whether it is performing uplink data transmission in an inactive state (i.e., SDT). If YES, the terminal device 110 may trigger sending a request for on-demand information to the network device 120 or may avoid sending (i.e., not send) a request for on-demand information to the network device 120.

[0083] In some embodiments, terminal device 110 may determine that the on-demand information is unavailable if a valid version of the on-demand information does not exist and it is determined that the on-demand information is not being broadcast by network device 120. In such an embodiment, for example, the absence of a valid version of the on-demand information may be a result of terminal device 110 not storing a valid version. In another example, the terminal device may not store any version of the on-demand information at all.

[0084] In some other embodiments, terminal device 110 may determine that the on-demand information is unavailable if a request for on-demand information is received from higher layers at terminal device 110 at the RRC layer and the on-demand information is determined not to be broadcast by network device 120. Terminal device 110 may determine whether on-demand information is available, and the scope of the disclosure is not limited in this respect.

[0085] Then, if it is determined that the on-demand information is unavailable, the terminal device 110 determines to trigger sending a request for on-demand information to the network device 120 (420). Alternatively, the terminal device 110 avoids sending a request for on-demand information to the network device 120. In other words, the terminal device 110 does not request an on-demand SI or on-demand PI during the SDT. In such a case, the terminal device 110 may postpone the request until after the SDT procedure. In some other embodiments, if it is determined that the on-demand information is unavailable and the terminal device 110 is not performing the SDT (i.e., the timer for the SDT is not running), the terminal device 110 may request an on-demand SI / PI.

[0086] The terminal device 110 may trigger the transmission of a request for on-demand information to the network device 120 in various ways. In the following section, the methods of triggering the transmission of the request are introduced in detail. However, it should be understood that there are other ways to trigger the transmission of the request, and the scope of the present disclosure is not limited in this respect.

[0087] In some embodiments, the terminal device 110 may enter an idle state from an inactive state and then send a request for on-demand information to the network device 120. In such an embodiment, in one example, the lower layer (e.g., MAC layer) of the terminal device 110 is triggered to start a random access (RA) procedure in a normal uplink using a PRACH preamble and PRACH resources in si-RequestConfig corresponding to the SI message that the terminal device 110 needs to operate in the cell according to TS 38.321, and in this case, si-BroadcastStatus is set to notBroadcasting. Thus, on-demand information may be obtained from the network device 120 as needed.

[0088] In another example, the terminal device 110 may initiate transmission of an RRCSystemInfoRequest message (i.e., an SRB0 message using CCCH) in accordance with existing 3GPP standards to request on-demand SI / PI for the terminal device 110 in an INACTIVE or IDLE state.

[0089] In some other embodiments, terminal device 110 may suspend transmission of uplink data in the inactive state and then send a request for on-demand information to network device 120. For example, terminal device 110 may suspend transmission of uplink data in the inactive state by using the same suspend procedures described in the following portions of this disclosure. Terminal device 110 may also utilize other suspend procedures to suspend transmission of uplink data in the inactive state, and the scope of the disclosure is not limited in this respect.

[0090] In such an embodiment, in one example, the lower layer (e.g., PHY layer) of the terminal device 110 is triggered to initiate an RA procedure in the normal uplink or the supplemental uplink using the PRACH preamble and PRACH resource in the si-RequestConfig or si-RequestConfigSUL corresponding to the SI message that the terminal device 110 needs to operate in the cell according to TS 38.321, and in this case, si-BroadcastStatus is set to notBroadcasting. Thus, on-demand information may be obtained from the network device 120 as needed.

[0091] In another example, the terminal device 110 may initiate transmission of an RRCSystemInfoRequest message (i.e., an SRB0 message using CCCH) in accordance with existing 3GPP standards to request on-demand SI / PI for the terminal device 110 in an INACTIVE or IDLE state.

[0092] Alternatively, the terminal device 110 may trigger the transmission of a request for on-demand SI / PI by transmitting an SRB1 or SRB2 message. Thus, since the SRB1 and SRB2 messages are transmitted in the RLC acknowledged mode (AM), segmentation is allowed for such a mode. As a result, since the request for on-demand SI / PI is transmitted using DCCH, there is no question of whether the UL grant is large enough to accommodate the CCCH message.

[0093] In such an embodiment, for example, the existing SRB1 or SRB2 message may be used. In this example, the existing DedicatedSIBRequest message may be used to send on-demand SI / PI. For more types of SIBs, the message content may be extended to request other SIBs (e.g., SIB2-SIB11) besides SIB12, SIB13, SIB14 currently supported by the DedicatedSIBRequest message.

[0094] In such an embodiment, in another example, a newly designed message may be used to transmit on-demand information using SRB1 or SRB2. Specifically, the content of the new message may be the same as or similar to RRCSystemInfoRquest.

[0095] In one example, the newly designed message may be as follows: NewMessage ::= SEQUENCE { criticalExtensions CHOICE { newMessage RRCSystemInfoRequest-IEs, criticalExtensionsFuture-r16 CHOICE { rrcPosSystemInfoRequest-r16 RRC-PosSystemInfoRequest-r16-IEs, criticalExtensionsFuture SEQUENCE {} } } } RRCSystemInfoRequest-IEs ::= SEQUENCE { requested-SI-List BIT STRING (SIZE (maxSI-Message)), --32bits spare BIT STRING (SIZE (12)) } RRC-PosSystemInfoRequest-r16-IEs ::= SEQUENCE { requestedPosSI-List BIT STRING (SIZE (maxSI-Message)), --32bits spare BIT STRING (SIZE (11)) }

[0096] It should be understood that the SRB1 and SRB2 messages may be designed in other formats, and the scope of the present disclosure is not limited in this respect.

[0097] In some embodiments, when an RA-based SDT is used and a request based on an RA procedure is triggered, considering that the RA-based request cannot be performed during the first SDT phase of the RA-based SDT, the terminal device 110 may postpone the RA-based request and perform it after the first SDT transmission (i.e., the first data transmission phase) is completed. Alternatively, in such a case, the terminal device 110 may also transmit a request based on an SRB0 message (e.g., an RRCSystemInfoRequest message) during the first data transmission phase instead of postponing the RA-based request.

[0098] The above solution can avoid a scenario where two parallel RACH procedures are triggered when on-demand information is required during an SDT and a request based RA procedure is triggered.

[0099] In some examples, the request based on the RA procedure for on-demand SI / on-demand PI may be performed during a subsequent data transmission phase of the SDT, in some other examples, the request based on the RA procedure may be performed for on-demand SI / on-demand PI during a CG-based SDT.

[0100] 2A and 2B, the phases for transmission of uplink data in the inactive state may possibly include an initial data transmission phase and additional subsequent data transmission phases. Thus, in such an embodiment, for example, the terminal device 110 may determine that a request for on-demand SI / PI may be transmitted with an SRB0 message (e.g., an RRC System Info Request message), and that during the initial data transmission phase, the SRB0 message may be transmitted in a medium access control protocol data unit (MAC PDU) together with an RRC Resume Request message and the transmission of uplink data in the inactive state.

[0101] In the conventional solution, a temporary cell-radio network temporary identifier (TC-RNTI) is used during the RA procedure in the first data transmission phase. However, in the subsequent data transmission phase, if an uplink grant for dynamic grant or configured grant is used, a cell-radio network temporary identifier (C-RNTI) and a configured scheduling-radio network temporary identifier (CS-RNTI) are used, respectively. However, in the conventional solution, both C-RNTI and CS-RNTI are not allowed to transmit UL CCCH messages. As a result, even if the CCCH can be segmented, it is still problematic when transmitting CCCH messages in the subsequent data transmission phase. That is, it is necessary to use C-RNTI and CS-RNTI to transmit UL CCCH messages for on-demand SI / PI during the subsequent data transmission phase of SDT.

[0102] In order to solve the above problem, in another example, the terminal device 110 may send an SRB0 message during a subsequent data transmission phase on the CCCH using the C-RNTI or CS-RNTI. For example, the relevant content of the modified 3GPP specification is as shown in Table 1 below:

[0103] Table 1. RNTI usage [Table 1]

[0104] It is therefore possible to enable an on-demand system information request to be initiated during the SDT by transmitting a UL CCCH message using the C-RNTI and CS-RNTI.

[0105] In some other embodiments, the terminal device 110 may determine that the request for on-demand information is sent using an SRB0 message. Thus, upon determining that the uplink grant accepts the uplink data and does not accept the SRB0 message as an addition, the terminal device 110 may send the request after entering the idle state. Alternatively, the terminal device 110 may send the request after suspending the transmission of uplink data in the inactive state. In one example, the terminal device 110 may suspend the transmission of uplink data in the inactive state by using the same suspend procedure described in the following portion of the disclosure. The terminal device 110 may also utilize other suspend procedures to suspend the transmission of uplink data in the inactive state, and the scope of the disclosure is not limited in this respect.

[0106] That is, if the UL permission is not acceptable for the data of the CCCH message, the MAC layer should indicate to the RRC layer. Therefore, the RRC layer of the terminal device 110 may perform an SDT interruption procedure or enter an idle mode and then initiate a request for on-demand information. In this way, on-demand information (e.g., SI / PI) can be obtained by the terminal device 110 even if it is triggered during the SDT procedure.

[0107] Example of SDT procedure termination The inventor of the present disclosure has noticed that during the SDT procedure, there may be some cases where the SDT procedure cannot be continued. Thus, it is better to terminate the SDT procedure. However, in this case, it is still unclear what the terminal device 110 should do to terminate the SDT procedure.

[0108] Furthermore, the inventors of the present disclosure have found numerous scenarios in which it is unclear what the terminal device 110 should do after any of them occurs. Specifically, in one scenario, for example, if the terminal device 110 only transmits the first SDT by transmitting an RRC resume request message and uplink data, and the network device 120 does not receive this first data transmission due to delays or failures in the network, then if the terminal device 110 receives a paging request (e.g., if there is an incoming call), it is better to provide a response to the paging request rather than continuing to perform the SDT. This is because the SDT has a lower priority than a paging request caused by, for example, an incoming call. In such a scenario, how should the terminal device 110 handle the SDT procedure?

[0109] Furthermore, in another scenario, the upper layer (e.g., NAS layer) of the terminal device 110 may trigger an RRC restart procedure to the RRC layer, and the SDT procedure is, for example, initiated by the RRC layer. However, the upper layer may then indicate to the RRC layer to abandon the RRC restart procedure, i.e., to abort the RRC connection establishment. In such a case, how should the terminal device 110 handle the SDT procedure?

[0110] In another scenario, a timer is introduced and used to determine whether the transmission of uplink data has failed or not. For example, the timer may be a timer that is started as soon as the SDT procedure is initiated by the RRC layer. Alternatively, the timer may be a timer that is started or reset when the transmission of uplink data is performed in the terminal device 11 during a subsequent data transmission phase.

[0111] In a normal scenario, the timer set at the maximum value should not expire during the SDT procedure, and there should be a response from the network device 120 before the timer expires. However, if the timer expires and there is no response from the network device 120 (e.g., due to network delay, network failure, etc.), the terminal device 110 may determine that the transmission of uplink data has failed. In such a scenario, how should the terminal device 110 handle the SDT procedure?

[0112] In another scenario, when an RLC transmission fails, an RLC retransmission occurs. If the RLC retransmission fails, there may be another RLC retransmission. In such a scenario, a maximum number of RLC retransmissions (e.g., 2 or 4 RLC retransmissions) may be defined. If the maximum number of RLC retransmissions is reached during SDT, this may mean that the channel condition at that time is poor. In such a scenario, how should the terminal device 110 handle the SDT procedure?

[0113] Additionally, if the first uplink data transmission within the Msg A or Msg 3 resources of an RA-based SDT, or within the CG resources of a CG-based SDT, fails a predetermined number of times, how should the terminal device 110 perform further SDT procedures?

[0114] In another scenario, the RRC layer of the terminal device 110 may determine that all radio bearers with new data are configured to support SDT and the data volume is below a threshold, and the RRC layer indicates to the MAC layer that the MAC layer of the terminal device 110 should select whether to perform RA-based SDT or CG-based SDT. If there are no suitable RA-based SDT resources or suitable CG-based SDT resources available, the MAC layer should indicate to the RRC layer of the terminal device 110 to cancel SDT since there are no suitable SDT resources available. At this point, the RRC layer of the terminal device 110 may have already completed the RLC re-establishment or other SDT-related processing described above. However, since the MAC layer of the terminal device 110 has already indicated to the RRC layer that SDT resources are unavailable, what should the terminal device 110 do?

[0115] In order to solve at least one of the above problems, a solution for terminating SDT is provided. Now, referring to FIG. 5, FIG. 5 shows a signaling flow 500 for an SDT procedure according to some embodiments of the present disclosure. For illustrative purposes, the signaling flow 500 will be described with reference to FIG. 1A. The signaling flow 500 involves a terminal device 110 and a network device 120 as shown in FIG. 1A.

[0116] 5, for example, the terminal device 110 may be transmitting uplink data to the network device 120 in the inactive state (510). In another example, the terminal device 110 may be attempting to transmit uplink data to the network device 120 in the inactive state but has not yet transmitted it. The terminal device 110 then suspends transmission of uplink data in the inactive state (i.e., SDT procedure) in response to one of receiving a paging message addressed to the terminal device 110 from the network device 120, receiving a connection establishment interruption from a non-access stratum layer in the RRC layer of the terminal device 110, expiry of a first timer associated with transmission of uplink data in the inactive state, having already reached a maximum number of RLC retransmissions, a predetermined number of failures in the first uplink data transmission (in MsgA / Msg3 / CG resources), and an indication to cancel transmission of uplink data in the inactive state is provided from the MAC layer of the terminal device 110 to the RRC layer (520).

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

[0118] In some embodiments, the terminal device 110 may abort the SDT procedure by stopping a timer associated with the transmission of uplink data in the inactive state, so that once the timer is stopped, the expiration of the timer is not triggered and therefore no other unexpected actions are triggered.

[0119] In some other embodiments, the terminal device 110 may also abort the SDT procedure by at least one of discarding the current KgNB, KRRCenc, KRRCint, KUPint and KUPenc keys, resetting the MAC and releasing the default MAC cell group configuration, re-establishing the RLC entities of at least the radio bearers supporting transmission in the inactive state (i.e., all radio bearers or only the radio bearers supporting SDT), and suspending SRB1 and at least the radio bearers supporting transmission in the inactive state (i.e., all radio bearers or only the radio bearers supporting SDT). It should be noted that aborting the SDT procedure may include more or fewer actions.

[0120] With the above solution, it is clear in which scenarios an ongoing SDT procedure should be terminated, and the terminal device 110 can provide a more robust SDT solution by aborting the SDT procedure if the listed scenarios occur.

[0121] In some other embodiments, the terminal device 110 may also enter the idle state in response to one of the following: receiving a paging message addressed to the terminal device 110 from the network device 120; receiving a connection establishment interruption from a non-access stratum layer in the RRC layer of the terminal device 110; expiration of a first timer related to transmission of uplink data in the inactive state; a maximum number of RLC retransmissions having been reached; a first uplink data transmission (in MsgA / Msg3 / CG resources) having failed a predetermined number of times; or an instruction to cancel transmission of uplink data in the inactive state being provided from the MAC layer of the terminal device 110 to the RRC layer.

[0122] The above solution allows the terminal device 110 to also enter an idle state if the listed scenarios occur, thereby providing a more robust and complete solution for SDT.

[0123] It should be understood that upon entering the idle state (ie, RRC_IDLE), the terminal device 110 may perform in accordance with what is defined in existing 3GPP standards, the details of which are not specified in this specification.

[0124] Second RRC Resumption Implementation Example In some embodiments, as described above, an SDT suspension may be performed after an SDT procedure is initiated for various reasons. Also, after an SDT suspension, the terminal device 110 may remain in an inactive state. When in an inactive state, the terminal device 110 may initiate an RRC resumption procedure again in the same cell. The inventors of the present disclosure have realized that there are some security concerns when using the same resumeMAC-I in such cases.

[0125] Specifically, ResumeMAC-I is information sent by the terminal device 110 to the network device 120 in an RRC Resume Request message, thereby enabling the network device 120 to use it to verify whether the terminal device 110 is a valid terminal device 110. It should be understood that the RRC Resume Request message may be an RRCResumeRequest or RRCResumeRequest1 message.

[0126] However, the problem is that ResumeMAC-I has already been calculated in an SDT procedure that occurs before the SDT suspension procedure. However, since an RRC resume procedure (e.g., for SDT or for non-SDT) is performed in the same cell and using the same UE context again, ResumeMAC-I may be recalculated, so that the ResumeMAC-I calculated the second time may be the same as the one already calculated in the previous SDT procedure. As a result, if someone with another device (e.g., another terminal device 110) obtains the resumeMAC-I calculated in the SDT procedure before the suspension procedure by eavesdropping, the person with the device may masquerade as the terminal device 110 and send a second RRC resume request message to the network device 120.

[0127] In order to prevent the above cases from occurring, it is better not to reuse resumeMAC-I that has already been used once in the next SDT / non-SDT procedure. Therefore, a second solution for RRC resumption is provided. In this solution, the terminal device 110 determines a message authentication code-integrity (MAC-I) parameter for the RRC resumption procedure based on a first value related to the RRC resumption procedure. Then, the terminal device 110 transmits an RRC resumption request message including the parameter to initiate the RRC resumption procedure. In such a solution, the first value is different from a value of MAC-I used to determine another RRC resumption procedure (e.g., an RRC resumption procedure occurring before an SDT interruption procedure).

[0128] The above solution allows improving network security by calculating MAC-I parameters (e.g., resumeMAC-I) using different input values ​​of COUNT and / or BEARER and / or DIRECTION for each scene during the second RRC resumption procedure.

[0129] Reference is now made to Figure 6, which illustrates a signaling flow 600 for an SDT procedure in accordance with some embodiments of the present disclosure. For purposes of illustration, the signaling flow 600 will be described with reference to Figure IA. 600 involves a terminal device 110 and a network device 120 as shown in FIG. 1A.

[0130] 6, the terminal device 110 determines 610 a parameter of a MAC-I for an RRC restart procedure based on a value associated with the RRC restart procedure, the value being different from a value for determining a MAC-I for another RRC restart procedure. In some examples, the parameter of the MAC-I may be resumeMAC-I.

[0131] In some examples, the value for determining the MAC-I of another RRC resumption procedure may be a predefined value that is a sequence of binary 1's. For example, if a 16-bit sequence, the predefined value may be 1111, 1111, 1111, 1111. In some other embodiments, the predefined value may be 11 or 1111, and embodiments of the present disclosure are not limited in this respect.

[0132] In some embodiments, the value associated with the RRC resume procedure may be the input bits of the count for determining resumeMAC-I. In some other embodiments, the value may be the input bits of the bearer for determining resumeMAC-I. Alternatively, the value may be the input bits of the direction for determining resumeMAC-I. In other embodiments, the value may be the input bits of the count, the bearer and the direction, or any combination thereof.

[0133] In some embodiments, terminal device 110 may determine the parameter according to a determination that an RRC resumption procedure is initiated after ceasing transmission of other uplink data in an inactive state.

[0134] In such an embodiment, for example, if the terminal device 110 later performs a second RRC resumption procedure (for SDT or legacy data transmission) using the same UE context in the same cell, the terminal device 110 may: 2> on the ASN.1 encoded according to clause 8 (i.e., a multiple of 8 bits) VarResumeMAC-Input, 2> Using the KRRCint key in the UE Inactive AS Context and the previously configured integrity protection algorithm, and 2> input bits for count and / or bearer and / or direction set to a predetermined value other than the full binary value 1; Set resumeMAC-I in RRCResumeRequest or RRCResumeRequest1 to the least significant 16 bits of the MAC-I calculated with predefined input values ​​of count and / or bear and / or direction (e.g., all binary 0s, a sequence containing binary 1s and 0s, etc.) instead of all binary 1s.

[0135] The above solution allows the terminal device 110 to use a different resumeMAC-I after an SDT interruption when it starts the RRC resumption procedure again in the same cell, thus improving system security.

[0136] In some other embodiments, terminal device 110 may also determine the parameters according to determining that the RRC resumption procedure is for transmission of uplink data in an inactive state.

[0137] In such an embodiment, for example, if terminal device 110 initiates an RRC resumption procedure for SDT, terminal device 110 may calculate resumeMAC-I with input bits for count and / or bearer and / or direction set to a predefined value that is not all binary 1s (e.g., all binary 0s, etc.). Otherwise, terminal device 110 calculates resumeMAC-I in the same manner as in the conventional solution, i.e., set to all binary 1s.

[0138] Returning to FIG. 6, upon determining the MAC-I parameters for the RRC resumption procedure, terminal device 110 transmits an RRC resumption request message including the parameters to initiate the RRC resumption procedure (620).

[0139] In some examples, an RRC resumption request including resumeMAC-I may be sent by terminal device 110 to network device 120 as follows: RRCResumeRequest ::= SEQUENCE { rrcResumeRequest RRRCResumeRequest-IEs } RRCResumeRequest-IEs ::= SEQUENCE { resumeIdentity ShortI-RNTI-Value, resumeMAC-I BIT STRING (SIZE (16)), resumeCause ResumeCause, spare BIT STRING (SIZE (1)) }

[0140] Also, the state variable TX_NEXT indicates a count value of the next PDCP SDU to be transmitted. In some embodiments, the initial value of the state variable is 0 except for SRBs for which the state variable CONTINUE is set. In some embodiments, for target SRBs for which the state variable CONTINUE is set, the initial value is the value stored in the PDCP entity of the corresponding source SRB. For source SRBs for which the state variable CONTINUE is set, the initial value is the value stored in the PDCP entity of the corresponding target SRB.

[0141] During the PDCP entity suspend procedure, TX_NEXT is set to the initial value currently in effect when the terminal equipment enters the inactive state.

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

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

[0144] In view of this, the embodiments of the present application provide a solution to address the security issue by not resetting the state variable TX_NEXT.

[0145] As mentioned above, in some scenarios, the SDT procedure may be interrupted and then the terminal device may trigger another RRC resumption procedure in the same cell in which the SDT procedure was performed. This embodiment aims to provide a solution for enhancing security in these scenarios, which will be described in detail below.

[0146] In such an embodiment, terminal device 110 transmits uplink data to network device 120 in an inactive state, i.e., terminal device 110 performs an SDT procedure. In some embodiments, terminal device 110 may abort the SDT procedure.

[0147] During the SDT procedure, the terminal device 110 may determine whether a resumption of connection with the network device 120 is to be performed in a cell in which the SDT procedure has already been performed. If a resumption of connection is to be performed in the cell, the terminal device 110 may perform the resumption of connection as described below.

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

[0149] When the NAS layer or AS layer requests the terminal device 110 to resume the RRC connection for SDT or legacy data transmission, if the terminal device 110 is a cell that performed the SDT procedure using the current UE context, the terminal device 110 may perform the following actions in the RRC resume procedure. For example, in the case of legacy data transmission, the network device 120 may configure the terminal device 110 to perform PDCP re-establishment for DRB, SRB1, and SRB2 in the RRC resume message. In the case of SDT, the RRC layer of the terminal device 110 may initiate PDCP re-establishment for the DRB or SRB (e.g., SRB1 or SRB2) configured to have SDT. When the RRC layer indicates to the PDCP entity of the radio bearer configured to have SDT to perform re-establishment, the RRC layer should further indicate to the PDCP that TX_NEXT is not initialized during re-establishment for the UM DRB and SRB.

[0150] In some embodiments, if the other RRC resumption procedure (i.e., the second RRC process) is for legacy data transmission (i.e., data transmission during a connected state), considering that security issues exist only for SDT bearers and not for non-SDT bearers, the network device 120 may set in the RRC resumption message in any one of the following ways:

[0151] For example, in the RRC resumption message, the network device 120 may configure PDCP re-establishment for SDT bearers and non-SDT bearers, and the RRC layer of the terminal device 110 may indicate TX_NEXT continuation for radio bearers that support SDT to the PDCP layer when performing PDCP re-establishment.

[0152] Alternatively, in the RRC resume message, the network device 120 may configure PDCP re-establishment for radio bearers that do not support SDT. At the same time, the network device 120 may configure PDCP recovery for DRBs that support SDT and configure PDCP SDU discard for SRB1 and / or SRBs that support SDT. PDCP recovery does not reset TX_NEXT even for radio bearers that support SDT.

[0153] In some embodiments, when connection resumption is performed in a cell different from the cell in which the SDT procedure was performed, terminal device 110 may perform connection resumption by initializing state variables in PDCP re-establishment. For example, terminal device 110 may perform PDCP re-establishment without indicating PDCP pause to the lower layers of the DRB and indicating that TX_NEXT is not initialized before PDCP re-establishment.

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

[0155] Power Headroom Reporting Implementation Example Traditionally, the PHR is used by the terminal device 110 to report uplink power usage to the network device 120. In traditional solutions, the PHR is triggered by the MAC layer of the terminal device 110 at SDT. Additionally, the PHR has a higher priority than data (e.g., DRB and SRB data).

[0156] Therefore, during the first data transmission phase, if an RRC resumption request (i.e., a CCCH message) is sent with uplink data in the inactive state, and if a PHR also needs to be sent at that time, the UL grant may only accommodate data (including UL CCCH, DCCH, and DTCH), but not the PHR MAC CE and its header (3 bytes). As a result, the uplink data may not be transmitted at once, and the terminal device 110 will have to make subsequent data transmissions that should be avoided.

[0157] In some examples, if the size of the RRC resume request message with uplink data is 100 bits, the size of the PHR is 10 bits (i.e., 110 bits in total). However, the case will be described where the network device 120 allocates only 100 bits. As mentioned above, the priority of the PHR is higher than the data. As a result, there are 10 bits of data that cannot be transmitted in this uplink grant and need to be transmitted in the subsequent data transmission phase. However, considering that the PHR is used for the subsequent data transmission (e.g., to adjust the uplink transmission power of the subsequent data transmission) but has a higher priority, there will be data that cannot be transmitted at once in the first data transmission phase.

[0158] In order to solve the above problems, a solution for SDT is provided. Now, referring to FIG. 7, FIG. 7 shows a signaling flow 700 for an SDT procedure according to some embodiments of the present disclosure. For illustration purposes, the signaling flow 700 will be described with reference to FIG. 1A. The signaling flow 700 involves a terminal device 110 and a network device 120 as shown in FIG. 1A.

[0159] As shown in Fig. 7, the terminal device 110 triggers a PHR (710). Then, if it is determined that uplink data is transmitted in an inactive state, the terminal device 110 determines whether the uplink grant accepts the uplink data and does not accept the PHR as an addition (720). If it is determined that the uplink grant accepts the uplink data and does not accept the PHR as an addition, the terminal device 110 allocates resources to the uplink data (730). Then, the terminal device 110 transmits the uplink data using the allocated resources (740).

[0160] Therefore, if a PHR is triggered during the SDT, if the UL grant can accommodate all pending data available for transmission, but is insufficient to accommodate the PHR MAC CE and its header as an addition, then when performing resource allocation, the MAC layer should not select resources to allocate to the logical channel of the PHR MAC CE.

[0161] Therefore, if the UL-grant can only accept data but not PHR, the UE may only transmit data, and the SDT procedure can be completed in one transmission.

[0162] In some embodiments, if it is determined that the uplink grant does not additionally accommodate the PHR, terminal device 110 may avoid allocating resources to the MAC-CE of the PHR, i.e., terminal device 110 does not allocate resources to the MAC-CE of the PHR. In some embodiments, if the UL grant can accommodate both data and PHR, terminal device 110 may transmit both simultaneously.

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

[0164] 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 terminal device 110 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.

[0165] 8, in block 810, the terminal device 110 determines whether RLC entity re-establishment is performed for a radio bearer. The radio bearer is configured to have transmission of data in an inactive state. In some embodiments, determining whether RLC entity re-establishment is performed includes determining that RLC entity re-establishment is performed if uplink data transmission is performed in an inactive state, or determining that RLC entity re-establishment is performed if a radio resource control (RRC) release message including an indication regarding RLC entity re-establishment for the radio bearer is received from a network device.

[0166] If it is determined in block 820 that the RLC entity re-establishment is to be performed, the terminal device 110 re-establishes the RLC entity. Then, the terminal device 110 transmits uplink data in the inactive state on the radio bearer to the network device.

[0167] In some embodiments, in response to receiving an RRC resumption message from a network device including an instruction for re-establishing another RLC entity for another radio bearer that is not configured to have data transmission in an inactive state, the terminal device may re-establish the another RLC entity for transmitting data in a connected state.

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

[0169] 9, in block 910, the network device 120 determines whether uplink data and an RRC resume request message are received from the terminal device in the inactive state. If YES, the network device 120 sends an RRC resume message to the terminal device including instructions for RLC entity re-establishment for radio bearers that are not configured to have data transmission in the inactive state.

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

[0171] 10, the terminal device 110 performing uplink data transmission in an inactive state determines whether on-demand information is available in block 1010. If no, the method 1000 proceeds to block 1020.

[0172] If, in block 1020, it is determined that the on-demand information is unavailable, the terminal device performs at least one of triggering transmission of a request for the on-demand information to the network device or avoiding transmission of a request for the on-demand information to the network device.

[0173] In some embodiments, the on-demand information may include at least one of an on-demand SI or an on-demand PI.

[0174] In some embodiments, triggering the transmission of the request may include performing operations performed by at least one of entering an idle state and sending an SRB0 message requesting the on-demand information or initiating an RA procedure to request the on-demand information.

[0175] In some embodiments, triggering transmission of the request may include performing operations performed by at least one of suspending transmission of uplink data in an inactive state and transmitting an SRB0 message requesting the on-demand information or initiating an RA procedure to request the on-demand information.

[0176] In some embodiments, triggering the transmission of the request may include transmitting an SRB1 or SRB2 message requesting the on-demand information.

[0177] In some embodiments, triggering the transmission of the request may include at least one of sending the request after the first data transmission phase or sending an SRB0 message during the first data transmission phase.

[0178] In some embodiments, the phases for transmitting uplink data in the inactive state include an initial data transmission phase and a subsequent data transmission phase, and the method further includes, in accordance with a determination that the request is transmitted together with the SRB0 message, transmitting the SRB0 message during the initial data transmission phase by at least one of transmitting the SRB0 message together with the RRC resume request message and the transmission of uplink data in the inactive state within a media access control protocol data unit (MAC PDU), or transmitting the SRB0 message using the C-RNTI or CS-RNTI on a CCCH during the subsequent data transmission phase.

[0179] In some embodiments, the method 1000 may further include determining that the request is sent with an SRB0 message and, in accordance with a determination that the uplink grant accepts the uplink data and does not accept the SRB0 message as an additional, performing at least one of sending the request after entering an idle state or sending the request after ceasing transmission of uplink data in an inactive state.

[0180] In some embodiments, determining whether the on-demand information is available includes at least one of determining that the on-demand information is unavailable in accordance with a determination that no valid version of the on-demand information exists and that the on-demand information is not broadcast by the network device, and determining that the on-demand information is unavailable in accordance with a determination that a request for on-demand information is received from an upper layer of the terminal device at the RRC layer and that the on-demand information is not broadcast by the network device.

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

[0182] As shown in Fig. 11, in block 1110, the terminal device 110 may transmit uplink data in the inactive state to the network device. In block 1120, the terminal device 110 suspends transmission of uplink data in the inactive state in response to at least one of receiving a paging message addressed to the terminal device from the network device, receiving a connection establishment interruption from a non-access stratum layer in a radio resource control (RRC) layer of the terminal device, expiry of a first timer associated with transmission of uplink data in the inactive state, reaching a maximum number of RLC retransmissions already, a predetermined number of failures in the initial uplink data transmission, and a media access control (MAC) layer of the terminal device providing an instruction to the RRC layer to cancel transmission of uplink data in the inactive state.

[0183] In some embodiments, suspending transmission may include stopping a timer associated with transmitting uplink data in an inactive state.

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

[0185] 12, in block 1210, the terminal device 110 determines a parameter of a MAC-I for a radio resource control (RRC) resumption procedure based on a first value associated with the RRC resumption procedure, and in block 1220, the terminal device 110 transmits an RRC resumption request message including the parameter to initiate the RRC resumption procedure, the first value being different from a second value for determining a MAC-I for another RRC resumption procedure.

[0186] In some examples, the first value may include at least one of: a count input bit for determining resumeMAC-I; a bearer input bit for determining resumeMAC-I; and a direction input bit for determining resumeMAC-I.

[0187] In some embodiments, determining the parameter may include determining the parameter in response to determining at least one of: an RRC restart procedure is initiated after interrupting another transmission of another uplink data in an inactive state; or the RRC restart procedure is for a transmission of uplink data in an inactive state.

[0188] In some examples, the first value includes one or more of: a count input bit for determining resumeMAC-I, a bearer input bit for determining resumeMAC-I, and a direction input bit for determining resumeMAC-I. In some embodiments, the predetermined value includes a sequence of binary 1's.

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

[0190] As shown in FIG. 13, in block 1310, the terminal device 110 triggers a PHR. In block 1320, the terminal device 110 determines whether uplink data is transmitted in an inactive state. If YES, in block 1330, the terminal device 110 determines whether the uplink grant accepts the uplink data and does not accept a PHR as an additional. If YES, the method 1300 proceeds to block 1340. In block 1340, the terminal device 110 allocates resources for the uplink data. Thereafter, in block 1350, the terminal device 110 transmits the uplink data to the network device using the allocated resources.

[0191] In some embodiments, if it is determined that the uplink grant does not accommodate the PHR as an addition, terminal device 110 may avoid allocating resources to a media access control element (MAC-CE) of the PHR.

[0192] Device implementation examples 14 is a schematic block diagram of an apparatus 1400 suitable for implementing embodiments of the present disclosure. The apparatus 1400 may be considered as another exemplary implementation of the terminal device 110 or the network device 120 shown in FIG. 1A. Thus, the apparatus 1400 may be implemented in the terminal device 110 or the network device 120, or as at least a part thereof.

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

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

[0195] The memory 1420 may be of any type suitable for a local technology network and may be implemented using any suitable data storage technology, such as, by way of non-limiting example, non-transitory computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. Although only one memory 1420 is shown in the device 1400, there may be several physically different memory modules in the device 1400. The processor 1410 may be of any type suitable for a local technology network and may include, by way of non-limiting example, one or more of a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. The device 1400 may have multiple processors, for example application specific integrated circuit chips time-slaved to a clock that synchronizes the main processor.

[0196] In some embodiments, a terminal device (e.g., terminal device 110) includes circuitry configured to determine whether radio link control (RLC) entity re-establishment is performed for a radio bearer configured to have data transmission in an inactive state, and, in accordance with a determination that RLC entity re-establishment is performed, re-establish the RLC entity and transmit uplink data to a network device in the inactive state on the radio bearer.

[0197] In some embodiments, the circuitry may be configured to determine whether RLC entity re-establishment is performed by determining that RLC entity re-establishment is performed if transmission of uplink data is performed in an inactive state or by determining that RLC entity re-establishment is performed if a Radio Resource Control (RRC) release message is received from the network device including an indication regarding RLC entity re-establishment for the radio bearer.

[0198] In some embodiments, the circuitry is further configured to re-establish another RLC entity for transmitting data in a connected state in response to receiving an RRC resumption message from the network device including an instruction for re-establishing another RLC entity for another radio bearer that is not configured to have data transmission in an inactive state.

[0199] In some embodiments, a network device (e.g., network device 120) comprises circuitry configured to, in response to receiving uplink data and a radio resource control (RRC) resume request message from a terminal device in an inactive state, transmit to the terminal device a radio link control (RRC) resume message including instructions for RLC entity re-establishment for radio bearers that are not configured to have data transmission in the inactive state.

[0200] In some embodiments, the terminal device comprises circuitry configured to determine whether on-demand information is available in the terminal device performing uplink data transmission in an inactive state, and, in accordance with a determination that the on-demand information is unavailable, at least one of triggering transmission of a request for the on-demand information to the network device or avoiding transmission of a request for the on-demand information to the network device.

[0201] In some embodiments, the on-demand information includes at least one of on-demand system information or on-demand location information.

[0202] In some embodiments, the circuitry may be configured to trigger sending of the request by entering an idle state and performing operations performed by at least one of sending an SRB0 message requesting the on-demand information or initiating a random access procedure to request the on-demand information.

[0203] In some embodiments, the circuitry may be configured to trigger transmission of the request by performing operations performed by at least one of: suspending transmission of uplink data in an inactive state and transmitting an SRB0 message requesting the on-demand information, or initiating a random access procedure to request the on-demand information.

[0204] In some embodiments, the circuitry may be configured to trigger sending of the request by sending a signaling radio bearer 1 (SRB1) message or a signaling radio bearer 2 (SRB2) message to request the on-demand information.

[0205] In some embodiments, the circuitry may be configured to trigger sending of the request by at least one of sending the request after the first data transmission phase or sending a signaling radio bearer 0 (SRB0) message during the first data transmission phase.

[0206] In some embodiments, the phases for transmitting uplink data in the inactive state include an initial data transmission phase and a subsequent data transmission phase, and the circuitry is further configured to transmit the SRB0 message in accordance with a determination that the request is transmitted together with the SRB0 message by at least one of transmitting the SRB0 message together with the RRC resume request message and the transmission of uplink data in the inactive state within a media access control protocol data unit (MAC PDU) during the initial data transmission phase, or transmitting the SRB0 message using a C-RNTI or CS-RNTI on a common control channel (CCCH) during the subsequent data transmission phase.

[0207] In some embodiments, the circuitry is further configured to determine that the request is sent together with an SRB0 message, and in accordance with a determination that the uplink grant accepts the uplink data and does not accept the SRB0 message as an additional, perform at least one of: sending the request after entering an idle state or sending the request after ceasing transmission of the uplink data in an inactive state.

[0208] In some embodiments, the circuitry may be configured to determine whether the on-demand information is available by at least one of determining that the on-demand information is unavailable in accordance with a determination that no valid version of the on-demand information exists and that the on-demand information is not broadcast by the network device, and determining that the on-demand information is unavailable in accordance with a determination that a request for on-demand information is received from an upper layer of the terminal device at the RRC layer and that the on-demand information is not broadcast by the network device.

[0209] In some embodiments, a terminal device (e.g., terminal device 110) includes circuitry configured to transmit uplink data in an inactive state to a network device and to interrupt transmission of uplink data in an inactive state in response to at least one of: receiving a paging message addressed to the terminal device from the network device; receiving a connection establishment interruption from a non-access stratum layer at a radio resource control (RRC) layer of the terminal device; expiration of a first timer associated with transmitting uplink data in an inactive state; a maximum number of radio link control (RLC) retransmissions having been reached; a predetermined number of failures in the initial uplink data transmission; and an instruction to cancel transmission of uplink data in an inactive state provided from a media access control (MAC) layer of the terminal device to an RRC layer.

[0210] In some embodiments, the circuitry is configured to suspend transmission by stopping a timer associated with transmitting uplink data in an inactive state.

[0211] In some embodiments, a terminal device (e.g., terminal device 110) includes circuitry configured to determine a parameter of a MAC-I for an RRC restart procedure based on a first value associated with the RRC restart procedure and to transmit an RRC restart request message including the parameter to initiate the RRC restart procedure, the first value being different from a second value for determining a MAC-I for another RRC restart procedure.

[0212] In some embodiments, the first value includes at least one of: a count input bit for determining resumeMAC-I; a bearer input bit for determining resumeMAC-I; and a direction input bit for determining resumeMAC-I.

[0213] In some embodiments, the circuitry is configured to determine the parameter by determining the parameter in response to determining at least one of: an RRC restart procedure is initiated after interrupting another transmission of another uplink data in an inactive state; or the RRC restart procedure is for transmission of uplink data in an inactive state.

[0214] In some embodiments, the predetermined value may include a sequence of binary 1's.

[0215] In some embodiments, a terminal device (e.g., terminal device 110) includes circuitry configured to trigger a PHR, determine whether an uplink grant accepts the uplink data and does not accept a PHR as an addition according to a determination that the uplink data is transmitted in an inactive state, allocate resources to the uplink data according to a determination that the uplink grant accepts the uplink data and does not accept a PHR as an addition, and transmit the uplink data to a network device using the allocated resources.

[0216] The circuitry is further configured to avoid allocating resources to the MAC-CE of the PHR pursuant to a determination that the uplink grant does not accept the PHR as an addition.

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

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

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

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

[0221] It should be understood that although operations have been described in a particular order, it is not required that such operations be performed in the particular order shown, or in any sequential order, or that all of the operations described be performed, in order to achieve desired results. In some cases, multitasking or parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure, but rather as descriptions of features that may be specific to certain embodiments. Some features described in the context of individual embodiments may be 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.

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

Claims

1. means for supporting a small data transmission (SDT) procedure; means for triggering a request for on-demand system information to obtain a system information (SI) message when the UE does not store a valid version of a system information block (SIB), a system information (SI) message is not being broadcast, and the SDT procedure is not in progress; means for starting a first timer associated with the SDT procedure when the SDT procedure is initiated; means for stopping said first timer when a Radio Link Control (RLC) indicates that a maximum number of retransmissions has been reached or when a second timer associated with said SDT procedure expires; A user equipment (UE) comprising:

2. A means for receiving a radio resource control (RRC) rejection message; means for stopping the first timer upon receiving the RRC reject message; The user equipment of claim 1 further comprising:

3. means for initiating a first timer associated with a small data transmission (SDT) procedure when the SDT procedure is initiated; means for receiving a radio resource control (RRC) rejection message; means for stopping the first timer upon receiving the RRC reject message; means for stopping said first timer when a Radio Link Control (RLC) indicates that a maximum number of retransmissions has been reached or when a second timer associated with said SDT procedure expires; A user equipment (UE) comprising:

4. means for initiating a first timer associated with a small data transmission (SDT) procedure when the SDT procedure is initiated; means for stopping said first timer when a Radio Link Control (RLC) indicates that a maximum number of retransmissions has been reached or when a second timer associated with said SDT procedure expires; A user equipment (UE) comprising:

5. A method for a user equipment (UE), comprising: Supporting small data transmission (SDT) procedures; triggering a request for on-demand system information to obtain a system information (SI) message when the UE does not store a valid version of a system information block (SIB), a system information (SI) message is not being broadcast, and the SDT procedure is not in progress; starting a first timer associated with the SDT procedure when the SDT procedure is initiated; Stopping the first timer when a Radio Link Control (RLC) indicates that a maximum number of retransmissions has been reached or when a second timer related to the SDT procedure expires; A method comprising:

6. Receiving a radio resource control (RRC) rejection message; and upon receiving the RRC rejection message, stopping the first timer; The method of claim 5 further comprising:

7. A method for a user equipment (UE), comprising: starting a first timer associated with a small data transmission (SDT) procedure when the SDT procedure is initiated; receiving a radio resource control (RRC) rejection message; upon receiving the RRC rejection message, stopping the first timer; Stopping the first timer when a Radio Link Control (RLC) indicates that a maximum number of retransmissions has been reached or when a second timer related to the SDT procedure expires; A method comprising:

8. A method for a user equipment (UE), comprising: starting a first timer associated with a small data transmission (SDT) procedure when the SDT procedure is initiated; Stopping the first timer when a Radio Link Control (RLC) indicates that a maximum number of retransmissions has been reached or when a second timer related to the SDT procedure expires; A method comprising:

Images