Processing of data transmission

Abstract

Systems, methods, devices, and computer program products for handling data transmissions such as non-small data transmission (SDT) in combination with SDT are disclosed. One method can include determining availability of non-small data transmission (non-SDT) data. The method can also include indicating a result of the determination to a network element.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 089,312, filed October 8, 2020. The contents of that previously filed application are incorporated herein by reference in their entirety. Technical Field

[0003] Some example implementations may generally relate to mobile or wireless telecommunications systems, such as Long Term Evolution (LTE) or 5G radio access technologies or New Radio (NR) access technologies, or other communication systems. For example, some example implementations may relate to devices, systems, and / or methods for processing data transmissions such as Non-Small Data Transmission (SDT) combined with SDT. Background Technology

[0004] Examples of mobile or wireless telecommunications systems may include Universal Mobile Telecommunications System (UMTS), Terrestrial Radio Access Network (UTRAN), Long Term Evolution (LTE), Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE-A), MulteFire, LTE-APro, and / or fifth-generation (5G) radio access technologies or new radio (NR) access technologies. Fifth-generation (5G) radio systems refer to next-generation (NG) radio systems and network architectures. 5G is primarily built on new radio (NR), but 5G (or NG) networks can also be built on E-UTRAN radio. NR is expected to provide bit rates of approximately 10 to 20 Gbit / s or higher and will at least support enhanced mobile broadband (eMBB) and ultra-reliable low-latency communications (URLLC) as well as massive machine-type communications (mMTC). NR is expected to provide ultra-wideband and ultra-robust, low-latency connectivity and massive networking to support the Internet of Things (IoT). As IoT and machine-to-machine (M2M) communications become increasingly prevalent, the demand for networks that meet the requirements of low power consumption, high data rates, and long battery life will continue to grow. It should be noted that in 5G, when established on NR radio, the node that can provide radio access for user equipment (i.e., similar to a node B in UTRAN or an eNB in ​​LTE) is named gNB, and when established on E-UTRAN radio, it is named NG-eNB. Summary of the Invention

[0005] Some example implementations involve a method. The method may include determining the availability of non-small data transmission (non-SDT) data. The method may also include instructing network elements on the result of the determination.

[0006] Other example embodiments relate to a device that may include at least one processor and at least one memory, the at least one memory including computer program code. The at least one memory and the computer program code are configured, together with the at least one processor, to cause the device to at least determine the availability of non-small data transfer (non-SDT) data. The device may also cause the device to indicate the determination result to network elements.

[0007] Other example implementations relate to an apparatus. The apparatus may include means for determining the availability of non-small data transmission (non-SDT) data. The apparatus may also include means for instructing network elements on the result of the determination.

[0008] According to other example embodiments, a non-transitory computer-readable medium may be encoded with instructions that, when executed in hardware, can perform a method. The method may include determining the availability of non-small data transfer (non-SDT) data. The method may also include instructing a network element on the result of the determination.

[0009] Other example implementations may relate to a computer program product that performs a method. The method may include determining the availability of non-small data transmission (non-SDT) data. The method may also include instructing network elements on the result of the determination.

[0010] Other example implementations may involve an apparatus that may include circuitry configured to determine the availability of non-small data transmission (non-SDT) data. The apparatus may also include circuitry configured to indicate the result of the determination to network elements.

[0011] Some example implementations may involve a method. The method may include configuring a user equipment to trigger an SDT for Small Data Transmission (SDT) data and indicate the presence of non-SDT data. The method may also include receiving an SDT data transmission including the SDT data. The method may further include receiving an indication from the user equipment indicating the presence of the non-SDT data.

[0012] Other example embodiments may relate to a device. The device may include at least one processor and at least one memory, the at least one memory including computer program code. The at least one memory and the computer program code may be configured, together with the at least one processor, to cause the device to at least configure a user equipment to trigger SDT for Small Data Transfer (SDT) data and indicate the presence of non-SDT data. The device may also be caused to receive SDT data transmissions including the SDT data. The device may further be caused to receive an indication from the user equipment indicating the presence of the non-SDT data.

[0013] Other example embodiments may relate to an apparatus. The apparatus may include means for configuring a user equipment to trigger an SDT for Small Data Transmission (SDT) data and indicate the presence of non-SDT data. The apparatus may also include means for receiving SDT data transmissions including SDT data. The apparatus may further include means for receiving an indication from the user equipment indicating the presence of non-SDT data.

[0014] According to other example embodiments, a non-transitory computer-readable medium may be encoded with instructions that, when executed in hardware, can perform a method. The method may include configuring a user equipment to trigger an SDT for small data transfer (SDT) data and indicate the presence of non-SDT data. The method may also include receiving an SDT data transfer including the SDT data. The method may further include receiving an indication from the user equipment indicating the presence of the non-SDT data.

[0015] Other example implementations may relate to a computer program product that performs a method. The method may include configuring a user equipment to trigger an SDT for Small Data Transmission (SDT) data and indicate the presence of non-SDT data. The method may also include receiving an SDT data transmission including the SDT data. The method may further include receiving an indication from the user equipment indicating the presence of the non-SDT data.

[0016] Other example embodiments may relate to an apparatus that may include circuitry configured to configure a user equipment to trigger a Small Data Transmission (SDT) for Small Data Transmission (SDT) data and indicate the presence of non-SDT data. The apparatus may also include circuitry configured to receive SDT data transmissions including the SDT data. The apparatus may further include circuitry configured to receive from the user equipment an indication of the presence of the non-SDT data. Attached Figure Description

[0017] To correctly understand the example implementation scheme, please refer to the accompanying drawings, in which:

[0018] Figure 1(a) shows an example of a 4-step Small Data Transmission (SDT) signaling diagram.

[0019] Figure 1(b) shows an example of a 2-step SDT signaling diagram.

[0020] Figure 1(c) shows an example of a Configuration Authorization (CG) SDT signaling diagram.

[0021] Figure 2 An example of the content of the uplink Media Access Control Protocol (MAC) data unit is shown.

[0022] Figure 3 An example recovery process for enabling data transfer is shown.

[0023] Figure 4 The example shown illustrates a scenario where SDT and non-SDT data coexist in the buffer, and where the user equipment initiates SDT and resumes transmission.

[0024] Figure 5(a) shows a signaling diagram of non-SDT data indication via BSR along with SDT according to some example implementations.

[0025] Figure 5(b) shows a signaling diagram of the recovery process after an SDT interruption due to the presence of SDT and non-SDT data, according to some example implementations.

[0026] Figure 6(a) shows a signaling diagram of the buffer for non-SDT data according to some example implementations.

[0027] Figure 6(b) shows another signaling diagram of the buffering of non-SDT data according to some example implementations.

[0028] Figure 7 A flowchart of a method according to some example implementations is shown.

[0029] Figure 8 A flowchart of another method based on some example implementations is shown.

[0030] Figure 9(a) shows a device according to some example implementations.

[0031] Figure 9(b) shows another device according to some example implementations. Detailed Implementation

[0032] It will be readily understood that the components of some example embodiments, as generally described and illustrated in the accompanying figures, can be arranged and designed in a variety of different configurations. The following are detailed descriptions of some example embodiments of systems, methods, apparatuses, and computer program products for handling data transmissions such as Non-Small Data Transmission (SDT) combined with SDT.

