Rach-less early data transmission attempts

Abstract

Provided is a method performed by a first network entity (e.g. a UE) for transmitting data to a second network entity (e.g. a base station) in a contention-based (CB) manner without performing random

Description

BACKGROUND Field Certain examples of the present disclosure provide various techniques relating to Random Access Channel-less (RACH-less) Early Data Transmission ((E)DT) attempts, for example within 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR) and NR-based relay networks. Description of the Related Art In 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR), 3GPP 5G Release 16 has been frozen and work on Release 17 is currently underway. An aim of Release 17 is to develop and improve various features. Internet of Things (loT) Non-Terrestrial Networks (NTN) was a 3GPP study and work item in 3GPP Release 17 to provide NTN access for Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E-UTRAN) loT devices Narrowband (NB) loT and LTE-M I evolved Machine Type Communication (eMTC)) [RP-202689, RAN#90 December 2020], NR NTN was a work item in Release 17 to specify adaptations to allow NR to function over NTNs [RP-211557, RAN#91-e March 2021], NTN 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). The NTN Release 17 architecture and scenario is illustrated in Figure 1. Following the Work items in Release 17 there were work items to enhance NR NTN [RP-220953, RAN#95-e March 2022] and loT NTN [RP-223519, RAN#98-e December 2022] in Release 18. The work item description for loT NTN Release 19 is the following [RP-234077]: • Support of Store&Forward (S&F) satellite operation with full E-UTRAN NodeB (eNB) as regenerative payload, therefore: o Define the necessary enhancements into E-UTRAN (network &User Equipment (UE)) to support S&F operation for delay-tolerant services [RAN3, RAN2, RAN4] ■ At least specify necessary enhancements, e.g. related to S1 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 Quality of Service ((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 (UL) o Study, then specify, if beneficial, enhancements to enable multiplexing of multiple UEs (e.g. up to the minimum of 4 and the maximum allowed by the existing UL and Downlink (DL) signalling) in a single 3.75 kHz or 15 kHz subcarrier via orthogonal cover codes (OCC) for NPUSCH format 1 and NPRACH [RAN1, 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 signalling to complete an EDT transaction [RAN2J: • Msg3 transmission without msg 1 / Radio Resource Control (RAR) • Efficient delivery (reduced overhead) of msg4 / RRCEarlyDataComplete Narrowband loT and LTE-M 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. This supports the massive (mMTC) 5G use case for IMT-2020 The use case of NB-loT is to serve massive loT applications, where requirements, for instance, are to support enhanced coverage, powerefficient 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 a UE to sleep for very long times, relaxed requirements and more efficient signal to establish with a cell. 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. This addressed a slightly wider use case compared to NB-loT, with higher data rates and is not quite as power efficient as NB-loT. Both LTE-M and NB-loT are specified with what is known as User Plane (UP) and Control Plane (CP) enhancements for reduced signalling. In the UP solution, the UE supports AS security and data radio bearers. In the CP solution, the UE does not support AS security and instead relies on NAS for security, which means that all data is routed through the Mobility Management Entity (MME). CP is mandatory for NB-loT and optional for LTE-M. NTN-system Information As NTN has a number of NTN-specific information elements (lEs) that are only required when accessing an NTN cell, and also due to the rather large lEs, it was agreed that new system information blocks (SIB) were needed. NR NTN SIB19 contains the required information to access an NTN cell: (38.331 V18.1.0 [1]) SIB19 contains satellite assistance information for NTN access. ||||gi41444i44|84444 ref erenc^Lucati'jn-rl7 fift anteThreab-rlt nt n-tleigh'lell'lc.nfigLiat-rlt 1 at el InnCr it in alExtension ::::444l44Si4444i4::::::::::::::::::::::::::::::::::::::::::::4:::44:4::4444 iiii888 8888 88 88 88 8888 8888111111111111111111818881881811111111111111818^ iiiiiiiSOtOnOOiiSSBOaOHigriSiiiiiiiiiiiifffsfstl^^ :8:8444444444444444444444444444444444444444444444444444444444444444444444444441 lITH-HoighCollC-rnfigLi^t-rl- :::4:48888888888 Illi::::::::::::::::::::! ::::::::]O£O:OOOOO:0:0:0::::::::::::::::::::::::::::00 nTn-neighCellConfigLiot-rV : :-He i ghC«11Co n f i g - r 17 4 ::::::4:::::4:: :84:488:4 ::::::::::8i88:(i:888444844s4S8444:::i::::::: :::44444 <444444000001:7 4 4 WOO WOO l::: ^4^4^410^00001^1^ 111111414:4:4:4:4:4:4:4:444 :lllllllOS8888£8:888i41111111111111111111111111111111111111111111118888s8818881111111111:^ ::::::1440448814841:::::::::::::::::::::::::::::::^ ::::::::iil4iiii:::::::::::::::::i 00000o0::il:Oiiiiiiiiil r 5 r p - T h res h 01 dbls g 4 - r 13 11888:8881141111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 444484848488481111111111111111111111111111111111111111111111118 iiiuuh~u >flL i4i ii> Li-£-11 t f ^1..4i> 1 Ii ind t-1 Ofl Ir 7 4 - HunOn >flk j4-R^_^titi i^-rl ::- 8844488488844448844448444844448844444444444444 cat? TitchWithReCgnc-rl ? : : = :444444444OOOOOiO0i444444444444 t-ServiOOt-rly 444448444448444 5 SIB19 field descriptions i distanceThresh ; Distance from the serving cell reference location and is used in location-based measurement initiation in 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 movingReferenceLocation i Reference location of the serving cell of an NTN Earth moving system at a time reference. It is used in the i evaluation of eventD2 and condEventD2 criteria for the serving cell in RRC_CONNECTED, and location-based ; measurement initiation in RRC_IDLE and RRC_INACTIVE when distanceThresh is also configured, as defined in i TS 38.304

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

[20] , This field is only i present in an NTN cell. i saiSwiichWiihReSync i Provides parameters for the target satellite required to perform satellite switch with resynchronization. This field i is only present in an NTN cell and its presence indicates that satellite switch without PCI change is supported in I the cell. ; 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 currently covering. This field applies for both service link switches in NTN quasi-Earth fixed system and feeder i link switches for both NTN quasi-Earth fixed and Earth moving system. The field indicates a time in multiples of i 10 ms after 00:00:00 on Gregorian calendar date 1 January, 1900 (midnight between Sunday, December 31, i 1899 and Monday, January 1, 1900). The exact stop time is between the time indicated by the value of this field 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. _________________________________NTN-CovEnh field descriptions_____________________________ numberOfMsg4-RepetitionsList The number of repetitions for PUCCH transmission for Msg4 HARQ-ACK, see clause 9.2.6 in TS 38.213

[13] , The value {n 1} needs to be configured with another value from the list {n2, n4, n8}. If more than one value is configured, a single value from the configured values is indicated in DCI. rsrp-ThresholdMsg4 This threshold used by the UE for determining the report of the capability of PUCCH repetition for Msg4 HARQ-ACK if numberOfMsg4-RepetitionsList is provided, as specified in TS 38.321 [3], satSwitchWithReSync field descriptions i ssb-TimeOffset i Indicates the time offset between the SSB from source and target satellite at the uplink time synchronization ; reference point. It is given in number of subframes. i t-ServiceStart ; Indicates the time information on when the target satellite is going to start serving the area currently covered by i the serving satellite. The field indicates a time in multiples of 10 ms after 00:00:00 on Gregorian calendar date 1st i January 1900 (midnight between Sunday, December 31,1899, and Monday, January 1, 1900). The exact start i time is between the time indicated by the value of this field minus 1 and the time indicated by the value of this i field. The reference point for t-ServiceStart is the uplink time synchronization reference point of the serving ; satellite. 38.331 V18.1.0 [1] In loT NTN SIB31 contains the required information to access an loT NTN cell: (36.331 V18.1.0 [2]) SIB Type 31 contains satellite assistance information for the serving cell. SystemlnformationBlockType31 is only signalled for an NTN cell. SIBType31 IE -- A.SN1STA.RT eyatemlnfO'niiatiO'nElO'oJiTyioeil-rli ::= SEQUENCE ( lateNO'nCritir.alEntenaion OCTET STRING OPTIONAL, a p h e me r 1 a I n f o - r 17 atatelactura o r bi t a 1P a r ame t e r a |i|||||||||||||||||||i nt a-CommonParametera-rl nt a-Ct'mmO'n-tlE nt a-Co.himonDti ft-rl" ill u 1 - S yno v a 11U11 yDu r a 11 o n - r 17 rMa-CommonDrift"ariation-rl • iiiliiilillllllllllllllll Ephorne r i a S t a t aVe a t o r a-r1", EphemeriaOrloit al Paramet era~rl~ INTEGER (I. INTEGER (-261135..261135) ENUMERATED (15, alu, 315, a2u, a 4 5, a 5 Li, a 5 5, a 6 Li OPTIONAL, OPTIONAL IIIIIIIIIIe a 12 6, a 12 L>, -- Need OP -- HeeC OP' NaeC Op ililllilllli aPlti, aluu}, 5 10 15 / / I)1 iii :: ARMalRiCi 0 t 1 3::^^^:^:1:^7:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::3-:- ITEGER <>: ?uh'Fi?3ni6 —i?l .■ 11 ITEGER (f> 1:1:1:1:1:1:1:1:1:1:-0^:5:5:0^^15^:^:^:^:^:^:^:^:8:651:::::0:1 / :::::::::::::::::::: SR (U..1L 30111605515:1 0PTI01IAL, -- 11660 OP 5353510535::^:^.:0:^ i .iteld-rl §000000350 3333333333 1333103:13 lOR:^ 1111111100¾¾ £ f 5:¾¾¾¾¾¾¾¾ ¾¾¾¾¾¾¾ : 1 133333:53: T.p; T ■(^TE1 1 1 ' / 1 1 1 1 1 IWlfeE::<3 ::: jr. p ■ .£•. p ■ pj. ■ ¢= ■ f ■ ■ <■) ■ p- 05150011:^033333333333333333333333333335 m 5i6a|lg|gEgaO / S:Sa:lE8aREll::::::s R6 lOOOl / i 61 i o n - r 1E 0 ITEGER ( 3 . .65535) - P.GlIlGTnp SystemlnformationBlockType31 field descriptions distanceThresh 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. epochTime Epoch time of the satellite ephemeris data and common TA parameters, see TS 36.213

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

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

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

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

[23] , Unit of ps / s. Step of 0.2 xio-3 ps / s. Actual value = field value * 0.2 xio 3. If the field is absent, the UE uses the (default) value of 0. nta-CommonDriftVariation Drift rate variation of the common TA, see TS 36.213

[23] , Unit of ps / s2. Step of 0.2 x104 ps / s2. Actual value = field value * 0.2 xio 4. If the field is absent, the UE uses the (default) value of 0. ; orbitalParameters i Instantaneous values of the satellite orbital parameters. The signalled values are valid at least for the duration as i defined by ul-SyncValidityDuration and epochTime. i referenceLocation i Reference location of the NTN (quasi-)earth fixed cell or earth moving cell, used in location-based measurement ; initiation in RRCJDLE (as specified in TS 36.304 [4]) and RRC_CONNECTED if distanceThresh is also configured. If i configured by an earth moving cell, the broadcast reference location corresponds to the epoch time and is also used i in the evaluation of Event D2 and CondEvent D2, and the UE derives the real-time reference location based on the i serving satellite ephemeris, see TS 36.304 [4], i stateVectors i Instantaneous values of the satellite state vectors. The signalled values are valid at least for the duration as defined by i ul-SyncValidityDuration and epochTime. i ul-SyncValidityDuration i Validity duration of the satellite ephemeris data and common TA parameters, i.e. maximum time duration (from i epochTime) during which the UE can apply the satellite ephemeris without acquiring new satellite ephemeris, see TS ; 36.213(23]. Unit of second. i Value s5 corresponds to 5 seconds, value s10 corresponds to 10 seconds and so on. i The ul-SyncValidityDuration is only updated when at least one of epochTime, nta-CommonParameters, ephemerisinfo ; is updated. 36.331 V18.1.0 [2] The system information contains the following: Serving cell Ephemeris elements - which allow a UE to calculate the satellite 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 signalling 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 38.331): o T-Service (signalled 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 NTN System Information Acquisition 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 the 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 a 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 Radio Link Failure (RLF) similar to other cases where RLF is performed. This operation can be seen in Figure 2. The T317 timer is different compared to a normal timer in RRC 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 than what was signalled according to what was signalled in the field ul-SyncValidityDuration in SIB31. Initial / Random Access Procedure in loT NTN The initial access procedure can be seen in Figure 3. The steps are normally as follows: 0. UE determines the timing advance 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. 1. UE uses the pre-compensation and sends Msg1 which is the RACH preamble. The RACH preamble will represent a number between 1 and 64. The number selected by the RACH is random, but there exists several rules to determine the range of preambles, depending on configurations and conditions - sometimes referred to as preamble division. 2. If the network is able to detect and the determine the RACH preamble, the eNB responds with Msg1 or RAR. 3. UE sends Msg3, which is sent using PUSCH. This message will contain 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 re-establishing RRC it is RRCConnectionReestablishmentRequest, for CP-EDT it is RRCEarlyDataRequest etc. 4. Since it is possible that two UEs select the same RAPID, there is a chance of collision. So in Msg4, sent over PDSCH 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. 5. 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. Early Data Transmission Early Data Transmission (EDT) 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. The EDT procedure can be seen in Figure 4, from the perspective of the PHY layer, MAC and RRC. The steps are follows: 0. Same as in any random access procedure. 1. Same as in any random access procedure, but the UE selects a RACH preamble from a specific set of preambles that indicates that the UE will perform EDT. 2. If the network is able to detect and the determine the RACH preamble, the eNB responds with Msg1 or RAR. 3. UE sends Msg3, which contains 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 consists of the RRC message RRCEarlyDataRequest which in term contains a field for sending NAS messages which may contain data. 4. 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. Preconfigured Uplink Resource Preconfigured Uplink Resource (PUR) 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. The PUR procedure can be seen in Figure 5, from the perspective of PHY layer, MAC and RRC. The steps are follows: 1. 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. 2. 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 in the RRCConnectionRelease message. a. 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. 3. The UE suspends the RRC connection and moves to RRC idle. 4. Traffic arrives in the uplink buffer. 5. 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. 6. UE uses the configured PUR-resources and performs uplink transmission using PUSCH a. In Control plane solution the PUR message consists of the RRC message RRCEarlyDataRequest, which contains the transparent NAS container which may contain data or NAS signalling. b. In User plane solution the PUR message consists of the RRCConnectionResumeRequest as well as uplink data from any of the radio bearers that triggered the PUR. 7. The network responds to the PUR: a. In Control plane solution the response may consist of 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 User plane solution the response either consists of the RRCConnectionRelease message which successfully completes the PUR transmission or the RRCConnectionResume or RRCConnectionSetup to continue the RRC connection. The response may also include downlink data transmissions. Problem Statement In 3GPP Release 19 loT NTN the following objective can be seen: • Support of capacity enhancements for uplink o Study, then specify, if beneficial, enhancements to enable multiplexing of multiple UEs (e.g. up to the minimum 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 [RAN1, 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 signalling to complete an EDT transaction [RAN2J: • Msg3 transmission without msg 1 / RAR ■ Efficient delivery (reduced overhead) of msg4 / RRCEarlyDataComplete With the following justification. Need for Uplink capacity enhancement: NB-loT 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-loT, will have to support massive capacity in terms of number and types of UE, some of which having worse characteristics than others (e.g. low cost devices, wearables, etc.). Multiplexing of UEs by usage of orthogonal cover codes (OCCs) for NPUSCH format 1 and NPRACH should therefore be studied and, if beneficial, specified. Therefore, in order to unlock the additional UL capacity potential, there is a need to identify methods to de-couple the UL from the DL as much as possible. RACH-less as has been introduced in 3GPP LTE in Release 14 and for 3GPP 5G NR in Release 18, is a feature which allows 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 an efficient access and data delivery procedure without performing random access - essentially a RACH-less data delivery procedure from RRC idle. PUR somewhat solves this problem, but the resources of PUR are pre-configured and contention-free. This means that 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: How to perform RACH-less EDT attempts, i.e. how to select resources and what power to use with each attempt. - Whether the methods for RACH-less EDT can be used in RRC connected mode and specific issues in these cases: o What conditions in which to perform RACH-less data transmissions o Success-conditions for RACH-less data transmissions [1] 3GPP TS 38.331 V18.1.0, “Radio Resource Control (RRC)”, Release 18. [2] 3GPP TS 36.331 V18.1.0, “Radio Resource Control (RRC)”, Release 18. The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with respect to the present invention. SUMMARY 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. The present invention is defined in the independent claims. Advantageous features are defined in the dependent claims. Embodiments or examples disclosed in the description and / or figures falling outside the scope of the claims are to be understood as examples useful for understanding the present invention. 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 Figure 1 illustrates the NTN Release 17 architecture and scenario; 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; Figure 3 illustrates a random access procedure; Figure 4 illustrates EDT procedures; Figure 5 illustrates Preconfigured Uplink Resource procedures; Figures 6A and 6B illustrate an example procedure of performing RACH-less (E)DT; Figure 7 illustrates a power ramping procedure; Figure 8 illustrates selecting frequency resources with each attempt aO, a1, a2, a3 - A) selecting the same frequency resource and B) selecting different frequency resources; Figure 9 illustrates selecting time-resources with each periodicity aO, a1, a2 - A) selecting the same time resources with each attempt and B) selecting different time resources with each periodicity, and Figure 10 illustrates a prohibit timer for Msg3 without RACH; Figure 11 illustrates a method that may be used in examples of the present disclosure; and Figure 12 illustrates a network entity that may be used in examples of the present disclosure. DETAILED DESCRIPTION The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of the present invention, as defined by the claims. 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. 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. For example, the functionality of an IAB node in the examples below may be applied to any other suitable type of entity performing functions of a network node. The skilled person will appreciate that the present invention is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 5G. • 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. To satisfy extremely high data rate requirements, the 3GPP 5G NR standard utilises communication frequencies in a relatively high range, from 30 GHz to 300 GHz, corresponding to wavelengths in the millimetre (mm) range (mmWave communication). Such mmWave communication provides a large available bandwidth and high transmission speeds. However, problems with mmWave communication include severe signal path loss and low penetration, resulting in a relatively short transmission range. This in turn requires a greater density of base stations deployment. Certain examples of the present disclosure provide a network or wireless communication system comprising a first network entity and a second network entity according to any example, embodiment, aspect and / or claim disclosed herein. Certain examples of the present disclosure provide a computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any example, embodiment, aspect and / or claim disclosed herein. Certain examples of the present disclosure provide a computer or processor-readable data carrier having stored thereon a computer program according to the preceding examples. 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. For example, in the following examples, a network may include one or more IAB nodes. 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, claim, example and / or embodiment disclosed herein. Certain embodiments of the present disclosure provide a machine-readable storage storing such a program. The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings. 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. This disclosure describes methods for performing access and data delivery procedures from RRC idle, without performing random access. Focus is on aspects such as resource (re-) selection, transmit power and configuring RACH-less (E)DT for connected mode. All proposals, embodiments and examples in this invention apply for any of NR NTN, LTE-M / eMTC NTN, E-UTRA NTN, 6G NTN. In this disclosure, the term “RACH-less (E)DT” may be used to 1) indicate a procedure where data along with control plane signalling can be transmitted in a contention-based manner without having to perform random access, 2) any procedure where random access is performed, but Msg1 and Msg2 are skipped. This may also be called or the methods may also apply for “contention-based PUR”, or “EDT without msg1” or similar. RACH-less (E)DT may be termed “Msg3 without random access”. This is a generalization of RACH-less EDT where any procedure normally using the random access procedure, may perform the random access procedure but only transmit Msg3 and receive Msg4. In this disclosure, the term “RACH-less (E)DT transmission” may be used to mean transmitting a first message of the “RACH-less EDT procedures”. Due to similarities with random access procedures, this message may also be referred to as “Msg3”, since it is an access procedure without the random access procedure, i.e. without Msg1 and Msg2. An example procedure of performing RACH-less (E)DT and the aspects that are covered in this disclosure may be seen in Figure 6A, which is associated with aspects in RACH-less (E)DT Attempts and 6B, which is associated with aspects of Connected Mode RACH-less (E)DT. RACH-less (E)DT Attempts Power-ramping is used in random access procedures for transmitting the PRACH / RACH preamble / Msg1. This is used to control interference, by having the UEs start the random access procedure at a lower transmit power, and to successively increase the likeliness of success by raising the transmit power until increasing to a maximum transmit power thereby increasing the likeliness of success at the expense of interference to intra and inter-cell UEs. In one aspect, a UE performing one or more RACH-less (E)DT attempt may use power ramping of the UE transmit power level. The UE performing the one or more RACH-less (E)DT attempt may successively ramp up the transmit power level if the UE detects that a RACH-less (E)DT attempt has failed. The UE may detect the RACH-less (E)DT attempt failure by not receiving a response from an eNB. The UE may perform a RACH-less (E)DT attempt multiple times. This is more likely to be successful, thus achieving fairness. If the same transmit power level is applied by all UEs, there is a risk that certain UEs will never be successful. The power ramping procedure can be seen in Figure 7. A UE using power ramping to perform one or more RACH-less (E)DT attempt may use the following parameters: - A parameter that gives an initial transmit power level. This can be any of an absolute initial transmit power level, a relative initial transmit power level. One example of a relative initial transmit power level is a received power level at an eNB. In this case, a UE may compute a transmit power level of a RACH-less (E)DT attempt by comparing an estimated path loss to the eNB and a configured received RACH-less (E)DT transmit power level threshold. This may be given in dBm or a linear unit. o In one aspect, a UE may randomly select an initial transmit power level. This can for example be in a span. o This can be a parameter called preamblelnitialReceivedTargetPowerRL-EDT o Power ramping parameters for RACH may be used for RACH-less (E)DT - A parameter that gives a power ramping step for the transmit power level. This may be given in dB or in a linear unit. For each RACH-less (E)DT transmission attempt a UE may use a higher transmit power level. o This can be a parameter powerRampingStepRL-EDT o Power ramping parameters for RACH may be used for RACH-less (E)DT In another aspect, related to RACH-less (E)DT attempt UE transmit power level, a UE may not perform power ramping for RACH-less (E)DT PUSCH attempts. A UE performing a RACH-less (E)DT PUSCH attempt may use power control of the UE transmit power level. For each RACH-less (E)DT PUSCH attempt, a UE may use separate power control parameters. This can be useful as the RACH-less (E)DT PUSCH attempts may be subject to specific requirements, for example to allow for higher probability of success, thus having a UE transmit with higher transmit power levels. Alternatively, in another aspect the UE may perform one or more RACH-less (E)DT PUSCH attempt with a lower transmit power level. This may be needed as the UE is more likely to not be as well-synchronized due to the NTN scenario. A power offset to any other broadcasted power control parameters may be introduced in order to increase or decrease settings of the power control parameters. In one aspect, a UE may be configured to apply a maximum transmit power level for each RACH-less (E)DT attempt. Another aspect of RACH-less (E)DT attempts is what resources are used for each attempt. This is important, as otherwise if two UEs select the same resources, then the UEs may continue to collide with each attempt. While the probability for collision for any specific attempt is the same if two UEs need to transmit the same number of times, a probability of all transmission attempts colliding is much less. Also if an attempt is successful, this also reduces the number of attempts needed. Examples of how to select different resources for RACH-less (E)DT attempts can be seen in Figure 8 and 9. The different resources used by a UE for each RACH-less (E)DT attempt may be in any of frequency, time, code (orthogonal cover code), DM RS, carrier. In one aspect, a network may configure whether a UE shall use different resources with each RACH-less (E)DT attempt. Connected Mode RACH-less (E)DT In one aspect, the methods used for RACH-less (E)DT may be used when a UE is in a connected mode. Note that in RACH-less (E)DT, a UE will not send or use the same RRC messages as when moving from RRC idle or RRC inactive, i.e. not send the RRCConnectionResumeRequest or RRCEarlyDataRequest. Thus the concept of connected mode RACH-less (E)DT may be termed RACH-less Data Transmissions (DT). This may be configurable, i.e. either broadcasted or dedicatedly configurable such that a UE may use a RACH-less (E)DT attempt to transmit data. When performing a RACH-less (E)DT attempt in connected mode, a UE may include a C-RNTI MAC CE in order for the UE to signal its identity and let a network know the UE identity. This C-RNTI would be the C-RNTI that the UE uses in connected mode. This C-RNTI may be different from the TC-RNTI that the UE uses to transmit the RACH-less (E)DT. Connected mode resources may be different from resources used for initial access, or may be different from resources used for idle mode. Applying RACH-less (E)DT in connected mode may be configured or used for a specific circumstance. This can for instance be for any of the following: No uplink resources, i.e. a UE not having been configured with a scheduling request. (Scheduling requests are messages sent to indicate to a network that there is data in the uplink and that the UE wants to have uplink resources - for NB-loT, scheduling requests are carried over RACH) or any PUCCH resources to perform scheduling requests. An example of this can be found in Example #1. Maximum number of Scheduling request attempts have been reached. Loss of uplink timing advance, i.e. a timer, such as timeAlignmentTimer, has expired. The timeAlignmentTimer is started upon receiving a Timing Advance MAC CE and upon expiry a UE can no longer consider its uplink resources as valid. o In this case, the UE may be configured to for example perform a GNSS measurement, or to acquire SIB31 to regain synchronization. - After having performed a GNSS position fix in RRC connected. A RACH-less (E)DT attempt may not be performed when a UE is not properly synchronized in connected mode. This may comprise any of the UE does not have uplink timing alignment, the UE does not have valid uplink synchronization, a timer, such as T317, is not running. Alternatively a UE may not perform a RACH-less (E)DT attempt in connected mode if a recovery timer, such as T318, is running. A UE may not perform a RACH-less (E)DT attempt when the UE does not have a valid GNSS position fix. A RACH-less (E)DT attempt may not be performed by a UE under the duration of the timer T390. This is because the T390 timer is a timer that governs how long the UE may be in RRC connected mode while the GNSS position is not valid. For all of the above cases, in a UE, MAC-to-RRC indications may be needed for a MAC to check whether any timer is running, expired, stopped or not running or any other condition is false or true in order for the UE to proceed with performing a RACH-less (E)DT attempt with data transmissions. To ensure that a connected UE does not excessively perform RACH-less (E)DT attempts, the UE may be configured with a timer that prohibits excessive attempts. This timer may prevent excessive RACH-less (E)DT attempts in a short time. The timer may ensure that after performance of a RACH-less attempt, a UE waits a certain amount of time before performing another RACH-less attempt. This may also be applicable to RACH-less (E)DT from a UE idle mode. This can be seen in Figure 10. When a UE is in connected mode, resources may be randomly selected, or randomly selected from a set of resources that have been computed based on the C-RNTI. A contention resolution for RACH-less (E)DT may be considered successful if, when a UE is in connected mode, the UE included a C-RNTI in MAC CE in Msg3 in any of the following cases: - A PDCCH transmission attempt sent by an eNB is addressed to the C-RNTI of the UE and contains an UL grant for a new transmission attempt - A PDCCH transmission attempt sent by an eNB is addressed to the C-RNTI of the UE - A MAC CE with Timing advance addressed to the C-RNTI is received from the eNB - A Random access response is receive from the eNB addressed to the C-RNTI of the UE o This can potentially also be used for idle mode, i.e. for RACH-less (E)DT - A UE Contention Resolution Identity MAC CE has been received by the UE on the PDSCH by a PDCCH transmission from the eNB addressed to the C-RNTI of the UE FIG. 11 illustrates a method that may be used in examples of the present disclosure. The method may be performed by a first network entity (e.g. a UE) for transmitting data to a second network entity (e.g. a base station) in a contention-based (CB) manner without performing random access. In block 1102, the method comprises transmitting a message comprising control plane signalling and data to the second network entity with a first transmit power. In block 1104, the method comprises determining whether the message transmission has failed. In block 1106, the method comprises retransmitting, in response to determining that the message transmission has failed, the message with a second transmit power, wherein the second transmit power is greater than the first transmit power. FIG. 12 illustrates a network entity (e.g. UE or base station) that may be used in examples of the present disclosure. The skilled person will appreciate that the network entity illustrated in FIG. 12 may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure. The network entity 1200 comprises a processor 1201 (or controller), a transmitter 1203 and a receiver 1205. The receiver 1205 is configured for receiving one or more messages from one or more other network entities. The transmitter 1203 is configured for transmitting one or more messages to one or more other network entities. The processor 1201 is configured for performing operations as described above. Specification Examples Example #1 Example based on 36.321 V18.1.0. As long as one SR is pending, the MAC entity shall for each TTI: - if no UL-SCH resources are available for a transmission in this TTI: - Except for NB-1oT: - if the MAC entity has no valid PUCCH nor valid SPUCCH resource for SR configured in any TTI: - if the MAC entity is a MCG MAC entity and rach-Skip is not configured; or - if the MAC entity is a SCG MAC entity and rach-SkipSCG is not configured: - if the MAC entity has resources for Msg3 without RACH and UE supports Msg3 without RACH: initiate Msg3 without RACH on the SpCell and cancel all pending SRs. - else: initiate a Random Access procedure (see clause 5.1) on the corresponding SpCell and cancel all pending SRs; - else if this TTI is not part of a measurement gap or Sidelink Discovery Gap for Transmission, and if transmission of V2X sidelink communication is not prioritized in this TTI as described in clause 5.14.1.2.2: - if the MAC entity has at least one valid SPUCCH resource for SR configured for this TTI and if ssr-ProhibitTimeris not running: - if SSR_COUNTER <dssr-TransMax'. - increment SSR_COUNTER by 1; - instruct the physical layer to signal the SR on one valid SPUCCH resource for SR; - start the ssr-ProhibitTimer. - else: - notify RRC to release SPUCCH for all serving cells; - if the MAC entity has no valid PUCCH resource for SR configured in any TTI: - notify RRC to release PUCCH for all serving cells; - notify RRC to release SRS for all serving cells; - clear any configured downlink assignments and uplink grants; - initiate a Random Access procedure (see clause 5.1) on the SpCell and cancel all pending SRs. - if the MAC entity has at least one valid PUCCH resource for SR configured for this TTI and if sr-ProhibitTimeris not running: - if SR_COUNTER <dsr-TransMax. - increment SR_COUNTER by 1; - instruct the physical layer to signal the SR on one valid PUCCH resource for SR; - start the sr-ProhibitTimer. - else: - notify RRC to release PUCCH and SPUCCH for all serving cells; - notify RRC to release SRS for all serving cells; - clear any configured downlink assignments and uplink grants; - if the MAC entity has resources for Msg3 without RACH and UE supports Msg3 without RACH: - initiate Msg3 without RACH on the SpCell and cancel all pending SRs. - else: - initiate a Random Access procedure (see clause 5.1) on the SpCell and cancel all pending SRs. - For NB-loT: - if the MAC entity has no valid resource for SR together with acknowledgement of the data in this TTI and no valid PRACH resource for SR configured in any TTI: - initiate a Random Access Procedure (see clause 5.1), and cancel all pending SRs in the first subframe containing PRACH for preamble transmission. - else: - if the MAC entity has valid resource for SR together with acknowledgement of the data in this TTI: - instruct the physical layer to signal the SR together with acknowledgement of the data. - cancel, if any, initiated Random Access Procedure for SR. - else: - if the MAC entity has resources for Msg3 without RACH and UE supports Msg3 without RACH - initiate Msg3 without RACH and cancel all pending SRs - else if the MAC entity has valid PRACH resource for SR configured in this TTI and sr-ProhibitTimeris not running: - instruct the physical layer to signal the SR on one valid PRACH resource for SR. - start the sr-ProhibitTimer in the subframe containing the last repetition of the corresponding SR transmission. 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 examples disclosed herein. Throughout the description and claims, the words “comprise”, “contain” and “include”, and variations thereof, for example “comprising”, “containing” and “including”, means “including but not limited to”, and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, functions, characteristics, and the like. Throughout the description and claims, 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. Throughout the description and claims, language in the general form of “X for Y” (where Y is some action, process, function, activity or step and X is some means for carrying out that action, process, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y. Features, elements, components, integers, steps, processes, functions, characteristics, and the like, described in conjunction with a particular aspect, embodiment, example or claim are to be understood to be applicable to any other aspect, embodiment, example or claim disclosed herein unless incompatible therewith. While the invention has been shown 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 invention, as defined by the appended claims. In a first example, there is provided a method performed by a first network entity (e.g. a UE) for transmitting data to a second network entity (e.g. a base station) in a contention-based (CB) manner without performing random access, the method comprising: transmitting a message comprising control plane signalling and data to the second network entity (e.g. a base station) with a first transmit power; determining whether the message transmission has failed; and retransmitting, in response to determining that the message transmission has failed, the message with a second transmit power, wherein the second transmit power is greater than the first transmit power. In a second example, there is provided the method of the first example, further comprising determining whether the message re-transmission has failed; and retransmitting, in response to determining that the message transmission has failed, the message with a third transmit power, wherein the third transmit power is greater than the second transmit power. In a third example, there is provided the method of the second example, further comprising continuing to retransmit the message until it is determined that the message transmission has not failed, and increasing the transmit power with each message retransmission until a maximum transmit power is reached. In a fourth example, there is provided the method of the first or second example, wherein determining whether the message transmission (or re-transmission) has failed comprises determining that the message transmission (or re-transmission) has failed if a response message is not received from the second network entity. In a fifth example, there is provided the method of any one of the first to fourth examples, wherein retransmitting the message comprises waiting for a predetermined time period from the message transmission (or previous retransmission) before retransmitting the message. In a sixth example, there is provided the method of any one of the first to fifth examples, wherein the first transmit power is determined based on an initial transmit power parameter. In a seventh example, there is provided the method of the sixth example, wherein the initial transmit power parameter is at least one of: an absolute initial transmit power, a relative initial transmit power, a randomly selected initial transmit power, and a random access channel (RACH) power ramping parameter. In an eighth example, there is provided the method of the seventh example, wherein the relative initial transmit power is determined based on a received power level at the second network entity. In a ninth example, there is provided the method of the eighth example, wherein the received power level at the second network entity is determined by comparing an estimated path loss to the second network entity and a configured transmit power threshold. In a tenth example, there is provided the method of any one of the first to ninth examples, wherein the second transmit power is determined based on a transmit power step parameter. In an eleventh example, there is provided the method of the tenth example, wherein the transmit power step parameter is based on at least one power ramping parameter configured for random access channel (RACH). In a twelfth example, there is provided the method of any of the first to eleventh examples, wherein the method is initiated when the first network entity is in an idle mode (e.g. RRC Idle). In a thirteenth example, there is provided the method of any of the first to twelfth examples, wherein the method is initiated when the first network entity is in a connected mode (e.g. RRC Connected). In a fourteenth example, there is provided a first network entity (e.g. a UE) configured to operate according to a method of any of the first to fourteenth examples. In a fifteenth example, there is provided a second network entity (e.g. a base station) configured to cooperate with a first network entity of the fourteenth example according to a method of any one of the first to thirteenth examples. In a sixteenth example, there is provided a network or wireless communication system comprising a first network entity according to the fourteenth example and a second network entity according to the fifteenth example. In a seventeenth example, there is provided a computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any one of the first to thirteenth examples. In an eighteenth example, there is provided a computer or processor-readable data carrier having stored thereon a computer program according to the seventeenth example. Abbreviations / Definitions In the present disclosure, the following abbreviations and definitions may be used. 3GPP 5G 3rd Generation Partnership Project 5th Generation 5 CP Control Plane EDT Early Data Transmission eNB E-UTRAN NodeB eMTC evolved Machine Type Communication E-UTRAN Evolved Universal Mobile Telecommunications System Terrestrial Radio 10 Access Network GEO Geostationary Orbit GNSS Global Navigation Satellite System HAPS High-Altitude Platform Systems HARQ-ACK Hybrid Automatic Repeat Request -Acknowledgement 15 IE Information Element loT Internet of Things LEO Lower Earth Orbit LTE Long Term Evolution MAC Medium Access Control 20 MEO Medium Earth Orbit MME Mobility Management Entity eMTC evolved Machine Type Communication MTC Machine Type Communication mMTC massive Machine Type Communication 25 NB-loT Narrowband loT NR New Radio OCC Orthogonal Cover Codes PDSCH Physical Download Shared Channel PHY Physical 30 PRACH Packet Random Access Channel PUCCH Physical Uplink Control Channel PUSCH Physical Uplink Shared Channel PUR Preconfigured Uplink Resource QoS Quality of Service 35 RACH Random Access Channel RAPID Random Access Preamble ID RAR Radio Resource Control RLF Radio Link Failure RNTI Radio Network Temporary Identifier 40 RRC Radio Resource Control SIB System Information Blocks SSB Secondary Synchronization Block TBS Transport Block Size TS Technical Specification 45 UE User Equipment UL UpLink UP User Plane

