Methods and nodes for connected SDT for latency reduction

Abstract

There is provided performed by a user equipment (UE) for communications with a network node, the method comprises: receiving a configuration of resources, for uplink (UL) transmissions, to be used when the UE is in a connected state, the resources being shared with other UEs in the connected state; and in response to determining that conditions for the UL transmissions in the connected state are fulfilled, transmitting data to the network node, according to the received configuration. A UE for implementing this method is also provided.

Description

METHODS AND NODES FOR CONNECTED SDT FOR LATENCY REDUCTIONRELATED APPLICATIONS

[0001] This application claims the benefits of priority of U.S. Provisional Patent Application No. 63 / 599,277 entitled “Connected SDT for latency reduction” and filed at the United States Patent and Trademark Office (USPTO) on November 15, 2023, which is hereby incorporated by reference in its entirety.TECHNICAL FIELD

[0002] This disclosure relates to wireless network communications in which small data transmission in the connected mode is configured and used.BACKGROUND

[0003] New Radio (NR) Small Data Transmissions (SDT) in Inactive state

[0004] In Release (Rel)-17, mobile originated small data transmission (MO-SDT) was introduced for NR to reduce the signaling overhead for small uplink data payloads (see RP- 200954 ‘New Work Item on NR small data transmissions in INACTIVE state’). Two solutions were introduced, random access based SDT (RA-SDT) and configured grant SDT (CG-SDT). RA-SDT means that either legacy 4-step Random Access Channel (RACH) (or 2-step RACH) procedure is used as a baseline but that a user-plane data payload can be appended (multiplexed with the RRCResumeRequest message) in Msg3 (or MsgA). CG-SDT means that the User Equipments (UEs) configured via Radio Resource Control (RRC) to have periodic CG-SDT occasions can be used for contention-free uplink transmission. In this way, Msgl and Msg2 can be omitted but it is a requirement that the UE has a valid Timing Advance (TA) and is uplink synchronized to be able to use the resources for transmission.

[0005] For Narrowband (NB)-Internet of Things (loT) and Long Term Evolution (LTE)- Machine Type of communications (M) similar signaling optimizations for small data have been introduced through Rel-15 Early Data Transmission (EDT) and Rel-16 Preconfigured Uplink Resources (PUR). The main differences for the NR SDT solutions are that the Rel- 17 NR Small Data is only to be supported for RRC INACTIVE state. The Rel-17 Small data also includes the 2-step RACH based small data, that is supported by any NR UE (i.e. also mobile broadband (MBB) UEs and not limited to loT UEs) and supports transmission of subsequent data (i.e. larger payload sizes which require more than one transmission).

[0006] LTE support for mobile terminated transmissions (MT) was later introduced in Rel- 16, which supports transmissions of small data payloads in the downlink. Several solutions were considered: ‘Data in paging’ (multiple versions), ‘Data in Msg2’, and ‘Data in Msg4’ (seeoverview in RAN2 email discussion R2 .901.143 from RAN2#105). ‘Data in paging’ was first ruled out (see meeting report R2- 1903001), and later ‘Data in Msg2’ was ruled out (see UP MT-EDT email discussion outcome in R2- .1.9.10420, and meeting report in R2- 1.9.12001), and therefore ‘Data in Msg4’ was specified as the LTE solution. Note that for NB-IoT and LTE-M different solutions were introduced for the loT control-plane optimization (‘Data over Non Access Stratum (NAS)’, or DoNAS) and loT user-plane optimizations (RRC suspend / resume), Control Plane (CP)-EDT and User Plane (UP)-EDT, respectively, and that the NR solutions resemble the UP-EDT. For example, data can be sent during the random access procedure when the RRC connection has been suspended. Currently MT-SDT is being introduced in Rel-18 for NR. A Rel-18 MT-SDT work item description (WID) was approved in RAN#94e (Dec 2021) and can be found in RP-213583. The WID contains the following objectives:

[0007] Specify the support for paging-triggered SDT (MT-SDT) [RAN2, RAN3]

[0008] MT-SDT triggering mechanism for UEs in RRC INACTIVE, supporting RA-SDT and CG-SDT as the UL response;

[0009] MT-SDT procedure for initial DL data reception and subsequent UL / DL data transmissions in RRC INACTIVE.

[0010] Note: Data transmission in DL within paging message is not in scope of this WI. SUMMARY

[0011] There currently exist certain challenge(s). The delay in the Connected mode of a UE performing the legacy Scheduling Request (SR) procedure is not desirable. For example, a UE for which data arrive in the uplink buffer must trigger a SR to be transmitted on Physical Uplink Control Channel (PUCCH), if the TA is valid, wait for a grant, transmit a Buffer Status Report (BSR) on the Physical Uplink Shared Channel (PUSCH), potentially with a first part of the data, obtain a grant of suitable size to then transmit the rest of the data. The roundtrip for the SR and obtaining a grant lead to latency, that is longer than it needs to be.

[0012] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.

[0013] The embodiments herein allow to support SDT in RRC CONNECTED state or connected state, or contention-based transmission of the initial BSR+PUSCH, to reduce the uplink (UL) latency and control signaling overhead (and PUCCH resource consumption). The embodiments include, for example, changes to existing Rel-17 SDT procedure to make it applicable to UEs in RRC CONNECTED.

[0014] For example, there is provided a method in a UE, for SDT, when the UE is in the connected mode. The method may comprise: receiving a configuration of resources, for ULtransmissions, to be used when the UE is in a connected state, the resources being shared with other UEs in the connected state; and in response to determining that conditions for the UL transmissions in the connected state are fulfilled, transmitting data to the network node, according to the received configuration.

[0015] There is also provided a network node for SDT, with a UE in the connected mode. The method comprises transmitting a configuration of resources, for UL transmissions, to be used when the UE is in a connected state, the resources being shared with other UEs in the connected state; and receiving data from the UE, according to the transmitted configuration.

[0016] Certain embodiments may provide one or more of the following technical advantage(s).

[0017] Latency and control overhead for uplink transmissions in RRC CONNECTED are reduced, also PUCCH resource consumption (PUCCH capacity benefit) is reduced.BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Exemplary embodiments will be described in more detail with reference to the following figures, in which:

[0019] Fig. 1 illustrates a schematic example of a signaling comparison for a small uplink payload between A) the legacy SR procedure and B) the SDT in Connected using 2-step RA resources or CG resources, according to an embodiment.

[0020] Fig. 2 illustrates an example of a signal diagram of the C-SDT procedure, between a UE and a gNB, according to an embodiment.

[0021] Fig. 3 illustrates an exemplary flowchart for Connected-SDT configuration of a UE, according to an embodiment.

[0022] Fig. 4 is a schematic illustration of partially joint resources.

[0023] Fig. 5 illustrates an example of a flow chart of a method at the UE, according to an embodiment.

[0024] Fig. 6 illustrates an example of a flow chart of a method at the network node, according to an embodiment.

[0025] Fig. 7 shows an example of a communication system, according to an embodiment.

[0026] Fig. 8 shows a schematic diagram of a UE, according to an embodiment.

[0027] Fig. 9 shows a schematic diagram of a network node, according to an embodiment.

[0028] Fig. 10 illustrates a block diagram illustrating a virtualization environment.DETAILED DESCRIPTION

[0029] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0030] As a note, in this disclosure, the term “C-SDT” is interchangeably used for the procedure as well as the resources (C-SDT resources).