[0033] In one or more example embodiments, the features, structures, or characteristics of the example embodiments described throughout this specification may be combined in any suitable manner. For example, the use of the phrases "certain embodiments," "example embodiments," "some embodiments," or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Therefore, the appearance of the phrases "in some embodiments," "example embodiments," "in some embodiments," "in other embodiments," or other similar language throughout this specification does not necessarily refer to the same set of embodiments, and in one or more example embodiments, the described features, structures, or characteristics may be combined in any suitable manner.

[0034] Additionally, if desired, the different functions or processes discussed below may be performed in different orders and / or simultaneously with each other. Furthermore, one or more of the described functions or processes may be optional or combinable, if desired. Therefore, the following description should be considered merely as illustrating the principles and teachings of certain example implementations, and not as limiting them.

[0035] Figure 1(a) shows an example of a 4-step Small Data Transmission (SDT) signaling diagram. Furthermore, Figure 1(b) shows an example of a 2-step SDT signaling diagram, and Figure 1(c) shows an example of an SDT signaling diagram based on Configuration Grant (CG). The 3rd Generation Partnership Project (3GPP) describes various solutions for enabling uplink (UL) user plane (UP) data SDT in the Radio Resource Control (RRC) inactive state of 5G New Radio (NR) systems. As shown in Figure 1(a), 3GPP describes SDT based on a 4-step Random Access Channel (RACH). Here, UP data can be transmitted in Msg3 of the 4-step RACH procedure. For example, the small data payload can be multiplexed with, for example, the RRC connection restoration request message in Msg3 of a Media Access Control (MAC) Protocol Data Unit (PDU).

[0036] As shown in Figure 1(b), 3GPP describes SDT based on a 2-step RACH. In this process, UP data transmission can be performed together with the MsgA of the 2-step RACH procedure, specifically on the Physical Uplink Shared Channel (PUSCH) resource. The PUSCH resource can be pre-configured by the gNB and broadcast in system information with associated physical transmission parameters.

[0037] Additionally, as shown in Figure 1(c), 3GPP describes CG-based SDT. Here, a UE in the RRC_connected state can receive CG type 1 configuration. According to some example implementations, this configuration can indicate specific pre-configured PUSCH resources to be used for UL data transmission in the RRC_inactive state, provided that the time alignment is valid.

[0038] In some cases, it can be assumed Figures 1(a) to 1(c) The illustrated method is based on RRC. For example, a UE can send an RRC message that includes information about its UE identifier and its authentication token (i.e., MAC-I). Figures 1(a) to 1(c) In this context, it can be assumed that the RRC recovery request message is for this purpose, and Figure 2The example content corresponds to the UL MAC PDU. In the RRC-free method, it can be assumed that the RRC layer does not need to participate in the SDT operation, and necessary information such as the User Equipment (UE) identifier and UE authentication token can be provided by the UE in the MAC header or as a MAC control element (CE). Additionally, the UE can use a data volume threshold to determine whether to perform SDT or a recovery procedure.

[0039] According to 3GPP, SDT can be configured by the network on a per-Data Radio Bearer (DRB) basis. The minimum number of DRBs that a UE can support can be 16 (without duplicates), and 8 per MAC entity (with duplicates). However, up to 29 DRBs can be added to the DRB-toAddModList, where each DRB can be identified by its DRB identifier. Additionally, configured DRBs can be suspended by the UE upon receiving an RRC release message with SuspendConfig. Furthermore, the Buffer Size Report (BSR) sent from the UE to the gNB via MAC CE can indicate the amount of pending data in the UL buffer allowed by the explicit buffer size bit field of each Logical Channel Group (LCG) in the NR. Additionally, a dedicated MAC CE format allows the transmission of short (truncated) and long (truncated) BSRs, indicating a buffer size index (in bytes) corresponding to the actual buffer size level of one or more Logical Channel Groups (LCGs). The network (gNB) can then schedule UL resources to each UE based on the BSR and the Quality of Service (QoS) characteristics of the corresponding DRB.

[0040] In some cases, Logical Channel Groups (LCGs) can be used to construct comprehensive reports of buffer states to improve signaling overhead efficiency. For example, buffer states can be reported to aggregate data on a set of logical channels (LCHs) assigned to the same LCG. Conversely, resource allocation can be performed based on logical channels. Mapping radio bearers and logical channels to LCGs can be performed by the gNB via RRC signaling during radio bearer establishment and can be based on the corresponding QoS attributes of the radio bearer. Current BSR triggering can include situations where new data arrives in a previously empty buffer, higher-priority data arrives after the UE has sent a BSR and is waiting for authorization, the UE needs to update the buffer state to the gNB (e.g., periodically updated according to the periodicBSR timer), and BSR retransmissions can be sent according to the retxBSR timer to provide BSR robustness.

[0041] Additionally, 3GPP describes that the UE AS context can be stored at the UE in an RRC-inactive state and at the previous serving gNB (e.g., anchor gNB or legacy NG-RAN node). The UE AS context may include the current RRC context, including pending RRC configurations and UE radio capabilities. The UE AS context may also include the current AS security context, including UE security capabilities and security information. Furthermore, the UE AS context may include the current configuration of the pending DRB, including the Packet Data Convergence Protocol (PDCP) state, including Robust Header Compression (ROHC) state, Serving Data Application Protocol (SDAP) configuration, and Radio Link Control (RLC) configuration. Additionally, the UE AS context may include the Cell Radio Network Temporary Identifier (C-RNTI), cell identifier, and physical cell identifier (PCI) of the source Pcell used in the source Pcell.

[0042] In some cases, receiving an RRC release with SuspendConfiguration can trigger a UE to move from an RRC connected state to an RRC inactive state, and consequently suspend the currently configured DRB. According to Radio Access Network 2 (RAN2), SDT features can be configured on a per-DRB basis. This indicates that the presence of service belonging to a DRB configured with SDT can trigger SDT. These DRBs can be referred to as SDT-DRBs. In this case, SDT can be selected if the SDT selection criteria are met. Furthermore, selection criteria based at least on data volume can be defined, for example, that the total data volume of the SDT-DRBs is lower than the maximum data volume threshold defined by the network for SDT in order to select SDT. Conversely, any other suspended DRB not configured with SDT (referred to as a non-SDT DRB) may have to initiate a recovery process to enable data transmission. This situation occurs in... Figure 3 The diagram illustrates an example recovery process for enabling data transfer.

[0043] Figure 4 This illustrates an example of a scenario where SDT and non-SDT data coexist in the buffer, and the user equipment initiates an SDT and triggers a recovery procedure. While SDT-DRB and non-SDT DRB operations may be straightforward when only a given type of service (SDT or non-SDT) exists in the UE buffer, problems can arise when both SDT-DRB and non-SDT DRB data are now / becoming present in the buffer. For cases where new data arrives at the UE buffer from SDT-DRB and non-SDT DRBs almost simultaneously, such as... Figure 4As shown, current SDT signaling (see Figure 1) allows carrying only UL data and / or related information for the SDT-DRB (e.g., the BSR of the SDT-DRB / LCG). Conversely, it is unclear how such signaling can provide an indication of the presence of other traffic not intended to be served via SDT. Therefore, some example implementations provide signaling extensions to handle situations where both SDT and non-SDT data are present. Without such extensions, the transmission of non-SDT DRB data may introduce additional latency when the data is generated in combination with SDT-DRB data, such as... Figure 4 As shown.

[0044] Some example implementations enable a UE in an RRC_inactive state to handle situations where SDT and non-SDT data may coexist in the UE's buffer when it initiates an SDT. For example, in some example implementations, when the UE has triggered an SDT procedure and data becomes available in a non-SDT DRB, the UE can indicate the presence of a non-SDT DRB. The UE's indication can be accomplished in various ways or by choice.

