Method and apparatus for data transmission without rach

Abstract

While a user equipment (UE) is in a non-connected (e.g. RRC-IDLE or RRC-INACTIVE) mode, the UE measures reference signal received power (RSRP) for a serving cell and, based on the measured RSRP being

Description

BACKGROUND Field

[0001] Certain examples of the present disclosure relate to methods, apparatus and / or systems for performing RACH-less data transmission, such as RACH-less EDT. Various examples provide one or more conditions under which RACH-less data transmission is performed, e.g. by a UE. Various examples describe howto select resources for RACH-less data transmission, such as PUSCH resources for EDT without RACH. Other examples relate to performing EDT in different ways depending on radio conditions, such as configuring a higher number of PUSCH repetitions for lower RSRP. Yet other examples relate to procedures for fallback in the event of RACH-less data transmission failure, such as UE controlled or network controlled fallback. Description of Related Art

[0002] The content of the following documents is referred to below and / or their content provides background information that the following disclosure should be considered in the context of: [1] 3GPP RP-202689 - MediaTek Inc., “New Study WID on NB-loT / eTMC support for NTN”-, 3GPP TSG RAN Meeting #90; Electronic Meeting, December?- 11, 2020. [2] 3GPP RP-211557 - Thales, “Solutions for NR to support nonterrestrial networks (NTN)’’-, 3GPP TSG RAN meeting #91-e; e-meeting, March 22-26th, 2021. [3] 3GPP RP-220953 - Thales, “NR NTN (Non-Terrestrial Networks) enhancements”-, 3GPP TSG RAN Meeting #95e; Electronic Meeting, March 17-23, 2022. [4] 3GPP RP-223519 - MediaTek Inc., “Revised WID on loT NTN enhancements”; 3GPPTSG RAN Meeting #98e; Electronic, 12-16 December 2022. [5] 3GPP RP-234077 - Deutsche Telekom (moderator, RAN VC), “New WID: Non-Terrestrial Networks (NTN) for Internet of Things (loT) Phase 3”; 3GPP TSG RAN Meeting #102; Edinburgh, Scotland, December 11-15, 2023. [6] 3GPP TS 38.331 - 5G; NR; Radio Resource Control (RRC); Protocol specification, Release 18 (e.g., V18.0.0). [7] 3GPP TS 36.331 - Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification, Release 18 (e.g. V18.0.0). Note: indicated version numbers are provided for illustrative purposes, other (including future) versions of these documents are considered also.

[0003] Wireless or mobile (cellular) communications networks in which a mobile terminal (e.g., user equipment (UE), such as a mobile handset) communicates via a radio link with a network of base stations, or other wireless access points or nodes, have undergone rapid development through a number of generations. The 3rd Generation Partnership Project (3GPP) design, specify and standardise technologies for mobile wireless communication networks. Fourth Generation (4G) and Fifth Generation (5G) systems (5GS) are now widely deployed, while beyond 5G (B5G) and 6G systems are being considered.

[0004] 3GPP standards for 4G systems include an Evolved Packet Core (EPC) and an Enhanced-UTRAN (E-UTRAN: an Enhanced Universal Terrestrial Radio Access Network). The E-UTRAN uses Long Term Evolution (LTE) radio technology. LTE is commonly used to refer to the whole system including both the EPC and the E-UTRAN, and LTE is used in this sense in the remainder of this document. LTE should also be taken to include LTE enhancements such as LTE Advanced and LTE Pro, which offer enhanced data rates compared to LTE.

[0005] In 5G systems a new air interface has been developed, which may be referred to as 5G New Radio (5G NR) or simply NR. NR is designed to support the wide variety of services and use case scenarios envisaged for 5G networks, though builds upon established LTE technologies B5G systems, such as 6G, are currently being considered and developed, and are expected to at least partly build on 5G systems.

[0006] New frameworks and architectures are being developed as part of 5G network (and beyond, such as 6G networks) in order to increase the range of functionality and use cases available through 5G networks.

[0007] loT (Internet of Things) NTN (Non-Terrestrial Network) was a 3GPP study and work item in 3GPP release 17 to provide Non-Terrestrial Network access for E-UTRAN loT devices (NB-loT (Narrowband-loT) and LTE-M / eMTC (Long-Term Evolution Machine Type Communication / enhanced machine-type communication)) (RP-202689 [1]].

[0008] An example of a NTN is shown in Figure 1. The NTN is shown to comprise NTN cell 110 and a NTN entity 180 associated with (e.g. controlling or configuring) NTN cell 110. The NTN entity 180 is connected to a gateway 120 via feeder link 170. The gateway 120 is connected to eNB / gNB 130, which communicates with core network 140. It will be appreciated that gateway and eNB / gNB 130 may be colocated or implemented together. A UE 150 is located with NTN cell 110. The UE 150 is connected to NTN entity 180 via access link 160. Accordingly, the UE 150 is connected to core network 140 via the NTN entity 180.

[0009] NR NTN was a work item in Rei-17 to specify adaptation to allow NR to function over NTN (RP-211557 [2]). Non-Terrestrial Network access may be through Lower Earth Orbit (LEO), Medium Earth Orbit (MEO) and Geostationary Orbit (GEO), as well as through High-Altitude Platform Systems (HAPS).

[0010] Following the Work items in Release 17 there were work items to enhance NR NTN (RP-220953 [3]) and loT NTN (RP-223519 [4]) in Release 18.

[0011] The work item description for loT NTN Rel-19 is the following (RP-234077 [5]): • Support of Store&Forward (S&F) satellite operation with full eNB as regenerative payload, therefore-. o Define the necessary enhancements into E-UTRAN (network &UE) to support S&F operation for delay-tolerant services I RANS, RAN2, RANH] ■ At least specify necessary enhancements e.g. related to SI protocol, especially to address the feeder link switch over as needed [RAN3] Note: Strive to minimise UE impact. Note: Coordination with SA2 (Rel-19 SA2 led Sat-Arch ph3 SI) is needed on the detail requirements (e.g. traffic type, or QoS parameters for S&F), network architecture (e.g. whether consider (partial) core network on satellite) etc.; further coordination with CT1 might be required • Support of Capacity enhancements for uplink o Study then specify, if beneficial, enhancements to enable multiplexing of multiple UEs (e.g. up to the min of 4 and the maximum allowed by the existing UL and DL signalling) in a single 3.75 kHz or 15 kHz subcarrier via orthogonal cover codes (OCC)for NPUSCH format 1 and NPRACH [RANI, RAN2] ■ Multi-tone support for 15 kHz SCS should also be considered Note: Impact of impairment shall be taken into account o Study and specify, if beneficial the following enhancements to reduce the necessary uplink and downlink signaling to complete an EDT transaction [RAN2]: ■ Msg3 transmission without msgl / RAR ■ Efficient delivery (reduced overhead) ofmsg4 / RRCEarlyDataComplete

[0012] Narrowband Internet of Things and LTE-M

[0013] Narrowband Internet of Things (NB-loT) is a 3GPP-defined network based on 4G E-UTRAN that supports ultra-low complexity devices with very narrow bandwidth that was introduced in 3GPP Release 13. It supports the massive Machine Type Communication (mMTC) 5G use case for IMT-2020. The use case of NB-loT is to serve massive loT application, where requirements for instance are to support enhanced coverage, power-efficient operation and a massive number of devices. Some of the features introduced are: — Support for enhanced coverage through low bandwidth and extreme amounts of repetitions. — Power efficient operation by allowing the UE to sleep for very long times, relaxed requirements and more efficient signal to establish with a cell.

[0014] LTE-M (or eMTC) is another technology that serves the mMTC 5G use case. Compared to NB-loT, an LTE-M device is more like a simplified 4G E-UTRAN device with certain simplifications allowing for easier and cheaper implementation. It addressed a slight wider use case compared to NB-loT, with higher data rates and is not quite as power efficient as NB-loT.

[0015] Both LTE-M and NB-loT are specified with what is known as User plane and Control plane enhancements for reduced signaling. In user plane solution, the UE supports AS security and Data radio bearers. In control plane, the UE does not support AS security and instead relies on NAS for security, which means that all data is routed through MME. Control plane is mandatory for NB-loT and optional for LTE-M.

[0016] NTN System Information

[0017] As NTN has a number of NTN-specific information elements that are only required when accessing an NTN cell, and also due to the rather large information elements it was agreed that new system information blocks (SIB) was needed.