[0031] In the legacy procedure, as illustrated by Fig. 1 A, the UE will, upon data arrival for uplink transmissions, notify the network that is has data to transmit and need a grant to do so (since the UE does not have any uplink resources for transmission). This is done by the transmission of a SR on PUCCH to the gNB (in step 10). The gNB will then respond with providing the UE with an UL grant for transmission (step 12). Note, however, that the SR is just a flag and the gNB does not know the link quality of the UE and will therefore typically provide a small UL grant. The UE will then be able to transmit the data, either all of it or a first part along with a B SR to indicate to the network how much data it has left and how big the subsequent grant should be (step 14). In case the UL buffer was not emptied and the BSR was included, the gNB can then provide the UE with an UL grant of suitable size to either empty its buffer or transmit the next part of the data (step 16). Upon receipt of the UL grant, the UE transmits all the data (from the buffer), in step 18. Note that this is the case for when the UE’s ‘Timing Advance’ is still valid such that the UE has uplink synchronization and is allowed to use its assigned PUCCH resources for the SR transmission. If not, the UE will need to trigger a Random Access and in such a case, there is even longer latency and more overhead.

[0032] Fig. IB illustrates an example signaling diagram for transmitting small data between a UE and a gNB, with the UE being in the connected state, according to an embodiment. With this embodiment, the first two steps of Fig. 1 A can be avoided, and the UE can immediately transmit data (step 20) and, if needed, the data from the BSR can use the SDT resources to be transmitted. Compared to the legacy procedure of Fig. 1A, the UL Grant for the initial data transmission can also be larger, either determined autonomously by the UE (using Transport Block Size (TBS) selection, as in LTE Early Data Transmission) or by restriction to good coverage conditions (e.g., using a Reference Signal Received Power (RSRP)-threshold as in NR Small Data Transmission). Therefore, there is a larger chance that the UE can include all its data in the initial transmission, and the procedure can be terminated by the acknowledgement of that. In this case, the 5 signaling exchanges for the legacy procedure of Fig. 1A is reduced to only 1 signal for the Connected SDT (C-SDT) case (Fig. IB). This signaling reduction will reduce the uplink latency and the control overhead.

[0033] However, in case the first transmission cannot transmit all the data, the gNB can send a UL grant to the UE in step 22. Then, in step 24, the UE can transmit the rest of the data to the gNB, using the received UL grant.

[0034] There may be a drawback for the procedure of Fig. IB, e.g. the uplink transmission can be contention-based and collisions can occur. That is, in the legacy procedure, SR is transmitted on dedicated PUCCH resources without risk of collision. In contrast, in C-SDT, the resources are shared among all UEs in the connected state, i.e. the resources are common to all the UEs in the connected state to use. So, the signaling reduction of Fig. IB should be weighed against the risk of collision. However, since the C-SDT resources are common to all the UEs in the connected state, the network can afford to configure them more frequently in time, which, on top of the signaling reduction, can reduce the latency even further (compared to the legacy solution where PUCCH resources are relatively infrequent). Further, if a UE is configured with C-SDT, it doesn’t any longer need frequent PUCCH resources, so the embodiments herein can also reduce the PUCCH resource consumption. As a note, the total resource consumption reduction is dependent on a) the periodicity of the C-SDT resources, b) the periodicity of the PUCCH resources, and c) the number of UEs in the Connected state.

[0035] Note that the term ‘Connected SDT’ is used here since the solutions reuse parts of the Rel-17 SDT functionality (e.g. transmissions of data in Msg3 or MsgA), but for any standardization activity a more descriptive name may be applied, e.g., ‘Contention-based SR’.

[0036] As mentioned before, the benefits of the solutions / embodiments herein are reduced uplink latency, reduced control signaling overhead, and reduced PUCCH resource consumption (all in RRC Connected). The latency benefit has been evaluated by system level simulations, where it is found that the time from data arrival at the UE to the time data have been delivered to the gNB can be reduced almost five times, when a realistic PUCCH periodicity of 20ms is considered as the baseline (i.e., ~5x latency reduction), for example. Connected-SDT procedure

[0037] Now turning to Fig. 2, a signal diagram of a method / procedure 100 for C-SDT, as shown in Fig. 1 B, will be described. The method 100 comprises:

[0038] In step 105, the UE moves to the Connected mode / state (triggered by the data buffer having data, for example). The connected state can be the RRC Connected state.

[0039] Step 110: the UE is configured by the gNB to use C-SDT (e.g. C-SDT resources) via RRC signaling (for example) i.e., the gNB sends the C-SDT configuration to the UE. The configuration of C-SDT is determined based on C-SDT conditions, e.g. UE capable of C-SDT, matching QoS requirements, UE preference, coverage, etc.

[0040] Step 120: the data buffer, which triggered the move to the Connected mode, is emptied, i.e. the UE transmits all the data in the buffer to the gNB. Then, the inactivity timer is started, and the time elapses.

[0041] Step 130: the C-SDT is activated (or deactivated). The activation / deactivation can be jointly done with the C-SDT configuration / de-configuration for the UE via RRC (in step 110) or done dynamically based on Downlink Control Information (DCI).

[0042] Step 140: new data arrive in the UE.

[0043] Step 150: the UE triggers a C-SDT transmission on the configured resources(potentially only if the dynamic C-SDT conditions are fulfilled in step 130), either on new specific C-SDT resources, existing 2-step RA-SDT resources, or existing 2-step RACH resources.

[0044] In step 160, the UE checks the C-SDT conditions. If C-SDT conditions are met (e.g., C-SDT is configured for the data radio bearer (DRB) on which the data are received, measured RSRP above configured RSRP -threshold, the TA is valid, data size, QoS / latency requirement suitable for C-SDT, etc.) then, the UE transmits a C-SDT preamble (optional) and PUSCH with the UE’s Cell-Radio Network Temporary Identifier (C-RNTI), in step 180.

[0045] In step 170, the UE starts a timer, e.g. the CSDT-ResponseWindow timer (and possibly maintain a counter, e.g. the CSDT-counter, for comparison to the maximum number of attempts, CSDT-maxAttempts).

[0046] Step 180: the UE sends a C-SDT transmission to the gNB; the transmission may comprise data and C-SDT preambles, for example. The transmission may be sent in the first message (e.g. MsgA).

[0047] Step 190: the C-SDT transmission can result in three different cases:

[0048] Case ACK: the gNB successfully decodes the C-SDT PUSCH and sends an ACK (acknowledgement message) to the C-RNTI (of the UE) which was indicated in the uplink C- SDT transmission (in step 180) and / or subsequent UL grant if there are more data in the UE’s UL buffer according to the included BSR. For example, the ACK message could have the ACK legacy format.

[0049] Case NACK (decoding failure): the gNB receives the preamble but no PUSCH / data(if C-SDT includes the preamble part), or if the PUSCH’ s Cyclic Redundancy Check (CRC) is not clear. In this case, the gNB schedules a retransmission for C-SDT-RNTI (beneficial for coverage) or sends a hard Negative Acknowledgement (NACK) to trigger re-attempt (i.e., NACK without UL grant for retransmission).

[0050] Case NACK (lost transmission): when the CSDT-ResponseWindow timer expires, which is considered as an implicit NACK and considered as a failed C-SDT attempt, it will trigger a C-SDT re-attempt (or fall-back to the legacy procedure).