[0045] For example, in some example implementations, a new BSR trigger can be defined that does not consider LCH priority but can be triggered based on data that becomes available on non-SDT DRBs while the SDT process is in progress. In this case, the existing BSR format can be used for reporting. For example, the network (NW) can use an LCG with data information to infer the presence of data in non-SDT DRBs. Alternatively, a new indication (or a new format) can be defined in the BSR that indicates the availability of data in non-SDT DRBs.

[0046] According to other example implementations, a new MAC CE can be defined to indicate data availability in non-SDT DRBs. Here, the MAC CE may indicate, for example, the DRB ID / Logical Channel ID (LCID) of the LCH, the amount of data, the LCH LCG, etc. In some example implementations, another option may include an SDAP / PDCP / RLC control PDU of a non-SDT DRB multiplexed with SDT data to indicate the presence of data in the non-SDT DRB.

[0047] In other example implementations, another option may include triggering a new RRC message indicating that data has also become available to non-SDT DRB buffers. Such an RRC message may be a Common Control Channel (CCCH) (SRB0) message, which may be multiplexed from an RRC message used for the SDT procedure (e.g., RRCResume), or sent via UL authorization addressed to the C-RNTI after a C-RNTI has been assigned during the SDT procedure. Additionally, the RRC message may indicate, for example, the DRB ID / LCID of the LCH, the amount of data, the LCH LCG, etc.

[0048] According to some example implementations, the selection may include triggering an RRRCResume message so that the NW can infer the recovery reason for the retransmission of data that exists in a non-SDTDRB. For example, the recovery reason may be mobile-oriented data (MO-data) (i.e., uplink data), or a new recovery reason defined for this purpose.