[0018] In NR NTN, SIB19 contains the required information to access an NTN cell. Referring to TS 38.331 [6], the following is disclosed in relation to SIB19: SIB19 SIB19 contains satellite assistance information for NTN access. SIB19 information element x n>. . N‘®rC 1 ", Rof oron'arLoua at ion-rlt IITII-IIoighCrllConf igLiat-rlt SSBsBSBSBCBS iCBBEiBRssf BBCRttst Rat aranceLc-cat Ban-vl" Sat 3- 'it'abWitRRaSgnc-rlf ^B^iiillllllllllllllllllllll iiiiiiiiiiiiiiiiiiiiiiiiiiii ^l|l||lii||||||||||||||||||; ;itiiiiiiiiiiiiii^^ 5 (U.gj.-rrg,. .g ref erencek'cat irn-rl" lateMonCritica lErtenMon liiiiiiiiiii ntn-HeighCellCmf igListEnt-—17 2 71 nrrun^Kf ftrent eLor^tivn^rlc' ?$<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< $ at Swit cN'Ut hKeSynt-vl a llllilllllllllllllllllllll iiiiiiiiiiii NTN-NeighCellConfigList-rl" : : = IiTIi-IieigbCallConfig-rl~ ::= sssssfi£BSS§B®®SS®j3ssssssstt tttttearrgsrnsgg® jSsssssstig SSSSSgHBSBe IS jSg® jSssssssst iiiiiiiiiiiiiiiiiil SatSvitcRTlithReSyn'a-vlt : : = nt n-Con f i g - r 13 t-S=r=ic=3t art-rl" sab-Tim<aOf fret-rl* |||||||||||||||||||| SIB19 field descriptions I distanceThresh i Distance from the serving cell reference location and is used in location-based measurement initiation in I I RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304

[20] , Each step represents 50m. This field is only | I present in an NTN cell. i I movingReferenceLocation I Reference location of the serving cell of an NTN Earth moving system at a time reference. It is used in location- i i based measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304

[20] , The time I I reference of this field is indicated by epochTime in ntn-Config of the serving cell. This field is excluded when i i determining changes in system information, i.e., changes to movingReferenceLocation should neither result in I I system information change notifications nor in a modification of valueTag in SIB1. This field is only present in an i | NTN cell. | i ntn-Config I Provides parameters needed for the UE to access NR via NTN access such as Ephemeris data, common TA i i parameters, k_offset, validity duration for UL sync information and epoch. In a TN cell, this field is only present in I I ntn-NeighCellConfigList and ntn-NeighCellConfigListExt. i i ntn-NeighCellConfigList, ntn-NeighCellConfigListExt I Provides a list of NTN neighbour cells including their ntn-Config, carrier frequency and PhysCellld. This set i i includes all elements of ntn-NeighCellConfigList and all elements of ntn-NeighCellConfigListExt. If ntn-Config is I i absent for an entry in ntn-NeighCellConfigListExt, the ntn-Config provided in the entry at the same position in ntn- I I NeighCellConfigList applies. Network provides ntn-Config for the first entry of ntn-NeighCellConfigList. If the ntn- i i Config is absent for any other entry in ntn-NeighCellConfigList, the ntn-Config provided in the previous entry in I I ntn-NeighCellConfigList applies. i i referenceLocation I Reference location of the serving cell provided via NTN quasi-Earth fixed system and is used in location-based i i measurement initiation in RRC_IDLE and RRC_INACTIVE, as defined in TS 38.304

[20] , This field is only I i present in an NTN cell. I i saiSwiichWithReSync I Provides parameters for the target satellite required to perform satellite switch with re-synchronization. This field | I is only present in an NTN cell and its presence indicates that satellite switch without PCI change is supported in i it he cell. I I t-Service i Indicates the time information on when a cell provided via NTN system is going to stop serving the area it is I I currently covering. This field applies for both service link switches in NTN quasi-Earth fixed system and feeder i i link switches for both NTN quasi-Earth fixed and Earth moving system. The field indicates a time in multiples of I i 10 ms after 00:00:00 on Gregorian calendar date 1 January, 1900 (midnight between Sunday, December 31, I I 1899 and Monday, January 1, 1900). The exact stop time is between the time indicated by the value of this field i i minus 1 and the time indicated by the value of this field. The reference point for t-Service is the uplink time I [ synchronization reference point of the cell. This field is only present in an NTN cell. ]

[0019] In loT NTN, SIB31 contains the required information to access an loT NTN cell. Referring to TS 38.331 [6], the following is disclosed in relation to SIB31: - SystemlnformationBlockType31 The IE SystemlnformationBlockType 31 contains satellite assistance information for the serving cell. SystemlnformationBlockType 31 is only signalled for an NTN cell. SystemlnformationBlockType31 information element Syst amlnfEEiuat iEnElEckTypatI-eIT ::= SEoNENCE { s^Evingcat ellit S'Inf’i'-rl"7 S»Evingcat ellit S'lnfE-El"7 lateHonCEiticalEEtenaiEn OCTET STRING OPTIONAL, stat eVect’SES EplTS'ins'Eisct at ^’’S'CtEES-El"?, nt s-CnmmnnDri f t - rl"7 ||||||:|:::|R#gggK: (U..CM7?) OPTIONAL, BtiilBiiiBBBBB -- OP OE- i^iiiiiiiiiiiiiiiiiiiiiii u 1 - 3 yn c" a1i C i t yDu r a t i on-r1~ BBBBtBliiiliBB? {aE, aid, alE, add, iQjSdiSS'SS'QsQQS , 340, i add, add, add, a d >j, aldd, alfd, ^240, ; add J SEQUENCE { BBBBBBBBBEiiBIBII at art SubFrama-rl^ llllllljfNiEBEE llllllllllll^^ RRBBM&eiiiO OE' oQngognB e?e? |||:i8QEQER|BBi.i iOowitssssssssss Bli^iBBBBBBBBBBBBBBBBBBB^ OE- I i BiBBBiB 11 Satalliteld BMsSsSsSsSsSsSsSs BtBlIBIilBBBB^ — OR ::: O O OiO OCR O ibNR O 8 : : : : : : lllllllllBiBBl fitedCall-rlS Referen^^Lvcstinn-rltf : SSSSSSSSSSM§ya:H§§g3:lS®iSSSSSS::::::::::::: R~f inn-rl R iQOiQNME^IIl — Need tt dial anceThreah~rl8 BBBBBBBBB^illBBBl rd..655B5) OPTIONAL RdBiBoB OR System lnformationBlockType31 field descriptions I distanceThresh i Distance from the serving cell reference location and is used in location-based measurement initiation in | [ RRC_IDLE (as specified in TS 36.304 [4]) and RRC_CONNECTED. Each step represents 50m. I i epochtime ] I Epoch time of the satellite ephemeris data and common TA parameters, see TS 36.213

[23] , This field also I i indicates the epoch time for the reference location of earth moving cells if present. The reference point for i I epoch time of the serving satellite ephemeris and Common TA parameters is the uplink time synchronization I I reference point when this field is provided in an NTN cell and the eNB when this field is provided in a TN cell. I i epochTime is the starting time of a DL subframe indicated by startSFN and startSubframe. For serving cell, i I the startSFN indicates the current SFN or the next upcoming SFN after the frame where the message I i indicating the epochTime is received. i i If the field is absent, the UE uses the starting time of the DL subframe corresponding to the end of the SI i I window during which the SI message carrying SIB31(-NB) is transmitted. I i E-UTRAN always includes epochTime when SIB31(-NB) is provided through dedicated signalling. i I In case of handover or conditional handover, this field is based on the timing of the target cell, i.e. the I I startSFN and startSubFrame number indicated in this field refers to the SFN and sub-frame of the target cell, I i and UE considers the target cell epoch time (indicated by the startSFN and startSubFrame in this field) to be i Lthe frame nearest to the frarn^ I i k-Mac ] I Scheduling offset used when downlink and uplink frame timing are not aligned at the eNB, see TS 36.213 I i

[23] , Unit in ms. i I If the field if absent, the UE uses the (default) value of 0. I i k-Offsei I Scheduling offset used in the timing relationships in NTN, see TS 36.213

[23] , Unit in ms. I i nta-Common I Network-controlled common TA, see TS 36.213

[23] , Unit of ps. I Step of 32.55208 xW3 ps. Actual value = field value * 32.55208 xW3 i If the field is absent, the UE uses the (default) value of 0. i i nia-Commonbrift i Drift rate of the common TA, see TS 36.213

[23] , Unit of ps / s. i I Step of 0.2 xi O'3 ps / s. Actual value = field value * 0.2 xi O'3 I Ljf the fiejd is ab^ i I nta-CommonbriftVariation i Drift rate variation of the common TA, see TS 36.213

[23] , Unit of ps / s2. i I Step of 0.2 xiO’4 ps / s2. Actual value = field value * 0.2 x10’4. I i If the field is absent, the UE uses the (default) value of 0. i I orbiialParameiers i Instantaneous values of the satellite orbital parameters. The signalled values are valid at least for the duration i I as defined by ul-SyncValidityDuration and epochTime. I i referenceLocation I Reference location of the NTN quasi-earth fixed cell or earth moving cell, used in location-based I I measurement initiation in RRC_IDLE (as specified in TS 36.304 [4]) and RRC_CONNECTED. If configured I i by an earth moving cell, the broadcast reference location corresponds to the epoch time, and the UE derives i [ the real-time reference location based on the serving satellite ephemeris, see TS 36.304 [4], I i siaieVectors ] I Instantaneous values of the satellite state vectors. The signalled values are valid at least for the duration as I i defined by ul-SyncValidityDuration and epochTime. i I ul-SyncValidityburation i Validity duration of the satellite ephemeris data and common TA parameters, i.e. maximum time duration i I (from epochTime) during which the UE can apply the satellite ephemeris without acquiring new satellite I I ephemeris, see TS 36.213

[23] , Unit in second. I i Value s5 corresponds to 5 seconds, value s10 corresponds to 10 seconds and so on. i I The ul-SyncValidityDuration is only updated when at least one of epochTime, nta-CommonParameters, I i ephemerisinfo is updated. i

[0020] The system information contains the following: Serving cell Ephemeris elements - which allows UE to calculate the satellite 5 position for doppler and time pre-compensation. This can be of two formats: o PVT format - which describes a (X,Y,Z) position as well as a speed vector (vX, vY, vZ). o Orbital parameters - this describes the orbital movements of the satellite which is then used to infer the satellite position. - TA common parameters - this provides the common timing advance parameters which is introduced to compensate for the feeder link delays. The signaling consists of (in total taking up 57 bits) o Absolute TA common, taking up 23 bits. o Drift of the TA common - how the TA common drifts, i.e. the first derivative, taking up 19 bits. o Variation of the TA common - how the TA common varies, i.e. the second derivative of the TA common, taking up 15 bits. Synchronization validity duration - used to define how long the ephemeris and TA common is valid. Epoch time - when the synchronization validity duration should start. K-Offset - scheduling offset for timing relationship in NTN. K-Mac - Scheduling offset used when the downlink and uplink frame timing is not aligned. NR NTN specific information also include (as part of TS 38.331 [6]): o T-Service (signaled in SIB3 in loT NTN). o Reference location and distance threshold - used for location-based measurement initiation in RRC IDLE and RRC Connected mode. o Neighbour cell ephemeris ■ This is used for idle mode measurements.

[0021] NTN System Information acquisition

[0022] As the ephemeris constantly changes due to the movement of the NTN payload, there is a need to make sure that the UE is correctly synchronized. Thus whenever a UE is connected to an eNB, the UE needs to read the system information. There is furthermore a timer (T317) associated with the ephemeris element that is started every time SIB31 is read. At expiry of T317, the UE is no longer considered synchronized and it will have to re-acquire SIB31 in order to stay synchronized. In NR NTN, the UE shall ensure that it has a recent ephemeris (SIB19 in NR) by reading the SIB in time by UE implementation. In loT NTN, since an loT UE (LTE-M and NB-loT UE) is not expected to be able to acquire system information in connected mode, the UE tunes away and is likely unreachable while reading SIB31. If the loT NTN UE is unable to read the SIB31 within a timer (T318) with a configured duration, the UE performs RLF (radio link failure) similar to other cases where RLF is performed. This operation can be seen in Figure 2.