[0051] More details of the procedure 100 of Fig. 2 are provided below.

[0052] In one example in step 110, the UE is configured with C-SDT resources when moving to RRC CONNECTED, e.g., upon the RRC Connection Setup or Resume. In another example, the C-SDT resources can be the same as the 2-step RA resources or CG resources. They can be configured in system information (SI). In case of the 2-step RA resources, these can be configured as a new separate feature in the RRC FeatureCombination Information element (IE). There can also be specific FeatureCombinationPr eambles, i.e. specific preambles associated with C-SDT.

[0053] In one option, the CG resources configured for SDT can be used also for C-SDT. The configuration and activation of C-SDT for the UE is left to network implementation but the decision to configure and / or activate the C-SDT can be based on e.g., the following:

[0054] - Quality of Services (QoS) parameters for the UE, e.g., based on QoS-flow identifier (QFI), current services, or QoS latency requirements;

[0055] - The number of UEs in RRC CONNECTED;

[0056] - The PUCCH periodicity the UE would be configured with;

[0057] - gNB support of C-SDT; it could be implicit since the gNB would otherwise not consider configuring the UE with C-SDT;

[0058] - UE capability of C-SDT, e.g., C-SDT is introduced as an additional UE capability in the legacy UE capability reporting framework;

[0059] - The periodicity of C-SDT resources configured in the cell;

[0060] - UE C-SDT request or assistance information; the UE’s request to be configured with C-SDT is introduced via RRC signaling, e.g., as an additional RRC IE; a new parameter can be added to the existing UE assistance information. For example, the additional parameter indicates that the UE prefers to be configured with C-SDT (see the example ASN.1 below).

[0061] -Stored C-SDT configuration in UE context upon RRC Resumption; for example, a new Resume Cause can be introduced to indicate that the UE, upon resuming to CONNECTED, will be activating its stored C-SDT configuration.

[0062] - The Core Network (CN) can provide the UE’s C-SDT configuration to the gNB over NG-C, e.g., the C-SDT information is added to the UE context stored in the AMF, or subscription profile / information.

[0063] - If the UE initiated a Rel-17 RA-SDT or CG-SDT procedure and then was moved to RRC Connected by the gNB;

[0064] - If the UE’ s move to RRC Connected was initiated by the 2-step RACH procedure;

[0065] - If the UE was moved to RRC Connected after the Rel-18 MT-SDT procedure;

[0066] - In one alternative, if C-SDT is configured for a least one DRB or SRB, it is used for all DRBs / SRBs (the rationale being that it may be unnecessary to keep the PUCCH resources).

[0067] Fig. 3 illustrates a flowchart 200 for a Connected-SDT configuration of the UE. In step 210, the UE enters RRC-Connected (upon setup or resume). In step 220, it is determined if the UE is configured with C-SDT, based on some input (step 230), such as the conditions and information as described above. If it is determined that the UE is not configured with C- SDT in step 240, because the conditions are not fulfilled for example, then, the UE is configured to apply the legacy SR procedure on PUCCH upon UL data arrival (step 260). If the UE is configured with C-SDT in step 250, because the conditions of step 230 are fulfilled for example, then in step 270, the UE is configured to apply the C-SDT procedure upon UL data arrival.