[0049] According to other example implementations, selection may include an indication that non-SDT DRB data exists in the UE buffer, triggered when non-SDT DRB data has a higher priority than SDT-DRB data. For example, this could be based on LCH priority in the MAC layer. As described herein, "SDT triggered" may mean that the UE (e.g., the UE's RRC / MAC layer) has selected SDT based on the detection of SDT data presence and SDT selection criteria (e.g., a data threshold), but has not yet initiated an actual SDT (e.g., MsgA / Msg3 of CG transmission). However, for the case of multiple SDTs, the same aspects described above can be applied during the SDT process (i.e., the UE has already performed a first actual data transmission), where a single SDT transaction may include more than one actual data transmission (without transitioning the UE to the RRC_connected state).

[0050] In some example implementations, when the UE has already triggered the SDT procedure and data becomes available in a non-SDT DRB, the UE can abort the SDT procedure and trigger an RRC recovery procedure. Alternatively or additionally, this may depend on the priority of the SDT-DRB with data, compared to the non-SDT DRB with data. For example, if the data in the SDT-DRB has a higher priority, the SDT procedure can be completed by the UE. However, if the data in the non-SDT-DRB has a higher priority, the SDT procedure can be aborted.

[0051] In other example implementations, when the UE has triggered the SDT procedure and data becomes available in the non-SDT DRB, whether the SDT procedure is aborted or completed by the UE may depend on whether the SDT data has been transmitted by the UE. For example, if the SDT-DRB data has been transmitted, the SDT procedure can be completed by the UE. On the other hand, if the SDT-DRB data has not yet been transmitted, the SDT procedure may be aborted.

[0052] According to some example implementations, when the UE has triggered the SDT procedure and data becomes available in the non-SDT DRB, the UE can buffer the data in the non-SDT DRB until the SDT procedure is complete (i.e., after receiving RRCResume or RRCRelease with supsendConfig from the NW). After receiving RRCRelease with suspendConfig, the UE can trigger the connection restoration procedure for non-SDT DRB data transmission.

[0053] According to other example implementations, when the UE is in an RRC_inactive state and SDT is configured, and UL data becomes (or is now) available for transmission over both the SDT-DRB and the non-SDT DRB, the UE may trigger a regular RRC recovery procedure instead of an SDT transmission. In some example implementations, this may be common when the RRC recovery procedure begins with the arrival of data on the non-SDT DRB and the data on the SDT-DRB becomes available.

[0054] In some example implementations, when an SDT procedure has been triggered, the UE implementation can determine whether to re-initiate a new RRC procedure for RRC recovery or continue the SDT procedure when data arrives on a non-SDT DRB. In other example implementations, the network can control UE behavior that may involve new signaling. For example, this signaling can be used by the network to configure the UE to indicate what it should report related to the presence of non-SDT data, and when / if such reporting should be triggered. This signaling can also be used by the UE initiating SDT to transmit permitted UL data belonging to the SDT-DRB to indicate to the network, based on network configuration, the presence of data belonging to a non-SDT DRB. According to some example implementations, if the network does not configure an SDT-DRB, the UE can determine that all configured DRBs are SDT-DRBs, disallowing SDT, or only allowing the default bearer for SDT.

[0055] Figure 5(a) illustrates a signaling diagram indicating non-SDT data via BSR along with SDT according to certain example embodiments. As shown in Figure 5(a), at 500, the UE may be in the RRC_connected state. At 505, the gNB may send an RRC release message with SuspendConfig, which may include SDT configuration. Furthermore, the SDT configuration may include a first SDT-DRB and optional BSR information for a second non-SDT DRB. According to certain example embodiments, an SDT procedure based on a 4-step RACH may be assumed. However, in other example embodiments, the SDT procedure may use a 2-step RACH-based SDT or a configuration-authorized SDT. At 510, the UE may change to the RRC_inactive state, and at 515, for both the first and second DRBs, the UE may have a new payload in the UE's buffer. Furthermore, at 520, the UE may send a Physical Random Access Channel (PRACH) preamble to the gNB via Msg1. At 525, the gNB can respond by sending a Random Access Response (RAR) to the UE via Msg2. At 530, the UE can send an SDT via Msg3, which includes a UL payload comprising a first DRB (the first SDT-DRB mapped to the first SDT-LCG) and a BSR (the second non-SDT DRB mapped to the second non-SDT DRB). At 535, the gNB can send an RRC recovery indication via Msg4, and at 540, the UE can recover to the RRC_connected state.

[0056] Figure 5(b) illustrates a signaling diagram of the recovery process following an SDT abort due to the presence of both SDT and non-SDT data, according to certain example embodiments. As shown in Figure 5(b), at 545, the UE may be in an RRC_connected state. At 550, the gNB may send an RRC release message with SuspendConfig to the UE. This message may include SDT configuration, which may include first SDT-DRB data. According to certain example embodiments, the SDT configuration may also include configuration / information for aborting the SDT procedure in the presence of both SDT and non-SDT data. Alternatively, in other example embodiments, the configuration / information for aborting the SDT procedure in the presence of both SDT and non-SDT data may be written into the specification. Furthermore, in some example embodiments, the configuration regarding whether to abort the SDT may depend on the type of SDT procedure. For example, aborting the SDT may depend on whether the SDT procedure is a 4-step, 2-step, or CG-SDT procedure, where, for example, aborting may apply to RACH-based SDT procedures but not to CG-based SDT procedures. At point 555, the UE can change to the RRC_Inactive state. Furthermore, at point 560, for the first DRB, a new payload can appear in the UE's buffer, triggering an SDT procedure. At point 565, for the second DRB, a new payload can appear in the UE's buffer, at which point the UE can abort the SDT procedure and trigger an RRC recovery procedure. At point 570, the UE can send a PRACH preamble to the gNB via Msg1. In response, at point 575, the gNB can send a RAR to the UE via Msg2. At point 580, the UE can send an RRC message (e.g., an RRC recovery request) indicating SDT and non-SDT data to the gNB via Msg3. At point 585, the gNB can send an RRC recovery message to the UE via Msg4, after which, at point 590, the UE can return to the RRC_Connected state.

[0057] Figure 6(a) illustrates a signaling diagram of the buffer for non-SDT data according to some example implementations. At 600, the UE may be in the RRC_connected state. At 602, the gNB may send an RRC release message with SuspendConfig to the UE. This message may include an SDT configuration, which may include a first SDT-DRB. At 604, the UE may change to the RRC_inactive state, and at 606, for the first DRB, a new payload may appear in the UE's buffer, and an SDT procedure may be triggered. At 608, the UE may send a PRACH preamble to the gNB via Msg1. In response, at 610, the gNB may send a RAR to the UE via Msg2. Furthermore, at 612, the UE may send an SDT with a UL payload (first SDT-DRB) to the gNB via Msg3. At 614, the gNB may send an RRC release with SuspendConfig to the UE via Msg4. As shown in Figure 6(a), during Msg2 to Msg4, when an SDT transaction is in progress, new payloads can appear in the UE's buffer for the second non-SDT DRB. Second non-SDT DRB data can be buffered while an SDT transaction is in progress.

[0058] At point 616, the UE can be in an RRC inactive state. Furthermore, at point 618, the UE can send a PRACH preamble to the gNB via Msg1. In response, at point 620, the gNB can send a RAR to the UE via Msg2. Between points 618 and 624, an RRC recovery procedure associated with the second non-SDT DRB data can be triggered after the SDT transaction is closed. At point 622, the UE can send an RRC recovery request to the gNB via Msg3. In response, at point 624, the gNB can send an RRC recovery response to the UE via Msg4.

[0059] Figure 6(b) illustrates another signaling diagram of the buffering of non-SDT data according to certain example implementations. As shown in Figure 6(b), at 626, the UE may be in the RRC_connected state. At 628, the gNB may send an RRC release with SuspendConfig to the UE. This message may include an SDT configuration, which may include a first SDT-DRB. Furthermore, at 630, the UE may be in the RRC_inactive state. At 632, for both the first and second DRBs, a new payload may appear in the UE's buffer, and an SDT may be initiated while the non-SDT is buffered. At 634, the UE may send a PRACH preamble to the gNB via Msg1. In response, at 636, the gNB may send a RAR to the UE via Msg2. At 638, the UE may send a UL payload (first SDT-DRB) to the gNB via Msg3. At 640, the gNB may send an RRC release with SuspendConfig to the UE via Msg4. Additionally, at point 642, the UE can be in an RRC_inactive state. At point 644, an RRC recovery procedure associated with the second non-SDT DRB data can be triggered after the SDT transaction is closed.

[0060] According to some example implementations, the network can be configured to allow the UE to use SDT for DRBs / LCGs, and whether the UE can send an indication along with the SDT that SDT is not allowed for data where a DRB / LCG exists. In some example implementations, the UE can be configured not to send an indication for disallowed DRBs / LCGs. For example, an LCG containing any LCH may not be mapped to an SDT-DRB. In other example implementations, the UE can be configured to send an indication for a subset of non-SDT DRB / LCG IDs. In a further example implementation, the UE can be configured to cancel / delay an ongoing trigger to restore the RRC connection whenever an SDT trigger is satisfied. According to some example implementations, the UE can be configured with allowed DRBs / LCGs for SDT, and there may not be a separate configuration for whether to allow an indication. For example, the UE can be allowed to send an indication.

[0061] In some example implementations, the UE can be configured (or operated as specified) to indicate the presence of data belonging to a non-SDT-LCG via a BSR. Additionally, the UE can send such a BSR multiplexed with UL data when initiating an SDT. For example, in some example implementations, a new BSR format can be used, and this format can be constructed to distinguish between SDT-LCG and non-SDT-LCG. According to some example implementations, this distinction can be beneficial by allowing a new cell / gNB (different from the previous serving gNB) to correctly and timely interpret the BSR indication. Without this feature, the new cell / gNB would otherwise not know whether a certain LCG is permitted for SDT unless / until it has requested and received the UE context from the anchor gNB (the previous serving gNB). According to a further example implementation, the target gNB can determine different actions based on whether the BSR report is for an SDT-LCG. In the former case (i.e., the BSR indicates SDT data), the network can decide to provide the data without moving the UE to the RRC_connected state (i.e., using subsequent packets during multiple SDTs). To this end, the network can begin scheduling the UE and buffer multiple packets while performing context retrieval. According to some example implementations, the network may be able to process buffered packets once it receives the UE context. In cases where the BSR indicates non-SDT data, the network may decide to immediately move the UE to the RRC_connected state during the anchor relocation procedure.

[0062] According to some example implementations, a new BSR format may be used if the UE performs SDT on a cell different from its previous serving cell. However, if the cell is the same, the UE may use the regular BSR format. According to further example implementations, a dedicated BSR index (e.g., value 0) may be assigned to indicate that certain reported LCGs are non-SDT (i.e., LCG ID spatial partitioning). In some example implementations, a new indication (e.g., a flag) may be added for each LCG to indicate whether the LCG is permitted for SDT. In other example implementations, the total buffer size of the expected non-SDT LCG may be reported, indicating that it is non-SDT data, but the corresponding LCG ID is omitted from the report. In some example implementations, this omission may be made when the UE performs SDT on a cell different from its previous serving cell. According to some example implementations, a short BSR format may be used to carry buffer size indices and non-SDT LCG IDs. Furthermore, in other example implementations, the BSR format may be used to carry at least two buffer size indices corresponding to at least one non-SDT LCG ID.

[0063] According to some example implementations, the UE may be configured (or operated as specified) to indicate the presence of data belonging to a non-SDT-LCG via a (new) RRC message, and to send such an RRC message multiplexed with UL data when initiating an SDT. According to other example implementations, the (new) RRC message can extend the RRC recovery request message and include additional indications such as "existence of MO-SDT+non-SDT data" or similar "MO-SDT+recovery request," etc. According to a further example implementation, the RRC message may include the amount of UL data the UE uses for non-SDT DRBs and / or SDT DRBs.

[0064] Figure 7 A flowchart illustrating a method according to certain example implementations is shown. In some exemplary implementations, Figure 7 The flowchart can be executed by a network entity or network node in a 3GPP system such as LTE or 5G-NR. For example, in the example implementation, Figure 7 The method can be performed by the UE, such as by device 10 or 20 similar to those shown in Figures 9(a) and 9(b).

[0065] According to some example implementations Figure 7 The method may include, at 700, determining the availability of non-small data transmission (non-SDT) data. The method may also include, at 705, indicating the determined result to the network element.

[0066] According to some example implementations, the method may further include determining the availability of Small Data Transmission (SDT) data and triggering an SDT procedure when the SDT data is determined to be available. According to some example implementations, the determination of the availability of non-SDT data may be performed while the SDT procedure is in progress or when the SDT procedure is initiated. According to other example implementations, the method may further include triggering a connection recovery procedure when non-SDT data is determined to be available. According to a further example implementation, the method may further include performing SDT on network elements using the SDT data.

[0067] In some example implementations, determining whether non-SDT data is available while the SDT process is in progress may include determining that non-SDT data is available. In other example implementations, instructing a network element of the determined result may include instructing the presence of non-SDT data. In some example implementations, the presence of non-SDT data may be indicated during the SDT process. In further example implementations, instructing a network element of the determined result may be performed via one of the following: a Buffer State Report (BSR), a new Media Access Control (MAC) element, a Service Data Adaptation Protocol (SDP) control data element, a Packet Data Convergence Protocol (PDCP) control data element, a Radio Link Control (RTC) control data element, or a connection restoration message. In some example implementations, the indication via the BSR may be transmitted during the SDT process.

[0068] According to some example embodiments, indicating a determined result to a network element can be performed by transmitting a new Radio Resource Control (RRC) message. According to some example embodiments, the new RRC message can be multiplexed with SDT data when an SDT procedure is triggered. According to other example embodiments, indicating a determined result to a network element may include indicating the presence of both SDT data and non-SDT data. According to a further example embodiment, the presence of both SDT data and non-SDT data can be indicated in BSR information.

[0069] In some example implementations, the method may further include buffering SDT data and non-SDT data. In some example implementations, when non-SDT data is available, the method may further include aborting the SDT process and triggering a connection recovery process. In other example implementations, aborting may be based on the priority of the SDT data or whether SDT data has already been transmitted. In a further example implementation, when non-SDT data is available, the method may further include buffering non-SDT data while the SDT process is in progress.

[0070] According to some example implementations, after the SDT procedure is completed, the method may further include triggering a connection restoration procedure for non-SDT data transmission. According to some example implementations, the method may further include buffering SDT and non-SDT data, and initiating the SDT procedure while buffering the non-SDT data. According to other example implementations, the method may further include transmitting SDT data to network elements while buffering the non-SDT data.

[0071] Figure 8 A flowchart illustrating another method according to certain example implementations is shown. In some exemplary implementations, Figure 8 The flowchart can be executed by a telecommunications network, network entity, or network node in a 3GPP system such as LTE or 5G-NR. For example, in the example implementation, Figure 8The method can be performed by a gNB, such as device 10 or 20 similar to those shown in Figures 9(a) and 9(b).

[0072] According to some example implementations Figure 8 The method may include, at 800, configuring the user equipment to trigger an SDT for Small Data Transfer (SDT) data and indicating the presence of non-SDT data. The method may also include, at 805, receiving an SDT data transfer including the SDT data. The method may further include, at 810, receiving an indication from the user equipment indicating the presence of non-SDT data.

[0073] According to some example implementations, user equipment (UE) configuration can be performed via Radio Resource Control (RRC) messages. According to some example implementations, RRC messages can trigger a change of UE from an RRC connected state to an RRC inactive state. According to other example implementations, an indication of the presence of non-SDT data can be received via one of the following: Buffer State Report (BSR), New Media Access Control (MAP) element, Service Data Adaptation Protocol (SDP) control protocol data element, Packet Data Convergence Protocol (PaDP) control protocol data element, Radio Link Control (RFC) control protocol data element, or Connection Resumption message. According to a further example implementation, an indication via a BSR can be received during an SDT process.

[0074] In some example implementations, configuring the user equipment may include configuring the user equipment with indications regarding what it should report in relation to the presence of non-SDT data, and when or whether to trigger such reporting. In some example implementations, the method may also include configuring the user equipment to initiate SDT to transmit permitted uplink SDT data. In other example implementations, configuring the user equipment includes one or more of the following: configuring the user equipment not to send indications for non-SDT data; configuring the user equipment to send indications for a subset of non-SDT data; configuring the user equipment to cancel or postpone an ongoing trigger to restore the RRC connection whenever an SDT initiation trigger is satisfied; configuring the user equipment with permitted SDT data for SDT; or configuring the user equipment to abort SDT in the presence of both SDT data and non-SDT data.

[0075] Figure 9(a) illustrates device 10 according to some example embodiments. In some example embodiments, device 10 may be a node or element in or associated with a communication network, such as a UE, mobile device (ME), mobile station, mobile device, fixed device, IoT device, or other device. In other example embodiments, device 10 may be a network element, node, host, or server in or serving a communication network. It should be noted that those skilled in the art will understand that device 10 may include components or features not shown in Figure 9(a).

[0076] In some example embodiments, device 10 may include one or more processors, one or more computer-readable storage media (e.g., memory, storage device, etc.), one or more radio access components (e.g., modems, transceivers, etc.), and / or user interfaces. In some example embodiments, device 10 may be configured to operate using one or more radio access technologies, such as GSM, LTE, LTE-A, NR, 5G, WLAN, WiFi, NB-IoT, Bluetooth, NFC, MulteFire, and / or any other radio access technology. It should be noted that those skilled in the art will understand that device 10 may include components or features not shown in FIG. 9(a).

[0077] As shown in Figure 9(a), device 10 may include or be coupled to processor 12 for processing information and executing instructions or operations. Processor 12 may be any type of general-purpose or special-purpose processor. In practice, as an example, processor 12 may include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), and processor based on a multi-core processor architecture. Although a single processor 12 is shown in Figure 9(a), multiple processors may be used according to other example embodiments. For example, it should be understood that in some example embodiments, device 10 may include two or more processors that can form a multiprocessor system capable of supporting multiple processing (e.g., in this case, processor 12 may represent multiple processors). According to some example embodiments, the multiprocessor system may be tightly coupled or loosely coupled (e.g., to form a computer cluster).