[0023] Figure 2 illustrates receipt of SIB31 and timers T317 and T318 according to an example. That is, Figure 2 illustrates an ephemeris synchronization operation, where in a) SIB31 functions as normal and b) where UE fails to read SIB31 during T318 which then expires and triggers RLF.

[0024] In Figure 2 a), SIB31 is received (e.g. by a UE) at a time corresponding to 210. Upon or following expiration of timer T317, timer T318 starts. At a time corresponding to 215, SIB31 is received, before expiration of timerT318.

[0025] In Figure 2 b), SIB31 is received (e.g. by a UE) at a time corresponding to 220. Upon or following expiration of timer T317, timer T318 starts. At a time corresponding to 225, timer T318 has expired without SIB31 having been received. RLF is therefore triggered.

[0026] The T317 timer is different compared to a normal timer in RRC (radio resource control) as it is not started at having received the SIB31. This is because the ephemeris has an epoch time, which is the reference point in time of when the ephemeris is defined. Thus the T317 is started from the epoch time, which may be in the past or in the future relative to have received SIB31. This means that in a UE implementation, the timer may be started with a different value with what was signaled according to what was signaled in the field ul-SyncValidityDuration in SIB31.

[0027] Initial / random access procedure in loT NTN

[0028] An example of an initial access procedure can be seen in Figure 3.

[0029] Briefly, the steps of Figure 3 may be considered as follows: • S310-UE in RRC idle. • S320 - 0. GNSS measurement, acquire SIB31 and self pre-compensate. • S330 - 1. Msg1 / preamble. • S340 - 2. Msg2 / RAR. • S350 - Scheduling Msg3. • S360 - 3. Msg3 (PUSCH). • S370 - 4. Msg41 Contention Resolution (PDSCH).

[0030] In more detail, the steps of Figure 3 may be described as follows:

[0031] In operation S310, the UE is in RRC idle mode.

[0032] In operation S320, the UE determines the timing advance (TA) pre-compensation using the UE position and the satellite position. The UE position is via GNSS, but other methods that do not rely on the network may also potentially be used, such as using inertial navigation system or similar. The satellite position is acquired via SIB19 and the UE also pre-compensates using TA-Common, which is the common timing advance from the satellite to the ground gate way where the base station resides.

[0033] In operation S330, the UE uses the pre-compensation and sends Msg1 which is the RACH (random access channel) preamble. The RACH preamble will represent a number between 1 and 64. The number selected by the is random, but there exists several rules to determine the range of preambles, depending on configurations and conditions - sometimes referred to as preamble division.

[0034] In operation S340, if the network (e.g. eNB, CN etc.) is able to detect and the determine the RACH preamble, the eNB responds with Msg1 or RAR (random access response).

[0035] In operations S350 and S360 (note, these may be combined into a single operation of scheduling and sending Msg3), the UE sends Msg3, which is sent using PUSCH (physical uplink shared channel). This message contains the first RRC message. The RRC message depends on the specific reason why the random access procedure was triggered. For example: for initial access it will be RRCSetupRequest; for resuming it is RRCConnectionResumeRequest; for reestablishing RRC it is RRCConnectionReestablishmentRequest; for CP-EDT it is RRCEarlyDataRequest etc.

[0036] In operation S370, since it is possible that two UEs select the same RAPID (random access preamble ID), there is a chance of collision. So in Msg4, sent over PDSCH in operation S370, this contention may be resolved using the Contention Resolution MAC CE. Msg4 also contains an RRC message that is a response to Msg3. This can for instance be RRCConnectionSetup, RRCConnectionResume, RRCConnectionReestablishment, RRCReject, RRCEarlyDataComplete etc.

[0037] Msg5 is a further message that is scheduled uplink message which would consist of the reply to the downlink RRC message in Msg4. Msg5 is sometimes not considered a part of the random access procedure, but a part of any access procedures. The RRC message carried in Msg5 may be RRCConnectionSetupComplete, RRCConnectionResumeComplete, RRCConnectionReestablishmentComplete and so on. Msg5 is not illustrated in Figure 3.

[0038] EDT

[0039] EDT (early data transmission) is a feature that allows a UE to start to transmit data already in Msg3. This is mostly for power-saving purposes where in the best case the UE would be able to transmit all of its data and then be released already in Msg4. In RRC Resume, the UE may not start transmitting data until after RRCResumeComplete in Msg5.

[0040] An example of the EDT procedure can be seen in Figure 4, from the perspective of PHY layer, MAC and RRC.

[0041] Briefly, the steps of Figure 4 may be considered as follows: • S410-UE in RRC idle • S420 - 0. GNSS measurement, acquire SIB31 and self pre-compensate. • S430 - 1. Msg1 / preamble. • S440 - 2. Msg2 / RAR. • S450 - Scheduling Msg3. • S460-3. Msg3 (PUSCH) RRCEarlyData - CP / RRCResumeRequest + Data - UP. • S470 - 4. Msg41 Contention Resolution (PDSCH) RRCearlyDataComplete - CP / RRCConnectionRelease - UP.

[0042] In more detail, the steps may be described as follows:

[0043] Operation S410 - UE is in RRC idle mode.

[0044] Operation S420 - same as in any random access procedure (e.g. see operation S320 of Figure 3).

[0045] Operation S430 - same as in any random access procedure (e.g. see operation S330 of Figure 3), but the UE selects a RACH preamble from a specific set of preambles that indicates that the UE will perform EDT.

[0046] In operation S440, if the network is able to detect and the determine the RACH preamble, the eNB responds with Msg2 or RAR.

[0047] In operations S450 and S460 (note, these may be combined into a single operation of scheduling and sending Msg3) UE sends Msg3, which includes user data transmissions. In User plane EDT, the Msg3 consists of the RRC message RRCConnectionResumeRequest along with data from a Data Radio Bearer (DRB). In Control plane EDT, the Msg3 consist of the RRC message RRCEarlyDataRequest which in term contains a field for sending NAS messages which may contain data.

[0048] In operation S470, the Msg4 is sent by the network. In User plane, if successful, this may contain the RRCConnectionRelease and a data message. If not successful or if there is more data to be sent, the network may reply with an RRCConnectionResume or RRCConnectionSetup. In Control plane, if successful this may contain the RRCEarlyDataComplete, which also has a container for downlink data. In Control plane, if not successful or if there is more data to be sent, the network may reply with RRCConnectionResume or RRCConnectionSetup.

[0049] PUR

[0050] PUR (preconfigured uplink resources) is a feature that allows for pre-configuring uplink transmissions without the need for random access. It also means that data can be transmitted without the UE needing to move to RRC connected, saving time and power consumption.

[0051] The PUR procedure can be seen in Figure 5, from the perspective of PHY layer, MAC and RRC.

[0052] Briefly, the steps of Figure 5 may be considered as follow: • S510-1. PURConfigurationRequest. • S520 - 2. RRCConnectionRelease (pur-Config). • S530 - 3. UE suspends RRC connection and goes to RRC idle. • S540 - 4. Data arrives in UL buffer. • S550 - 5. GNSS measurement, acquire SIB31 and self pre-compensate. • S560-6. PUR (PUSCH) • S570 - 7. Response.

[0053] In more detail, the steps of Figure 5 may be describes as follows:

[0054] In operation S510, a UE may optionally send a request to request the UE to be configured with PUR. This request contains the requested number of PUR occasions, the periodicity and offset as well as the Transport Block Size (TBS), i.e. the size of the allocation for PUR.

[0055] In operation S520, if the network determines that the UE shall go to RRC idle and that it would be beneficial for the UE to be configured with PUR, then the network releases the UE and configures pur-Config (e.g. a PUR configuration) in the RRCConnectionRelease message.

[0056] The PUR configuration contains the parameters that gives the PUR resource, such as periodicity and offset, the startSFN, the start subframe, the number of PUR occasions, the PUR-RNTI, the pur-TimeAlignmentTimer, and RSRP threshold, a response window timer, the configurations for MPDCCH, PDSCH, PUCCH and PUSCH and the PDSCH frequency hopping.

[0057] In operation S530, the UE suspends the RRC connection and moves to RRC idle.

[0058] In operation S540, traffic arrives in the uplink buffer.

[0059] In operation S550, in an NTN the UE would at least have to self-precompensate the timing advance. The UE may potentially also have to acquire the GNSS position as well as acquire SIB31 to ensure that it has the most updated satellite ephemeris.

[0060] In operation S560, the UE uses the configured PUR-resources and performs uplink transmission using PUSCH: a. In control plane (CP) solution the PUR message consist of the RRC message RRCEarlyDataRequest, which contains the transparent NAS container which may contain data or NAS signalling. b. In user plane (UP) solution the PUR message consists of the RRCConnectionResumeRequest as well as uplink data from any of the radio bearers that triggered the PUR.

[0061] In operation S570, the network responds to the PUR: a. In CP solution the response may include 1) a Layer 1 acknowledgement, 2) a Timing Advance MAC CE command that updates the TA or 3) an RRCEarlyDataComplete. If none of these are received, the UE considers the procedure to not be completed. b. In UP solution the response either include the RRCConnectionRelease message which successfully completes the PUR transmission or the RRCConnectionResume or RRCConnectionSetup to continue the RRC connection. The response may also (i.e. optionally) include downlink data transmissions.

[0062] In 3GPP Release 19 loT NTN there is the following objective (from RP- 234077 [5]): • Support of Capacity enhancements for uplink o Study then specify, if beneficial, enhancements to enable multiplexing of multiple UEs (e.g. up to the min of 4 and the maximum allowed by the existing UL and DL signalling) in a single 3.75 kHz or 15 kHz subcarrier via orthogonal cover codes (OCC)for NPUSCH format 1 and NPRACH [RANI, RAN2] ■ Multi-tone support for 15 kHz SCS should also be considered Note: Impact of impairment shall be taken into account o Study and specify, if beneficial the following enhancements to reduce the necessary uplink and downlink signaling to complete an EDT transaction [RAN2]: ■ Msg3 transmission without msgl / RAR ■ Efficient delivery (reduced overhead) ofmsg4 / RRCEarlyDataComplete