[0068] The text below shows an ASN.1 example of the UE assistance information messageUEAssistancelnformation messageUEAs si stancelnformation : : = SEQUENCE { critical Ex tens ions CHOICE { ueAs si stancelnf orm tion UEAs s is tancelnf ormation- IBs , criticalEx tensions Future SEQUENCE { ))UEAs si stancelnformation-I Es : : = SEQUENCE {propagationDelayDi f ference-rl7 PropagationDelayDi f f erence-r 17

[0069] In one example, the C-SDT configured for the UE can be activated / de-activated (step 130 of Fig. 4) by any of the following:

[0070] - the C-SDT operation is configured and activated / deactivated for the UE using dedicated RRC signaling;

[0071] - the C-SDT operation is configured for the UE using dedicated RRC signaling but activated and deactivated using dynamic DCI; to do so, a new DCI format can be used, or a spare bit in the existing DCI format can be used or a reinterpretation of a field unused for the C-SDT UEs in the existing DCI format can be used;

[0072] - the C-SDT operation is configured for the UE using one of the above methods, but activated as part of a prior PDSCH transmission. Alternatively, the C-SDT resources can be configured as part of a PDSCH transmission (e.g. similar to RAR);

[0073] - the UE is configured with C-SDT, and the UE is paged with an indication to activate C-SDT upon resumption;

[0074] - After the expiration of a timer: for example, upon expiration of the new timer tc-SDT, the UE stops using PUCCH (i.e. releases its PUCCH resources) and instead relies on C- SDT. In a specific case, tc-sor is equal to the TA timer (the rationale being that UL sync is considered lost at the Timing Advance timer (TAT) expiration and PUCCH can no longer be used, and that then C-SDT is better than legacy triggering for RA).The timer is for example restarted at data activity (PUCCH, PUSCH or PDSCH), or legacy conditions are reused if a legacy timer is applied (e.g., TAT);

[0075] - Use of C-SDT (i.e., activation / deactivation) is UE autonomous based on coverage. For example, the C-SDT is activated when the measured RSRP is above a configured threshold (provided by the gNB through RRC signaling, for example) and deactivated when it is (equal to or) below the threshold. In one option, the RSRP -threshold is configured as part ofthe C-SDT configuration. In another option, the Rel-17 RSRP -threshold for RA-SDT is reused and applied as the configured threshold;

[0076] - the C-SDT is activated if the TA is valid, i.e., Timing Advance timer (either newC-SDT specific or legacy TAT) is running and has not expired;

[0077] - in one option, the CG resources are deactivated when the TAT expires. In this case, only RA resources for C-SDT are active or can be activated;

[0078] - the C-SDT is activated whenever there is data in any UE buffer associated with a DRB or Signaling Radio Bearer (SRB) for which the C-SDT has been configured, and the C- SDT is deactivated if there is no data in any of the DRBs and SRBs for which the C-SDT has been configured;

[0079] - the C-SDT can be activated / deactivated by an indication in SI broadcast, i.e., a flag indicates to the UEs if the C-SDT is allowed in the current (or subsequent) Broadcast Control Channel (BCCH) modification period, and the UEs are required to acquire SI at least once every BCCH modification period in order to use the C-SDT. If for example, the load and the collision probability on the C-SDT resources become too high, the gNB can deactivate C- SDT for all UEs in the cell with the use of this flag.

[0080] In one example, the UE needs to fulfil certain C-SDT conditions before it is allowed to use the C-SDT resources for transmission (see step 160 of Fig. 2 and step 230 of Fig. 3). These dynamic conditions are evaluated by the UE at C-SDT transmission initiation. The conditions can be one or more or any combination of the following:

[0081] - the C-SDT is configured for the DRB, or SRB, on which data are received. For example, the C-SDT is applied for one latency sensitive service (on DRB1) but not for another latency insensitive service (on DRB2). For example, data arrival on DRBs triggers the use of C-SDT, whereas data arrival on SRBs triggers the use of legacy SR on PUCCH.

[0082] - the Coverage is sufficient for C-SDT: RSRP measured by the UE is above a configured RSRP-threshold. For example, the UE is allowed to use C-SDT when the measured RSRP is above a configured threshold (provided by the gNB through RRC signaling, for example). In one case, the RSRP-threshold is configured as part of the C-SDT configuration. In another case, the Rel-17 RSRP-threshold for RA-SDT is reused and applied.

[0083] - The size of the data in the UL buffer is below a configured threshold. The UE is allowed to use C-SDT when the data in its uplink buffer is less than a data size threshold (e.g. configured by the gNB). In one case, the data size threshold is configured as part of the C-SDT configuration. In another case, the Rel-17 data size threshold for RA-SDT is reused and applied.

[0084] - the TA is evaluated as valid: C-SDT can be used by the UE if, according to UE internal evaluation, it still has a valid TA. The UE can evaluate the TA to still be valid based on for example one or more or any combination of the following conditions: a. A timer which was started upon the allocation of the TA or the TA update has not expired (similar to LTE PUR or NR CG-SDT). A new C-SDT specific timer or a legacy TA timer can be used. b. The UE measured RSRP has not changed more than a configured delta range since the TA was assigned, indicating that the UE has not moved much, i.e., RSRPmeasured - RSRPto < ARSRP (similar to LTE PUR). In an alternative two different delta thresholds, RSRPUPand RSRPDOW", are configured and used depending on if the RSRP is increasing or decreasing. The reference RSRP, RSRPto, is reset upon TA reassignment or update. c. The UE has not changed cells (similar to LTE PUR).

[0085] - The UE is still configured with PUCCH resources, and the time to the UE’s nextPUCCH resources is within a certain range compared to the time to the subsequent C-SDT resource. In this manner, the UE can select the resource which occurs first in time to reduce latency, with the possibility of a configurable offset; i.e., the UE shall transmit the SR on PUCCH if ttimeToPuccH - ttimeToC-SDT < toffset , where Z se?would typically be configured to 0 but could be ± X ms to have a bias for either access type.

[0086] In one example, the UE indicates its C-RNTI to the gNB in the initial C-SDT transmission for identification (see step 180 of Fig. 2, for example). In an example implementation, the UE shall include the existing ‘C-RNTI Media Access Control (MAC) Control Element (CE)’ in the C-SDT uplink transmission (see Section 6.1.3.2 of TS 38.321); i.e., ‘C-RNTI MAC CE’ is multiplexed with the user plane data (and potentially BSR) in the C-SDT PUSCH transmission. When received by the gNB, this allows the gNB to uniquely identify the UE and thereby address the ACK / NACK feedback or further UL grant to this C- RTNI (see Fig IB). In an alternative, the C-SDT uplink transmission is scrambled with the C- RNTI and the gNB performs blind decoding over all the C-RNTIs in use in the cell to find the matching UE (this case needs larger gNB processing effort but less signaling overhead compared to the MAC CE solution).

[0087] In one example, the C-SDT PUSCH transmission is scrambled with a CSDT-RNTI, and the gNB schedules Hybrid Automatic Repeat Request (HARQ) retransmissions to this CSDT-RNTI. After a C-SDT PUSCH transmission, the UE monitors the search space (duringCSDT-ResponseWindow , see below for more detail) with both CSDT-RNTI and C-RNTI. For example, the CSDT-RNTI is used for NACK and scheduling of a retransmission, and the C- RNTI is used for ACK and scheduling of subsequent data (since the ‘C-RNTI MAC CE’ was then successfully decoded). Alternatively, a pre-defined ID / sequence (or a preamble) can be sent along with UL data to the UE as part of the C-SDT transmission when the UE is scrambled by a common CSDT-RNTI. In such a case, the gNB responds with an ACK / NACK followed by the ID matching the pre-defined ID / sequence sent by the UE. Matching this ID can enable the UE to verify whether the transmission itself is being acknowledged or not. The CSDT- RNTI can either be a new RNTI mapped to the C-SDT PUSCH resource used, or the legacy RA-RNTI can be reused (e.g., if C-SDT is reusing 2-step RA-SDT resources or legacy 2-step RACH resources), or the legacy CG-SDT-CS-RNTI can be reused (e.g., if C-SDT is reusing legacy CG-SDT resources). In an alternative option, if legacy resources are reused (2-step RA- SDT, 2-step RACH, or CG-SDT), the CSDT-RNTI can on purpose be configured to be different from the RA-RNTI and CG-SDT-CS-RNTI such that the gNB can distinguish legacy UEs from C-SDT UEs when both are transmitting in the common resources. The gNB must then attempt to decode with e.g., both the RA-RNTI and CSDT-RNTI.

[0088] In one example, for instance, in step 180 of Fig. 2, the C-SDT transmission resources consist of periodically occurring preambles mapped to PUSCH (e.g., preamble+PUSCH pair) with a certain time offset, similar to the 2-step RACH or 2-step RA- SDT. C-SDT could then support Msgl indication via preamble partitioning to allow for the most suitable PUSCH grant for the SR use case (see the example described below regarding frequent tailormade TBS or C-SDT resources to fit C-RNTI and BSR). In an alternative example, the C-SDT transmission resources consist of periodically occurring PUSCH (without the preamble part), similar to the configured grant or CG-SDT. If user-plane data is to be included in the initial transmission (and not just BSR), the PUSCH transport block size of C- SDT must be larger than the 2-step RACH or CG and more similar to 2-step RA-SDT and CG- SDT. To the most latency reduction, the C-SDT resources would be configured to be more frequent than for the 2-step RACH, 2-step RA-SDT, or CG-SDT. The difference with the 2- step RA-SDT is that in C-SDT the UE is already in RRC CONNECTED, the RRCResumeRequest message is omitted in PUSCH and instead the ‘C-RNTI MAC CE’ is included. The difference with the 2-step RACH is that in C-SDT the UE is already in RRC CONNECTED, the RRCSetupRequest message is omitted in PUSCH and instead the ‘C- RNTI MAC CE’ is included. The difference with the CG-SDT is that the RRCResumeRequest message is omitted in PUSCH and instead the ‘C-RNTI MAC CE’ is included, and that thePUSCH is not scrambled with the C-RNTI but with the CSDT-RNTI (or RA-RNTI) instead. This is because the C-SDT PUSCH resource is common and not UE-specific. In one example, the C-SDT resources are tailormade to be very frequent, for maximal latency reduction, and to have a size that fits the ‘C-RNTI MAC CE’ and a BSR and not much else, but that can be supported on the cell-edge (also with a different RSRP-threshold than the RA-SDT, which would have a large TBS and higher RSRP-threshold). In one alternative, the C-SDT resources are joint with legacy resources, e.g., 2-step RA-SDT, see Fig. 4, and the difference in PUSCH content above indicates to the gNB whether it is a C-SDT UE or a legacy (e.g., 2-step RA- SDT) UE transmitting in the resources. In another alternative, the C-SDT indication can be explicit e.g., from any of the following: a) PUSCH scrambled with CSDT-RNTI which is different from legacy RNTI, b) a new C-SDT indication MAC CE, c) RRC indication, either as an extension to an existing RRC message or as a new RRC message. If C-SDT resources are joint with legacy resources, e.g., 2-step RA-SDT for the Inactive state, a way to maintain backwards compatibility could be that the legacy resource set is a subset of the C-SDT resource set, e.g., the C-SDT resource periodicity, tc-SDT, is configured as a fraction of the configured 2- step RA-SDT periodicity, IRA-SDT, such that, tRA-SDT,=n* tc-SDT, a legacy UE could still operate in the shared resources even though it cannot understand the new C-SDT signaling and configuration.