[0078] Processor 12 can perform functions associated with the operation of device 10, including, for example, precoding of antenna gain / phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of device 10, as shown in Figures 1 to 10. Figure 7 The process is shown.

[0079] Device 10 may also include or be coupled to memory 14 (internal or external), which may be coupled to processor 12 for storing information and instructions executable by processor 12. Memory 14 may be one or more memories and may be of any type suitable for the local application environment, and may be implemented using any suitable volatile or non-volatile data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and / or removable memory. For example, memory 14 may include random access memory (RAM), read-only memory (ROM), static storage devices such as disks or optical discs, hard disk drives (HDDs), or any other type of non-transitory machine or computer-readable medium, and any combination thereof. Instructions stored in memory 14 may include program instructions or computer program code that, when executed by processor 12, enable device 10 to perform the tasks described herein.

[0080] In some example embodiments, device 10 may also include or be coupled to an (internal or external) drive or port configured to accept and read external computer-readable storage media, such as an optical disc, USB drive, flash drive, or any other storage media. For example, the external computer-readable storage media may store data for processor 12 and / or device 10 to execute to perform Figures 1 to Figure 7 Computer programs or software using any of the methods shown.

[0081] In some example implementations, device 10 may also include or be coupled to one or more antennas 15 for receiving downlink signals from device 10 and for transmitting via uplink. Device 10 may also include a transceiver 18 configured to transmit and receive information. Transceiver 18 may also include a radio interface (e.g., a modem) coupled to antenna 15. The radio interface may correspond to one or more of various radio access technologies, including GSM, LTE, LTE-A, 5G, NR, WLAN, NB-IoT, Bluetooth, BT-LE, NFC, RFID, UWB, etc. The radio interface may include other components such as filters, converters (e.g., digital-to-analog converters, etc.), symbol demappers, signal shaping components, inverse fast Fourier transform (IFFT) modules, etc., to process symbols carried by the downlink or uplink, such as OFDMA symbols.