[0063] With the following justification: Need for Uplink capacity enhancement: NB-IoT NTN is already being deployed live at this very moment. In these early and upcoming deployments, it is clearly emerging that loT-NTN, in particular NB-IoT, will have to support massive capacity in terms of number and types of UE, some of which with worse characteristics than others (e.g. low cost devices, wearables, etc). Multiplexing of UEs by usage of orthogonal cover codes (OCC)for NPUSCH format 1 and NPRACH should therefore be studied and if beneficial being specified. Therefore, in order to unlock the additional UL capacity potential, there is a need to identify methods to de-couple the ULfrom the DL as much as possible.

[0064] RACH-less, which was introduced in 3GPP LTE in Release 14 and for 3GPP 5G NR in Release 18, is a feature to allow for handovers without performing random access. This means that RACH-less is only performed when it has been dedicatedly configured by the network. In 3GPP Release 19 loT NTN, in order to increase uplink capacity, it is proposed to introduce efficient access and data delivery procedure without performing random access - essentially a RACH-less data delivery procedure from RRC idle.

[0065] Preconfigured Uplink Resource (PUR) has been suggested to partly address this, but the resources of PUR are pre-configured and contention-free. As a result, the RACH-less feature or the PUR feature has to become contention-based. The contention-based RACH-less will have a lot of issues that need to be solved, including issues such as: — How are the RACH-less resources selected — What are the conditions for performing RACH-less — How does one fall back from RACH-less SUMMARY

[0066] It is an aim of certain examples of the present disclosure to address, solve and / or mitigate, at least partly, at least one of the problems and / or disadvantages associated with the related art, for example at least one of the problems and / or disadvantages described herein. It is an aim of certain examples of the present disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein.

[0067] According to a first aspect of the present disclosure, there is provided a user equipment (UE) comprising: a receiver; a transmitter; and at least one processor configured to: while the UE is in a non-connected mode: measure reference signal received power (RSRP) for a serving cell; and based on the measured RSRP being greater than a threshold, perform a random access channel (RACH)-less data transmission procedure. Advantageously, this may support (early) data transmission without performing an access procedure.

[0068] In various examples, the UE is configured with different configuration information for each of a plurality of coverage levels; and wherein the at least one processor is configured to select configuration information, from among the configuration information for each of the plurality of coverage levels, and select resources for the RACH-less data transmission procedure based on the selected configuration information.

[0069] In various examples, configuration information for each coverage level comprises a number of repetitions or modulation and coding scheme (MCS).

[0070] In various examples, each coverage level corresponds to a RSRP threshold; and wherein selecting the configuration information comprises selecting configuration information for a coverage level, among the plurality of coverage levels, based on the measured RSRP being above the RSRP threshold for said coverage level and below the RSRP threshold for a subsequent coverage level.

[0071] In various examples, if the measured RSRP is above a first RSRP threshold and below a second RSRP threshold, first configuration information for a first coverage level is selected; if the measured RSRP is above the second RSRP threshold and below a third RSRP threshold, second configuration information for a second coverage level is selected; and if the measured RSRP is above the third RSRP threshold, third configuration information for a third coverage level is selected; and wherein the plurality of coverage levels comprises the first coverage level, the second coverage level and the third coverage level.

[0072] In various examples, a first number of physical uplink shared channel (PLISCH) repetitions are indicated in the first configuration information, a second number of PLISCH repetitions are indicated in the first configuration information, and no or zero PLISCH repetitions are indicated in the third configuration information; and wherein the first number is greater than the second number.

[0073] In various examples, the different configuration information is received by broadcast.

[0074] In various examples, the at least one processor is configured to: perform early data transmission (EDT) with RACH based on the measured RSRP being below the threshold.

[0075] In various examples, the at least one processor is configured to: fall back to early data transmission (EDT) with RACH based on failure of the RACH-less data transmission procedure.

[0076] In various examples, the at least one processor is configured to determine failure of the RACH-less data transmission procedure based on a number of failed attempts of the RACH-less data transmission procedure or receiving an indication of failure of the RACH-less data transmission procedure.

[0077] In various examples, failure of RACH-less data transmission procedure is determined if the number of failed attempts of the RACH-less data transmission procedure reaches a configured number of attempts.

[0078] In various examples, the at least one processor is configured to determine failure of the RACH-less data transmission procedure based on receiving an instruction to fallback to the EDT with RACH.

[0079] In various examples, the instruction to fallback to EDT with RACH is received from the network.

[0080] In various examples, the non-connected mode is RRC idle mode or RRC inactive mode.

[0081] In various examples, performing the RACH-less data transmission procedure comprises: transmitting data during an access procedure.

[0082] In various examples, performing the RACH-less data transmission procedure comprises: transmitting user data to an entity in the serving cell without performing RACH; and / or selecting RACH-less data transmission resources.

[0083] In various examples, the user data is transmitted in Msg3 either without Msg1 being received from the entity or without selecting a RACH preamble.

[0084] In various examples, the at least one processor is configured to: receive, from the entity, a response indicating success of the RACH-less data transmission procedure or a response indicating failure of the RACH-less data transmission procedure.

[0085] In various examples, the entity is a next-generation node B (gNB) or a core network (CN) function.

[0086] In various examples, the RACH-less data transmission procedure is contentionbased.

[0087] According to a second aspect of the present disclosure, there is provided a method of a user equipment (UE), the method comprising: while the UE is in a nonconnected mode: measuring reference signal received power (RSRP) for a serving cell; and based on the measured RSRP being greater than a threshold, performing a random access channel (RACH)-less data transmission procedure.

[0088] In various examples, the UE is configured with different configuration information for each of a plurality of coverage levels; and wherein the method comprises: selecting configuration information, from among the configuration information for each of the plurality of coverage levels, and selecting resources for the RACH-less data transmission procedure based on the selected configuration information.

[0089] In various examples, configuration information for each coverage level comprises a number of repetitions or modulation and coding scheme (MCS).

[0090] In various examples, each coverage level corresponds to a RSRP threshold; and wherein selecting the configuration information comprises selecting configuration information for a coverage level, among the plurality of coverage levels, based on the measured RSRP being above the RSRP threshold for said coverage level and below the RSRP threshold for a subsequent coverage level.

[0091] In various examples, if the measured RSRP is above a first RSRP threshold and below a second RSRP threshold, first configuration information for a first coverage level is selected; if the measured RSRP is above the second RSRP threshold and below a third RSRP threshold, second configuration information for a second coverage level is selected; and if the measured RSRP is above the third RSRP threshold, third configuration information for a third coverage level is selected; and wherein the plurality of coverage levels comprises the first coverage level, the second coverage level and the third coverage level.

[0092] In various examples, a first number of physical uplink shared channel (PLISCH) repetitions are indicated in the first configuration information, a second number of PLISCH repetitions are indicated in the first configuration information, and no or zero PLISCH repetitions are indicated in the third configuration information; and wherein the first number is greater than the second number.

[0093] In various examples, the different configuration information is received by broadcast.

[0094] In various examples, the method comprises: performing early data transmission (EDT) with RACH based on the measured RSRP being below the threshold.

[0095] In various examples, the method comprises: falling back to early data transmission (EDT) with RACH based on failure of the RACH-less data transmission procedure.

[0096] In various examples, the method comprises determining failure of the RACH-less data transmission procedure based on a number of failed attempts of the RACH-less data transmission procedure or receiving an indication of failure of the RACH-less data transmission procedure.

[0097] In various examples, failure of RACH-less data transmission procedure is determined if the number of failed attempts of the RACH-less data transmission procedure reaches a configured number of attempts.

[0098] In various examples, the method comprises determining failure of the RACH-less data transmission procedure based on receiving an instruction to fallback to the EDT with RACH.

[0099] In various examples, the instruction to fallback to EDT with RACH is received from the network.

[00100] In various examples, the non-connected mode is RRC idle mode or RRC inactive mode.

[00101] In various examples, performing the RACH-less data transmission procedure comprises: transmitting data during an access procedure.

[00102] In various examples, performing the RACH-less data transmission procedure comprises: transmitting user data to an entity in the serving cell without performing RACH; and / or selecting RACH-less data transmission resources.

[00103] In various examples, the user data is transmitted in Msg3 either without Msg1 being received from the entity or without selecting a RACH preamble.

[00104] In various examples, the method comprises: receiving, from the entity, a response indicating success of the RACH-less data transmission procedure or a response indicating failure of the RACH-less data transmission procedure.

[00105] In various examples, the entity is a next-generation node B (gNB) or a core network (CN) function.

[00106] In various examples, the RACH-less data transmission procedure is contentionbased.

[00107] According to a third aspect of the present disclosure, there is provided a computer-readable storage medium comprising instructions which, when executed by at least one processor of an electronic device (e.g. a UE), cause the electronic device to perform a method according to any one of the second aspect or examples described above.

[00108] According to a fourth aspect of the present disclosure, there is provided a network comprising a UE according to any one of the first aspect or examples described above.

[00109] Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[00110] Embodiments / examples of the present disclosure are further described hereinafter with reference to the accompanying drawings, in which: Figure 1 shows a schematic representation of an example of a NTN. Figure 2 shows examples of ephemeris synchronization operations where a) SIB31 functions normally and b) where RLF is triggered. Figure 3 is a call flow diagram showing a random access procedure according to various examples. Figure 4 is a call flow diagram showing an EDT procedure according to various examples. Figure 5 is a call flow diagram showing a PUR procedure according to various examples. Figure 6 is a call flow diagram showing a procedure of performing RACH-less data transmission according to various examples. Figures 7a, 7b, 7c illustrate selection of a resource(s) according to various examples. Figure 8 includes a call flow diagram showing a procedure of performing RACH-less data transmission with different coverage levels according to various examples. Figure 9 is a call flow diagram showing a procedure of performing data transmission without random access according to various examples. Figures 10a, 10b are call flow diagrams showing procedures for falling back from RACH-less data transmission according to various examples Figure 11 is a block diagram illustrating an example structure of a network entity in accordance with certain examples of the present disclosure. Figure 12 is a flow diagram illustrating a method according to various examples of the present disclosure. DETAILED DESCRIPTION

[00111] The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of certain examples of the present disclosure. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made without departing from the scope of the invention or disclosure.