[0089] In one example, if C-SDT resources are joint with legacy resources, e.g., 2-step RA-SDT, see Fig. 4, a new indication can be introduced to indicate to Connected UEs if they are allowed to use the legacy (2-step RA-SDT) resources for C-SDT upon SR. The indication would be part of the C-SDT configuration, e.g., in common RRC signaling such as SI, or in the dedicated C-SDT configuration provided to the UE when it is moved to RRC CONNECTED (also via RRC signaling).

[0090] In one example, the UE is configured with a CSDT-ResponseWindow timer (see step 170 of Fig. 2). The CSDT-ResponseWindow is started by the UE upon C-SDT transmission. At the expiration of this timer, if there was no response from the gNB (in which case the timer is stopped), the UE will conclude that the C-SDT transmission was lost and will trigger a re-attempt (or fallback to the legacy procedure). Note that in order to have latency reduction benefits, the CSDT-ResponseWindow would have a lower range and would typically be configured to shorter values than the existing ra-ResponseWindow or MsgB- Response Window .

[0091] In one example, the UE can be configured with a CSDT-counter and an associated CSDT-maxAttempts (see step 170 of Fig. 2). The CSDT-counter is set to zero at the initialconfiguration of the C-SDT and reset to zero after a successful C-SDT transmission and is incremented at each C-SDT transmission. If the CSDT-counter becomes equal (or larger) than the configured CSDT-maxAttempts number, the UE will conclude that the C-SDT has failed and fallback to the legacy procedure (e.g., using the legacy SR if the UE still has PUCCH resources, or otherwise by triggering the RA in Connected). In an add-on to this, the UE can at this subsequent communication with the gNB inform the network about the C-SDT failure.

[0092] In one example, when the gNB receives a C-SDT transmission which cannot be successfully decoded, the gNB can reply to the UE, or all UEs that used the same C-SDT resources with a NACK (step 190 of Fig. 2). That is, a NACK without any UL grant for retransmission. This is in case the gNB does not have the possibility to schedule a retransmission (e.g., due to collision, in which case there would be a persistent collision also for the retransmission if both UEs are addressed with the CSDT-RNTI). The benefit of this example is the reduction of the latency by letting the UE know about the reception failure quickly, i.e., as opposed to letting the CSDT-ResponseWindow timer expires.

[0093] In one example, the UE upon unsuccessful C-SDT applies a random selection of the C-SDT resource for the re-attempt. The randomness can apply for example to the back-off time, time- and / or frequency-resources, or code resources (e.g., Demodulation (DM)- Reference Signal (RS)).

[0094] In one example, it is left to the network implementation how to configure PUCCH resources for a UE which is configured with C-SDT. If no PUCCH resources are scheduled for a C-SDT UE, the UE behavior is specified such that the UE triggers legacy Connected RA procedure upon a fallback from C-SDT (e.g., upon C-SDT failure, reaching CSDT- maxAttempts, C-SDT conditions are not fulfilled). In another case, the gNB can still configure the UE with more infrequent PUCCH resources (i.e., with longer periodicity), this as a failsafe mechanism, and when the CSDT-counter becomes equal (or larger) than the CSDT- maxAttemptsFS, the UE falls back to the legacy transmission of SR on PUCCH.

[0095] In one example, the UE is configured with a CSDTprohibitTimer as part of the C- SDT configuration. The UE starts the timer upon C-SDT transmission / initiation and the UE is not allowed to transmit again on C-SDT resources before the timer has expired.

[0096] Specification impact

[0097] In one example, the MAC triggering condition for SR is modified to allow for the use of C-SDT, see the following modification to TS 38.321 (v!7.5.0).

[0098] In one example, C-SDT is considered as a SR configuration among other SR configurations, see example of the proposed additions to TS 38.321 which are shown with text underline below:TS 38.321 :5.4.4 Scheduling RequestThe Scheduling Request (SR) is used for requesting UL-SCH resources for new transmission. The MAC entity may be configured with zero, one, or more SR configurations. An SR configuration consists of a set of PUCCH resources, or a Connected-SDT configuration, for SR across different BWPs and cells. For a logical channel or for SCell beam failure recovery (see clause 5.17) and for consistent LBT failure recovery (see clause 5.21), at most one PUCCH resource for SR is configured per BWP. For a logical channel serving a radio bearer configured with SDT, PUCCH resource for SR is not configured for SDT except for Connected-SDT. For beam failure recovery of BFD-RS set(s) of Serving Cell, up to two PUCCH resources, or Connected-SDT configurations, for SR is configured per BWP. For positioning measurement gap activation / deactivation request, a dedicated SR configuration is configured.<Text omitted>Only PUCCH resources on a BWP which is active at the time of SR transmission occasion are considered valid.As long as at least one SR is pending, the MAC entity shall for each pending SR:1> if the MAC entity has no valid PUCCH resource or no valid Connected-SDT resource configured for the pending SR:2> initiate a Random Access procedure (see clause 5.1) on the SpCell and cancel the pending SR. l>else, for the SR configuration corresponding to the pending SR:2> when the MAC entity has an SR transmission occasion on the valid PUCCH or Connected-SDT resource for SR configured; and2> if sr-ProhibitTimer is not running at the time of the SR transmission occasion; and 2> if the PUCCH or Connected-SDT resource for the SR transmission occasion does not overlap with a measurement gap:3> if the PUCCH or Connected-SDT resource for the SR transmission occasion overlaps with neither a UL-SCH resource whose simultaneous transmission with the SR is not allowed by configuration of simultaneousPUCCH-PUSCH orsimultaneousPUCCH-PUSCH-SecondaryPUCCHgroup or simultaneousSR- PUSCH-diffPUCCH-Groups nor an SL-SCH resource; or3> if the MAC entity is able to perform this SR transmission simultaneously with the transmission of the SL-SCH resource; or3> if the MAC entity is configured with Ich-basedPrioritization, and the PUCCH or Connected- SDT resource for the SR transmission occasion does not overlap with the PUSCH duration of an uplink grant received in a Random Access Response or with the PUSCH duration of an uplink grant addressed to Temporary C-RNTI or with the PUSCH duration of a MSGA payload, and the PUCCH resource for the SR transmission occasion for the pending SR triggered as specified in clause 5.4.5 overlaps with any other UL-SCH resource(s), and the physical layer can signal the SR on one valid PUCCH resource for SR, and the priority of the logical channel that triggered SR is higher than the priority of the uplink grant(s) for any UL-SCH resource(s) where the uplink grant was not already de-prioritized and its simultaneous transmission with the SR is not allowed by configuration of simultaneousPUCCH-PUSCH or simultaneousPUCCH-PUSCH- SecondaryPUCCHgroup or simultaneousSR-PUSCH-diffPUCCHgroups, and the priority of the uplink grant is determined as specified in clause 5.4.1; or<Text omitted>NOTE 6: When the MAC entity has PUCCH resource for pending SR for SCell beam failure recovery overlapping with PUCCH resource for pending SR for beam failure recovery of a BFD-RS set for the SR transmission occasion, it's up to UE implementation to select PUCCH resource for SCell beam failure recovery or PUCCH resource for beam failure recovery of a BFD-RS set.NOTE 7 : If the UE has obtained SR configuration with both PUCCH and C-SDT resources, it is up to UE implementation which one to use upon SR triggering.