Claims

1. A method performed by a first network entity (e.g. a UE) for transmitting data to a second network entity (e.g. a base station) in a contention-based (CB) manner without performing random access, the method comprising:transmitting a message comprising control plane signalling and data to the second network entity (e.g. a base station) with a first transmit power;determining whether the message transmission has failed; andretransmitting, in response to determining that the message transmission has failed, the message with a second transmit power, wherein the second transmit power is greater than the first transmit power.

2. The method of claim 1, further comprising determining whether the message retransmission has failed; andretransmitting, in response to determining that the message transmission has failed, the message with a third transmit power, wherein the third transmit power is greater than the second transmit power.

3. The method of claim 2, further comprising continuing to retransmit the message until it is determined that the message transmission has not failed, and increasing the transmit power with each message retransmission until a maximum transmit power is reached.

4. The method of claim 1 or 2, wherein determining whether the message transmission (or retransmission) has failed comprises determining that the message transmission (or retransmission) has failed if a response message is not received from the second network entity.

5. The method of any one of claims 1 to 4, wherein retransmitting the message comprises waiting for a predetermined time period from the message transmission (or previous retransmission) before retransmitting the message.

6. The method of any one of claims 1 to 5, wherein the first transmit power is determined based on an initial transmit power parameter.

7. The method of claim 6, wherein the initial transmit power parameter is at least one of: an absolute initial transmit power, a relative initial transmit power,a randomly selected initial transmit power, anda random access channel (RACH) power ramping parameter.

8. The method of claim 7, wherein the relative initial transmit power is determined based on a received power level at the second network entity.

9. The method of claim 8, wherein the received power level at the second network entity is determined by comparing an estimated path loss to the second network entity and a configured transmit power threshold.

10. The method of any one of claims 1 to 9, wherein the second transmit power is determined based on a transmit power step parameter.

11. The method of claim 10, wherein the transmit power step parameter is based on at least one power ramping parameter configured for random access channel (RACH).

12. The method of any preceding claim, wherein the method is initiated when the first network entity is in an idle mode (e.g. RRC Idle).

13. The method of any one of claims 1 to 12, wherein the method is initiated when the first network entity is in a connected mode (e.g. RRC Connected).

14. A first network entity (e.g. a UE) configured to operate according to a method of any preceding claim.

15. A second network entity (e.g. a base station) configured to cooperate with a first network entity of claim 14 according to a method of any one of claim 1 to claim 13.

16. A network or wireless communication system comprising a first network entity according to claim 14 and a second network entity according to claim 15.

17. A computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any one of claims 1 to 13.

18. A computer or processor-readable data carrier having stored thereon a computer program according to claim 17.

Images