[00112] The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings.

[00113] Detailed descriptions of techniques, structures, constructions, functions or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present disclosure.

[00114] The terms and words used herein are not limited to the bibliographical or standard meanings, but are merely used to enable a clear and consistent understanding of the disclosure.

[00115] Throughout the description of this specification, the words “comprise”, “include” and “contain” and variations of the words, for example “comprising” and “comprises”, means “including but not limited to”, and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof.

[00116] Throughout the description of this specification, the singular form, for example “a”, “an” and “the”, encompasses the plural unless the context otherwise requires. For example, reference to “an object” includes reference to one or more of such objects.

[00117] Throughout the description, the expression “at least one of A, B and / or C” (or the like), the expression “and / or”, and the expression “one or more of A, B and / or C” (or the like) should be seen to separately include all possible combinations, for example: A, B, C, A and B, A and C, A and B and C.

[00118] Throughout the description of this specification, language in the general form of “X for Y” (where Y is some action, process, operation, function, activity or step and X is some means for carrying out that action, process, operation, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y.

[00119] Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof described or disclosed in conjunction with a particular aspect, embodiment or example are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith.

[00120] Certain examples of the present disclosure relate to methods, apparatus and / or systems for performing RACH-less communication, such as RACH-less EDT. Various examples provide one or more conditions under which RACH-less communication is performed, e.g. by a UE. Various examples describe how to select resources for RACH-less communication, e.g. PUSCH resources for EDT without RACH. Other examples relate to performing EDT in different ways depending on radio conditions, such as configuring a higher number of PUSCH repetitions for lower RSRP. Yet other examples relate to procedures for fallback in the event of RACH-less communication failure, such as UE controlled or network controlled fallback.

[00121] The following examples are applicable to, and use terminology associated with, 3GPP 5G. However, the skilled person will appreciate that the techniques disclosed herein are not limited to these examples or to 3GPP 5G, and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards. The skilled person will appreciate that the techniques disclosed herein may be applied in any existing or future releases of 3GPP 5G NR or any other relevant standard. For example, the functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function, operation or purpose within the network. In particular, the following disclosure should be considered at least in relation to 6G also, which is expected to use at least part of the 5G architecture, or equivalent, and to which the present disclosure also relates.

[00122] A particular network entity may be implemented as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[00123] The skilled person will appreciate that the present disclosure is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 5G, B5G or 6G. • One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations. • One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information. • One or more further elements, entities and / or messages may be added to the examples disclosed herein. • One or more non-essential elements, entities and / or messages may be omitted in certain examples. • The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example. • The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example. • Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example. • Information carried by two or more separate messages in one example may be carried by a single message in an alternative example. • The order in which operations are performed may be modified, if possible, in alternative examples. • The transmission of information between network entities is not limited to the specific form, type and / or order of messages described in relation to the examples disclosed herein.

[00124] Certain examples of the present disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or a method therefor. Such an apparatus / device / network entity may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). Certain examples of the present disclosure may be provided in the form of a system (e.g., a network) comprising one or more such apparatuses / devices / network entities, and / or a method therefor.

[00125] It will be appreciated that examples of the present disclosure may be realized in the form of hardware, software or a combination of hardware and software. Certain examples of the present disclosure may provide a computer program comprising instructions or code which, when executed, implement a method, system and / or apparatus in accordance with any aspect, example and / or embodiment disclosed herein. Certain embodiments of the present disclosure provide a machine-readable storage storing such a program.

[00126] A network according to one or more of the examples disclosed herein may include one or more of a Network Data Analytics Function (NWDAF) entity, an Access and Mobility Management Function (AMF) entity, a Session Management Function (SMF) entity, a Network Slice Selection Function (NSSF) entity, a Network Repository Function (NRF) entity, Application Function (AF) entity, and an Operation and Maintenance (OAM) entity. The network may include one or more Service Consumers (including one or more of the entities mentioned above and / or one or more other entities) that receive analytics from NWDAF. The skilled person will appreciate that a network may omit one or more of the entities mentioned above and / or may comprise one or more additional entities

[00127] As described above, contention-based RACH-less procedures will have a lot of issues that need to be solved. Various examples of the present disclosure aim to solve, address or mitigate issues(s) relating to such.

[00128] An aspect of the present disclosure relates to, or includes, methods for performing access and data delivery from RRC idle without performing random access. It is to be understood that all examples, aspects, embodiments, teachings etc. disclosed herein may also apply for NR NTN, LTE-M / eMTC NTN, E-UTRA NTN, and 6G NTN - i.e. the present disclosure is not limited to the specific cases used in the illustrative examples described herein.

[00129] Herein, the term “RACH-less EDT” is used, at times, to indicate a procedure where data along with control plane signaling can be transmitted in a contentionbased manner without having to perform random access. This may also be referred to as, or the examples (e.g. methods) disclosed herein may also apply for, “contention-based PUR”, or “EDT without msg1”, or similar. Additionally, in a more general case, examples disclosed herein may be considered to relate to RACH-less data transmission; that is, although the present disclosure tends to refer to RACH-less EDT or EDT without RACH (or the like), it is to be understood that the reference to EDT could be replaced by more general reference to data transmission. In other words, all examples disclosed herein should not be seen as limited to EDT but may instead refer to data transmission in general.

[00130] Figure 6 shows a procedure for performing RACH-less EDT according to various examples of the present disclosure.

[00131] Briefly, the steps of Figure 6 may be described as follows: • S610-UE in RRC idle. • S620 - 0. GNSS measurement, acquire SIB31 and self pre-compensate. • S630 - 1a. Conditions for performing EDT without RACH. • S640 - 1b. Selecting resources. • S650 - 2. PUSCH RRCEarlyData - CP / RRCResumeRequest + Data - UP • S660 - 3a. Response due to success. • S670 - 3b. Failure - fallback to other methods. • S680 - 3c. Failure - fallback to other methods.

[00132] In more detail:

[00133] In operation S610, the UE is in RRC idle mode.

[00134] In operation S620, the UE determines the timing advance (TA) pre-compensation using the UE position and the satellite position. The UE position is via GNSS, but other method(s) that do not rely on the network may also potentially be used, such as using inertial navigation system or similar. The satellite position is acquired via SIB19 and the UE also pre-compensates using TA-Common, which is the common timing advance from the satellite to the ground gate way where the base station resides. It will be appreciated that operation S620 is similar to operation S320 of Figure 3, and so may be omitted from various methods of the present disclosure without impact to the understanding of the skilled person.

[00135] In operation S630, the UE identifies (or determines, acquires, detects etc.) conditions for performing EDT without RACH. In an example, the UE simply determines to perform EDT without RACH. In another example, the UE determines whether a condition for performing EDT without RACH is met or satisfied. Various examples of such conditions are described below in a subsection relating to conditions for performing RACH-less data transmission.

[00136] In operation S640, the UE selects resources. For example, the UE selects RACH-less EDT resources, which may include a set of PUSCH resources. Various examples of selecting resources are described below in a subsection relating to selecting RACH-less data transmission resources.

[00137] In operation S650, the UE transmits Msg3. This may consist of the RRC messages RRCEarlyDataRequest or RRCConnectionResumeRequest, which may include data from a Data Radio Bearer or have the data included in the RRC message.

[00138] In operations S660, S670, the eNB or network transmits a response to the UE. In operation S660, this is a response due to success. In operation S670, this is a failure response which indicates to the UE (e.g. explicitly or implicitly) to fallback to other methods. It will be appreciated that only one of S660 and S670 may be performed by the eNB for a given transmission (e.g. as in S650), as the transmission / reception will either succeed or fail. In various examples, the eNB is configured to be able to perform both of operations S660, S670.

[00139] In operation S680, following operation S670 in which the network indicates failure and, potentially, fallback to other methods, the UE detects or determines failure and is configured to fallback to another method or other methods. In one example, receipt of an indication of failure triggers the UE to fallback to other methods; and in another example, receipt of an instruction to fallback triggers the UE to fallback to other methods.

[00140] Selecting RACH-less data transmission resources

[00141] The following provides examples of how RACH-less resources for data transmission (e.g. EDT) are selected. It will be appreciated that this may provide examples relating to, or of, operation S640 of FIG. 6.

[00142] RACH-less EDT will, as opposed to Preconfigured Uplink Resources (PUR), be contention-based. However, RACH-less, i.e. pre-configured uplink grants, cannot be shared in the same manner as a RACH resource, i.e. the resources are not designed to accommodate and distinguish multiple users. This means it is possible that not all users may be eligible to use the same resources. In other words, if the configured RACH-less EDT resources have a set of PUSCH-resources, then not all UEs can use these resources. Otherwise, as an example, ten users may use the same resources, making it impossible for the UE to decode any of the transmissions, and consequently any re-attempts would suffer from the same problem, if not even worse.

[00143] Therefore, according to an aspect of the present disclosure, the RACH-less EDT resources are contention-based, but the specific resource (e.g. time, frequency or code) selected is based on a UE identity. For example, the selected resource is based on a UE identity, or the specific resource is selected based on a UE identity.

[00144] In various examples, the specific resource can be selected based on any one or more of the following UE identities or information related thereto: Resume Identity, which is a 40 bit sequence o the truncated resume identity, or the l-RNTI (used for RRC inactive when connected via 5GC). o Only a set of the bits of the resume identity may be used, o This can for instance be used for user plane EDT. - UE C-RNTI o Only a set of the C-RNTI may be used, or a hash of the C-RNTI may be employed. o A pre-configured UE TC-RNTI may also be used. - S-TMSI or ng-5G-S-TMSI o For control plane EDT, it may be crucial that S-TMSI is used, as the S-TMSI is also signalled in the RRCEarlyDataRequest. Otherwise the UE risks giving up multiple identities. - Any other UE identity that has been configured o For instance, a RACH-less EDT identity, an EDT identity or a RACH-less identity.

[00145] One advantage of selecting resources based on the UE identity is that the network does not need to configure the specific resources beforehand - which is an significant issue with a lot of features (i.e. that a lot of pre-configurations are needed).