[0099] In another option, when the SR is triggered by the BSR procedure, the SR procedure could be amended to trigger a C-SDT procedure instead of a PUCCH transmission or legacy Random Access procedure as in the following additions (shown as underlined text) to TS 38.321, section 5.4.4. The statement “configured and valid” should here be understood to mean that the triggered BSR and the corresponding data are allowed to use C-SDT. This canbe the case both if PUCCH resources are configured, e.g. if there is a latency requirement as previously described, or if no PUCCH resources are configured for the triggered BSR.5.4.4 Scheduling RequestThe Scheduling Request (SR) is used for requesting UL-SCH resources for new transmission. The MAC entity may be configured with zero, one, or more SR configurations.[text omitted]As long as at least one SR is pending, the MAC entity shall for each pending SR:1> if the MAC entity has no valid PUCCH resource configured for the pending SR:2> if the SR is triggered by the BSR procedure and C-SDT resources are configured and valid:3> initiate a C-SDT procedure and transmit the BSR and if the grant can accomadate it, additional data.2> else, initiate a Random Access procedure (see clause 5,1) on the SpCell and cancel the pending SR. l>else, for the SR configuration corresponding to the pending SR:2> if the SR is triggered by the BSR procedure and C-SDT resources are configured and valid:3> initiate a C-SDT procedure and transmit the BSR and if the grant can accomadate it, additional data.2> else, when the MAC entity has an SR transmission occasion on the valid PUCCH resource for SR configured; and2> if sr-ProhibitTimer is not running at the time of the SR transmission occasion; and [text omitted]

[0100] In another example, the SR is never triggered, but rather the BSR is transmitted using C-SDT, if configured. For example, using the following modification of TS 38.321 (changes are underlined).A BSR shall be triggered if any of the following events occur for activated cell group:- UL data, for a logical channel which belongs to an LCG, becomes available to the MAC entity; and either- this UL data belongs to a logical channel with higher priority than the priority of any logical channel containing available UL data which belong to any LCG; or- none of the logical channels which belong to an LCG contains any available UL data.- Connected mode SDT has been configured for the logical channel and the LCG to which the UL data is associated. in which case the BSR is referred below to as 'Regular BSR';- UL resources are allocated, or the UE is configured with Connected mode SDT. and number of padding bits is equal to or larger than the size of the Buffer Status Report MAC CE plus its subheader, in which case the BSR is referred below to as 'Padding BSR';- retxBSR-Timer expires, and at least one of the logical channels which belong to an LCG contains UL data, in which case the BSR is referred below to as 'Regular BSR';- periodicBSR-Timer expires, in which case the BSR is referred below to as 'Periodic BSR'.

[0101] Now turning to Fig. 5, a flow chart of a method 300 for small data transmission in the connected state (C-SDT) will be described. It is to be understood that the functions / acts / steps noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved.

[0102] The method 300 may be performed by the UE, such as UE 712 of Fig. 7 and 800 of Fig. 8. Method 300 comprises:

[0103] Step 310: receiving a configuration of resources, for uplink (UL) transmissions, to be used when the UE is in a connected state, the resources being shared with other UEs in the connected state (e.g. RRC Connected state); and

[0104] Step 320: in response to determining that conditions for the UL transmissions in the connected state are fulfilled, transmitting data to the network node, according to the received configuration.

[0105] It should be noted that the configuration in step 310 may be received while the UE is still in the idle state or inactivated state. The configuration can be received when the UE is already in the connected state as well.

[0106] In some examples, the transmitted data are from a buffer status. The UE may transmit a BSR. In some examples, the UE may receive an indication of activation of the configuration of resources, for the UL transmissions for the UE in the connected state. For example, the indication can be received in DCI (e.g. new DCI format, using a spare bit in DCI, etc.) or via RRC signalling. In some examples, the configuration may comprise an indication of resources for the C-SDT. In some examples, the resources can be 2-step RA resources orCG resources. In some examples, the resources are periodically occurring preambles mapped to PUSCH (e.g., preamble+PUSCH pair) with a certain time offset. The resources can be also periodic common PUSCH resources. In some examples, the resources are joint with the legacy resources, e.g., 2-step RA-SDT for a RRC Idle and RRC Inactive state. In some examples, the UE may send a UE capability message to the network node, the UE capability message indicating UE capability to support the shared resources for UL transmissions in the connected state. In some examples, determining the conditions may comprise determining that one or more of a measured RSRP of a channel is above a power / signal strength threshold, a timing advance is valid, a data size is below a size threshold, and QoS or latency requirements are suitable. In some examples, the signal strength threshold can be a Rel-17 RSRP threshold and is comprised in the configuration. In some examples, the size threshold can be is a Rel-17 data size threshold and is comprised in the configuration. In some examples, the UE may further transmit C-SDT preambles. In some examples, the UE may transmit a C-RNTI in an initial transmission of data. In some examples, the UE may start a timer (e.g. CSDT- ResponseWindow) and / or a counter (CSDT-counter) upon transmitting the data to the network node. In some examples, in response to transmitting the data, the UE receives one of an ACK or NACK. In some examples, the UE can transmit the data in a first message (Msgl), upon arrival of new data in a UL buffer.

[0107] Now turning to Fig. 6, a flow chart of an example method 400 for SDT in the connected state (C-SDT) of a UE will be described. It is to be understood that the functions / acts / steps noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved.

[0108] The method 400 may be performed by the network node, such as 710 of Fig. 7 and 900 of Fig. 9. Method 400 comprises:

[0109] Step 410: transmitting a configuration of resources, for uplink (UL) transmissions, to be used when the UE is in a connected state, the resources being shared with other UEs in the connected state; and

[0110] Step 420: receiving data from the UE, according to the transmitted configuration. [OHl] It should be noted that the configuration in step 410 may be transmitted while the UE is still in the idle state or inactivated state. The configuration can be transmitted when the UE is already in the connected state as well.

[0112] In some examples, the received data are from a BSR. In addition, the gNB can receive the BSR, from the UE. In some examples, the network node may send an indication of activation of the configuration of resources for the UL transmissions, for the UE in the connected state. In some examples, the indication can be transmitted in DCI (e.g. new DCI format, using a spare bit in DCI, etc.) or via RRC signalling. In some examples, the configuration can comprise an indication of resources for the C-SDT. In some examples, the resources can be 2-step RA resources or CG resources. In some examples, the resources are periodically occurring preambles mapped to PUSCH (e.g., preamble+PUSCH pair) with a certain time offset. The resources can be also periodic common PUSCH resources. In some examples, the resources are joint with legacy resources, e.g., 2-step RA-SDT for an RRC Idle and RRC Inactive state. In some examples, the network node may receive a UE capability message from the UE, the UE capability message indicating UE capability to support C-SDT, e.g. to support the shared resources for UL transmissions in the connected state. In some examples, the network node may receive C-SDT preambles. In some examples, the network node may receive a C-RNTI in an initial transmission of data. In some examples, in response to receiving the data, the network node may transmit one of an ACK or NACK. In some examples, the configuration for UL transmissions is transmitted either when the UE is in an idle state, in an inactivate state, or in the connected state. In some examples, the network node may receive the data in the first message (e.g. Msgl).