[0082] For example, transceiver 18 may be configured to modulate information onto a carrier waveform for transmission by antenna 15 and demodulate information received via antenna 15 for further processing by other elements of device 10. In other example embodiments, transceiver 18 may be able to directly transmit and receive signals or data. Additionally or alternatively, in some example embodiments, device 10 may include input and / or output devices (I / O devices). In some example embodiments, device 10 may also include a user interface, such as a graphical user interface or a touchscreen.

[0083] In some example embodiments, memory 14 stores software modules that provide functionality when executed by processor 12. These modules may include, for example, an operating system that provides operating system functionality for device 10. The memory may also store one or more functional modules, such as applications or programs, to provide additional functionality to device 10. Components of device 10 may be implemented in hardware or as any suitable combination of hardware and software. According to some example embodiments, device 10 may optionally be configured to communicate with device 20 via wireless or wired communication link 70 according to any radio access technology, such as NR.

[0084] According to some example embodiments, processor 12 and memory 14 may be included in or form part of processing or control circuitry. Additionally, in some example embodiments, transceiver 18 may be included in or form part of transceiver circuitry.

[0085] As discussed above, according to certain example embodiments, device 10 may be, for example, a UE. According to certain example embodiments, device 10 may be controlled by memory 14 and processor 12 to perform functions associated with the example embodiments described herein. For example, in some example embodiments, device 10 may be controlled by memory 14 and processor 12 to determine the availability of non-small data transfer (non-SDT) data. Device 10 may also be controlled by memory 14 and processor 12 to indicate the determined results to network elements.

[0086] Figure 9(b) illustrates device 20 according to some example embodiments. In some example embodiments, device 20 may be a node or element in or associated with a communication network, such as a base station, node B, evolved node B (eNB), 5G node B or access point, next-generation node B (NG-NB or gNB), and / or WLAN access point associated with a radio access network (RAN) such as an LTE network, 5G, or NR. It should be noted that those skilled in the art will understand that device 20 may include components or features not shown in Figure 9(b).

[0087] As shown in Figure 9(b), device 20 may include processor 22 for processing information and executing instructions or operations. Processor 22 may be any type of general-purpose or special-purpose processor. For example, processor 22 may include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), and processor based on a multi-core processor architecture. Although a single processor 22 is shown in Figure 9(b), multiple processors may be used according to other example embodiments. For example, it should be understood that in some example embodiments, device 20 may include two or more processors that can form a multiprocessor system capable of supporting multiple processing (e.g., in this case, processor 22 may represent multiple processors). In some example embodiments, the multiprocessor system may be tightly coupled or loosely coupled (e.g., to form a computer cluster).

[0088] According to certain example embodiments, processor 22 may perform functions associated with the operation of device 20, which may include, for example, precoding of antenna gain / phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of device 20, as shown in Figures 1 to 6. Figure 8 The process is shown.

[0089] Device 20 may also include or be coupled to memory 24 (internal or external), which may be coupled to processor 22 for storing information and instructions executable by processor 22. Memory 24 may be one or more memories and may be of any type suitable for the local application environment, and may be implemented using any suitable volatile or non-volatile data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and / or removable memory. For example, memory 24 may include random access memory (RAM), read-only memory (ROM), static storage devices such as disks or optical discs, hard disk drives (HDDs), or any other type of non-transitory machine or computer-readable medium, and any combination thereof. Instructions stored in memory 24 may include program instructions or computer program code that, when executed by processor 22, enable device 20 to perform the tasks described herein.

[0090] In some example embodiments, device 20 may also include or be coupled to an (internal or external) drive or port configured to accept and read external computer-readable storage media, such as an optical disc, USB drive, flash drive, or any other storage media. For example, the external computer-readable storage media may store data for processor 22 and / or device 20 to execute the functions shown in Figures 1 through 6. Figure 8 The computer program or software of the method shown.

[0091] In some example implementations, device 20 may also include or be coupled to one or more antennas 25 for transmitting and / or receiving signals and / or data to and from device 20. Device 20 may also include or be coupled to a transceiver 28 configured to transmit and receive information. Transceiver 28 may include, for example, multiple radio interfaces that can be coupled to antennas 25. The radio interfaces may correspond to a variety of radio access technologies, including one or more of GSM, NB-IoT, LTE, 5G, WLAN, Bluetooth, BT-LE, NFC, radio frequency identification (RFID), ultra-wideband (UWB), MulteFire, etc. The radio interfaces may include components such as filters, converters (e.g., digital-to-analog converters, etc.), mappers, fast Fourier transform (FFT) modules, etc., to generate symbols for transmission via one or more downlinks and for receiving symbols (e.g., via an uplink).

[0092] Therefore, transceiver 28 can be configured to modulate information onto a carrier waveform for transmission by antenna 25 and demodulate information received via antenna 25 for further processing by other elements of device 20. In other example embodiments, transceiver 18 may be able to directly transmit and receive signals or data. Additionally or alternatively, in some example embodiments, device 20 may include input and / or output devices (I / O devices).

[0093] In some example embodiments, memory 24 may store software modules that provide functionality when executed by processor 22. These modules may include, for example, an operating system that provides operating system functionality to device 20. The memory may also store one or more functional modules, such as applications or programs, to provide additional functionality to device 20. Components of device 20 may be implemented in hardware or as any suitable combination of hardware and software.

[0094] According to some example embodiments, processor 22 and memory 24 may be included in or form part of processing or control circuitry. Additionally, in some example embodiments, transceiver 28 may be included in or form part of transceiver circuitry.

[0095] As used herein, the term "circuit" can refer to a purely hardware circuit implementation (e.g., analog and / or digital circuitry), a combination of hardware circuitry and software, a combination of analog and / or digital hardware circuitry and software / firmware, any portion of a hardware processor that works together to enable a device (e.g., devices 10 and 20) to perform various functions, along with software (including digital signal processors), and / or hardware circuitry and / or a processor or portion thereof that operates using software but may be absent when operation is not required. As another example, as used herein, the term "circuit" can also encompass an implementation of hardware circuitry or a processor (or processors) alone, or an implementation of hardware circuitry or a processor and portions thereof with accompanying software and / or firmware. The term "circuit" can also encompass baseband integrated circuits, such as those in servers, cellular network nodes or devices, or other computing or networking devices.

[0096] As described above, in some embodiments, device 20 may be a network element, node, host, or server in or serving a communications network. For example, device 20 may be a satellite, base station, node B, evolved node B (eNB), 5G node B or access point, next-generation node B (NG-NB or gNB), and / or WLAN access point associated with a radio access network (RAN) such as an LTE network, 5G, or NR. According to some embodiments, device 20 may be controlled by memory 24 and processor 22 to perform functions associated with any of the embodiments described herein.

[0097] As discussed above, according to certain example embodiments, device 20 may be, for example, a communication network. According to certain embodiments, device 20 may be controlled by memory 14 and processor 12 to perform functions associated with the example embodiments described herein. For example, in some example embodiments, device 20 may be controlled by memory 24 and processor 22 to configure a user equipment to trigger SDT for Small Data Transfer (SDT) data and indicate the presence of non-SDT data. Device 20 may also be controlled by memory 24 and processor 22 to receive SDT data transfers including SDT data. Device 20 may further be controlled by memory 24 and processor 22 to receive an indication from the user equipment indicating the presence of non-SDT data.

[0098] Further example embodiments may provide means for performing any of the functions or processes described herein. For example, some example embodiments may relate to an apparatus including means for determining the availability of non-small data transmission (non-SDT) data. The apparatus may also include means for instructing network elements on the result of the determination.