[00146] The time resource may be the resource in a radio frame, or in a super radio frame. The frequency resource may be the resource in a frequency layer if there are multiple frequency layers. The code resource may for instance be the Orthogonal Cover Code. Examples of various resources are illustrated in Figures 7a, 7b, 7c. The axes of the plots shown in Figures 7a, 7b, 7c are for illustrative purposes only, showing time and frequency merely to demonstrate the various resource types, with Fig. 7c implying different code resources.

[00147] Figure 7a illustrates an example of selecting a time resource. In Figure 7a, 710 indicates a number of available resources in time, and one time resource 715 is selected based on UE identity. For example, one time resource 715 is selected from among time resources 710 based on UE_ID.

[00148] Figure 7b illustrates an example of selecting a frequency resource. In Figure 7b, 720 indicates a number of available resources in frequency, and one frequency resource 725 is selected based on UE identity. For example, one frequency resource 725 is selected from among frequency resources 720 based on UE_ID.

[00149] Figure 7c illustrates an example of selecting a code resource. In Figure 7c, 730 indicates a number of available resources in code, and one code resource 725 is selected based on UE identity. For example, one code resource 735 is selected from among code resources 730 based on UE_ID.

[00150] In various examples, the UE identity is used to determine the time, frequency and code resources jointly. The resource may be used to first determine the radio frame and then the specific resource in a slot or in a subframe. Alternatively, only the specific slot or subframe is selected.

[00151] In general terms, the UE identities above may be described as a specific RACH-less resource in time and / or in frequency through a formula, such as a modulus operation or only using certain bits of the UE identity. Some examples of this are as follows:

[00152] In an example, if there is only a time-resource: o t_resource = mod (UE_ID, time_resources), where time_resources = subframes_per_radioframe / uplink_sched_interval ■ the specific subframe can be calculated as subframe = [N * uplink_sched_interval + uplink_start_subframe] mod subframes_per_radioframe o If UE_ID is (00001 FDE13)hex = (2088467)w, and the uplink scheduling interval is 2, and subframes_per_radioframe = 10 ■ the t_resource is 2, i.e the 3rd time resource ■ the specific subframe is thus calculated as subframe = [2 * 2 + 0] mod 10 = 4, (the uplink_start_subframe=O)

[00153] It will be appreciated that this example can be extended to cases of there being only a frequency resource or only a code resource.

[00154] If there are time and frequency resources o t_resource = mod (UE_ID / freq_layer, time_resources), time_resources = subframes_per_radioframe / uplink_sched_interval and freq_layer is the number of frequency layers ■ the specific subframe can be calculated as subframe = [N * uplink_sched_interval + uplink_start_subframe] mod subframes_per_radioframe o f_resource = mod (UE_ID, freq_layer) o If UE_ID is (00001 FDE13)hex = (2088467)w, and the uplink scheduling interval is 2, and subframes_per_radioframe = 10, the freqjayers is 2 ■ the t_resource is 3, i.e the 4th time resource and f_resource is 1, i.e the 2nd frequency resource ■ the specific subframe is thus calculated as subframe = [3 * 2 + 0] mod 10 = 6, (the uplink_start_subframe=O)

[00155] It will be appreciated that this example can be extended to cases of there being time and code resources and to cases of there being frequency and code resources.

[00156] If there are time, frequency and code resources o t_resource = mod (UE_ID / (freq_layer * codejayers), time_resources), time_resources = subframes_per_radioframe / uplink_sched_interval, freqjayer is the number of frequency layers and codejayers is the number of code layers. ■ the specific subframe can be calculated as subframe = [N * uplink_schedjnterval + uplink_start_subframe] mod subframes_per_radioframe o f_resource = mod (UE_ID / code_layers, freqjayer) o c_resource = mod (UE_ID, code_layers) o If UE_ID is (00001 FDE13)hex = (2088467)w, and the uplink scheduling interval is 2, and subframes_per_radioframe = 10, the freqjayers is 2 ■ the t_resource is 1, i.e the 2nd time resource and f_resource is 1, i.e the 2nd frequency resource and code resource is 1 ■ the specific subframe is thus calculated as subframe = [1 * 2 + 0] mod 10 = 2, (the uplink_start_subframe=O)

[00157] It will be understood that the present disclosure considers more general versions of each of the above examples. For instance, where a modulus operation is shown, it may be said that the (time, frequency, code) resource is selected based on UE ID and any other parameter of the modulus operation, such as, for the case of a time resource, “time_resources”, “suframes_per_radioframe”, “uplink_sched_interval” etc. For instance, it can be said that a time resource is selected based on UE ID and “subframes_per_radioframe”.

[00158] In other examples, the RACH-less configuration is configured in a release message or any other dedicated message. In this case the UE identity may not be required. For example, instead of using the UE identity to select a resource(s), the resources to use for RACH-less EDT may be configured in a message received by the UE, such as on release.

[00159] Conditions for performing RACH-less data transmission

[00160] The following provides examples of conditions for performing RACH-less data transmission (e.g. EDT). It will be appreciated that this may provide examples relating to, or of, operation S630 of FIG. 6

[00161] Since performing EDT without performing random access may be more sensitive compared to performing EDT with random access there may need to be conditions fulfilled before performing EDT without performing random access.

[00162] Various examples provide lower / MAC layer conditions for performing RACH-less EDT, e.g. performing RACH-less EDT is based on lower / MAC layer related aspects or parameters. Accordingly, in various examples of the present disclosure, to perform EDT without random access, the RSRP (reference signal received power) to the (serving) cell needs to be larger than a configured threshold (e.g. a predetermined threshold, a set value, etc.). This can ensure that at least the radio conditions are well enough to perform EDT without random access.

[00163] In case the UE is in bad radio condition, but still able to synchronize, it can be beneficial to have different coverage levels of the EDT transmissions. So in various examples, different coverage levels are configured for the RACH-Less EDT transmissions. This is, for example, done by the UE having (e.g. being configured with) different configurations for each coverage level, such as repetitions or MCS (modulation and coding scheme) or similar, depending on the coverage.

[00164] For this, (enhanced) coverage levels can be introduced, which control how many repetitions shall be performed. For instance: — If UE RSRP to the cell is below RSRP thresholdl but above RSRP threshold 2 - perform PUSCH repetition Level! — If UE RSRP to the cell is below RSRP threshold2 but above RSRP threshold 3 - perform PUSCH repetitionLevel2. — If UE RSRP to the cell is below RSRP thresholds but above RSRP threshold 4 - perform PUSCH repetition Levels.

[00165] It will be appreciated that fewer or more levels / thresholds can be implemented, in other examples.

[00166] Figure 8 shows an example of configuring different coverage levels.

[00167] In Figure 8, a call flow diagram represents operations between a UE and eNB (network), while an illustration of preconfigured thresholds is provided.

[00168] Briefly, the steps and features of FIG. 8 may be described as: • S810 - 0. Broadcasted RACH-less EDT configuration. • S820 - 1. UE determines level of repetitions based on RSRP. • S830 - 2. RACH-less EDT (PUSCH) using determined level of repetitions • 840 - RSRP-threshold 1. • 845 - No PUSCH repetitions. • 850 - RSRP-threshold 2. • 855 - PUSCH Repetition level 1. • 860 - RSRP-threshold 3. • 865 - PUSCH Repetition level 2.

[00169] As seen, in operation S820 the UE determines a level of repetitions based on RSRP. This may make use of the RSRP thresholds and corresponding repetition levels shown in the figure. If the UE detects or measures RSRP to be above threshold 1, then there is no repetition (e.g. it is assumed radio condition is good). If the UE detects or measures RSRP to be between thresholds 1 and 2, PUSCH repetition level 1 is determined. If the UE detects or measures RSRP to be between thresholds 2 and 3, PUSCH repetition level 2 is determined, which may provide for a greater number of repetitions than level 1.

[00170] The benefit of this approach is that RACH-less EDT may still be performed when the coverage is poor. Otherwise the UE may need to perform EDT with random access, requiring a lot more resources, or the UE may have to use resources that more tailored towards UEs with good coverage, causing a lot of failures.

[00171] It will be appreciated that, in operation S810 of Figure 8, the UE may receive of RACH-less EDT configuration by broadcast. Here, the UE may select resources for RACH-less EDT procedure based on UE identity (e.g. according to a method described herein) or may be configured to use specific resources by a received message.

[00172] In operation S830, as indicated, RACH-less EDT is performed based on the number of repetitions (if any) determined in S820.

[00173] In other examples, specific uplink grants are configured per coverage level, e.g. per RSRP-threshold. Accordingly, instead of selecting a number of repetitions based on RSRP to the cell or eNB, the UE selects a specific configured uplink grant. Here, an uplink grant is configured per enhanced coverage level.

[00174] Similarly, in other examples, both uplink grant and repetition level may be configured in an enhanced coverage level. This can be seen in Example #1 shown in the Annex below, which indicates an example of a way to implement these teachings of the present disclosure in a technical specification, such as TS 36.331 [6] in this case.

[00175] Various examples provide higher layer / RRC conditions for performing RACH-less EDT, e.g. performing RACH-less EDT is based on higher layer / RRC related aspects or parameters. According to various examples of the present disclosure, to perform EDT without random access, the UE is required or configured to maintain more precise synchronization.

[00176] Therefore, in various examples, the UE acquires (e.g. needs to acquire) the SIB31 just before performing EDT without random access. This can for instance be configurable; i.e., if a bit is signalled, the UE would be required to acquire SIB31 just before performing EDT with random access. This can also be expressed as a requirement for performing RACH-less EDT being that the UE has recently acquired SIB31. In other words, a condition for the UE to perform RACH-less EDT is that that the UE has acquired SIB31 recently (e.g. within a predetermined or configured time); the UE may determine whether this is the case as part of determining whether to perform RACH-less EDT, or may make such a determination and, if it is determined that SIB31 has been acquired sufficiently recently, RACH-less EDT is performed.

[00177] In further examples, the UE can be configured to be allowed (e.g., only allowed) to perform EDT without random access within a certain duration after having acquired SIB31. In other words, in some examples, the UE is restricted to performing EDT without RA within a specific time or period after having acquired SIB31. To put another way still, in various examples, the UE is prevented from performing EDT without random access if it has been more than a given time since SIB31 was acquired. In such examples, such a time or duration may be a hardcoded limit, for instance 5 or 10 seconds, or it may be a configured limit, e.g. configured in system information, for instance SIB1 or even in SIB31. In these examples, a requirement may be that, to perform EDT without random access, the UE has acquired SIB31 within X seconds. This would be different from the current ul-SyncValidityDuration, i.e. T317, in that the T317 may still be fairly long, but this time limit or timer can be short, to ensure that the UE is well-synchronized. Upon expiry of the timer, if the timer is configured, the UE will have to reacquire the SIB31 before performing EDT without random access. This means that both T317 and the new time limit would run concurrently. Some examples of this can be seen in Figure 9.