[0113] Fig. 7 shows an example of a communication system 700 in accordance with some embodiments.

[0114] In the example, the communication system 700 includes a telecommunication network 702 that includes an access network 704, such as a radio access network (RAN), and a core network 706, which includes one or more core network nodes 708. The access network 704 includes one or more access network nodes, such as network nodes 710a and 710b (one or more of which may be generally referred to as network nodes 710), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 702 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 702 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similarorganization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 702, including one or more network nodes 710 and / or core network nodes 708.

[0115] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O- CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the 0-RAN Alliance or comparable technologies. The network nodes 710 facilitate direct or indirect connection of UE, such as by connecting UEs 712a, 712b, 712c, and 712d (one or more of which may be generally referred to as UEs 712) to the core network 706 over one or more wireless connections.

[0116] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 700 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 700 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0117] The UEs 712 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 710 and other communication devices. Similarly, the network nodes 710 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 712 and / or with other network nodes or equipment in the telecommunication network 702to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 702.

[0118] In the depicted example, the core network 706 connects the network nodes 710 to one or more hosts, such as host 716. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 706 includes one more core network nodes (e.g., core network node 708) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 708. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function.

[0119] The host 716 may be under the ownership or control of a service provider other than an operator or provider of the access network 704 and / or the telecommunication network 702, and may be operated by the service provider or on behalf of the service provider. The host 716 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0120] As a whole, the communication system 700 of Fig. 7 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); LTE, and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near FieldCommunication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0121] In some examples, the telecommunication network 702 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 702 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 702. For example, the telecommunications network 702 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0122] In some examples, the UEs 712 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 704 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 704. Additionally, a UE may be configured for operating in single- or multi -RAT or multi -standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) NR - Dual Connectivity (EN-DC).

[0123] In the example, the hub 714 communicates with the access network 704 to facilitate indirect communication between one or more UEs (e.g., UE 712c and / or 712d) and network nodes (e.g., network node 710b). In some examples, the hub 714 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 714 may be a broadband router enabling access to the core network 706 for the UEs. As another example, the hub 714 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 710, or by executable code, script, process, or other instructions in the hub 714. As another example, the hub 714 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 714 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 714 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 714 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 714 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0124] The hub 714 may have a constant / persi stent or intermittent connection to the network node 710b. The hub 714 may also allow for a different communication scheme and / or schedule between the hub 714 and UEs (e.g., UE 712c and / or 712d), and between the hub 714 and the core network 706. In other examples, the hub 714 is connected to the core network 706 and / or one or more UEs via a wired connection. Moreover, the hub 714 may be configured to connect to an M2M service provider over the access network 704 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 710 while still connected via the hub 714 via a wired or wireless connection. In some embodiments, the hub 714 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 710b. In other embodiments, the hub 714 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 710b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0125] Fig. 8 shows a UE 800 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3 GPP, including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0126] A UE may support device-to-device (D2D) communication, for example by implementing a 3 GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle- to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0127] The UE 800 includes processing circuitry 802 that is operatively coupled via a bus 804 to an input / output interface 806, a power source 808, a memory 810, a communication interface 812, and / or any other component, or any combination thereof. Certain UEs mayutilize all or a subset of the components shown in Fig. 8. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0128] The processing circuitry 802 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 810. The processing circuitry 802 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays, application specific integrated circuits, etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 802 may include multiple central processing units (CPUs). Further, the processing circuitry 802 is configured to perform any steps of method 300 of Fig. 5.

[0129] In the example, the input / output interface 806 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 800. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0130] In some embodiments, the power source 808 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 808 may further include power circuitry for delivering power from the power source 808 itself, and / or an external power source, to the various parts of the UE 800 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of thepower source 808. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 808 to make the power suitable for the respective components of the UE 800 to which power is supplied.

[0131] The memory 810 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically EPROM (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 810 includes one or more application programs 814, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 816. The memory 810 may store, for use by the UE 800, any of a variety of various operating systems or combinations of operating systems.

[0132] The memory 810 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD- DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 810 may allow the UE 800 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 810, which may be or comprise a device-readable storage medium.

[0133] The processing circuitry 802 may be configured to communicate with an access network or other network using the communication interface 812. The communication interface 812 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 822. The communication interface 812 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 818 and / or a receiver 820 appropriate to provide network communications (e.g., optical, electrical,frequency allocations, and so forth). Moreover, the transmitter 818 and receiver 820 may be coupled to one or more antennas (e.g., antenna 822) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0134] In the illustrated embodiment, communication functions of the communication interface 812 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, NR, UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0135] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 812, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0136] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0137] A UE, when in the form of an loT device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler,an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE 800 shown in Fig. 8.

[0138] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3 GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0139] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’ s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0140] Fig. 9 shows a network node 900 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs (NBs), evolved NBs (eNBs) and NR NBs (gNBs)), 0-RAN nodes or components of an O-RAN node (e g., 0-RU, 0-DU, O-CU).

[0141] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an 0-RAN access node)and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0142] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi -standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi -cell / multi cast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0143] The network node 900 includes a processing circuitry 902, a memory 904, a communication interface 906, and a power source 908. The network node 900 may be composed of multiple physically separate components (e.g., a NB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 900 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NBs. In such a scenario, each unique NB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 900 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 904 for different RATs) and some components may be reused (e.g., a same antenna 910 may be shared by different RATs). The network node 900 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 900, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 900.

[0144] The processing circuitry 902 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logicoperable to provide, either alone or in conjunction with other network node 900 components, such as the memory 904, to provide network node 900 functionality.

[0145] In some embodiments, the processing circuitry 902 includes a system on a chip (SOC). In some embodiments, the processing circuitry 902 includes one or more of radio frequency (RF) transceiver circuitry 912 and baseband processing circuitry 914. In some embodiments, the RF transceiver circuitry 912 and the baseband processing circuitry 914 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 912 and baseband processing circuitry 914 may be on the same chip or set of chips, boards, or units. Further, the processing circuitry 902 is configured to perform any steps of method 400 of Fig. 6.

[0146] The memory 904 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), ROM, mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 902. The memory 904 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 902 and utilized by the network node 900. The memory 904 may be used to store any calculations made by the processing circuitry 902 and / or any data received via the communication interface 906. In some embodiments, the processing circuitry 902 and memory 904 is integrated.

[0147] The communication interface 906 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 906 comprises port(s) / terminal(s) 916 to send and receive data, for example to and from a network over a wired connection. The communication interface 906 also includes radio front-end circuitry 918 that may be coupled to, or in certain embodiments a part of, the antenna 910. Radio front-end circuitry 918 comprises filters 920 and amplifiers 922. The radio front-end circuitry 918 may be connected to an antenna 910 and processing circuitry 902. The radio front-end circuitry may be configured to condition signals communicated between antenna 910 and processing circuitry 902. The radio front-end circuitry 918 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 918 may convert the digital data into a radio signalhaving the appropriate channel and bandwidth parameters using a combination of filters 920 and / or amplifiers 922. The radio signal may then be transmitted via the antenna 910. Similarly, when receiving data, the antenna 910 may collect radio signals which are then converted into digital data by the radio front-end circuitry 918. The digital data may be passed to the processing circuitry 902. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0148] In certain alternative embodiments, the network node 900 does not include separate radio front-end circuitry 918, instead, the processing circuitry 902 includes radio front-end circuitry and is connected to the antenna 910. Similarly, in some embodiments, all or some of the RF transceiver circuitry 912 is part of the communication interface 906. In still other embodiments, the communication interface 906 includes one or more ports or terminals 916, the radio front-end circuitry 918, and the RF transceiver circuitry 912, as part of a radio unit (not shown), and the communication interface 906 communicates with the baseband processing circuitry 914, which is part of a digital unit (not shown).