[0099] Other example embodiments may relate to another device that includes means for configuring a user equipment to trigger an SDT for small data transmission (SDT) data and indicate the presence of non-SDT data. The device may also include means for receiving SDT data transmissions that include SDT data. The device may further include means for receiving an indication from the user equipment indicating the presence of non-SDT data.

[0100] Some example implementations described herein offer several technical improvements, enhancements, and / or advantages. In some example implementations, signaling extensions can be provided to handle situations where SDT and non-SDT data coexist. Additional latency can also be prevented whenever data is generated along with SDT-DRB data. Some example implementations may also provide means for enabling a UE in an RRC_inactive state to handle situations where SDT and non-SDT data may coexist in the UE's buffer when it initiates SDT. In some examples, processing may take into account data priority and data type (e.g., depending on the type of application generating the data, including non-smartphone applications such as sensors and smart meters, as well as smartphone applications).

[0101] A computer program product may include one or more computer-executable components that are configured to perform some example implementations when the program is run. The one or more computer-executable components may be at least one piece of software code or a portion thereof. Modifications and configurations required to implement the functionality of the example implementations may be executed as routines, which may be implemented as added or updated software routines. Software routines may be downloaded to a device.

[0102] As an example, software or computer program code, or portions thereof, may be in the form of source code, object code, or some intermediate form, and may be stored on some carrier, distribution medium, or computer-readable medium, which may be any entity or device capable of carrying the program. Such carriers may include, for example, recording media, computer memory, read-only memory, optoelectronic and / or electrical carrier signals, telecommunication signals, and software distribution packages. Depending on the required processing power, the computer program may execute in a single electronic digital computer or be distributed across multiple computers. Computer-readable media or computer-readable storage media may be non-transitory media.

[0103] In other example implementations, the function may be performed by hardware or circuitry included in a device (e.g., device 10 or device 20), for example by using an application-specific integrated circuit (ASIC), a programmable gate array (PGA), a field-programmable gate array (FPGA), or any other combination of hardware and software. In yet another example implementation, the function may be implemented as a signal, i.e., an intangible device carried by an electromagnetic signal downloadable from the Internet or other networks.

[0104] According to the example implementation, a device such as a node, apparatus, or corresponding component may be configured as a circuit, a computer, or a microprocessor, such as a single-chip computer element, or configured as a chipset, including at least one memory providing storage capacity for arithmetic operations and an arithmetic processor for performing arithmetic operations.

[0105] Those skilled in the art will readily understand that the invention as discussed above can be practiced using processes in different sequences and / or with hardware elements having configurations different from those disclosed. Therefore, while the invention has been described based on these exemplary embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be readily apparent while remaining within the spirit and scope of the exemplary embodiments. Although the above embodiments relate to 5G NR and LTE technologies, they can also be applied to any other current or future 3GPP technologies, such as Advanced LTE, and / or fourth-generation (4G) technologies.

[0106] Some vocabulary

[0107] 5GS 5G system

[0108] AMF access and mobility management functions

[0109] BSR Buffer Status Report

[0110] CG Configuration License

[0111] CP control plane

[0112] DRB Data Radio Bearer

[0113] eNB Enhanced Node B

[0114] gNB 5G or next-generation NodeB

[0115] I-RNTI Inactive Radio Network Temporary Identifier

[0116] LCG Logical Channel Group

[0117] LCH logical channel

[0118] LTE Long Term Evolution

[0119] NCC nextHopChainingCount

[0120] NG-RAN Next Generation Radio Access Network

[0121] NR New Radio

[0122] NW Network

[0123] PDU Protocol Data Unit

[0124] PRACH Physical Random Access Channel

[0125] RACH Random Access Channel

[0126] RAN Radio Access Network

[0127] RB radio bearer

[0128] RNA RAN Notification Region

[0129] RNAU RAN notification region update

[0130] RRC Radio Resource Control

[0131] SDT Small Data Transmission

[0132] UE User Equipment

[0133] UP User Plane

[0134] Xn Xn Network Interface

Claims

1. A method for communication, comprising: The availability of data for transmission on data radio bearers (DRBs) not configured for SDT is determined during the Small Data Transmission (SDT) process with network elements. The method further includes, when the data for transmission on the DRB not configured for SDT is available: While the SDT process is in progress, the network element is informed that the data is available for transmission on the DRB that is not configured for SDT; The SDT process is terminated.

2. The method according to claim 1, further comprising: Determine the availability of data to be transmitted on the DRB configured for SDT; as well as The SDT process is triggered when it is determined that the data to be transmitted on the DRB configured for SDT is available.

3. The method according to claim 1, further comprising: The connection recovery process is triggered when it is determined that the data to be transmitted on the DRB that is not configured for SDT is available.

4. The method according to claim 2, further comprising: SDT is performed on the network element using the data transmitted on the DRB configured for SDT.

5. The method according to claim 1, Indicating to the network element that the data is available for transmission on the DRB not configured for SDT includes indicating the presence of the data in the buffer of the DRB not configured for SDT, and The presence of the data in the buffer is indicated during the SDT process.

6. The method according to claim 1, Indicating to the network element that the data is available for transmission on the DRB not configured for SDT is performed via one of the following: Buffer Status Report (BSR), New Media Access Control (MAC) element, Service Data Adaptation Protocol (SDP) control protocol data element, Packet Data Convergence Protocol (PDCP) control protocol data element, Radio Link Control (RFC) control protocol data element, or Connection Resumption Message. The instruction transmitted via the BSR is transmitted during the SDT process.

7. The method according to claim 2, This is achieved by transmitting Radio Resource Control (RRC) messages to instruct the network element that the data is available for transmission on the DRB not configured for SDT, and The RRC message is multiplexed with the data of the DRB configured for SDT.

8. The method according to claim 2, Indicating to the network element that the data is available for transmission on the DRB not configured for SDT includes indicating the presence of the data for transmission on the DRB configured for SDT and the data for transmission on the DRB not configured for SDT. The BSR information indicates the presence of the data for transmission on the DRB configured for SDT and the data for transmission on the DRB not configured for SDT.

9. The method according to claim 2, further comprising: The buffer is used for the data transmitted on the DRB configured for SDT and for the data transmitted on the DRB not configured for SDT.

10. The method of claim 1, wherein the abort is based on the priority of the data to be transmitted on the DRB configured for SDT or whether the data to be transmitted on the DRB configured for SDT has already been transmitted.

11. The method of claim 1, wherein when the data for transmission on the DRB not configured for SDT is available, the method further comprises: While the SDT process is in progress, buffer the data to be transmitted on the DRB that is not configured for SDT.

12. The method of claim 11, wherein after completing the SDT process, the method further comprises: The connection recovery process is triggered for the data to be transmitted on the DRB that is not configured for SDT.

13. A method for communication, comprising: Configure the user equipment to trigger SDT for data that can be transmitted on a data radio bearer (DRB) configured for small data transmission (SDT) and indicate the presence of data that can be transmitted on a DRB not configured for SDT; Receive SDT data transmissions, including data that can be used on the DRB configured for SDT; as well as Receive from the user equipment an indication of the existence of the data that can be transmitted on the DRB not configured for SDT. The configuration of the user equipment includes: configuring the user equipment to terminate the SDT process when both data available for transmission on the DRB configured for SDT and data available for transmission on the DRB not configured for SDT are present.

14. The method of claim 13, wherein the configuration of the user equipment is performed via a Radio Resource Control (RRC) message.