[00178] Briefly, the operations and features of Figure 9 may be described as follows: • S910 - 1. Acquire SI B31 to synchronize. • S920 - 2a. RACH-less EDT. • S930 - 2b. EDT with RACH. • 940 - RACH-less validity duration (for contention-based RACH-less).

[00179] In more detail:

[00180] In operation S910, the UE acquires SIB31. The UE may therefore synchronise based on the information in SIB31. Following this, a timer such as described above may start, or the UE may otherwise track how long it has been since SIB31 was acquired.

[00181] The duration in which RACH-less EDT may be performed is represented by 940, where duration 940 follows acquisition of SIB31.

[00182] Operation S920 occurs within duration 940, as such operation S920 shows RACH-less EDT performed by the UE. It will be appreciated that the UE may have determined that SIB31 was acquired suitably recently (e.g. before expiation of the duration 940), and as a result determine that RACH-less EDT can be performed or is to be performed.

[00183] Operation S930 illustrates the case where duration 940 has ended / expired (that is, a time when operation S930 is performed is outside duration 940). As a result, the UE cannot perform RACH-less EDT so performs EDT with RACH.

[00184] Similar to the shorter synchronization requirement, in various examples, the uplink synchronization duration is configured to be shorter when a UE performs RACH-less EDT. This can be achieved in different ways. In a first method for achieving this, the UE reduces the value of the ul-SyncValidityDuration or the T317 timer. In various examples, this is done by applying a factor (configured or hardcoded) that makes the timer smaller, or a fixed offset that can be configured or hardcoded. In a second method, the UE uses a separate configured timer for uplink synchronization when performing EDT without random access. This may be called edt-RACH-skip-ValidityDuration, or similar. This can be the value used to apply to T317, but there may also be a separate timer, e.g. called ‘T3XX’, for this purpose.

[00185] In various examples of the present disclosure, the UE performs (e.g. only performs) EDT without random access for either Control Plane EDT or for User plane EDT. This may be configurable, e.g. the network signals for which type of EDT that the UE can perform EDT without random access. This can be useful as the methods and requirements for EDT may be different, and the network may have not implemented the methods required for certain types of EDT without random access.

[00186] In various examples, a condition for performing RACH-less EDT is that the UE is configured to perform RACH-less EDT. This may be configured in an RRC Release message. This means that the UE is only allowed to perform RACH-less EDT if it has been configured in RRC Connection Release. In various examples, this is configurable per cell, meaning that the configuration is only valid in the cell that the UE was released to, or the configuration can be valid for any cell that the UE chooses to resume or perform EDT or RACH-less EDT to.

[00187] According to various examples, a condition(s) to perform RACH-less EDT also encompasses whether to perform RACH-less EDT or to perform EDT with RACH. If any of the above conditions are not fulfilled it may cause the UE to perform EDT with RACH. In other words, for each example disclosed herein of a condition according to which RACH-less EDT is performed, there is also included a corresponding example where non-fulfilment of a given condition results in the UE performing data transmission (e.g. EDT) with RACH.

[00188] Some further options (i.e. examples) for selecting between RACH-less EDT or EDT with RACH are as follows: - The UE (uplink) buffer is above or below a certain threshold, o The buffer being above a threshold can be useful to only ensure that when the amount of data is large, the RACH-less EDT resources are used. o The buffer being below a threshold can be useful if the allocated resources for RACH-less EDT are small, or if the signal processing required for RACH-less EDT is large or scaling with the Transport Block Size (TBS), i.e. the size of the PUSCH data transmission. - Any NTN-related condition, for example: o UE distance to a reference point is larger or smaller than a threshold. In other words, the UE compares its location to a configured location and determines whether the distance to the configured reference location is smaller or larger than a configured threshold. This can for instance be used to ensure that RACH-less EDT is only performed when the UE is located in a location where the signal strength is good or where the UE is likely to have time to perform the procedures. Accordingly, in an example RACH-less data transmission is performed based on a UE location, such as a difference between a UE location and a reference location in relation to a threshold. o Timing related condition, such as the UE time being later then or before a configured time point. This time can be related to t-Service, which is a time point at which the satellite will stop serving a specific area. The relation can be an offset to t-Service, which means that RACH-less EDT may be performed if the UE is close to when the satellite is to stop serving the area. Accordingly, in an example RACH-less data transmission is performed based on UE time, such as how UE time relates to a configured time point.

[00189] In various examples, the selection between RACH-less EDT and EDT with RACH may only be performed if there are resources for EDT with RACH configured.

[00191] Various examples of the present disclosure also relate to falling back from RACH-less EDT.

[00192] Given that RACH-less EDT means that a UE may not perform (NTN) random access (e.g. does not always perform NTN RA), the risk for failure would be greater compared to a UE performing (NTN) random access. Accordingly, it may be beneficial to provide effective procedures for falling back from performing RACH-less EDT to other more secure or reliable procedures such as EDT (with Random access), RRC Resume or even RRC Setup.

[00193] In various examples, if the RACH-less EDT fails, the UE performs one of: Fall back to EDT with RACH, o This can be useful if there are synchronization issues or a lot of interference or very high UE load. Fall back to performing RRC Resume. Fall back to RRC Setup, o This may mean that the UE is unable to locate the UE context

[00194] How the UE performs the fallback may be configurable or may be signalled to the UE. For example, in the event that there are multiple options as to how fallback may be performed, a specific option may be signalled to the UE, or the UE may be configured to perform a different option, from among the multiple options, in different circumstances.

[00195] The failure of RACH-less EDT can be determined either by the UE or by the network. Examples of fallback procedures are illustrated in Figures 10a and 10b.

[00196] In Figure 10a, RACH-less EDT failure is detected by the UE.

[00197] Briefly, the operations of Figure 10a may be described as follows: • S1010a- 1. RACH-less EDT attempted. • S1020a - 2. RACH-less EDT failure detected. • S1030a - 3. Fallback to other access method. • S1040a - 4. Other access method.

[00198] In Figure 10b, RACH-less failure is detected by the network (e.g. eNB).

[00199] Briefly, the operations of Figure 10a may be described as follows: • S1010b- 1. RACH-less EDT attempted. • S1030b - 3. Indicate to fallback to other access method. • S1040b - 4. Other access method.

[00200] When determined by the network, failure may be detected or determined due to the UE context not being available, or that the synchronization (in time or in frequency) was sufficiently off (in other words, wrong or in error). The network thus, in various examples, signals to the UE to fallback from RACH-less EDT, e.g. indicates to the UE to stop attempting to perform RACH-less EDT and perform another type of access attempt using random access. This may be signalled in a Msg4 message, in a contention resolution MAC CE or in any other MAC CE, or in a higher layer RRC message, or in PDCCH. For instance, PDCCH-ordered random access could be used in response to a failed RACH-less EDT.

[00201] When the UE determines the failure, this can be done in a number of ways. Various examples of ways of detecting failure are as follows (e.g. failure may be detected based on any of the following): - A certain number of failed attempts or failed RACH-less transmissions; optional details for implementing this are as follows: o a specific failed attempt can be failing a specific transmission, such as not receiving a response, i.e. an uplink grant to a RACH-less EDT transmission, o a specific failed attempt can be not receiving a response to a set of transmission attempts, ■ in this case, as a further option, the UE may make multiple sets of transmissions attempts, where each set of attempts are a configured number of transmissions, o the number of attempts can be configured. - A certain time of performing the RACH-less EDT has elapsed; optional details for implementing this are as follows: o this can be a configured time within which RACH-less EDT needs to succeed, o the time can be for the whole RACH-less EDT procedure, i.e. successfully delivering the EDT transmission as well as receiving a response to either return to RRC idle or go to RRC connected, or only for a specific transmission to receive a response, such as an UL grant or PDSCH DL transmission, o the time can be for each RACH-less EDT transmission, o the time can be modelled in MAC or in RRC, o upon expiry of the timer the UE may fall back to EDT with RACH, RRC Resume or RRC Setup, o upon expiry the UE may re-attempt RACH-less EDT o there are a number of options for starting the timer (e.g. the separate timer ‘T3XX’” described above, or the timer T317, or a timer relating / corresponding to (e.g. expiring upon the end of) duration 940 of FIG. 9): ■ when transmitting (N)PUSCH in RACH-less EDT • (in the slot or subframe) after or before the first transmission • (in the slot or subframe) after or before the last transmission • (in the slot or subframe) after or before the first transmission in a set of repetitions • (in the slot or subframe) after or before the last transmission of a first set of repetitions ■ when acquiring the SIB31 before starting RACH-less EDT o the timer may be a timer that stops when an uplink grant or a PDSCH transmission is received. - A certain number of attempts, where each attempt is measured by the time that it takes to perform the RACH-less EDT.

[00202] It will be appreciated that failure may be detected according to any one or more of these examples and / or any one or more of the given optional implementation details.

[00203] In various examples of the present disclosure, the RACH-less EDT is configured on a separate non-anchor carrier or a set of separate non-anchor carriers. A nonanchor carrier is a carrier where the UE does not assume that synchronization and system information is / are being transmitted. For instance, the RACH-less EDT may, in some examples, not be performed on the anchor carrier, but only on a separate non-anchor carrier. The RACH-less EDT may be performed on specific non-anchor carrier or on any non-anchor carrier. This would be useful to keep the anchor carrier free from RACH-less EDT, which may use a lot of bandwidth since it would be used for data transmissions that are not scheduled. Similarly, as the RACH-less EDT incurs larger risk of interference due to UEs potentially not being as well synchronized as after having performed random access, it can keep the anchor carrier relatively interference free. If the RACH-less EDT fails on a non-anchor carrier, another access attempt may be performed on a anchor carrier.

[00204] In various examples, the RACH-less EDT is configured in a system information block, such as SIB1, SIB2, orSIB31 or a separate new SIB. One suitable information element would be RadioResourceConfigCommonSIB.