[0149] The antenna 910 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 910 may be coupled to the radio front-end circuitry 918 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In some examples, the antenna 910 is separate from the network node 900 and connectable to the network node 900 through an interface or port.

[0150] The antenna 910, communication interface 906, and / or the processing circuitry 902 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 910, the communication interface 906, and / or the processing circuitry 902 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0151] The power source 908 provides power to the various components of network node 900 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 908 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 900 with power for performing the functionality described herein. For example, the network node 900 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source suppliespower to power circuitry of the power source 908. As a further example, the power source 908 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0152] Embodiments of the network node 900 may include additional components beyond those shown in Fig. 9 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 900 may include user interface equipment to allow input of information into the network node 900 and to allow output of information from the network node 900. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 900.

[0153] Fig. 10 is a block diagram illustrating a virtualization environment 1000 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1000 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1000 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[0154] Applications 1002 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0155] Hardware 1004 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers1006 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1008a and 1008b (one or more of which may be generally referred to as VMs 1008), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1006 may present a virtual operating platform that appears like networking hardware to the VMs 1008.

[0156] The VMs 1008 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1006. Different embodiments of the instance of a virtual appliance 1002 may be implemented on one or more of VMs 1008, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0157] In the context of NFV, a VM 1008 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1008, and that part of hardware 1004 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1008 on top of the hardware 1004 and corresponds to the application 1002.

[0158] Hardware 1004 may be implemented in a standalone network node with generic or specific components. Hardware 1004 may implement some functions via virtualization. Alternatively, hardware 1004 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1010, which, among others, oversees lifecycle management of applications 1002. In some examples, hardware 1004 is coupled to one or more radio units (RUs) that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. RUs may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, e.g. a radio access node or a base station. In some examples, some signaling can be provided with the use of a control system 1012 which may alternatively be used for communication between hardware nodes and RUs.

[0159] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments maycomprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0160] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0161] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

CLAIMS1. A method (300) performed by a user equipment (UE 712, 800) for communications with a network node (710, 900), the method comprising:- receiving (310) a configuration of resources, for uplink (UL) transmissions, to be used when the UE is in a connected state, the resources being shared with other UEs in the connected state; and- in response to determining that conditions for the UL transmissions in the connected state are fulfilled, transmitting (320) data to the network node, according to the received configuration.

2. The method of claim 1, further comprising receiving an indication of activation of the configuration of resources for the UL transmissions, for the UE in the connected state.

3. The method of claim 2, wherein the indication is received in Downlink Control Information (DCI) or via Radio Resource Control (RRC) signalling.

4. The method of any one of claims 1 to 3, wherein the resources are one of 2-step Random Access (RA) resources and Configured Grant (CG) resources.

5. The method of any one of claims 1 to 4, wherein the resources are one of periodically occurring preambles mapped to Physically Uplink Shared Control Channel (PUSCH) with a certain time offset and periodic common PUSCH resources.

6. The method of any one of claims 1 to 4, wherein the resources are joint with legacy resources for a 2-step RA-Small Data Transmission (SDT) for a Radio Resource control (RRC) Idle and RRC Inactive state.

7. The method of any one of claims 1 to 6, further comprising sending a UE capability message to the network node, the UE capability message indicating UE capability to support the shared resources for UL transmissions in the connected state.

8. The method of any one of claims 1 to 7, wherein determining the conditions comprises determining that one or more of a measured Reference Signal Received Power (RSRP) of a channel is above a signal strength threshold, a timing advance is valid, a data size is below a size threshold, and Quality of Service (QoS) or latency requirements are suitable.

9. The method of claim 8, wherein the signal strength threshold is a Rel-17 RSRP threshold and is comprised in the configuration.

10. The method of claim 8 or 9, wherein the size threshold is a Rel-17 data size threshold and is comprised in the configuration.

11. The method of any one of claims 1 to 10, wherein an initial transmission of data comprises a Cell- Radio Network Temporary Identifier (C-RNTI).

12. The method of any one of claims 1 to 11, further comprising starting a timer and / or a counter upon transmitting the data to the network node.

13. The method of any one of claims 1 to 12, further comprising, in response to transmitting the data, receiving one of an acknowledgment (ACK) or negative ACK (NACK).

14. The method of any one of claims 1 to 13, wherein the configuration for UL transmissions is received either the UE is in an idle state, in an inactivate state, or in the connected state.

15. The method of any one of claims 1 to 14, further comprising transmitting a Buffer Status Report (BSR) to the network.

16. The method of any one of claims 1 to 15, wherein transmitting the data comprises transmitting the data in a first message, upon arrival of new data in a UL buffer.

17. A method (400) performed by a network node (710, 900) for communicating with a user equipment (UE, 712, 800), the method comprising:- transmitting (410) a configuration of resources, for uplink (UL) transmissions, to be used when the UE is in a connected state, the resources being shared with other UEs in the connected state; and- receiving (420) data from the UE, according to the transmitted configuration.

18. The method of claim 17, further comprising transmitting an indication of activation of the configuration of resources for the UL transmissions, for the UE in the connected state.

19. The method of claim 18, wherein the indication is transmitted in Downlink Control Information (DCI) or via Radio Resource Control (RRC) signalling.

20. The method of any one of claims 17 to 19, wherein the resources are one of 2-step Random Access (RA) resources and Configured Grant (CG) resources.

21. The method of any one of claims 17 to 20, wherein the resources are one of periodically occurring preambles mapped to Physically Uplink Shared Control Channel (PUSCH) with a certain time offset and periodic common PUSCH resources.

22. The method of any one of claims 17 to 20, wherein the resources are joint with legacy resources for a 2-step RA-Small Data Transmission (SDT) for an RRC Idle and RRC Inactive state.

23. The method of any one of claims 17 to 22, further comprising receiving a UE capability message from the UE, the UE capability message indicating UE capability to support the shared resources for UL transmissions in the connected state.

24. The method of any one of claims 17 to 23, wherein an initial reception of the data comprises a C-RNTI.

25. The method of any one of claims 17 to 24, further comprising, in response to receiving the data, transmitting one of an ACK or NACK.

26. The method of any one of claims 1 to 25, wherein the configuration for UL transmissions is transmitted either when the UE is in an idle state, in an inactivate state, or in the connected state.

27. The method of any one of claims 17 to 26, further comprising receiving a Buffer Status Report (BSR) from the UE.

28. The method of any one of claims 17 to 27, wherein receiving the data comprises receiving the data in a first message.

29. A user equipment (712, 800), comprising processing circuitry (802) and a network interface (812) connected thereto, the processing circuitry (802) configured to perform the method of any one of claims 1 to 16.

30. A network node (710, 900) comprising processing circuitry (902) and a network interface (906) connected thereto, the processing circuitry (902) configured to perform the method of any one of claims 17 to 28.

31. A computer program product comprising a computer readable memory storing computer executable instructions thereon that when executed by a computer perform any one of the methods of any one of claims 1 to 28.

Images