15. The method of claim 14, wherein the RRC message triggers the user equipment to move from an RRC connected state to an RRC inactive state.

16. The method according to claim 13, The indication of the presence of data that can be transmitted on the DRB not configured for SDT is received via one of the following: Buffer Status Report (BSR) New media access control elements. Service Data Adaptation Protocol Control Protocol Data Unit Packet Data Convergence Protocol Control Protocol Data Unit Radio Link Control Protocol Data Unit, or Connection restored message, and The instruction is received via the BSR during the SDT process.

17. The method of claim 13, wherein configuring the user equipment includes configuring the user equipment to indicate what indication it should report in relation to the presence of the data that can be transmitted on the DRB not configured for SDT, and when or whether to trigger the report.

18. The method of claim 13, further comprising: Configure the user equipment to initiate SDT to transmit permitted uplink SDT data.

19. A device for communication, comprising: At least one processor; as well as At least one memory, the at least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: Determine the availability of data for transmission on a data radio bearer (DRB) not configured for SDT during the Small Data Transmission (SDT) process with network elements; as well as The at least one memory storage instruction, when executed by the at least one processor, causes the device, when data for transmission on the DRB not configured for SDT is available, to at least: While the SDT process is in progress, the network element is informed that the data is available for transmission on the DRB that is not configured for SDT; The SDT process is terminated.

20. A device for communication, comprising: At least one processor; as well as At least one memory, the at least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: Configure the user equipment to trigger SDT for data that can be transmitted on a data radio bearer (DRB) configured for small data transmission (SDT) and indicate the presence of data that can be transmitted on a DRB not configured for SDT; Receive SDT data transmissions, including data that can be used on the DRB configured for SDT; as well as Receive from the user equipment an indication of the existence of the data that can be transmitted on the DRB not configured for SDT. The configuration of the user equipment includes: configuring the user equipment to terminate the SDT process when both data available for transmission on the DRB configured for SDT and data available for transmission on the DRB not configured for SDT are present.

21. A device for communication, comprising: A means for determining the availability of data for transmission on a data radio bearer (DRB) not configured for SDT during a small data transmission (SDT) process with network elements; A means for instructing a network element, while the SDT process is in progress, that the data is available for transmission on the DRB not configured for SDT when the data for transmission on the DRB not configured for SDT is available. A means for suspending the SDT process when data for transmission on the DRB not configured for SDT is available.

22. The device of claim 21, further comprising: A means for determining the availability of data for transmission on a DRB configured for SDT; as well as A means for triggering the SDT process when it is determined that the data to be transmitted on the DRB configured for SDT is available.

23. The device according to claim 21, further comprising: A means for triggering a connection recovery process when it is determined that data for transmission on the DRB not configured for SDT is available.

24. The device according to claim 22, further comprising: A means for performing SDT on the network element using the data transmitted on the DRB configured for SDT.

25. The device according to claim 21, The means for instructing the network element that the data is available for transmission on the DRB not configured for SDT includes means for instructing the presence of the data in the buffer of the DRB not configured for SDT. The presence of the data in the buffer is indicated during the SDT process.

26. The device according to claim 21, Indicating to the network element that the data is available for transmission on the DRB not configured for SDT is performed via one of the following: Buffer Status Report (BSR), New Media Access Control (MAC) element, Service Data Adaptation Protocol (SDP) control protocol data element, Packet Data Convergence Protocol (PDCP) control protocol data element, Radio Link Control (RFC) control protocol data element, or Connection Resumption Message. The instruction transmitted via the BSR is transmitted during the SDT process.

27. The device according to claim 22, This is achieved by transmitting Radio Resource Control (RRC) messages to instruct the network element that the data is available for transmission on the DRB not configured for SDT, and The RRC message is multiplexed with the data of the DRB configured for SDT.

28. The device according to claim 22, The means for instructing the network element that the data is available for transmission on the DRB not configured for SDT includes means for indicating the presence of the data for transmission on the DRB configured for SDT and for transmission on the DRB not configured for SDT. The BSR information indicates the presence of the data for transmission on the DRB configured for SDT and the data for transmission on the DRB not configured for SDT.

29. The device according to claim 22, further comprising: Means for buffering the data to be transmitted on the DRB configured for SDT and the data to be transmitted on the DRB not configured for SDT.

30. The device of claim 21, wherein the abort is based on the priority of the data to be transmitted on the DRB configured for SDT or whether the data to be transmitted on the DRB configured for SDT has already been transmitted.

31. The device according to claim 21, further comprising: A means for buffering data for transmission on a DRB not configured for SDT while the SDT process is in progress, when data for transmission on the DRB not configured for SDT is available.

32. The device according to claim 31, further comprising: A means for triggering a connection recovery process for data transmitted on the DRB that is not configured for SDT after the SDT process is completed.

33. A device for communication, comprising: Means for configuring user equipment to trigger SDT for data that can be transmitted on a data radio bearer (DRB) configured for small data transmission (SDT) and to indicate the presence of data that can be transmitted on a DRB not configured for SDT; A means for receiving SDT data transmission including data that can be used on the DRB configured for SDT; as well as A means for receiving from the user equipment an indication of the existence of data that can be transmitted on the DRB not configured for SDT. The configuration of the user equipment includes: configuring the user equipment to terminate the SDT process when both data available for transmission on the DRB configured for SDT and data available for transmission on the DRB not configured for SDT are present.

34. The device of claim 33, wherein the configuration of the user equipment is performed via a Radio Resource Control (RRC) message.

35. The device of claim 34, wherein the RRC message triggers the user equipment to move from an RRC connected state to an RRC inactive state.

36. The device according to claim 33, The indication of the presence of data that can be transmitted on the DRB not configured for SDT is received via one of the following: Buffer Status Report (BSR) New media access control elements. Service Data Adaptation Protocol Control Protocol Data Unit Packet Data Convergence Protocol Control Protocol Data Unit Radio Link Control Protocol Data Unit, or Connection restored message, and The instruction is received via the BSR during the SDT process.

37. The apparatus of claim 33, wherein the means for configuring the user equipment includes means for configuring the user equipment to indicate what it should report in relation to the presence of the data that can be transmitted on the DRB not configured for SDT, and when or whether to trigger the report.

38. The device according to claim 33, further comprising: A means for configuring the user equipment to initiate SDT to transmit permitted uplink SDT data.

39. A computer-readable medium for communication, comprising program instructions that, when executed by a device, cause the device to perform at least the following operations: Determine the availability of data for transmission on a data radio bearer (DRB) not configured for SDT during the Small Data Transmission (SDT) process with network elements; The computer-readable medium includes program instructions that, when executed by the device, cause the device to perform at least the following operations when data for transmission on the DRB not configured for SDT is available: While the SDT process is in progress, the network element is informed that the data is available for transmission on the DRB that is not configured for SDT; The SDT process is terminated.

40. A computer-readable medium for communication, comprising program instructions that, when executed by a device, cause the device to perform at least the following operations: Configure the user equipment to trigger SDT for data that can be transmitted on a data radio bearer (DRB) configured for small data transmission (SDT) and indicate the presence of data that can be transmitted on a DRB not configured for SDT; Receive SDT data transmissions, including data that can be used on the DRB configured for SDT; and Receive from the user equipment an indication of the existence of the data that can be transmitted on the DRB not configured for SDT. The configuration of the user equipment includes: The user equipment is configured to terminate the SDT process if both data available for transmission on the DRB configured for SDT and data available for transmission on the DRB not configured for SDT are present.

Images