[00205] What would be configured for the RACH-less EDT or for contentious RACH-less can be one or more of (e.g. all of) the following fields: Orthogonal Cover Codes. Number of configured uplink processes. - The scheduling interval of the PUSCH transmission. - The start subframe or slot of the PLISCH transmission. - The uplink grant-like fields, o Hopping flag - indicates whether UE shall perform frequency hopping or not of the PUSCH parameter, o Fixed size resource block assignment - indicates the specific resource block used, i.e the frequency resource, o Truncated modulation and coding scheme (MCS) - decides the modulation and coding scheme used, o CQI request.

[00206] In various examples, the UE may request for RACH-less EDT to be configured. This can for instance be done in an RRC message. The UE may request the TBS (transport block size) and frequency of a RACH-less configuration. For example, this may be requested from the network or eNB.

[00207] According to an example of the present disclosure, there is provided an entity (e.g. a UE) in a NTN, wherein the entity is configured to: determine to perform data transmission (e.g. EDT) without RACH; select one or more resources for the data transmission without RACH; and perform the data transmission based on the selected one or more resources. Optionally, the determination to perform data transmission without RACH is based on detecting one or more condition to be met. Optionally, the one or more condition include: detecting synchronization to have been performed within a specific time or SIB31 to have been acquired within the specific time (e.g. it is determined that a current time or a time for performing data transmission is within a specific duration following synchronization or acquisition of SIB31); receiving an indication from a second entity (e.g. CN or eNB) to perform data transmission without RACH (e.g. on RRC Connection Release); or RSRP (e.g. as measured by the first entity) to be above a configured or predetermined threshold. Optionally, the first entity receives an indication of successful data transmission, after performing the data transmission. Optionally, the first entity receives an indication of failure for the data transmission, after performing the data transmission. Optionally, if the first entity determines RACH-less data transmission failure (e.g. as in any of the examples disclosed herein), the first entity is configured to fallback to another access method, such as fallback to data transmission (e.g. EDT) with RACH, fallback to performing RRC Resume, or fallback to RRC Setup. Optionally, the first entity may receive, from the second entity, an indication to fallback to another access method.

[00208] Figure 11 is a block diagram of an exemplary apparatus, or network entity, that may be used in examples of the present disclosure. The skilled person will appreciate said entity may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[00209] The entity 1100 comprises a processor (or controller) 1101, a transmitter 1103 and a receiver 1105. The receiver 1105 is configured for receiving one or more messages from one or more other network entities, for example as described above. The transmitter 1103 is configured for transmitting one or more messages to one or more other network entities, for example as described above. The processor 1101 is configured for performing one or more operations, for example according to the operations as described above. It will be appreciated that an entity as described herein may be a virtual or logical entity, which may be implemented using or in an apparatus which comprises a processor, an antenna, a receiver and / or a transmitter etc. but which does not itself have a physical form (i.e. would not be said to comprise a processor, an antenna, a receiver and / or a transmitter etc.).

[00210] Figure 12 is a flow diagram illustrating a method according to various examples of the present disclosure.

[00211] The method of Figure 12 is performed by an entity, for example a UE.

[00212] In operation S1210, the entity (e.g. UE) measures RSRP for a serving cell. This may be performed while the entity is in a non-connected mode (e.g. while in RRC idle or RRC inactive, or not in RRC connected).

[00213] In operation S1220, the entity (e.g. UE) performs a RACH-less data transmission procedure based on the measured RSRP being greater than a threshold. This may be performed while the entity is in a non-connected mode (e.g. while in RRC idle or RRC inactive, or not in RRC connected).

[00214] According to various examples, the method comprises one or more features relating to any of the other examples disclosed herein, e.g.: selecting configuration information, from among configuration information for each of a plurality of coverage levels configured for the UE, and selecting resources for the RACH-less data transmission procedure based on the selected configuration information; performing EDT with RACH based on the measured RSRP being below threshold or based on failure of the RACH-less data transmission procedure; transmitting user data to an entity in the serving cell without performing RACH; etc.

[00215] It will be appreciated that, in each example / embodiment / aspect etc. described above, one or more features or operations may be omitted, modified or moved (e.g., to change the order of the features or the operations), if desired and appropriate. For example, referring to the method shown by the call flow diagram of any of the figures, it will be understood that one or more of the operations of these methods may be omitted, such as one or more operations which do not describe an aspect of the disclosure such as conditions for performing data transmission without RACH, selecting resources for data transmission without RACH, falling back from performing data transmission without RACH, or performing data transmission without RACH. Further, it will be appreciated that various examples may relate solely to conditions for performing data transmission without RACH, selecting resources for data transmission without RACH, falling back from performing data transmission without RACH, or performing data transmission without RACH - i.e. in some aspects of the present disclosure it is not necessary to recite all of these operations in combination. Additionally, one or more features or operations from any example / embodiment may be combined with features or operations from any other example / embodiment. In particular, regardless of whether or not a pointer towards a combination of features / examples is found herein, the present disclosure should be considered to include all combinations of two or more of the embodiments, examples etc. disclosed herein, and all combinations of two or more of the features disclosed herein.

[00216] The techniques described herein may be implemented using any suitably configured apparatus and / or system. Such an apparatus and / or system may be configured to perform a method according to any aspect, embodiment or example disclosed herein. Such an apparatus may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). The one or more elements may be implemented in the form of hardware, software, or any combination of hardware and software.

[00217] It will be appreciated that examples of the present disclosure may be implemented in the form of hardware, software or any combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape or the like.

[00218] It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement certain examples of the present disclosure. Accordingly, certain examples provide a program comprising code for implementing a method, apparatus or system according to any example, embodiment and / or aspect disclosed herein, and / or a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium, for example a communication signal carried over a wired or wireless connection.

[00219] While the present disclosure has been shown, illustrated and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the disclosure.

[00220] The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. [00221 ] Annex - Example of Specification text and / or changes based on the present disclosure There is now provided a non-limiting example of how various teachings of the present disclosure may be implemented in a technical specification, such as TS 36.331 (e.g. v18.0.0). Example #1 ------------------------based on TS 36.331 V18.0.0------------------------ - RA CH-Skip Common The IE RACH-SkipCommon is used to specify the RACH-less common resources and parameters. RACH-SkipCommon information element rsch-PkipdcverageLevels-rlP 3EQUE1ICE t3IZE (.1. . ma / zRACH-EkipLevels-rl 3 M RACH- RAAH-RhipConfiqlnfo-rll SEQUEHAE { select ionThreshold-rlS ul-3chedlnt ervel-rl 3 repetitionLevel-rl3 ul —3t srt3ubfrsme-rl3 R3RP-Threshold OPTIOHAL, iilligili^lli^ EIIUHERATED [ s f 2 f efl, efE, eflc, efS2r RACH-SkipCommon field descriptions rach-SkipThreshoid Threshold to determine whether to perform RACH skip or not. repeiitionLevel Threshold to determine whether to perform RACH skip or not. coverageLeveis Coverage levels for RACH-Skip. At least one is configured if RACH-SkipCommon is configured. Acronyms and Definitions (as may be used herein) 3GPP 3rd Generation Partnership Project NW Network 5G 5th Generation NWDAF Network Data Analytics Function 5GC 5G Core OAM Operations and Management 5QI 5G QoS Identifier OS Operating System 5GS 5G System PCF Policy Control Function 5GSM 5G System Session Management PCC Policy and Charging Control 5GMM 5G System Mobility Management PCO Protocol Configuration Options AF Application Function PDR Packet Detection Rule Al Artificial Intelligence PDU Protocol Data Unit AIML Artificial Intelligence / Machine PMF Performance Measurement Function Learning PRS Positioning Reference Signal AM Acknowledged Mode PRU Positioning Reference Unit AMF Access and Mobility Management PSA PDU session anchor Function QFI QoS Flow Identifier (ID) AS Application Server QoE Quality of Experience ASP Application Service Provider QoS Quality of Service ATSSS Access Traffic Steering Switching RACH Random Access Channel & Splitting RAN Radio Access Network AUSF Authentication Server Function RAT Radio Access Technology CDRX Connected Mode Discontinuous RLC-AM Radio Link Control Acknowledge Reception Mode CSI Channel Status Information RLC-UM Radio Link Control Unacknowledge DCAF Data Collection Application Mode Function RSD Route Selection Descriptor DNAI Data Network Access Identifier SA Standalone DNN Data Network Name SBA Service-Based Architecture DNS Domain Name Server SBI Service-Based Interface DRB Data Radio Bearer SCEF Service Capability Exposure Function eNB Evolved Node B SCP Service-Based Communication Proxy EPS Evolved Packet System SCTP Stream Control Transmission FQDN Fully Qualified Domain Name Protocol GBR Guaranteed Bit Rate SDAP Service Data Adaptation Protocol GMLC Gateway Mobile Location Centre SDU Service Data Unit gNB Next generation Node B SIM Subscriber Identity Module GPSI Generic Public Subscription SLA Service Level Agreement Identifier SM Session Management IAB Integrated Access and Backhaul SMF Session Management Function ID Identity / ldentifier SN Secondary Node lloT Industrial Internet of Things S-NSSAI Single Network Slice Selection IMEI International Mobile Equipment Assistance Information Identities SRS Sounding Reference Signal IP Internet Protocol SSC Session and Service Continuity l-SMF Intermediate SMF SUPI Subscription Permanent Identifier LMF Location Management Function TAI Tracking Area Identity MA-PDU Multiple Access PDU TE Terminal Equipment ML Machine Learning TM Transparent Mode MME Mobility Management Entity TS Technical Specification MN Master Node UDM Unified Data Manager MNO Mobile Network Operator UDR Unified Data Repository MPTCP MultiPath TCP UE User Equipment MT Mobile Termination UL Uplink NAS Non-Access Stratum UM Unacknowledged Mode NEF Network Exposure Function UP User Plane NRF Network Repository Function UPF User Plane Function NG-RAN Next Generation Radio Access URLLC Ultra-Reliable and Low-Latency Network Communication NG-eNB Next Generation eNB URSP UE Route Selection Policy NSA Non-Standalone XRM Extended Reality and Media NSSF Network Slice Selection Function

Images